Re: [PATCH 2/3] reset: Add Apple SoC CIO reset driver
Sven Peter <[email protected]>
| Newsgroups | gmane.linux.drivers.devicetree,gmane.linux.ports.arm.kernel,gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
On 09.08.26 16:30, Joshua Peisach wrote: > On Sun Aug 9, 2026 at 8:16 AM EDT, Sven Peter wrote: >> Add a driver for the reset of the CIO (USB4/Thunderbolt) blocks on >> Apple Silicon SoCs which has to be deasserted before their >> co-processor can be booted. On t8103 each port comes with a dedicated >> register page while t600x uses a single register with one request bit >> per port shared by all ports of a die inside the PMGR MMIO region. >> >> Signed-off-by: Sven Peter <[email protected]> >> --- >> MAINTAINERS | 1 + >> drivers/reset/Kconfig | 10 +++ >> drivers/reset/Makefile | 1 + >> drivers/reset/reset-apple-cio.c | 182 +++++++++++++++++++++++++++++++ >> +++++++++ >> 4 files changed, 194 insertions(+) > >> + >> +static int apple_cio_reset_probe(struct platform_device *pdev) >> +{ >> + struct device *dev = &pdev->dev; >> + struct apple_cio_reset *priv; >> + int ret; >> + >> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); >> + if (!priv) >> + return -ENOMEM; >> + >> + priv->variant = of_device_get_match_data(dev); > > Might be a dumb question, but does priv->variant also need to be > checked? Because later priv->variant->pmgr_child is and I *think* > it could return NULL. > > (Or is this not necessary since in theory the device should only run > this if detected... so this should never be an issue?) You might be able to get this driver to probe without a device tree node by manually forcing it with sysfs but well... play stupid games, win stupid prizes. Adding the check is just two lines and doesn't hurt though. Best, Sven