Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503

[Sjoerd Simons]

On Tue, 2015-09-15 at 15:50 +0900, Krzysztof Kozlowski wrote:
> 2015-09-14 17:35 GMT+09:00 Riku Voipio :
> > On 5 June 2015 at 15:45, Arnd Bergmann  wrote:
> > > On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote:
> > > > 
> > > > > 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.
> > 
> > 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.

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



> From my point of view this is the same case as USB_NET_SMSC75XX or
> USB_NET_SMSC95XX, so:
> 1. Reviewed-by: Krzysztof Kozlowski 
> 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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sjoerd Simons 
Collabora Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503

[Krzysztof Kozlowski]

On 15.09.2015 17:17, Sjoerd Simons wrote:
> On Tue, 2015-09-15 at 15:50 +0900, Krzysztof Kozlowski wrote:
>> 2015-09-14 17:35 GMT+09:00 Riku Voipio :
>>> On 5 June 2015 at 15:45, Arnd Bergmann  wrote:
 On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote:
>
>> 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.
>>>
>>> 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.
> 
> 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.

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'.


> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503

[Riku Voipio]

On 5 June 2015 at 15:45, Arnd Bergmann  wrote:
> On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote:
>>
>> > 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.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503

[Arnd Bergmann]

On Thursday 04 June 2015 10:47:07 Kevin Hilman wrote:
 
  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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 Hello Kevin,

 On 06/04/2015 03:08 AM, Kevin Hilman wrote:
 riku.voi...@linaro.org writes:
 
 From: Riku Voipio riku.voi...@linaro.org

 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 riku.voi...@linaro.org
 
 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


 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.

 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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503

[Javier Martinez Canillas]

Hello Kevin,

On 06/04/2015 03:08 AM, Kevin Hilman wrote:
 riku.voi...@linaro.org writes:
 
 From: Riku Voipio riku.voi...@linaro.org

 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 riku.voi...@linaro.org
 
 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


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?

 Kevin
 

Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503

[Kevin Hilman]

riku.voi...@linaro.org writes:

 From: Riku Voipio riku.voi...@linaro.org

 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 riku.voi...@linaro.org

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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html