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.

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.

The v1 iteration of this series was rejected due to an error in the
error path. Specifically, the @rc variable was not assigned a value
before a goto statement following a failed allocation. This oversight
was caught during compilation with LLVM=1, but was missed by GCC and the
AI tools used during the review (and myself of course).

All patches are unchanged since v1, except for "Add defensive sanity
checks", which fixes the said error and also makes a couple of minor
adjustments.

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 |  18 ++++-
 drivers/char/xillybus/xillybus_class.h |   4 +
 drivers/char/xillybus/xillybus_core.c  | 100 ++++++++++++++++++++++---
 drivers/char/xillybus/xillybus_of.c    |   3 +
 drivers/char/xillybus/xillyusb.c       |  62 +++++++++++----
 6 files changed, 162 insertions(+), 28 deletions(-)

-- 
2.34.1

Eli Billauer <eli.billauer@gmail.com> writes:

> 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.
>
> 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.

So it would seem that they need Assisted-by tags?

Thanks,

jon

On 22/07/2026 16:49, Jonathan Corbet wrote:
> Eli Billauer <eli.billauer@gmail.com> writes:
> 
>> 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.
>>
>> 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.
> 
> So it would seem that they need Assisted-by tags?
> 

Frankly speaking, I don't know. And I'll explain the dilemma:

As I wrote in the v1 cover letter (and removed for v2, which I perhaps 
shouldn't have done), my work with the AI tools was what I call a 
"reverse rubber duck" session: the AI tools told me what they considered 
to be a bug, and my job was to convince the rubber duck that it was 
wrong. And this went on for three weeks.

In a few cases, the rubber duck actually had a point. In most cases, it 
merely got me to pay attention to things I didn't notice before. And the 
actual corrections were written by me: the suggestions made by AI were a 
long way from being usable.

I understand that Assisted-by tags are intended to keep track of how AI 
is used for contributing to the Linux kernel. But I'm not sure my case 
is what this tag was meant for. Plus, as this went on for quite a while, 
I don't have a record of which tool contributed to which patch. So 
mention all four for all patches?

So I'll have to bounce the question back: Is the Assisted-by tag 
suitable when AI acts as a rubber duck?

Thanks and regards,
    Eli

On Wed, Jul 22, 2026 at 05:53:14PM +0200, Eli Billauer wrote:
> On 22/07/2026 16:49, Jonathan Corbet wrote:
> > Eli Billauer <eli.billauer@gmail.com> writes:
> > 
> > > 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.
> > > 
> > > 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.
> > 
> > So it would seem that they need Assisted-by tags?
> > 
> 
> Frankly speaking, I don't know. And I'll explain the dilemma:
> 
> As I wrote in the v1 cover letter (and removed for v2, which I perhaps
> shouldn't have done), my work with the AI tools was what I call a "reverse
> rubber duck" session: the AI tools told me what they considered to be a bug,
> and my job was to convince the rubber duck that it was wrong. And this went
> on for three weeks.
> 
> In a few cases, the rubber duck actually had a point. In most cases, it
> merely got me to pay attention to things I didn't notice before. And the
> actual corrections were written by me: the suggestions made by AI were a
> long way from being usable.
> 
> I understand that Assisted-by tags are intended to keep track of how AI is
> used for contributing to the Linux kernel. But I'm not sure my case is what
> this tag was meant for. Plus, as this went on for quite a while, I don't
> have a record of which tool contributed to which patch. So mention all four
> for all patches?
> 
> So I'll have to bounce the question back: Is the Assisted-by tag suitable
> when AI acts as a rubber duck?

Yes.  Please add something there.

thanks,

greg k-h