Hi Mohammad, On Sun, Aug 17, 2025 at 10:55:14AM +0300, Mohammad Gomaa wrote: > Add tracepoints to i2c-core-base.c file to help trace > and debug I2C device probe failures. > > The new trace points are: > - i2c_device_probe_debug: records non-failure routines > e.g. IRQ 0. > - i2c_device_probe_complete: records failed & successful > probbes with appropriate trace message. > > To support operation of these tracepoints an enum > was added that stores log message for debug and failure. > > Signed-off-by: Mohammad Gomaa <midomaxgo...@gmail.com> > --- > Hello, > > This patch adds tracepoints to i2c-core-base to aid with debugging I2C > probing failrues. > > The motivation for this comes from my work in Google Summer of Code (GSoC) > 2025: > "ChromeOS Platform Input Device Quality Monitoring" > https://summerofcode.withgoogle.com/programs/2025/projects/uCdIgK7K > > This is my first submission to the Linux kernel, so any feedback is welcome.
Welcome to Kernel hacking! I understand from the link above that this patch is intended for quality assurance. With automatic testing, you can find regression of firmware updates much easier. The drawback is that it is quite some code for such a niche use case. Also, I would think this code is very fragile because whenever the code path in probe changes, one must ensure that err_reason is still set accordingly. This adds maintenance burden. I wonder if you can't use the output in the kernel log to identify problems? We could add some if they are really missing. I know such strings are not static. Still, my gut feeling says some application should handle the complexity, not the kernel. Wouldn't we need a patch like this for each and every subsystem if we follow that route? Happy hacking, Wolfram
signature.asc
Description: PGP signature
