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

On Wed, 15 Jul 2020, Viresh Kumar wrote: > 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: war

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

On Wed, Jul 15, 2020 at 1:46 AM Bjorn Helgaas wrote: So something like: > > void pci_read_config_word(struct pci_dev *dev, int where, u16 *val) > > and where we used to return anything non-zero, we just set *val = ~0 > instead? I think we do that already in most, maybe all, cases. Right, thi

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

On Tue, Jul 14, 2020 at 11:33 PM Lee Jones wrote: > > On Tue, 14 Jul 2020, Olof Johansson wrote: > > > 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 m

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

On Wed, 15 Jul 2020 10:50:40 +0800 YueHaibing wrote: > commit e27e0a94651e ("powerpc/xive: Remove xive_kexec_teardown_cpu()") > left behind this, remove it. > > Signed-off-by: YueHaibing > --- Reviewed-by: Greg Kurz > arch/powerpc/include/asm/xive.h | 1 - > 1 file changed, 1 deletion(-) >

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

On Wed, Jul 15, 2020 at 12:14:01PM +0800, Shengjiu Wang wrote: > 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: >

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

On 15-07-20, 07:36, Lee Jones wrote: > I searched for "include.*platforms/" in drivers/, and was scared off > this method since no one else does this. Yeah its not right for generic drivers, but this is very much platform specific so it is fine here. -- viresh

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

On Tue, 14 Jul 2020, 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 05/13] cpufreq/arch: powerpc: pasemi: Move prototypes to shared header

On Tue, 14 Jul 2020, Olof Johansson wrote: > 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 conv

[powerpc:merge] BUILD SUCCESS 93c756af92e11df5c1a8be7a8360f28a97f7ad3f

allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a016-20200714 i386 randconfig-a011-20200714 i386 randconfig-a015-20200714 i386

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

> On 14-Jul-2020, at 11:38 AM, Michael Ellerman wrote: > > 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,

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

On Wed, Jul 15, 2020 at 3:24 PM Alexey Kardashevskiy wrote: > > > > @@ -158,9 +157,9 @@ static void pnv_pci_ioda_fixup_iov_resources(struct > > pci_dev *pdev) > > goto disable_iov; > > pdev->dev.archdata.iov_data = iov; > > > > + /* FIXME: totalvfs > phb->ioda.total_pe_num

Re: [PATCH v2 01/10] powerpc/perf: Add support for ISA3.1 PMU SPRs

> On 13-Jul-2020, at 6:20 PM, Michael Ellerman wrote: > > Athira Rajeev > writes: >>> On 08-Jul-2020, at 4:32 PM, Michael Ellerman wrote: >>> >>> Athira Rajeev writes: >>> ... diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/cor

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

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 15/15] powerpc/powernv/sriov: Make single PE mode a per-BAR setting

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 singl

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

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 earl

Re: [v3 4/5] KVM: PPC: Book3S HV: retry page migration before erroring-out H_SVM_PAGE_IN

On Mon, Jul 13, 2020 at 03:20:43PM +0530, Bharata B Rao wrote: > On Sat, Jul 11, 2020 at 02:13:46AM -0700, Ram Pai wrote: > > The page requested for page-in; sometimes, can have transient > > references, and hence cannot migrate immediately. Retry a few times > > before returning error. > > As I n

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

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 12/15] powerpc/powernv/sriov: De-indent setup and teardown

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 ppc_md.pc

Re: [PATCH 14/15] powerpc/powernv/sriov: Refactor M64 BAR setup

On 10/07/2020 15:23, Oliver O'Halloran wrote: > Split up the logic so that we have one branch that handles setting up a > segmented window and another that handles setting up single PE windows for > each VF. > > Signed-off-by: Oliver O'Halloran Reviewed-by: Alexey Kardashevskiy > --- > T

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

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 12/15] powerpc/powernv/sriov: De-indent setup and teardown

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. p

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

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. ppc_md is per-platform, not per-PHB andw e still have to deal w

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

On Wed, Jul 15, 2020 at 8:03 AM Arnd Bergmann wrote: > > - Most error checking is static: PCIBIOS_BAD_REGISTER_NUMBER > only happens if you pass an invalid register number, but most > callers pass a compile-time constant register number that is > known to be correct, or the driver would neve

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

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 Hea

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

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 Ca

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

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 fil

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

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 > --- > arch/powerpc/platforms/powernv/p

Re: [PATCH] powerpc: Fix inconsistent function names

YueHaibing writes: > The stub helpers name should be consistent with prototypes. > > mm_context_add_vas_windows() --> mm_context_add_vas_window() > mm_context_remove_vas_windows() --> mm_context_remove_vas_window() > > Fixes: c420644c0a8f ("powerpc: Use mm_context vas_windows counter to issue >

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

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 > > > al

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

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, early_init

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

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 convenient

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

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 'cpufreq_freq_attr_cpuinfo_nominal_fre

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

On 15/07/2020 11:38, Oliver O'Halloran wrote: > 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 als

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

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 th

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

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 bu

[PATCH] powerpc: Fix inconsistent function names

The stub helpers name should be consistent with prototypes. mm_context_add_vas_windows() --> mm_context_add_vas_window() mm_context_remove_vas_windows() --> mm_context_remove_vas_window() Fixes: c420644c0a8f ("powerpc: Use mm_context vas_windows counter to issue CP_ABORT") Signed-off-by: YueHaib

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

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 co

[PATCH -next] powerpc/smp: Remove unused inline functions

commit 441c19c8a290 ("powerpc/kvm/book3s_hv: Rework the secondary inhibit code") left behind this, remove it. Signed-off-by: YueHaibing --- arch/powerpc/include/asm/smp.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h index 49

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

On 14-07-20, 15:50, Lee Jones wrote: > 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

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

On 14-07-20, 15:50, Lee Jones wrote: > 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

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

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 warning(s)

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

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 d08ea11b271

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

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 pat

[powerpc:fixes-test] BUILD SUCCESS b710d27bf72068b15b2f0305d825988183e2ff28

allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a001-20200714 i386 randconfig-a005-20200714 i386 randconfig-a002-20200714 i386 randconfig-a006-20200714 i386

[powerpc:next-test] BUILD SUCCESS 17babc2734a55cdf4a678d572f316280b820202b

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 config

Re: [PATCH v3 04/12] ppc64/kexec_file: avoid stomping memory used by special regions

Hari Bathini writes: > diff --git a/arch/powerpc/include/asm/crashdump-ppc64.h > b/arch/powerpc/include/asm/crashdump-ppc64.h > new file mode 100644 > index 000..90deb46 > --- /dev/null > +++ b/arch/powerpc/include/asm/crashdump-ppc64.h > @@ -0,0 +1,10 @@ > +/* SPDX-License-Identifier: GPL

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

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 s

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

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 wrong

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

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 09/15] powerpc/powernv/sriov: Factor out M64 BAR setup

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 > 2

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

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 structure.

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

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 detec

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

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 > > --- a/arch/powerpc/platforms/powernv/pci.

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

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 Weigh

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

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 c

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

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 clocksour

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

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 07/15] powerpc/powernv/sriov: Rename truncate_iov

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 > --- > arch/powerpc/platforms/powernv/pc

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

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 to

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

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 >>>

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

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 --- arch/powerpc/platforms/pseries/hotplug-me

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

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: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

[+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 question

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

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

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

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

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 func

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

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 C

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

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 Speak

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

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: [PATCH v3 01/12] kexec_file: allow archs to handle special regions while locating memory hole

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 tryi

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

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 pr

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

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 regular

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

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 e

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

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 kpr

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

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 e

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

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 s

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

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 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

+++ 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 requi

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

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' argument.

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

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 e

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

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 architec

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

[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 include/linux/pci.

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

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 good

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

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 'last_lpst

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

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: war

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

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’ [-Wmissing-prototype

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

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 --- driv

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

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? drivers/

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

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, bit-nr)

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

> 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 Lutom

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

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 allo

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

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 pa

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

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 be

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

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 exe

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

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 th

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

On Tue, Jul 14, 2020 at 10:53:46AM +0100, Russell King - ARM Linux admin wrote: > 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

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

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 executable memory is broader and doesn't have these > restrictions.

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

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 patch suggests that there are other reasons why conflating > > > allocation of module space an

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

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 ex

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

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 all

  1   2   >