linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Andi Shyti <andi.shyti@samsung.com>
Cc: Andi Shyti <andi@etezian.org>, Kukjin Kim <kgene@kernel.org>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/5] spi: do not fail if the CS line is not connected
Date: Mon, 27 Jun 2016 14:06:57 +0100	[thread overview]
Message-ID: <20160627130657.GV28202@sirena.org.uk> (raw)
In-Reply-To: <20160627105716.GA7240@samsunx.samsung>

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

On Mon, Jun 27, 2016 at 07:57:16PM +0900, Andi Shyti wrote:

> What I meant is that if we do not like num-cs = <0>, the
> unlinked CS line can be handled only this way (case of the
> s3c64xx driver):

> +- broken-cs: the CS line is disconnected, therefore the device should not wait
> +  for the CS protocol to be established

So what you're saying here is that you just need a property for the
inability to read back the chip select status?  That seems like a
totally reasonable thing to have which fits in idiomatically with the
rest of the subsystem.  I might call it no-cs-readback or something.

> Which is not something I like, because it means adding a new
> flag in the dts.

> What I want to suggest, instead, is to slightly change the logic
> behind the num-cs property: i.e. if "num-cs = <0>", doesn't
> necessarily mean that we don't have a CS controller, but, while
> we can have as many as we wish, non of them is connected.

I disagree, I think from a system integration point of view this is just
a chip select which can't be changed and it's less likely that we will
run into nasty surprises later on with things assuming that chip selects
exist.  AFAICT you only need this property in your case because this
controller has some features that rely on readback of the chip select
status, that's not very common - normally it'd be write only.  I'd
expect most controllers would just say they have one chip select and
that'd be that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-06-27 13:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-17  7:57 [PATCH 0/5] SPI CS line logical change and s3c64xx code rework Andi Shyti
     [not found] ` <1466150245-2648-1-git-send-email-andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-06-17  7:57   ` [PATCH 1/5] spi: do not fail if the CS line is not connected Andi Shyti
     [not found]     ` <1466150245-2648-2-git-send-email-andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-06-17 10:47       ` Mark Brown
2016-06-17 11:36         ` Andi Shyti
     [not found]           ` <20160617113622.GA10760-A05emIGRluN/OPZsa/fw/Q@public.gmane.org>
2016-06-17 12:28             ` Mark Brown
     [not found]               ` <20160617122803.GN26099-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-19  6:09                 ` Andi Shyti
     [not found]                   ` <20160619060902.GB424-A05emIGRluN/OPZsa/fw/Q@public.gmane.org>
2016-06-26 12:48                     ` Mark Brown
     [not found]                       ` <20160626124843.GP28202-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-27 10:57                         ` Andi Shyti
2016-06-27 13:06                           ` Mark Brown [this message]
     [not found]                             ` <20160627130657.GV28202-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-27 14:08                               ` Andi Shyti
2016-06-17  7:57   ` [PATCH 2/5] spi: s3c64xx: group the CS signalling writes in a single function Andi Shyti
2016-06-30 12:15     ` Applied "spi: s3c64xx: group the CS signalling writes in a single function" to the spi tree Mark Brown
2016-06-17  7:57 ` [PATCH 3/5] spi: s3c64xx: consider the case where the CS line is not connected Andi Shyti
2016-06-17  7:57 ` [PATCH 4/5] spi: s3c64xx: do not configure the device twice Andi Shyti
2016-06-30 12:15   ` Applied "spi: s3c64xx: do not configure the device twice" to the spi tree Mark Brown
2016-06-17  7:57 ` [PATCH 5/5] spi: s3c63xx: simplify if statement in prepare_transfer function Andi Shyti
2016-06-30 12:15   ` Applied "spi: s3c64xx: simplify if statement in prepare_transfer function" to the spi tree Mark Brown

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=20160627130657.GV28202@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=andi.shyti@samsung.com \
    --cc=andi@etezian.org \
    --cc=k.kozlowski@samsung.com \
    --cc=kgene@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.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 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).