Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On 04/29/2016 12:57 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 11:09:23AM -0700, Dave Hansen wrote: >> Once we *HAVE* XSAVES support, it also opens up the possibilities for >> doing things like dynamic XSAVE buffer allocation. For instance, let >> threads that are not _using_ AVX-512 not

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On 04/29/2016 12:57 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 11:09:23AM -0700, Dave Hansen wrote: >> Once we *HAVE* XSAVES support, it also opens up the possibilities for >> doing things like dynamic XSAVE buffer allocation. For instance, let >> threads that are not _using_ AVX-512 not

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Hi, On Fri, Apr 29, 2016 at 12:50 PM, Russell King - ARM Linux wrote: > Your original two arguments don't really stand up. > > Let's take #2 to start with. > > You claim that coreboot doesn't have support to provide the correct UUID. > Why is that a problem? Distros on

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Hi, On Fri, Apr 29, 2016 at 12:50 PM, Russell King - ARM Linux wrote: > Your original two arguments don't really stand up. > > Let's take #2 to start with. > > You claim that coreboot doesn't have support to provide the correct UUID. > Why is that a problem? Distros on x86 don't have support to

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On Fri, Apr 29, 2016 at 11:09:23AM -0700, Dave Hansen wrote: > Once we *HAVE* XSAVES support, it also opens up the possibilities for > doing things like dynamic XSAVE buffer allocation. For instance, let > threads that are not _using_ AVX-512 not waste the 2k of space for it. If we can somehow

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

On Fri, Apr 29, 2016 at 11:09:23AM -0700, Dave Hansen wrote: > Once we *HAVE* XSAVES support, it also opens up the possibilities for > doing things like dynamic XSAVE buffer allocation. For instance, let > threads that are not _using_ AVX-512 not waste the 2k of space for it. If we can somehow

Re: [PATCH v2 08/11] serial: sh-sci: Correct pin initialization on (H)SCIF

Hi Peter, On Fri, Apr 29, 2016 at 5:59 PM, Peter Hurley wrote: > On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: >> Correct pin initialization on (H)SCIF: >> - RTS must be deasserted (it's active low), >> - SCK must be an input, as it may be used as the optional

Re: [PATCH v2 08/11] serial: sh-sci: Correct pin initialization on (H)SCIF

Hi Peter, On Fri, Apr 29, 2016 at 5:59 PM, Peter Hurley wrote: > On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote: >> Correct pin initialization on (H)SCIF: >> - RTS must be deasserted (it's active low), >> - SCK must be an input, as it may be used as the optional external >> clock

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 12:43:39PM -0700, Doug Anderson wrote: > Russell, > > On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux > wrote: > > On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote: > >> This series picks patches from various different

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 12:43:39PM -0700, Doug Anderson wrote: > Russell, > > On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux > wrote: > > On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote: > >> This series picks patches from various different places to produce what >

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 12:31:28PM -0700, Doug Anderson wrote: > Rob, > > On Fri, Apr 29, 2016 at 11:12 AM, Rob Herring wrote: > > On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson > > wrote: > >> This series picks patches from various different

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 12:31:28PM -0700, Doug Anderson wrote: > Rob, > > On Fri, Apr 29, 2016 at 11:12 AM, Rob Herring wrote: > > On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson > > wrote: > >> This series picks patches from various different places to produce what > >> I consider the best

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

* Compostella, Jeremy wrote: > -static void efibc_set_variable(const char *name, const char *value) > +static int efibc_set_variable(const char *name, const char *value) > { > int ret; > efi_guid_t guid = LINUX_EFI_LOADER_ENTRY_GUID; > - struct

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

* Compostella, Jeremy wrote: > -static void efibc_set_variable(const char *name, const char *value) > +static int efibc_set_variable(const char *name, const char *value) > { > int ret; > efi_guid_t guid = LINUX_EFI_LOADER_ENTRY_GUID; > - struct efivar_entry entry; > +

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

* Dave Hansen wrote: > Hi Folks, > > I've heard through the grapevine that there's some concern that we > should not be bothering to enable XSAVES because there's not a > sufficient use case for it. [...] So I have no fundamental objections against this series - I

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Russell, On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux wrote: > On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote: >> This series picks patches from various different places to produce what >> I consider the best solution to getting consistent

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

* Dave Hansen wrote: > Hi Folks, > > I've heard through the grapevine that there's some concern that we > should not be bothering to enable XSAVES because there's not a > sufficient use case for it. [...] So I have no fundamental objections against this series - I didn't apply it back in

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Russell, On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux wrote: > On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote: >> This series picks patches from various different places to produce what >> I consider the best solution to getting consistent mmc and mmcblk >>

Re: [PATCH] tpm: select ANON_INODES for proxy driver

On Fri, Apr 29, 2016 at 09:42:06PM +0300, Jarkko Sakkinen wrote: > On Thu, Apr 28, 2016 at 12:46:13PM +0200, Arnd Bergmann wrote: > > The newly added vtpmx driver fails to build if CONFIG_ANON_INODES > > is disabled: > > > > drivers/char/built-in.o: In function `vtpmx_fops_ioctl': > >

Re: [PATCH] tpm: select ANON_INODES for proxy driver

On Fri, Apr 29, 2016 at 09:42:06PM +0300, Jarkko Sakkinen wrote: > On Thu, Apr 28, 2016 at 12:46:13PM +0200, Arnd Bergmann wrote: > > The newly added vtpmx driver fails to build if CONFIG_ANON_INODES > > is disabled: > > > > drivers/char/built-in.o: In function `vtpmx_fops_ioctl': > >

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > Thanks to all the recent x86 entry code refactoring, most tasks' kernel > stacks start at the same offset right above their saved pt_regs, > regardless of which syscall was used to enter the kernel. That creates > a

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

85748c92c3853b75818: > > powercap, perf/x86/intel/rapl: Add PSys support (2016-04-28 10:39:19 +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-20160429 > > for you to fet

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

8: > > powercap, perf/x86/intel/rapl: Add PSys support (2016-04-28 10:39:19 +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-20160429 > > for you to fetch changes up to ca7c

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote: > Thanks to all the recent x86 entry code refactoring, most tasks' kernel > stacks start at the same offset right above their saved pt_regs, > regardless of which syscall was used to enter the kernel. That creates > a nice convention which

[PATCH] Bluetooth: Use hci_conn_hash_lookup_le

Use the function hci_conn_hash_lookup_le that integrates type testing for looking up LE connections. See the patch 1b51c7b6 that introduced this function for more details. The semantic patch that (sort of) fixes this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression

[PATCH] Bluetooth: Use hci_conn_hash_lookup_le

Use the function hci_conn_hash_lookup_le that integrates type testing for looking up LE connections. See the patch 1b51c7b6 that introduced this function for more details. The semantic patch that (sort of) fixes this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression

[PATCH 3/7] sched/fair: Correct unit of load_above_capacity

From: Morten Rasmussen In calculate_imbalance() load_above_capacity currently has the unit [load] while it is used as being [load/capacity]. Not only is it wrong it also makes it unlikely that load_above_capacity is ever used as the subsequent code picks the smaller of

[PATCH 2/7] sched/fair: Fix comment in calculate_imbalance()

The comment survived from commit 2dd73a4f09be ("[PATCH] sched: implement smpnice") in which the selection of busiest and busiest->avg_load (max_load) was based on if(avg_load > max_load && sum_nr_running > group->cpu_power / SCHED_LOAD_SCALE). Commit b18855500fc4 ("sched/balancing: Fix

[PATCH 4/7] sched/fair: Clean up the logic in fix_small_imbalance()

Avoid the need to add scaled_busy_load_per_task on both sides of the if condition to determine whether imbalance has to be set to busiest->load_per_task or not. The imbn variable was introduced with commit 2dd73a4f09be ("[PATCH] sched: implement smpnice") and the original if condition was if

[PATCH 3/7] sched/fair: Correct unit of load_above_capacity

From: Morten Rasmussen In calculate_imbalance() load_above_capacity currently has the unit [load] while it is used as being [load/capacity]. Not only is it wrong it also makes it unlikely that load_above_capacity is ever used as the subsequent code picks the smaller of load_above_capacity and

[PATCH 2/7] sched/fair: Fix comment in calculate_imbalance()

The comment survived from commit 2dd73a4f09be ("[PATCH] sched: implement smpnice") in which the selection of busiest and busiest->avg_load (max_load) was based on if(avg_load > max_load && sum_nr_running > group->cpu_power / SCHED_LOAD_SCALE). Commit b18855500fc4 ("sched/balancing: Fix

[PATCH 4/7] sched/fair: Clean up the logic in fix_small_imbalance()

Avoid the need to add scaled_busy_load_per_task on both sides of the if condition to determine whether imbalance has to be set to busiest->load_per_task or not. The imbn variable was introduced with commit 2dd73a4f09be ("[PATCH] sched: implement smpnice") and the original if condition was if

[PATCH 0/7] sched/fair: fixes and cleanups

This is a collection of rather loosely coupled small changes to the cfs scheduler related to: Comments (patch 1/7, 2/7): Remove/fix some outdated comments related to 'power aware scheduling' and smpnice. Load-balance (patch 3/7 - 5/7): Change unit of load_above_capacity in

[PATCH 1/7] sched/fair: Remove remaining power aware scheduling comments

Commit 8e7fbcbc22c1 ("sched: Remove stale power aware scheduling remnants and dysfunctional knobs") deleted the power aware scheduling support. This patch gets rid of the remaining power aware scheduling comments. Signed-off-by: Dietmar Eggemann ---

[PATCH 0/7] sched/fair: fixes and cleanups

This is a collection of rather loosely coupled small changes to the cfs scheduler related to: Comments (patch 1/7, 2/7): Remove/fix some outdated comments related to 'power aware scheduling' and smpnice. Load-balance (patch 3/7 - 5/7): Change unit of load_above_capacity in

[PATCH 1/7] sched/fair: Remove remaining power aware scheduling comments

Commit 8e7fbcbc22c1 ("sched: Remove stale power aware scheduling remnants and dysfunctional knobs") deleted the power aware scheduling support. This patch gets rid of the remaining power aware scheduling comments. Signed-off-by: Dietmar Eggemann --- kernel/sched/fair.c | 13 +++-- 1

[PATCH 6/7] sched/fair: Reorder code in update_sd_lb_stats()

Do the update of total load and total capacity of sched_domain statistics before detecting if it is the local group. This and the inclusion of sg=sg->next into the condition of the do...while loop makes the code easier to read. Signed-off-by: Dietmar Eggemann ---

[PATCH 6/7] sched/fair: Reorder code in update_sd_lb_stats()

Do the update of total load and total capacity of sched_domain statistics before detecting if it is the local group. This and the inclusion of sg=sg->next into the condition of the do...while loop makes the code easier to read. Signed-off-by: Dietmar Eggemann --- kernel/sched/fair.c | 14

[PATCH 5/7] sched/fair: Remove cpu_avg_load_per_task()

From: Morten Rasmussen cpu_avg_load_per_task() is called in situations where the local sched_group currently has no runnable tasks according to the group statistics (sum of rq->cfs.h_nr_running) to calculate the local load_per_task based on the destination cpu average

[PATCH 5/7] sched/fair: Remove cpu_avg_load_per_task()

From: Morten Rasmussen cpu_avg_load_per_task() is called in situations where the local sched_group currently has no runnable tasks according to the group statistics (sum of rq->cfs.h_nr_running) to calculate the local load_per_task based on the destination cpu average load_per_task. Since group

[PATCH 7/7] sched/fair: Use group_cfs_rq(se) instead of se->my_q

Replace all occurrences of se->my_q right values with group_cfs_rq(se) so it is used consistently to access the cfs_rq owned by this se/tg. Signed-off-by: Dietmar Eggemann --- kernel/sched/fair.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH 7/7] sched/fair: Use group_cfs_rq(se) instead of se->my_q

Replace all occurrences of se->my_q right values with group_cfs_rq(se) so it is used consistently to access the cfs_rq owned by this se/tg. Signed-off-by: Dietmar Eggemann --- kernel/sched/fair.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/sched/fair.c

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Rob, On Fri, Apr 29, 2016 at 11:12 AM, Rob Herring wrote: > On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson > wrote: >> This series picks patches from various different places to produce what >> I consider the best solution to getting consistent mmc

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Rob, On Fri, Apr 29, 2016 at 11:12 AM, Rob Herring wrote: > On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson > wrote: >> This series picks patches from various different places to produce what >> I consider the best solution to getting consistent mmc and mmcblk >> ordering. >> >> Why

Re: [Patch v2 2/8] firmware: qcom: scm: Convert SCM to platform driver

On Mon, Apr 25, 2016 at 06:29:35PM -0700, Stephen Boyd wrote: > On 04/25, Andy Gross wrote: > > This patch converts the Qualcomm SCM firmware driver into a platform > > driver. > > > > Signed-off-by: Andy Gross > > --- > > arch/arm64/Kconfig.platforms | 1 + > >

Re: [Patch v2 2/8] firmware: qcom: scm: Convert SCM to platform driver

On Mon, Apr 25, 2016 at 06:29:35PM -0700, Stephen Boyd wrote: > On 04/25, Andy Gross wrote: > > This patch converts the Qualcomm SCM firmware driver into a platform > > driver. > > > > Signed-off-by: Andy Gross > > --- > > arch/arm64/Kconfig.platforms | 1 + > > drivers/firmware/qcom_scm.c |

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Tue, Mar 1, 2016 at 9:54 AM, Luis R. Rodriguez wrote: > On Tue, Mar 01, 2016 at 08:10:24AM -0800, James Bottomley wrote: >> On Mon, 2016-02-29 at 10:12 +, David Woodhouse wrote: >> > On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote: >> > > This ports built-in

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Tue, Mar 1, 2016 at 9:54 AM, Luis R. Rodriguez wrote: > On Tue, Mar 01, 2016 at 08:10:24AM -0800, James Bottomley wrote: >> On Mon, 2016-02-29 at 10:12 +, David Woodhouse wrote: >> > On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote: >> > > This ports built-in firmware to use

[PATCH v2 2/3] ACPI/device_sysfs: Change _SUN and _STA show functions error return to EIO

The error return from a sysfs show function is passed up through the call chain and visible as the return from the read system call. The show functions for the _STA and _SUN object currently return -ENODEV. This patch changes the return to -EIO. ENODEV makes less sense since the "device' exists or

Re: [PATCH v2 00/10] STMPE fixes/rework and add STMPE1600 support

On Thu, 2016-04-28 at 14:12 +0200, patrice.chot...@st.com wrote: > From: Patrice Chotard > > > This series cleans and fixes some bugs in MFD/GPIO STMPE drivers and > prepare >  the ground to add new STMPE1600 support. > > STMPE1600 datasheet is available here :  >

[PATCH v2 3/3] ACPI/device_sysfs: Clean up checkpatch errors

Cleaning up five existing checkpatch errors in device_sysfs.c since the file is being changed. Signed-off-by: Betty Dall --- drivers/acpi/device_sysfs.c | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/acpi/device_sysfs.c

[PATCH v2 2/3] ACPI/device_sysfs: Change _SUN and _STA show functions error return to EIO

The error return from a sysfs show function is passed up through the call chain and visible as the return from the read system call. The show functions for the _STA and _SUN object currently return -ENODEV. This patch changes the return to -EIO. ENODEV makes less sense since the "device' exists or

Re: [PATCH v2 00/10] STMPE fixes/rework and add STMPE1600 support

On Thu, 2016-04-28 at 14:12 +0200, patrice.chot...@st.com wrote: > From: Patrice Chotard > > > This series cleans and fixes some bugs in MFD/GPIO STMPE drivers and > prepare >  the ground to add new STMPE1600 support. > > STMPE1600 datasheet is available here :  >

[PATCH v2 3/3] ACPI/device_sysfs: Clean up checkpatch errors

Cleaning up five existing checkpatch errors in device_sysfs.c since the file is being changed. Signed-off-by: Betty Dall --- drivers/acpi/device_sysfs.c | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/acpi/device_sysfs.c

[PATCH v2 1/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the device's hardware revision. This is an optional object. Add sysfs support for the _HRV object if it exists on the device. This change allows users to easily find the hardware version of non-PCI hardware by looking at the sysfs

[PATCH v2 1/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the device's hardware revision. This is an optional object. Add sysfs support for the _HRV object if it exists on the device. This change allows users to easily find the hardware version of non-PCI hardware by looking at the sysfs

[PATCH v2 0/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the device's hardware revision. This is an optional object. Add sysfs support for the _HRV object if it exists on the device. This change allows users to easily find the hardware version of non-PCI hardware by looking at the sysfs

[PATCH v2 0/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the device's hardware revision. This is an optional object. Add sysfs support for the _HRV object if it exists on the device. This change allows users to easily find the hardware version of non-PCI hardware by looking at the sysfs

Re: [PATCH v3] mtd: nand_bbt: scan for next free bbt block if writing bbt fails

On Fri, 29 Apr 2016 12:34:18 -0500 Kyle Roeschley wrote: > Hi Boris, > > On Wed, Mar 30, 2016 at 03:16:23PM +0200, Boris Brezillon wrote: > > +Peter, who's currently reworking the NAND BBT code. > > > > On Wed, 30 Mar 2016 15:13:51 +0200 > > Boris Brezillon

Re: [PATCH v3] mtd: nand_bbt: scan for next free bbt block if writing bbt fails

On Fri, 29 Apr 2016 12:34:18 -0500 Kyle Roeschley wrote: > Hi Boris, > > On Wed, Mar 30, 2016 at 03:16:23PM +0200, Boris Brezillon wrote: > > +Peter, who's currently reworking the NAND BBT code. > > > > On Wed, 30 Mar 2016 15:13:51 +0200 > > Boris Brezillon wrote: > > > > > Hi Kyle, > > >

RE: [PATCH] mptsas: fix checks for dma mapping errors

Please consider this patch as Ack-by: Sathya Prakash Veerichetty PS: We don't have test environment to test this patch as this is for an old controller. So ACKing based on code review and similar mpt3sas driver code. -Original Message- From: Martin K.

RE: [PATCH] mptsas: fix checks for dma mapping errors

Please consider this patch as Ack-by: Sathya Prakash Veerichetty PS: We don't have test environment to test this patch as this is for an old controller. So ACKing based on code review and similar mpt3sas driver code. -Original Message- From: Martin K. Petersen

Hello....!!

Good Day, I am Dr Paul Tobib,the Audit and Account Manager (A.D.B)Bank in Ouagadougou Burkina Faso,west africa I have a business transaction for you.In my department i discovered an abandoned Sum of US$10.2 Million Dollars.In an account that belongs to one of our late foreign customer who

Hello....!!

Good Day, I am Dr Paul Tobib,the Audit and Account Manager (A.D.B)Bank in Ouagadougou Burkina Faso,west africa I have a business transaction for you.In my department i discovered an abandoned Sum of US$10.2 Million Dollars.In an account that belongs to one of our late foreign customer who

Re: [RFC v5 3/4] gpio: move clps711x, moxart, ts4800 and gpio-ge into gpio-generic

On Friday, April 29, 2016 04:18:20 PM Linus Walleij wrote: > On Fri, Apr 29, 2016 at 2:53 AM, Christian Lamparter > wrote: > > > This patch integrates these GPIO drivers into gpio-generic. > > > > Signed-off-by: Christian Lamparter > > Very

Re: [RFC v5 3/4] gpio: move clps711x, moxart, ts4800 and gpio-ge into gpio-generic

On Friday, April 29, 2016 04:18:20 PM Linus Walleij wrote: > On Fri, Apr 29, 2016 at 2:53 AM, Christian Lamparter > wrote: > > > This patch integrates these GPIO drivers into gpio-generic. > > > > Signed-off-by: Christian Lamparter > > Very elegant. Let's wait for some feedback/ACKs from > the

[PATCH] iio: ak8975: Support adapters limited to BYTE_DATA

The device has simple 8-bit registers but the driver incorrectly uses block or word reads without checking functionality bits. Fix by using i2c_smbus_read_i2c_block_data_or_emulated instead of i2c_smbus_read_i2c_block_data or i2c_smbus_read_word_data. This will check functionality bits and use

[PATCH] iio: ak8975: Support adapters limited to BYTE_DATA

The device has simple 8-bit registers but the driver incorrectly uses block or word reads without checking functionality bits. Fix by using i2c_smbus_read_i2c_block_data_or_emulated instead of i2c_smbus_read_i2c_block_data or i2c_smbus_read_word_data. This will check functionality bits and use

[RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings

This series attempts to implement support for external readings in i2c master mode. I don't expect this to go in this form but I wanted to present a functional version in order to start the discussion earlier. The I2C master support is useful even without external readings. For example in SPI

[PATCH 2/7] iio: inv_mpu6050: Initial regcache support

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 47 ++ drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 5 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 1 + drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c |

[PATCH 2/7] iio: inv_mpu6050: Initial regcache support

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 47 ++ drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 5 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 1 + drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c | 5 4 files changed,

[RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings

This series attempts to implement support for external readings in i2c master mode. I don't expect this to go in this form but I wanted to present a functional version in order to start the discussion earlier. The I2C master support is useful even without external readings. For example in SPI

[PATCH 6/7] iio: inv_mpu6050: Check channel configuration on preenable

Right now it is possible to only enable some of the x/y/z channels, for example you can enable accel_z without x or y. If you actually do that what you get is actually only the x channel. In theory the device supports selecting gyro x/y/z channels individually. It would also be possible to

[PATCH 3/7] iio: inv_mpu6050: Only toggle DATA_RDY_EN in inv_reset_fifo

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c| 13 - drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 3 ++- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c

[PATCH 6/7] iio: inv_mpu6050: Check channel configuration on preenable

Right now it is possible to only enable some of the x/y/z channels, for example you can enable accel_z without x or y. If you actually do that what you get is actually only the x channel. In theory the device supports selecting gyro x/y/z channels individually. It would also be possible to

[PATCH 3/7] iio: inv_mpu6050: Only toggle DATA_RDY_EN in inv_reset_fifo

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c| 13 - drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 3 ++- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c

[PATCH 4/7] iio: inv_mpu6050: Cache non-volatile bits of user_ctrl

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++ drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c| 9 ++--- drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 4 +++- 3 files changed, 11 insertions(+), 4 deletions(-) diff

[RFC 7/7] iio: inv_mpu6050: Add support for external sensors

This works by copying their channels at probe time. Signed-off-by: Crestez Dan Leonard --- .../devicetree/bindings/iio/imu/inv_mpu6050.txt| 37 +- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 420 -

[PATCH 4/7] iio: inv_mpu6050: Cache non-volatile bits of user_ctrl

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++ drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c| 9 ++--- drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 4 +++- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git

[RFC 7/7] iio: inv_mpu6050: Add support for external sensors

This works by copying their channels at probe time. Signed-off-by: Crestez Dan Leonard --- .../devicetree/bindings/iio/imu/inv_mpu6050.txt| 37 +- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 420 - drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 63 +++-

[RFC 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master

The MPU has an auxiliary I2C bus for connecting external sensors. This bus has two operating modes: * pass-through, which connects the primary and auxiliary busses together. This is already supported via an i2c mux. * I2C master mode, where the mpu60x0 acts as a master to any external connected

[RFC 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master

The MPU has an auxiliary I2C bus for connecting external sensors. This bus has two operating modes: * pass-through, which connects the primary and auxiliary busses together. This is already supported via an i2c mux. * I2C master mode, where the mpu60x0 acts as a master to any external connected

[PATCH 1/7] iio: inv_mpu6050: Do burst reads using spi/i2c directly

Using regmap_read_bulk is wrong because it assumes that a range of registers is being read. In our case reading from the fifo register will return multiple values but this is *not* auto-increment. This currently works by accident. Signed-off-by: Crestez Dan Leonard

[PATCH 1/7] iio: inv_mpu6050: Do burst reads using spi/i2c directly

Using regmap_read_bulk is wrong because it assumes that a range of registers is being read. In our case reading from the fifo register will return multiple values but this is *not* auto-increment. This currently works by accident. Signed-off-by: Crestez Dan Leonard ---

Re: [PATCH v3 0/3] Extend the LED panic trigger

On 29/04/16 00:03, Ezequiel Garcia wrote: As per commit 916fe619951f ("leds: trigger: Introduce a kernel panic LED trigger"), the kernel now supports a new LED trigger to hook on the panic blink. However, the only way of using this is to dedicate a LED device, making it rather useless. To

Re: [PATCH v3 0/3] Extend the LED panic trigger

On 29/04/16 00:03, Ezequiel Garcia wrote: As per commit 916fe619951f ("leds: trigger: Introduce a kernel panic LED trigger"), the kernel now supports a new LED trigger to hook on the panic blink. However, the only way of using this is to dedicate a LED device, making it rather useless. To

Re: [PATCH 17/20] dm: get rid of superfluous gfp flags

On Thu, Apr 28 2016 at 9:24am -0400, Michal Hocko wrote: > From: Michal Hocko > > copy_params seems to be little bit confused about which allocation flags > to use. It enforces GFP_NOIO even though it uses > memalloc_noio_{save,restore} which enforces

Re: [PATCH 17/20] dm: get rid of superfluous gfp flags

On Thu, Apr 28 2016 at 9:24am -0400, Michal Hocko wrote: > From: Michal Hocko > > copy_params seems to be little bit confused about which allocation flags > to use. It enforces GFP_NOIO even though it uses > memalloc_noio_{save,restore} which enforces GFP_NOIO at the page > allocator level

Re: [PATCH] sched/core: don't include asm/mmu_context from drivers

On Fri, Apr 29, 2016 at 8:37 AM, Arnd Bergmann wrote: > On Friday 29 April 2016 09:42:18 Steven Rostedt wrote: >> On Fri, 29 Apr 2016 10:52:32 +0200 >> Arnd Bergmann wrote: >> >> > This reverts the earlier fix attempt and works around the problem >> > by including

Re: [PATCH] sched/core: don't include asm/mmu_context from drivers

On Fri, Apr 29, 2016 at 8:37 AM, Arnd Bergmann wrote: > On Friday 29 April 2016 09:42:18 Steven Rostedt wrote: >> On Fri, 29 Apr 2016 10:52:32 +0200 >> Arnd Bergmann wrote: >> >> > This reverts the earlier fix attempt and works around the problem >> > by including both linux/mmu_context.h and

Re: [4.2.y-ckt stable] Linux 4.2.8-ckt9

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 1d6f045..86dff8f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3858,6 +3858,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.

Re: [4.2.y-ckt stable] Linux 4.2.8-ckt9

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 1d6f045..86dff8f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3858,6 +3858,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.

[4.2.y-ckt stable] Linux 4.2.8-ckt9

I am announcing the release of the Linux 4.2.8-ckt9 kernel. The updated 4.2.y-ckt tree can be found at: git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt linux-4.2.y and can be browsed at:

[4.2.y-ckt stable] Linux 4.2.8-ckt9

I am announcing the release of the Linux 4.2.8-ckt9 kernel. The updated 4.2.y-ckt tree can be found at: git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt linux-4.2.y and can be browsed at:

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Thu, Apr 28, 2016 at 4:44 PM, Josh Poimboeuf wrote: > Thanks to all the recent x86 entry code refactoring, most tasks' kernel > stacks start at the same offset right above their saved pt_regs, > regardless of which syscall was used to enter the kernel. That creates > a

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Thu, Apr 28, 2016 at 4:44 PM, Josh Poimboeuf wrote: > Thanks to all the recent x86 entry code refactoring, most tasks' kernel > stacks start at the same offset right above their saved pt_regs, > regardless of which syscall was used to enter the kernel. That creates > a nice convention which

Re: [PATCH] tpm: select ANON_INODES for proxy driver

On Thu, Apr 28, 2016 at 12:46:13PM +0200, Arnd Bergmann wrote: > The newly added vtpmx driver fails to build if CONFIG_ANON_INODES > is disabled: > > drivers/char/built-in.o: In function `vtpmx_fops_ioctl': > (.text+0x97f8): undefined reference to `anon_inode_getfile' > > This adds a Kconfig

Re: [PATCH] tpm: select ANON_INODES for proxy driver

On Thu, Apr 28, 2016 at 12:46:13PM +0200, Arnd Bergmann wrote: > The newly added vtpmx driver fails to build if CONFIG_ANON_INODES > is disabled: > > drivers/char/built-in.o: In function `vtpmx_fops_ioctl': > (.text+0x97f8): undefined reference to `anon_inode_getfile' > > This adds a Kconfig

Re: random(4) changes

Am Freitag, 29. April 2016, 14:02:48 schrieb George Spelvin: Hi George, > >> 1. It DOES depend on the attacker. Any statement about independence > >> > >>depends on the available knowledge. > >> > >> 2. XOR being entropy preserving depends on independence ONLY, it does > >> > >>NOT

Re: random(4) changes

Am Freitag, 29. April 2016, 14:02:48 schrieb George Spelvin: Hi George, > >> 1. It DOES depend on the attacker. Any statement about independence > >> > >>depends on the available knowledge. > >> > >> 2. XOR being entropy preserving depends on independence ONLY, it does > >> > >>NOT

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