Samsung Galaxy Book6 Pro camera sensor (ACPI HID SSLC2000, IPU7) has no in-tree driver, working out-of-tree fix exists

Hello,

On a Samsung Galaxy Book6 Pro (Panther Lake, Intel Core Ultra X7 358H),
the integrated MIPI camera is not usable under Linux. The IPU7 driver
probes successfully and loads firmware, but no sensor subdevice is
registered, so the media graph stays empty:

intel-ipu7 0000:00:05.0: no subdev found in graph

The camera sensor presents itself with ACPI HID SSLC2000, for which
there was no in-tree driver. I could not find any prior public
reference to this HID, so this may be the first report of it.

Since first working on this, a community fix has surfaced here:

https://github.com/Jabbslad/sc200pc-linux

It confirms and completes the diagnosis below:

- The sensor is a Samsung/SmartSens SC200PC, ACPI HID SSLC2000, on
I2C3 at address 0x36, matching the ACPI data below.
- drivers/media/pci/intel/ipu-bridge.c has no entry for SSLC2000 in
ipu_supported_sensors[]. Because of that, ipu-bridge never builds a
software-node graph for the sensor, and intel-ipu7 correctly reports
"no subdev found in graph", which is the exact symptom seen here.
- The fix is a two-line addition to ipu_supported_sensors[] (patch:
patches/ipu-bridge-add-sslc2000.patch in the repo above), plus a new
out-of-tree V4L2 sensor driver (sc200pc.c, a 141-entry init table
reverse-engineered from the OEM Windows sc200pc.sys driver), since
no in-tree driver exists for this sensor yet.
- I have confirmed this working end to end on Fedora 44, kernel
7.1.5-201.fc44.x86_64 (the repo itself only targeted Arch). qcam
captures real frames, and Firefox picks up the camera correctly via
PipeWire/libcamera at 1920x1080 30fps.

This is currently packaged as an out-of-tree DKMS solution, but both
pieces seem small enough to be reasonable candidates for upstreaming.
ipu-bridge.c just needs the sensor added to its config table, and
sc200pc.c would need to go through the usual V4L2 sensor driver review
(register table cleanup, CameraSensorHelper / CameraSensorProperties
entries for libcamera, and so on).

I am filing this report with that context in case it helps prioritise
or review the upstreaming work. I am happy to test patches on this
hardware.

Below is the original diagnosis I put together before finding the
existing fix, kept for reference in case the ACPI details are useful.

SYSTEM

Machine: Samsung Galaxy Book6 Pro 14"
DMI system-product-name: Galaxy Book6 Pro - PRHK
DMI system-family: Galaxy Book6 Pro
DMI system-version: 1.0
DMI baseboard-product-name: NP940XJG-KG7DE
BIOS version: PRHK.1.2.48.546
SoC: Intel Core Ultra X7 358H (Panther Lake)
Distro: Fedora 44
Kernel: 7.1.5-201.fc44.x86_64 (stock Fedora)
IPU: 00:05.0 Multimedia controller: Intel Corporation Panther Lake IPU
(rev 04), device id 0xb05d

WHAT WORKS

The IPU7 side comes up cleanly. Relevant dmesg:

intel_ipu7: module is from the staging directory, the quality is
unknown, you have been warned.
intel-ipu7 0000:00:05.0: enabling device (0000 -> 0002)
intel-ipu7 0000:00:05.0: Device 0xb05d (rev: 0x4)
intel-ipu7 0000:00:05.0: IPU7 SKU 1 in secure mode mask 0x0
intel-ipu7 0000:00:05.0: firmware cpd file: intel/ipu/ipu7ptl_fw.bin
intel-ipu7 0000:00:05.0: FW binary0 info:
intel-ipu7 0000:00:05.0: Name: psys
intel-ipu7 0000:00:05.0: Version: 1.2.1.251215214352
intel-ipu7 0000:00:05.0: FW binary1 info:
intel-ipu7 0000:00:05.0: Name: isys
intel-ipu7 0000:00:05.0: Version: 1.2.1.251215214331
intel-ipu7 0000:00:05.0: Sending BOOT_LOAD to CSE
intel-ipu7 0000:00:05.0: Sending AUTHENTICATE_RUN to CSE
intel-ipu7 0000:00:05.0: CSE authenticate_run done
intel_ipu7_isys: module is from the staging directory, the quality is
unknown, you have been warned.
intel-ipu7 0000:00:05.0: no subdev found in graph

intel_skl_int3472_discrete and ipu_bridge are both loaded (before the
fix above).

THE SENSOR DEVICE

The sensor ACPI node is \_SB.LNK0, which reports itself as present and
functional:

$ cat /sys/bus/acpi/devices/SSLC2000:00/status
15

Evaluated live via acpi_call:

\_SB.LNK0._STA -> 0xf
\_SB.LNK0._HID -> "SSLC2000"
\_SB.DSC0._STA -> 0xf (the INT3472 PMIC/power controller for this link)
\_SB.LNK1._STA -> 0x0 (second link, not populated)

_HID is a method, not a static Name, so the HID only becomes visible
at runtime. It is produced by an HCID() helper in the MiCaTb/MiCaTabl
SSDT which selects between several possible sensor modules for this
board design.

There are also five OVTI08F4 ACPI nodes with status = 0. These appear
to be the unpopulated alternative sensor variants for the same board,
not the sensor actually fitted here. I initially chased those, which
was a red herring, worth flagging in case others hit the same
confusion on Samsung Panther Lake machines.

RESOURCES

\_SB.LNK0._CRS decodes to two I2cSerialBus descriptors, both on
\_SB.PC00.I2C3:

slave address 0x36 (presumably the sensor itself)
slave address 0x50 (presumably an EEPROM, calibration/OTP data)

SSDB

Raw \_SB.LNK0.SSDB dump (110 bytes), decoded values of note:

a lane count field that reads as 2 (2-lane MIPI CSI-2)
0x80 0xba 0x8c 0x01 little-endian = 0x018CBA80 = 25,920,000, plausibly
an MCLK or link frequency in Hz

Full raw buffer available on request.

WHAT THIS IS NOT

To save others the same detour, I ruled out the following:

Not the Intel CVS dependency. There is no INTC10DE / INTC10E0 /
INTC10CF / INTC10E1 / INTC10FA device anywhere in this machine's ACPI
tables, and \_SB.LNK0._DEP does not reference one. Building and
loading intel_cvs from intel/vision-drivers has no effect here, it
binds nothing. This differs from the reported Dell XPS and ThinkPad
X1 Carbon Gen 14 Panther Lake cases.

Not Samsung's "block recording" privacy feature. The
samsung-galaxybook driver binds (ACPI ID SAM0430) and creates the
"Samsung Galaxy Book Camera Lens Cover" input device;
evtest --query ... SW_CAMERA_LENS_COVER returns 0 (not blocked).

Not a disabled/absent device. _STA returns 0x0f for both the sensor
link and its INT3472 power controller.

Not an _OSI / OSYS quirk. The DSDT's highest recognised value is
"Windows 2022", which Linux already reports.

No UEFI setting. This machine's firmware setup exposes no camera
toggle.

No firmware update available via fwupd/LVFS for this model.

Thanks for reading, and happy to provide the full DSDT/SSDT dumps or
run further tests on this hardware.

Regards
Onuralp Akca