[PATCH 1/2] i2c: s3c2410: Print errno code in error logs

The driver not always prints the error code in case of a failure but this information can be very useful for debugging. So let's print if available. Signed-off-by: Javier Martinez Canillas --- Hello, This patch and 2/2 were only build tested because I don't have access

[PATCH 1/2] i2c: s3c2410: Print errno code in error logs

The driver not always prints the error code in case of a failure but this information can be very useful for debugging. So let's print if available. Signed-off-by: Javier Martinez Canillas --- Hello, This patch and 2/2 were only build tested because I don't have access to a board using this

Re: linux-next: Tree for Apr 19 (waketorture.c)

On Tue, Apr 19, 2016 at 12:34:10PM -0700, Randy Dunlap wrote: > On 04/19/16 12:05, Paul E. McKenney wrote: > > On Tue, Apr 19, 2016 at 10:55:21AM -0700, Randy Dunlap wrote: > >> On 04/19/16 09:56, Paul E. McKenney wrote: > >>> On Tue, Apr 19, 2016 at 09:20:24AM -0700, Randy Dunlap wrote: > On

Re: linux-next: Tree for Apr 19 (waketorture.c)

On Tue, Apr 19, 2016 at 12:34:10PM -0700, Randy Dunlap wrote: > On 04/19/16 12:05, Paul E. McKenney wrote: > > On Tue, Apr 19, 2016 at 10:55:21AM -0700, Randy Dunlap wrote: > >> On 04/19/16 09:56, Paul E. McKenney wrote: > >>> On Tue, Apr 19, 2016 at 09:20:24AM -0700, Randy Dunlap wrote: > On

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

Quoting Kees Cook (keesc...@chromium.org): > On Mon, Apr 18, 2016 at 9:54 AM, John Stultz wrote: > > On Thu, Apr 7, 2016 at 11:02 PM, Baolin Wang wrote: > >> security_settime() uses a timespec, which is not year 2038 safe > >> on 32bit systems.

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

Quoting Kees Cook (keesc...@chromium.org): > On Mon, Apr 18, 2016 at 9:54 AM, John Stultz wrote: > > On Thu, Apr 7, 2016 at 11:02 PM, Baolin Wang wrote: > >> security_settime() uses a timespec, which is not year 2038 safe > >> on 32bit systems. Thus this patch introduces the security_settime64()

Re: [RFC][PATCH 2/4] tracing: Use pid bitmap instead of a pid array for set_event_pid

On Tue, 19 Apr 2016 11:57:32 -0700 "H. Peter Anvin" wrote: > Also, I understand there is one of these bitmaps per ring buffer, and > the ring buffer is in the tens of megabytes. Right, there's only one bitmap per tracing instance, which in most cases is just one (I know of

Re: [RFC][PATCH 2/4] tracing: Use pid bitmap instead of a pid array for set_event_pid

On Tue, 19 Apr 2016 11:57:32 -0700 "H. Peter Anvin" wrote: > Also, I understand there is one of these bitmaps per ring buffer, and > the ring buffer is in the tens of megabytes. Right, there's only one bitmap per tracing instance, which in most cases is just one (I know of people who make

Re: linux-next: Tree for Apr 19 (waketorture.c)

On 04/19/16 12:05, Paul E. McKenney wrote: > On Tue, Apr 19, 2016 at 10:55:21AM -0700, Randy Dunlap wrote: >> On 04/19/16 09:56, Paul E. McKenney wrote: >>> On Tue, Apr 19, 2016 at 09:20:24AM -0700, Randy Dunlap wrote: On 04/18/16 22:13, Stephen Rothwell wrote: > Hi all, > >

Re: linux-next: Tree for Apr 19 (waketorture.c)

On 04/19/16 12:05, Paul E. McKenney wrote: > On Tue, Apr 19, 2016 at 10:55:21AM -0700, Randy Dunlap wrote: >> On 04/19/16 09:56, Paul E. McKenney wrote: >>> On Tue, Apr 19, 2016 at 09:20:24AM -0700, Randy Dunlap wrote: On 04/18/16 22:13, Stephen Rothwell wrote: > Hi all, > >

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin" wrote: >On April 19, 2016 12:03:47 PM PDT, ebied...@xmission.com wrote: >>"H. Peter Anvin" writes: >> - Support for reserving ptys for the system devpts instance using /proc/sys/kernel/pty/reserve needs

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin" wrote: >On April 19, 2016 12:03:47 PM PDT, ebied...@xmission.com wrote: >>"H. Peter Anvin" writes: >> - Support for reserving ptys for the system devpts instance using /proc/sys/kernel/pty/reserve needs to be removed. Eric

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 12:03:47 PM PDT, ebied...@xmission.com wrote: >"H. Peter Anvin" writes: > >>>- Support for reserving ptys for the system devpts instance using >>> /proc/sys/kernel/pty/reserve needs to be removed. >>> >>>Eric >> >> pty capping should probably be a devpts mount

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 12:03:47 PM PDT, ebied...@xmission.com wrote: >"H. Peter Anvin" writes: > >>>- Support for reserving ptys for the system devpts instance using >>> /proc/sys/kernel/pty/reserve needs to be removed. >>> >>>Eric >> >> pty capping should probably be a devpts mount option > >There

Re: Does anyone care about a race free ptsname?

On April 19, 2016 11:44:40 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> What this does is get rid of the horrible notion of having that >> >> struct inode *ptmx_inode >> >> be the interface between the pty code and devpts. By de-emphasizing

Re: Does anyone care about a race free ptsname?

On April 19, 2016 11:44:40 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> What this does is get rid of the horrible notion of having that >> >> struct inode *ptmx_inode >> >> be the interface between the pty code and devpts. By de-emphasizing >the >> ptmx inode, a lot of

Re: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree

[...] > Well I think we still have a very small sample size, the sun4i, sun5i and > sun7i boards (all using the same mmc controller afaik) have the broken-hpi > set, the sun6i and sun8i seem to be working fine (different mmc > controller?). > I'm not so sure it is an eMMC specific problem though.

Re: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree

[...] > Well I think we still have a very small sample size, the sun4i, sun5i and > sun7i boards (all using the same mmc controller afaik) have the broken-hpi > set, the sun6i and sun8i seem to be working fine (different mmc > controller?). > I'm not so sure it is an eMMC specific problem though.

Re: coccinelle: bool if (foo) return true; else return false;

On Tue, 19 Apr 2016, Joe Perches wrote: > There's ~150 of these in the kernel. > > Maybe there's use for this conversion to be added > to scripts/coccinelle/misc/boolreturn.cocci or in > a separate file. > > $ cat booltruefalse.cocci > @@ > identifier fn; > expression e; > typedef bool; >

Re: coccinelle: bool if (foo) return true; else return false;

On Tue, 19 Apr 2016, Joe Perches wrote: > There's ~150 of these in the kernel. > > Maybe there's use for this conversion to be added > to scripts/coccinelle/misc/boolreturn.cocci or in > a separate file. > > $ cat booltruefalse.cocci > @@ > identifier fn; > expression e; > typedef bool; >

Re: [PATCH 14/16] vfs: Implement mount_super_once

"H. Peter Anvin" writes: >>- Support for reserving ptys for the system devpts instance using >> /proc/sys/kernel/pty/reserve needs to be removed. >> >>Eric > > pty capping should probably be a devpts mount option There is a max option so pty capping is a per devpts option. > ,

Re: [PATCH 14/16] vfs: Implement mount_super_once

"H. Peter Anvin" writes: >>- Support for reserving ptys for the system devpts instance using >> /proc/sys/kernel/pty/reserve needs to be removed. >> >>Eric > > pty capping should probably be a devpts mount option There is a max option so pty capping is a per devpts option. > , and perhaps a >

coccinelle: bool if (foo) return true; else return false;

There's ~150 of these in the kernel. Maybe there's use for this conversion to be added to scripts/coccinelle/misc/boolreturn.cocci or in a separate file. $ cat booltruefalse.cocci @@ identifier fn; expression e; typedef bool; symbol true; symbol false; @@ bool fn ( ... ) { <... - if (e)

coccinelle: bool if (foo) return true; else return false;

There's ~150 of these in the kernel. Maybe there's use for this conversion to be added to scripts/coccinelle/misc/boolreturn.cocci or in a separate file. $ cat booltruefalse.cocci @@ identifier fn; expression e; typedef bool; symbol true; symbol false; @@ bool fn ( ... ) { <... - if (e)

Re: linux-next: Tree for Apr 19 (waketorture.c)

On Tue, Apr 19, 2016 at 10:55:21AM -0700, Randy Dunlap wrote: > On 04/19/16 09:56, Paul E. McKenney wrote: > > On Tue, Apr 19, 2016 at 09:20:24AM -0700, Randy Dunlap wrote: > >> On 04/18/16 22:13, Stephen Rothwell wrote: > >>> Hi all, > >>> > >>> Changes since 20160418: > >>> > >> > >> on x86_64:

Re: linux-next: Tree for Apr 19 (waketorture.c)

On Tue, Apr 19, 2016 at 10:55:21AM -0700, Randy Dunlap wrote: > On 04/19/16 09:56, Paul E. McKenney wrote: > > On Tue, Apr 19, 2016 at 09:20:24AM -0700, Randy Dunlap wrote: > >> On 04/18/16 22:13, Stephen Rothwell wrote: > >>> Hi all, > >>> > >>> Changes since 20160418: > >>> > >> > >> on x86_64:

Re: [PATCH 01/16] devpts: Attempting to get it right

"H. Peter Anvin" writes: > It's really too bad we can't just use follow_link :-/ Well follow_link is actually impossible to use as it doesn't exist anymore. The routine now is get_link. ;-) That said just to be certain of where everything stands I took a look to verify that we

Re: [PATCH 01/16] devpts: Attempting to get it right

"H. Peter Anvin" writes: > It's really too bad we can't just use follow_link :-/ Well follow_link is actually impossible to use as it doesn't exist anymore. The routine now is get_link. ;-) That said just to be certain of where everything stands I took a look to verify that we can't. I got

Re: [PATCH net-next V4 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

On Tue, Apr 19, 2016 at 1:12 PM, K. Y. Srinivasan wrote: > On Hyper-V, the VF/PF communication is a via software mediated path > as opposed to the hardware mailbox. Make the necessary > adjustments to support Hyper-V. > > Signed-off-by: K. Y. Srinivasan >

Re: [PATCH net-next V4 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

On Tue, Apr 19, 2016 at 1:12 PM, K. Y. Srinivasan wrote: > On Hyper-V, the VF/PF communication is a via software mediated path > as opposed to the hardware mailbox. Make the necessary > adjustments to support Hyper-V. > > Signed-off-by: K. Y. Srinivasan > --- > V2: Addressed most of the

Re: [PATCH v2 05/13] ARM: dts: db600c: add pmic regulator supplies

On 04/12/2016 02:33 AM, Srinivas Kandagatla wrote: > This patch adds pmic regulator supplies connected on the board. > Rest of the invidual regulators would be added as and when required by > the devices. > > Signed-off-by: Srinivas Kandagatla > Acked-by: Bjorn

Re: [PATCH v2 05/13] ARM: dts: db600c: add pmic regulator supplies

On 04/12/2016 02:33 AM, Srinivas Kandagatla wrote: > This patch adds pmic regulator supplies connected on the board. > Rest of the invidual regulators would be added as and when required by > the devices. > > Signed-off-by: Srinivas Kandagatla > Acked-by: Bjorn Andersson > --- >

Re: [PATCH] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

Hi Hoan, On Tue, Apr 5, 2016 at 11:14 PM, hotran wrote: > ACPI 6.1 has a HW-Reduced Communication Subspace Type 2 intended for > use on HW-Reduce ACPI Platform, which requires read-modify-write sequence > to acknowledge doorbell interrupt. This patch provides the implementation >

Re: [PATCH] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

Hi Hoan, On Tue, Apr 5, 2016 at 11:14 PM, hotran wrote: > ACPI 6.1 has a HW-Reduced Communication Subspace Type 2 intended for > use on HW-Reduce ACPI Platform, which requires read-modify-write sequence > to acknowledge doorbell interrupt. This patch provides the implementation > for the

Re: [PATCH V4 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

On 19/04/16 08:22, Laxman Dewangan wrote: > In some of platform, thermal sensors like NCT thermistors are > connected to the one of ADC channel. The temperature is read by > reading the voltage across the sensor resistance via ADC. Lookup > table for ADC read value to temperature is referred to

Re: [PATCH V4 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

On 19/04/16 08:22, Laxman Dewangan wrote: > In some of platform, thermal sensors like NCT thermistors are > connected to the one of ADC channel. The temperature is read by > reading the voltage across the sensor resistance via ADC. Lookup > table for ADC read value to temperature is referred to

Re: [GIT PULL 00/14] perf/core improvements and fixes

t://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2016-04-16 11:09:57 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo-20160419 > > for you to fetch chan

Re: [GIT PULL 00/14] perf/core improvements and fixes

b/scm/linux/kernel/git/acme/linux into perf/core > (2016-04-16 11:09:57 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo-20160419 > > for you to fetch changes up to 6566feafb4dba4

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 11:22:24 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman >> wrote: >>> The devpts filesystem has a notion of a system or primary instance >of >>> devpts.

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 11:22:24 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman >> wrote: >>> The devpts filesystem has a notion of a system or primary instance >of >>> devpts. To retain the notion of a primary system instance of

Re: [RFC][PATCH 2/4] tracing: Use pid bitmap instead of a pid array for set_event_pid

On April 19, 2016 10:19:47 AM PDT, Steven Rostedt wrote: >On Tue, 19 Apr 2016 16:55:28 + (UTC) >Mathieu Desnoyers wrote: > >> - On Apr 19, 2016, at 10:34 AM, rostedt rost...@goodmis.org >wrote: >> >> > From: Steven Rostedt

Re: [RFC][PATCH 2/4] tracing: Use pid bitmap instead of a pid array for set_event_pid

On April 19, 2016 10:19:47 AM PDT, Steven Rostedt wrote: >On Tue, 19 Apr 2016 16:55:28 + (UTC) >Mathieu Desnoyers wrote: > >> - On Apr 19, 2016, at 10:34 AM, rostedt rost...@goodmis.org >wrote: >> >> > From: Steven Rostedt >> > >> > In order to add the ability to let tasks that are

Re: [PATCH 04/16] devpts: Teach /dev/ptmx to automount the appropriate devpts via path lookup

Jann Horn writes: > On Fri, Apr 15, 2016 at 10:35:20AM -0500, Eric W. Biederman wrote: >> +static inline bool is_dev_ptmx(struct inode *inode) >> +{ >> +return inode->i_rdev == MKDEV(TTYAUX_MAJOR, PTMX_MINOR); >> +} > > I'm not sure whether it matters, but I think a FUSE

Re: [PATCH 04/16] devpts: Teach /dev/ptmx to automount the appropriate devpts via path lookup

Jann Horn writes: > On Fri, Apr 15, 2016 at 10:35:20AM -0500, Eric W. Biederman wrote: >> +static inline bool is_dev_ptmx(struct inode *inode) >> +{ >> +return inode->i_rdev == MKDEV(TTYAUX_MAJOR, PTMX_MINOR); >> +} > > I'm not sure whether it matters, but I think a FUSE filesystem > should

Re: [PATCH] Honor mmap_min_addr with the actual minimum

Ok, I see your point, but it seems that minimum address that a process is allowed to map is mmap_min_addr and not dac_mmap_min_addr. This is because mmap_min_addr can be seen as the max(dac_mmap_min_addr, CONFIG_LSM_MMAP_MIN_ADDR) which is correct (the minimum allowed address) but

Re: [PATCH] Honor mmap_min_addr with the actual minimum

Ok, I see your point, but it seems that minimum address that a process is allowed to map is mmap_min_addr and not dac_mmap_min_addr. This is because mmap_min_addr can be seen as the max(dac_mmap_min_addr, CONFIG_LSM_MMAP_MIN_ADDR) which is correct (the minimum allowed address) but

Does anyone care about a race free ptsname?

Linus Torvalds writes: > What this does is get rid of the horrible notion of having that > > struct inode *ptmx_inode > > be the interface between the pty code and devpts. By de-emphasizing the > ptmx inode, a lot of things actually get cleaner, and we will

Does anyone care about a race free ptsname?

Linus Torvalds writes: > What this does is get rid of the horrible notion of having that > > struct inode *ptmx_inode > > be the interface between the pty code and devpts. By de-emphasizing the > ptmx inode, a lot of things actually get cleaner, and we will have a much > saner way forward.

Re: [PATCH 3/4] soc: qcom: spm: use const and __initconst for qcom_cpuidle_ops

On Tue, Mar 22, 2016 at 10:42:42PM +0800, Jisheng Zhang wrote: > The qcom_cpuidle_ops structures is not over-written, so add "const" > qualifier and replace __initdata with __initconst. > > Signed-off-by: Jisheng Zhang Acked-by: Andy Gross

Re: [PATCH 3/4] soc: qcom: spm: use const and __initconst for qcom_cpuidle_ops

On Tue, Mar 22, 2016 at 10:42:42PM +0800, Jisheng Zhang wrote: > The qcom_cpuidle_ops structures is not over-written, so add "const" > qualifier and replace __initdata with __initconst. > > Signed-off-by: Jisheng Zhang Acked-by: Andy Gross

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 11:22:24 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman >> wrote: >>> The devpts filesystem has a notion of a system or primary instance >of >>> devpts.

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 11:22:24 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman >> wrote: >>> The devpts filesystem has a notion of a system or primary instance >of >>> devpts. To retain the notion of a primary system instance of

Re: [PATCH 1/2] MAINTAINERS: Add maintainer for OMAP DRM driver

Hi Tomi, Just a humble suggestion/nitpick. On 18 April 2016 at 16:46, Tomi Valkeinen wrote: > Add Tomi Valkeinen as omapdrm maintainer. > > Signed-off-by: Tomi Valkeinen > Cc: Rob Clark > Cc: Laurent Pinchart

Re: [PATCH 1/2] MAINTAINERS: Add maintainer for OMAP DRM driver

Hi Tomi, Just a humble suggestion/nitpick. On 18 April 2016 at 16:46, Tomi Valkeinen wrote: > Add Tomi Valkeinen as omapdrm maintainer. > > Signed-off-by: Tomi Valkeinen > Cc: Rob Clark > Cc: Laurent Pinchart > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git

Re: [PATCH] tpm_crb: fix mapping of the buffers

On Tue, Apr 19, 2016 at 11:09:53AM -0600, Jason Gunthorpe wrote: > On Tue, Apr 19, 2016 at 12:54:18PM +0300, Jarkko Sakkinen wrote: > > Cc: sta...@vger.kernel.org > > Fixes: 1bd047be37d9 ("tpm_crb: Use devm_ioremap_resource") > > Signed-off-by: Jarkko Sakkinen > >

Re: [PATCH] tpm_crb: fix mapping of the buffers

On Tue, Apr 19, 2016 at 11:09:53AM -0600, Jason Gunthorpe wrote: > On Tue, Apr 19, 2016 at 12:54:18PM +0300, Jarkko Sakkinen wrote: > > Cc: sta...@vger.kernel.org > > Fixes: 1bd047be37d9 ("tpm_crb: Use devm_ioremap_resource") > > Signed-off-by: Jarkko Sakkinen > > drivers/char/tpm/tpm_crb.c | 39

Re: [PATCHv2] wlcore: spi: add wl18xx support

On Tue, Apr 19, 2016 at 06:04:49PM +, Reizer, Eyal wrote: > Thanks! Glad the illustration helped. > I will try it out again as if i recall cotrectly, i did try that l, and it > didnt produce the correct waveform, but perhaps i didnt understand the usage > of .cs_change correctly. > Will

Re: [PATCHv2] wlcore: spi: add wl18xx support

On Tue, Apr 19, 2016 at 06:04:49PM +, Reizer, Eyal wrote: > Thanks! Glad the illustration helped. > I will try it out again as if i recall cotrectly, i did try that l, and it > didnt produce the correct waveform, but perhaps i didnt understand the usage > of .cs_change correctly. > Will

Re: [PATCH v2 1/1] drivers: net: cpsw: Prevent NUll pointer dereference with two PHYs

On 04/19/2016 08:14 PM, David Rivshin (Allworx) wrote: On Tue, 19 Apr 2016 18:44:41 +0300 Grygorii Strashko wrote: On 04/19/2016 06:01 PM, David Rivshin (Allworx) wrote: On Tue, 19 Apr 2016 17:41:07 +0300 Grygorii Strashko wrote: Hi, On

Re: [PATCH v2 1/1] drivers: net: cpsw: Prevent NUll pointer dereference with two PHYs

On 04/19/2016 08:14 PM, David Rivshin (Allworx) wrote: On Tue, 19 Apr 2016 18:44:41 +0300 Grygorii Strashko wrote: On 04/19/2016 06:01 PM, David Rivshin (Allworx) wrote: On Tue, 19 Apr 2016 17:41:07 +0300 Grygorii Strashko wrote: Hi, On 04/19/2016 04:56 PM, Andrew Goodbody wrote: Adding

Re: [PATCH V3 01/29] bitops: add parity functions

> Add generic odd parity functions, adapted from > "https://graphics.stanford.edu/~seander/bithacks.html#ParityParallel; Given a PARITY_MAGIC of 0x6996, this is even parity, not odd. (Which it should be; an XOR of all bits is the "natural" form.)

Re: [PATCH V3 01/29] bitops: add parity functions

> Add generic odd parity functions, adapted from > "https://graphics.stanford.edu/~seander/bithacks.html#ParityParallel; Given a PARITY_MAGIC of 0x6996, this is even parity, not odd. (Which it should be; an XOR of all bits is the "natural" form.)

Re: [PATCH v4 00/14] ACPI NUMA support for ARM64

There is a build problem on ia64 that slipped by. It is easy to correct, so I will have to send another version of the patches. Sorry for the noise, David Daney On 04/18/2016 02:13 PM, David Daney wrote: From: David Daney Based on v16 of device-tree NUMA patch set

Re: [PATCH v4 00/14] ACPI NUMA support for ARM64

There is a build problem on ia64 that slipped by. It is easy to correct, so I will have to send another version of the patches. Sorry for the noise, David Daney On 04/18/2016 02:13 PM, David Daney wrote: From: David Daney Based on v16 of device-tree NUMA patch set for arm64 [1],this

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

On Mon, Apr 18, 2016 at 11:45:49PM -0400, Ira Weiny wrote: > I'm a bit confused by what you are suggesting that "people will have to patch > the driver with some vendor version if they really need it."? > > Could you elaborate? There are lots of drivers where we simply did not accept these

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

On Mon, Apr 18, 2016 at 11:45:49PM -0400, Ira Weiny wrote: > I'm a bit confused by what you are suggesting that "people will have to patch > the driver with some vendor version if they really need it."? > > Could you elaborate? There are lots of drivers where we simply did not accept these

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/19/2016 2:22 PM, Christoph Hellwig wrote: > What I think we need is something like the patch below. In the long > ru nwe should also kill the mlx4_buf structure which now is pretty > pointless. Maybe; this could be the correct approach if we can guarantee that the architecture can allocate

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/19/2016 2:22 PM, Christoph Hellwig wrote: > What I think we need is something like the patch below. In the long > ru nwe should also kill the mlx4_buf structure which now is pretty > pointless. Maybe; this could be the correct approach if we can guarantee that the architecture can allocate

Re: [PATCH 14/16] vfs: Implement mount_super_once

Linus Torvalds writes: > On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman > wrote: >> The devpts filesystem has a notion of a system or primary instance of >> devpts. To retain the notion of a primary system instance of devpts >> the code

[PATCH net-next V4 1/2] ethernet: intel: Add the device ID's presented while running on Hyper-V

Intel SR-IOV cards present different ID when running on Hyper-V. Add the device IDs presented while running on Hyper-V. Signed-off-by: K. Y. Srinivasan --- V4: No change from V1 drivers/net/ethernet/intel/ixgbevf/defines.h |5 + 1 files changed, 5

Re: [PATCH 14/16] vfs: Implement mount_super_once

Linus Torvalds writes: > On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman > wrote: >> The devpts filesystem has a notion of a system or primary instance of >> devpts. To retain the notion of a primary system instance of devpts >> the code needs a way to allow userspace to mount the

[PATCH net-next V4 1/2] ethernet: intel: Add the device ID's presented while running on Hyper-V

Intel SR-IOV cards present different ID when running on Hyper-V. Add the device IDs presented while running on Hyper-V. Signed-off-by: K. Y. Srinivasan --- V4: No change from V1 drivers/net/ethernet/intel/ixgbevf/defines.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-)

[PATCH net-next V4 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

On Hyper-V, the VF/PF communication is a via software mediated path as opposed to the hardware mailbox. Make the necessary adjustments to support Hyper-V. Signed-off-by: K. Y. Srinivasan --- V2: Addressed most of the comments from Alexander Duyck

[PATCH net-next V4 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

On Hyper-V, the VF/PF communication is a via software mediated path as opposed to the hardware mailbox. Make the necessary adjustments to support Hyper-V. Signed-off-by: K. Y. Srinivasan --- V2: Addressed most of the comments from Alexander Duyck and Rustad, Mark

[PATCH net-next V4 0/2] ethernet: intel: Support Hyper-V hosts

Make adjustments to the Intel 10G VF driver to support running on Hyper-V hosts. K. Y. Srinivasan (2): ethernet: intel: Add the device ID's presented while running on Hyper-V intel: ixgbevf: Support Windows hosts (Hyper-V) drivers/net/ethernet/intel/ixgbevf/defines.h |5 +

[PATCH net-next V4 0/2] ethernet: intel: Support Hyper-V hosts

Make adjustments to the Intel 10G VF driver to support running on Hyper-V hosts. K. Y. Srinivasan (2): ethernet: intel: Add the device ID's presented while running on Hyper-V intel: ixgbevf: Support Windows hosts (Hyper-V) drivers/net/ethernet/intel/ixgbevf/defines.h |5 +

[PATCH v2 2/2] hwmon: Add support for INA3221 Triple Current/Voltage Monitors

Add support for the the INA3221 26v capable, Triple channel, Bi-Directional, Zero-Drift, Low-/High-Side, Current/Voltage Monitor with I2C interface. Signed-off-by: Andrew F. Davis --- Documentation/hwmon/ina3221 | 35 drivers/hwmon/Kconfig | 11 ++

[PATCH v2 2/2] hwmon: Add support for INA3221 Triple Current/Voltage Monitors

Add support for the the INA3221 26v capable, Triple channel, Bi-Directional, Zero-Drift, Low-/High-Side, Current/Voltage Monitor with I2C interface. Signed-off-by: Andrew F. Davis --- Documentation/hwmon/ina3221 | 35 drivers/hwmon/Kconfig | 11 ++ drivers/hwmon/Makefile | 1

[PATCH v2 1/2] hwmon: Define binding for the INA3221 hwmon driver

Define a binding for the INA3221 Triple Current/Voltage Monitor. Signed-off-by: Andrew F. Davis --- Documentation/devicetree/bindings/hwmon/ina3221.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/ina3221.txt

[PATCH v2 0/2] Add support for INA3221 Triple Current/Voltage Monitors

Hello all, This series adds support for the INA3221 Triple Current/Voltage Monitor. Changes from v1: - rearranged and renumbered sysfs enteries - added reading alert bits to sysfs - removed internal power calculation - added DT setting of shunt resistors - various other minor fixups

[PATCH v2 1/2] hwmon: Define binding for the INA3221 hwmon driver

Define a binding for the INA3221 Triple Current/Voltage Monitor. Signed-off-by: Andrew F. Davis --- Documentation/devicetree/bindings/hwmon/ina3221.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/ina3221.txt diff --git

[PATCH v2 0/2] Add support for INA3221 Triple Current/Voltage Monitors

Hello all, This series adds support for the INA3221 Triple Current/Voltage Monitor. Changes from v1: - rearranged and renumbered sysfs enteries - added reading alert bits to sysfs - removed internal power calculation - added DT setting of shunt resistors - various other minor fixups

Re: [PATCH 6/6] cifs: don't bother with kmap on read_pages side

On Sat, 2016-04-09 at 21:53 +0100, Al Viro wrote: > just do ITER_BVEC recvmsg > > Signed-off-by: Al Viro > --- >  fs/cifs/cifsproto.h |  7 +++--- >  fs/cifs/connect.c   | 65 > - >  fs/cifs/file.c  | 53

Re: [PATCH 6/6] cifs: don't bother with kmap on read_pages side

On Sat, 2016-04-09 at 21:53 +0100, Al Viro wrote: > just do ITER_BVEC recvmsg > > Signed-off-by: Al Viro > --- >  fs/cifs/cifsproto.h |  7 +++--- >  fs/cifs/connect.c   | 65 > - >  fs/cifs/file.c  | 53

Re: [PATCH] rtl8xxxu: hide unused tables

Kalle Valo writes: > Jes Sorensen writes: > >> Arnd Bergmann writes: >>> The references to some arrays in the rtl8xxxu driver were moved inside >>> of an #ifdef, but the symbols remain outside, resulting in build warnings: >>> >>>

Re: [PATCH] rtl8xxxu: hide unused tables

Kalle Valo writes: > Jes Sorensen writes: > >> Arnd Bergmann writes: >>> The references to some arrays in the rtl8xxxu driver were moved inside >>> of an #ifdef, but the symbols remain outside, resulting in build warnings: >>> >>> rtl8xxxu/rtl8xxxu.c:1506:33: error: >>>

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On Mon, Apr 18, 2016 at 10:26:10PM +0200, Jan Kara wrote: > On Fri 15-04-16 22:05:31, Andrew Morton wrote: > > On Thu, 14 Apr 2016 10:48:29 -0600 Toshi Kani wrote: > > > > > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page > > > size. This feature relies on

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On Mon, Apr 18, 2016 at 10:26:10PM +0200, Jan Kara wrote: > On Fri 15-04-16 22:05:31, Andrew Morton wrote: > > On Thu, 14 Apr 2016 10:48:29 -0600 Toshi Kani wrote: > > > > > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page > > > size. This feature relies on both mmap virtual

Re: [PATCH] clocksource/drivers/tango-xtal: Fix incorrect test

On 19/04/2016 19:31, Daniel Lezcano wrote: > On Tue, Apr 19, 2016 at 07:21:20PM +0200, Mason wrote: >> On 19/04/2016 16:59, Daniel Lezcano wrote: >>> On Tue, Apr 19, 2016 at 04:05:19PM +0200, Mason wrote: On 19/04/2016 15:13, Daniel Lezcano wrote: > On Tue, Apr 19, 2016 at 02:15:15PM

Re: [PATCH] clocksource/drivers/tango-xtal: Fix incorrect test

On 19/04/2016 19:31, Daniel Lezcano wrote: > On Tue, Apr 19, 2016 at 07:21:20PM +0200, Mason wrote: >> On 19/04/2016 16:59, Daniel Lezcano wrote: >>> On Tue, Apr 19, 2016 at 04:05:19PM +0200, Mason wrote: On 19/04/2016 15:13, Daniel Lezcano wrote: > On Tue, Apr 19, 2016 at 02:15:15PM

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

What I think we need is something like the patch below. In the long ru nwe should also kill the mlx4_buf structure which now is pretty pointless. --- >From a493881d2a6c90152d3daabb7b6b3afd1d254d78 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Tue, 19 Apr 2016 14:12:14

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

What I think we need is something like the patch below. In the long ru nwe should also kill the mlx4_buf structure which now is pretty pointless. --- >From a493881d2a6c90152d3daabb7b6b3afd1d254d78 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Tue, 19 Apr 2016 14:12:14 -0400 Subject:

Re: [PATCH] mmc: bcm2835: fix platform_no_drv_owner.cocci warnings

Julia Lawall writes: > Remove .owner field if calls are used which set it automatically > > Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Acked-by: Eric Anholt signature.asc Description: PGP signature

Re: [PATCH] mmc: bcm2835: fix platform_no_drv_owner.cocci warnings

Julia Lawall writes: > Remove .owner field if calls are used which set it automatically > > Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Acked-by: Eric Anholt signature.asc Description: PGP signature

[PATCH] drivers: net: cpsw: fix wrong regs access in cpsw_ndo_open

The cpsw_ndo_open() could try to access CPSW registers before calling pm_runtime_get_sync(). This will trigger L3 error: WARNING: CPU: 0 PID: 21 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x220/0x34c() 4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_FAST (Idle): Data

[PATCH] drivers: net: cpsw: fix wrong regs access in cpsw_ndo_open

The cpsw_ndo_open() could try to access CPSW registers before calling pm_runtime_get_sync(). This will trigger L3 error: WARNING: CPU: 0 PID: 21 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x220/0x34c() 4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_FAST (Idle): Data

Re: [PATCH v7 7/8] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

Hi, [auto build test ERROR on tip/irq/core] [also build test ERROR on v4.6-rc4 next-20160419] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64

Re: [PATCH v7 7/8] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

Hi, [auto build test ERROR on tip/irq/core] [also build test ERROR on v4.6-rc4 next-20160419] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 10:49 AM, Michael S. Tsirkin wrote: > On Tue, Apr 19, 2016 at 12:26:44PM -0400, David Woodhouse wrote: >> On Tue, 2016-04-19 at 19:20 +0300, Michael S. Tsirkin wrote: >> > >> > > I thought that PLATFORM served that purpose. Woudn't the host >> > >

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 10:49 AM, Michael S. Tsirkin wrote: > On Tue, Apr 19, 2016 at 12:26:44PM -0400, David Woodhouse wrote: >> On Tue, 2016-04-19 at 19:20 +0300, Michael S. Tsirkin wrote: >> > >> > > I thought that PLATFORM served that purpose. Woudn't the host >> > > advertise PLATFORM

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