* Re: [PATCH] spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189
From: Rob Herring (Arm) @ 2026-03-11 4:23 UTC (permalink / raw)
To: Meiker Gao
Cc: Chuanhong Guo, linux-kernel, linux-arm-kernel, linux-spi,
Project_Global_Chrome_Upstream_Group, jh.hsu,
AngeloGioacchino Del Regno, Krzysztof Kozlowski, devicetree,
Matthias Brugger, Bayi Cheng, vince-wl.liu, Conor Dooley,
Mark Brown, sirius.wang, linux-mediatek
In-Reply-To: <20260311034342.721583-1-ot_meiker.gao@mediatek.com>
On Wed, 11 Mar 2026 11:43:40 +0800, Meiker Gao wrote:
> Update mediatek,spi-mtk-nor.yaml to add conditional clock and
> clock-names bindings for the mt8189-nor platform. The mt8189-nor
> controller requires five specific clocks and corresponding clock-names
> ("spi", "sf", "axi_f", "axi_h", "axi_p"). This change enforces these
> requirements in the device tree binding schema.
>
> For other platforms, the minimum number of clocks and clock-names
> remains unchanged. The patch also adds an example for mt8189-nor,
> illustrating the new clock configuration.
>
> This update ensures correct hardware description and validation for
> mt8189-nor, improving compatibility and reducing configuration errors.
>
> Signed-off-by: Meiker Gao <ot_meiker.gao@mediatek.com>
> (cherry picked from commit c3180d35e52b5213764a89403e71f9a34d7bb842)
> ---
> .../bindings/spi/mediatek,spi-mtk-nor.yaml | 46 ++++++++++++++-----
> 1 file changed, 34 insertions(+), 12 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml: allOf:1:then:properties:clock-names: {'maxItems': 5, 'items': [{'const': 'spi'}, {'const': 'sf'}, {'const': 'axi_f'}, {'const': 'axi_h'}, {'const': 'axi_p'}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260311034342.721583-1-ot_meiker.gao@mediatek.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Patchwork housekeeping for: spi-devel-general
From: patchwork-bot+spi-devel-general @ 2026-03-11 3:57 UTC (permalink / raw)
To: linux-spi, broonie
Latest series: [v1] spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189 (2026-03-11T03:43:40)
Superseding: [v1] spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189 (2026-03-11T01:51:27):
spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189
From: Meiker Gao @ 2026-03-11 3:43 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Bayi Cheng,
Chuanhong Guo
Cc: linux-spi, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Meiker Gao
Update mediatek,spi-mtk-nor.yaml to add conditional clock and
clock-names bindings for the mt8189-nor platform. The mt8189-nor
controller requires five specific clocks and corresponding clock-names
("spi", "sf", "axi_f", "axi_h", "axi_p"). This change enforces these
requirements in the device tree binding schema.
For other platforms, the minimum number of clocks and clock-names
remains unchanged. The patch also adds an example for mt8189-nor,
illustrating the new clock configuration.
This update ensures correct hardware description and validation for
mt8189-nor, improving compatibility and reducing configuration errors.
Signed-off-by: Meiker Gao <ot_meiker.gao@mediatek.com>
(cherry picked from commit c3180d35e52b5213764a89403e71f9a34d7bb842)
---
.../bindings/spi/mediatek,spi-mtk-nor.yaml | 46 ++++++++++++++-----
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
index a453996c13f2..ff815266479f 100644
--- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
@@ -17,9 +17,6 @@ description: |
for devices other than SPI NOR flash due to limited transfer
capability of this controller.
-allOf:
- - $ref: /schemas/spi/spi-controller.yaml#
-
properties:
compatible:
oneOf:
@@ -27,6 +24,7 @@ properties:
- mediatek,mt8173-nor
- mediatek,mt8186-nor
- mediatek,mt8192-nor
+ - mediatek,mt8189-nor
- items:
- enum:
- mediatek,mt2701-nor
@@ -39,6 +37,7 @@ properties:
- items:
- enum:
- mediatek,mt8188-nor
+ - mediatek,mt8189-nor
- const: mediatek,mt8186-nor
reg:
@@ -56,14 +55,8 @@ properties:
design, so this is optional.
- description: clock used for controller axi slave bus.
this depends on hardware design, so it is optional.
-
- clock-names:
- minItems: 2
- items:
- - const: spi
- - const: sf
- - const: axi
- - const: axi_s
+ - description: clock used for controller axi_f, axi_h, and
+ axi_p to support the new platform.
required:
- compatible
@@ -71,6 +64,35 @@ required:
- clocks
- clock-names
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-nor
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ maxItems: 5
+ items:
+ - const: spi
+ - const: sf
+ - const: axi_f
+ - const: axi_h
+ - const: axi_p
+ else:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: spi
+ - const: sf
+ - const: axi
+
unevaluatedProperties: false
examples:
@@ -81,7 +103,7 @@ examples:
#address-cells = <2>;
#size-cells = <2>;
- nor_flash: spi@1100d000 {
+ spi@1100d000 {
compatible = "mediatek,mt8173-nor";
reg = <0 0x1100d000 0 0xe0>;
interrupts = <1>;
--
2.45.2
^ permalink raw reply related
* Re: [PATCH] spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189
From: Rob Herring (Arm) @ 2026-03-11 3:23 UTC (permalink / raw)
To: Meiker Gao
Cc: AngeloGioacchino Del Regno, linux-mediatek, jh.hsu,
Matthias Brugger, Mark Brown, linux-arm-kernel, linux-spi,
sirius.wang, Krzysztof Kozlowski, devicetree, linux-kernel,
Project_Global_Chrome_Upstream_Group, Conor Dooley, Chuanhong Guo,
vince-wl.liu, Bayi Cheng
In-Reply-To: <20260311015214.655555-1-ot_meiker.gao@mediatek.com>
On Wed, 11 Mar 2026 09:51:27 +0800, Meiker Gao wrote:
> Update mediatek,spi-mtk-nor.yaml to add conditional clock and clock-names
> bindings for the mt8189-nor platform. The mt8189-nor controller requires
> five specific clocks and corresponding clock-names ("spi", "sf", "axi_f",
> "axi_h", "axi_p"). This change enforces these requirements in the device
> tree binding schema.
>
> For other platforms, the minimum number of clocks and clock-names remains
> unchanged. The patch also adds an example for mt8189-nor, illustrating the
> new clock configuration.
>
> This update ensures correct hardware description and validation for
> mt8189-nor, improving compatibility and reducing configuration errors.
>
> Signed-off-by: Meiker Gao <ot_meiker.gao@mediatek.com>
> (cherry picked from commit de637a2fea765a92d4b06efef34671c74f8bc109)
> ---
> .../bindings/spi/mediatek,spi-mtk-nor.yaml | 71 +++++++++++++++----
> 1 file changed, 59 insertions(+), 12 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml: allOf:1:then:properties:clock-names: {'maxItems': 5, 'items': [{'const': 'spi'}, {'const': 'sf'}, {'const': 'axi_f'}, {'const': 'axi_h'}, {'const': 'axi_p'}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.example.dts:69:18: fatal error: dt-bindings/clock/mediatek,mt8189-clk.h: No such file or directory
69 | #include <dt-bindings/clock/mediatek,mt8189-clk.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.dtbs:140: Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1608: dt_binding_check] Error 2
make: *** [Makefile:248: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260311015214.655555-1-ot_meiker.gao@mediatek.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Patchwork housekeeping for: spi-devel-general
From: patchwork-bot+spi-devel-general @ 2026-03-11 1:57 UTC (permalink / raw)
To: linux-spi, broonie
Latest series: [v1] spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189 (2026-03-11T01:51:27)
Superseding: [v1] spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189 (2026-03-05T07:15:42):
spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v2 2/2] spi: atcspi200: fix mutex initialization order
From: Pei Xiao @ 2026-03-11 1:55 UTC (permalink / raw)
To: cl634, broonie, linux-spi, linux-kernel; +Cc: Pei Xiao
In-Reply-To: <cover.1773193726.git.xiaopei01@kylinos.cn>
The atcspi_exec_mem_op() function may call mutex_lock() on the
driver's mutex before it is properly initialized if a SPI memory
operation is initiated immediately after devm_spi_register_controller()
is called. The mutex initialization currently occurs after the
controller registration, which leaves a window where the mutex could
be used uninitialized.
Move the mutex initialization to the beginning of the probe function,
before any registration or resource allocation. Also replace the
plain mutex_init() with devm_mutex_init() to benefit from automatic
cleanup on driver unbind, preventing potential resource leaks.
Fixes: 34e3815ea459 ("spi: atcspi200: Add ATCSPI200 SPI controller driver")
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
drivers/spi/spi-atcspi200.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-atcspi200.c b/drivers/spi/spi-atcspi200.c
index c0607193be8d..dd1292c5bb98 100644
--- a/drivers/spi/spi-atcspi200.c
+++ b/drivers/spi/spi-atcspi200.c
@@ -551,6 +551,10 @@ static int atcspi_probe(struct platform_device *pdev)
spi->dev = &pdev->dev;
dev_set_drvdata(&pdev->dev, host);
+ ret = devm_mutex_init(spi->dev, &spi->mutex_lock);
+ if (ret)
+ goto free_controller;
+
ret = atcspi_init_resources(pdev, spi, &mem_res);
if (ret)
goto free_controller;
@@ -580,7 +584,6 @@ static int atcspi_probe(struct platform_device *pdev)
else
spi->use_dma = true;
}
- mutex_init(&spi->mutex_lock);
return 0;
--
2.25.1
^ permalink raw reply related
* [PATCH v2 1/2] spi: atcspi200: Use helper function devm_clk_get_enabled()
From: Pei Xiao @ 2026-03-11 1:55 UTC (permalink / raw)
To: cl634, broonie, linux-spi, linux-kernel; +Cc: Pei Xiao
In-Reply-To: <cover.1773193726.git.xiaopei01@kylinos.cn>
Since commit 7ef9651e9792 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled(). Moreover, it is no longer necessary to
unprepare and disable the clocks explicitly.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
drivers/spi/spi-atcspi200.c | 24 ++++++------------------
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/spi-atcspi200.c b/drivers/spi/spi-atcspi200.c
index dd19fe9f9ee7..c0607193be8d 100644
--- a/drivers/spi/spi-atcspi200.c
+++ b/drivers/spi/spi-atcspi200.c
@@ -486,11 +486,6 @@ static int atcspi_init_resources(struct platform_device *pdev,
return dev_err_probe(spi->dev, PTR_ERR(spi->regmap),
"Failed to init regmap\n");
- spi->clk = devm_clk_get(spi->dev, NULL);
- if (IS_ERR(spi->clk))
- return dev_err_probe(spi->dev, PTR_ERR(spi->clk),
- "Failed to get SPI clock\n");
-
spi->sclk_rate = ATCSPI_MAX_SPEED_HZ;
return 0;
}
@@ -512,13 +507,10 @@ static int atcspi_configure_dma(struct atcspi_dev *spi)
static int atcspi_enable_clk(struct atcspi_dev *spi)
{
- int ret;
-
- ret = clk_prepare_enable(spi->clk);
- if (ret)
- return dev_err_probe(spi->dev, ret,
- "Failed to enable clock\n");
-
+ spi->clk = devm_clk_get_enabled(spi->dev, NULL);
+ if (IS_ERR(spi->clk))
+ return dev_err_probe(spi->dev, PTR_ERR(spi->clk),
+ "Failed to get SPI clock\n");
spi->clk_rate = clk_get_rate(spi->clk);
if (!spi->clk_rate)
return dev_err_probe(spi->dev, -EINVAL,
@@ -571,15 +563,14 @@ static int atcspi_probe(struct platform_device *pdev)
ret = atcspi_setup(spi);
if (ret)
- goto disable_clk;
+ goto free_controller;
ret = devm_spi_register_controller(&pdev->dev, host);
if (ret) {
dev_err_probe(spi->dev, ret,
"Failed to register SPI controller\n");
- goto disable_clk;
+ goto free_controller;
}
-
spi->use_dma = false;
if (ATCSPI_DMA_SUPPORT) {
ret = atcspi_configure_dma(spi);
@@ -593,9 +584,6 @@ static int atcspi_probe(struct platform_device *pdev)
return 0;
-disable_clk:
- clk_disable_unprepare(spi->clk);
-
free_controller:
spi_controller_put(host);
return ret;
--
2.25.1
^ permalink raw reply related
* [PATCH v2 0/2] two cleanups in atcspi200
From: Pei Xiao @ 2026-03-11 1:55 UTC (permalink / raw)
To: cl634, broonie, linux-spi, linux-kernel; +Cc: Pei Xiao
1.Use helper function devm_clk_get_enabled() to simple code.
2.fix mutex initialization order
---
changlog in v2: fix return code error and leak the controller
---
Pei Xiao (2):
spi: atcspi200: Use helper function devm_clk_get_enabled()
spi: atcspi200: fix mutex initialization order
drivers/spi/spi-atcspi200.c | 29 ++++++++++-------------------
1 file changed, 10 insertions(+), 19 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH] spi: dt-bindings: mediatek,spi-mtk-nor: Add clock bindings for mt8189
From: Meiker Gao @ 2026-03-11 1:51 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Bayi Cheng,
Chuanhong Guo
Cc: linux-spi, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Meiker Gao
Update mediatek,spi-mtk-nor.yaml to add conditional clock and clock-names
bindings for the mt8189-nor platform. The mt8189-nor controller requires
five specific clocks and corresponding clock-names ("spi", "sf", "axi_f",
"axi_h", "axi_p"). This change enforces these requirements in the device
tree binding schema.
For other platforms, the minimum number of clocks and clock-names remains
unchanged. The patch also adds an example for mt8189-nor, illustrating the
new clock configuration.
This update ensures correct hardware description and validation for
mt8189-nor, improving compatibility and reducing configuration errors.
Signed-off-by: Meiker Gao <ot_meiker.gao@mediatek.com>
(cherry picked from commit de637a2fea765a92d4b06efef34671c74f8bc109)
---
.../bindings/spi/mediatek,spi-mtk-nor.yaml | 71 +++++++++++++++----
1 file changed, 59 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
index a453996c13f2..904c25279e2d 100644
--- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
@@ -17,9 +17,6 @@ description: |
for devices other than SPI NOR flash due to limited transfer
capability of this controller.
-allOf:
- - $ref: /schemas/spi/spi-controller.yaml#
-
properties:
compatible:
oneOf:
@@ -27,6 +24,7 @@ properties:
- mediatek,mt8173-nor
- mediatek,mt8186-nor
- mediatek,mt8192-nor
+ - mediatek,mt8189-nor
- items:
- enum:
- mediatek,mt2701-nor
@@ -39,6 +37,7 @@ properties:
- items:
- enum:
- mediatek,mt8188-nor
+ - mediatek,mt8189-nor
- const: mediatek,mt8186-nor
reg:
@@ -56,14 +55,8 @@ properties:
design, so this is optional.
- description: clock used for controller axi slave bus.
this depends on hardware design, so it is optional.
-
- clock-names:
- minItems: 2
- items:
- - const: spi
- - const: sf
- - const: axi
- - const: axi_s
+ - description: clock used for controller axi_f, axi_h, and
+ axi_p to support the new platform.
required:
- compatible
@@ -71,6 +64,35 @@ required:
- clocks
- clock-names
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-nor
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ maxItems: 5
+ items:
+ - const: spi
+ - const: sf
+ - const: axi_f
+ - const: axi_h
+ - const: axi_p
+ else:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: spi
+ - const: sf
+ - const: axi
+
unevaluatedProperties: false
examples:
@@ -81,7 +103,7 @@ examples:
#address-cells = <2>;
#size-cells = <2>;
- nor_flash: spi@1100d000 {
+ spi@1100d000 {
compatible = "mediatek,mt8173-nor";
reg = <0 0x1100d000 0 0xe0>;
interrupts = <1>;
@@ -97,3 +119,28 @@ examples:
};
};
};
+
+ - |
+ #include <dt-bindings/clock/mediatek,mt8189-clk.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ spi@11018000 {
+ compatible = "mediatek,mt8189-nor";
+ reg = <0 0x1100d000 0 0xe0>;
+ interrupts = <1>;
+ clocks = <&pericfg CLK_PERI_SPI>, <&topckgen CLK_TOP_SPINFI_IFR_SEL>,
+ <&pericfg CLK_PERAO_SFLASH_F>, <&topckgen CLK_PERAO_SFLASH_H>,
+ <&pericfg CLK_PERAO_SFLASH_P>;
+ clock-names = "spi", "sf", "axi_f", "axi_h", "axi_p";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+ };
+ };
--
2.45.2
^ permalink raw reply related
* Re: [PATCH] spi: atcspi200: Use helper function devm_clk_get_enabled()
From: kernel test robot @ 2026-03-10 20:43 UTC (permalink / raw)
To: Pei Xiao, cl634, broonie, linux-spi, linux-kernel
Cc: llvm, oe-kbuild-all, Pei Xiao
In-Reply-To: <9f6e31608a24f3cdbd6e1429c1e006ccf9f7d9c1.1773132237.git.xiaopei01@kylinos.cn>
Hi Pei,
kernel test robot noticed the following build warnings:
[auto build test WARNING on broonie-spi/for-next]
[also build test WARNING on linus/master v7.0-rc3 next-20260309]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Pei-Xiao/spi-atcspi200-Use-helper-function-devm_clk_get_enabled/20260310-165916
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
patch link: https://lore.kernel.org/r/9f6e31608a24f3cdbd6e1429c1e006ccf9f7d9c1.1773132237.git.xiaopei01%40kylinos.cn
patch subject: [PATCH] spi: atcspi200: Use helper function devm_clk_get_enabled()
config: riscv-randconfig-001-20260310 (https://download.01.org/0day-ci/archive/20260311/202603110449.mxLAYdGU-lkp@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260311/202603110449.mxLAYdGU-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603110449.mxLAYdGU-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/spi/spi-atcspi200.c:510:6: warning: unused variable 'ret' [-Wunused-variable]
510 | int ret;
| ^~~
1 warning generated.
vim +/ret +510 drivers/spi/spi-atcspi200.c
34e3815ea459713 CL Wang 2025-12-15 507
34e3815ea459713 CL Wang 2025-12-15 508 static int atcspi_enable_clk(struct atcspi_dev *spi)
34e3815ea459713 CL Wang 2025-12-15 509 {
34e3815ea459713 CL Wang 2025-12-15 @510 int ret;
34e3815ea459713 CL Wang 2025-12-15 511
7dd262df6a0fc29 Pei Xiao 2026-03-10 512 spi->clk = devm_clk_get_enabled(spi->dev, NULL);
7dd262df6a0fc29 Pei Xiao 2026-03-10 513 if (IS_ERR(spi->clk))
7dd262df6a0fc29 Pei Xiao 2026-03-10 514 return dev_err_probe(spi->dev, PTR_ERR(spi->clk),
7dd262df6a0fc29 Pei Xiao 2026-03-10 515 "Failed to get SPI clock\n");
34e3815ea459713 CL Wang 2025-12-15 516 spi->clk_rate = clk_get_rate(spi->clk);
34e3815ea459713 CL Wang 2025-12-15 517 if (!spi->clk_rate)
34e3815ea459713 CL Wang 2025-12-15 518 return dev_err_probe(spi->dev, -EINVAL,
34e3815ea459713 CL Wang 2025-12-15 519 "Failed to get SPI clock rate\n");
34e3815ea459713 CL Wang 2025-12-15 520
34e3815ea459713 CL Wang 2025-12-15 521 return 0;
34e3815ea459713 CL Wang 2025-12-15 522 }
34e3815ea459713 CL Wang 2025-12-15 523
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: allwinner: sun55i-t527: avaota-a1: Add SPI NAND
From: Chen-Yu Tsai @ 2026-03-10 19:49 UTC (permalink / raw)
To: Mark Brown
Cc: Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-sunxi, devicetree, linux-spi,
linux-arm-kernel, linux-kernel
In-Reply-To: <33204e68-5e65-4486-a473-79d09def88a8@sirena.org.uk>
On Wed, Mar 11, 2026 at 3:48 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Mar 11, 2026 at 03:44:01AM +0800, Chen-Yu Tsai wrote:
> > On Wed, Mar 11, 2026 at 3:42 AM Mark Brown <broonie@kernel.org> wrote:
> > > On Wed, Mar 11, 2026 at 03:41:07AM +0800, Chen-Yu Tsai wrote:
>
> > > > [1/3] spi: dt-bindings: sun6i: Allow Dual SPI and Quad SPI for newer SoCs
> > > > commit: e2f93f45d38f7b6dacb44203cfc7bb5d7e287b8e
>
> > > I'd have expected to take this one?
>
> > Normally you merge patches pretty quickly, so I thought maybe you weren't
> > going to take this one.
>
> I tend to leave a week or two if I think it's likely someone's going to
> review.
>
> > I can back it out if you want to take it through the SPI tree.
>
> Probably safer for conflicts.
Now backed out.
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: allwinner: sun55i-t527: avaota-a1: Add SPI NAND
From: Mark Brown @ 2026-03-10 19:47 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-sunxi, devicetree, linux-spi,
linux-arm-kernel, linux-kernel
In-Reply-To: <CAGb2v65TyEkirWpfynKnSCiuOAyTW1FZQyXncnTFEHGGOQr_Fw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
On Wed, Mar 11, 2026 at 03:44:01AM +0800, Chen-Yu Tsai wrote:
> On Wed, Mar 11, 2026 at 3:42 AM Mark Brown <broonie@kernel.org> wrote:
> > On Wed, Mar 11, 2026 at 03:41:07AM +0800, Chen-Yu Tsai wrote:
> > > [1/3] spi: dt-bindings: sun6i: Allow Dual SPI and Quad SPI for newer SoCs
> > > commit: e2f93f45d38f7b6dacb44203cfc7bb5d7e287b8e
> > I'd have expected to take this one?
> Normally you merge patches pretty quickly, so I thought maybe you weren't
> going to take this one.
I tend to leave a week or two if I think it's likely someone's going to
review.
> I can back it out if you want to take it through the SPI tree.
Probably safer for conflicts.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: allwinner: sun55i-t527: avaota-a1: Add SPI NAND
From: Chen-Yu Tsai @ 2026-03-10 19:44 UTC (permalink / raw)
To: Mark Brown
Cc: Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-sunxi, devicetree, linux-spi,
linux-arm-kernel, linux-kernel
In-Reply-To: <f3ed7b81-4e43-4baa-8a56-b18fa7f56436@sirena.org.uk>
On Wed, Mar 11, 2026 at 3:42 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Mar 11, 2026 at 03:41:07AM +0800, Chen-Yu Tsai wrote:
>
> > [1/3] spi: dt-bindings: sun6i: Allow Dual SPI and Quad SPI for newer SoCs
> > commit: e2f93f45d38f7b6dacb44203cfc7bb5d7e287b8e
>
> I'd have expected to take this one?
Normally you merge patches pretty quickly, so I thought maybe you weren't
going to take this one.
I can back it out if you want to take it through the SPI tree.
Thanks
ChenYu
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: allwinner: sun55i-t527: avaota-a1: Add SPI NAND
From: Mark Brown @ 2026-03-10 19:42 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-sunxi, devicetree, linux-spi,
linux-arm-kernel, linux-kernel
In-Reply-To: <177317166704.379398.1719490251066452420.b4-ty@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 233 bytes --]
On Wed, Mar 11, 2026 at 03:41:07AM +0800, Chen-Yu Tsai wrote:
> [1/3] spi: dt-bindings: sun6i: Allow Dual SPI and Quad SPI for newer SoCs
> commit: e2f93f45d38f7b6dacb44203cfc7bb5d7e287b8e
I'd have expected to take this one?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: allwinner: sun55i-t527: avaota-a1: Add SPI NAND
From: Chen-Yu Tsai @ 2026-03-10 19:41 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Mark Brown, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-sunxi,
devicetree, linux-spi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260302153559.3199783-1-wens@kernel.org>
On Mon, 02 Mar 2026 23:35:55 +0800, Chen-Yu Tsai wrote:
> This is v2 of my Avaota A1 SPI NAND enablement series.
>
> Changes since v1:
> - DT bindings (Krzysztof)
> - Moved "allOf:" block after "required:" block
> - Dropped "type:" from child node in conditional block
> - Collected tags
> - Link to v1:
> https://lore.kernel.org/linux-sunxi/20260227175157.2339758-1-wens@kernel.org/
>
> [...]
Applied to sunxi/dt-for-7.1 in local tree, thanks!
[1/3] spi: dt-bindings: sun6i: Allow Dual SPI and Quad SPI for newer SoCs
commit: e2f93f45d38f7b6dacb44203cfc7bb5d7e287b8e
[2/3] arm64: dts: allwinner: sun55i-a523: Add pinmux for spi0 on PJ pins
commit: 1a5ff6a0a8c2a0dc9f2d55039997c1cd928eb53c
[3/3] arm64: dts: allwinner: sun55i-t527: avaota-a1: Add SPI NAND
commit: 1b07332bf2ee816130e139a8966d312bf1aa32f9
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: SPI loopback tests
From: Mark Brown @ 2026-03-10 18:26 UTC (permalink / raw)
To: Conor Dooley
Cc: Francesco Dolcini, Rob Herring, Krzysztof Kozlowski, linux-spi,
devicetree, Max Krummenacher
In-Reply-To: <20260310-marlin-untoasted-ecca1e3e80e8@spud>
[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]
On Tue, Mar 10, 2026 at 06:12:38PM +0000, Conor Dooley wrote:
> On Tue, Mar 10, 2026 at 03:55:51PM +0000, Mark Brown wrote:
> > On Tue, Mar 10, 2026 at 02:32:54PM +0100, Francesco Dolcini wrote:
> > > I am aware that you all DT maintainers shared in a pretty clear way your
> > > view on the abuse of the spidev multiple times.
> > > What would you be your advice to handle the need of an SPI loopback
> > > test? Am I missing something and there is a solution already available?
> > I'm not aware of any idiomatic way to deal with this with DT
> > unfortunately. Perhaps the DT people have some ideas here?
> I dunno, the suggestion seems fairly reasonable to me. I don't think
> it's really abuse of anything, because the compatible would represent a
> real hardware configuration. The only think that feels "abusive" is the
> fake reg property you'd need.
In theory we should have a compatible specifically for loopback usage I
suppose. Depending on how the device does it's loopbacks there may
actually be a genuine reg (if there's a chip select that's still
selecting.
> Not sure that there should be a "linux," vendor prefix though, there's
> nothing linux-specific about doing loopback. Probably should be
> vendor-less?
I think at this point it's old enough that it's just ABI and adding the
option of having it vendorless would just cause people to ask why.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: SPI loopback tests
From: Conor Dooley @ 2026-03-10 18:12 UTC (permalink / raw)
To: Mark Brown
Cc: Francesco Dolcini, Rob Herring, Krzysztof Kozlowski, linux-spi,
devicetree, Max Krummenacher
In-Reply-To: <09f06ce4-0405-442b-bf3d-5722a6977a4d@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
On Tue, Mar 10, 2026 at 03:55:51PM +0000, Mark Brown wrote:
> On Tue, Mar 10, 2026 at 02:32:54PM +0100, Francesco Dolcini wrote:
>
> > So far to test this we had some out-of-tree DT overlay abusing the spidev
> > compatible, however we'd like to move away from this approach and have a
> > solution that is 100% in mainline.
>
> > Manually unbinding/binding the driver in userspace does not seems as an
> > option, because there is no device node.
>
> > One option that I could think of would be to add a new compatible that
> > to describe this single wire loopback connection (something like
> > `linux,spi-miso-mosi-loopback`) that would bind to the spidev driver.
>
> > I am aware that you all DT maintainers shared in a pretty clear way your
> > view on the abuse of the spidev multiple times.
>
> > What would you be your advice to handle the need of an SPI loopback
> > test? Am I missing something and there is a solution already available?
>
> I'm not aware of any idiomatic way to deal with this with DT
> unfortunately. Perhaps the DT people have some ideas here?
I dunno, the suggestion seems fairly reasonable to me. I don't think
it's really abuse of anything, because the compatible would represent a
real hardware configuration. The only think that feels "abusive" is the
fake reg property you'd need.
Not sure that there should be a "linux," vendor prefix though, there's
nothing linux-specific about doing loopback. Probably should be
vendor-less?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] spi: atcspi200: Use helper function devm_clk_get_enabled()
From: Mark Brown @ 2026-03-10 17:51 UTC (permalink / raw)
To: Pei Xiao; +Cc: cl634, linux-spi, linux-kernel
In-Reply-To: <9f6e31608a24f3cdbd6e1429c1e006ccf9f7d9c1.1773132237.git.xiaopei01@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
On Tue, Mar 10, 2026 at 04:53:02PM +0800, Pei Xiao wrote:
> - ret = atcspi_setup(spi);
> - if (ret)
> - goto disable_clk;
> + atcspi_setup(spi);
Previously we checked the return code here, now we ignore it?
> ret = devm_spi_register_controller(&pdev->dev, host);
> - if (ret) {
> + if (ret)
> dev_err_probe(spi->dev, ret,
> "Failed to register SPI controller\n");
> - goto disable_clk;
> - }
Similarly (and more seriously) here?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] spi: atcspi200: fix mutex initialization order
From: Mark Brown @ 2026-03-10 17:39 UTC (permalink / raw)
To: Pei Xiao; +Cc: cl634, linux-spi, linux-kernel
In-Reply-To: <09d5b199fa1f375b2fcdc3236ca9b2ee4a1fba77.1773136472.git.xiaopei01@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
On Tue, Mar 10, 2026 at 05:55:47PM +0800, Pei Xiao wrote:
> Move the mutex initialization to the beginning of the probe function,
> before any registration or resource allocation. Also replace the
> plain mutex_init() with devm_mutex_init() to benefit from automatic
> cleanup on driver unbind, preventing potential resource leaks.
> +++ b/drivers/spi/spi-atcspi200.c
> @@ -567,6 +567,10 @@ static int atcspi_probe(struct platform_device *pdev)
> spi->dev = &pdev->dev;
> dev_set_drvdata(&pdev->dev, host);
>
> + ret = devm_mutex_init(spi->dev, &spi->mutex_lock);
> + if (ret)
> + return ret;
> +
> ret = atcspi_init_resources(pdev, spi, &mem_res);
> if (ret)
> goto free_controller;
Shouldn't we be using free_controller if the mutex allocation fails too?
We'll leak the controller struct if that happens.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Patchwork summary for: spi-devel-general
From: patchwork-bot+spi-devel-general @ 2026-03-10 16:00 UTC (permalink / raw)
To: linux-spi, broonie
Hello:
The following patches were marked "accepted", because they were applied to
broonie/spi.git (for-next):
Patch: spi: cadence-qspi: Fix requesting of APB and AHB clocks on JH7110
Submitter: Mark Brown <broonie@kernel.org>
Committer: Mark Brown <broonie@kernel.org>
Patchwork: https://patchwork.kernel.org/project/spi-devel-general/list/?series=1063053
Lore link: https://lore.kernel.org/r/20260307-spi-cadence-qspi-fix-jh7110-v1-1-c9f37b8c58b1@kernel.org
Total patches: 1
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: SPI loopback tests
From: Mark Brown @ 2026-03-10 15:55 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-spi,
devicetree, Max Krummenacher
In-Reply-To: <20260310133254.GA51497@francesco-nb>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
On Tue, Mar 10, 2026 at 02:32:54PM +0100, Francesco Dolcini wrote:
> So far to test this we had some out-of-tree DT overlay abusing the spidev
> compatible, however we'd like to move away from this approach and have a
> solution that is 100% in mainline.
> Manually unbinding/binding the driver in userspace does not seems as an
> option, because there is no device node.
> One option that I could think of would be to add a new compatible that
> to describe this single wire loopback connection (something like
> `linux,spi-miso-mosi-loopback`) that would bind to the spidev driver.
> I am aware that you all DT maintainers shared in a pretty clear way your
> view on the abuse of the spidev multiple times.
> What would you be your advice to handle the need of an SPI loopback
> test? Am I missing something and there is a solution already available?
I'm not aware of any idiomatic way to deal with this with DT
unfortunately. Perhaps the DT people have some ideas here?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 02/28] driver core: Rename get_dev_from_fwnode() wrapper to get_device_from_fwnode()
From: Geert Uytterhoeven @ 2026-03-10 15:03 UTC (permalink / raw)
To: Herve Codina
Cc: Andrew Lunn, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kalle Niemi, Matti Vaittinen, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Michael Turquette,
Stephen Boyd, Andi Shyti, Wolfram Sang, Peter Rosin,
Arnd Bergmann, Saravana Kannan, Bjorn Helgaas, Charles Keepax,
Richard Fitzgerald, David Rhodes, Linus Walleij, Ulf Hansson,
Mark Brown, Len Brown, Andy Shevchenko, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Davidlohr Bueso, Jonathan Cameron,
Dave Jiang, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Shawn Guo, Wolfram Sang, linux-kernel, driver-core,
imx, linux-arm-kernel, linux-clk, linux-i2c, devicetree,
linux-pci, linux-sound, patches, linux-gpio, linux-pm, linux-spi,
linux-acpi, linux-cxl, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Luca Ceresoli, Thomas Petazzoni, Saravana Kannan,
Bartosz Golaszewski
In-Reply-To: <20260227135428.783983-3-herve.codina@bootlin.com>
Hi Hervé,
On Fri, 27 Feb 2026 at 14:55, Herve Codina <herve.codina@bootlin.com> wrote:
> get_dev_from_fwnode() calls get_device() and so it acquires a reference
> on the device returned.
>
> In order to be more obvious that this wrapper is a get_device() variant,
> rename it to get_device_from_fwnode().
>
> Suggested-by: Mark Brown <broonie@kernel.org>
> Link: https://lore.kernel.org/lkml/CAGETcx97QjnjVR8Z5g0ndLHpK96hLd4aYSV=iEkKPNbNOccYmA@mail.gmail.com/
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Saravana Kannan <saravanak@google.com>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
FTR, one more user of get_dev_from_fwnode() appeared in commit
9035073d0ef1de81 ("reset: convert reset core to using firmware nodes")
in reset/next.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] spi: cadence-qspi: Fix requesting of APB and AHB clocks on JH7110
From: Mark Brown @ 2026-03-10 14:32 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric), Mark Brown
Cc: Ron Economos, linux-spi, linux-kernel
In-Reply-To: <20260307-spi-cadence-qspi-fix-jh7110-v1-1-c9f37b8c58b1@kernel.org>
On Sat, 07 Mar 2026 09:50:35 +0000, Mark Brown wrote:
> spi: cadence-qspi: Fix requesting of APB and AHB clocks on JH7110
Applied to
local tree spi-7.0
Thanks!
[1/1] spi: cadence-qspi: Fix requesting of APB and AHB clocks on JH7110
commit: e53c0e99fd93da200c413deb57875f9f5fdb314a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH RFC 5/7] spi: Add RX sampling point adjustment
From: Frieder Schrempf @ 2026-03-10 14:19 UTC (permalink / raw)
To: Miquel Raynal, Frieder Schrempf
Cc: Mark Brown, Richard Weinberger, Vignesh Raghavendra, Han Xu,
Eberhard Stoll, Tudor Ambarus, Pratyush Yadav, Michael Walle,
linux-spi, linux-kernel, linux-mtd, imx, Santhosh Kumar K
In-Reply-To: <87fr69nhxs.fsf@bootlin.com>
On 09.03.26 16:25, Miquel Raynal wrote:
> Hello,
>
> + Santhosh
>
> On 03/03/2026 at 17:29:26 +01, Frieder Schrempf <frieder@fris.de> wrote:
>
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> Some SPI devices such as SPI NAND chips specify a clock-to-RX-sampling
>> delay constraint, which means that for the data read from the device
>> at a certain clock rate, we need to make sure that the point at
>> which the data is sampled is correct.
>>
>> The default is to assume that the data can be sampled one half clock
>> cycle after the triggering clock edge. For high clock rates, this
>> can be too early.
>>
>> To check this we introduce a new core function spi_set_rx_sampling_point()
>> and a handler set_rx_sampling_point() in the SPI controller.
>>
>> Controllers implementing set_rx_sampling_point() can calculate the
>> sampling point delay using the helper spi_calc_rx_sampling_point()
>> and store the value to set the appropriate registers during transfer.
>>
>> In case the controller capabilities are not sufficient to compensate
>> the RX delay, spi_set_rx_sampling_point() returns a reduced clock
>> rate value that is safe to use.
>>
>> This commit does not introduce generic logic for controllers that
>> don't implement set_rx_sampling_point() in order to reduce the clock
>> rate if the RX sampling delay requirement can not be met.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>> ---
>> drivers/spi/spi.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/spi/spi.h | 8 ++++++
>> 2 files changed, 81 insertions(+)
>>
>> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
>> index 61f7bde8c7fbb..b039007ed430f 100644
>> --- a/drivers/spi/spi.c
>> +++ b/drivers/spi/spi.c
>> @@ -3988,6 +3988,77 @@ static int spi_set_cs_timing(struct spi_device *spi)
>> return status;
>> }
>>
>> +/**
>> + * spi_calc_rx_sampling_point - calculate RX sampling delay cycles
>> + * @spi: the device that requires specific a RX sampling delay
>> + * @freq: pointer to the clock frequency setpoint for the calculation. This gets
>> + * altered to a reduced value if required.
>> + * @max_delay_cycles: the upper limit of supported delay cycles
>> + * @delay_cycles_per_clock_cycle: the ratio between delay cycles and
>> + * master clock cycles
>> + *
>> + * This function takes in the rx_sampling_delay_ns value from the SPI device
>> + * and the given clock frequency setpoint and calculates the required sampling
>> + * delay cycles to meet the device's spec. It uses the given controller
>> + * constraints and if those are exceeded, it adjusts the clock frequency
>> + * setpoint to a lower value that is safe to be used.
>> + *
>> + * Return: calculated number of delay cycles
>> + */
>> +unsigned int spi_calc_rx_sampling_point(struct spi_device *spi, unsigned int *freq,
>> + u16 max_delay_cycles,
>> + u16 delay_cycles_per_clock_cycle)
>> +{
>> + unsigned long long temp;
>> + u16 delay_cycles;
>> +
>> + /* if sampling delay is zero, we assume the default sampling point can be used */
>> + if (!spi->rx_sampling_delay_ns)
>> + return 0;
>> +
>> + temp = *freq * delay_cycles_per_clock_cycle * spi->rx_sampling_delay_ns;
>> + do_div(temp, 1000000000UL);
>> + delay_cycles = temp;
>> +
>> + if (delay_cycles > max_delay_cycles) {
>> + /*
>> + * Reduce the clock to the point where the sampling delay requirement
>> + * can be met.
>> + */
>> + delay_cycles = max_delay_cycles;
>> + temp = (1000000000UL * delay_cycles);
>> + do_div(temp, spi->rx_sampling_delay_ns * delay_cycles_per_clock_cycle);
>> + *freq = temp;
>
> This is silently modifying the spi_device structure, I don't like this much.
Right, I agree. I think we will likely need some struct type to hold the
frequency and sampling delay values anyway. So maybe this function could
then return a value of such type.
>
>> + }
>> +
>> + dev_dbg(&spi->controller->dev, "calculated RX sampling point delay: %u cycle(s) at %lu KHz", delay_cycles, *freq / 1000);
>> +
>> + return delay_cycles;
>> +}
>> +EXPORT_SYMBOL_GPL(spi_calc_rx_sampling_point);
>> +
>> +/**
>> + * spi_set_rx_sampling_point - set the RX sampling delay in the controller driver
>> + * @spi: the device that requires specific a RX sampling delay
>> + * @freq: the clock frequency setpoint for the RX sampling delay calculation
>> + *
>> + * This function calls the set_rx_sampling_point() handle in the controller
>> + * driver it is available. This makes sure that the controller uses the proper
>> + * RX sampling point adjustment. This function should be called whenever
>> + * the devices rx_sampling_delay_ns or the currently used clock frequency
>> + * changes.
>> + *
>> + * Return: adjusted clock frequency
>> + */
>> +unsigned int spi_set_rx_sampling_point(struct spi_device *spi, unsigned int freq)
>> +{
>> + if (spi->controller->set_rx_sampling_point)
>> + return spi->controller->set_rx_sampling_point(spi, spi->max_speed_hz);
>> +
>> + return freq;
>> +}
>> +EXPORT_SYMBOL_GPL(spi_set_rx_sampling_point);
>> +
>> /**
>> * spi_setup - setup SPI mode and clock rate
>> * @spi: the device whose settings are being modified
>> @@ -4090,6 +4161,8 @@ int spi_setup(struct spi_device *spi)
>> }
>> }
>>
>> + spi->max_speed_hz = spi_set_rx_sampling_point(spi, spi->max_speed_hz);
>
> I believe we need a clearer yet stronger logic around the setting of
> max_speed_hz.
>
> The "maximum speed" parameter is reaching its limit. This is clearly
> what needs to be discussed with Santhosh. The SPI tuning series is
> playing with this value as well.
I agree. I'm still missing parts of the bigger picture here, so I'm
currently not really sure how this might look like. But I'm open to any
discussions and suggestions.
^ permalink raw reply
* Re: [PATCH RFC 4/7] mtd: spinand: toshiba: Add RX sampling delay values
From: Frieder Schrempf @ 2026-03-10 14:17 UTC (permalink / raw)
To: Miquel Raynal, Frieder Schrempf
Cc: Mark Brown, Richard Weinberger, Vignesh Raghavendra, Han Xu,
Eberhard Stoll, Tudor Ambarus, Pratyush Yadav, Michael Walle,
linux-spi, linux-kernel, linux-mtd, imx
In-Reply-To: <87ldg1nij3.fsf@bootlin.com>
On 09.03.26 16:12, Miquel Raynal wrote:
>
>> @@ -277,7 +291,7 @@ static const struct spinand_info toshiba_spinand_table[] = {
>> &update_cache_variants),
>> 0,
>> SPINAND_ECCINFO(&tx58cxgxsxraix_ooblayout,
>> - tx58cxgxsxraix_ecc_get_status)),
>> + tx58cxgxsxraix_ecc_get_status),
>> /* 1.8V 4Gb (1st generation) */
>> SPINAND_INFO("TH58NYG2S3HBAI4",
>> SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xAC),
>> @@ -288,7 +302,7 @@ static const struct spinand_info toshiba_spinand_table[] = {
>> &update_cache_x4_variants),
>> SPINAND_HAS_QE_BIT,
>> SPINAND_ECCINFO(&tx58cxgxsxraix_ooblayout,
>> - tx58cxgxsxraix_ecc_get_status)),
>> + tx58cxgxsxraix_ecc_get_status),
>> /* 1.8V 8Gb (1st generation) */
>> SPINAND_INFO("TH58NYG3S0HBAI6",
>> SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xA3),
>> @@ -299,7 +313,7 @@ static const struct spinand_info toshiba_spinand_table[] = {
>> &update_cache_x4_variants),
>> SPINAND_HAS_QE_BIT,
>> SPINAND_ECCINFO(&tx58cxgxsxraix_ooblayout,
>> - tx58cxgxsxraix_ecc_get_status)),
>> + tx58cxgxsxraix_ecc_get_status),
>> };
>
> Are these 3 changes legitimate?
No, they are not. This is a last-minute fixup gone wrong.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox