drivers: spi: stm32: fix hardware NSS management
drivers: spi: stm32: fix hardware NSS management

The LL_SPI_NSS_* macros used in spi_stm32_configure() when
hardware-based NSS management is requested are incorrect; fix them.

In master mode, this seems like a copy/paste error. The slave mode
case is likely due to following incorrect documentation in the ST LL
headers.

Note that in my testing on STM32F4, NSS appears to be open drain when
managed by hardware, making that configuration harder to test (and
probably less useful).

Details for the curious:

    The ST LL headers (for example stm32f4xx_ll_spi.h) claim
    LL_SPI_NSS_HARD_INPUT is to be used only in master mode, and
    LL_SPI_NSS_HARD_OUTPUT is to be used in slave mode.

    The opposite is true: when NSS is not handled by software, the SPI
    peripheral is responsible for driving NSS as an output, and the
    slave peripheral is responsible for reading it as an input.

    This is an error in the LL header files; the reference manuals and
    the other LL code make this clear.

    - The ST reference manuals specify that LL_SPI_HARD_OUTPUT (which
      corresponds to SSM unset, SSOE set) is a master-only
      configuration.  For example, STM32 RM0368 says:

        "NSS output enabled (SSM = 0, SSOE = 1)

        This configuration is used only when the device operates in
        master mode."

    - LL_SPI_HARD_INPUT (SSM unset, SSOE unset) is either a master or
      a slave configuration; in the slave case (which is what we're
      interested in here), it corresponds to the "usual" NSS
      input. RM0368, again:

        "NSS output disabled (SSM = 0, SSOE = 0)

        This configuration allows multimaster capability for devices
        operating in master mode. For devices set as slave, the NSS
        pin acts as a classical NSS input: the slave is selected when
        NSS is low and deselected when NSS high."

      The LL_SPI_StructInit() implementations similarly combine
      LL_SPI_MODE_SLAVE with LL_SPI_NSS_HARD_INPUT.

Signed-off-by: Marti Bolivar <9d90ac4c7bf6a305f6bfd81a23c7859bc883380e@linaro.org>

GiulianoFranchetto/zephyr,zephyriot/zephyr,runchip/zephyr-cc3220,galak/zephyr,rsalveti/zephyr,zephyriot/zephyr,zephyrproject-rtos/zephyr,rsalveti/zephyr,aceofall/zephyr-iotos,GiulianoFranchetto/zephyr,fbsder/zephyr,Vudentz/zephyr,explora26/zephyr,aceofall/zephyr-iotos,mbolivar/zephyr,kraj/zephyr,finikorg/zephyr,fbsder/zephyr,ldts/zephyr,fbsder/zephyr,aceofall/zephyr-iotos,explora26/zephyr,zephyriot/zephyr,kraj/zephyr,fbsder/zephyr,nashif/zephyr,runchip/zephyr-cc3220,GiulianoFranchetto/zephyr,rsalveti/zephyr,finikorg/zephyr,galak/zephyr,Vudentz/zephyr,mbolivar/zephyr,galak/zephyr,explora26/zephyr,nashif/zephyr,ldts/zephyr,runchip/zephyr-cc3220,zephyrproject-rtos/zephyr,zephyrproject-rtos/zephyr,Vudentz/zephyr,explora26/zephyr,aceofall/zephyr-iotos,kraj/zephyr,finikorg/zephyr,finikorg/zephyr,punitvara/zephyr,nashif/zephyr,rsalveti/zephyr,mbolivar/zephyr,Vudentz/zephyr,punitvara/zephyr,kraj/zephyr,nashif/zephyr,ldts/zephyr,ldts/zephyr,aceofall/zephyr-iotos,rsalveti/zephyr,explora26/zephyr,galak/zephyr,kraj/zephyr,finikorg/zephyr,runchip/zephyr-cc3220,fbsder/zephyr,punitvara/zephyr,zephyrproject-rtos/zephyr,mbolivar/zephyr,runchip/zephyr-cc3220,zephyrproject-rtos/zephyr,GiulianoFranchetto/zephyr,nashif/zephyr,punitvara/zephyr,Vudentz/zephyr,punitvara/zephyr,galak/zephyr,ldts/zephyr,GiulianoFranchetto/zephyr,Vudentz/zephyr,zephyriot/zephyr,zephyriot/zephyr,mbolivar/zephyr