Re: [PATCH v2] powerpc/perf: Fix loop exit condition in nest_imc_event_init

2019-05-03 Thread Michael Ellerman
On Tue, 2018-12-18 at 06:20:41 UTC, Anju T Sudhakar wrote:
> The data structure (i.e struct imc_mem_info) to hold the memory address
> information for nest imc units is allocated based on the number of nodes
> in the system.
> 
> nest_imc_event_init() traverse this struct array to calculate the memory
> base address for the event-cpu. If we fail to find a match for the event
> cpu's chip-id in imc_mem_info struct array, then the do-while loop will
> iterate until we crash.
> 
> Fix this by changing the loop exit condition based on the number of 
> non zero vbase elements in the array, since the allocation is done for
> nr_chips + 1.
> 
> Reported-by: Dan Carpenter  
> Fixes: 885dcd709ba91 ( powerpc/perf: Add nest IMC PMU support)
> Signed-off-by: Anju T Sudhakar 
> Reviewed-by: Madhavan Srinivasan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/860b7d2286236170a36f94946d03ca98

cheers


Re: [PATCH] powerpc/tm: Avoid machine crash on rt_sigreturn

2019-05-03 Thread Michael Ellerman
On Wed, 2019-01-16 at 16:47:44 UTC, Breno Leitao wrote:
> There is a kernel crash that happens if rt_sigreturn is called inside a
> transactional block.
> 
> This crash happens if the kernel hits an in-kernel page fault when
> accessing userspace memory, usually through copy_ckvsx_to_user(). A major
> page fault calls might_sleep() function, which can cause a task reschedule.
> A task reschedule (switch_to()) reclaim and recheckpoint the TM states,
> but, in the signal return path, the checkpointed memory was already
> reclaimed, thus the exception stack has MSR that points to MSR[TS]=0.
> 
> When the code returns from might_sleep() and a task reschedule happened,
> then this task is returned with the memory recheckpointed, and
> CPU MSR[TS] = suspended.
> 
> This means that there is a side effect at might_sleep() if it is called
> with CPU MSR[TS] = 0 and the task has regs->msr[TS] != 0.
> 
> This side effect can cause a TM bad thing, since at the exception entrance,
> the stack saves MSR[TS]=0, and this is what will be used at RFID, but,
> the processor has MSR[TS] = Suspended, and this transition will be invalid
> and a TM Bad thing will be raised, causing the following crash:
> 
>   Unexpected TM Bad Thing exception at c000e9ec (msr 
> 0x800302a03031) tm_scratch=80010280b033
>   cpu 0xc: Vector: 700 (Program Check) at [c0003ff1fd70]
>   pc: c000e9ec: fast_exception_return+0x100/0x1bc
>   lr: c0032948: handle_rt_signal64+0xb8/0xaf0
>   sp: c004263ebc40
>  msr: 800302a03031
> current = 0xc00415050300
> paca= 0xc0003ffc4080   irqmask: 0x03   irq_happened: 0x01
>   pid   = 25006, comm = sigfuz
>   Linux version 5.0.0-rc1-1-g3bd6e94bec12 (breno@debian) (gcc version 
> 8.2.0 (Debian 8.2.0-3)) #899 SMP Mon Jan 7 11:30:07 EST 2019
>   WARNING: exception is not recoverable, can't continue
>   enter ? for help
>   [c004263ebc40] c0032948 handle_rt_signal64+0xb8/0xaf0 
> (unreliable)
>   [c004263ebd30] c0022780 do_notify_resume+0x2f0/0x430
>   [c004263ebe20] c000e844 ret_from_except_lite+0x70/0x74
>   --- Exception: c00 (System Call) at 7fffbaac400c
>   SP (7fffeca90f40) is in userspace
> 
> The solution for this problem is running the sigreturn code with
> regs->msr[TS] disabled, thus, avoiding hitting the side effect above. This
> does not seem to be a problem since regs->msr will be replaced by the
> ucontext value, so, it is being flushed already. In this case, it is
> flushed earlier.
> 
> Signed-off-by: Breno Leitao 
> Acked-by: Michael Neuling 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/e620d45065c7b5b8d6ae11217c09c093

cheers


Re: [PATCH] Selftests/powerpc: Add a signal fuzzer selftest

2019-05-03 Thread Michael Ellerman
On Thu, 2019-01-17 at 17:01:54 UTC, Breno Leitao wrote:
> This is a new selftest that raises SIGUSR1 signals and handles it in a set
> of different ways, trying to create different scenario for testing
> purpose.
> 
> This test works raising a signal and calling sigreturn interleaved with
> TM operations, as starting, suspending and terminating a transaction. The
> test depends on random numbers, and, based on them, it sets different TM
> states.
> 
> Other than that, the test fills out the user context struct that is passed
> to the sigreturn system call with random data, in order to make sure that
> the signal handler syscall can handle different and invalid states
> properly.
> 
> This selftest has command line parameters to control what kind of tests the
> user wants to run, as for example, if a transaction should be started prior
> to signal being raised, or, after the signal being raised and before the
> sigreturn. If no parameter is given, the default is enabling all options.
> 
> This test does not check if the user context is being read and set
> properly by the kernel. Its purpose, at this time, is basically
> guaranteeing that the kernel does not crash on invalid scenarios.
> 
> Signed-off-by: Breno Leitao 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/83e367f9ad18d42a1883ee29f20608a2

cheers


Re: [PATCH] powerpc/hmi: Fix kernel hang when TB is in error state.

2019-05-03 Thread Michael Ellerman
On Mon, 2019-03-04 at 19:42:19 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar 
> 
> On TOD/TB errors timebase register stops/freezes until HMI error recovery
> gets TOD/TB back into running state. On successful recovery, TB starts
> running again and udelay() that relies on TB value continues to function
> properly. But in case when HMI fails to recover from TOD/TB errors, the
> TB register stay freezed. With TB not running the __delay() function
> keeps looping and never return. If __delay() is called while in panic
> path then system hangs and never reboots after panic.
> 
> Signed-off-by: Mahesh Salgaonkar 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/de269129a48a2d590ba1d20c719e19d8

cheers


Re: [PATCH] powerpc/dts/fsl: add crypto node alias for B4

2019-05-03 Thread Michael Ellerman
On Wed, 2019-03-20 at 12:55:16 UTC, =?utf-8?q?Horia_Geant=C4=83?= wrote:
> crypto node alias is needed by U-boot to identify the node and
> perform fix-ups, like adding "fsl,sec-era" property.
> 
> Signed-off-by: Horia Geantă 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/32eebf96669568014b79b83a03f7895f

cheers


Re: [PATCH v2] powerpc/64s: Remove 'dummy_copy_buffer'

2019-05-03 Thread Michael Ellerman
On Wed, 2019-03-13 at 20:00:30 UTC, Mathieu Malaterre wrote:
> In commit 2bf1071a8d50 ("powerpc/64s: Remove POWER9 DD1 support") the
> function __switch_to remove usage for 'dummy_copy_buffer'. Since it is
> not used anywhere else, remove it completely.
> 
> This remove the following warning:
> 
>   arch/powerpc/kernel/process.c:1156:17: error: 'dummy_copy_buffer' defined 
> but not used [-Werror=unused-const-variable=]
> 
> Cc: Nicholas Piggin 
> Suggested-by: Christophe Leroy 
> Signed-off-by: Mathieu Malaterre 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a5ae043de7678f189303559782f60570

cheers


Re: [PATCH 1/7] powerpc/fadump: define an empty fadump_cleanup()

2019-05-03 Thread Michael Ellerman
On Fri, 2019-03-22 at 08:08:39 UTC, Christophe Leroy wrote:
> To avoid #ifdefs, define an static inline fadump_cleanup() function
> when CONFIG_FADUMP is not selected
> 
> Signed-off-by: Christophe Leroy 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/9c1d38b34e944cace44e0d2bea0beb56

cheers


Re: [PATCH] powerpc/irq: drop __irq_offset_value

2019-05-03 Thread Michael Ellerman
On Sat, 2019-03-09 at 17:47:27 UTC, Christophe Leroy wrote:
> This patch drops__irq_offset_value which has not been used since
> commit 9c4cb8251513 ("powerpc: Remove use of CONFIG_PPC_MERGE")
> 
> This removes a sparse warning.
> 
> Fixes: 9c4cb8251513 ("powerpc: Remove use of CONFIG_PPC_MERGE")
> Signed-off-by: Christophe Leroy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/502523fd1d2ac559b41d8302dc9f826f

cheers


Re: [PATCH 08/14] powerpc: entry: Remove unneeded need_resched() loop

2019-05-03 Thread Michael Ellerman
On Mon, 2019-03-11 at 22:47:46 UTC, Valentin Schneider wrote:
> Since the enabling and disabling of IRQs within preempt_schedule_irq()
> is contained in a need_resched() loop, we don't need the outer arch
> code loop.
> 
> Signed-off-by: Valentin Schneider 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-dev@lists.ozlabs.org

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/90437bffa5f9b1440ba03e023f4875d1

cheers


Re: [PATCH v4 1/7] ocxl: Split pci.c

2019-05-03 Thread Michael Ellerman
On Wed, 2019-03-27 at 05:31:30 UTC, "Alastair D'Silva" wrote:
> From: Alastair D'Silva 
> 
> In preparation for making core code available for external drivers,
> move the core code out of pci.c and into core.c
> 
> Signed-off-by: Alastair D'Silva 
> Acked-by: Frederic Barrat 
> Acked-by: Andrew Donnellan 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/1ba2143606a10f1c2e7308bc7abd940a

cheers


Re: [PATCH v4 1/4] ocxl: Rename struct link to ocxl_link

2019-05-03 Thread Michael Ellerman
On Mon, 2019-03-25 at 05:34:52 UTC, "Alastair D'Silva" wrote:
> From: Alastair D'Silva 
> 
> The term 'link' is ambiguous (especially when the struct is used for a
> list), so rename it for clarity.
> 
> Signed-off-by: Alastair D'Silva 
> Reviewed-by: Greg Kurz 
> Acked-by: Frederic Barrat 
> Acked-by: Andrew Donnellan 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/9c4ae0645682b97437072693f0edbee1

cheers


Re: [PATCH] powerpc/nohash64: clean pgtable.h

2019-05-03 Thread Michael Ellerman
On Thu, 2019-03-28 at 13:19:47 UTC, Christophe Leroy wrote:
> TRANSPARENT_HUGEPAGE is only supported by book3s
> 
> VMEMMAP_REGION_ID is never used
> 
> Signed-off-by: Christophe Leroy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/71faf8145cdc20f22aa398eb7b206b33

cheers


Re: [PATCH -next] ocxl: remove set but not used variables 'tid' and 'lpid'

2019-05-03 Thread Michael Ellerman
On Fri, 2019-03-29 at 15:44:56 UTC, Yue Haibing wrote:
> From: YueHaibing 
> 
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/misc/ocxl/link.c: In function 'xsl_fault_handler':
> drivers/misc/ocxl/link.c:187:17: warning: variable 'tid' set but not used 
> [-Wunused-but-set-variable]
> drivers/misc/ocxl/link.c:187:6: warning: variable 'lpid' set but not used 
> [-Wunused-but-set-variable]
> 
> They are never used and can be removed.
> 
> Signed-off-by: YueHaibing 
> Reviewed-by: Mukesh Ojha 
> Acked-by: Andrew Donnellan 
> Acked-by: Frederic Barrat 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/32eeb5614d3bf166e84fe69bb5f3a51a

cheers


Re: [PATCH] powerpc/book3e: drop BUG_ON() in map_kernel_page()

2019-05-03 Thread Michael Ellerman
On Thu, 2019-03-28 at 13:03:45 UTC, Christophe Leroy wrote:
> early_alloc_pgtable() never returns NULL as it panics on failure.
> 
> This patch drops the three BUG_ON() which check the non nullity
> of early_alloc_pgtable() returned value.
> 
> Signed-off-by: Christophe Leroy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a1ac2a9c4f98482e49305ab5551b7b32

cheers


Re: [PATCH] powerpc/perf: Remove PM_BR_CMPL_ALT from power9 event list

2019-05-03 Thread Michael Ellerman
On Mon, 2019-04-01 at 06:20:39 UTC, Madhavan Srinivasan wrote:
> PM_BR_CMPL_ALT event is not supported and remove from the power9 event list
> 
> Fixes: 24bedcb7c811 ('powerpc/perf: Fix branch event code for power9')
> Signed-off-by: Madhavan Srinivasan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/659a6e38db0b422c63fd68ca7e78a8da

cheers


Re: [PATCH v1 1/4] powerpc/mm: change #include "mmu_decl.h" to

2019-05-03 Thread Michael Ellerman
On Fri, 2019-03-29 at 09:59:59 UTC, Christophe Leroy wrote:
> This patch make inclusion of mmu_decl.h independant of the location
> of the file including it.
> 
> Signed-off-by: Christophe Leroy 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/9d9f2cccde952126185e3336af0d4dc6

cheers


Re: [PATCH] Documentation: powerpc: Expand the DAWR acronym

2019-05-03 Thread Michael Ellerman
On Mon, 2019-04-01 at 06:11:56 UTC, Joel Stanley wrote:
> Those not of us not drowning in POWER might not know what this means.
> 
> Signed-off-by: Joel Stanley 
> Acked-by: Michael Neuling 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/29b861ea7742e571c1940366944eabc2

cheers


Re: [PATCH v2] powerpc/watchdog: Use hrtimers for per-CPU heartbeat

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-09 at 04:40:05 UTC, Nicholas Piggin wrote:
> Using a jiffies timer creates a dependency on the tick_do_timer_cpu
> incrementing jiffies. If that CPU has locked up and jiffies is not
> incrementing, the watchdog heartbeat timer for all CPUs stops and
> creates false positives and confusing warnings on local CPUs, and
> also causes the SMP detector to stop, so the root cause is never
> detected.
> 
> Fix this by using hrtimer based timers for the watchdog heartbeat,
> like the generic kernel hardlockup detector.
> 
> Cc: Gautham R. Shenoy 
> Reported-by: Ravikumar Bangoria 
> Signed-off-by: Nicholas Piggin 
> Tested-by: Ravi Bangoria 
> Reported-by: Ravi Bangoria 
> Reviewed-by: Gautham R. Shenoy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/7ae3f6e130e8dc6188b59e3b4ebc2f16

cheers


Re: [PATCH] powerpc: config: skiroot: Add (back) MLX5 ethernet support

2019-05-03 Thread Michael Ellerman
On Wed, 2019-04-03 at 00:49:26 UTC, Joel Stanley wrote:
> It turns out that some defconfig changes and kernel config option
> changes meant we accidentally dropped Ethernet support for Mellanox CLX5
> cards.
> 
> Reported-by: Carol L Soto 
> Suggested-by: Carol L Soto 
> Signed-off-by: Stewart Smith 
> Signed-off-by: Joel Stanley 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/e1619e89c96c596d72e66f15a0794f50

cheers


Re: [PATCH 2/2] powerpc/perf: Add generic compat mode pmu driver

2019-05-03 Thread Michael Ellerman
On Thu, 2019-04-04 at 11:54:50 UTC, Madhavan Srinivasan wrote:
> Most of the power processor generation performance monitoring
> unit (PMU) driver code is bundled in the kernel and one of those
> is enabled/registered based on the oprofile_cpu_type check at
> the boot.
> 
> But things get little tricky incase of "compat" mode boot.
> IBM POWER System Server based processors has a compactibility
> mode feature, which simpily put is, Nth generation processor
> (lets say POWER8) will act and appear in a mode consistent
> with an earlier generation (N-1) processor (that is POWER7).
> And in this "compat" mode boot, kernel modify the
> "oprofile_cpu_type" to be Nth generation (POWER8). If Nth
> generation pmu driver is bundled (POWER8), it gets registered.
> 
> Key dependency here is to have distro support for latest
> processor performance monitoring support. Patch here adds
> a generic "compat-mode" performance monitoring driver to
> be register in absence of powernv platform specific pmu driver.
> 
> Driver supports only "cycles" and "instruction" events.
> "0x0001e" used as event code for "cycles" and "0x2"
> used as event code for "instruction" events. New file
> called "generic-compat-pmu.c" is created to contain the driver
> specific code. And base raw event code format modeled
> on PPMU_ARCH_207S.
> 
> Signed-off-by: Madhavan Srinivasan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/be80e758d0c2ec87eceac7676f08c761

cheers


Re: [PATCH 4/9] powerpc/prom_init: get rid of PROM_SCRATCH_SIZE

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-02 at 09:08:38 UTC, Christophe Leroy wrote:
> PROM_SCRATCH_SIZE is same as sizeof(prom_scratch)
> 
> Signed-off-by: Christophe Leroy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/d7fbe2a0439ce6f20917a65990a78c9e

cheers


Re: [PATCH] powerpc/security: Show powerpc_security_features in debugfs

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-09 at 13:14:20 UTC, Michael Ellerman wrote:
> This can be helpful for debugging problems with the security feature
> flags, especially on guests where the flags come from the hypervisor
> via an hcall and so can't be observed in the device tree.
> 
> Signed-off-by: Michael Ellerman 
> Reviewed-by: Joel Stanley 

Applied to powerpc next.

https://git.kernel.org/powerpc/c/398af571128fe75f07343f929975b26d

cheers


Re: [PATCH v2 1/2] powerpc/perf: init pmu from core-book3s

2019-05-03 Thread Michael Ellerman
On Thu, 2019-04-04 at 11:54:49 UTC, Madhavan Srinivasan wrote:
> Currenty pmu driver file for each ppc64 generation processor
> has a __init call in itself. Refactor the code by moving the
> __init call to core-books.c. This also clean's up compat mode
> pmu driver registration.
> 
> Suggested-by: Michael Ellerman 
> Signed-off-by: Madhavan Srinivasan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/708597daf23486ea6f889ca29cc88389

cheers


Re: [PATCH kernel] powerpc/powernv/ioda: Handle failures correctly in pnv_pci_ioda_iommu_bypass_supported

2019-05-03 Thread Michael Ellerman
On Wed, 2019-04-10 at 06:48:00 UTC, Alexey Kardashevskiy wrote:
> When the return value type was changed from int to bool, few places were
> left unchanged, this fixes them. We did not hit these failures as
> the first one is not happening at all and the second one is little more
> likely to happen if the user switches a 33..58bit DMA capable device
> between the VFIO and vendor drivers and there are not so many of these.
> 
> Fixes: 2d6ad41b2c21 ("powerpc/powernv: use the generic iommu bypass code", 
> 2019-02-13)
> Signed-off-by: Alexey Kardashevskiy 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/b511cdd1c12d1e450baeba5373dd3a88

cheers


Re: [PATCH v2] powerpc/booke64: set RI in default MSR

2019-05-03 Thread Michael Ellerman
On Mon, 2019-04-15 at 11:52:11 UTC, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor 
> 
> Set RI in the default kernel's MSR so that the architected way of
> detecting unrecoverable machine check interrupts has a chance to work.
> This is inline with the MSR setup of the rest of booke powerpc
> architectures configured here.
> 
> Signed-off-by: Laurentiu Tudor 
> Cc: sta...@vger.kernel.org

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/5266e58d6cd90ac85c187d673093ad9c

cheers


Re: [PATCH v4] powerpc/xmon: add read-only mode

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-16 at 03:26:38 UTC, "Christopher M. Riedl" wrote:
> Operations which write to memory and special purpose registers should be
> restricted on systems with integrity guarantees (such as Secure Boot)
> and, optionally, to avoid self-destructive behaviors.
> 
> Add a config option, XMON_DEFAULT_RO_MODE, to set default xmon behavior.
> The kernel cmdline options xmon=ro and xmon=rw override this default.
> 
> The following xmon operations are affected:
> memops:
>   disable memmove
>   disable memset
>   disable memzcan
> memex:
>   no-op'd mwrite
> super_regs:
>   no-op'd write_spr
> bpt_cmds:
>   disable
> proc_call:
>   disable
> 
> Signed-off-by: Christopher M. Riedl 
> Reviewed-by: Oliver O'Halloran 
> Reviewed-by: Andrew Donnellan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/0acb5f64560a052fd66ab37b212a7296

cheers


Re: [PATCH][next] powerpc/mm: fix spelling mistake "Outisde" -> "Outside"

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-23 at 15:10:17 UTC, Colin King wrote:
> From: Colin Ian King 
> 
> There are several identical spelling mistakes in warning messages,
> fix these.
> 
> Signed-off-by: Colin Ian King 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/f341d89790b0b7f99ca7835e0cf7de10

cheers


Re: [PATCH] powerpc: vdso: drop unnecessary cc-ldoption

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-23 at 21:11:14 UTC, Nick Desaulniers wrote:
> Towards the goal of removing cc-ldoption, it seems that --hash-style=
> was added to binutils 2.17.50.0.2 in 2006. The minimal required version
> of binutils for the kernel according to
> Documentation/process/changes.rst is 2.20.
> 
> Link: https://gcc.gnu.org/ml/gcc/2007-01/msg01141.html
> Cc: clang-built-li...@googlegroups.com
> Suggested-by: Masahiro Yamada 
> Signed-off-by: Nick Desaulniers 
> Reviewed-by: Nicholas Piggin 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/33dda8c32714c1a8f318450af4d1f9f1

cheers


Re: [PATCH v2 01/11] powerpc/mm: fix erroneous duplicate slb_addr_limit init

2019-05-03 Thread Michael Ellerman
On Thu, 2019-04-25 at 14:29:27 UTC, Christophe Leroy wrote:
> Commit 67fda38f0d68 ("powerpc/mm: Move slb_addr_linit to
> early_init_mmu") moved slb_addr_limit init out of setup_arch().
> 
> Commit 701101865f5d ("powerpc/mm: Reduce memory usage for mm_context_t
> for radix") brought it back into setup_arch() by error.
> 
> This patch reverts that erroneous regress.
> 
> Fixes: 701101865f5d ("powerpc/mm: Reduce memory usage for mm_context_t for 
> radix")
> Signed-off-by: Christophe Leroy 
> Reviewed-by: Aneesh Kumar K.V 

Patches 1-10 applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/5ba666d56c4ff9b011c1b029dcc689cf

cheers


Re: [PATCH v2 01/15] powerpc/mm: drop __bad_pte()

2019-05-03 Thread Michael Ellerman
On Fri, 2019-04-26 at 15:57:59 UTC, Christophe Leroy wrote:
> This has never been called (since Kernel has been in git at least),
> drop it.
> 
> Reviewed-by: Aneesh Kumar K.V 
> Signed-off-by: Christophe Leroy 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/447def3b06adab60b999417b316bd235

cheers


Re: [PATCH v11 01/13] powerpc/32: Move early_init() in a separate file

2019-05-03 Thread Michael Ellerman
On Fri, 2019-04-26 at 16:23:25 UTC, Christophe Leroy wrote:
> In preparation of KASAN, move early_init() into a separate
> file in order to allow deactivation of KASAN for that function.
> 
> Signed-off-by: Christophe Leroy 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/d69ca6bab39e84a84781535b977c7e62

cheers


Re: [PATCH] powerpc: Fix kobject memleak

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-30 at 01:09:23 UTC, "Tobin C. Harding" wrote:
> Currently error return from kobject_init_and_add() is not followed by a
> call to kobject_put().  This means there is a memory leak.
> 
> Add call to kobject_put() in error path of kobject_init_and_add().
> 
> Signed-off-by: Tobin C. Harding 
> Reviewed-by: Greg Kroah-Hartman 
> Reviewed-by: Tyrel Datwyler 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/7e8039795a80bdf1418964b9cabef616

cheers


Re: [PATCH v4 1/5] powerpc/include: Add data structures and macros for IMC trace mode

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-16 at 09:48:27 UTC, Anju T Sudhakar wrote:
> Add the macros needed for IMC (In-Memory Collection Counters) trace-mode
> and data structure to hold the trace-imc record data.
> Also, add the new type "OPAL_IMC_COUNTERS_TRACE" in 'opal-api.h', since
> there is a new switch case added in the opal-calls for IMC.
> 
> Signed-off-by: Anju T Sudhakar 
> Reviewed-by: Madhavan Srinivasan 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/d1720adff3783a2ba7c128e304a385d1

cheers


Re: [PATCH v2 03/17] powerpc/book3e: drop mmu_get_tsize()

2019-05-03 Thread Michael Ellerman
On Fri, 2019-04-26 at 05:59:38 UTC, Christophe Leroy wrote:
> This function is not used anymore, drop it.
> 
> Fixes: b42279f0165c ("powerpc/mm/nohash: MM_SLICE is only used by book3s 64")
> Signed-off-by: Christophe Leroy 

Patches 3-17 applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a521c44c3ded9fe184c5de3eed3a442a

cheers


Re: [PATCH v3 1/3] powerpc/32s: drop Hash_end

2019-05-03 Thread Michael Ellerman
On Fri, 2019-04-26 at 16:36:36 UTC, Christophe Leroy wrote:
> Hash_end has never been used, drop it.
> 
> Signed-off-by: Christophe Leroy 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/57e0491b58fa2a217029b69651149900

cheers


Re: [PATCH v3 1/3] powernv/mce: reduce mce console logs to lesser lines.

2019-05-03 Thread Michael Ellerman
On Mon, 2019-04-29 at 18:15:48 UTC, Mahesh Salgaonkar wrote:
> Also add cpu number while displaying mce log. This will help cleaner logs
> when mce hits on multiple cpus simultaneously.
> 
> before the changes the mce o/p was:
> 
> [  127.223515] Severe Machine check interrupt [Recovered]
> [  127.223530]   NIP [dba80280]: 
> insert_slb_entry.constprop.0+0x278/0x2c0 [mcetest_slb]
> [  127.223539]   Initiator: CPU
> [  127.223544]   Error type: SLB [Multihit]
> [  127.223550] Effective address: dba80280
> 
> After this patch series changes the mce o/p will be:
> 
> [  471.959843] MCE: CPU80: machine check (Warning) Host SLB Multihit 
> [Recovered]
> [  471.959870] MCE: CPU80: NIP: [db550280] 
> insert_slb_entry.constprop.0+0x278/0x2c0 [mcetest_slb]
> [  471.959892] MCE: CPU80: Probable software error (some chance of hardware 
> cause)
> 
> UE in host application:
> 
> [ 1001.831517] MCE: CPU48: machine check (Severe) Host UE Load/Store DAR: 
> 7fffc6079a80 paddr: 000f8e26 [Not recovered]
> [ 1001.831518] MCE: CPU48: PID: 4584 Comm: find NIP: [10023368]
> [ 1001.831519] MCE: CPU48: Hardware error
> 
> and for MCE in Guest:
> 
> [ 1289.447571] MCE: CPU80: machine check (Warning) Guest SLB Multihit DAR: 
> 01001b6e0320 [Recovered]
> [ 1289.447615] MCE: CPU80: PID: 24765 Comm: qemu-system-ppc Guest NIP: 
> [7fffa309dc60]
> [ 1289.447634] MCE: CPU80: Probable software error (some chance of hardware 
> cause)
> 
> Signed-off-by: Mahesh Salgaonkar 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/d6e8a150850601277039a548ffc1

cheers


Re: [PATCH v3 01/16] powerpc/32: Refactor EXCEPTION entry macros for head_8xx.S and head_32.S

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-30 at 12:38:50 UTC, Christophe Leroy wrote:
> EXCEPTION_PROLOG is similar in head_8xx.S and head_32.S
> 
> This patch creates head_32.h and moves EXCEPTION_PROLOG macro
> into it. It also converts it from a GCC macro to a GAS macro
> in order to ease refactorisation with 40x later, since
> GAS macros allows the use of #ifdef/#else/#endif inside it.
> And it also has the advantage of not requiring the uggly "; \"
> at the end of each line.
> 
> This patch also moves EXCEPTION() and EXC_XFER_() macros which
> are also similar while adding START_EXCEPTION() out of EXCEPTION().
> 
> Signed-off-by: Christophe Leroy 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/8a23fdec3dbdc8bfde6f806d36e77323

cheers


Re: [PATCH] powerpc/64: Don't trace code that runs with the soft irq mask unreconciled

2019-05-03 Thread Michael Ellerman
On Thu, 2019-05-02 at 05:21:07 UTC, Nicholas Piggin wrote:
> "Reconciling" in terms of interrupt handling, is to bring the soft irq
> mask state in to synch with the hardware, after an interrupt causes
> MSR[EE] to be cleared (while the soft mask may be enabled, and hard
> irqs not marked disabled).
> 
> General kernel code should not be called while unreconciled, because
> local_irq_disable, etc. manipulations can cause surprising irq traces,
> and it's fragile because the soft irq code does not really expect to
> be called in this situation.
> 
> When exiting from an interrupt, MSR[EE] is cleared to prevent races,
> but soft irq state is enabled for the returned-to context, so this is
> now an unreconciled state. restore_math is called in this state, and
> that can be ftraced, and the ftrace subsystem disables local irqs.
> 
> Mark restore_math and its callees as notrace. Restore a sanity check
> in the soft irq code that had to be disabled for this case, by commit
> 4da1f79227ad4 ("powerpc/64: Disable irq restore warning for now").
> 
> Signed-off-by: Nicholas Piggin 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/e2b36d591720d81741f37e047a6f0047

cheers


Re: [PATCH] MAINTAINERS: Update cxl/ocxl email address

2019-05-03 Thread Michael Ellerman
On Thu, 2019-05-02 at 06:00:41 UTC, Andrew Donnellan wrote:
> Use my @linux.ibm.com email to avoid a layer of redirection.
> 
> Signed-off-by: Andrew Donnellan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/4c1bd90477c60618eb6dfba2e92d3a28

cheers


Re: [PATCH] powerpc/powernv/ioda2: Add __printf format/argument verification

2019-05-03 Thread Michael Ellerman
On Thu, 2017-03-30 at 10:19:25 UTC, Joe Perches wrote:
> Fix fallout too.
> 
> Signed-off-by: Joe Perches 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/1e496391a8452101308a23b7395cdd49

cheers


Re: [PATCH v2] powerpc: remove the __kernel_io_end export

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-30 at 18:27:39 UTC, Christoph Hellwig wrote:
> This export was added in this merge window, but without any actual
> user, or justification for a modular user.
> 
> Fixes: a35a3c6f6065 ("powerpc/mm/hash64: Add a variable to track the end of 
> IO mapping")
> Signed-off-by: Christoph Hellwig 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/c9e0fc33b8be52a7134ed0ee79b6a1e3

cheers


Re: [PATCH v2 1/2] powerpc/mm/ptdump: Wrap seq_printf() to handle NULL pointers

2019-05-03 Thread Michael Ellerman
On Thu, 2019-05-02 at 07:39:46 UTC, Russell Currey wrote:
> Lovingly borrowed from the arch/arm64 ptdump code.
> 
> This doesn't seem to be an issue in practice, but is necessary for my
> upcoming commit.
> 
> Signed-off-by: Russell Currey 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/5f18cbdbdd42b050c51eb9859f8ce43d

cheers


Re: [PATCH] powerpc/mm/radix: Fix kernel crash when running subpage protect test

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-30 at 07:59:07 UTC, "Aneesh Kumar K.V" wrote:
> This patch fixes the below crash by making sure we touch the subpage 
> protection
> related structures only if we know they are allocated on the platform. With
> radix translation we don't allocate hash context at all and trying to access
> subpage_prot_table results in
> 
>  Faulting instruction address: 0xc008bdb4
>  Oops: Kernel access of bad area, sig: 11 [#1]
>  LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>  
>  NIP [c008bdb4] sys_subpage_prot+0x74/0x590
>  LR [c000b688] system_call+0x5c/0x70
>  Call Trace:
>  [c00020002c6b7d30] [c00020002c6b7d90] 0xc00020002c6b7d90 (unreliable)
>  [c00020002c6b7e20] [c000b688] system_call+0x5c/0x70
>  Instruction dump:
>  fb61ffd8 fb81ffe0 fba1ffe8 fbc1fff0 fbe1fff8 f821ff11 e92d1178 f9210068
>  3920 e92d0968 ebe90630 e93f03e8  6000 3860fffe e9410068
> 
> We also move the subpage_prot_table with mmp_sem held to avoid racec
> between two parallel subpage_prot syscall.
> 
> Reported-by: Sachin Sant 
> Signed-off-by: Aneesh Kumar K.V 
> Tested-by: Sachin Sant  >

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/2c474c03505677cfd987d52e8bf42abe

cheers


Re: [PATCH v2] powerpc/pseries: Track LMB nid instead of using device tree

2019-05-03 Thread Michael Ellerman
On Tue, 2018-10-02 at 15:35:59 UTC, Nathan Fontenot wrote:
> When removing memory we need to remove the memory from the node
> it was added to instead of looking up the node it should be in
> in the device tree.
> 
> During testing we have seen scenarios where the affinity for a
> LMB changes due to a partition migration or PRRN event. In these
> cases the node the LMB exists in may not match the node the device
> tree indicates it belongs in. This can lead to a system crash
> when trying to DLPAR remove the LMB after a migration or PRRN
> event. The current code looks up the node in the device tree to
> remove the LMB from, the crash occurs when we try to offline this
> node and it does not have any data, i.e. node_data[nid] == NULL.
> 
> 36:mon> e
> cpu 0x36: Vector: 300 (Data Access) at [c001828b7810]
> pc: c036d08c: try_offline_node+0x2c/0x1b0
> lr: c03a14ec: remove_memory+0xbc/0x110
> sp: c001828b7a90
>msr: 8280b033
>dar: 9a28
>  dsisr: 4000
>   current = 0xc006329c4c80
>   paca= 0xc7a55200   softe: 0irq_happened: 0x01
> pid   = 76926, comm = kworker/u320:3
> 
> 36:mon> t
> [link register   ] c03a14ec remove_memory+0xbc/0x110
> [c001828b7a90] c006a1cc arch_remove_memory+0x9c/0xd0 (unreliable)
> [c001828b7ad0] c03a14e0 remove_memory+0xb0/0x110
> [c001828b7b20] c00c7db4 dlpar_remove_lmb+0x94/0x160
> [c001828b7b60] c00c8ef8 dlpar_memory+0x7e8/0xd10
> [c001828b7bf0] c00bf828 handle_dlpar_errorlog+0xf8/0x160
> [c001828b7c60] c00bf8cc pseries_hp_work_fn+0x3c/0xa0
> [c001828b7c90] c0128cd8 process_one_work+0x298/0x5a0
> [c001828b7d20] c0129068 worker_thread+0x88/0x620
> [c001828b7dc0] c013223c kthread+0x1ac/0x1c0
> [c001828b7e30] c000b45c ret_from_kernel_thread+0x5c/0x80
> 
> To resolve this we need to track the node a LMB belongs to when
> it is added to the system so we can remove it from that node instead
> of the node that the device tree indicates it should belong to.
> 
> Signed-off-by: Nathan Fontenot 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/b2d3b5ee66f2a04a918cc043cec0c9ed

cheers


Re: [PATCH] powerpc: Add doorbell tracepoints

2019-05-03 Thread Michael Ellerman
On Thu, 2018-10-04 at 06:23:37 UTC, Anton Blanchard wrote:
> When analysing sources of OS jitter, I noticed that doorbells cannot be
> traced.
> 
> Signed-off-by: Anton Blanchard 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/5b2a15296210d3b70e06d0f09a8e701f

cheers


Re: [PATCH] arch: fix without checked-return value with lseek

2019-05-03 Thread Michael Ellerman
On Tue, 2018-10-30 at 13:21:55 UTC, Bo YU wrote:
> lseek should have returned value but we miss it maybe.
> This is detected by Coverity scan:
> CID: 1440481
> 
> Signed-off-by: Bo YU 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/5d085ec04a000fefb5182d3b03ee46ca

cheers


Re: [PATCH v2] powerpc/32s: fix BATs setting with CONFIG_STRICT_KERNEL_RWX

2019-05-03 Thread Michael Ellerman
On Tue, 2019-04-30 at 16:11:59 UTC, Christophe Leroy wrote:
> Serge reported some crashes with CONFIG_STRICT_KERNEL_RWX enabled
> on a book3s32 machine.
> 
> Analysis shows two issues:
> - BATs addresses and sizes are not properly aligned.
> - There is a gap between the last address covered by BATs and the
> first address covered by pages.
> 
> Memory mapped with DBATs:
> 0: 0xc000-0xc07f 0x Kernel RO coherent
> 1: 0xc080-0xc0bf 0x0080 Kernel RO coherent
> 2: 0xc0c0-0xc13f 0x00c0 Kernel RW coherent
> 3: 0xc140-0xc23f 0x0140 Kernel RW coherent
> 4: 0xc240-0xc43f 0x0240 Kernel RW coherent
> 5: 0xc440-0xc83f 0x0440 Kernel RW coherent
> 6: 0xc840-0xd03f 0x0840 Kernel RW coherent
> 7: 0xd040-0xe03f 0x1040 Kernel RW coherent
> 
> Memory mapped with pages:
> 0xe100-0xefff  0x2100   240Mrw   present  
>  dirty  accessed
> 
> This patch fixes both issues. With the patch, we get the following
> which is as expected:
> 
> Memory mapped with DBATs:
> 0: 0xc000-0xc07f 0x Kernel RO coherent
> 1: 0xc080-0xc0bf 0x0080 Kernel RO coherent
> 2: 0xc0c0-0xc0ff 0x00c0 Kernel RW coherent
> 3: 0xc100-0xc1ff 0x0100 Kernel RW coherent
> 4: 0xc200-0xc3ff 0x0200 Kernel RW coherent
> 5: 0xc400-0xc7ff 0x0400 Kernel RW coherent
> 6: 0xc800-0xcfff 0x0800 Kernel RW coherent
> 7: 0xd000-0xdfff 0x1000 Kernel RW coherent
> 
> Memory mapped with pages:
> 0xe000-0xefff  0x2000   256Mrw   present  
>  dirty  accessed
> 
> Reported-by: Serge Belyshev 
> Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
> Cc: sta...@vger.kernel.org
> Acked-by: Segher Boessenkool 
> Signed-off-by: Christophe Leroy 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/12f363511d47f86c49b7766c349989cb

cheers


Re: [PATCH v11 09/13] powerpc: disable KASAN instrumentation on early/critical files.

2019-05-03 Thread Christophe Leroy




Le 26/04/2019 à 18:23, Christophe Leroy a écrit :

All files containing functions run before kasan_early_init() is called
must have KASAN instrumentation disabled.

For those file, branch profiling also have to be disabled otherwise
each if () generates a call to ftrace_likely_update().

Signed-off-by: Christophe Leroy 
---
  arch/powerpc/kernel/Makefile | 12 
  arch/powerpc/lib/Makefile|  8 
  arch/powerpc/mm/Makefile |  6 ++
  arch/powerpc/platforms/powermac/Makefile |  6 ++
  arch/powerpc/purgatory/Makefile  |  3 +++
  arch/powerpc/xmon/Makefile   |  1 +
  6 files changed, 36 insertions(+)



[...]


diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 3c1bd9fa23cd..dd945ca869b2 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -7,6 +7,12 @@ ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC)
  
  CFLAGS_REMOVE_slb.o = $(CC_FLAGS_FTRACE)
  
+KASAN_SANITIZE_ppc_mmu_32.o := n

+
+ifdef CONFIG_KASAN
+CFLAGS_ppc_mmu_32.o+= -DDISABLE_BRANCH_PROFILING
+endif
+


The above is missing in powerpc/next (should now be in 
arch/powerpc/mm/book3s32/Makefile )


Christophe


[PATCH] powerpc/powernv: Restrict OPAL symbol map to only be readable by root

2019-05-03 Thread Andrew Donnellan
Currently the OPAL symbol map is globally readable, which seems bad as it
contains physical addresses.

Restrict it to root.

Suggested-by: Michael Ellerman 
Cc: Jordan Niethe 
Cc: Stewart Smith 
Fixes: c8742f85125d ("powerpc/powernv: Expose OPAL firmware symbol map")
Cc: sta...@vger.kernel.org
Signed-off-by: Andrew Donnellan 
---
 arch/powerpc/platforms/powernv/opal.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 2b0eca104f86..505460a72052 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -681,7 +681,10 @@ static ssize_t symbol_map_read(struct file *fp, struct 
kobject *kobj,
   bin_attr->size);
 }
 
-static BIN_ATTR_RO(symbol_map, 0);
+static struct bin_attribute symbol_map_attr = {
+   .attr = {.name = "symbol_map", .mode = 0400},
+   .read = symbol_map_read
+};
 
 static void opal_export_symmap(void)
 {
@@ -698,10 +701,10 @@ static void opal_export_symmap(void)
return;
 
/* Setup attributes */
-   bin_attr_symbol_map.private = __va(be64_to_cpu(syms[0]));
-   bin_attr_symbol_map.size = be64_to_cpu(syms[1]);
+symbol_map_attr.private = __va(be64_to_cpu(syms[0]));
+   symbol_map_attr.size = be64_to_cpu(syms[1]);
 
-   rc = sysfs_create_bin_file(opal_kobj, &bin_attr_symbol_map);
+   rc = sysfs_create_bin_file(opal_kobj, &symbol_map_attr);
if (rc)
pr_warn("Error %d creating OPAL symbols file\n", rc);
 }
-- 
2.20.1



Re: [PATCH] powerpc/powernv: Restrict OPAL symbol map to only be readable by root

2019-05-03 Thread Greg KH
On Fri, May 03, 2019 at 05:44:05PM +1000, Andrew Donnellan wrote:
> Currently the OPAL symbol map is globally readable, which seems bad as it
> contains physical addresses.
> 
> Restrict it to root.
> 
> Suggested-by: Michael Ellerman 
> Cc: Jordan Niethe 
> Cc: Stewart Smith 
> Fixes: c8742f85125d ("powerpc/powernv: Expose OPAL firmware symbol map")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andrew Donnellan 
> ---
>  arch/powerpc/platforms/powernv/opal.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/opal.c 
> b/arch/powerpc/platforms/powernv/opal.c
> index 2b0eca104f86..505460a72052 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -681,7 +681,10 @@ static ssize_t symbol_map_read(struct file *fp, struct 
> kobject *kobj,
>  bin_attr->size);
>  }
>  
> -static BIN_ATTR_RO(symbol_map, 0);
> +static struct bin_attribute symbol_map_attr = {
> + .attr = {.name = "symbol_map", .mode = 0400},
> + .read = symbol_map_read
> +};
>  
>  static void opal_export_symmap(void)
>  {
> @@ -698,10 +701,10 @@ static void opal_export_symmap(void)
>   return;
>  
>   /* Setup attributes */
> - bin_attr_symbol_map.private = __va(be64_to_cpu(syms[0]));
> - bin_attr_symbol_map.size = be64_to_cpu(syms[1]);
> +symbol_map_attr.private = __va(be64_to_cpu(syms[0]));

no tab?

checkpatch.pl is your friend :)



[PATCH v2] powerpc/powernv: Restrict OPAL symbol map to only be readable by root

2019-05-03 Thread Andrew Donnellan
Currently the OPAL symbol map is globally readable, which seems bad as it
contains physical addresses.

Restrict it to root.

Suggested-by: Michael Ellerman 
Cc: Jordan Niethe 
Cc: Stewart Smith 
Fixes: c8742f85125d ("powerpc/powernv: Expose OPAL firmware symbol map")
Cc: sta...@vger.kernel.org
Signed-off-by: Andrew Donnellan 

---

v1->v2:

- fix tabs vs spaces (Greg)
---
 arch/powerpc/platforms/powernv/opal.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 2b0eca104f86..0582a02623d0 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -681,7 +681,10 @@ static ssize_t symbol_map_read(struct file *fp, struct 
kobject *kobj,
   bin_attr->size);
 }
 
-static BIN_ATTR_RO(symbol_map, 0);
+static struct bin_attribute symbol_map_attr = {
+   .attr = {.name = "symbol_map", .mode = 0400},
+   .read = symbol_map_read
+};
 
 static void opal_export_symmap(void)
 {
@@ -698,10 +701,10 @@ static void opal_export_symmap(void)
return;
 
/* Setup attributes */
-   bin_attr_symbol_map.private = __va(be64_to_cpu(syms[0]));
-   bin_attr_symbol_map.size = be64_to_cpu(syms[1]);
+   symbol_map_attr.private = __va(be64_to_cpu(syms[0]));
+   symbol_map_attr.size = be64_to_cpu(syms[1]);
 
-   rc = sysfs_create_bin_file(opal_kobj, &bin_attr_symbol_map);
+   rc = sysfs_create_bin_file(opal_kobj, &symbol_map_attr);
if (rc)
pr_warn("Error %d creating OPAL symbols file\n", rc);
 }
-- 
2.20.1



Re: [PATCH] powerpc/powernv: Restrict OPAL symbol map to only be readable by root

2019-05-03 Thread Andrew Donnellan

On 3/5/19 5:48 pm, Greg KH wrote:

no tab?

checkpatch.pl is your friend :)



Ughh.

Sadly our CI is currently down ;)

Respun.

--
Andrew Donnellan  OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited



[PATCH v3 05/10] net: ethernet: support of_get_mac_address new ERR_PTR error

2019-05-03 Thread Petr Štetiar
There was NVMEM support added to of_get_mac_address, so it could now
return NULL and ERR_PTR encoded error values, so we need to adjust all
current users of of_get_mac_address to this new fact.

While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is always valid and checked by
is_valid_ether_addr anyway.

Signed-off-by: Petr Štetiar 
---
 drivers/net/ethernet/aeroflex/greth.c | 2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c   | 2 +-
 drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
 drivers/net/ethernet/arc/emac_main.c  | 2 +-
 drivers/net/ethernet/aurora/nb8800.c  | 2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-bcma.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-platform.c| 2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c| 2 +-
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c  | 2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
 drivers/net/ethernet/davicom/dm9000.c | 2 +-
 drivers/net/ethernet/ethoc.c  | 2 +-
 drivers/net/ethernet/ezchip/nps_enet.c| 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 drivers/net/ethernet/freescale/fec_mpc52xx.c  | 2 +-
 drivers/net/ethernet/freescale/fman/mac.c | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c   | 2 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +-
 drivers/net/ethernet/lantiq_xrx200.c  | 2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
 drivers/net/ethernet/marvell/sky2.c   | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 2 +-
 drivers/net/ethernet/micrel/ks8851.c  | 2 +-
 drivers/net/ethernet/micrel/ks8851_mll.c  | 2 +-
 drivers/net/ethernet/microchip/enc28j60.c | 2 +-
 drivers/net/ethernet/nxp/lpc_eth.c| 2 +-
 drivers/net/ethernet/qualcomm/qca_spi.c   | 2 +-
 drivers/net/ethernet/qualcomm/qca_uart.c  | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c  | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c | 2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c   | 2 +-
 drivers/net/ethernet/socionext/sni_ave.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 drivers/net/ethernet/ti/cpsw.c| 2 +-
 drivers/net/ethernet/ti/netcp_core.c  | 2 +-
 drivers/net/ethernet/wiznet/w5100.c   | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c   | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
 net/ethernet/eth.c| 2 +-
 46 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/drivers/net/ethernet/aeroflex/greth.c 
b/drivers/net/ethernet/aeroflex/greth.c
index 47e5984..ce4d2a5 100644
--- a/drivers/net/ethernet/aeroflex/greth.c
+++ b/drivers/net/ethernet/aeroflex/greth.c
@@ -1459,7 +1459,7 @@ static int greth_of_probe(struct platform_device *ofdev)
const u8 *addr;
 
addr = of_get_mac_address(ofdev->dev.of_node);
-   if (addr) {
+   if (!IS_ERR_OR_NULL(addr)) {
for (i = 0; i < 6; i++)
macaddr[i] = (unsigned int) addr[i];
} else {
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c 
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index e1acafa..9708199 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -870,7 +870,7 @@ static int emac_probe(struct platform_device *pdev)
 
/* Read MAC-address from DT */
mac_addr = of_get_mac_address(np);
-   if (mac_addr)
+   if (!IS_ERR_OR_NULL(mac_addr))
memcpy(ndev->dev_addr, mac_addr, ETH_ALEN);
 
/* Check if the MAC address is valid, if not get a random one */
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c 
b/drivers/net/ethernet/altera/altera_tse_main.c
index aa1d1f5..99a5149 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -1537,7 +1537,7 @@ static int altera_tse_probe(struct platform_device *pdev)
 
/* get default MAC address from device tree */
macaddr = of_get_mac_address(pdev->dev.of_node);
-   if (macaddr)
+   if (!IS_ERR_OR_NULL(macaddr))
eth

[PATCH v3 10/10] powerpc: tsi108: support of_get_mac_address new ERR_PTR error

2019-05-03 Thread Petr Štetiar
There was NVMEM support added to of_get_mac_address, so it could now
return NULL and ERR_PTR encoded error values, so we need to adjust all
current users of of_get_mac_address to this new fact.

Signed-off-by: Petr Štetiar 
---
 arch/powerpc/sysdev/tsi108_dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/tsi108_dev.c b/arch/powerpc/sysdev/tsi108_dev.c
index 1f1af12..2e54405 100644
--- a/arch/powerpc/sysdev/tsi108_dev.c
+++ b/arch/powerpc/sysdev/tsi108_dev.c
@@ -105,7 +105,7 @@ static int __init tsi108_eth_of_init(void)
}
 
mac_addr = of_get_mac_address(np);
-   if (mac_addr)
+   if (!IS_ERR_OR_NULL(mac_addr))
memcpy(tsi_eth_data.mac_addr, mac_addr, 6);
 
ph = of_get_property(np, "mdio-handle", NULL);
-- 
1.9.1



Re: [PATCH v2] powerpc/powernv: Restrict OPAL symbol map to only be readable by root

2019-05-03 Thread Greg KH
On Fri, May 03, 2019 at 05:52:53PM +1000, Andrew Donnellan wrote:
> Currently the OPAL symbol map is globally readable, which seems bad as it
> contains physical addresses.
> 
> Restrict it to root.
> 
> Suggested-by: Michael Ellerman 
> Cc: Jordan Niethe 
> Cc: Stewart Smith 
> Fixes: c8742f85125d ("powerpc/powernv: Expose OPAL firmware symbol map")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andrew Donnellan 
> 
> ---
> 
> v1->v2:
> 
> - fix tabs vs spaces (Greg)
> ---
>  arch/powerpc/platforms/powernv/opal.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/opal.c 
> b/arch/powerpc/platforms/powernv/opal.c
> index 2b0eca104f86..0582a02623d0 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -681,7 +681,10 @@ static ssize_t symbol_map_read(struct file *fp, struct 
> kobject *kobj,
>  bin_attr->size);
>  }
>  
> -static BIN_ATTR_RO(symbol_map, 0);
> +static struct bin_attribute symbol_map_attr = {
> + .attr = {.name = "symbol_map", .mode = 0400},
> + .read = symbol_map_read
> +};

There's no real need to rename the structure, right?  Why not just keep
the bin_attr_symbol_map name?  That would make this patch even smaller.

>  static void opal_export_symmap(void)
>  {
> @@ -698,10 +701,10 @@ static void opal_export_symmap(void)
>   return;
>  
>   /* Setup attributes */
> - bin_attr_symbol_map.private = __va(be64_to_cpu(syms[0]));
> - bin_attr_symbol_map.size = be64_to_cpu(syms[1]);
> + symbol_map_attr.private = __va(be64_to_cpu(syms[0]));
> + symbol_map_attr.size = be64_to_cpu(syms[1]);
>  
> - rc = sysfs_create_bin_file(opal_kobj, &bin_attr_symbol_map);
> + rc = sysfs_create_bin_file(opal_kobj, &symbol_map_attr);

Meta-comment, odds are you are racing userspace when you create this
sysfs file, why not add it to the device's default attributes so the
driver core creates it for you at the correct time?

thanks,

greg k-h


Re: [PATCH] powerpc/powernv/ioda2: Add __printf format/argument verification

2019-05-03 Thread Joe Perches
On Fri, 2019-05-03 at 16:59 +1000, Michael Ellerman wrote:
> On Thu, 2017-03-30 at 10:19:25 UTC, Joe Perches wrote:
> > Fix fallout too.
> > 
> > Signed-off-by: Joe Perches 
> 
> Applied to powerpc next, thanks.
> 
> https://git.kernel.org/powerpc/c/1e496391a8452101308a23b7395cdd49

2+ years later.




Re: [PATCH v2] powerpc/powernv: Restrict OPAL symbol map to only be readable by root

2019-05-03 Thread Andrew Donnellan

On 3/5/19 5:59 pm, Greg KH wrote:>> -static BIN_ATTR_RO(symbol_map, 0);

+static struct bin_attribute symbol_map_attr = {
+   .attr = {.name = "symbol_map", .mode = 0400},
+   .read = symbol_map_read
+};


There's no real need to rename the structure, right?  Why not just keep
the bin_attr_symbol_map name?  That would make this patch even smaller.


No real need but it's locally more consistent with the rest of the PPC 
code. (Though perhaps the other cases should use the BIN_ATTR macro...)


Given this is for stable I'm happy to change that if the smaller patch 
is more acceptable.





  static void opal_export_symmap(void)
  {
@@ -698,10 +701,10 @@ static void opal_export_symmap(void)
return;
  
  	/* Setup attributes */

-   bin_attr_symbol_map.private = __va(be64_to_cpu(syms[0]));
-   bin_attr_symbol_map.size = be64_to_cpu(syms[1]);
+   symbol_map_attr.private = __va(be64_to_cpu(syms[0]));
+   symbol_map_attr.size = be64_to_cpu(syms[1]);
  
-	rc = sysfs_create_bin_file(opal_kobj, &bin_attr_symbol_map);

+   rc = sysfs_create_bin_file(opal_kobj, &symbol_map_attr);


Meta-comment, odds are you are racing userspace when you create this
sysfs file, why not add it to the device's default attributes so the
driver core creates it for you at the correct time?


I was not previously aware of default attributes...

Are we actually racing against userspace in a subsys initcall?

--
Andrew Donnellan  OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited



Re: [PATCH] powerpc/powernv/ioda2: Add __printf format/argument verification

2019-05-03 Thread Mathieu Malaterre
On Fri, May 3, 2019 at 10:21 AM Joe Perches  wrote:
>
> On Fri, 2019-05-03 at 16:59 +1000, Michael Ellerman wrote:
> > On Thu, 2017-03-30 at 10:19:25 UTC, Joe Perches wrote:
> > > Fix fallout too.
> > >
> > > Signed-off-by: Joe Perches 
> >
> > Applied to powerpc next, thanks.
> >
> > https://git.kernel.org/powerpc/c/1e496391a8452101308a23b7395cdd49
>
> 2+ years later.
>
>

Can't wait until someone compute stats about largest delta (author
date / committer date)

;)


Re: [PATCH v2] powerpc/powernv: Restrict OPAL symbol map to only be readable by root

2019-05-03 Thread Greg KH
On Fri, May 03, 2019 at 06:27:18PM +1000, Andrew Donnellan wrote:
> On 3/5/19 5:59 pm, Greg KH wrote:>> -static BIN_ATTR_RO(symbol_map, 0);
> > > +static struct bin_attribute symbol_map_attr = {
> > > + .attr = {.name = "symbol_map", .mode = 0400},
> > > + .read = symbol_map_read
> > > +};
> > 
> > There's no real need to rename the structure, right?  Why not just keep
> > the bin_attr_symbol_map name?  That would make this patch even smaller.
> 
> No real need but it's locally more consistent with the rest of the PPC code.
> (Though perhaps the other cases should use the BIN_ATTR macro...)
> 
> Given this is for stable I'm happy to change that if the smaller patch is
> more acceptable.

stable doesn't care, and if this is more consistent, that's fine with
me, I didn't see the larger picture here, just providing unsolicited
patch review :)

> > >   static void opal_export_symmap(void)
> > >   {
> > > @@ -698,10 +701,10 @@ static void opal_export_symmap(void)
> > >   return;
> > >   /* Setup attributes */
> > > - bin_attr_symbol_map.private = __va(be64_to_cpu(syms[0]));
> > > - bin_attr_symbol_map.size = be64_to_cpu(syms[1]);
> > > + symbol_map_attr.private = __va(be64_to_cpu(syms[0]));
> > > + symbol_map_attr.size = be64_to_cpu(syms[1]);
> > > - rc = sysfs_create_bin_file(opal_kobj, &bin_attr_symbol_map);
> > > + rc = sysfs_create_bin_file(opal_kobj, &symbol_map_attr);
> > 
> > Meta-comment, odds are you are racing userspace when you create this
> > sysfs file, why not add it to the device's default attributes so the
> > driver core creates it for you at the correct time?
> 
> I was not previously aware of default attributes...
> 
> Are we actually racing against userspace in a subsys initcall?

You can be, if you subsys is a module :)

thanks,

greg k-h


Re: [PATCH v2] powerpc/powernv: Restrict OPAL symbol map to only be readable by root

2019-05-03 Thread Andrew Donnellan

On 3/5/19 6:35 pm, Greg KH wrote:

Are we actually racing against userspace in a subsys initcall?


You can be, if you subsys is a module :)


For various reasons, we don't compile core system firmware interfaces 
into modules... that could be an interesting exercise. :D


--
Andrew Donnellan  OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited



Re: [PATCH 04/15] arm64: switch to generic version of pte allocation

2019-05-03 Thread Mark Rutland
Hi,

On Thu, May 02, 2019 at 06:28:31PM +0300, Mike Rapoport wrote:
> The PTE allocations in arm64 are identical to the generic ones modulo the
> GFP flags.
> 
> Using the generic pte_alloc_one() functions ensures that the user page
> tables are allocated with __GFP_ACCOUNT set.
> 
> The arm64 definition of PGALLOC_GFP is removed and replaced with
> GFP_PGTABLE_USER for p[gum]d_alloc_one() and for KVM memory cache.
> 
> The mappings created with create_pgd_mapping() are now using
> GFP_PGTABLE_KERNEL.
> 
> The conversion to the generic version of pte_free_kernel() removes the NULL
> check for pte.
> 
> The pte_free() version on arm64 is identical to the generic one and
> can be simply dropped.
> 
> Signed-off-by: Mike Rapoport 
> ---
>  arch/arm64/include/asm/pgalloc.h | 43 
> 
>  arch/arm64/mm/mmu.c  |  2 +-
>  arch/arm64/mm/pgd.c  |  4 ++--
>  virt/kvm/arm/mmu.c   |  2 +-
>  4 files changed, 8 insertions(+), 43 deletions(-)

[...]

> diff --git a/arch/arm64/mm/pgd.c b/arch/arm64/mm/pgd.c
> index 289f911..2ef1a53 100644
> --- a/arch/arm64/mm/pgd.c
> +++ b/arch/arm64/mm/pgd.c
> @@ -31,9 +31,9 @@ static struct kmem_cache *pgd_cache __ro_after_init;
>  pgd_t *pgd_alloc(struct mm_struct *mm)
>  {
>   if (PGD_SIZE == PAGE_SIZE)
> - return (pgd_t *)__get_free_page(PGALLOC_GFP);
> + return (pgd_t *)__get_free_page(GFP_PGTABLE_USER);
>   else
> - return kmem_cache_alloc(pgd_cache, PGALLOC_GFP);
> + return kmem_cache_alloc(pgd_cache, GFP_PGTABLE_USER);
>  }

In efi_virtmap_init() we use pgd_alloc() to allocate a pgd for EFI
runtime services, which we map with a special kernel page table.

I'm not sure if accounting that is problematic, as it's allocated in a
kernel thread off the back of an early_initcall.

Just to check, Is that sound, or do we need a pgd_alloc_kernel()?

Thanks,
Mark.


Re: [RESEND PATCH v3 05/11] mtd: rawnand: vf610_nfc: add initializer to avoid -Wmaybe-uninitialized

2019-05-03 Thread Masahiro Yamada
Hi Miquel,

On Thu, May 2, 2019 at 11:14 PM Miquel Raynal  wrote:
>
> Hi Masahiro,
>
> Masahiro Yamada  wrote on Tue, 23 Apr
> 2019 12:49:53 +0900:
>
> > This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
> > place. We need to eliminate potential issues beforehand.
> >
> > Kbuild test robot has never reported -Wmaybe-uninitialized warning
> > for this probably because vf610_nfc_run() is inlined by the x86
> > compiler's inlining heuristic.
> >
> > If CONFIG_OPTIMIZE_INLINING is enabled for a different architecture
> > and vf610_nfc_run() is not inlined, the following warning is reported:
> >
> > drivers/mtd/nand/raw/vf610_nfc.c: In function ‘vf610_nfc_cmd’:
> > drivers/mtd/nand/raw/vf610_nfc.c:455:3: warning: ‘offset’ may be used 
> > uninitialized in this function [-Wmaybe-uninitialized]
> >vf610_nfc_rd_from_sram(instr->ctx.data.buf.in + offset,
> >^~~
> > nfc->regs + NFC_MAIN_AREA(0) + offset,
> > ~~
> > trfr_sz, !nfc->data_access);
> > ~~~
>
> IMHO this patch has no dependencies with this series.


This patch is the prerequisite for 11/11.
https://lore.kernel.org/patchwork/patch/1064959/


Without the correct patch order,
the kbuild test robot reports the warning.


> Would you mind sending it alone with the proper Fixes tag?


I do not think Fixes is necessary.

Nobody has noticed this potential issue before.
Without 11/11, probably we cannot reproduce this warning.


BTW, this series has been for a while in linux-next.


>
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> > Changes in v3: None
> > Changes in v2:
> >   - split into a separate patch
> >
> >  drivers/mtd/nand/raw/vf610_nfc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/nand/raw/vf610_nfc.c 
> > b/drivers/mtd/nand/raw/vf610_nfc.c
> > index a662ca1970e5..19792d725ec2 100644
> > --- a/drivers/mtd/nand/raw/vf610_nfc.c
> > +++ b/drivers/mtd/nand/raw/vf610_nfc.c
> > @@ -364,7 +364,7 @@ static int vf610_nfc_cmd(struct nand_chip *chip,
> >  {
> >   const struct nand_op_instr *instr;
> >   struct vf610_nfc *nfc = chip_to_nfc(chip);
> > - int op_id = -1, trfr_sz = 0, offset;
> > + int op_id = -1, trfr_sz = 0, offset = 0;
> >   u32 col = 0, row = 0, cmd1 = 0, cmd2 = 0, code = 0;
> >   bool force8bit = false;
> >
>
> Thanks,
> Miquèl
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



--
Best Regards

Masahiro Yamada


Re: [RESEND PATCH v3 05/11] mtd: rawnand: vf610_nfc: add initializer to avoid -Wmaybe-uninitialized

2019-05-03 Thread Miquel Raynal
Hi Masahiro,

Masahiro Yamada  wrote on Fri, 3 May
2019 19:36:35 +0900:

> Hi Miquel,
> 
> On Thu, May 2, 2019 at 11:14 PM Miquel Raynal  
> wrote:
> >
> > Hi Masahiro,
> >
> > Masahiro Yamada  wrote on Tue, 23 Apr
> > 2019 12:49:53 +0900:
> >  
> > > This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
> > > place. We need to eliminate potential issues beforehand.
> > >
> > > Kbuild test robot has never reported -Wmaybe-uninitialized warning
> > > for this probably because vf610_nfc_run() is inlined by the x86
> > > compiler's inlining heuristic.
> > >
> > > If CONFIG_OPTIMIZE_INLINING is enabled for a different architecture
> > > and vf610_nfc_run() is not inlined, the following warning is reported:
> > >
> > > drivers/mtd/nand/raw/vf610_nfc.c: In function ‘vf610_nfc_cmd’:
> > > drivers/mtd/nand/raw/vf610_nfc.c:455:3: warning: ‘offset’ may be used 
> > > uninitialized in this function [-Wmaybe-uninitialized]
> > >vf610_nfc_rd_from_sram(instr->ctx.data.buf.in + offset,
> > >^~~
> > > nfc->regs + NFC_MAIN_AREA(0) + offset,
> > > ~~
> > > trfr_sz, !nfc->data_access);
> > > ~~~  
> >
> > IMHO this patch has no dependencies with this series.  
> 
> 
> This patch is the prerequisite for 11/11.
> https://lore.kernel.org/patchwork/patch/1064959/
> 
> 
> Without the correct patch order,
> the kbuild test robot reports the warning.
> 
> 
> > Would you mind sending it alone with the proper Fixes tag?  
> 
> 
> I do not think Fixes is necessary.

IMHO it is. Even if today the warning does not spawn, there is a
real C error which might already be an issue.

> 
> Nobody has noticed this potential issue before.
> Without 11/11, probably we cannot reproduce this warning.
> 
> 
> BTW, this series has been for a while in linux-next.

Missed that. Ok, nevermind.


Thanks,
Miquèl


Re: [PATCH] Documentation: Add ARM64 to kernel-parameters.rst

2019-05-03 Thread Will Deacon
On Fri, May 03, 2019 at 06:37:56AM -0600, Jonathan Corbet wrote:
> On Fri, 12 Apr 2019 22:56:21 -0500
> Josh Poimboeuf  wrote:
> 
> > Add ARM64 to the legend of architectures.  It's already used in several
> > places in kernel-parameters.txt.
> > 
> > Suggested-by: Randy Dunlap 
> > Signed-off-by: Josh Poimboeuf 
> 
> It looks like nobody has picked this up...so I've applied it.

It's queued and tagged in the arm64 tree, which should also be in next!

Will


Re: [PATCH] Documentation: Add ARM64 to kernel-parameters.rst

2019-05-03 Thread Jonathan Corbet
On Fri, 12 Apr 2019 22:56:21 -0500
Josh Poimboeuf  wrote:

> Add ARM64 to the legend of architectures.  It's already used in several
> places in kernel-parameters.txt.
> 
> Suggested-by: Randy Dunlap 
> Signed-off-by: Josh Poimboeuf 

It looks like nobody has picked this up...so I've applied it.

Thanks,

jon


Re: [PATCH] Documentation: Add ARM64 to kernel-parameters.rst

2019-05-03 Thread Jonathan Corbet
On Fri, 3 May 2019 13:39:40 +0100
Will Deacon  wrote:

> > It looks like nobody has picked this up...so I've applied it.  
> 
> It's queued and tagged in the arm64 tree, which should also be in next!

Just looked again, I still don't see it there.  Josh's mitigations= change
is there, but not this one.  In any case, I've unapplied it, so it's all
yours.

Thanks,

jon


Re: [PATCH] Documentation: Add ARM64 to kernel-parameters.rst

2019-05-03 Thread Will Deacon
On Fri, May 03, 2019 at 06:47:19AM -0600, Jonathan Corbet wrote:
> On Fri, 3 May 2019 13:39:40 +0100
> Will Deacon  wrote:
> 
> > > It looks like nobody has picked this up...so I've applied it.  
> > 
> > It's queued and tagged in the arm64 tree, which should also be in next!
> 
> Just looked again, I still don't see it there.  Josh's mitigations= change
> is there, but not this one.  In any case, I've unapplied it, so it's all
> yours.

Weird... I see it in -next as 4ad499c94264:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4ad499c94264a2ee05aacc518b9bde658318e510

Will


[PATCH v3] dpaa_eth: fix SG frame cleanup

2019-05-03 Thread laurentiu . tudor
From: Laurentiu Tudor 

Fix issue with the entry indexing in the sg frame cleanup code being
off-by-1. This problem showed up when doing some basic iperf tests and
manifested in traffic coming to a halt.

Signed-off-by: Laurentiu Tudor 
Acked-by: Madalin Bucur 
Cc: 
---
v3:
 - added cc:stable tag (Joakim)
 - pulled from the original patch series and send individually

 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c 
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index daede7272768..40420edc9ce6 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1663,7 +1663,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct 
dpaa_priv *priv,
 qm_sg_entry_get_len(&sgt[0]), dma_dir);
 
/* remaining pages were mapped with skb_frag_dma_map() */
-   for (i = 1; i < nr_frags; i++) {
+   for (i = 1; i <= nr_frags; i++) {
WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
 
dma_unmap_page(dev, qm_sg_addr(&sgt[i]),
-- 
2.17.1



[PATCH] soc: fsl: qe: gpio: Fix an error code in qe_pin_request()

2019-05-03 Thread Dan Carpenter
There was a missing error code in this path.  It meant that we returned
ERR_PTR(0) which is NULL and would result in a NULL dereference in the
caller.

Fixes: 1a2d397a6eb5 ("gpio/powerpc: Eliminate duplication of 
of_get_named_gpio_flags()")
Signed-off-by: Dan Carpenter 
---
 drivers/soc/fsl/qe/gpio.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
index 819bed0f5667..51b3a47b5a55 100644
--- a/drivers/soc/fsl/qe/gpio.c
+++ b/drivers/soc/fsl/qe/gpio.c
@@ -179,8 +179,10 @@ struct qe_pin *qe_pin_request(struct device_node *np, int 
index)
if (err < 0)
goto err0;
gc = gpio_to_chip(err);
-   if (WARN_ON(!gc))
+   if (WARN_ON(!gc)) {
+   err = -ENODEV;
goto err0;
+   }
 
if (!of_device_is_compatible(gc->of_node, "fsl,mpc8323-qe-pario-bank")) 
{
pr_debug("%s: tried to get a non-qe pin\n", __func__);
-- 
2.18.0



Re: [PATCH 5/5] asm-generic: remove ptrace.h

2019-05-03 Thread Arnd Bergmann
On Wed, May 1, 2019 at 1:40 PM Christoph Hellwig  wrote:
>
> No one is using this helper anymore.
>
> Signed-off-by: Christoph Hellwig 

Acked-by: Arnd Bergmann 


Re: [PATCH] powerpc/powernv/ioda2: Add __printf format/argument verification

2019-05-03 Thread Michael Ellerman
Joe Perches  writes:
> On Fri, 2019-05-03 at 16:59 +1000, Michael Ellerman wrote:
>> On Thu, 2017-03-30 at 10:19:25 UTC, Joe Perches wrote:
>> > Fix fallout too.
>> > 
>> > Signed-off-by: Joe Perches 
>> 
>> Applied to powerpc next, thanks.
>> 
>> https://git.kernel.org/powerpc/c/1e496391a8452101308a23b7395cdd49
>
> 2+ years later.

I was hoping for a new record.

cheers


[PATCH] net: ucc_geth - fix Oops when changing number of buffers in the ring

2019-05-03 Thread Christophe Leroy
When changing the number of buffers in the RX ring while the interface
is running, the following Oops is encountered due to the new number
of buffers being taken into account immediately while their allocation
is done when opening the device only.

[   69.882706] Unable to handle kernel paging request for data at address 
0xf100
[   69.890172] Faulting instruction address: 0xc033e164
[   69.895122] Oops: Kernel access of bad area, sig: 11 [#1]
[   69.900494] BE PREEMPT CMPCPRO
[   69.907120] CPU: 0 PID: 0 Comm: swapper Not tainted 
4.14.115-6-g179ade8ce3-dirty #269
[   69.915956] task: c0684310 task.stack: c06da000
[   69.920470] NIP:  c033e164 LR: c02e44d0 CTR: c02e41fc
[   69.925504] REGS: dfff1e20 TRAP: 0300   Not tainted  
(4.14.115-6-g179ade8ce3-dirty)
[   69.934161] MSR:  9032   CR: 22004428  XER: 2000
[   69.940869] DAR: f100 DSISR: 2000
[   69.940869] GPR00: c0352d70 dfff1ed0 c0684310 f0a4 0040 dfff1f68 
 001f
[   69.940869] GPR08: df53f410 1cc00040 0021 c0781640 42004424 100c82b6 
f0a4 df53f5b0
[   69.940869] GPR16: df53f6c0 c05daf84 0040  0040 c0782be4 
 0001
[   69.940869] GPR24:  df53f400 01b0 df53f410 df53f000 003f 
df708220 1cc00044
[   69.978348] NIP [c033e164] skb_put+0x0/0x5c
[   69.982528] LR [c02e44d0] ucc_geth_poll+0x2d4/0x3f8
[   69.987384] Call Trace:
[   69.989830] [dfff1ed0] [c02e4554] ucc_geth_poll+0x358/0x3f8 (unreliable)
[   69.996522] [dfff1f20] [c0352d70] net_rx_action+0x248/0x30c
[   70.002099] [dfff1f80] [c04e93e4] __do_softirq+0xfc/0x310
[   70.007492] [dfff1fe0] [c0021124] irq_exit+0xd0/0xd4
[   70.012458] [dfff1ff0] [c000e7e0] call_do_irq+0x24/0x3c
[   70.017683] [c06dbe80] [c0006bac] do_IRQ+0x64/0xc4
[   70.022474] [c06dbea0] [c001097c] ret_from_except+0x0/0x14
[   70.027964] --- interrupt: 501 at rcu_idle_exit+0x84/0x90
[   70.027964] LR = rcu_idle_exit+0x74/0x90
[   70.037585] [c06dbf60] [2000] 0x2000 (unreliable)
[   70.042984] [c06dbf80] [c004bb0c] do_idle+0xb4/0x11c
[   70.047945] [c06dbfa0] [c004bd14] cpu_startup_entry+0x18/0x1c
[   70.053682] [c06dbfb0] [c05fb034] start_kernel+0x370/0x384
[   70.059153] [c06dbff0] [3438] 0x3438
[   70.063062] Instruction dump:
[   70.066023] 38a0 3880 90010014 4bfff015 80010014 7c0803a6 3123 
7c691910
[   70.073767] 38210010 4e800020 3860 4e800020 <80e3005c> 80c30098 3107 
7d083910
[   70.081690] ---[ end trace be7ccd9c1e1a9f12 ]---

This patch forbids the modification of the number of buffers in the
ring while the interface is running.

Fixes: ac421852b3a0 ("ucc_geth: add ethtool support")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy 
---
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/freescale/ucc_geth_ethtool.c 
b/drivers/net/ethernet/freescale/ucc_geth_ethtool.c
index 0beee2cc2ddd..722b6de24816 100644
--- a/drivers/net/ethernet/freescale/ucc_geth_ethtool.c
+++ b/drivers/net/ethernet/freescale/ucc_geth_ethtool.c
@@ -252,14 +252,12 @@ uec_set_ringparam(struct net_device *netdev,
return -EINVAL;
}
 
+   if (netif_running(netdev))
+   return -EBUSY;
+
ug_info->bdRingLenRx[queue] = ring->rx_pending;
ug_info->bdRingLenTx[queue] = ring->tx_pending;
 
-   if (netif_running(netdev)) {
-   /* FIXME: restart automatically */
-   netdev_info(netdev, "Please re-open the interface\n");
-   }
-
return ret;
 }
 
-- 
2.13.3



Re: Linux 5.1-rc5

2019-05-03 Thread Michael Ellerman
Greg KH  writes:
> On Mon, Apr 15, 2019 at 09:17:10AM -0700, Linus Torvalds wrote:
>> On Sun, Apr 14, 2019 at 10:19 PM Christoph Hellwig  
>> wrote:
>> >
>> > Can we please have the page refcount overflow fixes out on the list
>> > for review, even if it is after the fact?
>> 
>> They were actually on a list for review long before the fact, but it
>> was the security mailing list. The issue actually got discussed back
>> in January along with early versions of the patches, but then we
>> dropped the ball because it just wasn't on anybody's radar and it got
>> resurrected late March. Willy wrote a rather bigger patch-series, and
>> review of that is what then resulted in those commits. So they may
>> look recent, but that's just because the original patches got
>> seriously edited down and rewritten.
>> 
>> That said, powerpc and s390 should at least look at maybe adding a
>> check for the page ref in their gup paths too. Powerpc has the special
>> gup_hugepte() case, and s390 has its own version of gup entirely. I
>> was actually hoping the s390 guys would look at using the generic gup
>> code.
>> 
>> I ruthlessly also entirely ignored MIPS, SH and sparc, since they seem
>> largely irrelevant, partly since even theoretically this whole issue
>> needs a _lot_ of memory.
>> 
>> Michael, Martin, see commit 6b3a70773630 ("Merge branch 'page-refs'
>> (page ref overflow)"). You may or may not really care.
>
> I've now queued these patches up for the next round of stable releases,
> as some people seem to care about these.
>
> I didn't see any follow-on patches for s390 or ppc64 hit the tree for
> these changes, am I just missing them and should also queue up a few
> more to handle this issue on those platforms?

No you haven't missed them for powerpc. It's on my list.

cheers


Re: [RESEND PATCH v3 09/11] powerpc/mm/radix: mark __radix__flush_tlb_range_psize() as __always_inline

2019-05-03 Thread Masahiro Yamada
Hi Christophe,


On Tue, Apr 30, 2019 at 12:36 AM Christophe Leroy
 wrote:
>
>
>
> Le 23/04/2019 à 05:49, Masahiro Yamada a écrit :
> > This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
> > place. We need to eliminate potential issues beforehand.
>
> How did you identify the functions requiring __always_inline as this one
> ? Just by 'test and see if it fails',

Yes.

Based on my local build tests + 0day bot reports +
Arnd's randconfig + your reports.



> or did you have some script or so ?
>
> Here the problem is that one of the parameters of the function are used
> as "immediate" constraint for the inline assembly, therefore requiring
> the function to always be inline.
>
> I guess this should be explained in the commit log and I'm wondering how
> you ensure that you did identify all functions like this.


I think it is difficult to check all function call graphs, but
I just roughly checked though the "i" constraints,
and at least the following should be fixed.

This series has been a while in linux-next already,
so I want to let it go in
and I want to send the following fix-ups to each arch later
since they are currently not real problems.




diff --git a/arch/mips/include/asm/ginvt.h b/arch/mips/include/asm/ginvt.h
index 49c6dbe..6eb7c2b 100644
--- a/arch/mips/include/asm/ginvt.h
+++ b/arch/mips/include/asm/ginvt.h
@@ -19,7 +19,7 @@ _ASM_MACRO_1R1I(ginvt, rs, type,
 # define _ASM_SET_GINV
 #endif

-static inline void ginvt(unsigned long addr, enum ginvt_type type)
+static __always_inline void ginvt(unsigned long addr, enum ginvt_type type)
 {
  asm volatile(
  ".set push\n"
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index aaa28fd..bc2c35c 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -60,9 +60,11 @@ static inline void tlbiel_hash_set_isa206(unsigned
int set, unsigned int is)
  * tlbiel instruction for hash, set invalidation
  * i.e., r=1 and is=01 or is=10 or is=11
  */
-static inline void tlbiel_hash_set_isa300(unsigned int set, unsigned int is,
- unsigned int pid,
- unsigned int ric, unsigned int prs)
+static __always_inline void tlbiel_hash_set_isa300(unsigned int set,
+unsigned int is,
+unsigned int pid,
+unsigned int ric,
+unsigned int prs)
 {
  unsigned long rb;
  unsigned long rs;
diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
index 14ff414..c84d1a4 100644
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@ -29,9 +29,11 @@
  * tlbiel instruction for radix, set invalidation
  * i.e., r=1 and is=01 or is=10 or is=11
  */
-static inline void tlbiel_radix_set_isa300(unsigned int set, unsigned int is,
- unsigned int pid,
- unsigned int ric, unsigned int prs)
+static __always_inline void tlbiel_radix_set_isa300(unsigned int set,
+ unsigned int is,
+ unsigned int pid,
+ unsigned int ric,
+ unsigned int prs)
 {
  unsigned long rb;
  unsigned long rs;
@@ -120,8 +122,8 @@ static __always_inline void __tlbie_pid(unsigned
long pid, unsigned long ric)
  trace_tlbie(0, 0, rb, rs, ric, prs, r);
 }

-static inline void __tlbiel_lpid(unsigned long lpid, int set,
- unsigned long ric)
+static __always_inline void __tlbiel_lpid(unsigned long lpid, int set,
+   unsigned long ric)
 {
  unsigned long rb,rs,prs,r;

@@ -150,8 +152,8 @@ static __always_inline void __tlbie_lpid(unsigned
long lpid, unsigned long ric)
  trace_tlbie(lpid, 0, rb, rs, ric, prs, r);
 }

-static inline void __tlbiel_lpid_guest(unsigned long lpid, int set,
- unsigned long ric)
+static __always_inline void __tlbiel_lpid_guest(unsigned long lpid, int set,
+ unsigned long ric)
 {
  unsigned long rb,rs,prs,r;

@@ -167,8 +169,8 @@ static inline void __tlbiel_lpid_guest(unsigned
long lpid, int set,
 }


-static inline void __tlbiel_va(unsigned long va, unsigned long pid,
-unsigned long ap, unsigned long ric)
+static __always_inline void __tlbiel_va(unsigned long va, unsigned long pid,
+ unsigned long ap, unsigned long ric)
 {
  unsigned long rb,rs,prs,r;

@@ -183,8 +185,8 @@ static inline void __tlbiel_va(unsigned long va,
unsigned long pid,
  trace_tlbie(0, 1, rb, rs, ric, prs, r);
 }

-static inline void __tlbie_va(unsigned long va, unsigned long pid,
-   unsigned long ap, unsigned long ric)
+static __always_inline void __tlbie_va(unsigned long va, unsigned long pid,
+unsigned long ap, unsigned long ric)
 {
  unsigned long rb,rs,prs,r;

@@ -199,8 +201,9 @@ static inline void __tlbie_va(unsigned long va,
unsigned long pid,
  trace_tlbie(0, 0, rb, rs, ric, prs, r);
 }

-static inline void __tlbie_lpid_va(unsigned long va, unsigned long lpid,
-   unsigned long ap, unsigned long ric)
+static __always_inline void __tlbie_lpid_va(unsigned long va,
+ unsigned long lpid,
+ unsigned long ap, unsigned long ric)
 {
  unsigned long rb,rs,prs,r;

diff --git a/arch/s390/include/asm/atomic_ops.h
b/arch/s390/include/asm/atomic_ops.h
index d3f0952..b5d86e9 100644

Re: [PATCH] powerpc/32: Remove memory clobber asm constraint on dcbX() functions

2019-05-03 Thread Christophe Leroy

Segher,

A while ago I proposed the following patch, and didn't get any comment 
back on it.


Do you have any opinion on it ? Is it good and worth it ?

Thanks
Christophe

Le 09/01/2018 à 07:57, Christophe Leroy a écrit :

Instead of just telling GCC that dcbz(), dcbi(), dcbf() and dcbst()
clobber memory, tell it what it clobbers:
* dcbz(), dcbi() and dcbf() clobbers one cacheline as output
* dcbf() and dcbst() clobbers one cacheline as input

Signed-off-by: Christophe Leroy 
---
  arch/powerpc/include/asm/cache.h | 17 +
  1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index c1d257aa4c2d..fc8fe18acf8c 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -82,22 +82,31 @@ extern void _set_L3CR(unsigned long);
  
  static inline void dcbz(void *addr)

  {
-   __asm__ __volatile__ ("dcbz 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbz 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr) :);
  }
  
  static inline void dcbi(void *addr)

  {
-   __asm__ __volatile__ ("dcbi 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbi 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr) :);
  }
  
  static inline void dcbf(void *addr)

  {
-   __asm__ __volatile__ ("dcbf 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbf 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr), "m"(*(char (*)[L1_CACHE_BYTES])addr) :
+);
  }
  
  static inline void dcbst(void *addr)

  {
-   __asm__ __volatile__ ("dcbst 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbst 0, %0" : :
+ "r"(addr), "m"(*(char (*)[L1_CACHE_BYTES])addr) :
+);
  }
  #endif /* !__ASSEMBLY__ */
  #endif /* __KERNEL__ */



Re: [PATCH] powerpc/32: Remove memory clobber asm constraint on dcbX() functions

2019-05-03 Thread Christophe Leroy

Segher,

A while ago I proposed the following patch, and didn't get any comment 
back on it.


Do you have any opinion on it ? Is it good and worth it ?

Thanks
Christophe

Le 09/01/2018 à 07:57, Christophe Leroy a écrit :

Instead of just telling GCC that dcbz(), dcbi(), dcbf() and dcbst()
clobber memory, tell it what it clobbers:
* dcbz(), dcbi() and dcbf() clobbers one cacheline as output
* dcbf() and dcbst() clobbers one cacheline as input

Signed-off-by: Christophe Leroy 
---
arch/powerpc/include/asm/cache.h | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/cache.h 
b/arch/powerpc/include/asm/cache.h

index c1d257aa4c2d..fc8fe18acf8c 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -82,22 +82,31 @@ extern void _set_L3CR(unsigned long);
static inline void dcbz(void *addr)
{
- __asm__ __volatile__ ("dcbz 0, %0" : : "r"(addr) : "memory");
+ __asm__ __volatile__ ("dcbz 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr) :);
}
static inline void dcbi(void *addr)
{
- __asm__ __volatile__ ("dcbi 0, %0" : : "r"(addr) : "memory");
+ __asm__ __volatile__ ("dcbi 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr) :);
}
static inline void dcbf(void *addr)
{
- __asm__ __volatile__ ("dcbf 0, %0" : : "r"(addr) : "memory");
+ __asm__ __volatile__ ("dcbf 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr), "m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ );
}
static inline void dcbst(void *addr)
{
- __asm__ __volatile__ ("dcbst 0, %0" : : "r"(addr) : "memory");
+ __asm__ __volatile__ ("dcbst 0, %0" : :
+ "r"(addr), "m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ );
}
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */



[PATCH v4 05/10] net: ethernet: support of_get_mac_address new ERR_PTR error

2019-05-03 Thread Petr Štetiar
There was NVMEM support added to of_get_mac_address, so it could now return
ERR_PTR encoded error values, so we need to adjust all current users of
of_get_mac_address to this new fact.

While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is always valid and checked by
is_valid_ether_addr anyway.

Signed-off-by: Petr Štetiar 
---

 Changes since v3:

  * IS_ERR_OR_NULL -> IS_ERR

 drivers/net/ethernet/aeroflex/greth.c | 2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c   | 2 +-
 drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
 drivers/net/ethernet/arc/emac_main.c  | 2 +-
 drivers/net/ethernet/aurora/nb8800.c  | 2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-bcma.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-platform.c| 2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c| 2 +-
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c  | 2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
 drivers/net/ethernet/davicom/dm9000.c | 2 +-
 drivers/net/ethernet/ethoc.c  | 2 +-
 drivers/net/ethernet/ezchip/nps_enet.c| 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 drivers/net/ethernet/freescale/fec_mpc52xx.c  | 2 +-
 drivers/net/ethernet/freescale/fman/mac.c | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c   | 2 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +-
 drivers/net/ethernet/lantiq_xrx200.c  | 2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
 drivers/net/ethernet/marvell/sky2.c   | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 2 +-
 drivers/net/ethernet/micrel/ks8851.c  | 2 +-
 drivers/net/ethernet/micrel/ks8851_mll.c  | 2 +-
 drivers/net/ethernet/microchip/enc28j60.c | 2 +-
 drivers/net/ethernet/nxp/lpc_eth.c| 2 +-
 drivers/net/ethernet/qualcomm/qca_spi.c   | 2 +-
 drivers/net/ethernet/qualcomm/qca_uart.c  | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c  | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c | 2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c   | 2 +-
 drivers/net/ethernet/socionext/sni_ave.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 drivers/net/ethernet/ti/cpsw.c| 2 +-
 drivers/net/ethernet/ti/netcp_core.c  | 2 +-
 drivers/net/ethernet/wiznet/w5100.c   | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c   | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
 net/ethernet/eth.c| 2 +-
 46 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/drivers/net/ethernet/aeroflex/greth.c 
b/drivers/net/ethernet/aeroflex/greth.c
index 47e5984..7c5cf02 100644
--- a/drivers/net/ethernet/aeroflex/greth.c
+++ b/drivers/net/ethernet/aeroflex/greth.c
@@ -1459,7 +1459,7 @@ static int greth_of_probe(struct platform_device *ofdev)
const u8 *addr;
 
addr = of_get_mac_address(ofdev->dev.of_node);
-   if (addr) {
+   if (!IS_ERR(addr)) {
for (i = 0; i < 6; i++)
macaddr[i] = (unsigned int) addr[i];
} else {
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c 
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index e1acafa..37ebd89 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -870,7 +870,7 @@ static int emac_probe(struct platform_device *pdev)
 
/* Read MAC-address from DT */
mac_addr = of_get_mac_address(np);
-   if (mac_addr)
+   if (!IS_ERR(mac_addr))
memcpy(ndev->dev_addr, mac_addr, ETH_ALEN);
 
/* Check if the MAC address is valid, if not get a random one */
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c 
b/drivers/net/ethernet/altera/altera_tse_main.c
index aa1d1f5..877e67f 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -1537,7 +1537,7 @@ static int altera_tse_probe(struct platform_device *pdev)
 
/* get default MAC address from device tree */
macaddr = of_get_mac_address(pdev->dev.of_node);
-   if (macaddr)
+   if (!IS_ERR(macaddr))
 

[PATCH v4 10/10] powerpc: tsi108: support of_get_mac_address new ERR_PTR error

2019-05-03 Thread Petr Štetiar
There was NVMEM support added to of_get_mac_address, so it could now return
ERR_PTR encoded error values, so we need to adjust all current users of
of_get_mac_address to this new fact.

Signed-off-by: Petr Štetiar 
---

 Changes since v3:

  * IS_ERR_OR_NULL -> IS_ERR

 arch/powerpc/sysdev/tsi108_dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/tsi108_dev.c b/arch/powerpc/sysdev/tsi108_dev.c
index 1f1af12..c92dcac 100644
--- a/arch/powerpc/sysdev/tsi108_dev.c
+++ b/arch/powerpc/sysdev/tsi108_dev.c
@@ -105,7 +105,7 @@ static int __init tsi108_eth_of_init(void)
}
 
mac_addr = of_get_mac_address(np);
-   if (mac_addr)
+   if (!IS_ERR(mac_addr))
memcpy(tsi_eth_data.mac_addr, mac_addr, 6);
 
ph = of_get_property(np, "mdio-handle", NULL);
-- 
1.9.1



Re: [PATCH kernel] prom_init: Fetch flatten device tree from the system firmware

2019-05-03 Thread Segher Boessenkool
On Wed, May 01, 2019 at 01:42:21PM +1000, Alexey Kardashevskiy wrote:
> At the moment, on 256CPU + 256 PCI devices guest, it takes the guest
> about 8.5sec to fetch the entire device tree via the client interface
> as the DT is traversed twice - for strings blob and for struct blob.
> Also, "getprop" is quite slow too as SLOF stores properties in a linked
> list.

Most OF implementations do it that way.  An optimisation that can help
a lot is to cache the last accessed node / prop.  This of course then
requires you to invalidate that cache at many places you did not think
about :-/

> However, since [1] SLOF builds flattened device tree (FDT) for another
> purpose. [2] adds a new "fdt-fetch" client interface for the OS to fetch
> the FDT.

Since Linux does not do much more with the device tree, this should
work great for it.


Segher


Re: [PATCH kernel] prom_init: Fetch flatten device tree from the system firmware

2019-05-03 Thread Segher Boessenkool
On Fri, May 03, 2019 at 10:10:57AM +1000, Stewart Smith wrote:
> David Gibson  writes:
> > On Wed, May 01, 2019 at 01:42:21PM +1000, Alexey Kardashevskiy wrote:
> >> At the moment, on 256CPU + 256 PCI devices guest, it takes the guest
> >> about 8.5sec to fetch the entire device tree via the client interface
> >> as the DT is traversed twice - for strings blob and for struct blob.
> >> Also, "getprop" is quite slow too as SLOF stores properties in a linked
> >> list.
> >> 
> >> However, since [1] SLOF builds flattened device tree (FDT) for another
> >> purpose. [2] adds a new "fdt-fetch" client interface for the OS to fetch
> >> the FDT.
> >> 
> >> This tries the new method; if not supported, this falls back to
> >> the old method.
> >> 
> >> There is a change in the FDT layout - the old method produced
> >> (reserved map, strings, structs), the new one receives only strings and
> >> structs from the firmware and adds the final reserved map to the end,
> >> so it is (fw reserved map, strings, structs, reserved map).
> >> This still produces the same unflattened device tree.
> >> 
> >> This merges the reserved map from the firmware into the kernel's reserved
> >> map. At the moment SLOF generates an empty reserved map so this does not
> >> change the existing behaviour in regard of reservations.
> >> 
> >> This supports only v17 onward as only that version provides dt_struct_size
> >> which works as "fdt-fetch" only produces v17 blobs.
> >> 
> >> If "fdt-fetch" is not available, the old method of fetching the DT is used.
> >> 
> >> [1] https://git.qemu.org/?p=SLOF.git;a=commitdiff;h=e6fc84652c9c00
> >> [2] https://git.qemu.org/?p=SLOF.git;a=commit;h=ecda95906930b80
> >> 
> >> Signed-off-by: Alexey Kardashevskiy 
> >
> > Hrm.  I've gotta say I'm not terribly convinced that it's worth adding
> > a new interface we'll need to maintain to save 8s on a somewhat
> > contrived testcase.
> 
> 256CPUs aren't that many anymore though. Although I guess that many PCI
> devices is still a little uncommon.
> 
> A 4 socket POWER8 or POWER9 can easily be that large, and a small test
> kernel/userspace will boot in ~2.5-4 seconds. So it's possible that
> the device tree fetch could be surprisingly non-trivial percentage of boot
> time at least on some machines.

All client interface calls are really heavy, and you need to do a lot of
them if you have a big device tree.  This takes time, even if the linked
list stuff does not kill you :-)


Segher


Re: [PATCH 05/15] csky: switch to generic version of pte allocation

2019-05-03 Thread Guo Ren
Hi Mike,

Acked-by: Guo Ren 

On Thu, May 02, 2019 at 06:28:32PM +0300, Mike Rapoport wrote:
> The csky implementation pte_alloc_one(), pte_free_kernel() and pte_free()
> is identical to the generic except of lack of __GFP_ACCOUNT for the user
> PTEs allocation.
> 
> Switch csky to use generic version of these functions.
Ok.

> 
> The csky implementation of pte_alloc_one_kernel() is not replaced because
> it does not clear the allocated page but rather sets each PTE in it to a
> non-zero value.
Yes, we must set each PTE to _PAGE_GLOBAL because hardware refill the
MMU TLB entry with two PTEs and it use the result of pte0.global | pte1.global.
If pte0 is valid and pte1 is invalid, we must set _PAGE_GLOBAL in
invalid pte entry. Fortunately, there is no performance issue.

> 
> The pte_free_kernel() and pte_free() versions on csky are identical to the
> generic ones and can be simply dropped.
Ok.

Best Regards
 Guo Ren

> 
> Signed-off-by: Mike Rapoport 
> ---
>  arch/csky/include/asm/pgalloc.h | 30 +++---
>  1 file changed, 3 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/csky/include/asm/pgalloc.h b/arch/csky/include/asm/pgalloc.h
> index d213bb4..98c571670 100644
> --- a/arch/csky/include/asm/pgalloc.h
> +++ b/arch/csky/include/asm/pgalloc.h
> @@ -8,6 +8,9 @@
>  #include 
>  #include 
>  
> +#define __HAVE_ARCH_PTE_ALLOC_ONE_KERNEL
> +#include  /* for pte_{alloc,free}_one */
> +
>  static inline void pmd_populate_kernel(struct mm_struct *mm, pmd_t *pmd,
>   pte_t *pte)
>  {
> @@ -39,33 +42,6 @@ static inline pte_t *pte_alloc_one_kernel(struct mm_struct 
> *mm)
>   return pte;
>  }
>  
> -static inline struct page *pte_alloc_one(struct mm_struct *mm)
> -{
> - struct page *pte;
> -
> - pte = alloc_pages(GFP_KERNEL | __GFP_ZERO, 0);
> - if (!pte)
> - return NULL;
> -
> - if (!pgtable_page_ctor(pte)) {
> - __free_page(pte);
> - return NULL;
> - }
> -
> - return pte;
> -}
> -
> -static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
> -{
> - free_pages((unsigned long)pte, PTE_ORDER);
> -}
> -
> -static inline void pte_free(struct mm_struct *mm, pgtable_t pte)
> -{
> - pgtable_page_dtor(pte);
> - __free_pages(pte, PTE_ORDER);
> -}
> -
>  static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
>  {
>   free_pages((unsigned long)pgd, PGD_ORDER);
> -- 
> 2.7.4
> 


Re: [PATCH 05/15] csky: switch to generic version of pte allocation

2019-05-03 Thread Guo Ren
On Sat, May 04, 2019 at 12:03:48AM +0800, Guo Ren wrote:
> Hi Mike,
> 
> Acked-by: Guo Ren 
> 
> On Thu, May 02, 2019 at 06:28:32PM +0300, Mike Rapoport wrote:
> > The csky implementation pte_alloc_one(), pte_free_kernel() and pte_free()
> > is identical to the generic except of lack of __GFP_ACCOUNT for the user
> > PTEs allocation.
> > 
> > Switch csky to use generic version of these functions.
> Ok.
> 
> > 
> > The csky implementation of pte_alloc_one_kernel() is not replaced because
> > it does not clear the allocated page but rather sets each PTE in it to a
> > non-zero value.
> Yes, we must set each PTE to _PAGE_GLOBAL because hardware refill the
> MMU TLB entry with two PTEs and it use the result of pte0.global | 
> pte1.global.
   ^
  correct: pte0.global & pte1.global
> If pte0 is valid and pte1 is invalid, we must set _PAGE_GLOBAL in
> invalid pte entry. Fortunately, there is no performance issue.
> 
> > 
> > The pte_free_kernel() and pte_free() versions on csky are identical to the
> > generic ones and can be simply dropped.
> Ok.
> 
> Best Regards
>  Guo Ren
> 
> > 
> > Signed-off-by: Mike Rapoport 
> > ---
> >  arch/csky/include/asm/pgalloc.h | 30 +++---
> >  1 file changed, 3 insertions(+), 27 deletions(-)
> > 
> > diff --git a/arch/csky/include/asm/pgalloc.h 
> > b/arch/csky/include/asm/pgalloc.h
> > index d213bb4..98c571670 100644
> > --- a/arch/csky/include/asm/pgalloc.h
> > +++ b/arch/csky/include/asm/pgalloc.h
> > @@ -8,6 +8,9 @@
> >  #include 
> >  #include 
> >  
> > +#define __HAVE_ARCH_PTE_ALLOC_ONE_KERNEL
> > +#include/* for pte_{alloc,free}_one */
> > +
> >  static inline void pmd_populate_kernel(struct mm_struct *mm, pmd_t *pmd,
> > pte_t *pte)
> >  {
> > @@ -39,33 +42,6 @@ static inline pte_t *pte_alloc_one_kernel(struct 
> > mm_struct *mm)
> > return pte;
> >  }
> >  
> > -static inline struct page *pte_alloc_one(struct mm_struct *mm)
> > -{
> > -   struct page *pte;
> > -
> > -   pte = alloc_pages(GFP_KERNEL | __GFP_ZERO, 0);
> > -   if (!pte)
> > -   return NULL;
> > -
> > -   if (!pgtable_page_ctor(pte)) {
> > -   __free_page(pte);
> > -   return NULL;
> > -   }
> > -
> > -   return pte;
> > -}
> > -
> > -static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
> > -{
> > -   free_pages((unsigned long)pte, PTE_ORDER);
> > -}
> > -
> > -static inline void pte_free(struct mm_struct *mm, pgtable_t pte)
> > -{
> > -   pgtable_page_dtor(pte);
> > -   __free_pages(pte, PTE_ORDER);
> > -}
> > -
> >  static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
> >  {
> > free_pages((unsigned long)pgd, PGD_ORDER);
> > -- 
> > 2.7.4
> > 
> 
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Re: [PATCH] powerpc/32: Remove memory clobber asm constraint on dcbX() functions

2019-05-03 Thread Segher Boessenkool
Hi Christophe,

On Fri, May 03, 2019 at 04:14:13PM +0200, Christophe Leroy wrote:
> A while ago I proposed the following patch, and didn't get any comment 
> back on it.

I didn't see it.  Maybe because of holiday :-)

> Do you have any opinion on it ? Is it good and worth it ?

> Le 09/01/2018 à 07:57, Christophe Leroy a écrit :
> >Instead of just telling GCC that dcbz(), dcbi(), dcbf() and dcbst()
> >clobber memory, tell it what it clobbers:
> >* dcbz(), dcbi() and dcbf() clobbers one cacheline as output
> >* dcbf() and dcbst() clobbers one cacheline as input

You cannot "clobber input".

Seen another way, only dcbi clobbers anything; dcbz zeroes it instead,
and dcbf and dcbst only change in what caches the data hangs out.

> >--- a/arch/powerpc/include/asm/cache.h
> >+++ b/arch/powerpc/include/asm/cache.h
> >@@ -82,22 +82,31 @@ extern void _set_L3CR(unsigned long);
> >  
> >  static inline void dcbz(void *addr)
> >  {
> >-__asm__ __volatile__ ("dcbz 0, %0" : : "r"(addr) : "memory");
> >+__asm__ __volatile__ ("dcbz 0, %1" :
> >+  "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
> >+  "r"(addr) :);
> >  }

The instruction does *not* work on the memory pointed to by addr.  It
works on the cache line containing the address addr.

If you want to have addr always aligned, you need to document this, and
check all callers, etc.

> >  static inline void dcbf(void *addr)
> >  {
> >-__asm__ __volatile__ ("dcbf 0, %0" : : "r"(addr) : "memory");
> >+__asm__ __volatile__ ("dcbf 0, %1" :
> >+  "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
> >+  "r"(addr), "m"(*(char 
> >(*)[L1_CACHE_BYTES])addr) :
> >+ );
> >  }

Newline damage...  Was that your mailer?


Also, you may want a "memory" clobber anyway, to get ordering correct
for the synchronisation instructions.

I think your changes make things less robust than they were before.


[ Btw.  Instead of

__asm__ __volatile__ ("dcbf 0, %0" : : "r"(addr) : "memory");

you can do

__asm__ __volatile__ ("dcbf %0" : : "Z"(addr) : "memory");

to save some insns here and there. ]


Segher


Re: [PATCH] soc: fsl: qe: gpio: Fix an error code in qe_pin_request()

2019-05-03 Thread Li Yang
On Fri, May 3, 2019 at 8:19 AM Dan Carpenter  wrote:
>
> There was a missing error code in this path.  It meant that we returned
> ERR_PTR(0) which is NULL and would result in a NULL dereference in the
> caller.

Thanks Dan.  An early version of this patch has been included in a
pending pull request to arm-soc.
https://lkml.org/lkml/2019/5/1/506


>
> Fixes: 1a2d397a6eb5 ("gpio/powerpc: Eliminate duplication of 
> of_get_named_gpio_flags()")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/soc/fsl/qe/gpio.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
> index 819bed0f5667..51b3a47b5a55 100644
> --- a/drivers/soc/fsl/qe/gpio.c
> +++ b/drivers/soc/fsl/qe/gpio.c
> @@ -179,8 +179,10 @@ struct qe_pin *qe_pin_request(struct device_node *np, 
> int index)
> if (err < 0)
> goto err0;
> gc = gpio_to_chip(err);
> -   if (WARN_ON(!gc))
> +   if (WARN_ON(!gc)) {
> +   err = -ENODEV;
> goto err0;
> +   }
>
> if (!of_device_is_compatible(gc->of_node, 
> "fsl,mpc8323-qe-pario-bank")) {
> pr_debug("%s: tried to get a non-qe pin\n", __func__);
> --
> 2.18.0
>


[PATCH v5] ASoC: fsl_esai: Add pm runtime function

2019-05-03 Thread Nicolin Chen
From: "S.j. Wang" 

Add pm runtime support and move clock handling there.
Close the clocks at suspend to reduce the power consumption.

fsl_esai_suspend is replaced by pm_runtime_force_suspend.
fsl_esai_resume is replaced by pm_runtime_force_resume.

Signed-off-by: Shengjiu Wang 
Signed-off-by: Nicolin Chen 
---
Changes in v5
-Replaced my Acked-by with Signed-off-by as a resend.

Changes in v4
-resend base on for-5.2

Changes in v3
-refine the commit comments.
-add acked-by

Changes in v2
-refine the commit comments.
-move regcache_mark_dirty to runtime suspend.

 sound/soc/fsl/fsl_esai.c | 141 +--
 1 file changed, 77 insertions(+), 64 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index c7410bbfd2af..022368c8a074 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -466,30 +467,6 @@ static int fsl_esai_startup(struct snd_pcm_substream 
*substream,
struct snd_soc_dai *dai)
 {
struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
-   int ret;
-
-   /*
-* Some platforms might use the same bit to gate all three or two of
-* clocks, so keep all clocks open/close at the same time for safety
-*/
-   ret = clk_prepare_enable(esai_priv->coreclk);
-   if (ret)
-   return ret;
-   if (!IS_ERR(esai_priv->spbaclk)) {
-   ret = clk_prepare_enable(esai_priv->spbaclk);
-   if (ret)
-   goto err_spbaclk;
-   }
-   if (!IS_ERR(esai_priv->extalclk)) {
-   ret = clk_prepare_enable(esai_priv->extalclk);
-   if (ret)
-   goto err_extalck;
-   }
-   if (!IS_ERR(esai_priv->fsysclk)) {
-   ret = clk_prepare_enable(esai_priv->fsysclk);
-   if (ret)
-   goto err_fsysclk;
-   }
 
if (!dai->active) {
/* Set synchronous mode */
@@ -506,16 +483,6 @@ static int fsl_esai_startup(struct snd_pcm_substream 
*substream,
 
return 0;
 
-err_fsysclk:
-   if (!IS_ERR(esai_priv->extalclk))
-   clk_disable_unprepare(esai_priv->extalclk);
-err_extalck:
-   if (!IS_ERR(esai_priv->spbaclk))
-   clk_disable_unprepare(esai_priv->spbaclk);
-err_spbaclk:
-   clk_disable_unprepare(esai_priv->coreclk);
-
-   return ret;
 }
 
 static int fsl_esai_hw_params(struct snd_pcm_substream *substream,
@@ -576,20 +543,6 @@ static int fsl_esai_hw_params(struct snd_pcm_substream 
*substream,
return 0;
 }
 
-static void fsl_esai_shutdown(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
-{
-   struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
-
-   if (!IS_ERR(esai_priv->fsysclk))
-   clk_disable_unprepare(esai_priv->fsysclk);
-   if (!IS_ERR(esai_priv->extalclk))
-   clk_disable_unprepare(esai_priv->extalclk);
-   if (!IS_ERR(esai_priv->spbaclk))
-   clk_disable_unprepare(esai_priv->spbaclk);
-   clk_disable_unprepare(esai_priv->coreclk);
-}
-
 static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
struct snd_soc_dai *dai)
 {
@@ -658,7 +611,6 @@ static int fsl_esai_trigger(struct snd_pcm_substream 
*substream, int cmd,
 
 static const struct snd_soc_dai_ops fsl_esai_dai_ops = {
.startup = fsl_esai_startup,
-   .shutdown = fsl_esai_shutdown,
.trigger = fsl_esai_trigger,
.hw_params = fsl_esai_hw_params,
.set_sysclk = fsl_esai_set_dai_sysclk,
@@ -947,6 +899,10 @@ static int fsl_esai_probe(struct platform_device *pdev)
return ret;
}
 
+   pm_runtime_enable(&pdev->dev);
+
+   regcache_cache_only(esai_priv->regmap, true);
+
ret = imx_pcm_dma_init(pdev, IMX_ESAI_DMABUF_SIZE);
if (ret)
dev_err(&pdev->dev, "failed to init imx pcm dma: %d\n", ret);
@@ -954,6 +910,13 @@ static int fsl_esai_probe(struct platform_device *pdev)
return ret;
 }
 
+static int fsl_esai_remove(struct platform_device *pdev)
+{
+   pm_runtime_disable(&pdev->dev);
+
+   return 0;
+}
+
 static const struct of_device_id fsl_esai_dt_ids[] = {
{ .compatible = "fsl,imx35-esai", },
{ .compatible = "fsl,vf610-esai", },
@@ -961,22 +924,35 @@ static const struct of_device_id fsl_esai_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, fsl_esai_dt_ids);
 
-#ifdef CONFIG_PM_SLEEP
-static int fsl_esai_suspend(struct device *dev)
-{
-   struct fsl_esai *esai = dev_get_drvdata(dev);
-
-   regcache_cache_only(esai->regmap, true);
-   regcache_mark_dirty(esai->regmap);
-
-   return 0;
-}
-
-static int fsl_esai_resume(struct device *dev)
+#ifdef CONFIG_PM
+static int fsl_esai_runtime_resume(struct device *dev)
 {
struct fsl_esai *esai = de

Re: [PATCH] soc: fsl: qe: gpio: Fix an error code in qe_pin_request()

2019-05-03 Thread Dan Carpenter
On Fri, May 03, 2019 at 01:45:07PM -0500, Li Yang wrote:
> On Fri, May 3, 2019 at 8:19 AM Dan Carpenter  wrote:
> >
> > There was a missing error code in this path.  It meant that we returned
> > ERR_PTR(0) which is NULL and would result in a NULL dereference in the
> > caller.
> 
> Thanks Dan.  An early version of this patch has been included in a
> pending pull request to arm-soc.
> https://lkml.org/lkml/2019/5/1/506

Oops.  Sorry, I switched computers and forgot to copy my old outbox
over.  :(

regards,
dan carpenter



Re: [EXT] Re: [PATCH V4] ASoC: fsl_esai: Add pm runtime function

2019-05-03 Thread Nicolin Chen
Hi Mark, 
On Fri, May 03, 2019 at 01:27:31PM +0900, Mark Brown wrote:
> On Thu, May 02, 2019 at 09:13:58AM +, S.j. Wang wrote:
> 
> > I am checking, but I don't know why this patch failed in your side. I 
> > Tried to apply this patch on for-5.1, for 5.2,  for-linus  and for-next, 
> > all are
> > Successful.  The git is 
> > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git.
> 
> > I can't reproduce your problem. Is there any my operation wrong?
> 
> The error message I got was:
> 
> Applying: ASoC: fsl_esai: Add pm runtime function
> error: patch failed: sound/soc/fsl/fsl_esai.c:9
> error: sound/soc/fsl/fsl_esai.c: patch does not apply
> Patch failed at 0001 ASoC: fsl_esai: Add pm runtime function
> 
> which is the header addition.  I can't spot any obvious issues visually
> looking at the patch, only thing I can think is some kind of whitespace
> damage somewhere.

I downloaded this v4 from patchwork and resubmitted a v5 for a
test. Would you please try to apply that one?

If my v5 works vs. having merge conflict at v4, maybe something
wrong with Git version of Shengjiu's? I compared my v5 and his
v4 using vimdiff, there is no much difference of whitespace.

Thanks
Nicolin


[PATCH] mm: add account_locked_vm utility function

2019-05-03 Thread Daniel Jordan
locked_vm accounting is done roughly the same way in five places, so
unify them in a helper.  Standardize the debug prints, which vary
slightly.  Error codes stay the same, so user-visible behavior does too.

Signed-off-by: Daniel Jordan 
Cc: Alan Tull 
Cc: Alexey Kardashevskiy 
Cc: Alex Williamson 
Cc: Andrew Morton 
Cc: Benjamin Herrenschmidt 
Cc: Christoph Lameter 
Cc: Christophe Leroy 
Cc: Davidlohr Bueso 
Cc: Jason Gunthorpe 
Cc: Mark Rutland 
Cc: Michael Ellerman 
Cc: Moritz Fischer 
Cc: Paul Mackerras 
Cc: Steve Sistare 
Cc: Wu Hao 
Cc: linux...@kvack.org
Cc: k...@vger.kernel.org
Cc: kvm-...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-f...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---

Based on v5.1-rc7.  Tested with the vfio type1 driver.  Any feedback
welcome.

Andrew, this one patch replaces these six from [1]:

mm-change-locked_vms-type-from-unsigned-long-to-atomic64_t.patch
vfio-type1-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
vfio-spapr_tce-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
fpga-dlf-afu-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
kvm-book3s-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
powerpc-mmu-drop-mmap_sem-now-that-locked_vm-is-atomic.patch

That series converts locked_vm to an atomic, but on closer inspection causes at
least one accounting race in mremap, and fixing it just for this type
conversion came with too much ugly in the core mm to justify, especially when
the right long-term fix is making these drivers use pinned_vm instead.

Christophe's suggestion of cmpxchg[2] does prevent the races he
mentioned for pinned_vm, but others would still remain.  In perf_mmap
and the hfi1 driver, pinned_vm is checked against the rlimit racily and
then later increased when the pinned_vm originally read may have gone
stale.  Any fixes for that, that I could think of, seem about as good as
what's there now, so I left it.  I have a patch that uses cmpxchg with
pinned_vm if others feel strongly that the aforementioned races should
be fixed.

Daniel

[1] 
https://lore.kernel.org/linux-mm/20190402204158.27582-1-daniel.m.jor...@oracle.com/
[2] 
https://lore.kernel.org/linux-mm/964bd5b0-f1e5-7bf0-5c58-18e75c550...@c-s.fr/

 arch/powerpc/kvm/book3s_64_vio.c| 44 +++-
 arch/powerpc/mm/mmu_context_iommu.c | 41 +++---
 drivers/fpga/dfl-afu-dma-region.c   | 53 +++--
 drivers/vfio/vfio_iommu_spapr_tce.c | 52 +---
 drivers/vfio/vfio_iommu_type1.c | 23 -
 include/linux/mm.h  | 19 +++
 mm/util.c   | 48 ++
 7 files changed, 94 insertions(+), 186 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index f02b04973710..f7d37fa6003a 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -56,43 +57,6 @@ static unsigned long kvmppc_stt_pages(unsigned long 
tce_pages)
return tce_pages + ALIGN(stt_bytes, PAGE_SIZE) / PAGE_SIZE;
 }
 
-static long kvmppc_account_memlimit(unsigned long stt_pages, bool inc)
-{
-   long ret = 0;
-
-   if (!current || !current->mm)
-   return ret; /* process exited */
-
-   down_write(¤t->mm->mmap_sem);
-
-   if (inc) {
-   unsigned long locked, lock_limit;
-
-   locked = current->mm->locked_vm + stt_pages;
-   lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
-   if (locked > lock_limit && !capable(CAP_IPC_LOCK))
-   ret = -ENOMEM;
-   else
-   current->mm->locked_vm += stt_pages;
-   } else {
-   if (WARN_ON_ONCE(stt_pages > current->mm->locked_vm))
-   stt_pages = current->mm->locked_vm;
-
-   current->mm->locked_vm -= stt_pages;
-   }
-
-   pr_debug("[%d] RLIMIT_MEMLOCK KVM %c%ld %ld/%ld%s\n", current->pid,
-   inc ? '+' : '-',
-   stt_pages << PAGE_SHIFT,
-   current->mm->locked_vm << PAGE_SHIFT,
-   rlimit(RLIMIT_MEMLOCK),
-   ret ? " - exceeded" : "");
-
-   up_write(¤t->mm->mmap_sem);
-
-   return ret;
-}
-
 static void kvm_spapr_tce_iommu_table_free(struct rcu_head *head)
 {
struct kvmppc_spapr_tce_iommu_table *stit = container_of(head,
@@ -277,7 +241,7 @@ static int kvm_spapr_tce_release(struct inode *inode, 
struct file *filp)
 
kvm_put_kvm(stt->kvm);
 
-   kvmppc_account_memlimit(
+   account_locked_vm(current->mm,
kvmppc_stt_pages(kvmppc_tce_pages(stt->size)), false);
call_rcu(&stt->rcu, release_spapr_tce_table);
 
@@ -303,7 +267,7 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
return -EINVAL;
 
npages = 

Re: [PATCH 14/15] um: switch to generic version of pte allocation

2019-05-03 Thread Anton Ivanov




On 02/05/2019 16:28, Mike Rapoport wrote:

um allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.

Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.

The pte_free() and pte_free_kernel() versions are identical to the generic
ones and can be simply dropped.

Signed-off-by: Mike Rapoport 
---
  arch/um/include/asm/pgalloc.h | 16 ++--
  arch/um/kernel/mem.c  | 22 --
  2 files changed, 2 insertions(+), 36 deletions(-)

diff --git a/arch/um/include/asm/pgalloc.h b/arch/um/include/asm/pgalloc.h
index 99eb568..d7b282e 100644
--- a/arch/um/include/asm/pgalloc.h
+++ b/arch/um/include/asm/pgalloc.h
@@ -10,6 +10,8 @@
  
  #include 
  
+#include 	/* for pte_{alloc,free}_one */

+
  #define pmd_populate_kernel(mm, pmd, pte) \
set_pmd(pmd, __pmd(_PAGE_TABLE + (unsigned long) __pa(pte)))
  
@@ -25,20 +27,6 @@

  extern pgd_t *pgd_alloc(struct mm_struct *);
  extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
  
-extern pte_t *pte_alloc_one_kernel(struct mm_struct *);

-extern pgtable_t pte_alloc_one(struct mm_struct *);
-
-static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
-{
-   free_page((unsigned long) pte);
-}
-
-static inline void pte_free(struct mm_struct *mm, pgtable_t pte)
-{
-   pgtable_page_dtor(pte);
-   __free_page(pte);
-}
-
  #define __pte_free_tlb(tlb,pte, address)  \
  do {  \
pgtable_page_dtor(pte); \
diff --git a/arch/um/kernel/mem.c b/arch/um/kernel/mem.c
index 99aa11b..2280374 100644
--- a/arch/um/kernel/mem.c
+++ b/arch/um/kernel/mem.c
@@ -215,28 +215,6 @@ void pgd_free(struct mm_struct *mm, pgd_t *pgd)
free_page((unsigned long) pgd);
  }
  
-pte_t *pte_alloc_one_kernel(struct mm_struct *mm)

-{
-   pte_t *pte;
-
-   pte = (pte_t *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
-   return pte;
-}
-
-pgtable_t pte_alloc_one(struct mm_struct *mm)
-{
-   struct page *pte;
-
-   pte = alloc_page(GFP_KERNEL|__GFP_ZERO);
-   if (!pte)
-   return NULL;
-   if (!pgtable_page_ctor(pte)) {
-   __free_page(pte);
-   return NULL;
-   }
-   return pte;
-}
-
  #ifdef CONFIG_3_LEVEL_PGTABLES
  pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long address)
  {




Reviewed-by: Anton Ivanov 
Acked-by: Anton Ivanov 

--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/


Re: [PATCH] mm: add account_locked_vm utility function

2019-05-03 Thread Jason Gunthorpe
On Fri, May 03, 2019 at 01:16:30PM -0700, Daniel Jordan wrote:
> locked_vm accounting is done roughly the same way in five places, so
> unify them in a helper.  Standardize the debug prints, which vary
> slightly.  Error codes stay the same, so user-visible behavior does too.
> 
> Signed-off-by: Daniel Jordan 
> Cc: Alan Tull 
> Cc: Alexey Kardashevskiy 
> Cc: Alex Williamson 
> Cc: Andrew Morton 
> Cc: Benjamin Herrenschmidt 
> Cc: Christoph Lameter 
> Cc: Christophe Leroy 
> Cc: Davidlohr Bueso 
> Cc: Jason Gunthorpe 
> Cc: Mark Rutland 
> Cc: Michael Ellerman 
> Cc: Moritz Fischer 
> Cc: Paul Mackerras 
> Cc: Steve Sistare 
> Cc: Wu Hao 
> Cc: linux...@kvack.org
> Cc: k...@vger.kernel.org
> Cc: kvm-...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-f...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> 
> Based on v5.1-rc7.  Tested with the vfio type1 driver.  Any feedback
> welcome.
> 
> Andrew, this one patch replaces these six from [1]:
> 
> mm-change-locked_vms-type-from-unsigned-long-to-atomic64_t.patch
> vfio-type1-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
> vfio-spapr_tce-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
> fpga-dlf-afu-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
> kvm-book3s-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
> powerpc-mmu-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
> 
> That series converts locked_vm to an atomic, but on closer inspection causes 
> at
> least one accounting race in mremap, and fixing it just for this type
> conversion came with too much ugly in the core mm to justify, especially when
> the right long-term fix is making these drivers use pinned_vm instead.

Did we ever decide what to do here? Should all these drivers be
switched to pinned_vm anyhow?

Jason