I hope Qualcomm upstreams all the device tree kernel level stuff to Linux for every laptop model. One of the things I don't like about Arm Laptops is—for example—how even if a SoC is supported upstream, if the manufacturer does not upload a device tree for their device, then you're cooked.
I read that while these Snapdragon laptops do technically have UEFI + ACPI, the information they provide is not useful for Linux and is more coupled with Qualcomm's proprietary drivers on Windows. Therefore, device trees are needed on Linux (I could be wrong about the first part).
> One of the things I don't like about Arm Laptops is—for example—how even if a SoC is supported upstream, if the manufacturer does not upload a device tree for their device, then you're cooked.
Why? Downstream vendor kernels generally use device trees and they can typically be easily extracted and decompiled for cases where the vendor is not GPL compliant and hasn't provided sources.
I've ported arm board device trees to mainline based Linux myself, porting the device tree has not really been the hard part in general...if mainline already has the necessary drivers.
The bigger issue tends to be that vendor kernels have a bunch of drivers that don't have upstream equivalents. I've been porting a lot of Allwinner ARM SoC drivers recently for the purpose of mainlining board support and it has been quite involved as Allwinner downstream kernels very heavily diverge from their mainline equivalent versions and are often based on 10 year old kernels. Even with Allwinner vendor sources(which are typically available in some form from BSP releases floating around on the internet) the drivers typically need to be fully rewritten due to Allwinner doing things in ways that mainline wouldn't accept. Luckily LLM's are quite good at this sort of porting work since they can ingest lots of garbage vendor driver code and create mainline variants(although there's usually substantial review/refactoring needed to get these merged upstream).
Often one also needs to port the drivers to uboot as well, in many cases one can mix a vendor uboot with mainline kernel but that doesn't always work properly(i.e. for Allwinner you generally can't boot a mainline kernel from vendor uboot and need to port uboot as well).
One other issue I've run into is that mainline Linux doesn't have great support for dynamic hardware probing which is often needed when vendors have different minor hardware variants that are all expected to use the same software builds. For example Allwinner on some SoC's will use a different co-packaged EPHY depending on the SoC revision which requires dynamic hardware detection via efuse probing. In other cases one may need to say detect a touchscreen device and driver by probing i2c addresses, mainline Linux has some support for this sort of thing but it's not particularly mature so sometimes one needs to do the hardware detection in uboot and patch or conditionally load device trees and/or device tree overlays which can be a bit involved.
hurricanepootis · · focus · HN ↗
I read that while these Snapdragon laptops do technically have UEFI + ACPI, the information they provide is not useful for Linux and is more coupled with Qualcomm's proprietary drivers on Windows. Therefore, device trees are needed on Linux (I could be wrong about the first part).
jameshilliard · · focus · HN ↗
Why? Downstream vendor kernels generally use device trees and they can typically be easily extracted and decompiled for cases where the vendor is not GPL compliant and hasn't provided sources.
I've ported arm board device trees to mainline based Linux myself, porting the device tree has not really been the hard part in general...if mainline already has the necessary drivers.
The bigger issue tends to be that vendor kernels have a bunch of drivers that don't have upstream equivalents. I've been porting a lot of Allwinner ARM SoC drivers recently for the purpose of mainlining board support and it has been quite involved as Allwinner downstream kernels very heavily diverge from their mainline equivalent versions and are often based on 10 year old kernels. Even with Allwinner vendor sources(which are typically available in some form from BSP releases floating around on the internet) the drivers typically need to be fully rewritten due to Allwinner doing things in ways that mainline wouldn't accept. Luckily LLM's are quite good at this sort of porting work since they can ingest lots of garbage vendor driver code and create mainline variants(although there's usually substantial review/refactoring needed to get these merged upstream).
Often one also needs to port the drivers to uboot as well, in many cases one can mix a vendor uboot with mainline kernel but that doesn't always work properly(i.e. for Allwinner you generally can't boot a mainline kernel from vendor uboot and need to port uboot as well).
One other issue I've run into is that mainline Linux doesn't have great support for dynamic hardware probing which is often needed when vendors have different minor hardware variants that are all expected to use the same software builds. For example Allwinner on some SoC's will use a different co-packaged EPHY depending on the SoC revision which requires dynamic hardware detection via efuse probing. In other cases one may need to say detect a touchscreen device and driver by probing i2c addresses, mainline Linux has some support for this sort of thing but it's not particularly mature so sometimes one needs to do the hardware detection in uboot and patch or conditionally load device trees and/or device tree overlays which can be a bit involved.