Re: [PATCH 3.18 00/25] 3.18.108-stable review

On Tue, May 01, 2018 at 06:18:45AM -0700, Guenter Roeck wrote: > On 04/30/2018 12:23 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.108 release. > > There are 25 patches in this series, all will be posted as a response > > to this one. If anyone has

Re: [PATCH] clk:aspeed: Fix reset bits for PCI/VGA and PECI

On Thu, Apr 26, 2018 at 10:22:32AM -0700, Jae Hyun Yoo wrote: > This commit fixes incorrect setting of reset bits for PCI/VGA and > PECI modules. > > 1. Reset bit for PCI/VGA is 8. > 2. PECI reset bit is missing so added bit 10 as its reset bit. > > Signed-off-by: Jae Hyun Yoo

Re: [PATCH 3.18 00/25] 3.18.108-stable review

On Tue, May 01, 2018 at 06:18:45AM -0700, Guenter Roeck wrote: > On 04/30/2018 12:23 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.108 release. > > There are 25 patches in this series, all will be posted as a response > > to this one. If anyone has

Re: [PATCH] clk:aspeed: Fix reset bits for PCI/VGA and PECI

On Thu, Apr 26, 2018 at 10:22:32AM -0700, Jae Hyun Yoo wrote: > This commit fixes incorrect setting of reset bits for PCI/VGA and > PECI modules. > > 1. Reset bit for PCI/VGA is 8. > 2. PECI reset bit is missing so added bit 10 as its reset bit. > > Signed-off-by: Jae Hyun Yoo > Fixes:

Re: [PATCH 4.4 44/44] ath10k: fix rfc1042 header retrieval in QCA4019 with eth decap mode

On Tue, May 01, 2018 at 05:26:41AM +0530, Sriram R wrote: > On 2018-05-01 00:54, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me > > know. > Hi Greg, > > This is a dependency patch to the actual fix , > [PATCH 2/2 - linux-stable-4.4] ath10k:

Re: [PATCH 00/12] mtd: nand: davinci: stop using pdev->id as chipselect

On Tue, 1 May 2018 16:01:42 +0530 Sekhar Nori wrote: > On Monday 30 April 2018 03:39 PM, Boris Brezillon wrote: > > Hi Bartosz, > > > > On Mon, 30 Apr 2018 10:24:41 +0200 > > Bartosz Golaszewski wrote: > > > >> From: Bartosz Golaszewski

Re: [PATCH 4.4 44/44] ath10k: fix rfc1042 header retrieval in QCA4019 with eth decap mode

On Tue, May 01, 2018 at 05:26:41AM +0530, Sriram R wrote: > On 2018-05-01 00:54, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me > > know. > Hi Greg, > > This is a dependency patch to the actual fix , > [PATCH 2/2 - linux-stable-4.4] ath10k:

Re: [PATCH 00/12] mtd: nand: davinci: stop using pdev->id as chipselect

On Tue, 1 May 2018 16:01:42 +0530 Sekhar Nori wrote: > On Monday 30 April 2018 03:39 PM, Boris Brezillon wrote: > > Hi Bartosz, > > > > On Mon, 30 Apr 2018 10:24:41 +0200 > > Bartosz Golaszewski wrote: > > > >> From: Bartosz Golaszewski > >> > >> We have the 'ti,davinci-chipselect'

Re: [PATCH RFC v5 1/6] softirq: reorder trace_softirqs_on to prevent lockdep splat

On Tue, May 1, 2018 at 7:02 AM Steven Rostedt wrote: > On Mon, 30 Apr 2018 18:41:59 -0700 > Joel Fernandes wrote: > > I'm able to reproduce a lockdep splat when CONFIG_PROVE_LOCKING=y and > > CONFIG_PREEMPTIRQ_EVENTS=y. > Needs more info in the change

Re: [PATCH RFC v5 1/6] softirq: reorder trace_softirqs_on to prevent lockdep splat

On Tue, May 1, 2018 at 7:02 AM Steven Rostedt wrote: > On Mon, 30 Apr 2018 18:41:59 -0700 > Joel Fernandes wrote: > > I'm able to reproduce a lockdep splat when CONFIG_PROVE_LOCKING=y and > > CONFIG_PREEMPTIRQ_EVENTS=y. > Needs more info in the change log. It also requires that >

Re: [PATCH 07/11] irqchip: stm32: add stm32mp1 support with hierarchy domain

On Thu, Apr 26, 2018 at 06:18:30PM +0200, Ludovic Barre wrote: > From: Ludovic Barre > > Exti controller has been differently integrated on stm32mp1 SoC. > A parent irq has only one external interrupt. A hierachy domain could > be used. Handlers are call by parent, each

Re: [PATCH 07/11] irqchip: stm32: add stm32mp1 support with hierarchy domain

On Thu, Apr 26, 2018 at 06:18:30PM +0200, Ludovic Barre wrote: > From: Ludovic Barre > > Exti controller has been differently integrated on stm32mp1 SoC. > A parent irq has only one external interrupt. A hierachy domain could > be used. Handlers are call by parent, each parent interrupt could be

Re: [PATCH 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler atuo-inline optimizations

On Tue, 1 May 2018 21:00:12 +0800 changbin...@intel.com wrote: > From: Changbin Du > > This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting > this option will make compiler not auto-inline kernel functions. By > enabling this option, all the kernel

Re: [PATCH 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler atuo-inline optimizations

On Tue, 1 May 2018 21:00:12 +0800 changbin...@intel.com wrote: > From: Changbin Du > > This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting > this option will make compiler not auto-inline kernel functions. By > enabling this option, all the kernel functions (including static

[PATCH] firmware/psci: add support for SYSTEM_RESET2

PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets where the semantics are described by the PSCI specification itself as well as vendor-specific resets. Currently only system warm reset semantics is defined as part of architectural resets by the specification. This patch

[PATCH] firmware/psci: add support for SYSTEM_RESET2

PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets where the semantics are described by the PSCI specification itself as well as vendor-specific resets. Currently only system warm reset semantics is defined as part of architectural resets by the specification. This patch

Re: [PATCH v8 11/13] arm64: topology: enable ACPI/PPTT based CPU topology

On 26/04/18 00:31, Jeremy Linton wrote: > Propagate the topology information from the PPTT tree to the > cpu_topology array. We can get the thread id and core_id by assuming > certain levels of the PPTT tree correspond to those concepts. > The package_id is flagged in the tree and can be found

Re: [PATCH v8 11/13] arm64: topology: enable ACPI/PPTT based CPU topology

On 26/04/18 00:31, Jeremy Linton wrote: > Propagate the topology information from the PPTT tree to the > cpu_topology array. We can get the thread id and core_id by assuming > certain levels of the PPTT tree correspond to those concepts. > The package_id is flagged in the tree and can be found

Re: [PATCH v9 00/27] ARM: davinci: convert to common clock framework​

On Friday 27 April 2018 05:47 AM, David Lechner wrote: > This series converts mach-davinci to use the common clock framework. > > The series works like this, the first 3 patches fix some issues with the clock > drivers that have already been accepted into the mainline kernel. > > Then, starting

Re: [PATCH v9 00/27] ARM: davinci: convert to common clock framework​

On Friday 27 April 2018 05:47 AM, David Lechner wrote: > This series converts mach-davinci to use the common clock framework. > > The series works like this, the first 3 patches fix some issues with the clock > drivers that have already been accepted into the mainline kernel. > > Then, starting

Re: BUG: /proc/kcore does not export direct-mapped memory on arm64 (and presumably some other architectures)

- Original Message - > > > - Original Message - > > On 04/26/2018 02:16 PM, Kees Cook wrote: > > > On Thu, Apr 26, 2018 at 12:31 PM, Dave Anderson > > > wrote: > > >> > > >> While testing /proc/kcore as the live memory source for the crash > > >> utility,

Re: BUG: /proc/kcore does not export direct-mapped memory on arm64 (and presumably some other architectures)

- Original Message - > > > - Original Message - > > On 04/26/2018 02:16 PM, Kees Cook wrote: > > > On Thu, Apr 26, 2018 at 12:31 PM, Dave Anderson > > > wrote: > > >> > > >> While testing /proc/kcore as the live memory source for the crash > > >> utility, > > >> it fails on

Re: [PATCH] thermal: samsung: Remove support for Exynos5440

On Thu, Apr 26, 2018 at 01:21:12PM +0200, Bartlomiej Zolnierkiewicz wrote: > From: Krzysztof Kozlowski > Subject: [PATCH] thermal: samsung: Remove support for Exynos5440 > > The Exynos5440 is not actively developed, there are no development > boards available and probably there

Re: [PATCH] thermal: samsung: Remove support for Exynos5440

On Thu, Apr 26, 2018 at 01:21:12PM +0200, Bartlomiej Zolnierkiewicz wrote: > From: Krzysztof Kozlowski > Subject: [PATCH] thermal: samsung: Remove support for Exynos5440 > > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real

Re: [PATCH] mmc: meson-gx: add device reset

On Thu, Apr 26, 2018 at 12:38:17PM +0200, Jerome Brunet wrote: > Trigger the reset line of the mmc controller while probing, if available > The reset should be optional for now, at least until all related DT node > have the reset property > > Signed-off-by: Jerome Brunet >

Re: [PATCH] mmc: meson-gx: add device reset

On Thu, Apr 26, 2018 at 12:38:17PM +0200, Jerome Brunet wrote: > Trigger the reset line of the mmc controller while probing, if available > The reset should be optional for now, at least until all related DT node > have the reset property > > Signed-off-by: Jerome Brunet > --- >

Re: [PATCH 4/4] dt-bindings: mfd: max8998: Add charger subnode binding

On Tuesday, May 1, 2018 2:45:40 PM CEST Sebastian Reichel wrote: > Hi, > > On Fri, Apr 27, 2018 at 06:03:02PM +0200, Paweł Chmiel wrote: > > This patch adds devicetree bindings documentation for > > battery charging controller as the subnode of MAX8998 PMIC. > > It's based on current behavior of

Re: [PATCH 4/4] dt-bindings: mfd: max8998: Add charger subnode binding

On Tuesday, May 1, 2018 2:45:40 PM CEST Sebastian Reichel wrote: > Hi, > > On Fri, Apr 27, 2018 at 06:03:02PM +0200, Paweł Chmiel wrote: > > This patch adds devicetree bindings documentation for > > battery charging controller as the subnode of MAX8998 PMIC. > > It's based on current behavior of

Re: [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 5/1/2018 12:35 AM, Adam Thomson wrote: On 30 April 2018 10:23, Akshu Agrawal wrote: Non-dts based systems can use ACPI DSDT to pass on the mclk to da7219. This enables da7219 mclk to be linked to system clock. Enable/Disable of the mclk is already handled in the codec so platform drivers

Re: [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 5/1/2018 12:35 AM, Adam Thomson wrote: On 30 April 2018 10:23, Akshu Agrawal wrote: Non-dts based systems can use ACPI DSDT to pass on the mclk to da7219. This enables da7219 mclk to be linked to system clock. Enable/Disable of the mclk is already handled in the codec so platform drivers

Re: [PATCH v8 10/13] arm64: topology: rename cluster_id

On 26/04/18 00:31, Jeremy Linton wrote: > Lets match the name of the arm64 topology field > to the kernel macro that uses it. [nit] You can add a note that cluster id is not architectural defined for ARM platforms just to elaborate on the intention for this change. Acked-by: Sudeep Holla

Re: [PATCH v8 10/13] arm64: topology: rename cluster_id

On 26/04/18 00:31, Jeremy Linton wrote: > Lets match the name of the arm64 topology field > to the kernel macro that uses it. [nit] You can add a note that cluster id is not architectural defined for ARM platforms just to elaborate on the intention for this change. Acked-by: Sudeep Holla --

[PATCH v4 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver

This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v4 3/3] arm64: defconfig: Enable dw_mmc-bluefield driver

This patch updates arm64 defconfig to enable dw_mmc-bluefield, which is a driver extension of Synopsys Designware MMC for the Mellanox BlueField Soc. Signed-off-by: Liming Sun --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig

Re: [PATCH 6/7] clk: meson: axg: document bindings for the audio clock controller

On Wed, Apr 25, 2018 at 06:33:03PM +0200, Jerome Brunet wrote: > Add documentation for the device tree bindings of the audio clock > controller of the A113 based SoCs > The preferred subject prefix for bindings is 'dt/bindings: clock: ...' > Signed-off-by: Jerome Brunet >

Re: [PATCH 6/7] clk: meson: axg: document bindings for the audio clock controller

On Wed, Apr 25, 2018 at 06:33:03PM +0200, Jerome Brunet wrote: > Add documentation for the device tree bindings of the audio clock > controller of the A113 based SoCs > The preferred subject prefix for bindings is 'dt/bindings: clock: ...' > Signed-off-by: Jerome Brunet > --- >

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

[Cc'ing linux-security] On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote: [...] > diff --git a/drivers/base/firmware_loader/fallback_efi.c > b/drivers/base/firmware_loader/fallback_efi.c > new file mode 100644 > index ..82ba82f48a79 > --- /dev/null > +++

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

[Cc'ing linux-security] On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote: [...] > diff --git a/drivers/base/firmware_loader/fallback_efi.c > b/drivers/base/firmware_loader/fallback_efi.c > new file mode 100644 > index ..82ba82f48a79 > --- /dev/null > +++

RE: [PATCH v3 2/3] dt-bindings: mmc: Add binding for BlueField SoC

Sorry, my mistake. I missed the last one in the v3 comments. Fixed it in v4 2/3. Thanks, Liming > -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Tuesday, May 1, 2018 8:48 AM > To: Liming Sun > Cc: Ulf Hansson ; Mark

RE: [PATCH v3 2/3] dt-bindings: mmc: Add binding for BlueField SoC

Sorry, my mistake. I missed the last one in the v3 comments. Fixed it in v4 2/3. Thanks, Liming > -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Tuesday, May 1, 2018 8:48 AM > To: Liming Sun > Cc: Ulf Hansson ; Mark Rutland > ; Jaehoon Chung ; > Catalin Marinas

[PATCH v4 2/3] dt-bindings: mmc: Add binding for BlueField SoC

This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver extension on Mellanox BlueField SoC platform. Signed-off-by: Liming Sun --- .../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 ++ 1 file changed, 29 insertions(+) create mode 100644

[PATCH v4 2/3] dt-bindings: mmc: Add binding for BlueField SoC

This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver extension on Mellanox BlueField SoC platform. Signed-off-by: Liming Sun --- .../devicetree/bindings/mmc/bluefield-dw-mshc.txt | 29 ++ 1 file changed, 29 insertions(+) create mode 100644

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/30, Andrey Grodzovsky wrote: > > On 04/30/2018 12:00 PM, Oleg Nesterov wrote: > >On 04/30, Andrey Grodzovsky wrote: > >>What about changing PF_SIGNALED to  PF_EXITING in > >>drm_sched_entity_do_release > >> > >>-   if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL) >

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/30, Andrey Grodzovsky wrote: > > On 04/30/2018 12:00 PM, Oleg Nesterov wrote: > >On 04/30, Andrey Grodzovsky wrote: > >>What about changing PF_SIGNALED to  PF_EXITING in > >>drm_sched_entity_do_release > >> > >>-   if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL) >

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Tue, May 01, 2018 at 10:24:01AM -0400, Steven Rostedt wrote: > On Mon, 30 Apr 2018 18:42:03 -0700 > Joel Fernandes wrote: > > > In recent tests with IRQ on/off tracepoints, a large performance > > overhead ~10% is noticed when running hackbench. This is root caused to > >

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Tue, May 01, 2018 at 10:24:01AM -0400, Steven Rostedt wrote: > On Mon, 30 Apr 2018 18:42:03 -0700 > Joel Fernandes wrote: > > > In recent tests with IRQ on/off tracepoints, a large performance > > overhead ~10% is noticed when running hackbench. This is root caused to > > calls to

[PATCH v4 1/3] mmc: dw_mmc-bluefield: Add driver extension

This commit adds extension to the dw_mmc driver for Mellanox BlueField SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on this SoC. Signed-off-by: Liming Sun --- drivers/mmc/host/Kconfig| 9 + drivers/mmc/host/Makefile | 1 +

[PATCH v4 1/3] mmc: dw_mmc-bluefield: Add driver extension

This commit adds extension to the dw_mmc driver for Mellanox BlueField SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on this SoC. Signed-off-by: Liming Sun --- drivers/mmc/host/Kconfig| 9 + drivers/mmc/host/Makefile | 1 +

Re: [PATCH v8 13/13] arm64: topology: divorce MC scheduling domain from core_siblings

On 26/04/18 00:31, Jeremy Linton wrote: > Now that we have an accurate view of the physical topology > we need to represent it correctly to the scheduler. Generally MC > should equal the LLC in the system, but there are a number of > special cases that need to be dealt with. > > In the case of

Re: [PATCH v8 13/13] arm64: topology: divorce MC scheduling domain from core_siblings

On 26/04/18 00:31, Jeremy Linton wrote: > Now that we have an accurate view of the physical topology > we need to represent it correctly to the scheduler. Generally MC > should equal the LLC in the system, but there are a number of > special cases that need to be dealt with. > > In the case of

[V5 PATCH] perf parse-events: Specially handle uncore event alias in small groups

From: Kan Liang Perf stat doesn't count the uncore event aliases from the same uncore block in a group, for example: perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I 1000 # time counts unit events 1.000447342

[V5 PATCH] perf parse-events: Specially handle uncore event alias in small groups

From: Kan Liang Perf stat doesn't count the uncore event aliases from the same uncore block in a group, for example: perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I 1000 # time counts unit events 1.000447342unc_m_cas_count.all

Re: [alsa-devel] [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 4/30/2018 9:54 PM, Pierre-Louis Bossart wrote: On 4/30/18 4:23 AM, Akshu Agrawal wrote: Non-dts based systems can use ACPI DSDT to pass on the mclk to da7219. This enables da7219 mclk to be linked to system clock. Enable/Disable of the mclk is already handled in the codec so platform

Re: [alsa-devel] [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 4/30/2018 9:54 PM, Pierre-Louis Bossart wrote: On 4/30/18 4:23 AM, Akshu Agrawal wrote: Non-dts based systems can use ACPI DSDT to pass on the mclk to da7219. This enables da7219 mclk to be linked to system clock. Enable/Disable of the mclk is already handled in the codec so platform

Re: [PATCH 5/7] clk: meson: axg: export audio clock controller id bindings

On Wed, Apr 25, 2018 at 06:33:02PM +0200, Jerome Brunet wrote: > export the clock ids dt-bindings usable by the consumers of the axg > audio clock controller Capitalization and punctuation would be nice. > > Signed-off-by: Jerome Brunet > --- >

Re: [PATCH 5/7] clk: meson: axg: export audio clock controller id bindings

On Wed, Apr 25, 2018 at 06:33:02PM +0200, Jerome Brunet wrote: > export the clock ids dt-bindings usable by the consumers of the axg > audio clock controller Capitalization and punctuation would be nice. > > Signed-off-by: Jerome Brunet > --- > include/dt-bindings/clock/axg-audio-clkc.h | 94

Re: [PATCH 1/3] dt-bindings: mailbox: Add APSS shared binding for SDM845 SoCs

On Wed, Apr 25, 2018 at 08:08:01PM +0530, Sibi Sankar wrote: > Include SDM845 APSS shared to the list of possible bindings > > Signed-off-by: Sibi Sankar > --- > .../devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt| 1 + > 1 file changed, 1 insertion(+)

Re: [PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

Randy Dunlap wrote: > > + (2) Parse the options and attach them to the context. Options may be > > passed > > + individually from userspace. > > Does this say that step (2) can be multiple small steps? Perhaps "phase (2)" would be a better name than "step (2)".

Re: [PATCH 1/3] dt-bindings: mailbox: Add APSS shared binding for SDM845 SoCs

On Wed, Apr 25, 2018 at 08:08:01PM +0530, Sibi Sankar wrote: > Include SDM845 APSS shared to the list of possible bindings > > Signed-off-by: Sibi Sankar > --- > .../devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt| 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Rob Herring

Re: [PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

Randy Dunlap wrote: > > + (2) Parse the options and attach them to the context. Options may be > > passed > > + individually from userspace. > > Does this say that step (2) can be multiple small steps? Perhaps "phase (2)" would be a better name than "step (2)". During (2), multiple

Re: [PATCH 1/2] dt-bindings: media: i2c: Add mt9t111 image sensor

On Wed, Apr 25, 2018 at 01:00:13PM +0200, Jacopo Mondi wrote: > Add device tree bindings documentation for Micron MT9T111/MT9T112 image > sensors. > > Signed-off-by: Jacopo Mondi > --- > Documentation/devicetree/bindings/mt9t112.txt | 41 > +++

Re: [PATCH 1/2] dt-bindings: media: i2c: Add mt9t111 image sensor

On Wed, Apr 25, 2018 at 01:00:13PM +0200, Jacopo Mondi wrote: > Add device tree bindings documentation for Micron MT9T111/MT9T112 image > sensors. > > Signed-off-by: Jacopo Mondi > --- > Documentation/devicetree/bindings/mt9t112.txt | 41 > +++ > 1 file changed, 41

Re: ORC unwinder bad backtrace

On Wed, Apr 18, 2018 at 10:45:48AM -0500, Josh Poimboeuf wrote: > On Wed, Apr 18, 2018 at 06:54:38AM -0700, Matthew Wilcox wrote: > > f81061192 : > > ... > > 810611bf: 90 nop > > 810611c0 : > > > > I suspect an off-by-one error; you don't really mean to

Re: ORC unwinder bad backtrace

On Wed, Apr 18, 2018 at 10:45:48AM -0500, Josh Poimboeuf wrote: > On Wed, Apr 18, 2018 at 06:54:38AM -0700, Matthew Wilcox wrote: > > f81061192 : > > ... > > 810611bf: 90 nop > > 810611c0 : > > > > I suspect an off-by-one error; you don't really mean to

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Tuesday 01 May 2018 05:24 PM, Lorenzo Pieralisi wrote: > > On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote: > >> Hi Lorenzo, > >> > >> On Thursday 26 April 2018 10:26 PM, Lorenzo

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Tuesday 01 May 2018 05:24 PM, Lorenzo Pieralisi wrote: > > On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote: > >> Hi Lorenzo, > >> > >> On Thursday 26 April 2018 10:26 PM, Lorenzo

Re: [PATCH] dt-bindings: panel: lvds: Fix path to display timing bindings

On Wed, Apr 25, 2018 at 09:49:38AM +0200, Geert Uytterhoeven wrote: > Fixes: 14da3ed8dd08c581 ("devicetree/bindings: display: Document common > panel properties") > Signed-off-by: Geert Uytterhoeven > --- > Documentation/devicetree/bindings/display/panel/panel-common.txt

Re: [PATCH] dt-bindings: panel: lvds: Fix path to display timing bindings

On Wed, Apr 25, 2018 at 09:49:38AM +0200, Geert Uytterhoeven wrote: > Fixes: 14da3ed8dd08c581 ("devicetree/bindings: display: Document common > panel properties") > Signed-off-by: Geert Uytterhoeven > --- > Documentation/devicetree/bindings/display/panel/panel-common.txt | 2 +- > 1 file

Re: [PATCH 1/2] dt-bindings: add MediaTek XS-PHY binding

On Wed, Apr 25, 2018 at 03:45:28PM +0800, Chunfeng Yun wrote: > Add a DT binding documentation of XS-PHY for MediaTek SoCs > with USB3.1 GEN2 controller > > Signed-off-by: Chunfeng Yun > --- > .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 127 >

Re: [PATCH 1/2] dt-bindings: add MediaTek XS-PHY binding

On Wed, Apr 25, 2018 at 03:45:28PM +0800, Chunfeng Yun wrote: > Add a DT binding documentation of XS-PHY for MediaTek SoCs > with USB3.1 GEN2 controller > > Signed-off-by: Chunfeng Yun > --- > .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 127 > > 1 file changed,

Re: [PATCH 4.9 00/61] 4.9.98-stable review

On Mon, Apr 30, 2018 at 12:24:03PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.98 release. > There are 61 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Tue, 01 May 2018 01:56:01 + Joel Fernandes wrote: > This last bit is supposed to be srcu_dereference_notrace. The hunk to use > that is actually in patch 6/6 , sorry about that. I've fixed it in my tree > and it means patches 5/6 and 6/6 need an update. Steve, if you

Re: [PATCH 4.9 00/61] 4.9.98-stable review

On Mon, Apr 30, 2018 at 12:24:03PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.98 release. > There are 61 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Tue, 01 May 2018 01:56:01 + Joel Fernandes wrote: > This last bit is supposed to be srcu_dereference_notrace. The hunk to use > that is actually in patch 6/6 , sorry about that. I've fixed it in my tree > and it means patches 5/6 and 6/6 need an update. Steve, if you want me to > repost

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Mon, 30 Apr 2018 18:42:03 -0700 Joel Fernandes wrote: > In recent tests with IRQ on/off tracepoints, a large performance > overhead ~10% is noticed when running hackbench. This is root caused to > calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the > tracepoint

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Mon, 30 Apr 2018 18:42:03 -0700 Joel Fernandes wrote: > In recent tests with IRQ on/off tracepoints, a large performance > overhead ~10% is noticed when running hackbench. This is root caused to > calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the > tracepoint code. Following a

Re: [PATCH 2/2] sched: Introduce set_special_state()

On Tue, May 01, 2018 at 03:59:24PM +0200, Oleg Nesterov wrote: > On 05/01, Peter Zijlstra wrote: > > > > The only code I found that seems to care is ptrace_attach(), where we > > wait for JOBCTL_TRAPPING to get cleared. That same function has a > > comment about hiding the STOPPED -> RUNNING ->

Re: [PATCH 4.4 00/44] 4.4.131-stable review

On Mon, Apr 30, 2018 at 12:24:11PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.131 release. > There are 44 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 2/2] sched: Introduce set_special_state()

On Tue, May 01, 2018 at 03:59:24PM +0200, Oleg Nesterov wrote: > On 05/01, Peter Zijlstra wrote: > > > > The only code I found that seems to care is ptrace_attach(), where we > > wait for JOBCTL_TRAPPING to get cleared. That same function has a > > comment about hiding the STOPPED -> RUNNING ->

Re: [PATCH 4.4 00/44] 4.4.131-stable review

On Mon, Apr 30, 2018 at 12:24:11PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.131 release. > There are 44 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH net-next 0/2 v5] netns: uevent filtering

From: ebied...@xmission.com (Eric W. Biederman) Date: Mon, 30 Apr 2018 10:55:55 -0500 > Christian Brauner writes: > >> Hey everyone, >> >> This is the new approach to uevent filtering as discussed (see the >> threads in [1], [2], and [3]). It only contains

Re: [PATCH net-next 0/2 v5] netns: uevent filtering

From: ebied...@xmission.com (Eric W. Biederman) Date: Mon, 30 Apr 2018 10:55:55 -0500 > Christian Brauner writes: > >> Hey everyone, >> >> This is the new approach to uevent filtering as discussed (see the >> threads in [1], [2], and [3]). It only contains *non-functional >> changes*. ... >

Re: [PATCH v9 06/27] ARM: davinci: da850: add new clock init using common clock framework

On Friday 27 April 2018 05:47 AM, David Lechner wrote: > This adds the new board-specific clock init in mach-davinci/da850.c > using the new common clock framework drivers. > > The #ifdefs are needed to prevent compile errors until the entire > ARCH_DAVINCI is converted. > > Also clean up the

Re: [PATCH v9 06/27] ARM: davinci: da850: add new clock init using common clock framework

On Friday 27 April 2018 05:47 AM, David Lechner wrote: > This adds the new board-specific clock init in mach-davinci/da850.c > using the new common clock framework drivers. > > The #ifdefs are needed to prevent compile errors until the entire > ARCH_DAVINCI is converted. > > Also clean up the

Re: [PATCH RFC v5 3/6] srcu: Add notrace variant of srcu_dereference

On Mon, Apr 30, 2018 at 06:42:01PM -0700, Joel Fernandes wrote: > In this series, we are making lockdep use an rcuidle tracepoint. For > this reason we need a notrace variant of srcu_dereference since > otherwise we get lockdep splats since lockdep hooks may not have run > yet. This patch adds the

Re: [PATCH RFC v5 3/6] srcu: Add notrace variant of srcu_dereference

On Mon, Apr 30, 2018 at 06:42:01PM -0700, Joel Fernandes wrote: > In this series, we are making lockdep use an rcuidle tracepoint. For > this reason we need a notrace variant of srcu_dereference since > otherwise we get lockdep splats since lockdep hooks may not have run > yet. This patch adds the

[PATCH V1] irqchip/qcom: Fix check for spurious interrupts

When the interrupts for a combiner span multiple registers we need to check if any interrupts have been asserted on each register before checking for spurious interrupts. Signed-off-by: Agustin Vega-Frias --- drivers/irqchip/qcom-irq-combiner.c | 4 ++-- 1 file changed,

[PATCH V1] irqchip/qcom: Fix check for spurious interrupts

When the interrupts for a combiner span multiple registers we need to check if any interrupts have been asserted on each register before checking for spurious interrupts. Signed-off-by: Agustin Vega-Frias --- drivers/irqchip/qcom-irq-combiner.c | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [PATCH v9 05/27] ARM: davinci: da830: add new clock init using common clock framework

On Friday 27 April 2018 05:47 AM, David Lechner wrote: > This adds the new board-specific clock init in mach-davinci/da830.c > using the new common clock framework drivers. > > The #ifdefs are needed to prevent compile errors until the entire > ARCH_DAVINCI is converted. > > Also clean up the

Re: [PATCH v9 05/27] ARM: davinci: da830: add new clock init using common clock framework

On Friday 27 April 2018 05:47 AM, David Lechner wrote: > This adds the new board-specific clock init in mach-davinci/da830.c > using the new common clock framework drivers. > > The #ifdefs are needed to prevent compile errors until the entire > ARCH_DAVINCI is converted. > > Also clean up the

Re: [PATCH 3/4 v2] rculist: add list_for_each_entry_from_rcu()

On Tue, May 01, 2018 at 01:11:29PM +1000, NeilBrown wrote: > > list_for_each_entry_from_rcu() is an RCU version of > list_for_each_entry_from(). It walks a linked list under rcu > protection, from a given start point. > > It is similar to list_for_each_entry_continue_rcu() but starts *at* > the

Re: [PATCH 3/4 v2] rculist: add list_for_each_entry_from_rcu()

On Tue, May 01, 2018 at 01:11:29PM +1000, NeilBrown wrote: > > list_for_each_entry_from_rcu() is an RCU version of > list_for_each_entry_from(). It walks a linked list under rcu > protection, from a given start point. > > It is similar to list_for_each_entry_continue_rcu() but starts *at* > the

Re: [PATCH v9 04/27] ARM: davinci: pass clock as parameter to davinci_timer_init()

On Friday 27 April 2018 05:47 AM, David Lechner wrote: > This changes davinci_timer_init() so that we pass the clock as a > parameter instead of using clk_get(). This is done in preparation > for converting to the common clock framework. > > It removes the requirement that we have to have a clock

Re: [PATCH v9 04/27] ARM: davinci: pass clock as parameter to davinci_timer_init()

On Friday 27 April 2018 05:47 AM, David Lechner wrote: > This changes davinci_timer_init() so that we pass the clock as a > parameter instead of using clk_get(). This is done in preparation > for converting to the common clock framework. > > It removes the requirement that we have to have a clock

[PATCH] 1wire: family module autoload fails because of upper/lower case mismatch.

1wire family module autoload fails because of upper/lower  case mismatch. Signed-off-by: Ingo Flaschberger ---  drivers/w1/w1.c | 2 +-  1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index ab0931e..aa458f2 100644 ---

[PATCH] 1wire: family module autoload fails because of upper/lower case mismatch.

1wire family module autoload fails because of upper/lower  case mismatch. Signed-off-by: Ingo Flaschberger ---  drivers/w1/w1.c | 2 +-  1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index ab0931e..aa458f2 100644 --- a/drivers/w1/w1.c +++

Re: [RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:32:32PM +0200, Krzysztof Kozlowski wrote: > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real products with it. > Remove wide-tree support for Exynos5440. > > Signed-off-by: Krzysztof Kozlowski

Re: [PATCH v2 1/2] usb: dwc3: use local copy of resource to fix-up register offset

Hi Felipe, 2018-04-19 20:03 GMT+09:00 Masahiro Yamada : > It is not a good idea to directly modify the resource of a platform > device. Modify its local copy, and pass it to devm_ioremap_resource() > so that we do not need to restore it in the failure path and the

Re: [RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:32:32PM +0200, Krzysztof Kozlowski wrote: > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real products with it. > Remove wide-tree support for Exynos5440. > > Signed-off-by: Krzysztof Kozlowski > --- >

Re: [PATCH v2 1/2] usb: dwc3: use local copy of resource to fix-up register offset

Hi Felipe, 2018-04-19 20:03 GMT+09:00 Masahiro Yamada : > It is not a good idea to directly modify the resource of a platform > device. Modify its local copy, and pass it to devm_ioremap_resource() > so that we do not need to restore it in the failure path and the remove > hook. > >

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