Re: [PATCH v7 3/3] arm64: dts: qcom: Add hamoa Samsung Galaxy Book4 Edge devicetrees

[Antheas Kapenekakis <lkml@antheas.dev>]

On Mon, 28 Sept 2026 at 20:41, Maxim Storetvedt <mstoretv@cern.ch> wrote:
>
>
> On 9/28/26 18:44, Antheas Kapenekakis wrote:
> > On Sun, 20 Sept 2026 at 20:41, Maxim Storetvedt <mstoretv@cern.ch> wrote:
> >>
> >> Adds devicetrees for the 14-inch and 16-inch hamoa SKUs of the Samsung Galaxy Book4 Edge.
> >>
> >> These use a common dtsi derived from nodes that were able to work on Linux
> >> from the initial Galaxy Book4 Edge DTS by Marcus:
> >>
> >> Link: https://lore.kernel.org/all/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/
> >>
> >> combined with the patch series the Honor Magicbook Art 14, which shares device similarities:
> >>
> >> Link: https://lore.kernel.org/all/20260629154812.9066-1-mail@etehtsea.me/
> >
> > Links go in the bottom, Based-on-a-patch is not a thing, you may add a
> > Coby as noted in a parallel thread.
> >
> >> as well as a few more adjustments on top of that again to get additional features working.
> >> Special thanks to Jesse Ahn for helping expand on what would eventually become this dtsi.
> >
> > Hi Maxim,
> > I tested this series on a kernel with various other backports on two
> > european (norwegian market) galaxy book4 edges.
> >
> > Specifically, the 14in NP940XMA and the 15.6in (not 16) NP750XQB.
> > Specifically, the later is an X1Plus variant that came out a year
> > later with cheaper components. It does not work properly on either on
> > them. I was hoping that at least the 14in model would work as is but
> > no.
> >
> > My test devices have proprietary Samsung battery controllers
> > (ENE-KB9058) and type C controllers (Samsung EmuEC). Also the speaker
> > amplifiers are different. So the battery reporting, audio, and USB C
> > ports do not work at all using your DTs. The TPM does not bind either
> > but you do not claim that it does. At least they got me to boot and
> > for that I am grateful.
> >
> > Other stuff also does not work, but I am just listing the main ones.
> >
> > I suggest you change the -14/-16 suffixes on both models with
> > something more specific.
> >
> > The prior patches in the series look fine to my eyes. I did not A/B
> > test them, just pulled them in.
> >
> > Best,
> > Antheas
> >
>
> Hi Antheas,
>
> Thanks for giving it a test! I think we both have the (almost) same
> device, and your experience on the 14" NP940XMA (NO) probably mirrors
> that of my NP940XMA (IT).
>
> USB-C should already work for this SKU with the patch DT, but not USB-C
> hotplug (yet). For now, everything is just left as already set up by the
> firmware, so peripherals plugged in after boot will not be detected.
> Everything inserted before boot, and hotplug on USB hubs, should still
> be fine. Could you give it a try on your device?

Yes, that mirrors my experience. But without a TypeC driver you don't
get renegotiation. So no USB3, no fast charging, no hotplugging, and
no DP alt mode. I wrote one but it's still buggy and a bit too
complicated.

> Battery state monitoring should also be with the same caveats on both
> these devices, going via a separate protocol over I2C instead of
> following the other X1Es. There is a separate battery driver for this,
> and also other useful patches (like the webcam and kb backlight)
> downstream. For now at least, only the features listed in the cover are
> included here, but our repo linked there has pointers to the other
> relevant patches needed for now.

I did not find a battery driver so likewise I wrote mine. I think the
battery driver is more upstreamable than the TypeC driver. That will
take a lot of work.

But it also means you have a spurious hunk on your dt then. The hunk
that registers the dead battery and supposedly controls the TypeC
connectors from qualcomm can be removed as it is not present on your
device. It can then be replaced with one that registers the proper
driver later.

> On that topic, you will also find links to devicetrees for the X1P42100
> Book4 Edge there (via Ciscobugger). This might not be the same X1P SKU,
> but could also be worth a try.

I had a quick look at your repo. In my initial attempt, I tried to
reference your upstream (not you) but quickly gave up due to the large
number of commits and dtbs.

I only see a polling commit in your tree after it diverges, I do not
see a battery driver?

I think the only realistic way forward for me is to wait for upstream
to catch up and only add support for my reference devices (the 14 and
15.6) so I can flesh out my userspace until qualcomm starts to deliver
results on mainline kernels.

I attach my current tree below [1], note it is very unclean and I am
currently doing fix commits. Once I get to a place where I am happy
with base functionality, I will squash everything send it as a series.
If you tell me that your device works with the drivers I wrote (note
the LLM assistance), we can synergize. I do not expect the typec
driver to get upstreamed unless someone more familiar with the type c
internals gets involved, as a lot of the changes go over my head. But
I think it is realistic for me to upstream the battery driver, unless
you have a simpler alternative.

the drivers relevant to you are ene-kb9058 and samsung-emuec. If they
work with your laptop and are universal for these devices great. Note
that they are both interrupt based so the battery reporting changes
instantly. You can also take my dt for the 14 in for a spin or just
deploy my tree as a test.

I am contemplating whether an initial series using DTs, then a
follow-up switching to ACPI is simpler for everyone involved. But as I
see the huge amount of dts, I start to get concerned. So I might send
my initial series that enables the device to boot using ACPI instead.
As you know, Windows uses ACPI to boot the device and a lot of the dt
i derived was from the ACPI tables I dumped in Windows. The DT was
important for me to get an initial bring up for the device. I can now
sync kernels to it in ~2 minutes so I can rapidly iterate.

To that end, can anyone tell me why are we not attempting to use ACPI
to boot these devices and relying on DTs on the ARM side? I know that
traditionally for phones DTs are used but these are UEFI devices and
contain proper BIOS data for autodiscovery. What is the current
blocker? Switching to ACPI should let us drop all laptop specific DTs
by adding parsers to their currently DT only drivers. Am I wrong?

Antheas

[1] https://github.com/anatase-org/patchwork/commits/7.2.7-an12

> Cheers,
> -Max