From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751922AbcF0OId (ORCPT ); Mon, 27 Jun 2016 10:08:33 -0400 Received: from etezian.org ([198.101.225.253]:54023 "EHLO mail.etezian.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750870AbcF0OIb (ORCPT ); Mon, 27 Jun 2016 10:08:31 -0400 Date: Mon, 27 Jun 2016 23:08:27 +0900 From: Andi Shyti To: Mark Brown Cc: Andi Shyti , Andi Shyti , Kukjin Kim , Krzysztof Kozlowski , 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 Message-ID: <20160627140827.GF424@jack.zhora.eu> 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> <20160627130657.GV28202@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160627130657.GV28202@sirena.org.uk> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, > > 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. thanks for your feedback, I will then do as you say, I will use the no-cs-readback flag. Thanks again, Andi