MT-149180: add basic ipc/extcon mechanism to send usb events from the stm through the kernel#41
Open
Overdr0ne wants to merge 22 commits into
Open
MT-149180: add basic ipc/extcon mechanism to send usb events from the stm through the kernel#41Overdr0ne wants to merge 22 commits into
Overdr0ne wants to merge 22 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds an STM32 SPI-based IPC driver that publishes USB role/connection events as virtual extcon connectors, and wires it up for the mt-connect platform.
Changes:
- Introduce
extcon-stm32-ipcSPI core + child “virtual connector” platform driver with debugfs simulation support - Add Kconfig/Makefile integration for
CONFIG_EXTCON_STM32_SPI_IPC - Update mt-connect DTS/defconfig to instantiate the SPI IPC device and connect USB controllers via
extcon
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| drivers/extcon/extcon-stm32-ipc.c | New SPI IPC + virtual extcon implementation, IRQ handling, and debugfs simulation hooks |
| drivers/extcon/Makefile | Build integration for new extcon driver object |
| drivers/extcon/Kconfig | New EXTCON_STM32_SPI_IPC configuration option |
| arch/arm64/configs/mt_connect_defconfig | Enables the new driver in the platform defconfig |
| arch/arm64/boot/dts/freescale/mt-connect.dts | Replaces spidev node with STM32 IPC node, adds connector children, and links USB extcon phandles |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ardentra
approved these changes
Jun 17, 2026
Collaborator
|
@Overdr0ne unresolved comments here please |
Add a custom SPI client driver that functions as an extcon event provider. This driver communicates with an external STM32 co-processor over SPI using an attention line (interrupt) to propagate USB cable events. It registers separate virtual extcon sub-devices for each connector, allowing ChipIdea OTG controllers to switch between Host/Peripheral roles. A debugfs simulation interface is also exposed for runtime testing.
Enable CONFIG_EXTCON_STM32_SPI_IPC in mt_connect_defconfig to compile the custom stm-spi-ipc extcon driver directly into the kernel.
Configure the ECSPI2 controller on mt-connect to support the STM32 SPI IPC slave node and its virtual USB connector child nodes. Bind &usbotg1 and &usbotg2 to their respective virtual extcon connectors and enable role switching. Set up pin control and active-low interrupt for GPIO2_IO11.
Add a dependency on CONFIG_OF for CONFIG_EXTCON_STM32_SPI_IPC to prevent compile/configuration failures on architectures where Device Tree is not supported.
Move variable declarations in stm_usb_connector_probe() and stm_ipc_probe() to the top of functions. This resolves compilation failures under -Wdeclaration-after-statement.
Validate the 'port-id' Device Tree property in stm_usb_connector_probe() to ensure it fits within [0, 255] before casting it to u8. Avoids silently ignoring out-of-bounds inputs from the device tree.
Replace pr_warn_ratelimited() with dev_warn_ratelimited(&edev->dev, ...) in stm_ipc_update_state(). This logs the warning in the context of the specific extcon device instance, making debugging easier.
Move crc8_populate_msb() from stm_ipc_probe() to stm_ipc_init(). Populating the table during module initialization instead of probe prevents a concurrent write race condition when multiple devices are probed.
Create the top-level 'stm_ipc' debugfs parent directory once globally during module initialization and remove it during module exit. Per-device debugfs subdirectories are created under this parent directory during probe.
Read the current cable states of EXTCON_USB and EXTCON_USB_HOST first in stm_ipc_update_state(). Only invoke extcon_set_state_sync() when a state bit actually changes, clearing the opposite state first. This avoids unnecessary extcon uevent updates and userspace churn.
Replace dev_err() with dev_err_ratelimited() on SPI sync transfer failures in stm_ipc_threaded_irq(). This avoids flooding the kernel log in case the SPI bus becomes misconfigured or experiences noise.
Check the return value of device_for_each_child() when dispatching USB events. If no child platform connector matches the reported port ID, emit a rate-limited warning log to assist in troubleshooting Device Tree or protocol mismatches.
Register a devm device cleanup action in stm_usb_connector_probe() to automatically call debugfs_remove() on the connector's simulation file when the connector device is unbound. This prevents a potential use-after-free (UAF) if userspace interacts with the simulation file after the device is unbound.
Register the platform connector driver stm_usb_connector_driver before registering the SPI core driver stm_ipc_driver during module initialization. This ensures child connector devices can bind immediately when devm_of_platform_populate() is called during SPI device probe, preventing events from being dropped. Swap unregistration order in exit.
Do not dereference edev->dev to log messages in stm_ipc_update_state() since struct extcon_dev is opaque to client drivers. Instead, store the device pointer in struct stm_connector_priv and pass it explicitly to stm_ipc_update_state() from all call sites.
Comment on lines
+251
to
+263
| if (parent_priv && parent_priv->debugfs_root) { | ||
| struct dentry *sim_file; | ||
|
|
||
| snprintf(name, sizeof(name), "usb%d_sim", priv->port_id + 1); | ||
| sim_file = debugfs_create_file(name, 0200, parent_priv->debugfs_root, priv, &stm_ipc_sim_fops); | ||
| if (!IS_ERR_OR_NULL(sim_file)) { | ||
| ret = devm_add_action_or_reset(dev, stm_ipc_debugfs_cleanup, sim_file); | ||
| if (ret) { | ||
| dev_err(dev, "Failed to register debugfs cleanup action: %d\n", ret); | ||
| return ret; | ||
| } | ||
| } | ||
| } |
Comment on lines
+203
to
+208
| static void stm_ipc_debugfs_cleanup(void *data) | ||
| { | ||
| struct dentry *dentry = data; | ||
|
|
||
| debugfs_remove(dentry); | ||
| } |
Comment on lines
+505
to
+510
| stm_ipc: stm32-ipc@0 { | ||
| compatible = "multitracks,stm32-spi-ipc"; | ||
| reg = <0>; | ||
| compatible = "rohm,dh2228fv"; | ||
| spi-max-frequency = <500000>; | ||
| spi-max-frequency = <10000000>; | ||
| interrupt-parent = <&gpio2>; | ||
| interrupts = <11 IRQ_TYPE_EDGE_FALLING>; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MT-149180
This change implements a SPI IPC driver that triggers extcon events. The idea is, those extcon events look just like they would if they came from an onboard usb controller. I created some debug nodes to simulate disconnect and vbus detected events, which get sent to the extcon nodes where you can see the uevents in userspace here. So I’m only simulating the extcon part of the signal path, not yet anything with SPI. That part is in place, but I just need to get a clear spec on the SPI packet- we might already have that, I just need to look. Once the stm side is done, it should be a pretty simple modification to finish wiring things up.
I'm leaving this as a draft for now because the stm side isn't done, and I made up my own packet spec, but it would be safe to integrate so people can try it out
dev QA: @dnappier-mt