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:   Sun, 11 Jun 2017 21:51:37 +0200
From:   Javier Martinez Canillas <>
To:     Keerthy <>
Cc:     Enric Balletbo Serra <>,
        Lee Jones <>,
        Tony Lindgren <>,
        Mark Brown <>,
        Jingoo Han <>,
        Bartlomiej Zolnierkiewicz <>,
        Tero Kristo <>,
        linux-kernel <>,
        "" <>
Subject: Re: [PATCH v2] mfd: tps65217: Introduce dependency on CONFIG_OF

Hello Keerthy,

On Sun, Jun 11, 2017 at 8:12 PM, Keerthy <> wrote:
> On Sunday 11 June 2017 10:50 AM, Keerthy wrote:
>> On Friday 09 June 2017 05:18 AM, Javier Martinez Canillas wrote:
>>> On Fri, Jun 9, 2017 at 1:18 AM, Keerthy <> 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.
>> Thanks for clarifying!
>>>> 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.
>> Okay.
> Javier,
> I found one instance where in the config is tristate MFD_MAX77686.
> The driver already seems to be using probe_new.
> mfd: max77686: Use the struct i2c_driver .probe_new instead of .probe
> So for the above module auto probe would be broken?

Yes, and to make things even worse I see that I was the author of that
commit... so I missed that when posting the series :(

Now, arguably no one would build the MAX77686 as a module since the
regulators provided by that PMIC need to be enabled very early in the
boot process or the system will hang. Both exynos_defconfig and
multi_v7_defconfig have it as built-in. But yes, this is a regression
and the patch should be reverted (or maybe just wait for the I2C core
to report a proper modalias since no one complained, not sure what's
better for this driver).

> - Keerthy

Best regards,

Powered by blists - more mailing lists