From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out-2.itc.rwth-aachen.de ([134.130.5.47]:61195 "EHLO mail-out-2.itc.rwth-aachen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932214AbdK0RTV (ORCPT ); Mon, 27 Nov 2017 12:19:21 -0500 From: Stefan =?ISO-8859-1?Q?Br=FCns?= To: Maxime Ripard CC: , , Rob Herring , Arnd Bergmann , Chen-Yu Tsai , stable Subject: Re: [PATCH] sunxi-rsb: Include OF based modalias in device uevent Date: Mon, 27 Nov 2017 18:19:13 +0100 Message-ID: <2479565.qdx1IVDIGC@pebbles> In-Reply-To: <20171127153502.4wcqtimppgpfklmr@flea.home> References: <20171127153502.4wcqtimppgpfklmr@flea.home> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10581349.nozF8DQEW0"; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: stable-owner@vger.kernel.org List-ID: --nextPart10581349.nozF8DQEW0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Monday, November 27, 2017 4:35:02 PM CET Maxime Ripard wrote: > Hi, >=20 > On Mon, Nov 27, 2017 at 01:17:25PM +0100, Stefan Br=FCns wrote: > > Include the OF-based modalias in the uevent sent when registering devic= es > > on the sunxi RSB bus, so that user space has a chance to autoload the > > kernel module for the device. > >=20 > > Fixes a regression caused by commit 3f241bfa60bd ("arm64: allwinner: a6= 4: > > pine64: Use dcdc1 regulator for mmc0"). When the axp20x-rsb module for > > the AXP803 PMIC is built as a module, it is not loaded and the system > > ends up with an disfunctional MMC controller. > >=20 > > Cc: stable > > Signed-off-by: Stefan Br=FCns > > --- > >=20 > > drivers/bus/sunxi-rsb.c | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > >=20 > > diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c > > index 328ca93781cf..37cb57244cbe 100644 > > --- a/drivers/bus/sunxi-rsb.c > > +++ b/drivers/bus/sunxi-rsb.c > > @@ -173,11 +173,24 @@ static int sunxi_rsb_device_remove(struct device > > *dev)>=20 > > return drv->remove(to_sunxi_rsb_device(dev)); > > =20 > > } > >=20 > > +static int sunxi_rsb_device_uevent(struct device *dev, > > + struct kobj_uevent_env *env) > > +{ > > + int ret; > > + > > + ret =3D of_device_uevent_modalias(dev, env); > > + if (ret !=3D -ENODEV) > > + return ret; >=20 > A comment explaining why we need to ignore the ENODEV error code would > be great here. Lazy answer - everyone else is doing the same, and nobody cared to add an=20 explanation. =46or *some* drivers, this is likely because the same device may be enumera= ted=20 from e.g ACPI or OF, and for an ACPI device -ENODEV will be returned, as dev->of_node is NULL. =46or devices which are only usable in an OF context, this is bogus. Not su= re=20 about sunxi-rsb. > > + return 0; > > +} > > + > >=20 > > static struct bus_type sunxi_rsb_bus =3D { > > =20 > > .name =3D RSB_CTRL_NAME, > > .match =3D sunxi_rsb_device_match, > > .probe =3D sunxi_rsb_device_probe, > > .remove =3D sunxi_rsb_device_remove, > >=20 > > + .uevent =3D sunxi_rsb_device_uevent, >=20 > Any reason to not use of_device_uevent_modalias directly here? *If* sunxi-rsb can be used without OF, then yes, otherwise no. Regards, Stefan =2D-=20 Stefan Br=FCns / Bergstra=DFe 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 --nextPart10581349.nozF8DQEW0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQSwWRWIpJbl0W4DemNvf0o9jP6qUwUCWhxJEQAKCRBvf0o9jP6q U0LNAKCBV/lMdIs8DEtCdNoWC0NuJ807sQCfVZZrJqQAy1nLFJxWl7+FZ7dk8NU= =Cj7c -----END PGP SIGNATURE----- --nextPart10581349.nozF8DQEW0--