Hi, On 4/27/2015 4:49 PM, Felipe Balbi wrote: > Hi, > > On Mon, Apr 27, 2015 at 04:04:08PM +0100, Joao Pinto wrote: >> Hi Filipe, > > that's Felipe (and yes, I know it's João, but you spelled it without ~) > > :-) > >> On 4/27/2015 3:56 PM, Felipe Balbi wrote: >>> Hi Joao, >>> >>> On Mon, Apr 27, 2015 at 03:48:48PM +0100, Joao Pinto wrote: >>>>>> My name is Joao Pinto and I am working at Synopsys as a Software Engineer mainly >>>>>> in the USB Subsystem. >>>>>> >>>>>> I am sending you this email in order to know if someone is already working in >>>>>> the driver' development for Synopsys' USB 3.1 Host & Device and USB 2.0 OTG >>>>>> Controllers. >>>>> >>>>> Have you looked at the latest kernel tree to verify what is and is not >>>>> supported? That's your best source of information. >>>> >>>> I checked the USB Mailing List archive and the USB Git trees in order to find >>>> any reference of these drivers but nothing was found, so I would conclude that >>>> nothing was submitted about these 2 subjects. >>> >>> one of your colleagues maintains dwc2 which is the synopsys usb 2.0 otg >>> controller available on e.g. raspberry pi. >>> >>> For USB 3.1, nobody outside of synopsys (afaict) has access to any HW or >>> FPGA with USB 3.1, so there isn't much we can do without HW :-) In fact, >>> I don't know anybody, except for synopsys employees, with access to the >>> USB 3.1 documentation, but I would assume the core to be similar to the >>> current DWC USB3 (drivers/usb/dwc3) IP whose driver I maintain (please >>> confirm). >>> >>> If that's the case, then an incremental patch adding USB 3.1 support is >>> much more desirable than an entire new driver. >>> >>>>>> a) If no one is working, we have interest to start developing them >>>>> >>>>> Don't you already have internal code for these chips? Have you tested >>>>> Linux with them? >>>> >>>> As you know internal code is not always suitable for kernel submission >>>> and so sometimes it is better to upgrade a std kernel driver like dwc3 >>>> (USB 3.0 Device) in order to make it support 3.1 as well. >>> >>> yes, it's better to upgrade that driver, however, that driver is not >>> device only. I won't repeat myself trying to explain why we still don't >>> have DRD/OTG support, but it's coming. >>> >>>>>> b) If there is someone already developing them, we have interest in >>>>>> collaborating with the on going work >>>>> >>>>> Look at the changelog entries for the drivers for these chips, that >>>>> should give you the information you need here. >>>> >>>> I have checked the USB tree' logs as I said previously and nothing relevant was >>>> found. >>>> >>>>> >>>>> But really, running the latest kernel and seeing what doesn't work for >>>>> your hardware, and sending patches to fix this is the best way forward, >>>>> don't you agree? >>>> >>>> I agree with you if we are dealing with small improvements or bug fixes, but in >>>> this case we are dealing with new drivers or important updates on existing ones. >>> >>> I would assume that USB 3.1 itself is a very small change. The bulk of >>> the changes will probably come due to Type-C connector and USB Power >>> Delivery and Billboard classes, however, that's not coupled with USB 3.1 >>> at all. >>> >>>> One of the good practices I read about kernel development is to ask >>>> first if someone is already working in a particular subject to avoid >>>> work duplication and that's what I am doing in this email. >>> >>> that's correct, it's always good to ask and doesn't really hurt anybody, >>> but you also need to know who to ask :-) Greg can't know about >>> everything (although usually... well), and since you're talking about >>> changes to dwc2 and dwc3 it would be nice to Cc the maintainers for >>> those drivers, right ? ;-) >>> >>> cheers >>> >> >> Thank you very much for your inputs! When I have more details I will >> contact you about dwc3. Have a nice day! > > you too, thanks > Sorry Filipe, in Portugal we have the two ways: Felipe and Filipe! Cheers, Joao -- 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
