[PATCH v2] MIPS: Fix CONFIG_CMDLINE handling
Commit 8ce355cf2e38 ("MIPS: Setup boot_command_line before
plat_mem_setup") fixed a problem for systems which have
CONFIG_CMDLINE_BOOL=y & use a DT with a chosen node that has either no
bootargs property or an empty one. In this configuration
early_init_dt_scan_chosen() copies CONFIG_CMDLINE into
boot_command_line, but the MIPS code doesn't know this so it appends
CONFIG_CMDLINE (via builtin_cmdline) to boot_command_line again. The
result is that boot_command_line contains the arguments from
CONFIG_CMDLINE twice.
That commit took the approach of simply setting up boot_command_line
from the MIPS code before early_init_dt_scan_chosen() runs, causing it
not to copy CONFIG_CMDLINE to boot_command_line if a chosen node with no
bootargs property is found.
Unfortunately this is problematic for systems which do have a non-empty
bootargs property & CONFIG_CMDLINE_BOOL=y. There
early_init_dt_scan_chosen() will overwrite boot_command_line with the
arguments from DT, which means we lose those from CONFIG_CMDLINE
entirely. This breaks CONFIG_MIPS_CMDLINE_DTB_EXTEND. If we have
CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER or
CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND selected and the DT has a bootargs
property which we should ignore, it will instead be honoured breaking
those configurations too.
Fix this by reverting commit 8ce355cf2e38 ("MIPS: Setup
boot_command_line before plat_mem_setup") to restore the former
behaviour, and fixing the CONFIG_CMDLINE duplication issue by
initializing boot_command_line to a non-empty string that
early_init_dt_scan_chosen() will not overwrite with CONFIG_CMDLINE.
This is a little ugly, but cleanup in this area is on its way. In the
meantime this is at least easy to backport & contains the ugliness
within arch/mips/.
Signed-off-by: Paul Burton
Fixes: 8ce355cf2e38 ("MIPS: Setup boot_command_line before plat_mem_setup")
References: https://patchwork.linux-mips.org/patch/18804/
Cc: Frank Rowand
Cc: Jaedon Shin
Cc: Mathieu Malaterre
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: sta...@vger.kernel.org # v4.16+
---
This isn't pretty, but further cleanup is underway [1] and this fixes
the regression in an easily backportable manner without adding another
per-architecture function like v1.
[1] https://www.spinics.net/lists/kernel/msg2918275.html
Changes in v2:
- Drop the arch-specific function & just initialize boot_command_line
such that early_init_dt_scan_chosen() won't overwrite it with
CONFIG_CMDLINE.
v1: https://marc.info/?l=linux-mips=153634652318477=2
https://marc.info/?l=linux-mips=153634653718485=2
---
arch/mips/kernel/setup.c | 48 +++-
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index c71d1eb7da59..842f91ed 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -846,6 +846,34 @@ static void __init arch_mem_init(char **cmdline_p)
struct memblock_region *reg;
extern void plat_mem_setup(void);
+ /*
+* Initialize boot_command_line to an innocuous but non-empty string in
+* order to prevent early_init_dt_scan_chosen() from copying
+* CONFIG_CMDLINE into it without our knowledge. We handle
+* CONFIG_CMDLINE ourselves below & don't want to duplicate its
+* content because repeating arguments can be problematic.
+*/
+ strlcpy(boot_command_line, " ", COMMAND_LINE_SIZE);
+
+ /* call board setup routine */
+ plat_mem_setup();
+
+ /*
+* Make sure all kernel memory is in the maps. The "UP" and
+* "DOWN" are opposite for initdata since if it crosses over
+* into another memory section you don't want that to be
+* freed when the initdata is freed.
+*/
+ arch_mem_addpart(PFN_DOWN(__pa_symbol(&_text)) << PAGE_SHIFT,
+PFN_UP(__pa_symbol(&_edata)) << PAGE_SHIFT,
+BOOT_MEM_RAM);
+ arch_mem_addpart(PFN_UP(__pa_symbol(&__init_begin)) << PAGE_SHIFT,
+PFN_DOWN(__pa_symbol(&__init_end)) << PAGE_SHIFT,
+BOOT_MEM_INIT_RAM);
+
+ pr_info("Determined physical RAM map:\n");
+ print_memory_map();
+
#if defined(CONFIG_CMDLINE_BOOL) && defined(CONFIG_CMDLINE_OVERRIDE)
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
#else
@@ -873,26 +901,6 @@ static void __init arch_mem_init(char **cmdline_p)
}
#endif
#endif
-
- /* call board setup routine */
- plat_mem_setup();
-
- /*
-* Make sure all kernel memory is in the maps. The "UP" and
-* "DOWN" are opposite for initdata since if it crosses over
-* into another memory s
Re: [PATCH 7/8] mips: convert to generic builtin command line
Hi Maksym,
On Thu, Sep 27, 2018 at 07:56:57PM +0300, Maksym Kokhan wrote:
> -choice
> - prompt "Kernel command line type" if !CMDLINE_OVERRIDE
> - default MIPS_CMDLINE_FROM_DTB if USE_OF && !ATH79 && !MACH_INGENIC && \
> - !MIPS_MALTA && \
> - !CAVIUM_OCTEON_SOC
> - default MIPS_CMDLINE_FROM_BOOTLOADER
> -
> - config MIPS_CMDLINE_FROM_DTB
> - depends on USE_OF
> - bool "Dtb kernel arguments if available"
> -
> - config MIPS_CMDLINE_DTB_EXTEND
> - depends on USE_OF
> - bool "Extend dtb kernel arguments with bootloader arguments"
> -
> - config MIPS_CMDLINE_FROM_BOOTLOADER
> - bool "Bootloader kernel arguments if available"
> -
> - config MIPS_CMDLINE_BUILTIN_EXTEND
> - depends on CMDLINE_BOOL
> - bool "Extend builtin kernel arguments with bootloader arguments"
> -endchoice
>%
> -#define USE_PROM_CMDLINE IS_ENABLED(CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER)
> -#define USE_DTB_CMDLINE IS_ENABLED(CONFIG_MIPS_CMDLINE_FROM_DTB)
> -#define EXTEND_WITH_PROM IS_ENABLED(CONFIG_MIPS_CMDLINE_DTB_EXTEND)
> -#define BUILTIN_EXTEND_WITH_PROM \
> - IS_ENABLED(CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)
> -
> static void __init arch_mem_init(char **cmdline_p)
> {
> struct memblock_region *reg;
> extern void plat_mem_setup(void);
>
> -#if defined(CONFIG_CMDLINE_BOOL) && defined(CONFIG_CMDLINE_OVERRIDE)
> - strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> -#else
> - if ((USE_PROM_CMDLINE && arcs_cmdline[0]) ||
> - (USE_DTB_CMDLINE && !boot_command_line[0]))
> - strlcpy(boot_command_line, arcs_cmdline, COMMAND_LINE_SIZE);
> -
> - if (EXTEND_WITH_PROM && arcs_cmdline[0]) {
> - if (boot_command_line[0])
> - strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
> - strlcat(boot_command_line, arcs_cmdline, COMMAND_LINE_SIZE);
> - }
> -
> -#if defined(CONFIG_CMDLINE_BOOL)
> - if (builtin_cmdline[0]) {
> - if (boot_command_line[0])
> - strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
> - strlcat(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> - }
> -
> - if (BUILTIN_EXTEND_WITH_PROM && arcs_cmdline[0]) {
> - if (boot_command_line[0])
> - strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
> - strlcat(boot_command_line, arcs_cmdline, COMMAND_LINE_SIZE);
> - }
> -#endif
> -#endif
> -
> /* call board setup routine */
> plat_mem_setup();
>
> @@ -893,6 +856,8 @@ static void __init arch_mem_init(char **cmdline_p)
> pr_info("Determined physical RAM map:\n");
> print_memory_map();
>
> + cmdline_add_builtin(boot_command_line, arcs_cmdline, COMMAND_LINE_SIZE);
> +
> strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
>
> *cmdline_p = command_line;
I love the idea of simplifying this & sharing code with other
architectures, but unfortunately I believe the above will be problematic
for systems using arguments from device tree.
At the point you call cmdline_add_builtin we should expect that:
- boot_command_line contains arguments from the DT, if any, and
otherwise may contain CONFIG_CMDLINE copied there by
early_init_dt_scan_chosen().
- arcs_cmdline contains arguments from the bootloader, if any.
If I understand correctly you overwrite boot_command_line with the
concatenation of CONFIG_CMDLINE_PREPEND, arcs_cmdline &
CONFIG_CMDLINE_APPEND. This will clobber/lose the DT arguments.
I'd expect this to be reproducible under QEMU using its boston emulation
(ie. -M boston) and a kernel built for the generic platform that
includes boston support (eg. 64r6el_defconfig).
It also doesn't allow for the various Kconfig options which allow us to
ignore some of the sources of command line arguments, nor does it honor
the ordering that those existing options allow. In practice perhaps we
can cut down on some of this configurability anyway, but if we do that
it needs to be thought through & the commit message should describe the
changes in behaviour.
Thanks,
Paul
Re: [PATCH 7/8] mips: convert to generic builtin command line
Hi Maksym,
On Thu, Sep 27, 2018 at 07:56:57PM +0300, Maksym Kokhan wrote:
> -choice
> - prompt "Kernel command line type" if !CMDLINE_OVERRIDE
> - default MIPS_CMDLINE_FROM_DTB if USE_OF && !ATH79 && !MACH_INGENIC && \
> - !MIPS_MALTA && \
> - !CAVIUM_OCTEON_SOC
> - default MIPS_CMDLINE_FROM_BOOTLOADER
> -
> - config MIPS_CMDLINE_FROM_DTB
> - depends on USE_OF
> - bool "Dtb kernel arguments if available"
> -
> - config MIPS_CMDLINE_DTB_EXTEND
> - depends on USE_OF
> - bool "Extend dtb kernel arguments with bootloader arguments"
> -
> - config MIPS_CMDLINE_FROM_BOOTLOADER
> - bool "Bootloader kernel arguments if available"
> -
> - config MIPS_CMDLINE_BUILTIN_EXTEND
> - depends on CMDLINE_BOOL
> - bool "Extend builtin kernel arguments with bootloader arguments"
> -endchoice
>%
> -#define USE_PROM_CMDLINE IS_ENABLED(CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER)
> -#define USE_DTB_CMDLINE IS_ENABLED(CONFIG_MIPS_CMDLINE_FROM_DTB)
> -#define EXTEND_WITH_PROM IS_ENABLED(CONFIG_MIPS_CMDLINE_DTB_EXTEND)
> -#define BUILTIN_EXTEND_WITH_PROM \
> - IS_ENABLED(CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)
> -
> static void __init arch_mem_init(char **cmdline_p)
> {
> struct memblock_region *reg;
> extern void plat_mem_setup(void);
>
> -#if defined(CONFIG_CMDLINE_BOOL) && defined(CONFIG_CMDLINE_OVERRIDE)
> - strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> -#else
> - if ((USE_PROM_CMDLINE && arcs_cmdline[0]) ||
> - (USE_DTB_CMDLINE && !boot_command_line[0]))
> - strlcpy(boot_command_line, arcs_cmdline, COMMAND_LINE_SIZE);
> -
> - if (EXTEND_WITH_PROM && arcs_cmdline[0]) {
> - if (boot_command_line[0])
> - strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
> - strlcat(boot_command_line, arcs_cmdline, COMMAND_LINE_SIZE);
> - }
> -
> -#if defined(CONFIG_CMDLINE_BOOL)
> - if (builtin_cmdline[0]) {
> - if (boot_command_line[0])
> - strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
> - strlcat(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> - }
> -
> - if (BUILTIN_EXTEND_WITH_PROM && arcs_cmdline[0]) {
> - if (boot_command_line[0])
> - strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
> - strlcat(boot_command_line, arcs_cmdline, COMMAND_LINE_SIZE);
> - }
> -#endif
> -#endif
> -
> /* call board setup routine */
> plat_mem_setup();
>
> @@ -893,6 +856,8 @@ static void __init arch_mem_init(char **cmdline_p)
> pr_info("Determined physical RAM map:\n");
> print_memory_map();
>
> + cmdline_add_builtin(boot_command_line, arcs_cmdline, COMMAND_LINE_SIZE);
> +
> strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
>
> *cmdline_p = command_line;
I love the idea of simplifying this & sharing code with other
architectures, but unfortunately I believe the above will be problematic
for systems using arguments from device tree.
At the point you call cmdline_add_builtin we should expect that:
- boot_command_line contains arguments from the DT, if any, and
otherwise may contain CONFIG_CMDLINE copied there by
early_init_dt_scan_chosen().
- arcs_cmdline contains arguments from the bootloader, if any.
If I understand correctly you overwrite boot_command_line with the
concatenation of CONFIG_CMDLINE_PREPEND, arcs_cmdline &
CONFIG_CMDLINE_APPEND. This will clobber/lose the DT arguments.
I'd expect this to be reproducible under QEMU using its boston emulation
(ie. -M boston) and a kernel built for the generic platform that
includes boston support (eg. 64r6el_defconfig).
It also doesn't allow for the various Kconfig options which allow us to
ignore some of the sources of command line arguments, nor does it honor
the ordering that those existing options allow. In practice perhaps we
can cut down on some of this configurability anyway, but if we do that
it needs to be thought through & the commit message should describe the
changes in behaviour.
Thanks,
Paul
Re: [PATCH v2 1/1] MIPS: Add Kconfig variable for CPUs with unaligned load/store instructions
Hi Yasha, On Wed, Sep 26, 2018 at 02:16:15PM +0300, Yasha Cherikovsky wrote: > MIPSR6 CPUs do not support unaligned load/store instructions > (LWL, LWR, SWL, SWR and LDL, LDR, SDL, SDR for 64bit). > > Currently the MIPS tree has some special cases to avoid these > instructions, and the code is testing for !CONFIG_CPU_MIPSR6. > > This patch declares a new Kconfig variable: > CONFIG_CPU_HAS_LOAD_STORE_LR. > This variable indicates that the CPU supports these instructions. > > Then, the patch does the following: > - Carefully selects this option on all CPUs except MIPSR6. > - Switches all the special cases to test for the new variable, > and inverts the logic: > '#ifndef CONFIG_CPU_MIPSR6' turns into > '#ifdef CONFIG_CPU_HAS_LOAD_STORE_LR' > and vice-versa. > > Also, when this variable is NOT selected (e.g. MIPSR6), > CONFIG_GENERIC_CSUM will default to 'y', to compile generic > C checksum code (instead of special assembly code that uses the > unsupported instructions). > > This commit should not affect any existing CPU, and is required > for future Lexra CPU support, that misses these instructions too. > > Signed-off-by: Yasha Cherikovsky > Cc: Ralf Baechle > Cc: Paul Burton > Cc: James Hogan > Cc: linux-m...@linux-mips.org > Cc: linux-kernel@vger.kernel.org > --- > arch/mips/Kconfig| 35 +-- > arch/mips/kernel/unaligned.c | 47 ++-- > arch/mips/lib/memcpy.S | 10 > arch/mips/lib/memset.S | 12 - > 4 files changed, 67 insertions(+), 37 deletions(-) Thanks - applied to mips-next for 4.20. Paul
Re: [PATCH v2 1/1] MIPS: Add Kconfig variable for CPUs with unaligned load/store instructions
Hi Yasha, On Wed, Sep 26, 2018 at 02:16:15PM +0300, Yasha Cherikovsky wrote: > MIPSR6 CPUs do not support unaligned load/store instructions > (LWL, LWR, SWL, SWR and LDL, LDR, SDL, SDR for 64bit). > > Currently the MIPS tree has some special cases to avoid these > instructions, and the code is testing for !CONFIG_CPU_MIPSR6. > > This patch declares a new Kconfig variable: > CONFIG_CPU_HAS_LOAD_STORE_LR. > This variable indicates that the CPU supports these instructions. > > Then, the patch does the following: > - Carefully selects this option on all CPUs except MIPSR6. > - Switches all the special cases to test for the new variable, > and inverts the logic: > '#ifndef CONFIG_CPU_MIPSR6' turns into > '#ifdef CONFIG_CPU_HAS_LOAD_STORE_LR' > and vice-versa. > > Also, when this variable is NOT selected (e.g. MIPSR6), > CONFIG_GENERIC_CSUM will default to 'y', to compile generic > C checksum code (instead of special assembly code that uses the > unsupported instructions). > > This commit should not affect any existing CPU, and is required > for future Lexra CPU support, that misses these instructions too. > > Signed-off-by: Yasha Cherikovsky > Cc: Ralf Baechle > Cc: Paul Burton > Cc: James Hogan > Cc: linux-m...@linux-mips.org > Cc: linux-kernel@vger.kernel.org > --- > arch/mips/Kconfig| 35 +-- > arch/mips/kernel/unaligned.c | 47 ++-- > arch/mips/lib/memcpy.S | 10 > arch/mips/lib/memset.S | 12 - > 4 files changed, 67 insertions(+), 37 deletions(-) Thanks - applied to mips-next for 4.20. Paul
Re: [PATCH v5 06/12] MIPS: BMIPS: add dma remap for BrcmSTB PCIe
Hi Jim,
On Wed, Sep 19, 2018 at 10:32:01AM -0400, Jim Quinlan wrote:
> The design of the Broadcom PCIe RC controller requires us to remap its
> DMA addresses for inbound traffic. We do this by modifying the
> definitions of __phys_to_dma() and __dma_to_phys().
>
> In arch/mips/bmips/dma.c, these functions are already in use to remap
> DMA addresses for the 338x SOC chips. We leave this code alone -- and
> give its mapping priority -- but if it is not in use, the PCIe DMA
> mapping is in effect.
>
> One might think that the two DMA remapping systems of dma.c could be
> combined, but they cannot: one governs only DMA addresses for the PCIe
> controller of BrcmSTB ARM/ARM64/MIPs chips, while the other governs
> the PCIe controller *and* other peripherals for only MIPs 338x
> chips.
>
> Signed-off-by: Jim Quinlan
> ---
> arch/mips/bmips/dma.c | 9 +
> 1 file changed, 9 insertions(+)
Please copy me/linux-mips on the whole series next time - I seem to have
only received patches 6, 8 & 9 which means I have no idea whether they
have dependencies & if so whether those dependencies have been accepted
or rejected. I also have no clue whether these patches make sense to
take through the MIPS tree or if it would make more sense for someone
else to take them with acks.
> diff --git a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
> index 3d13c77..292994f 100644
> --- a/arch/mips/bmips/dma.c
> +++ b/arch/mips/bmips/dma.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * BCM338x has configurable address translation windows which allow the
> @@ -44,6 +45,10 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t
> pa)
> {
> struct bmips_dma_range *r;
>
> +#ifdef CONFIG_PCIE_BRCMSTB
> + if (!bmips_dma_ranges)
> + return brcm_phys_to_dma(dev, pa);
> +#endif
> for (r = bmips_dma_ranges; r && r->size; r++) {
> if (pa >= r->child_addr &&
> pa < (r->child_addr + r->size))
I can't tell because I presume brcm_phys_to_dma() is added in one of
those patches I wasn't copied on, but perhaps you could avoid the #ifdef
by just returning brcm_phys_to_dma(dev, pa) after the loop?
> @@ -56,6 +61,10 @@ phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t
> dma_addr)
> {
> struct bmips_dma_range *r;
>
> +#ifdef CONFIG_PCIE_BRCMSTB
> + if (!bmips_dma_ranges)
> + return (unsigned long)brcm_dma_to_phys(dev, dma_addr);
> +#endif
> for (r = bmips_dma_ranges; r && r->size; r++) {
> if (dma_addr >= r->parent_addr &&
> dma_addr < (r->parent_addr + r->size))
And similar here.
Thanks,
Paul
Re: [PATCH v5 06/12] MIPS: BMIPS: add dma remap for BrcmSTB PCIe
Hi Jim,
On Wed, Sep 19, 2018 at 10:32:01AM -0400, Jim Quinlan wrote:
> The design of the Broadcom PCIe RC controller requires us to remap its
> DMA addresses for inbound traffic. We do this by modifying the
> definitions of __phys_to_dma() and __dma_to_phys().
>
> In arch/mips/bmips/dma.c, these functions are already in use to remap
> DMA addresses for the 338x SOC chips. We leave this code alone -- and
> give its mapping priority -- but if it is not in use, the PCIe DMA
> mapping is in effect.
>
> One might think that the two DMA remapping systems of dma.c could be
> combined, but they cannot: one governs only DMA addresses for the PCIe
> controller of BrcmSTB ARM/ARM64/MIPs chips, while the other governs
> the PCIe controller *and* other peripherals for only MIPs 338x
> chips.
>
> Signed-off-by: Jim Quinlan
> ---
> arch/mips/bmips/dma.c | 9 +
> 1 file changed, 9 insertions(+)
Please copy me/linux-mips on the whole series next time - I seem to have
only received patches 6, 8 & 9 which means I have no idea whether they
have dependencies & if so whether those dependencies have been accepted
or rejected. I also have no clue whether these patches make sense to
take through the MIPS tree or if it would make more sense for someone
else to take them with acks.
> diff --git a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
> index 3d13c77..292994f 100644
> --- a/arch/mips/bmips/dma.c
> +++ b/arch/mips/bmips/dma.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * BCM338x has configurable address translation windows which allow the
> @@ -44,6 +45,10 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t
> pa)
> {
> struct bmips_dma_range *r;
>
> +#ifdef CONFIG_PCIE_BRCMSTB
> + if (!bmips_dma_ranges)
> + return brcm_phys_to_dma(dev, pa);
> +#endif
> for (r = bmips_dma_ranges; r && r->size; r++) {
> if (pa >= r->child_addr &&
> pa < (r->child_addr + r->size))
I can't tell because I presume brcm_phys_to_dma() is added in one of
those patches I wasn't copied on, but perhaps you could avoid the #ifdef
by just returning brcm_phys_to_dma(dev, pa) after the loop?
> @@ -56,6 +61,10 @@ phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t
> dma_addr)
> {
> struct bmips_dma_range *r;
>
> +#ifdef CONFIG_PCIE_BRCMSTB
> + if (!bmips_dma_ranges)
> + return (unsigned long)brcm_dma_to_phys(dev, dma_addr);
> +#endif
> for (r = bmips_dma_ranges; r && r->size; r++) {
> if (dma_addr >= r->parent_addr &&
> dma_addr < (r->parent_addr + r->size))
And similar here.
Thanks,
Paul
Re: [PATCH 0/4] MIPS: Simplify ELF appended dtb handling
Hi Yasha, On Tue, Sep 25, 2018 at 09:08:21PM +0300, Yasha Cherikovsky wrote: > Hi, > > This patch series simplifies and cleans up the handling of > CONFIG_MIPS_ELF_APPENDED_DTB in the MIPS tree. > > Specifically, it makes sure that the dtb appears in 'fw_passed_dtb' > also under CONFIG_MIPS_ELF_APPENDED_DTB=y. > > This allows to remove special platform code that handled the ELF > appended dtb case, and replace it with the generic appended dtb > case (fw_passed_dtb). > > There's also a bonus: platforms that already handle 'fw_passed_dtb', > gain now automatic support for detecting a DT blob under > CONFIG_MIPS_ELF_APPENDED_DTB=y. Thanks - applied to mips-next for 4.20. Paul
Re: [PATCH 0/4] MIPS: Simplify ELF appended dtb handling
Hi Yasha, On Tue, Sep 25, 2018 at 09:08:21PM +0300, Yasha Cherikovsky wrote: > Hi, > > This patch series simplifies and cleans up the handling of > CONFIG_MIPS_ELF_APPENDED_DTB in the MIPS tree. > > Specifically, it makes sure that the dtb appears in 'fw_passed_dtb' > also under CONFIG_MIPS_ELF_APPENDED_DTB=y. > > This allows to remove special platform code that handled the ELF > appended dtb case, and replace it with the generic appended dtb > case (fw_passed_dtb). > > There's also a bonus: platforms that already handle 'fw_passed_dtb', > gain now automatic support for detecting a DT blob under > CONFIG_MIPS_ELF_APPENDED_DTB=y. Thanks - applied to mips-next for 4.20. Paul
Re: [PATCH 1/1] MIPS: Add new Kconfig variable to avoid unaligned access instructions
Hi Yasha,
On Tue, Sep 25, 2018 at 10:30:52PM +0300, Yasha Cherikovsky wrote:
> On Tue, 2018-09-25 at 17:45 +0000, Paul Burton wrote:
> > How about we:
> >
> > - Add a Kconfig option CONFIG_CPU_SUPPORTS_LOAD_STORE_LR, and
> > select
> > it for all existing pre-r6 targets (probably from CONFIG_CPU_*).
> >
> > - Change CONFIG_GENERIC_CSUM to default y if
> > !CONFIG_CPU_SUPPORTS_LOAD_STORE_LR, and drop the selects of it.
> >
> > That would avoid the double-negative ("if we don't not support this")
> > that the #ifndef's currently represent. It would also mean any future
> > architecture/ISA targets beyond MIPSr6 automatically avoid the
> > instructions.
>
> Thanks for your feedback, I'll start preparing v2.
>
> Looking in arch/mips/Kconfig, some CPU options start
> with CPU_SUPPORTS_ and some with CPU_HAS_.
> Which perfix should we use here?
That's a good question :)
To be honest I don't think either of them is perfect, since what we're
really describing is what's supported by the ISA that the kernel build
is targeting - and in theory the CPU we actually run on could support
extra things.
But considering it I think CPU_HAS_ is probably the best choice for
this, since it's already used similarly to indicate support for pref &
sync instructions.
Thanks,
Paul
Re: [PATCH 1/1] MIPS: Add new Kconfig variable to avoid unaligned access instructions
Hi Yasha,
On Tue, Sep 25, 2018 at 10:30:52PM +0300, Yasha Cherikovsky wrote:
> On Tue, 2018-09-25 at 17:45 +0000, Paul Burton wrote:
> > How about we:
> >
> > - Add a Kconfig option CONFIG_CPU_SUPPORTS_LOAD_STORE_LR, and
> > select
> > it for all existing pre-r6 targets (probably from CONFIG_CPU_*).
> >
> > - Change CONFIG_GENERIC_CSUM to default y if
> > !CONFIG_CPU_SUPPORTS_LOAD_STORE_LR, and drop the selects of it.
> >
> > That would avoid the double-negative ("if we don't not support this")
> > that the #ifndef's currently represent. It would also mean any future
> > architecture/ISA targets beyond MIPSr6 automatically avoid the
> > instructions.
>
> Thanks for your feedback, I'll start preparing v2.
>
> Looking in arch/mips/Kconfig, some CPU options start
> with CPU_SUPPORTS_ and some with CPU_HAS_.
> Which perfix should we use here?
That's a good question :)
To be honest I don't think either of them is perfect, since what we're
really describing is what's supported by the ISA that the kernel build
is targeting - and in theory the CPU we actually run on could support
extra things.
But considering it I think CPU_HAS_ is probably the best choice for
this, since it's already used similarly to indicate support for pref &
sync instructions.
Thanks,
Paul
Re: [PATCH 1/1] MIPS: Add new Kconfig variable to avoid unaligned access instructions
Hi Yasha,
On Thu, Sep 20, 2018 at 08:03:06PM +0300, Yasha Cherikovsky wrote:
> MIPSR6 doesn't support unaligned access instructions (lwl, lwr, swl, swr).
> The MIPS tree has some special cases to avoid these instructions,
> and currently the code is testing for CONFIG_CPU_MIPSR6.
>
> Declare a new Kconfig variable: CONFIG_CPU_HAS_NO_UNALIGNED_LOAD_STORE,
> and make CONFIG_CPU_MIPSR6 select it.
> And switch all the special cases to test for the new variable.
>
> Also, the new variable selects CONFIG_GENERIC_CSUM, to use
> generic C checksum code (to avoid special assembly code that uses
> the unsupported instructions).
Thanks for your patch :)
I think it would be cleaner to invert this logic & instead have the
Kconfig entry indicate when kernel's build target *does* support the
[ls]w[lr] instructions.
It would be good for the name to be clear that these instructions are
what it's about too - "unaligned load store" is a little too vague for
my liking. For example one could easily misconstrue it to mean something
akin to the inverse of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, whereas
in the MIPSr6 case many CPUs actually handle unaligned accesses in
hardware when using the regular load/store instructions. They don't have
the [ls]w[lr] instructions, but they don't need them because they handle
unaligned accesses more naturally without needing us to be explicit
about them.
How about we:
- Add a Kconfig option CONFIG_CPU_SUPPORTS_LOAD_STORE_LR, and select
it for all existing pre-r6 targets (probably from CONFIG_CPU_*).
- Change CONFIG_GENERIC_CSUM to default y if
!CONFIG_CPU_SUPPORTS_LOAD_STORE_LR, and drop the selects of it.
That would avoid the double-negative ("if we don't not support this")
that the #ifndef's currently represent. It would also mean any future
architecture/ISA targets beyond MIPSr6 automatically avoid the
instructions.
Thanks,
Paul
Re: [PATCH 1/1] MIPS: Add new Kconfig variable to avoid unaligned access instructions
Hi Yasha,
On Thu, Sep 20, 2018 at 08:03:06PM +0300, Yasha Cherikovsky wrote:
> MIPSR6 doesn't support unaligned access instructions (lwl, lwr, swl, swr).
> The MIPS tree has some special cases to avoid these instructions,
> and currently the code is testing for CONFIG_CPU_MIPSR6.
>
> Declare a new Kconfig variable: CONFIG_CPU_HAS_NO_UNALIGNED_LOAD_STORE,
> and make CONFIG_CPU_MIPSR6 select it.
> And switch all the special cases to test for the new variable.
>
> Also, the new variable selects CONFIG_GENERIC_CSUM, to use
> generic C checksum code (to avoid special assembly code that uses
> the unsupported instructions).
Thanks for your patch :)
I think it would be cleaner to invert this logic & instead have the
Kconfig entry indicate when kernel's build target *does* support the
[ls]w[lr] instructions.
It would be good for the name to be clear that these instructions are
what it's about too - "unaligned load store" is a little too vague for
my liking. For example one could easily misconstrue it to mean something
akin to the inverse of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, whereas
in the MIPSr6 case many CPUs actually handle unaligned accesses in
hardware when using the regular load/store instructions. They don't have
the [ls]w[lr] instructions, but they don't need them because they handle
unaligned accesses more naturally without needing us to be explicit
about them.
How about we:
- Add a Kconfig option CONFIG_CPU_SUPPORTS_LOAD_STORE_LR, and select
it for all existing pre-r6 targets (probably from CONFIG_CPU_*).
- Change CONFIG_GENERIC_CSUM to default y if
!CONFIG_CPU_SUPPORTS_LOAD_STORE_LR, and drop the selects of it.
That would avoid the double-negative ("if we don't not support this")
that the #ifndef's currently represent. It would also mean any future
architecture/ISA targets beyond MIPSr6 automatically avoid the
instructions.
Thanks,
Paul
Re: [PATCH v2] mips: switch to NO_BOOTMEM
Hi Mike, On Mon, Sep 10, 2018 at 12:23:18PM +0300, Mike Rapoport wrote: > MIPS already has memblock support and all the memory is already registered > with it. > > This patch replaces bootmem memory reservations with memblock ones and > removes the bootmem initialization. > > Since memblock allocates memory in top-down mode, we ensure that memblock > limit is max_low_pfn to prevent allocations from the high memory. > > To have the exceptions base in the lower 512M of the physical memory, its > allocation in arch/mips/kernel/traps.c::traps_init() is using bottom-up > mode. > > Signed-off-by: Mike Rapoport > --- > v2: > * set memblock limit to max_low_pfn to avoid allocation attempts from high > memory > * use boottom-up mode for allocation of the exceptions base > > Build tested with *_defconfig. > Boot tested with qemu-system-mips64el for 32r6el, 64r6el and fuloong2e > defconfigs. > Boot tested with qemu-system-mipsel for malta defconfig. > > arch/mips/Kconfig | 1 + > arch/mips/kernel/setup.c | 99 > -- > arch/mips/kernel/traps.c | 3 ++ > arch/mips/loongson64/loongson-3/numa.c | 34 ++-- > arch/mips/sgi-ip27/ip27-memory.c | 11 ++-- > 5 files changed, 46 insertions(+), 102 deletions(-) Thanks - applied to mips-next for 4.20. Apologies for the delay, my son decided to be born a few weeks early & scupper my plans :) Paul
Re: [PATCH v2] mips: switch to NO_BOOTMEM
Hi Mike, On Mon, Sep 10, 2018 at 12:23:18PM +0300, Mike Rapoport wrote: > MIPS already has memblock support and all the memory is already registered > with it. > > This patch replaces bootmem memory reservations with memblock ones and > removes the bootmem initialization. > > Since memblock allocates memory in top-down mode, we ensure that memblock > limit is max_low_pfn to prevent allocations from the high memory. > > To have the exceptions base in the lower 512M of the physical memory, its > allocation in arch/mips/kernel/traps.c::traps_init() is using bottom-up > mode. > > Signed-off-by: Mike Rapoport > --- > v2: > * set memblock limit to max_low_pfn to avoid allocation attempts from high > memory > * use boottom-up mode for allocation of the exceptions base > > Build tested with *_defconfig. > Boot tested with qemu-system-mips64el for 32r6el, 64r6el and fuloong2e > defconfigs. > Boot tested with qemu-system-mipsel for malta defconfig. > > arch/mips/Kconfig | 1 + > arch/mips/kernel/setup.c | 99 > -- > arch/mips/kernel/traps.c | 3 ++ > arch/mips/loongson64/loongson-3/numa.c | 34 ++-- > arch/mips/sgi-ip27/ip27-memory.c | 11 ++-- > 5 files changed, 46 insertions(+), 102 deletions(-) Thanks - applied to mips-next for 4.20. Apologies for the delay, my son decided to be born a few weeks early & scupper my plans :) Paul
Re: [PATCH 2/2] MIPS: Fix CONFIG_CMDLINE handling
Hi Matthieu,
On Mon, Sep 10, 2018 at 02:09:21PM +0200, Mathieu Malaterre wrote:
> On Fri, Sep 7, 2018 at 8:55 PM Paul Burton wrote:
> > Commit 8ce355cf2e38 ("MIPS: Setup boot_command_line before
> > plat_mem_setup") fixed a problem for systems which have
> > CONFIG_CMDLINE_BOOL=y & use a DT with a chosen node that has either no
> > bootargs property or an empty one. In this configuration
> > early_init_dt_scan_chosen() copies CONFIG_CMDLINE into
> > boot_command_line, but the MIPS code doesn't know this so it appends
> > CONFIG_CMDLINE (via builtin_cmdline) to boot_command_line again. The
> > result is that boot_command_line contains the arguments from
> > CONFIG_CMDLINE twice.
> >
> > That commit took the approach of simply setting up boot_command_line
> > from the MIPS code before early_init_dt_scan_chosen() runs, causing it
> > not to copy CONFIG_CMDLINE to boot_command_line if a chosen node with no
> > bootargs property is found.
> >
> > Unfortunately this is problematic for systems which do have a non-empty
> > bootargs property & CONFIG_CMDLINE_BOOL=y. There
> > early_init_dt_scan_chosen() will overwrite boot_command_line with the
> > arguments from DT, which means we lose those from CONFIG_CMDLINE
> > entirely. This breaks CONFIG_MIPS_CMDLINE_DTB_EXTEND. If we have
> > CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER or
> > CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND selected and the DT has a bootargs
> > property which we should ignore, it will instead be honoured breaking
> > those configurations too.
> >
> > Fix this by reverting commit 8ce355cf2e38 ("MIPS: Setup
> > boot_command_line before plat_mem_setup") to restore the former
> > behaviour, and fixing the CONFIG_CMDLINE duplication issue by instead
> > providing a no-op implementation of early_init_dt_fixup_cmdline_arch()
> > to prevent early_init_dt_scan_chosen() from using CONFIG_CMDLINE.
>
> Sorry I cannot test this patch ATM. I've simply CCed Paul C. just in case.
Thanks - for the record I did test on a Ci20, though I was booting using
my ci20-usb-boot tool which doesn't currently provide a command line to
the kernel. CONFIG_CMDLINE didn't get duplicated though.
I'll get back to a v2 for this & hopefully get it fixed up for 4.19, but
it might take a little while because my son was just born on Saturday :)
Thanks,
Paul
Re: [PATCH 2/2] MIPS: Fix CONFIG_CMDLINE handling
Hi Matthieu,
On Mon, Sep 10, 2018 at 02:09:21PM +0200, Mathieu Malaterre wrote:
> On Fri, Sep 7, 2018 at 8:55 PM Paul Burton wrote:
> > Commit 8ce355cf2e38 ("MIPS: Setup boot_command_line before
> > plat_mem_setup") fixed a problem for systems which have
> > CONFIG_CMDLINE_BOOL=y & use a DT with a chosen node that has either no
> > bootargs property or an empty one. In this configuration
> > early_init_dt_scan_chosen() copies CONFIG_CMDLINE into
> > boot_command_line, but the MIPS code doesn't know this so it appends
> > CONFIG_CMDLINE (via builtin_cmdline) to boot_command_line again. The
> > result is that boot_command_line contains the arguments from
> > CONFIG_CMDLINE twice.
> >
> > That commit took the approach of simply setting up boot_command_line
> > from the MIPS code before early_init_dt_scan_chosen() runs, causing it
> > not to copy CONFIG_CMDLINE to boot_command_line if a chosen node with no
> > bootargs property is found.
> >
> > Unfortunately this is problematic for systems which do have a non-empty
> > bootargs property & CONFIG_CMDLINE_BOOL=y. There
> > early_init_dt_scan_chosen() will overwrite boot_command_line with the
> > arguments from DT, which means we lose those from CONFIG_CMDLINE
> > entirely. This breaks CONFIG_MIPS_CMDLINE_DTB_EXTEND. If we have
> > CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER or
> > CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND selected and the DT has a bootargs
> > property which we should ignore, it will instead be honoured breaking
> > those configurations too.
> >
> > Fix this by reverting commit 8ce355cf2e38 ("MIPS: Setup
> > boot_command_line before plat_mem_setup") to restore the former
> > behaviour, and fixing the CONFIG_CMDLINE duplication issue by instead
> > providing a no-op implementation of early_init_dt_fixup_cmdline_arch()
> > to prevent early_init_dt_scan_chosen() from using CONFIG_CMDLINE.
>
> Sorry I cannot test this patch ATM. I've simply CCed Paul C. just in case.
Thanks - for the record I did test on a Ci20, though I was booting using
my ci20-usb-boot tool which doesn't currently provide a command line to
the kernel. CONFIG_CMDLINE didn't get duplicated though.
I'll get back to a v2 for this & hopefully get it fixed up for 4.19, but
it might take a little while because my son was just born on Saturday :)
Thanks,
Paul
Re: [PATCH] mips: bug: add unlikely() to BUG_ON()
Hi Igor, On Fri, Sep 07, 2018 at 09:03:02PM +0300, Igor Stoppa wrote: > diff --git a/arch/mips/include/asm/bug.h b/arch/mips/include/asm/bug.h > index 745dc160a069..02101b54aec2 100644 > --- a/arch/mips/include/asm/bug.h > +++ b/arch/mips/include/asm/bug.h > @@ -31,7 +31,7 @@ static inline void __BUG_ON(unsigned long condition) >: : "r" (condition), "i" (BRK_BUG)); > } > > -#define BUG_ON(C) __BUG_ON((unsigned long)(C)) > +#define BUG_ON(C) __BUG_ON(unlikely((unsigned long)(C))) > > #define HAVE_ARCH_BUG_ON > I'm not sure this will actually do anything. __BUG_ON() doesn't use the value of its condition argument for regular control flow unless it's compile-time constant anyway, in which case unlikely() should be redundant because the compiler knows the value already. If the condition isn't compile-time constant then we just emit a tne (trap-if-not-equal) instruction using inline asm. That will generate an exception if the value is non-zero at runtime. I don't see how adding unlikely() is going to help the compiler do anything differently with that. Thanks, Paul
Re: [PATCH] mips: bug: add unlikely() to BUG_ON()
Hi Igor, On Fri, Sep 07, 2018 at 09:03:02PM +0300, Igor Stoppa wrote: > diff --git a/arch/mips/include/asm/bug.h b/arch/mips/include/asm/bug.h > index 745dc160a069..02101b54aec2 100644 > --- a/arch/mips/include/asm/bug.h > +++ b/arch/mips/include/asm/bug.h > @@ -31,7 +31,7 @@ static inline void __BUG_ON(unsigned long condition) >: : "r" (condition), "i" (BRK_BUG)); > } > > -#define BUG_ON(C) __BUG_ON((unsigned long)(C)) > +#define BUG_ON(C) __BUG_ON(unlikely((unsigned long)(C))) > > #define HAVE_ARCH_BUG_ON > I'm not sure this will actually do anything. __BUG_ON() doesn't use the value of its condition argument for regular control flow unless it's compile-time constant anyway, in which case unlikely() should be redundant because the compiler knows the value already. If the condition isn't compile-time constant then we just emit a tne (trap-if-not-equal) instruction using inline asm. That will generate an exception if the value is non-zero at runtime. I don't see how adding unlikely() is going to help the compiler do anything differently with that. Thanks, Paul
Re: [PATCH 1/2] of/fdt: Allow architectures to override CONFIG_CMDLINE logic
Hi Rob, On Fri, Sep 07, 2018 at 03:29:03PM -0500, Rob Herring wrote: > On Fri, Sep 7, 2018 at 1:55 PM Paul Burton wrote: > > The CONFIG_CMDLINE-related logic in early_init_dt_scan_chosen() falls > > back to copying CONFIG_CMDLINE into boot_command_line/data if the DT has > > a /chosen node but that node has no bootargs property or a bootargs > > property of length zero. > > The Risc-V guys found a similar issue if chosen is missing[1]. I > started a patch[2] to address that, but then looking at the different > arches wasn't sure if I'd break something. I don't recall for sure, > but it may have been MIPS that worried me. > > > This is problematic for the MIPS architecture because we support > > concatenating arguments from either the DT or the bootloader with those > > from CONFIG_CMDLINE, but the behaviour of early_init_dt_scan_chosen() > > gives us no way of knowing whether boot_command_line contains arguments > > from DT or already contains CONFIG_CMDLINE. This can lead to us > > concatenating CONFIG_CMDLINE with itself, duplicating command line > > arguments which can be problematic (eg. for earlycon which will attempt > > to register the same console twice & warn about it). > > If CONFIG_CMDLINE_EXTEND is set, you know it contains CONFIG_CMDLINE. > But I guess part of the problem is MIPS using its own kconfig options. Yes, that's part of the problem but there's more: - We can also take arguments from the bootloader/prom, so it's not just DT or CONFIG_CMDLINE as taken into account by early_init_dt_scan_chosen(). MIPS has options to concatenate various combinations of DT, bootloader & CONFIG_CMDLINE arguments & there's no mapping to move all of them to just CONFIG_CMDLINE_EXTEND & CONFIG_CMDLINE_OVERRIDE. - Some MIPS systems don't use DT, so don't run early_init_dt_scan_chosen() at all. Thus the architecture code still needs to deal with the bootloader/prom & CONFIG_CMDLINE cases anyway. In a perfect world we'd migrate all systems to use DT but in this world I don't see that happening until we kill off support for some of the older systems, which always seems contentious. Even then there'd be a lot of work for some of the remaining systems. I guess we could enable DT for these systems & only use it for the command line, it just feels like overkill. > > Move the CONFIG_CMDLINE-related logic to a weak function that > > architectures can provide their own version of, such that we continue to > > use the existing logic for architectures where it's suitable but also > > allow MIPS to override this behaviour such that the architecture code > > knows when CONFIG_CMDLINE is used. > > More arch specific functions is not what I want. Really, all the > cmdline manipulating logic doesn't belong in DT code, but it shouldn't > be in the arch specific code either IMO. Really it should be some > common kernel function which calls into the DT code to retrieve the DT > bootargs and that's it. Then you can skip calling that kernel function > if you really need non-standard handling. That would make sense. > Perhaps you should consider filling DT bootargs with the cmdline from > bootloader. IOW, make the legacy case look like the non-legacy case > early, and then the kernel doesn't have to deal with both cases later > on. That could work, but would force us to use DT universally & is a larger change than this, which I was hoping to get in 4.19 to fix the regression described in patch 2 that happened back in 4.16. But if you're unhappy with this perhaps we just have to live with it a little longer... An alternative workaround to this that would contain the regression fix within arch/mips/ would be to initialize boot_command_line to a single space character prior to early_init_dt_scan_chosen(), which would prevent early_init_dt_scan_chosen() from copying CONFIG_CMDLINE there. That smells much more like a hack to me than this patch though, so I'd rather not. Thanks, Paul
Re: [PATCH 1/2] of/fdt: Allow architectures to override CONFIG_CMDLINE logic
Hi Rob, On Fri, Sep 07, 2018 at 03:29:03PM -0500, Rob Herring wrote: > On Fri, Sep 7, 2018 at 1:55 PM Paul Burton wrote: > > The CONFIG_CMDLINE-related logic in early_init_dt_scan_chosen() falls > > back to copying CONFIG_CMDLINE into boot_command_line/data if the DT has > > a /chosen node but that node has no bootargs property or a bootargs > > property of length zero. > > The Risc-V guys found a similar issue if chosen is missing[1]. I > started a patch[2] to address that, but then looking at the different > arches wasn't sure if I'd break something. I don't recall for sure, > but it may have been MIPS that worried me. > > > This is problematic for the MIPS architecture because we support > > concatenating arguments from either the DT or the bootloader with those > > from CONFIG_CMDLINE, but the behaviour of early_init_dt_scan_chosen() > > gives us no way of knowing whether boot_command_line contains arguments > > from DT or already contains CONFIG_CMDLINE. This can lead to us > > concatenating CONFIG_CMDLINE with itself, duplicating command line > > arguments which can be problematic (eg. for earlycon which will attempt > > to register the same console twice & warn about it). > > If CONFIG_CMDLINE_EXTEND is set, you know it contains CONFIG_CMDLINE. > But I guess part of the problem is MIPS using its own kconfig options. Yes, that's part of the problem but there's more: - We can also take arguments from the bootloader/prom, so it's not just DT or CONFIG_CMDLINE as taken into account by early_init_dt_scan_chosen(). MIPS has options to concatenate various combinations of DT, bootloader & CONFIG_CMDLINE arguments & there's no mapping to move all of them to just CONFIG_CMDLINE_EXTEND & CONFIG_CMDLINE_OVERRIDE. - Some MIPS systems don't use DT, so don't run early_init_dt_scan_chosen() at all. Thus the architecture code still needs to deal with the bootloader/prom & CONFIG_CMDLINE cases anyway. In a perfect world we'd migrate all systems to use DT but in this world I don't see that happening until we kill off support for some of the older systems, which always seems contentious. Even then there'd be a lot of work for some of the remaining systems. I guess we could enable DT for these systems & only use it for the command line, it just feels like overkill. > > Move the CONFIG_CMDLINE-related logic to a weak function that > > architectures can provide their own version of, such that we continue to > > use the existing logic for architectures where it's suitable but also > > allow MIPS to override this behaviour such that the architecture code > > knows when CONFIG_CMDLINE is used. > > More arch specific functions is not what I want. Really, all the > cmdline manipulating logic doesn't belong in DT code, but it shouldn't > be in the arch specific code either IMO. Really it should be some > common kernel function which calls into the DT code to retrieve the DT > bootargs and that's it. Then you can skip calling that kernel function > if you really need non-standard handling. That would make sense. > Perhaps you should consider filling DT bootargs with the cmdline from > bootloader. IOW, make the legacy case look like the non-legacy case > early, and then the kernel doesn't have to deal with both cases later > on. That could work, but would force us to use DT universally & is a larger change than this, which I was hoping to get in 4.19 to fix the regression described in patch 2 that happened back in 4.16. But if you're unhappy with this perhaps we just have to live with it a little longer... An alternative workaround to this that would contain the regression fix within arch/mips/ would be to initialize boot_command_line to a single space character prior to early_init_dt_scan_chosen(), which would prevent early_init_dt_scan_chosen() from copying CONFIG_CMDLINE there. That smells much more like a hack to me than this patch though, so I'd rather not. Thanks, Paul
[PATCH 1/2] of/fdt: Allow architectures to override CONFIG_CMDLINE logic
The CONFIG_CMDLINE-related logic in early_init_dt_scan_chosen() falls
back to copying CONFIG_CMDLINE into boot_command_line/data if the DT has
a /chosen node but that node has no bootargs property or a bootargs
property of length zero.
This is problematic for the MIPS architecture because we support
concatenating arguments from either the DT or the bootloader with those
from CONFIG_CMDLINE, but the behaviour of early_init_dt_scan_chosen()
gives us no way of knowing whether boot_command_line contains arguments
from DT or already contains CONFIG_CMDLINE. This can lead to us
concatenating CONFIG_CMDLINE with itself, duplicating command line
arguments which can be problematic (eg. for earlycon which will attempt
to register the same console twice & warn about it).
Move the CONFIG_CMDLINE-related logic to a weak function that
architectures can provide their own version of, such that we continue to
use the existing logic for architectures where it's suitable but also
allow MIPS to override this behaviour such that the architecture code
knows when CONFIG_CMDLINE is used.
Signed-off-by: Paul Burton
References: https://patchwork.linux-mips.org/patch/18804/
Cc: Frank Rowand
Cc: Jaedon Shin
Cc: Mathieu Malaterre
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: sta...@vger.kernel.org # v4.16+
---
Marked for stable as a prerequisite of the following patch.
DT maintainers: if you're OK with this it'd be great to get an ack so
this can go through the mips-fixes tree.
---
drivers/of/fdt.c | 55 +-
include/linux/of_fdt.h | 1 +
2 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 800ad252cf9c..94c474315cff 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1072,6 +1072,43 @@ int __init early_init_dt_scan_memory(unsigned long node,
const char *uname,
return 0;
}
+/**
+ * early_init_dt_fixup_cmdline_arch() - Modify a command line taken from DT
+ * @data: A pointer to the command line
+ *
+ * This function provides an opportunity to make modifications to command line
+ * arguments taken from a device tree before use, for example to concatenate
+ * them with arguments from other sources or replace them entirely.
+ *
+ * Modifications should be made directly to the string pointed at by @data,
+ * which is COMMAND_LINE_SIZE bytes in size.
+ *
+ * The default implementation supports extending or overriding the DT command
+ * line arguments using CONFIG_CMDLINE. Since other sources of command line
+ * arguments are platform-specific, architectures can provide their own
+ * implementation of this function to obtain their desired behaviour.
+ */
+void __init __weak early_init_dt_fixup_cmdline_arch(char *data)
+{
+ /*
+* CONFIG_CMDLINE is meant to be a default in case nothing else
+* managed to set the command line, unless CONFIG_CMDLINE_FORCE
+* is set in which case we override whatever was found earlier.
+*/
+#ifdef CONFIG_CMDLINE
+#if defined(CONFIG_CMDLINE_EXTEND)
+ strlcat(data, " ", COMMAND_LINE_SIZE);
+ strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+#elif defined(CONFIG_CMDLINE_FORCE)
+ strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+#else
+ /* No arguments from boot loader, use kernel's cmdl */
+ if (!data[0])
+ strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+#endif
+#endif /* CONFIG_CMDLINE */
+}
+
int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
int depth, void *data)
{
@@ -1091,23 +1128,7 @@ int __init early_init_dt_scan_chosen(unsigned long node,
const char *uname,
if (p != NULL && l > 0)
strlcpy(data, p, min((int)l, COMMAND_LINE_SIZE));
- /*
-* CONFIG_CMDLINE is meant to be a default in case nothing else
-* managed to set the command line, unless CONFIG_CMDLINE_FORCE
-* is set in which case we override whatever was found earlier.
-*/
-#ifdef CONFIG_CMDLINE
-#if defined(CONFIG_CMDLINE_EXTEND)
- strlcat(data, " ", COMMAND_LINE_SIZE);
- strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#elif defined(CONFIG_CMDLINE_FORCE)
- strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#else
- /* No arguments from boot loader, use kernel's cmdl*/
- if (!((char *)data)[0])
- strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#endif
-#endif /* CONFIG_CMDLINE */
+ early_init_dt_fixup_cmdline_arch(data);
pr_debug("Command line is: %s\n", (char*)data);
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index b9cd9ebdf9b9..98935695f49d 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -80,6 +80,7 @@ extern void early_init_dt_add_memory_arch(u64 base, u64 size);
extern int early_init_dt_mark_hot
[PATCH 1/2] of/fdt: Allow architectures to override CONFIG_CMDLINE logic
The CONFIG_CMDLINE-related logic in early_init_dt_scan_chosen() falls
back to copying CONFIG_CMDLINE into boot_command_line/data if the DT has
a /chosen node but that node has no bootargs property or a bootargs
property of length zero.
This is problematic for the MIPS architecture because we support
concatenating arguments from either the DT or the bootloader with those
from CONFIG_CMDLINE, but the behaviour of early_init_dt_scan_chosen()
gives us no way of knowing whether boot_command_line contains arguments
from DT or already contains CONFIG_CMDLINE. This can lead to us
concatenating CONFIG_CMDLINE with itself, duplicating command line
arguments which can be problematic (eg. for earlycon which will attempt
to register the same console twice & warn about it).
Move the CONFIG_CMDLINE-related logic to a weak function that
architectures can provide their own version of, such that we continue to
use the existing logic for architectures where it's suitable but also
allow MIPS to override this behaviour such that the architecture code
knows when CONFIG_CMDLINE is used.
Signed-off-by: Paul Burton
References: https://patchwork.linux-mips.org/patch/18804/
Cc: Frank Rowand
Cc: Jaedon Shin
Cc: Mathieu Malaterre
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: sta...@vger.kernel.org # v4.16+
---
Marked for stable as a prerequisite of the following patch.
DT maintainers: if you're OK with this it'd be great to get an ack so
this can go through the mips-fixes tree.
---
drivers/of/fdt.c | 55 +-
include/linux/of_fdt.h | 1 +
2 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 800ad252cf9c..94c474315cff 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1072,6 +1072,43 @@ int __init early_init_dt_scan_memory(unsigned long node,
const char *uname,
return 0;
}
+/**
+ * early_init_dt_fixup_cmdline_arch() - Modify a command line taken from DT
+ * @data: A pointer to the command line
+ *
+ * This function provides an opportunity to make modifications to command line
+ * arguments taken from a device tree before use, for example to concatenate
+ * them with arguments from other sources or replace them entirely.
+ *
+ * Modifications should be made directly to the string pointed at by @data,
+ * which is COMMAND_LINE_SIZE bytes in size.
+ *
+ * The default implementation supports extending or overriding the DT command
+ * line arguments using CONFIG_CMDLINE. Since other sources of command line
+ * arguments are platform-specific, architectures can provide their own
+ * implementation of this function to obtain their desired behaviour.
+ */
+void __init __weak early_init_dt_fixup_cmdline_arch(char *data)
+{
+ /*
+* CONFIG_CMDLINE is meant to be a default in case nothing else
+* managed to set the command line, unless CONFIG_CMDLINE_FORCE
+* is set in which case we override whatever was found earlier.
+*/
+#ifdef CONFIG_CMDLINE
+#if defined(CONFIG_CMDLINE_EXTEND)
+ strlcat(data, " ", COMMAND_LINE_SIZE);
+ strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+#elif defined(CONFIG_CMDLINE_FORCE)
+ strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+#else
+ /* No arguments from boot loader, use kernel's cmdl */
+ if (!data[0])
+ strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+#endif
+#endif /* CONFIG_CMDLINE */
+}
+
int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
int depth, void *data)
{
@@ -1091,23 +1128,7 @@ int __init early_init_dt_scan_chosen(unsigned long node,
const char *uname,
if (p != NULL && l > 0)
strlcpy(data, p, min((int)l, COMMAND_LINE_SIZE));
- /*
-* CONFIG_CMDLINE is meant to be a default in case nothing else
-* managed to set the command line, unless CONFIG_CMDLINE_FORCE
-* is set in which case we override whatever was found earlier.
-*/
-#ifdef CONFIG_CMDLINE
-#if defined(CONFIG_CMDLINE_EXTEND)
- strlcat(data, " ", COMMAND_LINE_SIZE);
- strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#elif defined(CONFIG_CMDLINE_FORCE)
- strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#else
- /* No arguments from boot loader, use kernel's cmdl*/
- if (!((char *)data)[0])
- strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#endif
-#endif /* CONFIG_CMDLINE */
+ early_init_dt_fixup_cmdline_arch(data);
pr_debug("Command line is: %s\n", (char*)data);
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index b9cd9ebdf9b9..98935695f49d 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -80,6 +80,7 @@ extern void early_init_dt_add_memory_arch(u64 base, u64 size);
extern int early_init_dt_mark_hot
[PATCH 2/2] MIPS: Fix CONFIG_CMDLINE handling
Commit 8ce355cf2e38 ("MIPS: Setup boot_command_line before
plat_mem_setup") fixed a problem for systems which have
CONFIG_CMDLINE_BOOL=y & use a DT with a chosen node that has either no
bootargs property or an empty one. In this configuration
early_init_dt_scan_chosen() copies CONFIG_CMDLINE into
boot_command_line, but the MIPS code doesn't know this so it appends
CONFIG_CMDLINE (via builtin_cmdline) to boot_command_line again. The
result is that boot_command_line contains the arguments from
CONFIG_CMDLINE twice.
That commit took the approach of simply setting up boot_command_line
from the MIPS code before early_init_dt_scan_chosen() runs, causing it
not to copy CONFIG_CMDLINE to boot_command_line if a chosen node with no
bootargs property is found.
Unfortunately this is problematic for systems which do have a non-empty
bootargs property & CONFIG_CMDLINE_BOOL=y. There
early_init_dt_scan_chosen() will overwrite boot_command_line with the
arguments from DT, which means we lose those from CONFIG_CMDLINE
entirely. This breaks CONFIG_MIPS_CMDLINE_DTB_EXTEND. If we have
CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER or
CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND selected and the DT has a bootargs
property which we should ignore, it will instead be honoured breaking
those configurations too.
Fix this by reverting commit 8ce355cf2e38 ("MIPS: Setup
boot_command_line before plat_mem_setup") to restore the former
behaviour, and fixing the CONFIG_CMDLINE duplication issue by instead
providing a no-op implementation of early_init_dt_fixup_cmdline_arch()
to prevent early_init_dt_scan_chosen() from using CONFIG_CMDLINE.
Signed-off-by: Paul Burton
Fixes: 8ce355cf2e38 ("MIPS: Setup boot_command_line before plat_mem_setup")
References: https://patchwork.linux-mips.org/patch/18804/
Cc: Frank Rowand
Cc: Jaedon Shin
Cc: Mathieu Malaterre
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: sta...@vger.kernel.org # v4.16+
---
arch/mips/kernel/setup.c | 47 +++-
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index c71d1eb7da59..7f755bc8a91c 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -841,11 +841,38 @@ static void __init request_crashkernel(struct resource
*res)
#define BUILTIN_EXTEND_WITH_PROM \
IS_ENABLED(CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)
+void __init early_init_dt_fixup_cmdline_arch(char *data)
+{
+ /*
+* Do nothing - arch_mem_init() will assemble our command line below,
+* for both the DT & non-DT cases.
+*/
+}
+
static void __init arch_mem_init(char **cmdline_p)
{
struct memblock_region *reg;
extern void plat_mem_setup(void);
+ /* call board setup routine */
+ plat_mem_setup();
+
+ /*
+* Make sure all kernel memory is in the maps. The "UP" and
+* "DOWN" are opposite for initdata since if it crosses over
+* into another memory section you don't want that to be
+* freed when the initdata is freed.
+*/
+ arch_mem_addpart(PFN_DOWN(__pa_symbol(&_text)) << PAGE_SHIFT,
+PFN_UP(__pa_symbol(&_edata)) << PAGE_SHIFT,
+BOOT_MEM_RAM);
+ arch_mem_addpart(PFN_UP(__pa_symbol(&__init_begin)) << PAGE_SHIFT,
+PFN_DOWN(__pa_symbol(&__init_end)) << PAGE_SHIFT,
+BOOT_MEM_INIT_RAM);
+
+ pr_info("Determined physical RAM map:\n");
+ print_memory_map();
+
#if defined(CONFIG_CMDLINE_BOOL) && defined(CONFIG_CMDLINE_OVERRIDE)
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
#else
@@ -873,26 +900,6 @@ static void __init arch_mem_init(char **cmdline_p)
}
#endif
#endif
-
- /* call board setup routine */
- plat_mem_setup();
-
- /*
-* Make sure all kernel memory is in the maps. The "UP" and
-* "DOWN" are opposite for initdata since if it crosses over
-* into another memory section you don't want that to be
-* freed when the initdata is freed.
-*/
- arch_mem_addpart(PFN_DOWN(__pa_symbol(&_text)) << PAGE_SHIFT,
-PFN_UP(__pa_symbol(&_edata)) << PAGE_SHIFT,
-BOOT_MEM_RAM);
- arch_mem_addpart(PFN_UP(__pa_symbol(&__init_begin)) << PAGE_SHIFT,
-PFN_DOWN(__pa_symbol(&__init_end)) << PAGE_SHIFT,
-BOOT_MEM_INIT_RAM);
-
- pr_info("Determined physical RAM map:\n");
- print_memory_map();
-
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
2.18.0
[PATCH 2/2] MIPS: Fix CONFIG_CMDLINE handling
Commit 8ce355cf2e38 ("MIPS: Setup boot_command_line before
plat_mem_setup") fixed a problem for systems which have
CONFIG_CMDLINE_BOOL=y & use a DT with a chosen node that has either no
bootargs property or an empty one. In this configuration
early_init_dt_scan_chosen() copies CONFIG_CMDLINE into
boot_command_line, but the MIPS code doesn't know this so it appends
CONFIG_CMDLINE (via builtin_cmdline) to boot_command_line again. The
result is that boot_command_line contains the arguments from
CONFIG_CMDLINE twice.
That commit took the approach of simply setting up boot_command_line
from the MIPS code before early_init_dt_scan_chosen() runs, causing it
not to copy CONFIG_CMDLINE to boot_command_line if a chosen node with no
bootargs property is found.
Unfortunately this is problematic for systems which do have a non-empty
bootargs property & CONFIG_CMDLINE_BOOL=y. There
early_init_dt_scan_chosen() will overwrite boot_command_line with the
arguments from DT, which means we lose those from CONFIG_CMDLINE
entirely. This breaks CONFIG_MIPS_CMDLINE_DTB_EXTEND. If we have
CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER or
CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND selected and the DT has a bootargs
property which we should ignore, it will instead be honoured breaking
those configurations too.
Fix this by reverting commit 8ce355cf2e38 ("MIPS: Setup
boot_command_line before plat_mem_setup") to restore the former
behaviour, and fixing the CONFIG_CMDLINE duplication issue by instead
providing a no-op implementation of early_init_dt_fixup_cmdline_arch()
to prevent early_init_dt_scan_chosen() from using CONFIG_CMDLINE.
Signed-off-by: Paul Burton
Fixes: 8ce355cf2e38 ("MIPS: Setup boot_command_line before plat_mem_setup")
References: https://patchwork.linux-mips.org/patch/18804/
Cc: Frank Rowand
Cc: Jaedon Shin
Cc: Mathieu Malaterre
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: sta...@vger.kernel.org # v4.16+
---
arch/mips/kernel/setup.c | 47 +++-
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index c71d1eb7da59..7f755bc8a91c 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -841,11 +841,38 @@ static void __init request_crashkernel(struct resource
*res)
#define BUILTIN_EXTEND_WITH_PROM \
IS_ENABLED(CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)
+void __init early_init_dt_fixup_cmdline_arch(char *data)
+{
+ /*
+* Do nothing - arch_mem_init() will assemble our command line below,
+* for both the DT & non-DT cases.
+*/
+}
+
static void __init arch_mem_init(char **cmdline_p)
{
struct memblock_region *reg;
extern void plat_mem_setup(void);
+ /* call board setup routine */
+ plat_mem_setup();
+
+ /*
+* Make sure all kernel memory is in the maps. The "UP" and
+* "DOWN" are opposite for initdata since if it crosses over
+* into another memory section you don't want that to be
+* freed when the initdata is freed.
+*/
+ arch_mem_addpart(PFN_DOWN(__pa_symbol(&_text)) << PAGE_SHIFT,
+PFN_UP(__pa_symbol(&_edata)) << PAGE_SHIFT,
+BOOT_MEM_RAM);
+ arch_mem_addpart(PFN_UP(__pa_symbol(&__init_begin)) << PAGE_SHIFT,
+PFN_DOWN(__pa_symbol(&__init_end)) << PAGE_SHIFT,
+BOOT_MEM_INIT_RAM);
+
+ pr_info("Determined physical RAM map:\n");
+ print_memory_map();
+
#if defined(CONFIG_CMDLINE_BOOL) && defined(CONFIG_CMDLINE_OVERRIDE)
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
#else
@@ -873,26 +900,6 @@ static void __init arch_mem_init(char **cmdline_p)
}
#endif
#endif
-
- /* call board setup routine */
- plat_mem_setup();
-
- /*
-* Make sure all kernel memory is in the maps. The "UP" and
-* "DOWN" are opposite for initdata since if it crosses over
-* into another memory section you don't want that to be
-* freed when the initdata is freed.
-*/
- arch_mem_addpart(PFN_DOWN(__pa_symbol(&_text)) << PAGE_SHIFT,
-PFN_UP(__pa_symbol(&_edata)) << PAGE_SHIFT,
-BOOT_MEM_RAM);
- arch_mem_addpart(PFN_UP(__pa_symbol(&__init_begin)) << PAGE_SHIFT,
-PFN_DOWN(__pa_symbol(&__init_end)) << PAGE_SHIFT,
-BOOT_MEM_INIT_RAM);
-
- pr_info("Determined physical RAM map:\n");
- print_memory_map();
-
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
2.18.0
Re: [PATCH] MIPS: pci-rt2880: set pci controller of_node
Hi Matthias, On Wed, Sep 05, 2018 at 08:51:26AM +0200, Mathias Kresin wrote: > From: Tobias Wolf > > Set the PCI controller of_node such that PCI devices can be > instantiated via device tree. > > Signed-off-by: Tobias Wolf > Signed-off-by: Mathias Kresin > --- > arch/mips/pci/pci-rt2880.c | 2 ++ > 1 file changed, 2 insertions(+) Thanks - applied to mips-next for 4.20. Paul
Re: [PATCH] MIPS: pci-rt2880: set pci controller of_node
Hi Matthias, On Wed, Sep 05, 2018 at 08:51:26AM +0200, Mathias Kresin wrote: > From: Tobias Wolf > > Set the PCI controller of_node such that PCI devices can be > instantiated via device tree. > > Signed-off-by: Tobias Wolf > Signed-off-by: Mathias Kresin > --- > arch/mips/pci/pci-rt2880.c | 2 ++ > 1 file changed, 2 insertions(+) Thanks - applied to mips-next for 4.20. Paul
Re: [PATCH] mips: txx9: fix iounmap related issue
Hi Ding, On Thu, Sep 06, 2018 at 12:19:19PM +0800, Ding Xiang wrote: > if device_register return error, iounmap should be called, also iounmap > need to call before put_device. > > Signed-off-by: Ding Xiang > --- > arch/mips/txx9/generic/setup.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) Applied to mips-next for 4.20 - thanks, and thanks to Atsushi for reviewing too! Paul
Re: [PATCH] mips: txx9: fix iounmap related issue
Hi Ding, On Thu, Sep 06, 2018 at 12:19:19PM +0800, Ding Xiang wrote: > if device_register return error, iounmap should be called, also iounmap > need to call before put_device. > > Signed-off-by: Ding Xiang > --- > arch/mips/txx9/generic/setup.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) Applied to mips-next for 4.20 - thanks, and thanks to Atsushi for reviewing too! Paul
Re: [PATCH v5 0/7] Add support for MSCC Ocelot i2c
Hi Alexandre & Wolfram, On Sat, Sep 01, 2018 at 02:43:53PM +0200, Wolfram Sang wrote: > > Because the designware IP was not able to handle the SDA hold time before > > version 1.11a, MSCC has its own implementation. Add support for it and then > > add > > i2c on ocelot boards. > > > > I would expect patches 1 to 5 to go through the i2c tree. > > Applied to for-next, thanks! > > > Pathces 6-7 can go through the mips tree now that the bindings have been > > reviewed. > > They have been reviewed by Rob and are applied now to my tree. Patches 6 & 7 applied to mips-next for 4.20 - thanks! Paul
Re: [PATCH v5 0/7] Add support for MSCC Ocelot i2c
Hi Alexandre & Wolfram, On Sat, Sep 01, 2018 at 02:43:53PM +0200, Wolfram Sang wrote: > > Because the designware IP was not able to handle the SDA hold time before > > version 1.11a, MSCC has its own implementation. Add support for it and then > > add > > i2c on ocelot boards. > > > > I would expect patches 1 to 5 to go through the i2c tree. > > Applied to for-next, thanks! > > > Pathces 6-7 can go through the mips tree now that the bindings have been > > reviewed. > > They have been reviewed by Rob and are applied now to my tree. Patches 6 & 7 applied to mips-next for 4.20 - thanks! Paul
Re: [PATCH RESEND] mips: switch to NO_BOOTMEM
Hi Mike, On Sat, Sep 01, 2018 at 12:17:48AM +0300, Mike Rapoport wrote: > On Thu, Aug 30, 2018 at 02:48:57PM -0700, Paul Burton wrote: > > On Mon, Aug 27, 2018 at 10:59:35AM +0300, Mike Rapoport wrote: > > > MIPS already has memblock support and all the memory is already registered > > > with it. > > > > > > This patch replaces bootmem memory reservations with memblock ones and > > > removes the bootmem initialization. > > > > > > Signed-off-by: Mike Rapoport > > > --- > > > > > > arch/mips/Kconfig | 1 + > > > arch/mips/kernel/setup.c | 89 > > > +- > > > arch/mips/loongson64/loongson-3/numa.c | 34 ++--- > > > arch/mips/sgi-ip27/ip27-memory.c | 11 ++--- > > > 4 files changed, 33 insertions(+), 102 deletions(-) > > > > Thanks for working on this. Unfortunately it breaks boot for at least a > > 32r6el_defconfig kernel on QEMU: > > > > $ qemu-system-mips64el \ > > -M boston \ > > -kernel arch/mips/boot/vmlinux.gz.itb \ > > -serial stdio \ > > -append "earlycon=uart8250,mmio32,0x17ffe000,115200 > > console=ttyS0,115200 debug memblock=debug mminit_loglevel=4" > > [0.00] Linux version 4.19.0-rc1-8-g82d0f342eecd > > (pburton@pburton-laptop) (gcc version 8.1.0 (GCC)) #23 SMP Thu Aug 30 > > 14:38:06 PDT 2018 > > [0.00] CPU0 revision is: 0001a900 (MIPS I6400) > > [0.00] FPU revision is: 20f30300 > > [0.00] MSA revision is: 0300 > > [0.00] MIPS: machine is img,boston > > [0.00] Determined physical RAM map: > > [0.00] memory: 1000 @ (usable) > > [0.00] memory: 3000 @ 9000 (usable) > > [0.00] earlycon: uart8250 at MMIO32 0x17ffe000 (options '115200') > > [0.00] bootconsole [uart8250] enabled > > [0.00] memblock_reserve: [0x-0x009a8fff] > > setup_arch+0x224/0x718 > > [0.00] memblock_reserve: [0x0136-0x01361ca7] > > setup_arch+0x3d8/0x718 > > [0.00] Initrd not found or empty - disabling initrd > > [0.00] memblock_virt_alloc_try_nid: 7336 bytes align=0x40 nid=-1 > > from=0x max_addr=0x > > early_init_dt_alloc_memory_arch+0x20/0x2c > > [0.00] memblock_reserve: [0xbfffe340-0xbfe7] > > memblock_virt_alloc_internal+0x120/0x1ec > > > > > > It looks like we took a TLB store exception after calling memset() with > > a bogus address from memblock_virt_alloc_try_nid() or something inlined > > into it. > > Memblock tries to allocate from the top and the resulting address ends up > in the high memory. > > With the hunk below I was able to get to "VFS: Cannot open root device" > > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c > index 4114d3c..4a9b0f7 100644 > --- a/arch/mips/kernel/setup.c > +++ b/arch/mips/kernel/setup.c > @@ -577,6 +577,8 @@ static void __init bootmem_init(void) > * Reserve initrd memory if needed. > */ > finalize_initrd(); > + > + memblock_set_bottom_up(true); > } That does seem to fix it, and some basic tests are looking good. I notice you submitted this as part of your larger series to remove bootmem - are you still happy for me to take this one through mips-next? Thanks, Paul
Re: [PATCH RESEND] mips: switch to NO_BOOTMEM
Hi Mike, On Sat, Sep 01, 2018 at 12:17:48AM +0300, Mike Rapoport wrote: > On Thu, Aug 30, 2018 at 02:48:57PM -0700, Paul Burton wrote: > > On Mon, Aug 27, 2018 at 10:59:35AM +0300, Mike Rapoport wrote: > > > MIPS already has memblock support and all the memory is already registered > > > with it. > > > > > > This patch replaces bootmem memory reservations with memblock ones and > > > removes the bootmem initialization. > > > > > > Signed-off-by: Mike Rapoport > > > --- > > > > > > arch/mips/Kconfig | 1 + > > > arch/mips/kernel/setup.c | 89 > > > +- > > > arch/mips/loongson64/loongson-3/numa.c | 34 ++--- > > > arch/mips/sgi-ip27/ip27-memory.c | 11 ++--- > > > 4 files changed, 33 insertions(+), 102 deletions(-) > > > > Thanks for working on this. Unfortunately it breaks boot for at least a > > 32r6el_defconfig kernel on QEMU: > > > > $ qemu-system-mips64el \ > > -M boston \ > > -kernel arch/mips/boot/vmlinux.gz.itb \ > > -serial stdio \ > > -append "earlycon=uart8250,mmio32,0x17ffe000,115200 > > console=ttyS0,115200 debug memblock=debug mminit_loglevel=4" > > [0.00] Linux version 4.19.0-rc1-8-g82d0f342eecd > > (pburton@pburton-laptop) (gcc version 8.1.0 (GCC)) #23 SMP Thu Aug 30 > > 14:38:06 PDT 2018 > > [0.00] CPU0 revision is: 0001a900 (MIPS I6400) > > [0.00] FPU revision is: 20f30300 > > [0.00] MSA revision is: 0300 > > [0.00] MIPS: machine is img,boston > > [0.00] Determined physical RAM map: > > [0.00] memory: 1000 @ (usable) > > [0.00] memory: 3000 @ 9000 (usable) > > [0.00] earlycon: uart8250 at MMIO32 0x17ffe000 (options '115200') > > [0.00] bootconsole [uart8250] enabled > > [0.00] memblock_reserve: [0x-0x009a8fff] > > setup_arch+0x224/0x718 > > [0.00] memblock_reserve: [0x0136-0x01361ca7] > > setup_arch+0x3d8/0x718 > > [0.00] Initrd not found or empty - disabling initrd > > [0.00] memblock_virt_alloc_try_nid: 7336 bytes align=0x40 nid=-1 > > from=0x max_addr=0x > > early_init_dt_alloc_memory_arch+0x20/0x2c > > [0.00] memblock_reserve: [0xbfffe340-0xbfe7] > > memblock_virt_alloc_internal+0x120/0x1ec > > > > > > It looks like we took a TLB store exception after calling memset() with > > a bogus address from memblock_virt_alloc_try_nid() or something inlined > > into it. > > Memblock tries to allocate from the top and the resulting address ends up > in the high memory. > > With the hunk below I was able to get to "VFS: Cannot open root device" > > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c > index 4114d3c..4a9b0f7 100644 > --- a/arch/mips/kernel/setup.c > +++ b/arch/mips/kernel/setup.c > @@ -577,6 +577,8 @@ static void __init bootmem_init(void) > * Reserve initrd memory if needed. > */ > finalize_initrd(); > + > + memblock_set_bottom_up(true); > } That does seem to fix it, and some basic tests are looking good. I notice you submitted this as part of your larger series to remove bootmem - are you still happy for me to take this one through mips-next? Thanks, Paul
Re: [PATCH 1/3] MIPS: jz4780: Allow access to jz4740-i2s
On Fri, Aug 31, 2018 at 01:37:52PM -0700, Paul Burton wrote: > Further to that, this series doesn't seem to work for me. With > v4.19-rc1, with the patch from [1] & then this series applied I see the > following when booting a ci20_defconfig kernel: > > [0.846684] ALSA device list: > [0.849642] No soundcards found. D'oh! Apparently I haven't drunk enough coffee today - missing link can be found below: [1] https://www.spinics.net/lists/linux-gpio/msg31965.html Thanks, Paul
Re: [PATCH 1/3] MIPS: jz4780: Allow access to jz4740-i2s
On Fri, Aug 31, 2018 at 01:37:52PM -0700, Paul Burton wrote: > Further to that, this series doesn't seem to work for me. With > v4.19-rc1, with the patch from [1] & then this series applied I see the > following when booting a ci20_defconfig kernel: > > [0.846684] ALSA device list: > [0.849642] No soundcards found. D'oh! Apparently I haven't drunk enough coffee today - missing link can be found below: [1] https://www.spinics.net/lists/linux-gpio/msg31965.html Thanks, Paul
Re: [PATCH 1/3] MIPS: jz4780: Allow access to jz4740-i2s
Hi Matthieu, On Tue, Jul 24, 2018 at 01:47:57PM -0700, Paul Burton wrote: > On Wed, Jun 06, 2018 at 09:38:08PM +0200, Mathieu Malaterre wrote: > > diff --git a/sound/soc/jz4740/Kconfig b/sound/soc/jz4740/Kconfig > > index 1a354a6b6e87..35d82d96e781 100644 > > --- a/sound/soc/jz4740/Kconfig > > +++ b/sound/soc/jz4740/Kconfig > > @@ -1,20 +1,20 @@ > > config SND_JZ4740_SOC > > - tristate "SoC Audio for Ingenic JZ4740 SoC" > > - depends on MACH_JZ4740 || COMPILE_TEST > > + tristate "SoC Audio for Ingenic JZ4740/JZ4780 SoC" > > + depends on MACH_JZ4740 || MACH_JZ4780 || COMPILE_TEST > > Perhaps this could be MACH_INGENIC, or even just MIPS? Further to that, this series doesn't seem to work for me. With v4.19-rc1, with the patch from [1] & then this series applied I see the following when booting a ci20_defconfig kernel: [0.846684] ALSA device list: [0.849642] No soundcards found. Nothing else looks obviously relevant, but here's the full boot log for reference: https://gist.github.com/paulburton/336fa3a6ed756f9bbb587f01dcd520e5/6a5042a258348ed5e5d3d0cb1a72076abf31d85b Thanks, Paul
Re: [PATCH 1/3] MIPS: jz4780: Allow access to jz4740-i2s
Hi Matthieu, On Tue, Jul 24, 2018 at 01:47:57PM -0700, Paul Burton wrote: > On Wed, Jun 06, 2018 at 09:38:08PM +0200, Mathieu Malaterre wrote: > > diff --git a/sound/soc/jz4740/Kconfig b/sound/soc/jz4740/Kconfig > > index 1a354a6b6e87..35d82d96e781 100644 > > --- a/sound/soc/jz4740/Kconfig > > +++ b/sound/soc/jz4740/Kconfig > > @@ -1,20 +1,20 @@ > > config SND_JZ4740_SOC > > - tristate "SoC Audio for Ingenic JZ4740 SoC" > > - depends on MACH_JZ4740 || COMPILE_TEST > > + tristate "SoC Audio for Ingenic JZ4740/JZ4780 SoC" > > + depends on MACH_JZ4740 || MACH_JZ4780 || COMPILE_TEST > > Perhaps this could be MACH_INGENIC, or even just MIPS? Further to that, this series doesn't seem to work for me. With v4.19-rc1, with the patch from [1] & then this series applied I see the following when booting a ci20_defconfig kernel: [0.846684] ALSA device list: [0.849642] No soundcards found. Nothing else looks obviously relevant, but here's the full boot log for reference: https://gist.github.com/paulburton/336fa3a6ed756f9bbb587f01dcd520e5/6a5042a258348ed5e5d3d0cb1a72076abf31d85b Thanks, Paul
Re: [PATCH RESEND] mips: switch to NO_BOOTMEM
Hi Mike,
On Mon, Aug 27, 2018 at 10:59:35AM +0300, Mike Rapoport wrote:
> MIPS already has memblock support and all the memory is already registered
> with it.
>
> This patch replaces bootmem memory reservations with memblock ones and
> removes the bootmem initialization.
>
> Signed-off-by: Mike Rapoport
> ---
>
> arch/mips/Kconfig | 1 +
> arch/mips/kernel/setup.c | 89
> +-
> arch/mips/loongson64/loongson-3/numa.c | 34 ++---
> arch/mips/sgi-ip27/ip27-memory.c | 11 ++---
> 4 files changed, 33 insertions(+), 102 deletions(-)
Thanks for working on this. Unfortunately it breaks boot for at least a
32r6el_defconfig kernel on QEMU:
$ qemu-system-mips64el \
-M boston \
-kernel arch/mips/boot/vmlinux.gz.itb \
-serial stdio \
-append "earlycon=uart8250,mmio32,0x17ffe000,115200 console=ttyS0,115200
debug memblock=debug mminit_loglevel=4"
[0.00] Linux version 4.19.0-rc1-8-g82d0f342eecd
(pburton@pburton-laptop) (gcc version 8.1.0 (GCC)) #23 SMP Thu Aug 30 14:38:06
PDT 2018
[0.00] CPU0 revision is: 0001a900 (MIPS I6400)
[0.00] FPU revision is: 20f30300
[0.00] MSA revision is: 0300
[0.00] MIPS: machine is img,boston
[0.00] Determined physical RAM map:
[0.00] memory: 1000 @ (usable)
[0.00] memory: 3000 @ 9000 (usable)
[0.00] earlycon: uart8250 at MMIO32 0x17ffe000 (options '115200')
[0.00] bootconsole [uart8250] enabled
[0.00] memblock_reserve: [0x-0x009a8fff]
setup_arch+0x224/0x718
[0.00] memblock_reserve: [0x0136-0x01361ca7]
setup_arch+0x3d8/0x718
[0.00] Initrd not found or empty - disabling initrd
[0.00] memblock_virt_alloc_try_nid: 7336 bytes align=0x40 nid=-1
from=0x max_addr=0x early_init_dt_alloc_memory_arch+0x20/0x2c
[0.00] memblock_reserve: [0xbfffe340-0xbfe7]
memblock_virt_alloc_internal+0x120/0x1ec
It looks like we took a TLB store exception after calling memset() with
a bogus address from memblock_virt_alloc_try_nid() or something inlined
into it.
This was with your patch applied atop the mips-next branch from [1],
which is currently at commit 35d017947401 ("MIPS: ralink: Add rt3352
SPI_CS1 pinmux").
Thanks,
Paul
[1] git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git
Re: [PATCH RESEND] mips: switch to NO_BOOTMEM
Hi Mike,
On Mon, Aug 27, 2018 at 10:59:35AM +0300, Mike Rapoport wrote:
> MIPS already has memblock support and all the memory is already registered
> with it.
>
> This patch replaces bootmem memory reservations with memblock ones and
> removes the bootmem initialization.
>
> Signed-off-by: Mike Rapoport
> ---
>
> arch/mips/Kconfig | 1 +
> arch/mips/kernel/setup.c | 89
> +-
> arch/mips/loongson64/loongson-3/numa.c | 34 ++---
> arch/mips/sgi-ip27/ip27-memory.c | 11 ++---
> 4 files changed, 33 insertions(+), 102 deletions(-)
Thanks for working on this. Unfortunately it breaks boot for at least a
32r6el_defconfig kernel on QEMU:
$ qemu-system-mips64el \
-M boston \
-kernel arch/mips/boot/vmlinux.gz.itb \
-serial stdio \
-append "earlycon=uart8250,mmio32,0x17ffe000,115200 console=ttyS0,115200
debug memblock=debug mminit_loglevel=4"
[0.00] Linux version 4.19.0-rc1-8-g82d0f342eecd
(pburton@pburton-laptop) (gcc version 8.1.0 (GCC)) #23 SMP Thu Aug 30 14:38:06
PDT 2018
[0.00] CPU0 revision is: 0001a900 (MIPS I6400)
[0.00] FPU revision is: 20f30300
[0.00] MSA revision is: 0300
[0.00] MIPS: machine is img,boston
[0.00] Determined physical RAM map:
[0.00] memory: 1000 @ (usable)
[0.00] memory: 3000 @ 9000 (usable)
[0.00] earlycon: uart8250 at MMIO32 0x17ffe000 (options '115200')
[0.00] bootconsole [uart8250] enabled
[0.00] memblock_reserve: [0x-0x009a8fff]
setup_arch+0x224/0x718
[0.00] memblock_reserve: [0x0136-0x01361ca7]
setup_arch+0x3d8/0x718
[0.00] Initrd not found or empty - disabling initrd
[0.00] memblock_virt_alloc_try_nid: 7336 bytes align=0x40 nid=-1
from=0x max_addr=0x early_init_dt_alloc_memory_arch+0x20/0x2c
[0.00] memblock_reserve: [0xbfffe340-0xbfe7]
memblock_virt_alloc_internal+0x120/0x1ec
It looks like we took a TLB store exception after calling memset() with
a bogus address from memblock_virt_alloc_try_nid() or something inlined
into it.
This was with your patch applied atop the mips-next branch from [1],
which is currently at commit 35d017947401 ("MIPS: ralink: Add rt3352
SPI_CS1 pinmux").
Thanks,
Paul
[1] git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git
Re: [PATCH] MIPS: ralink: Add rt3352 SPI_CS1 pinmux
Hi Mathias, On Wed, Aug 22, 2018 at 10:38:06PM +0200, Mathias Kresin wrote: > The rt3352 has a pin that can be used as second spi chip select, > watchdog reset or GPIO. The pinmux setup was missing the definition of > said pin. > > The pin is configured via the same bit on rt5350, so reuse the existing > macro. > > Signed-off-by: Mathias Kresin > --- > arch/mips/ralink/rt305x.c | 5 + > 1 file changed, 5 insertions(+) Thanks, applied to mips-next for 4.20. Paul
Re: [PATCH] MIPS: ralink: Add rt3352 SPI_CS1 pinmux
Hi Mathias, On Wed, Aug 22, 2018 at 10:38:06PM +0200, Mathias Kresin wrote: > The rt3352 has a pin that can be used as second spi chip select, > watchdog reset or GPIO. The pinmux setup was missing the definition of > said pin. > > The pin is configured via the same bit on rt5350, so reuse the existing > macro. > > Signed-off-by: Mathias Kresin > --- > arch/mips/ralink/rt305x.c | 5 + > 1 file changed, 5 insertions(+) Thanks, applied to mips-next for 4.20. Paul
Re: [PATCH] MIPS: BCM47XX: Enable USB power on Netgear WNDR3400v3
Hi Tuomas, On Sun, Aug 19, 2018 at 10:20:23PM +0300, Tuomas Tynkkynen wrote: > Setting GPIO 21 high seems to be required to enable power to USB ports > on the WNDR3400v3. As there is already similar code for WNR3500L, > make the existing USB power GPIO code generic and use that. > > Signed-off-by: Tuomas Tynkkynen > --- > arch/mips/bcm47xx/workarounds.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) It'd be nice to see this stuff move towards DT, and configuring a GPIO to enable power doesn't seem so much a workaround as a normal expected part of operation. But I've applied this to mips-next for 4.20 since it doesn't really make things any worse for now... Thanks, Paul
Re: [PATCH] MIPS: BCM47XX: Enable USB power on Netgear WNDR3400v3
Hi Tuomas, On Sun, Aug 19, 2018 at 10:20:23PM +0300, Tuomas Tynkkynen wrote: > Setting GPIO 21 high seems to be required to enable power to USB ports > on the WNDR3400v3. As there is already similar code for WNR3500L, > make the existing USB power GPIO code generic and use that. > > Signed-off-by: Tuomas Tynkkynen > --- > arch/mips/bcm47xx/workarounds.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) It'd be nice to see this stuff move towards DT, and configuring a GPIO to enable power doesn't seem so much a workaround as a normal expected part of operation. But I've applied this to mips-next for 4.20 since it doesn't really make things any worse for now... Thanks, Paul
Re: [PATCH] MIPS: Fix computation on entry point
Hi Philippe,
On Tue, Aug 28, 2018 at 05:52:50PM +0200, Philippe Reynes wrote:
> Since commit 27c524d17430 ("MIPS: Use the entry point from the ELF
> file header"), the kernel entry point is computed with a grep on
> "start address" on the output of objdump. It works fine when the
> default language is english but it may fail on other language (for
> example in French, the grep should be done on "adresse de départ").
D'oh!
> To fix this computation on most machine, I propose to force the
> language to english with "LC_ALL=C".
I wonder if it's time to bite the bullet & just write a little custom
program to do what we need, rather than trying to wrangle standard tools
that *almost* do what we need but not quite... Patch incoming.
Thanks,
Paul
Re: [PATCH] MIPS: Fix computation on entry point
Hi Philippe,
On Tue, Aug 28, 2018 at 05:52:50PM +0200, Philippe Reynes wrote:
> Since commit 27c524d17430 ("MIPS: Use the entry point from the ELF
> file header"), the kernel entry point is computed with a grep on
> "start address" on the output of objdump. It works fine when the
> default language is english but it may fail on other language (for
> example in French, the grep should be done on "adresse de départ").
D'oh!
> To fix this computation on most machine, I propose to force the
> language to english with "LC_ALL=C".
I wonder if it's time to bite the bullet & just write a little custom
program to do what we need, rather than trying to wrangle standard tools
that *almost* do what we need but not quite... Patch incoming.
Thanks,
Paul
Re: [PATCH] MIPS: Convert to using %pOFn instead of device_node.name
Hi Rob, On Mon, Aug 27, 2018 at 08:52:05PM -0500, Rob Herring wrote: > In preparation to remove the node name pointer from struct device_node, > convert printf users to use the %pOFn format specifier. > > Cc: Ralf Baechle > Cc: Paul Burton > Cc: James Hogan > Cc: John Crispin > Cc: linux-m...@linux-mips.org > Signed-off-by: Rob Herring > --- > arch/mips/cavium-octeon/octeon-irq.c | 16 > arch/mips/netlogic/common/irq.c | 14 +++--- > arch/mips/ralink/cevt-rt3352.c | 6 +++--- > arch/mips/ralink/ill_acc.c | 2 +- > 4 files changed, 19 insertions(+), 19 deletions(-) Thanks - applied to mips-next for 4.20. Paul
Re: [PATCH] MIPS: Convert to using %pOFn instead of device_node.name
Hi Rob, On Mon, Aug 27, 2018 at 08:52:05PM -0500, Rob Herring wrote: > In preparation to remove the node name pointer from struct device_node, > convert printf users to use the %pOFn format specifier. > > Cc: Ralf Baechle > Cc: Paul Burton > Cc: James Hogan > Cc: John Crispin > Cc: linux-m...@linux-mips.org > Signed-off-by: Rob Herring > --- > arch/mips/cavium-octeon/octeon-irq.c | 16 > arch/mips/netlogic/common/irq.c | 14 +++--- > arch/mips/ralink/cevt-rt3352.c | 6 +++--- > arch/mips/ralink/ill_acc.c | 2 +- > 4 files changed, 19 insertions(+), 19 deletions(-) Thanks - applied to mips-next for 4.20. Paul
[PATCH] pinctrl: ingenic: Fix group & function error checking
Commit a203728ac6bb ("pinctrl: core: Return selector to the pinctrl
driver") and commit f913cfce4ee4 ("pinctrl: pinmux: Return selector to
the pinctrl driver") modified the return values of
pinctrl_generic_add_group() and pinmux_generic_add_function()
respectively, but did so without updating their callers. This broke the
pinctrl-ingenic driver, which treats non-zero return values from these
functions as errors & fails to probe. For example on a MIPS Ci20:
pinctrl-ingenic 1001.pin-controller: Failed to register group uart0-hwflow
pinctrl-ingenic: probe of 1001.pin-controller failed with error 1
Without the pinctrl driver probed, other drivers go on to fail to probe
too & the system is unusable.
Fix this by modifying the error checks to treat only negative values as
errors, matching the commits that introduced the breakage & similar
changes made to other drivers.
Signed-off-by: Paul Burton
Fixes: a203728ac6bb ("pinctrl: core: Return selector to the pinctrl driver")
Fixes: f913cfce4ee4 ("pinctrl: pinmux: Return selector to the pinctrl driver")
Cc: Linus Walleij
Cc: Paul Cercueil
Cc: Tony Lindgren
Cc: linux-g...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pinctrl/pinctrl-ingenic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 6a1b6058b991..628817c40e3b 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -793,7 +793,7 @@ static int ingenic_pinctrl_probe(struct platform_device
*pdev)
err = pinctrl_generic_add_group(jzpc->pctl, group->name,
group->pins, group->num_pins, group->data);
- if (err) {
+ if (err < 0) {
dev_err(dev, "Failed to register group %s\n",
group->name);
return err;
@@ -806,7 +806,7 @@ static int ingenic_pinctrl_probe(struct platform_device
*pdev)
err = pinmux_generic_add_function(jzpc->pctl, func->name,
func->group_names, func->num_group_names,
func->data);
- if (err) {
+ if (err < 0) {
dev_err(dev, "Failed to register function %s\n",
func->name);
return err;
--
2.18.0
[PATCH] pinctrl: ingenic: Fix group & function error checking
Commit a203728ac6bb ("pinctrl: core: Return selector to the pinctrl
driver") and commit f913cfce4ee4 ("pinctrl: pinmux: Return selector to
the pinctrl driver") modified the return values of
pinctrl_generic_add_group() and pinmux_generic_add_function()
respectively, but did so without updating their callers. This broke the
pinctrl-ingenic driver, which treats non-zero return values from these
functions as errors & fails to probe. For example on a MIPS Ci20:
pinctrl-ingenic 1001.pin-controller: Failed to register group uart0-hwflow
pinctrl-ingenic: probe of 1001.pin-controller failed with error 1
Without the pinctrl driver probed, other drivers go on to fail to probe
too & the system is unusable.
Fix this by modifying the error checks to treat only negative values as
errors, matching the commits that introduced the breakage & similar
changes made to other drivers.
Signed-off-by: Paul Burton
Fixes: a203728ac6bb ("pinctrl: core: Return selector to the pinctrl driver")
Fixes: f913cfce4ee4 ("pinctrl: pinmux: Return selector to the pinctrl driver")
Cc: Linus Walleij
Cc: Paul Cercueil
Cc: Tony Lindgren
Cc: linux-g...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pinctrl/pinctrl-ingenic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 6a1b6058b991..628817c40e3b 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -793,7 +793,7 @@ static int ingenic_pinctrl_probe(struct platform_device
*pdev)
err = pinctrl_generic_add_group(jzpc->pctl, group->name,
group->pins, group->num_pins, group->data);
- if (err) {
+ if (err < 0) {
dev_err(dev, "Failed to register group %s\n",
group->name);
return err;
@@ -806,7 +806,7 @@ static int ingenic_pinctrl_probe(struct platform_device
*pdev)
err = pinmux_generic_add_function(jzpc->pctl, func->name,
func->group_names, func->num_group_names,
func->data);
- if (err) {
+ if (err < 0) {
dev_err(dev, "Failed to register function %s\n",
func->name);
return err;
--
2.18.0
Re: [PATCH v9 1/2] kbuild: Allow arch-specific asm/compiler.h
Hi Masahiro,
On Tue, Aug 21, 2018 at 11:49:48AM +0900, Masahiro Yamada wrote:
> The code diff looks good to me.
>
> Reviewed-by: Masahiro Yamada
Thanks :)
> > A straightforward approach to the per-arch header is to make use of
> > asm-generic to provide a default empty header & adjust architectures
> > which don't need anything specific to make use of that by adding the
> > header to generic-y. Unfortunately this doesn't work so well due to
> > commit a95b37e20db9 ("kbuild: get out of
> > ") which moved the inclusion of linux/compiler.h to
> > cflags using the -include compiler flag.
>
> I doubt this statement.
>
> Commit a95b37e20db9 is not the cause of the problem.
>
>%
>
> The change happened in commit 28128c61e08e.
You're correct - I'll fix that up.
> One more thing, you are not touching any makefile in this version.
>
> Maybe, you can prefix the subject with "compiler.h:" or something
> instead of "kbuild:".
Will do.
Thanks,
Paul
Re: [PATCH v9 1/2] kbuild: Allow arch-specific asm/compiler.h
Hi Masahiro,
On Tue, Aug 21, 2018 at 11:49:48AM +0900, Masahiro Yamada wrote:
> The code diff looks good to me.
>
> Reviewed-by: Masahiro Yamada
Thanks :)
> > A straightforward approach to the per-arch header is to make use of
> > asm-generic to provide a default empty header & adjust architectures
> > which don't need anything specific to make use of that by adding the
> > header to generic-y. Unfortunately this doesn't work so well due to
> > commit a95b37e20db9 ("kbuild: get out of
> > ") which moved the inclusion of linux/compiler.h to
> > cflags using the -include compiler flag.
>
> I doubt this statement.
>
> Commit a95b37e20db9 is not the cause of the problem.
>
>%
>
> The change happened in commit 28128c61e08e.
You're correct - I'll fix that up.
> One more thing, you are not touching any makefile in this version.
>
> Maybe, you can prefix the subject with "compiler.h:" or something
> instead of "kbuild:".
Will do.
Thanks,
Paul
[PATCH v9 1/2] kbuild: Allow arch-specific asm/compiler.h
We have a need to override the definition of
barrier_before_unreachable() for MIPS, which means we either need to add
architecture-specific code into linux/compiler-gcc.h or we need to allow
the architecture to provide a header that can define the macro before
the generic definition. The latter seems like the better approach.
A straightforward approach to the per-arch header is to make use of
asm-generic to provide a default empty header & adjust architectures
which don't need anything specific to make use of that by adding the
header to generic-y. Unfortunately this doesn't work so well due to
commit a95b37e20db9 ("kbuild: get out of
") which moved the inclusion of linux/compiler.h to
cflags using the -include compiler flag.
Because the -include flag is present for all C files we compile, we need
the architecture-provided header to be present before any C files are
compiled. If any C files can be compiled prior to the asm-generic header
wrappers being generated then we hit a build failure due to missing
header. Such cases do exist - one pointed out by the kbuild test robot
is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
of the archprepare target [1].
This leaves us with a few options:
1) Use generic-y & fix any build failures we find by enforcing
ordering such that the asm-generic target occurs before any C
compilation, such that linux/compiler_types.h can always include
the generated asm-generic wrapper which in turn includes the empty
asm-generic header. This would rely on us finding all the
problematic cases - I don't know for sure that the ia64 issue is
the only one.
2) Add an actual empty header to each architecture, so that we don't
need the generated asm-generic wrapper. This seems messy.
3) Give up & add #ifdef CONFIG_MIPS or similar to
linux/compiler_types.h. This seems messy too.
4) Include the arch header only when it's actually needed, removing
the need for the asm-generic wrapper for all other architectures.
This patch allows us to use approach 4, by including an asm/compiler.h
header from linux/compiler_types.h after the inclusion of the
compiler-specific linux/compiler-*.h header(s). We do this
conditionally, only when CONFIG_HAVE_ARCH_COMPILER_H is selected, in
order to avoid the need for asm-generic wrappers & the associated build
ordering issue described above. The asm/compiler.h header is included
after the generic linux/compiler-*.h header(s) for consistency with the
way linux/compiler-intel.h & linux/compiler-clang.h are included after
the linux/compiler-gcc.h header that they override.
[1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
Signed-off-by: Paul Burton
Cc: Arnd Bergmann
Cc: James Hogan
Cc: Masahiro Yamada
Cc: Ralf Baechle
Cc: linux-a...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
Changes in v9:
- Use Kconfig & a #include directive as Masahiro suggested.
- Go with asm/compiler.h rather than asm/compiler_types.h as it's really
definitions from linux/compiler-*.h that we want to override & the
conditional include means we don't need to worry about existing
asm/compiler.h headers.
- Tweak subject & commit message to reflect the changes above.
Changes in v8:
- New patch.
arch/Kconfig | 8
include/linux/compiler_types.h | 12
2 files changed, 20 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index c6148166a7b4..c0b56b0d86b0 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -841,6 +841,14 @@ config REFCOUNT_FULL
against various use-after-free conditions that can be used in
security flaw exploits.
+config HAVE_ARCH_COMPILER_H
+ bool
+ help
+ An architecture can select this if it provides an
+ asm/compiler.h header that should be included after
+ linux/compiler-*.h in order to override macro definitions that those
+ headers generally provide.
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index fbf337933fd8..66239549d240 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -78,6 +78,18 @@ extern void __chk_io_ptr(const volatile void __iomem *);
#include
#endif
+/*
+ * Some architectures need to provide custom definitions of macros provided
+ * by linux/compiler-*.h, and can do so using asm/compiler.h. We include that
+ * conditionally rather than using an asm-generic wrapper in order to avoid
+ * build failures if any C compilation, which will include this file via an
+ * -include argument in c_flags, occurs prior to the asm-generic wrappers being
+ * generated.
+ */
+#ifdef CONFIG_HAVE_ARCH_COMPILER_H
+#include
+#endif
+
/*
* Generic compiler-dependent macros required for kernel
* build go below this comment. Actual compiler/compiler version
--
2.18.0
[PATCH v9 2/2] MIPS: Workaround GCC __builtin_unreachable reordering bug
Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.
See this potential GCC fix for details:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):
Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.
This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.
That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.
Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:
arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA
mode
Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.
We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in
order to have this included by linux/compiler_types.h after
linux/compiler-gcc.h. This will result in asm/compiler.h being included
in all C compilations via the -include linux/compiler_types.h argument
in c_flags, which should be harmless.
Signed-off-by: Paul Burton
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Cc: James Hogan
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: linux-m...@linux-mips.org
---
Changes in v9:
- Move back to asm/compiler.h to match changes in patch 1.
- #undef before #define since we're now including this after
linux/compiler-gcc.h.
Changes in v8:
- Move to asm/compiler_types.h to suit patch 1.
- Commit message improvements.
- Drop James' SoB since this changed a fair bit since he added it.
Changes in v7:
- Elaborate on affected GCC versions in comment.
Changes in v6: None
Changes in v5:
- Comment & commit message tweaks.
Changes in v4: None
Changes in v3:
- Forward port to v4.17-rc and update commit message.
- Drop stable tag for now.
Changes in v2:
- Remove generic-y entry.
arch/mips/Kconfig| 1 +
arch/mips/include/asm/compiler.h | 35
2 files changed, 36 insertions(+)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2af13b162e5e..35511999156a 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -33,6 +33,7 @@ config MIPS
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
select HANDLE_DOMAIN_IRQ
+ select HAVE_ARCH_COMPILER_H
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_MMAP_RND_BITS if MMU
diff --git a/arch/mips/include/asm/compiler.h b/arch/mips/include/asm/compiler.h
index e081a
[PATCH v9 1/2] kbuild: Allow arch-specific asm/compiler.h
We have a need to override the definition of
barrier_before_unreachable() for MIPS, which means we either need to add
architecture-specific code into linux/compiler-gcc.h or we need to allow
the architecture to provide a header that can define the macro before
the generic definition. The latter seems like the better approach.
A straightforward approach to the per-arch header is to make use of
asm-generic to provide a default empty header & adjust architectures
which don't need anything specific to make use of that by adding the
header to generic-y. Unfortunately this doesn't work so well due to
commit a95b37e20db9 ("kbuild: get out of
") which moved the inclusion of linux/compiler.h to
cflags using the -include compiler flag.
Because the -include flag is present for all C files we compile, we need
the architecture-provided header to be present before any C files are
compiled. If any C files can be compiled prior to the asm-generic header
wrappers being generated then we hit a build failure due to missing
header. Such cases do exist - one pointed out by the kbuild test robot
is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
of the archprepare target [1].
This leaves us with a few options:
1) Use generic-y & fix any build failures we find by enforcing
ordering such that the asm-generic target occurs before any C
compilation, such that linux/compiler_types.h can always include
the generated asm-generic wrapper which in turn includes the empty
asm-generic header. This would rely on us finding all the
problematic cases - I don't know for sure that the ia64 issue is
the only one.
2) Add an actual empty header to each architecture, so that we don't
need the generated asm-generic wrapper. This seems messy.
3) Give up & add #ifdef CONFIG_MIPS or similar to
linux/compiler_types.h. This seems messy too.
4) Include the arch header only when it's actually needed, removing
the need for the asm-generic wrapper for all other architectures.
This patch allows us to use approach 4, by including an asm/compiler.h
header from linux/compiler_types.h after the inclusion of the
compiler-specific linux/compiler-*.h header(s). We do this
conditionally, only when CONFIG_HAVE_ARCH_COMPILER_H is selected, in
order to avoid the need for asm-generic wrappers & the associated build
ordering issue described above. The asm/compiler.h header is included
after the generic linux/compiler-*.h header(s) for consistency with the
way linux/compiler-intel.h & linux/compiler-clang.h are included after
the linux/compiler-gcc.h header that they override.
[1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
Signed-off-by: Paul Burton
Cc: Arnd Bergmann
Cc: James Hogan
Cc: Masahiro Yamada
Cc: Ralf Baechle
Cc: linux-a...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
Changes in v9:
- Use Kconfig & a #include directive as Masahiro suggested.
- Go with asm/compiler.h rather than asm/compiler_types.h as it's really
definitions from linux/compiler-*.h that we want to override & the
conditional include means we don't need to worry about existing
asm/compiler.h headers.
- Tweak subject & commit message to reflect the changes above.
Changes in v8:
- New patch.
arch/Kconfig | 8
include/linux/compiler_types.h | 12
2 files changed, 20 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index c6148166a7b4..c0b56b0d86b0 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -841,6 +841,14 @@ config REFCOUNT_FULL
against various use-after-free conditions that can be used in
security flaw exploits.
+config HAVE_ARCH_COMPILER_H
+ bool
+ help
+ An architecture can select this if it provides an
+ asm/compiler.h header that should be included after
+ linux/compiler-*.h in order to override macro definitions that those
+ headers generally provide.
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index fbf337933fd8..66239549d240 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -78,6 +78,18 @@ extern void __chk_io_ptr(const volatile void __iomem *);
#include
#endif
+/*
+ * Some architectures need to provide custom definitions of macros provided
+ * by linux/compiler-*.h, and can do so using asm/compiler.h. We include that
+ * conditionally rather than using an asm-generic wrapper in order to avoid
+ * build failures if any C compilation, which will include this file via an
+ * -include argument in c_flags, occurs prior to the asm-generic wrappers being
+ * generated.
+ */
+#ifdef CONFIG_HAVE_ARCH_COMPILER_H
+#include
+#endif
+
/*
* Generic compiler-dependent macros required for kernel
* build go below this comment. Actual compiler/compiler version
--
2.18.0
[PATCH v9 2/2] MIPS: Workaround GCC __builtin_unreachable reordering bug
Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.
See this potential GCC fix for details:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):
Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.
This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.
That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.
Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:
arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA
mode
Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.
We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in
order to have this included by linux/compiler_types.h after
linux/compiler-gcc.h. This will result in asm/compiler.h being included
in all C compilations via the -include linux/compiler_types.h argument
in c_flags, which should be harmless.
Signed-off-by: Paul Burton
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Cc: James Hogan
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: linux-m...@linux-mips.org
---
Changes in v9:
- Move back to asm/compiler.h to match changes in patch 1.
- #undef before #define since we're now including this after
linux/compiler-gcc.h.
Changes in v8:
- Move to asm/compiler_types.h to suit patch 1.
- Commit message improvements.
- Drop James' SoB since this changed a fair bit since he added it.
Changes in v7:
- Elaborate on affected GCC versions in comment.
Changes in v6: None
Changes in v5:
- Comment & commit message tweaks.
Changes in v4: None
Changes in v3:
- Forward port to v4.17-rc and update commit message.
- Drop stable tag for now.
Changes in v2:
- Remove generic-y entry.
arch/mips/Kconfig| 1 +
arch/mips/include/asm/compiler.h | 35
2 files changed, 36 insertions(+)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2af13b162e5e..35511999156a 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -33,6 +33,7 @@ config MIPS
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
select HANDLE_DOMAIN_IRQ
+ select HAVE_ARCH_COMPILER_H
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_MMAP_RND_BITS if MMU
diff --git a/arch/mips/include/asm/compiler.h b/arch/mips/include/asm/compiler.h
index e081a
[PATCH v9 0/2] MIPS: Override barrier_before_unreachable() to fix microMIPS
This series overrides barrier_before_unreachable() for MIPS to add a .insn assembler directive. Due to the subsequent __builtin_unreachable(), the assembler can't tell that a label on the empty inline asm is code rather than data, so any microMIPS branches targeting it (which sadly can't be removed) raise errors due to the mismatching ISA mode, Adding the .insn in patch 2 tells the assembler that it should be treated as code. Applies cleanly atop v4.18. Changes in v9 (Paul): - Use a simple #include conditional upon a Kconfig symbol, as suggested by Masahiro. - Move back to asm/compiler.h instead of asm/compiler_types.h. Changes in v8 (Paul): - Try something different... including a header that might be an asm-generic wrapper in linux/compiler_types.h creates build ordering problems for any C file which can be built before the asm-generic target. Patch 1 changes tact to avoid asm-generic & the ordering problem. - Commit message improvements in patch 2. Changes in v7 (Paul): - Elaborate on affected GCC versions in patch 4. Changes in v6 (Paul): - Fix patch 2 to find the generated headers in $(objtree). - Remove CC's for defunct MIPS email addresses (Matthew & Robert). - CC linux...@lists.infradead.org. Changes in v5 (Paul): - Rebase atop v4.18-rc8. - Comment & commit message tweaks. - Add SPDX-License-Identifier to asm-generic/compiler.h. Changes in v4 (James): - Fix asm-generic/compiler.h include from check, compiler_types.h is included on the command line so linux/compiler.h may not be included (kbuild test robot). - New patch 2 to fix um (kbuild test robot). Changes in v3 (James): - New patch 1. - Rebase after 4.17 arch removal and update commit messages. - Use asm/compiler.h instead of compiler-gcc.h (Arnd). - Drop stable tag for now. Changes in v2 (Paul): - Add generic-y entries to arch Kbuild files. Oops! Previous versions: v1: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00399.html v2: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00401.html v3: https://lkml.org/lkml/2018/4/17/228 v4: https://www.linux-mips.org/archives/linux-mips/2018-05/msg00069.html v5: https://www.spinics.net/lists/mips/msg74408.html v6: https://www.spinics.net/lists/mips/msg74425.html v7: https://www.spinics.net/lists/linux-arch/msg47934.html v8: https://www.spinics.net/lists/mips/msg74562.html Older #ifdef-based attempt: https://marc.info/?l=linux-mips=14921408274=2 Paul Burton (2): kbuild: Allow arch-specific asm/compiler.h MIPS: Workaround GCC __builtin_unreachable reordering bug arch/Kconfig | 8 arch/mips/Kconfig| 1 + arch/mips/include/asm/compiler.h | 35 include/linux/compiler_types.h | 12 +++ 4 files changed, 56 insertions(+) -- 2.18.0
[PATCH v9 0/2] MIPS: Override barrier_before_unreachable() to fix microMIPS
This series overrides barrier_before_unreachable() for MIPS to add a .insn assembler directive. Due to the subsequent __builtin_unreachable(), the assembler can't tell that a label on the empty inline asm is code rather than data, so any microMIPS branches targeting it (which sadly can't be removed) raise errors due to the mismatching ISA mode, Adding the .insn in patch 2 tells the assembler that it should be treated as code. Applies cleanly atop v4.18. Changes in v9 (Paul): - Use a simple #include conditional upon a Kconfig symbol, as suggested by Masahiro. - Move back to asm/compiler.h instead of asm/compiler_types.h. Changes in v8 (Paul): - Try something different... including a header that might be an asm-generic wrapper in linux/compiler_types.h creates build ordering problems for any C file which can be built before the asm-generic target. Patch 1 changes tact to avoid asm-generic & the ordering problem. - Commit message improvements in patch 2. Changes in v7 (Paul): - Elaborate on affected GCC versions in patch 4. Changes in v6 (Paul): - Fix patch 2 to find the generated headers in $(objtree). - Remove CC's for defunct MIPS email addresses (Matthew & Robert). - CC linux...@lists.infradead.org. Changes in v5 (Paul): - Rebase atop v4.18-rc8. - Comment & commit message tweaks. - Add SPDX-License-Identifier to asm-generic/compiler.h. Changes in v4 (James): - Fix asm-generic/compiler.h include from check, compiler_types.h is included on the command line so linux/compiler.h may not be included (kbuild test robot). - New patch 2 to fix um (kbuild test robot). Changes in v3 (James): - New patch 1. - Rebase after 4.17 arch removal and update commit messages. - Use asm/compiler.h instead of compiler-gcc.h (Arnd). - Drop stable tag for now. Changes in v2 (Paul): - Add generic-y entries to arch Kbuild files. Oops! Previous versions: v1: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00399.html v2: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00401.html v3: https://lkml.org/lkml/2018/4/17/228 v4: https://www.linux-mips.org/archives/linux-mips/2018-05/msg00069.html v5: https://www.spinics.net/lists/mips/msg74408.html v6: https://www.spinics.net/lists/mips/msg74425.html v7: https://www.spinics.net/lists/linux-arch/msg47934.html v8: https://www.spinics.net/lists/mips/msg74562.html Older #ifdef-based attempt: https://marc.info/?l=linux-mips=14921408274=2 Paul Burton (2): kbuild: Allow arch-specific asm/compiler.h MIPS: Workaround GCC __builtin_unreachable reordering bug arch/Kconfig | 8 arch/mips/Kconfig| 1 + arch/mips/include/asm/compiler.h | 35 include/linux/compiler_types.h | 12 +++ 4 files changed, 56 insertions(+) -- 2.18.0
Re: [PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h
Hi Masahiro,
On Mon, Aug 20, 2018 at 02:04:24PM +0900, Masahiro Yamada wrote:
> 2018-08-19 3:10 GMT+09:00 Paul Burton :
> > We have a need to override the definition of
> > barrier_before_unreachable() for MIPS, which means we either need to add
> > architecture-specific code into linux/compiler-gcc.h or we need to allow
> > the architecture to provide a header that can define the macro before
> > the generic definition. The latter seems like the better approach.
> >
> > A straightforward approach to the per-arch header is to make use of
> > asm-generic to provide a default empty header & adjust architectures
> > which don't need anything specific to make use of that by adding the
> > header to generic-y. Unfortunately this doesn't work so well due to
> > commit a95b37e20db9 ("kbuild: get out of
> > ") which moved the inclusion of linux/compiler.h to
> > cflags using the -include compiler flag.
> >
> > Because the -include flag is present for all C files we compile, we need
> > the architecture-provided header to be present before any C files are
> > compiled. If any C files can be compiled prior to the asm-generic header
> > wrappers being generated then we hit a build failure due to missing
> > header. Such cases do exist - one pointed out by the kbuild test robot
> > is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
> > of the archprepare target [1].
> >
> > This leaves us with a few options:
> >
> > 1) Use generic-y & fix any build failures we find by enforcing
> > ordering such that the asm-generic target occurs before any C
> > compilation, such that linux/compiler_types.h can always include
> > the generated asm-generic wrapper which in turn includes the empty
> > asm-generic header. This would rely on us finding all the
> > problematic cases - I don't know for sure that the ia64 issue is
> > the only one.
> >
> > 2) Add an actual empty header to each architecture, so that we don't
> > need the generated asm-generic wrapper. This seems messy.
> >
> > 3) Give up & add #ifdef CONFIG_MIPS or similar to
> > linux/compiler_types.h. This seems messy too.
> >
> > 4) Include the arch header only when it's actually needed, removing
> > the need for the asm-generic wrapper for all other architectures.
> >
> > This patch allows us to use approach 4, by including an
> > asm/compiler_types.h header using the -include flag in the same way we
> > do for linux/compiler_types.h, but only if the header actually exists.
>
> I agree with the approach 4),
> but I am of two minds about how to implement it.
>
> I guess the cost of evaluating 'wildcard' for each C file
> is unnoticeable level, but I am slightly in favor of
> including from
> conditionally.
>
> I am not sure about the CONFIG name, but for example, like this.
>
> #ifdef CONFIG_HAVE_ARCH_COMPILER_TYPES
> #include
> #endif
>
> What do you think?
That sounds fine to me - I'll submit a v9 shortly :)
Thanks,
Paul
Re: [PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h
Hi Masahiro,
On Mon, Aug 20, 2018 at 02:04:24PM +0900, Masahiro Yamada wrote:
> 2018-08-19 3:10 GMT+09:00 Paul Burton :
> > We have a need to override the definition of
> > barrier_before_unreachable() for MIPS, which means we either need to add
> > architecture-specific code into linux/compiler-gcc.h or we need to allow
> > the architecture to provide a header that can define the macro before
> > the generic definition. The latter seems like the better approach.
> >
> > A straightforward approach to the per-arch header is to make use of
> > asm-generic to provide a default empty header & adjust architectures
> > which don't need anything specific to make use of that by adding the
> > header to generic-y. Unfortunately this doesn't work so well due to
> > commit a95b37e20db9 ("kbuild: get out of
> > ") which moved the inclusion of linux/compiler.h to
> > cflags using the -include compiler flag.
> >
> > Because the -include flag is present for all C files we compile, we need
> > the architecture-provided header to be present before any C files are
> > compiled. If any C files can be compiled prior to the asm-generic header
> > wrappers being generated then we hit a build failure due to missing
> > header. Such cases do exist - one pointed out by the kbuild test robot
> > is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
> > of the archprepare target [1].
> >
> > This leaves us with a few options:
> >
> > 1) Use generic-y & fix any build failures we find by enforcing
> > ordering such that the asm-generic target occurs before any C
> > compilation, such that linux/compiler_types.h can always include
> > the generated asm-generic wrapper which in turn includes the empty
> > asm-generic header. This would rely on us finding all the
> > problematic cases - I don't know for sure that the ia64 issue is
> > the only one.
> >
> > 2) Add an actual empty header to each architecture, so that we don't
> > need the generated asm-generic wrapper. This seems messy.
> >
> > 3) Give up & add #ifdef CONFIG_MIPS or similar to
> > linux/compiler_types.h. This seems messy too.
> >
> > 4) Include the arch header only when it's actually needed, removing
> > the need for the asm-generic wrapper for all other architectures.
> >
> > This patch allows us to use approach 4, by including an
> > asm/compiler_types.h header using the -include flag in the same way we
> > do for linux/compiler_types.h, but only if the header actually exists.
>
> I agree with the approach 4),
> but I am of two minds about how to implement it.
>
> I guess the cost of evaluating 'wildcard' for each C file
> is unnoticeable level, but I am slightly in favor of
> including from
> conditionally.
>
> I am not sure about the CONFIG name, but for example, like this.
>
> #ifdef CONFIG_HAVE_ARCH_COMPILER_TYPES
> #include
> #endif
>
> What do you think?
That sounds fine to me - I'll submit a v9 shortly :)
Thanks,
Paul
[PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h
We have a need to override the definition of
barrier_before_unreachable() for MIPS, which means we either need to add
architecture-specific code into linux/compiler-gcc.h or we need to allow
the architecture to provide a header that can define the macro before
the generic definition. The latter seems like the better approach.
A straightforward approach to the per-arch header is to make use of
asm-generic to provide a default empty header & adjust architectures
which don't need anything specific to make use of that by adding the
header to generic-y. Unfortunately this doesn't work so well due to
commit a95b37e20db9 ("kbuild: get out of
") which moved the inclusion of linux/compiler.h to
cflags using the -include compiler flag.
Because the -include flag is present for all C files we compile, we need
the architecture-provided header to be present before any C files are
compiled. If any C files can be compiled prior to the asm-generic header
wrappers being generated then we hit a build failure due to missing
header. Such cases do exist - one pointed out by the kbuild test robot
is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
of the archprepare target [1].
This leaves us with a few options:
1) Use generic-y & fix any build failures we find by enforcing
ordering such that the asm-generic target occurs before any C
compilation, such that linux/compiler_types.h can always include
the generated asm-generic wrapper which in turn includes the empty
asm-generic header. This would rely on us finding all the
problematic cases - I don't know for sure that the ia64 issue is
the only one.
2) Add an actual empty header to each architecture, so that we don't
need the generated asm-generic wrapper. This seems messy.
3) Give up & add #ifdef CONFIG_MIPS or similar to
linux/compiler_types.h. This seems messy too.
4) Include the arch header only when it's actually needed, removing
the need for the asm-generic wrapper for all other architectures.
This patch allows us to use approach 4, by including an
asm/compiler_types.h header using the -include flag in the same way we
do for linux/compiler_types.h, but only if the header actually exists.
[1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
Signed-off-by: Paul Burton
Cc: Arnd Bergmann
Cc: James Hogan
Cc: Masahiro Yamada
Cc: Ralf Baechle
Cc: linux-a...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
Any thoughts anyone?
This isn't the prettiest it could possibly be but it's a small change &
clearly shouldn't break anything, which are good qualities for a patch
fixing build failures that we'd ideally backport as far as 4.16.
Changes in v8:
- New patch.
scripts/Makefile.lib | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 1bb594fcfe12..4e7b41ef029b 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -151,8 +151,11 @@ __a_flags = $(call flags,_a_flags)
__cpp_flags = $(call flags,_cpp_flags)
endif
+c_includes = $(wildcard
$(srctree)/arch/$(SRCARCH)/include/asm/compiler_types.h)
+c_includes += $(srctree)/include/linux/compiler_types.h
+
c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
--include $(srctree)/include/linux/compiler_types.h \
+$(addprefix -include ,$(c_includes)) \
$(__c_flags) $(modkern_cflags) \
$(basename_flags) $(modname_flags)
--
2.18.0
[PATCH v8 2/2] MIPS: Workaround GCC __builtin_unreachable reordering bug
Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.
See this potential GCC fix for details:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):
Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.
This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.
That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.
Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:
arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA
mode
Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.
Signed-off-by: Paul Burton
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Cc: James Hogan
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: linux-m...@linux-mips.org
---
Changes in v8:
- Move to asm/compiler_types.h to suit patch 1.
- Commit message improvements.
- Drop James' SoB since this changed a fair bit since he added it.
Changes in v7:
- Elaborate on affected GCC versions in comment.
Changes in v6: None
Changes in v5:
- Comment & commit message tweaks.
Changes in v4: None
Changes in v3:
- Forward port to v4.17-rc and update commit message.
- Drop stable tag for now.
Changes in v2:
- Remove generic-y entry.
arch/mips/include/asm/compiler_types.h | 39 ++
include/linux/compiler-gcc.h | 2 ++
2 files changed, 41 insertions(+)
create mode 100644 arch/mips/include/asm/compiler_types.h
diff --git a/arch/mips/include/asm/compiler_types.h
b/arch/mips/include/asm/compiler_types.h
new file mode 100644
index ..cecd5dc48ce2
--- /dev/null
+++ b/arch/mips/include/asm/compiler_types.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_COMPILER_TYPES_H__
+#define __ASM_COMPILER_TYPES_H__
+
+/*
+ * With GCC 4.5 onwards we can use __builtin_unreachable to indicate to the
+ * compiler that a particular code path will never be hit. This allows it to be
+ * optimised out of the generated binary.
+ *
+ * Unfortunately at least GCC 4.6.3 through 7.3.0 inclusive suffer from a bug
+ * that can lead to instructions from beyond an unreachable statement being
+ * incorrectly reordered into earlier delay slots if the unreachable statement
+ * is the only content of a case in a switch statement. This can lead to
+ * seemingly random behaviour, such as invalid memory accesses from incorre
[PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h
We have a need to override the definition of
barrier_before_unreachable() for MIPS, which means we either need to add
architecture-specific code into linux/compiler-gcc.h or we need to allow
the architecture to provide a header that can define the macro before
the generic definition. The latter seems like the better approach.
A straightforward approach to the per-arch header is to make use of
asm-generic to provide a default empty header & adjust architectures
which don't need anything specific to make use of that by adding the
header to generic-y. Unfortunately this doesn't work so well due to
commit a95b37e20db9 ("kbuild: get out of
") which moved the inclusion of linux/compiler.h to
cflags using the -include compiler flag.
Because the -include flag is present for all C files we compile, we need
the architecture-provided header to be present before any C files are
compiled. If any C files can be compiled prior to the asm-generic header
wrappers being generated then we hit a build failure due to missing
header. Such cases do exist - one pointed out by the kbuild test robot
is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
of the archprepare target [1].
This leaves us with a few options:
1) Use generic-y & fix any build failures we find by enforcing
ordering such that the asm-generic target occurs before any C
compilation, such that linux/compiler_types.h can always include
the generated asm-generic wrapper which in turn includes the empty
asm-generic header. This would rely on us finding all the
problematic cases - I don't know for sure that the ia64 issue is
the only one.
2) Add an actual empty header to each architecture, so that we don't
need the generated asm-generic wrapper. This seems messy.
3) Give up & add #ifdef CONFIG_MIPS or similar to
linux/compiler_types.h. This seems messy too.
4) Include the arch header only when it's actually needed, removing
the need for the asm-generic wrapper for all other architectures.
This patch allows us to use approach 4, by including an
asm/compiler_types.h header using the -include flag in the same way we
do for linux/compiler_types.h, but only if the header actually exists.
[1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
Signed-off-by: Paul Burton
Cc: Arnd Bergmann
Cc: James Hogan
Cc: Masahiro Yamada
Cc: Ralf Baechle
Cc: linux-a...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
Any thoughts anyone?
This isn't the prettiest it could possibly be but it's a small change &
clearly shouldn't break anything, which are good qualities for a patch
fixing build failures that we'd ideally backport as far as 4.16.
Changes in v8:
- New patch.
scripts/Makefile.lib | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 1bb594fcfe12..4e7b41ef029b 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -151,8 +151,11 @@ __a_flags = $(call flags,_a_flags)
__cpp_flags = $(call flags,_cpp_flags)
endif
+c_includes = $(wildcard
$(srctree)/arch/$(SRCARCH)/include/asm/compiler_types.h)
+c_includes += $(srctree)/include/linux/compiler_types.h
+
c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
--include $(srctree)/include/linux/compiler_types.h \
+$(addprefix -include ,$(c_includes)) \
$(__c_flags) $(modkern_cflags) \
$(basename_flags) $(modname_flags)
--
2.18.0
[PATCH v8 2/2] MIPS: Workaround GCC __builtin_unreachable reordering bug
Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.
See this potential GCC fix for details:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):
Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.
This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.
That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.
Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:
arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA
mode
Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.
Signed-off-by: Paul Burton
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Cc: James Hogan
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: linux-m...@linux-mips.org
---
Changes in v8:
- Move to asm/compiler_types.h to suit patch 1.
- Commit message improvements.
- Drop James' SoB since this changed a fair bit since he added it.
Changes in v7:
- Elaborate on affected GCC versions in comment.
Changes in v6: None
Changes in v5:
- Comment & commit message tweaks.
Changes in v4: None
Changes in v3:
- Forward port to v4.17-rc and update commit message.
- Drop stable tag for now.
Changes in v2:
- Remove generic-y entry.
arch/mips/include/asm/compiler_types.h | 39 ++
include/linux/compiler-gcc.h | 2 ++
2 files changed, 41 insertions(+)
create mode 100644 arch/mips/include/asm/compiler_types.h
diff --git a/arch/mips/include/asm/compiler_types.h
b/arch/mips/include/asm/compiler_types.h
new file mode 100644
index ..cecd5dc48ce2
--- /dev/null
+++ b/arch/mips/include/asm/compiler_types.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_COMPILER_TYPES_H__
+#define __ASM_COMPILER_TYPES_H__
+
+/*
+ * With GCC 4.5 onwards we can use __builtin_unreachable to indicate to the
+ * compiler that a particular code path will never be hit. This allows it to be
+ * optimised out of the generated binary.
+ *
+ * Unfortunately at least GCC 4.6.3 through 7.3.0 inclusive suffer from a bug
+ * that can lead to instructions from beyond an unreachable statement being
+ * incorrectly reordered into earlier delay slots if the unreachable statement
+ * is the only content of a case in a switch statement. This can lead to
+ * seemingly random behaviour, such as invalid memory accesses from incorre
[PATCH v8 0/2] MIPS: Override barrier_before_unreachable() to fix microMIPS
This series overrides barrier_before_unreachable() for MIPS to add a .insn assembler directive. Due to the subsequent __builtin_unreachable(), the assembler can't tell that a label on the empty inline asm is code rather than data, so any microMIPS branches targeting it (which sadly can't be removed) raise errors due to the mismatching ISA mode, Adding the .insn in patch 2 tells the assembler that it should be treated as code. Applies cleanly atop v4.18. Changes in v8 (Paul): - Try something different... including a header that might be an asm-generic wrapper in linux/compiler_types.h creates build ordering problems for any C file which can be built before the asm-generic target. Patch 1 changes tact to avoid asm-generic & the ordering problem. - Commit message improvements in patch 2. Changes in v7 (Paul): - Elaborate on affected GCC versions in patch 4. Changes in v6 (Paul): - Fix patch 2 to find the generated headers in $(objtree). - Remove CC's for defunct MIPS email addresses (Matthew & Robert). - CC linux...@lists.infradead.org. Changes in v5 (Paul): - Rebase atop v4.18-rc8. - Comment & commit message tweaks. - Add SPDX-License-Identifier to asm-generic/compiler.h. Changes in v4 (James): - Fix asm-generic/compiler.h include from check, compiler_types.h is included on the command line so linux/compiler.h may not be included (kbuild test robot). - New patch 2 to fix um (kbuild test robot). Changes in v3 (James): - New patch 1. - Rebase after 4.17 arch removal and update commit messages. - Use asm/compiler.h instead of compiler-gcc.h (Arnd). - Drop stable tag for now. Changes in v2 (Paul): - Add generic-y entries to arch Kbuild files. Oops! Previous versions: v1: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00399.html v2: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00401.html v3: https://lkml.org/lkml/2018/4/17/228 v4: https://www.linux-mips.org/archives/linux-mips/2018-05/msg00069.html v5: https://www.spinics.net/lists/mips/msg74408.html v6: https://www.spinics.net/lists/mips/msg74425.html v7: https://www.spinics.net/lists/linux-arch/msg47934.html Older #ifdef-based attempt: https://marc.info/?l=linux-mips=14921408274=2 Paul Burton (2): kbuild: Allow asm-specific compiler_types.h MIPS: Workaround GCC __builtin_unreachable reordering bug arch/mips/include/asm/compiler_types.h | 39 ++ include/linux/compiler-gcc.h | 2 ++ scripts/Makefile.lib | 5 +++- 3 files changed, 45 insertions(+), 1 deletion(-) create mode 100644 arch/mips/include/asm/compiler_types.h -- 2.18.0
[PATCH v8 0/2] MIPS: Override barrier_before_unreachable() to fix microMIPS
This series overrides barrier_before_unreachable() for MIPS to add a .insn assembler directive. Due to the subsequent __builtin_unreachable(), the assembler can't tell that a label on the empty inline asm is code rather than data, so any microMIPS branches targeting it (which sadly can't be removed) raise errors due to the mismatching ISA mode, Adding the .insn in patch 2 tells the assembler that it should be treated as code. Applies cleanly atop v4.18. Changes in v8 (Paul): - Try something different... including a header that might be an asm-generic wrapper in linux/compiler_types.h creates build ordering problems for any C file which can be built before the asm-generic target. Patch 1 changes tact to avoid asm-generic & the ordering problem. - Commit message improvements in patch 2. Changes in v7 (Paul): - Elaborate on affected GCC versions in patch 4. Changes in v6 (Paul): - Fix patch 2 to find the generated headers in $(objtree). - Remove CC's for defunct MIPS email addresses (Matthew & Robert). - CC linux...@lists.infradead.org. Changes in v5 (Paul): - Rebase atop v4.18-rc8. - Comment & commit message tweaks. - Add SPDX-License-Identifier to asm-generic/compiler.h. Changes in v4 (James): - Fix asm-generic/compiler.h include from check, compiler_types.h is included on the command line so linux/compiler.h may not be included (kbuild test robot). - New patch 2 to fix um (kbuild test robot). Changes in v3 (James): - New patch 1. - Rebase after 4.17 arch removal and update commit messages. - Use asm/compiler.h instead of compiler-gcc.h (Arnd). - Drop stable tag for now. Changes in v2 (Paul): - Add generic-y entries to arch Kbuild files. Oops! Previous versions: v1: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00399.html v2: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00401.html v3: https://lkml.org/lkml/2018/4/17/228 v4: https://www.linux-mips.org/archives/linux-mips/2018-05/msg00069.html v5: https://www.spinics.net/lists/mips/msg74408.html v6: https://www.spinics.net/lists/mips/msg74425.html v7: https://www.spinics.net/lists/linux-arch/msg47934.html Older #ifdef-based attempt: https://marc.info/?l=linux-mips=14921408274=2 Paul Burton (2): kbuild: Allow asm-specific compiler_types.h MIPS: Workaround GCC __builtin_unreachable reordering bug arch/mips/include/asm/compiler_types.h | 39 ++ include/linux/compiler-gcc.h | 2 ++ scripts/Makefile.lib | 5 +++- 3 files changed, 45 insertions(+), 1 deletion(-) create mode 100644 arch/mips/include/asm/compiler_types.h -- 2.18.0
Re: [PATCH] mips: switch to NO_BOOTMEM
Hi Sergey & Mike, On Thu, Aug 09, 2018 at 12:30:03AM +0300, Fancer's opinion wrote: > Hello Mike, > I haven't read your patch text yet. I am waiting for the subsystem > maintainers response at least > about the necessity to have this type of changes being merged into the > sources (I mean > memblock/no-bootmem alteration). If they find it pointless (although I > would strongly disagree), then > nothing to discuss. Otherwise we can come up with a solution. > > -Sergey I'm all for dropping bootmem. It's too late for something this invasive in 4.19, but I'd love to get it into 4.20. Thanks, Paul
Re: [PATCH] mips: switch to NO_BOOTMEM
Hi Sergey & Mike, On Thu, Aug 09, 2018 at 12:30:03AM +0300, Fancer's opinion wrote: > Hello Mike, > I haven't read your patch text yet. I am waiting for the subsystem > maintainers response at least > about the necessity to have this type of changes being merged into the > sources (I mean > memblock/no-bootmem alteration). If they find it pointless (although I > would strongly disagree), then > nothing to discuss. Otherwise we can come up with a solution. > > -Sergey I'm all for dropping bootmem. It's too late for something this invasive in 4.19, but I'd love to get it into 4.20. Thanks, Paul
Re: [PATCH v2 01/18] MIPS: intel: Add initial support for Intel MIPS SoCs
Hi Songjun / Hua, On Fri, Aug 03, 2018 at 11:02:20AM +0800, Songjun Wu wrote: > From: Hua Ma > > Add initial support for Intel MIPS interAptiv SoCs made by Intel. > This series will add support for the grx500 family. > > The series allows booting a minimal system using a initramfs. Thanks for submitting this - I have some comments below. > diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms > index ac7ad54f984f..bcd647060f3e 100644 > --- a/arch/mips/Kbuild.platforms > +++ b/arch/mips/Kbuild.platforms > @@ -12,6 +12,7 @@ platforms += cobalt > platforms += dec > platforms += emma > platforms += generic > +platforms += intel-mips > platforms += jazz > platforms += jz4740 > platforms += lantiq Oh EVA, why must you ruin nice things... Ideally I'd be suggesting that we use the generic platform but it doesn't yet have a nice way to deal with non-standard EVA setups. It would be good if we could make sure that's the only reason for your custom platform though, so that once generic does support EVA we can migrate your system over. Most notably, it would be good to make use of the UHI-specified boot protocol if possible (ie. $r4==-2, $r5==). It looks like your prom_init_cmdline() supports multiple boot protocols - could you clarify which is actually used? > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 08c10c518f83..2d34f17f3e24 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -409,6 +409,34 @@ config LANTIQ > select ARCH_HAS_RESET_CONTROLLER > select RESET_CONTROLLER > > +config INTEL_MIPS > + bool "Intel MIPS interAptiv SoC based platforms" > + select BOOT_RAW > + select CEVT_R4K > + select COMMON_CLK > + select CPU_MIPS32_3_5_EVA > + select CPU_MIPS32_3_5_FEATURES > + select CPU_MIPSR2_IRQ_EI > + select CPU_MIPSR2_IRQ_VI > + select CSRC_R4K > + select DMA_NONCOHERENT > + select GENERIC_ISA_DMA > + select IRQ_MIPS_CPU > + select MFD_CORE > + select MFD_SYSCON > + select MIPS_CPU_SCACHE > + select MIPS_GIC > + select SYS_HAS_CPU_MIPS32_R1 For a system based on interAptiv you should never need to build a MIPS32r1 kernel, so you should remove the above select. > diff --git a/arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h > b/arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h > new file mode 100644 > index ..ac5f3b943d2a > --- /dev/null > +++ b/arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h > @@ -0,0 +1,61 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * This file was derived from: include/asm-mips/cpu-features.h > + * Copyright (C) 2003, 2004 Ralf Baechle > + * Copyright (C) 2004 Maciej W. Rozycki > + * Copyright (C) 2018 Intel Corporation. > + */ > + > +#ifndef __ASM_MACH_INTEL_MIPS_CPU_FEATURE_OVERRIDES_H > +#define __ASM_MACH_INTEL_MIPS_CPU_FEATURE_OVERRIDES_H > + > +#define cpu_has_tlb 1 > +#define cpu_has_4kex 1 > +#define cpu_has_3k_cache 0 > +#define cpu_has_4k_cache 1 > +#define cpu_has_tx39_cache 0 > +#define cpu_has_sb1_cache0 > +#define cpu_has_fpu 0 > +#define cpu_has_32fpr0 > +#define cpu_has_counter 1 > +#define cpu_has_watch1 > +#define cpu_has_divec1 > + > +#define cpu_has_prefetch 1 > +#define cpu_has_ejtag1 > +#define cpu_has_llsc 1 > + > +#define cpu_has_mips16 0 > +#define cpu_has_mdmx 0 > +#define cpu_has_mips3d 0 > +#define cpu_has_smartmips0 > +#define cpu_has_mmips0 > +#define cpu_has_vz 0 > + > +#define cpu_has_mips32r1 1 > +#define cpu_has_mips32r2 1 > +#define cpu_has_mips64r1 0 > +#define cpu_has_mips64r2 0 > + > +#define cpu_has_dsp 1 > +#define cpu_has_dsp2 0 > +#define cpu_has_mipsmt 1 > + > +#define cpu_has_vint 1 > +#define cpu_has_veic 0 > + > +#define cpu_has_64bits 0 > +#define cpu_has_64bit_zero_reg 0 > +#define cpu_has_64bit_gp_regs0 > +#define cpu_has_64bit_addresses 0 > + > +#define cpu_has_cm2 1 > +#define cpu_has_cm2_l2sync 1 > +#define cpu_has_eva 1 > +#define cpu_has_tlbinv 1 > + > +#define cpu_dcache_line_size() 32 > +#define cpu_icache_line_size() 32 > +#define cpu_scache_line_size() 32 If you rebase atop linux-next or mips-next then you should find that many of these defines are now redundant, especially after removing the SYS_HAS_CPU_MIPS32_R1 select which means your kernel build will always target MIPS32r2. Due to architectural restrictions on where various options can be present, you should be able to remove: - cpu_has_4kex - cpu_has_3k_cache - cpu_has_4k_cache - cpu_has_32fpr - cpu_has_divec - cpu_has_prefetch - cpu_has_llsc cpu_has_mmips defaults to a compile-time zero unless you select
Re: [PATCH v2 01/18] MIPS: intel: Add initial support for Intel MIPS SoCs
Hi Songjun / Hua, On Fri, Aug 03, 2018 at 11:02:20AM +0800, Songjun Wu wrote: > From: Hua Ma > > Add initial support for Intel MIPS interAptiv SoCs made by Intel. > This series will add support for the grx500 family. > > The series allows booting a minimal system using a initramfs. Thanks for submitting this - I have some comments below. > diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms > index ac7ad54f984f..bcd647060f3e 100644 > --- a/arch/mips/Kbuild.platforms > +++ b/arch/mips/Kbuild.platforms > @@ -12,6 +12,7 @@ platforms += cobalt > platforms += dec > platforms += emma > platforms += generic > +platforms += intel-mips > platforms += jazz > platforms += jz4740 > platforms += lantiq Oh EVA, why must you ruin nice things... Ideally I'd be suggesting that we use the generic platform but it doesn't yet have a nice way to deal with non-standard EVA setups. It would be good if we could make sure that's the only reason for your custom platform though, so that once generic does support EVA we can migrate your system over. Most notably, it would be good to make use of the UHI-specified boot protocol if possible (ie. $r4==-2, $r5==). It looks like your prom_init_cmdline() supports multiple boot protocols - could you clarify which is actually used? > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 08c10c518f83..2d34f17f3e24 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -409,6 +409,34 @@ config LANTIQ > select ARCH_HAS_RESET_CONTROLLER > select RESET_CONTROLLER > > +config INTEL_MIPS > + bool "Intel MIPS interAptiv SoC based platforms" > + select BOOT_RAW > + select CEVT_R4K > + select COMMON_CLK > + select CPU_MIPS32_3_5_EVA > + select CPU_MIPS32_3_5_FEATURES > + select CPU_MIPSR2_IRQ_EI > + select CPU_MIPSR2_IRQ_VI > + select CSRC_R4K > + select DMA_NONCOHERENT > + select GENERIC_ISA_DMA > + select IRQ_MIPS_CPU > + select MFD_CORE > + select MFD_SYSCON > + select MIPS_CPU_SCACHE > + select MIPS_GIC > + select SYS_HAS_CPU_MIPS32_R1 For a system based on interAptiv you should never need to build a MIPS32r1 kernel, so you should remove the above select. > diff --git a/arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h > b/arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h > new file mode 100644 > index ..ac5f3b943d2a > --- /dev/null > +++ b/arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h > @@ -0,0 +1,61 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * This file was derived from: include/asm-mips/cpu-features.h > + * Copyright (C) 2003, 2004 Ralf Baechle > + * Copyright (C) 2004 Maciej W. Rozycki > + * Copyright (C) 2018 Intel Corporation. > + */ > + > +#ifndef __ASM_MACH_INTEL_MIPS_CPU_FEATURE_OVERRIDES_H > +#define __ASM_MACH_INTEL_MIPS_CPU_FEATURE_OVERRIDES_H > + > +#define cpu_has_tlb 1 > +#define cpu_has_4kex 1 > +#define cpu_has_3k_cache 0 > +#define cpu_has_4k_cache 1 > +#define cpu_has_tx39_cache 0 > +#define cpu_has_sb1_cache0 > +#define cpu_has_fpu 0 > +#define cpu_has_32fpr0 > +#define cpu_has_counter 1 > +#define cpu_has_watch1 > +#define cpu_has_divec1 > + > +#define cpu_has_prefetch 1 > +#define cpu_has_ejtag1 > +#define cpu_has_llsc 1 > + > +#define cpu_has_mips16 0 > +#define cpu_has_mdmx 0 > +#define cpu_has_mips3d 0 > +#define cpu_has_smartmips0 > +#define cpu_has_mmips0 > +#define cpu_has_vz 0 > + > +#define cpu_has_mips32r1 1 > +#define cpu_has_mips32r2 1 > +#define cpu_has_mips64r1 0 > +#define cpu_has_mips64r2 0 > + > +#define cpu_has_dsp 1 > +#define cpu_has_dsp2 0 > +#define cpu_has_mipsmt 1 > + > +#define cpu_has_vint 1 > +#define cpu_has_veic 0 > + > +#define cpu_has_64bits 0 > +#define cpu_has_64bit_zero_reg 0 > +#define cpu_has_64bit_gp_regs0 > +#define cpu_has_64bit_addresses 0 > + > +#define cpu_has_cm2 1 > +#define cpu_has_cm2_l2sync 1 > +#define cpu_has_eva 1 > +#define cpu_has_tlbinv 1 > + > +#define cpu_dcache_line_size() 32 > +#define cpu_icache_line_size() 32 > +#define cpu_scache_line_size() 32 If you rebase atop linux-next or mips-next then you should find that many of these defines are now redundant, especially after removing the SYS_HAS_CPU_MIPS32_R1 select which means your kernel build will always target MIPS32r2. Due to architectural restrictions on where various options can be present, you should be able to remove: - cpu_has_4kex - cpu_has_3k_cache - cpu_has_4k_cache - cpu_has_32fpr - cpu_has_divec - cpu_has_prefetch - cpu_has_llsc cpu_has_mmips defaults to a compile-time zero unless you select
Re: [PATCH v4 0/3] Add support for MSCC Ocelot SPI
Hi Alexandre, On Tue, Jul 31, 2018 at 04:38:52PM +0200, Alexandre Belloni wrote: > Hello, > > This series only contains the DT documentation and the corresponding DT > addition > since it has been rebased on spi-next. > > Alexandre Belloni (3): > spi: dw: document Microsemi integration > mips: dts: mscc: Add spi on Ocelot > mips: dts: mscc: enable spi and NOR flash support on ocelot PCB123 > > .../devicetree/bindings/spi/snps,dw-apb-ssi.txt | 6 -- > arch/mips/boot/dts/mscc/ocelot.dtsi | 11 +++ > arch/mips/boot/dts/mscc/ocelot_pcb123.dts | 10 ++ > 3 files changed, 25 insertions(+), 2 deletions(-) Thanks - looks like the DT binding has been accepted, so I've applied patches 2 & 3 to mips-next for 4.19. Paul
Re: [PATCH v4 0/3] Add support for MSCC Ocelot SPI
Hi Alexandre, On Tue, Jul 31, 2018 at 04:38:52PM +0200, Alexandre Belloni wrote: > Hello, > > This series only contains the DT documentation and the corresponding DT > addition > since it has been rebased on spi-next. > > Alexandre Belloni (3): > spi: dw: document Microsemi integration > mips: dts: mscc: Add spi on Ocelot > mips: dts: mscc: enable spi and NOR flash support on ocelot PCB123 > > .../devicetree/bindings/spi/snps,dw-apb-ssi.txt | 6 -- > arch/mips/boot/dts/mscc/ocelot.dtsi | 11 +++ > arch/mips/boot/dts/mscc/ocelot_pcb123.dts | 10 ++ > 3 files changed, 25 insertions(+), 2 deletions(-) Thanks - looks like the DT binding has been accepted, so I've applied patches 2 & 3 to mips-next for 4.19. Paul
Re: [PATCH] mips:sgi-ip22:Check return value from kzalloc
Hi Raghu, On Tue, Jul 17, 2018 at 05:11:45PM +0530, RAGHU Halharvi wrote: > Signed-off-by: RAGHU Halharvi > --- > arch/mips/sgi-ip22/ip22-gio.c | 2 ++ > 1 file changed, 2 insertions(+) You should write a commit message, even for trivial patches, which describes the motivation for the patch. For more complex patches it should also explain how the changes being made solve a problem, or clarify anything non-obvious about the way the patched code works. In general, read Documentation/process/submitting-patches.rst > diff --git a/arch/mips/sgi-ip22/ip22-gio.c b/arch/mips/sgi-ip22/ip22-gio.c > index b225033aade6..5aaf40a1743b 100644 > --- a/arch/mips/sgi-ip22/ip22-gio.c > +++ b/arch/mips/sgi-ip22/ip22-gio.c > @@ -363,6 +363,8 @@ static void ip22_check_gio(int slotno, unsigned long > addr, int irq) > printk(KERN_INFO "GIO: slot %d : %s (id %x)\n", > slotno, name, id); > gio_dev = kzalloc(sizeof *gio_dev, GFP_KERNEL); > + if (!gio_dev) > + return -ENOMEM; One especially important point for patches like this one is to make sure that your code at least compiles. In this case you try to return an error code from a function that returns void, which won't work. Thanks, Paul
Re: [PATCH] mips:sgi-ip22:Check return value from kzalloc
Hi Raghu, On Tue, Jul 17, 2018 at 05:11:45PM +0530, RAGHU Halharvi wrote: > Signed-off-by: RAGHU Halharvi > --- > arch/mips/sgi-ip22/ip22-gio.c | 2 ++ > 1 file changed, 2 insertions(+) You should write a commit message, even for trivial patches, which describes the motivation for the patch. For more complex patches it should also explain how the changes being made solve a problem, or clarify anything non-obvious about the way the patched code works. In general, read Documentation/process/submitting-patches.rst > diff --git a/arch/mips/sgi-ip22/ip22-gio.c b/arch/mips/sgi-ip22/ip22-gio.c > index b225033aade6..5aaf40a1743b 100644 > --- a/arch/mips/sgi-ip22/ip22-gio.c > +++ b/arch/mips/sgi-ip22/ip22-gio.c > @@ -363,6 +363,8 @@ static void ip22_check_gio(int slotno, unsigned long > addr, int irq) > printk(KERN_INFO "GIO: slot %d : %s (id %x)\n", > slotno, name, id); > gio_dev = kzalloc(sizeof *gio_dev, GFP_KERNEL); > + if (!gio_dev) > + return -ENOMEM; One especially important point for patches like this one is to make sure that your code at least compiles. In this case you try to return an error code from a function that returns void, which won't work. Thanks, Paul
Re: [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller
Hi Quentin, On Wed, Jul 25, 2018 at 02:26:20PM +0200, Quentin Schulz wrote: > The GPIO controller also serves as an interrupt controller for events > on the GPIO it handles. > > An interrupt occurs whenever a GPIO line has changed. > > Signed-off-by: Quentin Schulz > --- > arch/mips/boot/dts/mscc/ocelot.dtsi | 3 +++ > 1 file changed, 3 insertions(+) Thanks - applied to mips-next for 4.19. Paul
Re: [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller
Hi Quentin, On Wed, Jul 25, 2018 at 02:26:20PM +0200, Quentin Schulz wrote: > The GPIO controller also serves as an interrupt controller for events > on the GPIO it handles. > > An interrupt occurs whenever a GPIO line has changed. > > Signed-off-by: Quentin Schulz > --- > arch/mips/boot/dts/mscc/ocelot.dtsi | 3 +++ > 1 file changed, 3 insertions(+) Thanks - applied to mips-next for 4.19. Paul
Re: [PATCH] mips: configs: remove no longer needed config option
Hi Anders,
On Thu, Jul 26, 2018 at 09:04:57AM +0200, Anders Roxell wrote:
> > Since commit eedf265aa003 ("devpts: Make each mount of devpts an
> > independent filesystem.") CONFIG_DEVPTS_MULTIPLE_INSTANCES isn't needed
> > in the defconfig anymore.
> >
> > Signed-off-by: Anders Roxell
> > ---
> > arch/mips/configs/ip27_defconfig| 1 -
> > arch/mips/configs/nlm_xlp_defconfig | 1 -
> > arch/mips/configs/nlm_xlr_defconfig | 1 -
> > 3 files changed, 3 deletions(-)
>
> Ping.
Apologies - this was forgotten because it stopped showing up as
requiring action in patchwork after Ralf marked it as accepted, but it
has never been applied to the shared mips-next branch.
I do question whether it's worthwhile making these one-line changes to
configs, because:
1) The no presence of CONFIG_DEVPTS_MULTIPLE_INSTANCES is harmless
anyway, it'll just be ignored.
2) The configs in question will still not be up to date with a lot of
other changes since they were added.
Together these 2 things lead me to think that we'd be better to either:
a) Leave the defconfigs as-is, since the changes won't make them work
any better or worse.
b) Regenerate them entirely, such that they're up to date with not
just this Kconfig change but all of them.
Thanks,
Paul
Re: [PATCH] mips: configs: remove no longer needed config option
Hi Anders,
On Thu, Jul 26, 2018 at 09:04:57AM +0200, Anders Roxell wrote:
> > Since commit eedf265aa003 ("devpts: Make each mount of devpts an
> > independent filesystem.") CONFIG_DEVPTS_MULTIPLE_INSTANCES isn't needed
> > in the defconfig anymore.
> >
> > Signed-off-by: Anders Roxell
> > ---
> > arch/mips/configs/ip27_defconfig| 1 -
> > arch/mips/configs/nlm_xlp_defconfig | 1 -
> > arch/mips/configs/nlm_xlr_defconfig | 1 -
> > 3 files changed, 3 deletions(-)
>
> Ping.
Apologies - this was forgotten because it stopped showing up as
requiring action in patchwork after Ralf marked it as accepted, but it
has never been applied to the shared mips-next branch.
I do question whether it's worthwhile making these one-line changes to
configs, because:
1) The no presence of CONFIG_DEVPTS_MULTIPLE_INSTANCES is harmless
anyway, it'll just be ignored.
2) The configs in question will still not be up to date with a lot of
other changes since they were added.
Together these 2 things lead me to think that we'd be better to either:
a) Leave the defconfigs as-is, since the changes won't make them work
any better or worse.
b) Regenerate them entirely, such that they're up to date with not
just this Kconfig change but all of them.
Thanks,
Paul
Re: [PATCH] MIPS: mscc: ocelot: add MIIM1 bus
Hi Quentin, On Wed, Jul 25, 2018 at 02:22:41PM +0200, Quentin Schulz wrote: > There is an additional MIIM (MDIO) bus in this SoC so let's declare it > in the dtsi. > > This bus requires GPIO 14 and 15 pins that need to be muxed. There is no > support for internal PHY reset on this bus on the contrary of MIIM0 so > there is only one register address space and not two. > > Signed-off-by: Quentin Schulz > --- > arch/mips/boot/dts/mscc/ocelot.dtsi | 16 > 1 file changed, 16 insertions(+) Thanks - applied to mips-next for 4.19. Paul
Re: [PATCH] MIPS: mscc: ocelot: add MIIM1 bus
Hi Quentin, On Wed, Jul 25, 2018 at 02:22:41PM +0200, Quentin Schulz wrote: > There is an additional MIIM (MDIO) bus in this SoC so let's declare it > in the dtsi. > > This bus requires GPIO 14 and 15 pins that need to be muxed. There is no > support for internal PHY reset on this bus on the contrary of MIIM0 so > there is only one register address space and not two. > > Signed-off-by: Quentin Schulz > --- > arch/mips/boot/dts/mscc/ocelot.dtsi | 16 > 1 file changed, 16 insertions(+) Thanks - applied to mips-next for 4.19. Paul
Re: [PATCH] MIPS: mscc: ocelot: fix length of memory address space for MIIM
Hi Quentin,
On Wed, Jul 25, 2018 at 02:21:32PM +0200, Quentin Schulz wrote:
> The length of memory address space for MIIM0 is from 0x7107009c to
> 0x710700bf included which is 36 bytes long in decimal, or 0x24 bytes in
> hexadecimal and not 0x36.
>
> Fixes: 49b031690abe ("MIPS: mscc: Add switch to ocelot")
>
> Signed-off-by: Quentin Schulz
> ---
> arch/mips/boot/dts/mscc/ocelot.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks - applied to mips-next for 4.19.
Paul
Re: [PATCH] MIPS: mscc: ocelot: fix length of memory address space for MIIM
Hi Quentin,
On Wed, Jul 25, 2018 at 02:21:32PM +0200, Quentin Schulz wrote:
> The length of memory address space for MIIM0 is from 0x7107009c to
> 0x710700bf included which is 36 bytes long in decimal, or 0x24 bytes in
> hexadecimal and not 0x36.
>
> Fixes: 49b031690abe ("MIPS: mscc: Add switch to ocelot")
>
> Signed-off-by: Quentin Schulz
> ---
> arch/mips/boot/dts/mscc/ocelot.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks - applied to mips-next for 4.19.
Paul
Re: [PATCH] MIPS: TXx9: remove useless RTC definitions
Hi Alexandre, On Thu, Jul 26, 2018 at 06:40:54PM +0200, Alexandre Belloni wrote: > The RTC definitions were moved to the driver, remove them from the platform > header. > > Signed-off-by: Alexandre Belloni > --- > arch/mips/include/asm/txx9/tx4939.h | 27 --- > 1 file changed, 27 deletions(-) Thanks - applied to mips-next for 4.19, with a small change to also remove the tx4939_rtc_reg macro. Paul
Re: [PATCH] MIPS: TXx9: remove useless RTC definitions
Hi Alexandre, On Thu, Jul 26, 2018 at 06:40:54PM +0200, Alexandre Belloni wrote: > The RTC definitions were moved to the driver, remove them from the platform > header. > > Signed-off-by: Alexandre Belloni > --- > arch/mips/include/asm/txx9/tx4939.h | 27 --- > 1 file changed, 27 deletions(-) Thanks - applied to mips-next for 4.19, with a small change to also remove the tx4939_rtc_reg macro. Paul
Re: [PATCH] mips: switch to NO_BOOTMEM
Hi Mike, On Thu, Jul 26, 2018 at 10:03:56AM +0300, Mike Rapoport wrote: > Any comments on this? I haven't looked at this in detail yet, but there was a much larger series submitted to accomplish this not too long ago, which needed another revision: https://patchwork.linux-mips.org/project/linux-mips/list/?series=787=* Given that, I'd be (pleasantly) surprised if this one smaller patch is enough. Thanks, Paul
Re: [PATCH] mips: switch to NO_BOOTMEM
Hi Mike, On Thu, Jul 26, 2018 at 10:03:56AM +0300, Mike Rapoport wrote: > Any comments on this? I haven't looked at this in detail yet, but there was a much larger series submitted to accomplish this not too long ago, which needed another revision: https://patchwork.linux-mips.org/project/linux-mips/list/?series=787=* Given that, I'd be (pleasantly) surprised if this one smaller patch is enough. Thanks, Paul
Re: [PATCH 1/3] MIPS: jz4780: Allow access to jz4740-i2s
Hi Matthieu, On Wed, Jun 06, 2018 at 09:38:08PM +0200, Mathieu Malaterre wrote: > diff --git a/sound/soc/jz4740/Kconfig b/sound/soc/jz4740/Kconfig > index 1a354a6b6e87..35d82d96e781 100644 > --- a/sound/soc/jz4740/Kconfig > +++ b/sound/soc/jz4740/Kconfig > @@ -1,20 +1,20 @@ > config SND_JZ4740_SOC > - tristate "SoC Audio for Ingenic JZ4740 SoC" > - depends on MACH_JZ4740 || COMPILE_TEST > + tristate "SoC Audio for Ingenic JZ4740/JZ4780 SoC" > + depends on MACH_JZ4740 || MACH_JZ4780 || COMPILE_TEST Perhaps this could be MACH_INGENIC, or even just MIPS? Thanks, Paul
Re: [PATCH 1/3] MIPS: jz4780: Allow access to jz4740-i2s
Hi Matthieu, On Wed, Jun 06, 2018 at 09:38:08PM +0200, Mathieu Malaterre wrote: > diff --git a/sound/soc/jz4740/Kconfig b/sound/soc/jz4740/Kconfig > index 1a354a6b6e87..35d82d96e781 100644 > --- a/sound/soc/jz4740/Kconfig > +++ b/sound/soc/jz4740/Kconfig > @@ -1,20 +1,20 @@ > config SND_JZ4740_SOC > - tristate "SoC Audio for Ingenic JZ4740 SoC" > - depends on MACH_JZ4740 || COMPILE_TEST > + tristate "SoC Audio for Ingenic JZ4740/JZ4780 SoC" > + depends on MACH_JZ4740 || MACH_JZ4780 || COMPILE_TEST Perhaps this could be MACH_INGENIC, or even just MIPS? Thanks, Paul
Re: [PATCH 1/2] MIPS: Ci20: Enable SPI/GPIO driver
Hi Mathieu, On Wed, Jun 06, 2018 at 09:37:29PM +0200, Mathieu Malaterre wrote: > Update the Ci20's defconfig to enable the JZ4780's SPI/GPIO driver. > > Signed-off-by: Mathieu Malaterre > --- > arch/mips/configs/ci20_defconfig | 2 ++ > 1 file changed, 2 insertions(+) Thanks - both patches applied to mips-next for 4.19, with changes to make the commit messages more descriptive. Paul
Re: [PATCH 1/2] MIPS: Ci20: Enable SPI/GPIO driver
Hi Mathieu, On Wed, Jun 06, 2018 at 09:37:29PM +0200, Mathieu Malaterre wrote: > Update the Ci20's defconfig to enable the JZ4780's SPI/GPIO driver. > > Signed-off-by: Mathieu Malaterre > --- > arch/mips/configs/ci20_defconfig | 2 ++ > 1 file changed, 2 insertions(+) Thanks - both patches applied to mips-next for 4.19, with changes to make the commit messages more descriptive. Paul
Re: [PATCH] mips: use asm-generic version of msi.h
Hi Thomas, On Tue, Jul 24, 2018 at 01:52:08PM +0200, Thomas Petazzoni wrote: > This is necessary to be able to include when > CONFIG_GENERIC_MSI_IRQ_DOMAIN is enabled. Without this, a build with > CONFIG_GENERIC_MSI_IRQ_DOMAIN fails with: > >In file included from include/linux/kvm_host.h:20:0, > from arch/mips/kernel/asm-offsets.c:24: > >> include/linux/msi.h:197:10: fatal error: asm/msi.h: No such file or > >> directory > #include > ^~~ >compilation terminated. >make[2]: *** [arch/mips/kernel/asm-offsets.s] Error 1 >make[2]: Target '__build' not remade because of errors. >make[1]: *** [prepare0] Error 2 >make[1]: Target 'prepare' not remade because of errors. >make: *** [sub-make] Error 2 > > Signed-off-by: Thomas Petazzoni > --- > arch/mips/include/asm/Kbuild | 1 + > 1 file changed, 1 insertion(+) Thanks, applied to mips-next for 4.19. BTW it looks like a bunch of other architectures might need this too - a grep suggests more architectures lack asm/msi.h (17) than have it. Paul
Re: [PATCH] mips: use asm-generic version of msi.h
Hi Thomas, On Tue, Jul 24, 2018 at 01:52:08PM +0200, Thomas Petazzoni wrote: > This is necessary to be able to include when > CONFIG_GENERIC_MSI_IRQ_DOMAIN is enabled. Without this, a build with > CONFIG_GENERIC_MSI_IRQ_DOMAIN fails with: > >In file included from include/linux/kvm_host.h:20:0, > from arch/mips/kernel/asm-offsets.c:24: > >> include/linux/msi.h:197:10: fatal error: asm/msi.h: No such file or > >> directory > #include > ^~~ >compilation terminated. >make[2]: *** [arch/mips/kernel/asm-offsets.s] Error 1 >make[2]: Target '__build' not remade because of errors. >make[1]: *** [prepare0] Error 2 >make[1]: Target 'prepare' not remade because of errors. >make: *** [sub-make] Error 2 > > Signed-off-by: Thomas Petazzoni > --- > arch/mips/include/asm/Kbuild | 1 + > 1 file changed, 1 insertion(+) Thanks, applied to mips-next for 4.19. BTW it looks like a bunch of other architectures might need this too - a grep suggests more architectures lack asm/msi.h (17) than have it. Paul
Re: [PATCH] MIPS: jz4740: Bump zload address
Hi Paul, On Sun, Jul 08, 2018 at 05:07:12PM +0200, Paul Cercueil wrote: > Having the zload address at 0x8060. means the size of the > uncompressed kernel cannot be bigger than around 6 MiB, as it is > deflated at address 0x8001.. > > This limit is too small; a kernel with some built-in drivers and things > like debugfs enabled will already be over 6 MiB in size, and so will > fail to extract properly. > > To fix this, we bump the zload address from 0x8060. to 0x8100.. > > This is fine, as all the boards featuring Ingenic JZ SoCs have at least > 32 MiB of RAM, and use u-boot or compatible bootloaders which won't > hardcode the load address but read it from the uImage's header. > > Signed-off-by: Paul Cercueil > --- > arch/mips/jz4740/Platform | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks - applied to mips-next for 4.19 (and tested on Ci20). Paul
Re: [PATCH] MIPS: jz4740: Bump zload address
Hi Paul, On Sun, Jul 08, 2018 at 05:07:12PM +0200, Paul Cercueil wrote: > Having the zload address at 0x8060. means the size of the > uncompressed kernel cannot be bigger than around 6 MiB, as it is > deflated at address 0x8001.. > > This limit is too small; a kernel with some built-in drivers and things > like debugfs enabled will already be over 6 MiB in size, and so will > fail to extract properly. > > To fix this, we bump the zload address from 0x8060. to 0x8100.. > > This is fine, as all the boards featuring Ingenic JZ SoCs have at least > 32 MiB of RAM, and use u-boot or compatible bootloaders which won't > hardcode the load address but read it from the uImage's header. > > Signed-off-by: Paul Cercueil > --- > arch/mips/jz4740/Platform | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks - applied to mips-next for 4.19 (and tested on Ci20). Paul
Re: [PATCH 06/15] MIPS: dts: img: pistachio_marduk: Add 6Lowpan node
Hi Andreas,
On Sun, Jul 22, 2018 at 11:20:01PM +0200, Andreas Färber wrote:
> diff --git a/arch/mips/boot/dts/img/pistachio_marduk.dts
> b/arch/mips/boot/dts/img/pistachio_marduk.dts
> index d723b68084c9..b0b6b534a41f 100644
> --- a/arch/mips/boot/dts/img/pistachio_marduk.dts
> +++ b/arch/mips/boot/dts/img/pistachio_marduk.dts
> @@ -158,6 +158,20 @@
> < 12 GPIO_ACTIVE_HIGH>,
> < 13 GPIO_ACTIVE_HIGH>,
> < 14 GPIO_ACTIVE_HIGH>;
> +
> + ca8210: sixlowpan@4 {
> + compatible = "cascoda,ca8210";
> + reg = <4>;
> + spi-max-frequency = <300>;
> + spi-cpol;
> + reset-gpio = < 12 GPIO_ACTIVE_HIGH>;
> + irq-gpio = < 12 GPIO_ACTIVE_HIGH>;
> +
> + extclock-enable;
> + extclock-freq = <1600>;
> + extclock-gpio = <2>; /* spiuart_clk */
> + #clock-cells = <0>;
> + };
dtc complains about the extclock-gpio property because it expects a
property named *-gpio to contain a gpio-list:
DTC arch/mips/boot/dts/img/pistachio_marduk.dtb
arch/mips/boot/dts/img/pistachio_marduk.dtb: Warning (gpios_property):
/spi@18100f00/sixlowpan@4: Missing property '#gpio-cells' in node
/clk@18144000 or bad phandle (referred from extclock-gpio[0])
Rob, perhaps this should be added as a second false-positive case in
dtc's prop_is_gpio()?
Thanks,
Paul
Re: [PATCH 06/15] MIPS: dts: img: pistachio_marduk: Add 6Lowpan node
Hi Andreas,
On Sun, Jul 22, 2018 at 11:20:01PM +0200, Andreas Färber wrote:
> diff --git a/arch/mips/boot/dts/img/pistachio_marduk.dts
> b/arch/mips/boot/dts/img/pistachio_marduk.dts
> index d723b68084c9..b0b6b534a41f 100644
> --- a/arch/mips/boot/dts/img/pistachio_marduk.dts
> +++ b/arch/mips/boot/dts/img/pistachio_marduk.dts
> @@ -158,6 +158,20 @@
> < 12 GPIO_ACTIVE_HIGH>,
> < 13 GPIO_ACTIVE_HIGH>,
> < 14 GPIO_ACTIVE_HIGH>;
> +
> + ca8210: sixlowpan@4 {
> + compatible = "cascoda,ca8210";
> + reg = <4>;
> + spi-max-frequency = <300>;
> + spi-cpol;
> + reset-gpio = < 12 GPIO_ACTIVE_HIGH>;
> + irq-gpio = < 12 GPIO_ACTIVE_HIGH>;
> +
> + extclock-enable;
> + extclock-freq = <1600>;
> + extclock-gpio = <2>; /* spiuart_clk */
> + #clock-cells = <0>;
> + };
dtc complains about the extclock-gpio property because it expects a
property named *-gpio to contain a gpio-list:
DTC arch/mips/boot/dts/img/pistachio_marduk.dtb
arch/mips/boot/dts/img/pistachio_marduk.dtb: Warning (gpios_property):
/spi@18100f00/sixlowpan@4: Missing property '#gpio-cells' in node
/clk@18144000 or bad phandle (referred from extclock-gpio[0])
Rob, perhaps this should be added as a second false-positive case in
dtc's prop_is_gpio()?
Thanks,
Paul
Re: [PATCH v3 00/18] JZ4780 DMA patchset v3
Hi Paul & Vinod, On Sat, Jul 21, 2018 at 01:06:25PM +0200, Paul Cercueil wrote: > This is the version 3 of my jz4780-dma driver update patchset. > > Apologies to the DMA people, the v2 of this patchset did not make it to > their mailing-list; see the bottom of this email for a description of > what happened in v2. > > Changelog from v2 to v3: > > - Modified the devicetree bindings to comply with the specification > > - New patch [06/18] allows the JZ4780 DMA driver to be compiled within a > generic MIPS kernel. Would you prefer to take the MIPS .dts changes in patches 16-18 through the DMA tree with the rest of the series? If so then for patches 16-18: Acked-by: Paul Burton Thanks, Paul
Re: [PATCH v3 00/18] JZ4780 DMA patchset v3
Hi Paul & Vinod, On Sat, Jul 21, 2018 at 01:06:25PM +0200, Paul Cercueil wrote: > This is the version 3 of my jz4780-dma driver update patchset. > > Apologies to the DMA people, the v2 of this patchset did not make it to > their mailing-list; see the bottom of this email for a description of > what happened in v2. > > Changelog from v2 to v3: > > - Modified the devicetree bindings to comply with the specification > > - New patch [06/18] allows the JZ4780 DMA driver to be compiled within a > generic MIPS kernel. Would you prefer to take the MIPS .dts changes in patches 16-18 through the DMA tree with the rest of the series? If so then for patches 16-18: Acked-by: Paul Burton Thanks, Paul
Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3
Hi Huacai, On Sat, Jul 21, 2018 at 09:35:59AM +0800, 陈华才 wrote: > SFB can improve the memory bandwidth as much as 30%, and we are > planning to enable SFB by default. So, we want to control cpu_relax() > under CONFIG_CPU_LOONGSON3, not under CONFIG_LOONGSON3_ENHANCEMENT. OK, applied to mips-next for 4.19 with changes to the commit message & comment. Thanks, Paul
Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3
Hi Huacai, On Sat, Jul 21, 2018 at 09:35:59AM +0800, 陈华才 wrote: > SFB can improve the memory bandwidth as much as 30%, and we are > planning to enable SFB by default. So, we want to control cpu_relax() > under CONFIG_CPU_LOONGSON3, not under CONFIG_LOONGSON3_ENHANCEMENT. OK, applied to mips-next for 4.19 with changes to the commit message & comment. Thanks, Paul
Re: [PATCH] mips: mm: Discard ioremap_cacheable_cow() method
Hi Serge, On Fri, Jul 20, 2018 at 11:14:27PM +0300, Serge Semin wrote: > This macro substitution is the shortcut to map cacheable IO memory > with coherent and write-back attributes. Since it is entirely unused > by kernel, lets just remove it. > > Signed-off-by: Serge Semin > Suggested-by: Christoph Hellwig > CC: Paul Burton > Cc: James Hogan > Cc: Ralf Baechle > Cc: Sinan Kaya > Cc: Huacai Chen > Cc: sergey.se...@t-platforms.ru > Cc: linux-m...@linux-mips.org > Cc: linux-kernel@vger.kernel.org > --- > arch/mips/include/asm/io.h | 7 --- > 1 file changed, 7 deletions(-) Applied to mips-next for 4.19, thanks! Paul
