From: Lars-Peter Clausen <lars@metafoo.de>
To: mfuzzey@parkeon.com
Cc: Grant Likely <grant.likely@secretlab.ca>,
spi-devel-general@lists.sourceforge.net,
Maxime Ripard <maxime.ripard@free-electrons.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] SPI: spidev: Add DT compatible string for spidev driver.
Date: Fri, 12 Apr 2013 19:28:39 +0200 [thread overview]
Message-ID: <51684447.4040600@metafoo.de> (raw)
In-Reply-To: <51681743.4020001@parkeon.com>
On 04/12/2013 04:16 PM, Martin Fuzzey wrote:
> Hi Maxime,
>
> On 12/04/13 15:30, Maxime Ripard wrote:
>> I submitted a similar patch quite some time ago [1], and at the time, this
>> patch was found inadequate, and we decided to add the compatible of the
>> particular device that we drive through spidev.
>
> Thanks for pointing this out.
>
>> The rationale behind that is that the device tree is a hardware
>> description, so it's only interested about which device there is on the
>> SPI bus, and not the driver that will eventually handle it. That allows
>> both to have a meaningful devicetree, but also to easily handle the case
>> where a driver for that particular device is finally implemented, since we
>> won't have to change the device tree in itself to reflect this.
>
> I'm not sure this is really an advantage of using a "real" compatible string.
>
> When a kernel driver is finally implemented it will not have the same
> userspace interface as spidev.
>
> This means that the switch from spidev to the kernel driver will not be
> transparent to userspace.
>
> So, if a "real" compatible string is used, upon upgrading to a new version
> of the kernel that adds support for that device userspace will break.
>
> Using a generic compatible string allows the board maintainer to decide when
> to switch by updating the DT.
>
> Of course, when a custom kernel is being configured and compiled, the
> problem can also be solved by not enabling the new driver but I thought one
> of the goals of DT was to enable using a single distribution style binary
> kernel images on multiple boards.
>
> Note that my patch only changes the driver, not any DTS.
> Indeed I agree that _using_ a generic compatible string in an _in kernel_
> DTS would be a mistake for the reasons you point out.
>
> The use case I'm talking about is where a mainline kernel is used but with a
> custom out of tree DTS - why force people to patch the driver for this use
> case?
>
> Best regards,
>
> Martin
In my opinion it would be good if we had a mechanism to bind to create a
spidev device for an existing spi device from sysfs. You wouldn't need any
special compilable strings in the spidev driver and could use it for any spi
device you'd like to.
- Lars
prev parent reply other threads:[~2013-04-12 17:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-12 12:56 [PATCH] SPI: spidev: Add DT compatible string for spidev driver Martin Fuzzey
2013-04-12 13:30 ` Maxime Ripard
2013-04-12 14:16 ` Martin Fuzzey
2013-04-12 17:28 ` Lars-Peter Clausen [this message]
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=51684447.4040600@metafoo.de \
--to=lars@metafoo.de \
--cc=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maxime.ripard@free-electrons.com \
--cc=mfuzzey@parkeon.com \
--cc=spi-devel-general@lists.sourceforge.net \
/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).