From: Breno Rodrigues Alves <breno3011alves@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux@armlinux.org.uk, Bart Van Assche <bvanassche@acm.org>,
James.Bottomley@HansenPartnership.com, mkp@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org,
Breno Rodrigues Alves <breno3011alves@gmail.com>
Subject: Re: [PATCH v4] scsi: arm: Convert acornscsi-io.S to C
Date: Thu, 22 Oct 2026 18:48:15 -0300 [thread overview]
Message-ID: <20261022214815.86306-1-breno3011alves@gmail.com> (raw)
In-Reply-To: <871p9h1kc7.fsf@trenco.lwn.net>
Hi Jonathan,
Fair question - the change is a conversion, and I do not have a RiscPC
with an Acorn SCSI card to test on real hardware. Here is what I did
test:
1. Userspace unit test with a mocked MMIO layer
I built a small harness that compiles acornscsi-io.c unmodified
against stub <linux/io.h> and <linux/types.h> headers. The stubs
map readl()/writel()/writeb() onto a byte-addressable "card" buffer
and a plain userspace memory buffer. For each transfer length L in
{0, 2, 4, 8, 16, 32, 64, 100, 512, 1000}:
- __acornscsi_in: I filled the "card" with L bytes of a known
pattern (each 32-bit card word carrying one 16-bit halfword in
the low half, garbage in the high half) and verified that the
output buffer matched the pattern byte-for-byte.
- __acornscsi_out: I filled a userspace buffer with a known
pattern, called the function, and verified that each 32-bit card
word held the expected halfword duplicated in both halves.
All 20 cases pass. This is the harness that caught the two issues
the sashiko bot later reported independently - it is not just a
smoke test.
2. Cross-compile for the target
Built with arm-linux-gnueabi-gcc on rpc_defconfig with
CONFIG_SCSI_ACORNSCSI_3=m. The module links cleanly
(acornscsi_mod.ko), and nm on acornscsi-io.o shows:
00000000 T __acornscsi_in
00000104 T __acornscsi_out
objdump on the resulting object shows that the alignment step
compiles to "bic sl, r0, #3", matching the original assembly's
"bic r0, r0, #3".
3. Apply to a clean tree and rebuild
Copied the tree, git reset --hard to the parent commit, applied the
patch with "git am". It applies cleanly; re-running the same
compile command produces the same object. This confirms the patch
file itself is intact and does not depend on my working tree state.
4. checkpatch.pl --strict --no-tree on the patch itself
Reports 0 errors, 0 warnings (with FILE_PATH_CHANGES ignored, as
drivers/scsi/arm/ is already covered by MAINTAINERS).
What I did NOT test:
- Real hardware. I do not have an Acorn RiscPC or the SCSI expansion
card. The unit test proves equivalence with the original assembly
semantics, but it cannot prove that the semantics match the actual
hardware - only that the C version does the same thing the assembly
did.
- Odd transfer lengths through acornscsi.c. All current callers pass
even lengths, so the trailing-byte path is only exercised by the
unit test, not by the driver end-to-end.
- Interrupt handling under load. This is unchanged by the patch (the
IRQ path is untouched), so I did not add specific coverage.
If there is a specific test or configuration you would like me to run,
please let me know.
Breno
next prev parent reply other threads:[~2026-10-22 21:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 18:36 [PATCH 0/1] " Breno Rodrigues Alves
2026-10-22 18:36 ` [PATCH] " Breno Rodrigues Alves
2026-10-22 18:52 ` [PATCH v2 0/1] " Breno Rodrigues Alves
2026-10-22 18:52 ` [PATCH v2] " Breno Rodrigues Alves
2026-10-22 19:22 ` Bart Van Assche
2026-10-22 20:30 ` Breno Rodrigues Alves
2026-10-22 21:02 ` Breno Rodrigues Alves
2026-10-22 20:30 ` [PATCH v3] " Breno Rodrigues Alves
2026-10-22 20:49 ` Bart Van Assche
2026-10-22 21:02 ` [PATCH v4] " Breno Rodrigues Alves
2026-10-22 21:36 ` Bart Van Assche
2026-10-22 21:44 ` Jonathan Corbet
2026-10-22 21:48 ` Breno Rodrigues Alves [this message]
2026-10-22 22:15 ` Jonathan Corbet
2026-10-22 22:28 ` Breno Rodrigues Alves
2026-10-22 22:46 ` Jonathan Corbet
2026-10-22 23:00 ` Breno Rodrigues Alves
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=20261022214815.86306-1-breno3011alves@gmail.com \
--to=breno3011alves@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bvanassche@acm.org \
--cc=corbet@lwn.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mkp@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®