linux-kernel - Re: [PATCH RFC 1/2] Documentation: devicetree: Add property for ignoring the dummy bits sent before read transfer

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <70d6c152-5d8d-9ad6-ce06-95a9f599c492@ti.com>
Date:   Fri, 11 Dec 2020 20:34:57 +0530
From:   Aswath Govindraju <a-govindraju@...com>
To:     Rob Herring <robh@...nel.org>
CC:     <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Vadym Kochan <vadym.kochan@...ision.eu>,
        Vignesh Raghavendra <vigneshr@...com>,
        Sekhar Nori <nsekhar@...com>
Subject: Re: [PATCH RFC 1/2] Documentation: devicetree: Add property for
 ignoring the dummy bits sent before read transfer

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 ??

If this is required by all the devices then we can drop the property and
include the zero bit by default.

[1]- https://www.mouser.com/datasheet/2/268/20001749K-277859.pdf

Thanks,
Aswath
>>
>> Suggested-by: Vignesh Raghavendra <vigneshr@...com>
>> Signed-off-by: Aswath Govindraju <a-govindraju@...com>
>> ---
>>  Documentation/devicetree/bindings/misc/eeprom-93xx46.txt | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
>> index a8ebb4621f79..09fb1cec54f0 100644
>> --- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
>> +++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
>> @@ -10,7 +10,9 @@ Optional properties:
>>  - read-only : parameter-less property which disables writes to the EEPROM
>>  - select-gpios : if present, specifies the GPIO that will be asserted prior to
>>    each access to the EEPROM (e.g. for SPI bus multiplexing)
>> -
>> +- read-op-dummy-cycles: If present specifies the number of dummy zero-bits to
>> +  be sent after the address during a read transfer to ignore any bits sent
>> +  preceding the data.
>>  Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
>>  apply.  In particular, "reg" and "spi-max-frequency" properties must be given.
>>  
>> -- 
>> 2.17.1
>>