[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f431e418-0b7c-4362-be26-9d2f03e0de07@sirena.org.uk>
Date: Sun, 7 Jan 2024 21:26:59 +0000
From: Mark Brown <broonie@...nel.org>
To: Jonathan Cameron <jic23@...nel.org>
Cc: David Lechner <dlechner@...libre.com>, linux-iio@...r.kernel.org,
linux-spi@...r.kernel.org, devicetree@...r.kernel.org,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Michael Hennerich <michael.hennerich@...log.com>,
Nuno Sá <nuno.sa@...log.com>,
Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: spi: add spi-rx-bus-channels
peripheral property
On Sun, Jan 07, 2024 at 04:43:56PM +0000, Jonathan Cameron wrote:
> David Lechner <dlechner@...libre.com> wrote:
> > This adds a new spi-rx-bus-channels property to the generic spi
> > peripheral property bindings. This property is used to describe
> > devices that have parallel data output channels.
> > This property is different from spi-rx-bus-width in that the latter
> > means that we are reading multiple bits of a single word at one time
> > while the former means that we are reading single bits of multiple words
> > at the same time.
> Mark, could you take a look at this SPI binding change when you have time?
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
> I don't want to apply it without your view on whether this makes sense
> from a general SPI point of view as we all hate maintaining bindings
> if they turn out to not be sufficiently future looking etc and we need
> to deprecate them in favour of something else.
This makes no sense to me without a corresponding change in the SPI core
and possibly controller support, though I guess you could do data
manging to rewrite from a normal parallel SPI to this for a pure
software implementation. I also see nothing in the driver that even
attempts to parse this so I can't see how it could possibly work.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists