From: Vladimir Oltean <[email protected]>
This series officializes the device tree bindings for the embedded
Ethernet switch on NXP LS1028A (and for the reference design board).
The driver has been in the tree since v5.4-rc6.
As per feedback received in v1, I've changed the DT bindings for the
internal ports from "gmii" to "internal". So I would like the entire
series to be merged through a single tree, be it net-next or devicetree.
If this happens, I would like the other maintainer to acknowledge this
fact and the patches themselves. Thanks.
Claudiu Manoil (2):
arm64: dts: fsl: ls1028a: add node for Felix switch
arm64: dts: fsl: ls1028a: enable switch PHYs on RDB
Vladimir Oltean (3):
arm64: dts: fsl: ls1028a: delete extraneous #interrupt-cells for ENETC
RCIE
net: dsa: felix: Use PHY_INTERFACE_MODE_INTERNAL instead of GMII
dt-bindings: net: dsa: ocelot: document the vsc9959 core
.../devicetree/bindings/net/dsa/ocelot.txt | 96 +++++++++++++++++++
.../boot/dts/freescale/fsl-ls1028a-rdb.dts | 51 ++++++++++
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 85 +++++++++++++++-
drivers/net/dsa/ocelot/felix.c | 3 +-
drivers/net/dsa/ocelot/felix_vsc9959.c | 3 +-
5 files changed, 232 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/dsa/ocelot.txt
--
2.17.1
From: Vladimir Oltean <[email protected]>
Date: Wed, 19 Feb 2020 17:12:54 +0200
> From: Vladimir Oltean <[email protected]>
>
> This series officializes the device tree bindings for the embedded
> Ethernet switch on NXP LS1028A (and for the reference design board).
> The driver has been in the tree since v5.4-rc6.
>
> As per feedback received in v1, I've changed the DT bindings for the
> internal ports from "gmii" to "internal". So I would like the entire
> series to be merged through a single tree, be it net-next or devicetree.
> If this happens, I would like the other maintainer to acknowledge this
> fact and the patches themselves. Thanks.
I'm fine with this going through the devicetree tree.
Acked-by: David S. Miller <[email protected]>
> This series officializes the device tree bindings for the embedded
> Ethernet switch on NXP LS1028A (and for the reference design board).
> The driver has been in the tree since v5.4-rc6.
>
> As per feedback received in v1, I've changed the DT bindings for the
> internal ports from "gmii" to "internal". So I would like the entire
> series to be merged through a single tree, be it net-next or devicetree.
> If this happens, I would like the other maintainer to acknowledge this
> fact and the patches themselves. Thanks.
>
> Claudiu Manoil (2):
> arm64: dts: fsl: ls1028a: add node for Felix switch
> arm64: dts: fsl: ls1028a: enable switch PHYs on RDB
>
> Vladimir Oltean (3):
> arm64: dts: fsl: ls1028a: delete extraneous #interrupt-cells for ENETC
> RCIE
> net: dsa: felix: Use PHY_INTERFACE_MODE_INTERNAL instead of GMII
> dt-bindings: net: dsa: ocelot: document the vsc9959 core
For all patches except 5/5 (because it was tested on a custom board) and
with patch from [1] applied:
Tested-by: Michael Walle <[email protected]>
-michael
[1] https://patchwork.ozlabs.org/patch/1239296/
>
> .../devicetree/bindings/net/dsa/ocelot.txt | 96 +++++++++++++++++++
> .../boot/dts/freescale/fsl-ls1028a-rdb.dts | 51 ++++++++++
> .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 85 +++++++++++++++-
> drivers/net/dsa/ocelot/felix.c | 3 +-
> drivers/net/dsa/ocelot/felix_vsc9959.c | 3 +-
> 5 files changed, 232 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/dsa/ocelot.txt
--
2.17.1
On Wed, Feb 19, 2020 at 05:12:54PM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean <[email protected]>
>
> This series officializes the device tree bindings for the embedded
> Ethernet switch on NXP LS1028A (and for the reference design board).
> The driver has been in the tree since v5.4-rc6.
>
> As per feedback received in v1, I've changed the DT bindings for the
> internal ports from "gmii" to "internal". So I would like the entire
> series to be merged through a single tree, be it net-next or devicetree.
Will applying the patches via different trees as normal cause any
issue like build breakage or regression on either tree? Otherwise, I do
not see the series needs to go in through a single tree.
Shawn
> If this happens, I would like the other maintainer to acknowledge this
> fact and the patches themselves. Thanks.
>
> Claudiu Manoil (2):
> arm64: dts: fsl: ls1028a: add node for Felix switch
> arm64: dts: fsl: ls1028a: enable switch PHYs on RDB
>
> Vladimir Oltean (3):
> arm64: dts: fsl: ls1028a: delete extraneous #interrupt-cells for ENETC
> RCIE
> net: dsa: felix: Use PHY_INTERFACE_MODE_INTERNAL instead of GMII
> dt-bindings: net: dsa: ocelot: document the vsc9959 core
>
> .../devicetree/bindings/net/dsa/ocelot.txt | 96 +++++++++++++++++++
> .../boot/dts/freescale/fsl-ls1028a-rdb.dts | 51 ++++++++++
> .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 85 +++++++++++++++-
> drivers/net/dsa/ocelot/felix.c | 3 +-
> drivers/net/dsa/ocelot/felix_vsc9959.c | 3 +-
> 5 files changed, 232 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/dsa/ocelot.txt
>
> --
> 2.17.1
>
Hi Shawn,
On Mon, 24 Feb 2020 at 08:32, Shawn Guo <[email protected]> wrote:
>
> On Wed, Feb 19, 2020 at 05:12:54PM +0200, Vladimir Oltean wrote:
> > From: Vladimir Oltean <[email protected]>
> >
> > As per feedback received in v1, I've changed the DT bindings for the
> > internal ports from "gmii" to "internal". So I would like the entire
> > series to be merged through a single tree, be it net-next or devicetree.
>
> Will applying the patches via different trees as normal cause any
> issue like build breakage or regression on either tree? Otherwise, I do
> not see the series needs to go in through a single tree.
>
> Shawn
>
No, the point is that I've made some changes in the device tree
bindings validation in the driver, which make the driver without those
changes incompatible with the bindings themselves that I'm
introducing. So I would like the driver to be operational on the
actual commit that introduces the bindings, at least in your tree. I
don't expect merge conflicts to occur in that area of the code.
Thanks,
-Vladimir
On Mon, Feb 24, 2020 at 09:59:53AM +0200, Vladimir Oltean wrote:
> Hi Shawn,
>
> On Mon, 24 Feb 2020 at 08:32, Shawn Guo <[email protected]> wrote:
> >
> > On Wed, Feb 19, 2020 at 05:12:54PM +0200, Vladimir Oltean wrote:
> > > From: Vladimir Oltean <[email protected]>
> > >
> > > As per feedback received in v1, I've changed the DT bindings for the
> > > internal ports from "gmii" to "internal". So I would like the entire
> > > series to be merged through a single tree, be it net-next or devicetree.
> >
> > Will applying the patches via different trees as normal cause any
> > issue like build breakage or regression on either tree? Otherwise, I do
> > not see the series needs to go in through a single tree.
> >
> > Shawn
> >
>
> No, the point is that I've made some changes in the device tree
> bindings validation in the driver, which make the driver without those
> changes incompatible with the bindings themselves that I'm
> introducing. So I would like the driver to be operational on the
> actual commit that introduces the bindings, at least in your tree. I
> don't expect merge conflicts to occur in that area of the code.
The dt-bindings patch is supposed to go through subsystem tree together
with driver changes by nature. That said, patch #1 and #2 are for
David, and I will pick up the rest (DTS ones).
Shawn
On Mon, 24 Feb 2020 at 10:48, Shawn Guo <[email protected]> wrote:
>
> On Mon, Feb 24, 2020 at 09:59:53AM +0200, Vladimir Oltean wrote:
> > Hi Shawn,
> >
> > On Mon, 24 Feb 2020 at 08:32, Shawn Guo <[email protected]> wrote:
> > >
> > > On Wed, Feb 19, 2020 at 05:12:54PM +0200, Vladimir Oltean wrote:
> > > > From: Vladimir Oltean <[email protected]>
> > > >
> > > > As per feedback received in v1, I've changed the DT bindings for the
> > > > internal ports from "gmii" to "internal". So I would like the entire
> > > > series to be merged through a single tree, be it net-next or devicetree.
> > >
> > > Will applying the patches via different trees as normal cause any
> > > issue like build breakage or regression on either tree? Otherwise, I do
> > > not see the series needs to go in through a single tree.
> > >
> > > Shawn
> > >
> >
> > No, the point is that I've made some changes in the device tree
> > bindings validation in the driver, which make the driver without those
> > changes incompatible with the bindings themselves that I'm
> > introducing. So I would like the driver to be operational on the
> > actual commit that introduces the bindings, at least in your tree. I
> > don't expect merge conflicts to occur in that area of the code.
>
> The dt-bindings patch is supposed to go through subsystem tree together
> with driver changes by nature. That said, patch #1 and #2 are for
> David, and I will pick up the rest (DTS ones).
>
> Shawn
Ok, any further comments on the series or should I respin after your
feedback regarding the commit message prefix and the status =
"disabled" ordering?
-Vladimir
On Mon, 24 Feb 2020 at 10:50, Vladimir Oltean <[email protected]> wrote:
>
> On Mon, 24 Feb 2020 at 10:48, Shawn Guo <[email protected]> wrote:
> >
> > On Mon, Feb 24, 2020 at 09:59:53AM +0200, Vladimir Oltean wrote:
> > > Hi Shawn,
> > >
> > > On Mon, 24 Feb 2020 at 08:32, Shawn Guo <[email protected]> wrote:
> > > >
> > > > On Wed, Feb 19, 2020 at 05:12:54PM +0200, Vladimir Oltean wrote:
> > > > > From: Vladimir Oltean <[email protected]>
> > > > >
> > > > > As per feedback received in v1, I've changed the DT bindings for the
> > > > > internal ports from "gmii" to "internal". So I would like the entire
> > > > > series to be merged through a single tree, be it net-next or devicetree.
> > > >
> > > > Will applying the patches via different trees as normal cause any
> > > > issue like build breakage or regression on either tree? Otherwise, I do
> > > > not see the series needs to go in through a single tree.
> > > >
> > > > Shawn
> > > >
> > >
> > > No, the point is that I've made some changes in the device tree
> > > bindings validation in the driver, which make the driver without those
> > > changes incompatible with the bindings themselves that I'm
> > > introducing. So I would like the driver to be operational on the
> > > actual commit that introduces the bindings, at least in your tree. I
> > > don't expect merge conflicts to occur in that area of the code.
> >
> > The dt-bindings patch is supposed to go through subsystem tree together
> > with driver changes by nature. That said, patch #1 and #2 are for
> > David, and I will pick up the rest (DTS ones).
> >
> > Shawn
>
> Ok, any further comments on the series or should I respin after your
> feedback regarding the commit message prefix and the status =
> "disabled" ordering?
>
> -Vladimir
By the way all your comments have been on v2 and I've sent v3 already.
So this series is superseded.
Regards,
-Vladimir