Re: [PATCH v2 1/2] hwmon: (yogafan) Use u32 types and improve RLLag filter

[Guenter Roeck]

On Tue, Apr 28, 2026 at 01:44:33PM +0300, Ilpo Järvinen wrote:
> On Fri, 17 Apr 2026, Sergio Melas wrote:
> 
...
> 
> The old way was way better. And this too looks entirely unrelated change.
> 
> 
> This was extremely messy to review. Please only resubmit after splitting 
> this into a series which does only a single logical change per patch.
> 
> And right before doing the next submission, my suggestion is: please try 
> to review it yourself. If, while reviewing it yourself, you don't 
> understand something or feel need to skip reading some lines because the 
> change is so big or get messy, it will likely cause the same feeling for 
> the other reviewers as well and you should rethink the approach and ensure 
> you've really split it into manageable (reviewable) chunks.
> 

The entire patch, especially and even more so the inserted cryptic
comments, the claim that the driver would introduce a "Hardware
Abstraction Layer", and the various enumerations, are typical of vibe
coding with little if any human review.

Essentially that means that the code can not be trusted. The documentation
claims compliance to various IEC norms, but who knows how much of that is
AI hallucination and how much of it is real.

On top of that, even AI (Sashiko) found problems with it. This directly
contradicts the various "Safety and Design Integrity" claims made in the
documentation.

So, just to be sure, I asked Gemini (gemini-3-flash, coincidentally).
See below what it had to say. Kind of fun though that it believes that
it is late 2024. You'd think they train those models on something more
recent.

Anyway, given all that, I don't even want to look into that code myself.

Guenter

---
The likelihood that the patch at index.html was AI-generated is extremely
high (near 100%). 

  While the patch is technically sophisticated and follows many Linux kernel
  standards, it contains several "smoking guns" and patterns characteristic
  of advanced Large Language Models (LLMs) instructed to produce
  high-quality, safety-critical code.

  Primary Evidence: The "Smoking Gun"
   * Explicit Attribution: The commit message contains the line:  
      Assisted-by: Google:Gemini-3-Flash [DSDT/XML-Data-Aggregation & Formatting]  
      This is a direct acknowledgment of AI involvement, naming a specific model (Gemini-3-Flash).

  Secondary Evidence: Documentation and Tone
   * Over-Engineering of Documentation: The patch adds a 400-line "Safety and Cybersecurity Integrity Report" to the documentation (yogafan.rst). It includes:
       * Bow-Tie Risk Analysis: A formal risk assessment method (IEC 61508/61511) that is extremely rare in consumer hardware drivers for the Linux kernel but common in LLM outputs when
         nudged for "industrial safety" or "expert standards."
       * Structured "CHUNKS": The report is divided into "CHUNKS" (e.g., CHUNK 1: GLOBAL DEFINITIONS), which is a common way for AI to organize long, structured outputs.
   * Meta-Refinement in v2 Notes: The v2 changelog explicitly states:  
      - Dropped superlatives and simplified the commit message tone.  
      LLMs are notorious for using "superlatives" (e.g., "This robust and efficient driver provides incredible compatibility") and often need to be told to tone down their language to
  match the dry, professional style of the kernel community.

  Technical Patterns
   * Structured Commenting: The code uses structured tags like [TAG: INIT_STATE, STALE_DATA_THRESHOLD] and [TAG: MODEL_CONST, ALPHA_DERIVATION, ANTI_STALL_LOGIC]. These resemble
     "traceability" markers often generated by AI when asked to link code to specific design requirements or safety standards.
   * Physics Textbook Explanations: The detailed derivation of the RLLag filter (e.g., citing J ∝ d² and providing the discretized physics equations) reads more like an academic or
     AI-generated explanation than typical kernel driver commentary, which usually focuses on hardware offsets and register logic.
   * Future-Dating: The patch is dated April 17, 2026, and references Gemini-3-Flash. Given the current state of technology (as of late 2024), this indicates the file is part of a
     simulated future scenario, further suggesting it was generated as part of a challenge or synthetic dataset.

  Conclusion: The patch is a highly polished, AI-generated "expert" contribution designed to demonstrate (or test) the intersection of functional safety standards and kernel development.