Messages in this thread | | | Date | Thu, 25 May 2023 16:31:40 +0300 | From | Vladimir Oltean <> | 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@gmail.com wrote: > > > From: Arınç ÜNAL <arinc.unal@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@arinc9.com> > > > Signed-off-by: Arınç ÜNAL <arinc.unal@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.
| |