On Fri, 11 Mar 2011, Andy Green wrote: > I don't believe I referred to class devices anywhere. It does not > matter if the main chip function is class device or not. It matters because the class specification for a USB device is never going to mention information sources that are outside the USB protocol, such as board definitions. Consequently a class driver will never need to use such a thing. > If there is any kind of "functional implementation" knowledge that is > outside the chip and driver itself, it has to be held somewhere, and > applied appropriately. platform_data from the board definition file is > the established place for that knowledge that is specific to a board. Since essentially all of the USB drivers currently in the kernel _are_ class drivers (at least, I'm not aware of any non-trivial exceptions), this means none of the existing USB drivers should need to access any platform data. Of course, this doesn't rule out the possibility of platform-specific USB drivers that _do_ need this information. > > Also, do you have a real example of a USB driver today that needs this? > > I think you find without devpath -> platform_data mapping, the kind of > layout given above is made quite difficult to support in Linux. What would be needed to support such a mapping? It seems to me that we probably have all the necessary ingredients in place already. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
