[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c69fef216b1a2474bbab1a146ec63450@manjaro.org>
Date: Tue, 01 Oct 2024 04:30:17 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Diederik de Haas <didi.debian@...ow.org>
Cc: Mark Brown <broonie@...nel.org>, linux-spi@...r.kernel.org,
linux-rockchip@...ts.infradead.org, heiko@...ech.de, oss@...ene.moe,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: (subset) [PATCH 0/5] Improve error handling in Rockchip SPI
drivers
Hello Diederik and Mark,
On 2024-10-01 02:05, Diederik de Haas wrote:
> On Tue Oct 1, 2024 at 1:51 AM CEST, Mark Brown wrote:
>> On Thu, 26 Sep 2024 10:38:11 +0200, Dragan Simic wrote:
>> > This is a small series that improves error handling in the probe path
>> > of the Rockchip SPI drivers, by using dev_err_probe() properly in multiple
>> > places. It also removes one unnecessary check of a function return value,
>> > and performs a bunch of small, rather trivial code cleanups, to make the
>> > code neater and a bit easier to read.
>> >
>> > Dragan Simic (5):
>> > spi: rockchip: Perform trivial code cleanups
>> > spi: rockchip-sfc: Perform trivial code cleanups
>> > spi: rockchip: Don't check for failed get_fifo_len()
>> > spi: rockchip: Use dev_err_probe() in the probe path
>> > spi: rockchip-sfc: Use dev_err_probe() in the probe path
>> >
>> > [...]
>>
>> Applied to
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
>> for-next
Thanks for applying a subset of the patches!
>> [1/5] spi: rockchip: Perform trivial code cleanups
>> commit: d87ec94e48dd2da27fbe948f2dc6c8fedc98fff4
>> [2/5] spi: rockchip-sfc: Perform trivial code cleanups
>> commit: 6c510eac1528d8939bad8b6df72c7b23ffec8c25
>> [5/5] spi: rockchip-sfc: Use dev_err_probe() in the probe path
>> commit: 1482c40b440fa58f956bc3e1ef3426e0cdbc09e0
>
> It looks like you applied some patches from v1 of this series while the
> current version is v3.
>
> https://lore.kernel.org/linux-rockchip/cover.1727601608.git.dsimic@manjaro.org/
Just checked this by hand, and the three patches that were applied
are the same as the respective patches from the v3 of the series,
albeit being picked from the v1 of the series. It's just that the
patch 5/5 from the v1 became patch 3/5 in the v3, which pushed the
patches with no dependencies earlier within the series.
Powered by blists - more mailing lists