[AMD Official Use Only] > >>>> On Fri, Feb 25, 2022 at 12:11:11AM -0600, Mario Limonciello wrote: > >>>>> This board definition was originally created for mobile devices to > >>>>> designate default link power managmeent policy to influence runtime > >>>>> power consumption. > >>>>> > >>>>> As this is interesting for more than just mobile designs, rename the > >>>>> board to `board_ahci_low_power` to make it clear it is about default > >>>>> policy. > >>>> > >>>> Is there any good reason to not just apply the policy to all devices > >>>> by default? > >>> > >>> That sure would make this all cleaner. > >>> > >>> I think Hans knows more of the history here than anyone else. I had > >>> presumed there was some data loss scenarios with some of the older > >>> chipsets. > >> > >> When I first introduced this change there were reports of crashes and > >> data corruption caused by setting the policy to min_power, these were > >> tied to some motherboards and/or to some drives. > >> > >> This is the whole reason why I only enabled this on a subset of all the > >> AHCI chipsets. > >> > >> At least on devices with a chipset which is currently marked as > >> mobile, the motherboard specific issues could be fixed with a BIOS > >> update. But I doubt that similar BIOS fixes have also been rolled > >> out to all desktop boards (and have been applied by all users), > >> and I also don't know about older boards. > >> > >> So enabling this on all chipsets is definitely not without risks. > >> > > > > This was before min_power_with_partial and min_power_with_dipm > > were introduced though right? > > The issues where some laptops needed BIOS updates was with fedora > using min_power_with_dipm as default for mobile chipsets. > Do you know if the drives actually supported slumber and partial? I wonder if that was the real problem that they were being set when they shouldn't be. I added something for this in 2/2 in the RFC series you can look at. > > Maybe another way to look at this > > is to drop the policy min_power, which overall is dangerous. > > Maybe, see above. I'm not going to block this if people want > to give this a try, but it is going to require someone keeping > a very close look at any issues popping up and we must be > prepared to roll-back the change if necessary. > Per Paul's suggestion I sent out v3 of this series and then I sent out a separate RFC series (you're on CC). For this type of thing if y'all think it makes sense to do.
