lists.openwall.net | 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
| ||
|
Date: Mon, 20 Sep 2021 17:50:45 -0300 From: Fabio Estevam <festevam@...il.com> To: Frieder Schrempf <frieder.schrempf@...tron.de> Cc: Heiko Thiery <heiko.thiery@...il.com>, Peter Chen <peter.chen@....com>, Jun Li <jun.li@....com>, Yu Kuai <yukuai3@...wei.com>, Sascha Hauer <s.hauer@...gutronix.de>, Mark Brown <broonie@...nel.org>, USB list <linux-usb@...r.kernel.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@...ts.infradead.org>, linux-kernel <linux-kernel@...r.kernel.org>, Shawn Guo <shawnguo@...nel.org> Subject: Re: imx8mm board crash in drivers/usb/chipidea/ci_hdrc_imx.c Hi Frieder, On Mon, Sep 20, 2021 at 11:26 AM Frieder Schrempf <frieder.schrempf@...tron.de> wrote: > 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. chipidea core populates ci->usb_phy when phys is used. The charger detection function only checks data->usb_phy, so they don't see ci->usb_phy that was populated by the chipidea core. We could change the signature of all charger detection functions to receive struct ci_hdrc *ci, but that will be a huge patch that will probably not meet the stable requirements, so I think to minimally fix stable we should go with the proposed fix I suggested. > > 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