Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read
2016-01-05 19:58 GMT+01:00 Wolfram Sang : > On Mon, Jan 04, 2016 at 03:01:54PM +0100, Bartosz Golaszewski wrote: >> 2016-01-02 21:50 GMT+01:00 Wolfram Sang : >> > On Fri, Dec 11, 2015 at 02:55:10PM +0100, Bartosz Golaszewski wrote: >> >> 2015-12-11 13:08 GMT+01:00 Wolfram Sang : >> >> > 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-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 : > > On Fri, Dec 11, 2015 at 02:55:10PM +0100, Bartosz Golaszewski wrote: > >> 2015-12-11 13:08 GMT+01:00 Wolfram Sang : > >> > 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 signature.asc Description: Digital signature
Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read
2016-01-02 21:50 GMT+01:00 Wolfram Sang : > On Fri, Dec 11, 2015 at 02:55:10PM +0100, Bartosz Golaszewski wrote: >> 2015-12-11 13:08 GMT+01:00 Wolfram Sang : >> > 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-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read
On Fri, Dec 11, 2015 at 02:55:10PM +0100, Bartosz Golaszewski wrote: > 2015-12-11 13:08 GMT+01:00 Wolfram Sang : > > 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? signature.asc Description: Digital signature
Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read
2015-12-11 14:55 GMT+01:00 Bartosz Golaszewski : > 2015-12-11 13:08 GMT+01:00 Wolfram Sang : >> 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. > > Best regards, > Bartosz Golaszewski Hi Wolfram, any chance of getting it in for 4.5? Best regards, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read
2015-12-11 13:08 GMT+01:00 Wolfram Sang : > 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. Best regards, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read
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? signature.asc Description: Digital signature