On Sat, 2018-07-07 at 19:24 +0300, Andy Shevchenko wrote: > On Sat, Jul 7, 2018 at 6:48 AM, <Mario.Limonciello@xxxxxxxx> wrote: > > > I strongly advocate for vendors to have more control over their > > > drivers, > > > but this scenario really frustrates me. I don't think I can > > > justify this > > > to Linus as a fix. But before we just say "no" (because hey, I > > > want > > > these fixes available as early as possible too), let's ask Rafael > > > if he > > > has an opinion or if there is precedent for this in his > > > experience with > > > ACPI drivers in general: > > > > Full disclosure - an updated FW has since been rolled out that > > reverted this > > behavior back to previous FW behavior due to lack of Linux support > > for the > > new _DSM. There is desire to use the new interface (as it did fix > > actual > > problems with the old one) so at some point it may return. When > > that happens > > it would be ideal that people who are (for example) running an LTS > > kernel > > or distro kernel that tracks stable can pick it up too. > > I am all for the better user experience and bugs especially in FW > should be fixed, but I think to support all kind of behaviour the new > FW release should always provide a knob by which we can check if some > feature is supported or not. > > Above sounds to me as mistake in design of the fix. The fix here takes care of all the combination. If the new _DSM is available, it checks what functionality the _DSM interface can provide (Fn 0). For those functionality it gets using _DSM matching new FW interface. If there is no _DSM or _DSM doesn't provide the functionality or _DSM provided method fails, it still revert to old FW interface style using standalone method. Eventually because of configurable 5-button array, all platforms will be using new FW interface with consideration of backward compatibility. Thanks, Srinivas
