Re: kernel since 5.6 do not boot anymore on Apple PowerBook

2020-08-24 Thread Giuseppe Sacco
Hello Christophe,

Il giorno lun, 24/08/2020 alle 07.17 +0200, Christophe Leroy ha
scritto:
> Hello Giuseppe,
[...]
> The Oopses in the video are fixed in 5.9-rc2, see my response to your 
> other mail.

Right, I just updated from git and rebuilt the kernel whith
CONFIG_VMAP_STACK not set and the machine boots correctly.

> So now we know that your kernel doesn't boot when CONFIG_VMAP_STACK is set.
> Can you remind the exact problem ?

latest kernel with CONFIG_VMAP_STACK set stops after writing:
pmac32_cpufreq: registering PowerMac CPU frequency driver
pmac32_cpufreq: Low: 667 MHz, High: 867 Mhz, Boot: 667 MHz

> One common problem with CONFIG_VMAP_STACK is when some drivers are 
> invalidly using buffers in stack for DMA.
> 
> Couldn't try with CONFIG_DEBUG_VIRTUAL (without CONFIG_VMAP_STACK) and 
> see if it triggers some warnings ?

I've just tried: it boots without any special warning. What should I
look for? This is an excerpt of dmesg output about the line it would
otherwise stop:

[...]
[6.566984] PowerMac i2c bus pmu 2 registered
[6.574879] PowerMac i2c bus pmu 1 registered
[6.582634] PowerMac i2c bus mac-io 0 registered
[6.590323] i2c i2c-2: No i2c address for 
/pci@f200/mac-io@17/i2c@18000/i2c-modem
[6.598290] PowerMac i2c bus uni-n 1 registered
[6.606196] i2c i2c-3: i2c-powermac: modalias failure on 
/uni-n@f800/i2c@f8001000/cereal@1c0
[6.614320] PowerMac i2c bus uni-n 0 registered
[6.622501] pmac32_cpufreq: Registering PowerMac CPU frequency driver
[6.630580] pmac32_cpufreq: Low: 667 Mhz, High: 867 Mhz, Boot: 667 Mhz
[6.639518] ledtrig-cpu: registered to indicate activity on CPUs
[6.647894] NET: Registered protocol family 10
[6.656492] Segment Routing with IPv6
[6.664490] mip6: Mobile IPv6
[6.672337] NET: Registered protocol family 17
[6.680213] mpls_gso: MPLS GSO support
[...]

Bye,
Giuseppe



[PATCH 17/29] fs_enet: Avoid comma separated statements

2020-08-24 Thread Joe Perches
Use semicolons and braces.

Signed-off-by: Joe Perches 
---
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c 
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index bf846b42bc74..78e008b81374 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -562,10 +562,13 @@ fs_enet_start_xmit(struct sk_buff *skb, struct net_device 
*dev)
BD_ENET_TX_TC);
CBDS_SC(bdp, BD_ENET_TX_READY);
 
-   if ((CBDR_SC(bdp) & BD_ENET_TX_WRAP) == 0)
-   bdp++, curidx++;
-   else
-   bdp = fep->tx_bd_base, curidx = 0;
+   if ((CBDR_SC(bdp) & BD_ENET_TX_WRAP) == 0) {
+   bdp++;
+   curidx++;
+   } else {
+   bdp = fep->tx_bd_base;
+   curidx = 0;
+   }
 
len = skb_frag_size(frag);
CBDW_BUFADDR(bdp, skb_frag_dma_map(fep->dev, frag, 0, len,
-- 
2.26.0



[PATCH 00/29] treewide: Convert comma separated statements

2020-08-24 Thread Joe Perches
There are many comma separated statements in the kernel.
See:https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@hadrien/

Convert the comma separated statements that are in if/do/while blocks
to use braces and semicolons.

Many comma separated statements still exist but those are changes for
another day.

Joe Perches (29):
  coding-style.rst: Avoid comma statements
  alpha: Avoid comma separated statements
  ia64: Avoid comma separated statements
  sparc: Avoid comma separated statements
  ata: Avoid comma separated statements
  drbd: Avoid comma separated statements
  lp: Avoid comma separated statements
  dma-buf: Avoid comma separated statements
  drm/gma500: Avoid comma separated statements
  drm/i915: Avoid comma separated statements
  hwmon: (scmi-hwmon): Avoid comma separated statements
  Input: MT - Avoid comma separated statements
  bcache: Avoid comma separated statements
  media: Avoid comma separated statements
  mtd: Avoid comma separated statements
  8390: Avoid comma separated statements
  fs_enet: Avoid comma separated statements
  wan: sbni: Avoid comma separated statements
  s390/tty3270: Avoid comma separated statements
  scai/arm: Avoid comma separated statements
  media: atomisp: Avoid comma separated statements
  video: fbdev: Avoid comma separated statements
  fuse: Avoid comma separated statements
  reiserfs: Avoid comma separated statements
  lib/zlib: Avoid comma separated statements
  lib: zstd: Avoid comma separated statements
  ipv6: fib6: Avoid comma separated statements
  sunrpc: Avoid comma separated statements
  tools: Avoid comma separated statements

 Documentation/process/coding-style.rst|  17 +
 arch/alpha/kernel/pci_iommu.c |   8 +-
 arch/alpha/oprofile/op_model_ev4.c|  22 +-
 arch/alpha/oprofile/op_model_ev5.c|   8 +-
 arch/ia64/kernel/smpboot.c|   7 +-
 arch/sparc/kernel/smp_64.c|   7 +-
 drivers/ata/pata_icside.c |  21 +-
 drivers/block/drbd/drbd_receiver.c|   6 +-
 drivers/char/lp.c |   6 +-
 drivers/dma-buf/st-dma-fence.c|   7 +-
 drivers/gpu/drm/gma500/mdfld_intel_display.c  |  44 ++-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |   8 +-
 drivers/gpu/drm/i915/gt/intel_gt_requests.c   |   6 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|   6 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c   |   6 +-
 drivers/hwmon/scmi-hwmon.c|   6 +-
 drivers/input/input-mt.c  |  11 +-
 drivers/md/bcache/bset.c  |  12 +-
 drivers/md/bcache/sysfs.c |   6 +-
 drivers/media/i2c/msp3400-kthreads.c  |  12 +-
 drivers/media/pci/bt8xx/bttv-cards.c  |   6 +-
 drivers/media/pci/saa7134/saa7134-video.c |   7 +-
 drivers/mtd/devices/lart.c|  10 +-
 drivers/net/ethernet/8390/axnet_cs.c  |  19 +-
 drivers/net/ethernet/8390/lib8390.c   |  14 +-
 drivers/net/ethernet/8390/pcnet_cs.c  |   6 +-
 .../ethernet/freescale/fs_enet/fs_enet-main.c |  11 +-
 drivers/net/wan/sbni.c| 101 +++---
 drivers/s390/char/tty3270.c   |   6 +-
 drivers/scsi/arm/cumana_2.c   |  19 +-
 drivers/scsi/arm/eesox.c  |   9 +-
 drivers/scsi/arm/powertec.c   |   9 +-
 .../media/atomisp/pci/atomisp_subdev.c|   6 +-
 drivers/video/fbdev/tgafb.c   |  12 +-
 fs/fuse/dir.c |  24 +-
 fs/reiserfs/fix_node.c|  36 ++-
 lib/zlib_deflate/deftree.c|  49 ++-
 lib/zstd/compress.c   | 120 ---
 lib/zstd/fse_compress.c   |  24 +-
 lib/zstd/huf_compress.c   |   6 +-
 net/ipv6/ip6_fib.c|  12 +-
 net/sunrpc/sysctl.c   |   6 +-
 tools/lib/subcmd/help.c   |  10 +-
 tools/power/cpupower/utils/cpufreq-set.c  |  14 +-
 tools/testing/selftests/vm/gup_benchmark.c|  18 +-
 tools/testing/selftests/vm/userfaultfd.c  | 296 +++---
 46 files changed, 694 insertions(+), 382 deletions(-)

-- 
2.26.0



[PATCH v5 5/8] powerpc/watchpoint: Fix exception handling for CONFIG_HAVE_HW_BREAKPOINT=N

2020-08-24 Thread Ravi Bangoria
On powerpc, ptrace watchpoint works in one-shot mode. i.e. kernel
disables event every time it fires and user has to re-enable it.
Also, in case of ptrace watchpoint, kernel notifies ptrace user
before executing instruction.

With CONFIG_HAVE_HW_BREAKPOINT=N, kernel is missing to disable
ptrace event and thus it's causing infinite loop of exceptions.
This is especially harmful when user watches on a data which is
also read/written by kernel, eg syscall parameters. In such case,
infinite exceptions happens in kernel mode which causes soft-lockup.

Fixes: 9422de3e953d ("powerpc: Hardware breakpoints rewrite to handle non DABR 
breakpoint registers")
Reported-by: Pedro Miraglia Franco de Carvalho 
Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/hw_breakpoint.h  |  3 ++
 arch/powerpc/kernel/process.c | 48 +++
 arch/powerpc/kernel/ptrace/ptrace-noadv.c |  5 +++
 3 files changed, 56 insertions(+)

diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
b/arch/powerpc/include/asm/hw_breakpoint.h
index 2eca3dd54b55..c72263214d3f 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -18,6 +18,7 @@ struct arch_hw_breakpoint {
u16 type;
u16 len; /* length of the target data symbol */
u16 hw_len; /* length programmed in hw */
+   u8  flags;
 };
 
 /* Note: Don't change the first 6 bits below as they are in the same order
@@ -37,6 +38,8 @@ struct arch_hw_breakpoint {
 #define HW_BRK_TYPE_PRIV_ALL   (HW_BRK_TYPE_USER | HW_BRK_TYPE_KERNEL | \
 HW_BRK_TYPE_HYP)
 
+#define HW_BRK_FLAG_DISABLED   0x1
+
 /* Minimum granularity */
 #ifdef CONFIG_PPC_8xx
 #define HW_BREAKPOINT_SIZE  0x4
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 016bd831908e..160fbbf41d40 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -636,6 +636,44 @@ void do_send_trap(struct pt_regs *regs, unsigned long 
address,
(void __user *)address);
 }
 #else  /* !CONFIG_PPC_ADV_DEBUG_REGS */
+
+static void do_break_handler(struct pt_regs *regs)
+{
+   struct arch_hw_breakpoint null_brk = {0};
+   struct arch_hw_breakpoint *info;
+   struct ppc_inst instr = ppc_inst(0);
+   int type = 0;
+   int size = 0;
+   unsigned long ea;
+   int i;
+
+   /*
+* If underneath hw supports only one watchpoint, we know it
+* caused exception. 8xx also falls into this category.
+*/
+   if (nr_wp_slots() == 1) {
+   __set_breakpoint(0, _brk);
+   current->thread.hw_brk[0] = null_brk;
+   current->thread.hw_brk[0].flags |= HW_BRK_FLAG_DISABLED;
+   return;
+   }
+
+   /* Otherwise findout which DAWR caused exception and disable it. */
+   wp_get_instr_detail(regs, , , , );
+
+   for (i = 0; i < nr_wp_slots(); i++) {
+   info = >thread.hw_brk[i];
+   if (!info->address)
+   continue;
+
+   if (wp_check_constraints(regs, instr, ea, type, size, info)) {
+   __set_breakpoint(i, _brk);
+   current->thread.hw_brk[i] = null_brk;
+   current->thread.hw_brk[i].flags |= HW_BRK_FLAG_DISABLED;
+   }
+   }
+}
+
 void do_break (struct pt_regs *regs, unsigned long address,
unsigned long error_code)
 {
@@ -647,6 +685,16 @@ void do_break (struct pt_regs *regs, unsigned long address,
if (debugger_break_match(regs))
return;
 
+   /*
+* We reach here only when watchpoint exception is generated by ptrace
+* event (or hw is buggy!). Now if CONFIG_HAVE_HW_BREAKPOINT is set,
+* watchpoint is already handled by hw_breakpoint_handler() so we don't
+* have to do anything. But when CONFIG_HAVE_HW_BREAKPOINT is not set,
+* we need to manually handle the watchpoint here.
+*/
+   if (!IS_ENABLED(CONFIG_HAVE_HW_BREAKPOINT))
+   do_break_handler(regs);
+
/* Deliver the signal to userspace */
force_sig_fault(SIGTRAP, TRAP_HWBKPT, (void __user *)address);
 }
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c 
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 57a0ab822334..866597b407bc 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -286,11 +286,16 @@ long ppc_del_hwdebug(struct task_struct *child, long data)
}
return ret;
 #else /* CONFIG_HAVE_HW_BREAKPOINT */
+   if (child->thread.hw_brk[data - 1].flags & HW_BRK_FLAG_DISABLED)
+   goto del;
+
if (child->thread.hw_brk[data - 1].address == 0)
return -ENOENT;
 
+del:
child->thread.hw_brk[data - 1].address = 0;
child->thread.hw_brk[data - 1].type = 0;
+   

[PATCH v5 8/8] powerpc/watchpoint/selftests: Tests for kernel accessing user memory

2020-08-24 Thread Ravi Bangoria
Introduce tests to cover simple scenarios where user is watching
memory which can be accessed by kernel as well. We also support
_MODE_EXACT with _SETHWDEBUG interface. Move those testcases out-
side of _BP_RANGE condition. This will help to test _MODE_EXACT
scenarios when CONFIG_HAVE_HW_BREAKPOINT is not set, eg:

  $ ./ptrace-hwbreak
  ...
  PTRACE_SET_DEBUGREG, Kernel Access Userspace, len: 8: Ok
  PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok
  PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok
  PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok
  PPC_PTRACE_SETHWDEBUG, MODE_EXACT, Kernel Access Userspace, len: 1: Ok
  success: ptrace-hwbreak

Suggested-by: Pedro Miraglia Franco de Carvalho 
Signed-off-by: Ravi Bangoria 
---
 .../selftests/powerpc/ptrace/ptrace-hwbreak.c | 48 ++-
 1 file changed, 46 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c 
b/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
index fc477dfe86a2..2e0d86e0687e 100644
--- a/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
+++ b/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "ptrace.h"
 
 #define SPRN_PVR   0x11F
@@ -44,6 +46,7 @@ struct gstruct {
 };
 static volatile struct gstruct gstruct __attribute__((aligned(512)));
 
+static volatile char cwd[PATH_MAX] __attribute__((aligned(8)));
 
 static void get_dbginfo(pid_t child_pid, struct ppc_debug_info *dbginfo)
 {
@@ -138,6 +141,9 @@ static void test_workload(void)
write_var(len);
}
 
+   /* PTRACE_SET_DEBUGREG, Kernel Access Userspace test */
+   syscall(__NR_getcwd, , PATH_MAX);
+
/* PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO test */
write_var(1);
 
@@ -150,6 +156,9 @@ static void test_workload(void)
else
read_var(1);
 
+   /* PPC_PTRACE_SETHWDEBUG, MODE_EXACT, Kernel Access Userspace test */
+   syscall(__NR_getcwd, , PATH_MAX);
+
/* PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO test */
gstruct.a[rand() % A_LEN] = 'a';
 
@@ -293,6 +302,24 @@ static int test_set_debugreg(pid_t child_pid)
return 0;
 }
 
+static int test_set_debugreg_kernel_userspace(pid_t child_pid)
+{
+   unsigned long wp_addr = (unsigned long)cwd;
+   char *name = "PTRACE_SET_DEBUGREG";
+
+   /* PTRACE_SET_DEBUGREG, Kernel Access Userspace test */
+   wp_addr &= ~0x7UL;
+   wp_addr |= (1Ul << DABR_READ_SHIFT);
+   wp_addr |= (1UL << DABR_WRITE_SHIFT);
+   wp_addr |= (1UL << DABR_TRANSLATION_SHIFT);
+   ptrace_set_debugreg(child_pid, wp_addr);
+   ptrace(PTRACE_CONT, child_pid, NULL, 0);
+   check_success(child_pid, name, "Kernel Access Userspace", wp_addr, 8);
+
+   ptrace_set_debugreg(child_pid, 0);
+   return 0;
+}
+
 static void get_ppc_hw_breakpoint(struct ppc_hw_breakpoint *info, int type,
  unsigned long addr, int len)
 {
@@ -338,6 +365,22 @@ static void test_sethwdebug_exact(pid_t child_pid)
ptrace_delhwdebug(child_pid, wh);
 }
 
+static void test_sethwdebug_exact_kernel_userspace(pid_t child_pid)
+{
+   struct ppc_hw_breakpoint info;
+   unsigned long wp_addr = (unsigned long)
+   char *name = "PPC_PTRACE_SETHWDEBUG, MODE_EXACT";
+   int len = 1; /* hardcoded in kernel */
+   int wh;
+
+   /* PPC_PTRACE_SETHWDEBUG, MODE_EXACT, Kernel Access Userspace test */
+   get_ppc_hw_breakpoint(, PPC_BREAKPOINT_TRIGGER_WRITE, wp_addr, 0);
+   wh = ptrace_sethwdebug(child_pid, );
+   ptrace(PTRACE_CONT, child_pid, NULL, 0);
+   check_success(child_pid, name, "Kernel Access Userspace", wp_addr, len);
+   ptrace_delhwdebug(child_pid, wh);
+}
+
 static void test_sethwdebug_range_aligned(pid_t child_pid)
 {
struct ppc_hw_breakpoint info;
@@ -452,9 +495,10 @@ static void
 run_tests(pid_t child_pid, struct ppc_debug_info *dbginfo, bool dawr)
 {
test_set_debugreg(child_pid);
+   test_set_debugreg_kernel_userspace(child_pid);
+   test_sethwdebug_exact(child_pid);
+   test_sethwdebug_exact_kernel_userspace(child_pid);
if (dbginfo->features & PPC_DEBUG_FEATURE_DATA_BP_RANGE) {
-   test_sethwdebug_exact(child_pid);
-
test_sethwdebug_range_aligned(child_pid);
if (dawr || is_8xx) {
test_sethwdebug_range_unaligned(child_pid);
-- 
2.26.2



[PATCH v5 7/8] powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_ARCH_31

2020-08-24 Thread Ravi Bangoria
PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 can be used to determine whether
we are running on an ISA 3.1 compliant machine. Which is needed to
determine DAR behaviour, 512 byte boundary limit etc. This was
requested by Pedro Miraglia Franco de Carvalho for extending
watchpoint features in gdb. Note that availability of 2nd DAWR is
independent of this flag and should be checked using
ppc_debug_info->num_data_bps.

Signed-off-by: Ravi Bangoria 
---
 Documentation/powerpc/ptrace.rst  | 1 +
 arch/powerpc/include/uapi/asm/ptrace.h| 1 +
 arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/Documentation/powerpc/ptrace.rst b/Documentation/powerpc/ptrace.rst
index 864d4b61..77725d69eb4a 100644
--- a/Documentation/powerpc/ptrace.rst
+++ b/Documentation/powerpc/ptrace.rst
@@ -46,6 +46,7 @@ features will have bits indicating whether there is support 
for::
   #define PPC_DEBUG_FEATURE_DATA_BP_RANGE  0x4
   #define PPC_DEBUG_FEATURE_DATA_BP_MASK   0x8
   #define PPC_DEBUG_FEATURE_DATA_BP_DAWR   0x10
+  #define PPC_DEBUG_FEATURE_DATA_BP_ARCH_310x20
 
 2. PTRACE_SETHWDEBUG
 
diff --git a/arch/powerpc/include/uapi/asm/ptrace.h 
b/arch/powerpc/include/uapi/asm/ptrace.h
index f5f1ccc740fc..7004cfea3f5f 100644
--- a/arch/powerpc/include/uapi/asm/ptrace.h
+++ b/arch/powerpc/include/uapi/asm/ptrace.h
@@ -222,6 +222,7 @@ struct ppc_debug_info {
 #define PPC_DEBUG_FEATURE_DATA_BP_RANGE0x0004
 #define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x0008
 #define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x0010
+#define PPC_DEBUG_FEATURE_DATA_BP_ARCH_31  0x0020
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c 
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 081c39842d84..1d0235db3c1b 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -57,6 +57,8 @@ void ppc_gethwdinfo(struct ppc_debug_info *dbginfo)
} else {
dbginfo->features = 0;
}
+   if (cpu_has_feature(CPU_FTR_ARCH_31))
+   dbginfo->features |= PPC_DEBUG_FEATURE_DATA_BP_ARCH_31;
 }
 
 int ptrace_get_debugreg(struct task_struct *child, unsigned long addr,
-- 
2.26.2



[PATCH v5 6/8] powerpc/watchpoint: Add hw_len wherever missing

2020-08-24 Thread Ravi Bangoria
There are couple of places where we set len but not hw_len. For
ptrace/perf watchpoints, when CONFIG_HAVE_HW_BREAKPOINT=Y, hw_len
will be calculated and set internally while parsing watchpoint.
But when CONFIG_HAVE_HW_BREAKPOINT=N, we need to manually set
'hw_len'. Similarly for xmon as well, hw_len needs to be set
directly.

Fixes: b57aeab811db ("powerpc/watchpoint: Fix length calculation for unaligned 
target")
Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/ptrace/ptrace-noadv.c | 1 +
 arch/powerpc/xmon/xmon.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c 
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 866597b407bc..081c39842d84 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -219,6 +219,7 @@ long ppc_set_hwdebug(struct task_struct *child, struct 
ppc_hw_breakpoint *bp_inf
brk.address = ALIGN_DOWN(bp_info->addr, HW_BREAKPOINT_SIZE);
brk.type = HW_BRK_TYPE_TRANSLATE | HW_BRK_TYPE_PRIV_ALL;
brk.len = DABR_MAX_LEN;
+   brk.hw_len = DABR_MAX_LEN;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
brk.type |= HW_BRK_TYPE_READ;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index df7bca00f5ec..55c43a6c9111 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -969,6 +969,7 @@ static void insert_cpu_bpts(void)
brk.address = dabr[i].address;
brk.type = (dabr[i].enabled & HW_BRK_TYPE_DABR) | 
HW_BRK_TYPE_PRIV_ALL;
brk.len = 8;
+   brk.hw_len = 8;
__set_breakpoint(i, );
}
}
-- 
2.26.2



[PATCH v5 4/8] powerpc/watchpoint: Move DAWR detection logic outside of hw_breakpoint.c

2020-08-24 Thread Ravi Bangoria
Power10 hw has multiple DAWRs but hw doesn't tell which DAWR caused
the exception. So we have a sw logic to detect that in hw_breakpoint.c.
But hw_breakpoint.c gets compiled only with CONFIG_HAVE_HW_BREAKPOINT=Y.
Move DAWR detection logic outside of hw_breakpoint.c so that it can be
reused when CONFIG_HAVE_HW_BREAKPOINT is not set.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/hw_breakpoint.h  |   8 +
 arch/powerpc/kernel/Makefile  |   3 +-
 arch/powerpc/kernel/hw_breakpoint.c   | 159 +
 .../kernel/hw_breakpoint_constraints.c| 162 ++
 4 files changed, 174 insertions(+), 158 deletions(-)
 create mode 100644 arch/powerpc/kernel/hw_breakpoint_constraints.c

diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
b/arch/powerpc/include/asm/hw_breakpoint.h
index da38e05e04d9..2eca3dd54b55 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -10,6 +10,7 @@
 #define _PPC_BOOK3S_64_HW_BREAKPOINT_H
 
 #include 
+#include 
 
 #ifdef __KERNEL__
 struct arch_hw_breakpoint {
@@ -52,6 +53,13 @@ static inline int nr_wp_slots(void)
return cpu_has_feature(CPU_FTR_DAWR1) ? 2 : 1;
 }
 
+bool wp_check_constraints(struct pt_regs *regs, struct ppc_inst instr,
+ unsigned long ea, int type, int size,
+ struct arch_hw_breakpoint *info);
+
+void wp_get_instr_detail(struct pt_regs *regs, struct ppc_inst *instr,
+int *type, int *size, unsigned long *ea);
+
 #ifdef CONFIG_HAVE_HW_BREAKPOINT
 #include 
 #include 
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index cbf41fb4ee89..a5550c2b24c4 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -45,7 +45,8 @@ obj-y := cputable.o syscalls.o \
   signal.o sysfs.o cacheinfo.o time.o \
   prom.o traps.o setup-common.o \
   udbg.o misc.o io.o misc_$(BITS).o \
-  of_platform.o prom_parse.o firmware.o
+  of_platform.o prom_parse.o firmware.o \
+  hw_breakpoint_constraints.o
 obj-y  += ptrace/
 obj-$(CONFIG_PPC64)+= setup_64.o \
   paca.o nvram_64.o note.o syscall_64.o
diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index f6b24838ca3c..f4e8f21046f5 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -494,161 +494,6 @@ void thread_change_pc(struct task_struct *tsk, struct 
pt_regs *regs)
}
 }
 
-static bool dar_in_user_range(unsigned long dar, struct arch_hw_breakpoint 
*info)
-{
-   return ((info->address <= dar) && (dar - info->address < info->len));
-}
-
-static bool ea_user_range_overlaps(unsigned long ea, int size,
-  struct arch_hw_breakpoint *info)
-{
-   return ((ea < info->address + info->len) &&
-   (ea + size > info->address));
-}
-
-static bool dar_in_hw_range(unsigned long dar, struct arch_hw_breakpoint *info)
-{
-   unsigned long hw_start_addr, hw_end_addr;
-
-   hw_start_addr = ALIGN_DOWN(info->address, HW_BREAKPOINT_SIZE);
-   hw_end_addr = ALIGN(info->address + info->len, HW_BREAKPOINT_SIZE);
-
-   return ((hw_start_addr <= dar) && (hw_end_addr > dar));
-}
-
-static bool ea_hw_range_overlaps(unsigned long ea, int size,
-struct arch_hw_breakpoint *info)
-{
-   unsigned long hw_start_addr, hw_end_addr;
-   unsigned long align_size = HW_BREAKPOINT_SIZE;
-
-   /*
-* On p10 predecessors, quadword is handle differently then
-* other instructions.
-*/
-   if (!cpu_has_feature(CPU_FTR_ARCH_31) && size == 16)
-   align_size = HW_BREAKPOINT_SIZE_QUADWORD;
-
-   hw_start_addr = ALIGN_DOWN(info->address, align_size);
-   hw_end_addr = ALIGN(info->address + info->len, align_size);
-
-   return ((ea < hw_end_addr) && (ea + size > hw_start_addr));
-}
-
-/*
- * If hw has multiple DAWR registers, we also need to check all
- * dawrx constraint bits to confirm this is _really_ a valid event.
- * If type is UNKNOWN, but privilege level matches, consider it as
- * a positive match.
- */
-static bool check_dawrx_constraints(struct pt_regs *regs, int type,
-   struct arch_hw_breakpoint *info)
-{
-   if (OP_IS_LOAD(type) && !(info->type & HW_BRK_TYPE_READ))
-   return false;
-
-   /*
-* The Cache Management instructions other than dcbz never
-* cause a match. i.e. if type is CACHEOP, the instruction
-* is dcbz, and dcbz is treated as Store.
-*/
-   if ((OP_IS_STORE(type) || type == CACHEOP) && !(info->type & 

[PATCH v5 3/8] powerpc/watchpoint/ptrace: Fix SETHWDEBUG when CONFIG_HAVE_HW_BREAKPOINT=N

2020-08-24 Thread Ravi Bangoria
When kernel is compiled with CONFIG_HAVE_HW_BREAKPOINT=N, user can
still create watchpoint using PPC_PTRACE_SETHWDEBUG, with limited
functionalities. But, such watchpoints are never firing because of
the missing privilege settings. Fix that.

It's safe to set HW_BRK_TYPE_PRIV_ALL because we don't really leak
any kernel address in signal info. Setting HW_BRK_TYPE_PRIV_ALL will
also help to find scenarios when kernel corrupts user memory.

Reported-by: Pedro Miraglia Franco de Carvalho 
Suggested-by: Pedro Miraglia Franco de Carvalho 
Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c 
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 697c7e4b5877..57a0ab822334 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -217,7 +217,7 @@ long ppc_set_hwdebug(struct task_struct *child, struct 
ppc_hw_breakpoint *bp_inf
return -EIO;
 
brk.address = ALIGN_DOWN(bp_info->addr, HW_BREAKPOINT_SIZE);
-   brk.type = HW_BRK_TYPE_TRANSLATE;
+   brk.type = HW_BRK_TYPE_TRANSLATE | HW_BRK_TYPE_PRIV_ALL;
brk.len = DABR_MAX_LEN;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
brk.type |= HW_BRK_TYPE_READ;
-- 
2.26.2



[PATCH v5 2/8] powerpc/watchpoint: Fix handling of vector instructions

2020-08-24 Thread Ravi Bangoria
Vector instructions are special because they are always aligned.
Thus unaligned EA needs to be aligned down before comparing it
with watch ranges. Otherwise we might consider valid event as
invalid.

Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than 
one watchpoint")
Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/hw_breakpoint.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index 9f7df1c37233..f6b24838ca3c 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -644,6 +644,8 @@ static void get_instr_detail(struct pt_regs *regs, struct 
ppc_inst *instr,
if (*type == CACHEOP) {
*size = cache_op_size();
*ea &= ~(*size - 1);
+   } else if (*type == LOAD_VMX || *type == STORE_VMX) {
+   *ea &= ~(*size - 1);
}
 }
 
-- 
2.26.2



[PATCH v5 1/8] powerpc/watchpoint: Fix quarword instruction handling on p10 predecessors

2020-08-24 Thread Ravi Bangoria
On p10 predecessors, watchpoint with quarword access is compared at
quardword length. If the watch range is doubleword or less than that
in a first half of quarword aligned 16 bytes, and if there is any
unaligned quadword access which will access only the 2nd half, the
handler should consider it as extraneous and emulate/single-step it
before continuing.

Reported-by: Pedro Miraglia Franco de Carvalho 
Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than 
one watchpoint")
Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/hw_breakpoint.h |  3 ++-
 arch/powerpc/kernel/hw_breakpoint.c  | 12 ++--
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
b/arch/powerpc/include/asm/hw_breakpoint.h
index db206a7f38e2..da38e05e04d9 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -40,7 +40,8 @@ struct arch_hw_breakpoint {
 #ifdef CONFIG_PPC_8xx
 #define HW_BREAKPOINT_SIZE  0x4
 #else
-#define HW_BREAKPOINT_SIZE  0x8
+#define HW_BREAKPOINT_SIZE 0x8
+#define HW_BREAKPOINT_SIZE_QUADWORD0x10
 #endif
 
 #define DABR_MAX_LEN   8
diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index 1f4a1efa0074..9f7df1c37233 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -520,9 +520,17 @@ static bool ea_hw_range_overlaps(unsigned long ea, int 
size,
 struct arch_hw_breakpoint *info)
 {
unsigned long hw_start_addr, hw_end_addr;
+   unsigned long align_size = HW_BREAKPOINT_SIZE;
 
-   hw_start_addr = ALIGN_DOWN(info->address, HW_BREAKPOINT_SIZE);
-   hw_end_addr = ALIGN(info->address + info->len, HW_BREAKPOINT_SIZE);
+   /*
+* On p10 predecessors, quadword is handle differently then
+* other instructions.
+*/
+   if (!cpu_has_feature(CPU_FTR_ARCH_31) && size == 16)
+   align_size = HW_BREAKPOINT_SIZE_QUADWORD;
+
+   hw_start_addr = ALIGN_DOWN(info->address, align_size);
+   hw_end_addr = ALIGN(info->address + info->len, align_size);
 
return ((ea < hw_end_addr) && (ea + size > hw_start_addr));
 }
-- 
2.26.2



[PATCH v5 0/8] powerpc/watchpoint: Bug fixes plus new feature flag

2020-08-24 Thread Ravi Bangoria
Patch #1 fixes issue for quardword instruction on p10 predecessors.
Patch #2 fixes issue for vector instructions.
Patch #3 fixes a bug about watchpoint not firing when created with
 ptrace PPC_PTRACE_SETHWDEBUG and CONFIG_HAVE_HW_BREAKPOINT=N.
 The fix uses HW_BRK_TYPE_PRIV_ALL for ptrace user which, I
 guess, should be fine because we don't leak any kernel
 addresses and PRIV_ALL will also help to cover scenarios when
 kernel accesses user memory.
Patch #4,#5 fixes infinite exception bug, again the bug happens only
 with CONFIG_HAVE_HW_BREAKPOINT=N.
Patch #6 fixes two places where we are missing to set hw_len.
Patch #7 introduce new feature bit PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
 which will be set when running on ISA 3.1 compliant machine.
Patch #8 finally adds selftest to test scenarios fixed by patch#2,#3
 and also moves MODE_EXACT tests outside of BP_RANGE condition.

Christophe, let me know if this series breaks something for 8xx.

v4: 
https://lore.kernel.org/r/20200817102330.777537-1-ravi.bango...@linux.ibm.com/

v4->v5:
 - Patch #1 and #2 are new. These bug happen irrespective of
   CONFIG_HAVE_HW_BREAKPOINT.
 - Patch #3 to #8 are carry forwarded from v4
 - Rebased to powerpc/next

Ravi Bangoria (8):
  powerpc/watchpoint: Fix quarword instruction handling on p10
predecessors
  powerpc/watchpoint: Fix handling of vector instructions
  powerpc/watchpoint/ptrace: Fix SETHWDEBUG when
CONFIG_HAVE_HW_BREAKPOINT=N
  powerpc/watchpoint: Move DAWR detection logic outside of
hw_breakpoint.c
  powerpc/watchpoint: Fix exception handling for
CONFIG_HAVE_HW_BREAKPOINT=N
  powerpc/watchpoint: Add hw_len wherever missing
  powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
  powerpc/watchpoint/selftests: Tests for kernel accessing user memory

 Documentation/powerpc/ptrace.rst  |   1 +
 arch/powerpc/include/asm/hw_breakpoint.h  |  14 +-
 arch/powerpc/include/uapi/asm/ptrace.h|   1 +
 arch/powerpc/kernel/Makefile  |   3 +-
 arch/powerpc/kernel/hw_breakpoint.c   | 149 +---
 .../kernel/hw_breakpoint_constraints.c| 162 ++
 arch/powerpc/kernel/process.c |  48 ++
 arch/powerpc/kernel/ptrace/ptrace-noadv.c |  10 +-
 arch/powerpc/xmon/xmon.c  |   1 +
 .../selftests/powerpc/ptrace/ptrace-hwbreak.c |  48 +-
 10 files changed, 285 insertions(+), 152 deletions(-)
 create mode 100644 arch/powerpc/kernel/hw_breakpoint_constraints.c

-- 
2.26.2



Re: fsl_espi errors on v5.7.15

2020-08-24 Thread Chris Packham

On 25/08/20 10:04 am, Chris Packham wrote:
>
> On 20/08/20 9:08 am, Chris Packham wrote:
>>
>> On 19/08/20 6:15 pm, Heiner Kallweit wrote:
>>> On 19.08.2020 00:44, Chris Packham wrote:
 Hi Again,

 On 17/08/20 9:09 am, Chris Packham wrote:

> On 14/08/20 6:19 pm, Heiner Kallweit wrote:
>> On 14.08.2020 04:48, Chris Packham wrote:
>>> Hi,
>>>
>>> I'm seeing a problem with accessing spi-nor after upgrading a T2081
>>> based system to linux v5.7.15
>>>
>>> For this board u-boot and the u-boot environment live on spi-nor.
>>>
>>> When I use fw_setenv from userspace I get the following kernel logs
>>>
>>> # fw_setenv foo=1
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>> fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't 
>>> empty!
>>> fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>> fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't 
>>> empty!
>>> fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>> fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't 
>>> empty!
>>> fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>> ...
>>>
>> This error reporting doesn't exist yet in 4.4. So you may have an 
>> issue
>> under 4.4 too, it's just not reported.
>> Did you verify that under 4.4 fw_setenv actually has an effect?
> Just double checked and yes under 4.4 the setting does get saved.
>>> If I run fw_printenv (before getting it into a bad state) it is 
>>> able to
>>> display the content of the boards u-boot environment.
>>>
>> This might indicate an issue with spi being locked. I've seen 
>> related
>> questions, just use the search engine of your choice and check for
>> fw_setenv and locked.
> I'm running a version of fw_setenv which includes
> https://gitlab.denx.de/u-boot/u-boot/-/commit/db820159 so it 
> shouldn't
> be locking things unnecessarily.
>>> If been unsuccessful in producing a setup for bisecting the 
>>> issue. I do
>>> know the issue doesn't occur on the old 4.4.x based kernel but 
>>> that's
>>> probably not much help.
>>>
>>> Any pointers on what the issue (and/or solution) might be.
 I finally managed to get our board running with a vanilla kernel. With
 corenet64_smp_defconfig I occasionally see

     fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!

 other than the message things seem to be working.

 With a custom defconfig I see

     fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
     fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't 
 empty!
     fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
     ...

 and access to the spi-nor does not work until the board is reset.

 I'll try and pick apart the differences between the two defconfigs.
>>
>> I now think my earlier testing is invalid. I have seen the problem 
>> with either defconfig if I try hard enough. I had convinced myself 
>> that the problem was CONFIG_PREEMPT but that was before I found 
>> boot-to-boot differences with the same kernel.
>>
>> It's possible that I'm chasing multiple issues with the same symptom.
>>
>> The error I'm most concerned with is in the sequence
>> 1. boot with old image
>> 2. write environment
>> 3. boot with new image
>> 4. write environment
>> 5. write fails and environment is corrupted
>>
>> After I recover the system things sometimes seem fine. Until I repeat 
>> the sequence above.
>>
>>> Also relevant may be:
>>> - Which dts are you using?
>> Custom but based heavily on the t2080rdb.
>>> - What's the spi-nor type, and at which frequency are you operating it?
>> The board has several alternate parts for the spi-nor so the dts just 
>> specifies compatible = "jedec,spi-nor" the actual chip detected on 
>> the board I have is "n25q032a (4096 Kbytes)". The dts sets 
>> spi-max-frequency = <1000> I haven't 

[PATCH] powerpc/boot: Update Makefile comment for 64bit wrapper

2020-08-24 Thread Jordan Niethe
As of commit 147c05168fc8 ("powerpc/boot: Add support for 64bit little
endian wrapper") the comment in the Makefile is misleading. The wrapper
packaging 64bit kernel may built as a 32 or 64 bit elf. Update the
comment to reflect this.

Signed-off-by: Jordan Niethe 
---
 arch/powerpc/boot/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index b88fd27a45f0..f8ce6d2dde7b 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -7,7 +7,7 @@
 # Based on coffboot by Paul Mackerras
 # Simplified for ppc64 by Todd Inglett
 #
-# NOTE:this code is built for 32 bit in ELF32 format even though
+# NOTE:this code may be built for 32 bit in ELF32 format even though
 #  it packages a 64 bit kernel.  We do this to simplify the
 #  bootloader and increase compatibility with OpenFirmware.
 #
-- 
2.17.1



[PATCH net] ibmvnic fix NULL tx_pools and rx_tools issue at do_reset

2020-08-24 Thread Dany Madden
From: Mingming Cao 

At the time of do_reset, ibmvnic tries to re-initalize the tx_pools
and rx_pools to avoid re-allocating the long term buffer. However
there is a window inside do_reset that the tx_pools and
rx_pools were freed before re-initialized making it possible to deference
null pointers.

This patch fixes this issue by checking that the tx_pool
and rx_pool are not NULL after ibmvnic_login. If so, re-allocating
the pools. This will avoid getting into calling reset_tx/rx_pools with
NULL adapter tx_pools/rx_pools pointer. Also add null pointer check in
reset_tx_pools and reset_rx_pools to safe handle NULL pointer case.

Signed-off-by: Mingming Cao 
Signed-off-by: Dany Madden 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 5afb3c9c52d2..5ff48e55308b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -479,6 +479,9 @@ static int reset_rx_pools(struct ibmvnic_adapter *adapter)
int i, j, rc;
u64 *size_array;
 
+   if (!adapter->tx_pool)
+   return -1;
+
size_array = (u64 *)((u8 *)(adapter->login_rsp_buf) +
be32_to_cpu(adapter->login_rsp_buf->off_rxadd_buff_size));
 
@@ -649,6 +652,9 @@ static int reset_tx_pools(struct ibmvnic_adapter *adapter)
int tx_scrqs;
int i, rc;
 
+   if (!adapter->tx_pool)
+   return -1;
+
tx_scrqs = be32_to_cpu(adapter->login_rsp_buf->num_txsubm_subcrqs);
for (i = 0; i < tx_scrqs; i++) {
rc = reset_one_tx_pool(adapter, >tso_pool[i]);
@@ -2011,7 +2017,10 @@ static int do_reset(struct ibmvnic_adapter *adapter,
adapter->req_rx_add_entries_per_subcrq !=
old_num_rx_slots ||
adapter->req_tx_entries_per_subcrq !=
-   old_num_tx_slots) {
+   old_num_tx_slots ||
+   !adapter->rx_pool ||
+   !adapter->tso_pool ||
+   !adapter->tx_pool) {
release_rx_pools(adapter);
release_tx_pools(adapter);
release_napi(adapter);
@@ -2024,10 +2033,14 @@ static int do_reset(struct ibmvnic_adapter *adapter,
} else {
rc = reset_tx_pools(adapter);
if (rc)
+   netdev_dbg(adapter->netdev, "reset tx pools 
failed (%d)\n",
+   rc);
goto out;
 
rc = reset_rx_pools(adapter);
if (rc)
+   netdev_dbg(adapter->netdev, "reset rx pools 
failed (%d)\n",
+   rc);
goto out;
}
ibmvnic_disable_irqs(adapter);
-- 
2.18.2



[Bug 209029] kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 - BUG: Kernel NULL pointer dereference on read at 0x00000020

2020-08-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209029

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 292155
  --> https://bugzilla.kernel.org/attachment.cgi?id=292155=edit
dmesg screenshot

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209029] New: kernel 5.9-rc2 fails to boot on a PowerMac G5 11, 2 - BUG: Kernel NULL pointer dereference on read at 0x00000020

2020-08-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209029

Bug ID: 209029
   Summary: kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 -
BUG: Kernel NULL pointer dereference on read at
0x0020
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.9-rc2
  Hardware: PPC-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: PPC-64
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: erhar...@mailbox.org
Regression: No

Created attachment 292153
  --> https://bugzilla.kernel.org/attachment.cgi?id=292153=edit
kernel .config (kernel 5.9-rc2, PowerMac G5 11,2)

Transcribed the stacktrace from a screenshot with my camera:

[...]
REGS: c0047d0d7850 TRAP:   0700 Tainted: GW 
(5.9.0-rc2-PowerMacG5)
MSR:  90029032   CR: 44000448  XER: 200f
IRQMASK: 0
GPR00: c0af853c c0047d0d7ae0 c0d17300 0001
GPR04: 1f255000 c0047b5c92a8 0001 
GPR08: c000 0001 3fff 4000
GPR12: 24000448 cc80 c000fd78 
GPR16:    
GPR20: 00c3e000 c0c3e307 c0d83b90 c00030030f80
GPR24: c0d83c28 0c00 c0047b5c74b0 8105
GPR28: ee1fffbf c0047d64f800 1f255000 1f255000
NIP [c0af8568] .debug_um_pgtable+0x884/0xa20
LR [c0af853c] .debug_vm_pgtable+0x858/0xa20
Call Trace:
[c0047d0d7ae0] [c0af853c] .debug_vm_pgtable++0x858/0xa20
(unreliable)
[c0047d0d7be0] [c000f62c] .do_one_initcall+0x60/0x344
[c0047d0d7cc0] [c0ad8d64] .kerne]_init_freeable+0x3c0/0x3f4
[c0047d0d7db0] [c000fd88] .kernel_init+0x10/0x130
[c0047d0d7e20] [c000b9d8] .ret_from_kerne!_thread+0x58/0x60
Instruction dump:
4b53b145 6000 e8df 7f863278 3f80ee1f 639c 7b9c07c6 679c
639cffbf 7cc6e038 3146 7cca3110 <0b06> 3900 38e0 38c0
irg event stamp: 369
hardirgs last  enabled at (369): []
.console_unlock+0x650/0x664
hardirgs last disabled at (366): []
.console_unlock+0x170/0x664
softirgs last  enabled at (0): [] .copy_process+0x69c/0x1510
softirgs last disabled at (0): [<>] 0x0
---[ end trace 0561544ca9dc6c57 ]---
BUG: Kernel NULL pointer dereference on read at 0x0020
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Faulting instruction address: 0xc0033924
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=4 NUMA PowerMac
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 5.9.0-rc2-PowerMacG5
#2
NIP:  c0033924 LR: c00338e4 CTR: 
REGS: c0047d0d77a0 TRAP: 0380 Tainted: GW 
(5.9.0-rc2-PowerMacG5)
MSR:  90009032  CR: 44000448 XER: 200f
IRQMASK: 0
GPR00: c00338e4 c0047d0d7a30 c0d17300 c0047d0d7aa8
GPR04: 80c3e387 0001 80c3e387 0001
GPR08: c000  c0d83d48 
GPR12: 24000448 cc80 c000fd78 
GPR16:    
GPR20: 00c3e000 c0c3e307 c0d83b90 c00030030f80
GPR24: c0d83c28 0c00 c0047b5c74b0 8105
GPR28: c0047b5c74b0 0001 80c3e387 c0047b5c92a8
NIP [c0033924] .huge_ptep_set_access_flags+0x70/0x114
LR [c00338e4] .huge_ptep_set_access_flags+0x30/0x114
Call Trace:
[c0047d0d7a30] [c00338e4] .huge_ptep_set_access_flags+0x30/0x114
(unreliable)
[c0047d0d7ae0] [c0af86b4] .debug_vm_pgtable++0x9d0/0xa20
[c0047d0d7be0] [c000f62c] .do_one_initcall+0x60/0x344
[c0047d0d7cc0] [c0ad8d64] .kerne]_init_freeable+0x3c0/0x3f4
[c0047d0d7db0] [c000fd88] .kernel_init+0x10/0x130
[c0047d0d7e20] [c000b9d8] .ret_from_kerne!_thread+0x58/0x60
Instruction dump:
794a07c6 654a 7fc94a78 614affbf 7d295038 2c29 33a9 7fbd4910
4182008c e93c00a0 3d420007 394aca48  810a0268 e9290028 e9290648
---[ end trace 0561544ca9dc6c58 ]---

note: swapper/0[1] exited with preempt_count 1
ata2.00: ATA-8: WDC WD5000BPKX-22HPJT0, 01.01A01, max UDMA/133
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
Rebooting in 120 seconds..

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: fsl_espi errors on v5.7.15

2020-08-24 Thread Chris Packham

On 20/08/20 9:08 am, Chris Packham wrote:
>
> On 19/08/20 6:15 pm, Heiner Kallweit wrote:
>> On 19.08.2020 00:44, Chris Packham wrote:
>>> Hi Again,
>>>
>>> On 17/08/20 9:09 am, Chris Packham wrote:
>>>
 On 14/08/20 6:19 pm, Heiner Kallweit wrote:
> On 14.08.2020 04:48, Chris Packham wrote:
>> Hi,
>>
>> I'm seeing a problem with accessing spi-nor after upgrading a T2081
>> based system to linux v5.7.15
>>
>> For this board u-boot and the u-boot environment live on spi-nor.
>>
>> When I use fw_setenv from userspace I get the following kernel logs
>>
>> # fw_setenv foo=1
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't empty!
>> fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>> fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't empty!
>> fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>> fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't empty!
>> fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>> ...
>>
> This error reporting doesn't exist yet in 4.4. So you may have an 
> issue
> under 4.4 too, it's just not reported.
> Did you verify that under 4.4 fw_setenv actually has an effect?
 Just double checked and yes under 4.4 the setting does get saved.
>> If I run fw_printenv (before getting it into a bad state) it is 
>> able to
>> display the content of the boards u-boot environment.
>>
> This might indicate an issue with spi being locked. I've seen related
> questions, just use the search engine of your choice and check for
> fw_setenv and locked.
 I'm running a version of fw_setenv which includes
 https://gitlab.denx.de/u-boot/u-boot/-/commit/db820159 so it shouldn't
 be locking things unnecessarily.
>> If been unsuccessful in producing a setup for bisecting the 
>> issue. I do
>> know the issue doesn't occur on the old 4.4.x based kernel but 
>> that's
>> probably not much help.
>>
>> Any pointers on what the issue (and/or solution) might be.
>>> I finally managed to get our board running with a vanilla kernel. With
>>> corenet64_smp_defconfig I occasionally see
>>>
>>>     fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>>
>>> other than the message things seem to be working.
>>>
>>> With a custom defconfig I see
>>>
>>>     fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>>>     fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't 
>>> empty!
>>>     fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>>     ...
>>>
>>> and access to the spi-nor does not work until the board is reset.
>>>
>>> I'll try and pick apart the differences between the two defconfigs.
>
> I now think my earlier testing is invalid. I have seen the problem 
> with either defconfig if I try hard enough. I had convinced myself 
> that the problem was CONFIG_PREEMPT but that was before I found 
> boot-to-boot differences with the same kernel.
>
> It's possible that I'm chasing multiple issues with the same symptom.
>
> The error I'm most concerned with is in the sequence
> 1. boot with old image
> 2. write environment
> 3. boot with new image
> 4. write environment
> 5. write fails and environment is corrupted
>
> After I recover the system things sometimes seem fine. Until I repeat 
> the sequence above.
>
>> Also relevant may be:
>> - Which dts are you using?
> Custom but based heavily on the t2080rdb.
>> - What's the spi-nor type, and at which frequency are you operating it?
> The board has several alternate parts for the spi-nor so the dts just 
> specifies compatible = "jedec,spi-nor" the actual chip detected on the 
> board I have is "n25q032a (4096 Kbytes)". The dts sets 
> spi-max-frequency = <1000> I haven't measured the actual frequency 
> on the bus.
>> - Does the issue still happen if you lower the frequency?
> I did play around with the frequency initially but I should probably 
> give that another 

[Bug 208957] 5.9-rc1 fails to build for a PowerMac G5: .../book3s64/hash_utils.c:1119:21: error: ‘default_uamor’ undeclared (first use in this function) 1119 | mtspr(SPRN_UAMOR, default_uamor);

2020-08-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208957

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
5.9-rc2 builds again with the same config.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: [GIT PULL] fallthrough pseudo-keyword macro conversions for 5.9-rc3

2020-08-24 Thread Gustavo A. R. Silva
Hi Nathan,

On 8/24/20 14:43, Nathan Chancellor wrote:

>> Gustavo A. R. Silva (1):
>>   treewide: Use fallthrough pseudo-keyword
> 
> $ scripts/config --file arch/powerpc/configs/powernv_defconfig -e KERNEL_XZ
> 
> $ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc64le-linux- distclean 
> powernv_defconfig zImage
> ...
> In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:234,
>  from arch/powerpc/boot/decompress.c:38:
> arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c: In function 'dec_main':
> arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:586:4: error: 'fallthrough' 
> undeclared (first use in this function)
>   586 |fallthrough;
>   |^~~
> arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:586:4: note: each 
> undeclared identifier is reported only once for each function it appears in
> In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:235,
>  from arch/powerpc/boot/decompress.c:38:
> arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c: In function 
> 'xz_dec_lzma2_run':
> arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c:1046:4: error: 'fallthrough' 
> undeclared (first use in this function)
>  1046 |fallthrough;
>   |^~~
> make[2]: *** [arch/powerpc/boot/Makefile:215: arch/powerpc/boot/decompress.o] 
> Error 1
> make[2]: Target 'arch/powerpc/boot/zImage' not remade because of errors.
> make[1]: *** [arch/powerpc/Makefile:295: zImage] Error 2
> make: *** [Makefile:335: __build_one_by_one] Error 2
> make: Target 'distclean' not remade because of errors.
> make: Target 'powernv_defconfig' not remade because of errors.
> make: Target 'zImage' not remade because of errors.
> 
> This will end up affecting distribution configurations such as Debian
> and OpenSUSE according to my testing. I am not sure what the solution
> is, the PowerPC wrapper does not set -D__KERNEL__ so I am not sure that
> compiler_attributes.h can be safely included. Adding Michael and
> linuxppc-dev to CC.
> 

Thanks for the report. I think, for now, the best solution is to
use /* fall through */ comments instead of the pseudo-keyword in
lib/

I'll send a fix for that right away.

Thanks
--
Gustavo


Re: [GIT PULL] fallthrough pseudo-keyword macro conversions for 5.9-rc3

2020-08-24 Thread Nathan Chancellor
On Sun, Aug 23, 2020 at 10:48:41PM -0500, Gustavo A. R. Silva wrote:
> Hi Linus,
> 
> Not sure what the problem was with my pull-request for -rc2. So, I'm giving
> this a second try because I think it is worth it.
> 
> I have build-tested this patch on 10 different architectures: x86_64, i386,
> arm64, powerpc, s390, sparc64, sh, m68k, powerpc64 and alpha (allyesconfig/
> allmodconfig for all of them). This is in linux-next already and kernel
> test robot has also helped me to successfully build-test early versions
> of this patch[2][3][4][5]. This patch does not introduce any new warnings.
> 
> Thank you
> --
> Gustavo
> 
> [1] 
> https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> [2] https://lore.kernel.org/lkml/5f3cc99a.hgvow3rh0md0rmkm%25...@intel.com/
> [3] https://lore.kernel.org/lkml/5f3dd1d2.l1axczh+t4hmbz63%25...@intel.com/
> [4] https://lore.kernel.org/lkml/5f3e977a.mwyhuiobbr4shr0b%25...@intel.com/
> [5] https://lore.kernel.org/lkml/5f3f9e1c.qsyb%2fayskixnpko4%25...@intel.com/
> 
> 
> The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
> 
>   Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git 
> tags/fallthrough-pseudo-keyword-5.9-rc3
> 
> for you to fetch changes up to df561f6688fef775baa341a0f5d960becd248b11:
> 
>   treewide: Use fallthrough pseudo-keyword (2020-08-23 17:36:59 -0500)
> 
> 
> fallthrough pseudo-keyword macro conversions for 5.9-rc3
> 
> Hi Linus,
> 
> Please, pull the following tree-wide patch that replaces tons (2484) of
> /* fall through */ comments, and its variants, with the new pseudo-keyword
> macro fallthrough[1]. Also, remove unnecessary fall-through markings when
> it is the case.
> 
> There are currently 1167 intances of this fallthrough pseudo-keyword
> macro in mainline (5.9-rc2), that have been introduced over the last
> couple of development cycles:
> 
> $ git grep -nw 'fallthrough;' | wc -l
> 1167
> 
> The global adoption of the fallthrough pseudo-keyword is something certain
> to happen; so, better sooner than later. :) This will also save everybody's
> time and thousands of lines of unnecessarily repetitive changelog text.
> 
> After applying this patch on top of 5.9-rc2, we'll have a total of 3651
> instances of this macro:
> 
> $ git grep -nw 'fallthrough;' | wc -l
> 3651
> 
> This treewide patch doesn't address ALL fall-through markings in all
> subsystems at once because I have previously sent out patches for some of
> such subsystems separately, and I will follow up on them; however, this
> definitely contributes most of the work needed to replace all the
> fall-through markings with the fallthrough pseudo-keyword macro in the
> whole codebase.
> 
> I have build-tested this patch on 10 different architectures: x86_64, i386,
> arm64, powerpc, s390, sparc64, sh, m68k, powerpc64 and alpha (allyesconfig
> for all of them). This is in linux-next already and kernel test robot has
> also helped me to successfully build-test early versions of this
> patch[2][3][4][5].
> 
> Thanks
> --
> [1] 
> https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> [2] https://lore.kernel.org/lkml/5f3cc99a.hgvow3rh0md0rmkm%25...@intel.com/
> [3] https://lore.kernel.org/lkml/5f3dd1d2.l1axczh+t4hmbz63%25...@intel.com/
> [4] https://lore.kernel.org/lkml/5f3e977a.mwyhuiobbr4shr0b%25...@intel.com/
> [5] https://lore.kernel.org/lkml/5f3f9e1c.qsyb%2fayskixnpko4%25...@intel.com/
> 
> 
> Gustavo A. R. Silva (1):
>   treewide: Use fallthrough pseudo-keyword

$ scripts/config --file arch/powerpc/configs/powernv_defconfig -e KERNEL_XZ

$ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc64le-linux- distclean 
powernv_defconfig zImage
...
In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:234,
 from arch/powerpc/boot/decompress.c:38:
arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c: In function 'dec_main':
arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:586:4: error: 'fallthrough' 
undeclared (first use in this function)
  586 |fallthrough;
  |^~~
arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:586:4: note: each undeclared 
identifier is reported only once for each function it appears in
In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:235,
 from arch/powerpc/boot/decompress.c:38:
arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c: In function 
'xz_dec_lzma2_run':
arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c:1046:4: error: 'fallthrough' 
undeclared (first use in this function)
 1046 |fallthrough;
  |^~~
make[2]: *** [arch/powerpc/boot/Makefile:215: arch/powerpc/boot/decompress.o] 

RE: [PATCH v2] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe

2020-08-24 Thread Leo Li



> -Original Message-
> From: Ye Bin 
> Sent: Monday, August 24, 2020 3:43 AM
> To: Leo Li ; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Cc: Ye Bin 
> Subject: [PATCH v2] usb: gadget: fsl: Fix unsigned expression compared with
> zero in fsl_udc_probe
> 
> udc_controller->irq is "unsigned int" always >= 0, but platform_get_irq may
> return little than zero. So "dc_controller->irq < 0" condition is never
> accessible.
> 
> Signed-off-by: Ye Bin 

Acked-by: Li Yang 

> ---
>  drivers/usb/gadget/udc/fsl_udc_core.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
> b/drivers/usb/gadget/udc/fsl_udc_core.c
> index a6f7b2594c09..3e98740b8cfc 100644
> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -2439,11 +2439,12 @@ static int fsl_udc_probe(struct platform_device
> *pdev)
>   /* DEN is bidirectional ep number, max_ep doubles the number */
>   udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK)
> * 2;
> 
> - udc_controller->irq = platform_get_irq(pdev, 0);
> - if (udc_controller->irq <= 0) {
> - ret = udc_controller->irq ? : -ENODEV;
> + ret = platform_get_irq(pdev, 0);
> + if (ret <= 0) {
> + ret = ret ? : -ENODEV;
>   goto err_iounmap;
>   }
> + udc_controller->irq = ret;
> 
>   ret = request_irq(udc_controller->irq, fsl_udc_irq, IRQF_SHARED,
>   driver_name, udc_controller);
> --
> 2.25.4



Re: Re:Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-24 Thread Segher Boessenkool
On Mon, Aug 24, 2020 at 07:54:07PM +0800, Guohua Zhong wrote:
> >> Yet, I have noticed that there is no checking of 'base' in these functions.
> >> But I am not sure how to check is better.As we know that the result is 
> >> undefined when divisor is zero. It maybe good to print error and dump 
> >> stack.
> >>  Let the process to know that the divisor is zero by sending SIGFPE. 
> 
> > That is now what the PowerPC integer divide insns do: they just leave
> > the result undefined (and they can set the overflow flag then, but no
> > one uses that).
> 
> OK ,So just keep the patch as below. If this patch looks good for you, please
> help to review. I will send the new patch later.
> 
> Thanks for your reply.
> 
> diff --git a/arch/powerpc/boot/div64.S b/arch/powerpc/boot/div64.S
> index 4354928ed62e..1d3561cf16fa 100644
> --- a/arch/powerpc/boot/div64.S
> +++ b/arch/powerpc/boot/div64.S
> @@ -13,8 +13,10 @@
> 
> .globl __div64_32
> .globl __div64_32
>  __div64_32:
> + cmplwi  r4,0# check if divisor r4 is zero
> lwz r5,0(r3)# get the dividend into r5/r6
> lwz r6,4(r3)
> + beq 5f  # jump to label 5 if r4(divisor) is zero

Just "beqlr".

This instruction scheduling hurts all CPUs that aren't 8xx, fwiw (but
likely only in the case where r4 *is* zero, so who cares :-) )

So...  What is the *goal* of this patch?  It looks like the routine
would not get into a loop if r4 is 0, just return the wrong result?
But, it *always* will, there *is* no right result?

No caller should call it with zero as divisor ever, so in that sense,
checking for it in the division routine is just pure wasted work.


Segher


[PATCH AUTOSEL 4.4 6/6] powerpc/perf: Fix soft lockups due to missed interrupt accounting

2020-08-24 Thread Sasha Levin
From: Athira Rajeev 

[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]

Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().

Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.

But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.

Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Athira Rajeev 
Tested-by: Alexey Kardashevskiy 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atraj...@linux.vnet.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/perf/core-book3s.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 30e2e8efbe6b7..aab13558e9700 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2040,6 +2040,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
 
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
+   } else if (period) {
+   /* Account for interrupt in case of invalid SIAR */
+   if (perf_event_account_interrupt(event))
+   power_pmu_stop(event, 0);
}
 }
 
-- 
2.25.1



[PATCH AUTOSEL 4.9 8/8] powerpc/perf: Fix soft lockups due to missed interrupt accounting

2020-08-24 Thread Sasha Levin
From: Athira Rajeev 

[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]

Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().

Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.

But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.

Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Athira Rajeev 
Tested-by: Alexey Kardashevskiy 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atraj...@linux.vnet.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/perf/core-book3s.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index ba49ae6625f1b..a10b67df83bae 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2042,6 +2042,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
 
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
+   } else if (period) {
+   /* Account for interrupt in case of invalid SIAR */
+   if (perf_event_account_interrupt(event))
+   power_pmu_stop(event, 0);
}
 }
 
-- 
2.25.1



[PATCH AUTOSEL 4.14 11/11] powerpc/perf: Fix soft lockups due to missed interrupt accounting

2020-08-24 Thread Sasha Levin
From: Athira Rajeev 

[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]

Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().

Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.

But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.

Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Athira Rajeev 
Tested-by: Alexey Kardashevskiy 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atraj...@linux.vnet.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/perf/core-book3s.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 3188040022c4f..78f75e48dfe7f 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2096,6 +2096,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
 
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
+   } else if (period) {
+   /* Account for interrupt in case of invalid SIAR */
+   if (perf_event_account_interrupt(event))
+   power_pmu_stop(event, 0);
}
 }
 
-- 
2.25.1



[PATCH AUTOSEL 4.19 21/21] powerpc/perf: Fix soft lockups due to missed interrupt accounting

2020-08-24 Thread Sasha Levin
From: Athira Rajeev 

[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]

Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().

Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.

But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.

Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Athira Rajeev 
Tested-by: Alexey Kardashevskiy 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atraj...@linux.vnet.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/perf/core-book3s.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 4004dbdab9c7b..d407b73298171 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2087,6 +2087,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
 
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
+   } else if (period) {
+   /* Account for interrupt in case of invalid SIAR */
+   if (perf_event_account_interrupt(event))
+   power_pmu_stop(event, 0);
}
 }
 
-- 
2.25.1



[PATCH AUTOSEL 5.4 36/38] powerpc/perf: Fix soft lockups due to missed interrupt accounting

2020-08-24 Thread Sasha Levin
From: Athira Rajeev 

[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]

Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().

Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.

But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.

Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Athira Rajeev 
Tested-by: Alexey Kardashevskiy 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atraj...@linux.vnet.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/perf/core-book3s.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index ca92e01d0bd1b..e32f7700303bc 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2106,6 +2106,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
 
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
+   } else if (period) {
+   /* Account for interrupt in case of invalid SIAR */
+   if (perf_event_account_interrupt(event))
+   power_pmu_stop(event, 0);
}
 }
 
-- 
2.25.1



[PATCH AUTOSEL 5.7 50/54] powerpc/perf: Fix soft lockups due to missed interrupt accounting

2020-08-24 Thread Sasha Levin
From: Athira Rajeev 

[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]

Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().

Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.

But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.

Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Athira Rajeev 
Tested-by: Alexey Kardashevskiy 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atraj...@linux.vnet.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/perf/core-book3s.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 3dcfecf858f36..5216c5a7f46da 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2099,6 +2099,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
 
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
+   } else if (period) {
+   /* Account for interrupt in case of invalid SIAR */
+   if (perf_event_account_interrupt(event))
+   power_pmu_stop(event, 0);
}
 }
 
-- 
2.25.1



[PATCH AUTOSEL 5.8 59/63] powerpc/perf: Fix soft lockups due to missed interrupt accounting

2020-08-24 Thread Sasha Levin
From: Athira Rajeev 

[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]

Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().

Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.

But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.

Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Athira Rajeev 
Tested-by: Alexey Kardashevskiy 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atraj...@linux.vnet.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/perf/core-book3s.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 01d70280d2872..190bc4f255b42 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2101,6 +2101,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
 
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
+   } else if (period) {
+   /* Account for interrupt in case of invalid SIAR */
+   if (perf_event_account_interrupt(event))
+   power_pmu_stop(event, 0);
}
 }
 
-- 
2.25.1



RE: Re:Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-24 Thread David Laight
From: Guohua Zhong
> Sent: 24 August 2020 14:26
> 
> >> >In generic version in lib/math/div64.c, there is no checking of 'base'
> >> >either.
> >> >Do we really want to add this check in the powerpc version only ?
> >>
> >> >The only user of __div64_32() is do_div() in
> >> >include/asm-generic/div64.h. Wouldn't it be better to do the check there ?
> >>
> >> >Christophe
> >>
> >> Yet, I have noticed that there is no checking of 'base' in these functions.
> >> But I am not sure how to check is better.As we know that the result is
> >> undefined when divisor is zero. It maybe good to print error and dump 
> >> stack.

I thought that the onus was put on the caller to avoid divide by zero.

On x86 divide by zero causes an exception which (I'm pretty sure)
leads to a oops/panic.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)


Re: [PATCH] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe

2020-08-24 Thread Joakim Tjernlund
On Mon, 2020-08-24 at 16:58 +0300, Felipe Balbi wrote:
> Joakim Tjernlund  writes:
> 
> > On Mon, 2020-08-24 at 10:21 +0200, Greg KH wrote:
> > > 
> > > On Mon, Aug 24, 2020 at 04:04:37PM +0800, Ye Bin wrote:
> > > > Signed-off-by: Ye Bin 
> > > 
> > > I can't take patches without any changelog text, sorry.
> > 
> > Still taking patches for fsl_udc_core.c ?
> > I figured this driver was obsolete and should be moved to one of the 
> > Chipidea drivers.
> 
> Nobody sent any patches to switch over the users of this driver to
> chipidea. I would love to delete this driver :-)

Me too, I got a few local patches here as the driver is quite buggy.
Got to little USB knowledge to switch it over though :(

 Jocke


Re: [PATCH] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe

2020-08-24 Thread Felipe Balbi
Joakim Tjernlund  writes:

> On Mon, 2020-08-24 at 10:21 +0200, Greg KH wrote:
>> 
>> On Mon, Aug 24, 2020 at 04:04:37PM +0800, Ye Bin wrote:
>> > Signed-off-by: Ye Bin 
>> 
>> I can't take patches without any changelog text, sorry.
>
> Still taking patches for fsl_udc_core.c ?
> I figured this driver was obsolete and should be moved to one of the Chipidea 
> drivers.

Nobody sent any patches to switch over the users of this driver to
chipidea. I would love to delete this driver :-)

-- 
balbi


signature.asc
Description: PGP signature


Re: Re:Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-24 Thread Guohua Zhong
>> >In generic version in lib/math/div64.c, there is no checking of 'base' 
>> >either.
>> >Do we really want to add this check in the powerpc version only ?
>> 
>> >The only user of __div64_32() is do_div() in 
>> >include/asm-generic/div64.h. Wouldn't it be better to do the check there ?
>> 
>> >Christophe
>> 
>> Yet, I have noticed that there is no checking of 'base' in these functions.
>> But I am not sure how to check is better.As we know that the result is 
>> undefined when divisor is zero. It maybe good to print error and dump stack.
>>  Let the process to know that the divisor is zero by sending SIGFPE. 
>> 
>> diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h
>> index a3b98c86f077..161c656ee3ee 100644
>> --- a/include/asm-generic/div64.h
>> +++ b/include/asm-generic/div64.h
>> @@ -43,6 +43,11 @@
>>  # define do_div(n,base) ({ \
>> uint32_t __base = (base);   \
>> uint32_t __rem; \
>> + if (unlikely(base == 0)) {  \
>> + pr_err("do_div base=%d\n",base);\
>> + dump_stack();   \
>> + force_sig(SIGFPE);  \
>> + }  
>> 

> I suspect this will generate a strong reaction. SIGFPE is for user space
> instruction attempting a division by zero. A division by zero in the
> kernel is a kernel bug, period, and you don't want to kill a user
> process for this reason.

> If it happens in an interrupt, the context of the kernel may not even be
> related to the current process.

> Many other architectures (x86 for example) already trigger an exception
> on a division by zero but the handler will find that the exception
> happened in kernel context and generate an Oops, not raise a signal in a
> (possibly innocent) userland process.

OK. So just don't touch do_div functions in include/asm-generic/div64.h
But for powerpc it can not trigger an exception when divisor is 0 in __div64_32.


So the patch as below is still useful for powerpc. If this patch looks good for 
you, please help to review. I will send the new patch later.

Thanks for your reply.

diff --git a/arch/powerpc/boot/div64.S b/arch/powerpc/boot/div64.S
index 4354928ed62e..1d3561cf16fa 100644
--- a/arch/powerpc/boot/div64.S
+++ b/arch/powerpc/boot/div64.S
@@ -13,8 +13,10 @@

.globl __div64_32
.globl __div64_32
 __div64_32:
+ cmplwi  r4,0# check if divisor r4 is zero
lwz r5,0(r3)# get the dividend into r5/r6
lwz r6,4(r3)
+ beq 5f  # jump to label 5 if r4(divisor) is zero
cmplw   r5,r4
li  r7,0
li  r8,0
@@ -52,7 +54,7 @@ __div64_32:
 4: stw r7,0(r3)# return the quotient in *r3
stw r8,4(r3)
mr  r3,r6   # return the remainder in r3
-   blr
+5:   blr # return if divisor r4 is zero

 /*
  * Extended precision shifts.
diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
index 3d5426e7dcc4..570774d9782d 100644
--- a/arch/powerpc/lib/div64.S
+++ b/arch/powerpc/lib/div64.S
@@ -13,8 +13,10 @@
 #include 

 _GLOBAL(__div64_32)
+ cmplwi  r4,0# check if divisor r4 is zero
lwz r5,0(r3)# get the dividend into r5/r6
lwz r6,4(r3)
+ beq 5f  # jump to label 5 if r4(divisor) is zero
cmplw   r5,r4
li  r7,0
li  r8,0
@@ -52,4 +54,4 @@ _GLOBAL(__div64_32)
 4: stw r7,0(r3)# return the quotient in *r3
stw r8,4(r3)
mr  r3,r6   # return the remainder in r3
-   blr
+5:   blr # return if divisor r4 is zero

Guohua



[PATCH] selftests/powerpc: Fix prefixes in alignment_handler signal handler

2020-08-24 Thread Jordan Niethe
The signal handler in the alignment handler self test has the ability to
jump over the instruction that triggered the signal. It does this by
incrementing the PT_NIP in the user context by 4. If it were a prefixed
instruction this will mean that the suffix is then executed which is
incorrect. Instead check if the major opcode indicates a prefixed
instruction (e.g. it is 1) and if so increment PT_NIP by 8.

If ISA v3.1 is not available treat it as a word instruction even if the
major opcode is 1.

Fixes: 620a6473df36 ("selftests/powerpc: Add prefixed loads/stores to
alignment_handler test")
Signed-off-by: Jordan Niethe 
---
 .../selftests/powerpc/alignment/alignment_handler.c   | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/powerpc/alignment/alignment_handler.c 
b/tools/testing/selftests/powerpc/alignment/alignment_handler.c
index 55ef15184057..c197ff828120 100644
--- a/tools/testing/selftests/powerpc/alignment/alignment_handler.c
+++ b/tools/testing/selftests/powerpc/alignment/alignment_handler.c
@@ -64,12 +64,14 @@ int bufsize;
 int debug;
 int testing;
 volatile int gotsig;
+bool haveprefixes;
 char *cipath = "/dev/fb0";
 long cioffset;
 
 void sighandler(int sig, siginfo_t *info, void *ctx)
 {
ucontext_t *ucp = ctx;
+   u32 inst;
 
if (!testing) {
signal(sig, SIG_DFL);
@@ -77,7 +79,12 @@ void sighandler(int sig, siginfo_t *info, void *ctx)
}
gotsig = sig;
 #ifdef __powerpc64__
-   ucp->uc_mcontext.gp_regs[PT_NIP] += 4;
+   if (haveprefixes) {
+   inst = *(u32 *)ucp->uc_mcontext.gp_regs[PT_NIP];
+   ucp->uc_mcontext.gp_regs[PT_NIP] += ((inst >> 26 == 1) ? 8 : 4);
+   } else {
+   ucp->uc_mcontext.gp_regs[PT_NIP] += 4;
+   }
 #else
ucp->uc_mcontext.uc_regs->gregs[PT_NIP] += 4;
 #endif
@@ -648,6 +655,8 @@ int main(int argc, char *argv[])
exit(1);
}
 
+   haveprefixes = have_hwcap2(PPC_FEATURE2_ARCH_3_1);
+
rc |= test_harness(test_alignment_handler_vsx_206,
   "test_alignment_handler_vsx_206");
rc |= test_harness(test_alignment_handler_vsx_207,
-- 
2.17.1



Re: Re:Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-24 Thread Guohua Zhong
>> Yet, I have noticed that there is no checking of 'base' in these functions.
>> But I am not sure how to check is better.As we know that the result is 
>> undefined when divisor is zero. It maybe good to print error and dump stack.
>>  Let the process to know that the divisor is zero by sending SIGFPE. 

> That is now what the PowerPC integer divide insns do: they just leave
> the result undefined (and they can set the overflow flag then, but no
> one uses that).

OK ,So just keep the patch as below. If this patch looks good for you, please
help to review. I will send the new patch later.

Thanks for your reply.

diff --git a/arch/powerpc/boot/div64.S b/arch/powerpc/boot/div64.S
index 4354928ed62e..1d3561cf16fa 100644
--- a/arch/powerpc/boot/div64.S
+++ b/arch/powerpc/boot/div64.S
@@ -13,8 +13,10 @@

.globl __div64_32
.globl __div64_32
 __div64_32:
+ cmplwi  r4,0# check if divisor r4 is zero
lwz r5,0(r3)# get the dividend into r5/r6
lwz r6,4(r3)
+ beq 5f  # jump to label 5 if r4(divisor) is zero
cmplw   r5,r4
li  r7,0
li  r8,0
@@ -52,7 +54,7 @@ __div64_32:
 4: stw r7,0(r3)# return the quotient in *r3
stw r8,4(r3)
mr  r3,r6   # return the remainder in r3
-   blr
+5:   blr # return if divisor r4 is zero

 /*
  * Extended precision shifts.
diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
index 3d5426e7dcc4..570774d9782d 100644
--- a/arch/powerpc/lib/div64.S
+++ b/arch/powerpc/lib/div64.S
@@ -13,8 +13,10 @@
 #include 

 _GLOBAL(__div64_32)
+ cmplwi  r4,0# check if divisor r4 is zero
lwz r5,0(r3)# get the dividend into r5/r6
lwz r6,4(r3)
+ beq 5f  # jump to label 5 if r4(divisor) is zero
cmplw   r5,r4
li  r7,0
li  r8,0
@@ -52,4 +54,4 @@ _GLOBAL(__div64_32)
 4: stw r7,0(r3)# return the quotient in *r3
stw r8,4(r3)
mr  r3,r6   # return the remainder in r3
-   blr
+5:   blr # return if divisor r4 is zero

Guohua



Re: [PATCH] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe

2020-08-24 Thread Joakim Tjernlund
On Mon, 2020-08-24 at 10:21 +0200, Greg KH wrote:
> 
> On Mon, Aug 24, 2020 at 04:04:37PM +0800, Ye Bin wrote:
> > Signed-off-by: Ye Bin 
> 
> I can't take patches without any changelog text, sorry.

Still taking patches for fsl_udc_core.c ?
I figured this driver was obsolete and should be moved to one of the Chipidea 
drivers.

 Jocke


[PATCH v2] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe

2020-08-24 Thread Ye Bin
udc_controller->irq is "unsigned int" always >= 0, but platform_get_irq may
return little than zero. So "dc_controller->irq < 0" condition is never
accessible.

Signed-off-by: Ye Bin 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index a6f7b2594c09..3e98740b8cfc 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2439,11 +2439,12 @@ static int fsl_udc_probe(struct platform_device *pdev)
/* DEN is bidirectional ep number, max_ep doubles the number */
udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;
 
-   udc_controller->irq = platform_get_irq(pdev, 0);
-   if (udc_controller->irq <= 0) {
-   ret = udc_controller->irq ? : -ENODEV;
+   ret = platform_get_irq(pdev, 0);
+   if (ret <= 0) {
+   ret = ret ? : -ENODEV;
goto err_iounmap;
}
+   udc_controller->irq = ret;
 
ret = request_irq(udc_controller->irq, fsl_udc_irq, IRQF_SHARED,
driver_name, udc_controller);
-- 
2.25.4



[PATCH] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe

2020-08-24 Thread Ye Bin
Signed-off-by: Ye Bin 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index a6f7b2594c09..3e98740b8cfc 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2439,11 +2439,12 @@ static int fsl_udc_probe(struct platform_device *pdev)
/* DEN is bidirectional ep number, max_ep doubles the number */
udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;
 
-   udc_controller->irq = platform_get_irq(pdev, 0);
-   if (udc_controller->irq <= 0) {
-   ret = udc_controller->irq ? : -ENODEV;
+   ret = platform_get_irq(pdev, 0);
+   if (ret <= 0) {
+   ret = ret ? : -ENODEV;
goto err_iounmap;
}
+   udc_controller->irq = ret;
 
ret = request_irq(udc_controller->irq, fsl_udc_irq, IRQF_SHARED,
driver_name, udc_controller);
-- 
2.25.4



Re: [PATCH] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe

2020-08-24 Thread Greg KH
On Mon, Aug 24, 2020 at 04:04:37PM +0800, Ye Bin wrote:
> Signed-off-by: Ye Bin 

I can't take patches without any changelog text, sorry.

greg k-h