Re: [PATCH v3 4/6] powerpc/pseries/iommu: Remove default DMA window before creating DDW

2020-07-14 Thread Leonardo Bras
On Tue, 2020-07-14 at 14:52 +1000, Alexey Kardashevskiy wrote: > > On 14/07/2020 12:40, Leonardo Bras wrote: > > Thank you for this feedback Alexey! > > > > On Mon, 2020-07-13 at 17:33 +1000, Alexey Kardashevskiy wrote: > > > [...] > > > > - int len, ret; > > > > + int len, ret,

Re: [PATCH v2] powerpc/pseries: detect secure and trusted boot state of the system.

2020-07-14 Thread Daniel Axtens
Hi Nayna, Thanks! Would you be able to fold in some of the information from my reply to v1 into the changelog? Until we have public PAPR release with it, that information is the extent of the public documentation. It would be good to get it into the git log rather than just floating around in the

Re: [PATCH 4/5] dma-mapping: add a dma_ops_bypass flag to struct device

2020-07-14 Thread Christoph Hellwig
On Mon, Jul 13, 2020 at 02:59:39PM +1000, Alexey Kardashevskiy wrote: > > > On 09/07/2020 01:24, Christoph Hellwig wrote: > > Several IOMMU drivers have a bypass mode where they can use a direct > > mapping if the devices DMA mask is large enough. Add generic support > > to the core dma-mapping

Re: [PATCH 4/5] dma-mapping: add a dma_ops_bypass flag to struct device

2020-07-14 Thread Alexey Kardashevskiy
On 14/07/2020 17:07, Christoph Hellwig wrote: > On Mon, Jul 13, 2020 at 02:59:39PM +1000, Alexey Kardashevskiy wrote: >> >> >> On 09/07/2020 01:24, Christoph Hellwig wrote: >>> Several IOMMU drivers have a bypass mode where they can use a direct >>> mapping if the devices DMA mask is large

Re: [PATCH 05/11] powerpc/smp: Dont assume l2-cache to be superset of sibling

2020-07-14 Thread Srikar Dronamraju
* Oliver O'Halloran [2020-07-14 15:40:09]: > On Tue, Jul 14, 2020 at 2:45 PM Srikar Dronamraju > wrote: > > > > Current code assumes that cpumask of cpus sharing a l2-cache mask will > > always be a superset of cpu_sibling_mask. > > > > Lets stop that assumption. > > It's been a while since I

Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-07-14 Thread Nicholas Piggin
Excerpts from Nicholas Piggin's message of July 14, 2020 3:04 pm: > Excerpts from Andy Lutomirski's message of July 14, 2020 4:18 am: >> >>> On Jul 13, 2020, at 9:48 AM, Nicholas Piggin wrote: >>> >>> Excerpts from Andy Lutomirski's message of July 14, 2020 1:59 am: > On Thu, Jul 9, 2020

Re: [PATCH v3 4/6] powerpc/pseries/iommu: Remove default DMA window before creating DDW

2020-07-14 Thread Leonardo Bras
In fact, the changes over the last patch are more complex than the current patch. Just for reference, that's how enable_ddw() currently patches: @@ -1087,7 +1119,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn) struct device_node *dn; u32

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Ard Biesheuvel
On Tue, 14 Jul 2020 at 05:04, Steven Rostedt wrote: > > On Mon, 13 Jul 2020 22:49:48 +0300 > Ard Biesheuvel wrote: > > > On arm64, we no longer use module_alloc for bpf or kprobes, to avoid > > wasting va space on code that does not need to be loaded close to the > > kernel. Also, module_alloc()

Re: /sys/kernel/debug/kmemleak empty despite kmemleak reports

2020-07-14 Thread Paul Menzel
Dear Catalin, Am 13.07.20 um 20:27 schrieb Catalin Marinas: On Thu, Jul 09, 2020 at 11:08:52PM +0200, Paul Menzel wrote: Am 09.07.20 um 19:57 schrieb Catalin Marinas: On Thu, Jul 09, 2020 at 04:37:10PM +0200, Paul Menzel wrote: Despite Linux 5.8-rc4 reporting memory leaks on the IBM POWER 8

Re: [PATCH 03/15] powerpc/powernv/pci: Add explicit tracking of the DMA setup state

2020-07-14 Thread Alexey Kardashevskiy
On 14/07/2020 15:58, Oliver O'Halloran wrote: > On Tue, Jul 14, 2020 at 3:37 PM Alexey Kardashevskiy wrote: >> >> On 10/07/2020 15:23, Oliver O'Halloran wrote: >>> There's an optimisation in the PE setup which skips performing DMA >>> setup for a PE if we only have bridges in a PE. The

[PATCH] spi: ppc4xx: Convert to use GPIO descriptors

2020-07-14 Thread Linus Walleij
This converts the PPC4xx SPI driver to use GPIO descriptors. The driver is already just picking some GPIOs from the device tree so the conversion is pretty straight forward. However this driver is looking form a pure "gpios" property rather than the standard binding "cs-gpios" so we need to add a

Re: [PATCH 04/15] powerpc/powernv/pci: Initialise M64 for IODA1 as a 1-1 window

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > We pre-configure the m64 window for IODA1 as a 1-1 segment-PE mapping, > similar to PHB3. Currently the actual mapping of segments occurs in > pnv_ioda_pick_m64_pe(), but we can move it into pnv_ioda1_init_m64() and > drop the IODA1 specific code

Re: [PATCH v3] powerpc/perf: Use SIER_USER_MASK while updating SPRN_SIER for EBB events

2020-07-14 Thread Michael Ellerman
Athira Rajeev writes: >> On 19-Mar-2020, at 4:22 PM, Michael Ellerman wrote: >> >> Hi Athira, >> >> Athira Rajeev writes: >>> Sampled Instruction Event Register (SIER), is a PMU register, >> ^ >>

[PATCH 2/3] ASoC: bindings: fsl-asoc-card: Support hp-det-gpio and mic-det-gpio

2020-07-14 Thread Shengjiu Wang
Add headphone and microphone detection GPIO support. Signed-off-by: Shengjiu Wang --- Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt

Re: [PATCH 06/20] Documentation: gpu/komeda-kms: eliminate duplicated word

2020-07-14 Thread Daniel Vetter
On Tue, Jul 14, 2020 at 12:10:05PM +0200, Daniel Vetter wrote: > This and next patch merged to drm-misc-next, thanks. Oops strike this, I just noticed that Jon said he's picked it all up. Oh well, the confusion, I managed to stop the script before it published anything at least :-) -Daniel > >

[PATCH v2 0/3] kprobes: Remove MODULE dependency

2020-07-14 Thread Jarkko Sakkinen
Remove MODULES dependency by creating module subsystem indepdent text_alloc() and text_memfree() to allocate space for executable code. Right now one has to compile modules support only to enable kprobes. This incrases the barrier to use them in test kernels and I'd guess also in some embedded

[PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Jarkko Sakkinen
Rename module_alloc() to text_alloc() and module_memfree() to text_memfree(), and move them to kernel/text.c, which is unconditionally compiled to the kernel proper. This allows kprobes, ftrace and bpf to allocate space for executable code without requiring to compile the modules support

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Jarkko Sakkinen
On Mon, Jul 13, 2020 at 07:34:10PM +0100, Russell King - ARM Linux admin wrote: > On Mon, Jul 13, 2020 at 09:19:37PM +0300, Jarkko Sakkinen wrote: > > Rename module_alloc() to text_alloc() and module_memfree() to > > text_memfree(), and move them to kernel/text.c, which is unconditionally > >

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Russell King - ARM Linux admin
On Tue, Jul 14, 2020 at 12:45:36PM +0300, Jarkko Sakkinen wrote: > Rename module_alloc() to text_alloc() and module_memfree() to > text_memfree(), and move them to kernel/text.c, which is unconditionally > compiled to the kernel proper. This allows kprobes, ftrace and bpf to > allocate space for

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Jarkko Sakkinen
On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote: > This patch suggests that there are other reasons why conflating > allocation of module space and allocating text pages for other uses > is a bad idea, but switching all users to text_alloc() is a step in > the wrong direction. It

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Russell King - ARM Linux admin
On Tue, Jul 14, 2020 at 12:49:28PM +0300, Jarkko Sakkinen wrote: > On Mon, Jul 13, 2020 at 07:34:10PM +0100, Russell King - ARM Linux admin > wrote: > > On Mon, Jul 13, 2020 at 09:19:37PM +0300, Jarkko Sakkinen wrote: > > > Rename module_alloc() to text_alloc() and module_memfree() to > > >

Re: [PATCH 06/20] Documentation: gpu/komeda-kms: eliminate duplicated word

2020-07-14 Thread Daniel Vetter
This and next patch merged to drm-misc-next, thanks. On Wed, Jul 08, 2020 at 01:08:21PM +0800, james qian wang (Arm Technology China) wrote: > Hi Randy > > On Tue, Jul 07, 2020 at 11:04:00AM -0700, Randy Dunlap wrote: > > Drop the doubled word "and". > > > > Signed-off-by: Randy Dunlap > >

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Ard Biesheuvel
On Tue, 14 Jul 2020 at 12:53, Jarkko Sakkinen wrote: > > On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote: > > This patch suggests that there are other reasons why conflating > > allocation of module space and allocating text pages for other uses > > is a bad idea, but switching

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Will Deacon
On Tue, Jul 14, 2020 at 12:45:36PM +0300, Jarkko Sakkinen wrote: > Rename module_alloc() to text_alloc() and module_memfree() to > text_memfree(), and move them to kernel/text.c, which is unconditionally > compiled to the kernel proper. This allows kprobes, ftrace and bpf to > allocate space for

[PATCH 1/3] ASoC: simple-card-utils: Support configure pin_name for asoc_simple_init_jack

2020-07-14 Thread Shengjiu Wang
Currently the pin_name is fixed in asoc_simple_init_jack, but some driver may use a different pin_name. So add a new parameter in asoc_simple_init_jack for configuring pin_name. If this parameter is NULL, then the default pin_name is used. Signed-off-by: Shengjiu Wang ---

[PATCH 3/3] ASoC: fsl-asoc-card: Support Headphone and Microphone Jack detection

2020-07-14 Thread Shengjiu Wang
Use asoc_simple_init_jack function from simple card to implement the Headphone and Microphone detection. Register notifier to disable Speaker when Headphone is plugged in and enable Speaker when Headphone is unplugged. Register notifier to disable Digital Microphone when Analog Microphone is

[PATCH 0/3] ASoC: fsl-asoc-card: Support hp and mic detection

2020-07-14 Thread Shengjiu Wang
Support hp and mic detection. Add a parameter for asoc_simple_init_jack. Shengjiu Wang (3): ASoC: simple-card-utils: Support configure pin_name for asoc_simple_init_jack ASoC: bindings: fsl-asoc-card: Support hp-det-gpio and mic-det-gpio ASoC: fsl-asoc-card: Support Headphone and

Re: [PATCH 05/15] powerpc/powernv/sriov: Move SR-IOV into a seperate file

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > pci-ioda.c is getting a bit unwieldly due to the amount of stuff jammed in > there. The SR-IOV support can be extracted easily enough and is mostly > standalone, so move it into a seperate file. > > This patch also moves the PowerNV SR-IOV

Re: [PATCH 14/14] powerpc/eeh: Move PE tree setup into the platform

2020-07-14 Thread Alexey Kardashevskiy
On 14/07/2020 13:08, Oliver O'Halloran wrote: > On Tue, Jul 14, 2020 at 11:50 AM Alexey Kardashevskiy wrote: >> >> On 06/07/2020 11:36, Oliver O'Halloran wrote: >>> /** >>> * eeh_pe_tree_insert - Add EEH device to parent PE >>> * @edev: EEH device >>> + * @new_pe_parent: PE to create

[PATCH -next] cpuidle/pseries: Make symbol 'pseries_idle_driver' static

2020-07-14 Thread Wei Yongjun
The sparse tool complains as follows: drivers/cpuidle/cpuidle-pseries.c:25:23: warning: symbol 'pseries_idle_driver' was not declared. Should it be static? 'pseries_idle_driver' is not used outside of this file, so marks it static. Reported-by: Hulk Robot Signed-off-by: Wei Yongjun ---

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Jarkko Sakkinen
On Tue, Jul 14, 2020 at 01:29:27PM +0200, Peter Zijlstra wrote: > On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote: > > > As Ard says, module_alloc() _is_ special, in the sense that the virtual > > memory it allocates wants to be close to the kernel text, whereas the > > concept of

Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-07-14 Thread Peter Zijlstra
On Tue, Jul 14, 2020 at 05:46:05AM -0700, Andy Lutomirski wrote: > x86 has this exact problem. At least no more than 64*8 CPUs share the cache > line :) I've seen patches for a 'sparse' bitmap to solve related problems. It's basically the same code, except it multiplies everything (size,

Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-07-14 Thread Andy Lutomirski
> On Jul 13, 2020, at 11:31 PM, Nicholas Piggin wrote: > > Excerpts from Nicholas Piggin's message of July 14, 2020 3:04 pm: >> Excerpts from Andy Lutomirski's message of July 14, 2020 4:18 am: >>> On Jul 13, 2020, at 9:48 AM, Nicholas Piggin wrote: Excerpts from Andy

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Ard Biesheuvel
On Tue, 14 Jul 2020 at 14:31, Peter Zijlstra wrote: > > On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote: > > > As Ard says, module_alloc() _is_ special, in the sense that the virtual > > memory it allocates wants to be close to the kernel text, whereas the > > concept of allocating

[PATCH -next] cpufreq: powernv: Make some symbols static

2020-07-14 Thread Wei Yongjun
The sparse tool complains as follows: drivers/cpufreq/powernv-cpufreq.c:88:1: warning: symbol 'pstate_revmap' was not declared. Should it be static? drivers/cpufreq/powernv-cpufreq.c:383:18: warning: symbol 'cpufreq_freq_attr_cpuinfo_nominal_freq' was not declared. Should it be static?

[PATCH 07/13] cpufreq: powernv-cpufreq: Fix a bunch of kerneldoc related issues

2020-07-14 Thread Lee Jones
Repair problems with formatting and missing attributes/parameters, and demote header comments which do not meet the required standards applicable to kerneldoc. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/powernv-cpufreq.c:84: warning: Function parameter or member

[PATCH 05/13] cpufreq/arch: powerpc: pasemi: Move prototypes to shared header

2020-07-14 Thread Lee Jones
If function callers and providers do not share the same prototypes the compiler complains of missing prototypes. Fix this by moving the already existing prototypes out to a mutually convenient location. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/pasemi-cpufreq.c:109:5:

Re: [PATCH v2] powerpc/pseries: detect secure and trusted boot state of the system.

2020-07-14 Thread Mimi Zohar
On Tue, 2020-07-14 at 16:38 +1000, Daniel Axtens wrote: > Hi Nayna, > > Thanks! Would you be able to fold in some of the information from my > reply to v1 into the changelog? Until we have public PAPR release with > it, that information is the extent of the public documentation. It would > be

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Peter Zijlstra
On Tue, Jul 14, 2020 at 11:33:33AM +0100, Russell King - ARM Linux admin wrote: > For 32-bit ARM, our bpf code uses "blx/bx" (or equivalent code > sequences) rather than encoding a "bl" or "b", so BPF there doesn't > care where the executable memory is mapped, and doesn't need any > PLTs. Given

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Jarkko Sakkinen
On Tue, Jul 14, 2020 at 11:33:33AM +0100, Russell King - ARM Linux admin wrote: > On Tue, Jul 14, 2020 at 01:17:22PM +0300, Ard Biesheuvel wrote: > > On Tue, 14 Jul 2020 at 12:53, Jarkko Sakkinen > > wrote: > > > > > > On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote: > > > > This

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Jarkko Sakkinen
On Tue, Jul 14, 2020 at 01:17:22PM +0300, Ard Biesheuvel wrote: > > This series essentially does this: introduces text_alloc() and > > text_memfree(), which have generic implementations in kernel/text.c. > > Those can be overriddent by arch specific implementations. > > > > What you think should

[PATCH 06/13] cpufreq: powernv-cpufreq: Functions only used in call-backs should be static

2020-07-14 Thread Lee Jones
Fixes the following W=1 kernel build warning(s): drivers/cpufreq/powernv-cpufreq.c:669:6: warning: no previous prototype for ‘gpstate_timer_handler’ [-Wmissing-prototypes] drivers/cpufreq/powernv-cpufreq.c:902:6: warning: no previous prototype for ‘powernv_cpufreq_work_fn’

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Russell King - ARM Linux admin
On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote: > On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote: > > So perhaps the answer is to have text_alloc() not with a 'where' > > argument but with a 'why' argument. Or more simply, just have separate > > alloc/free APIs for

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Peter Zijlstra
On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote: > So perhaps the answer is to have text_alloc() not with a 'where' > argument but with a 'why' argument. Or more simply, just have separate > alloc/free APIs for each case, with generic versions that can be > overridden by the

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Peter Zijlstra
On Tue, Jul 14, 2020 at 07:31:03PM +0300, Jarkko Sakkinen wrote: > On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote: > > to help with text_alloc() usage in generic code, but I think > > fundamentally, there's only these two options. > > There is one arch (nios2), which uses a

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Jessica Yu
+++ Jarkko Sakkinen [14/07/20 12:45 +0300]: Rename module_alloc() to text_alloc() and module_memfree() to text_memfree(), and move them to kernel/text.c, which is unconditionally compiled to the kernel proper. This allows kprobes, ftrace and bpf to allocate space for executable code without

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Steven Rostedt
On Tue, 14 Jul 2020 14:33:14 +0100 Mark Rutland wrote: > > Should work for all cases. Yes, we might then want something like a per > > arch: > > > > {BPF,FTRACE,KPROBE}_TEXT_TYPE > > ... at that point why not: > > text_alloc_ftrace(); > text_alloc_module(); > text_alloc_bpf(); >

Re: [PATCH v2 3/5] powerpc/lib: Use a temporary mm for code patching

2020-07-14 Thread Christopher M. Riedl
On Thu Jul 9, 2020 at 4:02 AM CDT, Christophe Leroy wrote: > > > Le 09/07/2020 à 06:03, Christopher M. Riedl a écrit : > > Currently, code patching a STRICT_KERNEL_RWX exposes the temporary > > mappings to other CPUs. These mappings should be kept local to the CPU > > doing the patching. Use the

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Bjorn Helgaas
[trimmed the cc list; it's still too large but maybe arch folks care] On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote: > On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa > wrote: > > This goal of these series is to move the definition of *all* > > PCIBIOS* from

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Steven Rostedt
On Tue, 14 Jul 2020 15:56:52 +0200 Jessica Yu wrote: > As Ard and Will have already explained, the major issue I'm having > with this is that we're taking module_alloc(), an allocator that was > originally specific to module loading, and turning it into a generic > interface to be used by other

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Mark Rutland
On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote: > On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote: > > So perhaps the answer is to have text_alloc() not with a 'where' > > argument but with a 'why' argument. Or more simply, just have separate > > alloc/free APIs for

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Ard Biesheuvel
On Tue, 14 Jul 2020 at 16:33, Mark Rutland wrote: > > On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote: > > On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote: > > > So perhaps the answer is to have text_alloc() not with a 'where' > > > argument but with a 'why'

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Jarkko Sakkinen
On Tue, Jul 14, 2020 at 03:56:52PM +0200, Jessica Yu wrote: > +++ Jarkko Sakkinen [14/07/20 12:45 +0300]: > > Rename module_alloc() to text_alloc() and module_memfree() to > > text_memfree(), and move them to kernel/text.c, which is unconditionally > > compiled to the kernel proper. This allows

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Jarkko Sakkinen
On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote: > On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote: > > So perhaps the answer is to have text_alloc() not with a 'where' > > argument but with a 'why' argument. Or more simply, just have separate > > alloc/free APIs for

Re: [PATCH v3 01/12] kexec_file: allow archs to handle special regions while locating memory hole

2020-07-14 Thread Thiago Jung Bauermann
Hari Bathini writes: > Some architectures may have special memory regions, within the given > memory range, which can't be used for the buffer in a kexec segment. > Implement weak arch_kexec_locate_mem_hole() definition which arch code > may override, to take care of special regions, while

Re: [PATCH v3 03/12] powerpc/kexec_file: add helper functions for getting memory ranges

2020-07-14 Thread Thiago Jung Bauermann
Hello Hari, Hari Bathini writes: > In kexec case, the kernel to be loaded uses the same memory layout as > the running kernel. So, passing on the DT of the running kernel would > be good enough. > > But in case of kdump, different memory ranges are needed to manage > loading the kdump kernel,

Re: [PATCH 03/15] powerpc/powernv/pci: Add explicit tracking of the DMA setup state

2020-07-14 Thread Alexey Kardashevskiy
On 14/07/2020 17:21, Alexey Kardashevskiy wrote: > > > On 14/07/2020 15:58, Oliver O'Halloran wrote: >> On Tue, Jul 14, 2020 at 3:37 PM Alexey Kardashevskiy wrote: >>> >>> On 10/07/2020 15:23, Oliver O'Halloran wrote: There's an optimisation in the PE setup which skips performing DMA

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Rob Herring
On Tue, Jul 14, 2020 at 12:45 PM Bjorn Helgaas wrote: > > [trimmed the cc list; it's still too large but maybe arch folks care] > > On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote: > > On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa > > wrote: > > > This goal of these series is

[PATCH] pseries: Fix 64 bit logical memory block panic

2020-07-14 Thread Anton Blanchard
Booting with a 4GB LMB size causes us to panic: qemu-system-ppc64: OS terminated: OS panic: Memory block size not suitable: 0x0 Fix pseries_memory_block_size() to handle 64 bit LMBs. Cc: sta...@vger.kernel.org Signed-off-by: Anton Blanchard ---

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Benjamin Herrenschmidt
On Tue, 2020-07-14 at 13:45 -0500, Bjorn Helgaas wrote: > > > fail for valid arguments on a valid pci_device* ? > > I really like this idea. > > pci_write_config_*() has one return value, and only 100ish of 2500 > callers check for errors. It's sometimes possible for config > accessors to

Re: [PATCH v2 5/5] powerpc: Add LKDTM test to hijack a patch mapping

2020-07-14 Thread Kees Cook
On Wed, Jul 08, 2020 at 11:03:16PM -0500, Christopher M. Riedl wrote: > When live patching with STRICT_KERNEL_RWX, the CPU doing the patching > must use a temporary mapping which allows for writing to kernel text. > During the entire window of time when this temporary mapping is in use, > another

Re: [PATCH 08/15] powerpc/powernv/sriov: Simplify used window tracking

2020-07-14 Thread Oliver O'Halloran
On Wed, Jul 15, 2020 at 11:34 AM Alexey Kardashevskiy wrote: > > On 10/07/2020 15:23, Oliver O'Halloran wrote: > > diff --git a/arch/powerpc/platforms/powernv/pci.h > > b/arch/powerpc/platforms/powernv/pci.h > > index 0156d7d17f7d..58c97e60c3db 100644 > > ---

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Benjamin Herrenschmidt
On Tue, 2020-07-14 at 23:02 +0200, Kjetil Oftedal wrote: > > > > > For b), it might be nice to also change other aspects of the > > > interface, e.g. passing a pci_host_bridge pointer plus bus number > > > instead of a pci_bus pointer, or having the callback in the > > > pci_host_bridge

Re: [PATCH 3/3] ASoC: fsl-asoc-card: Support Headphone and Microphone Jack detection

2020-07-14 Thread Nicolin Chen
Hi Shengjiu, The whole series looks good to me. Just a couple of small questions inline: On Tue, Jul 14, 2020 at 05:05:36PM +0800, Shengjiu Wang wrote: > Use asoc_simple_init_jack function from simple card to implement > the Headphone and Microphone detection. > Register notifier to disable

Re: [PATCH 07/15] powerpc/powernv/sriov: Rename truncate_iov

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > This prevents SR-IOV being used by making the SR-IOV BAR resources > unallocatable. Rename it to reflect what it actually does. > > Signed-off-by: Oliver O'Halloran Reviewed-by: Alexey Kardashevskiy > --- >

Re: [PATCH 08/15] powerpc/powernv/sriov: Simplify used window tracking

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > No need for the multi-dimensional arrays, just use a bitmap. > > Signed-off-by: Oliver O'Halloran > --- > arch/powerpc/platforms/powernv/pci-sriov.c | 48 +++--- > arch/powerpc/platforms/powernv/pci.h | 7 +++- > 2 files

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Kjetil Oftedal
On 14/07/2020, Bjorn Helgaas wrote: >> >> a) callers of the high-level config space accessors >>pci_{write,read}_config_{byte,word,dword}, mostly in device >>drivers. >> b) low-level implementation of the config space accessors >> through struct pci_ops >> c) all other occurrences of

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Arnd Bergmann
On Tue, Jul 14, 2020 at 8:45 PM Bjorn Helgaas wrote: > On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote: > > On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa > > Starting with a), my first question is whether any high-level > > drivers even need to care about errors from these

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-07-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #289937|0 |1 is obsolete|

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Bjorn Helgaas
[+cc Kjetil] On Wed, Jul 15, 2020 at 12:01:56AM +0200, Arnd Bergmann wrote: > On Tue, Jul 14, 2020 at 8:45 PM Bjorn Helgaas wrote: > > On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote: > > > On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa > > > Starting with a), my first

Re: [PATCH 06/15] powerpc/powernv/sriov: Explain how SR-IOV works on PowerNV

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > SR-IOV support on PowerNV is a byzantine maze of hooks. I have no idea > how anyone is supposed to know how it works except through a lot of > stuffering. Write up some docs about the overall story to help out > the next sucker^Wperson who needs

Re: [PATCH v3 1/9] powerpc/watchpoint: Fix 512 byte boundary limit

2020-07-14 Thread Jordan Niethe
On Wed, Jul 8, 2020 at 2:53 PM Ravi Bangoria wrote: > > Milton Miller reported that we are aligning start and end address to > wrong size SZ_512M. It should be SZ_512. Fix that. > > While doing this change I also found a case where ALIGN() comparison > fails. Within a given aligned range, ALIGN()

Re: [PATCH v8 5/8] powerpc/vdso: Prepare for switching VDSO to generic C implementation.

2020-07-14 Thread Michael Ellerman
Christophe Leroy writes: > Prepare for switching VDSO to generic C implementation in following > patch. Here, we: > - Modify __get_datapage() to take an offset > - Prepare the helpers to call the C VDSO functions > - Prepare the required callbacks for the C VDSO functions > - Prepare the

Re: [PATCH 03/15] powerpc/powernv/pci: Add explicit tracking of the DMA setup state

2020-07-14 Thread Oliver O'Halloran
On Tue, Jul 14, 2020 at 5:21 PM Alexey Kardashevskiy wrote: > > On 14/07/2020 15:58, Oliver O'Halloran wrote: > > On Tue, Jul 14, 2020 at 3:37 PM Alexey Kardashevskiy wrote: > >> > >> On 10/07/2020 15:23, Oliver O'Halloran wrote: > >>> This also means the only remaining user of the old "DMA

Re: [PATCH 09/15] powerpc/powernv/sriov: Factor out M64 BAR setup

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > The sequence required to use the single PE BAR mode is kinda janky and > requires a little explanation. The API was designed with P7-IOC style > windows where the setup process is something like: > > 1. Configure the window start / end address >

[powerpc:next-test] BUILD SUCCESS 17babc2734a55cdf4a678d572f316280b820202b

2020-07-14 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: 17babc2734a55cdf4a678d572f316280b820202b powerpc/fadump: fix race between pstore write and fadump crash trigger elapsed time: 720m configs tested: 104 configs skipped: 8 The following

Re: [PATCH 05/13] cpufreq/arch: powerpc: pasemi: Move prototypes to shared header

2020-07-14 Thread Viresh Kumar
On 14-07-20, 15:50, Lee Jones wrote: > If function callers and providers do not share the same prototypes the > compiler complains of missing prototypes. Fix this by moving the > already existing prototypes out to a mutually convenient location. > > Fixes the following W=1 kernel build

Re: [PATCH 11/15] powerpc/powernv/sriov: Drop iov->pe_num_map[]

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > Currently the iov->pe_num_map[] does one of two things depending on > whether single PE mode is being used or not. When it is, this contains an > array which maps a vf_index to the corresponding PE number. When single PE > mode is not being used

Re: [PATCH 12/15] powerpc/powernv/sriov: De-indent setup and teardown

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > Remove the IODA2 PHB checks. We already assume IODA2 in several places so > there's not much point in wrapping most of the setup and teardown process > in an if block. > > Signed-off-by: Oliver O'Halloran > --- >

Re: [PATCH 3/3] ASoC: fsl-asoc-card: Support Headphone and Microphone Jack detection

2020-07-14 Thread Shengjiu Wang
On Wed, Jul 15, 2020 at 5:16 AM Nicolin Chen wrote: > > Hi Shengjiu, > > The whole series looks good to me. Just a couple of small > questions inline: > > On Tue, Jul 14, 2020 at 05:05:36PM +0800, Shengjiu Wang wrote: > > Use asoc_simple_init_jack function from simple card to implement > > the

Re: [PATCH 12/15] powerpc/powernv/sriov: De-indent setup and teardown

2020-07-14 Thread Alexey Kardashevskiy
On 15/07/2020 14:21, Oliver O'Halloran wrote: > On Wed, Jul 15, 2020 at 2:00 PM Alexey Kardashevskiy wrote: >> >> >> or we could just skip setting >> >> ppc_md.pcibios_sriov_enable = pnv_pcibios_sriov_enable; >> >> for uninteresting platforms in pnv_pci_init_ioda_phb(). > > I don't think so.

Re: [PATCH 12/15] powerpc/powernv/sriov: De-indent setup and teardown

2020-07-14 Thread Alexey Kardashevskiy
On 15/07/2020 14:46, Oliver O'Halloran wrote: > On Wed, Jul 15, 2020 at 2:41 PM Alexey Kardashevskiy wrote: >> >> >> >> On 15/07/2020 14:21, Oliver O'Halloran wrote: >>> On Wed, Jul 15, 2020 at 2:00 PM Alexey Kardashevskiy wrote: or we could just skip setting

Re: [v3 1/5] KVM: PPC: Book3S HV: Disable page merging in H_SVM_INIT_START

2020-07-14 Thread Ram Pai
On Mon, Jul 13, 2020 at 10:59:41AM +0530, Bharata B Rao wrote: > On Sat, Jul 11, 2020 at 02:13:43AM -0700, Ram Pai wrote: > > Merging of pages associated with each memslot of a SVM is > > disabled the page is migrated in H_SVM_PAGE_IN handler. > > > > This operation should have been done much

Re: [PATCH v3 2/9] powerpc/watchpoint: Fix DAWR exception constraint

2020-07-14 Thread Ravi Bangoria
Hi Jordan, @@ -536,7 +538,12 @@ static bool check_dawrx_constraints(struct pt_regs *regs, int type, if (OP_IS_LOAD(type) && !(info->type & HW_BRK_TYPE_READ)) return false; - if (OP_IS_STORE(type) && !(info->type & HW_BRK_TYPE_WRITE)) + /* +* The

Re: [PATCH 12/15] powerpc/powernv/sriov: De-indent setup and teardown

2020-07-14 Thread Oliver O'Halloran
On Wed, Jul 15, 2020 at 2:41 PM Alexey Kardashevskiy wrote: > > > > On 15/07/2020 14:21, Oliver O'Halloran wrote: > > On Wed, Jul 15, 2020 at 2:00 PM Alexey Kardashevskiy wrote: > >> > >> > >> or we could just skip setting > >> > >> ppc_md.pcibios_sriov_enable = pnv_pcibios_sriov_enable; > >> >

Re: [PATCH 15/15] powerpc/powernv/sriov: Make single PE mode a per-BAR setting

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > Using single PE BARs to map an SR-IOV BAR is really a choice about what > strategy to use when mapping a BAR. It doesn't make much sense for this to > be a global setting since a device might have one large BAR which needs to > be mapped with

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Benjamin Herrenschmidt
On Tue, 2020-07-14 at 18:46 -0500, Bjorn Helgaas wrote: > Yes. I have no problem with that. There are a few cases where it's > important to check for errors, e.g., we read a status register and do > something based on a bit being set. A failure will return all bits > set, and we may do the

Re: [PATCH 10/15] powerpc/powernv/pci: Refactor pnv_ioda_alloc_pe()

2020-07-14 Thread Oliver O'Halloran
On Wed, Jul 15, 2020 at 12:29 PM Alexey Kardashevskiy wrote: > > > > On 10/07/2020 15:23, Oliver O'Halloran wrote: > > Rework the PE allocation logic to allow allocating blocks of PEs rather > > than individually. We'll use this to allocate contigious blocks of PEs for > > the SR-IOVs. > > The

[PATCH -next] powerpc/xive: Remove unused inline function xive_kexec_teardown_cpu()

2020-07-14 Thread YueHaibing
commit e27e0a94651e ("powerpc/xive: Remove xive_kexec_teardown_cpu()") left behind this, remove it. Signed-off-by: YueHaibing --- arch/powerpc/include/asm/xive.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h index

Re: [PATCH 10/15] powerpc/powernv/pci: Refactor pnv_ioda_alloc_pe()

2020-07-14 Thread Alexey Kardashevskiy
On 15/07/2020 12:53, Oliver O'Halloran wrote: > On Wed, Jul 15, 2020 at 12:29 PM Alexey Kardashevskiy wrote: >> >> >> >> On 10/07/2020 15:23, Oliver O'Halloran wrote: >>> Rework the PE allocation logic to allow allocating blocks of PEs rather >>> than individually. We'll use this to allocate

Re: [PATCH 05/13] cpufreq/arch: powerpc: pasemi: Move prototypes to shared header

2020-07-14 Thread Olof Johansson
On Tue, Jul 14, 2020 at 7:50 AM Lee Jones wrote: > > If function callers and providers do not share the same prototypes the > compiler complains of missing prototypes. Fix this by moving the > already existing prototypes out to a mutually convenient location. > > Fixes the following W=1 kernel

Re: [PATCH -next] cpufreq: powernv: Make some symbols static

2020-07-14 Thread Viresh Kumar
On 14-07-20, 22:23, Wei Yongjun wrote: > The sparse tool complains as follows: > > drivers/cpufreq/powernv-cpufreq.c:88:1: warning: > symbol 'pstate_revmap' was not declared. Should it be static? > drivers/cpufreq/powernv-cpufreq.c:383:18: warning: > symbol

Re: [PATCH 05/13] cpufreq/arch: powerpc: pasemi: Move prototypes to shared header

2020-07-14 Thread Viresh Kumar
On 14-07-20, 20:49, Olof Johansson wrote: > On Tue, Jul 14, 2020 at 8:07 PM Viresh Kumar wrote: > > > > On 14-07-20, 15:50, Lee Jones wrote: > > > If function callers and providers do not share the same prototypes the > > > compiler complains of missing prototypes. Fix this by moving the > > >

Re: [PATCH v3 05/12] powerpc/drmem: make lmb walk a bit more flexible

2020-07-14 Thread Thiago Jung Bauermann
Hari Bathini writes: > @@ -534,7 +537,7 @@ static int __init early_init_dt_scan_memory_ppc(unsigned > long node, > #ifdef CONFIG_PPC_PSERIES > if (depth == 1 && > strcmp(uname, "ibm,dynamic-reconfiguration-memory") == 0) { > - walk_drmem_lmbs_early(node,

Re: [PATCH 13/15] powerpc/powernv/sriov: Move M64 BAR allocation into a helper

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > I want to refactor the loop this code is currently inside of. Hoist it on > out. > > Signed-off-by: Oliver O'Halloran Reviewed-by: Alexey Kardashevskiy > --- > arch/powerpc/platforms/powernv/pci-sriov.c | 31 ++ > 1

Re: [v3 3/5] KVM: PPC: Book3S HV: migrate remaining normal-GFNs to secure-GFNs in H_SVM_INIT_DONE

2020-07-14 Thread Ram Pai
On Mon, Jul 13, 2020 at 03:15:06PM +0530, Bharata B Rao wrote: > On Sat, Jul 11, 2020 at 02:13:45AM -0700, Ram Pai wrote: > > The Ultravisor is expected to explicitly call H_SVM_PAGE_IN for all the > > pages > > > > if (!(*mig.src & MIGRATE_PFN_MIGRATE)) { > > - ret = -1; > > +

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Masami Hiramatsu
On Tue, 14 Jul 2020 10:03:45 -0400 Steven Rostedt wrote: > On Tue, 14 Jul 2020 14:33:14 +0100 > Mark Rutland wrote: > > > > Should work for all cases. Yes, we might then want something like a per > > > arch: > > > > > > {BPF,FTRACE,KPROBE}_TEXT_TYPE > > > > ... at that point why not: > >

Re: [PATCH 10/15] powerpc/powernv/pci: Refactor pnv_ioda_alloc_pe()

2020-07-14 Thread Alexey Kardashevskiy
On 10/07/2020 15:23, Oliver O'Halloran wrote: > Rework the PE allocation logic to allow allocating blocks of PEs rather > than individually. We'll use this to allocate contigious blocks of PEs for > the SR-IOVs. The patch does not do just this, it also adds missing mutexes (which is good) but

Re: [PATCH v3 2/9] powerpc/watchpoint: Fix DAWR exception constraint

2020-07-14 Thread Jordan Niethe
On Wed, Jul 8, 2020 at 2:52 PM Ravi Bangoria wrote: > > Pedro Miraglia Franco de Carvalho noticed that on p8, DAR value is > inconsistent with different type of load/store. Like for byte,word > etc. load/stores, DAR is set to the address of the first byte of > overlap between watch range and real

Re: [PATCH 05/13] cpufreq/arch: powerpc: pasemi: Move prototypes to shared header

2020-07-14 Thread Olof Johansson
On Tue, Jul 14, 2020 at 8:07 PM Viresh Kumar wrote: > > On 14-07-20, 15:50, Lee Jones wrote: > > If function callers and providers do not share the same prototypes the > > compiler complains of missing prototypes. Fix this by moving the > > already existing prototypes out to a mutually

  1   2   >