Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Message-ID: <65671a75.050a0220.53874.4dd1@mx.google.com>
Date:   Wed, 29 Nov 2023 12:03:14 +0100
From:   Christian Marangi <ansuelsmth@gmail.com>
To:     "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        linux-arm-msm@vger.kernel.org
Subject: Re: [net-next PATCH 02/14] net: phy: at803x: move disable WOL for
 8031 from probe to config
References: <20231129021219.20914-1-ansuelsmth@gmail.com>
 <20231129021219.20914-3-ansuelsmth@gmail.com>
 <ZWcDUJY8rM6uApO1@shell.armlinux.org.uk>
 <65670622.050a0220.4c0d0.3ee9@mx.google.com>
 <ZWcWN4kRRPBA9ZG6@shell.armlinux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZWcWN4kRRPBA9ZG6@shell.armlinux.org.uk>
Precedence: bulk

On Wed, Nov 29, 2023 at 10:45:11AM +0000, Russell King (Oracle) wrote:
> On Wed, Nov 29, 2023 at 10:36:31AM +0100, Christian Marangi wrote:
> > On Wed, Nov 29, 2023 at 09:24:32AM +0000, Russell King (Oracle) wrote:
> > > On Wed, Nov 29, 2023 at 03:12:07AM +0100, Christian Marangi wrote:
> > > > Probe should be used only for DT parsing and allocate required priv, it
> > > > shouldn't touch regs, there is config_init for that.
> > > 
> > > I'm not sure where you get that idea from. PHY driver probe() functions
> > > are permitted to access registers to do any setup that they wish to.
> > > 
> > > config_init() is to configure the PHY for use with the network
> > > interface.
> > > 
> > > I think this patch is just noise rather than a cleanup.
> > >
> > 
> > I got it from here [1]
> > 
> > Also on every other driver probe was always used for allocation and
> > parsing so why deviates from this pattern here?
> 
> Untrue.
> 
> bcm54140_enable_monitoring() is called from bcm54140_probe_once()
> which in turn is called from bcm54140_probe().
> 
> dp83869_probe() calls dp83869_config_init(), rightly or wrongly.
> 
> lxt973_probe() fixes up the BMCR.
> 
> mv3310_probe() configures power-down modes, modifying registers.
> 
> mt7988_phy_probe() calls mt7988_phy_fix_leds_polarities() which
> modifies registers.
> 
> lan8814_probe() calls lan8814_ptp_init() which does a whole load of
> register writes.
> 
> lan88xx_probe() configures LEDs via register writes.
> 
> yt8521_probe() configures clocks via register modification.
> 
> I'm afraid this means your comment is demonstrably false.
>

Don't want to start a discussion and thanks a lot for pointing this
out. This is really to talk about this and not contradict you.

Yes it's not true, and I was wrong but still I watch other driver
outside PHY and normally probe should not do that kind of stuff.
(even the comments describing the use in phy.h doesn't say that it
should be used for configuring the PHY only once on discovery)

Watching some of the thing, I feel all of this is done in probe as it's
not called again on software reset (as it will call config_init again).

This looks like there is a missing feature here and maybe a chance to
improve this?

Wonder if adding an additional OP would be beneficial to this?
Was thinking to something like

.config_once ?

And add some comments that it's called only on PHY discovery?
It would be put right after the probe call in phy_core.

> > Also I think it was wrong from the start as on reset I think WoL is
> > not disabled again. (probe is not called)
> 
> On hardware reset, the 1588 register will re-enable the WoL pin, but
> that needs a hardware reset of the PHY to happen after probe() is
> called.
> 
> However, phy_probe() will only assert the reset signal _if_ an error
> occured during probing, not if probing was successful. So, a successful
> probe of this driver will not cause a hardware reset.
> 
> Also, hardware reset is optional. Do you know whether the platforms
> that use the separate WoL pin which this 1588 register controls also
> wire the reset signal such that it can be controlled by Linux?
> Probably not.
> 
> So, this register write will not be cleared by a hardware reset after
> a successful probe.
>

I just checked Datasheet, on HW reset it's enabled again and on SW reset
value is retained. So yes it must stay in probe as it will cause side
effect if WoL get enabled after... Really hope the config_once thing is
OK since it will make things much cleaner.

-- 
	Ansuel