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

[Antheas Kapenekakis]

On Tue, 29 Sept 2026 at 00:22, Maxim Storetvedt <mstoretv@xxxxxxx> wrote:
>
>
> On 9/28/26 21:09, Antheas Kapenekakis wrote:
> > On Mon, 28 Sept 2026 at 20:41, Maxim Storetvedt <mstoretv@xxxxxxx> wrote:
> >>
> >>
> >> On 9/28/26 18:44, Antheas Kapenekakis wrote:
> >>> On Sun, 20 Sept 2026 at 20:41, Maxim Storetvedt <mstoretv@xxxxxxx> 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@xxxxxxxxxxx/
> >>>
> >>> 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.
>
> Just left as-is as placeholders, but yes, can otherwise be removed.
> Do not really affect anything otherwise.

Unfortunately, there is no such thing as placeholder. When your series
merges it will have no placeholders. Fold the contents of [1] into
this patch for next revision. This node should not be included and is
not used for these devices. This will drop the duplicate battery and
also allow you to drop your external rule.

[1] https://github.com/anatase-org/patchwork/commit/4b9fe35f55c78342b24c2ab309acc8dc38a890cf

> >
> >> 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?
> >
>
> Plenty of old branches here, but README should always be up-to-date with
> links to all the patches used [1]. In this case, we just use the
> existing battery driver by Saddy [2].
>
> > 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.
> >
>
> Thanks for that link! Tested your np940xma.dtb + ene-kb9058 and
> samsung-emuec drivers on top of my tree, and they seem to boot
> fine on my NP940XMA as well. Battery monitoring displayed, and there
> is hotplug detection (for the charger).

Good to know. I will base on your V7 going forward and only do my
changes on top (removing the separate dbts I did thinking there was a
deviation). This will hopefully help you to push this through.

> > 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?
> >
>
> There's an interesting discussion for that here that's worth a look [3]

I had a look. Interesting discussion. So that's where Hans went. Good
to know. Great hire by Qualcomm. I will consider his points and track
followups for ACPI

Best,
Antheas

> Cheers,
> -Max
>
> [1]
> https://github.com/zensanp/linux-book4-edge/blob/x1e80100-book4e-7.2-14-tmp/README.md
> [2] https://github.com/Saddytech/Galaxy-Book4-Edge-linux/tree/main/driver
> [3]
> https://lore.kernel.org/linux-acpi/20260623145225.143218-1-johannes.goede@xxxxxxxxxxxxxxxx/
>
>