Re: [PATCH 1/2] net/ipv6/addrconf: simplify sysctl registration

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:41:10 +0300 > Struct ctl_table_header holds pointer to sysctl table which could be used > for freeing it after unregistration. IPv4 sysctls already use that. > Remove redundant NULL assignment: ndev allocated using

Re: [PATCH 1/2] net/ipv6/addrconf: simplify sysctl registration

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:41:10 +0300 > Struct ctl_table_header holds pointer to sysctl table which could be used > for freeing it after unregistration. IPv4 sysctls already use that. > Remove redundant NULL assignment: ndev allocated using kzalloc. > > This also

Re: [PATCH 2/2] net/ipv6/addrconf: fix sysctl table indentation

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:41:17 +0300 > Separated from previous patch for readability. > > Signed-off-by: Konstantin Khlebnikov Applied.

Re: [PATCH 2/2] net/ipv6/addrconf: fix sysctl table indentation

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:41:17 +0300 > Separated from previous patch for readability. > > Signed-off-by: Konstantin Khlebnikov Applied.

Re: [PATCH] cls_cgroup: get sk_classid only from full sockets

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:37:10 +0300 > skb->sk could point to timewait or request socket which has no sk_classid. > Detected as "BUG: KASAN: slab-out-of-bounds in cls_cgroup_classify". > > Signed-off-by: Konstantin Khlebnikov

Re: [PATCH] cls_cgroup: get sk_classid only from full sockets

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:37:10 +0300 > skb->sk could point to timewait or request socket which has no sk_classid. > Detected as "BUG: KASAN: slab-out-of-bounds in cls_cgroup_classify". > > Signed-off-by: Konstantin Khlebnikov Applied, thank you.

Re: [PATCH] net/mlx4_en: allocate non 0-order pages for RX ring with __GFP_NOMEMALLOC

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:33:54 +0300 > High order pages are optional here since commit 51151a16a60f ("mlx4: allow > order-0 memory allocations in RX path"), so here is no reason for depleting > reserves. Generic __netdev_alloc_frag()

Re: [PATCH] net/mlx4_en: do batched put_page using atomic_sub

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:34:05 +0300 > This patch fixes couple error paths after allocation failures. > Atomic set of page reference counter is safe only if it is zero, > otherwise set can race with any speculative get_page_unless_zero. >

Re: [PATCH] net/mlx4_en: allocate non 0-order pages for RX ring with __GFP_NOMEMALLOC

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:33:54 +0300 > High order pages are optional here since commit 51151a16a60f ("mlx4: allow > order-0 memory allocations in RX path"), so here is no reason for depleting > reserves. Generic __netdev_alloc_frag() implements the same logic. > >

Re: [PATCH] net/mlx4_en: do batched put_page using atomic_sub

From: Konstantin Khlebnikov Date: Mon, 18 Apr 2016 14:34:05 +0300 > This patch fixes couple error paths after allocation failures. > Atomic set of page reference counter is safe only if it is zero, > otherwise set can race with any speculative get_page_unless_zero. > > Signed-off-by: Konstantin

Re: [BUG] machine check Oops on Alpha

On Mon, Apr 18, 2016 at 09:52:43PM -0500, Bob Tracy wrote: > 4.6.0-rc4 build complete, including suggested (by Alan Young) "Verbose > Machine Checks" option set to level 2 by default. System rebooted, and > now we wait... Thanks for everyone's continued patience. Within three minutes of

Re: [BUG] machine check Oops on Alpha

On Mon, Apr 18, 2016 at 09:52:43PM -0500, Bob Tracy wrote: > 4.6.0-rc4 build complete, including suggested (by Alan Young) "Verbose > Machine Checks" option set to level 2 by default. System rebooted, and > now we wait... Thanks for everyone's continued patience. Within three minutes of

Re: [PATCH 0/2] PCI: Skylake PCH ACS quirks

On Thu, Mar 31, 2016 at 04:34:26PM -0600, Alex Williamson wrote: > Intel Skylake systems attempted to implement ACS on the PCH root > ports, but it came out a wee bit off. As noted in the second patch > and the datasheets from Intel, dwords were used for the ACS > capability and control words, so

Re: [PATCH 0/2] PCI: Skylake PCH ACS quirks

On Thu, Mar 31, 2016 at 04:34:26PM -0600, Alex Williamson wrote: > Intel Skylake systems attempted to implement ACS on the PCH root > ports, but it came out a wee bit off. As noted in the second patch > and the datasheets from Intel, dwords were used for the ACS > capability and control words, so

Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages

On 4/19/2016 9:50 AM, Andrea Arcangeli wrote: Hello, On Mon, Apr 18, 2016 at 03:55:44PM -0700, Shi, Yang wrote: Hi Kirill, Finally, I got some time to look into and try yours and Hugh's patches, got two problems. One thing that come to mind to test is this: qemu with -machine accel=kvm

Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages

On 4/19/2016 9:50 AM, Andrea Arcangeli wrote: Hello, On Mon, Apr 18, 2016 at 03:55:44PM -0700, Shi, Yang wrote: Hi Kirill, Finally, I got some time to look into and try yours and Hugh's patches, got two problems. One thing that come to mind to test is this: qemu with -machine accel=kvm

Re: Does anyone care about a race free ptsname?

On 04/19/2016 04:23 PM, Linus Torvalds wrote: > On Tue, Apr 19, 2016 at 11:44 AM, Eric W. Biederman > wrote: >> >> I will take a look in a minute. Before I do that I want to mention >> why I care about /dev/pts/ptmx. >> >> There is a posix function that is widely used

Re: Does anyone care about a race free ptsname?

On 04/19/2016 04:23 PM, Linus Torvalds wrote: > On Tue, Apr 19, 2016 at 11:44 AM, Eric W. Biederman > wrote: >> >> I will take a look in a minute. Before I do that I want to mention >> why I care about /dev/pts/ptmx. >> >> There is a posix function that is widely used called ptsname. It's >>

[BUG linux-next] Kernel panic found with linux-next-20160414

Hi folks, When I ran ltp on linux-next-20160414 on my ARM64 machine, I got the below kernel panic: Unable to handle kernel paging request at virtual address ffc007846000 pgd = ffc01e21d000 [ffc007846000] *pgd=, *pud= Internal error: Oops: 9647

[BUG linux-next] Kernel panic found with linux-next-20160414

Hi folks, When I ran ltp on linux-next-20160414 on my ARM64 machine, I got the below kernel panic: Unable to handle kernel paging request at virtual address ffc007846000 pgd = ffc01e21d000 [ffc007846000] *pgd=, *pud= Internal error: Oops: 9647

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

On Tue, 19 Apr 2016 18:43:39 -0400 (EDT) David Miller wrote: > From: Grygorii Strashko > Date: Tue, 19 Apr 2016 21:44:09 +0300 > > > May be you can send revert + your patch 1 (only fix for this issue). > > > > Dave, Does that sound good to you?

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

On Tue, 19 Apr 2016 18:43:39 -0400 (EDT) David Miller wrote: > From: Grygorii Strashko > Date: Tue, 19 Apr 2016 21:44:09 +0300 > > > May be you can send revert + your patch 1 (only fix for this issue). > > > > Dave, Does that sound good to you? > > Sure. OK, I will hopefully have that

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

On Tue, Apr 19, 2016 at 3:06 PM, Eric W. Biederman wrote: > > I have work inspired by this rolled into my code. I will post shortly > after a little more testing. Actually, I have a slightly fixed version in my tree. I've been running this on my own machines for a few

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

On Tue, Apr 19, 2016 at 3:06 PM, Eric W. Biederman wrote: > > I have work inspired by this rolled into my code. I will post shortly > after a little more testing. Actually, I have a slightly fixed version in my tree. I've been running this on my own machines for a few days, just to verify,

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

On Tue, Apr 19, 2016 at 11:22 AM, Eric W. Biederman wrote: > Linus Torvalds writes: >> >> No. >> >> We want to get *rid* of the idiotic "primary instance" crap. > > That is actually pretty much the opposite of what you said last time, > but

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

On Tue, Apr 19, 2016 at 11:22 AM, Eric W. Biederman wrote: > Linus Torvalds writes: >> >> No. >> >> We want to get *rid* of the idiotic "primary instance" crap. > > That is actually pretty much the opposite of what you said last time, > but having looked at the cost to maintian a "primary

RE: [PATCH 2/2 v2] arm64: dts: ls2080a: fsl-mc dt node updates

> -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: Sunday, April 17, 2016 9:56 PM > To: Stuart Yoder > Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > german.riv...@freescale.com; > linux-kernel@vger.kernel.org;

RE: [PATCH 2/2 v2] arm64: dts: ls2080a: fsl-mc dt node updates

> -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: Sunday, April 17, 2016 9:56 PM > To: Stuart Yoder > Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > german.riv...@freescale.com; > linux-kernel@vger.kernel.org; robh...@kernel.org;

Re: Does anyone care about a race free ptsname?

On Tue, Apr 19, 2016 at 11:44 AM, Eric W. Biederman wrote: > > I will take a look in a minute. Before I do that I want to mention > why I care about /dev/pts/ptmx. > > There is a posix function that is widely used called ptsname. It's > function is to take a master file

regression: 3a878c430fd6 ("tty: serial: msm: Add TX DMA support") drops data

Hi Ivan, It appears that I have found a regression caused by 3a878c430fd6 ("tty: serial: msm: Add TX DMA support"). When I cat a file slightly larger than 126000 bytes on the console, viewed via minicom connected to the serial port, I am losing random chunks of data, almost always three bytes in

Re: Does anyone care about a race free ptsname?

On Tue, Apr 19, 2016 at 11:44 AM, Eric W. Biederman wrote: > > I will take a look in a minute. Before I do that I want to mention > why I care about /dev/pts/ptmx. > > There is a posix function that is widely used called ptsname. It's > function is to take a master file descriptor and returns

regression: 3a878c430fd6 ("tty: serial: msm: Add TX DMA support") drops data

Hi Ivan, It appears that I have found a regression caused by 3a878c430fd6 ("tty: serial: msm: Add TX DMA support"). When I cat a file slightly larger than 126000 bytes on the console, viewed via minicom connected to the serial port, I am losing random chunks of data, almost always three bytes in

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

On Tue, 19 Apr 2016 22:59:14 + (UTC) Mathieu Desnoyers wrote: > - On Apr 19, 2016, at 6:49 PM, rostedt rost...@goodmis.org wrote: > > > On Tue, 19 Apr 2016 21:22:21 + (UTC) > > Mathieu Desnoyers wrote: > > > >> It

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

On Tue, 19 Apr 2016 22:59:14 + (UTC) Mathieu Desnoyers wrote: > - On Apr 19, 2016, at 6:49 PM, rostedt rost...@goodmis.org wrote: > > > On Tue, 19 Apr 2016 21:22:21 + (UTC) > > Mathieu Desnoyers wrote: > > > >> It makes sense. Anyway, looking back at my own implementation, I

Re: [PATCH v3 1/2] ext4: Pass in DIO_SKIP_DIO_COUNT flag if inode_dio_begin() called

On Mon, Apr 18, 2016 at 03:46:46PM -0400, Waiman Long wrote: > On 04/15/2016 06:19 PM, Dave Chinner wrote: > >On Fri, Apr 15, 2016 at 01:17:41PM -0400, Waiman Long wrote: > >>On 04/15/2016 04:17 AM, Dave Chinner wrote: > >>>On Thu, Apr 14, 2016 at 12:21:13PM -0400, Waiman Long wrote: > What

Re: [PATCH v3 1/2] ext4: Pass in DIO_SKIP_DIO_COUNT flag if inode_dio_begin() called

On Mon, Apr 18, 2016 at 03:46:46PM -0400, Waiman Long wrote: > On 04/15/2016 06:19 PM, Dave Chinner wrote: > >On Fri, Apr 15, 2016 at 01:17:41PM -0400, Waiman Long wrote: > >>On 04/15/2016 04:17 AM, Dave Chinner wrote: > >>>On Thu, Apr 14, 2016 at 12:21:13PM -0400, Waiman Long wrote: > What

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

- On Apr 19, 2016, at 6:49 PM, rostedt rost...@goodmis.org wrote: > On Tue, 19 Apr 2016 21:22:21 + (UTC) > Mathieu Desnoyers wrote: > >> It makes sense. Anyway, looking back at my own implementation, I have >> an array of 64 hlist_head entries (64 * 8 =

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

- On Apr 19, 2016, at 6:49 PM, rostedt rost...@goodmis.org wrote: > On Tue, 19 Apr 2016 21:22:21 + (UTC) > Mathieu Desnoyers wrote: > >> It makes sense. Anyway, looking back at my own implementation, I have >> an array of 64 hlist_head entries (64 * 8 = 512 bytes), typically >>

Re: [fuse-devel] [PATCH] fuse: Fix fuse_get_user_pages() return value

Hi Seth, On 04/19/2016 03:43 PM, Seth Forshee wrote: fuse_direct_io() expects this to return either 0 or a negative error code, but on success it may return a positive value. fuse_direct_io() may return this same value when the subsequent I/O operation doesn't transfer any data, which means that

Re: [fuse-devel] [PATCH] fuse: Fix fuse_get_user_pages() return value

Hi Seth, On 04/19/2016 03:43 PM, Seth Forshee wrote: fuse_direct_io() expects this to return either 0 or a negative error code, but on success it may return a positive value. fuse_direct_io() may return this same value when the subsequent I/O operation doesn't transfer any data, which means that

Re: [PATCH] rtc: ds1307: Use irq when available for wakeup-source device

On 19/04/2016 at 11:23:54 -0500, Nishanth Menon wrote : > With commit 8bc2a40730ec ("rtc: ds1307: add support for the > DT property 'wakeup-source'") we lost the ability for rtc irq > functionality for devices that are actually hooked on a real IRQ > line and have capability to wakeup as well.

Re: [PATCH] rtc: ds1307: Use irq when available for wakeup-source device

On 19/04/2016 at 11:23:54 -0500, Nishanth Menon wrote : > With commit 8bc2a40730ec ("rtc: ds1307: add support for the > DT property 'wakeup-source'") we lost the ability for rtc irq > functionality for devices that are actually hooked on a real IRQ > line and have capability to wakeup as well.

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

On 04/19/2016 02:12 PM, Ashwin Chaugule wrote: > + Ryan > > Hi Al, > > On 18 April 2016 at 20:11, Al Stone wrote: >> When CPPC is being used by ACPI on arm64, user space tools such as >> cpupower report CPU frequency values from sysfs that are incorrect. >> >> What the driver

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

On 04/19/2016 02:12 PM, Ashwin Chaugule wrote: > + Ryan > > Hi Al, > > On 18 April 2016 at 20:11, Al Stone wrote: >> When CPPC is being used by ACPI on arm64, user space tools such as >> cpupower report CPU frequency values from sysfs that are incorrect. >> >> What the driver was doing was

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

On Tue, Apr 19, 2016 at 09:18:55AM +0200, Geert Uytterhoeven wrote: > On Wed, Apr 6, 2016 at 2:52 PM, Sjoerd Simons > wrote: > > clk_get on a disabled clock node will return EPROBE_DEFER, which can > > cause drivers to be deferred forever if such clocks are

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

On Tue, Apr 19, 2016 at 09:18:55AM +0200, Geert Uytterhoeven wrote: > On Wed, Apr 6, 2016 at 2:52 PM, Sjoerd Simons > wrote: > > clk_get on a disabled clock node will return EPROBE_DEFER, which can > > cause drivers to be deferred forever if such clocks are referenced in > > their clocks

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

On Tue, 19 Apr 2016 21:22:21 + (UTC) Mathieu Desnoyers wrote: > It makes sense. Anyway, looking back at my own implementation, I have > an array of 64 hlist_head entries (64 * 8 = 512 bytes), typically > populated by NULL pointers. It's only a factor 8 smaller

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

On Tue, 19 Apr 2016 21:22:21 + (UTC) Mathieu Desnoyers wrote: > It makes sense. Anyway, looking back at my own implementation, I have > an array of 64 hlist_head entries (64 * 8 = 512 bytes), typically > populated by NULL pointers. It's only a factor 8 smaller than the > bitmap, so it's not

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

RDPID is a new instruction that reads MSR_TSC_AUX quickly. This should be considerably faster than reading the GDT. Add a cpufeature for it and use it from __vdso_getcpu when available. Signed-off-by: Andy Lutomirski --- I don't have a Cannonlake CPU (or whatever CPU I'd need

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

RDPID is a new instruction that reads MSR_TSC_AUX quickly. This should be considerably faster than reading the GDT. Add a cpufeature for it and use it from __vdso_getcpu when available. Signed-off-by: Andy Lutomirski --- I don't have a Cannonlake CPU (or whatever CPU I'd need for this). Could

Re: [PATCH] rtc-pcf2123: use sign_extend32() for sign extension

Please always include a commit message else, I'm fine with the patch. On 18/04/2016 at 12:17:44 +0200, Martin Kepplinger wrote : > Signed-off-by: Martin Kepplinger > --- > drivers/rtc/rtc-pcf2123.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH] rtc-pcf2123: use sign_extend32() for sign extension

Please always include a commit message else, I'm fine with the patch. On 18/04/2016 at 12:17:44 +0200, Martin Kepplinger wrote : > Signed-off-by: Martin Kepplinger > --- > drivers/rtc/rtc-pcf2123.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

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

From: Grygorii Strashko Date: Tue, 19 Apr 2016 21:44:09 +0300 > May be you can send revert + your patch 1 (only fix for this issue). > > Dave, Does that sound good to you? Sure.

[PATCH] fuse: Fix fuse_get_user_pages() return value

fuse_direct_io() expects this to return either 0 or a negative error code, but on success it may return a positive value. fuse_direct_io() may return this same value when the subsequent I/O operation doesn't transfer any data, which means that it will return a positive value when no bytes were

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

From: Grygorii Strashko Date: Tue, 19 Apr 2016 21:44:09 +0300 > May be you can send revert + your patch 1 (only fix for this issue). > > Dave, Does that sound good to you? Sure.

[PATCH] fuse: Fix fuse_get_user_pages() return value

fuse_direct_io() expects this to return either 0 or a negative error code, but on success it may return a positive value. fuse_direct_io() may return this same value when the subsequent I/O operation doesn't transfer any data, which means that it will return a positive value when no bytes were

[RFC PATCH v2 04/10] acpi: add support for ACPI reconfiguration notifiers

Add support for ACPI reconfiguration notifiers to allow subsystems to react to changes in the ACPI tables that happen after the initial enumeration. This is similar with the way dynamic device tree notifications work. The reconfigure notifications supported for now are device add and device

[RFC PATCH v2 04/10] acpi: add support for ACPI reconfiguration notifiers

Add support for ACPI reconfiguration notifiers to allow subsystems to react to changes in the ACPI tables that happen after the initial enumeration. This is similar with the way dynamic device tree notifications work. The reconfigure notifications supported for now are device add and device

[RFC PATCH v2 02/10] acpi: decouple initrd table install from CONFIG_ACPI_INITRD_TABLE_OVERRIDE

The ACPI override and overlay functionality is different, with the latter being more then a debug option. Allow loading of ACPI tables from initrd even if CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not selected. The patch also switches to using TAINT_OVERLAY_ACPI_TABLE and adds documentation about how

[RFC PATCH v2 02/10] acpi: decouple initrd table install from CONFIG_ACPI_INITRD_TABLE_OVERRIDE

The ACPI override and overlay functionality is different, with the latter being more then a debug option. Allow loading of ACPI tables from initrd even if CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not selected. The patch also switches to using TAINT_OVERLAY_ACPI_TABLE and adds documentation about how

[RFC PATCH v2 08/10] acpi: add support for configfs

Register the ACPI subsystem with configfs. Signed-off-by: Octavian Purdila --- Documentation/ABI/testing/configfs-acpi | 7 ++ MAINTAINERS | 1 + drivers/acpi/Kconfig| 9 drivers/acpi/Makefile

Re: [PATCH 3/6] cifs: quit playing games with draining iovecs

On Tue, Apr 19, 2016 at 01:53:17PM -0400, Jeff Layton wrote: > What's the advantage of using iov_iter_bvec over iov_iter_kvec ? No need to screw with kmap() in the caller; moreover, when it comes to actual copying it gets away with kmap_atomic() just around the memcpy(), which is considerably

[RFC PATCH v2 08/10] acpi: add support for configfs

Register the ACPI subsystem with configfs. Signed-off-by: Octavian Purdila --- Documentation/ABI/testing/configfs-acpi | 7 ++ MAINTAINERS | 1 + drivers/acpi/Kconfig| 9 drivers/acpi/Makefile | 1 +

Re: [PATCH 3/6] cifs: quit playing games with draining iovecs

On Tue, Apr 19, 2016 at 01:53:17PM -0400, Jeff Layton wrote: > What's the advantage of using iov_iter_bvec over iov_iter_kvec ? No need to screw with kmap() in the caller; moreover, when it comes to actual copying it gets away with kmap_atomic() just around the memcpy(), which is considerably

[RFC PATCH v2 06/10] spi: add support for ACPI reconfigure notifications

This patch adds supports for SPI device enumeration and removal via ACPI reconfiguration notifications that are send as a result of an ACPI table load or unload operation. Signed-off-by: Octavian Purdila --- drivers/spi/spi.c | 94

[RFC PATCH v2 06/10] spi: add support for ACPI reconfigure notifications

This patch adds supports for SPI device enumeration and removal via ACPI reconfiguration notifications that are send as a result of an ACPI table load or unload operation. Signed-off-by: Octavian Purdila --- drivers/spi/spi.c | 94 ++- 1 file

[RFC PATCH v2 05/10] i2c: add support for ACPI reconfigure notifications

This patch adds supports for I2C device enumeration and removal via ACPI reconfiguration notifications that are send as a result of an ACPI table load or unload operation. Signed-off-by: Octavian Purdila --- drivers/i2c/i2c-core.c | 170

[RFC PATCH v2 09/10] acpi: add support for loading SSDTs via configfs

Add support for acpi_user_table configfs items that allows the user to load new tables. The data attributes contains the table data and once it is filled from userspace the table is loaded and ACPI devices are enumerated. Signed-off-by: Octavian Purdila ---

[RFC PATCH v2 10/10] HACK: acpi: configfs: add unload_hanlde_path attribute for tables

Because there is no way to get a references to a table that we can use to unload a table this patch adds an attribute allows the user to attach a path to an ACPI handle to be used when unloading the table. The ACPI handle must have been loaded with the table to which attribute is part of,

[RFC PATCH v2 07/10] efi: load SSTDs from EFI variables

This patch allows SSDTs to be loaded from EFI variables. It works by specifying the EFI variable name containing the SSDT to be loaded. All variables with the same name (regardless of the vendor GUID) will be loaded. Note that we can't use acpi_install_table and we must rely on the dynamic ACPI

[RFC PATCH v2 05/10] i2c: add support for ACPI reconfigure notifications

This patch adds supports for I2C device enumeration and removal via ACPI reconfiguration notifications that are send as a result of an ACPI table load or unload operation. Signed-off-by: Octavian Purdila --- drivers/i2c/i2c-core.c | 170 ++--- 1 file

[RFC PATCH v2 09/10] acpi: add support for loading SSDTs via configfs

Add support for acpi_user_table configfs items that allows the user to load new tables. The data attributes contains the table data and once it is filled from userspace the table is loaded and ACPI devices are enumerated. Signed-off-by: Octavian Purdila ---

[RFC PATCH v2 10/10] HACK: acpi: configfs: add unload_hanlde_path attribute for tables

Because there is no way to get a references to a table that we can use to unload a table this patch adds an attribute allows the user to attach a path to an ACPI handle to be used when unloading the table. The ACPI handle must have been loaded with the table to which attribute is part of,

[RFC PATCH v2 07/10] efi: load SSTDs from EFI variables

This patch allows SSDTs to be loaded from EFI variables. It works by specifying the EFI variable name containing the SSDT to be loaded. All variables with the same name (regardless of the vendor GUID) will be loaded. Note that we can't use acpi_install_table and we must rely on the dynamic ACPI

[RFC PATCH v2 01/10] kernel: add TAINT_OVERLAY_ACPI_TABLE

Add a new tain flag that indicates wheather the user has loaded ACPI SSDT overlays. This will provide a clean indication in bug reports that the user has added new information to the ACPI tables. Signed-off-by: Octavian Purdila ---

[RFC PATCH v2 00/10] ACPI overlays

This patch set enables custom ACPI board configuration by adding mechanisms in the Linux kernel for loading user defined SSDTs. In order to support ACPI open-ended hardware configurations we need a way to augment the ACPI configuration provided by the firmware image. A common example is

[RFC PATCH v2 03/10] acpi: fix enumeration (visited) flags for bus rescans

If the ACPI tables changes as a result of a dinamically loaded table and a bus rescan is required the enumeration/visited flag are not consistent. I2C/SPI are not directly enumerated in acpi_bus_attach(), however the visited flag is set. This makes it impossible to check if an ACPI device has

Re: [PATCH 2/3] RTC: Write Calibration value before set time

On 12/04/2016 at 17:45:45 +0530, Anurag Kumar Vulisha wrote : > It is suggested to programe CALIB_WRITE register with the calibration > value before updating the SET_TIME_WRITE register, doing so will > clear the Tick Counter and force the next second to be signaled > exactly in 1 second. > >

[RFC PATCH v2 01/10] kernel: add TAINT_OVERLAY_ACPI_TABLE

Add a new tain flag that indicates wheather the user has loaded ACPI SSDT overlays. This will provide a clean indication in bug reports that the user has added new information to the ACPI tables. Signed-off-by: Octavian Purdila --- Documentation/acpi/ssdt-overlays.txt | 64

[RFC PATCH v2 00/10] ACPI overlays

This patch set enables custom ACPI board configuration by adding mechanisms in the Linux kernel for loading user defined SSDTs. In order to support ACPI open-ended hardware configurations we need a way to augment the ACPI configuration provided by the firmware image. A common example is

[RFC PATCH v2 03/10] acpi: fix enumeration (visited) flags for bus rescans

If the ACPI tables changes as a result of a dinamically loaded table and a bus rescan is required the enumeration/visited flag are not consistent. I2C/SPI are not directly enumerated in acpi_bus_attach(), however the visited flag is set. This makes it impossible to check if an ACPI device has

Re: [PATCH 2/3] RTC: Write Calibration value before set time

On 12/04/2016 at 17:45:45 +0530, Anurag Kumar Vulisha wrote : > It is suggested to programe CALIB_WRITE register with the calibration > value before updating the SET_TIME_WRITE register, doing so will > clear the Tick Counter and force the next second to be signaled > exactly in 1 second. > >

Re: [PATCH 1/3] RTC: Enable RTC switching to battery power when VCC_PSAUX is N/A

On 12/04/2016 at 17:45:44 +0530, Anurag Kumar Vulisha wrote : > In order to conserve battery energy, during the PS operation, > it is expected that the supply for the battery-powered domain > to be switched from the battery (VCC_PSBATT) to (VCC_PSAUX) and > automatically be switched back to

Re: [PATCH 1/3] RTC: Enable RTC switching to battery power when VCC_PSAUX is N/A

On 12/04/2016 at 17:45:44 +0530, Anurag Kumar Vulisha wrote : > In order to conserve battery energy, during the PS operation, > it is expected that the supply for the battery-powered domain > to be switched from the battery (VCC_PSBATT) to (VCC_PSAUX) and > automatically be switched back to

Re: [PATCH 3/3] RTC: Update seconds time programming logic

Hi, Please use rtc: zynqmp in your subject line. On 12/04/2016 at 17:45:46 +0530, Anurag Kumar Vulisha wrote : > @@ -78,6 +85,17 @@ static int xlnx_rtc_set_time(struct device *dev, struct > rtc_time *tm) > > writel(new_time, xrtcdev->reg_base + RTC_SET_TM_WR); > > + /* > + *

Re: [PATCH 3/3] RTC: Update seconds time programming logic

Hi, Please use rtc: zynqmp in your subject line. On 12/04/2016 at 17:45:46 +0530, Anurag Kumar Vulisha wrote : > @@ -78,6 +85,17 @@ static int xlnx_rtc_set_time(struct device *dev, struct > rtc_time *tm) > > writel(new_time, xrtcdev->reg_base + RTC_SET_TM_WR); > > + /* > + *

Re: [PATCH 0/6 v2] of: Implement iterator for phandles

On Mon, Apr 4, 2016 at 10:49 AM, Joerg Roedel wrote: > Hi, > > here is a new version of the implementation of the iterator > over phandles concept which Rob Herring suggested to me some > time ago. My approach is a little bit different from what > the diff showed back then, but

Re: [PATCH 0/6 v2] of: Implement iterator for phandles

On Mon, Apr 4, 2016 at 10:49 AM, Joerg Roedel wrote: > Hi, > > here is a new version of the implementation of the iterator > over phandles concept which Rob Herring suggested to me some > time ago. My approach is a little bit different from what > the diff showed back then, but it gets rid of the

Re: [PATCH] kernel/futex: handle the case where we got a "late" waiter

On Fri, 15 Apr 2016, Sebastian Andrzej Siewior wrote: futex_unlock_pi() gets uval before taking the hb lock. Now imagine someone in futex_lock_pi() took the lock. While futex_unlock_pi() waits for the hb lock, the LOCK_PI sets FUTEX_WAITERS and drops the lock. Now, futex_unlock_pi() figures out

Re: [PATCH] kernel/futex: handle the case where we got a "late" waiter

On Fri, 15 Apr 2016, Sebastian Andrzej Siewior wrote: futex_unlock_pi() gets uval before taking the hb lock. Now imagine someone in futex_lock_pi() took the lock. While futex_unlock_pi() waits for the hb lock, the LOCK_PI sets FUTEX_WAITERS and drops the lock. Now, futex_unlock_pi() figures out

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

On Tue, 19 Apr 2016, Eric Wheeler wrote: > > bch_writeback_thread() is calling try_to_freeze(), but that's just an > > expensive no-op given the fact that the thread is not marked freezable. > > > > I/O helper kthreads, exactly such as the bcache writeback thread, actually > > shouldn't be

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

On Tue, 19 Apr 2016, Eric Wheeler wrote: > > bch_writeback_thread() is calling try_to_freeze(), but that's just an > > expensive no-op given the fact that the thread is not marked freezable. > > > > I/O helper kthreads, exactly such as the bcache writeback thread, actually > > shouldn't be

Re: [PATCH/TRIVIAL] devicetree: bindings: designware-pcie: Fix unit address

On Tue, Apr 12, 2016 at 01:01:34PM -0700, Stephen Boyd wrote: > Remove the 0x in the unit address because it shouldn't be there. > > Cc: Joao Pinto > Signed-off-by: Stephen Boyd Applied, thanks. Rob > --- >

Re: [PATCH/TRIVIAL] devicetree: bindings: designware-pcie: Fix unit address

On Tue, Apr 12, 2016 at 01:01:34PM -0700, Stephen Boyd wrote: > Remove the 0x in the unit address because it shouldn't be there. > > Cc: Joao Pinto > Signed-off-by: Stephen Boyd Applied, thanks. Rob > --- > Documentation/devicetree/bindings/pci/designware-pcie.txt | 2 +- > 1 file changed,

Re: [PATCH 2/2] of: Add Inforce Computing to vendor prefix list

On Tue, Apr 12, 2016 at 10:29:57AM +0100, Srinivas Kandagatla wrote: > This patch adds Inforce Computing to vendor prefix list. > This vendor makes boards like IFC6410, IFC6540 based on Qualcomm SOCs. > > Signed-off-by: Srinivas Kandagatla Applied, thanks. Rob

Re: [PATCH 2/2] of: Add Inforce Computing to vendor prefix list

On Tue, Apr 12, 2016 at 10:29:57AM +0100, Srinivas Kandagatla wrote: > This patch adds Inforce Computing to vendor prefix list. > This vendor makes boards like IFC6410, IFC6540 based on Qualcomm SOCs. > > Signed-off-by: Srinivas Kandagatla Applied, thanks. Rob > --- >

Re: [PATCH 1/2] of: Add Arrow Electronics to vendor prefix list

On Tue, Apr 12, 2016 at 10:29:56AM +0100, Srinivas Kandagatla wrote: > This patch adds Arrow Electronics to vendor perfix list, as this vendor > makes some of the Qualcomm SOC based 96boards like DB600c and DB410c. > > Signed-off-by: Srinivas Kandagatla Applied,

Re: [PATCH 1/2] of: Add Arrow Electronics to vendor prefix list

On Tue, Apr 12, 2016 at 10:29:56AM +0100, Srinivas Kandagatla wrote: > This patch adds Arrow Electronics to vendor perfix list, as this vendor > makes some of the Qualcomm SOC based 96boards like DB600c and DB410c. > > Signed-off-by: Srinivas Kandagatla Applied, thanks. Rob > --- >

Re: [PATCH] of: Add vendor prefix for Shenzhen Embest Technology

On Sat, Apr 09, 2016 at 03:14:25PM -0300, Sergio Prado wrote: > Signed-off-by: Sergio Prado Applied, thanks. Rob > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH] of: Add vendor prefix for Shenzhen Embest Technology

On Sat, Apr 09, 2016 at 03:14:25PM -0300, Sergio Prado wrote: > Signed-off-by: Sergio Prado Applied, thanks. Rob > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt >

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