lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 20 Sep 2021 16:26:18 +0200
From:   Frieder Schrempf <>
To:     Heiko Thiery <>,
        Fabio Estevam <>
Cc:     Peter Chen <>, Jun Li <>,
        Yu Kuai <>,
        Sascha Hauer <>,
        Mark Brown <>,
        USB list <>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        linux-kernel <>,
        Shawn Guo <>
Subject: Re: imx8mm board crash in drivers/usb/chipidea/ci_hdrc_imx.c

On 20.09.21 13:05, Heiko Thiery wrote:
> Hi,
> Am Mo., 20. Sept. 2021 um 12:52 Uhr schrieb Fabio Estevam <>:
>> Hi Heiko,
>> On Mon, Sep 20, 2021 at 6:17 AM Heiko Thiery <> wrote:
>>> Now it is clear to me. I used the dtb for my board that had already
>>> changed the phy node and tried to boot the "old" kernel 5.14. Thus no
>>> phy could be found. Nevertheless the kernel should not crash in case
>>> no phy was found.
>> Agreed. The patch I proposed earlier should fix the problem, correct?
> Yes this should do it.

Commit ed5a419bb019 ("usb: chipidea: imx: "fsl,usbphy" phandle is not
mandatory now") explains, that the core driver already covers reading
the "phys" property (see ci_hdrc_probe()):

  Since the chipidea common code support get the USB PHY phandle from
  "phys", the glue layer is not mandatory to get the "fsl,usbphy"
  phandle any more.

This seems to be the reason why ci_hdrc_imx_probe() doesn't return any
error in case "fsl,usbphy" is not set. It expects that the core will
handle data->phy = NULL and already checks for a "phys" property.

Therefore I'm not sure Fabio's fix is the right way to go. Could it be
that the ci_hdrc_imx driver expects that it will be probed before the
ci_hdrc core and this isn't true in Heiko's case?

Powered by blists - more mailing lists