Re: [PATCH v4 2/2] platform/x86: dell-uart-backlight: recover from stray EC response byte

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

On Sat, Oct 17, 2026 at 01:07:04PM +0530, chitranshmandhaniya@gmail.com wrote:
> 
> On some Dell All-in-One machines the EC occasionally inserts a spurious
> byte after the command echo in UART backlight response frames. For
> example a get-brightness reply that should be "04 0c 0a e5" arrives as
> "04 0c 0d 0a e5". The length field still reflects the original frame
> size, so the parser treats the stray byte as payload and the real
> payload as the checksum, producing a spurious -EIO.

This is very good example of the "bad" data. The character I believe is not
spurious at all. This is an UART communication which may be raw or line-based.
If you think of the UART line discipline, then the inserted character makes
a lot of sense, id est \n is replaced by \r\n.

Can you confirm that the only problematic one is 0x0a when we get 0x0d before?
If so, I think the issue can be addressed in a better way.

> Add single-attempt recovery inside dell_uart_bl_receive_data(): on a
> checksum mismatch for a frame longer than the minimum size, drop the
> byte at the first payload offset, shift the remaining data down by one,
> and decrement resp_idx so serdev re-delivers the real checksum byte on
> the next callback. Status remains -EBUSY, so no special handling is
> needed in the caller.
> 
> A per-transaction resync_used flag, cleared at the start of each
> command, limits recovery to one attempt. A second mismatch is a hard
> -EIO. Well-formed frames never enter the recovery path.
> 
> Tested on Dell OptiPlex AIO 7410 65W (board 0TKWC4) where the EC
> inserts a stray byte on every get-brightness response.


-- 
With Best Regards,
Andy Shevchenko