Re: [PATCH V3 0/4] Define coherent device memory node

On Wed 22-02-17 09:59:15, Jerome Glisse wrote: > On Wed, Feb 22, 2017 at 10:29:21AM +0100, Michal Hocko wrote: > > On Tue 21-02-17 18:39:17, Anshuman Khandual wrote: > > > On 02/17/2017 07:02 PM, Mel Gorman wrote: > > [...] > > > [...] > > > These are the reasons which prohibit the use of HMM

Re: v4.10: kernel stack frame pointer .. has bad value (null)

On Tue, Feb 21, 2017 at 03:15:36PM -0800, H. Peter Anvin wrote: > On 02/21/17 15:12, Josh Poimboeuf wrote: > >> > >> commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb > >> Author: Josh Poimboeuf > >> Date: Thu Oct 27 08:10:58 2016 -0500 > >> > >> x86/unwind: Ensure stack grows down > >> > >>

Re: [PATCH v3 1/3] binding: irqchip: mtk-cirq: Add binding document

On Tue, Feb 14, 2017 at 10:55:59AM +0800, Youlin Pei wrote: > This commit adds the device tree binding document for > the mediatek cirq. > > Signed-off-by: Youlin Pei > --- > .../interrupt-controller/mediatek,cirq.txt | 35 > > 1 file changed, 35 insertions(+) >

Re: [PATCH V3 0/4] Define coherent device memory node

On Wed 22-02-17 09:59:15, Jerome Glisse wrote: > On Wed, Feb 22, 2017 at 10:29:21AM +0100, Michal Hocko wrote: > > On Tue 21-02-17 18:39:17, Anshuman Khandual wrote: > > > On 02/17/2017 07:02 PM, Mel Gorman wrote: > > [...] > > > [...] > > > These are the reasons which prohibit the use of HMM

Re: [PATCH 1/4] Documentation: devicetree: Add vendor prefix for Zidoo

On Tue, Feb 14, 2017 at 04:34:36AM +0100, Andreas Färber wrote: > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring

Re: [PATCH 1/4] Documentation: devicetree: Add vendor prefix for Zidoo

On Tue, Feb 14, 2017 at 04:34:36AM +0100, Andreas Färber wrote: > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring

Re: [PATCH v7 8/8] perf tool: add cgroup identifier entry in perf report

On Tue, Feb 21, 2017 at 07:33:13PM +0530, Hari Bathini wrote: > This patch introduces a cgroup identifier entry field in perf report to > identify or distinguish data of different cgroups. It uses the device > number and inode number of cgroup namespace, included in perf data with > the new

Re: [PATCH v2 0/8] ARM64: Initial Marvell IAP140 enablement

Am 22.02.2017 um 17:43 schrieb Andreas Färber: > Hi Rob, > > Am 22.02.2017 um 14:34 schrieb Rob Herring: >> On Tue, Feb 21, 2017 at 8:29 PM, Andreas Färber wrote: >>> One limitation is currently the lack of an IAP140 clk driver. Patch 4/4 >>> works >>> around that for UART0

Re: [PATCH v7 8/8] perf tool: add cgroup identifier entry in perf report

On Tue, Feb 21, 2017 at 07:33:13PM +0530, Hari Bathini wrote: > This patch introduces a cgroup identifier entry field in perf report to > identify or distinguish data of different cgroups. It uses the device > number and inode number of cgroup namespace, included in perf data with > the new

Re: [PATCH v2 0/8] ARM64: Initial Marvell IAP140 enablement

Am 22.02.2017 um 17:43 schrieb Andreas Färber: > Hi Rob, > > Am 22.02.2017 um 14:34 schrieb Rob Herring: >> On Tue, Feb 21, 2017 at 8:29 PM, Andreas Färber wrote: >>> One limitation is currently the lack of an IAP140 clk driver. Patch 4/4 >>> works >>> around that for UART0 with a fixed-clock.

Re: [PATCH v5 3/3] MIPS: ath79: Fix the USB PHY reset names

On Mon, Feb 13, 2017 at 11:25:46PM +0100, Alban wrote: > From: Alban Bedel > > The binding for the USB PHY went thru before the driver. However the > new version of the driver now use the PHY core support for reset, and > this expect the reset to be named "phy". So remove the

Re: [PATCH v5 3/3] MIPS: ath79: Fix the USB PHY reset names

On Mon, Feb 13, 2017 at 11:25:46PM +0100, Alban wrote: > From: Alban Bedel > > The binding for the USB PHY went thru before the driver. However the > new version of the driver now use the PHY core support for reset, and > this expect the reset to be named "phy". So remove the "usb-" prefix >

Re: [RFC 7/8] fpga-region: add sysfs interface

On Tue, Feb 21, 2017 at 10:05:42PM -0800, Moritz Fischer wrote: > That being said older drivers / fpga-mgr will not deal with newer features. > TLV / KV or whatever doesn't change this fact, or am I missing something? Often a scheme will have an OPTIONAL and REQUIRED flag for each value. If a

Re: [PATCH 4/4] fs, afs: convert afs_volume.usage from atomic_t to refcount_t

Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > >

Re: [PATCH 4/4] fs, afs: convert afs_volume.usage from atomic_t to refcount_t

Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova >

Re: [RFC 7/8] fpga-region: add sysfs interface

On Tue, Feb 21, 2017 at 10:05:42PM -0800, Moritz Fischer wrote: > That being said older drivers / fpga-mgr will not deal with newer features. > TLV / KV or whatever doesn't change this fact, or am I missing something? Often a scheme will have an OPTIONAL and REQUIRED flag for each value. If a

Re: [RFC 7/8] fpga-region: add sysfs interface

On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull wrote: > On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer > wrote: > > Hi Moritz, > >> Hi all, >> >> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe >> wrote: >>>

Re: [RFC 7/8] fpga-region: add sysfs interface

On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull wrote: > On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer > wrote: > > Hi Moritz, > >> Hi all, >> >> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe >> wrote: >>> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote: >>> fdt does this

Re: [RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption

On 2/20/2017 12:38 PM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote: Adding general kernel support for memory encryption includes: - Modify and create some page table macros to include the Secure Memory Encryption (SME) memory encryption mask - Modify

Re: [RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption

On 2/20/2017 12:38 PM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote: Adding general kernel support for memory encryption includes: - Modify and create some page table macros to include the Secure Memory Encryption (SME) memory encryption mask - Modify

Re: [PATCH v2 0/8] ARM64: Initial Marvell IAP140 enablement

Hi Rob, Am 22.02.2017 um 14:34 schrieb Rob Herring: > On Tue, Feb 21, 2017 at 8:29 PM, Andreas Färber wrote: >> One limitation is currently the lack of an IAP140 clk driver. Patch 4/4 works >> around that for UART0 with a fixed-clock. > > The PXA1928 clock driver should be

Re: [PATCH v2 0/8] ARM64: Initial Marvell IAP140 enablement

Hi Rob, Am 22.02.2017 um 14:34 schrieb Rob Herring: > On Tue, Feb 21, 2017 at 8:29 PM, Andreas Färber wrote: >> One limitation is currently the lack of an IAP140 clk driver. Patch 4/4 works >> around that for UART0 with a fixed-clock. > > The PXA1928 clock driver should be close to what you

Re: [RFC v2 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 21, 2017 at 05:23:26PM -0500, James Bottomley wrote: > On Tue, 2017-02-21 at 11:06 -0500, Vivek Goyal wrote: > > On Mon, Feb 20, 2017 at 04:47:05PM -0800, James Bottomley wrote: > > > > [..] > > > +static struct dentry *shiftfs_lookup(struct inode *dir, struct > > > dentry *dentry, >

Re: [RFC v2 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 21, 2017 at 05:23:26PM -0500, James Bottomley wrote: > On Tue, 2017-02-21 at 11:06 -0500, Vivek Goyal wrote: > > On Mon, Feb 20, 2017 at 04:47:05PM -0800, James Bottomley wrote: > > > > [..] > > > +static struct dentry *shiftfs_lookup(struct inode *dir, struct > > > dentry *dentry, >

Re: [PATCH 4/4] perf annotate: Introduce source_code to collect actual code

On 02/22/2017 08:27 PM, Namhyung Kim wrote: On Wed, Feb 22, 2017 at 7:08 PM, Taeung Song wrote: The output of perf-annotate has a problem. It is so confusing that the output is mixed with both source code and assembly code. IMHO, we need readable annotate view based

Re: [PATCH 4/4] perf annotate: Introduce source_code to collect actual code

On 02/22/2017 08:27 PM, Namhyung Kim wrote: On Wed, Feb 22, 2017 at 7:08 PM, Taeung Song wrote: The output of perf-annotate has a problem. It is so confusing that the output is mixed with both source code and assembly code. IMHO, we need readable annotate view based on source code, not mixed

Re: [PATCH 1/2] power: supply: ltc2941-battery-gauge: Add OF device ID table

-ltc2941-battery-gauge-Add-OF-device-ID-table/20170222-223315 base: git://git.infradead.org/battery-2.6.git master config: x86_64-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH

Re: [PATCH 1/2] power: supply: ltc2941-battery-gauge: Add OF device ID table

-ltc2941-battery-gauge-Add-OF-device-ID-table/20170222-223315 base: git://git.infradead.org/battery-2.6.git master config: x86_64-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH

Re: [PATCH 1/7] clk: tegra: fix pll_a1 iddq register, add pll_a1

Reviewed-by: Mikko Perttunen On 02/22/2017 05:13 PM, Peter De Schrijver wrote: pll_a1 was using CLK_RST_CONTROLLER_PLLA1_MISC_0 for IDDQ control rather than the correct register CLK_RST_CONTROLLER_PLLA1_MISC_1. Also add pll_a1 to the set of clocks defined for Tegra210.

Re: [PATCH 1/7] clk: tegra: fix pll_a1 iddq register, add pll_a1

Reviewed-by: Mikko Perttunen On 02/22/2017 05:13 PM, Peter De Schrijver wrote: pll_a1 was using CLK_RST_CONTROLLER_PLLA1_MISC_0 for IDDQ control rather than the correct register CLK_RST_CONTROLLER_PLLA1_MISC_1. Also add pll_a1 to the set of clocks defined for Tegra210. Signed-off-by: Peter De

[GIT PULL] arm64: updates for 4.11

Hello Linus, Please pull the following arm64 updates for 4.11. The summary is in the tag below. The diffstat strays outside of arch/arm64 in a few places: - The core changes required for DEBUG_VIRTUAL (Acked, also merged by rmk) - Qualcomm SMCCC quirk (Olof suggested I take this) -

[GIT PULL] arm64: updates for 4.11

Hello Linus, Please pull the following arm64 updates for 4.11. The summary is in the tag below. The diffstat strays outside of arch/arm64 in a few places: - The core changes required for DEBUG_VIRTUAL (Acked, also merged by rmk) - Qualcomm SMCCC quirk (Olof suggested I take this) -

Re: [RFC 7/8] fpga-region: add sysfs interface

On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer wrote: Hi Moritz, > Hi all, > > On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe > wrote: >> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote: >> >>> fdt does this out of

Re: [RFC 7/8] fpga-region: add sysfs interface

On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer wrote: Hi Moritz, > Hi all, > > On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe > wrote: >> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote: >> >>> fdt does this out of the box, too. So far I've seen nothing fdt >>> couldn't do

Re: [PATCH 3/4] fs, afs: convert afs_server.usage from atomic_t to refcount_t

Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. Although I

Re: [PATCH 2/4] perf annotate: Align filename:linenr and more correct summary

On 02/22/2017 08:22 PM, Namhyung Kim wrote: On Wed, Feb 22, 2017 at 7:08 PM, Taeung Song wrote: In the stdio interface, currently 'filename:linenr' infos are confusedly printed in the intervals of assembly code. So fix it. The cause was a 0.5% filter of if

Re: [PATCH 3/4] fs, afs: convert afs_server.usage from atomic_t to refcount_t

Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. Although I don't see an assertion for

Re: [PATCH 2/4] perf annotate: Align filename:linenr and more correct summary

On 02/22/2017 08:22 PM, Namhyung Kim wrote: On Wed, Feb 22, 2017 at 7:08 PM, Taeung Song wrote: In the stdio interface, currently 'filename:linenr' infos are confusedly printed in the intervals of assembly code. So fix it. The cause was a 0.5% filter of if statement. After fixed,

Re: [PATCH 4/7] clk: tegra: remove non-existing pll_m_out1 clock

Missing commit message Cheers, Mikko. On 02/22/2017 05:13 PM, Peter De Schrijver wrote: Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-tegra210.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/clk/tegra/clk-tegra210.c

Re: [PATCH 4/7] clk: tegra: remove non-existing pll_m_out1 clock

Missing commit message Cheers, Mikko. On 02/22/2017 05:13 PM, Peter De Schrijver wrote: Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-tegra210.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c index

Re: [PATCH 1/2] Correct function definition for C++

On Wed, 2017-02-22 at 15:22 +0100, g...@kroah.com wrote: > On Wed, Feb 22, 2017 at 02:00:53PM +, Joakim Tjernlund wrote: > > On Wed, 2017-02-22 at 14:03 +0100, g...@kroah.com wrote: > > > On Wed, Feb 22, 2017 at 07:50:46AM +, Joakim Tjernlund wrote: > > > > On Wed, 2017-02-22 at 08:10

Re: [PATCH 1/2] Correct function definition for C++

On Wed, 2017-02-22 at 15:22 +0100, g...@kroah.com wrote: > On Wed, Feb 22, 2017 at 02:00:53PM +, Joakim Tjernlund wrote: > > On Wed, 2017-02-22 at 14:03 +0100, g...@kroah.com wrote: > > > On Wed, Feb 22, 2017 at 07:50:46AM +, Joakim Tjernlund wrote: > > > > On Wed, 2017-02-22 at 08:10

[PATCH 1/3] [media] soc-camera: ov5642: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 1/3] [media] soc-camera: ov5642: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

On 22/02/2017, Jason Vas Dias wrote: > RE: >>> 4.10 has new code which utilizes the TSC_ADJUST MSR. > > I just built an unpatched linux v4.10 with tglx's TSC improvements - > much else improved in this kernel (like iwlwifi) - thanks! > > I have attached an updated

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

On 22/02/2017, Jason Vas Dias wrote: > RE: >>> 4.10 has new code which utilizes the TSC_ADJUST MSR. > > I just built an unpatched linux v4.10 with tglx's TSC improvements - > much else improved in this kernel (like iwlwifi) - thanks! > > I have attached an updated version of the test program

Re: [PATCH 4/4] mm,hugetlb: compute page_size_log properly

On Wed 22-02-17 08:03:19, Davidlohr Bueso wrote: > On Mon, 20 Feb 2017, Michal Hocko wrote: > > > I am not sure I understand. > > $ git grep SHM_HUGE_ include/uapi/ > > $ > > > > So there doesn't seem to be any user visible constant. The man page > > mentiones is but I do not really see how is

Re: [PATCH 4/4] mm,hugetlb: compute page_size_log properly

On Wed 22-02-17 08:03:19, Davidlohr Bueso wrote: > On Mon, 20 Feb 2017, Michal Hocko wrote: > > > I am not sure I understand. > > $ git grep SHM_HUGE_ include/uapi/ > > $ > > > > So there doesn't seem to be any user visible constant. The man page > > mentiones is but I do not really see how is

Re: [PATCH 2/4] fs, afs: convert afs_vlocation.usage from atomic_t to refcount_t

Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. Please hold

Re: [PATCH 2/4] fs, afs: convert afs_vlocation.usage from atomic_t to refcount_t

Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. Please hold this patch also. An

[PATCH 2/3] [media] tc358743: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 2/3] [media] tc358743: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 3/3] [media] si4713: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 3/3] [media] si4713: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

Re: [PATCH 1/4] fs, afs: convert afs_cell.usage from atomic_t to refcount_t

Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. This causes

Re: [PATCH 1/4] fs, afs: convert afs_cell.usage from atomic_t to refcount_t

Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. This causes an assertion failure because

[PATCH 4/4] input:touchscreen:ad7879: Update MODULE_AUTHOR email address

From: Michael Hennerich Signed-off-by: Michael Hennerich --- drivers/input/touchscreen/ad7879-i2c.c | 2 +- drivers/input/touchscreen/ad7879-spi.c | 2 +- drivers/input/touchscreen/ad7879.c | 2 +- 3 files changed, 3

[PATCH 1/4] input:touchscreen:ad7879-spi.c: Fix regmap flag_masks

From: Michael Hennerich Mask only applied to the top byte of the register Signed-off-by: Michael Hennerich --- drivers/input/touchscreen/ad7879-spi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 4/4] input:touchscreen:ad7879: Update MODULE_AUTHOR email address

From: Michael Hennerich Signed-off-by: Michael Hennerich --- drivers/input/touchscreen/ad7879-i2c.c | 2 +- drivers/input/touchscreen/ad7879-spi.c | 2 +- drivers/input/touchscreen/ad7879.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 1/4] input:touchscreen:ad7879-spi.c: Fix regmap flag_masks

From: Michael Hennerich Mask only applied to the top byte of the register Signed-off-by: Michael Hennerich --- drivers/input/touchscreen/ad7879-spi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/touchscreen/ad7879-spi.c

[PATCH 0/4] Input: ad7879 RFC/RFT follow-up

From: Michael Hennerich Hi Dmitry, I reviewed and tested your patch series (posted February 18th). [RFC/RFT PATCH 1/3] Input: ad7879 - convert to use regmap [RFC/RFT PATCH 2/3] Input: ad7879 - use more devm interfaces [RFC/RFT PATCH 3/3] Input: ad7879 - allow

[PATCH 0/4] Input: ad7879 RFC/RFT follow-up

From: Michael Hennerich Hi Dmitry, I reviewed and tested your patch series (posted February 18th). [RFC/RFT PATCH 1/3] Input: ad7879 - convert to use regmap [RFC/RFT PATCH 2/3] Input: ad7879 - use more devm interfaces [RFC/RFT PATCH 3/3] Input: ad7879 - allow exporting AUX/VBAT/GPIO pin via

[PATCH 3/4] Documentation: Add SPI example

From: Michael Hennerich Signed-off-by: Michael Hennerich --- .../devicetree/bindings/input/touchscreen/ad7879.txt | 18 ++ 1 file changed, 18 insertions(+) diff --git

[PATCH 3/4] Documentation: Add SPI example

From: Michael Hennerich Signed-off-by: Michael Hennerich --- .../devicetree/bindings/input/touchscreen/ad7879.txt | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt

[PATCH 2/4] input:touchscreen:ad7879-spi.c: Remove bits_per_word = 16 enforcement

From: Michael Hennerich Using regmap this is no longer required. Signed-off-by: Michael Hennerich --- drivers/input/touchscreen/ad7879-spi.c | 7 --- 1 file changed, 7 deletions(-) diff --git

[PATCH 2/4] input:touchscreen:ad7879-spi.c: Remove bits_per_word = 16 enforcement

From: Michael Hennerich Using regmap this is no longer required. Signed-off-by: Michael Hennerich --- drivers/input/touchscreen/ad7879-spi.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/input/touchscreen/ad7879-spi.c b/drivers/input/touchscreen/ad7879-spi.c index

RE: [PATCH 1/9] tools: convert cgroup_sel.refcnt from atomic_t to refcount_t

> Em Wed, Feb 22, 2017 at 02:29:18PM +, Reshetova, Elena escreveu: > > > Em Tue, Feb 21, 2017 at 05:34:55PM +0200, Elena Reshetova escreveu: > > > > refcount_t type and corresponding API should be > > > > used instead of atomic_t when the variable is used as > > > > a reference counter. This

RE: [PATCH 1/9] tools: convert cgroup_sel.refcnt from atomic_t to refcount_t

> Em Wed, Feb 22, 2017 at 02:29:18PM +, Reshetova, Elena escreveu: > > > Em Tue, Feb 21, 2017 at 05:34:55PM +0200, Elena Reshetova escreveu: > > > > refcount_t type and corresponding API should be > > > > used instead of atomic_t when the variable is used as > > > > a reference counter. This

Re: [PATCH 1/4] perf annotate: Remove needless regular expression for filename:linenr

Hi Namhyung, On 02/22/2017 07:47 PM, Namhyung Kim wrote: Hi Taeung, On Wed, Feb 22, 2017 at 7:08 PM, Taeung Song wrote: The commit e592488c01d5 ("perf annotate: Support source line numbers in annotate") support source line numbers in annotate. But we can get

Re: [PATCH 1/4] perf annotate: Remove needless regular expression for filename:linenr

Hi Namhyung, On 02/22/2017 07:47 PM, Namhyung Kim wrote: Hi Taeung, On Wed, Feb 22, 2017 at 7:08 PM, Taeung Song wrote: The commit e592488c01d5 ("perf annotate: Support source line numbers in annotate") support source line numbers in annotate. But we can get filename:line number by

Re: [PATCH V2 1/3] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

On 21 February 2017 at 20:46, Chunyan Zhang wrote: > Hello Mathieu, > > On 二, 2月 21, 2017 at 09:27:44上午 -0700, Mathieu Poirier wrote: >> On Tue, Feb 21, 2017 at 02:55:02PM +0800, Chunyan Zhang wrote: >> > From: Orson Zhai >> >> Hello

Re: [PATCH V2 1/3] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

On 21 February 2017 at 20:46, Chunyan Zhang wrote: > Hello Mathieu, > > On 二, 2月 21, 2017 at 09:27:44上午 -0700, Mathieu Poirier wrote: >> On Tue, Feb 21, 2017 at 02:55:02PM +0800, Chunyan Zhang wrote: >> > From: Orson Zhai >> >> Hello Chunyan, >> >> > >> > SC9860G is a 8 cores of A53 SoC with 4G

Re: [PATCH v2 3/3] mfd: wm831x: Add device tree binding document

On Wed, Feb 22, 2017 at 09:15:02AM -0600, Rob Herring wrote: > On Mon, Feb 13, 2017 at 11:15:14AM +, Charles Keepax wrote: > > This is just a very simple initial binding, supporting only registering > > the chip and the GPIOs. More features will be added as support for > > device tree in the

Re: [PATCH v2 3/3] mfd: wm831x: Add device tree binding document

On Wed, Feb 22, 2017 at 09:15:02AM -0600, Rob Herring wrote: > On Mon, Feb 13, 2017 at 11:15:14AM +, Charles Keepax wrote: > > This is just a very simple initial binding, supporting only registering > > the chip and the GPIOs. More features will be added as support for > > device tree in the

Re: [PATCH v8 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family

On Wed, Feb 22, 2017 at 05:18:52PM +0800, Baoyou Xie wrote: > This patch adds i2c controller driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie > Reviewed-by: Shawn Guo > Reviewed-by: Andy Shevchenko >

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

RE: >> 4.10 has new code which utilizes the TSC_ADJUST MSR. I just built an unpatched linux v4.10 with tglx's TSC improvements - much else improved in this kernel (like iwlwifi) - thanks! I have attached an updated version of the test program which doesn't print the bogus "Nominal TSC

Re: [PATCH v8 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family

On Wed, Feb 22, 2017 at 05:18:52PM +0800, Baoyou Xie wrote: > This patch adds i2c controller driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie > Reviewed-by: Shawn Guo > Reviewed-by: Andy Shevchenko > Reviewed-by: Jun Nie Please provide a changelog what you changed since the last

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

RE: >> 4.10 has new code which utilizes the TSC_ADJUST MSR. I just built an unpatched linux v4.10 with tglx's TSC improvements - much else improved in this kernel (like iwlwifi) - thanks! I have attached an updated version of the test program which doesn't print the bogus "Nominal TSC

[PATCH 2/2] mm/cgroup: delay soft limit data allocation

Until a soft limit is set to a cgroup, the soft limit data are useless so delay this allocation when a limit is set. Suggested-by: Michal Hocko Signed-off-by: Laurent Dufour --- mm/memcontrol.c | 52

[PATCH 2/2] mm/cgroup: delay soft limit data allocation

Until a soft limit is set to a cgroup, the soft limit data are useless so delay this allocation when a limit is set. Suggested-by: Michal Hocko Signed-off-by: Laurent Dufour --- mm/memcontrol.c | 52 +++- 1 file changed, 39 insertions(+), 13

Re: [PATCH v2] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

On Mon, Feb 13, 2017 at 2:13 AM, Dmitry Torokhov wrote: > Given the intent behind gpiod_get_optional() and friends it does not make > sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to > work just fine without gpio so let's behave as if gpio

Re: [PATCH v2] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

On Mon, Feb 13, 2017 at 2:13 AM, Dmitry Torokhov wrote: > Given the intent behind gpiod_get_optional() and friends it does not make > sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to > work just fine without gpio so let's behave as if gpio was not found. > Otherwise we

Re: [PATCH v2 2/3] gpio: wm831x: Add basic device tree support

On Wed, Feb 22, 2017 at 03:35:26PM +0100, Linus Walleij wrote: > On Mon, Feb 13, 2017 at 12:15 PM, Charles Keepax > wrote: > > > Now the wm831x-core has basic DT support we can update this driver to > > allow use of the GPIOs within a device tree system. > >

Re: [PATCH v2 2/3] gpio: wm831x: Add basic device tree support

On Wed, Feb 22, 2017 at 03:35:26PM +0100, Linus Walleij wrote: > On Mon, Feb 13, 2017 at 12:15 PM, Charles Keepax > wrote: > > > Now the wm831x-core has basic DT support we can update this driver to > > allow use of the GPIOs within a device tree system. > > > > Signed-off-by: Charles Keepax >

[ANNOUNCE] util-linux v2.29.2

The util-linux release v2.29.2 is available at http://ftp.kernel.org/pub/linux/utils/util-linux/v2.29 Feedback and bug reports, as always, are welcomed. Karel util-linux 2.29.2 Release Notes === This release fixes su(1) security issue CVE-2017-2616: It is

[ANNOUNCE] util-linux v2.29.2

The util-linux release v2.29.2 is available at http://ftp.kernel.org/pub/linux/utils/util-linux/v2.29 Feedback and bug reports, as always, are welcomed. Karel util-linux 2.29.2 Release Notes === This release fixes su(1) security issue CVE-2017-2616: It is

Re: [PATCH 4/4] mm,hugetlb: compute page_size_log properly

On Mon, 20 Feb 2017, Michal Hocko wrote: I am not sure I understand. $ git grep SHM_HUGE_ include/uapi/ $ So there doesn't seem to be any user visible constant. The man page mentiones is but I do not really see how is the userspace supposed to use it. Yeah, userspace is not supposed to use

Re: [PATCH 4/4] mm,hugetlb: compute page_size_log properly

On Mon, 20 Feb 2017, Michal Hocko wrote: I am not sure I understand. $ git grep SHM_HUGE_ include/uapi/ $ So there doesn't seem to be any user visible constant. The man page mentiones is but I do not really see how is the userspace supposed to use it. Yeah, userspace is not supposed to use

Re: [BUGFIX PATCH V2 0/3] kprobes/arm: Improve kprobes implementation on arm

On Sat, 2017-02-18 at 06:43 +0900, Masami Hiramatsu wrote: > On Fri, 17 Feb 2017 11:01:10 + > "Jon Medhurst (Tixy)" wrote: [...] > > Meantime > > I'll investigate the kprobes test failures I see (which actually looks > > like cache/TLB issues and not test code problems after

Re: [BUGFIX PATCH V2 0/3] kprobes/arm: Improve kprobes implementation on arm

On Sat, 2017-02-18 at 06:43 +0900, Masami Hiramatsu wrote: > On Fri, 17 Feb 2017 11:01:10 + > "Jon Medhurst (Tixy)" wrote: [...] > > Meantime > > I'll investigate the kprobes test failures I see (which actually looks > > like cache/TLB issues and not test code problems after all). > > OK,

[PATCH 1/2] mm/cgroup: avoid panic when init with low memory

The system may panic when initialisation is done when almost all the memory is assigned to the huge pages using the kernel command line parameter hugepage=. Panic may occur like this: [0.082289] Unable to handle kernel paging request for data at address 0x [0.082338] Faulting

[PATCH 1/2] mm/cgroup: avoid panic when init with low memory

The system may panic when initialisation is done when almost all the memory is assigned to the huge pages using the kernel command line parameter hugepage=. Panic may occur like this: [0.082289] Unable to handle kernel paging request for data at address 0x [0.082338] Faulting

Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

On 22/02/17 14:50, Rafael J. Wysocki wrote: > On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla wrote: [...] >> >> OK, I thought I had told this before. What do you mean by PSCI system >> suspend can't wakeup from the configured wakeup source. You just said >> above that you

Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

On 22/02/17 14:50, Rafael J. Wysocki wrote: > On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla wrote: [...] >> >> OK, I thought I had told this before. What do you mean by PSCI system >> suspend can't wakeup from the configured wakeup source. You just said >> above that you can wake up from the

[PATCH 0/2] mm/cgroup soft limit data allocation

The first patch of this series is fixing a panic occurring when soft limit data allocation is using soft limit data. The second patch, as suggested by Michal Hocko, is pushing forward by delaying the soft limit data allocation when a soft limit is set. Laurent Dufour (2): mm/cgroup: avoid

[PATCH 0/2] mm/cgroup soft limit data allocation

The first patch of this series is fixing a panic occurring when soft limit data allocation is using soft limit data. The second patch, as suggested by Michal Hocko, is pushing forward by delaying the soft limit data allocation when a soft limit is set. Laurent Dufour (2): mm/cgroup: avoid

Re: [RESEND PATCH v7 0/7] Rockchip dw-mipi-dsi driver

On Wed, Feb 22, 2017 at 8:43 AM, John Keeping wrote: > On Tue, 21 Feb 2017 10:39:18 -0500, Sean Paul wrote: > >> On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote: >> > Hi all >> > >> > [Resend this v7 version series, since there are 5 mails have gone missing, >> >

Re: [RESEND PATCH v7 0/7] Rockchip dw-mipi-dsi driver

On Wed, Feb 22, 2017 at 8:43 AM, John Keeping wrote: > On Tue, 21 Feb 2017 10:39:18 -0500, Sean Paul wrote: > >> On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote: >> > Hi all >> > >> > [Resend this v7 version series, since there are 5 mails have gone missing, >> > last >> > week] >> >

Re: [PATCH v2 0/7] KVM TSS cleanups and speedups

On 22/02/2017 16:17, Andy Lutomirski wrote: >> I pushed and tagged before seeing this v2. :( The differences seem to >> be x86-only, so I suppose Ingo can handle them if you resubmit. >> > I renamed the helpers to make it less likely that someone would repeat > my little buglet. I can submit a

Re: [PATCH v2 0/7] KVM TSS cleanups and speedups

On 22/02/2017 16:17, Andy Lutomirski wrote: >> I pushed and tagged before seeing this v2. :( The differences seem to >> be x86-only, so I suppose Ingo can handle them if you resubmit. >> > I renamed the helpers to make it less likely that someone would repeat > my little buglet. I can submit a

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