Re: [PATCH v1 1/2] KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE (nested case only)
On Fri, Dec 11, 2020 at 12:16:39PM +1100, David Gibson wrote: > On Thu, Dec 10, 2020 at 09:54:18AM +0530, Bharata B Rao wrote: > > On Wed, Dec 09, 2020 at 03:15:42PM +1100, Paul Mackerras wrote: > > > On Mon, Oct 19, 2020 at 04:56:41PM +0530, Bharata B Rao wrote: > > > > Implements H_RPT_INVALIDATE hcall and supports only nested case > > > > currently. > > > > > > > > A KVM capability KVM_CAP_RPT_INVALIDATE is added to indicate the > > > > support for this hcall. > > > > > > I have a couple of questions about this patch: > > > > > > 1. Is this something that is useful today, or is it something that may > > > become useful in the future depending on future product plans? In > > > other words, what advantage is there to forcing L2 guests to use this > > > hcall instead of doing tlbie themselves? > > > > H_RPT_INVALIDATE will replace the use of the existing H_TLB_INVALIDATE > > for nested partition scoped invalidations. Implementations that want to > > off-load invalidations to the host (when GTSE=0) would have to bother > > about only one hcall (H_RPT_INVALIDATE) > > > > > > > > 2. Why does it need to be added to the default-enabled hcall list? > > > > > > There is a concern that if this is enabled by default we could get the > > > situation where a guest using it gets migrated to a host that doesn't > > > support it, which would be bad. That is the reason that all new > > > things like this are disabled by default and only enabled by userspace > > > (i.e. QEMU) in situations where we can enforce that it is available on > > > all hosts to which the VM might be migrated. > > > > As you suggested privately, I am thinking of falling back to > > H_TLB_INVALIDATE in case where this new hcall fails due to not being > > present. That should address the migration case that you mention > > above. With that and leaving the new hcall enabled by default > > is good okay? > > No. Assuming that guests will have some fallback is not how the qemu > migration compatibility model works. If we specify an old machine > type, we need to provide the same environment that the older host > would have. I misunderstood what this patchset is about when I first looked at it. H_RPT_INVALIDATE has two separate functions; one is to do process-scoped invalidations for a guest when LPCR[GTSE] = 0 (i.e., when the guest is not permitted to do tlbie itself), and the other is to do partition-scoped invalidations that an L1 hypervisor needs to do on behalf of an L2 guest. The second function is a replacement and standardization of the existing H_TLB_INVALIDATE which was introduced with the nested virtualization code (using a hypercall number from the platform-specific range). This patchset only implements the second function, not the first. The first function remains unimplemented in KVM at present. Given that QEMU will need changes for a guest to be able to exploit H_RPT_INVALIDATE (at a minimum, adding a device tree property), it doesn't seem onerous for QEMU to have to enable the hcall with KVM_CAP_PPC_ENABLE_HCALL. I think that the control on whether the hcall is handled in KVM along with the control on nested hypervisor function provides adequate control for QEMU without needing a writable capability. The read-only capability to say whether the hcall exists does seem useful. Given all that, I'm veering towards taking Bharata's patchset pretty much as-is, minus the addition of H_RPT_INVALIDATE to the default-enabled set. Paul.
[PATCH] powerpc/powernv: Rate limit opal-elog read failure message
Sometimes we can't read an error log from OPAL, and we print an error
message accordingly. But the OPAL userspace tools seem to like retrying a
lot, in which case we flood the kernel log with a lot of messages.
Change pr_err() to pr_err_ratelimited() to help with this.
Signed-off-by: Andrew Donnellan
---
arch/powerpc/platforms/powernv/opal-elog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c
b/arch/powerpc/platforms/powernv/opal-elog.c
index 37b380eef41a..5821b0fa8614 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -171,8 +171,8 @@ static ssize_t raw_attr_read(struct file *filep, struct
kobject *kobj,
opal_rc = opal_read_elog(__pa(elog->buffer),
elog->size, elog->id);
if (opal_rc != OPAL_SUCCESS) {
- pr_err("ELOG: log read failed for log-id=%llx\n",
- elog->id);
+ pr_err_ratelimited("ELOG: log read failed for
log-id=%llx\n",
+ elog->id);
kfree(elog->buffer);
elog->buffer = NULL;
return -EIO;
--
2.20.1
[powerpc:next] BUILD SUCCESS 0be47634db0baa9e91c7e635e7e73355d6a5cf43
defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparc defconfig i386 tinyconfig i386defconfig sparcallyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201209 i386 randconfig-a005-20201209 i386 randconfig-a001-20201209 i386 randconfig-a002-20201209 i386 randconfig-a006-20201209 i386 randconfig-a003-20201209 i386 randconfig-a001-20201210 i386 randconfig-a004-20201210 i386 randconfig-a003-20201210 i386 randconfig-a002-20201210 i386 randconfig-a005-20201210 i386 randconfig-a006-20201210 x86_64 randconfig-a016-20201209 x86_64 randconfig-a012-20201209 x86_64 randconfig-a013-20201209 x86_64 randconfig-a014-20201209 x86_64 randconfig-a015-20201209 x86_64 randconfig-a011-20201209 i386 randconfig-a013-20201209 i386 randconfig-a014-20201209 i386 randconfig-a011-20201209 i386 randconfig-a015-20201209 i386 randconfig-a012-20201209 i386 randconfig-a016-20201209 i386 randconfig-a014-20201210 i386 randconfig-a013-20201210 i386 randconfig-a012-20201210 i386 randconfig-a011-20201210 i386 randconfig-a016-20201210 i386 randconfig-a015-20201210 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20201209 x86_64 randconfig-a006-20201209 x86_64 randconfig-a005-20201209 x86_64 randconfig-a001-20201209 x86_64 randconfig-a002-20201209 x86_64 randconfig-a003-20201209 x86_64 randconfig-a003-20201210 x86_64 randconfig-a006-20201210 x86_64 randconfig-a002-20201210 x86_64 randconfig-a005-20201210 x86_64 randconfig-a004-20201210 x86_64 randconfig-a001-20201210 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[powerpc:merge] BUILD SUCCESS 244569c777ca638b08c75db88fe035bdec52ef80
secureedge5410_defconfig ia64 tiger_defconfig armmini2440_defconfig sh ul2_defconfig sh se7751_defconfig armmmp2_defconfig powerpc holly_defconfig arm h5000_defconfig mipsbcm63xx_defconfig c6x defconfig mips allyesconfig mips rb532_defconfig mipsbcm47xx_defconfig powerpc tqm8541_defconfig armcerfcube_defconfig arm multi_v4t_defconfig sh urquell_defconfig sh sdk7786_defconfig powerpc ppc64e_defconfig sh sh7785lcr_32bit_defconfig riscvnommu_k210_defconfig powerpc mpc8540_ads_defconfig arm tegra_defconfig powerpc pmac32_defconfig mips ath79_defconfig arm shannon_defconfig sh j2_defconfig m68k m5249evb_defconfig sh rts7751r2dplus_defconfig sh rts7751r2d1_defconfig mips bigsur_defconfig mips xway_defconfig mips cobalt_defconfig mipsnlm_xlp_defconfig mips rm200_defconfig arm mxs_defconfig riscvalldefconfig powerpc arches_defconfig m68km5272c3_defconfig powerpc mpc837x_rdb_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig parisc allyesconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201209 i386 randconfig-a005-20201209 i386 randconfig-a001-20201209 i386 randconfig-a002-20201209 i386 randconfig-a006-20201209 i386 randconfig-a003-20201209 i386 randconfig-a001-20201210 i386 randconfig-a004-20201210 i386 randconfig-a003-20201210 i386 randconfig-a002-20201210 i386 randconfig-a005-20201210 i386 randconfig-a006-20201210 x86_64 randconfig-a016-20201209 x86_64 randconfig-a012-20201209 x86_64 randconfig-a013-20201209 x86_64 randconfig-a014-20201209 x86_64 randconfig-a015-20201209 x86_64 randconfig-a011-20201209 i386 randconfig-a013-20201209 i386 randconfig-a014-20201209 i386 randconfig-a011-20201209 i386 randconfig-a015-20201209 i386 randconfig-a012-20201209 i386 randconfig-a016-20201209 i386 randconfig-a014-20201210 i386 randconfig-a013-20201210 i386 randconfig-a012-20201210 i386 randconfig-a011-20201210 i386 randconfig-a016-20201210 i386 randconfig-a015-20201210 riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig
Re: [PATCH v1 1/2] KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE (nested case only)
On Thu, Dec 10, 2020 at 09:54:18AM +0530, Bharata B Rao wrote: > On Wed, Dec 09, 2020 at 03:15:42PM +1100, Paul Mackerras wrote: > > On Mon, Oct 19, 2020 at 04:56:41PM +0530, Bharata B Rao wrote: > > > Implements H_RPT_INVALIDATE hcall and supports only nested case > > > currently. > > > > > > A KVM capability KVM_CAP_RPT_INVALIDATE is added to indicate the > > > support for this hcall. > > > > I have a couple of questions about this patch: > > > > 1. Is this something that is useful today, or is it something that may > > become useful in the future depending on future product plans? In > > other words, what advantage is there to forcing L2 guests to use this > > hcall instead of doing tlbie themselves? > > H_RPT_INVALIDATE will replace the use of the existing H_TLB_INVALIDATE > for nested partition scoped invalidations. Implementations that want to > off-load invalidations to the host (when GTSE=0) would have to bother > about only one hcall (H_RPT_INVALIDATE) > > > > > 2. Why does it need to be added to the default-enabled hcall list? > > > > There is a concern that if this is enabled by default we could get the > > situation where a guest using it gets migrated to a host that doesn't > > support it, which would be bad. That is the reason that all new > > things like this are disabled by default and only enabled by userspace > > (i.e. QEMU) in situations where we can enforce that it is available on > > all hosts to which the VM might be migrated. > > As you suggested privately, I am thinking of falling back to > H_TLB_INVALIDATE in case where this new hcall fails due to not being > present. That should address the migration case that you mention > above. With that and leaving the new hcall enabled by default > is good okay? No. Assuming that guests will have some fallback is not how the qemu migration compatibility model works. If we specify an old machine type, we need to provide the same environment that the older host would have. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.10-6 tag
The pull request you sent on Fri, 11 Dec 2020 11:25:43 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.10-6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/47003b9971cc7c38737f21e07034502ca35ab7af Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[GIT PULL] Please pull powerpc/linux.git powerpc-5.10-6 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull one final powerpc fix for 5.10: The following changes since commit a1ee28117077c3bf24e5ab6324c835eaab629c45: powerpc/64s/powernv: Fix memory corruption when saving SLB entries on MCE (2020-12-02 23:16:40 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.10-6 for you to fetch changes up to 5eedf9fe8db23313df104576845cec5f481b9b60: powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed() (2020-12-08 10:22:09 +1100) - -- powerpc fixes for 5.10 #6 One commit to implement copy_from_kernel_nofault_allowed(), otherwise copy_from_kernel_nofault() can trigger warnings when accessing bad addresses in some configurations. Thanks to: Christophe Leroy, Qian Cai. - -- Christophe Leroy (1): powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed() arch/powerpc/mm/Makefile | 2 +- arch/powerpc/mm/maccess.c | 9 + 2 files changed, 10 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/mm/maccess.c -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl/SvGcACgkQUevqPMjh pYAecRAAhM0j56uNwH4P+Mu/PJ3PXjuoLjZGSA1HAOyBOamJsTvShW3R3w+bq+0A nKo1I7qkrCBmvTcKWc/XqRQom3I+bP/DbtHdXx0IEW8qooBRDIRRqEXCTXPOLxnh lESPuixsTofm+HBNpg/gY4/VXphVM3+0gLp05YQ0SdeWedPmiEzyYF7IKPrYiuzq 7yOqu2wqUQ9BewWIWllDy+z5bNDnww7f2VIudTfEmg0AACriXfRvRSFk5y78OBtk fMzO1q8FLdWXTpWOVJfDFRpwPMMSjRK8DJblROoPjidXg57Lj998DP4R0WZQmiqO OKIa2AGBm9ZZCYArFhTA4X4ObmKIZKIox1th4WOAljBeByVFX8m+FbW/ChET1CSE KGmr1djFuEMljlCPPMUSgAns/LAYr+BfL+XRyix3I8vgF9lWjR2G0K1z8LEmXSEF 0MzJ/loxYSdRd89pGSuinPS8VNBObcRFTfqVqGC0LpI2PeSpawjRUbl3AOTkISFs zwdWcJWwj/XME6yjcFhic3CuUvw74v/ZGHTpbsvov0eR2ki0D5zKq9GqGHVkMP+m 5Db7i5rLGsM5zy7M2OloPVL+C193cbrrMrk7ndv3HS6ojPErHukwQ1SoQJrrGAKN 8KDfJlQB8ofjpux3jS9JoDkXqQd7zjdX63Ob9nTyjIYn0V+TEyY= =g55c -END PGP SIGNATURE-
Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
> On Dec 5, 2020, at 7:59 PM, Nicholas Piggin wrote: > > I'm still going to persue shoot-lazies for the merge window. As you > see it's about a dozen lines and a if (IS_ENABLED(... in core code. > Your change is common code, but a significant complexity (which > affects all archs) so needs a lot more review and testing at this > point. I don't think it's ready for this merge window. I read the early patches again, and I think they make the membarrier code worse, not better. I'm not fundamentally opposed to the shoot-lazies concept, but it needs more thought and it needs a cleaner foundation.
Re: [PATCH v2 07/13] powerpc: Increase NR_IRQS range to support more KVM guests
Cédric Le Goater writes: > PowerNV systems can handle up to 4K guests and 1M interrupt numbers > per chip. Increase the range of allowed interrupts to support a larger > number of guests. > > Reviewed-by: Greg Kurz > Signed-off-by: Cédric Le Goater > --- > arch/powerpc/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 5181872f9452..c250fbd430d1 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -66,7 +66,7 @@ config NEED_PER_CPU_PAGE_FIRST_CHUNK > > config NR_IRQS > int "Number of virtual interrupt numbers" > - range 32 32768 > + range 32 1048576 > default "512" > help > This defines the number of virtual interrupt numbers the kernel We should really do what other arches do, and size this appropriately based on the config, rather than asking users to guess what size they need. But I guess I'll take this for now, and we can do something fancier later. cheers
Re: linux-next: build warning after merge of the akpm tree
Hi Michael, On Thu, 10 Dec 2020 11:19:45 +1100 Michael Ellerman wrote: > > Stephen Rothwell writes: > > > > On Wed, 09 Dec 2020 15:44:35 +1100 Michael Ellerman > > wrote: > >> > >> They should really be in DATA_DATA or similar shouldn't they? > > > > No other architecture appears t need them ... > > Any arch with orphan-handling=warn should see them I thought? I did an x86_64 allyesconfig build (same compiler (more or less) and same source) and it produces none of these sections. The only difference in UBSAN CONFIG_ options was that CONFIG_UBSAN_UNREACHABLE is not set in the x86_64 build. -- Cheers, Stephen Rothwell pgpTjrQvtVVgi.pgp Description: OpenPGP digital signature
Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
Am 2020-12-10 18:38, schrieb Bjorn Helgaas: On Wed, Dec 09, 2020 at 10:29:04PM +0200, Vladimir Oltean wrote: On Wed, Dec 09, 2020 at 04:40:52PM +0100, Michael Walle wrote: > Hopefully my mail client won't mess up the output that much. I can reproduce on my LS1028A as well. The following fixes the bug for me. I did not follow the discussion and see if it is helpful for others. I don't understand how the bug came to be. There might be more to it than what I'm seeing. If it's just what I'm seeing, then the patch was pretty broken to begin with. I squashed the fix below into a pci/ecam branch for v5.11, thanks! FWIW Tested-by: Michael Walle -michael
Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
On Wed, Dec 09, 2020 at 10:29:04PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 04:40:52PM +0100, Michael Walle wrote:
> > Hopefully my mail client won't mess up the output that much.
>
> I can reproduce on my LS1028A as well. The following fixes the bug for
> me. I did not follow the discussion and see if it is helpful for others.
> I don't understand how the bug came to be. There might be more to it
> than what I'm seeing. If it's just what I'm seeing, then the patch was
> pretty broken to begin with.
I squashed the fix below into a pci/ecam branch for v5.11, thanks!
> -[cut here]-
> From b184da4088c9d39d25fee2486941cdf77688a409 Mon Sep 17 00:00:00 2001
> From: Vladimir Oltean
> Date: Wed, 9 Dec 2020 22:17:32 +0200
> Subject: [PATCH] PCI: fix invalid window size for the ECAM config space
>
> The blamed commit forgot that pci_ecam_create() calculates the size of
> the window for the ECAM's config space based on the spacing between two
> buses. The drivers whose .bus_shift from struct pci_ecam_ops was changed
> to zero in this commit are now using this invalid value for bus_shift
> in calculating the window size.
>
> Before (broken):
> pci_ecam_create: remapping config space from addr 0x1f000, bus_range 0x1,
> bsz 0x1
> After (fixed/restored):
> pci_ecam_create: remapping config space from addr 0x1f000, bus_range 0x1,
> bsz 0x10
>
> Fixes: f3c07cf6924e ("PCI: Unify ECAM constants in native PCI Express
> drivers")
> Signed-off-by: Vladimir Oltean
> ---
> drivers/pci/ecam.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
> index 59f91d434859..9fda0d49bc93 100644
> --- a/drivers/pci/ecam.c
> +++ b/drivers/pci/ecam.c
> @@ -28,11 +28,19 @@ struct pci_config_window *pci_ecam_create(struct device
> *dev,
> struct resource *cfgres, struct resource *busr,
> const struct pci_ecam_ops *ops)
> {
> + unsigned int bus_shift = ops->bus_shift;
> struct pci_config_window *cfg;
> unsigned int bus_range, bus_range_max, bsz;
> struct resource *conflict;
> int i, err;
>
> + /*
> + * struct pci_ecam_ops may omit specifying bus_shift
> + * if it is as per spec
> + */
> + if (!bus_shift)
> + bus_shift = PCIE_ECAM_BUS_SHIFT;
> +
> if (busr->start > busr->end)
> return ERR_PTR(-EINVAL);
>
> @@ -46,14 +54,14 @@ struct pci_config_window *pci_ecam_create(struct device
> *dev,
> cfg->busr.end = busr->end;
> cfg->busr.flags = IORESOURCE_BUS;
> bus_range = resource_size(>busr);
> - bus_range_max = resource_size(cfgres) >> ops->bus_shift;
> + bus_range_max = resource_size(cfgres) >> bus_shift;
> if (bus_range > bus_range_max) {
> bus_range = bus_range_max;
> cfg->busr.end = busr->start + bus_range - 1;
> dev_warn(dev, "ECAM area %pR can only accommodate %pR (reduced
> from %pR desired)\n",
>cfgres, >busr, busr);
> }
> - bsz = 1 << ops->bus_shift;
> + bsz = 1 << bus_shift;
>
> cfg->res.start = cfgres->start;
> cfg->res.end = cfgres->end;
> -[cut here]-
[PATCH v2 02/13] powerpc/xive: Rename XIVE_IRQ_NO_EOI to show its a flag
This is a simple cleanup to identify easily all flags of the XIVE
interrupt structure. The interrupts flagged with XIVE_IRQ_FLAG_NO_EOI
are the escalations used to wake up vCPUs in KVM. They are handled
very differently from the rest.
Reviewed-by: Greg Kurz
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/xive.h | 2 +-
arch/powerpc/kvm/book3s_xive.c| 4 ++--
arch/powerpc/sysdev/xive/common.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
index 309b4d65b74f..d332dd9a18de 100644
--- a/arch/powerpc/include/asm/xive.h
+++ b/arch/powerpc/include/asm/xive.h
@@ -66,7 +66,7 @@ struct xive_irq_data {
#define XIVE_IRQ_FLAG_H_INT_ESB0x20
/* Special flag set by KVM for excalation interrupts */
-#define XIVE_IRQ_NO_EOI0x80
+#define XIVE_IRQ_FLAG_NO_EOI 0x80
#define XIVE_INVALID_CHIP_ID -1
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index 18a6b75a3bfd..fae1c2e8da29 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -219,7 +219,7 @@ int kvmppc_xive_attach_escalation(struct kvm_vcpu *vcpu, u8
prio,
/* In single escalation mode, we grab the ESB MMIO of the
* interrupt and mask it. Also populate the VCPU v/raddr
* of the ESB page for use by asm entry/exit code. Finally
-* set the XIVE_IRQ_NO_EOI flag which will prevent the
+* set the XIVE_IRQ_FLAG_NO_EOI flag which will prevent the
* core code from performing an EOI on the escalation
* interrupt, thus leaving it effectively masked after
* it fires once.
@@ -231,7 +231,7 @@ int kvmppc_xive_attach_escalation(struct kvm_vcpu *vcpu, u8
prio,
xive_vm_esb_load(xd, XIVE_ESB_SET_PQ_01);
vcpu->arch.xive_esc_raddr = xd->eoi_page;
vcpu->arch.xive_esc_vaddr = (__force u64)xd->eoi_mmio;
- xd->flags |= XIVE_IRQ_NO_EOI;
+ xd->flags |= XIVE_IRQ_FLAG_NO_EOI;
}
return 0;
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index a80440af491a..65af34ac1fa2 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -416,7 +416,7 @@ static void xive_irq_eoi(struct irq_data *d)
* been passed-through to a KVM guest
*/
if (!irqd_irq_disabled(d) && !irqd_is_forwarded_to_vcpu(d) &&
- !(xd->flags & XIVE_IRQ_NO_EOI))
+ !(xd->flags & XIVE_IRQ_FLAG_NO_EOI))
xive_do_source_eoi(irqd_to_hwirq(d), xd);
else
xd->stale_p = true;
--
2.26.2
[PATCH v2 07/13] powerpc: Increase NR_IRQS range to support more KVM guests
PowerNV systems can handle up to 4K guests and 1M interrupt numbers per chip. Increase the range of allowed interrupts to support a larger number of guests. Reviewed-by: Greg Kurz Signed-off-by: Cédric Le Goater --- arch/powerpc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 5181872f9452..c250fbd430d1 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -66,7 +66,7 @@ config NEED_PER_CPU_PAGE_FIRST_CHUNK config NR_IRQS int "Number of virtual interrupt numbers" - range 32 32768 + range 32 1048576 default "512" help This defines the number of virtual interrupt numbers the kernel -- 2.26.2
[PATCH v2 08/13] powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_SHIFT_BUG
This flag was used to support the PHB4 LSIs on P9 DD1 and we have
stopped supporting this CPU when DD2 came out. See skiboot commit:
https://github.com/open-power/skiboot/commit/0b0d15e3c170
Reviewed-by: Greg Kurz
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/opal-api.h | 2 +-
arch/powerpc/include/asm/xive.h | 2 +-
arch/powerpc/kvm/book3s_xive_native.c | 3 ---
arch/powerpc/kvm/book3s_xive_template.c | 3 ---
arch/powerpc/sysdev/xive/common.c | 9 -
arch/powerpc/sysdev/xive/native.c | 2 --
6 files changed, 2 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index 1dffa3cb16ba..48ee604ca39a 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -1091,7 +1091,7 @@ enum {
OPAL_XIVE_IRQ_TRIGGER_PAGE = 0x0001,
OPAL_XIVE_IRQ_STORE_EOI = 0x0002,
OPAL_XIVE_IRQ_LSI = 0x0004,
- OPAL_XIVE_IRQ_SHIFT_BUG = 0x0008,
+ OPAL_XIVE_IRQ_SHIFT_BUG = 0x0008, /* P9 DD1.0 workaround */
OPAL_XIVE_IRQ_MASK_VIA_FW = 0x0010,
OPAL_XIVE_IRQ_EOI_VIA_FW= 0x0020,
};
diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
index d332dd9a18de..b3c039d0bb6e 100644
--- a/arch/powerpc/include/asm/xive.h
+++ b/arch/powerpc/include/asm/xive.h
@@ -60,7 +60,7 @@ struct xive_irq_data {
};
#define XIVE_IRQ_FLAG_STORE_EOI0x01
#define XIVE_IRQ_FLAG_LSI 0x02
-#define XIVE_IRQ_FLAG_SHIFT_BUG0x04
+/* #define XIVE_IRQ_FLAG_SHIFT_BUG 0x04 */ /* P9 DD1.0 workaround */
#define XIVE_IRQ_FLAG_MASK_FW 0x08
#define XIVE_IRQ_FLAG_EOI_FW 0x10
#define XIVE_IRQ_FLAG_H_INT_ESB0x20
diff --git a/arch/powerpc/kvm/book3s_xive_native.c
b/arch/powerpc/kvm/book3s_xive_native.c
index 9b395381179d..170d1d04e1d1 100644
--- a/arch/powerpc/kvm/book3s_xive_native.c
+++ b/arch/powerpc/kvm/book3s_xive_native.c
@@ -37,9 +37,6 @@ static u8 xive_vm_esb_load(struct xive_irq_data *xd, u32
offset)
* ordering.
*/
- if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
- offset |= offset << 4;
-
val = in_be64(xd->eoi_mmio + offset);
return (u8)val;
}
diff --git a/arch/powerpc/kvm/book3s_xive_template.c
b/arch/powerpc/kvm/book3s_xive_template.c
index 4ad3c0279458..ece36e024a8f 100644
--- a/arch/powerpc/kvm/book3s_xive_template.c
+++ b/arch/powerpc/kvm/book3s_xive_template.c
@@ -61,9 +61,6 @@ static u8 GLUE(X_PFX,esb_load)(struct xive_irq_data *xd, u32
offset)
if (offset == XIVE_ESB_SET_PQ_10 && xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
offset |= XIVE_ESB_LD_ST_MO;
- if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
- offset |= offset << 4;
-
val =__x_readq(__x_eoi_page(xd) + offset);
#ifdef __LITTLE_ENDIAN__
val >>= 64-8;
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 348445ffa0af..7b6e3149f1ea 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -200,10 +200,6 @@ static notrace u8 xive_esb_read(struct xive_irq_data *xd,
u32 offset)
if (offset == XIVE_ESB_SET_PQ_10 && xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
offset |= XIVE_ESB_LD_ST_MO;
- /* Handle HW errata */
- if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
- offset |= offset << 4;
-
if ((xd->flags & XIVE_IRQ_FLAG_H_INT_ESB) && xive_ops->esb_rw)
val = xive_ops->esb_rw(xd->hw_irq, offset, 0, 0);
else
@@ -214,10 +210,6 @@ static notrace u8 xive_esb_read(struct xive_irq_data *xd,
u32 offset)
static void xive_esb_write(struct xive_irq_data *xd, u32 offset, u64 data)
{
- /* Handle HW errata */
- if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
- offset |= offset << 4;
-
if ((xd->flags & XIVE_IRQ_FLAG_H_INT_ESB) && xive_ops->esb_rw)
xive_ops->esb_rw(xd->hw_irq, offset, data, 1);
else
@@ -1312,7 +1304,6 @@ static const struct {
} xive_irq_flags[] = {
{ XIVE_IRQ_FLAG_STORE_EOI, "STORE_EOI" },
{ XIVE_IRQ_FLAG_LSI, "LSI" },
- { XIVE_IRQ_FLAG_SHIFT_BUG, "SHIFT_BUG" },
{ XIVE_IRQ_FLAG_MASK_FW, "MASK_FW" },
{ XIVE_IRQ_FLAG_EOI_FW,"EOI_FW"},
{ XIVE_IRQ_FLAG_H_INT_ESB, "H_INT_ESB" },
diff --git a/arch/powerpc/sysdev/xive/native.c
b/arch/powerpc/sysdev/xive/native.c
index c3182ec9ed65..f501b1640068 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -64,8 +64,6 @@ int xive_native_populate_irq_data(u32 hw_irq, struct
xive_irq_data *data)
data->flags |= XIVE_IRQ_FLAG_STORE_EOI;
if (opal_flags & OPAL_XIVE_IRQ_LSI)
data->flags |= XIVE_IRQ_FLAG_LSI;
- if (opal_flags & OPAL_XIVE_IRQ_SHIFT_BUG)
- data->flags |=
[PATCH v2 13/13] KVM: PPC: Book3S HV: XIVE: Add a comment regarding VP numbering
When the XIVE resources are allocated at the HW level, the VP
structures describing the vCPUs of a guest are distributed among
the chips to optimize the PowerBUS usage. For best performance, the
guest vCPUs can be pinned to match the VP structure distribution.
Currently, the VP identifiers are deduced from the vCPU id using
the kvmppc_pack_vcpu_id() routine which is not incorrect but not
optimal either. It VSMT is used, the result is not continuous and
the constraints on HW resources described above can not be met.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s_xive.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_xive.h b/arch/powerpc/kvm/book3s_xive.h
index d5d4fee7ac94..86c24a4ad809 100644
--- a/arch/powerpc/kvm/book3s_xive.h
+++ b/arch/powerpc/kvm/book3s_xive.h
@@ -218,6 +218,17 @@ static inline struct kvmppc_xive_src_block
*kvmppc_xive_find_source(struct kvmpp
return xive->src_blocks[bid];
}
+/*
+ * When the XIVE resources are allocated at the HW level, the VP
+ * structures describing the vCPUs of a guest are distributed among
+ * the chips to optimize the PowerBUS usage. For best performance, the
+ * guest vCPUs can be pinned to match the VP structure distribution.
+ *
+ * Currently, the VP identifiers are deduced from the vCPU id using
+ * the kvmppc_pack_vcpu_id() routine which is not incorrect but not
+ * optimal either. It VSMT is used, the result is not continuous and
+ * the constraints on HW resources described above can not be met.
+ */
static inline u32 kvmppc_xive_vp(struct kvmppc_xive *xive, u32 server)
{
return xive->vp_base + kvmppc_pack_vcpu_id(xive->kvm, server);
--
2.26.2
[PATCH v2 09/13] powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_MASK_FW
This flag was used to support the PHB4 LSIs on P9 DD1 and we have
stopped supporting this CPU when DD2 came out. See skiboot commit:
https://github.com/open-power/skiboot/commit/0b0d15e3c170
Reviewed-by: Greg Kurz
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/opal-api.h | 2 +-
arch/powerpc/include/asm/xive.h | 2 +-
arch/powerpc/kvm/book3s_xive.c | 54 +
arch/powerpc/sysdev/xive/common.c | 40 +
arch/powerpc/sysdev/xive/native.c | 2 --
5 files changed, 11 insertions(+), 89 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index 48ee604ca39a..0455b679c050 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -1092,7 +1092,7 @@ enum {
OPAL_XIVE_IRQ_STORE_EOI = 0x0002,
OPAL_XIVE_IRQ_LSI = 0x0004,
OPAL_XIVE_IRQ_SHIFT_BUG = 0x0008, /* P9 DD1.0 workaround */
- OPAL_XIVE_IRQ_MASK_VIA_FW = 0x0010,
+ OPAL_XIVE_IRQ_MASK_VIA_FW = 0x0010, /* P9 DD1.0 workaround */
OPAL_XIVE_IRQ_EOI_VIA_FW= 0x0020,
};
diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
index b3c039d0bb6e..8d5b0dcc253c 100644
--- a/arch/powerpc/include/asm/xive.h
+++ b/arch/powerpc/include/asm/xive.h
@@ -61,7 +61,7 @@ struct xive_irq_data {
#define XIVE_IRQ_FLAG_STORE_EOI0x01
#define XIVE_IRQ_FLAG_LSI 0x02
/* #define XIVE_IRQ_FLAG_SHIFT_BUG 0x04 */ /* P9 DD1.0 workaround */
-#define XIVE_IRQ_FLAG_MASK_FW 0x08
+/* #define XIVE_IRQ_FLAG_MASK_FW 0x08 */ /* P9 DD1.0 workaround */
#define XIVE_IRQ_FLAG_EOI_FW 0x10
#define XIVE_IRQ_FLAG_H_INT_ESB0x20
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index fae1c2e8da29..30dfeac731c6 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -419,37 +419,16 @@ static u8 xive_lock_and_mask(struct kvmppc_xive *xive,
/* Get the right irq */
kvmppc_xive_select_irq(state, _num, );
+ /* Set PQ to 10, return old P and old Q and remember them */
+ val = xive_vm_esb_load(xd, XIVE_ESB_SET_PQ_10);
+ state->old_p = !!(val & 2);
+ state->old_q = !!(val & 1);
+
/*
-* If the interrupt is marked as needing masking via
-* firmware, we do it here. Firmware masking however
-* is "lossy", it won't return the old p and q bits
-* and won't set the interrupt to a state where it will
-* record queued ones. If this is an issue we should do
-* lazy masking instead.
-*
-* For now, we work around this in unmask by forcing
-* an interrupt whenever we unmask a non-LSI via FW
-* (if ever).
+* Synchronize hardware to sensure the queues are updated when
+* masking
*/
- if (xd->flags & OPAL_XIVE_IRQ_MASK_VIA_FW) {
- xive_native_configure_irq(hw_num,
- kvmppc_xive_vp(xive, state->act_server),
- MASKED, state->number);
- /* set old_p so we can track if an H_EOI was done */
- state->old_p = true;
- state->old_q = false;
- } else {
- /* Set PQ to 10, return old P and old Q and remember them */
- val = xive_vm_esb_load(xd, XIVE_ESB_SET_PQ_10);
- state->old_p = !!(val & 2);
- state->old_q = !!(val & 1);
-
- /*
-* Synchronize hardware to sensure the queues are updated
-* when masking
-*/
- xive_native_sync_source(hw_num);
- }
+ xive_native_sync_source(hw_num);
return old_prio;
}
@@ -483,23 +462,6 @@ static void xive_finish_unmask(struct kvmppc_xive *xive,
/* Get the right irq */
kvmppc_xive_select_irq(state, _num, );
- /*
-* See comment in xive_lock_and_mask() concerning masking
-* via firmware.
-*/
- if (xd->flags & OPAL_XIVE_IRQ_MASK_VIA_FW) {
- xive_native_configure_irq(hw_num,
- kvmppc_xive_vp(xive, state->act_server),
- state->act_priority, state->number);
- /* If an EOI is needed, do it here */
- if (!state->old_p)
- xive_vm_source_eoi(hw_num, xd);
- /* If this is not an LSI, force a trigger */
- if (!(xd->flags & OPAL_XIVE_IRQ_LSI))
- xive_irq_trigger(xd);
- goto bail;
- }
-
/* Old Q set, set PQ to 11 */
if (state->old_q)
xive_vm_esb_load(xd, XIVE_ESB_SET_PQ_11);
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 7b6e3149f1ea..b240eb698920 100644
--- a/arch/powerpc/sysdev/xive/common.c
[PATCH v2 06/13] powerpc/xive: Add a debug_show handler to the XIVE irq_domain
Full state of the Linux interrupt descriptors can be dumped under
debugfs when compiled with CONFIG_GENERIC_IRQ_DEBUGFS. Add support for
the XIVE interrupt controller.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 7314b87d0b45..348445ffa0af 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -1303,11 +1303,69 @@ static int xive_irq_domain_match(struct irq_domain *h,
struct device_node *node,
return xive_ops->match(node);
}
+#ifdef CONFIG_GENERIC_IRQ_DEBUGFS
+static const char * const esb_names[] = { "RESET", "OFF", "PENDING", "QUEUED"
};
+
+static const struct {
+ u64 mask;
+ char *name;
+} xive_irq_flags[] = {
+ { XIVE_IRQ_FLAG_STORE_EOI, "STORE_EOI" },
+ { XIVE_IRQ_FLAG_LSI, "LSI" },
+ { XIVE_IRQ_FLAG_SHIFT_BUG, "SHIFT_BUG" },
+ { XIVE_IRQ_FLAG_MASK_FW, "MASK_FW" },
+ { XIVE_IRQ_FLAG_EOI_FW,"EOI_FW"},
+ { XIVE_IRQ_FLAG_H_INT_ESB, "H_INT_ESB" },
+ { XIVE_IRQ_FLAG_NO_EOI,"NO_EOI"},
+};
+
+static void xive_irq_domain_debug_show(struct seq_file *m, struct irq_domain
*d,
+ struct irq_data *irqd, int ind)
+{
+ struct xive_irq_data *xd;
+ u64 val;
+ int i;
+
+ /* No IRQ domain level information. To be done */
+ if (!irqd)
+ return;
+
+ if (!is_xive_irq(irq_data_get_irq_chip(irqd)))
+ return;
+
+ seq_printf(m, "%*sXIVE:\n", ind, "");
+ ind++;
+
+ xd = irq_data_get_irq_handler_data(irqd);
+ if (!xd) {
+ seq_printf(m, "%*snot assigned\n", ind, "");
+ return;
+ }
+
+ val = xive_esb_read(xd, XIVE_ESB_GET);
+ seq_printf(m, "%*sESB: %s\n", ind, "", esb_names[val & 0x3]);
+ seq_printf(m, "%*sPstate: %s %s\n", ind, "", xd->stale_p ? "stale" :
"",
+ xd->saved_p ? "saved" : "");
+ seq_printf(m, "%*sTarget: %d\n", ind, "", xd->target);
+ seq_printf(m, "%*sChip: %d\n", ind, "", xd->src_chip);
+ seq_printf(m, "%*sTrigger: 0x%016llx\n", ind, "", xd->trig_page);
+ seq_printf(m, "%*sEOI: 0x%016llx\n", ind, "", xd->eoi_page);
+ seq_printf(m, "%*sFlags:0x%llx\n", ind, "", xd->flags);
+ for (i = 0; i < ARRAY_SIZE(xive_irq_flags); i++) {
+ if (xd->flags & xive_irq_flags[i].mask)
+ seq_printf(m, "%*s%s\n", ind + 12, "",
xive_irq_flags[i].name);
+ }
+}
+#endif
+
static const struct irq_domain_ops xive_irq_domain_ops = {
.match = xive_irq_domain_match,
.map = xive_irq_domain_map,
.unmap = xive_irq_domain_unmap,
.xlate = xive_irq_domain_xlate,
+#ifdef CONFIG_GENERIC_IRQ_DEBUGFS
+ .debug_show = xive_irq_domain_debug_show,
+#endif
};
static void __init xive_init_host(struct device_node *np)
--
2.26.2
[PATCH v2 10/13] powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_EOI_FW
This flag was used to support the P9 DD1 and we have stopped
supporting this CPU when DD2 came out. See skiboot commit:
https://github.com/open-power/skiboot/commit/0b0d15e3c170
Also, remove eoi handler which is now unused.
Reviewed-by: Greg Kurz
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/opal-api.h | 2 +-
arch/powerpc/include/asm/xive.h | 2 +-
arch/powerpc/sysdev/xive/xive-internal.h | 1 -
arch/powerpc/kvm/book3s_xive_template.c | 2 --
arch/powerpc/sysdev/xive/common.c| 14 +-
arch/powerpc/sysdev/xive/native.c| 12
arch/powerpc/sysdev/xive/spapr.c | 6 --
7 files changed, 3 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index 0455b679c050..0b63ba7d5917 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -1093,7 +1093,7 @@ enum {
OPAL_XIVE_IRQ_LSI = 0x0004,
OPAL_XIVE_IRQ_SHIFT_BUG = 0x0008, /* P9 DD1.0 workaround */
OPAL_XIVE_IRQ_MASK_VIA_FW = 0x0010, /* P9 DD1.0 workaround */
- OPAL_XIVE_IRQ_EOI_VIA_FW= 0x0020,
+ OPAL_XIVE_IRQ_EOI_VIA_FW= 0x0020, /* P9 DD1.0 workaround */
};
/* Flags for OPAL_XIVE_GET/SET_QUEUE_INFO */
diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
index 8d5b0dcc253c..9a312b975ca8 100644
--- a/arch/powerpc/include/asm/xive.h
+++ b/arch/powerpc/include/asm/xive.h
@@ -62,7 +62,7 @@ struct xive_irq_data {
#define XIVE_IRQ_FLAG_LSI 0x02
/* #define XIVE_IRQ_FLAG_SHIFT_BUG 0x04 */ /* P9 DD1.0 workaround */
/* #define XIVE_IRQ_FLAG_MASK_FW 0x08 */ /* P9 DD1.0 workaround */
-#define XIVE_IRQ_FLAG_EOI_FW 0x10
+/* #define XIVE_IRQ_FLAG_EOI_FW0x10 */ /* P9 DD1.0 workaround */
#define XIVE_IRQ_FLAG_H_INT_ESB0x20
/* Special flag set by KVM for excalation interrupts */
diff --git a/arch/powerpc/sysdev/xive/xive-internal.h
b/arch/powerpc/sysdev/xive/xive-internal.h
index c07fadb9d264..9cf57c722faa 100644
--- a/arch/powerpc/sysdev/xive/xive-internal.h
+++ b/arch/powerpc/sysdev/xive/xive-internal.h
@@ -52,7 +52,6 @@ struct xive_ops {
void(*shutdown)(void);
void(*update_pending)(struct xive_cpu *xc);
- void(*eoi)(u32 hw_irq);
void(*sync_source)(u32 hw_irq);
u64 (*esb_rw)(u32 hw_irq, u32 offset, u64 data, bool write);
#ifdef CONFIG_SMP
diff --git a/arch/powerpc/kvm/book3s_xive_template.c
b/arch/powerpc/kvm/book3s_xive_template.c
index ece36e024a8f..b0015e05d99a 100644
--- a/arch/powerpc/kvm/book3s_xive_template.c
+++ b/arch/powerpc/kvm/book3s_xive_template.c
@@ -74,8 +74,6 @@ static void GLUE(X_PFX,source_eoi)(u32 hw_irq, struct
xive_irq_data *xd)
/* If the XIVE supports the new "store EOI facility, use it */
if (xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
__x_writeq(0, __x_eoi_page(xd) + XIVE_ESB_STORE_EOI);
- else if (hw_irq && xd->flags & XIVE_IRQ_FLAG_EOI_FW)
- opal_int_eoi(hw_irq);
else if (xd->flags & XIVE_IRQ_FLAG_LSI) {
/*
* For LSIs the HW EOI cycle is used rather than PQ bits,
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index b240eb698920..ed9bc49f45a7 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -354,18 +354,7 @@ static void xive_do_source_eoi(u32 hw_irq, struct
xive_irq_data *xd)
/* If the XIVE supports the new "store EOI facility, use it */
if (xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
xive_esb_write(xd, XIVE_ESB_STORE_EOI, 0);
- else if (hw_irq && xd->flags & XIVE_IRQ_FLAG_EOI_FW) {
- /*
-* The FW told us to call it. This happens for some
-* interrupt sources that need additional HW whacking
-* beyond the ESB manipulation. For example LPC interrupts
-* on P9 DD1.0 needed a latch to be clared in the LPC bridge
-* itself. The Firmware will take care of it.
-*/
- if (WARN_ON_ONCE(!xive_ops->eoi))
- return;
- xive_ops->eoi(hw_irq);
- } else {
+ else {
u8 eoi_val;
/*
@@ -1267,7 +1256,6 @@ static const struct {
} xive_irq_flags[] = {
{ XIVE_IRQ_FLAG_STORE_EOI, "STORE_EOI" },
{ XIVE_IRQ_FLAG_LSI, "LSI" },
- { XIVE_IRQ_FLAG_EOI_FW,"EOI_FW"},
{ XIVE_IRQ_FLAG_H_INT_ESB, "H_INT_ESB" },
{ XIVE_IRQ_FLAG_NO_EOI,"NO_EOI"},
};
diff --git a/arch/powerpc/sysdev/xive/native.c
b/arch/powerpc/sysdev/xive/native.c
index 6c04ac1f3a1f..e91519c42463 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -64,8 +64,6 @@ int xive_native_populate_irq_data(u32 hw_irq,
[PATCH v2 00/13] powerpc/xive: misc cleanups
Hello, The most important change is the removal of support of OPAL flags required for P9 DD1. It provides a good cleanup of some complex routines. Thanks, C. Changes since v1: - dropped the change on the allocation of the pages donated to the XIVE IC. Needs a retest on a specific system. - Took into account Greg's comments on flag removal. Cédric Le Goater (13): KVM: PPC: Book3S HV: XIVE: Show detailed configuration in debug output powerpc/xive: Rename XIVE_IRQ_NO_EOI to show its a flag powerpc/xive: Introduce XIVE_IPI_HW_IRQ powerpc/xive: Use cpu_to_node() instead of ibm,chip-id property powerpc/xive: Add a name to the IRQ domain powerpc/xive: Add a debug_show handler to the XIVE irq_domain powerpc: Increase NR_IRQS range to support more KVM guests powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_SHIFT_BUG powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_MASK_FW powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_EOI_FW powerpc/xive: Simplify xive_do_source_eoi() powerpc/xive: Improve error reporting of OPAL calls KVM: PPC: Book3S HV: XIVE: Add a comment regarding VP numbering arch/powerpc/include/asm/opal-api.h | 6 +- arch/powerpc/include/asm/xive.h | 8 +- arch/powerpc/kvm/book3s_xive.h | 13 ++ arch/powerpc/sysdev/xive/xive-internal.h | 7 +- arch/powerpc/kvm/book3s_xive.c | 134 +++--- arch/powerpc/kvm/book3s_xive_native.c| 24 ++- arch/powerpc/kvm/book3s_xive_template.c | 5 - arch/powerpc/sysdev/xive/common.c| 214 +++ arch/powerpc/sysdev/xive/native.c| 46 ++--- arch/powerpc/sysdev/xive/spapr.c | 8 +- arch/powerpc/Kconfig | 2 +- 11 files changed, 234 insertions(+), 233 deletions(-) -- 2.26.2
[PATCH v2 03/13] powerpc/xive: Introduce XIVE_IPI_HW_IRQ
The XIVE driver deals with CPU IPIs in a peculiar way. Each CPU has
its own XIVE IPI interrupt allocated at the HW level, for PowerNV, or
at the hypervisor level for pSeries. In practice, these interrupts are
not always used. pSeries/PowerVM prefers local doorbells for local
threads since they are faster. On PowerNV, global doorbells are also
preferred for the same reason.
The mapping in the Linux is reduced to a single interrupt using HW
interrupt number 0 and a custom irq_chip to handle EOI. This can cause
performance issues in some benchmark (ipistorm) on multichip systems.
Clarify the use of the 0 value, it will help in improving multichip
support.
Reviewed-by: Greg Kurz
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/xive-internal.h | 2 ++
arch/powerpc/sysdev/xive/common.c| 10 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/xive-internal.h
b/arch/powerpc/sysdev/xive/xive-internal.h
index b7b901da2168..d701af7fb48c 100644
--- a/arch/powerpc/sysdev/xive/xive-internal.h
+++ b/arch/powerpc/sysdev/xive/xive-internal.h
@@ -5,6 +5,8 @@
#ifndef __XIVE_INTERNAL_H
#define __XIVE_INTERNAL_H
+#define XIVE_IPI_HW_IRQ0 /* interrupt source # for IPIs */
+
/*
* A "disabled" interrupt should never fire, to catch problems
* we set its logical number to this
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 65af34ac1fa2..ee375daf8114 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -1142,7 +1142,7 @@ static void __init xive_request_ipi(void)
return;
/* Initialize it */
- virq = irq_create_mapping(xive_irq_domain, 0);
+ virq = irq_create_mapping(xive_irq_domain, XIVE_IPI_HW_IRQ);
xive_ipi_irq = virq;
WARN_ON(request_irq(virq, xive_muxed_ipi_action,
@@ -1242,7 +1242,7 @@ static int xive_irq_domain_map(struct irq_domain *h,
unsigned int virq,
#ifdef CONFIG_SMP
/* IPIs are special and come up with HW number 0 */
- if (hw == 0) {
+ if (hw == XIVE_IPI_HW_IRQ) {
/*
* IPIs are marked per-cpu. We use separate HW interrupts under
* the hood but associated with the same "linux" interrupt
@@ -1271,7 +1271,7 @@ static void xive_irq_domain_unmap(struct irq_domain *d,
unsigned int virq)
if (!data)
return;
hw_irq = (unsigned int)irqd_to_hwirq(data);
- if (hw_irq)
+ if (hw_irq != XIVE_IPI_HW_IRQ)
xive_irq_free_data(virq);
}
@@ -1421,7 +1421,7 @@ static void xive_flush_cpu_queue(unsigned int cpu, struct
xive_cpu *xc)
* Ignore anything that isn't a XIVE irq and ignore
* IPIs, so can just be dropped.
*/
- if (d->domain != xive_irq_domain || hw_irq == 0)
+ if (d->domain != xive_irq_domain || hw_irq == XIVE_IPI_HW_IRQ)
continue;
/*
@@ -1655,7 +1655,7 @@ static int xive_core_debug_show(struct seq_file *m, void
*private)
hw_irq = (unsigned int)irqd_to_hwirq(d);
/* IPIs are special (HW number 0) */
- if (hw_irq)
+ if (hw_irq != XIVE_IPI_HW_IRQ)
xive_debug_show_irq(m, hw_irq, d);
}
return 0;
--
2.26.2
[PATCH v2 12/13] powerpc/xive: Improve error reporting of OPAL calls
Introduce a vp_err() macro to standardize error reporting.
Reviewed-by: Greg Kurz
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/native.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/native.c
b/arch/powerpc/sysdev/xive/native.c
index e91519c42463..05a800a3104e 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -122,6 +122,8 @@ static int xive_native_get_irq_config(u32 hw_irq, u32
*target, u8 *prio,
return rc == 0 ? 0 : -ENXIO;
}
+#define vp_err(vp, fmt, ...) pr_err("VP[0x%x]: " fmt, vp, ##__VA_ARGS__)
+
/* This can be called multiple time to change a queue configuration */
int xive_native_configure_queue(u32 vp_id, struct xive_q *q, u8 prio,
__be32 *qpage, u32 order, bool can_escalate)
@@ -149,7 +151,7 @@ int xive_native_configure_queue(u32 vp_id, struct xive_q
*q, u8 prio,
_irq_be,
NULL);
if (rc) {
- pr_err("Error %lld getting queue info prio %d\n", rc, prio);
+ vp_err(vp_id, "Failed to get queue %d info : %lld\n", prio, rc);
rc = -EIO;
goto fail;
}
@@ -172,7 +174,7 @@ int xive_native_configure_queue(u32 vp_id, struct xive_q
*q, u8 prio,
msleep(OPAL_BUSY_DELAY_MS);
}
if (rc) {
- pr_err("Error %lld setting queue for prio %d\n", rc, prio);
+ vp_err(vp_id, "Failed to set queue %d info: %lld\n", prio, rc);
rc = -EIO;
} else {
/*
@@ -199,7 +201,7 @@ static void __xive_native_disable_queue(u32 vp_id, struct
xive_q *q, u8 prio)
msleep(OPAL_BUSY_DELAY_MS);
}
if (rc)
- pr_err("Error %lld disabling queue for prio %d\n", rc, prio);
+ vp_err(vp_id, "Failed to disable queue %d : %lld\n", prio, rc);
}
void xive_native_disable_queue(u32 vp_id, struct xive_q *q, u8 prio)
@@ -698,6 +700,8 @@ int xive_native_enable_vp(u32 vp_id, bool single_escalation)
break;
msleep(OPAL_BUSY_DELAY_MS);
}
+ if (rc)
+ vp_err(vp_id, "Failed to enable VP : %lld\n", rc);
return rc ? -EIO : 0;
}
EXPORT_SYMBOL_GPL(xive_native_enable_vp);
@@ -712,6 +716,8 @@ int xive_native_disable_vp(u32 vp_id)
break;
msleep(OPAL_BUSY_DELAY_MS);
}
+ if (rc)
+ vp_err(vp_id, "Failed to disable VP : %lld\n", rc);
return rc ? -EIO : 0;
}
EXPORT_SYMBOL_GPL(xive_native_disable_vp);
@@ -723,8 +729,10 @@ int xive_native_get_vp_info(u32 vp_id, u32 *out_cam_id,
u32 *out_chip_id)
s64 rc;
rc = opal_xive_get_vp_info(vp_id, NULL, _cam_be, NULL,
_chip_id_be);
- if (rc)
+ if (rc) {
+ vp_err(vp_id, "Failed to get VP info : %lld\n", rc);
return -EIO;
+ }
*out_cam_id = be64_to_cpu(vp_cam_be) & 0xu;
*out_chip_id = be32_to_cpu(vp_chip_id_be);
@@ -755,8 +763,7 @@ int xive_native_get_queue_info(u32 vp_id, u32 prio,
rc = opal_xive_get_queue_info(vp_id, prio, , ,
_page, _irq, );
if (rc) {
- pr_err("OPAL failed to get queue info for VCPU %d/%d : %lld\n",
- vp_id, prio, rc);
+ vp_err(vp_id, "failed to get queue %d info : %lld\n", prio, rc);
return -EIO;
}
@@ -784,8 +791,7 @@ int xive_native_get_queue_state(u32 vp_id, u32 prio, u32
*qtoggle, u32 *qindex)
rc = opal_xive_get_queue_state(vp_id, prio, _qtoggle,
_qindex);
if (rc) {
- pr_err("OPAL failed to get queue state for VCPU %d/%d : %lld\n",
- vp_id, prio, rc);
+ vp_err(vp_id, "failed to get queue %d state : %lld\n", prio,
rc);
return -EIO;
}
@@ -804,8 +810,7 @@ int xive_native_set_queue_state(u32 vp_id, u32 prio, u32
qtoggle, u32 qindex)
rc = opal_xive_set_queue_state(vp_id, prio, qtoggle, qindex);
if (rc) {
- pr_err("OPAL failed to set queue state for VCPU %d/%d : %lld\n",
- vp_id, prio, rc);
+ vp_err(vp_id, "failed to set queue %d state : %lld\n", prio,
rc);
return -EIO;
}
@@ -827,8 +832,7 @@ int xive_native_get_vp_state(u32 vp_id, u64 *out_state)
rc = opal_xive_get_vp_state(vp_id, );
if (rc) {
- pr_err("OPAL failed to get vp state for VCPU %d : %lld\n",
- vp_id, rc);
+ vp_err(vp_id, "failed to get vp state : %lld\n", rc);
return -EIO;
}
--
2.26.2
[PATCH v2 01/13] KVM: PPC: Book3S HV: XIVE: Show detailed configuration in debug output
This is useful to track allocation of the HW resources on per guest
basis. Making sure IPIs are local to the chip of the vCPUs reduces
rerouting between interrupt controllers and gives better performance
in case of pinning. Checking the distribution of VP structures on the
chips also helps in reducing PowerBUS traffic.
Signed-off-by: Greg Kurz
[ clg: resurrected show_sources and reworked ouput ]
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s_xive.h| 2 +
arch/powerpc/kvm/book3s_xive.c| 76 ++-
arch/powerpc/kvm/book3s_xive_native.c | 21 ++--
3 files changed, 82 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_xive.h b/arch/powerpc/kvm/book3s_xive.h
index 382e3a56e789..d5d4fee7ac94 100644
--- a/arch/powerpc/kvm/book3s_xive.h
+++ b/arch/powerpc/kvm/book3s_xive.h
@@ -290,6 +290,8 @@ extern int (*__xive_vm_h_eoi)(struct kvm_vcpu *vcpu,
unsigned long xirr);
*/
void kvmppc_xive_disable_vcpu_interrupts(struct kvm_vcpu *vcpu);
int kvmppc_xive_debug_show_queues(struct seq_file *m, struct kvm_vcpu *vcpu);
+void kvmppc_xive_debug_show_sources(struct seq_file *m,
+ struct kvmppc_xive_src_block *sb);
struct kvmppc_xive_src_block *kvmppc_xive_create_src_block(
struct kvmppc_xive *xive, int irq);
void kvmppc_xive_free_sources(struct kvmppc_xive_src_block *sb);
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index a0ebc29f30b2..18a6b75a3bfd 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -2125,9 +2125,8 @@ int kvmppc_xive_debug_show_queues(struct seq_file *m,
struct kvm_vcpu *vcpu)
if (!q->qpage && !xc->esc_virq[i])
continue;
- seq_printf(m, " [q%d]: ", i);
-
if (q->qpage) {
+ seq_printf(m, "q[%d]: ", i);
idx = q->idx;
i0 = be32_to_cpup(q->qpage + idx);
idx = (idx + 1) & q->msk;
@@ -2141,16 +2140,54 @@ int kvmppc_xive_debug_show_queues(struct seq_file *m,
struct kvm_vcpu *vcpu)
irq_data_get_irq_handler_data(d);
u64 pq = xive_vm_esb_load(xd, XIVE_ESB_GET);
- seq_printf(m, "E:%c%c I(%d:%llx:%llx)",
- (pq & XIVE_ESB_VAL_P) ? 'P' : 'p',
- (pq & XIVE_ESB_VAL_Q) ? 'Q' : 'q',
- xc->esc_virq[i], pq, xd->eoi_page);
+ seq_printf(m, "ESC %d %c%c EOI @%llx",
+ xc->esc_virq[i],
+ (pq & XIVE_ESB_VAL_P) ? 'P' : '-',
+ (pq & XIVE_ESB_VAL_Q) ? 'Q' : '-',
+ xd->eoi_page);
seq_puts(m, "\n");
}
}
return 0;
}
+void kvmppc_xive_debug_show_sources(struct seq_file *m,
+ struct kvmppc_xive_src_block *sb)
+{
+ int i;
+
+ seq_puts(m, "LISN HW/CHIP TYPEPQ EISN
CPU/PRIO\n");
+ for (i = 0; i < KVMPPC_XICS_IRQ_PER_ICS; i++) {
+ struct kvmppc_xive_irq_state *state = >irq_state[i];
+ struct xive_irq_data *xd;
+ u64 pq;
+ u32 hw_num;
+
+ if (!state->valid)
+ continue;
+
+ kvmppc_xive_select_irq(state, _num, );
+
+ pq = xive_vm_esb_load(xd, XIVE_ESB_GET);
+
+ seq_printf(m, "%08x %08x/%02x", state->number, hw_num,
+ xd->src_chip);
+ if (state->lsi)
+ seq_printf(m, " %cLSI", state->asserted ? '^' : ' ');
+ else
+ seq_puts(m, " MSI");
+
+ seq_printf(m, " %s %c%c %08x % 4d/%d",
+ state->ipi_number == hw_num ? "IPI" : " PT",
+ pq & XIVE_ESB_VAL_P ? 'P' : '-',
+ pq & XIVE_ESB_VAL_Q ? 'Q' : '-',
+ state->eisn, state->act_server,
+ state->act_priority);
+
+ seq_puts(m, "\n");
+ }
+}
+
static int xive_debug_show(struct seq_file *m, void *private)
{
struct kvmppc_xive *xive = m->private;
@@ -2171,7 +2208,7 @@ static int xive_debug_show(struct seq_file *m, void
*private)
if (!kvm)
return 0;
- seq_printf(m, "=\nVCPU state\n=\n");
+ seq_puts(m, "=\nVCPU state\n=\n");
kvm_for_each_vcpu(i, vcpu, kvm) {
struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
@@ -2179,11 +2216,12 @@ static int xive_debug_show(struct seq_file *m, void
*private)
if (!xc)
continue;
- seq_printf(m, "cpu server %#x VP:%#x
[PATCH v2 11/13] powerpc/xive: Simplify xive_do_source_eoi()
Previous patches removed the need of the first argument which was a
hack for Firwmware EOI. Remove it and flatten the routine which has
became simpler.
Reviewed-by: Greg Kurz
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 72 ++-
1 file changed, 33 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index ed9bc49f45a7..b8e456da28aa 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -348,39 +348,40 @@ static void xive_do_queue_eoi(struct xive_cpu *xc)
* EOI an interrupt at the source. There are several methods
* to do this depending on the HW version and source type
*/
-static void xive_do_source_eoi(u32 hw_irq, struct xive_irq_data *xd)
+static void xive_do_source_eoi(struct xive_irq_data *xd)
{
+ u8 eoi_val;
+
xd->stale_p = false;
+
/* If the XIVE supports the new "store EOI facility, use it */
- if (xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
+ if (xd->flags & XIVE_IRQ_FLAG_STORE_EOI) {
xive_esb_write(xd, XIVE_ESB_STORE_EOI, 0);
- else {
- u8 eoi_val;
+ return;
+ }
- /*
-* Otherwise for EOI, we use the special MMIO that does
-* a clear of both P and Q and returns the old Q,
-* except for LSIs where we use the "EOI cycle" special
-* load.
-*
-* This allows us to then do a re-trigger if Q was set
-* rather than synthesizing an interrupt in software
-*
-* For LSIs the HW EOI cycle is used rather than PQ bits,
-* as they are automatically re-triggred in HW when still
-* pending.
-*/
- if (xd->flags & XIVE_IRQ_FLAG_LSI)
- xive_esb_read(xd, XIVE_ESB_LOAD_EOI);
- else {
- eoi_val = xive_esb_read(xd, XIVE_ESB_SET_PQ_00);
- DBG_VERBOSE("eoi_val=%x\n", eoi_val);
-
- /* Re-trigger if needed */
- if ((eoi_val & XIVE_ESB_VAL_Q) && xd->trig_mmio)
- out_be64(xd->trig_mmio, 0);
- }
+ /*
+* For LSIs, we use the "EOI cycle" special load rather than
+* PQ bits, as they are automatically re-triggered in HW when
+* still pending.
+*/
+ if (xd->flags & XIVE_IRQ_FLAG_LSI) {
+ xive_esb_read(xd, XIVE_ESB_LOAD_EOI);
+ return;
}
+
+ /*
+* Otherwise, we use the special MMIO that does a clear of
+* both P and Q and returns the old Q. This allows us to then
+* do a re-trigger if Q was set rather than synthesizing an
+* interrupt in software
+*/
+ eoi_val = xive_esb_read(xd, XIVE_ESB_SET_PQ_00);
+ DBG_VERBOSE("eoi_val=%x\n", eoi_val);
+
+ /* Re-trigger if needed */
+ if ((eoi_val & XIVE_ESB_VAL_Q) && xd->trig_mmio)
+ out_be64(xd->trig_mmio, 0);
}
/* irq_chip eoi callback, called with irq descriptor lock held */
@@ -398,7 +399,7 @@ static void xive_irq_eoi(struct irq_data *d)
*/
if (!irqd_irq_disabled(d) && !irqd_is_forwarded_to_vcpu(d) &&
!(xd->flags & XIVE_IRQ_FLAG_NO_EOI))
- xive_do_source_eoi(irqd_to_hwirq(d), xd);
+ xive_do_source_eoi(xd);
else
xd->stale_p = true;
@@ -788,14 +789,7 @@ static int xive_irq_retrigger(struct irq_data *d)
* 11, then perform an EOI.
*/
xive_esb_read(xd, XIVE_ESB_SET_PQ_11);
-
- /*
-* Note: We pass "0" to the hw_irq argument in order to
-* avoid calling into the backend EOI code which we don't
-* want to do in the case of a re-trigger. Backends typically
-* only do EOI for LSIs anyway.
-*/
- xive_do_source_eoi(0, xd);
+ xive_do_source_eoi(xd);
return 1;
}
@@ -910,7 +904,7 @@ static int xive_irq_set_vcpu_affinity(struct irq_data *d,
void *state)
* while masked, the generic code will re-mask it anyway.
*/
if (!xd->saved_p)
- xive_do_source_eoi(hw_irq, xd);
+ xive_do_source_eoi(xd);
}
return 0;
@@ -1054,7 +1048,7 @@ static void xive_ipi_eoi(struct irq_data *d)
DBG_VERBOSE("IPI eoi: irq=%d [0x%lx] (HW IRQ 0x%x) pending=%02x\n",
d->irq, irqd_to_hwirq(d), xc->hw_ipi, xc->pending_prio);
- xive_do_source_eoi(xc->hw_ipi, >ipi_data);
+ xive_do_source_eoi(>ipi_data);
xive_do_queue_eoi(xc);
}
@@ -1440,7 +1434,7 @@ static void xive_flush_cpu_queue(unsigned int cpu, struct
xive_cpu *xc)
* still asserted. Otherwise do an MSI retrigger.
*/
[PATCH v2 04/13] powerpc/xive: Use cpu_to_node() instead of ibm, chip-id property
The 'chip_id' field of the XIVE CPU structure is used to choose a
target for a source located on the same chip when possible. This field
is assigned on the PowerNV platform using the "ibm,chip-id" property
on pSeries under KVM when NUMA nodes are defined but it is undefined
under PowerVM. The XIVE source structure has a similar field
'src_chip' which is only assigned on the PowerNV platform.
cpu_to_node() returns a compatible value on all platforms, 0 being the
default node. It will also give us the opportunity to set the affinity
of a source on pSeries when we can localize them.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index ee375daf8114..605238ca65e4 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -1342,16 +1342,11 @@ static int xive_prepare_cpu(unsigned int cpu)
xc = per_cpu(xive_cpu, cpu);
if (!xc) {
- struct device_node *np;
-
xc = kzalloc_node(sizeof(struct xive_cpu),
GFP_KERNEL, cpu_to_node(cpu));
if (!xc)
return -ENOMEM;
- np = of_get_cpu_node(cpu, NULL);
- if (np)
- xc->chip_id = of_get_ibm_chip_id(np);
- of_node_put(np);
+ xc->chip_id = cpu_to_node(cpu);
xc->hw_ipi = XIVE_BAD_IRQ;
per_cpu(xive_cpu, cpu) = xc;
--
2.26.2
[PATCH v2 05/13] powerpc/xive: Add a name to the IRQ domain
We hope one day to handle multiple irq_domain in the XIVE driver.
Start simple by setting the name using the DT node.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/xive-internal.h | 4 ++--
arch/powerpc/sysdev/xive/common.c| 10 +-
arch/powerpc/sysdev/xive/native.c| 2 +-
arch/powerpc/sysdev/xive/spapr.c | 2 +-
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/xive-internal.h
b/arch/powerpc/sysdev/xive/xive-internal.h
index d701af7fb48c..c07fadb9d264 100644
--- a/arch/powerpc/sysdev/xive/xive-internal.h
+++ b/arch/powerpc/sysdev/xive/xive-internal.h
@@ -63,8 +63,8 @@ struct xive_ops {
const char *name;
};
-bool xive_core_init(const struct xive_ops *ops, void __iomem *area, u32 offset,
- u8 max_prio);
+bool xive_core_init(struct device_node *np, const struct xive_ops *ops,
+ void __iomem *area, u32 offset, u8 max_prio);
__be32 *xive_queue_page_alloc(unsigned int cpu, u32 queue_shift);
int xive_core_debug_init(void);
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 605238ca65e4..7314b87d0b45 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -1310,9 +1310,9 @@ static const struct irq_domain_ops xive_irq_domain_ops = {
.xlate = xive_irq_domain_xlate,
};
-static void __init xive_init_host(void)
+static void __init xive_init_host(struct device_node *np)
{
- xive_irq_domain = irq_domain_add_nomap(NULL, XIVE_MAX_IRQ,
+ xive_irq_domain = irq_domain_add_nomap(np, XIVE_MAX_IRQ,
_irq_domain_ops, NULL);
if (WARN_ON(xive_irq_domain == NULL))
return;
@@ -1508,8 +1508,8 @@ void xive_shutdown(void)
xive_ops->shutdown();
}
-bool __init xive_core_init(const struct xive_ops *ops, void __iomem *area, u32
offset,
- u8 max_prio)
+bool __init xive_core_init(struct device_node *np, const struct xive_ops *ops,
+ void __iomem *area, u32 offset, u8 max_prio)
{
xive_tima = area;
xive_tima_offset = offset;
@@ -1520,7 +1520,7 @@ bool __init xive_core_init(const struct xive_ops *ops,
void __iomem *area, u32 o
__xive_enabled = true;
pr_devel("Initializing host..\n");
- xive_init_host();
+ xive_init_host(np);
pr_devel("Initializing boot CPU..\n");
diff --git a/arch/powerpc/sysdev/xive/native.c
b/arch/powerpc/sysdev/xive/native.c
index cb58ec7ce77a..c3182ec9ed65 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -622,7 +622,7 @@ bool __init xive_native_init(void)
xive_native_setup_pools();
/* Initialize XIVE core with our backend */
- if (!xive_core_init(_native_ops, tima, TM_QW3_HV_PHYS,
+ if (!xive_core_init(np, _native_ops, tima, TM_QW3_HV_PHYS,
max_prio)) {
opal_xive_reset(OPAL_XIVE_MODE_EMU);
return false;
diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c
index 1e3674d7ea7b..6610e5149d5a 100644
--- a/arch/powerpc/sysdev/xive/spapr.c
+++ b/arch/powerpc/sysdev/xive/spapr.c
@@ -857,7 +857,7 @@ bool __init xive_spapr_init(void)
}
/* Initialize XIVE core with our backend */
- if (!xive_core_init(_spapr_ops, tima, TM_QW1_OS, max_prio))
+ if (!xive_core_init(np, _spapr_ops, tima, TM_QW1_OS, max_prio))
return false;
pr_info("Using %dkB queues\n", 1 << (xive_queue_shift - 10));
--
2.26.2
Re: [PATCH] cxl: Reduce scope for the variable “mm” in cxllib_get_PE_attributes()
>> A local variable was used only within an if branch. >> Thus move the definition for the variable “mm” into the corresponding >> code block. > > You did nothing here except add a checkpatch warning :( elfring@Sonne:~/Projekte/Linux/next-patched> scripts/checkpatch.pl /home/elfring/Projekte/Bau/Linux/scripts/Coccinelle/tuning1/next/20201204/Flicken/0001-cxl-Reduce-scope-for-the-variable-mm-in-cxllib_get_P.patch total: 0 errors, 0 warnings, 16 lines checked Regards, Markus
[PATCH] cxl: Reduce scope for the variable “mm” in cxllib_get_PE_attributes()
From: Markus Elfring
Date: Thu, 10 Dec 2020 14:14:07 +0100
A local variable was used only within an if branch.
Thus move the definition for the variable “mm” into the corresponding
code block.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/misc/cxl/cxllib.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/misc/cxl/cxllib.c b/drivers/misc/cxl/cxllib.c
index 2a1783f32254..53b919856426 100644
--- a/drivers/misc/cxl/cxllib.c
+++ b/drivers/misc/cxl/cxllib.c
@@ -170,8 +170,6 @@ int cxllib_get_PE_attributes(struct task_struct *task,
unsigned long translation_mode,
struct cxllib_pe_attributes *attr)
{
- struct mm_struct *mm = NULL;
-
if (translation_mode != CXL_TRANSLATED_MODE &&
translation_mode != CXL_REAL_MODE)
return -EINVAL;
@@ -182,7 +180,7 @@ int cxllib_get_PE_attributes(struct task_struct *task,
true);
attr->lpid = mfspr(SPRN_LPID);
if (task) {
- mm = get_task_mm(task);
+ struct mm_struct *mm = get_task_mm(task);
if (mm == NULL)
return -EINVAL;
/*
--
2.29.2
Re: [PATCH] cxl: Reduce scope for the variable “mm” in cxllib_get_PE_attributes()
On Thu, Dec 10, 2020 at 03:35:38PM +0100, Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 10 Dec 2020 14:14:07 +0100 > > A local variable was used only within an if branch. > Thus move the definition for the variable “mm” into the corresponding > code block. You did nothing here except add a checkpatch warning :( dropped. greg k-h
Re: [PATCH 09/13] powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_SHIFT_BUG
On 12/8/20 6:39 PM, Greg Kurz wrote:
> On Tue, 8 Dec 2020 16:11:20 +0100
> Cédric Le Goater wrote:
>
>> This flag was used to support the PHB4 LSIs on P9 DD1 and we have
>> stopped supporting this CPU when DD2 came out. See skiboot commit:
>>
>> https://github.com/open-power/skiboot/commit/0b0d15e3c170
>>
>> Signed-off-by: Cédric Le Goater
>> ---
>
> Reviewed-by: Greg Kurz
>
> Just a minor suggestion in case you need to post a v2. See below.
>
>> arch/powerpc/include/asm/opal-api.h | 2 +-
>> arch/powerpc/include/asm/xive.h | 2 +-
>> arch/powerpc/kvm/book3s_xive_native.c | 3 ---
>> arch/powerpc/kvm/book3s_xive_template.c | 3 ---
>> arch/powerpc/sysdev/xive/common.c | 8
>> arch/powerpc/sysdev/xive/native.c | 2 --
>> 6 files changed, 2 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/opal-api.h
>> b/arch/powerpc/include/asm/opal-api.h
>> index 1dffa3cb16ba..48ee604ca39a 100644
>> --- a/arch/powerpc/include/asm/opal-api.h
>> +++ b/arch/powerpc/include/asm/opal-api.h
>> @@ -1091,7 +1091,7 @@ enum {
>> OPAL_XIVE_IRQ_TRIGGER_PAGE = 0x0001,
>> OPAL_XIVE_IRQ_STORE_EOI = 0x0002,
>> OPAL_XIVE_IRQ_LSI = 0x0004,
>> -OPAL_XIVE_IRQ_SHIFT_BUG = 0x0008,
>> +OPAL_XIVE_IRQ_SHIFT_BUG = 0x0008, /* P9 DD1.0 workaround */
>
> Maybe you can even comment the entire line so that any future
> tentative to use that flag breaks build ?
This file is "copied" from OPAL. I think it is best to keep them
in sync.
>
>> OPAL_XIVE_IRQ_MASK_VIA_FW = 0x0010,
>> OPAL_XIVE_IRQ_EOI_VIA_FW= 0x0020,
>> };
>> diff --git a/arch/powerpc/include/asm/xive.h
>> b/arch/powerpc/include/asm/xive.h
>> index d332dd9a18de..ff805885a028 100644
>> --- a/arch/powerpc/include/asm/xive.h
>> +++ b/arch/powerpc/include/asm/xive.h
>> @@ -60,7 +60,7 @@ struct xive_irq_data {
>> };
>> #define XIVE_IRQ_FLAG_STORE_EOI 0x01
>> #define XIVE_IRQ_FLAG_LSI 0x02
>> -#define XIVE_IRQ_FLAG_SHIFT_BUG 0x04
>> +#define XIVE_IRQ_FLAG_SHIFT_BUG 0x04 /* P9 DD1.0 workaround */
>
> Same here, with an extra cleanup to stop using it when initializing
> xive_irq_flags[] in common.c.
Yes. Since this is an internal flag, we can simply remove it.
Thanks,
C.
>
>> #define XIVE_IRQ_FLAG_MASK_FW 0x08
>> #define XIVE_IRQ_FLAG_EOI_FW0x10
>> #define XIVE_IRQ_FLAG_H_INT_ESB 0x20
>> diff --git a/arch/powerpc/kvm/book3s_xive_native.c
>> b/arch/powerpc/kvm/book3s_xive_native.c
>> index 9b395381179d..170d1d04e1d1 100644
>> --- a/arch/powerpc/kvm/book3s_xive_native.c
>> +++ b/arch/powerpc/kvm/book3s_xive_native.c
>> @@ -37,9 +37,6 @@ static u8 xive_vm_esb_load(struct xive_irq_data *xd, u32
>> offset)
>> * ordering.
>> */
>>
>> -if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
>> -offset |= offset << 4;
>> -
>> val = in_be64(xd->eoi_mmio + offset);
>> return (u8)val;
>> }
>> diff --git a/arch/powerpc/kvm/book3s_xive_template.c
>> b/arch/powerpc/kvm/book3s_xive_template.c
>> index 4ad3c0279458..ece36e024a8f 100644
>> --- a/arch/powerpc/kvm/book3s_xive_template.c
>> +++ b/arch/powerpc/kvm/book3s_xive_template.c
>> @@ -61,9 +61,6 @@ static u8 GLUE(X_PFX,esb_load)(struct xive_irq_data *xd,
>> u32 offset)
>> if (offset == XIVE_ESB_SET_PQ_10 && xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
>> offset |= XIVE_ESB_LD_ST_MO;
>>
>> -if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
>> -offset |= offset << 4;
>> -
>> val =__x_readq(__x_eoi_page(xd) + offset);
>> #ifdef __LITTLE_ENDIAN__
>> val >>= 64-8;
>> diff --git a/arch/powerpc/sysdev/xive/common.c
>> b/arch/powerpc/sysdev/xive/common.c
>> index 411cba12d73b..a9259470bf9f 100644
>> --- a/arch/powerpc/sysdev/xive/common.c
>> +++ b/arch/powerpc/sysdev/xive/common.c
>> @@ -200,10 +200,6 @@ static notrace u8 xive_esb_read(struct xive_irq_data
>> *xd, u32 offset)
>> if (offset == XIVE_ESB_SET_PQ_10 && xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
>> offset |= XIVE_ESB_LD_ST_MO;
>>
>> -/* Handle HW errata */
>> -if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
>> -offset |= offset << 4;
>> -
>> if ((xd->flags & XIVE_IRQ_FLAG_H_INT_ESB) && xive_ops->esb_rw)
>> val = xive_ops->esb_rw(xd->hw_irq, offset, 0, 0);
>> else
>> @@ -214,10 +210,6 @@ static notrace u8 xive_esb_read(struct xive_irq_data
>> *xd, u32 offset)
>>
>> static void xive_esb_write(struct xive_irq_data *xd, u32 offset, u64 data)
>> {
>> -/* Handle HW errata */
>> -if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
>> -offset |= offset << 4;
>> -
>> if ((xd->flags & XIVE_IRQ_FLAG_H_INT_ESB) && xive_ops->esb_rw)
>> xive_ops->esb_rw(xd->hw_irq, offset, data, 1);
>> else
>> diff --git a/arch/powerpc/sysdev/xive/native.c
>> b/arch/powerpc/sysdev/xive/native.c
>> index 5f1e5aed8ab4..0310783241b5 100644
>> ---
Re: [PATCH] powerpc/rtas: fix typo of ibm,open-errinjct in rtas filter
On 9/12/20 6:54 am, Tyrel Datwyler wrote:
Commit bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
introduced the following error when invoking the errinjct userspace
tool.
[root@ltcalpine2-lp5 librtas]# errinjct open
[327884.071171] sys_rtas: RTAS call blocked - exploit attempt?
[327884.071186] sys_rtas: token=0x26, nargs=0 (called by errinjct)
errinjct: Could not open RTAS error injection facility
errinjct: librtas: open: Unexpected I/O error
The entry for ibm,open-errinjct in rtas_filter array has a typo where
the "j" is omitted in the rtas call name. After fixing this typo the
errinjct tool functions again as expected.
[root@ltcalpine2-lp5 linux]# errinjct open
RTAS error injection facility open, token = 1
fixes: bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
Signed-off-by: Tyrel Datwyler
Thanks for catching this!
Acked-by: Andrew Donnellan
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: Linux kernel: powerpc: RTAS calls can be used to compromise kernel integrity
On 24/11/20 1:41 am, Andrew Donnellan wrote: On 9/10/20 12:20 pm, Andrew Donnellan wrote: The Linux kernel for powerpc has an issue with the Run-Time Abstraction Services (RTAS) interface, allowing root (or CAP_SYS_ADMIN users) in a VM to overwrite some parts of memory, including kernel memory. This issue impacts guests running on top of PowerVM or KVM hypervisors (pseries platform), and does *not* impact bare-metal machines (powernv platform). CVE-2020-2 has been assigned. A minor regression has been identified, affecting the ibm,open-errinjct RTAS call. A patch is available at https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20201208195434.8289-1-tyr...@linux.ibm.com/ Thanks to Tyrel Datwyler for identifying and fixing this issue. -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH 1/2] ALSA: ppc: drop if block with always false condition
On Thu, 26 Nov 2020 17:59:49 +0100, Uwe Kleine-König wrote: > The remove callback is only called for devices that were probed > successfully before. As the matching probe function cannot complete > without error if dev->match_id != PS3_MATCH_ID_SOUND, we don't have to > check this here. Applied to powerpc/next. [1/2] ALSA: ppc: drop if block with always false condition https://git.kernel.org/powerpc/c/7ff94669e7d8e50756cd57947283381ae9665759 [2/2] powerpc/ps3: make system bus's remove and shutdown callbacks return void https://git.kernel.org/powerpc/c/6d247e4d264961aa3b871290f9b11a48d5a567f2 cheers
Re: [PATCH] powerpc: Use common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro
On Fri, 27 Nov 2020 15:07:37 +0800, Youling Tang wrote: > Use the common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro rule for > the linker script in an effort. Applied to powerpc/next. [1/1] powerpc: Use common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro https://git.kernel.org/powerpc/c/a21df7a1d6ca9bd387a17841863a99431c4aa730 cheers
Re: [PATCH v2 0/4] Powerpc: Better preemption for shared processor
On Wed, 2 Dec 2020 10:34:52 +0530, Srikar Dronamraju wrote: > Currently, vcpu_is_preempted will return the yield_count for > shared_processor. On a PowerVM LPAR, Phyp schedules at SMT8 core boundary > i.e all CPUs belonging to a core are either group scheduled in or group > scheduled out. This can be used to better predict non-preempted CPUs on > PowerVM shared LPARs. > > perf stat -r 5 -a perf bench sched pipe -l 1000 (lesser time is better) > > [...] Applied to powerpc/next. [1/4] powerpc: Refactor is_kvm_guest() declaration to new header https://git.kernel.org/powerpc/c/92cc6bf01c7f4c5cfefd1963985c0064687ebeda [2/4] powerpc: Rename is_kvm_guest() to check_kvm_guest() https://git.kernel.org/powerpc/c/16520a858a995742c2d2248e86a6026bd0316562 [3/4] powerpc: Reintroduce is_kvm_guest() as a fast-path check https://git.kernel.org/powerpc/c/a21d1becaa3f17a97b933ffa677b526afc514ec5 [4/4] powerpc/paravirt: Use is_kvm_guest() in vcpu_is_preempted() https://git.kernel.org/powerpc/c/ca3f969dcb111d35674b66bdcb72beb2c426b9b5 cheers
Re: [PATCH] powerpc/xmon: Fix build failure for 8xx
On Mon, 30 Nov 2020 09:14:06 +0530, Ravi Bangoria wrote: > With CONFIG_PPC_8xx and CONFIG_XMON set, kernel build fails with > > arch/powerpc/xmon/xmon.c:1379:12: error: 'find_free_data_bpt' defined > but not used [-Werror=unused-function] > > Fix it by enclosing find_free_data_bpt() inside #ifndef CONFIG_PPC_8xx. Applied to powerpc/next. [1/1] powerpc/xmon: Fix build failure for 8xx https://git.kernel.org/powerpc/c/f3e90408019b353fd1fcd338091fb8d3c4a1c1a5 cheers
Re: [PATCH] powernv/pci: Print an error when device enable is blocked
On Thu, 9 Apr 2020 16:13:37 +1000, Oliver O'Halloran wrote: > If the platform decides to block enabling the device nothing is printed > currently. This can lead to some confusion since the dmesg output will > usually print an error with no context e.g. > > e1000e: probe of 0022:01:00.0 failed with error -22 > > This shouldn't be spammy since pci_enable_device() already prints a > messages when it succeeds. Applied to powerpc/next. [1/1] powernv/pci: Print an error when device enable is blocked https://git.kernel.org/powerpc/c/6c58b1b41b19c00099e4771ee55e21eb9aa245c1 cheers
Re: [PATCH v3 0/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too
On Thu, 19 Nov 2020 17:01:54 +0100, Oleg Nesterov wrote: > Can we finally fix this problem? ;) > > My previous attempt was ignored, see > > https://lore.kernel.org/lkml/20190917121256.ga8...@redhat.com/ > > Now that gpr_get() was changed to use membuf API we can make a simpler fix. > > [...] Applied to powerpc/next. [1/2] powerpc/ptrace: Simplify gpr_get()/tm_cgpr_get() https://git.kernel.org/powerpc/c/640586f8af356096e084d69a9909d217852bde48 [2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too https://git.kernel.org/powerpc/c/324a69467f12652b21b17f9644faa967d3d8bbdf cheers
Re: [RFC PATCH] powerpc: show registers when unwinding interrupt frames
On Sat, 7 Nov 2020 12:33:05 +1000, Nicholas Piggin wrote: > It's often useful to know the register state for interrupts in > the stack frame. In the below example (with this patch applied), > the important information is the state of the page fault. > > A blatant case like this probably rather should have the page > fault regs passed down to the warning, but quite often there are > less obvious cases where an interrupt shows up that might give > some more clues. > > [...] Applied to powerpc/next. [1/1] powerpc: show registers when unwinding interrupt frames https://git.kernel.org/powerpc/c/bf13718bc57ada25016d9fe80323238d0b94506e cheers
Re: [PATCH 0/8] powerpc/64s: fix and improve machine check handling
On Sat, 28 Nov 2020 17:07:20 +1000, Nicholas Piggin wrote: > First patch is a nasty memory scribble introduced by me :( That > should go into fixes. > > The next ones could wait for next merge window. They get things to the > point where misbehaving or buggy guest isn't so painful for the host, > and also get the guest SLB dumping code working (because the host no > longer clears them before delivering the MCE to the guest). > > [...] Patches 2-8 applied to powerpc/next. [2/8] powerpc/64s/powernv: Allow KVM to handle guest machine check details https://git.kernel.org/powerpc/c/0ce2382657f39ced2adbb927355360c3aaeb05f8 [3/8] KVM: PPC: Book3S HV: Don't attempt to recover machine checks for FWNMI enabled guests https://git.kernel.org/powerpc/c/067c9f9c98c8804b07751994c51d8557e440821e [4/8] KVM: PPC: Book3S HV: Ratelimit machine check messages coming from guests https://git.kernel.org/powerpc/c/1d15ffdfc94127d75e04a88344ee1ce8c79f05fd [5/8] powerpc/64s/powernv: Ratelimit harmless HMI error printing https://git.kernel.org/powerpc/c/f4b239e4c6bddf63d00cd460eabb933232dbc326 [6/8] powerpc/64s/pseries: Add ERAT specific machine check handler https://git.kernel.org/powerpc/c/82f70a05108c98aea4f140067c44a606262d2af7 [7/8] powerpc/64s: Remove "Host" from MCE logging https://git.kernel.org/powerpc/c/4a869531ddbf5939c45eab6ff389e4e58c8ed19c [8/8] powerpc/64s: Tidy machine check SLB logging https://git.kernel.org/powerpc/c/865ae6f27789dcc3f92341d935f4439e8730a9fe cheers
Re: [PATCH v14 1/9] powerpc/feature: Use CONFIG_PPC64 instead of __powerpc64__ to define possible features
On Fri, 27 Nov 2020 00:09:58 +1100, Michael Ellerman wrote: > In order to build VDSO32 for PPC64, we need to have CPU_FTRS_POSSIBLE > and CPU_FTRS_ALWAYS independant of whether we are building the > 32 bits VDSO or the 64 bits VDSO. > > Use #ifdef CONFIG_PPC64 instead of #ifdef __powerpc64__ Applied to powerpc/next. [1/9] powerpc/feature: Use CONFIG_PPC64 instead of __powerpc64__ to define possible features https://git.kernel.org/powerpc/c/8d1eeabf253657ae3e76970514f30b7e53a6898f [2/9] powerpc/processor: Move cpu_relax() into asm/vdso/processor.h https://git.kernel.org/powerpc/c/8f8cffd9df81612b5b06d2c57ebf74f8961b41be [3/9] powerpc/time: Move timebase functions into new asm/vdso/timebase.h https://git.kernel.org/powerpc/c/d26b3817d9eefae6b39c1ea5daba5e72624e [4/9] powerpc/time: Fix mftb()/get_tb() for use with the compat VDSO https://git.kernel.org/powerpc/c/5c189c523e78d4a70e874477e4b0628fd74207e4 [5/9] powerpc/barrier: Use CONFIG_PPC64 for barrier selection https://git.kernel.org/powerpc/c/1f1676bb2dd52c1054db8476d6387e6dcf62a1ba [6/9] powerpc/vdso: Prepare for switching VDSO to generic C implementation. https://git.kernel.org/powerpc/c/ce7d8056e38b770f070fc4499c577322b6ccb9c7 [7/9] powerpc/vdso: Save and restore TOC pointer on PPC64 https://git.kernel.org/powerpc/c/7fec9f5d41979dbe273ec337327d5939449562e7 [8/9] powerpc/vdso: Switch VDSO to generic C implementation. https://git.kernel.org/powerpc/c/ab037dd87a2f946556850e204c06cbd7a2a19390 [9/9] powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32 https://git.kernel.org/powerpc/c/d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e cheers
Re: [PATCH 1/3] powerpc: Make NUMA depend on SMP
On Tue, 24 Nov 2020 23:05:45 +1100, Michael Ellerman wrote: > Our Kconfig allows NUMA to be enabled without SMP, but none of > our defconfigs use that combination. This means it can easily be > broken inadvertently by code changes, which has happened recently. > > Although it's theoretically possible to have a machine with a single > CPU and multiple memory nodes, I can't think of any real systems where > that's the case. Even so if such a system exists, it can just run an > SMP kernel anyway. > > [...] Applied to powerpc/next. [1/3] powerpc: Make NUMA depend on SMP https://git.kernel.org/powerpc/c/25395cd2f8cb24ce6a5ce073c898acfb091e06cf [2/3] powerpc: Make NUMA default y for powernv https://git.kernel.org/powerpc/c/4c28b32b886f1489c5f510ed8e3f0c4e3dcb59f5 [3/3] powerpc: Update NUMA Kconfig description & help text https://git.kernel.org/powerpc/c/bae80c27fc2195b9e5723d7b05c592e0874f4ba9 cheers
Re: [PATCH] powerpc/wrapper: add "-z rodynamic" when using LLD
On Wed, 18 Nov 2020 14:39:10 -0800, Bill Wendling wrote: > Normally all read-only sections precede SHF_WRITE sections. .dynamic and > .got have the SHF_WRITE flag; .dynamic probably because of DT_DEBUG. LLD > emits an error when this happens, so use "-z rodynamic" to mark .dynamic > as read-only. Applied to powerpc/next. [1/1] powerpc/boot/wrapper: Add "-z rodynamic" when using LLD https://git.kernel.org/powerpc/c/26ba9f9651d802ba38583138f43fea5dc7eb0fd6 cheers
Re: [PATCH] powerpc/boot: move the .got section to after the .dynamic section
On Fri, 16 Oct 2020 17:01:51 -0700, Bill Wendling wrote: > Both .dynamic and .got are RELRO sections and should be placed together, > and LLD emits an error: > > ld.lld: error: section: .got is not contiguous with other relro sections > > Place them together to avoid this. Applied to powerpc/next. [1/1] powerpc/boot: Move the .got section to after the .dynamic section https://git.kernel.org/powerpc/c/a538d184e3f0e3b5f800c5ab148e83bb5cdd0133 cheers
Re: [PATCH] powerpc/64: Fix an EMIT_BUG_ENTRY in head_64.S
On Mon, 30 Nov 2020 11:44:04 +1100, Jordan Niethe wrote:
> Commit 63ce271b5e37 ("powerpc/prom: convert PROM_BUG() to standard
> trap") added an EMIT_BUG_ENTRY for the trap after the branch to
> start_kernel(). The EMIT_BUG_ENTRY was for the address "0b", however the
> trap was not labeled with "0". Hence the address used for bug is in
> relative_toc() where the previous "0" label is. Label the trap as "0" so
> the correct address is used.
Applied to powerpc/next.
[1/1] powerpc/64: Fix an EMIT_BUG_ENTRY in head_64.S
https://git.kernel.org/powerpc/c/fe18a35e685c9bdabc8b11b3e19deb85a068b75d
cheers
Re: [PATCH v2] powerpc: Allow relative pointers in bug table entries
On Tue, 1 Dec 2020 11:52:03 +1100, Jordan Niethe wrote: > This enables GENERIC_BUG_RELATIVE_POINTERS on Power so that 32-bit > offsets are stored in the bug entries rather than 64-bit pointers. > While this doesn't save space for 32-bit machines, use it anyway so > there is only one code path. Applied to powerpc/next. [1/1] powerpc: Allow relative pointers in bug table entries https://git.kernel.org/powerpc/c/1baa1f70ef77c4447628992ad50ab83213e2eb6c cheers
Re: [PATCH 1/2] powerpc/book3s64/kexec: Clear CIABR on kexec
On Mon, 7 Dec 2020 12:05:18 +1100, Jordan Niethe wrote: > The value in CIABR persists across kexec which can lead to unintended > results when the new kernel hits the old kernel's breakpoint. For > example: > > 0:mon> bi $loadavg_proc_show > 0:mon> b >typeaddress > 1 inst c0519060 loadavg_proc_show+0x0/0x130 > 0:mon> x > > [...] Applied to powerpc/next. [1/2] powerpc/book3s64/kexec: Clear CIABR on kexec https://git.kernel.org/powerpc/c/4bb3219837a3dcf58bce96c27db6e0cd48f3d9b2 [2/2] powerpc/powernv/idle: Restore CIABR after idle for Power9 https://git.kernel.org/powerpc/c/250ad7a45b1e58d580decfb935fc063c4cf56f91 cheers
Re: [PATCH] selftests/powerpc: Fix uninitialized variable warning
On Tue, 1 Dec 2020 14:54:03 +0530, Harish wrote:
> Patch fixes uninitialized variable warning in bad_accesses test
> which causes the selftests build to fail in older distibutions
>
> bad_accesses.c: In function âbad_accessâ:
> bad_accesses.c:52:9: error: âxâ may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
>printf("Bad - no SEGV! (%c)\n", x);
> ^
> cc1: all warnings being treated as errors
Applied to powerpc/next.
[1/1] selftests/powerpc: Fix uninitialized variable warning
https://git.kernel.org/powerpc/c/c9344769e2b46ba28b947bec7a8a8f0a091ecd57
cheers
Re: [PATCH v5] lkdtm/powerpc: Add SLB multihit test
On Mon, 30 Nov 2020 14:00:57 +0530, Ganesh Goudar wrote: > To check machine check handling, add support to inject slb > multihit errors. Applied to powerpc/next. [1/1] lkdtm/powerpc: Add SLB multihit test https://git.kernel.org/powerpc/c/3ba150fb21207e4a7f4b600eb2dbbe83f94571fe cheers
Re: [PATCH] powerpc/pseries: Define PCI bus speed for Gen4 and Gen5
On Mon, 30 Nov 2020 16:29:49 +0100, Frederic Barrat wrote: > Update bus speed definition for PCI Gen4 and 5. Applied to powerpc/next. [1/1] powerpc/pseries: Define PCI bus speed for Gen4 and Gen5 https://git.kernel.org/powerpc/c/c8754c517e37270a01b0561ad46ee647a721a09b cheers
Re: [PATCH] selftests/powerpc: update .gitignore
On Wed, 2 Dec 2020 01:44:27 +1100, Daniel Axtens wrote: > I did an in-place build of the self-tests and found that it left > the tree dirty. > > Add missed test binaries to .gitignore Applied to powerpc/next. [1/1] selftests/powerpc: update .gitignore https://git.kernel.org/powerpc/c/f0812f6ca8299e864fe0f41bd7ffdaae3ce7630e cheers
Re: [PATCH] powerpc/feature-fixups: use a semicolon rather than a comma
On Wed, 2 Dec 2020 01:43:44 +1100, Daniel Axtens wrote: > In a bunch of our security flushes, we use a comma rather than > a semicolon to 'terminate' an assignment. Nothing breaks, but > checkpatch picks it up if you copy it into another flush. > > Switch to semicolons for ending statements. Applied to powerpc/next. [1/1] powerpc/feature-fixups: use a semicolon rather than a comma https://git.kernel.org/powerpc/c/1fc0c27b14b93b2506953ef59e965d98ccc78122 cheers
Re: [PATCH] powerpc: add security.config, enforcing lockdown=integrity
On Thu, 3 Dec 2020 15:28:07 +1100, Daniel Axtens wrote: > It's sometimes handy to have a config that boots a bit like a system > under secure boot (forcing lockdown=integrity, without needing any > extra stuff like a command line option). > > This config file allows that, and also turns on a few assorted security > and hardening options for good measure. Applied to powerpc/next. [1/1] powerpc: add security.config, enforcing lockdown=integrity https://git.kernel.org/powerpc/c/ed2bbd2b8581313ca18a7c586a947f6cdd93a52a cheers
Re: [PATCH V4 0/5] ocxl: Mmio invalidation support
On Wed, 25 Nov 2020 16:50:08 +0100, Christophe Lombard wrote: > OpenCAPI 4.0/5.0 with TLBI/SLBI Snooping, is not used due to performance > problems caused by the PAU having to process all incoming TLBI/SLBI > commands which will cause them to back up on the PowerBus. > > When the Address Translation Mode requires TLB operations to be initiated > using MMIO registers, a set of registers like the following is used: > ⢠XTS MMIO ATSD0 LPARID register > ⢠XTS MMIO ATSD0 AVA register > ⢠XTS MMIO ATSD0 launch register, write access initiates a shoot down > ⢠XTS MMIO ATSD0 status register > > [...] Applied to powerpc/next. [1/5] ocxl: Assign a register set to a Logical Partition https://git.kernel.org/powerpc/c/fc1347b5feb685073ce2108c68cd8147340be016 [2/5] ocxl: Initiate a TLB invalidate command https://git.kernel.org/powerpc/c/19b311ca51e108b6d8d679496af8635fdc1984a8 [3/5] ocxl: Update the Process Element Entry https://git.kernel.org/powerpc/c/d731feea00c7c1734c9697558f2a1962c12d2710 [4/5] ocxl: Add mmu notifier https://git.kernel.org/powerpc/c/5f686eea4b3cb1d311f02b81ce4264e66a21d979 [5/5] ocxl: Add new kernel traces https://git.kernel.org/powerpc/c/98f5559a439a68e0773f42352f7c0806cac9e76e cheers
Re: [PATCH v3 1/3] powerpc/uaccess: Don't use "m<>" constraint with GCC 4.9
On Thu, 22 Oct 2020 09:29:19 + (UTC), Christophe Leroy wrote:
> GCC 4.9 sometimes fails to build with "m<>" constraint in
> inline assembly.
>
> CC lib/iov_iter.o
> In file included from ./arch/powerpc/include/asm/cmpxchg.h:6:0,
> from ./arch/powerpc/include/asm/atomic.h:11,
> from ./include/linux/atomic.h:7,
> from ./include/linux/crypto.h:15,
> from ./include/crypto/hash.h:11,
> from lib/iov_iter.c:2:
> lib/iov_iter.c: In function 'iovec_from_user.part.30':
> ./arch/powerpc/include/asm/uaccess.h:287:2: error: 'asm' operand has
> impossible constraints
> __asm__ __volatile__(\
> ^
> ./include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
> # define unlikely(x) __builtin_expect(!!(x), 0)
> ^
> ./arch/powerpc/include/asm/uaccess.h:583:34: note: in expansion of macro
> 'unsafe_op_wrap'
> #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
> ^
> ./arch/powerpc/include/asm/uaccess.h:329:10: note: in expansion of macro
> '__get_user_asm'
> case 4: __get_user_asm(x, (u32 __user *)ptr, retval, "lwz"); break; \
> ^
> ./arch/powerpc/include/asm/uaccess.h:363:3: note: in expansion of macro
> '__get_user_size_allowed'
>__get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \
>^
> ./arch/powerpc/include/asm/uaccess.h:100:2: note: in expansion of macro
> '__get_user_nocheck'
> __get_user_nocheck((x), (ptr), sizeof(*(ptr)), false)
> ^
> ./arch/powerpc/include/asm/uaccess.h:583:49: note: in expansion of macro
> '__get_user_allowed'
> #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
> ^
> lib/iov_iter.c:1663:3: note: in expansion of macro 'unsafe_get_user'
>unsafe_get_user(len, [i].iov_len, uaccess_end);
>^
> make[1]: *** [scripts/Makefile.build:283: lib/iov_iter.o] Error 1
>
> [...]
Patches 2-3 applied to powerpc/next.
[2/3] powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
https://git.kernel.org/powerpc/c/d85be8a49e733dcd23674aa6202870d54bf5600d
[3/3] powerpc: Fix update form addressing in inline assembly
https://git.kernel.org/powerpc/c/ff57698a9610fcf7d9c4469bf68c881eff22e2f8
cheers
Re: [PATCH v2 1/2] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32
On Tue, 13 Oct 2020 11:11:20 + (UTC), Christophe Leroy wrote: > On 8xx, we get the following features: > > [0.00] cpu_features = 0x0100 > [0.00] possible= 0x0120 > [0.00] always = 0x > > This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all > other configurations, the three lines should be equal. > > [...] Patch 2 applied to powerpc/next. [2/2] powerpc/feature: Remove CPU_FTR_NODSISRALIGN https://git.kernel.org/powerpc/c/7d47034551687eb6c15e8431d897a3758fc5f83e cheers
Re: [PATCH v2 1/2] powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
On Sun, 18 Oct 2020 17:25:17 + (UTC), Christophe Leroy wrote: > As stated in platform/44x/Kconfig, CONFIG_PPC_47x is not > compatible with 440 and 460 variants. > > This is confirmed in asm/cache.h as L1_CACHE_SHIFT is different > for 47x, meaning a kernel built for 47x will not run correctly > on a 440. > > [...] Applied to powerpc/next. [1/2] powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set https://git.kernel.org/powerpc/c/8b8319b181fd9d6821703fef1228b4dcde613a16 [2/2] powerpc/44x: Don't support 47x code and non 47x code at the same time https://git.kernel.org/powerpc/c/1f69aa0b89240653fdf708aada6a3d968447cce7 cheers
Re: [PATCH v2 00/25] powerpc: Switch signal 32 to using unsafe_put_user() and friends
On Tue, 18 Aug 2020 17:19:11 + (UTC), Christophe Leroy wrote: > This series leads to a reduction from 2.55s to 1.73s of > the system CPU time with the following microbench app > on an mpc832x with KUAP (approx 32%) > > This series replaces copies to users by unsafe_put_user() and friends > with user_write_access_begin() dance in signal32. > > [...] Applied to powerpc/next. [01/25] powerpc/signal: Move inline functions in signal.h https://git.kernel.org/powerpc/c/95593e930d7d067ca9bbee996c845248930a01f9 [02/25] powerpc/ptrace: Move declaration of ptrace_get_reg() and ptrace_set_reg() https://git.kernel.org/powerpc/c/67e364b3295f9dbf3b820d0edde86fb7c95efc98 [03/25] powerpc/ptrace: Consolidate reg index calculation https://git.kernel.org/powerpc/c/e009fa433542cd09d6279e361b767a1f44ffd29a [04/25] powerpc/ptrace: Create ptrace_get_fpr() and ptrace_put_fpr() https://git.kernel.org/powerpc/c/4d90eb97e292c7b14de8ba59fded35b340c73101 [05/25] powerpc/signal: Don't manage floating point regs when no FPU https://git.kernel.org/powerpc/c/b6254ced4da6cf28d49fbffe24ee4b3286dcb3f4 [06/25] powerpc/32s: Allow deselecting CONFIG_PPC_FPU on mpc832x https://git.kernel.org/powerpc/c/7d68c89169508064c460a1208f38ed0589d226fa [07/25] powerpc/signal: Remove BUG_ON() in handler_signal functions https://git.kernel.org/powerpc/c/3fcfb5d1bf731bdbd847c29df57a5372d8ea58d3 [08/25] powerpc/signal: Move access_ok() out of get_sigframe() https://git.kernel.org/powerpc/c/454b1abb588b3942655638a8bcf1ea4501260579 [09/25] powerpc/signal: Remove get_clean_sp() https://git.kernel.org/powerpc/c/0ecbc6ad18e324012234183e21805423f5e0cc79 [10/25] powerpc/signal: Call get_tm_stackpointer() from get_sigframe() https://git.kernel.org/powerpc/c/c180cb305c9bba094657259487d563c8fbfb648b [11/25] powerpc/signal: Refactor bad frame logging https://git.kernel.org/powerpc/c/7fe8f773ee248c726cec2addcdb94056049d6e34 [12/25] powerpc/signal32: Simplify logging in handle_rt_signal32() https://git.kernel.org/powerpc/c/debf122c777f361137a3114db7be8aecc65f6af2 [13/25] powerpc/signal32: Move handle_signal32() close to handle_rt_signal32() https://git.kernel.org/powerpc/c/3eea688be0ccba2221e047b7df6f9ae87361cdd6 [14/25] powerpc/signal32: Rename local pointers in handle_rt_signal32() https://git.kernel.org/powerpc/c/8e91cf8501f14d8b6727c71c98fd743e95e9b402 [15/25] powerpc/signal32: Misc changes to make handle_[rt_]_signal32() more similar https://git.kernel.org/powerpc/c/91b8ecd419cb46058e99b3a574184883c02b7729 [16/25] powerpc/signal32: Move signal trampoline setup to handle_[rt_]signal32 https://git.kernel.org/powerpc/c/8d33001dd650b88e915a1a13e2ca807350e374df [17/25] powerpc/signal32: Switch handle_signal32() to user_access_begin() logic https://git.kernel.org/powerpc/c/ad65f4909fd3736d84533784cd9ab76905536b34 [18/25] powerpc/signal32: Switch handle_rt_signal32() to user_access_begin() logic https://git.kernel.org/powerpc/c/9504db3e90b22dca19d8152ed5a82c68512dac0e [19/25] powerpc/signal32: Remove ifdefery in middle of if/else https://git.kernel.org/powerpc/c/f1cf4f93de2ff66313a091320d7683735816a0bc [20/25] signal: Add unsafe_put_compat_sigset() https://git.kernel.org/powerpc/c/14026b94ccfe626e512bc9fa01e0e72ee75c7a98 [21/25] powerpc/signal32: Add and use unsafe_put_sigset_t() https://git.kernel.org/powerpc/c/de781ebdf6b8a256742da4fd6b0e39bb22ed9fe3 [22/25] powerpc/signal32: Switch swap_context() to user_access_begin() logic https://git.kernel.org/powerpc/c/31147d7d6133ea17504b118114a191a8af85f3de [23/25] powerpc/signal: Create 'unsafe' versions of copy_[ck][fpr/vsx]_to_user() https://git.kernel.org/powerpc/c/b3484a1d4d1fb54ad7b615a13003d8bc11919c96 [24/25] powerpc/signal32: Isolate non-copy actions in save_user_regs() and save_tm_user_regs() https://git.kernel.org/powerpc/c/968c4fccd1bb8b440326dac5078ad87d17af4a47 [25/25] powerpc/signal32: Transform save_user_regs() and save_tm_user_regs() in 'unsafe' version https://git.kernel.org/powerpc/c/ef75e73182949a94bde169a774de1b62ae21fbbc cheers
Re: [PATCH v1 1/8] powerpc/32s: Always map kernel text and rodata with BATs
On Wed, 25 Nov 2020 07:10:46 + (UTC), Christophe Leroy wrote:
> Since commit 2b279c0348af ("powerpc/32s: Allow mapping with BATs with
> DEBUG_PAGEALLOC"), there is no real situation where mapping without
> BATs is required.
>
> In order to simplify memory handling, always map kernel text
> and rodata with BATs even when "nobats" kernel parameter is set.
>
> [...]
Applied to powerpc/next.
[1/8] powerpc/32s: Always map kernel text and rodata with BATs
https://git.kernel.org/powerpc/c/035b19a15a98907916a42a6b1d025877c42f10ad
[2/8] powerpc/32s: Don't hash_preload() kernel text
https://git.kernel.org/powerpc/c/79d1befe054ad4adb277fbd2d2756b1394eaf24e
[3/8] powerpc/32s: Fix an FTR_SECTION_ELSE
https://git.kernel.org/powerpc/c/7b107a71e732c298d684ee1bafd82f1a2be58d5e
[4/8] powerpc/32s: Don't use SPRN_SPRG_PGDIR in hash_page
https://git.kernel.org/powerpc/c/03d701c2d9b0091cf8e96cb49ab7d2a6a9f19937
[5/8] powerpc/603: Use SPRN_SDR1 to store the pgdir phys address
https://git.kernel.org/powerpc/c/c4a22611bf6ced73d86bdfc0604d7db8982a24a4
[6/8] powerpc/32: Simplify EXCEPTION_PROLOG_1 macro
https://git.kernel.org/powerpc/c/6285f9cff570bfd07b542840912c1d01bd5428e0
[7/8] powerpc/32s: Use SPRN_SPRG_SCRATCH2 in DSI prolog
https://git.kernel.org/powerpc/c/de1cd0790697e67b728de43e8657bb52f528bfb9
[8/8] powerpc/32: Use SPRN_SPRG_SCRATCH2 in exception prologs
https://git.kernel.org/powerpc/c/d2e006036082e2dc394c5ec86c5bb88cc27c0749
cheers
Re: [PATCH v1 00/30] Modernise VDSO setup
On Sun, 27 Sep 2020 09:16:16 + (UTC), Christophe Leroy wrote: > This series modernises the setup of VDSO: > - Switch to using _install_special_mapping() which has replaced > install_special_mapping() > - Move datapage in front of text like most other architectures to simplify > its localisation > - Perform link time symbol resolution instead of runtime > > This leads to a huge size reduction of vdso.c > > [...] Applied to powerpc/next. [01/30] powerpc/vdso: Stripped VDSO is not needed, don't build it https://git.kernel.org/powerpc/c/7fe2de246e21f01212a8923fbabb4ac84c944d4a [02/30] powerpc/vdso: Add missing includes and clean vdso_setup_syscall_map() https://git.kernel.org/powerpc/c/bc9d5bfc4d23fb3580e7da360f2c9bd878dda9b2 [03/30] powerpc/vdso: Rename syscall_map_32/64 to simplify vdso_setup_syscall_map() https://git.kernel.org/powerpc/c/1bb30b7a45976ae02d54fd43a8665e77314cc05e [04/30] powerpc/vdso: Remove get_page() in vdso_pagelist initialization https://git.kernel.org/powerpc/c/abcdbd039e6823305c2841d07a352fbd2343564e [05/30] powerpc/vdso: Remove NULL termination element in vdso_pagelist https://git.kernel.org/powerpc/c/35c1c7c0bc354d8c3d55bea3bf3e239797980013 [06/30] powerpc/vdso: Refactor 32 bits and 64 bits pages setup https://git.kernel.org/powerpc/c/3cf63825413c9eed2dae06070464efb27381bdac [07/30] powerpc/vdso: Remove unnecessary ifdefs in vdso_pagelist initialization https://git.kernel.org/powerpc/c/4fe0e3c1724e397845df75f64059bcea4ff590e8 [08/30] powerpc/vdso: Use VDSO size in arch_setup_additional_pages() https://git.kernel.org/powerpc/c/7461a4f79ba16dc7733c07c00883a10c7e46b602 [09/30] powerpc/vdso: Simplify arch_setup_additional_pages() exit https://git.kernel.org/powerpc/c/b2df3f60b452ab496adcef1b2f9c2560f6d8e8e0 [10/30] powerpc/vdso: Move to _install_special_mapping() and remove arch_vma_name() https://git.kernel.org/powerpc/c/c1bab64360e6850ca54305d2f1902dac829c9752 [11/30] powerpc/vdso: Provide vdso_remap() https://git.kernel.org/powerpc/c/526a9c4a7234cccf6d900c6e82d79356f974cbfd [12/30] powerpc/vdso: Replace vdso_base by vdso https://git.kernel.org/powerpc/c/c102f07667486dc4a6ae1e3fe7aa67135cb40e3e [13/30] powerpc/vdso: Move vdso datapage up front https://git.kernel.org/powerpc/c/511157ab641eb6bedd00d62673388e78a4f871cf [14/30] powerpc/vdso: Simplify __get_datapage() https://git.kernel.org/powerpc/c/591857b635c1f635cae556e1b1f9d81808242493 [15/30] powerpc/vdso: Remove unused \tmp param in __get_datapage() https://git.kernel.org/powerpc/c/550e6074c106e1a6fb57dfef62f0daede12d832c [16/30] powerpc/vdso: Retrieve sigtramp offsets at buildtime https://git.kernel.org/powerpc/c/91bf695596f594e42d69d70deb2ae53cafecf77c [17/30] powerpc/vdso: Use builtin symbols to locate fixup section https://git.kernel.org/powerpc/c/ed07f6353ddf19e51c4db6d2be72ca97f7ed8a08 [18/30] powerpc/vdso: Merge __kernel_sync_dicache_p5() into __kernel_sync_dicache() https://git.kernel.org/powerpc/c/0fc980db9a404a993c4ed542369a745d8a14b0b7 [19/30] powerpc/vdso: Remove vdso32_pages and vdso64_pages https://git.kernel.org/powerpc/c/b7fe9c15b57d767fda250e8eff79be435996ef33 [20/30] powerpc/vdso: Remove __kernel_datapage_offset https://git.kernel.org/powerpc/c/49bf59fd0371b1053a17021f27605f43071584ee [21/30] powerpc/vdso: Remove runtime generated sigtramp offsets https://git.kernel.org/powerpc/c/899367ea50637f382fdc5c927fe47e6090d4aefe [22/30] powerpc/vdso: Remove vdso_patches[] and associated functions https://git.kernel.org/powerpc/c/5cda7c75493fd17a010d7399e39fda6619f69043 [23/30] powerpc/vdso: Remove unused text member in struct lib32/64_elfinfo https://git.kernel.org/powerpc/c/e113f8ef1c7e5fd79b440e5565c8552b36122bfa [24/30] powerpc/vdso: Remove symbol section information in struct lib32/64_elfinfo https://git.kernel.org/powerpc/c/6ed613ad572a84c175629fc8657a197c6415b7d6 [25/30] powerpc/vdso: Remove lib32_elfinfo and lib64_elfinfo https://git.kernel.org/powerpc/c/67a354051da28d482e53146def212b102664ce0e [26/30] powerpc/vdso: Remove vdso_setup() https://git.kernel.org/powerpc/c/a4ccd64acb8c08ce8d36001cdd06477deec6ae89 [27/30] powerpc/vdso: Remove vdso_ready https://git.kernel.org/powerpc/c/23c4ceaf1a457808d031c666760fa325c7b7f23f [28/30] powerpc/vdso: Remove DBG() https://git.kernel.org/powerpc/c/e90903203d94d0a0d0e8ebc979aa0617a7bbe9a3 [29/30] powerpc/vdso: Remove VDSO32_LBASE and VDSO64_LBASE https://git.kernel.org/powerpc/c/676155ab239dc2035d5306438b45695b6fa165e2 [30/30] powerpc/vdso: Cleanup vdso.h https://git.kernel.org/powerpc/c/65d2150c89121a49e4bd4abbb99c436c77003eed cheers
Re: [PATCH] powerpc/xmon: Change printk() to pr_cont()
On Fri, 4 Dec 2020 10:35:38 + (UTC), Christophe Leroy wrote: > Since some time now, printk() adds carriage return, leading to > unusable xmon output: > > [ 54.288722] sysrq: Entering xmon > [ 54.292209] Vector: 0 at [cace3d2c] > [ 54.292274] pc: > [ 54.292331] c0023650 > [ 54.292468] : xmon+0x28/0x58 > [ 54.292519] > [ 54.292574] lr: > [ 54.292630] c0023724 > [ 54.292749] : sysrq_handle_xmon+0xa4/0xfc > [ 54.292801] > [ 54.292867] sp: cace3de8 > [ 54.292931]msr: 9032 > [ 54.292999] current = 0xc28d > [ 54.293072] pid = 377, comm = sh > [ 54.293157] Linux version 5.10.0-rc6-s3k-dev-01364-gedf13f0ccd76-dirty > (r...@po17688vm.idsi0.si.c-s.fr) (powerpc64-linux-gcc (GCC) 10.1.0, GNU ld > (GNU Binutils) 2.34) #4211 PREEMPT Fri Dec 4 09:32:11 UTC 2020 > [ 54.293287] enter ? for help > [ 54.293470] [cace3de8] > [ 54.293532] c0023724 > [ 54.293654] sysrq_handle_xmon+0xa4/0xfc > [ 54.293711] (unreliable) > [ 54.293859] [cace3e18] > [ 54.293918] c03885a8 > [ 54.294056] __handle_sysrq+0xe4/0x1d4 > [ 54.294108] > [ 54.294255] [cace3e48] > [ 54.294314] c0388704 > [ 54.294441] write_sysrq_trigger+0x34/0x74 > [ 54.294493] > [ 54.294641] [cace3e68] > [ 54.294700] c01f65d0 > [ 54.294822] proc_reg_write+0xac/0x11c > [ 54.294875] > [ 54.295023] [cace3e88] > [ 54.295082] c0179910 > [ 54.295198] vfs_write+0x134/0x46c > [ 54.295250] > [ 54.295396] [cace3f08] > [ 54.295455] c0179de8 > [ 54.295567] ksys_write+0x78/0x11c > [ 54.295619] > [ 54.295766] [cace3f38] > [ 54.295825] c00110d0 > [ 54.295951] ret_from_syscall+0x0/0x34 > [ 54.296002] > [ 54.296159] --- Exception: c01 (System Call) at > [ 54.296217] 0fd4e784 > [ 54.296303] > [ 54.296375] SP (7fca6ff0) is in userspace > [ 54.296431] mon> > [ 54.296484] > > [...] Applied to powerpc/next. [1/1] powerpc/xmon: Change printk() to pr_cont() https://git.kernel.org/powerpc/c/7c6c86b36a36dd4a13d30bba07718e767aa2e7a1 cheers
Re: [PATCH] powerpc/time: Remove ifdef in get_vtb()
On Thu, 1 Oct 2020 10:59:20 + (UTC), Christophe Leroy wrote: > SPRN_VTB and CPU_FTR_ARCH_207S are always defined, > no need of an ifdef. Applied to powerpc/next. [1/1] powerpc/time: Remove ifdef in get_vtb() https://git.kernel.org/powerpc/c/c3cb5dbd85dbd9ae51fadf867782dc34806f04d8 cheers
Re: [PATCH] powerpc/mm: Remove useless #ifndef CPU_FTR_COHERENT_ICACHE in mem.c
On Mon, 12 Oct 2020 08:02:30 + (UTC), Christophe Leroy wrote:
> Since commit 10b35d9978ac ("[PATCH] powerpc: merged asm/cputable.h"),
> CPU_FTR_COHERENT_ICACHE has always been defined.
>
> Remove the #ifndef CPU_FTR_COHERENT_ICACHE block.
Applied to powerpc/next.
[1/1] powerpc/mm: Remove useless #ifndef CPU_FTR_COHERENT_ICACHE in mem.c
https://git.kernel.org/powerpc/c/1a1be322178ca8097abeee244262ce0da5b519a9
cheers
Re: [PATCH] powerpc/mm: MMU_FTR_NEED_DTLB_SW_LRU is only possible with CONFIG_PPC_83xx
On Mon, 12 Oct 2020 08:05:49 + (UTC), Christophe Leroy wrote: > Only mpc83xx will set MMU_FTR_NEED_DTLB_SW_LRU and its > definition is enclosed in #ifdef CONFIG_PPC_83xx. > > Make MMU_FTR_NEED_DTLB_SW_LRU possible only when > CONFIG_PPC_83xx is set. Applied to powerpc/next. [1/1] powerpc/mm: MMU_FTR_NEED_DTLB_SW_LRU is only possible with CONFIG_PPC_83xx https://git.kernel.org/powerpc/c/b68e3a3dff97bdc1cba79dc5f80cede8a2419cac cheers
Re: [PATCH] powerpc/mm: Fix verification of MMU_FTR_TYPE_44x
On Sat, 10 Oct 2020 17:30:59 + (UTC), Christophe Leroy wrote: > MMU_FTR_TYPE_44x cannot be checked by cpu_has_feature() > > Use mmu_has_feature() instead Applied to powerpc/next. [1/1] powerpc/mm: Fix verification of MMU_FTR_TYPE_44x https://git.kernel.org/powerpc/c/17179aeb9d34cc81e1a4ae3f85e5b12b13a1f8d0 cheers
Re: [PATCH] powerpc/mm: Desintegrate MMU_FTR_PPCAS_ARCH_V2
On Mon, 12 Oct 2020 08:04:24 + (UTC), Christophe Leroy wrote: > MMU_FTR_PPCAS_ARCH_V2 is defined in cpu_table.h > as MMU_FTR_TLBIEL | MMU_FTR_16M_PAGE. > > MMU_FTR_TLBIEL and MMU_FTR_16M_PAGE are defined in mmu.h > > MMU_FTR_PPCAS_ARCH_V2 is used only in mmu.h and it is used only once. > > [...] Applied to powerpc/next. [1/1] powerpc/mm: Desintegrate MMU_FTR_PPCAS_ARCH_V2 https://git.kernel.org/powerpc/c/0e8ff4f8d2faa2e3381e774c9e2fb975e8b4598f cheers
Re: [PATCH] powerpc: inline iomap accessors
On Sat, 21 Nov 2020 17:59:19 + (UTC), Christophe Leroy wrote:
> ioreadXX()/ioreadXXbe() accessors are equivalent to ppc
> in_leXX()/in_be16() accessors but they are not inlined.
>
> Since commit 0eb573682872 ("powerpc/kerenl: Enable EEH for IO
> accessors"), the 'le' versions are equivalent to the ones
> defined in asm-generic/io.h, allthough the ones there are inlined.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: inline iomap accessors
https://git.kernel.org/powerpc/c/894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e
cheers
Re: [PATCH 1/2] powerpc: Retire e200 core (mpc555x processor)
On Tue, 17 Nov 2020 05:07:58 + (UTC), Christophe Leroy wrote: > There is no defconfig selecting CONFIG_E200, and no platform. > > e200 is an earlier version of booke, a predecessor of e500, > with some particularities like an unified cache instead of both an > instruction cache and a data cache. > > Remove it. Applied to powerpc/next. [1/2] powerpc: Retire e200 core (mpc555x processor) https://git.kernel.org/powerpc/c/39c8bf2b3cc166a2a75111e4941cc5f7efbddc35 [2/2] powerpc: Remove ucache_bsize https://git.kernel.org/powerpc/c/8817aabb1bdd5811130f94ff6442bb19c9158a3a cheers
Re: [PATCH] powerpc/feature: Add CPU_FTR_NOEXECUTE to G2_LE
On Mon, 12 Oct 2020 08:02:13 + (UTC), Christophe Leroy wrote: > G2_LE has a 603 core, add CPU_FTR_NOEXECUTE. Applied to powerpc/next. [1/1] powerpc/feature: Add CPU_FTR_NOEXECUTE to G2_LE https://git.kernel.org/powerpc/c/197493af414ee22427be3343637ac290a791925a cheers
Re: [PATCH V2] powerpc/perf: Fix crash with is_sier_available when pmu is not set
On Mon, 23 Nov 2020 21:40:40 -0500, Athira Rajeev wrote: > On systems without any specific PMU driver support registered, running > 'perf record' with âintr-regs will crash ( perf record -I ). > > The relevant portion from crash logs and Call Trace: > > Unable to handle kernel paging request for data at address 0x0068 > Faulting instruction address: 0xc013eb18 > Oops: Kernel access of bad area, sig: 11 [#1] > CPU: 2 PID: 13435 Comm: kill Kdump: loaded Not tainted 4.18.0-193.el8.ppc64le > #1 > NIP: c013eb18 LR: c0139f2c CTR: c0393d80 > REGS: c004a07ab4f0 TRAP: 0300 Not tainted (4.18.0-193.el8.ppc64le) > NIP [c013eb18] is_sier_available+0x18/0x30 > LR [c0139f2c] perf_reg_value+0x6c/0xb0 > Call Trace: > [c004a07ab770] [c004a07ab7c8] 0xc004a07ab7c8 (unreliable) > [c004a07ab7a0] [c03aa77c] perf_output_sample+0x60c/0xac0 > [c004a07ab840] [c03ab3f0] perf_event_output_forward+0x70/0xb0 > [c004a07ab8c0] [c039e208] __perf_event_overflow+0x88/0x1a0 > [c004a07ab910] [c039e42c] perf_swevent_hrtimer+0x10c/0x1d0 > [c004a07abc50] [c0228b9c] __hrtimer_run_queues+0x17c/0x480 > [c004a07abcf0] [c022aaf4] hrtimer_interrupt+0x144/0x520 > [c004a07abdd0] [c002a864] timer_interrupt+0x104/0x2f0 > [c004a07abe30] [c00091c4] decrementer_common+0x114/0x120 > > [...] Applied to powerpc/next. [1/1] powerpc/perf: Fix crash with is_sier_available when pmu is not set https://git.kernel.org/powerpc/c/f75e7d73bdf73f07b0701a6d21c111ef5d9021dd cheers
Re: [PATCH V2 0/7] powerpc/perf: Fixes for power10 PMU
On Thu, 26 Nov 2020 11:54:37 -0500, Athira Rajeev wrote: > Patchset contains PMU fixes for power10. > > This patchset contains 7 patches. > Patch1 includes fix to update event code with radix_scope_qual > bit in power10. > Patch2 and Patch3 updates the event group constraints for L2/L3 > and threshold events in power10. > Patch4, patch5 and patch6 includes the event code changes for > l2/l3 events and some of the generic events. > Patch7 adds fixes for PMCCEXT bit in power10. > > [...] Applied to powerpc/next. [1/7] powerpc/perf: Fix to update radix_scope_qual in power10 https://git.kernel.org/powerpc/c/d3afd28cd2f35b2a1046b76e0cf010b684da2e84 [2/7] powerpc/perf: Update the PMU group constraints for l2l3 events in power10 https://git.kernel.org/powerpc/c/e924be7b0b0d1f37d0509c854a92c7a71e3cdfe7 [3/7] powerpc/perf: Fix the PMU group constraints for threshold events in power10 https://git.kernel.org/powerpc/c/0263bbb377af0c2d38bc8b2ad2ff147e240094de [4/7] powerpc/perf: Add generic and cache event list for power10 DD1 https://git.kernel.org/powerpc/c/c0e3985790251b307b7b71b687ed0128741b3f34 [5/7] powerpc/perf: Fix to update generic event codes for power10 https://git.kernel.org/powerpc/c/1f12316394e3b241e70ed620ca846002c8ace3ec [6/7] powerpc/perf: Fix to update cache events with l2l3 events in power10 https://git.kernel.org/powerpc/c/9a8ee52634235993273c43ef67669d8168497dd7 [7/7] powerpc/perf: MMCR0 control for PMU registers under PMCC=00 https://git.kernel.org/powerpc/c/91668ab7db4bcfae332e561df1de2401f3f18553 cheers
Re: [PATCH] powerpc/perf: Invoke per-CPU variable access with disabled interrupts
On Tue, 1 Dec 2020 04:28:00 -0500, Athira Rajeev wrote: > The power_pmu_event_init() callback access per-cpu variable > (cpu_hw_events) to check for event constraints and Branch Stack > (BHRB). Current usage is to disable preemption when accessing the > per-cpu variable, but this does not prevent timer callback from > interrupting event_init. Fix this by using 'local_irq_save/restore' > to make sure the code path is invoked with disabled interrupts. > > [...] Applied to powerpc/next. [1/1] powerpc/perf: Invoke per-CPU variable access with disabled interrupts https://git.kernel.org/powerpc/c/f66de7ac4849eb42a7b18e26b8ee49e08130fd27 cheers
Re: [PATCH v7 00/22] Kernel userspace access/execution prevention with hash translation
On Fri, 27 Nov 2020 10:14:02 +0530, Aneesh Kumar K.V wrote: > This patch series implements KUAP and KUEP with hash translation mode using > memory keys. The kernel now uses memory protection key 3 to control access > to the kernel. Kernel page table entries are now configured with key 3. > Access to locations configured with any other key value is denied when in > kernel mode (MSR_PR=0). This includes userspace which is by default configured > with key 0. > > [...] Patches 1-20, 22 applied to powerpc/next. [01/22] powerpc: Add new macro to handle NESTED_IFCLR https://git.kernel.org/powerpc/c/c3d35ddd1ec874690a4e8da5a18497256f1ffa9a [02/22] KVM: PPC: BOOK3S: PR: Ignore UAMOR SPR https://git.kernel.org/powerpc/c/9f378b9f007cc94beadea40df83cc62a76975c6f [03/22] powerpc/book3s64/kuap/kuep: Add PPC_PKEY config on book3s64 https://git.kernel.org/powerpc/c/227ae625522c65c4535cabe407f47abc058585ed [04/22] powerpc/book3s64/kuap/kuep: Move uamor setup to pkey init https://git.kernel.org/powerpc/c/39df17bc20059c84ddc6f91831fce2e2cc79a6f3 [05/22] powerpc/book3s64/kuap: Move KUAP related function outside radix https://git.kernel.org/powerpc/c/3b47b7549ead0719e94022c6742199333c7c8d9f [06/22] powerpc/book3s64/kuep: Move KUEP related function outside radix https://git.kernel.org/powerpc/c/57b7505aa8ba13eb18ffabeb689ac64343c53aaa [07/22] powerpc/book3s64/kuap: Rename MMU_FTR_RADIX_KUAP and MMU_FTR_KUEP https://git.kernel.org/powerpc/c/d5b810b5c938e73fd21b2b05ef6a79837eeaa305 [08/22] powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation https://git.kernel.org/powerpc/c/d94b827e89dc3f92cd871d10f4992a6bd3c861e5 [09/22] powerpc/exec: Set thread.regs early during exec https://git.kernel.org/powerpc/c/d7df77e89039623ededf0ece7b4358f7c9ecbaae [10/22] powerpc/book3s64/pkeys: Store/restore userspace AMR/IAMR correctly on entry and exit from kernel https://git.kernel.org/powerpc/c/8e560921b58cbc18e192f0ac273d307a37a144f9 [11/22] powerpc/book3s64/pkeys: Inherit correctly on fork. https://git.kernel.org/powerpc/c/f643fcab74c005ddfdda68c69909f03bde766ff1 [12/22] powerpc/book3s64/pkeys: Reset userspace AMR correctly on exec https://git.kernel.org/powerpc/c/d5fa30e6993ffcdd1859d8dab1a07a6f6c6e7c3f [13/22] powerpc/ptrace-view: Use pt_regs values instead of thread_struct based one. https://git.kernel.org/powerpc/c/edc541ecaae73d498a49b9ca82bc66255d9e0720 [14/22] powerpc/book3s64/pkeys: Don't update SPRN_AMR when in kernel mode. https://git.kernel.org/powerpc/c/48a8ab4eeb8271f2a0e2ca3cf80844a59acca153 [15/22] powerpc/book3s64/kuap: Restrict access to userspace based on userspace AMR https://git.kernel.org/powerpc/c/4d6c551e9f548f7675a01eff229d09ab41162a25 [16/22] powerpc/book3s64/kuap: Improve error reporting with KUAP https://git.kernel.org/powerpc/c/eb232b1624462752dc916d9015b31ecdac0a01f1 [17/22] powerpc/book3s64/kuap: Use Key 3 to implement KUAP with hash translation. https://git.kernel.org/powerpc/c/fa46c2fa6ffbedab3a3cbcbde1292468979e830b [18/22] powerpc/book3s64/kuep: Use Key 3 to implement KUEP with hash translation. https://git.kernel.org/powerpc/c/292f86c4c683a1064aff7210348da088c1573ee0 [19/22] powerpc/book3s64/hash/kuap: Enable kuap on hash https://git.kernel.org/powerpc/c/b2ff33a10c8b3e9d260c57df38b5cd3765a0b785 [20/22] powerpc/book3s64/hash/kuep: Enable KUEP on hash https://git.kernel.org/powerpc/c/c91435d95c49f4053b05ba03b41dd7ed0fbd6c71 [22/22] powerpc/book3s64/pkeys: Optimize KUAP and KUEP feature disabled case https://git.kernel.org/powerpc/c/ec0f9b98f7d01b15c804e77e12a515ffc56d7309 cheers
Re: [PATCH] powerpc/book3s64/kuap: Improve error reporting with KUAP
On Tue, 8 Dec 2020 08:45:39 +0530, Aneesh Kumar K.V wrote:
> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
> error reporting with KUAP") and update the fault handler to print
>
> [ 55.022514] Kernel attempted to access user page (7e6725b7) - exploit
> attempt? (uid: 0)
> [ 55.022528] BUG: Unable to handle kernel data access on read at
> 0x7e6725b7
> [ 55.022533] Faulting instruction address: 0xc0e8b9bc
> [ 55.022540] Oops: Kernel access of bad area, sig: 11 [#1]
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/book3s64/kuap: Improve error reporting with KUAP
https://git.kernel.org/powerpc/c/eb232b1624462752dc916d9015b31ecdac0a01f1
cheers
Re: [PATCH kernel v3] powerpc/pci: Remove LSI mappings on device teardown
On Wed, 2 Dec 2020 11:52:22 +1100, Alexey Kardashevskiy wrote: > When a passthrough IO adapter is removed from a pseries machine using hash > MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS > to clear all page table entries related to the adapter. If some are still > present, the RTAS call which isolates the PCI slot returns error 9001 > "valid outstanding translations" and the removal of the IO adapter fails. > This is because when the PHBs are scanned, Linux maps automatically the > INTx interrupts in the Linux interrupt number space but these are never > removed. > > [...] Applied to powerpc/next. [1/1] powerpc/pci: Remove LSI mappings on device teardown https://git.kernel.org/powerpc/c/450be4960a0fb89b931a6bb3c3f0bb538ac4c03c cheers
Re: [PATCH kernel v2] powerpc/powernv/npu: Do not attempt NPU2 setup on POWER8NVL NPU
On Sun, 22 Nov 2020 18:38:28 +1100, Alexey Kardashevskiy wrote: > We execute certain NPU2 setup code (such as mapping an LPID to a device > in NPU2) unconditionally if an Nvlink bridge is detected. However this > cannot succeed on POWER8NVL machines and errors appear in dmesg. This is > harmless as skiboot returns an error and the only place we check it is > vfio-pci but that code does not get called on P8+ either. > > This adds a check if pnv_npu2_xxx helpers are called on a machine with > NPU2 which initializes pnv_phb::npu in pnv_npu2_init(); > pnv_phb::npu==NULL on POWER8/NVL (Naples). > > [...] Applied to powerpc/next. [1/1] powerpc/powernv/npu: Do not attempt NPU2 setup on POWER8NVL NPU https://git.kernel.org/powerpc/c/b1198a88230f2ce50c271e22b82a8b8610b2eea9 cheers
[PATCH v3 0/5] Extend Parsing "ibm, thread-groups" for Shared-L2 information
From: "Gautham R. Shenoy"
Hi,
This is the v2 of the patchset to extend parsing of "ibm,thread-groups" property
to discover the Shared-L2 cache information.
The previous versions can be found here :
v2 :
https://lore.kernel.org/linuxppc-dev/1607533700-5546-1-git-send-email-...@linux.vnet.ibm.com/T/#m043ea15d3832658527fca94765202b9cbefd330d
v1 :
https://lore.kernel.org/linuxppc-dev/1607057327-29822-1-git-send-email-...@linux.vnet.ibm.com/T/#m0fabffa1ea1a2807b362f25c849bb19415216520
Changes form v2-->v3:
* Fixed the build errors reported by the Kernel Test Robot for Patches 4 and 5.
Changes from v1-->v2:
Incorporate the review comments from Srikar and
fix a build error on !PPC64 configs reported by the kernel bot.
* Split Patch 1 into three patches
* First patch ensure that parse_thread_groups() is made generic to
support more than one property.
* Second patch renames cpu_l1_cache_map as
thread_group_l1_cache_map for consistency. No functional impact.
* The third patch makes init_thread_group_l1_cache_map()
generic. No functional impact.
* Patch 2 (Now patch 4): Incorporates the review comments from Srikar
simplifying
the changes to update_mask_by_l2()
* Patch 3 (Now patch 5): Fix a build errors for 32-bit configs
reported by the kernel build bot.
Description of the Patchset
===
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
Furthermore, currently on platforms where groups of threads share L2
cache, we incorrectly create an extra CACHE level sched-domain that
maps to all the threads of the core.
For example, if "ibm,thread-groups" is
0001 0002 0004
0002 0004 0006 0001
0003 0005 0007 0002
0002 0004 0002
0004 0006 0001 0003
0005 0007
then, the sub-array
[0002 0002 0004
0002 0004 0006
0001 0003 0005 0007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
However, the sched-domain hierarchy for CPUs 0,1 is
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
where the CACHE domain reports that L2 is shared across the entire
core which is incorrect on such platforms.
This patchset remedies these issues by extending the parsing support
for "ibm,thread-groups" to discover information about multiple
properties being shared by the corresponding groups of threads. In
particular we cano now detect if the groups of threads within a core
share the L2-cache. On such platforms, we populate the populating the
cpu_l2_cache_mask of every CPU to the core-siblings which share L2
with the CPU as specified in the by the "ibm,thread-groups" property
array.
With the patchset, the sched-domain hierarchy is
[PATCH v3 2/5] powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map
From: "Gautham R. Shenoy"
On platforms which have the "ibm,thread-groups" property, the per-cpu
variable cpu_l1_cache_map keeps a track of which group of threads
within the same core share the L1 cache, Instruction and Data flow.
This patch renames the variable to "thread_group_l1_cache_map" to make
it consistent with a subsequent patch which will introduce
thread_group_l2_cache_map.
This patch introduces no functional change.
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/kernel/smp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 88d88ad..f3290d5 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -116,10 +116,10 @@ struct thread_groups_list {
static struct thread_groups_list tgl[NR_CPUS] __initdata;
/*
- * On big-cores system, cpu_l1_cache_map for each CPU corresponds to
+ * On big-cores system, thread_group_l1_cache_map for each CPU corresponds to
* the set its siblings that share the L1-cache.
*/
-DEFINE_PER_CPU(cpumask_var_t, cpu_l1_cache_map);
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
@@ -866,7 +866,7 @@ static struct thread_groups *__init get_thread_groups(int
cpu,
return tg;
}
-static int init_cpu_l1_cache_map(int cpu)
+static int init_thread_group_l1_cache_map(int cpu)
{
int first_thread = cpu_first_thread_sibling(cpu);
@@ -885,7 +885,7 @@ static int init_cpu_l1_cache_map(int cpu)
return -ENODATA;
}
- zalloc_cpumask_var_node(_cpu(cpu_l1_cache_map, cpu),
+ zalloc_cpumask_var_node(_cpu(thread_group_l1_cache_map, cpu),
GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
@@ -897,7 +897,7 @@ static int init_cpu_l1_cache_map(int cpu)
}
if (i_group_start == cpu_group_start)
- cpumask_set_cpu(i, per_cpu(cpu_l1_cache_map, cpu));
+ cpumask_set_cpu(i, per_cpu(thread_group_l1_cache_map,
cpu));
}
return 0;
@@ -976,7 +976,7 @@ static int init_big_cores(void)
int cpu;
for_each_possible_cpu(cpu) {
- int err = init_cpu_l1_cache_map(cpu);
+ int err = init_thread_group_l1_cache_map(cpu);
if (err)
return err;
@@ -1372,7 +1372,7 @@ static inline void add_cpu_to_smallcore_masks(int cpu)
cpumask_set_cpu(cpu, cpu_smallcore_mask(cpu));
- for_each_cpu(i, per_cpu(cpu_l1_cache_map, cpu)) {
+ for_each_cpu(i, per_cpu(thread_group_l1_cache_map, cpu)) {
if (cpu_online(i))
set_cpus_related(i, cpu, cpu_smallcore_mask);
}
--
1.9.4
[PATCH v3 3/5] powerpc/smp: Rename init_thread_group_l1_cache_map() to make it generic
From: "Gautham R. Shenoy"
init_thread_group_l1_cache_map() initializes the per-cpu cpumask
thread_group_l1_cache_map with the core-siblings which share L1 cache
with the CPU. Make this function generic to the cache-property (L1 or
L2) and update a suitable mask. This is a preparatory patch for the
next patch where we will introduce discovery of thread-groups that
share L2-cache.
No functional change.
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/kernel/smp.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index f3290d5..9078b5b5 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -866,15 +866,18 @@ static struct thread_groups *__init get_thread_groups(int
cpu,
return tg;
}
-static int init_thread_group_l1_cache_map(int cpu)
+static int __init init_thread_group_cache_map(int cpu, int cache_property)
{
int first_thread = cpu_first_thread_sibling(cpu);
int i, cpu_group_start = -1, err = 0;
struct thread_groups *tg = NULL;
+ cpumask_var_t *mask;
- tg = get_thread_groups(cpu, THREAD_GROUP_SHARE_L1,
- );
+ if (cache_property != THREAD_GROUP_SHARE_L1)
+ return -EINVAL;
+
+ tg = get_thread_groups(cpu, cache_property, );
if (!tg)
return err;
@@ -885,8 +888,8 @@ static int init_thread_group_l1_cache_map(int cpu)
return -ENODATA;
}
- zalloc_cpumask_var_node(_cpu(thread_group_l1_cache_map, cpu),
- GFP_KERNEL, cpu_to_node(cpu));
+ mask = _cpu(thread_group_l1_cache_map, cpu);
+ zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
int i_group_start = get_cpu_thread_group_start(i, tg);
@@ -897,7 +900,7 @@ static int init_thread_group_l1_cache_map(int cpu)
}
if (i_group_start == cpu_group_start)
- cpumask_set_cpu(i, per_cpu(thread_group_l1_cache_map,
cpu));
+ cpumask_set_cpu(i, *mask);
}
return 0;
@@ -976,7 +979,7 @@ static int init_big_cores(void)
int cpu;
for_each_possible_cpu(cpu) {
- int err = init_thread_group_l1_cache_map(cpu);
+ int err = init_thread_group_cache_map(cpu,
THREAD_GROUP_SHARE_L1);
if (err)
return err;
--
1.9.4
[PATCH v3 4/5] powerpc/smp: Add support detecting thread-groups sharing L2 cache
From: "Gautham R. Shenoy"
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
0001 0002 0004
0002 0004 0006 0001
0003 0005 0007 0002
0002 0004 0002
0004 0006 0001 0003
0005 0007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[0002 0002 0004
0002 0004 0006
0001 0003 0005 0007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/include/asm/smp.h | 2 ++
arch/powerpc/kernel/smp.c | 58 ++
2 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index b2035b2..035459c 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -134,6 +134,7 @@ static inline struct cpumask *cpu_smallcore_mask(int cpu)
extern int cpu_to_core_id(int cpu);
extern bool has_big_cores;
+extern bool thread_group_shares_l2;
#define cpu_smt_mask cpu_smt_mask
#ifdef CONFIG_SCHED_SMT
@@ -187,6 +188,7 @@ static inline const struct cpumask *cpu_smt_mask(int cpu)
/* for UP */
#define hard_smp_processor_id()get_hard_smp_processor_id(0)
#define smp_setup_cpu_maps()
+#define thread_group_shares_l2 0
static inline void inhibit_secondary_onlining(void) {}
static inline void uninhibit_secondary_onlining(void) {}
static inline const struct cpumask *cpu_sibling_mask(int cpu)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 9078b5b5..2b9b1bb 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -76,6 +76,7 @@
struct task_struct *secondary_current;
bool has_big_cores;
bool coregroup_enabled;
+bool thread_group_shares_l2;
DEFINE_PER_CPU(cpumask_var_t, cpu_sibling_map);
DEFINE_PER_CPU(cpumask_var_t, cpu_smallcore_map);
@@ -99,6 +100,7 @@ enum {
#define MAX_THREAD_LIST_SIZE 8
#define THREAD_GROUP_SHARE_L1 1
+#define THREAD_GROUP_SHARE_L2 2
struct thread_groups {
unsigned int property;
unsigned int nr_groups;
@@ -107,7 +109,7 @@ struct thread_groups {
};
/* Maximum number of properties that groups of threads within a core can share
*/
-#define MAX_THREAD_GROUP_PROPERTIES 1
+#define MAX_THREAD_GROUP_PROPERTIES 2
struct thread_groups_list {
unsigned int nr_properties;
@@ -121,6 +123,13 @@ struct thread_groups_list {
*/
DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
+/*
+ * On some big-cores system, thread_group_l2_cache_map for each CPU
+ * corresponds to the set its siblings within the core that share the
+ * L2-cache.
+ */
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
+
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
@@ -718,7 +727,9 @@ static void or_cpumasks_related(int i, int j, struct
cpumask *(*srcmask)(int),
*
* ibm,thread-groups[i + 0] tells us the property based on which the
* threads are being grouped together. If this value is 1, it implies
- * that the threads in the same group share L1, translation cache.
+ * that the threads in the same group share L1, translation cache. If
+ * the
[PATCH v3 5/5] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
From: "Gautham R. Shenoy"
On POWER platforms where only some groups of threads within a core
share the L2-cache (indicated by the ibm,thread-groups device-tree
property), we currently print the incorrect shared_cpu_map/list for
L2-cache in the sysfs.
This patch reports the correct shared_cpu_map/list on such platforms.
Example:
On a platform with "ibm,thread-groups" set to
0001 0002 0004
0002 0004 0006 0001
0003 0005 0007 0002
0002 0004 0002
0004 0006 0001 0003
0005 0007
This indicates that threads {0,2,4,6} in the core share the L2-cache
and threads {1,3,5,7} in the core share the L2 cache.
However, without the patch, the shared_cpu_map/list for L2 for CPUs 0,
1 is reported in the sysfs as follows:
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0-7
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:00,00ff
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list:0-7
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:00,00ff
With the patch, the shared_cpu_map/list for L2 cache for CPUs 0, 1 is
correctly reported as follows:
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0,2,4,6
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:00,0055
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list:1,3,5,7
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:00,00aa
This patch also defines cpu_l2_cache_mask() for !CONFIG_SMP case.
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/include/asm/smp.h | 4
arch/powerpc/kernel/cacheinfo.c | 30 --
2 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 035459c..c4e2d53 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -201,6 +201,10 @@ static inline const struct cpumask *cpu_smallcore_mask(int
cpu)
return cpumask_of(cpu);
}
+static inline const struct cpumask *cpu_l2_cache_mask(int cpu)
+{
+ return cpumask_of(cpu);
+}
#endif /* CONFIG_SMP */
#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 65ab9fc..6f903e9a 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -655,11 +655,27 @@ static unsigned int index_dir_to_cpu(struct
cache_index_dir *index)
* On big-core systems, each core has two groups of CPUs each of which
* has its own L1-cache. The thread-siblings which share l1-cache with
* @cpu can be obtained via cpu_smallcore_mask().
+ *
+ * On some big-core systems, the L2 cache is shared only between some
+ * groups of siblings. This is already parsed and encoded in
+ * cpu_l2_cache_mask().
+ *
+ * TODO: cache_lookup_or_instantiate() needs to be made aware of the
+ * "ibm,thread-groups" property so that cache->shared_cpu_map
+ * reflects the correct siblings on platforms that have this
+ * device-tree property. This helper function is only a stop-gap
+ * solution so that we report the correct siblings to the
+ * userspace via sysfs.
*/
-static const struct cpumask *get_big_core_shared_cpu_map(int cpu, struct cache
*cache)
+static const struct cpumask *get_shared_cpu_map(struct cache_index_dir *index,
struct cache *cache)
{
- if (cache->level == 1)
- return cpu_smallcore_mask(cpu);
+ if (has_big_cores) {
+ int cpu = index_dir_to_cpu(index);
+ if (cache->level == 1)
+ return cpu_smallcore_mask(cpu);
+ if (cache->level == 2 && thread_group_shares_l2)
+ return cpu_l2_cache_mask(cpu);
+ }
return >shared_cpu_map;
}
@@ -670,17 +686,11 @@ static const struct cpumask
*get_big_core_shared_cpu_map(int cpu, struct cache *
struct cache_index_dir *index;
struct cache *cache;
const struct cpumask *mask;
- int cpu;
index = kobj_to_cache_index_dir(k);
cache = index->cache;
- if (has_big_cores) {
- cpu = index_dir_to_cpu(index);
- mask = get_big_core_shared_cpu_map(cpu, cache);
- } else {
- mask = >shared_cpu_map;
- }
+ mask = get_shared_cpu_map(index, cache);
return cpumap_print_to_pagebuf(list, buf, mask);
}
--
1.9.4
[PATCH v3 1/5] powerpc/smp: Parse ibm, thread-groups with multiple properties
From: "Gautham R. Shenoy"
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/kernel/smp.c | 174 ++
1 file changed, 113 insertions(+), 61 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 8c2857c..88d88ad 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -106,6 +106,15 @@ struct thread_groups {
unsigned int thread_list[MAX_THREAD_LIST_SIZE];
};
+/* Maximum number of properties that groups of threads within a core can share
*/
+#define MAX_THREAD_GROUP_PROPERTIES 1
+
+struct thread_groups_list {
+ unsigned int nr_properties;
+ struct thread_groups property_tgs[MAX_THREAD_GROUP_PROPERTIES];
+};
+
+static struct thread_groups_list tgl[NR_CPUS] __initdata;
/*
* On big-cores system, cpu_l1_cache_map for each CPU corresponds to
* the set its siblings that share the L1-cache.
@@ -695,81 +704,98 @@ static void or_cpumasks_related(int i, int j, struct
cpumask *(*srcmask)(int),
/*
* parse_thread_groups: Parses the "ibm,thread-groups" device tree
* property for the CPU device node @dn and stores
- * the parsed output in the thread_groups
- * structure @tg if the ibm,thread-groups[0]
- * matches @property.
+ * the parsed output in the thread_groups_list
+ * structure @tglp.
*
* @dn: The device node of the CPU device.
- * @tg: Pointer to a thread group structure into which the parsed
+ * @tglp: Pointer to a thread group list structure into which the parsed
* output of "ibm,thread-groups" is stored.
- * @property: The property of the thread-group that the caller is
- *interested in.
*
* ibm,thread-groups[0..N-1] array defines which group of threads in
* the CPU-device node can be grouped together based on the property.
*
- * ibm,thread-groups[0] tells us the property based on which the
+ * This array can represent thread groupings for multiple properties.
+ *
+ * ibm,thread-groups[i + 0] tells us the property based on which the
* threads are being grouped together. If this value is 1, it implies
* that the threads in the same group share L1, translation cache.
*
- * ibm,thread-groups[1] tells us how many such thread groups exist.
+ * ibm,thread-groups[i+1] tells us how many such thread groups exist for the
+ * property ibm,thread-groups[i]
*
- * ibm,thread-groups[2] tells us the number of threads in each such
+ * ibm,thread-groups[i+2] tells us the number of threads in each such
* group.
+ * Suppose k = (ibm,thread-groups[i+1] * ibm,thread-groups[i+2]), then,
*
- * ibm,thread-groups[3..N-1] is the list of threads identified by
+ * ibm,thread-groups[i+3..i+k+2] (is the list of threads identified by
* "ibm,ppc-interrupt-server#s" arranged as per their membership in
* the grouping.
*
- * Example: If ibm,thread-groups = [1,2,4,5,6,7,8,9,10,11,12] it
- * implies that there are 2 groups of 4 threads each, where each group
- * of threads share L1, translation cache.
+ * Example:
+ * If "ibm,thread-groups" =
Re: [PATCH] drivers: usb: gadget: prefer pr_*() functions over raw printk()
On 09.12.20 12:27, Laurent Pinchart wrote: Hi, >>> I wonder if this shouldn't be dropped instead, commented-out code isn't >>> very useful. >> >> Indeed. Shall I send a separate patch for that ? > > Yes, that would make sense. Okay, I'm currently doing a more in-depth rework. I'll send another patch queue later. Since I don't own the corresponding devices, I can't do much testing (just build tests and careful review), so I need some help w/ that. > As most of the files touched by this patch are device drivers, dev_*() > functions should be used instead of pr_*() where possible. I'd recommend > a first patch that converts to dev_*(), and then a second patch that > converts the remaining printk()s, if any, to pr_*() in the contexts > where no struct device is available or can easily be made available. I'm now splitting it into per-driver patches. They're getting a bit bigger, since I'm also replacing some debug macros, etc. In some cases I'm introducing new helpers for not having to write long expressions to get the actual dev ptr, adding some prefixes (eg. per usb endpoint logging, ...). --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [PATCH 00/13] powerpc/xive: misc cleanups
On 12/8/20 4:11 PM, Cédric Le Goater wrote: > Hello, > > The most important change is the removal of support of OPAL flags > required for P9 DD1. It provides a good cleanup of some complex > routines. > > The series also includes a change on how the pages donated to the XIVE > IC are allocated in Linux. The flags are changed to make sure that > these pages can not be reclaimed. This issue (checkstop) only occurred a once or twice on a P9 Mihawk with 1TB of RAM and 1TB of swap. It's hard to reproduce. It seems we have a fix but I misunderstood some parts of the kernel page allocation scheme and, so, I am not entirely the root issue is well analyzed. This patch can wait until I grab a larger system with 2TB. I will send a v2. Greg had some valuable comments on extra cleanups. Thanks, C.
[PATCH v4 05/10] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/powerpc/boot/dts/akebono.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/akebono.dts
b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@301 {
interrupts = <93 2>;
};
- EHCI0: ehci@3001000 {
+ EHCI0: usb@3001000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x1000 0x0 0x1>;
interrupt-parent = <>;
@@ -140,14 +140,14 @@ SD0: sd@300 {
interrupt-parent = <>;
};
- OHCI0: ohci@3001001 {
+ OHCI0: usb@3001001 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1001 0x0 0x1>;
interrupt-parent = <>;
interrupts = <89 1>;
};
- OHCI1: ohci@3001002 {
+ OHCI1: usb@3001002 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1002 0x0 0x1>;
interrupt-parent = <>;
--
2.29.2
[PATCH RESEND v4 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].
Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible string in favor of
the ones with valid "snps,"-prefix. It's done in all the DTS files,
which have been unfortunate to define such nodes.
Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
been erroneously declared as boolean while having uint32 type. Neil said
it was ok to init that property with 0x20 value.
Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
and DWC USB3 DT nodes name as in accordance with their DT schema the
corresponding node name is suppose to comply with the Generic USB HCD DT
schema, which requires the USB nodes to have the name acceptable by the
regexp: "^usb(@.*)?". Such requirement had been applicable even before we
introduced the new DT schema in [1], but as we can see it hasn't been
strictly implemented for a lot the DTS files. Since DT schema is now
available the automated DTS validation shall make sure that the rule isn't
violated.
Note most of these patches have been a part of the last three patches of
[1]. But since there is no way to have them merged in in a combined
manner, I had to move them to the dedicated series and split them up so to
be accepted by the corresponding subsystem maintainers one-by-one.
[1] Link:
https://lore.kernel.org/linux-usb/20201014101402.18271-1-sergey.se...@baikalelectronics.ru/
Changelog v1:
- As Krzysztof suggested I've created a script which checked whether the
node names had been also updated in all the depended dts files. As a
result I found two more files which should have been also modified:
arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
- Correct the USB DWC3 nodes name found in
arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
Link:
https://lore.kernel.org/linux-usb/20201020115959.2658-1-sergey.se...@baikalelectronics.ru
Changelog v2:
- Drop the patch:
[PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
and get back the one which marks the "synopsys,dwc3" compatible string
as deprecated into the DT schema related series.
- Drop the patches:
[PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
[PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
[PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
[PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
[PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
[PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
[PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
[PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
[PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
- Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
sub-node and falling back to the "dwc3@"-prefixed one on failure.
Link:
https://lore.kernel.org/linux-usb/2020091552.15593-1-sergey.se...@baikalelectronics.ru
Changelog v3:
- Drop the patches:
[PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
[PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes
name
[PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
Link:
https://lore.kernel.org/linux-usb/20201205155621.3045-1-sergey.se...@baikalelectronics.ru
Changelog v4:
- Just resend.
Cc: Vineet Gupta
Cc: Rafal Milecki
Cc: Wei Xu
Cc: Thomas Bogendoerfer
Cc: Michael Ellerman
Cc: Jason Cooper
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Benoit Cousson
Cc: Patrice Chotard
Cc: Maxime Ripard
Cc: Khuong Dinh
Cc: Andy Gross
Cc: Alexey Brodkin
Cc: Hauke Mehrtens
Cc: Maxime Coquelin
Cc: Alexandre Torgue
Cc: Amelie Delaunay
Cc: Vladimir Zapolskiy
Cc: Paul Cercueil
Cc: Matthias Brugger
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Sebastian Hesselbarth
Cc: Kukjin Kim
Cc: Li Yang
Cc: Tony Lindgren
Cc: Chen-Yu Tsai
Cc: Bjorn Andersson
Cc: Jun Li
Cc: linux-snps-...@lists.infradead.org
Cc:
[PATCH v6 19/19] dt-bindings: usb: intel, keembay-dwc3: Validate DWC3 sub-node
Intel Keem Bay DWC3 compatible DT nodes are supposed to have a DWC USB3
compatible sub-node to describe a fully functioning USB interface. Let's
use the available DWC USB3 DT schema to validate the Intel Keem Bay DWC3
sub-nodes.
Note since the generic DWC USB3 DT node is supposed to be named as generic
USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
regexp and fix the DT node example.
Signed-off-by: Serge Semin
Acked-by: Wan Ahmad Zainie
Reviewed-by: Rob Herring
---
Changelog v5:
- This is a new patch created for the new Intel Keem Bay bindings file,
which has been added just recently.
Changelog v6:
- Fix typo in the commit log: Qualcomm sub-node should be called as Intel
Keem Bay sub-node
---
.../devicetree/bindings/usb/intel,keembay-dwc3.yaml | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
index dd32c10ce6c7..43b91ab62004 100644
--- a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
@@ -34,11 +34,8 @@ properties:
# Required child node:
patternProperties:
- "^dwc3@[0-9a-f]+$":
-type: object
-description:
- A child node must exist to represent the core DWC3 IP block.
- The content of the node is defined in dwc3.txt.
+ "^usb@[0-9a-f]+$":
+$ref: snps,dwc3.yaml#
required:
- compatible
@@ -68,7 +65,7 @@ examples:
#address-cells = <1>;
#size-cells = <1>;
- dwc3@3400 {
+ usb@3400 {
compatible = "snps,dwc3";
reg = <0x3400 0x1>;
interrupts = ;
--
2.29.2
[PATCH v6 18/19] dt-bindings: usb: qcom,dwc3: Validate DWC3 sub-node
Qualcomm msm8996/sc7180/sdm845 DWC3 compatible DT nodes are supposed to
have a DWC USB3 compatible sub-node to describe a fully functioning USB
interface. Let's use the available DWC USB3 DT schema to validate the
Qualcomm DWC3 sub-nodes.
Note since the generic DWC USB3 DT node is supposed to be named as generic
USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
regexp and fix the DT node example.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v2:
- Discard the "^dwc3@[0-9a-f]+$" nodes from being acceptable as sub-nodes.
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index 2cf525d21e05..b336662e838c 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -103,11 +103,8 @@ properties:
# Required child node:
patternProperties:
- "^dwc3@[0-9a-f]+$":
-type: object
-description:
- A child node must exist to represent the core DWC3 IP block
- The content of the node is defined in dwc3.txt.
+ "^usb@[0-9a-f]+$":
+$ref: snps,dwc3.yaml#
required:
- compatible
@@ -162,7 +159,7 @@ examples:
resets = < GCC_USB30_PRIM_BCR>;
-dwc3@a60 {
+usb@a60 {
compatible = "snps,dwc3";
reg = <0 0x0a60 0 0xcd00>;
interrupts = ;
--
2.29.2
[PATCH v6 17/19] dt-bindings: usb: keystone-dwc3: Validate DWC3 sub-node
TI Keystone DWC3 compatible DT node is supposed to have a DWC USB3 compatible sub-node to describe a fully functioning USB interface. Since DWC USB3 has now got a DT schema describing its DT node, let's make sure the TI Keystone DWC3 sub-node passes validation against it. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/it'/its" --- Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index c1b19fc5d0a2..ca7fbe3ed22e 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -64,9 +64,7 @@ properties: patternProperties: "usb@[a-f0-9]+$": -type: object -description: This is the node representing the DWC3 controller instance - Documentation/devicetree/bindings/usb/dwc3.txt +$ref: snps,dwc3.yaml# required: - compatible -- 2.29.2
[PATCH v6 16/19] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes
Amlogic G12A USB DT sub-nodes are supposed to be compatible with the generic DWC USB2 and USB3 devices. Since now we've got DT schemas for both of the later IP cores let's make sure that the Amlogic G12A USB DT nodes are fully evaluated including the DWC sub-nodes. Signed-off-by: Serge Semin Reviewed-by: Neil Armstrong Reviewed-by: Rob Herring Reviewed-by: Martin Blumenstingl --- Changelog v2: - Use "oneOf: [dwc2.yaml#, snps,dwc3.yaml#]" instead of the bulky "if: properties: compatibe: ..." statement. --- .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index 1eda16dd4ee0..e349fa5de606 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml @@ -79,7 +79,9 @@ properties: patternProperties: "^usb@[0-9a-f]+$": -type: object +oneOf: + - $ref: dwc2.yaml# + - $ref: snps,dwc3.yaml# additionalProperties: false -- 2.29.2
[PATCH v6 15/19] dt-bindings: usb: meson-g12a-usb: Fix FL-adj property value
An empty snps,quirk-frame-length-adjustment won't cause any change performed by the driver. Moreover the DT schema validation will fail, since it expects the property being assigned with some value. So set fix the example by setting a valid FL-adj value in accordance with Neil Armstrong comment. Link: https://lore.kernel.org/linux-usb/20201010224121.12672-16-sergey.se...@baikalelectronics.ru/ Signed-off-by: Serge Semin Acked-by: Neil Armstrong Reviewed-by: Rob Herring Reviewed-by: Martin Blumenstingl --- Note the same problem is in the DT source file arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi . --- .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index c0058332b967..1eda16dd4ee0 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml @@ -229,6 +229,6 @@ examples: interrupts = <30>; dr_mode = "host"; snps,dis_u2_susphy_quirk; - snps,quirk-frame-length-adjustment; + snps,quirk-frame-length-adjustment = <0x20>; }; }; -- 2.29.2
[PATCH v6 14/19] dt-bindings: usb: dwc3: Add Frame Length Adj constraints
In accordance with the IP core databook the snps,quirk-frame-length-adjustment property can be set within [0, 0x3F]. Let's make sure the DT schema applies a correct constraints on the property. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index e01a9a93d74a..2247da77eac1 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -243,6 +243,8 @@ properties: length adjustment when the fladj_30mhz_sdbnd signal is invalid or incorrect. $ref: /schemas/types.yaml#/definitions/uint32 +minimum: 0 +maximum: 0x3f snps,rx-thr-num-pkt-prd: description: -- 2.29.2
[PATCH v6 13/19] dt-bindings: usb: dwc3: Add Tx De-emphasis constraints
In accordance with the driver comments the PIPE3 de-emphasis can be tuned to be either -6dB, -2.5dB or disabled. Let's add the de-emphasis property constraints so the DT schema would make sure the controller DT node is equipped with correct value. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/tunned/tuned" - Grammar fix: remove redundant "or" conjunction. --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 6253bc5fb18e..e01a9a93d74a 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -156,6 +156,10 @@ properties: The value driven to the PHY is controlled by the LTSSM during USB3 Compliance mode. $ref: /schemas/types.yaml#/definitions/uint8 +enum: + - 0 # -6dB de-emphasis + - 1 # -3.5dB de-emphasis + - 2 # No de-emphasis snps,dis_u3_susphy_quirk: description: When set core will disable USB3 suspend phy -- 2.29.2
[PATCH v6 11/19] dt-bindings: usb: dwc3: Add interrupt-names property support
The controller driver supports two types of DWC USB3 devices: with a common interrupt lane and with individual interrupts for each mode. Add support for both these cases to the DWC USB3 DT schema. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/both of these cases support/support for both these cases" - Drop quotes from around the string constants. Changelog v4: - Discard the block scalar style modifier "|" from the interrupts property description. --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 57caca8339ae..87a92e313d24 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -34,8 +34,19 @@ properties: const: snps,dwc3 interrupts: +description: + It's either a single common DWC3 interrupt (dwc_usb3) or individual + interrupts for the host, gadget and DRD modes. +minItems: 1 +maxItems: 3 + + interrupt-names: minItems: 1 maxItems: 3 +oneOf: + - const: dwc_usb3 + - items: + enum: [host, peripheral, otg] clocks: description: -- 2.29.2
[PATCH v6 10/19] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
DWC USB3 DT node is supposed to be compliant with the Generic xHCI Controller schema, but with additional vendor-specific properties, the controller-specific reference clocks and PHYs. So let's convert the currently available legacy text-based DWC USB3 bindings to the DT schema and make sure the DWC USB3 nodes are also validated against the usb-xhci.yaml schema. Note 1. we have to discard the nodename restriction of being prefixed with "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes are supposed to be named as "^usb(@.*)". Note 2. The clock-related properties are marked as optional to match the DWC USB3 driver expectation and to improve the bindings mainainability so in case if there is a glue-node it would the responsible for the clocks initialization. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Discard '|' from the descriptions, since we don't need to preserve the text formatting in any of them. - Drop quotes from around the string constants. - Fix the "clock-names" prop description to be referring the enumerated clock-names instead of the ones from the Databook. Changelog v3: - Apply usb-xhci.yaml# schema only if the controller is supposed to work as either host or otg. Changelog v4: - Apply usb-drd.yaml schema first. If the controller is configured to work in a gadget mode only, then apply the usb.yaml schema too, otherwise apply the usb-xhci.yaml schema. - Discard the Rob'es Reviewed-by tag. Please review the patch one more time. Changelog v5: - Add "snps,dis-split-quirk" property to the DWC USB3 DT schema. - Add a commit log text about the clock-related property changes. - Make sure dr_mode exist to apply the USB-gadget-only schema. Changelog v6: - Fix identations in the "usb-phy" property definition. --- .../devicetree/bindings/usb/dwc3.txt | 128 --- .../devicetree/bindings/usb/snps,dwc3.yaml| 312 ++ 2 files changed, 312 insertions(+), 128 deletions(-) delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt deleted file mode 100644 index 1aae2b6160c1.. --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ /dev/null @@ -1,128 +0,0 @@ -synopsys DWC3 CORE - -DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties - as described in 'usb/generic.txt' - -Required properties: - - compatible: must be "snps,dwc3" - - reg : Address and length of the register set for the device - - interrupts: Interrupts used by the dwc3 controller. - - clock-names: list of clock names. Ideally should be "ref", -"bus_early", "suspend" but may be less or more. - - clocks: list of phandle and clock specifier pairs corresponding to - entries in the clock-names property. - -Exception for clocks: - clocks are optional if the parent node (i.e. glue-layer) is compatible to - one of the following: -"cavium,octeon-7130-usb-uctl" -"qcom,dwc3" -"samsung,exynos5250-dwusb3" -"samsung,exynos5433-dwusb3" -"samsung,exynos7-dwusb3" -"sprd,sc9860-dwc3" -"st,stih407-dwc3" -"ti,am437x-dwc3" -"ti,dwc3" -"ti,keystone-dwc3" -"rockchip,rk3399-dwc3" -"xlnx,zynqmp-dwc3" - -Optional properties: - - usb-phy : array of phandle for the PHY device. The first element - in the array is expected to be a handle to the USB2/HS PHY and - the second element is expected to be a handle to the USB3/SS PHY - - phys: from the *Generic PHY* bindings - - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy" - or "usb3-phy". - - resets: set of phandle and reset specifier pairs - - snps,usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM - - snps,usb3_lpm_capable: determines if platform is USB3 LPM capable - - snps,dis-start-transfer-quirk: when set, disable isoc START TRANSFER command - failure SW work-around for DWC_usb31 version 1.70a-ea06 - and prior. - - snps,disable_scramble_quirk: true when SW should disable data scrambling. - Only really useful for FPGA builds. - - snps,has-lpm-erratum: true when DWC3 was configured with LPM Erratum enabled - - snps,lpm-nyet-threshold: LPM NYET threshold - - snps,u2exit_lfps_quirk: set if we want to enable u2exit lfps quirk - - snps,u2ss_inp3_quirk: set if we enable P3 OK for U2/SS Inactive quirk - - snps,req_p1p2p3_quirk: when set, the core will always request for - P1/P2/P3 transition sequence. - - snps,del_p1p2p3_quirk: when set core will delay P1/P2/P3 until a certain - amount of 8B10B errors occur. - - snps,del_phy_power_chg_quirk: when set core will delay PHY power change - from P0 to P1/P2/P3. - - snps,lfps_filter_quirk: when set core will filter LFPS
[PATCH v6 12/19] dt-bindings: usb: dwc3: Add synopsys, dwc3 compatible string
The DWC USB3 driver and some DTS files like Exynos 5250, Keystone k2e, etc expects the DWC USB3 DT node to have the compatible string with the "synopsys" vendor prefix. Let's add the corresponding compatible string to the controller DT schema, but mark it as deprecated seeing the Synopsys, Inc. is presented with just "snps" vendor prefix. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Drop quotes from around the compat string constant. Changelog v4: - Get the patch back, since we can't discard the deprecated prefix from the driver. --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 87a92e313d24..6253bc5fb18e 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -31,7 +31,10 @@ allOf: properties: compatible: contains: - const: snps,dwc3 + oneOf: +- const: snps,dwc3 +- const: synopsys,dwc3 + deprecated: true interrupts: description: -- 2.29.2
[PATCH v6 08/19] dt-bindings: usb: xhci: Add Broadcom STB v2 compatible device
For some reason the "brcm,xhci-brcm-v2" compatible string has been missing in the original bindings file. Add it to the Generic xHCI Controllers DT schema since the controller driver expects it to be supported. Signed-off-by: Serge Semin Acked-by: Florian Fainelli Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/usb/generic-xhci.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml index 1ea1d49a8175..23d73df96ea3 100644 --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml @@ -26,7 +26,9 @@ properties: - marvell,armada-8k-xhci - const: generic-xhci - description: Broadcom STB SoCs with xHCI -const: brcm,bcm7445-xhci +enum: + - brcm,xhci-brcm-v2 + - brcm,bcm7445-xhci - description: Generic xHCI device const: xhci-platform deprecated: true -- 2.29.2
[PATCH v6 07/19] dt-bindings: usb: Convert xHCI bindings to DT schema
Currently the DT bindings of Generic xHCI Controllers are described by
means of the legacy text file. Since such format is deprecated in favor of
the DT schema, let's convert the Generic xHCI Controllers bindings file to
the corresponding yaml files. There will be two of them: a DT schema for
the xHCI controllers on a generic platform and a DT schema validating a
generic xHCI controllers properties. The later will be used to validate
the xHCI controllers, which aside from some vendor-specific features
support the basic xHCI functionality.
An xHCI-compatible DT node shall support the standard USB HCD properties
and custom ones like: usb2-lpm-disable, usb3-lpm-capable,
quirk-broken-port-ped and imod-interval-ns. In addition if a generic xHCI
controller is being validated against the DT schema it is also supposed to
be equipped with mandatory compatible string, single registers range,
single interrupts source, and is supposed to optionally contain up to two
reference clocks for the controller core and CSRs.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v2:
- Add explicit "additionalProperties: true" to the usb-xhci.yaml schema,
since additionalProperties/unevaluatedProperties are going to be mandary
for each binding.
---
.../devicetree/bindings/usb/generic-xhci.yaml | 63 +++
.../devicetree/bindings/usb/usb-xhci.txt | 41
.../devicetree/bindings/usb/usb-xhci.yaml | 42 +
3 files changed, 105 insertions(+), 41 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/generic-xhci.yaml
delete mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt
create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.yaml
diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
new file mode 100644
index ..1ea1d49a8175
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB xHCI Controller Device Tree Bindings
+
+maintainers:
+ - Mathias Nyman
+
+allOf:
+ - $ref: "usb-xhci.yaml#"
+
+properties:
+ compatible:
+oneOf:
+ - description: Generic xHCI device
+const: generic-xhci
+ - description: Armada 37xx/375/38x/8k SoCs
+items:
+ - enum:
+ - marvell,armada3700-xhci
+ - marvell,armada-375-xhci
+ - marvell,armada-380-xhci
+ - marvell,armada-8k-xhci
+ - const: generic-xhci
+ - description: Broadcom STB SoCs with xHCI
+const: brcm,bcm7445-xhci
+ - description: Generic xHCI device
+const: xhci-platform
+deprecated: true
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+minItems: 1
+maxItems: 2
+
+ clock-names:
+minItems: 1
+items:
+ - const: core
+ - const: reg
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+usb@f0931000 {
+ compatible = "generic-xhci";
+ reg = <0xf0931000 0x8c8>;
+ interrupts = <0x0 0x4e 0x0>;
+};
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
deleted file mode 100644
index 0c5cff84a969..
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-USB xHCI controllers
-
-Required properties:
- - compatible: should be one or more of
-
-- "generic-xhci" for generic XHCI device
-- "marvell,armada3700-xhci" for Armada 37xx SoCs
-- "marvell,armada-375-xhci" for Armada 375 SoCs
-- "marvell,armada-380-xhci" for Armada 38x SoCs
-- "brcm,bcm7445-xhci" for Broadcom STB SoCs with XHCI
-- "xhci-platform" (deprecated)
-
-When compatible with the generic version, nodes must list the
-SoC-specific version corresponding to the platform first
-followed by the generic version.
-
- - reg: should contain address and length of the standard XHCI
-register set for the device.
- - interrupts: one XHCI interrupt should be described here.
-
-Optional properties:
- - clocks: reference to the clocks
- - clock-names: mandatory if there is a second clock, in this case
-the name must be "core" for the first clock and "reg" for the
-second one
- - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
- - usb3-lpm-capable: determines if platform is USB3 LPM capable
- - quirk-broken-port-ped: set if the controller has broken port disable
mechanism
- - imod-interval-ns: default interrupt moderation interval is 5000ns
- - phys : see usb-hcd.yaml in the current directory
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-
-Example:
- usb@f0931000 {
[PATCH v6 05/19] dt-bindings: usb: usb-hcd: Add "tpl-support" property
The host controller device might be designed to work for the particular products or applications. In that case its DT node is supposed to be equipped with the tpl-support property. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/it'/its" - Discard '|' from the property description, since we don't need to preserve the text formatting. --- Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml index 52cc84c400c0..9881ac10380d 100644 --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml @@ -17,6 +17,12 @@ properties: description: Phandle of a companion device $ref: /schemas/types.yaml#/definitions/phandle + tpl-support: +description: + Indicates if the Targeted Peripheral List is supported for given + targeted hosts (non-PC hosts). +type: boolean + additionalProperties: true examples: -- 2.29.2
[PATCH v6 09/19] dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml file
With minor peculiarities (like uploading some vendor-specific firmware) these are just Generic xHCI controllers fully compatible with its properties. Make sure the Renesas USB xHCI DT nodes are also validated against the Generic xHCI DT schema. Signed-off-by: Serge Semin Reviewed-by: Rob Herring Reviewed-by: Yoshihiro Shimoda Reviewed-by: Lad Prabhakar --- Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml index 0f078bd0a3e5..7e5ed196b52c 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml @@ -11,7 +11,7 @@ maintainers: - Yoshihiro Shimoda allOf: - - $ref: "usb-hcd.yaml" + - $ref: "usb-xhci.yaml" properties: compatible: @@ -69,7 +69,7 @@ required: - power-domains - resets -additionalProperties: false +unevaluatedProperties: false examples: - | -- 2.29.2
