All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Wahren <wahrenst@gmx.net>
To: Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	Woojung Huh <woojung.huh@microchip.com>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Daniel Wagner <dwagner@suse.de>,
	netdev@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
	linux-arm-kernel@lists.infradead.org,
	linux-rpi-kernel@lists.infradead.org
Subject: Re: lan78xx and phy_state_machine
Date: Wed, 16 Oct 2019 07:48:00 +0200	[thread overview]
Message-ID: <4b160706-97a4-1fd8-9ddb-00a81d0cd6bb@gmx.net> (raw)
In-Reply-To: <524267e6-df8e-d884-aeef-1ed8700e4e58@gmail.com>

Am 15.10.19 um 21:38 schrieb Heiner Kallweit:
> On 15.10.2019 00:12, Russell King - ARM Linux admin wrote:
>> On Mon, Oct 14, 2019 at 10:20:15PM +0200, Heiner Kallweit wrote:
>>> On 14.10.2019 21:51, Stefan Wahren wrote:
>>>> [add more recipients]
>>>>
>>>> Am 14.10.19 um 21:25 schrieb Daniel Wagner:
>>>>> Moving the phy_prepare_link() up in phy_connect_direct() ensures that
>>>>> phydev->adjust_link is set when the phy_check_link_status() is called.
>>>>>
>>>>> diff --git a/drivers/net/phy/phy_device.c
>>>>> b/drivers/net/phy/phy_device.c index 9d2bbb13293e..2a61812bcb0d 100644
>>>>> --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c
>>>>> @@ -951,11 +951,12 @@ int phy_connect_direct(struct net_device *dev,
>>>>> struct phy_device *phydev, if (!dev) return -EINVAL;
>>>>>
>>>>> +       phy_prepare_link(phydev, handler);
>>>>> +
>>>>>         rc = phy_attach_direct(dev, phydev, phydev->dev_flags, interface);
>>>>>         if (rc)
>>> If phy_attach_direct() fails we may have to reset phydev->adjust_link to NULL,
>>> as we do in phy_disconnect(). Apart from that change looks good to me.
>> Sorry, but it doesn't look good to me.
>>
>> I think there's a deeper question here - why is the phy state machine
>> trying to call the link change function during attach?
> After your comment I had a closer look at the lm78xx driver and few things
> look suspicious:
>
> - lan78xx_phy_init() (incl. the call to phy_connect_direct()) is called
>   after register_netdev(). This may cause races.
>
> - The following is wrong, irq = 0 doesn't mean polling.
>   PHY_POLL is defined as -1. Also in case of irq = 0 phy_interrupt_is_valid()
>   returns true.
>
> 	/* if phyirq is not set, use polling mode in phylib */
> 	if (dev->domain_data.phyirq > 0)
> 		phydev->irq = dev->domain_data.phyirq;
> 	else
> 		phydev->irq = 0;
>
> - Manually calling genphy_config_aneg() in lan78xx_phy_init() isn't
>   needed, however this should not cause our problem.
Thanks for this review. This may help to fix at least a one of all the
other issues with lan78xx.

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Wahren <wahrenst@gmx.net>
To: Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	Woojung Huh <woojung.huh@microchip.com>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Daniel Wagner <dwagner@suse.de>,
	netdev@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: lan78xx and phy_state_machine
Date: Wed, 16 Oct 2019 07:48:00 +0200	[thread overview]
Message-ID: <4b160706-97a4-1fd8-9ddb-00a81d0cd6bb@gmx.net> (raw)
In-Reply-To: <524267e6-df8e-d884-aeef-1ed8700e4e58@gmail.com>

Am 15.10.19 um 21:38 schrieb Heiner Kallweit:
> On 15.10.2019 00:12, Russell King - ARM Linux admin wrote:
>> On Mon, Oct 14, 2019 at 10:20:15PM +0200, Heiner Kallweit wrote:
>>> On 14.10.2019 21:51, Stefan Wahren wrote:
>>>> [add more recipients]
>>>>
>>>> Am 14.10.19 um 21:25 schrieb Daniel Wagner:
>>>>> Moving the phy_prepare_link() up in phy_connect_direct() ensures that
>>>>> phydev->adjust_link is set when the phy_check_link_status() is called.
>>>>>
>>>>> diff --git a/drivers/net/phy/phy_device.c
>>>>> b/drivers/net/phy/phy_device.c index 9d2bbb13293e..2a61812bcb0d 100644
>>>>> --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c
>>>>> @@ -951,11 +951,12 @@ int phy_connect_direct(struct net_device *dev,
>>>>> struct phy_device *phydev, if (!dev) return -EINVAL;
>>>>>
>>>>> +       phy_prepare_link(phydev, handler);
>>>>> +
>>>>>         rc = phy_attach_direct(dev, phydev, phydev->dev_flags, interface);
>>>>>         if (rc)
>>> If phy_attach_direct() fails we may have to reset phydev->adjust_link to NULL,
>>> as we do in phy_disconnect(). Apart from that change looks good to me.
>> Sorry, but it doesn't look good to me.
>>
>> I think there's a deeper question here - why is the phy state machine
>> trying to call the link change function during attach?
> After your comment I had a closer look at the lm78xx driver and few things
> look suspicious:
>
> - lan78xx_phy_init() (incl. the call to phy_connect_direct()) is called
>   after register_netdev(). This may cause races.
>
> - The following is wrong, irq = 0 doesn't mean polling.
>   PHY_POLL is defined as -1. Also in case of irq = 0 phy_interrupt_is_valid()
>   returns true.
>
> 	/* if phyirq is not set, use polling mode in phylib */
> 	if (dev->domain_data.phyirq > 0)
> 		phydev->irq = dev->domain_data.phyirq;
> 	else
> 		phydev->irq = 0;
>
> - Manually calling genphy_config_aneg() in lan78xx_phy_init() isn't
>   needed, however this should not cause our problem.
Thanks for this review. This may help to fix at least a one of all the
other issues with lan78xx.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-10-16  5:49 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-14 14:06 lan78xx and phy_state_machine Daniel Wagner
2019-10-14 14:32 ` Daniel Wagner
2019-10-14 18:15   ` Stefan Wahren
2019-10-14 19:28     ` Daniel Wagner
2019-10-14 16:30 ` Russell King - ARM Linux admin
2019-10-14 19:25   ` Daniel Wagner
2019-10-14 19:51     ` Stefan Wahren
2019-10-14 19:51       ` Stefan Wahren
2019-10-14 20:20       ` Heiner Kallweit
2019-10-14 20:20         ` Heiner Kallweit
2019-10-14 22:12         ` Russell King - ARM Linux admin
2019-10-14 22:12           ` Russell King - ARM Linux admin
2019-10-15 19:38           ` Heiner Kallweit
2019-10-15 19:38             ` Heiner Kallweit
2019-10-15 22:09             ` Russell King - ARM Linux admin
2019-10-15 22:09               ` Russell King - ARM Linux admin
2019-10-16 15:36               ` Andrew Lunn
2019-10-16 15:36                 ` Andrew Lunn
2019-10-16  5:48             ` Stefan Wahren [this message]
2019-10-16  5:48               ` Stefan Wahren
2019-10-15  0:14   ` Andrew Lunn
2019-10-14 23:53 ` Andrew Lunn
2019-10-15  0:53 ` Andrew Lunn
2019-10-15 17:16   ` Daniel Wagner
2019-10-15 17:16     ` Daniel Wagner
2019-10-16 14:25     ` Daniel Wagner
2019-10-16 14:25       ` Daniel Wagner
2019-10-16 15:51       ` Andrew Lunn
2019-10-16 15:51         ` Andrew Lunn
2019-10-17  6:52         ` Daniel Wagner
2019-10-17  6:52           ` Daniel Wagner
2019-10-17 13:15           ` Andrew Lunn
2019-10-17 13:15             ` Andrew Lunn
2019-10-17 17:05           ` Stefan Wahren
2019-10-17 17:05             ` Stefan Wahren
2019-10-17 17:41             ` Daniel Wagner
2019-10-17 17:41               ` Daniel Wagner
2019-10-17 17:52               ` Stefan Wahren
2019-10-17 17:52                 ` Stefan Wahren
2019-10-17 18:14                 ` Daniel Wagner
2019-10-17 18:14                   ` Daniel Wagner
2019-10-17 18:25                 ` Andrew Lunn
2019-10-17 18:25                   ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b160706-97a4-1fd8-9ddb-00a81d0cd6bb@gmx.net \
    --to=wahrenst@gmx.net \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=dwagner@suse.de \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=woojung.huh@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.