Re: [PATCH v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code
On Fri, Mar 22, 2024 at 08:45:59PM -0400, Peter Xu wrote:
> On Fri, Mar 22, 2024 at 01:48:18PM -0700, Andrew Morton wrote:
> > On Thu, 21 Mar 2024 18:08:02 -0400 pet...@redhat.com wrote:
> >
> > > From: Peter Xu
> > >
> > > Now follow_page() is ready to handle hugetlb pages in whatever form, and
> > > over all architectures. Switch to the generic code path.
> > >
> > > Time to retire hugetlb_follow_page_mask(), following the previous
> > > retirement of follow_hugetlb_page() in 4849807114b8.
> > >
> > > There may be a slight difference of how the loops run when processing slow
> > > GUP over a large hugetlb range on cont_pte/cont_pmd supported archs: each
> > > loop of __get_user_pages() will resolve one pgtable entry with the patch
> > > applied, rather than relying on the size of hugetlb hstate, the latter may
> > > cover multiple entries in one loop.
> > >
> > > A quick performance test on an aarch64 VM on M1 chip shows 15% degrade
> > > over
> > > a tight loop of slow gup after the path switched. That shouldn't be a
> > > problem because slow-gup should not be a hot path for GUP in general: when
> > > page is commonly present, fast-gup will already succeed, while when the
> > > page is indeed missing and require a follow up page fault, the slow gup
> > > degrade will probably buried in the fault paths anyway. It also explains
> > > why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> > > accelerate thp gup even for "pages != NULL"") lands, the latter not part
> > > of
> > > a performance analysis but a side benefit. If the performance will be a
> > > concern, we can consider handle CONT_PTE in follow_page().
> > >
> > > Before that is justified to be necessary, keep everything clean and
> > > simple.
> > >
> >
> > mm/gup.c:33:21: warning: 'follow_hugepd' declared 'static' but never
> > defined [-Wunused-function]
> >33 | static struct page *follow_hugepd(struct vm_area_struct *vma,
> > hugepd_t hugepd,
> > | ^
> >
> > --- a/mm/gup.c~mm-gup-handle-hugepd-for-follow_page-fix
> > +++ a/mm/gup.c
> > @@ -30,10 +30,12 @@ struct follow_page_context {
> > unsigned int page_mask;
> > };
> >
> > +#ifdef CONFIG_HAVE_FAST_GUP
> > static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t
> > hugepd,
> > unsigned long addr, unsigned int pdshift,
> > unsigned int flags,
> > struct follow_page_context *ctx);
> > +#endif
> >
> > static inline void sanity_check_pinned_pages(struct page **pages,
> > unsigned long npages)
> > _
> >
> >
> > This looks inelegant.
> >
> > That's two build issues so far. Please be more expansive in the
> > Kconfig variations when testing. Especially when mucking with pgtable
> > macros.
>
> Andrew,
>
> Apologies for that, and also for a slightly late response. Yeah it's time
> I'll need my set of things to do serious build tests, and I'll at least
> start to cover a few error prone configs/archs in with that.
>
> I was trying to rely on the build bot in many of previous such cases, as
> that was quite useful to me to cover many build issues without investing my
> own test setups, but I think for some reason it retired and stopped working
> for a while. Maybe I shouldn't have relied on it at all.
>
> For this specific issue, I'm not sure if CONFIG_HAVE_FAST_GUP is proper?
> As follow_hugepd() is used in slow gup not fast. So maybe we can put that
> under CONFIG_MMU below that code (and I think we can drop "static" too as I
> don't think it's anything useful). My version of fixup attached at the end
the static is useful; below patch did pass on m68k but won't on
x86.. ignore that please.
> of email, and I verified it on m68k build.
>
> I do plan to post a small fixup series to fix these issues (so far it may
> contain 1 formal patch to touch up vmstat_item_print_in_thp, and 2 fixups
> where I'll mark the subject with "fixup!" properly). Either you can pick
> up below or you can wait for my small patchset, should be there either
> today or tomorrow.
I changed plan here too; I found more users of HPAGE_PMD_NR assuming it's
defined even if !CONFIG_MMU. That's weird, as CONFIG_MMU doesn't even
define PMD_SHIFT... To fix this I decided to use the old trick on using
BUILD_BUG() like it used to work before; frankly I don't know how that
didn't throw warnings, but i'll make sure it passes all known builds (ps: I
still haven't got my build harness ready, so that will still be limited but
should solve known issues).
In short: please wait for my fixup series. Thanks.
>
> Thanks,
>
> ===8<===
> diff --git a/mm/gup.c b/mm/gup.c
> index 4cd349390477..a2ed8203495a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -30,11 +30,6 @@ struct follow_page_context {
> unsigned int page_mask;
> };
>
> -static struct page *follow_hugepd(struct
Re: [PATCH v3 03/12] mm: Make HPAGE_PXD_* macros even if !THP
Hi Peter,
On Fri, 22 Mar 2024 20:30:24 -0400 Peter Xu wrote:
> On Fri, Mar 22, 2024 at 10:14:56AM -0700, SeongJae Park wrote:
> > Hi Peter,
>
> Hi, SeongJae,
>
> >
> > On Thu, 21 Mar 2024 18:07:53 -0400 pet...@redhat.com wrote:
> >
> > > From: Peter Xu
> > >
> > > These macros can be helpful when we plan to merge hugetlb code into
> > > generic
> > > code. Move them out and define them even if !THP.
> > >
> > > We actually already defined HPAGE_PMD_NR for other reasons even if !THP.
> > > Reorganize these macros.
> > >
> > > Reviewed-by: Christoph Hellwig
> > > Reviewed-by: Jason Gunthorpe
> > > Signed-off-by: Peter Xu
> > > ---
> > > include/linux/huge_mm.h | 17 ++---
> > > 1 file changed, 6 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > > index de0c89105076..3bcdfc7e5d57 100644
> > > --- a/include/linux/huge_mm.h
> > > +++ b/include/linux/huge_mm.h
> > > @@ -64,9 +64,6 @@ ssize_t single_hugepage_flag_show(struct kobject *kobj,
> > > enum transparent_hugepage_flag flag);
> > > extern struct kobj_attribute shmem_enabled_attr;
> > >
> > > -#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> > > -#define HPAGE_PMD_NR (1< > > -
> > > /*
> > > * Mask of all large folio orders supported for anonymous THP; all
> > > orders up to
> > > * and including PMD_ORDER, except order-0 (which is not "huge") and
> > > order-1
> > > @@ -87,14 +84,19 @@ extern struct kobj_attribute shmem_enabled_attr;
> > > #define thp_vma_allowable_order(vma, vm_flags, smaps, in_pf,
> > > enforce_sysfs, order) \
> > > (!!thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf, enforce_sysfs,
> > > BIT(order)))
> > >
> > > -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > > #define HPAGE_PMD_SHIFT PMD_SHIFT
> > > #define HPAGE_PMD_SIZE ((1UL) << HPAGE_PMD_SHIFT)
> > > #define HPAGE_PMD_MASK (~(HPAGE_PMD_SIZE - 1))
> > > +#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> > > +#define HPAGE_PMD_NR (1< > >
> > > #define HPAGE_PUD_SHIFT PUD_SHIFT
> > > #define HPAGE_PUD_SIZE ((1UL) << HPAGE_PUD_SHIFT)
> > > #define HPAGE_PUD_MASK (~(HPAGE_PUD_SIZE - 1))
> > > +#define HPAGE_PUD_ORDER (HPAGE_PUD_SHIFT-PAGE_SHIFT)
> > > +#define HPAGE_PUD_NR (1< >
> > I just found latest mm-unstable fails one of my build configurations[1] with
> > below error. 'git bisect' says this is the first patch set started the
> > failure. I haven't looked in deep, but just reporting first.
> >
> > In file included from .../include/linux/mm.h:1115,
> > from .../mm/vmstat.c:14:
> > .../mm/vmstat.c: In function 'zoneinfo_show_print':
> > .../include/linux/huge_mm.h:87:25: error: 'PMD_SHIFT' undeclared (first
> > use in this function); did you mean 'PUD_SHIFT'?
> >87 | #define HPAGE_PMD_SHIFT PMD_SHIFT
> > | ^
> >
> > [1]
> > https://github.com/awslabs/damon-tests/blob/next/corr/tests/build_m68k.sh
>
> Apologies for the issue.
No problem at all, this blocks nothing in real :)
> This is caused by !CONFIG_MMU, I think.
>
> I thought this would be fairly easy to fix by putting these macros under
> CONFIG_PGTABLE_HAS_HUGE_LEAVES, however when doing this I could have found
> some other issue that violates this rule.. mm/vmstat.c has referenced
> HPAGE_PMD_NR even if vmstat_item_print_in_thp() wanted to guard it only
> with CONFIG_THP.
>
> /home/peterx/git/linux/mm/vmstat.c: In function 'zoneinfo_show_print':
> /home/peterx/git/linux/mm/vmstat.c:1689:42: error: 'HPAGE_PMD_NR' undeclared
> (first use in this function)
> 1689 | pages /= HPAGE_PMD_NR;
> | ^~~~
> /home/peterx/git/linux/mm/vmstat.c:1689:42: note: each undeclared identifier
> is reported only once for each function it appears in
> CC drivers/tty/tty_port.o
> /home/peterx/git/linux/mm/vmstat.c: In function 'vmstat_start':
> /home/peterx/git/linux/mm/vmstat.c:1822:33: error: 'HPAGE_PMD_NR' undeclared
> (first use in this function)
> 1822 | v[i] /= HPAGE_PMD_NR;
> | ^~~~
> make[4]: *** [/home/peterx/git/linux/scripts/Makefile.build:243: mm/vmstat.o]
> Error 1
>
> static __always_inline bool vmstat_item_print_in_thp(enum node_stat_item item)
> {
> if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
> return false;
> ...
> }
>
> I think the problem is vmstat_item_print_in_thp() uses IS_ENABLED() however
> that won't stop compiler from looking into the "if".. so it'll still try to
> find the HPAGE_PMD_NR macro.
>
> It means, I may need to further change vmstat_item_print_in_thp() to make
> this work in the clean way.. by properly switching to a #ifdef.
>
> For that I'll need to post a formal patch and add people to review. I'll
> keep you posted.
Thank you for this kind explanation, all
[GIT PULL] Please pull powerpc/linux.git powerpc-6.9-2 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc updates for 6.9. These were posted before the merge window but had complicated dependencies and/or conflicts with other content that has gone into 6.9. cheers The following changes since commit 66a27abac311a30edbbb65fe8c41ff1b13876faa: Merge tag 'powerpc-6.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2024-03-15 17:53:48 -0700) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.9-2 for you to fetch changes up to 5c4233cc0920cc90787aafe950b90f6c57a35b88: powerpc/kdump: Split KEXEC_CORE and CRASH_DUMP dependency (2024-03-17 13:34:00 +1100) - -- powerpc updates for 6.9 #2 - Handle errors in mark_rodata_ro() and mark_initmem_nx(). - Make struct crash_mem available without CONFIG_CRASH_DUMP. Thanks to: Christophe Leroy, Hari Bathini. - -- Christophe Leroy (1): powerpc: Handle error in mark_rodata_ro() and mark_initmem_nx() Hari Bathini (3): kexec/kdump: make struct crash_mem available without CONFIG_CRASH_DUMP powerpc/kexec: split CONFIG_KEXEC_FILE and CONFIG_CRASH_DUMP powerpc/kdump: Split KEXEC_CORE and CRASH_DUMP dependency arch/powerpc/Kconfig | 9 +- arch/powerpc/include/asm/kexec.h | 98 +++ arch/powerpc/kernel/prom.c | 2 +- arch/powerpc/kernel/setup-common.c | 2 +- arch/powerpc/kernel/smp.c| 4 +- arch/powerpc/kexec/Makefile | 3 +- arch/powerpc/kexec/core.c| 4 + arch/powerpc/kexec/elf_64.c | 4 +- arch/powerpc/kexec/file_load_64.c| 269 ++-- arch/powerpc/mm/book3s32/mmu.c | 7 +- arch/powerpc/mm/mmu_decl.h | 8 +- arch/powerpc/mm/nohash/8xx.c | 33 ++- arch/powerpc/mm/nohash/e500.c| 10 +- arch/powerpc/mm/pgtable_32.c | 38 ++- arch/powerpc/platforms/powernv/smp.c | 2 +- include/linux/crash_core.h | 12 +- 16 files changed, 274 insertions(+), 231 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmX+Jw4ACgkQUevqPMjh pYA6WA/+PVlWRRhMWDZ0BEMFKtVMwUlGJWSZGNGqX/5ZV40lcTIsuIruw8C6VY11 Hq1J+CafM3H7LnqzYwruAYhpBYwb1Oje6IK208XiKH+eUmCzzk+hLfjGdbNbkTOx 6xBqoV3Hjj+p4H6QRXYkZQihQDHy9IfuBGNtoaTaiVuqg9NOT9PLnVNYaI11uLBP qRS08hkORyJEOO/QRjoVXyXdP7pOwl1EbuYYg805BZ9NFlp7j105yT8XjKQ1X5w+ yF4b2eSV78/Z55dpnBM1GqJqkOSaQjq42PKS+JNSBRpgVDZiLzTdVgWBHY1Q2zho H5XH9RHvT789vtGsXxhYqvSOSMsM+LgdZo82ZQuqHDA5djmwoMOVXcb/NkyVZ0o3 E+glLdWe6X+0B8Fhx2PH4R5j5j1r3/B2Ighf9Qz60rXNCnbUfT8ZJefyUZg6pHMg Y/YwdftiqBRnVsK1VSvMrIW3/Sk47QHlM2d7B11R9sVw85zlVwg4FHFXlGtoVpFS cWZityzVY10wKcblhHYt0/X0n2eeMhjyZuq9lvgls2zypr1qxJ+x/URVVM4hzbNH P+1qvVUp9mHfSmUGqC5OWv/365BhPQy2t7vkK1NYmmfee2r2umHEY9zphu/yysUg OQvE+v0F7fETuYg/QTWLlsusEyU0uBCoJOxeB2M6KacrNZfE64A= =SfuI -END PGP SIGNATURE-
Re: [PATCH linux-next v2 0/3] powerpc/kexec: split CONFIG_CRASH_DUMP out from CONFIG_KEXEC_CORE
On Mon, 26 Feb 2024 16:00:07 +0530, Hari Bathini wrote: > This patch series is a follow-up to [1] based on discussions at [2] > about additional work needed to get it working on powerpc. > > The first patch in the series makes struct crash_mem available with or > without CONFIG_CRASH_DUMP enabled. The next patch moves kdump specific > code for kexec_file_load syscall under CONFIG_CRASH_DUMP and the last > patch splits other kdump specific code under CONFIG_CRASH_DUMP and > removes dependency with CONFIG_CRASH_DUMP for CONFIG_KEXEC_CORE. > > [...] Applied to powerpc/next. [1/3] kexec/kdump: make struct crash_mem available without CONFIG_CRASH_DUMP https://git.kernel.org/powerpc/c/56a34d799bfa53064e7b8bd354aacd176aeaecc8 [2/3] powerpc/kexec: split CONFIG_KEXEC_FILE and CONFIG_CRASH_DUMP https://git.kernel.org/powerpc/c/33f2cc0a2e90f7177c49559b434191b02efd0cd5 [3/3] powerpc/kdump: Split KEXEC_CORE and CRASH_DUMP dependency https://git.kernel.org/powerpc/c/5c4233cc0920cc90787aafe950b90f6c57a35b88 cheers
Re: [PATCH v2] powerpc: Handle error in mark_rodata_ro() and mark_initmem_nx()
On Sat, 16 Mar 2024 12:18:21 +0100, Christophe Leroy wrote: > mark_rodata_ro() and mark_initmem_nx() use functions that can > fail like set_memory_nx() and set_memory_ro(), leading to a not > protected kernel. > > In case of failure, panic. > > > [...] Applied to powerpc/next. [1/1] powerpc: Handle error in mark_rodata_ro() and mark_initmem_nx() https://git.kernel.org/powerpc/c/78cb0945f7141961781f815168f6873ad2b7ed29 cheers
Re: [PATCH v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code
On Fri, Mar 22, 2024 at 01:48:18PM -0700, Andrew Morton wrote:
> On Thu, 21 Mar 2024 18:08:02 -0400 pet...@redhat.com wrote:
>
> > From: Peter Xu
> >
> > Now follow_page() is ready to handle hugetlb pages in whatever form, and
> > over all architectures. Switch to the generic code path.
> >
> > Time to retire hugetlb_follow_page_mask(), following the previous
> > retirement of follow_hugetlb_page() in 4849807114b8.
> >
> > There may be a slight difference of how the loops run when processing slow
> > GUP over a large hugetlb range on cont_pte/cont_pmd supported archs: each
> > loop of __get_user_pages() will resolve one pgtable entry with the patch
> > applied, rather than relying on the size of hugetlb hstate, the latter may
> > cover multiple entries in one loop.
> >
> > A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
> > a tight loop of slow gup after the path switched. That shouldn't be a
> > problem because slow-gup should not be a hot path for GUP in general: when
> > page is commonly present, fast-gup will already succeed, while when the
> > page is indeed missing and require a follow up page fault, the slow gup
> > degrade will probably buried in the fault paths anyway. It also explains
> > why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> > accelerate thp gup even for "pages != NULL"") lands, the latter not part of
> > a performance analysis but a side benefit. If the performance will be a
> > concern, we can consider handle CONT_PTE in follow_page().
> >
> > Before that is justified to be necessary, keep everything clean and simple.
> >
>
> mm/gup.c:33:21: warning: 'follow_hugepd' declared 'static' but never defined
> [-Wunused-function]
>33 | static struct page *follow_hugepd(struct vm_area_struct *vma,
> hugepd_t hugepd,
> | ^
>
> --- a/mm/gup.c~mm-gup-handle-hugepd-for-follow_page-fix
> +++ a/mm/gup.c
> @@ -30,10 +30,12 @@ struct follow_page_context {
> unsigned int page_mask;
> };
>
> +#ifdef CONFIG_HAVE_FAST_GUP
> static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t
> hugepd,
> unsigned long addr, unsigned int pdshift,
> unsigned int flags,
> struct follow_page_context *ctx);
> +#endif
>
> static inline void sanity_check_pinned_pages(struct page **pages,
>unsigned long npages)
> _
>
>
> This looks inelegant.
>
> That's two build issues so far. Please be more expansive in the
> Kconfig variations when testing. Especially when mucking with pgtable
> macros.
Andrew,
Apologies for that, and also for a slightly late response. Yeah it's time
I'll need my set of things to do serious build tests, and I'll at least
start to cover a few error prone configs/archs in with that.
I was trying to rely on the build bot in many of previous such cases, as
that was quite useful to me to cover many build issues without investing my
own test setups, but I think for some reason it retired and stopped working
for a while. Maybe I shouldn't have relied on it at all.
For this specific issue, I'm not sure if CONFIG_HAVE_FAST_GUP is proper?
As follow_hugepd() is used in slow gup not fast. So maybe we can put that
under CONFIG_MMU below that code (and I think we can drop "static" too as I
don't think it's anything useful). My version of fixup attached at the end
of email, and I verified it on m68k build.
I do plan to post a small fixup series to fix these issues (so far it may
contain 1 formal patch to touch up vmstat_item_print_in_thp, and 2 fixups
where I'll mark the subject with "fixup!" properly). Either you can pick
up below or you can wait for my small patchset, should be there either
today or tomorrow.
Thanks,
===8<===
diff --git a/mm/gup.c b/mm/gup.c
index 4cd349390477..a2ed8203495a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -30,11 +30,6 @@ struct follow_page_context {
unsigned int page_mask;
};
-static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
- unsigned long addr, unsigned int pdshift,
- unsigned int flags,
- struct follow_page_context *ctx);
-
static inline void sanity_check_pinned_pages(struct page **pages,
unsigned long npages)
{
@@ -505,6 +500,12 @@ static inline void mm_set_has_pinned_flag(unsigned long
*mm_flags)
}
#ifdef CONFIG_MMU
+
+struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
+ unsigned long addr, unsigned int pdshift,
+ unsigned int flags,
+ struct follow_page_context *ctx);
+
static struct page *no_page_table(struct vm_area_struct *vma,
unsigned int flags, unsigned long address)
{
Re: [PATCH v3 03/12] mm: Make HPAGE_PXD_* macros even if !THP
On Fri, Mar 22, 2024 at 10:14:56AM -0700, SeongJae Park wrote:
> Hi Peter,
Hi, SeongJae,
>
> On Thu, 21 Mar 2024 18:07:53 -0400 pet...@redhat.com wrote:
>
> > From: Peter Xu
> >
> > These macros can be helpful when we plan to merge hugetlb code into generic
> > code. Move them out and define them even if !THP.
> >
> > We actually already defined HPAGE_PMD_NR for other reasons even if !THP.
> > Reorganize these macros.
> >
> > Reviewed-by: Christoph Hellwig
> > Reviewed-by: Jason Gunthorpe
> > Signed-off-by: Peter Xu
> > ---
> > include/linux/huge_mm.h | 17 ++---
> > 1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index de0c89105076..3bcdfc7e5d57 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -64,9 +64,6 @@ ssize_t single_hugepage_flag_show(struct kobject *kobj,
> > enum transparent_hugepage_flag flag);
> > extern struct kobj_attribute shmem_enabled_attr;
> >
> > -#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> > -#define HPAGE_PMD_NR (1< > -
> > /*
> > * Mask of all large folio orders supported for anonymous THP; all orders
> > up to
> > * and including PMD_ORDER, except order-0 (which is not "huge") and
> > order-1
> > @@ -87,14 +84,19 @@ extern struct kobj_attribute shmem_enabled_attr;
> > #define thp_vma_allowable_order(vma, vm_flags, smaps, in_pf,
> > enforce_sysfs, order) \
> > (!!thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf, enforce_sysfs,
> > BIT(order)))
> >
> > -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > #define HPAGE_PMD_SHIFT PMD_SHIFT
> > #define HPAGE_PMD_SIZE ((1UL) << HPAGE_PMD_SHIFT)
> > #define HPAGE_PMD_MASK (~(HPAGE_PMD_SIZE - 1))
> > +#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> > +#define HPAGE_PMD_NR (1< >
> > #define HPAGE_PUD_SHIFT PUD_SHIFT
> > #define HPAGE_PUD_SIZE ((1UL) << HPAGE_PUD_SHIFT)
> > #define HPAGE_PUD_MASK (~(HPAGE_PUD_SIZE - 1))
> > +#define HPAGE_PUD_ORDER (HPAGE_PUD_SHIFT-PAGE_SHIFT)
> > +#define HPAGE_PUD_NR (1<
> I just found latest mm-unstable fails one of my build configurations[1] with
> below error. 'git bisect' says this is the first patch set started the
> failure. I haven't looked in deep, but just reporting first.
>
> In file included from .../include/linux/mm.h:1115,
> from .../mm/vmstat.c:14:
> .../mm/vmstat.c: In function 'zoneinfo_show_print':
> .../include/linux/huge_mm.h:87:25: error: 'PMD_SHIFT' undeclared (first
> use in this function); did you mean 'PUD_SHIFT'?
>87 | #define HPAGE_PMD_SHIFT PMD_SHIFT
> | ^
>
> [1] https://github.com/awslabs/damon-tests/blob/next/corr/tests/build_m68k.sh
Apologies for the issue. This is caused by !CONFIG_MMU, I think.
I thought this would be fairly easy to fix by putting these macros under
CONFIG_PGTABLE_HAS_HUGE_LEAVES, however when doing this I could have found
some other issue that violates this rule.. mm/vmstat.c has referenced
HPAGE_PMD_NR even if vmstat_item_print_in_thp() wanted to guard it only
with CONFIG_THP.
/home/peterx/git/linux/mm/vmstat.c: In function 'zoneinfo_show_print':
/home/peterx/git/linux/mm/vmstat.c:1689:42: error: 'HPAGE_PMD_NR' undeclared
(first use in this function)
1689 | pages /= HPAGE_PMD_NR;
| ^~~~
/home/peterx/git/linux/mm/vmstat.c:1689:42: note: each undeclared identifier is
reported only once for each function it appears in
CC drivers/tty/tty_port.o
/home/peterx/git/linux/mm/vmstat.c: In function 'vmstat_start':
/home/peterx/git/linux/mm/vmstat.c:1822:33: error: 'HPAGE_PMD_NR' undeclared
(first use in this function)
1822 | v[i] /= HPAGE_PMD_NR;
| ^~~~
make[4]: *** [/home/peterx/git/linux/scripts/Makefile.build:243: mm/vmstat.o]
Error 1
static __always_inline bool vmstat_item_print_in_thp(enum node_stat_item item)
{
if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
return false;
...
}
I think the problem is vmstat_item_print_in_thp() uses IS_ENABLED() however
that won't stop compiler from looking into the "if".. so it'll still try to
find the HPAGE_PMD_NR macro.
It means, I may need to further change vmstat_item_print_in_thp() to make
this work in the clean way.. by properly switching to a #ifdef.
For that I'll need to post a formal patch and add people to review. I'll
keep you posted.
Side note: thank you for your script, just to mention make.cross has been
moved to kbuild/, and it'll also need kbuild.sh now to work. So you may
want to fix your test script (and it worked for you because you kept the
old make.cross around), like:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/kbuild/make.cross -O
./bin/make.cross
wget
Re: Cannot load wireguard module
Herbert Xu writes: > On Wed, Mar 20, 2024 at 11:41:32PM +1100, Michael Ellerman wrote: >> >> This diff fixes it for me: > > Yes I think this is the correct fix. Thanks, I'll send a proper patch next week. cheers
Re: [PATCH v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code
On Thu, 21 Mar 2024 18:08:02 -0400 pet...@redhat.com wrote:
> From: Peter Xu
>
> Now follow_page() is ready to handle hugetlb pages in whatever form, and
> over all architectures. Switch to the generic code path.
>
> Time to retire hugetlb_follow_page_mask(), following the previous
> retirement of follow_hugetlb_page() in 4849807114b8.
>
> There may be a slight difference of how the loops run when processing slow
> GUP over a large hugetlb range on cont_pte/cont_pmd supported archs: each
> loop of __get_user_pages() will resolve one pgtable entry with the patch
> applied, rather than relying on the size of hugetlb hstate, the latter may
> cover multiple entries in one loop.
>
> A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
> a tight loop of slow gup after the path switched. That shouldn't be a
> problem because slow-gup should not be a hot path for GUP in general: when
> page is commonly present, fast-gup will already succeed, while when the
> page is indeed missing and require a follow up page fault, the slow gup
> degrade will probably buried in the fault paths anyway. It also explains
> why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> accelerate thp gup even for "pages != NULL"") lands, the latter not part of
> a performance analysis but a side benefit. If the performance will be a
> concern, we can consider handle CONT_PTE in follow_page().
>
> Before that is justified to be necessary, keep everything clean and simple.
>
mm/gup.c:33:21: warning: 'follow_hugepd' declared 'static' but never defined
[-Wunused-function]
33 | static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t
hugepd,
| ^
--- a/mm/gup.c~mm-gup-handle-hugepd-for-follow_page-fix
+++ a/mm/gup.c
@@ -30,10 +30,12 @@ struct follow_page_context {
unsigned int page_mask;
};
+#ifdef CONFIG_HAVE_FAST_GUP
static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
unsigned long addr, unsigned int pdshift,
unsigned int flags,
struct follow_page_context *ctx);
+#endif
static inline void sanity_check_pinned_pages(struct page **pages,
unsigned long npages)
_
This looks inelegant.
That's two build issues so far. Please be more expansive in the
Kconfig variations when testing. Especially when mucking with pgtable
macros.
Re: [PATCH] powerpc: ps3: mark ps3_notification_device static for stack usage
On Fri, Mar 22, 2024, at 09:34, Geoff Levand wrote:
> On 3/21/24 17:32, Geert Uytterhoeven wrote:
>> --- a/arch/powerpc/platforms/ps3/device-init.c
>>> +++ b/arch/powerpc/platforms/ps3/device-init.c
>>> @@ -770,7 +770,7 @@ static struct task_struct *probe_task;
>>>
>>> static int ps3_probe_thread(void *data)
>>> {
>>> - struct ps3_notification_device dev;
>>> + static struct ps3_notification_device dev;
>>> int res;
>>> unsigned int irq;
>>> u64 lpar;
>>
>> Making it static increases kernel size for everyone. So I'd rather
>> allocate it dynamically. The thread already allocates a buffer, which
>> can be replaced at no cost by allocating a structure containing both
>> the ps3_notification_device and the buffer.
I didn't think it mattered much, given that you would rarely
have a kernel with PS3 support along with other platforms.
I suppose it does increase the size for a PS3-only kernel
as well, while your version makes it smaller.
> Here's what I came up with. It builds for me without warnings.
> I haven't tested it yet. A review would be appreciated.
It seems a little complicated but looks all correct to
me and reduces both stack and .data size, so
Acked-by: Arnd Bergmann
Re: [PATCH 3/4] PCI: Add TLP Prefix reading into pcie_read_tlp_log()
On Tue, Feb 06, 2024 at 03:57:16PM +0200, Ilpo Järvinen wrote:
> pcie_read_tlp_log() handles only 4 TLP Header Log DWORDs but TLP Prefix
> Log (PCIe r6.1 secs 7.8.4.12 & 7.9.14.13) may also be present.
s/TLP Header Log/Header Log/ to match spec terminology (also below)
> Generalize pcie_read_tlp_log() and struct pcie_tlp_log to handle also
> TLP Prefix Log. The layout of relevant registers in AER and DPC
> Capability is not identical but the offsets of TLP Header Log and TLP
> Prefix Log vary so the callers must pass the offsets to
> pcie_read_tlp_log().
s/is not identical but/is identical, but/ ?
The spec is a little obtuse about Header Log Size.
> Convert eetlp_prefix_path into integer called eetlp_prefix_max and
> make is available also when CONFIG_PCI_PASID is not configured to
> be able to determine the number of E-E Prefixes.
I think this eetlp_prefix_path piece is right, but would be nice in a
separate patch since it's a little bit different piece to review.
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -11336,7 +11336,9 @@ static pci_ers_result_t
> ixgbe_io_error_detected(struct pci_dev *pdev,
> if (!pos)
> goto skip_bad_vf_detection;
>
> - ret = pcie_read_tlp_log(pdev, pos + PCI_ERR_HEADER_LOG, _log);
> + ret = pcie_read_tlp_log(pdev, pos + PCI_ERR_HEADER_LOG,
> + pos + PCI_ERR_PREFIX_LOG,
> + aer_tlp_log_len(pdev), _log);
> if (ret < 0) {
> ixgbe_check_cfg_remove(hw, pdev);
> goto skip_bad_vf_detection;
We applied the patch to export pcie_read_tlp_log(), but I'm having
second thoughts about it. I don't think drivers really have any
business here, and I'd rather not expose either pcie_read_tlp_log() or
aer_tlp_log_len().
This part of ixgbe_io_error_detected() was added by 83c61fa97a7d
("ixgbe: Add protection from VF invalid target DMA"), and to me it
looks like debug code that probably doesn't need to be there as long
as the PCI core does the appropriate logging.
Bjorn
[PATCH v3 5/5] dt-bindings: hwmon: ibm,p8-occ-hwmon: move to trivial devices
This binding meets the requirements to be converted to dtschema
via trivial-devices.yaml.
Reviewed-by: Rob Herring
Signed-off-by: Javier Carrasco
---
.../devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt | 25 --
.../devicetree/bindings/trivial-devices.yaml | 2 ++
2 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt
b/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt
deleted file mode 100644
index 5dc5d2e2573d..
--- a/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Device-tree bindings for I2C-based On-Chip Controller hwmon device
---
-
-Required properties:
- - compatible = "ibm,p8-occ-hwmon";
- - reg = ;: I2C bus address
-
-Examples:
-
-i2c-bus@100 {
-#address-cells = <1>;
-#size-cells = <0>;
-clock-frequency = <10>;
-< more properties >
-
-occ-hwmon@1 {
-compatible = "ibm,p8-occ-hwmon";
-reg = <0x50>;
-};
-
-occ-hwmon@2 {
-compatible = "ibm,p8-occ-hwmon";
-reg = <0x51>;
-};
-};
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml
b/Documentation/devicetree/bindings/trivial-devices.yaml
index e07be7bf8395..87b0dd9b0734 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -126,6 +126,8 @@ properties:
- ibm,cffps1
# IBM Common Form Factor Power Supply Versions 2
- ibm,cffps2
+# IBM On-Chip Controller hwmon device
+ - ibm,p8-occ-hwmon
# Infineon barometric pressure and temperature sensor
- infineon,dps310
# Infineon IR36021 digital POL buck controller
--
2.40.1
[PATCH v3 4/5] dt-bindings: hwmon: stts751: convert to dtschema
Convert existing binding to support validation.
This is a straightforward conversion with no new properties.
Reviewed-by: Conor Dooley
Signed-off-by: Javier Carrasco
---
.../devicetree/bindings/hwmon/st,stts751.yaml | 41 ++
.../devicetree/bindings/hwmon/stts751.txt | 15
2 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/st,stts751.yaml
b/Documentation/devicetree/bindings/hwmon/st,stts751.yaml
new file mode 100644
index ..9c825adbed58
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/st,stts751.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/st,stts751.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STTS751 Thermometer
+
+maintainers:
+ - Javier Carrasco
+
+properties:
+ compatible:
+const: st,stts751
+
+ reg:
+maxItems: 1
+
+ smbus-timeout-disable:
+description:
+ When set, the smbus timeout function will be disabled.
+$ref: /schemas/types.yaml#/definitions/flag
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+thermometer@48 {
+compatible = "st,stts751";
+reg = <0x48>;
+smbus-timeout-disable;
+};
+};
diff --git a/Documentation/devicetree/bindings/hwmon/stts751.txt
b/Documentation/devicetree/bindings/hwmon/stts751.txt
deleted file mode 100644
index 3ee1dc30e72f..
--- a/Documentation/devicetree/bindings/hwmon/stts751.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* STTS751 thermometer.
-
-Required node properties:
-- compatible: "stts751"
-- reg: I2C bus address of the device
-
-Optional properties:
-- smbus-timeout-disable: when set, the smbus timeout function will be disabled
-
-Example stts751 node:
-
-temp-sensor {
- compatible = "stts751";
- reg = <0x48>;
-}
--
2.40.1
[PATCH v3 1/5] dt-bindings: hwmon: as370: convert to dtschema
Convert existing binding to support validation.
This is a straightforward conversion with now new properties.
Reviewed-by: Rob Herring
Signed-off-by: Javier Carrasco
---
Documentation/devicetree/bindings/hwmon/as370.txt | 11
.../devicetree/bindings/hwmon/syna,as370.yaml | 32 ++
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/as370.txt
b/Documentation/devicetree/bindings/hwmon/as370.txt
deleted file mode 100644
index d102fe765124..
--- a/Documentation/devicetree/bindings/hwmon/as370.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-Bindings for Synaptics AS370 PVT sensors
-
-Required properties:
-- compatible : "syna,as370-hwmon"
-- reg: address and length of the register set.
-
-Example:
- hwmon@ea0810 {
- compatible = "syna,as370-hwmon";
- reg = <0xea0810 0xc>;
- };
diff --git a/Documentation/devicetree/bindings/hwmon/syna,as370.yaml
b/Documentation/devicetree/bindings/hwmon/syna,as370.yaml
new file mode 100644
index ..1f7005f55247
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/syna,as370.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/syna,as370.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics AS370 PVT sensors
+
+maintainers:
+ - Javier Carrasco
+
+properties:
+ compatible:
+const: syna,as370-hwmon
+
+ reg:
+description:
+ Address and length of the register set.
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+sensor@ea0810 {
+compatible = "syna,as370-hwmon";
+reg = <0xea0810 0xc>;
+};
--
2.40.1
[PATCH v3 0/5] dt-bindings: hwmon: convert multiple devices to dtschema
This series converts the following existing bindings to dtschema: - as370 - ibmpowernv (renamed to ibm,opal-sensor to match compatibles) - stts751 - ibm,p8-occ-hwmon (moved to trivial-devices.yaml) Additionally, pwm-fan.txt has been dropped because it was converted a year ago, and it is not mentioned anywhere in the tree. I could not find the rationale, but its current state does not seem to provide any valuable information. Signed-off-by: Javier Carrasco --- Changes in v3: - Rename ibmpowernv to ibm,opal-sensor to match compatibles. - Link to v2: https://lore.kernel.org/r/20240322-hwmon_dtschema-v2-0-570bee1ac...@gmail.com Changes in v2: - ibmpowernv: fix compatible string in the example. - Link to v1: https://lore.kernel.org/r/20240321-hwmon_dtschema-v1-0-96c3810c3...@gmail.com --- Javier Carrasco (5): dt-bindings: hwmon: as370: convert to dtschema dt-bindings: hwmon: ibmpowernv: convert to dtschema dt-bindings: hwmon: pwm-fan: drop text file dt-bindings: hwmon: stts751: convert to dtschema dt-bindings: hwmon: ibm,p8-occ-hwmon: move to trivial devices Documentation/devicetree/bindings/hwmon/as370.txt | 11 -- .../devicetree/bindings/hwmon/ibm,opal-sensor.yaml | 37 +++ .../devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt | 25 - .../devicetree/bindings/hwmon/ibmpowernv.txt | 23 .../devicetree/bindings/hwmon/pwm-fan.txt | 1 - .../devicetree/bindings/hwmon/st,stts751.yaml | 41 ++ .../devicetree/bindings/hwmon/stts751.txt | 15 .../devicetree/bindings/hwmon/syna,as370.yaml | 32 + .../devicetree/bindings/trivial-devices.yaml | 2 ++ 9 files changed, 112 insertions(+), 75 deletions(-) --- base-commit: ebc9bee8814d12ec247de117aa2f7fd39ff11127 change-id: 20240320-hwmon_dtschema-7f58f49118aa Best regards, -- Javier Carrasco
[PATCH v3 2/5] dt-bindings: hwmon: ibmpowernv: convert to dtschema
Convert existing binding to support validation.
The binding has been renamed to match its compatible strings, with no
further additions.
Reviewed-by: Conor Dooley
Signed-off-by: Javier Carrasco
---
.../devicetree/bindings/hwmon/ibm,opal-sensor.yaml | 37 ++
.../devicetree/bindings/hwmon/ibmpowernv.txt | 23 --
2 files changed, 37 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml
b/Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml
new file mode 100644
index ..376ee7f1cdb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ibm,opal-sensor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM POWERNV platform sensors
+
+maintainers:
+ - Javier Carrasco
+
+properties:
+ compatible:
+enum:
+ - ibm,opal-sensor-cooling-fan
+ - ibm,opal-sensor-amb-temp
+ - ibm,opal-sensor-power-supply
+ - ibm,opal-sensor-power
+
+ sensor-id:
+description:
+ An opaque id provided by the firmware to the kernel, identifies a
+ given sensor and its attribute data.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - sensor-id
+
+additionalProperties: false
+
+examples:
+ - |
+sensor {
+compatible = "ibm,opal-sensor-cooling-fan";
+sensor-id = <0x7052107>;
+};
diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
deleted file mode 100644
index f93242be60a1..
--- a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-IBM POWERNV platform sensors
-
-
-Required node properties:
-- compatible: must be one of
- "ibm,opal-sensor-cooling-fan"
- "ibm,opal-sensor-amb-temp"
- "ibm,opal-sensor-power-supply"
- "ibm,opal-sensor-power"
-- sensor-id: an opaque id provided by the firmware to the kernel, identifies a
-given sensor and its attribute data
-
-Example sensors node:
-
-cooling-fan#8-data {
- sensor-id = <0x7052107>;
- compatible = "ibm,opal-sensor-cooling-fan";
-};
-
-amb-temp#1-thrs {
- sensor-id = <0x5096000>;
- compatible = "ibm,opal-sensor-amb-temp";
-};
--
2.40.1
[PATCH v3 3/5] dt-bindings: hwmon: pwm-fan: drop text file
This binding was converted to dtschema a year ago. Acked-by: Rob Herring Signed-off-by: Javier Carrasco --- Documentation/devicetree/bindings/hwmon/pwm-fan.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt deleted file mode 100644 index 48886f0ce415.. --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt +++ /dev/null @@ -1 +0,0 @@ -This file has moved to pwm-fan.yaml. -- 2.40.1
Re: [PATCH v2 4/5] dt-bindings: hwmon: stts751: convert to dtschema
On Fri, Mar 22, 2024 at 07:45:29AM +0100, Javier Carrasco wrote: > Convert existing binding to support validation. > > This is a straightforward conversion with no new properties. > Reviewed-by: Conor Dooley Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH v2 2/5] dt-bindings: hwmon: ibmpowernv: convert to dtschema
On Fri, Mar 22, 2024 at 07:45:27AM +0100, Javier Carrasco wrote:
> Convert existing binding to support validation.
>
> This is a straightforward conversion with now new properties.
>
> Signed-off-by: Javier Carrasco
> ---
> .../devicetree/bindings/hwmon/ibm,powernv.yaml | 37
> ++
> .../devicetree/bindings/hwmon/ibmpowernv.txt | 23 --
> 2 files changed, 37 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ibm,powernv.yaml
> b/Documentation/devicetree/bindings/hwmon/ibm,powernv.yaml
> new file mode 100644
> index ..b26d42bce938
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ibm,powernv.yaml
Filename should really match one of the compatibles. "powernv" is not a
type of hwmon as far as a quick google reports so I think its a poor
choice here regardless. With a compatible for the filename:
Reviewed-by: Conor Dooley
Thanks,
Conor.
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/ibm,powernv.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: IBM POWERNV platform sensors
> +
> +maintainers:
> + - Javier Carrasco
> +
> +properties:
> + compatible:
> +enum:
> + - ibm,opal-sensor-cooling-fan
> + - ibm,opal-sensor-amb-temp
> + - ibm,opal-sensor-power-supply
> + - ibm,opal-sensor-power
> +
> + sensor-id:
> +description:
> + An opaque id provided by the firmware to the kernel, identifies a
> + given sensor and its attribute data.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +
> +required:
> + - compatible
> + - sensor-id
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +sensor {
> +compatible = "ibm,opal-sensor-cooling-fan";
> +sensor-id = <0x7052107>;
> +};
> diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
> b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
> deleted file mode 100644
> index f93242be60a1..
> --- a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -IBM POWERNV platform sensors
> -
> -
> -Required node properties:
> -- compatible: must be one of
> - "ibm,opal-sensor-cooling-fan"
> - "ibm,opal-sensor-amb-temp"
> - "ibm,opal-sensor-power-supply"
> - "ibm,opal-sensor-power"
> -- sensor-id: an opaque id provided by the firmware to the kernel, identifies
> a
> - given sensor and its attribute data
> -
> -Example sensors node:
> -
> -cooling-fan#8-data {
> - sensor-id = <0x7052107>;
> - compatible = "ibm,opal-sensor-cooling-fan";
> -};
> -
> -amb-temp#1-thrs {
> - sensor-id = <0x5096000>;
> - compatible = "ibm,opal-sensor-amb-temp";
> -};
>
> --
> 2.40.1
>
signature.asc
Description: PGP signature
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
> Kind of odd though to change function names but not parameter names of > those very same functions. Ouch, this is definitely a valid point. Seems like this series will need a respin after all. Will wait for further comments, though. Thanks! signature.asc Description: PGP signature
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
On 22/03/2024 at 14:25, Wolfram Sang wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C v7, SMBus 3.2, I3C specifications and replace "master/slave" with more appropriate terms. For some drivers, this means no more conversions are needed. For the others more work needs to be done but this will be performed incrementally along with API changes/improvements. All these changes here are simple search/replace results. Signed-off-by: Wolfram Sang --- [..] drivers/i2c/busses/i2c-at91-master.c | 2 +- drivers/i2c/busses/i2c-at91-slave.c| 8 [..] Acked-by: Nicolas Ferre # for at91 Probably file names themselves will need some care, in a second time. Thanks. Regards, Nicolas [..] -- 2.43.0
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
On Fri, Mar 22, 2024 at 9:47 AM Wolfram Sang wrote: > > > > Acked-by: Nicolas Ferre # for at91 > > Probably file names themselves will need some care, in a second time. > > Totally true. I am aware of that. But one step after the other... > Kind of odd though to change function names but not parameter names of those very same functions. Guenter
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
> Acked-by: Nicolas Ferre # for at91 > Probably file names themselves will need some care, in a second time. Totally true. I am aware of that. But one step after the other... signature.asc Description: PGP signature
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
On Fri, Mar 22, 2024 at 02:25:57PM +0100, Wolfram Sang wrote: > Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C > v7, SMBus 3.2, I3C specifications and replace "master/slave" with more > appropriate terms. For some drivers, this means no more conversions are > needed. For the others more work needs to be done but this will be > performed incrementally along with API changes/improvements. All these > changes here are simple search/replace results. > > Signed-off-by: Wolfram Sang Reviewed-by: Bjorn Andersson Regards, Bjorn
[PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C
v7, SMBus 3.2, I3C specifications and replace "master/slave" with more
appropriate terms. For some drivers, this means no more conversions are
needed. For the others more work needs to be done but this will be
performed incrementally along with API changes/improvements. All these
changes here are simple search/replace results.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-amd-mp2-plat.c | 2 +-
drivers/i2c/busses/i2c-at91-master.c | 2 +-
drivers/i2c/busses/i2c-at91-slave.c| 8
drivers/i2c/busses/i2c-axxia.c | 10 +-
drivers/i2c/busses/i2c-cros-ec-tunnel.c| 2 +-
drivers/i2c/busses/i2c-designware-master.c | 2 +-
drivers/i2c/busses/i2c-designware-slave.c | 8
drivers/i2c/busses/i2c-diolan-u2c.c| 2 +-
drivers/i2c/busses/i2c-exynos5.c | 4 ++--
drivers/i2c/busses/i2c-gxp.c | 12 ++--
drivers/i2c/busses/i2c-hisi.c | 4 ++--
drivers/i2c/busses/i2c-img-scb.c | 2 +-
drivers/i2c/busses/i2c-imx.c | 12 ++--
drivers/i2c/busses/i2c-jz4780.c| 2 +-
drivers/i2c/busses/i2c-kempld.c| 2 +-
drivers/i2c/busses/i2c-meson.c | 4 ++--
drivers/i2c/busses/i2c-mlxbf.c | 8
drivers/i2c/busses/i2c-mt65xx.c| 2 +-
drivers/i2c/busses/i2c-mxs.c | 2 +-
drivers/i2c/busses/i2c-nomadik.c | 2 +-
drivers/i2c/busses/i2c-npcm7xx.c | 12 ++--
drivers/i2c/busses/i2c-nvidia-gpu.c| 4 ++--
drivers/i2c/busses/i2c-ocores.c| 8
drivers/i2c/busses/i2c-octeon-platdrv.c| 2 +-
drivers/i2c/busses/i2c-omap.c | 4 ++--
drivers/i2c/busses/i2c-opal.c | 4 ++--
drivers/i2c/busses/i2c-pasemi-core.c | 2 +-
drivers/i2c/busses/i2c-pnx.c | 2 +-
drivers/i2c/busses/i2c-pxa.c | 12 ++--
drivers/i2c/busses/i2c-qcom-cci.c | 2 +-
drivers/i2c/busses/i2c-qcom-geni.c | 2 +-
drivers/i2c/busses/i2c-robotfuzz-osif.c| 2 +-
drivers/i2c/busses/i2c-rzv2m.c | 8
drivers/i2c/busses/i2c-s3c2410.c | 4 ++--
drivers/i2c/busses/i2c-stm32f7.c | 14 +++---
drivers/i2c/busses/i2c-tegra-bpmp.c| 4 ++--
drivers/i2c/busses/i2c-tegra.c | 4 ++--
drivers/i2c/busses/i2c-thunderx-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-virtio.c| 2 +-
drivers/i2c/busses/i2c-wmt.c | 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
41 files changed, 95 insertions(+), 95 deletions(-)
diff --git a/drivers/i2c/busses/i2c-amd-mp2-plat.c
b/drivers/i2c/busses/i2c-amd-mp2-plat.c
index 112fe2bc5662..eb47de29ec90 100644
--- a/drivers/i2c/busses/i2c-amd-mp2-plat.c
+++ b/drivers/i2c/busses/i2c-amd-mp2-plat.c
@@ -179,7 +179,7 @@ static u32 i2c_amd_func(struct i2c_adapter *a)
}
static const struct i2c_algorithm i2c_amd_algorithm = {
- .master_xfer = i2c_amd_xfer,
+ .xfer = i2c_amd_xfer,
.functionality = i2c_amd_func,
};
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index d311981d3e60..56223eee7755 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -739,7 +739,7 @@ static u32 at91_twi_func(struct i2c_adapter *adapter)
}
static const struct i2c_algorithm at91_twi_algorithm = {
- .master_xfer= at91_twi_xfer,
+ .xfer = at91_twi_xfer,
.functionality = at91_twi_func,
};
diff --git a/drivers/i2c/busses/i2c-at91-slave.c
b/drivers/i2c/busses/i2c-at91-slave.c
index d6eeea5166c0..00234bf776ab 100644
--- a/drivers/i2c/busses/i2c-at91-slave.c
+++ b/drivers/i2c/busses/i2c-at91-slave.c
@@ -62,7 +62,7 @@ static irqreturn_t atmel_twi_interrupt_slave(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static int at91_reg_slave(struct i2c_client *slave)
+static int at91_reg_target(struct i2c_client *slave)
{
struct at91_twi_dev *dev = i2c_get_adapdata(slave->adapter);
@@ -86,7 +86,7 @@ static int at91_reg_slave(struct i2c_client *slave)
return 0;
}
-static int at91_unreg_slave(struct i2c_client *slave)
+static int at91_unreg_target(struct i2c_client *slave)
{
struct at91_twi_dev *dev = i2c_get_adapdata(slave->adapter);
@@ -111,8 +111,8 @@ static u32 at91_twi_func(struct i2c_adapter *adapter)
}
static const struct i2c_algorithm at91_twi_algorithm_slave = {
- .reg_slave = at91_reg_slave,
- .unreg_slave= at91_unreg_slave,
+ .reg_target = at91_reg_target,
+ .unreg_target = at91_unreg_target,
.functionality = at91_twi_func,
};
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index a66f7f67b3b8..19545a44dbc9 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++
Re: [PATCH v3 03/12] mm: Make HPAGE_PXD_* macros even if !THP
Hi Peter, On Thu, 21 Mar 2024 18:07:53 -0400 pet...@redhat.com wrote: > From: Peter Xu > > These macros can be helpful when we plan to merge hugetlb code into generic > code. Move them out and define them even if !THP. > > We actually already defined HPAGE_PMD_NR for other reasons even if !THP. > Reorganize these macros. > > Reviewed-by: Christoph Hellwig > Reviewed-by: Jason Gunthorpe > Signed-off-by: Peter Xu > --- > include/linux/huge_mm.h | 17 ++--- > 1 file changed, 6 insertions(+), 11 deletions(-) > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index de0c89105076..3bcdfc7e5d57 100644 > --- a/include/linux/huge_mm.h > +++ b/include/linux/huge_mm.h > @@ -64,9 +64,6 @@ ssize_t single_hugepage_flag_show(struct kobject *kobj, > enum transparent_hugepage_flag flag); > extern struct kobj_attribute shmem_enabled_attr; > > -#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) > -#define HPAGE_PMD_NR (1< - > /* > * Mask of all large folio orders supported for anonymous THP; all orders up > to > * and including PMD_ORDER, except order-0 (which is not "huge") and order-1 > @@ -87,14 +84,19 @@ extern struct kobj_attribute shmem_enabled_attr; > #define thp_vma_allowable_order(vma, vm_flags, smaps, in_pf, enforce_sysfs, > order) \ > (!!thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf, enforce_sysfs, > BIT(order))) > > -#ifdef CONFIG_TRANSPARENT_HUGEPAGE > #define HPAGE_PMD_SHIFT PMD_SHIFT > #define HPAGE_PMD_SIZE ((1UL) << HPAGE_PMD_SHIFT) > #define HPAGE_PMD_MASK (~(HPAGE_PMD_SIZE - 1)) > +#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) > +#define HPAGE_PMD_NR (1< > #define HPAGE_PUD_SHIFT PUD_SHIFT > #define HPAGE_PUD_SIZE ((1UL) << HPAGE_PUD_SHIFT) > #define HPAGE_PUD_MASK (~(HPAGE_PUD_SIZE - 1)) > +#define HPAGE_PUD_ORDER (HPAGE_PUD_SHIFT-PAGE_SHIFT) > +#define HPAGE_PUD_NR (1
Re: [RFC] sched/eevdf: sched feature to dismiss lag on wakeup
On Thu, 21 Mar 2024 at 13:18, Tobias Huschle wrote: > > On Wed, Mar 20, 2024 at 02:51:00PM +0100, Vincent Guittot wrote: > > On Wed, 20 Mar 2024 at 08:04, Tobias Huschle wrote: > > > There was no guarantee of course. place_entity was reducing the vruntime > > > of > > > woken up tasks though, giving it a slight boost, right?. For the scenario > > > > It was rather the opposite, It was ensuring that long sleeping tasks > > will not get too much bonus because of vruntime too far in the past. > > This is similar although not exactly the same intent as the lag. The > > bonus was up to 24ms previously whereas it's not more than a slice now > > > > I might have gotten this quite wrong then. I was looking at place_entity > and saw that non-initial placements get their vruntime reduced via > > vruntime -= thresh; and then se->vruntime = max_vruntime(se->vruntime, vruntime) > > which would mean that the placed task would have a vruntime smaller than > cfs_rq->min_vruntime, based on pre-EEVDF behavior, last seen at: > >af4cf40470c2 sched/fair: Add cfs_rq::avg_vruntime > > If there was no such benefit for woken up tasks. Then the scenario I observed > is just conincidentally worse with EEVDF, which can happen when exchanging an > algorithm I suppose. Or EEVDF just exposes a so far hidden problem in that > scenario.
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
On Fri, Mar 22, 2024 at 05:48:54PM +0100, Wolfram Sang wrote:
>
> > > static const struct i2c_algorithm at91_twi_algorithm = {
> > > - .master_xfer= at91_twi_xfer,
> > > + .xfer = at91_twi_xfer,
> >
> > Seems you made this by a script, can you check the indentations afterwards?
>
> Yes, I noticed as well. But other (not converted) drivers have issues
> there as well, so this will be a seperate patch.
The problem is that you add to a technical debt. We don't want that.
If you have not introduced a new indentation issue, it obviously is
not needed to be fixed in a separate patch. So, please consider this.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
> > static const struct i2c_algorithm at91_twi_algorithm = {
> > - .master_xfer= at91_twi_xfer,
> > + .xfer = at91_twi_xfer,
>
> Seems you made this by a script, can you check the indentations afterwards?
Yes, I noticed as well. But other (not converted) drivers have issues
there as well, so this will be a seperate patch.
Thanks!
signature.asc
Description: PGP signature
Re: [PATCH v3 00/12] mm/gup: Unify hugetlb, part 2
On Thu, Mar 21, 2024 at 06:07:50PM -0400, pet...@redhat.com wrote: > From: Peter Xu > > v3: > - Rebased to latest mm-unstalbe (a824831a082f, of March 21th) > - Dropped patch to introduce pmd_thp_or_huge(), replace such uses (and also > pXd_huge() users) with pXd_leaf() [Jason] > - Add a comment for CONFIG_PGTABLE_HAS_HUGE_LEAVES [Jason] > - Use IS_ENABLED() in follow_huge_pud() [Jason] > - Remove redundant none pud check in follow_pud_mask() [Jason] > > rfc: https://lore.kernel.org/r/20231116012908.392077-1-pet...@redhat.com > v1: https://lore.kernel.org/r/20231219075538.414708-1-pet...@redhat.com > v2: https://lore.kernel.org/r/20240103091423.400294-1-pet...@redhat.com > > The series removes the hugetlb slow gup path after a previous refactor work > [1], so that slow gup now uses the exact same path to process all kinds of > memory including hugetlb. > > For the long term, we may want to remove most, if not all, call sites of > huge_pte_offset(). It'll be ideal if that API can be completely dropped > from arch hugetlb API. This series is one small step towards merging > hugetlb specific codes into generic mm paths. From that POV, this series > removes one reference to huge_pte_offset() out of many others. This remark would be a little easier to understand if you refer to hugetlb_walk() not huge_pte_offset() - the latter is only used to implement hugetlb_walk() and isn't removed by this series, while a single hugetlb_walk() was removed. Regardless, I think the point is spot on, the direction should be to make the page table reading generic with minimal/no interaction with hugetlbfs in the generic code. After this series I would suggest doing the pagewalk.c stuff as it is very parallel to GUP slow (indeed it would be amazing to figure out a way to make GUP slow and pagewalk.c use the same code without a performance cost) Some of the other core mm callers don't look too bad either, getting to the point where hugetlb_walk() is internal to hugetlb.c would be a nice step that looks reasonable size. > One goal of such a route is that we can reconsider merging hugetlb features > like High Granularity Mapping (HGM). It was not accepted in the past > because it may add lots of hugetlb specific codes and make the mm code even > harder to maintain. With a merged codeset, features like HGM can hopefully > share some code with THP, legacy (PMD+) or modern (continuous PTEs). Yeah, if all the special hugetlb stuff is using generic arch code and generic page walkers (maybe with that special vma locking hook) it is much easier to swallow than adding yet another special class of code to all the page walkers. > To make it work, the generic slow gup code will need to at least understand > hugepd, which is already done like so in fast-gup. Due to the specialty of > hugepd to be software-only solution (no hardware recognizes the hugepd > format, so it's purely artificial structures), there's chance we can merge > some or all hugepd formats with cont_pte in the future. That question is > yet unsettled from Power side to have an acknowledgement. At a minimum, I think we have a concurrence that the reading of the hugepd entries should be fine through the standard contig pte APIs and so all the page walkers doing read side operations could stop having special hugepd code. It is just an implementation of contig pte with the new property that the size of a PTE can be larger than a PMD entry. If, or how much, the hugepd write side remains special is the open question, I think. > this series, I kept the hugepd handling because we may still need to do so > before getting a clearer picture of the future of hugepd. The other reason > is simply that we did it already for fast-gup and most codes are still > around to be reused. It'll make more sense to keep slow/fast gup behave > the same before a decision is made to remove hugepd. Yeah, I think that is right for this series. Lets get this done and then try to remove hugepd read side. Thanks, Jason
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
On Fri, Mar 22, 2024 at 02:25:57PM +0100, Wolfram Sang wrote:
> Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C
> v7, SMBus 3.2, I3C specifications and replace "master/slave" with more
> appropriate terms. For some drivers, this means no more conversions are
> needed. For the others more work needs to be done but this will be
> performed incrementally along with API changes/improvements. All these
> changes here are simple search/replace results.
...
> static const struct i2c_algorithm at91_twi_algorithm = {
> - .master_xfer= at91_twi_xfer,
> + .xfer = at91_twi_xfer,
Seems you made this by a script, can you check the indentations afterwards?
> .functionality = at91_twi_func,
> };
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code
On Fri, Mar 22, 2024 at 11:55:11AM -0400, Peter Xu wrote:
> Jason,
>
> On Fri, Mar 22, 2024 at 10:30:12AM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 21, 2024 at 06:08:02PM -0400, pet...@redhat.com wrote:
> >
> > > A quick performance test on an aarch64 VM on M1 chip shows 15% degrade
> > > over
> > > a tight loop of slow gup after the path switched. That shouldn't be a
> > > problem because slow-gup should not be a hot path for GUP in general: when
> > > page is commonly present, fast-gup will already succeed, while when the
> > > page is indeed missing and require a follow up page fault, the slow gup
> > > degrade will probably buried in the fault paths anyway. It also explains
> > > why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> > > accelerate thp gup even for "pages != NULL"") lands, the latter not part
> > > of
> > > a performance analysis but a side benefit. If the performance will be a
> > > concern, we can consider handle CONT_PTE in follow_page().
> >
> > I think this is probably fine for the moment, at least for this
> > series, as CONT_PTE is still very new.
> >
> > But it will need to be optimized. "slow" GUP is the only GUP that is
> > used by FOLL_LONGTERM and it still needs to be optimized because you
> > can't assume a FOLL_LONGTERM user will be hitting the really slow
> > fault path. There are enough important cases where it is just reading
> > already populted page tables, and these days, often with large folios.
>
> Ah, I thought FOLL_LONGTERM should work in most cases for fast-gup,
> especially for hugetlb, but maybe I missed something?
Ah, no this is my bad memory, there was a time where that was true,
but it is not the case now. Oh, it is a really bad memory because it
seems I removed parts of it :)
> I do see that devmap skips fast-gup for LONGTERM, we also have that
> writeback issue but none of those that I can find applies to
> hugetlb. This might be a problem indeed if we have hugetlb cont_pte
> pages that will constantly fallback to slow gup.
Right, DAX would be the main use case I can think of. Today the
intersection of DAX and contig PTE is non-existant so lets not worry.
> OTOH, I also agree with you that such batching would be nice to have for
> slow-gup, likely devmap or many fs (exclude shmem/hugetlb) file mappings
> can at least benefit from it due to above. But then that'll be a more
> generic issue to solve, IOW, we still don't do that for !hugetlb cont_pte
> large folios, before or after this series.
Right, improving contig pte is going to be a process and eventually it
will make sense to optimize this regardless of hugetlbfs
Jason
Re: [PATCH v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code
Jason,
On Fri, Mar 22, 2024 at 10:30:12AM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 21, 2024 at 06:08:02PM -0400, pet...@redhat.com wrote:
>
> > A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
> > a tight loop of slow gup after the path switched. That shouldn't be a
> > problem because slow-gup should not be a hot path for GUP in general: when
> > page is commonly present, fast-gup will already succeed, while when the
> > page is indeed missing and require a follow up page fault, the slow gup
> > degrade will probably buried in the fault paths anyway. It also explains
> > why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> > accelerate thp gup even for "pages != NULL"") lands, the latter not part of
> > a performance analysis but a side benefit. If the performance will be a
> > concern, we can consider handle CONT_PTE in follow_page().
>
> I think this is probably fine for the moment, at least for this
> series, as CONT_PTE is still very new.
>
> But it will need to be optimized. "slow" GUP is the only GUP that is
> used by FOLL_LONGTERM and it still needs to be optimized because you
> can't assume a FOLL_LONGTERM user will be hitting the really slow
> fault path. There are enough important cases where it is just reading
> already populted page tables, and these days, often with large folios.
Ah, I thought FOLL_LONGTERM should work in most cases for fast-gup,
especially for hugetlb, but maybe I missed something? I do see that devmap
skips fast-gup for LONGTERM, we also have that writeback issue but none of
those that I can find applies to hugetlb. This might be a problem indeed
if we have hugetlb cont_pte pages that will constantly fallback to slow
gup.
OTOH, I also agree with you that such batching would be nice to have for
slow-gup, likely devmap or many fs (exclude shmem/hugetlb) file mappings
can at least benefit from it due to above. But then that'll be a more
generic issue to solve, IOW, we still don't do that for !hugetlb cont_pte
large folios, before or after this series.
>
> Reviewed-by: Jason Gunthorpe
Thanks!
--
Peter Xu
Re: [PATCH 0/4] PCI: Consolidate TLP Log reading and printing
On Mon, 11 Mar 2024, Ilpo Järvinen wrote: > On Fri, 8 Mar 2024, Bjorn Helgaas wrote: > > > On Tue, Feb 06, 2024 at 03:57:13PM +0200, Ilpo Järvinen wrote: > > > This series consolidates AER & DPC TLP Log handling code. Helpers are > > > added for reading and printing the TLP Log and the format is made to > > > include E-E Prefixes in both cases (previously only one DPC RP PIO > > > displayed the E-E Prefixes). > > > > > > I'd appreciate if people familiar with ixgbe could check the error > > > handling conversion within the driver is correct. > > > > > > Ilpo Järvinen (4): > > > PCI/AER: Cleanup register variable > > > PCI: Generalize TLP Header Log reading > > > > I applied these first two to pci/aer for v6.9, thanks, these are all > > nice improvements! > > > > I postponed the ixgbe part for now because I think we should get an > > ack from those maintainers or just send it to them since it subtly > > changes the error and device removal checking there. > > Okay, I'll make sure they're separated properly for the remaining patches > (I was already planning on doing that separation and posting v2 to avoid > their input blocking the changed but you beat me to it). > > > > PCI: Add TLP Prefix reading into pcie_read_tlp_log() > > > PCI: Create helper to print TLP Header and Prefix Log > > > > I'll respond to these with some minor comments. > > Did you forget to send those comments? Ping. I still haven't received those comments for patches 3 & 4. -- i.
[PATCH 42/64] i2c: powermac: reword according to newest specification
Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
specifications and replace "master/slave" with more appropriate terms.
They are also more specific because we distinguish now between a remote
entity ("client") and a local one ("target").
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-powermac.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 8e57ebe595be..03abc5f3cb9e 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -25,7 +25,7 @@ MODULE_LICENSE("GPL");
/*
* SMBUS-type transfer entrypoint
*/
-static s32 i2c_powermac_smbus_xfer(struct i2c_adapter* adap,
+static s32 i2c_powermac_smbus_xfer(struct i2c_adapter *adap,
u16 addr,
unsigned short flags,
charread_write,
@@ -127,11 +127,11 @@ static s32 i2c_powermac_smbus_xfer( struct
i2c_adapter* adap,
}
/*
- * Generic i2c master transfer entrypoint. This driver only support single
+ * Generic i2c transfer entrypoint. This driver only supports single
* messages (for "lame i2c" transfers). Anything else should use the smbus
* entry point
*/
-static int i2c_powermac_master_xfer( struct i2c_adapter *adap,
+static int i2c_powermac_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
int num)
{
@@ -180,7 +180,7 @@ static u32 i2c_powermac_func(struct i2c_adapter * adapter)
/* For now, we only handle smbus */
static const struct i2c_algorithm i2c_powermac_algorithm = {
.smbus_xfer = i2c_powermac_smbus_xfer,
- .master_xfer= i2c_powermac_master_xfer,
+ .xfer = i2c_powermac_xfer,
.functionality = i2c_powermac_func,
};
--
2.43.0
[PATCH 14/64] i2c: cpm: reword according to newest specification
Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
specifications and replace "master/slave" with more appropriate terms.
They are also more specific because we distinguish now between a remote
entity ("client") and a local one ("target").
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-cpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index 4404b4aac676..306e397fec0a 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -402,7 +402,7 @@ static u32 cpm_i2c_func(struct i2c_adapter *adap)
/* -exported algorithm data: - */
static const struct i2c_algorithm cpm_i2c_algo = {
- .master_xfer = cpm_i2c_xfer,
+ .xfer = cpm_i2c_xfer,
.functionality = cpm_i2c_func,
};
@@ -570,7 +570,7 @@ static int cpm_i2c_setup(struct cpm_i2c *cpm)
out_8(>i2c_reg->i2brg, brg);
out_8(>i2c_reg->i2mod, 0x00);
- out_8(>i2c_reg->i2com, I2COM_MASTER); /* Master mode */
+ out_8(>i2c_reg->i2com, I2COM_MASTER); /* Host mode */
/* Disable interrupts. */
out_8(>i2c_reg->i2cmr, 0);
--
2.43.0
[PATCH 00/64] i2c: reword i2c_algorithm according to newest specification
Okay, we need to begin somewhere... Start changing the wording of the I2C main header wrt. the newest I2C v7, SMBus 3.2, I3C specifications and replace "master/slave" with more appropriate terms. This first step renames the members of struct i2c_algorithm. Once all in-tree users are converted, the anonymous union will go away again. All this work will also pave the way for finally seperating the monolithic header into more fine-grained headers like "i2c/clients.h" etc. So, this is not a simple renaming-excercise but also a chance to update the I2C core to recent Linux standards. My motivation is to improve the I2C core API, in general. My motivation is not to clean each and every driver. I think this is impossible because register names based on official documentation will need to stay as they are. But the Linux-internal names should be updated IMO. That being said, I worked on 62 drivers in this series beyond plain renames inside 'struct i2c_algorithm' because the fruits were so low-hanging. Before this series, 112 files in the 'busses/' directory contained 'master' and/or 'slave'. After the series, only 57. Why not? Next step is updating the drivers outside the 'i2c'-folder regarding 'struct i2c_algorithm' so we can remove the anonymous union ASAP. To be able to work on this with minimal dependencies, I'd like to apply this series between -rc1 and -rc2. I hope this will work for you guys. The changes are really minimal. If you are not comfortable with changes to your driver or need more time to review, please NACK the patch and I will drop the patch and/or address the issues separeately. @Andi: are you okay with this approach? It means you'd need to merge -rc2 into your for-next branch. Or rebase if all fails. Speaking of Andi, thanks a lot to him taking care of the controller drivers these days. His work really gives me the freedom to work on I2C core issues again. Also, Renesas deserves a honorable mention here for increased support of my I2C activities. Thank you! If you have comments, hints, etc, please let me know. Happy hacking, Wolfram Wolfram Sang (64): i2c: reword i2c_algorithm according to newest specification i2c: ali15x3: reword according to newest specification i2c: altera: reword according to newest specification i2c: amd-mp2-pci: reword according to newest specification i2c: aspeed: reword according to newest specification i2c: au1550: reword according to newest specification i2c: bcm-iproc: reword according to newest specification i2c: bcm-kona: reword according to newest specification i2c: bcm2835: reword according to newest specification i2c: brcmstb: reword according to newest specification i2c: cadence: reword according to newest specification i2c: cht-wc: reword according to newest specification i2c: cp2615: reword according to newest specification i2c: cpm: reword according to newest specification i2c: davinci: reword according to newest specification i2c: digicolor: reword according to newest specification i2c: dln2: reword according to newest specification i2c: eg20t: reword according to newest specification i2c: emev2: reword according to newest specification i2c: fsi: reword according to newest specification i2c: gpio: reword according to newest specification i2c: highlander: reword according to newest specification i2c: hix5hd2: reword according to newest specification i2c: i801: reword according to newest specification i2c: ibm_iic: reword according to newest specification i2c: imx-lpi2c: reword according to newest specification i2c: iop3xx: reword according to newest specification i2c: isch: reword according to newest specification i2c: ismt: reword according to newest specification i2c: ljca: reword according to newest specification i2c: lpc2k: reword according to newest specification i2c: ls2x: reword according to newest specification i2c: mchp-pci1: reword according to newest specification i2c: microchip-corei2c: reword according to newest specification i2c: mlxcpld: reword according to newest specification i2c: mpc: reword according to newest specification i2c: mt7621: reword according to newest specification i2c: mv64xxx: reword according to newest specification i2c: octeon-core: reword according to newest specification i2c: owl: reword according to newest specification i2c: piix4: reword according to newest specification i2c: powermac: reword according to newest specification i2c: pxa-pci: reword according to newest specification i2c: qup: reword according to newest specification i2c: rcar: reword according to newest specification i2c: riic: reword according to newest specification i2c: rk3x: reword according to newest specification i2c: sh7760: reword according to newest specification i2c: sh_mobile: reword according to newest specification i2c: sis5595: reword according to newest specification i2c: sis630: reword according to newest specification
Re: [PATCH v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code
On Thu, Mar 21, 2024 at 06:08:02PM -0400, pet...@redhat.com wrote:
> A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
> a tight loop of slow gup after the path switched. That shouldn't be a
> problem because slow-gup should not be a hot path for GUP in general: when
> page is commonly present, fast-gup will already succeed, while when the
> page is indeed missing and require a follow up page fault, the slow gup
> degrade will probably buried in the fault paths anyway. It also explains
> why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> accelerate thp gup even for "pages != NULL"") lands, the latter not part of
> a performance analysis but a side benefit. If the performance will be a
> concern, we can consider handle CONT_PTE in follow_page().
I think this is probably fine for the moment, at least for this
series, as CONT_PTE is still very new.
But it will need to be optimized. "slow" GUP is the only GUP that is
used by FOLL_LONGTERM and it still needs to be optimized because you
can't assume a FOLL_LONGTERM user will be hitting the really slow
fault path. There are enough important cases where it is just reading
already populted page tables, and these days, often with large folios.
Reviewed-by: Jason Gunthorpe
Jason
Re: [PATCH v3 05/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
On Thu, Mar 21, 2024 at 06:07:55PM -0400, pet...@redhat.com wrote:
> From: Peter Xu
>
> Hugepd format for GUP is only used in PowerPC with hugetlbfs. There are
> some kernel usage of hugepd (can refer to hugepd_populate_kernel() for
> PPC_8XX), however those pages are not candidates for GUP.
>
> Commit a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to
> file-backed mappings") added a check to fail gup-fast if there's potential
> risk of violating GUP over writeback file systems. That should never apply
> to hugepd. Considering that hugepd is an old format (and even
> software-only), there's no plan to extend hugepd into other file typed
> memories that is prone to the same issue.
>
> Drop that check, not only because it'll never be true for hugepd per any
> known plan, but also it paves way for reusing the function outside
> fast-gup.
>
> To make sure we'll still remember this issue just in case hugepd will be
> extended to support non-hugetlbfs memories, add a rich comment above
> gup_huge_pd(), explaining the issue with proper references.
>
> Cc: Christoph Hellwig
> Cc: Lorenzo Stoakes
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Peter Xu
> ---
> mm/gup.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
Re: [PATCH v3 04/12] mm: Introduce vma_pgtable_walk_{begin|end}()
On Thu, Mar 21, 2024 at 06:07:54PM -0400, pet...@redhat.com wrote: > From: Peter Xu > > Introduce per-vma begin()/end() helpers for pgtable walks. This is a > preparation work to merge hugetlb pgtable walkers with generic mm. > > The helpers need to be called before and after a pgtable walk, will start > to be needed if the pgtable walker code supports hugetlb pages. It's a > hook point for any type of VMA, but for now only hugetlb uses it to > stablize the pgtable pages from getting away (due to possible pmd > unsharing). > > Reviewed-by: Christoph Hellwig > Reviewed-by: Muchun Song > Signed-off-by: Peter Xu > --- > include/linux/mm.h | 3 +++ > mm/memory.c| 12 > 2 files changed, 15 insertions(+) is_vm_hugetlb_page(vma) seems weirdly named. Regardless Reviewed-by: Jason Gunthorpe Jason
Re: [PATCH v10 8/8] PCI: dwc: ep: Remove "core_init_notifier" flag
On Thu, Mar 14, 2024 at 01:18:06PM +0530, Manivannan Sadhasivam wrote: > "core_init_notifier" flag is set by the glue drivers requiring refclk from > the host to complete the DWC core initialization. Also, those drivers will > send a notification to the EPF drivers once the initialization is fully > completed using the pci_epc_init_notify() API. Only then, the EPF drivers > will start functioning. > > For the rest of the drivers generating refclk locally, EPF drivers will > start functioning post binding with them. EPF drivers rely on the > 'core_init_notifier' flag to differentiate between the drivers. > Unfortunately, this creates two different flows for the EPF drivers. > > So to avoid that, let's get rid of the "core_init_notifier" flag and follow > a single initialization flow for the EPF drivers. This is done by calling > the dw_pcie_ep_init_notify() from all glue drivers after the completion of > dw_pcie_ep_init_registers() API. This will allow all the glue drivers to > send the notification to the EPF drivers once the initialization is fully > completed. > > Only difference here is that, the drivers requiring refclk from host will > send the notification once refclk is received, while others will send it > during probe time itself. > > But this also requires the EPC core driver to deliver the notification > after EPF driver bind. Because, the glue driver can send the notification > before the EPF drivers bind() and in those cases the EPF drivers will miss > the event. To accommodate this, EPC core is now caching the state of the > EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the > notification to EPF drivers based on that after each EPF driver bind. > > Signed-off-by: Manivannan Sadhasivam > --- > drivers/pci/controller/dwc/pci-dra7xx.c | 2 ++ > drivers/pci/controller/dwc/pci-imx6.c | 2 ++ > drivers/pci/controller/dwc/pci-keystone.c | 2 ++ > drivers/pci/controller/dwc/pci-layerscape-ep.c| 2 ++ > drivers/pci/controller/dwc/pcie-artpec6.c | 2 ++ > drivers/pci/controller/dwc/pcie-designware-plat.c | 2 ++ > drivers/pci/controller/dwc/pcie-keembay.c | 2 ++ > drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 - > drivers/pci/controller/dwc/pcie-rcar-gen4.c | 2 ++ > drivers/pci/controller/dwc/pcie-tegra194.c| 1 - > drivers/pci/controller/dwc/pcie-uniphier-ep.c | 2 ++ > drivers/pci/endpoint/functions/pci-epf-test.c | 18 +- > drivers/pci/endpoint/pci-ep-cfs.c | 9 + > drivers/pci/endpoint/pci-epc-core.c | 22 ++ > include/linux/pci-epc.h | 7 --- > 15 files changed, 58 insertions(+), 18 deletions(-) FWIW: Tested-by: Niklas Cassel However, when looking at this, I was surprised that you never call something that will set: init_complete = false; from e.g. dw_pcie_ep_deinit() or dw_pcie_ep_cleanup(). I saw that you do seem to set init_complete = false; in your other follow up series that is based on this one. What will happen if you run with only this series merged (without your follow up series), on a platform that used to have .core_init_notifier? If you do remove and recreate the symlink on a platform with external refclk, since you never set init_complete to false, you could trigger EPF core_init callback, e.g. pci_epf_test_core_init() to be called, which will do DBI writes even when there is no refclk. E.g. (on a platform with external refclk): 1) Create symlink to pci-epf-test in configfs. 2) Start RC, your EPC driver will call ep_init_notifiy() when perst deasserts. 3) Run pci-epf-test. 4) Remove the pci-epf-test symlink 5) Shutdown RC 6) Create symlink to pci-epf-test in configfs. This will see that init_complete is true, and will do DBI writes which will crash your system, since you don't have a refclk. Perhaps you should move the patch that calls a function that sets init_complete = false; to this series, so that this crash is not possible? > > diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c > b/drivers/pci/controller/dwc/pci-dra7xx.c > index 395042b29ffc..d2d17d37d3e0 100644 > --- a/drivers/pci/controller/dwc/pci-dra7xx.c > +++ b/drivers/pci/controller/dwc/pci-dra7xx.c > @@ -474,6 +474,8 @@ static int dra7xx_add_pcie_ep(struct dra7xx_pcie *dra7xx, > return ret; > } > > + dw_pcie_ep_init_notify(ep); > + > return 0; > } > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c > b/drivers/pci/controller/dwc/pci-imx6.c > index bfcafa440ddb..894b5de76e3a 100644 > --- a/drivers/pci/controller/dwc/pci-imx6.c > +++ b/drivers/pci/controller/dwc/pci-imx6.c > @@ -1144,6 +1144,8 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie, > return ret; > } > > + dw_pcie_ep_init_notify(ep); > + > /* Start LTSSM. */ > imx6_pcie_ltssm_enable(dev); > > diff --git
Re: Cannot load wireguard module
On Wed, Mar 20, 2024 at 11:41:32PM +1100, Michael Ellerman wrote: > > This diff fixes it for me: Yes I think this is the correct fix. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v10 7/8] PCI: dwc: ep: Call dw_pcie_ep_init_registers() API directly from all glue drivers
On Thu, Mar 14, 2024 at 01:18:05PM +0530, Manivannan Sadhasivam wrote: > Currently, dw_pcie_ep_init_registers() API is directly called by the glue > drivers requiring active refclk from host. But for the other drivers, it is > getting called implicitly by dw_pcie_ep_init(). This is due to the fact > that this API initializes DWC EP specific registers and that requires an > active refclk (either from host or generated locally by endpoint itsef). > > But, this causes a discrepancy among the glue drivers. So to avoid this > confusion, let's call this API directly from all glue drivers irrespective > of refclk dependency. Only difference here is that the drivers requiring > refclk from host will call this API only after the refclk is received and > other drivers without refclk dependency will call this API right after > dw_pcie_ep_init(). > > With this change, the check for 'core_init_notifier' flag can now be > dropped from dw_pcie_ep_init() API. This will also allow us to remove the > 'core_init_notifier' flag completely in the later commits. > > Reviewed-by: Yoshihiro Shimoda > Signed-off-by: Manivannan Sadhasivam > --- Reviewed-by: Niklas Cassel
Re: [PATCH v10 2/8] PCI: dwc: ep: Add Kernel-doc comments for APIs
On Thu, Mar 14, 2024 at 01:18:00PM +0530, Manivannan Sadhasivam wrote:
> All of the APIs are missing the Kernel-doc comments. Hence, add them.
>
> Reviewed-by: Frank Li
> Signed-off-by: Manivannan Sadhasivam
> ---
> drivers/pci/controller/dwc/pcie-designware-ep.c | 78
> +
> 1 file changed, 78 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index c05304eabb89..d7e8f2dda6ce 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -14,6 +14,10 @@
> #include
> #include
>
> +/**
> + * dw_pcie_ep_linkup - Notify EPF drivers about link up event
> + * @ep: DWC EP device
> + */
> void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> {
> struct pci_epc *epc = ep->epc;
> @@ -22,6 +26,11 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> }
> EXPORT_SYMBOL_GPL(dw_pcie_ep_linkup);
>
> +/**
> + * dw_pcie_ep_init_notify - Notify EPF drivers about EPC initialization
> + * complete
Nit: "complete" can be on previous line without exceeding 80 chars.
> + * @ep: DWC EP device
> + */
> void dw_pcie_ep_init_notify(struct dw_pcie_ep *ep)
> {
> struct pci_epc *epc = ep->epc;
> @@ -30,6 +39,14 @@ void dw_pcie_ep_init_notify(struct dw_pcie_ep *ep)
> }
> EXPORT_SYMBOL_GPL(dw_pcie_ep_init_notify);
>
> +/**
> + * dw_pcie_ep_get_func_from_ep - Get the struct dw_pcie_ep_func
> corresponding to
> + *the endpoint function
> + * @ep: DWC EP device
> + * @func_no: Function number of the endpoint device
> + *
> + * Return: struct dw_pcie_ep_func if success, NULL otherwise.
> + */
> struct dw_pcie_ep_func *
> dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no)
> {
> @@ -60,6 +77,11 @@ static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8
> func_no,
> dw_pcie_dbi_ro_wr_dis(pci);
> }
>
> +/**
> + * dw_pcie_ep_reset_bar - Reset endpoint BAR
> + * @pci: DWC PCI device
> + * @bar: BAR number of the endpoint
> + */
> void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
> {
> u8 func_no, funcs;
> @@ -439,6 +461,13 @@ static const struct pci_epc_ops epc_ops = {
> .get_features = dw_pcie_ep_get_features,
> };
>
> +/**
> + * dw_pcie_ep_raise_intx_irq - Raise INTx IRQ to the host
> + * @ep: DWC EP device
> + * @func_no: Function number of the endpoint
> + *
> + * Return: 0 if success, errono otherwise.
> + */
> int dw_pcie_ep_raise_intx_irq(struct dw_pcie_ep *ep, u8 func_no)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> @@ -450,6 +479,14 @@ int dw_pcie_ep_raise_intx_irq(struct dw_pcie_ep *ep, u8
> func_no)
> }
> EXPORT_SYMBOL_GPL(dw_pcie_ep_raise_intx_irq);
>
> +/**
> + * dw_pcie_ep_raise_msi_irq - Raise MSI IRQ to the host
> + * @ep: DWC EP device
> + * @func_no: Function number of the endpoint
> + * @interrupt_num: Interrupt number to be raised
> + *
> + * Return: 0 if success, errono otherwise.
> + */
> int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
>u8 interrupt_num)
> {
> @@ -498,6 +535,15 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8
> func_no,
> }
> EXPORT_SYMBOL_GPL(dw_pcie_ep_raise_msi_irq);
>
> +/**
> + * dw_pcie_ep_raise_msix_irq_doorbell - Raise MSIX to the host using Doorbell
Nit: s/MSIX/MSI-X/
> + * method
> + * @ep: DWC EP device
> + * @func_no: Function number of the endpoint device
> + * @interrupt_num: Interrupt number to be raised
> + *
> + * Return: 0 if success, errno otherwise.
> + */
> int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8 func_no,
> u16 interrupt_num)
> {
> @@ -517,6 +563,14 @@ int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep
> *ep, u8 func_no,
> return 0;
> }
>
> +/**
> + * dw_pcie_ep_raise_msix_irq - Raise MSIX to the host
Nit: s/MSIX/MSI-X/
> + * @ep: DWC EP device
> + * @func_no: Function number of the endpoint device
> + * @interrupt_num: Interrupt number to be raised
> + *
> + * Return: 0 if success, errno otherwise.
> + */
> int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> u16 interrupt_num)
> {
> @@ -564,6 +618,13 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8
> func_no,
> return 0;
> }
>
> +/**
> + * dw_pcie_ep_exit - Deinitialize the endpoint device
> + * @ep: DWC EP device
> + *
> + * Deinitialize the endpoint device. EPC device is not destroyed since that
> will
> + * taken care by Devres.
Nit: s/will/will be/
> + */
> void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> @@ -599,6 +660,14 @@ static unsigned int
> dw_pcie_ep_find_ext_capability(struct dw_pcie *pci, int cap)
> return 0;
> }
>
> +/**
> + * dw_pcie_ep_init_complete - Complete DWC EP
[PATCH] Documentation: embargoed-hardware-issues.rst: Add myself for Power
Unfortunately Anton has left IBM. Add myself as the contact for Power, until someone else volunteers. Signed-off-by: Michael Ellerman --- Documentation/process/embargoed-hardware-issues.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index bb2100228cc7..6e9a4597bf2c 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -252,7 +252,7 @@ an involved disclosed party. The current ambassadors list: AMD Tom Lendacky Ampere Darren Hart ARM Catalin Marinas - IBM PowerAnton Blanchard + IBM PowerMichael Ellerman IBM ZChristian Borntraeger IntelTony Luck Qualcomm Trilok Soni -- 2.44.0
[PATCH v3] arch/powerpc/kvm: Add support for reading VPA counters for pseries guests
PAPR hypervisor has introduced three new counters in the VPA area of
LPAR CPUs for KVM L2 guest (see [1] for terminology) observability - 2
for context switches from host to guest and vice versa, and 1 counter
for getting the total time spent inside the KVM guest. Add a tracepoint
that enables reading the counters for use by ftrace/perf. Note that this
tracepoint is only available for nestedv2 API (i.e, KVM on PowerVM).
Also maintain an aggregation of the context switch times in vcpu->arch.
This will be useful in getting the aggregate times with a pmu driver
which will be upstreamed in the near future.
[1] Terminology:
a. L1 refers to the VM (LPAR) booted on top of PAPR hypervisor
b. L2 refers to the KVM guest booted on top of L1.
Signed-off-by: Vaibhav Jain
Signed-off-by: Gautam Menghani
---
v1 -> v2:
1. Fix the build error due to invalid struct member reference.
v2 -> v3:
1. Move the counter disabling and zeroing code to a different function.
2. Move the get_lppaca() inside the tracepoint_enabled() branch.
3. Add the aggregation logic to maintain total context switch time.
arch/powerpc/include/asm/kvm_host.h | 5 +
arch/powerpc/include/asm/lppaca.h | 11 +++---
arch/powerpc/kvm/book3s_hv.c| 33 +
arch/powerpc/kvm/trace_hv.h | 25 ++
4 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 8abac5321..d953b32dd 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -847,6 +847,11 @@ struct kvm_vcpu_arch {
gpa_t nested_io_gpr;
/* For nested APIv2 guests*/
struct kvmhv_nestedv2_io nestedv2_io;
+
+ /* Aggregate context switch and guest run time info (in ns) */
+ u64 l1_to_l2_cs_agg;
+ u64 l2_to_l1_cs_agg;
+ u64 l2_runtime_agg;
#endif
#ifdef CONFIG_KVM_BOOK3S_HV_EXIT_TIMING
diff --git a/arch/powerpc/include/asm/lppaca.h
b/arch/powerpc/include/asm/lppaca.h
index 61ec2447d..bda6b86b9 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -62,7 +62,8 @@ struct lppaca {
u8 donate_dedicated_cpu; /* Donate dedicated CPU cycles */
u8 fpregs_in_use;
u8 pmcregs_in_use;
- u8 reserved8[28];
+ u8 l2_accumul_cntrs_enable; /* Enable usage of counters for KVM
guest */
+ u8 reserved8[27];
__be64 wait_state_cycles; /* Wait cycles for this proc */
u8 reserved9[28];
__be16 slb_count; /* # of SLBs to maintain */
@@ -92,9 +93,13 @@ struct lppaca {
/* cacheline 4-5 */
__be32 page_ins; /* CMO Hint - # page ins by OS */
- u8 reserved12[148];
+ u8 reserved12[28];
+ volatile __be64 l1_to_l2_cs_tb;
+ volatile __be64 l2_to_l1_cs_tb;
+ volatile __be64 l2_runtime_tb;
+ u8 reserved13[96];
volatile __be64 dtl_idx;/* Dispatch Trace Log head index */
- u8 reserved13[96];
+ u8 reserved14[96];
} cacheline_aligned;
#define lppaca_of(cpu) (*paca_ptrs[cpu]->lppaca_ptr)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 8e86eb577..5a0bcb57e 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4108,6 +4108,30 @@ static void vcpu_vpa_increment_dispatch(struct kvm_vcpu
*vcpu)
}
}
+static void do_trace_nested_cs_time(struct kvm_vcpu *vcpu)
+{
+ struct lppaca *lp = get_lppaca();
+ u64 l1_to_l2_ns, l2_to_l1_ns, l2_runtime_ns;
+
+ if (!lp->l2_accumul_cntrs_enable)
+ return;
+
+ l1_to_l2_ns = tb_to_ns(be64_to_cpu(lp->l1_to_l2_cs_tb));
+ l2_to_l1_ns = tb_to_ns(be64_to_cpu(lp->l2_to_l1_cs_tb));
+ l2_runtime_ns = tb_to_ns(be64_to_cpu(lp->l2_runtime_tb));
+ trace_kvmppc_vcpu_exit_cs_time(vcpu, l1_to_l2_ns, l2_to_l1_ns,
+ l2_runtime_ns);
+ lp->l1_to_l2_cs_tb = 0;
+ lp->l2_to_l1_cs_tb = 0;
+ lp->l2_runtime_tb = 0;
+ lp->l2_accumul_cntrs_enable = 0;
+
+ // Maintain an aggregate of context switch times
+ vcpu->arch.l1_to_l2_cs_agg += l1_to_l2_ns;
+ vcpu->arch.l2_to_l1_cs_agg += l2_to_l1_ns;
+ vcpu->arch.l2_runtime_agg += l2_runtime_ns;
+}
+
static int kvmhv_vcpu_entry_nestedv2(struct kvm_vcpu *vcpu, u64 time_limit,
unsigned long lpcr, u64 *tb)
{
@@ -4130,6 +4154,11 @@ static int kvmhv_vcpu_entry_nestedv2(struct kvm_vcpu
*vcpu, u64 time_limit,
kvmppc_gse_put_u64(io->vcpu_run_input, KVMPPC_GSID_LPCR, lpcr);
accumulate_time(vcpu, >arch.in_guest);
+
+ /* Enable the guest host context switch time tracking */
+ if (unlikely(trace_kvmppc_vcpu_exit_cs_time_enabled()))
+ get_lppaca()->l2_accumul_cntrs_enable = 1;
+
rc = plpar_guest_run_vcpu(0,
Re: [PATCH] powerpc: ps3: mark ps3_notification_device static for stack usage
On 3/21/24 17:32, Geert Uytterhoeven wrote:
> --- a/arch/powerpc/platforms/ps3/device-init.c
>> +++ b/arch/powerpc/platforms/ps3/device-init.c
>> @@ -770,7 +770,7 @@ static struct task_struct *probe_task;
>>
>> static int ps3_probe_thread(void *data)
>> {
>> - struct ps3_notification_device dev;
>> + static struct ps3_notification_device dev;
>> int res;
>> unsigned int irq;
>> u64 lpar;
>
> Making it static increases kernel size for everyone. So I'd rather
> allocate it dynamically. The thread already allocates a buffer, which
> can be replaced at no cost by allocating a structure containing both
> the ps3_notification_device and the buffer.
Here's what I came up with. It builds for me without warnings.
I haven't tested it yet. A review would be appreciated.
diff --git a/arch/powerpc/platforms/ps3/device-init.c
b/arch/powerpc/platforms/ps3/device-init.c
index 878bc160246e..9bb44a6ccdaf 100644
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -770,37 +770,48 @@ static struct task_struct *probe_task;
static int ps3_probe_thread(void *data)
{
- struct ps3_notification_device dev;
+ struct ps3_probe_thread_local {
+ struct ps3_notification_device dev;
+ union {
+ char buf[512];
+ struct ps3_notify_cmd notify_cmd;
+ struct ps3_notify_event notify_event;
+ };
+ };
+ struct ps3_probe_thread_local *local;
+ struct ps3_notification_device *dev;
+ struct ps3_notify_cmd *notify_cmd;
+ struct ps3_notify_event *notify_event;
int res;
unsigned int irq;
u64 lpar;
- void *buf;
- struct ps3_notify_cmd *notify_cmd;
- struct ps3_notify_event *notify_event;
pr_debug(" -> %s:%u: kthread started\n", __func__, __LINE__);
- buf = kzalloc(512, GFP_KERNEL);
- if (!buf)
+ local = kzalloc(sizeof(local), GFP_KERNEL);
+
+ if (!local)
return -ENOMEM;
- lpar = ps3_mm_phys_to_lpar(__pa(buf));
- notify_cmd = buf;
- notify_event = buf;
+ dev = >dev;
+ notify_cmd = >notify_cmd;
+ notify_event = >notify_event;
+
+ lpar = ps3_mm_phys_to_lpar(__pa(>notify_cmd));
/* dummy system bus device */
- dev.sbd.bus_id = (u64)data;
- dev.sbd.dev_id = PS3_NOTIFICATION_DEV_ID;
- dev.sbd.interrupt_id = PS3_NOTIFICATION_INTERRUPT_ID;
+ dev->sbd.bus_id = (u64)data;
+ dev->sbd.dev_id = PS3_NOTIFICATION_DEV_ID;
+ dev->sbd.interrupt_id = PS3_NOTIFICATION_INTERRUPT_ID;
- res = lv1_open_device(dev.sbd.bus_id, dev.sbd.dev_id, 0);
+ res = lv1_open_device(dev->sbd.bus_id, dev->sbd.dev_id, 0);
if (res) {
pr_err("%s:%u: lv1_open_device failed %s\n", __func__,
__LINE__, ps3_result(res));
goto fail_free;
}
- res = ps3_sb_event_receive_port_setup(, PS3_BINDING_CPU_ANY,
+ res = ps3_sb_event_receive_port_setup(>sbd, PS3_BINDING_CPU_ANY,
);
if (res) {
pr_err("%s:%u: ps3_sb_event_receive_port_setup failed %d\n",
@@ -808,11 +819,11 @@ static int ps3_probe_thread(void *data)
goto fail_close_device;
}
- spin_lock_init();
- rcuwait_init();
+ spin_lock_init(>lock);
+ rcuwait_init(>wait);
res = request_irq(irq, ps3_notification_interrupt, 0,
- "ps3_notification", );
+ "ps3_notification", >dev);
if (res) {
pr_err("%s:%u: request_irq failed %d\n", __func__, __LINE__,
res);
@@ -823,7 +834,7 @@ static int ps3_probe_thread(void *data)
notify_cmd->operation_code = 0; /* must be zero */
notify_cmd->event_mask = 1UL << notify_region_probe;
- res = ps3_notification_read_write(, lpar, 1);
+ res = ps3_notification_read_write(>dev, lpar, 1);
if (res)
goto fail_free_irq;
@@ -834,36 +845,36 @@ static int ps3_probe_thread(void *data)
memset(notify_event, 0, sizeof(*notify_event));
- res = ps3_notification_read_write(, lpar, 0);
+ res = ps3_notification_read_write(>dev, lpar, 0);
if (res)
break;
pr_debug("%s:%u: notify event type 0x%llx bus id %llu dev id
%llu"
" type %llu port %llu\n", __func__, __LINE__,
-notify_event->event_type, notify_event->bus_id,
-notify_event->dev_id, notify_event->dev_type,
-notify_event->dev_port);
+ notify_event->event_type, notify_event->bus_id,
+ notify_event->dev_id, notify_event->dev_type,
+
[PATCH v2 5/5] dt-bindings: hwmon: ibm,p8-occ-hwmon: move to trivial devices
This binding meets the requirements to be converted to dtschema
via trivial-devices.yaml.
Reviewed-by: Rob Herring
Signed-off-by: Javier Carrasco
---
.../devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt | 25 --
.../devicetree/bindings/trivial-devices.yaml | 2 ++
2 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt
b/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt
deleted file mode 100644
index 5dc5d2e2573d..
--- a/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Device-tree bindings for I2C-based On-Chip Controller hwmon device
---
-
-Required properties:
- - compatible = "ibm,p8-occ-hwmon";
- - reg = ;: I2C bus address
-
-Examples:
-
-i2c-bus@100 {
-#address-cells = <1>;
-#size-cells = <0>;
-clock-frequency = <10>;
-< more properties >
-
-occ-hwmon@1 {
-compatible = "ibm,p8-occ-hwmon";
-reg = <0x50>;
-};
-
-occ-hwmon@2 {
-compatible = "ibm,p8-occ-hwmon";
-reg = <0x51>;
-};
-};
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml
b/Documentation/devicetree/bindings/trivial-devices.yaml
index e07be7bf8395..87b0dd9b0734 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -126,6 +126,8 @@ properties:
- ibm,cffps1
# IBM Common Form Factor Power Supply Versions 2
- ibm,cffps2
+# IBM On-Chip Controller hwmon device
+ - ibm,p8-occ-hwmon
# Infineon barometric pressure and temperature sensor
- infineon,dps310
# Infineon IR36021 digital POL buck controller
--
2.40.1
[PATCH v2 4/5] dt-bindings: hwmon: stts751: convert to dtschema
Convert existing binding to support validation.
This is a straightforward conversion with no new properties.
Signed-off-by: Javier Carrasco
---
.../devicetree/bindings/hwmon/st,stts751.yaml | 41 ++
.../devicetree/bindings/hwmon/stts751.txt | 15
2 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/st,stts751.yaml
b/Documentation/devicetree/bindings/hwmon/st,stts751.yaml
new file mode 100644
index ..9c825adbed58
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/st,stts751.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/st,stts751.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STTS751 Thermometer
+
+maintainers:
+ - Javier Carrasco
+
+properties:
+ compatible:
+const: st,stts751
+
+ reg:
+maxItems: 1
+
+ smbus-timeout-disable:
+description:
+ When set, the smbus timeout function will be disabled.
+$ref: /schemas/types.yaml#/definitions/flag
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+thermometer@48 {
+compatible = "st,stts751";
+reg = <0x48>;
+smbus-timeout-disable;
+};
+};
diff --git a/Documentation/devicetree/bindings/hwmon/stts751.txt
b/Documentation/devicetree/bindings/hwmon/stts751.txt
deleted file mode 100644
index 3ee1dc30e72f..
--- a/Documentation/devicetree/bindings/hwmon/stts751.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* STTS751 thermometer.
-
-Required node properties:
-- compatible: "stts751"
-- reg: I2C bus address of the device
-
-Optional properties:
-- smbus-timeout-disable: when set, the smbus timeout function will be disabled
-
-Example stts751 node:
-
-temp-sensor {
- compatible = "stts751";
- reg = <0x48>;
-}
--
2.40.1
[PATCH v2 3/5] dt-bindings: hwmon: pwm-fan: drop text file
This binding was converted to dtschema a year ago. Acked-by: Rob Herring Signed-off-by: Javier Carrasco --- Documentation/devicetree/bindings/hwmon/pwm-fan.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt deleted file mode 100644 index 48886f0ce415.. --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt +++ /dev/null @@ -1 +0,0 @@ -This file has moved to pwm-fan.yaml. -- 2.40.1
[PATCH v2 2/5] dt-bindings: hwmon: ibmpowernv: convert to dtschema
Convert existing binding to support validation.
This is a straightforward conversion with now new properties.
Signed-off-by: Javier Carrasco
---
.../devicetree/bindings/hwmon/ibm,powernv.yaml | 37 ++
.../devicetree/bindings/hwmon/ibmpowernv.txt | 23 --
2 files changed, 37 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/ibm,powernv.yaml
b/Documentation/devicetree/bindings/hwmon/ibm,powernv.yaml
new file mode 100644
index ..b26d42bce938
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ibm,powernv.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ibm,powernv.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM POWERNV platform sensors
+
+maintainers:
+ - Javier Carrasco
+
+properties:
+ compatible:
+enum:
+ - ibm,opal-sensor-cooling-fan
+ - ibm,opal-sensor-amb-temp
+ - ibm,opal-sensor-power-supply
+ - ibm,opal-sensor-power
+
+ sensor-id:
+description:
+ An opaque id provided by the firmware to the kernel, identifies a
+ given sensor and its attribute data.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - sensor-id
+
+additionalProperties: false
+
+examples:
+ - |
+sensor {
+compatible = "ibm,opal-sensor-cooling-fan";
+sensor-id = <0x7052107>;
+};
diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
deleted file mode 100644
index f93242be60a1..
--- a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-IBM POWERNV platform sensors
-
-
-Required node properties:
-- compatible: must be one of
- "ibm,opal-sensor-cooling-fan"
- "ibm,opal-sensor-amb-temp"
- "ibm,opal-sensor-power-supply"
- "ibm,opal-sensor-power"
-- sensor-id: an opaque id provided by the firmware to the kernel, identifies a
-given sensor and its attribute data
-
-Example sensors node:
-
-cooling-fan#8-data {
- sensor-id = <0x7052107>;
- compatible = "ibm,opal-sensor-cooling-fan";
-};
-
-amb-temp#1-thrs {
- sensor-id = <0x5096000>;
- compatible = "ibm,opal-sensor-amb-temp";
-};
--
2.40.1
[PATCH v2 0/5] dt-bindings: hwmon: convert multiple devices to dtschema
This series converts the following existing bindings to dtschema: - as370 - ibmpowernv - stts751 - ibm,p8-occ-hwmon (moved to trivial-devices.yaml) Additionally, pwm-fan.txt has been dropped because it was converted a year ago, and it is not mentioned anywhere in the tree. I could not find the rationale, but its current state does not seem to provide any valuable information. The binding of the as370 looks very simple, but given that the reg property is not a single address, I have written a dedicated file for it. If reg = is valid in trivial-devices.yaml, I have nothing against moving this device as well. Signed-off-by: Javier Carrasco --- Changes in v2: - ibmpowernv: fix compatible string in the example. - Link to v1: https://lore.kernel.org/r/20240321-hwmon_dtschema-v1-0-96c3810c3...@gmail.com --- Javier Carrasco (5): dt-bindings: hwmon: as370: convert to dtschema dt-bindings: hwmon: ibmpowernv: convert to dtschema dt-bindings: hwmon: pwm-fan: drop text file dt-bindings: hwmon: stts751: convert to dtschema dt-bindings: hwmon: ibm,p8-occ-hwmon: move to trivial devices Documentation/devicetree/bindings/hwmon/as370.txt | 11 -- .../devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt | 25 - .../devicetree/bindings/hwmon/ibm,powernv.yaml | 37 +++ .../devicetree/bindings/hwmon/ibmpowernv.txt | 23 .../devicetree/bindings/hwmon/pwm-fan.txt | 1 - .../devicetree/bindings/hwmon/st,stts751.yaml | 41 ++ .../devicetree/bindings/hwmon/stts751.txt | 15 .../devicetree/bindings/hwmon/syna,as370.yaml | 32 + .../devicetree/bindings/trivial-devices.yaml | 2 ++ 9 files changed, 112 insertions(+), 75 deletions(-) --- base-commit: ebc9bee8814d12ec247de117aa2f7fd39ff11127 change-id: 20240320-hwmon_dtschema-7f58f49118aa Best regards, -- Javier Carrasco
[PATCH v2 1/5] dt-bindings: hwmon: as370: convert to dtschema
Convert existing binding to support validation.
This is a straightforward conversion with now new properties.
Reviewed-by: Rob Herring
Signed-off-by: Javier Carrasco
---
Documentation/devicetree/bindings/hwmon/as370.txt | 11
.../devicetree/bindings/hwmon/syna,as370.yaml | 32 ++
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/as370.txt
b/Documentation/devicetree/bindings/hwmon/as370.txt
deleted file mode 100644
index d102fe765124..
--- a/Documentation/devicetree/bindings/hwmon/as370.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-Bindings for Synaptics AS370 PVT sensors
-
-Required properties:
-- compatible : "syna,as370-hwmon"
-- reg: address and length of the register set.
-
-Example:
- hwmon@ea0810 {
- compatible = "syna,as370-hwmon";
- reg = <0xea0810 0xc>;
- };
diff --git a/Documentation/devicetree/bindings/hwmon/syna,as370.yaml
b/Documentation/devicetree/bindings/hwmon/syna,as370.yaml
new file mode 100644
index ..1f7005f55247
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/syna,as370.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/syna,as370.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics AS370 PVT sensors
+
+maintainers:
+ - Javier Carrasco
+
+properties:
+ compatible:
+const: syna,as370-hwmon
+
+ reg:
+description:
+ Address and length of the register set.
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+sensor@ea0810 {
+compatible = "syna,as370-hwmon";
+reg = <0xea0810 0xc>;
+};
--
2.40.1
