Re: [PATCH 0/3] spi: spi-imx: fix use of more than four chip selects

[Rasmus Villemoes <rasmus.villemoes@xxxxxxxxx>]

On 26/04/2023 15.23, Rasmus Villemoes wrote:

>>> It's not exactly a regression, because any chip_select >= 4 never
>>> actually worked, but what I'm saying is that 87c614175bbf also isn't a
>>> complete fix if one wants to support mixing native and gpio chip
>>> selects. For that, one really needs the unused_native_cs to be used for
>>> all gpio chip selects; in particular, one needs some unused native cs to
>>> exist. IOW, what my series tries to do.
>>
>> No, we only need one unused chip select to be available.
> 
> Which is exactly what I'm saying, so I think we're in agreement.
> 
> I.e., something like this 3-patch series is needed to actually support
> mixing native and gpio chip selects (having the core verify that there
> is an unused chip select available, and provide that in the
> ->unused_native_cs field in the spi_controller). I don't think there's
> any textual conflict with 87c614175bbf, and the masking done by
> 87c614175bbf doesn't hurt, but also becomes irrelevant if this series is
> applied, since we'd never pass any value > 3 to those macros.

So, what's the conclusion here? Will these three patches be applied, or
will we just live with the status as of next-20230516, namely that

* for up to four slaves, any combination of native and gpio chip select
works

* with more then four slaves, CSn and CS(n&3) must be be gpios for all n
>= 4

?

Rasmus