On Mon, 2021-11-29 at 15:16 +0100, Ferry Toth wrote:
Hi,
Op 29-11-2021 om 13:08 schreef Martyn Welch:
quoted
On Sat, 2021-11-27 at 18:48 +0100, Ferry Toth wrote:
quoted
The patch introduces a new error on each unplug:
usb 1-1: USB disconnect, device number 2
usb 1-1.1: USB disconnect, device number 3
smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-xhci-hcd.1.auto-
1.1,
smsc95xx USB 2.0 Ethernet
smsc95xx 1-1.1:1.0 eth0: Link is Down
smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -19
smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -19
smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Agh! Somehow missed that. I'm looking into it...
That would be great!
They appear as a result of phy_disconnect() being called in unbind()
when the hardware has already been disconnected (which is kinda likely
to physically be the case with USB devices...). The PHY is not going to
be accessible, but such calls *are* needed for instances where we are
unbinding without the device having been physically removed and want to
put the device in a suitable state. Failing with -ENODEV (as it
currently does) seems to be the right thing to do.
I wonder whether removing some of these error messages might be an
option? It appears that some of them are present in other drivers, but
I don't know whether such messages get displayed when that hardware is
unplugged too or whether I'm missing something that protects against
that.
I'm not seeing that at all, but I've also been developing and testing
on an ARM based device that has the LAN9500A I'm using built into it.
I have also recently got a LAN9500A devkit which I've tried on my
Ryzen
laptop and that's not throwing that error either.
Martyn
Yes I am using the LAN9514 Evaluation board (EVB9514). Plugging the
board into my desktop with 5.15 Ubuntu PPA kernel I also don't see this
crash.
OTOH I'm building vanilla kernel so no idea why this happens. It might
be that I have CONFIG_DMA_API_DEBUG and Ubuntu not.
I suspect this is probably unrelated (directly) to the driver then.
Martyn
On Mon, 2021-11-29 at 15:16 +0100, Ferry Toth wrote:
quoted
Hi,
Op 29-11-2021 om 13:08 schreef Martyn Welch:
quoted
On Sat, 2021-11-27 at 18:48 +0100, Ferry Toth wrote:
quoted
The patch introduces a new error on each unplug:
usb 1-1: USB disconnect, device number 2
usb 1-1.1: USB disconnect, device number 3
smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-xhci-hcd.1.auto-
1.1,
smsc95xx USB 2.0 Ethernet
smsc95xx 1-1.1:1.0 eth0: Link is Down
smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -19
smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -19
smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Agh! Somehow missed that. I'm looking into it...
That would be great!
They appear as a result of phy_disconnect() being called in unbind()
when the hardware has already been disconnected (which is kinda likely
to physically be the case with USB devices...). The PHY is not going to
be accessible, but such calls *are* needed for instances where we are
unbinding without the device having been physically removed and want to
put the device in a suitable state. Failing with -ENODEV (as it
currently does) seems to be the right thing to do.
I wonder whether removing some of these error messages might be an
option? It appears that some of them are present in other drivers, but
I don't know whether such messages get displayed when that hardware is
unplugged too or whether I'm missing something that protects against
that.
I just retried 5.10.63 and found it did not yet have the crash that you
fix here. But it did have the above Error reading MII_ACCESS. So
apparently this is more of an older annoyance since smsc95xx v2.00?
I'm not seeing that at all, but I've also been developing and testing
on an ARM based device that has the LAN9500A I'm using built into it.
I have also recently got a LAN9500A devkit which I've tried on my
Ryzen
laptop and that's not throwing that error either.
Martyn
Yes I am using the LAN9514 Evaluation board (EVB9514). Plugging the
board into my desktop with 5.15 Ubuntu PPA kernel I also don't see this
crash.
OTOH I'm building vanilla kernel so no idea why this happens. It might
be that I have CONFIG_DMA_API_DEBUG and Ubuntu not.
I suspect this is probably unrelated (directly) to the driver then.
Maybe not related to this driver but possibly an old bug in hub.c which
only surfaces now due to patch "[PATCH] dma debug: report -EEXIST errors
in add_dma_entry"? And only shows when CONFIG_DMA_API_DEBUG is set?
Ferry
On Tue, 2021-11-30 at 22:47 +0100, Ferry Toth wrote:
Op 30-11-2021 om 19:52 schreef Martyn Welch:
quoted
On Mon, 2021-11-29 at 15:16 +0100, Ferry Toth wrote:
quoted
Hi,
Op 29-11-2021 om 13:08 schreef Martyn Welch:
quoted
On Sat, 2021-11-27 at 18:48 +0100, Ferry Toth wrote:
quoted
The patch introduces a new error on each unplug:
usb 1-1: USB disconnect, device number 2
usb 1-1.1: USB disconnect, device number 3
smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-xhci-
hcd.1.auto-
1.1,
smsc95xx USB 2.0 Ethernet
smsc95xx 1-1.1:1.0 eth0: Link is Down
smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -
19
smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -
19
smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote
wakeup
Agh! Somehow missed that. I'm looking into it...
That would be great!
They appear as a result of phy_disconnect() being called in unbind()
when the hardware has already been disconnected (which is kinda
likely
to physically be the case with USB devices...). The PHY is not going
to
be accessible, but such calls *are* needed for instances where we are
unbinding without the device having been physically removed and want
to
put the device in a suitable state. Failing with -ENODEV (as it
currently does) seems to be the right thing to do.
I wonder whether removing some of these error messages might be an
option? It appears that some of them are present in other drivers,
but
I don't know whether such messages get displayed when that hardware
is
unplugged too or whether I'm missing something that protects against
that.
I just retried 5.10.63 and found it did not yet have the crash that you
fix here. But it did have the above Error reading MII_ACCESS. So
apparently this is more of an older annoyance since smsc95xx v2.00?
That's an interesting observation. Trying the v4.19 stable branch I see
that these errors aren't generated, however it seems that the driver at
that point may not be making any attempt to stop the PHY when the
driver is unbound/disconnected, which explains the lack of errors.
I'm not seeing that at all, but I've also been developing and
testing
on an ARM based device that has the LAN9500A I'm using built
into it.
I have also recently got a LAN9500A devkit which I've tried on
my
Ryzen
laptop and that's not throwing that error either.
Martyn
Yes I am using the LAN9514 Evaluation board (EVB9514). Plugging
the
board into my desktop with 5.15 Ubuntu PPA kernel I also don't
see this
crash.
OTOH I'm building vanilla kernel so no idea why this happens. It
might
be that I have CONFIG_DMA_API_DEBUG and Ubuntu not.
I suspect this is probably unrelated (directly) to the driver then.
Maybe not related to this driver but possibly an old bug in hub.c
which
only surfaces now due to patch "[PATCH] dma debug: report -EEXIST
errors
in add_dma_entry"? And only shows when CONFIG_DMA_API_DEBUG is set?
Ferry
On Tue, 2021-11-30 at 22:47 +0100, Ferry Toth wrote:
quoted
Op 30-11-2021 om 19:52 schreef Martyn Welch:
quoted
On Mon, 2021-11-29 at 15:16 +0100, Ferry Toth wrote:
quoted
Hi,
Op 29-11-2021 om 13:08 schreef Martyn Welch:
quoted
On Sat, 2021-11-27 at 18:48 +0100, Ferry Toth wrote:
quoted
The patch introduces a new error on each unplug:
usb 1-1: USB disconnect, device number 2
usb 1-1.1: USB disconnect, device number 3
smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-xhci-
hcd.1.auto-
1.1,
smsc95xx USB 2.0 Ethernet
smsc95xx 1-1.1:1.0 eth0: Link is Down
smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -
19
smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
smsc95xx 1-1.1:1.0 eth0: Failed to read reg index 0x00000114: -
19
smsc95xx 1-1.1:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-1.1:1.0 eth0: __smsc95xx_mdio_read: MII is busy
smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote
wakeup
Agh! Somehow missed that. I'm looking into it...
That would be great!
They appear as a result of phy_disconnect() being called in unbind()
when the hardware has already been disconnected (which is kinda
likely
to physically be the case with USB devices...). The PHY is not going
to
be accessible, but such calls *are* needed for instances where we are
unbinding without the device having been physically removed and want
to
put the device in a suitable state. Failing with -ENODEV (as it
currently does) seems to be the right thing to do.
I wonder whether removing some of these error messages might be an
option? It appears that some of them are present in other drivers,
but
I don't know whether such messages get displayed when that hardware
is
unplugged too or whether I'm missing something that protects against
that.
I just retried 5.10.63 and found it did not yet have the crash that you
fix here. But it did have the above Error reading MII_ACCESS. So
apparently this is more of an older annoyance since smsc95xx v2.00?
That's an interesting observation. Trying the v4.19 stable branch I see
that these errors aren't generated, however it seems that the driver at
that point may not be making any attempt to stop the PHY when the
driver is unbound/disconnected, which explains the lack of errors.
If I'm not mistaken v2.0.0 introduced by "smsc95xx: add phylib support"
in 5.10.0. Version before that was 1.0.6.
I'm not seeing that at all, but I've also been developing and
testing
on an ARM based device that has the LAN9500A I'm using built
into it.
I have also recently got a LAN9500A devkit which I've tried on
my
Ryzen
laptop and that's not throwing that error either.
Martyn
Yes I am using the LAN9514 Evaluation board (EVB9514). Plugging
the
board into my desktop with 5.15 Ubuntu PPA kernel I also don't
see this
crash.
OTOH I'm building vanilla kernel so no idea why this happens. It
might
be that I have CONFIG_DMA_API_DEBUG and Ubuntu not.
I suspect this is probably unrelated (directly) to the driver then.
Maybe not related to this driver but possibly an old bug in hub.c
which
only surfaces now due to patch "[PATCH] dma debug: report -EEXIST
errors
in add_dma_entry"? And only shows when CONFIG_DMA_API_DEBUG is set?
Ferry