All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Tudor.Ambarus@microchip.com, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org, p.yadav@ti.com,
	miquel.raynal@bootlin.com, richard@nod.at
Subject: Re: [PATCH v5 3/5] mtd: spi-nor: otp: return -EROFS if region is read-only
Date: Mon, 07 Jun 2021 11:56:33 +0200	[thread overview]
Message-ID: <2559d150b3a0d964ece0c9e29e155ecc@walle.cc> (raw)
In-Reply-To: <3e46bc75-6ace-f7c0-1b14-aae812554ac9@ti.com>

Am 2021-06-07 08:47, schrieb Vignesh Raghavendra:
> On 6/7/21 11:38 AM, Michael Walle wrote:
>> Am 2021-06-07 07:46, schrieb Vignesh Raghavendra:
>>> On 6/4/21 6:45 PM, Michael Walle wrote:
>>>> Am 2021-06-04 15:07, schrieb Tudor.Ambarus@microchip.com:
>>>>> On 6/4/21 1:02 PM, Michael Walle wrote:
>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>>>>> know the content is safe
>>>>>> 
>>>>>> SPI NOR flashes will just ignore program commands if the OTP 
>>>>>> region is
>>>>>> locked. Thus, a user might not notice that the intended write
>>>>>> didn't end
>>>>>> up in the flash. Return -EROFS to the user in this case. From what
>>>>>> I can
>>>>>> tell, chips/cfi_cmdset_0001.c also return this error code.
>>>>>> 
>>>>>> One could optimize spi_nor_mtd_otp_range_is_locked() to read the
>>>>>> status
>>>>>> register only once and not for every OTP region, but for that we 
>>>>>> would
>>>>>> need some more invasive changes. Given that this is
>>>>>> one-time-programmable memory and the normal access mode is 
>>>>>> reading, we
>>>>>> just live with the small overhead.
>>>>>> 
>>>>>> Fixes: 069089acf88b ("mtd: spi-nor: add OTP support")
>>>>>> Signed-off-by: Michael Walle <michael@walle.cc>
>>>>>> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
>>>>>> ---
>>>>>>  drivers/mtd/spi-nor/otp.c | 36 
>>>>>> ++++++++++++++++++++++++++++++++++++
>>>>>>  1 file changed, 36 insertions(+)
>>>>>> 
>>>>>> diff --git a/drivers/mtd/spi-nor/otp.c b/drivers/mtd/spi-nor/otp.c
>>>>>> index 3898ed67ba1c..063f8fb68649 100644
>>>>>> --- a/drivers/mtd/spi-nor/otp.c
>>>>>> +++ b/drivers/mtd/spi-nor/otp.c
>>>>>> @@ -249,6 +249,32 @@ static int spi_nor_mtd_otp_info(struct 
>>>>>> mtd_info
>>>>>> *mtd, size_t len,
>>>>>>         return ret;
>>>>>>  }
>>>>>> 
>>>>>> +static int spi_nor_mtd_otp_range_is_locked(struct spi_nor *nor,
>>>>>> loff_t ofs,
>>>>>> +                                          size_t len)
>>>>>> +{
>>>>>> +       const struct spi_nor_otp_ops *ops = nor->params->otp.ops;
>>>>>> +       unsigned int region;
>>>>>> +       int locked;
>>>>>> +
>>>>>> +       if (!len)
>>>>>> +               return 0;
>>>>>> +
>>>>> 
>>>>> You won't need this if you put patch 4/5 before this one. With 
>>>>> this:
>>>> 
>>>> This patch will get backported to the stable kernels. Patch 4 on the
>>>> other hand does not.
>>>> 
>>> 
>>> I don't see why 4/5 cannot be marked for backport too as it makes 3/5
>>> much cleaner?
>> 
>> What kind of problem does 4/5 fix? I can't see how that patch would
>> apply to any rule in Documentation/process/stable-kernel-rules.rst.
>> 
> 
> Looking further, I don't see the need for 4/5 to be a separate patch.
> Patch 4/5 is simplifying spi_nor_mtd_otp_range_is_locked() by ensuring
> 'len' passed is never 0 which can be done in 3/5 when introducing
> spi_nor_mtd_otp_range_is_locked().
> 
> So why not squashed it into 3/5.

Because, strictly speaking, it is not part of that particular fix
and IMHO violates "It must fix only one thing". But if you're fine
with that, I can squash the two.

TBH I find it kinda funny to bend the rules, just to get rid of
these three lines of code or the ugliness that they will be removed
in the following patch.

-michael

WARNING: multiple messages have this Message-ID (diff)
From: Michael Walle <michael@walle.cc>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Tudor.Ambarus@microchip.com, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org, p.yadav@ti.com,
	miquel.raynal@bootlin.com, richard@nod.at
Subject: Re: [PATCH v5 3/5] mtd: spi-nor: otp: return -EROFS if region is read-only
Date: Mon, 07 Jun 2021 11:56:33 +0200	[thread overview]
Message-ID: <2559d150b3a0d964ece0c9e29e155ecc@walle.cc> (raw)
In-Reply-To: <3e46bc75-6ace-f7c0-1b14-aae812554ac9@ti.com>

Am 2021-06-07 08:47, schrieb Vignesh Raghavendra:
> On 6/7/21 11:38 AM, Michael Walle wrote:
>> Am 2021-06-07 07:46, schrieb Vignesh Raghavendra:
>>> On 6/4/21 6:45 PM, Michael Walle wrote:
>>>> Am 2021-06-04 15:07, schrieb Tudor.Ambarus@microchip.com:
>>>>> On 6/4/21 1:02 PM, Michael Walle wrote:
>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>>>>> know the content is safe
>>>>>> 
>>>>>> SPI NOR flashes will just ignore program commands if the OTP 
>>>>>> region is
>>>>>> locked. Thus, a user might not notice that the intended write
>>>>>> didn't end
>>>>>> up in the flash. Return -EROFS to the user in this case. From what
>>>>>> I can
>>>>>> tell, chips/cfi_cmdset_0001.c also return this error code.
>>>>>> 
>>>>>> One could optimize spi_nor_mtd_otp_range_is_locked() to read the
>>>>>> status
>>>>>> register only once and not for every OTP region, but for that we 
>>>>>> would
>>>>>> need some more invasive changes. Given that this is
>>>>>> one-time-programmable memory and the normal access mode is 
>>>>>> reading, we
>>>>>> just live with the small overhead.
>>>>>> 
>>>>>> Fixes: 069089acf88b ("mtd: spi-nor: add OTP support")
>>>>>> Signed-off-by: Michael Walle <michael@walle.cc>
>>>>>> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
>>>>>> ---
>>>>>>  drivers/mtd/spi-nor/otp.c | 36 
>>>>>> ++++++++++++++++++++++++++++++++++++
>>>>>>  1 file changed, 36 insertions(+)
>>>>>> 
>>>>>> diff --git a/drivers/mtd/spi-nor/otp.c b/drivers/mtd/spi-nor/otp.c
>>>>>> index 3898ed67ba1c..063f8fb68649 100644
>>>>>> --- a/drivers/mtd/spi-nor/otp.c
>>>>>> +++ b/drivers/mtd/spi-nor/otp.c
>>>>>> @@ -249,6 +249,32 @@ static int spi_nor_mtd_otp_info(struct 
>>>>>> mtd_info
>>>>>> *mtd, size_t len,
>>>>>>         return ret;
>>>>>>  }
>>>>>> 
>>>>>> +static int spi_nor_mtd_otp_range_is_locked(struct spi_nor *nor,
>>>>>> loff_t ofs,
>>>>>> +                                          size_t len)
>>>>>> +{
>>>>>> +       const struct spi_nor_otp_ops *ops = nor->params->otp.ops;
>>>>>> +       unsigned int region;
>>>>>> +       int locked;
>>>>>> +
>>>>>> +       if (!len)
>>>>>> +               return 0;
>>>>>> +
>>>>> 
>>>>> You won't need this if you put patch 4/5 before this one. With 
>>>>> this:
>>>> 
>>>> This patch will get backported to the stable kernels. Patch 4 on the
>>>> other hand does not.
>>>> 
>>> 
>>> I don't see why 4/5 cannot be marked for backport too as it makes 3/5
>>> much cleaner?
>> 
>> What kind of problem does 4/5 fix? I can't see how that patch would
>> apply to any rule in Documentation/process/stable-kernel-rules.rst.
>> 
> 
> Looking further, I don't see the need for 4/5 to be a separate patch.
> Patch 4/5 is simplifying spi_nor_mtd_otp_range_is_locked() by ensuring
> 'len' passed is never 0 which can be done in 3/5 when introducing
> spi_nor_mtd_otp_range_is_locked().
> 
> So why not squashed it into 3/5.

Because, strictly speaking, it is not part of that particular fix
and IMHO violates "It must fix only one thing". But if you're fine
with that, I can squash the two.

TBH I find it kinda funny to bend the rules, just to get rid of
these three lines of code or the ugliness that they will be removed
in the following patch.

-michael

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-06-07  9:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-04 10:02 [PATCH v5 0/5] mtd: spi-nor: otp: 4 byte mode fix and erase support Michael Walle
2021-06-04 10:02 ` Michael Walle
2021-06-04 10:02 ` [PATCH v5 1/5] mtd: spi-nor: otp: fix access to security registers in 4 byte mode Michael Walle
2021-06-04 10:02   ` Michael Walle
2021-06-04 10:02 ` [PATCH v5 2/5] mtd: spi-nor: otp: use more consistent wording Michael Walle
2021-06-04 10:02   ` Michael Walle
2021-06-04 10:02 ` [PATCH v5 3/5] mtd: spi-nor: otp: return -EROFS if region is read-only Michael Walle
2021-06-04 10:02   ` Michael Walle
2021-06-04 13:07   ` Tudor.Ambarus
2021-06-04 13:07     ` Tudor.Ambarus
2021-06-04 13:15     ` Michael Walle
2021-06-04 13:15       ` Michael Walle
2021-06-07  5:46       ` Vignesh Raghavendra
2021-06-07  5:46         ` Vignesh Raghavendra
2021-06-07  6:08         ` Michael Walle
2021-06-07  6:08           ` Michael Walle
2021-06-07  6:47           ` Vignesh Raghavendra
2021-06-07  6:47             ` Vignesh Raghavendra
2021-06-07  9:56             ` Michael Walle [this message]
2021-06-07  9:56               ` Michael Walle
2021-06-07 10:30               ` Vignesh Raghavendra
2021-06-07 10:30                 ` Vignesh Raghavendra
2021-06-07 10:45                 ` Michael Walle
2021-06-07 10:45                   ` Michael Walle
2021-06-04 10:02 ` [PATCH v5 4/5] mtd: spi-nor: otp: simplify length check Michael Walle
2021-06-04 10:02   ` Michael Walle
2021-06-04 13:06   ` Tudor.Ambarus
2021-06-04 13:06     ` Tudor.Ambarus
2021-06-04 10:02 ` [PATCH v5 5/5] mtd: spi-nor: otp: implement erase for Winbond and similar flashes Michael Walle
2021-06-04 10:02   ` Michael Walle
2021-06-04 12:51   ` Tudor.Ambarus
2021-06-04 12:51     ` Tudor.Ambarus

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=2559d150b3a0d964ece0c9e29e155ecc@walle.cc \
    --to=michael@walle.cc \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /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.