From: Eli Billauer <eli.billauer@gmail.com>
To: gregkh@linuxfoundation.org
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org,
Eli Billauer <eli.billauer@gmail.com>
Subject: [PATCH 0/7] char: xillybus: Harden driver and improve code quality
Date: Tue, 30 Jun 2026 11:23:23 +0200 [thread overview]
Message-ID: <20260630092330.43534-1-eli.billauer@gmail.com> (raw)
This patch set consists of several boundary and sanity checks, gaining
better control of execution flow and fixing minor coding issues. No
difference is expected in the driver's behavior under normal conditions,
except for one change that might improve bandwidth performance
marginally.
Why all of the sudden? These patches are the result of a comprehensive
AI-assisted code review, using Deepseek, Kimi Thinking K2.6, ChatGPT,
and Claude Sonnet 4.6 as plain prompt tools.
I've spent three weeks in what I call a "reverse rubber duck" session,
asking these LLMs to find bugs in the code and following up on different
leads, the vast majority of which turned out to be no more than quack.
Occasionally the points made by AI were valid, and in others, the mere
effort to explain why the remark is wrong to the rubber duck led to
finding real issues.
Almost none of the fixes suggested by AI were even near the actual
corrections in this patch set.
Thanks & regards,
Eli
Eli Billauer (7):
char: xillybus: Improve control of execution flow with mutexes
char: xillybus: Remove duplicate error path code
char: xillybus: Avoid possible bandwidth inefficiency
char: xillybus: Use unsigned arithmetic for jiffies differences
char: xillybus: Integer arithmetic improvements
char: xillybus: Add defensive sanity checks
char: xillybus: Ignore and report unsolicited interrupts
drivers/char/xillybus/xillybus.h | 3 +
drivers/char/xillybus/xillybus_class.c | 11 +++
drivers/char/xillybus/xillybus_class.h | 4 +
drivers/char/xillybus/xillybus_core.c | 100 ++++++++++++++++++++++---
drivers/char/xillybus/xillybus_of.c | 6 ++
drivers/char/xillybus/xillyusb.c | 62 +++++++++++----
6 files changed, 160 insertions(+), 26 deletions(-)
--
2.34.1
next reply other threads:[~2026-06-30 9:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 9:23 Eli Billauer [this message]
2026-06-30 9:23 ` [PATCH 1/7] char: xillybus: Improve control of execution flow with mutexes Eli Billauer
2026-06-30 9:23 ` [PATCH 2/7] char: xillybus: Remove duplicate error path code Eli Billauer
2026-06-30 9:23 ` [PATCH 3/7] char: xillybus: Avoid possible bandwidth inefficiency Eli Billauer
2026-06-30 9:23 ` [PATCH 4/7] char: xillybus: Use unsigned arithmetic for jiffies differences Eli Billauer
2026-06-30 9:23 ` [PATCH 5/7] char: xillybus: Integer arithmetic improvements Eli Billauer
2026-06-30 9:23 ` [PATCH 6/7] char: xillybus: Add defensive sanity checks Eli Billauer
2026-06-30 9:23 ` [PATCH 7/7] char: xillybus: Ignore and report unsolicited interrupts Eli Billauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260630092330.43534-1-eli.billauer@gmail.com \
--to=eli.billauer@gmail.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox