Re: [PATCH v3 2/2] spi: qcom-geni: Use GPIO to notify master of SPI target activity
Konrad Dybcio <[email protected]>
| Newsgroups | org.kernel.vger.linux-spi,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 8/18/26 3:38 PM, Praveen Talari wrote:
> When operating in SPI target mode, the GENI controller relies on an
> external GPIO to notify the SPI master about the target's active state.
>
> Add support for an optional ready GPIO that is asserted when a target
> transfer begins and deasserted when the transfer completes, is aborted,
> or hits a timeout. This allows the target to explicitly signal its
> availability to the master and ensures the GPIO is released in all error
> and completion paths, preventing the master from observing a stale or
> incorrect target-ready indication.
[...]
> + if (spi->target && mas->target_gpio)
> + gpiod_set_value(mas->target_gpio, 0);
FWIW it seems like the gpiod APIs can eat nullptrs
[...]
> @@ -1131,8 +1144,16 @@ static int spi_geni_probe(struct platform_device *pdev)
> init_completion(&mas->rx_reset_done);
> spin_lock_init(&mas->lock);
>
> - if (spi->target)
> + if (spi->target) {
> spi->target_abort = spi_geni_target_abort;
> + mas->target_gpio = devm_gpiod_get_index_optional(dev, "ready", 0,
> + GPIOD_OUT_LOW);
Is there a reason for the get_index_ variant specifically?
i.e. why not just devm_gpiod_get_optional()?
Konrad