| Message ID | 20230309125421.3900962-6-lukma@denx.de (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | dsa: marvell: Add support for mv88e6071 and 6020 switches | expand |
On Thu, Mar 09, 2023 at 01:54:19PM +0100, Lukasz Majewski wrote: > This commit shall be regarded as a transition one, as this function helps > to validate the correctness of max_frame_size variable added to > mv88e6xxx_info structure. > > It is necessary to avoid regressions as manual assessment of this value > turned out to be error prone. > > Signed-off-by: Lukasz Majewski <lukma@denx.de> > Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Shouldn't this be patch 2 - immediately after populating the .max_frame_size members, and before adding any additional devices?
On Thu, Mar 09, 2023 at 01:21:13PM +0000, Russell King (Oracle) wrote: > On Thu, Mar 09, 2023 at 01:54:19PM +0100, Lukasz Majewski wrote: > > This commit shall be regarded as a transition one, as this function helps > > to validate the correctness of max_frame_size variable added to > > mv88e6xxx_info structure. > > > > It is necessary to avoid regressions as manual assessment of this value > > turned out to be error prone. > > > > Signed-off-by: Lukasz Majewski <lukma@denx.de> > > Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> > > Shouldn't this be patch 2 - immediately after populating the > .max_frame_size members, and before adding any additional devices? Moreover, shouldn't the patch order be: 1, 5, 6 (fixing the entry that needs it), 7 (which then gets the max frame size support in place), 4 (so that .set_max_frame_size for 6250 is in place), 2, 3 ? In other words, get the new infrastructure you need in place first (that being the new .max_frame_size and the .set_max_frame_size function) before then adding the new support.
Hi Russell, > On Thu, Mar 09, 2023 at 01:21:13PM +0000, Russell King (Oracle) wrote: > > On Thu, Mar 09, 2023 at 01:54:19PM +0100, Lukasz Majewski wrote: > > > This commit shall be regarded as a transition one, as this > > > function helps to validate the correctness of max_frame_size > > > variable added to mv88e6xxx_info structure. > > > > > > It is necessary to avoid regressions as manual assessment of this > > > value turned out to be error prone. > > > > > > Signed-off-by: Lukasz Majewski <lukma@denx.de> > > > Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> > > > > Shouldn't this be patch 2 - immediately after populating the > > .max_frame_size members, and before adding any additional devices? > > Moreover, shouldn't the patch order be: > > 1, 5, 6 (fixing the entry that needs it), 7 (which then gets the > max frame size support in place), 4 (so that .set_max_frame_size for > 6250 is in place), 2, 3 > > ? > > In other words, get the new infrastructure you need in place first > (that being the new .max_frame_size and the .set_max_frame_size > function) before then adding the new support. > Ok, I will reorder those patches and submit v6. Do you have any other comments regarding this patch set? Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On Thu, Mar 09, 2023 at 02:47:52PM +0100, Lukasz Majewski wrote: > Ok, I will reorder those patches and submit v6. > > Do you have any other comments regarding this patch set? Please allow for at least 24 hours between reposts. I would like to look at this patch set too, later today or tomorrow.
Hi Vladimir, > On Thu, Mar 09, 2023 at 02:47:52PM +0100, Lukasz Majewski wrote: > > Ok, I will reorder those patches and submit v6. > > > > Do you have any other comments regarding this patch set? > > Please allow for at least 24 hours between reposts. I would like to > look at this patch set too, later today or tomorrow. Ok. No problem. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 9695a1af45a9..af14eb8a1bfd 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -7169,6 +7169,27 @@ static int __maybe_unused mv88e6xxx_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(mv88e6xxx_pm_ops, mv88e6xxx_suspend, mv88e6xxx_resume); +static void mv88e6xxx_validate_frame_size(void) +{ + int max; + int i; + + for (i = 0; i < ARRAY_SIZE(mv88e6xxx_table); i++) { + /* same logic as in mv88e6xxx_get_max_mtu() */ + if (mv88e6xxx_table[i].ops->port_set_jumbo_size) + max = 10240; + else if (mv88e6xxx_table[i].ops->set_max_frame_size) + max = 1632; + else + max = 1522; + + if (mv88e6xxx_table[i].max_frame_size != max) + pr_err("BUG: %s has differing max_frame_size: %d != %d\n", + mv88e6xxx_table[i].name, max, + mv88e6xxx_table[i].max_frame_size); + } +} + static int mv88e6xxx_probe(struct mdio_device *mdiodev) { struct dsa_mv88e6xxx_pdata *pdata = mdiodev->dev.platform_data; @@ -7302,6 +7323,7 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev) if (err) goto out_mdio; + mv88e6xxx_validate_frame_size(); return 0; out_mdio:
This commit shall be regarded as a transition one, as this function helps to validate the correctness of max_frame_size variable added to mv88e6xxx_info structure. It is necessary to avoid regressions as manual assessment of this value turned out to be error prone. Signed-off-by: Lukasz Majewski <lukma@denx.de> Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> --- Changes for v5: - New patch --- drivers/net/dsa/mv88e6xxx/chip.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)