Re: [PATCH] uprobes: reduce contention on uprobes_tree access
* Jonathan Haslam wrote: > Active uprobes are stored in an RB tree and accesses to this tree are > dominated by read operations. Currently these accesses are serialized by > a spinlock but this leads to enormous contention when large numbers of > threads are executing active probes. > > This patch converts the spinlock used to serialize access to the > uprobes_tree RB tree into a reader-writer spinlock. This lock type > aligns naturally with the overwhelmingly read-only nature of the tree > usage here. Although the addition of reader-writer spinlocks are > discouraged [0], this fix is proposed as an interim solution while an > RCU based approach is implemented (that work is in a nascent form). This > fix also has the benefit of being trivial, self contained and therefore > simple to backport. > > This change has been tested against production workloads that exhibit > significant contention on the spinlock and an almost order of magnitude > reduction for mean uprobe execution time is observed (28 -> 3.5 microsecs). Have you considered/measured per-CPU RW semaphores? Thanks, Ingo
Re: [PATCH v2] arch/riscv: Enable kprobes when CONFIG_MODULES=n
On Sun Mar 24, 2024 at 2:37 AM EET, Randy Dunlap wrote: > > > On 3/23/24 16:29, Jarkko Sakkinen wrote: > > +config HAVE_KPROBES_ALLOC > > + bool > > + help > > + Architectures that select this option are capable of allocating memory > > + for kprobes withou the kernel module allocator. > > without Thanks, will fix. BR, Jarkko
Re: [PATCH v2] arch/riscv: Enable kprobes when CONFIG_MODULES=n
On 3/23/24 16:29, Jarkko Sakkinen wrote: > +config HAVE_KPROBES_ALLOC > + bool > + help > + Architectures that select this option are capable of allocating memory > + for kprobes withou the kernel module allocator. without -- #Randy
Re: [PATCH v2] arch/riscv: Enable kprobes when CONFIG_MODULES=n
On Sun Mar 24, 2024 at 1:29 AM EET, Jarkko Sakkinen wrote:
> Tracing with kprobes while running a monolithic kernel is currently
> impossible due the kernel module allocator dependency.
>
> Address the issue by allowing architectures to implement module_alloc()
> and module_memfree() independent of the module subsystem. An arch tree
> can signal this by setting HAVE_KPROBES_ALLOC in its Kconfig file.
>
> Realize the feature on RISC-V by separating allocator to module_alloc.c
> and implementing module_memfree().
>
> Link: https://www.sochub.fi # for power on testing new SoC's with a minimal
> stack
> Link:
> https://lore.kernel.org/all/2022060814.3054333-1-jar...@profian.com/ #
> continuation
> Signed-off-by: Jarkko Sakkinen
As for testing I tried the kprobes example for boottime tracing
dcoumentation:
https://www.kernel.org/doc/html/v5.7/trace/boottime-trace.html
I.e.
ftrace.event {
kprobes.vfs_read {
probes = "vfs_read $arg1 $arg2"
filter = "common_pid < 100"
enable
}
}
kernel {
console = hvc0
earlycon = sbi
trace_options = sym-addr
trace_event = "initcall:*"
tp_printk
dump_on_oops = 2
trace_buf_size = 1M
}
BR, Jarkko
[PATCH v2] arch/riscv: Enable kprobes when CONFIG_MODULES=n
Tracing with kprobes while running a monolithic kernel is currently
impossible due the kernel module allocator dependency.
Address the issue by allowing architectures to implement module_alloc()
and module_memfree() independent of the module subsystem. An arch tree
can signal this by setting HAVE_KPROBES_ALLOC in its Kconfig file.
Realize the feature on RISC-V by separating allocator to module_alloc.c
and implementing module_memfree().
Link: https://www.sochub.fi # for power on testing new SoC's with a minimal
stack
Link: https://lore.kernel.org/all/2022060814.3054333-1-jar...@profian.com/
# continuation
Signed-off-by: Jarkko Sakkinen
---
v2:
- Better late than never right? :-)
- Focus only to RISC-V for now to make the patch more digestable. This
is the arch where I use the patch on a daily basis to help with QA.
- Introduce HAVE_KPROBES_ALLOC flag to help with more gradual migration.
---
arch/Kconfig | 8 +++-
arch/riscv/Kconfig | 1 +
arch/riscv/kernel/Makefile | 5 +
arch/riscv/kernel/module.c | 11 ---
arch/riscv/kernel/module_alloc.c | 28
kernel/kprobes.c | 10 ++
kernel/trace/trace_kprobe.c | 18 --
7 files changed, 67 insertions(+), 14 deletions(-)
create mode 100644 arch/riscv/kernel/module_alloc.c
diff --git a/arch/Kconfig b/arch/Kconfig
index a5af0edd3eb8..c931f1de98a7 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -52,7 +52,7 @@ config GENERIC_ENTRY
config KPROBES
bool "Kprobes"
- depends on MODULES
+ depends on MODULES || HAVE_KPROBES_ALLOC
depends on HAVE_KPROBES
select KALLSYMS
select TASKS_RCU if PREEMPTION
@@ -215,6 +215,12 @@ config HAVE_OPTPROBES
config HAVE_KPROBES_ON_FTRACE
bool
+config HAVE_KPROBES_ALLOC
+ bool
+ help
+ Architectures that select this option are capable of allocating memory
+ for kprobes withou the kernel module allocator.
+
config ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
bool
help
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e3142ce531a0..4f1b925e83d8 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -132,6 +132,7 @@ config RISCV
select HAVE_KPROBES if !XIP_KERNEL
select HAVE_KPROBES_ON_FTRACE if !XIP_KERNEL
select HAVE_KRETPROBES if !XIP_KERNEL
+ select HAVE_KPROBES_ALLOC if !XIP_KERNEL
# https://github.com/ClangBuiltLinux/linux/issues/1881
select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if !LD_IS_LLD
select HAVE_MOVE_PMD
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index 604d6bf7e476..46318194bce1 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -73,6 +73,11 @@ obj-$(CONFIG_SMP)+= cpu_ops.o
obj-$(CONFIG_RISCV_BOOT_SPINWAIT) += cpu_ops_spinwait.o
obj-$(CONFIG_MODULES) += module.o
+ifeq ($(CONFIG_MODULES),y)
+obj-y += module_alloc.o
+else
+obj-$(CONFIG_KPROBES) += module_alloc.o
+endif
obj-$(CONFIG_MODULE_SECTIONS) += module-sections.o
obj-$(CONFIG_CPU_PM) += suspend_entry.o suspend.o
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 5e5a82644451..cc324b450f2e 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -905,17 +905,6 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char
*strtab,
return 0;
}
-#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
-void *module_alloc(unsigned long size)
-{
- return __vmalloc_node_range(size, 1, MODULES_VADDR,
- MODULES_END, GFP_KERNEL,
- PAGE_KERNEL, VM_FLUSH_RESET_PERMS,
- NUMA_NO_NODE,
- __builtin_return_address(0));
-}
-#endif
-
int module_finalize(const Elf_Ehdr *hdr,
const Elf_Shdr *sechdrs,
struct module *me)
diff --git a/arch/riscv/kernel/module_alloc.c b/arch/riscv/kernel/module_alloc.c
new file mode 100644
index ..3d9aa8dbca8a
--- /dev/null
+++ b/arch/riscv/kernel/module_alloc.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2017 Zihao Yu
+ * Copyright (c) 2024 Jarkko Sakkinen
+ */
+
+#include
+#include
+#include
+#include
+
+#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
+void *module_alloc(unsigned long size)
+{
+ return __vmalloc_node_range(size, 1, MODULES_VADDR,
+ MODULES_END, GFP_KERNEL,
+ PAGE_KERNEL, 0, NUMA_NO_NODE,
+ __builtin_return_address(0));
+}
+
+void module_memfree(void *module_region)
+{
+ if (in_interrupt())
+ pr_warn("In interrupt context: vmalloc may not work.\n");
+
+ vfree(module_region);
+}
+#endif
diff --git a/kernel/kprobes.c
[BUG][KMEMLEAK] modprobe: unreferenced object (size 16)
Hi, On the Ubuntu 22.04 LTS system, with recent iproute2-next toolsvand build 6.8-11743-ga4145ce1e7bc, kmemleak system reported the following memory leaks: unreferenced object 0x9da692e7e920 (size 16): comm "modprobe", pid 2248188, jiffies 4358296226 hex dump (first 16 bytes): 68 6d 6d 5f 64 6d 69 72 72 6f 72 30 00 00 00 00 hmm_dmirror0 backtrace (crc d64cce1d): kmemleak_alloc (/home/marvin/linux/kernel/linux_torvalds/mm/kmemleak.c:1045) __kmalloc_node_track_caller (/home/marvin/linux/kernel/linux_torvalds/./include/linux/kmemleak.h:42 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3802 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3845 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3965 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3986) kvasprintf (/home/marvin/linux/kernel/linux_torvalds/lib/kasprintf.c:25) kvasprintf_const (/home/marvin/linux/kernel/linux_torvalds/lib/kasprintf.c:50) kobject_set_name_vargs (/home/marvin/linux/kernel/linux_torvalds/lib/kobject.c:274) dev_set_name (/home/marvin/linux/kernel/linux_torvalds/drivers/base/core.c:3445) drr_init (/home/marvin/linux/kernel/linux_torvalds/net/sched/sch_drr.c:233) sch_drr do_one_initcall (/home/marvin/linux/kernel/linux_torvalds/init/main.c:1238) do_init_module (/home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:2538) load_module (/home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3001) init_module_from_file (/home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3168) idempotent_init_module (/home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3185) __x64_sys_finit_module (/home/marvin/linux/kernel/linux_torvalds/./include/linux/file.h:47 /home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3207 /home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3189 /home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3189) do_syscall_64 (/home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/common.c:52 /home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (/home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/entry_64.S:129) unreferenced object 0x9d9b0080bf00 (size 256): comm "modprobe", pid 2248188, jiffies 4358296226 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 bf 80 00 9b 9d ff ff 08 bf 80 00 9b 9d ff ff 00 d9 80 af ff ff ff ff backtrace (crc 31d67378): kmemleak_alloc (/home/marvin/linux/kernel/linux_torvalds/mm/kmemleak.c:1045) kmalloc_trace (/home/marvin/linux/kernel/linux_torvalds/./include/linux/kmemleak.h:42 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3802 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3845 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3992) device_add (/home/marvin/linux/kernel/linux_torvalds/drivers/base/core.c:3484 /home/marvin/linux/kernel/linux_torvalds/drivers/base/core.c:3535) cdev_device_add (/home/marvin/linux/kernel/linux_torvalds/fs/char_dev.c:557) drr_init (/home/marvin/linux/kernel/linux_torvalds/./include/linux/list.h:195 /home/marvin/linux/kernel/linux_torvalds/./include/linux/list.h:218 /home/marvin/linux/kernel/linux_torvalds/./include/linux/list.h:229 /home/marvin/linux/kernel/linux_torvalds/net/sched/sch_drr.c:434) sch_drr do_one_initcall (/home/marvin/linux/kernel/linux_torvalds/init/main.c:1238) do_init_module (/home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:2538) load_module (/home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3001) init_module_from_file (/home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3168) idempotent_init_module (/home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3185) __x64_sys_finit_module (/home/marvin/linux/kernel/linux_torvalds/./include/linux/file.h:47 /home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3207 /home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3189 /home/marvin/linux/kernel/linux_torvalds/kernel/module/main.c:3189) do_syscall_64 (/home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/common.c:52 /home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (/home/marvin/linux/kernel/linux_torvalds/arch/x86/entry/entry_64.S:129) unreferenced object 0x9da692e7ee90 (size 16): comm "modprobe", pid 2248188, jiffies 4358296235 hex dump (first 16 bytes): 68 6d 6d 5f 64 6d 69 72 72 6f 72 31 00 00 00 00 hmm_dmirror1 backtrace (crc eb2ce7ad): kmemleak_alloc (/home/marvin/linux/kernel/linux_torvalds/mm/kmemleak.c:1045) __kmalloc_node_track_caller (/home/marvin/linux/kernel/linux_torvalds/./include/linux/kmemleak.h:42 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3802 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3845 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3965 /home/marvin/linux/kernel/linux_torvalds/mm/slub.c:3986) kvasprintf (/home/marvin/linux/kernel/linux_torvalds/lib/kasprintf.c:25)
Re: [PATCH v7 3/7] LoongArch: KVM: Add cpucfg area for kvm hypervisor
On 3/15/24 16:07, Bibo Mao wrote: Instruction cpucfg can be used to get processor features. And there is trap exception when it is executed in VM mode, and also it is to provide cpu features to VM. On real hardware cpucfg area 0 - 20 is used. Here one specified area 0x4000 -- 0x40ff is used for KVM hypervisor to privide PV features, and the area can be extended for other hypervisors in future. This area will never be used for real HW, it is only used by software. Signed-off-by: Bibo Mao --- arch/loongarch/include/asm/inst.h | 1 + arch/loongarch/include/asm/loongarch.h | 10 + arch/loongarch/kvm/exit.c | 59 +++--- 3 files changed, 54 insertions(+), 16 deletions(-) Sorry for the late reply, but I think it may be a bit non-constructive to repeatedly submit the same code without due explanation in our previous review threads. Let me try to recollect some of the details though... If I remember correctly, during the previous reviews, it was mentioned that the only upsides of using CPUCFG were: - it was exactly identical to the x86 approach, - it would not require access to the LoongArch Reference Manual Volume 3 to use, and - it was plain old data. But, for the first point, we don't have to follow x86 convention after all. The second reason might be compelling, but on the one hand that's another problem orthogonal to the current one, and on the other hand HVCL is: - already effectively public because of the fact that this very patchset is public, - its semantics is trivial to implement even without access to the LVZ manual, because of its striking similarity with SYSCALL, and - by being a function call, we reserve the possibility for hypervisors to invoke logic for self-identification purposes, even if this is likely overkill from today's perspective. And, even if we decide that using HVCL for self-identification is overkill after all, we still have another choice that's IOCSR. We already read LOONGARCH_IOCSR_FEATURES (0x8) for its bit 11 (IOCSRF_VM) to populate the CPU_FEATURE_HYPERVISOR bit, and it's only natural that we put the identification word in the IOCSR space. As far as I can see, the IOCSR space is plenty and equally available for making reservations; it can only be even easier when it's done by a Loongson team. Finally, I've mentioned multiple times, that varying CPUCFG behavior based on PLV is not something well documented on the manuals, hence not friendly to low-level developers. Devs of third-party firmware and/or kernels do exist, I've personally spoken to some of them on the 2023-11-18 3A6000 release event; in order for the varying CPUCFG behavior approach to pass for me, at the very least, the LoongArch reference manual must be amended to explicitly include an explanation of it, and a reference to potential use cases. -- WANG "xen0n" Xuerui Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
Re: [PATCH v7 7/7] Documentation: KVM: Add hypercall for LoongArch
On 3/15/24 16:11, Bibo Mao wrote: [snip] +KVM hypercall ABI += + +Hypercall ABI on KVM is simple, only one scratch register a0 and at most +five generic registers used as input parameter. FP register and vector register +is not used for input register and should not be modified during hypercall. +Hypercall function can be inlined since there is only one scratch register. Maybe it's better to describe the list of preserved registers with an expression such as "all non-GPR registers shall remain unmodified after returning from the hypercall", to guard ourselves against future ISA state additions. But I still maintain that it's better to promise less here, and only hint on the extensive preservation of context as an implementation detail. It is for not losing our ability to save/restore less in the future, should we decide to do so. -- WANG "xen0n" Xuerui Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
Re: [PATCH v2 net] ice: Fix freeing uninitialized pointers
> Automatically cleaned up pointers need to be initialized before exiting > their scope. In this case, they need to be initialized to NULL before > any return statement. * May we expect that compilers should report that affected variables were only declared here instead of appropriately defined (despite of attempts for scope-based resource management)? * Did you extend detection support in the source code analysis tool “Smatch” for a questionable implementation detail? Regards, Markus
Re: [PATCH] [v2] module: don't ignore sysfs_create_link() failures
On Fri, Mar 22, 2024 at 06:39:11PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The sysfs_create_link() return code is marked as __must_check, but the
> module_add_driver() function tries hard to not care, by assigning the
> return code to a variable. When building with 'make W=1', gcc still
> warns because this variable is only assigned but not used:
>
> drivers/base/module.c: In function 'module_add_driver':
> drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used
> [-Wunused-but-set-variable]
>
> Rework the code to properly unwind and return the error code to the
> caller. My reading of the original code was that it tries to
> not fail when the links already exist, so keep ignoring -EEXIST
> errors.
>
> Cc: Luis Chamberlain
> Cc: linux-modu...@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
> See-also: 4a7fb6363f2d ("add __must_check to device management code")
> Signed-off-by: Arnd Bergmann
> ---
> v2: rework to actually handle the error. I have not tested the
> error handling beyond build testing, so please review carefully.
> ---
> drivers/base/base.h | 2 +-
> drivers/base/bus.c| 7 ++-
> drivers/base/module.c | 42 +++---
> 3 files changed, 38 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/base/base.h b/drivers/base/base.h
> index 0738ccad08b2..0e04bfe02943 100644
> --- a/drivers/base/base.h
> +++ b/drivers/base/base.h
> @@ -192,7 +192,7 @@ extern struct kset *devices_kset;
> void devices_kset_move_last(struct device *dev);
>
> #if defined(CONFIG_MODULES) && defined(CONFIG_SYSFS)
> -void module_add_driver(struct module *mod, struct device_driver *drv);
> +int module_add_driver(struct module *mod, struct device_driver *drv);
> void module_remove_driver(struct device_driver *drv);
> #else
> static inline void module_add_driver(struct module *mod,
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index daee55c9b2d9..7ef75b60d331 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -674,7 +674,12 @@ int bus_add_driver(struct device_driver *drv)
> if (error)
> goto out_del_list;
> }
> - module_add_driver(drv->owner, drv);
> + error = module_add_driver(drv->owner, drv);
> + if (error) {
> + printk(KERN_ERR "%s: failed to create module links for %s\n",
> + __func__, drv->name);
> + goto out_del_list;
Don't we need to walk back the driver_attach() call here if this fails?
> + }
>
> error = driver_create_file(drv, _attr_uevent);
> if (error) {
> diff --git a/drivers/base/module.c b/drivers/base/module.c
> index 46ad4d636731..61282eaed670 100644
> --- a/drivers/base/module.c
> +++ b/drivers/base/module.c
> @@ -30,14 +30,14 @@ static void module_create_drivers_dir(struct
> module_kobject *mk)
> mutex_unlock(_dir_mutex);
> }
>
> -void module_add_driver(struct module *mod, struct device_driver *drv)
> +int module_add_driver(struct module *mod, struct device_driver *drv)
> {
> char *driver_name;
> - int no_warn;
> + int ret;
> struct module_kobject *mk = NULL;
>
> if (!drv)
> - return;
> + return 0;
>
> if (mod)
> mk = >mkobj;
> @@ -56,17 +56,37 @@ void module_add_driver(struct module *mod, struct
> device_driver *drv)
> }
>
> if (!mk)
> - return;
> + return 0;
> +
> + ret = sysfs_create_link(>p->kobj, >kobj, "module");
> + if (ret && ret != -EEXIST)
Why would EEXIST happen here? How can this be called twice?
> + return ret;
>
> - /* Don't check return codes; these calls are idempotent */
> - no_warn = sysfs_create_link(>p->kobj, >kobj, "module");
> driver_name = make_driver_name(drv);
> - if (driver_name) {
> - module_create_drivers_dir(mk);
> - no_warn = sysfs_create_link(mk->drivers_dir, >p->kobj,
> - driver_name);
> - kfree(driver_name);
> + if (!driver_name) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + module_create_drivers_dir(mk);
> + if (!mk->drivers_dir) {
> + ret = -EINVAL;
> + goto out;
> }
> +
> + ret = sysfs_create_link(mk->drivers_dir, >p->kobj, driver_name);
> + if (ret && ret != -EEXIST)
> + goto out;
Same EEXIST question here.
thanks,
greg k-h
Re: [PATCH 00/64] i2c: reword i2c_algorithm according to newest specification
Hi Wolfram, On Fri, Mar 22, 2024 at 02:24:53PM +0100, Wolfram Sang wrote: > Okay, we need to begin somewhere... > > Start changing the wording of the I2C main header wrt. the newest I2C > v7, SMBus 3.2, I3C specifications and replace "master/slave" with more > appropriate terms. This first step renames the members of struct > i2c_algorithm. Once all in-tree users are converted, the anonymous union > will go away again. All this work will also pave the way for finally > seperating the monolithic header into more fine-grained headers like > "i2c/clients.h" etc. So, this is not a simple renaming-excercise but > also a chance to update the I2C core to recent Linux standards. yes, very good! It's clearly stated in all three documentations that Target replaces Slave and Controller replaces Master (i3c is at the 1.1.1 version). > My motivation is to improve the I2C core API, in general. My motivation > is not to clean each and every driver. I think this is impossible > because register names based on official documentation will need to stay > as they are. But the Linux-internal names should be updated IMO. Also because some drivers have been written based on previous specifications where master/slave was used. > That being said, I worked on 62 drivers in this series beyond plain > renames inside 'struct i2c_algorithm' because the fruits were so > low-hanging. Before this series, 112 files in the 'busses/' directory > contained 'master' and/or 'slave'. After the series, only 57. Why not? > > Next step is updating the drivers outside the 'i2c'-folder regarding > 'struct i2c_algorithm' so we can remove the anonymous union ASAP. To be > able to work on this with minimal dependencies, I'd like to apply this > series between -rc1 and -rc2. > > I hope this will work for you guys. The changes are really minimal. If > you are not comfortable with changes to your driver or need more time to > review, please NACK the patch and I will drop the patch and/or address > the issues separeately. > > @Andi: are you okay with this approach? It means you'd need to merge > -rc2 into your for-next branch. Or rebase if all fails. I think it's a good plan, I'll try to support you with it. > Speaking of Andi, thanks a lot to him taking care of the controller > drivers these days. His work really gives me the freedom to work on I2C > core issues again. Thank you, Wolfram! Andi
