linux-kernel - RE: [PATCH v8 2/2] iio: imu: smi240: add 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:
 <DB9PR10MB4730F796051995DDAFD03DBFCD472@DB9PR10MB4730.EURPRD10.PROD.OUTLOOK.COM>
Date: Thu, 17 Oct 2024 07:46:48 +0000
From: "Shen Jianping (ME-SE/EAD2)" <Jianping.Shen@...bosch.com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
CC: Jonathan Cameron <jic23@...nel.org>, "lars@...afoo.de" <lars@...afoo.de>,
	"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	"dima.fedrau@...il.com" <dima.fedrau@...il.com>, "marcelo.schmitt1@...il.com"
	<marcelo.schmitt1@...il.com>, "linux-iio@...r.kernel.org"
	<linux-iio@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Lorenz Christian (ME-SE/EAD2)"
	<Christian.Lorenz3@...bosch.com>, "Frauendorf Ulrike (ME/PJ-SW3)"
	<Ulrike.Frauendorf@...bosch.com>, "Dolde Kai (ME-SE/PAE-A3)"
	<Kai.Dolde@...bosch.com>
Subject: RE: [PATCH v8 2/2] iio: imu: smi240: add driver


>> >It should still need to place the two bytes of that 16 bit value in the correct order to send to hardware.  That may be handled via a 32 bit word length on SPI though.
>>
>>
>> This is the most confusing part.  During the request preparation, we focus on the bit order not the byte order. We need to bring the 16 bit value in the correct bit order, to the correct bit position in the 32 bit request. This is automatically guarantied using FIELD_PREP. FIELD_PREP shifts the data 15-0 to request 18-3. We shall never manually change the byte order of the 16 bit value. The byte order (of the whole request) becomes important when we send it over spi, which will be explained later.
>>
>>
>> >> In the SMI240, the register address is 8 bit and each register is 16 bit. We do not have any register value, which is bigger than 16 bit and need to be stored in multiple registers.  Therefore the device does not need endian. Neither big endian nor Little Endian.  To access the register, it is important to prepare the request frame according to the specification.
>> >>
>> >> A request is 32 bit
>> >>
>> >> 	ID	ADR	W	CAP	*	WDATA	CRC
>> >> 	31-30	29-22	21	20	19	18-3		2-0
>> >>
>> >> ID: device id (if more than 1 device)
>> >> ADR: reg address
>> >> W: write/read
>> >> CAP: capture mode on/off
>> >> *: reserved
>> >> WDATA : reg value bit 15-0
>> >> CRC: check sum
>> >>
>> >> To prepare the request properly, the bit order is here critical. We need to put each part in its bit position. The request is created as a local u32, with help of FIELD_PREP, we put the value of each part to its bit position. FIELD_PREP will take care of the cpu endian and always put the value to the correct bit position. Before we send the request via SPI, a cpu endian to big endian conversion is required.
>> >
>> >So there are two possibilities here.  Either the byte order is just reversed for the device in which case fine as you describe or perhaps the SPI transfers should be using a 32 bit word?  You'd do that by overriding the bits_per_word in the individual SPI transfers.
>> >
>> >
>> >> Since the spi bus transfers data using big endian. When we get the response from spi, the response is big endian and need to be converted in cpu endian.  Any other manually endian conversion is not required.
>> >
>> >The SPI bus itself has no real concept of endian as such. It just sends bits in the order it is fed them.  The device may require a particular ordering of course if we assume it makes sense to break the transfers up into byte size chnunks.
>>
>>
>> Yes, the device expect that the 32 bit request will be sent from MSBit to LSBit. Which means the ID shall be sent firstly, followed by ADR, W, CAP, *, WDATA, CRC.  If we consider the 32 bit as 4 bytes , then the MSB need to sent firstly, and followed by the LSBs. From this perspective we can say that the SMI240 SPI protocol requires big endian. On the host side the request is a local u32 (4 bytes). To make sure that the MSB will be sent firstly we need to convert the request to big endian before sending it over spi.
>
>Understood.  Try a 32 bit word size for the spi transfers. I think that should make everything work without any need to make it big endian.
>
We tried to use 32 bit word size for the spi transfers. Nevertheless not all the spi libraries supports 32 bit word. A number of spi library just support 8bit. Therefore we will firstly provide a 8bit spi transfer in next version. 

Best Regards
Jianping Shen