[PATCH 00/18] Export SPI and OF module aliases in missing drivers

[PATCH 00/18] Export SPI and OF module aliases in missing drivers

[Javier Martinez Canillas]

Hello,

Short version:

This patch series is the SPI equivalent of the I2C one posted before [0].

This series add the missing MODULE_DEVICE_TABLE() for OF and SPI tables
to export that information so modules have the correct aliases built-in
and autoloading works correctly.

Longer version:

The SPI core always reports the MODALIAS uevent as "spi:<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: SPI id table or OF match table).

But this means that OF-only drivers needs to have both OF and SPI id
tables that have to be kept in sync and also the device node's compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same SPI device name for example.

Also, there are many SPI drivers whose module auto-loading is not working
because of this fact that the SPI core always reports the MODALIAS as
spi:<modalias> and many developers didn't expect this since is not how
other subsystems behave.

I've identified SPI drivers with 3 types of different issues:

a) Those that have an spi_table but are not exported. The match works
   if the driver is built-in but since the ID table is not exported,
   module auto-load won't work.

b) Those that have a of_table but are not exported. This is currently
   not an issue since even when the of_table is used to match the dev
   with the driver, an OF modalias is not reported by the SPI core.
   But if the SPI core is changed to report the MODALIAS of the form
   of:N*T*C as it's made by other subsystems, then module auto-load
   will break for these drivers.

c) Those that don't have an of_table but should since are OF drivers
   with DT bindings doc for them. Since the SPI core does not report
   a OF modalias and since spi_match_device() fallbacks to match the
   device part of the compatible string with the SPI device ID table,
   many OF drivers don't have an of_table to match. After all having
   a SPI device ID table is mandatory so it works without a of_table.

So, in order to not make mandatory to have a SPI device ID table, all
these three kind of issues have to be addressed. This series does that.

I split the changes so the patches in this series are independent and
can be picked individually by subsystem maintainers.

Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches

Patch #18 changes the logic of spi_uevent() to report an OF modalias if
the device was registered using OF. But this patch is included in the
series only as an RFC for illustration purposes since changing that
without first applying all the other patches in this series, will break
module autoloading for the drivers of devices registered using OF but
that lacks an of_match_table. I'll repost patch #18 once all the patches
in this series have landed.

[0]: https://lkml.org/lkml/2015/7/30/519

Best regards,
Javier


Javier Martinez Canillas (18):
  iio: Export SPI module alias information in missing drivers
  staging: iio: hmc5843: Export missing SPI module alias information
  mtd: dataflash: Export OF module alias information
  OMAPDSS: panel-sony-acx565akm: Export OF module alias information
  mmc: mmc_spi: Export OF module alias information
  staging: mt29f_spinand: Export OF module alias information
  net: ks8851: Export OF module alias information
  [media] s5c73m3: Export OF module alias information
  mfd: cros_ec: spi: Add OF match table
  iio: dac: ad7303: Add OF match table
  iio: adc: max1027: Set struct spi_driver .of_match_table
  mfd: stmpe: Add OF match table
  iio: adc: mcp320x: Set struct spi_driver .of_match_table
  iio: as3935: Add OF match table
  iio: adc128s052: Add OF match table
  iio: frequency: adf4350: Add OF match table
  NFC: trf7970a: Add OF match table
  spi: (RFC, don't apply) report OF style modalias when probing using DT

 drivers/iio/adc/max1027.c                                   |  1 +
 drivers/iio/adc/mcp320x.c                                   |  1 +
 drivers/iio/adc/ti-adc128s052.c                             |  8 ++++++++
 drivers/iio/amplifiers/ad8366.c                             |  1 +
 drivers/iio/dac/ad7303.c                                    |  7 +++++++
 drivers/iio/frequency/adf4350.c                             |  9 +++++++++
 drivers/iio/proximity/as3935.c                              |  7 +++++++
 drivers/media/i2c/s5c73m3/s5c73m3-spi.c                     |  1 +
 drivers/mfd/cros_ec_spi.c                                   |  7 +++++++
 drivers/mfd/stmpe-spi.c                                     | 13 +++++++++++++
 drivers/mmc/host/mmc_spi.c                                  |  1 +
 drivers/mtd/devices/mtd_dataflash.c                         |  1 +
 drivers/net/ethernet/micrel/ks8851.c                        |  1 +
 drivers/nfc/trf7970a.c                                      |  7 +++++++
 drivers/spi/spi.c                                           |  8 ++++++++
 drivers/staging/iio/magnetometer/hmc5843_spi.c              |  1 +
 drivers/staging/mt29f_spinand/mt29f_spinand.c               |  1 +
 .../video/fbdev/omap2/displays-new/panel-sony-acx565akm.c   |  1 +
 18 files changed, 76 insertions(+)

-- 
2.4.3

[PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Javier Martinez Canillas]

From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

An SPI driver that supports both OF and legacy platforms, will have
both an OF and SPI ID table. This means that when built as a module,
the aliases will be filled from both tables, e.g:

$ modinfo cros_ec_spi | grep alias
alias:          spi:cros-ec-spi
alias:          of:N*T*Cgoogle,cros-ec-spi*

But currently the SPI core always report a module alias of the form
spi:<modalias>, e.g:

$ cat /sys/devices/12d40000.spi/spi_master/spi2/spi2.0/modalias
spi:cros-ec-spi

And also this spi:<modalias> is always reported to user-space as
MODALIAS regardless of the mechanism that was used to register the
device (i.e: OF or board code).

This means that OF-only drivers needs to have both OF and SPI 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 SPI device name for example.

This patch changes the SPI core to report an OF related MODALIAS uevent
(of:N*T*C) env var instead so the module can be auto-loaded and also
the correct modalias is reported on sysfs, e.g:

$ cat /sys/devices/12d40000.spi/spi_master/spi2/spi2.0/modalias
of:Ncros-ecT<NULL>Cgoogle,cros-ec-spi

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

 drivers/spi/spi.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 08861a0233ca..beb7fb2b15c5 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -59,6 +59,10 @@ modalias_show(struct device *dev, struct device_attribute *a, char *buf)
 	const struct spi_device	*spi = to_spi_device(dev);
 	int len;
 
+	len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1);
+	if (len != -ENODEV)
+		return len;
+
 	len = acpi_device_modalias(dev, buf, PAGE_SIZE - 1);
 	if (len != -ENODEV)
 		return len;
@@ -250,6 +254,10 @@ static int spi_uevent(struct device *dev, struct kobj_uevent_env *env)
 	const struct spi_device		*spi = to_spi_device(dev);
 	int rc;
 
+	rc = of_device_uevent_modalias(dev, env);
+	if (rc != -ENODEV)
+		return rc;
+
 	rc = acpi_device_uevent_modalias(dev, env);
 	if (rc != -ENODEV)
 		return rc;
-- 
2.4.3

Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Thu, Aug 20, 2015 at 09:07:31AM +0200, Javier Martinez Canillas wrote:
> From: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> 
> An SPI driver that supports both OF and legacy platforms, will have
> both an OF and SPI ID table. This means that when built as a module,
> the aliases will be filled from both tables, e.g:

This is tagged as something that can't be applied but you've not
explained why it can't be applied or what comments might be useful :(

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Brian Norris]

On Thu, Aug 20, 2015 at 11:36:34AM -0700, Mark Brown wrote:
> On Thu, Aug 20, 2015 at 09:07:31AM +0200, Javier Martinez Canillas wrote:
> > From: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> > 
> > An SPI driver that supports both OF and legacy platforms, will have
> > both an OF and SPI ID table. This means that when built as a module,
> > the aliases will be filled from both tables, e.g:
> 
> This is tagged as something that can't be applied but you've not
> explained why it can't be applied or what comments might be useful :(

I believe that's mostly addressed in the cover letter [1].

  Patch #18 changes the logic of spi_uevent() to report an OF modalias
  if the device was registered using OF. But this patch is included in
  the series only as an RFC for illustration purposes since changing
  that without first applying all the other patches in this series, will
  break module autoloading for the drivers of devices registered using
  OF but that lacks an of_match_table. I'll repost patch #18 once all
  the patches in this series have landed.

IOW, it's labeled as such mostly for safety, since it has quite a few
distributed dependencies.

Brian

[1] https://lkml.org/lkml/2015/8/20/109
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/18] Export SPI and OF module aliases in missing drivers

[Brian Norris]

On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote:
> Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches

^^^ I'm dying to know how this sentence ends :)

> Patch #18 changes the logic of spi_uevent() to report an OF modalias if
> the device was registered using OF. But this patch is included in the
> series only as an RFC for illustration purposes since changing that
> without first applying all the other patches in this series, will break
> module autoloading for the drivers of devices registered using OF but
> that lacks an of_match_table. I'll repost patch #18 once all the patches
> in this series have landed.

On a more productive note, the patches I've looked at look good to me.
The missing aliases are a problem enough that should be fixed (i.e.,
part (b)). I'll leave the SPI framework changes to others to comment on.

Brian

Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Javier Martinez Canillas]

On 08/20/2015 11:08 PM, Brian Norris wrote:
> On Thu, Aug 20, 2015 at 11:36:34AM -0700, Mark Brown wrote:
>> On Thu, Aug 20, 2015 at 09:07:31AM +0200, Javier Martinez Canillas wrote:
>>> From: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
>>>
>>> An SPI driver that supports both OF and legacy platforms, will have
>>> both an OF and SPI ID table. This means that when built as a module,
>>> the aliases will be filled from both tables, e.g:
>>
>> This is tagged as something that can't be applied but you've not
>> explained why it can't be applied or what comments might be useful :(
>

As Brian pointed out it was in the cover letter so I thought it would
just be duplicated information. But you are right, I should had added
a brief note as well just to make the patch self contained.
 
> I believe that's mostly addressed in the cover letter [1].
> 
>   Patch #18 changes the logic of spi_uevent() to report an OF modalias
>   if the device was registered using OF. But this patch is included in
>   the series only as an RFC for illustration purposes since changing
>   that without first applying all the other patches in this series, will
>   break module autoloading for the drivers of devices registered using
>   OF but that lacks an of_match_table. I'll repost patch #18 once all
>   the patches in this series have landed.
> 
> IOW, it's labeled as such mostly for safety, since it has quite a few
> distributed dependencies.
>

That's correct. If is merged before the other patches, module autoloading
will break for the drivers that are relying on the current behavior.

I just added for illustration purposes to show what was the plan.

> Brian
> 
> [1] https://lkml.org/lkml/2015/8/20/109
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/18] Export SPI and OF module aliases in missing drivers

[Javier Martinez Canillas]

Hello Brian,

On 08/20/2015 11:11 PM, Brian Norris wrote:
> On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote:
>> Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches
> 
> ^^^ I'm dying to know how this sentence ends :)
>

Sigh, I did some last minute restructuring of the cover letter and
seems I missed a sentence. I meant to said:

"and patches #9 to #17 solves c)."
 
>> Patch #18 changes the logic of spi_uevent() to report an OF modalias if
>> the device was registered using OF. But this patch is included in the
>> series only as an RFC for illustration purposes since changing that
>> without first applying all the other patches in this series, will break
>> module autoloading for the drivers of devices registered using OF but
>> that lacks an of_match_table. I'll repost patch #18 once all the patches
>> in this series have landed.
> 
> On a more productive note, the patches I've looked at look good to me.
> The missing aliases are a problem enough that should be fixed (i.e.,
> part (b)). I'll leave the SPI framework changes to others to comment on.
>

Great, thanks a lot for your feedback.
 
> Brian
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Thu, Aug 20, 2015 at 11:45:09PM +0200, Javier Martinez Canillas wrote:
> On 08/20/2015 11:08 PM, Brian Norris wrote:

> >> This is tagged as something that can't be applied but you've not
> >> explained why it can't be applied or what comments might be useful :(

> As Brian pointed out it was in the cover letter so I thought it would
> just be duplicated information. But you are right, I should had added
> a brief note as well just to make the patch self contained.

Right, a big part of what I was looking for was something about why this
is an incompatible change in the changelog so that once it gets applied
someone with out of tree code which gets broken can see what happens.
Plus...

> > I believe that's mostly addressed in the cover letter [1].

> >   Patch #18 changes the logic of spi_uevent() to report an OF modalias
> >   if the device was registered using OF. But this patch is included in
> >   the series only as an RFC for illustration purposes since changing
> >   that without first applying all the other patches in this series, will
> >   break module autoloading for the drivers of devices registered using
> >   OF but that lacks an of_match_table. I'll repost patch #18 once all
> >   the patches in this series have landed.

> > IOW, it's labeled as such mostly for safety, since it has quite a few
> > distributed dependencies.

Are there really only 17 drivers that are missing an explict of_table?
That seems like a low number.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Javier Martinez Canillas]

Hello Mark,

On 08/21/2015 01:25 AM, Mark Brown wrote:
> On Thu, Aug 20, 2015 at 11:45:09PM +0200, Javier Martinez Canillas wrote:
>> On 08/20/2015 11:08 PM, Brian Norris wrote:
> 
>>>> This is tagged as something that can't be applied but you've not
>>>> explained why it can't be applied or what comments might be useful :(
> 
>> As Brian pointed out it was in the cover letter so I thought it would
>> just be duplicated information. But you are right, I should had added
>> a brief note as well just to make the patch self contained.
> 
> Right, a big part of what I was looking for was something about why this
> is an incompatible change in the changelog so that once it gets applied
> someone with out of tree code which gets broken can see what happens.

Yes, you are absolutely right. When I finally post this as a proper
patch I'll make sure to have a big NOTE so people can track module
autoload issues for OF drivers down to this commit.

> Plus...
> 
>>> I believe that's mostly addressed in the cover letter [1].
> 
>>>   Patch #18 changes the logic of spi_uevent() to report an OF modalias
>>>   if the device was registered using OF. But this patch is included in
>>>   the series only as an RFC for illustration purposes since changing
>>>   that without first applying all the other patches in this series, will
>>>   break module autoloading for the drivers of devices registered using
>>>   OF but that lacks an of_match_table. I'll repost patch #18 once all
>>>   the patches in this series have landed.
> 
>>> IOW, it's labeled as such mostly for safety, since it has quite a few
>>> distributed dependencies.
> 
> Are there really only 17 drivers that are missing an explict of_table?
> That seems like a low number.
>

In fact the 17 patches are the combination of the SPI drivers that:

a) Have a .id_table but not a MODULE_DEVICE_TABLE(spi,...)
b) Have a .of_match_table but no a MODULE_DEVICE_TABLE(of,...)
c) Don't have a .of_match_table but have a DT binding document

Maybe there are more SPI drivers out there that only have a .id_table
and don't have a .of_match_table nor a DT binding doc. But in that case
there isn't too much I can do since I've no information that these are
drivers are actually used in systems booted with OF.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

On Fri, Aug 21, 2015 at 01:47:00AM +0200, Javier Martinez Canillas wrote:
> On 08/21/2015 01:25 AM, Mark Brown wrote:
> > On Thu, Aug 20, 2015 at 11:45:09PM +0200, Javier Martinez Canillas wrote:

> >>> IOW, it's labeled as such mostly for safety, since it has quite a few
> >>> distributed dependencies.

> > Are there really only 17 drivers that are missing an explict of_table?
> > That seems like a low number.

> In fact the 17 patches are the combination of the SPI drivers that:

> a) Have a .id_table but not a MODULE_DEVICE_TABLE(spi,...)
> b) Have a .of_match_table but no a MODULE_DEVICE_TABLE(of,...)
> c) Don't have a .of_match_table but have a DT binding document

> Maybe there are more SPI drivers out there that only have a .id_table
> and don't have a .of_match_table nor a DT binding doc. But in that case
> there isn't too much I can do since I've no information that these are
> drivers are actually used in systems booted with OF.

We could at the very least scan through the in tree DTs.  There does
seem to be a substantial overlap between systems that often don't use
modular kernels but could and systems where people are using the I2C
and SPI ID mapping shims.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Javier Martinez Canillas]

Hello Mark,

On 08/21/2015 07:29 PM, Mark Brown wrote:
> On Fri, Aug 21, 2015 at 01:47:00AM +0200, Javier Martinez Canillas wrote:
>> On 08/21/2015 01:25 AM, Mark Brown wrote:
>>> On Thu, Aug 20, 2015 at 11:45:09PM +0200, Javier Martinez Canillas wrote:
> 
>>>>> IOW, it's labeled as such mostly for safety, since it has quite a few
>>>>> distributed dependencies.
> 
>>> Are there really only 17 drivers that are missing an explict of_table?
>>> That seems like a low number.
> 
>> In fact the 17 patches are the combination of the SPI drivers that:
> 
>> a) Have a .id_table but not a MODULE_DEVICE_TABLE(spi,...)
>> b) Have a .of_match_table but no a MODULE_DEVICE_TABLE(of,...)
>> c) Don't have a .of_match_table but have a DT binding document
> 
>> Maybe there are more SPI drivers out there that only have a .id_table
>> and don't have a .of_match_table nor a DT binding doc. But in that case
>> there isn't too much I can do since I've no information that these are
>> drivers are actually used in systems booted with OF.
> 
> We could at the very least scan through the in tree DTs.  There does
> seem to be a substantial overlap between systems that often don't use
> modular kernels but could and systems where people are using the I2C
> and SPI ID mapping shims.
> 

My script does this but didn't find any matches.

Basically what I do is for drivers with no OF table, to take the name field
from the spi_device_id in the SPI id table and see if one of these are used
as a compatible string either in a DTS or mentioned in a DT binding.

I found some matches in DT bindings which are the type c) issue but none
used in an in tree DTS.

But that doesn't mean that there could be drivers with no OF table, no DT
binding and with out-of-tree DTS that are using compatible = "bar" instead
compatible = "foo,bar" and relying on SPI matching using the SPI device id
table as a fallback. But I guess these should be fixed for module autoload.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html