Re: [PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device Tree

Hi Yuriy, On 11/11/16 14:38, Yuriy Kolerov wrote: > Ignore value of interrupt distribution mode for common interrupts in > IDU since setting of affinity using value from Device Tree is deprecated > in ARC. Originally it is done in idu_irq_xlate() function and it is > semantically wrong and does

Re: [PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device Tree

Hi Yuriy, On 11/11/16 14:38, Yuriy Kolerov wrote: > Ignore value of interrupt distribution mode for common interrupts in > IDU since setting of affinity using value from Device Tree is deprecated > in ARC. Originally it is done in idu_irq_xlate() function and it is > semantically wrong and does

Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_simple_widgets" to the asoc tree

The patch ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_simple_widgets has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_simple_widgets" to the asoc tree

The patch ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_simple_widgets has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Re: [PATCH v14 4/9] acpi/arm64: Add GTDT table parse driver

On Fri, Nov 11, 2016 at 09:46:29PM +0800, Hanjun Guo wrote: > On 10/21/2016 12:37 AM, Mark Rutland wrote: > >On Thu, Sep 29, 2016 at 02:17:12AM +0800, fu@linaro.org wrote: > >>+static int __init map_gt_gsi(u32 interrupt, u32 flags) > >>+{ > >>+ int trigger, polarity; > >>+ > >>+ if

Re: [PATCH v14 4/9] acpi/arm64: Add GTDT table parse driver

On Fri, Nov 11, 2016 at 09:46:29PM +0800, Hanjun Guo wrote: > On 10/21/2016 12:37 AM, Mark Rutland wrote: > >On Thu, Sep 29, 2016 at 02:17:12AM +0800, fu@linaro.org wrote: > >>+static int __init map_gt_gsi(u32 interrupt, u32 flags) > >>+{ > >>+ int trigger, polarity; > >>+ > >>+ if

[PATCH v2] firmware: fix async, manual firmware loading

When wait_for_completion_interruptible_timeout() is called from _request_firmware_load() with a large timeout value (here, MAX_JIFFY_OFFSET because it's a an explicit call to the user helper), its return value (a long) will overflow when silently casted to int, be stored as a negative integer and

[PATCH v2] firmware: fix async, manual firmware loading

When wait_for_completion_interruptible_timeout() is called from _request_firmware_load() with a large timeout value (here, MAX_JIFFY_OFFSET because it's a an explicit call to the user helper), its return value (a long) will overflow when silently casted to int, be stored as a negative integer and

Re: Kbuild: CC= handling broken for tools/

On Fri, Nov 11, 2016 at 04:14:27PM +0100, Jiri Olsa wrote: > On Fri, Nov 11, 2016 at 03:04:35PM +0100, Jiri Slaby wrote: > > On 11/11/2016, 03:00 PM, Jiri Olsa wrote: > > > On Fri, Nov 11, 2016 at 12:23:25PM +0100, Jiri Slaby wrote: > > >> Hi, > > >> > > >> I am trying a new gcc with new warnings

Re: Kbuild: CC= handling broken for tools/

On Fri, Nov 11, 2016 at 04:14:27PM +0100, Jiri Olsa wrote: > On Fri, Nov 11, 2016 at 03:04:35PM +0100, Jiri Slaby wrote: > > On 11/11/2016, 03:00 PM, Jiri Olsa wrote: > > > On Fri, Nov 11, 2016 at 12:23:25PM +0100, Jiri Slaby wrote: > > >> Hi, > > >> > > >> I am trying a new gcc with new warnings

Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name" to the asoc tree

The patch ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name" to the asoc tree

The patch ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_routing" to the asoc tree

The patch ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_routing has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_routing" to the asoc tree

The patch ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_routing has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "ASoC: soc-core: snd_soc_get_dai_name() become non static" to the asoc tree

The patch ASoC: soc-core: snd_soc_get_dai_name() become non static has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_prefix" to the asoc tree

The patch ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_prefix has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: soc-core: snd_soc_get_dai_name() become non static" to the asoc tree

The patch ASoC: soc-core: snd_soc_get_dai_name() become non static has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_prefix" to the asoc tree

The patch ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_prefix has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On Wed, Nov 09, 2016 at 02:19:36PM +, Lorenzo Pieralisi wrote: > +struct iommu_fwentry { > + struct list_head list; > + struct fwnode_handle *fwnode; > + const struct iommu_ops *ops; > +}; Is there a reason the iommu_ops need to be stored there? Currently it seems that the ops are

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On Wed, Nov 09, 2016 at 02:19:36PM +, Lorenzo Pieralisi wrote: > +struct iommu_fwentry { > + struct list_head list; > + struct fwnode_handle *fwnode; > + const struct iommu_ops *ops; > +}; Is there a reason the iommu_ops need to be stored there? Currently it seems that the ops are

Re: Kbuild: CC= handling broken for tools/

On Fri, Nov 11, 2016 at 03:04:35PM +0100, Jiri Slaby wrote: > On 11/11/2016, 03:00 PM, Jiri Olsa wrote: > > On Fri, Nov 11, 2016 at 12:23:25PM +0100, Jiri Slaby wrote: > >> Hi, > >> > >> I am trying a new gcc with new warnings enabled: > >> > >> make O=../a/gcc7/ CC='gcc-7' V=1 kernel/exit.o > >>

Re: Kbuild: CC= handling broken for tools/

On Fri, Nov 11, 2016 at 03:04:35PM +0100, Jiri Slaby wrote: > On 11/11/2016, 03:00 PM, Jiri Olsa wrote: > > On Fri, Nov 11, 2016 at 12:23:25PM +0100, Jiri Slaby wrote: > >> Hi, > >> > >> I am trying a new gcc with new warnings enabled: > >> > >> make O=../a/gcc7/ CC='gcc-7' V=1 kernel/exit.o > >>

Re: [PATCH 0/3] perf tools: Plug jvmti compilation into perf build

On Fri, Nov 11, 2016 at 1:51 AM, Jiri Olsa wrote: > > On Wed, Nov 02, 2016 at 02:35:46PM +0100, Jiri Olsa wrote: > > hi, > > adding jvmti compilation under perf build, so it's easy > > to put it under rpm. > > > > I plan on updating fedora/rhel perf rpm, to have the jvmti > >

Re: [PATCH 0/3] perf tools: Plug jvmti compilation into perf build

On Fri, Nov 11, 2016 at 1:51 AM, Jiri Olsa wrote: > > On Wed, Nov 02, 2016 at 02:35:46PM +0100, Jiri Olsa wrote: > > hi, > > adding jvmti compilation under perf build, so it's easy > > to put it under rpm. > > > > I plan on updating fedora/rhel perf rpm, to have the jvmti > > placed in like: > >

Re: [PATCH v5 2/3] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

A quick review: On 11/08/2016 07:34 AM, Rick Chang wrote: > Add v4l2 driver for Mediatek JPEG Decoder > > Signed-off-by: Rick Chang > Signed-off-by: Minghsiu Tsai > --- > drivers/media/platform/Kconfig | 15 + >

Re: [PATCH v5 2/3] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

A quick review: On 11/08/2016 07:34 AM, Rick Chang wrote: > Add v4l2 driver for Mediatek JPEG Decoder > > Signed-off-by: Rick Chang > Signed-off-by: Minghsiu Tsai > --- > drivers/media/platform/Kconfig | 15 + > drivers/media/platform/Makefile |2 + >

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

On Fri, Nov 11, 2016 at 02:34:39PM +, Robin Murphy wrote: > On 10/11/16 16:16, Joerg Roedel wrote: > > On Thu, Nov 10, 2016 at 04:07:08PM +, Robin Murphy wrote: > >> On 10/11/16 15:46, Joerg Roedel wrote: > >>> On Fri, Nov 04, 2016 at 11:24:06AM +, Eric Auger wrote: > +

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

On Fri, Nov 11, 2016 at 02:34:39PM +, Robin Murphy wrote: > On 10/11/16 16:16, Joerg Roedel wrote: > > On Thu, Nov 10, 2016 at 04:07:08PM +, Robin Murphy wrote: > >> On 10/11/16 15:46, Joerg Roedel wrote: > >>> On Fri, Nov 04, 2016 at 11:24:06AM +, Eric Auger wrote: > +

Re: [RFC] [media] Add Synopsys Designware HDMI RX PHY e405 driver

Hi Jose, On 11/09/2016 06:43 PM, Jose Abreu wrote: > Hi All, > > This is a RFC patch for Synopsys Designware HDMI RX PHY e405. > This phy receives and decodes HDMI video that is delivered to > a controller. The controller bit is not yet ready for submission > but we are planning to submit it as

Re: [RFC] [media] Add Synopsys Designware HDMI RX PHY e405 driver

Hi Jose, On 11/09/2016 06:43 PM, Jose Abreu wrote: > Hi All, > > This is a RFC patch for Synopsys Designware HDMI RX PHY e405. > This phy receives and decodes HDMI video that is delivered to > a controller. The controller bit is not yet ready for submission > but we are planning to submit it as

Re: [PATCH v8 0/3] drm: add explict fencing

I tested this series on the db410c platform and I've seen no regressions from previous versions of this series. Tested-by: Robert Foss

Re: [PATCH v8 0/3] drm: add explict fencing

I tested this series on the db410c platform and I've seen no regressions from previous versions of this series. Tested-by: Robert Foss

Re: [PATCH] Video: fbdev: Remove impossible condition.

Sachin Shukla wrote: From: "Sachin Shukla" xoffset and yoffset of struct fb_var_screeninfo are unsigned and so they can never be less than 0. Signed-off-by: Sachin Shukla fsl-diu-fb portion: Acked-by: Timur Tabi

Re: [PATCH] Video: fbdev: Remove impossible condition.

Sachin Shukla wrote: From: "Sachin Shukla" xoffset and yoffset of struct fb_var_screeninfo are unsigned and so they can never be less than 0. Signed-off-by: Sachin Shukla fsl-diu-fb portion: Acked-by: Timur Tabi

PRIVATE AND CONFIDENTIAL

Hello, I have a business deal it’s private and confidence for more information please feel free to contact me with your personal telephone number for easy communication +27835485068 You’re sincerely, Savelieva Costa

PRIVATE AND CONFIDENTIAL

Hello, I have a business deal it’s private and confidence for more information please feel free to contact me with your personal telephone number for easy communication +27835485068 You’re sincerely, Savelieva Costa

Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC

On Fri, Nov 11, 2016 at 03:39:05PM +0100, Thomas Gleixner wrote: > On Fri, 11 Nov 2016, Peter Zijlstra wrote: > > A wee bit like so... > > + > > +static inline bool refcount_sub_and_test(int i, refcount_t *r) > > Why would we want to expose that at all? refcount_inc() and >

Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC

On Fri, Nov 11, 2016 at 03:39:05PM +0100, Thomas Gleixner wrote: > On Fri, 11 Nov 2016, Peter Zijlstra wrote: > > A wee bit like so... > > + > > +static inline bool refcount_sub_and_test(int i, refcount_t *r) > > Why would we want to expose that at all? refcount_inc() and >

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

On Fri, Nov 11, 2016 at 01:39:35PM +, Gabriele Paoloni wrote: > Hi Arnd > > > -Original Message- > > From: Arnd Bergmann [mailto:a...@arndb.de] > > Sent: 10 November 2016 16:07 > > To: Gabriele Paoloni > > Cc: linux-arm-ker...@lists.infradead.org; Yuanzhichang; > >

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

On Fri, Nov 11, 2016 at 01:39:35PM +, Gabriele Paoloni wrote: > Hi Arnd > > > -Original Message- > > From: Arnd Bergmann [mailto:a...@arndb.de] > > Sent: 10 November 2016 16:07 > > To: Gabriele Paoloni > > Cc: linux-arm-ker...@lists.infradead.org; Yuanzhichang; > >

Re: [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

Hi Laurent, On 11/11/16 01:50, Laurent Pinchart wrote: > Hi Robin, > > On Friday 21 Oct 2016 18:52:53 Robin Murphy wrote: >> On 20/10/16 00:36, Magnus Damm wrote: >>> From: Magnus Damm >>> >>> Introduce an alternative set of iommu_ops suitable for 64-bit ARM >>> as

Re: [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

Hi Laurent, On 11/11/16 01:50, Laurent Pinchart wrote: > Hi Robin, > > On Friday 21 Oct 2016 18:52:53 Robin Murphy wrote: >> On 20/10/16 00:36, Magnus Damm wrote: >>> From: Magnus Damm >>> >>> Introduce an alternative set of iommu_ops suitable for 64-bit ARM >>> as well as 32-bit ARM when

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

On 10.11.2016 13:22, Oliver Neukum wrote: On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote: Kai-Heng Feng writes: On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote: Oliver Neukum writes: On Tue, 2016-11-08 at 13:44 -0500,

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

On 10.11.2016 13:22, Oliver Neukum wrote: On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote: Kai-Heng Feng writes: On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote: Oliver Neukum writes: On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: These problems could very well be caused by

Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC

On Fri, 11 Nov 2016, Peter Zijlstra wrote: > A wee bit like so... > + > +static inline bool refcount_sub_and_test(int i, refcount_t *r) Why would we want to expose that at all? refcount_inc() and refcount_dec_and_test() is what is required for refcounting. I know there are a few users of

Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC

On Fri, 11 Nov 2016, Peter Zijlstra wrote: > A wee bit like so... > + > +static inline bool refcount_sub_and_test(int i, refcount_t *r) Why would we want to expose that at all? refcount_inc() and refcount_dec_and_test() is what is required for refcounting. I know there are a few users of

Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task

On Fri, Nov 11, 2016 at 03:32:04PM +0100, Tommaso Cucinotta wrote: > >+struct sched_param param = { .sched_priority = 50 }; > > won't you have a tunable here? (sysctl?) You can use the regular userspace tools, like schedtool and chrt to set priorities.

Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task

On Fri, Nov 11, 2016 at 03:32:04PM +0100, Tommaso Cucinotta wrote: > >+struct sched_param param = { .sched_priority = 50 }; > > won't you have a tunable here? (sysctl?) You can use the regular userspace tools, like schedtool and chrt to set priorities.

[PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device Tree

Ignore value of interrupt distribution mode for common interrupts in IDU since setting of affinity using value from Device Tree is deprecated in ARC. Originally it is done in idu_irq_xlate() function and it is semantically wrong and does not guaranty that an affinity value will be set properly.

[PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device Tree

Ignore value of interrupt distribution mode for common interrupts in IDU since setting of affinity using value from Device Tree is deprecated in ARC. Originally it is done in idu_irq_xlate() function and it is semantically wrong and does not guaranty that an affinity value will be set properly.

[PATCH v8 3/3] drm/fence: add out-fences support

From: Gustavo Padovan Support DRM out-fences by creating a sync_file with a fence for each CRTC that sets the OUT_FENCE_PTR property. We use the out_fence pointer received in the OUT_FENCE_PTR prop to send the sync_file fd back to userspace. The sync_file and

Re: BUG: 'list_empty(>free_vbufs)' is true!

On 11/08/2016, 09:37 PM, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at some kind > of memory corruption. > > > diff --git

[PATCH v8 3/3] drm/fence: add out-fences support

From: Gustavo Padovan Support DRM out-fences by creating a sync_file with a fence for each CRTC that sets the OUT_FENCE_PTR property. We use the out_fence pointer received in the OUT_FENCE_PTR prop to send the sync_file fd back to userspace. The sync_file and fd are allocated/created before

Re: BUG: 'list_empty(>free_vbufs)' is true!

On 11/08/2016, 09:37 PM, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at some kind > of memory corruption. > > > diff --git

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

On 10/11/16 16:16, Joerg Roedel wrote: > On Thu, Nov 10, 2016 at 04:07:08PM +, Robin Murphy wrote: >> On 10/11/16 15:46, Joerg Roedel wrote: >>> On Fri, Nov 04, 2016 at 11:24:06AM +, Eric Auger wrote: + resource_list_for_each_entry(window, >windows) { + if

Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback

On 10/11/16 16:16, Joerg Roedel wrote: > On Thu, Nov 10, 2016 at 04:07:08PM +, Robin Murphy wrote: >> On 10/11/16 15:46, Joerg Roedel wrote: >>> On Fri, Nov 04, 2016 at 11:24:06AM +, Eric Auger wrote: + resource_list_for_each_entry(window, >windows) { + if

[PATCH v8 0/3] drm: add explict fencing

From: Gustavo Padovan Hi, Another iteration after Brian comments. Please refer to the cover letter[1] in a previous version to check for more details. The changes since the last version can be seen in commit message on each patch. Robert Foss managed to port

[PATCH v8 0/3] drm: add explict fencing

From: Gustavo Padovan Hi, Another iteration after Brian comments. Please refer to the cover letter[1] in a previous version to check for more details. The changes since the last version can be seen in commit message on each patch. Robert Foss managed to port Android's drm_hwcomposer to the

[PATCH v8 1/3] drm/fence: add in-fences support

From: Gustavo Padovan There is now a new property called IN_FENCE_FD attached to every plane state that receives sync_file fds from userspace via the atomic commit IOCTL. The fd is then translated to a fence (that may be a fence_array subclass or just a normal

[PATCH v8 2/3] drm/fence: add fence timeline to drm_crtc

From: Gustavo Padovan Create one timeline context for each CRTC to be able to handle out-fences and signal them. It adds a few members to struct drm_crtc: fence_context, where we store the context we get from fence_context_alloc(), the fence seqno and the fence

RCU related tracebacks in various boot tests in -next

/test scripts are in the various subdirectories of https://github.com/groeck/linux-build-test/tree/master/rootfs/. Thanks, Guenter arm: [1.699096] === [1.699188] suspicious RCU usage. ] [1.699340] 4.9.0-rc4-next-2016 #4 Not tainted [1.699462

[PATCH v8 1/3] drm/fence: add in-fences support

From: Gustavo Padovan There is now a new property called IN_FENCE_FD attached to every plane state that receives sync_file fds from userspace via the atomic commit IOCTL. The fd is then translated to a fence (that may be a fence_array subclass or just a normal fence) and then used by DRM to

[PATCH v8 2/3] drm/fence: add fence timeline to drm_crtc

From: Gustavo Padovan Create one timeline context for each CRTC to be able to handle out-fences and signal them. It adds a few members to struct drm_crtc: fence_context, where we store the context we get from fence_context_alloc(), the fence seqno and the fence lock, that we pass in fence_init()

RCU related tracebacks in various boot tests in -next

/test scripts are in the various subdirectories of https://github.com/groeck/linux-build-test/tree/master/rootfs/. Thanks, Guenter arm: [1.699096] === [1.699188] suspicious RCU usage. ] [1.699340] 4.9.0-rc4-next-2016 #4 Not tainted [1.699462

Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task

Hi, On 11/11/2016 11:22, Viresh Kumar wrote: If slow path frequency changes are conducted in a SCHED_OTHER context then they may be delayed for some amount of time, including indefinitely, when real time or deadline activity is taking place. Move the slow path to a real time kernel thread. In

Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task

Hi, On 11/11/2016 11:22, Viresh Kumar wrote: If slow path frequency changes are conducted in a SCHED_OTHER context then they may be delayed for some amount of time, including indefinitely, when real time or deadline activity is taking place. Move the slow path to a real time kernel thread. In

Re: [PATCH] Gpu: drm: arm: - Fix possible dereference of NULL

On Fri, Nov 11, 2016 at 01:58:46PM +, Emil Velikov wrote: > On 11 November 2016 at 10:56, Liviu Dudau wrote: > > Hi Shailendra, > > > > On Fri, Nov 11, 2016 at 02:16:08PM +0530, Shailendra Verma wrote: > >> From: "Shailendra Verma" > >> > >>

Re: [PATCH] Gpu: drm: arm: - Fix possible dereference of NULL

On Fri, Nov 11, 2016 at 01:58:46PM +, Emil Velikov wrote: > On 11 November 2016 at 10:56, Liviu Dudau wrote: > > Hi Shailendra, > > > > On Fri, Nov 11, 2016 at 02:16:08PM +0530, Shailendra Verma wrote: > >> From: "Shailendra Verma" > >> > >> There is possible dereference of NULL pointer if

[PATCH] sched/cpuacct: avoid %lld seq_printf warning

For s390 kernel builds I keep getting this warning: kernel/sched/cpuacct.c: In function 'cpuacct_stats_show': kernel/sched/cpuacct.c:298:25: warning: format '%lld' expects argument of type 'long long int', but argument 4 has type 'clock_t {aka long int}' [-Wformat=] seq_printf(sf, "%s

[PATCH] sched/cpuacct: avoid %lld seq_printf warning

For s390 kernel builds I keep getting this warning: kernel/sched/cpuacct.c: In function 'cpuacct_stats_show': kernel/sched/cpuacct.c:298:25: warning: format '%lld' expects argument of type 'long long int', but argument 4 has type 'clock_t {aka long int}' [-Wformat=] seq_printf(sf, "%s

Re: [PATCH 2/2] staging: iio: ad7606: move out of staging

On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote: > Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the > corresponding Makefile and Kconfig associated with the change. This is obviously OK, but when you generate a patch that moves files use `git format-patch -M ...`. This

Re: [PATCH 2/2] staging: iio: ad7606: move out of staging

On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote: > Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the > corresponding Makefile and Kconfig associated with the change. This is obviously OK, but when you generate a patch that moves files use `git format-patch -M ...`. This

Re: [PATCH 1/3] cpufreq: schedutil: enable fast switch earlier

On Fri, Nov 11, 2016 at 03:52:21PM +0530, Viresh Kumar wrote: > @@ -456,8 +460,6 @@ static int sugov_init(struct cpufreq_policy *policy) > > out: > mutex_unlock(_tunables_lock); > - > - cpufreq_enable_fast_switch(policy); > return 0; > > fail: > @@ -468,6 +470,10 @@ static

Re: [PATCH 1/3] cpufreq: schedutil: enable fast switch earlier

On Fri, Nov 11, 2016 at 03:52:21PM +0530, Viresh Kumar wrote: > @@ -456,8 +460,6 @@ static int sugov_init(struct cpufreq_policy *policy) > > out: > mutex_unlock(_tunables_lock); > - > - cpufreq_enable_fast_switch(policy); > return 0; > > fail: > @@ -468,6 +470,10 @@ static

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

On 11/11/16 13:34, Rob Herring wrote: On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla wrote: On 10/11/16 19:03, Olof Johansson wrote: On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla wrote: [...] E.g. Amlogic follows most of the legacy protocol

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

On 11/11/16 13:34, Rob Herring wrote: On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla wrote: On 10/11/16 19:03, Olof Johansson wrote: On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla wrote: [...] E.g. Amlogic follows most of the legacy protocol though it deviates in couple of things which

Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote: > Eliminate the non-standard attribute in_voltage_range and move its > functionality under the scale attribute. read_raw() has been taken care > of previously so only write_raw() is handled here. > > Additionally, rename the attribute

Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote: > Eliminate the non-standard attribute in_voltage_range and move its > functionality under the scale attribute. read_raw() has been taken care > of previously so only write_raw() is handled here. > > Additionally, rename the attribute

[PATCH v3 3/4] lib/scatterlist: Introduce and export __sg_alloc_table_from_pages

From: Tvrtko Ursulin Drivers like i915 benefit from being able to control the maxium size of the sg coallesced segment while building the scatter- gather list. Introduce and export the __sg_alloc_table_from_pages function which will allow it that control. v2: Reorder

[PATCH v3 3/4] lib/scatterlist: Introduce and export __sg_alloc_table_from_pages

From: Tvrtko Ursulin Drivers like i915 benefit from being able to control the maxium size of the sg coallesced segment while building the scatter- gather list. Introduce and export the __sg_alloc_table_from_pages function which will allow it that control. v2: Reorder parameters. (Chris Wilson)

Re: [PATCH v8 0/3] drm: add explict fencing

Subject was supposed to be v9! sorry about that. 2016-11-11 Gustavo Padovan : > From: Gustavo Padovan > > Hi, > > Another iteration after Brian comments. Please refer to the cover letter[1] in > a previous version to check for more

Re: [PATCH v8 0/3] drm: add explict fencing

Subject was supposed to be v9! sorry about that. 2016-11-11 Gustavo Padovan : > From: Gustavo Padovan > > Hi, > > Another iteration after Brian comments. Please refer to the cover letter[1] in > a previous version to check for more details. > > The changes since the last version can be seen

[PATCH] net: ethernet: ti: davinci_cpdma: don't stop ctlr if it was stopped

No need to stop ctlr if it was already stopped. It can cause timeout warns. Steps: - ifconfig eth0 down - ethtool -l eth0 rx 8 tx 8 - ethtool -l eth0 rx 1 tx 1 Signed-off-by: Ivan Khoronzhuk --- Based on net-next/master drivers/net/ethernet/ti/davinci_cpdma.c | 2

[PATCH] net: ethernet: ti: davinci_cpdma: don't stop ctlr if it was stopped

No need to stop ctlr if it was already stopped. It can cause timeout warns. Steps: - ifconfig eth0 down - ethtool -l eth0 rx 8 tx 8 - ethtool -l eth0 rx 1 tx 1 Signed-off-by: Ivan Khoronzhuk --- Based on net-next/master drivers/net/ethernet/ti/davinci_cpdma.c | 2 +- 1 file changed, 1

Re: Kbuild: CC= handling broken for tools/

On 11/11/2016, 03:00 PM, Jiri Olsa wrote: > On Fri, Nov 11, 2016 at 12:23:25PM +0100, Jiri Slaby wrote: >> Hi, >> >> I am trying a new gcc with new warnings enabled: >> >> make O=../a/gcc7/ CC='gcc-7' V=1 kernel/exit.o >> EXTRA_CFLAGS='-Wimplicit-fallthrough=3' >> >> But the build fails when

Re: Kbuild: CC= handling broken for tools/

On 11/11/2016, 03:00 PM, Jiri Olsa wrote: > On Fri, Nov 11, 2016 at 12:23:25PM +0100, Jiri Slaby wrote: >> Hi, >> >> I am trying a new gcc with new warnings enabled: >> >> make O=../a/gcc7/ CC='gcc-7' V=1 kernel/exit.o >> EXTRA_CFLAGS='-Wimplicit-fallthrough=3' >> >> But the build fails when

[PATCH v3 2/3] ASoC: tse850: document axentia,tse850-pcm5142 bindings

The TSE-850 is an FM Transmitter Station Equipment, designed to generate baseband signals for FM, mainly the DARC subcarrier, but other signals are also possible. Signed-off-by: Peter Rosin --- .../bindings/sound/axentia,tse850-pcm5142.txt | 88 ++

[PATCH v3 2/3] ASoC: tse850: document axentia,tse850-pcm5142 bindings

The TSE-850 is an FM Transmitter Station Equipment, designed to generate baseband signals for FM, mainly the DARC subcarrier, but other signals are also possible. Signed-off-by: Peter Rosin --- .../bindings/sound/axentia,tse850-pcm5142.txt | 88 ++ MAINTAINERS

Re: [PATCH 0/2] bnx2: Hard reset bnx2 chip at probe stage

On 11/11/16 at 09:46pm, Baoquan He wrote: > Hi bnx2 experts, > > In commit 3e1be7a ("bnx2: Reset device during driver initialization"), > firmware requesting code was moved from open stage to probe stage. > The reason is in kdump kernel hardware iommu need device be reset in > driver probe stage,

Re: [PATCH 0/2] bnx2: Hard reset bnx2 chip at probe stage

On 11/11/16 at 09:46pm, Baoquan He wrote: > Hi bnx2 experts, > > In commit 3e1be7a ("bnx2: Reset device during driver initialization"), > firmware requesting code was moved from open stage to probe stage. > The reason is in kdump kernel hardware iommu need device be reset in > driver probe stage,

Re: Kbuild: CC= handling broken for tools/

On Fri, Nov 11, 2016 at 12:23:25PM +0100, Jiri Slaby wrote: > Hi, > > I am trying a new gcc with new warnings enabled: > > make O=../a/gcc7/ CC='gcc-7' V=1 kernel/exit.o > EXTRA_CFLAGS='-Wimplicit-fallthrough=3' > > But the build fails when building under tools/: > ... > make -f

Re: Kbuild: CC= handling broken for tools/

On Fri, Nov 11, 2016 at 12:23:25PM +0100, Jiri Slaby wrote: > Hi, > > I am trying a new gcc with new warnings enabled: > > make O=../a/gcc7/ CC='gcc-7' V=1 kernel/exit.o > EXTRA_CFLAGS='-Wimplicit-fallthrough=3' > > But the build fails when building under tools/: > ... > make -f

Re: [PATCH v14 4/9] acpi/arm64: Add GTDT table parse driver

On 11/11/2016 09:46 PM, Hanjun Guo wrote: Hi Mark, Sorry for the late reply. On 10/21/2016 12:37 AM, Mark Rutland wrote: Hi, As a heads-up, on v4.9-rc1 I see conflicts at least against arch/arm64/Kconfig. Luckily git am -3 seems to be able to fix that up automatically, but this will need to

Re: [PATCH v14 4/9] acpi/arm64: Add GTDT table parse driver

On 11/11/2016 09:46 PM, Hanjun Guo wrote: Hi Mark, Sorry for the late reply. On 10/21/2016 12:37 AM, Mark Rutland wrote: Hi, As a heads-up, on v4.9-rc1 I see conflicts at least against arch/arm64/Kconfig. Luckily git am -3 seems to be able to fix that up automatically, but this will need to

Re: [PATCH] Gpu: drm: arm: - Fix possible dereference of NULL

On 11 November 2016 at 10:56, Liviu Dudau wrote: > Hi Shailendra, > > On Fri, Nov 11, 2016 at 02:16:08PM +0530, Shailendra Verma wrote: >> From: "Shailendra Verma" >> >> There is possible dereference of NULL pointer if kmalloc fails. > > You could

Re: [PATCH] Gpu: drm: arm: - Fix possible dereference of NULL

On 11 November 2016 at 10:56, Liviu Dudau wrote: > Hi Shailendra, > > On Fri, Nov 11, 2016 at 02:16:08PM +0530, Shailendra Verma wrote: >> From: "Shailendra Verma" >> >> There is possible dereference of NULL pointer if kmalloc fails. > > You could add: ... when the function returns. From the

Re: [PATCH v3 2/3] pinctrl: sunxi: Add support for fetching pinconf settings from hardware

On Fri, Nov 11, 2016 at 9:51 PM, Maxime Ripard wrote: > On Fri, Nov 11, 2016 at 05:50:35PM +0800, Chen-Yu Tsai wrote: >> The sunxi pinctrl driver only caches whatever pinconf setting was last >> set on a given pingroup. This is not particularly helpful, nor is it

Re: [PATCH v3 2/3] pinctrl: sunxi: Add support for fetching pinconf settings from hardware

On Fri, Nov 11, 2016 at 9:51 PM, Maxime Ripard wrote: > On Fri, Nov 11, 2016 at 05:50:35PM +0800, Chen-Yu Tsai wrote: >> The sunxi pinctrl driver only caches whatever pinconf setting was last >> set on a given pingroup. This is not particularly helpful, nor is it >> correct. >> >> Fix this by

Re: [linuxwifi] [PATCH 1/2] iwlwifi: fix MODULE_FIRMWARE for 6030

Hi Jürg, On Mon, 2016-10-10 at 18:30 +0200, Jürg Billeter wrote: > IWL6000G2B_UCODE_API_MAX is not defined. ucode_api_max of > IWL_DEVICE_6030 uses IWL6000G2_UCODE_API_MAX. Use this also for > MODULE_FIRMWARE. > > Fixes: 9d9b21d1b616 ("iwlwifi: remove IWL_*_UCODE_API_OK") > Signed-off-by: Jürg

Re: [linuxwifi] [PATCH 1/2] iwlwifi: fix MODULE_FIRMWARE for 6030

Hi Jürg, On Mon, 2016-10-10 at 18:30 +0200, Jürg Billeter wrote: > IWL6000G2B_UCODE_API_MAX is not defined. ucode_api_max of > IWL_DEVICE_6030 uses IWL6000G2_UCODE_API_MAX. Use this also for > MODULE_FIRMWARE. > > Fixes: 9d9b21d1b616 ("iwlwifi: remove IWL_*_UCODE_API_OK") > Signed-off-by: Jürg

<    3   4   5   6   7   8   9   10   11   12   >