All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Elfring <Markus.Elfring@web.de>
To: Daniel Okazaki <dtokazaki@google.com>,
	kernel-team@android.com, linux-i2c@vger.kernel.org,
	kernel-janitors@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] eeprom: at24: fix memory corruption race condition
Date: Tue, 23 Apr 2024 08:15:33 +0200	[thread overview]
Message-ID: <ac9cae80-cd9d-4ae0-9f27-b4b424304cbb@web.de> (raw)
In-Reply-To: <20240422174337.2487142-1-dtokazaki@google.com>

How do you think about to increase the version number for your attempt in the patch subject?

See also previous contribution:
https://lore.kernel.org/lkml/20240419191200.219548-1-dtokazaki@google.com/
https://lkml.org/lkml/2024/4/19/946


> If the eeprom is not accessible, an nvmem device will be registered, the
> read will fail, and the device will be torn down.
…

Please present the introduction for failure conditions as an enumeration.


> Move the failure point before registering the nvmem device.
…

I would interpret the diff data more in the way that a devm_nvmem_register() call
should be performed a bit later in the implementation of the function “at24_probe”.
How do you think about to mention the affected function also in the summary phrase?


> Changed sha length to 12 in description

A specification was adjusted for a tag.
Please add a version identifier here.
Will version descriptions be extended another bit?


> ---

I suggest to use blank line instead of a duplicate marker line.

Regards,
Markus

  parent reply	other threads:[~2024-04-23  6:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-22 17:43 [PATCH v3] eeprom: at24: fix memory corruption race condition Daniel Okazaki
2024-04-22 22:09 ` Greg Kroah-Hartman
2024-04-23  8:14   ` Bartosz Golaszewski
2024-04-23  6:15 ` Markus Elfring [this message]
2024-04-23  8:13 ` Bartosz Golaszewski
2024-04-23  8:15 ` Bartosz Golaszewski
  -- strict thread matches above, loose matches on Subject: below --
2024-04-19 19:04 [PATCH v2] " Markus Elfring
2024-04-19 19:12 ` [PATCH v3] " Daniel Okazaki
2024-04-20  6:15   ` Greg Kroah-Hartman
2024-04-20  9:11   ` Markus Elfring
2024-04-20 10:04     ` Greg Kroah-Hartman

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=ac9cae80-cd9d-4ae0-9f27-b4b424304cbb@web.de \
    --to=markus.elfring@web.de \
    --cc=arnd@arndb.de \
    --cc=brgl@bgdev.pl \
    --cc=dtokazaki@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.