CS check on SPI loopback test case

[Raymond0225]

Describe the bug

On SPI loopback test case:
this test case failed -[spi_loopback.test_nop_nil_bufs] on DMA mode GPIO CS line.

This case failed is because RX and TX are both NULL and there is no any transfer in fact.
CS line should not be asserted and deasserted.
But in test code, what CS check is always there whatever transfer happens or not.

/* There should be two CS triggers during the transaction, start and end */
zassert_false(spi_loopback_gpio_cs_loopback_check(2));
zassert_ok(pm_device_runtime_put(spec->bus));

I think it is not reasonable.

Regression

• This is a regression.

Steps to reproduce

1. Work on NXP RT1050 EVK board.

2. import spi_loopback example.

3. Modify mimxrt1050_evk_mimxrt1052_hyperflash.overlay file, add
   / {
   zephyr,user {
   cs-loopback-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
   };
   };

4. connect J24 pin4 and pin5, connect J24 pin2 and pin3

5. build and run.

Relevant log output

- FAIL - [spi_loopback.test_nop_nil_bufs] duration = 0.015 seconds

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

Windows11, VSS , V4.1.99

Additional Context

No response

[decsny]

I agree with @Raymond0225 here, that if a transfer has 0 length, i.e., no clocks are even going to occur, I don't know why someone would do that, but, it probably shouldn't be required to even toggle the CS line in that case. So maybe we do change the test to not check that it toggles CS for that case. I also think that it shouldn't be required NOT to toggle though, I think it can be allowed to remain undefined, since this is a useless case AFAIK. I think the point of the test case is just to check that the system doesn't crash or anything from an edge case type of call like this.

I can edit the test for this change