mbox series

[00/11] ARM: removal of STiH415/STiH416 remainings bits

Message ID 20230209091659.1409-1-avolmat@me.com (mailing list archive)
Headers show
Series ARM: removal of STiH415/STiH416 remainings bits | expand

Message

Alain Volmat Feb. 9, 2023, 9:16 a.m. UTC 
Most of code in order to support STiH415 and STiH416 have already
been removed from the kernel in 2016, however few bits are still
remainings.
This serie removes the last pieces of support for STiH415, STiH416
and STiD127.

Alain Volmat (11):
  Documentation: arm: remove stih415/stih416 related entries
  ARM: sti: removal of stih415/stih416 related entries
  irqchip/st: remove stih415/stih416 and stid127 platforms support
  dt-bindings: irqchip: sti: remove stih415/stih416 and stid127
  dt-bindings: arm: sti: remove bindings for stih415 and stih416
  thermal/drivers/st: remove syscfg based driver
  net: ethernet: stmmac: dwmac-sti: remove stih415/stih416/stid127
  dt-bindings: net: dwmac: sti: remove stih415/sti416/stid127
  dt-bindings: reset: remove stih415/stih416 reset bindings
  dt-bindings: clock: remove stih416 bindings
  ARM: debug: removal of STiH415/STiH416 related debug uart

 Documentation/arm/index.rst                   |   2 -
 Documentation/arm/sti/overview.rst            |  10 +-
 Documentation/arm/sti/stih415-overview.rst    |  14 --
 Documentation/arm/sti/stih416-overview.rst    |  13 --
 .../devicetree/bindings/arm/sti.yaml          |   2 -
 .../st,sti-irq-syscfg.txt                     |   9 +-
 .../devicetree/bindings/net/sti-dwmac.txt     |   3 +-
 arch/arm/Kconfig.debug                        |  28 ---
 arch/arm/mach-sti/Kconfig                     |  20 +-
 arch/arm/mach-sti/board-dt.c                  |   2 -
 drivers/irqchip/irq-st.c                      |  15 --
 .../net/ethernet/stmicro/stmmac/dwmac-sti.c   |  60 +-----
 drivers/thermal/st/Kconfig                    |   4 -
 drivers/thermal/st/Makefile                   |   1 -
 drivers/thermal/st/st_thermal_syscfg.c        | 174 ------------------
 include/dt-bindings/clock/stih416-clks.h      |  17 --
 include/dt-bindings/reset/stih415-resets.h    |  28 ---
 include/dt-bindings/reset/stih416-resets.h    |  52 ------
 18 files changed, 8 insertions(+), 446 deletions(-)
 delete mode 100644 Documentation/arm/sti/stih415-overview.rst
 delete mode 100644 Documentation/arm/sti/stih416-overview.rst
 delete mode 100644 drivers/thermal/st/st_thermal_syscfg.c
 delete mode 100644 include/dt-bindings/clock/stih416-clks.h
 delete mode 100644 include/dt-bindings/reset/stih415-resets.h
 delete mode 100644 include/dt-bindings/reset/stih416-resets.h

Comments

Daniel Lezcano Feb. 10, 2023, 9:04 a.m. UTC | #1 
On Thu, Feb 09, 2023 at 10:16:48AM +0100, Alain Volmat wrote:
> Most of code in order to support STiH415 and STiH416 have already
> been removed from the kernel in 2016, however few bits are still
> remainings.
> This serie removes the last pieces of support for STiH415, STiH416
> and STiD127.

How would like to have the patches applied ?

Ack from the different maintainers or each maintainer apply the relevant patches ?

Thanks
  -- Daniel
Alain Volmat Feb. 10, 2023, 9:12 a.m. UTC | #2 
On Fri, Feb 10, 2023 at 10:04:20AM +0100, Daniel Lezcano wrote:
> On Thu, Feb 09, 2023 at 10:16:48AM +0100, Alain Volmat wrote:
> > Most of code in order to support STiH415 and STiH416 have already
> > been removed from the kernel in 2016, however few bits are still
> > remainings.
> > This serie removes the last pieces of support for STiH415, STiH416
> > and STiD127.
> 
> How would like to have the patches applied ?
> 
> Ack from the different maintainers or each maintainer apply the relevant patches ?

Having seen situations like that for some other series I was guessing
that each maintainer would apply the relevant patches on his side.
Those two platforms being no more used, there is no specific patch
ordering to keep.

I've actually been wondering at the beginning how should I post those
patches.  If another way is preferrable I can post again differently
if that helps.

Thanks
Alain

> 
> Thanks
>   -- Daniel
> 
> -- 
> 
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
> 
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
Jakub Kicinski Feb. 10, 2023, 6:13 p.m. UTC | #3 
On Fri, 10 Feb 2023 10:12:25 +0100 Alain Volmat wrote:
> Having seen situations like that for some other series I was guessing
> that each maintainer would apply the relevant patches on his side.
> Those two platforms being no more used, there is no specific patch
> ordering to keep.
> 
> I've actually been wondering at the beginning how should I post those
> patches.  If another way is preferrable I can post again differently
> if that helps.

You'd have most luck getting the changes accepted for 6.3 if you split
this up and resend to individual maintainers.
Alain Volmat Feb. 16, 2023, 7:59 p.m. UTC | #4 
On Fri, Feb 10, 2023 at 10:13:20AM -0800, Jakub Kicinski wrote:
> On Fri, 10 Feb 2023 10:12:25 +0100 Alain Volmat wrote:
> > Having seen situations like that for some other series I was guessing
> > that each maintainer would apply the relevant patches on his side.
> > Those two platforms being no more used, there is no specific patch
> > ordering to keep.
> > 
> > I've actually been wondering at the beginning how should I post those
> > patches.  If another way is preferrable I can post again differently
> > if that helps.
> 
> You'd have most luck getting the changes accepted for 6.3 if you split
> this up and resend to individual maintainers.

Alright, since those patches do not have real dependencies between each
others, I won't update this serie and send the patches separately to
their related maintainers.