From: Dan Carpenter <error27@gmail.com>
To: suryasaimadhu <suryasaimadhu369@gmail.com>
Cc: andy@kernel.org, gregkh@linuxfoundation.org,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: fbtft: fix unaligned access and txbuf safety issues
Date: Thu, 25 Jun 2026 15:00:47 +0300 [thread overview]
Message-ID: <aj0YbygQwhlga4Om@stanley.mountain> (raw)
In-Reply-To: <20260625114215.325973-1-suryasaimadhu369@gmail.com>
On Thu, Jun 25, 2026 at 07:42:15PM +0800, suryasaimadhu wrote:
> This patch addresses several pre-existing issues in the fbtft driver:
>
> 1. define_fbtft_write_reg(): when par->startbyte is set, buf is
> advanced by one byte creating a misaligned pointer for 16-bit types.
> Use put_unaligned() for register writes and fix the SPI transfer
> size from len * (sizeof(data_type) + offset) to
> len * sizeof(data_type) + offset.
>
> 2. fbtft_write_vmem16_bus8() and fb_ra8875 write_vmem16_bus8(): same
> unaligned 16-bit stores when txbuf is byte-offset for a start
> prefix. Use put_unaligned() for pixel data copies.
>
> 3. tx_array_size underflow: both vmem helpers subtract 2 from
> tx_array_size when a startbyte prefix is used. A small txbuflen
> device property causes unsigned underflow and out-of-bounds heap
> writes. Fall back to the non-buffered write path when the buffer
> is too small.
>
> 4. fb_ra8875 write_vmem16_bus8(): missing NULL check for
> par->txbuf.buf, which remains NULL on big-endian when txbuflen is
> 0 because the PAGE_SIZE fallback is little-endian only. Fall back
> to direct write when the buffer is missing.
>
> Also replace empty modifier arguments in define_fbtft_write_reg() with
> a no-op macro to fix checkpatch warnings.
>
> Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
Is this how you would sign a legal document?
This patch does too many things at once. Split it up. Also please
a delay between sending us patches. Otherwise it's overwhelming to
deal with. Bunch them together in a patchset instead of sending them
one by one.
regards,
dan carpenter
next prev parent reply other threads:[~2026-06-25 12:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 10:30 [PATCH] staging: fbtft: fix unaligned access and buffer size when startbyte is used suryasaimadhu
2026-06-25 10:42 ` sashiko-bot
2026-06-25 11:02 ` [PATCH] staging: fbtft: fix unaligned vmem writes when txbuf is byte-offset suryasaimadhu
2026-06-25 11:16 ` sashiko-bot
2026-06-25 11:42 ` [PATCH] staging: fbtft: fix unaligned access and txbuf safety issues suryasaimadhu
2026-06-25 11:54 ` sashiko-bot
2026-06-25 12:00 ` Dan Carpenter [this message]
2026-06-25 14:05 ` Andy Shevchenko
2026-06-25 13:20 ` [PATCH] staging: fbtft: fix unaligned vmem writes when txbuf is byte-offset kernel test robot
2026-06-25 13:53 ` kernel test robot
2026-06-25 13:59 ` Andy Shevchenko
2026-06-25 14:08 ` [PATCH] staging: fbtft: fix unaligned access and buffer size when startbyte is used Andy Shevchenko
2026-06-26 6:48 ` David Laight
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=aj0YbygQwhlga4Om@stanley.mountain \
--to=error27@gmail.com \
--cc=andy@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=suryasaimadhu369@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.