Hello,
This is a resend of the patches that were not picked from the series
"[PATCH 00/27] Export I2C and OF module aliases in missing drivers" [0]
posted about a month ago.
The patches have no dependencies and can be picked individually by the
relevant maintainer.
I preferred to resend instead of sending a naked ping for each patch
that I got no answer.
Best regards,
Javier
Javier Martinez Canillas (7):
i2c: core: Export I2C module alias information in dummy driver
backlight: tosa: Export I2C module alias information
usb: phy: isp1301: Export I2C module alias information
ALSA: ppc: keywest: Export I2C module alias information
extcon: Export OF module alias information in missing drivers
leds: Export OF module alias information in missing drivers
regulator: isl9305: Export OF module alias information
drivers/extcon/extcon-rt8973a.c | 1 +
drivers/extcon/extcon-sm5502.c | 1 +
drivers/i2c/i2c-core.c | 1 +
drivers/leds/leds-pca963x.c | 1 +
drivers/leds/leds-tca6507.c | 1 +
drivers/regulator/isl9305.c | 1 +
drivers/usb/phy/phy-isp1301.c | 1 +
drivers/video/backlight/tosa_bl.c | 1 +
sound/ppc/keywest.c | 1 +
9 files changed, 9 insertions(+)
--
2.4.3
The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: I2C id table or OF match table).
So drivers needs to export the I2C id table and this be built into
the module or udev won't have the necessary information to autoload
the needed driver module when the device is added.
Signed-off-by: Javier Martinez Canillas <[email protected]>
---
drivers/i2c/i2c-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a6780289c61d..46536834920c 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1041,6 +1041,7 @@ static const struct i2c_device_id dummy_id[] = {
{ "dummy", 0 },
{ },
};
+MODULE_DEVICE_TABLE(i2c, dummy_id);
static int dummy_probe(struct i2c_client *client,
const struct i2c_device_id *id)
--
2.4.3
The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: I2C id table or OF match table).
So drivers needs to export the I2C id table and this be built into
the module or udev won't have the necessary information to autoload
the needed driver module when the device is added.
Signed-off-by: Javier Martinez Canillas <[email protected]>
---
drivers/video/backlight/tosa_bl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/tosa_bl.c b/drivers/video/backlight/tosa_bl.c
index 3ad676558c80..83742d806391 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -158,6 +158,7 @@ static const struct i2c_device_id tosa_bl_id[] = {
{ "tosa-bl", 0 },
{ },
};
+MODULE_DEVICE_TABLE(i2c, tosa_bl_id);
static struct i2c_driver tosa_bl_driver = {
.driver = {
--
2.4.3
The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.
Signed-off-by: Javier Martinez Canillas <[email protected]>
---
drivers/usb/phy/phy-isp1301.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
index 8a55b37d1a02..db68156568e6 100644
--- a/drivers/usb/phy/phy-isp1301.c
+++ b/drivers/usb/phy/phy-isp1301.c
@@ -31,6 +31,7 @@ static const struct i2c_device_id isp1301_id[] = {
{ "isp1301", 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, isp1301_id);
static struct i2c_client *isp1301_i2c_client;
--
2.4.3
The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.
Signed-off-by: Javier Martinez Canillas <[email protected]>
---
sound/ppc/keywest.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/ppc/keywest.c b/sound/ppc/keywest.c
index 6120a067494a..f644a8c57e0a 100644
--- a/sound/ppc/keywest.c
+++ b/sound/ppc/keywest.c
@@ -101,6 +101,7 @@ static const struct i2c_device_id keywest_i2c_id[] = {
{ "keywest", 0 }, /* instantiated by us if needed */
{ }
};
+MODULE_DEVICE_TABLE(i2c, keywest_i2c_id);
static struct i2c_driver keywest_driver = {
.driver = {
--
2.4.3
The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: I2C id table or OF match table).
So drivers needs to export the I2C id table and this be built into
the module or udev won't have the necessary information to autoload
the needed driver module when the device is added.
But this means that OF-only drivers needs to have both OF and I2C id
tables that have to be kept in sync and also the dev node compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same I2C device name for example.
To avoid the above, the I2C core behavior may be changed in the future
to not require an SPI device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table even when
is unused now to prevent breaking module loading when the core changes.
Signed-off-by: Javier Martinez Canillas <[email protected]>
---
drivers/extcon/extcon-rt8973a.c | 1 +
drivers/extcon/extcon-sm5502.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
index 11592e980bc1..3428b6aae1a2 100644
--- a/drivers/extcon/extcon-rt8973a.c
+++ b/drivers/extcon/extcon-rt8973a.c
@@ -658,6 +658,7 @@ static const struct of_device_id rt8973a_dt_match[] = {
{ .compatible = "richtek,rt8973a-muic" },
{ },
};
+MODULE_DEVICE_TABLE(of, rt8973a_dt_match);
#ifdef CONFIG_PM_SLEEP
static int rt8973a_muic_suspend(struct device *dev)
diff --git a/drivers/extcon/extcon-sm5502.c b/drivers/extcon/extcon-sm5502.c
index 0ffefefa2e26..92ae48415fb2 100644
--- a/drivers/extcon/extcon-sm5502.c
+++ b/drivers/extcon/extcon-sm5502.c
@@ -650,6 +650,7 @@ static const struct of_device_id sm5502_dt_match[] = {
{ .compatible = "siliconmitus,sm5502-muic" },
{ },
};
+MODULE_DEVICE_TABLE(of, sm5502_dt_match);
#ifdef CONFIG_PM_SLEEP
static int sm5502_muic_suspend(struct device *dev)
--
2.4.3
The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: I2C id table or OF match table).
So drivers needs to export the I2C id table and this be built into
the module or udev won't have the necessary information to autoload
the needed driver module when the device is added.
But this means that OF-only drivers needs to have both OF and I2C id
tables that have to be kept in sync and also the dev node compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same I2C device name for example.
To avoid the above, the I2C core behavior may be changed in the future
to not require an SPI device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table even when
is unused now to prevent breaking module loading when the core changes.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
---
drivers/leds/leds-pca963x.c | 1 +
drivers/leds/leds-tca6507.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
index 3f63a1bfdc4f..41f269fe0920 100644
--- a/drivers/leds/leds-pca963x.c
+++ b/drivers/leds/leds-pca963x.c
@@ -332,6 +332,7 @@ static const struct of_device_id of_pca963x_match[] = {
{ .compatible = "nxp,pca9635", },
{},
};
+MODULE_DEVICE_TABLE(of, of_pca963x_match);
#else
static struct pca963x_platform_data *
pca963x_dt_init(struct i2c_client *client, struct pca963x_chipdef *chip)
diff --git a/drivers/leds/leds-tca6507.c b/drivers/leds/leds-tca6507.c
index c1f910981781..edbecc4ca2da 100644
--- a/drivers/leds/leds-tca6507.c
+++ b/drivers/leds/leds-tca6507.c
@@ -735,6 +735,7 @@ static const struct of_device_id of_tca6507_leds_match[] = {
{ .compatible = "ti,tca6507", },
{},
};
+MODULE_DEVICE_TABLE(of, of_tca6507_leds_match);
#else
static struct tca6507_platform_data *
--
2.4.3
The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: I2C id table or OF match table).
So drivers needs to export the I2C id table and this be built into
the module or udev won't have the necessary information to autoload
the needed driver module when the device is added.
But this means that OF-only drivers needs to have both OF and I2C id
tables that have to be kept in sync and also the dev node compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same I2C device name for example.
To avoid the above, the I2C core behavior may be changed in the future
to not require an SPI device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table even when
is unused now to prevent breaking module loading when the core changes.
Signed-off-by: Javier Martinez Canillas <[email protected]>
---
drivers/regulator/isl9305.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/isl9305.c b/drivers/regulator/isl9305.c
index eae9d1ffe641..257c1943e753 100644
--- a/drivers/regulator/isl9305.c
+++ b/drivers/regulator/isl9305.c
@@ -183,6 +183,7 @@ static const struct of_device_id isl9305_dt_ids[] = {
{ .compatible = "isil,isl9305h" },
{},
};
+MODULE_DEVICE_TABLE(of, isl9305_dt_ids);
#endif
static const struct i2c_device_id isl9305_i2c_id[] = {
--
2.4.3
On Tue, 25 Aug 2015, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
> regardless of the mechanism that was used to register the device
> (i.e: OF or board code) and the table that is used later to match
> the driver with the device (i.e: I2C id table or OF match table).
>
> So drivers needs to export the I2C id table and this be built into
> the module or udev won't have the necessary information to autoload
> the needed driver module when the device is added.
>
> Signed-off-by: Javier Martinez Canillas <[email protected]>
>
> ---
>
> drivers/video/backlight/tosa_bl.c | 1 +
> 1 file changed, 1 insertion(+)
Applied, thanks.
> diff --git a/drivers/video/backlight/tosa_bl.c b/drivers/video/backlight/tosa_bl.c
> index 3ad676558c80..83742d806391 100644
> --- a/drivers/video/backlight/tosa_bl.c
> +++ b/drivers/video/backlight/tosa_bl.c
> @@ -158,6 +158,7 @@ static const struct i2c_device_id tosa_bl_id[] = {
> { "tosa-bl", 0 },
> { },
> };
> +MODULE_DEVICE_TABLE(i2c, tosa_bl_id);
>
> static struct i2c_driver tosa_bl_driver = {
> .driver = {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On 08/25/2015 08:31 AM, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
> regardless of the mechanism that was used to register the device
> (i.e: OF or board code) and the table that is used later to match
> the driver with the device (i.e: I2C id table or OF match table).
>
> So drivers needs to export the I2C id table and this be built into
> the module or udev won't have the necessary information to autoload
> the needed driver module when the device is added.
>
> But this means that OF-only drivers needs to have both OF and I2C id
> tables that have to be kept in sync and also the dev node compatible
> manufacturer prefix is stripped when reporting the MODALIAS. Which can
> lead to issues if two vendors use the same I2C device name for example.
>
> To avoid the above, the I2C core behavior may be changed in the future
> to not require an SPI device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table even when
> is unused now to prevent breaking module loading when the core changes.
>
> Signed-off-by: Javier Martinez Canillas <[email protected]>
> Acked-by: Jacek Anaszewski <[email protected]>
>
> ---
>
> drivers/leds/leds-pca963x.c | 1 +
> drivers/leds/leds-tca6507.c | 1 +
> 2 files changed, 2 insertions(+)
Merged, thanks.
--
Best Regards,
Jacek Anaszewski
On Tue, 25 Aug 2015 08:31:14 +0200,
Javier Martinez Canillas wrote:
>
> The I2C core always reports the MODALIAS uevent as "i2c:<client name"
> regardless if the driver was matched using the I2C id_table or the
> of_match_table. So the driver needs to export the I2C table and this
> be built into the module or udev won't have the necessary information
> to auto load the correct module when the device is added.
>
> Signed-off-by: Javier Martinez Canillas <[email protected]>
Applied, thanks.
Takashi
>
> ---
>
> sound/ppc/keywest.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/ppc/keywest.c b/sound/ppc/keywest.c
> index 6120a067494a..f644a8c57e0a 100644
> --- a/sound/ppc/keywest.c
> +++ b/sound/ppc/keywest.c
> @@ -101,6 +101,7 @@ static const struct i2c_device_id keywest_i2c_id[] = {
> { "keywest", 0 }, /* instantiated by us if needed */
> { }
> };
> +MODULE_DEVICE_TABLE(i2c, keywest_i2c_id);
>
> static struct i2c_driver keywest_driver = {
> .driver = {
> --
> 2.4.3
>
> .
>
On Tue, Aug 25, 2015 at 08:31:17AM +0200, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
> regardless of the mechanism that was used to register the device
> (i.e: OF or board code) and the table that is used later to match
> the driver with the device (i.e: I2C id table or OF match table).
>
> So drivers needs to export the I2C id table and this be built into
> the module or udev won't have the necessary information to autoload
> the needed driver module when the device is added.
>
> But this means that OF-only drivers needs to have both OF and I2C id
> tables that have to be kept in sync and also the dev node compatible
> manufacturer prefix is stripped when reporting the MODALIAS. Which can
> lead to issues if two vendors use the same I2C device name for example.
>
> To avoid the above, the I2C core behavior may be changed in the future
> to not require an SPI device table for OF-only drivers and report the
> OF module alias. So, it's better to also export the OF table even when
> is unused now to prevent breaking module loading when the core changes.
So, on the one hand detailed commit messages are nice. On the other
hand if they wander too far off point it can be hard to sustain
interest and one can glaze over a bit. All the above really needs to
say is that if we want to use the OF alias table we need to export it.
Hello Mark,
On 08/25/2015 06:20 PM, Mark Brown wrote:
> On Tue, Aug 25, 2015 at 08:31:17AM +0200, Javier Martinez Canillas wrote:
>> The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
>> regardless of the mechanism that was used to register the device
>> (i.e: OF or board code) and the table that is used later to match
>> the driver with the device (i.e: I2C id table or OF match table).
>>
>> So drivers needs to export the I2C id table and this be built into
>> the module or udev won't have the necessary information to autoload
>> the needed driver module when the device is added.
>>
>> But this means that OF-only drivers needs to have both OF and I2C id
>> tables that have to be kept in sync and also the dev node compatible
>> manufacturer prefix is stripped when reporting the MODALIAS. Which can
>> lead to issues if two vendors use the same I2C device name for example.
>>
>> To avoid the above, the I2C core behavior may be changed in the future
>> to not require an SPI device table for OF-only drivers and report the
>> OF module alias. So, it's better to also export the OF table even when
>> is unused now to prevent breaking module loading when the core changes.
>
> So, on the one hand detailed commit messages are nice. On the other
> hand if they wander too far off point it can be hard to sustain
> interest and one can glaze over a bit. All the above really needs to
> say is that if we want to use the OF alias table we need to export it.
>
Ok, I wanted to explain why needs to be added even if currently
is not used. But I'll post a v2 with a shorter commit message.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
On Tue, Aug 25, 2015 at 07:33:36PM +0200, Javier Martinez Canillas wrote:
> > So, on the one hand detailed commit messages are nice. On the other
> > hand if they wander too far off point it can be hard to sustain
> > interest and one can glaze over a bit. All the above really needs to
> > say is that if we want to use the OF alias table we need to export it.
> Ok, I wanted to explain why needs to be added even if currently
> is not used. But I'll post a v2 with a shorter commit message.
No need, I already applied this.
On Tue, Aug 25, 2015 at 08:31:11AM +0200, Javier Martinez Canillas wrote:
> The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
> regardless of the mechanism that was used to register the device
> (i.e: OF or board code) and the table that is used later to match
> the driver with the device (i.e: I2C id table or OF match table).
>
> So drivers needs to export the I2C id table and this be built into
> the module or udev won't have the necessary information to autoload
> the needed driver module when the device is added.
>
> Signed-off-by: Javier Martinez Canillas <[email protected]>
The dummy driver is always loaded when the i2c core inits.
Hello Wolfram,
On 08/26/2015 06:55 PM, Wolfram Sang wrote:
> On Tue, Aug 25, 2015 at 08:31:11AM +0200, Javier Martinez Canillas wrote:
>> The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
>> regardless of the mechanism that was used to register the device
>> (i.e: OF or board code) and the table that is used later to match
>> the driver with the device (i.e: I2C id table or OF match table).
>>
>> So drivers needs to export the I2C id table and this be built into
>> the module or udev won't have the necessary information to autoload
>> the needed driver module when the device is added.
>>
>> Signed-off-by: Javier Martinez Canillas <[email protected]>
>
> The dummy driver is always loaded when the i2c core inits.
>
Ok, I wondered if that was the case but I
was not sure so I posted it just in case.
Then this patch should be dropped.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
> > The dummy driver is always loaded when the i2c core inits.
> >
>
> Ok, I wondered if that was the case but I
> was not sure so I posted it just in case.
Check the source code, this part is pretty obvious...
Hello Wolfram,
On 08/31/2015 10:31 PM, Wolfram Sang wrote:
>
>>> The dummy driver is always loaded when the i2c core inits.
>>>
>>
>> Ok, I wondered if that was the case but I
>> was not sure so I posted it just in case.
>
> Check the source code, this part is pretty obvious...
>
Yes, sorry for missing that obvious detail...
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
On Tue, Sep 01, 2015 at 12:30:22AM +0200, Javier Martinez Canillas wrote:
> Hello Wolfram,
>
> On 08/31/2015 10:31 PM, Wolfram Sang wrote:
> >
> >>> The dummy driver is always loaded when the i2c core inits.
> >>>
> >>
> >> Ok, I wondered if that was the case but I
> >> was not sure so I posted it just in case.
> >
> > Check the source code, this part is pretty obvious...
> >
>
> Yes, sorry for missing that obvious detail...
No problem, now you know :)