On 04/04/2019 08:44 AM, Christian Zigotzky wrote:
On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
On 03 April 2019 at 07:05AM, Christophe Leroy wrote:
Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :
Please test VLC with the
Hi Abhishek,
thanks for taking the time to test the different scenario and give us
the numbers.
On 01/04/2019 07:11, Abhishek wrote:
>
>
> On 03/22/2019 06:56 PM, Daniel Lezcano wrote:
>> On 22/03/2019 10:45, Rafael J. Wysocki wrote:
>>> On Fri, Mar 22, 2019 at 8:31 AM Abhishek Goel
>>>
Jens Axboe writes:
> On 4/3/19 5:11 AM, Will Deacon wrote:
>> On Wed, Apr 03, 2019 at 01:47:50PM +1100, Michael Ellerman wrote:
>>> Arnd Bergmann writes:
diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
b/arch/powerpc/kernel/syscalls/syscall.tbl
index
On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
On 03 April 2019 at 07:05AM, Christophe Leroy wrote:
Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :
Please test VLC with the RC3 of kernel 5.1.
The removing of the PowerPC fixes
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen
5.0-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen
On Mon, 1 Apr 2019, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
> function call syscall_get_arguments() implemented in x86 was horribly
> written and not optimized for the standard case of passing in 0
5.0-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by
5.0-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 5cd401ace914dc68556c6d2fcae0c349444d5f86 ]
walk_system_ram_range() can return an error code either becuase
*it* failed, or because the 'func' that it calls returned an
error. The
In ESAI synchronous mode, the clock is generated by Tx, So
we should always set registers of Tx which relate with the
bit clock and frame clock generation (TCCR, TCR, ECR), even
there is only Rx is working.
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
Changes in v3
- fix the
On Mon, 1 Apr 2019, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> After removing the start and count arguments of syscall_get_arguments() it
> seems reasonable to remove them from syscall_set_arguments(). Note, as of
> today, there are no users of syscall_set_arguments(). But we
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen
Hi
>
> This looks better :)
>
> On Wed, Apr 03, 2019 at 10:07:40AM +, S.j. Wang wrote:
> > @@ -218,7 +218,7 @@ static int fsl_esai_set_dai_sysclk(struct
> > snd_soc_dai *dai, int clk_id, {
> > struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
> > struct clk *clksrc =
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by
On 04 April 2019 at 11:07AM, Christophe Leroy wrote:
On 04/04/2019 08:44 AM, Christian Zigotzky wrote:
On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
On 03 April 2019 at 07:05AM, Christophe Leroy wrote:
Le 03/04/2019 à 05:52,
On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
wrote:
>
> Hi!
>
> On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
> > - NOTES :kernel :notes
> > + NOTES
>
> I think this still need to be
>
> NOTES :kernel
>
> or the linker will complain. Did you try to build
On 04 April 2019 at 1:23PM, Christian Zigotzky wrote:
On 04 April 2019 at 11:07AM, Christophe Leroy wrote:
On 04/04/2019 08:44 AM, Christian Zigotzky wrote:
On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
On 03 April 2019 at
On 04/04/2019 03:51 PM, Daniel Lezcano wrote:
Hi Abhishek,
thanks for taking the time to test the different scenario and give us
the numbers.
On 01/04/2019 07:11, Abhishek wrote:
On 03/22/2019 06:56 PM, Daniel Lezcano wrote:
On 22/03/2019 10:45, Rafael J. Wysocki wrote:
On Fri, Mar 22,
Most of the power processor generation performance monitoring
unit (PMU) driver code is bundled in the kernel and one of those
is enabled/registered based on the oprofile_cpu_type check at
the boot.
But things get little tricky incase of "compat" mode boot.
IBM POWER System Server based
On Thu, Apr 4, 2019 at 9:07 AM Andra Danciu wrote:
>
> Adopt the SPDX license identifier headers to ease license compliance
> management.
>
> Signed-off-by: Andra Danciu
> ---
> sound/soc/fsl/imx-pcm.h | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git
Commit b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC
inconsistencies across Y2038") changed the type of wtom_clock_sec
to s64 on PPC64. Therefore, VDSO32 needs to read it with a 4 bytes
shift in order to retrieve the lower part of it.
Fixes: b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC
Hello Daniel,
On Thu, Apr 4, 2019 at 3:52 PM Daniel Lezcano wrote:
>
>
> Hi Abhishek,
>
> thanks for taking the time to test the different scenario and give us
> the numbers.
>
> On 01/04/2019 07:11, Abhishek wrote:
> >
[.. snip..]
>
> In case of POWER, this is problematic, when the
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu
---
sound/soc/fsl/imx-pcm-dma.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
Hello Nicholas,
On Tue, Apr 2, 2019 at 4:57 PM Nicholas Piggin wrote:
>
> Using a jiffies timer creates a dependency on the tick_do_timer_cpu
> incrementing jiffies. If that CPU has locked up and jiffies is not
> incrementing, the watchdog heartbeat timer for all CPUs stops and
> creates false
Currenty pmu driver file for each ppc64 generation processor
has a __init call in itself. Refactor the code by moving the
__init call to core-books.c. This also clean's up compat mode
pmu driver registration.
Suggested-by: Michael Ellerman
Signed-off-by: Madhavan Srinivasan
---
Changelog v1:
-
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu
---
sound/soc/fsl/imx-pcm.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index 133c4470acad..3ce2f437e645
Hi Joel,
On Thu, Apr 04, 2019 at 12:17:40PM +, Joel Stanley wrote:
> On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
> wrote:
> > On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
> > > - NOTES :kernel :notes
> > > + NOTES
> >
> > I think this still need to be
> >
> >
Le 04/04/2019 à 16:53, Segher Boessenkool a écrit :
Hi Joel,
On Thu, Apr 04, 2019 at 12:17:40PM +, Joel Stanley wrote:
On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
wrote:
On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
- NOTES :kernel :notes
+ NOTES
I
Christophe Leroy's on April 3, 2019 4:31 am:
>
>
> Le 02/04/2019 à 16:34, Aneesh Kumar K.V a écrit :
>> Currently, our mm_context_t on book3s64 include all hash specific
>> context details like slice mask, subpage protection details. We
>> can skip allocating those on radix. This will help us to
Peter Zijlstra's on April 1, 2019 6:38 pm:
>
> + fweisbec, who did the remote bits
>
> On Sat, Mar 30, 2019 at 01:10:28PM +1000, Nicholas Piggin wrote:
>> Something like this?
>>
>> kernel/irq_work: Do not raise an IPI when queueing work on the local CPU
>>
>> The QEMU powerpc/pseries machine
Configure arm64 runtime CPU speculation bug mitigations in accordance
with the 'cpu_spec_mitigations=' cmdline options. This affects
Meltdown and Speculative Store Bypass.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
Documentation/admin-guide/kernel-parameters.txt | 2
Le 04/04/2019 à 18:13, Nicholas Piggin a écrit :
Christophe Leroy's on April 3, 2019 4:31 am:
Le 02/04/2019 à 16:34, Aneesh Kumar K.V a écrit :
Currently, our mm_context_t on book3s64 include all hash specific
context details like slice mask, subpage protection details. We
can skip
Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users. It's getting more and more
complicated to decide which mitigations are needed for a given
architecture. Complicating matters is the fact that each arch tends to
it own custom way
Configure x86 runtime CPU speculation bug mitigations in accordance with
the 'cpu_spec_mitigations=' cmdline options. This affects Meltdown,
Spectre v2, Speculative Store Bypass, and L1TF.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
Configure powerpc CPU runtime speculation bug mitigations in accordance
with the 'cpu_spec_mitigations=' cmdline options. This affects
Meltdown, Spectre v1, Spectre v2, and Speculative Store Bypass.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
On 04/04/2019 12:44 PM, Josh Poimboeuf wrote:
> Keeping track of the number of mitigations for all the CPU speculation
> bugs has become overwhelming for many users. It's getting more and more
> complicated to decide which mitigations are needed for a given
> architecture. Complicating matters
Gautham R Shenoy's on April 4, 2019 9:19 pm:
> Hello Nicholas,
>
> On Tue, Apr 2, 2019 at 4:57 PM Nicholas Piggin wrote:
>>
>> Using a jiffies timer creates a dependency on the tick_do_timer_cpu
>> incrementing jiffies. If that CPU has locked up and jiffies is not
>> incrementing, the watchdog
Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users. It's getting more and more
complicated to decide which mitigations are needed for a given
architecture. Complicating matters is the fact that each arch tends to
their own custom
Configure s390 runtime CPU speculation bug mitigations in accordance
with the 'cpu_spec_mitigations=' cmdline options. This affects Spectre
v1 and Spectre v2.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
Documentation/admin-guide/kernel-parameters.txt | 7 ---
On Thu, Apr 04, 2019 at 11:44:11AM -0500, Josh Poimboeuf wrote:
> Keeping track of the number of mitigations for all the CPU speculation
> bugs has become overwhelming for many users. It's getting more and more
> complicated to decide which mitigations are needed for a given
> architecture.
On Thu, 4 Apr 2019, Josh Poimboeuf wrote:
> Configure powerpc CPU runtime speculation bug mitigations in accordance
> with the 'cpu_spec_mitigations=' cmdline options. This affects
> Meltdown, Spectre v1, Spectre v2, and Speculative Store Bypass.
[ ... snip ... ]
> - if (!no_nospec)
> +
Will be joining in ~ 5 mins. Getting Chromium set up here.
- Original Message -
> From: "Jiri Kosina"
> To: "Josh Poimboeuf"
> Cc: "Peter Zijlstra" , "Heiko Carstens"
> , "Paul Mackerras"
> , "H . Peter Anvin" , "Ingo Molnar"
> , "Andrea Arcangeli"
> , linux-s...@vger.kernel.org,
On Thu, 4 Apr 2019 16:23:24 +1100
Alexey Kardashevskiy wrote:
> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
> platform
On Mon, Apr 1, 2019 at 6:45 AM Steven Rostedt wrote:
>
> From: "Steven Rostedt (VMware)"
>
> After removing the start and count arguments of syscall_get_arguments() it
> seems reasonable to remove them from syscall_set_arguments(). Note, as of
> today, there are no users of
On Mon, Apr 1, 2019 at 6:45 AM Steven Rostedt wrote:
>
> From: "Steven Rostedt (Red Hat)"
>
> At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
> function call syscall_get_arguments() implemented in x86 was horribly
> written and not optimized for the standard case of
On Fri, Mar 22, 2019 at 05:10:25PM -0600, Alex Williamson wrote:
> On Fri, 22 Mar 2019 14:08:38 +1100
> David Gibson wrote:
>
> > On Thu, Mar 21, 2019 at 12:19:34PM -0600, Alex Williamson wrote:
> > > On Thu, 21 Mar 2019 10:56:00 +1100
> > > David Gibson wrote:
> > >
> > > > On Wed, Mar 20,
The patch
ASoC: fsl_esai: Support synchronous mode
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
From: Yue Haibing
Date: Wed, 3 Apr 2019 15:54:09 +0800
> From: YueHaibing
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/ibm/ibmvnic.c: In function '__ibmvnic_reset':
> drivers/net/ethernet/ibm/ibmvnic.c:1971:21: warning: variable 'netdev' set
> but not used
On Thu, Apr 04, 2019 at 02:22:25PM -0600, Alex Williamson wrote:
> On Thu, 4 Apr 2019 16:23:24 +1100
> Alexey Kardashevskiy wrote:
>
> > The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> > (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> > peer to
On Thu, 4 Apr 2019 21:17:58 +0300
"Dmitry V. Levin" wrote:
> There are several places listed below where I'd prefer to see more readable
> equivalents, but feel free to leave it to respective arch maintainers.
I was going to do similar changes, but figured I'd do just that (let
the arch
On Mon, Apr 01, 2019 at 09:41:10AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> After removing the start and count arguments of syscall_get_arguments() it
> seems reasonable to remove them from syscall_set_arguments(). Note, as of
> today, there are no users of
On Mon, Apr 01, 2019 at 09:41:09AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
> function call syscall_get_arguments() implemented in x86 was horribly
> written and not optimized for the standard
55 matches
Mail list logo
