Re: [PATCH v5 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks
On Mon, 2023-10-09 at 17:04 +0200, David Hildenbrand wrote:
> On 07.10.23 10:55, Huang, Ying wrote:
> > Vishal Verma writes:
> >
> > > @@ -2167,47 +2221,28 @@ static int __ref try_remove_memory(u64 start, u64
> > > size)
> > > if (rc)
> > > return rc;
> > >
> > > + mem_hotplug_begin();
> > > +
> > > /*
> > > - * We only support removing memory added with
> > > MHP_MEMMAP_ON_MEMORY in
> > > - * the same granularity it was added - a single memory block.
> > > + * For memmap_on_memory, the altmaps could have been added on
> > > + * a per-memblock basis. Loop through the entire range if so,
> > > + * and remove each memblock and its altmap.
> > > */
> > > if (mhp_memmap_on_memory()) {
> >
> > IIUC, even if mhp_memmap_on_memory() returns true, it's still possible
> > that the memmap is put in DRAM after [2/2]. So that,
> > arch_remove_memory() are called for each memory block unnecessarily. Can
> > we detect this (via altmap?) and call remove_memory_block_and_altmap()
> > for the whole range?
>
> Good point. We should handle memblock-per-memblock onny if we have to
> handle the altmap. Otherwise, just call a separate function that doesn't
> care about -- e.g., called remove_memory_blocks_no_altmap().
>
> We could simply walk all memory blocks and make sure either all have an
> altmap or none has an altmap. If there is a mix, we should bail out with
> WARN_ON_ONCE().
>
Ok I think I follow - based on both of these threads, here's my
understanding in an incremental diff from the original patches (may not
apply directly as I've already committed changes from the other bits of
feedback - but this should provide an idea of the direction) -
---
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 507291e44c0b..30addcb063b4 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -2201,6 +2201,40 @@ static void __ref remove_memory_block_and_altmap(u64
start, u64 size)
}
}
+static bool memblocks_have_altmaps(u64 start, u64 size)
+{
+ unsigned long memblock_size = memory_block_size_bytes();
+ u64 num_altmaps = 0, num_no_altmaps = 0;
+ struct memory_block *mem;
+ u64 cur_start;
+ int rc = 0;
+
+ if (!mhp_memmap_on_memory())
+ return false;
+
+ for (cur_start = start; cur_start < start + size;
+cur_start += memblock_size) {
+ if (walk_memory_blocks(cur_start, memblock_size, ,
+ test_has_altmap_cb))
+ num_altmaps++;
+ else
+ num_no_altmaps++;
+ }
+
+ if (!num_altmaps && num_no_altmaps > 0)
+ return false;
+
+ if (!num_no_altmaps && num_altmaps > 0)
+ return true;
+
+ /*
+* If there is a mix of memblocks with and without altmaps,
+* something has gone very wrong. WARN and bail.
+*/
+ WARN_ONCE(1, "memblocks have a mix of missing and present altmaps");
+ return false;
+}
+
static int __ref try_remove_memory(u64 start, u64 size)
{
int rc, nid = NUMA_NO_NODE;
@@ -2230,7 +2264,7 @@ static int __ref try_remove_memory(u64 start, u64 size)
* a per-memblock basis. Loop through the entire range if so,
* and remove each memblock and its altmap.
*/
- if (mhp_memmap_on_memory()) {
+ if (mhp_memmap_on_memory() && memblocks_have_altmaps(start, size)) {
unsigned long memblock_size = memory_block_size_bytes();
u64 cur_start;
@@ -2239,7 +2273,8 @@ static int __ref try_remove_memory(u64 start, u64 size)
remove_memory_block_and_altmap(cur_start,
memblock_size);
} else {
- remove_memory_block_and_altmap(start, size);
+ remove_memory_block_devices(start, size);
+ arch_remove_memory(start, size, NULL);
}
if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) {
[PATCH v4] module: Add CONFIG_MODULE_DISABLE_INIT_FREE option
To facilitate syzkaller test, it's essential for the module to retain the same address across reboots. In userspace, the execution of modprobe commands must occur sequentially. In the kernel, selecting the CONFIG_MODULE_DISABLE_INIT_FREE option disables the asynchronous freeing of init sections. Signed-off-by: Joey Jiao --- kernel/module/Kconfig | 12 kernel/module/main.c | 3 ++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig index 33a2e991f608..88206bc4c7d4 100644 --- a/kernel/module/Kconfig +++ b/kernel/module/Kconfig @@ -389,4 +389,16 @@ config MODULES_TREE_LOOKUP def_bool y depends on PERF_EVENTS || TRACING || CFI_CLANG +config MODULE_DISABLE_INIT_FREE + bool "Disable freeing of init sections" + default n + help + By default, kernel will free init sections after module being fully + loaded. + + MODULE_DISABLE_INIT_FREE allows users to prevent the freeing of init + sections. This option is particularly helpful for syzkaller fuzzing, + ensuring that the module consistently loads into the same address + across reboots. + endif # MODULES diff --git a/kernel/module/main.c b/kernel/module/main.c index 98fedfdb8db5..0f242b7b29fe 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -2593,7 +2593,8 @@ static noinline int do_init_module(struct module *mod) * be cleaned up needs to sync with the queued work - ie * rcu_barrier() */ - if (llist_add(>node, _free_list)) + if (llist_add(>node, _free_list) && + !IS_ENABLED(CONFIG_MODULE_DISABLE_INIT_FREE)) schedule_work(_free_wq); mutex_unlock(_mutex); -- 2.42.0
Re: [PATCH RFC 17/37] arm64: mte: Disable dynamic tag storage management if HW KASAN is enabled
On Wed, Aug 23, 2023 at 02:13:30PM +0100, Alexandru Elisei wrote:
> Reserving the tag storage associated with a tagged page requires the
> ability to migrate existing data if the tag storage is in use for data.
>
> The kernel allocates pages, which are now tagged because of HW KASAN, in
> non-preemptible contexts, which can make reserving the associate tag
> storage impossible.
>
> Don't expose the tag storage pages to the memory allocator if HW KASAN is
> enabled.
>
> Signed-off-by: Alexandru Elisei
> ---
> arch/arm64/kernel/mte_tag_storage.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/kernel/mte_tag_storage.c
> b/arch/arm64/kernel/mte_tag_storage.c
> index 4a6bfdf88458..f45128d0244e 100644
> --- a/arch/arm64/kernel/mte_tag_storage.c
> +++ b/arch/arm64/kernel/mte_tag_storage.c
> @@ -314,6 +314,18 @@ static int __init mte_tag_storage_activate_regions(void)
> return 0;
> }
>
> + /*
> + * The kernel allocates memory in non-preemptible contexts, which makes
> + * migration impossible when reserving the associated tag storage.
> + *
> + * The check is safe to make because KASAN HW tags are enabled before
> + * the rest of the init functions are called, in smp_prepare_boot_cpu().
> + */
> + if (kasan_hw_tags_enabled()) {
> + pr_info("KASAN HW tags enabled, disabling tag storage");
> + return 0;
> + }
> +
Hi.
Is there no plan to enable HW KASAN in the current design ?
I wonder if dynamic MTE is only used for user ?
Thanks,
Hyesoo Yu.
> for (i = 0; i < num_tag_regions; i++) {
> tag_range = _regions[i].tag_range;
> for (pfn = tag_range->start; pfn <= tag_range->end; pfn +=
> pageblock_nr_pages) {
> --
> 2.41.0
>
>
[PATCH v3] module: Add CONFIG_MODULE_DISABLE_INIT_FREE option
To facilitate syzkaller test, it's essential for the module to retain the same address across reboots. In userspace, the execution of modprobe commands must occur sequentially. In the kernel, selecting the CONFIG_MODULE_DISABLE_INIT_FREE option disables the asynchronous freeing of init sections. Signed-off-by: Joey Jiao --- kernel/module/Kconfig | 8 kernel/module/main.c | 5 +++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig index 33a2e991f608..1cdbee4c51de 100644 --- a/kernel/module/Kconfig +++ b/kernel/module/Kconfig @@ -389,4 +389,12 @@ config MODULES_TREE_LOOKUP def_bool y depends on PERF_EVENTS || TRACING || CFI_CLANG +config MODULE_DISABLE_INIT_FREE + bool "Disable freeing of init sections" + default n + help + Allows users to prevent the freeing of init sections. This option is + particularly helpful for syzkaller fuzzing, ensuring that the module + consistently loads into the same address across reboots. + endif # MODULES diff --git a/kernel/module/main.c b/kernel/module/main.c index 98fedfdb8db5..a5210b90c078 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -2593,8 +2593,9 @@ static noinline int do_init_module(struct module *mod) * be cleaned up needs to sync with the queued work - ie * rcu_barrier() */ - if (llist_add(>node, _free_list)) - schedule_work(_free_wq); + if (llist_add(>node, _free_list) && + !IS_ENABLED(CONFIG_MODULE_DISABLE_INIT_FREE)) + schedule_work(_free_wq); mutex_unlock(_mutex); wake_up_all(_wq); -- 2.42.0
Re: [PATCH RFC 04/37] mm: Add MIGRATE_METADATA allocation policy
On Wed, Aug 23, 2023 at 02:13:17PM +0100, Alexandru Elisei wrote:
> Some architectures implement hardware memory coloring to catch incorrect
> usage of memory allocation. One such architecture is arm64, which calls its
> hardware implementation Memory Tagging Extension.
>
> So far, the memory which stores the metadata has been configured by
> firmware and hidden from Linux. For arm64, it is impossible to to have the
> entire system RAM allocated with metadata because executable memory cannot
> be tagged. Furthermore, in practice, only a chunk of all the memory that
> can have tags is actually used as tagged. which leaves a portion of
> metadata memory unused. As such, it would be beneficial to use this memory,
> which so far has been unaccessible to Linux, to service allocation
> requests. To prepare for exposing this metadata memory a new migratetype is
> being added to the page allocator, called MIGRATE_METADATA.
>
> One important aspect is that for arm64 the memory that stores metadata
> cannot have metadata associated with it, it can only be used to store
> metadata for other pages. This means that the page allocator will *not*
> allocate from this migratetype if at least one of the following is true:
>
> - The allocation also needs metadata to be allocated.
> - The allocation isn't movable. A metadata page storing data must be
> able to be migrated at any given time so it can be repurposed to store
> metadata.
>
> Both cases are specific to arm64's implementation of memory metadata.
>
> For now, metadata storage pages management is disabled, and it will be
> enabled once the architecture-specific handling is added.
>
> Signed-off-by: Alexandru Elisei
> ---
> arch/arm64/include/asm/memory_metadata.h | 21 ++
> arch/arm64/mm/fault.c| 3 +++
> include/asm-generic/Kbuild | 1 +
> include/asm-generic/memory_metadata.h| 18 +++
> include/linux/mmzone.h | 11 ++
> mm/Kconfig | 3 +++
> mm/internal.h| 5 +
> mm/page_alloc.c | 28
> 8 files changed, 90 insertions(+)
> create mode 100644 arch/arm64/include/asm/memory_metadata.h
> create mode 100644 include/asm-generic/memory_metadata.h
>
> diff --git a/arch/arm64/include/asm/memory_metadata.h
> b/arch/arm64/include/asm/memory_metadata.h
> new file mode 100644
> index ..5269be7f455f
> --- /dev/null
> +++ b/arch/arm64/include/asm/memory_metadata.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2023 ARM Ltd.
> + */
> +#ifndef __ASM_MEMORY_METADATA_H
> +#define __ASM_MEMORY_METADATA_H
> +
> +#include
> +
> +#ifdef CONFIG_MEMORY_METADATA
> +static inline bool metadata_storage_enabled(void)
> +{
> + return false;
> +}
> +static inline bool alloc_can_use_metadata_pages(gfp_t gfp_mask)
> +{
> + return false;
> +}
> +#endif /* CONFIG_MEMORY_METADATA */
> +
> +#endif /* __ASM_MEMORY_METADATA_H */
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 0ca89ebcdc63..1ca421c11ebc 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -956,6 +957,8 @@ struct folio *vma_alloc_zeroed_movable_folio(struct
> vm_area_struct *vma,
>
> void tag_clear_highpage(struct page *page)
> {
> + /* Tag storage pages cannot be tagged. */
> + WARN_ON_ONCE(is_migrate_metadata_page(page));
> /* Newly allocated page, shouldn't have been tagged yet */
> WARN_ON_ONCE(!try_page_mte_tagging(page));
> mte_zero_clear_page_tags(page_address(page));
> diff --git a/include/asm-generic/Kbuild b/include/asm-generic/Kbuild
> index 941be574bbe0..048ecffc430c 100644
> --- a/include/asm-generic/Kbuild
> +++ b/include/asm-generic/Kbuild
> @@ -36,6 +36,7 @@ mandatory-y += kprobes.h
> mandatory-y += linkage.h
> mandatory-y += local.h
> mandatory-y += local64.h
> +mandatory-y += memory_metadata.h
> mandatory-y += mmiowb.h
> mandatory-y += mmu.h
> mandatory-y += mmu_context.h
> diff --git a/include/asm-generic/memory_metadata.h
> b/include/asm-generic/memory_metadata.h
> new file mode 100644
> index ..dc0c84408a8e
> --- /dev/null
> +++ b/include/asm-generic/memory_metadata.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_GENERIC_MEMORY_METADATA_H
> +#define __ASM_GENERIC_MEMORY_METADATA_H
> +
> +#include
> +
> +#ifndef CONFIG_MEMORY_METADATA
> +static inline bool metadata_storage_enabled(void)
> +{
> + return false;
> +}
> +static inline bool alloc_can_use_metadata_pages(gfp_t gfp_mask)
> +{
> + return false;
> +}
> +#endif /* !CONFIG_MEMORY_METADATA */
> +
> +#endif /* __ASM_GENERIC_MEMORY_METADATA_H */
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 5e50b78d58ea..74925806687e 100644
Re: [PATCH RFC 06/37] mm: page_alloc: Allocate from movable pcp lists only if ALLOC_FROM_METADATA
On Wed, Aug 23, 2023 at 02:13:19PM +0100, Alexandru Elisei wrote:
> pcp lists keep MIGRATE_METADATA pages on the MIGRATE_MOVABLE list. Make
> sure pages from the movable list are allocated only when the
> ALLOC_FROM_METADATA alloc flag is set, as otherwise the page allocator
> could end up allocating a metadata page when that page cannot be used.
>
> __alloc_pages_bulk() sidesteps rmqueue() and calls __rmqueue_pcplist()
> directly. Add a check for the flag before calling __rmqueue_pcplist(), and
> fallback to __alloc_pages() if the check is false.
>
> Note that CMA isn't a problem for __alloc_pages_bulk(): an allocation can
> always use CMA pages if the requested migratetype is MIGRATE_MOVABLE, which
> is not the case with MIGRATE_METADATA pages.
>
> Signed-off-by: Alexandru Elisei
> ---
> mm/page_alloc.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 829134a4dfa8..a693e23c4733 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2845,11 +2845,16 @@ struct page *rmqueue(struct zone *preferred_zone,
>
> if (likely(pcp_allowed_order(order))) {
> /*
> - * MIGRATE_MOVABLE pcplist could have the pages on CMA area and
> - * we need to skip it when CMA area isn't allowed.
> + * PCP lists keep MIGRATE_CMA/MIGRATE_METADATA pages on the same
> + * movable list. Make sure it's allowed to allocate both type of
> + * pages before allocating from the movable list.
>*/
> - if (!IS_ENABLED(CONFIG_CMA) || alloc_flags & ALLOC_CMA ||
> - migratetype != MIGRATE_MOVABLE) {
> + bool movable_allowed = (!IS_ENABLED(CONFIG_CMA) ||
> + (alloc_flags & ALLOC_CMA)) &&
> +(!IS_ENABLED(CONFIG_MEMORY_METADATA) ||
> + (alloc_flags & ALLOC_FROM_METADATA));
> +
> + if (migratetype != MIGRATE_MOVABLE || movable_allowed) {
Hi!
I don't think it would be effcient when the majority of movable pages
do not use GFP_TAGGED.
Metadata pages have a low probability of being in the pcp list
because metadata pages is bypassed when freeing pages.
The allocation performance of most movable pages is likely to decrease
if only the request with ALLOC_FROM_METADATA could be allocated.
How about not including metadata pages in the pcp list at all ?
Thanks,
Hyesoo Yu.
> page = rmqueue_pcplist(preferred_zone, zone, order,
> migratetype, alloc_flags);
> if (likely(page))
> @@ -4388,6 +4393,14 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int
> preferred_nid,
> goto out;
> gfp = alloc_gfp;
>
> + /*
> + * pcp lists puts MIGRATE_METADATA on the MIGRATE_MOVABLE list, don't
> + * use pcp if allocating metadata pages is not allowed.
> + */
> + if (metadata_storage_enabled() && ac.migratetype == MIGRATE_MOVABLE &&
> + !(alloc_flags & ALLOC_FROM_METADATA))
> + goto failed;
> +
> /* Find an allowed local zone that meets the low watermark. */
> for_each_zone_zonelist_nodemask(zone, z, ac.zonelist,
> ac.highest_zoneidx, ac.nodemask) {
> unsigned long mark;
> --
> 2.41.0
>
>
Re: [PATCH 1/3] dt-bindings: watchdog: qcom-wdt: Add MSM8226 and MSM8974 compatibles
On Wed, Oct 11, 2023 at 06:33:13PM +0200, Luca Weiss wrote: > From: Matti Lehtimäki > > Add compatibles for the MSM8226 and MSM8974 platforms to the Qualcomm > watchdog binding. > > Signed-off-by: Matti Lehtimäki > Signed-off-by: Luca Weiss Reviewed-by: Guenter Roeck > --- > Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml > b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml > index 5046dfa55f13..c12bc852aedc 100644 > --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml > +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml > @@ -21,6 +21,8 @@ properties: >- qcom,apss-wdt-ipq5018 >- qcom,apss-wdt-ipq5332 >- qcom,apss-wdt-ipq9574 > + - qcom,apss-wdt-msm8226 > + - qcom,apss-wdt-msm8974 >- qcom,apss-wdt-msm8994 >- qcom,apss-wdt-qcm2290 >- qcom,apss-wdt-qcs404 > > -- > 2.42.0 >
Re: [PATCH 4/5] kbuild: unify vdso_install rules
On Mon 09 Oct 2023 21:42:09 GMT, Masahiro Yamada wrote:
> Currently, there is no standard implementation for vdso_install,
> leading to various issues:
>
> 1. Code duplication
>
> Many architectures duplicate similar code just for copying files
> to the install destination.
>
> Some architectures (arm, sparc, x86) create build-id symlinks,
> introducing more code duplication.
>
> 2. Accidental updates of in-tree build artifacts
>
> The vdso_install rule depends on the vdso files to install.
> It may update in-tree build artifacts. This can be problematic,
> as explained in commit 19514fc665ff ("arm, kbuild: make
> "make install" not depend on vmlinux").
>
> 3. Broken code in some architectures
>
> Makefile code is often copied from one architecture to another
> without proper adaptation or testing.
>
> The previous commits removed broken code from csky, UML, and parisc.
>
> Another issue is that 'make vdso_install' for ARCH=s390 installs
> vdso64, but not vdso32.
>
> To address these problems, this commit introduces the generic vdso_install.
>
> Architectures that support vdso_install need to define vdso-install-y
> in arch/*/Makefile.
>
> vdso-install-y lists the files to install. For example, arch/x86/Makefile
> looks like this:
>
> vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg
> vdso-install-$(CONFIG_X86_X32_ABI) +=
> arch/x86/entry/vdso/vdsox32.so.dbg
> vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg
> vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
>
> These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
> if exists, stripped away.
>
> vdso-install-y can optionally take the second field after the colon
> separator. This is needed because some architectures install vdso
> files as a different base name.
>
> The following is a snippet from arch/arm64/Makefile.
>
> vdso-install-$(CONFIG_COMPAT_VDSO) +=
> arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
>
> This will rename vdso.so.dbg to vdso32.so during installation. If such
> architectures change their implementation so that the file names match,
> this workaround will go away.
>
> Signed-off-by: Masahiro Yamada
> ---
Thanks for cleaning this up!
Reviewed-by: Nicolas Schier
Re: [PATCH v2] module: Add CONFIG_MODULE_LOAD_IN_SEQUENCE option
On Wed, Oct 11, 2023 at 01:14:38PM +0530, Joey Jiao wrote:
> When modprobe cmds are executed one by one, the final loaded modules
> are not in fixed sequence as expected.
>
> Add the option to make sure modules are in fixed sequence across reboot.
>
> Signed-off-by: Joey Jiao
> ---
> kernel/module/Kconfig | 11 +++
> kernel/module/main.c | 3 ++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> index 33a2e991f608..b45a45f31d6d 100644
> --- a/kernel/module/Kconfig
> +++ b/kernel/module/Kconfig
> @@ -389,4 +389,15 @@ config MODULES_TREE_LOOKUP
> def_bool y
> depends on PERF_EVENTS || TRACING || CFI_CLANG
>
> +config MODULE_LOAD_IN_SEQUENCE
> + bool "Load module in sequence"
> + default n
> + help
> + By default, modules are loaded in random sequence depending on when
> modprobe
> + is executed.
> +
> + This option allows modules to be loaded in sequence if modprobe cmds
> are
> + executed one by one in sequence. This option is helpful during
> syzkaller fuzzing
> + to make sure module is loaded into fixed address across device reboot.
> +
> endif # MODULES
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 98fedfdb8db5..e238a31d09eb 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -2594,7 +2594,8 @@ static noinline int do_init_module(struct module *mod)
>* rcu_barrier()
>*/
> if (llist_add(>node, _free_list))
> - schedule_work(_free_wq);
> + if (!IS_ENABLED(CONFIG_MODULE_LOAD_IN_SEQUENCE)) {
> + schedule_work(_free_wq);
>
As Christoph suggested the rationale for something like this needs to be
clearly spelled out in the commit log and if so valuable it should be
a default. The commit log and even the Kconfig description do little
to justify any rationale for this.
Luis
Re: [PATCH 3/3] ARM: dts: qcom: msm8974: Add watchdog node
On 10/11/23 18:33, Luca Weiss wrote: From: Matti Lehtimäki Add watchdog for MSM8974 platform. Signed-off-by: Matti Lehtimäki Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/3] ARM: dts: qcom: msm8226: Add watchdog node
On 10/11/23 18:33, Luca Weiss wrote: From: Matti Lehtimäki Add watchdog for MSM8226 platform. Signed-off-by: Matti Lehtimäki Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 1/3] dt-bindings: watchdog: qcom-wdt: Add MSM8226 and MSM8974 compatibles
On 11/10/2023 18:33, Luca Weiss wrote: > From: Matti Lehtimäki > > Add compatibles for the MSM8226 and MSM8974 platforms to the Qualcomm > watchdog binding. > > Signed-off-by: Matti Lehtimäki Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 1/3] dt-bindings: vendor-prefixes: document HTC Corporation
On 10/11/23 20:24, Krzysztof Kozlowski wrote: On 11/10/2023 19:02, Luca Weiss wrote: Add the vendor prefix for HTC (https://www.htc.com/). Signed-off-by: Luca Weiss --- So it is the first HTC device in upstream? That's a surprise... Same feeling, this was very unexpected! Konrad
Re: [PATCH 3/3] ARM: dts: qcom: Add support for HTC One Mini 2
On 10/11/23 19:02, Luca Weiss wrote:
Add support for this smartphone based on the MSM8926 SoC, codenamed
"memul".
Supported functionality:
* Power & volume buttons
* ADSP
* Magnetometer
* Accelerometer
* Touchscreen
* Vibrator
* Internal storage
* SD card
* Charger
* USB
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/Makefile | 1 +
arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts | 337 ++
2 files changed, 338 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/Makefile b/arch/arm/boot/dts/qcom/Makefile
index a3d293e40820..0cb272f4fa45 100644
--- a/arch/arm/boot/dts/qcom/Makefile
+++ b/arch/arm/boot/dts/qcom/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8916-samsung-e7.dtb \
qcom-msm8916-samsung-grandmax.dtb \
qcom-msm8916-samsung-serranove.dtb \
+ qcom-msm8926-htc-memul.dtb \
qcom-msm8926-microsoft-superman-lte.dtb \
qcom-msm8926-microsoft-tesla.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts
b/arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts
new file mode 100644
index ..b848f0cce3b4
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts
@@ -0,0 +1,337 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023, Luca Weiss
+ */
+
+/dts-v1/;
+
+#include "qcom-msm8226.dtsi"
+#include "qcom-pm8226.dtsi"
+
+/delete-node/ _region;
+/delete-node/ _region;
+
+/ {
+ model = "HTC One Mini 2";
+ compatible = "htc,memul", "qcom,msm8926", "qcom,msm8226";
+ chassis-type = "handset";
+
+ aliases {
+ mmc0 = _1; /* SDC1 eMMC slot */
+ mmc1 = _2; /* SDC2 SD card slot */
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ key-power {
+ label = "Power";
+ gpios = < 106 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+
+ key-volume-down {
+ label = "Volume Down";
+ gpios = < 107 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = < 108 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+ };
+
+ reserved-memory {
+ unknown@5b0 {
+ reg = <0x05b0 0x20>;
+ no-map;
+ };
+
+ unknown@7a0 {
+ reg = <0x07a0 0x10>;
+ no-map;
+ };
+
+ mpss_region: mpss@800 {
+ reg = <0x0800 0x4f0>;
+ no-map;
+ };
+
+ unknown@cf0 {
+ reg = <0x0cf0 0x20>;
+ no-map;
+ };
+
+ mba_region: mba@d10 {
+ reg = <0x0d10 0x3a000>;
+ no-map;
+ };
+
+ wcnss_region: wcnss@d20 {
+ reg = <0x0d20 0x65>;
+ no-map;
+ };
+
+ adsp_region: adsp@dc0 {
+ reg = <0x0dc0 0x140>;
+ no-map;
+ };
+
+ venus_region: venus@f50 {
+ reg = <0x0f50 0x50>;
+ no-map;
+ };
+
+ smem_region: smem@fa0 {
+ reg = <0x0fa0 0x10>;
+ no-map;
+ };
+
+ unknown@fc0 {
+ reg = <0x0fc0 0xa0>;
+ no-map;
+ };
+ };
+};
+
+ {
+ status = "okay";
firmware-path?
[...]
+ pm8226_s3: s3 {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <135>;
+ };
Newline between subnodes, please
[...]
+ {
+ qcom,fast-charge-safe-current = <175>;
+ qcom,fast-charge-current-limit = <175>;
+ qcom,fast-charge-safe-voltage = <436>;
+ qcom,fast-charge-high-threshold-voltage = <435>;
+ qcom,auto-recharge-threshold-voltage = <430>;
+ qcom,minimum-input-voltage = <430>;
we had quickcharge in 2013? nice
Konrad
Re: [PATCH 1/3] dt-bindings: vendor-prefixes: document HTC Corporation
On 11/10/2023 19:02, Luca Weiss wrote: > Add the vendor prefix for HTC (https://www.htc.com/). > > Signed-off-by: Luca Weiss > --- So it is the first HTC device in upstream? That's a surprise... Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 2/3] dt-bindings: arm: qcom: Add HTC One Mini 2
On 11/10/2023 19:02, Luca Weiss wrote: > Document the compatible for the MSM8926-based HTC One Mini 2 smartphone. > > Signed-off-by: Luca Weiss Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v1] samples: kprobes: Fixes a typo
On Tue, Oct 10, 2023 at 12:03:56AM +0900, Masami Hiramatsu wrote:
> On Mon, 9 Oct 2023 09:51:03 -0400
> Steven Rostedt wrote:
>
> > On Sat, 7 Oct 2023 21:09:00 +0530
> > Atul Kumar Pant wrote:
> >
> > > On Sat, Sep 23, 2023 at 11:00:46PM +0530, Atul Kumar Pant wrote:
> > > > On Thu, Aug 17, 2023 at 10:38:19PM +0530, Atul Kumar Pant wrote:
> > > > > Fixes typo in a function name.
> > > > >
> > > > > Signed-off-by: Atul Kumar Pant
> > > > > ---
> > > > > samples/kprobes/kretprobe_example.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/samples/kprobes/kretprobe_example.c
> > > > > b/samples/kprobes/kretprobe_example.c
> > > > > index cbf16542d84e..ed79fd3d48fb 100644
> > > > > --- a/samples/kprobes/kretprobe_example.c
> > > > > +++ b/samples/kprobes/kretprobe_example.c
> > > > > @@ -35,7 +35,7 @@ struct my_data {
> > > > > ktime_t entry_stamp;
> > > > > };
> > > > >
> > > > > -/* Here we use the entry_hanlder to timestamp function entry */
> > > > > +/* Here we use the entry_handler to timestamp function entry */
> > > > > static int entry_handler(struct kretprobe_instance *ri, struct
> > > > > pt_regs *regs)
> > > > > {
> > > > > struct my_data *data;
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > > > Hi all, can someone provide comments on this change.
> > >
> > > Hi all, can someone please review this change. It has
> > > been not
> > > reviewed for quite some time.
> >
> > That's because trivial typos in comments are considered very low priority,
> > and are usually only added (if they are ever added) if the maintainer has
> > extra time, which may not be for a while.
>
> Anyway, let me pick this. I found this in my inbox now. :)
Thank you. Sorry for the redundant emails for reviewing the change :)
>
> Thank you,
>
> >
> > -- Steve
>
>
> --
> Masami Hiramatsu (Google)
Re: [PATCH v1] samples: kprobes: Fixes a typo
On Mon, Oct 09, 2023 at 09:51:03AM -0400, Steven Rostedt wrote:
> On Sat, 7 Oct 2023 21:09:00 +0530
> Atul Kumar Pant wrote:
>
> > On Sat, Sep 23, 2023 at 11:00:46PM +0530, Atul Kumar Pant wrote:
> > > On Thu, Aug 17, 2023 at 10:38:19PM +0530, Atul Kumar Pant wrote:
> > > > Fixes typo in a function name.
> > > >
> > > > Signed-off-by: Atul Kumar Pant
> > > > ---
> > > > samples/kprobes/kretprobe_example.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/samples/kprobes/kretprobe_example.c
> > > > b/samples/kprobes/kretprobe_example.c
> > > > index cbf16542d84e..ed79fd3d48fb 100644
> > > > --- a/samples/kprobes/kretprobe_example.c
> > > > +++ b/samples/kprobes/kretprobe_example.c
> > > > @@ -35,7 +35,7 @@ struct my_data {
> > > > ktime_t entry_stamp;
> > > > };
> > > >
> > > > -/* Here we use the entry_hanlder to timestamp function entry */
> > > > +/* Here we use the entry_handler to timestamp function entry */
> > > > static int entry_handler(struct kretprobe_instance *ri, struct pt_regs
> > > > *regs)
> > > > {
> > > > struct my_data *data;
> > > > --
> > > > 2.25.1
> > > >
> > >
> > > Hi all, can someone provide comments on this change.
> >
> > Hi all, can someone please review this change. It has
> > been not
> > reviewed for quite some time.
>
> That's because trivial typos in comments are considered very low priority,
> and are usually only added (if they are ever added) if the maintainer has
> extra time, which may not be for a while.
>
> -- Steve
Thank you Steve for the response. I wasn't aware of this.
[PATCH] iommu/qcom: restore IOMMU state if needed
From: Vladimir Lypak
If the IOMMU has a power domain then some state will be lost in
qcom_iommu_suspend and TZ will reset device if we don't call
qcom_scm_restore_sec_cfg before accessing it again.
Signed-off-by: Vladimir Lypak
[l...@z3ntu.xyz: reword commit message a bit]
Signed-off-by: Luca Weiss
---
This patch is required for MSM8953 GPU IOMMU.
See also downstream sources:
https://git.codelinaro.org/clo/la/kernel/msm-4.9/-/commit/f8464885dafc5b780b85de29d92a08c692d3a4d0
https://git.codelinaro.org/clo/la/kernel/msm-4.9/-/blob/LA.UM.10.6.2.r1-02500-89xx.0/drivers/iommu/arm-smmu.c#L4221-4225
Since the compatibles provided by this driver (qcom,msm-iommu-v*) is
only used on msm8916, msm8939 and msm8953, and both 8916 and 8939 don't
have a power domain on the IOMMU, I also don't expect anything to break
there.
---
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index 97b2122032b2..67abeb02cf53 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -900,8 +900,16 @@ static void qcom_iommu_device_remove(struct
platform_device *pdev)
static int __maybe_unused qcom_iommu_resume(struct device *dev)
{
struct qcom_iommu_dev *qcom_iommu = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_bulk_prepare_enable(CLK_NUM, qcom_iommu->clks);
+ if (ret < 0)
+ return ret;
+
+ if (dev->pm_domain)
+ return qcom_scm_restore_sec_cfg(qcom_iommu->sec_id, 0);
- return clk_bulk_prepare_enable(CLK_NUM, qcom_iommu->clks);
+ return ret;
}
static int __maybe_unused qcom_iommu_suspend(struct device *dev)
---
base-commit: 2933a1156742d8c47550493a77af8e2d81cf3c84
change-id: 20231011-msm8953-iommu-restore-fabc2e31fee7
Best regards,
--
Luca Weiss
Re: [PATCH] remoteproc: st: Use device_get_match_data()
On Mon, Oct 09, 2023 at 04:13:40PM -0500, Rob Herring wrote:
> Use preferred device_get_match_data() instead of of_match_device() to
> get the driver match data. With this, adjust the includes to explicitly
> include the correct headers.
>
> Signed-off-by: Rob Herring
> ---
> drivers/remoteproc/st_remoteproc.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
Applied.
Thanks,
Mathieu
> diff --git a/drivers/remoteproc/st_remoteproc.c
> b/drivers/remoteproc/st_remoteproc.c
> index e3ce01d98b4c..b0638f984842 100644
> --- a/drivers/remoteproc/st_remoteproc.c
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -16,10 +16,9 @@
> #include
> #include
> #include
> -#include
> -#include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -341,7 +340,6 @@ static int st_rproc_parse_dt(struct platform_device *pdev)
> static int st_rproc_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> - const struct of_device_id *match;
> struct st_rproc *ddata;
> struct device_node *np = dev->of_node;
> struct rproc *rproc;
> @@ -349,19 +347,15 @@ static int st_rproc_probe(struct platform_device *pdev)
> int enabled;
> int ret, i;
>
> - match = of_match_device(st_rproc_match, dev);
> - if (!match || !match->data) {
> - dev_err(dev, "No device match found\n");
> - return -ENODEV;
> - }
> -
> rproc = rproc_alloc(dev, np->name, _rproc_ops, NULL, sizeof(*ddata));
> if (!rproc)
> return -ENOMEM;
>
> rproc->has_iommu = false;
> ddata = rproc->priv;
> - ddata->config = (struct st_rproc_config *)match->data;
> + ddata->config = (struct st_rproc_config *)device_get_match_data(dev);
> + if (!ddata->config)
> + goto free_rproc;
>
> platform_set_drvdata(pdev, rproc);
>
> --
> 2.42.0
>
[PATCH 3/3] ARM: dts: qcom: Add support for HTC One Mini 2
Add support for this smartphone based on the MSM8926 SoC, codenamed
"memul".
Supported functionality:
* Power & volume buttons
* ADSP
* Magnetometer
* Accelerometer
* Touchscreen
* Vibrator
* Internal storage
* SD card
* Charger
* USB
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/Makefile | 1 +
arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts | 337 ++
2 files changed, 338 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/Makefile b/arch/arm/boot/dts/qcom/Makefile
index a3d293e40820..0cb272f4fa45 100644
--- a/arch/arm/boot/dts/qcom/Makefile
+++ b/arch/arm/boot/dts/qcom/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8916-samsung-e7.dtb \
qcom-msm8916-samsung-grandmax.dtb \
qcom-msm8916-samsung-serranove.dtb \
+ qcom-msm8926-htc-memul.dtb \
qcom-msm8926-microsoft-superman-lte.dtb \
qcom-msm8926-microsoft-tesla.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts
b/arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts
new file mode 100644
index ..b848f0cce3b4
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts
@@ -0,0 +1,337 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023, Luca Weiss
+ */
+
+/dts-v1/;
+
+#include "qcom-msm8226.dtsi"
+#include "qcom-pm8226.dtsi"
+
+/delete-node/ _region;
+/delete-node/ _region;
+
+/ {
+ model = "HTC One Mini 2";
+ compatible = "htc,memul", "qcom,msm8926", "qcom,msm8226";
+ chassis-type = "handset";
+
+ aliases {
+ mmc0 = _1; /* SDC1 eMMC slot */
+ mmc1 = _2; /* SDC2 SD card slot */
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ key-power {
+ label = "Power";
+ gpios = < 106 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+
+ key-volume-down {
+ label = "Volume Down";
+ gpios = < 107 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = < 108 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <15>;
+ };
+ };
+
+ reserved-memory {
+ unknown@5b0 {
+ reg = <0x05b0 0x20>;
+ no-map;
+ };
+
+ unknown@7a0 {
+ reg = <0x07a0 0x10>;
+ no-map;
+ };
+
+ mpss_region: mpss@800 {
+ reg = <0x0800 0x4f0>;
+ no-map;
+ };
+
+ unknown@cf0 {
+ reg = <0x0cf0 0x20>;
+ no-map;
+ };
+
+ mba_region: mba@d10 {
+ reg = <0x0d10 0x3a000>;
+ no-map;
+ };
+
+ wcnss_region: wcnss@d20 {
+ reg = <0x0d20 0x65>;
+ no-map;
+ };
+
+ adsp_region: adsp@dc0 {
+ reg = <0x0dc0 0x140>;
+ no-map;
+ };
+
+ venus_region: venus@f50 {
+ reg = <0x0f50 0x50>;
+ no-map;
+ };
+
+ smem_region: smem@fa0 {
+ reg = <0x0fa0 0x10>;
+ no-map;
+ };
+
+ unknown@fc0 {
+ reg = <0x0fc0 0xa0>;
+ no-map;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+_i2c2 {
+ status = "okay";
+
+ magnetometer@d {
+ compatible = "asahi-kasei,ak8963";
+ reg = <0x0d>;
+ interrupts-extended = < 66 IRQ_TYPE_EDGE_RISING>;
+ vdd-supply = <_l19>;
+ vid-supply = <_l28>;
+ };
+
+ accelerometer@18 {
+ compatible = "bosch,bma250e";
+ reg = <0x18>;
+ interrupts-extended = < 63 IRQ_TYPE_EDGE_RISING>;
+ vdd-supply = <_l19>;
+ vddio-supply = <_l28>;
+ };
+};
+
+_i2c4 {
+ status = "okay";
+
+ /* TFA9887 @ 34 */
+ /* TFA9887 @ 35 */
+};
+
+_i2c5 {
+ status = "okay";
+
+ touchscreen@20 {
+ compatible = "syna,rmi4-i2c";
+ reg = <0x20>;
+
+ interrupts-extended = < 17 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <_l19>;
+
+ syna,startup-delay-ms =
[PATCH 1/3] dt-bindings: vendor-prefixes: document HTC Corporation
Add the vendor prefix for HTC (https://www.htc.com/). Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 573578db9509..9fddc274ce76 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -583,6 +583,8 @@ patternProperties: description: Hewlett Packard Enterprise "^hsg,.*": description: HannStar Display Co. + "^htc,.*": +description: HTC Corporation "^huawei,.*": description: Huawei Technologies Co., Ltd. "^hugsun,.*": -- 2.42.0
[PATCH 2/3] dt-bindings: arm: qcom: Add HTC One Mini 2
Document the compatible for the MSM8926-based HTC One Mini 2 smartphone. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/arm/qcom.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 2a607b1595c9..1b7f094aa100 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -192,6 +192,7 @@ properties: - items: - enum: + - htc,memul - microsoft,superman-lte - microsoft,tesla - const: qcom,msm8926 -- 2.42.0
[PATCH 0/3] Add support for HTC One Mini 2 smartphone
Add support for this smartphone from HTC which is based on the MSM8926 SoC and codenamed "memul". Depends on, runtime-only, bootloader enables watchdog so we need to pet it to stay alive: https://lore.kernel.org/linux-arm-msm/20231011-msm8226-msm8974-watchdog-v1-0-2c472818f...@z3ntu.xyz/T/ Depends on, for dt-bindings & Makefile change, could also be re-ordered: https://lore.kernel.org/linux-arm-msm/20230930221323.101289-1-ray...@ansari.sh/T/ (Technically a resend of msg-id <20231011-htc-memul-v1-0-97c3910f8...@z3ntu.xyz> where I missed adding most email addresses, sorry) Signed-off-by: Luca Weiss --- Luca Weiss (3): dt-bindings: vendor-prefixes: document HTC Corporation dt-bindings: arm: qcom: Add HTC One Mini 2 ARM: dts: qcom: Add support for HTC One Mini 2 Documentation/devicetree/bindings/arm/qcom.yaml| 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/qcom/Makefile| 1 + arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts | 337 + 4 files changed, 341 insertions(+) --- base-commit: 4a914c105417214fb38cd124317f174247c0a426 change-id: 20231002-htc-memul-742a8517d24b Best regards, -- Luca Weiss
[PATCH 1/3] dt-bindings: watchdog: qcom-wdt: Add MSM8226 and MSM8974 compatibles
From: Matti Lehtimäki Add compatibles for the MSM8226 and MSM8974 platforms to the Qualcomm watchdog binding. Signed-off-by: Matti Lehtimäki Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index 5046dfa55f13..c12bc852aedc 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -21,6 +21,8 @@ properties: - qcom,apss-wdt-ipq5018 - qcom,apss-wdt-ipq5332 - qcom,apss-wdt-ipq9574 + - qcom,apss-wdt-msm8226 + - qcom,apss-wdt-msm8974 - qcom,apss-wdt-msm8994 - qcom,apss-wdt-qcm2290 - qcom,apss-wdt-qcs404 -- 2.42.0
[PATCH 2/3] ARM: dts: qcom: msm8226: Add watchdog node
From: Matti Lehtimäki
Add watchdog for MSM8226 platform.
Signed-off-by: Matti Lehtimäki
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
index 97a377b5a0ec..b5e715858211 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
@@ -185,6 +185,14 @@ apcs: syscon@f9011000 {
reg = <0xf9011000 0x1000>;
};
+ watchdog@f9017000 {
+ compatible = "qcom,apss-wdt-msm8226", "qcom,kpss-wdt";
+ reg = <0xf9017000 0x1000>;
+ interrupts = ,
+;
+ clocks = <_clk>;
+ };
+
sdhc_1: mmc@f9824900 {
compatible = "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4";
reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
--
2.42.0
[PATCH 3/3] ARM: dts: qcom: msm8974: Add watchdog node
From: Matti Lehtimäki
Add watchdog for MSM8974 platform.
Signed-off-by: Matti Lehtimäki
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
index 0bc2e66d15b1..fbeadd43c9ad 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
@@ -346,6 +346,14 @@ apcs: syscon@f9011000 {
reg = <0xf9011000 0x1000>;
};
+ watchdog@f9017000 {
+ compatible = "qcom,apss-wdt-msm8974", "qcom,kpss-wdt";
+ reg = <0xf9017000 0x1000>;
+ interrupts = ,
+;
+ clocks = <_clk>;
+ };
+
timer@f902 {
#address-cells = <1>;
#size-cells = <1>;
--
2.42.0
[PATCH 0/3] Add watchdog nodes to msm8226 & msm8974
Document the compatible for the watchdog found on both SoCs, and add them to the SoC dtsi file. And especially for the case where the bootloader has already enabled the watchdog we need to start petting it on time, otherwise the system gets rebooted. It's worth noting that the watchdog behaves a bit unexpectedly. It appears the watchdog counts down significantly slower when there's no load on the system and can last far longer than 30 seconds until they bark. Only when putting load on the system, e.g. with stress-ng does the watchdog interrupt fire and kill the system within an expected amount of time. This behavior has been observed on both msm8974 and msm8226 smartphones. Signed-off-by: Luca Weiss --- Matti Lehtimäki (3): dt-bindings: watchdog: qcom-wdt: Add MSM8226 and MSM8974 compatibles ARM: dts: qcom: msm8226: Add watchdog node ARM: dts: qcom: msm8974: Add watchdog node Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml | 2 ++ arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 8 arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 8 3 files changed, 18 insertions(+) --- base-commit: 2933a1156742d8c47550493a77af8e2d81cf3c84 change-id: 20231011-msm8226-msm8974-watchdog-a88e45f4e2a4 Best regards, -- Luca Weiss
Re: [PATCH] bpf/btf: Move tracing BTF APIs to the BTF library
On 10/10/2023 14:54, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google)
>
> Move the BTF APIs used in tracing to the BTF library code for sharing it
> with others.
> Previously, to avoid complex dependency in a series I made it on the
> tracing tree, but now it is a good time to move it to BPF tree because
> these functions are pure BTF functions.
>
Makes sense to me. Two very small things - usual practice for
bpf-related changes is to specify "PATCH bpf-next" for changes like
this that target the -next tree. Other thing is I'm reasonably sure
no functional changes are intended - it's basically just a matter of
moving code from trace_btf -> btf - but would be good to confirm
that no functional changes are intended or similar in the commit
message. It's sort of implicit when you say "move the BTF APIs", but
would be good to confirm.
> Signed-off-by: Masami Hiramatsu (Google)
Reviewed-by: Alan Maguire
> ---
> include/linux/btf.h| 24 +
> kernel/bpf/btf.c | 115 +
> kernel/trace/Makefile |1
> kernel/trace/trace_btf.c | 122
>
> kernel/trace/trace_btf.h | 11
> kernel/trace/trace_probe.c |2 -
> 6 files changed, 140 insertions(+), 135 deletions(-)
> delete mode 100644 kernel/trace/trace_btf.c
> delete mode 100644 kernel/trace/trace_btf.h
>
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index 928113a80a95..8372d93ea402 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -507,6 +507,14 @@ btf_get_prog_ctx_type(struct bpf_verifier_log *log,
> const struct btf *btf,
> int get_kern_ctx_btf_id(struct bpf_verifier_log *log, enum bpf_prog_type
> prog_type);
> bool btf_types_are_same(const struct btf *btf1, u32 id1,
> const struct btf *btf2, u32 id2);
> +const struct btf_type *btf_find_func_proto(const char *func_name,
> +struct btf **btf_p);
> +const struct btf_param *btf_get_func_param(const struct btf_type *func_proto,
> +s32 *nr);
> +const struct btf_member *btf_find_struct_member(struct btf *btf,
> + const struct btf_type *type,
> + const char *member_name,
> + u32 *anon_offset);
> #else
> static inline const struct btf_type *btf_type_by_id(const struct btf *btf,
> u32 type_id)
> @@ -559,6 +567,22 @@ static inline bool btf_types_are_same(const struct btf
> *btf1, u32 id1,
> {
> return false;
> }
> +static inline const struct btf_type *btf_find_func_proto(const char
> *func_name,
> + struct btf **btf_p)
> +{
> + return NULL;
> +}
> +static inline const struct btf_param *
> +btf_get_func_param(const struct btf_type *func_proto, s32 *nr)
> +{
> + return NULL;
> +}
> +static inline const struct btf_member *
> +btf_find_struct_member(struct btf *btf, const struct btf_type *type,
> +const char *member_name, u32 *anon_offset)
> +{
> + return NULL;
> +}
> #endif
>
> static inline bool btf_type_is_struct_ptr(struct btf *btf, const struct
> btf_type *t)
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 8090d7fb11ef..e5cbf3b31b78 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -912,6 +912,121 @@ static const struct btf_type
> *btf_type_skip_qualifiers(const struct btf *btf,
> return t;
> }
>
> +/*
> + * Find a function proto type by name, and return the btf_type with its btf
> + * in *@btf_p. Return NULL if not found.
> + * Note that caller has to call btf_put(*@btf_p) after using the btf_type.
> + */
> +const struct btf_type *btf_find_func_proto(const char *func_name, struct btf
> **btf_p)
> +{
> + const struct btf_type *t;
> + s32 id;
> +
> + id = bpf_find_btf_id(func_name, BTF_KIND_FUNC, btf_p);
> + if (id < 0)
> + return NULL;
> +
> + /* Get BTF_KIND_FUNC type */
> + t = btf_type_by_id(*btf_p, id);
> + if (!t || !btf_type_is_func(t))
> + goto err;
> +
> + /* The type of BTF_KIND_FUNC is BTF_KIND_FUNC_PROTO */
> + t = btf_type_by_id(*btf_p, t->type);
> + if (!t || !btf_type_is_func_proto(t))
> + goto err;
> +
> + return t;
> +err:
> + btf_put(*btf_p);
> + return NULL;
> +}
> +
> +/*
> + * Get function parameter with the number of parameters.
> + * This can return NULL if the function has no parameters.
> + * It can return -EINVAL if the @func_proto is not a function proto type.
> + */
> +const struct btf_param *btf_get_func_param(const struct btf_type
> *func_proto, s32 *nr)
> +{
> + if (!btf_type_is_func_proto(func_proto))
> + return ERR_PTR(-EINVAL);
> +
> + *nr = btf_type_vlen(func_proto);
> +
Re: [PATCH v5 12/18] x86/sgx: Add EPC OOM path to forcefully reclaim EPC
On Tue, 10 Oct 2023 19:31:19 -0500, Huang, Kai wrote: On Tue, 2023-10-10 at 12:05 -0500, Haitao Huang wrote: On Mon, 09 Oct 2023 21:12:27 -0500, Huang, Kai wrote: > > > > > > > > > > Later the hosting process could migrated/reassigned to another > > cgroup? > > > > What to do when the new cgroup is OOM? > > > > > > > > > > You addressed in the documentation, no? > > > > > > +Migration > > > +- > > > + > > > +Once an EPC page is charged to a cgroup (during allocation), it > > > +remains charged to the original cgroup until the page is released > > > +or reclaimed. Migrating a process to a different cgroup doesn't > > > +move the EPC charges that it incurred while in the previous cgroup > > > +to its new cgroup. > > > > Should we kill the enclave though because some VA pages may be in the > > new > > group? > > > > I guess acceptable? > > And any difference if you keep VA/SECS to unreclaimabe list? Tracking VA/SECS allows all cgroups, in which an enclave has allocation, to identify the enclave following the back pointer and kill it as needed. > If you migrate one > enclave to another cgroup, the old EPC pages stay in the old cgroup > while the > new one is charged to the new group IIUC. > > I am not cgroup expert, but by searching some old thread it appears this > isn't a > supported model: > > https://lore.kernel.org/lkml/yeyr9181qgzt+...@mtj.duckdns.org/ > IIUC it's a different problem here. If we don't track the allocated VAs in the new group, then the enclave that spans the two groups can't be killed by the new group. If so, some enclave could just hide in some small group and never gets killed but keeps allocating in a different group? I mean from the link above IIUC migrating enclave among different cgroups simply isn't a supported model, thus any bad behaviour isn't a big concern in terms of decision making. If we leave some pages in a cgroup unkillable, we are in the same situation of not able to enforce a cgroup limit as that we are are in if we don't kill VMs for lower limits. I think not supporting migration of pages between cgroups should not leave a gap for enforcement just like we don't want to have an enforcement gap if we let VMs to hold pages once it is launched. Haitao
Re: [PATCH] testing: nvdimm: make struct class structures constant
Greg Kroah-Hartman wrote: > Now that the driver core allows for struct class to be in read-only > memory, we should make all 'class' structures declared at build time > placing them into read-only memory, instead of having to be dynamically > allocated at runtime. > > Cc: Dan Williams > Cc: Vishal Verma > Cc: Dave Jiang > Cc: Ira Weiny Tested-by: Ira Weiny Reviewed-by: Ira Weiny > Signed-off-by: Greg Kroah-Hartman > --- > tools/testing/nvdimm/test/ndtest.c | 17 + > tools/testing/nvdimm/test/nfit.c | 14 +++--- > 2 files changed, 16 insertions(+), 15 deletions(-)
Re: [PATCH v5 12/18] x86/sgx: Add EPC OOM path to forcefully reclaim EPC
On Tue, 10 Oct 2023 19:01:25 -0500, Sean Christopherson wrote: On Tue, Oct 10, 2023, Haitao Huang wrote: On Mon, 09 Oct 2023 21:23:12 -0500, Huang, Kai wrote: > On Mon, 2023-10-09 at 20:42 -0500, Haitao Huang wrote: > > Hi Sean > > > > On Mon, 09 Oct 2023 19:23:04 -0500, Sean Christopherson > > wrote: > > > I can see userspace wanting to explicitly terminate the VM instead of > > > "silently" > > > the VM's enclaves, but that seems like it should be a knob in the > > > virtual EPC > > > code. > > > > If my understanding above is correct and understanding your statement > > above correctly, then don't see we really need separate knob for vEPC > > code. Reaching a cgroup limit by a running guest (assuming dynamic > > allocation implemented) should not translate automatically killing > > the VM. > > Instead, it's user space job to work with guest to handle allocation > > failure. Guest could page and kill enclaves. > > > > IIUC Sean was talking about changing misc.max _after_ you launch SGX VMs: > > 1) misc.max = 100M > 2) Launch VMs with total virtual EPC size = 100M <- success > 3) misc.max = 50M > > 3) will also succeed, but nothing will happen, the VMs will be still > holding 100M EPC. > > You need to somehow track virtual EPC and kill VM instead. > > (or somehow fail to do 3) if it is also an acceptable option.) > Thanks for explaining it. There is an error code to return from max_write. I can add that too to the callback definition and fail it when it can't be enforced for any reason. Would like some community feedback if this is acceptable though. That likely isn't acceptable. E.g. create a cgroup with both a host enclave and virtual EPC, set the hard limit to 100MiB. Virtual EPC consumes 50MiB, and the host enclave consumes 50MiB. Userspace lowers the limit to 49MiB. The cgroup code would reclaim all of the enclave's reclaimable EPC, and then kill the enclave because it's still over the limit. And then fail the max_write because the cgroup is *still* over the limit. So in addition to burning a lot of cycles, from userspace's perspective its enclave was killed for no reason, as the new limit wasn't actually set. I was thinking before reclaiming enclave pages, if we know the untracked vepc pages (current-tracked) is larger than limit, we just return error without enforcing the limit. That way user also knows something is wrong. But I get that we want to be able to kill VMs to enforce the newer lower limit. I assume we can't optimize efficiency/priority of killing: enclave pages will be reclaimed first no matter what just because they are reclaimable; no good rules to choose victim between enclave and VMs in your example so enclaves could be killed still before VMs. I think to solve it ultimately, we need be able to adjust 'capacity' of VMs not to just kill them, which is basically the same as dynamic allocation support for VMs (being able to increase/decrease epc size when it is running). For now, we only have static allocation so max can't be enforced once it is launched. No, reclaiming virtual EPC is not a requirement. VMM EPC oversubscription is insanely complex, and I highly doubt any users actually want to oversubcribe VMs. There are use cases for cgroups beyond oversubscribing/swapping, e.g. privileged userspace may set limits on a container to ensure the container doesn't *accidentally* consume more EPC than it was allotted, e.g. due to a configuration bug that created a VM with more EPC than it was supposed to have. My comments on virtual EPC vs. cgroups is much more about having sane, well-defined behavior, not about saying the kernel actually needs to support oversubscribing EPC for KVM guests. So here are the steps I see now, let me know if this is aligned with your thinking or I'm off track. 0) when all left are enclave VA, SECS pages and VEPC in a cgroup, the OOM kill process starts. 1) The cgroup identifies a victim vepc for OOM kill(this could be before or after enclaves being killed), sets a new flag VEPC_NO_MEMORY in the vepc. 2) call sgx_vepc_remove_all(), ignore failure counts returned. This will perform best effort to eremove all normal pages used by the vepc. 3) Guest may trigger fault again, return SIGBUS in sgx_vepc_fault when VEPC_NO_MEMORY is set. Do the same for mmap. 4) That would eventually cause sgx_vepc_release() before VM dies or killed by user space, which does the final cleanup. Q: should we reset VEPC_NO_MEMORY flag if #4 never happens and cgroup usage is below limit? I suppose we can do it, but not sure it is sane because VM would try to load as much pages as configured originally. I'm still thinking about using one unreclaimable list, justification is simplicity and lack of rules to select items from separate lists, but may change my mind if I found it's inconvenient. Not sure how age/youngness can be accounted for guest pages though Kai
Re: [PATCH v1 0/2] Fix memory leak and move to modern scope based rollback
On 9/26/2023 8:45 PM, Michal Wilczynski wrote: > In acpi_nfit_init_interleave_set() there is a memory leak + improper use > of devm_*() family of functions for local memory allocations. This patch > series provides two commits - one is meant as a bug fix, and could > potentially be backported, and the other one improves old style rollback > with scope based, similar to C++ RAII [1]. > > Link: https://lwn.net/Articles/934679/ [1] > > Michal Wilczynski (2): > ACPI: NFIT: Fix memory leak, and local use of devm_*() > ACPI: NFIT: Use modern scope based rollback > > drivers/acpi/nfit/core.c | 21 - > 1 file changed, 8 insertions(+), 13 deletions(-) Hi Dan, Do you think this patchset is fine ? Would you like me to change anything ? Regards, Michał >
Re: [PATCH 09/10] wireless: hostap: remove unused ioctl function
On Tue, Oct 10, 2023, at 09:00, Kalle Valo wrote: > Arnd Bergmann writes: > >> From: Arnd Bergmann >> >> The ioctl handler has no actual callers in the kernel and is useless. >> All the functionality should be reachable through the regualar interfaces. >> >> Signed-off-by: Arnd Bergmann > > In the title we prefer "wifi:" over "wireless:" but that's nitpicking. I > assume this goes via a net tree so: Changed for v2 > Acked-by: Kalle Valo Thanks > Let me know if I should take this to wireless-next instead. I think it's better to keep the series together and merge it through net-next directly, since the last patch depends on all the ones before it. Arnd
Re: [PATCH 4/5] kbuild: unify vdso_install rules
On Wed, Oct 11, 2023 at 11:24 AM Guo Ren wrote: > > On Mon, Oct 9, 2023 at 8:42 PM Masahiro Yamada wrote: > > --- a/arch/riscv/Makefile > > +++ b/arch/riscv/Makefile > > @@ -131,12 +131,6 @@ endif > > libs-y += arch/riscv/lib/ > > libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > > > > -PHONY += vdso_install > > -vdso_install: > > - $(Q)$(MAKE) $(build)=arch/riscv/kernel/vdso $@ > > - $(if $(CONFIG_COMPAT),$(Q)$(MAKE) \ > > - $(build)=arch/riscv/kernel/compat_vdso compat_$@) > > - > > ifeq ($(KBUILD_EXTMOD),) > > ifeq ($(CONFIG_MMU),y) > > prepare: vdso_prepare > > @@ -148,6 +142,9 @@ vdso_prepare: prepare0 > > endif > > endif > > > > +vdso-install-y += arch/riscv/kernel/vdso/vdso.so.dbg > > +vdso-install-$(CONFIG_COMPAT) += > > arch/riscv/kernel/compat_vdso/compat_vdso.so.dbg:../compat_vdso/compat_vdso.so > Why do we need ":../compat_vdso/compat_vdso.so" here? All architectures except riscv install vdso files to /lib/modules/$(uname -r)/vdso/. See the following code in arch/riscv/kernel/compat_vdso/Makefile: quiet_cmd_compat_vdso_install = INSTALL $@ cmd_compat_vdso_install = cp $(obj)/$@.dbg $(MODLIB)/compat_vdso/$@ Riscv copies the compat vdso to /lib/modules/$(uname -r)/compat_vdso/. This commit preserves the current installation path as-is. If the riscv maintainers agree, we can change the installation destination to /lib/modules/$(uname -r)/vdso/ for consistency. -- Best Regards Masahiro Yamada
Re: [PATCH v2] module: Add CONFIG_MODULE_LOAD_IN_SEQUENCE option
Hi Joey, kernel test robot noticed the following build warnings: [auto build test WARNING on mcgrof/modules-next] [also build test WARNING on linus/master v6.6-rc5 next-20231011] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Joey-Jiao/module-Add-CONFIG_MODULE_LOAD_IN_SEQUENCE-option/20231011-154640 base: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git modules-next patch link: https://lore.kernel.org/r/20231011074438.6098-1-quic_jiangenj%40quicinc.com patch subject: [PATCH v2] module: Add CONFIG_MODULE_LOAD_IN_SEQUENCE option config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20231011/202310111840.ufgoxyfm-...@intel.com/config) compiler: m68k-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231011/202310111840.ufgoxyfm-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202310111840.ufgoxyfm-...@intel.com/ All warnings (new ones prefixed by >>): kernel/module/main.c: In function 'do_init_module': kernel/module/main.c:2627:12: error: invalid storage class for function 'may_init_module' 2627 | static int may_init_module(void) |^~~ kernel/module/main.c:2636:13: error: invalid storage class for function 'finished_loading' 2636 | static bool finished_loading(const char *name) | ^~~~ kernel/module/main.c:2657:12: error: invalid storage class for function 'module_patient_check_exists' 2657 | static int module_patient_check_exists(const char *name, |^~~ kernel/module/main.c:2701:12: error: invalid storage class for function 'add_unformed_module' 2701 | static int add_unformed_module(struct module *mod) |^~~ kernel/module/main.c:2722:12: error: invalid storage class for function 'complete_formation' 2722 | static int complete_formation(struct module *mod, struct load_info *info) |^~ kernel/module/main.c:2755:12: error: invalid storage class for function 'prepare_coming_module' 2755 | static int prepare_coming_module(struct module *mod) |^ kernel/module/main.c:2773:12: error: invalid storage class for function 'unknown_module_param_cb' 2773 | static int unknown_module_param_cb(char *param, char *val, const char *modname, |^~~ kernel/module/main.c:2793:12: error: invalid storage class for function 'early_mod_check' 2793 | static int early_mod_check(struct load_info *info, int flags) |^~~ kernel/module/main.c:2829:12: error: invalid storage class for function 'load_module' 2829 | static int load_module(struct load_info *info, const char __user *uargs, |^~~ In file included from include/linux/compiler_types.h:125, from : >> include/linux/compiler-gcc.h:132:33: warning: 'alias' attribute ignored >> [-Wattributes] 132 | #define __diag(s) _Pragma(__diag_str(GCC diagnostic s)) | ^~~ include/linux/compiler-gcc.h:135:33: note: in expansion of macro '__diag' 135 | #define __diag_GCC_8(s) __diag(s) | ^~ include/linux/compiler-gcc.h:123:9: note: in expansion of macro '__diag_GCC_8' 123 | __diag_GCC_ ## version(__diag_GCC_ ## severity s) | ^~~ include/linux/compiler_types.h:416:9: note: in expansion of macro '__diag_GCC' 416 | __diag_ ## compiler(version, ignore, option) | ^~~ include/linux/syscalls.h:242:9: note: in expansion of macro '__diag_ignore' 242 | __diag_ignore(GCC, 8, "-Wattribute-alias", \ | ^ include/linux/syscalls.h:230:9: note: in expansion of macro '__SYSCALL_DEFINEx' 230 | __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) | ^ include/linux/syscalls.h:221:36: note: in expansion of macro 'SYSCALL_DEFINEx' 221 | #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__) |^~~ kernel/module/main.c:3039:1: note: in expansion of macro 'SYSCALL_DEFINE3' 3039 | SYSCALL_DEFINE3(init_module, void __user *, umod, | ^~~ In file included from kernel/module
Re: [PATCH 01/10] appletalk: remove localtalk and ppp support
Hi Arnd,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20231009]
[cannot apply to linus/master v6.6-rc5 v6.6-rc4 v6.6-rc3 v6.6-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Arnd-Bergmann/ieee802154-avoid-deprecated-ndo_do_ioctl-callback/20231009-222305
base: next-20231009
patch link:
https://lore.kernel.org/r/20231009141908.1767241-1-arnd%40kernel.org
patch subject: [PATCH 01/10] appletalk: remove localtalk and ppp support
config: x86_64-randconfig-002-20231011
(https://download.01.org/0day-ci/archive/20231011/202310111736.4mh6cf5c-...@intel.com/config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231011/202310111736.4mh6cf5c-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202310111736.4mh6cf5c-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/net/appletalk/ipddp.c: In function 'ipddp_create':
drivers/net/appletalk/ipddp.c:207:24: error: implicit declaration of
function 'atrtr_get_dev'; did you mean 'to_net_dev'?
[-Werror=implicit-function-declaration]
if ((rt->dev = atrtr_get_dev(>at)) == NULL) {
^
to_net_dev
>> drivers/net/appletalk/ipddp.c:207:22: warning: assignment makes pointer from
>> integer without a cast [-Wint-conversion]
if ((rt->dev = atrtr_get_dev(>at)) == NULL) {
^
cc1: some warnings being treated as errors
vim +207 drivers/net/appletalk/ipddp.c
^1da177e4c3f41 Linus Torvalds 2005-04-16 192
^1da177e4c3f41 Linus Torvalds 2005-04-16 193 /*
^1da177e4c3f41 Linus Torvalds 2005-04-16 194 * Create a routing entry. We
first verify that the
^1da177e4c3f41 Linus Torvalds 2005-04-16 195 * record does not already
exist. If it does we return -EEXIST
^1da177e4c3f41 Linus Torvalds 2005-04-16 196 */
^1da177e4c3f41 Linus Torvalds 2005-04-16 197 static int ipddp_create(struct
ipddp_route *new_rt)
^1da177e4c3f41 Linus Torvalds 2005-04-16 198 {
ce7e40c432ba84 Vlad Tsyrklevich 2017-01-09 199 struct ipddp_route *rt
= kzalloc(sizeof(*rt), GFP_KERNEL);
^1da177e4c3f41 Linus Torvalds 2005-04-16 200
^1da177e4c3f41 Linus Torvalds 2005-04-16 201 if (rt == NULL)
^1da177e4c3f41 Linus Torvalds 2005-04-16 202 return -ENOMEM;
^1da177e4c3f41 Linus Torvalds 2005-04-16 203
^1da177e4c3f41 Linus Torvalds 2005-04-16 204 rt->ip = new_rt->ip;
^1da177e4c3f41 Linus Torvalds 2005-04-16 205 rt->at = new_rt->at;
^1da177e4c3f41 Linus Torvalds 2005-04-16 206 rt->next = NULL;
^1da177e4c3f41 Linus Torvalds 2005-04-16 @207 if ((rt->dev =
atrtr_get_dev(>at)) == NULL) {
^1da177e4c3f41 Linus Torvalds 2005-04-16 208 kfree(rt);
^1da177e4c3f41 Linus Torvalds 2005-04-16 209 return
-ENETUNREACH;
^1da177e4c3f41 Linus Torvalds 2005-04-16 210 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 211
5615968a708451 David S. Miller 2009-05-27 212
spin_lock_bh(_route_lock);
5615968a708451 David S. Miller 2009-05-27 213 if
(__ipddp_find_route(rt)) {
5615968a708451 David S. Miller 2009-05-27 214
spin_unlock_bh(_route_lock);
^1da177e4c3f41 Linus Torvalds 2005-04-16 215 kfree(rt);
^1da177e4c3f41 Linus Torvalds 2005-04-16 216 return -EEXIST;
^1da177e4c3f41 Linus Torvalds 2005-04-16 217 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 218
^1da177e4c3f41 Linus Torvalds 2005-04-16 219 rt->next =
ipddp_route_list;
^1da177e4c3f41 Linus Torvalds 2005-04-16 220 ipddp_route_list = rt;
^1da177e4c3f41 Linus Torvalds 2005-04-16 221
5615968a708451 David S. Miller 2009-05-27 222
spin_unlock_bh(_route_lock);
5615968a708451 David S. Miller 2009-05-27 223
^1da177e4c3f41 Linus Torvalds 2005-04-16 224 return 0;
^1da177e4c3f41 Linus Torvalds 2005-04-16 225 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 226
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
[PATCH v3 6/6] ACPI: NFIT: Remove redundant call to to_acpi_dev()
In acpi_nfit_ctl() ACPI handle is extracted using to_acpi_dev()
function and accessing handle field in ACPI device. After transformation
from ACPI driver to platform driver this is not optimal anymore. To get
a handle it's enough to just use ACPI_HANDLE() macro to extract the
handle.
Suggested-by: Andy Shevchenko
Signed-off-by: Michal Wilczynski
---
drivers/acpi/nfit/core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 6b9d10cae92c..402bb56d4163 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -475,8 +475,6 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc,
struct nvdimm *nvdimm,
guid = to_nfit_uuid(nfit_mem->family);
handle = adev->handle;
} else {
- struct acpi_device *adev = to_acpi_dev(acpi_desc);
-
cmd_name = nvdimm_bus_cmd_name(cmd);
cmd_mask = nd_desc->cmd_mask;
if (cmd == ND_CMD_CALL && call_pkg->nd_family) {
@@ -493,7 +491,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc,
struct nvdimm *nvdimm,
guid = to_nfit_uuid(NFIT_DEV_BUS);
}
desc = nd_cmd_bus_desc(cmd);
- handle = adev->handle;
+ handle = ACPI_HANDLE(dev);
dimm_name = "bus";
}
--
2.41.0
[PATCH v3 5/6] ACPI: NFIT: Replace acpi_driver with platform_driver
NFIT driver uses struct acpi_driver incorrectly to register itself.
This is wrong as the instances of the ACPI devices are not meant
to be literal devices, they're supposed to describe ACPI entry of a
particular device.
Use platform_driver instead of acpi_driver. In relevant places call
platform devices instances pdev to make a distinction with ACPI
devices instances.
NFIT driver uses devm_*() family of functions extensively. This change
has no impact on correct functioning of the whole devm_*() family of
functions, since the lifecycle of the device stays the same. It is still
being created during the enumeration, and destroyed on platform device
removal.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Michal Wilczynski
---
drivers/acpi/nfit/core.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 3826f49d481b..6b9d10cae92c 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include "intel.h"
@@ -98,7 +99,7 @@ static struct acpi_device *to_acpi_dev(struct acpi_nfit_desc
*acpi_desc)
|| strcmp(nd_desc->provider_name, "ACPI.NFIT") != 0)
return NULL;
- return to_acpi_device(acpi_desc->dev);
+ return ACPI_COMPANION(acpi_desc->dev);
}
static int xlat_bus_status(void *buf, unsigned int cmd, u32 status)
@@ -3284,11 +3285,11 @@ static void acpi_nfit_put_table(void *table)
static void acpi_nfit_notify(acpi_handle handle, u32 event, void *data)
{
- struct acpi_device *adev = data;
+ struct device *dev = data;
- device_lock(>dev);
- __acpi_nfit_notify(>dev, handle, event);
- device_unlock(>dev);
+ device_lock(dev);
+ __acpi_nfit_notify(dev, handle, event);
+ device_unlock(dev);
}
static void acpi_nfit_remove_notify_handler(void *data)
@@ -3329,11 +3330,12 @@ void acpi_nfit_shutdown(void *data)
}
EXPORT_SYMBOL_GPL(acpi_nfit_shutdown);
-static int acpi_nfit_add(struct acpi_device *adev)
+static int acpi_nfit_probe(struct platform_device *pdev)
{
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_nfit_desc *acpi_desc;
- struct device *dev = >dev;
+ struct device *dev = >dev;
+ struct acpi_device *adev = ACPI_COMPANION(dev);
struct acpi_table_header *tbl;
acpi_status status = AE_OK;
acpi_size sz;
@@ -3360,7 +3362,7 @@ static int acpi_nfit_add(struct acpi_device *adev)
acpi_desc = devm_kzalloc(dev, sizeof(*acpi_desc), GFP_KERNEL);
if (!acpi_desc)
return -ENOMEM;
- acpi_nfit_desc_init(acpi_desc, >dev);
+ acpi_nfit_desc_init(acpi_desc, dev);
/* Save the acpi header for exporting the revision via sysfs */
acpi_desc->acpi_header = *tbl;
@@ -3391,7 +3393,7 @@ static int acpi_nfit_add(struct acpi_device *adev)
return rc;
rc = acpi_dev_install_notify_handler(adev, ACPI_DEVICE_NOTIFY,
-acpi_nfit_notify, adev);
+acpi_nfit_notify, dev);
if (rc)
return rc;
@@ -3475,11 +3477,11 @@ static const struct acpi_device_id acpi_nfit_ids[] = {
};
MODULE_DEVICE_TABLE(acpi, acpi_nfit_ids);
-static struct acpi_driver acpi_nfit_driver = {
- .name = KBUILD_MODNAME,
- .ids = acpi_nfit_ids,
- .ops = {
- .add = acpi_nfit_add,
+static struct platform_driver acpi_nfit_driver = {
+ .probe = acpi_nfit_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .acpi_match_table = acpi_nfit_ids,
},
};
@@ -3517,7 +3519,7 @@ static __init int nfit_init(void)
return -ENOMEM;
nfit_mce_register();
- ret = acpi_bus_register_driver(_nfit_driver);
+ ret = platform_driver_register(_nfit_driver);
if (ret) {
nfit_mce_unregister();
destroy_workqueue(nfit_wq);
@@ -3530,7 +3532,7 @@ static __init int nfit_init(void)
static __exit void nfit_exit(void)
{
nfit_mce_unregister();
- acpi_bus_unregister_driver(_nfit_driver);
+ platform_driver_unregister(_nfit_driver);
destroy_workqueue(nfit_wq);
WARN_ON(!list_empty(_descs));
}
--
2.41.0
[PATCH v3 4/6] ACPI: AC: Rename ACPI device from device to adev
Since transformation from ACPI driver to platform driver there are two
devices on which the driver operates - ACPI device and platform device.
For the sake of reader this calls for the distinction in their naming,
to avoid confusion. Rename device to adev, as corresponding
platform device is called pdev.
Signed-off-by: Michal Wilczynski
---
drivers/acpi/ac.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index 1dd4919be7ac..2618a7ccc11c 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -121,11 +121,11 @@ static void acpi_ac_notify(acpi_handle handle, u32 event,
void *data)
{
struct device *dev = data;
struct acpi_ac *ac = dev_get_drvdata(dev);
- struct acpi_device *device = ACPI_COMPANION(dev);
+ struct acpi_device *adev = ACPI_COMPANION(dev);
switch (event) {
default:
- acpi_handle_debug(device->handle, "Unsupported event [0x%x]\n",
+ acpi_handle_debug(adev->handle, "Unsupported event [0x%x]\n",
event);
fallthrough;
case ACPI_AC_NOTIFY_STATUS:
@@ -142,11 +142,11 @@ static void acpi_ac_notify(acpi_handle handle, u32 event,
void *data)
msleep(ac_sleep_before_get_state_ms);
acpi_ac_get_state(ac);
- acpi_bus_generate_netlink_event(device->pnp.device_class,
+ acpi_bus_generate_netlink_event(adev->pnp.device_class,
dev_name(dev),
event,
ac->state);
- acpi_notifier_call_chain(device, event, ac->state);
+ acpi_notifier_call_chain(adev, event, ac->state);
kobject_uevent(>charger->dev.kobj, KOBJ_CHANGE);
}
}
@@ -205,7 +205,7 @@ static const struct dmi_system_id ac_dmi_table[]
__initconst = {
static int acpi_ac_probe(struct platform_device *pdev)
{
- struct acpi_device *device = ACPI_COMPANION(>dev);
+ struct acpi_device *adev = ACPI_COMPANION(>dev);
struct power_supply_config psy_cfg = {};
struct acpi_ac *ac;
int result;
@@ -214,9 +214,9 @@ static int acpi_ac_probe(struct platform_device *pdev)
if (!ac)
return -ENOMEM;
- ac->device = device;
- strcpy(acpi_device_name(device), ACPI_AC_DEVICE_NAME);
- strcpy(acpi_device_class(device), ACPI_AC_CLASS);
+ ac->device = adev;
+ strcpy(acpi_device_name(adev), ACPI_AC_DEVICE_NAME);
+ strcpy(acpi_device_class(adev), ACPI_AC_CLASS);
platform_set_drvdata(pdev, ac);
@@ -226,7 +226,7 @@ static int acpi_ac_probe(struct platform_device *pdev)
psy_cfg.drv_data = ac;
- ac->charger_desc.name = acpi_device_bid(device);
+ ac->charger_desc.name = acpi_device_bid(adev);
ac->charger_desc.type = POWER_SUPPLY_TYPE_MAINS;
ac->charger_desc.properties = ac_props;
ac->charger_desc.num_properties = ARRAY_SIZE(ac_props);
@@ -238,13 +238,13 @@ static int acpi_ac_probe(struct platform_device *pdev)
goto err_release_ac;
}
- pr_info("%s [%s] (%s-line)\n", acpi_device_name(device),
- acpi_device_bid(device), str_on_off(ac->state));
+ pr_info("%s [%s] (%s-line)\n", acpi_device_name(adev),
+ acpi_device_bid(adev), str_on_off(ac->state));
ac->battery_nb.notifier_call = acpi_ac_battery_notify;
register_acpi_notifier(>battery_nb);
- result = acpi_dev_install_notify_handler(device, ACPI_ALL_NOTIFY,
+ result = acpi_dev_install_notify_handler(adev, ACPI_ALL_NOTIFY,
acpi_ac_notify, >dev);
if (result)
goto err_unregister;
--
2.41.0
[PATCH v3 3/6] ACPI: AC: Replace acpi_driver with platform_driver
AC driver uses struct acpi_driver incorrectly to register itself. This
is wrong as the instances of the ACPI devices are not meant to
be literal devices, they're supposed to describe ACPI entry of a
particular device.
Use platform_driver instead of acpi_driver. In relevant places call
platform devices instances pdev to make a distinction with ACPI
devices instances.
Drop unnecessary casts from acpi_bus_generate_netlink_event() and
acpi_notifier_call_chain().
Add a blank line to distinguish pdev API vs local ACPI notify function.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Michal Wilczynski
---
drivers/acpi/ac.c | 61 +--
1 file changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index f809f6889b4a..1dd4919be7ac 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -33,8 +33,9 @@ MODULE_AUTHOR("Paul Diefenbaugh");
MODULE_DESCRIPTION("ACPI AC Adapter Driver");
MODULE_LICENSE("GPL");
-static int acpi_ac_add(struct acpi_device *device);
-static void acpi_ac_remove(struct acpi_device *device);
+static int acpi_ac_probe(struct platform_device *pdev);
+static void acpi_ac_remove(struct platform_device *pdev);
+
static void acpi_ac_notify(acpi_handle handle, u32 event, void *data);
static const struct acpi_device_id ac_device_ids[] = {
@@ -51,17 +52,6 @@ static SIMPLE_DEV_PM_OPS(acpi_ac_pm, NULL, acpi_ac_resume);
static int ac_sleep_before_get_state_ms;
static int ac_only;
-static struct acpi_driver acpi_ac_driver = {
- .name = "ac",
- .class = ACPI_AC_CLASS,
- .ids = ac_device_ids,
- .ops = {
- .add = acpi_ac_add,
- .remove = acpi_ac_remove,
- },
- .drv.pm = _ac_pm,
-};
-
struct acpi_ac {
struct power_supply *charger;
struct power_supply_desc charger_desc;
@@ -129,8 +119,9 @@ static enum power_supply_property ac_props[] = {
/* Driver Model */
static void acpi_ac_notify(acpi_handle handle, u32 event, void *data)
{
- struct acpi_device *device = data;
- struct acpi_ac *ac = acpi_driver_data(device);
+ struct device *dev = data;
+ struct acpi_ac *ac = dev_get_drvdata(dev);
+ struct acpi_device *device = ACPI_COMPANION(dev);
switch (event) {
default:
@@ -152,9 +143,10 @@ static void acpi_ac_notify(acpi_handle handle, u32 event,
void *data)
acpi_ac_get_state(ac);
acpi_bus_generate_netlink_event(device->pnp.device_class,
- dev_name(>dev), event,
- (u32) ac->state);
- acpi_notifier_call_chain(device, event, (u32) ac->state);
+ dev_name(dev),
+ event,
+ ac->state);
+ acpi_notifier_call_chain(device, event, ac->state);
kobject_uevent(>charger->dev.kobj, KOBJ_CHANGE);
}
}
@@ -211,8 +203,9 @@ static const struct dmi_system_id ac_dmi_table[]
__initconst = {
{},
};
-static int acpi_ac_add(struct acpi_device *device)
+static int acpi_ac_probe(struct platform_device *pdev)
{
+ struct acpi_device *device = ACPI_COMPANION(>dev);
struct power_supply_config psy_cfg = {};
struct acpi_ac *ac;
int result;
@@ -224,7 +217,8 @@ static int acpi_ac_add(struct acpi_device *device)
ac->device = device;
strcpy(acpi_device_name(device), ACPI_AC_DEVICE_NAME);
strcpy(acpi_device_class(device), ACPI_AC_CLASS);
- device->driver_data = ac;
+
+ platform_set_drvdata(pdev, ac);
result = acpi_ac_get_state(ac);
if (result)
@@ -237,7 +231,7 @@ static int acpi_ac_add(struct acpi_device *device)
ac->charger_desc.properties = ac_props;
ac->charger_desc.num_properties = ARRAY_SIZE(ac_props);
ac->charger_desc.get_property = get_ac_property;
- ac->charger = power_supply_register(>device->dev,
+ ac->charger = power_supply_register(>dev,
>charger_desc, _cfg);
if (IS_ERR(ac->charger)) {
result = PTR_ERR(ac->charger);
@@ -251,7 +245,7 @@ static int acpi_ac_add(struct acpi_device *device)
register_acpi_notifier(>battery_nb);
result = acpi_dev_install_notify_handler(device, ACPI_ALL_NOTIFY,
-acpi_ac_notify, device);
+acpi_ac_notify, >dev);
if (result)
goto err_unregister;
@@ -269,7 +263,7 @@ static int acpi_ac_add(struct acpi_device *device)
#ifdef CONFIG_PM_SLEEP
static int acpi_ac_resume(struct device *dev)
{
- struct acpi_ac *ac = acpi_driver_data(to_acpi_device(dev));
+ struct acpi_ac *ac = dev_get_drvdata(dev);
unsigned int old_state;
[PATCH v3 1/6] ACPI: AC: Remove unnecessary checks
Remove unnecessary checks for NULL for variables that can't be NULL at
the point they're checked for it. Defensive programming is discouraged
in the kernel.
Signed-off-by: Michal Wilczynski
---
drivers/acpi/ac.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index aac3e561790c..83d45c681121 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -131,9 +131,6 @@ static void acpi_ac_notify(acpi_handle handle, u32 event,
void *data)
struct acpi_device *device = data;
struct acpi_ac *ac = acpi_driver_data(device);
- if (!ac)
- return;
-
switch (event) {
default:
acpi_handle_debug(device->handle, "Unsupported event [0x%x]\n",
@@ -216,12 +213,8 @@ static const struct dmi_system_id ac_dmi_table[]
__initconst = {
static int acpi_ac_add(struct acpi_device *device)
{
struct power_supply_config psy_cfg = {};
- int result = 0;
- struct acpi_ac *ac = NULL;
-
-
- if (!device)
- return -EINVAL;
+ struct acpi_ac *ac;
+ int result;
ac = kzalloc(sizeof(struct acpi_ac), GFP_KERNEL);
if (!ac)
@@ -275,16 +268,9 @@ static int acpi_ac_add(struct acpi_device *device)
#ifdef CONFIG_PM_SLEEP
static int acpi_ac_resume(struct device *dev)
{
- struct acpi_ac *ac;
+ struct acpi_ac *ac = acpi_driver_data(to_acpi_device(dev));
unsigned int old_state;
- if (!dev)
- return -EINVAL;
-
- ac = acpi_driver_data(to_acpi_device(dev));
- if (!ac)
- return -EINVAL;
-
old_state = ac->state;
if (acpi_ac_get_state(ac))
return 0;
@@ -299,12 +285,7 @@ static int acpi_ac_resume(struct device *dev)
static void acpi_ac_remove(struct acpi_device *device)
{
- struct acpi_ac *ac = NULL;
-
- if (!device || !acpi_driver_data(device))
- return;
-
- ac = acpi_driver_data(device);
+ struct acpi_ac *ac = acpi_driver_data(device);
acpi_dev_remove_notify_handler(device, ACPI_ALL_NOTIFY,
acpi_ac_notify);
--
2.41.0
[PATCH v3 2/6] ACPI: AC: Use string_choices API instead of ternary operator
Use modern string_choices API instead of manually determining the
output using ternary operator.
Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Signed-off-by: Michal Wilczynski
---
drivers/acpi/ac.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index 83d45c681121..f809f6889b4a 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -243,8 +244,8 @@ static int acpi_ac_add(struct acpi_device *device)
goto err_release_ac;
}
- pr_info("%s [%s] (%s)\n", acpi_device_name(device),
- acpi_device_bid(device), ac->state ? "on-line" : "off-line");
+ pr_info("%s [%s] (%s-line)\n", acpi_device_name(device),
+ acpi_device_bid(device), str_on_off(ac->state));
ac->battery_nb.notifier_call = acpi_ac_battery_notify;
register_acpi_notifier(>battery_nb);
--
2.41.0
[PATCH v3 0/6] Replace acpi_driver with platform_driver
Currently there is a number of drivers that somewhat incorrectly register themselves as acpi_driver, while they should be registering as platform_drivers. acpi_device was never meant to represent actual device, it only represents an entry in the ACPI table and ACPI driver should be treated as a driver for the ACPI entry of the particular device, not the device itself. Drivers of the devices itself should register as platform_drivers. Replace acpi_driver with platform_driver for all relevant drivers in drivers/acpi directory. This is just the first part of the change, as many acpi_drivers are present in many files outside of drivers/acpi directory. Additionally during internal review we've decided that it's best to send the relevant patches sequentially, in order not to overwhelm the reviewers. So I'm starting with NFIT and AC drivers. This change is possible thanks to recent .notify callback removal in drivers/acpi [1]. So flow for the remaining acpi_drivers will look like this: 1) Remove .notify callback with separate patchset for drivers/platform and other outstanding places like drivers/hwmon, drivers/iio etc. 2) Replace acpi_driver with platform_driver, as aside for .notify callback they're mostly functionally compatible. Most of the patches in this series could be considered independent, and could be merged separately, with a notable exception of the very first patch in this series that changes notify installer wrappers to be more generic. I decided it would be best not to force the user of this wrappers to pass any specific structure, like acpi_device or platform_device. It makes sense as it is very often the case that drivers declare their own private structure which gets allocated during the .probe() callback, and become the heart of the driver. In that case it makes much more sense to pass this structure to notify handler. Additionally some drivers, like acpi_video that already have custom notify handlers do that already. Link: https://lore.kernel.org/linux-acpi/20230703080252.2899090-1-michal.wilczyn...@intel.com/ [1] v3: - in AC transformation patch replaced struct device* with struct acpi_device*, as suggested. v2: - dropped first, second and last commit. Last commit was deemed pointless, first and second are already merged. - rebased on top of modified first commit (changes in the wrappers) Michal Wilczynski (6): ACPI: AC: Remove unnecessary checks ACPI: AC: Use string_choices API instead of ternary operator ACPI: AC: Replace acpi_driver with platform_driver ACPI: AC: Rename ACPI device from device to adev ACPI: NFIT: Replace acpi_driver with platform_driver ACPI: NFIT: Remove redundant call to to_acpi_dev() drivers/acpi/ac.c| 103 +-- drivers/acpi/nfit/core.c | 38 +++ 2 files changed, 64 insertions(+), 77 deletions(-) -- 2.41.0
Re: [PATCH v3 0/7] sysctl: Remove sentinel elements from arch
On Tue, Oct 10, 2023 at 03:22:34PM -0700, Luis Chamberlain wrote: > On Mon, Oct 02, 2023 at 01:30:35PM +0200, Joel Granados via B4 Relay wrote: > > V3: > > * Removed the ia64 patch to avoid conflicts with the ia64 removal > > * Rebased onto v6.6-rc4 > > * Kept/added the trailing comma for the ctl_table arrays. This was a comment > > that we received "drivers/*" patch set. > > * Link to v2: > > https://lore.kernel.org/r/20230913-jag-sysctl_remove_empty_elem_arch-v2-0-d1bd13a29...@samsung.com > > Thanks! I replaced the v2 with this v3 on sysctl-next. perfect > > Luis -- Joel Granados signature.asc Description: PGP signature
[PATCH v2] module: Add CONFIG_MODULE_LOAD_IN_SEQUENCE option
When modprobe cmds are executed one by one, the final loaded modules
are not in fixed sequence as expected.
Add the option to make sure modules are in fixed sequence across reboot.
Signed-off-by: Joey Jiao
---
kernel/module/Kconfig | 11 +++
kernel/module/main.c | 3 ++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
index 33a2e991f608..b45a45f31d6d 100644
--- a/kernel/module/Kconfig
+++ b/kernel/module/Kconfig
@@ -389,4 +389,15 @@ config MODULES_TREE_LOOKUP
def_bool y
depends on PERF_EVENTS || TRACING || CFI_CLANG
+config MODULE_LOAD_IN_SEQUENCE
+ bool "Load module in sequence"
+ default n
+ help
+ By default, modules are loaded in random sequence depending on when
modprobe
+ is executed.
+
+ This option allows modules to be loaded in sequence if modprobe cmds
are
+ executed one by one in sequence. This option is helpful during
syzkaller fuzzing
+ to make sure module is loaded into fixed address across device reboot.
+
endif # MODULES
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 98fedfdb8db5..e238a31d09eb 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2594,7 +2594,8 @@ static noinline int do_init_module(struct module *mod)
* rcu_barrier()
*/
if (llist_add(>node, _free_list))
- schedule_work(_free_wq);
+ if (!IS_ENABLED(CONFIG_MODULE_LOAD_IN_SEQUENCE)) {
+ schedule_work(_free_wq);
mutex_unlock(_mutex);
wake_up_all(_wq);
--
2.42.0
Re: [PATCH 01/10] appletalk: remove localtalk and ppp support
> Il giorno 10 ott 2023, alle ore 10:15, Arnd Bergmann ha > scritto: > > On Tue, Oct 10, 2023, at 09:10, Rodolfo Zitellini wrote: >>> Il giorno 9 ott 2023, alle ore 19:29, Arnd Bergmann ha >>> scritto: >>> On Mon, Oct 9, 2023, at 18:49, Rodolfo Zitellini wrote: >>> I can see a few ways this could work out: >>> >>> - add a custom callback pointer to struct atalk_iface to >>> get and set the address for phase1 probing instead of going >>> through the ioctl >> >> This was my initial thought, at least for the moment, mostly to keep >> netatalk happy and make sure I don’t break other stuff that makes >> assumptions on how the address probing worked. There are other bits I >> would like to improve, for example tcpdump (which parses correctly >> appetalk packets!) is broken in the current implementation. >> >>> - rewrite the probing logic in aarp.c more widely, and improve >>> the userspace interface in the process by introducing a netlink >>> interface >> >> This is sorta the “second step” I was planning, I think the logic for >> probing could be redesigned and simplified (it also does not work 100% >> correctly), and it could be a good chance to improve the interface with >> netatalk too. > > Ok, I've adapted my patch now to not actually drop the > localtalk code for now, and sent that out, I hope that works > for you. Even if we go with the v1 patch that removes it all, > you could just as well start with a revert of my patch when > you add your driver, so in the end it shouldn't make much > of a difference. Thank you very much! I will try to make my patch ready to be submitted soon, and I will add the proper reverts if needed. >>> - Move your entire driver into userspace and go to the kernel >>> using tun/tap. This has the added benefit of avoiding a lot >>> of the complexity of the tty line discipline code you have. >> >> We had some discussion too if to just make the lt an userspace stack, I >> personally like how it is currently implemented because existing code >> can run basically without modification. >> >> I would propose at this stage to change the TashTalk driver to remove >> ndo_do_ioctl and to use a custom callback, if this ok. > > It looks like you still need a custom userspace tool to set up > the uart for your new driver, so my feeling would be that having a > userspace bridge to implement the localtalk/uart to ethertalk/tap > driver would actually be nicer for both usability and maintenance. > > It's not something we need to decide now though, and is up to > you in the end. I will experiment with this too, as it will require a bit of work to morph localtalk packets to ethertalk/aarp ones, and the code in the kernel has some specialized bits for localtalk here and there. In any case, many thanks! Rodolfo
Re: [PATCH] module: Add CONFIG_MODULE_LOAD_IN_SEQUENCE option
On Mon, Oct 09, 2023 at 10:26:35AM +0530, Joey Jiao wrote: > When modprobe cmds are executed one by one, the final loaded modules > are not in fixed sequence as expected. And why does this matter? If this is important enough to matter it should just be the default, and have really good reason for that. Doing something like this as a config option does not make any sense.
Re: [PATCH] module: Add CONFIG_MODULE_LOAD_IN_SEQUENCE option
Thanks Luis, will recheck these two points. On Tue, Oct 10, 2023 at 07:21:13PM -0700, Luis Chamberlain wrote: > Please find a good email client to reply to patches. > > On Wed, Oct 11, 2023 at 01:57:58AM +, Joey Jiao (QUIC) wrote: > > Hi Luis, > > > > > How is ignoring an error ensuring ordering? > > The change is just to disable the schedule_work. > > That's different and can be made clearer. Try: > > if (!IS_ENABLED(CONFIG_FOO)) > schedule_stuff > > > > Why are you making this only now be called with this new kconfig option? > > This sequence loading is especially helpful for syzkaller coverage decoding. > > When kaslr is disabled, address inside core kernel is fixed, so syzkaller > > can always get right function/line number from addr2line. > > But module address keeps change across rebooting, in first booting, it > > might be loaded at X1, and at X2 after reboot, and at X3 after another > > reboot. > > In this way, syzkaller just can't decode correctly for module address. And > > syzkaller currently uses PC and branch info for coverage guided things. > > > > There was a discussion previously here > > https://groups.google.com/g/syzkaller/c/1Pnm_BjrZO8/m/WOyAKx8ZAgAJ for > > modprobe. > > You are missing my point, you are disabling in effect a piece of code > where it was not before. > > Luis
