Re: [PATCHv9 2/2] selftest/x86: add mremap vdso test

2016-05-21 23:27 GMT+03:00 Ingo Molnar : > > * Andy Lutomirski wrote: > >> On Thu, May 19, 2016 at 11:48 PM, Ingo Molnar wrote: >> > >> > * Dmitry Safonov wrote: >> > >> >> Should print on success: >> >>

Re: [PATCHv9 2/2] selftest/x86: add mremap vdso test

2016-05-21 23:27 GMT+03:00 Ingo Molnar : > > * Andy Lutomirski wrote: > >> On Thu, May 19, 2016 at 11:48 PM, Ingo Molnar wrote: >> > >> > * Dmitry Safonov wrote: >> > >> >> Should print on success: >> >> [root@localhost ~]# ./test_mremap_vdso_32 >> >> AT_SYSINFO_EHDR is 0xf773f000 >> >>

[PATCH] clk: fixed-rate: add clk_hw_unregister_fixed_rate()

This will be used to migrate to the clk_hw APIs. Signed-off-by: Masahiro Yamada --- drivers/clk/clk-fixed-rate.c | 11 +++ include/linux/clk-provider.h | 1 + 2 files changed, 12 insertions(+) diff --git a/drivers/clk/clk-fixed-rate.c

[PATCH] clk: fixed-rate: add clk_hw_unregister_fixed_rate()

This will be used to migrate to the clk_hw APIs. Signed-off-by: Masahiro Yamada --- drivers/clk/clk-fixed-rate.c | 11 +++ include/linux/clk-provider.h | 1 + 2 files changed, 12 insertions(+) diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c index

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41 >

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41 >

[PATCH v3] Drivers: hv: vmbus: fix the race when querying & updating the percpu list

There is a rare race when we remove an entry from the global list hv_context.percpu_list[cpu] in hv_process_channel_removal() -> percpu_channel_deq() -> list_del(): at this time, if vmbus_on_event() -> process_chn_event() -> pcpu_relid2channel() is trying to query the list, we can get the kernel

[PATCH v3] Drivers: hv: vmbus: fix the race when querying & updating the percpu list

There is a rare race when we remove an entry from the global list hv_context.percpu_list[cpu] in hv_process_channel_removal() -> percpu_channel_deq() -> list_del(): at this time, if vmbus_on_event() -> process_chn_event() -> pcpu_relid2channel() is trying to query the list, we can get the kernel

[rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 8704baab9bc848b58c129fed6b591bb84ec02f41 Author: Paul E. McKenney AuthorDate: Thu Dec 31

[rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 8704baab9bc848b58c129fed6b591bb84ec02f41 Author: Paul E. McKenney AuthorDate: Thu Dec 31 18:33:22 2015 -0800 Commit:

Re: [PATCH 1/4] x86: Save return value from kernel_thread

On Sat, May 21, 2016 at 9:44 PM, Andy Lutomirski wrote: > On Sat, May 21, 2016 at 9:04 AM, Brian Gerst wrote: >> Kernel threads should always return zero on success after calling >> do_execve(). The >> two existing cases in the kernel (kernel_init() and

Re: [PATCH 1/4] x86: Save return value from kernel_thread

On Sat, May 21, 2016 at 9:44 PM, Andy Lutomirski wrote: > On Sat, May 21, 2016 at 9:04 AM, Brian Gerst wrote: >> Kernel threads should always return zero on success after calling >> do_execve(). The >> two existing cases in the kernel (kernel_init() and >> call_usermodehelper_exec_async()) >>

Re: [PATCH 1/4] x86: Save return value from kernel_thread

On Sat, May 21, 2016 at 9:04 AM, Brian Gerst wrote: > Kernel threads should always return zero on success after calling > do_execve(). The > two existing cases in the kernel (kernel_init() and > call_usermodehelper_exec_async()) > correctly do this. Save a few bytes by

Re: [PATCH 1/4] x86: Save return value from kernel_thread

On Sat, May 21, 2016 at 9:04 AM, Brian Gerst wrote: > Kernel threads should always return zero on success after calling > do_execve(). The > two existing cases in the kernel (kernel_init() and > call_usermodehelper_exec_async()) > correctly do this. Save a few bytes by storing EAX/RAX instead

[GIT PULL] f2fs for 4.7-rc1

Hi Linus, In this round, as Ted pointed out, fscrypto allows one more key prefix given by filesystem to resolve backward compatibility issue. Other than that, we could fix several error handling flow by introducing fault injection facility. We've also achieved performance improvement in some

[GIT PULL] f2fs for 4.7-rc1

Hi Linus, In this round, as Ted pointed out, fscrypto allows one more key prefix given by filesystem to resolve backward compatibility issue. Other than that, we could fix several error handling flow by introducing fault injection facility. We've also achieved performance improvement in some

Re: [PATCH] dell-smm-hwmon: Detect fan with index=2

On Sunday 22 May 2016 02:21:46 Guenter Roeck wrote: > On 05/21/2016 07:52 AM, Pali Rohár wrote: > > Some Dell machines (e.g. Dell Precision M3800) have two fans, first > > with index=0 and second with index=2. So export also attributes > > for third fan device with index=2. > > > > Reported-by:

Re: [PATCH] dell-smm-hwmon: Detect fan with index=2

On Sunday 22 May 2016 02:21:46 Guenter Roeck wrote: > On 05/21/2016 07:52 AM, Pali Rohár wrote: > > Some Dell machines (e.g. Dell Precision M3800) have two fans, first > > with index=0 and second with index=2. So export also attributes > > for third fan device with index=2. > > > > Reported-by:

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On Sunday 22 May 2016 02:19:48 Guenter Roeck wrote: > On 05/21/2016 07:46 AM, Pali Rohár wrote: > > On more Dell machines (e.g. Dell Precision M3800) > > I8K_SMM_GET_FAN_TYPE call is too expensive (CPU is too long in SMM > > mode) and cause kernel to hang. This patch cache type for each fan > >

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On Sunday 22 May 2016 02:19:48 Guenter Roeck wrote: > On 05/21/2016 07:46 AM, Pali Rohár wrote: > > On more Dell machines (e.g. Dell Precision M3800) > > I8K_SMM_GET_FAN_TYPE call is too expensive (CPU is too long in SMM > > mode) and cause kernel to hang. This patch cache type for each fan > >

Re: [PATCH] dell-smm-hwmon: Detect fan with index=2

On 05/21/2016 07:52 AM, Pali Rohár wrote: Some Dell machines (e.g. Dell Precision M3800) have two fans, first with index=0 and second with index=2. So export also attributes for third fan device with index=2. Reported-by: Tolga Cakir Signed-off-by: Pali Rohár

Re: [PATCH] dell-smm-hwmon: Detect fan with index=2

On 05/21/2016 07:52 AM, Pali Rohár wrote: Some Dell machines (e.g. Dell Precision M3800) have two fans, first with index=0 and second with index=2. So export also attributes for third fan device with index=2. Reported-by: Tolga Cakir Signed-off-by: Pali Rohár ---

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On 05/21/2016 07:46 AM, Pali Rohár wrote: On more Dell machines (e.g. Dell Precision M3800) I8K_SMM_GET_FAN_TYPE call is too expensive (CPU is too long in SMM mode) and cause kernel to hang. This patch cache type for each fan (as it should not change) and change the way how fan presense is

Re: [PATCH] dell-smm-hwmon: Cache fan_type() calls and use fan_status() for fan detection

On 05/21/2016 07:46 AM, Pali Rohár wrote: On more Dell machines (e.g. Dell Precision M3800) I8K_SMM_GET_FAN_TYPE call is too expensive (CPU is too long in SMM mode) and cause kernel to hang. This patch cache type for each fan (as it should not change) and change the way how fan presense is

Re: [PATCH] drm/gma500: use vma_pages().

On Sat, May 21, 2016 at 3:21 PM, Muhammad Falak R Wani wrote: > Replace explicit computation of vma page count by a call to > vma_pages() > > Signed-off-by: Muhammad Falak R Wani Thanks, queued for gma500-next > --- >

Re: [PATCH] drm/gma500: use vma_pages().

On Sat, May 21, 2016 at 3:21 PM, Muhammad Falak R Wani wrote: > Replace explicit computation of vma page count by a call to > vma_pages() > > Signed-off-by: Muhammad Falak R Wani Thanks, queued for gma500-next > --- > drivers/gpu/drm/gma500/framebuffer.c | 2 +- > 1 file changed, 1

[rcu:dev.2016.05.18a 28/28] kernel/rcu/tree_plugin.h:1168:2: error: implicit declaration of function 'for_each_leaf_node_cpu_bit'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2016.05.18a head: a396e98dae720a48c49795892d23ca17c87319b0 commit: a396e98dae720a48c49795892d23ca17c87319b0 [28/28] rcu: Correctly handle sparse possible CPUs config: x86_64-randconfig-n0-05220622 (attached as

[rcu:dev.2016.05.18a 28/28] kernel/rcu/tree_plugin.h:1168:2: error: implicit declaration of function 'for_each_leaf_node_cpu_bit'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2016.05.18a head: a396e98dae720a48c49795892d23ca17c87319b0 commit: a396e98dae720a48c49795892d23ca17c87319b0 [28/28] rcu: Correctly handle sparse possible CPUs config: x86_64-randconfig-n0-05220622 (attached as

[PATCH v2 1/1] rtc: ds1685: correct check of day of month

The day of month is checked in ds1685_rtc_read_alarm and ds1685_rtc_set_alarm. Multiple errors exist in the day of month check. Operator ! has a higher priority than &&. (!(mday >= 1) && (mday <= 31)) is false for mday == 32. When verifying the day of month the binary and the BCD mode have to

[PATCH v2 1/1] rtc: ds1685: correct check of day of month

The day of month is checked in ds1685_rtc_read_alarm and ds1685_rtc_set_alarm. Multiple errors exist in the day of month check. Operator ! has a higher priority than &&. (!(mday >= 1) && (mday <= 31)) is false for mday == 32. When verifying the day of month the binary and the BCD mode have to

[PATCH] libnvdimm, dax: fix deletion

The ndctl unit tests discovered that the dax enabling omitted updates to nd_detach_and_reset(). This routine clears device the configuration when the namespace is detached. Without this clearing userspace may assume that the device is in the process of being configured by another agent in the

[PATCH] libnvdimm, dax: fix deletion

The ndctl unit tests discovered that the dax enabling omitted updates to nd_detach_and_reset(). This routine clears device the configuration when the namespace is detached. Without this clearing userspace may assume that the device is in the process of being configured by another agent in the

Re: [PATCHv9 2/2] selftest/x86: add mremap vdso test

* Andy Lutomirski wrote: > On Thu, May 19, 2016 at 11:48 PM, Ingo Molnar wrote: > > > > * Dmitry Safonov wrote: > > > >> Should print on success: > >> [root@localhost ~]# ./test_mremap_vdso_32 > >> AT_SYSINFO_EHDR is

Re: [PATCHv9 2/2] selftest/x86: add mremap vdso test

* Andy Lutomirski wrote: > On Thu, May 19, 2016 at 11:48 PM, Ingo Molnar wrote: > > > > * Dmitry Safonov wrote: > > > >> Should print on success: > >> [root@localhost ~]# ./test_mremap_vdso_32 > >> AT_SYSINFO_EHDR is 0xf773f000 > >> [NOTE]Moving vDSO: [f773f000, f774] ->

[PATCH] seqlock: fix raw_read_seqcount_latch()

lockless_dereference() is supposed to take pointer not integer. Signed-off-by: Alexey Dobriyan --- include/linux/seqlock.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/linux/seqlock.h +++ b/include/linux/seqlock.h @@ -277,7 +277,7 @@ static

[PATCH] seqlock: fix raw_read_seqcount_latch()

lockless_dereference() is supposed to take pointer not integer. Signed-off-by: Alexey Dobriyan --- include/linux/seqlock.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/linux/seqlock.h +++ b/include/linux/seqlock.h @@ -277,7 +277,7 @@ static inline void

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

Hi Peter, Ingo, On Thu, May 19, 2016 at 04:04:19PM -0700, Steve Muckle wrote: > On Thu, May 19, 2016 at 11:06:14PM +0200, Rafael J. Wysocki wrote: > > > In the case of a remote update the hook has to run (or not) after it is > > > known whether preemption will occur so we don't do needless work

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

Hi Peter, Ingo, On Thu, May 19, 2016 at 04:04:19PM -0700, Steve Muckle wrote: > On Thu, May 19, 2016 at 11:06:14PM +0200, Rafael J. Wysocki wrote: > > > In the case of a remote update the hook has to run (or not) after it is > > > known whether preemption will occur so we don't do needless work

Re: [GIT PULL] RTC for 4.7

On 21/05/2016 at 11:18:15 -0700, Linus Torvalds wrote : > On Sat, May 21, 2016 at 8:15 AM, Alexandre Belloni > wrote: > > > > Here is the pull-request for the RTC subsystem for 4.7. > > Grr. I noticed this too late, but this has all been rebased very

Re: [GIT PULL] RTC for 4.7

On 21/05/2016 at 11:18:15 -0700, Linus Torvalds wrote : > On Sat, May 21, 2016 at 8:15 AM, Alexandre Belloni > wrote: > > > > Here is the pull-request for the RTC subsystem for 4.7. > > Grr. I noticed this too late, but this has all been rebased very recently. > > Don't f*cking do this! Why do

Re: [PATCH] max44000: Remove scale from proximity

On 20/05/16 15:44, Crestez Dan Leonard wrote: > This is not implemented and doesn't really make sense because IIO > proximity is unit-less. > > Remove IIO_CHAN_INFO_SCALE from info_mask because so that the _scale > sysfs entry won't appear. This fixes userspace tools like generic_buffer > which

Re: [PATCH] max44000: Remove scale from proximity

On 20/05/16 15:44, Crestez Dan Leonard wrote: > This is not implemented and doesn't really make sense because IIO > proximity is unit-less. > > Remove IIO_CHAN_INFO_SCALE from info_mask because so that the _scale > sysfs entry won't appear. This fixes userspace tools like generic_buffer > which

Re: [PATCH] iio: light: jsa1212: remove unneeded i2c check functionality test

On 19/05/16 21:19, Matt Ranostay wrote: > Reviewed-by: Matt Ranostay Applied to the togreg branch of iio.git. Thanks, Jonathan > > On Thu, May 19, 2016 at 11:37 AM, sathyanarayanan kuppuswamy > wrote: >> Looks Good. >> >>

Re: [PATCH] iio: light: jsa1212: remove unneeded i2c check functionality test

On 19/05/16 21:19, Matt Ranostay wrote: > Reviewed-by: Matt Ranostay Applied to the togreg branch of iio.git. Thanks, Jonathan > > On Thu, May 19, 2016 at 11:37 AM, sathyanarayanan kuppuswamy > wrote: >> Looks Good. >> >> Reviewed-by:Kuppuswamy Sathyanarayanan >> >> >> >> On 05/15/2016 11:37

Re: [PATCH v2 03/12] of: add J-Core interrupt controller bindings

On Sat, May 21, 2016 at 08:07:54PM +0200, Geert Uytterhoeven wrote: > On Sat, May 21, 2016 at 12:34 AM, Rich Felker wrote: > > On Fri, May 20, 2016 at 10:04:26AM +0200, Geert Uytterhoeven wrote: > >> On Fri, May 20, 2016 at 4:53 AM, Rich Felker wrote: > >> >

Re: [PATCH v2 03/12] of: add J-Core interrupt controller bindings

On Sat, May 21, 2016 at 08:07:54PM +0200, Geert Uytterhoeven wrote: > On Sat, May 21, 2016 at 12:34 AM, Rich Felker wrote: > > On Fri, May 20, 2016 at 10:04:26AM +0200, Geert Uytterhoeven wrote: > >> On Fri, May 20, 2016 at 4:53 AM, Rich Felker wrote: > >> > +Additional properties required for

Re: [PATCH v5] iio: max5487: Add support for Maxim digital potentiometers

On 19/05/16 06:55, Cristina Moraru wrote: > Add implementation for Maxim MAX5487, MAX5488, MAX5489 > digital potentiometers. > > Datasheet: > http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf > > Signed-off-by: Cristina Moraru > CC: Daniel Baluta

Re: [PATCH v5] iio: max5487: Add support for Maxim digital potentiometers

On 19/05/16 06:55, Cristina Moraru wrote: > Add implementation for Maxim MAX5487, MAX5488, MAX5489 > digital potentiometers. > > Datasheet: > http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf > > Signed-off-by: Cristina Moraru > CC: Daniel Baluta Applied to the togreg branch of

Re: [PATCH] iio: Export I2C module alias information

On 17/05/16 17:25, Javier Martinez Canillas wrote: > The I2C drivers have an i2c_device_id array but that information isn't > exported to the modules using the MODULE_DEVICE_TABLE() macro. So the > modules autoloading won't work if the I2C device is registered using > OF or legacy board files due

Re: [PATCH] iio: Export I2C module alias information

On 17/05/16 17:25, Javier Martinez Canillas wrote: > The I2C drivers have an i2c_device_id array but that information isn't > exported to the modules using the MODULE_DEVICE_TABLE() macro. So the > modules autoloading won't work if the I2C device is registered using > OF or legacy board files due

Re: [PATCH 2/3] sched,fair: Fix local starvation

On Sat, 2016-05-21 at 16:04 +0200, Mike Galbraith wrote: > Wakees that were not migrated/normalized eat an unwanted min_vruntime, > and likely take a size XXL latency hit. Big box running master bled > profusely under heavy load until I turned TTWU_QUEUE off. The below made big box a happy

Re: [PATCH 2/3] sched,fair: Fix local starvation

On Sat, 2016-05-21 at 16:04 +0200, Mike Galbraith wrote: > Wakees that were not migrated/normalized eat an unwanted min_vruntime, > and likely take a size XXL latency hit. Big box running master bled > profusely under heavy load until I turned TTWU_QUEUE off. The below made big box a happy

[PATCH 0/2] f_fs: better handle excess data on read

Between this set and Du, Changbin’s patch, we now have implementation for the following three possibilities to choose from: 1. Buffer excess data (this whole patch set). 2. Fail the transfer (Du, Changbin’s patch). 3. Drop excess data (the first patch from this set). As per earlier comments, I

[PATCH 0/2] f_fs: better handle excess data on read

Between this set and Du, Changbin’s patch, we now have implementation for the following three possibilities to choose from: 1. Buffer excess data (this whole patch set). 2. Fail the transfer (Du, Changbin’s patch). 3. Drop excess data (the first patch from this set). As per earlier comments, I

[PATCH 2/2] usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests

f_fs rounds up read(2) requests to a multiple of a max packet size which means that host may provide more data than user has space for. So far, the excess data has been silently ignored. This introduces a buffer for a tail of such requests so that they are returned on next read instead of being

[PATCH 2/2] usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests

f_fs rounds up read(2) requests to a multiple of a max packet size which means that host may provide more data than user has space for. So far, the excess data has been silently ignored. This introduces a buffer for a tail of such requests so that they are returned on next read instead of being

[PATCH 1/2] usb: gadget: f_fs: printk error when excess data is dropped on read

Add a pr_err when host sent more data then the size of the buffer user space gave us. This may happen on UDCs which require OUT requests to be aligned to max packet size. The patch includes a description of the situation. Signed-off-by: Michal Nazarewicz ---

[PATCH 1/2] usb: gadget: f_fs: printk error when excess data is dropped on read

Add a pr_err when host sent more data then the size of the buffer user space gave us. This may happen on UDCs which require OUT requests to be aligned to max packet size. The patch includes a description of the situation. Signed-off-by: Michal Nazarewicz --- drivers/usb/gadget/function/f_fs.c

RE: [PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

On Thu, 19 May 2016 13:49:16 + "N, Soumya P" wrote: > Hi Steve, > > Thanks for the explanation. > I will take care of your comments and send v2 of the same patch. > >>No need, I just pulled in your patch and made the updates to the change log >>and subject myself. I'm

RE: [PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

On Thu, 19 May 2016 13:49:16 + "N, Soumya P" wrote: > Hi Steve, > > Thanks for the explanation. > I will take care of your comments and send v2 of the same patch. > >>No need, I just pulled in your patch and made the updates to the change log >>and subject myself. I'm starting my tests

Re: [PATCH v8 2/4] power: reset: add reboot mode driver

On Sun, Apr 24, 2016 at 11:55 PM, Andy Yan wrote: [..] > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig [..] > +config SYSCON_REBOOT_MODE > + bool "Generic SYSCON regmap reboot mode driver" > + depends on OF As this isn't really

Re: [PATCH v8 2/4] power: reset: add reboot mode driver

On Sun, Apr 24, 2016 at 11:55 PM, Andy Yan wrote: [..] > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig [..] > +config SYSCON_REBOOT_MODE > + bool "Generic SYSCON regmap reboot mode driver" > + depends on OF As this isn't really useful without syscon (but

Re: [GIT PULL] RTC for 4.7

On Sat, May 21, 2016 at 8:15 AM, Alexandre Belloni wrote: > > Here is the pull-request for the RTC subsystem for 4.7. Grr. I noticed this too late, but this has all been rebased very recently. Don't f*cking do this! Why do I have to tell people every single

Re: [GIT PULL] RTC for 4.7

On Sat, May 21, 2016 at 8:15 AM, Alexandre Belloni wrote: > > Here is the pull-request for the RTC subsystem for 4.7. Grr. I noticed this too late, but this has all been rebased very recently. Don't f*cking do this! Why do I have to tell people every single merge window? Linus

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

On Wed, May 18, 2016 at 12:07:02AM +0800, jeffrey.lin wrote: > Hi Dmitry: > > >static int raydium_i2c_read_message(struct i2c_client *client, > > > u32 addr, void *data, size_t len) > > >{ > > > __be32 be_addr; > > > size_t xfer_len; > > > int error; > > >

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

On Wed, May 18, 2016 at 12:07:02AM +0800, jeffrey.lin wrote: > Hi Dmitry: > > >static int raydium_i2c_read_message(struct i2c_client *client, > > > u32 addr, void *data, size_t len) > > >{ > > > __be32 be_addr; > > > size_t xfer_len; > > > int error; > > >

[PATCH 2/2] iommu/amd: Destroy api_lock mutex when freeing domain

From: Jan Vesely Signed-off-by: Jan Vesely --- drivers/iommu/amd_iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 17c76f2..4ff5e40 100644 --- a/drivers/iommu/amd_iommu.c +++

[PATCH 1/2] iommu/amd: Remove entry from the list before freeing it

From: Jan Vesely Signed-off-by: Jan Vesely --- drivers/iommu/amd_iommu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 634f636..17c76f2 100644 ---

[PATCH 1/2] iommu/amd: Remove entry from the list before freeing it

From: Jan Vesely Signed-off-by: Jan Vesely --- drivers/iommu/amd_iommu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 634f636..17c76f2 100644 --- a/drivers/iommu/amd_iommu.c +++ b/drivers/iommu/amd_iommu.c @@

[PATCH 2/2] iommu/amd: Destroy api_lock mutex when freeing domain

From: Jan Vesely Signed-off-by: Jan Vesely --- drivers/iommu/amd_iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 17c76f2..4ff5e40 100644 --- a/drivers/iommu/amd_iommu.c +++ b/drivers/iommu/amd_iommu.c @@ -3016,6 +3016,7 @@

Re: [PATCH v2 03/12] of: add J-Core interrupt controller bindings

On Sat, May 21, 2016 at 12:34 AM, Rich Felker wrote: > On Fri, May 20, 2016 at 10:04:26AM +0200, Geert Uytterhoeven wrote: >> On Fri, May 20, 2016 at 4:53 AM, Rich Felker wrote: >> > +Additional properties required for aic1: >> > + >> > +- reg : Memory region

Re: [PATCH v2 03/12] of: add J-Core interrupt controller bindings

On Sat, May 21, 2016 at 12:34 AM, Rich Felker wrote: > On Fri, May 20, 2016 at 10:04:26AM +0200, Geert Uytterhoeven wrote: >> On Fri, May 20, 2016 at 4:53 AM, Rich Felker wrote: >> > +Additional properties required for aic1: >> > + >> > +- reg : Memory region for configuration. >> > + >> > +-

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

Sasha Levin writes: > On 05/18/2016 12:05 PM, Greg Kroah-Hartman wrote: >> On Wed, May 18, 2016 at 11:18:16AM -0400, Sasha Levin wrote: >>> On 05/18/2016 11:01 AM, Nicolai Stange wrote: Thanks a million for reporting! 1.) Do you have lockdep enabled? >>>

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

Sasha Levin writes: > On 05/18/2016 12:05 PM, Greg Kroah-Hartman wrote: >> On Wed, May 18, 2016 at 11:18:16AM -0400, Sasha Levin wrote: >>> On 05/18/2016 11:01 AM, Nicolai Stange wrote: Thanks a million for reporting! 1.) Do you have lockdep enabled? >>> >>> Yup, nothing there.

Re: [GIT PULL] Driver core update for 4.7-rc1

On Sat, May 21, 2016 at 10:16 AM, William Breathitt Gray wrote: > > Would you like me to submit a patchset after your commit to introduce > the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant > drivers' Kconfig options to depend on the ISA_BUS_API? Yes

Re: [GIT PULL] Driver core update for 4.7-rc1

On Sat, May 21, 2016 at 10:16 AM, William Breathitt Gray wrote: > > Would you like me to submit a patchset after your commit to introduce > the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant > drivers' Kconfig options to depend on the ISA_BUS_API? Yes please.

Re: [GIT PULL] Driver core update for 4.7-rc1

On Sat, May 21, 2016 at 09:59:09AM -0700, Linus Torvalds wrote: >Author: Linus Torvalds >Date: Sat May 21 09:13:41 2016 -0700 > >x86 isa: add back X86_32 dependency on CONFIG_ISA > >Commit b3c1be1b789c ("base: isa: Remove X86_32 dependency") made ISA >

Re: [GIT PULL] Driver core update for 4.7-rc1

On Sat, May 21, 2016 at 09:59:09AM -0700, Linus Torvalds wrote: >Author: Linus Torvalds >Date: Sat May 21 09:13:41 2016 -0700 > >x86 isa: add back X86_32 dependency on CONFIG_ISA > >Commit b3c1be1b789c ("base: isa: Remove X86_32 dependency") made ISA >support available on x86-64

Re: sem_lock() vs qspinlocks

On Sat, 21 May 2016, Peter Zijlstra wrote: On Fri, May 20, 2016 at 05:48:39PM -0700, Davidlohr Bueso wrote: On Fri, 20 May 2016, Linus Torvalds wrote: >Oh, I definitely agree on the stable part, and yes, the "splt things >up" model should come later if people agree that it's a good thing.

Re: sem_lock() vs qspinlocks

On Sat, 21 May 2016, Peter Zijlstra wrote: On Fri, May 20, 2016 at 05:48:39PM -0700, Davidlohr Bueso wrote: On Fri, 20 May 2016, Linus Torvalds wrote: >Oh, I definitely agree on the stable part, and yes, the "splt things >up" model should come later if people agree that it's a good thing.

Re: [PATCH v2 1/6] power: Introduce Broadcom kona reset driver

Le 11/05/2016 14:36, Chris Brand a écrit : > This driver supports reset on both BCM21664 and BCM23550. > Code is being moved from arch/arm/mach-bcm/board_bcm21664.c > > Signed-off-by: Chris Brand Sebastian, Dmitry, I know we are in the merge window, let me know if you

Re: [PATCH v2 1/6] power: Introduce Broadcom kona reset driver

Le 11/05/2016 14:36, Chris Brand a écrit : > This driver supports reset on both BCM21664 and BCM23550. > Code is being moved from arch/arm/mach-bcm/board_bcm21664.c > > Signed-off-by: Chris Brand Sebastian, Dmitry, I know we are in the merge window, let me know if you would want me to take this

Re: [GIT PULL] Driver core update for 4.7-rc1

On Sat, May 21, 2016 at 9:31 AM, Linus Torvalds wrote: > > We're not suddenly enabling ISA on x86-64 after having successfully > gotten rid of that insane crap long long ago. > > If you have *specific* dribvers that are actually relevant for some > reason, make

Re: [GIT PULL] Driver core update for 4.7-rc1

On Sat, May 21, 2016 at 9:31 AM, Linus Torvalds wrote: > > We're not suddenly enabling ISA on x86-64 after having successfully > gotten rid of that insane crap long long ago. > > If you have *specific* dribvers that are actually relevant for some > reason, make those ones available based on other

Re: [PATCH] spi: spidev: fix possible arithmetic overflow for multi-transfer message

On Mon, Mar 23, 2015 at 10:50 AM, Ian Abbott wrote: > `spidev_message()` sums the lengths of the individual SPI transfers to > determine the overall SPI message length. It restricts the total > length, returning an error if too long, but it does not check for > arithmetic

Re: [PATCH] spi: spidev: fix possible arithmetic overflow for multi-transfer message

On Mon, Mar 23, 2015 at 10:50 AM, Ian Abbott wrote: > `spidev_message()` sums the lengths of the individual SPI transfers to > determine the overall SPI message length. It restricts the total > length, returning an error if too long, but it does not check for > arithmetic overflow. For example,

Re: PROBLEM: Resume form hibernate broken by setting NX on gap

On Fri, May 20, 2016 at 6:57 PM, Logan Gunthorpe wrote: > On 20/05/16 04:16 PM, Kees Cook wrote: >> >> On Fri, May 20, 2016 at 2:59 PM, Kees Cook wrote: >>> >>> On Fri, May 20, 2016 at 2:46 PM, Rafael J. Wysocki >>> wrote:

Re: PROBLEM: Resume form hibernate broken by setting NX on gap

On Fri, May 20, 2016 at 6:57 PM, Logan Gunthorpe wrote: > On 20/05/16 04:16 PM, Kees Cook wrote: >> >> On Fri, May 20, 2016 at 2:59 PM, Kees Cook wrote: >>> >>> On Fri, May 20, 2016 at 2:46 PM, Rafael J. Wysocki >>> wrote: On Fri, May 20, 2016 at 3:56 PM, Stephen Smalley wrote:

Re: [RFT PATCH] iio: magn: Add support for BMM150 magnetometer

On 18/05/16 15:01, Daniel Baluta wrote: > On Wed, May 4, 2016 at 1:26 PM, Jonathan Cameron wrote: >> On 27/04/16 15:55, Lucas De Marchi wrote: >>> On Tue, Apr 26, 2016 at 9:39 AM, Daniel Baluta >>> wrote: BMM150 is register compatible with

Re: [RFT PATCH] iio: magn: Add support for BMM150 magnetometer

On 18/05/16 15:01, Daniel Baluta wrote: > On Wed, May 4, 2016 at 1:26 PM, Jonathan Cameron wrote: >> On 27/04/16 15:55, Lucas De Marchi wrote: >>> On Tue, Apr 26, 2016 at 9:39 AM, Daniel Baluta >>> wrote: BMM150 is register compatible with magnetometer part of BMC156.

Re: [GIT PULL] Driver core update for 4.7-rc1

On Sat, May 21, 2016 at 9:20 AM, William Breathitt Gray wrote: > > I'll submit patches to resolve these warnings and errors. No. I will disable that ISA config option. We're not randomly making old drivers available on modern platforms. Really. We're not suddenly

Re: [GIT PULL] Driver core update for 4.7-rc1

On Sat, May 21, 2016 at 9:20 AM, William Breathitt Gray wrote: > > I'll submit patches to resolve these warnings and errors. No. I will disable that ISA config option. We're not randomly making old drivers available on modern platforms. Really. We're not suddenly enabling ISA on x86-64 after

Re: [PATCH 2/2] iio: generic_buffer: Add --device-num option

On 20/05/16 16:45, Crestez Dan Leonard wrote: > This makes it possible to distinguish between iio devices with the same > name. > > Signed-off-by: Crestez Dan Leonard happy with this and will pickup once the first patch is sorted. Jonathan > --- >

Re: [PATCH 2/2] iio: generic_buffer: Add --device-num option

On 20/05/16 16:45, Crestez Dan Leonard wrote: > This makes it possible to distinguish between iio devices with the same > name. > > Signed-off-by: Crestez Dan Leonard happy with this and will pickup once the first patch is sorted. Jonathan > --- > tools/iio/generic_buffer.c | 53 >

Re: [PATCH 1/2] iio: generic_buffer: Cleanup when receiving signals

On 20/05/16 16:55, Peter Meerwald-Stadler wrote: > >> This also drops all the code freeing string buffers at the end of main. >> Memory is freed when the process exits anyway so there's no point in >> cluttering the code with all those gotos. > > well, it helps to see that all memory has been

Re: [PATCH 1/2] iio: generic_buffer: Cleanup when receiving signals

On 20/05/16 16:55, Peter Meerwald-Stadler wrote: > >> This also drops all the code freeing string buffers at the end of main. >> Memory is freed when the process exits anyway so there's no point in >> cluttering the code with all those gotos. > > well, it helps to see that all memory has been

Re: [PATCH] iio: humidity: hdc100x: add HDC1000 and HDC1008 product names

On 20/05/16 18:34, Matt Ranostay wrote: > On Fri, May 20, 2016 at 10:05 AM, Alison Schofield > wrote: >> hdc100x supports Texas Instruments HDC1000 and HDC1008 relative >> humidity and temperature sensors. Add these product names to >> Kconfig and to the drivers device id

Re: [PATCH] iio: humidity: hdc100x: add HDC1000 and HDC1008 product names

On 20/05/16 18:34, Matt Ranostay wrote: > On Fri, May 20, 2016 at 10:05 AM, Alison Schofield > wrote: >> hdc100x supports Texas Instruments HDC1000 and HDC1008 relative >> humidity and temperature sensors. Add these product names to >> Kconfig and to the drivers device id structure to enable

Re: [PATCH] iio: humidity: hdc100x: correct humidity integration time mask

On 20/05/16 18:44, Matt Ranostay wrote: > Reviewed-by: Matt Ranostay > > On Fri, May 20, 2016 at 10:06 AM, Alison Schofield > wrote: >> Apply the correct mask to enable all available humidity integration >> times. Currently, the driver defaults to

Re: [PATCH] iio: humidity: hdc100x: correct humidity integration time mask

On 20/05/16 18:44, Matt Ranostay wrote: > Reviewed-by: Matt Ranostay > > On Fri, May 20, 2016 at 10:06 AM, Alison Schofield > wrote: >> Apply the correct mask to enable all available humidity integration >> times. Currently, the driver defaults to 6500 and all is okay with that. >> However,

  1   2   >