Hi, On Fri, Oct 02, 2015 at 07:16:05PM +0000, John Youn wrote: > >>>> From now, any check based on a revision (for STARS, workarounds, and > >>>> new features) should take into consideration how it applies to both > >>>> the 3.1/3.0 IP and make the check accordingly. > >>>> > >>>> Cc: <stable@xxxxxxxxxxxxxxx> # v3.18+ > >>> > >>> I really fail to how any of these patches in this series apply for stable. Care > >>> to explain ? > >> > >> We have some prototyping products that are stuck on 3.18 stable > >> kernels and will continue to ship with that for some time. We'd > >> like to run the USB 3.1 controller on those platforms. Without > >> these version id and version number updates dwc3 will not work > >> with the USB 3.1 IP. > >> > >> I think the plan is to update those platforms to 4.2 eventually. > >> So even then it will still need this patch. > >> > >> Also it will help out any customers stuck on earlier kernels. > >> > >> How would you advise we handle this, with the version id and > >> number changes? > > > > I have a feeling the answer to that will be that you will need to backport your > > own patches :-( Or upgrade to the latest kernel around once your patches get > > merged. > > > > Would you care to explain why upgrading the kernel is so complex for this > > prototyping solution ? I suppose you're not using HAPS as a PCIe card on a > > common desktop PC, then ? > > I don't know the technical reasons why. One platform is ARM based > and using the 3.18 Linaro stable kernel. Another uses our ARC > platform which is also on 3.18. > > We're trying to avoid the situation where where we have to ship > patches or maintain a separate kernel tree. > > Do you have any objections to these going into stable? I'm not the one you need to convince. That would be Greg :-) -- balbi
Attachment:
signature.asc
Description: PGP signature