From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752023AbcF0NHN (ORCPT ); Mon, 27 Jun 2016 09:07:13 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:46368 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751671AbcF0NHL (ORCPT ); Mon, 27 Jun 2016 09:07:11 -0400 Date: Mon, 27 Jun 2016 14:06:57 +0100 From: Mark Brown To: Andi Shyti Cc: Andi Shyti , Kukjin Kim , Krzysztof Kozlowski , linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Message-ID: <20160627130657.GV28202@sirena.org.uk> References: <1466150245-2648-1-git-send-email-andi.shyti@samsung.com> <1466150245-2648-2-git-send-email-andi.shyti@samsung.com> <20160617104725.GC26099@sirena.org.uk> <20160617113622.GA10760@jack.zhora.eu> <20160617122803.GN26099@sirena.org.uk> <20160619060902.GB424@jack.zhora.eu> <20160626124843.GP28202@sirena.org.uk> <20160627105716.GA7240@samsunx.samsung> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7z668gRi33XfcD/+" Content-Disposition: inline In-Reply-To: <20160627105716.GA7240@samsunx.samsung> X-Cookie: Beware of Bigfoot! User-Agent: Mutt/1.6.0 (2016-04-01) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 1/5] spi: do not fail if the CS line is not connected X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --7z668gRi33XfcD/+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. --7z668gRi33XfcD/+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXcSTrAAoJECTWi3JdVIfQjaEH/RDSWuBB7G3XEFXRRM1s8V5s zcXqnL5ngzizL5JLrBSvJVjtAv0h0aLa7QPfoJj9xb1tkcQJptSBsxBOfj9HRvja JTiwVPaAHmIjy5azklF0A3GnqViFxX7e5Q7s+DukDC6LV+WPMKkM82qZECkkKbUK o9Y1bPmplbVCwlXoYgXbFGi9tm4RZcqxT+/sk2CM5wHlNjW1sYNynhjybTctn5wv HMftpe+QhW/cIODTGG9WeS1phZmIac9hnan4ZHi9K8iVEkd/L/sjXH7ZycJBifMS 3jQZe2Hp2+WqnN7xwvp/pGPZk5F2f6YJ/4lfPVUd2ZGn2xesXUOmXgwy5lctYxY= =00VN -----END PGP SIGNATURE----- --7z668gRi33XfcD/+--