| Message ID | 20200915213039.862123-1-jlvillal@os.amperecomputing.com |
|---|---|
| Headers | show |
| Series | Add support needed for Renesas USB 3.0 controller | expand |
On Tue, Sep 15, 2020 at 02:30:34PM -0700, John L. Villalovos wrote: > Add support needed for the Renesas USB 3.0 controller > (PD720201/PD720202). Without these patches a system with this USB > controller will crash during boot. Is this a regression, or something that has always happened? If a regression, any pointers to what commit caused this? this really feels like a "new feature" addition to me, unless this used to work properly. thanks, greg k-h
On 9/15/2020 11:31 PM, Greg KH wrote: > On Tue, Sep 15, 2020 at 02:30:34PM -0700, John L. Villalovos wrote: >> Add support needed for the Renesas USB 3.0 controller >> (PD720201/PD720202). Without these patches a system with this USB >> controller will crash during boot. > Is this a regression, or something that has always happened? If a > regression, any pointers to what commit caused this? > > this really feels like a "new feature" addition to me, unless this used > to work properly. It is not a regression. It is a crash that occurs on new hardware that has this USB controller. Without this patch series, hardware with this USB controller will fail to work. So in the choice between "regression" and "new feature" I would say "new feature". Thanks, John
On Wed, Sep 16, 2020 at 09:54:50AM -0700, John Villalovos wrote: > > On 9/15/2020 11:31 PM, Greg KH wrote: > > On Tue, Sep 15, 2020 at 02:30:34PM -0700, John L. Villalovos wrote: > > > Add support needed for the Renesas USB 3.0 controller > > > (PD720201/PD720202). Without these patches a system with this USB > > > controller will crash during boot. > > Is this a regression, or something that has always happened? If a > > regression, any pointers to what commit caused this? > > > > this really feels like a "new feature" addition to me, unless this used > > to work properly. > > It is not a regression. It is a crash that occurs on new hardware that has > this USB controller. > > > Without this patch series, hardware with this USB controller will fail to > work. So in the choice between "regression" and "new feature" I would say > "new feature". Ok, to support new hardware, use a newer kernel, no reason why 5.4 or newer will not work here, right? thanks, greg k-h
On 9/16/2020 10:08 AM, Greg KH wrote: > On Wed, Sep 16, 2020 at 09:54:50AM -0700, John Villalovos wrote: >> >> On 9/15/2020 11:31 PM, Greg KH wrote: >>> On Tue, Sep 15, 2020 at 02:30:34PM -0700, John L. Villalovos wrote: >>>> Add support needed for the Renesas USB 3.0 controller >>>> (PD720201/PD720202). Without these patches a system with this USB >>>> controller will crash during boot. >>> Is this a regression, or something that has always happened? If a >>> regression, any pointers to what commit caused this? >>> >>> this really feels like a "new feature" addition to me, unless this used >>> to work properly. >> >> It is not a regression. It is a crash that occurs on new hardware that has >> this USB controller. >> >> >> Without this patch series, hardware with this USB controller will fail to >> work. So in the choice between "regression" and "new feature" I would say >> "new feature". > > Ok, to support new hardware, use a newer kernel, no reason why 5.4 or > newer will not work here, right? This is true, but some customers who want to use this hardware don't want (refuse) to use a new kernel :( Can I take this to mean that this patch series is not allowed to go into the stable kernel? Thanks, John
On Wed, Sep 16, 2020 at 10:15:12AM -0700, John Villalovos wrote: > On 9/16/2020 10:08 AM, Greg KH wrote: > > On Wed, Sep 16, 2020 at 09:54:50AM -0700, John Villalovos wrote: > > > > > > On 9/15/2020 11:31 PM, Greg KH wrote: > > > > On Tue, Sep 15, 2020 at 02:30:34PM -0700, John L. Villalovos wrote: > > > > > Add support needed for the Renesas USB 3.0 controller > > > > > (PD720201/PD720202). Without these patches a system with this USB > > > > > controller will crash during boot. > > > > Is this a regression, or something that has always happened? If a > > > > regression, any pointers to what commit caused this? > > > > > > > > this really feels like a "new feature" addition to me, unless this used > > > > to work properly. > > > > > > It is not a regression. It is a crash that occurs on new hardware that has > > > this USB controller. > > > > > > > > > Without this patch series, hardware with this USB controller will fail to > > > work. So in the choice between "regression" and "new feature" I would say > > > "new feature". > > > > Ok, to support new hardware, use a newer kernel, no reason why 5.4 or > > newer will not work here, right? > > This is true, but some customers who want to use this hardware don't want > (refuse) to use a new kernel :( That's crazy, 4.19 should NOT be used for any system that requires new hardware. You all have read my "what kernel should I pick" guide, right? > Can I take this to mean that this patch series is not allowed to go into the > stable kernel? That is correct. Use a newer kernel, it's much better overall. Only reason you should be stuck on 4.19 at this point in time is if you have an SoC with millions of out-of-tree lines added to it (making a Linux-like system), or you are an "enterprise" distro and you are paying for support for them. Or you are using Debian, they know what they are doing there :) thanks, greg k-h
Add support needed for the Renesas USB 3.0 controller (PD720201/PD720202). Without these patches a system with this USB controller will crash during boot. This patch series backports the following upstream patches: 01: da83a722959a82733c3ca60030cc364ca2318c5a lib/genalloc: add gen_pool_dma_zalloc() for zeroed DMA allocations 02: b0310c2f09bbe8aebefb97ed67949a3a7092aca6 USB: use genalloc for USB HCs with local memory 03: 2d7a3dc3e24f43504b1f25eae8195e600f4cce8b USB: drop HCD_LOCAL_MEM flag 04: dd3ecf17ba70a70d2c9ef9ba725281b84f8eef12 usb: don't create dma pools for HCDs with a localmem_pool 05: edfbcb321faf07ca970e4191abe061deeb7d3788 usb: add a hcd_uses_dma helper Signed-off-by: John L. Villalovos <jlvillal@os.amperecomputing.com>