Re: [PATCH v7 9/9] iio: ssp_sensors: reuse embedded RX buffer for SPI transfers

Sanjay Chitroda
2026-05-03T14:17:16Z

On 26 April 2026 8:05:40 pm IST, Jonathan Cameron <jic23@kernel.org> wrote:
>On Sun, 26 Apr 2026 14:47:10 +0530
>Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:
>
>> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>>
>> Avoid allocating a temporary DMA buffer in the interrupt context when
>> handling hub-to-AP and AP-to-hub SPI write messages.
>>
>> Replace the dynamically allocated RX buffer with a fixed-size,
>> preallocated buffer embedded in the driver structure and reused for all
>> SPI receive operations. This removes memory allocation from the
>> IRQ path, simplifies lifetime management.
>>
>> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
>> diff --git a/drivers/iio/common/ssp_sensors/ssp_spi.c b/drivers/iio/common/ssp_sensors/ssp_spi.c
>> index 870214551f0b..e41da88bf96d 100644
>> --- a/drivers/iio/common/ssp_sensors/ssp_spi.c
>> +++ b/drivers/iio/common/ssp_sensors/ssp_spi.c
>> @@ -339,7 +339,7 @@ static int ssp_parse_dataframe(struct ssp_data *data, char *dataframe, int len)
>> /* threaded irq */
>> int ssp_irq_msg(struct ssp_data *data)
>> {
>> - char *buffer;
>> + char *buffer = data->rx_buf;
>> u8 msg_type;
>> int ret;
>> u16 length, msg_options;
>> @@ -383,19 +383,12 @@ int ssp_irq_msg(struct ssp_data *data)
>> * but the slave should not send such ones - it is to
>> * check but let's handle this
>> */
>> - buffer = kmalloc(length, GFP_KERNEL | GFP_DMA);
>As bellow.
>
>> - if (!buffer) {
>> - ret = -ENOMEM;
>> - goto _unlock;
>> - }
>>
>> /* got dead packet so it is always an error */
>> ret = spi_read(data->spi, buffer, length);
>> if (ret >= 0)
>> ret = -EPROTO;
>>
>> - kfree(buffer);
>> -
>> dev_err(SSP_DEV, "No match error %x\n",
>> msg_options);
>>
>> @@ -428,22 +421,13 @@ int ssp_irq_msg(struct ssp_data *data)
>> mutex_unlock(&data->pending_lock);
>> break;
>> case SSP_HUB2AP_WRITE:
>> - buffer = kzalloc(length, GFP_KERNEL | GFP_DMA);
>Is there any chance that GFP_DMA marking is needed?
>

As per my understanding, this must be legacy flag as there is no direct use of any dma_* API. marking should be redundant and safe to drop.

>> - if (!buffer)
>> - return -ENOMEM;