Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753360AbbDULBe (ORCPT ); Tue, 21 Apr 2015 07:01:34 -0400 Received: from kiutl.biot.com ([31.172.244.210]:36270 "EHLO kiutl.biot.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751482AbbDULBb (ORCPT ); Tue, 21 Apr 2015 07:01:31 -0400 Message-ID: <55362E02.3070309@biot.com> Date: Tue, 21 Apr 2015 13:01:22 +0200 From: Bert Vermeulen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Geert Uytterhoeven , Mark Brown CC: linux-spi , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] spi: rb4xx: Fix set_cs logic. References: <1429538005-1985-1-git-send-email-bert@biot.com> <20150420203703.GG14892@sirena.org.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1457 Lines: 34 On 04/21/2015 11:46 AM, Geert Uytterhoeven wrote: > On Mon, Apr 20, 2015 at 10:37 PM, Mark Brown wrote: >> On Mon, Apr 20, 2015 at 03:53:25PM +0200, Bert Vermeulen wrote: >>> As it turns out, the set_cs() enable parameter refers to the logic level >>> on the CS pin, not the state of chip selection. >> >>> This broke functionality of the LEDs behind the CPLD, or at least delayed >>> the commands until another one came in to toggle CS. >> >> No, the enable parameter *should* refer to chip select assertion (see >> how we handle GPIO chip selects). However it's possible that this >> device has an inverted chip select and should be registered with the >> SPI_CS_HIGH flag? > > It's logic level: > > * @set_cs: set the logic level of the chip select line. May be called > * from interrupt context. Right It's the implementation which doesn't really make sense IMHO: it always inverts the "enable" parameter (unless SPI_CS_HIGH is set), in keeping with the default active-low. So the docs are right, but "enable" doesn't match what it does. Chip select assertion would be a better API here. Is it worth fixing? -- Bert Vermeulen bert@biot.com email/xmpp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/