Re: [RFC PATCH] scsi: core: Drop Scsi_Host.default_lock

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Finn,

On 06/08/2026 12:35 PM, Finn Thain wrote:
> 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?

Not wanting to set a precedent, but seeing as Russell may be the only 
maintainer still in a position to build and hopefully test these 
drivers, moving responsibility for driver code to the arch maintainer 
may be justified here.

I must admit I've been dreadfully slack in testing recent code myself, 
ever since I started running out of memory at boot ...

Cheers,

     Michael