linux-kernel - Re: [RFC PATCH 10/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs

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 linux-cve-announce 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]

Message-ID: <5611c687e6fc86fefb750faf2f726472e22a7d57.camel@fi.rohmeurope.com>
Date:   Tue, 22 Oct 2019 13:19:37 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>
CC:     "dmurphy@...com" <dmurphy@...com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "jacek.anaszewski@...il.com" <jacek.anaszewski@...il.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "pavel@....cz" <pavel@....cz>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>
Subject: Re: [RFC PATCH 10/13] gpio: bd71828: Initial support for ROHM
 BD71828 PMIC GPIOs

Hello Bartosz,

Just a short note at this point.

On Mon, 2019-10-21 at 16:36 +0200, Bartosz Golaszewski wrote:
> pon., 21 paź 2019 o 09:00 Vaittinen, Matti
> <Matti.Vaittinen@...rohmeurope.com> napisał(a):
> > On Thu, 2019-10-17 at 14:45 +0200, Bartosz Golaszewski wrote:
> > > czw., 17 paź 2019 o 11:53 Matti Vaittinen
> > > 
> > > > +static struct platform_driver bd71828_gpio = {
> > > > +       .driver = {
> > > > +               .name = "bd71828-gpio"
> > > > +       },
> > > > +       .probe = bd71828_probe,
> > > > +};
> > > > +
> > > > +module_platform_driver(bd71828_gpio);
> > > > +
> > > > +MODULE_AUTHOR("Matti Vaittinen <
> > > > matti.vaittinen@...rohmeurope.com>
> > > > ");
> > > > +MODULE_DESCRIPTION("BD71828 voltage regulator driver");
> > > > +MODULE_LICENSE("GPL");
> > > 
> > > Don't you need a MODULE_ALIAS() here since this is an MFD sub-
> > > module?
> > 
> > I must admit I don't know the details of how module loading is
> > done. I
> > used system where modules are load by scripts. (I guess the module
> > alias could be used to allow automatic module loading [by udev?])
> > 
> > Can you please educate me - If I add module aliases matching the
> > sub-
> > device name given in in MFD cell - should the sub module loading be
> > automatic when MFD driver gets probed? For some reason I didn't get
> > that working on my test bed. Or maybe I misunderstood something.
> > 
> 
> If the gpio module is a sub-node on the device tree than you may need
> to use a sub-compatible to get the module loaded by udev.
> 
> Bart
> 
> > Eg, this should be enough for GPIO sub-module to be also load:
> > 
> > MFD:
> > static struct mfd_cell bd71828_mfd_cells[] = {
> >         { .name = "bd71828-pmic", },
> >         { .name = "bd71828-gpio", },
> > ...
> > ret = devm_mfd_add_devices(&i2c->dev, PLATFORM_DEVID_AUTO,
> >                            bd71828_mfd_cells,
> >                            ARRAY_SIZE(bd71828_mfd_cells), NULL, 0,
> >                            regmap_irq_get_domain(irq_data));
> > 
> > GPIO driver:
> > MODULE_ALIAS("platform:bd71828-gpio");
> > 
> > I had the sub-devices probed even without the MODULE_ALIAS - but
> > manual
> > loading is required. I will gladly add the alias if it should
> > enable
> > the automatic module loading.

I had some problems with my test setup. After I fixed those I was able
to test the automatic module loading. The sub-devices do not need own
compatible to be load - they only need the correct module_alias:
"platform:sub-device-name-used-in-mfd-cell". If this is added, the
module for sub-device is load when MFD cell with name matching the
alias is instantiated.

So to your original question - yes, MODULE_ALIAS() is needed for
automated loading. No compatible is required then :)

Thanks for pointing me to correct direction here! It's always nice to
learn something new!

Br,
	Matti Vaittinen