Re: [PATCH v5] fbtft: limit dirty rows based on damage range

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Thu, Jan 29, 2026 at 09:29:26AM +0300, Dan Carpenter wrote:
> On Thu, Jan 29, 2026 at 05:39:38AM +0900, ChanSoo Shin wrote:
> > Instead of marking the entire display as dirty, calculate the start
> > and end rows based on the damage offset and length and only mark the
> > affected rows dirty. This reduces unnecessary full framebuffer updates
> > for partial writes.
> > 
> > Signed-off-by: ChanSoo Shin <csshin9928@gmail.com>
> > ---
> 
> TL/DR:  I suck as a reviewer so I would be nervous to apply this
> without testing.  Andy is an expert here and we trust him so if he's
> okay with it then great.  Or if some other expert could sign off, but
> I don't know enough to sign off myself.

The rule of thumb for _this_ driver (or set of drivers under FBTFT) is
that: we are in maintenance mode and we only accept bugfixes or treewide
changes. The rest can be accepted but unlikely. Either way, we really
want to see this (kind of changes) being tested on real HW. It's not as
simple as renaming variable 'i' to 'j'.

> The problem for me is how do I review something like this?  Staging
> is a grab bag of different modules and I'm not an expert in any of
> the subsystems.  Normally, it's easy to review staging patches
> because they are clean up work which does change how the code works
> so I just look for unintentional side effects.
> 
> It's trickier to review a patch like this which changes runtime.  If
> it were fixing a bug, then I could verify the bug is real and say
> well, "Maybe the fix is wrong, but we were going to corrupt memory
> anyway, so the worst case is that it is as bad as before.  It can't
> make the problem worse."
> 
> This is your first kernel patch.  You don't work for a company that
> makes the hardware.  You said earlier in a private email that this
> hasn't been tested.

Unfortunately it is not the best driver to go with this. At some point I might
be able to test this when I setup my fbtft minilab at home, I have a few I²C,
SPI, and parallel panels.

> The patch looks reasonable to me, but it also looks simple.  If it
> were that easy why didn't the original author do it?

-- 
With Best Regards,
Andy Shevchenko