Re: [PATCH] ASoC: do not include pm_runtime.h if not used
On 07/03/2023 10:30, Claudiu Beznea wrote: diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c index 41db6617e2ed..dc892fac4baa 100644 --- a/sound/soc/qcom/lpass-sc7180.c +++ b/sound/soc/qcom/lpass-sc7180.c @@ -12,7 +12,6 @@ #include #include #include -#include #include #include #include diff --git a/sound/soc/qcom/lpass-sc7280.c b/sound/soc/qcom/lpass-sc7280.c index d43f480cbae3..ee4a4b553e74 100644 --- a/sound/soc/qcom/lpass-sc7280.c +++ b/sound/soc/qcom/lpass-sc7280.c @@ -8,7 +8,6 @@ #include #include #include -#include #include Has these been compile tested? the reason I ask is because both these drivers need SET_SYSTEM_SLEEP_PM_OPS macro from pm.h which was getting included from pm_runtime.h, now that is removed, am guessing it will cause a compile errors. can you atleast replace this with pm.h instead of removing it totally? --srini
Re: [PATCH] ASoC: do not include pm_runtime.h if not used
On Tue, Mar 07, 2023 at 12:30:22PM +0200, Claudiu Beznea wrote: > Do not include pm_runtime.h header in files where runtime PM support is > not implemented. > > Signed-off-by: Claudiu Beznea > --- ... > sound/soc/ti/omap-mcbsp-st.c | 1 - > 36 files changed, 37 deletions(-) Looks like header was copied by accident from omap-mcbsp.c when sidetone functionality was split into this new file. Acked-by: Jarkko Nikula
Re: [PATCH V4 1/3] core/device: Add function to return child node using name at substring "@"
> On 06-Mar-2023, at 9:09 AM, Athira Rajeev wrote:
>
> Add a function dt_find_by_name_substr() that returns the child node if
> it matches till first occurence at "@" of a given name, otherwise NULL.
> This is helpful for cases with node name like: "name@addr". In
> scenarios where nodes are added with "name@addr" format and if the
> value of "addr" is not known, that node can't be matched with node
> name or addr. Hence matching with substring as node name will return
> the expected result. Patch adds dt_find_by_name_substr() function
> and testcase for the same in core/test/run-device.c
>
> Signed-off-by: Athira Rajeev
> Reviewed-by: Mahesh Salgaonkar
> ---
> Changelog:
> v3 -> v4:
> - Addressed review comment from Mahesh and added his Reviewed-by.
Hi,
Looking for review comments. Please share feedback.
Thanks
Athira
>
> v2 -> v3:
> - After review comments from Mahesh, fixed the code
> to consider string upto "@" for both input node name
> as well as child node name. V2 version was comparing
> input node name and child node name upto string length
> of child name. But this will return wrong node if input
> name is larger than child name. Because it will match
> as substring for child name.
> https://lists.ozlabs.org/pipermail/skiboot/2023-January/018596.html
>
> v1 -> v2:
> - Addressed review comment from Dan to update
> the utility funtion to search and compare
> upto "@". Renamed it as dt_find_by_name_substr.
>
> core/device.c | 31 +++
> core/test/run-device.c | 15 +++
> include/device.h | 3 +++
> 3 files changed, 49 insertions(+)
>
> diff --git a/core/device.c b/core/device.c
> index b102dd97..6b457ec4 100644
> --- a/core/device.c
> +++ b/core/device.c
> @@ -395,6 +395,37 @@ struct dt_node *dt_find_by_name(struct dt_node *root,
> const char *name)
> }
>
>
> +struct dt_node *dt_find_by_name_substr(struct dt_node *root, const char
> *name)
> +{
> + struct dt_node *child, *match;
> + char *node, *child_node = NULL;
> +
> + node = strdup(name);
> + if (!node)
> + return NULL;
> + node = strtok(node, "@");
> + list_for_each(>children, child, list) {
> + child_node = strdup(child->name);
> + if (!child_node)
> + goto err;
> + child_node = strtok(child_node, "@");
> + if (!strcmp(child_node, node)) {
> + free(child_node);
> + free(node);
> + return child;
> + }
> +
> + match = dt_find_by_name_substr(child, name);
> + if (match)
> + return match;
> + }
> +
> + free(child_node);
> +err:
> + free(node);
> + return NULL;
> +}
> +
> struct dt_node *dt_new_check(struct dt_node *parent, const char *name)
> {
> struct dt_node *node = dt_find_by_name(parent, name);
> diff --git a/core/test/run-device.c b/core/test/run-device.c
> index 4a12382b..6997452e 100644
> --- a/core/test/run-device.c
> +++ b/core/test/run-device.c
> @@ -466,6 +466,21 @@ int main(void)
> new_prop_ph = dt_prop_get_u32(ut2, "something");
> assert(!(new_prop_ph == ev1_ph));
> dt_free(subtree);
> +
> + /* Test dt_find_by_name_substr */
> + root = dt_new_root("");
> + addr1 = dt_new_addr(root, "node", 0x1);
> + addr2 = dt_new_addr(root, "node0_1", 0x2);
> + assert(dt_find_by_name(root, "node@1") == addr1);
> + assert(dt_find_by_name(root, "node0_1@2") == addr2);
> + assert(dt_find_by_name_substr(root, "node@1") == addr1);
> + assert(dt_find_by_name_substr(root, "node0_1@2") == addr2);
> + assert(dt_find_by_name_substr(root, "node0_") == NULL);
> + assert(dt_find_by_name_substr(root, "node0_1") == addr2);
> + assert(dt_find_by_name_substr(root, "node0@") == NULL);
> + assert(dt_find_by_name_substr(root, "node0_@") == NULL);
> + dt_free(root);
> +
> return 0;
> }
>
> diff --git a/include/device.h b/include/device.h
> index 93fb90ff..b6a1a813 100644
> --- a/include/device.h
> +++ b/include/device.h
> @@ -184,6 +184,9 @@ struct dt_node *dt_find_by_path(struct dt_node *root,
> const char *path);
> /* Find a child node by name */
> struct dt_node *dt_find_by_name(struct dt_node *root, const char *name);
>
> +/* Find a child node by name and substring */
> +struct dt_node *dt_find_by_name_substr(struct dt_node *root, const char
> *name);
> +
> /* Find a node by phandle */
> struct dt_node *dt_find_by_phandle(struct dt_node *root, u32 phandle);
>
> --
> 2.31.1
>
[PATCH] powerpc/mm: Fix false detection of read faults
To support detection of read faults with Radix execute-only memory, the
vma_is_accessible() check in access_error() (which checks for PROT_NONE)
was replaced with a check to see if VM_READ was missing, and if so,
returns true to assert the fault was caused by a bad read.
This is incorrect, as it ignores that both VM_WRITE and VM_EXEC imply
read on powerpc, as defined in protection_map[]. This causes mappings
containing VM_WRITE or VM_EXEC without VM_READ to misreport the cause of
page faults, since the MMU is still allowing reads.
Correct this by restoring the original vma_is_accessible() check for
PROT_NONE mappings, and adding a separate check for Radix PROT_EXEC-only
mappings.
Fixes: 395cac7752b9 ("powerpc/mm: Support execute-only memory on the Radix MMU")
Reported-by: Michal Suchánek
Tested-by: Benjamin Gray
Signed-off-by: Russell Currey
---
arch/powerpc/mm/fault.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index c7ae86b04b8a..d0710ecc1fc7 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -271,11 +271,16 @@ static bool access_error(bool is_write, bool is_exec,
struct vm_area_struct *vma
}
/*
-* Check for a read fault. This could be caused by a read on an
-* inaccessible page (i.e. PROT_NONE), or a Radix MMU execute-only page.
+* VM_READ, VM_WRITE and VM_EXEC all imply read permissions, as
+* defined in protection_map[]. Read faults can only be caused by
+* a PROT_NONE mapping, or with a PROT_EXEC-only mapping on Radix.
*/
- if (unlikely(!(vma->vm_flags & VM_READ)))
+ if (unlikely(!vma_is_accessible(vma)))
return true;
+
+ if (unlikely(radix_enabled() && ((vma->vm_flags & VM_ACCESS_FLAGS) ==
VM_EXEC)))
+ return true;
+
/*
* We should ideally do the vma pkey access check here. But in the
* fault path, handle_mm_fault() also does the same check. To avoid
--
2.39.2
[powerpc:next-test] BUILD SUCCESS f3358336042bbcf24a0b916c283559133717bbb2
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: f3358336042bbcf24a0b916c283559133717bbb2 powerpc: Add myself to MAINTAINERS for Power VFIO support elapsed time: 830m configs tested: 97 configs skipped: 9 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc arc allyesconfig gcc arc buildonly-randconfig-r003-20230308 gcc arc defconfig gcc arc randconfig-r023-20230308 gcc arc randconfig-r043-20230308 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r012-20230308 gcc arm randconfig-r046-20230308 gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r005-20230309 clang arm64randconfig-r013-20230308 clang cskydefconfig gcc csky randconfig-r026-20230308 gcc csky randconfig-r036-20230308 gcc hexagon randconfig-r041-20230308 clang hexagon randconfig-r045-20230308 clang i386 allyesconfig gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-a001 gcc i386 randconfig-a002 clang i386 randconfig-a003 gcc i386 randconfig-a004 clang i386 randconfig-a005 gcc i386 randconfig-a006 clang i386 randconfig-a011 clang i386 randconfig-a012 gcc i386 randconfig-a013 clang i386 randconfig-a014 gcc i386 randconfig-a015 clang i386 randconfig-a016 gcc ia64 allmodconfig gcc ia64defconfig gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68kdefconfig gcc m68k randconfig-r006-20230309 gcc microblaze randconfig-r002-20230309 gcc mips allmodconfig gcc mips allyesconfig gcc mips buildonly-randconfig-r004-20230308 clang mips randconfig-r001-20230309 gcc nios2 defconfig gcc nios2randconfig-r014-20230308 gcc nios2randconfig-r016-20230308 gcc nios2randconfig-r035-20230308 gcc parisc defconfig gcc parisc randconfig-r031-20230308 gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc randconfig-r034-20230308 gcc riscvallmodconfig gcc riscv allnoconfig gcc riscv defconfig gcc riscvrandconfig-r042-20230308 clang riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390defconfig gcc s390 randconfig-r032-20230308 gcc s390 randconfig-r044-20230308 clang sh allmodconfig gcc sparcbuildonly-randconfig-r005-20230308 gcc sparc defconfig gcc sparc64 randconfig-r004-20230309 gcc sparc64 randconfig-r021-20230308 gcc um i386_defconfig gcc um x86_64_defconfig gcc x86_64allnoconfig gcc x86_64 allyesconfig gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64randconfig-a001 clang x86_64randconfig-a002 gcc x86_64randconfig-a003 clang x86_64randconfig-a004 gcc x86_64randconfig-a005 clang x86_64
Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
On 03/09/23 at 03:36pm, Thomas Bogendoerfer wrote: > On Wed, Mar 08, 2023 at 09:07:09PM +0800, Baoquan He wrote: > > ioremap_uc() is only meaningful on old x86-32 systems with the PAT > > extension, and on ia64 with its slightly unconventional ioremap() > > behavior. So remove the ioremap_uc() definition in architecutures > > other than x86 and ia64. These architectures all have asm-generic/io.h > > included and will have the default ioremap_uc() definition which > > returns NULL. > > > > This changes the existing behaviour, while no need to worry about > > any breakage because in the only callsite of ioremap_uc(), code > > has been adjusted to eliminate the impact. Please see > > atyfb_setup_generic() of drivers/video/fbdev/aty/atyfb_base.c. > > > > If any new invocation of ioremap_uc() need be added, please consider > > using ioremap() intead or adding a ARCH specific version if necessary. > > > > Acked-by: Geert Uytterhoeven > > Signed-off-by: Baoquan He > > Cc: linux-al...@vger.kernel.org > > Cc: linux-hexa...@vger.kernel.org > > Cc: linux-m...@lists.linux-m68k.org > > Cc: linux-m...@vger.kernel.org > > Cc: linux-par...@vger.kernel.org > > Cc: linuxppc-dev@lists.ozlabs.org > > Cc: linux...@vger.kernel.org > > Cc: sparcli...@vger.kernel.org > > --- > > Documentation/driver-api/device-io.rst | 9 + > > arch/alpha/include/asm/io.h| 1 - > > arch/hexagon/include/asm/io.h | 3 --- > > arch/m68k/include/asm/kmap.h | 1 - > > arch/mips/include/asm/io.h | 1 - > > arch/parisc/include/asm/io.h | 2 -- > > arch/powerpc/include/asm/io.h | 1 - > > arch/sh/include/asm/io.h | 2 -- > > arch/sparc/include/asm/io_64.h | 1 - > > 9 files changed, 5 insertions(+), 16 deletions(-) > > this doesn't apply to v6.3-rc1... what tree is this based on ? Sorry, I forgot mentioning this in cover letter. This series is followup of below patchset, so it's on top of below patchset and based on v6.3-rc1. https://lore.kernel.org/all/20230301034247.136007-1-...@redhat.com/T/#u [PATCH v5 00/17] mm: ioremap: Convert architectures to take GENERIC_IOREMAP way Thanks Baoquan
[powerpc:merge] BUILD SUCCESS 63b88b2ce373adab7537659372ef29302d10db5d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 63b88b2ce373adab7537659372ef29302d10db5d Automatic merge of 'master' into merge (2023-03-08 09:26) elapsed time: 722m configs tested: 97 configs skipped: 9 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc alpharandconfig-r036-20230308 gcc arc allyesconfig gcc arc buildonly-randconfig-r003-20230308 gcc arc defconfig gcc arc randconfig-r025-20230308 gcc arc randconfig-r043-20230308 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r046-20230308 gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r001-20230309 clang cskydefconfig gcc csky randconfig-r015-20230308 gcc hexagon randconfig-r035-20230308 clang hexagon randconfig-r041-20230308 clang hexagon randconfig-r045-20230308 clang i386 allyesconfig gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-a001 gcc i386 randconfig-a002 clang i386 randconfig-a003 gcc i386 randconfig-a004 clang i386 randconfig-a005 gcc i386 randconfig-a006 clang i386 randconfig-a011 clang i386 randconfig-a012 gcc i386 randconfig-a013 clang i386 randconfig-a014 gcc i386 randconfig-a015 clang i386 randconfig-a016 gcc ia64 allmodconfig gcc ia64defconfig gcc ia64 randconfig-r013-20230308 gcc ia64 randconfig-r024-20230308 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchbuildonly-randconfig-r005-20230308 gcc loongarch defconfig gcc m68k allmodconfig gcc m68kdefconfig gcc microblaze randconfig-r005-20230309 gcc mips allmodconfig gcc mips allyesconfig gcc mips randconfig-r023-20230308 gcc nios2 defconfig gcc nios2randconfig-r014-20230308 gcc parisc defconfig gcc parisc randconfig-r004-20230309 gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc randconfig-r021-20230308 clang powerpc randconfig-r031-20230308 gcc riscvallmodconfig gcc riscv allnoconfig gcc riscv defconfig gcc riscvrandconfig-r022-20230308 clang riscvrandconfig-r026-20230308 clang riscvrandconfig-r033-20230308 gcc riscvrandconfig-r042-20230308 clang riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390defconfig gcc s390 randconfig-r044-20230308 clang sh allmodconfig gcc sh buildonly-randconfig-r004-20230308 gcc sh randconfig-r011-20230308 gcc sh randconfig-r012-20230308 gcc sparc defconfig gcc sparcrandconfig-r034-20230308 gcc sparc64 buildonly-randconfig-r002-20230308 gcc um i386_defconfig gcc um x86_64_defconfig gcc x86_64allnoconfig gcc x86_64 allyesconfig gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64randconfig-a001 clang x86_64randconfig-a002 gcc x86_64
Re: [RFC PATCH 02/13] powerpc: Add initial Dynamic Execution Control Register (DEXCR) support
On Tue, 2023-03-07 at 14:45 +1000, Nicholas Piggin wrote:
> On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> > diff --git a/arch/powerpc/include/asm/cputable.h
> > b/arch/powerpc/include/asm/cputable.h
> > index 757dbded11dc..03bc192f2d8b 100644
> > --- a/arch/powerpc/include/asm/cputable.h
> > +++ b/arch/powerpc/include/asm/cputable.h
> > @@ -192,6 +192,10 @@ static inline void cpu_feature_keys_init(void)
> > { }
> > #define
> > CPU_FTR_P9_RADIX_PREFETCH_BUG LONG_ASM_CONST(0x0002)
> > #define
> > CPU_FTR_ARCH_31LONG_ASM_CONST(0x0004000
> > 0)
> > #define
> > CPU_FTR_DAWR1 LONG_ASM_CONST(0x0008)
> > +#define
> > CPU_FTR_DEXCR_SBHE LONG_ASM_CONST(0x0010)
> > +#define
> > CPU_FTR_DEXCR_IBRTPD LONG_ASM_CONST(0x0020)
> > +#define
> > CPU_FTR_DEXCR_SRAPDLONG_ASM_CONST(0x0040)
> > +#define
> > CPU_FTR_DEXCR_NPHIELONG_ASM_CONST(0x0080)
>
> We potentially don't need to use CPU_FTR bits for each of these. We
> only really want them to use instruction patching and make feature
> tests fast. But we have been a bit liberal with using them and they
> are kind of tied into cpu feature parsing code so maybe it's easier
> to go with them for now.
For the static only DEXCR series I've only got CPU_FTR_DEXCR_NPHIE
because that's needed for hashkey updates. The others don't really
matter; they are only interesting for masking out unsupported bits.
Masking itself seems to be unnecessary; the DEXCR will just ignore
unsupported bits. Attempting to set all bits on a P10 showed the first
8 were set and the remainder stayed 0'd, and the kernel worked fine.
It's definitely easier to use CPU_FTR_* for feature detection from the
PAPR specified blob though. Maybe it would be possible to support a
callback on a match instead of setting a feature flag.
@@ -1802,7 +1809,7 @@ int copy_thread(struct task_struct *p, const
>
>
> > @@ -1802,7 +1809,7 @@ int copy_thread(struct task_struct *p, const
> > struct kernel_clone_args *args)
> >
> > setup_ksp_vsid(p, sp);
> >
> > -#ifdef CONFIG_PPC64
> > +#ifdef CONFIG_PPC64
> > if (cpu_has_feature(CPU_FTR_DSCR)) {
> > p->thread.dscr_inherit = current-
> > >thread.dscr_inherit;
> > p->thread.dscr = mfspr(SPRN_DSCR);
> > @@ -1939,6 +1946,10 @@ void start_thread(struct pt_regs *regs,
> > unsigned long start, unsigned long sp)
> > current->thread.tm_tfiar = 0;
> > current->thread.load_tm = 0;
> > #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
> > +#ifdef CONFIG_PPC_BOOK3S_64
> > + if (cpu_has_feature(CPU_FTR_ARCH_31))
> > + mtspr(SPRN_DEXCR, get_thread_dexcr(
> > >thread));
> > +#endif /* CONFIG_PPC_BOOK3S_64 */
>
> You possibly don't need the ifdef here because CPU_FTR_ARCH_31 should
> fold away. Some of the others do because they're using open-coded
> access to struct members, but if you're using accessor functions to
> get and set such things, there may be no need to.
>
> I think my preference is for your style.
I've been revisiting where the DEXCR is initialised and updated. With
the static DEXCR, the thread value is just a field on the task struct
like the others.
Re: [PATCH v2] hvc/xen: prevent concurrent accesses to the shared ring
Roger Pau Monné writes: > On Mon, Dec 12, 2022 at 01:36:48PM +0100, Roger Pau Monné wrote: >> On Fri, Dec 02, 2022 at 12:40:05PM +0100, Roger Pau Monné wrote: >> > On Wed, Nov 30, 2022 at 05:08:06PM -0800, Stefano Stabellini wrote: >> > > On Wed, 30 Nov 2022, Roger Pau Monne wrote: >> > > > The hvc machinery registers both a console and a tty device based on >> > > > the hv ops provided by the specific implementation. Those two >> > > > interfaces however have different locks, and there's no single locks >> > > > that's shared between the tty and the console implementations, hence >> > > > the driver needs to protect itself against concurrent accesses. >> > > > Otherwise concurrent calls using the split interfaces are likely to >> > > > corrupt the ring indexes, leaving the console unusable. >> > > > >> > > > Introduce a lock to xencons_info to serialize accesses to the shared >> > > > ring. This is only required when using the shared memory console, >> > > > concurrent accesses to the hypercall based console implementation are >> > > > not an issue. >> > > > >> > > > Note the conditional logic in domU_read_console() is slightly modified >> > > > so the notify_daemon() call can be done outside of the locked region: >> > > > it's an hypercall and there's no need for it to be done with the lock >> > > > held. >> > > >> > > For domU_read_console: I don't mean to block this patch but we need to >> > > be sure about the semantics of hv_ops.get_chars. Either it is expected >> > > to be already locked, then we definitely shouldn't add another lock to >> > > domU_read_console. Or it is not expected to be already locked, then we >> > > should add the lock. >> > > >> > > My impression is that it is expected to be already locked, but I think >> > > we need Greg or Jiri to confirm one way or the other. >> > >> > Let me move both to the 'To:' field then. >> > >> > My main concern is the usage of hv_ops.get_chars hook in >> > hvc_poll_get_char(), as it's not obvious to me that callers of >> > tty->poll_get_char hook as returned by tty_find_polling_driver() will >> > always do so with the tty lock held (in fact the only user right now >> > doesn't seem to hold the tty lock). >> > >> > > Aside from that the rest looks fine. > > I guess I could reluctantly remove the lock in the get_chars hook, > albeit I'm not convinced at all the lock is not needed there. I don't know the xen driver, but other HVC backends have a lock around their private state in their get_chars() implementations. See eg. hvterm_raw_get_chars(). cheers
Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
Baoquan He writes: > ioremap_uc() is only meaningful on old x86-32 systems with the PAT > extension, and on ia64 with its slightly unconventional ioremap() > behavior. So remove the ioremap_uc() definition in architecutures > other than x86 and ia64. These architectures all have asm-generic/io.h > included and will have the default ioremap_uc() definition which > returns NULL. > > This changes the existing behaviour, while no need to worry about > any breakage because in the only callsite of ioremap_uc(), code > has been adjusted to eliminate the impact. Please see > atyfb_setup_generic() of drivers/video/fbdev/aty/atyfb_base.c. > > If any new invocation of ioremap_uc() need be added, please consider > using ioremap() intead or adding a ARCH specific version if necessary. > > Acked-by: Geert Uytterhoeven > Signed-off-by: Baoquan He > Cc: linux-al...@vger.kernel.org > Cc: linux-hexa...@vger.kernel.org > Cc: linux-m...@lists.linux-m68k.org > Cc: linux-m...@vger.kernel.org > Cc: linux-par...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux...@vger.kernel.org > Cc: sparcli...@vger.kernel.org > --- > Documentation/driver-api/device-io.rst | 9 + > arch/alpha/include/asm/io.h| 1 - > arch/hexagon/include/asm/io.h | 3 --- > arch/m68k/include/asm/kmap.h | 1 - > arch/mips/include/asm/io.h | 1 - > arch/parisc/include/asm/io.h | 2 -- > arch/powerpc/include/asm/io.h | 1 - Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems
- Original Message - > From: "Michael Ellerman" > To: "Timothy Pearson" , "kvm" > > Cc: "linuxppc-dev" > Sent: Thursday, March 9, 2023 5:40:01 AM > Subject: Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems > Timothy Pearson writes: >> This patch series reenables VFIO support on POWER systems. It >> is based on Alexey Kardashevskiys's patch series, rebased and >> successfully tested under QEMU with a Marvell PCIe SATA controller >> on a POWER9 Blackbird host. >> >> Alexey Kardashevskiy (3): >> powerpc/iommu: Add "borrowing" iommu_table_group_ops >> powerpc/pci_64: Init pcibios subsys a bit later >> powerpc/iommu: Add iommu_ops to report capabilities and allow blocking >> domains > > As sent the patches had lost Alexey's authorship (no From: line), I > fixed it up when applying so the first 3 are authored by Alexey. > > cheers Thanks for catching that, it wasn't intentional. Probably used a wrong Git command...
[PATCH v2 4/4] powerpc/bpf: use bpf_jit_binary_pack_[alloc|finalize|free]
Use bpf_jit_binary_pack_alloc in powerpc jit. The jit engine first
writes the program to the rw buffer. When the jit is done, the program
is copied to the final location with bpf_jit_binary_pack_finalize.
With multiple jit_subprogs, bpf_jit_free is called on some subprograms
that haven't got bpf_jit_binary_pack_finalize() yet. Implement custom
bpf_jit_free() like in commit 1d5f82d9dd47 ("bpf, x86: fix freeing of
not-finalized bpf_prog_pack") to call bpf_jit_binary_pack_finalize(),
if necessary. While here, correct the misnomer powerpc64_jit_data to
powerpc_jit_data as it is meant for both ppc32 and ppc64.
Signed-off-by: Hari Bathini
---
arch/powerpc/net/bpf_jit.h| 7 +-
arch/powerpc/net/bpf_jit_comp.c | 104 +-
arch/powerpc/net/bpf_jit_comp32.c | 4 +-
arch/powerpc/net/bpf_jit_comp64.c | 6 +-
4 files changed, 83 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index d767e39d5645..a8b7480c4d43 100644
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -168,15 +168,16 @@ static inline void bpf_clear_seen_register(struct
codegen_context *ctx, int i)
void bpf_jit_init_reg_mapping(struct codegen_context *ctx);
int bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64
func);
-int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context
*ctx,
+int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct
codegen_context *ctx,
u32 *addrs, int pass, bool extra_pass);
void bpf_jit_build_prologue(u32 *image, struct codegen_context *ctx);
void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx);
void bpf_jit_realloc_regs(struct codegen_context *ctx);
int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context *ctx, int
tmp_reg, long exit_addr);
-int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image, int pass, struct
codegen_context *ctx,
- int insn_idx, int jmp_off, int dst_reg);
+int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image, u32 *fimage, int
pass,
+ struct codegen_context *ctx, int insn_idx,
+ int jmp_off, int dst_reg);
#endif
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index d1794d9f0154..ece75c829499 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -42,10 +42,11 @@ int bpf_jit_emit_exit_insn(u32 *image, struct
codegen_context *ctx, int tmp_reg,
return 0;
}
-struct powerpc64_jit_data {
- struct bpf_binary_header *header;
+struct powerpc_jit_data {
+ struct bpf_binary_header *hdr;
+ struct bpf_binary_header *fhdr;
u32 *addrs;
- u8 *image;
+ u8 *fimage;
u32 proglen;
struct codegen_context ctx;
};
@@ -62,15 +63,18 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
u8 *image = NULL;
u32 *code_base;
u32 *addrs;
- struct powerpc64_jit_data *jit_data;
+ struct powerpc_jit_data *jit_data;
struct codegen_context cgctx;
int pass;
int flen;
- struct bpf_binary_header *bpf_hdr;
+ struct bpf_binary_header *fhdr = NULL;
+ struct bpf_binary_header *hdr = NULL;
struct bpf_prog *org_fp = fp;
struct bpf_prog *tmp_fp;
bool bpf_blinded = false;
bool extra_pass = false;
+ u8 *fimage = NULL;
+ u32 *fcode_base;
u32 extable_len;
u32 fixup_len;
@@ -100,9 +104,11 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
addrs = jit_data->addrs;
if (addrs) {
cgctx = jit_data->ctx;
- image = jit_data->image;
- bpf_hdr = jit_data->header;
+ fimage = jit_data->fimage;
+ fhdr = jit_data->fhdr;
proglen = jit_data->proglen;
+ hdr = jit_data->hdr;
+ image = (void *)hdr + ((void *)fimage - (void *)fhdr);
extra_pass = true;
goto skip_init_ctx;
}
@@ -120,7 +126,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
cgctx.stack_size = round_up(fp->aux->stack_depth, 16);
/* Scouting faux-generate pass 0 */
- if (bpf_jit_build_body(fp, 0, , addrs, 0, false)) {
+ if (bpf_jit_build_body(fp, NULL, NULL, , addrs, 0, false)) {
/* We hit something illegal or unsupported. */
fp = org_fp;
goto out_addrs;
@@ -135,7 +141,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
*/
if (cgctx.seen & SEEN_TAILCALL ||
!is_offset_in_branch_range((long)cgctx.idx * 4)) {
cgctx.idx = 0;
- if (bpf_jit_build_body(fp, 0, , addrs, 0, false)) {
+ if (bpf_jit_build_body(fp, NULL, NULL, , addrs, 0,
false)) {
fp = org_fp;
[PATCH v2 3/4] powerpc/bpf: implement bpf_arch_text_invalidate for bpf_prog_pack
Implement bpf_arch_text_invalidate and use it to fill unused part of
the bpf_prog_pack with trap instructions when a BPF program is freed.
Signed-off-by: Hari Bathini
---
arch/powerpc/net/bpf_jit_comp.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 0a70319116d1..d1794d9f0154 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -293,3 +293,18 @@ void *bpf_arch_text_copy(void *dst, void *src, size_t len)
return ret;
}
+
+int bpf_arch_text_invalidate(void *dst, size_t len)
+{
+ u32 inst = BREAKPOINT_INSTRUCTION;
+ int ret = -EINVAL;
+
+ if (WARN_ON_ONCE(core_kernel_text((unsigned long)dst)))
+ return ret;
+
+ mutex_lock(_mutex);
+ ret = patch_instructions(dst, , true, len);
+ mutex_unlock(_mutex);
+
+ return ret;
+}
--
2.39.2
[PATCH v2 1/4] powerpc/code-patching: introduce patch_instructions()
patch_instruction() entails setting up pte, patching the instruction,
clearing the pte and flushing the tlb. If multiple instructions need
to be patched, every instruction would have to go through the above
drill unnecessarily. Instead, introduce function patch_instructions()
that patches multiple instructions at one go while setting up the pte,
clearing the pte and flushing the tlb only once per page range of
instructions. Observed ~5X improvement in speed of execution using
patch_instructions() over patch_instructions(), when more instructions
are to be patched.
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/code-patching.h | 1 +
arch/powerpc/lib/code-patching.c | 151 ---
2 files changed, 106 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/include/asm/code-patching.h
b/arch/powerpc/include/asm/code-patching.h
index 3f881548fb61..059fc4fe700e 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -74,6 +74,7 @@ int create_cond_branch(ppc_inst_t *instr, const u32 *addr,
int patch_branch(u32 *addr, unsigned long target, int flags);
int patch_instruction(u32 *addr, ppc_inst_t instr);
int raw_patch_instruction(u32 *addr, ppc_inst_t instr);
+int patch_instructions(u32 *addr, u32 *code, bool fill_inst, size_t len);
static inline unsigned long patch_site_addr(s32 *site)
{
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index b00112d7ad46..33857b9b53de 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -278,77 +278,117 @@ static void unmap_patch_area(unsigned long addr)
flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
}
-static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t instr)
+static int __do_patch_instructions_mm(u32 *addr, u32 *code, bool fill_inst,
size_t len)
{
- int err;
- u32 *patch_addr;
- unsigned long text_poke_addr;
- pte_t *pte;
- unsigned long pfn = get_patch_pfn(addr);
- struct mm_struct *patching_mm;
- struct mm_struct *orig_mm;
+ struct mm_struct *patching_mm, *orig_mm;
+ unsigned long text_poke_addr, pfn;
+ u32 *patch_addr, *end, *pend;
+ ppc_inst_t instr;
spinlock_t *ptl;
+ int ilen, err;
+ pte_t *pte;
patching_mm = __this_cpu_read(cpu_patching_context.mm);
text_poke_addr = __this_cpu_read(cpu_patching_context.addr);
- patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
pte = get_locked_pte(patching_mm, text_poke_addr, );
if (!pte)
return -ENOMEM;
- __set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn,
PAGE_KERNEL), 0);
+ end = (void *)addr + len;
+ do {
+ pfn = get_patch_pfn(addr);
+ __set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn,
PAGE_KERNEL), 0);
- /* order PTE update before use, also serves as the hwsync */
- asm volatile("ptesync": : :"memory");
-
- /* order context switch after arbitrary prior code */
- isync();
-
- orig_mm = start_using_temp_mm(patching_mm);
-
- err = __patch_instruction(addr, instr, patch_addr);
+ /* order PTE update before use, also serves as the hwsync */
+ asm volatile("ptesync": : :"memory");
- /* hwsync performed by __patch_instruction (sync) if successful */
- if (err)
- mb(); /* sync */
+ /* order context switch after arbitrary prior code */
+ isync();
+
+ orig_mm = start_using_temp_mm(patching_mm);
+
+ patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
+ pend = (void *)addr + PAGE_SIZE - offset_in_page(addr);
+ if (end < pend)
+ pend = end;
+
+ while (addr < pend) {
+ instr = ppc_inst_read(code);
+ ilen = ppc_inst_len(instr);
+ err = __patch_instruction(addr, instr, patch_addr);
+ /* hwsync performed by __patch_instruction (sync) if
successful */
+ if (err) {
+ mb(); /* sync */
+ break;
+ }
+
+ patch_addr = (void *)patch_addr + ilen;
+ addr = (void *)addr + ilen;
+ if (!fill_inst)
+ code = (void *)code + ilen;
+ }
- /* context synchronisation performed by __patch_instruction (isync or
exception) */
- stop_using_temp_mm(patching_mm, orig_mm);
+ /* context synchronisation performed by __patch_instruction
(isync or exception) */
+ stop_using_temp_mm(patching_mm, orig_mm);
- pte_clear(patching_mm, text_poke_addr, pte);
- /*
-* ptesync to order PTE update before TLB
[PATCH v2 2/4] powerpc/bpf: implement bpf_arch_text_copy
bpf_arch_text_copy is used to dump JITed binary to RX page, allowing
multiple BPF programs to share the same page. Use the newly introduced
patch_instructions() to implement it. Around 5X improvement in speed
of execution observed, using the new patch_instructions() function
over patch_instruction(), while running the tests from test_bpf.ko.
Signed-off-by: Hari Bathini
---
arch/powerpc/net/bpf_jit_comp.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index e93aefcfb83f..0a70319116d1 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -13,9 +13,12 @@
#include
#include
#include
-#include
+#include
#include
+#include
+#include
+
#include "bpf_jit.h"
static void bpf_jit_fill_ill_insns(void *area, unsigned int size)
@@ -272,3 +275,21 @@ int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image,
int pass, struct code
ctx->exentry_idx++;
return 0;
}
+
+void *bpf_arch_text_copy(void *dst, void *src, size_t len)
+{
+ void *ret = ERR_PTR(-EINVAL);
+ int err;
+
+ if (WARN_ON_ONCE(core_kernel_text((unsigned long)dst)))
+ return ret;
+
+ ret = dst;
+ mutex_lock(_mutex);
+ err = patch_instructions(dst, src, false, len);
+ if (err)
+ ret = ERR_PTR(err);
+ mutex_unlock(_mutex);
+
+ return ret;
+}
--
2.39.2
[PATCH v2 0/4] enable bpf_prog_pack allocator for powerpc
Most BPF programs are small, but they consume a page each. For systems with busy traffic and many BPF programs, this may also add significant pressure on instruction TLB. High iTLB pressure usually slows down the whole system causing visible performance degradation for production workloads. bpf_prog_pack, a customized allocator that packs multiple bpf programs into preallocated memory chunks, was proposed [1] to address it. This series extends this support on powerpc. The first patch introduces patch_instructions() function to enable patching more than one instruction at a time. This change showed around 5X improvement in the time taken to run test_bpf test cases. Patches 2 & 3 add the arch specific functions needed to support this feature. Patch 4 enables the support for powerpc and ensures cleanup is handled racefully. Tested the changes successfully. [1] https://lore.kernel.org/bpf/20220204185742.271030-1-s...@kernel.org/ [2] https://lore.kernel.org/all/20221110184303.393179-1-hbath...@linux.ibm.com/ Changes in v2: * Introduced patch_instructions() to help with patching bpf programs. Hari Bathini (4): powerpc/code-patching: introduce patch_instructions() powerpc/bpf: implement bpf_arch_text_copy powerpc/bpf: implement bpf_arch_text_invalidate for bpf_prog_pack powerpc/bpf: use bpf_jit_binary_pack_[alloc|finalize|free] arch/powerpc/include/asm/code-patching.h | 1 + arch/powerpc/lib/code-patching.c | 151 --- arch/powerpc/net/bpf_jit.h | 7 +- arch/powerpc/net/bpf_jit_comp.c | 142 - arch/powerpc/net/bpf_jit_comp32.c| 4 +- arch/powerpc/net/bpf_jit_comp64.c| 6 +- 6 files changed, 226 insertions(+), 85 deletions(-) -- 2.39.2
[PATCH v2 4/4] powerpc/bpf: use bpf_jit_binary_pack_[alloc|finalize|free]
Use bpf_jit_binary_pack_alloc in powerpc jit. The jit engine first
writes the program to the rw buffer. When the jit is done, the program
is copied to the final location with bpf_jit_binary_pack_finalize.
With multiple jit_subprogs, bpf_jit_free is called on some subprograms
that haven't got bpf_jit_binary_pack_finalize() yet. Implement custom
bpf_jit_free() like in commit 1d5f82d9dd47 ("bpf, x86: fix freeing of
not-finalized bpf_prog_pack") to call bpf_jit_binary_pack_finalize(),
if necessary. While here, correct the misnomer powerpc64_jit_data to
powerpc_jit_data as it is meant for both ppc32 and ppc64.
Signed-off-by: Hari Bathini
---
arch/powerpc/net/bpf_jit.h| 7 +-
arch/powerpc/net/bpf_jit_comp.c | 104 +-
arch/powerpc/net/bpf_jit_comp32.c | 4 +-
arch/powerpc/net/bpf_jit_comp64.c | 6 +-
4 files changed, 83 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index d767e39d5645..a8b7480c4d43 100644
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -168,15 +168,16 @@ static inline void bpf_clear_seen_register(struct
codegen_context *ctx, int i)
void bpf_jit_init_reg_mapping(struct codegen_context *ctx);
int bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64
func);
-int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context
*ctx,
+int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct
codegen_context *ctx,
u32 *addrs, int pass, bool extra_pass);
void bpf_jit_build_prologue(u32 *image, struct codegen_context *ctx);
void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx);
void bpf_jit_realloc_regs(struct codegen_context *ctx);
int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context *ctx, int
tmp_reg, long exit_addr);
-int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image, int pass, struct
codegen_context *ctx,
- int insn_idx, int jmp_off, int dst_reg);
+int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image, u32 *fimage, int
pass,
+ struct codegen_context *ctx, int insn_idx,
+ int jmp_off, int dst_reg);
#endif
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index d1794d9f0154..ece75c829499 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -42,10 +42,11 @@ int bpf_jit_emit_exit_insn(u32 *image, struct
codegen_context *ctx, int tmp_reg,
return 0;
}
-struct powerpc64_jit_data {
- struct bpf_binary_header *header;
+struct powerpc_jit_data {
+ struct bpf_binary_header *hdr;
+ struct bpf_binary_header *fhdr;
u32 *addrs;
- u8 *image;
+ u8 *fimage;
u32 proglen;
struct codegen_context ctx;
};
@@ -62,15 +63,18 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
u8 *image = NULL;
u32 *code_base;
u32 *addrs;
- struct powerpc64_jit_data *jit_data;
+ struct powerpc_jit_data *jit_data;
struct codegen_context cgctx;
int pass;
int flen;
- struct bpf_binary_header *bpf_hdr;
+ struct bpf_binary_header *fhdr = NULL;
+ struct bpf_binary_header *hdr = NULL;
struct bpf_prog *org_fp = fp;
struct bpf_prog *tmp_fp;
bool bpf_blinded = false;
bool extra_pass = false;
+ u8 *fimage = NULL;
+ u32 *fcode_base;
u32 extable_len;
u32 fixup_len;
@@ -100,9 +104,11 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
addrs = jit_data->addrs;
if (addrs) {
cgctx = jit_data->ctx;
- image = jit_data->image;
- bpf_hdr = jit_data->header;
+ fimage = jit_data->fimage;
+ fhdr = jit_data->fhdr;
proglen = jit_data->proglen;
+ hdr = jit_data->hdr;
+ image = (void *)hdr + ((void *)fimage - (void *)fhdr);
extra_pass = true;
goto skip_init_ctx;
}
@@ -120,7 +126,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
cgctx.stack_size = round_up(fp->aux->stack_depth, 16);
/* Scouting faux-generate pass 0 */
- if (bpf_jit_build_body(fp, 0, , addrs, 0, false)) {
+ if (bpf_jit_build_body(fp, NULL, NULL, , addrs, 0, false)) {
/* We hit something illegal or unsupported. */
fp = org_fp;
goto out_addrs;
@@ -135,7 +141,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
*/
if (cgctx.seen & SEEN_TAILCALL ||
!is_offset_in_branch_range((long)cgctx.idx * 4)) {
cgctx.idx = 0;
- if (bpf_jit_build_body(fp, 0, , addrs, 0, false)) {
+ if (bpf_jit_build_body(fp, NULL, NULL, , addrs, 0,
false)) {
fp = org_fp;
[PATCH v2 3/4] powerpc/bpf: implement bpf_arch_text_invalidate for bpf_prog_pack
Implement bpf_arch_text_invalidate and use it to fill unused part of
the bpf_prog_pack with trap instructions when a BPF program is freed.
Signed-off-by: Hari Bathini
---
arch/powerpc/net/bpf_jit_comp.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 0a70319116d1..d1794d9f0154 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -293,3 +293,18 @@ void *bpf_arch_text_copy(void *dst, void *src, size_t len)
return ret;
}
+
+int bpf_arch_text_invalidate(void *dst, size_t len)
+{
+ u32 inst = BREAKPOINT_INSTRUCTION;
+ int ret = -EINVAL;
+
+ if (WARN_ON_ONCE(core_kernel_text((unsigned long)dst)))
+ return ret;
+
+ mutex_lock(_mutex);
+ ret = patch_instructions(dst, , true, len);
+ mutex_unlock(_mutex);
+
+ return ret;
+}
--
2.39.2
[PATCH v2 1/4] powerpc/code-patching: introduce patch_instructions()
patch_instruction() entails setting up pte, patching the instruction,
clearing the pte and flushing the tlb. If multiple instructions need
to be patched, every instruction would have to go through the above
drill unnecessarily. Instead, introduce function patch_instructions()
that patches multiple instructions at one go while setting up the pte,
clearing the pte and flushing the tlb only once per page range of
instructions. Observed ~5X improvement in speed of execution using
patch_instructions() over patch_instructions(), when more instructions
are to be patched.
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/code-patching.h | 1 +
arch/powerpc/lib/code-patching.c | 151 ---
2 files changed, 106 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/include/asm/code-patching.h
b/arch/powerpc/include/asm/code-patching.h
index 3f881548fb61..059fc4fe700e 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -74,6 +74,7 @@ int create_cond_branch(ppc_inst_t *instr, const u32 *addr,
int patch_branch(u32 *addr, unsigned long target, int flags);
int patch_instruction(u32 *addr, ppc_inst_t instr);
int raw_patch_instruction(u32 *addr, ppc_inst_t instr);
+int patch_instructions(u32 *addr, u32 *code, bool fill_inst, size_t len);
static inline unsigned long patch_site_addr(s32 *site)
{
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index b00112d7ad46..33857b9b53de 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -278,77 +278,117 @@ static void unmap_patch_area(unsigned long addr)
flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
}
-static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t instr)
+static int __do_patch_instructions_mm(u32 *addr, u32 *code, bool fill_inst,
size_t len)
{
- int err;
- u32 *patch_addr;
- unsigned long text_poke_addr;
- pte_t *pte;
- unsigned long pfn = get_patch_pfn(addr);
- struct mm_struct *patching_mm;
- struct mm_struct *orig_mm;
+ struct mm_struct *patching_mm, *orig_mm;
+ unsigned long text_poke_addr, pfn;
+ u32 *patch_addr, *end, *pend;
+ ppc_inst_t instr;
spinlock_t *ptl;
+ int ilen, err;
+ pte_t *pte;
patching_mm = __this_cpu_read(cpu_patching_context.mm);
text_poke_addr = __this_cpu_read(cpu_patching_context.addr);
- patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
pte = get_locked_pte(patching_mm, text_poke_addr, );
if (!pte)
return -ENOMEM;
- __set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn,
PAGE_KERNEL), 0);
+ end = (void *)addr + len;
+ do {
+ pfn = get_patch_pfn(addr);
+ __set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn,
PAGE_KERNEL), 0);
- /* order PTE update before use, also serves as the hwsync */
- asm volatile("ptesync": : :"memory");
-
- /* order context switch after arbitrary prior code */
- isync();
-
- orig_mm = start_using_temp_mm(patching_mm);
-
- err = __patch_instruction(addr, instr, patch_addr);
+ /* order PTE update before use, also serves as the hwsync */
+ asm volatile("ptesync": : :"memory");
- /* hwsync performed by __patch_instruction (sync) if successful */
- if (err)
- mb(); /* sync */
+ /* order context switch after arbitrary prior code */
+ isync();
+
+ orig_mm = start_using_temp_mm(patching_mm);
+
+ patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
+ pend = (void *)addr + PAGE_SIZE - offset_in_page(addr);
+ if (end < pend)
+ pend = end;
+
+ while (addr < pend) {
+ instr = ppc_inst_read(code);
+ ilen = ppc_inst_len(instr);
+ err = __patch_instruction(addr, instr, patch_addr);
+ /* hwsync performed by __patch_instruction (sync) if
successful */
+ if (err) {
+ mb(); /* sync */
+ break;
+ }
+
+ patch_addr = (void *)patch_addr + ilen;
+ addr = (void *)addr + ilen;
+ if (!fill_inst)
+ code = (void *)code + ilen;
+ }
- /* context synchronisation performed by __patch_instruction (isync or
exception) */
- stop_using_temp_mm(patching_mm, orig_mm);
+ /* context synchronisation performed by __patch_instruction
(isync or exception) */
+ stop_using_temp_mm(patching_mm, orig_mm);
- pte_clear(patching_mm, text_poke_addr, pte);
- /*
-* ptesync to order PTE update before TLB
[PATCH v2 2/4] powerpc/bpf: implement bpf_arch_text_copy
bpf_arch_text_copy is used to dump JITed binary to RX page, allowing
multiple BPF programs to share the same page. Use the newly introduced
patch_instructions() to implement it. Around 5X improvement in speed
of execution observed, using the new patch_instructions() function
over patch_instruction(), while running the tests from test_bpf.ko.
Signed-off-by: Hari Bathini
---
arch/powerpc/net/bpf_jit_comp.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index e93aefcfb83f..0a70319116d1 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -13,9 +13,12 @@
#include
#include
#include
-#include
+#include
#include
+#include
+#include
+
#include "bpf_jit.h"
static void bpf_jit_fill_ill_insns(void *area, unsigned int size)
@@ -272,3 +275,21 @@ int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image,
int pass, struct code
ctx->exentry_idx++;
return 0;
}
+
+void *bpf_arch_text_copy(void *dst, void *src, size_t len)
+{
+ void *ret = ERR_PTR(-EINVAL);
+ int err;
+
+ if (WARN_ON_ONCE(core_kernel_text((unsigned long)dst)))
+ return ret;
+
+ ret = dst;
+ mutex_lock(_mutex);
+ err = patch_instructions(dst, src, false, len);
+ if (err)
+ ret = ERR_PTR(err);
+ mutex_unlock(_mutex);
+
+ return ret;
+}
--
2.39.2
[PATCH v2 0/4] enable bpf_prog_pack allocator for powerpc
Most BPF programs are small, but they consume a page each. For systems with busy traffic and many BPF programs, this may also add significant pressure on instruction TLB. High iTLB pressure usually slows down the whole system causing visible performance degradation for production workloads. bpf_prog_pack, a customized allocator that packs multiple bpf programs into preallocated memory chunks, was proposed [1] to address it. This series extends this support on powerpc. The first patch introduces patch_instructions() function to enable patching more than one instruction at a time. This change showed around 5X improvement in the time taken to run test_bpf test cases. Patches 2 & 3 add the arch specific functions needed to support this feature. Patch 4 enables the support for powerpc and ensures cleanup is handled racefully. Tested the changes successfully. [1] https://lore.kernel.org/bpf/20220204185742.271030-1-s...@kernel.org/ [2] https://lore.kernel.org/all/20221110184303.393179-1-hbath...@linux.ibm.com/ Changes in v2: * Introduced patch_instructions() to help with patching bpf programs. Hari Bathini (4): powerpc/code-patching: introduce patch_instructions() powerpc/bpf: implement bpf_arch_text_copy powerpc/bpf: implement bpf_arch_text_invalidate for bpf_prog_pack powerpc/bpf: use bpf_jit_binary_pack_[alloc|finalize|free] arch/powerpc/include/asm/code-patching.h | 1 + arch/powerpc/lib/code-patching.c | 151 --- arch/powerpc/net/bpf_jit.h | 7 +- arch/powerpc/net/bpf_jit_comp.c | 142 - arch/powerpc/net/bpf_jit_comp32.c| 4 +- arch/powerpc/net/bpf_jit_comp64.c| 6 +- 6 files changed, 226 insertions(+), 85 deletions(-) -- 2.39.2
Re: [PATCH 0/3] Fix the PowerQUICC audio support using the QMC
On Tue, 07 Mar 2023 15:15:00 +0100, Herve Codina wrote: > A previous series added the PowerQUICC audio support using the QMC. > The v6 version of this previous series was applied but some feedbacks > lead to a v7 version. > > The v6 can be found here: > > https://lore.kernel.org/linux-kernel/20230217145645.1768659-1-herve.cod...@bootlin.com/ > and the v7, here: > > https://lore.kernel.org/linux-kernel/20230306161754.89146-1-herve.cod...@bootlin.com/ > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/3] dt-bindings: soc: fsl: cpm_qe: cpm1-scc-qmc: Remove unneeded property commit: 33a33005b2db0966c00d4f58dd2a36e5a44217db [2/3] dt-bindings: soc: fsl: cpm_qe: cpm1-tsa: Remove unneeded property commit: 0fb6f518cb46cf8bac7c30c29171050e355cd738 [3/3] soc: fsl: cpm1: qmc: Fix assigned timeslot masks commit: f37acbde076d8dbf5e4c694f29760e608fdffe11 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
On 3/8/23 18:10, Rob Herring wrote:
> On Mon, Mar 06, 2023 at 02:15:25PM -0500, Sean Anderson wrote:
>> This is a generic binding for simple MMIO GPIO controllers. Although we
>> have a single driver for these controllers, they were previously spread
>> over several files. Consolidate them. The register descriptions are
>> adapted from the comments in the source. There is no set order for the
>> registers, so I have not specified one.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> Changes in v10:
>> - New
>>
>> .../bindings/gpio/brcm,bcm6345-gpio.yaml | 16 +--
>> .../devicetree/bindings/gpio/gpio-mmio.yaml | 136 ++
>> .../bindings/gpio/ni,169445-nand-gpio.txt | 38 -
>> .../devicetree/bindings/gpio/wd,mbl-gpio.txt | 38 -
>> 4 files changed, 137 insertions(+), 91 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
>> delete mode 100644
>> Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
>> delete mode 100644 Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
>> b/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
>> index 4d69f79df859..e11f4af49c52 100644
>> --- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
>> +++ b/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
>> @@ -4,7 +4,7 @@
>> $id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> -title: Broadcom BCM6345 GPIO controller
>> +title: Broadcom BCM63xx GPIO controller
>>
>> maintainers:
>>- Álvaro Fernández Rojas
>> @@ -18,8 +18,6 @@ description: |+
>>
>>BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
>>and/or written, and the direction changed from input to output.
>> - BCM6345 have 16-bit data and dirout registers, where GPIO state can be
>> read
>> - and/or written, and the direction changed from input to output.
>>BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
>>and dirout registers, where GPIO state can be read and/or written, and the
>>direction changed from input to output.
>> @@ -29,7 +27,6 @@ properties:
>> enum:
>>- brcm,bcm6318-gpio
>>- brcm,bcm6328-gpio
>> - - brcm,bcm6345-gpio
>>- brcm,bcm6358-gpio
>>- brcm,bcm6362-gpio
>>- brcm,bcm6368-gpio
>> @@ -63,17 +60,6 @@ required:
>> additionalProperties: false
>>
>> examples:
>> - - |
>> -gpio@fffe0406 {
>> - compatible = "brcm,bcm6345-gpio";
>> - reg-names = "dirout", "dat";
>> - reg = <0xfffe0406 2>, <0xfffe040a 2>;
>> - native-endian;
>> -
>> - gpio-controller;
>> - #gpio-cells = <2>;
>> -};
>> -
>>- |
>> gpio@0 {
>>compatible = "brcm,bcm63268-gpio";
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
>> b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
>> new file mode 100644
>> index ..fd5c7055d542
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
>> @@ -0,0 +1,136 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/gpio/gpio-mmio.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Generic MMIO GPIO
>> +
>> +maintainers:
>> + - Linus Walleij
>> + - Bartosz Golaszewski
>> +
>> +description: |
>
> Don't need '|' unless you want line endings preserved. Elsewhere too.
OK
>> + Some simple GPIO controllers may consist of a single data register or a
>> pair
>> + of set/clear-bit registers. Such controllers are common for glue logic in
>> + FPGAs or ASICs. Commonly, these controllers are accessed over
>> memory-mapped
>> + NAND-style parallel busses.
>> +
>> +properties:
>> + big-endian:
>> +true
>
> big-endian: true
OK
>> +
>> + compatible:
>> +enum:
>> + - brcm,bcm6345-gpio # Broadcom BCM6345 GPIO controller
>> + - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO
>> controller
>> + - ni,169445-nand-gpio # National Instruments 169445 GPIO NAND
>> controller
>> +
>> + '#gpio-cells':
>> +const: 2
>> +
>> + gpio-controller:
>> +true
>
> ditto.
OK
--Sean
Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
On Wed, Mar 08, 2023 at 09:07:09PM +0800, Baoquan He wrote: > ioremap_uc() is only meaningful on old x86-32 systems with the PAT > extension, and on ia64 with its slightly unconventional ioremap() > behavior. So remove the ioremap_uc() definition in architecutures > other than x86 and ia64. These architectures all have asm-generic/io.h > included and will have the default ioremap_uc() definition which > returns NULL. > > This changes the existing behaviour, while no need to worry about > any breakage because in the only callsite of ioremap_uc(), code > has been adjusted to eliminate the impact. Please see > atyfb_setup_generic() of drivers/video/fbdev/aty/atyfb_base.c. > > If any new invocation of ioremap_uc() need be added, please consider > using ioremap() intead or adding a ARCH specific version if necessary. > > Acked-by: Geert Uytterhoeven > Signed-off-by: Baoquan He > Cc: linux-al...@vger.kernel.org > Cc: linux-hexa...@vger.kernel.org > Cc: linux-m...@lists.linux-m68k.org > Cc: linux-m...@vger.kernel.org > Cc: linux-par...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux...@vger.kernel.org > Cc: sparcli...@vger.kernel.org > --- > Documentation/driver-api/device-io.rst | 9 + > arch/alpha/include/asm/io.h| 1 - > arch/hexagon/include/asm/io.h | 3 --- > arch/m68k/include/asm/kmap.h | 1 - > arch/mips/include/asm/io.h | 1 - > arch/parisc/include/asm/io.h | 2 -- > arch/powerpc/include/asm/io.h | 1 - > arch/sh/include/asm/io.h | 2 -- > arch/sparc/include/asm/io_64.h | 1 - > 9 files changed, 5 insertions(+), 16 deletions(-) this doesn't apply to v6.3-rc1... what tree is this based on ? Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH] powerpc/pseries: Select the generic memory allocator.
Sebastian Andrzej Siewior writes:
> The RTAS work area allocator is using the generic memory allocator and
> as such it must select it.
>
> Select the generic memory allocator on pseries.
>
> Fixes: 43033bc62d349 ("powerpc/pseries: add RTAS work area allocator")
> Signed-off-by: Sebastian Andrzej Siewior
Thanks. Randy already sent the same fix:
https://lore.kernel.org/linuxppc-dev/20230223070116.660-4-rdun...@infradead.org/
> ---
> arch/powerpc/platforms/pseries/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/pseries/Kconfig
> b/arch/powerpc/platforms/pseries/Kconfig
> index b481c5c8bae11..1c23f2d4ed557 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -2,6 +2,7 @@
> config PPC_PSERIES
> depends on PPC64 && PPC_BOOK3S
> bool "IBM pSeries & new (POWER5-based) iSeries"
> + select GENERIC_ALLOCATOR
> select HAVE_PCSPKR_PLATFORM
> select MPIC
> select OF_DYNAMIC
> --
> 2.39.2
[PATCH] powerpc/imc-pmu: Use the correct spinlock initializer.
The macro __SPIN_LOCK_INITIALIZER() is implementation specific. Users
that desire to initialize a spinlock in a struct must use
__SPIN_LOCK_UNLOCKED().
Use __SPIN_LOCK_UNLOCKED() for the spinlock_t in imc_global_refc.
Fixes: 76d588dddc459 ("powerpc/imc-pmu: Fix use of mutex in IRQs disabled
section")
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/perf/imc-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 9d229ef7f86ef..ada817c49b722 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -51,7 +51,7 @@ static int trace_imc_mem_size;
* core and trace-imc
*/
static struct imc_pmu_ref imc_global_refc = {
- .lock = __SPIN_LOCK_INITIALIZER(imc_global_refc.lock),
+ .lock = __SPIN_LOCK_UNLOCKED(imc_global_refc.lock),
.id = 0,
.refc = 0,
};
--
2.39.2
[PATCH] powerpc/pseries: Select the generic memory allocator.
The RTAS work area allocator is using the generic memory allocator and
as such it must select it.
Select the generic memory allocator on pseries.
Fixes: 43033bc62d349 ("powerpc/pseries: add RTAS work area allocator")
Signed-off-by: Sebastian Andrzej Siewior
---
arch/powerpc/platforms/pseries/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index b481c5c8bae11..1c23f2d4ed557 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -2,6 +2,7 @@
config PPC_PSERIES
depends on PPC64 && PPC_BOOK3S
bool "IBM pSeries & new (POWER5-based) iSeries"
+ select GENERIC_ALLOCATOR
select HAVE_PCSPKR_PLATFORM
select MPIC
select OF_DYNAMIC
--
2.39.2
Re: [PATCH 3/3] powerpc/kvm: Enable prefixed instructions for HV KVM and disable for PR KVM
> On 08-Mar-2023, at 12:06 PM, Paul Mackerras wrote: > > Now that we can read prefixed instructions from a HV KVM guest and > emulate prefixed load/store instructions to emulated MMIO locations, > we can add HFSCR_PREFIXED into the set of bits that are set in the > HFSCR for a HV KVM guest on POWER10, allowing the guest to use > prefixed instructions. > > PR KVM has not yet been extended to handle prefixed instructions in > all situations where we might need to emulate them, so prevent the > guest from enabling prefixed instructions in the FSCR for now. > > Reviewed-by: Nicholas Piggin > Tested-by: Nicholas Piggin > Signed-off-by: Paul Mackerras > --- Tested on a Power10 system. Prefixed instructions work correctly. Tested-by: Sachin Sant > arch/powerpc/include/asm/reg.h | 1 + > arch/powerpc/kvm/book3s_hv.c | 9 +++-- > arch/powerpc/kvm/book3s_pr.c | 2 ++ > arch/powerpc/kvm/book3s_rmhandlers.S | 1 + > 4 files changed, 11 insertions(+), 2 deletions(-) >
Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems
Timothy Pearson writes: > This patch series reenables VFIO support on POWER systems. It > is based on Alexey Kardashevskiys's patch series, rebased and > successfully tested under QEMU with a Marvell PCIe SATA controller > on a POWER9 Blackbird host. > > Alexey Kardashevskiy (3): > powerpc/iommu: Add "borrowing" iommu_table_group_ops > powerpc/pci_64: Init pcibios subsys a bit later > powerpc/iommu: Add iommu_ops to report capabilities and allow blocking > domains As sent the patches had lost Alexey's authorship (no From: line), I fixed it up when applying so the first 3 are authored by Alexey. cheers > Timothy Pearson (1): > Add myself to MAINTAINERS for Power VFIO support > > MAINTAINERS | 5 + > arch/powerpc/include/asm/iommu.h | 6 +- > arch/powerpc/include/asm/pci-bridge.h | 7 + > arch/powerpc/kernel/iommu.c | 246 +- > arch/powerpc/kernel/pci_64.c | 2 +- > arch/powerpc/platforms/powernv/pci-ioda.c | 36 +++- > arch/powerpc/platforms/pseries/iommu.c| 27 +++ > arch/powerpc/platforms/pseries/pseries.h | 4 + > arch/powerpc/platforms/pseries/setup.c| 3 + > drivers/vfio/vfio_iommu_spapr_tce.c | 96 ++--- > 10 files changed, 338 insertions(+), 94 deletions(-) > > -- > 2.30.2
Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems
Alex Williamson writes: > On Mon, 6 Mar 2023 11:29:53 -0600 (CST) > Timothy Pearson wrote: > >> This patch series reenables VFIO support on POWER systems. It >> is based on Alexey Kardashevskiys's patch series, rebased and >> successfully tested under QEMU with a Marvell PCIe SATA controller >> on a POWER9 Blackbird host. >> >> Alexey Kardashevskiy (3): >> powerpc/iommu: Add "borrowing" iommu_table_group_ops >> powerpc/pci_64: Init pcibios subsys a bit later >> powerpc/iommu: Add iommu_ops to report capabilities and allow blocking >> domains >> >> Timothy Pearson (1): >> Add myself to MAINTAINERS for Power VFIO support >> >> MAINTAINERS | 5 + >> arch/powerpc/include/asm/iommu.h | 6 +- >> arch/powerpc/include/asm/pci-bridge.h | 7 + >> arch/powerpc/kernel/iommu.c | 246 +- >> arch/powerpc/kernel/pci_64.c | 2 +- >> arch/powerpc/platforms/powernv/pci-ioda.c | 36 +++- >> arch/powerpc/platforms/pseries/iommu.c| 27 +++ >> arch/powerpc/platforms/pseries/pseries.h | 4 + >> arch/powerpc/platforms/pseries/setup.c| 3 + >> drivers/vfio/vfio_iommu_spapr_tce.c | 96 ++--- >> 10 files changed, 338 insertions(+), 94 deletions(-) >> > > For vfio and MAINTAINERS portions, > > Acked-by: Alex Williamson Thanks. cheers
Re: [PATCH v2] hvc/xen: prevent concurrent accesses to the shared ring
Hello, It's been 3 months and no reply. On Mon, Dec 12, 2022 at 01:36:48PM +0100, Roger Pau Monné wrote: > Hello, > > Gentle ping regarding the locking question below. > > Thanks, Roger. > > On Fri, Dec 02, 2022 at 12:40:05PM +0100, Roger Pau Monné wrote: > > On Wed, Nov 30, 2022 at 05:08:06PM -0800, Stefano Stabellini wrote: > > > On Wed, 30 Nov 2022, Roger Pau Monne wrote: > > > > The hvc machinery registers both a console and a tty device based on > > > > the hv ops provided by the specific implementation. Those two > > > > interfaces however have different locks, and there's no single locks > > > > that's shared between the tty and the console implementations, hence > > > > the driver needs to protect itself against concurrent accesses. > > > > Otherwise concurrent calls using the split interfaces are likely to > > > > corrupt the ring indexes, leaving the console unusable. > > > > > > > > Introduce a lock to xencons_info to serialize accesses to the shared > > > > ring. This is only required when using the shared memory console, > > > > concurrent accesses to the hypercall based console implementation are > > > > not an issue. > > > > > > > > Note the conditional logic in domU_read_console() is slightly modified > > > > so the notify_daemon() call can be done outside of the locked region: > > > > it's an hypercall and there's no need for it to be done with the lock > > > > held. > > > > > > For domU_read_console: I don't mean to block this patch but we need to > > > be sure about the semantics of hv_ops.get_chars. Either it is expected > > > to be already locked, then we definitely shouldn't add another lock to > > > domU_read_console. Or it is not expected to be already locked, then we > > > should add the lock. > > > > > > My impression is that it is expected to be already locked, but I think > > > we need Greg or Jiri to confirm one way or the other. > > > > Let me move both to the 'To:' field then. > > > > My main concern is the usage of hv_ops.get_chars hook in > > hvc_poll_get_char(), as it's not obvious to me that callers of > > tty->poll_get_char hook as returned by tty_find_polling_driver() will > > always do so with the tty lock held (in fact the only user right now > > doesn't seem to hold the tty lock). > > > > > Aside from that the rest looks fine. I guess I could reluctantly remove the lock in the get_chars hook, albeit I'm not convinced at all the lock is not needed there. Roger.
Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms
"Arnd Bergmann" writes: > On Fri, Mar 3, 2023, at 02:04, Paul Gortmaker wrote: >> 01/03/2023 (Wed 14:23) Christophe Leroy wrote: >>> Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??: >>> Hope it clarifies how those reference boards are used. >> >> It was really useful input and gave an insight into how things get used. >> >> But let me put a slightly different slant on things. If there is no >> maintainer for the platform/architecture/CPU, then where is the >> obligation for mainline to keep it up to date just for your company to >> use the code/BSP as a reference? >> >> Do they continue to do this for one more year, or three or ... ??? >> Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ? > ... >> >> If you see change 0123abcdef breaks boot on your platform, you have a >> legit voice to gripe about it right then and there. Don't wait!!! > > I think the answer here is that Christophe is already the only person > that does this, so he is the de-facto maintainer for ppc32 regardless > of whether he wants himself listed in the file or not: Yes he is the de-facto 32-bit maintainer :) He's listed as a reviewer on the converged 64-bit/32-bit maintainers entry which is meant to reflect that: LINUX FOR POWERPC (32-BIT AND 64-BIT) M: Michael Ellerman R: Nicholas Piggin R: Christophe Leroy L: linuxppc-dev@lists.ozlabs.org But we could add a separate 32-bit entry if people think that would make things clearer. Although I don't think we could run separate trees for 64-bit and 32-bit, there'd be too many conflicts, so in that way I think one entry makes sense. cheers
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
On Tue, Mar 7, 2023 at 4:35 PM Sean Anderson wrote: > On 3/7/23 03:42, Krzysztof Kozlowski wrote: > > https://lore.kernel.org/all/20230126-gpio-mmio-fix-v2-1-38397aace...@ncr.com/ > > Thanks for linking to that. > > I believe this patch should be applied instead of that one because > > - It documents all the registers, which were previously only documented > in the driver > - It handles the endianness properties. > - It consolidates the various descriptions of this binding into one > schema. Niall are you sending a v3 of this patch soon? Include Sean on the reviewer list! Yours, Linus Walleij
