Hi, On Thu, Jan 16, 2014 at 01:58:30PM +0100, Carmelo Amoroso wrote: > I'm one of the maintainer of the STLinux kernel @ST. > Let me clarify the inconvenience occurred about this patches. > > We are back-porting some patches from upstream for DWC3 driver into > our 3.4.58 based kernel as our chipsets use this host controller. right, that's ok. Would be nice to see your glue layer hitting upstream, though. > The way we do it, is exactly what you referred to, by using 'git > cherry-pick -xs' to keep authorship, upstream reference and so on, > and when cherry-pick is not straightforward, we are used to specify > what are the modification added by us wrt the upstream patch. git cherry-pick would give a merge conflict, in which case you would just solve it. In any case, if you cherry-pick every patch, you would never have conflicts to solve, just the usual API change which is usually very simple to sort out. > You might have a look at some recent backport stuff we did for our > 3.4 kernel: > > http://git.stlinux.com/?p=stm/linux-stm.git;a=commit;h=cef7a3a85413142e73315463eae2fedea451490e > > http://git.stlinux.com/?p=stm/linux-stm.git;a=commit;h=71538603d521a6e1b5d5b4ad47c77e6f9dfc8882 > > (feel free to browse our git.stlinux.com) just did, you guys have a few things to sort out on your glue layer: a) PHY shouldn't be directly accessed by the glue layer, just add a PHY driver and you get all of that for free. b) you shouldn't access DWC3_GSBUSCFG0 outside of core.c. The right way to handle that, would be to either pass a quirk flag, or figure out a detect that the underlying AXI needs this particular configuration. One thing though, why wasn't that bit set properly during coreConsultant configuration ? c) you should be using devm_ioremap_resource() instead of devm_request_and_ioremap() d) that xhci_hub_on_disconnect() is nasty > You will see authorship not changed, properly upstream commit > reference and so on. > > Regarding the merged patches sent by the colleague Giuseppe, I asked > him to provide me an unique patch just to check locally if the issue > were actually fixed. It should have been a private, temporary hack > for testing. I see. > It was not meant to be applied in the kernel, neither he had the > intention to change authorship. > > Due to bad git configuration (and user mistakes), when he sent the > patch it went to our devel-list plus you as in the signed-off list, > but purely by mistake (--suppress-xxx neither passed) > > As kernel maintainer, I can guarantee such a work will not included > at all in our kernel. It has been just due to user mistakes. > > We seriously consider copyright laws. > > Our apologies for such inconvenience. apologies accepted, thanks for clarifying so quickly. Hope to see your glue layer in mainline soon, believe me, it'll make your life a lot easier in the long run. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
