| Message ID | 20250514-b4-upstream_ospi_reset_update-v5-1-7b5de0552c8c@foss.st.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v5] spi: stm32-ospi: Make usage of reset_control_acquire/release() API | expand |
On Wed, May 14, 2025 at 03:56:01PM +0200, Patrice Chotard wrote: > This patch is dependent on commit 6b3754009f87 > ("reset: Add devm_reset_control_array_get_exclusive_released()") > available on tag reset-for-v6.16. When telling people about dependencies like this the standard thing is to also specify the repostiory, or link to a pull request. The git repository is needed to actually pull the tag. This appears to be the PR at: https://lore.kernel.org/all/20250513092516.3331585-1-p.zabel@pengutronix.de/ which is the full reset pull request for v6.16. The commit you referenced isn't the tagged commit, it's further back in the history but still has a whole new reset driver backed up behind it. I'd have expected that if this was expected to be pulled into other subsystems it'd be on a topic branch and directly tagged?
On 5/15/25 11:19, Mark Brown wrote: > On Wed, May 14, 2025 at 03:56:01PM +0200, Patrice Chotard wrote: > >> This patch is dependent on commit 6b3754009f87 >> ("reset: Add devm_reset_control_array_get_exclusive_released()") >> available on tag reset-for-v6.16. > > When telling people about dependencies like this the standard thing is > to also specify the repostiory, or link to a pull request. The git > repository is needed to actually pull the tag. This appears to be the > PR at: > > https://lore.kernel.org/all/20250513092516.3331585-1-p.zabel@pengutronix.de/ > > which is the full reset pull request for v6.16. The commit you > referenced isn't the tagged commit, it's further back in the history > but still has a whole new reset driver backed up behind it. I'd have > expected that if this was expected to be pulled into other subsystems > it'd be on a topic branch and directly tagged? Hi Mark Sorry for that, how do you want me to proceed ? Thanks Patrice
diff --git a/drivers/spi/spi-stm32-ospi.c b/drivers/spi/spi-stm32-ospi.c index 668022098b1eac3628f0677e6d786e5a267346be..b2597b52beb1133155e0d6f601b0632ad4b8e8f5 100644 --- a/drivers/spi/spi-stm32-ospi.c +++ b/drivers/spi/spi-stm32-ospi.c @@ -804,7 +804,7 @@ static int stm32_ospi_get_resources(struct platform_device *pdev) return ret; } - ospi->rstc = devm_reset_control_array_get_optional_exclusive(dev); + ospi->rstc = devm_reset_control_array_get_exclusive_released(dev); if (IS_ERR(ospi->rstc)) return dev_err_probe(dev, PTR_ERR(ospi->rstc), "Can't get reset\n"); @@ -936,11 +936,13 @@ static int stm32_ospi_probe(struct platform_device *pdev) if (ret < 0) goto err_pm_enable; - if (ospi->rstc) { - reset_control_assert(ospi->rstc); - udelay(2); - reset_control_deassert(ospi->rstc); - } + ret = reset_control_acquire(ospi->rstc); + if (ret) + return dev_err_probe(dev, ret, "Can not acquire reset %d\n", ret); + + reset_control_assert(ospi->rstc); + udelay(2); + reset_control_deassert(ospi->rstc); ret = spi_register_controller(ctrl); if (ret) { @@ -983,6 +985,8 @@ static void stm32_ospi_remove(struct platform_device *pdev) if (ospi->dma_chrx) dma_release_channel(ospi->dma_chrx); + reset_control_release(ospi->rstc); + pm_runtime_put_sync_suspend(ospi->dev); pm_runtime_force_suspend(ospi->dev); } @@ -993,6 +997,8 @@ static int __maybe_unused stm32_ospi_suspend(struct device *dev) pinctrl_pm_select_sleep_state(dev); + reset_control_release(ospi->rstc); + return pm_runtime_force_suspend(ospi->dev); } @@ -1012,6 +1018,12 @@ static int __maybe_unused stm32_ospi_resume(struct device *dev) if (ret < 0) return ret; + ret = reset_control_acquire(ospi->rstc); + if (ret) { + dev_err(dev, "Can not acquire reset\n"); + return ret; + } + writel_relaxed(ospi->cr_reg, regs_base + OSPI_CR); writel_relaxed(ospi->dcr_reg, regs_base + OSPI_DCR1); pm_runtime_mark_last_busy(ospi->dev);
As ospi reset is consumed by both OMM and OSPI drivers, use the reset acquire/release mechanism which ensure exclusive reset usage. This avoid to call reset_control_get/put() in OMM driver each time we need to reset OSPI children and guarantee the reset line stays deasserted. During resume, OMM driver takes temporarily control of reset. This patch is dependent on commit 6b3754009f87 ("reset: Add devm_reset_control_array_get_exclusive_released()") available on tag reset-for-v6.16. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> --- Changes in v5: - Add dependency with commit 6b3754009f87 ("reset: Add devm_reset_control_array_get_exclusive_released()") in commit message. - Link to v4: https://lore.kernel.org/r/20250512-b4-upstream_ospi_reset_update-v4-1-982c6f7886ef@foss.st.com Changes in v4: - Add a comment about reset sharing between OSPI and OMM drivers durig resume. - Link to v3: https://lore.kernel.org/r/20250507-b4-upstream_ospi_reset_update-v3-1-7e46a8797572@foss.st.com Changes in v3: - Remove previous patch 1/2 as already merged. - Keep the reset control acquired from probe() to remove(). - Link to v2: https://lore.kernel.org/r/20250411-b4-upstream_ospi_reset_update-v2-0-4de7f5dd2a91@foss.st.com Changes in v2: - Rebased on spi/for-next (7a978d8fcf57). - Remove useless check on reset. - Add error handling on reset_control_acquire(). - Link to v1: https://lore.kernel.org/all/20250410-b4-upstream_ospi_reset_update-v1-0-74126a8ceb9c@foss.st.com/ --- drivers/spi/spi-stm32-ospi.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) --- base-commit: 1c64de886b8893c0158097edd6ba08d527a2c97a change-id: 20250411-b4-upstream_ospi_reset_update-596ce245ada1 Best regards,