[Backport v4.4-branch] drivers: i2s: esp32: reject an unsupported trigger direction

[github-actions]

Backport 0d82dbb from #115721.

Original PR description:

---

What this fixes

i2s_esp32_trigger_check() validates the direction for I2S_DIR_BOTH and then does not validate it for either single direction. The I2S_DIR_BOTH branch checks all four pointers and returns -ENOSYS when the instance does not have both directions; the I2S_DIR_RX and I2S_DIR_TX branches read ->configured straight out of a stream that may not exist.

The instantiation macro gives a direction the devicetree does not describe a null conf and a null data, so on an instance that enables only one direction, triggering the other one dereferences NULL rather than returning an error. This adds the guard the I2S_DIR_BOTH branch already has, and returns the same -ENOSYS for the same reason: the hardware this instance describes cannot do what the caller asked.

Fixes #115719.

Why -ENOSYS rather than -EINVAL

-EINVAL is already used a few lines below for a direction value that is not one of the enumerators, which is a different mistake — a bad argument rather than a request the instance cannot serve. Keeping the two apart means a caller can tell "you passed nonsense" from "this instance has no TX", and it matches what I2S_DIR_BOTH already returns in exactly this situation.

Is this the only place with the same hole?

I checked rather than assumed, because a guard added to one function while its siblings keep the same gap is worse than no guard at all — it reads as if the class of bug has been dealt with.

Every other dereference of rx.data or tx.data in the file is already safe. Two of them sit behind an explicit dev_cfg->tx.data && test. The rest are inside the I2S_DIR_BOTH branch of this same function, or are reached only after active_dir has been set to I2S_DIR_BOTH, which cannot happen unless this function first validated all four pointers — the two reads in the callbacks are short-circuited by an active_dir == I2S_DIR_BOTH test, and the two in the start rollback sit inside if (dir == I2S_DIR_BOTH && err < 0). So these two branches were the only unguarded ones.

Verification

Built for esp32s3_devkitc/esp32s3/procpu and for esp32_devkitc/esp32/procpu, so both the GDMA and the non-GDMA halves of this driver are covered rather than only the one my own board takes.

I have not exercised the faulting path on hardware, because the board I have describes both directions and so cannot reach it. The change is a guard on a branch that was previously unguarded, and it does not alter behaviour for an instance that has the direction being triggered.

[thc1006]

Verified against the original fix and the v4.4 branch context. This is a clean backport and the affected code path is present here. No backport-specific issues found.