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	zephyrproject-rtos/hal_intel@0905a52 (main)	zephyrproject-rtos/hal_intel@98092b7	zephyrproject-rtos/[email protected]

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

[XenuIsWatching]

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

[gmarull]

work should converge to #64528, agreed this proposal has quite a few issues

[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.