plat-stm32mp1: bumping to pinctrl framework

[etienne-lms]

Bump stm32_gpio driver to recently merged pinctrl device driver probing support.

For STM32MP13 variant to comply with pinctrl support (and not panic on driver probe errors), I needed to update STM32MP13 DTS and DTSI file and 2 stm32 drivers (stm32_etzpc and stm32_rstctrl). They are part of this series.

A patch fixing a pinctrl driver probe function in under review at #6081.

[etienne-lms]

This series it too long. I'll shorten it and rebase it.

[etienne-lms]

I've kept only the 5 first commits initially posted (15 patches) in the P-R, the one that introduce PINCTRL support in stm32_gpio.c, leaving out activation of CFG_DRIVERS_PINCTRL on plat-stm32mp1 as there are few other platform resources to update.

Some of these platform updates are proposed to review in P-R #6091.

[etienne-lms]

for info, CI checkpatch error reports are false positives (build error trace messages dumped in commit messages).

[etienne-lms]

review comments addressed

[etienne-lms]

may I squash the fixup commits?

[GseoC]

may I squash the fixup commits?

For clearer view, yes please

[etienne-lms]

Fixup commits squashed + addressed comment on stm32mp_register_secure_pinctrl()/stm32mp_register_non_secure_pinctrl().

[GseoC]

Thank you,

Acked-by: Gatien Chevallier <gatien.chevallier@foss.st.com>

[etienne-lms]

tag applied
thanks

[etienne-lms]

I need to rebase due to #6098 being recently merged.

[etienne-lms]

@GseoC, I added a fixup commit to "drivers: stm32_gpio: support CFG_DRIVERS_PINCTRL", to address the rebase issue.
Could you please confirm (or infirm) your A-b tag with this change?

[jforissier]

I have restarted IBART which failed on a socket test (rcu_sched stalls), looks unrelated to this PR.

[etienne-lms]

thanks

[GseoC]

Seems fine, tag applies

[etienne-lms]

Some changes in the series, to finalize bumping stm32_gpio.c to GPIO and PINCTRL frameworks:

• 1st commit is unmodified regarding previous review. @GseoC review tag is already applied to the commit.
  "drivers: stm32_gpio: support CFG_DRIVERS_PINCTRL"

• The 5 next commit were review but I changed added functions prototypes to return void instead of a useless TEE_Result. @GseoC, I removed your review tag from those commits:
  "drivers: stm32_gpio: add helper function stm32_gpio_pinctrl_bank_pin()"
  "drivers: stm32_gpio: add helper function stm32_pinctrl_set_secure_cfg()"
  "plat-stm32mp1: shared_resources: support CFG_DRIVERS_PINCTRL"
  "drivers: stm32_uart: support CFG_DRIVERS_PINCTRL"
  "drivers: stm32_i2c: support CFG_DRIVERS_PINCTRL"

• I added 5 new commits in the series, to finalize the evolution: enforce CFG_DRIVERS_PINCTRL=y and remove deprecated functions:
  "plat-stm32mp1: conf: enable CFG_DRIVERS_PINCTRL"
  "drivers: stm32_gpio: remove cases when CFG_DRIVERS_PINCTRL is disabled"
  "drivers: stm32_uart: remove cases when CFG_DRIVERS_PINCTRL is disabled"
  "drivers: stm32_i2c: remove cases when CFG_DRIVERS_PINCTRL is disabled"
  "drivers: stm32_gpio: move definitions to source file"

[etienne-lms]

Changed title has the seire finalizes stm32mp1 upgrades to pinctrl framework.
Checkpatch failure on a typo in a commit. I'll the 2 fixed after the review.

[GseoC]

Maybe add a message as we may think we secure a pin that will not be secure?

[etienne-lms]

if there is no pinctrl, there is no pin to configure so returning straight is fine, IMO.

[GseoC]

I do not catch why the code style check fails, I guess it did not restart

Acked-by: Gatien Chevallier <gatien.chevallier@foss.st.com>

[jforissier]

I do not catch why the code style check fails, I guess it did not restart

It did, but the way the code style check works might be a bit counter-intuitive 😉 It is actually run twice:

• once for each commit in the PR, and
• once on the global diff (all commits squashed together if you wish)

The rationale is, we want to check the code but also the commit descriptions, so each commit is checked (the checkpatch lines in the log). When fixes are done as fixup commits (as opposed to force-pushing with corrected commits), the initial failure remain visible. However thanks to the second phase (called checkdiff in the log), you can be confident that the code style issues will be gone when squashing the fixups.

[GseoC]

I do not catch why the code style check fails, I guess it did not restart

It did, but the way the code style check works might be a bit counter-intuitive wink It is actually run twice:

• once for each commit in the PR, and
• once on the global diff (all commits squashed together if you wish)

The rationale is, we want to check the code but also the commit descriptions, so each commit is checked (the checkpatch lines in the log). When fixes are done as fixup commits (as opposed to force-pushing with corrected commits), the initial failure remain visible. However thanks to the second phase (called checkdiff in the log), you can be confident that the code style issues will be gone when squashing the fixups.

Thanks for the explanation :)

[etienne-lms]

I'll sqaush the fixup commits. Once done, checkpatch should be happy.

[etienne-lms]

Thakns for the review.
Fixup commits squashed.
Review tag applied.

I also removed a suprious inline comment in comment "drivers: stm32_i2c: remove cases when CFG_DRIVERS_PINCTRL is disabled" (below). @GseoC, I preserved your review tag on that commit, I think it still applies :)

@@ -113,7 +113,6 @@ struct i2c_cfg {
  * @sec_cfg: I2C registers configuration storage
  * @pinctrl: Pin control configuration for the I2C bus in active state
  * @pinctrl_sleep: Pin control configuration for the I2C bus in standby state
- * @pinctrl_count: Number of PINCTRLs elements
  */
 struct i2c_handle_s {
        struct io_pa_va base;

[github-actions]

This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.