linux-kernel - Re: [PATCH net-next] net: ethernet: mediatek: Allow gaps in MAC allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 02 Jul 2024 09:05:19 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: linux-mediatek@...ts.infradead.org,
 Przemek Kitszel <przemyslaw.kitszel@...el.com>,
 Elad Yifee <eladwf@...il.com>
CC: Felix Fietkau <nbd@....name>, Sean Wang <sean.wang@...iatek.com>,
 Mark Lee <Mark-MC.Lee@...iatek.com>, Lorenzo Bianconi <lorenzo@...nel.org>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net-next] net: ethernet: mediatek: Allow gaps in MAC allocation

On 2 July 2024 06:58:22 UTC, Przemek Kitszel <przemyslaw.kitszel@...el.com> wrote:
>On 7/1/24 21:28, Daniel Golle wrote:
>> Some devices with MediaTek SoCs don't use the first but only the second
>> MAC in the chip. Especially with MT7981 which got a built-in 1GE PHY
>> connected to the second MAC this is quite common.
>> Make sure to reset and enable PSE also in those cases by skipping gaps
>> using 'continue' instead of aborting the loop using 'break'.
>> 
>> Fixes: dee4dd10c79a ("net: ethernet: mtk_eth_soc: ppe: add support for multiple PPEs")
>> Suggested-by: Elad Yifee <eladwf@...il.com>
>> Signed-off-by: Daniel Golle <daniel@...rotopia.org>
>> ---
>> Note that this should go to 'net-next' because the commit being fixed
>> isn't yet part of the 'net' tree.
>
>makes sense, and the fix is correct, so:
>Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>

Thank you the fast review!

>what about:
>4733│ static int mtk_sgmii_init(struct mtk_eth *eth)
>4734│ {
>4735│         struct device_node *np;
>4736│         struct regmap *regmap;
>4737│         u32 flags;
>4738│         int i;
>4739│
>4740│         for (i = 0; i < MTK_MAX_DEVS; i++) {
>4741│                 np = of_parse_phandle(eth->dev->of_node, "mediatek,sgmiisys", i);
>4742│                 if (!np)
>4743│                         break;
>
>should we also continue here?

Good point. As sgmiisys is defined in dtsi it's not so relevant in practise though, as the SoC components are of course always present even if we don't use them. Probably it is still better to not be overly strict on the presence of things we may not even use, not even emit an error message and silently break something else, so yes, worth fixing imho.

>
>4744│
>4745│                 regmap = syscon_node_to_regmap(np);
>4746│                 flags = 0;
>4747│                 if (of_property_read_bool(np, "mediatek,pnswap"))
>4748│                         flags |= MTK_SGMII_FLAG_PN_SWAP;
>4749│
>4750│                 of_node_put(np);
>4751│
>4752│                 if (IS_ERR(regmap))
>4753│                         return PTR_ERR(regmap);
>4754│
>4755│                 eth->sgmii_pcs[i] = mtk_pcs_lynxi_create(eth->dev, regmap,
>4756│ eth->soc->ana_rgc3,
>4757│                                                          flags);
>4758│         }
>4759│
>4760│         return 0;
>4761│ }
>
>