Re: [PATCH v2] x86/vdso: Use RDPID in preference to LSL when available

On Thu, Apr 21, 2016 at 08:25:45AM -0700, Andy Lutomirski wrote: > Didn't I? Bah, I cut off the line which has the "=a" and then did the commenting. Sorry about the noise. > I thought about it, and there were two reasons: > > 1. I don't think we want to use __getcpu in the kernel. LSL is

Re: [PATCH v2] x86/vdso: Use RDPID in preference to LSL when available

On Thu, Apr 21, 2016 at 08:25:45AM -0700, Andy Lutomirski wrote: > Didn't I? Bah, I cut off the line which has the "=a" and then did the commenting. Sorry about the noise. > I thought about it, and there were two reasons: > > 1. I don't think we want to use __getcpu in the kernel. LSL is

Re: [PATCH] drivers: led: is31fl319x: 6/9-channel light effect led driver

Hi, > Am 21.04.2016 um 17:01 schrieb Rob Herring : > > On Mon, Apr 18, 2016 at 08:43:16PM +0200, H. Nikolaus Schaller wrote: >> This is a driver for the Integrated Silicon Solution Inc. LED driver >> chips IS31FL3196 and IS31FL3199. They can drive up to 6 or 9 >> LEDs. >> >>

Re: [PATCH] drivers: led: is31fl319x: 6/9-channel light effect led driver

Hi, > Am 21.04.2016 um 17:01 schrieb Rob Herring : > > On Mon, Apr 18, 2016 at 08:43:16PM +0200, H. Nikolaus Schaller wrote: >> This is a driver for the Integrated Silicon Solution Inc. LED driver >> chips IS31FL3196 and IS31FL3199. They can drive up to 6 or 9 >> LEDs. >> >> Each LED is

Re: [PATCH v3 3/3] dmaengine: vdma: Add clock support

On Thu, 2016-04-21 at 16:08:38 +0530, Kedareswara rao Appana wrote: > Added basic clock support for axi dma's. > The clocks are requested at probe and released at remove. > > Reviewed-by: Shubhrajyoti Datta > Signed-off-by: Kedareswara rao Appana > --- >

Re: [PATCH v3 3/3] dmaengine: vdma: Add clock support

On Thu, 2016-04-21 at 16:08:38 +0530, Kedareswara rao Appana wrote: > Added basic clock support for axi dma's. > The clocks are requested at probe and released at remove. > > Reviewed-by: Shubhrajyoti Datta > Signed-off-by: Kedareswara rao Appana > --- > Changes for v3: > ---> Added clock

[PATCH v3] regulator: core: Add debugfs to show constraint flags

There are debugfs entries for voltage and current, but not for the constraint flags. It's useful for debugging to be able to see what these flags are so this patch adds a new debugfs file. We can't use debugfs_create_bool for this because the flags are bitfields, so as this needs a special read

[PATCH v3] regulator: core: Add debugfs to show constraint flags

There are debugfs entries for voltage and current, but not for the constraint flags. It's useful for debugging to be able to see what these flags are so this patch adds a new debugfs file. We can't use debugfs_create_bool for this because the flags are bitfields, so as this needs a special read

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

On 04/21/16 14:18, Matt Fleming wrote: > ( Good Lord, I hate doing string manipulation in C ) > > On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote: >> >> So, "len" does not include the room for the terminating NUL-byte here. >> When "len" is passed to ucs2_as_utf8(), with the proposed patch

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

On 04/21/16 14:18, Matt Fleming wrote: > ( Good Lord, I hate doing string manipulation in C ) > > On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote: >> >> So, "len" does not include the room for the terminating NUL-byte here. >> When "len" is passed to ucs2_as_utf8(), with the proposed patch

[PATCH 3/5] regulator: core: Move registration of regulator device

The public functions to acquire a regulator, such as regulator_get(), internally look-up the regulator from the list of regulators that have been registered with the regulator device class. The registration of a new regulator with the regulator device class happens before the regulator has been

[PATCH 5/5] regulator: helpers: Ensure bypass register field matches ON value

When checking bypass state for a regulator, we check to see if any bits in the bypass mask are set. For most cases this is fine because there is typically, only a single bit used to determine if the regulator is in bypass. However, for some regulators, such as LDO6 on AS3722, the bypass state is

[PATCH 1/5] regulator: core: Don't terminate supply resolution early

The function regulator_register_resolve_supply() is called from the context of class_for_each_dev() (during the regulator registration) to resolve any supplies added. regulator_register_resolve_supply() will return an error if a regulator's supply cannot be resolved and this will terminate the

[PATCH 5/5] regulator: helpers: Ensure bypass register field matches ON value

When checking bypass state for a regulator, we check to see if any bits in the bypass mask are set. For most cases this is fine because there is typically, only a single bit used to determine if the regulator is in bypass. However, for some regulators, such as LDO6 on AS3722, the bypass state is

[PATCH 3/5] regulator: core: Move registration of regulator device

The public functions to acquire a regulator, such as regulator_get(), internally look-up the regulator from the list of regulators that have been registered with the regulator device class. The registration of a new regulator with the regulator device class happens before the regulator has been

[PATCH 1/5] regulator: core: Don't terminate supply resolution early

The function regulator_register_resolve_supply() is called from the context of class_for_each_dev() (during the regulator registration) to resolve any supplies added. regulator_register_resolve_supply() will return an error if a regulator's supply cannot be resolved and this will terminate the

Re: [PATCH] OMAPDSS: HDMI5: Change DDC timings

On 04/21/2016 09:38 AM, Tomi Valkeinen wrote: > Thanks, makes sense. Did you measure the rise & fall times? Do you get > more or less exactly 100kHz with the new times? Rise time is around 600 nsec and fall time is around 140 nsec. When the clock frequency is measured we get right at 100 kHz and

Re: [PATCH] OMAPDSS: HDMI5: Change DDC timings

On 04/21/2016 09:38 AM, Tomi Valkeinen wrote: > Thanks, makes sense. Did you measure the rise & fall times? Do you get > more or less exactly 100kHz with the new times? Rise time is around 600 nsec and fall time is around 140 nsec. When the clock frequency is measured we get right at 100 kHz and

Re: fs: GPF in locked_inode_to_wb_and_lock_list

Hello, On Thu, Apr 21, 2016 at 10:25:12AM +0200, Dmitry Vyukov wrote: > I use this script for symbolization: > https://github.com/google/sanitizers/blob/master/address-sanitizer/tools/kasan_symbolize.py > It invokes addr2line to provide file:line info, adds inline frames, > strips ? frames (are

Re: fs: GPF in locked_inode_to_wb_and_lock_list

Hello, On Thu, Apr 21, 2016 at 10:25:12AM +0200, Dmitry Vyukov wrote: > I use this script for symbolization: > https://github.com/google/sanitizers/blob/master/address-sanitizer/tools/kasan_symbolize.py > It invokes addr2line to provide file:line info, adds inline frames, > strips ? frames (are

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote: > yes, you are right. more load/store will be done in C code. > However such xchg_u8/u16 is just used by qspinlock now. and I did not see any > performance regression. > So just wrote in C, for simple. :) Which is fine; but worthy of a

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote: > yes, you are right. more load/store will be done in C code. > However such xchg_u8/u16 is just used by qspinlock now. and I did not see any > performance regression. > So just wrote in C, for simple. :) Which is fine; but worthy of a

[PATCH 2/5] regulator: core: Clear the supply pointer if enabling fails

During the resolution of a regulator's supply, we may attempt to enable the supply if the regulator itself is already enabled. If enabling the supply fails, then we will call _regulator_put() for the supply. However, the pointer to the supply has not been cleared for the regulator and this will

[PATCH 2/5] regulator: core: Clear the supply pointer if enabling fails

During the resolution of a regulator's supply, we may attempt to enable the supply if the regulator itself is already enabled. If enabling the supply fails, then we will call _regulator_put() for the supply. However, the pointer to the supply has not been cleared for the regulator and this will

[PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

The call to set_machine_constraints() in regulator_register(), will attempt to get the voltage for the regulator. A regulator that is in bypass will fail to be registered because we will attempt to get the voltage of the regulator (ie. it's bypass voltage) before the supply for the regulator has

[PATCH 4/5] regulator: core: Add early supply resolution for a bypassed regulator

The call to set_machine_constraints() in regulator_register(), will attempt to get the voltage for the regulator. A regulator that is in bypass will fail to be registered because we will attempt to get the voltage of the regulator (ie. it's bypass voltage) before the supply for the regulator has

Applied "ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver" to the asoc tree

The patch ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: core: Use a bitfield for continuous_voltage_range" to the regulator tree

The patch regulator: core: Use a bitfield for continuous_voltage_range has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: tps6524x: Fix broken use of spi_dev_get()" to the regulator tree

The patch regulator: tps6524x: Fix broken use of spi_dev_get() has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: core: Use a bitfield for continuous_voltage_range" to the regulator tree

The patch regulator: core: Use a bitfield for continuous_voltage_range has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: tps6524x: Fix broken use of spi_dev_get()" to the regulator tree

The patch regulator: tps6524x: Fix broken use of spi_dev_get() has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver" to the asoc tree

The patch ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

[PATCH 0/5] regulator: A few fixes for supply resolution

This series is to mainly address the boot failures reported on the Tegra124 Jetson TK1 where the AS3772 PMIC is failing to probe on -next [0]. However, there are a couple other patches I am including here which came from looking at this problem. Here is a summary of the patches ... Patch 1:

[PATCH 0/5] regulator: A few fixes for supply resolution

This series is to mainly address the boot failures reported on the Tegra124 Jetson TK1 where the AS3772 PMIC is failing to probe on -next [0]. However, there are a couple other patches I am including here which came from looking at this problem. Here is a summary of the patches ... Patch 1:

Applied "ASoC: arizona: Prefer lower FRATIO in pseudo-fractional mode" to the asoc tree

The patch ASoC: arizona: Prefer lower FRATIO in pseudo-fractional mode has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: arizona: Prefer lower FRATIO in pseudo-fractional mode" to the asoc tree

The patch ASoC: arizona: Prefer lower FRATIO in pseudo-fractional mode has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH V2 14/15] coresight: tmc: implementing TMC-ETR AUX space API

On 12/04/16 18:54, Mathieu Poirier wrote: This patch implement the AUX area interfaces required to use the TMC (configured as an ETR) from the Perf sub-system. The heuristic is heavily borrowed from the ETB10 and TMC-ETF implementation. Signed-off-by: Mathieu Poirier

Re: [PATCH V2 14/15] coresight: tmc: implementing TMC-ETR AUX space API

On 12/04/16 18:54, Mathieu Poirier wrote: This patch implement the AUX area interfaces required to use the TMC (configured as an ETR) from the Perf sub-system. The heuristic is heavily borrowed from the ETB10 and TMC-ETF implementation. Signed-off-by: Mathieu Poirier +static void

Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

2016-04-21 17:49+0200, Greg Kurz: > So we're good ? I support the change, just had a nit about API design for v2. > Whose tree can carry these patches ? (PowerPC is the only immediately affected arch, so I'd it there.) What do you think is best? My experience in this regard is

Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

2016-04-21 17:49+0200, Greg Kurz: > So we're good ? I support the change, just had a nit about API design for v2. > Whose tree can carry these patches ? (PowerPC is the only immediately affected arch, so I'd it there.) What do you think is best? My experience in this regard is

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On 2016年04月20日 22:24, Peter Zijlstra wrote: > On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote: > >> +#define __XCHG_GEN(cmp, type, sfx, skip, v) \ >> +static __always_inline unsigned long >> \ >> +__cmpxchg_u32##sfx(v

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On 2016年04月20日 22:24, Peter Zijlstra wrote: > On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote: > >> +#define __XCHG_GEN(cmp, type, sfx, skip, v) \ >> +static __always_inline unsigned long >> \ >> +__cmpxchg_u32##sfx(v

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

On 13/04/2016 07:14, Michael Ellerman wrote: > On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote: >> On 07/04/2016 23:49, Michael Ellerman wrote: >>> On 7 April 2016 7:23:46 pm AEST, Laurent Dufour >>> wrote: This series is required to handle TM state in

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

On 13/04/2016 07:14, Michael Ellerman wrote: > On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote: >> On 07/04/2016 23:49, Michael Ellerman wrote: >>> On 7 April 2016 7:23:46 pm AEST, Laurent Dufour >>> wrote: This series is required to handle TM state in CRIU. Is there a chance

[PATCH] Mark "Out of Date" addresses as undeliverable

From: Maxpain --- Documentation/zh_CN/CodingStyle | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/zh_CN/CodingStyle b/Documentation/zh_CN/CodingStyle index 654afd7..26ff11d 100644 --- a/Documentation/zh_CN/CodingStyle +++

[PATCH] Mark "Out of Date" addresses as undeliverable

From: Maxpain --- Documentation/zh_CN/CodingStyle | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/zh_CN/CodingStyle b/Documentation/zh_CN/CodingStyle index 654afd7..26ff11d 100644 --- a/Documentation/zh_CN/CodingStyle +++

[PATCH v2] Documentation: bindings: fix palmas-rtc documentation

change 100mA -> 100uA Signed-off-by: H. Nikolaus Schaller --- Documentation/devicetree/bindings/rtc/rtc-palmas.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/rtc/rtc-palmas.txt

Re: [PATCH] nohz_full: Make sched_should_stop_tick() more conservative

On Thu, Apr 21, 2016 at 04:42:13PM +0200, Peter Zijlstra wrote: > So I think that is indeed the right thing here. But looking at this > function I think there's more problems with it. > > It seems to assume that if there's FIFO tasks, those will run. This is > incorrect. The FIFO task can have a

[PATCH v2] Documentation: bindings: fix palmas-rtc documentation

change 100mA -> 100uA Signed-off-by: H. Nikolaus Schaller --- Documentation/devicetree/bindings/rtc/rtc-palmas.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/rtc/rtc-palmas.txt

Re: [PATCH] nohz_full: Make sched_should_stop_tick() more conservative

On Thu, Apr 21, 2016 at 04:42:13PM +0200, Peter Zijlstra wrote: > So I think that is indeed the right thing here. But looking at this > function I think there's more problems with it. > > It seems to assume that if there's FIFO tasks, those will run. This is > incorrect. The FIFO task can have a

Re: [PATCH v2 4/7] regulator: rk808: Add regulator driver for RK818

On Thu, Apr 21, 2016 at 03:12:38PM +0200, Wadim Egorov wrote: > Add support for the rk818 regulator. The regulator module consists > of 4 DCDCs, 9 LDOs, 1 switch and 1 BOOST converter which is used to > power OTG and HDMI5V. Acked-by: Mark Brown signature.asc Description:

Re: [PATCH v2 4/7] regulator: rk808: Add regulator driver for RK818

On Thu, Apr 21, 2016 at 03:12:38PM +0200, Wadim Egorov wrote: > Add support for the rk818 regulator. The regulator module consists > of 4 DCDCs, 9 LDOs, 1 switch and 1 BOOST converter which is used to > power OTG and HDMI5V. Acked-by: Mark Brown signature.asc Description: PGP signature

Re: [PATCH v2 3/7] regulator: rk808: Migrate to regulator core's simplified DT parsing code

On Thu, Apr 21, 2016 at 03:12:37PM +0200, Wadim Egorov wrote: > +static int rk808_set_suspend_voltage(struct regulator_dev *rdev, int uv) > +{ > + unsigned int reg; > + int sel = regulator_map_voltage_linear(rdev, uv, uv); > + > + if (sel < 0) > + return -EINVAL; > + > +

Re: [PATCH v2 3/7] regulator: rk808: Migrate to regulator core's simplified DT parsing code

On Thu, Apr 21, 2016 at 03:12:37PM +0200, Wadim Egorov wrote: > +static int rk808_set_suspend_voltage(struct regulator_dev *rdev, int uv) > +{ > + unsigned int reg; > + int sel = regulator_map_voltage_linear(rdev, uv, uv); > + > + if (sel < 0) > + return -EINVAL; > + > +

Re: [PATCH v4 2/2] KVM: move vcpu id checking to archs

2016-04-21 16:20+0200, Greg Kurz: > Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter (CVE-2013-4587)") > introduced a check to prevent potential kernel memory corruption in case > the vcpu id is too great. > > Unfortunately this check assumes vcpu ids grow in sequence with a common >

Re: [PATCH v4 2/2] KVM: move vcpu id checking to archs

2016-04-21 16:20+0200, Greg Kurz: > Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter (CVE-2013-4587)") > introduced a check to prevent potential kernel memory corruption in case > the vcpu id is too great. > > Unfortunately this check assumes vcpu ids grow in sequence with a common >

Re: [PATCH 09/18] ASoC: sti: Update DT example to match the driver code

On Thu, Apr 21, 2016 at 12:04:26PM +0100, Peter Griffin wrote: > uniperiph-id, version and mode are ST specific bindings and > need the 'st,' prefix. Update the examples, as otherwise copying > them yields a runtime error parsing the DT node. I'm not sure what connection this or the other ASoC

Re: [PATCH 09/18] ASoC: sti: Update DT example to match the driver code

On Thu, Apr 21, 2016 at 12:04:26PM +0100, Peter Griffin wrote: > uniperiph-id, version and mode are ST specific bindings and > need the 'st,' prefix. Update the examples, as otherwise copying > them yields a runtime error parsing the DT node. I'm not sure what connection this or the other ASoC

[PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge()

mem_cgroup_move_charge() invokes lru_add_drain_all() so that the pvec pages can be moved too. lru_add_drain_all() schedules and flushes work items on system_wq which depends on being able to create new kworkers to make forward progress. Since 1ed1328792ff ("sched, cgroup: replace

[PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge()

mem_cgroup_move_charge() invokes lru_add_drain_all() so that the pvec pages can be moved too. lru_add_drain_all() schedules and flushes work items on system_wq which depends on being able to create new kworkers to make forward progress. Since 1ed1328792ff ("sched, cgroup: replace

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky wrote: > > >On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> +void __init kernel_randomize_memory(void) >> +{ >> +size_t i; >> +unsigned long addr = memory_rand_start; >> +unsigned long padding, rand,

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky wrote: > > >On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> +void __init kernel_randomize_memory(void) >> +{ >> +size_t i; >> +unsigned long addr = memory_rand_start; >> +unsigned long padding, rand, mem_tb; >> +struct rnd_state

RE: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

Hi Bjorn > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 21 April 2016 16:49 > To: Gabriele Paoloni > Cc: Jisheng Zhang; jingooh...@gmail.com; pratyush.an...@gmail.com; > bhelg...@google.com; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org;

RE: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

Hi Bjorn > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 21 April 2016 16:49 > To: Gabriele Paoloni > Cc: Jisheng Zhang; jingooh...@gmail.com; pratyush.an...@gmail.com; > bhelg...@google.com; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org;

Re: [PATCH V3] audit: add tty field to LOGIN event

Hi, [auto build test ERROR on v4.6-rc4] [also build test ERROR on next-20160421] [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/Richard-Guy-Briggs/audit-add-tty-field-to-LOGIN-event/20160421

Re: [PATCH V3] audit: add tty field to LOGIN event

Hi, [auto build test ERROR on v4.6-rc4] [also build test ERROR on next-20160421] [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/Richard-Guy-Briggs/audit-add-tty-field-to-LOGIN-event/20160421

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: > On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky > wrote: >> >> >>On 04/15/2016 06:03 PM, Thomas Garnier wrote: >>> +void __init kernel_randomize_memory(void) >>> +{ >>> +size_t i; >>> +

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: > On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky > wrote: >> >> >>On 04/15/2016 06:03 PM, Thomas Garnier wrote: >>> +void __init kernel_randomize_memory(void) >>> +{ >>> +size_t i; >>> +unsigned long addr = memory_rand_start; >>>

Re: stable-security kernel updates

[Sorry I'm cutting out lots of stuff here, I just want to understand the point below first] On 04/21/2016 10:54 AM, Jiri Slaby wrote: > On 04/21/2016, 03:53 PM, Sasha Levin wrote: >>> Pardom my ignorance, how can you actually be sure? >> >> I'm not, same way you can't be sure about your stable

Re: stable-security kernel updates

[Sorry I'm cutting out lots of stuff here, I just want to understand the point below first] On 04/21/2016 10:54 AM, Jiri Slaby wrote: > On 04/21/2016, 03:53 PM, Sasha Levin wrote: >>> Pardom my ignorance, how can you actually be sure? >> >> I'm not, same way you can't be sure about your stable

Re: [PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge()

On Thu, Apr 21, 2016 at 05:00:24PM +0200, Petr Mladek wrote: > > Acked-by: Michal Hocko > > Just for completeness. The problematic LTP test is running for hours > with this patch. Feel free to add: > > Tested-by: Petr Mladek Thanks, I'm gonna repost w/

Re: [PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge()

On Thu, Apr 21, 2016 at 05:00:24PM +0200, Petr Mladek wrote: > > Acked-by: Michal Hocko > > Just for completeness. The problematic LTP test is running for hours > with this patch. Feel free to add: > > Tested-by: Petr Mladek Thanks, I'm gonna repost w/ Andrew cc'd and the tags added. --

Re: [PATCH 10/18] ASoC: sti: Update example to include assigned-clocks and mclk-fs

On Thu, Apr 21, 2016 at 12:04:27PM +0100, Peter Griffin wrote: > clocks = <_s_d0_flexgen CLK_PCM_2>; > + assigned-clocks = <_s_d0_flexgen CLK_PCM_2>; > + assigned-clock-parents = <_s_d0_quadfs 2>; > + assigned-clock-rates = <5000>; This may

Re: [PATCH 10/18] ASoC: sti: Update example to include assigned-clocks and mclk-fs

On Thu, Apr 21, 2016 at 12:04:27PM +0100, Peter Griffin wrote: > clocks = <_s_d0_flexgen CLK_PCM_2>; > + assigned-clocks = <_s_d0_flexgen CLK_PCM_2>; > + assigned-clock-parents = <_s_d0_quadfs 2>; > + assigned-clock-rates = <5000>; This may

Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

On Thu, 21 Apr 2016 17:29:16 +0200 Radim Krčmář wrote: > 2016-04-21 13:29+0200, Greg Kurz: > > On Wed, 20 Apr 2016 20:29:09 +0200 > > Radim Krčmář wrote: > >> 2016-04-20 17:44+0200, Greg Kurz: > >> > Commit 338c7dbadd26 ("KVM: Improve create VCPU

Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

On Thu, 21 Apr 2016 17:29:16 +0200 Radim Krčmář wrote: > 2016-04-21 13:29+0200, Greg Kurz: > > On Wed, 20 Apr 2016 20:29:09 +0200 > > Radim Krčmář wrote: > >> 2016-04-20 17:44+0200, Greg Kurz: > >> > Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter > >> > (CVE-2013-4587)") > >> >

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote: > On 2016年04月20日 22:24, Peter Zijlstra wrote: > > On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote: > > > >> +#define __XCHG_GEN(cmp, type, sfx, skip, v) > >> \ > >> +static __always_inline

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote: > On 2016年04月20日 22:24, Peter Zijlstra wrote: > > On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote: > > > >> +#define __XCHG_GEN(cmp, type, sfx, skip, v) > >> \ > >> +static __always_inline

Re: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

On Tue, Apr 12, 2016 at 09:43:32AM +, Gabriele Paoloni wrote: > Hi Bjorn > > [...] > > > > > > > > > What's the hisi plan for resuming after suspend-to-RAM? How does > > the > > > > RC get reprogrammed after it loses all its state? > > > > > > PM is not part of the driver yet. This is

Re: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

On Tue, Apr 12, 2016 at 09:43:32AM +, Gabriele Paoloni wrote: > Hi Bjorn > > [...] > > > > > > > > > What's the hisi plan for resuming after suspend-to-RAM? How does > > the > > > > RC get reprogrammed after it loses all its state? > > > > > > PM is not part of the driver yet. This is

Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch

From: Yunhui Cui Sent: Thursday, April 21, 2016 3:41 AM To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com; han...@freescale.com Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org;

Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch

From: Yunhui Cui Sent: Thursday, April 21, 2016 3:41 AM To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com; han...@freescale.com Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org;

[PATCH] drm/i915/vlv: Enable polling when we shut off all power domains

Unfortunately HPD isn't functional once we shut off all of the power domains. Unfortunately we can end up shutting off all of the power domains in any situation where we don't have any monitors connected, essentially breaking hpd for the user unless they reboot with one of their monitors

Re: [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

On Wed, Apr 20, 2016 at 03:02:31PM +0530, Vinay Simha BN wrote: > Add documentation for lt070me05000 panel > > Signed-off-by: Vinay Simha BN > --- > .../bindings/display/panel/jdi,lt070me05000.txt| 43 > ++ > 1 file changed, 43 insertions(+) >

[PATCH] drm/i915/vlv: Enable polling when we shut off all power domains

Unfortunately HPD isn't functional once we shut off all of the power domains. Unfortunately we can end up shutting off all of the power domains in any situation where we don't have any monitors connected, essentially breaking hpd for the user unless they reboot with one of their monitors

Re: [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

On Wed, Apr 20, 2016 at 03:02:31PM +0530, Vinay Simha BN wrote: > Add documentation for lt070me05000 panel > > Signed-off-by: Vinay Simha BN > --- > .../bindings/display/panel/jdi,lt070me05000.txt| 43 > ++ > 1 file changed, 43 insertions(+) > create mode 100644 >

Re: [PATCH V2 06/14] irqdomain: Don't set type when mapping an IRQ

On 20/04/16 12:03, Jon Hunter wrote: > Some IRQ chips, such as GPIO controllers or secondary level interrupt > controllers, may require require additional runtime power management > control to ensure they are accessible. For such IRQ chips, it makes sense > to enable the IRQ chip when interrupts

Re: [PATCH V2 06/14] irqdomain: Don't set type when mapping an IRQ

On 20/04/16 12:03, Jon Hunter wrote: > Some IRQ chips, such as GPIO controllers or secondary level interrupt > controllers, may require require additional runtime power management > control to ensure they are accessible. For such IRQ chips, it makes sense > to enable the IRQ chip when interrupts

Re: [PATCH/RFC] perf core: Allow setting up max frame stack depth via sysctl

Em Thu, Apr 21, 2016 at 12:17:07PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Apr 21, 2016 at 12:48:58PM +0200, Peter Zijlstra escreveu: > > On Wed, Apr 20, 2016 at 07:47:30PM -0300, Arnaldo Carvalho de Melo wrote: > > > +++ b/kernel/events/callchain.c > > > > @@ -73,7 +81,7 @@ static

Re: [PATCH/RFC] perf core: Allow setting up max frame stack depth via sysctl

Em Thu, Apr 21, 2016 at 12:17:07PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Apr 21, 2016 at 12:48:58PM +0200, Peter Zijlstra escreveu: > > On Wed, Apr 20, 2016 at 07:47:30PM -0300, Arnaldo Carvalho de Melo wrote: > > > +++ b/kernel/events/callchain.c > > > > @@ -73,7 +81,7 @@ static

Re: [PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

On Mon, Mar 21, 2016 at 10:39:52AM +0100, Krzysztof Halasa wrote: > I think this bug needs to be fixed, this way or another. > > The platform in question is Cavium CNS3xxx, ARMv6. > > A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid > potential stack overflow") converted

Re: [PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

On Mon, Mar 21, 2016 at 10:39:52AM +0100, Krzysztof Halasa wrote: > I think this bug needs to be fixed, this way or another. > > The platform in question is Cavium CNS3xxx, ARMv6. > > A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid > potential stack overflow") converted

Re: [PATCH] Fix bindings documentation for Palmas.

> Am 21.04.2016 um 17:31 schrieb Rob Herring : > > On Tue, Apr 19, 2016 at 05:42:51PM +0200, H. Nikolaus Schaller wrote: >> >> >> H. Nikolaus Schaller (1): >> Documentation: bindings: fix palmas-rtc documentation >> >> Documentation/devicetree/bindings/rtc/rtc-palmas.txt | 6

Re: [PATCH] Fix bindings documentation for Palmas.

> Am 21.04.2016 um 17:31 schrieb Rob Herring : > > On Tue, Apr 19, 2016 at 05:42:51PM +0200, H. Nikolaus Schaller wrote: >> >> >> H. Nikolaus Schaller (1): >> Documentation: bindings: fix palmas-rtc documentation >> >> Documentation/devicetree/bindings/rtc/rtc-palmas.txt | 6 +++--- >> 1 file

[PATCH v12 1/2] kernel.h: add u64_to_user_ptr()

From: Gustavo Padovan This function had copies in 3 different files. Unify them in kernel.h. Cc: Joe Perches Cc: Andrew Morton Cc: David Airlie Cc: Daniel Vetter Cc: Rob

[PATCH v12 1/2] kernel.h: add u64_to_user_ptr()

From: Gustavo Padovan This function had copies in 3 different files. Unify them in kernel.h. Cc: Joe Perches Cc: Andrew Morton Cc: David Airlie Cc: Daniel Vetter Cc: Rob Clark Signed-off-by: Gustavo Padovan --- v2: add typecheck() (comment from Maarten Lankhorst) v3: make

[PATCH v12 0/2] staging/android: Sync ABI rework

From: Gustavo Padovan Hi, Here we clean up the Sync ABI and then improve in to a more optimized version. Also it is now less likely to need changes in the future. This is not breaking any upstream user of the sync framework, as no driver wired support for it, so

[PATCH v12 0/2] staging/android: Sync ABI rework

From: Gustavo Padovan Hi, Here we clean up the Sync ABI and then improve in to a more optimized version. Also it is now less likely to need changes in the future. This is not breaking any upstream user of the sync framework, as no driver wired support for it, so far Android is the only user. A

[PATCH v12 2/2] staging/android: refactor SYNC IOCTLs

From: Gustavo Padovan Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid future API breaks and optimize buffer allocation. Now num_fences can be filled by the caller to inform how many fences it wants to retrieve from the kernel. If the

[PATCH v12 2/2] staging/android: refactor SYNC IOCTLs

From: Gustavo Padovan Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid future API breaks and optimize buffer allocation. Now num_fences can be filled by the caller to inform how many fences it wants to retrieve from the kernel. If the num_fences passed is greater than

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