Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1251459 > unrolled thread
| Started by | Bartosz Golaszewski <bgolaszewski@baylibre.com> |
|---|---|
| First post | 2015-10-20 10:50 +0200 |
| Last post | 2015-10-21 17:10 +0200 |
| Articles | 7 — 2 participants |
Back to article view | Back to linux.kernel
[RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2015-10-20 10:50 +0200
[RESEND PATCH 1/9] eeprom: at24: platform_data: use BIT() macro Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2015-10-20 11:00 +0200
Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read Peter Korsgaard <peter@korsgaard.com> - 2015-10-21 13:10 +0200
Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2015-10-21 16:20 +0200
Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read Peter Korsgaard <peter@korsgaard.com> - 2015-10-21 16:30 +0200
Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2015-10-21 16:50 +0200
Re: [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read Peter Korsgaard <peter@korsgaard.com> - 2015-10-21 17:10 +0200
| From | Bartosz Golaszewski <bgolaszewski@baylibre.com> |
|---|---|
| Date | 2015-10-20 10:50 +0200 |
| Subject | [RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read |
| Message-ID | <qlAMh-6Wk-7@gated-at.bofh.it> |
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. This series adds support for reading the serial number through a sysfs attribute. While we're at it: some of the patches contain readability tweaks and code organization fixes. Tested with at24cs64 and at24cs02 chips (for both 16 and 8 bit address pointers). Bartosz Golaszewski (9): eeprom: at24: platform_data: use BIT() macro eeprom: at24: new flag in platform_data eeprom: at24: tie up an additional address for at24cs series eeprom: at24: support reading of the serial number eeprom: at24: export the serial number through sysfs eeprom: at24: improve the device_id table readability eeprom: at24: add the at24cs series to the list of supported devices eeprom: at24: remove a reduntant if eeprom: at24: readability tweaks drivers/misc/eeprom/at24.c | 181 +++++++++++++++++++++++++++++++------ include/linux/platform_data/at24.h | 9 +- 2 files changed, 160 insertions(+), 30 deletions(-) -- 2.1.4 -- 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] | [next] | [standalone]
| From | Bartosz Golaszewski <bgolaszewski@baylibre.com> |
|---|---|
| Date | 2015-10-20 11:00 +0200 |
| Subject | [RESEND PATCH 1/9] eeprom: at24: platform_data: use BIT() macro |
| Message-ID | <qlAVY-77N-15@gated-at.bofh.it> |
| In reply to | #1251459 |
Use BIT() macro to replace the 0xXX constants in platform_data flags
definitions.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
include/linux/platform_data/at24.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
index c42aa89..8d90f52 100644
--- a/include/linux/platform_data/at24.h
+++ b/include/linux/platform_data/at24.h
@@ -43,10 +43,10 @@ struct at24_platform_data {
u32 byte_len; /* size (sum of all addr) */
u16 page_size; /* for writes */
u8 flags;
-#define AT24_FLAG_ADDR16 0x80 /* address pointer is 16 bit */
-#define AT24_FLAG_READONLY 0x40 /* sysfs-entry will be read-only */
-#define AT24_FLAG_IRUGO 0x20 /* sysfs-entry will be world-readable */
-#define AT24_FLAG_TAKE8ADDR 0x10 /* take always 8 addresses (24c00) */
+#define AT24_FLAG_ADDR16 BIT(7) /* address pointer is 16 bit */
+#define AT24_FLAG_READONLY BIT(6) /* sysfs-entry will be read-only */
+#define AT24_FLAG_IRUGO BIT(5) /* sysfs-entry will be world-readable */
+#define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */
void (*setup)(struct memory_accessor *, void *context);
void *context;
--
2.1.4
--
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]
| From | Peter Korsgaard <peter@korsgaard.com> |
|---|---|
| Date | 2015-10-21 13:10 +0200 |
| Message-ID | <qlZrj-17w-11@gated-at.bofh.it> |
| In reply to | #1251459 |
>>>>> "Bartosz" == Bartosz Golaszewski <bgolaszewski@baylibre.com> writes: > 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. > This series adds support for reading the serial number through a sysfs > attribute. > While we're at it: some of the patches contain readability tweaks and code > organization fixes. > Tested with at24cs64 and at24cs02 chips (for both 16 and 8 bit address > pointers). As the serial number is available on a separate i2c address, wouldn't it be simpler to handle these as special (read only) device variants and instantiate E.G. a 24c64 (for the normal data) and a 24cs64 (for the serial)? -- Bye, Peter Korsgaard -- 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]
| From | Bartosz Golaszewski <bgolaszewski@baylibre.com> |
|---|---|
| Date | 2015-10-21 16:20 +0200 |
| Message-ID | <qm2pc-5pS-7@gated-at.bofh.it> |
| In reply to | #1252720 |
2015-10-21 13:03 GMT+02:00 Peter Korsgaard <peter@korsgaard.com>: >>>>>> "Bartosz" == Bartosz Golaszewski <bgolaszewski@baylibre.com> writes: > > > 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. > > > This series adds support for reading the serial number through a sysfs > > attribute. > > > While we're at it: some of the patches contain readability tweaks and code > > organization fixes. > > > Tested with at24cs64 and at24cs02 chips (for both 16 and 8 bit address > > pointers). > > As the serial number is available on a separate i2c address, wouldn't > it be simpler to handle these as special (read only) device variants and > instantiate E.G. a 24c64 (for the normal data) and a 24cs64 (for the > serial)? > Hi Peter, I wanted to respond that this way we would not be protected from concurrent accesses, but then I saw I didn't actually include any locks in the serial read function - my bad. It needs to be fixed as both memory blocks share the same address pointer. I'll resend the series. 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]
| From | Peter Korsgaard <peter@korsgaard.com> |
|---|---|
| Date | 2015-10-21 16:30 +0200 |
| Message-ID | <qm2yS-5Ck-1@gated-at.bofh.it> |
| In reply to | #1252851 |
>>>>> "Bartosz" == Bartosz Golaszewski <bgolaszewski@baylibre.com> writes: >> As the serial number is available on a separate i2c address, wouldn't >> it be simpler to handle these as special (read only) device variants and >> instantiate E.G. a 24c64 (for the normal data) and a 24cs64 (for the >> serial)? >> > Hi Peter, > I wanted to respond that this way we would not be protected from > concurrent accesses, but then I saw I didn't actually include any > locks in the serial read function - my bad. It needs to be fixed as > both memory blocks share the same address pointer. > I'll resend the series. But we're protected by the i2c bus lock, right? You do a single i2c_transfer to read the serial number. -- Venlig hilsen, Peter Korsgaard -- 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]
| From | Bartosz Golaszewski <bgolaszewski@baylibre.com> |
|---|---|
| Date | 2015-10-21 16:50 +0200 |
| Message-ID | <qm2Sd-606-11@gated-at.bofh.it> |
| In reply to | #1252853 |
2015-10-21 16:23 GMT+02:00 Peter Korsgaard <peter@korsgaard.com>: >>>>>> "Bartosz" == Bartosz Golaszewski <bgolaszewski@baylibre.com> writes: > > >> As the serial number is available on a separate i2c address, wouldn't > >> it be simpler to handle these as special (read only) device variants and > >> instantiate E.G. a 24c64 (for the normal data) and a 24cs64 (for the > >> serial)? > >> > > > Hi Peter, > > > I wanted to respond that this way we would not be protected from > > concurrent accesses, but then I saw I didn't actually include any > > locks in the serial read function - my bad. It needs to be fixed as > > both memory blocks share the same address pointer. > > > I'll resend the series. > > But we're protected by the i2c bus lock, right? You do a single > i2c_transfer to read the serial number. Why the at24->lock then? 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]
| From | Peter Korsgaard <peter@korsgaard.com> |
|---|---|
| Date | 2015-10-21 17:10 +0200 |
| Message-ID | <qm3bz-6Fw-3@gated-at.bofh.it> |
| In reply to | #1252886 |
>>>>> "Bartosz" == Bartosz Golaszewski <bgolaszewski@baylibre.com> writes: Hi, >> > I wanted to respond that this way we would not be protected from >> > concurrent accesses, but then I saw I didn't actually include any >> > locks in the serial read function - my bad. It needs to be fixed as >> > both memory blocks share the same address pointer. >> >> > I'll resend the series. >> >> But we're protected by the i2c bus lock, right? You do a single >> i2c_transfer to read the serial number. > Why the at24->lock then? I'm not sure. Wolfram? -- Bye, Peter Korsgaard -- 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] | [standalone]
Back to top | Article view | linux.kernel
csiph-web