From: Tom Zanussi
Currently, the onmatch action data binds the onmatch action to data
related to synthetic event generation. Since we want to allow the
onmatch handler to potentially invoke a different action, and because
we expect other handlers to generate synthetic events, we need to
From: Tom Zanussi
Hi,
This is v7 of the hist trigger snapshot and onchange additions
patchset. It does a bit of refactoring to address the suggestions
made by Masami in v6.
It also adds an additional patch to update the trigger/inter-event
testcases with SPDX license blurbs.
BTW, I noticed
From: Tom Zanussi
Add a test case for the alternative trace(
---
.../inter-event/trigger-trace-action-hist.tc | 42 ++
1 file changed, 42 insertions(+)
create mode 100644
tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-trace-action-hist.tc
diff
From: Tom Zanussi
Currently, the onmatch action data binds the onmatch action to data
related to synthetic event generation. Since we want to allow the
onmatch handler to potentially invoke a different action, and because
we expect other handlers to generate synthetic events, we need to
From: Tom Zanussi
Hi,
This is v7 of the hist trigger snapshot and onchange additions
patchset. It does a bit of refactoring to address the suggestions
made by Masami in v6.
It also adds an additional patch to update the trigger/inter-event
testcases with SPDX license blurbs.
BTW, I noticed
From: Tom Zanussi
Add a test case for the alternative trace(
---
.../inter-event/trigger-trace-action-hist.tc | 42 ++
1 file changed, 42 insertions(+)
create mode 100644
tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-trace-action-hist.tc
diff
From: Tom Zanussi
The action refactor code allowed actions and handlers to be separated,
but the existing onmax handler and save action code is still not
flexible enough to handle arbitrary coupling. This change generalizes
them and in the process makes additional handlers and actions easier
to
From: Tom Zanussi
Add a test case verifying the basic functionality of the
hist:snapshot() action.
Signed-off-by: Tom Zanussi
---
.../inter-event/trigger-snapshot-action-hist.tc| 43 ++
1 file changed, 43 insertions(+)
create mode 100644
From: Tom Zanussi
Add a test case verifying the basic functionality of the
hist:onchange($var) handler.
Signed-off-by: Tom Zanussi
---
.../inter-event/trigger-onchange-action-hist.tc| 28 ++
1 file changed, 28 insertions(+)
create mode 100644
From: Tom Zanussi
The action refactor code allowed actions and handlers to be separated,
but the existing onmax handler and save action code is still not
flexible enough to handle arbitrary coupling. This change generalizes
them and in the process makes additional handlers and actions easier
to
From: Tom Zanussi
Add a test case verifying the basic functionality of the
hist:snapshot() action.
Signed-off-by: Tom Zanussi
---
.../inter-event/trigger-snapshot-action-hist.tc| 43 ++
1 file changed, 43 insertions(+)
create mode 100644
From: Tom Zanussi
Add a test case verifying the basic functionality of the
hist:onchange($var) handler.
Signed-off-by: Tom Zanussi
---
.../inter-event/trigger-onchange-action-hist.tc| 28 ++
1 file changed, 28 insertions(+)
create mode 100644
From: Tom Zanussi
Add Documentation for the hist:handlerXXX($var).snapshot() action.
Signed-off-by: Tom Zanussi
---
Documentation/trace/histogram.rst | 110 ++
1 file changed, 110 insertions(+)
diff --git a/Documentation/trace/histogram.rst
From: Tom Zanussi
Add Documentation for the hist:handlerXXX($var).snapshot() action.
Signed-off-by: Tom Zanussi
---
Documentation/trace/histogram.rst | 110 ++
1 file changed, 110 insertions(+)
diff --git a/Documentation/trace/histogram.rst
From: Tom Zanussi
Add abbreviated documentation for handlers and actions to README.
Signed-off-by: Tom Zanussi
---
kernel/trace/trace.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index ff1c4b20cd0a..998955dcc3ca
From: Tom Zanussi
Add abbreviated documentation for handlers and actions to README.
Signed-off-by: Tom Zanussi
---
kernel/trace/trace.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index ff1c4b20cd0a..998955dcc3ca
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-4.20-rc3
with top-most commit 017ce359a7187192df5222a00fa3c9055eb3736d
ACPI / PMIC: xpower: fix IOSF_MBI dependency
on top of commit 651022382c7f8da46cb4872a545ee1da6d097d2a
Linux
On Wed, Nov 14, 2018 at 09:12:14PM +0100, Borislav Petkov wrote:
> Hey Konstantin,
>
> that bot needs some parsing improvs: "None None".
Correct, this is because the original pull request was for an ssh://
URL, which I'm not properly handling for the purposes of generating
responses. I will add
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-4.20-rc3
with top-most commit 017ce359a7187192df5222a00fa3c9055eb3736d
ACPI / PMIC: xpower: fix IOSF_MBI dependency
on top of commit 651022382c7f8da46cb4872a545ee1da6d097d2a
Linux
On Wed, Nov 14, 2018 at 09:12:14PM +0100, Borislav Petkov wrote:
> Hey Konstantin,
>
> that bot needs some parsing improvs: "None None".
Correct, this is because the original pull request was for an ssh://
URL, which I'm not properly handling for the purposes of generating
responses. I will add
Hey Konstantin,
that bot needs some parsing improvs: "None None".
On Wed, Nov 14, 2018 at 08:00:03PM +, pr-tracker-...@kernel.org wrote:
> The pull request you sent on Wed, 14 Nov 2018 00:20:10 -0600:
>
> > None None
>
> has been merged into torvalds/linux.git:
>
Hey Konstantin,
that bot needs some parsing improvs: "None None".
On Wed, Nov 14, 2018 at 08:00:03PM +, pr-tracker-...@kernel.org wrote:
> The pull request you sent on Wed, 14 Nov 2018 00:20:10 -0600:
>
> > None None
>
> has been merged into torvalds/linux.git:
>
The pull request you sent on Mon, 12 Nov 2018 17:46:24 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
> parisc-4.20-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/857c34cd094b94a82aceba23fdd9af47296404a2
Thank you!
--
The pull request you sent on Mon, 12 Nov 2018 17:46:24 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
> parisc-4.20-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/857c34cd094b94a82aceba23fdd9af47296404a2
Thank you!
--
The pull request you sent on Wed, 14 Nov 2018 00:20:10 -0600:
> None None
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d41217aac0a577a247c9c8cde688419fde25fba5
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
The pull request you sent on Wed, 14 Nov 2018 00:20:10 -0600:
> None None
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d41217aac0a577a247c9c8cde688419fde25fba5
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
The pull request you sent on Mon, 12 Nov 2018 23:04:54 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git
> tags/rtc-4.20-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b7bbf9935fb793ef8dc42c61a459d74e8606a799
Thank you!
--
Deet-doot-dot,
The pull request you sent on Mon, 12 Nov 2018 09:15:06 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/47e624c03043f544ab797ee073d958cfa57dbf51
Thank you!
--
The pull request you sent on Mon, 12 Nov 2018 23:04:54 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git
> tags/rtc-4.20-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b7bbf9935fb793ef8dc42c61a459d74e8606a799
Thank you!
--
Deet-doot-dot,
The pull request you sent on Mon, 12 Nov 2018 09:15:06 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/47e624c03043f544ab797ee073d958cfa57dbf51
Thank you!
--
On Thu, Nov 15, 2018 at 06:33:21AM +1100, Stephen Rothwell wrote:
> Hi Johan,
>
> Commits
>
> 9ac9252b4bcd ("gnss: sirf: fix synchronous write timeout")
> b1a003961711 ("gnss: serial: fix synchronous write timeout")
>
> are missing a Signed-off-by from their author and committer.
Thanks
On Thu, Nov 15, 2018 at 06:33:21AM +1100, Stephen Rothwell wrote:
> Hi Johan,
>
> Commits
>
> 9ac9252b4bcd ("gnss: sirf: fix synchronous write timeout")
> b1a003961711 ("gnss: serial: fix synchronous write timeout")
>
> are missing a Signed-off-by from their author and committer.
Thanks
Hi Greg,
Please ignore my previous pull request for GNSS fixes and consider this one
instead.
I've now asked Stephen to include the GNSS tree in linux-next, and he
immediately spotted the missing Sign-offs. I was too focused on how best to
split the gnss and serdev patches and handle their
Hi Greg,
Please ignore my previous pull request for GNSS fixes and consider this one
instead.
I've now asked Stephen to include the GNSS tree in linux-next, and he
immediately spotted the missing Sign-offs. I was too focused on how best to
split the gnss and serdev patches and handle their
In automated testing it has been found that on many systems the fsgsbase
test fails intermittently. This was reported and discussed a while
back:
https://lore.kernel.org/lkml/20180126153631.ha7yc33fj5uhitjo@xps/
with the analysis concluding that this is a hardware issue affecting a
subset
In preparation for a change to make this test run repeatedly which
would generate huge amounts of output as is indirect all the printf()
calls in the program through a wrapper and add a quiet flag which can
be used to suppress the output. This is fairly quick and dirty, I'm not
100% sure what
In automated testing it has been found that on many systems the fsgsbase
test fails intermittently. This was reported and discussed a while
back:
https://lore.kernel.org/lkml/20180126153631.ha7yc33fj5uhitjo@xps/
with the analysis concluding that this is a hardware issue affecting a
subset
In preparation for a change to make this test run repeatedly which
would generate huge amounts of output as is indirect all the printf()
calls in the program through a wrapper and add a quiet flag which can
be used to suppress the output. This is fairly quick and dirty, I'm not
100% sure what
This series attempts to make the fsgsbase test in the x86 kselftest
report a stable result. On some Intel systems there are intermittent
failures in this testcase which have been reported and discussed
previously:
https://lore.kernel.org/lkml/20180126153631.ha7yc33fj5uhitjo@xps/
with the
This series attempts to make the fsgsbase test in the x86 kselftest
report a stable result. On some Intel systems there are intermittent
failures in this testcase which have been reported and discussed
previously:
https://lore.kernel.org/lkml/20180126153631.ha7yc33fj5uhitjo@xps/
with the
On Wed, 2018-11-14 at 16:49 +0100, Stefan Agner wrote:
> On 19.10.2018 13:13, Stefan Agner wrote:
> > Reading the full 4k config space through sysfs leads to an
> > external abort. Testing on a platform showed that the upper
> > limit is 512. Limit config space to 512.
>
> Any comment on this
On Wed, 2018-11-14 at 16:49 +0100, Stefan Agner wrote:
> On 19.10.2018 13:13, Stefan Agner wrote:
> > Reading the full 4k config space through sysfs leads to an
> > external abort. Testing on a platform showed that the upper
> > limit is 512. Limit config space to 512.
>
> Any comment on this
On Fri, Apr 20, 2018 at 9:36 PM Rob Herring wrote:
> I share the concern as I doubt most kernel developers don't know
> jsonschema. But then the alternative is us defining and writing our
> own thing which is C like 'cause that's what kernel developers
> understand. My hope is to simplify and
On Fri, Apr 20, 2018 at 9:36 PM Rob Herring wrote:
> I share the concern as I doubt most kernel developers don't know
> jsonschema. But then the alternative is us defining and writing our
> own thing which is C like 'cause that's what kernel developers
> understand. My hope is to simplify and
On Tue, Nov 06, 2018 at 05:35:28PM +0530, Balakrishna Godavarthi wrote:
> [ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
> (-84)
> [ 176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
> (-84)
> [ 176.953298] Bluetooth: hci_qca.c:qca_recv()
On Tue, Nov 06, 2018 at 05:35:28PM +0530, Balakrishna Godavarthi wrote:
> [ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
> (-84)
> [ 176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
> (-84)
> [ 176.953298] Bluetooth: hci_qca.c:qca_recv()
Hi Johan,
Commits
9ac9252b4bcd ("gnss: sirf: fix synchronous write timeout")
b1a003961711 ("gnss: serial: fix synchronous write timeout")
are missing a Signed-off-by from their author and committer.
--
Cheers,
Stephen Rothwell
pgpuxlManY7n2.pgp
Description: OpenPGP digital signature
Hi Johan,
Commits
9ac9252b4bcd ("gnss: sirf: fix synchronous write timeout")
b1a003961711 ("gnss: serial: fix synchronous write timeout")
are missing a Signed-off-by from their author and committer.
--
Cheers,
Stephen Rothwell
pgpuxlManY7n2.pgp
Description: OpenPGP digital signature
Hello Masahiro,
On Tue, 13 Nov 2018, Masahiro Yamada wrote:
Hi Paul,
On Sat, Oct 20, 2018 at 10:21 PM Paul Walmsley wrote:
During development of a serial console driver with a RISC-V toolchain,
the following modpost warning appeared:
WARNING: vmlinux.o(.data+0x19b10): Section
Hello Masahiro,
On Tue, 13 Nov 2018, Masahiro Yamada wrote:
Hi Paul,
On Sat, Oct 20, 2018 at 10:21 PM Paul Walmsley wrote:
During development of a serial console driver with a RISC-V toolchain,
the following modpost warning appeared:
WARNING: vmlinux.o(.data+0x19b10): Section
On Wed 2018-11-14 11:38:19, Andy Shevchenko wrote:
> On Wed, Nov 14, 2018 at 12:05:12AM +0100, Petr Mladek wrote:
> > On Tue 2018-11-13 14:23:17, Steven Rostedt wrote:
> > > On Tue, 13 Nov 2018 13:58:18 -0500
> > > Qian Cai wrote:
> > >
> > > > > Care to print the len and name parameters before
On Wed 2018-11-14 11:38:19, Andy Shevchenko wrote:
> On Wed, Nov 14, 2018 at 12:05:12AM +0100, Petr Mladek wrote:
> > On Tue 2018-11-13 14:23:17, Steven Rostedt wrote:
> > > On Tue, 13 Nov 2018 13:58:18 -0500
> > > Qian Cai wrote:
> > >
> > > > > Care to print the len and name parameters before
Hello,
> > I couldn't reproduce this on a Westmere. Are you sure you're testing
> > a clean compilation? Can you bisect the kernel?
I don't do a make clean normally, but I will do it this time when
bisecting, also I only use shallow
clones so it will also take some time pulling. Also to note,
Hello,
> > I couldn't reproduce this on a Westmere. Are you sure you're testing
> > a clean compilation? Can you bisect the kernel?
I don't do a make clean normally, but I will do it this time when
bisecting, also I only use shallow
clones so it will also take some time pulling. Also to note,
On 18-11-13 12:03:10, Arun KS wrote:
> Now that totalram_pages and managed_pages are atomic varibles, no need
> of managed_page_count spinlock. The lock had really a weak consistency
> guarantee. It hasn't been used for anything but the update but no reader
> actually cares about all the values
On Wed, Nov 7, 2018 at 5:52 PM, Mark Rutland wrote:
> Hi Andrey,
>
> On Tue, Nov 06, 2018 at 06:30:23PM +0100, Andrey Konovalov wrote:
>> __kimg_to_phys (which is used by virt_to_phys) and _virt_addr_is_linear
>> (which is used by virt_addr_valid) assume that the top byte of the address
>> is
On 18-11-13 12:03:10, Arun KS wrote:
> Now that totalram_pages and managed_pages are atomic varibles, no need
> of managed_page_count spinlock. The lock had really a weak consistency
> guarantee. It hasn't been used for anything but the update but no reader
> actually cares about all the values
On Wed, Nov 7, 2018 at 5:52 PM, Mark Rutland wrote:
> Hi Andrey,
>
> On Tue, Nov 06, 2018 at 06:30:23PM +0100, Andrey Konovalov wrote:
>> __kimg_to_phys (which is used by virt_to_phys) and _virt_addr_is_linear
>> (which is used by virt_addr_valid) assume that the top byte of the address
>> is
On 18-11-13 12:03:09, Arun KS wrote:
> totalram_pages and totalhigh_pages are made static inline function.
>
> Main motivation was that managed_page_count_lock handling was
> complicating things. It was discussed in lenght here,
> https://lore.kernel.org/patchwork/patch/995739/#1181785
> So it
On 18-11-13 12:03:09, Arun KS wrote:
> totalram_pages and totalhigh_pages are made static inline function.
>
> Main motivation was that managed_page_count_lock handling was
> complicating things. It was discussed in lenght here,
> https://lore.kernel.org/patchwork/patch/995739/#1181785
> So it
On 18-11-13 12:03:08, Arun KS wrote:
> totalram_pages, zone->managed_pages and totalhigh_pages updates
> are protected by managed_page_count_lock, but readers never care
> about it. Convert these variables to atomic to avoid readers
> potentially seeing a store tear.
>
> This patch converts
On 18-11-13 12:03:08, Arun KS wrote:
> totalram_pages, zone->managed_pages and totalhigh_pages updates
> are protected by managed_page_count_lock, but readers never care
> about it. Convert these variables to atomic to avoid readers
> potentially seeing a store tear.
>
> This patch converts
On 18-11-13 12:03:07, Arun KS wrote:
> This patch is in preparation to a later patch which converts totalram_pages
> and zone->managed_pages to atomic variables. Please note that re-reading
> the value might lead to a different value and as such it could lead to
> unexpected behavior. There are no
On 18-11-13 12:03:07, Arun KS wrote:
> This patch is in preparation to a later patch which converts totalram_pages
> and zone->managed_pages to atomic variables. Please note that re-reading
> the value might lead to a different value and as such it could lead to
> unexpected behavior. There are no
Lubomir Rintel writes:
> A careless oversight. Sorry.
>
> Fixes: 0a897143b7c9 ("spi: pxa2xx: Add slave mode support")
> Signed-off-by: Lubomir Rintel
> ---
> drivers/spi/spi-pxa2xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-pxa2xx.c
Lubomir Rintel writes:
> A careless oversight. Sorry.
>
> Fixes: 0a897143b7c9 ("spi: pxa2xx: Add slave mode support")
> Signed-off-by: Lubomir Rintel
> ---
> drivers/spi/spi-pxa2xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-pxa2xx.c
> -Original Message-
> From: Z.q. Hou
> Sent: Sunday, November 11, 2018 5:48 PM
> To: Leo Li ; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com;
> -Original Message-
> From: Z.q. Hou
> Sent: Sunday, November 11, 2018 5:48 PM
> To: Leo Li ; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com;
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> A good demonstration of a new commitment to pragmatism would be
> merging the trivial wrappers for gettid(2).
I support the addition of gettid (for use with those syscalls that take
tids, and with appropriate documentation explaining the
On Wed, 14 Nov 2018 20:27:52 +0200
Priit Laes wrote:
> Kernel library has a common cordic algorithm which is identical
> to internally implementatd one, so use it and drop the duplicate
> implementation.
In v2 of the series it has been said that:
Arend van Spriel wrote:
> I recall doing a
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> A good demonstration of a new commitment to pragmatism would be
> merging the trivial wrappers for gettid(2).
I support the addition of gettid (for use with those syscalls that take
tids, and with appropriate documentation explaining the
On Wed, 14 Nov 2018 20:27:52 +0200
Priit Laes wrote:
> Kernel library has a common cordic algorithm which is identical
> to internally implementatd one, so use it and drop the duplicate
> implementation.
In v2 of the series it has been said that:
Arend van Spriel wrote:
> I recall doing a
On Wed, Nov 14, 2018 at 10:15 AM, Joseph Myers wrote:
> Any
> feature (e.g. syscall library) with a design coming solely from the kernel
> rather than a cooperative process is also likely to have an unsuitable
> design meaning it doesn't get used.
Is that so? membarrier came directly from the
On Wed, Nov 14, 2018 at 10:15 AM, Joseph Myers wrote:
> Any
> feature (e.g. syscall library) with a design coming solely from the kernel
> rather than a cooperative process is also likely to have an unsuitable
> design meaning it doesn't get used.
Is that so? membarrier came directly from the
On Wed, 14 Nov 2018, Arnd Bergmann wrote:
> Firoz Khan is in the process of doing part of this, by changing the
> in-kernel per-architecture unistd.h and syscall.S files into a
> architecture independent machine-readable format that is used to
> generate the existing files. The format will be
On Wed, 14 Nov 2018, Arnd Bergmann wrote:
> Firoz Khan is in the process of doing part of this, by changing the
> in-kernel per-architecture unistd.h and syscall.S files into a
> architecture independent machine-readable format that is used to
> generate the existing files. The format will be
There is no reason why we rearm the waitiqueue upon every
fetch_events retry (for when events are found yet send_events()
fails). If nothing else, this saves four lock operations per
retry, and furthermore reduces the scope of the lock even
further.
Signed-off-by: Davidlohr Bueso
---
There is no reason why we rearm the waitiqueue upon every
fetch_events retry (for when events are found yet send_events()
fails). If nothing else, this saves four lock operations per
retry, and furthermore reduces the scope of the lock even
further.
Signed-off-by: Davidlohr Bueso
---
It is currently called check_events because it, well, did
exactly that. However, since the lockless ep_events_available()
call, the label no longer checks, but just sends the events.
Rename as such.
Signed-off-by: Davidlohr Bueso
---
Both patch 1 and 2 apply on top of the mmots.
It is currently called check_events because it, well, did
exactly that. However, since the lockless ep_events_available()
call, the label no longer checks, but just sends the events.
Rename as such.
Signed-off-by: Davidlohr Bueso
---
Both patch 1 and 2 apply on top of the mmots.
On Mon, Nov 12, 2018 at 02:11:24PM -0800, Matthias Kaehlcke wrote:
> This series adds a channel for the die temperature to the QCOM SPMI
> PMIC5 ADC. It also fixes an example in the DT documentation.
>
> Matthias Kaehlcke (2):
> dt-bindings: iio: vadc: Add unit address to ADC channel node in
>
On Mon, Nov 12, 2018 at 02:11:24PM -0800, Matthias Kaehlcke wrote:
> This series adds a channel for the die temperature to the QCOM SPMI
> PMIC5 ADC. It also fixes an example in the DT documentation.
>
> Matthias Kaehlcke (2):
> dt-bindings: iio: vadc: Add unit address to ADC channel node in
>
On Wed, 14 Nov 2018 at 19:08, Andrew Jones wrote:
>
> On Wed, Nov 14, 2018 at 05:30:28PM +0200, Ahmed Soliman wrote:
> > Hello,
> >
> > KVM Self tests located at tools/testing/selftests/kvm seams to be failing.
> > I have tried:
> > - dirty_log_test
> > - x86_64/cr4_cpuid_sync_test
> > -
On Wed, 14 Nov 2018 at 19:08, Andrew Jones wrote:
>
> On Wed, Nov 14, 2018 at 05:30:28PM +0200, Ahmed Soliman wrote:
> > Hello,
> >
> > KVM Self tests located at tools/testing/selftests/kvm seams to be failing.
> > I have tried:
> > - dirty_log_test
> > - x86_64/cr4_cpuid_sync_test
> > -
+cc Andy
On Wed, Nov 14, 2018 at 7:03 PM Eric Biggers wrote:
> When a UHID_CREATE command is written to the uhid char device, a
> copy_from_user() is done from a user pointer embedded in the command.
> When the address limit is KERNEL_DS, e.g. as is the case during
> sendfile(), this can read
+cc Andy
On Wed, Nov 14, 2018 at 7:03 PM Eric Biggers wrote:
> When a UHID_CREATE command is written to the uhid char device, a
> copy_from_user() is done from a user pointer embedded in the command.
> When the address limit is KERNEL_DS, e.g. as is the case during
> sendfile(), this can read
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> > there is a lot of bikesheding here by people who
> > don't understand the constraints nor the use-cases.
>
> Conversely, there's a lot of doubt-sowing from the other side that
"other side" is the wrong concept here in the first place - it's
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> > there is a lot of bikesheding here by people who
> > don't understand the constraints nor the use-cases.
>
> Conversely, there's a lot of doubt-sowing from the other side that
"other side" is the wrong concept here in the first place - it's
From: Borislav Petkov
The hardware configuration register has some useful bits which can be
used by guests. Implement McStatusWrEn which can be used by guests when
injecting MCEs with the in-kernel mce-inject module.
For that, we need to set bit 18 - McStatusWrEn - first, before writing
the
From: Borislav Petkov
The hardware configuration register has some useful bits which can be
used by guests. Implement McStatusWrEn which can be used by guests when
injecting MCEs with the in-kernel mce-inject module.
For that, we need to set bit 18 - McStatusWrEn - first, before writing
the
From: Borislav Petkov
This is an AMD-specific MSR. Put it where it belongs.
Signed-off-by: Borislav Petkov
Tested-by: Yazen Ghannam
---
arch/x86/kvm/svm.c | 14 ++
arch/x86/kvm/x86.c | 12
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git
From: Borislav Petkov
This is an AMD-specific MSR. Put it where it belongs.
Signed-off-by: Borislav Petkov
Tested-by: Yazen Ghannam
---
arch/x86/kvm/svm.c | 14 ++
arch/x86/kvm/x86.c | 12
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git
From: Borislav Petkov
Hi all,
here's a rediff ontop of -rc2. No changes, only added Yazen's Tested-by.
Please queue,
thx.
Changelog:
==
v2:
here's v2, dropping patch 3 and incorporating hopefully all of Radim's
feedback.
v1:
there's this mce-inject.ko module in the kernel which
From: Borislav Petkov
Hi all,
here's a rediff ontop of -rc2. No changes, only added Yazen's Tested-by.
Please queue,
thx.
Changelog:
==
v2:
here's v2, dropping patch 3 and incorporating hopefully all of Radim's
feedback.
v1:
there's this mce-inject.ko module in the kernel which
On Wed, Nov 14, 2018 at 10:03 AM Eric Biggers wrote:
>
> From: Eric Biggers
>
> When a UHID_CREATE command is written to the uhid char device, a
> copy_from_user() is done from a user pointer embedded in the command.
> When the address limit is KERNEL_DS, e.g. as is the case during
> sendfile(),
On Wed, Nov 14, 2018 at 10:03 AM Eric Biggers wrote:
>
> From: Eric Biggers
>
> When a UHID_CREATE command is written to the uhid char device, a
> copy_from_user() is done from a user pointer embedded in the command.
> When the address limit is KERNEL_DS, e.g. as is the case during
> sendfile(),
On 11/14/18 9:40 AM, Joseph Myers wrote:
Historically, there was once an attempt to rework POSIX into a separate
language-independent definition and language bindings (for C, Fortran, Ada
etc.), but I don't think it got anywhere, and it's probably doubtful
whether the idea was ever very
On 11/14/18 9:40 AM, Joseph Myers wrote:
Historically, there was once an attempt to rework POSIX into a separate
language-independent definition and language bindings (for C, Fortran, Ada
etc.), but I don't think it got anywhere, and it's probably doubtful
whether the idea was ever very
On Wed, Nov 14, 2018 at 03:58:36PM +0100, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Wed, Nov 14, 2018 at 3:16 PM Russell King - ARM Linux
> wrote:
> > On Wed, Nov 14, 2018 at 02:17:09PM +1100, Finn Thain wrote:
> > > So, even assuming that you're right about the limitations of single-timer
On Wed, Nov 14, 2018 at 03:58:36PM +0100, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Wed, Nov 14, 2018 at 3:16 PM Russell King - ARM Linux
> wrote:
> > On Wed, Nov 14, 2018 at 02:17:09PM +1100, Finn Thain wrote:
> > > So, even assuming that you're right about the limitations of single-timer
701 - 800 of 1344 matches
Mail list logo
