[PATCH v4] dt-bindings: Add jdi lt070me05000 panel bindings

Add documentation for lt070me05000 panel Cc: Archit Taneja Cc: John Stultz Cc: Thierry Reding Cc: Sumit Semwal Signed-off-by: Vinay Simha BN Acked-by: Rob Herring

[PATCH v4] dt-bindings: Add jdi lt070me05000 panel bindings

Add documentation for lt070me05000 panel Cc: Archit Taneja Cc: John Stultz Cc: Thierry Reding Cc: Sumit Semwal Signed-off-by: Vinay Simha BN Acked-by: Rob Herring --- v2: * incorporated rob herring and thierry reviews gpio to gpios, gpio to regulator using fixed regulators and pwm

[PATCH] syscon: dt-bindings: Add documentation for Aspeed system control units

Signed-off-by: Andrew Jeffery Acked-by: Rob Herring Acked-by: Joel Stanley Acked-by: Linus Walleij --- Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 18 ++ 1 file changed, 18 insertions(+)

[PATCH] syscon: dt-bindings: Add documentation for Aspeed system control units

Signed-off-by: Andrew Jeffery Acked-by: Rob Herring Acked-by: Joel Stanley Acked-by: Linus Walleij --- Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-scu.txt diff

Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

Recently I got myself a new laptop with the following integrated GPU: 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] (rev 40) I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6) and bisected it to commit 274ad65c9d02

Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

Recently I got myself a new laptop with the following integrated GPU: 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] (rev 40) I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6) and bisected it to commit 274ad65c9d02

Re: [PATCH] ubifs: compress lines for immediate return

Heiko, On 05.09.2016 06:59, Heiko Schocher wrote: > fix the following code: > > -ret = expression; > -if (ret) > -return ret; > -return 0; > +return expression; "Fix"? ;-) What was broken? I agree that we can write the expression in a different way, but is it really worth it? Is this

Re: [PATCH] ubifs: compress lines for immediate return

Heiko, On 05.09.2016 06:59, Heiko Schocher wrote: > fix the following code: > > -ret = expression; > -if (ret) > -return ret; > -return 0; > +return expression; "Fix"? ;-) What was broken? I agree that we can write the expression in a different way, but is it really worth it? Is this

[GIT PULL] ARM: SoC fixes

Hi Linus, The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468: Linux 4.8-rc3 (2016-08-21 16:14:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to

Re: [RFC2 PATCH 00/23] ARM64: support ILP32

Hi, Guys There was a discussion about bump vdso version of kernel. We need update the vdso version in glibc correspondingly otherwise the application could not make use of the vdso. Is it make sense to you? Regards Bamvor commit 3ffc1d798fc25ccb02e7cc325fe5fb3890c085e3 Author: Bamvor Jian

[GIT PULL] ARM: SoC fixes

Hi Linus, The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468: Linux 4.8-rc3 (2016-08-21 16:14:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to

Re: [RFC2 PATCH 00/23] ARM64: support ILP32

Hi, Guys There was a discussion about bump vdso version of kernel. We need update the vdso version in glibc correspondingly otherwise the application could not make use of the vdso. Is it make sense to you? Regards Bamvor commit 3ffc1d798fc25ccb02e7cc325fe5fb3890c085e3 Author: Bamvor Jian

Re: [RFC PATCH 1/2] macb: Add 1588 support in Cadence GEM.

Hi, On Tue, Sep 6, 2016 at 9:18 PM, Richard Cochran wrote: > >> +#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */ > > This regsiter does not exist. Looking at > >Zynq-7000 AP SoC Technical Reference Manual >UG585 (v1.10) February 23, 2015

Re: [RFC PATCH 1/2] macb: Add 1588 support in Cadence GEM.

Hi, On Tue, Sep 6, 2016 at 9:18 PM, Richard Cochran wrote: > >> +#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */ > > This regsiter does not exist. Looking at > >Zynq-7000 AP SoC Technical Reference Manual >UG585 (v1.10) February 23, 2015 > > starting on page 1273

[sched/wait] 02ae2b22bd: WARNING: CPU: 0 PID: 958 at kernel/sched/core.c:7610 __might_sleep+0x6e/0x90

FYI, we noticed the following commit: https://github.com/0day-ci/linux Oleg-Nesterov/sched-wait-fix-and-then-kill-abort_exclusive_wait/20160907-145024 commit 02ae2b22bd2a42c4e4054563b139a541ba67a43e ("sched/wait: avoid abort_exclusive_wait() in ___wait_event()") in testcase: boo

[sched/wait] 02ae2b22bd: WARNING: CPU: 0 PID: 958 at kernel/sched/core.c:7610 __might_sleep+0x6e/0x90

FYI, we noticed the following commit: https://github.com/0day-ci/linux Oleg-Nesterov/sched-wait-fix-and-then-kill-abort_exclusive_wait/20160907-145024 commit 02ae2b22bd2a42c4e4054563b139a541ba67a43e ("sched/wait: avoid abort_exclusive_wait() in ___wait_event()") in testcase: boo

Re: [PATCH v2 3/4] ARM: dts: Add NextThing GR8 dtsi

On Thu, Sep 8, 2016 at 3:37 AM, Linus Walleij wrote: > On Wed, Sep 7, 2016 at 4:53 PM, Maxime Ripard > wrote: > >> From: Mylène Josserand >> >> The GR8 is an SoC made by Nextthing loosely based on

Re: [PATCH v2 3/4] ARM: dts: Add NextThing GR8 dtsi

On Thu, Sep 8, 2016 at 3:37 AM, Linus Walleij wrote: > On Wed, Sep 7, 2016 at 4:53 PM, Maxime Ripard > wrote: > >> From: Mylène Josserand >> >> The GR8 is an SoC made by Nextthing loosely based on the sun5i family. >> >> Since it's not clear yet what we can factor out and merge with the A10s

Re: [GIT PULL] seccomp fixes for v4.8-rc6

Actually I asked if you could send them to me... On 08/09/16 02:29, Kees Cook wrote: Hi, Please pull these seccomp fixes for v4.8-rc6. These got accidentally put in James's -next tree, but they're needed for v4.8. He asked me to forward them directly to you. Thanks! -Kees The following

Re: [GIT PULL] seccomp fixes for v4.8-rc6

Actually I asked if you could send them to me... On 08/09/16 02:29, Kees Cook wrote: Hi, Please pull these seccomp fixes for v4.8-rc6. These got accidentally put in James's -next tree, but they're needed for v4.8. He asked me to forward them directly to you. Thanks! -Kees The following

DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[ adding linux-fsdevel and linux-nvdimm ] On Wed, Sep 7, 2016 at 8:36 PM, Xiao Guangrong wrote: [..] > However, it is not easy to handle the case that the new VMA overlays with > the old VMA > already got by userspace. I think we have some choices: > 1: One way is

DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[ adding linux-fsdevel and linux-nvdimm ] On Wed, Sep 7, 2016 at 8:36 PM, Xiao Guangrong wrote: [..] > However, it is not easy to handle the case that the new VMA overlays with > the old VMA > already got by userspace. I think we have some choices: > 1: One way is completely skipping the new VMA

Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts

On Wed, Sep 07, 2016 at 03:50:57PM +0200, Ralf Ramsauer wrote: > Hi all, > > may I *poke* you again? > > We're close to the release of 4.8, and this patch (b5c86b749 upstream) > should still be reverted on mainline Ok, done in fixes now. -Olof

Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts

On Wed, Sep 07, 2016 at 03:50:57PM +0200, Ralf Ramsauer wrote: > Hi all, > > may I *poke* you again? > > We're close to the release of 4.8, and this patch (b5c86b749 upstream) > should still be reverted on mainline Ok, done in fixes now. -Olof

Re: bcache vs bcachefs

On Wed, Sep 07, 2016 at 11:01:40PM -0400, Theodore Ts'o wrote: > On Wed, Sep 07, 2016 at 07:55:52AM -0800, Kent Overstreet wrote: > > That said, I'm not advocating people rush out to throw bcachefs on their > > servers > > or use it without backups yet, it's still young and needs more widespread

Re: bcache vs bcachefs

On Wed, Sep 07, 2016 at 11:01:40PM -0400, Theodore Ts'o wrote: > On Wed, Sep 07, 2016 at 07:55:52AM -0800, Kent Overstreet wrote: > > That said, I'm not advocating people rush out to throw bcachefs on their > > servers > > or use it without backups yet, it's still young and needs more widespread

[PATCH] Bluetooth: fix kzalloc-simple.cocci warnings

net/bluetooth/mgmt.c:905:6-13: WARNING: kzalloc should be used for rp, instead of kmalloc/memset Use kzalloc rather than kmalloc followed by memset with 0 This considers some simple cases that are common and easy to validate Note in particular that there are no ...s in the rule, so all of

[PATCH] Bluetooth: fix kzalloc-simple.cocci warnings

net/bluetooth/mgmt.c:905:6-13: WARNING: kzalloc should be used for rp, instead of kmalloc/memset Use kzalloc rather than kmalloc followed by memset with 0 This considers some simple cases that are common and easy to validate Note in particular that there are no ...s in the rule, so all of

Re: [Linaro-acpi] [PATCH V8 1/8] ACPI: I/O Remapping Table (IORT) initial support

On 02.09.2016 13:52, Fu Wei wrote: > Hi Tomasz, > > On 11 August 2016 at 18:06, Tomasz Nowicki wrote: >> IORT shows representation of IO topology for ARM based systems. >> It describes how various components are connected together on >> parent-child basis e.g. PCI RC -> SMMU ->

Re: [Linaro-acpi] [PATCH V8 1/8] ACPI: I/O Remapping Table (IORT) initial support

On 02.09.2016 13:52, Fu Wei wrote: > Hi Tomasz, > > On 11 August 2016 at 18:06, Tomasz Nowicki wrote: >> IORT shows representation of IO topology for ARM based systems. >> It describes how various components are connected together on >> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT

Re: [PATCH v3 5/8] pinctrl: Add core support for Aspeed SoCs

On Wed, 2016-09-07 at 16:50 +0200, Linus Walleij wrote: > On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > > > > > The Aspeed SoCs typically provide more than 200 pins for GPIO and other > > functions. The signal enabled on a pin is determined on a priority > > basis,

Re: [PATCH v3 5/8] pinctrl: Add core support for Aspeed SoCs

On Wed, 2016-09-07 at 16:50 +0200, Linus Walleij wrote: > On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery wrote: > > > > > The Aspeed SoCs typically provide more than 200 pins for GPIO and other > > functions. The signal enabled on a pin is determined on a priority > > basis, where a given pin

Re: [PATCH v4 3/3] iio: adc: add support for Allwinner SoCs ADC

On 04/09/2016 16:35, Jonathan Cameron wrote: > On 01/09/16 15:05, Quentin Schulz wrote: >> The Allwinner SoCs all have an ADC that can also act as a touchscreen >> controller and a thermal sensor. This patch adds the ADC driver which is >> based on the MFD for the same SoCs ADC. >> >> This also

Re: [PATCH v4 3/3] iio: adc: add support for Allwinner SoCs ADC

On 04/09/2016 16:35, Jonathan Cameron wrote: > On 01/09/16 15:05, Quentin Schulz wrote: >> The Allwinner SoCs all have an ADC that can also act as a touchscreen >> controller and a thermal sensor. This patch adds the ADC driver which is >> based on the MFD for the same SoCs ADC. >> >> This also

[PATCH v2 2/2] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

Make sure the request PSR state could effect in analogix_dp_send_psr_spd() function, or printing the error Sink PSR state if we failed to effect the request PSR setting. Signed-off-by: Yakir Yang --- Changes in v2: - A bunch of good fixes from Sean

[PATCH v2 2/2] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

Make sure the request PSR state could effect in analogix_dp_send_psr_spd() function, or printing the error Sink PSR state if we failed to effect the request PSR setting. Signed-off-by: Yakir Yang --- Changes in v2: - A bunch of good fixes from Sean

[PATCH v2 1/2] drm/bridge: analogix_dp: Remove duplicated code v2

From: Tomeu Vizoso Remove code for reading the EDID and DPCD fields and use the helpers instead. Besides the obvious code reduction, other helpers are being added to the core that could be used in this driver and will be good to be able to use them instead of

[PATCH v2 1/2] drm/bridge: analogix_dp: Remove duplicated code v2

From: Tomeu Vizoso Remove code for reading the EDID and DPCD fields and use the helpers instead. Besides the obvious code reduction, other helpers are being added to the core that could be used in this driver and will be good to be able to use them instead of duplicating them. Signed-off-by:

Re: [PATCH 4/6] clk: sunxi-ng: Add A33 CCU support

Hi, On Thu, Sep 1, 2016 at 10:16 PM, Maxime Ripard wrote: > This commit introduces the clocks found in the Allwinner A33 CCU. > > Since this SoC is very similar to the A23, and we share a significant share > of the DTSI, the clock IDs that are going to be used

Re: [PATCH 4/6] clk: sunxi-ng: Add A33 CCU support

Hi, On Thu, Sep 1, 2016 at 10:16 PM, Maxime Ripard wrote: > This commit introduces the clocks found in the Allwinner A33 CCU. > > Since this SoC is very similar to the A23, and we share a significant share > of the DTSI, the clock IDs that are going to be used will also be shared > with the A23,

Re: [PATCH] Fix region lost in /proc/self/smaps

On 09/08/2016 12:34 AM, Dave Hansen wrote: On 09/06/2016 11:51 PM, Xiao Guangrong wrote: In order to fix this bug, we make 'file->version' indicate the next VMA we want to handle This new approach makes it more likely that we'll skip a new VMA that gets inserted in between the read()s.

Re: [PATCH] Fix region lost in /proc/self/smaps

On 09/08/2016 12:34 AM, Dave Hansen wrote: On 09/06/2016 11:51 PM, Xiao Guangrong wrote: In order to fix this bug, we make 'file->version' indicate the next VMA we want to handle This new approach makes it more likely that we'll skip a new VMA that gets inserted in between the read()s.

Re: [PATCH v2 0/5] perf, bts: Fallout from the fuzzer for perf/urgent

On Wed, 7 Sep 2016, Alexander Shishkin wrote: > Vince Weaver writes: > > > On Wed, 7 Sep 2016, Alexander Shishkin wrote: > > > >> Sure. And yes, I did catch a warning, which calls for one more patch > >> (below). Also one unrelated thing in PEBS that Peter fixed. > > > > Does

Re: [PATCH v2 0/5] perf, bts: Fallout from the fuzzer for perf/urgent

On Wed, 7 Sep 2016, Alexander Shishkin wrote: > Vince Weaver writes: > > > On Wed, 7 Sep 2016, Alexander Shishkin wrote: > > > >> Sure. And yes, I did catch a warning, which calls for one more patch > >> (below). Also one unrelated thing in PEBS that Peter fixed. > > > > Does that fix this

Re: [PATCH V2] ARM: BCM5301X: Add basic dts for BCM53573 based Tenda AC9

Le 22/08/2016 à 22:37, Rafał Miłecki a écrit : > BCM53573 seems to be low priced alternative for Northstar chipsts. It > uses single core Cortex-A7 and doesn't have SDU or local (TWD) timer. It > was also stripped out of independent SPI controller and 2 GMACs. > > DTS for Tenda AC9 isn't

Re: [PATCH V2] ARM: BCM5301X: Add basic dts for BCM53573 based Tenda AC9

Le 22/08/2016 à 22:37, Rafał Miłecki a écrit : > BCM53573 seems to be low priced alternative for Northstar chipsts. It > uses single core Cortex-A7 and doesn't have SDU or local (TWD) timer. It > was also stripped out of independent SPI controller and 2 GMACs. > > DTS for Tenda AC9 isn't

Re: [PATCH] ARM: BCM5301X: Add DT for Netgear R8500

Le 22/08/2016 à 23:40, Rafał Miłecki a écrit : > From: Rafał Miłecki > > Netgear R8500 is another BCM47094 device, it just has three BCM4366 > wireless chipsets. It's a very standard DT with mostly GPIO devices. > > Signed-off-by: Rafał Miłecki Applied,

Re: [PATCH] ARM: BCM5301X: Add DT for Netgear R8500

Le 22/08/2016 à 23:40, Rafał Miłecki a écrit : > From: Rafał Miłecki > > Netgear R8500 is another BCM47094 device, it just has three BCM4366 > wireless chipsets. It's a very standard DT with mostly GPIO devices. > > Signed-off-by: Rafał Miłecki Applied, thanks! -- Florian

[PATCH] usb: dwc3: OCTEON: add support for device tree

This patch adds support to parse probe data for the dwc3-octeon driver using device tree. The DWC3 IP core is found on OCTEON III processors. Signed-off-by: Steven J. Hill --- drivers/usb/dwc3/Kconfig | 10 + drivers/usb/dwc3/Makefile | 1 +

[PATCH] usb: dwc3: OCTEON: add support for device tree

This patch adds support to parse probe data for the dwc3-octeon driver using device tree. The DWC3 IP core is found on OCTEON III processors. Signed-off-by: Steven J. Hill --- drivers/usb/dwc3/Kconfig | 10 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-octeon.c | 96

[PATCH] ARM: dts: sun8i: Move A23/A33 usbphy and usb_otg nodes to common dtsi

The usbphy and usb_otg nodes in the A23 and A33 dts files only differ by compatible, and for the usbphy, the size of one of its register regions. Move all the common bits to the A23/A33 common dtsi file. Signed-off-by: Chen-Yu Tsai --- Hi Maxime, This patch applies on top of

[PATCH] ARM: dts: sun8i: Move A23/A33 usbphy and usb_otg nodes to common dtsi

The usbphy and usb_otg nodes in the A23 and A33 dts files only differ by compatible, and for the usbphy, the size of one of its register regions. Move all the common bits to the A23/A33 common dtsi file. Signed-off-by: Chen-Yu Tsai --- Hi Maxime, This patch applies on top of your A23/A33 CCU

Re: [PATCH V2 2/3] pwm: Add MediaTek MT2701 display PWM driver support

On Mon, Jul 11, 2016 at 04:18:08PM +0800, Weiqing Kong wrote: > Use the mtk_pwm_data struction to define different registers > and add MT2701 specific register operations, such as MT2701 > doesn't have commit register, needs to disable double buffer > before writing register, and needs to select

Re: [PATCH V2 2/3] pwm: Add MediaTek MT2701 display PWM driver support

On Mon, Jul 11, 2016 at 04:18:08PM +0800, Weiqing Kong wrote: > Use the mtk_pwm_data struction to define different registers > and add MT2701 specific register operations, such as MT2701 > doesn't have commit register, needs to disable double buffer > before writing register, and needs to select

[PATCH] phy: sun4i-usb: Use spinlock to guard phyctl register access

The musb driver calls into this phy driver to disable/enable squelch detection. This function was introduced in 24fe86a617c5 ("phy: sun4i-usb: Add a sunxi specific function for setting squelch-detect"). This function in turn calls sun4i_usb_phy_write, which uses a mutex to guard the common access

[PATCH] phy: sun4i-usb: Use spinlock to guard phyctl register access

The musb driver calls into this phy driver to disable/enable squelch detection. This function was introduced in 24fe86a617c5 ("phy: sun4i-usb: Add a sunxi specific function for setting squelch-detect"). This function in turn calls sun4i_usb_phy_write, which uses a mutex to guard the common access

Re: [PATCH] [media] pci: constify snd_pcm_ops structures

On Thu, 8 Sep 2016, Andrey Utkin wrote: > Thanks for looking into this. > I have tested that it compiles and passes checks (C=2) cleanly after > this patch. > > Acked-by: Andrey Utkin > > While we're at it, what about constification of > *-core.c:static struct

Re: [PATCH] [media] pci: constify snd_pcm_ops structures

On Thu, 8 Sep 2016, Andrey Utkin wrote: > Thanks for looking into this. > I have tested that it compiles and passes checks (C=2) cleanly after > this patch. > > Acked-by: Andrey Utkin > > While we're at it, what about constification of > *-core.c:static struct pci_driver *_pci_driver = { >

Re: bcache vs bcachefs

On Wed, Sep 07, 2016 at 07:55:52AM -0800, Kent Overstreet wrote: > That said, I'm not advocating people rush out to throw bcachefs on their > servers > or use it without backups yet, it's still young and needs more widespread > testing. Hi Kent! Have you started using xfstests to stress test

Re: bcache vs bcachefs

On Wed, Sep 07, 2016 at 07:55:52AM -0800, Kent Overstreet wrote: > That said, I'm not advocating people rush out to throw bcachefs on their > servers > or use it without backups yet, it's still young and needs more widespread > testing. Hi Kent! Have you started using xfstests to stress test

[PATCH V6 3/3] stm: Mark the functions of writing buffer with notrace

If CONFIG_STM_FTRACE is selected, Function trace data can be writen to sink via STM, all functions that related to writing data packets to STM should be marked 'notrace' to avoid being traced by Ftrace, otherwise the program would stall into an endless loop. Signed-off-by: Chunyan Zhang

[PATCH V6 2/3] stm class: ftrace: Add ftrace-export-over-stm driver

This patch adds a driver that models itself as an stm_source. Once the stm device and stm_source have been linked via sysfs, the driver registers itself as a trace_export and everything passed to the interface from Ftrace subsystem will end up in the STM trace engine. Signed-off-by: Chunyan

[PATCH V6 3/3] stm: Mark the functions of writing buffer with notrace

If CONFIG_STM_FTRACE is selected, Function trace data can be writen to sink via STM, all functions that related to writing data packets to STM should be marked 'notrace' to avoid being traced by Ftrace, otherwise the program would stall into an endless loop. Signed-off-by: Chunyan Zhang

[PATCH V6 2/3] stm class: ftrace: Add ftrace-export-over-stm driver

This patch adds a driver that models itself as an stm_source. Once the stm device and stm_source have been linked via sysfs, the driver registers itself as a trace_export and everything passed to the interface from Ftrace subsystem will end up in the STM trace engine. Signed-off-by: Chunyan

[PATCH V6 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

Currently Function traces can be only exported to ring buffer, this patch added trace_export concept which can process traces and export them to a registered destination as an addition to the current only output of Ftrace - i.e. ring buffer. In this way, if we want Function traces to be sent to

[PATCH V6 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

Currently Function traces can be only exported to ring buffer, this patch added trace_export concept which can process traces and export them to a registered destination as an addition to the current only output of Ftrace - i.e. ring buffer. In this way, if we want Function traces to be sent to

[PATCH V6 0/3] Integration of function trace with System Trace IP blocks

IP blocks allowing a variety of trace sources to log debugging information to a pre-defined area have been introduced on a couple of architecture [1][2]. These system trace blocks (also known as STM) typically follow the MIPI STPv2 protocol [3] and provide a system wide logging facility to any

[PATCH V6 0/3] Integration of function trace with System Trace IP blocks

IP blocks allowing a variety of trace sources to log debugging information to a pre-defined area have been introduced on a couple of architecture [1][2]. These system trace blocks (also known as STM) typically follow the MIPI STPv2 protocol [3] and provide a system wide logging facility to any

RE: [PATCH net-next 0/3] r8152: configuration setting

David Miller [mailto:da...@davemloft.net] > Sent: Thursday, September 08, 2016 8:38 AM [...] > By forcing a certain mode via a Kconfig value, you are basically making it > impossible for distributions to do something reasonable here. The request is always from some manufacturers, not end users.

RE: [PATCH net-next 0/3] r8152: configuration setting

David Miller [mailto:da...@davemloft.net] > Sent: Thursday, September 08, 2016 8:38 AM [...] > By forcing a certain mode via a Kconfig value, you are basically making it > impossible for distributions to do something reasonable here. The request is always from some manufacturers, not end users.

Re: linux-next: Tree for Sep 7 (kernel/trace/trace_hwlat.c)

On Thu, 8 Sep 2016 07:42:01 +1000 Stephen Rothwell wrote: > > Link: > > http://lkml.kernel.org/r/20160907175258.1f17a...@canb.auug.org.au > > That is not the reporting email ... Randy's was a reply to that one > with message id >

Re: linux-next: Tree for Sep 7 (kernel/trace/trace_hwlat.c)

On Thu, 8 Sep 2016 07:42:01 +1000 Stephen Rothwell wrote: > > Link: > > http://lkml.kernel.org/r/20160907175258.1f17a...@canb.auug.org.au > > That is not the reporting email ... Randy's was a reply to that one > with message id > "". > Strange, I wonder how I got that email. I cut

Re: linux-next: Tree for Sep 7 (kernel/trace/trace_hwlat.c)

On Wed, 7 Sep 2016 13:55:47 -0700 Randy Dunlap wrote: > Yes, that works. Thanks. > > Acked-by: Randy Dunlap Hmm, would "Tested-by" be a more appropriate tag? -- Steve

Re: linux-next: Tree for Sep 7 (kernel/trace/trace_hwlat.c)

On Wed, 7 Sep 2016 13:55:47 -0700 Randy Dunlap wrote: > Yes, that works. Thanks. > > Acked-by: Randy Dunlap Hmm, would "Tested-by" be a more appropriate tag? -- Steve

Re: [RFC] zram: support page-based parallel write

Hi Sergey, On Thu, Sep 08, 2016 at 10:34:44AM +0900, Sergey Senozhatsky wrote: > Hello Minchan, > > sorry, I don't have enough time at the moment to review it in details > due to some urgent issues I'm working on. can this wait? Why not. I need a time to complete the work for removing RFC

Re: [RFC] zram: support page-based parallel write

Hi Sergey, On Thu, Sep 08, 2016 at 10:34:44AM +0900, Sergey Senozhatsky wrote: > Hello Minchan, > > sorry, I don't have enough time at the moment to review it in details > due to some urgent issues I'm working on. can this wait? Why not. I need a time to complete the work for removing RFC

Re: [PATCH] kbuild/builddeb: Fix !CONFIG_GCC_PLUGINS build

Dne 3.9.2016 v 21:58 Borislav Petkov napsal(a): > From: Borislav Petkov > > When building a bindeb-pkg target into an object output dir, i.e., O=, I > get: > > find: `scripts/gcc-plugins': No such file or directory > /mnt/kernel/kernel/linux-2.6/scripts/package/Makefile:97:

Re: [PATCH] kbuild/builddeb: Fix !CONFIG_GCC_PLUGINS build

Dne 3.9.2016 v 21:58 Borislav Petkov napsal(a): > From: Borislav Petkov > > When building a bindeb-pkg target into an object output dir, i.e., O=, I > get: > > find: `scripts/gcc-plugins': No such file or directory > /mnt/kernel/kernel/linux-2.6/scripts/package/Makefile:97: recipe for

RE: [PATCH net-next 0/3] r8152: configuration setting

Bjørn Mork [mailto:bj...@mork.no] > Sent: Wednesday, September 07, 2016 9:51 PM [...] > So this adds a lot of code to work around the issues you introduced by > unnecessarily blacklisting the CDC ECM configuration earlier, and still > makes the r8152 driver handle the device even in ECM mode. I

RE: [PATCH net-next 0/3] r8152: configuration setting

Bjørn Mork [mailto:bj...@mork.no] > Sent: Wednesday, September 07, 2016 9:51 PM [...] > So this adds a lot of code to work around the issues you introduced by > unnecessarily blacklisting the CDC ECM configuration earlier, and still > makes the r8152 driver handle the device even in ECM mode. I

[PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

Each individual node in the system has a ZONELIST_FALLBACK zonelist and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback order of zones during memory allocations. Sometimes it helps to dump these zonelists to see the priority order of various zones in them. Particularly platforms

[PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

Each individual node in the system has a ZONELIST_FALLBACK zonelist and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback order of zones during memory allocations. Sometimes it helps to dump these zonelists to see the priority order of various zones in them. Particularly platforms

[GIT PULL] Thermal management updates for v4.8-rc6

Hi, Linus, Please pull from   git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc to receive the latest Thermal Management updates for v4.8-rc6 with top-most commit 87260d3f7aecba9a5fadc6886c338b2a8fccfca9:   thermal: rcar_thermal: Fix priv->zone error handling (2016-09-06

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

Hi Thomas, On 8 September 2016 at 00:03, Thomas Gleixner wrote: > On Tue, 6 Sep 2016, John Stultz wrote: >> > Changes since v3: >> > - Fix the build error on S390. >> >> Since the original change is already applied to tip/timers/core, can >> you provide an incremental patch

[GIT PULL] Thermal management updates for v4.8-rc6

Hi, Linus, Please pull from   git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc to receive the latest Thermal Management updates for v4.8-rc6 with top-most commit 87260d3f7aecba9a5fadc6886c338b2a8fccfca9:   thermal: rcar_thermal: Fix priv->zone error handling (2016-09-06

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

Hi Thomas, On 8 September 2016 at 00:03, Thomas Gleixner wrote: > On Tue, 6 Sep 2016, John Stultz wrote: >> > Changes since v3: >> > - Fix the build error on S390. >> >> Since the original change is already applied to tip/timers/core, can >> you provide an incremental patch (a patch against

[PATCH v2] rtc: Add some dummy static inline functions

The patch (commit id: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021) adding tracepoints for alarmtimers will build failed on S390 platform, due to S390 defconfig did not define CONFIG_RTC_LIB macro to define the rtc_ktime_to_tm() function which is used in this patch. Thus we should add dummy static

[PATCH v2] rtc: Add some dummy static inline functions

The patch (commit id: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021) adding tracepoints for alarmtimers will build failed on S390 platform, due to S390 defconfig did not define CONFIG_RTC_LIB macro to define the rtc_ktime_to_tm() function which is used in this patch. Thus we should add dummy static

[PATCH v5 3/3] usb: dwc2: Properly account for the force mode delays

When a force mode bit is set and the IDDIG debounce filter is enabled, there is a delay for the forced mode to take effect. This delay is due to the IDDIG debounce filter and is variable depending on the platform's PHY clock speed. To account for this delay we can poll for the expected mode. On a

[PATCH v5 0/3] usb: dwc2: Fix core reset and force mode delays

This series accounts for the delay from the IDDIG debounce filter when switching modes. This delay is a function of the PHY clock speed and can range from 5-50 ms. This delay must be taken into account on core reset and force modes. A full explanation is provided in the patch commit log and code

[PATCH v5 3/3] usb: dwc2: Properly account for the force mode delays

When a force mode bit is set and the IDDIG debounce filter is enabled, there is a delay for the forced mode to take effect. This delay is due to the IDDIG debounce filter and is variable depending on the platform's PHY clock speed. To account for this delay we can poll for the expected mode. On a

[PATCH v5 0/3] usb: dwc2: Fix core reset and force mode delays

This series accounts for the delay from the IDDIG debounce filter when switching modes. This delay is a function of the PHY clock speed and can range from 5-50 ms. This delay must be taken into account on core reset and force modes. A full explanation is provided in the patch commit log and code

[PATCH v5 2/3] usb: dwc2: Add delay to core soft reset

Add a delay to the core soft reset function to account for the IDDIG debounce filter. If the current mode is host, either due to the force mode bit being set (which persists after core reset) or the connector id pin, a core soft reset will temporarily reset the mode to device and a delay from the

[PATCH v5 2/3] usb: dwc2: Add delay to core soft reset

Add a delay to the core soft reset function to account for the IDDIG debounce filter. If the current mode is host, either due to the force mode bit being set (which persists after core reset) or the connector id pin, a core soft reset will temporarily reset the mode to device and a delay from the

[PATCH v5 1/3] usb: dwc2: gadget: Only initialize device if in device mode

In dwc2_hsotg_udc_start(), don't initialize the controller for device mode unless we are actually in device mode. Tested-by: Heiko Stuebner Tested-by: Stefan Wahren Signed-off-by: John Youn --- drivers/usb/dwc2/gadget.c | 7

[PATCH v5 1/3] usb: dwc2: gadget: Only initialize device if in device mode

In dwc2_hsotg_udc_start(), don't initialize the controller for device mode unless we are actually in device mode. Tested-by: Heiko Stuebner Tested-by: Stefan Wahren Signed-off-by: John Youn --- drivers/usb/dwc2/gadget.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

Re: [RFC] zram: support page-based parallel write

Hello, On Tue, Sep 06, 2016 at 10:22:20AM +0200, Andreas Mohr wrote: > On Tue, Sep 06, 2016 at 04:24:17PM +0900, Minchan Kim wrote: > > @@ -1464,6 +1908,9 @@ static int __init zram_init(void) > > num_devices--; > > } > > > > + if (create_workers()) > > + goto

Re: [RFC] zram: support page-based parallel write

Hello, On Tue, Sep 06, 2016 at 10:22:20AM +0200, Andreas Mohr wrote: > On Tue, Sep 06, 2016 at 04:24:17PM +0900, Minchan Kim wrote: > > @@ -1464,6 +1908,9 @@ static int __init zram_init(void) > > num_devices--; > > } > > > > + if (create_workers()) > > + goto

Re: [PATCH 1/7] [v2] dt-bindings: fsl: updates bindings for some SoC-specific devices

On Mon, Sep 05, 2016 at 06:01:29PM +0800, shh@gmail.com wrote: > From: Shaohui Xie > > SCFG and DCFG are SoC-specific devices can be found on SoCs like LS1021A, > LS1043A and LS1046A, this patch updates bindings for SCFG and DCFG to > reflect more SoCs. > >

Re: [PATCH 1/7] [v2] dt-bindings: fsl: updates bindings for some SoC-specific devices

On Mon, Sep 05, 2016 at 06:01:29PM +0800, shh@gmail.com wrote: > From: Shaohui Xie > > SCFG and DCFG are SoC-specific devices can be found on SoCs like LS1021A, > LS1043A and LS1046A, this patch updates bindings for SCFG and DCFG to > reflect more SoCs. > > Signed-off-by: Shaohui Xie > ---

  1   2   3   4   5   6   7   8   9   10   >