From: Brian Norris <computersforpeace@gmail.com>
To: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Mark Brown <broonie@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
linux-mtd@lists.infradead.org,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org
Subject: Re: spi: OF module autoloading is still broken
Date: Mon, 16 Nov 2015 13:51:44 -0800 [thread overview]
Message-ID: <20151116215144.GQ8456@google.com> (raw)
In-Reply-To: <564A4B66.6090107@osg.samsung.com>
Hi Javier,
On Mon, Nov 16, 2015 at 06:32:22PM -0300, Javier Martinez Canillas wrote:
> On 11/16/2015 05:47 PM, Brian Norris wrote:
> > On Mon, Nov 16, 2015 at 05:00:43PM -0300, Javier Martinez Canillas wrote:
> >> Now that I think about it, there is another issue and is that today spi:foo
> >> defines a namespace while changing to of: will make the namespace flat so
> >> a platform driver that has the same vendor and model will have the same
> >> modalias.
> >>
> >> IOW, for board files will be platform:bar and i2c:bar while for OF will be
> >> of:NfooT<NULL>Cfoo,bar in both cases. I wonder if we should reuse the type
> >> for that and store the subsystem prefix there. What do you think?
> >
> > I'm not sure I understand all the issues here to be able to comment
> > properly. But I bet someone else might.
> >
> > (For me, it might help if you had a more concrete example to speak of.)
> >
>
> From a quick look I couldn't find a real example (that doesn't mean there
> isn't one) but I'll make one just to explain the problem.
>
> Let's suppose you have 3 different IP's blocks (i.e: pmics) from the same
> vendor. The IP's are quite similar but only differ in that use a different
> bus to communicate with the SoC.
Ah, I thought that's what you might have meant, but then I reread enough
times that I confused myself. I think my first understanding was correct
:)
> So you could have a core driver and transport drivers for SPI and I2C.
>
> So currently you could use the not too creative compatible strings compatible
> string "acme,my-pmic" in all the drivers and is not a problem because the SPI
> and I2C subsystem will always report the MODALIAS uevent as:
>
> MODALIAS=i2c:my-pmic and MODALIAS=spi:my-pmic
>
> so as far as there is a "my-pmic" entry in the SPI and I2C id tables, module
> autoload will work and the match will also work since that happens per bus_type.
>
> But if SPI and I2C are migrated to OF modalias reporting, then both I2C and SPI
> will report (assuming the device node is called pmic in both cases):
>
> MODALIAS=of:NpmicT<NULL>Cacme,my-pmic
>
> That's what I meant when said that the modalias namespace is flat in the case of
> OF but is separated in the case of board files and the current implementation.
Thanks for the additional explanation.
> What currently the drivers are doing is to name the model my-pmic-{i2c,spi,etc}
> but I think that the subsystem information should be explicitly present in the
> OF modalias information as it is for legacy device registration.
Lest someone else wonder whether this is theoretical or not, I'll save
them the work in pointing at an example: "st,st33zp24". See:
Documentation/devicetree/bindings/security/tpm/st33zp24-*.txt
and the code is in drivers/char/tpm/st33zp24/, sharing the same core
library, suggesting that the devices really are the same except simply
the bus.
In my limited opinion, then, it seems like a good idea to still try to
separate the bus namespaces when reporting module-loading information.
Brian
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Javier Martinez Canillas
<javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Heiner Kallweit
<hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Dmitry Torokhov
<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: spi: OF module autoloading is still broken
Date: Mon, 16 Nov 2015 13:51:44 -0800 [thread overview]
Message-ID: <20151116215144.GQ8456@google.com> (raw)
In-Reply-To: <564A4B66.6090107-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Hi Javier,
On Mon, Nov 16, 2015 at 06:32:22PM -0300, Javier Martinez Canillas wrote:
> On 11/16/2015 05:47 PM, Brian Norris wrote:
> > On Mon, Nov 16, 2015 at 05:00:43PM -0300, Javier Martinez Canillas wrote:
> >> Now that I think about it, there is another issue and is that today spi:foo
> >> defines a namespace while changing to of: will make the namespace flat so
> >> a platform driver that has the same vendor and model will have the same
> >> modalias.
> >>
> >> IOW, for board files will be platform:bar and i2c:bar while for OF will be
> >> of:NfooT<NULL>Cfoo,bar in both cases. I wonder if we should reuse the type
> >> for that and store the subsystem prefix there. What do you think?
> >
> > I'm not sure I understand all the issues here to be able to comment
> > properly. But I bet someone else might.
> >
> > (For me, it might help if you had a more concrete example to speak of.)
> >
>
> From a quick look I couldn't find a real example (that doesn't mean there
> isn't one) but I'll make one just to explain the problem.
>
> Let's suppose you have 3 different IP's blocks (i.e: pmics) from the same
> vendor. The IP's are quite similar but only differ in that use a different
> bus to communicate with the SoC.
Ah, I thought that's what you might have meant, but then I reread enough
times that I confused myself. I think my first understanding was correct
:)
> So you could have a core driver and transport drivers for SPI and I2C.
>
> So currently you could use the not too creative compatible strings compatible
> string "acme,my-pmic" in all the drivers and is not a problem because the SPI
> and I2C subsystem will always report the MODALIAS uevent as:
>
> MODALIAS=i2c:my-pmic and MODALIAS=spi:my-pmic
>
> so as far as there is a "my-pmic" entry in the SPI and I2C id tables, module
> autoload will work and the match will also work since that happens per bus_type.
>
> But if SPI and I2C are migrated to OF modalias reporting, then both I2C and SPI
> will report (assuming the device node is called pmic in both cases):
>
> MODALIAS=of:NpmicT<NULL>Cacme,my-pmic
>
> That's what I meant when said that the modalias namespace is flat in the case of
> OF but is separated in the case of board files and the current implementation.
Thanks for the additional explanation.
> What currently the drivers are doing is to name the model my-pmic-{i2c,spi,etc}
> but I think that the subsystem information should be explicitly present in the
> OF modalias information as it is for legacy device registration.
Lest someone else wonder whether this is theoretical or not, I'll save
them the work in pointing at an example: "st,st33zp24". See:
Documentation/devicetree/bindings/security/tpm/st33zp24-*.txt
and the code is in drivers/char/tpm/st33zp24/, sharing the same core
library, suggesting that the devices really are the same except simply
the bus.
In my limited opinion, then, it seems like a good idea to still try to
separate the bus namespaces when reporting module-loading information.
Brian
--
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
next prev parent reply other threads:[~2015-11-16 21:52 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-03 21:54 m25p80: Commit "allow arbitrary OF matching for "jedec,spi-nor"" breaks module autoloading Heiner Kallweit
2015-11-12 18:59 ` m25p80: Commit "allow arbitrary OF matching for "jedec, spi-nor"" " Brian Norris
2015-11-12 18:59 ` m25p80: Commit "allow arbitrary OF matching for "jedec,spi-nor"" " Brian Norris
2015-11-12 18:59 ` Brian Norris
2015-11-13 19:40 ` spi: OF module autoloading is still broken (was: Re: m25p80: Commit "allow arbitrary OF matching for "jedec,spi-nor"" breaks module autoloading) Brian Norris
2015-11-13 19:40 ` Brian Norris
2015-11-13 22:12 ` Mark Brown
2015-11-13 22:12 ` Mark Brown
2015-11-13 22:51 ` Brian Norris
2015-11-13 23:14 ` Mark Brown
2015-11-13 23:14 ` Mark Brown
2015-11-13 23:48 ` Brian Norris
2015-11-13 23:48 ` Brian Norris
2015-11-16 13:53 ` Mark Brown
2015-11-16 13:53 ` Mark Brown
2015-11-16 17:26 ` spi: OF module autoloading is still broken Javier Martinez Canillas
2015-11-16 17:26 ` Javier Martinez Canillas
2015-11-16 17:51 ` Mark Brown
2015-11-16 17:51 ` Mark Brown
2015-11-16 18:00 ` Javier Martinez Canillas
2015-11-16 18:00 ` Javier Martinez Canillas
2015-11-16 17:19 ` Javier Martinez Canillas
2015-11-16 17:19 ` Javier Martinez Canillas
2015-11-16 17:49 ` Mark Brown
2015-11-16 17:49 ` Mark Brown
2015-11-16 17:57 ` Javier Martinez Canillas
2015-11-16 17:57 ` Javier Martinez Canillas
2015-11-16 19:24 ` Brian Norris
2015-11-16 19:24 ` Brian Norris
2015-11-16 20:00 ` Javier Martinez Canillas
2015-11-16 20:00 ` Javier Martinez Canillas
2015-11-16 20:47 ` Brian Norris
2015-11-16 20:47 ` Brian Norris
2015-11-16 21:32 ` Javier Martinez Canillas
2015-11-16 21:51 ` Brian Norris [this message]
2015-11-16 21:51 ` Brian Norris
2015-11-17 13:14 ` Javier Martinez Canillas
2015-11-17 13:14 ` Javier Martinez Canillas
2015-11-17 13:19 ` Mark Brown
2015-11-17 13:19 ` Mark Brown
2015-11-17 13:36 ` Javier Martinez Canillas
2015-11-18 20:07 ` Javier Martinez Canillas
2015-11-18 20:07 ` Javier Martinez Canillas
2015-11-19 12:47 ` Javier Martinez Canillas
2015-11-17 13:34 ` Mark Brown
2015-11-17 13:34 ` Mark Brown
2015-11-17 13:38 ` Javier Martinez Canillas
2015-11-17 13:38 ` 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=20151116215144.GQ8456@google.com \
--to=computersforpeace@gmail.com \
--cc=broonie@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=javier@osg.samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.