Re: [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible

On Tuesday, November 22, 2016 5:48:41 PM CET Gregory CLEMENT wrote: > +#ifdef CONFIG_64BIT > + void *data_tmp; > + > + /* In Neta HW only 32 bits data is supported, so in order to > +* obtain whole 64 bits address from RX descriptor, we store > +* the upper 32 bits when

Re: [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible

On Tuesday, November 22, 2016 5:48:41 PM CET Gregory CLEMENT wrote: > +#ifdef CONFIG_64BIT > + void *data_tmp; > + > + /* In Neta HW only 32 bits data is supported, so in order to > +* obtain whole 64 bits address from RX descriptor, we store > +* the upper 32 bits when

[PATCH] [media] DaVinci-VPFE-Capture: fix error handling

A recent cleanup had the right idea to remove the initialization of the error variable, but missed the actual benefit of that, which is that we get warnings if there is a bug in it. Now we get a warning about a bug that was introduced by this cleanup:

[PATCH] [media] DaVinci-VPFE-Capture: fix error handling

A recent cleanup had the right idea to remove the initialization of the error variable, but missed the actual benefit of that, which is that we get warnings if there is a bug in it. Now we get a warning about a bug that was introduced by this cleanup:

Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available

On Tue, Nov 22, 2016 at 10:39:29AM +, David Howells wrote: > Dave Chinner wrote: > > > No. Just provide a 64 bit high resoultion field, and define it to > > contain nanoseconds. When we need higher resolution to be exported > > to userspace, we use a /feature flag/ to

Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available

On Tue, Nov 22, 2016 at 10:39:29AM +, David Howells wrote: > Dave Chinner wrote: > > > No. Just provide a 64 bit high resoultion field, and define it to > > contain nanoseconds. When we need higher resolution to be exported > > to userspace, we use a /feature flag/ to indicate that is

Re: [PATCH] KVM: x86: restore IP after all far jump failures

2016-11-22 12:03-0800, Jim Mattson: > Should the subject read: "KVM: x86: restore CS after all far jump failures"? Yes, thanks. Maybe "preserve CS" would be even better. I'll fix it when applying if there are no other problems.

Re: [PATCH] KVM: x86: restore IP after all far jump failures

2016-11-22 12:03-0800, Jim Mattson: > Should the subject read: "KVM: x86: restore CS after all far jump failures"? Yes, thanks. Maybe "preserve CS" would be even better. I'll fix it when applying if there are no other problems.

Re: [PATCH v6 3/5] USB: ohci: da8xx: Allow a regulator to handle VBUS

On 11/22/2016 02:46 PM, Axel Haslam wrote: On Tue, Nov 22, 2016 at 9:37 PM, David Lechner wrote: On 11/21/2016 10:30 AM, Axel Haslam wrote: Using a regulator to handle VBUS will eliminate the need for platform data and callbacks, and make the driver more generic

Re: [PATCH v6 3/5] USB: ohci: da8xx: Allow a regulator to handle VBUS

On 11/22/2016 02:46 PM, Axel Haslam wrote: On Tue, Nov 22, 2016 at 9:37 PM, David Lechner wrote: On 11/21/2016 10:30 AM, Axel Haslam wrote: Using a regulator to handle VBUS will eliminate the need for platform data and callbacks, and make the driver more generic allowing different types of

Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes

On 11/21/2016 02:17 PM, Peter Rosin wrote: [...] > I have a piece of hardware that is using the same 3 GPIO pins > to control four 8-way muxes. Three of them control ADC lines > to an ADS1015 chip with an iio driver, and the last one > controls the SDA line of an i2c bus. We have some deployed >

Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes

On 11/21/2016 02:17 PM, Peter Rosin wrote: [...] > I have a piece of hardware that is using the same 3 GPIO pins > to control four 8-way muxes. Three of them control ADC lines > to an ADS1015 chip with an iio driver, and the last one > controls the SDA line of an i2c bus. We have some deployed >

[PATCH v16 1/3] drm/rockchip: cdn-dp: add cdn DP support for rk3399

From: Chris Zhong Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work,

[PATCH v16 1/3] drm/rockchip: cdn-dp: add cdn DP support for rk3399

From: Chris Zhong Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware

Re: [PATCH 5/5] thermal: rockchip: handle the set_trips without the trip points.

On Tue, Nov 22, 2016 at 08:34:48PM +0800, Caesar Wang wrote: > In some cases, some sensors didn't need the trip points, the > set_trips will return {-INT_MAX, INT_MAX} to trigger thermal alarm. > > Signed-off-by: Caesar Wang > --- > > drivers/thermal/rockchip_thermal.c |

Re: [PATCH 5/5] thermal: rockchip: handle the set_trips without the trip points.

On Tue, Nov 22, 2016 at 08:34:48PM +0800, Caesar Wang wrote: > In some cases, some sensors didn't need the trip points, the > set_trips will return {-INT_MAX, INT_MAX} to trigger thermal alarm. > > Signed-off-by: Caesar Wang > --- > > drivers/thermal/rockchip_thermal.c | 13 + > 1

[PATCH] NFSv4.x: hide array-bounds warning

A correct bugfix introduced a harmless warning that shows up with gcc-7: fs/nfs/callback.c: In function 'nfs_callback_up': fs/nfs/callback.c:214:14: error: array subscript is outside array bounds [-Werror=array-bounds] What happens here is that the 'minorversion == 0' check tells the compiler

[PATCH] NFSv4.x: hide array-bounds warning

A correct bugfix introduced a harmless warning that shows up with gcc-7: fs/nfs/callback.c: In function 'nfs_callback_up': fs/nfs/callback.c:214:14: error: array subscript is outside array bounds [-Werror=array-bounds] What happens here is that the 'minorversion == 0' check tells the compiler

Re: [PATCH 3/5] thermal: rockchip: fixes invalid temperature case

On Tue, Nov 22, 2016 at 08:34:46PM +0800, Caesar Wang wrote: > The temp_to_code function will return 0 when we set the trip points value > or valid temperature. I'm not quite sure what you mean by "when we set the trip points value or valid temperature." Do you mean "when we set the trip point's

Re: [PATCH 3/5] thermal: rockchip: fixes invalid temperature case

On Tue, Nov 22, 2016 at 08:34:46PM +0800, Caesar Wang wrote: > The temp_to_code function will return 0 when we set the trip points value > or valid temperature. I'm not quite sure what you mean by "when we set the trip points value or valid temperature." Do you mean "when we set the trip point's

Re: [PATCH] KVM: x86: restore IP after all far jump failures

2016-11-22 11:43-0800, Nadav Amit: > I admit my wrongdoings, but I still think the fix should have been to > remove the entire recovery logic and just return X86EMUL_UNHANDLEABLE if > something goes wrong (exception). This will kill the misbehaving process > but keep the VM running.

Re: [PATCH] KVM: x86: restore IP after all far jump failures

2016-11-22 11:43-0800, Nadav Amit: > I admit my wrongdoings, but I still think the fix should have been to > remove the entire recovery logic and just return X86EMUL_UNHANDLEABLE if > something goes wrong (exception). This will kill the misbehaving process > but keep the VM running.

[PATCH 3/3] drm/rockchip: cdn-dp: Do not run worker while suspended

From: Guenter Roeck If the driver is in suspended mode, the dp block may be disabled, and chip registers may not be accessible. Yet, the worker may be triggered in this situation by an extcon event. If that happens, the following crash will be seen. cdn-dp fec0.dp:

[PATCH 2/3] drm/rockchip: cdn-dp: Load firmware if no monitor connected

From: Guenter Roeck If no monitor is connected, suspend/resume cycles result in firmware load errors because the driver attempts to load the firmware while the system is in suspend state. This results in a kernel warning and traceback. Loading the firmware during boot fixes

[PATCH 3/3] drm/rockchip: cdn-dp: Do not run worker while suspended

From: Guenter Roeck If the driver is in suspended mode, the dp block may be disabled, and chip registers may not be accessible. Yet, the worker may be triggered in this situation by an extcon event. If that happens, the following crash will be seen. cdn-dp fec0.dp:

[PATCH 2/3] drm/rockchip: cdn-dp: Load firmware if no monitor connected

From: Guenter Roeck If no monitor is connected, suspend/resume cycles result in firmware load errors because the driver attempts to load the firmware while the system is in suspend state. This results in a kernel warning and traceback. Loading the firmware during boot fixes the problem. Note

[PATCH 0/3] drm/rockchip: Add CDN DP driver

This series adds support for the CDN DP controller to the rockchip drm driver. This version of includes the version we merged into the chromium.org repo plus ~15 fixes squashed on top. Notable fixes include: - Fixed races between hotplug/extcon worker and modeset - Greater support

[PATCH 0/3] drm/rockchip: Add CDN DP driver

This series adds support for the CDN DP controller to the rockchip drm driver. This version of includes the version we merged into the chromium.org repo plus ~15 fixes squashed on top. Notable fixes include: - Fixed races between hotplug/extcon worker and modeset - Greater support

Re: [PATCH v6 3/5] USB: ohci: da8xx: Allow a regulator to handle VBUS

On Tue, Nov 22, 2016 at 9:37 PM, David Lechner wrote: > On 11/21/2016 10:30 AM, Axel Haslam wrote: >> >> Using a regulator to handle VBUS will eliminate the need for >> platform data and callbacks, and make the driver more generic >> allowing different types of regulators to

Re: [PATCH v6 3/5] USB: ohci: da8xx: Allow a regulator to handle VBUS

On Tue, Nov 22, 2016 at 9:37 PM, David Lechner wrote: > On 11/21/2016 10:30 AM, Axel Haslam wrote: >> >> Using a regulator to handle VBUS will eliminate the need for >> platform data and callbacks, and make the driver more generic >> allowing different types of regulators to handle VBUS. >> >>

Re: [Qemu-devel] [PATCH] drm: update MAINTAINERS for qemu drivers (bochs, cirrus, qxl, virtio-gpu)

On 11/22/2016 01:41 PM, Paolo Bonzini wrote: > > > On 22/11/2016 19:54, Eric Blake wrote: >> DRM DRIVER FOR BOCHS VIRTUAL GPU >> M: Gerd Hoffmann >> -S: Odd Fixes >> +L: qemu-de...@nongnu.org qemu-devel list already has very high

Re: [Qemu-devel] [PATCH] drm: update MAINTAINERS for qemu drivers (bochs, cirrus, qxl, virtio-gpu)

On 11/22/2016 01:41 PM, Paolo Bonzini wrote: > > > On 22/11/2016 19:54, Eric Blake wrote: >> DRM DRIVER FOR BOCHS VIRTUAL GPU >> M: Gerd Hoffmann >> -S: Odd Fixes >> +L: qemu-de...@nongnu.org qemu-devel list already has very high traffic - not sure

Re: [PATCH v6 1/5] USB: ohci: da8xx: use ohci priv data instead of globals

On 11/21/2016 10:30 AM, Axel Haslam wrote: Instead of global variables, use the extra_priv_size of the ohci driver. We cannot yet move the ocic mask because this is used on the interrupt handler which is registerded through platform s/registerded/registered/ data and does not have an hcd

Re: [PATCH v6 1/5] USB: ohci: da8xx: use ohci priv data instead of globals

On 11/21/2016 10:30 AM, Axel Haslam wrote: Instead of global variables, use the extra_priv_size of the ohci driver. We cannot yet move the ocic mask because this is used on the interrupt handler which is registerded through platform s/registerded/registered/ data and does not have an hcd

[PATCH] clk: bcm2835: Fix ->fixed_divider of pllh_aux

From: Boris Brezillon There is no fixed divider on pllh_aux. Signed-off-by: Boris Brezillon Signed-off-by: Eric Anholt Reviewed-by: Eric Anholt --- This was copy and paste failure on my

[PATCH] clk: bcm2835: Fix ->fixed_divider of pllh_aux

From: Boris Brezillon There is no fixed divider on pllh_aux. Signed-off-by: Boris Brezillon Signed-off-by: Eric Anholt Reviewed-by: Eric Anholt --- This was copy and paste failure on my (anholt's) part. The divider of 10 is on PLLH_PIX. No need to worry about backporting, as this channel

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

On Tue, Nov 22, 2016 at 04:41:37PM +0100, Borislav Petkov wrote: > On Tue, Nov 22, 2016 at 05:22:38PM +0200, Michael S. Tsirkin wrote: > > The issue is it's a (potential) security hole, not a slowdown. > > How? Because the bounce buffers will be unencrypted and someone might > intercept them? Or

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

On Tue, Nov 22, 2016 at 04:41:37PM +0100, Borislav Petkov wrote: > On Tue, Nov 22, 2016 at 05:22:38PM +0200, Michael S. Tsirkin wrote: > > The issue is it's a (potential) security hole, not a slowdown. > > How? Because the bounce buffers will be unencrypted and someone might > intercept them? Or

Re: [PATCH v6 3/5] USB: ohci: da8xx: Allow a regulator to handle VBUS

On 11/21/2016 10:30 AM, Axel Haslam wrote: Using a regulator to handle VBUS will eliminate the need for platform data and callbacks, and make the driver more generic allowing different types of regulators to handle VBUS. The regulator equivalents to the platform callbacks are: set_power

Re: [PATCH v6 3/5] USB: ohci: da8xx: Allow a regulator to handle VBUS

On 11/21/2016 10:30 AM, Axel Haslam wrote: Using a regulator to handle VBUS will eliminate the need for platform data and callbacks, and make the driver more generic allowing different types of regulators to handle VBUS. The regulator equivalents to the platform callbacks are: set_power

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-22 03:10 PM, Daniel Vetter wrote: On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams wrote: On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch wrote: I personally like "device-DAX" idea but my concerns are: - How well it

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-22 03:10 PM, Daniel Vetter wrote: On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams wrote: On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch wrote: I personally like "device-DAX" idea but my concerns are: - How well it will co-exists with the DRM infrastructure /

Re: [PATCH 4/6] efi: Get the secure boot status

On Tue, Nov 22, 2016 at 02:52:01PM +, David Howells wrote: > Lukas Wunner wrote: > > You dropped the efi_system_table_t *sys_table_arg argument but this > > isn't defined anywhere as a static global. > > It seems to me that passing this value in on x86 is probably a bad idea

Re: [PATCH 4/6] efi: Get the secure boot status

On Tue, Nov 22, 2016 at 02:52:01PM +, David Howells wrote: > Lukas Wunner wrote: > > You dropped the efi_system_table_t *sys_table_arg argument but this > > isn't defined anywhere as a static global. > > It seems to me that passing this value in on x86 is probably a bad idea as > it's not

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams wrote: > On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch > wrote: >> I personally like "device-DAX" idea but my concerns are: >> >> - How well it will co-exists with the DRM

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams wrote: > On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch > wrote: >> I personally like "device-DAX" idea but my concerns are: >> >> - How well it will co-exists with the DRM infrastructure / implementations >>in part dealing with CPU

Re: [PATCH 4/6] efi: Get the secure boot status

On Tue, Nov 22, 2016 at 02:47:27PM +, David Howells wrote: > Lukas Wunner wrote: > > The "out_efi_err" portion differs from the previous version of this > > patch. Setting a __u8 to a negative value, is this really what you > > want? > > Eh? efi_get_secureboot() returns an

Re: [PATCH 4/6] efi: Get the secure boot status

On Tue, Nov 22, 2016 at 02:47:27PM +, David Howells wrote: > Lukas Wunner wrote: > > The "out_efi_err" portion differs from the previous version of this > > patch. Setting a __u8 to a negative value, is this really what you > > want? > > Eh? efi_get_secureboot() returns an int as before.

[PATCH v8 0/8] Support Intel Turbo Boost Max Technology 3.0

With Intel Turbo Boost Max Technology 3.0 (ITMT), single-threaded performance is optimized by identifying processor's fastest core and running critical workloads on it. Refer to: http://www.intel.com/content/www/us/en/architecture-and-technology/turbo-boost/turbo-boost-max-technology.html This

[PATCH v8 1/8] sched: Extend scheduler's asym packing

We generalize the scheduler's asym packing to provide an ordering of the cpu beyond just the cpu number. This allows the use of the ASYM_PACKING scheduler machinery to move loads to preferred CPU in a sched domain. The preference is defined with the cpu priority given by

[PATCH v8 0/8] Support Intel Turbo Boost Max Technology 3.0

With Intel Turbo Boost Max Technology 3.0 (ITMT), single-threaded performance is optimized by identifying processor's fastest core and running critical workloads on it. Refer to: http://www.intel.com/content/www/us/en/architecture-and-technology/turbo-boost/turbo-boost-max-technology.html This

[PATCH v8 1/8] sched: Extend scheduler's asym packing

We generalize the scheduler's asym packing to provide an ordering of the cpu beyond just the cpu number. This allows the use of the ASYM_PACKING scheduler machinery to move loads to preferred CPU in a sched domain. The preference is defined with the cpu priority given by

[PATCH v8 4/8] x86/sysctl: Add sysctl for ITMT scheduling feature

Intel Turbo Boost Max Technology 3.0 (ITMT) feature allows some cores to be boosted to higher turbo frequency than others. Add /proc/sys/kernel/sched_itmt_enabled so operator can enable/disable scheduling of tasks that favor cores with higher turbo boost frequency potential. By default, system

[PATCH v8 5/8] x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU

Some Intel cores in a package can be boosted to a higher turbo frequency with ITMT 3.0 technology. The scheduler can use the asymmetric packing feature to move tasks to the more capable cores. If ITMT is enabled, add SD_ASYM_PACKING flag to the thread and core sched domains to enable asymmetric

[PATCH v8 4/8] x86/sysctl: Add sysctl for ITMT scheduling feature

Intel Turbo Boost Max Technology 3.0 (ITMT) feature allows some cores to be boosted to higher turbo frequency than others. Add /proc/sys/kernel/sched_itmt_enabled so operator can enable/disable scheduling of tasks that favor cores with higher turbo boost frequency potential. By default, system

[PATCH v8 5/8] x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU

Some Intel cores in a package can be boosted to a higher turbo frequency with ITMT 3.0 technology. The scheduler can use the asymmetric packing feature to move tasks to the more capable cores. If ITMT is enabled, add SD_ASYM_PACKING flag to the thread and core sched domains to enable asymmetric

[PATCH v8 3/8] x86: Enable Intel Turbo Boost Max Technology 3.0

On platforms supporting Intel Turbo Boost Max Technology 3.0, the maximum turbo frequencies of some cores in a CPU package may be higher than for the other cores in the same package. In that case, better performance (and possibly lower energy consumption as well) can be achieved by making the

[PATCH v8 7/8] acpi: bus: Set _OSC for diverse core support

From: Srinivas Pandruvada Set the OSC_SB_CPC_DIVERSE_HIGH_SUPPORT (bit 12) to enable diverse core support. This is required to inform BIOS the support of Intel Turbo Boost Max Technology 3.0 feature. Signed-off-by: Srinivas Pandruvada

[PATCH v8 3/8] x86: Enable Intel Turbo Boost Max Technology 3.0

On platforms supporting Intel Turbo Boost Max Technology 3.0, the maximum turbo frequencies of some cores in a CPU package may be higher than for the other cores in the same package. In that case, better performance (and possibly lower energy consumption as well) can be achieved by making the

[PATCH v8 7/8] acpi: bus: Set _OSC for diverse core support

From: Srinivas Pandruvada Set the OSC_SB_CPC_DIVERSE_HIGH_SUPPORT (bit 12) to enable diverse core support. This is required to inform BIOS the support of Intel Turbo Boost Max Technology 3.0 feature. Signed-off-by: Srinivas Pandruvada Signed-off-by: Tim Chen --- drivers/acpi/bus.c | 3 +++

[PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance

From: "Rafael J. Wysocki" This change uses acpi cppc_lib interface to get CPPC performance limits and calls scheduler interface to update per cpu highest priority. If there is a difference in highest performance of each CPUs, call scheduler interface to enable ITMT

[PATCH v8 6/8] acpi: bus: Enable HWP CPPC objects

From: Srinivas Pandruvada Need to set platform wide _OSC bits to enable CPPC and CPPC version 2. If platform supports CPPC, then BIOS exposes CPPC tables. The primary reason to enable CPPC support is to get the maximum performance of each CPU to check and

[PATCH v8 6/8] acpi: bus: Enable HWP CPPC objects

From: Srinivas Pandruvada Need to set platform wide _OSC bits to enable CPPC and CPPC version 2. If platform supports CPPC, then BIOS exposes CPPC tables. The primary reason to enable CPPC support is to get the maximum performance of each CPU to check and enable Intel Turbo Boost Max Technology

[PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance

From: "Rafael J. Wysocki" This change uses acpi cppc_lib interface to get CPPC performance limits and calls scheduler interface to update per cpu highest priority. If there is a difference in highest performance of each CPUs, call scheduler interface to enable ITMT feature for only one time.

[PATCH v8 2/8] x86/topology: Define x86's arch_update_cpu_topology

The scheduler calls arch_update_cpu_topology() to check whether the scheduler domains have to be rebuilt. So far x86 has no requirement for this, but the upcoming ITMT support makes this necessary. Request the rebuild when the x86 internal update flag is set. Suggested-by: Morten Rasmussen

[PATCH v8 2/8] x86/topology: Define x86's arch_update_cpu_topology

The scheduler calls arch_update_cpu_topology() to check whether the scheduler domains have to be rebuilt. So far x86 has no requirement for this, but the upcoming ITMT support makes this necessary. Request the rebuild when the x86 internal update flag is set. Suggested-by: Morten Rasmussen

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Nov 22, 2016 at 12:10 PM, Daniel Vetter wrote: > On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams > wrote: >> On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch >> wrote: >>> I personally like "device-DAX" idea but

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Nov 22, 2016 at 12:10 PM, Daniel Vetter wrote: > On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams > wrote: >> On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch >> wrote: >>> I personally like "device-DAX" idea but my concerns are: >>> >>> - How well it will co-exists with the DRM

Re: [PATCH v7 1/8] sched: Extend scheduler's asym packing

On Tue, 2016-11-22 at 11:09 +0100, Peter Zijlstra wrote: >  > > Not a big fan of that part.. would not something like the below cure > that? > > It would be slightly less optimal for Power7 but would actually be > faster (on average) for the ITMT case, but most importantly, it does > away with

[PATCH v2 0/2] trace-cmd record: add --cpu-list option

This series adds support for a --cpu-list option, which is much more human friendly than -M: # trace-cmd record --cpu-list 1,4,10-15 [...] The first patch is a small refectoring needed to make --cpu-list support fit nicely. The second patch adds the new option. v2 -- - Use the CPU_SET() API

Re: [PATCH v7 1/8] sched: Extend scheduler's asym packing

On Tue, 2016-11-22 at 11:09 +0100, Peter Zijlstra wrote: >  > > Not a big fan of that part.. would not something like the below cure > that? > > It would be slightly less optimal for Power7 but would actually be > faster (on average) for the ITMT case, but most importantly, it does > away with

[PATCH v2 0/2] trace-cmd record: add --cpu-list option

This series adds support for a --cpu-list option, which is much more human friendly than -M: # trace-cmd record --cpu-list 1,4,10-15 [...] The first patch is a small refectoring needed to make --cpu-list support fit nicely. The second patch adds the new option. v2 -- - Use the CPU_SET() API

[PATCH 1/2] trace-cmd record: refactor set_mask()

This commit makes set_mask() more specialized: all it does now is to write the cpumask to tracing_cpumask. The handling of "-M -1" is now done by the newly added alloc_mask_from_hex(). Also, uneeded checks are dropped and buffer_instance->cpumask points to dynamic memory. This work is a

[PATCH 2/2] trace-cmd record: add --cpu-list option

With --cpu-list you can do: # trace-cmd record --cpu-list 1,4,10-15 [...] Which is much more human friendly than -M. Support for --cpu-list is implemented by dynamically allocating a cpu_set_t object and setting the parsed CPUs. Using the CPU_SET API allows for more robost error detection.

[PATCH 1/2] trace-cmd record: refactor set_mask()

This commit makes set_mask() more specialized: all it does now is to write the cpumask to tracing_cpumask. The handling of "-M -1" is now done by the newly added alloc_mask_from_hex(). Also, uneeded checks are dropped and buffer_instance->cpumask points to dynamic memory. This work is a

[PATCH 2/2] trace-cmd record: add --cpu-list option

With --cpu-list you can do: # trace-cmd record --cpu-list 1,4,10-15 [...] Which is much more human friendly than -M. Support for --cpu-list is implemented by dynamically allocating a cpu_set_t object and setting the parsed CPUs. Using the CPU_SET API allows for more robost error detection.

Re: [PATCH V4 03/15] blk-throttle: configure bps/iops limit for cgroup in high limit

On Mon, Nov 14, 2016 at 02:22:10PM -0800, Shaohua Li wrote: > each queue will have a state machine. Initially queue is in LIMIT_HIGH > state, which means all cgroups will be throttled according to their high > limit. After all cgroups with high limit cross the limit, the queue state > gets

Re: [PATCH V4 03/15] blk-throttle: configure bps/iops limit for cgroup in high limit

On Mon, Nov 14, 2016 at 02:22:10PM -0800, Shaohua Li wrote: > each queue will have a state machine. Initially queue is in LIMIT_HIGH > state, which means all cgroups will be throttled according to their high > limit. After all cgroups with high limit cross the limit, the queue state > gets

Re: [PATCH V4 02/15] blk-throttle: add .high interface

Hello, Shaohua. Sorry about the delay. On Mon, Nov 14, 2016 at 02:22:09PM -0800, Shaohua Li wrote: > @@ -1376,11 +1414,37 @@ static ssize_t tg_set_max(struct kernfs_open_file *of, > goto out_finish; > } > > - tg->bps[READ][LIMIT_MAX] = v[0]; > -

Re: [PATCH V4 02/15] blk-throttle: add .high interface

Hello, Shaohua. Sorry about the delay. On Mon, Nov 14, 2016 at 02:22:09PM -0800, Shaohua Li wrote: > @@ -1376,11 +1414,37 @@ static ssize_t tg_set_max(struct kernfs_open_file *of, > goto out_finish; > } > > - tg->bps[READ][LIMIT_MAX] = v[0]; > -

Re: [PATCH] KVM: x86: restore IP after all far jump failures

Should the subject read: "KVM: x86: restore CS after all far jump failures"? On Tue, Nov 22, 2016 at 11:21 AM, Radim Krčmář wrote: > em_jmp_far and em_ret_far assumed that setting IP can only fail in 64 > bit mode, but syzkaller proved otherwise (and SDM agrees). > Code

Re: [PATCH] KVM: x86: restore IP after all far jump failures

Should the subject read: "KVM: x86: restore CS after all far jump failures"? On Tue, Nov 22, 2016 at 11:21 AM, Radim Krčmář wrote: > em_jmp_far and em_ret_far assumed that setting IP can only fail in 64 > bit mode, but syzkaller proved otherwise (and SDM agrees). > Code segment was restored upon

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch wrote: > Dan, > > I personally like "device-DAX" idea but my concerns are: > > - How well it will co-exists with the DRM infrastructure / implementations >in part dealing with CPU pointers? Inside the kernel

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch wrote: > Dan, > > I personally like "device-DAX" idea but my concerns are: > > - How well it will co-exists with the DRM infrastructure / implementations >in part dealing with CPU pointers? Inside the kernel a device-DAX range is "just

Re: [PATCH 1/5] mm: migrate: Add mode parameter to support additional page copy routines.

Hi Zi, [auto build test WARNING on linus/master] [also build test WARNING on v4.9-rc6 next-20161122] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Zi-Yan/Parallel-hugepage-migration

Re: [PATCH 1/5] mm: migrate: Add mode parameter to support additional page copy routines.

Hi Zi, [auto build test WARNING on linus/master] [also build test WARNING on v4.9-rc6 next-20161122] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Zi-Yan/Parallel-hugepage-migration

2 Millionen Euro

Ich war ein normaler Bürger genauso wie Sie, bis ich auf dem Gehen Spende einen Artikel corncerning abot ein lesen, die das Leben verändert, ich mit ihnen Kontakt auf und es war leicht, sie gaben mir guidline und am nächsten Tag bekam ich eine Spende von 2 Millionen Euro. Es ist einfach nur

2 Millionen Euro

Ich war ein normaler Bürger genauso wie Sie, bis ich auf dem Gehen Spende einen Artikel corncerning abot ein lesen, die das Leben verändert, ich mit ihnen Kontakt auf und es war leicht, sie gaben mir guidline und am nächsten Tag bekam ich eine Spende von 2 Millionen Euro. Es ist einfach nur

Re: [Qemu-devel] [PATCH] drm: update MAINTAINERS for qemu drivers (bochs, cirrus, qxl, virtio-gpu)

On 22/11/2016 19:54, Eric Blake wrote: >>> >> DRM DRIVER FOR BOCHS VIRTUAL GPU >>> >> M: Gerd Hoffmann >>> >> -S: Odd Fixes >>> >> +L: qemu-de...@nongnu.org >> > >> > qemu-devel list already has very high traffic - not sure whether it >> > makes much sense

Re: [Qemu-devel] [PATCH] drm: update MAINTAINERS for qemu drivers (bochs, cirrus, qxl, virtio-gpu)

On 22/11/2016 19:54, Eric Blake wrote: >>> >> DRM DRIVER FOR BOCHS VIRTUAL GPU >>> >> M: Gerd Hoffmann >>> >> -S: Odd Fixes >>> >> +L: qemu-de...@nongnu.org >> > >> > qemu-devel list already has very high traffic - not sure whether it >> > makes much sense to route even more

Re: BUG at drivers/iommu/amd_iommu.c:1436!

On 11/22/2016 03:45 AM, Joerg Roedel wrote: On Mon, Nov 21, 2016 at 04:47:59PM -0500, Mark Hounschell wrote: OK, I did get this message before the reported BUG message. gpiohsd gpiohsd: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0xffee8000]

Re: BUG at drivers/iommu/amd_iommu.c:1436!

On 11/22/2016 03:45 AM, Joerg Roedel wrote: On Mon, Nov 21, 2016 at 04:47:59PM -0500, Mark Hounschell wrote: OK, I did get this message before the reported BUG message. gpiohsd gpiohsd: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0xffee8000]

Applied "ASoC: sunxi: Add support for A23/A33/H3 codec's analog path controls" to the asoc tree

The patch ASoC: sunxi: Add support for A23/A33/H3 codec's analog path controls 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

Applied "ASoC: sunxi: Add support for A23/A33/H3 codec's analog path controls" to the asoc tree

The patch ASoC: sunxi: Add support for A23/A33/H3 codec's analog path controls 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

Re: [patch V2 00/12] thermal/x86_pkg_temp: Sanitize hotplug and locking

On Tue, 2016-11-22 at 17:57 +, Thomas Gleixner wrote: > Changes vs. V1: Fix the package removal wreckage reported by Srinivas > I haven't looked at individual patch but tested the series as a whole.  So Rui, you can add Tested-by: Srinivas Pandruvada

Re: [patch V2 00/12] thermal/x86_pkg_temp: Sanitize hotplug and locking

On Tue, 2016-11-22 at 17:57 +, Thomas Gleixner wrote: > Changes vs. V1: Fix the package removal wreckage reported by Srinivas > I haven't looked at individual patch but tested the series as a whole.  So Rui, you can add Tested-by: Srinivas Pandruvada Thanks, Srinivas

Re: [PATCH] mtd: mtdswap: fix spelling mistake "erassure" -> "erasure"

On Fri, Oct 28, 2016 at 11:51:47AM -0700, Joe Perches wrote: > I'd suggest as well fixing all the dev_ uses > to be a consistent form: (this also fixes the typo) > and a few other bits > > o Coalesce formats > o Realign arguments > o Add missing newlines Yeah, Colin missed this on the line he

Re: [PATCH] mtd: mtdswap: fix spelling mistake "erassure" -> "erasure"

On Fri, Oct 28, 2016 at 11:51:47AM -0700, Joe Perches wrote: > I'd suggest as well fixing all the dev_ uses > to be a consistent form: (this also fixes the typo) > and a few other bits > > o Coalesce formats > o Realign arguments > o Add missing newlines Yeah, Colin missed this on the line he

Re: [PATCH] mtd: mtdswap: fix spelling mistake "erassure" -> "erasure"

On Fri, Oct 28, 2016 at 07:25:59PM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err message > > Signed-off-by: Colin Ian King > --- > drivers/mtd/mtdswap.c | 2 +- > 1 file changed, 1

Re: [PATCH] mtd: mtdswap: fix spelling mistake "erassure" -> "erasure"

On Fri, Oct 28, 2016 at 07:25:59PM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err message > > Signed-off-by: Colin Ian King > --- > drivers/mtd/mtdswap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

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