ARM: multi_v7_defconfig: enable usb3503

PATCH New riku.voipio at linaro.org 6 participants 9 messages Mar 13, 2015 – Sep 15, 2015

Subsystems (2)

Arm (32-bit) Arm Samsung Exynos

lore

Share & tools

lore

riku.voipio at linaro.org

author

2015-03-13 13:54 UTC #0 lore raw

PATCH 1/1 ARM: multi_v7_defconfig: enable usb3503

From: Riku Voipio <[email protected]>

CONFIG_USB_HSIC_USB3503 is needed by exynos5250-arndale for the on-board asix network controller. Enable it so networking works with multi_v7_defconfig out of box like it does with exynos_defconfig.

USB3503 is also referenced from exynos4412-odroidu3.dts and exynos5250-spring.dts so this patch should improve multi_v7_defconfig on those platforms as well.

Signed-off-by Riku Voipio <[email protected]>

---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm/configs/multi_v7_defconfig +1 -0

index b7e6b6fb..a4b9bc3 100644
@@ -426,6 +426,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_CHIPIDEA=y
 CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_HSIC_USB3503=y
 CONFIG_AB8500_USB=y
 CONFIG_KEYSTONE_USB_PHY=y
 CONFIG_OMAP_USB3=y

Signature · 1 line

2.1.4

Kevin Hilman

2015-06-04 01:08 UTC #1 lore raw

PATCH 1/1 ARM: multi_v7_defconfig: enable usb3503

Quoted 11 lines · riku.voipio at linaro.org

From: Riku Voipio <[email protected]>
CONFIG_USB_HSIC_USB3503 is needed by exynos5250-arndale for the on-board asix network controller. Enable it so networking works with multi_v7_defconfig out of box like it does with exynos_defconfig.
USB3503 is also referenced from exynos4412-odroidu3.dts and exynos5250-spring.dts so this patch should improve multi_v7_defconfig on those platforms as well.
Signed-off-by Riku Voipio <[email protected]>

Tyler pointed me to this in order to get arndale networking on mainline, but looks like this might need to be revisited for current mainline.

I tested this and it doesn't work because as of commit 7de7c6717f2c (ARM: multi_v7_defconfig: Enable Exynos USB PHY) the PHY that this depends on is built as a module in multi_v7_config, so having this driver built-in doesn't help. Even after the PHY driver is loaded, this driver will not detect the hardware.

So instead, I think this driver should be built as a module as well. Testing that, I can get networking by doing loading both the phy and this driver after boot:

 # modprobe phy-exynos-usb2
 # modprobe usb3503

Kevin

Javier Martinez Canillas

2015-06-04 06:38 UTC #2 lore raw

PATCH 1/1 ARM: multi_v7_defconfig: enable usb3503

Hello Kevin,

Quoted 23 lines · Kevin Hilman

Quoted 11 lines · riku.voipio at linaro.org
From: Riku Voipio <[email protected]>
CONFIG_USB_HSIC_USB3503 is needed by exynos5250-arndale for the on-board asix network controller. Enable it so networking works with multi_v7_defconfig out of box like it does with exynos_defconfig.
USB3503 is also referenced from exynos4412-odroidu3.dts and exynos5250-spring.dts so this patch should improve multi_v7_defconfig on those platforms as well.
Signed-off-by Riku Voipio <[email protected]>
Tyler pointed me to this in order to get arndale networking on mainline, but looks like this might need to be revisited for current mainline.
I tested this and it doesn't work because as of commit 7de7c6717f2c (ARM: multi_v7_defconfig: Enable Exynos USB PHY) the PHY that this depends on is built as a module in multi_v7_config, so having this driver built-in doesn't help. Even after the PHY driver is loaded, this driver will not detect the hardware.

Quoted 7 lines

So instead, I think this driver should be built as a module as well. Testing that, I can get networking by doing loading both the phy and this driver after boot:
 # modprobe phy-exynos-usb2
 # modprobe usb3503

Current policy is to have as much as possible built as a module in multi_v7_config so regardless of your issue I think that the patch should be re-spun to change this.

But I wonder why is not working, shouldn't the driver defer and be probed again once the PHY driver probe succeeds?

Quoted 2 lines

Kevin

Best regards,
Javier

Kevin Hilman

2015-06-04 17:47 UTC #3 lore raw

PATCH 1/1 ARM: multi_v7_defconfig: enable usb3503

Quoted 30 lines · Javier Martinez Canillas

Hello Kevin,
Quoted 27 lines · Kevin Hilman
Quoted 11 lines · riku.voipio at linaro.org
From: Riku Voipio <[email protected]>
CONFIG_USB_HSIC_USB3503 is needed by exynos5250-arndale for the on-board asix network controller. Enable it so networking works with multi_v7_defconfig out of box like it does with exynos_defconfig.
USB3503 is also referenced from exynos4412-odroidu3.dts and exynos5250-spring.dts so this patch should improve multi_v7_defconfig on those platforms as well.
Signed-off-by Riku Voipio <[email protected]>
Tyler pointed me to this in order to get arndale networking on mainline, but looks like this might need to be revisited for current mainline.
I tested this and it doesn't work because as of commit 7de7c6717f2c (ARM: multi_v7_defconfig: Enable Exynos USB PHY) the PHY that this depends on is built as a module in multi_v7_config, so having this driver built-in doesn't help. Even after the PHY driver is loaded, this driver will not detect the hardware.
So instead, I think this driver should be built as a module as well. Testing that, I can get networking by doing loading both the phy and this driver after boot:

Quoted 7 lines

Quoted 3 lines
 # modprobe phy-exynos-usb2
 # modprobe usb3503
Current policy is to have as much as possible built as a module in multi_v7_config so regardless of your issue I think that the patch should be re-spun to change this.

Correct.

Quoted 2 lines

But I wonder why is not working, shouldn't the driver defer and be probed again once the PHY driver probe succeeds?

Yeah, I'm not sure why that isn't working, and didn't look into it.

FWIW, the same problem happens when both are modules. If you modprobe usb3503 first, then the phy, it doesn't work. You have to load the phy before the usb3503.

Kevin

Arnd Bergmann

2015-06-05 12:45 UTC #4 lore raw

PATCH 1/1 ARM: multi_v7_defconfig: enable usb3503

Quoted 11 lines · On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote:

Quoted 3 lines
But I wonder why is not working, shouldn't the driver defer and be probed again once the PHY driver probe succeeds?
Yeah, I'm not sure why that isn't working, and didn't look into it.
FWIW, the same problem happens when both are modules. If you modprobe usb3503 first, then the phy, it doesn't work. You have to load the phy before the usb3503.

The driver does not try to get a reference to the phy, and it does not return -EPROBE_DEFER in any circumstance, so I assume it just runs into an error condition on the first probe and does not try again.

I don't really understand why the driver registers both an i2c_driver and a platform_driver, or if that is required, but it may also complicate getting deferred probing to work here.

Arnd

Riku Voipio

author

2015-09-14 08:35 UTC #5 lore raw

PATCH 1/1 ARM: multi_v7_defconfig: enable usb3503

Quoted 11 lines · Arnd Bergmann

Quoted 9 lines · On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote:
Quoted 3 lines
But I wonder why is not working, shouldn't the driver defer and be probed again once the PHY driver probe succeeds?
Yeah, I'm not sure why that isn't working, and didn't look into it.
FWIW, the same problem happens when both are modules. If you modprobe usb3503 first, then the phy, it doesn't work. You have to load the phy before the usb3503.

Quoted 8 lines

The driver does not try to get a reference to the phy, and it does not return -EPROBE_DEFER in any circumstance, so I assume it just runs into an error condition on the first probe and does not try again.
I don't really understand why the driver registers both an i2c_driver and a platform_driver, or if that is required, but it may also complicate getting deferred probing to work here.

Is someone looking into fixing it? Having to load this as module would be an inconvenience for me, as I like to boot arndale with nfsroot. Yet I understand that eventually I'll need to use an initrd - so not a blocker, just grumpy work.

Riku

Krzysztof Kozlowski

2015-09-15 06:50 UTC #6 lore raw

PATCH 1/1 ARM: multi_v7_defconfig: enable usb3503

2015-09-14 17:35 GMT+09:00 Riku Voipio <[email protected]>:

Quoted 17 lines · Arnd Bergmann

Quoted 15 lines · On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote:
Quoted 9 lines
Quoted 3 lines
But I wonder why is not working, shouldn't the driver defer and be probed again once the PHY driver probe succeeds?
Yeah, I'm not sure why that isn't working, and didn't look into it.
FWIW, the same problem happens when both are modules. If you modprobe usb3503 first, then the phy, it doesn't work. You have to load the phy before the usb3503.
The driver does not try to get a reference to the phy, and it does not return -EPROBE_DEFER in any circumstance, so I assume it just runs into an error condition on the first probe and does not try again.

Quoted 5 lines

Quoted 3 lines
I don't really understand why the driver registers both an i2c_driver and a platform_driver, or if that is required, but it may also complicate getting deferred probing to work here.
Is someone looking into fixing it?

Fixing what? The PHY issue? The driver not supporting deferred probe?

As for module vs builtin, this is somehow orthogonal for me. Although modules are preferred on multi_v7 but in case of boot-essential drivers this should not be a requirement. I also don't use initrd for network boot... however my root is on MMC. Regardless if of that I would expect nfsroot to be working on multi_v7 kernel.

Quoted 1 line

From my point of view this is the same case as USB_NET_SMSC75XX or

USB_NET_SMSC95XX, so:
1. Reviewed-by: Krzysztof Kozlowski <[email protected]>
2. +1 for CONFIG_PHY_SAMSUNG_USB2=y (regardless of fixing issues in the driver)
3. +1 for fixing the PHY driver

Best regards,
Krzysztof

Sjoerd Simons

2015-09-15 08:17 UTC #7 lore raw

PATCH 1/1 ARM: multi_v7_defconfig: enable usb3503

Quoted 30 lines · Krzysztof Kozlowski

2015-09-14 17:35 GMT+09:00 Riku Voipio <[email protected]>:
Quoted 22 lines · Arnd Bergmann
Quoted 20 lines · On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote:
Quoted 5 lines
Quoted 4 lines
But I wonder why is not working, shouldn't the driver defer and
be probed again once the PHY driver probe succeeds?
Quoted 8 lines
Yeah, I'm not sure why that isn't working, and didn't look into it.
FWIW, the same problem happens when both are modules. If you modprobe
usb3503 first, then the phy, it doesn't work. You have to load the phy
before the usb3503.
The driver does not try to get a reference to the phy, and it does
not return -EPROBE_DEFER in any circumstance, so I assume it just runs into an error condition on the first probe and does not try again.
Quoted 6 lines
Quoted 4 lines
I don't really understand why the driver registers both an i2c_driver
and a platform_driver, or if that is required, but it may also complicate getting deferred probing to work here.
Is someone looking into fixing it?

Quoted 7 lines

Fixing what? The PHY issue? The driver not supporting deferred probe?
As for module vs builtin, this is somehow orthogonal for me. Although modules are preferred on multi_v7 but in case of boot-essential drivers this should not be a requirement. I also don't use initrd for network boot... however my root is on MMC. Regardless if of that I would expect nfsroot to be working on multi_v7 kernel.

When posting a set of multi_v7 config changes recently to improve how we support RockChip, Thierry argued the case for building things as modules as much as possible (even if that means needing an initramfs to complete boot)[0]..

You're arguing the exact oposite here, while I can see the points in both arguments (though i'm leaning to agreeing with Thierry) it would be nice to work out a common policy here as multi_v7 seems to be a rather big mismatch currently.

Fwiw, looking at the arm64 defconfig it currently has everything built in. Which isn't too bad as there aren't that many arm64 boards in mainline yet, but I bet it's going to run into similar issues at some point.

0: http://lists.infradead.org/pipermail/linux-rockchip/2015-September/0
04280.html

Quoted 15 lines

From my point of view this is the same case as USB_NET_SMSC75XX or USB_NET_SMSC95XX, so:
1. Reviewed-by: Krzysztof Kozlowski <[email protected]>
2. +1 for CONFIG_PHY_SAMSUNG_USB2=y (regardless of fixing issues in the driver)
3. +1 for fixing the PHY driver
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux -samsung-soc" in
the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 2 lines

Sjoerd Simons <[email protected]>
Collabora Ltd.

Krzysztof Kozlowski

2015-09-15 08:34 UTC #8 lore raw

PATCH 1/1 ARM: multi_v7_defconfig: enable usb3503

Quoted 44 lines · Sjoerd Simons

Quoted 30 lines · Krzysztof Kozlowski
2015-09-14 17:35 GMT+09:00 Riku Voipio <[email protected]>:
Quoted 22 lines · Arnd Bergmann
Quoted 20 lines · On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote:
Quoted 5 lines
Quoted 4 lines
But I wonder why is not working, shouldn't the driver defer and
be probed again once the PHY driver probe succeeds?
Quoted 8 lines
Yeah, I'm not sure why that isn't working, and didn't look into it.
FWIW, the same problem happens when both are modules. If you modprobe
usb3503 first, then the phy, it doesn't work. You have to load the phy
before the usb3503.
The driver does not try to get a reference to the phy, and it does
not return -EPROBE_DEFER in any circumstance, so I assume it just runs into an error condition on the first probe and does not try again.
Quoted 6 lines
Quoted 4 lines
I don't really understand why the driver registers both an i2c_driver
and a platform_driver, or if that is required, but it may also complicate getting deferred probing to work here.
Is someone looking into fixing it?
Quoted 7 lines
Fixing what? The PHY issue? The driver not supporting deferred probe?
As for module vs builtin, this is somehow orthogonal for me. Although modules are preferred on multi_v7 but in case of boot-essential drivers this should not be a requirement. I also don't use initrd for network boot... however my root is on MMC. Regardless if of that I would expect nfsroot to be working on multi_v7 kernel.
When posting a set of multi_v7 config changes recently to improve how we support RockChip, Thierry argued the case for building things as modules as much as possible (even if that means needing an initramfs to complete boot)[0]..

Quoted 4 lines

You're arguing the exact oposite here, while I can see the points in both arguments (though i'm leaning to agreeing with Thierry) it would be nice to work out a common policy here as multi_v7 seems to be a rather big mismatch currently.

Not entirely the exact opposite. Opposite only for stuff important for booting. I agree: put into modules as much as possible. But the difference is in meaning of "possible". It is possible to network boot with network rootfs when the adapter is a module. But it is not possible to do it without initrd. :)

Anyway I agree that conclusion should be made a standard (or policy) so other driver should be converted to 'm' or 'y'.

Quoted 4 lines

Fwiw, looking at the arm64 defconfig it currently has everything built in. Which isn't too bad as there aren't that many arm64 boards in mainline yet, but I bet it's going to run into similar issues at some point.

Indeed, that is the easiest option for development... until Image grows out of device partition.

Best regards,
Krzysztof