On Sat, 5 Oct 2024 at 18:27, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > p.s. > > On 5-Oct-24 6:24 PM, Hans de Goede wrote: > > Hi Antheas, > > > > On 5-Oct-24 5:10 PM, Antheas Kapenekakis wrote: > >> Hi Hans, > >> > > <snip> > > >>> IMHO it would be good to submit a v2 of just patches 1 - 3 run through > >>> checkpatch. Also the commit message of patch 3 should point to the existing > >>> quirk code in asus-wmi.c and mention that then is no longer necessary after > >>> patch 3, then we can discuss what is the best place for these quirks. > >> > >> I did run it through before sending the patch. However, some of the > >> warnings were a bit cryptic to me... I will run it again. > >> > >> I will add a note for asus-wmi on future patch series. > >> > >> First 3 patches of the series are designed to NOOP before patch 4. Did > >> you mean patch 3 (which adds the delay) instead of 4? > > > > Ah I misread the series and failed to notice that patch 4 actually hooks > > things up, I was under the impression that patch 4 hooks things up. > > > > But I did mean that patch 3 might lead to discussion not patch 4. > > Oh and upon re-reading the series I see that pathc 5 is just dropping > the quirks from asus-wmi.c, which is fine. > > I somehow thought that the later patches where adding a way for userspace > to already enter the LPS0 display off state earlier. No idea how that > idea got in my head ... Done this way to hopefully be easier to upstream and get this fix out sooner. The plan here would be 3 series: 1) move Display On/Off + quirk, 2) move Sleep Entry/Exit + Quirk, 3) RFC for exposing to userspace, in which case if the kernel starts to suspend while in standby it would skip those calls. Antheas