[RFC,0/5] Deprecate register_restart_handler()

Message

Andrew Davis Nov. 17, 2023, 4:10 p.m. UTC

Hello all,

Explanation is in patch #1.

The rest of this series is a set of representative examples of converting
away from the old API. They should be valid and can be taken by their
respective maintainers even if patch #1 doesn't find acceptance.

Thanks,
Andrew

Andrew Davis (5):
  kernel/reboot: Deprecate register_restart_handler()
  drivers/soc/litex: Use devm_register_restart_handler()
  power: reset: gpio-restart: Use devm_register_sys_off_handler()
  spi: sprd: adi: Use devm_register_restart_handler()
  firmware: psci: Use register_sys_off_handler(SYS_OFF_MODE_RESTART)

 drivers/firmware/psci/psci.c       | 10 ++-------
 drivers/power/reset/gpio-restart.c | 34 ++++++++----------------------
 drivers/soc/litex/litex_soc_ctrl.c | 23 +++++---------------
 drivers/spi/spi-sprd-adi.c         | 30 +++++++-------------------
 include/linux/reboot.h             |  8 +++++--
 kernel/reboot.c                    |  3 +++
 6 files changed, 33 insertions(+), 75 deletions(-)

Comments

Mark Brown Nov. 27, 2023, 4:48 p.m. UTC | #1

On Fri, 17 Nov 2023 10:10:01 -0600, Andrew Davis wrote:
> Explanation is in patch #1.
> 
> The rest of this series is a set of representative examples of converting
> away from the old API. They should be valid and can be taken by their
> respective maintainers even if patch #1 doesn't find acceptance.
> 
> Thanks,
> Andrew
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[4/5] spi: sprd: adi: Use devm_register_restart_handler()
      commit: 8e6a43961f24cf841d3c0d199521d0b284d948b9

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

Gabriel L. Somlo Nov. 29, 2023, 10:09 a.m. UTC | #2

Hi Mark,

On Mon, Nov 27, 2023 at 04:48:29PM +0000, Mark Brown wrote:
> On Fri, 17 Nov 2023 10:10:01 -0600, Andrew Davis wrote:
> > Explanation is in patch #1.
> > 
> > The rest of this series is a set of representative examples of converting
> > away from the old API. They should be valid and can be taken by their
> > respective maintainers even if patch #1 doesn't find acceptance.
> > 
> > Thanks,
> > Andrew
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
> 
> Thanks!
> 
> [4/5] spi: sprd: adi: Use devm_register_restart_handler()
>       commit: 8e6a43961f24cf841d3c0d199521d0b284d948b9

Any chance you can also pick up

[2/5] drivers/soc/litex: Use devm_register_restart_handler()

from this series?

I'm maintaining the LiteX (FPGA SoC) related drivers, but we don't as of
yet have a dedicated "path to upstream" of our own -- we've been mostly
going through specific subsystem trees (e.g. mmc, block, networking, etc.),
for mostly device drivers, up until now...

If not, no worries, I need to dedicate some time to figuring this out
eventually anyway :)

Thanks much,
--Gabriel

> 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
>