dts: cgroup: remove cgroup_disable=memory parameter

[ferferga]

This was introduced in commit 86099de

In issue #6980, it is commented that appending cgroup_enable=memory fixes the issue. However, as seen in the code changes of the commit, this only works if the kernel in use is Raspberry Pi's own kernel. Kernel from other distros like Ubuntu or Debian doesn't have that patch, so appending cgroup_enable=memory doesn't solve the issue there. I can confirm that compiling this DTB allows Docker to enforce memory limits.

Given distros like Ubuntu or Debian still rely on the .dtb (Debian does it through the raspi-firmware package), I think it's sensible to remove this flag altogether. A few Google searches can be found about this topic and, given Docker is now ubiquituous and commonly used, having to manually adjust this is, in my opinion, more problematic than worth it. Most Raspberry Pis have more than 1 GB now so this argument should be opt-in (not opt-out) by default and can be documented elsewhere in case users want to make the most out of their memory (although, in my opinion, this falls more in the area of micro-optimization with negligible returns).

[pelwell]

The DTBs should be considered to be kernel version-specific. They don't change frequently, but when they do there can be some hard breakages if you're not careful.

Any OS not shipping a kernel built from our branches, which presumably means they will be using an upstream kernel, should not be including our downstream DTBs.

[ferferga]

@pelwell I agree and it seems that I was wrong and Debian doesn't even include those files. Whenever I update the Debian's kernel packages or update-initramfs is run, I manually copy all the files from the original Raspberry Pi OS boot partition (except the vmlinuz*, initrd*, config and cmdline) into my Debian install, so the PoE hat (non Poe+) fan starts working, so probably that's on me and I could go on without the bcm*.dtb files, but I would need further time to investigate this since I'm away.

Regardless of my own situation and 3rd party distros, perhaps this can still be reconsidered? There are plenty of results in Google and forums when searching for the message "Kernel does not support memory limit capabilities" that Docker shows by affected Pi users. Even if memory limit are a niche feature of it, Docker is one of the most widely used software out there and I think it's safe to say that Pi users are probably the most likely to use them due to Pis not having memory to spare.

I cite myself again: I believe this might be an example of micro-optimization with negligible good returns with bigger tradeoffs (affects a widely used software, difficult to debug because the cmdline is injected by a binary whose source needs to be specifically looked for by the user).