Fail to build Linux with O= in master

Hello, I have tried to build the latest master and got the following error: 42sh> make O=~/works/linux-build/aarch64-4k -C ~/works/linux make: Entering directory '/home/julgra01/works/linux'

[PATCH] phy: rockchip-typec: Check for errors from tcphy_phy_init()

The function tcphy_phy_init() could return an error but the callers weren't checking the return value. They should. In at least one case while testing I saw the message "wait pma ready timeout" which indicates that tcphy_phy_init() really could return an error and we should account for it.

Fail to build Linux with O= in master

Hello, I have tried to build the latest master and got the following error: 42sh> make O=~/works/linux-build/aarch64-4k -C ~/works/linux make: Entering directory '/home/julgra01/works/linux'

[PATCH] phy: rockchip-typec: Check for errors from tcphy_phy_init()

The function tcphy_phy_init() could return an error but the callers weren't checking the return value. They should. In at least one case while testing I saw the message "wait pma ready timeout" which indicates that tcphy_phy_init() really could return an error and we should account for it.

Re: [PATCH 02/12] Input: ad7879 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:29AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 02/12] Input: ad7879 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:29AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 04/12] Input: atmel_mxt_ts - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:31AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group. > > CC: Nick Dyer

Re: [PATCH 04/12] Input: atmel_mxt_ts - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:31AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group. > > CC: Nick Dyer >

Re: [PATCH 03/12] Input: ads7846 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:30AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

Re: [PATCH 03/12] Input: ads7846 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:30AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

Re: [PATCH 07/12] Input: ili210x - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:34AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

Re: [PATCH 07/12] Input: ili210x - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:34AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

Re: [PATCH 11/12] Input: tsc200x-core - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:38AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

Re: [PATCH 11/12] Input: tsc200x-core - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:38AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

Re: [PATCH] kvm/x86: Handle async PF in RCU read-side critical sections

On Fri, Sep 29, 2017 at 04:43:39PM +, Paul E. McKenney wrote: > On Fri, Sep 29, 2017 at 04:53:57PM +0200, Paolo Bonzini wrote: > > On 29/09/2017 13:01, Boqun Feng wrote: > > > Sasha Levin reported a WARNING: > > > > > > | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 > > > |

Re: [PATCH] kvm/x86: Handle async PF in RCU read-side critical sections

On Fri, Sep 29, 2017 at 04:43:39PM +, Paul E. McKenney wrote: > On Fri, Sep 29, 2017 at 04:53:57PM +0200, Paolo Bonzini wrote: > > On 29/09/2017 13:01, Boqun Feng wrote: > > > Sasha Levin reported a WARNING: > > > > > > | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 > > > |

Re: [PATCH 05/12] Input: edt-ft5x06 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:32AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

Re: [PATCH 05/12] Input: edt-ft5x06 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:32AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

Re: [PATCH 12/12] Input: wdt87xx_i2c - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:39AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

Re: [PATCH 12/12] Input: wdt87xx_i2c - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:39AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the relative

[PATCH] PCI / PM: Add dev_dbg() to print device suspend power states

From: Rafael J. Wysocki It sometimes is useful to know what power states the kernel thinks it puts PCI devices into during system suspend, so add a dev_dbg() statement for that. Signed-off-by: Rafael J. Wysocki ---

[PATCH] PCI / PM: Add dev_dbg() to print device suspend power states

From: Rafael J. Wysocki It sometimes is useful to know what power states the kernel thinks it puts PCI devices into during system suspend, so add a dev_dbg() statement for that. Signed-off-by: Rafael J. Wysocki --- drivers/pci/pci-driver.c |3 +++ 1 file changed, 3 insertions(+) Index:

Re: [PATCH 10/12] Input: rohm_bu21023 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:37AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 10/12] Input: rohm_bu21023 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:37AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 09/12] Input: raydium_i2c_ts - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:36AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 09/12] Input: raydium_i2c_ts - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:36AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 08/12] Input: melfas_mip4 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:35AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 08/12] Input: melfas_mip4 - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:35AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 06/12] Input: elants_i2c - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:33AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 06/12] Input: elants_i2c - use managed devm_device_add_group

On Sat, Sep 30, 2017 at 05:38:33AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the action that

Re: [PATCH 01/12] Input: ad7897 - use managed devm_device_add_group

Hi Andi, On Sat, Sep 30, 2017 at 05:38:28AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the

Re: [PATCH 01/12] Input: ad7897 - use managed devm_device_add_group

Hi Andi, On Sat, Sep 30, 2017 at 05:38:28AM +0900, Andi Shyti wrote: > Commit 57b8ff070f98 ("driver core: add devm_device_add_group() > and friends") has added the the managed version for creating > sysfs group files. > > Use devm_device_add_group instead of sysfs_create_group and > remove the

Re: [PATCH v2 1/7] driver core: emit uevents when device is bound to a driver

On Fri, Sep 29, 2017 at 07:40:15PM +, Ruhl, Michael J wrote: > > -Original Message- > > From: dan.j.willi...@gmail.com [mailto:dan.j.willi...@gmail.com] On > > Behalf Of Dan Williams > > Sent: Friday, September 29, 2017 3:37 PM > > To: Dmitry Torokhov > >

Re: [PATCH v2 1/7] driver core: emit uevents when device is bound to a driver

On Fri, Sep 29, 2017 at 07:40:15PM +, Ruhl, Michael J wrote: > > -Original Message- > > From: dan.j.willi...@gmail.com [mailto:dan.j.willi...@gmail.com] On > > Behalf Of Dan Williams > > Sent: Friday, September 29, 2017 3:37 PM > > To: Dmitry Torokhov > > Cc: Greg Kroah-Hartman ;

Re: [PATCH RFC hack dont apply] intel_idle: support running within a VM

On Sat, Sep 30, 2017 at 12:01 AM, Michael S. Tsirkin wrote: > intel idle driver does not DTRT when running within a VM: > when going into a deep power state, the right thing to > do is to exit to hypervisor rather than to keep polling > within guest using mwait. > > Currently the

Re: [PATCH RFC hack dont apply] intel_idle: support running within a VM

On Sat, Sep 30, 2017 at 12:01 AM, Michael S. Tsirkin wrote: > intel idle driver does not DTRT when running within a VM: > when going into a deep power state, the right thing to > do is to exit to hypervisor rather than to keep polling > within guest using mwait. > > Currently the solution is just

[PATCH] m32r: fix build failure

L_RELA against undefined symbol 'abort' The function 'abort' was never defined for the m32r architecture. Create 'abort' as is done in other arch like 'arm' and 'unicore32'. Signed-off-by: Sudip Mukherjee <sudipm.mukher...@gmail.com> --- The build log of next-20170929 is at: https://t

[PATCH] m32r: fix build failure

'abort' The function 'abort' was never defined for the m32r architecture. Create 'abort' as is done in other arch like 'arm' and 'unicore32'. Signed-off-by: Sudip Mukherjee --- The build log of next-20170929 is at: https://travis-ci.org/sudipm-mukherjee/parport/jobs/281164217 arch/m32r/kernel

Re: [PATCH 7/7] fs-writeback: only allow one inflight and pending full flush

On 09/28/2017 08:09 PM, Jens Axboe wrote: > On 09/25/2017 11:35 AM, Jan Kara wrote: >> On Thu 21-09-17 10:00:25, Jens Axboe wrote: >>> On 09/21/2017 09:36 AM, Jens Axboe wrote: > But more importantly once we are not guaranteed that we only have > a single global wb_writeback_work per

Re: [PATCH 7/7] fs-writeback: only allow one inflight and pending full flush

On 09/28/2017 08:09 PM, Jens Axboe wrote: > On 09/25/2017 11:35 AM, Jan Kara wrote: >> On Thu 21-09-17 10:00:25, Jens Axboe wrote: >>> On 09/21/2017 09:36 AM, Jens Axboe wrote: > But more importantly once we are not guaranteed that we only have > a single global wb_writeback_work per

[PATCH 2/2] userns: control capabilities of some user namespaces

From: Mahesh Bandewar With this new notion of "controlled" user-namespaces, the controlled user-namespaces are marked at the time of their creation while the capabilities of processes that belong to them are controlled using the global mask. Init-user-ns is always

[PATCH 2/2] userns: control capabilities of some user namespaces

From: Mahesh Bandewar With this new notion of "controlled" user-namespaces, the controlled user-namespaces are marked at the time of their creation while the capabilities of processes that belong to them are controlled using the global mask. Init-user-ns is always uncontrolled and a process

[PATCH 0/2] capability controlled user-namespaces

From: Mahesh Bandewar [Same as the previous RFC series sent on 9/21] TL;DR version - Creating a sandbox environment with namespaces is challenging considering what these sandboxed processes can engage into. e.g. CVE-2017-6074, CVE-2017-7184, CVE-2017-7308 etc.

[PATCH 1/2] capability: introduce sysctl for controlled user-ns capability whitelist

From: Mahesh Bandewar Add a sysctl variable kernel.controlled_userns_caps_whitelist. This takes input as capability mask expressed as two comma separated hex u32 words. The mask, however, is stored in kernel as kernel_cap_t type. Any capabilities that are not part of this

[PATCH 1/2] capability: introduce sysctl for controlled user-ns capability whitelist

From: Mahesh Bandewar Add a sysctl variable kernel.controlled_userns_caps_whitelist. This takes input as capability mask expressed as two comma separated hex u32 words. The mask, however, is stored in kernel as kernel_cap_t type. Any capabilities that are not part of this mask will be

[PATCH 0/2] capability controlled user-namespaces

From: Mahesh Bandewar [Same as the previous RFC series sent on 9/21] TL;DR version - Creating a sandbox environment with namespaces is challenging considering what these sandboxed processes can engage into. e.g. CVE-2017-6074, CVE-2017-7184, CVE-2017-7308 etc. just to name few.

Re: Problems compiling with KCFLAGS="-frecord-gcc-switches"

On 09/29/2017 01:58 PM, Josh Poimboeuf wrote: On Fri, Sep 29, 2017 at 01:38:43PM -0700, Guenter Roeck wrote: On Fri, Sep 29, 2017 at 01:00:56PM -0700, Guenter Roeck wrote: Hi Josh, when trying to compile an image with KCFLAGS="-frecord-gcc-switches", I get the folllowing build warning/error.

Re: Problems compiling with KCFLAGS="-frecord-gcc-switches"

On 09/29/2017 01:58 PM, Josh Poimboeuf wrote: On Fri, Sep 29, 2017 at 01:38:43PM -0700, Guenter Roeck wrote: On Fri, Sep 29, 2017 at 01:00:56PM -0700, Guenter Roeck wrote: Hi Josh, when trying to compile an image with KCFLAGS="-frecord-gcc-switches", I get the folllowing build warning/error.

[Part1 PATCH v5 18/18] x86/mm: add 'sme' argument in mem_encrypt=

The mem_encrypt=on activates both SME and SEV. Add a new argument to disable the SEV and allow SME. The argument can be useful when SEV has issues and we want to disable it. early_detect_mem_encrypt() [cpu/amd.com] will need to know the state of the mem_encrypt= argument. Since

[Part1 PATCH v5 18/18] x86/mm: add 'sme' argument in mem_encrypt=

The mem_encrypt=on activates both SME and SEV. Add a new argument to disable the SEV and allow SME. The argument can be useful when SEV has issues and we want to disable it. early_detect_mem_encrypt() [cpu/amd.com] will need to know the state of the mem_encrypt= argument. Since

Re: Read-only `slaves` with shared subtrees?

On Fri, Sep 22, 2017 at 11:43 AM, Dawid Ciezarkiewicz wrote: > On Thu, Sep 21, 2017 at 12:14 PM, Ram Pai wrote: >> Here is a patch that accomplishes the job. tested to work with >> some simple use cases. check if this works for you. If it

Re: Read-only `slaves` with shared subtrees?

On Fri, Sep 22, 2017 at 11:43 AM, Dawid Ciezarkiewicz wrote: > On Thu, Sep 21, 2017 at 12:14 PM, Ram Pai wrote: >> Here is a patch that accomplishes the job. tested to work with >> some simple use cases. check if this works for you. If it does >> than we will have to think through all the edge

Re: [PATCH 1/2] block: genhd: add device_add_disk_with_groups

On Thu, Sep 28, 2017 at 09:36:36PM +0200, Martin Wilck wrote: > In the NVME subsystem, we're seeing a race condition with udev where > device_add_disk() is called (which triggers an "add" uevent), and a > sysfs attribute group is added to the disk device afterwards. > If udev rules access these

Re: [PATCH 1/2] block: genhd: add device_add_disk_with_groups

On Thu, Sep 28, 2017 at 09:36:36PM +0200, Martin Wilck wrote: > In the NVME subsystem, we're seeing a race condition with udev where > device_add_disk() is called (which triggers an "add" uevent), and a > sysfs attribute group is added to the disk device afterwards. > If udev rules access these

Re: [PATCH 2/2] nvme: use device_add_disk_with_groups()

On Thu, Sep 28, 2017 at 09:36:37PM +0200, Martin Wilck wrote: > By using device_add_disk_with_groups(), we can avoid the race > condition with udev rule processing, because no udev event will > be triggered before all attributes are available. > > Signed-off-by: Martin Wilck

Re: [PATCH 2/2] nvme: use device_add_disk_with_groups()

On Thu, Sep 28, 2017 at 09:36:37PM +0200, Martin Wilck wrote: > By using device_add_disk_with_groups(), we can avoid the race > condition with udev rule processing, because no udev event will > be triggered before all attributes are available. > > Signed-off-by: Martin Wilck Looks good.

Re: [Patch v2 1/2] libiscsi: Fix use-after-free race during iscsi_session_teardown

Noticed these don't seem to be in 4.14/scsi-queue On Tue, Aug 29, 2017 at 6:45 PM, Martin K. Petersen wrote: > > Chris, > >> Looks good to me, fixes up the code given that the comment there about >> calling iscsi_remove_session wasn't being followed. > > Applied these

Re: [Patch v2 1/2] libiscsi: Fix use-after-free race during iscsi_session_teardown

Noticed these don't seem to be in 4.14/scsi-queue On Tue, Aug 29, 2017 at 6:45 PM, Martin K. Petersen wrote: > > Chris, > >> Looks good to me, fixes up the code given that the comment there about >> calling iscsi_remove_session wasn't being followed. > > Applied these two to 4.14/scsi-queue. > >

Re: [PATCH V4 1/1] clk: bulk: add of_clk_bulk_get()

On 09/26, Dong Aisheng wrote: > 'clock-names' property is optinal in DT, so of_clk_bulk_get() is introduced s/optinal/optional/ > here to handle this for DT users without 'clock-names' specified. > > Cc: Stephen Boyd > Cc: Michael Turquette > Cc:

Re: [PATCH V4 1/1] clk: bulk: add of_clk_bulk_get()

On 09/26, Dong Aisheng wrote: > 'clock-names' property is optinal in DT, so of_clk_bulk_get() is introduced s/optinal/optional/ > here to handle this for DT users without 'clock-names' specified. > > Cc: Stephen Boyd > Cc: Michael Turquette > Cc: Russell King > Reported-by: Shawn Guo >

[PATCH] HID: i2c-hid: Use device properties (instead of device tree)

Use the device properties (that can be provided by ACPI systems as well as non ACPI systems) instead of device tree properties (that are not provided ACPI systems). This required some minor code restructuring. Signed-off-by: Rajat Jain --- I don't think its a big deal, but

[PATCH] HID: i2c-hid: Use device properties (instead of device tree)

Use the device properties (that can be provided by ACPI systems as well as non ACPI systems) instead of device tree properties (that are not provided ACPI systems). This required some minor code restructuring. Signed-off-by: Rajat Jain --- I don't think its a big deal, but just FYI, this changes

Re: [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On 09/29/2017 07:19 AM, Borislav Petkov wrote: ... This one was in the Part1 set, right? It landed here for whatever reason... Part1 is based on tip/master and Part2 is based on kvm/master. With the current division, we should be able to compile and run part1 and part2 independently.

Re: [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On 09/29/2017 07:19 AM, Borislav Petkov wrote: ... This one was in the Part1 set, right? It landed here for whatever reason... Part1 is based on tip/master and Part2 is based on kvm/master. With the current division, we should be able to compile and run part1 and part2 independently.

[PATCH] binder: fix use-after-free in binder_transaction()

User-space normally keeps the node alive when creating a transaction since it has a reference to the target. The local strong ref keeps it alive if the sending process dies before the target process processes the transaction. If the source process is malicious or has a reference counting bug, this

[PATCH] binder: fix use-after-free in binder_transaction()

User-space normally keeps the node alive when creating a transaction since it has a reference to the target. The local strong ref keeps it alive if the sending process dies before the target process processes the transaction. If the source process is malicious or has a reference counting bug, this

[PATCH 4/7] bus: ti-sysc: Add minimal TI sysc interconnect target driver

We can handle the sysc interconnect target module in a generic way for many TI SoCs. Initially let's just enable runtime PM with autosuspend, and probe the children. This can already be used for idling interconnect target modules that don't have any device driver available for the child devices.

[PATCH 4/7] bus: ti-sysc: Add minimal TI sysc interconnect target driver

We can handle the sysc interconnect target module in a generic way for many TI SoCs. Initially let's just enable runtime PM with autosuspend, and probe the children. This can already be used for idling interconnect target modules that don't have any device driver available for the child devices.

Re: [PATCH v5 6/7] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Thu, 28 Sep 2017 15:09:50 +0100 Will Deacon wrote: > +/* Perf callbacks */ > +static int arm_spe_pmu_event_init(struct perf_event *event) > +{ > + u64 reg; > + struct perf_event_attr *attr = >attr; > + struct arm_spe_pmu *spe_pmu = to_spe_pmu(event->pmu); > +

Re: [PATCH v5 6/7] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Thu, 28 Sep 2017 15:09:50 +0100 Will Deacon wrote: > +/* Perf callbacks */ > +static int arm_spe_pmu_event_init(struct perf_event *event) > +{ > + u64 reg; > + struct perf_event_attr *attr = >attr; > + struct arm_spe_pmu *spe_pmu = to_spe_pmu(event->pmu); > + > + /* This is,

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

On 9/28/17 1:45 PM, Tetsuo Handa wrote: Yang Shi wrote: On 9/28/17 12:57 PM, Tetsuo Handa wrote: Yang Shi wrote: On 9/27/17 9:36 PM, Tetsuo Handa wrote: On 2017/09/28 6:46, Yang Shi wrote: Changelog v7 -> v8: * Adopted Michal’s suggestion to dump unreclaim slab info when unreclaimable

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

On 9/28/17 1:45 PM, Tetsuo Handa wrote: Yang Shi wrote: On 9/28/17 12:57 PM, Tetsuo Handa wrote: Yang Shi wrote: On 9/27/17 9:36 PM, Tetsuo Handa wrote: On 2017/09/28 6:46, Yang Shi wrote: Changelog v7 -> v8: * Adopted Michal’s suggestion to dump unreclaim slab info when unreclaimable

[PATCH] ASoC: rockchip: Allocate enough memory so we don't overflow routes

In the recent commit d9f9c167edae ("ASoC: rockchip: Init dapm routes dynamically") we improperly allocated memory for the card->dapm_routes causing us to overflow the allocation on every boot. Oops. Let's allocate the correct amount of memory. We'll also add a check to make sure that we don't

[PATCH] ASoC: rockchip: Allocate enough memory so we don't overflow routes

In the recent commit d9f9c167edae ("ASoC: rockchip: Init dapm routes dynamically") we improperly allocated memory for the card->dapm_routes causing us to overflow the allocation on every boot. Oops. Let's allocate the correct amount of memory. We'll also add a check to make sure that we don't

[PATCH RFC hack dont apply] intel_idle: support running within a VM

intel idle driver does not DTRT when running within a VM: when going into a deep power state, the right thing to do is to exit to hypervisor rather than to keep polling within guest using mwait. Currently the solution is just to exit to hypervisor each time we go idle - this is why kvm does not

[PATCH RFC hack dont apply] intel_idle: support running within a VM

intel idle driver does not DTRT when running within a VM: when going into a deep power state, the right thing to do is to exit to hypervisor rather than to keep polling within guest using mwait. Currently the solution is just to exit to hypervisor each time we go idle - this is why kvm does not

[PATCH 06/12] Input: elants_i2c - use managed devm_device_add_group

Commit 57b8ff070f98 ("driver core: add devm_device_add_group() and friends") has added the the managed version for creating sysfs group files. Use devm_device_add_group instead of sysfs_create_group and remove the action that cleans the sysfs file when exiting the driver. Signed-off-by: Andi

[PATCH 06/12] Input: elants_i2c - use managed devm_device_add_group

Commit 57b8ff070f98 ("driver core: add devm_device_add_group() and friends") has added the the managed version for creating sysfs group files. Use devm_device_add_group instead of sysfs_create_group and remove the action that cleans the sysfs file when exiting the driver. Signed-off-by: Andi

[PATCH 05/12] Input: edt-ft5x06 - use managed devm_device_add_group

Commit 57b8ff070f98 ("driver core: add devm_device_add_group() and friends") has added the the managed version for creating sysfs group files. Use devm_device_add_group instead of sysfs_create_group and remove the relative sysfs_remove_group and goto label. Signed-off-by: Andi Shyti

[PATCH 09/12] Input: raydium_i2c_ts - use managed devm_device_add_group

Commit 57b8ff070f98 ("driver core: add devm_device_add_group() and friends") has added the the managed version for creating sysfs group files. Use devm_device_add_group instead of sysfs_create_group and remove the action that cleans the sysfs file when exiting the driver. Signed-off-by: Andi

[PATCH 05/12] Input: edt-ft5x06 - use managed devm_device_add_group

Commit 57b8ff070f98 ("driver core: add devm_device_add_group() and friends") has added the the managed version for creating sysfs group files. Use devm_device_add_group instead of sysfs_create_group and remove the relative sysfs_remove_group and goto label. Signed-off-by: Andi Shyti ---

[PATCH 09/12] Input: raydium_i2c_ts - use managed devm_device_add_group

Commit 57b8ff070f98 ("driver core: add devm_device_add_group() and friends") has added the the managed version for creating sysfs group files. Use devm_device_add_group instead of sysfs_create_group and remove the action that cleans the sysfs file when exiting the driver. Signed-off-by: Andi

Re: How to verify linux-next

On Fri, Sep 29, 2017 at 07:56:41PM +0530, Pintu Kumar wrote: > BTW, I am more interested in my another query about QEMU arm. > This will be much quicker and easy for me. > But the problem is I wanted to use multiple ssh shell on qemu. > Also I needed a pre-built rootfs image for qemu-arm,

Re: How to verify linux-next

On Fri, Sep 29, 2017 at 07:56:41PM +0530, Pintu Kumar wrote: > BTW, I am more interested in my another query about QEMU arm. > This will be much quicker and easy for me. > But the problem is I wanted to use multiple ssh shell on qemu. > Also I needed a pre-built rootfs image for qemu-arm,

Re: [Outreachy kernel] [PATCH] Staging: rtl8723bs: Remove unnecessary comments.

On Fri, 2017-09-29 at 23:10 +0200, Julia Lawall wrote: > > On Sat, 30 Sep 2017, Shreeya Patel wrote: > > > > > The comments regarding memset are not needed in the > > files which have been modified since the necessary changes > > are already there in the files. > The comments don't look very

Re: [Outreachy kernel] [PATCH] Staging: rtl8723bs: Remove unnecessary comments.

On Fri, 2017-09-29 at 23:10 +0200, Julia Lawall wrote: > > On Sat, 30 Sep 2017, Shreeya Patel wrote: > > > > > The comments regarding memset are not needed in the > > files which have been modified since the necessary changes > > are already there in the files. > The comments don't look very

Re: [PATCHSET REPOST for-4.15] cgroup, sched: cgroup2 interface for CPU controller (on basic acct)

On Mon, Sep 25, 2017 at 09:00:17AM -0700, Tejun Heo wrote: > Hello, > > (Rebased on cgroup/for-4.15, no real changes. Once acked, I think > it'd be easiest to route these through the cgroup branch; > alternatively, we can pull cgroup/for-4.15 to a sched branch and > apply these there.) > >

Re: [PATCHSET REPOST for-4.15] cgroup, sched: cgroup2 interface for CPU controller (on basic acct)

On Mon, Sep 25, 2017 at 09:00:17AM -0700, Tejun Heo wrote: > Hello, > > (Rebased on cgroup/for-4.15, no real changes. Once acked, I think > it'd be easiest to route these through the cgroup branch; > alternatively, we can pull cgroup/for-4.15 to a sched branch and > apply these there.) > >

Re: [PATCH v3] PCIe AER: report uncorrectable errors only to the functions that logged the errors

On Fri, Sep 29, 2017 at 04:15:26PM -0500, Bjorn Helgaas wrote: > On Thu, Sep 28, 2017 at 03:33:05PM +0100, Gabriele Paoloni wrote: > > Currently if an uncorrectable error is reported by an EP the AER > > driver walks over all the devices connected to the upstream port > > bus and in turns call the

Re: [PATCH v3] PCIe AER: report uncorrectable errors only to the functions that logged the errors

On Fri, Sep 29, 2017 at 04:15:26PM -0500, Bjorn Helgaas wrote: > On Thu, Sep 28, 2017 at 03:33:05PM +0100, Gabriele Paoloni wrote: > > Currently if an uncorrectable error is reported by an EP the AER > > driver walks over all the devices connected to the upstream port > > bus and in turns call the

[Part1 PATCH v5.1 02/17] x86/mm: Add Secure Encrypted Virtualization (SEV) support

From: Tom Lendacky Provide support for Secure Encrypted Virtualization (SEV). This initial support defines a flag that is used by the kernel to determine if it is running with SEV active. Cc: Thomas Gleixner Cc: Ingo Molnar Cc:

[Part1 PATCH v5.1 02/17] x86/mm: Add Secure Encrypted Virtualization (SEV) support

From: Tom Lendacky Provide support for Secure Encrypted Virtualization (SEV). This initial support defines a flag that is used by the kernel to determine if it is running with SEV active. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Borislav Petkov Cc: Andy Lutomirski Cc:

[PATCH net-next v2 1/7] net: dsa: add master helper to look up slaves

The DSA tagging code does not need to know about the DSA architecture, it only needs to return the slave device corresponding to the source port index (and eventually the source device index for cascade-capable switches) parsed from the frame received on the master device. For this purpose,

[PATCH net-next v2 1/7] net: dsa: add master helper to look up slaves

The DSA tagging code does not need to know about the DSA architecture, it only needs to return the slave device corresponding to the source port index (and eventually the source device index for cascade-capable switches) parsed from the frame received on the master device. For this purpose,

[PATCH net-next v2 6/7] net: dsa: change dsa_ptr for a dsa_port

With DSA, a master net device (CPU facing interface) has a dsa_ptr pointer to which hangs a dsa_switch_tree. This is not correct because a master interface is wired to a dedicated switch port, and because we can theoretically have several master interfaces pointing to several CPU ports of the same

[PATCH net-next v2 6/7] net: dsa: change dsa_ptr for a dsa_port

With DSA, a master net device (CPU facing interface) has a dsa_ptr pointer to which hangs a dsa_switch_tree. This is not correct because a master interface is wired to a dedicated switch port, and because we can theoretically have several master interfaces pointing to several CPU ports of the same

[PATCH net-next v2 7/7] net: dsa: remove tag ops from the switch tree

Now that the dsa_ptr is a dsa_port instance, there is no need to keep the tag operations in the dsa_switch_tree structure. Remove it. Signed-off-by: Vivien Didelot Reviewed-by: Florian Fainelli --- include/net/dsa.h | 11 ---

[PATCH net-next v2 0/7] net: dsa: change dsa_ptr for a dsa_port

With DSA, a master net_device is physically wired to a dedicated CPU switch port. For interaction with the DSA layer, the struct net_device contains a dsa_ptr, which currently points to a dsa_switch_tree object. This is only valid for a switch fabric with a single CPU port. In order to support

[PATCH net-next v2 7/7] net: dsa: remove tag ops from the switch tree

Now that the dsa_ptr is a dsa_port instance, there is no need to keep the tag operations in the dsa_switch_tree structure. Remove it. Signed-off-by: Vivien Didelot Reviewed-by: Florian Fainelli --- include/net/dsa.h | 11 --- net/dsa/dsa2.c| 2 -- net/dsa/legacy.c | 2 -- 3

[PATCH net-next v2 0/7] net: dsa: change dsa_ptr for a dsa_port

With DSA, a master net_device is physically wired to a dedicated CPU switch port. For interaction with the DSA layer, the struct net_device contains a dsa_ptr, which currently points to a dsa_switch_tree object. This is only valid for a switch fabric with a single CPU port. In order to support

<    1   2   3   4   5   6   7   8   9   10   >