Re: [PATCH v7 7/8] perf tools: Check write_backward during evlist config

Em Wed, Jun 15, 2016 at 02:23:34AM +, Wang Nan escreveu: > Before this patch, when using overwritable ring buffer on an old > kernel, error message is misleading: > > # ~/perf record -m 1 -e raw_syscalls:*/overwrite/ -a > Error: > The raw_syscalls:sys_enter event is not supported. > >

[PATCH V2 01/63] of: Add a new macro to declare_of for one parameter function returning a value

The macro OF_DECLARE_1 expect a void (*func)(struct device_node *) while the OF_DECLARE_2 expect a int (*func)(struct device_node *, struct device_node *). The second one allows to pass an init function returning a value, which make possible to call the functions in the table and check the return

Re: [PATCH v7 7/8] perf tools: Check write_backward during evlist config

Em Wed, Jun 15, 2016 at 02:23:34AM +, Wang Nan escreveu: > Before this patch, when using overwritable ring buffer on an old > kernel, error message is misleading: > > # ~/perf record -m 1 -e raw_syscalls:*/overwrite/ -a > Error: > The raw_syscalls:sys_enter event is not supported. > >

[PATCH V2 01/63] of: Add a new macro to declare_of for one parameter function returning a value

The macro OF_DECLARE_1 expect a void (*func)(struct device_node *) while the OF_DECLARE_2 expect a int (*func)(struct device_node *, struct device_node *). The second one allows to pass an init function returning a value, which make possible to call the functions in the table and check the return

[PATCH V2 02/63] clocksource/drivers/clksrc-probe: Introduce init functions with return code

Currently, the clksrc-probe is not able to handle any error from the init functions. There are different issues with the current code: - the code is duplicated in the init functions by writing error - every driver tends to panic in its own init function - counting the number of clocksources is

[PATCH V2 02/63] clocksource/drivers/clksrc-probe: Introduce init functions with return code

Currently, the clksrc-probe is not able to handle any error from the init functions. There are different issues with the current code: - the code is duplicated in the init functions by writing error - every driver tends to panic in its own init function - counting the number of clocksources is

[PATCH V2 04/63] clocksource/drivers/mkt_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 04/63] clocksource/drivers/mkt_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 08/63] clocksource/drivers/st_lpc: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 06/63] clocksource/drivers/asm9260: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 08/63] clocksource/drivers/st_lpc: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 06/63] clocksource/drivers/asm9260: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 05/63] clocksource/drivers/exynos_mct: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 05/63] clocksource/drivers/exynos_mct: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 07/63] clocksource/drivers/cadence_ttc: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 07/63] clocksource/drivers/cadence_ttc: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 15/63] clocksource/drivers/clksrc-dbx500: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 09/63] clocksource/drivers/dw_apb_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 15/63] clocksource/drivers/clksrc-dbx500: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 09/63] clocksource/drivers/dw_apb_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 10/63] clocksource/drivers/clps711x: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 10/63] clocksource/drivers/clps711x: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 13/63] clocksource/drivers/bcm2835_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 12/63] clocksource/drivers/armv7m_systick: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

Re: [BUG] act_ife: sleeping functions called in atomic context

On Thu, Jun 16, 2016 at 1:50 PM, Alexey Khoroshilov wrote: > tcf_ife_init() contains a big chunk of code executed with > ife->tcf_lock spinlock held. But that code contains several calls > to sleeping functions: > populate_metalist() and use_all_metadata() > ->

Re: [PATCH V2 07/63] clocksource/drivers/cadence_ttc: Convert init function to return error

On Thu, 2016-06-16 at 23:26:26 +0200, Daniel Lezcano wrote: > The init functions do not return any error. They behave as the following: > > - panic, thus leading to a kernel crash while another timer may work and >make the system boot up correctly > > or > > - print an error and let the

[PATCH V2 13/63] clocksource/drivers/bcm2835_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

[PATCH V2 12/63] clocksource/drivers/armv7m_systick: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the

Re: [BUG] act_ife: sleeping functions called in atomic context

On Thu, Jun 16, 2016 at 1:50 PM, Alexey Khoroshilov wrote: > tcf_ife_init() contains a big chunk of code executed with > ife->tcf_lock spinlock held. But that code contains several calls > to sleeping functions: > populate_metalist() and use_all_metadata() > -> add_metainfo() > ->

Re: [PATCH V2 07/63] clocksource/drivers/cadence_ttc: Convert init function to return error

On Thu, 2016-06-16 at 23:26:26 +0200, Daniel Lezcano wrote: > The init functions do not return any error. They behave as the following: > > - panic, thus leading to a kernel crash while another timer may work and >make the system boot up correctly > > or > > - print an error and let the

[PATCH V2 21/63] clocksource/drivers/h8300_tpu: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 21/63] clocksource/drivers/h8300_tpu: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 20/63] clocksource/drivers/h8300_tpu: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 17/63] clocksource/drivers/arm_arch_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 20/63] clocksource/drivers/h8300_tpu: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 17/63] clocksource/drivers/arm_arch_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH 6/6] [media] gsc-m2m: improve v4l2_capability driver and card fields

According to the V4L2 documentation the driver and card fields should be used to identify the driver and the device but the gsc-m2m driver fills those field using the platform device name, which in turn is the name of the device DT node. So not only the filled information isn't correct but also

[PATCH 0/6] [media] Fixes and improvements for VIDIOC_QUERYCAP in Samsung media drivers

Hello, This series contains some fixes and improvements for the VIDIOC_QUERYCAP ioctl handler in different media platform drivers for IP blocks found in Exynos SoCs. Some of the issues were reported by the v4l2-compliance tool while others are things I noticed while looking at the Driver name,

[PATCH 5/6] [media] gsc-m2m: add device name sufix to bus_info capatiliby field

The driver doesn't set the device in the struct v4l2_capability bus_info field so v4l2-compliance reports the following error for VIDIOC_QUERYCAP: Required ioctls: fail: v4l2-compliance.cpp(537): missing bus_info prefix ('platform') test VIDIOC_QUERYCAP: FAIL This patch

[PATCH 4/6] [media] s5p-jpeg: only fill driver's name in capabilities driver field

The driver fills in both the struct v4l2_capability driver and card fields the same values, that is the driver's name plus the information if the dev is a decoder or an encoder. But the driver field has a fixed length of 16 bytes so the filled data is truncated: Driver Info (not using libv4l2):

[PATCH 3/6] [media] s5p-jpeg: set capablity bus_info as required by VIDIOC_QUERYCAP

The driver doesn't set the struct v4l2_capability cap_info field so the v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) fail: v4l2-compliance.cpp(304): string empty fail:

[PATCH 1/6] [media] s5p-mfc: set capablity bus_info as required by VIDIOC_QUERYCAP

The driver doesn't set the struct v4l2_capability bus_info field so the v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) fail: v4l2-compliance.cpp(304): string empty fail:

[PATCH 6/6] [media] gsc-m2m: improve v4l2_capability driver and card fields

According to the V4L2 documentation the driver and card fields should be used to identify the driver and the device but the gsc-m2m driver fills those field using the platform device name, which in turn is the name of the device DT node. So not only the filled information isn't correct but also

[PATCH 0/6] [media] Fixes and improvements for VIDIOC_QUERYCAP in Samsung media drivers

Hello, This series contains some fixes and improvements for the VIDIOC_QUERYCAP ioctl handler in different media platform drivers for IP blocks found in Exynos SoCs. Some of the issues were reported by the v4l2-compliance tool while others are things I noticed while looking at the Driver name,

[PATCH 5/6] [media] gsc-m2m: add device name sufix to bus_info capatiliby field

The driver doesn't set the device in the struct v4l2_capability bus_info field so v4l2-compliance reports the following error for VIDIOC_QUERYCAP: Required ioctls: fail: v4l2-compliance.cpp(537): missing bus_info prefix ('platform') test VIDIOC_QUERYCAP: FAIL This patch

[PATCH 4/6] [media] s5p-jpeg: only fill driver's name in capabilities driver field

The driver fills in both the struct v4l2_capability driver and card fields the same values, that is the driver's name plus the information if the dev is a decoder or an encoder. But the driver field has a fixed length of 16 bytes so the filled data is truncated: Driver Info (not using libv4l2):

[PATCH 3/6] [media] s5p-jpeg: set capablity bus_info as required by VIDIOC_QUERYCAP

The driver doesn't set the struct v4l2_capability cap_info field so the v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) fail: v4l2-compliance.cpp(304): string empty fail:

[PATCH 1/6] [media] s5p-mfc: set capablity bus_info as required by VIDIOC_QUERYCAP

The driver doesn't set the struct v4l2_capability bus_info field so the v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) fail: v4l2-compliance.cpp(304): string empty fail:

[PATCH 2/6] [media] s5p-mfc: improve v4l2_capability driver and card fields

According to the V4L2 documentation the driver and card fields should be used to identify the driver and the device but the s5p-mfc driver fills those field using the platform device name, which in turn is the name of the device DT node. So not only the filled information isn't correct but also

[PATCH 2/6] [media] s5p-mfc: improve v4l2_capability driver and card fields

According to the V4L2 documentation the driver and card fields should be used to identify the driver and the device but the s5p-mfc driver fills those field using the platform device name, which in turn is the name of the device DT node. So not only the filled information isn't correct but also

[PATCH V2 25/63] clocksource/drivers/mxs_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 25/63] clocksource/drivers/mxs_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 18/63] clocksource/drivers/arm_global_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 23/63] clocksource/drivers/moxart_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 18/63] clocksource/drivers/arm_global_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 23/63] clocksource/drivers/moxart_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 22/63] clocksource/drivers/mips-gic-timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 19/63] clocksource/drivers/h8300_timer16: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 22/63] clocksource/drivers/mips-gic-timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 19/63] clocksource/drivers/h8300_timer16: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 27/63] clocksource/drivers/pxa_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 28/63] clocksource/drivers/qcom-timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 29/63] clocksource/drivers/samsung_pwm_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 27/63] clocksource/drivers/pxa_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 28/63] clocksource/drivers/qcom-timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 29/63] clocksource/drivers/samsung_pwm_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 16/63] clocksource/drivers/fsl_ftm_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 16/63] clocksource/drivers/fsl_ftm_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 34/63] clocksource/drivers/time-efm32: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 32/63] clocksource/drivers/tegra20_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 31/63] clocksource/drivers/tango_xtal: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 30/63] clocksource/drivers/sun4i_time: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 34/63] clocksource/drivers/time-efm32: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 32/63] clocksource/drivers/tegra20_timer: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 31/63] clocksource/drivers/tango_xtal: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 30/63] clocksource/drivers/sun4i_time: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 37/63] clocksource/drivers/time-pistachio: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 35/63] clocksource/drivers/time-lpc32xx: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 37/63] clocksource/drivers/time-pistachio: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 35/63] clocksource/drivers/time-lpc32xx: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

On 06/15/2016 10:19 PM, Boqun Feng wrote: On Wed, Jun 15, 2016 at 03:01:19PM -0400, Waiman Long wrote: On 06/15/2016 04:04 AM, Boqun Feng wrote: Hi Waiman, On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote: The osq_lock() and osq_unlock() function may not provide the necessary

Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

On Thu, Jun 16, 2016 at 05:16:04PM -0400, Vince Weaver wrote: > I'd believe the 6W report as a value for how much the CPU is using. > The others seem spurious. I guess I should go check the Errata for > this chip. Maybe this is the reason why it got enabled on F15 only :-) -- Regards/Gruss,

Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

On Thu, Jun 16, 2016 at 05:16:04PM -0400, Vince Weaver wrote: > I'd believe the 6W report as a value for how much the CPU is using. > The others seem spurious. I guess I should go check the Errata for > this chip. Maybe this is the reason why it got enabled on F15 only :-) -- Regards/Gruss,

Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

On 06/15/2016 10:19 PM, Boqun Feng wrote: On Wed, Jun 15, 2016 at 03:01:19PM -0400, Waiman Long wrote: On 06/15/2016 04:04 AM, Boqun Feng wrote: Hi Waiman, On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote: The osq_lock() and osq_unlock() function may not provide the necessary

[PATCH V2 39/63] clocksource/drivers/timer-atlas7: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 39/63] clocksource/drivers/timer-atlas7: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 38/63] clocksource/drivers/time-pistachio: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 42/63] clocksource/drivers/prima2: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 41/63] clocksource/drivers/timer-atmel-st: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 38/63] clocksource/drivers/time-pistachio: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 42/63] clocksource/drivers/prima2: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 41/63] clocksource/drivers/timer-atmel-st: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 45/63] clocksource/drivers/timer-keystone: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 49/63] clocksource/drivers/timer-ti-32k: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 43/63] clocksource/drivers/timer-imx-gpt: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 45/63] clocksource/drivers/timer-keystone: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 49/63] clocksource/drivers/timer-ti-32k: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 43/63] clocksource/drivers/timer-imx-gpt: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 47/63] clocksource/drivers/timer-stm32: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

[PATCH V2 46/63] clocksource/drivers/timer-sp804: Convert init function to return error

The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting

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