From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Jansen Date: Sat, 29 Sep 2001 01:15:36 +0000 Subject: Re: IDs (was Re: Hotplugging for the input subsystem) Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Saturday 29 September 2001 01:07, Vojtech Pavlik wrote: > > driver id > > === > > Identifies a loaded driver (a driver can consist of one or more modules, > > or be compiled into the kernel). Drivers can be layered. This is > > neccessary for the equivalent of your PHYS id if you want it to apply to > > other drivers as well. > Ok. Is this needed for anything? It's in the device node id and I also use it for references between driver (for example that "hid" uses "input"). > Small note: function number is more a location than an identifier, > various VIA chipset revisions with the same ID have different assignment > of functions, and each function has its own vendor and model ids. My device id is not used to identify a certain kind (class) of devices, like for example the Plug&Play IDs in Windows. It is used to find a device instance that currently is or has been connected to the system. So if the function changes this is a sign that it's a different device and the id should be different. > This is a problem. USB bus numbers aren't hotplug safe. They are > allocated on first-init-first-get-number basis. With CardBus and HotPlug > PCI and with stuff as simple as loading ohci driver before the uhci one > or vice versa you get different USB bus numbers on subsequent powerups. > The only method to identify the USB busses is by the underlying bus, ie > PCI slot location, not by USB bus number. The PCI location is not used because I wanted to avoid to nest device ids (this is what you have to do if you can not rely on all USB controllers being PCI devices). Usually the numbers dont change and even if they do it's not too bad. I know that USB numbers are fragile, but using the location is better than using nothing. > Also, USB is a hierarchical bus, thus you can plug a hub into one of > the root ports and another hub into that one and so on. You can't stuff > all this into just one 'port number'. Sorry, that was wrong in my mail, the actual location scheme is already :[:...] > Furthermore, in one port can be a > multifunction device, acting for example as both a keyboard and a mouse, > being seen as two different devices from userspace. In my model this is seen as two driver instances using the same physical device. > Note that all the strings won't change when the init order is different, > when you add other cards, etc. Also note that the strings match exactly > the arrangement of driver layers (not the drivers themselves) in the > kernel. > ... > This is why I have split the location and unique ID, because in my > approach the location string (PHYS) can be of arbitrary lengthm because > it's a tree path, it'd need another separator in addition to slash to > add the unique ID at the end of it. Hmm.. looks very good. I'm not sure yet whether I like the idea of having two or three IDs. PHYS is certainly superior to my approach (now that I understood the format :), but I have to think of how to implement this. PRODUCT should IMHO have the format "/" because you cannot assume that every bus has idvendor and idproduct. > > numbers is empty it is still possible that the devices are the same. This > > is because the serial number is sometimes set by the device driver (like > > in pci ethernet drivers). If the driver was not loaded when the device id > > has been created then the serial number is empty. > Ugh? Which PCI ethernet drivers create the serial? All ethernet cards > are REQUIRED to have an SAPROM in them and that makes them all unique, > without that ethernet wouldn't work. The serial number from the card is used to set the device id serial number using devreg's API. The device is added by the bus driver using device_register(). Later the device driver can change/set the serial number using device_set_serialnumber(). However, when the driver is not loaded it cannot provide a serial number, so it is possible that the serial number is missing. > I think you misundrestood the PHYS meaning then - it has no relation to > the /dev hierarchy, it really only describes the true physical location > of the device as seen by the kernel. I misunderstood the "input0" in your example. It's role more like my and combined, only that it is device-centric and not driver-centric. > > Devreg exports the relations between drivers so you > > can easily find out which device driver instance uses which "input" > > instance. is the device id of the physical device > > This is useful. Where do you get the info from? Each driver has to register itself and all instances (in other words: has to be patched). /dev nodes are connected to the graph using a new devfs_register function. The objects (driver instances, devices) are internally identified using void pointers that can be freely defined per driver or bus. For example the input layer uses struct input_dev pointers as key for driver instances and PCI uses struct pci_dev pointers for PCI devices. > > is the driver id of the driver that created the node (not the > > driver that handles the device). So in your case it would be "input", not > > "hid" for a USB device. > It'd most likely be evdev, or mousedev, or whatever. Input doesn't > create any devices, it just manages another (virtual) bus of devices, > much like the usbcore driver does. Actually I use "input" in my port because it calls devfs_register() (in input_register_minor()). Input is then connected directly to the driver that calls input_register_device(). Evdev and mousedev don't appear as separate drivers. bye... _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel