Re: [RFC PATCH] scsi: core: Drop Scsi_Host.default_lock
Finn Thain <[email protected]> Thu, 6 Aug 2026 10:35:25 +1000 (AEST)
| Newsgroups | gmane.linux.scsi |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 5 Aug 2026, John Garry wrote:
> On 04/08/2026 21:08, Bart Van Assche wrote:
> >> Cool, I'll go through this. But how does it handle the arm v3-related
> >> drivers, like fas216? At a glance, the script requires gnu-
> >> a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07 - but I thought that HW like
> >> this requires an even earlier toolchain version.
> > Correct. I think that gcc-8 or older is required to generate correct
> > code. But generating correct code is not required to do build testing.
> > Hence the following hack in my script for 32-bit ARM architectures that
> > deletes a GCC version check from a Kconfig file:
> >
> > if [ "${arch%-*}" = "arm" ]; then
> > # gcc-9 and later do not support armv3m. Hence the sed commands below.
> > local f
> > for f in arch/arm/Kconfig arch/arm/mach-rpc/Kconfig; do
> > if [ -e "$f" ]; then
> > sed -i 's/GCC_VERSION < 90100 && //' "$f"
> > fi
> > done
> > sed -i 's/select CPU_32v3/select CPU_32v4/' arch/arm/mm/Kconfig
> > fi
>
> ok, I'll try it, thanks!
>
> I do have to question why we maintain support on modern kernels for such
> obsolete HW. The maintenance burden is not zero, as we see here ...
>
The non-zero maintenance burden is a two-way street. That's just the
downside of the "open" part of "open source", of course.
The maintainer for the relevant hardware port is Russell King whom you
forgot to Cc. But Linux on obsolete hardware is quite normal in my
experience, and the issue here is actually the compiler.
I'm not going to attempt to fix the compiler. I don't have the talent,
time, hardware etc. And yet the MAINTAINERS file lists Michael and I as
maintainers for two RISCPC drivers:
F: drivers/scsi/arm/cumana_1.c
F: drivers/scsi/arm/oak.c
Given the compiler problem, which I too have long had to work around when
build-testing NCR5380 drivers, and given that I have no ability to test
this hardware, I'm thinking of sending a patch to shift the responsibility
for these files from the NCR5380 entry to Russell's RISCPC entry in
MAINTAINERS.
Russell and Michael -- do you have any thoughts about this issue?