public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mans@mansr.com (Måns Rullgård)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] spi: atmel: improve internal vs gpio chip-select choice
Date: Tue, 12 Jan 2016 09:08:04 +0000	[thread overview]
Message-ID: <yw1xfuy3upvv.fsf@unicorn.mansr.com> (raw)
In-Reply-To: <5694BE36.7060702@atmel.com> (Nicolas Ferre's message of "Tue, 12 Jan 2016 09:49:58 +0100")

Nicolas Ferre <nicolas.ferre@atmel.com> writes:

> Le 11/01/2016 16:43, M?ns Rullg?rd a ?crit :
>> Nicolas Ferre <nicolas.ferre@atmel.com> writes:
>> 
>>> Le 08/01/2016 01:11, Mans Rullgard a ?crit :
>>>> The driver currently chooses between internal chip-select or gpio
>>>> based on the existence of the cs-gpios DT property which fails on
>>>> non-DT systems and also enforces the same choice for all devices.
>>>
>>> Well, I fear that such a per-device choice may impact further the driver
>>> than just moving a field from one structure to another...
>> 
>> Could you please elaborate?
>
> Well, the first thing that comes to my mind is that the DT property may
> need to be  to the SPI device node and not the controller anymore, for a
> need of coherency.
> That would imply modifying the binding and I don't want that for such an
> useless "improvement".
>
>>> Moreover, I have the feeling that it was not the objective of this
>>> patch.
>> 
>> Your feeling is mistaken.  If it's somehow impossible to mix CS types,
>> please explain why.
>
> Please only fix the avr32 issue with CS gpio selection that I admit we
> have. I don't need nor want to mix CS types: it just doesn't make sense
> to allow it.

OK, fine.  I thought it could be useful (and it works), but apparently
you disagree.

Now the trouble with a global gpio vs internal setting is that we don't
know whether the non-DT platform data provides a gpio for the slave
devices when the master device is probed.  One possibility is to make
the choice based on the first slave to be registered and insist that the
rest follow suit.  I don't really like it, but I can't think of anything
else off the top of my head.  Do you have any better suggestions?

-- 
M?ns Rullg?rd

  reply	other threads:[~2016-01-12  9:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1452211907-16074-1-git-send-email-mans@mansr.com>
2016-01-11 15:26 ` [PATCH] spi: atmel: improve internal vs gpio chip-select choice Nicolas Ferre
2016-01-11 15:43   ` Måns Rullgård
2016-01-12  8:49     ` Nicolas Ferre
2016-01-12  9:08       ` Måns Rullgård [this message]
2016-01-13  2:07       ` Måns Rullgård
2016-01-11 16:33   ` Cyrille Pitchen
2016-01-11 16:37     ` Måns Rullgård

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=yw1xfuy3upvv.fsf@unicorn.mansr.com \
    --to=mans@mansr.com \
    --cc=linux-arm-kernel@lists.infradead.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