"David S. Miller" wrote:
> Why not just make the eepro100 driver print out it's bus/devfn
> PCI geography, and then you have "eth%d" and the PCI bits
> to do your groveling with.
This reminds me of an old topic from linux-fbdev -- the X server needs
to know the fbdev device's bus/slot/devfn info, so that it may skip it
when doing its own h/w probe. The current hueristic, as you yourself
pointed out :), is inadequate for 32-bit buses on 64-bit machines.
Attached is Jakub Jelinek's proposal. I agree w/ him - the concept of
being able to report to userspace a device's bus info is very useful for
many situations, including fbdev and $subject.
Jeff
-- Jeff Garzik | Liberty is always dangerous, but Building 1024 | it is the safest thing we have. MandrakeSoft, Inc. | -- Harry Emerson Fosdick
attached mail follows:
On Fri, Mar 24, 2000 at 12:13:48PM -0500, Jeff Garzik wrote: > Attached is a patch which shows something I am interested in getting > into the 2.4.x fbdev API if possible. > > The first change is FBIOGET_BUS_INFO ioctl -- this returns bus info in a > standard text format, for userland apps like the X server to determine > whether or not they should poke at this hardware.
Great, that's what I was gonna to do for SBUS as well. Currently, e.g. RedHat hardware detection has to scan the whole PROM tree and all fbdev devices and try to match them in the order it expects the kernel to match them. Only one question: why do you put a text interface in a binary interface (ioctl)? IMHO it would be much better to put a bus type, structure version number and union (with some reserved fields to make it extendable). Like:
struct fb_bus_info { enum bus_type { BUS_PCI, BUS_SBUS, BUS_ISA, ... } type; int version; union { struct fb_pci_info { int busno; int devfn; int flags; } pci; struct fb_sbus_info { int node; } sbus; struct fb_isa_info { int lowest_io_addr; ???? } isa; ... int pad[32]; } u; }
In fact, it would be even better to make this non-fbdev dependent ioctl, so that I could do this ioctl on say /dev/sda1 to find out what hardware device is the HBA, on /dev/fb0, on eth0 socket... Then there should be a kernel routine which would be able to print this info in human readable format for /proc purposes.
Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj Linux version 2.3.99-pre2 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:11 EST