[PATCH 7/8] f2fs crypto: migrate into vfs's crypto engine

This patch removes the most parts of internal crypto codes. And then, it modifies some f2fs-specific crypt codes to use the generic facility. Signed-off-by: Jaegeuk Kim --- fs/f2fs/Kconfig | 10 +- fs/f2fs/Makefile| 2 - fs/f2fs/crypto.c| 473

[PATCH 2/8] fs crypto: add crypto.c for encrypt/decrypt functions

This patch adds crypto.c supporting encrypting and decrypting functions. 1. IO preparation: - fscrypt_get_ctx / fscrypt_release_ctx 2. before IOs: - fscrypt_encrypt_page - fscrypt_decrypt_page - fscrypt_zeroout_range 3. after IOs: - fscrypt_decrypt_bio_pages -

[PATCH 7/8] f2fs crypto: migrate into vfs's crypto engine

This patch removes the most parts of internal crypto codes. And then, it modifies some f2fs-specific crypt codes to use the generic facility. Signed-off-by: Jaegeuk Kim --- fs/f2fs/Kconfig | 10 +- fs/f2fs/Makefile| 2 - fs/f2fs/crypto.c| 473

[PATCH 2/8] fs crypto: add crypto.c for encrypt/decrypt functions

This patch adds crypto.c supporting encrypting and decrypting functions. 1. IO preparation: - fscrypt_get_ctx / fscrypt_release_ctx 2. before IOs: - fscrypt_encrypt_page - fscrypt_decrypt_page - fscrypt_zeroout_range 3. after IOs: - fscrypt_decrypt_bio_pages -

[PATCH 2/9] ARM: dts: uniphier: rework UniPhier System Bus nodes

Tidy up the System Bus nodes in order to make the driver (drivers/bus/uniphier-system-bus.c) really available. Signed-off-by: Masahiro Yamada --- arch/arm/boot/dts/uniphier-common32.dtsi | 19 ++-

[PATCH 1/9] ARM: dts: uniphier: factor out ranges property of support card

This property is used in common by several boards. Move it to the common place (uniphier-support-card.dtsi). If necessary, each board can still override the property. Signed-off-by: Masahiro Yamada --- arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 8

[PATCH 2/9] ARM: dts: uniphier: rework UniPhier System Bus nodes

Tidy up the System Bus nodes in order to make the driver (drivers/bus/uniphier-system-bus.c) really available. Signed-off-by: Masahiro Yamada --- arch/arm/boot/dts/uniphier-common32.dtsi | 19 ++- arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 19

[PATCH 1/9] ARM: dts: uniphier: factor out ranges property of support card

This property is used in common by several boards. Move it to the common place (uniphier-support-card.dtsi). If necessary, each board can still override the property. Signed-off-by: Masahiro Yamada --- arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 8

[PATCH 1/8] fs crypto: add basic definitions for per-file encryption

This patch adds definitions for per-file encryption used by ext4 and f2fs. Signed-off-by: Jaegeuk Kim --- include/linux/fs.h | 8 ++ include/linux/fscrypto.h | 238 +++ include/uapi/linux/fs.h | 18 3 files changed,

[PATCH 1/8] fs crypto: add basic definitions for per-file encryption

This patch adds definitions for per-file encryption used by ext4 and f2fs. Signed-off-by: Jaegeuk Kim --- include/linux/fs.h | 8 ++ include/linux/fscrypto.h | 238 +++ include/uapi/linux/fs.h | 18 3 files changed, 264 insertions(+)

[PATCH 2/2] ARM: dts: vf-colibri: add supply regulators

Colibri modules need to be powered using the power pins 3V3 and AVDD. Add fixed regulators which represent this power rails. Potentially, those power rails could be switched on a carrier board. A carrier board device tree could add a own regulator with a GPIO, and reference that regulator in a

[PATCH 1/2] ARM: dts: vf-colibri: remove container node of regulators

Drop the fake simple-bus container 'regulators' and put the regulators directly under the root node. This also makes the artificial 'reg' properties superfluous. Signed-off-by: Stefan Agner --- arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 44 +-- 1

[PATCH 2/2] ARM: dts: vf-colibri: add supply regulators

Colibri modules need to be powered using the power pins 3V3 and AVDD. Add fixed regulators which represent this power rails. Potentially, those power rails could be switched on a carrier board. A carrier board device tree could add a own regulator with a GPIO, and reference that regulator in a

[PATCH 1/2] ARM: dts: vf-colibri: remove container node of regulators

Drop the fake simple-bus container 'regulators' and put the regulators directly under the root node. This also makes the artificial 'reg' properties superfluous. Signed-off-by: Stefan Agner --- arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 44 +-- 1 file changed, 18

Re: [PATCH v4 4/8] dt-bindings: Add a binding for Mediatek Video Encoder

Hi Daniel, On Mon, 2016-02-15 at 18:42 +0800, Daniel Kurtz wrote: > On Tue, Feb 9, 2016 at 7:29 PM, Daniel Kurtz wrote: > > Hi Tiffany, > > > > On Thu, Feb 4, 2016 at 7:34 PM, Tiffany Lin > > wrote: > >> Add a DT binding documentation of Video

Re: [PATCH v4 4/8] dt-bindings: Add a binding for Mediatek Video Encoder

Hi Daniel, On Mon, 2016-02-15 at 18:42 +0800, Daniel Kurtz wrote: > On Tue, Feb 9, 2016 at 7:29 PM, Daniel Kurtz wrote: > > Hi Tiffany, > > > > On Thu, Feb 4, 2016 at 7:34 PM, Tiffany Lin > > wrote: > >> Add a DT binding documentation of Video Encoder for the > >> MT8173 SoC from Mediatek. >

Re: [media 7/7] PCI bridge driver for PT3 & PXQ3PE

2016-02-15 21:57 GMT+09:00 kbuild test robot <l...@intel.com>: > Hi Буди, > > [auto build test ERROR on linuxtv-media/master] > [cannot apply to v4.5-rc4 next-20160215] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the syst

Re: [media 7/7] PCI bridge driver for PT3 & PXQ3PE

2016-02-15 21:57 GMT+09:00 kbuild test robot : > Hi Буди, > > [auto build test ERROR on linuxtv-media/master] > [cannot apply to v4.5-rc4 next-20160215] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: &

[PATCH] rtc: s5m: De-inline large functions to save space

Few functions were marked inline even though they were relatively large and sometimes used in multiple places. De-inline them to let the compiler decide whether optimization makes sense. This fixes inline_hunt report: drivers/rtc/rtc-s5m.c: Deinline s5m8767_rtc_set_alarm_reg, save 704 bytes

[PATCH] rtc: s5m: De-inline large functions to save space

Few functions were marked inline even though they were relatively large and sometimes used in multiple places. De-inline them to let the compiler decide whether optimization makes sense. This fixes inline_hunt report: drivers/rtc/rtc-s5m.c: Deinline s5m8767_rtc_set_alarm_reg, save 704 bytes

Re: [PATCH 1/2] ideapad: No hardware switch after 2016

On 02/16/2016 01:32 AM, Bjørn Mork wrote: > Ike Panhc writes: >> On 02/15/2016 08:08 PM, Bjørn Mork wrote: >>> Ike Panhc writes: >>> There are complains on few ideapads that wireless is always hard blocked but there is no physical radio

Re: [PATCH 1/2] ideapad: No hardware switch after 2016

On 02/16/2016 01:32 AM, Bjørn Mork wrote: > Ike Panhc writes: >> On 02/15/2016 08:08 PM, Bjørn Mork wrote: >>> Ike Panhc writes: >>> There are complains on few ideapads that wireless is always hard blocked but there is no physical radio switch. For now, we need each user to report

Re: checkpatch falsepositives in Lustre code

On Feb 15, 2016, at 7:56 PM, Joe Perches wrote: > [etc...] > > Yeah, that's a defect of some type. Also while I have your attention, here's another one: struct cfs_percpt_lock * cfs_percpt_lock_alloc(struct cfs_cpt_table *cptab) { struct cfs_percpt_lock *pcl; spinlock_t

Re: checkpatch falsepositives in Lustre code

On Feb 15, 2016, at 7:56 PM, Joe Perches wrote: > [etc...] > > Yeah, that's a defect of some type. Also while I have your attention, here's another one: struct cfs_percpt_lock * cfs_percpt_lock_alloc(struct cfs_cpt_table *cptab) { struct cfs_percpt_lock *pcl; spinlock_t

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

On Tue, Feb 16, 2016 at 06:30:59AM +0530, Viresh Kumar wrote: > - And so I left the regulator pointer to NULL in OPP core. > - But then I realized that its not safe to call many regulator core > APIs with NULL regulator, as those caused the crashes reported by > multiple people now. > - clk

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

On Tue, Feb 16, 2016 at 06:30:59AM +0530, Viresh Kumar wrote: > - And so I left the regulator pointer to NULL in OPP core. > - But then I realized that its not safe to call many regulator core > APIs with NULL regulator, as those caused the crashes reported by > multiple people now. > - clk

Re: [ANNOUNCE] 4.4.1-rt6

On Mon, 2016-02-15 at 18:25 +0100, Mike Galbraith wrote: > On Sat, 2016-02-13 at 00:47 +0100, Sebastian Andrzej Siewior wrote: > > > Known issues: > > - bcache stays disabled > > > > - CPU hotplug got a little better but can deadlock. > > My x86_64 desktop box survived 100 iterations of

Re: [ANNOUNCE] 4.4.1-rt6

On Mon, 2016-02-15 at 18:25 +0100, Mike Galbraith wrote: > On Sat, 2016-02-13 at 00:47 +0100, Sebastian Andrzej Siewior wrote: > > > Known issues: > > - bcache stays disabled > > > > - CPU hotplug got a little better but can deadlock. > > My x86_64 desktop box survived 100 iterations of

Re: [PATCH 0/4][RESEND] thermal: rcar: use thermal-zone on DT

On Wed, Feb 10, 2016 at 12:34:13AM +, Kuninori Morimoto wrote: > > Hi Eduardo, Simon > > > > > Hi Eduardo > > > > > > > > I'm sorry I didn't mention you. > > > > Can you please check these patches ? > > > > > > Yes Morimoto, they are now on my todo list. > > > > > > Applied first one. >

Re: [PATCH 0/4][RESEND] thermal: rcar: use thermal-zone on DT

On Wed, Feb 10, 2016 at 12:34:13AM +, Kuninori Morimoto wrote: > > Hi Eduardo, Simon > > > > > Hi Eduardo > > > > > > > > I'm sorry I didn't mention you. > > > > Can you please check these patches ? > > > > > > Yes Morimoto, they are now on my todo list. > > > > > > Applied first one. >

Re: [PATCH 2/2] hwmon: (scpi) add energy meter support

On 02/09/2016 06:32 AM, Sudeep Holla wrote: SCPI specification v1.1 adds support for energy sensors. This patch adds support for the same. Cc: Punit Agrawal Signed-off-by: Sudeep Holla Acked-by: Guenter Roeck ---

Re: [PATCH 2/2] hwmon: (scpi) add energy meter support

On 02/09/2016 06:32 AM, Sudeep Holla wrote: SCPI specification v1.1 adds support for energy sensors. This patch adds support for the same. Cc: Punit Agrawal Signed-off-by: Sudeep Holla Acked-by: Guenter Roeck --- drivers/hwmon/scpi-hwmon.c| 8

Re: [PATCH 1/2] firmware: arm_scpi: add support for 64-bit sensor values

On 02/09/2016 06:32 AM, Sudeep Holla wrote: SCPI specification version 1.1 extended the sensor from 32-bit to 64-bit values in order to accommodate new sensor class with 64-bit requirements Since the SCPI driver sets the higher 32-bit for older protocol version to zeros, there's no need to

Re: [PATCH 1/2] firmware: arm_scpi: add support for 64-bit sensor values

On 02/09/2016 06:32 AM, Sudeep Holla wrote: SCPI specification version 1.1 extended the sensor from 32-bit to 64-bit values in order to accommodate new sensor class with 64-bit requirements Since the SCPI driver sets the higher 32-bit for older protocol version to zeros, there's no need to

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

ren wrote: https://kernelci.org/boot/all/job/next/kernel/next-20160215/ The SMP ones seem to fail with some regulator issues? There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add dev_pm_opp_set_rate()"). The kernelci boot log for next-20160212:omap3-overo-tobi and ot

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On 02/15/2016 01:36 PM, Tony Lindgren wrote: * Rafael J. Wysocki [160215 12:39]: On Mon, Feb 15, 2016 at 8:58 PM, Tony Lindgren wrote: * Guenter Roeck [160215 11:41]: On 02/15/2016 11:01 AM, Tony Lindgren wrote: https://kernelci.org/boot/all/job/next/kernel/next-20160215/ The SMP ones

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On 16-02-16, 02:27, Rafael J. Wysocki wrote: > Yes, that's what we should be doing, but it seemed to me that we didn't. > > Or maybe the trace just contained the last one, because that's when the > crash happened. Ofcourse, it wouldn't mention the function calls that have already finished :) --

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On 16-02-16, 02:27, Rafael J. Wysocki wrote: > Yes, that's what we should be doing, but it seemed to me that we didn't. > > Or maybe the trace just contained the last one, because that's when the > crash happened. Ofcourse, it wouldn't mention the function calls that have already finished :) --

Re: [PATCH] usb: dwc2: host: fix the data toggle error in full speed descriptor dma

On 1/25/2016 10:20 PM, Jianqiang Tang wrote: > From: "Tang, Jianqiang" > > There will be data toggle error happen for full speed buld-out transfer. > The data toggle bit is saved in qh for non-control transfers, it is wrong > to check the qtd for that case. > > Also

Re: [PATCH] usb: dwc2: host: fix the data toggle error in full speed descriptor dma

On 1/25/2016 10:20 PM, Jianqiang Tang wrote: > From: "Tang, Jianqiang" > > There will be data toggle error happen for full speed buld-out transfer. > The data toggle bit is saved in qh for non-control transfers, it is wrong > to check the qtd for that case. > > Also fix one static analysis

Re: [PATCH 3/3] spi: rockchip: add debug interface support

Hi Mark, On 2016/2/16 1:26, Mark Brown wrote: On Mon, Feb 15, 2016 at 04:28:22PM +0800, Shawn Lin wrote: +#ifdef CONFIG_DEBUG_FS +#include +#endif Just include the header. Only add ifdefs if they do something. +static int rockchip_spi_debugfs_init(struct rockchip_spi *rs) +{ +

Re: [PATCH 3/3] spi: rockchip: add debug interface support

Hi Mark, On 2016/2/16 1:26, Mark Brown wrote: On Mon, Feb 15, 2016 at 04:28:22PM +0800, Shawn Lin wrote: +#ifdef CONFIG_DEBUG_FS +#include +#endif Just include the header. Only add ifdefs if they do something. +static int rockchip_spi_debugfs_init(struct rockchip_spi *rs) +{ +

Re: [PATCH v2 1/4] locking/mutex: Add waiter parameter to mutex_optimistic_spin()

On 02/12/2016 03:40 PM, Peter Zijlstra wrote: On Fri, Feb 12, 2016 at 12:32:12PM -0500, Waiman Long wrote: @@ -358,8 +373,8 @@ static bool mutex_optimistic_spin(struct mutex *lock, } mutex_set_owner(lock); -

Re: [PATCH v2 1/4] locking/mutex: Add waiter parameter to mutex_optimistic_spin()

On 02/12/2016 03:40 PM, Peter Zijlstra wrote: On Fri, Feb 12, 2016 at 12:32:12PM -0500, Waiman Long wrote: @@ -358,8 +373,8 @@ static bool mutex_optimistic_spin(struct mutex *lock, } mutex_set_owner(lock); -

Re: [PATCH] drivers/hwtracing: make coresight-* explicitly non-modular

On 14 February 2016 at 10:19, Paul Gortmaker wrote: > None of the Kconfig currently controlling compilation of any of > the files here are tristate, meaning that none of it currently > is being built as a module by anyone. > > We need not be concerned about .remove

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Tuesday, February 16, 2016 06:43:35 AM Viresh Kumar wrote: > On 15-02-16, 19:41, Rafael J. Wysocki wrote: > > On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote: > > > [1.34] [] (__cpufreq_driver_target) from [] > > > (dbs_check_cpu+0x1ac/0x1e8) > > > [

Re: [PATCH] drivers/hwtracing: make coresight-* explicitly non-modular

On 14 February 2016 at 10:19, Paul Gortmaker wrote: > None of the Kconfig currently controlling compilation of any of > the files here are tristate, meaning that none of it currently > is being built as a module by anyone. > > We need not be concerned about .remove functions and blocking the >

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Tuesday, February 16, 2016 06:43:35 AM Viresh Kumar wrote: > On 15-02-16, 19:41, Rafael J. Wysocki wrote: > > On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote: > > > [1.34] [] (__cpufreq_driver_target) from [] > > > (dbs_check_cpu+0x1ac/0x1e8) > > > [1.34] []

Re: [PATCH v6 2/2] ACPI: amba bus probing support

On Wednesday, January 20, 2016 08:29:27 PM Aleksey Makarov wrote: > From: Graeme Gregory > > On ARM64 some devices use the AMBA device and not the platform bus for > probing so add support for this. Uses a dummy clock for apb_pclk as ACPI > does not have a suitable

Re: [PATCH v8 1/5] mfd: hi655x: Add document for mfd hi665x PMIC

Lee, Thanks for your review. On 2016/2/15 16:32, Lee Jones wrote: > On Sun, 14 Feb 2016, Chen Feng wrote: > >> DT bindings for hisilicon hi655x MFD PMIC chip. >> >> Signed-off-by: Chen Feng >> Signed-off-by: Fei Wang >> Signed-off-by: Xinwei Kong

Re: [PATCH v6 2/2] ACPI: amba bus probing support

On Wednesday, January 20, 2016 08:29:27 PM Aleksey Makarov wrote: > From: Graeme Gregory > > On ARM64 some devices use the AMBA device and not the platform bus for > probing so add support for this. Uses a dummy clock for apb_pclk as ACPI > does not have a suitable clock representation and to

Re: [PATCH v8 1/5] mfd: hi655x: Add document for mfd hi665x PMIC

Lee, Thanks for your review. On 2016/2/15 16:32, Lee Jones wrote: > On Sun, 14 Feb 2016, Chen Feng wrote: > >> DT bindings for hisilicon hi655x MFD PMIC chip. >> >> Signed-off-by: Chen Feng >> Signed-off-by: Fei Wang >> Signed-off-by: Xinwei Kong >> Reviewed-by: Haojian Zhuang >> --- >>

Re: [PATCH v6 1/2] ACPI: introduce a function to find the first physical device

On Wednesday, January 20, 2016 05:12:18 PM Andy Shevchenko wrote: > On Wed, Jan 20, 2016 at 4:29 PM, Aleksey Makarov > wrote: > > Factor out the code that finds the first physical device > > of a given ACPI device. It is used in several places. > > > > Reviewed-by:

[PATCH] Add fix case for open braces

Some quite excellent fixes from Joe Perches that belong back in the original. Submitting to Joe for inclusion. Joe was the original author of these fixes that save a lot of time rewriting code. Thanks Joe. Signed-off-by: Jeffrey Merkey --- scripts/checkpatch.pl | 23

Re: [PATCH v6 1/2] ACPI: introduce a function to find the first physical device

On Wednesday, January 20, 2016 05:12:18 PM Andy Shevchenko wrote: > On Wed, Jan 20, 2016 at 4:29 PM, Aleksey Makarov > wrote: > > Factor out the code that finds the first physical device > > of a given ACPI device. It is used in several places. > > > > Reviewed-by: Andy Shevchenko > >

[PATCH] Add fix case for open braces

Some quite excellent fixes from Joe Perches that belong back in the original. Submitting to Joe for inclusion. Joe was the original author of these fixes that save a lot of time rewriting code. Thanks Joe. Signed-off-by: Jeffrey Merkey --- scripts/checkpatch.pl | 23 ++-

Re: [PATCH v6 1/2] ACPI: introduce a function to find the first physical device

On Wednesday, January 20, 2016 08:29:26 PM Aleksey Makarov wrote: > Factor out the code that finds the first physical device > of a given ACPI device. It is used in several places. > > Reviewed-by: Andy Shevchenko I guess the above doesn't apply any more, does it? >

Re: [PATCH v6 1/2] ACPI: introduce a function to find the first physical device

On Wednesday, January 20, 2016 08:29:26 PM Aleksey Makarov wrote: > Factor out the code that finds the first physical device > of a given ACPI device. It is used in several places. > > Reviewed-by: Andy Shevchenko I guess the above doesn't apply any more, does it? > Signed-off-by: Aleksey

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

On Tue, 16 Feb 2016 09:47:20 +0900 Joonsoo Kim wrote: > > They return true when CONFIG_TRACEPOINTS is configured in and the > > tracepoint is enabled, and false otherwise. > > This implementation is what you proposed before. Please refer below > link and source. > >

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

On Tue, 16 Feb 2016 09:47:20 +0900 Joonsoo Kim wrote: > > They return true when CONFIG_TRACEPOINTS is configured in and the > > tracepoint is enabled, and false otherwise. > > This implementation is what you proposed before. Please refer below > link and source. > >

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On 15-02-16, 19:41, Rafael J. Wysocki wrote: > On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote: > > [1.34] [] (__cpufreq_driver_target) from [] > > (dbs_check_cpu+0x1ac/0x1e8) > > [1.34] [] (dbs_check_cpu) from [] > > (cpufreq_governor_dbs+0x1fc/0x608) >

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On 15-02-16, 19:41, Rafael J. Wysocki wrote: > On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote: > > [1.34] [] (__cpufreq_driver_target) from [] > > (dbs_check_cpu+0x1ac/0x1e8) > > [1.34] [] (dbs_check_cpu) from [] > > (cpufreq_governor_dbs+0x1fc/0x608) > > [1.34] []

Re: [PATCH V7 0/5] rtc: max77686: make max77686 rtc driver as IP driver

On 09/02/2016 at 22:56:29 +0530, Laxman Dewangan wrote : > Based on discussion on patch series of MAX77620 when adding separate > driver for max77620 RTC, it is discussed to reuse the max77686 driver > for all CHips MAX77802, MAX77686 and MAX77620. For this, the rtc-max77686 > need to make as IP

Re: [PATCH V7 0/5] rtc: max77686: make max77686 rtc driver as IP driver

On 09/02/2016 at 22:56:29 +0530, Laxman Dewangan wrote : > Based on discussion on patch series of MAX77620 when adding separate > driver for max77620 RTC, it is discussed to reuse the max77686 driver > for all CHips MAX77802, MAX77686 and MAX77620. For this, the rtc-max77686 > need to make as IP

Re: [RFC 6/6] RCU: Track rcu_dereference() in RCU read-side critical section

On Thu, Feb 04, 2016 at 12:45:12AM +0800, Boqun Feng wrote: > The variables protected by an RCU read-side critical section are > sometimes hard to figure out, especially when the critical section is > long or has some function calls in it. However, figuring out which > variable a RCU read-side

Re: [RFC 6/6] RCU: Track rcu_dereference() in RCU read-side critical section

On Thu, Feb 04, 2016 at 12:45:12AM +0800, Boqun Feng wrote: > The variables protected by an RCU read-side critical section are > sometimes hard to figure out, especially when the critical section is > long or has some function calls in it. However, figuring out which > variable a RCU read-side

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

Cc'ing Mark as well. On 15-02-16, 21:38, Arnd Bergmann wrote: > There is usually something else wrong if you have to check for both. > Why exactly do you need to check for both IS_ERR and NULL? And here is the reasoning behind it: - It is normally said that 'NULL' is a valid clk. The same is

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

Cc'ing Mark as well. On 15-02-16, 21:38, Arnd Bergmann wrote: > There is usually something else wrong if you have to check for both. > Why exactly do you need to check for both IS_ERR and NULL? And here is the reasoning behind it: - It is normally said that 'NULL' is a valid clk. The same is

Re: checkpatch falsepositives in Lustre code

On Mon, 2016-02-15 at 18:49 -0500, Oleg Drokin wrote: > Hello! > > >    As I am going over Lustre to clean up the code style, I noticed this bunch > below. > >    Those all are function definitions, though I guess it might have been > foiled by >    return type on the previous line? >    Now

Re: checkpatch falsepositives in Lustre code

On Mon, 2016-02-15 at 18:49 -0500, Oleg Drokin wrote: > Hello! > > >    As I am going over Lustre to clean up the code style, I noticed this bunch > below. > >    Those all are function definitions, though I guess it might have been > foiled by >    return type on the previous line? >    Now

Re: [PATCH v3] powercap/rapl: reduce ipi calls

On Friday, January 15, 2016 11:04:13 AM Jacob Pan wrote: > Reduce remote CPU calls for MSR access by combining read > modify write into one function. Also optimize search for active CPU on > package such that remote CPU is not used if the current CPU is already > on the target package. > >

Re: [PATCH v3] powercap/rapl: reduce ipi calls

On Friday, January 15, 2016 11:04:13 AM Jacob Pan wrote: > Reduce remote CPU calls for MSR access by combining read > modify write into one function. Also optimize search for active CPU on > package such that remote CPU is not used if the current CPU is already > on the target package. > >

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

On Tuesday, February 16, 2016 06:17:16 AM Viresh Kumar wrote: > On 15-02-16, 22:13, Rafael J. Wysocki wrote: > > That should be something like -ENXIO IMO. > > Thanks for modifying and applying the patch :) Well, you're welcome. I wanted it to be fixed in the tomorrow's linux-next so people can

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

On Tuesday, February 16, 2016 06:17:16 AM Viresh Kumar wrote: > On 15-02-16, 22:13, Rafael J. Wysocki wrote: > > That should be something like -ENXIO IMO. > > Thanks for modifying and applying the patch :) Well, you're welcome. I wanted it to be fixed in the tomorrow's linux-next so people can

Re: [PATCH v2 2/2] tracing/rcu: don't trace rcu_callback on offline CPUs

On Sun, Feb 14, 2016 at 10:05:22PM -0800, Paul E. McKenney wrote: > On Sun, Feb 14, 2016 at 09:50:18AM +0300, Denis Kirjanov wrote: > > Tracepoints use RCU for protection and they must not be called on > > offline CPUS. So make this tracepoint conditional. > > Good catch! Queued for review and

Re: [PATCH v2 2/2] tracing/rcu: don't trace rcu_callback on offline CPUs

On Sun, Feb 14, 2016 at 10:05:22PM -0800, Paul E. McKenney wrote: > On Sun, Feb 14, 2016 at 09:50:18AM +0300, Denis Kirjanov wrote: > > Tracepoints use RCU for protection and they must not be called on > > offline CPUS. So make this tracepoint conditional. > > Good catch! Queued for review and

Re: livepatch/module: remove livepatch module notifier

+++ Jiri Kosina [16/02/16 00:42 +0100]: On Mon, 15 Feb 2016, Josh Poimboeuf wrote: So I think the commit causing the regression is 5156dca34a3e, which occurred in the 4.5 cycle, *not* in 4.4. Agreed, by "4.4 regresion" I mean "regression compared to 4.4"; i.e. regression that will become

Re: livepatch/module: remove livepatch module notifier

+++ Jiri Kosina [16/02/16 00:42 +0100]: On Mon, 15 Feb 2016, Josh Poimboeuf wrote: So I think the commit causing the regression is 5156dca34a3e, which occurred in the 4.5 cycle, *not* in 4.4. Agreed, by "4.4 regresion" I mean "regression compared to 4.4"; i.e. regression that will become

Re: [PATCH -next] PM / OPP: Fix crash seen if CPU clock has no voltage regulator

On 15-02-16, 11:34, Guenter Roeck wrote: > omap3 overo boots crash with > > Unable to handle kernel NULL pointer dereference at virtual address 0030 > pgd = c0204000 > [0030] *pgd= > Internal error: Oops: 17 [#1] SMP ARM > ... > [] (regulator_set_voltage) from []

Re: [PATCH -next] PM / OPP: Fix crash seen if CPU clock has no voltage regulator

On 15-02-16, 11:34, Guenter Roeck wrote: > omap3 overo boots crash with > > Unable to handle kernel NULL pointer dereference at virtual address 0030 > pgd = c0204000 > [0030] *pgd= > Internal error: Oops: 17 [#1] SMP ARM > ... > [] (regulator_set_voltage) from []

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

On 15-02-16, 22:13, Rafael J. Wysocki wrote: > That should be something like -ENXIO IMO. Thanks for modifying and applying the patch :) -- viresh

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

On 15-02-16, 22:13, Rafael J. Wysocki wrote: > That should be something like -ENXIO IMO. Thanks for modifying and applying the patch :) -- viresh

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

On Mon, Feb 15, 2016 at 11:07:41AM -0500, Steven Rostedt wrote: > On Mon, 15 Feb 2016 12:04:50 +0900 > js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > CMA allocation should be guaranteed to succeed by definition, but, > > unfortunately, it would be failed

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

On Mon, Feb 15, 2016 at 11:07:41AM -0500, Steven Rostedt wrote: > On Mon, 15 Feb 2016 12:04:50 +0900 > js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > CMA allocation should be guaranteed to succeed by definition, but, > > unfortunately, it would be failed sometimes. It is hard to track

Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count

On Mon, Feb 15, 2016 at 03:52:31PM -0800, Daniel Walker wrote: > >>We need it to determine accurately what the free memory in the > >>system is. If you know where we can get this information already > >>please tell, we aren't aware of it. For instance /proc/meminfo isn't > >>accurate enough. > >

Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count

On Mon, Feb 15, 2016 at 03:52:31PM -0800, Daniel Walker wrote: > >>We need it to determine accurately what the free memory in the > >>system is. If you know where we can get this information already > >>please tell, we aren't aware of it. For instance /proc/meminfo isn't > >>accurate enough. > >

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

Hi Ping, it seems inno hdmi driver is ready, So I'd like to merge it into drm/rockchip if there is no doubt these days. Thanks. Mark On 2016年01月29日 14:42, Yakir Yang wrote: Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

Hi Ping, it seems inno hdmi driver is ready, So I'd like to merge it into drm/rockchip if there is no doubt these days. Thanks. Mark On 2016年01月29日 14:42, Yakir Yang wrote: Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant

Re: [PATCH] acpi, pci, irq: account for early penalty assignment

On Mon, Feb 15, 2016 at 5:41 PM, Sinan Kaya wrote: > A crash has been observed when assigning penalty on x86 systems. > > It looks like this problem happens on x86 platforms with IOAPIC and an SCI > interrupt override in the ACPI table with interrupt number greater than >

Re: [PATCH] acpi, pci, irq: account for early penalty assignment

On Mon, Feb 15, 2016 at 5:41 PM, Sinan Kaya wrote: > A crash has been observed when assigning penalty on x86 systems. > > It looks like this problem happens on x86 platforms with IOAPIC and an SCI > interrupt override in the ACPI table with interrupt number greater than > 16. (22 in this example)

4.4.1 skb_warn_bad_offload+0xc5/0x110

Please keep me in CC. I've been seeing the following on some of my VMs ran under qemu. The VMs do not have internet connectivity. This happened when some files were accessed via NFS to another VM (NOTE: Both VMs throw these warnings. Both VMs are running the exact same kernel). The host is

4.4.1 skb_warn_bad_offload+0xc5/0x110

Please keep me in CC. I've been seeing the following on some of my VMs ran under qemu. The VMs do not have internet connectivity. This happened when some files were accessed via NFS to another VM (NOTE: Both VMs throw these warnings. Both VMs are running the exact same kernel). The host is

Re: [PATCH -next] PM / OPP: Fix crash seen if CPU clock has no voltage regulator

Hi Jon, [auto build test WARNING on next-20160215] url: https://github.com/0day-ci/linux/commits/Jon-Hunter/PM-OPP-Fix-NULL-pointer-dereference-crash-when-setting-the-OPP/20160215-220238 config: x86_64-randconfig-s0-02160737 (attached as .config) reproduce: # save the attached

Re: [PATCH -next] PM / OPP: Fix crash seen if CPU clock has no voltage regulator

Hi Jon, [auto build test WARNING on next-20160215] url: https://github.com/0day-ci/linux/commits/Jon-Hunter/PM-OPP-Fix-NULL-pointer-dereference-crash-when-setting-the-OPP/20160215-220238 config: x86_64-randconfig-s0-02160737 (attached as .config) reproduce: # save the attached

[PATCH net-next] net: macb: make magic-packet property generic

Signed-off-by: Sergio Prado --- As requested by Rob Herring on patch https://patchwork.ozlabs.org/patch/580862/ --- Documentation/devicetree/bindings/net/macb.txt | 2 +- drivers/net/ethernet/cadence/macb.c| 2 +- 2 files changed, 2 insertions(+), 2

[PATCH net-next] net: macb: make magic-packet property generic

Signed-off-by: Sergio Prado --- As requested by Rob Herring on patch https://patchwork.ozlabs.org/patch/580862/ --- Documentation/devicetree/bindings/net/macb.txt | 2 +- drivers/net/ethernet/cadence/macb.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v2 1/4] locking/mutex: Add waiter parameter to mutex_optimistic_spin()

On 02/12/2016 05:02 PM, Davidlohr Bueso wrote: On Fri, 12 Feb 2016, Waiman Long wrote: This patch adds a new waiter parameter to the mutex_optimistic_spin() function to prepare it to be used by a waiter-spinner that doesn't need to go into the OSQ as there can only be one waiter-spinner which

Re: [PATCH v2 1/4] locking/mutex: Add waiter parameter to mutex_optimistic_spin()

On 02/12/2016 05:02 PM, Davidlohr Bueso wrote: On Fri, 12 Feb 2016, Waiman Long wrote: This patch adds a new waiter parameter to the mutex_optimistic_spin() function to prepare it to be used by a waiter-spinner that doesn't need to go into the OSQ as there can only be one waiter-spinner which

Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count

On 02/15/2016 03:05 PM, Dave Chinner wrote: On Mon, Feb 15, 2016 at 10:19:54AM -0800, Daniel Walker wrote: On 02/14/2016 01:18 PM, Dave Chinner wrote: On Fri, Feb 12, 2016 at 12:14:39PM -0800, Daniel Walker wrote: From: Khalid Mughal Currently there is no way to figure

Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count

On 02/15/2016 03:05 PM, Dave Chinner wrote: On Mon, Feb 15, 2016 at 10:19:54AM -0800, Daniel Walker wrote: On 02/14/2016 01:18 PM, Dave Chinner wrote: On Fri, Feb 12, 2016 at 12:14:39PM -0800, Daniel Walker wrote: From: Khalid Mughal Currently there is no way to figure out the droppable

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