Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, 2017-07-19 at 18:22 +0200, Borislav Petkov wrote: > On Wed, Jul 19, 2017 at 04:10:07PM +, Kani, Toshimitsu wrote: > > I do prefer to avoid any white / black listing.  But I do not see > > how it solves the buggy DMI/SMBIOS info as an example of firmware > > bugs we may have to deal

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, 2017-07-19 at 18:22 +0200, Borislav Petkov wrote: > On Wed, Jul 19, 2017 at 04:10:07PM +, Kani, Toshimitsu wrote: > > I do prefer to avoid any white / black listing.  But I do not see > > how it solves the buggy DMI/SMBIOS info as an example of firmware > > bugs we may have to deal

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Wed, Jul 19, 2017 at 10:03:22AM -0500, Christopher Lameter wrote: > On Wed, 19 Jul 2017, Paul E. McKenney wrote: > > > > Do we have any problem if we skip RCU idle enter/exit under a fast idle > > > scenario? > > > My understanding is, if tick is not stopped, then we don't need inform > > >

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Wed, Jul 19, 2017 at 10:03:22AM -0500, Christopher Lameter wrote: > On Wed, 19 Jul 2017, Paul E. McKenney wrote: > > > > Do we have any problem if we skip RCU idle enter/exit under a fast idle > > > scenario? > > > My understanding is, if tick is not stopped, then we don't need inform > > >

Re: [PATCH v1] crypto: caam - set hwrng quality level

On 7/19/2017 7:32 PM, Oleksij Rempel wrote: > On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote: >> On 7/19/2017 10:45 AM, Oleksij Rempel wrote: >>> According documentation, it is NIST certified TRNG. >>> So, set high quality to let the HWRNG framework automatically use it. >>> >>>

Re: [PATCH v1] crypto: caam - set hwrng quality level

On 7/19/2017 7:32 PM, Oleksij Rempel wrote: > On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote: >> On 7/19/2017 10:45 AM, Oleksij Rempel wrote: >>> According documentation, it is NIST certified TRNG. >>> So, set high quality to let the HWRNG framework automatically use it. >>> >>>

Re: [PATCH 0/6] FlexRM driver improvements

Patch series all looks good. On 17-07-19 02:55 AM, Anup Patel wrote: This patchset does various improvments to Broadcom FlexRM mailbox controller driver and also adds FlexRM DT nodes for Stingray SOC. The patches are based on Linux-4.13-rc1 and can also be found at flexrm-imp-v1 branch of

Re: [PATCH 0/6] FlexRM driver improvements

Patch series all looks good. On 17-07-19 02:55 AM, Anup Patel wrote: This patchset does various improvments to Broadcom FlexRM mailbox controller driver and also adds FlexRM DT nodes for Stingray SOC. The patches are based on Linux-4.13-rc1 and can also be found at flexrm-imp-v1 branch of

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Wed, Jul 19, 2017 at 7:58 AM, Leonard Crestez wrote: > On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote: >> On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez >> wrote: >> > On Tue, 2017-07-18 at 09:04 -0700, Thomas Garnier wrote: >> >

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Wed, Jul 19, 2017 at 7:58 AM, Leonard Crestez wrote: > On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote: >> On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez >> wrote: >> > On Tue, 2017-07-18 at 09:04 -0700, Thomas Garnier wrote: >> > > On Tue, Jul 18, 2017 at 7:36 AM, Leonard Crestez

Re: [PATCH 5/5] vfio: platform: reset: Add Broadcom FlexRM reset module

Hi Anup, NAK - as indicated in internal review please use unmodified Broadcom legal header in its own comment block. On 17-07-19 02:33 AM, Anup Patel wrote: This patch adds low-level reset for Broadcom FlexRM to VFIO platform. It will do the following: 1. Disable/Deactivate each FlexRM

Re: [PATCH 5/5] vfio: platform: reset: Add Broadcom FlexRM reset module

Hi Anup, NAK - as indicated in internal review please use unmodified Broadcom legal header in its own comment block. On 17-07-19 02:33 AM, Anup Patel wrote: This patch adds low-level reset for Broadcom FlexRM to VFIO platform. It will do the following: 1. Disable/Deactivate each FlexRM

Re: [PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders

El Wed, Jul 19, 2017 at 08:30:36AM +0200 Daniel Vetter ha dit: > On Tue, Jul 18, 2017 at 01:48:53PM -0700, Matthias Kaehlcke wrote: > > Hi Daniel, > > > > El Tue, Jul 18, 2017 at 08:39:50AM +0200 Daniel Vetter ha dit: > > > > > On Mon, Jul 17, 2017 at 11:14:03AM -0700, Matthias Kaehlcke wrote:

Re: [PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders

El Wed, Jul 19, 2017 at 08:30:36AM +0200 Daniel Vetter ha dit: > On Tue, Jul 18, 2017 at 01:48:53PM -0700, Matthias Kaehlcke wrote: > > Hi Daniel, > > > > El Tue, Jul 18, 2017 at 08:39:50AM +0200 Daniel Vetter ha dit: > > > > > On Mon, Jul 17, 2017 at 11:14:03AM -0700, Matthias Kaehlcke wrote:

Re: [PATCH] netvsc: Remove redundant use of ipv6_hdr()

On Wed, 19 Jul 2017 15:19:28 +0200 Mohammed Gamal wrote: > This condition already uses an object of type ipv6hdr in the line above. > Use the object directly instead of calling ipv6_hdr > > Signed-off-by: Mohammed Gamal > --- >

Re: [PATCH] netvsc: Remove redundant use of ipv6_hdr()

On Wed, 19 Jul 2017 15:19:28 +0200 Mohammed Gamal wrote: > This condition already uses an object of type ipv6hdr in the line above. > Use the object directly instead of calling ipv6_hdr > > Signed-off-by: Mohammed Gamal > --- > drivers/net/hyperv/netvsc_drv.c | 2 +- > 1 file changed, 1

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Tue, 2017-07-18 at 18:15 -0300, Mauro Carvalho Chehab wrote: > Em Tue, 18 Jul 2017 19:58:54 + : > We had a similar discussion several years ago when I wrote this > driver. On that time, I talked with Red Hat, HP, Dell, Intel people > and with some customers with large clusters. > > The

Re: [PATCH] mm/mremap: Fail map duplication attempts for private mappings

On 07/13/2017 12:11 PM, Vlastimil Babka wrote: > [+CC linux-api] > > On 07/13/2017 05:58 PM, Mike Kravetz wrote: >> mremap will create a 'duplicate' mapping if old_size == 0 is >> specified. Such duplicate mappings make no sense for private >> mappings. If duplication is attempted for a private

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Tue, 2017-07-18 at 18:15 -0300, Mauro Carvalho Chehab wrote: > Em Tue, 18 Jul 2017 19:58:54 + : > We had a similar discussion several years ago when I wrote this > driver. On that time, I talked with Red Hat, HP, Dell, Intel people > and with some customers with large clusters. > > The

Re: [PATCH] mm/mremap: Fail map duplication attempts for private mappings

On 07/13/2017 12:11 PM, Vlastimil Babka wrote: > [+CC linux-api] > > On 07/13/2017 05:58 PM, Mike Kravetz wrote: >> mremap will create a 'duplicate' mapping if old_size == 0 is >> specified. Such duplicate mappings make no sense for private >> mappings. If duplication is attempted for a private

[PATCH] MAINTAINERS: fpga: Update email and add patchwork URL

Add Q: entry for patchwork and update my email address. Signed-off-by: Moritz Fischer Cc: Alan Tull Cc: linux-f...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH] MAINTAINERS: fpga: Update email and add patchwork URL

Add Q: entry for patchwork and update my email address. Signed-off-by: Moritz Fischer Cc: Alan Tull Cc: linux-f...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index

Re: [PATCH 4.12 00/84] 4.12.3-stable review

On 07/19/2017 10:29 AM, kernelci.org bot wrote: > stable-rc/linux-4.12.y boot: 166 boots: 5 failed, 161 passed > (v4.12.2-85-g908a8d27d1c5) > > Full Boot Summary: > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/ > Full Build Summary: >

Re: [PATCH 4.12 00/84] 4.12.3-stable review

On 07/19/2017 10:29 AM, kernelci.org bot wrote: > stable-rc/linux-4.12.y boot: 166 boots: 5 failed, 161 passed > (v4.12.2-85-g908a8d27d1c5) > > Full Boot Summary: > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/ > Full Build Summary: >

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello, Peter. On Wed, Jul 19, 2017 at 04:07:28PM +0200, Peter Zijlstra wrote: > On Tue, Jul 18, 2017 at 02:47:14PM -0400, Tejun Heo wrote: > > Were there other things that caught your eyes? > > I didn't immediately see the point of "domain (threaded" output, and I I'll probably drop the parens

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello, Peter. On Wed, Jul 19, 2017 at 04:07:28PM +0200, Peter Zijlstra wrote: > On Tue, Jul 18, 2017 at 02:47:14PM -0400, Tejun Heo wrote: > > Were there other things that caught your eyes? > > I didn't immediately see the point of "domain (threaded" output, and I I'll probably drop the parens

Re: [PATCH V3 8/9] cpufreq: Add CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING cpufreq driver flag

On Wed, Jul 19, 2017 at 03:42:48PM +0530, Viresh Kumar wrote: > The policy->transition_latency field is used for multiple purposes > today and its not straight forward at all. This is how it is used: > > A. Set the correct transition_latency value. > > B. Set it to CPUFREQ_ETERNAL because: >

Re: [PATCH V3 8/9] cpufreq: Add CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING cpufreq driver flag

On Wed, Jul 19, 2017 at 03:42:48PM +0530, Viresh Kumar wrote: > The policy->transition_latency field is used for multiple purposes > today and its not straight forward at all. This is how it is used: > > A. Set the correct transition_latency value. > > B. Set it to CPUFREQ_ETERNAL because: >

Re: [PATCH v1] crypto: caam - set hwrng quality level

On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote: > On 7/19/2017 10:45 AM, Oleksij Rempel wrote: > > According documentation, it is NIST certified TRNG. > > So, set high quality to let the HWRNG framework automatically use it. > > > > Signed-off-by: Oleksij Rempel

Re: [PATCH v1] crypto: caam - set hwrng quality level

On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote: > On 7/19/2017 10:45 AM, Oleksij Rempel wrote: > > According documentation, it is NIST certified TRNG. > > So, set high quality to let the HWRNG framework automatically use it. > > > > Signed-off-by: Oleksij Rempel > > --- > >

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello, On Tue, Jul 18, 2017 at 01:23:14PM -0400, Waiman Long wrote: > > If we could get rid of the invalid state completely that way, I'd > > completely agree with you but that isn't the case here as you noted > > yourself, so the choice between the two isn't something trivially > > clear. Both

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello, On Tue, Jul 18, 2017 at 01:23:14PM -0400, Waiman Long wrote: > > If we could get rid of the invalid state completely that way, I'd > > completely agree with you but that isn't the case here as you noted > > yourself, so the choice between the two isn't something trivially > > clear. Both

Re: [PATCH v3 3/5] dax: use common 4k zero page for dax mmap reads

On Wed, Jul 19, 2017 at 05:33:14PM +0200, Jan Kara wrote: > On Wed 28-06-17 16:01:50, Ross Zwisler wrote: > > Another major change is that we remove dax_pfn_mkwrite() from our fault > > flow, and instead rely on the page fault itself to make the PTE dirty and > > writeable. The following

Re: [PATCH v3 3/5] dax: use common 4k zero page for dax mmap reads

On Wed, Jul 19, 2017 at 05:33:14PM +0200, Jan Kara wrote: > On Wed 28-06-17 16:01:50, Ross Zwisler wrote: > > Another major change is that we remove dax_pfn_mkwrite() from our fault > > flow, and instead rely on the page fault itself to make the PTE dirty and > > writeable. The following

Re: [PATCH] ath10k_htt_rx_amsdu_allowed(): use ath10k_dbg()

On Wed, 2017-07-19 at 17:37 +0200, Gabriel C wrote: > Each time we get disconencted from AP we get flooded with messages > like: > > ... > ath10k_pci :03:00.0: no channel configured; ignoring frame(s)! > > ath10k_warn: 155 callbacks suppressed

Re: [PATCH] ath10k_htt_rx_amsdu_allowed(): use ath10k_dbg()

On Wed, 2017-07-19 at 17:37 +0200, Gabriel C wrote: > Each time we get disconencted from AP we get flooded with messages > like: > > ... > ath10k_pci :03:00.0: no channel configured; ignoring frame(s)! > > ath10k_warn: 155 callbacks suppressed

[PATCH v4 2/3] of: overlay: correctly apply overlay node with unit-address

From: Frank Rowand Correct existing node name detection when overlay node name has a unit-address. Expected test result is overlay will update the nodes and properties for /testcase-data-2/fairway-1/ride@100/ after this commit. Before this commit: Console error

[PATCH v4 2/3] of: overlay: correctly apply overlay node with unit-address

From: Frank Rowand Correct existing node name detection when overlay node name has a unit-address. Expected test result is overlay will update the nodes and properties for /testcase-data-2/fairway-1/ride@100/ after this commit. Before this commit: Console error message near end of

[PATCH v4 1/3] of: overlay: add overlay unittest data for node names and symbols

From: Frank Rowand Add nodes and properties to overlay_base and overlay dts files to test for - incorrect existing node name detection when overlay node name has a unit-address - adding overlay __symbols__ properties to live tree when an overlay is added to

[PATCH v4 1/3] of: overlay: add overlay unittest data for node names and symbols

From: Frank Rowand Add nodes and properties to overlay_base and overlay dts files to test for - incorrect existing node name detection when overlay node name has a unit-address - adding overlay __symbols__ properties to live tree when an overlay is added to the live tree The

[PATCH v4 3/3] of: overlay: add overlay symbols to live device tree

From: Frank Rowand Add overlay __symbols__ properties to live tree when an overlay is added to the live tree so that the symbols are available to subsequent overlays. Expected test result is new __symbols__ entries for labels from the overlay after this commit. Before

[PATCH v4 0/3] of: overlay: load overlay symbols into live device tree

From: Frank Rowand Symbols in a loaded overlay are not currently available to subsequently loaded overlays because the properties in the overlay's __symbols__ node are not loaded into the live device tree. Patch 1 is unittests to test patches 2 and 3. Patch 2 fixes a

[PATCH v4 3/3] of: overlay: add overlay symbols to live device tree

From: Frank Rowand Add overlay __symbols__ properties to live tree when an overlay is added to the live tree so that the symbols are available to subsequent overlays. Expected test result is new __symbols__ entries for labels from the overlay after this commit. Before this commit: Console

[PATCH v4 0/3] of: overlay: load overlay symbols into live device tree

From: Frank Rowand Symbols in a loaded overlay are not currently available to subsequently loaded overlays because the properties in the overlay's __symbols__ node are not loaded into the live device tree. Patch 1 is unittests to test patches 2 and 3. Patch 2 fixes a problem discovered while

Re: [PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

Radim Krčmář wrote: > 2017-07-19 08:14-0700, Nadav Amit: >> Radim Krčmář wrote: >>> @@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu >>> *vcpu) >>> >>> static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags) >>>

Re: [PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

Radim Krčmář wrote: > 2017-07-19 08:14-0700, Nadav Amit: >> Radim Krčmář wrote: >>> @@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu >>> *vcpu) >>> >>> static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags) >>> { >>> + unsigned long old_rflags =

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, Jul 19, 2017 at 04:10:07PM +, Kani, Toshimitsu wrote: > I do prefer to avoid any white / black listing. But I do not see how > it solves the buggy DMI/SMBIOS info as an example of firmware bugs we > may have to deal with. So how do you want to deal with this? Maintain an evergrowing

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, Jul 19, 2017 at 04:10:07PM +, Kani, Toshimitsu wrote: > I do prefer to avoid any white / black listing. But I do not see how > it solves the buggy DMI/SMBIOS info as an example of firmware bugs we > may have to deal with. So how do you want to deal with this? Maintain an evergrowing

Re: [PATCH v5 1/1] KVM: trigger uevents when creating or destroying a VM

2017-07-17 18:27+0200, Claudio Imbrenda: > On Mon, 17 Jul 2017 17:53:51 +0200 > David Hildenbrand wrote: > > > + tmp = strchrnul(p + 1, '-');> + > > > *tmp = '\0'; > > > + add_uevent_var(env, "PID=%s", p); When we're at it ... PID exists regardless of debugfs,

Re: [PATCH v5 1/1] KVM: trigger uevents when creating or destroying a VM

2017-07-17 18:27+0200, Claudio Imbrenda: > On Mon, 17 Jul 2017 17:53:51 +0200 > David Hildenbrand wrote: > > > + tmp = strchrnul(p + 1, '-');> + > > > *tmp = '\0'; > > > + add_uevent_var(env, "PID=%s", p); When we're at it ... PID exists regardless of debugfs, so it would be nice

[PATCH] staging: lustre: lnet: fix incorrect arguments order calling lstcon_session_new

From: Colin Ian King The arguments args->lstio_ses_force and args->lstio_ses_timeout are in the incorrect order. Fix this by swapping them around. Detected by CoverityScan, CID#1226833 ("Arguments in wrong order") Signed-off-by: Colin Ian King

[PATCH] staging: lustre: lnet: fix incorrect arguments order calling lstcon_session_new

From: Colin Ian King The arguments args->lstio_ses_force and args->lstio_ses_timeout are in the incorrect order. Fix this by swapping them around. Detected by CoverityScan, CID#1226833 ("Arguments in wrong order") Signed-off-by: Colin Ian King ---

[PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

2017-07-19 08:14-0700, Nadav Amit: > Radim Krčmář wrote: > > @@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu > > *vcpu) > > > > static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags) > > { > > + unsigned long old_rflags =

[PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

2017-07-19 08:14-0700, Nadav Amit: > Radim Krčmář wrote: > > @@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu > > *vcpu) > > > > static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags) > > { > > + unsigned long old_rflags = to_vmx(vcpu)->rflags; > >

Re: Kernel BUG at fs/namei.c:248

On 19 July 2017 at 19:24, Al Viro wrote: > On Wed, Jul 19, 2017 at 03:54:54PM +0530, Naresh Kamboju wrote: >> Linux version: >> Linux version 4.13.0-rc1-00059-g74cbd96 (buildslave@x86-64-07) (gcc >> version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Tue >>

Re: Kernel BUG at fs/namei.c:248

On 19 July 2017 at 19:24, Al Viro wrote: > On Wed, Jul 19, 2017 at 03:54:54PM +0530, Naresh Kamboju wrote: >> Linux version: >> Linux version 4.13.0-rc1-00059-g74cbd96 (buildslave@x86-64-07) (gcc >> version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Tue >> Jul 18 19:09:37 UTC 2017 >>

Re: [PATCH v3 1/3] of: overlay: add overlay unittest data for node names and symbols

On 07/19/17 06:39, Rob Herring wrote: > On Tue, Jul 18, 2017 at 10:52 PM, wrote: >> From: Frank Rowand >> >> Add nodes and properties to overlay_base and overlay dts files to >> test for >>- incorrect existing node name detection when overlay

Re: [PATCH v3 1/3] of: overlay: add overlay unittest data for node names and symbols

On 07/19/17 06:39, Rob Herring wrote: > On Tue, Jul 18, 2017 at 10:52 PM, wrote: >> From: Frank Rowand >> >> Add nodes and properties to overlay_base and overlay dts files to >> test for >>- incorrect existing node name detection when overlay node name >> has a unit-address >>-

Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM

2017-07-19 16:18+0200, Arnd Bergmann: > On Wed, Jul 19, 2017 at 4:11 PM, Radim Krčmář wrote: > > 2017-07-19 14:53+0200, Arnd Bergmann: > >> KVM tries to select 'TASKSTATS', which had additional dependencies: > >> > >> warning: (KVM) selects TASKSTATS which has unmet direct

Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM

2017-07-19 16:18+0200, Arnd Bergmann: > On Wed, Jul 19, 2017 at 4:11 PM, Radim Krčmář wrote: > > 2017-07-19 14:53+0200, Arnd Bergmann: > >> KVM tries to select 'TASKSTATS', which had additional dependencies: > >> > >> warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET > >>

Re: [PATCH 002/102] ARM: socfpga: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:06PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 002/102] ARM: socfpga: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:06PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Applied "ASoC: tegra: explicitly request exclusive reset control" to the asoc tree

The patch ASoC: tegra: explicitly request exclusive reset control has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: tegra: explicitly request exclusive reset control" to the asoc tree

The patch ASoC: tegra: explicitly request exclusive reset control has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, 2017-07-19 at 07:52 +0200, Borislav Petkov wrote: > On Tue, Jul 18, 2017 at 09:20:44PM +, Kani, Toshimitsu wrote: > > I agree that 'osc_sb_apei_support_acked' should be checked when > > enabling ghes_edac.  I do not know the details of existing issues, > > but it sounds unlikely that

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, 2017-07-19 at 07:52 +0200, Borislav Petkov wrote: > On Tue, Jul 18, 2017 at 09:20:44PM +, Kani, Toshimitsu wrote: > > I agree that 'osc_sb_apei_support_acked' should be checked when > > enabling ghes_edac.  I do not know the details of existing issues, > > but it sounds unlikely that

Applied "spi: tegra20-sflash: explicitly request exclusive reset control" to the spi tree

The patch spi: tegra20-sflash: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "spi: tegra20-sflash: explicitly request exclusive reset control" to the spi tree

The patch spi: tegra20-sflash: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch

Hi Laurentiu, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc1 next-20170718] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch

Hi Laurentiu, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc1 next-20170718] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Applied "spi: stm32: explicitly request exclusive reset control" to the spi tree

The patch spi: stm32: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "spi: sun6i: explicitly request exclusive reset control" to the spi tree

The patch spi: sun6i: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "spi: stm32: explicitly request exclusive reset control" to the spi tree

The patch spi: stm32: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "spi: sun6i: explicitly request exclusive reset control" to the spi tree

The patch spi: sun6i: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "spi: tegra114: explicitly request exclusive reset control" to the spi tree

The patch spi: tegra114: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "spi: tegra114: explicitly request exclusive reset control" to the spi tree

The patch spi: tegra114: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "spi: tegra20-slink: explicitly request exclusive reset control" to the spi tree

The patch spi: tegra20-slink: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "spi: tegra20-slink: explicitly request exclusive reset control" to the spi tree

The patch spi: tegra20-slink: explicitly request exclusive reset control has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: img: explicitly request exclusive reset control" to the asoc tree

The patch ASoC: img: explicitly request exclusive reset control has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: img: explicitly request exclusive reset control" to the asoc tree

The patch ASoC: img: explicitly request exclusive reset control has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: stm32: explicitly request exclusive reset control" to the asoc tree

The patch ASoC: stm32: explicitly request exclusive reset control has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: stm32: explicitly request exclusive reset control" to the asoc tree

The patch ASoC: stm32: explicitly request exclusive reset control has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: sun4i: explicitly request exclusive reset control" to the asoc tree

The patch ASoC: sun4i: explicitly request exclusive reset control has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: sun4i: explicitly request exclusive reset control" to the asoc tree

The patch ASoC: sun4i: explicitly request exclusive reset control has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Re: [PATCH] lib/strscpy: avoid KASAN false positive

On Wed, Jul 19, 2017 at 11:39:32AM -0400, Chris Metcalf wrote: > > We could just remove all that word-at-a-time logic. Do we have any > > evidence that this would harm anything? > > The word-at-a-time logic was part of the initial commit since I wanted > to ensure that strscpy could be

Re: [PATCH] lib/strscpy: avoid KASAN false positive

On Wed, Jul 19, 2017 at 11:39:32AM -0400, Chris Metcalf wrote: > > We could just remove all that word-at-a-time logic. Do we have any > > evidence that this would harm anything? > > The word-at-a-time logic was part of the initial commit since I wanted > to ensure that strscpy could be

[PATCH 00/11] ARMv8.3 pointer authentication userspace support

This series adds support for the ARMv8.3 pointer authentication extension. Since RFC [1]: * Make the KVM context switch (semi-lazy) * Rebase to v4.13-rc1 * Improve pointer authentication documentation * Add hwcap documentation * Various minor cleanups I've pushed the series to the

[PATCH 00/11] ARMv8.3 pointer authentication userspace support

This series adds support for the ARMv8.3 pointer authentication extension. Since RFC [1]: * Make the KVM context switch (semi-lazy) * Rebase to v4.13-rc1 * Improve pointer authentication documentation * Add hwcap documentation * Various minor cleanups I've pushed the series to the

Re: 4.12 NULL pointer dereference in kmem_cache_free on USB storage removal

On Wed, 2017-07-19 at 08:13 +0300, Yagmur Oymak wrote: > On 07/14/2017 12:07 AM, Bart Van Assche wrote: > > On Thu, 2017-07-13 at 23:24 +0300, Meelis Roos wrote: > > > [258062.320700] RIP: 0010:kmem_cache_free+0x12/0x160 > > > [258062.320886] Call Trace: > > > [258062.320897]

Re: 4.12 NULL pointer dereference in kmem_cache_free on USB storage removal

On Wed, 2017-07-19 at 08:13 +0300, Yagmur Oymak wrote: > On 07/14/2017 12:07 AM, Bart Van Assche wrote: > > On Thu, 2017-07-13 at 23:24 +0300, Meelis Roos wrote: > > > [258062.320700] RIP: 0010:kmem_cache_free+0x12/0x160 > > > [258062.320886] Call Trace: > > > [258062.320897]

[PATCH 02/11] asm-generic: mm_hooks: allow hooks to be overridden individually

Currently, an architecture must either implement all of the mm hooks itself, or use all of those provided by the asm-generic implementation. When an architecture only needs to override a single hook, it must copy the stub implementations from the asm-generic version. To avoid this repetition,

[PATCH 04/11] arm64/cpufeature: add ARMv8.3 id_aa64isar1 bits

>From ARMv8.3 onwards, ID_AA64ISAR1 is no longer entirely RES0, and now has four fields describing the presence of pointer authentication functionality: * APA - address authentication present, using an architected algorithm * API - address authentication present, using an IMP DEF algorithm * GPA

[PATCH 02/11] asm-generic: mm_hooks: allow hooks to be overridden individually

Currently, an architecture must either implement all of the mm hooks itself, or use all of those provided by the asm-generic implementation. When an architecture only needs to override a single hook, it must copy the stub implementations from the asm-generic version. To avoid this repetition,

[PATCH 04/11] arm64/cpufeature: add ARMv8.3 id_aa64isar1 bits

>From ARMv8.3 onwards, ID_AA64ISAR1 is no longer entirely RES0, and now has four fields describing the presence of pointer authentication functionality: * APA - address authentication present, using an architected algorithm * API - address authentication present, using an IMP DEF algorithm * GPA

Re: [PATCH v4 1/5] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

On 18/07/17 11:57 PM, Michael Ellerman wrote: > Seems fair enough, have you tested it at all? It's only been compile tested and the kbuild robot has beat up on it a bit. Thanks, Logan

Re: [PATCH v4 1/5] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

On 18/07/17 11:57 PM, Michael Ellerman wrote: > Seems fair enough, have you tested it at all? It's only been compile tested and the kbuild robot has beat up on it a bit. Thanks, Logan

[PATCH 06/11] arm64: Don't trap host pointer auth use to EL2

To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions and accesses to pointer authentication keys are not trapped to EL2 (where we will not be able to handle them). This patch ensures that HCR_EL2 is configured appropriately

[PATCH 06/11] arm64: Don't trap host pointer auth use to EL2

To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions and accesses to pointer authentication keys are not trapped to EL2 (where we will not be able to handle them). This patch ensures that HCR_EL2 is configured appropriately

[PATCH 10/11] arm64/kvm: context-switch ptrauth registers

When pointer authentication is supported, a guest may wish to use it. This patch adds the necessary KVM infrastructure for this to work, with a semi-lazy context switch of the pointer auth state. When we schedule a vcpu, we disable guest usage of pointer authentication instructions and accesses

[PATCH 09/11] arm64/kvm: preserve host HCR_EL2 value

When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which is a constant value. This works today, as the host HCR_EL2 value is always the same, but this will get in the way of supporting extensions that require HCR_EL2 bits to be set conditionally for the host. To allow such features

<    5   6   7   8   9   10   11   12   13   14   >