devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Andrei.Simion@microchip.com>
To: <brgl@bgdev.pl>
Cc: <robh@kernel.org>, <krzk+dt@kernel.org>, <conor+dt@kernel.org>,
	<Nicolas.Ferre@microchip.com>, <alexandre.belloni@bootlin.com>,
	<claudiu.beznea@tuxon.dev>, <arnd@arndb.de>,
	<gregkh@linuxfoundation.org>, <linux-i2c@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<claudiu.beznea@microchip.com>
Subject: Re: [PATCH v3 1/3] eeprom: at24: avoid adjusting offset for 24AA025E{48, 64}
Date: Mon, 1 Jul 2024 07:23:01 +0000	[thread overview]
Message-ID: <c1b53308-d1d5-412b-9558-9f40dd237397@microchip.com> (raw)
In-Reply-To: <CAMRc=MeJM4LmczCbZ8bKytLZKY_mP=Q8eaUprLMmO8BYHecStw@mail.gmail.com>

On 28.06.2024 17:46, Bartosz Golaszewski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, Jun 28, 2024 at 4:17 PM <Andrei.Simion@microchip.com> wrote:
>>
>> On 28.06.2024 11:30, Bartosz Golaszewski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On Fri, Jun 28, 2024 at 10:02 AM Andrei Simion
>>> <andrei.simion@microchip.com> wrote:
>>>>
>>>> From: Claudiu Beznea <claudiu.beznea@microchip.com>
>>>>
>>>> The EEPROMs could be used only for MAC storage. In this case the
>>>> EEPROM areas where MACs resides could be modeled as NVMEM cells
>>>> (directly via DT bindings) such that the already available networking
>>>> infrastructure to read properly the MAC addresses (via
>>>> of_get_mac_address()). The previously available compatibles needs the
>>>> offset adjustment probably for compatibility w/ old DT bindings.
>>>> Add "microchip,24aa025e48", "microchip,24aa025e64" compatible for the
>>>> usage w/ 24AA025E{48, 64} type of EEPROMs where "24aa025e48" stands
>>>> for EUI-48 address and "24aa025e64" stands for EUI-64 address.
>>>>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
>>>> [andrei.simion@microchip.com: Add extended macros to initialize the structure
>>>> with explicit value to adjusting offset. Add extra description for the commit
>>>> message.]
>>>> Signed-off-by: Andrei Simion <andrei.simion@microchip.com>
>>>> ---
>>>> v2 -> v3:
>>>> - add specific compatible names according with
>>>> https://ww1.microchip.com/downloads/en/DeviceDoc/24AA02E48-24AA025E48-24AA02E64-24AA025E64-Data-Sheet-20002124H.pdf
>>>> - add extended macros to initialize the structure with explicit value for adjoff
>>>> - drop co-developed-by to maintain the commit history
>>>>  (chronological order of modifications)
>>>>
>>>> v1 -> v2:
>>>> - no change
>>>> ---
>>>>  drivers/misc/eeprom/at24.c | 28 +++++++++++++++++++++++-----
>>>>  1 file changed, 23 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
>>>> index 4bd4f32bcdab..e2ac08f656cf 100644
>>>> --- a/drivers/misc/eeprom/at24.c
>>>> +++ b/drivers/misc/eeprom/at24.c
>>>> @@ -121,20 +121,29 @@ struct at24_chip_data {
>>>>         u32 byte_len;
>>>>         u8 flags;
>>>>         u8 bank_addr_shift;
>>>> +       u8 adjoff;
>>>>         void (*read_post)(unsigned int off, char *buf, size_t count);
>>>>  };
>>>>
>>>> -#define AT24_CHIP_DATA(_name, _len, _flags)                            \
>>>> +#define AT24_CHIP_DATA_AO(_name, _len, _flags, _ao)                    \
>>>
>>> Please, don't try to save space on a few letters, call it
>>> AT24_CHIP_DATA_ADJOFF() for better readability.
>>>
>>
>> I will change in next the version.
>>
>>>>         static const struct at24_chip_data _name = {                    \
>>>>                 .byte_len = _len, .flags = _flags,                      \
>>>> +               .adjoff = _ao                                           \
>>>>         }
>>>>
>>>> -#define AT24_CHIP_DATA_CB(_name, _len, _flags, _read_post)             \
>>>> +#define AT24_CHIP_DATA(_name, _len, _flags)                            \
>>>> +       AT24_CHIP_DATA_AO(_name, _len, _flags, 0)
>>>> +
>>>> +#define AT24_CHIP_DATA_CB_AO(_name, _len, _flags, _ao, _read_post)     \
>>>>         static const struct at24_chip_data _name = {                    \
>>>>                 .byte_len = _len, .flags = _flags,                      \
>>>> +               .adjoff = _ao,                                          \
>>>>                 .read_post = _read_post,                                \
>>>>         }
>>>>
>>>> +#define AT24_CHIP_DATA_CB(_name, _len, _flags, _read_post)             \
>>>> +       AT24_CHIP_DATA_CB_AO(_name, _len, _flags, 0, _read_post)
>>>> +
>>>>  #define AT24_CHIP_DATA_BS(_name, _len, _flags, _bank_addr_shift)       \
>>>>         static const struct at24_chip_data _name = {                    \
>>>>                 .byte_len = _len, .flags = _flags,                      \
>>>> @@ -170,9 +179,13 @@ AT24_CHIP_DATA(at24_data_24cs01, 16,
>>>>  AT24_CHIP_DATA(at24_data_24c02, 2048 / 8, 0);
>>>>  AT24_CHIP_DATA(at24_data_24cs02, 16,
>>>>         AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
>>>> -AT24_CHIP_DATA(at24_data_24mac402, 48 / 8,
>>>> +AT24_CHIP_DATA_AO(at24_data_24mac402, 48 / 8,
>>>> +       AT24_FLAG_MAC | AT24_FLAG_READONLY, 1);
>>>
>>> And this will not break existing users? I guess you refer to these
>>> changes in your commit message but it's not very clear what you're
>>> doing and why.
>>>
>>
>> For those types of eeprom 24AA025E{48, 64} adjusting offset is not required (at24_get_offset_adj()).
>> So, indeed, it is an entanglement in logic.
>> To keep the implementation as it is:
>> adjoff (which is a flag that indicates when to use the adjusting offset) needs to be 1 for old compatibles but for these new ones needs to be 0.
>>
>> I think that is enough not to break the existing users. What are your thoughts?
>>
> 
> Wait... is the adjoff field effectively a boolean? Why u8?
> 

struct at24_data contains offset_adj which will get value calling at24_get_offset_adj()) if adjoff is true (1).
Yes, adjoff needs to be treated as a boolean. I will change it in the next version.

Best Regards,
Andrei

> Bart
> 
>> Best Regards,
>> Andrei Simion
>>
>>>> +AT24_CHIP_DATA_AO(at24_data_24mac602, 64 / 8,
>>>> +       AT24_FLAG_MAC | AT24_FLAG_READONLY, 1);
>>>> +AT24_CHIP_DATA(at24_data_24aa025e48, 48 / 8,
>>>>         AT24_FLAG_MAC | AT24_FLAG_READONLY);
>>>> -AT24_CHIP_DATA(at24_data_24mac602, 64 / 8,
>>>> +AT24_CHIP_DATA(at24_data_24aa025e64, 64 / 8,
>>>>         AT24_FLAG_MAC | AT24_FLAG_READONLY);
>>>>  /* spd is a 24c02 in memory DIMMs */
>>>>  AT24_CHIP_DATA(at24_data_spd, 2048 / 8,
>>>> @@ -218,6 +231,8 @@ static const struct i2c_device_id at24_ids[] = {
>>>>         { "24cs02",     (kernel_ulong_t)&at24_data_24cs02 },
>>>>         { "24mac402",   (kernel_ulong_t)&at24_data_24mac402 },
>>>>         { "24mac602",   (kernel_ulong_t)&at24_data_24mac602 },
>>>> +       { "24aa025e48", (kernel_ulong_t)&at24_data_24aa025e48 },
>>>> +       { "24aa025e64", (kernel_ulong_t)&at24_data_24aa025e64 },
>>>>         { "spd",        (kernel_ulong_t)&at24_data_spd },
>>>>         { "24c02-vaio", (kernel_ulong_t)&at24_data_24c02_vaio },
>>>>         { "24c04",      (kernel_ulong_t)&at24_data_24c04 },
>>>> @@ -270,6 +285,8 @@ static const struct of_device_id __maybe_unused at24_of_match[] = {
>>>>         { .compatible = "atmel,24c1024",        .data = &at24_data_24c1024 },
>>>>         { .compatible = "atmel,24c1025",        .data = &at24_data_24c1025 },
>>>>         { .compatible = "atmel,24c2048",        .data = &at24_data_24c2048 },
>>>> +       { .compatible = "microchip,24aa025e48", .data = &at24_data_24aa025e48 },
>>>> +       { .compatible = "microchip,24aa025e64", .data = &at24_data_24aa025e64 },
>>>>         { /* END OF LIST */ },
>>>>  };
>>>>  MODULE_DEVICE_TABLE(of, at24_of_match);
>>>> @@ -690,7 +707,8 @@ static int at24_probe(struct i2c_client *client)
>>>>         at24->read_post = cdata->read_post;
>>>>         at24->bank_addr_shift = cdata->bank_addr_shift;
>>>>         at24->num_addresses = num_addresses;
>>>> -       at24->offset_adj = at24_get_offset_adj(flags, byte_len);
>>>> +       at24->offset_adj = cdata->adjoff ?
>>>> +                               at24_get_offset_adj(flags, byte_len) : 0;
>>>>         at24->client_regmaps[0] = regmap;
>>>>
>>>>         at24->vcc_reg = devm_regulator_get(dev, "vcc");
>>>> --
>>>> 2.34.1
>>>>
>>>
>>> Bart



  reply	other threads:[~2024-07-01  7:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28  8:01 [PATCH v3 0/3] Read MAC address through NVMEM for sama7g5ek Andrei Simion
2024-06-28  8:01 ` [PATCH v3 1/3] eeprom: at24: avoid adjusting offset for 24AA025E{48, 64} Andrei Simion
2024-06-28  8:30   ` Bartosz Golaszewski
2024-06-28 14:17     ` Andrei.Simion
2024-06-28 14:46       ` Bartosz Golaszewski
2024-07-01  7:23         ` Andrei.Simion [this message]
2024-07-01  8:46           ` Bartosz Golaszewski
2024-07-01 10:20             ` Andrei.Simion
2024-07-01 11:16               ` Bartosz Golaszewski
2024-07-01 12:17                 ` Andrei.Simion
2024-06-28  8:01 ` [PATCH v3 2/3] ARM: dts: at91: at91-sama7g5ek: add EEPROMs Andrei Simion
2024-06-28  8:01 ` [PATCH v3 3/3] dt-bindings: eeprom: at24: Add Microchip 24AA025E48/24AA025E64 Andrei Simion
2024-06-28  9:09   ` Conor Dooley
2024-07-01 14:37     ` Andrei.Simion
2024-07-01 14:47       ` Conor Dooley
2024-07-01 14:56         ` Andrei.Simion
2024-06-28  8:29 ` [PATCH v3 0/3] Read MAC address through NVMEM for sama7g5ek Arnd Bergmann
2024-06-28 14:06   ` Andrei.Simion
2024-06-28 14:25     ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1b53308-d1d5-412b-9558-9f40dd237397@microchip.com \
    --to=andrei.simion@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=brgl@bgdev.pl \
    --cc=claudiu.beznea@microchip.com \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).