Make Hi3620 explicit, remove wildcards
Subsystems (7)
RFC 1/7 Make Hi3620 explicit, remove wildcards
This is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Only internal APIs are modified with this series.
--- arch/arm/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/Kconfig.debug +1 -1
@@ -280,7 +280,7 @@ choice config DEBUG_HI3620_UART bool "Hisilicon HI3620 Debug UART" - depends on ARCH_HI3xxx + depends on ARCH_HI3620 select DEBUG_UART_PL01X help Say Y here if you want kernel low-level debugging support
Signature · 1 line
2.9.3
RFC 2/7 Make Hi3620 explicit, remove wildcards
This is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Only internal APIs are modified with this series.
--- arch/arm/boot/dts/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/Makefile +1 -1
@@ -154,7 +154,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \ exynos5440-sd5v1.dtb \ exynos5440-ssdk5440.dtb \ exynos5800-peach-pi.dtb -dtb-$(CONFIG_ARCH_HI3xxx) += \ +dtb-$(CONFIG_ARCH_HI3620) += \ hi3620-hi4511.dtb dtb-$(CONFIG_ARCH_HIGHBANK) += \ highbank.dtb \
Signature · 1 line
2.9.3
RFC 2/7 Make Hi3620 explicit, remove wildcards
Quoted 6 lines · Marty Plummer
This is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Quoted 6 lines
Only internal APIs are modified with this series.
Signed-off-by Marty Plummer <[email protected]>--- arch/arm/boot/dts/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
A quick trick for figuring out the preferred Subject line format for a subsystem is to do:
$ git log --oneline --no-merges -- arch/arm/boot/dts/
thx,
Jason.
Quoted 22 lines
arch/arm/boot/dts/Makefile +1
-1@@ -154,7 +154,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \ exynos5440-sd5v1.dtb \ exynos5440-ssdk5440.dtb \ exynos5800-peach-pi.dtb -dtb-$(CONFIG_ARCH_HI3xxx) += \ +dtb-$(CONFIG_ARCH_HI3620) += \ hi3620-hi4511.dtb dtb-$(CONFIG_ARCH_HIGHBANK) += \ highbank.dtb \Signature · 7 lines
2.9.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
RFC 3/7 Make Hi3620 explicit, remove wildcards
In reply to Marty PlummerThis is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Only internal APIs are modified with this series.
--- arch/arm/configs/hisi_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/configs/hisi_defconfig +1 -1
@@ -4,7 +4,7 @@ CONFIG_HIGH_RES_TIMERS=y CONFIG_BLK_DEV_INITRD=y CONFIG_RD_LZMA=y CONFIG_ARCH_HISI=y -CONFIG_ARCH_HI3xxx=y +CONFIG_ARCH_HI3620=y CONFIG_PARTITION_ADVANCED=y CONFIG_CMDLINE_PARTITION=y CONFIG_ARCH_HIX5HD2=y
Signature · 1 line
2.9.3
RFC 4/7 Make Hi3620 explicit, remove wildcards
In reply to Marty PlummerThis is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Only internal APIs are modified with this series.
--- arch/arm/configs/multi_v7_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/configs/multi_v7_defconfig +1 -1
@@ -45,7 +45,7 @@ CONFIG_MACH_BERLIN_BG2Q=y CONFIG_ARCH_DIGICOLOR=y CONFIG_ARCH_HIGHBANK=y CONFIG_ARCH_HISI=y -CONFIG_ARCH_HI3xxx=y +CONFIG_ARCH_HI3620=y CONFIG_ARCH_HIX5HD2=y CONFIG_ARCH_HIP01=y CONFIG_ARCH_HIP04=y
Signature · 1 line
2.9.3
RFC 5/7 Make Hi3620 explicit, remove wildcards
In reply to Marty PlummerThis is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Only internal APIs are modified with this series.
--- arch/arm/mach-hisi/Kconfig | 4 ++-- arch/arm/mach-hisi/core.h | 10 +++++----- arch/arm/mach-hisi/hisilicon.c | 6 +++--- arch/arm/mach-hisi/hotplug.c | 16 ++++++++-------- arch/arm/mach-hisi/platsmp.c | 24 ++++++++++++------------ 5 files changed, 30 insertions(+), 30 deletions(-)
arch/arm/mach-hisi/Kconfig +2 -2
@@ -12,8 +12,8 @@ if ARCH_HISI menu "Hisilicon platform type" -config ARCH_HI3xxx - bool "Hisilicon Hi36xx family" +config ARCH_HI3620 + bool "Hisilicon Hi3620 family" depends on ARCH_MULTI_V7 select CACHE_L2X0 select HAVE_ARM_SCU if SMP
arch/arm/mach-hisi/core.h +5 -5
@@ -3,13 +3,13 @@#include <linux/reboot.h> -extern void hi3xxx_set_cpu_jump (int cpu,void *jump_addr); -extern int hi3xxx_get_cpu_jump (int cpu); +extern void hi3620_set_cpu_jump (int cpu,void *jump_addr); +extern int hi3620_get_cpu_jump (int cpu);extern void secondary_startup (void ); -extern void hi3xxx_cpu_die (unsigned int cpu); -extern int hi3xxx_cpu_kill (unsigned int cpu); -extern void hi3xxx_set_cpu (int cpu,bool enable); +extern void hi3620_cpu_die (unsigned int cpu); +extern int hi3620_cpu_kill (unsigned int cpu); +extern void hi3620_set_cpu (int cpu,bool enable);extern void hix5hd2_set_cpu (int cpu,bool enable);extern void hix5hd2_cpu_die (unsigned int cpu);
arch/arm/mach-hisi/hisilicon.c +3 -3
@@ -9,7 +9,7 @@* This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. -*/ +*/ #include <linux/clocksource.h> #include <linux/irqchip.h>
@@ -44,12 +44,12 @@ static void __init hi3620_map_io(void)iotable_init (hi3620_io_desc,ARRAY_SIZE (hi3620_io_desc)); } -static const char *const hi3xxx_compat[]__initconst = { +static const char *const hi3620_compat[]__initconst = {"hisilicon,hi3620-hi4511" ,NULL , };DT_MACHINE_START (HI3620 ,"Hisilicon Hi3620 (Flattened Device Tree)" ) .map_io = hi3620_map_io, - .dt_compat = hi3xxx_compat, + .dt_compat = hi3620_compat,MACHINE_END
arch/arm/mach-hisi/hotplug.c +8 -8
@@ -143,7 +143,7 @@ static void set_cpu_hi3620(int cpu, bool enable) } } -static int hi3xxx_hotplug_init (void ) +static int hi3620_hotplug_init (void ) {struct device_node *node;
@@ -157,10 +157,10 @@ static int hi3xxx_hotplug_init(void)return -ENOENT ; } -void hi3xxx_set_cpu (int cpu,bool enable) +void hi3620_set_cpu (int cpu,bool enable) {if (!ctrl_base) { -if (hi3xxx_hotplug_init () <0 ) +if (hi3620_hotplug_init () <0 )return ; }
@@ -262,24 +262,24 @@ static inline void cpu_enter_lowpower(void) }#ifdef CONFIG_HOTPLUG_CPU -void hi3xxx_cpu_die (unsigned int cpu) +void hi3620_cpu_die (unsigned int cpu) {cpu_enter_lowpower (); -hi3xxx_set_cpu_jump (cpu,phys_to_virt (0 )); +hi3620_set_cpu_jump (cpu,phys_to_virt (0 ));cpu_do_idle ();/* We should have never returned from idle */ panic ("cpu %d unexpectedly exit from shutdown\n" , cpu); } -int hi3xxx_cpu_kill (unsigned int cpu) +int hi3620_cpu_kill (unsigned int cpu) {unsigned long timeout = jiffies +msecs_to_jiffies (50 ); -while (hi3xxx_get_cpu_jump (cpu)) +while (hi3620_get_cpu_jump (cpu))if (time_after (jiffies, timeout))return 0 ; -hi3xxx_set_cpu (cpu, false); +hi3620_set_cpu (cpu, false);return 1 ; }
arch/arm/mach-hisi/platsmp.c +12 -12
@@ -23,7 +23,7 @@static void __iomem *ctrl_base; -void hi3xxx_set_cpu_jump (int cpu,void *jump_addr) +void hi3620_set_cpu_jump (int cpu,void *jump_addr) { cpu =cpu_logical_map (cpu);if (!cpu || !ctrl_base)
@@ -31,7 +31,7 @@ void hi3xxx_set_cpu_jump(int cpu, void *jump_addr)writel_relaxed (virt_to_phys (jump_addr), ctrl_base + ((cpu -1 ) <<2 )); } -int hi3xxx_get_cpu_jump (int cpu) +int hi3620_get_cpu_jump (int cpu) { cpu =cpu_logical_map (cpu);if (!cpu || !ctrl_base)
@@ -56,7 +56,7 @@ static void __init hisi_enable_scu_a9(void) } } -static void __init hi3xxx_smp_prepare_cpus (unsigned int max_cpus) +static void __init hi3620_smp_prepare_cpus (unsigned int max_cpus) {struct device_node *np =NULL ;u32 offset =0 ;
@@ -81,20 +81,20 @@ static void __init hi3xxx_smp_prepare_cpus(unsigned int max_cpus) } } -static int hi3xxx_boot_secondary (unsigned int cpu,struct task_struct *idle) +static int hi3620_boot_secondary (unsigned int cpu,struct task_struct *idle) { -hi3xxx_set_cpu (cpu, true); -hi3xxx_set_cpu_jump (cpu, secondary_startup); +hi3620_set_cpu (cpu, true); +hi3620_set_cpu_jump (cpu, secondary_startup);arch_send_wakeup_ipi_mask (cpumask_of (cpu));return 0 ; } -static const struct smp_operations hi3xxx_smp_ops__initconst = { - .smp_prepare_cpus = hi3xxx_smp_prepare_cpus, - .smp_boot_secondary = hi3xxx_boot_secondary, +static const struct smp_operations hi3620_smp_ops__initconst = { + .smp_prepare_cpus = hi3620_smp_prepare_cpus, + .smp_boot_secondary = hi3620_boot_secondary, #ifdef CONFIG_HOTPLUG_CPU - .cpu_die = hi3xxx_cpu_die, - .cpu_kill = hi3xxx_cpu_kill, + .cpu_die = hi3620_cpu_die, + .cpu_kill = hi3620_cpu_kill, #endif };
@@ -181,6 +181,6 @@ static const struct smp_operations hip01_smp_ops __initconst = { .smp_boot_secondary = hip01_boot_secondary, }; -CPU_METHOD_OF_DECLARE (hi3xxx_smp,"hisilicon,hi3620-smp" , &hi3xxx_smp_ops); +CPU_METHOD_OF_DECLARE (hi3620_smp,"hisilicon,hi3620-smp" , &hi3620_smp_ops);CPU_METHOD_OF_DECLARE (hix5hd2_smp,"hisilicon,hix5hd2-smp" , &hix5hd2_smp_ops);CPU_METHOD_OF_DECLARE (hip01_smp,"hisilicon,hip01-smp" , &hip01_smp_ops);
Signature · 1 line
2.9.3
RFC 6/7 Make Hi3620 explicit, remove wildcards
In reply to Marty PlummerThis is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Only internal APIs are modified with this series.
--- drivers/clk/hisilicon/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/hisilicon/Makefile +1 -1
@@ -4,7 +4,7 @@ obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o -obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o +obj-$(CONFIG_ARCH_HI3620) += clk-hi3620.o obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o obj-$(CONFIG_COMMON_CLK_HI3519) += clk-hi3519.o
Signature · 1 line
2.9.3
RFC 7/7 Make Hi3620 explicit, remove wildcards
In reply to Marty PlummerThis is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Only internal APIs are modified with this series.
--- drivers/dma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dma/Kconfig +1 -1
@@ -279,7 +279,7 @@ config INTEL_MIC_X100_DMA config K3_DMA tristate "Hisilicon K3 DMA support" - depends on ARCH_HI3xxx + depends on ARCH_HI3620 select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help
Signature · 1 line
2.9.3
RFC 7/7 Make Hi3620 explicit, remove wildcards
Quoted 6 lines · Marty Plummer
This is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Quoted 6 lines
Only internal APIs are modified with this series.
Signed-off-by Marty Plummer <[email protected]>--- drivers/dma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
This doesn't have to do with DMA, but it's last in the series, so...
I saw on IRC that you have the serial port, vic, and clock at some initial stage of working for your board, congrats!
I would add those patches to the end of this series implementing that basic functionality. That makes it very clear to everyone *why* the previous patches are necessary.
thx,
Jason.
RFC 7/7 Make Hi3620 explicit, remove wildcards
Quoted 14 lines · Jason Cooper
Quoted 6 lines · Marty Plummer
This is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Quoted 6 lines
Only internal APIs are modified with this series.
Signed-off-by Marty Plummer <[email protected]>--- drivers/dma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Quoted 5 lines
This doesn't have to do with DMA, but it's last in the series, so...
I saw on IRC that you have the serial port, vic, and clock at some initial stage of working for your board, congrats!
Yep! Also got usb going (well, I have to manually modprobe the modules, but it does work). Thanks a lot!
Quoted 3 lines
I would add those patches to the end of this series implementing that basic functionality. That makes it very clear to everyone *why* the previous patches are necessary.
I suppose so, I was just trying to keep changes as modular as possible, but if you think that's a good idea, I'll roll with it.
Quoted 5 lines
thx,
Jason.
RFC 1/7 Make Hi3620 explicit, remove wildcards
In reply to Marty PlummerHi Marty,
+ Andrew, Russell,
Since this is your first series, I'll go ahead and gather a few comments right here:
- Make sure to change the subject line for each patch.
The subject is retrieved from the first line of the commit. you can look at the output of 'git log --oneline' to see a nice, concise view of your series.
- Include 'PATCH' or 'Patch' inside the square brackets on the subject line.
When you use the prefix option, as you did, it *replaces* 'PATCH', so you need '--subject-prefix="RFC PATCH"' or '--subject-prefix="RFC PATCH V2"'
- Please Cc Andrew, Russell and myself on future series.
Personally, I do that at the 'send-email' stage instead of 'format-patch'. But whichever you prefer. Don't be shy about Cc'ing. We all are accustomed to handling lots of email. It makes it easier for us to spot stuff we are actively involved in. :-)
thx,
Jason.
Quoted 34 lines · Marty Plummer
This is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Only internal APIs are modified with this series.
Signed-off-by Marty Plummer <[email protected]>--- arch/arm/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig.debug +1
-1@@ -280,7 +280,7 @@ choice config DEBUG_HI3620_UART bool "Hisilicon HI3620 Debug UART" - depends on ARCH_HI3xxx + depends on ARCH_HI3620 select DEBUG_UART_PL01X help Say Y here if you want kernel low-level debugging supportSignature · 7 lines
2.9.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
RFC 1/7 Make Hi3620 explicit, remove wildcards
Quoted 5 lines · Jason Cooper
Hi Marty,
+ Andrew, Russell,
Quoted 9 lines
Since this is your first series, I'll go ahead and gather a few comments right here:
- Make sure to change the subject line for each patch.
The subject is retrieved from the first line of the commit. you can look at the output of 'git log --oneline' to see a nice, concise view of your series.
Ah crap. I knew the subject was taken from the first line of the commit, but to be honest I didn't think there was any real room for unique subjects here, since its quite literally the exact same changes in each file affected, but I take it this is a general rule that each patch in a series has to have a unique subject, then?
Quoted 5 lines
- Include 'PATCH' or 'Patch' inside the square brackets on the subject line.
When you use the prefix option, as you did, it *replaces* 'PATCH', so you need '--subject-prefix="RFC PATCH"' or '--subject-prefix="RFC PATCH V2"'
Ah ok. I didn't realize you needed both RFC and PATCH in this instance.
Quoted 12 lines
- Please Cc Andrew, Russell and myself on future series.
Personally, I do that at the 'send-email' stage instead of 'format-patch'. But whichever you prefer. Don't be shy about Cc'ing. We all are accustomed to handling lots of email. It makes it easier for us to spot stuff we are actively involved in. :-)
thx,
Jason.
Alrighty, I sorta realized this issue right after I sent, will do in future instances. Also, you say at 'send-email' instead of 'format-patch'; I take it there is a way to do the latter? I'm not aware of it :)
Quoted 35 lines · Marty Plummer
Quoted 34 lines
This is a preparatory series for adding the ARMv5/v6 hi3520 SoCs. Assumptions were made when adding hi3620 that don't hold water in light of adding support for the hi3520 SoC. Fix the issue by renaming config options and other namespaces to avoid collisions with the new work.
Only internal APIs are modified with this series.
Signed-off-by Marty Plummer <[email protected]>--- arch/arm/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig.debug +1
-1@@ -280,7 +280,7 @@ choice config DEBUG_HI3620_UART bool "Hisilicon HI3620 Debug UART" - depends on ARCH_HI3xxx + depends on ARCH_HI3620 select DEBUG_UART_PL01X help Say Y here if you want kernel low-level debugging supportSignature · 7 lines
2.9.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
RFC 1/7 Make Hi3620 explicit, remove wildcards
Quoted 8 lines · Marty Plummer
Quoted 7 lines · Jason Cooper
- Please Cc Andrew, Russell and myself on future series.
Personally, I do that at the 'send-email' stage instead of 'format-patch'. But whichever you prefer. Don't be shy about Cc'ing. We all are accustomed to handling lots of email. It makes it easier for us to spot stuff we are actively involved in. :-)
Quoted 4 lines
Alrighty, I sorta realized this issue right after I sent, will do in future instances. Also, you say at 'send-email' instead of 'format-patch'; I take it there is a way to do the latter? I'm not aware of it :)
Both git send-email and git format-patch take --to, --cc, --bcc as arguments. I prefer to do all of the email addressing with send-email instead of while doing format-patch. But it's personal preference, that's why the options are in both.
thx,
Jason.
RFC 1/7 Make Hi3620 explicit, remove wildcards
In reply to Marty PlummerHi Marty
Adding to Jasons comments... a [0/7] "patch" created via --cover should be include with all multi-patch series. It should explain the big picture for the whole set. What does this set do. Then you can leave each patch just explaining what it does.
Some maintainers will use the cover note as the log for the merge commit. So keep it formal in the same way as the individual patches comment.
Andrew
Arnd Bergmann
maintainerRFC 1/7 Make Hi3620 explicit, remove wildcards
In reply to Marty PlummerQuoted 9 lines · CEST Marty Plummer
arch/arm/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig.debug +0
-0
arch/arm/Kconfig.debug choice · line 286
Quoted 8 lines
arch/arm/Kconfig.debug +1
-1@@ -280,7 +280,7 @@ choice config DEBUG_HI3620_UART bool "Hisilicon HI3620 Debug UART" - depends on ARCH_HI3xxx + depends on ARCH_HI3620 select DEBUG_UART_PL01X help Say Y here if you want kernel low-level debugging support
While patches should normally be split up into per-subsystem changes, they also have to be done in an 'atomic' way:
applying just the first patch without the second one must not introduce a regression.
In this case, I'd suggest simply doing a larger patch for the global rename to collect 'Acked-by's and send that through the arm-soc tree.
If you get in a similar situation with more complex changes, you should come up with a way to do it independently. Here you would first have to introduce a CONFIG_ARCH_HI3620 symbol in one patch and make that always selected at the same time as CONFIG_ARCH_HI3xxx, then change all users of that symbol, and finally remove the original.
Arnd
RFC 1/7 Make Hi3620 explicit, remove wildcards
Quoted 29 lines · Arnd Bergmann
Quoted 9 lines · CEST Marty Plummer
arch/arm/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig.debug +0
-0arch/arm/Kconfig.debug choice · line 286
Quoted 8 lines
arch/arm/Kconfig.debug +1
-1@@ -280,7 +280,7 @@ choice config DEBUG_HI3620_UART bool "Hisilicon HI3620 Debug UART" - depends on ARCH_HI3xxx + depends on ARCH_HI3620 select DEBUG_UART_PL01X help Say Y here if you want kernel low-level debugging supportWhile patches should normally be split up into per-subsystem changes, they also have to be done in an 'atomic' way:
applying just the first patch without the second one must not introduce a regression.In this case, I'd suggest simply doing a larger patch for the global rename to collect 'Acked-by's and send that through the arm-soc tree.
Quoted 9 lines
If you get in a similar situation with more complex changes, you should come up with a way to do it independently. Here you would first have to introduce a
CONFIG_ARCH_HI3620symbol in one patch and make that always selected at the same time asCONFIG_ARCH_HI3xxx, then change all users of that symbol, and finally remove the original.Arnd
So, in this case it should be one single patch? Geeze this is hella complicated to just get a name changed XD
Arnd Bergmann
maintainerRFC 1/7 Make Hi3620 explicit, remove wildcards
Quoted 2 lines · CEST Marty Plummer
So, in this case it should be one single patch? Geeze this is hella complicated to just get a name changed
Yes and yes. Sometimes it's easier to leave an slightly misleading name than to change it. ;-)
If there is any relation between Hi3620 and Hi3520, we could also decide to use the "HI3xxx" name for both after all, and just change the Kconfig files like
config ARCH_HI3xxx
bool "Hisilicon Hi36xx family"
depends on ARCH_MULTI_V5 || ARCH_MULTI_V6 || ARCH_MULTI_V7 select CACHE_L2X0 if CPU_V7
select HAVE_ARM_SCU if SMP
...
config DEBUG_HI3520_UART
bool "Hisilicon HI3520 Debug UART"
depends on ARCH_HI3xxx
select DEBUG_UART_PL01X
help
Say Y here if you want kernel low-level debugging support
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
depends on ARCH_HI3xxx
select DEBUG_UART_PL01X
help
Say Y here if you want kernel low-level debugging support
Arnd