From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Sjoerd Simons <sjoerd.simons@collabora.co.uk>,
Riku Voipio <riku.voipio@linaro.org>,
Thierry Reding <treding@nvidia.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
linux-samsung-soc@vger.kernel.org,
Tyler Baker <tyler.baker@linaro.org>,
Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Kevin Hilman <khilman@kernel.org>, heiko <heiko@sntech.de>
Subject: Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503
Date: Tue, 15 Sep 2015 17:34:46 +0900 [thread overview]
Message-ID: <55F7D826.6060104@samsung.com> (raw)
In-Reply-To: <1442305045.8733.20.camel@collabora.co.uk>
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 <riku.voipio@linaro.org>:
>>> On 5 June 2015 at 15:45, Arnd Bergmann <arnd@arndb.de> 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
WARNING: multiple messages have this Message-ID (diff)
From: k.kozlowski@samsung.com (Krzysztof Kozlowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: multi_v7_defconfig: enable usb3503
Date: Tue, 15 Sep 2015 17:34:46 +0900 [thread overview]
Message-ID: <55F7D826.6060104@samsung.com> (raw)
In-Reply-To: <1442305045.8733.20.camel@collabora.co.uk>
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 <riku.voipio@linaro.org>:
>>> On 5 June 2015 at 15:45, Arnd Bergmann <arnd@arndb.de> 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
next prev parent reply other threads:[~2015-09-15 8:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 13:54 [PATCH] ARM: multi_v7_defconfig: enable usb3503 riku.voipio
2015-03-13 13:54 ` riku.voipio at linaro.org
2015-06-04 1:08 ` Kevin Hilman
2015-06-04 1:08 ` Kevin Hilman
2015-06-04 6:38 ` Javier Martinez Canillas
2015-06-04 6:38 ` Javier Martinez Canillas
2015-06-04 17:47 ` Kevin Hilman
2015-06-04 17:47 ` Kevin Hilman
2015-06-05 12:45 ` Arnd Bergmann
2015-06-05 12:45 ` Arnd Bergmann
2015-09-14 8:35 ` Riku Voipio
2015-09-14 8:35 ` Riku Voipio
2015-09-15 6:50 ` Krzysztof Kozlowski
2015-09-15 6:50 ` Krzysztof Kozlowski
2015-09-15 8:17 ` Sjoerd Simons
2015-09-15 8:17 ` Sjoerd Simons
2015-09-15 8:34 ` Krzysztof Kozlowski [this message]
2015-09-15 8:34 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F7D826.6060104@samsung.com \
--to=k.kozlowski@samsung.com \
--cc=arnd@arndb.de \
--cc=heiko@sntech.de \
--cc=javier.martinez@collabora.co.uk \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=riku.voipio@linaro.org \
--cc=sjoerd.simons@collabora.co.uk \
--cc=treding@nvidia.com \
--cc=tyler.baker@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.