On 1/17/2014 3:43 AM, Felipe Balbi wrote:
Hi,
Hello Felipe,
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.
we are working on 3.12 kernel indeed as well for upstream.
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.
yes, right.
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:
for sure
a) PHY shouldn't be directly accessed by the glue layer, just add a PHY
driver and you get all of that for free.
we are not relying upon the USB_PHY driver in 3.4 (we have it in 3.10)
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.
thanks for the hint
One thing though, why wasn't that bit set
properly during coreConsultant configuration ?
Frankly I don't know.
c) you should be using devm_ioremap_resource() instead of
devm_request_and_ioremap()
ok
d) that xhci_hub_on_disconnect() is nasty
yes, I know. We had to manage under a big pressure and with a short time
such feature and the fastest way was to implement it and use 'weak'
symbol. I know it will not work if some other xhci controllers would
require it.
This is why we are maintaining it internally and not posted for
upstream. A proper and clean design should come later. For sure, I'd
like to post to the community.
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 to you
thanks for clarifying so quickly.
it was our duty
Hope to see your glue layer in mainline soon, believe me, it'll make
your life a lot easier in the long run.
I do fully agree.
cheers
cheers,
Carmelo
--
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
