It is a unified driver for multiple platforms across multiple generations.
So it would be possible* that there are no changes that are relevant to the FW platform after that version.
*: possible. Probable though? Given FW not updating other drivers that do affect existing platforms much and based on the way other OEMs do it: more likely they were tracking a specific bug, and the version they are shipping now is the one that has that fixed. But ignoring other benefits of newer drivers as that would not fix issues that the manufacturers was “tracking” but would require more testing.
I’ve been messing around with the NPU support on Linux (per GitHub - amd/xdna-driver) and had a bear of a time trying to get things working on the 3.03 BIOS - kept running into an apparent memory allocation error (in dmesg) that prevented the NPU from being properly detected/initialized by the system. On a hunch I tried updating to 3.05, and now it works! I’m guessing something changed in the IOMMU apparatus that doesn’t appear in the summary on the first post here…
This checks for an existing /etc/udev/rules.d/20-suspend-fixes.rules file, if none is found, creates it and appends ACTION==“add”, SUBSYSTEM==“serio”, DRIVERS==“atkbd”, ATTR{power/wakeup}=“disabled” to the file.
This hasn’t happened since that time, and I unfortunately had memory dumps disabled at the time. I since have turned them back on in Windows and will definitely submit a support ticket if I see it again.
I don’t know where to ask or whether I should contact support. I recently discovered some minor problem with the PD charging. This problem appears to persist before and after the BIOS/embedded controller update.
When booting up(not restart), the PD charging input will momentarily off right upon pressing the power button before resuming to 20V(or whatever your power brick is doing). Only the FW13 AMD has this problem (IDK whether Intel versions have it too as I don’t have one).
If the computer is switched off(not suspended) for half a day or longer, it won’t charge immediately when plugged in USBC PD, the LED is white and the current flow is 0A. You’ll have to wait for several minute before the current goes to positive and LED turns red.
Other users also discovered the problem, as shown here
Yeah I have the same issue, it repeats that message every 2 seconds. Removing & reinserting the front right expansion card stops it until the next reboot. Setting ‘echo "on" > /sys/bus/pci/devices/0000\:c1\:00.3/power/control’ also works.
I’m running BIOS 3.05, kernel 6.8.5, with a USB A expansion card in the front right slot.
Reporting from Kubuntu 24.04 (6.8.0-22-generic). I had these issues still with kernel 6.8 before the update (different from @Michael_Marley - not sure why, but I’m using KDE Plasma + Wayland + two external 4k displays).
So far everything looks good with sg_display=0 removed here too. I’ve done all the usual things that would trigger it and haven’t been able to replicate except for having it up and running for several days and adding/removing the monitors multiple times during that. (But I have added/removed monitors, slept/woken in different monitor states, etc.) I’ll report back if that changes, but we seem to be having joy here.
FOLLOW-UP
After a weekend of running around with my laptop, all still seems to be good here, so this update may well have solved the sg_display issue!
c || c <- charged from here for bios update
c || a
I’ve noticed today that the back right c port does not charge randomly after resuming from suspend.
The value at that location is currently auto. Curious, could you recommend an easy way to tell which port on the computer correlates to each pci address?
I can’t reproduce this, but the back right is the port I usually use to charge, so I’m sure I’ll see it eventually.
auto just means that power management is handled by the kernel (the default), on means auto power management is disabled (forced on).
I originally used trial and error, e.g removed everything until the errors stopped. But lsusb -v does report the PCI address via the iSerial descriptor, so I mapped them out:
c3:00.4 || c3:00.3
c1:00.3 || c1:00.3
Which is interesting considering the front left and right are on the same bus, but only the right side will produce the error.
I went from 3.03b to 3.05 and I thought that I’m having the same issue, but worse, since I’m using the power-on password. However I managed to figure out that it was one of the two or three passwords that I ended up rotating between (when the password expired), so I ultimately was able to continue booting.
The BIOS reset with the switch did not reset the BIOS for me - or the password. I have now tried it three times. Is this the switch?
I tested with the notebook off and with the expansion card removed, I still am unable to charge from the back right port (#3 from the guide).
Starting to wonder if it’s an issue with either the bios, or maybe the firmware for that controller wasn’t updated in lock step with the bios firmware?
Nah, because it’s the PCI address, not a USB address, and the same USB controller provides both ports (and also the fingerprint reader and bluetooth). AFAIK it’s actually fairly uncommon to have a whole controller dedicated to each port like the ones above, although USB4 is probably the reason why the back 2 ports each have their own controller.
Fedora has started offering me what appears to be this update and a fingerprint reader firmware update unprompted. Is there any particular reason at this date not to just go ahead and let it install them, or is the process still buggy?
