All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Santhosh Kumar K <s-k6@ti.com>
Cc: Michael Walle <mwalle@kernel.org>,
	 Pratyush Yadav <pratyush@kernel.org>,  <richard@nod.at>,
	 <vigneshr@ti.com>, <broonie@kernel.org>,
	 <tudor.ambarus@linaro.org>,  <p-mantena@ti.com>,
	<linux-spi@vger.kernel.org>,  <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,  <a-dutta@ti.com>,
	 <u-kumar1@ti.com>, <praneeth@ti.com>
Subject: Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller
Date: Thu, 11 Dec 2025 15:16:43 +0100	[thread overview]
Message-ID: <878qf96r3o.fsf@bootlin.com> (raw)
In-Reply-To: <ea6f3dd7-0732-4de9-8bf1-e88a45ad6ac2@ti.com> (Santhosh Kumar K.'s message of "Wed, 10 Dec 2025 17:04:09 +0530")


>>>> 2. Using of_get_* APIs:
>>>>         Using the standard OF helpers to locate the phypattern partition
>>>>         and retrieve its offset is both reliable and straighforward, and
>>>>         is the approach currently implemented in v2.
>>>
>>> I don't like that hardcoded partition name which is basically
>>> becoming an ABI then.
>>>
>>> At least we'd need some kind of phandle to the partition inside the
>>> controller node (and get the ACK from the DT maintainers).
>> Yes, agreed, this is controller specific, if we need to use an of_ API
>> (which is still not needed for SPI NANDs, only for tuning the read SPI
>> NOR path), it should not just be a partition hardcoded name but a
>> phandle in the controller node.
>
> Yes, using a phandle is a valid idea to avoid relying on a hard-coded
> name. But, it does not work well when multiple chip selects are
> involved. The controller is not tied to a single flash device - a single
> SPI controller may host both NOR and NAND flashes, for example. In such
> case, only the NOR would require this phandle, while the NAND would
> not,

This honestly doesn't seem a problem to me.

> which makes the phandle approach unsuitable. Another example is a
> controller hosting two NOR flashes - both would then need their own
> phandle references.
>
> An alternative would be to associate the phandle with the flash device
> itself rather than with the controller. Let me know your thoughts on
> this approach.

I find pretty strange to have this property in the flash node, even
though I understand the reason. Perhaps an array of phandles may work in
the controller node instead?

Thanks,
Miquèl

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

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Santhosh Kumar K <s-k6@ti.com>
Cc: Michael Walle <mwalle@kernel.org>,
	 Pratyush Yadav <pratyush@kernel.org>,  <richard@nod.at>,
	 <vigneshr@ti.com>, <broonie@kernel.org>,
	 <tudor.ambarus@linaro.org>,  <p-mantena@ti.com>,
	<linux-spi@vger.kernel.org>,  <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,  <a-dutta@ti.com>,
	 <u-kumar1@ti.com>, <praneeth@ti.com>
Subject: Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller
Date: Thu, 11 Dec 2025 15:16:43 +0100	[thread overview]
Message-ID: <878qf96r3o.fsf@bootlin.com> (raw)
In-Reply-To: <ea6f3dd7-0732-4de9-8bf1-e88a45ad6ac2@ti.com> (Santhosh Kumar K.'s message of "Wed, 10 Dec 2025 17:04:09 +0530")


>>>> 2. Using of_get_* APIs:
>>>>         Using the standard OF helpers to locate the phypattern partition
>>>>         and retrieve its offset is both reliable and straighforward, and
>>>>         is the approach currently implemented in v2.
>>>
>>> I don't like that hardcoded partition name which is basically
>>> becoming an ABI then.
>>>
>>> At least we'd need some kind of phandle to the partition inside the
>>> controller node (and get the ACK from the DT maintainers).
>> Yes, agreed, this is controller specific, if we need to use an of_ API
>> (which is still not needed for SPI NANDs, only for tuning the read SPI
>> NOR path), it should not just be a partition hardcoded name but a
>> phandle in the controller node.
>
> Yes, using a phandle is a valid idea to avoid relying on a hard-coded
> name. But, it does not work well when multiple chip selects are
> involved. The controller is not tied to a single flash device - a single
> SPI controller may host both NOR and NAND flashes, for example. In such
> case, only the NOR would require this phandle, while the NAND would
> not,

This honestly doesn't seem a problem to me.

> which makes the phandle approach unsuitable. Another example is a
> controller hosting two NOR flashes - both would then need their own
> phandle references.
>
> An alternative would be to associate the phandle with the flash device
> itself rather than with the controller. Let me know your thoughts on
> this approach.

I find pretty strange to have this property in the flash node, even
though I understand the reason. Perhaps an array of phandles may work in
the controller node instead?

Thanks,
Miquèl

  reply	other threads:[~2025-12-11 14:17 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-11 19:32 [RFC PATCH 00/10] SPINAND PHY Tuning Series Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K
2025-08-13 20:26   ` Mark Brown
2025-08-13 20:26     ` Mark Brown
2025-08-14 11:34     ` Santhosh Kumar K
2025-08-14 11:34       ` Santhosh Kumar K
2025-08-14 12:34       ` Mark Brown
2025-08-14 12:34         ` Mark Brown
2025-08-22  6:05         ` Santhosh Kumar K
2025-08-22  6:05           ` Santhosh Kumar K
2025-09-10  8:07         ` Miquel Raynal
2025-09-10  8:07           ` Miquel Raynal
2025-08-24 17:02     ` Miquel Raynal
2025-08-24 17:02       ` Miquel Raynal
2025-09-10  8:21   ` Miquel Raynal
2025-09-10  8:21     ` Miquel Raynal
2025-09-20 17:55     ` Santhosh Kumar K
2025-09-20 17:55       ` Santhosh Kumar K
2025-10-28 15:41       ` Miquel Raynal
2025-10-28 15:41         ` Miquel Raynal
2025-11-05  8:55         ` Santhosh Kumar K
2025-11-05  8:55           ` Santhosh Kumar K
2025-11-05  9:35           ` Miquel Raynal
2025-11-05  9:35             ` Miquel Raynal
2025-11-18 13:42             ` Pratyush Yadav
2025-11-18 13:42               ` Pratyush Yadav
2025-12-03  8:02               ` Santhosh Kumar K
2025-12-03  8:02                 ` Santhosh Kumar K
2025-12-03  8:58                 ` Miquel Raynal
2025-12-03  8:58                   ` Miquel Raynal
2025-12-10 11:33                   ` Santhosh Kumar K
2025-12-10 11:33                     ` Santhosh Kumar K
2025-12-12  6:43                   ` Pratyush Yadav
2025-12-12  6:43                     ` Pratyush Yadav
2025-11-18 13:49       ` Pratyush Yadav
2025-11-18 13:49         ` Pratyush Yadav
2025-12-03  8:02         ` Santhosh Kumar K
2025-12-03  8:02           ` Santhosh Kumar K
2025-12-03  9:28           ` Michael Walle
2025-12-03  9:28             ` Michael Walle
2025-12-03  9:50             ` Miquel Raynal
2025-12-03  9:50               ` Miquel Raynal
2025-12-03 14:12               ` Michael Walle
2025-12-03 14:12                 ` Michael Walle
2025-12-10 11:36                 ` Santhosh Kumar K
2025-12-10 11:36                   ` Santhosh Kumar K
2025-12-10 11:34               ` Santhosh Kumar K
2025-12-10 11:34                 ` Santhosh Kumar K
2025-12-11 14:16                 ` Miquel Raynal [this message]
2025-12-11 14:16                   ` Miquel Raynal
2025-12-04 16:54           ` Mahapatra, Amit Kumar
2025-12-04 16:54             ` Mahapatra, Amit Kumar
2025-12-10 11:34             ` Santhosh Kumar K
2025-12-10 11:34               ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 02/10] spi: spi-mem: Define spi_mem_tuning_params and spi_mem_get_tuning_params() Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 03/10] mtd: nand: spi: Introduce _execute_tuning for mtd devices Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 04/10] mtd: mtdcore: Call mtd_execute_tuning during mtd_register Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 05/10] spi: cadence-quadspi: Move cqspi_readdata_capture() above all operations Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 06/10] spi: cadence-quadspi: Use BIT() macro for CQSPI_REG_READCAPTURE_BYPASS Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 07/10] spi: cadence-quadspi: Enable PHY for aligned DAC reads Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 08/10] spi: cadence-quadspi: Enable PHY for data writes Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 09/10] spi: cadence-quadspi: Implement PHY for higher frequencies in SDR mode Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 10/10] spi: cadence-quadspi: Define cqspi_get_tuning_params() Santhosh Kumar K
2025-08-11 19:32   ` Santhosh Kumar K

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=878qf96r3o.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=a-dutta@ti.com \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mwalle@kernel.org \
    --cc=p-mantena@ti.com \
    --cc=praneeth@ti.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=s-k6@ti.com \
    --cc=tudor.ambarus@linaro.org \
    --cc=u-kumar1@ti.com \
    --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.