[Patch v5 1/2] arm: kernel: Add SMC structure parameter

This patch adds a quirk parameter to the arm_smccc_smc call. The quirk structure allows for specialized SMC operations due to SoC specific requirements. The current arm_smccc_smc is renamed and macros are used instead to specify the standard arm_smccc_smc or the arm_smccc_smc_quirk function.

[Patch v5 2/2] firmware: qcom: scm: Fix interrupted SCM calls

This patch adds a Qualcomm specific quirk to the arm_smccc_smc call. On Qualcomm ARM64 platforms, the SMC call can return before it has completed. If this occurs, the call can be restarted, but it requires using the returned session ID value from the interrupted SMC call. The quirk stores off

[no subject]

Subject: [Patch v5 0/2] Support ARM SMCC SoC vendor quirks At least one SoC vendor (Qualcomm) requires additional processing done during ARM SMCCC calls. As such, an additional parameter to the arm_smccc_smc is required to be able to handle SoC specific quirks. The Qualcomm quirk is necessary

[Patch v5 1/2] arm: kernel: Add SMC structure parameter

This patch adds a quirk parameter to the arm_smccc_smc call. The quirk structure allows for specialized SMC operations due to SoC specific requirements. The current arm_smccc_smc is renamed and macros are used instead to specify the standard arm_smccc_smc or the arm_smccc_smc_quirk function.

[Patch v5 2/2] firmware: qcom: scm: Fix interrupted SCM calls

This patch adds a Qualcomm specific quirk to the arm_smccc_smc call. On Qualcomm ARM64 platforms, the SMC call can return before it has completed. If this occurs, the call can be restarted, but it requires using the returned session ID value from the interrupted SMC call. The quirk stores off

[no subject]

Subject: [Patch v5 0/2] Support ARM SMCC SoC vendor quirks At least one SoC vendor (Qualcomm) requires additional processing done during ARM SMCCC calls. As such, an additional parameter to the arm_smccc_smc is required to be able to handle SoC specific quirks. The Qualcomm quirk is necessary

[PATCH v5 0/2] PM / devfreq: Change the device name on sysfs entry

These patches change the name of sysfs entry for devfreq/devfreq-event device as following: - old For devfreq, /sys/class/devfreq/[non-standard device name] For devfreq-event, /sys/class/devfreq-event/event.(X) - new For devfreq, /sys/class/devfreq/devfreq(X) For devfreq-event,

[PATCH v5 1/2] PM / devfreq: Simplify the sysfs name of devfreq-event device

This patch just removes '.' character from the sysfs name of devfreq-event device as following. Usually, the subsystem uses the similiar naming style such as {framework name}{Number}. - old : /sys/class/devfreq-event/event.(X) - new : /sys/class/devfreq-event/event(X) And this patch initializes

[PATCH v5 0/2] PM / devfreq: Change the device name on sysfs entry

These patches change the name of sysfs entry for devfreq/devfreq-event device as following: - old For devfreq, /sys/class/devfreq/[non-standard device name] For devfreq-event, /sys/class/devfreq-event/event.(X) - new For devfreq, /sys/class/devfreq/devfreq(X) For devfreq-event,

[PATCH v5 1/2] PM / devfreq: Simplify the sysfs name of devfreq-event device

This patch just removes '.' character from the sysfs name of devfreq-event device as following. Usually, the subsystem uses the similiar naming style such as {framework name}{Number}. - old : /sys/class/devfreq-event/event.(X) - new : /sys/class/devfreq-event/event(X) And this patch initializes

[PATCH v5 2/2] PM / devfreq: Modify the device name as devfreq(X) for sysfs

This patch modifies the device name as devfreq(X) for sysfs by using the 'devfreq' prefix word instead of separate device name. On user-space aspect, user would find the some devfreq drvier with 'devfreq(X)' pattern. So, this patch modify the device name as following: -

[PATCH v5 2/2] PM / devfreq: Modify the device name as devfreq(X) for sysfs

This patch modifies the device name as devfreq(X) for sysfs by using the 'devfreq' prefix word instead of separate device name. On user-space aspect, user would find the some devfreq drvier with 'devfreq(X)' pattern. So, this patch modify the device name as following: -

Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes

On 2017/01/31 07:43AM, Michael Ellerman wrote: > Anju T Sudhakar writes: > > > Detour buffer contains instructions to create an in memory pt_regs. > > After the execution of the pre-handler, a call is made for instruction > > emulation. > > The NIP is determined in

Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes

On 2017/01/31 07:43AM, Michael Ellerman wrote: > Anju T Sudhakar writes: > > > Detour buffer contains instructions to create an in memory pt_regs. > > After the execution of the pre-handler, a call is made for instruction > > emulation. > > The NIP is determined in advanced through dummy

[RFC PATCH v2] Input: gpio_keys - add dt abs/rel button support

This change adds support for specifying device tree buttons emitting abs/rel events. ABS events were previously supported, but only via platform data, so add the missing device tree property to allow axis values to be emitted with abs/rel events. Also emit 0 on button releases for REL and ABS

[RFC PATCH v2] Input: gpio_keys - add dt abs/rel button support

This change adds support for specifying device tree buttons emitting abs/rel events. ABS events were previously supported, but only via platform data, so add the missing device tree property to allow axis values to be emitted with abs/rel events. Also emit 0 on button releases for REL and ABS

Re: [PATCH 1/2 v2] mm: vmscan: do not pass reclaimed slab to vmpressure

On Tue, Jan 31, 2017 at 5:26 AM, Minchan Kim wrote: > On Fri, Jan 27, 2017 at 01:43:36PM +0530, Vinayak Menon wrote: >> It is noticed that during a global reclaim the memory >> reclaimed via shrinking the slabs can sometimes result >> in reclaimed pages being greater than the

Re: [PATCH 1/2 v2] mm: vmscan: do not pass reclaimed slab to vmpressure

On Tue, Jan 31, 2017 at 5:26 AM, Minchan Kim wrote: > On Fri, Jan 27, 2017 at 01:43:36PM +0530, Vinayak Menon wrote: >> It is noticed that during a global reclaim the memory >> reclaimed via shrinking the slabs can sometimes result >> in reclaimed pages being greater than the scanned pages >> in

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

* Mike Galbraith wrote: > On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > > * Mike Galbraith wrote: > > > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew > > > an early boot brick problem. > > > > That's bad - could you perhaps

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

* Mike Galbraith wrote: > On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > > * Mike Galbraith wrote: > > > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew > > > an early boot brick problem. > > > > That's bad - could you perhaps try to bisect it? All recently

Re: [PATCH] x86/microcode: Do not access the initrd after it has been freed

(Cc:-ed Mike as this could explain his early boot crash/hang? Mike: please try -tip f18a8a0143b1 that I just pushed out. ) * Borislav Petkov wrote: > On Mon, Jan 30, 2017 at 09:46:32AM +0100, Ingo Molnar wrote: > > Ok, I have applied this to tip:x86/urgent. > > > >

Re: [PATCH] x86/microcode: Do not access the initrd after it has been freed

(Cc:-ed Mike as this could explain his early boot crash/hang? Mike: please try -tip f18a8a0143b1 that I just pushed out. ) * Borislav Petkov wrote: > On Mon, Jan 30, 2017 at 09:46:32AM +0100, Ingo Molnar wrote: > > Ok, I have applied this to tip:x86/urgent. > > > > Note that there are

[PATCH v3] DM: dm-inplace-compress: inplace compressed DM target

This patch provides a generic device-mapper compression device. Originally written by Shaohua Li. https://www.redhat.com/archives/dm-devel/2013-December/msg00143.html I have optimized and hardened the code. Testing: --- This compression block device is tested in the following

[PATCH v3 1/1] DM: inplace compressed DM target

This is a simple DM target supporting inplace compression. Its best suited for SSD. The underlying disk must support 512B sector size. The target only supports 4k sector size. Disk layout: |super|...meta...|..data...| Store unit is 4k (a block). Super is 1 block, which stores meta and data size

[PATCH v3] DM: dm-inplace-compress: inplace compressed DM target

This patch provides a generic device-mapper compression device. Originally written by Shaohua Li. https://www.redhat.com/archives/dm-devel/2013-December/msg00143.html I have optimized and hardened the code. Testing: --- This compression block device is tested in the following

[PATCH v3 1/1] DM: inplace compressed DM target

This is a simple DM target supporting inplace compression. Its best suited for SSD. The underlying disk must support 512B sector size. The target only supports 4k sector size. Disk layout: |super|...meta...|..data...| Store unit is 4k (a block). Super is 1 block, which stores meta and data size

Re: [PATCH v8 07/12] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings

On 2017-01-30 18:20, Rob Herring wrote: > On Sat, Jan 28, 2017 at 4:42 PM, Peter Rosin wrote: >> On 2017-01-27 20:39, Rob Herring wrote: >>> On Wed, Jan 18, 2017 at 04:57:10PM +0100, Peter Rosin wrote: Describe how a generic multiplexer controller is used to mux an i2c bus.

Re: [PATCH v8 07/12] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings

On 2017-01-30 18:20, Rob Herring wrote: > On Sat, Jan 28, 2017 at 4:42 PM, Peter Rosin wrote: >> On 2017-01-27 20:39, Rob Herring wrote: >>> On Wed, Jan 18, 2017 at 04:57:10PM +0100, Peter Rosin wrote: Describe how a generic multiplexer controller is used to mux an i2c bus.

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > * Mike Galbraith wrote: > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew > > an early boot brick problem. > > That's bad - could you perhaps try to bisect it? All recently queued up > patches >

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > * Mike Galbraith wrote: > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew > > an early boot brick problem. > > That's bad - could you perhaps try to bisect it? All recently queued up > patches > that could cause

Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero()

* Fabian Frederick wrote: > complementary definition to atomic_inc_not_zero() featured in > lib/fault-inject.c > > Signed-off-by: Fabian Frederick > --- > include/linux/atomic.h | 2 ++ > lib/fault-inject.c | 2 -- > 2 files changed, 2 insertions(+), 2

Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero()

* Fabian Frederick wrote: > complementary definition to atomic_inc_not_zero() featured in > lib/fault-inject.c > > Signed-off-by: Fabian Frederick > --- > include/linux/atomic.h | 2 ++ > lib/fault-inject.c | 2 -- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

* Robert O'Callahan wrote: > pmc_reprogram_counter() always sets a sample period based on the value of > pmc->counter. However, hsw_hw_config() rejects sample periods less than > 2^31 - 1. So for example, a KVM guest doing > perf stat -e r2005101c4 sleep 0 > will count

Re: [PATCH] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

* Robert O'Callahan wrote: > pmc_reprogram_counter() always sets a sample period based on the value of > pmc->counter. However, hsw_hw_config() rejects sample periods less than > 2^31 - 1. So for example, a KVM guest doing > perf stat -e r2005101c4 sleep 0 > will count some conditional branch

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

On 01/30/2017 05:57 PM, Dave Hansen wrote: On 01/30/2017 05:36 PM, Anshuman Khandual wrote: Let's say we had a CDM node with 100x more RAM than the rest of the system and it was just as fast as the rest of the RAM. Would we still want it isolated like this? Or would we want a different

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

On 01/30/2017 05:57 PM, Dave Hansen wrote: On 01/30/2017 05:36 PM, Anshuman Khandual wrote: Let's say we had a CDM node with 100x more RAM than the rest of the system and it was just as fast as the rest of the RAM. Would we still want it isolated like this? Or would we want a different

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

* Mike Galbraith wrote: > On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote: > > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote: > > > Running Steven's hotplug stress script in tip.today. Config is > > > NOPREEMPT, tune for maximum build time (enterprise default-ish). >

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

* Mike Galbraith wrote: > On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote: > > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote: > > > Running Steven's hotplug stress script in tip.today. Config is > > > NOPREEMPT, tune for maximum build time (enterprise default-ish). > > > > > > [

[PATCH v2] iio: accel: Add driver for the Analog Devices ADXL345 3-axis accelerometer

Add basic IIO support for the Analog Devices ADXL345 3-axis accelerometer. The datasheet can be found here: http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf Signed-off-by: Eva Rachel Retuya Cc: Michael Hennerich

[PATCH v2] iio: accel: Add driver for the Analog Devices ADXL345 3-axis accelerometer

Add basic IIO support for the Analog Devices ADXL345 3-axis accelerometer. The datasheet can be found here: http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf Signed-off-by: Eva Rachel Retuya Cc: Michael Hennerich Cc: Daniel Baluta Cc: Alison Schofield --- v1

Re: [PATCH v2 2/2] iio: distance: add devantech us ranger srf04

> > + indio_dev->num_channels = ARRAY_SIZE(srf04_chan_spec); > > + > > + return iio_device_register(indio_dev); > > +} > > + > > +static int srf04_remove(struct platform_device *pdev) > > +{ > > + struct iio_dev *indio_dev = platform_get_drvdata(pdev); > > + > > +

Re: [PATCH v2 2/2] iio: distance: add devantech us ranger srf04

> > + indio_dev->num_channels = ARRAY_SIZE(srf04_chan_spec); > > + > > + return iio_device_register(indio_dev); > > +} > > + > > +static int srf04_remove(struct platform_device *pdev) > > +{ > > + struct iio_dev *indio_dev = platform_get_drvdata(pdev); > > + > > +

RE: [PATCH V2 07/12] PM / OPP: Update OPP users to put reference

> This patch updates dev_pm_opp_find_freq_*() routines to get a reference > to the OPPs returned by them. > > Also updates the users of dev_pm_opp_find_freq_*() routines to call > dev_pm_opp_put() after they are done using the OPPs. > > As it is guaranteed the that OPPs wouldn't get freed while

Re: next-20170125 hangs on aarch64

t; the > > >> attempt to dereference the ENOSYS error code as the address. > > >> next-20170124 works > > >> fine, at least it boots. > > >> > > >> Does anyone have details on that? > > > > I hit this with next-20170130 too,

RE: [PATCH V2 07/12] PM / OPP: Update OPP users to put reference

> This patch updates dev_pm_opp_find_freq_*() routines to get a reference > to the OPPs returned by them. > > Also updates the users of dev_pm_opp_find_freq_*() routines to call > dev_pm_opp_put() after they are done using the OPPs. > > As it is guaranteed the that OPPs wouldn't get freed while

Re: next-20170125 hangs on aarch64

t; the > > >> attempt to dereference the ENOSYS error code as the address. > > >> next-20170124 works > > >> fine, at least it boots. > > >> > > >> Does anyone have details on that? > > > > I hit this with next-20170130 too,

linux-next: Tree for Jan 31

Hi all, Changes since 20170130: New tree: idr Dropped tree: vfs-miklos (build failure and out of date) The vfs-miklos tree gained a conflict against the overlayfs tree and a build failure, so I just dropped it for today. The v4l-dvb tree gained a build failure so I used the version from next

linux-next: Tree for Jan 31

Hi all, Changes since 20170130: New tree: idr Dropped tree: vfs-miklos (build failure and out of date) The vfs-miklos tree gained a conflict against the overlayfs tree and a build failure, so I just dropped it for today. The v4l-dvb tree gained a build failure so I used the version from next

Re: [PATCH v6 4/5] iio: light: lm3533-als: Support initialization from Device Tree

> Implement support for initialization of the lm3533 als driver from > Device Tree. minor comment below > Signed-off-by: Bjorn Andersson > Signed-off-by: Bjorn Andersson > --- > > Note that this patch can be merged independently of

Re: [PATCH v6 4/5] iio: light: lm3533-als: Support initialization from Device Tree

> Implement support for initialization of the lm3533 als driver from > Device Tree. minor comment below > Signed-off-by: Bjorn Andersson > Signed-off-by: Bjorn Andersson > --- > > Note that this patch can be merged independently of the other patches in the > series. > > Changes since v5: >

Re: [PATCH] [RFC] fs: Possible filp_open race experiment

On Tue, Jan 31, 2017 at 06:29:36AM +0100, Marek Vasut wrote: > +CC Greg, LKML as I don't quite know where this should go. You do know about linux-fsdevel, right? > On 01/18/2017 12:16 AM, Marek Vasut wrote: > > I believe there is a possible race condition when configfs attributes > > trigger

Re: [PATCH] [RFC] fs: Possible filp_open race experiment

On Tue, Jan 31, 2017 at 06:29:36AM +0100, Marek Vasut wrote: > +CC Greg, LKML as I don't quite know where this should go. You do know about linux-fsdevel, right? > On 01/18/2017 12:16 AM, Marek Vasut wrote: > > I believe there is a possible race condition when configfs attributes > > trigger

crash in perf_event_read

Hi Peter, rarely I'm seeing the following crash: [40196.164255] BUG: unable to handle kernel paging request at a11a [40196.179636] IP: perf_event_read+0xd3/0x1a0 [40196.188669] PGD 82e93a067 [40196.188670] PUD 7e1ddf067 [40196.194629] PMD 0 [40196.200589] [40196.208284] Oops:

crash in perf_event_read

Hi Peter, rarely I'm seeing the following crash: [40196.164255] BUG: unable to handle kernel paging request at a11a [40196.179636] IP: perf_event_read+0xd3/0x1a0 [40196.188669] PGD 82e93a067 [40196.188670] PUD 7e1ddf067 [40196.194629] PMD 0 [40196.200589] [40196.208284] Oops:

Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I

Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I

RE: [PATCH v2 1/3] PM / devfreq: Fix available_governor sysfs

> The devfreq using passive governor is not able to change the governor. > So, the user can not change the governor through 'available_governor' sysfs > entry. Also, the devfreq which don't use the passive governor is not able to > change to 'passive' governor on the fly. > > Fixes: 996133119f57

RE: [PATCH v2 1/3] PM / devfreq: Fix available_governor sysfs

> The devfreq using passive governor is not able to change the governor. > So, the user can not change the governor through 'available_governor' sysfs > entry. Also, the devfreq which don't use the passive governor is not able to > change to 'passive' governor on the fly. > > Fixes: 996133119f57

Re: linux-next: manual merge of the vfs-miklos tree with the overlayfs tree and build failure

On Tue, Jan 31, 2017 at 2:16 AM, Stephen Rothwell wrote: > Hi Miklos, > > Today's linux-next merge of the vfs-miklos tree got a conflict in: > > fs/read_write.c > > between commit: > > 97e147358bea ("vfs: wrap write f_ops with file_{start,end}_write()") > > from the

Re: [GIT PULL rcu/next] RCU commits for 4.11

* Paul E. McKenney wrote: > Hello, Ingo, > > This pull request contains the following changes: > > 1.Documentation updates. > > http://lkml.kernel.org/r/20170114085032.ga18...@linux.vnet.ibm.com > > 2.Dyntick updates, consolidating open-coded

Re: linux-next: manual merge of the vfs-miklos tree with the overlayfs tree and build failure

On Tue, Jan 31, 2017 at 2:16 AM, Stephen Rothwell wrote: > Hi Miklos, > > Today's linux-next merge of the vfs-miklos tree got a conflict in: > > fs/read_write.c > > between commit: > > 97e147358bea ("vfs: wrap write f_ops with file_{start,end}_write()") > > from the overlayfs tree and various

Re: [GIT PULL rcu/next] RCU commits for 4.11

* Paul E. McKenney wrote: > Hello, Ingo, > > This pull request contains the following changes: > > 1.Documentation updates. > > http://lkml.kernel.org/r/20170114085032.ga18...@linux.vnet.ibm.com > > 2.Dyntick updates, consolidating open-coded counter accesses > into a

Re: fs, net: deadlock between bind/splice on af_unix

On Thu, Jan 26, 2017 at 10:41 PM, Mateusz Guzik wrote: > On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote: >> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik wrote: >> > Currently the file creation is potponed until unix_bind can no longer >> > fail

Re: fs, net: deadlock between bind/splice on af_unix

On Thu, Jan 26, 2017 at 10:41 PM, Mateusz Guzik wrote: > On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote: >> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik wrote: >> > Currently the file creation is potponed until unix_bind can no longer >> > fail otherwise. With it reordered, it may

[PATCH v2 2/3] PM / devfreq: Fix wrong trans_stat of passive devfreq device

Until now, the trans_stat information of passive devfreq is not updated. This patch updates the trans_stat information after setting the target frequency of passive devfreq device. Fixes: 996133119f57 ("PM / devfreq: Add new passive governor") Cc: sta...@vger.kernel.org Signed-off-by: Chanwoo

[PATCH v2 3/3] PM / devfreq: Remove unnecessary separate _remove_devfreq()

The _remove_devfreq() releases the all resources of the devfreq device. This function is only called in the devfreq_dev_release(). For that reason, the devfreq core doesn't need to leave the _remove_devfreq() separately. This patch releases the all resources in the devfreq_dev_release() and then

[PATCH v2 2/3] PM / devfreq: Fix wrong trans_stat of passive devfreq device

Until now, the trans_stat information of passive devfreq is not updated. This patch updates the trans_stat information after setting the target frequency of passive devfreq device. Fixes: 996133119f57 ("PM / devfreq: Add new passive governor") Cc: sta...@vger.kernel.org Signed-off-by: Chanwoo

[PATCH v2 3/3] PM / devfreq: Remove unnecessary separate _remove_devfreq()

The _remove_devfreq() releases the all resources of the devfreq device. This function is only called in the devfreq_dev_release(). For that reason, the devfreq core doesn't need to leave the _remove_devfreq() separately. This patch releases the all resources in the devfreq_dev_release() and then

[PATCH v2 1/3] PM / devfreq: Fix available_governor sysfs

The devfreq using passive governor is not able to change the governor. So, the user can not change the governor through 'available_governor' sysfs entry. Also, the devfreq which don't use the passive governor is not able to change to 'passive' governor on the fly. Fixes: 996133119f57 ("PM /

[PATCH v2 1/3] PM / devfreq: Fix available_governor sysfs

The devfreq using passive governor is not able to change the governor. So, the user can not change the governor through 'available_governor' sysfs entry. Also, the devfreq which don't use the passive governor is not able to change to 'passive' governor on the fly. Fixes: 996133119f57 ("PM /

[PATCH v2 0/3] PM / devfreq: Fix issues about passive governor

This patchset fix the two issues about passive governor and remove the unneeded separate _remove_devfreq() function. First, the parent devfreq device can use the governors except for the passive governor on the fly through sysfs entry and the passive devfreq device is only possible to use the

[PATCH v2 0/3] PM / devfreq: Fix issues about passive governor

This patchset fix the two issues about passive governor and remove the unneeded separate _remove_devfreq() function. First, the parent devfreq device can use the governors except for the passive governor on the fly through sysfs entry and the passive devfreq device is only possible to use the

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

Tony Lindgren writes: > * Pavel Machek [170127 11:41]: >> On Fri 2017-01-27 17:23:07, Kalle Valo wrote: >> > Pali Rohár writes: >> > >> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote: >> > >> Pali Rohár

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

Tony Lindgren writes: > * Pavel Machek [170127 11:41]: >> On Fri 2017-01-27 17:23:07, Kalle Valo wrote: >> > Pali Rohár writes: >> > >> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote: >> > >> Pali Rohár writes: >> > >> >> > >> > 2) It was already tested that example NVS data can be

RE: Re: [PATCH v4 1/4] PM / devfreq: Fix the wrong description for userspace governor

> On Tue, Jan 24, 2017 at 4:42 AM, MyungJoo Ham > wrote: > >> This patch fixes the wrong description of governor_userspace.c > >> and removes the unneeded blank line. > >> > >> Signed-off-by: Chanwoo Choi > >> --- > > > > Applied in for-next > >

[PATCH 2/2] ASoC: qcom: Drop __func__ usage from log prints

The combination of dev_err() and __func__ make most of these log prints over 100 chars long. Remove the usage of __func__ to clean the kernel log and as the usage is not necessary to identify the individual log prints. Cc: Banajit Goswami Cc: Patrick Lai

RE: Re: [PATCH v4 1/4] PM / devfreq: Fix the wrong description for userspace governor

> On Tue, Jan 24, 2017 at 4:42 AM, MyungJoo Ham > wrote: > >> This patch fixes the wrong description of governor_userspace.c > >> and removes the unneeded blank line. > >> > >> Signed-off-by: Chanwoo Choi > >> --- > > > > Applied in for-next > > > Quite frankly I'm not entirely sure what's

[PATCH 2/2] ASoC: qcom: Drop __func__ usage from log prints

The combination of dev_err() and __func__ make most of these log prints over 100 chars long. Remove the usage of __func__ to clean the kernel log and as the usage is not necessary to identify the individual log prints. Cc: Banajit Goswami Cc: Patrick Lai Cc: Srinivas Kandagatla Signed-off-by:

Re: [Patch v4 2/2] firmware: qcom: scm: Fix interrupted SCM calls

On Mon, Jan 30, 2017 at 2:55 AM, Will Deacon wrote: > Hi Olof, > > On Sun, Jan 29, 2017 at 04:24:51PM -0800, Olof Johansson wrote: >> On Thu, Jan 19, 2017 at 8:58 AM, Andy Gross wrote: >> > This patch adds a Qualcomm specific quirk to the arm_smccc_smc

Re: [Patch v4 2/2] firmware: qcom: scm: Fix interrupted SCM calls

On Mon, Jan 30, 2017 at 2:55 AM, Will Deacon wrote: > Hi Olof, > > On Sun, Jan 29, 2017 at 04:24:51PM -0800, Olof Johansson wrote: >> On Thu, Jan 19, 2017 at 8:58 AM, Andy Gross wrote: >> > This patch adds a Qualcomm specific quirk to the arm_smccc_smc call. >> > >> > On Qualcomm ARM64

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 5:31 PM, Eric Dumazet wrote: > On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: >> On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: >> > Oh well, I forgot to submit the official patch I think, Jan 9th. >> > >> >

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 5:31 PM, Eric Dumazet wrote: > On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: >> On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: >> > Oh well, I forgot to submit the official patch I think, Jan 9th. >> > >> >

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote: > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote: > > Running Steven's hotplug stress script in tip.today. Config is > > NOPREEMPT, tune for maximum build time (enterprise default-ish). > > > > [ 75.268049] x86: Booting SMP

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote: > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote: > > Running Steven's hotplug stress script in tip.today. Config is > > NOPREEMPT, tune for maximum build time (enterprise default-ish). > > > > [ 75.268049] x86: Booting SMP

Re: [PATCH] remoteproc: Move rproc_delete_debug_dir() to rproc_del()

On Mon 30 Jan 14:01 PST 2017, Bjorn Andersson wrote: > On Mon 23 Jan 17:48 PST 2017, Sarangdhar Joshi wrote: > > > The "remoteproc{0,1...}" sysfs entries are added in > > rproc_add() and deleted in rproc_type_release() instead of > > in rproc_del(). That leaves these lingering entries sticking >

Re: [PATCH] remoteproc: Move rproc_delete_debug_dir() to rproc_del()

On Mon 30 Jan 14:01 PST 2017, Bjorn Andersson wrote: > On Mon 23 Jan 17:48 PST 2017, Sarangdhar Joshi wrote: > > > The "remoteproc{0,1...}" sysfs entries are added in > > rproc_add() and deleted in rproc_type_release() instead of > > in rproc_del(). That leaves these lingering entries sticking >

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

On 1/26/2017 23:19, Philippe Reynes wrote: 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 ---

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

On 1/26/2017 23:19, Philippe Reynes wrote: 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 ---

Re: [RFC V2 00/12] Define coherent device memory node

On Tue, Jan 31, 2017 at 11:18:49AM +0530, Anshuman Khandual wrote: > Hello Dave/Jerome/Mel, > > Here is the overall layout of the functions I am trying to put together > through this patch series. > > (1) Define CDM from core VM and kernel perspective > > (2) Isolation/Special consideration for

Re: [RFC V2 00/12] Define coherent device memory node

On Tue, Jan 31, 2017 at 11:18:49AM +0530, Anshuman Khandual wrote: > Hello Dave/Jerome/Mel, > > Here is the overall layout of the functions I am trying to put together > through this patch series. > > (1) Define CDM from core VM and kernel perspective > > (2) Isolation/Special consideration for

Re: [PATCH v2 14/25] ARM: dts: sun8i: sina33: enable ACIN power supply subnode

On Fri, Jan 27, 2017 at 4:54 PM, Quentin Schulz wrote: > The Sinlinx SinA33 has an AXP223 PMIC and an ACIN connector, thus, we > enable the ACIN power supply in its Device Tree. > > Signed-off-by: Quentin Schulz Acked-by:

Re: [PATCH v2 14/25] ARM: dts: sun8i: sina33: enable ACIN power supply subnode

On Fri, Jan 27, 2017 at 4:54 PM, Quentin Schulz wrote: > The Sinlinx SinA33 has an AXP223 PMIC and an ACIN connector, thus, we > enable the ACIN power supply in its Device Tree. > > Signed-off-by: Quentin Schulz Acked-by: Chen-Yu Tsai

Re: [RFC V2 08/12] mm: Add new VMA flag VM_CDM

On Tue, Jan 31, 2017 at 09:52:20AM +0530, Anshuman Khandual wrote: > On 01/31/2017 12:22 AM, Jerome Glisse wrote: > > On Mon, Jan 30, 2017 at 09:05:49AM +0530, Anshuman Khandual wrote: > >> VMA which contains CDM memory pages should be marked with new VM_CDM flag. > >> These VMAs need to be

Re: [PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

On 1/31/2017 3:16 AM, Bjorn Andersson wrote: On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote: This patch add additional clock and regulator resource which are initialized based on compatible and has no impact on existing driver working. This resourse addition enable the existing

Re: [RFC V2 08/12] mm: Add new VMA flag VM_CDM

On Tue, Jan 31, 2017 at 09:52:20AM +0530, Anshuman Khandual wrote: > On 01/31/2017 12:22 AM, Jerome Glisse wrote: > > On Mon, Jan 30, 2017 at 09:05:49AM +0530, Anshuman Khandual wrote: > >> VMA which contains CDM memory pages should be marked with new VM_CDM flag. > >> These VMAs need to be

Re: [PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

On 1/31/2017 3:16 AM, Bjorn Andersson wrote: On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote: This patch add additional clock and regulator resource which are initialized based on compatible and has no impact on existing driver working. This resourse addition enable the existing

Re: [PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

On Mon 30 Jan 21:58 PST 2017, Dwivedi, Avaneesh Kumar (avani) wrote: > > > On 1/31/2017 3:16 AM, Bjorn Andersson wrote: > > On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote: > > > > > This patch add additional clock and regulator resource which are > > > initialized based on

Re: [PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

On Mon 30 Jan 21:58 PST 2017, Dwivedi, Avaneesh Kumar (avani) wrote: > > > On 1/31/2017 3:16 AM, Bjorn Andersson wrote: > > On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote: > > > > > This patch add additional clock and regulator resource which are > > > initialized based on

Re: [PATCH] remoteproc: Move rproc_delete_debug_dir() to rproc_del()

On Mon 23 Jan 17:48 PST 2017, Sarangdhar Joshi wrote: > The "remoteproc{0,1...}" sysfs entries are added in > rproc_add() and deleted in rproc_type_release() instead of > in rproc_del(). That leaves these lingering entries sticking > around after we return from rproc_del(). Move the >

Re: [PATCH] remoteproc: Move rproc_delete_debug_dir() to rproc_del()

On Mon 23 Jan 17:48 PST 2017, Sarangdhar Joshi wrote: > The "remoteproc{0,1...}" sysfs entries are added in > rproc_add() and deleted in rproc_type_release() instead of > in rproc_del(). That leaves these lingering entries sticking > around after we return from rproc_del(). Move the >

  1   2   3   4   5   6   7   8   9   10   >