Store the spi_device_id at probe entry and reuse it for the name and
chip info instead of calling spi_get_device_id() repeatedly.

While at it, reshuffle variable list in a reverse Christmas tree
order. No functional change intended.

Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
---
v2->v3: Split cachine spi device id patch from the  dev cleanup.
---
 drivers/iio/accel/sca3000.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/accel/sca3000.c b/drivers/iio/accel/sca3000.c
index 9ef4d6e27466..a0b431aff024 100644
--- a/drivers/iio/accel/sca3000.c
+++ b/drivers/iio/accel/sca3000.c
@@ -1439,9 +1439,10 @@ static const struct iio_info sca3000_info = {
 
 static int sca3000_probe(struct spi_device *spi)
 {
-	int ret;
+	const struct spi_device_id *id = spi_get_device_id(spi);
 	struct sca3000_state *st;
 	struct iio_dev *indio_dev;
+	int ret;
 
 	indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
 	if (!indio_dev)
@@ -1451,10 +1452,9 @@ static int sca3000_probe(struct spi_device *spi)
 	spi_set_drvdata(spi, indio_dev);
 	st->us = spi;
 	mutex_init(&st->lock);
-	st->info = &sca3000_spi_chip_info_tbl[spi_get_device_id(spi)
-					      ->driver_data];
+	st->info = &sca3000_spi_chip_info_tbl[id->driver_data];
 
-	indio_dev->name = spi_get_device_id(spi)->name;
+	indio_dev->name = id->name;
 	indio_dev->info = &sca3000_info;
 	if (st->info->temp_output) {
 		indio_dev->channels = sca3000_channels_with_temp;
-- 
2.47.3

On Tue, Feb 03, 2026 at 04:20:45AM -0800, Harshit Mogalapalli wrote:
> Store the spi_device_id at probe entry and reuse it for the name and
> chip info instead of calling spi_get_device_id() repeatedly.
> 
> While at it, reshuffle variable list in a reverse Christmas tree
> order. No functional change intended.

Did you miss David's comment? AFAIU the suggestion was to convert to
chip_info(). With that done, this should use spi_device_get_match_data()
(or something like that, I don't remember the correct spelling of that API).

-- 
With Best Regards,
Andy Shevchenko

Hi Andy,

On 03/02/26 20:49, Andy Shevchenko wrote:
> On Tue, Feb 03, 2026 at 04:20:45AM -0800, Harshit Mogalapalli wrote:
>> Store the spi_device_id at probe entry and reuse it for the name and
>> chip info instead of calling spi_get_device_id() repeatedly.
>>
>> While at it, reshuffle variable list in a reverse Christmas tree
>> order. No functional change intended.
> 
> Did you miss David's comment? AFAIU the suggestion was to convert to
> chip_info(). With that done, this should use spi_device_get_match_data()
> (or something like that, I don't remember the correct spelling of that API).
> 

I was thinking of dealing with it in a separate series(as documented in 
the cover letter). Also David pointed out that if I am planning to do 
that conversion separate, there is no neccesity of this patch, as it is 
anyway going to be replaced soon when I have that ready. So I will drop 
this simplification in my next version and leave the conversion to 
spi_device_get_match_data() to another patch set. Will also include your 
"irq > 0" check fixup in the following series. Hope you are okay with that ?

Thanks a lot for the review!


Regards,
Harshit

On Tue, Feb 03, 2026 at 09:25:08PM +0530, Harshit Mogalapalli wrote:
> On 03/02/26 20:49, Andy Shevchenko wrote:
> > On Tue, Feb 03, 2026 at 04:20:45AM -0800, Harshit Mogalapalli wrote:
> > > Store the spi_device_id at probe entry and reuse it for the name and
> > > chip info instead of calling spi_get_device_id() repeatedly.
> > > 
> > > While at it, reshuffle variable list in a reverse Christmas tree
> > > order. No functional change intended.
> > 
> > Did you miss David's comment? AFAIU the suggestion was to convert to
> > chip_info(). With that done, this should use spi_device_get_match_data()
> > (or something like that, I don't remember the correct spelling of that API).
> 
> I was thinking of dealing with it in a separate series(as documented in the
> cover letter). Also David pointed out that if I am planning to do that
> conversion separate, there is no neccesity of this patch, as it is anyway
> going to be replaced soon when I have that ready. So I will drop this
> simplification in my next version and leave the conversion to
> spi_device_get_match_data() to another patch set. Will also include your
> "irq > 0" check fixup in the following series. Hope you are okay with that ?

As long as there is no added churn I'm fine with the approach.

-- 
With Best Regards,
Andy Shevchenko