From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 079521E493C for ; Tue, 7 Jan 2025 23:40:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736293216; cv=none; b=YQG4hWvf8ISIUufKQWMr8m+HqGLcr6KNeSR3n/0ViFKg3+IPOZrVB+wWXBjeklCHelc8UsMjzwwNPmovf+1AATr+blM5tXOyjGJyJnYe/PcFVUY6UHVIxTk9nJ9MrWjCLdGgIAJRlX8uKCmvXnnHeThCQtPJSzNQuNNQt9g+Y7E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736293216; c=relaxed/simple; bh=jfTpOGKr0wQcc2L8f69AZ9dp6NW5ajddeQBm1nraAXM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Q6fE0lXLJHTin6rRyr3iXdZxAvEUy8MZ8xFfXwSkZb/io8SUqbQ5U8rvamvIbSzdid1Fcc1s/Si+ifsxDuAkbbeXVr8bLzS3XrcRxM+cOpiIBX2tKzTeOuVAVatrdLhiGSOj6LeIRBTgkJ15TzUH6UqitvJdmMCcRizBgvYXKU0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=z7HBq2nj; arc=none smtp.client-ip=209.85.210.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="z7HBq2nj" Received: by mail-ot1-f44.google.com with SMTP id 46e09a7af769-71e3005916aso3408521a34.2 for ; Tue, 07 Jan 2025 15:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1736293214; x=1736898014; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=O2Eas7BrmzjhcA+ZrXqMVkpxsT7oX0umexUKB4e1IpE=; b=z7HBq2njBu1jHNG84Mcv87i+tp8KqdQw3ZGmC5ibgNdSVyGEHB9MoOwu3cS2kfuUmJ t7PZWUPj4YB0J9rv5rQ7Qy+lxJrJ49GP2iXeLiwm01tSzJe0eQkRNqofNgSXko/yrfIF eBmBU7H1gLB/x3ecSBPSc2IaOBk8HWbtFmUPdOPx54c+DnlXozcdspwAkH/JkYVhhlEp d2Yn8UdpWzLVl3lf6EMe5bUcKY0zzX//+pRQR0t41N2E/Ry2/N3PaZnldynP4C5RU2Yd OO6/suk3O0N+FWiW7Hs9hky8miqmeYBwRS+niZ91CiCA18Z3vwOJ6a0t22AbsJZuHDCP OjUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736293214; x=1736898014; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=O2Eas7BrmzjhcA+ZrXqMVkpxsT7oX0umexUKB4e1IpE=; b=BxhwJr2jz8YOxLXLouH2fCuFpHSca7j4igIj/j/5ATcIFw6TQ5knVuDUuL2jH2uOUk fr2tEl4KcJFAXtZIXZrOtxD7fBRULn+eaVKmg68eXEWL68UgFMyVoMvHUuJBqcS1cECx tKNYmb7ksz/35vUH8PoL07cYPivq5jOakU3TiB68JLjZ6+OrGrKR2QVApTqyfcuE/qL5 w8nEFwPr6807UYNZ618i4Dx/byTtQMfla8sB8Q6CxRsV/dNXV2UFSiOERjL/XodHgGxE 66vgqjVa55sIv45obmGexbRM+zwlASTYDPWicZKwTyzwZHaUgIX4rfLUXGWbSiNXTiRX GawQ== X-Forwarded-Encrypted: i=1; AJvYcCVTyFzxihJ7cA/jICnQ0um6RHsVquUhpmk7XXQqCMWd7EA2I+PeR+JUVWnNKWyUDKkTBCrhWpig168xaj8=@vger.kernel.org X-Gm-Message-State: AOJu0YysfXJkysw/wsFVoKbwSn5qzbicf1gZ1Oi2v1kOdcYjMoMt2ZRt ZUXvI5+j7Yl0XcRk+Sw6XgsRbFMECgzR+7GirZEDbCPAPQvYpw6remcYDtxBnqo= X-Gm-Gg: ASbGncuq7vkghqfAioMqqqOVWjXd4qPJkZ2OOY+a8Qwv17OPOgZUqPtFbBDu68EnS0d XAnlYfmiS8USS1TFGQ368crCdKWuk3p/OAl6QJ9RtDLX+On7Ailbuyb5thv2BQC87VDI7ql9Im9 RG4LtoUH3S6OFNASynfiQBe9VM9rLoCF7lyK9HPmOx77Es4ACJq8eSLwdns70Z6uY/u28rPSINL se1OCbHjzX/EiDcodEHn+n6P+EOtqU0mzFs5NCbY+JZCx2iYqOals1ULxo/lZXbzjtmJbXWfYX0 n591nIwLxhmERtVBuQ== X-Google-Smtp-Source: AGHT+IGtfDHNF/ydxld0CqCusHeQ1otA7hAtxou0jX/2OQsW5XxImqkiWOhjS8YyReikmH/jReFxKw== X-Received: by 2002:a05:6830:61c7:b0:718:7c3:f86a with SMTP id 46e09a7af769-721e2dfcb59mr638050a34.6.1736293214168; Tue, 07 Jan 2025 15:40:14 -0800 (PST) Received: from [192.168.0.142] (ip98-183-112-25.ok.ok.cox.net. [98.183.112.25]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-71fc97dc94dsm10555741a34.34.2025.01.07.15.40.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jan 2025 15:40:13 -0800 (PST) Message-ID: <4449ec60-08cd-4074-ba0b-95603864a458@baylibre.com> Date: Tue, 7 Jan 2025 17:40:12 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 05/15] iio: adc: ad7768-1: set MOSI idle state to high To: Jonathan Santos , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: lars@metafoo.de, Michael.Hennerich@analog.com, jic23@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, marcelo.schmitt1@gmail.com References: <714ff48341753de0509208e3c553b19c1c43e480.1736201898.git.Jonathan.Santos@analog.com> From: David Lechner Content-Language: en-US In-Reply-To: <714ff48341753de0509208e3c553b19c1c43e480.1736201898.git.Jonathan.Santos@analog.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/7/25 9:25 AM, Jonathan Santos wrote: > All supported parts require that the MOSI line stays high > while in idle. > > Configure SPI controller to set MOSI idle state to high. > > Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") > Signed-off-by: Jonathan Santos > --- > drivers/iio/adc/ad7768-1.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c > index c3cf04311c40..463a28d09c2e 100644 > --- a/drivers/iio/adc/ad7768-1.c > +++ b/drivers/iio/adc/ad7768-1.c > @@ -574,6 +574,15 @@ static int ad7768_probe(struct spi_device *spi) > return -ENOMEM; > > st = iio_priv(indio_dev); > + /* > + * The ADC SDI line must be kept high when > + * data is not being clocked out of the controller. > + * Request the SPI controller to make MOSI idle high. > + */ > + spi->mode |= SPI_MOSI_IDLE_HIGH; > + ret = spi_setup(spi); > + if (ret < 0) > + return ret; > st->spi = spi; > > st->vref = devm_regulator_get(&spi->dev, "vref"); Very few SPI controllers currently have the SPI_MOSI_IDLE_HIGH capability flag set in Linux right now (whether they actually support it or not), so this could break existing users. The datasheet says: When reading back data with CS held low, it is recommended that SDI idle high to prevent an accidental reset of the device where SCLK is free running (see the Reset section). And the reset section says: When CS is held low, it is possible to provide a reset by clocking in a 1 followed by 63 zeros on SDI, which is the SPI resume command reset function used to exit power-down mode. Since the largest xfer we do is 3 bytes before deasserting CS, I don't think we have any risk of accidentally resetting right now. If we ever do implement a data read of more than 64 bits without toggling CS, then we could just set the TX data to be all 0xFF and have the same effect without requiring the SPI controller to support SPI_MOSI_IDLE_HIGH.