Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

On Mon, May 16, 2016 at 09:41:45AM -0700, Dmitry Torokhov wrote: > On Mon, May 16, 2016 at 11:46:51PM +0800, jeffrey.lin wrote: > > Hi Dmitry: > > I've finished issues under the format you suggested as below. > > > > >#define RM_RESET_MSG_ADDR 0x4004 > > >#define RM_FASTBOOT_MSG_ADDR

[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes

This patchset introduces changeset helpers which makes working with changeset much easier and less error prone. The first patch exports an internal method which is used for the third patch which contains the bulk of the changes. The second introduces a of_changeset_node_move method that helps

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

On Mon, May 16, 2016 at 09:41:45AM -0700, Dmitry Torokhov wrote: > On Mon, May 16, 2016 at 11:46:51PM +0800, jeffrey.lin wrote: > > Hi Dmitry: > > I've finished issues under the format you suggested as below. > > > > >#define RM_RESET_MSG_ADDR 0x4004 > > >#define RM_FASTBOOT_MSG_ADDR

[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes

This patchset introduces changeset helpers which makes working with changeset much easier and less error prone. The first patch exports an internal method which is used for the third patch which contains the bulk of the changes. The second introduces a of_changeset_node_move method that helps

Re: [PATCH] regulator: axp20x: Add support for the (external) drivebus regulator

On Sat, May 14, 2016 at 07:55:45PM +0200, Hans de Goede wrote: > The axp20x pmics have 2 power inputs, one called ACIN which is intended > for to be supplied via a powerbarrel on the board and one called VBUS > which is intended to be supplied via an otg connector. > > In the VBUS case the pmic

Re: [PATCH] regulator: axp20x: Add support for the (external) drivebus regulator

On Sat, May 14, 2016 at 07:55:45PM +0200, Hans de Goede wrote: > The axp20x pmics have 2 power inputs, one called ACIN which is intended > for to be supplied via a powerbarrel on the board and one called VBUS > which is intended to be supplied via an otg connector. > > In the VBUS case the pmic

[PATCH v2 3/5] of: changeset: Add of_changeset_node_move method

Adds a changeset helper for moving a subtree to a different place in the running tree. This is useful in advances cases of dynamic device tree construction. Signed-off-by: Pantelis Antoniou --- drivers/of/dynamic.c | 66

[PATCH v2 3/5] of: changeset: Add of_changeset_node_move method

Adds a changeset helper for moving a subtree to a different place in the running tree. This is useful in advances cases of dynamic device tree construction. Signed-off-by: Pantelis Antoniou --- drivers/of/dynamic.c | 66 include/linux/of.h

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

On Mon, May 16, 2016 at 11:46:51PM +0800, jeffrey.lin wrote: > Hi Dmitry: > I've finished issues under the format you suggested as below. > > >#define RM_RESET_MSG_ADDR0x4004 > >#define RM_FASTBOOT_MSG_ADDR 0x5620 > > >#define RM_MAX_READ_SIZE 63 > change maximum read size to 56

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

On Mon, May 16, 2016 at 11:46:51PM +0800, jeffrey.lin wrote: > Hi Dmitry: > I've finished issues under the format you suggested as below. > > >#define RM_RESET_MSG_ADDR0x4004 > >#define RM_FASTBOOT_MSG_ADDR 0x5620 > > >#define RM_MAX_READ_SIZE 63 > change maximum read size to 56

[PATCH v2 4/5] of: unittest: changeset helpers

Add a unitest specific for the new changeset helpers. Signed-off-by: Pantelis Antoniou --- drivers/of/unittest.c | 54 +++ 1 file changed, 54 insertions(+) diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c

[PATCH v2 1/5] of: dynamic: Add __of_node_dupv()

Add an __of_node_dupv() private method and make __of_node_dup() use it. This is required for the subsequent changeset accessors which will make use of it. Signed-off-by: Pantelis Antoniou --- drivers/of/dynamic.c | 29 +++-- 1 file

[PATCH v2 2/5] of: changesets: Introduce changeset helper methods

Changesets are very powerful, but the lack of a helper API makes using them cumbersome. Introduce a simple copy based API that makes things considerably easier. To wit, adding a property using the raw API. struct property *prop; prop = kzalloc(sizeof(*prop)), GFP_KERNEL);

[PATCH v2 4/5] of: unittest: changeset helpers

Add a unitest specific for the new changeset helpers. Signed-off-by: Pantelis Antoniou --- drivers/of/unittest.c | 54 +++ 1 file changed, 54 insertions(+) diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c index e986e6e..ff6939b 100644

[PATCH v2 1/5] of: dynamic: Add __of_node_dupv()

Add an __of_node_dupv() private method and make __of_node_dup() use it. This is required for the subsequent changeset accessors which will make use of it. Signed-off-by: Pantelis Antoniou --- drivers/of/dynamic.c | 29 +++-- 1 file changed, 23 insertions(+), 6

[PATCH v2 2/5] of: changesets: Introduce changeset helper methods

Changesets are very powerful, but the lack of a helper API makes using them cumbersome. Introduce a simple copy based API that makes things considerably easier. To wit, adding a property using the raw API. struct property *prop; prop = kzalloc(sizeof(*prop)), GFP_KERNEL);

Re: [PATCHv8 resend 2/2] selftest/x86: add mremap vdso test

On 05/16/2016 04:54 PM, Ingo Molnar wrote: * Dmitry Safonov wrote: Should print on success: [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773f000 [NOTE] Moving vDSO: [f773f000, f774] -> [a00, a001000] [OK] Or segfault if landing was

Re: [PATCHv8 resend 2/2] selftest/x86: add mremap vdso test

On 05/16/2016 04:54 PM, Ingo Molnar wrote: * Dmitry Safonov wrote: Should print on success: [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773f000 [NOTE] Moving vDSO: [f773f000, f774] -> [a00, a001000] [OK] Or segfault if landing was bad (before patches):

Re: [RFC PATCH] perf session: fixing uninitialised cpumode

On 16 May 2016 at 00:01, Jiri Olsa wrote: > On Fri, May 13, 2016 at 05:36:16PM -0600, Mathieu Poirier wrote: >> The following patch[1] adds a new "cpumode" to the perf_sample >> structure that gets initialised as events are read from the data >> event file. >> >> With the advent

Re: [RFC PATCH] perf session: fixing uninitialised cpumode

On 16 May 2016 at 00:01, Jiri Olsa wrote: > On Fri, May 13, 2016 at 05:36:16PM -0600, Mathieu Poirier wrote: >> The following patch[1] adds a new "cpumode" to the perf_sample >> structure that gets initialised as events are read from the data >> event file. >> >> With the advent of HW tracers and

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

Hi Michal, On 05/16/2016 06:05 PM, Michal Nazarewicz wrote: > So I’ve been looking at AIO handling in f_fs and either I’m stupid or > the code is broken. Here’s part of ffs_user_copy_worker: > > int ret = io_data->req->status ? io_data->req->status : >

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

Hi Michal, On 05/16/2016 06:05 PM, Michal Nazarewicz wrote: > So I’ve been looking at AIO handling in f_fs and either I’m stupid or > the code is broken. Here’s part of ffs_user_copy_worker: > > int ret = io_data->req->status ? io_data->req->status : >

Re: [rcu_sched stall] regression/miss-config ?

On 5/16/2016 5:03 AM, Paul E. McKenney wrote: On Sun, May 15, 2016 at 09:35:40PM -0700, santosh.shilim...@oracle.com wrote: On 5/15/16 2:18 PM, Santosh Shilimkar wrote: Hi Paul, I was asking Sasha about [1] since other folks in Oracle also stumbled upon similar RCU stalls with v4.1 kernel in

Re: [rcu_sched stall] regression/miss-config ?

On 5/16/2016 5:03 AM, Paul E. McKenney wrote: On Sun, May 15, 2016 at 09:35:40PM -0700, santosh.shilim...@oracle.com wrote: On 5/15/16 2:18 PM, Santosh Shilimkar wrote: Hi Paul, I was asking Sasha about [1] since other folks in Oracle also stumbled upon similar RCU stalls with v4.1 kernel in

Re: [PATCH] mtd: Adding of_mtd_info_get to get mtd_info from devicetree

Hi Boris, On Mon, May 16, 2016 at 1:05 AM, Boris Brezillon wrote: >> Here are a few questions (I'm assuming the netdev + MAC address case): >> - how would you link the net/PHY device to the MTD partition storing >> the MAC address Well in my case I

Re: [PATCH] mtd: Adding of_mtd_info_get to get mtd_info from devicetree

Hi Boris, On Mon, May 16, 2016 at 1:05 AM, Boris Brezillon wrote: >> Here are a few questions (I'm assuming the netdev + MAC address case): >> - how would you link the net/PHY device to the MTD partition storing >> the MAC address Well in my case I actually planned to use it with the OTP

[GIT PULL] perf changes for v4.7

Linus, Please pull the latest perf-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus # HEAD: 3f56e687a138481894a1088d5aa7d41951bdb020 perf/core: Disable the event on a truncated AUX record Bigger kernel side changes: - Add

[GIT PULL] perf changes for v4.7

Linus, Please pull the latest perf-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus # HEAD: 3f56e687a138481894a1088d5aa7d41951bdb020 perf/core: Disable the event on a truncated AUX record Bigger kernel side changes: - Add

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

On 05/16/2016 06:05 PM, Michal Nazarewicz wrote: > So I’ve been looking at AIO handling in f_fs and either I’m stupid or > the code is broken. The code was broken. Fixed in commit 332a5b446b791 ("usb: gadget: f_fs: Fix EFAULT generation for async read operations:).

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

On 05/16/2016 06:05 PM, Michal Nazarewicz wrote: > So I’ve been looking at AIO handling in f_fs and either I’m stupid or > the code is broken. The code was broken. Fixed in commit 332a5b446b791 ("usb: gadget: f_fs: Fix EFAULT generation for async read operations:).

Re: [PATCH v2] drm/amd/powerplay: use ARRAY_SIZE() to calculate array size.

On Fri, May 13, 2016 at 11:06:40PM +0530, Muhammad Falak R Wani wrote: > It is preferred to use ARRAY_SIZE() for size calculation, instead > using sizeof(array)/sizeof(*array). It makes the code more readable. > > Signed-off-by: Muhammad Falak R Wani Reviewed-by: Eric

Re: [PATCH v2] drm/amd/powerplay: use ARRAY_SIZE() to calculate array size.

On Fri, May 13, 2016 at 11:06:40PM +0530, Muhammad Falak R Wani wrote: > It is preferred to use ARRAY_SIZE() for size calculation, instead > using sizeof(array)/sizeof(*array). It makes the code more readable. > > Signed-off-by: Muhammad Falak R Wani Reviewed-by: Eric Engestrom Thanks, and

Re: [PATCH 2/2] Fix efi_call

On Thu, May 12, 2016 at 12:41:49PM +0100, Matt Fleming wrote: > On Wed, 11 May, at 02:55:45PM, Alex Thorlton wrote: > Nice. Your fix looks good, so I've put it in the urgent queue and > tagged it for stable. Great! Thanks, Matt. - Alex

Re: [PATCH 2/2] Fix efi_call

On Thu, May 12, 2016 at 12:41:49PM +0100, Matt Fleming wrote: > On Wed, 11 May, at 02:55:45PM, Alex Thorlton wrote: > Nice. Your fix looks good, so I've put it in the urgent queue and > tagged it for stable. Great! Thanks, Matt. - Alex

Re: [PATCH 2/2] Fix efi_call

On Thu, May 12, 2016 at 08:48:35AM +0200, Ingo Molnar wrote: > I suppose the SGI/UV code is the only one using 7 arguments or more? Might > make > sense to point that out in the changelog. First off, to everybody, sorry for the delayed responses. I've been AFK for a few days and forgot to set

Re: [PATCH 2/2] Fix efi_call

On Thu, May 12, 2016 at 08:48:35AM +0200, Ingo Molnar wrote: > I suppose the SGI/UV code is the only one using 7 arguments or more? Might > make > sense to point that out in the changelog. First off, to everybody, sorry for the delayed responses. I've been AFK for a few days and forgot to set

Re: [PATCHv8 resend 1/2] x86/vdso: add mremap hook to vm_special_mapping

On 05/16/2016 04:55 PM, Ingo Molnar wrote: Ok, this looks useful - please add this information to the changelog (with typos fixed). Thanks will add to v9.

Re: [PATCHv8 resend 1/2] x86/vdso: add mremap hook to vm_special_mapping

On 05/16/2016 04:55 PM, Ingo Molnar wrote: Ok, this looks useful - please add this information to the changelog (with typos fixed). Thanks will add to v9.

Re: [PATCH v3] ASoC: MAX9860: new driver

On Fri, May 13, 2016 at 09:25:33AM +0200, Peter Rosin wrote: > This is a driver for the MAX9860 Mono Audio Voice Codec. > > https://datasheets.maximintegrated.com/en/ds/MAX9860.pdf > > This driver does not support sidetone since the DVST register field is > backwards with the mute near the

Re: [PATCH v3] ASoC: MAX9860: new driver

On Fri, May 13, 2016 at 09:25:33AM +0200, Peter Rosin wrote: > This is a driver for the MAX9860 Mono Audio Voice Codec. > > https://datasheets.maximintegrated.com/en/ds/MAX9860.pdf > > This driver does not support sidetone since the DVST register field is > backwards with the mute near the

[PATCH] rtc: interface: ignore exprired timers one enqueing new timers

From: Colin Ian King This patch fixes a RTC wakealarm issue, namely, the event fires during hibernate and is not cleared from the list, causing hwclock to block. The current enqueuing does not trigger an alarm if any expired timers already exist on the timerqueue. This

[PATCH] rtc: interface: ignore exprired timers one enqueing new timers

From: Colin Ian King This patch fixes a RTC wakealarm issue, namely, the event fires during hibernate and is not cleared from the list, causing hwclock to block. The current enqueuing does not trigger an alarm if any expired timers already exist on the timerqueue. This can occur when a RTC wake

Re: [PATCH v9 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

On Fri, May 13, 2016 at 12:33:52PM +0530, Kedareswara rao Appana wrote: > Device-tree binding documentation for Xilinx zynqmp dma engine > used in Zynq UltraScale+ MPSoC. > > Signed-off-by: Punnaiah Choudary Kalluri > Signed-off-by: Kedareswara rao Appana

Re: [PATCH v9 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

On Fri, May 13, 2016 at 12:33:52PM +0530, Kedareswara rao Appana wrote: > Device-tree binding documentation for Xilinx zynqmp dma engine > used in Zynq UltraScale+ MPSoC. > > Signed-off-by: Punnaiah Choudary Kalluri > Signed-off-by: Kedareswara rao Appana > --- > Changs in v9: > - Removed

Re: [PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

On Sun, May 15, 2016 at 7:59 PM, ethan zhao wrote: > Alexander, > > On 2016/5/14 0:46, Alexander Duyck wrote: >> >> On Thu, May 12, 2016 at 10:56 PM, Ethan Zhao >> wrote: >>> >>> Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less

Re: [PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

On Sun, May 15, 2016 at 7:59 PM, ethan zhao wrote: > Alexander, > > On 2016/5/14 0:46, Alexander Duyck wrote: >> >> On Thu, May 12, 2016 at 10:56 PM, Ethan Zhao >> wrote: >>> >>> Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less >>> CPUs were assigned. especially when DCB is

Re: [PATCH 1/1] userfaultfd: don't pin the user memory in userfaultfd_file_create()

On 05/16, Andrea Arcangeli wrote: > > Reviewed-by: Andrea Arcangeli Thanks, > > +static inline bool userfaultfd_get_mm(struct userfaultfd_ctx *ctx) > > +{ > > + return atomic_inc_not_zero(>mm->mm_users); > > +} > > Nice cleanup, but wouldn't it be more generic to

Re: [PATCH 1/1] userfaultfd: don't pin the user memory in userfaultfd_file_create()

On 05/16, Andrea Arcangeli wrote: > > Reviewed-by: Andrea Arcangeli Thanks, > > +static inline bool userfaultfd_get_mm(struct userfaultfd_ctx *ctx) > > +{ > > + return atomic_inc_not_zero(>mm->mm_users); > > +} > > Nice cleanup, but wouldn't it be more generic to implement this as >

Re: [PATCH v2] drm/amd/powerplay: use ARRAY_SIZE() to calculate array size.

On Fri, May 13, 2016 at 1:36 PM, Muhammad Falak R Wani wrote: > It is preferred to use ARRAY_SIZE() for size calculation, instead > using sizeof(array)/sizeof(*array). It makes the code more readable. > > Signed-off-by: Muhammad Falak R Wani Applied.

[PATCH 1/3] Documentation: dtb: xgene: Add hwmon dts binding documentation

This patch adds the APM X-Gene hwmon device tree node documentation. Signed-off-by: Hoan Tran --- .../devicetree/bindings/hwmon/apm-xgene-hwmon.txt | 14 ++ 1 file changed, 14 insertions(+) create mode 100644

Re: [PATCH v2] drm/amd/powerplay: use ARRAY_SIZE() to calculate array size.

On Fri, May 13, 2016 at 1:36 PM, Muhammad Falak R Wani wrote: > It is preferred to use ARRAY_SIZE() for size calculation, instead > using sizeof(array)/sizeof(*array). It makes the code more readable. > > Signed-off-by: Muhammad Falak R Wani Applied. thanks! Alex > --- >

[PATCH 1/3] Documentation: dtb: xgene: Add hwmon dts binding documentation

This patch adds the APM X-Gene hwmon device tree node documentation. Signed-off-by: Hoan Tran --- .../devicetree/bindings/hwmon/apm-xgene-hwmon.txt | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt

[PATCH 3/3] arm64: dts: apm: Add X-Gene SoC hwmon to device tree

This patch adds DT node to enable hwmon driver for APM X-Gene SoC. Signed-off-by: Hoan Tran --- arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 5 + arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 + 2 files changed, 10 insertions(+) diff --git

[PATCH 3/3] arm64: dts: apm: Add X-Gene SoC hwmon to device tree

This patch adds DT node to enable hwmon driver for APM X-Gene SoC. Signed-off-by: Hoan Tran --- arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 5 + arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 + 2 files changed, 10 insertions(+) diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

[PATCH 2/3] hwmon: xgene: Adds hwmon driver

This patch adds hardware temperature and power reading support for APM X-Gene SoC's using the mailbox communication interface. Signed-off-by: Hoan Tran --- Documentation/hwmon/xgene-hwmon | 32 ++ drivers/hwmon/Kconfig | 7 + drivers/hwmon/Makefile | 1 +

[PATCH 2/3] hwmon: xgene: Adds hwmon driver

This patch adds hardware temperature and power reading support for APM X-Gene SoC's using the mailbox communication interface. Signed-off-by: Hoan Tran --- Documentation/hwmon/xgene-hwmon | 32 ++ drivers/hwmon/Kconfig | 7 + drivers/hwmon/Makefile | 1 +

[PATCH 0/3] Add support for X-Gene hwmon driver

This patch set adds hardware temperature and power reading support ​for APM X-Gene SoC's using the mailbox communication interface. For device tree, it is the standard DT mailbox. For ACPI, it is the PCC mailbox. For ACPI, tested with this patch[1] which supports PCC subspace 2 [1]

[PATCH 0/3] Add support for X-Gene hwmon driver

This patch set adds hardware temperature and power reading support ​for APM X-Gene SoC's using the mailbox communication interface. For device tree, it is the standard DT mailbox. For ACPI, it is the PCC mailbox. For ACPI, tested with this patch[1] which supports PCC subspace 2 [1]

Re: [PATCH] watchdog: qcom: Report reboot reason

[plain text this time...] On Sat, May 14, 2016 at 9:35 AM, Wim Van Sebroeck wrote: > > Hi Guenter, > > > The Qualcom watchdog timer block reports if the system was reset by the > > watchdog. Pass the information to user space. > > > > Cc: Grant Grundler >

Re: [PATCH] watchdog: qcom: Report reboot reason

[plain text this time...] On Sat, May 14, 2016 at 9:35 AM, Wim Van Sebroeck wrote: > > Hi Guenter, > > > The Qualcom watchdog timer block reports if the system was reset by the > > watchdog. Pass the information to user space. > > > > Cc: Grant Grundler > > Signed-off-by: Guenter Roeck > > ---

Re: [PATCH] tools: testing: define the _GNU_SOURCE macro

On 05/16/2016 08:02 AM, Muhammad Falak R Wani wrote: > On Mon, May 16, 2016 at 07:27:25AM -0600, Shuah Khan wrote: >> On 05/13/2016 06:05 AM, Muhammad Falak R Wani wrote: >>> Add the macro _GNU_SOURCE, so that compilation does not terminate. >> >> What error are you seeing? Could you please send

Re: [PATCH] tools: testing: define the _GNU_SOURCE macro

On 05/16/2016 08:02 AM, Muhammad Falak R Wani wrote: > On Mon, May 16, 2016 at 07:27:25AM -0600, Shuah Khan wrote: >> On 05/13/2016 06:05 AM, Muhammad Falak R Wani wrote: >>> Add the macro _GNU_SOURCE, so that compilation does not terminate. >> >> What error are you seeing? Could you please send

Re: [PATCH 1/2] kselftests/ftrace: Detect tracefs mount point

On 05/10/2016 09:24 AM, Shuah Khan wrote: > On 05/10/2016 08:53 AM, Namhyung Kim wrote: >> Currently ftracetest assumes tracing directory is located under >> $DEBUGFS/tracing. But it's possible to mount tracefs directly without >> debugfs. >> >> Signed-off-by: Namhyung Kim >

Re: [PATCH 1/2] kselftests/ftrace: Detect tracefs mount point

On 05/10/2016 09:24 AM, Shuah Khan wrote: > On 05/10/2016 08:53 AM, Namhyung Kim wrote: >> Currently ftracetest assumes tracing directory is located under >> $DEBUGFS/tracing. But it's possible to mount tracefs directly without >> debugfs. >> >> Signed-off-by: Namhyung Kim > > Looks good to me.

Re: [PATCH 2/2] kselftests/ftrace: Add a test case for event pid filtering

On 05/10/2016 09:24 AM, Shuah Khan wrote: > On 05/10/2016 08:53 AM, Namhyung Kim wrote: >> Check event is filtered by set_event_pid and options/event-fork. >> >> Signed-off-by: Namhyung Kim > > Looks good to me. Steve! Ack if you are good with this patch. > I can get this

Re: [PATCH 2/2] kselftests/ftrace: Add a test case for event pid filtering

On 05/10/2016 09:24 AM, Shuah Khan wrote: > On 05/10/2016 08:53 AM, Namhyung Kim wrote: >> Check event is filtered by set_event_pid and options/event-fork. >> >> Signed-off-by: Namhyung Kim > > Looks good to me. Steve! Ack if you are good with this patch. > I can get this into 4.8-rc1 > >

Re: [Patch v5 1/8] dt/bindings: firmware: Add Qualcomm SCM binding

On Thu, May 12, 2016 at 10:46:54PM -0500, Andy Gross wrote: > This patch adds the device tree support for the Qualcomm SCM firmware. > > Signed-off-by: Andy Gross > --- > .../devicetree/bindings/firmware/qcom,scm.txt | 28 > ++ > 1 file changed,

Re: [Patch v5 1/8] dt/bindings: firmware: Add Qualcomm SCM binding

On Thu, May 12, 2016 at 10:46:54PM -0500, Andy Gross wrote: > This patch adds the device tree support for the Qualcomm SCM firmware. > > Signed-off-by: Andy Gross > --- > .../devicetree/bindings/firmware/qcom,scm.txt | 28 > ++ > 1 file changed, 28 insertions(+) >

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

So I’ve been looking at AIO handling in f_fs and either I’m stupid or the code is broken. Here’s part of ffs_user_copy_worker: int ret = io_data->req->status ? io_data->req->status : io_data->req->actual; if (io_data->read && ret > 0) {

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

So I’ve been looking at AIO handling in f_fs and either I’m stupid or the code is broken. Here’s part of ffs_user_copy_worker: int ret = io_data->req->status ? io_data->req->status : io_data->req->actual; if (io_data->read && ret > 0) {

Re: [PATCH V4 8/9] dt-bindings: arm-gic: Add documentation for Tegra210 AGIC

On Thu, May 12, 2016 at 04:19:31PM +0100, Jon Hunter wrote: > The Tegra AGIC is an interrupt controller that is compatible with the > ARM GIC-400, however, it is a 2nd level controller and requires runtime > power-management because it is outside the main CPU complex. Ideally, > the AGIC would use

Re: [PATCH V4 8/9] dt-bindings: arm-gic: Add documentation for Tegra210 AGIC

On Thu, May 12, 2016 at 04:19:31PM +0100, Jon Hunter wrote: > The Tegra AGIC is an interrupt controller that is compatible with the > ARM GIC-400, however, it is a 2nd level controller and requires runtime > power-management because it is outside the main CPU complex. Ideally, > the AGIC would use

Re: [PATCH 1/4] dt: bindings: add bcm2835-memory-controller documentation

On Thu, May 12, 2016 at 12:38:49PM +, ker...@martin.sperl.org wrote: > From: Martin Sperl > > Add memory controller dt-binding documentation for the > bcm2835 soc. > > Signed-off-by: Martin Sperl > --- >

Re: [PATCH 1/4] dt: bindings: add bcm2835-memory-controller documentation

On Thu, May 12, 2016 at 12:38:49PM +, ker...@martin.sperl.org wrote: > From: Martin Sperl > > Add memory controller dt-binding documentation for the > bcm2835 soc. > > Signed-off-by: Martin Sperl > --- > .../bindings/memory-controllers/brcm,bcm2835-sdram.txt | 16 > >

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

>static int raydium_i2c_do_update_firmware(struct raydium_data *ts, >const struct firmware *fw) >{ > struct i2c_client *client = ts->client; > const void *data; > size_t data_len; > size_t len; > int page_nr; > int i; >

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

>static int raydium_i2c_do_update_firmware(struct raydium_data *ts, >const struct firmware *fw) >{ > struct i2c_client *client = ts->client; > const void *data; > size_t data_len; > size_t len; > int page_nr; > int i; >

Re: [PATCH 1/1] userfaultfd: don't pin the user memory in userfaultfd_file_create()

On Mon, May 16, 2016 at 05:25:46PM +0200, Oleg Nesterov wrote: > userfaultfd_file_create() increments mm->mm_users; this means that the memory > won't be unmapped/freed if mm owner exits/execs, and UFFDIO_COPY after that > can > populate the orphaned mm more. > > Change userfaultfd_file_create()

Re: [PATCH 1/1] userfaultfd: don't pin the user memory in userfaultfd_file_create()

On Mon, May 16, 2016 at 05:25:46PM +0200, Oleg Nesterov wrote: > userfaultfd_file_create() increments mm->mm_users; this means that the memory > won't be unmapped/freed if mm owner exits/execs, and UFFDIO_COPY after that > can > populate the orphaned mm more. > > Change userfaultfd_file_create()

Re: [PATCH] x86/boot: Refuse to build with data relocations

On Thu, May 12, 2016 at 01:31:04PM -0700, Kees Cook wrote: > diff --git a/arch/x86/boot/compressed/Makefile > b/arch/x86/boot/compressed/Makefile > index cfdd8c3f8af2..25d477fcd5b4 100644 > --- a/arch/x86/boot/compressed/Makefile > +++ b/arch/x86/boot/compressed/Makefile > @@ -85,7 +85,25 @@

Re: [PATCH] x86/boot: Refuse to build with data relocations

On Thu, May 12, 2016 at 01:31:04PM -0700, Kees Cook wrote: > diff --git a/arch/x86/boot/compressed/Makefile > b/arch/x86/boot/compressed/Makefile > index cfdd8c3f8af2..25d477fcd5b4 100644 > --- a/arch/x86/boot/compressed/Makefile > +++ b/arch/x86/boot/compressed/Makefile > @@ -85,7 +85,25 @@

Re: [PATCH] arm: tegra: initial support for apalis tk1

On Thu, May 12, 2016 at 02:27:12PM +0200, Marcel Ziswiler wrote: > This patch adds the device tree to support Toradex Apalis TK1 a > computer on module which can be used on different carrier boards. > > The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of DDR3L > RAM, a bunch of level

Re: [PATCH] arm: tegra: initial support for apalis tk1

On Thu, May 12, 2016 at 02:27:12PM +0200, Marcel Ziswiler wrote: > This patch adds the device tree to support Toradex Apalis TK1 a > computer on module which can be used on different carrier boards. > > The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of DDR3L > RAM, a bunch of level

Re: UBSAN: Undefined behaviour in block/blk-mq.c:1459:27 with pata_amd

On 05/13/2016 09:31 AM, Bartlomiej Zolnierkiewicz wrote: Does the patch below help? From: Bartlomiej Zolnierkiewicz Subject: [PATCH] blk-mq: fix undefined behaviour in order_to_size() When this_order variable in blk_mq_init_rq_map() becomes zero the code incorrectly

Re: UBSAN: Undefined behaviour in block/blk-mq.c:1459:27 with pata_amd

On 05/13/2016 09:31 AM, Bartlomiej Zolnierkiewicz wrote: Does the patch below help? From: Bartlomiej Zolnierkiewicz Subject: [PATCH] blk-mq: fix undefined behaviour in order_to_size() When this_order variable in blk_mq_init_rq_map() becomes zero the code incorrectly decrements the variable

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On 2016/5/11 17:31, Peter Zijlstra wrote: > Please use the GEN_*_RMWcc() stuff to avoid the setpo where possible. Setpo is better. In most cases, we need to store the parity, or compare it with other variables. For example, in drivers/net/ethernet/broadcom/tg3.c, static int

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On 2016/5/11 17:31, Peter Zijlstra wrote: > Please use the GEN_*_RMWcc() stuff to avoid the setpo where possible. Setpo is better. In most cases, we need to store the parity, or compare it with other variables. For example, in drivers/net/ethernet/broadcom/tg3.c, static int

Re: [PATCH v2 0/8] crypto: caam - add support for LS1043A SoC

On 5/5/2016 6:34 PM, Horia Geantă wrote: > v2: > As suggested by Arnd, patch 1 fixes io{read,write}{16,32}be accessors > to prevent the case when {read,write}{w,l} are overriden by arch-specific > ones having barriers, while the BE accessors previously mentioned are not > (thus behaving

Re: [PATCH v2 0/8] crypto: caam - add support for LS1043A SoC

On 5/5/2016 6:34 PM, Horia Geantă wrote: > v2: > As suggested by Arnd, patch 1 fixes io{read,write}{16,32}be accessors > to prevent the case when {read,write}{w,l} are overriden by arch-specific > ones having barriers, while the BE accessors previously mentioned are not > (thus behaving

Re: [PATCH 2/2] clk: rockchip: fix incorrect parent for rk3399's {c,g}pll_aclk_perihp_src

Hi, On Fri, May 13, 2016 at 8:36 PM, Xing Zheng wrote: > Hi Doug, > > > On 2016年05月14日 04:10, Doug Anderson wrote: >> >> Hi, >> >> On Fri, May 13, 2016 at 11:42 AM, Brian Norris >> wrote: >>> >>> From: Xing Zheng >>>

Re: [PATCH 2/2] clk: rockchip: fix incorrect parent for rk3399's {c,g}pll_aclk_perihp_src

Hi, On Fri, May 13, 2016 at 8:36 PM, Xing Zheng wrote: > Hi Doug, > > > On 2016年05月14日 04:10, Doug Anderson wrote: >> >> Hi, >> >> On Fri, May 13, 2016 at 11:42 AM, Brian Norris >> wrote: >>> >>> From: Xing Zheng >>> >>> There was a typo, swapping 'c' <--> 'g'. >>> >>> Signed-off-by: Xing

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

Hi Dmitry: I've finished issues under the format you suggested as below. >#define RM_RESET_MSG_ADDR 0x4004 >#define RM_FASTBOOT_MSG_ADDR 0x5620 >#define RM_MAX_READ_SIZE 63 change maximum read size to 56 bytes #define RM_MAX_READ_SIZE56 >#define RM_CONTACT_X_POS

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

Hi Dmitry: I've finished issues under the format you suggested as below. >#define RM_RESET_MSG_ADDR 0x4004 >#define RM_FASTBOOT_MSG_ADDR 0x5620 >#define RM_MAX_READ_SIZE 63 change maximum read size to 56 bytes #define RM_MAX_READ_SIZE56 >#define RM_CONTACT_X_POS

Re: [lkp] [xfs] a08ee40a79: kmsg.XFS(vdd):unknown_mount_option[nosuchopt]

On 5/15/16 8:42 PM, kernel test robot wrote: > FYI, we noticed the following commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit a08ee40a79653d082911cab9fbeff94baa7714cb ("xfs: sanitize remount > options") > > on test machine: vm-kbuild-4G: 4 threads

Re: [lkp] [xfs] a08ee40a79: kmsg.XFS(vdd):unknown_mount_option[nosuchopt]

On 5/15/16 8:42 PM, kernel test robot wrote: > FYI, we noticed the following commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit a08ee40a79653d082911cab9fbeff94baa7714cb ("xfs: sanitize remount > options") > > on test machine: vm-kbuild-4G: 4 threads

Re: [git pull] vfs.git

On Sun, May 15, 2016 at 8:32 PM, Al Viro wrote: > FWIW, I considered sending that pile in several pull requests, but for some > reason git request-pull v4.6 vfs work.lookups spews something very odd into > diffstat - files that have never been touched by it and, in fact,

Re: [git pull] vfs.git

On Sun, May 15, 2016 at 8:32 PM, Al Viro wrote: > FWIW, I considered sending that pile in several pull requests, but for some > reason git request-pull v4.6 vfs work.lookups spews something very odd into > diffstat - files that have never been touched by it and, in fact, doing > merge with

[PATCH] dell_rbu: Don't fallback to userhelper when loading firmware

dell_rbu previously would allow a userspace application to craft the payload after dell_rbu was loaded and abuse the udev userspace API. Instead require the payload to be crafted and placed in /lib/firmware/dell_rbu ahead of time. This adjusts dell_rbu to immediately load the firmware from

[PATCH] dell_rbu: Don't fallback to userhelper when loading firmware

dell_rbu previously would allow a userspace application to craft the payload after dell_rbu was loaded and abuse the udev userspace API. Instead require the payload to be crafted and placed in /lib/firmware/dell_rbu ahead of time. This adjusts dell_rbu to immediately load the firmware from

Re: [PATCH 1/1] tty/serial: to support 8250 earlycon can be enabled independently

On 05/16/2016 04:35 AM, Zhen Lei wrote: > Sometimes, we may only use SSH to login, and build 8250 uart driver as a > ko(insmod if needed). But the earlycon may still be necessary, because > the kernel boot process may take a long time. It's not good to display > nothing but ask people to wait

Re: [PATCH 1/1] tty/serial: to support 8250 earlycon can be enabled independently

On 05/16/2016 04:35 AM, Zhen Lei wrote: > Sometimes, we may only use SSH to login, and build 8250 uart driver as a > ko(insmod if needed). But the earlycon may still be necessary, because > the kernel boot process may take a long time. It's not good to display > nothing but ask people to wait

<    6   7   8   9   10   11   12   13   14   15   >