ARM: multi_v7_defconfig: Enable USB3503 driver

Message ID 20170928024022.2071-1-linus.luessing@c0d3.blue
State New
Headers show
Series
  • ARM: multi_v7_defconfig: Enable USB3503 driver
Related show

Commit Message

Linus Lüssing Sept. 28, 2017, 2:40 a.m.
The Odroid U3 (Exynos 4412 based) for instance needs this driver,
otherwise its USB hub will not come up.

exynos_defconfig already has this enabled as built-in, too. So
just doing the same here in multi_v7_defconfig.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

---
Thanks to Tobias Jakobi, who indirectly made me aware of why USB
did not work for me.

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

Comments

Krzysztof Kozlowski Sept. 28, 2017, 6:21 a.m. | #1
On Thu, Sep 28, 2017 at 4:40 AM, Linus Lüssing <linus.luessing@c0d3.blue> wrote:
> The Odroid U3 (Exynos 4412 based) for instance needs this driver,
> otherwise its USB hub will not come up.
>
> exynos_defconfig already has this enabled as built-in, too. So
> just doing the same here in multi_v7_defconfig.
>
> Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
>
> ---
> Thanks to Tobias Jakobi, who indirectly made me aware of why USB
> did not work for me.
>
>  arch/arm/configs/multi_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Partially this was part of my patchset fixing powersequence for
usb3503 and lan9730:
https://patchwork.kernel.org/patch/9502939/
but that patch waits still for power sequence.

Anyway please define this as a module (unless it can't... but it
worked in my case).

Best regards,
Krzysztof
Linus Lüssing Sept. 28, 2017, 10:43 a.m. | #2
Hi Krzysztof,

Thanks for your quick reply!

On Thu, Sep 28, 2017 at 08:21:26AM +0200, Krzysztof Kozlowski wrote:
> [...]
> Anyway please define this as a module (unless it can't... but it
> worked in my case).

In that case you used an initrd, right? I see various cases of USB
built-ins, like CONFIG_USB_STORAGE=y, CONFIG_USB_DWC2=y and so on in
multi_v7_defconfig. So my impression was that multi_v7_defconfig was
supposed to allow booting a rootfs from a USB storage device even
without an initrd.

Let me know if that impression is wrong though, I'll happily resend
(and test) the patch with CONFIG_USB_HSIC_USB3503=m then :-).

Regards, Linus
Krzysztof Kozlowski Sept. 28, 2017, 12:22 p.m. | #3
On Thu, Sep 28, 2017 at 12:43 PM, Linus Lüssing
<linus.luessing@c0d3.blue> wrote:
> Hi Krzysztof,
>
> Thanks for your quick reply!
>
> On Thu, Sep 28, 2017 at 08:21:26AM +0200, Krzysztof Kozlowski wrote:
>> [...]
>> Anyway please define this as a module (unless it can't... but it
>> worked in my case).
>
> In that case you used an initrd, right? I see various cases of USB
> built-ins, like CONFIG_USB_STORAGE=y, CONFIG_USB_DWC2=y and so on in
> multi_v7_defconfig. So my impression was that multi_v7_defconfig was
> supposed to allow booting a rootfs from a USB storage device even
> without an initrd.

We use modules for multi_v7 as much as possible with that exception as
fair as I remember - no need of initramfs/initrd for boots. If this is
your intention, please mention this in commit message ("using usb3503
as builtin to provide boot from USB without initrd/initramfs").

Best regards,
Krzysztof

Patch

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 0cacdbf..c2484ef 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -693,6 +693,7 @@  CONFIG_USB_MUSB_HDRC=m
 CONFIG_USB_MUSB_SUNXI=m
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC2=y
+CONFIG_USB_HSIC_USB3503=y
 CONFIG_USB_CHIPIDEA=y
 CONFIG_USB_CHIPIDEA_UDC=y
 CONFIG_USB_CHIPIDEA_HOST=y