netdev - Re: [PATCH net-next 5/5] net: stmmac: stm32: Use syscon_regmap_lookup_by_phandle

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 for Android: free password hash cracker in your pocket

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

Message-ID: <e48f70bd-bb2b-4443-bb76-1b3511700043@linux.dev>
Date: Tue, 14 Jan 2025 09:58:08 +0800
From: Yanteng Si <si.yanteng@...ux.dev>
To: Andrew Lunn <andrew@...n.ch>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 MD Danish Anwar <danishanwar@...com>, Roger Quadros <rogerq@...nel.org>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Jose Abreu <joabreu@...opsys.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>, Shawn Guo
 <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, linux-arm-kernel@...ts.infradead.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com, imx@...ts.linux.dev
Subject: Re: [PATCH net-next 5/5] net: stmmac: stm32: Use
 syscon_regmap_lookup_by_phandle_args

在 2025/1/14 01:01, Andrew Lunn 写道:
> On Mon, Jan 13, 2025 at 04:05:13PM +0800, Yanteng Si wrote:
>> 在 2025/1/12 21:32, Krzysztof Kozlowski 写道:
>>> Use syscon_regmap_lookup_by_phandle_args() which is a wrapper over
>>> syscon_regmap_lookup_by_phandle() combined with getting the syscon
>>> argument.  Except simpler code this annotates within one line that given
>>> phandle has arguments, so grepping for code would be easier.
>>>
>>> There is also no real benefit in printing errors on missing syscon
>>> argument, because this is done just too late: runtime check on
>>> static/build-time data.  Dtschema and Devicetree bindings offer the
>>> static/build-time check for this already.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>> ---
>>>    drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 9 ++-------
>>>    1 file changed, 2 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>>> index 1e8bac665cc9bc95c3aa96e87a8e95d9c63ba8e1..1fcb74e9e3ffacdc7581b267febb55d015a83aed 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>>> @@ -419,16 +419,11 @@ static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
>>>    	}
>>>    	/* Get mode register */
>>> -	dwmac->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
>>> +	dwmac->regmap = syscon_regmap_lookup_by_phandle_args(np, "st,syscon",
>>> +							     1, &dwmac->mode_reg);
>> The network subsystem still requires that the length of
>> each line of code should not exceed 80 characters.
>> So, let's silence the warning:
>>
>> WARNING: line length of 83 exceeds 80 columns
>> #33: FILE: drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c:307:
>> +							     &dwmac->intf_reg_off);
> checkpatch should be considered a guide, not a strict conformance
> tool. You often need to look at its output and consider does what it
> suggest really make the code better? In this case, i would disagree
> with checkpatch and allow this code.
>
> If the code had all been on one long line, then i would suggest to
> wrap it. But as it is, it keeps with the spirit of 80 characters, even
> if it is technically not.
Oh, I got it! Thanks for explaining. You cleared up my confusion.

I made those comments based on my past experience. Actually, I
hesitated for ages before hitting the send button. I couldn't
figure out a better way other than refactoring the function.
I guess I might have come across as a bit unreasonable. But
now I understand the reasoning behind the ‘80 - character’
thing. I'll be more confident when dealing with this kind
of situation in the future.

Thanks，
Yanteng

> 	Andrew