from:"Geert Uytterhoeven"

There is no need to cast a kprobe_opcode_t pointer to a kprobe_opcode_t
pointer.

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/kernel/kprobes.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/sh/kernel/kprobes.c b/arch/sh/kernel/kprobes.c
index d8c2e399d6e50794..49c4ffd782d6d6c5 100644
--- a/arch/sh/kernel/kprobes.c
+++ b/arch/sh/kernel/kprobes.c
@@ -39,7 +39,7 @@ static DEFINE_PER_CPU(struct kprobe, saved_next_opcode2);
 
 int __kprobes arch_prepare_kprobe(struct kprobe *p)
 {
-   kprobe_opcode_t opcode = *(kprobe_opcode_t *) (p->addr);
+   kprobe_opcode_t opcode = *p->addr;
 
if (OPCODE_RTE(opcode))
return -EFAULT; /* Bad breakpoint */
@@ -248,7 +248,7 @@ static int __kprobes kprobe_handler(struct pt_regs *regs)
p = get_kprobe(addr);
if (!p) {
/* Not one of ours: let kernel handle it */
-   if (*(kprobe_opcode_t *)addr != BREAKPOINT_INSTRUCTION) {
+   if (*addr != BREAKPOINT_INSTRUCTION) {
/*
 * The breakpoint instruction was removed right
 * after we hit it. Another cpu has removed
-- 
2.34.1

[PATCH 20/20] [RFC] sh: dma: Remove unused functionality

dma_extend(), get_dma_info_by_name(), register_chan_caps(), and
request_dma_bycap() are unused.  Remove them, and all related code.

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/drivers/dma/dma-api.c | 116 --
 arch/sh/include/asm/dma.h |   7 --
 2 files changed, 123 deletions(-)

diff --git a/arch/sh/drivers/dma/dma-api.c b/arch/sh/drivers/dma/dma-api.c
index f49097fa634c36d4..87e5a892887360f5 100644
--- a/arch/sh/drivers/dma/dma-api.c
+++ b/arch/sh/drivers/dma/dma-api.c
@@ -41,21 +41,6 @@ struct dma_info *get_dma_info(unsigned int chan)
 }
 EXPORT_SYMBOL(get_dma_info);
 
-struct dma_info *get_dma_info_by_name(const char *dmac_name)
-{
-   struct dma_info *info;
-
-   list_for_each_entry(info, _dmac_list, list) {
-   if (dmac_name && (strcmp(dmac_name, info->name) != 0))
-   continue;
-   else
-   return info;
-   }
-
-   return NULL;
-}
-EXPORT_SYMBOL(get_dma_info_by_name);
-
 static unsigned int get_nr_channels(void)
 {
struct dma_info *info;
@@ -101,66 +86,6 @@ int get_dma_residue(unsigned int chan)
 }
 EXPORT_SYMBOL(get_dma_residue);
 
-static int search_cap(const char **haystack, const char *needle)
-{
-   const char **p;
-
-   for (p = haystack; *p; p++)
-   if (strcmp(*p, needle) == 0)
-   return 1;
-
-   return 0;
-}
-
-/**
- * request_dma_bycap - Allocate a DMA channel based on its capabilities
- * @dmac: List of DMA controllers to search
- * @caps: List of capabilities
- *
- * Search all channels of all DMA controllers to find a channel which
- * matches the requested capabilities. The result is the channel
- * number if a match is found, or %-ENODEV if no match is found.
- *
- * Note that not all DMA controllers export capabilities, in which
- * case they can never be allocated using this API, and so
- * request_dma() must be used specifying the channel number.
- */
-int request_dma_bycap(const char **dmac, const char **caps, const char *dev_id)
-{
-   unsigned int found = 0;
-   struct dma_info *info;
-   const char **p;
-   int i;
-
-   BUG_ON(!dmac || !caps);
-
-   list_for_each_entry(info, _dmac_list, list)
-   if (strcmp(*dmac, info->name) == 0) {
-   found = 1;
-   break;
-   }
-
-   if (!found)
-   return -ENODEV;
-
-   for (i = 0; i < info->nr_channels; i++) {
-   struct dma_channel *channel = >channels[i];
-
-   if (unlikely(!channel->caps))
-   continue;
-
-   for (p = caps; *p; p++) {
-   if (!search_cap(channel->caps, *p))
-   break;
-   if (request_dma(channel->chan, dev_id) == 0)
-   return channel->chan;
-   }
-   }
-
-   return -EINVAL;
-}
-EXPORT_SYMBOL(request_dma_bycap);
-
 int request_dma(unsigned int chan, const char *dev_id)
 {
struct dma_channel *channel = { 0 };
@@ -213,35 +138,6 @@ void dma_wait_for_completion(unsigned int chan)
 }
 EXPORT_SYMBOL(dma_wait_for_completion);
 
-int register_chan_caps(const char *dmac, struct dma_chan_caps *caps)
-{
-   struct dma_info *info;
-   unsigned int found = 0;
-   int i;
-
-   list_for_each_entry(info, _dmac_list, list)
-   if (strcmp(dmac, info->name) == 0) {
-   found = 1;
-   break;
-   }
-
-   if (unlikely(!found))
-   return -ENODEV;
-
-   for (i = 0; i < info->nr_channels; i++, caps++) {
-   struct dma_channel *channel;
-
-   if ((info->first_channel_nr + i) != caps->ch_num)
-   return -EINVAL;
-
-   channel = >channels[i];
-   channel->caps = caps->caplist;
-   }
-
-   return 0;
-}
-EXPORT_SYMBOL(register_chan_caps);
-
 void dma_configure_channel(unsigned int chan, unsigned long flags)
 {
struct dma_info *info = get_dma_info(chan);
@@ -267,18 +163,6 @@ int dma_xfer(unsigned int chan, unsigned long from,
 }
 EXPORT_SYMBOL(dma_xfer);
 
-int dma_extend(unsigned int chan, unsigned long op, void *param)
-{
-   struct dma_info *info = get_dma_info(chan);
-   struct dma_channel *channel = get_dma_channel(chan);
-
-   if (info->ops->extend)
-   return info->ops->extend(channel, op, param);
-
-   return -ENOSYS;
-}
-EXPORT_SYMBOL(dma_extend);
-
 static int dma_proc_show(struct seq_file *m, void *v)
 {
struct dma_info *info = v;
diff --git a/arch/sh/include/asm/dma.h b/arch/sh/include/asm/dma.h
index c8bee3f985a29393..6b6d409956d17f09 100644
--- a/arch/sh/include/asm/dma.h
+++ b/arch/sh/include/asm/dma.h
@@ -56,7 +56,6 @@ struct dma_ops {
int (*get_residue)(struct dma_channel *chan);

[PATCH 16/20] sh: kprobes: Merge arch_copy_kprobe() into arch_prepare_kprobe()

arch/sh/kernel/kprobes.c:52:16: warning: no previous prototype for 
'arch_copy_kprobe' [-Wmissing-prototypes]

Although SH kprobes support was only merged in v2.6.28, it missed the
earlier removal of the arch_copy_kprobe() callback in v2.6.15.

Based on the powerpc part of commit 49a2a1b83ba6fa40 ("[PATCH] kprobes:
changed from using spinlock to mutex").

Fixes: d39f5450146ff39f ("sh: Add kprobes support.")
Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.
---
 arch/sh/kernel/kprobes.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/sh/kernel/kprobes.c b/arch/sh/kernel/kprobes.c
index aed1ea8e2c2f063b..74051b8ddf3e7bf9 100644
--- a/arch/sh/kernel/kprobes.c
+++ b/arch/sh/kernel/kprobes.c
@@ -44,17 +44,12 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
if (OPCODE_RTE(opcode))
return -EFAULT; /* Bad breakpoint */
 
+   memcpy(p->ainsn.insn, p->addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
p->opcode = opcode;
 
return 0;
 }
 
-void __kprobes arch_copy_kprobe(struct kprobe *p)
-{
-   memcpy(p->ainsn.insn, p->addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
-   p->opcode = *p->addr;
-}
-
 void __kprobes arch_arm_kprobe(struct kprobe *p)
 {
*p->addr = BREAKPOINT_INSTRUCTION;
-- 
2.34.1

[PATCH 05/20] sh: return_address: Add missing #include

arch/sh/kernel/return_address.c:49:7: warning: no previous prototype for 
‘return_address’ [-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/kernel/return_address.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/kernel/return_address.c b/arch/sh/kernel/return_address.c
index 8838094c9ff9444f..2ce22f11eab37839 100644
--- a/arch/sh/kernel/return_address.c
+++ b/arch/sh/kernel/return_address.c
@@ -7,7 +7,9 @@
  */
 #include 
 #include 
+
 #include 
+#include 
 
 #ifdef CONFIG_DWARF_UNWINDER
 
-- 
2.34.1

[PATCH 12/20] sh: dma: Remove unused dmac_search_free_channel()

arch/sh/drivers/dma/dma-api.c:164:5: warning: no previous prototype for 
'dmac_search_free_channel' [-Wmissing-prototypes]

dmac_search_free_channel() never had a user in upstream, remove it.

Signed-off-by: Geert Uytterhoeven 
---
dma_extend(), get_dma_info_by_name(), register_chan_caps(), and
request_dma_bycap() are also unused, but don't trigger warnings
---
 arch/sh/drivers/dma/dma-api.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/arch/sh/drivers/dma/dma-api.c b/arch/sh/drivers/dma/dma-api.c
index 89cd4a3b4ccafbe2..f49097fa634c36d4 100644
--- a/arch/sh/drivers/dma/dma-api.c
+++ b/arch/sh/drivers/dma/dma-api.c
@@ -161,33 +161,6 @@ int request_dma_bycap(const char **dmac, const char 
**caps, const char *dev_id)
 }
 EXPORT_SYMBOL(request_dma_bycap);
 
-int dmac_search_free_channel(const char *dev_id)
-{
-   struct dma_channel *channel = { 0 };
-   struct dma_info *info = get_dma_info(0);
-   int i;
-
-   for (i = 0; i < info->nr_channels; i++) {
-   channel = >channels[i];
-   if (unlikely(!channel))
-   return -ENODEV;
-
-   if (atomic_read(>busy) == 0)
-   break;
-   }
-
-   if (info->ops->request) {
-   int result = info->ops->request(channel);
-   if (result)
-   return result;
-
-   atomic_set(>busy, 1);
-   return channel->chan;
-   }
-
-   return -ENOSYS;
-}
-
 int request_dma(unsigned int chan, const char *dev_id)
 {
struct dma_channel *channel = { 0 };
-- 
2.34.1

[PATCH 00/20] sh: Fix missing prototypes

Hi all,

This patch series fixes several "no previous prototype for "
warnings when building a kernel for SuperH.

Known issues:
  - The various warnings about cache functions are not yet fixed, but
I didn't want to hold off the rest of this series,
  - sdk7786_defconfig needs "[PATCH/RFC] locking/spinlocks: Make __raw_*
lock ops static" [1],
  - Probably there are more warnings to fix, I didn't build all
defconfigs.

This has been boot-tested on landisk and on qemu/rts7751r2d.

Thanks for your comments!

[1] 
https://lore.kernel.org/linux-sh/c395b02613572131568bc1fd1bc456d20d1a5426.1709325647.git.geert+rene...@glider.be

Geert Uytterhoeven (20):
  sh: pgtable: Fix missing prototypes
  sh: fpu: Add missing forward declarations
  sh: syscall: Add missing forward declaration for sys_cacheflush()
  sh: tlb: Add missing forward declaration for handle_tlbmiss()
  sh: return_address: Add missing #include 
  sh: traps: Add missing #include 
  sh: hw_breakpoint: Add missing forward declaration for
arch_bp_generic_fields()
  sh: boot: Add proper forward declarations
  sh: ftrace: Fix missing prototypes
  sh: nommu: Add missing #include 
  sh: math-emu: Add missing #include 
  sh: dma: Remove unused dmac_search_free_channel()
  sh: sh2a: Add missing #include 
  sh: sh7786: Remove unused sh7786_usb_use_exclock()
  sh: smp: Fix missing prototypes
  sh: kprobes: Merge arch_copy_kprobe() into arch_prepare_kprobe()
  sh: kprobes: Make trampoline_probe_handler() static
  sh: kprobes: Remove unneeded kprobe_opcode_t casts
  sh: dwarf: Make dwarf_lookup_fde() static
  [RFC] sh: dma: Remove unused functionality

 arch/sh/boot/compressed/cache.c |   3 +
 arch/sh/boot/compressed/cache.h |  10 ++
 arch/sh/boot/compressed/misc.c  |   8 +-
 arch/sh/boot/compressed/misc.h  |   9 ++
 arch/sh/drivers/dma/dma-api.c   | 143 
 arch/sh/include/asm/dma.h   |   7 --
 arch/sh/include/asm/fpu.h   |   3 +
 arch/sh/include/asm/ftrace.h|  10 ++
 arch/sh/include/asm/hw_breakpoint.h |   2 +
 arch/sh/include/asm/syscalls.h  |   1 +
 arch/sh/include/asm/tlb.h   |   4 +
 arch/sh/kernel/cpu/sh2a/opcode_helper.c |   2 +
 arch/sh/kernel/cpu/sh4a/setup-sh7786.c  |  14 ---
 arch/sh/kernel/dwarf.c  |   2 +-
 arch/sh/kernel/kprobes.c|  13 +--
 arch/sh/kernel/return_address.c |   2 +
 arch/sh/kernel/smp.c|   4 +-
 arch/sh/kernel/traps.c  |  10 +-
 arch/sh/kernel/traps_32.c   |   1 +
 arch/sh/math-emu/math.c |   2 +
 arch/sh/mm/nommu.c  |   2 +
 arch/sh/mm/pgtable.c|   4 +-
 arch/sh/mm/tlbex_32.c   |   1 +
 23 files changed, 68 insertions(+), 189 deletions(-)
 create mode 100644 arch/sh/boot/compressed/cache.h
 create mode 100644 arch/sh/boot/compressed/misc.h

-- 
2.34.1

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 15/20] sh: smp: Fix missing prototypes

arch/sh/kernel/smp.c:173:17: warning: no previous prototype for 
'start_secondary' [-Wmissing-prototypes]
arch/sh/kernel/smp.c:324:5: warning: no previous prototype for 
'setup_profiling_timer' [-Wmissing-prototypes]

Make start_secondary() static, as it is only used in this file.
Include  to fix the other warning.

There are no users outside this file, so make it static.

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/kernel/smp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/sh/kernel/smp.c b/arch/sh/kernel/smp.c
index 5cf35a774dc70082..b3ea50aabba3d7f2 100644
--- a/arch/sh/kernel/smp.c
+++ b/arch/sh/kernel/smp.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
@@ -170,7 +172,7 @@ void native_play_dead(void)
 }
 #endif
 
-asmlinkage void start_secondary(void)
+static asmlinkage void start_secondary(void)
 {
unsigned int cpu = smp_processor_id();
struct mm_struct *mm = _mm;
-- 
2.34.1

[PATCH 08/20] sh: boot: Add proper forward declarations

arch/sh/boot/compressed/cache.c:2:5: warning: no previous prototype for 
‘cache_control’ [-Wmissing-prototypes]
arch/sh/boot/compressed/misc.c:115:6: warning: no previous prototype for 
‘ftrace_stub’ [-Wmissing-prototypes]
arch/sh/boot/compressed/misc.c:118:6: warning: no previous prototype for 
‘arch_ftrace_ops_list_func’ [-Wmissing-prototypes]
arch/sh/boot/compressed/misc.c:128:6: warning: no previous prototype for 
‘decompress_kernel’ [-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/boot/compressed/cache.c |  3 +++
 arch/sh/boot/compressed/cache.h | 10 ++
 arch/sh/boot/compressed/misc.c  |  8 +++-
 arch/sh/boot/compressed/misc.h  |  9 +
 4 files changed, 25 insertions(+), 5 deletions(-)
 create mode 100644 arch/sh/boot/compressed/cache.h
 create mode 100644 arch/sh/boot/compressed/misc.h

diff --git a/arch/sh/boot/compressed/cache.c b/arch/sh/boot/compressed/cache.c
index 31e04ff4841ed084..95c1e73ccbb7e011 100644
--- a/arch/sh/boot/compressed/cache.c
+++ b/arch/sh/boot/compressed/cache.c
@@ -1,4 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
+
+#include "cache.h"
+
 int cache_control(unsigned int command)
 {
volatile unsigned int *p = (volatile unsigned int *) 0x8000;
diff --git a/arch/sh/boot/compressed/cache.h b/arch/sh/boot/compressed/cache.h
new file mode 100644
index ..b622b68c87f59b97
--- /dev/null
+++ b/arch/sh/boot/compressed/cache.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef CACHE_H
+#define CACHE_H
+
+#define CACHE_ENABLE   0
+#define CACHE_DISABLE  1
+
+int cache_control(unsigned int command);
+
+#endif /* CACHE_H */
diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c
index ca05c99a3d5b488d..5178150ca6650dcf 100644
--- a/arch/sh/boot/compressed/misc.c
+++ b/arch/sh/boot/compressed/misc.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 
+#include "cache.h"
+#include "misc.h"
+
 /*
  * gzip declarations
  */
@@ -26,11 +29,6 @@
 #undef memcpy
 #define memzero(s, n) memset ((s), 0, (n))
 
-/* cache.c */
-#define CACHE_ENABLE  0
-#define CACHE_DISABLE 1
-int cache_control(unsigned int command);
-
 extern char input_data[];
 extern int input_len;
 static unsigned char *output;
diff --git a/arch/sh/boot/compressed/misc.h b/arch/sh/boot/compressed/misc.h
new file mode 100644
index ..2b4534faa3052857
--- /dev/null
+++ b/arch/sh/boot/compressed/misc.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef MISC_H
+#define MISC_H
+
+void arch_ftrace_ops_list_func(void);
+void decompress_kernel(void);
+void ftrace_stub(void);
+
+#endif /* MISC_H */
-- 
2.34.1

[PATCH 06/20] sh: traps: Add missing #include

arch/sh/kernel/traps_32.c:735:6: warning: no previous prototype for 
‘per_cpu_trap_init’ [-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/kernel/traps_32.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/sh/kernel/traps_32.c b/arch/sh/kernel/traps_32.c
index 6cdda3a621a1e577..8cd4b05df75c3e07 100644
--- a/arch/sh/kernel/traps_32.c
+++ b/arch/sh/kernel/traps_32.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-- 
2.34.1

[PATCH 07/20] sh: hw_breakpoint: Add missing forward declaration for arch_bp_generic_fields()

arch/sh/kernel/hw_breakpoint.c:135:5: warning: no previous prototype for 
‘arch_bp_generic_fields’ [-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/include/asm/hw_breakpoint.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/include/asm/hw_breakpoint.h 
b/arch/sh/include/asm/hw_breakpoint.h
index 361a0f57bdebda6e..74a438cea6559efd 100644
--- a/arch/sh/include/asm/hw_breakpoint.h
+++ b/arch/sh/include/asm/hw_breakpoint.h
@@ -52,6 +52,8 @@ struct pmu;
 
 /* arch/sh/kernel/hw_breakpoint.c */
 extern int arch_check_bp_in_kernelspace(struct arch_hw_breakpoint *hw);
+extern int arch_bp_generic_fields(int sh_len, int sh_type, int *gen_len,
+ int *gen_type);
 extern int hw_breakpoint_arch_parse(struct perf_event *bp,
const struct perf_event_attr *attr,
struct arch_hw_breakpoint *hw);
-- 
2.34.1

[PATCH 01/20] sh: pgtable: Fix missing prototypes

arch/sh/mm/pgtable.c:12:6: warning: no previous prototype for 'pgd_ctor' 
[-Wmissing-prototypes]
arch/sh/mm/pgtable.c:34:8: warning: no previous prototype for 'pgd_alloc' 
[-Wmissing-prototypes]
arch/sh/mm/pgtable.c:39:6: warning: no previous prototype for 'pgd_free' 
[-Wmissing-prototypes]
arch/sh/mm/pgtable.c:45:6: warning: no previous prototype for 'pud_populate' 
[-Wmissing-prototypes]
arch/sh/mm/pgtable.c:50:8: warning: no previous prototype for 'pmd_alloc_one' 
[-Wmissing-prototypes]
arch/sh/mm/pgtable.c:55:6: warning: no previous prototype for 'pmd_free' 
[-Wmissing-prototypes]

Make pgd_ctor() static, as it is only used in this file.
Include  to fix the other warnings.

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/mm/pgtable.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/sh/mm/pgtable.c b/arch/sh/mm/pgtable.c
index cf7ce4b5735954bf..3a4085ea0161fe56 100644
--- a/arch/sh/mm/pgtable.c
+++ b/arch/sh/mm/pgtable.c
@@ -2,12 +2,14 @@
 #include 
 #include 
 
+#include 
+
 static struct kmem_cache *pgd_cachep;
 #if PAGETABLE_LEVELS > 2
 static struct kmem_cache *pmd_cachep;
 #endif
 
-void pgd_ctor(void *x)
+static void pgd_ctor(void *x)
 {
pgd_t *pgd = x;
 
-- 
2.34.1

[PATCH 13/20] sh: sh2a: Add missing #include

arch/sh/kernel/cpu/sh2a/opcode_helper.c:34:14: warning: no previous prototype 
for 'instruction_size' [-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/kernel/cpu/sh2a/opcode_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/kernel/cpu/sh2a/opcode_helper.c 
b/arch/sh/kernel/cpu/sh2a/opcode_helper.c
index c509081d90b9affe..fcf53f5827eb286c 100644
--- a/arch/sh/kernel/cpu/sh2a/opcode_helper.c
+++ b/arch/sh/kernel/cpu/sh2a/opcode_helper.c
@@ -8,6 +8,8 @@
  */
 #include 
 
+#include 
+
 /*
  * Instructions on SH are generally fixed at 16-bits, however, SH-2A
  * introduces some 32-bit instructions. Since there are no real
-- 
2.34.1

[PATCH 09/20] sh: ftrace: Fix missing prototypes

arch/sh/kernel/ftrace.c:130:6: warning: no previous prototype for 
‘arch_ftrace_nmi_enter’ [-Wmissing-prototypes]
arch/sh/kernel/ftrace.c:140:6: warning: no previous prototype for 
‘arch_ftrace_nmi_exit’ [-Wmissing-prototypes]
arch/sh/kernel/ftrace.c:316:6: warning: no previous prototype for 
‘prepare_ftrace_return’ [-Wmissing-prototypes]

Fix this by moving existing forward declarations to , and
adding the missing forward declaration for prepare_ftrace_return().

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/include/asm/ftrace.h | 10 ++
 arch/sh/kernel/traps.c   | 10 ++
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/sh/include/asm/ftrace.h b/arch/sh/include/asm/ftrace.h
index b1c1dc0cc261d1db..1c10e106639098fc 100644
--- a/arch/sh/include/asm/ftrace.h
+++ b/arch/sh/include/asm/ftrace.h
@@ -33,6 +33,8 @@ static inline unsigned long ftrace_call_adjust(unsigned long 
addr)
return addr;
 }
 
+void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr);
+
 #endif /* __ASSEMBLY__ */
 #endif /* CONFIG_FUNCTION_TRACER */
 
@@ -43,6 +45,14 @@ extern void *return_address(unsigned int);
 
 #define ftrace_return_address(n) return_address(n)
 
+#ifdef CONFIG_DYNAMIC_FTRACE
+extern void arch_ftrace_nmi_enter(void);
+extern void arch_ftrace_nmi_exit(void);
+#else
+static inline void arch_ftrace_nmi_enter(void) { }
+static inline void arch_ftrace_nmi_exit(void) { }
+#endif
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_SH_FTRACE_H */
diff --git a/arch/sh/kernel/traps.c b/arch/sh/kernel/traps.c
index 01884054aeb2bd30..4339c4cafa79ce2a 100644
--- a/arch/sh/kernel/traps.c
+++ b/arch/sh/kernel/traps.c
@@ -15,6 +15,8 @@
 
 #include 
 #include   /* print_modules */
+
+#include 
 #include 
 #include 
 
@@ -170,14 +172,6 @@ BUILD_TRAP_HANDLER(bug)
force_sig(SIGTRAP);
 }
 
-#ifdef CONFIG_DYNAMIC_FTRACE
-extern void arch_ftrace_nmi_enter(void);
-extern void arch_ftrace_nmi_exit(void);
-#else
-static inline void arch_ftrace_nmi_enter(void) { }
-static inline void arch_ftrace_nmi_exit(void) { }
-#endif
-
 BUILD_TRAP_HANDLER(nmi)
 {
TRAP_HANDLER_DECL;
-- 
2.34.1

[PATCH 14/20] sh: sh7786: Remove unused sh7786_usb_use_exclock()

arch/sh/kernel/cpu/sh4a/setup-sh7786.c:411:13: warning: no previous prototype 
for 'sh7786_usb_use_exclock' [-Wmissing-prototypes]

Upstream never had a user of sh7786_usb_use_exclock(), remove it.

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/kernel/cpu/sh4a/setup-sh7786.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7786.c 
b/arch/sh/kernel/cpu/sh4a/setup-sh7786.c
index 74620f30b19badbd..c048842d8a589866 100644
--- a/arch/sh/kernel/cpu/sh4a/setup-sh7786.c
+++ b/arch/sh/kernel/cpu/sh4a/setup-sh7786.c
@@ -400,20 +400,6 @@ static struct platform_device *sh7786_devices[] __initdata 
= {
_ohci_device,
 };
 
-/*
- * Please call this function if your platform board
- * use external clock for USB
- * */
-#define USBCTL00xffe70858
-#define CLOCK_MODE_MASK 0xff7f
-#define EXT_CLOCK_MODE  0x0080
-
-void __init sh7786_usb_use_exclock(void)
-{
-   u32 val = __raw_readl(USBCTL0) & CLOCK_MODE_MASK;
-   __raw_writel(val | EXT_CLOCK_MODE, USBCTL0);
-}
-
 #define USBINITREG10xffe70094
 #define USBINITREG20xffe7009c
 #define USBINITVAL10x00ff0040
-- 
2.34.1

[PATCH 11/20] sh: math-emu: Add missing #include

arch/sh/math-emu/math.c:492:5: warning: no previous prototype for 'do_fpu_inst' 
[-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/math-emu/math.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/math-emu/math.c b/arch/sh/math-emu/math.c
index cdaef6501d764a0c..b65703e065735663 100644
--- a/arch/sh/math-emu/math.c
+++ b/arch/sh/math-emu/math.c
@@ -15,6 +15,8 @@
 #include 
 
 #include 
+
+#include 
 #include 
 #include 
 
-- 
2.34.1

[PATCH 10/20] sh: nommu: Add missing #include

arch/sh/mm/nommu.c:76:13: warning: no previous prototype for 
'kmap_coherent_init' [-Wmissing-prototypes]
arch/sh/mm/nommu.c:80:7: warning: no previous prototype for 'kmap_coherent' 
[-Wmissing-prototypes]
arch/sh/mm/nommu.c:86:6: warning: no previous prototype for 'kunmap_coherent' 
[-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/mm/nommu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/mm/nommu.c b/arch/sh/mm/nommu.c
index 78c4b6e6d33ba3af..fa3dc9428a737ffe 100644
--- a/arch/sh/mm/nommu.c
+++ b/arch/sh/mm/nommu.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+
+#include 
 #include 
 #include 
 #include 
-- 
2.34.1

[PATCH 02/20] sh: fpu: Add missing forward declarations

arch/sh/kernel/cpu/sh4/fpu.c:389:6: warning: no previous prototype for 
‘float_raise’ [-Wmissing-prototypes]
arch/sh/kernel/cpu/sh4/fpu.c:394:5: warning: no previous prototype for 
‘float_rounding_mode’ [-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/include/asm/fpu.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/sh/include/asm/fpu.h b/arch/sh/include/asm/fpu.h
index 04584be8986c418a..0379f4cce5ed25fb 100644
--- a/arch/sh/include/asm/fpu.h
+++ b/arch/sh/include/asm/fpu.h
@@ -64,6 +64,9 @@ static inline void clear_fpu(struct task_struct *tsk, struct 
pt_regs *regs)
preempt_enable();
 }
 
+void float_raise(unsigned int flags);
+int float_rounding_mode(void);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_SH_FPU_H */
-- 
2.34.1

[PATCH 17/20] sh: kprobes: Make trampoline_probe_handler() static

arch/sh/kernel/kprobes.c:299:15: warning: no previous prototype for 
'trampoline_probe_handler' [-Wmissing-prototypes]

There are no users outside this file, so make it static.

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/kernel/kprobes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/kernel/kprobes.c b/arch/sh/kernel/kprobes.c
index 74051b8ddf3e7bf9..d8c2e399d6e50794 100644
--- a/arch/sh/kernel/kprobes.c
+++ b/arch/sh/kernel/kprobes.c
@@ -296,7 +296,7 @@ static void __used kretprobe_trampoline_holder(void)
 /*
  * Called when we hit the probe point at __kretprobe_trampoline
  */
-int __kprobes trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
+static int __kprobes trampoline_probe_handler(struct kprobe *p, struct pt_regs 
*regs)
 {
regs->pc = __kretprobe_trampoline_handler(regs, NULL);
 
-- 
2.34.1

[PATCH 04/20] sh: tlb: Add missing forward declaration for handle_tlbmiss()

arch/sh/mm/tlbex_32.c:22:1: warning: no previous prototype for ‘handle_tlbmiss’ 
[-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/include/asm/tlb.h | 4 
 arch/sh/mm/tlbex_32.c | 1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h
index aeb8915e92549609..ddf324bfb9a09721 100644
--- a/arch/sh/include/asm/tlb.h
+++ b/arch/sh/include/asm/tlb.h
@@ -24,6 +24,10 @@ static inline void tlb_unwire_entry(void)
BUG();
 }
 #endif /* CONFIG_CPU_SH4 */
+
+asmlinkage int handle_tlbmiss(struct pt_regs *regs, unsigned long error_code,
+ unsigned long address);
+
 #endif /* CONFIG_MMU */
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_SH_TLB_H */
diff --git a/arch/sh/mm/tlbex_32.c b/arch/sh/mm/tlbex_32.c
index 1c53868632ee4c69..7d58578c15f4ef55 100644
--- a/arch/sh/mm/tlbex_32.c
+++ b/arch/sh/mm/tlbex_32.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Called with interrupts disabled.
-- 
2.34.1

[PATCH 03/20] sh: syscall: Add missing forward declaration for sys_cacheflush()

arch/sh/kernel/sys_sh.c:58:16: warning: no previous prototype for 
‘sys_cacheflush’ [-Wmissing-prototypes]

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/include/asm/syscalls.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/sh/include/asm/syscalls.h b/arch/sh/include/asm/syscalls.h
index 387105316d2882fe..39240e06e8aa5f6b 100644
--- a/arch/sh/include/asm/syscalls.h
+++ b/arch/sh/include/asm/syscalls.h
@@ -8,6 +8,7 @@ asmlinkage int old_mmap(unsigned long addr, unsigned long len,
 asmlinkage long sys_mmap2(unsigned long addr, unsigned long len,
  unsigned long prot, unsigned long flags,
  unsigned long fd, unsigned long pgoff);
+asmlinkage int sys_cacheflush(unsigned long addr, unsigned long len, int op);
 
 #include 
 
-- 
2.34.1

[PATCH 19/20] sh: dwarf: Make dwarf_lookup_fde() static

arch/sh/kernel/dwarf.c:347:19: warning: no previous prototype for 
'dwarf_lookup_fde' [-Wmissing-prototypes]

There are no users outside this file, so make it static.

Signed-off-by: Geert Uytterhoeven 
---
 arch/sh/kernel/dwarf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/kernel/dwarf.c b/arch/sh/kernel/dwarf.c
index bf8682e718303051..45c8ae20d10957db 100644
--- a/arch/sh/kernel/dwarf.c
+++ b/arch/sh/kernel/dwarf.c
@@ -344,7 +344,7 @@ static struct dwarf_cie *dwarf_lookup_cie(unsigned long 
cie_ptr)
  * dwarf_lookup_fde - locate the FDE that covers pc
  * @pc: the program counter
  */
-struct dwarf_fde *dwarf_lookup_fde(unsigned long pc)
+static struct dwarf_fde *dwarf_lookup_fde(unsigned long pc)
 {
struct rb_node **rb_node = _root.rb_node;
struct dwarf_fde *fde = NULL;
-- 
2.34.1

Re: [PATCH 0/4] apply page shift to PFN instead of VA in pfn_to_virt

2024-02-01 Thread Geert Uytterhoeven

Hi Arnd,

On Thu, Feb 1, 2024 at 11:11 AM Arnd Bergmann  wrote:
> I think it's fair to assume we won't need asm-generic/page.h any
> more, as we likely won't be adding new NOMMU architectures.

So you think riscv-nommu (k210) was the last one we will ever see?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] dt-bindings: correct white-spaces in examples

2023-11-27 Thread Geert Uytterhoeven

On Fri, Nov 24, 2023 at 10:21 AM Krzysztof Kozlowski
 wrote:
> Use only one and exactly one space around '=' in DTS example.
>
> Signed-off-by: Krzysztof Kozlowski 

>  .../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml   | 6 +++---

Reviewed-by: Geert Uytterhoeven 
Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2] locking/atomic: sh: Use generic_cmpxchg_local for arch_cmpxchg_local()

2023-10-26 Thread Geert Uytterhoeven

On Wed, Oct 25, 2023 at 5:10 PM Masami Hiramatsu (Google)
 wrote:
> From: Masami Hiramatsu (Google) 
>
> Use __generic_cmpxchg_local() for arch_cmpxchg_local() implementation
> in SH architecture because it does not implement arch_cmpxchg_local().
>
> Reported-by: kernel test robot 
> Closes: 
> https://lore.kernel.org/oe-kbuild-all/202310241310.ir5uukog-...@intel.com/
> Signed-off-by: Masami Hiramatsu (Google) 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] locking/atomic: sh: Use generic_cmpxchg_local for arch_cmpxchg_local()

2023-10-25 Thread Geert Uytterhoeven

Hi Adrian,

On Wed, Oct 25, 2023 at 12:32 PM John Paul Adrian Glaubitz
 wrote:
> On Wed, 2023-10-25 at 11:30 +0100, Mark Rutland wrote:
> > On Wed, Oct 25, 2023 at 08:42:55AM +0900, Masami Hiramatsu wrote:
> > > On Tue, 24 Oct 2023 16:08:12 +0100
> > > Mark Rutland  wrote:
> > > > On Tue, Oct 24, 2023 at 11:52:54PM +0900, Masami Hiramatsu (Google) 
> > > > wrote:
> > > > > From: Masami Hiramatsu (Google) 
> > > > >
> > > > > Use generic_cmpxchg_local() for arch_cmpxchg_local() implementation
> > > > > in SH architecture because it does not implement arch_cmpxchg_local().
> > > >
> > > > I do not think this is correct.
> > > >
> > > > The implementation in  is UP-only (and it 
> > > > only
> > > > disables interrupts), whereas arch/sh can be built SMP. We should 
> > > > probably add
> > > > some guards into  for that as we have in
> > > > .
> > >
> > > Isn't cmpxchg_local for the data which only needs to ensure to do cmpxchg
> > > on local CPU?
> > > So I think it doesn't care about the other CPUs (IOW, it should not 
> > > touched by
> > > other CPUs), so it only considers UP case. E.g. on x86, 
> > > arch_cmpxchg_local() is
> > > defined as raw "cmpxchg" without lock prefix.
> > >
> > > #define __cmpxchg_local(ptr, old, new, size)\
> > > __raw_cmpxchg((ptr), (old), (new), (size), "")
> > >
> >
> > Yes, you're right; sorry for the noise.
> >
> > For your original patch:
> >
> > Acked-by: Mark Rutland 
>
> Geert, what's your opinion on this?

While this looks OK on first sight (ARM includes the same file, even
on SMP), it does not seem to work?

For sh-allnoconfig, as reported by kernel test robot:

$ make ARCH=sh CROSS_COMPILE=sh2-linux- allnoconfig lib/objpool.o
lib/objpool.c: In function 'objpool_try_add_slot':
./include/linux/atomic/atomic-arch-fallback.h:384:27: error: implicit
declaration of function 'arch_cmpxchg_local'; did you mean
'raw_cmpxchg_local'? [-Werror=implicit-function-declaration]
  384 | #define raw_cmpxchg_local arch_cmpxchg_local
  |   ^~
./include/linux/atomic/atomic-arch-fallback.h:392:16: note: in
expansion of macro 'raw_cmpxchg_local'
  392 | ___r = raw_cmpxchg_local((_ptr), ___o, (_new)); \
  |^
./include/linux/atomic/atomic-instrumented.h:4980:9: note: in
expansion of macro 'raw_try_cmpxchg_local'
 4980 | raw_try_cmpxchg_local(__ai_ptr, __ai_oldp, __VA_ARGS__); \
  | ^
lib/objpool.c:169:19: note: in expansion of macro 'try_cmpxchg_local'
  169 | } while (!try_cmpxchg_local(>tail, , tail + 1));
  |   ^

For an SMP defconfig:

$ make ARCH=sh CROSS_COMPILE=sh4-linux-gnu- sdk7786_defconfig lib/objpool.o

./include/linux/atomic/atomic-arch-fallback.h:384:27: error: implicit
declaration of function ‘arch_cmpxchg_local’; did you mean
‘try_cmpxchg_local’? [-Werror=implicit-function-declaration]
  384 | #define raw_cmpxchg_local arch_cmpxchg_local
  |   ^~
./include/linux/atomic/atomic-arch-fallback.h:392:16: note: in
expansion of macro ‘raw_cmpxchg_local’
  392 | ___r = raw_cmpxchg_local((_ptr), ___o, (_new)); \
  |^
./include/linux/atomic/atomic-instrumented.h:4980:9: note: in
expansion of macro ‘raw_try_cmpxchg_local’
 4980 |     raw_try_cmpxchg_local(__ai_ptr, __ai_oldp, __VA_ARGS__); \
  | ^
lib/objpool.c:169:19: note: in expansion of macro ‘try_cmpxchg_local’
  169 | } while (!try_cmpxchg_local(>tail, , tail + 1));
  |   ^

Hiramatsu-san: do these build for you?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] neighbor: tracing: Move pin6 inside CONFIG_IPV6=y section

2023-10-16 Thread Geert Uytterhoeven

When CONFIG_IPV6=n, and building with W=1:

In file included from include/trace/define_trace.h:102,
 from include/trace/events/neigh.h:255,
 from net/core/net-traces.c:51:
include/trace/events/neigh.h: In function 
‘trace_event_raw_event_neigh_create’:
include/trace/events/neigh.h:42:34: error: variable ‘pin6’ set but not used 
[-Werror=unused-but-set-variable]
   42 | struct in6_addr *pin6;
  |  ^~~~
include/trace/trace_events.h:402:11: note: in definition of macro 
‘DECLARE_EVENT_CLASS’
  402 | { assign; } 
\
  |   ^~
include/trace/trace_events.h:44:30: note: in expansion of macro ‘PARAMS’
   44 |  PARAMS(assign),   \
  |  ^~
include/trace/events/neigh.h:23:1: note: in expansion of macro ‘TRACE_EVENT’
   23 | TRACE_EVENT(neigh_create,
  | ^~~
include/trace/events/neigh.h:41:9: note: in expansion of macro 
‘TP_fast_assign’
   41 | TP_fast_assign(
  | ^~
In file included from include/trace/define_trace.h:103,
 from include/trace/events/neigh.h:255,
 from net/core/net-traces.c:51:
include/trace/events/neigh.h: In function ‘perf_trace_neigh_create’:
include/trace/events/neigh.h:42:34: error: variable ‘pin6’ set but not used 
[-Werror=unused-but-set-variable]
   42 | struct in6_addr *pin6;
  |  ^~~~
include/trace/perf.h:51:11: note: in definition of macro 
‘DECLARE_EVENT_CLASS’
   51 | { assign; } 
\
  |   ^~
include/trace/trace_events.h:44:30: note: in expansion of macro ‘PARAMS’
   44 |  PARAMS(assign),   \
  |  ^~
include/trace/events/neigh.h:23:1: note: in expansion of macro ‘TRACE_EVENT’
   23 | TRACE_EVENT(neigh_create,
  | ^~~
include/trace/events/neigh.h:41:9: note: in expansion of macro 
‘TP_fast_assign’
   41 | TP_fast_assign(
  | ^~

Indeed, the variable pin6 is declared and initialized unconditionally,
while it is only used and needlessly re-initialized when support for
IPv6 is enabled.

Fix this by dropping the unused variable initialization, and moving the
variable declaration inside the existing section protected by a check
for CONFIG_IPV6.

Fixes: fc651001d2c5ca4f ("neighbor: Add tracepoint to __neigh_create")
Signed-off-by: Geert Uytterhoeven 
---
No changes in generated code.

 include/trace/events/neigh.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/neigh.h b/include/trace/events/neigh.h
index 5eaa1fa9917153f6..833143d0992e063b 100644
--- a/include/trace/events/neigh.h
+++ b/include/trace/events/neigh.h
@@ -39,7 +39,6 @@ TRACE_EVENT(neigh_create,
),
 
TP_fast_assign(
-   struct in6_addr *pin6;
__be32 *p32;
 
__entry->family = tbl->family;
@@ -47,7 +46,6 @@ TRACE_EVENT(neigh_create,
__entry->entries = atomic_read(>gc_entries);
__entry->created = n != NULL;
__entry->gc_exempt = exempt_from_gc;
-   pin6 = (struct in6_addr *)__entry->primary_key6;
p32 = (__be32 *)__entry->primary_key4;
 
if (tbl->family == AF_INET)
@@ -57,6 +55,8 @@ TRACE_EVENT(neigh_create,
 
 #if IS_ENABLED(CONFIG_IPV6)
if (tbl->family == AF_INET6) {
+   struct in6_addr *pin6;
+
pin6 = (struct in6_addr *)__entry->primary_key6;
*pin6 = *(struct in6_addr *)pkey;
}
-- 
2.34.1

Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED

2023-10-06 Thread Geert Uytterhoeven

Hi Thomas,

On Tue, Sep 19, 2023 at 9:57 PM Thomas Gleixner  wrote:
> Though it just occured to me that there are dragons lurking:
>
> arch/alpha/Kconfig: select ARCH_NO_PREEMPT
> arch/hexagon/Kconfig:   select ARCH_NO_PREEMPT
> arch/m68k/Kconfig:  select ARCH_NO_PREEMPT if !COLDFIRE
> arch/um/Kconfig:select ARCH_NO_PREEMPT
>
> So we have four architectures which refuse to enable preemption points,
> i.e. the only model they allow is NONE and they rely on cond_resched()
> for breaking large computations.

Looks like there is a fifth one hidden: although openrisc does not
select ARCH_NO_PREEMPT, it does not call preempt_schedule_irq() or
select GENERIC_ENTRY?

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX

2023-09-19 Thread Geert Uytterhoeven

Hi Michael,

On Tue, Sep 19, 2023 at 4:13 AM Michael Ellerman  wrote:
> Geert Uytterhoeven  writes:
> > Upstream Linux never had a "README.legal" file, but it was present
> > in early source releases of Linux/m68k.  It contained a simple copyright
> > notice and a link to a version of the "COPYING" file that predated the
> > addition of the "only valid GPL version is v2" clause.
> >
> > Get rid of the references to non-existent files by replacing the
> > boilerplate with SPDX license identifiers.
> >
> > Signed-off-by: Geert Uytterhoeven 
>
> LGTM.
>
> Acked-by: Michael Ellerman  (powerpc)

Can you please take it through the PPC tree?
Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v2 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX

2023-09-18 Thread Geert Uytterhoeven

Upstream Linux never had a "README.legal" file, but it was present
in early source releases of Linux/m68k.  It contained a simple copyright
notice and a link to a version of the "COPYING" file that predated the
addition of the "only valid GPL version is v2" clause.

Get rid of the references to non-existent files by replacing the
boilerplate with SPDX license identifiers.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - s/existant/existent/.
---
 arch/powerpc/kernel/ptrace/ptrace.c | 5 +
 arch/powerpc/kernel/signal.c| 5 +
 arch/powerpc/kernel/signal.h| 7 ++-
 3 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/kernel/ptrace/ptrace.c 
b/arch/powerpc/kernel/ptrace/ptrace.c
index 5d7a72b41ae71158..727ed4a145451356 100644
--- a/arch/powerpc/kernel/ptrace/ptrace.c
+++ b/arch/powerpc/kernel/ptrace/ptrace.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
 /*
  *  PowerPC version
  *Copyright (C) 1995-1996 Gary Thomas (g...@linuxppc.org)
@@ -9,10 +10,6 @@
  *
  * Modified by Cort Dougan (c...@hq.fsmlabs.com)
  * and Paul Mackerras (pau...@samba.org).
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License.  See the file README.legal in the main directory of
- * this archive for more details.
  */
 
 #include 
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index 68a91e553e14cea2..aa17e62f37547a79 100644
--- a/arch/powerpc/kernel/signal.c
+++ b/arch/powerpc/kernel/signal.c
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
 /*
  * Common signal handling code for both 32 and 64 bits
  *
  *Copyright (c) 2007 Benjamin Herrenschmidt, IBM Corporation
  *Extracted from signal_32.c and signal_64.c
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License.  See the file README.legal in the main directory of
- * this archive for more details.
  */
 
 #include 
diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index a429c57ed4331805..58ecea1cdc27ae80 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -1,10 +1,7 @@
-/*
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *Copyright (c) 2007 Benjamin Herrenschmidt, IBM Corporation
  *Extracted from signal_32.c and signal_64.c
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License.  See the file README.legal in the main directory of
- * this archive for more details.
  */
 
 #ifndef _POWERPC_ARCH_SIGNAL_H
-- 
2.34.1

[PATCH v2 0/2] m68k/powerpc: Kill references to non-existent README.legal

2023-09-18 Thread Geert Uytterhoeven

Hi all,

Several source files contain license boilerplate that refers to the file
"README.legal", which never existed in upstream Linux. This is a relic
from the early port of Linux to the m68k processor family, before it was
merged in v1.3.94. Later, copies of this boilerplate ended up in the
PowerPC port.

The "README.legal" file (from e.g. [1]) read:

---8<-
Legal information about the Linux/68k software package

All files contained in this archive are copyrighted by one or more
person. They are not in the public domain.

Most of the files are copyrighted by Linus Torvalds, the original
writer of Linux for IBM PC clone systems. Some parts are copyrighted
by other IBM PC linux developers. Other parts are copyrighted by
Linux/68k developers.

This package is subject to the terms and conditions of the GNU General
Public License. A copy of this license may be found in the file named
"COPYING" which should be in the same directory as this file. If the
file has been omitted, you may obtain it by writing to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
->8---

Note that the "COPYING" file at that time corresponded to the version
from upstream Linux v0.99.11 until v2.1.104, and thus predated the
addition of the "only valid GPL version is v2" clause in v2.4.0-test8.

This patch series gets rid of the references to README.legal by
replacing the boilerplate with SPDX license identifiers.

Changes compared to v1[2]:
- Add Acked-by,
- s/existant/existent/.

Thanks for your comments!

[1]
https://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/680x0/v0.9/linux-0.9.tar.gz
[2] "[PATCH 0/2] m68k/powerpc: Kill references to non-existent README.legal
https://lore.kernel.org/r/cover.1694095086.git.ge...@linux-m68k.org

Geert Uytterhoeven (2):
m68k: Replace GPL 2.0+ README.legal boilerplate with SPDX
powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX

--
2.34.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v2 1/2] m68k: Replace GPL 2.0+ README.legal boilerplate with SPDX

2023-09-18 Thread Geert Uytterhoeven

Upstream Linux never had a "README.legal" file, but it was present
in early source releases of Linux/m68k.  It contained a simple copyright
notice and a link to a version of the "COPYING" file that predated the
addition of the "only valid GPL version is v2" clause.

Get rid of the references to non-existent files by replacing the
boilerplate with SPDX license identifiers.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Greg Ungerer 
---
v2:
  - Add Acked-by,
  - s/existant/existent/.
---
 arch/m68k/68000/entry.S | 7 ++-
 arch/m68k/bvme6000/config.c | 5 +
 arch/m68k/coldfire/entry.S  | 7 ++-
 arch/m68k/ifpsp060/Makefile | 6 ++
 arch/m68k/kernel/entry.S| 7 ++-
 arch/m68k/kernel/head.S | 8 ++--
 arch/m68k/mvme147/config.c  | 5 +
 arch/m68k/mvme16x/config.c  | 5 +
 arch/m68k/q40/config.c  | 5 +
 9 files changed, 14 insertions(+), 41 deletions(-)

diff --git a/arch/m68k/68000/entry.S b/arch/m68k/68000/entry.S
index 7d63e2f1555a03dc..72e95663b62ffd54 100644
--- a/arch/m68k/68000/entry.S
+++ b/arch/m68k/68000/entry.S
@@ -1,12 +1,9 @@
-/*
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  entry.S -- non-mmu 68000 interrupt and exception entry points
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
- *
  * Linux/m68k support by Hamish Macdonald
  */
 
diff --git a/arch/m68k/bvme6000/config.c b/arch/m68k/bvme6000/config.c
index e604fe6602461334..8a2ee69a09f6659c 100644
--- a/arch/m68k/bvme6000/config.c
+++ b/arch/m68k/bvme6000/config.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
 /*
  *  arch/m68k/bvme6000/config.c
  *
@@ -8,10 +9,6 @@
  *  linux/amiga/config.c
  *
  *  Copyright (C) 1993 Hamish Macdonald
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
  */
 
 #include 
diff --git a/arch/m68k/coldfire/entry.S b/arch/m68k/coldfire/entry.S
index 35104c5417ff4d07..4ea08336e2fb0aae 100644
--- a/arch/m68k/coldfire/entry.S
+++ b/arch/m68k/coldfire/entry.S
@@ -1,4 +1,5 @@
-/*
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  entry.S  -- interrupt and exception processing for ColdFire
  *
  *  Copyright (C) 1999-2007, Greg Ungerer (g...@snapgear.com)
@@ -13,10 +14,6 @@
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
- *
  * Linux/m68k support by Hamish Macdonald
  *
  * 68060 fixes by Jesper Skov
diff --git a/arch/m68k/ifpsp060/Makefile b/arch/m68k/ifpsp060/Makefile
index 56b530a96c2f33b5..00d0621f547ccb93 100644
--- a/arch/m68k/ifpsp060/Makefile
+++ b/arch/m68k/ifpsp060/Makefile
@@ -1,7 +1,5 @@
-# Makefile for 680x0 Linux 68060 integer/floating point support package
+# SPDX-License-Identifier: GPL-2.0-or-later
 #
-# This file is subject to the terms and conditions of the GNU General Public
-# License.  See the file "README.legal" in the main directory of this archive
-# for more details.
+# Makefile for 680x0 Linux 68060 integer/floating point support package
 
 obj-y := fskeleton.o iskeleton.o os.o
diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index 4dd2fd7acba9ea07..3bcdd32a6b36613d 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -1,13 +1,10 @@
-/* -*- mode: asm -*-
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ * -*- mode: asm -*-
  *
  *  linux/arch/m68k/kernel/entry.S
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
- *
  * Linux/m68k support by Hamish Macdonald
  *
  * 68060 fixes by Jesper Skov
diff --git a/arch/m68k/kernel/head.S b/arch/m68k/kernel/head.S
index 9e812d8606be8301..852255cf60dec132 100644
--- a/arch/m68k/kernel/head.S
+++ b/arch/m68k/kernel/head.S
@@ -1,4 +1,5 @@
-/* -*- mode: asm -*-
+/* SPDX-License-Identifier: GPL-2.0-or-later
+** -*- mode: asm -*-
 **
 ** head.S -- This file contains the initial boot code for the
 **  Linux/68k kernel.
@@ -25,11 +26,6 @@
 **for linux-2.1.115
 ** 1999/02/11  Richard Zidlicky: added Q40 support (initial version 99/01/01)
 ** 2004/05/13 Kars de Jong: Finalised HP300 support
-**
-** This file is subject to the terms and conditions of the GNU General Public
-** License. See the file README.legal in the main directory of this archive
-** for more details.
-**
 */
 
 /*
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index 7dfacd0b207a9750..8b5dc07f0811f2fc 100644
--- a/arch/m68k/mvme147/config.c

Re: [PATCH] um,ethertap: refactor deprecated strncpy

2023-09-12 Thread Geert Uytterhoeven

Hi Justin,

Thanks for your patch!

On Mon, Sep 11, 2023 at 7:53 PM Justin Stitt  wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
>
> `gate_buf` should always be NUL-terminated and does not require
> NUL-padding. It is used as a string arg inside an argv array given to

Can you please explain why it does not require NUL-padding?
It looks like this buffer is passed eventually to a user space
application, thus possibly leaking uninitialized stack data.

> `run_helper()`. Due to this, let's use `strscpy` as it guarantees
> NUL-terminated on the destination buffer preventing potential buffer
> overreads [2].
>
> This exact invocation was changed from `strcpy` to `strncpy` in commit
> 7879b1d94badb ("um,ethertap: use strncpy") back in 2015. Let's continue
> hardening our `str*cpy` apis and use the newer and safer `strscpy`!
>
> Link: 
> www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings[1]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html 
> [2]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kernel.org
> Cc: Kees Cook 
> Signed-off-by: Justin Stitt 
> ---
>  arch/um/os-Linux/drivers/ethertap_user.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/um/os-Linux/drivers/ethertap_user.c 
> b/arch/um/os-Linux/drivers/ethertap_user.c
> index 9483021d86dd..3363851a4ae8 100644
> --- a/arch/um/os-Linux/drivers/ethertap_user.c
> +++ b/arch/um/os-Linux/drivers/ethertap_user.c
> @@ -105,7 +105,7 @@ static int etap_tramp(char *dev, char *gate, int 
> control_me,
> sprintf(data_fd_buf, "%d", data_remote);
> sprintf(version_buf, "%d", UML_NET_VERSION);
> if (gate != NULL) {
> -   strncpy(gate_buf, gate, 15);
> +   strscpy(gate_buf, gate, sizeof(gate_buf));
> args = setup_args;
> }
> else args = nosetup_args;
>
> ---
> base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
> change-id: 
> 20230911-strncpy-arch-um-os-linux-drivers-ethertap_user-c-859160d13f59

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: Build regressions/improvements in v5.19-rc1

2022-06-06 Thread Geert Uytterhoeven


On Mon, 6 Jun 2022, Geert Uytterhoeven wrote:

Below is the list of build error/warning regressions/improvements in
v5.19-rc1[1] compared to v5.18[2].

Summarized:
 - build errors: +9/-10



[1] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f2906aa863381afb0015a9eb7fefad885d4e5a56/
 (all 135 configs)
[2] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/4b0986a3613c92f4ec1bdc7f60ec66fea135991f/
 (131 out of 135 configs)



9 error regressions:
 + /kisskb/src/arch/um/include/asm/page.h: error: too few arguments to function 
'to_phys':  => 105:20
 + /kisskb/src/drivers/nvdimm/pmem.c: error: conflicting types for 'to_phys':  
=> 48:20
 + /kisskb/src/drivers/nvdimm/pmem.c: error: control reaches end of non-void 
function [-Werror=return-type]:  => 324:1


um-x86_64/um-allyesconfig


 + /kisskb/src/arch/xtensa/kernel/entry.S: Error: unknown pseudo-op: `.bss':  
=> 2176


xtensa-gcc11/xtensa-allmodconfig


 + /kisskb/src/drivers/tty/serial/sh-sci.c: error: unused variable 'sport' 
[-Werror=unused-variable]:  => 2655:26


sh4-gcc11/se7619_defconfig
sh4-gcc11/sh-allmodconfig

Fix available
https://lore.kernel.org/all/4ed0a7a0d3fa912a5b44c451884818f2c138ef42.1644914600.git.geert+rene...@glider.be


 + /kisskb/src/include/linux/fortify-string.h: error: call to 
'__write_overflow_field' declared with attribute warning: detected write beyond 
size of field (1st parameter); maybe use struct_group()? 
[-Werror=attribute-warning]:  => 344:25


powerpc-gcc11/ppc64_book3e_allmodconfig


 + /kisskb/src/include/ufs/ufshci.h: error: initializer element is not constant:  
=> 245:36


mipsel-gcc5/mips-allmodconfig
powerpc-gcc5/powerpc-allmodconfig

FTR, include/ufs/ufshci.h lacks a MAINTAINERS entry.


 + error: relocation truncated to fit: R_SPARC_WDISP22 against `.init.text':  
=> (.head.text+0x5100), (.head.text+0x5040)
 + error: relocation truncated to fit: R_SPARC_WDISP22 against symbol 
`leon_smp_cpu_startup' defined in .text section in 
arch/sparc/kernel/trampoline_32.o:  => (.init.text+0xa4)


sparc64-gcc5/sparc-allmodconfig


3 warning regressions:



 + arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for ZPOOL: 
 => 61
 + arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for ZPOOL:  
=> 37


Will be fixed by the m68k defconfig update for v5.20.

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems

2021-04-20 Thread Geert Uytterhoeven

Hi Willy,

On Sat, Apr 17, 2021 at 4:49 AM Matthew Wilcox  wrote:
> Replacement patch to fix compiler warning.
>
> From: "Matthew Wilcox (Oracle)" 
> Date: Fri, 16 Apr 2021 16:34:55 -0400
> Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
> To: bro...@redhat.com
> Cc: linux-kernel@vger.kernel.org,
> linux...@kvack.org,
> net...@vger.kernel.org,
> linuxppc-...@lists.ozlabs.org,
> linux-arm-ker...@lists.infradead.org,
> linux-m...@vger.kernel.org,
> ilias.apalodi...@linaro.org,
> mcr...@linux.microsoft.com,
> grygorii.stras...@ti.com,
> a...@kernel.org,
> h...@lst.de,
> linux-snps-...@lists.infradead.org,
> mho...@kernel.org,
> mgor...@suse.de
>
> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019.  When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
>
> Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
> This restores the alignment to that of an unsigned long, and also fixes a
> potential problem where (on a big endian platform), the bit used to denote
> PageTail could inadvertently get set, and a racing get_user_pages_fast()
> could dereference a bogus compound_head().
>
> Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> Signed-off-by: Matthew Wilcox (Oracle) 

Thanks for your patch!

> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -97,10 +97,10 @@ struct page {
> };
> struct {/* page_pool used by netstack */
> /**
> -* @dma_addr: might require a 64-bit value even on
> +* @dma_addr: might require a 64-bit value on
>  * 32-bit architectures.
>  */
> -   dma_addr_t dma_addr;
> +   unsigned long dma_addr[2];

So we get two 64-bit words on 64-bit platforms, while only one is
needed?

Would

unsigned long _dma_addr[sizeof(dma_addr_t) / sizeof(unsigned long)];

work?

Or will the compiler become too overzealous, and warn about the use
of ...[1] below, even when unreachable?
I wouldn't mind an #ifdef instead of an if () in the code below, though.

> };
> struct {/* slab, slob and slub */
> union {
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..ad6154dc206c 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct 
> page_pool *pool,
>
>  static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>  {
> -   return page->dma_addr;
> +   dma_addr_t ret = page->dma_addr[0];
> +   if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +   ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;

We don't seem to have a handy macro for a 32-bit left shift yet...

But you can also avoid the warning using

ret |= (u64)page->dma_addr[1] << 32;

> +   return ret;
> +}
> +
> +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> +{
> +   page->dma_addr[0] = addr;
> +   if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +   page->dma_addr[1] = addr >> 16 >> 16;

... but we do have upper_32_bits() for a 32-bit right shift.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

Hi Andy,

On Mon, Apr 19, 2021 at 4:14 PM Andy Shevchenko
 wrote:
> On Mon, Apr 19, 2021 at 4:58 PM Andy Shevchenko
>  wrote:
> > On Mon, Apr 19, 2021 at 4:54 PM Geert Uytterhoeven  
> > wrote:
>
> > > > In any case it's not true. We have the platform drivers w/o legacy
> > > > users that are not dependent on OF.
> > >
> > > Example? ;-)
> >
> > i2c-owl.c
>
> In case you want more
> sound/sparc/amd7930.c

SND_SUN_AMD7930 depends on SND_SPARC && SBUS
SND_SPARC depends on SPARC
SPARC selects OF

Hence, SND_SUN_AMD7930 depends on OF.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

Hi Andy,

On Mon, Apr 19, 2021 at 3:58 PM Andy Shevchenko
 wrote:
> On Mon, Apr 19, 2021 at 4:54 PM Geert Uytterhoeven  
> wrote:
> > On Mon, Apr 19, 2021 at 3:35 PM Andy Shevchenko
> >  wrote:
> > > On Mon, Apr 19, 2021 at 4:02 PM Geert Uytterhoeven  
> > > wrote:
> > > > On Thu, Apr 15, 2021 at 10:50 AM Andy Shevchenko
> > > >  wrote:
> > > > > On Thu, Apr 15, 2021 at 3:43 AM Geert Uytterhoeven 
> > > > >  wrote:
> > > > > > On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
> > > > > >  wrote:
> > > > > > > On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven 
> > > > > > > wrote:
> > > > > > > > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > > > > > > >  wrote:
> > > > > > > > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven 
> > > > > > > > > wrote:
> > > > > > > > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang 
> > > > > > > > > >  wrote:
> > >
> > > ...
> > >
> > > > > > > > > > I guess it's still fine to add a dependency on ACPI?
> > > > > > > > >
> > > > > > > > > But why?
> > > > > > > >
> > > > > > > > Please tell me how/when the driver is used when CONFIG_ACPI=n.
> > > > > > >
> > > > > > > I'm not using it at all. Ask the author :-)
> > > > > > >
> > > > > > > But if we follow your logic, then we need to mark all the 
> > > > > > > _platform_ drivers
> > > > > > > for x86 world as ACPI dependent? This sounds ugly.
> > > > > >
> > > > > > Do all other x86 platform drivers have (1) an .acpi_match_table[] 
> > > > > > and
> > > > > > (2) no other way of instantiating their devices?
> > > > > > The first driver from the top of my memory I looked at is rtc-cmos:
> > > > > > it has no .acpi_match_table[], and the rtc-cmos device is 
> > > > > > instantiated
> > > > > > from arch/x86/kernel/rtc.c.
> > > > > >
> > > > > > For drivers with only an .of_match_table(), and no legacy users
> > > > > > instantiating platform devices, we do have dependencies on OF.
> > > > >
> > > > > This is not true. Entire IIO subsystem is an example.
> > > >
> > > > Do you care to elaborate?
> > > > Three quarters of the IIO drivers are I2C and SPI drivers, and thus not
> > > > subject to the above.
> > >
> > > It seems I missed that you are talking about platform device drivers.
> >
> > OK.
> >
> > > In any case it's not true. We have the platform drivers w/o legacy
> > > users that are not dependent on OF.
> >
> > Example? ;-)
>
> i2c-owl.c

I2C_OWL depends on ARCH_ACTIONS || COMPILE_TEST

(arm32) ARCH_ACTIONS depends on ARCH_MULTI_V7
 depends on ARCH_MULTIPLATFORM
 ARCH_MULTIPLATFORM selects USE_OF
 USE_OF selects OF
ARCH_MULTI_V7 selects ARCH_MULTI_V6_V7

(arm64) ARM64 selects OF

so we do have a dependency on OF, unless we're compile-testing.

> > > They may _indirectly_ be dependent, but this is fine as I stated above
> > > when suggested to move ACPI dependency on ARCH_xxx level.
> >
> > As per the response from the driver maintainer
> > https://lore.kernel.org/linux-arm-kernel/bd8db435-24e1-5ab3-6b35-1d4d8a292...@hisilicon.com/,
> > there is no dependency on ARCH_HISI, so moving the ACPI dependency
> > up won't help.
>
> So, an ACPI dependency is simply not applicable here as it's a compile
> dependency as well, which is not a limitation for this driver. Again,
> talk to Masahiro how to handle this, but I don't see any good
> justification to have ACPI (compile time) dependency here. So, again
> NAK!

Please tell me how this driver will be probed when CONFIG_ACPI
is disabled (it cannot, as nothing instantiates platform devices of the
right type, so there is no reason to bother the user with a question about
this driver when configuring his kernel).

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

Hi Andy,

On Mon, Apr 19, 2021 at 3:35 PM Andy Shevchenko
 wrote:
> On Mon, Apr 19, 2021 at 4:02 PM Geert Uytterhoeven  
> wrote:
> > On Thu, Apr 15, 2021 at 10:50 AM Andy Shevchenko
> >  wrote:
> > > On Thu, Apr 15, 2021 at 3:43 AM Geert Uytterhoeven  
> > > wrote:
> > > > On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
> > > >  wrote:
> > > > > On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > > > > > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > > > > >  wrote:
> > > > > > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven 
> > > > > > > wrote:
> > > > > > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang 
> > > > > > > >  wrote:
>
> ...
>
> > > > > > > > I guess it's still fine to add a dependency on ACPI?
> > > > > > >
> > > > > > > But why?
> > > > > >
> > > > > > Please tell me how/when the driver is used when CONFIG_ACPI=n.
> > > > >
> > > > > I'm not using it at all. Ask the author :-)
> > > > >
> > > > > But if we follow your logic, then we need to mark all the _platform_ 
> > > > > drivers
> > > > > for x86 world as ACPI dependent? This sounds ugly.
> > > >
> > > > Do all other x86 platform drivers have (1) an .acpi_match_table[] and
> > > > (2) no other way of instantiating their devices?
> > > > The first driver from the top of my memory I looked at is rtc-cmos:
> > > > it has no .acpi_match_table[], and the rtc-cmos device is instantiated
> > > > from arch/x86/kernel/rtc.c.
> > > >
> > > > For drivers with only an .of_match_table(), and no legacy users
> > > > instantiating platform devices, we do have dependencies on OF.
> > >
> > > This is not true. Entire IIO subsystem is an example.
> >
> > Do you care to elaborate?
> > Three quarters of the IIO drivers are I2C and SPI drivers, and thus not
> > subject to the above.
>
> It seems I missed that you are talking about platform device drivers.

OK.

> In any case it's not true. We have the platform drivers w/o legacy
> users that are not dependent on OF.

Example? ;-)

> They may _indirectly_ be dependent, but this is fine as I stated above
> when suggested to move ACPI dependency on ARCH_xxx level.

As per the response from the driver maintainer
https://lore.kernel.org/linux-arm-kernel/bd8db435-24e1-5ab3-6b35-1d4d8a292...@hisilicon.com/,
there is no dependency on ARCH_HISI, so moving the ACPI dependency
up won't help.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

Hi Andy,

On Thu, Apr 15, 2021 at 10:50 AM Andy Shevchenko
 wrote:
> On Thu, Apr 15, 2021 at 3:43 AM Geert Uytterhoeven  
> wrote:
> > On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
> >  wrote:
> > > On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > > >  wrote:
> > > > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang 
> > > > > >  wrote:
>
> ...
>
> > > > > > I guess it's still fine to add a dependency on ACPI?
> > > > >
> > > > > But why?
> > > >
> > > > Please tell me how/when the driver is used when CONFIG_ACPI=n.
> > >
> > > I'm not using it at all. Ask the author :-)
> > >
> > > But if we follow your logic, then we need to mark all the _platform_ 
> > > drivers
> > > for x86 world as ACPI dependent? This sounds ugly.
> >
> > Do all other x86 platform drivers have (1) an .acpi_match_table[] and
> > (2) no other way of instantiating their devices?
> > The first driver from the top of my memory I looked at is rtc-cmos:
> > it has no .acpi_match_table[], and the rtc-cmos device is instantiated
> > from arch/x86/kernel/rtc.c.
> >
> > For drivers with only an .of_match_table(), and no legacy users
> > instantiating platform devices, we do have dependencies on OF.
>
> This is not true. Entire IIO subsystem is an example.

Do you care to elaborate?
Three quarters of the IIO drivers are I2C and SPI drivers, and thus not
subject to the above.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH V3 5/5] arm64: dts: renesas: beacon kits: Setup AVB refclk

Hi Adam,

On Sat, Apr 17, 2021 at 3:54 PM Adam Ford  wrote:
> On Thu, Mar 4, 2021 at 2:04 AM Geert Uytterhoeven  
> wrote:
> > On Wed, Feb 24, 2021 at 12:52 PM Adam Ford  wrote:
> > > The AVB refererence clock assumes an external clock that runs
> >
> > reference
> >
> > > automatically.  Because the Versaclock is wired to provide the
> > > AVB refclock, the device tree needs to reference it in order for the
> > > driver to start the clock.
> > >
> > > Signed-off-by: Adam Ford 
> >
> > Reviewed-by: Geert Uytterhoeven 
> > i.e. will queue in renesas-devel (with the typo fixed) once the DT
> > bindings have been accepted.
>
> Geert,
>
> Since the refclk update and corresponding dt-bindings are in net-next,
> are you OK applying the rest of the DT changes so they can get into
> 5.13?

Queueing in renesas-devel for v5.14, as the soc deadline for v5.13
has already passed two weeks ago.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH V3 3/5] arm64: dts: renesas: Add fck to etheravb-rcar-gen3 clock-names list

On Wed, Feb 24, 2021 at 12:52 PM Adam Ford  wrote:
> The bindings have been updated to support two clocks, but the
> original clock now requires the name fck.  Add a clock-names
> list in the device tree with fck in it.
>
> Signed-off-by: Adam Ford 
> Reviewed-by: Geert Uytterhoeven 

queueing in renesas-devel for v5.14, with an additional update for
the recently added r8a779a0.dtsi.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Build regressions/improvements in v5.12-rc8

kinit.c: warning: 'test_big_hole_zero' uses 
dynamic stack allocation:  => 255:15
  + /kisskb/src/mm/slub.c: warning: '___slab_alloc' uses dynamic stack 
allocation:  => 2768:1
  + /kisskb/src/mm/slub.c: warning: '__slab_free' uses dynamic stack 
allocation:  => 3092:1
  + /kisskb/src/mm/slub.c: warning: 'deactivate_slab.isra.65' uses dynamic 
stack allocation:  => 2304:1
  + /kisskb/src/mm/slub.c: warning: 'get_partial_node.isra.64' uses dynamic 
stack allocation:  => 2014:1
  + /kisskb/src/mm/slub.c: warning: 'unfreeze_partials.isra.63' uses dynamic 
stack allocation:  => 2372:1
  + /kisskb/src/mm/z3fold.c: warning: 'z3fold_reclaim_page.constprop' uses 
dynamic stack allocation:  => 1485:1
  + /kisskb/src/net/bridge/br_netlink.c: warning: 'br_fill_linkxstats' uses 
dynamic stack allocation:  => 1753:1
  + /kisskb/src/net/bridge/br_vlan.c: warning: 'br_vlan_fill_vids' uses dynamic 
stack allocation:  => 1672:1
  + /kisskb/src/net/bridge/netfilter/ebtables.c: warning: 
'compat_copy_everything_to_user' uses dynamic stack allocation:  => 1791:1
  + modpost: WARNING: modpost: Symbol info of vmlinux is missing. Unresolved 
symbol check will be entirely skipped.:  => N/A

10 warning improvements:
  - /kisskb/src/arch/sparc/include/asm/cmpxchg_32.h: warning: value computed is 
not used [-Wunused-value]: 28:22 => 
  - 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c: 
warning: (near initialization for 'cmd.lock_hw') [-Wmissing-braces]: 36:8 => 
  - 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c: 
warning: missing braces around initializer [-Wmissing-braces]: 36:8 => 
  - /kisskb/src/drivers/net/ethernet/aurora/nb8800.h: warning: "TCR_DIE" 
redefined: 92 => 
  - /kisskb/src/drivers/net/ethernet/freescale/fec_main.c: warning: unused 
variable 'pdata' [-Wunused-variable]: 1667:28 => 
  - /kisskb/src/drivers/net/ethernet/freescale/fec_main.c: warning: unused 
variable 'val' [-Wunused-variable]: 948:6 => 
  - /kisskb/src/drivers/rtc/rtc-rx6110.c: warning: 'rx6110_probe' defined but 
not used [-Wunused-function]: 314:12 => 
  - arch/ia64/configs/generic_defconfig: warning: override: reassigning to 
symbol ATA: 58 => 
  - arch/ia64/configs/generic_defconfig: warning: override: reassigning to 
symbol ATA_PIIX: 59 => 
  - warning: unmet direct dependencies detected for COMPAT_BINFMT_ELF: N/A => 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

Hi Dominique,

CC Arnd (soc_device_match() author)

On Mon, Apr 19, 2021 at 7:03 AM Dominique MARTINET
 wrote:
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo 
> > Update all the code that use soc_device_match
>
> A single patch might be difficult to accept for all components, a each
> maintainer will probably want to have a say on their subsystem?
>
> I would suggest to split these for a non-RFC version; a this will really
> need to be case-by-case handling.
>
> > because add support for soc_device_match returning -EPROBE_DEFER.
>
> (English does not parse here for me)
>
> I've only commented a couple of places in the code itself, but this
> doesn't seem to add much support for errors, just sweep the problem
> under the rug.
>
> > Signed-off-by: Alice Guo 
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
> > index 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >   }
> >
> >   match = soc_device_match(sysc_soc_feat_match);
> > - if (!match)
> > + if (!match || IS_ERR(match))
> >   return 0;
>
> This function handles errors, I would recommend returning the error as
> is if soc_device_match returned one so the probe can be retried later.

Depends...

> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[] 
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)
> >  {
> > + const struct soc_device_attribute *match;
> >   const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >   u32 cpg_mode;
> >   int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device 
> > *dev)
> >   return -EINVAL;
> >   }
> >
> > - if (soc_device_match(r8a7795es1)) {
> > + match = soc_device_match(r8a7795es1);
> > + if (!IS_ERR(match) && match) {
>
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug
> problems because the driver potentially assumed the wrong device when
> it's just not ready yet.

When running on R-Car H3, there will always be a match device, as
the SoC device is registered early.

>
> >   cpg_core_nullify_range(r8a7795_core_clks,
> >  ARRAY_SIZE(r8a7795_core_clks),
> >  R8A7795_CLK_S0D2, R8A7795_CLK_S0D12);
> > [...]
> > diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> > index eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] = {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)
> >  {
> > + const struct soc_device_attribute *match1, *match2;
> >   unsigned int i;
> >
> >   /*
> >* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >* For Other SoCs, this returns true anyway.
> >*/
> > - if (!soc_device_match(soc_needs_opt_in))
> > + match1 = soc_device_match(soc_needs_opt_in);
> > + if (!IS_ERR(match1) && !match1)
>
> I'm not sure what you intended to do, but !match1 already means there is
> no error so the original code is identical.
>
> In this case ipmmu_device_is_allowed does not allow errors so this is
> one of the "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly,
> so in this case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
>
> ...
> This is going to need quite some more work to be acceptable, in my
> opinion, but I think it should be possible.

In general, this is very hard to do, IMHO. Some drivers may be used on
multiple platforms, some of them registering an SoC device, some of
them not registering an SoC device.  So there is no way to know the
difference between "SoC device not registered, intentionally", and
"SoC device not yet registered".

soc_device_match() should only be used as a last resort, to identify
systems that cannot be identified otherwise.  Typically this is used for
quirks, which should only be enabled on a very specific subset of
systems.  IMHO such systems should make sure soc_device_match()
is available early, by registering their SoC device early.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [RFC v1 PATCH 1/3] drivers: soc: add support for soc_device_match returning -EPROBE_DEFER

Hi Alice,

CC Arnd (soc_device_match() author)

On Mon, Apr 19, 2021 at 6:28 AM Alice Guo (OSS)  wrote:
> From: Alice Guo 
>
> In i.MX8M boards, the registration of SoC device is later than caam
> driver which needs it. Caam driver needs soc_device_match to provide
> -EPROBE_DEFER when no SoC device is registered and no
> early_soc_dev_attr.

I'm wondering if this is really a good idea: soc_device_match() is a
last-resort low-level check, and IMHO should be made available early on,
so there is no need for -EPROBE_DEFER.

>
> Signed-off-by: Alice Guo 

Thanks for your patch!

> --- a/drivers/base/soc.c
> +++ b/drivers/base/soc.c
> @@ -110,6 +110,7 @@ static void soc_release(struct device *dev)
>  }
>
>  static struct soc_device_attribute *early_soc_dev_attr;
> +static bool soc_dev_attr_init_done = false;

Do you need this variable?

>
>  struct soc_device *soc_device_register(struct soc_device_attribute 
> *soc_dev_attr)
>  {
> @@ -157,6 +158,7 @@ struct soc_device *soc_device_register(struct 
> soc_device_attribute *soc_dev_attr
> return ERR_PTR(ret);
> }
>
> +   soc_dev_attr_init_done = true;
> return soc_dev;
>
>  out3:
> @@ -246,6 +248,9 @@ const struct soc_device_attribute *soc_device_match(
> if (!matches)
> return NULL;
>
> +   if (!soc_dev_attr_init_done && !early_soc_dev_attr)

if (!soc_bus_type.p && !early_soc_dev_attr)

> +   return ERR_PTR(-EPROBE_DEFER);
> +
> while (!ret) {
> if (!(matches->machine || matches->family ||
>   matches->revision || matches->soc_id))

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH V2] mm: Define default value for FIRST_USER_ADDRESS

On Fri, Apr 16, 2021 at 7:17 AM Anshuman Khandual
 wrote:
> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplication the
> same code all over. Instead just define a generic default value (i.e 0UL)
> for FIRST_USER_ADDRESS and let the platforms override when required. This
> makes it much cleaner with reduced code.
>
> The default FIRST_USER_ADDRESS here would be skipped in 
> when the given platform overrides its value via .

> Signed-off-by: Anshuman Khandual 

>  arch/m68k/include/asm/pgtable_mm.h   | 1 -

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] net: ethernet: ravb: Fix release of refclk

On Sat, Apr 17, 2021 at 3:23 PM Adam Ford  wrote:
> The call to clk_disable_unprepare() can happen before priv is
> initialized. This means moving clk_disable_unprepare out of
> out_release into a new label.
>
> Fixes: 8ef7adc6beb2("net: ethernet: ravb: Enable optional refclk")
> Signed-off-by: Adam Ford 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 5/6] kunit: mptcp: adhear to KUNIT formatting standard

Hi David,

On Sat, Apr 17, 2021 at 6:24 AM David Gow  wrote:
> > Like patch 1/6, I can apply it in MPTCP tree and send it later to
> > net-next with other patches.
> > Except if you guys prefer to apply it in KUnit tree and send it to
> > linux-next?
>
> Given 1/6 is going to net-next, it makes sense to send this out that
> way too, then, IMHO.
> The only slight concern I have is that the m68k test config patch in
> the series will get split from the others, but that should resolve
> itself when they pick up the last patch.

I can apply the m68k test config patch when all other parts have
entered mainline.  Note that I would have made the same changes
myself anyway, on -rc1 defconfig refresh.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 4/7] arm64: dts: renesas: r8a77970: Add csi40 port@0

Hi Laurent,

On Thu, Apr 15, 2021 at 4:47 PM Laurent Pinchart
 wrote:
> On Thu, Apr 15, 2021 at 02:25:59PM +0200, Jacopo Mondi wrote:
> > Declare port@0 in the csi40 device node and leave it un-connected.
> > Each board .dts file will connect the port as it requires.
> >
> > Signed-off-by: Jacopo Mondi 
>
> The port exists at the hardware level, so including it here sounds good.
> The DT binding even makes the port mandatory :-)

But the latter is subject to change?

[PATCH] media: dt-bindings: media: renesas,csi2: Node port@0 is not mandatory
https://lore.kernel.org/linux-devicetree/20210413155346.2471776-1-niklas.soderlund+rene...@ragnatech.se/

> > --- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > @@ -1106,6 +1106,10 @@ ports {
> >   #address-cells = <1>;
> >   #size-cells = <0>;
> >
> > + port@0 {
> > + reg = <0>;
> > + };
> > +
> >   port@1 {
> >   #address-cells = <1>;
> >   #size-cells = <0>;
\
Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH bpf-next v3 3/6] bpf: Add a bpf_snprintf helper

Hi Andrii,

On Thu, Apr 15, 2021 at 12:58 AM Andrii Nakryiko
 wrote:
> On Wed, Apr 14, 2021 at 11:30 AM Florent Revest  wrote:
> > On Wed, Apr 14, 2021 at 8:02 PM Geert Uytterhoeven  
> > wrote:
> > > On Wed, Apr 14, 2021 at 9:41 AM Andrii Nakryiko
> > >  wrote:
> > > > On Mon, Apr 12, 2021 at 8:38 AM Florent Revest  
> > > > wrote:
> > > > > +   fmt = (char *)fmt_addr + fmt_map_off;
> > > > > +
> > > >
> > > > bot complained about lack of (long) cast before fmt_addr, please address
> > >
> > > (uintptr_t), I assume?
> >
> > (uintptr_t) seems more correct to me as well. However, I just had a
> > look at the rest of verifier.c and (long) casts are already used
> > pretty much everywhere whereas uintptr_t isn't used yet.
> > I'll send a v4 with a long cast for the sake of consistency with the
> > rest of the verifier.
>
> right, I don't care about long or uintptr_t, both are guaranteed to
> work, I just remember seeing a lot of code with (long) cast. I have no
> preference.

AFAIR, uintptr_t was introduced only in C99. Early Linux code predates that,
hence uses long, and this behavior was of course copied to new code.

Please use uintptr_t in new code.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] m68k: Remove unneeded semicolon

On Thu, Apr 15, 2021 at 5:15 AM Wan Jiabing  wrote:
> Fix the following coccicheck warning:
>
> ./arch/m68k/include/asm/sun3xflop.h:109:2-3: Unneeded semicolon
>
> Signed-off-by: Wan Jiabing 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in the m68k for-v5.14 branch.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 1/5] dt-bindings: media: max9286: Define 'maxim,gpio-poc'

Hi Jacopo,

On Thu, Apr 15, 2021 at 8:53 AM Jacopo Mondi  wrote:
> On Thu, Apr 15, 2021 at 02:47:12AM +0300, Laurent Pinchart wrote:
> > On Wed, Apr 14, 2021 at 03:51:24PM +0200, Jacopo Mondi wrote:
> > > Define a new vendor property in the maxim,max9286 binding schema.
> > >
> > > The new property allows to declare that the remote camera
> > > power-over-coax is controlled by one of the MAX9286 gpio lines.
> > >
> > > As it is currently not possible to establish a regulator as consumer
> > > of the MAX9286 gpio controller for this purpose, the property allows to
> > > declare that the camera power is controlled by the MAX9286 directly.
> > >
> > > The property accepts a gpio-index (0 or 1) and one line polarity
> > > flag as defined by dt-bindings/gpio/gpio.h.
> > >
> > > Signed-off-by: Jacopo Mondi 
> > > ---
> > >  .../bindings/media/i2c/maxim,max9286.yaml | 53 ++-
> > >  1 file changed, 52 insertions(+), 1 deletion(-)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml 
> > > b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > > index ee16102fdfe7..480a491f3744 100644
> > > --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > > +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > > @@ -70,6 +70,24 @@ properties:
> > >a remote serializer whose high-threshold noise immunity is not 
> > > enabled
> > >is 10 micro volts
> > >
> > > +  maxim,gpio-poc:
> >
> > I would have written poc-gpio to match the order of the GPIO bindings
> > syntax.
> >
>
> That's what I had :) but then the property gets matched against the
> gpio schema and I get complains because it expects a phandle as first
> argument... Maybe there's a way I've missed to prevent the property to
> be matched with *-gpio ?

GPIO hogs also use gpio properties lacking the phandle.
Hence the way this is handled for hogs may (or may not, it's yaml after all ;-)
inspire you how to handle this here.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

Hi Andy,

On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
 wrote:
> On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> >  wrote:
> > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang  
> > > > wrote:
> > > > > On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> > > > > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > > > > Kunpeng SoCs, and its driver relies on ACPI to probe for its 
> > > > > > presence.
> > > > > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the 
> > > > > > user
> > > > > > about this driver when configuring a kernel without Hisilicon 
> > > > > > platform
> > > > > > or ACPI firmware support.
> > > > >
> > > > > this is a public IP which doesn't specifically depend on ARCH_HISI. 
> > > > > I'm
> > > > > not sure all the platform this IP on has ARCH_HISI configured. The 
> > > > > driver
> > > > > will not be compiled by default config. This is not correct to have
> > > > > this dependence.
> > > >
> > > > Thanks for your answer!
> > > >
> > > > I guess it's still fine to add a dependency on ACPI?
> > >
> > > But why?
> >
> > Please tell me how/when the driver is used when CONFIG_ACPI=n.
>
> I'm not using it at all. Ask the author :-)
>
> But if we follow your logic, then we need to mark all the _platform_ drivers
> for x86 world as ACPI dependent? This sounds ugly.

Do all other x86 platform drivers have (1) an .acpi_match_table[] and
(2) no other way of instantiating their devices?
The first driver from the top of my memory I looked at is rtc-cmos:
it has no .acpi_match_table[], and the rtc-cmos device is instantiated
from arch/x86/kernel/rtc.c.

For drivers with only an .of_match_table(), and no legacy users
instantiating platform devices, we do have dependencies on OF.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 4/5] sh: Get rid of oprofile leftovers

On Wed, Apr 14, 2021 at 3:53 PM Marc Zyngier  wrote:
> perf_pmu_name() and perf_num_counters() are unused. Drop them.
>
> Signed-off-by: Marc Zyngier 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

Hi Andy,

On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
 wrote:
> On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang  
> > wrote:
> > > On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> > > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > > > about this driver when configuring a kernel without Hisilicon platform
> > > > or ACPI firmware support.
> > >
> > > this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
> > > not sure all the platform this IP on has ARCH_HISI configured. The driver
> > > will not be compiled by default config. This is not correct to have
> > > this dependence.
> >
> > Thanks for your answer!
> >
> > I guess it's still fine to add a dependency on ACPI?
>
> But why?

Please tell me how/when the driver is used when CONFIG_ACPI=n.
Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

Hi Yicong,

On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang  wrote:
> On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > about this driver when configuring a kernel without Hisilicon platform
> > or ACPI firmware support.
>
> this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
> not sure all the platform this IP on has ARCH_HISI configured. The driver
> will not be compiled by default config. This is not correct to have
> this dependence.

Thanks for your answer!

I guess it's still fine to add a dependency on ACPI?

Thanks again!

> > Fixes: d62fbdb99a85730a ("i2c: add support for HiSilicon I2C controller")
> > Signed-off-by: Geert Uytterhoeven 
> > ---
> >  drivers/i2c/busses/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index b5b4e0d0ff4dd0bc..3ead6d9e130b2ebc 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -647,7 +647,7 @@ config I2C_HIGHLANDER
> >
> >  config I2C_HISI
> >   tristate "HiSilicon I2C controller"
> > - depends on ARM64 || COMPILE_TEST
> > + depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
> >   help
> > Say Y here if you want to have Hisilicon I2C controller support
> > available on the Kunpeng Server.
\
Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH bpf-next v3 3/6] bpf: Add a bpf_snprintf helper

Hi Andrii,

On Wed, Apr 14, 2021 at 9:41 AM Andrii Nakryiko
 wrote:
> On Mon, Apr 12, 2021 at 8:38 AM Florent Revest  wrote:
> > The implementation takes inspiration from the existing bpf_trace_printk
> > helper but there are a few differences:
> >
> > To allow for a large number of format-specifiers, parameters are
> > provided in an array, like in bpf_seq_printf.
> >
> > Because the output string takes two arguments and the array of
> > parameters also takes two arguments, the format string needs to fit in
> > one argument. Thankfully, ARG_PTR_TO_CONST_STR is guaranteed to point to
> > a zero-terminated read-only map so we don't need a format string length
> > arg.
> >
> > Because the format-string is known at verification time, we also do
> > a first pass of format string validation in the verifier logic. This
> > makes debugging easier.
> >
> > Signed-off-by: Florent Revest 
> > ---
> >  include/linux/bpf.h|  6 
> >  include/uapi/linux/bpf.h   | 28 +++
> >  kernel/bpf/helpers.c   |  2 ++
> >  kernel/bpf/verifier.c  | 41 
> >  kernel/trace/bpf_trace.c   | 50 ++
> >  tools/include/uapi/linux/bpf.h | 28 +++
> >  6 files changed, 155 insertions(+)
> >
>
> [...]
>
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 5f46dd6f3383..d4020e5f91ee 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -5918,6 +5918,41 @@ static int check_reference_leak(struct 
> > bpf_verifier_env *env)
> > return state->acquired_refs ? -EINVAL : 0;
> >  }
> >
> > +static int check_bpf_snprintf_call(struct bpf_verifier_env *env,
> > +  struct bpf_reg_state *regs)
> > +{
> > +   struct bpf_reg_state *fmt_reg = [BPF_REG_3];
> > +   struct bpf_reg_state *data_len_reg = [BPF_REG_5];
> > +   struct bpf_map *fmt_map = fmt_reg->map_ptr;
> > +   int err, fmt_map_off, num_args;
> > +   u64 fmt_addr;
> > +   char *fmt;
> > +
> > +   /* data must be an array of u64 */
> > +   if (data_len_reg->var_off.value % 8)
> > +   return -EINVAL;
> > +   num_args = data_len_reg->var_off.value / 8;
> > +
> > +   /* fmt being ARG_PTR_TO_CONST_STR guarantees that var_off is const
> > +* and map_direct_value_addr is set.
> > +*/
> > +   fmt_map_off = fmt_reg->off + fmt_reg->var_off.value;
> > +   err = fmt_map->ops->map_direct_value_addr(fmt_map, _addr,
> > + fmt_map_off);
> > +   if (err)
> > +   return err;
> > +   fmt = (char *)fmt_addr + fmt_map_off;
> > +
>
> bot complained about lack of (long) cast before fmt_addr, please address

(uintptr_t), I assume?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH V4 2/2] net: ethernet: ravb: Enable optional refclk

Hi Adam,

On Wed, Apr 14, 2021 at 3:08 PM Adam Ford  wrote:
> On Tue, Apr 13, 2021 at 2:33 AM Geert Uytterhoeven  
> wrote:
> > On Mon, Apr 12, 2021 at 3:27 PM Adam Ford  wrote:
> > > For devices that use a programmable clock for the AVB reference clock,
> > > the driver may need to enable them.  Add code to find the optional clock
> > > and enable it when available.
> > >
> > > Signed-off-by: Adam Ford 
> > > Reviewed-by: Andrew Lunn 
> > >
> > > ---
> > > V4:  Eliminate the NULL check when disabling refclk, and add a line
> > >  to disable the refclk if there is a failure after it's been
> > >  initialized.
> >
> > Thanks for the update!
> >
> > > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > > @@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
> > > goto out_release;
> > > }
> > >
> > > +   priv->refclk = devm_clk_get_optional(>dev, "refclk");
> > > +   if (IS_ERR(priv->refclk)) {
> > > +   error = PTR_ERR(priv->refclk);
> > > +   goto out_release;
> >
> > Note that this will call clk_disable_unprepare() in case of failure, which 
> > is
> > fine, as that function is a no-op in case of a failed clock.
>
> Geert,
>
> A bot reported that if I jump to out_release may try to free a clock
> if some instances where priv isn't defined.

As priv is allocated using alloc_etherdev_mqs(), priv->refclk is
NULL initially, but priv itself may indeed not be initialized when the first
"goto out_release" is taken.  Sorry for missing that.

> Currently, the priv->clk isn't freed either.  I have heard some
> back-and-forth discussions in other threads on whether or not devm
> functions auto free or not.

The devm_clk_get_optional() will be undone automatically, so there
is no need to handle that explicitly.

> I'm fine with sending a V5 to make the free for the refclock happen
> only when the priv has successfully initialized.  Should I also add

As this patch has been applied to net-next, you''ll have to send
a follow-up fix patch, not a v5.

> one for freeing priv->clk and change all the other goto out_release
> commands to point to this new section?

No, not for priv->clk, due to devm_*().

> I am thinking it would like something like:
>
> free_refclk:
> clk_disable_unprepare(priv->refclk);

OK.

> free_clk;
> clk_disable_unprepare(priv->clk);

NAK, as priv->clk is not enabled in ravb_probe().

> out_release:
> free_netdev(ndev);
> 

OK.

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

Hi Andy,

On Tue, Apr 13, 2021 at 4:41 PM Andy Shevchenko
 wrote:
> On Tue, Apr 13, 2021 at 02:48:15PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Apr 13, 2021 at 2:37 PM Andy Shevchenko
> >  wrote:
> > > On Tue, Apr 13, 2021 at 02:26:15PM +0200, Geert Uytterhoeven wrote:
> > > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > > > about this driver when configuring a kernel without Hisilicon platform
> > > > or ACPI firmware support.
> > >
> > > I don't by the ACPI dependency, sorry.
> > >
> > > The driver is a pure platform driver that can be enumerated on ACPI 
> > > enabled
> > > devices, but otherwise it can be used as a platform one.
> >
> > Sure, you can manually instantiate a platform device with a matching
> > name, and set up the "clk_rate" device property.
> > But would it make sense to do that? Would anyone ever do that?
>
> It will narrow down the possibility to have One Kernel for as many as possible
> platforms.

That One Kernel needs to have CONFIG_ACPI enabled to use I2C on the
HiSilicon Kunpeng.  If CONFIG_ACPI is disabled, it cannot be used, as there
is no other code that creates "hisi-i2c" platform devices.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

Hi Andy,

On Tue, Apr 13, 2021 at 2:37 PM Andy Shevchenko
 wrote:
> On Tue, Apr 13, 2021 at 02:26:15PM +0200, Geert Uytterhoeven wrote:
> > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > about this driver when configuring a kernel without Hisilicon platform
> > or ACPI firmware support.
>
> I don't by the ACPI dependency, sorry.
>
> The driver is a pure platform driver that can be enumerated on ACPI enabled
> devices, but otherwise it can be used as a platform one.

Sure, you can manually instantiate a platform device with a matching
name, and set up the "clk_rate" device property.
But would it make sense to do that? Would anyone ever do that?

The corresponding SPI_HISI_KUNPENG depends on ACPI, too.

> If you remove ACPI dependency, feel free to add my
> Reviewed-by: Andy Shevchenko 

Thanks! ;-)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] spi: SPI_HISI_KUNPENG should depend on ARCH_HISI

The HiSilicon Kunpeng SPI controller is only present on HiSilicon
Kunpeng SoCs.  Hence add a dependency on ARCH_HISI, to prevent asking
the user about this driver when configuring a kernel without Hisilicon
platform support.

Fixes: c770d8631e1810d8 ("spi: Add HiSilicon SPI Controller Driver for Kunpeng 
SoCs")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/spi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 1ffcad19c0562a39..7d438ad343598bb8 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -334,7 +334,7 @@ config SPI_FSL_QUADSPI
 
 config SPI_HISI_KUNPENG
tristate "HiSilicon SPI Controller for Kunpeng SoCs"
-   depends on (ARM64 && ACPI) || COMPILE_TEST
+   depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
help
  This enables support for HiSilicon SPI controller found on
  Kunpeng SoCs.
-- 
2.25.1

[PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI

The HiSilicon Kunpeng I2C controller is only present on HiSilicon
Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
about this driver when configuring a kernel without Hisilicon platform
or ACPI firmware support.

Fixes: d62fbdb99a85730a ("i2c: add support for HiSilicon I2C controller")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/i2c/busses/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b5b4e0d0ff4dd0bc..3ead6d9e130b2ebc 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -647,7 +647,7 @@ config I2C_HIGHLANDER
 
 config I2C_HISI
tristate "HiSilicon I2C controller"
-   depends on ARM64 || COMPILE_TEST
+   depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
help
  Say Y here if you want to have Hisilicon I2C controller support
  available on the Kunpeng Server.
-- 
2.25.1

[PATCH] irqchip: APPLE_AIC should depend on ARCH_APPLE

The Apple Interrupt Controller is only present on Apple Silicon SoCs.
Hence add a dependency on ARCH_APPLE, to prevent asking the user about
this driver when configuring a kernel without Apple Silicon SoC support.

Drop the default, as ARCH_APPLE already selects APPLE_AIC.

Fixes: 76cde26394114f6a ("irqchip/apple-aic: Add support for the Apple 
Interrupt Controller")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/irqchip/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index d3a14f304ec80caa..b165b3285d9b0555 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -580,7 +580,7 @@ config MST_IRQ
 config APPLE_AIC
bool "Apple Interrupt Controller (AIC)"
depends on ARM64
-   default ARCH_APPLE
+   depends on ARCH_APPLE || COMPILE_TEST
help
  Support for the Apple Interrupt Controller found on Apple Silicon 
SoCs,
  such as the M1.
-- 
2.25.1

Re: [PATCH V4 2/2] net: ethernet: ravb: Enable optional refclk

Hi Adam,

On Mon, Apr 12, 2021 at 3:27 PM Adam Ford  wrote:
> For devices that use a programmable clock for the AVB reference clock,
> the driver may need to enable them.  Add code to find the optional clock
> and enable it when available.
>
> Signed-off-by: Adam Ford 
> Reviewed-by: Andrew Lunn 
>
> ---
> V4:  Eliminate the NULL check when disabling refclk, and add a line
>  to disable the refclk if there is a failure after it's been
>  initialized.

Thanks for the update!

> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
> goto out_release;
> }
>
> +   priv->refclk = devm_clk_get_optional(>dev, "refclk");
> +   if (IS_ERR(priv->refclk)) {
> +   error = PTR_ERR(priv->refclk);
> +   goto out_release;

Note that this will call clk_disable_unprepare() in case of failure, which is
fine, as that function is a no-op in case of a failed clock.

> +   }
> +   clk_prepare_enable(priv->refclk);
> +
> ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
> ndev->min_mtu = ETH_MIN_MTU;
>
> @@ -2244,6 +2251,7 @@ static int ravb_probe(struct platform_device *pdev)
> if (chip_id != RCAR_GEN2)
> ravb_ptp_stop(ndev);
>  out_release:
> +   clk_disable_unprepare(priv->refclk);
> free_netdev(ndev);
>
> pm_runtime_put(>dev);

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: New 'make dtbs_check W=1' warnings

Hi Arnd,

On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann  wrote:
> I've just gone through the DT merges I've received so far and, with a
> little help from Rob,
> managed to run 'make dtbs_check W=1' before and after, to see what
> warnings we get.
> The good news is that the number of warnings is going down, but
> unfortunately there
> is still an unmanageable amount of remaining warnings, and some new
> ones crept in.
>
> I'm still working on my tooling for this, to catch these better, but
> ideally I think we should
> try to not introduce new warnings. I think some platforms are already
> clean, and I did
> not see any new warnings for mvebu, samsung and broadcom. There were a lot of
> warnings from .dtsi files, and I probably did an incomplete job at
> deduplicating those.

Thanks for running these checks!

> See below for the other platforms, and the new warnings that I found.
> If these are
> valid, please send a fixup before the merge window, and let me know if
> you have ideas
> for how we should handle these in the future.
>
> For this merge window, I don't think any of them are show-stoppers (Rob, let 
> me
> know if you disagree), but in the long run we may want to gradually enforce
> a rule about not merging changes that introduce any new warnings, in order to
> have a chance of cleaning up the existing ones.

This may not be as simple as it sounds, as DT binding updates typically
follow a different path than DTS(i) updates.  DT bindings updates may be
picked up by a subsystem maintainer, by Rob, or by the platform
maintainer.
For trivial updates (e.g. adding a compatible value, and sometimes
extending a limit), a DTS(i) update may be accepted by the platform
maintainer before the corresponding DT binding update.  The latter may
even be merged one or more kernel revisions later, especially when
involving subsystems that are not traditionally rooted into platforms
using DT.

Of course we could mention any expected warning regressions in our pull
requests for soc.

> renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa: ports:
> 'port@0' is a required property

[...]

I've replied to these as a response to your PR reply, see
https://lore.kernel.org/linux-renesas-soc/camuhmdwhlnxgbsjp7vkudx-ynr9rskfke5ge5q_taru6hp9...@mail.gmail.com/

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Build regressions/improvements in v5.12-rc7

kinit.c: warning: 'test_big_hole_zero' uses 
dynamic stack allocation:  => 255:15
  + /kisskb/src/mm/slub.c: warning: '___slab_alloc' uses dynamic stack 
allocation:  => 2768:1
  + /kisskb/src/mm/slub.c: warning: '__slab_free' uses dynamic stack 
allocation:  => 3092:1
  + /kisskb/src/mm/slub.c: warning: 'deactivate_slab.isra.65' uses dynamic 
stack allocation:  => 2304:1
  + /kisskb/src/mm/slub.c: warning: 'get_partial_node.isra.64' uses dynamic 
stack allocation:  => 2014:1
  + /kisskb/src/mm/slub.c: warning: 'unfreeze_partials.isra.63' uses dynamic 
stack allocation:  => 2372:1
  + /kisskb/src/mm/z3fold.c: warning: 'z3fold_reclaim_page.constprop' uses 
dynamic stack allocation:  => 1485:1
  + /kisskb/src/net/bridge/br_netlink.c: warning: 'br_fill_linkxstats' uses 
dynamic stack allocation:  => 1753:1
  + /kisskb/src/net/bridge/br_vlan.c: warning: 'br_vlan_fill_vids' uses dynamic 
stack allocation:  => 1672:1
  + /kisskb/src/net/bridge/netfilter/ebtables.c: warning: 
'compat_copy_everything_to_user' uses dynamic stack allocation:  => 1767:1
  + modpost: WARNING: modpost: Symbol info of vmlinux is missing. Unresolved 
symbol check will be entirely skipped.:  => N/A

8 warning improvements:
  - /kisskb/src/arch/sparc/include/asm/cmpxchg_32.h: warning: value computed is 
not used [-Wunused-value]: 28:22 => 
  - 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c: 
warning: (near initialization for 'cmd.lock_hw') [-Wmissing-braces]: 36:8 => 
  - 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c: 
warning: missing braces around initializer [-Wmissing-braces]: 36:8 => 
  - /kisskb/src/drivers/net/ethernet/aurora/nb8800.h: warning: "TCR_DIE" 
redefined: 92 => 
  - /kisskb/src/drivers/net/ethernet/freescale/fec_main.c: warning: unused 
variable 'pdata' [-Wunused-variable]: 1667:28 => 
  - /kisskb/src/drivers/net/ethernet/freescale/fec_main.c: warning: unused 
variable 'val' [-Wunused-variable]: 948:6 => 
  - /kisskb/src/drivers/rtc/rtc-rx6110.c: warning: 'rx6110_probe' defined but 
not used [-Wunused-function]: 314:12 => 
  - warning: unmet direct dependencies detected for COMPAT_BINFMT_ELF: N/A => 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 1/1] serial: sh-sci: Respect deferred probe when getting IRQ

Hi Günter,

On Wed, Apr 7, 2021 at 10:58 PM Guenter Roeck  wrote:
> On 4/7/21 3:17 AM, Andy Shevchenko wrote:
> > With platform_get_irq() and its optional variant it's possible to get
> > a deferred probe error code. Since the commit ed7027fdf4ec ("driver core:
> > platform: Make platform_get_irq_optional() optional") the error code
> > can be distinguished from no IRQ case. With this, rewrite IRQ resource
> > handling in sh-sci driver to follow above and allow to respect deferred
> > probe.
> >
> > Fixes: ed7027fdf4ec ("driver core: platform: Make 
> > platform_get_irq_optional() optional")
> > Reported-by: Guenter Roeck 
> > Signed-off-by: Andy Shevchenko 
>
> This patch alone causes a hard hang early during boot. It works if applied
> together with ed7027fdf4ec. Ultimately that means that ed7027fdf4ec introduces
> a functional change, and will need to be applied very carefully. A cursory
> glance through callers of platform_get_irq_optional() shows that many
> do not handle this correctly: various drivers handle a return value of 0
> as valid interrupt, and others treat errors other than -ENXIO as fatal.
>
> Also, each patch on its own causes failures on sh, which is problematic
> when applying them even as series. See below for an idea how to
> address that.
>
> > ---
> > v2: fixed a typo: i -> 0
> >  drivers/tty/serial/sh-sci.c | 18 --
> >  1 file changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> > index ad2c189e8fc8..574f68ba50ff 100644
> > --- a/drivers/tty/serial/sh-sci.c
> > +++ b/drivers/tty/serial/sh-sci.c
> > @@ -2899,13 +2899,6 @@ static int sci_init_single(struct platform_device 
> > *dev,
> >   port->mapbase = res->start;
> >   sci_port->reg_size = resource_size(res);
> >
> > - for (i = 0; i < ARRAY_SIZE(sci_port->irqs); ++i) {
> > - if (i)
> > - sci_port->irqs[i] = platform_get_irq_optional(dev, i);
> > - else
> > - sci_port->irqs[i] = platform_get_irq(dev, i);
> > - }
> > -
> >   /* The SCI generates several interrupts. They can be muxed together or
> >* connected to different interrupt lines. In the muxed case only one
> >* interrupt resource is specified as there is only one interrupt ID.
> > @@ -2913,12 +2906,17 @@ static int sci_init_single(struct platform_device 
> > *dev,
> >* from the SCI, however those signals might have their own individual
> >* interrupt ID numbers, or muxed together with another interrupt.
> >*/
> > + sci_port->irqs[0] = platform_get_irq(dev, 0);
> >   if (sci_port->irqs[0] < 0)
> > - return -ENXIO;
> > + return sci_port->irqs[0];
> >
> > - if (sci_port->irqs[1] < 0)
> > - for (i = 1; i < ARRAY_SIZE(sci_port->irqs); i++)
> > + for (i = 1; i < ARRAY_SIZE(sci_port->irqs); ++i) {
> > + sci_port->irqs[i] = platform_get_irq_optional(dev, i);
> > + if (sci_port->irqs[i] < 0)
> > + return sci_port->irqs[i];
> > + if (sci_port->irqs[i] == 0)
> >   sci_port->irqs[i] = sci_port->irqs[0];
>
> Since sh never gets -EPROBE_DEFER, the following code can be applied
> on its own and does not depend on ed7027fdf4ec.

Note that the sh-sci driver is also used on ARM32/64 and H8/300.
On ARM, I don't expect GIC interrupts causing -EPROBE_DEFER, though.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] clk: renesas: rcar-usb2-clock-sel: Fix error handling in rcar_usb2_clock_sel_probe

Hi Dinghao,

On Mon, Apr 12, 2021 at 9:51 AM Dinghao Liu  wrote:
> When clk_get_rate() fails, a pairing PM usage counter decrement
> and disable is required to prevent refcount leak. It's the same
> for the subsequent error paths. When of_clk_add_hw_provider()
> fails, we need to unregister clk_hw.
>
> Signed-off-by: Dinghao Liu 

Thanks for your patch, which looks correct to me.

> --- a/drivers/clk/renesas/rcar-usb2-clock-sel.c
> +++ b/drivers/clk/renesas/rcar-usb2-clock-sel.c
> @@ -180,7 +180,8 @@ static int rcar_usb2_clock_sel_probe(struct 
> platform_device *pdev)
>
> if (!priv->extal && !priv->xtal) {
> dev_err(dev, "This driver needs usb_extal or usb_xtal\n");
> -   return -ENOENT;
> +   ret = -ENOENT;
> +   goto pm_put;
> }

As the code above doesn't rely on the device being powered yet, you
could move the pm_runtime_{enable,get_sync}() calls below the clock
checks instead.

>
> platform_set_drvdata(pdev, priv);
> @@ -194,10 +195,23 @@ static int rcar_usb2_clock_sel_probe(struct 
> platform_device *pdev)
> priv->hw.init = 
>
> clk = clk_register(NULL, >hw);
> -   if (IS_ERR(clk))
> -   return PTR_ERR(clk);
> +   if (IS_ERR(clk)) {
> +   ret = PTR_ERR(clk);
> +   goto pm_put;
> +   }
> +
> +   ret = of_clk_add_hw_provider(np, of_clk_hw_simple_get, >hw);
> +   if (ret)
> +   goto clk_unregister;
> +
> +   return 0;
>
> -   return of_clk_add_hw_provider(np, of_clk_hw_simple_get, >hw);
> +clk_unregister:
> +   clk_hw_unregister(>hw);

The error path can be simplified by replacing the call to clk_register()
by a call to devm_clk_register(), to match the style of the other
initialization steps.

> +pm_put:
> +   pm_runtime_put(dev);
> +   pm_runtime_disable(dev);
> +   return ret;

This part has to stay, of course.

>  }

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] kbuild: use ?= to assign CROSS_COMPILE by arch-Makefile

Hi Yamada-san,

On Sun, Apr 11, 2021 at 3:56 PM Masahiro Yamada  wrote:
> Use ?= operator to let arch/*/Makefile to assign CROSS_COMPILE only
> when CROSS_COMPILE is undefined.
>
> This allows arch-Makefiles to drop the ifeq ($(CROSS_COMPILE),)
> conditional.
>
> This slightly changes the behavior; the arch-Makefile previously
> overrode CROSS_COMPILE when CROSS_COMPILE has already been made empty
> via an environment variable as in 'export CROSS_COMPILE='.
>
> With this commit, arch-Makefle will respect the user's environment
> set-up, which seems to be a more correct behavior.
>
> Signed-off-by: Masahiro Yamada 

Thanks for your patch!

> ---
>
>  arch/arc/Makefile| 4 +---
>  arch/h8300/Makefile  | 4 +---
>  arch/m68k/Makefile   | 4 +---
>  arch/mips/Makefile   | 4 +---
>  arch/parisc/Makefile | 6 ++
>  arch/sh/Makefile | 4 +---

What about arch/xtensa/Makefile?

> --- a/arch/m68k/Makefile
> +++ b/arch/m68k/Makefile
> @@ -17,10 +17,8 @@
>  KBUILD_DEFCONFIG := multi_defconfig
>
>  ifneq ($(SUBARCH),$(ARCH))
> -   ifeq ($(CROSS_COMPILE),)
> -   CROSS_COMPILE := $(call cc-cross-prefix, \
> +   CROSS_COMPILE ?= $(call cc-cross-prefix, \
> m68k-linux-gnu- m68k-linux- m68k-unknown-linux-gnu-)
> -   endif
>  endif

This does not seem to work as expected: my standard build scripts
(using "make ARCH=m68k") no longer pick up the cross-compiler,
but fall back to the native compiler, thus breaking the build.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] arch/m68k/kernel/sys_m68k: Add missing mmap_read_lock() to sys_cacheflush()

On Wed, Apr 7, 2021 at 10:00 PM Liam Howlett  wrote:
> When the superuser flushes the entire cache, the mmap_read_lock() is not
> taken, but mmap_read_unlock() is called.  Add the missing
> mmap_read_lock() call.
>
> Signed-off-by: Liam R. Howlett 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in the m68k for-v5.13 branch.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 12/20] kbuild: m68k: use common install script

2021-04-07 Thread Geert Uytterhoeven

Hi Greg,

On Wed, Apr 7, 2021 at 7:35 AM Greg Kroah-Hartman
 wrote:
> The common scripts/install.sh script will now work for m68k, all that
> is needed is to add it to the list of arches that do not put the version
> number in the installed file name.
>
> With that we can remove the m68k-only version of the install script.
>
> Cc: Geert Uytterhoeven 
> Cc: linux-m...@lists.linux-m68k.org
> Signed-off-by: Greg Kroah-Hartman 

Thanks for your patch!

Acked-by: Geert Uytterhoeven 

I guess it would "work" with the version number, too.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 00/20] kbuild: unify the install.sh script usage

2021-04-07 Thread Geert Uytterhoeven

Hi Greg,

Thanks for your series!

On Wed, Apr 7, 2021 at 7:34 AM Greg Kroah-Hartman
 wrote:
> Almost every architecture has copied the "install.sh" script that
> originally came with i386, and modified it in very tiny ways.  This
> patch series unifies all of these scripts into one single script to
> allow people to understand how to correctly install a kernel, and fixes
> up some issues regarding trying to install a kernel to a path with
> spaces in it.
>
> Note that not all architectures actually seem to have any type of way to
> install a kernel, they must rely on external scripts or tools which
> feels odd as everything should be included here in the main repository.
> I'll work on trying to figure out the missing architecture issues
> afterward.

I'll bite ;-)

Does anyone actually use these scripts (outside of x86)?
I assume the architectures that have them, only have them because they
were copied from x86 while doing the initial ports ("oh, a file I don't
have to modify at all.").
But installing the kernel can be very platform-specific.
Do you need the vmlinux, vmlinux.gz, Image, zImage, uImage, ...?
With separate or appended DTB?

Even on x86, the script will bail out with "Cannot find LILO." if you're
using Grub.

Anyway, having less of them is good.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 4/9] sh: intc: Drop the use of irq_create_identity_mapping()

Hi Marc,

On Tue, Apr 6, 2021 at 11:44 AM Marc Zyngier  wrote:
> Instead of playing games with using irq_create_identity_mapping()
> and irq_domain_associate(), drop the use of the former and only
> use the latter, together with the allocation of the irq_desc
> as needed.
>
> It doesn't make the code less awful, but at least the intent
> is clearer.
>
> Signed-off-by: Marc Zyngier 

Thanks for your patch!

> --- a/drivers/sh/intc/core.c
> +++ b/drivers/sh/intc/core.c
> @@ -179,6 +179,23 @@ static unsigned int __init save_reg(struct intc_desc_int 
> *d,
> return 0;
>  }
>
> +static bool __init intc_map(struct irq_domain *domain, int irq)
> +{
> +   int res;

warning: unused variable ‘res’ [-Wunused-variable]

> +
> +   if (!irq_to_desc(irq) && irq_alloc_desc_at(irq, NUMA_NO_NODE) != irq) 
> {
> +   pr_err("uname to allocate IRQ %d\n", irq);
> +   return false;
> +   }
> +
> +   if (irq_domain_associate(domain, irq, irq)) {
> +   pr_err("domain association failure\n");
> +   return false;
> +   }
> +
> +   return true;
> +}
> +
>  int __init register_intc_controller(struct intc_desc *desc)
>  {
> unsigned int i, k, smp;
> @@ -316,19 +333,8 @@ int __init register_intc_controller(struct intc_desc 
> *desc)

warning: unused variable ‘res’ [-Wunused-variable]

> if (!vect->enum_id)
> continue;
>
> -   res = irq_create_identity_mapping(d->domain, irq);


> -   if (unlikely(res)) {
> -   if (res == -EEXIST) {
> -   res = irq_domain_associate(d->domain, irq, 
> irq);
> -   if (unlikely(res)) {
> -   pr_err("domain association 
> failure\n");
> -   continue;
> -   }
> -   } else {
> -   pr_err("can't identity map IRQ %d\n", irq);
> -   continue;
> -   }
> -   }
> +   if (!intc_map(d->domain, irq))
> +   continue;
>
> intc_irq_xlate_set(irq, vect->enum_id, d);
> intc_register_irq(desc, d, vect->enum_id, irq);

Otherwise this seems to work fine on real hardware (landisk) and qemu
(rts7751r2d).  I did verify that the new function intc_map() is called.

Tested-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] media: VIDEO_IMX8_JPEG should depend on ARCH_MXC and not default to m

Hoi Hans,

On Tue, Apr 6, 2021 at 11:24 AM Hans Verkuil  wrote:
> On 31/03/2021 10:17, Geert Uytterhoeven wrote:
> > The i.MX8 QXP/QM integrated JPEG encoder/decoder is only present on
> > Freescale/NXP i.MX8 QXP and QM SoCs.  Hence add a dependency on
> > ARCH_MXC, to prevent asking the user about this driver when configuring
> > a kernel without i.MX8 support.
> >
> > Drop the "default m" (which means "default y" if CONFIG_MODULES is not
> > enabled), as merely enabling CONFIG_COMPILE_TEST should not enable
> > additional code.
>
> You do not actually drop 'default m' in the patch. Either the patch or the
> commit message is wrong.

Oops, the patch is wrong.
V2 sent.
Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v2] media: VIDEO_IMX8_JPEG should depend on ARCH_MXC and not default to m

The i.MX8 QXP/QM integrated JPEG encoder/decoder is only present on
Freescale/NXP i.MX8 QXP and QM SoCs.  Hence add a dependency on
ARCH_MXC, to prevent asking the user about this driver when configuring
a kernel without i.MX8 support.

Drop the "default m" (which means "default y" if CONFIG_MODULES is not
enabled), as merely enabling CONFIG_COMPILE_TEST should not enable
additional code.

Fixes: 2db16c6ed72ce644 ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG 
Encoder/Decoder")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Really drop the "default m".
---
 drivers/media/platform/imx-jpeg/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/imx-jpeg/Kconfig 
b/drivers/media/platform/imx-jpeg/Kconfig
index d875f7c88cdad125..2fdd648cda80af8e 100644
--- a/drivers/media/platform/imx-jpeg/Kconfig
+++ b/drivers/media/platform/imx-jpeg/Kconfig
@@ -1,11 +1,11 @@
 # SPDX-License-Identifier: GPL-2.0
 config VIDEO_IMX8_JPEG
tristate "IMX8 JPEG Encoder/Decoder"
+   depends on ARCH_MXC || COMPILE_TEST
depends on VIDEO_DEV && VIDEO_V4L2
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select V4L2_JPEG_HELPER
-   default m
help
  This is a video4linux2 driver for the i.MX8 QXP/QM integrated
  JPEG encoder/decoder.
-- 
2.25.1

Re: [PATCH v3 3/5] RISC-V: Improve init_resources

Hi Nick,

On Tue, Apr 6, 2021 at 10:11 AM Nick Kossifidis  wrote:
> Hello Geert,
> Στις 2021-04-06 10:19, Geert Uytterhoeven έγραψε:
> > On Mon, Apr 5, 2021 at 10:57 AM Nick Kossifidis 
> > wrote:
> >> * Kernel region is always present and we know where it is, no
> >> need to look for it inside the loop, just ignore it like the
> >> rest of the reserved regions within system's memory.
> >>
> >> * Don't call memblock_free inside the loop, if called it'll split
> >> the region of pre-allocated resources in two parts, messing things
> >> up, just re-use the previous pre-allocated resource and free any
> >> unused resources after both loops finish.
> >>
> >> * memblock_alloc may add a region when called, so increase the
> >> number of pre-allocated regions by one to be on the safe side
> >> (reported and patched by Geert Uytterhoeven)
> >>
> >> Signed-off-by: Geert Uytterhoeven 
> >
> > Where does this SoB come from?
> >
> >> Signed-off-by: Nick Kossifidis 
> >
> >> --- a/arch/riscv/kernel/setup.c
> >> +++ b/arch/riscv/kernel/setup.c
> >
> >> @@ -129,53 +139,42 @@ static void __init init_resources(void)
> >> struct resource *res = NULL;
> >> struct resource *mem_res = NULL;
> >> size_t mem_res_sz = 0;
> >> -   int ret = 0, i = 0;
> >> -
> >> -   code_res.start = __pa_symbol(_text);
> >> -   code_res.end = __pa_symbol(_etext) - 1;
> >> -   code_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> >> -
> >> -   rodata_res.start = __pa_symbol(__start_rodata);
> >> -   rodata_res.end = __pa_symbol(__end_rodata) - 1;
> >> -   rodata_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> >> -
> >> -   data_res.start = __pa_symbol(_data);
> >> -   data_res.end = __pa_symbol(_edata) - 1;
> >> -   data_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> >> +   int num_resources = 0, res_idx = 0;
> >> +   int ret = 0;
> >>
> >> -   bss_res.start = __pa_symbol(__bss_start);
> >> -   bss_res.end = __pa_symbol(__bss_stop) - 1;
> >> -   bss_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> >> +   /* + 1 as memblock_alloc() might increase
> >> memblock.reserved.cnt */
> >> +   num_resources = memblock.memory.cnt + memblock.reserved.cnt +
> >> 1;
> >> +   res_idx = num_resources - 1;
> >>
> >> -   mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt) *
> >> sizeof(*mem_res);
> >
> > Oh, you incorporated my commit ce989f1472ae350e ("RISC-V: Fix
> > out-of-bounds
> > accesses in init_resources()") (from v5.12-rc4) into your patch.
> > Why? This means your patch does not apply against upstream.
> >
>
> Sorry if this looks awkward, I'm under the impression that new features
> go on for-next instead of fixes and your patch hasn't been merged on
> for-next yet. I thought it would be cleaner to have one patch to merge
> for init_resources instead of two, and simpler for people to test the
> series. I can rebase this on top of fixes if that works better for you
> or Palmer.

Ideally the fixes branch is part of the next branch.  That also helps
to avoid other people having to fix conflicts when merging both.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] m68k: mvme147, mvme16x: Don't wipe PCC timer config bits

On Tue, Mar 30, 2021 at 9:40 AM Finn Thain  wrote:
> Don't clear the timer 1 configuration bits when clearing the interrupt flag
> and counter overflow. As Michael reported, "This results in no timer
> interrupts being delivered after the first. Initialization then hangs
> in calibrate_delay as the jiffies counter is not updated."
>
> On mvme16x, enable the timer after requesting the irq, consistent with
> mvme147.
>
> Cc: Michael Pavone 
> Fixes: 7529b90d051e ("m68k: mvme147: Handle timer counter overflow")
> Fixes: 1a8b8782 ("m68k: mvme16x: Handle timer counter overflow")
> Reported-and-tested-by: Michael Pavone 
> Signed-off-by: Finn Thain 

Thanks, applying, and queueing in the m68k for-v5.13 branch.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 3/5] RISC-V: Improve init_resources

Hi Nick,

Thanks for your patch!

On Mon, Apr 5, 2021 at 10:57 AM Nick Kossifidis  wrote:
> * Kernel region is always present and we know where it is, no
> need to look for it inside the loop, just ignore it like the
> rest of the reserved regions within system's memory.
>
> * Don't call memblock_free inside the loop, if called it'll split
> the region of pre-allocated resources in two parts, messing things
> up, just re-use the previous pre-allocated resource and free any
> unused resources after both loops finish.
>
> * memblock_alloc may add a region when called, so increase the
> number of pre-allocated regions by one to be on the safe side
> (reported and patched by Geert Uytterhoeven)
>
> Signed-off-by: Geert Uytterhoeven 

Where does this SoB come from?

> Signed-off-by: Nick Kossifidis 

> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c

> @@ -129,53 +139,42 @@ static void __init init_resources(void)
> struct resource *res = NULL;
> struct resource *mem_res = NULL;
> size_t mem_res_sz = 0;
> -   int ret = 0, i = 0;
> -
> -   code_res.start = __pa_symbol(_text);
> -   code_res.end = __pa_symbol(_etext) - 1;
> -   code_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> -
> -   rodata_res.start = __pa_symbol(__start_rodata);
> -   rodata_res.end = __pa_symbol(__end_rodata) - 1;
> -   rodata_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> -
> -   data_res.start = __pa_symbol(_data);
> -   data_res.end = __pa_symbol(_edata) - 1;
> -   data_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> +   int num_resources = 0, res_idx = 0;
> +   int ret = 0;
>
> -   bss_res.start = __pa_symbol(__bss_start);
> -   bss_res.end = __pa_symbol(__bss_stop) - 1;
> -   bss_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> +   /* + 1 as memblock_alloc() might increase memblock.reserved.cnt */
> +   num_resources = memblock.memory.cnt + memblock.reserved.cnt + 1;
> +   res_idx = num_resources - 1;
>
> -   mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt) * 
> sizeof(*mem_res);

Oh, you incorporated my commit ce989f1472ae350e ("RISC-V: Fix out-of-bounds
accesses in init_resources()") (from v5.12-rc4) into your patch.
Why? This means your patch does not apply against upstream.

> +   mem_res_sz = num_resources * sizeof(*mem_res);
> mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
> if (!mem_res)
> panic("%s: Failed to allocate %zu bytes\n", __func__, 
> mem_res_sz);

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Build regressions/improvements in v5.12-rc6

2021-04-05 Thread Geert Uytterhoeven

ning: 'test_big_hole_zero' uses 
dynamic stack allocation:  => 255:15
  + /kisskb/src/mm/slub.c: warning: '___slab_alloc' uses dynamic stack 
allocation:  => 2768:1
  + /kisskb/src/mm/slub.c: warning: '__slab_free' uses dynamic stack 
allocation:  => 3092:1
  + /kisskb/src/mm/slub.c: warning: 'deactivate_slab.isra.65' uses dynamic 
stack allocation:  => 2304:1
  + /kisskb/src/mm/slub.c: warning: 'get_partial_node.isra.64' uses dynamic 
stack allocation:  => 2014:1
  + /kisskb/src/mm/slub.c: warning: 'unfreeze_partials.isra.63' uses dynamic 
stack allocation:  => 2372:1
  + /kisskb/src/mm/z3fold.c: warning: 'z3fold_reclaim_page.constprop' uses 
dynamic stack allocation:  => 1485:1
  + /kisskb/src/net/bridge/br_netlink.c: warning: 'br_fill_linkxstats' uses 
dynamic stack allocation:  => 1753:1
  + /kisskb/src/net/bridge/br_vlan.c: warning: 'br_vlan_fill_vids' uses dynamic 
stack allocation:  => 1672:1
  + /kisskb/src/net/bridge/netfilter/ebtables.c: warning: 
'compat_copy_everything_to_user' uses dynamic stack allocation:  => 1767:1
  + modpost: WARNING: modpost: Symbol info of vmlinux is missing. Unresolved 
symbol check will be entirely skipped.:  => N/A

8 warning improvements:
  - /kisskb/src/arch/sparc/include/asm/cmpxchg_32.h: warning: value computed is 
not used [-Wunused-value]: 28:22 => 
  - 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c: 
warning: (near initialization for 'cmd.lock_hw') [-Wmissing-braces]: 36:8 => 
  - 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c: 
warning: missing braces around initializer [-Wmissing-braces]: 36:8 => 
  - /kisskb/src/drivers/net/ethernet/aurora/nb8800.h: warning: "TCR_DIE" 
redefined: 92 => 
  - /kisskb/src/drivers/net/ethernet/freescale/fec_main.c: warning: unused 
variable 'pdata' [-Wunused-variable]: 1667:28 => 
  - /kisskb/src/drivers/net/ethernet/freescale/fec_main.c: warning: unused 
variable 'val' [-Wunused-variable]: 948:6 => 
  - /kisskb/src/drivers/rtc/rtc-rx6110.c: warning: 'rx6110_probe' defined but 
not used [-Wunused-function]: 314:12 => 
  - warning: unmet direct dependencies detected for COMPAT_BINFMT_ELF: N/A => 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] dt-bindings: fpga: fpga-region: Convert to sugar syntax

2021-04-02 Thread Geert Uytterhoeven

Using overlay sugar syntax makes the DTS files easier to read (and
write).

While at it, fix two build issues:
  - "/dts-v1/" and "/plugin/" must be separate statements.
  - Add a missing closing curly brace.

Signed-off-by: Geert Uytterhoeven 
---
 .../devicetree/bindings/fpga/fpga-region.txt  | 187 --
 1 file changed, 85 insertions(+), 102 deletions(-)

diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt 
b/Documentation/devicetree/bindings/fpga/fpga-region.txt
index e811cf8250199b14..d787d57491a1c537 100644
--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -245,36 +245,31 @@ Base tree contains:
 
 Overlay contains:
 
-/dts-v1/ /plugin/;
-/ {
-   fragment@0 {
-   target = <_region0>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   __overlay__ {
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   firmware-name = "soc_system.rbf";
-   fpga-bridges = <_bridge1>;
-   ranges = <0x2 0xff20 0x10>,
-<0x0 0xc000 0x2000>;
-
-   gpio@10040 {
-   compatible = "altr,pio-1.0";
-   reg = <0x10040 0x20>;
-   altr,ngpio = <4>;
-   #gpio-cells = <2>;
-   clocks = <2>;
-   gpio-controller;
-   };
-
-   onchip-memory {
-   device_type = "memory";
-   compatible = "altr,onchipmem-15.1";
-   reg = <0x0 0x1>;
-   };
-   };
+/dts-v1/;
+/plugin/;
+
+_region0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   firmware-name = "soc_system.rbf";
+   fpga-bridges = <_bridge1>;
+   ranges = <0x2 0xff20 0x10>,
+<0x0 0xc000 0x2000>;
+
+   gpio@10040 {
+   compatible = "altr,pio-1.0";
+   reg = <0x10040 0x20>;
+   altr,ngpio = <4>;
+   #gpio-cells = <2>;
+   clocks = <2>;
+   gpio-controller;
+   };
+
+   onchip-memory {
+   device_type = "memory";
+   compatible = "altr,onchipmem-15.1";
+   reg = <0x0 0x1>;
};
 };
 
@@ -371,25 +366,22 @@ Live Device Tree contains:
};
 
 DT Overlay contains:
-/dts-v1/ /plugin/;
-/ {
-fragment@0 {
-   target = <_region0>;
+
+/dts-v1/;
+/plugin/;
+
+_region0 {
#address-cells = <1>;
#size-cells = <1>;
-   __overlay__ {
-   #address-cells = <1>;
-   #size-cells = <1>;
 
-   firmware-name = "zynq-gpio.bin";
+   firmware-name = "zynq-gpio.bin";
 
-   gpio1: gpio@4000 {
-   compatible = "xlnx,xps-gpio-1.00.a";
-   reg = <0x4000 0x1>;
-   gpio-controller;
-   #gpio-cells = <0x2>;
-   xlnx,gpio-width= <0x6>;
-   };
+   gpio1: gpio@4000 {
+   compatible = "xlnx,xps-gpio-1.00.a";
+   reg = <0x4000 0x1>;
+   gpio-controller;
+   #gpio-cells = <0x2>;
+   xlnx,gpio-width= <0x6>;
};
 };
 
@@ -402,41 +394,37 @@ This example programs the FPGA to have two regions that 
can later be partially
 configured.  Each region has its own bridge in the FPGA fabric.
 
 DT Overlay contains:
-/dts-v1/ /plugin/;
-/ {
-   fragment@0 {
-   target = <_region0>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   __overlay__ {
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   firmware-name = "base.rbf";
-
-   fpga-bridge@4400 {
-   compatible = "altr,freeze-bridge-controller";
-   reg = <0x4400 0x10>;
-
-   fpga_region1: fpga-region1 {
-   compatible = "fpga-region";
-   #address-cells = <0x1>;
-   #size-cells = <0x1>;
-   ranges;
-

Re: [PATCH] zero-fill colormap in drivers/video/fbdev/core/fbcmap.c

2021-04-01 Thread Geert Uytterhoeven

On Thu, Apr 1, 2021 at 12:09 AM Phillip Potter  wrote:
> Use kzalloc() rather than kmalloc() for the dynamically allocated parts
> of the colormap in fb_alloc_cmap_gfp, to prevent a leak of random kernel
> data to userspace under certain circumstances.
>
> Fixes a KMSAN-found infoleak bug reported by syzbot at:
> https://syzkaller.appspot.com/bug?id=741578659feabd108ad9e06696f0c1f2e69c4b6e
>
> Reported-by: syzbot+47fa9c9c648b76530...@syzkaller.appspotmail.com
> Signed-off-by: Phillip Potter 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages

2021-04-01 Thread Geert Uytterhoeven

Hi Steven,

On Wed, Mar 31, 2021 at 3:40 PM Steven Rostedt  wrote:
> On Wed, 31 Mar 2021 11:31:03 +0200
> Geert Uytterhoeven  wrote:
>
> > This reduces kernel size by ca. 0.5 KiB.
>
> If you are worried about size, disable tracing and it will go away
> entirely. 0.5KiB is a drop in the bucket compared to what tracing adds in
> size overhead.

Fair enough for this particular case, as tracing can be disabled.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 2/2] m68k: remove meaningless EXTRA_LDFLAGS

On Wed, Mar 31, 2021 at 4:44 PM Masahiro Yamada  wrote:
> These two Makefiles contain only built-in objects (i.e. obj-y), which
> are collected by $(AR) into a thin-archive.
>
> EXTRA_LDFLAGS is meaningless because $(LD) is not used here.
>
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in the m68k for-v5.13 branch.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 1/2] m68k: remove meaningless $(OS_OBJS)

On Wed, Mar 31, 2021 at 4:44 PM Masahiro Yamada  wrote:
> 'git grep OS_OBJS' hits only this line. $(OS_OBJS) is just empty.

Indeed. All other users were removed in 2002.

> Signed-off-by: Masahiro Yamada 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in the m68k for-v5.13 branch.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages

While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed.  In addition, they increase boot time and
kernel size.

The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level.  Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.

Fix this by increasing the reporting level from KERN_WARNING to
KERN_CRIT, and removing irrelevant text and graphics.

This reduces kernel size by ca. 0.5 KiB.

Fixes: 2184db46e425c2b8 ("tracing: Print nasty banner when trace_printk() is in 
use")
Signed-off-by: Geert Uytterhoeven 
---
 kernel/trace/trace.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index eccb4e1187cc788e..b3a93aff01045923 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3175,20 +3175,9 @@ void trace_printk_init_buffers(void)
 
/* trace_printk() is for debug use only. Don't use it in production. */
 
-   pr_warn("\n");
-   pr_warn("**\n");
-   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
-   pr_warn("**  **\n");
-   pr_warn("** trace_printk() being used. Allocating extra memory.  **\n");
-   pr_warn("**  **\n");
-   pr_warn("** This means that this is a DEBUG kernel and it is **\n");
-   pr_warn("** unsafe for production use.   **\n");
-   pr_warn("**  **\n");
-   pr_warn("** If you see this message and you are not debugging**\n");
-   pr_warn("** the kernel, report this immediately to your vendor!  **\n");
-   pr_warn("**  **\n");
-   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
-   pr_warn("**\n");
+   pr_crit("trace_printk() being used. Allocating extra memory.\n");
+   pr_crit("This means that this is a DEBUG kernel and it is\n");
+   pr_crit("unsafe for production use.\n");
 
/* Expand the buffers to set size */
tracing_update_buffers();
-- 
2.25.1

[PATCH] clk: Align provider-specific CLK_* bit definitions

The definition of CLK_MULTIPLIER_ROUND_CLOSEST is not aligned to the two
bit definitions next to it.  A deeper inspection reveals that the
alignment of CLK_MULTIPLIER_ROUND_CLOSEST does match the most common
alignment.

Align the bit definitions for the various provider types throughout the
file at 40 columns, to increase uniformity.

Signed-off-by: Geert Uytterhoeven 
---
 include/linux/clk-provider.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 58f6fe866ae9b797..8f37829565f9640e 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -342,7 +342,7 @@ struct clk_fixed_rate {
unsigned long   flags;
 };
 
-#define CLK_FIXED_RATE_PARENT_ACCURACY BIT(0)
+#define CLK_FIXED_RATE_PARENT_ACCURACY BIT(0)
 
 extern const struct clk_ops clk_fixed_rate_ops;
 struct clk_hw *__clk_hw_register_fixed_rate(struct device *dev,
@@ -984,8 +984,8 @@ struct clk_fractional_divider {
 
 #define to_clk_fd(_hw) container_of(_hw, struct clk_fractional_divider, hw)
 
-#define CLK_FRAC_DIVIDER_ZERO_BASEDBIT(0)
-#define CLK_FRAC_DIVIDER_BIG_ENDIANBIT(1)
+#define CLK_FRAC_DIVIDER_ZERO_BASEDBIT(0)
+#define CLK_FRAC_DIVIDER_BIG_ENDIANBIT(1)
 
 extern const struct clk_ops clk_fractional_divider_ops;
 struct clk *clk_register_fractional_divider(struct device *dev,
@@ -1033,9 +1033,9 @@ struct clk_multiplier {
 
 #define to_clk_multiplier(_hw) container_of(_hw, struct clk_multiplier, hw)
 
-#define CLK_MULTIPLIER_ZERO_BYPASS BIT(0)
+#define CLK_MULTIPLIER_ZERO_BYPASS BIT(0)
 #define CLK_MULTIPLIER_ROUND_CLOSEST   BIT(1)
-#define CLK_MULTIPLIER_BIG_ENDIAN  BIT(2)
+#define CLK_MULTIPLIER_BIG_ENDIAN  BIT(2)
 
 extern const struct clk_ops clk_multiplier_ops;
 
-- 
2.25.1

[PATCH 0/3] Use pr_crit() instead of long fancy messages

Hi all,

While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed.  In addition, they increase boot time and
kernel size.

The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level.  Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.

This series increases the reporting level of such messages from
KERN_WARNING to KERN_CRIT, and removes irrelevant text and graphics.
It was made against linux-next, but applies to v5.12-rc5 with an offset
for the last patch.

Each of these patches reduces kernel size by ca. 0.5 KiB.

Thanks for your comments!

Geert Uytterhoeven (3):
  iommu: Use pr_crit() instead of long fancy messages
  tracing: Use pr_crit() instead of long fancy messages
  lib/vsprintf: Use pr_crit() instead of long fancy messages

 drivers/iommu/iommu-debugfs.c | 19 ---
 kernel/trace/trace.c  | 17 +++--
 lib/vsprintf.c| 17 +++--
 3 files changed, 10 insertions(+), 43 deletions(-)

-- 
2.25.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages

While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed.  In addition, they increase boot time and
kernel size.

The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level.  Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.

Fix this by increasing the reporting level from KERN_WARNING to
KERN_CRIT, and removing irrelevant text and graphics.

This reduces kernel size by ca. 0.5 KiB.

Fixes: 5ead723a20e0447b ("lib/vsprintf: no_hash_pointers prints all addresses 
as unhashed")
Signed-off-by: Geert Uytterhoeven 
---
 lib/vsprintf.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 9b423359bb6433d3..0293f1b89064b287 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2193,20 +2193,9 @@ static int __init no_hash_pointers_enable(char *str)
 
no_hash_pointers = true;
 
-   pr_warn("**\n");
-   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
-   pr_warn("**  **\n");
-   pr_warn("** This system shows unhashed kernel memory addresses   **\n");
-   pr_warn("** via the console, logs, and other interfaces. This**\n");
-   pr_warn("** might reduce the security of your system.**\n");
-   pr_warn("**  **\n");
-   pr_warn("** If you see this message and you are not debugging**\n");
-   pr_warn("** the kernel, report this immediately to your system   **\n");
-   pr_warn("** administrator!   **\n");
-   pr_warn("**  **\n");
-   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
-   pr_warn("**\n");
-
+   pr_crit("This system shows unhashed kernel memory addresses\n");
+   pr_crit("via the console, logs, and other interfaces. This\n");
+   pr_crit("might reduce the security of your system.\n");
return 0;
 }
 early_param("no_hash_pointers", no_hash_pointers_enable);
-- 
2.25.1

[PATCH 1/3] iommu: Use pr_crit() instead of long fancy messages

While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed.  In addition, they increase boot time and
kernel size.

The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level.  Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.

Fix this by increasing the reporting level from KERN_WARNING to
KERN_CRIT, and removing irrelevant text and graphics.

This reduces kernel size by ca. 0.5 KiB.

Fixes: bad614b24293ae46 ("iommu: Enable debugfs exposure of IOMMU driver 
internals")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/iommu/iommu-debugfs.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/iommu/iommu-debugfs.c b/drivers/iommu/iommu-debugfs.c
index f0354894209648fd..c3306998de0687bd 100644
--- a/drivers/iommu/iommu-debugfs.c
+++ b/drivers/iommu/iommu-debugfs.c
@@ -32,20 +32,9 @@ void iommu_debugfs_setup(void)
 {
if (!iommu_debugfs_dir) {
iommu_debugfs_dir = debugfs_create_dir("iommu", NULL);
-   pr_warn("\n");
-   
pr_warn("*\n");
-   pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE 
NOTICE**\n");
-   pr_warn("** 
**\n");
-   pr_warn("**  IOMMU DebugFS SUPPORT HAS BEEN ENABLED IN THIS 
KERNEL  **\n");
-   pr_warn("** 
**\n");
-   pr_warn("** This means that this kernel is built to expose 
internal **\n");
-   pr_warn("** IOMMU data structures, which may compromise 
security on **\n");
-   pr_warn("** your system.
**\n");
-   pr_warn("** 
**\n");
-   pr_warn("** If you see this message and you are not debugging 
the   **\n");
-   pr_warn("** kernel, report this immediately to your vendor! 
**\n");
-   pr_warn("** 
**\n");
-   pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE 
NOTICE**\n");
-   
pr_warn("*\n");
+   pr_crit("IOMMU DebugFS SUPPORT HAS BEEN ENABLED IN THIS 
KERNEL\n");
+   pr_crit("This means that this kernel is built to expose 
internal\n");
+   pr_crit("IOMMU data structures, which may compromise security 
on\n");
+   pr_crit("your system.\n");
}
 }
-- 
2.25.1

[PATCH] phy: microchip: PHY_SPARX5_SERDES should depend on ARCH_SPARX5

The Microchip Sparx5 SerDes PHY is present only Microchip Sparx5 SoCs.
Hence add a dependency on ARCH_SPARX5, to prevent asking the user about
this driver when configuring a kernel without support for Sparx5 SoCs.

Fixes: 2ff8a1eeb5aa8bb4 ("phy: Add Sparx5 ethernet serdes PHY driver")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/phy/microchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/phy/microchip/Kconfig b/drivers/phy/microchip/Kconfig
index 0b1a818e01b88cc5..3728a284bf643d48 100644
--- a/drivers/phy/microchip/Kconfig
+++ b/drivers/phy/microchip/Kconfig
@@ -6,6 +6,7 @@
 config PHY_SPARX5_SERDES
tristate "Microchip Sparx5 SerDes PHY driver"
select GENERIC_PHY
+   depends on ARCH_SPARX5 || COMPILE_TEST
depends on OF
depends on HAS_IOMEM
help
-- 
2.25.1

[PATCH] reset: RESET_INTEL_GW should depend on X86

The Intel Gateway reset controller is only present on Intel Gateway
platforms.  Hence add a dependency on X86, to prevent asking the user
about this driver when configuring a kernel without Intel Gateway
support.

Fixes: c9aef213e38cde27 ("reset: intel: Add system reset controller driver")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/reset/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 6dba675bcec4..c5dc1503de7909fa 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -83,6 +83,7 @@ config RESET_IMX7
 
 config RESET_INTEL_GW
bool "Intel Reset Controller Driver"
+   depends on X86 || COMPILE_TEST
depends on OF && HAS_IOMEM
select REGMAP_MMIO
help
-- 
2.25.1

[PATCH] media: VIDEO_IMX8_JPEG should depend on ARCH_MXC and not default to m

The i.MX8 QXP/QM integrated JPEG encoder/decoder is only present on
Freescale/NXP i.MX8 QXP and QM SoCs.  Hence add a dependency on
ARCH_MXC, to prevent asking the user about this driver when configuring
a kernel without i.MX8 support.

Drop the "default m" (which means "default y" if CONFIG_MODULES is not
enabled), as merely enabling CONFIG_COMPILE_TEST should not enable
additional code.

Fixes: 2db16c6ed72ce644 ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG 
Encoder/Decoder")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/media/platform/imx-jpeg/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/imx-jpeg/Kconfig 
b/drivers/media/platform/imx-jpeg/Kconfig
index d875f7c88cdad125..0e3269d06ded30ec 100644
--- a/drivers/media/platform/imx-jpeg/Kconfig
+++ b/drivers/media/platform/imx-jpeg/Kconfig
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 config VIDEO_IMX8_JPEG
tristate "IMX8 JPEG Encoder/Decoder"
+   depends on ARCH_MXC || COMPILE_TEST
depends on VIDEO_DEV && VIDEO_V4L2
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
-- 
2.25.1

Re: [PATCH] clk: Mark fwnodes when their clock provider is added