On Tue, 2007-08-14 at 12:51 -0700, Edward Pilatowicz wrote:
> On Tue, Aug 14, 2007 at 12:42:06PM -0700, Garrett D'Amore wrote:
> > On Tue, 2007-08-14 at 12:28 -0700, Edward Pilatowicz wrote:
> > > On Tue, Aug 14, 2007 at 12:26:46PM -0600, Mark J. Nelson wrote:
> > > >
> > > >
> > > > >> To have "qfe" devices properly represented by the "qfe" driver, while
> > > > >> allowing for "hme" devices to be seen by the "hme" driver, we need
> > > > >> some
> > > > >> code. The only differences between these two devices are:
> > > > >>
> > > > >> 1) qfe has a specific parent PCI bridge
> > > > >> 2) different Fcode
> > > > >>
> > > > >> The point is that admins don't want to rename the devices for qfe to
> > > > >> hme, because it will cause major conversion headaches. And on x86,
> > > > >> it
> > > > >> would be "nice" if qfe devices were still qfe (as they are on sparc)
> > > > >> rather than being known by "hme" in the x86 hardware.
> > > >
> > > > > Both examples sound too special to warrant for any change in the core
> > > > > kernel, imho. I think if any quirks need to be implemented, they
> > > > > should
> > > > > be confined within the driver modules. At least when devices EOL, the
> > > > > ugliness goes away with the drivers; if you let ugliness into the DDI,
> > > > > it's forever.
> > > >
> > > > In the update_drv(1M) manpage, we see that:
> > > >
> > > > > -a Add a permission, aliases, privilege
> > > > > or policy entry.
> > > > >
> > > > > With the -a option specified, a per-
> > > > > mission entry (using the -m option),
> > > > > or a driver's aliases entry (using the
> > > > > -i option), a device privilege (using
> > > > > the -P option) or a a device policy
> > > > > (using the -p option), can be added or
> > > > > updated. If a matching minor node per-
> > > > > missions entry is encountered (having
> > > > > the same driver name and the minor
> > > > > node), it is replaced. If a matching
> > > > > aliases entry is encountered (having a
> > > > > different driver name and the same
> > > > > alias), an error is reported.
> > > >
> > > > ...the point being that "the binding mechanism doesn't know how to
> > > > handle
> > > > this situation." You can't fix this in the driver, because you can't
> > > > bind
> > > > multiple drivers to the same alias.
> > > >
> > > > Why is it ugly to extend the binding mechanism to allow greater
> > > > differentiation between devices?
> > > >
> > >
> > > because the devices we're trying to differentiate between are actually
> > > the same device? the case we're actually trying to handle is when one
> > > of these devices is connected a bridge/bus that we deem "special".
> >
> > Actually, the magic in this case is the presence of fcode. The bridge
> > is just another heuristic to detect it. Checking Fcode contents would
> > be more accurate.
> >
>
> but fcode doesn't exist on x86, or well, it exist on the card but isn't run.
> so our options are to use the heuristic, which is what i said above.
> <joke> or perhaps we should consider using the kernel fcode interpreter
> on x86.</joke>
I suspect, rather strongly, a simpler solution would just to be have
code that groks through the Fcode looking for either the string
"SUNW,qfe" or "SUNW,hme". (x86 code could map the Fcode BAR, and search
through it.)
Again, though, the problem is getting a different driver bound, though.
(probe(9e) runs early enough to do the work, if it runs on PCI devices,
but I am not aware of any way for it say "no, this is really a SUNW,qfe
device"...)
-- Garrett
>
> ed
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
