| Message ID | 20180903093308.24366-1-quentin.schulz@bootlin.com |
|---|---|
| Headers | show |
| Series | mscc: ocelot: add support for SerDes muxing configuration | expand |
> I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem. Hi Quentin Are you expecting merge conflicts? If not, it might be simpler to gets ACKs from each maintainer, and then merge it though one tree. Andrew
On 03/09/2018 15:34:15+0200, Andrew Lunn wrote: > > I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through > > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem. > > Hi Quentin > > Are you expecting merge conflicts? If not, it might be simpler to gets > ACKs from each maintainer, and then merge it though one tree. > There are some other DT changes for this cycle so those should probably go through MIPS.
From: Alexandre Belloni <alexandre.belloni@bootlin.com> Date: Mon, 3 Sep 2018 15:45:22 +0200 > On 03/09/2018 15:34:15+0200, Andrew Lunn wrote: >> > I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through >> > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem. >> >> Hi Quentin >> >> Are you expecting merge conflicts? If not, it might be simpler to gets >> ACKs from each maintainer, and then merge it though one tree. >> > > There are some other DT changes for this cycle so those should probably > go through MIPS. No objection for this going through the MIPS tree, and from me: Acked-by: David S. Miller <davem@davemloft.net>
On 03/09/2018 22:09:10-0700, David Miller wrote: > From: Alexandre Belloni <alexandre.belloni@bootlin.com> > Date: Mon, 3 Sep 2018 15:45:22 +0200 > > > On 03/09/2018 15:34:15+0200, Andrew Lunn wrote: > >> > I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through > >> > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem. > >> > >> Hi Quentin > >> > >> Are you expecting merge conflicts? If not, it might be simpler to gets > >> ACKs from each maintainer, and then merge it though one tree. > >> > > > > There are some other DT changes for this cycle so those should probably > > go through MIPS. > > No objection for this going through the MIPS tree, and from me: > What I meant was that 1/11 and 8/11 should go through MIPS because of the potential conflicts. The other patches can go through net-next as that will make more sense. Maybe Quentin can split the series in two, one for MIPS and one for net if that makes it easier for you to apply. > Acked-by: David S. Miller <davem@davemloft.net>
Hi Alexandre, Quentin, all, On Tue, Sep 04, 2018 at 05:16:53PM +0200, Alexandre Belloni wrote: > On 03/09/2018 22:09:10-0700, David Miller wrote: > > From: Alexandre Belloni <alexandre.belloni@bootlin.com> > > Date: Mon, 3 Sep 2018 15:45:22 +0200 > > > > > On 03/09/2018 15:34:15+0200, Andrew Lunn wrote: > > >> > I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through > > >> > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem. > > >> > > >> Hi Quentin > > >> > > >> Are you expecting merge conflicts? If not, it might be simpler to gets > > >> ACKs from each maintainer, and then merge it though one tree. > > > > > > There are some other DT changes for this cycle so those should probably > > > go through MIPS. > > > > No objection for this going through the MIPS tree, and from me: > > > > Acked-by: David S. Miller <davem@davemloft.net> > > What I meant was that 1/11 and 8/11 should go through MIPS because of > the potential conflicts. The other patches can go through net-next as > that will make more sense. Maybe Quentin can split the series in two, > one for MIPS and one for net if that makes it easier for you to apply. I'd be happy to take the .dts changes through the MIPS tree, though looking at them won't patch 1 break bisection? Since you remove the hsio reg entry it looks to me like mscc_ocelot_probe() will fail with -EINVAL (which comes from devm_ioremap_resource() with res=NULL) until patch 3. I'd feel more comfortable merging this piecemeal if it doesn't result in us breaking bisection for however long it takes for both the trees involved to be merged. Thanks, Paul
From: Alexandre Belloni <alexandre.belloni@bootlin.com> Date: Tue, 4 Sep 2018 17:16:53 +0200 > What I meant was that 1/11 and 8/11 should go through MIPS because of > the potential conflicts. The other patches can go through net-next as > that will make more sense. Maybe Quentin can split the series in two, > one for MIPS and one for net if that makes it easier for you to apply. It would make things easier for me.
Hi Paul, On Tue, Sep 04, 2018 at 09:10:28AM -0700, Paul Burton wrote: > Hi Alexandre, Quentin, all, > > On Tue, Sep 04, 2018 at 05:16:53PM +0200, Alexandre Belloni wrote: > > On 03/09/2018 22:09:10-0700, David Miller wrote: > > > From: Alexandre Belloni <alexandre.belloni@bootlin.com> > > > Date: Mon, 3 Sep 2018 15:45:22 +0200 > > > > > > > On 03/09/2018 15:34:15+0200, Andrew Lunn wrote: > > > >> > I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through > > > >> > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem. > > > >> > > > >> Hi Quentin > > > >> > > > >> Are you expecting merge conflicts? If not, it might be simpler to gets > > > >> ACKs from each maintainer, and then merge it though one tree. > > > > > > > > There are some other DT changes for this cycle so those should probably > > > > go through MIPS. > > > > > > No objection for this going through the MIPS tree, and from me: > > > > > > Acked-by: David S. Miller <davem@davemloft.net> > > > > What I meant was that 1/11 and 8/11 should go through MIPS because of > > the potential conflicts. The other patches can go through net-next as > > that will make more sense. Maybe Quentin can split the series in two, > > one for MIPS and one for net if that makes it easier for you to apply. > > I'd be happy to take the .dts changes through the MIPS tree, though > looking at them won't patch 1 break bisection? > > Since you remove the hsio reg entry it looks to me like > mscc_ocelot_probe() will fail with -EINVAL (which comes from > devm_ioremap_resource() with res=NULL) until patch 3. > That's correct. > I'd feel more comfortable merging this piecemeal if it doesn't result in > us breaking bisection for however long it takes for both the trees > involved to be merged. > How do you want to proceed then? Quentin
Hi Quentin, On Tue, Sep 04, 2018 at 08:00:06PM +0200, Quentin Schulz wrote: > On Tue, Sep 04, 2018 at 09:10:28AM -0700, Paul Burton wrote: > > Hi Alexandre, Quentin, all, > > > > On Tue, Sep 04, 2018 at 05:16:53PM +0200, Alexandre Belloni wrote: > > > On 03/09/2018 22:09:10-0700, David Miller wrote: > > > > From: Alexandre Belloni <alexandre.belloni@bootlin.com> > > > > Date: Mon, 3 Sep 2018 15:45:22 +0200 > > > > > > > > > On 03/09/2018 15:34:15+0200, Andrew Lunn wrote: > > > > >> > I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through > > > > >> > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem. > > > > >> > > > > >> Hi Quentin > > > > >> > > > > >> Are you expecting merge conflicts? If not, it might be simpler to gets > > > > >> ACKs from each maintainer, and then merge it though one tree. > > > > > > > > > > There are some other DT changes for this cycle so those should probably > > > > > go through MIPS. > > > > > > > > No objection for this going through the MIPS tree, and from me: > > > > > > > > Acked-by: David S. Miller <davem@davemloft.net> > > > > > > What I meant was that 1/11 and 8/11 should go through MIPS because of > > > the potential conflicts. The other patches can go through net-next as > > > that will make more sense. Maybe Quentin can split the series in two, > > > one for MIPS and one for net if that makes it easier for you to apply. > > > > I'd be happy to take the .dts changes through the MIPS tree, though > > looking at them won't patch 1 break bisection? > > > > Since you remove the hsio reg entry it looks to me like > > mscc_ocelot_probe() will fail with -EINVAL (which comes from > > devm_ioremap_resource() with res=NULL) until patch 3. > > > > That's correct. > > > I'd feel more comfortable merging this piecemeal if it doesn't result in > > us breaking bisection for however long it takes for both the trees > > involved to be merged. > > > > How do you want to proceed then? Well, it sounded like David is OK with this all going through the MIPS tree, though we'd need an ack for the PHY parts. Alternatively I'd be happy for the DT changes to go through the net-next tree, which may make more sense given that the .dts changes are pretty trivial in comparison with the driver changes. If David wants to do that then for patches 1 & 8: Acked-by: Paul Burton <paul.burton@mips.com> Either way there may be conflicts for ocelot.dtsi when it comes to merging to master, but they should be simple to resolve. It seems Wolfram already took your DT changes for I2C so there's probably going to be multiple trees updating that file this cycle already anyway. Ideally I'd say "don't break bisection" but that's sort of a separate issue here since even if you restructure your series to do that it would still need to go through one tree. For example you could adjust mscc_ocelot_probe() to handle either the reg property or the syscon, then adjust the DT to use the syscon, then remove the code dealing with the reg property, and I'd consider that a good idea anyway but it would still probably all need to go through one tree to make sure things get merged in the right order & avoid breaking bisection. Thanks, Paul
On 04/09/2018 16:03:51-0700, Paul Burton wrote: > Well, it sounded like David is OK with this all going through the MIPS > tree, though we'd need an ack for the PHY parts. > > Alternatively I'd be happy for the DT changes to go through the net-next > tree, which may make more sense given that the .dts changes are pretty > trivial in comparison with the driver changes. If David wants to do that > then for patches 1 & 8: > > Acked-by: Paul Burton <paul.burton@mips.com> > > Either way there may be conflicts for ocelot.dtsi when it comes to > merging to master, but they should be simple to resolve. It seems > Wolfram already took your DT changes for I2C so there's probably going > to be multiple trees updating that file this cycle already anyway. > Actually, I think Wolfram meant that he took the bindings so you can take the DT patches for i2c. > Ideally I'd say "don't break bisection" but that's sort of a separate > issue here since even if you restructure your series to do that it would > still need to go through one tree. For example you could adjust > mscc_ocelot_probe() to handle either the reg property or the syscon, > then adjust the DT to use the syscon, then remove the code dealing with > the reg property, and I'd consider that a good idea anyway but it would > still probably all need to go through one tree to make sure things get > merged in the right order & avoid breaking bisection. > I don't really think bisection is important at this stage but if you don't want to break it, then I guess it makes more sense to have the whole series through net.
The Ocelot switch has currently an hardcoded SerDes muxing that suits only a particular use case. Any other board setup will fail to work. To prepare for upcoming boards' support that do not have the same muxing, create a PHY driver that will handle all possible cases. A SerDes can work in SGMII, QSGMII or PCIe and is also muxed to use a given port depending on the selected mode or board design. The SerDes configuration is in the middle of an address space (HSIO) that is used to configure some parts in the MAC controller driver, that is why we need to use a syscon so that we can write to the same address space from different drivers safely using regmap. Patches from generic PHY and net should be safe to be merged separately. This breaks backward compatibility but it's fine because there's only one board at the moment that is using what's modified in this patch series. This will break git bisect. Even though this patch series is about SerDes __muxing__ configuration, the DT node is named serdes for the simple reason that I couldn't find any mention to SerDes anywhere else from the address space handled by this driver. I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through net while the others (6, 7, 9 and 10) go through the generic PHY subsystem. Thanks, Quentin v2: - use a switch case for setting the phy_mode in the SerDes driver as suggested by Andrew, - stop replacing the value of the error pointer in the SerDes driver, - use a dev_dbg for the deferring of the probe in the SerDes driver, - use constants in the Device Tree to select the SerDes macro in use with a port, - adapt the SerDes driver to use those constants, - add a header file in include/dt-bindings for the constants, - fix space/tab issue, Quentin Schulz (11): MIPS: mscc: ocelot: make HSIO registers address range a syscon dt-bindings: net: ocelot: remove hsio from the list of register address spaces net: mscc: ocelot: get HSIO regmap from syscon net: mscc: ocelot: move the HSIO header to include/soc net: mscc: ocelot: simplify register access for PLL5 configuration phy: add QSGMII and PCIE modes dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing MIPS: mscc: ocelot: add SerDes mux DT node dt-bindings: add constants for Microsemi Ocelot SerDes driver phy: add driver for Microsemi Ocelot SerDes muxing net: mscc: ocelot: make use of SerDes PHYs for handling their configuration .../devicetree/bindings/mips/mscc.txt | 16 + .../devicetree/bindings/net/mscc-ocelot.txt | 9 +- .../bindings/phy/phy-ocelot-serdes.txt | 40 +++ arch/mips/boot/dts/mscc/ocelot.dtsi | 19 +- drivers/net/ethernet/mscc/Kconfig | 2 + drivers/net/ethernet/mscc/ocelot.c | 16 +- drivers/net/ethernet/mscc/ocelot.h | 79 +---- drivers/net/ethernet/mscc/ocelot_board.c | 61 +++- drivers/net/ethernet/mscc/ocelot_regs.c | 93 +----- drivers/phy/Kconfig | 1 + drivers/phy/Makefile | 1 + drivers/phy/mscc/Kconfig | 11 + drivers/phy/mscc/Makefile | 5 + drivers/phy/mscc/phy-ocelot-serdes.c | 288 ++++++++++++++++++ include/dt-bindings/phy/phy-ocelot-serdes.h | 19 ++ include/linux/phy/phy.h | 2 + .../soc}/mscc/ocelot_hsio.h | 74 +++++ 17 files changed, 556 insertions(+), 180 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt create mode 100644 drivers/phy/mscc/Kconfig create mode 100644 drivers/phy/mscc/Makefile create mode 100644 drivers/phy/mscc/phy-ocelot-serdes.c create mode 100644 include/dt-bindings/phy/phy-ocelot-serdes.h rename {drivers/net/ethernet => include/soc}/mscc/ocelot_hsio.h (95%)