On Tue, Nov 08, 2011 at 04:33:22PM +0200, Felipe Balbi wrote: > All in all, except for a few comments I had, the series is ok. But I > truly don't see the big benefit we have out of this. You're just > renaming a bunch of structures, enumerations and functions without a > real reason behind it. > > What we need in the long run, like I had told you back in Nokia, is to > be able to compile several transceiver drivers into the same zImage or > as dynamically loadable modules and still have it working somehow. Which > means that we need a way for a Link (dwc3, musb, omap_udc, renesas_udc, > etc) to request a transceiver, or that transceiver has to be assigned to > a link as a resource. > > Also keep in mind that on USB3 device controllers, we will have at least > two PHYs: one which will be handling USB2 signalling and another which > will be handling USB3 signalling. > > I say "at least" because OMAP boards generally have split PHY > functionality between internal (into the SoC) entities and an external > PMIC. If you take OMAP4, for example, we have an internal IP handling > the data parts and communicating VBUS/ID levels to MUSB while the > actual VBUS/ID comparators are inside the PMIC. > > With this series of yours I don't see any way we could easily model this > split PHY functionality. > > Some OEMs might also decide to ditch completely the internal and PMIC > PHY functionality in exchange for their own solution of an all-in-one > PHY (e.g. N900). > > So all of that is still a pain in the ass to get sorted out and your > series isn't helping at all towards that goal so I can't see the real > benefit in accepting these patches other than having better matching > structure names. > > You didn't even cleanup the <linux/usb/otg.h> header. There's a bunch of > stuff in there which isn't OTG-related at all and you seem to not have > cared too much about it. > > At the end of the day we need to solve the problems we have and make the > Embedded part of the USB suport on linux (mainly the gadget framework > and OTG support) as easy as possible to generate a product out of it. > > If you remember the amount of patches we had to get N900 sorted out, you > know what I'm talking about. To prevent our users from ever rebasing > their own hacks on their internal trees, we need to provide solutions > which are flexible enough to have boards with USB2-only, USB3, > Host-only, device-only, OTG, with and without USB Battery Charging. > > As of now we can't. > > I hope you have some other patches/ideas behind this series, otherwise > there's not enough reason to merge it. > > I suggest you start laying down your ideas and, where possible, code so > we can come up with a solution to help everybody. To me there are several things that need to be addressed in Linux USB OTG and Gadget architecture. Having support for multiple transceivers is one of them, but I'm after clear cut between OTG and PHY first. I got the idea of doing it like this when you said: "I would start by splitting <linux/usb/otg.h> into things which are really otg specific and things are only related to transceivers...": http://www.spinics.net/lists/linux-usb/msg50152.html I know you had more in mind, but it felt like the right thing to do. The changes are quite minor like you said, but they affect many drivers. It's only the first step but it is enough to introduce the basic structures. I'm hoping we could at least avoid any new "langwell_otg" driver that mix controller and transceiver control into one driver, making them impossible to maintain. The idea was indeed to add support for multiple PHYs, but only after this. -- heikki -- 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
