| Message ID | 20240611125057.1232873-1-yoshihiro.shimoda.uh@renesas.com |
|---|---|
| Headers | show |
| Series | PCI: rcar-gen4: Add R-Car V4H support | expand |
Hello, > The pcie-rcar-gen4 driver can reuse other R-Car Gen4 support like > r8a779g0 (R-Car V4H) and r8a779h0 (R-Car V4M). However, some > initializing settings differ between R-Car S4-8 (r8a779f0) and > others. The R-Car S4-8 will be minority about the setting way. So, > R-Car V4H will be majority and this is generic initialization way > as "renesas,rcar-gen4-pcie{-ep}" compatible. Applied to controller/rcar-gen4, thank you! [01/04] PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros https://git.kernel.org/pci/pci/c/544a18c936f9 [02/04] PCI: rcar-gen4: Add struct rcar_gen4_pcie_drvdata https://git.kernel.org/pci/pci/c/ac1d89f8dcc3 [03/04] PCI: rcar-gen4: Add .ltssm_control() for other SoC support https://git.kernel.org/pci/pci/c/2c49151b3fff [04/04] PCI: rcar-gen4: Add support for R-Car V4H https://git.kernel.org/pci/pci/c/60ad25bcac1d Krzysztof
Hello, [...] > About the firmware binary, please refer to the following patch > descirption: > PCI: rcar-gen4: Add support for r8a779g0 This quite a sad state of affairs, and usually would I oppose including drivers that rely on closed proprietary firmware blobs to operate. That said, Renesas is not really setting any precedent here, so we will live with this. Shimoda-san, if you can, please pass the feedback to your bosses that this decision to keep the firmware closed is rather unfortunate. Krzysztof
On Sun, Jun 30, 2024 at 05:06:50AM +0900, Krzysztof Wilczyński wrote: > Hello, > > [...] > > About the firmware binary, please refer to the following patch > > descirption: > > PCI: rcar-gen4: Add support for r8a779g0 > > This quite a sad state of affairs, and usually would I oppose including > drivers that rely on closed proprietary firmware blobs to operate. That > said, Renesas is not really setting any precedent here, so we will live > with this. What are the existing similar situations? Just for curiosity, I'd like to know what precedent we are relying on here.
Hello Krzysztof-san, > From: Krzysztof Wilczyński, Sent: Sunday, June 30, 2024 5:07 AM > > Hello, > > [...] > > About the firmware binary, please refer to the following patch > > descirption: > > PCI: rcar-gen4: Add support for r8a779g0 > > This quite a sad state of affairs, and usually would I oppose including > drivers that rely on closed proprietary firmware blobs to operate. That > said, Renesas is not really setting any precedent here, so we will live > with this. > > Shimoda-san, if you can, please pass the feedback to your bosses that this > decision to keep the firmware closed is rather unfortunate. I got it. I'll try it. Best regards, Yoshihiro Shimoda > Krzysztof
Hello Bjorn, > From: Bjorn Helgaas, Sent: Sunday, June 30, 2024 5:46 AM > > On Sun, Jun 30, 2024 at 05:06:50AM +0900, Krzysztof Wilczyński wrote: > > Hello, > > > > [...] > > > About the firmware binary, please refer to the following patch > > > descirption: > > > PCI: rcar-gen4: Add support for r8a779g0 > > > > This quite a sad state of affairs, and usually would I oppose including > > drivers that rely on closed proprietary firmware blobs to operate. That > > said, Renesas is not really setting any precedent here, so we will live > > with this. > > What are the existing similar situations? Just for curiosity, I'd > like to know what precedent we are relying on here. Wolfram mentioned it on previous email thread [1]. [1] https://lore.kernel.org/linux-pci/53sfkav45djcaapqkzsps6ofsinf5lnxbhrjvgsevt3w6qcms6@e2vptwrj645q/ Best regards, Yoshihiro Shimoda
Hello, [...] > > > [...] > > > > About the firmware binary, please refer to the following patch > > > > descirption: > > > > PCI: rcar-gen4: Add support for r8a779g0 > > > > > > This quite a sad state of affairs, and usually would I oppose including > > > drivers that rely on closed proprietary firmware blobs to operate. That > > > said, Renesas is not really setting any precedent here, so we will live > > > with this. > > > > What are the existing similar situations? Just for curiosity, I'd > > like to know what precedent we are relying on here. > > Wolfram mentioned it on previous email thread [1]. > > [1] > https://lore.kernel.org/linux-pci/53sfkav45djcaapqkzsps6ofsinf5lnxbhrjvgsevt3w6qcms6@e2vptwrj645q/ Another example could be the Marvell's (formerly Aquantia) "Atlantic" network cards family, which requires a custom firmware blob that wasn't readily or freely distributed. The firmware files were never added to the linux-firmware repository. ... unless things have changes since I looked some time ago. Krzysztof
The pcie-rcar-gen4 driver can reuse other R-Car Gen4 support like r8a779g0 (R-Car V4H) and r8a779h0 (R-Car V4M). However, some initializing settings differ between R-Car S4-8 (r8a779f0) and others. The R-Car S4-8 will be minority about the setting way. So, R-Car V4H will be majority and this is generic initialization way as "renesas,rcar-gen4-pcie{-ep}" compatible. About the firmware binary, please refer to the following patch descirption: PCI: rcar-gen4: Add support for r8a779g0 For now, I tested both R-Car S4-8 and R-Car V4H on this driver. I'll support one more other SoC (R-Car V4M) in the future. Changes from v8: https://lore.kernel.org/linux-pci/20240520074300.125969-1-yoshihiro.shimoda.uh@renesas.com/ - Add Reviewed-by in the patch 3/5. - Revise commit description in the patch [2345]/5. - Some minor updates of the code in the patch 4/5. Changes from v7: https://lore.kernel.org/linux-pci/20240415081135.3814373-1-yoshihiro.shimoda.uh@renesas.com/ - Since the following patches are merged into pci.git / dt-bindings branch, drop them from this patch series: dt-bindings: PCI: rcar-gen4-pci-host: Add R-Car V4H compatible dt-bindings: PCI: rcar-gen4-pci-ep: Add R-Car V4H compatible - Add Reviewed-by in the patch [25]/5. - Add a condition to avoid automated tools report in the patch 2/5. - Change the new function which adds an "enable" flag in the patch 3/5. So, change the commit description and move some functions' places. - Revise the commit description and add firmware information in detail in the patch 4/5. - Use the offset directly instead of definitions in the patch 4/5. - Add comments for some magical offsets/values in the patch 4/5. - Change error message when request_firmware() failed in the patch 4/5. Changes from v6: https://lore.kernel.org/linux-pci/20240410004832.3726922-1-yoshihiro.shimoda.uh@renesas.com/ - Add Manivannan's Reviewed-by in patch [37]/7. - Rename a struct from "platdata" to "drvdata" in patch [4/7]. - Revise the commit descriptions in patch [456]/7. - Rename some functions in patch 6/7. - Fix the return value of an error path in patch 6/7. Yoshihiro Shimoda (5): PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros PCI: rcar-gen4: Add rcar_gen4_pcie_drvdata PCI: rcar-gen4: Add .ltssm_control() for other SoC support PCI: rcar-gen4: Add support for r8a779g0 misc: pci_endpoint_test: Document a policy about adding pci_device_id drivers/misc/pci_endpoint_test.c | 4 + drivers/pci/controller/dwc/pcie-designware.h | 6 + drivers/pci/controller/dwc/pcie-rcar-gen4.c | 313 +++++++++++++++++-- 3 files changed, 289 insertions(+), 34 deletions(-)