Re: [PATCH v4 0/2] Add device tree for Acer Swift Go Pro AI (SFA14-11)

[Jianfeng Liu <liujianfeng1994@gmail.com>]

Hi Kaipeng,

Thanks for the detailed reply!

On Mon, 12 Oct 2026 16:15:19 +0800,Kaipeng Zeng wrote:
>Acer had a page about "Acer Swift Go Pro AI" but it was deleted,
>fortunately here is
>a snapshot:
>https://web.archive.org/web/20260314171131/https://www.acer.com.cn/product_list.html?parentid=323
>It's sold in China using the name "Acer 非凡 Go Pro AI".
>There is some discussion in the thread of my previous version:
>https://lore.kernel.org/linux-devicetree/20260729064538.19564-3-kaipeng94@gmail.com/
>I have no idea if your "swift SFA14-11" is the same as my "Acer swift
>Go Pro AI".
On the naming: you're right, and thanks for the pointer — the SFA14-11
series was indeed marketed in China as 宏碁非凡 Go Pro AI (my unit is
an SFA14-11-QWU1; the retail listings I found, e.g. on Suning, are other
SKUs like the SFA14-11-QGU1). One thing I noticed though: that retail page
 has since been taken down, and Acer's support sites — global and China
alike [2] — identify the machine as plain "SFA14-11" within the Swift/非凡
series, matching the DMI and the model string shown in Windows. So it
looks like "Swift SFA14-11" is the stable, support-level identity, while
"Go Pro AI" was the transient retail name.

In my series the maintainers asked me to use "acer,swift-sfa14-11";
Ubuntu's stubble has also independently settled on that exact string as
the hwid for this machine [1], so that is the string my series will keep
unless the maintainers reconsider after seeing your evidence — happy to
align either way.

>Currently, the audio of my dts can only work partially.
>I suspect there is something wrong in my ALSA configuration, and
>adding sound-name-prefix
>can improve nothing in my case.
>I still need time to try to solve this problem (also dmic23 / "VA
>DMIC2/3" routing problem
>you point out).
>I notice you list that your audio totally works, if your
>alsa-ucm-config is your customized or
>just using X1E80100-CRD.conf?
I'm using the UCM configuration for this machine from Ratizux's downstream
alsa-ucm-conf tree [3] (small world — your brightness work is based on
their kernel repo [4]). Upstream alsa-ucm-conf doesn't have a profile for
this machine yet, so if your Ubuntu 26.04 doesn't carry one either, that's
likely a good part of your audio issues, on top of the missing
displayport-2 DAI link. It would be nice to coordinate with Ratizux and get
the profile submitted upstream.

On the dmic23 question: the array on my machine is a dual-mic setup next to
the camera — I verified by tap-testing around the chassis (only the camera
area shows mic response), and the VA capture device exposes 2 channels.
The other X1E laptops in tree (T14s, Vivobook, EliteBook, ...) all use
dmic01 only; dmic23 is only wired on the CRD, which made me suspect it was
carried over from the template.

>BTW, could you let me know, how can you know which usb devices use
>which repeater?
The repeater mapping mostly comes from the ThinkPad T14s device tree, which
is the same reference design — it gives the i2c addresses, reset GPIOs and
which hsphy each repeater feeds (0x43/0x47/0x4f on i2c5 with tlmm 7/6/184).
On my board i2cdetect shows the repeaters at 0x47/0x4b/0x4f (the camera's
repeater sits at 0x4b rather than T14s's 0x43), so I kept the T14s mapping
with that one address adjusted, and verified functionally: webcam on usb_2,
USB-A ports on usb_mp. Your UEFI hypothesis sounds right by the way — since
Linux never touches the reset GPIOs when the nodes are absent, chips
initialized by UEFI keep working; describing them is still the correct thing
to do since it makes the boot-to-boot behaviour deterministic.

>It may be an unused USB root hub device, can be found via lsusb or sysfs.
>I didn't verify if there is any device wired to it before.
>I verified after you point out this, and I couldn't find any device is
>wired to it.
>All USB devices I tested still worked when I disabled it.
>If so, I think it could be removed.
>But, I can't confirm if this USB device would be used by SoC internal.
Thanks for checking! On this board the internal devices (webcam, the fingerprint hub) hang off usb_2 and usb_mp, so with nothing answering on ss1 I agree it can be dropped.

Since you're planning to send the next version, I'll keep my series updated in parallel and will of course review yours — I'll leave it to Bjorn and Konrad to pick whichever they prefer. Thanks also for the EL2 notes; I haven't tested that configuration yet and will give it a try with iommu.passthrough=1.

Best regards,
Jianfeng

[1] https://github.com/ubuntu/stubble/blob/main/hwids/json/x1e78100-acer-sfa14-11.json
[2] https://www.acer.com.cn/support.html?type=1
[3] https://github.com/Ratizux/alsa-ucm-conf
[4] https://github.com/Ratizux/linux-device-acer-sfa14-11.git