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, w
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
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: <>, hrtimer_wakeup
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 opera
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 E
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)
Signed-off-by: Changbin Du
Reviewed-
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: correct spell (Jim)
Cha
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 deletions(-)
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
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
availab
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 o
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 M
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
circumst
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
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
Signed-off-by: Andrew Jeffery
---
drivers/hwm
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 driver provides an i
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
Signed-off-by: Andrew Jeffery
Acked-by: Rob Herring
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
MAINTAINERS| 7 +
drivers/hwmon/K
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
Signed-off-by: Andrew Jeffery
---
Documentation/hw
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
Signed-off-by: Andrew Jeffery
---
Documentation/hw
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 +++
drivers/hwmon/occ/Makefile| 2 +-
drivers/hwmon/occ/occ_sysfs.c | 251 +++
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
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 appear sooner here???
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
---
Documentation/i2c/muxes/i2c-mux-gpio | 2
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 the case (and I lik
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???
> > https://www.kernel.org/doc/html/lat
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 here???
> > > > https://www.kernel.o
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.
>
> v3 mostly focuses o
+++ 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 do.
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/
>
> The goal is to trac
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 eventually. Sometime
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? Or let me ask in an
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 in
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???
> > https://www.kernel.org/doc/html/lat
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 it's likely best to ke
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 be
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 improving
this document with
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 | 255 +++
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 ++
Documentation/bpf/index.rst
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 |3 +
Document
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 the
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 now and am sending this patch
41 matches
Mail list logo