Linux Laying Out Guidelines To Avoid Kernel Updates Breaking Firmware Compatibility

[phoronix]

Phoronix: Linux Laying Out Guidelines To Avoid Kernel Updates Breaking Firmware Compatibility

Stemming from my article last week noting how Linux 5.19 Git broke Intel Alder Lake P graphics support due to requiring new firmware while not retaining backwards compatibility with the existing Intel GuC firmware, a solution is still being worked on prior to Linux 5.19 final whether it be a revert or the proposed patch working on GuC v69/70 firmware compatibility. Linux firmware guidelines are also being proposed to ensure kernel developers in the future don't try to break firmware support guarantees...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-No-Firmware-Breakage

[CochainComplex]

Guinness? - ether you are cheating on german beers or its someonelse in the Picture. I would have expected some proper german beer . Or it was by accident cheating because you had been drunk.

[Sonadow]

Linux poseurs are all ready to waste hours working around all kinds of issues that don't exist in Windows, yet can't even be arsed to to run a git pull or git update inside /lib/firmware when installing a kernel that is released every two months.

[Michael]

Guinness? - ether you are cheating on german beers or its someonelse in the Picture. I would have expected some proper german beer

This picture was from like ~2008 First picture that came to mind when thinking about GPU breakage... This was during like the 7800GTX days.

[Developer12]

Interesting that this should also apply to microcode. AMD have been particularly lazy about getting that out the door, with spectre microcode patches that have been shipped to bios vendors but still haven't landed on git in the last 4 years. For the average linux user not so privileged as to have had their motherboard vendor put out a bios update, those CPUs are effectively unpatched.

[Gerhard]

Linux poseurs are all ready to waste hours working around all kinds of issues that don't exist in Windows, yet can't even be arsed to to run a git pull or git update inside /lib/firmware when installing a kernel that is released every two months.

You are assuming Alder Lake has firmware in /lib/firmware. I can't seem to find any documentation indicating that it's loaded from there.

[c117152]

Is this related to why debian doesn't package certain guc 69 blobs* even in the non-free firmware package even years after they were released?

* skl_guc_69.0.3.bin bxt_guc_69.0.3.bin kbl_guc_69.0.3.bin glk_guc_69.0.3.bin kbl_guc_69.0.3.bin kbl_guc_69.0.3.bin cml_guc_69.0.3.bin icl_guc_69.0.3.bin ehl_guc_69.0.3.bin ehl_guc_69.0.3.bin tgl_guc_69.0.3.bin tgl_guc_69.0.3.bin dg1_guc_69.0.3.bin tgl_guc_69.0.3.bin adlp_guc_69.0.3.bin adlp_dmc_ver2_14.bin among others from https://git.kernel.org/pub/scm/linux...it/plain/i915/ that should be in /lib/firmware/i915/ but aren't...

[skeevy420]

Perhaps I'm being too pedantic about the phrasing, but, unlike Michael, I wouldn't use the terms "explicit" and "clearly" to describe that due to it starting off with "should attempt to follow the rules", followed by, "it is suggested that", with the word "should" peppered about. Following that, no actual punishments for breaking the suggestions are given. Ergo, they aren't rules. They're merely suggestions and guidelines. Worst case scenario is some company runs yet another out of tree kernel if they're assholes and don't want to follow the suggestions.

The word "should" outta be changed to "must" throughout the entirety of that and then the beginning tweaked it so it reads "must attempt to follow the rules in good faith". A little bit of "whoopsie" room in case stuff accidentally happens. This needs to be "you must follow this to the best of your abilities" declaration; not a "should follow" loose guideline. I have no desire to set punishments. Probably something that needs to happen on a case-by-case basis.

Don't get me wrong, I totally agree with the spirit of it. I just think it needs to be the spirit of a tiger, not a lamb.

[skeevy420]

Linux poseurs are all ready to waste hours working around all kinds of issues that don't exist in Windows, yet can't even be arsed to to run a git pull or git update inside /lib/firmware when installing a kernel that is released every two months.

Arch or Gentoo type people? Sure. They know what they're getting into.

Some random Ubuntu or Mint user needing a newer kernel for their GPU that's provided by Ubuntu but Ubuntu didn't update their firmware package accordingly so the CPU firmware or something else unrelated messes up? Nah.

Noob using noob distribution following noob distribution help guides and gets bit in the ass? That's on Noob Distribution 22.04.

[oiaohm]

Linux poseurs are all ready to waste hours working around all kinds of issues that don't exist in Windows, yet can't even be arsed to to run a git pull or git update inside /lib/firmware when installing a kernel that is released every two months.

Really read the post again. Firmware in drivers causing particular hardware not to work happens under windows as well. The unwritten rule was first in 1994. To be correct written rule on mailing list over and over again never added into Linux kernel documentation. So putting this rules in documentation is a good thing.

Why these rules exist does AMD/Intel.... make the products user in fact use the answer is in most cases no. You have some other hardware vendor making the devices. So how can AMD or Intel or any vendor exactly be sure that when they make a new firmware update that its not going to have a issue on some bit of hardware user happen to have the answer is they cannot.

Yes it funny that this issue happened that firmware version 69 worked with older kernels and 70 did not. Also to be really fun there turns out to be something fun with 70 there is hardware prior to Alder Lake P that you could optionally turn on GuC that you cannot with version 70 of the firmware but you could with 69. This did lead to the DRM maintainer of the Linux kernel being very upset with the Intel developers when he worked this out as well.

So Sonadow what says that if you download the latest versions of firmware from Linux kernel.org that they will work with your hardware the reality is nothing without these rules. The strict requirement to be able to load older firmware with newer kernels is about dealing with when you hit a hardware/firmware quirk.

Linux users also don't have to put up with a stack of issues that happen under windows either. The reality here is you did not understand the problem and came out insulting.

Sonadow like it or not these proposed rules that new kernel must be able to use old firmware unless maker can document a really serous reason why not absolutely sane. The history of hardware tells as clearly that new firmware no matter how good the maker intentions are does not always work. The requirement to be able to use old version of firmware is so when users hit case of opps the new firmware version does not work with my hardware they are not left having to pick between having hardware functional and having a newer kernel as often.

There is advantage to the Linux model of splinting the firmware from the driver if the rules are obeyed. Because this allows you to update the kernel side driver out of alignment with the hardware firmware driver. There are cases were Linux users are able to keep on using particular hardware with newer version of Linux due to this old rule.

Yes cases that drivers have to be updated for a new version of windows and the firmware is updated so user cannot go to new version of windows because they will lose old hardware does happen. The problem of the firmware exists under windows as well. Yes then you see ODM/vendor unique drivers appear that are basically the new driver with the old firmware.... So fragmented to hell. Linux world 1 driver multi firmware support has been the way. Less drivers to maintain less drivers to validate that someone has not screwed up under the Linux way.

Writing the rules into the Linux kernel documentation will be a really good thing. Not just have being rewritten into the mailing list about once every 3 to 4 years and reverting patches of those who break the rules and have them do their work over.

Sonadow you are kind of right that Linux users have enough issue to deal with. Linux users don't need driver makers screwing them over by breaking backwards firmware compatibility so having problems with old hardware that does not like new firmware being made that in this case you have to choose to use older kernel as fix.