Re: [PATCH] Input - ntrig_spi: add new driver for the Surface 3

On Thu, 2016-05-12 at 21:51 +0200, Benjamin Tissoires wrote: > Which leads to an other question: do you think we should call it > surface_ts_spi.c instead of ntrig_spi? I am not sure this will work > with any other Ntrig/SPI device... N-Trig got bought by Microsoft, so it's unlikely that this

Re: [PATCH] Input - ntrig_spi: add new driver for the Surface 3

On Thu, May 12, 2016 at 09:51:22PM +0200, Benjamin Tissoires wrote: > On May 12 2016 or thereabouts, Dmitry Torokhov wrote: > > On Thu, May 12, 2016 at 05:07:54PM +0200, Benjamin Tissoires wrote: > > > +static int __maybe_unused ntrig_spi_suspend(struct device *dev) > > > +{ > > > + struct

Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, May 12, 2016 at 01:25:08PM -0600, Jason Gunthorpe wrote: On Thu, May 12, 2016 at 03:07:38PM -0400, Dennis Dalessandro wrote: >>There is also a driver software version being exported via a sysfs >>file. This is needed so that user space applications (psm) can >>determine if it needs to

Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, May 12, 2016 at 01:25:08PM -0600, Jason Gunthorpe wrote: On Thu, May 12, 2016 at 03:07:38PM -0400, Dennis Dalessandro wrote: >>There is also a driver software version being exported via a sysfs >>file. This is needed so that user space applications (psm) can >>determine if it needs to

Re: [PATCH] Input - ntrig_spi: add new driver for the Surface 3

On May 12 2016 or thereabouts, Dmitry Torokhov wrote: > Hi Benjamin, > > On Thu, May 12, 2016 at 05:07:54PM +0200, Benjamin Tissoires wrote: > > This is a basic driver for the Surface 3. I am not so sure it will work > > with any firmwares as most values are encoded, but given that I only have >

Re: [PATCH] Input - ntrig_spi: add new driver for the Surface 3

On May 12 2016 or thereabouts, Dmitry Torokhov wrote: > Hi Benjamin, > > On Thu, May 12, 2016 at 05:07:54PM +0200, Benjamin Tissoires wrote: > > This is a basic driver for the Surface 3. I am not so sure it will work > > with any firmwares as most values are encoded, but given that I only have >

[RFC][PATCH 0/5] sched: Diagnostic checks for missing rq clock updates

There are currently no runtime diagnostic checks for detecting when we have inadvertently missed a call to update_rq_clock() before accessing rq_clock(). The idea in these patches, which came from Peter, is to piggyback on the rq->lock pin/unpin context to detect when we expected (and failed) to

[RFC][PATCH 0/5] sched: Diagnostic checks for missing rq clock updates

There are currently no runtime diagnostic checks for detecting when we have inadvertently missed a call to update_rq_clock() before accessing rq_clock(). The idea in these patches, which came from Peter, is to piggyback on the rq->lock pin/unpin context to detect when we expected (and failed) to

[RFC][PATCH 2/5] sched: Add wrappers for lockdep_(un)pin_lock()

In preparation for adding diagnostic checks to catch missing calls to update_rq_clock(), provide wrappers for (re)pinning and unpinning rq->lock. Because the pending diagnostic checks allow state to be maintained in rq_flags across pin contexts, swap the 'struct pin_cookie' arguments for 'struct

[RFC][PATCH 2/5] sched: Add wrappers for lockdep_(un)pin_lock()

In preparation for adding diagnostic checks to catch missing calls to update_rq_clock(), provide wrappers for (re)pinning and unpinning rq->lock. Because the pending diagnostic checks allow state to be maintained in rq_flags across pin contexts, swap the 'struct pin_cookie' arguments for 'struct

[RFC][PATCH 1/5] sched/fair: Update the rq clock before detaching tasks

detach_task_cfs_rq() may indirectly call rq_clock() to inform the cpufreq code that the rq utilisation has changed. In which case, we need to update the rq clock. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike

[RFC][PATCH 1/5] sched/fair: Update the rq clock before detaching tasks

detach_task_cfs_rq() may indirectly call rq_clock() to inform the cpufreq code that the rq utilisation has changed. In which case, we need to update the rq clock. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike Galbraith Cc: Yuyang Du Cc: Byungchul Park Cc: Rik van Riel Cc:

[RFC][PATCH 3/5] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

rq_clock() is called from sched_info_{depart,arrive}() after resetting RQCF_ACT_SKIP but prior to a call to update_rq_clock(). In preparation for pending patches that check whether the rq clock has been updated inside of a pin context before rq_clock() is called, move the reset of

[RFC][PATCH 3/5] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

rq_clock() is called from sched_info_{depart,arrive}() after resetting RQCF_ACT_SKIP but prior to a call to update_rq_clock(). In preparation for pending patches that check whether the rq clock has been updated inside of a pin context before rq_clock() is called, move the reset of

[RFC][PATCH 4/5] sched/fair: Push rq lock pin/unpin into idle_balance()

Future patches will emit warnings if rq_clock() is called before update_rq_clock() inside a rq_pin_lock()/rq_unpin_lock() pair. Since there is only one caller of idle_balance() we can push the unpin/repin there. Cc: Peter Zijlstra Cc: Ingo Molnar Cc:

[RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

There's no diagnostic checks for figuring out when we've accidentally missed update_rq_clock() calls. Let's add some by piggybacking on the rq_*pin_lock() wrappers. The idea behind the diagnostic checks is that upon pining rq lock the rq clock should be updated, via update_rq_clock(), before

[RFC][PATCH 4/5] sched/fair: Push rq lock pin/unpin into idle_balance()

Future patches will emit warnings if rq_clock() is called before update_rq_clock() inside a rq_pin_lock()/rq_unpin_lock() pair. Since there is only one caller of idle_balance() we can push the unpin/repin there. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mike Galbraith Cc: Mel Gorman Cc: Yuyang

[RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

There's no diagnostic checks for figuring out when we've accidentally missed update_rq_clock() calls. Let's add some by piggybacking on the rq_*pin_lock() wrappers. The idea behind the diagnostic checks is that upon pining rq lock the rq clock should be updated, via update_rq_clock(), before

Re: [PATCH 6/6] pinctrl: tegra: Add driver to configure voltage and power state of io pads

On 02/05/16 13:17, Laxman Dewangan wrote: > NVIDIA Tegra210 supports the IO pads which can operate at 1.8V > or 3.3V I/O voltage levels. Also the IO pads can be configured > for power down state if it is not used. SW needs to configure the > voltage level of IO pads based on IO rail voltage and

Re: [PATCH 6/6] pinctrl: tegra: Add driver to configure voltage and power state of io pads

On 02/05/16 13:17, Laxman Dewangan wrote: > NVIDIA Tegra210 supports the IO pads which can operate at 1.8V > or 3.3V I/O voltage levels. Also the IO pads can be configured > for power down state if it is not used. SW needs to configure the > voltage level of IO pads based on IO rail voltage and

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

Hi Dave, Tried to do my xfs homework first! On Fri, May 06, 2016 at 12:50:36PM +1000, Dave Chinner wrote: > On Thu, May 05, 2016 at 11:24:35PM +0100, Djalal Harouni wrote: > > On Thu, May 05, 2016 at 10:23:14AM +1000, Dave Chinner wrote: > > > On Wed, May 04, 2016 at 04:26:46PM +0200, Djalal

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

Hi Dave, Tried to do my xfs homework first! On Fri, May 06, 2016 at 12:50:36PM +1000, Dave Chinner wrote: > On Thu, May 05, 2016 at 11:24:35PM +0100, Djalal Harouni wrote: > > On Thu, May 05, 2016 at 10:23:14AM +1000, Dave Chinner wrote: > > > On Wed, May 04, 2016 at 04:26:46PM +0200, Djalal

Re: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

On 05/12/2016 03:40 PM, Jason Gunthorpe wrote: > On Thu, May 12, 2016 at 03:27:27PM -0400, Dennis Dalessandro wrote: >>> I thought we agreed to get rid of this as well? It certainly does not >>> belong here, and as a general rule, I don't think ioctls should be >>> doing capable tests.. >> >>

Re: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

On 05/12/2016 03:40 PM, Jason Gunthorpe wrote: > On Thu, May 12, 2016 at 03:27:27PM -0400, Dennis Dalessandro wrote: >>> I thought we agreed to get rid of this as well? It certainly does not >>> belong here, and as a general rule, I don't think ioctls should be >>> doing capable tests.. >> >>

Re: [PATCH 0/4] add minimal bcm2835-sdram driver

> On 12.05.2016, at 20:15, Eric Anholt wrote: > > ker...@martin.sperl.org writes: > >> From: Martin Sperl >> >> As the sdram clock is a critical clock to the system >> the minimal bcm2835-sdram driver claims (and enables) >> this clock and also

Re: [PATCH 0/4] add minimal bcm2835-sdram driver

> On 12.05.2016, at 20:15, Eric Anholt wrote: > > ker...@martin.sperl.org writes: > >> From: Martin Sperl >> >> As the sdram clock is a critical clock to the system >> the minimal bcm2835-sdram driver claims (and enables) >> this clock and also exposes the corresponding sdram >> registers

Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable

On 05/12/2016 08:19 AM, Michal Hocko wrote: On Thu 12-05-16 14:12:04, Peter Zijlstra wrote: On Wed, May 11, 2016 at 08:03:46PM +0200, Michal Hocko wrote: I still cannot say I would understand why the pending RWSEM_WAITING_BIAS matters but I would probably need to look at the code again with a

Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable

On 05/12/2016 08:19 AM, Michal Hocko wrote: On Thu 12-05-16 14:12:04, Peter Zijlstra wrote: On Wed, May 11, 2016 at 08:03:46PM +0200, Michal Hocko wrote: I still cannot say I would understand why the pending RWSEM_WAITING_BIAS matters but I would probably need to look at the code again with a

Re: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

On Thu, May 12, 2016 at 03:27:27PM -0400, Dennis Dalessandro wrote: > >I thought we agreed to get rid of this as well? It certainly does not > >belong here, and as a general rule, I don't think ioctls should be > >doing capable tests.. > > Yeah. I left it in this patch set because this just

Re: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

On Thu, May 12, 2016 at 03:27:27PM -0400, Dennis Dalessandro wrote: > >I thought we agreed to get rid of this as well? It certainly does not > >belong here, and as a general rule, I don't think ioctls should be > >doing capable tests.. > > Yeah. I left it in this patch set because this just

Re: [PATCH net-next 2/5] drivers: replace dev->trans_start accesses with dev_trans_start

On 05/03/2016 10:30 AM, Florian Westphal wrote: > a trans_start struct member exists twice: > - in struct net_device (legacy) > - in struct netdev_queue > > Instead of open-coding dev->trans_start usage to obtain the current > trans_start value, use dev_trans_start() instead. > > This is not

Re: [PATCH net-next 2/5] drivers: replace dev->trans_start accesses with dev_trans_start

On 05/03/2016 10:30 AM, Florian Westphal wrote: > a trans_start struct member exists twice: > - in struct net_device (legacy) > - in struct netdev_queue > > Instead of open-coding dev->trans_start usage to obtain the current > trans_start value, use dev_trans_start() instead. > > This is not

[RFC] wcn36xx: Implement firmware assisted scan

Using the software based channel scan mechanism from mac80211 keeps us offline for 10-15 second, we should instead issue a start_scan/end_scan on each channel reducing this time. Signed-off-by: Bjorn Andersson --- With this implementation I see a reduction of

[RFC] wcn36xx: Implement firmware assisted scan

Using the software based channel scan mechanism from mac80211 keeps us offline for 10-15 second, we should instead issue a start_scan/end_scan on each channel reducing this time. Signed-off-by: Bjorn Andersson --- With this implementation I see a reduction of throughput for about 1-2 seconds

Re: [PATCH 1/2] i2c: qup: Cleared the error bits in ISR

On Thu, May 12, 2016 at 12:58:30PM -0500, Andy Gross wrote: > On Thu, May 12, 2016 at 11:48:43AM +0530, Abhishek Sahu wrote: > > On Thu, May 12, 2016 at 12:13:47AM -0500, Andy Gross wrote: > > > On Wed, May 11, 2016 at 11:04:17PM +0530, Abhishek Sahu wrote: > > > > > > > > > > > > > > In

Re: [PATCH 1/2] i2c: qup: Cleared the error bits in ISR

On Thu, May 12, 2016 at 12:58:30PM -0500, Andy Gross wrote: > On Thu, May 12, 2016 at 11:48:43AM +0530, Abhishek Sahu wrote: > > On Thu, May 12, 2016 at 12:13:47AM -0500, Andy Gross wrote: > > > On Wed, May 11, 2016 at 11:04:17PM +0530, Abhishek Sahu wrote: > > > > > > > > > > > > > > In

[PATCH v5 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Randomizes the virtual address space of kernel memory sections (physical memory mapping, vmalloc & vmemmap) for x86_64. This security feature mitigates exploits relying on predictable kernel addresses. These addresses can be used to disclose the kernel modules base addresses or corrupt specific

[PATCH v5 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define the padding used for the physical memory mapping section when KASLR memory is enabled. It ensures there is enough virtual address space when CONFIG_MEMORY_HOTPLUG is used. The default value is 10 terabytes. If

[PATCH v5 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Randomizes the virtual address space of kernel memory sections (physical memory mapping, vmalloc & vmemmap) for x86_64. This security feature mitigates exploits relying on predictable kernel addresses. These addresses can be used to disclose the kernel modules base addresses or corrupt specific

[PATCH v5 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define the padding used for the physical memory mapping section when KASLR memory is enabled. It ensures there is enough virtual address space when CONFIG_MEMORY_HOTPLUG is used. The default value is 10 terabytes. If

[PATCH v5 1/4] x86, boot: Refactor KASLR entropy functions

Move the KASLR entropy functions in x86/libray to be used in early kernel boot for KASLR memory randomization. Signed-off-by: Thomas Garnier --- Based on next-20160511 --- arch/x86/boot/compressed/kaslr.c | 77 +++--- arch/x86/include/asm/kaslr.h

[PATCH v5 1/4] x86, boot: Refactor KASLR entropy functions

Move the KASLR entropy functions in x86/libray to be used in early kernel boot for KASLR memory randomization. Signed-off-by: Thomas Garnier --- Based on next-20160511 --- arch/x86/boot/compressed/kaslr.c | 77 +++--- arch/x86/include/asm/kaslr.h | 6 +++

[PATCH v5 0/4] x86, boot: KASLR memory randomization

This is PATCH v5 for KASLR memory implementation for x86_64. Recent changes: Add performance information on commit. Add details on PUD alignment. Add information on testing against the KASLR bypass exploit. Rebase on next-20160511 and merge recent KASLR changes. Integrate

[PATCH v5 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

Minor change that allows early boot physical mapping of PUD level virtual addresses. The current implementation expect the virtual address to be PUD aligned. For KASLR memory randomization, we need to be able to randomize the offset used on the PUD table. It has no impact on current usage.

[PATCH v5 0/4] x86, boot: KASLR memory randomization

This is PATCH v5 for KASLR memory implementation for x86_64. Recent changes: Add performance information on commit. Add details on PUD alignment. Add information on testing against the KASLR bypass exploit. Rebase on next-20160511 and merge recent KASLR changes. Integrate

[PATCH v5 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

Minor change that allows early boot physical mapping of PUD level virtual addresses. The current implementation expect the virtual address to be PUD aligned. For KASLR memory randomization, we need to be able to randomize the offset used on the PUD table. It has no impact on current usage.

[PATCH v9.1] gpio: mmio: add DT support for memory-mapped GPIOs

From: Álvaro Fernández Rojas This patch adds support for defining memory-mapped GPIOs which are compatible with the existing gpio-mmio interface. The generic library provides support for many memory-mapped GPIO controllers that are found in various on-board FPGA and ASIC

[PATCH v9.1] gpio: mmio: add DT support for memory-mapped GPIOs

From: Álvaro Fernández Rojas This patch adds support for defining memory-mapped GPIOs which are compatible with the existing gpio-mmio interface. The generic library provides support for many memory-mapped GPIO controllers that are found in various on-board FPGA and ASIC solutions that are used

Re: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

On Thu, May 12, 2016 at 11:43:32AM -0600, Jason Gunthorpe wrote: On Thu, May 12, 2016 at 10:18:47AM -0700, Dennis Dalessandro wrote: + case HFI1_IOCTL_EP_INFO: + case HFI1_IOCTL_EP_ERASE_CHIP: + case HFI1_IOCTL_EP_ERASE_RANGE: + case HFI1_IOCTL_EP_READ_RANGE: +

Re: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

On Thu, May 12, 2016 at 11:43:32AM -0600, Jason Gunthorpe wrote: On Thu, May 12, 2016 at 10:18:47AM -0700, Dennis Dalessandro wrote: + case HFI1_IOCTL_EP_INFO: + case HFI1_IOCTL_EP_ERASE_CHIP: + case HFI1_IOCTL_EP_ERASE_RANGE: + case HFI1_IOCTL_EP_READ_RANGE: +

[PATCH] fs: jffs2: initialize the field fs_flags

jffs2 requires device, so the field fs_flags of the structure file_system_type must be initialized to FS_REQUIRES_DEV. Signed-off-by: Salah Triki --- fs/jffs2/super.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c index

[PATCH] fs: jffs2: initialize the field fs_flags

jffs2 requires device, so the field fs_flags of the structure file_system_type must be initialized to FS_REQUIRES_DEV. Signed-off-by: Salah Triki --- fs/jffs2/super.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c index 0a9a114..fd24af9 100644 ---

Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, May 12, 2016 at 03:07:38PM -0400, Dennis Dalessandro wrote: > >>There is also a driver software version being exported via a sysfs > >>file. This is needed so that user space applications (psm) can > >>determine if it needs to do ioctl() or write(). > > > >Why? Don't do this, just call

Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, May 12, 2016 at 03:07:38PM -0400, Dennis Dalessandro wrote: > >>There is also a driver software version being exported via a sysfs > >>file. This is needed so that user space applications (psm) can > >>determine if it needs to do ioctl() or write(). > > > >Why? Don't do this, just call

Re: [PATCH] ARM: dts: omap5-igep0050: Correct hdmi regulator

On 05/12/2016 11:57 AM, Tony Lindgren wrote: > * Eduard Gavin [160509 07:43]: >> Dear Nishanth, >> In igepV5 the LDO7 is connected to: >> VDDA_DSIPORTA - ball AA33 >> VDDA_DSIPORTC - ball AE33 >> VDDA_HDMI - ball AN25 >> LDO4 is connected to: >> VPP1 - ball

Re: [PATCH] ARM: dts: omap5-igep0050: Correct hdmi regulator

On 05/12/2016 11:57 AM, Tony Lindgren wrote: > * Eduard Gavin [160509 07:43]: >> Dear Nishanth, >> In igepV5 the LDO7 is connected to: >> VDDA_DSIPORTA - ball AA33 >> VDDA_DSIPORTC - ball AE33 >> VDDA_HDMI - ball AN25 >> LDO4 is connected to: >> VPP1 - ball AD9 > > Thanks for

Re: [PATCH] Input - ntrig_spi: add new driver for the Surface 3

Hi Benjamin, On Thu, May 12, 2016 at 05:07:54PM +0200, Benjamin Tissoires wrote: > This is a basic driver for the Surface 3. I am not so sure it will work > with any firmwares as most values are encoded, but given that I only have > access to my current device with its firmware and I don't have

Re: [PATCH] Input - ntrig_spi: add new driver for the Surface 3

Hi Benjamin, On Thu, May 12, 2016 at 05:07:54PM +0200, Benjamin Tissoires wrote: > This is a basic driver for the Surface 3. I am not so sure it will work > with any firmwares as most values are encoded, but given that I only have > access to my current device with its firmware and I don't have

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt21

Hi Kamal, seems using a toolchain with gcc 6.1 creates funny new issues like this: In file included from include/linux/compiler.h:54:0, from include/uapi/linux/stddef.h:1, from include/linux/stddef.h:4, from ./include/uapi/linux/posix_types.h:4,

RE: [PATCH v3 2/2] dell-laptop: Expose auxiliary MAC address if available

> -Original Message- > From: Pali Rohár [mailto:pali.ro...@gmail.com] > Sent: Thursday, May 12, 2016 3:41 AM > To: Limonciello, Mario > Cc: ker...@kempniu.pl; mj...@srcf.ucam.org; dvh...@infradead.org; linux- > ker...@vger.kernel.org;

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

This allows any subtree to be uid/gid shifted and bound elsewhere. It does this by operating simlarly to overlayfs, except that since there's only a single underlying layer, all dentry lookups go through this. Its primary use is for shifting the underlying uids of filesystems used to support

Re: [3.19.y-ckt stable] Linux 3.19.8-ckt21

Hi Kamal, seems using a toolchain with gcc 6.1 creates funny new issues like this: In file included from include/linux/compiler.h:54:0, from include/uapi/linux/stddef.h:1, from include/linux/stddef.h:4, from ./include/uapi/linux/posix_types.h:4,

RE: [PATCH v3 2/2] dell-laptop: Expose auxiliary MAC address if available

> -Original Message- > From: Pali Rohár [mailto:pali.ro...@gmail.com] > Sent: Thursday, May 12, 2016 3:41 AM > To: Limonciello, Mario > Cc: ker...@kempniu.pl; mj...@srcf.ucam.org; dvh...@infradead.org; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org > Subject: Re:

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

This allows any subtree to be uid/gid shifted and bound elsewhere. It does this by operating simlarly to overlayfs, except that since there's only a single underlying layer, all dentry lookups go through this. Its primary use is for shifting the underlying uids of filesystems used to support

Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, May 12, 2016 at 11:34:45AM -0600, Jason Gunthorpe wrote: On Thu, May 12, 2016 at 10:18:27AM -0700, Dennis Dalessandro wrote: There is also a driver software version being exported via a sysfs file. This is needed so that user space applications (psm) can determine if it needs to do

Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, May 12, 2016 at 11:34:45AM -0600, Jason Gunthorpe wrote: On Thu, May 12, 2016 at 10:18:27AM -0700, Dennis Dalessandro wrote: There is also a driver software version being exported via a sysfs file. This is needed so that user space applications (psm) can determine if it needs to do

[RFC 0/1] shiftfs: uid/gid shifting filesystem

This is currently an RFC because the patch applies to Linus head, but needs altering for the vfs tree, so I'll respin and resend after the merge window closes. My use case for this is that I run a lot of unprivileged architectural emulation containers on my system using user namespaces. Details

[RFC 0/1] shiftfs: uid/gid shifting filesystem

This is currently an RFC because the patch applies to Linus head, but needs altering for the vfs tree, so I'll respin and resend after the merge window closes. My use case for this is that I run a lot of unprivileged architectural emulation containers on my system using user namespaces. Details

Re: [PATCH v4 0/3] drm: Add various helpers for simple drivers

Hi Noralf, Thank you for the patches. For 1/3 and 2/3, Reviewed-by: Laurent Pinchart On Thursday 12 May 2016 20:25:20 Noralf Trønnes wrote: > This patchset adds various helpers that was originally part of the > tinydrm patchset. > > Essentially it adds 2

Re: [PATCH v4 0/3] drm: Add various helpers for simple drivers

Hi Noralf, Thank you for the patches. For 1/3 and 2/3, Reviewed-by: Laurent Pinchart On Thursday 12 May 2016 20:25:20 Noralf Trønnes wrote: > This patchset adds various helpers that was originally part of the > tinydrm patchset. > > Essentially it adds 2 functions: > -

Re: [PATCH 6/6] pinctrl: tegra: Add driver to configure voltage and power state of io pads

Hello Laxman, On Mon, May 2, 2016 at 8:17 AM, Laxman Dewangan wrote: [snip] > diff --git a/drivers/pinctrl/tegra/pinctrl-tegra210-io-pad.c > b/drivers/pinctrl/tegra/pinctrl-tegra210-io-pad.c > new file mode 100644 > index 000..ab06c71 > --- /dev/null > +++

Re: [PATCH 6/6] pinctrl: tegra: Add driver to configure voltage and power state of io pads

Hello Laxman, On Mon, May 2, 2016 at 8:17 AM, Laxman Dewangan wrote: [snip] > diff --git a/drivers/pinctrl/tegra/pinctrl-tegra210-io-pad.c > b/drivers/pinctrl/tegra/pinctrl-tegra210-io-pad.c > new file mode 100644 > index 000..ab06c71 > --- /dev/null > +++

Re: [PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

Nice Kedar! Is this getting applied? I would really like to see this get into the mainline. thanks, Paul On Thu, Apr 7, 2016 at 1:29 AM, Kedareswara rao Appana wrote: > This patch adds support for the AXI Direct Memory Access (AXI DMA) > core in the existing vdma

Re: [PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

Nice Kedar! Is this getting applied? I would really like to see this get into the mainline. thanks, Paul On Thu, Apr 7, 2016 at 1:29 AM, Kedareswara rao Appana wrote: > This patch adds support for the AXI Direct Memory Access (AXI DMA) > core in the existing vdma driver, AXI DMA Core is a >

[git pull] Input updates for 4.6-rc7

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Changelog: - Chris Diamand (1): Input: byd - update copyright header H. Nikolaus Schaller (1): Input: twl6040-vibra - fix

[git pull] Input updates for 4.6-rc7

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Changelog: - Chris Diamand (1): Input: byd - update copyright header H. Nikolaus Schaller (1): Input: twl6040-vibra - fix

Re: [1/1] mm: thp: calculate the mapcount correctly for THP pages during WP faults

Reviewed-by: "Kirill A. Shutemov" Signed-off-by: Andrea Arcangeli Andrea, Perhaps add a V in the subject for subsequent submissions as well as version change control in email after the ---. I happened to know the differences, but others might

Re: [1/1] mm: thp: calculate the mapcount correctly for THP pages during WP faults

Reviewed-by: "Kirill A. Shutemov" Signed-off-by: Andrea Arcangeli Andrea, Perhaps add a V in the subject for subsequent submissions as well as version change control in email after the ---. I happened to know the differences, but others might not. This patch also solves the >= 4.5-rc1 IB

Re: [PATCH v4 10/18] sh: Remove unnecessary of_platform_populate with default match table

On Thu, May 12, 2016 at 08:06:07PM +0800, Kefeng Wang wrote: > After patch "of/platform: Add common method to populate default bus", > it is possible for arch code to remove unnecessary callers about the > of_platform_populate with default match table. s/about the/of/ ? > Cc: Yoshinori Sato

Re: [PATCH v4 10/18] sh: Remove unnecessary of_platform_populate with default match table

On Thu, May 12, 2016 at 08:06:07PM +0800, Kefeng Wang wrote: > After patch "of/platform: Add common method to populate default bus", > it is possible for arch code to remove unnecessary callers about the > of_platform_populate with default match table. s/about the/of/ ? > Cc: Yoshinori Sato >

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello Sergei, [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus Walleij to Cc, there is a question for

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello Sergei, [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus Walleij to Cc, there is a question for

Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4

On 5/12/2016 6:30 AM, Christian Lamparter wrote: > On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote: >> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote: >> Detecting the endianess of the >> device is probably the best future-proof solution, but it's also >>

Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4

On 5/12/2016 6:30 AM, Christian Lamparter wrote: > On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote: >> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote: >> Detecting the endianess of the >> device is probably the best future-proof solution, but it's also >>

Re: [PATCH v4 3/3] drm: Add helper for simple display pipeline

On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote: > Provides helper functions for drivers that have a simple display > pipeline. Plane, crtc and encoder are collapsed into one entity. > > Cc: jsa...@ti.com > Signed-off-by: Noralf Trønnes > --- > > Changes since

Re: [PATCH v4 3/3] drm: Add helper for simple display pipeline

On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote: > Provides helper functions for drivers that have a simple display > pipeline. Plane, crtc and encoder are collapsed into one entity. > > Cc: jsa...@ti.com > Signed-off-by: Noralf Trønnes > --- > > Changes since v3: > - (struct

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On 05/10/2016 08:57 AM, Borislav Petkov wrote: > On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: >> Is it not possible to maintain some kind of kernel virtual address >> mapping so memremap*() and friends can figure out when to twiddle the >> mapping attributes and map with/without

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On 05/10/2016 08:57 AM, Borislav Petkov wrote: > On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: >> Is it not possible to maintain some kind of kernel virtual address >> mapping so memremap*() and friends can figure out when to twiddle the >> mapping attributes and map with/without

Re: [PATCH] arm64: Implement optimised IP checksum helpers

Hi Robin, On 5/12/2016 1:08 PM, Robin Murphy wrote: Hi Luke, On 12/05/16 16:34, Luke Starrett wrote: Hi Robin, I pulled this in to a userspace test app expecting that the __uint128_t type might cause GCC to emit 'ldp'. Seems like that was that your intent based on your commit note. Instead

Re: [PATCH] arm64: Implement optimised IP checksum helpers

Hi Robin, On 5/12/2016 1:08 PM, Robin Murphy wrote: Hi Luke, On 12/05/16 16:34, Luke Starrett wrote: Hi Robin, I pulled this in to a userspace test app expecting that the __uint128_t type might cause GCC to emit 'ldp'. Seems like that was that your intent based on your commit note. Instead

[PATCH v3] mmc: dw_mmc: rockchip: Set the drive phase properly

Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance

[PATCH v3] mmc: dw_mmc: rockchip: Set the drive phase properly

Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance

Re: [PATCH v12 00/13] support "task_isolation" mode

Ping, since the 4.7 merge window is opening soon and I haven't received too much feedback on this version of the patch series based on 4.6-rc1. 1. Patch 09/13 for timer ticks was acked by Daniel Lezcano and is standalone, so could be taken into the relevant trees. I'm not sure if it should

Re: [PATCH v12 00/13] support "task_isolation" mode

Ping, since the 4.7 merge window is opening soon and I haven't received too much feedback on this version of the patch series based on 4.6-rc1. 1. Patch 09/13 for timer ticks was acked by Daniel Lezcano and is standalone, so could be taken into the relevant trees. I'm not sure if it should

[PATCH v4 3/3] drm: Add helper for simple display pipeline

Provides helper functions for drivers that have a simple display pipeline. Plane, crtc and encoder are collapsed into one entity. Cc: jsa...@ti.com Signed-off-by: Noralf Trønnes --- Changes since v3: - (struct drm_simple_display_pipe *)->funcs should be const Changes since

[PATCH v4 3/3] drm: Add helper for simple display pipeline

Provides helper functions for drivers that have a simple display pipeline. Plane, crtc and encoder are collapsed into one entity. Cc: jsa...@ti.com Signed-off-by: Noralf Trønnes --- Changes since v3: - (struct drm_simple_display_pipe *)->funcs should be const Changes since v2: - Drop Kconfig

[PATCH v4 2/3] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

Add drm_fb_cma_create_with_funcs() for drivers that need to set the dirty() callback. Signed-off-by: Noralf Trønnes Acked-by: Laurent Pinchart --- Changes since v3: - funcs argument should be const Changes since v1: - Expand docs

[PATCH v4 2/3] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

Add drm_fb_cma_create_with_funcs() for drivers that need to set the dirty() callback. Signed-off-by: Noralf Trønnes Acked-by: Laurent Pinchart --- Changes since v3: - funcs argument should be const Changes since v1: - Expand docs drivers/gpu/drm/drm_fb_cma_helper.c | 31

[PATCH v4 0/3] drm: Add various helpers for simple drivers

This patchset adds various helpers that was originally part of the tinydrm patchset. Essentially it adds 2 functions: - drm_fb_cma_create_with_funcs() CMA backed framebuffer supporting a dirty() callback. - drm_simple_display_pipe_init() Plane, crtc and encoder are collapsed into one entity.

[PATCH v4 0/3] drm: Add various helpers for simple drivers

This patchset adds various helpers that was originally part of the tinydrm patchset. Essentially it adds 2 functions: - drm_fb_cma_create_with_funcs() CMA backed framebuffer supporting a dirty() callback. - drm_simple_display_pipe_init() Plane, crtc and encoder are collapsed into one entity.

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