Messages in this thread | | | Date | Mon, 25 Mar 2002 15:27:16 -0500 | From | christophe barbé <> | Subject | Re: [PATCH] 3c59x and resume |
| |
On Mon, Mar 25, 2002 at 11:11:27AM -0800, Greg KH wrote: > On Mon, Mar 25, 2002 at 01:19:56PM -0500, christophe barbé wrote: > > > > Ok I understand that but hotplug has no way to influence the way the > > device is treated by the driver. The only way I can see is via the /proc > > interface, but at least it is not possible with this driver. > > Not true. The link I pointed to changes the way the "ethX" names are > assigned to the device based on MAC addresses. So that's just one way > to influence the way a device is treated by a driver. > > > > > > > The problem here is not to give the same interface to a given NIC. The > > > > problem is to give the same options to a given NIC. But a solution can > > > > simply be to set the option from hotplug using the proc interface. The > > > > 3c59x doesn't support that for wol but that can be changed. > > > > > > Understood. > > > > So do you agree that something is missing here ? > > Yes I do. See below for more. > > > > > > And why is there a limitation of only 8 devices? Why not do what all > > > > > USB drivers do, and just create the structure that you need to use at > > > > > probe() time, and destroy it at remove() time? > > > > > > > > This is an implementation issue which is not really important. It comes > > > > from Donald Becker. Your dynamic structure doesn't solve the problem > > > > 'which options for which cards', does it ? > > > > > > No, but it solves the problem, "only 8 devices max", and "what to do > > > when a card is removed and then plugged back in." Both seems like good > > > things to fix in the driver :) > > > > I have not checked the module loading code but is it possible to define > > for an option a vector with an undefined size ? Or do you consider that > > all devices use the same option ? (the vortex driver is only limited to > > 8 cards for the options passed by modutils) > > Ok, in looking more at the 3c59x driver's module parameters, I see your > main problem. You are relying on module wide options to effect > different cards in a system. And these different cards could need > different options, right?
Yes. I don't have this problem. I am a mobile user of this driver (hotplug and power-management) and the driver was done with other things in mind. The good thing is that both views seems to converge today. I am looking for a clean fix. As I see it, the vector of options is a mistake. We should be able to give a default value for an option with modutils but for more complicate configuration a userland tool should be able to decide the correct options for a given device. This is a generalisation to what hotplug does.
> If so, yes this is a problem as you have outlined. Might I suggest a > driverfs entry for the device? That way every point in the device tree > could have those options be unique for the different device? This could > also be done like you said above, with a /proc entry (but we are moving > away from /proc entries, remember? :)
Yes I remember even if I am not yet convinced.
> Then when /sbin/hotplug is run when your network device is brought up, > it could find the driverfs entry for your device and initialize it with > the proper options (full_duplex, hw_checksums, etc.) > > > Could you point me to a specific usb driver ? > > In the drivers/usb directory, the following are network drivers: > CDCEther.c > catc.c > kaweth.c > pegasus.c > usbnet.c
I will have a look. Thanks.
> > How is solved the "what to do when a card is removed and then plugged > > back in." problem ? By keeping the entry for further use ? > > No, all of the information is deleted when a device is removed. When a > device is inserted again, a structure is created again. They do not > remember information about the device across removals.
So this particular problem is not solved in the usb drivers ?
Christophe
> Hope this helps, > > greg k-h > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
-- Christophe Barbé <christophe.barbe@ufies.org> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann [unhandled content-type:application/pgp-signature] | |