linux-kernel - Re: [PATCH] i2c: axxia: Add I2C driver for AXM55xx

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:	Mon, 22 Sep 2014 14:18:24 +0200
From:	Anders Berg <anders.berg@...gotech.com>
To:	Wolfram Sang <wsa@...-dreams.de>
Cc:	devicetree <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-i2c@...r.kernel.org
Subject: Re: [PATCH] i2c: axxia: Add I2C driver for AXM55xx

On Mon, Sep 22, 2014 at 1:04 PM, Wolfram Sang <wsa@...-dreams.de> wrote:
>
>> >> >> +     if (msg->len == 0 || msg->len > 255)
>> >> >> +             return -EINVAL;
>> >> >
>> >> > Ouch, really? Maybe we should warn the user here.
>> >>
>> >> Yeah, the transfer length register limits the length to 255. I'll add
>> >> a warning here.
>> >
>> > Please also add this information to the Kconfig description and
>> > somewhere at the top of the source file. This is an important flaw which
>> > people should easily find out about.
>> >
>>
>> You are referring to the "len <= 255" restriction being the flaw here,
>> right? I'll add a note to Kconfig and the driver about that.
>
> Yes, I meant that. I just remembered we should do something else:
>
> Remove I2C_FUNC_I2C (because it cannot do endless transfers) from
> functionality and simply use I2C_FUNC_SMBUS_I2C_BLOCK which does I2C
> like transfers with the SMBus Limit of 32 bytes. It seems PMBus allows
> for 255 byte which this HW could support, yet I don't recall we have
> support for that size currently.
>

Just tried this out... With the above change (I2C_FUNC_I2C replaced
with I2C_FUNC_SMBUS_I2C_BLOCK) an EEPROM device fails (at24 driver)
since it can't do a 16-bit offset when using the SMBUS_I2C_BLOCK
transfer.

Would you be OK with keeping the I2C_FUNC_I2C capability and
documenting the restriction (as per your initial suggestion)?

/Anders
--
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/