Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

On Mon, 2017-08-28 at 11:37 +0200, Peter Zijlstra wrote: > > Doing all this job and just give up because we cannot allocate page tables > > looks very wasteful to me. > > > > Have you considered to look how we can hand over from speculative to > > non-speculative path without starting from

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

On Mon, 2017-08-28 at 11:37 +0200, Peter Zijlstra wrote: > > Doing all this job and just give up because we cannot allocate page tables > > looks very wasteful to me. > > > > Have you considered to look how we can hand over from speculative to > > non-speculative path without starting from

Re: boot failure with 4.13.0-rc6 due to ATA errors

Hello, On Mon, Aug 28, 2017 at 02:26:52PM -0600, David Ahern wrote: > On 8/28/17 1:59 PM, Tejun Heo wrote: > > Can you please verify whether 818831c8b22f ("libata: implement > > SECURITY PROTOCOL IN/OUT") is the culprit? ie. try to boot the commit > > to verify that the problem is there, and try

Re: boot failure with 4.13.0-rc6 due to ATA errors

Hello, On Mon, Aug 28, 2017 at 02:26:52PM -0600, David Ahern wrote: > On 8/28/17 1:59 PM, Tejun Heo wrote: > > Can you please verify whether 818831c8b22f ("libata: implement > > SECURITY PROTOCOL IN/OUT") is the culprit? ie. try to boot the commit > > to verify that the problem is there, and try

Re: [PATCH 2/6] nbd: make device_attribute const

On 08/21/2017 05:43 AM, Bhumika Goyal wrote: > Make this const as is is only passed as an argument to the > function device_create_file and device_remove_file and the corresponding > arguments are of type const. > Done using Coccinelle Added for 4.14, thanks. -- Jens Axboe

Re: [PATCH 2/6] nbd: make device_attribute const

On 08/21/2017 05:43 AM, Bhumika Goyal wrote: > Make this const as is is only passed as an argument to the > function device_create_file and device_remove_file and the corresponding > arguments are of type const. > Done using Coccinelle Added for 4.14, thanks. -- Jens Axboe

Re: [PATCH v4 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, Aug 28, 2017 at 10:55:07PM +0200, Rafael J. Wysocki wrote: > So what about the [3-5/5] in this series? > > My current plan is to apply them too and expose a branch with them, can I > go ahead with that? No, please expose a branch with only the ACPI patches, i.e., 1 and 2 and I can merge

Re: [PATCH v4 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, Aug 28, 2017 at 10:55:07PM +0200, Rafael J. Wysocki wrote: > So what about the [3-5/5] in this series? > > My current plan is to apply them too and expose a branch with them, can I > go ahead with that? No, please expose a branch with only the ACPI patches, i.e., 1 and 2 and I can merge

Re: [PATCH 1/2] mtd: spi-nor: add an option to force 3byte adressing mode

On Mon, Aug 28, 2017 at 11:14 PM, Marcin Wojtas wrote: > Hitherto code set 4B addressing mode for all SPI flashes whose > size exceeds 16MB. However, changing the default 3B access > in some cases may be harmful - it may happen that the Boot ROM > is not capable of handling

Re: [PATCH 1/2] mtd: spi-nor: add an option to force 3byte adressing mode

On Mon, Aug 28, 2017 at 11:14 PM, Marcin Wojtas wrote: > Hitherto code set 4B addressing mode for all SPI flashes whose > size exceeds 16MB. However, changing the default 3B access > in some cases may be harmful - it may happen that the Boot ROM > is not capable of handling non-default state of

Re: [PATCH v2 1/2] dt-bindings: leds: gpio: Add optional retain-state-shutdown property

On Mon, Aug 28, 2017 at 5:19 AM, Pavel Machek wrote: > On Mon 2017-08-28 09:47:10, Andrew Jeffery wrote: >> On Baseboard Management Controller (BMC) systems it's sometimes >> necessary for a LED to retain its state across a BMC reset (which is >> independent of the host system

Re: [PATCH v2 1/2] dt-bindings: leds: gpio: Add optional retain-state-shutdown property

On Mon, Aug 28, 2017 at 5:19 AM, Pavel Machek wrote: > On Mon 2017-08-28 09:47:10, Andrew Jeffery wrote: >> On Baseboard Management Controller (BMC) systems it's sometimes >> necessary for a LED to retain its state across a BMC reset (which is >> independent of the host system state). Add a

[PATCH 1/2] mtd: spi-nor: add an option to force 3byte adressing mode

Hitherto code set 4B addressing mode for all SPI flashes whose size exceeds 16MB. However, changing the default 3B access in some cases may be harmful - it may happen that the Boot ROM is not capable of handling non-default state of the SPI NOR (e.g. after soft reset). Some flash devices allow to

[PATCH 1/2] mtd: spi-nor: add an option to force 3byte adressing mode

Hitherto code set 4B addressing mode for all SPI flashes whose size exceeds 16MB. However, changing the default 3B access in some cases may be harmful - it may happen that the Boot ROM is not capable of handling non-default state of the SPI NOR (e.g. after soft reset). Some flash devices allow to

[PATCH 0/2] SPI NOR - force 3byte addressing mode

Hi, This very short patchset introduces optional forcing via DT 3byte addressing mode for accessing the SPI flash, whose size exceeds 16MiB. It can be used in case the device does not support SPI_NOR_4B_OPCODES and helps overcome an issue, when the Boot ROM cannot handle non-default settings

[PATCH 0/2] SPI NOR - force 3byte addressing mode

Hi, This very short patchset introduces optional forcing via DT 3byte addressing mode for accessing the SPI flash, whose size exceeds 16MiB. It can be used in case the device does not support SPI_NOR_4B_OPCODES and helps overcome an issue, when the Boot ROM cannot handle non-default settings

[PATCH 2/2] arm64: dts: marvell: Force 3byte addressing mode for SPI on A7040 DB

Armada 7040 DB boards can be shipped with various models of boot SPI flash devices. An issue can emerge, when their size exceeds 16MB - in such case the kernel driver will switch automatically to 4B addressing mode. Later, in case of soft reset, the Boot ROM will fail to fetch the firmware during

[PATCH 2/2] arm64: dts: marvell: Force 3byte addressing mode for SPI on A7040 DB

Armada 7040 DB boards can be shipped with various models of boot SPI flash devices. An issue can emerge, when their size exceeds 16MB - in such case the kernel driver will switch automatically to 4B addressing mode. Later, in case of soft reset, the Boot ROM will fail to fetch the firmware during

Re: [PATCH] acpi/processor: make function acpi_processor_check_duplicates static

On Tuesday, August 15, 2017 11:46:30 AM CEST Colin King wrote: > From: Colin Ian King > > The function acpi_processor_check_duplicates is local to the source and > does not need to be in global scope, so make it static. > > Cleans up sparse warnings: > symbol

Re: [PATCH] acpi/processor: make function acpi_processor_check_duplicates static

On Tuesday, August 15, 2017 11:46:30 AM CEST Colin King wrote: > From: Colin Ian King > > The function acpi_processor_check_duplicates is local to the source and > does not need to be in global scope, so make it static. > > Cleans up sparse warnings: > symbol 'acpi_processor_check_duplicates'

Re: [PATCH] libnvdimm: clean up command definitions

On Mon, Aug 28, 2017 at 1:50 PM, Jerry Hoemann wrote: > > On Mon, Aug 28, 2017 at 08:45:32AM -0700, Dan Williams wrote: >> Remove the command payloads that do not have an associated libnvdimm >> ioctl. I.e. remove the payloads that would only ever be carried in the >>

Re: [PATCH] libnvdimm: clean up command definitions

On Mon, Aug 28, 2017 at 1:50 PM, Jerry Hoemann wrote: > > On Mon, Aug 28, 2017 at 08:45:32AM -0700, Dan Williams wrote: >> Remove the command payloads that do not have an associated libnvdimm >> ioctl. I.e. remove the payloads that would only ever be carried in the >> ND_CMD_CALL envelope. This

Re: [PATCH v4] acpi: apei: fix the wrong iteration of generic error status block

On Thursday, August 17, 2017 1:43:49 PM CEST Borislav Petkov wrote: > On Thu, Aug 17, 2017 at 08:07:18PM +0800, Dongjiu Geng wrote: > > The revision 0x300 generic error data entry is different > > from the old version, but currently iterating through the > > GHES estatus blocks does not take into

Re: [PATCH v4] acpi: apei: fix the wrong iteration of generic error status block

On Thursday, August 17, 2017 1:43:49 PM CEST Borislav Petkov wrote: > On Thu, Aug 17, 2017 at 08:07:18PM +0800, Dongjiu Geng wrote: > > The revision 0x300 generic error data entry is different > > from the old version, but currently iterating through the > > GHES estatus blocks does not take into

Re: [PATCH 1/6] ACPI: make device_attribute const

On Monday, August 21, 2017 1:43:07 PM CEST Bhumika Goyal wrote: > Make these const as they are only passed as an argument to the function > device_create_file and device_remove_file and the corresponding > arguments are of type const. > Done using Coccinelle > > Signed-off-by: Bhumika Goyal

Re: [PATCH 1/6] ACPI: make device_attribute const

On Monday, August 21, 2017 1:43:07 PM CEST Bhumika Goyal wrote: > Make these const as they are only passed as an argument to the function > device_create_file and device_remove_file and the corresponding > arguments are of type const. > Done using Coccinelle > > Signed-off-by: Bhumika Goyal >

Re: [PATCH v4] ACPI / sysfs: Extend ACPI sysfs to provide access to boot error region

On Saturday, August 19, 2017 1:19:00 AM CEST Luck, Tony wrote: > From: Tony Luck > > The ACPI sysfs interface provides a way to read each ACPI table from > userspace via entries in /sys/firmware/acpi/tables/ > > The BERT table simply provides the size and address of the

Re: [PATCH v4] ACPI / sysfs: Extend ACPI sysfs to provide access to boot error region

On Saturday, August 19, 2017 1:19:00 AM CEST Luck, Tony wrote: > From: Tony Luck > > The ACPI sysfs interface provides a way to read each ACPI table from > userspace via entries in /sys/firmware/acpi/tables/ > > The BERT table simply provides the size and address of the error > record in BIOS

Re: [PATCH v4 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Thursday, August 24, 2017 9:53:48 AM CEST Borislav Petkov wrote: > On Wed, Aug 23, 2017 at 04:54:43PM -0600, Toshi Kani wrote: > > ACPI OEM ID / OEM Table ID / Revision can be used to identify > > a platform based on ACPI firmware info. acpi_blacklisted(), > >

Re: [PATCH v4 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Thursday, August 24, 2017 9:53:48 AM CEST Borislav Petkov wrote: > On Wed, Aug 23, 2017 at 04:54:43PM -0600, Toshi Kani wrote: > > ACPI OEM ID / OEM Table ID / Revision can be used to identify > > a platform based on ACPI firmware info. acpi_blacklisted(), > >

Re: [PATCH] acpi: apei: call into AER handling regardless of severity

On Monday, August 28, 2017 7:11:54 PM CEST Tyler Baicar wrote: > Currently the GHES code only calls into the AER driver for > recoverable type errors. This is incorrect because errors of > other severities do not get logged by the AER driver and do not > get exposed to user space via the AER trace

Re: [PATCH] acpi: apei: call into AER handling regardless of severity

On Monday, August 28, 2017 7:11:54 PM CEST Tyler Baicar wrote: > Currently the GHES code only calls into the AER driver for > recoverable type errors. This is incorrect because errors of > other severities do not get logged by the AER driver and do not > get exposed to user space via the AER trace

Re: [v6 3/4] mm, oom: introduce oom_priority for memory cgroups

On Thu, 24 Aug 2017, Roman Gushchin wrote: > > > Do you have an example, which can't be effectively handled by an approach > > > I'm suggesting? > > > > No, I do not have any which would be _explicitly_ requested but I do > > envision new requirements will emerge. The most probable one would be

Re: [v6 3/4] mm, oom: introduce oom_priority for memory cgroups

On Thu, 24 Aug 2017, Roman Gushchin wrote: > > > Do you have an example, which can't be effectively handled by an approach > > > I'm suggesting? > > > > No, I do not have any which would be _explicitly_ requested but I do > > envision new requirements will emerge. The most probable one would be

Re: [PATCH] libnvdimm: clean up command definitions

On Mon, Aug 28, 2017 at 08:45:32AM -0700, Dan Williams wrote: > Remove the command payloads that do not have an associated libnvdimm > ioctl. I.e. remove the payloads that would only ever be carried in the > ND_CMD_CALL envelope. This prevents userspace from growing unnecessary > dependencies on

Re: [PATCH] libnvdimm: clean up command definitions

On Mon, Aug 28, 2017 at 08:45:32AM -0700, Dan Williams wrote: > Remove the command payloads that do not have an associated libnvdimm > ioctl. I.e. remove the payloads that would only ever be carried in the > ND_CMD_CALL envelope. This prevents userspace from growing unnecessary > dependencies on

Re: [PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP

On Tue, Aug 29, 2017 at 1:24 AM, Bjorn Helgaas wrote: > On Tue, Aug 29, 2017 at 01:09:53AM +0530, Oza Oza wrote: >> On Tue, Aug 29, 2017 at 12:47 AM, Bjorn Helgaas wrote: >> > On Thu, Aug 24, 2017 at 10:34:25AM +0530, Oza Pawandeep wrote: >> >> PCIe spec

Re: [PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP

On Tue, Aug 29, 2017 at 1:24 AM, Bjorn Helgaas wrote: > On Tue, Aug 29, 2017 at 01:09:53AM +0530, Oza Oza wrote: >> On Tue, Aug 29, 2017 at 12:47 AM, Bjorn Helgaas wrote: >> > On Thu, Aug 24, 2017 at 10:34:25AM +0530, Oza Pawandeep wrote: >> >> PCIe spec r3.1, sec 2.3.2 >> >> If CRS software

Re: [PATCH] perf record: enable multiplexing scaling via -R

> So I think we are good to go. to capture multiplexing scaling factor > when sampling simply use the S > modifier. > But to my surprise, newer kernels are not happy with the cmdline: > $ perf record -e cycles:S noploop 1 > Error: > The sys_perf_event_open() syscall returned with 22 (Invalid

Re: [PATCH] perf record: enable multiplexing scaling via -R

> So I think we are good to go. to capture multiplexing scaling factor > when sampling simply use the S > modifier. > But to my surprise, newer kernels are not happy with the cmdline: > $ perf record -e cycles:S noploop 1 > Error: > The sys_perf_event_open() syscall returned with 22 (Invalid

make linkcheckdocs error with 4.13-rc7

On my Fedora 26 desktop (with Sphinx 1.6.3), make linkcheckdocs is failing with InputError: [Errno 2] No such file or directory: '/data/linux-rc/Documentation/output/cec.h.rst'. reST markup error: /data/linux-rc/Documentation/media/uapi/cec/cec-header.rst:9: (SEVERE/4) Problems with

make linkcheckdocs error with 4.13-rc7

On my Fedora 26 desktop (with Sphinx 1.6.3), make linkcheckdocs is failing with InputError: [Errno 2] No such file or directory: '/data/linux-rc/Documentation/output/cec.h.rst'. reST markup error: /data/linux-rc/Documentation/media/uapi/cec/cec-header.rst:9: (SEVERE/4) Problems with

Re: [PATCH] mm, madvise: Ensure poisoned pages are removed from per-cpu lists

On Mon, 28 Aug 2017, Mel Gorman wrote: > Wendy Wang reported off-list that a RAS HWPOISON-SOFT test case failed and > bisected it to the commit 479f854a207c ("mm, page_alloc: defer debugging > checks of pages allocated from the PCP"). The problem is that a page that > was poisoned with madvise()

Re: [PATCH] mm, madvise: Ensure poisoned pages are removed from per-cpu lists

On Mon, 28 Aug 2017, Mel Gorman wrote: > Wendy Wang reported off-list that a RAS HWPOISON-SOFT test case failed and > bisected it to the commit 479f854a207c ("mm, page_alloc: defer debugging > checks of pages allocated from the PCP"). The problem is that a page that > was poisoned with madvise()

Re: iov_iter_pipe warning.

On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote: > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote: > > > currently running v4.11-rc8-75-gf83246089ca0 > > > > > > sunrpc bit is for the other unrelated

Re: iov_iter_pipe warning.

On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote: > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote: > > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote: > > > currently running v4.11-rc8-75-gf83246089ca0 > > > > > > sunrpc bit is for the other unrelated

Re: boot failure with 4.13.0-rc6 due to ATA errors

On 8/28/17 1:59 PM, Tejun Heo wrote: > Can you please verify whether 818831c8b22f ("libata: implement > SECURITY PROTOCOL IN/OUT") is the culprit? ie. try to boot the commit > to verify that the problem is there, and try the one prior? That commit is the problem.

Re: boot failure with 4.13.0-rc6 due to ATA errors

On 8/28/17 1:59 PM, Tejun Heo wrote: > Can you please verify whether 818831c8b22f ("libata: implement > SECURITY PROTOCOL IN/OUT") is the culprit? ie. try to boot the commit > to verify that the problem is there, and try the one prior? That commit is the problem.

Re: [PATCH] leds-PowerNV: Delete an error message for a failed memory allocation in powernv_led_create()

Hi Markus, Thanks for the patch. On 08/27/2017 10:10 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 27 Aug 2017 22:00:22 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the

Re: [PATCH] leds-PowerNV: Delete an error message for a failed memory allocation in powernv_led_create()

Hi Markus, Thanks for the patch. On 08/27/2017 10:10 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 27 Aug 2017 22:00:22 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > >

Re: [PATCH v2 0/2] leds: gpio: Allow retaining state on shutdown

Hi Andrew, Thanks for the update. On 08/28/2017 02:17 AM, Andrew Jeffery wrote: > Hello, > > LEDs controlled by Baseboard Management Controllers (BMCs) are sometimes > required to retain their state across BMC resets. BMC resets may occur whilst > the host is alive, thus the chassis and host

Re: [PATCH v2 0/2] leds: gpio: Allow retaining state on shutdown

Hi Andrew, Thanks for the update. On 08/28/2017 02:17 AM, Andrew Jeffery wrote: > Hello, > > LEDs controlled by Baseboard Management Controllers (BMCs) are sometimes > required to retain their state across BMC resets. BMC resets may occur whilst > the host is alive, thus the chassis and host

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

On Mon, Aug 28, 2017 at 03:17:39PM -0400, Vivien Didelot wrote: > This commit adds a DEBUG_FS dependent DSA core file creating a generic > debug filesystem interface for the DSA switch devices. > > The interface can be mounted with: > > # mount -t debugfs none /sys/kernel/debug > > The dsa

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

On Mon, Aug 28, 2017 at 03:17:39PM -0400, Vivien Didelot wrote: > This commit adds a DEBUG_FS dependent DSA core file creating a generic > debug filesystem interface for the DSA switch devices. > > The interface can be mounted with: > > # mount -t debugfs none /sys/kernel/debug > > The dsa

Re: [PATCH net-next v2 03/10] net: dsa: debugfs: add tag_protocol

On Mon, Aug 28, 2017 at 03:17:41PM -0400, Vivien Didelot wrote: > Add a debug filesystem "tag_protocol" entry to query the switch tagging > protocol through the .get_tag_protocol operation. > > # cat switch1/tag_protocol > EDSA > > To ease maintenance of tag protocols, add a

Re: [PATCH net-next v2 03/10] net: dsa: debugfs: add tag_protocol

On Mon, Aug 28, 2017 at 03:17:41PM -0400, Vivien Didelot wrote: > Add a debug filesystem "tag_protocol" entry to query the switch tagging > protocol through the .get_tag_protocol operation. > > # cat switch1/tag_protocol > EDSA > > To ease maintenance of tag protocols, add a

Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface

> I see this overlaps a lot with DPIPE. Why won't you use that to expose > your hw state? We took a look at dpipe and i talked to you about using it for this sort of thing at netconf/netdev. But dpipe has issues displaying the sort of information we have. I never figured out how to do two

Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface

> I see this overlaps a lot with DPIPE. Why won't you use that to expose > your hw state? We took a look at dpipe and i talked to you about using it for this sort of thing at netconf/netdev. But dpipe has issues displaying the sort of information we have. I never figured out how to do two

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

Mon, Aug 28, 2017 at 09:58:12PM CEST, f.faine...@gmail.com wrote: >On 08/28/2017 12:50 PM, Jiri Pirko wrote: >> Mon, Aug 28, 2017 at 09:17:39PM CEST, vivien.dide...@savoirfairelinux.com >> wrote: >>> This commit adds a DEBUG_FS dependent DSA core file creating a generic >>> debug filesystem

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

Mon, Aug 28, 2017 at 09:58:12PM CEST, f.faine...@gmail.com wrote: >On 08/28/2017 12:50 PM, Jiri Pirko wrote: >> Mon, Aug 28, 2017 at 09:17:39PM CEST, vivien.dide...@savoirfairelinux.com >> wrote: >>> This commit adds a DEBUG_FS dependent DSA core file creating a generic >>> debug filesystem

Re: [PATCH] initramfs: Fix disabling of initramfs (and its compression)

On 05/21/2017 07:46 PM, Nicholas Piggin wrote: > On Sat, 20 May 2017 20:33:35 -0700 > Florian Fainelli wrote: > >> Commit db2aa7fd15e8 ("initramfs: allow again choice of the embedded >> initram compression algorithm") introduced the possibility to select the >> initramfs

Re: [PATCH] initramfs: Fix disabling of initramfs (and its compression)

On 05/21/2017 07:46 PM, Nicholas Piggin wrote: > On Sat, 20 May 2017 20:33:35 -0700 > Florian Fainelli wrote: > >> Commit db2aa7fd15e8 ("initramfs: allow again choice of the embedded >> initram compression algorithm") introduced the possibility to select the >> initramfs compression algorithm

Re: [patch v1 0/2] JTAG driver introduction

Hi! > > Thanks a lot for review. > > > > > We used user space tool for that, which is an adaptation of some > > Lattice tools, which allows programming of SVF files. We are using > > it for Lattice CPLD burning, since we have for such devices on our > > system, but this tool could be used for

Re: [patch v1 0/2] JTAG driver introduction

Hi! > > Thanks a lot for review. > > > > > We used user space tool for that, which is an adaptation of some > > Lattice tools, which allows programming of SVF files. We are using > > it for Lattice CPLD burning, since we have for such devices on our > > system, but this tool could be used for

Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit

On 08/28/2017 09:48 AM, Linus Torvalds wrote: > On Mon, Aug 28, 2017 at 7:51 AM, Liang, Kan wrote: >> >> I tried this patch and https://lkml.org/lkml/2017/8/27/222 together. >> But they don't fix the issue. I can still get the similar call stack. > > So the main issue was

Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit

On 08/28/2017 09:48 AM, Linus Torvalds wrote: > On Mon, Aug 28, 2017 at 7:51 AM, Liang, Kan wrote: >> >> I tried this patch and https://lkml.org/lkml/2017/8/27/222 together. >> But they don't fix the issue. I can still get the similar call stack. > > So the main issue was that I *really* hated

[PATCH] pwm_bl: Fix overflow condition

This fixes and overflow condition that happens with a high value of brightness-levels-scale by using a 64-bit variable. The issue would prevent a range of higher brightness levels from being set. Signed-off-by: Derek Basehore --- drivers/video/backlight/pwm_bl.c | 7

[PATCH] pwm_bl: Fix overflow condition

This fixes and overflow condition that happens with a high value of brightness-levels-scale by using a 64-bit variable. The issue would prevent a range of higher brightness levels from being set. Signed-off-by: Derek Basehore --- drivers/video/backlight/pwm_bl.c | 7 +-- 1 file changed, 5

Re: boot failure with 4.13.0-rc6 due to ATA errors

(cc'ing Christoph) On Mon, Aug 28, 2017 at 12:40:39PM -0600, David Ahern wrote: > Not sure why mailing list to direct this bug report to, so starting with > libata based on the error messages. > > Some where between v4.12 and 4.13.0-rc6 a Celestica redstone switch > fails to boot due to ATA

Re: boot failure with 4.13.0-rc6 due to ATA errors

(cc'ing Christoph) On Mon, Aug 28, 2017 at 12:40:39PM -0600, David Ahern wrote: > Not sure why mailing list to direct this bug report to, so starting with > libata based on the error messages. > > Some where between v4.12 and 4.13.0-rc6 a Celestica redstone switch > fails to boot due to ATA

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

On 08/28/2017 12:50 PM, Jiri Pirko wrote: > Mon, Aug 28, 2017 at 09:17:39PM CEST, vivien.dide...@savoirfairelinux.com > wrote: >> This commit adds a DEBUG_FS dependent DSA core file creating a generic >> debug filesystem interface for the DSA switch devices. >> >> The interface can be mounted

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

On 08/28/2017 12:50 PM, Jiri Pirko wrote: > Mon, Aug 28, 2017 at 09:17:39PM CEST, vivien.dide...@savoirfairelinux.com > wrote: >> This commit adds a DEBUG_FS dependent DSA core file creating a generic >> debug filesystem interface for the DSA switch devices. >> >> The interface can be mounted

Re: [PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP

On Tue, Aug 29, 2017 at 01:09:53AM +0530, Oza Oza wrote: > On Tue, Aug 29, 2017 at 12:47 AM, Bjorn Helgaas wrote: > > On Thu, Aug 24, 2017 at 10:34:25AM +0530, Oza Pawandeep wrote: > >> PCIe spec r3.1, sec 2.3.2 > >> If CRS software visibility is not enabled, the RC must

Re: [PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP

On Tue, Aug 29, 2017 at 01:09:53AM +0530, Oza Oza wrote: > On Tue, Aug 29, 2017 at 12:47 AM, Bjorn Helgaas wrote: > > On Thu, Aug 24, 2017 at 10:34:25AM +0530, Oza Pawandeep wrote: > >> PCIe spec r3.1, sec 2.3.2 > >> If CRS software visibility is not enabled, the RC must reissue the > >> config

Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface

Mon, Aug 28, 2017 at 09:17:38PM CEST, vivien.dide...@savoirfairelinux.com wrote: >This patch series adds a generic debugfs interface for the DSA >framework, so that all switch devices benefit from it, e.g. Marvell, >Broadcom, Microchip or any other DSA driver. > >This is really convenient for

Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface

Mon, Aug 28, 2017 at 09:17:38PM CEST, vivien.dide...@savoirfairelinux.com wrote: >This patch series adds a generic debugfs interface for the DSA >framework, so that all switch devices benefit from it, e.g. Marvell, >Broadcom, Microchip or any other DSA driver. > >This is really convenient for

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

Mon, Aug 28, 2017 at 09:17:39PM CEST, vivien.dide...@savoirfairelinux.com wrote: >This commit adds a DEBUG_FS dependent DSA core file creating a generic >debug filesystem interface for the DSA switch devices. > >The interface can be mounted with: > ># mount -t debugfs none /sys/kernel/debug >

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

Mon, Aug 28, 2017 at 09:17:39PM CEST, vivien.dide...@savoirfairelinux.com wrote: >This commit adds a DEBUG_FS dependent DSA core file creating a generic >debug filesystem interface for the DSA switch devices. > >The interface can be mounted with: > ># mount -t debugfs none /sys/kernel/debug >

[GIT PULL] (xen) stable/for-jens-4.13.. for 4.13-rc7 or 4.14-rc1 if you would like

Hey Jens, Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.13 .. which as a bug-fix when shutting down xen block backend driver with multiple queues and the driver not clearing all of them. Thank you! If you pull it in your

[GIT PULL] (xen) stable/for-jens-4.13.. for 4.13-rc7 or 4.14-rc1 if you would like

Hey Jens, Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.13 .. which as a bug-fix when shutting down xen block backend driver with multiple queues and the driver not clearing all of them. Thank you! If you pull it in your

Re: [PATCH] KVM: MMU: speedup update_permission_bitmask

Looks okay to me, but I'm hoping Peter will chime in. Reviewed-by: Jim Mattson On Thu, Aug 24, 2017 at 8:56 AM, Paolo Bonzini wrote: > update_permission_bitmask currently does a 128-iteration loop to, > essentially, compute a constant array. Computing

Re: [PATCH] KVM: MMU: speedup update_permission_bitmask

Looks okay to me, but I'm hoping Peter will chime in. Reviewed-by: Jim Mattson On Thu, Aug 24, 2017 at 8:56 AM, Paolo Bonzini wrote: > update_permission_bitmask currently does a 128-iteration loop to, > essentially, compute a constant array. Computing the 8 bits in parallel > reduces it to 16

Re: [PATCH 4.12 00/99] 4.12.10-stable review

On 08/28/2017 02:03 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.12.10 release. > There are 99 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.12 00/99] 4.12.10-stable review

On 08/28/2017 02:03 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.12.10 release. > There are 99 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP

On Tue, Aug 29, 2017 at 12:47 AM, Bjorn Helgaas wrote: > On Thu, Aug 24, 2017 at 10:34:25AM +0530, Oza Pawandeep wrote: >> PCIe spec r3.1, sec 2.3.2 >> If CRS software visibility is not enabled, the RC must reissue the >> config request as a new request. >> >> - If CRS

Re: [PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP

On Tue, Aug 29, 2017 at 12:47 AM, Bjorn Helgaas wrote: > On Thu, Aug 24, 2017 at 10:34:25AM +0530, Oza Pawandeep wrote: >> PCIe spec r3.1, sec 2.3.2 >> If CRS software visibility is not enabled, the RC must reissue the >> config request as a new request. >> >> - If CRS software visibility is

Re: [PATCH 4.9 00/84] 4.9.46-stable review

On 08/28/2017 02:04 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.46 release. > There are 84 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 00/84] 4.9.46-stable review

On 08/28/2017 02:04 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.46 release. > There are 84 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/53] 4.4.85-stable review

On 08/28/2017 02:05 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.85 release. > There are 53 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/53] 4.4.85-stable review

On 08/28/2017 02:05 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.85 release. > There are 53 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/22] 3.18.68-stable review

On 08/28/2017 02:05 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.68 release. > There are 22 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/22] 3.18.68-stable review

On 08/28/2017 02:05 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.68 release. > There are 22 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [tip:perf/core] perf/x86: Export some PMU attributes in caps/ directory

> is not intel specific at all.. > > Not very nice. > > Boris, could you give this a spin? Thanks for fixing. I guess could also just have removed the warning, but your patch is better Reviewed-by: Andi Kleen -Andi

Re: [tip:perf/core] perf/x86: Export some PMU attributes in caps/ directory

> is not intel specific at all.. > > Not very nice. > > Boris, could you give this a spin? Thanks for fixing. I guess could also just have removed the warning, but your patch is better Reviewed-by: Andi Kleen -Andi

Re: [PATCH] perf record: enable multiplexing scaling via -R

Hi, On Tue, Aug 22, 2017 at 12:24 AM, Stephane Eranian wrote: > On Tue, Aug 22, 2017 at 12:03 AM, Jiri Olsa wrote: >> >> On Mon, Aug 21, 2017 at 06:25:45PM -0700, Andi Kleen wrote: >> > On Mon, Aug 21, 2017 at 05:13:29PM -0700, Stephane Eranian wrote: >> >

Re: [PATCH] perf record: enable multiplexing scaling via -R

Hi, On Tue, Aug 22, 2017 at 12:24 AM, Stephane Eranian wrote: > On Tue, Aug 22, 2017 at 12:03 AM, Jiri Olsa wrote: >> >> On Mon, Aug 21, 2017 at 06:25:45PM -0700, Andi Kleen wrote: >> > On Mon, Aug 21, 2017 at 05:13:29PM -0700, Stephane Eranian wrote: >> > > On Mon, Aug 21, 2017 at 4:02 PM,

[PATCH net-next v2 07/10] net: dsa: restore mdb dump

The same dsa_fdb_dump_cb_t callback is used since there is no distinction to do between FDB and MDB entries at this layer. Implement mv88e6xxx_port_mdb_dump so that multicast addresses associated to a switch port can be dumped. Signed-off-by: Vivien Didelot

[PATCH net-next v2 07/10] net: dsa: restore mdb dump

The same dsa_fdb_dump_cb_t callback is used since there is no distinction to do between FDB and MDB entries at this layer. Implement mv88e6xxx_port_mdb_dump so that multicast addresses associated to a switch port can be dumped. Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn ---

Re: [PATCH 01/10] perf/x86: Add warning on proper cpu during event's update

On Thu, Aug 24, 2017 at 06:27:28PM +0200, Jiri Olsa wrote: > Mark reported that we could actually call pmu->read on > unscheduled event. I think it's good idea to keep a > warning here to see if we've get it wrong again in > future. > > Reported-by: Mark Rutland >

Re: [PATCH 01/10] perf/x86: Add warning on proper cpu during event's update

On Thu, Aug 24, 2017 at 06:27:28PM +0200, Jiri Olsa wrote: > Mark reported that we could actually call pmu->read on > unscheduled event. I think it's good idea to keep a > warning here to see if we've get it wrong again in > future. > > Reported-by: Mark Rutland > Signed-off-by: Jiri Olsa

<    1   2   3   4   5   6   7   8   9   10   >