[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8ad3c0ba-8e84-b75c-7873-882f90fa39d5@ti.com>
Date: Sun, 11 Jun 2017 23:42:14 +0530
From: Keerthy <j-keerthy@...com>
To: Javier Martinez Canillas <javier@...hile0.org>
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 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 <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.
>
> 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?
- Keerthy
>
>>
>> [0]: https://lkml.org/lkml/2017/5/19/394
>>
>> Best regards,
>> Javier
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Powered by blists - more mailing lists