From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH 2/7] eeprom: at24: consider that SERIAL and MAC flags imply read-only
Date: Sun, 3 Dec 2017 22:20:39 +0100 [thread overview]
Message-ID: <CAMRc=MftoNhSik9iM6__VXQBzPSmCbcK2VKiS58bK5D6CSqQNA@mail.gmail.com> (raw)
In-Reply-To: <e598ac1a-443c-4ec4-e92c-b526ac4e6370@gmail.com>
2017-12-02 23:00 GMT+01:00 Heiner Kallweit <hkallweit1@gmail.com>:
> Am 01.12.2017 um 11:10 schrieb Bartosz Golaszewski:
>> 2017-11-30 7:49 GMT+01:00 Heiner Kallweit <hkallweit1@gmail.com>:
>>> Flags AT24_FLAG_SERIAL and AT24_FLAG_MAC imply read-only.
>>> Therefore handle this in the code instead of specifying
>>> AT24_FLAG_READONLY in the config data in these cases.
>>>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>> ---
>>> drivers/misc/eeprom/at24.c | 31 +++++++++++++------------------
>>> 1 file changed, 13 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
>>> index c75bb9b45..90fefd1cf 100644
>>> --- a/drivers/misc/eeprom/at24.c
>>> +++ b/drivers/misc/eeprom/at24.c
>>> @@ -131,38 +131,29 @@ static const struct i2c_device_id at24_ids[] = {
>>> { "24c00", AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR) },
>>> /* old variants can't be handled with this generic entry! */
>>> { "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
>>> - { "24cs01", AT24_DEVICE_MAGIC(16,
>>> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
>>> + { "24cs01", AT24_DEVICE_MAGIC(16, AT24_FLAG_SERIAL) },
>>> { "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) },
>>> - { "24cs02", AT24_DEVICE_MAGIC(16,
>>> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
>>> - { "24mac402", AT24_DEVICE_MAGIC(48 / 8,
>>> - AT24_FLAG_MAC | AT24_FLAG_READONLY) },
>>> - { "24mac602", AT24_DEVICE_MAGIC(64 / 8,
>>> - AT24_FLAG_MAC | AT24_FLAG_READONLY) },
>>> + { "24cs02", AT24_DEVICE_MAGIC(16, AT24_FLAG_SERIAL) },
>>> + { "24mac402", AT24_DEVICE_MAGIC(48 / 8, AT24_FLAG_MAC) },
>>> + { "24mac602", AT24_DEVICE_MAGIC(64 / 8, AT24_FLAG_MAC) },
>>> /* spd is a 24c02 in memory DIMMs */
>>> { "spd", AT24_DEVICE_MAGIC(2048 / 8,
>>> AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
>>> { "24c04", AT24_DEVICE_MAGIC(4096 / 8, 0) },
>>> - { "24cs04", AT24_DEVICE_MAGIC(16,
>>> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
>>> + { "24cs04", AT24_DEVICE_MAGIC(16, AT24_FLAG_SERIAL) },
>>> /* 24rf08 quirk is handled at i2c-core */
>>> { "24c08", AT24_DEVICE_MAGIC(8192 / 8, 0) },
>>> - { "24cs08", AT24_DEVICE_MAGIC(16,
>>> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
>>> + { "24cs08", AT24_DEVICE_MAGIC(16, AT24_FLAG_SERIAL) },
>>> { "24c16", AT24_DEVICE_MAGIC(16384 / 8, 0) },
>>> - { "24cs16", AT24_DEVICE_MAGIC(16,
>>> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
>>> + { "24cs16", AT24_DEVICE_MAGIC(16, AT24_FLAG_SERIAL) },
>>> { "24c32", AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16) },
>>> { "24cs32", AT24_DEVICE_MAGIC(16,
>>> AT24_FLAG_ADDR16 |
>>> - AT24_FLAG_SERIAL |
>>> - AT24_FLAG_READONLY) },
>>> + AT24_FLAG_SERIAL) },
>>> { "24c64", AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16) },
>>> { "24cs64", AT24_DEVICE_MAGIC(16,
>>> AT24_FLAG_ADDR16 |
>>> - AT24_FLAG_SERIAL |
>>> - AT24_FLAG_READONLY) },
>>> + AT24_FLAG_SERIAL) },
>>> { "24c128", AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16) },
>>> { "24c256", AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16) },
>>> { "24c512", AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16) },
>>> @@ -556,6 +547,10 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
>>> chip.context = NULL;
>>> }
>>>
>>> + /* both flags imply read-only */
>>> + if (chip.flags & AT24_FLAG_SERIAL || chip.flags & AT24_FLAG_MAC)
>>> + chip.flags |= AT24_FLAG_READONLY;
>>> +
>>> if (!is_power_of_2(chip.byte_len))
>>> dev_warn(&client->dev,
>>> "byte_len looks suspicious (no power of 2)!\n");
>>> --
>>> 2.15.0
>>>
>>>
>>
>> Just as with the header patch: this doesn't save us any code other
>> than visual. We want the definition to scream that this chip is
>> read-only. Nacked.
>>
> I see your point. My concern is that so far we may have platform-data-
> configured devices setting flag SERIAL or MAC and not READONLY and we
> have no control over such (IMO) misconfigurations.
>
> So my primary question would be whether we agree on SERIAL and MAC
> implying READONLY. If yes then I think we should reflect this
> relationship in the code.
> Instead of silently setting flag READONLY we could also reject such
> invalid flag configurations. Or print at least a message/warning
> when setting READONLY.
>
> Rgds, Heiner
>
>> Thanks,
>> Bartosz
>>
>
OK, this makes more sense, let's check if READONLY is set for MAC and
CS and if not: let's set it ourselves while also printing a warning.
Thanks,
Bartosz
next prev parent reply other threads:[~2017-12-03 21:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 6:40 [PATCH 0/7] eeprom: at24: series with smaller improvements Heiner Kallweit
2017-11-30 6:48 ` [PATCH 1/7] eeprom: at24: don't explicitely include header files which are implicitely included Heiner Kallweit
2017-11-30 15:56 ` Peter Rosin
2017-11-30 19:32 ` Heiner Kallweit
2017-12-01 10:09 ` Bartosz Golaszewski
2017-11-30 6:49 ` [PATCH 2/7] eeprom: at24: consider that SERIAL and MAC flags imply read-only Heiner Kallweit
2017-12-01 10:10 ` Bartosz Golaszewski
2017-12-02 22:00 ` Heiner Kallweit
2017-12-03 21:20 ` Bartosz Golaszewski [this message]
2017-11-30 6:49 ` [PATCH 3/7] eeprom: at24: simplify probe a little by replacing &client->dev Heiner Kallweit
2017-12-01 10:14 ` Bartosz Golaszewski
2017-11-30 6:49 ` [PATCH 4/7] eeprom: at24: simplify functions at24_read/write a little Heiner Kallweit
2017-12-01 10:14 ` Bartosz Golaszewski
2017-11-30 6:49 ` [PATCH 5/7] eeprom: at24: zero-initialize variable chip in probe Heiner Kallweit
2017-11-30 6:49 ` [PATCH 6/7] eeprom: at24: don't check chip.byte_len for power of two Heiner Kallweit
2017-11-30 6:49 ` [PATCH 7/7] eeprom: at24: don't check page_size for read-only chips and reorder checks Heiner Kallweit
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='CAMRc=MftoNhSik9iM6__VXQBzPSmCbcK2VKiS58bK5D6CSqQNA@mail.gmail.com' \
--to=brgl@bgdev.pl \
--cc=hkallweit1@gmail.com \
--cc=linux-i2c@vger.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).