Re: [PATCH] powerpc: Use octal numbers for file permissions

On Mon, Jan 16, 2017 at 11:21:52AM +1100, Russell Currey wrote: > On Fri, 2017-01-13 at 13:41 +0530, Balbir Singh wrote: > > On Thu, Jan 12, 2017 at 02:54:13PM +1100, Russell Currey wrote: > > > Symbolic macros are unintuitive and hard to read, whereas octal constants > > > are much easier to

Re: [PATCH v5 4/4] powerpc/mm: unstub radix__vmemmap_remove_mapping()

On Mon, Jan 16, 2017 at 01:07:46PM -0600, Reza Arbab wrote: > Use remove_pagetable() and friends for radix vmemmap removal. > > We do not require the special-case handling of vmemmap done in the x86 > versions of these functions. This is because vmemmap_free() has already > freed the mapped

Re: [PATCH v5 3/4] powerpc/mm: add radix__remove_section_mapping()

On Mon, Jan 16, 2017 at 01:07:45PM -0600, Reza Arbab wrote: > Tear down and free the four-level page tables of physical mappings > during memory hotremove. > > Borrow the basic structure of remove_pagetable() and friends from the > identically-named x86 functions. Reduce the frequency of tlb

Re: [PATCH v5 2/4] powerpc/mm: add radix__create_section_mapping()

On Mon, Jan 16, 2017 at 01:07:44PM -0600, Reza Arbab wrote: > Wire up memory hotplug page mapping for radix. Share the mapping > function already used by radix_init_pgtable(). > > Signed-off-by: Reza Arbab > --- Acked-by: Balbir Singh

Re: [PATCH v5 1/4] powerpc/mm: refactor radix physical page mapping

On Mon, Jan 16, 2017 at 01:07:43PM -0600, Reza Arbab wrote: > Move the page mapping code in radix_init_pgtable() into a separate > function that will also be used for memory hotplug. > > The current goto loop progressively decreases its mapping size as it > covers the tail of a range whose end is

Re: [PATCH] powerpc/icp-opal: Fix missing KVM case and harden replay

On Mon, Jan 16, 2017 at 11:58:53AM -0600, Benjamin Herrenschmidt wrote: > The icp-opal call is missing the code from icp-native to recover > interrupts snatched by KVM. Without that, when running KVM, we can > get into a situation where an interrupt is lost and the CPU stuck > with an elevated

Re: [PATCH] powerpc/perf: use MSR to report privilege level on P9 DD1

On Tuesday 17 January 2017 11:16 AM, Michael Ellerman wrote: Madhavan Srinivasan writes: "use_siar" variable is primarily used for deciding the sampled address and the privilege level to be reported for a sample. perf_read_regs() function updates the "use_siar" and

Re: [PATCH] powerpc/perf: use MSR to report privilege level on P9 DD1

Madhavan Srinivasan writes: > "use_siar" variable is primarily used for deciding the sampled address > and the privilege level to be reported for a sample. perf_read_regs() > function updates the "use_siar" and "regs->result" based on the pmu > flags along with other

[PATCH] powerpc: Disable HFSCR:TM if TM not supported

Otherwise KVM guests might mess with it even when told not to causing bad thing interrupts in the host Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/setup_64.c | 10 ++ 1 file changed, 10 insertions(+) diff --git

Re: Normal service will resume shortly ...

On Mon, Jan 16, 2017 at 08:33:09PM +1100, Michael Ellerman wrote: >Hi folks, > >I'm back from paternity leave, and will start processing patches in the >next day or two. > >If you've sent a fix that should go into 4.10 that hasn't been merged >yet, please feel free to reply to this message giving

Re: Normal service will resume shortly ...

On Mon, Jan 16, 2017 at 08:33:09PM +1100, Michael Ellerman wrote: If you've sent a fix that should go into 4.10 that hasn't been merged yet, please feel free to reply to this message giving me a pointer to it. Welcome back! I think this should go into 4.10:

Re: [PATCH] net: constify mdiobb_ops structures

Hello! On 01/13/2017 09:02 PM, Bhumika Goyal wrote: Declare mdiobb_ops structures as const as they are only stored in the ops field of mdiobb_ctrl structures. This field is of type const, so mdiobb_ops structures having this property can be declared const too. Done using Coccinelle: [...]

[PATCH 2/2] of: Add function for generating a DT modalias with a newline

The modalias sysfs attr is lacking a newline for DT aliases on platform devices. The macio and ibmebus correctly add the newline, but open code it. Introduce a new function, of_device_modalias(), that fills the buffer with the modalias including the newline and update users of the old

[PATCH v5 3/4] powerpc/mm: add radix__remove_section_mapping()

Tear down and free the four-level page tables of physical mappings during memory hotremove. Borrow the basic structure of remove_pagetable() and friends from the identically-named x86 functions. Reduce the frequency of tlb flushes and page_table_lock spinlocks by only doing them in the outermost

[PATCH v5 4/4] powerpc/mm: unstub radix__vmemmap_remove_mapping()

Use remove_pagetable() and friends for radix vmemmap removal. We do not require the special-case handling of vmemmap done in the x86 versions of these functions. This is because vmemmap_free() has already freed the mapped pages, and calls us with an aligned address range. So, add a few failsafe

[PATCH v5 2/4] powerpc/mm: add radix__create_section_mapping()

Wire up memory hotplug page mapping for radix. Share the mapping function already used by radix_init_pgtable(). Signed-off-by: Reza Arbab --- arch/powerpc/include/asm/book3s/64/radix.h | 4 arch/powerpc/mm/pgtable-book3s64.c | 2 +-

[PATCH v5 1/4] powerpc/mm: refactor radix physical page mapping

Move the page mapping code in radix_init_pgtable() into a separate function that will also be used for memory hotplug. The current goto loop progressively decreases its mapping size as it covers the tail of a range whose end is unaligned. Change this to a for loop which can do the same for both

[PATCH v5 0/4] powerpc/mm: enable memory hotplug on radix

Do the plumbing needed for memory hotplug on systems using radix pagetables, borrowing from existing vmemmap and x86 code. This passes basic verification of plugging and removing memory, but this stuff is tricky and I'd appreciate extra scrutiny of the series for correctness--in particular, the

Re: [PATCH] net: constify mdiobb_ops structures

From: Bhumika Goyal Date: Fri, 13 Jan 2017 23:32:26 +0530 > Declare mdiobb_ops structures as const as they are only stored in the > ops field of mdiobb_ctrl structures. This field is of type const, so > mdiobb_ops structures having this property can be declared const too.

Re: [PATCH 1/3] powerpc: bpf: remove redundant check for non-null image

I'm assuming these patches will go via the powerpc tree. If you want them to go into net-next, I kindly ask that you always explicitly say so, and furthermore always submit a patch series with a proper "[PATCH 0/N] ..." header posting. Thanks.

[PATCH] powerpc/icp-opal: Fix missing KVM case and harden replay

The icp-opal call is missing the code from icp-native to recover interrupts snatched by KVM. Without that, when running KVM, we can get into a situation where an interrupt is lost and the CPU stuck with an elevated CPPR. Also harden replay by always checking the return from opal_int_eoi

Re: [PATCH] powerpc/icp-opal: Fix missing KVM case and harden replay

On Mon, 2017-01-16 at 21:37 +0530, Balbir Singh wrote: > ?? > > > > > @@ -39,7 +40,2 Ah evolution bug ... fixed upstream but fix hasn't made it to Fedora yet. I'll attach in the meantime. Cheers, Ben.

Re: [PATCH] powerpc/mm/hugetlb: Don't panic if we don't find the default huge page size

Anshuman Khandual writes: > On 12/13/2016 07:34 PM, Aneesh Kumar K.V wrote: >> generic hugetlbfs can handle that condition correctly. With HPAGE_SHIFT = 0 > > Need to add some context here. "That condition" refers to something without > first mentioning it. It is

Re: llist code relies on undefined behaviour, upsets llvm/clang

On Mon, Jan 16, 2017 at 02:34:43PM +, David Laight wrote: > From: Anton Blanchard > > Sent: 15 January 2017 21:36 > > I was debugging a hang on a ppc64le kernel built with clang, and it > > looks to be undefined behaviour with pointer wrapping in the llist code. > > > > A test case is below.

Re: [PATCH] powerpc/icp-opal: Fix missing KVM case and harden replay

On Sun, Jan 15, 2017 at 08:19:31PM -0600, Benjamin Herrenschmidt wrote: > The icp-opal call is missing the code from icp-native to recover > interrupts snatched by KVM. Without that, when running KVM, we can > get into a situation where an interrupt is lost and the CPU stuck > with an elevated

Re: [PATCH 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions

On Mon, Jan 16, 2017 at 11:31:23AM +0530, Kishon Vijay Abraham I wrote: > Actually not all devices have hardcoded headers. E.g the platform I'm using > doesn't have hardcoded headers and it can be configured based on the function > the user would like to use. If the devices are hardcoded, then

RE: llist code relies on undefined behaviour, upsets llvm/clang

From: Anton Blanchard > Sent: 15 January 2017 21:36 > I was debugging a hang on a ppc64le kernel built with clang, and it > looks to be undefined behaviour with pointer wrapping in the llist code. > > A test case is below. llist_for_each_entry() does container_of() on a > NULL pointer, which

Re: [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files

Às 11:30 AM de 1/16/2017, Kishon Vijay Abraham I escreveu: > Hi Joao, > > On Monday 16 January 2017 03:57 PM, Joao Pinto wrote: >> >> Hi, >> >> Às 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu: >>> Hi Joao, >>> >>> On Friday 13 January 2017 10:19 PM, Joao Pinto wrote: Às 10:26 AM de

Re: llist code relies on undefined behaviour, upsets llvm/clang

2017-01-16 15:53 GMT+03:00 Peter Zijlstra : > On Mon, Jan 16, 2017 at 10:42:29PM +1100, Anton Blanchard wrote: >> Hi Peter, >> >> > Last I checked I couldn't build a x86_64 kernel with llvm. So no, not >> > something I've ever ran into. >> > >> > Also, I would argue that this

Re: llist code relies on undefined behaviour, upsets llvm/clang

On Mon, Jan 16, 2017 at 10:42:29PM +1100, Anton Blanchard wrote: > Hi Peter, > > > Last I checked I couldn't build a x86_64 kernel with llvm. So no, not > > something I've ever ran into. > > > > Also, I would argue that this is broken in llvm, the kernel very much > > relies on things like this

Re: llist code relies on undefined behaviour, upsets llvm/clang

Hi Peter, > Last I checked I couldn't build a x86_64 kernel with llvm. So no, not > something I've ever ran into. > > Also, I would argue that this is broken in llvm, the kernel very much > relies on things like this all over the place. Sure, we're way outside > of what the C language spec says,

Re: [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files

Hi Joao, On Monday 16 January 2017 03:57 PM, Joao Pinto wrote: > > Hi, > > Às 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu: >> Hi Joao, >> >> On Friday 13 January 2017 10:19 PM, Joao Pinto wrote: >>> Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu: Split

Re: [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files

Hi, Às 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu: > Hi Joao, > > On Friday 13 January 2017 10:19 PM, Joao Pinto wrote: >> Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu: >>> Split pcie-designware.c into pcie-designware-host.c that contains >>> the host specific parts of

Re: [PATCH 09/37] PCI: dwc: designware: Parse *num-lanes* property in dw_pcie_setup_rc

Hi, Às 5:19 AM de 1/16/2017, Kishon Vijay Abraham I escreveu: > Hi, > > On Friday 13 January 2017 10:43 PM, Joao Pinto wrote: >> Hi, >> >> Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu: >>> *num-lanes* dt property is parsed in dw_pcie_host_init. However >>> *num-lanes* property is

Normal service will resume shortly ...

Hi folks, I'm back from paternity leave, and will start processing patches in the next day or two. If you've sent a fix that should go into 4.10 that hasn't been merged yet, please feel free to reply to this message giving me a pointer to it. cheers

Re: llist code relies on undefined behaviour, upsets llvm/clang

On Mon, Jan 16, 2017 at 08:36:00AM +1100, Anton Blanchard wrote: > Hi, > > I was debugging a hang on a ppc64le kernel built with clang, and it > looks to be undefined behaviour with pointer wrapping in the llist code. > > A test case is below. llist_for_each_entry() does container_of() on a >

[PATCH RFC] powerpc/32: fix handling of stack protector with recent GCC

Since 2005, powerpc GCC doesn't manage anymore __stack_chk_guard as a global variable but as some value located at -0x7008(r2) In the Linux kernel, r2 is used as a pointer to current task struct. This patch changes the meaning of r2 when stack protector is activated: - current is taken from