On Fri, 2020-09-04 at 10:57 -0300, Fabio Estevam wrote: > On Fri, Sep 4, 2020 at 10:02 AM Matthias Schiffer > <matthias.schiffer@xxxxxxxxxxxxxxx> wrote: > > > This would make num_chipselect default to 1 again (set by > > __spi_alloc_controller()), breaking every i.MX board that uses more > > than 1 native CS. > > Which boards are that? Are you referring to non-DT i.MX boards? > > If so, I have sent a patch removing all non-DT i.MX boards. > > > I'm aware that using cs-gpios instead of native CS is probably a > > good > > idea in any case, as the native CS of this SPI controller is kinda > > flaky (and at a glance it looks like all in-tree DTs do this; not > > sure > > about board files that don't use DTs?), but I'm not convinced that > > breaking native CS support completely is desirable either. > > Initial i.MX chips with this SPI IP had issues in using chip-select > in > native mode and GPIO chip-select has been used since them. > > Do we have i.MX dts that make use of native chip select? As mentioned in my previous mail, all in-tree DTS use cs-gpios (unless I've overlooked something - I grepped for CSPIn_SSm pinmuxings), so removing support for native CS should not break anything we know of. Nevertheless, I don't see why we should deliberately remove the native CS support - my understanding was that we try to avoid breaking changes to DT interpretation even for unknown/out-of-tree DTS.