On Mon, 2005-03-07 at 11:26 -0800, David Brownell wrote: > On Monday 07 March 2005 9:47 am, David Hollis wrote: > > > > It seems that I can re-factor the ax8817x code to make use of this > > instead of manually creating/handling the INT URB to reduce the > > duplicity eh? > > I'd sure hope so! Ideally, without needing to tweak any of > the infrastructure; but if it's needed, we'd work that out. > > On a cursory glance, I think it should work just fine. And as a bonus it frees up a few bytes in the ax8817x_data structure that can be used for other purposes.
> > 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. > > > 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). 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. 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.
signature.asc
Description: This is a digitally signed message part
