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
| ||
|
Message-ID: <20230525133140.xewm6g5rl7sm57d2@skbuf> Date: Thu, 25 May 2023 16:31:40 +0300 From: Vladimir Oltean <olteanv@...il.com> To: Arınç ÜNAL <arinc.unal@...nc9.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 05/30] net: dsa: mt7530: read XTAL value from correct register On Thu, May 25, 2023 at 09:20:08AM +0300, Arınç ÜNAL wrote: > On 24.05.2023 19:57, Vladimir Oltean wrote: > > On Mon, May 22, 2023 at 03:15:07PM +0300, arinc9.unal@...il.com wrote: > > > From: Arınç ÜNAL <arinc.unal@...nc9.com> > > > > > > On commit 7ef6f6f8d237 ("net: dsa: mt7530: Add MT7621 TRGMII mode support") > > > macros for reading the crystal frequency were added under the MT7530_HWTRAP > > > register. However, the value given to the xtal variable on > > > mt7530_pad_clk_setup() is read from the MT7530_MHWTRAP register instead. > > > > > > Although the document MT7621 Giga Switch Programming Guide v0.3 states that > > > the value can be read from both registers, use the register where the > > > macros were defined under. > > > > > > Tested-by: Arınç ÜNAL <arinc.unal@...nc9.com> > > > Signed-off-by: Arınç ÜNAL <arinc.unal@...nc9.com> > > > --- > > > > I'm sorry, but I refuse this patch, mainly as a matter of principle - > > because that's just not how we do things, and you need to understand why. > > > > The commit title ("read XTAL value from correct register") claims that > > the process of reading a field which cannot be changed by software is > > any more correct when it is read from HWTRAP rather than MHWTRAP > > (modified HWTRAP). > > > > Your justification is that it's confusing to you if two registers have > > the same layout, and the driver has a single set of macros to decode the > > fields from both. You seem to think it's somehow not correct to decode > > fields from the MHWTRAP register using macros which have just HWTRAP in > > the name. > > No, it doesn't confuse me that two registers share the same layout. My > understanding was that the MHWTRAP register should be used for modifying the > hardware trap, and the HWTRAP register should be used for reading from the > hardware trap. My understanding is that reading from the read-only HWTRAP always gives you the power-on settings, while reading from the r/w MHWTRAP always gives you the current settings. If those settings coincide, as happens here, there's no practical difference. > I see that the XTAL constants were defined under the HWTRAP > register so I thought it would make sense to change the code to read the > XTAL values from the HWTRAP register instead. Let me know if you disagree > with this. I disagree as a matter of principle with the reasoning. The fact that XTAL constants are defined under HWTRAP is not a reason to change the code to read the XTAL values from the HWTRAP register. The fact that XTAL_FSEL is read-only in MHWTRAP is indeed a reason why you *could* read it from HWTRAP, but also not one why you *should* make a change. > > Seriously, please first share these small rewrites with someone more > > senior than you, and ask for a preliminary second opinion. > > Would submitting this as an RFC had been a similar action to your describing > here? Because I already did that: > > https://lore.kernel.org/netdev/20230421143648.87889-6-arinc.unal@arinc9.com/ In practice, volume is also an issue. The higher the volume, the lower the chances that people will be able to crop a chunk of time large enough to review. > I should've given more effort to explain my reasons for this patch. I > disagree that the series is a large volume of worthless and misguided > refactoring and am happy to discuss it patch by patch. I agree that the follow-up patches, as far as I could reach into this series, are not as gratuitous as this one.
Powered by blists - more mailing lists