user_fpu_begin() sets fpu_fpregs_owner_ctx to task's fpu struct. This is
always the case since there is no lazy FPU anymore.
fpu_fpregs_owner_ctx is used during context switch to decide if it needs
to load the saved registers or if the currently loaded registers are
valid. This field is always
The preempt_disable() section was introduced in commit a10b6a16cdad8
("x86/fpu: Make the fpu state change in fpu__clear() scheduler-atomic")
and it was said to be temporary.
fpu__initialize() initializes the FPU struct to its "init" value and
then sets ->initialized to 1. The last part is the
The math_emu.h header files contains the definition of struct
math_emu_info. It is not used in this file.
Remove asm/math_emu.h include.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/process_32.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kernel/process_32.c
There are no users of fpu__restore() so it is time to remove it.
The comment regarding fpu__restore() and TS bit is stale since commit
b3b0870ef3ffe ("i387: do not preload FPU state at task switch time") and
has no meaning since.
Signed-off-by: Sebastian Andrzej Siewior
---
There is no user of _TIF_ALLWORK_MASK since commit 21d375b6b34ff
("x86/entry/64: Remove the SYSCALL64 fast path").
Remove unused define _TIF_ALLWORK_MASK.
Reviewed-by: Borislav Petkov
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/thread_info.h | 8
1 file changed,
There is no user of _TIF_ALLWORK_MASK since commit 21d375b6b34ff
("x86/entry/64: Remove the SYSCALL64 fast path").
Remove unused define _TIF_ALLWORK_MASK.
Reviewed-by: Borislav Petkov
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/thread_info.h | 8
1 file changed,
write_pkru() checks if the current value is the same as the expected
value. So instead just checking if the current and new value is zero
(and skip the write in such a case) we can benefit from that.
Remove the zero check of PKRU, write_pkru() provides a similar check.
Signed-off-by: Sebastian
From: Rik van Riel
While most of a task's FPU state is only needed in user space, the
protection keys need to be in place immediately after a context switch.
The reason is that any access to userspace memory while running in
kernel mode also need to abide by the memory permissions specified in
The variable init_pkru_value isn't used outside of this file.
Make init_pkru_value static.
Acked-by: Dave Hansen
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/mm/pkeys.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
index
write_pkru() checks if the current value is the same as the expected
value. So instead just checking if the current and new value is zero
(and skip the write in such a case) we can benefit from that.
Remove the zero check of PKRU, write_pkru() provides a similar check.
Signed-off-by: Sebastian
From: Rik van Riel
While most of a task's FPU state is only needed in user space, the
protection keys need to be in place immediately after a context switch.
The reason is that any access to userspace memory while running in
kernel mode also need to abide by the memory permissions specified in
The variable init_pkru_value isn't used outside of this file.
Make init_pkru_value static.
Acked-by: Dave Hansen
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/mm/pkeys.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
index
During the context switch the xstate is loaded which also includes the
PKRU value.
If xstate is restored on return to userland it is required that the
PKRU value in xstate is the same as the one in the CPU.
Save the PKRU in xstate during modification.
Signed-off-by: Sebastian Andrzej Siewior
Dave Hansen says that the `wrpkru' is more expensive than `rdpkru'. It
has a higher cycle cost and it's also practically a (light) speculation
barrier.
As an optimisation read the current PKRU value and only write the new
one if it is different.
Signed-off-by: Sebastian Andrzej Siewior
---
During the context switch the xstate is loaded which also includes the
PKRU value.
If xstate is restored on return to userland it is required that the
PKRU value in xstate is the same as the one in the CPU.
Save the PKRU in xstate during modification.
Signed-off-by: Sebastian Andrzej Siewior
Dave Hansen says that the `wrpkru' is more expensive than `rdpkru'. It
has a higher cycle cost and it's also practically a (light) speculation
barrier.
As an optimisation read the current PKRU value and only write the new
one if it is different.
Signed-off-by: Sebastian Andrzej Siewior
---
After changing the argument of __raw_xsave_addr() from a mask to number
Dave suggested to check if it makes sense to do the same for
get_xsave_addr(). As it turns out it does. Only get_xsave_addr() needs
the mask to check if the requested feature is part of what is
support/saved and then uses the
Most users of __raw_xsave_addr() use a feature number, shift it to a
mask and then __raw_xsave_addr() shifts it back to the feature number.
Make __raw_xsave_addr() use the feature number as argument.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/xstate.c | 22
After changing the argument of __raw_xsave_addr() from a mask to number
Dave suggested to check if it makes sense to do the same for
get_xsave_addr(). As it turns out it does. Only get_xsave_addr() needs
the mask to check if the requested feature is part of what is
support/saved and then uses the
Most users of __raw_xsave_addr() use a feature number, shift it to a
mask and then __raw_xsave_addr() shifts it back to the feature number.
Make __raw_xsave_addr() use the feature number as argument.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/xstate.c | 22
From: Rik van Riel
copy_fpstate_to_sigframe() stores the registers directly to user space.
This is okay because the FPU register are valid and saving it directly
avoids saving it into kernel memory and making a copy.
However… We can't keep doing this if we are going to restore the FPU
registers
From: Rik van Riel
copy_fpstate_to_sigframe() stores the registers directly to user space.
This is okay because the FPU register are valid and saving it directly
avoids saving it into kernel memory and making a copy.
However… We can't keep doing this if we are going to restore the FPU
registers
On 11/07/2018 08:37 PM, Daniel Mack wrote:
> On 6/11/2018 11:07 PM, Jacek Anaszewski wrote:
>> Switch to using generic LED support for composing LED class
>> device name.
>
> Thanks for the rework!
>
>> Signed-off-by: Jacek Anaszewski
>> ---
>> drivers/leds/leds-lt3593.c | 19
On 11/07/2018 08:37 PM, Daniel Mack wrote:
> On 6/11/2018 11:07 PM, Jacek Anaszewski wrote:
>> Switch to using generic LED support for composing LED class
>> device name.
>
> Thanks for the rework!
>
>> Signed-off-by: Jacek Anaszewski
>> ---
>> drivers/leds/leds-lt3593.c | 19
From: Rik van Riel
Defer loading of FPU state until return to userspace. This gives
the kernel the potential to skip loading FPU state for tasks that
stay in kernel mode, or for tasks that end up with repeated
invocations of kernel_fpu_begin() & kernel_fpu_end().
The
Add TIF_NEED_FPU_LOAD. This is reserved for loading the FPU registers
before returning to userland. This flag must not be set for systems
without a FPU.
If this flag is cleared, the CPU's FPU register hold the current content
of current()'s FPU register. The in-memory copy (union fpregs_state) is
__fpu__restore_sig() restores the CPU's FPU state directly from
userland. If we restore registers on return to userland then we can't
load them directly from userland because a context switch/BH could
destroy them.
Restore the FPU registers after they have been copied from userland.
From: Rik van Riel
The FPU registers need only to be saved if TIF_NEED_FPU_LOAD is not set.
Otherwise this has been already done and can be skipped.
Signed-off-by: Rik van Riel
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/signal.c | 19 ++-
1 file changed,
From: Rik van Riel
Defer loading of FPU state until return to userspace. This gives
the kernel the potential to skip loading FPU state for tasks that
stay in kernel mode, or for tasks that end up with repeated
invocations of kernel_fpu_begin() & kernel_fpu_end().
The
Add TIF_NEED_FPU_LOAD. This is reserved for loading the FPU registers
before returning to userland. This flag must not be set for systems
without a FPU.
If this flag is cleared, the CPU's FPU register hold the current content
of current()'s FPU register. The in-memory copy (union fpregs_state) is
__fpu__restore_sig() restores the CPU's FPU state directly from
userland. If we restore registers on return to userland then we can't
load them directly from userland because a context switch/BH could
destroy them.
Restore the FPU registers after they have been copied from userland.
From: Rik van Riel
The FPU registers need only to be saved if TIF_NEED_FPU_LOAD is not set.
Otherwise this has been already done and can be skipped.
Signed-off-by: Rik van Riel
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/signal.c | 19 ++-
1 file changed,
Since ->initialized is always true for user tasks and kernel threads
don't get this far, we always save the registers directly to userspace.
Remove check for ->initialized because it is always true and remove the
false condition.
Signed-off-by: Sebastian Andrzej Siewior
---
From: Rik van Riel
Add helper function that ensures the floating point registers for
the current task are active. Use with preemption disabled.
Signed-off-by: Rik van Riel
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/fpu/api.h | 11 +++
Since ->initialized is always true for user tasks and kernel threads
don't get this far, we always save the registers directly to userspace.
Remove check for ->initialized because it is always true and remove the
false condition.
Signed-off-by: Sebastian Andrzej Siewior
---
From: Rik van Riel
Add helper function that ensures the floating point registers for
the current task are active. Use with preemption disabled.
Signed-off-by: Rik van Riel
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/fpu/api.h | 11 +++
This is a preparation for the removal of the ->initialized member in the
fpu struct.
__fpu__restore_sig() is deactivating the FPU via fpu__drop() and then
setting manually ->initialized followed by fpu__restore(). The result is
that it is possible to manipulate fpu->state and the state of
This is a preparation for the removal of the ->initialized member in the
fpu struct.
__fpu__restore_sig() is deactivating the FPU via fpu__drop() and then
setting manually ->initialized followed by fpu__restore(). The result is
that it is possible to manipulate fpu->state and the state of
On Wed, 07 Nov 2018 18:10:10 +0100
Thomas Gleixner wrote:
> Mark recently suggested in one of the ksummit discussions to add subsystem
> or tree specific maintainer handbooks to document subsystem/tree specific
> development process information.
>
> The following series adds the general section
On Wed, 07 Nov 2018 18:10:10 +0100
Thomas Gleixner wrote:
> Mark recently suggested in one of the ksummit discussions to add subsystem
> or tree specific maintainer handbooks to document subsystem/tree specific
> development process information.
>
> The following series adds the general section
Hi Yamada-san,
Since commit:
80463f1b7bf9 kbuild: add --include-dir flag only for out-of-tree build
I can no longer run the bindeb-pkg rule. For example:
$ make O=wii ARCH=powerpc wii_defconfig
$ make -j8 O=wii ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- bindeb-pkg
...
WRAP
Hi Yamada-san,
Since commit:
80463f1b7bf9 kbuild: add --include-dir flag only for out-of-tree build
I can no longer run the bindeb-pkg rule. For example:
$ make O=wii ARCH=powerpc wii_defconfig
$ make -j8 O=wii ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- bindeb-pkg
...
WRAP
Hello Tejun,
I've discovered what looks to be a bug in the reporting
of PIDs in the cgroup.procs file in the "domain threaded"
node at the root of a threaded subtree. The following
demo is on vanilla kernel 4.19.
Suppose we have the following multithreaded process:
$ ps -L 654
PID LWP TTY
Hello Tejun,
I've discovered what looks to be a bug in the reporting
of PIDs in the cgroup.procs file in the "domain threaded"
node at the root of a threaded subtree. The following
demo is on vanilla kernel 4.19.
Suppose we have the following multithreaded process:
$ ps -L 654
PID LWP TTY
On Tue, Nov 6, 2018 at 4:17 PM Olof Johansson wrote:
>
> Hi KS organizers (and others),
>
> This is a late topic proposal, hopefully there is still time on the agenda.
>
> We’ve recently been discussing some maintainer model changes as
> described below, and would like a slot to discuss the idea
On Tue, Nov 6, 2018 at 4:17 PM Olof Johansson wrote:
>
> Hi KS organizers (and others),
>
> This is a late topic proposal, hopefully there is still time on the agenda.
>
> We’ve recently been discussing some maintainer model changes as
> described below, and would like a slot to discuss the idea
On Wed, Nov 07, 2018 at 09:32:17AM +0100, Jiri Olsa wrote:
> On Tue, Nov 06, 2018 at 10:13:49PM -0800, David Miller wrote:
> > From: Jiri Olsa
> > Date: Tue, 6 Nov 2018 21:42:55 +0100
> >
> > > I pushed that fix in perf/fixes branch, but I'm still occasionaly
> > > hitting the namespace crash..
On Wed, Nov 07, 2018 at 09:32:17AM +0100, Jiri Olsa wrote:
> On Tue, Nov 06, 2018 at 10:13:49PM -0800, David Miller wrote:
> > From: Jiri Olsa
> > Date: Tue, 6 Nov 2018 21:42:55 +0100
> >
> > > I pushed that fix in perf/fixes branch, but I'm still occasionaly
> > > hitting the namespace crash..
On Wed, Nov 07, 2018 at 06:10:12PM +0100, Thomas Gleixner wrote:
> Add a document to the subsystem/maintainer handbook section, which explains
> what the tip tree is, how it operates and what rules and expectations it
> has.
>
> Signed-off-by: Thomas Gleixner
A few more suggestions below, again
On Wed, Nov 07, 2018 at 06:10:12PM +0100, Thomas Gleixner wrote:
> Add a document to the subsystem/maintainer handbook section, which explains
> what the tip tree is, how it operates and what rules and expectations it
> has.
>
> Signed-off-by: Thomas Gleixner
A few more suggestions below, again
On 6/11/2018 11:07 PM, Jacek Anaszewski wrote:
Switch to using generic LED support for composing LED class
device name.
Thanks for the rework!
Signed-off-by: Jacek Anaszewski
---
drivers/leds/leds-lt3593.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff
On 6/11/2018 11:07 PM, Jacek Anaszewski wrote:
Switch to using generic LED support for composing LED class
device name.
Thanks for the rework!
Signed-off-by: Jacek Anaszewski
---
drivers/leds/leds-lt3593.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff
On 11/1/18 1:02 PM, Florian Fainelli wrote:
> From: Thomas Gleixner
>
> [ Upstream commit 78c9c4dfbf8c04883941445a195276bb4bb92c76 ]
>
> The posix timer overrun handling is broken because the forwarding functions
> can return a huge number of overruns which does not fit in an int. As a
>
On 11/1/18 1:02 PM, Florian Fainelli wrote:
> From: Thomas Gleixner
>
> [ Upstream commit 78c9c4dfbf8c04883941445a195276bb4bb92c76 ]
>
> The posix timer overrun handling is broken because the forwarding functions
> can return a huge number of overruns which does not fit in an int. As a
>
On Fri, Nov 02, 2018 at 12:41:19PM +0100, Anders Roxell wrote:
> In today's merge_config.sh the order of the config fragment files dictates
> the output of a config option. With this approach we will get different
> .config files depending on the order of the config fragment files.
> Adding a
On Fri, Nov 02, 2018 at 12:41:19PM +0100, Anders Roxell wrote:
> In today's merge_config.sh the order of the config fragment files dictates
> the output of a config option. With this approach we will get different
> .config files depending on the order of the config fragment files.
> Adding a
On Wed, Nov 07, 2018 at 05:58:53PM -, David Woodhouse wrote:
>
> > On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse wrote:
> >>
> >> > Yes, this may slow things down. I am not sure I agree with the impl.
> >> > either.
> >> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr
On Wed, Nov 07, 2018 at 05:58:53PM -, David Woodhouse wrote:
>
> > On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse wrote:
> >>
> >> > Yes, this may slow things down. I am not sure I agree with the impl.
> >> > either.
> >> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr
Hi Michal
On 11/07/2018 09:36 AM, Vokáč Michal wrote:
> On 6.11.2018 23:07, Jacek Anaszewski wrote:
>> Add common LED function definitions for use in Device Tree.
>> The function names were extracted from existing dts files
>> after eliminating oddities.
>>
>> Signed-off-by: Jacek Anaszewski
>>
Hi Michal
On 11/07/2018 09:36 AM, Vokáč Michal wrote:
> On 6.11.2018 23:07, Jacek Anaszewski wrote:
>> Add common LED function definitions for use in Device Tree.
>> The function names were extracted from existing dts files
>> after eliminating oddities.
>>
>> Signed-off-by: Jacek Anaszewski
>>
On Wed, Nov 07, 2018 at 10:22:37AM +0800, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/edac/i82975x_edac.c:378:16: warning:
> variable 'dtype' set but not used [-Wunused-but-set-variable]
>
> It never used since introduction in commit
> 084a4fccef39 ("edac:
On Wed, Nov 07, 2018 at 10:22:37AM +0800, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/edac/i82975x_edac.c:378:16: warning:
> variable 'dtype' set but not used [-Wunused-but-set-variable]
>
> It never used since introduction in commit
> 084a4fccef39 ("edac:
ksmd need search stable tree to look for the suitable KSM page, but the
KSM page might be locked for long time due to i.e. KSM page rmap walk.
It sounds not worth waiting for the lock, the page can be skip, then try
to merge it in the next scan to avoid long stall if its content is
still intact.
ksmd need search stable tree to look for the suitable KSM page, but the
KSM page might be locked for long time due to i.e. KSM page rmap walk.
It sounds not worth waiting for the lock, the page can be skip, then try
to merge it in the next scan to avoid long stall if its content is
still intact.
When running some stress test, we ran into the below hung issue
occasionally:
INFO: task ksmd:205 blocked for more than 360 seconds.
Tainted: GE
4.9.128-001.ali3000_nightly_20180925_264.alios7.x86_64 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
When running some stress test, we ran into the below hung issue
occasionally:
INFO: task ksmd:205 blocked for more than 360 seconds.
Tainted: GE
4.9.128-001.ali3000_nightly_20180925_264.alios7.x86_64 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
From: Peter Zijlstra
Sent: November 5, 2018 at 2:09:25 PM GMT
> To: Nadav Amit
> Cc: Ingo Molnar , linux-kernel@vger.kernel.org,
> x...@kernel.org, H. Peter Anvin , Thomas Gleixner
> , Borislav Petkov , Dave Hansen
> , Andy Lutomirski , Kees Cook
> , Dave Hansen , Masami
> Hiramatsu
>
From: Peter Zijlstra
Sent: November 5, 2018 at 2:09:25 PM GMT
> To: Nadav Amit
> Cc: Ingo Molnar , linux-kernel@vger.kernel.org,
> x...@kernel.org, H. Peter Anvin , Thomas Gleixner
> , Borislav Petkov , Dave Hansen
> , Andy Lutomirski , Kees Cook
> , Dave Hansen , Masami
> Hiramatsu
>
Hi Rui,
hi Eduardo,
hi Daniel,
> matthias@kernel.org hat am 21. Oktober 2018 um 23:58 geschrieben:
>
>
> From: Matthias Brugger
>
> By defaul of-based thermal driver do not enable hwmon.
> This patch does this explicitly, so that the temperature can be read
> through the common hwmon
Hi Rui,
hi Eduardo,
hi Daniel,
> matthias@kernel.org hat am 21. Oktober 2018 um 23:58 geschrieben:
>
>
> From: Matthias Brugger
>
> By defaul of-based thermal driver do not enable hwmon.
> This patch does this explicitly, so that the temperature can be read
> through the common hwmon
Quoting Abel Vesa (2018-11-07 03:54:45)
> On Wed, Oct 17, 2018 at 12:55:52PM -0700, Stephen Boyd wrote:
> > Quoting Abel Vesa (2018-09-24 03:39:55)
> > > +static unsigned long clk_pll2_recalc_rate(struct clk_hw *hw,
> > > +unsigned long parent_rate)
> > > +{
Quoting Abel Vesa (2018-11-07 03:54:45)
> On Wed, Oct 17, 2018 at 12:55:52PM -0700, Stephen Boyd wrote:
> > Quoting Abel Vesa (2018-09-24 03:39:55)
> > > +static unsigned long clk_pll2_recalc_rate(struct clk_hw *hw,
> > > +unsigned long parent_rate)
> > > +{
On Wed, Nov 07, 2018 at 07:34:52AM -0800, Sean Christopherson wrote:
> On Tue, Nov 06, 2018 at 05:17:14PM -0800, Andy Lutomirski wrote:
> > On Tue, Nov 6, 2018 at 4:02 PM Sean Christopherson
> > wrote:
> > >
> > > On Tue, Nov 06, 2018 at 03:39:48PM -0800, Andy Lutomirski wrote:
> > > > On Tue,
On Wed, Nov 07, 2018 at 07:34:52AM -0800, Sean Christopherson wrote:
> On Tue, Nov 06, 2018 at 05:17:14PM -0800, Andy Lutomirski wrote:
> > On Tue, Nov 6, 2018 at 4:02 PM Sean Christopherson
> > wrote:
> > >
> > > On Tue, Nov 06, 2018 at 03:39:48PM -0800, Andy Lutomirski wrote:
> > > > On Tue,
Hello,
syzbot found the following crash on:
HEAD commit:8053e5b93eca Merge tag 'trace-v4.20-rc1' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1539246d40
kernel config: https://syzkaller.appspot.com/x/.config?x=8f559fee2fc3375a
Hello,
syzbot found the following crash on:
HEAD commit:8053e5b93eca Merge tag 'trace-v4.20-rc1' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1539246d40
kernel config: https://syzkaller.appspot.com/x/.config?x=8f559fee2fc3375a
On Mon, Nov 05, 2018 at 05:42:42PM -0800, Eric Biggers wrote:
> Hi Corentin,
>
> On Mon, Nov 05, 2018 at 12:51:11PM +, Corentin Labbe wrote:
> > All the 32-bit fields need to be 64-bit. In some cases, UINT32_MAX crypto
> > operations can be done in seconds.
> >
> > Reported-by: Eric Biggers
On Mon, Nov 05, 2018 at 05:42:42PM -0800, Eric Biggers wrote:
> Hi Corentin,
>
> On Mon, Nov 05, 2018 at 12:51:11PM +, Corentin Labbe wrote:
> > All the 32-bit fields need to be 64-bit. In some cases, UINT32_MAX crypto
> > operations can be done in seconds.
> >
> > Reported-by: Eric Biggers
Hello,
syzbot found the following crash on:
HEAD commit:7438a3b20295 kmsan: print user address when reporting info..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=10d782f540
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:7438a3b20295 kmsan: print user address when reporting info..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=10d782f540
kernel config:
From: Logan Gunthorpe
Sent: November 7, 2018 at 6:53:02 PM GMT
> Subject: Re: [PATCH v9 02/10] Makefile: Prepare for using macros for inline
> asm
>
>
>
>
> On 2018-11-07 11:01 a.m., Nadav Amit wrote:
>> Ideas? Do people care about it?
>
> Just spit balling, but is there a reason we didn't
From: Logan Gunthorpe
Sent: November 7, 2018 at 6:53:02 PM GMT
> Subject: Re: [PATCH v9 02/10] Makefile: Prepare for using macros for inline
> asm
>
>
>
>
> On 2018-11-07 11:01 a.m., Nadav Amit wrote:
>> Ideas? Do people care about it?
>
> Just spit balling, but is there a reason we didn't
On 2018-11-07 11:01 a.m., Nadav Amit wrote:
> Ideas? Do people care about it?
Just spit balling, but is there a reason we didn't just put the macros
for inline assembly directly in the header? Something like this:
asm(".macro ANNOTATE_UNREACHABLE counter:req\n\t"
"\\counter:\n\t"
On 2018-11-07 11:01 a.m., Nadav Amit wrote:
> Ideas? Do people care about it?
Just spit balling, but is there a reason we didn't just put the macros
for inline assembly directly in the header? Something like this:
asm(".macro ANNOTATE_UNREACHABLE counter:req\n\t"
"\\counter:\n\t"
On Wed, Nov 7, 2018 at 9:35 AM Olof Johansson wrote:
>
> On Wed, Nov 7, 2018 at 9:17 AM Theodore Y. Ts'o wrote:
> >
> > On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
> > >
> > > Olof Johansson (arm-soc)
> > > Arnd Bergmann (arm-soc)
> > > Kevin Hilman (arm-soc)
> > > Mike
On Wed, Nov 7, 2018 at 9:35 AM Olof Johansson wrote:
>
> On Wed, Nov 7, 2018 at 9:17 AM Theodore Y. Ts'o wrote:
> >
> > On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
> > >
> > > Olof Johansson (arm-soc)
> > > Arnd Bergmann (arm-soc)
> > > Kevin Hilman (arm-soc)
> > > Mike
On Wed, Nov 07, 2018 at 09:35:09AM -0800, Olof Johansson wrote:
>
> Tuesday afternoon looks least conflict-y when I squint at the
> schedule, or Thursday afternoon (but ideally not overlapping with
> Daniel's DRM/gitlab session).
I've posted a draft schedule, so why don't we move the
On Wed, Nov 07, 2018 at 09:35:09AM -0800, Olof Johansson wrote:
>
> Tuesday afternoon looks least conflict-y when I squint at the
> schedule, or Thursday afternoon (but ideally not overlapping with
> Daniel's DRM/gitlab session).
I've posted a draft schedule, so why don't we move the
Previously, all pattern_masks in the chip_info table were hardcoded. Now they
are generated using the PAT macros, as described in the datasheets.
Signed-off-by: Giuliano Belinassi
---
drivers/staging/iio/adc/ad7780.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Previously, all pattern_masks in the chip_info table were hardcoded. Now they
are generated using the PAT macros, as described in the datasheets.
Signed-off-by: Giuliano Belinassi
---
drivers/staging/iio/adc/ad7780.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Only the ad778x have the 'gain' status bit. Check it before updating.
Signed-off-by: Giuliano Belinassi
---
drivers/staging/iio/adc/ad7780.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index
Only the ad778x have the 'gain' status bit. Check it before updating.
Signed-off-by: Giuliano Belinassi
---
drivers/staging/iio/adc/ad7780.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index
This series of patches fixes a bug in ad717x chips where the PAT2 bit
was wrongly read as a GAIN bit. It also refactors the pattern_mask
generation with the PAT bits.
Giuliano Belinassi (3):
staging: iio: ad7780: Add is_ad778x flag chip info
staging: iio: ad7780: check if ad778x before gain
This patch allows further checking of whatever the chip is (ad778x or
ad717x).
Signed-off-by: Giuliano Belinassi
---
drivers/staging/iio/adc/ad7780.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index
This series of patches fixes a bug in ad717x chips where the PAT2 bit
was wrongly read as a GAIN bit. It also refactors the pattern_mask
generation with the PAT bits.
Giuliano Belinassi (3):
staging: iio: ad7780: Add is_ad778x flag chip info
staging: iio: ad7780: check if ad778x before gain
This patch allows further checking of whatever the chip is (ad778x or
ad717x).
Signed-off-by: Giuliano Belinassi
---
drivers/staging/iio/adc/ad7780.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index
On Tue, Nov 06, 2018 at 02:57:40PM +0100, Anders Roxell wrote:
> On Mon, 5 Nov 2018 at 09:35, Masahiro Yamada
> wrote:
> >
> > Hi Anders,
> >
> > On Fri, Nov 2, 2018 at 8:41 PM Anders Roxell
> > wrote:
> > >
> > > In today's merge_config.sh the order of the config fragment files dictates
> > >
On Tue, Nov 06, 2018 at 02:57:40PM +0100, Anders Roxell wrote:
> On Mon, 5 Nov 2018 at 09:35, Masahiro Yamada
> wrote:
> >
> > Hi Anders,
> >
> > On Fri, Nov 2, 2018 at 8:41 PM Anders Roxell
> > wrote:
> > >
> > > In today's merge_config.sh the order of the config fragment files dictates
> > >
On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> On a different tangent: how about the --no-optional-locks (see
> git(1))? Will this get you your "up-to-date" result without writing to
> the .git directory? I've only read the documentation, but not tested
> it.
I think I can add a
On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> On a different tangent: how about the --no-optional-locks (see
> git(1))? Will this get you your "up-to-date" result without writing to
> the .git directory? I've only read the documentation, but not tested
> it.
I think I can add a
601 - 700 of 1460 matches
Mail list logo
