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]
Date:	Tue, 27 Jan 2015 20:06:13 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Jean Delvare <jdelvare@...e.de>
CC:	Robert Rosengren <robert.rosengren@...s.com>,
	lm-sensors@...sensors.org, Johan Adolfsson <johana@...s.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [lm-sensors] [PATCH] hwmon: (ads7828) Make sample interval configurable

On 01/27/2015 02:34 PM, Jean Delvare wrote:
> On Tue, 27 Jan 2015 12:05:53 -0800, Guenter Roeck wrote:
>> On Tue, Jan 27, 2015 at 08:54:34PM +0100, Robert Rosengren wrote:
>>> Guenter and Jean,
>>>
>>> To sum up, my problems was related my kernel and hardware configuration, and it now works. Many thanks for your input!
>>>
>>> However, the values retrieved from hwmon sysfs is not the same as before the regmap patch. Guenter, the byte swap for the regval retrieved by regmap_read. In what order is the bits returned from that function, because it seems as if I disabled that code I get values as I expect (i.e. before the regmap patch).
>>>
>> Trying to understand. Are you saying everything works as expected
>> if you keep byte_swap set to false ?
>>
>> That might well be, though it might mean that regmap has a bug
>> in how it treats i2c word read operations. I'll have to look into it
>> some more.
>
> Remember that SMBus specifies that the LSB comes first (and i2c-core
> implement things that way) while real I2C devices typically send the MSB
> first. This has always caused confusion. This is why a lot of drivers
> need byte-swapping.
>

regmap specifies "normal" i2c accesses as MSB first. When SMBus accesses
are used, it specifies LSB first. I guess that means that regmap assumes
the more common case of MSB first, meaning the driver would not need a byte
swap since the chip reports data with MSB first.

I just hope I interpret it correctly this time.

There is also a configuration flag "val_format_endian" which can be set to
REGMAP_ENDIAN_BIG or REGMAP_ENDIAN_LITTLE. Maybe that can be used as well
if needed. Either case I'll wait for the samples before I send an updated
version of the patch.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ