[PATCH 1/3] USB: ohci: da8xx: Add devicetree bindings

This patch documents the device tree bindings required for the ohci controller found in TI da8xx family of SoC's Cc: devicet...@vger.kernel.org Signed-off-by: Axel Haslam --- .../devicetree/bindings/usb/ohci-da8xx.txt | 39 ++ 1 file changed, 39

[PATCH v4 0/3] [PART 1/4] USB: ohci-da8xx: Allow a regulator for VBUS and over current

This is the first of 4 series of patches to convert the da8xx-ohci driver to use a regulator and probe form device tree To be able to use device tree to probe the driver, we need to remove the platform callbacks that are handling vbus and over current. These patches prepare the stage by

[PATCH 0/2] ASoC driver for the TSE-850

Hi! The TSE-850 is an FM Transmitter Station Equipment, designed to generate baseband signals for FM, mainly the DARC subcarrier, but other signals are also possible. This adds a driver for the "sound" bits of the device (quoted since it is normally not used for normal sound output, but that

[PATCH 1/3] USB: ohci: da8xx: Add devicetree bindings

This patch documents the device tree bindings required for the ohci controller found in TI da8xx family of SoC's Cc: devicet...@vger.kernel.org Signed-off-by: Axel Haslam --- .../devicetree/bindings/usb/ohci-da8xx.txt | 39 ++ 1 file changed, 39 insertions(+) create

[PATCH v4 0/3] [PART 1/4] USB: ohci-da8xx: Allow a regulator for VBUS and over current

This is the first of 4 series of patches to convert the da8xx-ohci driver to use a regulator and probe form device tree To be able to use device tree to probe the driver, we need to remove the platform callbacks that are handling vbus and over current. These patches prepare the stage by

[PATCH 0/2] ASoC driver for the TSE-850

Hi! The TSE-850 is an FM Transmitter Station Equipment, designed to generate baseband signals for FM, mainly the DARC subcarrier, but other signals are also possible. This adds a driver for the "sound" bits of the device (quoted since it is normally not used for normal sound output, but that

Re: [PATCH v3 3/3] ARM: dmaengine: sun6i: share the dma driver with sun50i

On Tue, Nov 08, 2016 at 02:28:40AM +0800, Hao Zhang wrote: > According to the datasheet, the dma of A64 support 8/16/32/64 bits > so, we can add the condition of device compatible in convert_buswidth > function and other place to determine the device whether is for A64, > and then accept the 8

Re: [PATCH v3 3/3] ARM: dmaengine: sun6i: share the dma driver with sun50i

On Tue, Nov 08, 2016 at 02:28:40AM +0800, Hao Zhang wrote: > According to the datasheet, the dma of A64 support 8/16/32/64 bits > so, we can add the condition of device compatible in convert_buswidth > function and other place to determine the device whether is for A64, > and then accept the 8

Re: [RFC v3 1/6] Track the active utilisation

On 08/11/16 19:17, Luca Abeni wrote: > Hi Juri, > > On Tue, 8 Nov 2016 17:56:35 + > Juri Lelli wrote: > [...] > > > > > static void switched_to_dl(struct rq *rq, struct task_struct > > > > > *p) { > > > > > + add_running_bw(>dl, >dl); > > > > > > > > > > /*

Re: [RFC v3 1/6] Track the active utilisation

On 08/11/16 19:17, Luca Abeni wrote: > Hi Juri, > > On Tue, 8 Nov 2016 17:56:35 + > Juri Lelli wrote: > [...] > > > > > static void switched_to_dl(struct rq *rq, struct task_struct > > > > > *p) { > > > > > + add_running_bw(>dl, >dl); > > > > > > > > > > /* If p is not queued we

Re: [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops

On 11/8/2016 10:09 PM, Alex Williamson wrote: > On Tue, 8 Nov 2016 19:25:35 +0530 > Kirti Wankhede wrote: > ... - + int (*pin_pages)(void *iommu_data, unsigned long *user_pfn, + int npage, int prot, +

Re: [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops

On 11/8/2016 10:09 PM, Alex Williamson wrote: > On Tue, 8 Nov 2016 19:25:35 +0530 > Kirti Wankhede wrote: > ... - + int (*pin_pages)(void *iommu_data, unsigned long *user_pfn, + int npage, int prot, +

Re: [PATCH v3 4/4] posix-timers: make it configurable

On Tue, Nov 8, 2016 at 10:19 AM, Nicolas Pitre wrote: > On Tue, 8 Nov 2016, John Stultz wrote: > >> One spot of concern is that the >> tools/testing/selftests/timers/posix_timers.c test hangs testing >> virtual itimers. Looking through the code I'm not seeing where an >>

Re: [PATCH v3 4/4] posix-timers: make it configurable

On Tue, Nov 8, 2016 at 10:19 AM, Nicolas Pitre wrote: > On Tue, 8 Nov 2016, John Stultz wrote: > >> One spot of concern is that the >> tools/testing/selftests/timers/posix_timers.c test hangs testing >> virtual itimers. Looking through the code I'm not seeing where an >> error case is missed. >>

Re: [PATCH v3 2/3] ARM64: dts: sun6i: add dma node for a64.

Hi, On Tue, Nov 08, 2016 at 02:22:47AM +0800, Hao Zhang wrote: > This adds the dma node for sun50i a64. > > Signed-off-by: Hao Zhang > --- > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 + > 1 file changed, 9 insertions(+) > > diff --git

Re: [PATCH v3 2/3] ARM64: dts: sun6i: add dma node for a64.

Hi, On Tue, Nov 08, 2016 at 02:22:47AM +0800, Hao Zhang wrote: > This adds the dma node for sun50i a64. > > Signed-off-by: Hao Zhang > --- > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 + > 1 file changed, 9 insertions(+) > > diff --git

Re: [PATCH 1/2] clk: sunxi-ng: Fix CPUX clock for the A23/A33

On Mon, Nov 07, 2016 at 05:36:03PM +0800, Icenowy Zheng wrote: > > And your commit log should explain why it is an issue. Yours is even > > wrong here, we could definitely change the rate of these clocks > > already. The only thing that was not allowed was to change the rate of > > its parents,

Re: [PATCH 1/2] clk: sunxi-ng: Fix CPUX clock for the A23/A33

On Mon, Nov 07, 2016 at 05:36:03PM +0800, Icenowy Zheng wrote: > > And your commit log should explain why it is an issue. Yours is even > > wrong here, we could definitely change the rate of these clocks > > already. The only thing that was not allowed was to change the rate of > > its parents,

Re: net/sctp: null-ptr-deref in sctp_inet_listen

Hi Xin, Your patch seems to be fixing the issue. Tested-by: Andrey Konovalov Thanks! On Tue, Nov 8, 2016 at 11:06 AM, Xin Long wrote: > On Tue, Nov 8, 2016 at 5:44 AM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the

Re: linux-next: manual merge of the kspp tree with Linus' tree

On Mon, Nov 7, 2016 at 7:31 PM, Stephen Rothwell wrote: > Hi Kees, > > FIXME: Add owner of second tree to To: >Add author(s)/SOB of conflicting commits. > > Today's linux-next merge of the kspp tree got a conflict in: > > mm/page_alloc.c >

Re: net/sctp: null-ptr-deref in sctp_inet_listen

Hi Xin, Your patch seems to be fixing the issue. Tested-by: Andrey Konovalov Thanks! On Tue, Nov 8, 2016 at 11:06 AM, Xin Long wrote: > On Tue, Nov 8, 2016 at 5:44 AM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the following error report while running the syzkaller fuzzer: >> >>

Re: linux-next: manual merge of the kspp tree with Linus' tree

On Mon, Nov 7, 2016 at 7:31 PM, Stephen Rothwell wrote: > Hi Kees, > > FIXME: Add owner of second tree to To: >Add author(s)/SOB of conflicting commits. > > Today's linux-next merge of the kspp tree got a conflict in: > > mm/page_alloc.c > scripts/gcc-plugins/latent_entropy_plugin.c >

[PATCH v10 3/7] x86/arch_prctl: Add do_arch_prctl_common

Add do_arch_prctl_common to handle arch_prctls that are not specific to 64 bits. Call it from the syscall entry point, but not any of the other callsites in the kernel, which all want one of the existing 64 bit only arch_prctls. Signed-off-by: Kyle Huey ---

[PATCH v10 3/7] x86/arch_prctl: Add do_arch_prctl_common

Add do_arch_prctl_common to handle arch_prctls that are not specific to 64 bits. Call it from the syscall entry point, but not any of the other callsites in the kernel, which all want one of the existing 64 bit only arch_prctls. Signed-off-by: Kyle Huey --- arch/x86/include/asm/proto.h | 1 +

[PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. When enabled, the processor will fault on attempts to execute the CPUID instruction with CPL>0. Exposing this feature to userspace will allow a ptracer to trap and emulate the CPUID instruction. When supported, this

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

On Tue, 8 Nov 2016, Bjørn Mork wrote: > Alan Stern writes: > > > On Tue, 8 Nov 2016, Kai-Heng Feng wrote: > > > >> Hi, > >> > >> On Mon, Nov 7, 2016 at 7:02 PM, Oliver Neukum wrote: > >> > On Fri, 2016-11-04 at 17:57 +0800, Kai-Heng Feng wrote: >

[PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. When enabled, the processor will fault on attempts to execute the CPUID instruction with CPL>0. Exposing this feature to userspace will allow a ptracer to trap and emulate the CPUID instruction. When supported, this

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

On Tue, 8 Nov 2016, Bjørn Mork wrote: > Alan Stern writes: > > > On Tue, 8 Nov 2016, Kai-Heng Feng wrote: > > > >> Hi, > >> > >> On Mon, Nov 7, 2016 at 7:02 PM, Oliver Neukum wrote: > >> > On Fri, 2016-11-04 at 17:57 +0800, Kai-Heng Feng wrote: > >> >> Sometimes cdc_mbim failed to probe if

[PATCH v10 2/7] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64

In order to introduce new arch_prctls that are not 64 bit only, rename the existing 64 bit implementation to do_arch_prctl_64. Also rename the second argument to arch_prctl, which will no longer always be an address. Signed-off-by: Kyle Huey Reviewed-by: Andy Lutomirski

[PATCH v10 7/7] KVM: x86: virtualize cpuid faulting

Hardware support for faulting on the cpuid instruction is not required to emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a cpuid-induced VM exit checks the cpuid faulting state and the CPL.

[PATCH v10 2/7] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64

In order to introduce new arch_prctls that are not 64 bit only, rename the existing 64 bit implementation to do_arch_prctl_64. Also rename the second argument to arch_prctl, which will no longer always be an address. Signed-off-by: Kyle Huey Reviewed-by: Andy Lutomirski ---

[PATCH v10 7/7] KVM: x86: virtualize cpuid faulting

Hardware support for faulting on the cpuid instruction is not required to emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a cpuid-induced VM exit checks the cpuid faulting state and the CPL.

[PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support

Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. When enabled, the processor will fault on attempts to execute the CPUID instruction with CPL>0. This will allow a ptracer to emulate the CPUID instruction. Bit 31 of MSR_PLATFORM_INFO advertises support for this feature.

[PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support

Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. When enabled, the processor will fault on attempts to execute the CPUID instruction with CPL>0. This will allow a ptracer to emulate the CPUID instruction. Bit 31 of MSR_PLATFORM_INFO advertises support for this feature.

Re: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

On Sun, Nov 6, 2016 at 7:40 AM, Jörg Otte wrote: > Since v4.9-rc4 I get following crash in dvb-usb-cinergyT2 module. Looks like it's commit 5ef8ed0e5608f ("[media] cinergyT2-core: don't do DMA on stack"), which movced the DMA data array from the stack to the "private"

Re: linux-next: manual merge of the tty tree with the jc_docs tree

On 11/08/2016, 11:15 AM, Greg KH wrote: > On Tue, Nov 08, 2016 at 04:30:13PM +1100, Stephen Rothwell wrote: >> Hi Greg, >> >> Today's linux-next merge of the tty tree got a conflict in: >> >> Documentation/VGA-softcursor.txt >> >> between commits: >> >> 27641b953c54

[PATCH v10 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32

Hook up arch_prctl to call do_arch_prctl on x86-32, and in 32 bit compat mode on x86-64. This allows us to have arch_prctls that are not specific to 64 bits. On UML, simply stub out this syscall. Signed-off-by: Kyle Huey --- arch/x86/entry/syscalls/syscall_32.tbl | 1 +

Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On Tue, 8 Nov 2016, Peter Rosin wrote: > On 2016-11-08 16:59, Thomas Gleixner wrote: > > So you need that whole dance including the delayed work because you cannot > > call iio_write_channel_raw() from hard interrupt context, right? > > It's not the "cannot call from hard irq context" that made

Re: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

On Sun, Nov 6, 2016 at 7:40 AM, Jörg Otte wrote: > Since v4.9-rc4 I get following crash in dvb-usb-cinergyT2 module. Looks like it's commit 5ef8ed0e5608f ("[media] cinergyT2-core: don't do DMA on stack"), which movced the DMA data array from the stack to the "private" pointer. In the process it

Re: linux-next: manual merge of the tty tree with the jc_docs tree

On 11/08/2016, 11:15 AM, Greg KH wrote: > On Tue, Nov 08, 2016 at 04:30:13PM +1100, Stephen Rothwell wrote: >> Hi Greg, >> >> Today's linux-next merge of the tty tree got a conflict in: >> >> Documentation/VGA-softcursor.txt >> >> between commits: >> >> 27641b953c54

[PATCH v10 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32

Hook up arch_prctl to call do_arch_prctl on x86-32, and in 32 bit compat mode on x86-64. This allows us to have arch_prctls that are not specific to 64 bits. On UML, simply stub out this syscall. Signed-off-by: Kyle Huey --- arch/x86/entry/syscalls/syscall_32.tbl | 1 +

Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On Tue, 8 Nov 2016, Peter Rosin wrote: > On 2016-11-08 16:59, Thomas Gleixner wrote: > > So you need that whole dance including the delayed work because you cannot > > call iio_write_channel_raw() from hard interrupt context, right? > > It's not the "cannot call from hard irq context" that made

[PATCH v10 0/7] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

rr (http://rr-project.org/), a userspace record-and-replay reverse- execution debugger, would like to trap and emulate the CPUID instruction. This would allow us to a) mask away certain hardware features that rr does not support (e.g. RDRAND) and b) enable trace portability across machines by

[PATCH v10 1/7] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl

Signed-off-by: Kyle Huey --- arch/x86/kernel/process_64.c | 3 ++- arch/x86/um/syscalls_64.c| 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index b3760b3..2718cf9 100644 ---

[PATCH v10 0/7] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

rr (http://rr-project.org/), a userspace record-and-replay reverse- execution debugger, would like to trap and emulate the CPUID instruction. This would allow us to a) mask away certain hardware features that rr does not support (e.g. RDRAND) and b) enable trace portability across machines by

[PATCH v10 1/7] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl

Signed-off-by: Kyle Huey --- arch/x86/kernel/process_64.c | 3 ++- arch/x86/um/syscalls_64.c| 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index b3760b3..2718cf9 100644 --- a/arch/x86/kernel/process_64.c +++

Re: [PATCH] mm: only enable sys_pkey* when ARCH_HAS_PKEYS

On 11/08/2016 03:24 AM, Heiko Carstens wrote: > Something like this: > > diff --git a/mm/mprotect.c b/mm/mprotect.c > index 11936526b08b..9fb86b107e49 100644 > --- a/mm/mprotect.c > +++ b/mm/mprotect.c > @@ -484,6 +484,8 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, > len, >

Re: [PATCH] mm: only enable sys_pkey* when ARCH_HAS_PKEYS

On 11/08/2016 03:24 AM, Heiko Carstens wrote: > Something like this: > > diff --git a/mm/mprotect.c b/mm/mprotect.c > index 11936526b08b..9fb86b107e49 100644 > --- a/mm/mprotect.c > +++ b/mm/mprotect.c > @@ -484,6 +484,8 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, > len, >

Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

On Nov 8 09:16, Hisashi T Fujinaka wrote: > On Tue, 8 Nov 2016, Corinna Vinschen wrote: > > On Nov 8 15:06, Cao jin wrote: > > > When running as guest, under certain condition, it will oops as following. > > > writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr > > > is

Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

On Nov 8 09:16, Hisashi T Fujinaka wrote: > On Tue, 8 Nov 2016, Corinna Vinschen wrote: > > On Nov 8 15:06, Cao jin wrote: > > > When running as guest, under certain condition, it will oops as following. > > > writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr > > > is

Re: [PATCH] spi: rspi: avoid uninitialized variable access

On Tue, Nov 8, 2016 at 6:20 PM, Chris Brandt wrote: > However > > On 11/8/2016, Arnd Bergmann wrote: >> This simplifies it again by keeping the two separate, which then ends up >> avoiding that warning. > > I agree with Arnd's method of NOT adding a new

Re: [PATCH] spi: rspi: avoid uninitialized variable access

On Tue, Nov 8, 2016 at 6:20 PM, Chris Brandt wrote: > However > > On 11/8/2016, Arnd Bergmann wrote: >> This simplifies it again by keeping the two separate, which then ends up >> avoiding that warning. > > I agree with Arnd's method of NOT adding a new "rspi_pio_transfer_in_or_our" >

Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

On Tue, 8 Nov 2016, Hisashi T Fujinaka wrote: Incidentally we're just looking for a solution to that problem too. Do three patches to fix the same problem at rougly the same time already qualify as freak accident? FTR, I attached my current patch, which I was planning to submit after some

Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

On Tue, 8 Nov 2016, Hisashi T Fujinaka wrote: Incidentally we're just looking for a solution to that problem too. Do three patches to fix the same problem at rougly the same time already qualify as freak accident? FTR, I attached my current patch, which I was planning to submit after some

Re: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info

On 11/07/2016 09:50 PM, Li, Liang Z wrote: > Sounds good. Should we ignore some of the order-0 pages in step 4 if the > bitmap is full? > Or should retry to get a complete list of order-0 pages? I think that's a pretty reasonable thing to do. >>> It seems the benefit we get for this feature is

Re: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info

On 11/07/2016 09:50 PM, Li, Liang Z wrote: > Sounds good. Should we ignore some of the order-0 pages in step 4 if the > bitmap is full? > Or should retry to get a complete list of order-0 pages? I think that's a pretty reasonable thing to do. >>> It seems the benefit we get for this feature is

Re: linux-next: Tree for Nov 8 (netdev, netfilter)

On 11/07/16 23:38, Stephen Rothwell wrote: > Hi all, > > Changes since 20161028: on i386 or x86_64: net/built-in.o: In function `nf_sk_lookup_slow_v4': (.text+0x97414): undefined reference to `udp4_lib_lookup' when these are not enabled: #if IS_ENABLED(CONFIG_NETFILTER_XT_MATCH_SOCKET) || \

Re: linux-next: Tree for Nov 8 (netdev, netfilter)

On 11/07/16 23:38, Stephen Rothwell wrote: > Hi all, > > Changes since 20161028: on i386 or x86_64: net/built-in.o: In function `nf_sk_lookup_slow_v4': (.text+0x97414): undefined reference to `udp4_lib_lookup' when these are not enabled: #if IS_ENABLED(CONFIG_NETFILTER_XT_MATCH_SOCKET) || \

RE: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

> This still preserves the precise TSC timestamp in intel_threshold_interrupt(). Yup - this looks right. Acked-by: Tony Luck -Tony

[GIT PULL 2/3] ARM64: dts: exynos: DT for v4.10

Hi, Exynos5433 + two boards using it. Mobile boards! :) I am really happy to push it. I know that it has been a lot of effort in Samsung to mainline this. Best regards, Krzysztof The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50

Re: [PATCH] perf/x86: Fix overlap counter scheduling bug

On Tue, Nov 08, 2016 at 05:25:34PM +, Liang, Kan wrote: > > I think all the 0x3 mask need the overlap flag set, since they clearly > > overlap > > with the 0x1 masks. That would improve the scheduling. > > > > How much the overlap hint can improve the scheduling? > Because there is not only

RE: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

> This still preserves the precise TSC timestamp in intel_threshold_interrupt(). Yup - this looks right. Acked-by: Tony Luck -Tony

[GIT PULL 2/3] ARM64: dts: exynos: DT for v4.10

Hi, Exynos5433 + two boards using it. Mobile boards! :) I am really happy to push it. I know that it has been a lot of effort in Samsung to mainline this. Best regards, Krzysztof The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50

Re: [PATCH] perf/x86: Fix overlap counter scheduling bug

On Tue, Nov 08, 2016 at 05:25:34PM +, Liang, Kan wrote: > > I think all the 0x3 mask need the overlap flag set, since they clearly > > overlap > > with the 0x1 masks. That would improve the scheduling. > > > > How much the overlap hint can improve the scheduling? > Because there is not only

Re: [PATCH v3 1/2] arm64: Add hypervisor safe helper for checking constant capabilities

On Tue, Nov 08, 2016 at 01:56:20PM +, Suzuki K Poulose wrote: > The hypervisor may not have full access to the kernel data structures > and hence cannot safely use cpus_have_cap() helper for checking the > system capability. Add a safe helper for hypervisors to check a constant > system

Re: [PATCH v3 1/2] arm64: Add hypervisor safe helper for checking constant capabilities

On Tue, Nov 08, 2016 at 01:56:20PM +, Suzuki K Poulose wrote: > The hypervisor may not have full access to the kernel data structures > and hence cannot safely use cpus_have_cap() helper for checking the > system capability. Add a safe helper for hypervisors to check a constant > system

[GIT PULL 1/3] ARM: dts: exynos: DT for v4.10

Hi, Hurray! New board! ... Exynos4415 slowly is going away. Best regards, Krzysztof The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in the git repository at:

[GIT PULL 1/3] ARM: dts: exynos: DT for v4.10

Hi, Hurray! New board! ... Exynos4415 slowly is going away. Best regards, Krzysztof The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in the git repository at:

[GIT PULL 0/3] ARM: exynos: Stuff for v4.10

Hi, Two weeks ago it looked it will be very boring merge window for Samsung, but luckily it is not! So far we got Exynos5433 and two boards on it. ARMv7 got one board using Exynos4412. I am pushing this patches early but expect another pull requests in few weeks. No order of pulling, no

[GIT PULL 3/3] ARM: defconfig: Samsung defconfigs for v4.10

Hi, Nothing special. Best regards, Krzysztof The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git

[GIT PULL 0/3] ARM: exynos: Stuff for v4.10

Hi, Two weeks ago it looked it will be very boring merge window for Samsung, but luckily it is not! So far we got Exynos5433 and two boards on it. ARMv7 got one board using Exynos4412. I am pushing this patches early but expect another pull requests in few weeks. No order of pulling, no

[GIT PULL 3/3] ARM: defconfig: Samsung defconfigs for v4.10

Hi, Nothing special. Best regards, Krzysztof The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git

Re: [PATCH v3 4/4] posix-timers: make it configurable

On Tue, 8 Nov 2016, John Stultz wrote: > One spot of concern is that the > tools/testing/selftests/timers/posix_timers.c test hangs testing > virtual itimers. Looking through the code I'm not seeing where an > error case is missed. > > The strace looks like: > ... > write(1, "Testing posix

Re: [PATCH v3 4/4] posix-timers: make it configurable

On Tue, 8 Nov 2016, John Stultz wrote: > One spot of concern is that the > tools/testing/selftests/timers/posix_timers.c test hangs testing > virtual itimers. Looking through the code I'm not seeing where an > error case is missed. > > The strace looks like: > ... > write(1, "Testing posix

Re: [RFC v3 1/6] Track the active utilisation

Hi Juri, On Tue, 8 Nov 2016 17:56:35 + Juri Lelli wrote: [...] > > > > static void switched_to_dl(struct rq *rq, struct task_struct > > > > *p) { > > > > + add_running_bw(>dl, >dl); > > > > > > > > /* If p is not queued we will update its parameters at >

Re: [RFC v3 1/6] Track the active utilisation

Hi Juri, On Tue, 8 Nov 2016 17:56:35 + Juri Lelli wrote: [...] > > > > static void switched_to_dl(struct rq *rq, struct task_struct > > > > *p) { > > > > + add_running_bw(>dl, >dl); > > > > > > > > /* If p is not queued we will update its parameters at > > > > next wakeup.

Re: [PATCH] gpio: davinci: Use unique labels for each gpio chip

Axel Haslam writes: > The gpiod framework uses the chip label to match a specific chip. > The davinci gpio driver, creates several chips using always the same > label, which is not compatible with gpiod. > > To allow platform data to declare gpio lookup tables, and for

Re: [PATCH] gpio: davinci: Use unique labels for each gpio chip

Axel Haslam writes: > The gpiod framework uses the chip label to match a specific chip. > The davinci gpio driver, creates several chips using always the same > label, which is not compatible with gpiod. > > To allow platform data to declare gpio lookup tables, and for drivers > to use the gpiod

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Mon, Nov 07, 2016 at 06:37:50PM +, Luck, Tony wrote: > Also to me ... and I think that's what used to happen (or at least was the > intent). How's that? This still preserves the precise TSC timestamp in intel_threshold_interrupt(). --- From: Borislav Petkov Date: Tue, 8

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Mon, Nov 07, 2016 at 06:37:50PM +, Luck, Tony wrote: > Also to me ... and I think that's what used to happen (or at least was the > intent). How's that? This still preserves the precise TSC timestamp in intel_threshold_interrupt(). --- From: Borislav Petkov Date: Tue, 8 Nov 2016

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, Nov 08, 2016 at 12:17:10PM -0500, Steven Rostedt wrote: > On Tue, 8 Nov 2016 17:51:33 +0100 > Peter Zijlstra wrote: > > > You really should already know this. > > I know what we want to do, but there's some momentous problems that > need to be solved first. Like

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, Nov 08, 2016 at 12:17:10PM -0500, Steven Rostedt wrote: > On Tue, 8 Nov 2016 17:51:33 +0100 > Peter Zijlstra wrote: > > > You really should already know this. > > I know what we want to do, but there's some momentous problems that > need to be solved first. Like what? > Until then, we

RE: [PATCH V3 13/14] Drivers: hv: vmbus: On write cleanup the logic to interrupt the host

Please don't add name/date information into comments. This kind of meta data belongs in the commit message only. My philosophy is that comments should be reserved for explain the semantics of the code, not the history. + * + * KYS: Oct. 30, 2016: + * It looks like Windows hosts have logic to

RE: [PATCH V3 13/14] Drivers: hv: vmbus: On write cleanup the logic to interrupt the host

Please don't add name/date information into comments. This kind of meta data belongs in the commit message only. My philosophy is that comments should be reserved for explain the semantics of the code, not the history. + * + * KYS: Oct. 30, 2016: + * It looks like Windows hosts have logic to

Re: [PATCH 2/2] clk: pxa: fix pxa2xx_determine_rate return

Arnd Bergmann writes: > The new pxa2xx_determine_rate() function seems lacking in a few > regards: > > - For an exact match or no match at all, the rate is uninitialized > as reported by gcc -Wmaybe-unintialized: >drivers/clk/pxa/clk-pxa.c: In function

Re: [PATCH 2/2] clk: pxa: fix pxa2xx_determine_rate return

Arnd Bergmann writes: > The new pxa2xx_determine_rate() function seems lacking in a few > regards: > > - For an exact match or no match at all, the rate is uninitialized > as reported by gcc -Wmaybe-unintialized: >drivers/clk/pxa/clk-pxa.c: In function 'pxa2xx_determine_rate': >

Re: [PATCH v9 7/7] KVM: x86: virtualize cpuid faulting

On Tue, Nov 8, 2016 at 9:53 AM, Thomas Gleixner wrote: > On Tue, 8 Nov 2016, Kyle Huey wrote: >> > It will simplify the MSR get/set code, and make it easier to plumb >> > support for new bits in these MSRs. >> >> I'm inclined to do this for MSR_PLATFORM_INFO but not >>

Re: [PATCH v9 7/7] KVM: x86: virtualize cpuid faulting

On Tue, Nov 8, 2016 at 9:53 AM, Thomas Gleixner wrote: > On Tue, 8 Nov 2016, Kyle Huey wrote: >> > It will simplify the MSR get/set code, and make it easier to plumb >> > support for new bits in these MSRs. >> >> I'm inclined to do this for MSR_PLATFORM_INFO but not >> MSR_MISC_FEATURES_ENABLES.

[PATCH v9 7/7] KVM: x86: virtualize cpuid faulting

Hardware support for faulting on the cpuid instruction is not required to emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a cpuid-induced VM exit checks the cpuid faulting state and the CPL.

[PATCH v9 7/7] KVM: x86: virtualize cpuid faulting

Hardware support for faulting on the cpuid instruction is not required to emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a cpuid-induced VM exit checks the cpuid faulting state and the CPL.

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

On Tue, Nov 08, 2016 at 09:49:27AM -0700, Stephen Warren wrote: > On 11/08/2016 08:55 AM, Thierry Reding wrote: > > On Mon, Nov 07, 2016 at 05:42:33PM -0800, Olof Johansson wrote: > > > On Mon, Nov 7, 2016 at 5:21 AM, Thierry Reding > > > wrote: > > > > On Mon, Nov 07,

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

On Tue, Nov 08, 2016 at 09:49:27AM -0700, Stephen Warren wrote: > On 11/08/2016 08:55 AM, Thierry Reding wrote: > > On Mon, Nov 07, 2016 at 05:42:33PM -0800, Olof Johansson wrote: > > > On Mon, Nov 7, 2016 at 5:21 AM, Thierry Reding > > > wrote: > > > > On Mon, Nov 07, 2016 at 08:53:37AM +0100,

[PATCH v9 7/7] KVM: x86: virtualize cpuid faulting

e.g. like this

[PATCH v9 7/7] KVM: x86: virtualize cpuid faulting

e.g. like this

Re: [PATCH v9 7/7] KVM: x86: virtualize cpuid faulting

On Tue, 8 Nov 2016, Kyle Huey wrote: > > It will simplify the MSR get/set code, and make it easier to plumb > > support for new bits in these MSRs. > > I'm inclined to do this for MSR_PLATFORM_INFO but not > MSR_MISC_FEATURES_ENABLES. The former actually has other bits, and > isn't used outside

Re: [PATCH v9 7/7] KVM: x86: virtualize cpuid faulting

On Tue, 8 Nov 2016, Kyle Huey wrote: > > It will simplify the MSR get/set code, and make it easier to plumb > > support for new bits in these MSRs. > > I'm inclined to do this for MSR_PLATFORM_INFO but not > MSR_MISC_FEATURES_ENABLES. The former actually has other bits, and > isn't used outside

Re: [PATCH v2] spi: atmel: use managed resource for gpio chip select

On 08/11/2016 at 18:48:52 +0100, Nicolas Ferre wrote : > Use the managed gpio CS pin request so that we avoid having trouble > in the cleanup code. > In fact, if module was configured with DT, cleanup code released > invalid pin. Since resource wasn't freed, module cannot be reinserted. > > This

Re: [RFC v3 1/6] Track the active utilisation

On 01/11/16 22:10, Luca Abeni wrote: > Hi Juri, > > On Tue, 1 Nov 2016 16:45:43 + > Juri Lelli wrote: > > > Hi, > > > > a few nitpicks on subject and changelog and a couple of questions below. > > > > Subject should be changed to something like > > > >

Re: net/sunrpc/clnt.c:2773 suspicious rcu_dereference_check() usage!

On 11/08/2016 12:43 PM, Ross Zwisler wrote: > On Tue, Nov 08, 2016 at 07:42:59AM -0500, Anna Schumaker wrote: >> On 11/08/2016 07:09 AM, Jeff Layton wrote: >>> On Tue, 2016-11-08 at 06:53 -0500, Jeff Layton wrote: On Mon, 2016-11-07 at 22:42 -0700, Ross Zwisler wrote: > > I've got a

Re: [PATCH v2] spi: atmel: use managed resource for gpio chip select

On 08/11/2016 at 18:48:52 +0100, Nicolas Ferre wrote : > Use the managed gpio CS pin request so that we avoid having trouble > in the cleanup code. > In fact, if module was configured with DT, cleanup code released > invalid pin. Since resource wasn't freed, module cannot be reinserted. > > This

<    3   4   5   6   7   8   9   10   11   12   >