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]
Message-ID: <C24C4687-1C00-434D-8C37-BDB85E39456C@makrotopia.org>
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│ }
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ