i3c: add sedi i3c driver

[leifuzhao]

This gives initial support to the design ware i3c controller used in intel ish.

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_intel	https://github.com/zephyrproject-rtos/hal_intel/commit/0905a528623de56b1bedf817536321bcdbc0efae (main)	https://github.com/zephyrproject-rtos/hal_intel/commit/98092b773a2b62383bde78656f62ec4ceffeacc3	zephyrproject-rtos/[email protected]

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[leifuzhao]

Theres many many issues here with this PR... I'm not sure where to begin

If this really is the snps designware i3c as the description implies, then this is a duplicate of #64528

The zephyr driver has two modes. One is native driver mode, the other is the HAL mode, the two mode drivers could co-exist. The ISH drivers use HAL mode, for example, the previous upstreamed i2c driver uses sedi HAL to perform low level operation and config while there is another native i2c driver for the same designware i2c IP. The ISH i3c driver follows the same way with other upstreamed ISH drivers such as i2c driver. So this PR could co-exist with PR #64528, they fulfill different job.

[gmarull]

Theres many many issues here with this PR... I'm not sure where to begin If this really is the snps designware i3c as the description implies, then this is a duplicate of #64528

The zephyr driver has two modes. One is native driver mode, the other is the HAL mode, the two mode drivers could co-exist. The ISH drivers use HAL mode, for example, the previous upstreamed i2c driver uses sedi HAL to perform low level operation and config while there is another native i2c driver for the same designware i2c IP. The ISH i3c driver follows the same way with other upstreamed ISH drivers such as i2c driver. So this PR could co-exist with PR #64528, they fulfill different job.

-1 on using HALs for generic IPs like Synopsys DW I3C. Vendor-specific code should only exist for any wrapper/vendor quirks.

[leifuzhao]

Theres many many issues here with this PR... I'm not sure where to begin If this really is the snps designware i3c as the description implies, then this is a duplicate of #64528

The zephyr driver has two modes. One is native driver mode, the other is the HAL mode, the two mode drivers could co-exist. The ISH drivers use HAL mode, for example, the previous upstreamed i2c driver uses sedi HAL to perform low level operation and config while there is another native i2c driver for the same designware i2c IP. The ISH i3c driver follows the same way with other upstreamed ISH drivers such as i2c driver. So this PR could co-exist with PR #64528, they fulfill different job.

-1 on using HALs for generic IPs like Synopsys DW I3C. Vendor-specific code should only exist for any wrapper/vendor quirks.

The HAL code used is not stay in zephyr repo, rather it resides in another opensource repo, the code submitted here for upstreaming only only contains API calls to HAL.

[gmarull]

Theres many many issues here with this PR... I'm not sure where to begin If this really is the snps designware i3c as the description implies, then this is a duplicate of #64528

The zephyr driver has two modes. One is native driver mode, the other is the HAL mode, the two mode drivers could co-exist. The ISH drivers use HAL mode, for example, the previous upstreamed i2c driver uses sedi HAL to perform low level operation and config while there is another native i2c driver for the same designware i2c IP. The ISH i3c driver follows the same way with other upstreamed ISH drivers such as i2c driver. So this PR could co-exist with PR #64528, they fulfill different job.

-1 on using HALs for generic IPs like Synopsys DW I3C. Vendor-specific code should only exist for any wrapper/vendor quirks.

The HAL code used is not stay in zephyr repo, rather it resides in another opensource repo, the code submitted here for upstreaming only only contains API calls to HAL.

This approach doesn't make sense for vendor-agnostic IP.

[github-actions[bot]]

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