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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160426073620.GA1543@katana>
Date:	Tue, 26 Apr 2016 09:36:20 +0200
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Jan Glauber <jan.glauber@...iumnetworks.com>
Cc:	linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
	David Daney <ddaney@...iumnetworks.com>
Subject: Re: [PATCH v7 03/15] i2c: octeon: Remove I2C_FUNC_SMBUS_QUICK support


> > Yes, I thought briefly about splitting SMBUS_QUICK into read-write
> > variants too. To me the question is if this feature is still used on modern
> > devices or if this is more a relict of the past. I don't know enough
> > about SMBUS to answer that.

Well, note that there are zero-length messages in I2C allowed as well.
Not only in SMBUS. I mainly use the term SMBUS_QUICK because it covers
both cases.


> Checking on ThunderX:
...
> Do all these other numbers make sense (although there are no
> devices)?

It makes sense in a way that it shows SMBUS_QUICK_WRITE is broken :) It
doesn't react to ACK/NACK properly. So, what needs to be done:

1) remove SMBUS_QUICK as you did in this patch 2) move the length check
so it doesn't only check read messages but also write messages. That is
to prevent handling custom setup I2C messages with a length of 0 (which
is legal). I'd suggest to return -EOPNOTSUPP in this case.

Thanks,

   Wolfram


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ