On Monday 07 March 2005 1:48 pm, David Hollis wrote: > On Mon, 2005-03-07 at 11:26 -0800, David Brownell wrote:
> > > How about Jamie's use of the kevent to take care of the > > > link/speed negotiation bits? > > > > You mean, as found in his usbnet-ax8817x-medium-mode-take2.patch? > > I see that uses the bit 3 flag for a different purpose ... :) > > > > That'd be a different mechanism. I didn't see anything wrong > > with such a mechanism on first read, but I didn't have time to > > give it a serious review and notice more than the fact that it > > was specific to the ASIX support. > > > > It was only used by ASIX, but it seemed to be written in a manner that > other drivers could make use of. It may be designed slightly ASIX > specific however in that the reset() method gets called in defer_kevent > if the LINK_RESET bit is set. Maybe it would be more flexible to add a > link_reset() method to struct usbnet. Sounds reasonable to me, and likely to make sense for other minidrivers too. Though it'd be good to be clear what's meant by "link", and how that relates to MII (or doesn't). Presumably some drivers would make a "reset" actually reset the device, others might just toggle the altsetting, and so on. > > > Would it still be legit to use that > > > (changing the kevent flag accordingly of course) for the various ways we > > > need to handle that with the three different ASIX devices? > > > > I think what I'd like to see is a generalized mechanism that just > > lets the minidrivers say "call my function in (work) task context". > > Probably with some mechanism to cache minidriver-specific parameters > > for the call. A generic KEVENT_MINIDRIVER might suffice, plus maybe > > another word or two of minidriver-specific state. > > > > > > As you know, my not-so-secret plan is to see the usbnet core mature > > enough that minidrivers (like CDC Ethernet and ASIX) can split out > > into separate files, like usb-serial ... and so that potentially > > that infrastructure can be reused by other usb networking drivers. > > > > Doing that certainly seems to require having a good reusable solution > > for operations that need task contexts ... control requests to poll > > link status, and so on. In fact, given this status polling stuff, > > that's about the last technical issue I know of other than not yet > > having the serial-style modularization. > > > On those lines, I did some experimentation with splitting out the ASIX > support. I was pondering two different avenues: > 1) Separate source file but they compile into one monolithic usbnet > 2) separate source file, and separate module with usbnet being a > dependency, like video devices needing the videodev module. > > I found that option 2 seemed to offer more bang for the buck. Separating > into separate source files made for smaller files, but made a lot of > other things a PITA (handling the USB_DEVICE structures, etc etc). That's what I've been wanting. Shrinking the size of that source file so that most of it is in separate per-minidriver files will ease the maintainers' jobs a bit. Shrinking the object file size is a win for whoever worries about the ever-increasing sizes of kernels. (That is, most folk who aren't selling memory chips... :) And it should let the Kconfig stuff look more normal too. > To make usbnet more like a mini-driver, I only had to do a few things. > I made a few functions non-static, renamed a few to have a usbnet_ > prefix since they were now non-static (get_endpoints -> > usbnet_get_endpoints) and that was about it. For the ASIX part, I just > used the usbnet_probe as my probe routine and everything worked fine. Seemed like that should be about it. Also provide a "usbnet.h" header with those declarations, and export the functions. Worth eyeballing the usb-serial stuff to make sure all bases are covered. (And maybe Greg knows a few things to watch out for, stuff he'd change if he somehow acquired a large supply of spare time for Linux!) > Seems that such an approach may be useful for embedded type folks since > they can have the ASIX modules built, but not put them in their image if > they don't need and and want to save space, etc. With hotplug and > friends, everything still gets picked up the same way so an end user > doesn't even notice. Exactly. Sounds like you have most of a patch ready ... feel like sending it around, splitting the ASIX stuff out to a separate module? That is, after Greg merges that polling patch (and the other pending patches). Once those interfaces are ready, I'll split out some of the other minidrivers. - Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
