Re: [PATCH v2 0/2] get_maintainer: add patch-only keyword matching
On Fri, Sep 29, 2023 at 11:50 AM Joe Perches wrote: > > On Fri, 2023-09-29 at 11:07 +0900, Justin Stitt wrote: > > On Fri, Sep 29, 2023 at 12:52 AM Nick Desaulniers > > wrote: > > > > > > On Wed, Sep 27, 2023 at 11:09 PM Joe Perches wrote: > > > > > > > > On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote: > > > > > On Thu, Sep 28, 2023 at 2:01 PM Joe Perches wrote: > > > > > > > > > > > > On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote: > > > > > > > Changes in v2: > > > > > > > - remove formatting pass (thanks Joe) (but seriously the > > > > > > > formatting is > > > > > > > bad, is there opportunity to get a formatting pass in here at > > > > > > > some > > > > > > > point?) > > > > > > > > LG G7 Battery Replacement | Guide | Is it actually a Samsung? I t > > > > > > Why? What is it that makes you believe the formatting is bad? > > > > > > > > > > > > > > > > Investigating further, it looked especially bad in my editor. There is > > > > > a mixture of > > > > > tabs and spaces and my vim tabstop is set to 4 for pl files. Setting > > > > > this to > > > > > 8 is a whole lot better. But I still see some weird spacing > > > > > > > > > > > > > Yes, it's a bit odd indentation. > > > > It's emacs default perl format. > > > > 4 space indent with 8 space tabs, maximal tab fill. > > > > > > > > > > Oh! What?! That's the most surprising convention I've ever heard of > > > (after the GNU C coding style). Yet another thing to hold against > > > perl I guess. :P > > > > > > I have my editor setup to highlight tabs vs spaces via visual cues, so > > > that I don't mess up kernel coding style. (`git clang-format HEAD~` > > > after a commit helps). scripts/get_maintainer.pl has some serious > > > inconsistencies to the point where I'm not sure what it should or was > > > meant to be. Now that you mention it, I see it, and it does seem > > > consistent in that regard. > > > > > > Justin, is your formatter configurable to match that convention? > > > Maybe it's still useful, as long as you configure it to stick to the > > > pre-existing convention. > > > > Negative, all the perl formatters I've tried will convert everything to > > spaces. > > The best I've seen is perltidy. > > > > https://gist.github.com/JustinStitt/347385921c80a5212c2672075aa769b6 > > emacs with cperl mode works fine. > > I don't know much about vim, but when I open this file in vim > it looks perfectly normal and it's apparently properly syntax > highlighted. > I believe a :set tabstop=2 will make it look weird. But really, this whole formatting thing is a non-issue for me personally once I discovered what the problem was. I'm not sure this file attracts nearly enough eyes to warrant an eager formatting attempt as I was previously preaching for. Nick and I using vim with special tab handling are most definitely the exception and for most folks this file probably looks fine.
Re: [PATCH v2 0/2] get_maintainer: add patch-only keyword matching
On Fri, 2023-09-29 at 11:07 +0900, Justin Stitt wrote: > On Fri, Sep 29, 2023 at 12:52 AM Nick Desaulniers > wrote: > > > > On Wed, Sep 27, 2023 at 11:09 PM Joe Perches wrote: > > > > > > On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote: > > > > On Thu, Sep 28, 2023 at 2:01 PM Joe Perches wrote: > > > > > > > > > > On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote: > > > > > > Changes in v2: > > > > > > - remove formatting pass (thanks Joe) (but seriously the formatting > > > > > > is > > > > > > bad, is there opportunity to get a formatting pass in here at some > > > > > > point?) > > > > > LG G7 Battery Replacement | Guide | Is it actually a Samsung? I t > > > > > Why? What is it that makes you believe the formatting is bad? > > > > > > > > > > > > > Investigating further, it looked especially bad in my editor. There is > > > > a mixture of > > > > tabs and spaces and my vim tabstop is set to 4 for pl files. Setting > > > > this to > > > > 8 is a whole lot better. But I still see some weird spacing > > > > > > > > > > Yes, it's a bit odd indentation. > > > It's emacs default perl format. > > > 4 space indent with 8 space tabs, maximal tab fill. > > > > > > > Oh! What?! That's the most surprising convention I've ever heard of > > (after the GNU C coding style). Yet another thing to hold against > > perl I guess. :P > > > > I have my editor setup to highlight tabs vs spaces via visual cues, so > > that I don't mess up kernel coding style. (`git clang-format HEAD~` > > after a commit helps). scripts/get_maintainer.pl has some serious > > inconsistencies to the point where I'm not sure what it should or was > > meant to be. Now that you mention it, I see it, and it does seem > > consistent in that regard. > > > > Justin, is your formatter configurable to match that convention? > > Maybe it's still useful, as long as you configure it to stick to the > > pre-existing convention. > > Negative, all the perl formatters I've tried will convert everything to > spaces. > The best I've seen is perltidy. > > https://gist.github.com/JustinStitt/347385921c80a5212c2672075aa769b6 emacs with cperl mode works fine. I don't know much about vim, but when I open this file in vim it looks perfectly normal and it's apparently properly syntax highlighted.
Re: [PATCH v2 0/2] get_maintainer: add patch-only keyword matching
On Fri, Sep 29, 2023 at 12:52 AM Nick Desaulniers wrote: > > On Wed, Sep 27, 2023 at 11:09 PM Joe Perches wrote: > > > > On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote: > > > On Thu, Sep 28, 2023 at 2:01 PM Joe Perches wrote: > > > > > > > > On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote: > > > > > Changes in v2: > > > > > - remove formatting pass (thanks Joe) (but seriously the formatting is > > > > > bad, is there opportunity to get a formatting pass in here at some > > > > > point?) > > > > > > > > Why? What is it that makes you believe the formatting is bad? > > > > > > > > > > Investigating further, it looked especially bad in my editor. There is > > > a mixture of > > > tabs and spaces and my vim tabstop is set to 4 for pl files. Setting this > > > to > > > 8 is a whole lot better. But I still see some weird spacing > > > > > > > Yes, it's a bit odd indentation. > > It's emacs default perl format. > > 4 space indent with 8 space tabs, maximal tab fill. > > > > Oh! What?! That's the most surprising convention I've ever heard of > (after the GNU C coding style). Yet another thing to hold against > perl I guess. :P > > I have my editor setup to highlight tabs vs spaces via visual cues, so > that I don't mess up kernel coding style. (`git clang-format HEAD~` > after a commit helps). scripts/get_maintainer.pl has some serious > inconsistencies to the point where I'm not sure what it should or was > meant to be. Now that you mention it, I see it, and it does seem > consistent in that regard. > > Justin, is your formatter configurable to match that convention? > Maybe it's still useful, as long as you configure it to stick to the > pre-existing convention. Negative, all the perl formatters I've tried will convert everything to spaces. The best I've seen is perltidy. https://gist.github.com/JustinStitt/347385921c80a5212c2672075aa769b6 > -- > Thanks, > ~Nick Desaulniers
[PATCH] module: fix oops on loading module with malformed ELF section header
Hi, I encountered the following OOPS when loading a kernel module with insmod. It occurs when loading a kernel module with an invalid ELF section header - the Section name is invalid and out of bounds into the section name table. # insmod hello-1-boom.ko [41829.405681] BUG: unable to handle page fault for address: c9c3efa3 [41829.407111] #PF: supervisor read access in kernel mode [41829.408209] #PF: error_code(0x) - not-present page [41829.409328] PGD 10067 P4D 10067 PUD 10012a067 PMD 0 [41829.410593] Oops: [#1] PREEMPT SMP NOPTI [41829.411592] CPU: 5 PID: 146 Comm: insmod Not tainted 6.6.0-rc2-g8a511e7efc5a #14 [41829.412944] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [41829.413686] RIP: 0010:strcmp+0x10/0x40 [41829.413944] Code: cc cc cc cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 31 c0 66 2e 0f 1f 84 00 00 00 00 003 [41829.415135] RSP: 0018:c939fd50 EFLAGS: 00010246 [41829.415470] RAX: RBX: 0023 RCX: 0023 [41829.415978] RDX: c906de40 RSI: 82ca5bbc RDI: c9c3efa3 [41829.416443] RBP: 00bd1163 R08: c906d000 R09: 0fa8 [41829.416808] R10: 00031b20 R11: 8148bbe0 R12: 0001 [41829.417212] R13: 0001 R14: c9c3efa3 R15: c906e010 [41829.417556] FS: 7ff0c2f31740() GS:88813bd4() knlGS: [41829.417944] CS: 0010 DS: ES: CR0: 80050033 [41829.418219] CR2: c9c3efa3 CR3: 0001019d6001 CR4: 00770ee0 [41829.418560] PKRU: 5554 [41829.418693] Call Trace: [41829.418827] [41829.418935] ? __die_body+0x75/0xf0 [41829.419142] ? page_fault_oops+0x340/0x450 [41829.419338] ? do_kern_addr_fault+0xa1/0x140 [41829.419546] ? exc_page_fault+0x87/0x180 [41829.419741] ? asm_exc_page_fault+0x26/0x30 [41829.419943] ? __pfx_ext4_file_read_iter+0x10/0x10 [41829.420172] ? strcmp+0x10/0x40 [41829.420328] load_module+0x235/0x1a20 [41829.420506] __se_sys_finit_module+0x35e/0x4c0 [41829.420723] do_syscall_64+0x45/0xa0 [41829.420902] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [41829.421145] RIP: 0033:0x7ff0c2ffaf09 [41829.421320] Code: 8d 3d 03 d4 0b 00 e8 11 23 fa ff 89 e8 5a 5b 5d c3 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 058 [41829.422193] RSP: 002b:7ffda4a062b8 EFLAGS: 0246 ORIG_RAX: 0139 [41829.422550] RAX: ffda RBX: 56194469f2a0 RCX: 7ff0c2ffaf09 [41829.422890] RDX: RSI: 56194469f2a0 RDI: 0003 [41829.423227] RBP: 0003 R08: R09: 0020 [41829.423565] R10: R11: 0246 R12: 7ffda4a07f55 [41829.423906] R13: 7ff0c30faac0 R14: 7ffda4a064d0 R15: 7ff0c30fb000 [41829.424246] [41829.424355] Modules linked in: [41829.424507] CR2: c9c3efa3 [41829.424669] ---[ end trace ]--- [41829.424893] RIP: 0010:strcmp+0x10/0x40 [41829.425076] Code: cc cc cc cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 31 c0 66 2e 0f 1f 84 00 00 00 00 003 [41829.425948] RSP: 0018:c939fd50 EFLAGS: 00010246 [41829.426196] RAX: RBX: 0023 RCX: 0023 [41829.426534] RDX: c906de40 RSI: 82ca5bbc RDI: c9c3efa3 [41829.426874] RBP: 00bd1163 R08: c906d000 R09: 0fa8 [41829.427212] R10: 00031b20 R11: 8148bbe0 R12: 0001 [41829.427551] R13: 0001 R14: c9c3efa3 R15: c906e010 [41829.427891] FS: 7ff0c2f31740() GS:88813bd4() knlGS: [41829.428271] CS: 0010 DS: ES: CR0: 80050033 [41829.428545] CR2: c9c3efa3 CR3: 0001019d6001 CR4: 00770ee0 [41829.428887] PKRU: 5554 [41829.429021] note: insmod[146] exited with irqs disabled Killed == This happens because elf_validity_cache_copy does not validate the section name index before looking for the ".gnu.linkonce.this_module" and ".modinfo" sections while iterating through the section headers. This seems to have been introduced in the refactoring done in https://lkml.kernel.org/linux-modules/20230319213542.1790479-2-mcg...@kernel.org/ and in the kernel since v6.4. My patch below moves the search for the ".gnu.linkonce.this_module" and ".modinfo" sections after the check validating the section header name. Since both these sections are SHF_ALLOC, it should be okay to nest the check within that if - which is what was happening prior to the refactor too. I have tested that with the patch, loading a malformed kernel
Re: [PATCH v5 00/12] tracing: fprobe: rethook: Use ftrace_regs instead of pt_regs
Hi, While revising the LPC slides, I realized that this series is actually slightly going in the wrong direction. My goal is to unify "the shadow stack and the trampoline" for function exit tracing (function graph tracer and function return probe event), but not only unifying the internal interface. My original plan was to introduce an independent "interface" for the shadow stack and trampoline, which can switch the backend implementation. This was important because when I started that, there were kretprobe or function- graph tracer which hook the function exit. If kprobe depends on the function-graph tracer only for using the same shadow stack, that makes kprobe usability down. So I introduced "rethook" for the interface, which could be a wrapper interface of the shadow stacks and the trampolines. One my misread was the "pt_regs" issue. So this series is for fixing it. However, when I introduced "fprobe" for function entry and exit probe, this assumption has changed. If we move from kprobe/kretprobe to fprobe for function entry/exit probing (= function entry/exit probe event on ftrace), we don't need to care about the dependency of kprobes, because if "fprobe" already depends on function tracer. Maybe it can depends on function-graph tracer too. Thus, what I need is to make fprobe to use function-graph tracer's shadow stack and trampoline instead of rethook. This may need to generalize its interface so that we can share it between fprobe and function-graph tracer, but we don't need to involve rethook and kretprobes anymore. Note that this plan still requires changing the fprobe interface to use ftrace_regs, because some architecture doesn't support pt_regs on ftrace. Thus, I will keep the following patches from this series. (first 3 patches are fixes so to be sent independently) > - RISCV ftrace fix to save registers on struct ftrace_regs correctly. > - Document fix for the current fprobe callback prototype. > - Add a comment of requirement for the ftrace_regs. > - Simply replace pt_regs in fprobe_entry_handler with ftrace_regs. (this needs to be fixed) > - Expose ftrace_regs even if CONFIG_FUNCTION_TRACER=n. > - Introduce ftrace_partial_regs(). (This changes ARM64 which needs a custom >implementation) > - Introduce ftrace_fill_perf_regs() for perf pt_regs. > - Update fprobe-events to use ftrace_regs natively. > - Update bpf multi-kprobe handler use ftrace_partial_regs(). And need to add patches - Introduce a generized function exit hook interface for ftrace. - Replace rethook in fprobe with the function exit hook interface. Thank you, On Sun, 24 Sep 2023 22:35:47 +0900 "Masami Hiramatsu (Google)" wrote: > Hi, > > Here is the 5th version of the series to use ftrace_regs instead of pt_regs > in fprobe. > The previous version is here; > > https://lore.kernel.org/all/169280372795.282662.9784422934484459769.stgit@devnote2/ > > In this version, I decided to use perf's own per-cpu pt_regs array to > copy the required registers[8/12]. Thus this version adds a patch which > adds a new ftrace_fill_perf_regs() API. So the ftrace_partial_regs() will > be used for BPF and ftrace_fill_perf_regs() is used for perf events. > > This also adds a fix for RISCV ftrace[1/12]. When kernel is built with > disabling CONFIG_DYNAMIC_FTRACE_WITH_REGS on RISCV, it stores partial > registers on the stack, but it doesn't make it fit to struct ftrace_regs. > But since the 4th argument of ftrace_func_t is ftrace_regs *, it breaks > the ABI. So fixing it to save registers on ftrace_regs (== pt_regs on RISCV). > > Another new patch [3/12] is adding a comment about the requirements for > the ftrace_regs. > > - RISCV ftrace fix to save registers on struct ftrace_regs correctly. > - Document fix for the current fprobe callback prototype. > - Add a comment of requirement for the ftrace_regs. > - Simply replace pt_regs in fprobe_entry_handler with ftrace_regs. > - Expose ftrace_regs even if CONFIG_FUNCTION_TRACER=n. > - Introduce ftrace_partial_regs(). (This changes ARM64 which needs a custom >implementation) > - Introduce ftrace_fill_perf_regs() for perf pt_regs. > - Replace pt_regs in rethook and fprobe_exit_handler with ftrace_regs. This >introduce a new HAVE_PT_REGS_TO_FTRACE_REGS_CAST which means ftrace_regs is >just a wrapper of pt_regs (except for arm64, other architectures do this) > - Update fprobe-events to use ftrace_regs natively. > - Update bpf multi-kprobe handler use ftrace_partial_regs(). > - Update document for new fprobe callbacks. > - Add notes for the $argN and $retval. > > This series can be applied against the trace-v6.6-rc2 on linux-trace tree. > > This series can also be found below branch. > > https://git.kernel.org/pub/scm/linux/kernel/git/mhiramat/linux.git/log/?h=topic/fprobe-ftrace-regs > > Thank you, > > --- > > Masami Hiramatsu (Google) (12): > riscv: ftrace: Fix to pass correct ftrace_regs to ftrace_func_t > functions >
Re: [PATCH v6] x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race
Hi Dave, On 9/28/2023 5:11 PM, Dave Hansen wrote: > On 9/28/23 16:08, Reinette Chatre wrote: >> I'd like to check in on the status of this patch. This two month old >> patch looks to be a needed fix and has Jarkko and Kai's review tags, >> but I am not able to find it queued or merged in tip or upstream. >> Apologies if I did not look in the right spot, I just want to make >> sure it did not fall through the cracks if deemed needed. > > It fell through the cracks. Sorry about that. It's in x86/urgent now. No problem. Thank you very much for including it. Reinette
Re: [PATCH v6] x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race
On 9/28/23 16:08, Reinette Chatre wrote: > I'd like to check in on the status of this patch. This two month old > patch looks to be a needed fix and has Jarkko and Kai's review tags, > but I am not able to find it queued or merged in tip or upstream. > Apologies if I did not look in the right spot, I just want to make > sure it did not fall through the cracks if deemed needed. It fell through the cracks. Sorry about that. It's in x86/urgent now.
Re: [PATCH v6] x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race
Hi Everybody,
I'd like to check in on the status of this patch. This two month old
patch looks to be a needed fix and has Jarkko and Kai's review tags,
but I am not able to find it queued or merged in tip or upstream.
Apologies if I did not look in the right spot, I just want to make
sure it did not fall through the cracks if deemed needed.
Reinette
On 7/27/2023 10:10 PM, Haitao Huang wrote:
> The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an
> enclave and set secs.epc_page to NULL. The SECS page is used for EAUG
> and ELDU in the SGX page fault handler. However, the NULL check for
> secs.epc_page is only done for ELDU, not EAUG before being used.
>
> Fix this by doing the same NULL check and reloading of the SECS page as
> needed for both EAUG and ELDU.
>
> The SECS page holds global enclave metadata. It can only be reclaimed
> when there are no other enclave pages remaining. At that point,
> virtually nothing can be done with the enclave until the SECS page is
> paged back in.
>
> An enclave can not run nor generate page faults without a resident SECS
> page. But it is still possible for a #PF for a non-SECS page to race
> with paging out the SECS page: when the last resident non-SECS page A
> triggers a #PF in a non-resident page B, and then page A and the SECS
> both are paged out before the #PF on B is handled.
>
> Hitting this bug requires that race triggered with a #PF for EAUG.
> Following is a trace when it happens.
>
> BUG: kernel NULL pointer dereference, address:
> RIP: 0010:sgx_encl_eaug_page+0xc7/0x210
> Call Trace:
> ? __kmem_cache_alloc_node+0x16a/0x440
> ? xa_load+0x6e/0xa0
> sgx_vma_fault+0x119/0x230
> __do_fault+0x36/0x140
> do_fault+0x12f/0x400
> __handle_mm_fault+0x728/0x1110
> handle_mm_fault+0x105/0x310
> do_user_addr_fault+0x1ee/0x750
> ? __this_cpu_preempt_check+0x13/0x20
> exc_page_fault+0x76/0x180
> asm_exc_page_fault+0x27/0x30
>
> Fixes: 5a90d2c3f5ef ("x86/sgx: Support adding of pages to an initialized
> enclave")
> Cc: sta...@vger.kernel.org # v6.0+
> Signed-off-by: Haitao Huang
> Reviewed-by: Jarkko Sakkinen
> Reviewed-by: Kai Huang
> Acked-by: Reinette Chatre
> ---
> v6:
> - Removed 'Under heavy load' as it is not the required condition though
> it makes the bug more likely happen. (Kai)
> - Added mentioning of the NULL check and reloading already done for ELDU (Kai)
> - Added Reviewed-by (Kai)
>
> v5:
> - Trimmed trace and added Acked-by (Reinette)
>
> v4:
> - Refined the title (Kai, Dave)
> - Added a trace to commit meesage (Kai)
> - Added a few details for the race.
>
> v3:
> - Added comments on sgx_encl_load_secs(). (Dave)
> - Added theory of the race condition to hit the bug. (Dave)
> - Added Reviewed-by, and applicable stable release. (Jarkko)
>
> v2:
> - Fixes for style, commit message (Jarkko, Kai)
> - Removed unneeded WARN_ON (Kai)
> ---
> arch/x86/kernel/cpu/sgx/encl.c | 30 +-
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> index 91fa70e51004..279148e72459 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -235,6 +235,21 @@ static struct sgx_epc_page *sgx_encl_eldu(struct
> sgx_encl_page *encl_page,
> return epc_page;
> }
>
> +/*
> + * Ensure the SECS page is not swapped out. Must be called with encl->lock
> + * to protect the enclave states including SECS and ensure the SECS page is
> + * not swapped out again while being used.
> + */
> +static struct sgx_epc_page *sgx_encl_load_secs(struct sgx_encl *encl)
> +{
> + struct sgx_epc_page *epc_page = encl->secs.epc_page;
> +
> + if (!epc_page)
> + epc_page = sgx_encl_eldu(>secs, NULL);
> +
> + return epc_page;
> +}
> +
> static struct sgx_encl_page *__sgx_encl_load_page(struct sgx_encl *encl,
> struct sgx_encl_page *entry)
> {
> @@ -248,11 +263,9 @@ static struct sgx_encl_page *__sgx_encl_load_page(struct
> sgx_encl *encl,
> return entry;
> }
>
> - if (!(encl->secs.epc_page)) {
> - epc_page = sgx_encl_eldu(>secs, NULL);
> - if (IS_ERR(epc_page))
> - return ERR_CAST(epc_page);
> - }
> + epc_page = sgx_encl_load_secs(encl);
> + if (IS_ERR(epc_page))
> + return ERR_CAST(epc_page);
>
> epc_page = sgx_encl_eldu(entry, encl->secs.epc_page);
> if (IS_ERR(epc_page))
> @@ -339,6 +352,13 @@ static vm_fault_t sgx_encl_eaug_page(struct
> vm_area_struct *vma,
>
> mutex_lock(>lock);
>
> + epc_page = sgx_encl_load_secs(encl);
> + if (IS_ERR(epc_page)) {
> + if (PTR_ERR(epc_page) == -EBUSY)
> + vmret = VM_FAULT_NOPAGE;
> + goto err_out_unlock;
> + }
> +
> epc_page = sgx_alloc_epc_page(encl_page, false);
> if (IS_ERR(epc_page)) {
> if
Re: [PATCH v4 2/2] leds: add ktd202x driver
Hi Lee Jones,
Am Donnerstag, dem 28.09.2023 um 15:42 +0100 schrieb Lee Jones:
> On Sat, 23 Sep 2023, André Apitzsch wrote:
>
> > This commit adds support for Kinetic KTD2026/7 RGB/White LED
> > driver.
> >
> > Signed-off-by: André Apitzsch
> > ---
> > drivers/leds/rgb/Kconfig | 13 +
> > drivers/leds/rgb/Makefile | 1 +
> > drivers/leds/rgb/leds-ktd202x.c | 625
> >
> > 3 files changed, 639 insertions(+)
> >
> > diff --git a/drivers/leds/rgb/Kconfig b/drivers/leds/rgb/Kconfig
> > index 183bccc06cf3..a6a21f564673 100644
> > --- a/drivers/leds/rgb/Kconfig
> > +++ b/drivers/leds/rgb/Kconfig
> > @@ -14,6 +14,19 @@ config LEDS_GROUP_MULTICOLOR
> > To compile this driver as a module, choose M here: the
> > module
> > will be called leds-group-multicolor.
> >
> > +config LEDS_KTD202X
> > + tristate "LED support for KTD202x Chips"
> > + depends on I2C
> > + depends on OF
> > + select REGMAP_I2C
> > + help
> > + This option enables support for the Kinetic
> > KTD2026/KTD2027
> > + RGB/White LED driver found in different BQ mobile phones.
> > + It is a 3 or 4 channel LED driver programmed via an I2C
> > interface.
> > +
> > + To compile this driver as a module, choose M here: the
> > module
> > + will be called leds-ktd202x.
> > +
> > config LEDS_PWM_MULTICOLOR
> > tristate "PWM driven multi-color LED Support"
> > depends on PWM
> > diff --git a/drivers/leds/rgb/Makefile b/drivers/leds/rgb/Makefile
> > index c11cc56384e7..243f31e4d70d 100644
> > --- a/drivers/leds/rgb/Makefile
> > +++ b/drivers/leds/rgb/Makefile
> > @@ -1,6 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0
> >
> > obj-$(CONFIG_LEDS_GROUP_MULTICOLOR)+= leds-group-multicolor.o
> > +obj-$(CONFIG_LEDS_KTD202X) += leds-ktd202x.o
> > obj-$(CONFIG_LEDS_PWM_MULTICOLOR) += leds-pwm-multicolor.o
> > obj-$(CONFIG_LEDS_QCOM_LPG)+= leds-qcom-lpg.o
> > obj-$(CONFIG_LEDS_MT6370_RGB) += leds-mt6370-rgb.o
> > diff --git a/drivers/leds/rgb/leds-ktd202x.c
> > b/drivers/leds/rgb/leds-ktd202x.c
> > new file mode 100644
> > index ..b328ecd34664
> > --- /dev/null
> > +++ b/drivers/leds/rgb/leds-ktd202x.c
> > @@ -0,0 +1,625 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Kinetic KTD2026/7 RGB/White LED driver with I2C interface
> > + *
> > + * Copyright 2023 André Apitzsch
> > + *
> > + * Datasheet: https://www.kinet-ic.com/uploads/KTD2026-7-04h.pdf
> > + */
> > +
> > [..]
> > +
> > +static int ktd202x_probe_dt(struct ktd202x *chip)
> > +{
> > + struct device_node *np = dev_of_node(chip->dev), *child;
> > + unsigned int i;
> > + int count, ret;
> > +
> > + chip->num_leds = (int)(unsigned
> > long)of_device_get_match_data(chip->dev);
>
> There are a bunch of recent patches converting these to:
>
> i2c_get_match_data()
>
> ... is that also applicable here?
>
I don't think there is a benefit in using it here.
i2c_get_match_data() requires a "struct i2c_client client", so we would
have to pass that to ktd202x_probe_dt().
Only to replace
chip->num_leds = (int)(unsigned long)of_device_get_match_data(chip->dev);
by
chip->num_leds = (int)(unsigned long)i2c_get_match_data(client);
Best regards,
André
> > + count = of_get_available_child_count(np);
> > + if (!count || count > chip->num_leds)
> > + return -EINVAL;
> > +
> > + regmap_write(chip->regmap, KTD202X_REG_RESET_CONTROL,
> > + KTD202X_RSTR_RESET);
> > +
> > + /* Allow the device to execute the complete reset */
> > + usleep_range(200, 300);
> > +
> > + i = 0;
> > + for_each_available_child_of_node(np, child) {
> > + ret = ktd202x_add_led(chip, child, i);
> > + if (ret)
> > + return ret;
> > + i++;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static const struct regmap_config ktd202x_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .max_register = 0x09,
> > + .cache_type = REGCACHE_FLAT,
> > + .reg_defaults = ktd202x_reg_defaults,
> > + .num_reg_defaults = ARRAY_SIZE(ktd202x_reg_defaults),
> > +};
> > +
> > +static int ktd202x_probe(struct i2c_client *client)
> > +{
> > + struct device *dev = >dev;
> > + struct ktd202x *chip;
> > + int count;
> > + int ret;
> > +
> > + count = device_get_child_node_count(dev);
> > + if (!count || count > KTD202X_MAX_LEDS)
> > + return dev_err_probe(dev, -EINVAL,
> > + "Incorrect number of leds
> > (%d)", count);
> > +
> > + chip = devm_kzalloc(dev, struct_size(chip, leds, count),
> > GFP_KERNEL);
> > + if (!chip)
> > + return -ENOMEM;
> > +
> > + mutex_init(>mutex);
> > +
> > +
Re: [PATCH] dt-bindings: remoteproc: mtk,scp: Add missing additionalProperties on child node schemas
On Thu, Sep 28, 2023 at 2:31 PM Mathieu Poirier wrote: > > Hi Rob, > > On Tue, Sep 26, 2023 at 11:45:08AM -0500, Rob Herring wrote: > > Just as unevaluatedProperties or additionalProperties are required at > > the top level of schemas, they should (and will) also be required for > > child node schemas. That ensures only documented properties are > > present for any node. > > > > Signed-off-by: Rob Herring > > --- > > Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > > index 895415772d1d..24422fd56e83 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > > @@ -91,6 +91,7 @@ allOf: > > > > additionalProperties: > >type: object > > + additionalProperties: false > > Things have changed in the remoteproc tree [1] and this patch doesn't apply. > Please see if it is still needed. It is not needed any more. Thanks, Rob
[PATCH v4 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory
Large amounts of memory managed by the kmem driver may come in via CXL,
and it is often desirable to have the memmap for this memory on the new
memory itself.
Enroll kmem-managed memory for memmap_on_memory semantics if the dax
region originates via CXL. For non-CXL dax regions, retain the existing
default behavior of hot adding without memmap_on_memory semantics.
Add a sysfs override under the dax device to control this behavior and
override either default.
Cc: Andrew Morton
Cc: David Hildenbrand
Cc: Michal Hocko
Cc: Oscar Salvador
Cc: Dan Williams
Cc: Dave Jiang
Cc: Dave Hansen
Cc: Huang Ying
Reviewed-by: Jonathan Cameron
Signed-off-by: Vishal Verma
---
drivers/dax/bus.h | 1 +
drivers/dax/dax-private.h | 1 +
drivers/dax/bus.c | 38 ++
drivers/dax/cxl.c | 1 +
drivers/dax/hmem/hmem.c | 1 +
drivers/dax/kmem.c| 8 +++-
drivers/dax/pmem.c| 1 +
7 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/dax/bus.h b/drivers/dax/bus.h
index 1ccd23360124..cbbf64443098 100644
--- a/drivers/dax/bus.h
+++ b/drivers/dax/bus.h
@@ -23,6 +23,7 @@ struct dev_dax_data {
struct dev_pagemap *pgmap;
resource_size_t size;
int id;
+ bool memmap_on_memory;
};
struct dev_dax *devm_create_dev_dax(struct dev_dax_data *data);
diff --git a/drivers/dax/dax-private.h b/drivers/dax/dax-private.h
index 27cf2d79..446617b73aea 100644
--- a/drivers/dax/dax-private.h
+++ b/drivers/dax/dax-private.h
@@ -70,6 +70,7 @@ struct dev_dax {
struct ida ida;
struct device dev;
struct dev_pagemap *pgmap;
+ bool memmap_on_memory;
int nr_range;
struct dev_dax_range {
unsigned long pgoff;
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 0ee96e6fc426..81351eb69884 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -367,6 +367,7 @@ static ssize_t create_store(struct device *dev, struct
device_attribute *attr,
.dax_region = dax_region,
.size = 0,
.id = -1,
+ .memmap_on_memory = false,
};
struct dev_dax *dev_dax = devm_create_dev_dax();
@@ -1269,6 +1270,40 @@ static ssize_t numa_node_show(struct device *dev,
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sprintf(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ struct dax_region *dax_region = dev_dax->region;
+ ssize_t rc;
+ bool val;
+
+ rc = kstrtobool(buf, );
+ if (rc)
+ return rc;
+
+ device_lock(dax_region->dev);
+ if (!dax_region->dev->driver) {
+ device_unlock(dax_region->dev);
+ return -ENXIO;
+ }
+
+ dev_dax->memmap_on_memory = val;
+
+ device_unlock(dax_region->dev);
+ return rc == 0 ? len : rc;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int
n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1295,6 +1330,7 @@ static struct attribute *dev_dax_attributes[] = {
_attr_align.attr,
_attr_resource.attr,
_attr_numa_node.attr,
+ _attr_memmap_on_memory.attr,
NULL,
};
@@ -1400,6 +1436,8 @@ struct dev_dax *devm_create_dev_dax(struct dev_dax_data
*data)
dev_dax->align = dax_region->align;
ida_init(_dax->ida);
+ dev_dax->memmap_on_memory = data->memmap_on_memory;
+
inode = dax_inode(dax_dev);
dev->devt = inode->i_rdev;
dev->bus = _bus_type;
diff --git a/drivers/dax/cxl.c b/drivers/dax/cxl.c
index 8bc9d04034d6..c696837ab23c 100644
--- a/drivers/dax/cxl.c
+++ b/drivers/dax/cxl.c
@@ -26,6 +26,7 @@ static int cxl_dax_region_probe(struct device *dev)
.dax_region = dax_region,
.id = -1,
.size = range_len(_dax->hpa_range),
+ .memmap_on_memory = true,
};
return PTR_ERR_OR_ZERO(devm_create_dev_dax());
diff --git a/drivers/dax/hmem/hmem.c b/drivers/dax/hmem/hmem.c
index 5d2ddef0f8f5..b9da69f92697 100644
--- a/drivers/dax/hmem/hmem.c
+++ b/drivers/dax/hmem/hmem.c
@@ -36,6 +36,7 @@ static int dax_hmem_probe(struct platform_device *pdev)
.dax_region = dax_region,
.id = -1,
.size = region_idle ? 0 : range_len(>range),
+ .memmap_on_memory = false,
};
return
[PATCH v4 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks
The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to
'memblock_size' chunks of memory being added. Adding a larger span of
memory precludes memmap_on_memory semantics.
For users of hotplug such as kmem, large amounts of memory might get
added from the CXL subsystem. In some cases, this amount may exceed the
available 'main memory' to store the memmap for the memory being added.
In this case, it is useful to have a way to place the memmap on the
memory being added, even if it means splitting the addition into
memblock-sized chunks.
Change add_memory_resource() to loop over memblock-sized chunks of
memory if caller requested memmap_on_memory, and if other conditions for
it are met. Teach try_remove_memory() to also expect that a memory
range being removed might have been split up into memblock sized chunks,
and to loop through those as needed.
Cc: Andrew Morton
Cc: David Hildenbrand
Cc: Michal Hocko
Cc: Oscar Salvador
Cc: Dan Williams
Cc: Dave Jiang
Cc: Dave Hansen
Cc: Huang Ying
Suggested-by: David Hildenbrand
Signed-off-by: Vishal Verma
---
mm/memory_hotplug.c | 165 +++-
1 file changed, 100 insertions(+), 65 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index f8d3e7427e32..43dbd71a4910 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1380,6 +1380,44 @@ static bool mhp_supports_memmap_on_memory(unsigned long
size)
return arch_supports_memmap_on_memory(vmemmap_size);
}
+static int add_memory_create_devices(int nid, struct memory_group *group,
+u64 start, u64 size, mhp_t mhp_flags)
+{
+ struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) };
+ struct vmem_altmap mhp_altmap = {
+ .base_pfn = PHYS_PFN(start),
+ .end_pfn = PHYS_PFN(start + size - 1),
+ };
+ int ret;
+
+ if ((mhp_flags & MHP_MEMMAP_ON_MEMORY)) {
+ mhp_altmap.free = memory_block_memmap_on_memory_pages();
+ params.altmap = kmalloc(sizeof(struct vmem_altmap), GFP_KERNEL);
+ if (!params.altmap)
+ return -ENOMEM;
+
+ memcpy(params.altmap, _altmap, sizeof(mhp_altmap));
+ }
+
+ /* call arch's memory hotadd */
+ ret = arch_add_memory(nid, start, size, );
+ if (ret < 0)
+ goto error;
+
+ /* create memory block devices after memory was added */
+ ret = create_memory_block_devices(start, size, params.altmap, group);
+ if (ret)
+ goto err_bdev;
+
+ return 0;
+
+err_bdev:
+ arch_remove_memory(start, size, NULL);
+error:
+ kfree(params.altmap);
+ return ret;
+}
+
/*
* NOTE: The caller must call lock_device_hotplug() to serialize hotplug
* and online/offline operations (triggered e.g. by sysfs).
@@ -1388,14 +1426,10 @@ static bool mhp_supports_memmap_on_memory(unsigned long
size)
*/
int __ref add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
{
- struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) };
+ unsigned long memblock_size = memory_block_size_bytes();
enum memblock_flags memblock_flags = MEMBLOCK_NONE;
- struct vmem_altmap mhp_altmap = {
- .base_pfn = PHYS_PFN(res->start),
- .end_pfn = PHYS_PFN(res->end),
- };
struct memory_group *group = NULL;
- u64 start, size;
+ u64 start, size, cur_start;
bool new_node = false;
int ret;
@@ -1436,28 +1470,21 @@ int __ref add_memory_resource(int nid, struct resource
*res, mhp_t mhp_flags)
/*
* Self hosted memmap array
*/
- if (mhp_flags & MHP_MEMMAP_ON_MEMORY) {
- if (mhp_supports_memmap_on_memory(size)) {
- mhp_altmap.free = memory_block_memmap_on_memory_pages();
- params.altmap = kmalloc(sizeof(struct vmem_altmap),
GFP_KERNEL);
- if (!params.altmap)
+ if ((mhp_flags & MHP_MEMMAP_ON_MEMORY) &&
+ mhp_supports_memmap_on_memory(memblock_size)) {
+ for (cur_start = start; cur_start < start + size;
+cur_start += memblock_size) {
+ ret = add_memory_create_devices(nid, group, cur_start,
+ memblock_size,
+ mhp_flags);
+ if (ret)
goto error;
-
- memcpy(params.altmap, _altmap, sizeof(mhp_altmap));
}
- /* fallback to not using altmap */
- }
-
- /* call arch's memory hotadd */
- ret = arch_add_memory(nid, start, size, );
- if (ret < 0)
- goto error_free;
-
- /* create memory block devices after memory was added */
- ret =
[PATCH v4 0/2] mm: use memmap_on_memory semantics for dax/kmem
The dax/kmem driver can potentially hot-add large amounts of memory originating from CXL memory expanders, or NVDIMMs, or other 'device memories'. There is a chance there isn't enough regular system memory available to fit the memmap for this new memory. It's therefore desirable, if all other conditions are met, for the kmem managed memory to place its memmap on the newly added memory itself. The main hurdle for accomplishing this for kmem is that memmap_on_memory can only be done if the memory being added is equal to the size of one memblock. To overcome this, allow the hotplug code to split an add_memory() request into memblock-sized chunks, and try_remove_memory() to also expect and handle such a scenario. Patch 1 teaches the memory_hotplug code to allow for splitting add_memory() and remove_memory() requests over memblock sized chunks. Patch 2 adds a sysfs control for the kmem driver that would allow an opt-out of using memmap_on_memory for the memory being added. Signed-off-by: Vishal Verma --- Changes in v4: - Rebase to Aneesh's PPC64 memmap_on_memory series v8 [2]. - Tweak a goto / error path in add_memory_create_devices() (Jonathan) - Retain the old behavior for dax devices, only default to memmap_on_memory for CXL (Jonathan) - Link to v3: https://lore.kernel.org/r/20230801-vv-kmem_memmap-v3-0-406e9aaf5...@intel.com [2]: https://lore.kernel.org/linux-mm/20230808091501.287660-1-aneesh.ku...@linux.ibm.com Changes in v3: - Rebase on Aneesh's patches [1] - Drop Patch 1 - it is not needed since [1] allows for dynamic setting of the memmap_on_memory param (David) - Link to v2: https://lore.kernel.org/r/20230720-vv-kmem_memmap-v2-0-88bdaab34...@intel.com [1]: https://lore.kernel.org/r/20230801044116.10674-1-aneesh.ku...@linux.ibm.com Changes in v2: - Drop the patch to create an override path for the memmap_on_memory module param (David) - Move the chunking into memory_hotplug.c so that any caller of add_memory() can request this behavior. (David) - Handle remove_memory() too. (David, Ying) - Add a sysfs control in the kmem driver for memmap_on_memory semantics (David, Jonathan) - Add a #else case to define mhp_supports_memmap_on_memory() if CONFIG_MEMORY_HOTPLUG is unset. (0day report) - Link to v1: https://lore.kernel.org/r/20230613-vv-kmem_memmap-v1-0-f6de9c6af...@intel.com --- Vishal Verma (2): mm/memory_hotplug: split memmap_on_memory requests across memblocks dax/kmem: allow kmem to add memory with memmap_on_memory drivers/dax/bus.h | 1 + drivers/dax/dax-private.h | 1 + drivers/dax/bus.c | 38 +++ drivers/dax/cxl.c | 1 + drivers/dax/hmem/hmem.c | 1 + drivers/dax/kmem.c| 8 ++- drivers/dax/pmem.c| 1 + mm/memory_hotplug.c | 165 -- 8 files changed, 150 insertions(+), 66 deletions(-) --- base-commit: 25b5b1a0646c3d39e1d885e27c10be1c9e202bf2 change-id: 20230613-vv-kmem_memmap-5483c8d04279 Best regards, -- Vishal Verma
Re: [PATCH] dt-bindings: remoteproc: mtk,scp: Add missing additionalProperties on child node schemas
Hi Rob, On Tue, Sep 26, 2023 at 11:45:08AM -0500, Rob Herring wrote: > Just as unevaluatedProperties or additionalProperties are required at > the top level of schemas, they should (and will) also be required for > child node schemas. That ensures only documented properties are > present for any node. > > Signed-off-by: Rob Herring > --- > Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > index 895415772d1d..24422fd56e83 100644 > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > @@ -91,6 +91,7 @@ allOf: > > additionalProperties: >type: object > + additionalProperties: false Things have changed in the remoteproc tree [1] and this patch doesn't apply. Please see if it is still needed. Thanks, Mathieu [1]. https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git/tree/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml?h=rproc-next#n80 >description: > Subnodes of the SCP represent rpmsg devices. The names of the devices > are not important. The properties of these nodes are defined by the > -- > 2.40.1 >
Re: [PATCH v2 1/2] get_maintainer: add patch-only keyword-matching
On Wed, Sep 27, 2023 at 10:08:33PM -0700, Joe Perches wrote: > > This could all be a moot point, though, as I believe Konstantin > > is trying to separate out the whole idea of a patch-sender needing > > to specify the recipients of a patch. > > As I understand it, by using get_maintainer. Correct, we will ultimately still defer to get_maintainer to figure out who needs to be added. -K
Re: [PATCH 1/1] rpmsg: virtio: Make buffer size and number configurable
Hello,
Thanks for your patch.
Instead of having this in Kconfig, It's better to have buffer size decided
dynamically. Probably by resource-table.
We still need implementation that achieves that goal. Meanwhile I think it's
best to keep buffer size fixed.
Thanks.
On 9/28/23 10:38 AM, Divin Raj wrote:
> CAUTION: This message has originated from an External Source. Please use
> proper judgment and caution when opening attachments, clicking links, or
> responding to this email.
>
>
> From: Peter Hoyes
>
> Replace the MAX_RPMSG_BUF_SIZE and MAX_RPMSG_NUM_BUFS #define in
> virtio_rpmsg_bus.c with the Kconfig parameters CONFIG_RPMSG_VIRTIO_BUF_SIZE
> and CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS, allowing user-provided customization.
>
> Making both the number of buffers and size configurable facilitates aligning
> memory requirements between vdev-buffer and vdev-vrings for client drivers
> that require larger buffer sizes, for example.
>
> Signed-off-by: Peter Hoyes
> Signed-off-by: Divin Raj
> ---
> drivers/rpmsg/Kconfig| 23 +++
> drivers/rpmsg/virtio_rpmsg_bus.c | 27 +++
> 2 files changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index d3795860f5c0..677f4a1ac8bb 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -81,4 +81,27 @@ config RPMSG_VIRTIO
> select RPMSG_NS
> select VIRTIO
>
> +config RPMSG_VIRTIO_MAX_BUF_SIZE
> + int "Virtio RPMSG max buffer size (in bytes)"
> + default 512
> + depends on RPMSG_VIRTIO
> + help
> + This option allows you to configure the maximum buffer size (in
> bytes)
> + for Virtio RPMSG communications. The number of buffers will be
> computed
> + based on the number of buffers (CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS)
> + supported by the vring. By default, it supports up to a maximum of
> 512
> + buffers (256 in each direction). Each buffer consists of 16 bytes
> for the
> + message header and the remaining bytes for the payload.The default
> values
> + will utilize a maximum total space of 256KB for the buffers.
> +
> +config RPMSG_VIRTIO_MAX_NUM_BUFS
> + int "Virtio RPMSG max buffer count (even number for TX and Rx)"
> + default 512
> + depends on RPMSG_VIRTIO
> + help
> + This option allows you to configure the maximum number of buffers
> used
> + for Virtio RPMSG communication. By default, it supports up to a
> maximum
> + of 512 buffers (256 in each direction). Please note that this value
> + should be an even number, as it accounts for both transmit (TX) and
> + receive (Rx) buffers.
> endmenu
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 905ac7910c98..87a9a4fa30e0 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -109,27 +109,6 @@ struct virtio_rpmsg_channel {
> #define to_virtio_rpmsg_channel(_rpdev) \
> container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
>
> -/*
> - * We're allocating buffers of 512 bytes each for communications. The
> - * number of buffers will be computed from the number of buffers supported
> - * by the vring, upto a maximum of 512 buffers (256 in each direction).
> - *
> - * Each buffer will have 16 bytes for the msg header and 496 bytes for
> - * the payload.
> - *
> - * This will utilize a maximum total space of 256KB for the buffers.
> - *
> - * We might also want to add support for user-provided buffers in time.
> - * This will allow bigger buffer size flexibility, and can also be used
> - * to achieve zero-copy messaging.
> - *
> - * Note that these numbers are purely a decision of this driver - we
> - * can change this without changing anything in the firmware of the remote
> - * processor.
> - */
> -#define MAX_RPMSG_NUM_BUFS (512)
> -#define MAX_RPMSG_BUF_SIZE (512)
> -
> /*
> * Local addresses are dynamically allocated on-demand.
> * We do not dynamically assign addresses from the low 1024 range,
> @@ -902,12 +881,12 @@ static int rpmsg_probe(struct virtio_device *vdev)
> virtqueue_get_vring_size(vrp->svq));
>
> /* we need less buffers if vrings are small */
> - if (virtqueue_get_vring_size(vrp->rvq) < MAX_RPMSG_NUM_BUFS / 2)
> + if (virtqueue_get_vring_size(vrp->rvq) <
> CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS / 2)
> vrp->num_bufs = virtqueue_get_vring_size(vrp->rvq) * 2;
> else
> - vrp->num_bufs = MAX_RPMSG_NUM_BUFS;
> + vrp->num_bufs = CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS;
>
> - vrp->buf_size = MAX_RPMSG_BUF_SIZE;
> + vrp->buf_size = CONFIG_RPMSG_VIRTIO_MAX_BUF_SIZE;
>
> total_buf_space = vrp->num_bufs * vrp->buf_size;
>
> --
> 2.25.1
>
Re: [PATCH v2 0/2] get_maintainer: add patch-only keyword matching
On Wed, Sep 27, 2023 at 11:09 PM Joe Perches wrote: > > On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote: > > On Thu, Sep 28, 2023 at 2:01 PM Joe Perches wrote: > > > > > > On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote: > > > > Changes in v2: > > > > - remove formatting pass (thanks Joe) (but seriously the formatting is > > > > bad, is there opportunity to get a formatting pass in here at some > > > > point?) > > > > > > Why? What is it that makes you believe the formatting is bad? > > > > > > > Investigating further, it looked especially bad in my editor. There is > > a mixture of > > tabs and spaces and my vim tabstop is set to 4 for pl files. Setting this to > > 8 is a whole lot better. But I still see some weird spacing > > > > Yes, it's a bit odd indentation. > It's emacs default perl format. > 4 space indent with 8 space tabs, maximal tab fill. > Oh! What?! That's the most surprising convention I've ever heard of (after the GNU C coding style). Yet another thing to hold against perl I guess. :P I have my editor setup to highlight tabs vs spaces via visual cues, so that I don't mess up kernel coding style. (`git clang-format HEAD~` after a commit helps). scripts/get_maintainer.pl has some serious inconsistencies to the point where I'm not sure what it should or was meant to be. Now that you mention it, I see it, and it does seem consistent in that regard. Justin, is your formatter configurable to match that convention? Maybe it's still useful, as long as you configure it to stick to the pre-existing convention. -- Thanks, ~Nick Desaulniers
Re: [PATCH 1/1] rpmsg: virtio: Make buffer size and number configurable
Hi, On 9/28/23 08:38, Divin Raj wrote: > From: Peter Hoyes > > Replace the MAX_RPMSG_BUF_SIZE and MAX_RPMSG_NUM_BUFS #define in > virtio_rpmsg_bus.c with the Kconfig parameters CONFIG_RPMSG_VIRTIO_BUF_SIZE > and CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS, allowing user-provided customization. > > Making both the number of buffers and size configurable facilitates aligning > memory requirements between vdev-buffer and vdev-vrings for client drivers > that require larger buffer sizes, for example. > > Signed-off-by: Peter Hoyes > Signed-off-by: Divin Raj > --- > drivers/rpmsg/Kconfig| 23 +++ > drivers/rpmsg/virtio_rpmsg_bus.c | 27 +++ > 2 files changed, 26 insertions(+), 24 deletions(-) > > diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig > index d3795860f5c0..677f4a1ac8bb 100644 > --- a/drivers/rpmsg/Kconfig > +++ b/drivers/rpmsg/Kconfig > @@ -81,4 +81,27 @@ config RPMSG_VIRTIO > select RPMSG_NS > select VIRTIO > > +config RPMSG_VIRTIO_MAX_BUF_SIZE > + int "Virtio RPMSG max buffer size (in bytes)" > + default 512 Looks to me like you need to: (a) use the "range" kconfig keyword (Documentation/kbuild/kconfig-language.rst) and/or (b) change the source code (driver) to check that both of these new config variables' values make sense. As is (in this patch), I could enter a value of 1 for each of them and see what happens. > + depends on RPMSG_VIRTIO > + help > + This option allows you to configure the maximum buffer size (in bytes) > + for Virtio RPMSG communications. The number of buffers will be > computed > + based on the number of buffers (CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS) > + supported by the vring. By default, it supports up to a maximum of 512 > + buffers (256 in each direction). Each buffer consists of 16 bytes for > the > + message header and the remaining bytes for the payload.The default > values payload. The > + will utilize a maximum total space of 256KB for the buffers. > + > +config RPMSG_VIRTIO_MAX_NUM_BUFS > + int "Virtio RPMSG max buffer count (even number for TX and Rx)" Tx and Rx)" > + default 512 > + depends on RPMSG_VIRTIO > + help > + This option allows you to configure the maximum number of buffers used > + for Virtio RPMSG communication. By default, it supports up to a > maximum > + of 512 buffers (256 in each direction). Please note that this value > + should be an even number, as it accounts for both transmit (TX) and > + receive (Rx) buffers. > endmenu -- ~Randy
[PATCH 1/1] rpmsg: virtio: Make buffer size and number configurable
From: Peter Hoyes
Replace the MAX_RPMSG_BUF_SIZE and MAX_RPMSG_NUM_BUFS #define in
virtio_rpmsg_bus.c with the Kconfig parameters CONFIG_RPMSG_VIRTIO_BUF_SIZE
and CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS, allowing user-provided customization.
Making both the number of buffers and size configurable facilitates aligning
memory requirements between vdev-buffer and vdev-vrings for client drivers
that require larger buffer sizes, for example.
Signed-off-by: Peter Hoyes
Signed-off-by: Divin Raj
---
drivers/rpmsg/Kconfig| 23 +++
drivers/rpmsg/virtio_rpmsg_bus.c | 27 +++
2 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index d3795860f5c0..677f4a1ac8bb 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -81,4 +81,27 @@ config RPMSG_VIRTIO
select RPMSG_NS
select VIRTIO
+config RPMSG_VIRTIO_MAX_BUF_SIZE
+ int "Virtio RPMSG max buffer size (in bytes)"
+ default 512
+ depends on RPMSG_VIRTIO
+ help
+ This option allows you to configure the maximum buffer size (in bytes)
+ for Virtio RPMSG communications. The number of buffers will be
computed
+ based on the number of buffers (CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS)
+ supported by the vring. By default, it supports up to a maximum of 512
+ buffers (256 in each direction). Each buffer consists of 16 bytes for
the
+ message header and the remaining bytes for the payload.The default
values
+ will utilize a maximum total space of 256KB for the buffers.
+
+config RPMSG_VIRTIO_MAX_NUM_BUFS
+ int "Virtio RPMSG max buffer count (even number for TX and Rx)"
+ default 512
+ depends on RPMSG_VIRTIO
+ help
+ This option allows you to configure the maximum number of buffers used
+ for Virtio RPMSG communication. By default, it supports up to a
maximum
+ of 512 buffers (256 in each direction). Please note that this value
+ should be an even number, as it accounts for both transmit (TX) and
+ receive (Rx) buffers.
endmenu
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 905ac7910c98..87a9a4fa30e0 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -109,27 +109,6 @@ struct virtio_rpmsg_channel {
#define to_virtio_rpmsg_channel(_rpdev) \
container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
-/*
- * We're allocating buffers of 512 bytes each for communications. The
- * number of buffers will be computed from the number of buffers supported
- * by the vring, upto a maximum of 512 buffers (256 in each direction).
- *
- * Each buffer will have 16 bytes for the msg header and 496 bytes for
- * the payload.
- *
- * This will utilize a maximum total space of 256KB for the buffers.
- *
- * We might also want to add support for user-provided buffers in time.
- * This will allow bigger buffer size flexibility, and can also be used
- * to achieve zero-copy messaging.
- *
- * Note that these numbers are purely a decision of this driver - we
- * can change this without changing anything in the firmware of the remote
- * processor.
- */
-#define MAX_RPMSG_NUM_BUFS (512)
-#define MAX_RPMSG_BUF_SIZE (512)
-
/*
* Local addresses are dynamically allocated on-demand.
* We do not dynamically assign addresses from the low 1024 range,
@@ -902,12 +881,12 @@ static int rpmsg_probe(struct virtio_device *vdev)
virtqueue_get_vring_size(vrp->svq));
/* we need less buffers if vrings are small */
- if (virtqueue_get_vring_size(vrp->rvq) < MAX_RPMSG_NUM_BUFS / 2)
+ if (virtqueue_get_vring_size(vrp->rvq) <
CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS / 2)
vrp->num_bufs = virtqueue_get_vring_size(vrp->rvq) * 2;
else
- vrp->num_bufs = MAX_RPMSG_NUM_BUFS;
+ vrp->num_bufs = CONFIG_RPMSG_VIRTIO_MAX_NUM_BUFS;
- vrp->buf_size = MAX_RPMSG_BUF_SIZE;
+ vrp->buf_size = CONFIG_RPMSG_VIRTIO_MAX_BUF_SIZE;
total_buf_space = vrp->num_bufs * vrp->buf_size;
--
2.25.1
[PATCH 0/1] rpmsg: virtio: Make buffer size and number configurable
This change is necessary to support the allocation of memory for an out-of-tree rpmsg ethernet device driver over virtio, enabling support for packet sizes based on the MTU (Maximum Transmission Unit) size (1500). Peter Hoyes (1): rpmsg: virtio: Make buffer size and number configurable drivers/rpmsg/Kconfig| 23 +++ drivers/rpmsg/virtio_rpmsg_bus.c | 27 +++ 2 files changed, 26 insertions(+), 24 deletions(-) -- 2.25.1
Re: [PATCH v4 2/2] leds: add ktd202x driver
On Sat, 23 Sep 2023, André Apitzsch wrote:
> This commit adds support for Kinetic KTD2026/7 RGB/White LED driver.
>
> Signed-off-by: André Apitzsch
> ---
> drivers/leds/rgb/Kconfig| 13 +
> drivers/leds/rgb/Makefile | 1 +
> drivers/leds/rgb/leds-ktd202x.c | 625
>
> 3 files changed, 639 insertions(+)
>
> diff --git a/drivers/leds/rgb/Kconfig b/drivers/leds/rgb/Kconfig
> index 183bccc06cf3..a6a21f564673 100644
> --- a/drivers/leds/rgb/Kconfig
> +++ b/drivers/leds/rgb/Kconfig
> @@ -14,6 +14,19 @@ config LEDS_GROUP_MULTICOLOR
> To compile this driver as a module, choose M here: the module
> will be called leds-group-multicolor.
>
> +config LEDS_KTD202X
> + tristate "LED support for KTD202x Chips"
> + depends on I2C
> + depends on OF
> + select REGMAP_I2C
> + help
> + This option enables support for the Kinetic KTD2026/KTD2027
> + RGB/White LED driver found in different BQ mobile phones.
> + It is a 3 or 4 channel LED driver programmed via an I2C interface.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called leds-ktd202x.
> +
> config LEDS_PWM_MULTICOLOR
> tristate "PWM driven multi-color LED Support"
> depends on PWM
> diff --git a/drivers/leds/rgb/Makefile b/drivers/leds/rgb/Makefile
> index c11cc56384e7..243f31e4d70d 100644
> --- a/drivers/leds/rgb/Makefile
> +++ b/drivers/leds/rgb/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> obj-$(CONFIG_LEDS_GROUP_MULTICOLOR) += leds-group-multicolor.o
> +obj-$(CONFIG_LEDS_KTD202X) += leds-ktd202x.o
> obj-$(CONFIG_LEDS_PWM_MULTICOLOR)+= leds-pwm-multicolor.o
> obj-$(CONFIG_LEDS_QCOM_LPG) += leds-qcom-lpg.o
> obj-$(CONFIG_LEDS_MT6370_RGB)+= leds-mt6370-rgb.o
> diff --git a/drivers/leds/rgb/leds-ktd202x.c b/drivers/leds/rgb/leds-ktd202x.c
> new file mode 100644
> index ..b328ecd34664
> --- /dev/null
> +++ b/drivers/leds/rgb/leds-ktd202x.c
> @@ -0,0 +1,625 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Kinetic KTD2026/7 RGB/White LED driver with I2C interface
> + *
> + * Copyright 2023 André Apitzsch
> + *
> + * Datasheet: https://www.kinet-ic.com/uploads/KTD2026-7-04h.pdf
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define KTD2026_NUM_LEDS 3
> +#define KTD2027_NUM_LEDS 4
> +#define KTD202X_MAX_LEDS 4
> +
> +/* Register bank */
> +#define KTD202X_REG_RESET_CONTROL0x00
> +#define KTD202X_REG_FLASH_PERIOD 0x01
> +#define KTD202X_REG_PWM1_TIMER 0x02
> +#define KTD202X_REG_PWM2_TIMER 0x03
> +#define KTD202X_REG_CHANNEL_CTRL 0x04
> +#define KTD202X_REG_TRISE_FALL 0x05
> +#define KTD202X_REG_LED_IOUT(x) (0x06 + (x))
> +
> +/* Register 0 */
> +#define KTD202X_TIMER_SLOT_CONTROL_TSLOT10x00
> +#define KTD202X_TIMER_SLOT_CONTROL_TSLOT20x01
> +#define KTD202X_TIMER_SLOT_CONTROL_TSLOT30x02
> +#define KTD202X_TIMER_SLOT_CONTROL_TSLOT40x03
> +#define KTD202X_RSTR_RESET 0x07
> +
> +#define KTD202X_ENABLE_CTRL_WAKE 0x00 /* SCL High & SDA High */
> +#define KTD202X_ENABLE_CTRL_SLEEP0x08 /* SCL High & SDA Toggling */
> +
> +#define KTD202X_TRISE_FALL_SCALE_NORMAL 0x00
> +#define KTD202X_TRISE_FALL_SCALE_SLOW_X2 0x20
> +#define KTD202X_TRISE_FALL_SCALE_SLOW_X4 0x40
> +#define KTD202X_TRISE_FALL_SCALE_FAST_X8 0x60
> +
> +/* Register 1 */
> +#define KTD202X_FLASH_PERIOD_256_MS_LOG_RAMP 0x00
> +
> +/* Register 2-3 */
> +#define KTD202X_FLASH_ON_TIME_0_4_PERCENT0x01
> +
> +/* Register 4 */
> +#define KTD202X_CHANNEL_CTRL_MASK(x) (BIT(2 * (x)) | BIT(2 * (x) + 1))
> +#define KTD202X_CHANNEL_CTRL_OFF 0x00
> +#define KTD202X_CHANNEL_CTRL_ON(x) BIT(2 * (x))
> +#define KTD202X_CHANNEL_CTRL_PWM1(x) BIT(2 * (x) + 1)
> +#define KTD202X_CHANNEL_CTRL_PWM2(x) (BIT(2 * (x)) | BIT(2 * (x) + 1))
> +
> +/* Register 5 */
> +#define KTD202X_RAMP_TIMES_2_MS 0x00
> +
> +/* Register 6-9 */
> +#define KTD202X_LED_CURRENT_10_mA0x4f
> +
> +#define KTD202X_FLASH_PERIOD_MIN_MS 256
> +#define KTD202X_FLASH_PERIOD_STEP_MS 128
> +#define KTD202X_FLASH_PERIOD_MAX_STEPS 126
> +#define KTD202X_FLASH_ON_MAX 256
> +
> +#define KTD202X_MAX_BRIGHTNESS 192
> +
> +static const struct reg_default ktd202x_reg_defaults[] = {
> + { KTD202X_REG_RESET_CONTROL, KTD202X_TIMER_SLOT_CONTROL_TSLOT1 |
> + KTD202X_ENABLE_CTRL_WAKE | KTD202X_TRISE_FALL_SCALE_NORMAL },
> + { KTD202X_REG_FLASH_PERIOD, KTD202X_FLASH_PERIOD_256_MS_LOG_RAMP },
> + { KTD202X_REG_PWM1_TIMER, KTD202X_FLASH_ON_TIME_0_4_PERCENT },
> + { KTD202X_REG_PWM2_TIMER, KTD202X_FLASH_ON_TIME_0_4_PERCENT },
> + { KTD202X_REG_CHANNEL_CTRL, KTD202X_CHANNEL_CTRL_OFF },
> + { KTD202X_REG_TRISE_FALL, KTD202X_RAMP_TIMES_2_MS },
> +
[PATCH 71/87] fs/tracefs: convert to new inode {a,m}time accessors
Signed-off-by: Jeff Layton
---
fs/tracefs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 891653ba9cf3..429603d865a9 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -152,7 +152,7 @@ struct inode *tracefs_get_inode(struct super_block *sb)
struct inode *inode = new_inode(sb);
if (inode) {
inode->i_ino = get_next_ino();
- inode->i_atime = inode->i_mtime =
inode_set_ctime_current(inode);
+ simple_inode_init_ts(inode);
}
return inode;
}
--
2.41.0
[PATCH] tracing/eprobe: drop unneeded breaks
Drop break after return.
Signed-off-by: Julia Lawall
---
kernel/trace/trace_eprobe.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/trace/trace_eprobe.c b/kernel/trace/trace_eprobe.c
index 72714cbf475c..03c851f57969 100644
--- a/kernel/trace/trace_eprobe.c
+++ b/kernel/trace/trace_eprobe.c
@@ -788,12 +788,9 @@ find_and_get_event(const char *system, const char
*event_name)
name = trace_event_name(tp_event);
if (!name || strcmp(event_name, name))
continue;
- if (!trace_event_try_get_ref(tp_event)) {
+ if (!trace_event_try_get_ref(tp_event))
return NULL;
- break;
- }
return tp_event;
- break;
}
return NULL;
}
Re: [PATCH v5 11/18] x86/sgx: store unreclaimable pages in LRU lists
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -746,6 +746,7 @@ void sgx_encl_release(struct kref *ref)
> xa_destroy(>page_array);
>
> if (!encl->secs_child_cnt && encl->secs.epc_page) {
> + sgx_drop_epc_page(encl->secs.epc_page);
> sgx_encl_free_epc_page(encl->secs.epc_page);
> encl->secs.epc_page = NULL;
> }
The "record" of SECS/VA pages should be done together with this. I see no
reason why the "record" and "drop" are separated into different patches.
Re: [PATCH v5 08/18] x86/sgx: Use a list to track to-be-reclaimed pages
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> @@ -314,18 +313,22 @@ static void sgx_reclaim_pages(void)
>
> if (kref_get_unless_zero(_page->encl->refcount) != 0) {
> sgx_epc_page_set_state(epc_page,
> SGX_EPC_PAGE_RECLAIM_IN_PROGRESS);
> - chunk[cnt++] = epc_page;
> + list_move_tail(_page->list, );
> } else {
> - /* The owner is freeing the page. No need to add the
> - * page back to the list of reclaimable pages.
> + /* The owner is freeing the page, remove it from the
> + * LRU list
> */
Please fix comment style.
> sgx_epc_page_reset_state(epc_page);
> + list_del_init(_page->list);
Is this still needed? It seems list_del_init() has been done when the EPC page
is taken off from the global active list?
Re: [PATCH v2 0/2] get_maintainer: add patch-only keyword matching
On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote: > On Thu, Sep 28, 2023 at 2:01 PM Joe Perches wrote: > > > > On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote: > > > Changes in v2: > > > - remove formatting pass (thanks Joe) (but seriously the formatting is > > > bad, is there opportunity to get a formatting pass in here at some > > > point?) > > > > Why? What is it that makes you believe the formatting is bad? > > > > Investigating further, it looked especially bad in my editor. There is > a mixture of > tabs and spaces and my vim tabstop is set to 4 for pl files. Setting this to > 8 is a whole lot better. But I still see some weird spacing > Yes, it's a bit odd indentation. It's emacs default perl format. 4 space indent with 8 space tabs, maximal tab fill.
