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

[Maxim Storetvedt]

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.

> 
>> 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).

> 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]

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/