Re: [PATCH 4/4] cpu_cooling: Drop static-power related stuff

On 16/11/2017 03:47, Viresh Kumar wrote: > On 15-11-17, 19:17, Rafael J. Wysocki wrote: >> However, I would like to see a clear declaration from whoever is >> maintaining that code today that there is a plan in place to upstream >> it and that this plan will actually be acted on. And, better yet,

Re: [PATCH 4/4] cpu_cooling: Drop static-power related stuff

On 16/11/2017 03:47, Viresh Kumar wrote: > On 15-11-17, 19:17, Rafael J. Wysocki wrote: >> However, I would like to see a clear declaration from whoever is >> maintaining that code today that there is a plan in place to upstream >> it and that this plan will actually be acted on. And, better yet,

Re: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A

On Fri, Nov 17, 2017 at 05:57:43AM +, Harninder Rai wrote: > > > > No, not at all, if you want a patch in a specific stable tree, just email > > the git > > commit id to sta...@vger.kernel.org and let me know what > > tree(s) it should be applied to. > > You can drop this patch. Thanks Greg

Re: [alsa-devel] [PATCH] ASoC: Intel: Add defaults for SND_SST_ options and machine drivers

On Fri, 17 Nov 2017 00:01:06 +0100, Pierre-Louis Bossart wrote: > > > > On 11/16/2017 04:24 PM, Linus Torvalds wrote: > > On Thu, Nov 16, 2017 at 2:16 PM, Pierre-Louis Bossart > > wrote: > >> Add 'default m' when sensible > > No. > > > > This is not

Re: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A

On Fri, Nov 17, 2017 at 05:57:43AM +, Harninder Rai wrote: > > > > No, not at all, if you want a patch in a specific stable tree, just email > > the git > > commit id to sta...@vger.kernel.org and let me know what > > tree(s) it should be applied to. > > You can drop this patch. Thanks Greg

Re: [alsa-devel] [PATCH] ASoC: Intel: Add defaults for SND_SST_ options and machine drivers

On Fri, 17 Nov 2017 00:01:06 +0100, Pierre-Louis Bossart wrote: > > > > On 11/16/2017 04:24 PM, Linus Torvalds wrote: > > On Thu, Nov 16, 2017 at 2:16 PM, Pierre-Louis Bossart > > wrote: > >> Add 'default m' when sensible > > No. > > > > This is not sensible, and is not at all what I

Re: [PATCH v1] mm: relax deferred struct page requirements

On Thu, Nov 16, 2017 at 08:46:01PM -0500, Pavel Tatashin wrote: > There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT, > as all the page initialization code is in common code. > > Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code > does not really use hotplug

Re: [PATCH v1] mm: relax deferred struct page requirements

On Thu, Nov 16, 2017 at 08:46:01PM -0500, Pavel Tatashin wrote: > There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT, > as all the page initialization code is in common code. > > Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code > does not really use hotplug

Re: [PATCH v7 06/13] slimbus: Add messaging APIs to slimbus framework

On Wed, Nov 15, 2017 at 02:10:36PM +, srinivas.kandaga...@linaro.org wrote: > +void slim_msg_response(struct slim_controller *ctrl, u8 *reply, u8 tid, u8 > len) > +{ > + struct slim_msg_txn *txn; > + struct slim_val_inf *msg; > + unsigned long flags; > + > +

Re: [PATCH v7 06/13] slimbus: Add messaging APIs to slimbus framework

On Wed, Nov 15, 2017 at 02:10:36PM +, srinivas.kandaga...@linaro.org wrote: > +void slim_msg_response(struct slim_controller *ctrl, u8 *reply, u8 tid, u8 > len) > +{ > + struct slim_msg_txn *txn; > + struct slim_val_inf *msg; > + unsigned long flags; > + > +

Re: 4.1 EOL

On 11/16/17, Jani Nikula wrote: > On Wed, 15 Nov 2017, Tuncer Ayaz wrote: > > I don't follow why you think it's a different platform and how I > > might have "more" definitely shown v4.1 to be good, but I'll trust > > your judgement as a drm

Re: 4.1 EOL

On 11/16/17, Jani Nikula wrote: > On Wed, 15 Nov 2017, Tuncer Ayaz wrote: > > I don't follow why you think it's a different platform and how I > > might have "more" definitely shown v4.1 to be good, but I'll trust > > your judgement as a drm dev and not argue :). > > You apparently have Sandy

Re: [RFC v5 10/11] [media] vb2: add out-fence support to QBUF

On Thursday, November 16, 2017 2:10:56 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create an out_fence and send its fd to userspace on the fence_fd field as a return arg for the QBUF call.

Re: [patch 1/7] Documentation: Add license-rules.rst to describe how to properly identify file licenses

On Thu, Nov 16, 2017 at 4:15 PM, Jonas Oberg wrote: > Hi, > >> One other thing that occurred to me is that documentation files, too, >> are copyrightable and should have license identifiers. > > Would it make sense to take an incremental approach to this? Get the > source code and

Re: [RFC v5 10/11] [media] vb2: add out-fence support to QBUF

On Thursday, November 16, 2017 2:10:56 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create an out_fence and send its fd to userspace on the fence_fd field as a return arg for the QBUF call. The fence is signaled on

Re: [patch 1/7] Documentation: Add license-rules.rst to describe how to properly identify file licenses

On Thu, Nov 16, 2017 at 4:15 PM, Jonas Oberg wrote: > Hi, > >> One other thing that occurred to me is that documentation files, too, >> are copyrightable and should have license identifiers. > > Would it make sense to take an incremental approach to this? Get the > source code and identifiers

Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On Fri, Nov 17, 2017 at 07:18:45AM +, Liuwenliang (Abbott Liu) wrote: > On 16/11/17 22:41 Marc Zyngier [mailto:marc.zyng...@arm.com] wrote: > >No, it doesn't. It cannot work, because Cortex-A9 predates the invention > >of the 64bit accessor. I suspect that you are testing stuff in QEMU, >

Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On Fri, Nov 17, 2017 at 07:18:45AM +, Liuwenliang (Abbott Liu) wrote: > On 16/11/17 22:41 Marc Zyngier [mailto:marc.zyng...@arm.com] wrote: > >No, it doesn't. It cannot work, because Cortex-A9 predates the invention > >of the 64bit accessor. I suspect that you are testing stuff in QEMU, >

Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE

On 11/16/2017 11:18 AM, Michal Hocko wrote: + if (flags & MAP_FIXED_SAFE) { + struct vm_area_struct *vma = find_vma(mm, addr); + + if (vma && vma->vm_start <= addr) + return -ENOMEM; + } Could you pick a different error code which

Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE

On 11/16/2017 11:18 AM, Michal Hocko wrote: + if (flags & MAP_FIXED_SAFE) { + struct vm_area_struct *vma = find_vma(mm, addr); + + if (vma && vma->vm_start <= addr) + return -ENOMEM; + } Could you pick a different error code which

Re: [RFC v5 09/11] [media] vb2: add infrastructure to support out-fences

On Friday, November 17, 2017 4:19:00 PM JST, Alexandre Courbot wrote: On Thursday, November 16, 2017 2:10:55 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan Add vb2_setup_out_fence() and the needed members to struct vb2_buffer. v3: - Do not hold

Re: [RFC v5 09/11] [media] vb2: add infrastructure to support out-fences

On Friday, November 17, 2017 4:19:00 PM JST, Alexandre Courbot wrote: On Thursday, November 16, 2017 2:10:55 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan Add vb2_setup_out_fence() and the needed members to struct vb2_buffer. v3: - Do not hold yet another ref to the out_fence

Re: [PATCH] kbuild: define KBUILD_MODNAME even if multiple modules share objects

On 11/16/2017 03:46 PM, Masahiro Yamada wrote: > Currently, KBUILD_MODNAME is defined only when $(modname) contains > just one word. If an object is shared between multiple modules, > undefined KBUILD_MODNAME causes a build error. > > A simple test case is as follows: > > obj-m += foo.o >

Re: [PATCH] kbuild: define KBUILD_MODNAME even if multiple modules share objects

On 11/16/2017 03:46 PM, Masahiro Yamada wrote: > Currently, KBUILD_MODNAME is defined only when $(modname) contains > just one word. If an object is shared between multiple modules, > undefined KBUILD_MODNAME causes a build error. > > A simple test case is as follows: > > obj-m += foo.o >

Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On 16/11/17 22:41 Marc Zyngier [mailto:marc.zyng...@arm.com] wrote: >No, it doesn't. It cannot work, because Cortex-A9 predates the invention >of the 64bit accessor. I suspect that you are testing stuff in QEMU, >which is giving you a SW model that always supports LPAE. I suggest you >test this

Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On 16/11/17 22:41 Marc Zyngier [mailto:marc.zyng...@arm.com] wrote: >No, it doesn't. It cannot work, because Cortex-A9 predates the invention >of the 64bit accessor. I suspect that you are testing stuff in QEMU, >which is giving you a SW model that always supports LPAE. I suggest you >test this

Re: [RFC v5 09/11] [media] vb2: add infrastructure to support out-fences

On Thursday, November 16, 2017 2:10:55 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan Add vb2_setup_out_fence() and the needed members to struct vb2_buffer. v3: - Do not hold yet another ref to the out_fence (Brian Starkey) v2: - change it to

Re: [RFC v5 09/11] [media] vb2: add infrastructure to support out-fences

On Thursday, November 16, 2017 2:10:55 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan Add vb2_setup_out_fence() and the needed members to struct vb2_buffer. v3: - Do not hold yet another ref to the out_fence (Brian Starkey) v2: - change it to reflect fd_install at DQEVENT

RE: [PATCH 12/16] nsproxy: convert nsproxy.count to refcount_t

> The middle of the merge window is the wrong time to send patches as > maintaner attention is going to making certain the merge goes smoothly > and nothing is missed. Sorry Eric, please feel free to ignore the patch until you have time. It is very difficult to figure out the correct time, since

RE: [PATCH 12/16] nsproxy: convert nsproxy.count to refcount_t

> The middle of the merge window is the wrong time to send patches as > maintaner attention is going to making certain the merge goes smoothly > and nothing is missed. Sorry Eric, please feel free to ignore the patch until you have time. It is very difficult to figure out the correct time, since

[PATCH] kmemcheck: add scheduling point to kmemleak_scan

kmemleak_scan will scan struct page for each node and it can be really large and resulting in a soft lockup. We have seen a soft lockup when do scan while compile kernel: [ 220.561051] watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287] [...] [ 220.753837] Call Trace: [

[PATCH] kmemcheck: add scheduling point to kmemleak_scan

kmemleak_scan will scan struct page for each node and it can be really large and resulting in a soft lockup. We have seen a soft lockup when do scan while compile kernel: [ 220.561051] watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287] [...] [ 220.753837] Call Trace: [

Re: [RFC v5 08/11] [media] vb2: add videobuf2 dma-buf fence helpers

On Friday, November 17, 2017 4:02:56 PM JST, Alexandre Courbot wrote: On Thursday, November 16, 2017 2:10:54 AM JST, Gustavo Padovan wrote: From: Javier Martinez Canillas Add a videobuf2-fence.h header file that contains different helpers for DMA buffer sharing

Re: [RFC v5 08/11] [media] vb2: add videobuf2 dma-buf fence helpers

On Friday, November 17, 2017 4:02:56 PM JST, Alexandre Courbot wrote: On Thursday, November 16, 2017 2:10:54 AM JST, Gustavo Padovan wrote: From: Javier Martinez Canillas Add a videobuf2-fence.h header file that contains different helpers for DMA buffer sharing explicit fence support in

Re: [alsa-devel] [PATCH v7 05/13] slimbus: core: add support to device tree helper

On Wed, Nov 15, 2017 at 02:10:35PM +, srinivas.kandaga...@linaro.org wrote: > + > + for_each_child_of_node(ctrl->dev->of_node, node) { > + struct slim_device *sbdev; > + struct slim_eaddr e_addr; > + const char *compat = NULL; > + int reg[2],

Re: [alsa-devel] [PATCH v7 05/13] slimbus: core: add support to device tree helper

On Wed, Nov 15, 2017 at 02:10:35PM +, srinivas.kandaga...@linaro.org wrote: > + > + for_each_child_of_node(ctrl->dev->of_node, node) { > + struct slim_device *sbdev; > + struct slim_eaddr e_addr; > + const char *compat = NULL; > + int reg[2],

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On 17/11/2017 00:35, Tony Krowiak wrote: On 11/16/2017 03:25 PM, Pierre Morel wrote: On 16/11/2017 18:03, Cornelia Huck wrote: On Thu, 16 Nov 2017 17:06:58 +0100 Pierre Morel wrote: On 16/11/2017 16:23, Tony Krowiak wrote: On 11/14/2017 08:57 AM, Cornelia Huck

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On 17/11/2017 00:35, Tony Krowiak wrote: On 11/16/2017 03:25 PM, Pierre Morel wrote: On 16/11/2017 18:03, Cornelia Huck wrote: On Thu, 16 Nov 2017 17:06:58 +0100 Pierre Morel wrote: On 16/11/2017 16:23, Tony Krowiak wrote: On 11/14/2017 08:57 AM, Cornelia Huck wrote: On Tue, 31 Oct 2017

Re: [PATCH] mailbox: txdone_method shouldn't always be reset

On Thu 16 Nov 22:47 PST 2017, Jassi Brar wrote: > On 16 Nov 2017 23:12, "Bjorn Andersson" wrote: > On Thu 16 Nov 09:06 PST 2017, Jassi Brar wrote: > > diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c > > index 674b35f..95e480e 100644 > > ---

Re: [PATCH] mailbox: txdone_method shouldn't always be reset

On Thu 16 Nov 22:47 PST 2017, Jassi Brar wrote: > On 16 Nov 2017 23:12, "Bjorn Andersson" wrote: > On Thu 16 Nov 09:06 PST 2017, Jassi Brar wrote: > > diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c > > index 674b35f..95e480e 100644 > > --- a/drivers/mailbox/mailbox.c > > +++

Re: [RFC v5 08/11] [media] vb2: add videobuf2 dma-buf fence helpers

On Thursday, November 16, 2017 2:10:54 AM JST, Gustavo Padovan wrote: From: Javier Martinez Canillas Add a videobuf2-fence.h header file that contains different helpers for DMA buffer sharing explicit fence support in videobuf2. v2: - use fence context provided by

Re: [RFC v5 08/11] [media] vb2: add videobuf2 dma-buf fence helpers

On Thursday, November 16, 2017 2:10:54 AM JST, Gustavo Padovan wrote: From: Javier Martinez Canillas Add a videobuf2-fence.h header file that contains different helpers for DMA buffer sharing explicit fence support in videobuf2. v2: - use fence context provided by the caller in

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

On Thu 16 Nov 22:36 PST 2017, kgu...@codeaurora.org wrote: > On 2017-11-16 22:25, Bjorn Andersson wrote: > > On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote: > > > > > WLED driver provides the interface to the display driver to > > > adjust the brightness of the display backlight. > > > > > >

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

On Thu 16 Nov 22:36 PST 2017, kgu...@codeaurora.org wrote: > On 2017-11-16 22:25, Bjorn Andersson wrote: > > On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote: > > > > > WLED driver provides the interface to the display driver to > > > adjust the brightness of the display backlight. > > > > > >

Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume

On Thu, Nov 16, 2017 at 09:27:51PM +0800, Chris Chiu wrote: > On Thu, Nov 16, 2017 at 8:44 PM, Mika Westerberg > wrote: > > On Wed, Nov 15, 2017 at 06:19:56PM +0800, Chris Chiu wrote: > >> Hi Mika, > >> I've confirmed with Asus and they said it's the latest

Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume

On Thu, Nov 16, 2017 at 09:27:51PM +0800, Chris Chiu wrote: > On Thu, Nov 16, 2017 at 8:44 PM, Mika Westerberg > wrote: > > On Wed, Nov 15, 2017 at 06:19:56PM +0800, Chris Chiu wrote: > >> Hi Mika, > >> I've confirmed with Asus and they said it's the latest BIOS for > >> shipment and verified

Re: [PATCH 02/13] x86/paravirt: Fix output constraint macro names

On 16/11/17 21:50, Josh Poimboeuf wrote: > On Wed, Oct 25, 2017 at 11:33:43AM +0200, Juergen Gross wrote: >> On 04/10/17 17:58, Josh Poimboeuf wrote: >>> Some of the paravirt '*_CLOBBERS' macros refer to output constraints >>> instead of clobbers, which makes the code extra confusing. Rename the

Re: [PATCH 02/13] x86/paravirt: Fix output constraint macro names

On 16/11/17 21:50, Josh Poimboeuf wrote: > On Wed, Oct 25, 2017 at 11:33:43AM +0200, Juergen Gross wrote: >> On 04/10/17 17:58, Josh Poimboeuf wrote: >>> Some of the paravirt '*_CLOBBERS' macros refer to output constraints >>> instead of clobbers, which makes the code extra confusing. Rename the

[PATCH] sched: use unsigned int for one-bit bitfield in sched_dl_entity

This patch is to fix the 'dubious one-bit signed bitfield' error reported by sparse, when using 'make C=2'. Fixes: 799ba82de01e ("sched/deadline: Use C bitfields for the state flags") Signed-off-by: Xin Long --- include/linux/sched.h | 8 1 file changed, 4

[PATCH] sched: use unsigned int for one-bit bitfield in sched_dl_entity

This patch is to fix the 'dubious one-bit signed bitfield' error reported by sparse, when using 'make C=2'. Fixes: 799ba82de01e ("sched/deadline: Use C bitfields for the state flags") Signed-off-by: Xin Long --- include/linux/sched.h | 8 1 file changed, 4 insertions(+), 4 deletions(-)

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

Hi Gustavo, I am coming a bit late in this series' review, so apologies if some of my comments have already have been discussed in an earlier revision. On Thursday, November 16, 2017 2:10:53 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan Receive in-fence

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

Hi Gustavo, I am coming a bit late in this series' review, so apologies if some of my comments have already have been discussed in an earlier revision. On Thursday, November 16, 2017 2:10:53 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan Receive in-fence from userspace and add support

Re: [PATCH] mm/shmem: set default tmpfs size according to memcg limit

2017-11-17 12:43 GMT+08:00 Shakeel Butt : > On Thu, Nov 16, 2017 at 7:09 PM, Yafang Shao wrote: >> Currently the default tmpfs size is totalram_pages / 2 if mount tmpfs >> without "-o size=XXX". >> When we mount tmpfs in a container(i.e. docker), it is

Re: [PATCH] mm/shmem: set default tmpfs size according to memcg limit

2017-11-17 12:43 GMT+08:00 Shakeel Butt : > On Thu, Nov 16, 2017 at 7:09 PM, Yafang Shao wrote: >> Currently the default tmpfs size is totalram_pages / 2 if mount tmpfs >> without "-o size=XXX". >> When we mount tmpfs in a container(i.e. docker), it is also >> totalram_pages / 2 regardless of the

Re: [PATCH] staging: comedi: ni_atmio: Handle return value of pnp_*

hi, On Thursday 16 November 2017 07:27 PM, Ian Abbott wrote: On 16/11/17 04:32, Arvind Yadav wrote: pnp_irq() and pnp_port_start() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/staging/comedi/drivers/ni_atmio.c | 3 +++

Re: [PATCH] staging: comedi: ni_atmio: Handle return value of pnp_*

hi, On Thursday 16 November 2017 07:27 PM, Ian Abbott wrote: On 16/11/17 04:32, Arvind Yadav wrote: pnp_irq() and pnp_port_start() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/staging/comedi/drivers/ni_atmio.c | 3 +++ 1 file changed, 3

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

On 2017-11-16 22:25, Bjorn Andersson wrote: On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote: WLED driver provides the interface to the display driver to adjust the brightness of the display backlight. Hi Kiran, This driver has a lot in common with the already upstream pm8941-wled.c,

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

On 2017-11-16 22:25, Bjorn Andersson wrote: On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote: WLED driver provides the interface to the display driver to adjust the brightness of the display backlight. Hi Kiran, This driver has a lot in common with the already upstream pm8941-wled.c,

Re: [PATCH v3 2/5] soc: qcom: Introduce QMI helpers

On Thu 16 Nov 04:11 PST 2017, Srinivas Kandagatla wrote: > On 15/11/17 20:10, Bjorn Andersson wrote: [..] > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig > > index 91b70b170a82..9718f1c41e3d 100644 > > --- a/drivers/soc/qcom/Kconfig > > +++ b/drivers/soc/qcom/Kconfig > > @@

Re: [PATCH v3 2/5] soc: qcom: Introduce QMI helpers

On Thu 16 Nov 04:11 PST 2017, Srinivas Kandagatla wrote: > On 15/11/17 20:10, Bjorn Andersson wrote: [..] > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig > > index 91b70b170a82..9718f1c41e3d 100644 > > --- a/drivers/soc/qcom/Kconfig > > +++ b/drivers/soc/qcom/Kconfig > > @@

Urgent Circuit Board Prototyping Service

Hi , I haven't heard from you for a long time. How are things with you? Do you have new projects that need PCB? I really hope that we can have chance to make boards for you and I am sure you won't be disappointed. You may have many suppliers but we are glad to send our quotation for your

Urgent Circuit Board Prototyping Service

Hi , I haven't heard from you for a long time. How are things with you? Do you have new projects that need PCB? I really hope that we can have chance to make boards for you and I am sure you won't be disappointed. You may have many suppliers but we are glad to send our quotation for your

Re: [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[...] >> > +++ linux-pm/include/linux/pm.h >> > @@ -559,6 +559,7 @@ struct pm_subsys_data { >> > * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device. >> > * SMART_PREPARE: Check the return value of the driver's ->prepare >> > callback. >> > * SMART_SUSPEND: No need to

Re: [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[...] >> > +++ linux-pm/include/linux/pm.h >> > @@ -559,6 +559,7 @@ struct pm_subsys_data { >> > * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device. >> > * SMART_PREPARE: Check the return value of the driver's ->prepare >> > callback. >> > * SMART_SUSPEND: No need to

Re: [PATCH v3 1/5] soc: qcom: Introduce QMI encoder/decoder

On Thu 16 Nov 04:10 PST 2017, Srinivas Kandagatla wrote: > On 15/11/17 20:10, Bjorn Andersson wrote: [..] > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig > > index b00bccddcd3b..91b70b170a82 100644 > > --- a/drivers/soc/qcom/Kconfig > > +++ b/drivers/soc/qcom/Kconfig > > @@

Re: [PATCH v3 1/5] soc: qcom: Introduce QMI encoder/decoder

On Thu 16 Nov 04:10 PST 2017, Srinivas Kandagatla wrote: > On 15/11/17 20:10, Bjorn Andersson wrote: [..] > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig > > index b00bccddcd3b..91b70b170a82 100644 > > --- a/drivers/soc/qcom/Kconfig > > +++ b/drivers/soc/qcom/Kconfig > > @@

Re: [PATCH] Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops

Hi Lukas, > John Stultz reports a boot time crash with the HiKey board (which uses > hci_serdev) occurring in hci_uart_tx_wakeup(). That function is > contained in hci_ldisc.c, but also called from the newer hci_serdev.c. > It acquires the proto_lock in struct hci_uart and it turns out that we >

Re: [PATCH] Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops

Hi Lukas, > John Stultz reports a boot time crash with the HiKey board (which uses > hci_serdev) occurring in hci_uart_tx_wakeup(). That function is > contained in hci_ldisc.c, but also called from the newer hci_serdev.c. > It acquires the proto_lock in struct hci_uart and it turns out that we >

Re: [PATCH v3 4/5] remoteproc: qcom: Introduce sysmon

On Thu 16 Nov 12:05 PST 2017, Chris Lew wrote: > > + req.event = SSCTL_SSR_EVENT_BEFORE_SHUTDOWN; > > Are there plans to add the other SSR events to sysmon notifiers? I think the > SSCTL service expects to receive events about remote procs starting as well. > We could easily add support here

Re: [PATCH v3 4/5] remoteproc: qcom: Introduce sysmon

On Thu 16 Nov 12:05 PST 2017, Chris Lew wrote: > > + req.event = SSCTL_SSR_EVENT_BEFORE_SHUTDOWN; > > Are there plans to add the other SSR events to sysmon notifiers? I think the > SSCTL service expects to receive events about remote procs starting as well. > We could easily add support here

RE: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A

> > No, not at all, if you want a patch in a specific stable tree, just email the > git > commit id to sta...@vger.kernel.org and let me know what > tree(s) it should be applied to. You can drop this patch. Thanks Greg > > thanks, > > greg k-h

RE: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A

> > No, not at all, if you want a patch in a specific stable tree, just email the > git > commit id to sta...@vger.kernel.org and let me know what > tree(s) it should be applied to. You can drop this patch. Thanks Greg > > thanks, > > greg k-h

Re: [RFC v5 03/11] [media] vb2: add 'ordered_in_driver' property to queues

On Thursday, November 16, 2017 2:10:49 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan We use ordered_in_driver property to optimize for the case where the driver can deliver the buffers in an ordered fashion. When it is ordered we can use the same fence

Re: [RFC v5 03/11] [media] vb2: add 'ordered_in_driver' property to queues

On Thursday, November 16, 2017 2:10:49 AM JST, Gustavo Padovan wrote: From: Gustavo Padovan We use ordered_in_driver property to optimize for the case where the driver can deliver the buffers in an ordered fashion. When it is ordered we can use the same fence context for all fences, but when

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

On 2017/11/17 11:30, Yunlong Song wrote: > How about add file_write_and_wait_range in __write_node_page as following: > if (atomic && !test_opt(sbi, NOBARRIER)) { > file_write_and_wait_range(file, 0, LLONG_MAX); Nope, GCed encrypted data wouldn't be cached in inode page cache. I don't think

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

On 2017/11/17 11:30, Yunlong Song wrote: > How about add file_write_and_wait_range in __write_node_page as following: > if (atomic && !test_opt(sbi, NOBARRIER)) { > file_write_and_wait_range(file, 0, LLONG_MAX); Nope, GCed encrypted data wouldn't be cached in inode page cache. I don't think

Re: [PATCH 10/13] x86/alternative: Support indirect call replacement

On 16/11/17 22:19, Josh Poimboeuf wrote: > On Wed, Oct 25, 2017 at 01:25:02PM +0200, Juergen Gross wrote: >> On 04/10/17 17:58, Josh Poimboeuf wrote: >>> Add alternative patching support for replacing an instruction with an >>> indirect call. This will be needed for the paravirt alternatives. >>>

Re: [PATCH 10/13] x86/alternative: Support indirect call replacement

On 16/11/17 22:19, Josh Poimboeuf wrote: > On Wed, Oct 25, 2017 at 01:25:02PM +0200, Juergen Gross wrote: >> On 04/10/17 17:58, Josh Poimboeuf wrote: >>> Add alternative patching support for replacing an instruction with an >>> indirect call. This will be needed for the paravirt alternatives. >>>

[PATCH 1/4] ARM: dts: uniphier: use macros in dt-bindings header

The dt-bindings header was applied to the driver subsystem. I had to wait for a merge window to use it from DT. Signed-off-by: Masahiro Yamada --- arch/arm/boot/dts/uniphier-ld4-ref.dts | 2 +- arch/arm/boot/dts/uniphier-ld4.dtsi | 2 ++

[PATCH 1/4] ARM: dts: uniphier: use macros in dt-bindings header

The dt-bindings header was applied to the driver subsystem. I had to wait for a merge window to use it from DT. Signed-off-by: Masahiro Yamada --- arch/arm/boot/dts/uniphier-ld4-ref.dts | 2 +- arch/arm/boot/dts/uniphier-ld4.dtsi | 2 ++ arch/arm/boot/dts/uniphier-ld6b-ref.dts | 2 +-

Re: [git pull] drm amdgpu-dc merge

gmail for some reason ate my email formatting, apparantly preediting in gedit, then pasting in here doesn't work so well. Dave. On 17 November 2017 at 14:05, Dave Airlie wrote: > Hi Linus, > > This is the pull request for the AMD DC (display code) layer which is > a

Re: [git pull] drm amdgpu-dc merge

gmail for some reason ate my email formatting, apparantly preediting in gedit, then pasting in here doesn't work so well. Dave. On 17 November 2017 at 14:05, Dave Airlie wrote: > Hi Linus, > > This is the pull request for the AMD DC (display code) layer which is > a requirement > to program the

Re: [PATCH] drivers: base: cacheinfo: support DT overrides for cache type

On 2017/11/17 10:13, Tan Xiaojun wrote: > On 2017/11/16 23:23, Sudeep Holla wrote: >> >> >> On 16/11/17 12:58, Tan Xiaojun wrote: >>> Since commit dfea747d2aba ("drivers: base: cacheinfo: support DT >>> overrides for cache properties"), we can set the correct cacheinfo >>> via DT. But the cache

Re: [PATCH] drivers: base: cacheinfo: support DT overrides for cache type

On 2017/11/17 10:13, Tan Xiaojun wrote: > On 2017/11/16 23:23, Sudeep Holla wrote: >> >> >> On 16/11/17 12:58, Tan Xiaojun wrote: >>> Since commit dfea747d2aba ("drivers: base: cacheinfo: support DT >>> overrides for cache properties"), we can set the correct cacheinfo >>> via DT. But the cache

[PATCH 2/4] arm64: dts: uniphier: remove unnecessary interrupt-parent

These were added to make the ARM64 branch self-contained because updates for ARM and ARM64 are supposed to be sent as separate pull requests. Now, they were merged together in Linus' tree and interrupt-parent from the arch/arm/boot/dts/uniphier-support-card.dtsi is visible from ARM64 DT files by

[PATCH 2/4] arm64: dts: uniphier: remove unnecessary interrupt-parent

These were added to make the ARM64 branch self-contained because updates for ARM and ARM64 are supposed to be sent as separate pull requests. Now, they were merged together in Linus' tree and interrupt-parent from the arch/arm/boot/dts/uniphier-support-card.dtsi is visible from ARM64 DT files by

[PATCH 3/4] arm64: dts: uniphier: use macros in dt-bindings header

The dt-bindings header was applied to the driver subsystem. I had to wait for a merge window to use it from DT. Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 2 +- arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi| 3

[PATCH 4/4] arm64: dts: uniphier: add GPIO hog definition for PXs3

Commit 15e85695e500 ("arm64: dts: uniphier: add GPIO hog definition") missed to update the PXs3 DTS for some reason. Do it now. Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts | 8 1 file changed, 8 insertions(+)

[PATCH 3/4] arm64: dts: uniphier: use macros in dt-bindings header

The dt-bindings header was applied to the driver subsystem. I had to wait for a merge window to use it from DT. Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 2 +- arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi| 3 ++-

[PATCH 4/4] arm64: dts: uniphier: add GPIO hog definition for PXs3

Commit 15e85695e500 ("arm64: dts: uniphier: add GPIO hog definition") missed to update the PXs3 DTS for some reason. Do it now. Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts | 8 1 file changed, 8 insertions(+) diff --git

Re: [PATCH] virto_net: remove empty file 'virtio_net.'

From: Jason Wang Date: Fri, 17 Nov 2017 10:55:44 +0800 > > > On 2017年11月17日 10:46, Joel Stanley wrote: >> Looks like this was mistakenly added to the tree as part of >> commit 186b3c998c50 ("virtio-net: support XDP_REDIRECT"). >> >> Signed-off-by: Joel Stanley

Re: [PATCH] virto_net: remove empty file 'virtio_net.'

From: Jason Wang Date: Fri, 17 Nov 2017 10:55:44 +0800 > > > On 2017年11月17日 10:46, Joel Stanley wrote: >> Looks like this was mistakenly added to the tree as part of >> commit 186b3c998c50 ("virtio-net: support XDP_REDIRECT"). >> >> Signed-off-by: Joel Stanley >> --- >>

Re: [lkp-robot] [fw_cfg] 05b5d5161b: WARNING:at_drivers/firmware/qemu_fw_cfg.c:#fw_cfg_dma_transfer

On 11/16, Michael S. Tsirkin wrote: >On Thu, Nov 16, 2017 at 08:58:13AM +0800, kernel test robot wrote: >> >> FYI, we noticed the following commit (built with gcc-6): >> >> commit: 05b5d5161b9e6c72e1d06f36614edbdbfe192cc7 ("fw_cfg: do DMA read >> operation") >>

Re: [lkp-robot] [fw_cfg] 05b5d5161b: WARNING:at_drivers/firmware/qemu_fw_cfg.c:#fw_cfg_dma_transfer

On 11/16, Michael S. Tsirkin wrote: >On Thu, Nov 16, 2017 at 08:58:13AM +0800, kernel test robot wrote: >> >> FYI, we noticed the following commit (built with gcc-6): >> >> commit: 05b5d5161b9e6c72e1d06f36614edbdbfe192cc7 ("fw_cfg: do DMA read >> operation") >>

Re: [PATCH] rdma: Add Jason as a co-maintainer

On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > As was discussed in September and October, add Jason along with > Doug to have a team maintainership model for the RDMA subystem. > > Mellanox Technologies will be funding Jason's independent work on > the maintainership. > >

Re: [PATCH] rdma: Add Jason as a co-maintainer

On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > As was discussed in September and October, add Jason along with > Doug to have a team maintainership model for the RDMA subystem. > > Mellanox Technologies will be funding Jason's independent work on > the maintainership. > >

wlcore: wl18xx: Trouble suspending caused by wifi being enabled?

Hey Folks, So, for awhile recently, I've noticed my HiKey board (which uses the TI WL1835MOD chip for wifi) has had trouble when it tries to suspend. Basically it keeps on waking up while suspending, and then re-suspending over and over until it lucks out in whatever race is going on and manages

wlcore: wl18xx: Trouble suspending caused by wifi being enabled?

Hey Folks, So, for awhile recently, I've noticed my HiKey board (which uses the TI WL1835MOD chip for wifi) has had trouble when it tries to suspend. Basically it keeps on waking up while suspending, and then re-suspending over and over until it lucks out in whatever race is going on and manages

Towards 4.14 LTS

At Linaro we’ve been putting effort into regularly running kernel tests over arm, arm64 and x86_64 targets. On those targets we’re running mainline, -next, 4.4, and 4.9 kernels and yes we are adding to this list as the hardware capacity grows. For test buckets we’re using just LTP, kselftest

Towards 4.14 LTS

At Linaro we’ve been putting effort into regularly running kernel tests over arm, arm64 and x86_64 targets. On those targets we’re running mainline, -next, 4.4, and 4.9 kernels and yes we are adding to this list as the hardware capacity grows. For test buckets we’re using just LTP, kselftest

  1   2   3   4   5   6   7   8   9   10   >