* Regression: onboard-usb-hub breaks USB on RPi 3 @ 2022-12-18 13:35 Stefan Wahren 2022-12-19 10:41 ` Regression: onboard-usb-hub breaks USB on RPi 3 #forregzbot Thorsten Leemhuis 2022-12-19 17:44 ` Regression: onboard-usb-hub breaks USB on RPi 3 Matthias Kaehlcke 0 siblings, 2 replies; 15+ messages in thread From: Stefan Wahren @ 2022-12-18 13:35 UTC (permalink / raw) To: Matthias Kaehlcke, Fabrice Gasnier Cc: Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi, unfortunately i didn't notice this regression sooner, but the following commits breaks USB on Raspberry Pi 3: usb: misc: Add onboard_usb_hub driver usb: misc: onboard-hub: add support for Microchip USB2514B USB 2.0 hub After these commits (and this new driver enabled like in multi_v7_defconfig) the connected USB devices doesn't work anymore (mouse is powered, but no function of keyboard and mouse). Reconnecting doesn't help. Running lsusb hangs forever. Here is the relevant dmesg in error case: [ 0.078446] usbcore: registered new interface driver usbfs [ 0.078516] usbcore: registered new interface driver hub [ 0.078574] usbcore: registered new device driver usb [ 0.078827] usb_phy_generic phy: supply vcc not found, using dummy regulator [ 0.078990] usb_phy_generic phy: dummy supplies not allowed for exclusive requests [ 2.897258] usbcore: registered new interface driver pegasus [ 2.903161] usbcore: registered new interface driver asix [ 2.908809] usbcore: registered new interface driver ax88179_178a [ 2.915185] usbcore: registered new interface driver cdc_ether [ 2.921281] usbcore: registered new interface driver smsc75xx [ 2.927305] usbcore: registered new interface driver smsc95xx [ 2.933298] usbcore: registered new interface driver net1080 [ 2.939219] usbcore: registered new interface driver cdc_subset [ 2.945407] usbcore: registered new interface driver zaurus [ 2.951238] usbcore: registered new interface driver cdc_ncm [ 3.030909] usbcore: registered new interface driver usb-storage [ 3.178104] usbcore: registered new interface driver usbhid [ 3.191022] usbhid: USB HID core driver [ 3.981848] dwc2 3f980000.usb: supply vusb_d not found, using dummy regulator [ 3.992467] dwc2 3f980000.usb: supply vusb_a not found, using dummy regulator [ 4.053728] dwc2 3f980000.usb: DWC OTG Controller [ 4.065343] dwc2 3f980000.usb: new USB bus registered, assigned bus number 1 [ 4.079415] dwc2 3f980000.usb: irq 66, io mem 0x3f980000 [ 4.463447] usb 1-1: new high-speed USB device number 2 using dwc2 [ 5.063444] usb 1-1.1: new high-speed USB device number 3 using dwc2 [ 5.523440] usb 1-1.3: new low-speed USB device number 4 using dwc2 [ 5.685546] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0001/input/input0 [ 5.763446] usb 1-1.1.2: new low-speed USB device number 5 using dwc2 [ 5.777968] hid-generic 0003:046A:0011.0001: input: USB HID v1.11 Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 [ 5.931991] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0002/input/input1 [ 5.954668] hid-generic 0003:045E:00CB.0002: input: USB HID v1.11 Mouse [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 [ 6.263459] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 [ 14.828915] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not found, using dummy regulator [ 14.829493] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: supply vdd not found, using dummy regulator [ 14.829729] usbcore: registered new device driver onboard-usb-hub [ 14.829945] usb 1-1.1: USB disconnect, device number 3 [ 14.829958] usb 1-1.1.1: USB disconnect, device number 6 [ 14.830419] usb 1-1.1.2: USB disconnect, device number 5 [ 14.854725] usb 1-1.3: USB disconnect, device number 4 [ 14.896865] usbcore: registered new interface driver lan78xx Unfortunately i'm not that USB expert, so please tell me if you need more information. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 #forregzbot 2022-12-18 13:35 Regression: onboard-usb-hub breaks USB on RPi 3 Stefan Wahren @ 2022-12-19 10:41 ` Thorsten Leemhuis 2022-12-19 17:44 ` Regression: onboard-usb-hub breaks USB on RPi 3 Matthias Kaehlcke 1 sibling, 0 replies; 15+ messages in thread From: Thorsten Leemhuis @ 2022-12-19 10:41 UTC (permalink / raw) To: regressions; +Cc: linux-usb [Note: this mail contains only information for Linux kernel regression tracking. Mails like these contain '#forregzbot' in the subject to make then easy to spot and filter out. The author also tried to remove most or all individuals from the list of recipients to spare them the hassle.] On 18.12.22 14:35, Stefan Wahren wrote: > > unfortunately i didn't notice this regression sooner, but the following > commits breaks USB on Raspberry Pi 3: > > usb: misc: Add onboard_usb_hub driver that's 43993626de00 > usb: misc: onboard-hub: add support for Microchip USB2514B USB 2.0 hub that's 8bc063641ceb /me wonders which of this it actually is and assumes it's the latter > After these commits (and this new driver enabled like in > multi_v7_defconfig) the connected USB devices doesn't work anymore > (mouse is powered, but no function of keyboard and mouse). Reconnecting > doesn't help. Running lsusb hangs forever. Thanks for the report. To be sure below issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced 8bc063641ceb #regzbot title usb: onboard-usb-hub breaks USB on RPi3 #regzbot ignore-activity Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. > Here is the relevant dmesg in error case: > > [ 0.078446] usbcore: registered new interface driver usbfs > [ 0.078516] usbcore: registered new interface driver hub > [ 0.078574] usbcore: registered new device driver usb > [ 0.078827] usb_phy_generic phy: supply vcc not found, using dummy > regulator > [ 0.078990] usb_phy_generic phy: dummy supplies not allowed for > exclusive requests > [ 2.897258] usbcore: registered new interface driver pegasus > [ 2.903161] usbcore: registered new interface driver asix > [ 2.908809] usbcore: registered new interface driver ax88179_178a > [ 2.915185] usbcore: registered new interface driver cdc_ether > [ 2.921281] usbcore: registered new interface driver smsc75xx > [ 2.927305] usbcore: registered new interface driver smsc95xx > [ 2.933298] usbcore: registered new interface driver net1080 > [ 2.939219] usbcore: registered new interface driver cdc_subset > [ 2.945407] usbcore: registered new interface driver zaurus > [ 2.951238] usbcore: registered new interface driver cdc_ncm > [ 3.030909] usbcore: registered new interface driver usb-storage > [ 3.178104] usbcore: registered new interface driver usbhid > [ 3.191022] usbhid: USB HID core driver > [ 3.981848] dwc2 3f980000.usb: supply vusb_d not found, using dummy > regulator > [ 3.992467] dwc2 3f980000.usb: supply vusb_a not found, using dummy > regulator > [ 4.053728] dwc2 3f980000.usb: DWC OTG Controller > [ 4.065343] dwc2 3f980000.usb: new USB bus registered, assigned bus > number 1 > [ 4.079415] dwc2 3f980000.usb: irq 66, io mem 0x3f980000 > [ 4.463447] usb 1-1: new high-speed USB device number 2 using dwc2 > [ 5.063444] usb 1-1.1: new high-speed USB device number 3 using dwc2 > [ 5.523440] usb 1-1.3: new low-speed USB device number 4 using dwc2 > [ 5.685546] input: HID 046a:0011 as > /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0001/input/input0 > [ 5.763446] usb 1-1.1.2: new low-speed USB device number 5 using dwc2 > [ 5.777968] hid-generic 0003:046A:0011.0001: input: USB HID v1.11 > Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 > [ 5.931991] input: PixArt Microsoft USB Optical Mouse as > /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0002/input/input1 > [ 5.954668] hid-generic 0003:045E:00CB.0002: input: USB HID v1.11 > Mouse [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 > [ 6.263459] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 > [ 14.828915] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not > found, using dummy regulator > [ 14.829493] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: > supply vdd not found, using dummy regulator > [ 14.829729] usbcore: registered new device driver onboard-usb-hub > [ 14.829945] usb 1-1.1: USB disconnect, device number 3 > [ 14.829958] usb 1-1.1.1: USB disconnect, device number 6 > [ 14.830419] usb 1-1.1.2: USB disconnect, device number 5 > [ 14.854725] usb 1-1.3: USB disconnect, device number 4 > [ 14.896865] usbcore: registered new interface driver lan78xx > > Unfortunately i'm not that USB expert, so please tell me if you need > more information. > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-18 13:35 Regression: onboard-usb-hub breaks USB on RPi 3 Stefan Wahren 2022-12-19 10:41 ` Regression: onboard-usb-hub breaks USB on RPi 3 #forregzbot Thorsten Leemhuis @ 2022-12-19 17:44 ` Matthias Kaehlcke 2022-12-19 22:32 ` Stefan Wahren 1 sibling, 1 reply; 15+ messages in thread From: Matthias Kaehlcke @ 2022-12-19 17:44 UTC (permalink / raw) To: Stefan Wahren Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi Stefan, Sorry for the regression. What seems to happen is this: arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi specifies device nodes for the two (nested) USB hubs (which is done rarely since USB devices (including hubs) are autodetected). The DT nodes were most likely only added to be able to configure the LED modes of the USB to Ethernet adapter. With 43993626de00 ("usb: misc: onboard-hub: add support for Microchip USB2514B USB 2.0 hub") the onboard_usb_hub driver gained support for the hubs on the RPi3. The onboard_usb_hub driver expects a regulator ("vdd") in the DT node of the USB hub, which isn't present for the RPi3 (this isn't an error per se). Without the regulator the onboard_hub platform driver fails to probe, when the USB driver of the hub is probed (onboard_hub_usbdev_probe()) it doesn't find the corresponding platform driver instance (_find_onboard_hub()) and defers probing. When the deferred probe runs it encounters the same situation, rinse and repeat. One possible fix would be to specify the 'missing' "vdd" property, however that wouln't fix the issue for other boards with a similar configurations. Instead the driver could check if "vdd" exists in the DT node of the hub, and not defer probing if it doesn't. Could you please try if the below patch fixes the issue on the Rpi 3? Thanks m. diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c index d63c63942af1..4d2a27afb09c 100644 --- a/drivers/usb/misc/onboard_usb_hub.c +++ b/drivers/usb/misc/onboard_usb_hub.c @@ -363,6 +363,15 @@ static struct onboard_hub *_find_onboard_hub(struct device *dev) hub = dev_get_drvdata(&pdev->dev); put_device(&pdev->dev); + /* + * Some boards have device tree nodes for USB hubs supported by this + * driver, but the nodes don't have all properties needed for the driver + * to work properly. Use the absence of the "vdd" regulator as an + * indicator of such nodes. + */ + if (!of_get_property(pdev->dev.of_node, "vdd", NULL)) + return ERR_PTR(-ENODEV); + /* * The presence of drvdata ('hub') indicates that the platform driver * finished probing. This handles the case where (conceivably) we could On Sun, Dec 18, 2022 at 02:35:43PM +0100, Stefan Wahren wrote: > Hi, > > unfortunately i didn't notice this regression sooner, but the following > commits breaks USB on Raspberry Pi 3: > > usb: misc: Add onboard_usb_hub driver > usb: misc: onboard-hub: add support for Microchip USB2514B USB 2.0 hub > > After these commits (and this new driver enabled like in multi_v7_defconfig) > the connected USB devices doesn't work anymore (mouse is powered, but no > function of keyboard and mouse). Reconnecting doesn't help. Running lsusb > hangs forever. > > Here is the relevant dmesg in error case: > > [ 0.078446] usbcore: registered new interface driver usbfs > [ 0.078516] usbcore: registered new interface driver hub > [ 0.078574] usbcore: registered new device driver usb > [ 0.078827] usb_phy_generic phy: supply vcc not found, using dummy > regulator > [ 0.078990] usb_phy_generic phy: dummy supplies not allowed for exclusive > requests > [ 2.897258] usbcore: registered new interface driver pegasus > [ 2.903161] usbcore: registered new interface driver asix > [ 2.908809] usbcore: registered new interface driver ax88179_178a > [ 2.915185] usbcore: registered new interface driver cdc_ether > [ 2.921281] usbcore: registered new interface driver smsc75xx > [ 2.927305] usbcore: registered new interface driver smsc95xx > [ 2.933298] usbcore: registered new interface driver net1080 > [ 2.939219] usbcore: registered new interface driver cdc_subset > [ 2.945407] usbcore: registered new interface driver zaurus > [ 2.951238] usbcore: registered new interface driver cdc_ncm > [ 3.030909] usbcore: registered new interface driver usb-storage > [ 3.178104] usbcore: registered new interface driver usbhid > [ 3.191022] usbhid: USB HID core driver > [ 3.981848] dwc2 3f980000.usb: supply vusb_d not found, using dummy > regulator > [ 3.992467] dwc2 3f980000.usb: supply vusb_a not found, using dummy > regulator > [ 4.053728] dwc2 3f980000.usb: DWC OTG Controller > [ 4.065343] dwc2 3f980000.usb: new USB bus registered, assigned bus > number 1 > [ 4.079415] dwc2 3f980000.usb: irq 66, io mem 0x3f980000 > [ 4.463447] usb 1-1: new high-speed USB device number 2 using dwc2 > [ 5.063444] usb 1-1.1: new high-speed USB device number 3 using dwc2 > [ 5.523440] usb 1-1.3: new low-speed USB device number 4 using dwc2 > [ 5.685546] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0001/input/input0 > [ 5.763446] usb 1-1.1.2: new low-speed USB device number 5 using dwc2 > [ 5.777968] hid-generic 0003:046A:0011.0001: input: USB HID v1.11 > Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 > [ 5.931991] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0002/input/input1 > [ 5.954668] hid-generic 0003:045E:00CB.0002: input: USB HID v1.11 Mouse > [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 > [ 6.263459] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 > [ 14.828915] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not > found, using dummy regulator > [ 14.829493] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: supply > vdd not found, using dummy regulator > [ 14.829729] usbcore: registered new device driver onboard-usb-hub > [ 14.829945] usb 1-1.1: USB disconnect, device number 3 > [ 14.829958] usb 1-1.1.1: USB disconnect, device number 6 > [ 14.830419] usb 1-1.1.2: USB disconnect, device number 5 > [ 14.854725] usb 1-1.3: USB disconnect, device number 4 > [ 14.896865] usbcore: registered new interface driver lan78xx > > Unfortunately i'm not that USB expert, so please tell me if you need more > information. > ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-19 17:44 ` Regression: onboard-usb-hub breaks USB on RPi 3 Matthias Kaehlcke @ 2022-12-19 22:32 ` Stefan Wahren 2022-12-20 0:30 ` Matthias Kaehlcke 0 siblings, 1 reply; 15+ messages in thread From: Stefan Wahren @ 2022-12-19 22:32 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi Matthias, Am 19.12.22 um 18:44 schrieb Matthias Kaehlcke: > Hi Stefan, > > Sorry for the regression. > > What seems to happen is this: > > arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi specifies device nodes for the > two (nested) USB hubs (which is done rarely since USB devices (including > hubs) are autodetected). The DT nodes were most likely only added to be > able to configure the LED modes of the USB to Ethernet adapter. With > 43993626de00 ("usb: misc: onboard-hub: add support for Microchip USB2514B > USB 2.0 hub") the onboard_usb_hub driver gained support for the hubs on > the RPi3. The onboard_usb_hub driver expects a regulator ("vdd") in the DT > node of the USB hub, which isn't present for the RPi3 (this isn't an error > per se). Without the regulator the onboard_hub platform driver fails to > probe, when the USB driver of the hub is probed (onboard_hub_usbdev_probe()) > it doesn't find the corresponding platform driver instance > (_find_onboard_hub()) and defers probing. When the deferred probe runs it > encounters the same situation, rinse and repeat. I forgot to mention that in error case /sys/kernel/debug/devices_deferred was empty. > One possible fix would be to specify the 'missing' "vdd" property, however > that wouln't fix the issue for other boards with a similar configurations. > Instead the driver could check if "vdd" exists in the DT node of the hub, > and not defer probing if it doesn't. > > Could you please try if the below patch fixes the issue on the Rpi 3? Yes, this prevents probing of onboard-usb-hub and the issue. Thanks > > Thanks > > m. > > > diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c > index d63c63942af1..4d2a27afb09c 100644 > --- a/drivers/usb/misc/onboard_usb_hub.c > +++ b/drivers/usb/misc/onboard_usb_hub.c > @@ -363,6 +363,15 @@ static struct onboard_hub *_find_onboard_hub(struct device *dev) > hub = dev_get_drvdata(&pdev->dev); > put_device(&pdev->dev); > > + /* > + * Some boards have device tree nodes for USB hubs supported by this > + * driver, but the nodes don't have all properties needed for the driver > + * to work properly. Use the absence of the "vdd" regulator as an > + * indicator of such nodes. > + */ > + if (!of_get_property(pdev->dev.of_node, "vdd", NULL)) > + return ERR_PTR(-ENODEV); > + > /* > * The presence of drvdata ('hub') indicates that the platform driver > * finished probing. This handles the case where (conceivably) we could > > > > On Sun, Dec 18, 2022 at 02:35:43PM +0100, Stefan Wahren wrote: >> Hi, >> >> unfortunately i didn't notice this regression sooner, but the following >> commits breaks USB on Raspberry Pi 3: >> >> usb: misc: Add onboard_usb_hub driver >> usb: misc: onboard-hub: add support for Microchip USB2514B USB 2.0 hub >> >> After these commits (and this new driver enabled like in multi_v7_defconfig) >> the connected USB devices doesn't work anymore (mouse is powered, but no >> function of keyboard and mouse). Reconnecting doesn't help. Running lsusb >> hangs forever. >> >> Here is the relevant dmesg in error case: >> >> [ 0.078446] usbcore: registered new interface driver usbfs >> [ 0.078516] usbcore: registered new interface driver hub >> [ 0.078574] usbcore: registered new device driver usb >> [ 0.078827] usb_phy_generic phy: supply vcc not found, using dummy >> regulator >> [ 0.078990] usb_phy_generic phy: dummy supplies not allowed for exclusive >> requests >> [ 2.897258] usbcore: registered new interface driver pegasus >> [ 2.903161] usbcore: registered new interface driver asix >> [ 2.908809] usbcore: registered new interface driver ax88179_178a >> [ 2.915185] usbcore: registered new interface driver cdc_ether >> [ 2.921281] usbcore: registered new interface driver smsc75xx >> [ 2.927305] usbcore: registered new interface driver smsc95xx >> [ 2.933298] usbcore: registered new interface driver net1080 >> [ 2.939219] usbcore: registered new interface driver cdc_subset >> [ 2.945407] usbcore: registered new interface driver zaurus >> [ 2.951238] usbcore: registered new interface driver cdc_ncm >> [ 3.030909] usbcore: registered new interface driver usb-storage >> [ 3.178104] usbcore: registered new interface driver usbhid >> [ 3.191022] usbhid: USB HID core driver >> [ 3.981848] dwc2 3f980000.usb: supply vusb_d not found, using dummy >> regulator >> [ 3.992467] dwc2 3f980000.usb: supply vusb_a not found, using dummy >> regulator >> [ 4.053728] dwc2 3f980000.usb: DWC OTG Controller >> [ 4.065343] dwc2 3f980000.usb: new USB bus registered, assigned bus >> number 1 >> [ 4.079415] dwc2 3f980000.usb: irq 66, io mem 0x3f980000 >> [ 4.463447] usb 1-1: new high-speed USB device number 2 using dwc2 >> [ 5.063444] usb 1-1.1: new high-speed USB device number 3 using dwc2 >> [ 5.523440] usb 1-1.3: new low-speed USB device number 4 using dwc2 >> [ 5.685546] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0001/input/input0 >> [ 5.763446] usb 1-1.1.2: new low-speed USB device number 5 using dwc2 >> [ 5.777968] hid-generic 0003:046A:0011.0001: input: USB HID v1.11 >> Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 >> [ 5.931991] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0002/input/input1 >> [ 5.954668] hid-generic 0003:045E:00CB.0002: input: USB HID v1.11 Mouse >> [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 >> [ 6.263459] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 >> [ 14.828915] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not >> found, using dummy regulator >> [ 14.829493] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: supply >> vdd not found, using dummy regulator >> [ 14.829729] usbcore: registered new device driver onboard-usb-hub >> [ 14.829945] usb 1-1.1: USB disconnect, device number 3 >> [ 14.829958] usb 1-1.1.1: USB disconnect, device number 6 >> [ 14.830419] usb 1-1.1.2: USB disconnect, device number 5 >> [ 14.854725] usb 1-1.3: USB disconnect, device number 4 >> [ 14.896865] usbcore: registered new interface driver lan78xx >> >> Unfortunately i'm not that USB expert, so please tell me if you need more >> information. >> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-19 22:32 ` Stefan Wahren @ 2022-12-20 0:30 ` Matthias Kaehlcke 2022-12-20 16:19 ` Stefan Wahren 0 siblings, 1 reply; 15+ messages in thread From: Matthias Kaehlcke @ 2022-12-20 0:30 UTC (permalink / raw) To: Stefan Wahren Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli On Mon, Dec 19, 2022 at 11:32:58PM +0100, Stefan Wahren wrote: > Hi Matthias, > > Am 19.12.22 um 18:44 schrieb Matthias Kaehlcke: > > Hi Stefan, > > > > Sorry for the regression. > > > > What seems to happen is this: > > > > arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi specifies device nodes for the > > two (nested) USB hubs (which is done rarely since USB devices (including > > hubs) are autodetected). The DT nodes were most likely only added to be > > able to configure the LED modes of the USB to Ethernet adapter. With > > 43993626de00 ("usb: misc: onboard-hub: add support for Microchip USB2514B > > USB 2.0 hub") the onboard_usb_hub driver gained support for the hubs on > > the RPi3. The onboard_usb_hub driver expects a regulator ("vdd") in the DT > > node of the USB hub, which isn't present for the RPi3 (this isn't an error > > per se). Without the regulator the onboard_hub platform driver fails to > > probe, when the USB driver of the hub is probed (onboard_hub_usbdev_probe()) > > it doesn't find the corresponding platform driver instance > > (_find_onboard_hub()) and defers probing. When the deferred probe runs it > > encounters the same situation, rinse and repeat. > I forgot to mention that in error case /sys/kernel/debug/devices_deferred > was empty. > > One possible fix would be to specify the 'missing' "vdd" property, however > > that wouln't fix the issue for other boards with a similar configurations. > > Instead the driver could check if "vdd" exists in the DT node of the hub, > > and not defer probing if it doesn't. > > > > Could you please try if the below patch fixes the issue on the Rpi 3? > Yes, this prevents probing of onboard-usb-hub and the issue. Thanks for the confirmation, I'll send out a proper patch to get this fixed upstream. > > diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c > > index d63c63942af1..4d2a27afb09c 100644 > > --- a/drivers/usb/misc/onboard_usb_hub.c > > +++ b/drivers/usb/misc/onboard_usb_hub.c > > @@ -363,6 +363,15 @@ static struct onboard_hub *_find_onboard_hub(struct device *dev) > > hub = dev_get_drvdata(&pdev->dev); > > put_device(&pdev->dev); > > + /* > > + * Some boards have device tree nodes for USB hubs supported by this > > + * driver, but the nodes don't have all properties needed for the driver > > + * to work properly. Use the absence of the "vdd" regulator as an > > + * indicator of such nodes. > > + */ > > + if (!of_get_property(pdev->dev.of_node, "vdd", NULL)) > > + return ERR_PTR(-ENODEV); > > + > > /* > > * The presence of drvdata ('hub') indicates that the platform driver > > * finished probing. This handles the case where (conceivably) we could > > > > > > > > On Sun, Dec 18, 2022 at 02:35:43PM +0100, Stefan Wahren wrote: > > > Hi, > > > > > > unfortunately i didn't notice this regression sooner, but the following > > > commits breaks USB on Raspberry Pi 3: > > > > > > usb: misc: Add onboard_usb_hub driver > > > usb: misc: onboard-hub: add support for Microchip USB2514B USB 2.0 hub > > > > > > After these commits (and this new driver enabled like in multi_v7_defconfig) > > > the connected USB devices doesn't work anymore (mouse is powered, but no > > > function of keyboard and mouse). Reconnecting doesn't help. Running lsusb > > > hangs forever. > > > > > > Here is the relevant dmesg in error case: > > > > > > [ 0.078446] usbcore: registered new interface driver usbfs > > > [ 0.078516] usbcore: registered new interface driver hub > > > [ 0.078574] usbcore: registered new device driver usb > > > [ 0.078827] usb_phy_generic phy: supply vcc not found, using dummy > > > regulator > > > [ 0.078990] usb_phy_generic phy: dummy supplies not allowed for exclusive > > > requests > > > [ 2.897258] usbcore: registered new interface driver pegasus > > > [ 2.903161] usbcore: registered new interface driver asix > > > [ 2.908809] usbcore: registered new interface driver ax88179_178a > > > [ 2.915185] usbcore: registered new interface driver cdc_ether > > > [ 2.921281] usbcore: registered new interface driver smsc75xx > > > [ 2.927305] usbcore: registered new interface driver smsc95xx > > > [ 2.933298] usbcore: registered new interface driver net1080 > > > [ 2.939219] usbcore: registered new interface driver cdc_subset > > > [ 2.945407] usbcore: registered new interface driver zaurus > > > [ 2.951238] usbcore: registered new interface driver cdc_ncm > > > [ 3.030909] usbcore: registered new interface driver usb-storage > > > [ 3.178104] usbcore: registered new interface driver usbhid > > > [ 3.191022] usbhid: USB HID core driver > > > [ 3.981848] dwc2 3f980000.usb: supply vusb_d not found, using dummy > > > regulator > > > [ 3.992467] dwc2 3f980000.usb: supply vusb_a not found, using dummy > > > regulator > > > [ 4.053728] dwc2 3f980000.usb: DWC OTG Controller > > > [ 4.065343] dwc2 3f980000.usb: new USB bus registered, assigned bus > > > number 1 > > > [ 4.079415] dwc2 3f980000.usb: irq 66, io mem 0x3f980000 > > > [ 4.463447] usb 1-1: new high-speed USB device number 2 using dwc2 > > > [ 5.063444] usb 1-1.1: new high-speed USB device number 3 using dwc2 > > > [ 5.523440] usb 1-1.3: new low-speed USB device number 4 using dwc2 > > > [ 5.685546] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0001/input/input0 > > > [ 5.763446] usb 1-1.1.2: new low-speed USB device number 5 using dwc2 > > > [ 5.777968] hid-generic 0003:046A:0011.0001: input: USB HID v1.11 > > > Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 > > > [ 5.931991] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0002/input/input1 > > > [ 5.954668] hid-generic 0003:045E:00CB.0002: input: USB HID v1.11 Mouse > > > [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 > > > [ 6.263459] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 > > > [ 14.828915] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not > > > found, using dummy regulator > > > [ 14.829493] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: supply > > > vdd not found, using dummy regulator > > > [ 14.829729] usbcore: registered new device driver onboard-usb-hub > > > [ 14.829945] usb 1-1.1: USB disconnect, device number 3 > > > [ 14.829958] usb 1-1.1.1: USB disconnect, device number 6 > > > [ 14.830419] usb 1-1.1.2: USB disconnect, device number 5 > > > [ 14.854725] usb 1-1.3: USB disconnect, device number 4 > > > [ 14.896865] usbcore: registered new interface driver lan78xx > > > > > > Unfortunately i'm not that USB expert, so please tell me if you need more > > > information. > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-20 0:30 ` Matthias Kaehlcke @ 2022-12-20 16:19 ` Stefan Wahren 2022-12-20 22:50 ` Matthias Kaehlcke 0 siblings, 1 reply; 15+ messages in thread From: Stefan Wahren @ 2022-12-20 16:19 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi Matthias, Am 20.12.22 um 01:30 schrieb Matthias Kaehlcke: > On Mon, Dec 19, 2022 at 11:32:58PM +0100, Stefan Wahren wrote: >> Hi Matthias, >> >> Am 19.12.22 um 18:44 schrieb Matthias Kaehlcke: >>> Hi Stefan, >>> >>> Sorry for the regression. >>> >>> What seems to happen is this: >>> >>> arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi specifies device nodes for the >>> two (nested) USB hubs (which is done rarely since USB devices (including >>> hubs) are autodetected). The DT nodes were most likely only added to be >>> able to configure the LED modes of the USB to Ethernet adapter. With >>> 43993626de00 ("usb: misc: onboard-hub: add support for Microchip USB2514B >>> USB 2.0 hub") the onboard_usb_hub driver gained support for the hubs on >>> the RPi3. The onboard_usb_hub driver expects a regulator ("vdd") in the DT >>> node of the USB hub, which isn't present for the RPi3 (this isn't an error >>> per se). Without the regulator the onboard_hub platform driver fails to >>> probe, when the USB driver of the hub is probed (onboard_hub_usbdev_probe()) >>> it doesn't find the corresponding platform driver instance >>> (_find_onboard_hub()) and defers probing. When the deferred probe runs it >>> encounters the same situation, rinse and repeat. >> I forgot to mention that in error case /sys/kernel/debug/devices_deferred >> was empty. >>> One possible fix would be to specify the 'missing' "vdd" property, however >>> that wouln't fix the issue for other boards with a similar configurations. >>> Instead the driver could check if "vdd" exists in the DT node of the hub, >>> and not defer probing if it doesn't. >>> >>> Could you please try if the below patch fixes the issue on the Rpi 3? >> Yes, this prevents probing of onboard-usb-hub and the issue. > Thanks for the confirmation, I'll send out a proper patch to get this fixed > upstream. sorry, i accidentally disabled this driver during testing of the patch. So i erroneously assumed the patch is working, but it's not. I seems that the change is never reached (add dev_info around your change). The following worked on my Raspberry Pi 3 B+ diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c index de3627af3c84..570e9f3d2d89 100644 --- a/drivers/usb/misc/onboard_usb_hub.c +++ b/drivers/usb/misc/onboard_usb_hub.c @@ -227,6 +227,9 @@ static int onboard_hub_probe(struct platform_device *pdev) if (!hub) return -ENOMEM; + if (!of_get_property(dev->of_node, "vdd", NULL)) + return -ENODEV; + hub->vdd = devm_regulator_get(dev, "vdd"); if (IS_ERR(hub->vdd)) return PTR_ERR(hub->vdd); @@ -340,6 +343,15 @@ static struct onboard_hub *_find_onboard_hub(struct device *dev) hub = dev_get_drvdata(&pdev->dev); put_device(&pdev->dev); + /* + * Some boards have device tree nodes for USB hubs supported by this + * driver, but the nodes don't have all properties needed for the driver + * to work properly. Use the absence of the "vdd" regulator as an + * indicator of such nodes. + */ + if (!of_get_property(pdev->dev.of_node, "vdd", NULL)) + return ERR_PTR(-ENODEV); + /* * The presence of drvdata ('hub') indicates that the platform driver * finished probing. This handles the case where (conceivably) we couldThe following changes worked for me: ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-20 16:19 ` Stefan Wahren @ 2022-12-20 22:50 ` Matthias Kaehlcke 2022-12-21 12:29 ` Stefan Wahren 0 siblings, 1 reply; 15+ messages in thread From: Matthias Kaehlcke @ 2022-12-20 22:50 UTC (permalink / raw) To: Stefan Wahren Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli On Tue, Dec 20, 2022 at 05:19:34PM +0100, Stefan Wahren wrote: > Hi Matthias, > > Am 20.12.22 um 01:30 schrieb Matthias Kaehlcke: > > On Mon, Dec 19, 2022 at 11:32:58PM +0100, Stefan Wahren wrote: > > > Hi Matthias, > > > > > > Am 19.12.22 um 18:44 schrieb Matthias Kaehlcke: > > > > Hi Stefan, > > > > > > > > Sorry for the regression. > > > > > > > > What seems to happen is this: > > > > > > > > arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi specifies device nodes for the > > > > two (nested) USB hubs (which is done rarely since USB devices (including > > > > hubs) are autodetected). The DT nodes were most likely only added to be > > > > able to configure the LED modes of the USB to Ethernet adapter. With > > > > 43993626de00 ("usb: misc: onboard-hub: add support for Microchip USB2514B > > > > USB 2.0 hub") the onboard_usb_hub driver gained support for the hubs on > > > > the RPi3. The onboard_usb_hub driver expects a regulator ("vdd") in the DT > > > > node of the USB hub, which isn't present for the RPi3 (this isn't an error > > > > per se). Without the regulator the onboard_hub platform driver fails to > > > > probe, when the USB driver of the hub is probed (onboard_hub_usbdev_probe()) > > > > it doesn't find the corresponding platform driver instance > > > > (_find_onboard_hub()) and defers probing. When the deferred probe runs it > > > > encounters the same situation, rinse and repeat. > > > I forgot to mention that in error case /sys/kernel/debug/devices_deferred > > > was empty. > > > > One possible fix would be to specify the 'missing' "vdd" property, however > > > > that wouln't fix the issue for other boards with a similar configurations. > > > > Instead the driver could check if "vdd" exists in the DT node of the hub, > > > > and not defer probing if it doesn't. > > > > > > > > Could you please try if the below patch fixes the issue on the Rpi 3? > > > Yes, this prevents probing of onboard-usb-hub and the issue. > > Thanks for the confirmation, I'll send out a proper patch to get this fixed > > upstream. > > sorry, i accidentally disabled this driver during testing of the patch. So i > erroneously assumed the patch is working, but it's not. I seems that the > change is never reached (add dev_info around your change). Ah, good you caught it before a 'fix' was landed :) > The following worked on my Raspberry Pi 3 B+ > > diff --git a/drivers/usb/misc/onboard_usb_hub.c > b/drivers/usb/misc/onboard_usb_hub.c > index de3627af3c84..570e9f3d2d89 100644 > --- a/drivers/usb/misc/onboard_usb_hub.c > +++ b/drivers/usb/misc/onboard_usb_hub.c > @@ -227,6 +227,9 @@ static int onboard_hub_probe(struct platform_device > *pdev) > if (!hub) > return -ENOMEM; > > + if (!of_get_property(dev->of_node, "vdd", NULL)) > + return -ENODEV; > + > hub->vdd = devm_regulator_get(dev, "vdd"); > if (IS_ERR(hub->vdd)) > return PTR_ERR(hub->vdd); Today I learned that regulator_get() doesn't return an error when the regulator isn't specified, but the 'dummy regulator'. With that the platform driver is instantiated, which is not intended. The proper fix is probably to skip the creation of the 'raw' platform device in onboard_hub_create_pdevs() when the 'vdd-supply' does not exist. I tried to repro the Rpi 3 case by adjusting sc7280-herobrine.dtsi to look somewhat similar to the Rpi 3 hub config, but so far I wasn't 'successful' with breaking USB by deleting 'vdd-supply' (and 'peer-hub'). So I don't fully understand your scenario, but I'm relatively confident that not creating the platform devices should fix it. I'll try to send out a v2 of the fix before disappearing over the holidays after tomorrow. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-20 22:50 ` Matthias Kaehlcke @ 2022-12-21 12:29 ` Stefan Wahren 2022-12-21 16:50 ` Matthias Kaehlcke 0 siblings, 1 reply; 15+ messages in thread From: Stefan Wahren @ 2022-12-21 12:29 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi Matthias, Am 20.12.22 um 23:50 schrieb Matthias Kaehlcke: > > Today I learned that regulator_get() doesn't return an error when the regulator > isn't specified, but the 'dummy regulator'. With that the platform driver is > instantiated, which is not intended. The proper fix is probably to skip the > creation of the 'raw' platform device in onboard_hub_create_pdevs() when the > 'vdd-supply' does not exist. Yes, i can confirm this by debugfs: regulator use open bypass opmode voltage current min max --------------------------------------------------------------------------------------- regulator-dummy 8 7 0 unknown 0mV 0mA 0mV 0mV serial0-0-vddio 1 0mA 0mV 0mV serial0-0-vbat 1 0mA 0mV 0mV 3f980000.usb:usb-port@1:usb-port@1-vdd 1 0mA 0mV 0mV 3f980000.usb:usb-port@1-vdd 1 0mA 0mV 0mV 3f980000.usb-vusb_a 1 0mA 0mV 0mV 3f980000.usb-vusb_d 1 0mA 0mV 0mV phy-vcc 1 0mA 0mV 0mV > > I tried to repro the Rpi 3 case by adjusting sc7280-herobrine.dtsi to look > somewhat similar to the Rpi 3 hub config, but so far I wasn't 'successful' > with breaking USB by deleting 'vdd-supply' (and 'peer-hub'). So I don't fully > understand your scenario, but I'm relatively confident that not creating the > platform devices should fix it. I just played a little bit with arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi and removed only the second hub node (including ethernet chip). After this the issue also doesn't occur without any modification to onboard-usb-hub. So it seems to me that the real issue is caused by the cascade of 2x Microchip USB2514B USB 2.0 hubs. Here are the relevant kernel log entries: [ 4.025150] dwc2 3f980000.usb: supply vusb_d not found, using dummy regulator [ 4.038776] dwc2 3f980000.usb: supply vusb_a not found, using dummy regulator [ 4.104207] dwc2 3f980000.usb: DWC OTG Controller [ 4.115852] dwc2 3f980000.usb: new USB bus registered, assigned bus number 1 [ 4.129921] dwc2 3f980000.usb: irq 66, io mem 0x3f980000 [ 4.513217] usb 1-1: new high-speed USB device number 2 using dwc2 [ 5.123296] usb 1-1.1: new high-speed USB device number 3 using dwc2 [ 5.623217] usb 1-1.3: new low-speed USB device number 4 using dwc2 [ 5.785049] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0001/input/input0 [ 5.863240] usb 1-1.1.2: new low-speed USB device number 5 using dwc2 [ 5.868998] hid-generic 0003:046A:0011.0001: input: USB HID v1.11 Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 [ 6.031327] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0002/input/input1 [ 6.031490] hid-generic 0003:045E:00CB.0002: input: USB HID v1.11 Mouse [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 [ 6.333278] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 [ 24.165633] usbcore: registered new interface driver lan78xx [ 24.423801] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not found, using dummy regulator [ 24.424202] usbcore: registered new device driver onboard-usb-hub [ 24.424376] usb 1-1.1: USB disconnect, device number 3 [ 24.424385] usb 1-1.1.1: USB disconnect, device number 6 [ 24.564921] usb 1-1.1.2: USB disconnect, device number 5 [ 24.624696] usb 1-1.3: USB disconnect, device number 4 [ 25.523236] usb 1-1.1: new high-speed USB device number 7 using dwc2 [ 26.143248] usb 1-1.3: new low-speed USB device number 8 using dwc2 [ 26.305673] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0003/input/input2 [ 26.374840] hid-generic 0003:046A:0011.0003: input: USB HID v1.11 Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 [ 26.383241] usb 1-1.1.2: new low-speed USB device number 9 using dwc2 [ 26.521526] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0004/input/input3 [ 26.522241] hid-generic 0003:045E:00CB.0004: input: USB HID v1.11 Mouse [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 [ 26.833251] usb 1-1.1.1: new high-speed USB device number 10 using dwc2 As you can see the input devices are deregistered after probing of onboard-usb-hub and then registered again. The re-registering doesn't happen in the error case (as in my first email). Also in error case i noticed an unusual high load on the Rpi board, which doesn't occur in good case. Is it possible that both onboard-usb-hub instances are in some kind of deadlock? > > I'll try to send out a v2 of the fix before disappearing over the holidays > after tomorrow. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-21 12:29 ` Stefan Wahren @ 2022-12-21 16:50 ` Matthias Kaehlcke 2022-12-21 18:00 ` Stefan Wahren 0 siblings, 1 reply; 15+ messages in thread From: Matthias Kaehlcke @ 2022-12-21 16:50 UTC (permalink / raw) To: Stefan Wahren Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli On Wed, Dec 21, 2022 at 01:29:25PM +0100, Stefan Wahren wrote: > Hi Matthias, > > Am 20.12.22 um 23:50 schrieb Matthias Kaehlcke: > > > > Today I learned that regulator_get() doesn't return an error when the regulator > > isn't specified, but the 'dummy regulator'. With that the platform driver is > > instantiated, which is not intended. The proper fix is probably to skip the > > creation of the 'raw' platform device in onboard_hub_create_pdevs() when the > > 'vdd-supply' does not exist. > > Yes, i can confirm this by debugfs: > > regulator use open bypass opmode voltage current > min max > --------------------------------------------------------------------------------------- > regulator-dummy 8 7 0 unknown 0mV 0mA > 0mV 0mV > serial0-0-vddio 1 0mA 0mV 0mV > serial0-0-vbat 1 0mA 0mV 0mV > 3f980000.usb:usb-port@1:usb-port@1-vdd 1 > 0mA 0mV 0mV > 3f980000.usb:usb-port@1-vdd 1 0mA > 0mV 0mV > 3f980000.usb-vusb_a 1 0mA 0mV > 0mV > 3f980000.usb-vusb_d 1 0mA 0mV > 0mV > phy-vcc 1 0mA 0mV 0mV > > > > > I tried to repro the Rpi 3 case by adjusting sc7280-herobrine.dtsi to look > > somewhat similar to the Rpi 3 hub config, but so far I wasn't 'successful' > > with breaking USB by deleting 'vdd-supply' (and 'peer-hub'). So I don't fully > > understand your scenario, but I'm relatively confident that not creating the > > platform devices should fix it. > > I just played a little bit with arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi > and removed only the second hub node (including ethernet chip). After this > the issue also doesn't occur without any modification to onboard-usb-hub. So > it seems to me that the real issue is caused by the cascade of 2x Microchip > USB2514B USB 2.0 hubs. Thanks for your debugging efforts. I did some limited testing with nested hubs during development of the driver, using an external hub as alleged 2nd level onboard hub. I went back to such a configuration, unfortunately I still can't repro what you are seeing :( > Here are the relevant kernel log entries: > > [ 4.025150] dwc2 3f980000.usb: supply vusb_d not found, using dummy > regulator > [ 4.038776] dwc2 3f980000.usb: supply vusb_a not found, using dummy > regulator > [ 4.104207] dwc2 3f980000.usb: DWC OTG Controller > [ 4.115852] dwc2 3f980000.usb: new USB bus registered, assigned bus > number 1 > [ 4.129921] dwc2 3f980000.usb: irq 66, io mem 0x3f980000 > [ 4.513217] usb 1-1: new high-speed USB device number 2 using dwc2 > [ 5.123296] usb 1-1.1: new high-speed USB device number 3 using dwc2 > [ 5.623217] usb 1-1.3: new low-speed USB device number 4 using dwc2 > [ 5.785049] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0001/input/input0 > [ 5.863240] usb 1-1.1.2: new low-speed USB device number 5 using dwc2 > [ 5.868998] hid-generic 0003:046A:0011.0001: input: USB HID v1.11 > Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 > [ 6.031327] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0002/input/input1 > [ 6.031490] hid-generic 0003:045E:00CB.0002: input: USB HID v1.11 Mouse > [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 > [ 6.333278] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 > [ 24.165633] usbcore: registered new interface driver lan78xx > [ 24.423801] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not > found, using dummy regulator > [ 24.424202] usbcore: registered new device driver onboard-usb-hub > [ 24.424376] usb 1-1.1: USB disconnect, device number 3 > [ 24.424385] usb 1-1.1.1: USB disconnect, device number 6 > [ 24.564921] usb 1-1.1.2: USB disconnect, device number 5 > [ 24.624696] usb 1-1.3: USB disconnect, device number 4 > [ 25.523236] usb 1-1.1: new high-speed USB device number 7 using dwc2 > [ 26.143248] usb 1-1.3: new low-speed USB device number 8 using dwc2 > [ 26.305673] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0003/input/input2 > [ 26.374840] hid-generic 0003:046A:0011.0003: input: USB HID v1.11 > Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 > [ 26.383241] usb 1-1.1.2: new low-speed USB device number 9 using dwc2 > [ 26.521526] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0004/input/input3 > [ 26.522241] hid-generic 0003:045E:00CB.0004: input: USB HID v1.11 Mouse > [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 > [ 26.833251] usb 1-1.1.1: new high-speed USB device number 10 using dwc2 > > As you can see the input devices are deregistered after probing of > onboard-usb-hub and then registered again. It looks like the onboard_usb_hub driver is built as a module, which is the cause of the de- and re-registration. On a system that actually intends to use the onboard_hub driver I would recommand to make it a builtin driver to avoid this, but a module driver should still work. I changed my kernel config to use a onboard_hub module, but that didn't help either with reproducing the issue. Which kernel version are you running on the Rpi 3? > The re-registering doesn't happen in the error case (as in my first email). Could you add logs to onboard_hub_usbdev_probe() to see whether it is called at all and how far it gets? Confirming whether onboard_hub_probe() completes successfully might also help. > Also in error case i noticed an unusual high load on the Rpi board, which > doesn't occur in good case. Is it possible that both onboard-usb-hub > instances are in some kind of deadlock? Possibly. The driver itself uses a mutex for locking, which shouldn't result in a high load in case of a deadlock, in any case the high load you are observing seems to be related with the issue if it is only seen in the error case. Do things work properly when of_is_onboard_usb_hub() returns always false? That would be similar to the fix I have in mind for configs that shouldn't use the onboard_hub driver. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-21 16:50 ` Matthias Kaehlcke @ 2022-12-21 18:00 ` Stefan Wahren 2022-12-21 19:02 ` Matthias Kaehlcke 0 siblings, 1 reply; 15+ messages in thread From: Stefan Wahren @ 2022-12-21 18:00 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi Matthias, Am 21.12.22 um 17:50 schrieb Matthias Kaehlcke: > On Wed, Dec 21, 2022 at 01:29:25PM +0100, Stefan Wahren wrote: >> Hi Matthias, >> >> Am 20.12.22 um 23:50 schrieb Matthias Kaehlcke: >>> Today I learned that regulator_get() doesn't return an error when the regulator >>> isn't specified, but the 'dummy regulator'. With that the platform driver is >>> instantiated, which is not intended. The proper fix is probably to skip the >>> creation of the 'raw' platform device in onboard_hub_create_pdevs() when the >>> 'vdd-supply' does not exist. >> Yes, i can confirm this by debugfs: >> >> regulator use open bypass opmode voltage current >> min max >> --------------------------------------------------------------------------------------- >> regulator-dummy 8 7 0 unknown 0mV 0mA >> 0mV 0mV >> serial0-0-vddio 1 0mA 0mV 0mV >> serial0-0-vbat 1 0mA 0mV 0mV >> 3f980000.usb:usb-port@1:usb-port@1-vdd 1 >> 0mA 0mV 0mV >> 3f980000.usb:usb-port@1-vdd 1 0mA >> 0mV 0mV >> 3f980000.usb-vusb_a 1 0mA 0mV >> 0mV >> 3f980000.usb-vusb_d 1 0mA 0mV >> 0mV >> phy-vcc 1 0mA 0mV 0mV >> >>> I tried to repro the Rpi 3 case by adjusting sc7280-herobrine.dtsi to look >>> somewhat similar to the Rpi 3 hub config, but so far I wasn't 'successful' >>> with breaking USB by deleting 'vdd-supply' (and 'peer-hub'). So I don't fully >>> understand your scenario, but I'm relatively confident that not creating the >>> platform devices should fix it. >> I just played a little bit with arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi >> and removed only the second hub node (including ethernet chip). After this >> the issue also doesn't occur without any modification to onboard-usb-hub. So >> it seems to me that the real issue is caused by the cascade of 2x Microchip >> USB2514B USB 2.0 hubs. > Thanks for your debugging efforts. > > I did some limited testing with nested hubs during development of the > driver, using an external hub as alleged 2nd level onboard hub. I went > back to such a configuration, unfortunately I still can't repro what > you are seeing :( > >> Here are the relevant kernel log entries: >> >> [ 4.025150] dwc2 3f980000.usb: supply vusb_d not found, using dummy >> regulator >> [ 4.038776] dwc2 3f980000.usb: supply vusb_a not found, using dummy >> regulator >> [ 4.104207] dwc2 3f980000.usb: DWC OTG Controller >> [ 4.115852] dwc2 3f980000.usb: new USB bus registered, assigned bus >> number 1 >> [ 4.129921] dwc2 3f980000.usb: irq 66, io mem 0x3f980000 >> [ 4.513217] usb 1-1: new high-speed USB device number 2 using dwc2 >> [ 5.123296] usb 1-1.1: new high-speed USB device number 3 using dwc2 >> [ 5.623217] usb 1-1.3: new low-speed USB device number 4 using dwc2 >> [ 5.785049] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0001/input/input0 >> [ 5.863240] usb 1-1.1.2: new low-speed USB device number 5 using dwc2 >> [ 5.868998] hid-generic 0003:046A:0011.0001: input: USB HID v1.11 >> Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 >> [ 6.031327] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0002/input/input1 >> [ 6.031490] hid-generic 0003:045E:00CB.0002: input: USB HID v1.11 Mouse >> [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 >> [ 6.333278] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 >> [ 24.165633] usbcore: registered new interface driver lan78xx >> [ 24.423801] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not >> found, using dummy regulator >> [ 24.424202] usbcore: registered new device driver onboard-usb-hub >> [ 24.424376] usb 1-1.1: USB disconnect, device number 3 >> [ 24.424385] usb 1-1.1.1: USB disconnect, device number 6 >> [ 24.564921] usb 1-1.1.2: USB disconnect, device number 5 >> [ 24.624696] usb 1-1.3: USB disconnect, device number 4 >> [ 25.523236] usb 1-1.1: new high-speed USB device number 7 using dwc2 >> [ 26.143248] usb 1-1.3: new low-speed USB device number 8 using dwc2 >> [ 26.305673] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0003/input/input2 >> [ 26.374840] hid-generic 0003:046A:0011.0003: input: USB HID v1.11 >> Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 >> [ 26.383241] usb 1-1.1.2: new low-speed USB device number 9 using dwc2 >> [ 26.521526] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0004/input/input3 >> [ 26.522241] hid-generic 0003:045E:00CB.0004: input: USB HID v1.11 Mouse >> [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 >> [ 26.833251] usb 1-1.1.1: new high-speed USB device number 10 using dwc2 >> >> As you can see the input devices are deregistered after probing of >> onboard-usb-hub and then registered again. > It looks like the onboard_usb_hub driver is built as a module, which > is the cause of the de- and re-registration. On a system that actually > intends to use the onboard_hub driver I would recommand to make it a > builtin driver to avoid this, but a module driver should still work. Yes, most of the USB stuff is builtin, but onboard-usb-hub is build as module. > I changed my kernel config to use a onboard_hub module, but that didn't > help either with reproducing the issue. > > Which kernel version are you running on the Rpi 3? I started with v6.1, then went to v6.0 and then 43993626de00 ("usb: misc: onboard-hub: add support for Microchip USB2514B USB 2.0 hub"). All of them showed the issue. The configuration based on arm/multi_v7_defconfig. In the last case i need to enable ONBOARD_USB_HUB in the configuration. Based on my observations in v6.1 it wasn't always reproducible (50/50 chance). Btw the initial subject wasn't precise only Rpi 3 B Plus is affected. > >> The re-registering doesn't happen in the error case (as in my first email). > Could you add logs to onboard_hub_usbdev_probe() to see whether it is called > at all and how far it gets? Confirming whether onboard_hub_probe() completes > successfully might also help. Sure: [ 7.963910] usbcore: registered new interface driver lan78xx [ 8.231548] onboard-usb-hub 3f980000.usb:usb-port@1: onboard_hub_probe called [ 8.231590] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not found, using dummy regulator [ 8.231763] onboard-usb-hub 3f980000.usb:usb-port@1: onboard_hub_probe success [ 8.231867] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: onboard_hub_probe called [ 8.231880] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: supply vdd not found, using dummy regulator [ 8.231971] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: onboard_hub_probe success [ 8.232090] usbcore: registered new device driver onboard-usb-hub [ 8.232256] usb 1-1.1: USB disconnect, device number 3 [ 8.232264] usb 1-1.1.1: USB disconnect, device number 6 [ 8.380602] usb 1-1.1.2: USB disconnect, device number 5 [ 8.447421] usb 1-1.3: USB disconnect, device number 4 So onboard_hub_probe() is called successfully, but onboard_hub_usbdev_probe() doesn't seems to be. > >> Also in error case i noticed an unusual high load on the Rpi board, which >> doesn't occur in good case. Is it possible that both onboard-usb-hub >> instances are in some kind of deadlock? > Possibly. The driver itself uses a mutex for locking, which shouldn't result > in a high load in case of a deadlock, in any case the high load you are > observing seems to be related with the issue if it is only seen in the error > case. I will try to play with lock debugging. > > Do things work properly when of_is_onboard_usb_hub() returns always false? > That would be similar to the fix I have in mind for configs that shouldn't > use the onboard_hub driver. [ 24.781914] usbcore: registered new device driver onboard-usb-hub [ 24.782097] usb 1-1.1: USB disconnect, device number 3 [ 24.782110] usb 1-1.1.1: USB disconnect, device number 6 [ 24.916725] usb 1-1.1.2: USB disconnect, device number 5 [ 25.011118] usb 1-1.3: USB disconnect, device number 4 [ 25.648211] onboard-usb-hub 1-1: onboard_hub_usbdev_probe called [ 25.648259] onboard-usb-hub 1-1: failed to find device node for peer hub [ 25.648264] onboard-usb-hub: probe of 1-1 failed with error -22 [ 25.965643] usb 1-1.1: new high-speed USB device number 7 using dwc2 [ 26.107578] onboard-usb-hub 1-1.1: onboard_hub_usbdev_probe called [ 26.107636] onboard-usb-hub 1-1.1: failed to find device node for peer hub [ 26.107642] onboard-usb-hub: probe of 1-1.1 failed with error -22 [ 26.415691] usb 1-1.3: new low-speed USB device number 8 using dwc2 [ 26.567393] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0003/input/input2 [ 26.637183] hid-generic 0003:046A:0011.0003: input: USB HID v1.11 Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 [ 26.645694] usb 1-1.1.2: new low-speed USB device number 9 using dwc2 [ 26.793634] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0004/input/input3 [ 26.793859] hid-generic 0003:045E:00CB.0004: input: USB HID v1.11 Mouse [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 [ 27.135695] usb 1-1.1.1: new high-speed USB device number 10 using dwc2 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-21 18:00 ` Stefan Wahren @ 2022-12-21 19:02 ` Matthias Kaehlcke 2022-12-21 21:31 ` Stefan Wahren 0 siblings, 1 reply; 15+ messages in thread From: Matthias Kaehlcke @ 2022-12-21 19:02 UTC (permalink / raw) To: Stefan Wahren Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi Stefan, On Wed, Dec 21, 2022 at 07:00:41PM +0100, Stefan Wahren wrote: > Hi Matthias, > > Am 21.12.22 um 17:50 schrieb Matthias Kaehlcke: > > On Wed, Dec 21, 2022 at 01:29:25PM +0100, Stefan Wahren wrote: > > > Hi Matthias, > > > > > > Am 20.12.22 um 23:50 schrieb Matthias Kaehlcke: > > > > Today I learned that regulator_get() doesn't return an error when the regulator > > > > isn't specified, but the 'dummy regulator'. With that the platform driver is > > > > instantiated, which is not intended. The proper fix is probably to skip the > > > > creation of the 'raw' platform device in onboard_hub_create_pdevs() when the > > > > 'vdd-supply' does not exist. > > > Yes, i can confirm this by debugfs: > > > > > > regulator use open bypass opmode voltage current > > > min max > > > --------------------------------------------------------------------------------------- > > > regulator-dummy 8 7 0 unknown 0mV 0mA > > > 0mV 0mV > > > serial0-0-vddio 1 0mA 0mV 0mV > > > serial0-0-vbat 1 0mA 0mV 0mV > > > 3f980000.usb:usb-port@1:usb-port@1-vdd 1 > > > 0mA 0mV 0mV > > > 3f980000.usb:usb-port@1-vdd 1 0mA > > > 0mV 0mV > > > 3f980000.usb-vusb_a 1 0mA 0mV > > > 0mV > > > 3f980000.usb-vusb_d 1 0mA 0mV > > > 0mV > > > phy-vcc 1 0mA 0mV 0mV > > > > > > > I tried to repro the Rpi 3 case by adjusting sc7280-herobrine.dtsi to look > > > > somewhat similar to the Rpi 3 hub config, but so far I wasn't 'successful' > > > > with breaking USB by deleting 'vdd-supply' (and 'peer-hub'). So I don't fully > > > > understand your scenario, but I'm relatively confident that not creating the > > > > platform devices should fix it. > > > I just played a little bit with arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi > > > and removed only the second hub node (including ethernet chip). After this > > > the issue also doesn't occur without any modification to onboard-usb-hub. So > > > it seems to me that the real issue is caused by the cascade of 2x Microchip > > > USB2514B USB 2.0 hubs. > > Thanks for your debugging efforts. > > > > I did some limited testing with nested hubs during development of the > > driver, using an external hub as alleged 2nd level onboard hub. I went > > back to such a configuration, unfortunately I still can't repro what > > you are seeing :( > > > > > Here are the relevant kernel log entries: > > > > > > [ 4.025150] dwc2 3f980000.usb: supply vusb_d not found, using dummy > > > regulator > > > [ 4.038776] dwc2 3f980000.usb: supply vusb_a not found, using dummy > > > regulator > > > [ 4.104207] dwc2 3f980000.usb: DWC OTG Controller > > > [ 4.115852] dwc2 3f980000.usb: new USB bus registered, assigned bus > > > number 1 > > > [ 4.129921] dwc2 3f980000.usb: irq 66, io mem 0x3f980000 > > > [ 4.513217] usb 1-1: new high-speed USB device number 2 using dwc2 > > > [ 5.123296] usb 1-1.1: new high-speed USB device number 3 using dwc2 > > > [ 5.623217] usb 1-1.3: new low-speed USB device number 4 using dwc2 > > > [ 5.785049] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0001/input/input0 > > > [ 5.863240] usb 1-1.1.2: new low-speed USB device number 5 using dwc2 > > > [ 5.868998] hid-generic 0003:046A:0011.0001: input: USB HID v1.11 > > > Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 > > > [ 6.031327] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0002/input/input1 > > > [ 6.031490] hid-generic 0003:045E:00CB.0002: input: USB HID v1.11 Mouse > > > [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 > > > [ 6.333278] usb 1-1.1.1: new high-speed USB device number 6 using dwc2 > > > [ 24.165633] usbcore: registered new interface driver lan78xx > > > [ 24.423801] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not > > > found, using dummy regulator > > > [ 24.424202] usbcore: registered new device driver onboard-usb-hub > > > [ 24.424376] usb 1-1.1: USB disconnect, device number 3 > > > [ 24.424385] usb 1-1.1.1: USB disconnect, device number 6 > > > [ 24.564921] usb 1-1.1.2: USB disconnect, device number 5 > > > [ 24.624696] usb 1-1.3: USB disconnect, device number 4 > > > [ 25.523236] usb 1-1.1: new high-speed USB device number 7 using dwc2 > > > [ 26.143248] usb 1-1.3: new low-speed USB device number 8 using dwc2 > > > [ 26.305673] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0003/input/input2 > > > [ 26.374840] hid-generic 0003:046A:0011.0003: input: USB HID v1.11 > > > Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 > > > [ 26.383241] usb 1-1.1.2: new low-speed USB device number 9 using dwc2 > > > [ 26.521526] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0004/input/input3 > > > [ 26.522241] hid-generic 0003:045E:00CB.0004: input: USB HID v1.11 Mouse > > > [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 > > > [ 26.833251] usb 1-1.1.1: new high-speed USB device number 10 using dwc2 > > > > > > As you can see the input devices are deregistered after probing of > > > onboard-usb-hub and then registered again. > > It looks like the onboard_usb_hub driver is built as a module, which > > is the cause of the de- and re-registration. On a system that actually > > intends to use the onboard_hub driver I would recommand to make it a > > builtin driver to avoid this, but a module driver should still work. > Yes, most of the USB stuff is builtin, but onboard-usb-hub is build as > module. > > I changed my kernel config to use a onboard_hub module, but that didn't > > help either with reproducing the issue. > > > > Which kernel version are you running on the Rpi 3? > > I started with v6.1, then went to v6.0 and then Ok, I also tried v6.1, besides a downstream v5.15 kernel. > 43993626de00 ("usb: misc: onboard-hub: add support for Microchip USB2514B > USB 2.0 hub"). All of them showed the issue. The configuration based on > arm/multi_v7_defconfig. In the last case i need to enable ONBOARD_USB_HUB in > the configuration. > > Based on my observations in v6.1 it wasn't always reproducible (50/50 > chance). Good to know, so timing might be a factor. > Btw the initial subject wasn't precise only Rpi 3 B Plus is affected. Ok, thanks for the clarification. > > > The re-registering doesn't happen in the error case (as in my first email). > > Could you add logs to onboard_hub_usbdev_probe() to see whether it is called > > at all and how far it gets? Confirming whether onboard_hub_probe() completes > > successfully might also help. > > Sure: > > [ 7.963910] usbcore: registered new interface driver lan78xx > [ 8.231548] onboard-usb-hub 3f980000.usb:usb-port@1: onboard_hub_probe > called > [ 8.231590] onboard-usb-hub 3f980000.usb:usb-port@1: supply vdd not > found, using dummy regulator > [ 8.231763] onboard-usb-hub 3f980000.usb:usb-port@1: onboard_hub_probe > success > [ 8.231867] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: > onboard_hub_probe called > [ 8.231880] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: supply > vdd not found, using dummy regulator > [ 8.231971] onboard-usb-hub 3f980000.usb:usb-port@1:usb-port@1: > onboard_hub_probe success > [ 8.232090] usbcore: registered new device driver onboard-usb-hub > [ 8.232256] usb 1-1.1: USB disconnect, device number 3 > [ 8.232264] usb 1-1.1.1: USB disconnect, device number 6 > [ 8.380602] usb 1-1.1.2: USB disconnect, device number 5 > [ 8.447421] usb 1-1.3: USB disconnect, device number 4 > > So onboard_hub_probe() is called successfully, but > onboard_hub_usbdev_probe() doesn't seems to be. Odd, the 'onboard-usb-hub' driver was registered, onboard_hub_probe() completed for both hubs and the 'disconnect' logs seem to indicate that re-probing started: usb_register_device_driver __usb_bus_reprobe_drivers device_reprobe device_driver_detach <= this should be the cause of the 'disconnect' logs bus_rescan_devices_helper device_lock(dev->parent) device_attach __device_attach device_lock(dev) bus_for_each_drv __device_attach_driver driver_probe_device <= one of the subcalls should call onboard_hub_usbdev_probe() Maybe in the failure case some other thread acquired the device lock first and then the parent lock, leading to an ABBA deadlock? Pure guess work ... > > > Also in error case i noticed an unusual high load on the Rpi board, which > > > doesn't occur in good case. Is it possible that both onboard-usb-hub > > > instances are in some kind of deadlock? > > Possibly. The driver itself uses a mutex for locking, which shouldn't result > > in a high load in case of a deadlock, in any case the high load you are > > observing seems to be related with the issue if it is only seen in the error > > case. > I will try to play with lock debugging. Thanks, hopefully that can provide some hint. > > Do things work properly when of_is_onboard_usb_hub() returns always false? > > That would be similar to the fix I have in mind for configs that shouldn't > > use the onboard_hub driver. > [ 24.781914] usbcore: registered new device driver onboard-usb-hub > [ 24.782097] usb 1-1.1: USB disconnect, device number 3 > [ 24.782110] usb 1-1.1.1: USB disconnect, device number 6 > [ 24.916725] usb 1-1.1.2: USB disconnect, device number 5 > [ 25.011118] usb 1-1.3: USB disconnect, device number 4 > [ 25.648211] onboard-usb-hub 1-1: onboard_hub_usbdev_probe called > [ 25.648259] onboard-usb-hub 1-1: failed to find device node for peer hub > [ 25.648264] onboard-usb-hub: probe of 1-1 failed with error -22 > [ 25.965643] usb 1-1.1: new high-speed USB device number 7 using dwc2 > [ 26.107578] onboard-usb-hub 1-1.1: onboard_hub_usbdev_probe called > [ 26.107636] onboard-usb-hub 1-1.1: failed to find device node for peer > hub > [ 26.107642] onboard-usb-hub: probe of 1-1.1 failed with error -22 > [ 26.415691] usb 1-1.3: new low-speed USB device number 8 using dwc2 > [ 26.567393] input: HID 046a:0011 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046A:0011.0003/input/input2 > [ 26.637183] hid-generic 0003:046A:0011.0003: input: USB HID v1.11 > Keyboard [HID 046a:0011] on usb-3f980000.usb-1.3/input0 > [ 26.645694] usb 1-1.1.2: new low-speed USB device number 9 using dwc2 > [ 26.793634] input: PixArt Microsoft USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:045E:00CB.0004/input/input3 > [ 26.793859] hid-generic 0003:045E:00CB.0004: input: USB HID v1.11 Mouse > [PixArt Microsoft USB Optical Mouse] on usb-3f980000.usb-1.1.2/input0 > [ 27.135695] usb 1-1.1.1: new high-speed USB device number 10 using dwc2 The keyboard and the mouse are enumerated, so it seems generally the fix would work. We should probably get rid of the "failed to find device node for peer hub" log, the assumption was that the driver only gets probed when it should be used, but that isn't always the case. And _probe() should probably return -ENODEV when no platform device exists, not -EINVAL. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-21 19:02 ` Matthias Kaehlcke @ 2022-12-21 21:31 ` Stefan Wahren 2022-12-22 0:55 ` Matthias Kaehlcke 2022-12-27 13:15 ` Stefan Wahren 0 siblings, 2 replies; 15+ messages in thread From: Stefan Wahren @ 2022-12-21 21:31 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi Matthias, Am 21.12.22 um 20:02 schrieb Matthias Kaehlcke: > Hi Stefan, > > On Wed, Dec 21, 2022 at 07:00:41PM +0100, Stefan Wahren wrote: >> I will try to play with lock debugging. > Thanks, hopefully that can provide some hint. > DETECT_HUNG_TASK reveals this in error case: [ 243.676253] INFO: task kworker/2:1:44 blocked for more than 122 seconds. [ 243.676284] Not tainted 6.1.0-00007-g22fada783b9f #32 [ 243.676294] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.676303] task:kworker/2:1 state:D stack:0 pid:44 ppid:2 flags:0x00000000 [ 243.676329] Workqueue: events onboard_hub_attach_usb_driver [onboard_usb_hub] [ 243.676388] __schedule from schedule+0x58/0xf8 [ 243.676419] schedule from schedule_preempt_disabled+0x1c/0x2c [ 243.676445] schedule_preempt_disabled from __mutex_lock.constprop.0+0x29c/0x948 [ 243.676474] __mutex_lock.constprop.0 from __driver_attach+0x74/0x188 [ 243.676503] __driver_attach from bus_for_each_dev+0x70/0xb0 [ 243.676532] bus_for_each_dev from onboard_hub_attach_usb_driver+0xc/0x28 [onboard_usb_hub] [ 243.676587] onboard_hub_attach_usb_driver [onboard_usb_hub] from process_one_work+0x1f8/0x520 [ 243.676637] process_one_work from worker_thread+0x40/0x55c [ 243.676663] worker_thread from kthread+0xf0/0x110 [ 243.676685] kthread from ret_from_fork+0x14/0x2c [ 243.676705] Exception stack(0xf091dfb0 to 0xf091dff8) [ 243.676720] dfa0: 00000000 00000000 00000000 00000000 [ 243.676737] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 243.676752] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 243.676788] INFO: task systemd-udevd:148 blocked for more than 122 seconds. [ 243.676800] Not tainted 6.1.0-00007-g22fada783b9f #32 [ 243.676809] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.676817] task:systemd-udevd state:D stack:0 pid:148 ppid:144 flags:0x00000081 [ 243.676839] __schedule from schedule+0x58/0xf8 [ 243.676864] schedule from schedule_timeout+0xb4/0x15c [ 243.676893] schedule_timeout from __wait_for_common+0xc4/0x228 [ 243.676922] __wait_for_common from __flush_work+0x1a8/0x360 [ 243.676949] __flush_work from __cancel_work_timer+0x10c/0x1e4 [ 243.676975] __cancel_work_timer from onboard_hub_remove+0x28/0xbc [onboard_usb_hub] [ 243.677021] onboard_hub_remove [onboard_usb_hub] from platform_remove+0x20/0x4c [ 243.677067] platform_remove from device_release_driver_internal+0x194/0x21c [ 243.677092] device_release_driver_internal from bus_remove_device+0xcc/0xf8 [ 243.677124] bus_remove_device from device_del+0x16c/0x468 [ 243.677159] device_del from platform_device_del.part.0+0x10/0x74 [ 243.677187] platform_device_del.part.0 from platform_device_unregister+0x18/0x24 [ 243.677216] platform_device_unregister from of_platform_device_destroy+0x98/0xa8 [ 243.677249] of_platform_device_destroy from onboard_hub_destroy_pdevs+0x48/0x6c [ 243.677287] onboard_hub_destroy_pdevs from hub_disconnect+0x104/0x174 [ 243.677321] hub_disconnect from usb_unbind_interface+0x78/0x26c [ 243.677356] usb_unbind_interface from device_release_driver_internal+0x194/0x21c [ 243.677388] device_release_driver_internal from bus_remove_device+0xcc/0xf8 [ 243.677419] bus_remove_device from device_del+0x16c/0x468 [ 243.677452] device_del from usb_disable_device+0xcc/0x178 [ 243.677486] usb_disable_device from usb_set_configuration+0x4ec/0x8d0 [ 243.677523] usb_set_configuration from usb_unbind_device+0x24/0x7c [ 243.677560] usb_unbind_device from device_release_driver_internal+0x194/0x21c [ 243.677590] device_release_driver_internal from device_reprobe+0x18/0x90 [ 243.677620] device_reprobe from __usb_bus_reprobe_drivers+0x40/0x6c [ 243.677648] __usb_bus_reprobe_drivers from bus_for_each_dev+0x70/0xb0 [ 243.677676] bus_for_each_dev from usb_register_device_driver+0x9c/0xd0 [ 243.677713] usb_register_device_driver from onboard_hub_init+0x30/0x1000 [onboard_usb_hub] [ 243.677765] onboard_hub_init [onboard_usb_hub] from do_one_initcall+0x40/0x204 [ 243.677811] do_one_initcall from do_init_module+0x44/0x1d4 [ 243.677840] do_init_module from sys_finit_module+0xbc/0xf8 [ 243.677865] sys_finit_module from __sys_trace_return+0x0/0x10 [ 243.677887] Exception stack(0xf4659fa8 to 0xf4659ff0) [ 243.677904] 9fa0: bf369800 0051dba8 00000006 b6e438e0 00000000 b6e443f4 [ 243.677921] 9fc0: bf369800 0051dba8 00000000 0000017b 00531658 0051a1dc 00526398 00000000 [ 243.677935] 9fe0: befbb160 befbb150 b6e3a9d8 b6f2aae0 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-21 21:31 ` Stefan Wahren @ 2022-12-22 0:55 ` Matthias Kaehlcke 2022-12-22 11:19 ` Stefan Wahren 2022-12-27 13:15 ` Stefan Wahren 1 sibling, 1 reply; 15+ messages in thread From: Matthias Kaehlcke @ 2022-12-22 0:55 UTC (permalink / raw) To: Stefan Wahren Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi Stefan, On Wed, Dec 21, 2022 at 10:31:09PM +0100, Stefan Wahren wrote: > Hi Matthias, > > Am 21.12.22 um 20:02 schrieb Matthias Kaehlcke: > > Hi Stefan, > > > > On Wed, Dec 21, 2022 at 07:00:41PM +0100, Stefan Wahren wrote: > > > I will try to play with lock debugging. > > Thanks, hopefully that can provide some hint. > > > DETECT_HUNG_TASK reveals this in error case: > > [ 243.676253] INFO: task kworker/2:1:44 blocked for more than 122 seconds. > [ 243.676284] Not tainted 6.1.0-00007-g22fada783b9f #32 > [ 243.676294] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 243.676303] task:kworker/2:1 state:D stack:0 pid:44 ppid:2 > flags:0x00000000 > [ 243.676329] Workqueue: events onboard_hub_attach_usb_driver > [onboard_usb_hub] > [ 243.676388] __schedule from schedule+0x58/0xf8 > [ 243.676419] schedule from schedule_preempt_disabled+0x1c/0x2c > [ 243.676445] schedule_preempt_disabled from > __mutex_lock.constprop.0+0x29c/0x948 > [ 243.676474] __mutex_lock.constprop.0 from __driver_attach+0x74/0x188 > [ 243.676503] __driver_attach from bus_for_each_dev+0x70/0xb0 > [ 243.676532] bus_for_each_dev from onboard_hub_attach_usb_driver+0xc/0x28 > [onboard_usb_hub] > [ 243.676587] onboard_hub_attach_usb_driver [onboard_usb_hub] from > process_one_work+0x1f8/0x520 > [ 243.676637] process_one_work from worker_thread+0x40/0x55c > [ 243.676663] worker_thread from kthread+0xf0/0x110 > [ 243.676685] kthread from ret_from_fork+0x14/0x2c > [ 243.676705] Exception stack(0xf091dfb0 to 0xf091dff8) > [ 243.676720] dfa0: 00000000 00000000 > 00000000 00000000 > [ 243.676737] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 > [ 243.676752] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 > [ 243.676788] INFO: task systemd-udevd:148 blocked for more than 122 > seconds. > [ 243.676800] Not tainted 6.1.0-00007-g22fada783b9f #32 > [ 243.676809] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 243.676817] task:systemd-udevd state:D stack:0 pid:148 ppid:144 > flags:0x00000081 > [ 243.676839] __schedule from schedule+0x58/0xf8 > [ 243.676864] schedule from schedule_timeout+0xb4/0x15c > [ 243.676893] schedule_timeout from __wait_for_common+0xc4/0x228 > [ 243.676922] __wait_for_common from __flush_work+0x1a8/0x360 > [ 243.676949] __flush_work from __cancel_work_timer+0x10c/0x1e4 > [ 243.676975] __cancel_work_timer from onboard_hub_remove+0x28/0xbc > [onboard_usb_hub] > [ 243.677021] onboard_hub_remove [onboard_usb_hub] from > platform_remove+0x20/0x4c > [ 243.677067] platform_remove from > device_release_driver_internal+0x194/0x21c > [ 243.677092] device_release_driver_internal from > bus_remove_device+0xcc/0xf8 > [ 243.677124] bus_remove_device from device_del+0x16c/0x468 > [ 243.677159] device_del from platform_device_del.part.0+0x10/0x74 > [ 243.677187] platform_device_del.part.0 from > platform_device_unregister+0x18/0x24 > [ 243.677216] platform_device_unregister from > of_platform_device_destroy+0x98/0xa8 > [ 243.677249] of_platform_device_destroy from > onboard_hub_destroy_pdevs+0x48/0x6c > [ 243.677287] onboard_hub_destroy_pdevs from hub_disconnect+0x104/0x174 > [ 243.677321] hub_disconnect from usb_unbind_interface+0x78/0x26c > [ 243.677356] usb_unbind_interface from > device_release_driver_internal+0x194/0x21c > [ 243.677388] device_release_driver_internal from > bus_remove_device+0xcc/0xf8 > [ 243.677419] bus_remove_device from device_del+0x16c/0x468 > [ 243.677452] device_del from usb_disable_device+0xcc/0x178 > [ 243.677486] usb_disable_device from usb_set_configuration+0x4ec/0x8d0 > [ 243.677523] usb_set_configuration from usb_unbind_device+0x24/0x7c > [ 243.677560] usb_unbind_device from > device_release_driver_internal+0x194/0x21c > [ 243.677590] device_release_driver_internal from device_reprobe+0x18/0x90 > [ 243.677620] device_reprobe from __usb_bus_reprobe_drivers+0x40/0x6c > [ 243.677648] __usb_bus_reprobe_drivers from bus_for_each_dev+0x70/0xb0 > [ 243.677676] bus_for_each_dev from usb_register_device_driver+0x9c/0xd0 > [ 243.677713] usb_register_device_driver from onboard_hub_init+0x30/0x1000 > [onboard_usb_hub] > [ 243.677765] onboard_hub_init [onboard_usb_hub] from > do_one_initcall+0x40/0x204 > [ 243.677811] do_one_initcall from do_init_module+0x44/0x1d4 > [ 243.677840] do_init_module from sys_finit_module+0xbc/0xf8 > [ 243.677865] sys_finit_module from __sys_trace_return+0x0/0x10 > [ 243.677887] Exception stack(0xf4659fa8 to 0xf4659ff0) > [ 243.677904] 9fa0: bf369800 0051dba8 00000006 b6e438e0 > 00000000 b6e443f4 > [ 243.677921] 9fc0: bf369800 0051dba8 00000000 0000017b 00531658 0051a1dc > 00526398 00000000 > [ 243.677935] 9fe0: befbb160 befbb150 b6e3a9d8 b6f2aae0 Thanks, that's useful! The flow is something like this: - USB root hub is instantiated - core hub driver calls onboard_hub_create_pdevs(), which creates the platform device for the 1st level hub - the platform device is created even though the onboard hub driver hasn't been loaded yet, because onboard_hub_create/destroy_pdevs() is linked into the USB core - 1st level Microchip hubs is probed by the core hub driver - core hub driver calls onboard_hub_create_pdevs(), which creates the platform device for the 2nd level hub - onboard_hub platform driver is registered - platform device for 1st level hub is probed - schedules 'attach' work - platform device for 2nd level hub is probed - schedules 'attach' work - onboard_hub USB driver is registered - device (and parent) lock of Microchip hub is held while the device is re-probing - 'attach' work (running in another thread) calls driver_attach(), which blocks on one of the hub device locks - onboard_hub_destroy_pdevs() is called by the core hub driver when one of the Microchip hubs is detached - destroying the pdevs invokes onboard_hub_remove(), which waits for the 'attach' work to complete - waits forever, since the 'attach' work can't acquire the device lock For the Rpi 3 B Plus and boards with similar configurations it should be enough with not creating the onboard_hub platform devices, which anyway is the right thing do. I'll send patches for this. The above race condition could also impact boards which actually should use the onboard_hub driver, so not creating the pdevs for some boards won't be enough. Out of my head I can't think of a clean solution. The onboard hub driver doesn't control the locks involved. Detaching the driver is necessary to make sure the onboard_hub USB devices don't hold stale pointers to their platform device. Re-attaching is needed because of the detach. One option could be to change the 'attach' work from being a member of struct onboard_hub to a static variable owned by the driver. With that onboard_hub_remove() wouldn't have to wait for the work to finish. An inconvenient is that only one instance of the work can run at any time, which could result in a race condition when multiple onboard hubs are probed closely together. It could happen that the USB device of the 2nd (or 3rd, ...) hub isn't re-attached if it wasn't on the system wide USB 'bus' yet when the 'attach' work of the 1st hub runs. Probably a rare condition within the (as of now) rare scenario of multiple onboard hubs, but it could happen. A mitigation could be to enter a sleepy loop if schedule_work() returns false (work is already running) and schedule it again until it is actually scheduled on behalf of the platform device in question. I might go for that if I don't get a better idea. Happy holidays! m. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-22 0:55 ` Matthias Kaehlcke @ 2022-12-22 11:19 ` Stefan Wahren 0 siblings, 0 replies; 15+ messages in thread From: Stefan Wahren @ 2022-12-22 11:19 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi Matthias, Am 22.12.22 um 01:55 schrieb Matthias Kaehlcke: > The above race condition could also impact boards which actually should > use the onboard_hub driver, so not creating the pdevs for some boards > won't be enough. > > Out of my head I can't think of a clean solution. The onboard hub driver > doesn't control the locks involved. Detaching the driver is necessary > to make sure the onboard_hub USB devices don't hold stale pointers to > their platform device. Re-attaching is needed because of the detach. > > One option could be to change the 'attach' work from being a member of > struct onboard_hub to a static variable owned by the driver. With that > onboard_hub_remove() wouldn't have to wait for the work to finish. An > inconvenient is that only one instance of the work can run at any time, > which could result in a race condition when multiple onboard hubs are > probed closely together. It could happen that the USB device of the 2nd > (or 3rd, ...) hub isn't re-attached if it wasn't on the system wide USB > 'bus' yet when the 'attach' work of the 1st hub runs. Probably a rare > condition within the (as of now) rare scenario of multiple onboard hubs, > but it could happen. A mitigation could be to enter a sleepy loop if > schedule_work() returns false (work is already running) and schedule it > again until it is actually scheduled on behalf of the platform device > in question. I might go for that if I don't get a better idea. i don't have any idea. > Happy holidays! Thank you. Happy holidays to you, too! > > m. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression: onboard-usb-hub breaks USB on RPi 3 2022-12-21 21:31 ` Stefan Wahren 2022-12-22 0:55 ` Matthias Kaehlcke @ 2022-12-27 13:15 ` Stefan Wahren 1 sibling, 0 replies; 15+ messages in thread From: Stefan Wahren @ 2022-12-27 13:15 UTC (permalink / raw) To: Matthias Kaehlcke, Doug Anderson, Icenowy Zheng, Johan Hovold Cc: Fabrice Gasnier, Greg Kroah-Hartman, linux-usb, regressions, Florian Fainelli Hi, [add Doug, Icenowy and Johan] Am 21.12.22 um 22:31 schrieb Stefan Wahren: > Hi Matthias, > > Am 21.12.22 um 20:02 schrieb Matthias Kaehlcke: >> Hi Stefan, >> >> On Wed, Dec 21, 2022 at 07:00:41PM +0100, Stefan Wahren wrote: >>> I will try to play with lock debugging. >> Thanks, hopefully that can provide some hint. >> > DETECT_HUNG_TASK reveals this in error case: > > [ 243.676253] INFO: task kworker/2:1:44 blocked for more than 122 > seconds. > [ 243.676284] Not tainted 6.1.0-00007-g22fada783b9f #32 > [ 243.676294] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 243.676303] task:kworker/2:1 state:D stack:0 pid:44 > ppid:2 flags:0x00000000 > [ 243.676329] Workqueue: events onboard_hub_attach_usb_driver > [onboard_usb_hub] > [ 243.676388] __schedule from schedule+0x58/0xf8 > [ 243.676419] schedule from schedule_preempt_disabled+0x1c/0x2c > [ 243.676445] schedule_preempt_disabled from > __mutex_lock.constprop.0+0x29c/0x948 > [ 243.676474] __mutex_lock.constprop.0 from __driver_attach+0x74/0x188 > [ 243.676503] __driver_attach from bus_for_each_dev+0x70/0xb0 > [ 243.676532] bus_for_each_dev from > onboard_hub_attach_usb_driver+0xc/0x28 [onboard_usb_hub] > [ 243.676587] onboard_hub_attach_usb_driver [onboard_usb_hub] from > process_one_work+0x1f8/0x520 > [ 243.676637] process_one_work from worker_thread+0x40/0x55c > [ 243.676663] worker_thread from kthread+0xf0/0x110 > [ 243.676685] kthread from ret_from_fork+0x14/0x2c > [ 243.676705] Exception stack(0xf091dfb0 to 0xf091dff8) > [ 243.676720] dfa0: 00000000 > 00000000 00000000 00000000 > [ 243.676737] dfc0: 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 > [ 243.676752] dfe0: 00000000 00000000 00000000 00000000 00000013 > 00000000 > [ 243.676788] INFO: task systemd-udevd:148 blocked for more than 122 > seconds. > [ 243.676800] Not tainted 6.1.0-00007-g22fada783b9f #32 > [ 243.676809] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 243.676817] task:systemd-udevd state:D stack:0 pid:148 > ppid:144 flags:0x00000081 > [ 243.676839] __schedule from schedule+0x58/0xf8 > [ 243.676864] schedule from schedule_timeout+0xb4/0x15c > [ 243.676893] schedule_timeout from __wait_for_common+0xc4/0x228 > [ 243.676922] __wait_for_common from __flush_work+0x1a8/0x360 > [ 243.676949] __flush_work from __cancel_work_timer+0x10c/0x1e4 > [ 243.676975] __cancel_work_timer from onboard_hub_remove+0x28/0xbc > [onboard_usb_hub] > [ 243.677021] onboard_hub_remove [onboard_usb_hub] from > platform_remove+0x20/0x4c > [ 243.677067] platform_remove from > device_release_driver_internal+0x194/0x21c > [ 243.677092] device_release_driver_internal from > bus_remove_device+0xcc/0xf8 > [ 243.677124] bus_remove_device from device_del+0x16c/0x468 > [ 243.677159] device_del from platform_device_del.part.0+0x10/0x74 > [ 243.677187] platform_device_del.part.0 from > platform_device_unregister+0x18/0x24 > [ 243.677216] platform_device_unregister from > of_platform_device_destroy+0x98/0xa8 > [ 243.677249] of_platform_device_destroy from > onboard_hub_destroy_pdevs+0x48/0x6c > [ 243.677287] onboard_hub_destroy_pdevs from hub_disconnect+0x104/0x174 > [ 243.677321] hub_disconnect from usb_unbind_interface+0x78/0x26c > [ 243.677356] usb_unbind_interface from > device_release_driver_internal+0x194/0x21c > [ 243.677388] device_release_driver_internal from > bus_remove_device+0xcc/0xf8 > [ 243.677419] bus_remove_device from device_del+0x16c/0x468 > [ 243.677452] device_del from usb_disable_device+0xcc/0x178 > [ 243.677486] usb_disable_device from usb_set_configuration+0x4ec/0x8d0 > [ 243.677523] usb_set_configuration from usb_unbind_device+0x24/0x7c > [ 243.677560] usb_unbind_device from > device_release_driver_internal+0x194/0x21c > [ 243.677590] device_release_driver_internal from > device_reprobe+0x18/0x90 > [ 243.677620] device_reprobe from __usb_bus_reprobe_drivers+0x40/0x6c > [ 243.677648] __usb_bus_reprobe_drivers from bus_for_each_dev+0x70/0xb0 > [ 243.677676] bus_for_each_dev from > usb_register_device_driver+0x9c/0xd0 > [ 243.677713] usb_register_device_driver from > onboard_hub_init+0x30/0x1000 [onboard_usb_hub] > [ 243.677765] onboard_hub_init [onboard_usb_hub] from > do_one_initcall+0x40/0x204 > [ 243.677811] do_one_initcall from do_init_module+0x44/0x1d4 > [ 243.677840] do_init_module from sys_finit_module+0xbc/0xf8 > [ 243.677865] sys_finit_module from __sys_trace_return+0x0/0x10 > [ 243.677887] Exception stack(0xf4659fa8 to 0xf4659ff0) > [ 243.677904] 9fa0: bf369800 0051dba8 00000006 > b6e438e0 00000000 b6e443f4 > [ 243.677921] 9fc0: bf369800 0051dba8 00000000 0000017b 00531658 > 0051a1dc 00526398 00000000 > [ 243.677935] 9fe0: befbb160 befbb150 b6e3a9d8 b6f2aae0 > since Matthias patch [1] has been rejected any ideas to this issue would be helpful. Best regards [1] - https://lore.kernel.org/lkml/9f42f88f-26bc-1e82-03a0-659c85c40469@i2se.com/T/ ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2022-12-27 13:15 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-18 13:35 Regression: onboard-usb-hub breaks USB on RPi 3 Stefan Wahren 2022-12-19 10:41 ` Regression: onboard-usb-hub breaks USB on RPi 3 #forregzbot Thorsten Leemhuis 2022-12-19 17:44 ` Regression: onboard-usb-hub breaks USB on RPi 3 Matthias Kaehlcke 2022-12-19 22:32 ` Stefan Wahren 2022-12-20 0:30 ` Matthias Kaehlcke 2022-12-20 16:19 ` Stefan Wahren 2022-12-20 22:50 ` Matthias Kaehlcke 2022-12-21 12:29 ` Stefan Wahren 2022-12-21 16:50 ` Matthias Kaehlcke 2022-12-21 18:00 ` Stefan Wahren 2022-12-21 19:02 ` Matthias Kaehlcke 2022-12-21 21:31 ` Stefan Wahren 2022-12-22 0:55 ` Matthias Kaehlcke 2022-12-22 11:19 ` Stefan Wahren 2022-12-27 13:15 ` Stefan Wahren
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.