Mastodawn

Lennart Poettering 2d ago

2️⃣1️⃣ Here's the 21st post highlighting key new features of the recently released v261 release of systemd. #systemd261 #systemd

In the past releases systemd's functionality on TPM-based secure has been growing substantially. One constant pain point of doing hardware and firmware backed security is that hardware and firmware typically sucks. Not necessarily in the specific case, but overall the offerings across the industry are very uneven in quality.

systemd is supposed to be generally useful, …

@z3ntu @valpackett

i.e. this:

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 5ee2bfed0b1d..dfeb63d7428e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -399,9 +399,9 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
                pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
                return ret;
        }

-       if (msm_host->byte_intf_clk) {
+       if (msm_host->byte_intf_clk && !clk_hw_is_enabled(__clk_get_hw(msm_host->byte_clk))) {
                ret = clk_set_rate(msm_host->byte_intf_clk, msm_host->byte_intf_clk_rate);
                if (ret) {
                        pr_err("%s: Failed to set rate byte intf clk, %d\n",
                               __func__, ret);

@z3ntu @valpackett ohhh damn nice!!! that fix looks interesting, i do wonder then if the "correct" fix would be in the clock driver, the rates we set should be the same as the current rate so we shouldn't actually touch the hardware in that case

would be interesting to log all the ops for the pixel/byte/byte_div clocks and see what's happening in CCF.

also i just noticed kodiak has a byte_intf clock, it's parent is the byte_div clock, the parent of that is the byte_src clock, so calling set_rate on the byte clock and then on the byte_intf clock will result in the rates for the byte_src clock being recalculated twice, that could definitely be causing some weirdness

I'd be curious to know if just removing the set_rate call on the byte_intf clock if the byte clock is already enabled would fix the issue

@valpackett yeah it's a shame things are so obscure. honestly i think with a reasonable amount of effort we could start to get a better idea of what the vendor commands do and the capabilities (like i haven't seen anyone trying to parse the device descriptors you can read from the panel)

idk, a productive place to start would be to try and debug the issues with the fairphone 5 where changing the brightness causes corruption in the display xd

pros: learning a lot about Qualcomm's DRM code lately

cons: have to distill said code into something simpler, maintainable, and hopefully expandable for U-Boot

so like, only DSI interface support (for now!), either single or dual "bonded" DSI, and then it gets really fun and messy with Display Stream Compression and weird displays that require a total of 4 DSC sub-blocks running in "merge" mode

So far I have ~300 lines of code that takes a `dpu_resource_request` and returns a `dpu_topology` and it seems to be basically right for at least 1 case XD

@penguin42 @craftyguy @bluca

Honestly I'm not super well-read on LVM, but summarily it would introduce a whole additional wildcard that at least 1 (ideally more) people would need to have a good enough understanding of to maintain and debug it.

Also, we previously used device-mapper directly to access the partitions rather than using loop devices, and it turns out this was causing a bunch of weird issues because device-mapper entries are not technically block devices, so e.g. systemd-repart got very confused about this early on with Duranium.

tl;dr: KISS and just use loop devices

RE: https://fedi.lwn.net/@lwn/116778299228237826

Since forever #postmarketOS has had to rely on various hacky solutions in our custom shell-based initramfs to access the nested GPT which actually contains the root/boot partitions. It's necessary to do this since modifying the partition table on Android phones can very quickly lead to bricks.

However, thanks to this awesome patch by @craftyguy (and @bluca ) in the new Systemd v261 release we no longer need to deal with any of this!

The immutable #Duranium version of postmarketOS runs systemd in the initramfs and it now automatically sets up loop devices for nested partition tables with ZERO additional configuration! (well technically it has been shipping this patch for a little while already :D)

I think I'd cry if I knew how many hours we have collectively spent dealing with weird dumb bugs in the initramfs, so having all of this just be handled by systemd is so SO nice. The value of the event-driven declarative service model really can't be understated imho, especially when it comes to quirky things like loop devices.

https://github.com/systemd/systemd/commit/47d408163b0b71e5f8fed6b2e520c053cefc5780