Re: [PATCH 2/2] tty: pl011: Work around QDF2400 E44 for earlycon

Hi Cov, The same PL011 driver will be used in virtutal machine, make sure your changes have no side effects in VM. On 02/07/2017 10:07 PM, Timur Tabi wrote: Christopher Covington wrote: The previous change worked around QDF2432v1 and QDF2400v1 SoC erratum 44 for the full-fledged console,

Re: [PATCH] time: Remove CONFIG_TIMER_STATS

Hi Kees, [auto build test WARNING on tip/timers/core] [also build test WARNING on v4.10-rc7 next-20170207] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kees-Cook/time-Remove

Re: [PATCH] time: Remove CONFIG_TIMER_STATS

On Tue, Feb 7, 2017 at 3:40 PM, Kees Cook wrote: > Currently CONFIG_TIMER_STATS exposes process information across namespaces: > > kernel/time/timer_list.c print_timer(): > > SEQ_printf(m, ", %s/%d", tmp, timer->start_pid); > > /proc/timer_list: > > #11:

Re: [PATCH 2/2] tty: pl011: Work around QDF2400 E44 for earlycon

Christopher Covington wrote: The previous change worked around QDF2432v1 and QDF2400v1 SoC erratum 44 for the full-fledged console, when UART AMBA Port (UAP) data is available. Additionally provide a workaround the earlycon case, again checking TXFE == 0 instead of BUSY == 1. As earlycon is

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

Christopher Covington wrote: The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1 and 2400v1 SoCs. Checking that the Transmit FIFO

[PATCH v2 2/2] Documentation/kconfig: add search jump feature description

From: Changbin Du Kernel menuconfig support direct jumping function from the search result. This is a very convenient feature but not documented. So add a short description to the kconfig documentation to let more developers know it. v2: correct spell (Jim)

[PATCH v2 0/2] kconfig/mconf: propagate jumping function in search result view

From: Changbin Du While I am searching something in menuconfig, I hope if I can jump to interested items directly. I even try to add this feature. When I check the code just found it has already been there but not documented. So why let more developers know it? v2:

[PATCH v2 1/2] kconfig/mconf: add jumping tip in title of search result textbox

From: Changbin Du Prompt user how to quickly jump to the item he/she is interested in. Signed-off-by: Changbin Du Reviewed-by: Jani Nikula --- scripts/kconfig/mconf.c | 8 1 file changed, 4 insertions(+), 4

[PATCH 2/2] tty: pl011: Work around QDF2400 E44 for earlycon

The previous change worked around QDF2432v1 and QDF2400v1 SoC erratum 44 for the full-fledged console, when UART AMBA Port (UAP) data is available. Additionally provide a workaround the earlycon case, again checking TXFE == 0 instead of BUSY == 1. As earlycon is operating before UAP data is

[PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1 and 2400v1 SoCs. Checking that the Transmit FIFO Empty (TXFE) bit is 0, instead

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On 02/01/2017 01:38 PM, Catalin Marinas wrote: > On Wed, Feb 01, 2017 at 06:34:01PM +, Will Deacon wrote: >> On Wed, Feb 01, 2017 at 06:22:44PM +, Catalin Marinas wrote: >>> On Wed, Feb 01, 2017 at 05:59:48PM +, Will Deacon wrote: On Wed, Feb 01, 2017 at 05:49:34PM +, Catalin

[PATCH v6] arm64: Work around Falkor erratum 1003

The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum is triggered, page table entries using the new translation table base address (BADDR) will be allocated into the TLB using the old ASID. All

[PATCH] time: Remove CONFIG_TIMER_STATS

Currently CONFIG_TIMER_STATS exposes process information across namespaces: kernel/time/timer_list.c print_timer(): SEQ_printf(m, ", %s/%d", tmp, timer->start_pid); /proc/timer_list: #11: <>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570 Given that the tracer can give

[PATCH linux v7 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations

From: "Edward A. James" Add functions to send SCOM operations over I2C bus. The BMC can communicate with the Power8 host processor over I2C, but needs to use SCOM operations in order to access the OCC register space. Signed-off-by: Edward A. James

[PATCH linux v7 0/6] drivers: hwmon: Add On-Chip Controller driver

From: "Edward A. James" This patchset adds a hwmon driver to support the OCC (On-Chip Controller) on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The OCC is an embedded processor that provides real time power and thermal monitoring. The

[PATCH linux v7 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC

From: "Edward A. James" Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as well as probe the entire driver from the I2C bus. I2C is the communication method between the BMC and the P8 OCC. Signed-off-by: Edward A. James

[PATCH linux v7 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs

From: "Edward A. James" Add core support for polling the OCC for it's sensor data and parsing that data into sensor-specific information. Signed-off-by: Edward A. James Signed-off-by: Andrew Jeffery --- Documentation/hwmon/occ| 40

[PATCH linux v7 6/6] hwmon: occ: Add callbacks for parsing P9 OCC datastructures

From: "Edward A. James" Add functions to parse the data structures that are specific to the OCC on the POWER9 processor. These are the sensor data structures, including temperature, frequency, power, and "caps." Signed-off-by: Edward A. James

[PATCH linux v7 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures

From: "Edward A. James" Add functions to parse the data structures that are specific to the OCC on the POWER8 processor. These are the sensor data structures, including temperature, frequency, power, and "caps." Signed-off-by: Edward A. James

[PATCH linux v7 2/6] hwmon: occ: Add sysfs interface

From: "Edward A. James" Add a generic mechanism to expose the sensors provided by the OCC in sysfs. Signed-off-by: Edward A. James Signed-off-by: Andrew Jeffery --- Documentation/hwmon/occ | 62 +++

Re: [PATCH linux v6 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs

tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/eajames-linux-vnet-ibm-com/drivers-hwmon-Add-On-Chip-Controller-driver/20170207-043353 base: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next config: openrisc

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On 02/07/2017 10:19 PM, Jesper Dangaard Brouer wrote: On Tue, 07 Feb 2017 17:43:38 +0100 Daniel Borkmann wrote: Hi Jesper, On 02/07/2017 03:30 PM, Jesper Dangaard Brouer wrote: Question: What kernel tree should this go into??? If going through Jonathan Corbet, will it

[PATCH] i2c: i2c-mux-gpio: rename i2c-gpio-mux to i2c-mux-gpio

The rename did the wrong thing for this documentation file all those years ago. Fix that as well as the neglected rename of the platform data structure. Fixes: e7065e20d9a6 ("i2c: Rename last mux driver to standard pattern") Signed-off-by: Peter Rosin ---

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 7 Feb 2017 21:51:49 +0100 Jesper Dangaard Brouer wrote: > I sounds like Daniel (see other email) have bigger plans for what > Documentation/BPF/ should contain. E.g. consolidating > Documentation/networking/filter.txt which covers the cBPF/eBPF internals. > If that is

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 07 Feb 2017 17:43:38 +0100 Daniel Borkmann wrote: > Hi Jesper, > > On 02/07/2017 03:30 PM, Jesper Dangaard Brouer wrote: > > Question: What kernel tree should this go into??? > > > > If going through Jonathan Corbet, will it appear sooner here??? > >

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 7 Feb 2017 09:46:08 -0700 Jonathan Corbet wrote: > On Tue, 7 Feb 2017 17:09:08 +0100 > Jesper Dangaard Brouer wrote: > > > > > Question: What kernel tree should this go into??? > > > > > > > > If going through Jonathan Corbet, will it appear sooner

Re: [PATCHv3 0/2] Hardening configs refactor/rename

On Mon, Feb 6, 2017 at 4:31 PM, Laura Abbott wrote: > Hi, > > This is v3 of my series to rename/refactor CONFIG_DEBUG_RODATA > and CONFIG_DEBUG_SET_MODULE_RONX. Among other objections, there shouldn't > be 'debug' in the name since these provide necessary kernel protection. >

Re: arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

+++ Laura Abbott [06/02/17 16:31 -0800]: Both of these options are poorly named. The features they provide are necessary for system security and should not be considered debug only. Change the names to CONFIG_STRICT_KERNEL_RWX and CONFIG_STRICT_MODULE_RWX to better describe what these options

Re: [PATCH] drm/doc: Add TODO list

On Tue, Feb 07, 2017 at 06:51:13PM +0100, Thierry Reding wrote: > From: Thierry Reding > > This commit adds a TODO list to the GPU driver developer's guide. The > content was taken from the DRMJanitors page on the X.Org wiki: > > https://www.x.org/wiki/DRMJanitors/ >

[PATCH] drm/doc: Add TODO list

From: Thierry Reding This commit adds a TODO list to the GPU driver developer's guide. The content was taken from the DRMJanitors page on the X.Org wiki: https://www.x.org/wiki/DRMJanitors/ The goal is to track a list of refactorings that would be nice to see merged

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 7 Feb 2017 17:09:08 +0100 Jesper Dangaard Brouer wrote: > > > Question: What kernel tree should this go into??? > > > > > > If going through Jonathan Corbet, will it appear sooner here??? > > > https://www.kernel.org/doc/html/latest/ > > What about this question?

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

Hi Jesper, On 02/07/2017 03:30 PM, Jesper Dangaard Brouer wrote: Question: What kernel tree should this go into??? If going through Jonathan Corbet, will it appear sooner here??? https://www.kernel.org/doc/html/latest/ If it will not appear sooner that way, then it's likely best to keep it

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 7 Feb 2017 08:37:17 -0700 Jonathan Corbet wrote: > On Tue, 07 Feb 2017 15:30:11 +0100 > Jesper Dangaard Brouer wrote: > > > Question: What kernel tree should this go into??? > > > > If going through Jonathan Corbet, will it appear sooner here??? > >

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

On Tue, 07 Feb 2017 15:30:11 +0100 Jesper Dangaard Brouer wrote: > Question: What kernel tree should this go into??? > > If going through Jonathan Corbet, will it appear sooner here??? > https://www.kernel.org/doc/html/latest/ > If it will not appear sooner that way, then

[net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

Question: What kernel tree should this go into??? If going through Jonathan Corbet, will it appear sooner here??? https://www.kernel.org/doc/html/latest/ If it will not appear sooner that way, then it's likely best to keep it in sync with the tree that takes eBPF code changes. This marks the

[net-next PATCH 1/4] doc/bpf: start eBPF documentation tree bpf/

The learning curve for eBPF programs is hard. The purpose of this documentation (subtree) is to make it easier for developers to get started using and writing eBPF programs. Including bpf/index under section User-oriented documentation. Thanks to Quentin Monnet for

[net-next PATCH 2/4] doc/bpf: document interacting with eBPF maps

Describe what eBPF maps are, how to create them, and how to interact with them. Thanks to Quentin Monnet for improving this document by fixing many typos and early review. Signed-off-by: Jesper Dangaard Brouer --- Documentation/bpf/ebpf_maps.rst |

[net-next PATCH 4/4] doc/bpf: describe BCC the BPF Compiler Collection

It is worth mentioning BCC (BPF Compiler Collection) in-order to direct developers into that community. Reviewed-by: Alexander Alemayhu Signed-off-by: Jesper Dangaard Brouer --- Documentation/bpf/bcc_tool_chain.rst | 37

[net-next PATCH 3/4] doc/bpf: describes the different types of eBPF maps available

The purpose is to help choose the right map type based on the individual use-case. To start with, only BPF_MAP_TYPE_ARRAY is described. It is the plan that all types should have descriptions here. Signed-off-by: Jesper Dangaard Brouer --- Documentation/bpf/ebpf_maps.rst

Re: [PATCHv3 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

On Mon, Feb 06, 2017 at 04:31:57PM -0800, Laura Abbott wrote: > > There are multiple architectures that support CONFIG_DEBUG_RODATA and > CONFIG_SET_MODULE_RONX. These options also now have the ability to be > turned off at runtime. Move these to an architecture independent > location and make

[PATCH] irqdesc: add memory managed version of irq_alloc_descs()

Add a devres flavor of __devm_irq_alloc_descs() and corresponding helper macros. Signed-off-by: Bartosz Golaszewski --- I initially sent this patch as part of the series extending the GPIO testing driver, but as suggested by Linus - I used the non-managed version for