From: Fabio Piparo <holofermes@gmail.com>
To: sashiko-reviews@lists.linux.dev,
Javier Martinez Canillas <javierm@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Amit Barzilai <amit.barzilai22@gmail.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Fabio Piparo <holofermes@gmail.com>
Subject: Re: [PATCH] drm/ssd130x: Set the address window in ssd132x_clear_screen()
Date: Mon, 17 Aug 2026 18:24:01 -0400 [thread overview]
Message-ID: <20260817222401.906748-1-holofermes@gmail.com> (raw)
In-Reply-To: <20260817154126.D13271F000E9@smtp.kernel.org>
I can confirm that one of Sashiko's findings is correct, and it's not
limited to my use case: with the early return on !plane_state->crtc,
the clear in this path never runs at all.
I also have to retract the testing note. I did more testing, and the
blackout I had attributed to clear_screen during bring-up was
something else entirely, not the clear writing RAM. So "Exercised on
an SPI SSD1322" is wrong. The asymmetry itself is still valid I think
(the sibling ssd130x_clear_screen() sets the window, this one
doesn't), and the patch stands on inspection and compile testing
only. Happy to reword the commit message in a v2 if the cleanup is
still wanted, or drop it.
The other finding, the out-of-bounds read in ssd132x_update_rect(),
looks real too, but it's pre-existing and separate from this patch.
Thanks,
Fabio
prev parent reply other threads:[~2026-08-17 22:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 15:24 [PATCH] drm/ssd130x: Set the address window in ssd132x_clear_screen() Fabio Piparo
2026-08-17 15:41 ` sashiko-bot
2026-08-17 22:24 ` Fabio Piparo [this message]
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=20260817222401.906748-1-holofermes@gmail.com \
--to=holofermes@gmail.com \
--cc=airlied@gmail.com \
--cc=amit.barzilai22@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/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.