| Message ID | 20220921084745.3355107-1-yoshihiro.shimoda.uh@renesas.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | treewide: Add R-Car S4-8 Ethernet Switch support | expand |
On Wed, 21 Sep 2022 17:47:37 +0900 Yoshihiro Shimoda wrote:
> Subject: [PATCH v2 0/8] treewide: Add R-Car S4-8 Ethernet Switch support
I think you may be slightly confused about the use of the treewide
prefix. Perhaps Geert or one of the upstream-savvy contractors could
help you navigate targeting the correct trees?
Hi Jakub, Thank you for your comment! > From: Jakub Kicinski, Sent: Wednesday, September 21, 2022 11:40 PM > > On Wed, 21 Sep 2022 17:47:37 +0900 Yoshihiro Shimoda wrote: > > Subject: [PATCH v2 0/8] treewide: Add R-Car S4-8 Ethernet Switch support > > I think you may be slightly confused about the use of the treewide > prefix. Perhaps Geert or one of the upstream-savvy contractors could > help you navigate targeting the correct trees? I thought we have 2 types about the use of the treewide: 1) Completely depends on multiple subsystems and/or change multiple subsystems in a patch. 2) Convenient for review. This patch series type is the 2) above. However, should I use treewide for the 1) only? Best regards, Yoshihiro Shimoda
On Thu, 22 Sep 2022 00:46:34 +0000 Yoshihiro Shimoda wrote: > I thought we have 2 types about the use of the treewide: > 1) Completely depends on multiple subsystems and/or > change multiple subsystems in a patch. > 2) Convenient for review. > > This patch series type is the 2) above. However, should I use > treewide for the 1) only? I thought "treewide" means you're changing something across the tree. If you want to get a new platform reviewed I'd just post the patches as RFC without any prefix in the subject. But I could be wrong. My main point (which I did a pretty poor job of actually making) was that for the networking driver to be merged it needs to get posted separately.
On Wed, Sep 21, 2022 at 06:06:40PM -0700, Jakub Kicinski wrote: > On Thu, 22 Sep 2022 00:46:34 +0000 Yoshihiro Shimoda wrote: > > I thought we have 2 types about the use of the treewide: > > 1) Completely depends on multiple subsystems and/or > > change multiple subsystems in a patch. > > 2) Convenient for review. > > > > This patch series type is the 2) above. However, should I use > > treewide for the 1) only? > > I thought "treewide" means you're changing something across the tree. > If you want to get a new platform reviewed I'd just post the patches > as RFC without any prefix in the subject. But I could be wrong. > > My main point (which I did a pretty poor job of actually making) > was that for the networking driver to be merged it needs to get > posted separately. Expanding on that... You have a clock patch, which should go via the clock subsystem Maintainer. You have a PHY path, which should go via the generic PHY subsystem Maintainer. You have an Ethernet driver and binding patch, which can go via netdev, Cc: the device tree list. And a patch to add the needed nodes to .dts files which can go via the renesas Maintainer. At an early RFC stage, posting them all at once can be useful, to help see all the bits and pieces. But by the time you have code ready for merging, it should really go via easu subsystem Maintainer. All these patches should then meet up in next, and work. If any are missing, the driver should return -ENODEV or similar. If there are any compile time dependencies in these patches, then we need to handle them differently. But at a very quick glance, i don't see any. Andrew
Hi Jakub, Thank you for your reply! > From: Jakub Kicinski, Sent: Thursday, September 22, 2022 10:07 AM > > On Thu, 22 Sep 2022 00:46:34 +0000 Yoshihiro Shimoda wrote: > > I thought we have 2 types about the use of the treewide: > > 1) Completely depends on multiple subsystems and/or > > change multiple subsystems in a patch. > > 2) Convenient for review. > > > > This patch series type is the 2) above. However, should I use > > treewide for the 1) only? > > I thought "treewide" means you're changing something across the tree. > If you want to get a new platform reviewed I'd just post the patches > as RFC without any prefix in the subject. But I could be wrong. Using RFC is reasonable, I think. I'll use this at next time. Thanks! > My main point (which I did a pretty poor job of actually making) > was that for the networking driver to be merged it needs to get > posted separately. I'll separate patches for the networking driver on v3 patch. Best regards, Yoshihiro Shimoda
Hi Andrew, > From: Andrew Lunn, Sent: Thursday, September 22, 2022 10:19 AM > > On Wed, Sep 21, 2022 at 06:06:40PM -0700, Jakub Kicinski wrote: > > On Thu, 22 Sep 2022 00:46:34 +0000 Yoshihiro Shimoda wrote: > > > I thought we have 2 types about the use of the treewide: > > > 1) Completely depends on multiple subsystems and/or > > > change multiple subsystems in a patch. > > > 2) Convenient for review. > > > > > > This patch series type is the 2) above. However, should I use > > > treewide for the 1) only? > > > > I thought "treewide" means you're changing something across the tree. > > If you want to get a new platform reviewed I'd just post the patches > > as RFC without any prefix in the subject. But I could be wrong. > > > > My main point (which I did a pretty poor job of actually making) > > was that for the networking driver to be merged it needs to get > > posted separately. > > Expanding on that... > > You have a clock patch, which should go via the clock subsystem Maintainer. > You have a PHY path, which should go via the generic PHY subsystem Maintainer. > You have an Ethernet driver and binding patch, which can go via netdev, > Cc: the device tree list. > And a patch to add the needed nodes to .dts files which can go via the > renesas Maintainer. > > At an early RFC stage, posting them all at once can be useful, to help > see all the bits and pieces. But by the time you have code ready for > merging, it should really go via easu subsystem Maintainer. Thank you very much for the detailed explanation. I completely understood it. > All these patches should then meet up in next, and work. If any are > missing, the driver should return -ENODEV or similar. Yes, I did test such things. > If there are any compile time dependencies in these patches, then we > need to handle them differently. But at a very quick glance, i don't > see any. You're correct. This patch series doesn't depend in compile time. Best regards, Yoshihiro Shimoda > Andrew
On 22-09-22, 00:46, Yoshihiro Shimoda wrote: > Hi Jakub, > > Thank you for your comment! > > > From: Jakub Kicinski, Sent: Wednesday, September 21, 2022 11:40 PM > > > > On Wed, 21 Sep 2022 17:47:37 +0900 Yoshihiro Shimoda wrote: > > > Subject: [PATCH v2 0/8] treewide: Add R-Car S4-8 Ethernet Switch support > > > > I think you may be slightly confused about the use of the treewide > > prefix. Perhaps Geert or one of the upstream-savvy contractors could > > help you navigate targeting the correct trees? > > I thought we have 2 types about the use of the treewide: > 1) Completely depends on multiple subsystems and/or > change multiple subsystems in a patch. > 2) Convenient for review. > > This patch series type is the 2) above. However, should I use > treewide for the 1) only? No, How is it convenient for review.. I would like to see a series just for phy... I dont need to see the whole other things... Maybe Convenient for you to toss the pile to upstream reviewers, surely not for us!
Hi Vinod, > From: Vinod Koul, Sent: Saturday, September 24, 2022 3:57 PM > > On 22-09-22, 00:46, Yoshihiro Shimoda wrote: > > Hi Jakub, > > > > Thank you for your comment! > > > > > From: Jakub Kicinski, Sent: Wednesday, September 21, 2022 11:40 PM > > > > > > On Wed, 21 Sep 2022 17:47:37 +0900 Yoshihiro Shimoda wrote: > > > > Subject: [PATCH v2 0/8] treewide: Add R-Car S4-8 Ethernet Switch support > > > > > > I think you may be slightly confused about the use of the treewide > > > prefix. Perhaps Geert or one of the upstream-savvy contractors could > > > help you navigate targeting the correct trees? > > > > I thought we have 2 types about the use of the treewide: > > 1) Completely depends on multiple subsystems and/or > > change multiple subsystems in a patch. > > 2) Convenient for review. > > > > This patch series type is the 2) above. However, should I use > > treewide for the 1) only? > > No, How is it convenient for review.. I would like to see a series just > for phy... I dont need to see the whole other things... > > Maybe Convenient for you to toss the pile to upstream reviewers, surely > not for us! Thank you very much for your comments. I understood it. I will not submit this type of treewide from now on. Best regards, Yoshihiro Shimoda
This patch series is based on next-20220915. Add minimal support for R-Car S4-8 Etherent Switch. This hardware supports a lot of features. But, this driver only supports it as act as an ethernet controller for now. - patch [1/8] is for CCF. - patch [2/8] and [3/8] are for Generic PHY. - patch [4/8] through [6/8] are for Network Ethernet. - patch [7/8] and [8/8] are for Renesas ARM64 SoC. Changes from v1: https://lore.kernel.org/all/20220909132614.1967276-1-yoshihiro.shimoda.uh@renesas.com/ - Separate Ethernet SERDES hardware block so that made a Generic PHY driver. - Separate PTP support into a patch as patch [6/8]. - Fix dt-bindings of Ethernet Switch. - Remove module parameters from Ethernet Switch driver. - Wrote reverse christmas tree about local variables in all the code. - Improve error path handlings. - Add comment about the current hardware limitation. - Add comment about magic numbers about SERDES settings. Yoshihiro Shimoda (8): clk: renesas: r8a779f0: Add Ethernet Switch clocks dt-bindings: phy: renesas: Document Renesas Ethernet SERDES phy: renesas: Add Renesas Ethernet SERDES driver for R-Car S4-8 dt-bindings: net: renesas: Document Renesas Ethernet Switch net: ethernet: renesas: Add Ethernet Switch driver net: ethernet: renesas: rswitch: Add R-Car Gen4 gPTP support arm64: dts: renesas: r8a779f0: Add Ethernet Switch and SERDES nodes arm64: dts: renesas: r8a779f0: spider: Enable Ethernet Switch and SERDES .../bindings/net/renesas,etherswitch.yaml | 286 +++ .../bindings/phy/renesas,ether-serdes.yaml | 54 + .../dts/renesas/r8a779f0-spider-ethernet.dtsi | 54 + arch/arm64/boot/dts/renesas/r8a779f0.dtsi | 111 + drivers/clk/renesas/r8a779f0-cpg-mssr.c | 2 + drivers/net/ethernet/renesas/Kconfig | 11 + drivers/net/ethernet/renesas/Makefile | 4 + drivers/net/ethernet/renesas/rcar_gen4_ptp.c | 151 ++ drivers/net/ethernet/renesas/rcar_gen4_ptp.h | 71 + drivers/net/ethernet/renesas/rswitch.c | 1779 +++++++++++++++++ drivers/net/ethernet/renesas/rswitch.h | 967 +++++++++ drivers/phy/renesas/Kconfig | 7 + drivers/phy/renesas/Makefile | 2 +- drivers/phy/renesas/r8a779f0-ether-serdes.c | 303 +++ 14 files changed, 3801 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/net/renesas,etherswitch.yaml create mode 100644 Documentation/devicetree/bindings/phy/renesas,ether-serdes.yaml create mode 100644 drivers/net/ethernet/renesas/rcar_gen4_ptp.c create mode 100644 drivers/net/ethernet/renesas/rcar_gen4_ptp.h create mode 100644 drivers/net/ethernet/renesas/rswitch.c create mode 100644 drivers/net/ethernet/renesas/rswitch.h create mode 100644 drivers/phy/renesas/r8a779f0-ether-serdes.c