[PATCH v2 20/27] media: dst_ca: return a proper error code from CA errors

Right now, on several places, the driver is returning a "-1" error to userspace, instead of a proper error code. Fix it. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/pci/bt8xx/dst_ca.c | 41 +--- 1 file changed, 22

[PATCH v2 20/27] media: dst_ca: return a proper error code from CA errors

Right now, on several places, the driver is returning a "-1" error to userspace, instead of a proper error code. Fix it. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/pci/bt8xx/dst_ca.c | 41 +--- 1 file changed, 22 insertions(+), 19 deletions(-)

Re: ide: pmac: Convert to using %pOF instead of full_name

On Tue, 2017-07-18 at 21:43:07 UTC, Rob Herring wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring > Cc:

Re: [1/4] axonram: Delete an error message for a failed memory allocation in axon_ram_probe()

On Thu, 2017-08-03 at 19:12:50 UTC, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 3 Aug 2017 19:49:18 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. >

Re: ide: pmac: Convert to using %pOF instead of full_name

On Tue, 2017-07-18 at 21:43:07 UTC, Rob Herring wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring > Cc: "David S. Miller" >

Re: [1/4] axonram: Delete an error message for a failed memory allocation in axon_ram_probe()

On Thu, 2017-08-03 at 19:12:50 UTC, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 3 Aug 2017 19:49:18 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Link: >

[PATCH v2 09/27] media: dvb frontend docs: use kernel-doc documentation

Now that frontend.h contains most documentation for the frontend, remove the duplicated information from Documentation/ and use the kernel-doc auto-generated one instead. That should simplify maintainership of DVB frontend uAPI, as most of the documentation will stick with the header file.

[PATCH v2 09/27] media: dvb frontend docs: use kernel-doc documentation

Now that frontend.h contains most documentation for the frontend, remove the duplicated information from Documentation/ and use the kernel-doc auto-generated one instead. That should simplify maintainership of DVB frontend uAPI, as most of the documentation will stick with the header file.

[PATCH v2 04/27] media: dvb/intro: update references for TV standards

The references there are only for DVB. Add missing references for ATSC and ISDB standards. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/intro.rst | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git

[PATCH v2 04/27] media: dvb/intro: update references for TV standards

The references there are only for DVB. Add missing references for ATSC and ISDB standards. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/intro.rst | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/media/uapi/dvb/intro.rst

Re: powerpc: 4xx: constify platform_suspend_ops

On Wed, 2017-08-30 at 16:48:20 UTC, Arvind Yadav wrote: > platform_suspend_ops are not supposed to change at runtime. > Functions suspend_set_ops working with const platform_suspend_ops. > So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav Applied

Re: powerpc: 4xx: constify platform_suspend_ops

On Wed, 2017-08-30 at 16:48:20 UTC, Arvind Yadav wrote: > platform_suspend_ops are not supposed to change at runtime. > Functions suspend_set_ops working with const platform_suspend_ops. > So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav Applied to powerpc next, thanks.

Re: [1/4] powerpc/32: add memset16()

On Wed, 2017-08-23 at 14:54:32 UTC, Christophe Leroy wrote: > Commit 694fc88ce271f ("powerpc/string: Implement optimized > memset variants") added memset16(), memset32() and memset64() > for the 64 bits PPC. > > On 32 bits, memset64() is not relevant, and as shown below, > the generic version of

[PATCH v2 25/27] media: dvb CA docs: place undocumented data together with ioctls

Right now, the same undocumented structs are on two places: at ca_data_types.rst and together with their ioctls. Move them to just one place and use the standard way to represent them. Signed-off-by: Mauro Carvalho Chehab ---

Re: [1/4] powerpc/32: add memset16()

On Wed, 2017-08-23 at 14:54:32 UTC, Christophe Leroy wrote: > Commit 694fc88ce271f ("powerpc/string: Implement optimized > memset variants") added memset16(), memset32() and memset64() > for the 64 bits PPC. > > On 32 bits, memset64() is not relevant, and as shown below, > the generic version of

[PATCH v2 25/27] media: dvb CA docs: place undocumented data together with ioctls

Right now, the same undocumented structs are on two places: at ca_data_types.rst and together with their ioctls. Move them to just one place and use the standard way to represent them. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/ca-get-msg.rst| 38

RE: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

> On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote: > > Actually on the second thought: does the above memory ordering differences > > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way > > how it is currently implemented for x86 is the same way as it is for

RE: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

> On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote: > > Actually on the second thought: does the above memory ordering differences > > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way > > how it is currently implemented for x86 is the same way as it is for

[PATCH v2 13/27] media: dmx.h: get rid of DMX_GET_CAPS

There's no driver currently using it; it is also not documented about what it would be supposed to do. So, get rid of it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/dmx.h.rst.exceptions | 1 - Documentation/media/uapi/dvb/dmx-get-caps.rst | 41

[PATCH v2 13/27] media: dmx.h: get rid of DMX_GET_CAPS

There's no driver currently using it; it is also not documented about what it would be supposed to do. So, get rid of it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/dmx.h.rst.exceptions | 1 - Documentation/media/uapi/dvb/dmx-get-caps.rst | 41

[PATCH v2 19/27] media: ca.h: document most CA data types

For most of the stuff there, documenting is easy, as the header file contains information. Yet, I was unable to document two data structs: ca_msg and ca_descr As those two structs are used by a few drivers, keep them. Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 19/27] media: ca.h: document most CA data types

For most of the stuff there, documenting is easy, as the header file contains information. Yet, I was unable to document two data structs: ca_msg and ca_descr As those two structs are used by a few drivers, keep them. Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 00/26] Improve DVB documentation and reduce its gap

The DVB documentation was negligected for a long time, with resulted on several gaps between the API description and its documentation. I'm doing a new reading at the documentation. As result of it, this series: - improves the introductory chapter, making it more generic; - Do some adjustments

[PATCH v2 00/26] Improve DVB documentation and reduce its gap

The DVB documentation was negligected for a long time, with resulted on several gaps between the API description and its documentation. I'm doing a new reading at the documentation. As result of it, this series: - improves the introductory chapter, making it more generic; - Do some adjustments

[PATCH v2 24/27] media: ca-get-descr-info.rst: document this ioctl

Instead of a generic boilerplate, fill it with relevant information about this ioctl. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/ca-get-descr-info.rst | 29 +++--- 1 file changed, 4 insertions(+), 25 deletions(-) diff --git

[PATCH v2 24/27] media: ca-get-descr-info.rst: document this ioctl

Instead of a generic boilerplate, fill it with relevant information about this ioctl. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/ca-get-descr-info.rst | 29 +++--- 1 file changed, 4 insertions(+), 25 deletions(-) diff --git

[PATCH v2 02/27] media: dmx.h: split typedefs from structs

Using typedefs inside the Kernel is against CodingStyle, and there's no good usage here. Just like we did at frontend.h, at changeset 0df289a209e0 ("[media] dvb: Get rid of typedev usage for enums"), let's keep those typedefs only to provide userspace backward compatibility. No functional

[PATCH v2 02/27] media: dmx.h: split typedefs from structs

Using typedefs inside the Kernel is against CodingStyle, and there's no good usage here. Just like we did at frontend.h, at changeset 0df289a209e0 ("[media] dvb: Get rid of typedev usage for enums"), let's keep those typedefs only to provide userspace backward compatibility. No functional

[PATCH v2 26/27] media: dvb rst: identify the documentation gap at the API

Now that DVB spec is almost in sync, document what's missing. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/ca.rst | 5 + Documentation/media/uapi/dvb/legacy_dvb_apis.rst | 5 + 2 files changed, 10 insertions(+) diff --git

[PATCH v2 26/27] media: dvb rst: identify the documentation gap at the API

Now that DVB spec is almost in sync, document what's missing. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/ca.rst | 5 + Documentation/media/uapi/dvb/legacy_dvb_apis.rst | 5 + 2 files changed, 10 insertions(+) diff --git

[PATCH v2 05/27] media: dvb/intro: update the history part of the document

Convergence doesn't exist anymore. The community itself maintains the spec. Update accordingly. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/intro.rst | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git

[PATCH v2 05/27] media: dvb/intro: update the history part of the document

Convergence doesn't exist anymore. The community itself maintains the spec. Update accordingly. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/intro.rst | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git

[PATCH v2 08/27] media: dvb/frontend.h: document the uAPI file

Most of the stuff at the Digital TV frontend header file are documented only at the Documentation. However, a few kernel-doc markups are there, several of them with parsing issues. Add the missing documentation, copying definitions from the Documentation when it applies, fixing some bugs. Please

[PATCH v2 08/27] media: dvb/frontend.h: document the uAPI file

Most of the stuff at the Digital TV frontend header file are documented only at the Documentation. However, a few kernel-doc markups are there, several of them with parsing issues. Add the missing documentation, copying definitions from the Documentation when it applies, fixing some bugs. Please

[PATCH v2 01/27] media: ca.h: split typedefs from structs

Using typedefs inside the Kernel is against CodingStyle, and there's no good usage here. Just like we did at frontend.h, at changeset 0df289a209e0 ("[media] dvb: Get rid of typedev usage for enums"), let's keep those typedefs only to provide userspace backward compatibility. No functional

[PATCH v2 01/27] media: ca.h: split typedefs from structs

Using typedefs inside the Kernel is against CodingStyle, and there's no good usage here. Just like we did at frontend.h, at changeset 0df289a209e0 ("[media] dvb: Get rid of typedev usage for enums"), let's keep those typedefs only to provide userspace backward compatibility. No functional

[PATCH v2 21/27] media: ca-reset.rst: add some description to this ioctl

While we don't have any documentation for it, based on what's there at Kaffeine and VDR, it seems that this command should be issued before start using CA. So, document it as such. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/ca-reset.rst | 3

[PATCH v2 21/27] media: ca-reset.rst: add some description to this ioctl

While we don't have any documentation for it, based on what's there at Kaffeine and VDR, it seems that this command should be issued before start using CA. So, document it as such. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/ca-reset.rst | 3 ++- 1 file changed, 2

Re: printk: what is going on with additional newlines?

On (08/29/17 21:10), Steven Rostedt wrote: [..] > > could do. for a single continuation line printk("%.*s", s.len, s.buffer) > > this will work perfectly fine. for a more general case - backtraces, dumps, > > etc. - this requires some tweaks. > > We could simply add a seq_buf_printk() that is

Re: printk: what is going on with additional newlines?

On (08/29/17 21:10), Steven Rostedt wrote: [..] > > could do. for a single continuation line printk("%.*s", s.len, s.buffer) > > this will work perfectly fine. for a more general case - backtraces, dumps, > > etc. - this requires some tweaks. > > We could simply add a seq_buf_printk() that is

Re: linux-next: manual merge of the pm tree with the dmi tree

Hi Stephen, On jeu., 2017-08-31 at 11:07 +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the pm tree got a conflict in: > > drivers/acpi/blacklist.c > > between commit: > > f996c4155d0d ("dmi: Mark all struct dmi_system_id instances const") > > from the dmi tree

Re: linux-next: manual merge of the pm tree with the dmi tree

Hi Stephen, On jeu., 2017-08-31 at 11:07 +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the pm tree got a conflict in: > > drivers/acpi/blacklist.c > > between commit: > > f996c4155d0d ("dmi: Mark all struct dmi_system_id instances const") > > from the dmi tree

Re: Applied "regulator: pbias: Select voltage table based on max-voltage" to the regulator tree

On 31 August 2017 at 15:50, Mark Brown wrote: > On Thu, Aug 31, 2017 at 05:37:34PM +0530, Kishon Vijay Abraham I wrote: > >> This patch should be merged along with the 1st patch of the series "mmc: >> host: >> omap_hsmmc: Remove setting PBIAS voltage". Or else it'll break MMC

Re: Applied "regulator: pbias: Select voltage table based on max-voltage" to the regulator tree

On 31 August 2017 at 15:50, Mark Brown wrote: > On Thu, Aug 31, 2017 at 05:37:34PM +0530, Kishon Vijay Abraham I wrote: > >> This patch should be merged along with the 1st patch of the series "mmc: >> host: >> omap_hsmmc: Remove setting PBIAS voltage". Or else it'll break MMC with >> omap_hsmmc

Re: [PATCH v3 1/3] drm/bridge/synopsys: dsi: Constify funcs structures

On 01.08.2017 15:23, Philippe CORNU wrote: > Constify dw_mipi_dsi_bridge_funcs as these functions are not supposed > to change at runtime. > > Signed-off-by: Philippe CORNU > Reviewed-by: Laurent Pinchart > --- >

Re: [PATCH v3 1/3] drm/bridge/synopsys: dsi: Constify funcs structures

On 01.08.2017 15:23, Philippe CORNU wrote: > Constify dw_mipi_dsi_bridge_funcs as these functions are not supposed > to change at runtime. > > Signed-off-by: Philippe CORNU > Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > 1 file changed, 1

Re: [PATCH 1/2] mm,page_alloc: don't call __node_reclaim() without scoped allocation constraints.

Michal Hocko wrote: > On Fri 01-09-17 21:40:07, Tetsuo Handa wrote: > > We are doing the first allocation attempt before calling > > current_gfp_context(). But since slab shrinker functions might depend on > > __GFP_FS and/or __GFP_IO masking, calling slab shrinker functions from > >

Re: [PATCH 1/2] mm,page_alloc: don't call __node_reclaim() without scoped allocation constraints.

Michal Hocko wrote: > On Fri 01-09-17 21:40:07, Tetsuo Handa wrote: > > We are doing the first allocation attempt before calling > > current_gfp_context(). But since slab shrinker functions might depend on > > __GFP_FS and/or __GFP_IO masking, calling slab shrinker functions from > >

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

On Fri, 2017-09-01 at 08:57 +0200, Mike Galbraith wrote: > On Thu, 2017-08-31 at 11:45 -0700, Kees Cook wrote: > > On Thu, Aug 31, 2017 at 10:19 AM, Mike Galbraith wrote: > > > On Thu, 2017-08-31 at 10:00 -0700, Kees Cook wrote: > > >> > > >> Oh! So it's gcc-version sensitive?

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

On Fri, 2017-09-01 at 08:57 +0200, Mike Galbraith wrote: > On Thu, 2017-08-31 at 11:45 -0700, Kees Cook wrote: > > On Thu, Aug 31, 2017 at 10:19 AM, Mike Galbraith wrote: > > > On Thu, 2017-08-31 at 10:00 -0700, Kees Cook wrote: > > >> > > >> Oh! So it's gcc-version sensitive? That's alarming. Is

Re: [PATCH v2 1/2] ARM: dts: sun7i: Fix A20-OLinuXino-MICRO dts for LAN8710

On Mon, Aug 28, 2017 at 09:32:42AM +0300, Stefan Mavrodiev wrote: > From revision J the board uses new phy chip LAN8710. Compared > with RTL8201, RA17 pin is TXERR. It has pullup which causes phy > not to work. To fix this PA17 is muxed with GMAC function. This > makes the pin output-low. > >

Re: [PATCH v2 1/2] ARM: dts: sun7i: Fix A20-OLinuXino-MICRO dts for LAN8710

On Mon, Aug 28, 2017 at 09:32:42AM +0300, Stefan Mavrodiev wrote: > From revision J the board uses new phy chip LAN8710. Compared > with RTL8201, RA17 pin is TXERR. It has pullup which causes phy > not to work. To fix this PA17 is muxed with GMAC function. This > makes the pin output-low. > >

[PATCH v4 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

This patch adds the MFD driver for Dollar Cove (TI version) PMIC with ACPI INT33F5 that is found on some Intel Cherry Trail devices. The driver is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts This is a minimal version for adding the basic

[PATCH v4 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

This patch adds the MFD driver for Dollar Cove (TI version) PMIC with ACPI INT33F5 that is found on some Intel Cherry Trail devices. The driver is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts This is a minimal version for adding the basic

[PATCH v4 2/3] platform/x86: Add support for Dollar Cove TI power button

This provides a new input driver for supporting the power button on Dollar Cove TI PMIC, found on Cherrytrail-based devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891

[PATCH v4 2/3] platform/x86: Add support for Dollar Cove TI power button

This provides a new input driver for supporting the power button on Dollar Cove TI PMIC, found on Cherrytrail-based devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891

[PATCH v4 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

Hi, this is the revised v4 patch set to add the support for Dollar Cove TI PMIC found on some Intel Cherry Trail laptops / tablets. All drivers are based on the original code from Intel downstream patches, with lots of rewrites and cleanups. MFD driver is implemented as a stand-alone driver

[PATCH v4 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

Hi, this is the revised v4 patch set to add the support for Dollar Cove TI PMIC found on some Intel Cherry Trail laptops / tablets. All drivers are based on the original code from Intel downstream patches, with lots of rewrites and cleanups. MFD driver is implemented as a stand-alone driver

Re: [PATCH v2 1/2] ARM: dts: sun7i: Fix A20-OLinuXino-MICRO dts for LAN8710

On Thu, Aug 31, 2017 at 08:20:18AM +0300, Stefan Mavrodiev wrote: > > > From revision J the board uses new phy chip LAN8710. Compared > > > with RTL8201, RA17 pin is TXERR. It has pullup which causes phy > > > not to work. To fix this PA17 is muxed with GMAC function. This > > > makes the pin

Re: [PATCH v2 1/2] ARM: dts: sun7i: Fix A20-OLinuXino-MICRO dts for LAN8710

On Thu, Aug 31, 2017 at 08:20:18AM +0300, Stefan Mavrodiev wrote: > > > From revision J the board uses new phy chip LAN8710. Compared > > > with RTL8201, RA17 pin is TXERR. It has pullup which causes phy > > > not to work. To fix this PA17 is muxed with GMAC function. This > > > makes the pin

[PATCH v4 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

This patch adds the opregion driver for Dollar Cove TI PMIC on Intel Cherry Trail devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts with many cleanups and rewrites. The driver is currently provided only as built-in to

[PATCH v4 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

This patch adds the opregion driver for Dollar Cove TI PMIC on Intel Cherry Trail devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts with many cleanups and rewrites. The driver is currently provided only as built-in to

Re: [PATCH 12/15] media: dmx.h: get rid of DMX_SET_SOURCE

Em Fri, 1 Sep 2017 13:14:04 +0200 Honza Petrouš escreveu: > 2017-09-01 12:45 GMT+02:00 Mauro Carvalho Chehab : > > Em Fri, 1 Sep 2017 11:53:11 +0200 > > Honza Petrouš escreveu: > > > >> 2017-09-01 11:37 GMT+02:00 Mauro Carvalho

Re: [PATCH 12/15] media: dmx.h: get rid of DMX_SET_SOURCE

Em Fri, 1 Sep 2017 13:14:04 +0200 Honza Petrouš escreveu: > 2017-09-01 12:45 GMT+02:00 Mauro Carvalho Chehab : > > Em Fri, 1 Sep 2017 11:53:11 +0200 > > Honza Petrouš escreveu: > > > >> 2017-09-01 11:37 GMT+02:00 Mauro Carvalho Chehab > >> : > >> > Em Fri, 1 Sep 2017 08:28:20 +0200 > >> >

RE: [PATCH V8] perf: Add PERF_SAMPLE_PHYS_ADDR

> On Thursday 31 August 2017 10:13 PM, Arnaldo Carvalho de Melo wrote: > Em Tue, Aug 29, 2017 at 01:45:53PM +0200, Peter Zijlstra escreveu: > On Tue, Aug 29, 2017 at 05:05:15PM +0530, Madhavan Srinivasan wrote: > > > On Tuesday 29 August 2017 06:22 AM, kan.li...@intel.com wrote: > From: Kan

RE: [PATCH V8] perf: Add PERF_SAMPLE_PHYS_ADDR

> On Thursday 31 August 2017 10:13 PM, Arnaldo Carvalho de Melo wrote: > Em Tue, Aug 29, 2017 at 01:45:53PM +0200, Peter Zijlstra escreveu: > On Tue, Aug 29, 2017 at 05:05:15PM +0530, Madhavan Srinivasan wrote: > > > On Tuesday 29 August 2017 06:22 AM, kan.li...@intel.com wrote: > From: Kan

Re: [PATCH 2/7] dt-bindings: PM / OPP: add clocks per OPP node support

On Thu, Aug 31, 2017 at 12:39:20PM -0500, Rob Herring wrote: > On Thu, Aug 24, 2017 at 12:10:05AM +0800, Dong Aisheng wrote: > > It's used for platforms where different OPPs may use different clocks. > > With this extended binding, user could specify the correct clock for each > > OPP node. > > >

Re: [PATCH 2/7] dt-bindings: PM / OPP: add clocks per OPP node support

On Thu, Aug 31, 2017 at 12:39:20PM -0500, Rob Herring wrote: > On Thu, Aug 24, 2017 at 12:10:05AM +0800, Dong Aisheng wrote: > > It's used for platforms where different OPPs may use different clocks. > > With this extended binding, user could specify the correct clock for each > > OPP node. > > >

Re: [PATCH 4/7] ARM: dts: sun8i: h3: Enable AP6212 WiFi on mmc1 on Nanopi M1 Plus

On Wed, Aug 30, 2017 at 11:51:37PM +0200, Philipp Rossak wrote: > Hi, > thanks for the feedback I will rework the patch. > Should I also update the sun8i-h3-bananapi-m2-plus.dts? It uses also the > AP6212 and it is done in the same way like in this patch. Yes, please. Maxime -- Maxime Ripard,

Re: [PATCH 4/7] ARM: dts: sun8i: h3: Enable AP6212 WiFi on mmc1 on Nanopi M1 Plus

On Wed, Aug 30, 2017 at 11:51:37PM +0200, Philipp Rossak wrote: > Hi, > thanks for the feedback I will rework the patch. > Should I also update the sun8i-h3-bananapi-m2-plus.dts? It uses also the > AP6212 and it is done in the same way like in this patch. Yes, please. Maxime -- Maxime Ripard,

Re: [PATCH 7/7] ARM: dts: sun8i: h3: Enable AP6212 BT on uart3 on Nanopi M1 Plus

On Wed, Aug 30, 2017 at 05:01:10AM +0200, Philipp Rossak wrote: > From: Philipp Rossak > > The BT side of the AP6212 WiFi/BT combo module is connected to > uart3. > > Enable BT on this board by enabling uart3 with using additionally > the cts and rts pins. > > Signed-off-by:

Re: [PATCH 7/7] ARM: dts: sun8i: h3: Enable AP6212 BT on uart3 on Nanopi M1 Plus

On Wed, Aug 30, 2017 at 05:01:10AM +0200, Philipp Rossak wrote: > From: Philipp Rossak > > The BT side of the AP6212 WiFi/BT combo module is connected to > uart3. > > Enable BT on this board by enabling uart3 with using additionally > the cts and rts pins. > > Signed-off-by: Philipp Rossak

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

On Thu, Aug 31, 2017 at 03:22:05PM +1000, Michael Neuling wrote: > On Thu, 2017-08-31 at 06:36 +0200, Greg Kroah-Hartman wrote: > > On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote: > > > Hello everyone, > > > > > > Recently Nathan March reported on centos-virt list he's getting

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

On Thu, Aug 31, 2017 at 03:22:05PM +1000, Michael Neuling wrote: > On Thu, 2017-08-31 at 06:36 +0200, Greg Kroah-Hartman wrote: > > On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote: > > > Hello everyone, > > > > > > Recently Nathan March reported on centos-virt list he's getting

Re: [PATCH 6/7] ARM: dts: sun8i: h3: Adding UART3 RTS and CTS Pins

On Wed, Aug 30, 2017 at 05:01:09AM +0200, Philipp Rossak wrote: > From: Philipp Rossak > > This node adds the definition for the UART3 RTS and CTS Pins > > That makes it able to use UART3 with RTS and CTS. > > Signed-off-by: Philipp Rossak Queued for

Re: [PATCH 6/7] ARM: dts: sun8i: h3: Adding UART3 RTS and CTS Pins

On Wed, Aug 30, 2017 at 05:01:09AM +0200, Philipp Rossak wrote: > From: Philipp Rossak > > This node adds the definition for the UART3 RTS and CTS Pins > > That makes it able to use UART3 with RTS and CTS. > > Signed-off-by: Philipp Rossak Queued for 4.15, thanks Maxime -- Maxime Ripard,

Re: [PATCH v3 4/4] soc: ti: Add pm33xx driver for basic suspend support

On Tue, Jul 25, 2017 at 09:44:14AM -0500, Dave Gerlach wrote: > AM335x and AM437x support various low power modes as documented > in section 8.1.4.3 of the AM335x Technical Reference Manual and > section 6.4.3 of the AM437x Technical Reference Manual. > v2->v3: > * Rename

Re: [PATCH v3 4/4] soc: ti: Add pm33xx driver for basic suspend support

On Tue, Jul 25, 2017 at 09:44:14AM -0500, Dave Gerlach wrote: > AM335x and AM437x support various low power modes as documented > in section 8.1.4.3 of the AM335x Technical Reference Manual and > section 6.4.3 of the AM437x Technical Reference Manual. > v2->v3: > * Rename

Re: [PATCH 1/2] mm,page_alloc: don't call __node_reclaim() without scoped allocation constraints.

On Fri 01-09-17 21:40:07, Tetsuo Handa wrote: > We are doing the first allocation attempt before calling > current_gfp_context(). But since slab shrinker functions might depend on > __GFP_FS and/or __GFP_IO masking, calling slab shrinker functions from > node_reclaim() from

Re: [PATCH 1/2] mm,page_alloc: don't call __node_reclaim() without scoped allocation constraints.

On Fri 01-09-17 21:40:07, Tetsuo Handa wrote: > We are doing the first allocation attempt before calling > current_gfp_context(). But since slab shrinker functions might depend on > __GFP_FS and/or __GFP_IO masking, calling slab shrinker functions from > node_reclaim() from

Re: [RFC][PATCH] perf: Rewrite enabled/running timekeeping

On Fri, Sep 01, 2017 at 02:17:17PM +0300, Alexey Budankov wrote: > > No more weird and wonderful mind bending interaction between 3 different > > timestamps with arcane update rules. > > > > --- > > include/linux/perf_event.h | 25 +- > > kernel/events/core.c | 551 > >

Re: [RFC][PATCH] perf: Rewrite enabled/running timekeeping

On Fri, Sep 01, 2017 at 02:17:17PM +0300, Alexey Budankov wrote: > > No more weird and wonderful mind bending interaction between 3 different > > timestamps with arcane update rules. > > > > --- > > include/linux/perf_event.h | 25 +- > > kernel/events/core.c | 551 > >

Re: [PATCH v3 0/3] drm/bridge/synopsys: dsi: Various cleanups

Hi Archit, Gentle reminder :-) Do not hesitate to send me any comments so I can update these patches. Note that the "Constify funcs structures" patch is now obsolete as a similar ones from Bhumika Goyal has been posted then integrated recently. Many thanks for your support, Philippe :-) On

Re: [PATCH v3 0/3] drm/bridge/synopsys: dsi: Various cleanups

Hi Archit, Gentle reminder :-) Do not hesitate to send me any comments so I can update these patches. Note that the "Constify funcs structures" patch is now obsolete as a similar ones from Bhumika Goyal has been posted then integrated recently. Many thanks for your support, Philippe :-) On

[PATCH 1/2] mm,page_alloc: don't call __node_reclaim() without scoped allocation constraints.

We are doing the first allocation attempt before calling current_gfp_context(). But since slab shrinker functions might depend on __GFP_FS and/or __GFP_IO masking, calling slab shrinker functions from node_reclaim() from get_page_from_freelist() without calling current_gfp_context() has

[PATCH 1/2] mm,page_alloc: don't call __node_reclaim() without scoped allocation constraints.

We are doing the first allocation attempt before calling current_gfp_context(). But since slab shrinker functions might depend on __GFP_FS and/or __GFP_IO masking, calling slab shrinker functions from node_reclaim() from get_page_from_freelist() without calling current_gfp_context() has

[RFC PATCH 2/2] mm,sched: include memalloc info when printing debug dump of a task.

When analyzing memory allocation stalls, ability to cleanly take snapshots for knowing how far progress is made is important, but warn_alloc() is too problematic to obtain useful information. I have been proposing memory allocation watchdog kernel thread [1], but nobody seems to be interested in

[RFC PATCH 2/2] mm,sched: include memalloc info when printing debug dump of a task.

When analyzing memory allocation stalls, ability to cleanly take snapshots for knowing how far progress is made is important, but warn_alloc() is too problematic to obtain useful information. I have been proposing memory allocation watchdog kernel thread [1], but nobody seems to be interested in

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

On Fri, Sep 01, 2017 at 07:16:29PM +0900, Byungchul Park wrote: > It would be gone _only_ at the time the history overrun, and then it > will be built again. So, you are wrong. How will it ever be build again? You only ever spawn the worker thread _ONCE_, then it runs lots and lots of works. We

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

On Fri, Sep 01, 2017 at 07:16:29PM +0900, Byungchul Park wrote: > It would be gone _only_ at the time the history overrun, and then it > will be built again. So, you are wrong. How will it ever be build again? You only ever spawn the worker thread _ONCE_, then it runs lots and lots of works. We

[PATCH] perf/x86/intel/cstate: revise package C-state residency of SKL/KBL

Despite Intel SDM vol-4 does not claim to have there MSRs, EDS of SKL/KBL do claim to have PC8/PC9/PC10 states, also these residency MSRs are visible through rdmsr. This patch allows developers to calculate correct portions among various package C-states against total TSC ticks, and this would

[PATCH] perf/x86/intel/cstate: revise package C-state residency of SKL/KBL

Despite Intel SDM vol-4 does not claim to have there MSRs, EDS of SKL/KBL do claim to have PC8/PC9/PC10 states, also these residency MSRs are visible through rdmsr. This patch allows developers to calculate correct portions among various package C-states against total TSC ticks, and this would

Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote: > Actually on the second thought: does the above memory ordering differences > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way > how it is currently implemented for x86 is the same way as it is for atomic

Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t

On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote: > Actually on the second thought: does the above memory ordering differences > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way > how it is currently implemented for x86 is the same way as it is for atomic

Re: [PATCH] sched: reset sysctl_sched_time_avg to default when

On Fri, Sep 01, 2017 at 07:31:54PM +0800, Ethan Zhao wrote: > System will hang if user set sysctl_sched_time_avg to 0 by > > [root@XXX ~]# sysctl kernel.sched_time_avg_ms=0 > > Stack traceback for pid 0 > 0x883f6406c600 0 0 1 3 R 0x883f6406cf50 *swapper/3 > 883f7ccc3ae8

Re: [PATCH] sched: reset sysctl_sched_time_avg to default when

On Fri, Sep 01, 2017 at 07:31:54PM +0800, Ethan Zhao wrote: > System will hang if user set sysctl_sched_time_avg to 0 by > > [root@XXX ~]# sysctl kernel.sched_time_avg_ms=0 > > Stack traceback for pid 0 > 0x883f6406c600 0 0 1 3 R 0x883f6406cf50 *swapper/3 > 883f7ccc3ae8

Re: [patch 2/2] mm, compaction: persistently skip hugetlbfs pageblocks

On 08/23/2017 10:41 AM, Vlastimil Babka wrote: > On 08/16/2017 01:39 AM, David Rientjes wrote: >> It is pointless to migrate hugetlb memory as part of memory compaction if >> the hugetlb size is equal to the pageblock order. No defragmentation is >> occurring in this condition. >> >> It is also

Re: [patch 2/2] mm, compaction: persistently skip hugetlbfs pageblocks

On 08/23/2017 10:41 AM, Vlastimil Babka wrote: > On 08/16/2017 01:39 AM, David Rientjes wrote: >> It is pointless to migrate hugetlb memory as part of memory compaction if >> the hugetlb size is equal to the pageblock order. No defragmentation is >> occurring in this condition. >> >> It is also

Re: [RFC][PATCH] perf: Rewrite enabled/running timekeeping

On Fri, Sep 01, 2017 at 01:45:17PM +0300, Alexey Budankov wrote: > Well, this looks like an "opposite" approach to event timekeeping in > comparison to what we currently have. I would say 'sane' approach. The current thing is horrible. > Do you want this rework before or after the current

Re: [RFC][PATCH] perf: Rewrite enabled/running timekeeping

On Fri, Sep 01, 2017 at 01:45:17PM +0300, Alexey Budankov wrote: > Well, this looks like an "opposite" approach to event timekeeping in > comparison to what we currently have. I would say 'sane' approach. The current thing is horrible. > Do you want this rework before or after the current

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