Regressions in Ocelot switch drivers
Subsystems (7)
Vladimir Oltean
maintainercover Regressions in Ocelot switch drivers
These are 3 patches which resolve a regression in the Seville driver, one in the Felix driver and a generic one which affects any kernel compiled with 2 Kconfig options enabled. All of them have in common my lack of attention during review/testing. The patches touch the DSA, MFD and MDIO drivers for Ocelot. I think it would be preferable if all patches went through netdev (with Lee's Ack).
Vladimir Oltean (3):
net: dsa: seville: ignore mscc-miim read errors from Lynx PCS
net: dsa: felix: fix internal MDIO controller resource length
net: mscc: ocelot: fix duplicate driver name error
drivers/mfd/ocelot-core.c | 2 +- drivers/net/dsa/ocelot/felix_vsc9959.c | 2 +- drivers/net/dsa/ocelot/ocelot_ext.c | 2 +- drivers/net/dsa/ocelot/seville_vsc9953.c | 4 ++-- drivers/net/mdio/mdio-mscc-miim.c | 9 ++++++--- include/linux/mdio/mdio-mscc-miim.h | 2 +- 6 files changed, 12 insertions(+), 9 deletions(-)
Signature · 1 line
2.34.1
Vladimir Oltean
maintainerPATCH 1/3 net: dsa: seville: ignore mscc-miim read errors from Lynx PCS
During the refactoring in the commit below, vsc9953_mdio_read() was replaced with mscc_miim_read(), which has one extra step: it checks for the MSCC_MIIM_DATA_ERROR bits before returning the result.
On T1040RDB, there are 8 QSGMII PCSes belonging to the switch, and they are organized in 2 groups. First group responds to MDIO addresses 4-7 because QSGMIIACR1[MDEV_PORT] is 1, and the second group responds to MDIO addresses 8-11 because QSGMIIBCR1[MDEV_PORT] is 2. I have double checked that these values are correctly set in the SERDES, as well as PCCR1[QSGMA_CFG] and PCCR1[QSGMB_CFG] are both 0b01.
mscc_miim_read: phyad 8 reg 0x1 MIIM_DATA 0x2dmscc_miim_read: phyad 8 reg 0x5 MIIM_DATA 0x5801mscc_miim_read: phyad 8 reg 0x1 MIIM_DATA 0x2dmscc_miim_read: phyad 8 reg 0x5 MIIM_DATA 0x5801mscc_miim_read: phyad 9 reg 0x1 MIIM_DATA 0x2dmscc_miim_read: phyad 9 reg 0x5 MIIM_DATA 0x5801mscc_miim_read: phyad 9 reg 0x1 MIIM_DATA 0x2dmscc_miim_read: phyad 9 reg 0x5 MIIM_DATA 0x5801mscc_miim_read: phyad 10 reg 0x1 MIIM_DATA 0x2dmscc_miim_read: phyad 10 reg 0x5 MIIM_DATA 0x5801mscc_miim_read: phyad 10 reg 0x1 MIIM_DATA 0x2dmscc_miim_read: phyad 10 reg 0x5 MIIM_DATA 0x5801mscc_miim_read: phyad 11 reg 0x1 MIIM_DATA 0x2dmscc_miim_read: phyad 11 reg 0x5 MIIM_DATA 0x5801mscc_miim_read: phyad 11 reg 0x1 MIIM_DATA 0x2dmscc_miim_read: phyad 11 reg 0x5 MIIM_DATA 0x5801mscc_miim_read: phyad 4 reg 0x1 MIIM_DATA 0x3002d, ERRORmscc_miim_read: phyad 4 reg 0x5 MIIM_DATA 0x3da01, ERRORmscc_miim_read: phyad 5 reg 0x1 MIIM_DATA 0x3002d, ERRORmscc_miim_read: phyad 5 reg 0x5 MIIM_DATA 0x35801, ERRORmscc_miim_read: phyad 5 reg 0x1 MIIM_DATA 0x3002d, ERRORmscc_miim_read: phyad 5 reg 0x5 MIIM_DATA 0x35801, ERRORmscc_miim_read: phyad 6 reg 0x1 MIIM_DATA 0x3002d, ERRORmscc_miim_read: phyad 6 reg 0x5 MIIM_DATA 0x35801, ERRORmscc_miim_read: phyad 6 reg 0x1 MIIM_DATA 0x3002d, ERRORmscc_miim_read: phyad 6 reg 0x5 MIIM_DATA 0x35801, ERRORmscc_miim_read: phyad 7 reg 0x1 MIIM_DATA 0x3002d, ERRORmscc_miim_read: phyad 7 reg 0x5 MIIM_DATA 0x35801, ERRORmscc_miim_read: phyad 7 reg 0x1 MIIM_DATA 0x3002d, ERRORmscc_miim_read: phyad 7 reg 0x5 MIIM_DATA 0x35801, ERROR
As can be seen, the data in MIIM_DATA is still valid despite having the MSCC_MIIM_DATA_ERROR bits set. The driver as introduced in commit 84705fc16552 ("net: dsa: felix: introduce support for Seville VSC9953 switch") was ignoring these bits, perhaps deliberately (although unbeknownst to me).
This is an old IP and the hardware team cannot seem to be able to help me track down a plausible reason for these failures. I'll keep investigating, but in the meantime, this is a direct regression which must be restored to a working state.
The only thing I can do is keep ignoring the errors as before.
--- drivers/net/dsa/ocelot/seville_vsc9953.c | 4 ++-- drivers/net/mdio/mdio-mscc-miim.c | 9 ++++++--- include/linux/mdio/mdio-mscc-miim.h | 2 +- 3 files changed, 9 insertions(+), 6 deletions(-)
drivers/net/dsa/ocelot/seville_vsc9953.c +2 -2
@@ -893,8 +893,8 @@ static int vsc9953_mdio_bus_alloc(struct ocelot *ocelot) rc =mscc_miim_setup (dev, &bus,"VSC9953 internal MDIO bus" , ocelot->targets[GCB ], - ocelot->map[GCB ][GCB_MIIM_MII_STATUS ®_MASK ]); - + ocelot->map[GCB ][GCB_MIIM_MII_STATUS ®_MASK ], + true);if (rc) {dev_err (dev,"failed to setup MDIO bus\n" );return rc;
drivers/net/mdio/mdio-mscc-miim.c +6 -3
@@ -52,6 +52,7 @@ struct mscc_miim_info {struct mscc_miim_dev {struct regmap *regs;int mii_status_offset; +bool ignore_read_errors;struct regmap *phy_regs;const struct mscc_miim_info *info;struct clk *clk;
@@ -135,7 +136,7 @@ static int mscc_miim_read(struct mii_bus *bus, int mii_id, int regnum) goto out; } -if (val &MSCC_MIIM_DATA_ERROR ) { +if (!miim->ignore_read_errors && !!(val &MSCC_MIIM_DATA_ERROR )) { ret = -EIO ; goto out; }
@@ -212,7 +213,8 @@ static const struct regmap_config mscc_miim_phy_regmap_config = { };int mscc_miim_setup (struct device *dev,struct mii_bus **pbus,const char *name, -struct regmap *mii_regmap,int status_offset) +struct regmap *mii_regmap,int status_offset, +bool ignore_read_errors) {struct mscc_miim_dev *miim;struct mii_bus *bus;
@@ -234,6 +236,7 @@ int mscc_miim_setup(struct device *dev, struct mii_bus **pbus, const char *name, miim->regs = mii_regmap; miim->mii_status_offset = status_offset; + miim->ignore_read_errors = ignore_read_errors; *pbus = bus;
@@ -285,7 +288,7 @@ static int mscc_miim_probe(struct platform_device *pdev)return dev_err_probe (dev,PTR_ERR (phy_regmap),"Unable to create phy register regmap\n" ); - ret =mscc_miim_setup (dev, &bus,"mscc_miim" , mii_regmap,0 ); + ret =mscc_miim_setup (dev, &bus,"mscc_miim" , mii_regmap,0 , false);if (ret <0 ) {dev_err (dev,"Unable to setup the MDIO bus\n" );return ret;
include/linux/mdio/mdio-mscc-miim.h +1 -1
@@ -14,6 +14,6 @@int mscc_miim_setup (struct device *device,struct mii_bus **bus,const char *name,struct regmap *mii_regmap, -int status_offset); +int status_offset,bool ignore_read_errors);#endif
Signature · 1 line
2.34.1
Re: [PATCH net 1/3] net: dsa: seville: ignore mscc-miim read errors from Lynx PCS
Quoted 53 lines · Vladimir Oltean
During the refactoring in the commit below,
vsc9953_mdio_read()was replaced withmscc_miim_read(), which has one extra step: it checks for theMSCC_MIIM_DATA_ERRORbits before returning the result.On T1040RDB, there are 8 QSGMII PCSes belonging to the switch, and they are organized in 2 groups. First group responds to MDIO addresses 4-7 because QSGMIIACR1[MDEV_PORT] is 1, and the second group responds to MDIO addresses 8-11 because QSGMIIBCR1[MDEV_PORT] is 2. I have double checked that these values are correctly set in the SERDES, as well as PCCR1[QSGMA_CFG] and PCCR1[QSGMB_CFG] are both 0b01.
mscc_miim_read: phyad 8 reg0x1MIIM_DATA0x2dmscc_miim_read: phyad 8 reg0x5MIIM_DATA0x5801mscc_miim_read: phyad 8 reg0x1MIIM_DATA0x2dmscc_miim_read: phyad 8 reg0x5MIIM_DATA0x5801mscc_miim_read: phyad 9 reg0x1MIIM_DATA0x2dmscc_miim_read: phyad 9 reg0x5MIIM_DATA0x5801mscc_miim_read: phyad 9 reg0x1MIIM_DATA0x2dmscc_miim_read: phyad 9 reg0x5MIIM_DATA0x5801mscc_miim_read: phyad 10 reg0x1MIIM_DATA0x2dmscc_miim_read: phyad 10 reg0x5MIIM_DATA0x5801mscc_miim_read: phyad 10 reg0x1MIIM_DATA0x2dmscc_miim_read: phyad 10 reg0x5MIIM_DATA0x5801mscc_miim_read: phyad 11 reg0x1MIIM_DATA0x2dmscc_miim_read: phyad 11 reg0x5MIIM_DATA0x5801mscc_miim_read: phyad 11 reg0x1MIIM_DATA0x2dmscc_miim_read: phyad 11 reg0x5MIIM_DATA0x5801mscc_miim_read: phyad 4 reg0x1MIIM_DATA0x3002d, ERRORmscc_miim_read: phyad 4 reg0x5MIIM_DATA0x3da01, ERRORmscc_miim_read: phyad 5 reg0x1MIIM_DATA0x3002d, ERRORmscc_miim_read: phyad 5 reg0x5MIIM_DATA0x35801, ERRORmscc_miim_read: phyad 5 reg0x1MIIM_DATA0x3002d, ERRORmscc_miim_read: phyad 5 reg0x5MIIM_DATA0x35801, ERRORmscc_miim_read: phyad 6 reg0x1MIIM_DATA0x3002d, ERRORmscc_miim_read: phyad 6 reg0x5MIIM_DATA0x35801, ERRORmscc_miim_read: phyad 6 reg0x1MIIM_DATA0x3002d, ERRORmscc_miim_read: phyad 6 reg0x5MIIM_DATA0x35801, ERRORmscc_miim_read: phyad 7 reg0x1MIIM_DATA0x3002d, ERRORmscc_miim_read: phyad 7 reg0x5MIIM_DATA0x35801, ERRORmscc_miim_read: phyad 7 reg0x1MIIM_DATA0x3002d, ERRORmscc_miim_read: phyad 7 reg0x5MIIM_DATA0x35801, ERRORAs can be seen, the data in
MIIM_DATAis still valid despite having theMSCC_MIIM_DATA_ERRORbits set. The driver as introduced in commit84705fc16552("net: dsa: felix: introduce support for Seville VSC9953 switch") was ignoring these bits, perhaps deliberately (although unbeknownst to me).This is an old IP and the hardware team cannot seem to be able to help me track down a plausible reason for these failures. I'll keep investigating, but in the meantime, this is a direct regression which must be restored to a working state.
Quoted 4 lines
The only thing I can do is keep ignoring the errors as before.
Fixes b99658452355 ("net: dsa: ocelot: felix: utilize shared mscc-miim driver for indirect MDIO access")Signed-off-by Vladimir Oltean <[email protected]>
Signature · 1 line
Florian
Vladimir Oltean
maintainerPATCH 2/3 net: dsa: felix: fix internal MDIO controller resource length
In reply to Vladimir OlteanThe blamed commit did not properly convert the resource start/end format into the DEFINE_RES_MEM_NAMED() start/length format, resulting in a resource for vsc9959_imdio_res which is much longer than expected:
$ cat /proc/iomem
1f8000000-1f815ffff : pcie@1f0000000
1f8140000-1f815ffff : 0000:00:00.5
1f8148030-1f815006f : imdiovs (correct)
$ cat /proc/iomem
1f8000000-1f815ffff : pcie@1f0000000
1f8140000-1f815ffff : 0000:00:00.5
1f8148030-1f814803f : imdioLuckily it's not big enough to exceed the size of the parent resource (pci_resource_end(pdev, VSC9959_IMDIO_PCI_BAR)), and it doesn't overlap with anything else that the Linux driver uses currently, so the larger than expected size isn't a practical problem that I can see. Although it is clearly wrong in the /proc/iomem output.
--- drivers/net/dsa/ocelot/felix_vsc9959.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/dsa/ocelot/felix_vsc9959.c +1 -1
@@ -554,7 +554,7 @@ static const char * const vsc9959_resource_names[TARGET_MAX] = {* SGMII/QSGMII MAC PCS can be found. */ static const struct resource vsc9959_imdio_res = -DEFINE_RES_MEM_NAMED (0x8030 ,0x8040 ,"imdio" ); +DEFINE_RES_MEM_NAMED (0x8030 ,0x10 ,"imdio" );static const struct reg_field vsc9959_regfields[REGFIELD_MAX ] = { [ANA_ADVLEARN_VLAN_CHK ] =REG_FIELD (ANA_ADVLEARN ,6 ,6 ),
Signature · 1 line
2.34.1
Re: [PATCH net 2/3] net: dsa: felix: fix internal MDIO controller resource length
Quoted 16 lines · Vladimir Oltean
The blamed commit did not properly convert the resource start/end format into the
DEFINE_RES_MEM_NAMED()start/length format, resulting in a resource forvsc9959_imdio_reswhich is much longer than expected:$ cat /proc/iomem 1f8000000-1f815ffff : pcie@1f0000000 1f8140000-1f815ffff : 0000:00:00.5 1f8148030-1f815006f : imdiovs (correct)
$ cat /proc/iomem 1f8000000-1f815ffff : pcie@1f0000000 1f8140000-1f815ffff : 0000:00:00.5 1f8148030-1f814803f : imdio
Quoted 8 lines
Luckily it's not big enough to exceed the size of the parent resource (
pci_resource_end(pdev, VSC9959_IMDIO_PCI_BAR)), and it doesn't overlap with anything else that the Linux driver uses currently, so the larger than expected size isn't a practical problem that I can see. Although it is clearly wrong in the/proc/iomemoutput.Fixes 044d447a801f ("net: dsa: felix: use DEFINE_RES_MEM_NAMED for resources")Signed-off-by Vladimir Oltean <[email protected]>
Signature · 1 line
Florian
Vladimir Oltean
maintainerPATCH 3/3 net: mscc: ocelot: fix duplicate driver name error
In reply to Vladimir OlteanWhen compiling a kernel which has both CONFIG_NET_DSA_MSCC_OCELOT_EXT and CONFIG_MSCC_OCELOT_SWITCH enabled, the following error message will be printed:
[ 5.266588] Error: Driver 'ocelot-switch' is already registered, aborting...
Rename the ocelot_ext.c driver to "ocelot-ext-switch" to avoid the name duplication, and update the mfd_cell entry for its resources.
--- drivers/mfd/ocelot-core.c | 2 +- drivers/net/dsa/ocelot/ocelot_ext.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/mfd/ocelot-core.c +1 -1
@@ -177,7 +177,7 @@ static const struct mfd_cell vsc7512_devs[] = { .num_resources = ARRAY_SIZE(vsc7512_miim1_resources), .resources = vsc7512_miim1_resources, }, { - .name = "ocelot-switch", + .name = "ocelot-ext-switch", .of_compatible = "mscc,vsc7512-switch", .num_resources = ARRAY_SIZE(vsc7512_switch_resources), .resources = vsc7512_switch_resources,
drivers/net/dsa/ocelot/ocelot_ext.c +1 -1
@@ -149,7 +149,7 @@ MODULE_DEVICE_TABLE(of, ocelot_ext_switch_of_match);static struct platform_driver ocelot_ext_switch_driver = { .driver = { - .name ="ocelot-switch" , + .name ="ocelot-ext-switch" , .of_match_table =of_match_ptr (ocelot_ext_switch_of_match), }, .probe = ocelot_ext_probe,
Signature · 1 line
2.34.1
Russell King (Oracle)
reviewerRe: [PATCH net 3/3] net: mscc: ocelot: fix duplicate driver name error
Quoted 11 lines · Vladimir Oltean
When compiling a kernel which has both
CONFIG_NET_DSA_MSCC_OCELOT_EXTandCONFIG_MSCC_OCELOT_SWITCHenabled, the following error message will be printed:[ 5.266588] Error: Driver 'ocelot-switch' is already registered, aborting...Rename the
ocelot_ext.cdriver to "ocelot-ext-switch" to avoid the name duplication, and update themfd_cellentry for its resources.Fixes 3d7316ac81ac ("net: dsa: ocelot: add external ocelot switch control")Signed-off-by Vladimir Oltean <[email protected]>
I'll also send another patch to delete linux/phylink.h from ocelot_ext.c - seems that wasn't removed when the phylink instance was removed during review.
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Vladimir Oltean
maintainerRe: [PATCH net 3/3] net: mscc: ocelot: fix duplicate driver name error
Quoted 3 lines · Russell King (Oracle)
I'll also send another patch to delete
linux/phylink.hfromocelot_ext.c- seems that wasn't removed when the phylink instance was removed during review.
Good point. I suppose that would be on net-next, after the 6th of March? I just hope we'll remember by then.
Russell King (Oracle)
reviewerRe: [PATCH net 3/3] net: mscc: ocelot: fix duplicate driver name error
Quoted 7 lines · Vladimir Oltean
Quoted 3 lines · Russell King (Oracle)
I'll also send another patch to delete
linux/phylink.hfromocelot_ext.c- seems that wasn't removed when the phylink instance was removed during review.Good point. I suppose that would be on net-next, after the 6th of March? I just hope we'll remember by then.
Yep - however, I'm facing challenges to build-testing it at the moment as net-next is broken:
kernel/bpf/core.c: In function '___bpf_prog_run':kernel/bpf/core.c:1914:3: error: implicit declaration of function 'barrier_nospec' [-Werror=implicit-function-declaration]
1914 | barrier_nospec();
| ^~~~~~~~~~~~~~cc1: some warnings being treated as errors
... so I'm going to send the patch as untested.
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Vladimir Oltean
maintainerRe: [PATCH net 3/3] net: mscc: ocelot: fix duplicate driver name error
Quoted 12 lines · Russell King (Oracle)
Quoted 7 lines · Vladimir Oltean
Quoted 3 lines · Russell King (Oracle)
I'll also send another patch to delete
linux/phylink.hfromocelot_ext.c- seems that wasn't removed when the phylink instance was removed during review.Good point. I suppose that would be on net-next, after the 6th of March? I just hope we'll remember by then.
Yep - however, I'm facing challenges to build-testing it at the moment as net-next is broken:
Quoted 11 lines
kernel/bpf/core.c: In function '___bpf_prog_run':kernel/bpf/core.c:1914:3: error: implicit declaration of function 'barrier_nospec' [-Werror=implicit-function-declaration]1914 | barrier_nospec(); | ^~~~~~~~~~~~~~cc1: some warnings being treated as errors
... so I'm going to send the patch as untested.
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
https://github.com/torvalds/linux/commit/f3dd0c53370e70c0f9b7e931bbec12916f3bb8cc
Can't deny it would be great to have this on net.git ASAP :)
Russell King (Oracle)
reviewerRe: [PATCH net 3/3] net: mscc: ocelot: fix duplicate driver name error
Quoted 21 lines · Vladimir Oltean
Quoted 20 lines · Russell King (Oracle)
Quoted 7 lines · Vladimir Oltean
Quoted 3 lines · Russell King (Oracle)
I'll also send another patch to delete
linux/phylink.hfromocelot_ext.c- seems that wasn't removed when the phylink instance was removed during review.Good point. I suppose that would be on net-next, after the 6th of March? I just hope we'll remember by then.
Yep - however, I'm facing challenges to build-testing it at the moment as net-next is broken:
kernel/bpf/core.c: In function '___bpf_prog_run':kernel/bpf/core.c:1914:3: error: implicit declaration of function 'barrier_nospec' [-Werror=implicit-function-declaration]1914 | barrier_nospec(); | ^~~~~~~~~~~~~~cc1: some warnings being treated as errors
... so I'm going to send the patch as untested.
Quoted 7 lines
Quoted 3 lines
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!https://github.com/torvalds/linux/commit/f3dd0c53370e70c0f9b7e931bbec12916f3bb8cc
Can't deny it would be great to have this on net.git ASAP :)
Agreed, and thanks for the patch, my build-test on net.git succeeded with that.
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH net 3/3] net: mscc: ocelot: fix duplicate driver name error
In reply to Vladimir OlteanQuoted 11 lines · Vladimir Oltean
When compiling a kernel which has both
CONFIG_NET_DSA_MSCC_OCELOT_EXTandCONFIG_MSCC_OCELOT_SWITCHenabled, the following error message will be printed:[ 5.266588] Error: Driver 'ocelot-switch' is already registered, aborting...Rename the
ocelot_ext.cdriver to "ocelot-ext-switch" to avoid the name duplication, and update themfd_cellentry for its resources.Fixes 3d7316ac81ac ("net: dsa: ocelot: add external ocelot switch control")Signed-off-by Vladimir Oltean <[email protected]>
Signature · 1 line
Florian
Re: [PATCH net 3/3] net: mscc: ocelot: fix duplicate driver name error
In reply to Vladimir OlteanQuoted 6 lines · Vladimir Oltean
When compiling a kernel which has both
CONFIG_NET_DSA_MSCC_OCELOT_EXTandCONFIG_MSCC_OCELOT_SWITCHenabled, the following error message will be printed:[ 5.266588] Error: Driver 'ocelot-switch' is already registered, aborting...
Quoted 7 lines
Rename the
ocelot_ext.cdriver to "ocelot-ext-switch" to avoid the name duplication, and update themfd_cellentry for its resources.Fixes 3d7316ac81ac ("net: dsa: ocelot: add external ocelot switch control")Signed-off-by Vladimir Oltean <[email protected]>--- drivers/mfd/ocelot-core.c | 2 +-
Quoted 32 lines
drivers/net/dsa/ocelot/ocelot_ext.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)drivers/mfd/ocelot-core.c +1
-1@@ -177,7 +177,7 @@ static const struct mfd_cell vsc7512_devs[] = { .num_resources = ARRAY_SIZE(vsc7512_miim1_resources), .resources = vsc7512_miim1_resources, }, { - .name = "ocelot-switch", + .name = "ocelot-ext-switch", .of_compatible = "mscc,vsc7512-switch", .num_resources = ARRAY_SIZE(vsc7512_switch_resources), .resources = vsc7512_switch_resources,drivers/net/dsa/ocelot/ocelot_ext.c +1
-1@@ -149,7 +149,7 @@ MODULE_DEVICE_TABLE(of, ocelot_ext_switch_of_match);static struct platform_driver ocelot_ext_switch_driver = { .driver = { - .name ="ocelot-switch" , + .name ="ocelot-ext-switch" , .of_match_table =of_match_ptr (ocelot_ext_switch_of_match), }, .probe = ocelot_ext_probe,Signature · 1 line
2.34.1
Signature · 1 line
Lee Jones [李琼斯]
Quoted 6 lines · On Fri, 24 Feb 2023 17:52:32 +0200 Vladimir Oltean wrote:
These are 3 patches which resolve a regression in the Seville driver, one in the Felix driver and a generic one which affects any kernel compiled with 2
Kconfigoptions enabled. All of them have in common my lack of attention during review/testing. The patches touch the DSA, MFD and MDIO drivers for Ocelot. I think it would be preferable if all patches went through netdev (with Lee's Ack).
Applied, thanks!