Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300124 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number  read Wolfram Sang <wsa@the-dreams.de> - 2016-01-02 22:00 +0100
    Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2016-01-04 15:10 +0100
      Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number  read Wolfram Sang <wsa@the-dreams.de> - 2016-01-05 20:00 +0100
        Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2016-01-07 17:20 +0100
          Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number  read Wolfram Sang <wsa@the-dreams.de> - 2016-01-09 22:20 +0100
            Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2016-01-11 15:00 +0100

#1300124 — Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read

[Multipart message — attachments visible in raw view] — view raw

On Fri, Dec 11, 2015 at 02:55:10PM +0100, Bartosz Golaszewski wrote:
> 2015-12-11 13:08 GMT+01:00 Wolfram Sang <wsa@the-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. So, it looks to me that it would be OK if a
serial read access gets inbetween a eeprom read access. Am I wrong?

[toc] | [next] | [standalone]

#1300758 — Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read

2016-01-02 21:50 GMT+01:00 Wolfram Sang <wsa@the-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@the-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?

> So, it looks to me that it would be OK if a
> serial read access gets inbetween a eeprom read access. Am I wrong?
>

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

Best regards,
Bartosz Golaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301887

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 04, 2016 at 03:01:54PM +0100, Bartosz Golaszewski wrote:
> 2016-01-02 21:50 GMT+01:00 Wolfram Sang <wsa@the-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@the-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

[toc] | [prev] | [next] | [standalone]

#1303711 — Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read

2016-01-05 19:58 GMT+01:00 Wolfram Sang <wsa@the-dreams.de>:
> On Mon, Jan 04, 2016 at 03:01:54PM +0100, Bartosz Golaszewski wrote:
>> 2016-01-02 21:50 GMT+01:00 Wolfram Sang <wsa@the-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@the-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.

Then I'll see if it can be safely removed in the next iteration.

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

Right, but then these patches keep the driver backwards compatible in
that they keep the 'eeprom' sysfs attribute, so it's still a viable
option.

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

Nothing - it can't be read with the regular driver. Its protocol
requires certain bits set just like in the function from patch 4/9 in
this series.

As for the MAC address - I can't find anything in the datasheet, and
haven't heard about it.

> Regards,
>
>    Wolfram
>

Best regards,
Bartosz Golaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1305357

[Multipart message — attachments visible in raw view] — view raw

> >> If that's correct, then is there any need to have an additional mutex
> >> for at24_data?
> >
> > I can't see a need, yes.
> 
> Then I'll see if it can be safely removed in the next iteration.

That would be great, thanks!

> > 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.
> 
> Right, but then these patches keep the driver backwards compatible in
> that they keep the 'eeprom' sysfs attribute, so it's still a viable
> option.

Yes, they do it for backwards compatibility. If you do something new,
you can't really claim that ;)

> > 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.
> 
> Nothing - it can't be read with the regular driver. Its protocol
> requires certain bits set just like in the function from patch 4/9 in
> this series.

Maybe it might work if you seek to the right offset and read the right
number of bytes, but this is clumsy, I agree.

> As for the MAC address - I can't find anything in the datasheet, and
> haven't heard about it.

http://www.atmel.com/images/atmel-8807-seeprom-at24mac402-602-datasheet.pdf

That was the first data sheet I found when looking for documentation.
So, we should keep in mind that there might be more than a serial number
in this extra memory space.

Thanks,

   Wolfram

[toc] | [prev] | [next] | [standalone]

#1306252 — Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read

2016-01-09 22:09 GMT+01:00 Wolfram Sang <wsa@the-dreams.de>:
>
>> >> If that's correct, then is there any need to have an additional mutex
>> >> for at24_data?
>> >
>> > I can't see a need, yes.
>>
>> Then I'll see if it can be safely removed in the next iteration.
>
> That would be great, thanks!
>
>> > 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.
>>
>> Right, but then these patches keep the driver backwards compatible in
>> that they keep the 'eeprom' sysfs attribute, so it's still a viable
>> option.
>
> Yes, they do it for backwards compatibility. If you do something new,
> you can't really claim that ;)
>
>> > 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.
>>
>> Nothing - it can't be read with the regular driver. Its protocol
>> requires certain bits set just like in the function from patch 4/9 in
>> this series.
>
> Maybe it might work if you seek to the right offset and read the right
> number of bytes, but this is clumsy, I agree.

You not only need to reset the address pointer to the right value, but
also prefix the word address with the right sequence just like in the
following snippet:

200         if (at24->chip.flags & AT24_FLAG_ADDR16) {
201                 /*
202                  * For 16 bit address pointers, the word address
must contain
203                  * a '10' sequence in bits 11 and 10 regardless of the
204                  * intended position of the address pointer.
205                  */
206                 addrbuf[0] = 0x08;
207                 addrbuf[1] = offset;
208                 msg[0].len = 2;
209         } else {
210                 /*
211                  * Otherwise the word address must begin with a
'10' sequence,
212                  * regardless of the intended address.
213                  */
214                 addrbuf[0] = 0x80 + offset;
215                 msg[0].len = 1;
216         }

>> As for the MAC address - I can't find anything in the datasheet, and
>> haven't heard about it.
>
> http://www.atmel.com/images/atmel-8807-seeprom-at24mac402-602-datasheet.pdf
>
> That was the first data sheet I found when looking for documentation.
> So, we should keep in mind that there might be more than a serial number
> in this extra memory space.

Right. I'll keep that in mind, but unfortunately I have no means of testing it.

Best regards,
Bartosz Golaszewski

> Thanks,
>
>    Wolfram
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web