linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Maxime Ripard" <maxime@cerno.tech>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Linux Fbdev development list" <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH v3 5/7] (WIP) drm/solomon: Add SSD130X OLED displays SPI support
Date: Wed, 9 Feb 2022 17:56:41 +0100	[thread overview]
Message-ID: <b8ec21bc-91d4-0f41-2500-db712819fae3@redhat.com> (raw)
In-Reply-To: <CAMuHMdXsAyp18ivtSe-ZVmu6xbBBnvjMuZ=H1w9Gk=Ys4rkCeg@mail.gmail.com>

Sorry for the long reply but I don't really know how to make it shorter.

On 2/9/22 17:25, Geert Uytterhoeven wrote:
> Hi Javier,

[snip]

>> Did you see my comment about automatic module loading ? I think
>> that would be an issue if we use the same compatible for both
>> I2C and SPI drivers.
> 
> We have several drivers that have a core and separate i2c and spi
> wrappers, see e.g.
> 
> $ git grep -w ltc2947_of_match
> drivers/hwmon/ltc2947-core.c:const struct of_device_id ltc2947_of_match[] = {
> drivers/hwmon/ltc2947-core.c:EXPORT_SYMBOL_GPL(ltc2947_of_match);
> drivers/hwmon/ltc2947-core.c:MODULE_DEVICE_TABLE(of, ltc2947_of_match);
> drivers/hwmon/ltc2947-i2c.c:            .of_match_table = ltc2947_of_match,
> drivers/hwmon/ltc2947-spi.c:            .of_match_table = ltc2947_of_match,
> drivers/hwmon/ltc2947.h:extern const struct of_device_id ltc2947_of_match[];
> 
> Are they all broken?
>

It doesn't have an easy answer. It depends on what device ID tables have to
match, what modalias are present in the kernel modules and for what buses
are since not all subsystem reports the modalias uevent in the same manner.

Let's take this particular driver for example, the module aliases are the
following for each kernel module:

$ modinfo drivers/hwmon/ltc2947-core.ko | grep alias
alias:          of:N*T*Cadi,ltc2947C*
alias:          of:N*T*Cadi,ltc2947

$ modinfo drivers/hwmon/ltc2947-i2c.ko | grep alias
alias:          i2c:ltc2947

$ modinfo drivers/hwmon/ltc2947-spi.ko | grep alias
alias:          spi:ltc2947

The DT node will just contain a node with compatible = "adi,ltc2947", and
depending if the device is on a I2C or SPI bus, the OF subsystem will do
a device registration with the proper bus_type.

If is SPI, the subsystem always report a modalias uevent of the type
"spi:ltc2947", even if the device was registered by OF. So for SPI the
proper module will be loaded since it contains an alias "spi:ltc2947".

But I2C does report a proper OF modalias, so it will report instead
"of:N*T*Cadi,ltc2947" which will match the core module but not the I2C.

The I2C ltc2947-i2c.ko module is missing a "of:N*T*Cadi,ltc2947" alias
and the module loading likely isn't working and needs to be done manually.

Conversely, if ltc2947-spi.ko only add "of:N*T*Cadi,ltc2947", then the
automatic module loading wouldn't work because the modalias uevent will
be "spi:ltc2947" which won't match "of:N*T*Cadi,ltc2947". So everything
is really fragile.

Note also that the "T*" in the alias, that's to denote the device type
according to the ePAPR spec but that's only filled in the DT node has a
device_type DT property, and most DT nodes don't fill this.

So the driver module is greedy and will match any device type. And also
the modalias reported by the kernel won't set this, i.e:

$ cat /sys/bus/i2c/drivers/ssd130x-i2c/1-003c/modalias 
of:NoledT(null)Csolomon,ssd1306fb-i2c

The only way I found to make this robust and always working is with each
driver to define its own tables depending on what is used to match and
report the modalias to user-space. That means having an of_device_id and
spi_device_id (just for modalias reporting and alias table in module) for
SPI and a of_device_id table for I2C and platform devices.

And also having different compatible strings with a "-i2c" and "-spi" as
suffixes to allow kmod / udev to differentiate and match the modules.

Otherwise you will get "of:N(null)T(null)Cadi,ltc2947" in both cases and
user-space won't be able to figure out which module to match AFAICT.

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat


  parent reply	other threads:[~2022-02-09 16:56 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09  9:03 [PATCH v3 0/7] drm: Add driver for Solomon SSD130X OLED displays Javier Martinez Canillas
2022-02-09  9:03 ` [PATCH v3 1/7] drm/format-helper: Add drm_fb_xrgb8888_to_gray8_line() Javier Martinez Canillas
2022-02-09  9:03 ` [PATCH v3 2/7] drm/format-helper: Add drm_fb_{xrgb8888,gray8}_to_mono_reversed() Javier Martinez Canillas
2022-02-09 12:51   ` [PATCH v3 2/7] drm/format-helper: Add drm_fb_{xrgb8888, gray8}_to_mono_reversed() Thomas Zimmermann
2022-02-09 13:26     ` Javier Martinez Canillas
2022-02-09 15:21       ` Thomas Zimmermann
2022-02-09 15:30         ` Javier Martinez Canillas
2022-02-09  9:03 ` [PATCH v3 3/7] drm: Add driver for Solomon SSD130X OLED displays Javier Martinez Canillas
2022-02-09 13:43   ` Mark Brown
2022-02-09 14:17     ` Javier Martinez Canillas
2022-02-09 14:22       ` Mark Brown
2022-02-09 14:50         ` Javier Martinez Canillas
2022-02-09 15:03           ` Mark Brown
2022-02-09 15:17             ` Javier Martinez Canillas
2022-02-09 15:12   ` Andy Shevchenko
2022-02-09 15:54     ` Javier Martinez Canillas
2022-02-09 16:08       ` Andy Shevchenko
2022-02-09 16:26         ` Javier Martinez Canillas
2022-02-09 16:44           ` Andy Shevchenko
2022-02-11  8:54           ` Javier Martinez Canillas
2022-02-09  9:03 ` [PATCH v3 4/7] drm/solomon: Add SSD130X OLED displays I2C support Javier Martinez Canillas
2022-02-09 12:21   ` Geert Uytterhoeven
2022-02-09 12:41     ` Javier Martinez Canillas
2022-02-09 15:15   ` Andy Shevchenko
2022-02-09 16:05     ` Javier Martinez Canillas
2022-02-09  9:12 ` [PATCH v3 5/7] (WIP) drm/solomon: Add SSD130X OLED displays SPI support Javier Martinez Canillas
2022-02-09 12:25   ` Geert Uytterhoeven
2022-02-09 13:04     ` Javier Martinez Canillas
2022-02-09 15:19       ` Andy Shevchenko
2022-02-09 16:10         ` Javier Martinez Canillas
2022-02-09 15:17     ` Andy Shevchenko
2022-02-09 16:07       ` Javier Martinez Canillas
2022-02-09 16:25         ` Geert Uytterhoeven
2022-02-09 16:41           ` Andy Shevchenko
2022-02-09 17:04             ` Javier Martinez Canillas
2022-02-09 16:56           ` Javier Martinez Canillas [this message]
2022-02-09 16:40         ` Andy Shevchenko
2022-02-09 15:16   ` Andy Shevchenko
2022-02-09 16:05     ` Javier Martinez Canillas
2022-02-09  9:13 ` [PATCH v3 6/7] MAINTAINERS: Add entry for Solomon SSD130X OLED displays DRM driver Javier Martinez Canillas
2022-02-09  9:13 ` [PATCH v3 7/7] dt-bindings: display: ssd1307fb: Add myself as binding co-maintainer Javier Martinez Canillas
2022-02-09 12:19 ` [PATCH v3 0/7] drm: Add driver for Solomon SSD130X OLED displays Geert Uytterhoeven
2022-02-09 12:37   ` Javier Martinez Canillas
2022-02-11  8:45     ` Javier Martinez Canillas
2022-02-10 17:06   ` Geert Uytterhoeven
2022-02-10 17:55     ` Javier Martinez Canillas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b8ec21bc-91d4-0f41-2500-db712819fae3@redhat.com \
    --to=javierm@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime@cerno.tech \
    --cc=noralf@tronnes.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).