linux-kernel - Re: [PATCH 6/7] iio: adc: ad485x: add ad485x driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241005182729.014819df@jic23-huawei>
Date: Sat, 5 Oct 2024 18:27:29 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: "Miclaus, Antoniu" <Antoniu.Miclaus@...log.com>
Cc: David Lechner <dlechner@...libre.com>, Andy Shevchenko
 <andy@...nel.org>, Lars-Peter Clausen <lars@...afoo.de>, "Hennerich,
 Michael" <Michael.Hennerich@...log.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, "Sa, Nuno" <Nuno.Sa@...log.com>, Olivier Moysan
 <olivier.moysan@...s.st.com>, Uwe Kleine-König
 <ukleinek@...nel.org>, "Schmitt, Marcelo" <Marcelo.Schmitt@...log.com>,
 João Paulo Gonçalves
 <joao.goncalves@...adex.com>, Mike Looijmans <mike.looijmans@...ic.nl>,
 Dumitru Ceclan <mitrutzceclan@...il.com>, AngeloGioacchino Del Regno
 <angelogioacchino.delregno@...labora.com>, Alisa-Dariana Roman
 <alisadariana@...il.com>, "Cuciurean, Sergiu"
 <Sergiu.Cuciurean@...log.com>, "Bogdan, Dragos" <Dragos.Bogdan@...log.com>,
 "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>
Subject: Re: [PATCH 6/7] iio: adc: ad485x: add ad485x driver

On Fri, 4 Oct 2024 14:07:37 +0000
"Miclaus, Antoniu" <Antoniu.Miclaus@...log.com> wrote:

> > On 10/3/24 5:14 AM, Miclaus, Antoniu wrote:  
> > >> On 10/1/24 8:51 AM, Miclaus, Antoniu wrote:  
> > >>>>> Regarding the bulk writes/reads, the msb/mid/lsb registers need to be
> > >>>>> read/write in a specific order and the addresses are not incremental,  
> > >>>>
> > >>>> We have _noinc() variants of regmap accessors.  
> > >>> [Miclaus, Antoniu]
> > >>> I think _noinc() functions read from the same register address so it doesn't
> > >>> apply.
> > >>> I am reading values from multiple register addresses that are not reg_addr,
> > >>> reg_addr+1, reg_addr+2.  
> > >>
> > >> I'm confused by the statement that the registers are not incremental.
> > >>
> > >> For example, this patch defines...
> > >>
> > >> +#define AD485X_REG_CHX_OFFSET_LSB(ch)
> > >> 	AD485X_REG_CHX_OFFSET(ch)
> > >> +#define AD485X_REG_CHX_OFFSET_MID(ch)
> > >> 	(AD485X_REG_CHX_OFFSET_LSB(ch) + 0x01)
> > >> +#define AD485X_REG_CHX_OFFSET_MSB(ch)
> > >> 	(AD485X_REG_CHX_OFFSET_MID(ch) + 0x01)
> > >>
> > >> This looks exactly like reg_addr, reg_addr+1, reg_addr+2 to me.  
> > > Yes you are right. Although I tested with hardware and it seems that the  
> > registers  
> > > are not properly written when using bulk operations. My guess is that  
> > holding CS low during  
> > > the entire transaction might be a possible issue. Any suggestions are  
> > appreciated.
> > 
> > Is ADDR_DIR in SPI_CONFIG_A set to the correct value to match how
> > the regmap is configured for bulk writes?
> > 
> > I had to set this bit for AD4695 which has a similar register map
> > (although on that one I used two regmaps, an 8-bit one and a 16-bit
> > one, instead of doing bulk operations on the 8-bit one).
> >   
> Thanks for the input! I tried your suggested approach: set the ADDR_DIR
> to 1 during probe. Unfortunately, this did not fix the issue. I am still not able
> to perform bulk writes properly to the device.
> 
> For now I will keep the only working version in v2, since there will be
> most probably  other iterations of the this patch series 😊.
I'd definitely like to know what is going on here if you can dig into it.
But if we really get stuck then the code at least needs a comment saying
it is necessary and we aren't sure why.  If we know why and can't change
it then the comment should give that reasoning.

Jonathan

> 
> > >  
> > >>>  
> > >>>>> so I am not sure how the bulk functions fit. On this matter, we will need
> > >>>>> unsigned int (not u8) to store the values read via regmap_read, and in  
> > this  
> > >>>>> case we will need extra casts and assignments to use get_unaligned.  
> > >>>>
> > >>>> --
> > >>>> With Best Regards,
> > >>>> Andy Shevchenko
> > >>>>  
> > >>>  
> > >  
>