On Wed, Dec 08, 2021 at 07:59:00AM +0100, Alexander Stein wrote:
> Am Dienstag, dem 07.12.2021 um 12:57 +0000 schrieb Mark Brown:

> > Do we need to use the num_cs property or can we just set num_chipselect
> > to whatever the maximum value that can be set is?  I've never been 100%
> > clear on why num-cs is in the binding.

> I see two things which needs to be considered when setting
> num_chipselect:

> 1.
> The hardware limitation in the uC. The i.MX8XQP RM says:
> >  The entire CS field is not fully supported in every LPSPI module
> > instance. Refer to the chip-specific information for LPSPI.

> This indicates there are some i.MX, not necessarily i.MX8 only, which
> have more than 2 hardware chip selects. This might be set depending on
> the compatible.

Yes, this sounds like it should be figured out from the compatible and
not need a separate property - that's usually better in general if
there's quirks in the IP configuration in different SoCs.

> 2.
> The hardware limitation on the SOM and/or mainboard. E.g. even if the
> uC supports 2 chip selects, only one may be available on the board
> connector. This is something which can only be set in the DT.
> This case is what this patch is about: Providing 2 hardware chip
> selects, as the default (if unset) is just one.

Given that we won't try to enable a chip select unless there's something
connected to it this shouldn't be an issue - with a lot of designs you
can't avoid doing that anyway since the chip selects are all in a single
register.  If the pin isn't connected (or the signal not pinmuxed out)
that doesn't seem like a problem?