On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Define and document a SMART_SUSPEND flag to instruct bus types and PM
> domains that the system suspend callbacks provided by the driver can
> cope with
Hi Douglous
2017-10-20 14:06 GMT+09:00 Doug Anderson :
> Hi,
>
> On Wed, Oct 18, 2017 at 9:45 AM, Masahiro Yamada
> wrote:
>> 2017-10-14 3:02 GMT+09:00 Douglas Anderson :
>>> Right now there is a way to add some CFLAGS
Currently, the existing qspinlock implementation will fallback to
test-and-set if the hypervisor has not set the PV_UNHALT flag.
This patch gives the opportunity to guest kernels to select
between test-and-set and the regular queueu fair lock implementation
based on the PV_DEDICATED KVM feature
On Monday, October 23, 2017 6:37:41 PM CEST Ulf Hansson wrote:
> On 19 October 2017 at 01:17, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > The motivation for this change is to provide a way to work around
> > a problem with the
On 16 October 2017 at 03:30, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
> instruct the PM core that it is desirable to leave the device in
> runtime suspend after
On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Move the LPSS-specific code from acpi_lpss_runtime_suspend()
> and acpi_lpss_runtime_resume() into separate functions,
> acpi_lpss_suspend() and acpi_lpss_resume(),
On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The only user of non-empty pcibios_pm_ops is s390 and it only uses
> "noirq" callbacks, so drop the invocations of the other pcibios_pm_ops
> callbacks from the PCI
On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Define and document a SMART_SUSPEND flag to instruct bus types and PM
> domains that the system suspend callbacks provided by the driver can
> cope with
> -Original Message-
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Monday, October 23, 2017 1:00 PM
> To: Limonciello, Mario
> Cc: andriy.shevche...@linux.intel.com; cor...@lwn.net; linux-
> d...@vger.kernel.org;
On Mon, Oct 23, 2017 at 05:46:18PM +, mario.limoncie...@dell.com wrote:
> Mika,
>
> I'm not CC on patch 2/2 of this series (so apologies this probably won't come
> in threaded right), but I
> was curious and reviewed it from the web:
> http://www.spinics.net/lists/linux-doc/msg50034.html
>
Mika,
I'm not CC on patch 2/2 of this series (so apologies this probably won't come
in threaded right), but I
was curious and reviewed it from the web:
http://www.spinics.net/lists/linux-doc/msg50034.html
Are you sure this is true? When I saw this I tried it myself and didn't find
the need
On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Modify i2c-designware-platdrv to set DPM_FLAG_SMART_PREPARE for its
> devices and return 0 from the system suspend ->prepare callback
> if the device has an ACPI
On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Replace the PCI-specific flag PCI_DEV_FLAGS_NEEDS_RESUME with the
> PM core's DPM_FLAG_NEVER_SKIP one everywhere and drop it.
>
> Signed-off-by: Rafael J. Wysocki
On 19 October 2017 at 01:17, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The motivation for this change is to provide a way to work around
> a problem with the direct-complete mechanism used for avoiding
> system suspend/resume handling
Acked-by: Mario Limonciello
> -Original Message-
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Monday, October 23, 2017 4:52 AM
> To: Andy Shevchenko
> Cc: Jonathan Corbet ;
On Sun 22-10-17 17:24:51, David Rientjes wrote:
> On Thu, 19 Oct 2017, Johannes Weiner wrote:
>
> > David would have really liked for this patchset to include knobs to
> > influence how the algorithm picks cgroup victims. The rest of us
> > agreed that this is beyond the scope of these patches,
On Fri, Oct 20, 2017 at 09:49:37PM +0300, Andy Shevchenko wrote:
> WMI is the bus inside kernel, so, we may access the GUID via
> /sys/bus/wmi instead of doing this through /sys/devices path.
>
> Signed-off-by: Andy Shevchenko
Looks reasonable. Adding Mario
On Fri, Oct 20, 2017 at 09:49:38PM +0300, Andy Shevchenko wrote:
> The device will not appear until we rescan the bus.
>
> Signed-off-by: Andy Shevchenko
No, we definitely will not want to do anything like this. The controller
should appear without any action
Did you receive my previous email regarding your family inheritance ?
Andrew.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 22 Oct 2017, Randy Dunlap wrote:
> (2) It wants to preface each "function" in the "art" with ":c:func:" and put
> back-quote marks around each function name, like `finish()`. That makes the
> ASCII art
> unreadable.
>
> I have tried :: by itself and ..
20 matches
Mail list logo