> >> 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
Attachment:
signature.asc
Description: Digital signature
