netdev - Re: [PATCH net-next 25/30] net: dsa: mt7530: properly set MT7531_CPU

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: Sun, 4 Jun 2023 16:33:17 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Sean Wang <sean.wang@...iatek.com>, Landen Chao
 <Landen.Chao@...iatek.com>, DENG Qingfang <dqfext@...il.com>,
 Daniel Golle <daniel@...rotopia.org>, Andrew Lunn <andrew@...n.ch>,
 Florian Fainelli <f.fainelli@...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>,
 Russell King <linux@...linux.org.uk>,
 Richard van Schagen <richard@...terhints.com>,
 Richard van Schagen <vschagen@...com>,
 Frank Wunderlich <frank-w@...lic-files.de>,
 Bartel Eerdekens <bartel.eerdekens@...stell8.be>, erkin.bozoglu@...ont.com,
 mithat.guner@...ont.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 25/30] net: dsa: mt7530: properly set
 MT7531_CPU_PMAP

On 4.06.2023 16:08, Vladimir Oltean wrote:
> On Sun, Jun 04, 2023 at 11:21:48AM +0300, Arınç ÜNAL wrote:
>>> Stylistically, the existence of an indirect call to priv->info->cpu_port_config()
>>> per switch family is a bit dissonant with an explicit check for device id later
>>> in the same function.
>>
>> mt753x_cpu_port_enable() is not being called from priv->info->cpu_port_config()
>> though.
> 
> Quite the other way around. I'm saying that mt753x_cpu_port_enable(),
> the function whose logic you're changing, already has a mechanism to
> execute code specific to one switch family.

Ah, makes sense.

> 
>> I'm not sure how I would do this without the device ID check here.
> 
> Hmm, by defining a new mt7530_cpu_port_config() procedure for ID_MT7621
> and ID_MT7530?
> 
> Although in a different thread we are perhaps challenging the idea that
> what is currently in priv->info->cpu_port_config() is useful - at least
> half of it are manual invocations of phylink methods which are possibly
> not needed. If after the removal of those, it no longer makes sense to
> have priv->info->cpu_port_config() at all, then I'm not saying that the
> explicit check for device id here doesn't make sense. Just that it's not
> in harmony with what currently exists 3 lines above.

Regardless of the outcome of that conversation, I would like to avoid 
structural changes like this since this patch will go to net.

> 
>>>> -#define  MT7531_CPU_PMAP_MASK		GENMASK(7, 0)
>>>> +#define  MT7531_CPU_PMAP(x)		((x) & 0xff)
>>>
>>> You can leave this as ((x) & GENMASK(7, 0))
>>
>> Now that I've read Russell's comment on the previous patch, the below would
>> be even better?
>>
>> MT7531_CPU_PMAP(x)		FIELD_PREP(MT7531_CPU_PMAP_MASK, x)
>>
>>>
>>>> +#define  MT7531_CPU_PMAP_MASK		MT7531_CPU_PMAP(~0)
>>>
>>> There's no other user of MT7531_CPU_PMAP_MASK, you can remove this.
>>
>> Should I do above or remove this?
> 
> No specific preference. If you want to make this driver start using
> FIELD_PREP() then go ahead.

Will do.

Arınç