Re: [PATCH v3 2/2] spi: qcom-geni: Use GPIO to notify master of SPI target activity
Praveen Talari <[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]> |
Hi konrad
On 19-08-2026 19:30, Konrad Dybcio wrote:
> 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
Oh, let me review and update.
>
> [...]
>
>> @@ -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?
There is no specific reason. i just had choosen with index.
>
> i.e. why not just devm_gpiod_get_optional()?
Yes, we can use it.
Thanks,
Praveen Talari
>
> Konrad