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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 15 Dec 2020 21:42:01 +0530
From:   Aswath Govindraju <>
To:     Rob Herring <>
CC:     <>, <>,
        Arnd Bergmann <>,
        Greg Kroah-Hartman <>,
        Vadym Kochan <>,
        Vignesh Raghavendra <>,
        Sekhar Nori <>
Subject: Re: [PATCH RFC 1/2] Documentation: devicetree: Add property for
 ignoring the dummy bits sent before read transfer

Hi Rob,
On 15/12/20 3:53 am, Rob Herring wrote:
> On Fri, Dec 11, 2020 at 08:34:57PM +0530, Aswath Govindraju wrote:
>> Hi,
>> On 11/12/20 9:03 am, Rob Herring wrote:
>>> On Wed, Dec 09, 2020 at 11:27:07PM +0530, Aswath Govindraju wrote:
>>>> Dummy zero bits are sent before data during a read transfer. This causes
>>>> the data read to be shifted to the right. To fix this send zero bits after
>>>> the address during a read transfer.
>>>> Add property to send zero bits after the address during a read transfer.
>>> When is this necessary? Why can't it be implied by the compatible 
>>> string which should be specific to the chip model?
>> This is necessary for 93AA46A/B/C, 93LC46A/B/C, 93C46A/B/C eeproms, as
>> it can be seen in section 2.7 of [1]. We were not sure if these were the
>> only devices supported by the driver(eeprom_93xx46.c). So, in order to
>> apply this only to the above listed devices, we thought that it would be
>> better to apply this change when required by introducing a DT property.
>> May I know how has this case been handled till now ??
> No idea. From the at93c46d (which has a compatible string) datasheet it 
> looks like it has the same thing.
>> If this is required by all the devices then we can drop the property and
>> include the zero bit by default.
> Looks like you need a combination of compatible strings for the above  
> devices and a property for the ORG pin state on the C devices. I assume 
> s/w needs to know if x8 or x16?
Yes, there are separate properties for indicating different types of
types of eeproms.

So, do you think that it is better to add it as a seperate property??

> Rob

Powered by blists - more mailing lists