All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Marcel Ziswiler <marcel@ziswiler.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
	thierry.reding@gmail.com, linux@arm.linux.org.uk,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
	stefan@agner.ch
Subject: Re: [PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds
Date: Wed, 4 Jun 2014 12:17:55 +0100	[thread overview]
Message-ID: <20140604111755.GG2520@sirena.org.uk> (raw)
In-Reply-To: <538EBACB.70100@ziswiler.com>

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

On Wed, Jun 04, 2014 at 08:20:59AM +0200, Marcel Ziswiler wrote:
> On 06/03/2014 11:45 AM, Mark Brown wrote:

> >When you say "generic user space access" you are describing a specific
> >detail of how this device happens to be controlled with your software.

> No, not at all. In fact I did not even specify neither the exact type of
> device apart from it being a SPI device nor any property of the software
> apart from the generic user space access thereof implemented in the Linux

You're saying you're controlling it from userspace.  This is a
particular detail of what you are doing in your system.  You happen to
want to control the devices you are hanging off the system with
userspace drivers but that's just what you're doing right now.

> kernel. I really don't see any difference to i2c chardev which is already
> enabled in multi_v7_defconfig.

That does not require explicit registration as the device driver for the
device in order to be used.

> >This is not a description of your hardware, it is a description of how
> >it is controlled with your current software.

> Sorry, but I really don't know what you are referring to. It's a pure
> hardware description of some pins being the SPI bus namely MISO/MOSI and the
> clock plus an accompanying chip-select pin.

No, that's in the controller node - the chip selects are described
there.  The child node references a chip select number that the master
has and describes what's connected to that chip select.

> I fear for some reason or another you have some affinity against spidev
> which strikes me odd. Admittedly it is not perfect but it is the only
> generic SPI user space access currently implemented in the Linux kernel and
> so far did its job perfectly for many of our customers.

It's a perfectly fine way of controlling things from userspace if that's
a sensible way of controlling devices but that does not mean you should
describe it in the device tree in that fashion.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds
Date: Wed, 4 Jun 2014 12:17:55 +0100	[thread overview]
Message-ID: <20140604111755.GG2520@sirena.org.uk> (raw)
In-Reply-To: <538EBACB.70100@ziswiler.com>

On Wed, Jun 04, 2014 at 08:20:59AM +0200, Marcel Ziswiler wrote:
> On 06/03/2014 11:45 AM, Mark Brown wrote:

> >When you say "generic user space access" you are describing a specific
> >detail of how this device happens to be controlled with your software.

> No, not at all. In fact I did not even specify neither the exact type of
> device apart from it being a SPI device nor any property of the software
> apart from the generic user space access thereof implemented in the Linux

You're saying you're controlling it from userspace.  This is a
particular detail of what you are doing in your system.  You happen to
want to control the devices you are hanging off the system with
userspace drivers but that's just what you're doing right now.

> kernel. I really don't see any difference to i2c chardev which is already
> enabled in multi_v7_defconfig.

That does not require explicit registration as the device driver for the
device in order to be used.

> >This is not a description of your hardware, it is a description of how
> >it is controlled with your current software.

> Sorry, but I really don't know what you are referring to. It's a pure
> hardware description of some pins being the SPI bus namely MISO/MOSI and the
> clock plus an accompanying chip-select pin.

No, that's in the controller node - the chip selects are described
there.  The child node references a chip select number that the master
has and describes what's connected to that chip select.

> I fear for some reason or another you have some affinity against spidev
> which strikes me odd. Admittedly it is not perfect but it is the only
> generic SPI user space access currently implemented in the Linux kernel and
> so far did its job perfectly for many of our customers.

It's a perfectly fine way of controlling things from userspace if that's
a sensible way of controlling devices but that does not mean you should
describe it in the device tree in that fashion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140604/93c068c6/attachment.sig>

  reply	other threads:[~2014-06-04 11:17 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c5522b0efcbfc7690dcde6aaf78b9dd568f99604.1401665237.git.marcel@ziswiler.com>
     [not found] ` <c5522b0efcbfc7690dcde6aaf78b9dd568f99604.1401665237.git.marcel-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-01 23:37   ` [PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds Marcel Ziswiler
2014-06-01 23:37     ` Marcel Ziswiler
2014-06-01 23:37     ` Marcel Ziswiler
2014-06-02 16:11     ` Stephen Warren
2014-06-02 16:11       ` Stephen Warren
2014-06-02 16:28       ` Marcel Ziswiler
2014-06-02 16:28         ` Marcel Ziswiler
     [not found]         ` <538CA635.4050502-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-02 22:16           ` Mark Brown
2014-06-02 22:16             ` Mark Brown
2014-06-02 22:16             ` Mark Brown
     [not found]             ` <20140602221627.GP31751-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-06-03  6:02               ` Marcel Ziswiler
2014-06-03  6:02                 ` Marcel Ziswiler
2014-06-03  6:02                 ` Marcel Ziswiler
     [not found]                 ` <538D64FD.2010909-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-03  9:45                   ` Mark Brown
2014-06-03  9:45                     ` Mark Brown
2014-06-03  9:45                     ` Mark Brown
     [not found]                     ` <20140603094537.GQ31751-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-06-04  6:20                       ` Marcel Ziswiler
2014-06-04  6:20                         ` Marcel Ziswiler
2014-06-04  6:20                         ` Marcel Ziswiler
2014-06-04 11:17                         ` Mark Brown [this message]
2014-06-04 11:17                           ` Mark Brown
     [not found]                           ` <20140604111755.GG2520-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-06-09 22:16                             ` Marcel Ziswiler
2014-06-09 22:16                               ` Marcel Ziswiler
2014-06-09 22:16                               ` Marcel Ziswiler
2014-06-09 22:57                               ` Mark Brown
2014-06-09 22:57                                 ` Mark Brown
2014-06-01 23:37   ` [PATCH 3/3] arm: tegra: initial support for apalis t30 Marcel Ziswiler
2014-06-01 23:37     ` Marcel Ziswiler
2014-06-01 23:37     ` Marcel Ziswiler
     [not found]     ` <b470c9c8631a6ef021d140192eb07006de3cfd93.1401665237.git.marcel-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-02 16:26       ` Stephen Warren
2014-06-02 16:26         ` Stephen Warren
2014-06-02 16:26         ` Stephen Warren
     [not found]         ` <538CA5C3.5050709-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-02 20:18           ` Marcel Ziswiler
2014-06-02 20:18             ` Marcel Ziswiler
2014-06-02 20:18             ` Marcel Ziswiler
     [not found]             ` <538CDC08.7020106-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-02 20:33               ` Stephen Warren
2014-06-02 20:33                 ` Stephen Warren
2014-06-02 20:33                 ` Stephen Warren
2014-06-02 16:33       ` Stephen Warren
2014-06-02 16:33         ` Stephen Warren
2014-06-02 16:33         ` Stephen Warren
     [not found]         ` <538CA749.3010106-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-02 20:24           ` Marcel Ziswiler
2014-06-02 20:24             ` Marcel Ziswiler
2014-06-02 20:24             ` Marcel Ziswiler

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=20140604111755.GG2520@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marcel@ziswiler.com \
    --cc=stefan@agner.ch \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    /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.