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

[Sanjay Chitroda]

On 26 April 2026 8:05:40 pm IST, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>On Sun, 26 Apr 2026 14:47:10 +0530
>Sanjay Chitroda <sanjayembeddedse@xxxxxxxxx> wrote:
>
>> From: Sanjay Chitroda <sanjayembeddedse@xxxxxxxxx>
>> 
>> 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@xxxxxxxxx>
>
>> 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;