IPU6 camera (OVTI01A0) not working on XPS 13 9315: VSC device on native SPI1 never instantiated

## Summary

On a Dell XPS 13 9315 (OV01A10 / OVTI01A0 sensor), the built-in `intel-ipu6` driver fails to enumerate the camera on every boot. The IPU6 PCI device probes and loads firmware correctly, but the associated VSC (Visual Sensing Controller) device is declared in ACPI as a child of the native `SPI1` controller (`\_SB_.PC00.SPI1.SPFD.CVFD`) rather than behind a USB-LJCA bridge, and this ACPI-declared device is **never instantiated as a real SPI device** by the kernel. As a result, no `vsc-tp`/`intel_vsc` driver activity ever appears in dmesg, the sensor never shows up on the I2C bus, and the camera never becomes available.

This looks related to, but distinct from, the previously-fixed bug tracked in [[Red Hat Bugzilla #2316918](https://bugzilla.redhat.com/show_bug.cgi?id=2316918)](https://bugzilla.redhat.com/show_bug.cgi?id=2316918) ("iVSC fails to probe with ETIMEDOUT on XPS 9315 (IPU6 + OVTI01A0)"), which was fixed upstream and landed in Arch's 6.13.4-arch1 kernel (Feb 2025) and backported to 6.12.19 LTS. That fix addressed a USB-LJCA topology where `vsc-tp` did attempt (and fail) to probe. On this system, the VSC device never reaches that point at all — the SPI device is never created in the first place.

## System information

- **Model:** Dell XPS 13 9315
- **Camera sensor:** OV01A10, ACPI HID `OVTI01A0` (also present: `OVTI01AB` for the IR sensor, `INT3471`, `INT3472:00`–`0c`, `INT3474:00`)
- **Distro:** Arch Linux
- **Kernel:** 7.1.11-arch1-1
- **`intel_ipu6` module:** in-tree (`intree: Y`), not a DKMS/out-of-tree build
- **linux-firmware-intel:** 20260810-2 (official firmware present and correctly located)

## Expected behavior

`intel-ipu6` probes, the VSC chip initializes (`intel_vsc: silicon stepping is version is 0:2` or similar), the sensor is found on I2C, and dmesg shows:
```
intel-ipu6 0000:00:05.0: Found supported sensor OVTI01A0:00
intel-ipu6 0000:00:05.0: Connected 1 cameras
```

## Actual behavior

dmesg shows only:
```
[ 4.458267] intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002)
[ 15.459455] pci 0000:00:05.0: deferred probe pending: intel-ipu6: IPU6 bridge init failed
```

No firmware-load line, no `FW version:` line, no sensor-found line, and — critically — **no `vsc-tp` or `intel_vsc` log lines at all**, unlike every report in RHBZ#2316918 (where those lines appear repeatedly even in the failing case).

## Diagnostic steps taken

1. **Firmware present and correctly located** (via official `linux-firmware-intel`):
- `/lib/firmware/intel/ipu/ipu6ep_fw.bin.zst` and related files present
- `/lib/firmware/intel/vsc/ivsc_pkg_ovti01a0_0.bin.zst` and related files present

2. **Sensor driver present and loadable:**
- `ov01a10.ko.zst` present in `/lib/modules/7.1.11-arch1-1/kernel/drivers/media/i2c/`
- `modprobe ov01a10` succeeds; module shows loaded in `lsmod`

3. **Sensor identified correctly via ACPI:**
```
$ ls /sys/bus/acpi/devices/ | grep -iE "OVTI|INT347"
OVTI01A0:00
OVTI01AB:00
OVTI01AS:00
INT3471:00
INT3472:00 ... INT3472:0c
INT3474:00
```
But **not** present on `/sys/bus/i2c/devices/` — consistent with the sensor being gated behind VSC init, which never completes.

4. **`int3472-discrete` reports no dependents:**
```
[ 4.479842] int3472-discrete INT3472:01: INT3472 seems to have no dependents.
```

5. **VSC/LJCA driver chain — all modules present, none active:**
- `mei-vsc-hw.ko.zst`, `mei-vsc.ko.zst`, `usb-ljca.ko.zst`, `spi-ljca.ko.zst`, `gpio-ljca.ko.zst`, `i2c-ljca.ko.zst` all exist in the kernel tree and load cleanly with `modprobe` (`usbcore: registered new interface driver ljca` appears in dmesg after manual load)
- `mei_vsc_hw` is loaded automatically at boot with 0 references
- No `vsc-tp`, `intel_vsc`, or `ljca` messages ever appear in dmesg otherwise

6. **No USB-LJCA bridge present on the USB bus:**
```
$ for d in /sys/bus/usb/devices/*/idVendor; do echo "$d: $(cat $d)"; done
```
only shows generic hubs (`1d6b`), a Goodix fingerprint reader (`27c6`), and the Intel Bluetooth/WiFi controller (`8087`). **No Intel (`8086`) LJCA USB device is ever enumerated.**

7. **ACPI declares the VSC device on the native SPI1 controller, not behind USB-LJCA:**
```
$ cat /sys/bus/acpi/devices/INTC1094:00/path
\_SB_.PC00.SPI1.SPFD
$ ls /sys/bus/acpi/devices/ | grep -i SPI
...
\_SB_.PC00.SPI1
\_SB_.PC00.SPI1.FPNT
\_SB_.PC00.SPI1.SPFD
\_SB_.PC00.SPI1.SPFD.CVFD
```
The SPI1 master itself **is** registered and functional:
```
$ find /sys/devices -iname "*SPI1*"
/sys/devices/pci0000:00/0000:00:1e.2/pxa2xx-spi.3/spi_master/spi1
```
But no `spi1.x` child device for `SPFD`/`CVFD` is ever created:
```
$ ls /sys/bus/spi/devices/
spi0.0
```
(only the unrelated `spi0.0` on a different PCI controller, `0000:00:1f.5`)

8. **Full power cycle attempted** (shutdown, unplug from AC, hold power button ~30s, wait, replug, boot) — no change in behavior. (RHBZ#2316918 reports this sometimes un-sticks a wedged VSC chip; it did not help here, suggesting the VSC/SPI device isn't reaching an init attempt at all, wedged or otherwise.)

9. **Ruled out leftover packages from earlier manual attempts:** system had residual AUR packages (`intel-ipu6-dkms-git-fix`, `intel-ipu6ep-camera-bin-fix`, `intel-ivsc-firmware`) from prior troubleshooting, including one that had silently overwritten `/lib/firmware/intel/ipu6ep_fw.bin` outside the path the driver actually reads (`/lib/firmware/intel/ipu/ipu6ep_fw.bin.zst`). Removed all three and reinstalled `linux-firmware-intel --overwrite`; behavior is unchanged, so this was not the root cause (though worth cleaning up regardless).

10. **`dell-privacy` WMI driver reports all three privacy toggles as unsupported** (Microphone/Camera Shutter/ePrivacy Screen), correlating with a firmware bug logged at boot:
```
[ 1.697751] wmi_bus wmi_bus-PNP0C14:02: [Firmware Bug]: WQBC data block query control method not found
```
Camera is confirmed **enabled** in BIOS setup (Integrated Devices → Enable Camera). Unclear whether the WQBC issue is related to the SPI enumeration failure or a separate, cosmetic firmware bug.

## Hypothesis

On this particular XPS 9315 board revision, the VSC chip is wired to the native `SPI1` controller rather than routed through a USB-LJCA bridge (the topology assumed by most existing IPU6/IVSC fixes and documentation, including RHBZ#2316918). The ACPI tables correctly describe this device (`SPI1.SPFD.CVFD`), and the `spi-ljca`/`pxa2xx-spi` infrastructure is present and functional at the controller level, but the kernel never instantiates the ACPI-declared child device as an actual `spi1.x` device — so no driver (vsc-tp or otherwise) ever gets a chance to probe it, successfully or not.

This may indicate an ACPI enumeration gap for this specific board's SPI-attached VSC topology, as opposed to the probe/timing bug already fixed for the USB-LJCA topology.

## Note

This investigation was carried out together with Claude (Anthropic's AI assistant), which helped work through the diagnostic steps interactively based on the command output shared during troubleshooting, and prepared this report.

Start by tracing ACPI child-device enumeration for the native pxa2xx-spi SPI1 controller and compare it with the spi-ljca and vsc-tp paths described in the report. Reproduce the missing spi1 child in sysfs and the absent VSC messages, then determine what allows the ACPI-declared SPFD/CVFD device to probe. Done means the VSC initializes, the OVTI01A0 sensor appears on I2C, and intel-ipu6 reports a connected camera.

Written by the indexing model from the issue text.