[PATCH net-next 05/30] net: dsa: mt7530: read XTAL value from correct register

[Vladimir Oltean]

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 at gmail.com wrote:
> > > From: Arınç ÜNAL <arinc.unal at arinc9.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 at arinc9.com>
> > > Signed-off-by: Arınç ÜNAL <arinc.unal at arinc9.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.