The LAN8720Ai has special bit (12) in the PHY SPECIAL
CONTROL/STATUS REGISTER (dec 31) to indicate if the
AutoNeg is finished.
Signed-off-by: Lukasz Majewski <[email protected]>
---
drivers/net/phy/smsc.c | 8 ++++++++
include/linux/smscphy.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index ac7481ce2fc1..58e5f06ef453 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -83,6 +83,13 @@ static int smsc_phy_config_intr(struct phy_device *phydev)
return rc < 0 ? rc : 0;
}
+static int smsc_phy_aneg_done(struct phy_device *phydev)
+{
+ int rc = phy_read(phydev, MII_LAN83C185_PHY_CTRL_STS);
+
+ return rc & MII_LAN87XX_AUTODONE;
+}
+
static irqreturn_t smsc_phy_handle_interrupt(struct phy_device *phydev)
{
struct smsc_phy_priv *priv = phydev->priv;
@@ -416,6 +423,7 @@ static struct phy_driver smsc_phy_driver[] = {
.config_init = smsc_phy_config_init,
.soft_reset = smsc_phy_reset,
.config_aneg = lan95xx_config_aneg_ext,
+ .aneg_done = smsc_phy_aneg_done,
/* IRQ related */
.config_intr = smsc_phy_config_intr,
diff --git a/include/linux/smscphy.h b/include/linux/smscphy.h
index 1a136271ba6a..0debebe999d6 100644
--- a/include/linux/smscphy.h
+++ b/include/linux/smscphy.h
@@ -4,6 +4,7 @@
#define MII_LAN83C185_ISF 29 /* Interrupt Source Flags */
#define MII_LAN83C185_IM 30 /* Interrupt Mask */
+#define MII_LAN83C185_PHY_CTRL_STS 31 /* PHY Special Control/Status Register */
#define MII_LAN83C185_CTRL_STATUS 17 /* Mode/Status Register */
#define MII_LAN83C185_SPECIAL_MODES 18 /* Special Modes Register */
@@ -22,6 +23,7 @@
MII_LAN83C185_ISF_INT7)
#define MII_LAN83C185_EDPWRDOWN (1 << 13) /* EDPWRDOWN */
+#define MII_LAN87XX_AUTODONE (1 << 12) /* AUTODONE */
#define MII_LAN83C185_ENERGYON (1 << 1) /* ENERGYON */
#define MII_LAN83C185_MODE_MASK 0xE0
--
2.20.1
On Thu, Apr 06, 2023 at 03:11:27PM +0200, Lukasz Majewski wrote:
> The LAN8720Ai has special bit (12) in the PHY SPECIAL
> CONTROL/STATUS REGISTER (dec 31) to indicate if the
> AutoNeg is finished.
>
> Signed-off-by: Lukasz Majewski <[email protected]>
Hi Lukasz,
I think you need to rebase this on net-next.
If you repost please also include 'net-next' in the subject:
[PATCH net-next v2].
And a note about the changes between v1 and v2.
On Thu, Apr 06, 2023 at 03:48:43PM +0200, Simon Horman wrote:
> On Thu, Apr 06, 2023 at 03:11:27PM +0200, Lukasz Majewski wrote:
> > The LAN8720Ai has special bit (12) in the PHY SPECIAL
> > CONTROL/STATUS REGISTER (dec 31) to indicate if the
> > AutoNeg is finished.
> >
> > Signed-off-by: Lukasz Majewski <[email protected]>
>
> Hi Lukasz,
>
> I think you need to rebase this on net-next.
>
> If you repost please also include 'net-next' in the subject:
> [PATCH net-next v2].
>
> And a note about the changes between v1 and v2.
This actually seems like a fix. So it should probably be based on net,
and have a Fixes: tag.
Lukasz, how does this bit differ to the one in BMSR? Is the BMSR bit
broken? Is there an errata for this? It would be good to describe the
problem you see which this patch fixes.
Andrew
Hi Andrew,
> On Thu, Apr 06, 2023 at 03:48:43PM +0200, Simon Horman wrote:
> > On Thu, Apr 06, 2023 at 03:11:27PM +0200, Lukasz Majewski wrote:
> > > The LAN8720Ai has special bit (12) in the PHY SPECIAL
> > > CONTROL/STATUS REGISTER (dec 31) to indicate if the
> > > AutoNeg is finished.
> > >
> > > Signed-off-by: Lukasz Majewski <[email protected]>
> >
> > Hi Lukasz,
> >
> > I think you need to rebase this on net-next.
> >
> > If you repost please also include 'net-next' in the subject:
> > [PATCH net-next v2].
> >
> > And a note about the changes between v1 and v2.
>
> This actually seems like a fix. So it should probably be based on net,
> and have a Fixes: tag.
I've rebased it on the newest vanila kernel.
And this patch come from the work on LAN8720Ai based system (speed up
of the boot time).
It turned out that this IC has a dedicated bit (in vendor specific
register) to show explicitly if auto neg is done.
>
> Lukasz, how does this bit differ to the one in BMSR?
In the BMSR - bit 5 (Auto Negotiate Complete) - shows the same kind of
information.
The only difference is that this bit is described as "Auto
Negotiate Complete" and the bit in this patch indicates "Auto
Negotiation Done".
> Is the BMSR bit
> broken?
This bit works as expected.
> Is there an errata for this?
No, errata doesn't mention it.
I just was wondering if shall we do use the "vendor specific"
indication bit or the "standard one" from BMSR register.
I try to figure out why SMSC put bit from this patch in the SoC...
> It would be good to describe the
> problem you see which this patch fixes.
>
> Andrew
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: [email protected]
> > This actually seems like a fix. So it should probably be based on net,
> > and have a Fixes: tag.
>
> I've rebased it on the newest vanila kernel.
Please see the netdev FAQ. It talks about the two git trees used for
networking.
> It turned out that this IC has a dedicated bit (in vendor specific
> register) to show explicitly if auto neg is done.
>
> >
> > Lukasz, how does this bit differ to the one in BMSR?
>
> In the BMSR - bit 5 (Auto Negotiate Complete) - shows the same kind of
> information.
>
> The only difference is that this bit is described as "Auto
> Negotiate Complete" and the bit in this patch indicates "Auto
> Negotiation Done".
>
> > Is the BMSR bit
> > broken?
>
> This bit works as expected.
I would avoid the vendor bit, if it has no benefit. A lot of
developers understand the BMSR bit, where as very few know this vendor
bit. BMSR can probably be handled with generic code, where as the
vendor bit requires vendor specific code etc.
Andrew
On Thu, Apr 06, 2023 at 03:11:27PM +0200, Lukasz Majewski wrote:
> The LAN8720Ai has special bit (12) in the PHY SPECIAL
> CONTROL/STATUS REGISTER (dec 31) to indicate if the
> AutoNeg is finished.
>
> Signed-off-by: Lukasz Majewski <[email protected]>
> ---
> drivers/net/phy/smsc.c | 8 ++++++++
> include/linux/smscphy.h | 2 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
> index ac7481ce2fc1..58e5f06ef453 100644
> --- a/drivers/net/phy/smsc.c
> +++ b/drivers/net/phy/smsc.c
> @@ -83,6 +83,13 @@ static int smsc_phy_config_intr(struct phy_device *phydev)
> return rc < 0 ? rc : 0;
> }
>
> +static int smsc_phy_aneg_done(struct phy_device *phydev)
> +{
> + int rc = phy_read(phydev, MII_LAN83C185_PHY_CTRL_STS);
> +
> + return rc & MII_LAN87XX_AUTODONE;
> +}
> +
> static irqreturn_t smsc_phy_handle_interrupt(struct phy_device *phydev)
> {
> struct smsc_phy_priv *priv = phydev->priv;
> @@ -416,6 +423,7 @@ static struct phy_driver smsc_phy_driver[] = {
> .config_init = smsc_phy_config_init,
> .soft_reset = smsc_phy_reset,
> .config_aneg = lan95xx_config_aneg_ext,
> + .aneg_done = smsc_phy_aneg_done,
>
> /* IRQ related */
> .config_intr = smsc_phy_config_intr,
> diff --git a/include/linux/smscphy.h b/include/linux/smscphy.h
> index 1a136271ba6a..0debebe999d6 100644
> --- a/include/linux/smscphy.h
> +++ b/include/linux/smscphy.h
> @@ -4,6 +4,7 @@
>
> #define MII_LAN83C185_ISF 29 /* Interrupt Source Flags */
> #define MII_LAN83C185_IM 30 /* Interrupt Mask */
> +#define MII_LAN83C185_PHY_CTRL_STS 31 /* PHY Special Control/Status Register */
Looks like this is a new register.
> #define MII_LAN83C185_CTRL_STATUS 17 /* Mode/Status Register */
> #define MII_LAN83C185_SPECIAL_MODES 18 /* Special Modes Register */
>
> @@ -22,6 +23,7 @@
> MII_LAN83C185_ISF_INT7)
>
> #define MII_LAN83C185_EDPWRDOWN (1 << 13) /* EDPWRDOWN */
> +#define MII_LAN87XX_AUTODONE (1 << 12) /* AUTODONE */
Is this somehow related to the two definitions either side of it? How
do we know which register this definition corresponds to? In fact,
how do we know which registers any of these bits correspond with?
Bunging new definitions for new registers amongst other definitions
for other registers isn't particularly helpful when someone who
doesn't know the driver has to look at the code.
> #define MII_LAN83C185_ENERGYON (1 << 1) /* ENERGYON */
>
> #define MII_LAN83C185_MODE_MASK 0xE0
> --
> 2.20.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Hi Andrew,
> > > This actually seems like a fix. So it should probably be based on
> > > net, and have a Fixes: tag.
> >
> > I've rebased it on the newest vanila kernel.
>
> Please see the netdev FAQ. It talks about the two git trees used for
> networking.
Thanks for the information.
>
> > It turned out that this IC has a dedicated bit (in vendor specific
> > register) to show explicitly if auto neg is done.
> >
> > >
> > > Lukasz, how does this bit differ to the one in BMSR?
> >
> > In the BMSR - bit 5 (Auto Negotiate Complete) - shows the same kind
> > of information.
> >
> > The only difference is that this bit is described as "Auto
> > Negotiate Complete" and the bit in this patch indicates "Auto
> > Negotiation Done".
> >
> > > Is the BMSR bit
> > > broken?
> >
> > This bit works as expected.
>
> I would avoid the vendor bit, if it has no benefit. A lot of
> developers understand the BMSR bit, where as very few know this vendor
> bit. BMSR can probably be handled with generic code, where as the
> vendor bit requires vendor specific code etc.
Ok. Then, this patch shall be dropped. Thanks for the clarification :)
>
> Andrew
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: [email protected]