From: Couret Charles-Antoine <charles-antoine.couret@mind.be>
To: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Cc: broonie@kernel.org, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2 v2] spi: add SPI_MOSI_IDLE_LOW support from device tree
Date: Sun, 29 Mar 2026 17:39:25 +0200 [thread overview]
Message-ID: <3a9dc8f9-0588-44ee-97ba-3a248d4f65dd@mind.be> (raw)
In-Reply-To: <ack2dPiLpO0uE2VE@debian-BULLSEYE-live-builder-AMD64>
Le 29/03/26 à 16:25, Marcelo Schmitt a écrit :
> Hello Charles-Antoine,
>
> On 03/29, charles-antoine.couret@mind.be wrote:
>> From: Charles-Antoine Couret <charles-antoine.couret@mind.be>
>>
>> This flag was introduced but was not added as device tree property which is
>> limiting the possibility to use this flag on real devices.
> I'm not seeing why a device tree property is needed for SPI idle modes. For
> idling high, the configuration is requested through spi_setup(). It should
> work in similar way for idling low. See spi-summary.rst. If believe a dt
> property is needed despite the spi_setup() interface, can you elaborate on why?
Hi Marcelo,
You're right that for a compliant SPI device, this devicetree option is
not really relevant and this must be in the driver itself. However, I
think the purpose of this mode is itself not designed for compliant SPI
devices.
It's not unusual to use Linux SPI subsystem for devices which are not
fully compliant with SPI in embedded context and where both options
(idle low or idle high) can make sense based on hardware design around
the device or the feature that you want. So having this property in
device tree is documenting the hardware then giving more flexibility.
For example we used that to communicate with TI DAC161P997 device, where
"IDLE low" setting can be used to detect when the device is really
powered or not. But this is an optional setting, this option does not
affect the rest of the driver.
I can understand this is a corner case and you don't want to support it
at all, I thought this can be interesting to provide it anyway. If you
want to reject it, I understand.
Thank you for the feedback and have a nice day.
Regards,
next prev parent reply other threads:[~2026-03-29 15:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-29 12:57 charles-antoine.couret
2026-03-29 14:25 ` Marcelo Schmitt
2026-03-29 15:39 ` Couret Charles-Antoine [this message]
2026-03-29 19:29 ` Marcelo Schmitt
2026-03-31 23:05 ` Couret Charles-Antoine
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=3a9dc8f9-0588-44ee-97ba-3a248d4f65dd@mind.be \
--to=charles-antoine.couret@mind.be \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.com \
/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
all inboxes | Powered by JetHome®