mbox series

[0/5] Improve error handling in Rockchip SPI drivers

Message ID cover.1727337732.git.dsimic@manjaro.org
Headers show
Series Improve error handling in Rockchip SPI drivers | expand

Message

Dragan Simic Sept. 26, 2024, 8:38 a.m. UTC
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

 drivers/spi/spi-rockchip-sfc.c | 21 +++++--------
 drivers/spi/spi-rockchip.c     | 57 ++++++++++++++--------------------
 2 files changed, 32 insertions(+), 46 deletions(-)

Comments

Mark Brown Sept. 30, 2024, 11:51 p.m. UTC | #1
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!

[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

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
Diederik de Haas Oct. 1, 2024, 12:05 a.m. UTC | #2
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!
>
> [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/
Dragan Simic Oct. 1, 2024, 2:30 a.m. UTC | #3
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.