Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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. signature.asc Description: Digital signature
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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. signature.asc Description: Digital signature
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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. signature.asc Description: Digital signature
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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 >>> >>> 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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 > > > > 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
On Thu, Aug 20, 2015 at 09:07:31AM +0200, Javier Martinez Canillas wrote: > From: Javier Martinez Canillas > > 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 :( signature.asc Description: Digital signature
[PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
From: Javier Martinez Canillas 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:, e.g: $ cat /sys/devices/12d4.spi/spi_master/spi2/spi2.0/modalias spi:cros-ec-spi And also this spi: 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/12d4.spi/spi_master/spi2/spi2.0/modalias of:Ncros-ecTCgoogle,cros-ec-spi Signed-off-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
From: Javier Martinez Canillas javier.marti...@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/12d4.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/12d4.spi/spi_master/spi2/spi2.0/modalias of:Ncros-ecTNULLCgoogle,cros-ec-spi Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Signed-off-by: Javier Martinez Canillas jav...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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. signature.asc Description: Digital signature
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
On Thu, Aug 20, 2015 at 09:07:31AM +0200, Javier Martinez Canillas wrote: From: Javier Martinez Canillas javier.marti...@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: 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 :( signature.asc Description: Digital signature
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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.marti...@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: 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-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT
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.marti...@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: 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-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
