We're using imx_v6_v7_defconfig on our Wandboards. After upgrading to
v4.14.67, reboot no longer works (or, well, takes a very long time when
the watchdog is configured).
v4.14.66 works fine, the breakage bisects to
2059e527a659cf16d6bb709f1c8509f7a7623fc4 (ARM: imx_v6_v7_defconfig:
Select ULPI support), and reverting that on top of v4.14.67 again works.
Rasmus
On 2018-08-29 11:55, Rasmus Villemoes wrote:
> We're using imx_v6_v7_defconfig on our Wandboards. After upgrading to
> v4.14.67, reboot no longer works (or, well, takes a very long time when
> the watchdog is configured).
>
> v4.14.66 works fine, the breakage bisects to
> 2059e527a659cf16d6bb709f1c8509f7a7623fc4 (ARM: imx_v6_v7_defconfig:
> Select ULPI support), and reverting that on top of v4.14.67 again works.
FWIW, v4.18 (the mainline release containing the upstream commit
157bcc0609) works fine, while v4.17.19 which also has that commit
backported (as df06ca1f56) fails. So I'm guessing there must be some
other commits in v4.18 that happen to make imx_v6_v7_defconfig work.
Rasmus
On 2018-08-29 12:55, Rasmus Villemoes wrote:
> On 2018-08-29 11:55, Rasmus Villemoes wrote:
>> We're using imx_v6_v7_defconfig on our Wandboards. After upgrading to
>> v4.14.67, reboot no longer works (or, well, takes a very long time when
>> the watchdog is configured).
>>
>> v4.14.66 works fine, the breakage bisects to
>> 2059e527a659cf16d6bb709f1c8509f7a7623fc4 (ARM: imx_v6_v7_defconfig:
>> Select ULPI support), and reverting that on top of v4.14.67 again works.
>
> FWIW, v4.18 (the mainline release containing the upstream commit
> 157bcc0609) works fine, while v4.17.19 which also has that commit
> backported (as df06ca1f56) fails. So I'm guessing there must be some
> other commits in v4.18 that happen to make imx_v6_v7_defconfig work.
OK, so v4.18-rc4 is also broken. Bisecting between that and v4.18 points
to a930d8bd94d (usb: chipidea: Always build ULPI code) introduced in
-rc7. The Makefile/Kconfig parts of that commit should not make any
difference wrt. 2059e527a6, since that commit explicitly set
USB_CHIPIDEA_ULPI, so we compile the same TUs with or without
a930d8bd94d. However, a930d8bd94d also adds this hunk
diff --git a/drivers/usb/chipidea/ulpi.c b/drivers/usb/chipidea/ulpi.c
index 6da42dcd2888..dfec07e8ae1d 100644
--- a/drivers/usb/chipidea/ulpi.c
+++ b/drivers/usb/chipidea/ulpi.c
@@ -95,6 +95,9 @@ int ci_ulpi_resume(struct ci_hdrc *ci)
{
int cnt = 100000;
+ if (ci->platdata->phy_mode != USBPHY_INTERFACE_MODE_ULPI)
+ return 0;
+
while (cnt-- > 0) {
if (hw_read(ci, OP_ULPI_VIEWPORT, ULPI_SYNC_STATE))
return 0;
and indeed just adding that on top of v4.14.67 makes it work again.
I don't know what the best fix for -stable is; the hunk above is the
minimal fix, but does not correspond to a mainline commit. a930d8bd94d
does cherrypick cleanly to v4.14.67, so might be the better option.
Rasmus
Hi Rasmus,
> On 2018-08-29 11:55, Rasmus Villemoes wrote:
>> We're using imx_v6_v7_defconfig on our Wandboards. After upgrading to
>> v4.14.67, reboot no longer works (or, well, takes a very long time when
>> the watchdog is configured).
>>
>> v4.14.66 works fine, the breakage bisects to
>> 2059e527a659cf16d6bb709f1c8509f7a7623fc4 (ARM: imx_v6_v7_defconfig:
>> Select ULPI support), and reverting that on top of v4.14.67 again works.
>
> FWIW, v4.18 (the mainline release containing the upstream commit
> 157bcc0609) works fine, while v4.17.19 which also has that commit
> backported (as df06ca1f56) fails. So I'm guessing there must be some
> other commits in v4.18 that happen to make imx_v6_v7_defconfig work.
Thanks for reporting.
Commit 157bcc06094c3 ("ARM: imx_v6_v7_defconfig: Select ULPI support")
was meant to be applied for 4.18 only.
I think we should revert it from earlier stable versions.
Thanks
Hi Rasmus,
On Wed, Aug 29, 2018 at 10:57 AM, Fabio Estevam <[email protected]> wrote:
> Hi Rasmus,
>
>> On 2018-08-29 11:55, Rasmus Villemoes wrote:
>>> We're using imx_v6_v7_defconfig on our Wandboards. After upgrading to
>>> v4.14.67, reboot no longer works (or, well, takes a very long time when
>>> the watchdog is configured).
>>>
>>> v4.14.66 works fine, the breakage bisects to
>>> 2059e527a659cf16d6bb709f1c8509f7a7623fc4 (ARM: imx_v6_v7_defconfig:
>>> Select ULPI support), and reverting that on top of v4.14.67 again works.
>>
>> FWIW, v4.18 (the mainline release containing the upstream commit
>> 157bcc0609) works fine, while v4.17.19 which also has that commit
>> backported (as df06ca1f56) fails. So I'm guessing there must be some
>> other commits in v4.18 that happen to make imx_v6_v7_defconfig work.
>
> Thanks for reporting.
>
> Commit 157bcc06094c3 ("ARM: imx_v6_v7_defconfig: Select ULPI support")
> was meant to be applied for 4.18 only.
>
> I think we should revert it from earlier stable versions.
Or a better solution would be to port
a930d8bd94d8db7715d1af74299f710b1fb22fc8 from upstream.
Please test the attached patch adjusted for 4.14.67.
Thanks
Hi Rasmus and Greg,
On Wed, Aug 29, 2018 at 10:57 AM, Fabio Estevam <[email protected]> wrote:
> Thanks for reporting.
>
> Commit 157bcc06094c3 ("ARM: imx_v6_v7_defconfig: Select ULPI support")
> was meant to be applied for 4.18 only.
>
> I think we should revert it from earlier stable versions.
Yes, the simplest fix is indeed to revert this commit from the older
stable trees.
I have sent the revert patches for 4.4, 4.9, 4.14 and 4.17 stable trees.
Thanks