# \[TRACKING\] Controlling Power Direction for USB C

**URL:** <https://community.frame.work/t/tracking-controlling-power-direction-for-usb-c/19259>\
**Category:** Linux\
**Tags:** arch\
**Created:** [June 5, 2022, 9:26am UTC](https://community.frame.work/t/tracking-controlling-power-direction-for-usb-c/19259 "2022-06-05T09:26:48Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![DHowett](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/dhowett/32/1990_2.png) [@DHowett](https://community.frame.work/u/DHowett)\
**Post date:** [June 6, 2022, 1:42am UTC](https://community.frame.work/t/tracking-controlling-power-direction-for-usb-c/19259/10 "2022-06-06T01:42:46Z")

</div>

It looks like UCSI should be exposed via ACPI device `PNP0CA0`, and should report a specific GUID via `_DSM`. Looking at the `hx20`'s ACPI tables, that is certainly what’s happening. Everything checks out on the ACPI side… including the EC communication through ER1/the “customer memory map”.

EDIT: with dyndbg tracing `module acpi +p`:

```auto
[4103.506382] ucsi_acpi USBC000:00: Adding to IOMMU failed: -19 (ENODEV)

```

---

_[View the full topic](https://community.frame.work/t/tracking-controlling-power-direction-for-usb-c/19259)._