| Message ID | 1440054451-1223-19-git-send-email-javier@osg.samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Aug 20, 2015 at 09:07:31AM +0200, Javier Martinez Canillas wrote: > 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: 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 :(
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@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-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@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,
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.
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,
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.
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,
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;