drivers/usb/typec/port-mapper.c
Source file repositories/reference/linux-study-clean/drivers/usb/typec/port-mapper.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/usb/typec/port-mapper.c- Extension
.c- Size
- 2959 bytes
- Lines
- 109
- Domain
- Driver Families
- Bucket
- drivers/usb
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/acpi.hlinux/component.hlinux/thunderbolt.hlinux/usb.hclass.h
Detected Declarations
struct each_port_argfunction Copyrightfunction typec_aggregate_unbindfunction usb4_port_comparefunction typec_port_comparefunction typec_port_matchfunction typec_link_portsfunction typec_unlink_ports
Annotated Snippet
struct each_port_arg {
struct typec_port *port;
struct component_match *match;
};
static int usb4_port_compare(struct device *dev, void *fwnode)
{
return usb4_usb3_port_match(dev, fwnode);
}
static int typec_port_compare(struct device *dev, void *fwnode)
{
return device_match_fwnode(dev, fwnode);
}
static int typec_port_match(struct device *dev, void *data)
{
struct acpi_device *adev = to_acpi_device(dev);
struct each_port_arg *arg = data;
struct acpi_device *con_adev;
con_adev = ACPI_COMPANION(&arg->port->dev);
if (con_adev == adev)
return 0;
if (con_adev->pld_crc == adev->pld_crc) {
struct fwnode_handle *adev_fwnode = acpi_fwnode_handle(adev);
component_match_add(&arg->port->dev, &arg->match, typec_port_compare,
adev_fwnode);
/*
* If dev is USB 3.x port, it may have reference to the
* USB4 host interface in which case we can also link the
* Type-C port with the USB4 port.
*/
if (fwnode_property_present(adev_fwnode, "usb4-host-interface"))
component_match_add(&arg->port->dev, &arg->match,
usb4_port_compare, adev_fwnode);
}
return 0;
}
int typec_link_ports(struct typec_port *con)
{
struct each_port_arg arg = { .port = con, .match = NULL };
if (!has_acpi_companion(&con->dev))
return 0;
acpi_bus_for_each_dev(typec_port_match, &arg);
if (!arg.match)
return 0;
/*
* REVISIT: Now each connector can have only a single component master.
* So far only the USB ports connected to the USB Type-C connector share
* the _PLD with it, but if there one day is something else (like maybe
* the DisplayPort ACPI device object) that also shares the _PLD with
* the connector, every one of those needs to have its own component
* master, because each different type of component needs to be bind to
* the connector independently of the other components. That requires
* improvements to the component framework. Right now you can only have
* one master per device.
*/
return component_master_add_with_match(&con->dev, &typec_aggregate_ops, arg.match);
}
void typec_unlink_ports(struct typec_port *con)
{
if (has_acpi_companion(&con->dev))
component_master_del(&con->dev, &typec_aggregate_ops);
}
Annotation
- Immediate include surface: `linux/acpi.h`, `linux/component.h`, `linux/thunderbolt.h`, `linux/usb.h`, `class.h`.
- Detected declarations: `struct each_port_arg`, `function Copyright`, `function typec_aggregate_unbind`, `function usb4_port_compare`, `function typec_port_compare`, `function typec_port_match`, `function typec_link_ports`, `function typec_unlink_ports`.
- Atlas domain: Driver Families / drivers/usb.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.