Add SDHC common driver by yangbolu1991 · Pull Request #114752 · zephyrproject-rtos/zephyr

yangbolu1991 · 2026-07-28T08:17:31Z

This PR added sdhc common driver and sdhc standard controller driver.
And converted imx_usdhc to use them.

sdhc common driver

Added sdhc_common driver. For now, it provided only one
common API, for SDHC device tree properties initialization.

Vendor drivers can convert to use sdhc_common_config and
sdhc_common_dt_props_init API.

sdhc standard controller driver

Added standard controller driver per SD Specifications Part A2
SD Host Controller Simplified Specification (Version 3.00).

For now, the driver provided standard registers definition and
access APIs, also provided a sdhc_standard_capabilites_init API
for host capabilities initialization.

The host controller driver needs to initialize a sdhc_standard_host
structure variable, then it can reuse the standard controller
driver APIs.

Thanks.

maass-hamburg · 2026-07-28T11:01:35Z

+int sdhc_host_props_init(struct sdhc_host_props *props, const struct sdhc_config *cfg)
+{
+	props->max_current_330 = cfg->max_current_330;
+	props->max_current_300 = cfg->max_current_300;
+	props->max_current_180 = cfg->max_current_180;
+
+	return 0;
+}


this function should be a inline function, it only copies 3 vars

For now, it is...
Let me implement full support for sdhc properties defined in binding file. Introducing some debug messages are better. And in the future I think this function will handle more things.

maass-hamburg · 2026-07-28T11:03:57Z

-# Copyright 2022 NXP
+# SPDX-FileCopyrightText: Copyright 2022, 2026 NXP
 # SPDX-License-Identifier: Apache-2.0
 if(CONFIG_SDHC)


instead remove this, it is not needed, as this cmakefile is already only conditionally included:

zephyr/drivers/CMakeLists.txt

Line 89 in bf3339d

add_subdirectory_ifdef(CONFIG_SDHC sdhc)

Thanks. Will do that.

yangbolu1991 · 2026-07-29T03:44:01Z

Updated to v2. Changes include,

Improved CMakefile per @maass-hamburg comment.
Added full sdhc properties handling defined in sdhc binding file.

Thanks.

yangbolu1991 · 2026-08-03T02:16:31Z

@danieldegrasse Could you help to review when you get any chance?
Thanks a lot:)

danieldegrasse

I agree that we should consider a common SDHC driver- when I initially proposed this subsystem I felt it did not make sense, but so many vendors either reuse IP from Synopsis or Cadence or follow the SD Host Controller Spec (A2) pretty closely that I do think a common driver is reasonable.

That being said, I think this driver needs a bit more logic in order to move forwards. At a minimum lets target implementing a shared "transfer" function that uses the registers in the SD host controller specification.

I'd like to have an architecture where the SD subsystem implements a common SDHC driver, with public functions that other drivers can utilize. This way IP blocks that are partially compliant can use the common functions where possible, and write their own for other cases. Similar to the can_mcan.c driver in the CAN subsystem

erwango · 2026-08-12T07:38:25Z

+    property-blocklist:
+      - bus-width


I'm not following here. Why not just removing bus-width prop from the list props below ?

I didn't remove the property in this file, because it had different default value with in sdhc.yaml.
Keeping it here can ensure native/out-of-tree platforms not affected.
Thanks.

mathieuchopstm

There seems to be confusion between:

hardware-independent operations implemented similarly/identically across drivers
hardware implementations complying with the SD Host Controller Simplified Specification (SD Specifications Part A2)

The former can be refactored into a common implementation (as done in ADC and other subsystems); the latter can be covered by a unique driver, potentially layered like the Bosch M-CAN driver as pointed out by @danieldegrasse.

But the two concepts are orthogonal so I'm not sure I understand what this PR is trying to do, because it seems to conflate the two? Clearly, it is not reasonable to force SDHC-Specification-compliant-controller-only fields in the common API/structures: this should be opt-in for the drivers which are interested.

Vendor SDHC hosts were actually designed per common specification. There may be specific implementation in hardware but most should be compatible.

The SD Host Controller Simplified Specification is not binding:

The Secure Digital (SD) Host Standard Specification is the SD Association's (SDA) guideline for designing SD Host Controllers and related vendor products.
Within the scope of the SD Associations adherence to this specification is not mandatory.

From a rough look at tree, I'm estimating ~50% of IPs covered by existing drivers do not comply with the specification; the claim that "most hardware complies" doesn't seem accurate.

mathieuchopstm · 2026-08-12T11:16:50Z

-	unsigned int adma3_support: 1;			/**< ADMA3 support */
-	unsigned int vdd2_180_support: 1;		/**< 1.8V VDD2 support */
-	unsigned int _rsvd_61: 3;			/**< Reserved */
+	uint64_t timeout_clk_freq: 6;			/**< Timeout clock frequency */


As pointed out by SonarCloud: bitfields must have type int, signed int or (in this case) unsigned int (support for other types is implementation-defined).

Will drop the changes.
Thanks.

yangbolu1991 · 2026-08-13T11:39:40Z

There seems to be confusion between:
* hardware-independent operations implemented similarly/identically across drivers

* hardware implementations complying with the _SD Host Controller Simplified Specification_ (SD Specifications Part A2)
The former can be refactored into a common implementation (as done in ADC and other subsystems); the latter can be covered by a unique driver, potentially layered like the Bosch M-CAN driver as pointed out by @danieldegrasse.

But the two concepts are orthogonal so I'm not sure I understand what this PR is trying to do, because it seems to conflate the two? Clearly, it is not reasonable to force SDHC-Specification-compliant-controller-only fields in the common API/structures: this should be opt-in for the drivers which are interested.

Vendor SDHC hosts were actually designed per common specification. There may be specific implementation in hardware but most should be compatible.

The SD Host Controller Simplified Specification is not binding:

The Secure Digital (SD) Host Standard Specification is the SD Association's (SDA) guideline for designing SD Host Controllers and related vendor products.
Within the scope of the SD Associations adherence to this specification is not mandatory.

From a rough look at tree, I'm estimating ~50% of IPs covered by existing drivers do not comply with the specification; the claim that "most hardware complies" doesn't seem accurate.

You're right. I initially didn't realize adherence to this specification is not mandatory. Going to the drivers, only the below are compatible with spec.

drivers/sdhc/imx_usdhc.c
drivers/sdhc/xlnx_sdhc.c
drivers/sdhc/sdhc_ti_am654.c
drivers/sdhc/sdhc_mchp_g1.c
drivers/sdhc/sdhc_max32.c
drivers/sdhc/sdhc_infineon.c
drivers/sdhc/sdhc_bflb.c
drivers/sdhc/sdhc_ambiq.c
drivers/sdhc/sam_sdmmc.c
drivers/sdhc/intel_emmc_host.c

Then we may need a sdhc_common driver for common APIs, and a sdhc_standard driver for standard controller APIs.
Both should be in drivers/sdhc/ as private.
Let me update PR to review.

Thank you very much.

yangbolu1991 · 2026-08-13T11:47:00Z

Updated to v4. Changes include,

Split changes into sdhc_common driver and sdhc_standard driver under drivers/sdhc/
left out default: for bus-width in common sdhc.yaml.
Some other improvement per @mathieuchopstm

Thanks a lot.

sonarqubecloud · 2026-08-13T12:22:23Z

Quality Gate passed

Issues
6 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

mathieuchopstm

Seems like a much better direction 🙂

mathieuchopstm · 2026-08-13T12:43:52Z

FWIW, this could remain as just:

power-delay-ms: required: true

Not mandatory - removal is fine too.

Thanks, let's remove it.
Because for required property, it should not have default value in common yaml.

mathieuchopstm · 2026-08-13T12:47:12Z

+  bus-width:
+    type: int
+    description: |
+      SDHC data bus width.


Nit: SDHC data bus width (in bits).

Thanks, will update.

mathieuchopstm · 2026-08-13T12:49:35Z

In commit titled drivers: sdhc: add common driver: prefer "common code" to "driver" since this is not directly related to actual hardware

Thanks, will rephrase.

mathieuchopstm · 2026-08-13T12:52:26Z

+ * Version 3.00
+ * @{
+ */
+#define SDHC_REG_SDMA_SYS_ADDR_ARG2     0x000 /**< SDMA System Address / Argument 2 Register */


Nit: indicating register sizes would be nice

e.g.:

/**< SDMA System Address / Argument 2 Register (u32) */

Thanks. Will add that.

mathieuchopstm · 2026-08-13T13:02:47Z

 	help
 	  Enable SDHC scatter-gather API.

+config SDHC_STANDARD


SDHC_STANDARD_CORE

Thanks, will update.

mathieuchopstm · 2026-08-13T13:08:00Z

+#define SDHC_REG_CAPABILITIES_CM_MASK      (0xffULL << 48)
+#define SDHC_REG_CAPABILITIES_CM_SHIFT     48
+/** @} */
+


It is probably wiser to define:

struct sdhc_standard_host_common_config { struct sdhc_common_config subsys_common; DEVICE_MMIO_NAMED(xxx); };

which would replace the sdhc_common_config for spec-compliant controllers. These functions would then consume the usual const struct device *.

As I understand, DEVICE_MMIO_NAMED_ROM() must be put in dev->config, nesting will not be workable.
So, will keep struct sdhc_standard_host for vendor drivers to use.
Vendor driver initialize it like registering itself as standard host.

Thanks.

mathieuchopstm · 2026-08-13T13:09:49Z

sdhc_standard.c -> sdhc_standard_core.c; ditto for .h file

Thanks, will update.

mathieuchopstm · 2026-08-13T13:10:15Z

+uint32_t sdhc_standard_read32(struct sdhc_standard_host *host, uint32_t reg);
+void sdhc_standard_write32(struct sdhc_standard_host *host, uint32_t reg, uint32_t value);
+uint64_t sdhc_standard_read64(struct sdhc_standard_host *host, uint32_t reg);
+void sdhc_standard_write64(struct sdhc_standard_host *host, uint32_t reg, uint64_t value);


Since that's intended to be called by the core itself, these should be kept private. But I think this is overkill, see comment in iMX driver.

In vendor drivers, they may have registers accessing for specific process.
Then they can reuse IO access functions and registers definition.

Without these APIs exported, vendor drivers also could implement that (maybe efficient or redundant).
But exporting them provides an available way to choose.

My thought is from Linux :)
https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci.h#L731
Thanks.

mathieuchopstm · 2026-08-13T13:21:11Z

+ * - imx_usdhc_reg32_read
+ * - imx_usdhc_reg32_write
+ */
+static uint64_t imx_usdhc_reg32_read(const struct device *dev, uint32_t reg, uint8_t reg_bytes)


This code is overall pretty generic. I think it should be in the core driver rather than here.

Here's my proposal:

add a Kconfig option SDHC_STANDARD_CORE_MMIO_SIZE

8/16/32(/64) - or 1/2/4(/8)

Indicates the size for all accesses to the HC MMIO interface

(maybe separate bool options instead of a single int option is better)

Downside: all controllers in a system must support the same access size

This can be turned into a property in the future if necessary...

Implement these MMIO wrappers in the core driver

For now, only CONFIG_SDHC_STANDARD_CORE_MMIO_SIZE=32 support is sufficient (BUILD_ASSERT() it)

#if CONFIG_SDHC_STANDARD_CORE_MMIO_SIZE == 32 uint8_t sdhc_std_core_read8(mem_addr_t reg) { return (uint8_t)sys_read32(reg); } /* ...all others, always using sys_read32()/sys_write32()... */ #else #error Unsupported MMIO size #endif

Perform all I/O directly in the driver

using dev->config->sdhc_std_common.mmio as base address

c.f. comment about having a common config structure

This should be sufficiently extensible to allow support for platforms where MMIO is larger (64-bit) or smaller (16-bit/8-bit) in the future if it ever becomes necessary.

EDIT: see #114752 (comment)

Just go full raw 32-bit I/O, not need for this abstraction layer at all. Controllers which don't support 32-bit operations are non-compliant with the Spec.

Thanks a lot. That's really good discussion. The specification is sometime hard to understand...
Let use raw 32-bit I/O, for standard registers with different width.
Thanks.

mathieuchopstm · 2026-08-13T13:45:47Z

+		/* There is only lower 32-bit capabilities register on usdhc */
+		usdhc_caps = imx_usdhc_reg32_read(dev, reg, 4);


The issue seems to rather be that the uSDHC capabilities register(s) are not compliant with the Specification. Using the core driver to parse them seems like the wrong approach: just read the register and decode it from this driver instead?

In any case, this approach doesn't seem clean at all.

In fact, browsing quickly through the i.MX93 Applications Processor Reference Manual, it seems there are other registers which don't match the Standard Specification...

There are several, NXP's uSDHC isn't really a compliant controller IMO. I believe that the Synopsis SD controller IP (and the one from Cadence as well) may be fully compliant, but NXP's only partially complies with the spec. This was one of the reasons I didn't write a generic SD controller driver when I introduced the subsystem- NXP wasn't compliant with the spec.

@yangbolu1991 is there any part of the controller that is fully compliant? It looks like the registers related to command arguments and responses are the same as the SDHC spec- I haven't checked the ADMA2 descriptor format though.

@danieldegrasse @mathieuchopstm
Unfortunately, I only have experience on NXP uSDHC/eSDHC by now.
They are partial compatible with spec. There are some different with register/bit/process.
The difficulty to implement a full standard host driver is we don't have compliant platform to verify.
But with the basic driver framework here, more people can work on this gradually.

For the registers/bits which are not fully compliant, I think vendor driver can choose to handle totally in itself, or choose to do some io access fixup which can still reusing standard driver. That's the way linux using.

https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci-esdhc-imx.c#L1533
https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci-of-esdhc.c#L1266

I think no need to estimate how much a controller is complaint with spec.
For standard driver, we may leave any callback in process to let vendor driver to do by itself if needs in the future.
For vendor driver, Just feel free to choose to reuse some APIs if could, or handle by itself.

Thanks.

danieldegrasse · 2026-08-20T14:22:45Z

+
+LOG_MODULE_REGISTER(sdhc_standard, CONFIG_SDHC_LOG_LEVEL);
+
+uint8_t sdhc_standard_read8(struct sdhc_standard_host *host, uint32_t reg)


In the SDHC spec, it states the following:

Implementation Note: Table 1-4 implies that the Host Driver should align register accesses on address boundaries matching the number of bytes in the access. That is, single byte accesses may be aligned on any offset within the register set; word (double byte) accesses should be aligned on two-byte offsets; and double-word (quad byte) accesses should be aligned on four-byte offsets. According to the feature (3), the Host Driver can always access Buffer Data Port register with double-word access.

Could we just restrict accesses to 32 bit, so we can always use sys_read32?

For more context, the feature (3) it refers to is:

Details

(3) Buffer Control with Block Size
The buffer preserves data up to the block size specified by the Block Size register. Following
definitions of controlling buffer enable the Host Driver to access the Buffer Data Port register
repeatedly with 32-bit width regardless of block size.
In case of write operation, the buffer accumulates the data written through the Buffer Data Port
register. When the buffer pointer reaches the block size, Buffer Write Enable in the Present State
register changes 1 to 0. It means no more data can be written to the buffer. Excess data of the last
write is ignored. For example, if just lower 2 bytes data can be written to the buffer and a 32-bit
(4-byte) block of data is written to the Buffer Data Port register, the lower 2 bytes of data is written to
the buffer and the upper 2 bytes is ignored. Every time Buffer Write Enable changes 0 to 1, it
means a next block of data can be written to the buffer. A new blocks write shall always start from
BE[00] position. After that, a block of data can be written to the buffer without checking Buffer Write
Enable.
In case of read operation, every time Buffer Read Enable in the Present State register changes 0
to 1, a block of data can be read through the Buffer Data Port register. A new block read shall
always start from BE[00] position. After that a block of data can be read from the buffer without
checking Buffer Read Enable. Excess data of the last read is ignored. For example, if just lower 2
bytes of data are left in the buffer and a 32-bit (4-byte) read is performed, the lower 2 bytes is valid
but the upper 2 bytes is undefined. When the buffer pointer reaches block size, Buffer Read
Enable changes 1 to 0. It means no more data can be read from the buffer.

(In Version 4.20 of the specification, this is titled (8) Buffer Control with Block Size but the implementation note still reads feature (3) - presumably an error)

With this context, it seems like this note should be understood as Double-word accesses to the Buffer Data Port [if supported by the implementation] will always be valid - as opposed to e.g., byte accesses which must be done in ascending order (see (2) Sequential and continuous access). In particular, I don't think this note should be interpreted as the Host Controller shall support double-word accesses...

...but looking through the specification again, I found the following paragraph:

SD Host Controller Simplified Specification Version 4.20

1.2 Register Map

The standard register map is classified in 18 parts listed below.
The Host Controller shall support byte, word and double word accesses to these registers.
Reserved bits in all registers shall be fixed to zero.
The Host Controller shall ignore writes to reserved bits; however, the Host Driver should write them as zero to ensure compatibility with possible future revisions to this Specification.

In older versions of the specification

SD Host Controller Simplified Specification Version 3.00

1.2 Register Map

The standard register map is classified in 12 parts listed below.
The Host Controller shall support byte, word and double word accesses to these registers.
Reserved bits in all registers shall be fixed to zero.
The Host Controller shall ignore writes to reserved bits; however, the Host Driver should write them as zero to ensure compatibility with possible future revisions to this Specification.

SD Host Controller Simplified Specification Version 2.00

1.2 Register Map

The standard register map is classified in 9 parts listed below.
The Host Controller shall support byte, word and double word accesses to these registers.
Reserved bits in all registers shall be fixed to zero.
The Host Controller shall ignore writes to reserved bits; however, the Host Driver should write them as zero to ensure compatibility with possible future revisions to this Specification.

I was actually wondering if the Specification imposed any such restriction (or if a controller supporting only 16-bit accesses would be valid for example) and must have missed this paragraph.

With this in mind, full +1 from me on using only native 32-bit I/O operations since support of these operations is required by the specification.

(that's what I proposed in #114752 (comment) but as extensible mechanism, which we should not need given this - except to support 16-bit platforms, perhaps... 🙂)

Thanks a lot for the good discussion.
Let's use sys_read32 in default in standard driver for any width registers.
But still leave 8/16/32/64 access callbacks if vendor driver want their implementation, or do some fixup for register complaint.

danieldegrasse · 2026-08-20T14:32:58Z

+		/* There is only lower 32-bit capabilities register on usdhc */
+		usdhc_caps = imx_usdhc_reg32_read(dev, reg, 4);


There are several, NXP's uSDHC isn't really a compliant controller IMO. I believe that the Synopsis SD controller IP (and the one from Cadence as well) may be fully compliant, but NXP's only partially complies with the spec. This was one of the reasons I didn't write a generic SD controller driver when I introduced the subsystem- NXP wasn't compliant with the spec.

@yangbolu1991 is there any part of the controller that is fully compliant? It looks like the registers related to command arguments and responses are the same as the SDHC spec- I haven't checked the ADMA2 descriptor format though.

Kept unified max-current-xxx property in sdhc.yaml. Dopped them in other binding files. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Kept unified power-delay-ms property in sdhc.yaml. Dopped power-delay-ms in other binding files. - If host requires it, add it in dts node. - If not, there is default value used. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Added common bus-width property in sdhc.yaml. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Renamed sdhc_helpers.h to sdhc_common.h for more usage in the future. The SDHC needs a common c file for vendor drivers reusing, and this file can be as its header file. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Added sdhc_common.c for common code. For now, it provided only one common API, for SDHC device tree properties initialization. Vendor drivers can convert to use sdhc_common_config and sdhc_common_dt_props_init API. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Added standard controller driver per SD Specifications Part A2 SD Host Controller Simplified Specification (Version 3.00) which matches current sdhc and sd subsystem features support. It can be updated in the future for example to v4.20 if new features are required to support. For now, the driver provided standard registers definition and access APIs, also provided a sdhc_standard_capabilites_init API for host capabilities initialization. The host controller driver needs to initialize a sdhc_standard_host structure variable, then it can reuse the standard controller driver APIs. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Converted imx_usdhc to use common API to init properties. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Converted imx_usdhc to use standard driver APIs for capabilities init. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

yangbolu1991 · 2026-08-26T04:06:16Z

@danieldegrasse @mathieuchopstm
Sorry for my late reply.

Updated to v5. Changes include,

Renamed sdhc_standard driver to sdhc_standard_core.
Made 32bit IO as default way to access standard registers.
Other improvement per comments.

Thanks.

yangbolu1991 · 2026-08-26T06:47:49Z

It seems the twister issue existed on main code base.

@VynDragon May I know if you are the right person to fix it? Thanks.

west build -p -b m1s_dock/bl808c09q2i tests/drivers/sdhc -T drivers.sdhc.sdhc_api

/__w/zephyr/zephyr/drivers/sdhc/sdhc_bflb.c:20:10: fatal error: sdh_reg.h: No such file or directory
   20 | #include <sdh_reg.h>
      |          ^~~~~~~~~~~
compilation terminated.

zephyrbot requested review from JiafeiPan, LucasTambor, ZhaoQiang-b45475, Zhiqiang-Hou, danieldegrasse, dbaluta, iuliana-prodan, lorc, lucien-nxp, marekmatej, raffarost, sylvioalves, uLipe, wmrsouza and xakep-amatop July 28, 2026 08:19

zephyrbot assigned danieldegrasse Jul 28, 2026

yangbolu1991 force-pushed the sdhc-common-driver branch from 978c7ab to b6a8052 Compare July 28, 2026 08:47

maass-hamburg requested changes Jul 28, 2026

View reviewed changes

yangbolu1991 force-pushed the sdhc-common-driver branch from b6a8052 to 05a2658 Compare July 29, 2026 03:42

danieldegrasse reviewed Aug 3, 2026

View reviewed changes

zephyrbot requested review from KhiemNguyenT, khoa-nguyen-18, kylebonnici, lauracarlesso and mathieuchopstm August 12, 2026 07:00

erwango reviewed Aug 12, 2026

View reviewed changes

mathieuchopstm requested changes Aug 12, 2026

View reviewed changes

yangbolu1991 force-pushed the sdhc-common-driver branch from 1db419a to f6e4271 Compare August 13, 2026 11:40

zephyrbot requested review from MerinMGeorge, mbolivar, mcatee-infineon, mchp-asif, minyuan-xue, mmahadevan108 and nandojve August 13, 2026 11:43

mathieuchopstm reviewed Aug 13, 2026

View reviewed changes

danieldegrasse reviewed Aug 20, 2026

View reviewed changes

yangbolu1991 added 8 commits August 26, 2026 10:01

dts: bindings: sdhc: unify max-current-xxx property

c229962

Kept unified max-current-xxx property in sdhc.yaml. Dopped them in other binding files. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

dts: bindings: sdhc: unify power-delay-ms property

c4f7258

Kept unified power-delay-ms property in sdhc.yaml. Dopped power-delay-ms in other binding files. - If host requires it, add it in dts node. - If not, there is default value used. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

dts: bindings: sdhc: unify bus-width property

c943c57

Added common bus-width property in sdhc.yaml. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

drivers: sdhc: rename sdhc_helpers.h to sdhc_common.h

3089fc2

Renamed sdhc_helpers.h to sdhc_common.h for more usage in the future. The SDHC needs a common c file for vendor drivers reusing, and this file can be as its header file. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

drivers: sdhc: imx_usdhc: use common API to init properties

6de1d7e

Converted imx_usdhc to use common API to init properties. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

drivers: sdhc: imx_usdhc: use standard driver APIs for capabilities init

92bc9d1

Converted imx_usdhc to use standard driver APIs for capabilities init. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

		/* There is only lower 32-bit capabilities register on usdhc */
		usdhc_caps = imx_usdhc_reg32_read(dev, reg, 4);


		LOG_MODULE_REGISTER(sdhc_standard, CONFIG_SDHC_LOG_LEVEL);

		uint8_t sdhc_standard_read8(struct sdhc_standard_host *host, uint32_t reg)

Uh oh!

Conversation

yangbolu1991 commented Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yangbolu1991 commented Jul 29, 2026

Uh oh!

yangbolu1991 commented Aug 3, 2026

Uh oh!

danieldegrasse left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mathieuchopstm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yangbolu1991 commented Aug 13, 2026

Uh oh!

yangbolu1991 commented Aug 13, 2026

Uh oh!

sonarqubecloud Bot commented Aug 13, 2026

Quality Gate passed

Uh oh!

mathieuchopstm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yangbolu1991 commented Jul 28, 2026 •

edited

Loading