All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: macromorgan@hotmail.com, vigneshr@ti.com, jaimeliao@mxic.com.tw,
	richard@nod.at, esben@geanix.com, linux@rasmusvillemoes.dk,
	knaerzche@gmail.com, Nicolas.Ferre@microchip.com,
	michael@walle.cc, linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, code@reto-schneider.ch,
	miquel.raynal@bootlin.com, heiko.thiery@gmail.com, sr@denx.de,
	mail@david-bauer.net, zhengxunli@mxic.com.tw
Subject: Re: [PATCH v3 03/25] mtd: spi-nor: Introduce spi_nor_set_mtd_info()
Date: Mon, 22 Nov 2021 08:38:56 +0000	[thread overview]
Message-ID: <7949e1c0-6756-8bed-75e5-29c76b4a61aa@microchip.com> (raw)
In-Reply-To: <20211119182316.vkzjpkrkssmoftlo@ti.com>

Hi, Pratyush,

On 11/19/21 8:23 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 17/11/21 02:36PM, Tudor.Ambarus@microchip.com wrote:
>> On 11/16/21 8:11 PM, Pratyush Yadav wrote:
>>
>>>>
>>>>> - spi_nor_try_unlock_all(), which is called by spi_nor_init(). I don't
>>>>>   think it actually uses any values you initialize here but still worth
>>>>>   pointing out.
>>>>
>>>> we are safe here, the pointer to mtd is used just to get the pointer to
>>>> nor.
>>>
>>> Yeah, but who knows if that might change some time later. I would prefer
>>> we don't use a member we haven't initialized yet.
>>
>> If it weren't for the SPI NOR controller drivers that use
>> spi_nor_scan(), I would put the spi_nor_set_mtd_info() just
>> above the mtd_device_register(). It will indicate that no mtd_info
>> field is used up to that point, less things to worry about.
>> spi_nor_try_unlock_all() calls
>>       spi_nor_unlock(&nor->mtd, 0, nor->params->size);
>> I can't see for now if we will ever need some specific mtd_info
>> parameter. I would say that we won't, we're just unlocking the full
>> flash, every info we would need we can obtain from NOR. The discussion
>> would be different if it were about mtd partitions, but it isn't, we're
>> dealing with the entire flash.
>>
>> Would you accept the place where I put spi_nor_set_mtd_info() if I add
>> a comment before calling it? Something like:
>> /* No mtd_info fields are used up to this point. */
>> spi_nor_set_mtd_info();
> 
> I see that everything that spi_nor_set_mtd_info() needs is set by the
> time spi_nor_init_params() is finished. Everything after that is
> concerned about selecting the protocol and sending the init commands to
> the flash. So why can't you call it right after spi_nor_init_params()?

Because I would like to move it just above mtd_device_register() in the future.
If unlock_all() will need some mtd fields in the future, we can introduce a
spi_nor_prepare_mtd_for_unlock_all(). I don't want the mtd fields init to be
scattered through the SPI NOR core. They shouldn't be used in the NOR's
probe sequence of calls anyway, keeping them closer to mtd_device_register()
makes the code easier to grasp I think.

I will respin the series soon and wanted to let you know why I kept
spi_nor_set_mtd_info() where it is in this patch set.

Cheers,
ta

> That and updating spi_nor_spimem_check_op() and spi_nor_set_addr_width()
> to use nor->params->size instead of nor->mtd.size should do the trick.
> 
> I think that it is implied that mtd_info fields are not being used until
> they are initialized so I don't think the comment itself is of much use,
> but I don't care much about it either way.
> 
> --
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.
> 

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

WARNING: multiple messages have this Message-ID (diff)
From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: macromorgan@hotmail.com, vigneshr@ti.com, jaimeliao@mxic.com.tw,
	richard@nod.at, esben@geanix.com, linux@rasmusvillemoes.dk,
	knaerzche@gmail.com, michael@walle.cc,
	linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, code@reto-schneider.ch,
	miquel.raynal@bootlin.com, heiko.thiery@gmail.com, sr@denx.de,
	figgyc@figgyc.uk, mail@david-bauer.net, zhengxunli@mxic.com.tw
Subject: Re: [PATCH v3 03/25] mtd: spi-nor: Introduce spi_nor_set_mtd_info()
Date: Mon, 22 Nov 2021 08:38:56 +0000	[thread overview]
Message-ID: <7949e1c0-6756-8bed-75e5-29c76b4a61aa@microchip.com> (raw)
In-Reply-To: <20211119182316.vkzjpkrkssmoftlo@ti.com>

Hi, Pratyush,

On 11/19/21 8:23 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 17/11/21 02:36PM, Tudor.Ambarus@microchip.com wrote:
>> On 11/16/21 8:11 PM, Pratyush Yadav wrote:
>>
>>>>
>>>>> - spi_nor_try_unlock_all(), which is called by spi_nor_init(). I don't
>>>>>   think it actually uses any values you initialize here but still worth
>>>>>   pointing out.
>>>>
>>>> we are safe here, the pointer to mtd is used just to get the pointer to
>>>> nor.
>>>
>>> Yeah, but who knows if that might change some time later. I would prefer
>>> we don't use a member we haven't initialized yet.
>>
>> If it weren't for the SPI NOR controller drivers that use
>> spi_nor_scan(), I would put the spi_nor_set_mtd_info() just
>> above the mtd_device_register(). It will indicate that no mtd_info
>> field is used up to that point, less things to worry about.
>> spi_nor_try_unlock_all() calls
>>       spi_nor_unlock(&nor->mtd, 0, nor->params->size);
>> I can't see for now if we will ever need some specific mtd_info
>> parameter. I would say that we won't, we're just unlocking the full
>> flash, every info we would need we can obtain from NOR. The discussion
>> would be different if it were about mtd partitions, but it isn't, we're
>> dealing with the entire flash.
>>
>> Would you accept the place where I put spi_nor_set_mtd_info() if I add
>> a comment before calling it? Something like:
>> /* No mtd_info fields are used up to this point. */
>> spi_nor_set_mtd_info();
> 
> I see that everything that spi_nor_set_mtd_info() needs is set by the
> time spi_nor_init_params() is finished. Everything after that is
> concerned about selecting the protocol and sending the init commands to
> the flash. So why can't you call it right after spi_nor_init_params()?

Because I would like to move it just above mtd_device_register() in the future.
If unlock_all() will need some mtd fields in the future, we can introduce a
spi_nor_prepare_mtd_for_unlock_all(). I don't want the mtd fields init to be
scattered through the SPI NOR core. They shouldn't be used in the NOR's
probe sequence of calls anyway, keeping them closer to mtd_device_register()
makes the code easier to grasp I think.

I will respin the series soon and wanted to let you know why I kept
spi_nor_set_mtd_info() where it is in this patch set.

Cheers,
ta

> That and updating spi_nor_spimem_check_op() and spi_nor_set_addr_width()
> to use nor->params->size instead of nor->mtd.size should do the trick.
> 
> I think that it is implied that mtd_info fields are not being used until
> they are initialized so I don't think the comment itself is of much use,
> but I don't care much about it either way.
> 
> --
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-11-22  8:40 UTC|newest]

Thread overview: 156+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29 17:26 [PATCH v3 00/25] mtd: spi-nor: Clean params init Tudor Ambarus
2021-10-29 17:26 ` Tudor Ambarus
2021-10-29 17:26 ` [PATCH v3 01/25] mtd: spi-nor: core: Fix spi_nor_flash_parameter otp description Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  8:18   ` Michael Walle
2021-11-09  8:18     ` Michael Walle
2021-10-29 17:26 ` [PATCH v3 02/25] mtd: spi-nor: core: Use container_of to get the pointer to struct spi_nor Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  8:21   ` Michael Walle
2021-11-09  8:21     ` Michael Walle
2021-11-15 10:59   ` Pratyush Yadav
2021-11-15 10:59     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 03/25] mtd: spi-nor: Introduce spi_nor_set_mtd_info() Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  8:22   ` Michael Walle
2021-11-09  8:22     ` Michael Walle
2021-11-15 18:52   ` Pratyush Yadav
2021-11-15 18:52     ` Pratyush Yadav
2021-11-16 14:25     ` Tudor.Ambarus
2021-11-16 14:25       ` Tudor.Ambarus
2021-11-16 18:11       ` Pratyush Yadav
2021-11-16 18:11         ` Pratyush Yadav
2021-11-17 14:36         ` Tudor.Ambarus
2021-11-17 14:36           ` Tudor.Ambarus
2021-11-19 18:23           ` Pratyush Yadav
2021-11-19 18:23             ` Pratyush Yadav
2021-11-22  8:38             ` Tudor.Ambarus [this message]
2021-11-22  8:38               ` Tudor.Ambarus
2021-10-29 17:26 ` [PATCH v3 04/25] mtd: spi-nor: Get rid of nor->page_size Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  8:24   ` Michael Walle
2021-11-09  8:24     ` Michael Walle
2021-11-09  8:34     ` Tudor.Ambarus
2021-11-09  8:34       ` Tudor.Ambarus
2021-10-29 17:26 ` [PATCH v3 05/25] mtd: spi-nor: core: Introduce the late_init() hook Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  9:31   ` Michael Walle
2021-11-09  9:31     ` Michael Walle
2021-11-15 18:56   ` Pratyush Yadav
2021-11-15 18:56     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 06/25] mtd: spi-nor: atmel: Use flash late_init() for locking Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  9:31   ` Michael Walle
2021-11-09  9:31     ` Michael Walle
2021-11-15 18:59   ` Pratyush Yadav
2021-11-15 18:59     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 07/25] mtd: spi-nor: sst: " Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  9:34   ` Michael Walle
2021-11-09  9:34     ` Michael Walle
2021-11-15 19:00   ` Pratyush Yadav
2021-11-15 19:00     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 08/25] mtd: spi-nor: winbond: Use manufacturer late_init() for OTP ops Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  9:36   ` Michael Walle
2021-11-09  9:36     ` Michael Walle
2021-11-15 19:00   ` Pratyush Yadav
2021-11-15 19:00     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 09/25] mtd: spi-nor: xilinx: Use manufacturer late_init() to set setup method Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  9:43   ` Michael Walle
2021-11-09  9:43     ` Michael Walle
2021-11-15 19:01   ` Pratyush Yadav
2021-11-15 19:01     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 10/25] mtd: spi-nor: sst: Use manufacturer late_init() to set _write() Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  9:47   ` Michael Walle
2021-11-09  9:47     ` Michael Walle
2021-11-09 10:22     ` Tudor.Ambarus
2021-11-09 10:22       ` Tudor.Ambarus
2021-11-09 10:23       ` Tudor.Ambarus
2021-11-09 10:23         ` Tudor.Ambarus
2021-11-09 10:24       ` Michael Walle
2021-11-09 10:24         ` Michael Walle
2021-11-15 19:03   ` Pratyush Yadav
2021-11-15 19:03     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 11/25] mtd: spi-nor: spansion: Use manufacturer late_init() Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09  9:48   ` Michael Walle
2021-11-09  9:48     ` Michael Walle
2021-11-15 19:06   ` Pratyush Yadav
2021-11-15 19:06     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 12/25] mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only when SFDP is defined Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09 10:18   ` Michael Walle
2021-11-09 10:18     ` Michael Walle
2021-10-29 17:26 ` [PATCH v3 13/25] mtd: spi-nor: sst: Get rid of SST_WRITE flash_info flag Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-09 12:21   ` Michael Walle
2021-11-09 12:21     ` Michael Walle
2021-11-09 12:31     ` Tudor.Ambarus
2021-11-09 12:31       ` Tudor.Ambarus
2021-11-12 21:28       ` Michael Walle
2021-11-12 21:28         ` Michael Walle
2021-10-29 17:26 ` [PATCH v3 14/25] mtd: spi-nor: Introduce flash_info flags masks Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-12 21:50   ` Michael Walle
2021-11-12 21:50     ` Michael Walle
2021-11-15  4:55     ` Tudor.Ambarus
2021-11-15  4:55       ` Tudor.Ambarus
2021-10-29 17:26 ` [PATCH v3 15/25] mtd: spi-nor: Introduce spi_nor_nonsfdp_init_flags() Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-15 19:12   ` Pratyush Yadav
2021-11-15 19:12     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 16/25] mtd: spi-nor: Introduce spi_nor_init_fixup_flags() Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-16 10:57   ` Pratyush Yadav
2021-11-16 10:57     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 17/25] mtd: spi-nor: core: Introduce SPI_NOR_PARSE_SFDP Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-10-29 17:26 ` [PATCH v3 18/25] mtd: spi-nor: core: Init flash params based on SFDP first for new flash additions Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-16 11:07   ` Pratyush Yadav
2021-11-16 11:07     ` Pratyush Yadav
2021-10-29 17:26 ` [PATCH v3 19/25] mtd: spi-nor: core: Move spi_nor_set_addr_width() in spi_nor_setup() Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-11-12 21:53   ` Michael Walle
2021-11-12 21:53     ` Michael Walle
2021-10-29 17:26 ` [PATCH v3 20/25] mtd: spi-nor: sst: sst26vf064b: Init flash based on SFDP Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-10-29 17:31   ` Tudor.Ambarus
2021-10-29 17:31     ` Tudor.Ambarus
2021-11-09 12:25     ` Michael Walle
2021-11-09 12:25       ` Michael Walle
2021-11-09 12:33       ` Tudor.Ambarus
2021-11-09 12:33         ` Tudor.Ambarus
2021-11-09 12:37         ` Michael Walle
2021-11-09 12:37           ` Michael Walle
2021-10-29 17:26 ` [PATCH v3 21/25] mtd: spi-nor: winbond: w25q256jvm: " Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-10-29 17:31   ` Tudor.Ambarus
2021-10-29 17:31     ` Tudor.Ambarus
2021-10-29 17:26 ` [PATCH v3 22/25] mtd: spi-nor: spansion: s25fl256s0: Skip SFDP parsing Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-10-29 17:26 ` [PATCH v3 23/25] mtd: spi-nor: gigadevice: gd25q256: Init flash based on SFDP Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-10-29 17:33   ` Tudor.Ambarus
2021-10-29 17:33     ` Tudor.Ambarus
2021-10-29 17:26 ` [PATCH v3 24/25] mtd: spi-nor: issi: is25lp256: " Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-10-29 17:33   ` Tudor.Ambarus
2021-10-29 17:33     ` Tudor.Ambarus
2021-10-29 17:26 ` [PATCH v3 25/25] mtd: spi-nor: macronix: mx25l25635e: " Tudor Ambarus
2021-10-29 17:26   ` Tudor Ambarus
2021-10-29 17:34   ` Tudor.Ambarus
2021-10-29 17:34     ` Tudor.Ambarus
2021-11-08 10:15 ` [PATCH v3 00/25] mtd: spi-nor: Clean params init Tudor.Ambarus
2021-11-08 10:15   ` Tudor.Ambarus
2021-11-08 10:31   ` Michael Walle
2021-11-08 10:31     ` Michael Walle
2021-11-16 11:36 ` Pratyush Yadav
2021-11-16 11:36   ` Pratyush Yadav
2021-11-16 11:56   ` Michael Walle
2021-11-16 11:56     ` Michael Walle
2021-11-17 13:17 ` (subset)[PATCH " Tudor Ambarus
2021-11-17 13:17   ` 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=7949e1c0-6756-8bed-75e5-29c76b4a61aa@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=code@reto-schneider.ch \
    --cc=esben@geanix.com \
    --cc=heiko.thiery@gmail.com \
    --cc=jaimeliao@mxic.com.tw \
    --cc=knaerzche@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=macromorgan@hotmail.com \
    --cc=mail@david-bauer.net \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=sr@denx.de \
    --cc=vigneshr@ti.com \
    --cc=zhengxunli@mxic.com.tw \
    /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.