From: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org,
sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org
Subject: Re: SPI and module auto-loading
Date: Fri, 12 Sep 2014 11:50:23 +0200 [thread overview]
Message-ID: <5412C1DF.3040707@collabora.co.uk> (raw)
In-Reply-To: <20140911193325.GT4015-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On 09/11/2014 09:33 PM, Mark Brown wrote:
> On Thu, Sep 11, 2014 at 03:03:50PM +0200, Javier Martinez Canillas wrote:
>
>> This can be easily worked around (and probably why it never was an issue) if
>> the OF and SPI tables are kept in sync but I don't know if that is a hard
>> requirement for all use-cases (e.g: a SPI driver that is DT only?).
>
> I'm not sure I see that as an interesting use case, it seems better to
> have drivers usable without DT and it's trivial to do so.
>
Yes, it's trivial but seems like an unnecessary duplication for me. AFAICT the
OF tables are only used to match the devices in spi_match_device() but if both
the OF and SPI tables must be kept in sync to properly report the module
aliases to user-space then I wonder if the OF tables shouldn't just be removed
from the SPI drivers since spi_match_device() will succeed anyways when
calling spi_match_id().
>> I'm sending an RFC patch [1] to know what you think about it.
>> [1]
>> From a7cd35209a597a578df6c801e5ff7b63b584bf3e Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
>> Date: Thu, 11 Sep 2014 14:31:04 +0200
>> Subject: [PATCH RFC] spi: core: report OF style modalias when probing using DT
>
> We already have a perfectly good way of sending patches.
>
Of course I know how to post patches properly but proposing a patch was not my
intention here since as I said this could break module auto-loading for many
drivers that rely on the current behavior. What I wanted was to explain with
code how the SPI core could report uevents in order to be consistent with what
other subsystems do (e.g: platform drivers):
http://lxr.free-electrons.com/source/drivers/base/platform.c#L717
I should probably had used sharing instead of sending but as a non-native
english speaker sometimes I don't always choose the best wording.
Anyway, I was just raising the issue because if a driver only defines an OF
table and not a SPI table, the driver will be probed correctly but module
auto-loading will not work. So even when it looks like having a SPI id table
is not a requirement for OF, it really is and I think that is not documented.
--
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
WARNING: multiple messages have this Message-ID (diff)
From: javier.martinez@collabora.co.uk (Javier Martinez Canillas)
To: linux-arm-kernel@lists.infradead.org
Subject: SPI and module auto-loading
Date: Fri, 12 Sep 2014 11:50:23 +0200 [thread overview]
Message-ID: <5412C1DF.3040707@collabora.co.uk> (raw)
In-Reply-To: <20140911193325.GT4015@sirena.org.uk>
On 09/11/2014 09:33 PM, Mark Brown wrote:
> On Thu, Sep 11, 2014 at 03:03:50PM +0200, Javier Martinez Canillas wrote:
>
>> This can be easily worked around (and probably why it never was an issue) if
>> the OF and SPI tables are kept in sync but I don't know if that is a hard
>> requirement for all use-cases (e.g: a SPI driver that is DT only?).
>
> I'm not sure I see that as an interesting use case, it seems better to
> have drivers usable without DT and it's trivial to do so.
>
Yes, it's trivial but seems like an unnecessary duplication for me. AFAICT the
OF tables are only used to match the devices in spi_match_device() but if both
the OF and SPI tables must be kept in sync to properly report the module
aliases to user-space then I wonder if the OF tables shouldn't just be removed
from the SPI drivers since spi_match_device() will succeed anyways when
calling spi_match_id().
>> I'm sending an RFC patch [1] to know what you think about it.
>> [1]
>> From a7cd35209a597a578df6c801e5ff7b63b584bf3e Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Date: Thu, 11 Sep 2014 14:31:04 +0200
>> Subject: [PATCH RFC] spi: core: report OF style modalias when probing using DT
>
> We already have a perfectly good way of sending patches.
>
Of course I know how to post patches properly but proposing a patch was not my
intention here since as I said this could break module auto-loading for many
drivers that rely on the current behavior. What I wanted was to explain with
code how the SPI core could report uevents in order to be consistent with what
other subsystems do (e.g: platform drivers):
http://lxr.free-electrons.com/source/drivers/base/platform.c#L717
I should probably had used sharing instead of sending but as a non-native
english speaker sometimes I don't always choose the best wording.
Anyway, I was just raising the issue because if a driver only defines an OF
table and not a SPI table, the driver will be probed correctly but module
auto-loading will not work. So even when it looks like having a SPI id table
is not a requirement for OF, it really is and I think that is not documented.
WARNING: multiple messages have this Message-ID (diff)
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
wsa@the-dreams.de, sjoerd.simons@collabora.co.uk
Subject: Re: SPI and module auto-loading
Date: Fri, 12 Sep 2014 11:50:23 +0200 [thread overview]
Message-ID: <5412C1DF.3040707@collabora.co.uk> (raw)
In-Reply-To: <20140911193325.GT4015@sirena.org.uk>
On 09/11/2014 09:33 PM, Mark Brown wrote:
> On Thu, Sep 11, 2014 at 03:03:50PM +0200, Javier Martinez Canillas wrote:
>
>> This can be easily worked around (and probably why it never was an issue) if
>> the OF and SPI tables are kept in sync but I don't know if that is a hard
>> requirement for all use-cases (e.g: a SPI driver that is DT only?).
>
> I'm not sure I see that as an interesting use case, it seems better to
> have drivers usable without DT and it's trivial to do so.
>
Yes, it's trivial but seems like an unnecessary duplication for me. AFAICT the
OF tables are only used to match the devices in spi_match_device() but if both
the OF and SPI tables must be kept in sync to properly report the module
aliases to user-space then I wonder if the OF tables shouldn't just be removed
from the SPI drivers since spi_match_device() will succeed anyways when
calling spi_match_id().
>> I'm sending an RFC patch [1] to know what you think about it.
>> [1]
>> From a7cd35209a597a578df6c801e5ff7b63b584bf3e Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Date: Thu, 11 Sep 2014 14:31:04 +0200
>> Subject: [PATCH RFC] spi: core: report OF style modalias when probing using DT
>
> We already have a perfectly good way of sending patches.
>
Of course I know how to post patches properly but proposing a patch was not my
intention here since as I said this could break module auto-loading for many
drivers that rely on the current behavior. What I wanted was to explain with
code how the SPI core could report uevents in order to be consistent with what
other subsystems do (e.g: platform drivers):
http://lxr.free-electrons.com/source/drivers/base/platform.c#L717
I should probably had used sharing instead of sending but as a non-native
english speaker sometimes I don't always choose the best wording.
Anyway, I was just raising the issue because if a driver only defines an OF
table and not a SPI table, the driver will be probed correctly but module
auto-loading will not work. So even when it looks like having a SPI id table
is not a requirement for OF, it really is and I think that is not documented.
next prev parent reply other threads:[~2014-09-12 9:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 13:03 SPI and module auto-loading Javier Martinez Canillas
2014-09-11 13:03 ` Javier Martinez Canillas
[not found] ` <54119DB6.8020807-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2014-09-11 19:33 ` Mark Brown
2014-09-11 19:33 ` Mark Brown
2014-09-11 19:33 ` Mark Brown
[not found] ` <20140911193325.GT4015-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-09-12 9:50 ` Javier Martinez Canillas [this message]
2014-09-12 9:50 ` Javier Martinez Canillas
2014-09-12 9:50 ` Javier Martinez Canillas
[not found] ` <5412C1DF.3040707-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2014-09-12 10:14 ` Mark Brown
2014-09-12 10:14 ` Mark Brown
2014-09-12 10:14 ` Mark Brown
[not found] ` <20140912101442.GR7960-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-09-15 8:10 ` Sjoerd Simons
2014-09-15 8:10 ` Sjoerd Simons
2014-09-15 8:10 ` Sjoerd Simons
2014-09-15 22:58 ` Mark Brown
2014-09-15 22:58 ` Mark Brown
[not found] ` <20140915225820.GI7960-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-09-19 11:08 ` Sjoerd Simons
2014-09-19 11:08 ` Sjoerd Simons
2014-09-19 11:08 ` Sjoerd Simons
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=5412C1DF.3040707@collabora.co.uk \
--to=javier.martinez-zgy8ohtn/8ppycu2f3hruq@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org \
--cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.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.