drivers/net/ethernet/ti/icssg/icssg_config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
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(-)
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 */
--
2.34.1On 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 -- Thanks and Regards, Md Danish Anwar
> > 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
--
Thanks and Regards,
Md Danish Anwar
> 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
© 2016 - 2025 Red Hat, Inc.