Re: Resizeable PCI BAR support V5

Hello Christian, I've running this since you've sent it on-top of amd-staging-4.11. But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), PCIe 2.0, 24 GB is to old for this stuff... [1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 0x-0x0003 64bit]

Re: Resizeable PCI BAR support V5

Hello Christian, I've running this since you've sent it on-top of amd-staging-4.11. But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), PCIe 2.0, 24 GB is to old for this stuff... [1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 0x-0x0003 64bit]

Re: [PATCH v2 04/19] media: camss: Add CSIPHY files

Hi Todor, On Thu, Jun 29, 2017 at 07:36:47PM +0300, Todor Tomov wrote: > >> +/* > >> + * csiphy_link_setup - Setup CSIPHY connections > >> + * @entity: Pointer to media entity structure > >> + * @local: Pointer to local pad > >> + * @remote: Pointer to remote pad > >> + * @flags: Link flags > >>

Re: [PATCH v2 04/19] media: camss: Add CSIPHY files

Hi Todor, On Thu, Jun 29, 2017 at 07:36:47PM +0300, Todor Tomov wrote: > >> +/* > >> + * csiphy_link_setup - Setup CSIPHY connections > >> + * @entity: Pointer to media entity structure > >> + * @local: Pointer to local pad > >> + * @remote: Pointer to remote pad > >> + * @flags: Link flags > >>

Re: [PATCH 1/3] dts: RISC-V vendor prefix

On Thu, 29 Jun 2017 13:35:15 PDT (-0700), r...@kernel.org wrote: > On Mon, Jun 26, 2017 at 10:21:22PM -0700, Palmer Dabbelt wrote: >> RISC-V systems use device tree to specify the memory layout of the >> system. This patch reserves the "riscv" vendor prefix, which will be >> used for devices that

Re: [PATCH 1/3] dts: RISC-V vendor prefix

On Thu, 29 Jun 2017 13:35:15 PDT (-0700), r...@kernel.org wrote: > On Mon, Jun 26, 2017 at 10:21:22PM -0700, Palmer Dabbelt wrote: >> RISC-V systems use device tree to specify the memory layout of the >> system. This patch reserves the "riscv" vendor prefix, which will be >> used for devices that

mmotm 2017-06-29-16-41 uploaded

The mm-of-the-moment snapshot 2017-06-29-16-41 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2017-06-29-16-41 uploaded

The mm-of-the-moment snapshot 2017-06-29-16-41 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

[PATCH] staging: media: atomisp: Remove unnecessary return statement in void function

Return statement at the end of a void function is useless. The Coccinelle semantic patch used to make this change is as follows: // @@ identifier f; expression e; @@ void f(...) { <... - return e; ...> } // Signed-off-by: Amitoj Kaur Chawla ---

[PATCH] staging: media: atomisp: Remove unnecessary return statement in void function

Return statement at the end of a void function is useless. The Coccinelle semantic patch used to make this change is as follows: // @@ identifier f; expression e; @@ void f(...) { <... - return e; ...> } // Signed-off-by: Amitoj Kaur Chawla ---

[PATCH 0/2] Expose VMFUNC to the nested hypervisor

These patches expose eptp switching/vmfunc to the nested hypervisor. Testing with kvm-unit-tests seems to work ok. If the guest hypervisor enables vmfunc/eptp switching, a "shadow" eptp list address page is written to the VMCS. Initially, it would be unpopulated which would result in a vmexit

[PATCH 0/2] Expose VMFUNC to the nested hypervisor

These patches expose eptp switching/vmfunc to the nested hypervisor. Testing with kvm-unit-tests seems to work ok. If the guest hypervisor enables vmfunc/eptp switching, a "shadow" eptp list address page is written to the VMCS. Initially, it would be unpopulated which would result in a vmexit

[PATCH 2/2] KVM: nVMX: Advertise VMFUNC to L1 hypervisor

Advertise VMFUNC and EPTP switching function to the L1 hypervisor. Change nested_vmx_exit_handled() to return false for VMFUNC so L0 can handle it. Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 4 arch/x86/kvm/vmx.c | 18 ++ 2 files

[PATCH 2/2] KVM: nVMX: Advertise VMFUNC to L1 hypervisor

Advertise VMFUNC and EPTP switching function to the L1 hypervisor. Change nested_vmx_exit_handled() to return false for VMFUNC so L0 can handle it. Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 4 arch/x86/kvm/vmx.c | 18 ++ 2 files changed, 22

[PATCH 1/2] KVM: nVMX: Implement EPTP switching for the L1 hypervisor

This is a mix of emulation/passthrough to implement EPTP switching for the nested hypervisor. If the shadow EPT are absent, a vmexit occurs with reason 59. L0 can then create shadow structures based on the entry that the guest calls with to obtain a new root_hpa that can be written to the shadow

[PATCH 1/2] KVM: nVMX: Implement EPTP switching for the L1 hypervisor

This is a mix of emulation/passthrough to implement EPTP switching for the nested hypervisor. If the shadow EPT are absent, a vmexit occurs with reason 59. L0 can then create shadow structures based on the entry that the guest calls with to obtain a new root_hpa that can be written to the shadow

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 02:55:55PM -0700, Dan Williams wrote: > On Thu, Jun 29, 2017 at 2:47 PM, Jerry Hoemann wrote: > > On Thu, Jun 29, 2017 at 02:35:14PM -0700, Dan Williams wrote: > >> On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann > >> wrote: >

Re: [PATCH v3 4/7] acpi, nfit: Use bus_dsm_mask for passthru

On Thu, Jun 29, 2017 at 02:55:55PM -0700, Dan Williams wrote: > On Thu, Jun 29, 2017 at 2:47 PM, Jerry Hoemann wrote: > > On Thu, Jun 29, 2017 at 02:35:14PM -0700, Dan Williams wrote: > >> On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann > >> wrote: > >> > Populate bus_dsm_mask and use it to

Re: [tip:x86/platform] x86/PCI/mmcfg: Switch to ECAM config mode if possible

On Wed, Jun 28, 2017 at 11:45 PM, tip-bot for Thomas Gleixner wrote: > Commit-ID: b5b0f00c760b6e9673ab79b88ede2f3c7a039f74 > Gitweb: http://git.kernel.org/tip/b5b0f00c760b6e9673ab79b88ede2f3c7a039f74 > Author: Thomas Gleixner > AuthorDate: Thu, 16

Re: [PATCH v2] ext4: have ext4_xattr_set_handle() allocate journal credits

On Jun 28, 2017, at 9:06 PM, Tahsin Erdogan wrote: > > Currently, callers of ext4_xattr_set_handle() are expected to allocate > journal credits for setting extended attributes. ext4_xattr_set_credits() > helps them figure out necessary credits. ext4_xattr_set_handle() >

Re: [tip:x86/platform] x86/PCI/mmcfg: Switch to ECAM config mode if possible

On Wed, Jun 28, 2017 at 11:45 PM, tip-bot for Thomas Gleixner wrote: > Commit-ID: b5b0f00c760b6e9673ab79b88ede2f3c7a039f74 > Gitweb: http://git.kernel.org/tip/b5b0f00c760b6e9673ab79b88ede2f3c7a039f74 > Author: Thomas Gleixner > AuthorDate: Thu, 16 Mar 2017 22:50:09 +0100 > Committer:

Re: [PATCH v2] ext4: have ext4_xattr_set_handle() allocate journal credits

On Jun 28, 2017, at 9:06 PM, Tahsin Erdogan wrote: > > Currently, callers of ext4_xattr_set_handle() are expected to allocate > journal credits for setting extended attributes. ext4_xattr_set_credits() > helps them figure out necessary credits. ext4_xattr_set_handle() > performs a sufficient

Re: [PATCH 5/5] sched: Accumulate vtime on top of nsec clocksource

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > From: Wanpeng Li > > Currently the cputime source used by vtime is jiffies. When we cross > a context boundary and jiffies have changed since the last snapshot, > the > pending cputime is accounted to the

Re: [PATCH 5/5] sched: Accumulate vtime on top of nsec clocksource

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > From: Wanpeng Li > > Currently the cputime source used by vtime is jiffies. When we cross > a context boundary and jiffies have changed since the last snapshot, > the > pending cputime is accounted to the switching out context. > >

[PATCH 1/4] selftests: breakpoint_test: use ksft_* var arg msg api

Use ksft_* var arg msg to include strerror() info. in test output. Change output from child process to use ksft_print_msg() instead of ksft_exit_* to avoid double counting tests and ensure parent does the incrementing test counters. Also includes unused variable cleanup. Signed-off-by: Shuah Khan

[PATCH 1/4] selftests: breakpoint_test: use ksft_* var arg msg api

Use ksft_* var arg msg to include strerror() info. in test output. Change output from child process to use ksft_print_msg() instead of ksft_exit_* to avoid double counting tests and ensure parent does the incrementing test counters. Also includes unused variable cleanup. Signed-off-by: Shuah Khan

[PATCH 0/4] Convert to TAP13 using ksft_ var arg msg api

This patch series converts breakpoint_test_arm64 to TAP13 output. Uses ksft_ var arg msg functions as needed. Changed to ensure parent is the one that increments test counters. breakpoint_test, step_after_suspend_test, membarrier tests are changed to use ksft_ var arg msg functions as needed.

[PATCH 3/4] selftests: breakpoints: breakpoint_test_arm64: convert test to use TAP13

Convert breakpoint_test_arm64 output to TAP13 format. Use ksft_* var arg msg api to include strerror() info. in the output. Change output from child process to use ksft_print_msg() instead of ksft_exit_* to avoid double counting tests and ensure parent process does the test counter incrementing.

[PATCH 0/4] Convert to TAP13 using ksft_ var arg msg api

This patch series converts breakpoint_test_arm64 to TAP13 output. Uses ksft_ var arg msg functions as needed. Changed to ensure parent is the one that increments test counters. breakpoint_test, step_after_suspend_test, membarrier tests are changed to use ksft_ var arg msg functions as needed.

[PATCH 3/4] selftests: breakpoints: breakpoint_test_arm64: convert test to use TAP13

Convert breakpoint_test_arm64 output to TAP13 format. Use ksft_* var arg msg api to include strerror() info. in the output. Change output from child process to use ksft_print_msg() instead of ksft_exit_* to avoid double counting tests and ensure parent process does the test counter incrementing.

[PATCH 4/4] selftests: membarrier: use ksft_* var arg msg api

Use ksft_* var arg msg to include strerror() info. in test output. Remove redundant SKIP/FAIL/PASS logic as it is no longer needed with ksft_ api. Improve test output to be consistent and clear. Signed-off-by: Shuah Khan ---

[PATCH 2/4] selftests: breakpoints: step_after_suspend_test use ksft_* var arg msg api

Use ksft_* var arg msg to include strerror() info. in test output and simplify test_result and exit_* using var arg msg api. Signed-off-by: Shuah Khan --- .../breakpoints/step_after_suspend_test.c | 59 -- 1 file changed, 33 insertions(+),

[PATCH 4/4] selftests: membarrier: use ksft_* var arg msg api

Use ksft_* var arg msg to include strerror() info. in test output. Remove redundant SKIP/FAIL/PASS logic as it is no longer needed with ksft_ api. Improve test output to be consistent and clear. Signed-off-by: Shuah Khan --- .../testing/selftests/membarrier/membarrier_test.c | 91

[PATCH 2/4] selftests: breakpoints: step_after_suspend_test use ksft_* var arg msg api

Use ksft_* var arg msg to include strerror() info. in test output and simplify test_result and exit_* using var arg msg api. Signed-off-by: Shuah Khan --- .../breakpoints/step_after_suspend_test.c | 59 -- 1 file changed, 33 insertions(+), 26 deletions(-) diff

Re: [PATCH v2 03/10] Documentation: Add device tree binding for Goldfish PIC driver

On Wed, Jun 28, 2017 at 10:46 AM, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Add documentation for DT binding of Goldfish PIC driver. The compatible > string used by OS for binding the driver is "google,goldfish-pic".

Re: [PATCH v2 03/10] Documentation: Add device tree binding for Goldfish PIC driver

On Wed, Jun 28, 2017 at 10:46 AM, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Add documentation for DT binding of Goldfish PIC driver. The compatible > string used by OS for binding the driver is "google,goldfish-pic". This isn't even supported in Google's common kernel tree. If

Re: [PATCH v2] acpi: handle the acpi hotplug schedule error

Hi Rafael, Thanks for your review. On Thu, Jun 29, 2017 at 12:06:20AM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 21, 2017 03:04:34 PM Lee, Chun-Yi wrote: > > Kernel should decrements the reference count of acpi device > > when the scheduling of acpi hotplug work is failed, and > >

Re: [PATCH v2] acpi: handle the acpi hotplug schedule error

Hi Rafael, Thanks for your review. On Thu, Jun 29, 2017 at 12:06:20AM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 21, 2017 03:04:34 PM Lee, Chun-Yi wrote: > > Kernel should decrements the reference count of acpi device > > when the scheduling of acpi hotplug work is failed, and > >

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

Hi Hans, On 06/29/2017 06:24 AM, Hans de Goede wrote: Hi, On 29-06-17 14:30, Andy Shevchenko wrote: +Cc: Hans On Mon, Jun 26, 2017 at 8:37 PM, wrote: From: Kuppuswamy Sathyanarayanan According to

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 06:58 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers > wrote: >>> The parent region of the namespace will have a 'volatile' type: >>> >>> # cat /sys/bus/nd/devices/region0/devtype >>> nd_volatile >> >> >> If all I know is the

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

Hi Hans, On 06/29/2017 06:24 AM, Hans de Goede wrote: Hi, On 29-06-17 14:30, Andy Shevchenko wrote: +Cc: Hans On Mon, Jun 26, 2017 at 8:37 PM, wrote: From: Kuppuswamy Sathyanarayanan According to Whiskey Cove PMIC GPIO controller specification, for GPIO pins 0-12, GPIO input and output

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 06:58 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers > wrote: >>> The parent region of the namespace will have a 'volatile' type: >>> >>> # cat /sys/bus/nd/devices/region0/devtype >>> nd_volatile >> >> >> If all I know is the /dev/pmem device name, how do

Re: [PATCH v2 06/10] Documentation: Add device tree binding for Goldfish FB driver

On Wed, Jun 28, 2017 at 10:46 AM, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Add documentation for DT binding of Goldfish FB driver. The compatible > string used by OS for binding the driver is "google,goldfish-fb". >

Re: [PATCH v2 06/10] Documentation: Add device tree binding for Goldfish FB driver

On Wed, Jun 28, 2017 at 10:46 AM, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Add documentation for DT binding of Goldfish FB driver. The compatible > string used by OS for binding the driver is "google,goldfish-fb". > > Signed-off-by: Miodrag Dinic > Signed-off-by: Goran Ferenc

Re: [RFC 2/2] soc: bcm: brcmstb: PM: Implement target_state callback

On Thursday, June 22, 2017 06:08:37 PM Florian Fainelli wrote: > Provide a target_state callback implementation which just returns the > suspend_state_t the system is about to enter. Broadcom STB drivers can > utilize platform_suspend_target_state() to retrieve that and take > appropriate actions

Re: [RFC 2/2] soc: bcm: brcmstb: PM: Implement target_state callback

On Thursday, June 22, 2017 06:08:37 PM Florian Fainelli wrote: > Provide a target_state callback implementation which just returns the > suspend_state_t the system is about to enter. Broadcom STB drivers can > utilize platform_suspend_target_state() to retrieve that and take > appropriate actions

Re: [RFC 1/2] PM / suspend: Add platform_suspend_target_state()

On Thursday, June 22, 2017 06:08:36 PM Florian Fainelli wrote: > Add an optional platform_suspend_ops callback: target_state, and a > helper function globally visible to get this called: > platform_suspend_target_state(). > > This is useful for platform specific drivers that may need to take a >

Re: [RFC 1/2] PM / suspend: Add platform_suspend_target_state()

On Thursday, June 22, 2017 06:08:36 PM Florian Fainelli wrote: > Add an optional platform_suspend_ops callback: target_state, and a > helper function globally visible to get this called: > platform_suspend_target_state(). > > This is useful for platform specific drivers that may need to take a >

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, 29 Jun 2017 16:00:32 -0700, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 3:53 PM, Jakub Kicinski > wrote: > > On Fri, 30 Jun 2017 00:50:03 +0200, Luis R. Rodriguez wrote: > >> On Thu, Jun 29, 2017 at 01:58:22PM -0700, Jakub Kicinski wrote: > >> > On

Re: [PATCH v2] rpmsg: Make modalias work for DeviceTree based devices

On Wed, Jun 28, 2017 at 5:53 PM, Bjorn Andersson wrote: > When rpmsg devices are expected to be matched based on their compatible > the modalias should reflect this, so that module autoloading has a > chance to match and load the appropriate module. > > Tested-by: Rob

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, 29 Jun 2017 16:00:32 -0700, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 3:53 PM, Jakub Kicinski > wrote: > > On Fri, 30 Jun 2017 00:50:03 +0200, Luis R. Rodriguez wrote: > >> On Thu, Jun 29, 2017 at 01:58:22PM -0700, Jakub Kicinski wrote: > >> > On Thu, 29 Jun 2017 21:44:55

Re: [PATCH v2] rpmsg: Make modalias work for DeviceTree based devices

On Wed, Jun 28, 2017 at 5:53 PM, Bjorn Andersson wrote: > When rpmsg devices are expected to be matched based on their compatible > the modalias should reflect this, so that module autoloading has a > chance to match and load the appropriate module. > > Tested-by: Rob Clark > Reported-by: Rob

Re: [RESEND PATCH] spmi: Include OF based modalias in device uevent

On Thu, Jun 29, 2017 at 5:46 PM, Bjorn Andersson wrote: > Include the OF-based modalias in the uevent sent when registering SPMI > devices, so that user space has a chance to autoload the kernel module > for the device. > > Tested-by: Rob Clark >

Re: [RESEND PATCH] spmi: Include OF based modalias in device uevent

On Thu, Jun 29, 2017 at 5:46 PM, Bjorn Andersson wrote: > Include the OF-based modalias in the uevent sent when registering SPMI > devices, so that user space has a chance to autoload the kernel module > for the device. > > Tested-by: Rob Clark > Reported-by: Rob Clark > Reviewed-by: Stephen

Re: [PATCH 4/5] sched: Move vtime task fields to their own struct

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > We are about to add vtime accumulation fields to the task struct. > Let's > avoid more bloatification and gather vtime informations to their own > struct. > > Cc: Wanpeng Li > Cc: Rik van Riel

Re: [PATCH 4/5] sched: Move vtime task fields to their own struct

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > We are about to add vtime accumulation fields to the task struct. > Let's > avoid more bloatification and gather vtime informations to their own > struct. > > Cc: Wanpeng Li > Cc: Rik van Riel > Cc: Peter Zijlstra > Cc: Thomas

[PATCH] mm: Fix overflow check in expand_upwards()

I believe the overflow check was correct, then got subtly broken by commit bd726c90b6b8 Author: Helge Deller Date: Mon Jun 19 17:34:05 2017 +0200 Allow stack to grow up to address space limit The old overflow check may have been a bit subtle

[PATCH] mm: Fix overflow check in expand_upwards()

I believe the overflow check was correct, then got subtly broken by commit bd726c90b6b8 Author: Helge Deller Date: Mon Jun 19 17:34:05 2017 +0200 Allow stack to grow up to address space limit The old overflow check may have been a bit subtle and I suppose

Re: [PATCH 3/5] sched: Rename vtime fields

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > The current "snapshot" based naming on vtime fields suggests we > record > some past event but that's a low level picture of their actual > purpose > which comes out blurry. The real point of these fields is to run a > basic > state

Re: [PATCH 3/5] sched: Rename vtime fields

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > The current "snapshot" based naming on vtime fields suggests we > record > some past event but that's a low level picture of their actual > purpose > which comes out blurry. The real point of these fields is to run a > basic > state

Re: [PATCH 2/5] sched: Always set vtime_snap_whence after accounting vtime

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > Even though it doesn't have functional consequences, setting > the task's new context state after we actually accounted the pending > vtime from the old context state makes more sense from a review > perspective. > >

Re: [PATCH 2/5] sched: Always set vtime_snap_whence after accounting vtime

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > Even though it doesn't have functional consequences, setting > the task's new context state after we actually accounted the pending > vtime from the old context state makes more sense from a review > perspective. > >

Re: [PATCH 1/5] vtime: Remove vtime_account_user()

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > It's an unnecessary function between vtime_user_exit() and > account_user_time(). > > Cc: Wanpeng Li > Cc: Rik van Riel > Cc: Peter Zijlstra > Cc: Thomas Gleixner

Re: [PATCH 1/5] vtime: Remove vtime_account_user()

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > It's an unnecessary function between vtime_user_exit() and > account_user_time(). > > Cc: Wanpeng Li > Cc: Rik van Riel > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Luiz Capitulino > Signed-off-by:

[PATCH] libnvdimm, btt: fix btt_rw_page not returning errors

btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any IO errors via the rw_page path going unnoticed. the pmem driver recently fixed this in e10624f pmem: fail io-requests to known bad blocks but same problem in BTT went neglected. Fixes: 5212e11 nd_btt: atomic sector updates

[PATCH] libnvdimm, btt: fix btt_rw_page not returning errors

btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any IO errors via the rw_page path going unnoticed. the pmem driver recently fixed this in e10624f pmem: fail io-requests to known bad blocks but same problem in BTT went neglected. Fixes: 5212e11 nd_btt: atomic sector updates

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 3:53 PM, Jakub Kicinski wrote: > On Fri, 30 Jun 2017 00:50:03 +0200, Luis R. Rodriguez wrote: >> On Thu, Jun 29, 2017 at 01:58:22PM -0700, Jakub Kicinski wrote: >> > On Thu, 29 Jun 2017 21:44:55 +0200, Luis R. Rodriguez wrote: >> > > > Since

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 3:53 PM, Jakub Kicinski wrote: > On Fri, 30 Jun 2017 00:50:03 +0200, Luis R. Rodriguez wrote: >> On Thu, Jun 29, 2017 at 01:58:22PM -0700, Jakub Kicinski wrote: >> > On Thu, 29 Jun 2017 21:44:55 +0200, Luis R. Rodriguez wrote: >> > > > Since this swake_up() -->

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

--Andy > On Jun 29, 2017, at 2:41 PM, Josh Poimboeuf wrote: > >> On Thu, Jun 29, 2017 at 02:09:54PM -0700, Andy Lutomirski wrote: >>> On Thu, Jun 29, 2017 at 12:05 PM, Josh Poimboeuf >>> wrote: On Thu, Jun 29, 2017 at 11:50:18AM -0700, Andy

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers wrote: >> The parent region of the namespace will have a 'volatile' type: >> >> # cat /sys/bus/nd/devices/region0/devtype >> nd_volatile > > > If all I know is the /dev/pmem device name, how do I find that? > cat

Re: [PATCH v2 6/8] x86/entry: add unwind hint annotations

--Andy > On Jun 29, 2017, at 2:41 PM, Josh Poimboeuf wrote: > >> On Thu, Jun 29, 2017 at 02:09:54PM -0700, Andy Lutomirski wrote: >>> On Thu, Jun 29, 2017 at 12:05 PM, Josh Poimboeuf >>> wrote: On Thu, Jun 29, 2017 at 11:50:18AM -0700, Andy Lutomirski wrote: > On Thu, Jun 29, 2017

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers wrote: >> The parent region of the namespace will have a 'volatile' type: >> >> # cat /sys/bus/nd/devices/region0/devtype >> nd_volatile > > > If all I know is the /dev/pmem device name, how do I find that? > cat $(readlink -f

Re: [PATCH 5/9] RISC-V: Task implementation

On Thu, 29 Jun 2017 01:22:23 PDT (-0700), tklau...@distanz.ch wrote: > On 2017-06-28 at 20:55:34 +0200, Palmer Dabbelt wrote: > [...] >> diff --git a/arch/riscv/include/asm/kprobes.h >> b/arch/riscv/include/asm/kprobes.h >> new file mode 100644 >> index

Re: [PATCH 5/9] RISC-V: Task implementation

On Thu, 29 Jun 2017 01:22:23 PDT (-0700), tklau...@distanz.ch wrote: > On 2017-06-28 at 20:55:34 +0200, Palmer Dabbelt wrote: > [...] >> diff --git a/arch/riscv/include/asm/kprobes.h >> b/arch/riscv/include/asm/kprobes.h >> new file mode 100644 >> index ..1190de7a0f74 >> ---

Re: [PATCH 2/4] swait: add the missing killable swaits

On Fri, 30 Jun 2017 00:50:03 +0200, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 01:58:22PM -0700, Jakub Kicinski wrote: > > On Thu, 29 Jun 2017 21:44:55 +0200, Luis R. Rodriguez wrote: > > > > Since this swake_up() --> swake_up_all() reportedly *fixed* the one > > > > wake up > > > >

Re: [PATCH 2/4] swait: add the missing killable swaits

On Fri, 30 Jun 2017 00:50:03 +0200, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 01:58:22PM -0700, Jakub Kicinski wrote: > > On Thu, 29 Jun 2017 21:44:55 +0200, Luis R. Rodriguez wrote: > > > > Since this swake_up() --> swake_up_all() reportedly *fixed* the one > > > > wake up > > > >

Re: [PATCH 1/9] RISC-V: Init and Halt Code

On Thu, 29 Jun 2017 02:44:32 PDT (-0700), ge...@linux-m68k.org wrote: > Hi Palmer, > > On Wed, Jun 28, 2017 at 8:55 PM, Palmer Dabbelt wrote: >> This contains the various __init C functions, the initial assembly >> kernel entry point, and the code to reset the system. When a

Re: [PATCH 1/9] RISC-V: Init and Halt Code

On Thu, 29 Jun 2017 02:44:32 PDT (-0700), ge...@linux-m68k.org wrote: > Hi Palmer, > > On Wed, Jun 28, 2017 at 8:55 PM, Palmer Dabbelt wrote: >> This contains the various __init C functions, the initial assembly >> kernel entry point, and the code to reset the system. When a file was >>

Re: [PATCH 6/9] RISC-V: Device, timer, IRQs, and the SBI

On Thu, 29 Jun 2017 01:39:25 PDT (-0700), tklau...@distanz.ch wrote: > On 2017-06-28 at 20:55:35 +0200, Palmer Dabbelt wrote: > [...] >> diff --git a/arch/riscv/include/asm/device.h >> b/arch/riscv/include/asm/device.h >> new file mode 100644 >> index

Re: [PATCH 6/9] RISC-V: Device, timer, IRQs, and the SBI

On Thu, 29 Jun 2017 01:39:25 PDT (-0700), tklau...@distanz.ch wrote: > On 2017-06-28 at 20:55:35 +0200, Palmer Dabbelt wrote: > [...] >> diff --git a/arch/riscv/include/asm/device.h >> b/arch/riscv/include/asm/device.h >> new file mode 100644 >> index ..28975e528d2f >> --- /dev/null

Re: [PATCH 5/9] RISC-V: Task implementation

On Wed, 28 Jun 2017 16:32:55 PDT (-0700), james.ho...@imgtec.com wrote: > On Wed, Jun 28, 2017 at 11:55:34AM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/include/asm/kprobes.h >> b/arch/riscv/include/asm/kprobes.h >> new file mode 100644 >> index ..1190de7a0f74 >> ---

Re: [PATCH v2 04/20] gcc-plugins: Add the randstruct plugin

On Thu, Jun 29, 2017 at 3:08 PM, Arnd Bergmann wrote: > On Fri, May 26, 2017 at 10:17 PM, Kees Cook wrote: > I noticed new build errors that bisected back to this patch, which has > now showed up > in linux-next again: (FWIW this is randstruct not initify,

Re: [PATCH 5/9] RISC-V: Task implementation

On Wed, 28 Jun 2017 16:32:55 PDT (-0700), james.ho...@imgtec.com wrote: > On Wed, Jun 28, 2017 at 11:55:34AM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/include/asm/kprobes.h >> b/arch/riscv/include/asm/kprobes.h >> new file mode 100644 >> index ..1190de7a0f74 >> ---

Re: [PATCH v2 04/20] gcc-plugins: Add the randstruct plugin

On Thu, Jun 29, 2017 at 3:08 PM, Arnd Bergmann wrote: > On Fri, May 26, 2017 at 10:17 PM, Kees Cook wrote: > I noticed new build errors that bisected back to this patch, which has > now showed up > in linux-next again: (FWIW this is randstruct not initify, and has been in -next for a couple

Re: [PATCH v3 7/7] acpi, nfit: override mask

On Thu, Jun 29, 2017 at 3:18 PM, Jerry Hoemann wrote: > On Thu, Jun 29, 2017 at 02:16:17PM -0700, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: >> > Have module parameter override_dsm_mask override the dsm_mask for >> >

Re: [PATCH v3 7/7] acpi, nfit: override mask

On Thu, Jun 29, 2017 at 3:18 PM, Jerry Hoemann wrote: > On Thu, Jun 29, 2017 at 02:16:17PM -0700, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 9:56 AM, Jerry Hoemann wrote: >> > Have module parameter override_dsm_mask override the dsm_mask for >> > root calls like it does for non-root dsm

Re: [PATCH 2/4] swait: add the missing killable swaits

to actually have fixed most issues considering optional firmware. ie, I expect the combination of both to fix your issues, not just the last series I just posted [0]. If you want this in git form you can find all of the patches bundled on the 20170629-fw-fixes-wait-v4 branch [1]. I just wrote this

Re: [PATCH 2/4] swait: add the missing killable swaits

to actually have fixed most issues considering optional firmware. ie, I expect the combination of both to fix your issues, not just the last series I just posted [0]. If you want this in git form you can find all of the patches bundled on the 20170629-fw-fixes-wait-v4 branch [1]. I just wrote this

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 6/29/2017 6:43 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers wrote: On 06/29/2017 06:28 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers wrote: [..] The /dev/pmem device name just tells you

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 6/29/2017 6:43 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers wrote: On 06/29/2017 06:28 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers wrote: [..] The /dev/pmem device name just tells you that your block device is hosted by a driver

Re: [PATCH v4 2/2] fs/dcache.c: fix spin lockup issue on nlru->lock

On Thu, 29 Jun 2017 09:09:35 +0530 Sahitya Tummala wrote: > __list_lru_walk_one() acquires nlru spin lock (nlru->lock) for > longer duration if there are more number of items in the lru list. > As per the current code, it can hold the spin lock for upto maximum >

Re: [PATCH v4 2/2] fs/dcache.c: fix spin lockup issue on nlru->lock

On Thu, 29 Jun 2017 09:09:35 +0530 Sahitya Tummala wrote: > __list_lru_walk_one() acquires nlru spin lock (nlru->lock) for > longer duration if there are more number of items in the lru list. > As per the current code, it can hold the spin lock for upto maximum > UINT_MAX entries at a time. So

Re: [PATCHv3 4/4] hwmon: da9052: add support for TSI channel

On Thu, Jun 29, 2017 at 11:45:21AM -0700, Dmitry Torokhov wrote: > Hi Sebastian, > > On Thu, Jun 29, 2017 at 02:43:46PM +0200, Sebastian Reichel wrote: > > @@ -238,6 +239,14 @@ static int da9052_ts_probe(struct platform_device > > *pdev) > > if (!da9052) > > return -EINVAL; > >

Re: [PATCHv3 4/4] hwmon: da9052: add support for TSI channel

On Thu, Jun 29, 2017 at 11:45:21AM -0700, Dmitry Torokhov wrote: > Hi Sebastian, > > On Thu, Jun 29, 2017 at 02:43:46PM +0200, Sebastian Reichel wrote: > > @@ -238,6 +239,14 @@ static int da9052_ts_probe(struct platform_device > > *pdev) > > if (!da9052) > > return -EINVAL; > >

Re: [PATCH v2] PCI / PM: Avoid using device_may_wakeup() for runtime PM

On Friday, June 23, 2017 02:58:11 PM Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > pci_target_state() calls device_may_wakeup() which checks whether > or not the device may wake up the system from sleep states, but > pci_target_state() is used for runtime PM

Re: [PATCH v2] PCI / PM: Avoid using device_may_wakeup() for runtime PM

On Friday, June 23, 2017 02:58:11 PM Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > pci_target_state() calls device_may_wakeup() which checks whether > or not the device may wake up the system from sleep states, but > pci_target_state() is used for runtime PM too. > > Since runtime PM

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers wrote: > On 06/29/2017 06:28 PM, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers >> wrote: >> [..] The /dev/pmem device name just tells you that your block device is

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers wrote: > On 06/29/2017 06:28 PM, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers >> wrote: >> [..] The /dev/pmem device name just tells you that your block device is hosted by a driver that knows how to handle

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

On Tue, Jun 27, 2017 at 12:10 AM, Scott Branden wrote: > Hi Rob/Florian, > > Thanks for input but still don't see any need for SoC specific > compatible stings. IP revision specific yes. > > > On 17-06-22 06:04 PM, Florian Fainelli wrote: >> >> On 06/22/2017 05:42 PM,

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

On Tue, Jun 27, 2017 at 12:10 AM, Scott Branden wrote: > Hi Rob/Florian, > > Thanks for input but still don't see any need for SoC specific > compatible stings. IP revision specific yes. > > > On 17-06-22 06:04 PM, Florian Fainelli wrote: >> >> On 06/22/2017 05:42 PM, Scott Branden wrote: >>>

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