Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #3]

On Fri, 2016-04-01 at 15:06 +0100, David Howells wrote: > David Howells wrote: > > > The three choice options I implemented don't exactly provide new features. > > Firstly: > > > > config IMA_LOAD_X509 > > > > allow keys to be loaded in at compile time, > > Ah - I

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #3]

On Fri, 2016-04-01 at 15:06 +0100, David Howells wrote: > David Howells wrote: > > > The three choice options I implemented don't exactly provide new features. > > Firstly: > > > > config IMA_LOAD_X509 > > > > allow keys to be loaded in at compile time, > > Ah - I think I'm labouring

Re: [PATCH 1/4] ARM: bcm2835: Switch BCM2835 to sdhci-iproc.c for MMC

On 03/31/2016 06:30 PM, Eric Anholt wrote: This approximately triples write performance for the SD card. My card is too full of important data to collect very reliable numbers, but I see 271.361% +/- 166.742% improvement (n=3 before, 6 after), for 'dd if=/dev/zero of=/boot/asdf bs=1M count=3

Re: [PATCH 1/4] ARM: bcm2835: Switch BCM2835 to sdhci-iproc.c for MMC

On 03/31/2016 06:30 PM, Eric Anholt wrote: This approximately triples write performance for the SD card. My card is too full of important data to collect very reliable numbers, but I see 271.361% +/- 166.742% improvement (n=3 before, 6 after), for 'dd if=/dev/zero of=/boot/asdf bs=1M count=3

Re: [PATCH] regulator: core: Use parent voltage from the supply when bypassed

On Thu, Mar 31, 2016 at 10:55:27AM -0700, Mark Brown wrote: > On Thu, Mar 31, 2016 at 03:27:58PM +0100, Jon Hunter wrote: > > On 30/03/16 18:32, Mark Brown wrote: > > > > + if (bypassed) { > > > + if (rdev->supply) { > > > + ret = > > >

Re: [PATCH 2/3] ARM: multi_v7_defconfig: Switch BCM2835 to sdhci-iproc.c for MMC

On 03/31/2016 08:01 PM, Stephen Warren wrote: On 03/31/2016 06:28 PM, Eric Anholt wrote: This approximately triples write performance for the SD card. My card is too full of important data to collect very reliable numbers, but I see 271.361% +/- 166.742% improvement (n=3 before, 6 after), for

Re: [PATCH] regulator: core: Use parent voltage from the supply when bypassed

On Thu, Mar 31, 2016 at 10:55:27AM -0700, Mark Brown wrote: > On Thu, Mar 31, 2016 at 03:27:58PM +0100, Jon Hunter wrote: > > On 30/03/16 18:32, Mark Brown wrote: > > > > + if (bypassed) { > > > + if (rdev->supply) { > > > + ret = > > >

Re: [PATCH 2/3] ARM: multi_v7_defconfig: Switch BCM2835 to sdhci-iproc.c for MMC

On 03/31/2016 08:01 PM, Stephen Warren wrote: On 03/31/2016 06:28 PM, Eric Anholt wrote: This approximately triples write performance for the SD card. My card is too full of important data to collect very reliable numbers, but I see 271.361% +/- 166.742% improvement (n=3 before, 6 after), for

Re: [PATCHSET v3][RFC] Make background writeback not suck

On 04/01/16 03:01, Dave Chinner wrote: > Can you go back to your original kernel, and lower nr_requests to 8? Sure, did that and as expected it didn't help much. Under prolonged stress it was actually even a bit worse than writeback throttling. IMHO that's not really surprising either, since

Re: [PATCHSET v3][RFC] Make background writeback not suck

On 04/01/16 03:01, Dave Chinner wrote: > Can you go back to your original kernel, and lower nr_requests to 8? Sure, did that and as expected it didn't help much. Under prolonged stress it was actually even a bit worse than writeback throttling. IMHO that's not really surprising either, since

Re: [PATCH v2 2/3] devicetree: Add ANX7814 SlimPort transmitter binding.

On Wed, Mar 30, 2016 at 06:22:23PM +0200, Enric Balletbo i Serra wrote: > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > Cc: Rob Herring > Signed-off-by: Enric Balletbo i Serra > --- >

Re: [PATCH v2 2/3] devicetree: Add ANX7814 SlimPort transmitter binding.

On Wed, Mar 30, 2016 at 06:22:23PM +0200, Enric Balletbo i Serra wrote: > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > Cc: Rob Herring > Signed-off-by: Enric Balletbo i Serra > --- > > Changes since v1: > - Rob Herring: >-

Re: [PATCH 4/7] Documentation: dt: socfpga: Add Altera Arria10 OCRAM binding

On Wed, Mar 30, 2016 at 10:27:45AM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Add the device tree bindings needed to support the Altera On-Chip > RAM ECC on the Arria10 chip. > > Signed-off-by: Thor Thayer >

Re: [PATCH 4/7] Documentation: dt: socfpga: Add Altera Arria10 OCRAM binding

On Wed, Mar 30, 2016 at 10:27:45AM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Add the device tree bindings needed to support the Altera On-Chip > RAM ECC on the Arria10 chip. > > Signed-off-by: Thor Thayer > --- > .../bindings/arm/altera/socfpga-eccmgr.txt |

Re: [PATCH 1/5] devicetree: bindings: Add vendor prefix for Amazon.com, Inc.

On Tue, Mar 29, 2016 at 09:28:23PM +0200, Paul Kocialkowski wrote: > This adds the amazon vendor prefix for Amazon.com, Inc. > > Signed-off-by: Paul Kocialkowski > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by:

Re: [PATCH 1/5] devicetree: bindings: Add vendor prefix for Amazon.com, Inc.

On Tue, Mar 29, 2016 at 09:28:23PM +0200, Paul Kocialkowski wrote: > This adds the amazon vendor prefix for Amazon.com, Inc. > > Signed-off-by: Paul Kocialkowski > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring

[PATCH] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

Two instances are moved to the new claim/release API: In the first instance, the driver was using mlock followed by iio_buffer_enabled(). Replace that code with the new API to guarantee the device stays in direct mode. There is no change in driver behavior. In the second instance, the driver was

[PATCH] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

Two instances are moved to the new claim/release API: In the first instance, the driver was using mlock followed by iio_buffer_enabled(). Replace that code with the new API to guarantee the device stays in direct mode. There is no change in driver behavior. In the second instance, the driver was

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #3]

On Fri, 2016-04-01 at 15:33 +0100, David Howells wrote: > Mimi Zohar wrote: > > > The only place where "KEY_ALLOC_BYPASS_RESTRICTION" is specified is in > > load_system_certificate_list(), when adding keys to > > the .builtin_trusted_keys keyring. There is no other

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #3]

On Fri, 2016-04-01 at 15:33 +0100, David Howells wrote: > Mimi Zohar wrote: > > > The only place where "KEY_ALLOC_BYPASS_RESTRICTION" is specified is in > > load_system_certificate_list(), when adding keys to > > the .builtin_trusted_keys keyring. There is no other set of keys > > builtin and

Re: [RFC][PATCH 1/2] dt/bindings: display: Add DT bindings for Mali Display Processors.

On Fri, Apr 01, 2016 at 05:21:51PM +0100, Liviu Dudau wrote: > Add DT bindings documentation for the Mali Display Processor. The bindings > describe the Mali DP500, DP550 and DP650 processors from ARM Ltd. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark

Re: [RFC][PATCH 1/2] dt/bindings: display: Add DT bindings for Mali Display Processors.

On Fri, Apr 01, 2016 at 05:21:51PM +0100, Liviu Dudau wrote: > Add DT bindings documentation for the Mali Display Processor. The bindings > describe the Mali DP500, DP550 and DP650 processors from ARM Ltd. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Ian Campbell > Cc: Kumar

Re: [PATCH] locking/qrwlock: Allow multiple spinning readers

On Fri, Apr 01, 2016 at 01:43:03PM +0200, Peter Zijlstra wrote: > > Ah, yes, I forgot about that. Lemme go find that discussions and see > > what I can do there. > > Completely untested.. > > --- > include/linux/compiler.h | 20 ++-- > kernel/locking/qspinlock.c | 12

Re: [PATCH] locking/qrwlock: Allow multiple spinning readers

On Fri, Apr 01, 2016 at 01:43:03PM +0200, Peter Zijlstra wrote: > > Ah, yes, I forgot about that. Lemme go find that discussions and see > > what I can do there. > > Completely untested.. > > --- > include/linux/compiler.h | 20 ++-- > kernel/locking/qspinlock.c | 12

Re: [intel-pstate driver regression] processor frequency very high even if in idle

2016-04-01 17:20 GMT+02:00 Doug Smythies : > On 2016.04.01 05:40 Rafael J. Wysocki wrote: >> On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote: >>> 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki : On Thursday, March 31, 2016 05:25:18 PM Jörg Otte

Re: [intel-pstate driver regression] processor frequency very high even if in idle

2016-04-01 17:20 GMT+02:00 Doug Smythies : > On 2016.04.01 05:40 Rafael J. Wysocki wrote: >> On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote: >>> 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki : On Thursday, March 31, 2016 05:25:18 PM Jörg Otte wrote: > 2016-03-31 13:42 GMT+02:00

Re: [PATCH v5 45/50] mtd: nand: vf610: switch to mtd_ooblayout_ops

On 2016-03-30 09:15, Boris Brezillon wrote: > Implementing the mtd_ooblayout_ops interface is the new way of exposing > ECC/OOB layout to MTD users. I think I sent this already in the last revision: Tested-by: Stefan Agner Acked-by: Stefan Agner -- Stefan >

Re: [RFC][PATCH v9 1/2] printk: Make printk() completely async

On (04/01/16 17:00), Petr Mladek wrote: > You need to move this assigment right above the > console_lock()/console_unlock() > calls. Otherwise, there is a race: > > CPU0: CPU1 > > printk_kthread_func() > > console_unlock() > > printk() >

Re: [PATCH v5 45/50] mtd: nand: vf610: switch to mtd_ooblayout_ops

On 2016-03-30 09:15, Boris Brezillon wrote: > Implementing the mtd_ooblayout_ops interface is the new way of exposing > ECC/OOB layout to MTD users. I think I sent this already in the last revision: Tested-by: Stefan Agner Acked-by: Stefan Agner -- Stefan > > Signed-off-by: Boris Brezillon

Re: [RFC][PATCH v9 1/2] printk: Make printk() completely async

On (04/01/16 17:00), Petr Mladek wrote: > You need to move this assigment right above the > console_lock()/console_unlock() > calls. Otherwise, there is a race: > > CPU0: CPU1 > > printk_kthread_func() > > console_unlock() > > printk() >

[PATCH RFC] sched/fair: let cpu's cfs_rq to reflect task migration

When task is migrated from CPU_A to CPU_B, scheduler will decrease the task's load/util from the task's cfs_rq and also add them into migrated cfs_rq. But if kernel enables CONFIG_FAIR_GROUP_SCHED then this cfs_rq is not the same one with cpu's cfs_rq. As a result, after task is migrated to CPU_B,

[PATCH RFC] sched/fair: let cpu's cfs_rq to reflect task migration

When task is migrated from CPU_A to CPU_B, scheduler will decrease the task's load/util from the task's cfs_rq and also add them into migrated cfs_rq. But if kernel enables CONFIG_FAIR_GROUP_SCHED then this cfs_rq is not the same one with cpu's cfs_rq. As a result, after task is migrated to CPU_B,

Re: [PATCH 3/3] staging: fwserial: (coding style) Rewriting a call to a long function

Hi Dominique, On 03/29/2016 10:14 AM, Dominique van den Broeck wrote: > Fixing a lone row exceeding 80 columns so the only remaining warnings > emitted by checkpatch.pl are missing comments on spinlocks and memory > barriers. > > Signed-off-by: Dominique van den Broeck > ---

Re: [PATCH 3/3] staging: fwserial: (coding style) Rewriting a call to a long function

Hi Dominique, On 03/29/2016 10:14 AM, Dominique van den Broeck wrote: > Fixing a lone row exceeding 80 columns so the only remaining warnings > emitted by checkpatch.pl are missing comments on spinlocks and memory > barriers. > > Signed-off-by: Dominique van den Broeck > --- >

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

Hello Xunlei, This patch can has potential to create some funny side effects. Especially the change from memblock_remove() to memblock_reserve() and the later call of reserve_crashkernel(). Give me some time. I will look into this next week. Michael On Wed, 30 Mar 2016 19:47:21 +0800 Xunlei

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

Hello Xunlei, This patch can has potential to create some funny side effects. Especially the change from memblock_remove() to memblock_reserve() and the later call of reserve_crashkernel(). Give me some time. I will look into this next week. Michael On Wed, 30 Mar 2016 19:47:21 +0800 Xunlei

Re: [RFC][PATCH v9 1/2] printk: Make printk() completely async

Hello, On (04/01/16 22:33), kbuild test robot wrote: > Hi Jan, > > > >> kernel/printk/printk.c:1938:28: warning: 'printk_kthread' defined but not > >> used [-Wunused-variable] > static struct task_struct *printk_kthread; >^ yeah. thanks. please find the

Re: [RFC][PATCH v9 1/2] printk: Make printk() completely async

Hello, On (04/01/16 22:33), kbuild test robot wrote: > Hi Jan, > > > >> kernel/printk/printk.c:1938:28: warning: 'printk_kthread' defined but not > >> used [-Wunused-variable] > static struct task_struct *printk_kthread; >^ yeah. thanks. please find the

Re: [PATCH] Security: Keys: Big keys stored encrypted

Kirill Marinushkin wrote: > +enum { > + ENC, > + DEC, > +}; "enum big_key_mode" and use it as a parameter type to big_key_crypt(). Also BIG_KEY_ENC, BIG_KEY_DEC. Please use prefixes consistently. > +static const char *rng_name = "stdrng"; > + > +/* > + *

Re: [PATCH] Security: Keys: Big keys stored encrypted

Kirill Marinushkin wrote: > +enum { > + ENC, > + DEC, > +}; "enum big_key_mode" and use it as a parameter type to big_key_crypt(). Also BIG_KEY_ENC, BIG_KEY_DEC. Please use prefixes consistently. > +static const char *rng_name = "stdrng"; > + > +/* > + * Algorithm name for big_key

Re: [PATCH 1/3] staging: fwserial: (coding style) Turning every "unsigned" into "unsigned int"

On 03/29/2016 10:14 AM, Dominique van den Broeck wrote: > Coding-style-only modifications to remove every warning saying: > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Compiled against revision "next-20160327". > > (checkpatch.pl was updated to treat "UNSPECIFIED_INT" warnings >

Re: [PATCH 1/3] staging: fwserial: (coding style) Turning every "unsigned" into "unsigned int"

On 03/29/2016 10:14 AM, Dominique van den Broeck wrote: > Coding-style-only modifications to remove every warning saying: > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Compiled against revision "next-20160327". > > (checkpatch.pl was updated to treat "UNSPECIFIED_INT" warnings >

[PATCH] perf/x86/intel/pt: Don't die on VMXON

Some versions of Intel PT do not support tracing across VMXON, more specifically, VMXON will clear TraceEn control bit and any attempt to set it before VMXOFF will throw a #GP, which in the current state of things will crash the kernel. Namely, $ perf record -e intel_pt// kvm -nographic on such

[PATCH] perf/x86/intel/pt: Don't die on VMXON

Some versions of Intel PT do not support tracing across VMXON, more specifically, VMXON will clear TraceEn control bit and any attempt to set it before VMXOFF will throw a #GP, which in the current state of things will crash the kernel. Namely, $ perf record -e intel_pt// kvm -nographic on such

Re: [PATCH 2/3] staging: fwserial: (coding style) removing "!= NULL" to comply with checkpatch.pl

On 03/29/2016 10:14 AM, Dominique van den Broeck wrote: > Removing two "!= NULL" from fwserial.c as suggested by checkpatch.pl. > Note that the associated expression "port->port.console" is a 1-bit-field > that is already assumed as an implicit boolean (that is: without comparison) Similarly,

Re: [PATCH 2/3] staging: fwserial: (coding style) removing "!= NULL" to comply with checkpatch.pl

On 03/29/2016 10:14 AM, Dominique van den Broeck wrote: > Removing two "!= NULL" from fwserial.c as suggested by checkpatch.pl. > Note that the associated expression "port->port.console" is a 1-bit-field > that is already assumed as an implicit boolean (that is: without comparison) Similarly,

[RFC][PATCH 2/2] drm/arm: Add support for Mali Display Processors

Add support for the new family of Display Processors from ARM Ltd. This commit adds basic support for Mali DP500, DP550 and DP650 parts, with only the display engine being supported at the moment. Cc: David Brown Cc: Brian Starkey Signed-off-by:

[RFC][PATCH 1/2] dt/bindings: display: Add DT bindings for Mali Display Processors.

Add DT bindings documentation for the Mali Display Processor. The bindings describe the Mali DP500, DP550 and DP650 processors from ARM Ltd. Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell

[RFC][PATCH 2/2] drm/arm: Add support for Mali Display Processors

Add support for the new family of Display Processors from ARM Ltd. This commit adds basic support for Mali DP500, DP550 and DP650 parts, with only the display engine being supported at the moment. Cc: David Brown Cc: Brian Starkey Signed-off-by: Liviu Dudau --- drivers/gpu/drm/arm/Kconfig

[RFC][PATCH 1/2] dt/bindings: display: Add DT bindings for Mali Display Processors.

Add DT bindings documentation for the Mali Display Processor. The bindings describe the Mali DP500, DP550 and DP650 processors from ARM Ltd. Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Liviu Dudau ---

[RFC][PATCH 0/2] Initial support for ARM Mali Display Processors

Hello, Here is the public first version of the driver for the Mali Display Processors. Currently, the driver supports the Display Engine found in Mali DP500, DP550 and DP650, with up to 3 planes that can be rotated by the hardware. There are features that the hardware supports that are not

[RFC][PATCH 0/2] Initial support for ARM Mali Display Processors

Hello, Here is the public first version of the driver for the Mali Display Processors. Currently, the driver supports the Display Engine found in Mali DP500, DP550 and DP650, with up to 3 planes that can be rotated by the hardware. There are features that the hardware supports that are not

Re: [PATCH] sched/deadline: No need to check NULL later_mask

On Fri, Apr 01, 2016 at 08:16:37PM +0800, Xunlei Pang wrote: > On 2016/04/01 at 19:29, Peter Zijlstra wrote: > > On Fri, Apr 01, 2016 at 07:13:18PM +0800, Xunlei Pang wrote: > >> Unlike rt tasks, we (should) have no deadline tasks in > >> booting phase before the mask is allocated, so we can > >>

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

Hi, On Fri, Apr 01, 2016 at 11:02:23AM -0500, David Lechner wrote: > On 04/01/2016 09:45 AM, Bin Liu wrote: > >>>+EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); > >> > >>Don't prefer export symbols from PHY driver. That'll create unnecessary > >>dependencies between the controller and the PHY. > >

Re: [PATCH] sched/deadline: No need to check NULL later_mask

On Fri, Apr 01, 2016 at 08:16:37PM +0800, Xunlei Pang wrote: > On 2016/04/01 at 19:29, Peter Zijlstra wrote: > > On Fri, Apr 01, 2016 at 07:13:18PM +0800, Xunlei Pang wrote: > >> Unlike rt tasks, we (should) have no deadline tasks in > >> booting phase before the mask is allocated, so we can > >>

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

Hi, On Fri, Apr 01, 2016 at 11:02:23AM -0500, David Lechner wrote: > On 04/01/2016 09:45 AM, Bin Liu wrote: > >>>+EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); > >> > >>Don't prefer export symbols from PHY driver. That'll create unnecessary > >>dependencies between the controller and the PHY. > >

Re: [PATCH v1 2/2] rockchip: power-domain: support qos save and restore

Hi Elaine, Am Freitag, 1. April 2016, 10:33:45 schrieb Elaine Zhang: > I agree with most of your modifications. > Except, the u32 *qos_save_regs below you're right. I didn't take that into account when my open-coding my idea. A bit more below: > On 04/01/2016 12:31 AM, Heiko Stuebner wrote: > >

Re: [PATCH v1 2/2] rockchip: power-domain: support qos save and restore

Hi Elaine, Am Freitag, 1. April 2016, 10:33:45 schrieb Elaine Zhang: > I agree with most of your modifications. > Except, the u32 *qos_save_regs below you're right. I didn't take that into account when my open-coding my idea. A bit more below: > On 04/01/2016 12:31 AM, Heiko Stuebner wrote: > >

Re: [PATCH] Security: Rename SELinux to NSALinux

On Friday 01 April 2016 08:47:53 Casey Schaufler wrote: > On 4/1/2016 1:47 AM, Pali Rohár wrote: > > This patch helps NSA agents, so they will know easily which part of Linux > > kernel code and also which config options must be enabled for their > > "customer" kernel builds. > > > > Patch also

Re: [PATCH] Security: Rename SELinux to NSALinux

On Friday 01 April 2016 08:47:53 Casey Schaufler wrote: > On 4/1/2016 1:47 AM, Pali Rohár wrote: > > This patch helps NSA agents, so they will know easily which part of Linux > > kernel code and also which config options must be enabled for their > > "customer" kernel builds. > > > > Patch also

Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

On Fri, Apr 01, 2016 at 12:45:21PM +0530, Laxman Dewangan wrote: > On Friday 01 April 2016 02:09 AM, Mark Brown wrote: > >Is the error in the observed values a function of the capacitance that > >we can calcuate here? > As per datasheet, There is no direct equation for ramp time deviation when >

Re: [PATCH] x86: Add a turbo mode sysctl

On Fri, 1 Apr 2016, Andy Lutomirski wrote: > +static void update_local_turbo_mode(void *dummy) > +{ > + unsigned long cr0 = read_cr0(); > + > + /* > + * KVM doesn't properly handle CD. > + * > + * XXX: this may interact poorly with CPU hotplug. Please cc these crazy folks

Re: [PATCH] x86: Add a turbo mode sysctl

On Fri, 1 Apr 2016, Andy Lutomirski wrote: > +static void update_local_turbo_mode(void *dummy) > +{ > + unsigned long cr0 = read_cr0(); > + > + /* > + * KVM doesn't properly handle CD. > + * > + * XXX: this may interact poorly with CPU hotplug. Please cc these crazy folks

Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

On Fri, Apr 01, 2016 at 12:45:21PM +0530, Laxman Dewangan wrote: > On Friday 01 April 2016 02:09 AM, Mark Brown wrote: > >Is the error in the observed values a function of the capacitance that > >we can calcuate here? > As per datasheet, There is no direct equation for ramp time deviation when >

Re: [PATCH] x86: Add a turbo mode sysctl

Hi Andy, [auto build test WARNING on tip/x86/core] [also build test WARNING on v4.6-rc1 next-20160401] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Andy-Lutomirski/x86-Add-a-turbo-mode

Re: [PATCH] x86: Add a turbo mode sysctl

Hi Andy, [auto build test WARNING on tip/x86/core] [also build test WARNING on v4.6-rc1 next-20160401] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Andy-Lutomirski/x86-Add-a-turbo-mode

Re: [PATCH] x86: Add a turbo mode sysctl

On Fri, Apr 01, 2016 at 08:49:53AM -0700, Andy Lutomirski wrote: > Sadly, hardware turbo mode buttons are few and far between in these > degenerate times. Add a software control at /proc/sys/turbo_mode. > > Unfortunately, Linux graphical environments have become very > heavy-weight and are

Re: [PATCH] x86: Add a turbo mode sysctl

On Fri, Apr 01, 2016 at 08:49:53AM -0700, Andy Lutomirski wrote: > Sadly, hardware turbo mode buttons are few and far between in these > degenerate times. Add a software control at /proc/sys/turbo_mode. > > Unfortunately, Linux graphical environments have become very > heavy-weight and are

Re: Block layer - meaning of REQ_FUA on not write requests

Alex Bligh writes: > I am trying to clean up the documentation of the NBD protocol. NBD's > support for Force Unit Access (FUA) was modelled on the linux kernel > block layer. When I added support a few years ago, I omitted to find > out exactly what types of request it applies

Re: Block layer - meaning of REQ_FUA on not write requests

Alex Bligh writes: > I am trying to clean up the documentation of the NBD protocol. NBD's > support for Force Unit Access (FUA) was modelled on the linux kernel > block layer. When I added support a few years ago, I omitted to find > out exactly what types of request it applies to. Obviously it

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

On 04/01/2016 09:45 AM, Bin Liu wrote: +EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); Don't prefer export symbols from PHY driver. That'll create unnecessary dependencies between the controller and the PHY. Agreed. I think it'll be better to create a new attribute and use it? Another

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

On 04/01/2016 09:45 AM, Bin Liu wrote: +EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); Don't prefer export symbols from PHY driver. That'll create unnecessary dependencies between the controller and the PHY. Agreed. I think it'll be better to create a new attribute and use it? Another

Re: Bug with paravirt ops and livepatches

On Fri, Apr 01, 2016 at 05:46:52PM +0200, Miroslav Benes wrote: > On Fri, 1 Apr 2016, Jiri Kosina wrote: > > > On Tue, 29 Mar 2016, Jiri Kosina wrote: > > > > > Agreed; I think we should be safe applying all the alternatives (with > > > paravirt being really just a special case of those) to the

Re: Bug with paravirt ops and livepatches

On Fri, Apr 01, 2016 at 05:46:52PM +0200, Miroslav Benes wrote: > On Fri, 1 Apr 2016, Jiri Kosina wrote: > > > On Tue, 29 Mar 2016, Jiri Kosina wrote: > > > > > Agreed; I think we should be safe applying all the alternatives (with > > > paravirt being really just a special case of those) to the

RE: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

>Question about removing lustre typedefs. > >Various bits of lustre code use a mix of struct foo and foo_t. > >When would be an appropriate time to submit patches similar to >below that individually remove various typedefs from lustre code? > >These are pretty trivial to produce and verify so

RE: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

>Question about removing lustre typedefs. > >Various bits of lustre code use a mix of struct foo and foo_t. > >When would be an appropriate time to submit patches similar to >below that individually remove various typedefs from lustre code? > >These are pretty trivial to produce and verify so

Re: [PATCH] Security: Keys: Added derived keytype

Kirill Marinushkin wrote: > For details see > Documentation/security/keys-derived.txt Please include at least a summary in the patch description, not just a pointer to the documentation file. > + Derived Keys > + > +Derived is a keytype of the

Re: [PATCH] Security: Keys: Added derived keytype

Kirill Marinushkin wrote: > For details see > Documentation/security/keys-derived.txt Please include at least a summary in the patch description, not just a pointer to the documentation file. > + Derived Keys > + > +Derived is a keytype of the kernel keyring facility. >

[PATCH v10 07/17] Xen: ARM: Add support for mapping AMBA device mmio

Add a bus_notifier for AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini --- drivers/xen/arm-device.c | 43

[PATCH v10 07/17] Xen: ARM: Add support for mapping AMBA device mmio

Add a bus_notifier for AMBA bus device in order to map the device mmio regions when DOM0 booting with ACPI. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini --- drivers/xen/arm-device.c | 43 +++ 1 file changed, 43 insertions(+) diff --git

[PATCH v10 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place

Move xlated_setup_gnttab_pages to common place, so it can be reused by ARM to setup grant table. Rename it to xen_xlate_map_ballooned_pages. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini --- arch/x86/xen/grant-table.c |

[PATCH v10 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place

Move xlated_setup_gnttab_pages to common place, so it can be reused by ARM to setup grant table. Rename it to xen_xlate_map_ballooned_pages. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini --- arch/x86/xen/grant-table.c | 57 +--

[PATCH v10 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information. CC: Rob Herring Signed-off-by: Shannon Zhao Acked-by: Rob Herring Reviewed-by: Stefano Stabellini

[PATCH v10 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI

The kernel will get the event-channel IRQ through HVM_PARAM_CALLBACK_IRQ. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini --- arch/arm/xen/enlighten.c | 36 +++- 1 file changed, 35

[PATCH v10 11/17] ARM: XEN: Move xen_early_init() before efi_init()

Move xen_early_init() before efi_init(), then when calling efi_init() could initialize Xen specific UEFI. Check if it runs on Xen hypervisor through the flat dts. Cc: Russell King Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini

[PATCH v10 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI

Add a new function to parse DT parameters for Xen specific UEFI just like the way for normal UEFI. Then it could reuse the existing codes. If Xen supports EFI, initialize runtime services. CC: Matt Fleming Signed-off-by: Shannon Zhao

[PATCH v10 14/17] XEN: EFI: Move x86 specific codes to architecture directory

Move x86 specific codes to architecture directory and export those EFI runtime service functions. This will be useful for initializing runtime service on ARM later. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini ---

[PATCH v10 16/17] FDT: Add a helper to get the subnode by given name

Sometimes it needs to check if there is a subnode of given node in FDT by given name. Introduce this helper to get the subnode if it exists. CC: Rob Herring Signed-off-by: Shannon Zhao Acked-by: Stefano Stabellini

[PATCH v10 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information. CC: Rob Herring Signed-off-by: Shannon Zhao Acked-by: Rob Herring Reviewed-by: Stefano Stabellini --- Documentation/devicetree/bindings/arm/xen.txt | 35 +++

[PATCH v10 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI

The kernel will get the event-channel IRQ through HVM_PARAM_CALLBACK_IRQ. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini --- arch/arm/xen/enlighten.c | 36 +++- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/arch/arm/xen/enlighten.c

[PATCH v10 11/17] ARM: XEN: Move xen_early_init() before efi_init()

Move xen_early_init() before efi_init(), then when calling efi_init() could initialize Xen specific UEFI. Check if it runs on Xen hypervisor through the flat dts. Cc: Russell King Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini --- arch/arm/kernel/setup.c | 2 +-

[PATCH v10 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI

Add a new function to parse DT parameters for Xen specific UEFI just like the way for normal UEFI. Then it could reuse the existing codes. If Xen supports EFI, initialize runtime services. CC: Matt Fleming Signed-off-by: Shannon Zhao Reviewed-by: Matt Fleming Reviewed-by: Stefano Stabellini

[PATCH v10 14/17] XEN: EFI: Move x86 specific codes to architecture directory

Move x86 specific codes to architecture directory and export those EFI runtime service functions. This will be useful for initializing runtime service on ARM later. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini --- arch/x86/xen/efi.c| 112

[PATCH v10 16/17] FDT: Add a helper to get the subnode by given name

Sometimes it needs to check if there is a subnode of given node in FDT by given name. Introduce this helper to get the subnode if it exists. CC: Rob Herring Signed-off-by: Shannon Zhao Acked-by: Stefano Stabellini Acked-by: Rob Herring --- drivers/of/fdt.c | 13 +

[PATCH v10 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

When running on Xen hypervisor, runtime services are supported through hypercall. Add a Xen specific function to initialize runtime services. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini ---

[PATCH v10 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and a /hypervisor node in DT. So check if it needs to enable ACPI. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini Acked-by: Hanjun Guo

[PATCH v10 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

This new delivery type which is for ARM shares the same value with HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86. val[15:8] is flag: val[7:0] is a PPI. To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and bit 9 stands the interrupt polarity is active low(1) or high(0).

[PATCH v10 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and a /hypervisor node in DT. So check if it needs to enable ACPI. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini Acked-by: Hanjun Guo --- arch/arm64/kernel/acpi.c | 14 ++ 1 file changed, 10

[PATCH v10 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

This new delivery type which is for ARM shares the same value with HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86. val[15:8] is flag: val[7:0] is a PPI. To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and bit 9 stands the interrupt polarity is active low(1) or high(0).

[PATCH v10 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

When running on Xen hypervisor, runtime services are supported through hypercall. Add a Xen specific function to initialize runtime services. Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini --- arch/arm/include/asm/xen/xen-ops.h | 6 ++ arch/arm/xen/Makefile|

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