| Message ID | 20231016161525.1695795-1-danishanwar@ti.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net,v2] net: ti: icssg-prueth: Fix r30 CMDs bitmasks | expand |
On Mon, Oct 16, 2023 at 09:45:25PM +0530, MD Danish Anwar wrote: > The bitmask for EMAC_PORT_DISABLE and EMAC_PORT_FORWARD has been changed > in the ICSSG firmware REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05. > > The current bitmasks are wrong and as a result EMAC_PORT_DISABLE and > EMAC_PORT_FORWARD commands doesn not work. > Update r30 commands to use the same bitmask as used by the ICSSG firmware > REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05. > > These bitmasks are not backwards compatible. This will work with > firmware version REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05 and above but > not with lower firmware versions. Breaking backwards compatibility is generally not allowed. As far as i understand the driver, it loads whatever version of firmware is available. It does not ask for a specific version. So you should ask the firmware what version it is, and then handle the bitmask as appropriate. How many different versions of REL.PRU-ICSS-ETHERNET-SWITCH have been released? They don't appear to be part of linux-firmware.git :-( Andrew --- pw-bot: cr
On 10/16/2023 9:58 PM, Andrew Lunn wrote: > On Mon, Oct 16, 2023 at 09:45:25PM +0530, MD Danish Anwar wrote: >> The bitmask for EMAC_PORT_DISABLE and EMAC_PORT_FORWARD has been changed >> in the ICSSG firmware REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05. >> >> The current bitmasks are wrong and as a result EMAC_PORT_DISABLE and >> EMAC_PORT_FORWARD commands doesn not work. >> Update r30 commands to use the same bitmask as used by the ICSSG firmware >> REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05. >> >> These bitmasks are not backwards compatible. This will work with >> firmware version REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05 and above but >> not with lower firmware versions. > > Breaking backwards compatibility is generally not allowed. > > As far as i understand the driver, it loads whatever version of > firmware is available. It does not ask for a specific version. So you > should ask the firmware what version it is, and then handle the > bitmask as appropriate. > Understood. I will try to find a way to do this at runtime. > How many different versions of REL.PRU-ICSS-ETHERNET-SWITCH have been > released? They don't appear to be part of linux-firmware.git :-( > The firmwares are currently not posted to linux-firmware.git. They are maintained internally as of now. Different version of firmware is released for every SDK release (3-4 times a year) > Andrew > > --- > pw-bot: cr
> > How many different versions of REL.PRU-ICSS-ETHERNET-SWITCH have been > > released? They don't appear to be part of linux-firmware.git :-( > > > > The firmwares are currently not posted to linux-firmware.git. They are > maintained internally as of now. Different version of firmware is > released for every SDK release (3-4 times a year) Clearly, mainline works differently. Ideally you do want to get the firmware in linux-firmware.git. The kernel and firmware are then more likely to by upgraded at the same time. However, you should not assume so. Maybe in mainline you can then support the last 4 firmware versions, and issue an error if a version older than that is found. However, until the firmware is easily available via linux-firmware, you probably should be backwards compatible for a longer period. Andrew
On 10/17/2023 12:09 AM, Andrew Lunn wrote: >>> How many different versions of REL.PRU-ICSS-ETHERNET-SWITCH have been >>> released? They don't appear to be part of linux-firmware.git :-( >>> >> >> The firmwares are currently not posted to linux-firmware.git. They are >> maintained internally as of now. Different version of firmware is >> released for every SDK release (3-4 times a year) > > Clearly, mainline works differently. Ideally you do want to get the > firmware in linux-firmware.git. The kernel and firmware are then more > likely to by upgraded at the same time. However, you should not assume Definitely, we are having discussions on this and soon we'll start pushing the ICSSG firmware to linux-firmware.git. Till then, we will maintain firmware internally only. > so. Maybe in mainline you can then support the last 4 firmware > versions, and issue an error if a version older than that is found. > > However, until the firmware is easily available via linux-firmware, > you probably should be backwards compatible for a longer period. > I understand that. I had discussion with the firmware team and this is actually not breaking backwards compatibility. The commands EMAC_PORT_DISABLE and EMAC_PORT_FORWARDING are actually wrong in the driver. Firmware is using below bitmasks since the beginning and they were wrong in the driver. This patch actually fixes this. {{0xffff0004, 0xffff0100, 0xffff0004, EMAC_NONE}},/* EMAC_PORT_DISABLE */ {{0xffbb0000, 0xfcff0000, 0xdcfb0000, EMAC_NONE}},/* EMAC_PORT_FORWARD */ I tested this patch with older firmware (Version REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.04) as well as newer firmware (Version REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05). With this patch both EMAC_PORT_DISABLE and EMAC_PORT_FORWARD commands are working with both older and newer firmwares. Apologies for wrong commit message. I will send next version with proper commit message mentioning that this patch is backwards compatible > Andrew
> Apologies for wrong commit message. I will send next version with proper > commit message mentioning that this patch is backwards compatible Great, thanks for looking into this. Andrew --- pw-bot: cr
diff --git a/drivers/net/ethernet/ti/icssg/icssg_config.c b/drivers/net/ethernet/ti/icssg/icssg_config.c index 933b84666574..b272361e378f 100644 --- a/drivers/net/ethernet/ti/icssg/icssg_config.c +++ b/drivers/net/ethernet/ti/icssg/icssg_config.c @@ -379,9 +379,9 @@ int icssg_config(struct prueth *prueth, struct prueth_emac *emac, int slice) /* Bitmask for ICSSG r30 commands */ static const struct icssg_r30_cmd emac_r32_bitmask[] = { - {{0xffff0004, 0xffff0100, 0xffff0100, EMAC_NONE}}, /* EMAC_PORT_DISABLE */ + {{0xffff0004, 0xffff0100, 0xffff0004, EMAC_NONE}}, /* EMAC_PORT_DISABLE */ {{0xfffb0040, 0xfeff0200, 0xfeff0200, EMAC_NONE}}, /* EMAC_PORT_BLOCK */ - {{0xffbb0000, 0xfcff0000, 0xdcff0000, EMAC_NONE}}, /* EMAC_PORT_FORWARD */ + {{0xffbb0000, 0xfcff0000, 0xdcfb0000, EMAC_NONE}}, /* EMAC_PORT_FORWARD */ {{0xffbb0000, 0xfcff0000, 0xfcff2000, EMAC_NONE}}, /* EMAC_PORT_FORWARD_WO_LEARNING */ {{0xffff0001, EMAC_NONE, EMAC_NONE, EMAC_NONE}}, /* ACCEPT ALL */ {{0xfffe0002, EMAC_NONE, EMAC_NONE, EMAC_NONE}}, /* ACCEPT TAGGED */
The bitmask for EMAC_PORT_DISABLE and EMAC_PORT_FORWARD has been changed in the ICSSG firmware REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05. The current bitmasks are wrong and as a result EMAC_PORT_DISABLE and EMAC_PORT_FORWARD commands doesn not work. Update r30 commands to use the same bitmask as used by the ICSSG firmware REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05. These bitmasks are not backwards compatible. This will work with firmware version REL.PRU-ICSS-ETHERNET-SWITCH_02.02.12.05 and above but not with lower firmware versions. Fixes: e9b4ece7d74b ("net: ti: icssg-prueth: Add Firmware config and classification APIs.") Signed-off-by: MD Danish Anwar <danishanwar@ti.com> --- Cc: Andrew Lunn <andrew@lunn.ch> Cc: Ravi Gunasekaran <r-gunasekaran@ti.com> Changes from v1 to v2: *) Added firmware version in commit message as asked by Ravi. *) Mentioned in commit message that the patch is not backwards compatible as asked by Andrew. v1: https://lore.kernel.org/all/20231013111758.213769-1-danishanwar@ti.com/ drivers/net/ethernet/ti/icssg/icssg_config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)