[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=Mewx0NAdFBX6hpes_oa62M_Jp=LtzAPK73tZv+tKxnScA@mail.gmail.com>
Date: Mon, 1 Jul 2024 10:46:34 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Andrei.Simion@...rochip.com
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
Nicolas.Ferre@...rochip.com, alexandre.belloni@...tlin.com,
claudiu.beznea@...on.dev, arnd@...db.de, gregkh@...uxfoundation.org,
linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
claudiu.beznea@...rochip.com
Subject: Re: [PATCH v3 1/3] eeprom: at24: avoid adjusting offset for
24AA025E{48, 64}
On Mon, Jul 1, 2024 at 9:23 AM <Andrei.Simion@...rochip.com> wrote:
>
> >>
> >> 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.
>
No, wait. Why can't you just do:
AT24_CHIP_DATA(at24_data_24aa025e48, 48 / 8, AT24_FLAG_READONLY);
and avoid this whole new macro variant entirely?
Bart
Powered by blists - more mailing lists