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: Mon, 8 Jan 2024 13:22:18 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Simon Horman <horms@...nel.org>
Cc: Daniel Golle <daniel@...rotopia.org>,
 Landen Chao <Landen.Chao@...iatek.com>, DENG Qingfang <dqfext@...il.com>,
 Sean Wang <sean.wang@...iatek.com>, Andrew Lunn <andrew@...n.ch>,
 Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean
 <olteanv@...il.com>, "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>,
 David Bauer <mail@...id-bauer.net>, mithat.guner@...ont.com,
 erkin.bozoglu@...ont.com, Luiz Angelo Daros de Luca <luizluca@...il.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH net-next] net: dsa: mt7530: support OF-based registration
 of switch MDIO bus

On 7.01.2024 22:52, Simon Horman wrote:
> On Sat, Jan 06, 2024 at 03:21:42PM +0300, Arınç ÜNAL wrote:
>> From: David Bauer <mail@...id-bauer.net>
>>
>> Currently the MDIO bus of the switches the MT7530 DSA subdriver controls
>> can only be registered as non-OF-based. Bring support for registering the
>> bus OF-based.
>>
>> The subdrivers that control switches [with MDIO bus] probed on OF must
>> follow this logic to support all cases properly:
>>
>> No switch MDIO bus defined: Populate ds->user_mii_bus, register the MDIO
>> bus, set the interrupts for PHYs if "interrupt-controller" is defined at
>> the switch node. This case should only be covered for the switches which
>> their dt-bindings documentation didn't document the MDIO bus from the
>> start. This is to keep supporting the device trees that do not describe the
>> MDIO bus on the device tree but the MDIO bus is being used nonetheless.
>>
>> Switch MDIO bus defined: Don't populate ds->user_mii_bus, register the MDIO
>> bus, set the interrupts for PHYs if ["interrupt-controller" is defined at
>> the switch node and "interrupts" is defined at the PHY nodes under the
>> switch MDIO bus node].
>>
>> Switch MDIO bus defined but explicitly disabled: If the device tree says
>> status = "disabled" for the MDIO bus, we shouldn't need an MDIO bus at all.
>> Instead, just exit as early as possible and do not call any MDIO API.
>>
>> The use of ds->user_mii_bus is inappropriate when the MDIO bus of the
>> switch is described on the device tree [1], which is why we don't populate
>> ds->user_mii_bus in that case.
>>
>> Link: https://lore.kernel.org/netdev/20231213120656.x46fyad6ls7sqyzv@skbuf/ [1]
>> Suggested-by: David Bauer <mail@...id-bauer.net>
>> Signed-off-by: Arınç ÜNAL <arinc.unal@...nc9.com>
>> ---
>>   drivers/net/dsa/mt7530.c | 18 ++++++++++++++----
>>   1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
>> index 391c4dbdff42..39d7e7ad7154 100644
>> --- a/drivers/net/dsa/mt7530.c
>> +++ b/drivers/net/dsa/mt7530.c
>> @@ -2153,17 +2153,25 @@ mt7530_free_irq(struct mt7530_priv *priv)
>>   static int
>>   mt7530_setup_mdio(struct mt7530_priv *priv)
>>   {
>> +	struct device_node *mnp, *np = priv->dev->of_node;
>>   	struct dsa_switch *ds = priv->ds;
>>   	struct device *dev = priv->dev;
>>   	struct mii_bus *bus;
>>   	static int idx;
>> -	int ret;
>> +	int ret = 0;
>> +
>> +	mnp = of_get_child_by_name(np, "mdio");
>> +
>> +	if (mnp && !of_device_is_available(mnp))
>> +		goto out;
> 
> nit: I think it would easier on the eyes to simply
> 
> 		return 0;

Will do.

Thanks.
Arınç

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ