linux-kernel - Re: [PATCH v2] mfd: tps65217: Introduce dependency on CONFIG

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]

Date:   Fri, 9 Jun 2017 01:48:16 +0200
From:   Javier Martinez Canillas <javier@...hile0.org>
To:     Keerthy <j-keerthy@...com>
Cc:     Enric Balletbo Serra <eballetbo@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Tony Lindgren <tony@...mide.com>,
        Mark Brown <broonie@...nel.org>,
        Jingoo Han <jingoohan1@...il.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Tero Kristo <t-kristo@...com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: Re: [PATCH v2] mfd: tps65217: Introduce dependency on CONFIG_OF

On Fri, Jun 9, 2017 at 1:18 AM, Keerthy <j-keerthy@...com> wrote:

[snip]

>>
>>>>
>>>> -static const struct i2c_device_id tps65217_id_table[] = {
>>>> -       {"tps65217", TPS65217},
>>>> -       { /* sentinel */ }
>>>> -};
>>>> -MODULE_DEVICE_TABLE(i2c, tps65217_id_table);
>>
>> Unfortunately you can't get rid of this table (yet) since the I2C
>> subsystem always reports a MODALIAS of the form "i2c:tps65217" even
>> when the devices have been registered via OF. There are only a couple
>> of drivers more to clean-up and then I'll post a patch that fixes the
>> I2C core to report a proper OF modalias. But for now, removing will
>> mean that module autoload will be broken for this driver.
>
> So this means whole logic of probe_new without i2c_device_id is not
> ready? I will have to revert all that logic right?
>

No, that's not what I meant.

It's absolutely correct for drivers that can't be build as a module
(i.e: have a boolean instead of tristate Kconfig symbol) or if you
want to get rid of the struct i2c_device_id pointed passed to your
probe callback since isn't used in the driver.

But it's not enough to get rid of the struct i2c_device_id table for
the reason I mentioned before.

> Lee Jones,
>
> Does that mean even for LP87565 driver we need MODULE_DEVICE_TABLE for
> module autoload?
>

I guess you are talking about [0], right?

Yes, it's needed because the driver can be built as a module.

[0]: https://lkml.org/lkml/2017/5/19/394

Best regards,
Javier