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


Groups > linux.kernel > #1251459 > unrolled thread

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

Started byBartosz Golaszewski <bgolaszewski@baylibre.com>
First post2015-10-20 10:50 +0200
Last post2015-10-21 17:10 +0200
Articles 7 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [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

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

FromBartosz Golaszewski <bgolaszewski@baylibre.com>
Date2015-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]


#1251463 — [RESEND PATCH 1/9] eeprom: at24: platform_data: use BIT() macro

FromBartosz Golaszewski <bgolaszewski@baylibre.com>
Date2015-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]


#1252720

FromPeter Korsgaard <peter@korsgaard.com>
Date2015-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]


#1252851

FromBartosz Golaszewski <bgolaszewski@baylibre.com>
Date2015-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]


#1252853

FromPeter Korsgaard <peter@korsgaard.com>
Date2015-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]


#1252886

FromBartosz Golaszewski <bgolaszewski@baylibre.com>
Date2015-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]


#1252916

FromPeter Korsgaard <peter@korsgaard.com>
Date2015-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