modalias for OF-declared I2C/SPI devices

modalias for OF-declared I2C/SPI devices

[Lukas Wunner]

Hi Javier,

you proposed an RFC patch a while ago which lets the I2C and SPI core
report an "of:" modalias to user space for devices declared in a
device tree (vs. a legacy machine description), instead of an "i2c:"
or "spi:" modalias:

https://lkml.org/lkml/2014/9/11/458
https://lkml.org/lkml/2015/8/20/98

I justed wanted to ask what the status of the patch is?  Looking at
linux-next I notice that you've been fixing up drivers, machine
descriptions and device trees as recently as July.  Apparently you're
still busy landing all the prep work necessary for the patch, is that
correct?

It seems to be an awful lot of work cleaning up this mess and I assume
there is plenty of out-of-tree stuff that may break once the patch lands,
so I've been wondering if a simpler solution might be to change user
space, given that we already communicate all the OF_COMPATIBLE_* uevent
variables.  So I opened an issue for systemd-udevd but so far Lennart
remains unconvinced:

https://github.com/systemd/systemd/issues/6555

I still think that evaluation of OF_COMPATIBLE_* by user space would be
the best solution since it seems impossible to cram the degrees of
freedom afforded by compatible strings into a single modalias string.

The reason I came across this issue is that module autoloading fails for
drivers/gpio/gpio-74x164.c as it only declares an "of" MODULE_DEVICE_TABLE.
I was going to upstream a GPIO and an IIO driver, both SPI-based, and was
wondering what the current best practice is:  Should I only declare an
"of" MODULE_DEVICE_TABLE or should I also provide an "spi"
MODULE_DEVICE_TABLE?

Thanks!

Lukas
--
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: modalias for OF-declared I2C/SPI devices

[Javier Martinez Canillas]

[adding the I2C and SPI subsystem maintainers]

Hello Lukas,

On 08/11/2017 10:14 AM, Lukas Wunner wrote:
> Hi Javier,
> 
> you proposed an RFC patch a while ago which lets the I2C and SPI core
> report an "of:" modalias to user space for devices declared in a
> device tree (vs. a legacy machine description), instead of an "i2c:"
> or "spi:" modalias:
> 
> https://lkml.org/lkml/2014/9/11/458
> https://lkml.org/lkml/2015/8/20/98
> 
> I justed wanted to ask what the status of the patch is?  Looking at
> linux-next I notice that you've been fixing up drivers, machine
> descriptions and device trees as recently as July.  Apparently you're
> still busy landing all the prep work necessary for the patch, is that
> correct?
>

That's partially correct. I'm still pushing the remaining fixes for I2C but I'm
not doing any changes to SPI drivers anymore. It's just too much work and churn
for maintainers.

> It seems to be an awful lot of work cleaning up this mess and I assume

I would also give up on I2C but I'm just keep doing it since we are so close to
finally fix it (only fixes for a couple of drivers are remaining to be merged).

> there is plenty of out-of-tree stuff that may break once the patch lands,

That's correct, but IMHO that's not a problem for mainline. It's the out-of-tree
drivers that were relying on a broken behavior and so what they are doing wasn't
ever expected to work (the fact that works is just due an implementation detail).

Once the I2C and SPI subsystems are fixed to report the proper OF modalias, then
we should document clearly that this may break out-of-tree drivers for courtesy
but I think that's all that mainline should do IMHO.

> so I've been wondering if a simpler solution might be to change user
> space, given that we already communicate all the OF_COMPATIBLE_* uevent
> variables.  So I opened an issue for systemd-udevd but so far Lennart
> remains unconvinced:
> 
> https://github.com/systemd/systemd/issues/6555
> 
> I still think that evaluation of OF_COMPATIBLE_* by user space would be
> the best solution since it seems impossible to cram the degrees of
> freedom afforded by compatible strings into a single modalias string.
>

I agree with Lennart on this. User-space is doing the correct thing and should
not be changed. I'll comment on the Github issue as well.
 
> The reason I came across this issue is that module autoloading fails for
> drivers/gpio/gpio-74x164.c as it only declares an "of" MODULE_DEVICE_TABLE.
> I was going to upstream a GPIO and an IIO driver, both SPI-based, and was
> wondering what the current best practice is:  Should I only declare an
> "of" MODULE_DEVICE_TABLE or should I also provide an "spi"
> MODULE_DEVICE_TABLE?
>

That's a question for Mark Brown. My opinion (since I'm not a maintainer) is
that you should add a SPI device ID table and export it as spi:<foo> aliases
until this is properly fixed.

The correct way to fix this is to move this into the device model instead of
all subsystem types duplicating the same uevent logic and requiring a table
per each firmware interface. But that's a much bigger task...
 
> Thanks!
> 
> Lukas
> 

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
--
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: modalias for OF-declared I2C/SPI devices

[Mark Brown]

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

On Fri, Aug 11, 2017 at 04:11:51PM +0200, Javier Martinez Canillas wrote:
> On 08/11/2017 10:14 AM, Lukas Wunner wrote:

> > The reason I came across this issue is that module autoloading fails for
> > drivers/gpio/gpio-74x164.c as it only declares an "of" MODULE_DEVICE_TABLE.
> > I was going to upstream a GPIO and an IIO driver, both SPI-based, and was
> > wondering what the current best practice is:  Should I only declare an
> > "of" MODULE_DEVICE_TABLE or should I also provide an "spi"
> > MODULE_DEVICE_TABLE?

> That's a question for Mark Brown. My opinion (since I'm not a maintainer) is
> that you should add a SPI device ID table and export it as spi:<foo> aliases
> until this is properly fixed.

Declare both.  Apart from anything else not all the world is DT.

> The correct way to fix this is to move this into the device model instead of
> all subsystem types duplicating the same uevent logic and requiring a table
> per each firmware interface. But that's a much bigger task...

Yes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]