[RFC PATCH 4/6] pci: Add a mutex to pci_dev to protect device state

This adds a pci_dev mutex which will be used to fix a number of races related to the various state bits maintained in that structure. We call it "state_lock" with similarly named accessors to avoid confusion with the pci_dev_lock() which uses the device_lock(). This is a low level mutex meant to

[RFC PATCH 4/6] pci: Add a mutex to pci_dev to protect device state

This adds a pci_dev mutex which will be used to fix a number of races related to the various state bits maintained in that structure. We call it "state_lock" with similarly named accessors to avoid confusion with the pci_dev_lock() which uses the device_lock(). This is a low level mutex meant to

Re: [PATCH] PCI / ACPI / PM: Resume all bridges on suspend-to-RAM

For the record, about the exactness of the patch description. The patch mentions the regression by the commit c62ec4610c40, but it is not the cause of the bug (https://bugzilla.kernel.org/show_bug.cgi?id=20067) reported by me; I reverted c62ec4610c40 on linux-4.17.13, and the bug remained. #

Re: [PATCH] PCI / ACPI / PM: Resume all bridges on suspend-to-RAM

For the record, about the exactness of the patch description. The patch mentions the regression by the commit c62ec4610c40, but it is not the cause of the bug (https://bugzilla.kernel.org/show_bug.cgi?id=20067) reported by me; I reverted c62ec4610c40 on linux-4.17.13, and the bug remained. #

Re: [RESEND PATCH v10 6/6] mm: page_alloc: reduce unnecessary binary search in early_pfn_valid()

Hi Pasha Thanks for the comments On 8/17/2018 9:35 AM, Pasha Tatashin Wrote: > > > On 7/6/18 5:01 AM, Jia He wrote: >> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns >> where possible") optimized the loop in memmap_init_zone(). But there is >> still some room for

Re: [RESEND PATCH v10 6/6] mm: page_alloc: reduce unnecessary binary search in early_pfn_valid()

Hi Pasha Thanks for the comments On 8/17/2018 9:35 AM, Pasha Tatashin Wrote: > > > On 7/6/18 5:01 AM, Jia He wrote: >> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns >> where possible") optimized the loop in memmap_init_zone(). But there is >> still some room for

[RFC PATCH 6/6] pci: Protect is_busmaster using the state lock

This wraps pci_set_master() and pci_clear_master() with the pci_dev state lock. The clearing of is_busmaster in pci_disable_device() is already covered. This also adds a comment explaining why is_busmaster must not be checked in pci_set_master() due to how the power management code uses it.

[RFC PATCH 3/6] pci: Remove priv_flags and use dev->error_state for "disconnected" status

This already represents whether a device is accessible or not, creating a new flag isn't particularly helpful. dev->error_state being an int, assigning it doesn't require an atomic operation per-se. The existing atomic bitop only protects the field, not anything else anyway. Signed-off-by:

[RFC PATCH 6/6] pci: Protect is_busmaster using the state lock

This wraps pci_set_master() and pci_clear_master() with the pci_dev state lock. The clearing of is_busmaster in pci_disable_device() is already covered. This also adds a comment explaining why is_busmaster must not be checked in pci_set_master() due to how the power management code uses it.

[RFC PATCH 3/6] pci: Remove priv_flags and use dev->error_state for "disconnected" status

This already represents whether a device is accessible or not, creating a new flag isn't particularly helpful. dev->error_state being an int, assigning it doesn't require an atomic operation per-se. The existing atomic bitop only protects the field, not anything else anyway. Signed-off-by:

[RFC PATCH v2 3/6] pci: Remove priv_flags and use dev->error_state for "disconnected" status

This already represents whether a device is accessible or not, creating a new flag isn't particularly helpful. dev->error_state being an int, assigning it doesn't require an atomic operation per-se. The existing atomic bitop only protects the field, not anything else anyway. Signed-off-by:

[RFC PATCH v2 3/6] pci: Remove priv_flags and use dev->error_state for "disconnected" status

This already represents whether a device is accessible or not, creating a new flag isn't particularly helpful. dev->error_state being an int, assigning it doesn't require an atomic operation per-se. The existing atomic bitop only protects the field, not anything else anyway. Signed-off-by:

[RFC PATCH 2/6] pci: Set pci_dev->is_added before calling device_add

This re-fixes the bug reported by Hari Vyas after my revert of his commit but in a much simpler way. The main issues is that is_added was being set after the driver got bound and started, and thus setting it could race with other changes to struct pci_dev. This fixes it by setting the flag

[RFC PATCH 2/6] pci: Set pci_dev->is_added before calling device_add

This re-fixes the bug reported by Hari Vyas after my revert of his commit but in a much simpler way. The main issues is that is_added was being set after the driver got bound and started, and thus setting it could race with other changes to struct pci_dev. This fixes it by setting the flag

[RFC PATCH 5/6] pci: Protect the enable/disable state of pci_dev using the state mutex

This protects enable/disable operations using the state mutex to avoid races with, for example, concurrent enables on a bridge. The bus hierarchy is walked first before taking the lock to avoid lock nesting (though it would be ok if we ensured that we always nest them bottom-up, it is better to

[RFC PATCH 5/6] pci: Protect the enable/disable state of pci_dev using the state mutex

This protects enable/disable operations using the state mutex to avoid races with, for example, concurrent enables on a bridge. The bus hierarchy is walked first before taking the lock to avoid lock nesting (though it would be ok if we ensured that we always nest them bottom-up, it is better to

Re: [RFC PATCH 0/6] pci: Rework is_added race fix and address bridge enable races

On Fri, 2018-08-17 at 14:48 +1000, Benjamin Herrenschmidt wrote: > The second part aims at fixing the enable/disable/set_master races, > and does so by providing a framework for future device state locking > issues. > > It introduces a pci_dev->state_mutex which is used at a lower level > than

Re: [RFC PATCH 0/6] pci: Rework is_added race fix and address bridge enable races

On Fri, 2018-08-17 at 14:48 +1000, Benjamin Herrenschmidt wrote: > The second part aims at fixing the enable/disable/set_master races, > and does so by providing a framework for future device state locking > issues. > > It introduces a pci_dev->state_mutex which is used at a lower level > than

linux-next: Tree for Aug 17

Hi all, Please do not add any v4.20 material to your linux-next included branches until after v4.19-rc1 has been released. Changes since 20180816: The ipvs tree gained a conflict against the netfilter tree. The mfd tree gained a conflict against Linus' tree. Non-merge commits (relative

linux-next: Tree for Aug 17

Hi all, Please do not add any v4.20 material to your linux-next included branches until after v4.19-rc1 has been released. Changes since 20180816: The ipvs tree gained a conflict against the netfilter tree. The mfd tree gained a conflict against Linus' tree. Non-merge commits (relative

Re: [RFC PATCH 2/6] pci: Set pci_dev->is_added before calling device_add

s/device_add/device_attach .. ugh. On Fri, 2018-08-17 at 14:48 +1000, Benjamin Herrenschmidt wrote: > This re-fixes the bug reported by Hari Vyas > after my revert of his commit but in a much simpler way. > > The main issues is that is_added was being set after the driver > got bound and

Re: [RFC PATCH 2/6] pci: Set pci_dev->is_added before calling device_add

s/device_add/device_attach .. ugh. On Fri, 2018-08-17 at 14:48 +1000, Benjamin Herrenschmidt wrote: > This re-fixes the bug reported by Hari Vyas > after my revert of his commit but in a much simpler way. > > The main issues is that is_added was being set after the driver > got bound and

Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"

On Fri, 2018-08-17 at 14:48 +1000, Benjamin Herrenschmidt wrote: > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. > > The new pci state mutex provides a simpler way of addressing > this race and avoids the relative includes added to the powerpc > code. Ignore the cset comment, my

Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"

On Fri, 2018-08-17 at 14:48 +1000, Benjamin Herrenschmidt wrote: > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. > > The new pci state mutex provides a simpler way of addressing > this race and avoids the relative includes added to the powerpc > code. Ignore the cset comment, my

[RFC PATCH 0/6] pci: Rework is_added race fix and address bridge enable races

This is really two series but since they conflict a bit separately here they are in one: First we undo the mess of those atomic priv_flags. The atomicity doesn't provide any security since there's no locking against the other state pertaining to those flags, it only protects the flags themselves.

[RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"

This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. The new pci state mutex provides a simpler way of addressing this race and avoids the relative includes added to the powerpc code. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/pci-common.c | 4 +---

[RFC PATCH 0/6] pci: Rework is_added race fix and address bridge enable races

This is really two series but since they conflict a bit separately here they are in one: First we undo the mess of those atomic priv_flags. The atomicity doesn't provide any security since there's no locking against the other state pertaining to those flags, it only protects the flags themselves.

[RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"

This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. The new pci state mutex provides a simpler way of addressing this race and avoids the relative includes added to the powerpc code. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/pci-common.c | 4 +---

[PATCH] faddr2line: fix path name comment

From: Randy Dunlap Fix a source file reference location to the correct path name. Signed-off-by: Randy Dunlap Cc: Josh Poimboeuf --- scripts/faddr2line |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-418.orig/scripts/faddr2line +++ lnx-418/scripts/faddr2line @@ -71,7 +71,7

[PATCH] faddr2line: fix path name comment

From: Randy Dunlap Fix a source file reference location to the correct path name. Signed-off-by: Randy Dunlap Cc: Josh Poimboeuf --- scripts/faddr2line |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-418.orig/scripts/faddr2line +++ lnx-418/scripts/faddr2line @@ -71,7 +71,7

Re: [PATCH] misc: remove meanless null check before kfree

On 2018/8/17 11:24, zhong jiang wrote: > kfree has taken null pointer into account. so check the null pointer > before kfree is meanless. meanless/meaningless. will repost. please ignore the patch, thanks. > Signed-off-by: zhong jiang > --- > drivers/misc/sgi-xp/xpc_partition.c | 3 +-- > 1

Re: [PATCH] misc: remove meanless null check before kfree

On 2018/8/17 11:24, zhong jiang wrote: > kfree has taken null pointer into account. so check the null pointer > before kfree is meanless. meanless/meaningless. will repost. please ignore the patch, thanks. > Signed-off-by: zhong jiang > --- > drivers/misc/sgi-xp/xpc_partition.c | 3 +-- > 1

[PATCH] misc: remove meaningless null check before kfree

kfree has taken null pointer into account. so check the null pointer before kfree is meaningless. Signed-off-by: zhong jiang --- drivers/misc/sgi-xp/xpc_partition.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/misc/sgi-xp/xpc_partition.c

[PATCH] misc: remove meaningless null check before kfree

kfree has taken null pointer into account. so check the null pointer before kfree is meaningless. Signed-off-by: zhong jiang --- drivers/misc/sgi-xp/xpc_partition.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/misc/sgi-xp/xpc_partition.c

Re: [PATCH] drviers: intel_ips: remove the unneeded null pointer check before debugfs_remove_recursive

subect: drviers/drivers will repost, please ingore the patch. Thanks On 2018/8/17 11:31, zhong jiang wrote: > debugfs_remove_recursive has taken the null pointer into account. > just remove the null check before debugfs_remove_recursive. > > Signed-off-by: zhong jiang > --- >

Re: [PATCH] drviers: intel_ips: remove the unneeded null pointer check before debugfs_remove_recursive

subect: drviers/drivers will repost, please ingore the patch. Thanks On 2018/8/17 11:31, zhong jiang wrote: > debugfs_remove_recursive has taken the null pointer into account. > just remove the null check before debugfs_remove_recursive. > > Signed-off-by: zhong jiang > --- >

[PATCH] media: NULL check is meaningless before debugfs_remove_recursive

debugfs_remove_recursive has taken null pointer into account. so remove the unneeded check. Signed-off-by: zhong jiang --- drivers/media/usb/uvc/uvc_debugfs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_debugfs.c

[PATCH] media: NULL check is meaningless before debugfs_remove_recursive

debugfs_remove_recursive has taken null pointer into account. so remove the unneeded check. Signed-off-by: zhong jiang --- drivers/media/usb/uvc/uvc_debugfs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_debugfs.c

[PATCH] drivers: intel_ips: remove the unneeded null pointer check before debugfs_remove_recursive

debugfs_remove_recursive has taken the null pointer into account. just remove the null check before debugfs_remove_recursive. Signed-off-by: zhong jiang --- drivers/platform/x86/intel_ips.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/platform/x86/intel_ips.c

[PATCH] drivers: intel_ips: remove the unneeded null pointer check before debugfs_remove_recursive

debugfs_remove_recursive has taken the null pointer into account. just remove the null check before debugfs_remove_recursive. Signed-off-by: zhong jiang --- drivers/platform/x86/intel_ips.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/platform/x86/intel_ips.c

[PATCH] drviers: intel_ips: remove the unneeded null pointer check before debugfs_remove_recursive

debugfs_remove_recursive has taken the null pointer into account. just remove the null check before debugfs_remove_recursive. Signed-off-by: zhong jiang --- drivers/platform/x86/intel_ips.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/platform/x86/intel_ips.c

Re: [RFC PATCH] pci: Proof of concept at fixing pci_enable_device/bridge races

On Thu, 2018-08-16 at 22:07 -0500, Bjorn Helgaas wrote: > [+cc Srinath, Guenter, Jens, Lukas, Konstantin, Marta, Pierre-Yves] > > On Thu, Aug 16, 2018 at 07:50:13AM +1000, Benjamin Herrenschmidt wrote: > > [Note: This isn't meant to be merged, it need splitting at the very > > least, see below] >

[PATCH] drviers: intel_ips: remove the unneeded null pointer check before debugfs_remove_recursive

debugfs_remove_recursive has taken the null pointer into account. just remove the null check before debugfs_remove_recursive. Signed-off-by: zhong jiang --- drivers/platform/x86/intel_ips.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/platform/x86/intel_ips.c

Re: [RFC PATCH] pci: Proof of concept at fixing pci_enable_device/bridge races

On Thu, 2018-08-16 at 22:07 -0500, Bjorn Helgaas wrote: > [+cc Srinath, Guenter, Jens, Lukas, Konstantin, Marta, Pierre-Yves] > > On Thu, Aug 16, 2018 at 07:50:13AM +1000, Benjamin Herrenschmidt wrote: > > [Note: This isn't meant to be merged, it need splitting at the very > > least, see below] >

[PATCH] misc: remove meanless null check before kfree

kfree has taken null pointer into account. so check the null pointer before kfree is meanless. Signed-off-by: zhong jiang --- drivers/misc/sgi-xp/xpc_partition.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/misc/sgi-xp/xpc_partition.c

[PATCH] misc: remove meanless null check before kfree

kfree has taken null pointer into account. so check the null pointer before kfree is meanless. Signed-off-by: zhong jiang --- drivers/misc/sgi-xp/xpc_partition.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/misc/sgi-xp/xpc_partition.c

Re: Re: [PATCH 1/1] Preventive patch in the proc file-system to handle NULL check.

On Fri, Aug 17, 2018 at 08:51:42AM +0530, Srikanth Korangala Hari wrote: > > Thanks for the patch! Do you have a reproducer or is this theoretical? > > This will affect if it should go to stable or not. > > Dear Luis, this is theoretical as I observed in most of the call's to api - >

Re: Re: [PATCH 1/1] Preventive patch in the proc file-system to handle NULL check.

On Fri, Aug 17, 2018 at 08:51:42AM +0530, Srikanth Korangala Hari wrote: > > Thanks for the patch! Do you have a reproducer or is this theoretical? > > This will affect if it should go to stable or not. > > Dear Luis, this is theoretical as I observed in most of the call's to api - >

RE: Re: [PATCH 1/1] Preventive patch in the proc file-system to handle NULL check.

> It is fine to crash because /proc is not modular. Dear Alexey, this was theoretical solution. If you feel this should crash instead if the call fail's then ignore the patch. Regards, Srikanth  

RE: Re: [PATCH 1/1] Preventive patch in the proc file-system to handle NULL check.

> It is fine to crash because /proc is not modular. Dear Alexey, this was theoretical solution. If you feel this should crash instead if the call fail's then ignore the patch. Regards, Srikanth  

RE: Re: [PATCH 1/1] Preventive patch in the proc file-system to handle NULL check.

> Thanks for the patch! Do you have a reproducer or is this theoretical? > This will affect if it should go to stable or not. Dear Luis, this is theoretical as I observed in most of the call's to api - "proc_mkdir" the NULL check is being done. Hence I thought of adding one here. Regards,

RE: Re: [PATCH 1/1] Preventive patch in the proc file-system to handle NULL check.

> Thanks for the patch! Do you have a reproducer or is this theoretical? > This will affect if it should go to stable or not. Dear Luis, this is theoretical as I observed in most of the call's to api - "proc_mkdir" the NULL check is being done. Hence I thought of adding one here. Regards,

Re: [PATCH] x86/vdso: Fix vDSO build if a retpoline is emitted

On 17/08/2018 5:41 AM, Andy Lutomirski wrote: Currently, if the vDSO ends up containing an indirect branch or call, GCC will emit the "external thunk" style of retpoline, and it will fail to link. Fix it by building the vDSO with inline retpoline thunks. I haven't seen any reports of this

Re: [PATCH] x86/vdso: Fix vDSO build if a retpoline is emitted

On 17/08/2018 5:41 AM, Andy Lutomirski wrote: Currently, if the vDSO ends up containing an indirect branch or call, GCC will emit the "external thunk" style of retpoline, and it will fail to link. Fix it by building the vDSO with inline retpoline thunks. I haven't seen any reports of this

Re: [RFC PATCH] pci: Proof of concept at fixing pci_enable_device/bridge races

[+cc Srinath, Guenter, Jens, Lukas, Konstantin, Marta, Pierre-Yves] On Thu, Aug 16, 2018 at 07:50:13AM +1000, Benjamin Herrenschmidt wrote: > [Note: This isn't meant to be merged, it need splitting at the very > least, see below] > > This is something I cooked up quickly today to test if that

Re: [RFC PATCH] pci: Proof of concept at fixing pci_enable_device/bridge races

[+cc Srinath, Guenter, Jens, Lukas, Konstantin, Marta, Pierre-Yves] On Thu, Aug 16, 2018 at 07:50:13AM +1000, Benjamin Herrenschmidt wrote: > [Note: This isn't meant to be merged, it need splitting at the very > least, see below] > > This is something I cooked up quickly today to test if that

Naléhavá odpověd

-- Pozdravy, Existuje naléhavá záležitost a vzájemná nabídka, kterou bych vám chtěl dát soukromě a já bych ocenil vaši rychlou odpověď zde (xu.shiq...@aol.com) pro další komunikaci. Vyčkejte na rychlou odpověď. Pozdravy,

Naléhavá odpověd

-- Pozdravy, Existuje naléhavá záležitost a vzájemná nabídka, kterou bych vám chtěl dát soukromě a já bych ocenil vaši rychlou odpověď zde (xu.shiq...@aol.com) pro další komunikaci. Vyčkejte na rychlou odpověď. Pozdravy,

Re: [PATCH 0/3] PTI for x86-32 Fixes

On Tue, 2018-08-07 at 12:24 +0200, Joerg Roedel wrote: > Hi, > > here is a small patch-set to fix two small issues in the > PTI implementation for 32 bit x86. The issues are: > > 1) Fix the 32 bit PCID check. I used the wrong > operator there and this caused false-positive >

Naléhavá odpověd

-- Pozdravy, Existuje naléhavá záležitost a vzájemná nabídka, kterou bych vám chtěl dát soukromě a já bych ocenil vaši rychlou odpověď zde (xu.shiq...@aol.com) pro další komunikaci. Vyčkejte na rychlou odpověď. Pozdravy,

Naléhavá odpověd

-- Pozdravy, Existuje naléhavá záležitost a vzájemná nabídka, kterou bych vám chtěl dát soukromě a já bych ocenil vaši rychlou odpověď zde (xu.shiq...@aol.com) pro další komunikaci. Vyčkejte na rychlou odpověď. Pozdravy,

Re: [PATCH 0/3] PTI for x86-32 Fixes

On Tue, 2018-08-07 at 12:24 +0200, Joerg Roedel wrote: > Hi, > > here is a small patch-set to fix two small issues in the > PTI implementation for 32 bit x86. The issues are: > > 1) Fix the 32 bit PCID check. I used the wrong > operator there and this caused false-positive >

Re: [PATCH] x86/mm/pti: Move user W+X check into pti_finalize()

On Wed, 2018-08-08 at 13:16 +0200, Joerg Roedel wrote: > From: Joerg Roedel > > The user page-table gets the updated kernel mappings in > pti_finalize(), which runs after the RO+X permissions got > applied to the kernel page-table in mark_readonly(). > > But with CONFIG_DEBUG_WX enabled, the

Re: [PATCH] x86/mm/pti: Move user W+X check into pti_finalize()

On Wed, 2018-08-08 at 13:16 +0200, Joerg Roedel wrote: > From: Joerg Roedel > > The user page-table gets the updated kernel mappings in > pti_finalize(), which runs after the RO+X permissions got > applied to the kernel page-table in mark_readonly(). > > But with CONFIG_DEBUG_WX enabled, the

[PATCH] kbuild: remove "rpm" target, which is alias of "rpm-pkg"

As commit ebaad7d36406 ("kbuild: rpm: prompt to use "rpm-pkg" if "rpm" target is used") noticed, the "rpm" target is now removed. I assume people have already migrated to "rpm-pkg". Signed-off-by: Masahiro Yamada --- Makefile | 4 1 file changed, 4 deletions(-) diff --git a/Makefile

[PATCH] kbuild: remove "rpm" target, which is alias of "rpm-pkg"

As commit ebaad7d36406 ("kbuild: rpm: prompt to use "rpm-pkg" if "rpm" target is used") noticed, the "rpm" target is now removed. I assume people have already migrated to "rpm-pkg". Signed-off-by: Masahiro Yamada --- Makefile | 4 1 file changed, 4 deletions(-) diff --git a/Makefile

RE: [PATCH V3 0/4] clk: new APIs to handle all available clocks

Hi Stephen, Do you want me to resend this series for review? It seems have been pending for quite a long time. Thor just pinged me for its status as he wants to use it. Regards Dong Aisheng > -Original Message- > From: A.s. Dong > Sent: Wednesday, June 20, 2018 10:54 AM > To:

RE: [PATCH V3 0/4] clk: new APIs to handle all available clocks

Hi Stephen, Do you want me to resend this series for review? It seems have been pending for quite a long time. Thor just pinged me for its status as he wants to use it. Regards Dong Aisheng > -Original Message- > From: A.s. Dong > Sent: Wednesday, June 20, 2018 10:54 AM > To:

Re: Built in PS2 keyboard in new ASUS/acer laptops can not wake up system after s2idle

On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki wrote: >> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the >> keyboard wake up the system as expected. We considered to work out a DMI >> based quirk for this. But based on the information that EC would not signal >>

Re: Built in PS2 keyboard in new ASUS/acer laptops can not wake up system after s2idle

On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki wrote: >> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the >> keyboard wake up the system as expected. We considered to work out a DMI >> based quirk for this. But based on the information that EC would not signal >>

Re: [PATCH] drivers/thermal/tegra: fix a doule free devce node

On 2018/8/14 14:39, Daniel Lezcano wrote: > On 09/08/2018 15:40, zhong jiang wrote: >> Device node iterators will get the return node. Meawhile, It is >> also put the previous device node. An explicit put will cause >> a double put. > What about: > > Subject: drivers/thermal/tegra: Fix a double

Re: [PATCH] drivers/thermal/tegra: fix a doule free devce node

On 2018/8/14 14:39, Daniel Lezcano wrote: > On 09/08/2018 15:40, zhong jiang wrote: >> Device node iterators will get the return node. Meawhile, It is >> also put the previous device node. An explicit put will cause >> a double put. > What about: > > Subject: drivers/thermal/tegra: Fix a double

Re: [PATCHv4 00/12] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems

On Wed, Jul 04, 2018 at 11:17:38AM +0100, Morten Rasmussen wrote: > On asymmetric cpu capacity systems (e.g. Arm big.LITTLE) it is crucial > for performance that cpu intensive tasks are aggressively migrated to > high capacity cpus as soon as those become available. The capacity > awareness tweaks

Re: [PATCHv4 00/12] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems

On Wed, Jul 04, 2018 at 11:17:38AM +0100, Morten Rasmussen wrote: > On asymmetric cpu capacity systems (e.g. Arm big.LITTLE) it is crucial > for performance that cpu intensive tasks are aggressively migrated to > high capacity cpus as soon as those become available. The capacity > awareness tweaks

Re: [PATCH] kconfig: add build-only configurator targets

2018-08-17 1:30 GMT+09:00 Randy Dunlap : > On 08/15/2018 08:27 PM, Masahiro Yamada wrote: >> 2018-08-15 9:36 GMT+09:00 Randy Dunlap : >>> From: Randy Dunlap >>> >>> Add build-only targets for build_menuconfig, build_nconfig, >>> build_xconfig, and build_gconfig. >>> (targets must end in "config"

Re: [PATCH] kconfig: add build-only configurator targets

2018-08-17 1:30 GMT+09:00 Randy Dunlap : > On 08/15/2018 08:27 PM, Masahiro Yamada wrote: >> 2018-08-15 9:36 GMT+09:00 Randy Dunlap : >>> From: Randy Dunlap >>> >>> Add build-only targets for build_menuconfig, build_nconfig, >>> build_xconfig, and build_gconfig. >>> (targets must end in "config"

Re: [PATCH] remoteproc/davinci: Use %zx for formating size_t

On 08/16/2018 07:49 PM, Bjorn Andersson wrote: > da8xx_rproc_mem size is of type size_t, so use %zx to format the debug > print of it to avoid a compile warning. > Thanks for the improvement, Acked-by: Suman Anna > Signed-off-by: Bjorn Andersson > --- > drivers/remoteproc/da8xx_remoteproc.c

Re: [PATCH] remoteproc/davinci: Use %zx for formating size_t

On 08/16/2018 07:49 PM, Bjorn Andersson wrote: > da8xx_rproc_mem size is of type size_t, so use %zx to format the debug > print of it to avoid a compile warning. > Thanks for the improvement, Acked-by: Suman Anna > Signed-off-by: Bjorn Andersson > --- > drivers/remoteproc/da8xx_remoteproc.c

[PATCH V2 1/3] MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms

From: Roy Im This patch adds the da7280 bindings doc and driver to the Dialog Semiconductor support list. Signed-off-by: Roy Im --- v2: No changes MAINTAINERS |2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 544cac8..720f9fe 100644 --- a/MAINTAINERS

[PATCH V2 1/3] MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms

From: Roy Im This patch adds the da7280 bindings doc and driver to the Dialog Semiconductor support list. Signed-off-by: Roy Im --- v2: No changes MAINTAINERS |2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 544cac8..720f9fe 100644 --- a/MAINTAINERS

[PATCH V2 0/3] da7280: haptic driver submission

From: Roy Im This patch adds support for the Dialog DA7280 Haptic driver IC. In this patch set the following is provided: [PATCH V2 1/3] MAINTAINERS file update for DA7280 [PATCH V2 2/3] DA7280 DT Binding [PATCH V2 3/3] DA7280 Driver This patch applies against linux-next and v4.18 Thank you,

[PATCH V2 0/3] da7280: haptic driver submission

From: Roy Im This patch adds support for the Dialog DA7280 Haptic driver IC. In this patch set the following is provided: [PATCH V2 1/3] MAINTAINERS file update for DA7280 [PATCH V2 2/3] DA7280 DT Binding [PATCH V2 3/3] DA7280 Driver This patch applies against linux-next and v4.18 Thank you,

[PATCH V2 3/3] Input: new da7280 haptic driver

from: Roy Im Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple mode and integrated waveform memory and wideband support. It communicates via an I2C bus to the device. Signed-off-by: Roy Im --- v2: Fixed kbuild error/warning drivers/input/misc/Kconfig | 12 +

[PATCH V2 3/3] Input: new da7280 haptic driver

from: Roy Im Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple mode and integrated waveform memory and wideband support. It communicates via an I2C bus to the device. Signed-off-by: Roy Im --- v2: Fixed kbuild error/warning drivers/input/misc/Kconfig | 12 +

[PATCH V2 2/3] Documentation: devicetree: input: new binding for da7280

from: Roy Im Add device tree binding information for DA7280 haptic driver. Example bindings for DA7280 are added. Signed-off-by: Roy Im --- v2: No changes .../devicetree/bindings/input/dlg,da7280.txt | 91 1 file changed, 91 insertions(+) create mode 100644

[PATCH V2 2/3] Documentation: devicetree: input: new binding for da7280

from: Roy Im Add device tree binding information for DA7280 haptic driver. Example bindings for DA7280 are added. Signed-off-by: Roy Im --- v2: No changes .../devicetree/bindings/input/dlg,da7280.txt | 91 1 file changed, 91 insertions(+) create mode 100644

Re: [RESEND PATCH v10 6/6] mm: page_alloc: reduce unnecessary binary search in early_pfn_valid()

On 8/16/18 9:35 PM, Pasha Tatashin wrote: > > > On 7/6/18 5:01 AM, Jia He wrote: >> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns >> where possible") optimized the loop in memmap_init_zone(). But there is >> still some room for improvement. E.g. in early_pfn_valid(),

Re: [RESEND PATCH v10 6/6] mm: page_alloc: reduce unnecessary binary search in early_pfn_valid()

On 8/16/18 9:35 PM, Pasha Tatashin wrote: > > > On 7/6/18 5:01 AM, Jia He wrote: >> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns >> where possible") optimized the loop in memmap_init_zone(). But there is >> still some room for improvement. E.g. in early_pfn_valid(),

Re: [RESEND PATCH v10 6/6] mm: page_alloc: reduce unnecessary binary search in early_pfn_valid()

On 7/6/18 5:01 AM, Jia He wrote: > Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns > where possible") optimized the loop in memmap_init_zone(). But there is > still some room for improvement. E.g. in early_pfn_valid(), if pfn and > pfn+1 are in the same memblock region,

Re: [RESEND PATCH v10 6/6] mm: page_alloc: reduce unnecessary binary search in early_pfn_valid()

On 7/6/18 5:01 AM, Jia He wrote: > Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns > where possible") optimized the loop in memmap_init_zone(). But there is > still some room for improvement. E.g. in early_pfn_valid(), if pfn and > pfn+1 are in the same memblock region,

Re: [RESEND PATCH v10 3/6] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn()

On 8/16/18 9:08 PM, Pavel Tatashin wrote: > >> Signed-off-by: Jia He >> --- >> mm/memblock.c | 37 + >> 1 file changed, 29 insertions(+), 8 deletions(-) >> >> diff --git a/mm/memblock.c b/mm/memblock.c >> index ccad225..84f7fa7 100644 >> --- a/mm/memblock.c

Re: [RESEND PATCH v10 3/6] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn()

On 8/16/18 9:08 PM, Pavel Tatashin wrote: > >> Signed-off-by: Jia He >> --- >> mm/memblock.c | 37 + >> 1 file changed, 29 insertions(+), 8 deletions(-) >> >> diff --git a/mm/memblock.c b/mm/memblock.c >> index ccad225..84f7fa7 100644 >> --- a/mm/memblock.c

Re: [RESEND PATCH v10 3/6] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn()

> Signed-off-by: Jia He > --- > mm/memblock.c | 37 + > 1 file changed, 29 insertions(+), 8 deletions(-) > > diff --git a/mm/memblock.c b/mm/memblock.c > index ccad225..84f7fa7 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -1140,31 +1140,52 @@ int

Re: [RESEND PATCH v10 3/6] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn()

> Signed-off-by: Jia He > --- > mm/memblock.c | 37 + > 1 file changed, 29 insertions(+), 8 deletions(-) > > diff --git a/mm/memblock.c b/mm/memblock.c > index ccad225..84f7fa7 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -1140,31 +1140,52 @@ int

[PATCH] remoteproc/davinci: Use %zx for formating size_t

da8xx_rproc_mem size is of type size_t, so use %zx to format the debug print of it to avoid a compile warning. Signed-off-by: Bjorn Andersson --- drivers/remoteproc/da8xx_remoteproc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/remoteproc/da8xx_remoteproc.c

[PATCH] remoteproc/davinci: Use %zx for formating size_t

da8xx_rproc_mem size is of type size_t, so use %zx to format the debug print of it to avoid a compile warning. Signed-off-by: Bjorn Andersson --- drivers/remoteproc/da8xx_remoteproc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/remoteproc/da8xx_remoteproc.c

linux-next: manual merge of the mfd tree with Linus' tree

Hi all, Today's linux-next merge of the mfd tree got a conflict in: MAINTAINERS between commit: 16b7db4c8150 ("MAINTAINERS: Add .clang-format entry") from Linus' tree and commit: 97c2b5cba204 ("mfd: madera: Add register definitions for Cirrus Logic Madera codecs") from the mfd tree.

linux-next: manual merge of the mfd tree with Linus' tree

Hi all, Today's linux-next merge of the mfd tree got a conflict in: MAINTAINERS between commit: 16b7db4c8150 ("MAINTAINERS: Add .clang-format entry") from Linus' tree and commit: 97c2b5cba204 ("mfd: madera: Add register definitions for Cirrus Logic Madera codecs") from the mfd tree.

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

On Thu, 2018-08-16 at 21:31 +0100, David Howells wrote: > James Bottomley wrote: > > > As a step by step process, I agree.  However, I think we can > > automate it to the point where you install a package and it says > > "insert your yubikey" every time you upgrade the kernel > > That's a very

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

On Thu, 2018-08-16 at 21:31 +0100, David Howells wrote: > James Bottomley wrote: > > > As a step by step process, I agree.  However, I think we can > > automate it to the point where you install a package and it says > > "insert your yubikey" every time you upgrade the kernel > > That's a very

  1   2   3   4   5   6   7   8   9   10   >