On Tue, 20 May 2025 22:49:06 +0300 Andy Shevchenko <andy@xxxxxxxxxx> wrote: > On Tue, May 20, 2025 at 09:32:18PM +0200, Lothar Rubusch wrote: > > Hi Andy, I forgot to put my mail addresses as well. I copied your answer > > now from the mailing list archive. Hence, sorry for the bad formatting > > of this mail. > > > > One question / remark down below. > > > > > On Sun, May 18, 2025 at 11:13:15AM +0000, Lothar Rubusch wrote: > > > > Evaluate the devicetree property for an optional interrupt line, and > > > > configure the interrupt mapping accordingly. When no interrupt line > > > > is defined in the devicetree, keep the FIFO in bypass mode as before. > > ... > > > > > + ret = regmap_write(data->regmap, ADXL313_REG_INT_MAP, regval); > > > > > > Don't you want to use regmap_assign_bits() or something like this to have > > > the above ternary be included? > > > > Thank you so much. I guess this is a function I was looking for quite > > a while and I know several places where to use it. > > > > Anyway, I saw, my hardware test setup still runs on an older kernel > > w/o regmap_assign_bits(). > > You are going to upstream the driver, right? So, we don't care about old > kernels as there was no such code at all, and since it's not a fix for > backporting I see no impediments to use the modern APIs. > > > So, I kindly liked to ask if you have any objections against leaving > > regmap_write() for now? Actually I'd prefer first to see the > > activity/inactivity stuff in, in case this will need some more > > modifications and I need to verify them on hardware. I think, leaving > > regmap_write() here would make that easier for this patch set. Please, > > let me know? > > Ask maintainers. I will not object if they agree on your justification. > Hmm. Given the good progress you are making on this driver anyway I'll go with 'maybe' particularly if you add a final patch on top that updates the code to use nicer bits of regmap that have been introduced more recently. Jonathan
