RE: UBIFS LEB properties tree with odd addresses

Hi Richard, >> Hmm, the calculations in lpt.c use basic properties of the MTD (number of >> blocks, etc...). >> Can you please double check which property causes the failure and also >> verify whether the MTD driver provides correct properties. i.e. page sizes, >> block size, number of blocks,

RE: UBIFS LEB properties tree with odd addresses

Hi Richard, >> Hmm, the calculations in lpt.c use basic properties of the MTD (number of >> blocks, etc...). >> Can you please double check which property causes the failure and also >> verify whether the MTD driver provides correct properties. i.e. page sizes, >> block size, number of blocks,

Re: [RFC] make kmemleak scan __ro_after_init section (was: Re: [PATCH 0/5] genetlink improvements)

On Wed, Nov 2, 2016 at 4:47 PM, Jakub Kicinski wrote: > > Thanks for looking into this! Bisect led me to the following commit: > > commit 56989f6d8568c21257dcec0f5e644d5570ba3281 > Author: Johannes Berg > Date: Mon Oct 24 14:40:05 2016 +0200 > >

Re: [RFC] make kmemleak scan __ro_after_init section (was: Re: [PATCH 0/5] genetlink improvements)

On Wed, Nov 2, 2016 at 4:47 PM, Jakub Kicinski wrote: > > Thanks for looking into this! Bisect led me to the following commit: > > commit 56989f6d8568c21257dcec0f5e644d5570ba3281 > Author: Johannes Berg > Date: Mon Oct 24 14:40:05 2016 +0200 > > genetlink: mark families as __ro_after_init

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

On Thursday 03 November 2016 02:34 AM, Anton Blanchard wrote: > Hi Ravi, > >> emulate_step() uses a number of underlying kernel functions that were >> initially not enabled for LE. This has been rectified since. So, fix >> emulate_step() for LE for the corresponding instructions. > Thanks.

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

On Thursday 03 November 2016 02:34 AM, Anton Blanchard wrote: > Hi Ravi, > >> emulate_step() uses a number of underlying kernel functions that were >> initially not enabled for LE. This has been rectified since. So, fix >> emulate_step() for LE for the corresponding instructions. > Thanks.

Re: [PATCH v7 REPOST 9/9] arm64: add sysfs cpu_capacity attribute

Hi, small update to be in sync with Russell's comments on arm correspoding patch. On 17/10/16 16:46, Juri Lelli wrote: > Add a sysfs cpu_capacity attribute with which it is possible to read and > write (thus over-writing default values) CPUs capacity. This might be > useful in situations where

Re: [PATCH v7 REPOST 9/9] arm64: add sysfs cpu_capacity attribute

Hi, small update to be in sync with Russell's comments on arm correspoding patch. On 17/10/16 16:46, Juri Lelli wrote: > Add a sysfs cpu_capacity attribute with which it is possible to read and > write (thus over-writing default values) CPUs capacity. This might be > useful in situations where

[PATCH] userns: suppress kmemleak message

We do not ever intend to unregister "user" sysctl table, unfortunately it leads kmemleak to believe that we are leaking memory: unreferenced object 0x8807383bfd48 (size 96): comm "swapper/0", pid 1, jiffies 4294894636 (age 278.320s) hex dump (first 32 bytes): a0 b4 b0 ba ff ff ff ff

[PATCH] userns: suppress kmemleak message

We do not ever intend to unregister "user" sysctl table, unfortunately it leads kmemleak to believe that we are leaking memory: unreferenced object 0x8807383bfd48 (size 96): comm "swapper/0", pid 1, jiffies 4294894636 (age 278.320s) hex dump (first 32 bytes): a0 b4 b0 ba ff ff ff ff

Re: [PATCH v7 REPOST 0/9] CPUs capacity information for heterogeneous systems

Hi Catalin, On 30/10/16 14:22, Catalin Marinas wrote: > On Mon, Oct 17, 2016 at 04:46:41PM +0100, Juri Lelli wrote: > > I'm thus now assuming that everybody is OK with the patches and that they > > can > > be queued for 4.10 (we certainly need this plumbing at this point). Please > > speak if my

Re: [PATCH v7 REPOST 0/9] CPUs capacity information for heterogeneous systems

Hi Catalin, On 30/10/16 14:22, Catalin Marinas wrote: > On Mon, Oct 17, 2016 at 04:46:41PM +0100, Juri Lelli wrote: > > I'm thus now assuming that everybody is OK with the patches and that they > > can > > be queued for 4.10 (we certainly need this plumbing at this point). Please > > speak if my

Re: net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla

On Wed, Nov 2, 2016 at 10:25 PM, Cong Wang wrote: > On Wed, Nov 2, 2016 at 5:25 PM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the following error report while running the syzkaller fuzzer: >> >>

Re: net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla

On Wed, Nov 2, 2016 at 10:25 PM, Cong Wang wrote: > On Wed, Nov 2, 2016 at 5:25 PM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the following error report while running the syzkaller fuzzer: >> >> == >> BUG: KASAN:

Re: [PATCH v7 REPOST 8/9] arm: add sysfs cpu_capacity attribute

Hi, apologies for the delay in replying, but I'm attending Linux Plumbers this week. On 30/10/16 20:45, Russell King - ARM Linux wrote: > On Mon, Oct 17, 2016 at 04:46:49PM +0100, Juri Lelli wrote: > > +#ifdef CONFIG_PROC_SYSCTL > > +#include > > +#include > > Include files at the top of the

Re: [PATCH v7 REPOST 8/9] arm: add sysfs cpu_capacity attribute

Hi, apologies for the delay in replying, but I'm attending Linux Plumbers this week. On 30/10/16 20:45, Russell King - ARM Linux wrote: > On Mon, Oct 17, 2016 at 04:46:49PM +0100, Juri Lelli wrote: > > +#ifdef CONFIG_PROC_SYSCTL > > +#include > > +#include > > Include files at the top of the

Re: net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla

On Wed, Nov 2, 2016 at 5:25 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while running the syzkaller fuzzer: > > == > BUG: KASAN: global-out-of-bounds in validate_nla+0x49b/0x4e0 at

Re: net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla

On Wed, Nov 2, 2016 at 5:25 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while running the syzkaller fuzzer: > > == > BUG: KASAN: global-out-of-bounds in validate_nla+0x49b/0x4e0 at addr >

Re: [PATCH 0/2] mmc: dw_mmc: fix the wrong operation for reset controller

Hi, On 11/02/2016 06:56 AM, John Stultz wrote: > On Sun, Oct 30, 2016 at 7:49 PM, Jaehoon Chung wrote: >> This patch adds the "reset-names" as reset controller for dwmmc controller. >> Linaro guys had reported the issue about booting stuck. >> >> Some SoCs are enabled the

Re: [PATCH 0/2] mmc: dw_mmc: fix the wrong operation for reset controller

Hi, On 11/02/2016 06:56 AM, John Stultz wrote: > On Sun, Oct 30, 2016 at 7:49 PM, Jaehoon Chung wrote: >> This patch adds the "reset-names" as reset controller for dwmmc controller. >> Linaro guys had reported the issue about booting stuck. >> >> Some SoCs are enabled the

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Wed, Nov 2, 2016 at 5:41 PM, Neri, Ricardo wrote: > On Sun, 2016-10-30 at 08:59 -0700, Dan Williams wrote: >> On Sun, Oct 30, 2016 at 5:08 AM, Thorsten Leemhuis >> wrote: >> > JFYI: I added this report to the list of regressions for Linux

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Wed, Nov 2, 2016 at 5:41 PM, Neri, Ricardo wrote: > On Sun, 2016-10-30 at 08:59 -0700, Dan Williams wrote: >> On Sun, Oct 30, 2016 at 5:08 AM, Thorsten Leemhuis >> wrote: >> > JFYI: I added this report to the list of regressions for Linux 4.9. I'll >> > watch this thread for further updates

Grant Benefit

You are a recipient to Mrs Julie Leach Donation of $2 million USD. Contact (julieleach...@gmail.com) for claims

Grant Benefit

You are a recipient to Mrs Julie Leach Donation of $2 million USD. Contact (julieleach...@gmail.com) for claims

bpf: kernel BUG in htab_elem_free

Here we go. The following program triggers kernel BUG in htab_elem_free. On commit 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31). Run as "while true; do ./a.out; done". [ cut here ] kernel BUG at mm/slub.c:3866! invalid opcode: [#1] SMP KASAN Modules linked in:

bpf: kernel BUG in htab_elem_free

Here we go. The following program triggers kernel BUG in htab_elem_free. On commit 0c183d92b20b5c84ca655b45ef57b3318b83eb9e (Oct 31). Run as "while true; do ./a.out; done". [ cut here ] kernel BUG at mm/slub.c:3866! invalid opcode: [#1] SMP KASAN Modules linked in:

Re: [PATCH V3 2/2] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

Hi Bjorn Thanks for your review. 在 2016/11/3 7:40, Bjorn Helgaas 写道: On Thu, Oct 20, 2016 at 11:10:34AM +0800, Dongdong Liu wrote: PCIe controller in Hip05/HIP06/HIP07 SoCs is not ECAM compliant. It is non ECAM only for the RC bus config space;for any other bus underneath the root bus we

Re: [PATCH V3 2/2] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

Hi Bjorn Thanks for your review. 在 2016/11/3 7:40, Bjorn Helgaas 写道: On Thu, Oct 20, 2016 at 11:10:34AM +0800, Dongdong Liu wrote: PCIe controller in Hip05/HIP06/HIP07 SoCs is not ECAM compliant. It is non ECAM only for the RC bus config space;for any other bus underneath the root bus we

[PATCH 0/2] arm64: fix the bugs found in the hugetlb test

(1) Backgroud For the arm64, the hugetlb page size can be 32M (PMD + Contiguous bit). In the 4K page environment, the max page order is 10 (max_order - 1), so 32M page is the gigantic page. The arm64 MMU supports a Contiguous bit which is a hint that the PTE is one of a set of

[PATCH 0/2] arm64: fix the bugs found in the hugetlb test

(1) Backgroud For the arm64, the hugetlb page size can be 32M (PMD + Contiguous bit). In the 4K page environment, the max page order is 10 (max_order - 1), so 32M page is the gigantic page. The arm64 MMU supports a Contiguous bit which is a hint that the PTE is one of a set of

[PATCH v5 4/8] firmware: arm_scpi: allow firmware with get_capabilities not implemented

From: Neil Armstrong On Amlogic SCPI legacy implementation, the GET_CAPABILITIES command is not supported, failover by using 0.0.0 version. Signed-off-by: Neil Armstrong [sudeep.ho...@arm.com: changed the subject] Signed-off-by: Sudeep Holla

[PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

Since SCPI is a generic protocol and the bindings are intended to be generic, we need to decouple all the platform specific binding details out of the generic bindings. This patch moves are the Juno platform specific details into a separate binding document. Cc: Rob Herring

[PATCH v5 3/8] firmware: arm_scpi: add alternative legacy structures, functions and macros

From: Neil Armstrong This patch adds support for the Legacy SCPI protocol that is available in very early JUNO versions and shipped Amlogic ARMv8 based SoCs. Some Rockchip SoC are also known to use this version of protocol with extended vendor commands. In order to

[PATCH v5 4/8] firmware: arm_scpi: allow firmware with get_capabilities not implemented

From: Neil Armstrong On Amlogic SCPI legacy implementation, the GET_CAPABILITIES command is not supported, failover by using 0.0.0 version. Signed-off-by: Neil Armstrong [sudeep.ho...@arm.com: changed the subject] Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scpi.c | 4 1 file

[PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

Since SCPI is a generic protocol and the bindings are intended to be generic, we need to decouple all the platform specific binding details out of the generic bindings. This patch moves are the Juno platform specific details into a separate binding document. Cc: Rob Herring Signed-off-by:

[PATCH v5 3/8] firmware: arm_scpi: add alternative legacy structures, functions and macros

From: Neil Armstrong This patch adds support for the Legacy SCPI protocol that is available in very early JUNO versions and shipped Amlogic ARMv8 based SoCs. Some Rockchip SoC are also known to use this version of protocol with extended vendor commands. In order to support the legacy SCPI

[PATCH v5 8/8] firmware: arm_scpi: add support for legacy SCPI compatible

This patch adds new DT match table to setup the support for legacy SCPI protocol. It aldo adds "arm,legacy-scpi" to the legacy match entry. Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scpi.c | 9 + 1 file changed, 9 insertions(+) diff --git

[PATCH v5 8/8] firmware: arm_scpi: add support for legacy SCPI compatible

This patch adds new DT match table to setup the support for legacy SCPI protocol. It aldo adds "arm,legacy-scpi" to the legacy match entry. Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scpi.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/firmware/arm_scpi.c

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

This patch adds specific compatible to support legacy SCPI protocol. Cc: Rob Herring Signed-off-by: Sudeep Holla --- Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v5 2/8] firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries

From: Neil Armstrong Since Amlogic SoCs supports more than 8 OPPs per domains, we need increase the OPP structure size. This patch increases the MAX_DVFS_OPPS to 16. Signed-off-by: Neil Armstrong Signed-off-by: Sudeep Holla

RE: [patch v2] i2c: add master driver for mellanox systems

> -Original Message- > From: Vladimir Zapolskiy [mailto:v...@mleia.com] > Sent: Thursday, November 03, 2016 1:09 AM > To: Vadim Pasternak ; w...@the-dreams.de > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; j...@resnulli.us; > Michael Shych

[PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

From: Neil Armstrong Cc: Rob Herring Signed-off-by: Neil Armstrong (decoupled from the generic scpi binding) Signed-off-by: Sudeep Holla --- .../devicetree/bindings/arm/amlogic,scpi.txt | 20

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

This patch adds specific compatible to support legacy SCPI protocol. Cc: Rob Herring Signed-off-by: Sudeep Holla --- Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt

[PATCH v5 2/8] firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries

From: Neil Armstrong Since Amlogic SoCs supports more than 8 OPPs per domains, we need increase the OPP structure size. This patch increases the MAX_DVFS_OPPS to 16. Signed-off-by: Neil Armstrong Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scpi.c | 2 +- 1 file changed, 1

RE: [patch v2] i2c: add master driver for mellanox systems

> -Original Message- > From: Vladimir Zapolskiy [mailto:v...@mleia.com] > Sent: Thursday, November 03, 2016 1:09 AM > To: Vadim Pasternak ; w...@the-dreams.de > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; j...@resnulli.us; > Michael Shych > Subject: Re: [patch v2] i2c:

[PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

From: Neil Armstrong Cc: Rob Herring Signed-off-by: Neil Armstrong (decoupled from the generic scpi binding) Signed-off-by: Sudeep Holla --- .../devicetree/bindings/arm/amlogic,scpi.txt | 20 1 file changed, 20 insertions(+) create mode 100644

[PATCH v5 1/8] firmware: arm_scpi: add command indirection to support legacy commands

Since the legacy SCPI and the SCPI v1.0 differ in the command values, it's better to create some sort of command indirection in the driver to avoid repeated version check at multiple places. This patch adds the indirection command table to allow different values of the command across SCPI

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

Hi, This is minor rework of the series[1] from Neil Armstrong's to support legacy SCPI protocol to make DT bindings more generic and move out all the platform specific bindings out of the generic binding document. -- Regards, Sudeep [1] http://www.spinics.net/lists/arm-kernel/msg534999.html

[PATCH v5 1/8] firmware: arm_scpi: add command indirection to support legacy commands

Since the legacy SCPI and the SCPI v1.0 differ in the command values, it's better to create some sort of command indirection in the driver to avoid repeated version check at multiple places. This patch adds the indirection command table to allow different values of the command across SCPI

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

Hi, This is minor rework of the series[1] from Neil Armstrong's to support legacy SCPI protocol to make DT bindings more generic and move out all the platform specific bindings out of the generic binding document. -- Regards, Sudeep [1] http://www.spinics.net/lists/arm-kernel/msg534999.html

Re: [PATCH v4 10/10] IB/mlx5: Simplify completion into a wait_event

On Sun, Oct 30, 2016 at 11:17:57PM +0200, Sagi Grimberg wrote: > > > On 27/10/16 09:59, Binoy Jayan wrote: > >Convert the completion 'mlx5_ib_umr_context:done' to a wait_event as it > >just waits for the return value to be filled. On top of Sagi's response, I'm failing to understand why it is

Re: [PATCH v4 10/10] IB/mlx5: Simplify completion into a wait_event

On Sun, Oct 30, 2016 at 11:17:57PM +0200, Sagi Grimberg wrote: > > > On 27/10/16 09:59, Binoy Jayan wrote: > >Convert the completion 'mlx5_ib_umr_context:done' to a wait_event as it > >just waits for the return value to be filled. On top of Sagi's response, I'm failing to understand why it is

Re: [PATCH v4 6/8] dt-bindings: Add support for Amlogic GXBB SCPI Interface

On 02/11/16 21:51, Rob Herring wrote: On Wed, Nov 2, 2016 at 5:20 PM, Sudeep Holla wrote: On Sat, Oct 29, 2016 at 11:39:05AM -0700, Olof Johansson wrote: Hi, On Wed, Oct 5, 2016 at 12:33 AM, Neil Armstrong wrote: Acked-by: Rob Herring

Re: [PATCH v4 6/8] dt-bindings: Add support for Amlogic GXBB SCPI Interface

On 02/11/16 21:51, Rob Herring wrote: On Wed, Nov 2, 2016 at 5:20 PM, Sudeep Holla wrote: On Sat, Oct 29, 2016 at 11:39:05AM -0700, Olof Johansson wrote: Hi, On Wed, Oct 5, 2016 at 12:33 AM, Neil Armstrong wrote: Acked-by: Rob Herring Signed-off-by: Neil Armstrong ---

Re: [Qemu-devel] [PATCH v9 04/12] vfio iommu: Add support for mediated devices

On 03/11/16 00:18, Kirti Wankhede wrote: > > > On 11/2/2016 6:30 PM, Jike Song wrote: >> On 11/02/2016 08:41 PM, Kirti Wankhede wrote: >>> On 11/2/2016 5:51 PM, Jike Song wrote: On 11/02/2016 12:09 PM, Alexey Kardashevskiy wrote: > Or you could just reference and use @mm as KVM and

Re: [Qemu-devel] [PATCH v9 04/12] vfio iommu: Add support for mediated devices

On 03/11/16 00:18, Kirti Wankhede wrote: > > > On 11/2/2016 6:30 PM, Jike Song wrote: >> On 11/02/2016 08:41 PM, Kirti Wankhede wrote: >>> On 11/2/2016 5:51 PM, Jike Song wrote: On 11/02/2016 12:09 PM, Alexey Kardashevskiy wrote: > Or you could just reference and use @mm as KVM and

Re: [PATCH] ARM: davinci: da850: Fix pwm name matching

On 11/01/2016 05:31 AM, Sekhar Nori wrote: On Monday 31 October 2016 08:18 PM, David Lechner wrote: On 10/31/2016 05:18 AM, Sekhar Nori wrote: On Tuesday 25 October 2016 11:24 PM, David Lechner wrote: This fixes pwm name matching for DA850 familiy devices. When using device tree, the

Re: [PATCH] ARM: davinci: da850: Fix pwm name matching

On 11/01/2016 05:31 AM, Sekhar Nori wrote: On Monday 31 October 2016 08:18 PM, David Lechner wrote: On 10/31/2016 05:18 AM, Sekhar Nori wrote: On Tuesday 25 October 2016 11:24 PM, David Lechner wrote: This fixes pwm name matching for DA850 familiy devices. When using device tree, the

Re: [PATCH] acer-wmi: only supports AMW0_GUID1 on acer family

On Thu, Nov 03, 2016 at 11:40:15AM +0800, Anthony Wong wrote: > On 1 November 2016 at 12:30, Lee, Chun-Yi wrote: > > > > The AMW0_GUID1 wmi is not only found on Acer family but also other > > machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi > > driver

Re: [PATCH] acer-wmi: only supports AMW0_GUID1 on acer family

On Thu, Nov 03, 2016 at 11:40:15AM +0800, Anthony Wong wrote: > On 1 November 2016 at 12:30, Lee, Chun-Yi wrote: > > > > The AMW0_GUID1 wmi is not only found on Acer family but also other > > machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi > > driver handled those non-Acer

Reimbursement Payment of USD1.5M Approved, Email: (help.andyo...@gmail.com)

Congratulations Beneficiary, You a recipient of USD1.5M Yours Faithfully, Mr. Wu Hongbo Under-Secretary-General for Economic and Social Affairs

Reimbursement Payment of USD1.5M Approved, Email: (help.andyo...@gmail.com)

Congratulations Beneficiary, You a recipient of USD1.5M Yours Faithfully, Mr. Wu Hongbo Under-Secretary-General for Economic and Social Affairs

Reimbursement Payment of USD1.5M Approved, Email: (help.andyo...@gmail.com)

Reimbursement Payment of USD1.5M Approved, Email: (help.andyo...@gmail.com)

[PATCH 2/2] arm64: hugetlb: fix the wrong address for several functions

The libhugetlbfs meets several failures since the following functions do not use the correct address: huge_ptep_get_and_clear() huge_ptep_set_access_flags() huge_ptep_set_wrprotect() huge_ptep_clear_flush() This patch fixes the wrong address for them. Acked-by: Steve Capper

[PATCH 2/2] arm64: hugetlb: fix the wrong address for several functions

The libhugetlbfs meets several failures since the following functions do not use the correct address: huge_ptep_get_and_clear() huge_ptep_set_access_flags() huge_ptep_set_wrprotect() huge_ptep_clear_flush() This patch fixes the wrong address for them. Acked-by: Steve Capper

Re: [PATCH v4 6/8] dt-bindings: Add support for Amlogic GXBB SCPI Interface

On Wed, Nov 2, 2016 at 5:20 PM, Sudeep Holla wrote: > On Sat, Oct 29, 2016 at 11:39:05AM -0700, Olof Johansson wrote: >> Hi, >> >> >> On Wed, Oct 5, 2016 at 12:33 AM, Neil Armstrong >> wrote: >> > Acked-by: Rob Herring >> >

Re: [PATCH v4 6/8] dt-bindings: Add support for Amlogic GXBB SCPI Interface

On Wed, Nov 2, 2016 at 5:20 PM, Sudeep Holla wrote: > On Sat, Oct 29, 2016 at 11:39:05AM -0700, Olof Johansson wrote: >> Hi, >> >> >> On Wed, Oct 5, 2016 at 12:33 AM, Neil Armstrong >> wrote: >> > Acked-by: Rob Herring >> > Signed-off-by: Neil Armstrong >> > --- >> >

Re: [PATCH] acer-wmi: only supports AMW0_GUID1 on acer family

On 1 November 2016 at 12:30, Lee, Chun-Yi wrote: > > The AMW0_GUID1 wmi is not only found on Acer family but also other > machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi > driver handled those non-Acer machines by quirks list. > > But actually

Re: [PATCH] acer-wmi: only supports AMW0_GUID1 on acer family

On 1 November 2016 at 12:30, Lee, Chun-Yi wrote: > > The AMW0_GUID1 wmi is not only found on Acer family but also other > machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi > driver handled those non-Acer machines by quirks list. > > But actually acer-wmi driver was loaded on

[PATCH] clk: rockchip: remove more CLK_IGNORE_UNUSED for rk3399 clocktree

Optimize rk3399 clocktree by removing CLK_IGNORE_UNUSED of some clocks. clocks will managered by usb: - clk_usbphy0_480m_src - clk_usbphy1_480m_src - clk_usbphy_480m clocks will be managered by pvtm: - clk_pvtm_core_l - clk_pvtm_core_b - clk_pvtm_ddr clocks will be managered by dfi: -

[PATCH] clk: rockchip: remove more CLK_IGNORE_UNUSED for rk3399 clocktree

Optimize rk3399 clocktree by removing CLK_IGNORE_UNUSED of some clocks. clocks will managered by usb: - clk_usbphy0_480m_src - clk_usbphy1_480m_src - clk_usbphy_480m clocks will be managered by pvtm: - clk_pvtm_core_l - clk_pvtm_core_b - clk_pvtm_ddr clocks will be managered by dfi: -

Re: [PATCH v2] of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible.

On Fri, Oct 28, 2016 at 4:15 PM, David Daney wrote: > From: David Daney > > On arm64 NUMA kernels we can pass "numa=off" on the command line to > disable NUMA. A side effect of this is that kmalloc_node() calls to > non-zero nodes will crash the

Re: [PATCH v2] of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible.

On Fri, Oct 28, 2016 at 4:15 PM, David Daney wrote: > From: David Daney > > On arm64 NUMA kernels we can pass "numa=off" on the command line to > disable NUMA. A side effect of this is that kmalloc_node() calls to > non-zero nodes will crash the system with an OOPS: > > [0.00]

[RESEND][PATCH 0/2 v4] Audio support for adv7511 hdmi bridge

Just wanted to resend the adv7511 hdmi bridge audio support for review and consideration for merging. I've taken the core audio work done by Lars-Peter Clausen, and adapted by Srinivas Kandagatla and Archit Taneja, and tried to rework it to use the hdmi-codec sound driver. This patchset, along

[RESEND][PATCH 1/2 v4] drm/bridge: adv7511: Add Audio support.

This patch adds support to Audio for both adv7511 and adv7533 bridge chips. This patch was originally from [1] by Lars-Peter Clausen and was adapted by Archit Taneja and Srinivas Kandagatla . Then I heavily reworked it to

[RESEND][PATCH 2/2 v4] drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

From: Srinivas Kandagatla This patch enables the Audio Data and Clock pads to the adv7533 bridge. Without this patch audio can not be played. Cc: David Airlie Cc: Archit Taneja Cc: Laurent Pinchart

[RESEND][PATCH 0/2 v4] Audio support for adv7511 hdmi bridge

Just wanted to resend the adv7511 hdmi bridge audio support for review and consideration for merging. I've taken the core audio work done by Lars-Peter Clausen, and adapted by Srinivas Kandagatla and Archit Taneja, and tried to rework it to use the hdmi-codec sound driver. This patchset, along

[RESEND][PATCH 1/2 v4] drm/bridge: adv7511: Add Audio support.

This patch adds support to Audio for both adv7511 and adv7533 bridge chips. This patch was originally from [1] by Lars-Peter Clausen and was adapted by Archit Taneja and Srinivas Kandagatla . Then I heavily reworked it to use the hdmi-codec driver. And also folded in some audio packet

[RESEND][PATCH 2/2 v4] drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

From: Srinivas Kandagatla This patch enables the Audio Data and Clock pads to the adv7533 bridge. Without this patch audio can not be played. Cc: David Airlie Cc: Archit Taneja Cc: Laurent Pinchart Cc: Wolfram Sang Cc: Srinivas Kandagatla Cc: "Ville Syrjälä" Cc: Boris Brezillon Cc: Andy

[PATCH net] netlink: netlink_diag_dump() runs without locks

From: Eric Dumazet A recent commit removed locking from netlink_diag_dump() but forgot one error case. = [ BUG: bad unlock balance detected! ] 4.9.0-rc3+ #336 Not tainted - syz-executor/4018 is trying

[PATCH net] netlink: netlink_diag_dump() runs without locks

From: Eric Dumazet A recent commit removed locking from netlink_diag_dump() but forgot one error case. = [ BUG: bad unlock balance detected! ] 4.9.0-rc3+ #336 Not tainted - syz-executor/4018 is trying to release lock ([

Re: [PATCH v3 2/3] mm: add LSM hook for writes to readonly memory

On Thu, Nov 03, 2016 at 04:04:45AM +0100, Jann Horn wrote: > SELinux attempts to make it possible to whitelist trustworthy sources of > code that may be mapped into memory, and Android makes use of this feature. > To prevent an attacker from bypassing this by modifying R+X memory through >

Re: [PATCH v3 2/3] mm: add LSM hook for writes to readonly memory

On Thu, Nov 03, 2016 at 04:04:45AM +0100, Jann Horn wrote: > SELinux attempts to make it possible to whitelist trustworthy sources of > code that may be mapped into memory, and Android makes use of this feature. > To prevent an attacker from bypassing this by modifying R+X memory through >

Re: net/netlink: null-ptr-deref in netlink_dump/lock_acquire

Hi Eric, This fixes the second report, the first one is still there. Apparently these are two separate issues. For the second one: Tested-by: Andrey Konovalov Thanks for the fix! On Thu, Nov 3, 2016 at 3:58 AM, Eric Dumazet wrote: > On Thu,

Re: net/netlink: null-ptr-deref in netlink_dump/lock_acquire

Hi Eric, This fixes the second report, the first one is still there. Apparently these are two separate issues. For the second one: Tested-by: Andrey Konovalov Thanks for the fix! On Thu, Nov 3, 2016 at 3:58 AM, Eric Dumazet wrote: > On Thu, 2016-11-03 at 03:36 +0100, Andrey Konovalov wrote:

[PATCH 2/3] mm: add LSM hook for writes to readonly memory

SELinux attempts to make it possible to whitelist trustworthy sources of code that may be mapped into memory, and Android makes use of this feature. To prevent an attacker from bypassing this by modifying R+X memory through /proc/$pid/mem, PTRACE_POKETEXT or DMA, it is necessary to call a security

[PATCH 2/3] mm: add LSM hook for writes to readonly memory

SELinux attempts to make it possible to whitelist trustworthy sources of code that may be mapped into memory, and Android makes use of this feature. To prevent an attacker from bypassing this by modifying R+X memory through /proc/$pid/mem, PTRACE_POKETEXT or DMA, it is necessary to call a security

[PATCH 3/3] selinux: require EXECMEM for forced ptrace poke

This restricts forced writes to private R+X mappings using the EXECMEM permission. To avoid a breaking change, a new policy capability needs to be enabled before the new restrictions take effect. Unlike most other SELinux hooks, this one takes the subject credentials as an argument instead of

[PATCH v3 1/3] fs/exec: don't force writing memory access

This shouldn't change behavior in any way - at this point, there should be no non-writable mappings, only the initial stack mapping -, but this change makes it easier to reason about the correctness of the following commits that place restrictions on forced memory writes. Signed-off-by: Jann Horn

[PATCH 3/3] selinux: require EXECMEM for forced ptrace poke

This restricts forced writes to private R+X mappings using the EXECMEM permission. To avoid a breaking change, a new policy capability needs to be enabled before the new restrictions take effect. Unlike most other SELinux hooks, this one takes the subject credentials as an argument instead of

[PATCH v3 1/3] fs/exec: don't force writing memory access

This shouldn't change behavior in any way - at this point, there should be no non-writable mappings, only the initial stack mapping -, but this change makes it easier to reason about the correctness of the following commits that place restrictions on forced memory writes. Signed-off-by: Jann Horn

[PATCH v3 3/3] selinux: require EXECMEM for forced ptrace poke

This restricts forced writes to private R+X mappings using the EXECMEM permission. To avoid a breaking change, a new policy capability needs to be enabled before the new restrictions take effect. Unlike most other SELinux hooks, this one takes the subject credentials as an argument instead of

[PATCH v3 2/3] mm: add LSM hook for writes to readonly memory

SELinux attempts to make it possible to whitelist trustworthy sources of code that may be mapped into memory, and Android makes use of this feature. To prevent an attacker from bypassing this by modifying R+X memory through /proc/$pid/mem, PTRACE_POKETEXT or DMA, it is necessary to call a security

[PATCH v3 3/3] selinux: require EXECMEM for forced ptrace poke

This restricts forced writes to private R+X mappings using the EXECMEM permission. To avoid a breaking change, a new policy capability needs to be enabled before the new restrictions take effect. Unlike most other SELinux hooks, this one takes the subject credentials as an argument instead of

[PATCH v3 2/3] mm: add LSM hook for writes to readonly memory

SELinux attempts to make it possible to whitelist trustworthy sources of code that may be mapped into memory, and Android makes use of this feature. To prevent an attacker from bypassing this by modifying R+X memory through /proc/$pid/mem, PTRACE_POKETEXT or DMA, it is necessary to call a security

[PATCH 1/3] fs/exec: don't force writing memory access

This shouldn't change behavior in any way - at this point, there should be no non-writable mappings, only the initial stack mapping -, but this change makes it easier to reason about the correctness of the following commits that place restrictions on forced memory writes. Signed-off-by: Jann Horn

[PATCH 1/3] fs/exec: don't force writing memory access

This shouldn't change behavior in any way - at this point, there should be no non-writable mappings, only the initial stack mapping -, but this change makes it easier to reason about the correctness of the following commits that place restrictions on forced memory writes. Signed-off-by: Jann Horn

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

From: Larry Finger Date: Wed, 2 Nov 2016 20:00:03 -0500 > On 10/30/2016 05:21 AM, John Heenan wrote: >> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to >> set >> macpower, is never 0xea. It is only ever 0x01 (first time after >> modprobe) >>

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

From: Larry Finger Date: Wed, 2 Nov 2016 20:00:03 -0500 > On 10/30/2016 05:21 AM, John Heenan wrote: >> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to >> set >> macpower, is never 0xea. It is only ever 0x01 (first time after >> modprobe) >> using wpa_supplicant and 0x00

  1   2   3   4   5   6   7   8   9   10   >