lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1502405652.20268.20.camel@linux.intel.com>
Date:   Thu, 10 Aug 2017 15:54:12 -0700
From:   Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
To:     Mario.Limonciello@...l.com, rjw@...ysocki.net, lenb@...nel.org
Cc:     linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, lukas@...ner.de
Subject: Re: [PATCH v2 2/2] ACPI / Sleep: Check low power idle constraints
 for debug only

On Thu, 2017-08-10 at 22:07 +0000, Mario.Limonciello@...l.com wrote:
> 
> > 
> > 
[...]

> > +
> > +		ret = acpi_device_get_power(adev, &state);
> > +		if (!ret)
> > +			pr_debug("LPI: %s required min power state
> > %d, current
> > power state %d, real power state %d\n",
> > +				 lpi_constraints_table[i].name,
> > +				 lpi_constraints_table[i].min_dsta
> > te,
> > +				 adev->power.state, state);
> Isn't this superfluous to be showing the state returned from
> acpi_device_get_power and
> also probing directly at the state? You can't just rely on the
> information you got
> back from apci_device_get_power?
They can be different as one is real power state and the other is what
was set.
For example on Dell 9365 it shows

[ 1924.393653] LPI: \_SB.PCI0.XHC required min power state 3, current
power state 3, real power state 255 

> 
> > 
> > +
> > +		if (adev->flags.power_manageable && adev-
> > >power.state <
> > +					lpi_constraints_table[i].m
> > in_dstate)
> > +			pr_info("LPI: Constraint [%s] not
> > matched\n",
> > +				 lpi_constraints_table[i].name);
> Similarly here, can't you just compare against &state instead?
> 
The problem then the check will fail for XHCI on Dell 9365. So not
using "state".

Thanks,
Srinivas
> > 
> > +	}
> > +}
> > +
> >  static void acpi_sleep_run_lps0_dsm(unsigned int func)
> >  {
> >  	union acpi_object *out_obj;
> > @@ -729,6 +886,9 @@ static int lps0_device_attach(struct
> > acpi_device *adev,
> >  				  "_DSM function 0 evaluation
> > failed\n");
> >  	}
> >  	ACPI_FREE(out_obj);
> > +
> > +	lpi_device_get_constraints();
> > +
> >  	return 0;
> >  }
> > 
> > @@ -773,6 +933,8 @@ static void acpi_freeze_wake(void)
> >  	 */
> >  	if (acpi_sci_irq_valid() &&
> >  	    !irqd_is_wakeup_armed(irq_get_irq_data(acpi_sci_irq)))
> > {
> > +		if (pm_debug_messages_enabled())
> > +			lpi_check_constraints();
> >  		pm_system_cancel_wakeup();
> >  		s2idle_wakeup = true;
> >  	}
> > --
> > 2.7.5

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ