Remove support for the LM3633 from the ti-lmu
driver in favor of a dedicated LED driver.
Signed-off-by: Dan Murphy
---
drivers/mfd/Kconfig | 2 +-
drivers/mfd/ti-lmu.c | 21 -
2 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/mfd/Kconfig
From: Pavel Machek
This adds backlight support for the following TI LMU
chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
It controls LEDs on Droid 4
smartphone, including keyboard and screen backlights.
Signed-off-by: Milo Kim
[add LED subsystem support for keyboard backlight and
Remove support for the LM3633 from the ti-lmu
driver in favor of a dedicated LED driver.
Signed-off-by: Dan Murphy
---
drivers/mfd/Kconfig | 2 +-
drivers/mfd/ti-lmu.c | 21 -
2 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/mfd/Kconfig
From: Pavel Machek
This adds backlight support for the following TI LMU
chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
It controls LEDs on Droid 4
smartphone, including keyboard and screen backlights.
Signed-off-by: Milo Kim
[add LED subsystem support for keyboard backlight and
Introduce the LED LM3633 driver. This LED
driver has 9 total LED outputs with runtime
internal ramp configurations.
Data sheet:
http://www.ti.com/lit/ds/symlink/lm3633.pdf
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
Introduce the LED LM3633 driver. This LED
driver has 9 total LED outputs with runtime
internal ramp configurations.
Data sheet:
http://www.ti.com/lit/ds/symlink/lm3633.pdf
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
Introduce the lm3697 LED driver for
backlighting and display.
Datasheet location:
http://www.ti.com/lit/ds/symlink/lm3697.pdf
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 8 +-
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3697.c | 381
Introduce the lm3697 LED driver for
backlighting and display.
Datasheet location:
http://www.ti.com/lit/ds/symlink/lm3697.pdf
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 8 +-
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3697.c | 381
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> Add name field in struct rproc_mem_entry.
> This new field will be used to match memory area
> requested in resource table with pre-registered carveout.
>
> Signed-off-by: Loic Pallardy
> Acked-by: Bjorn Andersson
Acked-by: Suman Anna
> ---
>
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> Add name field in struct rproc_mem_entry.
> This new field will be used to match memory area
> requested in resource table with pre-registered carveout.
>
> Signed-off-by: Loic Pallardy
> Acked-by: Bjorn Andersson
Acked-by: Suman Anna
> ---
>
Hi Bjorn, Loic,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> This patch introduces a new API to allow platform driver to register
> platform specific carveout regions.
>
> Signed-off-by: Loic Pallardy
> Acked-by: Bjorn Andersson
Hmm, I do not prefer that this function be exported. It adds no
Hi Bjorn, Loic,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> This patch introduces a new API to allow platform driver to register
> platform specific carveout regions.
>
> Signed-off-by: Loic Pallardy
> Acked-by: Bjorn Andersson
Hmm, I do not prefer that this function be exported. It adds no
On 10/20/18 7:21 AM, Rob Herring wrote:
On Fri, Oct 19, 2018 at 5:06 PM Paul Walmsley wrote:
On 10/19/18 1:45 PM, Rob Herring wrote:
On Fri, Oct 19, 2018 at 1:48 PM Paul Walmsley wrote:
Add DT binding documentation for the Linux driver for the SiFive
asynchronous serial IP block. Nothing
On Tue 23-10-18 08:26:40, Matthew Wilcox wrote:
> On Tue, Oct 23, 2018 at 09:02:56AM -0600, Shuah Khan wrote:
[...]
> > The way it can be handled is by adding a test module under lib. test_kmod,
> > test_sysctl, test_user_copy etc.
>
> The problem is that said module can only invoke functions
On Tue 23-10-18 08:26:40, Matthew Wilcox wrote:
> On Tue, Oct 23, 2018 at 09:02:56AM -0600, Shuah Khan wrote:
[...]
> > The way it can be handled is by adding a test module under lib. test_kmod,
> > test_sysctl, test_user_copy etc.
>
> The problem is that said module can only invoke functions
On 10/20/18 7:21 AM, Rob Herring wrote:
On Fri, Oct 19, 2018 at 5:06 PM Paul Walmsley wrote:
On 10/19/18 1:45 PM, Rob Herring wrote:
On Fri, Oct 19, 2018 at 1:48 PM Paul Walmsley wrote:
Add DT binding documentation for the Linux driver for the SiFive
asynchronous serial IP block. Nothing
On Fri, 2018-10-19 at 16:57 +0300, Andy Shevchenko wrote:
> On Wed, Oct 10, 2018 at 8:23 PM Lubomir Rintel wrote:
> > Hi.
> >
> > This patchset adds support for the Embedded Controller on an OLPC XO
> > 1.75 machine. OLPC XO 1.75 is a MMP2 based ARM laptop. It plugs into
> > the existing OLPC
On Fri, 2018-10-19 at 16:57 +0300, Andy Shevchenko wrote:
> On Wed, Oct 10, 2018 at 8:23 PM Lubomir Rintel wrote:
> > Hi.
> >
> > This patchset adds support for the Embedded Controller on an OLPC XO
> > 1.75 machine. OLPC XO 1.75 is a MMP2 based ARM laptop. It plugs into
> > the existing OLPC
On Wed 17-10-18 09:30:58, Dan Williams wrote:
> On Wed, Oct 17, 2018 at 1:18 AM Michal Hocko wrote:
[...]
> > > Again, devm_memremap_pagex() exposes and relies upon core kernel
> > > internal assumptions and will continue to evolve along with 'struct
> > > page', memory hotplug, and support for
On Wed 17-10-18 09:30:58, Dan Williams wrote:
> On Wed, Oct 17, 2018 at 1:18 AM Michal Hocko wrote:
[...]
> > > Again, devm_memremap_pagex() exposes and relies upon core kernel
> > > internal assumptions and will continue to evolve along with 'struct
> > > page', memory hotplug, and support for
On 10/23/2018 09:17 AM, Shuah Khan wrote:
> On 10/22/2018 02:51 AM, Jiri Olsa wrote:
>> On Wed, Oct 17, 2018 at 09:28:16AM -0600, Shuah Khan wrote:
>>> On 10/17/2018 07:23 AM, Thomas Renninger wrote:
On Tuesday, October 16, 2018 5:06:05 PM CEST Jiri Olsa wrote:
> hi,
> while hardening
On 10/23/2018 09:17 AM, Shuah Khan wrote:
> On 10/22/2018 02:51 AM, Jiri Olsa wrote:
>> On Wed, Oct 17, 2018 at 09:28:16AM -0600, Shuah Khan wrote:
>>> On 10/17/2018 07:23 AM, Thomas Renninger wrote:
On Tuesday, October 16, 2018 5:06:05 PM CEST Jiri Olsa wrote:
> hi,
> while hardening
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> Memory entry could be allocated in different ways (ioremap,
> dma_alloc_coherent, internal RAM allocator...).
> This patch introduces a release ops in rproc_mem_entry structure
> to associate dedicated release mechanism to each memory entry descriptor
>
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> Memory entry could be allocated in different ways (ioremap,
> dma_alloc_coherent, internal RAM allocator...).
> This patch introduces a release ops in rproc_mem_entry structure
> to associate dedicated release mechanism to each memory entry descriptor
>
Hi Loic, Bjorn,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> This new function translates CPU virtual address in
> CPU physical one according to virtual address location.
>
> Signed-off-by: Loic Pallardy
> Acked-by: Bjorn Andersson
> ---
> drivers/remoteproc/remoteproc_core.c | 18
Hi Loic, Bjorn,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> This new function translates CPU virtual address in
> CPU physical one according to virtual address location.
>
> Signed-off-by: Loic Pallardy
> Acked-by: Bjorn Andersson
> ---
> drivers/remoteproc/remoteproc_core.c | 18
On Mon, Oct 22, 2018 at 5:41 PM Matthias Kaehlcke wrote:
>
> If scheduler debugging is disabled sched_feat() resolves to a constant
> value that can be non-boolean. clang raises a warning when it detects
> that a non-boolean constant is used as operand in logical expressions:
>
>
On Mon, Oct 22, 2018 at 5:41 PM Matthias Kaehlcke wrote:
>
> If scheduler debugging is disabled sched_feat() resolves to a constant
> value that can be non-boolean. clang raises a warning when it detects
> that a non-boolean constant is used as operand in logical expressions:
>
>
Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs
with a relatively small number of objects") leads to a regression on
his setup: periodically the majority of the pagecache is evicted
without an obvious reason, while before the change the amount of free
memory was balancing
Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs
with a relatively small number of objects") leads to a regression on
his setup: periodically the majority of the pagecache is evicted
without an obvious reason, while before the change the amount of free
memory was balancing
Hi Bjorn,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> The aim of the series is to implement carveout memory management as
> discussed during OpenAMP weekly call and defined in proposed document [1]
>
> This first series focus only on adding support of the different types of
> carveout memories
Hi Bjorn,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> The aim of the series is to implement carveout memory management as
> discussed during OpenAMP weekly call and defined in proposed document [1]
>
> This first series focus only on adding support of the different types of
> carveout memories
On Mon, Oct 22, 2018 at 03:25:10PM +0200, Petr Mladek wrote:
> On Fri 2018-10-19 09:36:04, Josh Poimboeuf wrote:
> > On Fri, Oct 19, 2018 at 02:16:19PM +0200, Miroslav Benes wrote:
> > > On Thu, 18 Oct 2018, Josh Poimboeuf wrote:
> > >
> > > > On Thu, Oct 18, 2018 at 04:54:56PM +0200, Petr Mladek
On Mon, Oct 22, 2018 at 03:25:10PM +0200, Petr Mladek wrote:
> On Fri 2018-10-19 09:36:04, Josh Poimboeuf wrote:
> > On Fri, Oct 19, 2018 at 02:16:19PM +0200, Miroslav Benes wrote:
> > > On Thu, 18 Oct 2018, Josh Poimboeuf wrote:
> > >
> > > > On Thu, Oct 18, 2018 at 04:54:56PM +0200, Petr Mladek
The patchset fixes issues with LDT remap for PTI:
- Layout collision due to KASLR with 5-level paging;
- Information leak via Meltdown-like attack;
Please review and consider applying.
Kirill A. Shutemov (2):
x86/mm: Move LDT remap out of KASLR region on 5-level paging
x86/ldt: Unmap
The patchset fixes issues with LDT remap for PTI:
- Layout collision due to KASLR with 5-level paging;
- Information leak via Meltdown-like attack;
Please review and consider applying.
Kirill A. Shutemov (2):
x86/mm: Move LDT remap out of KASLR region on 5-level paging
x86/ldt: Unmap
On 5-level paging LDT remap area is placed in the middle of
KASLR randomization region and it can overlap with direct mapping,
vmalloc or vmap area.
Let's move LDT just before direct mapping which makes it safe for KASLR.
This also allows us to unify layout between 4- and 5-level paging.
We
modify_ldt(2) leaves old LDT mapped after we switch over to the new one.
Memory for the old LDT gets freed and the pages can be re-used.
Leaving the mapping in place can have security implications. The mapping
is present in userspace copy of page tables and Meltdown-like attack can
read these
On 5-level paging LDT remap area is placed in the middle of
KASLR randomization region and it can overlap with direct mapping,
vmalloc or vmap area.
Let's move LDT just before direct mapping which makes it safe for KASLR.
This also allows us to unify layout between 4- and 5-level paging.
We
modify_ldt(2) leaves old LDT mapped after we switch over to the new one.
Memory for the old LDT gets freed and the pages can be re-used.
Leaving the mapping in place can have security implications. The mapping
is present in userspace copy of page tables and Meltdown-like attack can
read these
On Mon, Oct 22, 2018 at 5:29 PM Rob Herring wrote:
>
> On Thu, Oct 18, 2018 at 02:09:29PM -0700, Evan Green wrote:
> > This change adds register regions for the second lane of dual-lane nodes.
> > This additional specification is needed so that the driver can stop
> > reaching beyond the tx and
On Mon, Oct 22, 2018 at 5:29 PM Rob Herring wrote:
>
> On Thu, Oct 18, 2018 at 02:09:29PM -0700, Evan Green wrote:
> > This change adds register regions for the second lane of dual-lane nodes.
> > This additional specification is needed so that the driver can stop
> > reaching beyond the tx and
Hi Andreas,
On Mon, 22 Oct 2018 13:15:34 +
Andreas Puhm p...@oregano.at wrote:
...
>Full description:
>The altera_cvp probe function only checks,
>if the Altera/Intel PCI device configuration space contains a vendor
>specific entry (VSEC Capability Header 0x000b) at offset 0x200.
> But the
Hi Andreas,
On Mon, 22 Oct 2018 13:15:34 +
Andreas Puhm p...@oregano.at wrote:
...
>Full description:
>The altera_cvp probe function only checks,
>if the Altera/Intel PCI device configuration space contains a vendor
>specific entry (VSEC Capability Header 0x000b) at offset 0x200.
> But the
On Tue, Oct 23, 2018 at 12:19:35PM +0100, Alan Jenkins wrote:
> I think there's another small hole. It is possible to move a sub-mount from
> a detached tree (instead of moving the root of the tree). Then
> do_move_mount() calls attach_recursive_mnt() with a non-NULL parent_path.
>
> This
On Tue, Oct 23, 2018 at 12:19:35PM +0100, Alan Jenkins wrote:
> I think there's another small hole. It is possible to move a sub-mount from
> a detached tree (instead of moving the root of the tree). Then
> do_move_mount() calls attach_recursive_mnt() with a non-NULL parent_path.
>
> This
On 2018-10-11 01:03, Bryan O'Donoghue wrote:
> On 05/10/2018 15:28, Rasmus Villemoes wrote:
>> Signed-off-by: Rasmus Villemoes
>> ---
>> I have no idea if the performance matters (it probably doesn't). Feel
>> free to ignore this and the followup cleanup.
>
> What's the problem you're fixing here
On 2018-10-11 01:03, Bryan O'Donoghue wrote:
> On 05/10/2018 15:28, Rasmus Villemoes wrote:
>> Signed-off-by: Rasmus Villemoes
>> ---
>> I have no idea if the performance matters (it probably doesn't). Feel
>> free to ignore this and the followup cleanup.
>
> What's the problem you're fixing here
This contains two drivers:
* i2c-amd-plat-mp2: platform driver managing an i2c adapter (one of
the two busses of the MP2) and routing any i2c read write call or
command to the PCI driver.
* i2c-amd-pci-mp2: PCI driver communicating through the C2P/P2C
mailbox registers, or through DMA for more
This contains two drivers:
* i2c-amd-plat-mp2: platform driver managing an i2c adapter (one of
the two busses of the MP2) and routing any i2c read write call or
command to the PCI driver.
* i2c-amd-pci-mp2: PCI driver communicating through the C2P/P2C
mailbox registers, or through DMA for more
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Rami Rosen
> Sent: Tuesday, October 23, 2018 8:31 PM
> To: pandit.pa...@gmail.com
> Cc: t...@kernel.org; linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Rami Rosen
> Sent: Tuesday, October 23, 2018 8:31 PM
> To: pandit.pa...@gmail.com
> Cc: t...@kernel.org; linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
Hi Tejun
On Wed, 17 Oct 2018 at 18:20, Tejun Heo wrote:
>
> Hello, Michael.
>
> Sorry about the delay.
>
> On Thu, Oct 04, 2018 at 09:40:57PM +0200, Michael Kerrisk (man-pages) wrote:
> > This seems odd. x/y is now of "domain invalid" type with a controller
> > enabled! This feels like a
Hi Tejun
On Wed, 17 Oct 2018 at 18:20, Tejun Heo wrote:
>
> Hello, Michael.
>
> Sorry about the delay.
>
> On Thu, Oct 04, 2018 at 09:40:57PM +0200, Michael Kerrisk (man-pages) wrote:
> > This seems odd. x/y is now of "domain invalid" type with a controller
> > enabled! This feels like a
On October 23, 2018 7:53:51 AM PDT, Greg Kroah-Hartman
wrote:
>On Mon, Oct 22, 2018 at 09:19:04AM -0700, H. Peter Anvin (Intel) wrote:
>> From: "H. Peter Anvin"
>>
>> On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in
>tty_baudrate.c does
>> not do any limit checking on the
On October 23, 2018 7:53:51 AM PDT, Greg Kroah-Hartman
wrote:
>On Mon, Oct 22, 2018 at 09:19:04AM -0700, H. Peter Anvin (Intel) wrote:
>> From: "H. Peter Anvin"
>>
>> On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in
>tty_baudrate.c does
>> not do any limit checking on the
If a bias is enabled on a pin of an Amlogic SoC, calling .pin_config_set()
with PIN_CONFIG_BIAS_DISABLE will not disable the bias. Instead it will
force a pull-down bias on the pin.
Instead of the pull type register bank, the driver should access the pull
enable register bank.
Fixes:
If a bias is enabled on a pin of an Amlogic SoC, calling .pin_config_set()
with PIN_CONFIG_BIAS_DISABLE will not disable the bias. Instead it will
force a pull-down bias on the pin.
Instead of the pull type register bank, the driver should access the pull
enable register bank.
Fixes:
On Mon, Oct 22, 2018 at 10:02:44AM -0700, Dmitry Torokhov wrote:
Hi Sasha,
On Mon, Oct 22, 2018 at 06:19:05AM -0400, Sasha Levin wrote:
From: Dmitry Torokhov
[ Upstream commit 36d2582ff235b4e01ad64a734c877a52dc762d9c ]
Large writes to evdev interface may cause rcu stalls. Let's add
On Mon, Oct 22, 2018 at 10:02:44AM -0700, Dmitry Torokhov wrote:
Hi Sasha,
On Mon, Oct 22, 2018 at 06:19:05AM -0400, Sasha Levin wrote:
From: Dmitry Torokhov
[ Upstream commit 36d2582ff235b4e01ad64a734c877a52dc762d9c ]
Large writes to evdev interface may cause rcu stalls. Let's add
On Mon, Oct 22, 2018 at 09:58:21AM -0700, Dmitry Torokhov wrote:
Hi Sasha,
On Mon, Oct 22, 2018 at 06:19:01AM -0400, Sasha Levin wrote:
From: Daniel Drake
[ Upstream commit 684bec1092b6991ff2a7751e8a763898576eb5c2 ]
Previously, on typical consumer laptops, pressing a key on the keyboard
On Mon, Oct 22, 2018 at 09:58:21AM -0700, Dmitry Torokhov wrote:
Hi Sasha,
On Mon, Oct 22, 2018 at 06:19:01AM -0400, Sasha Levin wrote:
From: Daniel Drake
[ Upstream commit 684bec1092b6991ff2a7751e8a763898576eb5c2 ]
Previously, on typical consumer laptops, pressing a key on the keyboard
On Tue, 23 Oct 2018, Mikulas Patocka wrote:
> If you run aptitude on framebuffer console, the display is corrupted. The
> corruption is caused by the commit d8ae7242. The patch adds "offset" to
> "start" when calling scr_memsetw, but it forgets to do the same addition
> on a subsequent call to
On Tue, 23 Oct 2018, Mikulas Patocka wrote:
> If you run aptitude on framebuffer console, the display is corrupted. The
> corruption is caused by the commit d8ae7242. The patch adds "offset" to
> "start" when calling scr_memsetw, but it forgets to do the same addition
> on a subsequent call to
On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote:
>
> And whether that CoC does come with a political agenda or is just being
> *perceived* so, is irrelevant: the perception *is* the reality. And by
> embracing this CoC, Linux is now being perceived as also supporting the
> agenda
On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote:
>
> And whether that CoC does come with a political agenda or is just being
> *perceived* so, is irrelevant: the perception *is* the reality. And by
> embracing this CoC, Linux is now being perceived as also supporting the
> agenda
On Mon, Oct 22, 2018 at 01:50:58PM -0700, Evan Green wrote:
> Add register regions for the second lane of dual-lane nodes.
> This additional specification is needed so that the driver can stop
> reaching beyond the tx and rx register allocations to get at the
> second lane registers in a dual-lane
On Mon, Oct 22, 2018 at 01:50:58PM -0700, Evan Green wrote:
> Add register regions for the second lane of dual-lane nodes.
> This additional specification is needed so that the driver can stop
> reaching beyond the tx and rx register allocations to get at the
> second lane registers in a dual-lane
If you run aptitude on framebuffer console, the display is corrupted. The
corruption is caused by the commit d8ae7242. The patch adds "offset" to
"start" when calling scr_memsetw, but it forgets to do the same addition
on a subsequent call to do_update_region.
Signed-off-by: Mikulas Patocka
If you run aptitude on framebuffer console, the display is corrupted. The
corruption is caused by the commit d8ae7242. The patch adds "offset" to
"start" when calling scr_memsetw, but it forgets to do the same addition
on a subsequent call to do_update_region.
Signed-off-by: Mikulas Patocka
On Tue, Oct 23, 2018 at 09:02:56AM -0600, Shuah Khan wrote:
> Hi Michal,
>
> On 10/23/2018 01:23 AM, Michal Hocko wrote:
> > Hi Shuah,
> >
> > On Mon 22-10-18 18:52:53, Uladzislau Rezki wrote:
> >> On Mon, Oct 22, 2018 at 02:51:42PM +0200, Michal Hocko wrote:
> >>> Hi,
> >>> I haven't read
On Tue, Oct 23, 2018 at 09:02:56AM -0600, Shuah Khan wrote:
> Hi Michal,
>
> On 10/23/2018 01:23 AM, Michal Hocko wrote:
> > Hi Shuah,
> >
> > On Mon 22-10-18 18:52:53, Uladzislau Rezki wrote:
> >> On Mon, Oct 22, 2018 at 02:51:42PM +0200, Michal Hocko wrote:
> >>> Hi,
> >>> I haven't read
On 10/22/2018 02:51 AM, Jiri Olsa wrote:
> On Wed, Oct 17, 2018 at 09:28:16AM -0600, Shuah Khan wrote:
>> On 10/17/2018 07:23 AM, Thomas Renninger wrote:
>>> On Tuesday, October 16, 2018 5:06:05 PM CEST Jiri Olsa wrote:
hi,
while hardening some of the tools rpm, we noticed we
can't
On 10/22/2018 02:51 AM, Jiri Olsa wrote:
> On Wed, Oct 17, 2018 at 09:28:16AM -0600, Shuah Khan wrote:
>> On 10/17/2018 07:23 AM, Thomas Renninger wrote:
>>> On Tuesday, October 16, 2018 5:06:05 PM CEST Jiri Olsa wrote:
hi,
while hardening some of the tools rpm, we noticed we
can't
On s390 the CPU Measurement Facility for counters now supports
2 PMUs named cpum_cf (CPU Measurement Facility for counters) and
cpum_cf_diag (CPU Measurement Facility for diagnostic counters)
for one and the same CPU.
Running command
[root@s35lp76 perf]# ./perf stat -e tx_c_tend \
--
On s390 the CPU Measurement Facility for counters now supports
2 PMUs named cpum_cf (CPU Measurement Facility for counters) and
cpum_cf_diag (CPU Measurement Facility for diagnostic counters)
for one and the same CPU.
Running command
[root@s35lp76 perf]# ./perf stat -e tx_c_tend \
--
On Fri, 2018-10-19 at 13:21 -0700, Paul E. McKenney wrote:
> On Fri, Oct 19, 2018 at 07:45:51PM +, Raslan, KarimAllah wrote:
> >
> > On Fri, 2018-10-19 at 05:31 -0700, Paul E. McKenney wrote:
> > >
> > > On Fri, Oct 19, 2018 at 02:49:05AM +0200, KarimAllah Ahmed wrote:
> > > >
> > > >
> >
On Fri, 2018-10-19 at 13:21 -0700, Paul E. McKenney wrote:
> On Fri, Oct 19, 2018 at 07:45:51PM +, Raslan, KarimAllah wrote:
> >
> > On Fri, 2018-10-19 at 05:31 -0700, Paul E. McKenney wrote:
> > >
> > > On Fri, Oct 19, 2018 at 02:49:05AM +0200, KarimAllah Ahmed wrote:
> > > >
> > > >
> >
Hi Michal,
On 10/23/2018 01:23 AM, Michal Hocko wrote:
> Hi Shuah,
>
> On Mon 22-10-18 18:52:53, Uladzislau Rezki wrote:
>> On Mon, Oct 22, 2018 at 02:51:42PM +0200, Michal Hocko wrote:
>>> Hi,
>>> I haven't read through the implementation yet but I have say that I
>>> really love this cover
Hi Michal,
On 10/23/2018 01:23 AM, Michal Hocko wrote:
> Hi Shuah,
>
> On Mon 22-10-18 18:52:53, Uladzislau Rezki wrote:
>> On Mon, Oct 22, 2018 at 02:51:42PM +0200, Michal Hocko wrote:
>>> Hi,
>>> I haven't read through the implementation yet but I have say that I
>>> really love this cover
On Thu, 11 Oct 2018 16:02:07 -0500
Tom Zanussi wrote:
> From: Tom Zanussi
>
> Add a test case verifying the basic functionality of the
> hist:snapshot() action.
>
I think this is OK for current tracing tree, but for next kernel version
you may need to update it (against the kselftest tree)
On Thu, 11 Oct 2018 16:02:07 -0500
Tom Zanussi wrote:
> From: Tom Zanussi
>
> Add a test case verifying the basic functionality of the
> hist:snapshot() action.
>
I think this is OK for current tracing tree, but for next kernel version
you may need to update it (against the kselftest tree)
This patch fixes a typo in RDMA cgroup documentation.
Signed-off-by: Rami Rosen
---
Documentation/cgroup-v1/rdma.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/cgroup-v1/rdma.txt b/Documentation/cgroup-v1/rdma.txt
index af618171e0eb..9bdb7fd03f83 100644
This patch fixes a typo in RDMA cgroup documentation.
Signed-off-by: Rami Rosen
---
Documentation/cgroup-v1/rdma.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/cgroup-v1/rdma.txt b/Documentation/cgroup-v1/rdma.txt
index af618171e0eb..9bdb7fd03f83 100644
Hi Linus,
please pull the parisc architecture patches and fixes for 4.20-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.20-1
Lots of small fixes and enhancements, most noteably:
- Many TLB and cache flush optimizations (Dave)
- Fixed HPMC/crash
Hi Linus,
please pull the parisc architecture patches and fixes for 4.20-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.20-1
Lots of small fixes and enhancements, most noteably:
- Many TLB and cache flush optimizations (Dave)
- Fixed HPMC/crash
- On Oct 12, 2018, at 10:59 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
> On 11/10/18 20:42, Mathieu Desnoyers wrote:
>> - On Oct 11, 2018, at 1:04 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
>>
>>> On 11/10/18 17:37, Mathieu Desnoyers wrote:
- On Oct 11, 2018, at 12:20
- On Oct 12, 2018, at 10:59 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
> On 11/10/18 20:42, Mathieu Desnoyers wrote:
>> - On Oct 11, 2018, at 1:04 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
>>
>>> On 11/10/18 17:37, Mathieu Desnoyers wrote:
- On Oct 11, 2018, at 12:20
On Tue, Oct 23, 2018 at 4:26 AM Moritz Fischer wrote:
>
> Hi Andreas,
>
> we're getting there :) It seems your mail setup is still a bit
> funky though. Did you use git send-email / git format-patch?
>
> On Tue, Oct 23, 2018 at 09:01:39AM +, Andreas Puhm wrote:
> > From
On Tue, Oct 23, 2018 at 4:26 AM Moritz Fischer wrote:
>
> Hi Andreas,
>
> we're getting there :) It seems your mail setup is still a bit
> funky though. Did you use git send-email / git format-patch?
>
> On Tue, Oct 23, 2018 at 09:01:39AM +, Andreas Puhm wrote:
> > From
HI Dinh,
On Tue, 23 Oct 2018 at 16:04, Dinh Nguyen wrote:
>
> Hi Clément,
>
> On 10/09/2018 06:28 AM, Clément Péron wrote:
> > Cyclone5 and Arria10 doesn't have the same memory map for UART1.
> >
> > Split the SOCFPGA_UART1 into 2 options to allow debugging on UART1 for
> > Cylone5.
> >
>
> I'm
HI Dinh,
On Tue, 23 Oct 2018 at 16:04, Dinh Nguyen wrote:
>
> Hi Clément,
>
> On 10/09/2018 06:28 AM, Clément Péron wrote:
> > Cyclone5 and Arria10 doesn't have the same memory map for UART1.
> >
> > Split the SOCFPGA_UART1 into 2 options to allow debugging on UART1 for
> > Cylone5.
> >
>
> I'm
Hi Tom,
On Thu, 11 Oct 2018 16:02:04 -0500
Tom Zanussi wrote:
> From: Tom Zanussi
>
> Future patches will want to print a histogram key outside a histogram
> - add and use hist_trigger_print_key() for that purpose.
Hmm, I think this change should be done with such user code, because without
Hi Tom,
On Thu, 11 Oct 2018 16:02:04 -0500
Tom Zanussi wrote:
> From: Tom Zanussi
>
> Future patches will want to print a histogram key outside a histogram
> - add and use hist_trigger_print_key() for that purpose.
Hmm, I think this change should be done with such user code, because without
On Wed 2018-10-17 18:54:52, Tetsuo Handa wrote:
> Petr Mladek wrote:
> > On Sat 2018-10-13 13:39:40, Tetsuo Handa wrote:
> > > +struct printk_buffer;
> > > +#if defined(CONFIG_PRINTK_LINE_BUFFERED)
> > > +struct printk_buffer *get_printk_buffer(void);
> > > +void flush_printk_buffer(struct
On Wed 2018-10-17 18:54:52, Tetsuo Handa wrote:
> Petr Mladek wrote:
> > On Sat 2018-10-13 13:39:40, Tetsuo Handa wrote:
> > > +struct printk_buffer;
> > > +#if defined(CONFIG_PRINTK_LINE_BUFFERED)
> > > +struct printk_buffer *get_printk_buffer(void);
> > > +void flush_printk_buffer(struct
On Tue, Oct 23, 2018 at 02:42:03AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:ca9eb48fe01f Merge tag 'regulator-v5.0' of git://git.kerne..
> git tree: upstream
> console output:
On Tue, Oct 23, 2018 at 02:42:03AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:ca9eb48fe01f Merge tag 'regulator-v5.0' of git://git.kerne..
> git tree: upstream
> console output:
Am Dienstag, 23. Oktober 2018, 04:11:44 schrieb Theodore Y. Ts'o:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
> > Yes, you could, and you can. But if it was Linus who was behaving
> > inappropriately, where did you go then? This is why I think whatever
> > "code" we have should
Am Dienstag, 23. Oktober 2018, 04:11:44 schrieb Theodore Y. Ts'o:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
> > Yes, you could, and you can. But if it was Linus who was behaving
> > inappropriately, where did you go then? This is why I think whatever
> > "code" we have should
601 - 700 of 1128 matches
Mail list logo
