[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240729211534.7389a3e3@jic23-huawei>
Date: Mon, 29 Jul 2024 21:15:34 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Mark Brown <broonie@...nel.org>
Cc: lars@...afoo.de, Michael.Hennerich@...log.com, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, nuno.sa@...log.com,
dlechner@...libre.com, corbet@....net, marcelo.schmitt1@...il.com, Marcelo
Schmitt <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-spi@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: (subset) [PATCH v7 0/7] Add support for AD4000 series of ADCs
On Mon, 29 Jul 2024 19:02:29 +0100
Mark Brown <broonie@...nel.org> wrote:
> On Fri, 12 Jul 2024 16:20:00 -0300, Marcelo Schmitt wrote:
> > This patch series extends the SPI bitbang, gpio, and spi-engine controllers to
> > support configurable MOSI line idle states.
> > It then introduces the ad4000 driver which uses the MOSI idle configuration to
> > provide improved support for the AD4000 series of ADCs.
> > Documentation is added describing the new extension to the SPI protocol.
> > The currently supported wiring modes for AD4000 devices were documented under
> > IIO documentation directory.
> >
> > [...]
>
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
>
> Thanks!
>
> [1/7] spi: Enable controllers to extend the SPI protocol with MOSI idle configuration
> commit: f58872f45c36ded048bccc22701b0986019c24d8
> [2/7] spi: bitbang: Implement support for MOSI idle state configuration
> commit: 320f6693097bf89d67f9cabad24a2b911e23073f
> [3/7] spi: spi-gpio: Add support for MOSI idle state configuration
> commit: 927d382c7efbcc2206c31fa2f672fa264c0f1d5b
> [4/7] spi: spi-axi-spi-engine: Add support for MOSI idle configuration
> commit: a62073f4b2164028fc7c5ae45ceba10c9326cd91
> [5/7] dt-bindings: iio: adc: Add AD4000
> commit: 96472f18a4affdaff5013a836c48375f1eddb4a4
Ah. I replied to wrong message.
I suspect you didn't intend to pick up patch 5.
Any chance of a tag I can pull to support patches 5-7?
I need the HIGH flag in patch 1 only.
If not I'll replace it with a numeric value + comments, and queue up a patch for
next cycle to switch to the define.
Jonathan
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
Powered by blists - more mailing lists