drivers: memc: stm32_xspi_psram: Add conditional HAL API support

[Ayushkothari96]

Fixes #99191

Add conditional compilation to support different STM32 XSPI HAL capabilities across product lines.

Related PRs:

• Depends on: hal_stm32: stm32h5: Add XSPI1 compatibility macros hal_stm32#328

Problem:
After adding XSPI1 compatibility macros (hal_stm32#328), the XSPI PSRAM driver still had STM32H5-incompatible code that assumed all STM32 XSPI peripherals have the same features (XSPI Manager, 16-line data mode, MaxTran/MemorySelect fields).

Solution:

• Use XSPIM (XSPI Manager) configuration only when xspi_mgr clock exists (STM32H7RS)
• Use 16-line data mode when HAL_XSPI_DATA_16_LINES is defined (STM32H7RS), otherwise 8-line (STM32H5)
• Include MaxTran and MemorySelect Init fields only when XSPIM exists

Benefits:

• STM32H7RS: Uses full hardware capabilities (16-line XSPI with dual-port manager)
• STM32H5 (H573): Works with simpler single-port XSPI/OCTOSPI implementation (8-line max)
• Automatic adaptation based on devicetree and HAL feature detection

Testing:

• Verified compilation on STM32H573I-DK with XSPI PSRAM driver enabled
• Driver object file successfully created: memc_stm32_xspi_psram.c.obj
• No code changes needed when switching between STM32 variants

[github-actions]

Hello @Ayushkothari96, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[JarmouniA]

Already addressed by #99194

[erwango]

Thanks but a similar PR was already opended last week: #99194
Would you mind have a look at this one first ?

[mathieuchopstm]

Use more generic wording:

Suggested change

	#else
	/* STM32H5 max is 8 lines */
	cmd.DataMode = HAL_XSPI_DATA_8_LINES;
	#endif
	#else /* 16 lines mode not supported */
	cmd.DataMode = HAL_XSPI_DATA_8_LINES;
	#endif

[mathieuchopstm]

Suggested change

	/* Use 16-line if DT requests and hardware supports it */
	/* Use 16 lines mode if DT requests and hardware supports it */

[mathieuchopstm]

Why move this?

[mathieuchopstm]

Suggested change

	#endif
	#endif /* DT_CLOCKS_HAS_NAME(STM32_XSPI_NODE, xspi_mgr) */

[mathieuchopstm]

Regroup both under same check:

			.Refresh = 0x81U,
#if DT_CLOCKS_HAS_NAME(STM32_XSPI_NODE, xspi_mgr)
			.MaxTran = 0U,  /* Communication regulation (STM32H7RS only) */
			.MemorySelect = HAL_XSPI_CSSEL_NCS1,  /* Chip select (STM32H7RS only) */
#endif

+ if series-specific, it should be under #if SOC_SERIES - either change condition or comment

[Ayushkothari96]

Thanks but a similar PR was already opended last week: #99194 Would you mind have a look at this one first ?

Hello @erwango
Thanks for the heads-up on PR #99194. I've reviewed it - both fix the compilation, but they differ fundamentally:

PR #99194: Adds #ifdef guards in the driver using HAL macro detection

My PR: Fixes the root cause by adding XSPI1→OCTOSPI1 compatibility macros in hal_stm32 (PR #328) + uses DT-based detection (DT_CLOCKS_HAS_NAME)
I can add the build test from #99194 if that would help, but the fundamental approach here prevents this issue ecosystem-wide rather than patching one driver

[erwango]

My PR: Fixes the root cause by adding XSPI1→OCTOSPI1 compatibility macros in hal_stm32 (PR #328) + uses DT-based detection (DT_CLOCKS_HAS_NAME)

While I agree it seems cleaner, I prefer the other one. Indeed we avoid patching the HAL to stay closer to upstream and avoid maintaining downstream patches. Unless ... the patch you propose could be accepted in https://github.com/STMicroelectronics/STM32CubeH5

[Ayushkothari96]

My PR: Fixes the root cause by adding XSPI1→OCTOSPI1 compatibility macros in hal_stm32 (PR #328) + uses DT-based detection (DT_CLOCKS_HAS_NAME)

While I agree it seems cleaner, I prefer the other one. Indeed we avoid patching the HAL to stay closer to upstream and avoid maintaining downstream patches. Unless ... the patch you propose could be accepted in https://github.com/STMicroelectronics/STM32CubeH5

Fair point about staying clos to upstream. However, stm32_hal_legacy.h exists specifically for these compatibility cases, it has already contains similar macros for other STM32 series.
Anyways would you want me to wait for upstream STM32CubeH5 acceptance before proceeding?

[erwango]

it has already contains similar macros for other STM32 series.

Agreed, but it remains upstream code nonetheless.

Anyways would you want me to wait for upstream STM32CubeH5 acceptance before proceeding?

Yes. But note that it can take some time before getting a response, so I propose we don't block #99194 and get back to it if your proposal is accepted.

[Ayushkothari96]

it has already contains similar macros for other STM32 series.

Agreed, but it remains upstream code nonetheless.

Anyways would you want me to wait for upstream STM32CubeH5 acceptance before proceeding?

Yes. But note that it can take some time before getting a response, so I propose we don't block #99194 and get back to it if your proposal is accepted.

Understood, I'll propose the compatibility macros to STMicroelectronics/STM32CubeH5 and can revisit this approach if they accept it. In the meantime, I'm fine with proceeding with #99194 to unblock users. Thanks for the feedback.