On Fri, Nov 09, 2018 at 09:19:52PM -0200, Matheus Tavares Bernardino wrote:
> On Fri, Nov 9, 2018 at 8:13 PM Fabio Estevam wrote:
> >
> > Hi Matheus,
> >
>
> Hi, Fabio
>
> > On Fri, Nov 9, 2018 at 8:01 PM Matheus Tavares
> > wrote:
> > >
> > > This patch adds the SPDX GPL-2.0-only license
On Fri, Nov 09, 2018 at 09:19:52PM -0200, Matheus Tavares Bernardino wrote:
> On Fri, Nov 9, 2018 at 8:13 PM Fabio Estevam wrote:
> >
> > Hi Matheus,
> >
>
> Hi, Fabio
>
> > On Fri, Nov 9, 2018 at 8:01 PM Matheus Tavares
> > wrote:
> > >
> > > This patch adds the SPDX GPL-2.0-only license
Commit f77084d96355 "x86/mm/pat: Disable preemption around
__flush_tlb_all()" addressed a case where __flush_tlb_all() is called
without preemption being disabled. It also left a warning to catch other
cases where preemption is not disabled. That warning triggers for the
memory hotplug path which
Commit f77084d96355 "x86/mm/pat: Disable preemption around
__flush_tlb_all()" addressed a case where __flush_tlb_all() is called
without preemption being disabled. It also left a warning to catch other
cases where preemption is not disabled. That warning triggers for the
memory hotplug path which
On 11/09/2018 04:13 AM, Kirill A. Shutemov wrote:
> On Thu, Nov 08, 2018 at 10:48:58PM -0800, Anthony Yznaga wrote:
>> The basic idea as outlined by Mel Gorman in [2] is:
>>
>> 1) On first fault in a sufficiently sized range, allocate a huge page
>>sized and aligned block of base pages.
On 11/09/2018 04:13 AM, Kirill A. Shutemov wrote:
> On Thu, Nov 08, 2018 at 10:48:58PM -0800, Anthony Yznaga wrote:
>> The basic idea as outlined by Mel Gorman in [2] is:
>>
>> 1) On first fault in a sufficiently sized range, allocate a huge page
>>sized and aligned block of base pages.
Quoting Evan Green (2018-11-09 15:52:12)
> Add the gpio-ranges property to the TLMM node so that GPIO hogs work.
>
> Signed-off-by: Evan Green
> ---
Reviewed-by: Stephen Boyd
Quoting Evan Green (2018-11-09 15:52:12)
> Add the gpio-ranges property to the TLMM node so that GPIO hogs work.
>
> Signed-off-by: Evan Green
> ---
Reviewed-by: Stephen Boyd
Quoting Evan Green (2018-11-09 14:28:35)
> Add PM suspend callbacks to the msm core driver that select the
> sleep and default pinctrl states. Then wire those callbacks up
> in the sdm845 driver, for those boards that may have GPIO hogs
> that need to change state during suspend.
>
>
Quoting Evan Green (2018-11-09 14:28:35)
> Add PM suspend callbacks to the msm core driver that select the
> sleep and default pinctrl states. Then wire those callbacks up
> in the sdm845 driver, for those boards that may have GPIO hogs
> that need to change state during suspend.
>
>
Add the gpio-ranges property to the TLMM node so that GPIO hogs work.
Signed-off-by: Evan Green
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index
Add the gpio-ranges property to the TLMM node so that GPIO hogs work.
Signed-off-by: Evan Green
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index
The lock validator forces to categorize multiple instances of a lock object
as the same lock class because it requires that struct lockdep_map and struct
lock_class_key instances are static objects. This can result in false
positive lockdep reports that are hard to suppress in an elegant way.
Hi Ingo,
As you may know some false positive lockdep reports are the result of the
requirement to associate the same static lockdep key with all instances
of a locking object. Recently I encountered a lockdep false positive for
which I found no elegant way to suppress it other than by modifying
The lock validator forces to categorize multiple instances of a lock object
as the same lock class because it requires that struct lockdep_map and struct
lock_class_key instances are static objects. This can result in false
positive lockdep reports that are hard to suppress in an elegant way.
Hi Ingo,
As you may know some false positive lockdep reports are the result of the
requirement to associate the same static lockdep key with all instances
of a locking object. Recently I encountered a lockdep false positive for
which I found no elegant way to suppress it other than by modifying
Commit 87915adc3f0a ("workqueue: re-add lockdep dependencies for flushing")
improved deadlock checking in the workqueue implementation. Unfortunately
that patch also introduced a few false positive lockdep complaints. This
patch suppresses these false positives by allocating the workqueue mutex
Commit 87915adc3f0a ("workqueue: re-add lockdep dependencies for flushing")
improved deadlock checking in the workqueue implementation. Unfortunately
that patch also introduced a few false positive lockdep complaints. This
patch suppresses these false positives by allocating the workqueue mutex
This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
https://bugzilla.kernel.org/show_bug.cgi?id=200501
It enables the front speakers on Huawei Matebook X Pro laptops.
These laptops come with Dolby Atmos sound system and these pins
configuration enables the front speakers.
On Fri, Nov 09, 2018 at 10:06:31PM +0100, Jann Horn wrote:
> +linux-api for API addition
> +hughd as FYI since this is somewhat related to mm/shmem
>
> On Fri, Nov 9, 2018 at 9:46 PM Joel Fernandes (Google)
> wrote:
> > Android uses ashmem for sharing memory regions. We are looking forward
> >
This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
https://bugzilla.kernel.org/show_bug.cgi?id=200501
It enables the front speakers on Huawei Matebook X Pro laptops.
These laptops come with Dolby Atmos sound system and these pins
configuration enables the front speakers.
On Fri, Nov 09, 2018 at 10:06:31PM +0100, Jann Horn wrote:
> +linux-api for API addition
> +hughd as FYI since this is somewhat related to mm/shmem
>
> On Fri, Nov 9, 2018 at 9:46 PM Joel Fernandes (Google)
> wrote:
> > Android uses ashmem for sharing memory regions. We are looking forward
> >
Some of Huawei laptops come with a LED in the micmute key. This patch
enables and disable this LED accordingly.
This enables micmute LED for:
1. Matebook X (19e5:3200), (19e5:3201)
2. Matebook X Pro (19e5:3204)
Signed-off-by: Ayman Bagabas
---
sound/pci/hda/huawei_wmi_helper.c | 47
On 11/9/18 5:40 PM, Darrick J. Wong wrote:
> On Sat, Nov 10, 2018 at 07:23:01AM +0800, hmsjwzb wrote:
>
> Sorry, but all submissions must have a Signed-off-by: to be reviewed.
>
> Also, there's no To: header on this message??
Also, it's not the only misspelling, and not even the only
Some of Huawei laptops come with a LED in the micmute key. This patch
enables and disable this LED accordingly.
This enables micmute LED for:
1. Matebook X (19e5:3200), (19e5:3201)
2. Matebook X Pro (19e5:3204)
Signed-off-by: Ayman Bagabas
---
sound/pci/hda/huawei_wmi_helper.c | 47
On 11/9/18 5:40 PM, Darrick J. Wong wrote:
> On Sat, Nov 10, 2018 at 07:23:01AM +0800, hmsjwzb wrote:
>
> Sorry, but all submissions must have a Signed-off-by: to be reviewed.
>
> Also, there's no To: header on this message??
Also, it's not the only misspelling, and not even the only
This driver adds support for missing hotkeys on some Huawei laptops.
Currently, only Huawei Matebook X and Matebook X Pro is supported.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/Kconfig | 10 +
drivers/platform/x86/Makefile| 1 +
This driver adds support for missing hotkeys on some Huawei laptops.
Currently, only Huawei Matebook X and Matebook X Pro is supported.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/Kconfig | 10 +
drivers/platform/x86/Makefile| 1 +
Changes from v3:
* Code formatting
Changes from v2:
* Support for Huawei MBX
* Style and formating issues
[PATCH v3 1/3]
The first patch adds support for missing hotkeys on some models.
[PATCH v3 2/3]
This one enables the front speakers on the Huawei Matebook X Pro (MBXP). This
solves bug
Changes from v3:
* Code formatting
Changes from v2:
* Support for Huawei MBX
* Style and formating issues
[PATCH v3 1/3]
The first patch adds support for missing hotkeys on some models.
[PATCH v3 2/3]
This one enables the front speakers on the Huawei Matebook X Pro (MBXP). This
solves bug
On Sat, Nov 10, 2018 at 07:23:01AM +0800, hmsjwzb wrote:
Sorry, but all submissions must have a Signed-off-by: to be reviewed.
Also, there's no To: header on this message??
NAK.
--D
> ---
> fs/xfs/kmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/xfs/kmem.c
On Sat, Nov 10, 2018 at 07:23:01AM +0800, hmsjwzb wrote:
Sorry, but all submissions must have a Signed-off-by: to be reviewed.
Also, there's no To: header on this message??
NAK.
--D
> ---
> fs/xfs/kmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/xfs/kmem.c
On 11/09/2018 03:07 AM, Mel Gorman wrote:
> On Thu, Nov 08, 2018 at 10:48:58PM -0800, Anthony Yznaga wrote:
>> The basic idea as outlined by Mel Gorman in [2] is:
>>
>> 1) On first fault in a sufficiently sized range, allocate a huge page
>>sized and aligned block of base pages. Map the
On 11/09/2018 03:07 AM, Mel Gorman wrote:
> On Thu, Nov 08, 2018 at 10:48:58PM -0800, Anthony Yznaga wrote:
>> The basic idea as outlined by Mel Gorman in [2] is:
>>
>> 1) On first fault in a sufficiently sized range, allocate a huge page
>>sized and aligned block of base pages. Map the
On 2018-11-09 19:52:02 [+0100], Borislav Petkov wrote:
> On Fri, Nov 09, 2018 at 06:35:21PM +0100, Sebastian Andrzej Siewior wrote:
> > fpu__drop() stets ->initialized to 0. As a result the context switch
>
> "... the context switch path landing in switch_fpu_prepare()... " is what you
> mean,
On 2018-11-09 19:52:02 [+0100], Borislav Petkov wrote:
> On Fri, Nov 09, 2018 at 06:35:21PM +0100, Sebastian Andrzej Siewior wrote:
> > fpu__drop() stets ->initialized to 0. As a result the context switch
>
> "... the context switch path landing in switch_fpu_prepare()... " is what you
> mean,
On Sat, 2018-11-10 at 00:10 +0100, Rasmus Villemoes wrote:
> Changes on x86-64 later in this series require that all struct _ddebug
> descriptors in a translation unit uses distinct identifiers. Realize
> that for net_dbg_ratelimited by generating such an identifier via
> __UNIQUE_ID and pass that
---
fs/xfs/kmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c
index fdd9d6ede25c..73ec1f84e591 100644
--- a/fs/xfs/kmem.c
+++ b/fs/xfs/kmem.c
@@ -45,7 +45,7 @@ kmem_alloc_large(size_t size, xfs_km_flags_t flags)
return ptr;
On Sat, 2018-11-10 at 00:10 +0100, Rasmus Villemoes wrote:
> Changes on x86-64 later in this series require that all struct _ddebug
> descriptors in a translation unit uses distinct identifiers. Realize
> that for net_dbg_ratelimited by generating such an identifier via
> __UNIQUE_ID and pass that
---
fs/xfs/kmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c
index fdd9d6ede25c..73ec1f84e591 100644
--- a/fs/xfs/kmem.c
+++ b/fs/xfs/kmem.c
@@ -45,7 +45,7 @@ kmem_alloc_large(size_t size, xfs_km_flags_t flags)
return ptr;
On Mon, Nov 05, 2018 at 09:50:13PM -0800, Bjorn Andersson wrote:
> As of v4.20-rc1 probing the GCC driver on a SDM845 device with the
> standard security implementation causes an access violation and an
> immediate system restart. Use the protected-clocks property to mark the
> offending clocks
On Fri, Nov 9, 2018 at 5:09 PM, Alexander Popov wrote:
>
> On 09.11.2018 23:46, Andy Lutomirski wrote:
>>> On Nov 9, 2018, at 12:06 PM, Jann Horn wrote:
>>>
>>> +Andy, Thomas, Ingo
>>>
On Fri, Nov 9, 2018 at 2:24 PM kernel test robot wrote:
0day kernel testing robot got the below
On Mon, Nov 05, 2018 at 09:50:13PM -0800, Bjorn Andersson wrote:
> As of v4.20-rc1 probing the GCC driver on a SDM845 device with the
> standard security implementation causes an access violation and an
> immediate system restart. Use the protected-clocks property to mark the
> offending clocks
On Fri, Nov 9, 2018 at 5:09 PM, Alexander Popov wrote:
>
> On 09.11.2018 23:46, Andy Lutomirski wrote:
>>> On Nov 9, 2018, at 12:06 PM, Jann Horn wrote:
>>>
>>> +Andy, Thomas, Ingo
>>>
On Fri, Nov 9, 2018 at 2:24 PM kernel test robot wrote:
0day kernel testing robot got the below
On Fri, Nov 9, 2018 at 8:13 PM Fabio Estevam wrote:
>
> Hi Matheus,
>
Hi, Fabio
> On Fri, Nov 9, 2018 at 8:01 PM Matheus Tavares
> wrote:
> >
> > This patch adds the SPDX GPL-2.0-only license identifier to ad2s90.c,
> > which solves the checkpatch.pl warning:
> > "WARNING: Missing or malformed
On Fri, Nov 9, 2018 at 8:13 PM Fabio Estevam wrote:
>
> Hi Matheus,
>
Hi, Fabio
> On Fri, Nov 9, 2018 at 8:01 PM Matheus Tavares
> wrote:
> >
> > This patch adds the SPDX GPL-2.0-only license identifier to ad2s90.c,
> > which solves the checkpatch.pl warning:
> > "WARNING: Missing or malformed
> On Nov 9, 2018, at 2:42 PM, Daniel Colascione wrote:
>
> On Fri, Nov 9, 2018 at 2:37 PM, Andy Lutomirski wrote:
>>> Another, more general fix might be to prevent /proc/pid/fd/N opens
>>> from "upgrading" access modes. But that'd be a bigger ABI break.
>>
>> I think we should fix that,
On Fri, 2018-11-09 at 16:15 -0500, Pavel Tatashin wrote:
> On 18-11-05 13:19:25, Alexander Duyck wrote:
> > This patchset is essentially a refactor of the page initialization logic
> > that is meant to provide for better code reuse while providing a
> > significant improvement in deferred page
> On Nov 9, 2018, at 2:42 PM, Daniel Colascione wrote:
>
> On Fri, Nov 9, 2018 at 2:37 PM, Andy Lutomirski wrote:
>>> Another, more general fix might be to prevent /proc/pid/fd/N opens
>>> from "upgrading" access modes. But that'd be a bigger ABI break.
>>
>> I think we should fix that,
On Fri, 2018-11-09 at 16:15 -0500, Pavel Tatashin wrote:
> On 18-11-05 13:19:25, Alexander Duyck wrote:
> > This patchset is essentially a refactor of the page initialization logic
> > that is meant to provide for better code reuse while providing a
> > significant improvement in deferred page
Changes on x86-64 later in this series require that all struct _ddebug
descriptors in a translation unit uses distinct identifiers. Realize
that for pr_debug_ratelimited by generating such an identifier via
__UNIQUE_ID and pass that to an extra level of macros.
No functional change.
Acked-by:
Changes on x86-64 later in this series require that all struct _ddebug
descriptors in a translation unit uses distinct identifiers. Realize
that for pr_debug_ratelimited by generating such an identifier via
__UNIQUE_ID and pass that to an extra level of macros.
No functional change.
Acked-by:
pr_debug_ratelimited tests the dynamic debug descriptor the old-fashioned
way, and doesn't utilize the static key/jump label implementation on
architectures that HAVE_JUMP_LABEL. Use the DYNAMIC_DEBUG_BRANCH which
is defined appropriately.
Acked-by: Petr Mladek
Acked-by: Jason Baron
Cc: Steven
pr_debug_ratelimited tests the dynamic debug descriptor the old-fashioned
way, and doesn't utilize the static key/jump label implementation on
architectures that HAVE_JUMP_LABEL. Use the DYNAMIC_DEBUG_BRANCH which
is defined appropriately.
Acked-by: Petr Mladek
Acked-by: Jason Baron
Cc: Steven
dev_dbg_ratelimited tests the dynamic debug descriptor the old-fashioned
way, and doesn't utilize the static key/jump label implementation on
architectures that HAVE_JUMP_LABEL. Use the DYNAMIC_DEBUG_BRANCH which
is defined appropriately.
Reviewed-by: Greg Kroah-Hartman
Acked-by: Jason Baron
Changes on x86-64 later in this series require that all struct _ddebug
descriptors in a translation unit uses distinct identifiers. Realize
that for dev_dbg_ratelimited by generating such an identifier via
__UNIQUE_ID and pass that to an extra level of macros.
No functional change.
Reviewed-by:
This started as an experiment to see how hard it would be to change
the four pointers in struct _ddebug into relative offsets, a la
CONFIG_GENERIC_BUG_RELATIVE_POINTERS, thus saving 16 bytes per
pr_debug site (and thus exactly making up for the extra space used by
the introduction of jump labels
Changes on x86-64 later in this series require that all struct _ddebug
descriptors in a translation unit uses distinct identifiers. Realize
that for dev_dbg_ratelimited by generating such an identifier via
__UNIQUE_ID and pass that to an extra level of macros.
No functional change.
Reviewed-by:
This started as an experiment to see how hard it would be to change
the four pointers in struct _ddebug into relative offsets, a la
CONFIG_GENERIC_BUG_RELATIVE_POINTERS, thus saving 16 bytes per
pr_debug site (and thus exactly making up for the extra space used by
the introduction of jump labels
dev_dbg_ratelimited tests the dynamic debug descriptor the old-fashioned
way, and doesn't utilize the static key/jump label implementation on
architectures that HAVE_JUMP_LABEL. Use the DYNAMIC_DEBUG_BRANCH which
is defined appropriately.
Reviewed-by: Greg Kroah-Hartman
Acked-by: Jason Baron
Instead of defining DEFINE_DYNAMIC_DEBUG_METADATA in terms of a helper
DEFINE_DYNAMIC_DEBUG_METADATA_KEY, that needs another helper
dd_key_init to be properly defined, just make the various #ifdef
branches define a _DPRINTK_KEY_INIT that can be used directly, similar
to _DPRINTK_FLAGS_DEFAULT.
For the upcoming 'define the _ddebug descriptor in assembly', we need
all the descriptors in a translation unit to have distinct
names (because asm does not understand C scope). The easiest way to
achieve that is as usual with an extra level of macros, passing the
identifier to use to the
Instead of defining DEFINE_DYNAMIC_DEBUG_METADATA in terms of a helper
DEFINE_DYNAMIC_DEBUG_METADATA_KEY, that needs another helper
dd_key_init to be properly defined, just make the various #ifdef
branches define a _DPRINTK_KEY_INIT that can be used directly, similar
to _DPRINTK_FLAGS_DEFAULT.
For the upcoming 'define the _ddebug descriptor in assembly', we need
all the descriptors in a translation unit to have distinct
names (because asm does not understand C scope). The easiest way to
achieve that is as usual with an extra level of macros, passing the
identifier to use to the
dynamic debug may be implemented via static keys, but ACPI is missing
out on that runtime benefit since it open-codes one possible definition
of DYNAMIC_DEBUG_BRANCH.
Cc: linux-a...@vger.kernel.org
Acked-by: Jason Baron
Acked-by: Rafael J. Wysocki
Signed-off-by: Rasmus Villemoes
---
Now that we store the passed-in string directly in ddebug_add_module, we
can use pointer equality instead of strcmp. This is a little more
efficient, but more importantly, this also makes the code somewhat more
correct:
Currently, if one loads and then unloads a module whose name happens to
match
dynamic debug may be implemented via static keys, but ACPI is missing
out on that runtime benefit since it open-codes one possible definition
of DYNAMIC_DEBUG_BRANCH.
Cc: linux-a...@vger.kernel.org
Acked-by: Jason Baron
Acked-by: Rafael J. Wysocki
Signed-off-by: Rasmus Villemoes
---
Now that we store the passed-in string directly in ddebug_add_module, we
can use pointer equality instead of strcmp. This is a little more
efficient, but more importantly, this also makes the code somewhat more
correct:
Currently, if one loads and then unloads a module whose name happens to
match
This serves two purposes: First, we get a diagnostic if (though
extremely unlikely), any of the calls of ddebug_add_module for built-in
code fails, effectively disabling dynamic_debug. Second, I want to make
struct _ddebug opaque, and avoid accessing any of its members outside
dynamic_debug.[ch].
This serves two purposes: First, we get a diagnostic if (though
extremely unlikely), any of the calls of ddebug_add_module for built-in
code fails, effectively disabling dynamic_debug. Second, I want to make
struct _ddebug opaque, and avoid accessing any of its members outside
dynamic_debug.[ch].
When we introduce compact versions of these pointers (a la
CONFIG_GENERIC_BUG_RELATIVE_POINTERS), all access to these members must
go via appropriate accessors. This just mass-converts dynamic_debug.c to
use the new accessors.
Acked-by: Jason Baron
Signed-off-by: Rasmus Villemoes
---
I'm going to need to refer to the JUMP_TYPE_FALSE and JUMP_TYPE_TRUE
constants from asm code. In order to do that, move them to an
asm-generic header and define them using the UL() helper macro.
Cc: Ingo Molnar
Cc: Jason Baron
Signed-off-by: Rasmus Villemoes
---
With coming changes on x86-64, all dynamic debug descriptors in a
translation unit must have distinct names. The macro _dynamic_func_call
takes care of that. No functional change.
Cc: linux-a...@vger.kernel.org
Acked-by: Rafael J. Wysocki
Acked-by: Jason Baron
Signed-off-by: Rasmus Villemoes
Properly initializing a struct containing bitfields in assembly is
hard. Instead, merge lineno and flags to a single unsigned int, which we
mask manually. This should not cause any worse code than what gcc would
need to generate for accessing the bitfields anyway.
Actually, on 64 bit, there is a
When we introduce compact versions of these pointers (a la
CONFIG_GENERIC_BUG_RELATIVE_POINTERS), all access to these members must
go via appropriate accessors. This just mass-converts dynamic_debug.c to
use the new accessors.
Acked-by: Jason Baron
Signed-off-by: Rasmus Villemoes
---
I'm going to need to refer to the JUMP_TYPE_FALSE and JUMP_TYPE_TRUE
constants from asm code. In order to do that, move them to an
asm-generic header and define them using the UL() helper macro.
Cc: Ingo Molnar
Cc: Jason Baron
Signed-off-by: Rasmus Villemoes
---
With coming changes on x86-64, all dynamic debug descriptors in a
translation unit must have distinct names. The macro _dynamic_func_call
takes care of that. No functional change.
Cc: linux-a...@vger.kernel.org
Acked-by: Rafael J. Wysocki
Acked-by: Jason Baron
Signed-off-by: Rasmus Villemoes
Properly initializing a struct containing bitfields in assembly is
hard. Instead, merge lineno and flags to a single unsigned int, which we
mask manually. This should not cause any worse code than what gcc would
need to generate for accessing the bitfields anyway.
Actually, on 64 bit, there is a
Based on the same idea for struct bug_entry, an architecture can opt-in
to use relative pointers in struct _ddebug. It only makes sense for 64
bit architectures, where one saves 16 bytes per entry (out of 40 or 56,
depending on CONFIG_JUMP_LABEL). The architecture is responsible for
providing a
Similar to how x86_64 uses bug_entry-relative pointers to reduce
sizeof(struct bug_entry), the same thing can now be done for struct
_ddebug, saving 16 bytes for each of those (i.e., each pr_debug, dev_dbg
etc. in a CONFIG_DYNAMIC_DEBUG kernel).
Note the use of .ifndef/.endif in asm to avoid
Similar to how x86_64 uses bug_entry-relative pointers to reduce
sizeof(struct bug_entry), the same thing can now be done for struct
_ddebug, saving 16 bytes for each of those (i.e., each pr_debug, dev_dbg
etc. in a CONFIG_DYNAMIC_DEBUG kernel).
Note the use of .ifndef/.endif in asm to avoid
Based on the same idea for struct bug_entry, an architecture can opt-in
to use relative pointers in struct _ddebug. It only makes sense for 64
bit architectures, where one saves 16 bytes per entry (out of 40 or 56,
depending on CONFIG_JUMP_LABEL). The architecture is responsible for
providing a
These will be useful when defining the contents of (a struct containing)
a static key in assembly.
Cc: x...@kernel.org
Cc: Ingo Molnar
Cc: Jason Baron
Signed-off-by: Rasmus Villemoes
---
arch/x86/include/asm/jump_label.h | 17 +
1 file changed, 17 insertions(+)
diff --git
For symmetry with ddebug_remove_module, and to avoid a bit of ifdeffery
in module.c, move the declaration of ddebug_add_module inside #if
defined(CONFIG_DYNAMIC_DEBUG) and add a corresponding no-op stub in the
#else branch.
Acked-by: Jason Baron
Signed-off-by: Rasmus Villemoes
---
For symmetry with ddebug_remove_module, and to avoid a bit of ifdeffery
in module.c, move the declaration of ddebug_add_module inside #if
defined(CONFIG_DYNAMIC_DEBUG) and add a corresponding no-op stub in the
#else branch.
Acked-by: Jason Baron
Signed-off-by: Rasmus Villemoes
---
These will be useful when defining the contents of (a struct containing)
a static key in assembly.
Cc: x...@kernel.org
Cc: Ingo Molnar
Cc: Jason Baron
Signed-off-by: Rasmus Villemoes
---
arch/x86/include/asm/jump_label.h | 17 +
1 file changed, 17 insertions(+)
diff --git
The only caller of ddebug_{add,remove}_module outside dynamic_debug.c is
kernel/module.c, which is obviously not itself modular (though it would
be an interesting exercise to make that happen...). I also fail to see
how these interfaces can be used by modules, in-tree or not.
Acked-by: Jason
If CONFIG_DYNAMIC_DEBUG is not set, acpi_handle_debug directly invokes
acpi_handle_printk (if DEBUG) or does a no-printk (if !DEBUG). So this
macro is never used.
Cc: linux-a...@vger.kernel.org
Acked-by: Jason Baron
Acked-by: Rafael J. Wysocki
Signed-off-by: Rasmus Villemoes
---
For built-in modules, we're already reusing the passed-in string via
kstrdup_const(). But for actual modules (i.e. when we're called from
dynamic_debug_setup in module.c), the passed-in string (which points
at the name[] array inside struct module) is also
guaranteed to live at least as long as
The only caller of ddebug_{add,remove}_module outside dynamic_debug.c is
kernel/module.c, which is obviously not itself modular (though it would
be an interesting exercise to make that happen...). I also fail to see
how these interfaces can be used by modules, in-tree or not.
Acked-by: Jason
If CONFIG_DYNAMIC_DEBUG is not set, acpi_handle_debug directly invokes
acpi_handle_printk (if DEBUG) or does a no-printk (if !DEBUG). So this
macro is never used.
Cc: linux-a...@vger.kernel.org
Acked-by: Jason Baron
Acked-by: Rafael J. Wysocki
Signed-off-by: Rasmus Villemoes
---
For built-in modules, we're already reusing the passed-in string via
kstrdup_const(). But for actual modules (i.e. when we're called from
dynamic_debug_setup in module.c), the passed-in string (which points
at the name[] array inside struct module) is also
guaranteed to live at least as long as
Hi Naga,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on mtd/nand/next]
[also build test WARNING on v4.20-rc1 next-20181109]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Naga,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on mtd/nand/next]
[also build test WARNING on v4.20-rc1 next-20181109]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
The pull request you sent on Fri, 9 Nov 2018 15:39:43 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> tags/devicetree-fixes-for-4.20-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/aa4330e15c26c5ef8dd184f515c0655db8c6df3a
Thank you!
--
The pull request you sent on Fri, 9 Nov 2018 15:39:43 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> tags/devicetree-fixes-for-4.20-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/aa4330e15c26c5ef8dd184f515c0655db8c6df3a
Thank you!
--
On Fri, Nov 9, 2018 at 3:39 PM Rob Herring wrote:
>
> Devicetree fixes for 4.20-rc:
This pull request should be getting an automated reply once I've
pushed my merge out (soon), so I won't be doing the manual "pulled"
ack emails any more.
If you don't see the automated reply, or you have any
On Fri, Nov 9, 2018 at 3:39 PM Rob Herring wrote:
>
> Devicetree fixes for 4.20-rc:
This pull request should be getting an automated reply once I've
pushed my merge out (soon), so I won't be doing the manual "pulled"
ack emails any more.
If you don't see the automated reply, or you have any
The pull request you sent on Fri, 9 Nov 2018 17:47:55 +0100:
> https://github.com/ceph/ceph-client.git tags/ceph-for-4.20-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d757a3b01e72368176c5ee580ea17f8c2d185cd7
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Fri, 9 Nov 2018 17:47:55 +0100:
> https://github.com/ceph/ceph-client.git tags/ceph-for-4.20-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d757a3b01e72368176c5ee580ea17f8c2d185cd7
Thank you!
--
Deet-doot-dot, I am a bot.
101 - 200 of 1222 matches
Mail list logo
