[PATCH v2 1/3] Input: alps - move ALPS_PROTO_V4 out of alps_model_data table

Like for other protocols create alps_v4_protocol_data and use it in alps_identify() function. Signed-off-by: Pali Rohár --- drivers/input/mouse/alps.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c index

[PATCH v2 2/3] Input: alps - warn about unsupported ALPS V9 touchpad

Support for devices with ALPS_PROTO_V9 is not implemented yet but we can detect these alps touchpads and warn users about it. Signed-off-by: Pali Rohár --- drivers/input/mouse/alps.c |9 + drivers/input/mouse/alps.h |1 + 2 files changed, 10 insertions(+) diff --git

[PATCH v2 3/3] Input: alps - cleanup alps_model_data

Sort all devices in alps_model_data by signature and remove command_mode_resp which is not used anymore. Signed-off-by: Pali Rohár --- drivers/input/mouse/alps.c | 56 drivers/input/mouse/alps.h |5 2 files changed,

[PATCH v2 3/3] Input: alps - cleanup alps_model_data

Sort all devices in alps_model_data by signature and remove command_mode_resp which is not used anymore. Signed-off-by: Pali Rohár --- drivers/input/mouse/alps.c | 56 drivers/input/mouse/alps.h |5 2 files changed, 25 insertions(+), 36

Re: [PATCH v2] pinctrl: samsung: Calculate GPIO base for pinctrl_add_gpio_range

Hi Charles, 2017-03-01 2:04 GMT+09:00 Charles Keepax : > As the pinctrl is now added before the GPIOs are registered we need to > manually calculate what the GPIO base will be, otherwise the base for > each gpio_range will be set to zero. Fortunately the

Re: [PATCH v2] pinctrl: samsung: Calculate GPIO base for pinctrl_add_gpio_range

Hi Charles, 2017-03-01 2:04 GMT+09:00 Charles Keepax : > As the pinctrl is now added before the GPIOs are registered we need to > manually calculate what the GPIO base will be, otherwise the base for > each gpio_range will be set to zero. Fortunately the driver > already assigns a GPIO base, in

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

Hi Steve, On Fri, Mar 03, 2017 at 02:43:51PM -0800, Steve Longerbeam wrote: > > > On 03/03/2017 03:45 AM, Sakari Ailus wrote: > >On Thu, Mar 02, 2017 at 03:07:21PM -0800, Steve Longerbeam wrote: > >> > >> > >>On 03/02/2017 07:53 AM, Sakari Ailus wrote: > >>>Hi Steve, > >>> > >>>On Wed, Feb 15,

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

Hi Steve, On Fri, Mar 03, 2017 at 02:43:51PM -0800, Steve Longerbeam wrote: > > > On 03/03/2017 03:45 AM, Sakari Ailus wrote: > >On Thu, Mar 02, 2017 at 03:07:21PM -0800, Steve Longerbeam wrote: > >> > >> > >>On 03/02/2017 07:53 AM, Sakari Ailus wrote: > >>>Hi Steve, > >>> > >>>On Wed, Feb 15,

[PATCH -v5 06/14] futex,rt_mutex: Provide futex specific rt_mutex API

Part of what makes futex_unlock_pi() intricate is that rt_mutex_futex_unlock() -> rt_mutex_slowunlock() can drop rt_mutex::wait_lock. This means we cannot rely on the atomicy of wait_lock, which we would like to do in order to not rely on hb->lock so much. The reason rt_mutex_slowunlock() needs

[PATCH -v5 06/14] futex,rt_mutex: Provide futex specific rt_mutex API

Part of what makes futex_unlock_pi() intricate is that rt_mutex_futex_unlock() -> rt_mutex_slowunlock() can drop rt_mutex::wait_lock. This means we cannot rely on the atomicy of wait_lock, which we would like to do in order to not rely on hb->lock so much. The reason rt_mutex_slowunlock() needs

[PATCH -v5 05/14] futex: Remove rt_mutex_deadlock_account_*()

These are unused and clutter up the code. Signed-off-by: Peter Zijlstra (Intel) --- kernel/locking/rtmutex-debug.c |9 --- kernel/locking/rtmutex-debug.h |3 -- kernel/locking/rtmutex.c | 47 +++--

[PATCH -v5 05/14] futex: Remove rt_mutex_deadlock_account_*()

These are unused and clutter up the code. Signed-off-by: Peter Zijlstra (Intel) --- kernel/locking/rtmutex-debug.c |9 --- kernel/locking/rtmutex-debug.h |3 -- kernel/locking/rtmutex.c | 47 +++-- kernel/locking/rtmutex.h |2 -

Re: Passionate Partner

Dear Sir, Did you recieved my mail? I have sent it twice without a response. Mr Masella Giuseppe

Re: Passionate Partner

Dear Sir, Did you recieved my mail? I have sent it twice without a response. Mr Masella Giuseppe

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

On Fri, Mar 03, 2017 at 03:01:23PM -0600, Brijesh Singh wrote: > +merely enables SME (sets bit 23 of the MSR_K8_SYSCFG), then Linux can > activate > +memory encryption by default (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y) > or > +by supplying mem_encrypt=on on the kernel command line. However,

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

On Fri, Mar 03, 2017 at 03:01:23PM -0600, Brijesh Singh wrote: > +merely enables SME (sets bit 23 of the MSR_K8_SYSCFG), then Linux can > activate > +memory encryption by default (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y) > or > +by supplying mem_encrypt=on on the kernel command line. However,

Re: [PATCH] net: smsc: smc91x: use new api ethtool_{get|set}_link_ksettings

On Sat, Mar 04, 2017 at 11:11:32AM +0100, Philippe Reynes wrote: > > // lp->port = cmd->port; Hi, Review looks good. However, please also update the above comment as well. Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile

Re: [PATCH] net: smsc: smc91x: use new api ethtool_{get|set}_link_ksettings

On Sat, Mar 04, 2017 at 11:11:32AM +0100, Philippe Reynes wrote: > > // lp->port = cmd->port; Hi, Review looks good. However, please also update the above comment as well. Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile

Re: [PATCH v2 0/2] patches for Innomedia INNEX GENESIS/ATARI adapter

On Fri, Mar 03, 2017 at 05:15:01PM +0100, Benjamin Tissoires wrote: > > Firstly, the value reported by the device is still unusual and does not > > correctly represent the state of the device. > > That's a little bit worrying. I still think the patch could be taken, > but it would be interesting

Re: [PATCH v2 0/2] patches for Innomedia INNEX GENESIS/ATARI adapter

On Fri, Mar 03, 2017 at 05:15:01PM +0100, Benjamin Tissoires wrote: > > Firstly, the value reported by the device is still unusual and does not > > correctly represent the state of the device. > > That's a little bit worrying. I still think the patch could be taken, > but it would be interesting

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On 03/03/17 at 04:23pm, Borislav Petkov wrote: > Ok, > > TBH, I still don't like adding yet another define and paying attention > to whether I should use image size or mapping size. After your patch, > KERNEL_IMAGE_SIZE is used to enforce the actual image size from > exploding: > >

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On 03/03/17 at 04:23pm, Borislav Petkov wrote: > Ok, > > TBH, I still don't like adding yet another define and paying attention > to whether I should use image size or mapping size. After your patch, > KERNEL_IMAGE_SIZE is used to enforce the actual image size from > exploding: > >

[PATCH] net: smsc: smc91x: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/smsc/smc91x.c | 45

[PATCH] net: smsc: smc91x: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/smsc/smc91x.c | 45

[PATCH -v5 00/14] the saga of FUTEX_UNLOCK_PI wobbles continues

Hi all, Here be the 5th iteration of these patches; which strive to unlock the rt_mutex without holding hb->lock. In total this patch-set is very much like the previous one (including the 'late' fix) but it gets there in a slightly different -- and hopefully easier to understand -- route. The

[PATCH -v5 00/14] the saga of FUTEX_UNLOCK_PI wobbles continues

Hi all, Here be the 5th iteration of these patches; which strive to unlock the rt_mutex without holding hb->lock. In total this patch-set is very much like the previous one (including the 'late' fix) but it gets there in a slightly different -- and hopefully easier to understand -- route. The

[PATCH -v5 04/14] futex: Use smp_store_release() in mark_wake_futex()

Since the futex_q can dissapear the instruction after assigning NULL, this really should be a RELEASE barrier. That stops loads from hitting dead memory too. Signed-off-by: Peter Zijlstra (Intel) --- kernel/futex.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

[PATCH -v5 01/14] futex: Fix potential use-after-free in FUTEX_REQUEUE_PI

While working on the futex code, I stumbled over this potential use-after-free scenario. pi_mutex is a pointer into pi_state, which we drop the reference on in unqueue_me_pi(). So any access to that pointer after that is bad. Since other sites already do rt_mutex_unlock() with hb->lock held, see

[PATCH -v5 02/14] futex: Add missing error handling to FUTEX_REQUEUE_PI

Thomas spotted that fixup_pi_state_owner() can return errors and we fail to unlock the rt_mutex in that case. Reviewed-by: Darren Hart Reported-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) --- kernel/futex.c |2

[PATCH -v5 04/14] futex: Use smp_store_release() in mark_wake_futex()

Since the futex_q can dissapear the instruction after assigning NULL, this really should be a RELEASE barrier. That stops loads from hitting dead memory too. Signed-off-by: Peter Zijlstra (Intel) --- kernel/futex.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/kernel/futex.c

[PATCH -v5 01/14] futex: Fix potential use-after-free in FUTEX_REQUEUE_PI

While working on the futex code, I stumbled over this potential use-after-free scenario. pi_mutex is a pointer into pi_state, which we drop the reference on in unqueue_me_pi(). So any access to that pointer after that is bad. Since other sites already do rt_mutex_unlock() with hb->lock held, see

[PATCH -v5 02/14] futex: Add missing error handling to FUTEX_REQUEUE_PI

Thomas spotted that fixup_pi_state_owner() can return errors and we fail to unlock the rt_mutex in that case. Reviewed-by: Darren Hart Reported-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) --- kernel/futex.c |2 ++ 1 file changed, 2 insertions(+) --- a/kernel/futex.c +++

[PATCH -v5 09/14] futex: Rework inconsistent rt_mutex/futex_q state

There is a weird state in the futex_unlock_pi() path when it interleaves with a concurrent futex_lock_pi() at the point where it drops hb->lock. In this case, it can happen that the rt_mutex wait_list and the futex_q disagree on pending waiters, in particular rt_mutex will find no pending waiters

[PATCH -v5 09/14] futex: Rework inconsistent rt_mutex/futex_q state

There is a weird state in the futex_unlock_pi() path when it interleaves with a concurrent futex_lock_pi() at the point where it drops hb->lock. In this case, it can happen that the rt_mutex wait_list and the futex_q disagree on pending waiters, in particular rt_mutex will find no pending waiters

[PATCH -v5 10/14] futex: Pull rt_mutex_futex_unlock() out from under hb->lock

There's a number of 'interesting' problems, all caused by holding hb->lock while doing the rt_mutex_unlock() equivalient. Notably: - a PI inversion on hb->lock; and, - a DL crash because of pointer instability. Because of all the previous patches that: - allow us to do

[PATCH -v5 07/14] futex: Change locking rules

Currently futex-pi relies on hb->lock to serialize everything. Since hb->lock is giving us problems (PI inversions among other things, since on -rt hb lock itself is a rt_mutex), we want to break this up a bit. This patch reworks and documents the locking. Notably, it consistently uses

[PATCH -v5 07/14] futex: Change locking rules

Currently futex-pi relies on hb->lock to serialize everything. Since hb->lock is giving us problems (PI inversions among other things, since on -rt hb lock itself is a rt_mutex), we want to break this up a bit. This patch reworks and documents the locking. Notably, it consistently uses

[PATCH -v5 10/14] futex: Pull rt_mutex_futex_unlock() out from under hb->lock

There's a number of 'interesting' problems, all caused by holding hb->lock while doing the rt_mutex_unlock() equivalient. Notably: - a PI inversion on hb->lock; and, - a DL crash because of pointer instability. Because of all the previous patches that: - allow us to do

[PATCH -v5 14/14] futex: futex_unlock_pi() determinism

The problem with returning -EAGAIN when the waiter state mismatches is that it becomes very hard to proof a bounded execution time on the operation. And seeing that this is a RT operation, this is somewhat important. While in practise it will be very unlikely to ever really take more than one or

[PATCH -v5 13/14] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()

By changing futex_lock_pi() to use rt_mutex_*_proxy_lock() we arrive at a point where all wait_list modifications are done under both hb->lock and wait_lock. This closes the obvious interleave pattern between futex_lock_pi() and futex_unlock_pi(), but not entirely so. See below: Before:

[PATCH -v5 14/14] futex: futex_unlock_pi() determinism

The problem with returning -EAGAIN when the waiter state mismatches is that it becomes very hard to proof a bounded execution time on the operation. And seeing that this is a RT operation, this is somewhat important. While in practise it will be very unlikely to ever really take more than one or

[PATCH -v5 13/14] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()

By changing futex_lock_pi() to use rt_mutex_*_proxy_lock() we arrive at a point where all wait_list modifications are done under both hb->lock and wait_lock. This closes the obvious interleave pattern between futex_lock_pi() and futex_unlock_pi(), but not entirely so. See below: Before:

[PATCH -v5 11/14] futex,rt_mutex: Introduce rt_mutex_init_waiter()

Since there's already two copies of this code, introduce a helper now before we get a third instance. Signed-off-by: Peter Zijlstra (Intel) --- kernel/futex.c |5 + kernel/locking/rtmutex.c| 12 +---

[PATCH -v5 11/14] futex,rt_mutex: Introduce rt_mutex_init_waiter()

Since there's already two copies of this code, introduce a helper now before we get a third instance. Signed-off-by: Peter Zijlstra (Intel) --- kernel/futex.c |5 + kernel/locking/rtmutex.c| 12 +--- kernel/locking/rtmutex_common.h |1 + 3 files

Re: Passionate Partner

Dear Sir, Did you recieved my mail? I have sent it twice without a response. Mr Masella Giuseppe

Re: Passionate Partner

Dear Sir, Did you recieved my mail? I have sent it twice without a response. Mr Masella Giuseppe

[PATCH 2/2] x86/head_64.S: Pass struct boot_params' virtual address to C

From: Borislav Petkov ... so that callees don't have to convert it and can use it directly. Simplifies C code a bit. Cleanup comments and formatting in the vicinity, while at it. Also, document what phys_base really is. No functionality change. Signed-off-by: Borislav Petkov

[PATCH 2/2] x86/head_64.S: Pass struct boot_params' virtual address to C

From: Borislav Petkov ... so that callees don't have to convert it and can use it directly. Simplifies C code a bit. Cleanup comments and formatting in the vicinity, while at it. Also, document what phys_base really is. No functionality change. Signed-off-by: Borislav Petkov ---

[PATCH 1/2] x86/head_64.S: Rename start_cpu()

From: Borislav Petkov It doesn't really start a CPU but does a far jump to C code. So call it that. Eliminate the unconditional JMP to it from secondary_startup_64() but make the jump to C code piece part of secondary_startup_64() instead. Also, it doesn't need to be a global

[PATCH 1/2] x86/head_64.S: Rename start_cpu()

From: Borislav Petkov It doesn't really start a CPU but does a far jump to C code. So call it that. Eliminate the unconditional JMP to it from secondary_startup_64() but make the jump to C code piece part of secondary_startup_64() instead. Also, it doesn't need to be a global symbol either so

Re: [PATCH 8/8] LinuxPPS: pps_gen_parport: Add check for bad clocksource.

Hello Rodolfo, I should say, that I found this solution is not the best. For example on high speed PCs (I think over 3GHz) 5 iteration is not enough and module stops working after several hours. That makes it not user-friendly, cause user had to calibrate and set failure_iterations manually. It

Re: [PATCH 8/8] LinuxPPS: pps_gen_parport: Add check for bad clocksource.

Hello Rodolfo, I should say, that I found this solution is not the best. For example on high speed PCs (I think over 3GHz) 5 iteration is not enough and module stops working after several hours. That makes it not user-friendly, cause user had to calibrate and set failure_iterations manually. It

Re: [PATCH 2/2] dt-bindings: display: imx: entry for LAUSCR

Hi, Thus wrote Rob Herring (r...@kernel.org): > On Mon, Feb 27, 2017 at 11:56:42AM +0100, Martin Kaiser wrote: > > - fsl,pcr: LCDC PCR value > > + A display node may optionally define > > + - fsl,lauscr: LCDC AUS Mode Control Register value (only for imx21) > Looks like we already got

Re: [PATCH 2/2] dt-bindings: display: imx: entry for LAUSCR

Hi, Thus wrote Rob Herring (r...@kernel.org): > On Mon, Feb 27, 2017 at 11:56:42AM +0100, Martin Kaiser wrote: > > - fsl,pcr: LCDC PCR value > > + A display node may optionally define > > + - fsl,lauscr: LCDC AUS Mode Control Register value (only for imx21) > Looks like we already got

Re: [PATCH] staging: ks7010: clean up code

On Fri, 2017-03-03 at 23:24-0800, Joe Perches wrote: > > More stuff the changelog doesn't show :( > > On Fri, 2017-03-03 at 22:58 +0200, Ernestas Kulik wrote: > > This fixes type warnings generated by sparse, replaces instances of > > ntohs() with be16_to_cpu() and removes unused fields in

Re: [PATCH] staging: ks7010: clean up code

On Fri, 2017-03-03 at 23:24-0800, Joe Perches wrote: > > More stuff the changelog doesn't show :( > > On Fri, 2017-03-03 at 22:58 +0200, Ernestas Kulik wrote: > > This fixes type warnings generated by sparse, replaces instances of > > ntohs() with be16_to_cpu() and removes unused fields in

Re: [PATCH v3 2/3] x86/hyperv: move TSC reading method to asm/mshyperv.h

On Fri, 3 Mar 2017, Stephen Hemminger wrote: > static inline u64 hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg) > { > u64 scale, offset, cur_tsc; > u32 start; > > /* >* The protocol for reading Hyper-V TSC page is specified in Hypervisor >* Top-Level

Re: [PATCH v3 2/3] x86/hyperv: move TSC reading method to asm/mshyperv.h

On Fri, 3 Mar 2017, Stephen Hemminger wrote: > static inline u64 hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg) > { > u64 scale, offset, cur_tsc; > u32 start; > > /* >* The protocol for reading Hyper-V TSC page is specified in Hypervisor >* Top-Level

[PATCH] staging/fbtft: Hush checkpatch.pl warning about unnecessary line continuations

Use a single string literal as the fmt argument passed to dev_err() instead of multiple string literals split with an embedded backslash character. Signed-off-by: Alexander Kapshuk --- drivers/staging/fbtft/fb_ssd1331.c | 8 1 file changed, 4 insertions(+),

[PATCH] staging/fbtft: Hush checkpatch.pl warning about unnecessary line continuations

Use a single string literal as the fmt argument passed to dev_err() instead of multiple string literals split with an embedded backslash character. Signed-off-by: Alexander Kapshuk --- drivers/staging/fbtft/fb_ssd1331.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [patch 2/3] speakup: convert screen reading to 16bit characters

On Thu, Mar 02, 2017 at 02:53:55AM +0100, Samuel Thibault wrote: > This adds 16bit character support to most of the screen reading by > extending characters to u16 throughout the code. > > Non-latin1 characters are assumed to be alphabetic type for now. > > non-latin1 vt_notifier_call-provided

Re: [patch 2/3] speakup: convert screen reading to 16bit characters

On Thu, Mar 02, 2017 at 02:53:55AM +0100, Samuel Thibault wrote: > This adds 16bit character support to most of the screen reading by > extending characters to u16 throughout the code. > > Non-latin1 characters are assumed to be alphabetic type for now. > > non-latin1 vt_notifier_call-provided

[PATCH v2] staging: ks7010: fix sparse warnings

Currently, sparse generates many warnings for the driver. This commit changes the types of struct fields/function variables to match the endianness at their assignment. Signed-off-by: Ernestas Kulik --- Changes from v1: * Change the type of the variable being passed to

[PATCH v2] staging: ks7010: fix sparse warnings

Currently, sparse generates many warnings for the driver. This commit changes the types of struct fields/function variables to match the endianness at their assignment. Signed-off-by: Ernestas Kulik --- Changes from v1: * Change the type of the variable being passed to ntohs() instead of casting

Re: camera subdevice support was Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

Dobry den! :-) > > > > Ok, I got the camera sensor to work. No subdevices support, so I don't > > > > have focus (etc) working, but that's a start. I also had to remove > > > > video-bus-switch support; but I guess it will be easier to use > > > > video-multiplexer patches... > > > > > > > >

Re: camera subdevice support was Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

Dobry den! :-) > > > > Ok, I got the camera sensor to work. No subdevices support, so I don't > > > > have focus (etc) working, but that's a start. I also had to remove > > > > video-bus-switch support; but I guess it will be easier to use > > > > video-multiplexer patches... > > > > > > > >

Re: [patch 2/3] speakup: convert screen reading to 16bit characters

On Thu, Mar 02, 2017 at 02:53:55AM +0100, Samuel Thibault wrote: > This adds 16bit character support to most of the screen reading by > extending characters to u16 throughout the code. > > Non-latin1 characters are assumed to be alphabetic type for now. > > non-latin1 vt_notifier_call-provided

Re: [patch 2/3] speakup: convert screen reading to 16bit characters

On Thu, Mar 02, 2017 at 02:53:55AM +0100, Samuel Thibault wrote: > This adds 16bit character support to most of the screen reading by > extending characters to u16 throughout the code. > > Non-latin1 characters are assumed to be alphabetic type for now. > > non-latin1 vt_notifier_call-provided

[PATCH v6 0/4] iio: accel: adxl345: Split driver into core and I2C then add SPI support

This patchset modifies the adxl345 to use regmap. In doing so, we can easily introduce SPI support and let regmap handle the rest. Recap of basic features: read_raw for x, y and z axes, scale. After applying this series, driver now supports the SPI protocol and enumeration of device via device

[PATCH v6 3/4] iio: accel: adxl345: Split driver into core and I2C

Move I2C-specific code into its own file and rely on regmap to access registers. The core code provides access to x, y, z and scale readings. Signed-off-by: Eva Rachel Retuya Reviewed-by: Andy Shevchenko --- Changes from v5: * Simplify

[PATCH v6 0/4] iio: accel: adxl345: Split driver into core and I2C then add SPI support

This patchset modifies the adxl345 to use regmap. In doing so, we can easily introduce SPI support and let regmap handle the rest. Recap of basic features: read_raw for x, y and z axes, scale. After applying this series, driver now supports the SPI protocol and enumeration of device via device

[PATCH v6 3/4] iio: accel: adxl345: Split driver into core and I2C

Move I2C-specific code into its own file and rely on regmap to access registers. The core code provides access to x, y, z and scale readings. Signed-off-by: Eva Rachel Retuya Reviewed-by: Andy Shevchenko --- Changes from v5: * Simplify configuration dependency to "depends on INPUT_ADXL34X=n" *

[PATCH v6 2/4] iio: accel: adxl345: Use I2C regmap instead of direct I2C access

Convert the driver to use regmap instead of I2C-specific functions. This is done in preparation for splitting this driver into core and I2C-specific code as well as introduction of SPI driver. Signed-off-by: Eva Rachel Retuya Reviewed-by: Andy Shevchenko

Re: [PATCH v2] video: fbdev: imxfb: support AUS mode

Hi, Thus wrote Bartlomiej Zolnierkiewicz (b.zolnier...@samsung.com): > Do you mean that you want to have code adding bindings > and its documentation in separate patches (because that > is like it was before)? ok, I'll send the next version as two patches again. Looks like we'll need another

[PATCH v6 2/4] iio: accel: adxl345: Use I2C regmap instead of direct I2C access

Convert the driver to use regmap instead of I2C-specific functions. This is done in preparation for splitting this driver into core and I2C-specific code as well as introduction of SPI driver. Signed-off-by: Eva Rachel Retuya Reviewed-by: Andy Shevchenko --- Changes from v5: * Re-order local

Re: [PATCH v2] video: fbdev: imxfb: support AUS mode

Hi, Thus wrote Bartlomiej Zolnierkiewicz (b.zolnier...@samsung.com): > Do you mean that you want to have code adding bindings > and its documentation in separate patches (because that > is like it was before)? ok, I'll send the next version as two patches again. Looks like we'll need another

[PATCH v6 1/4] dt-bindings: iio: accel: Document ADXL345 accelerometer binding

Add the device tree binding documentation for the ADXL345 3-axis digital accelerometer. Signed-off-by: Eva Rachel Retuya Acked-by: Rob Herring --- Change from v5: * Add Rob's Acked-by tag .../devicetree/bindings/iio/accel/adxl345.txt | 38

[PATCH v6 1/4] dt-bindings: iio: accel: Document ADXL345 accelerometer binding

Add the device tree binding documentation for the ADXL345 3-axis digital accelerometer. Signed-off-by: Eva Rachel Retuya Acked-by: Rob Herring --- Change from v5: * Add Rob's Acked-by tag .../devicetree/bindings/iio/accel/adxl345.txt | 38 ++ 1 file changed, 38

[PATCH v6 4/4] iio: accel: adxl345: Add SPI support

Add SPI driver that initializes SPI regmap for the adxl345 core driver. The driver supports the same functionality as I2C namely the x, y, z and scale readings. Signed-off-by: Eva Rachel Retuya Reviewed-by: Andy Shevchenko --- Changes from v5: *

[PATCH v6 4/4] iio: accel: adxl345: Add SPI support

Add SPI driver that initializes SPI regmap for the adxl345 core driver. The driver supports the same functionality as I2C namely the x, y, z and scale readings. Signed-off-by: Eva Rachel Retuya Reviewed-by: Andy Shevchenko --- Changes from v5: * Simplify configuration dependency to "depends on

Re: [PATCH v3 0/7] Fix the parse_dt of exynos dsi and remove the OF graph

On Fri, Mar 03, 2017 at 09:22:06AM +0900, Andi Shyti wrote: > Hi Hoegeun, > > > Hoegeun Kwon (7): > > arm64: dts: exynos: Add the burst and esc clock frequency properties > > for exynos5433 dts > > arm: dts: Add the burst and esc clock frequency properties for > > exynos3250 dts > >

Re: [PATCH v3 0/7] Fix the parse_dt of exynos dsi and remove the OF graph

On Fri, Mar 03, 2017 at 09:22:06AM +0900, Andi Shyti wrote: > Hi Hoegeun, > > > Hoegeun Kwon (7): > > arm64: dts: exynos: Add the burst and esc clock frequency properties > > for exynos5433 dts > > arm: dts: Add the burst and esc clock frequency properties for > > exynos3250 dts > >

Re: [patch v2] mm, vmstat: print non-populated zones in zoneinfo

On 03/04/2017 04:23 AM, David Rientjes wrote: > Initscripts can use the information (protection levels) from > /proc/zoneinfo to configure vm.lowmem_reserve_ratio at boot. > > vm.lowmem_reserve_ratio is an array of ratios for each configured zone on > the system. If a zone is not populated on an

Re: [patch v2] mm, vmstat: print non-populated zones in zoneinfo

On 03/04/2017 04:23 AM, David Rientjes wrote: > Initscripts can use the information (protection levels) from > /proc/zoneinfo to configure vm.lowmem_reserve_ratio at boot. > > vm.lowmem_reserve_ratio is an array of ratios for each configured zone on > the system. If a zone is not populated on an

Re: [PATCH] pinctrl: samsung: fix segfault when using external interrupts on s3c24xx

On Thu, Mar 02, 2017 at 06:23:19PM -0300, Sergio Prado wrote: > We are getting a NULL pointer dereference when working with external > interrupts on s3c24xx: > > Unable to handle kernel NULL pointer dereference at virtual address 00a8 > pgd = c0104000 > [00a8] *pgd= > Internal

Re: [PATCH] pinctrl: samsung: fix segfault when using external interrupts on s3c24xx

On Thu, Mar 02, 2017 at 06:23:19PM -0300, Sergio Prado wrote: > We are getting a NULL pointer dereference when working with external > interrupts on s3c24xx: > > Unable to handle kernel NULL pointer dereference at virtual address 00a8 > pgd = c0104000 > [00a8] *pgd= > Internal

Re: [PATCH 2/2] pps: fix padding issue with PPS_FETCH for ioctl_compat

On 02/24/17 21:23, Matt Ranostay wrote: Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes so this patchset works around the issue and corrects the data returned in pps_fdata_compat. Cc: Rodolfo Giometti Cc: Moritz Fischer Cc: George

Re: [PATCH 2/2] pps: fix padding issue with PPS_FETCH for ioctl_compat

On 02/24/17 21:23, Matt Ranostay wrote: Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes so this patchset works around the issue and corrects the data returned in pps_fdata_compat. Cc: Rodolfo Giometti Cc: Moritz Fischer Cc: George McCollister Signed-off-by: Matt Ranostay ---

Re: [PATCH 8/8] LinuxPPS: pps_gen_parport: Add check for bad clocksource.

On 02/15/17 15:31, Andrey Drobyshev wrote: From: Nikita Edward Baruzdin This commit is supposed to resolve the issue with hard lockups on systems using jiffies as their clock source. Namely, it sets limits on number of iterations clock source may remain unchanged (i. e.

Re: [PATCH 8/8] LinuxPPS: pps_gen_parport: Add check for bad clocksource.

On 02/15/17 15:31, Andrey Drobyshev wrote: From: Nikita Edward Baruzdin This commit is supposed to resolve the issue with hard lockups on systems using jiffies as their clock source. Namely, it sets limits on number of iterations clock source may remain unchanged (i. e. not being updated for

Re: [PATCH 2/8] ntp/pps: ignore pps_valid decreasing if there is no pps signal.

On 02/15/17 15:31, Andrey Drobyshev wrote: From: Alexander GQ Gerasiov In case pps_dec_valid() is called from second_overflow() in the absence of pps signal, there is no need to decrease pps_valid. Signed-off-by: Alexander GQ Gerasiov Acked-by: Rodolfo

Re: [PATCH 2/8] ntp/pps: ignore pps_valid decreasing if there is no pps signal.

On 02/15/17 15:31, Andrey Drobyshev wrote: From: Alexander GQ Gerasiov In case pps_dec_valid() is called from second_overflow() in the absence of pps signal, there is no need to decrease pps_valid. Signed-off-by: Alexander GQ Gerasiov Acked-by: Rodolfo Giometti

[PATCH] scsi: qedf: Fix defective logging format and argument mismatches

Add __printf compiler verification of format and arguments. Fix fallout. Signed-off-by: Joe Perches --- drivers/scsi/qedf/qedf_dbg.h | 13 - drivers/scsi/qedf/qedf_fip.c | 2 +- drivers/scsi/qedf/qedf_io.c | 4 ++-- 3 files changed, 11 insertions(+), 8

[PATCH] scsi: qedf: Fix defective logging format and argument mismatches

Add __printf compiler verification of format and arguments. Fix fallout. Signed-off-by: Joe Perches --- drivers/scsi/qedf/qedf_dbg.h | 13 - drivers/scsi/qedf/qedf_fip.c | 2 +- drivers/scsi/qedf/qedf_io.c | 4 ++-- 3 files changed, 11 insertions(+), 8 deletions(-) diff --git

[GIT PULL] Staging/IIO driver fixes for 4.11-rc1

The following changes since commit bc49a7831b1137ce1c2dda1c57e3631655f5d2ae: Merge branch 'akpm' (patches from Andrew) (2017-02-22 19:29:24 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-4.11-rc1-part2 for you

[GIT PULL] Staging/IIO driver fixes for 4.11-rc1

The following changes since commit bc49a7831b1137ce1c2dda1c57e3631655f5d2ae: Merge branch 'akpm' (patches from Andrew) (2017-02-22 19:29:24 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-4.11-rc1-part2 for you

Re: [PATCH] ARM: dts: exynos: Use thermal fuse value for thermal zone 0 on Exynos5420

On Fri, Mar 03, 2017 at 06:50:06PM -0300, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 02/11/2017 05:14 PM, Krzysztof Kozlowski wrote: > > In Odroid XU3 Lite board, the temperature levels reported for thermal > > zone 0 were weird. In warm room: > >

Re: [PATCH] ARM: dts: exynos: Use thermal fuse value for thermal zone 0 on Exynos5420

On Fri, Mar 03, 2017 at 06:50:06PM -0300, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 02/11/2017 05:14 PM, Krzysztof Kozlowski wrote: > > In Odroid XU3 Lite board, the temperature levels reported for thermal > > zone 0 were weird. In warm room: > >

<    1   2   3   4   5   6