driver/mtd: ramtron multi-device spi bus support

[stbenn]

Adds a device ID to ramtron_initialize, which is stored in the ramtron_dev_s structure. This ID is used when calling SPI_SELECT to board specific logic to allow chip select on the SPI bus.

This change is NOT backwards compatible, as it changes the function signature of ramtron_initialize.

This implementation is based on the handling of chip select in nuttx/drivers/mtd/sst26.c:sst26_initialize_spi().

Additional Changes:

• Add MB85RS64V to ramtron supported parts list.

Additional contributors: @ArrestedLightning

Note: Please adhere to Contributing Guidelines.

Summary

This change makes the ramtron driver compatible with boards that have more than one memory device per SPI peripheral. Its implementation is based on other mtd drivers such as sst26.c.

Before this change the ramtron driver exclusively called SPIDEV_FLASH(0). With this change, the SPI device ID is provided during initialization and used with SPIDEV_FLASH calls in the driver. This allows control over chip select in board specific code.

Impact

This change breaks backwards compatibility: it changes the function signature of ramtron_initialize from ramtron_initialize(FAR struct spi_dev_s *) to ramtron_initialize(FAR struct spi_dev_s *, uint16_t).

Testing

Target used for testing is a custom board:

• CPU: STM32H753BIT6
• FRAM and FLASH on SPI4
  • FRAM chip: MB85RS256B
  • FLASH chip: MX25L25645G

Build Host:

• Ubuntu 24.04
• Arm GNU Toolchain 13.3.rel1 x86_64 arm-none-eabi

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR mostly meets the requirements, but needs minor improvements.

Strengths:

• Clearly explains the "why" and "how" of the change.
• Provides context by referencing similar implementations (sst26.c).
• Explicitly acknowledges the backwards compatibility break.
• Lists target and host details for testing.

Areas for improvement:

• Testing Logs: The template requests "Testing logs before change" and "Testing logs after change". Even simple logs demonstrating basic functionality before and after the change would significantly improve the PR. Examples: output showing successful initialization, data read/write operations, etc.
• Impact - Documentation: Since ramtron_initialize's signature changed, the documentation MUST be updated. The PR description should state this explicitly (YES) and ideally, the documentation changes should be included in the PR itself.
• Impact - Hardware: While the target is specified, be more explicit about which hardware is impacted. "Custom board" isn't sufficient. Mention the specific board name or, if none exists, provide more details about its SPI configuration. The description already mentions STM32H753BIT6 which is good; consider adding explicit mention of SPI4.
• Summary (conciseness): The first summary section is a bit too detailed for a summary. Keep it shorter and higher level; the details are already present in the rest of the description. For instance, "Adds a device ID parameter to ramtron_initialize for multi-device SPI bus support, breaking backwards compatibility." would suffice.
• Related Issues: If there's a related issue, link it. Even if this change isn't directly tied to an open issue, consider creating one to track the backwards compatibility break.

By addressing these points, the PR will be even stronger and easier for reviewers to assess.

[stbenn]

If breaking backwards compatibility with the initialization is not acceptable, it could be broken into two functions. FAR struct mtd_dev_s ramtron_initialize(FAR struct spi_dev_s *dev) (same as before) and FAR struct mtd_dev_s ramtron_initialize_devid(FAR struct spi_dev_s *dev, uint16_t spi_devid).

The backwards compatible function would just call the new one with spi_devid = 0

[stbenn]

I made the requested text alignment change.