linux-kernel - Re: [PATCH v11 5/8] i2c: fsi: Add transfer implementation

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]

Date:   Tue, 10 Jul 2018 14:14:40 -0500
From:   Eddie James <eajames@...ux.vnet.ibm.com>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, robh+dt@...nel.org,
        benh@...nel.crashing.org, joel@....id.au, mark.rutland@....com,
        gregkh@...uxfoundation.org, rdunlap@...radead.org,
        andy.shevchenko@...il.com, peda@...ntia.se
Subject: Re: [PATCH v11 5/8] i2c: fsi: Add transfer implementation



On 07/10/2018 01:50 PM, Wolfram Sang wrote:
>>>> +	cmd |= FIELD_PREP(I2C_CMD_ADDR, msg->addr >> 1);
>>> I just noticed this and wonder: Don't you need the LSB of the address?
>>> It is not the RW flag, this is encoded in msg->flags.
>> So, the hardware interprets the LSB as the RW flag. It wouldn't be possible
>> to have a device addressed with the LSB set on this I2C master.
> But msg->addr is 7 bit and LSB aligned. If I am not horribly wrong, with
> the above code, an EEPROM at 0x50 would show up as 0x28 with your
> driver?

Sorry, what do you mean "show up as"? Yes, we could first shift all our 
addresses in user-space before passing them to the driver, so that the 
msg->addr field is exactly what the hardware expects already... This 
would be non-trivial for our users considering all our documentation 
represents the addresses as the top 7 bits of a byte :(

>
>> Indeed, real 10-bit addresses require some additional manipulation of this
>> I2C master in order to work. We don't support it right now.
> Then you should remove the associated FUNC flag.

Ah, but due to the addressing situation, tools like i2cget don't work 
with our addresses unless the 10 bit flag is specified. For example, we 
may want to access 0xA0.

>