linux-kernel - Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read

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: <20160105185853.GB1743@katana>
Date:	Tue, 5 Jan 2016 19:58:53 +0100
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:	linux-i2c <linux-i2c@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number
 read

On Mon, Jan 04, 2016 at 03:01:54PM +0100, Bartosz Golaszewski wrote:
> 2016-01-02 21:50 GMT+01:00 Wolfram Sang <wsa@...-dreams.de>:
> > On Fri, Dec 11, 2015 at 02:55:10PM +0100, Bartosz Golaszewski wrote:
> >> 2015-12-11 13:08 GMT+01:00 Wolfram Sang <wsa@...-dreams.de>:
> >> > On Wed, Dec 02, 2015 at 11:25:17AM +0100, Bartosz Golaszewski wrote:
> >> >> Chips from the at24cs EEPROM series have an additional read-only memory area
> >> >> containing a factory pre-programmed serial number. In order to access it, a
> >> >> dummy write must be executed before reading the serial number bytes.
> >> >
> >> > Can't you instantiate a read-only EEPROM on this second address? Or a
> >> > seperate driver attaching to this address? What is the advantage of
> >> > having this in at24?
> >> >
> >>
> >> The regular memory area and serial number read-only block share the
> >> internal address pointer. We must ensure that there's no race
> >> conditions between normal EEPROM reads/writes and serial number reads.
> >
> > I don't get it. Both, regular at24 reads and the serial read, setup the
> > pointer every time by using two messages, first write to set the
> > pointer, then read. The per-adapter lock makes sure those two messages
> > will not get interrupted.
> 
> If that's correct, then is there any need to have an additional mutex
> for at24_data?

I can't see a need, yes.

> In that case would the preferred method be to access the regular
> memory area like before - by allocating, for example, a 24c02 device -
> while allocating a second device - in that case 24cs02 - on the
> corresponding serial number address would give the user access to the
> serial number via the eeprom sysfs attribute (which for the latter
> would be read-only and 16 bytes in size)?

Yes, a seperate driver for the second address is what I meant to suggest
in the above paragraph. Only that the data should probably be exported
via the NVMEM framework, not directly via sysfs. We have patches pending
doing that for at24.

What happens if you assign another at24 instance (read-only) to the
second address? I mean, there is not only the serial number, but also a
MAC address IIRC.

Regards,

   Wolfram


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