From: Song Liu
Both libbfd and libopcodes are distributed with binutil-dev/devel. When
libbfd is present, it is OK to assume that libopcodes also present. This
has been a safe assumption for bpftool.
This patch adds -lopcodes to perf/Makefile.config. libopcodes will be
used in the next commit
From: Song Liu
To fully annotate BPF programs with source code mapping, 4 different
information are needed:
1) PERF_RECORD_KSYMBOL
2) PERF_RECORD_BPF_EVENT
3) bpf_prog_info
4) btf
This patch handles 3) and 4) for BPF programs loaded after 'perf
record|top'.
For timely process
From: Song Liu
Introduce a new dso type DSO_BINARY_TYPE__BPF_PROG_INFO for BPF programs. In
symbol__disassemble(), DSO_BINARY_TYPE__BPF_PROG_INFO dso will call into a new
function symbol__disassemble_bpf() in an upcoming patch, where annotation line
information is filled based bpf_prog_info and
From: Song Liu
This patch adds processing of PERF_BPF_EVENT_PROG_LOAD, which sets
proper DSO type/id/etc of memory regions mapped to BPF programs to
DSO_BINARY_TYPE__BPF_PROG_INFO.
Signed-off-by: Song Liu
Reviewed-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Namhyung Kim
From: Song Liu
With bpf_program__get_prog_info_linear, we can simplify the logic that
synthesizes bpf events.
This patch doesn't change the behavior of the code.
Commiter notes:
Needed this (for all four variables), suggested by Song, to overcome
build failure on debian experimental cross
From: Song Liu
This patches uses bpf_program__get_prog_info_linear() to simplify the
logic in prog.c do_dump().
Committer testing:
Before:
# bpftool prog dump xlated id 208 > /tmp/dump.xlated.before
# bpftool prog dump jited id 208 > /tmp/dump.jited.before
# bpftool map dump id 107 >
From: Song Liu
This patch adds option --no-bpf-event to 'perf top', which is the same
as the option of 'perf record'.
The following patches will use this option.
Committer testing:
# perf top -vv 2> /tmp/perf_event_attr.out
# cat /tmp/perf_event_attr.out
From: Song Liu
This patch enables 'perf record' to save BTF information as headers to
perf.data.
A new header type HEADER_BPF_BTF is introduced for this data.
Committer testing:
As root, being on the kernel sources top level directory, run:
# perf trace -e
From: Song Liu
BTF contains information necessary to annotate BPF programs. This patch
saves BTF for BPF programs loaded in the system.
Signed-off-by: Song Liu
Reviewed-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stanislav Fomichev
Cc:
From: Song Liu
This patch changes the arguments of perf_event__synthesize_bpf_events()
to include perf_session* instead of perf_tool*. perf_session will be
used in the next patch.
Signed-off-by: Song Liu
Reviewed-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Namhyung Kim
Cc:
On Fri, Mar 22, 2019 at 12:18:58AM +0530, Bharath Vedartham wrote:
> On Thu, Mar 21, 2019 at 07:46:09PM +0100, Greg KH wrote:
> > On Fri, Mar 22, 2019 at 12:07:10AM +0530, Bharath Vedartham wrote:
> > > Change uint32_t to u32
> >
> > That says _what_ you did, but _why_ are you doing this? That's
From: Song Liu
This patch enables perf-record to save bpf_prog_info information as
headers to perf.data. A new header type HEADER_BPF_PROG_INFO is
introduced for this data.
Committer testing:
As root, being on the kernel sources top level directory, run:
# perf trace -e
From: Changbin Du
There are two trees for each map inserted by maps__insert(), so remove
it from the 'names' tree in __maps__remove().
Detected with gcc's ASan.
Signed-off-by: Changbin Du
Reviewed-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Eric Saint-Etienne
Cc: Namhyung
From: Song Liu
Currently, monitoring of BPF programs through bpf_event is off by
default for 'perf record'.
To turn it on, the user need to use option "--bpf-event". As BPF gets
wider adoption in different subsystems, this option becomes
inconvenient.
This patch makes bpf_event on by default,
From: Changbin Du
We should go to the cleanup path, to avoid leaks, detected using gcc's
ASan.
Signed-off-by: Changbin Du
Reviewed-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Steven Rostedt (VMware)
Link:
From: Song Liu
Currently, bpf_prog_info includes 9 arrays. The user has the option to
fetch any combination of these arrays. However, this requires a lot of
handling.
This work becomes more tricky when we need to store bpf_prog_info to a
file, because these arrays are allocated independently.
From: Changbin Du
=
==20875==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1160 byte(s) in 1 object(s) allocated from:
#0 0x7f1b6fc84138 in calloc
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1
From: Changbin Du
We need to map__put() before returning from failure of
sample__resolve_callchain().
Detected with gcc's ASan.
Signed-off-by: Changbin Du
Reviewed-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Krister Johansen
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc:
From: Changbin Du
=
==7506==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 13 byte(s) in 3 object(s) allocated from:
#0 0x7f03339d6070 in __interceptor_strdup
From: Changbin Du
The array str[] should have six elements.
=
==4322==ERROR: AddressSanitizer: global-buffer-overflow on address
0x56463844e300 at pc 0x564637e7ad0d bp 0x7f30c8c89d10 sp 0x7f30c8c89d00
READ of size 8 at
From: Changbin Du
=
==7497==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a88f30 in __interceptor_malloc
From: Changbin Du
Add function __maps__purge_names() to purge all maps from the names
tree. We need to cleanup the names tree in maps__exit().
Detected with gcc's ASan.
Signed-off-by: Changbin Du
Reviewed-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Eric Saint-Etienne
Cc:
From: Arnaldo Carvalho de Melo
Using gcc's ASan, Changbin reports:
=
==7494==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a89138 in calloc
From: Changbin Du
The evlist should be destroyed before the perf session.
Detected with gcc's ASan:
=
==27350==ERROR: AddressSanitizer: heap-use-after-free on address
0x62b02e38 at pc 0x5611da276999 bp 0x7ffce8f1d1a0 sp
From: Changbin Du
Detected with gcc's ASan:
Direct leak of 4356 byte(s) in 120 object(s) allocated from:
#0 0x7ff1a2b5a070 in __interceptor_strdup
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
#1 0x55719aef4814 in build_id_cache__origname util/build-id.c:215
#2
From: Changbin Du
The option 'sort-order' should be 'sort_order'.
Signed-off-by: Changbin Du
Reviewed-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Milian Wolff
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Steven Rostedt (VMware)
Fixes: 893c5c798be9 ("perf config: Show default
From: Changbin Du
Detected with gcc's ASan:
Direct leak of 66 byte(s) in 5 object(s) allocated from:
#0 0x7ff3b1f32070 in __interceptor_strdup
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
#1 0x560c8761034d in collect_config util/config.c:597
#2 0x560c8760d9cb in
From: Changbin Du
Optimization level '-Og' offers a reasonable level of optimization while
maintaining fast compilation and a good debugging experience. This patch
tries to make it work.
$ make DEBUG=1 EXTRA_CFLAGS='-Og'
bench/epoll-ctl.c: In function ‘do_threads’:
From: Changbin Du
AddressSanitizer (or ASan) and UndefinedBehaviorSanitizer (or UBSan) are
very useful tools to detect program bugs:
- AddressSanitizer (or ASan) is a GCC feature that detects memory
corruption bugs such as buffer overflows and memory leaks.
- UndefinedBehaviorSanitizer
From: Andi Kleen
The multiplexing scaling in perf stat mysteriously adds 0.5 to the
value. This dates back to the original perf tool. Other scaling code
doesn't use that strange convention. Remove the extra 0.5.
Before:
$ perf stat -e 'cycles,cycles,cycles,cycles,cycles,cycles' grep -rq foo
From: Mamatha Inamdar
This patch is to remove following hardware events from JSON file which
are not supported on POWER8.
pm_co_disp_fail
pm_co_tm_sc_footprint
pm_iside_disp
pm_iside_disp_fail
pm_iside_disp_fail_other
pm_iside_mru_touch
pm_l2_castout_mod
pm_l2_castout_shr
From: Changbin Du
Detected via gcc's ASan:
Direct leak of 2048 byte(s) in 64 object(s) allocated from:
6 #0 0x7f606512e370 in __interceptor_realloc
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee370)
7 #1 0x556b0f1d7ddd in thread_map__realloc util/thread_map.c:43
8 #2
From: Andi Kleen
The -c option to enable multiplex scaling has been useless for quite
some time because scaling is default.
It's only useful as --no-scale to disable scaling. But the non scaling
code path has bitrotted and doesn't print anything because perf output
code relies on value run/ena
dfcbc2f2994b8a3af3605a26dc29c07ad7378bf4:
tools lib bpf: Fix the build by adding a missing stdarg.h include (2019-03-11
17:14:31 -0300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tags/perf-core-for-mingo-5.1-20190321
for you to fetch changes up
From: Andi Kleen
Print [TID] tid %d instead of the crypted /tmp/perf-%d.map default.
% cat >loop.java
public class loop {
public static void main(String[] args)
{
for (;;);
}
}
^D
% javac loop.java
% perf record java loop
^C
Before:
From: Andi Kleen
When comparing time stamps in 'perf script' traces it can be annoying to
work with the full perf time stamps.
Add a --reltime option that displays time stamps relative to the trace
start to make it easier to read the traces.
Note: not currently supported for --time. Report an
From: Andi Kleen
Show all the supported sort keys in the command line help output, so
that it's not needed to refer to the manpage.
Before:
% perf report -h
...
-s, --sort
sort by key(s): pid, comm, dso, symbol, parent,
cpu, srcline, ... Please refer
From: Andi Kleen
The help description for --switch-output looks like there are multiple
comma separated fields. But it's actually a choice of different options.
Make it clear and less confusing.
Before:
% perf record -h
...
--switch-output[=]
Switch
From: Andi Kleen
When a filter is specified on the command line, filter the metrics too.
Before:
% perf list foo
List of pre-defined events (to be used in -e):
Metric Groups:
DSB:
DSB_Coverage
[Fraction of Uops delivered by the DSB (aka Decoded Icache; or Uop
Cache)]
From: Andi Kleen
When doing long term recording and waiting for some event to snapshot
on, we often only care about the last minute or so.
The --switch-output command line option supports rotating the perf.data
file when the size exceeds a threshold. But the disk would still be
filled with
Hi all,
Commit
828a8dfb7069 ("cifs: update internal module version number")
is missing a Signed-off-by from its author and committer.
--
Cheers,
Stephen Rothwell
pgpNr2uKRMEgN.pgp
Description: OpenPGP digital signature
On Fri, Mar 22, 2019 at 12:07:10AM +0530, Bharath Vedartham wrote:
> Change uint32_t to u32
That says _what_ you did, but _why_ are you doing this? That's the main
content a changelog text should have in it.
thanks,
greg k-h
On Thu, Mar 21, 2019 at 11:38:25AM -0700, Andy Lutomirski wrote:
> I suspect we'll want PV spinlocks and other goodies like PV TLB
> shootdown for a long time. The stuff I'd like to kill eventually is
> the PV "I'm not actually at CPL 0 so I'm faking it" part.
Right, and it's exactly those bits
Change device attributes' names to match ABI documentation. Names were
chosen such that they tend to be similar to existing ABI so it should
be easier to standardize them when necessary.
Signed-off-by: Marcelo Schmitt
---
.../staging/iio/impedance-analyzer/ad5933.c | 24 +--
1
Move ad5933 impedance-analyzer driver from staging to mainline. The
ad5933 is a high precision impedance converter system solution that
combines an on-board frequency generator with an analog-to-digital
converter (ADC). This driver was designed to be compatible with both
ad5933 and ad5934 chips.
This series of patches makes device attributes' names equal to ABI
documentation and move ad5933 driver out of staging. More precisely:
It changes device attributes' names to match or be similar to existing
ABI.
It moves the ad5933 driver from staging directory to iio main drivers
directory.
On Thu, Mar 21, 2019 at 11:37 AM Peter Zijlstra wrote:
>
> On Thu, Mar 21, 2019 at 11:25:44AM -0700, Linus Torvalds wrote:
> > On Thu, Mar 21, 2019 at 11:21 AM Andy Lutomirski wrote:
> > >
> > > I dunno. Lots of people at least use to have serious commercial interest
> > > in it.
> >
> > Yes,
On Thu, Mar 21, 2019 at 11:33 AM Linus Torvalds
wrote:
>
> On Thu, Mar 21, 2019 at 11:21 AM Andy Lutomirski wrote:
> >
> > I dunno. Lots of people at least use to have serious commercial interest
> > in it.
>
> Yes, it used to be a big deal. But full virtualization has gotten a
> lot more
Change uint32_t to u32
Signed-off-by: Bharath Vedartham
---
drivers/staging/ralink-gdma/ralink-gdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ralink-gdma/ralink-gdma.c
b/drivers/staging/ralink-gdma/ralink-gdma.c
index d78042e..2c19287 100644
---
On Thu, Mar 21, 2019 at 11:25:44AM -0700, Linus Torvalds wrote:
> On Thu, Mar 21, 2019 at 11:21 AM Andy Lutomirski wrote:
> >
> > I dunno. Lots of people at least use to have serious commercial interest
> > in it.
>
> Yes, it used to be a big deal. But full virtualization has gotten a
> lot
On Thu, Mar 21, 2019 at 11:28:50AM -0700, Andy Lutomirski wrote:
> On Thu, Mar 21, 2019 at 11:27 AM Peter Zijlstra wrote:
> >
> > On Thu, Mar 21, 2019 at 11:05:06AM -0700, Andy Lutomirski wrote:
> >
> > > Ugh.
> > >
> > > I certainly agree in principle that sticking the CR2 read into the asm
> >
On Thu, Mar 21, 2019 at 07:01:37PM +0100 Peter Zijlstra wrote:
> On Tue, Mar 19, 2019 at 09:00:05AM -0400, Phil Auld wrote:
> > sched/fair: Limit sched_cfs_period_timer loop to avoid hard lockup
> >
> > With extremely short cfs_period_us setting on a parent task group with a
> > large
> > number
On Thu, Mar 21, 2019 at 07:19:46PM +0100, David Sterba wrote:
> On Thu, Mar 21, 2019 at 05:39:41PM +0100, Greg KH wrote:
> > On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> > > Hi,
> > >
> > > would it be possible to have a git repository with all patches that are
> > > submitted
On 4/24/18 10:14 AM, Eric W. Biederman wrote:
> je...@suse.com writes:
>
>> From: Jeff Mahoney
>>
>> Hi all -
>>
>> I recently encountered a customer issue where, on a machine with many TiB
>> of memory and a few hundred cores, after a task with a few thousand threads
>> and hundreds of files
On Thu, Mar 21, 2019 at 11:27 AM Peter Zijlstra wrote:
>
> On Thu, Mar 21, 2019 at 11:05:06AM -0700, Andy Lutomirski wrote:
>
> > Ugh.
> >
> > I certainly agree in principle that sticking the CR2 read into the asm
> > is the right solution. But this patch makes the spaghetti even more
> >
On Thu, Mar 21, 2019 at 02:10:20PM -0400, Steven Rostedt wrote:
> On Thu, 21 Mar 2019 11:05:06 -0700
> Andy Lutomirski wrote:
>
> > In the long run, I think the right solution is to rewrite even more of
> > this mess in C. We really ought to be able to put the IRQ flag
> > tracing and the
On Thu, Mar 21, 2019 at 11:05:06AM -0700, Andy Lutomirski wrote:
> Ugh.
>
> I certainly agree in principle that sticking the CR2 read into the asm
> is the right solution. But this patch makes the spaghetti even more
> tangled. Maybe we can rearrange the code a bit so that the entry
> sequence
On Thu, Mar 21, 2019 at 11:10 AM Steven Rostedt wrote:
>
> On Thu, 21 Mar 2019 11:05:06 -0700
> Andy Lutomirski wrote:
>
> > In the long run, I think the right solution is to rewrite even more of
> > this mess in C. We really ought to be able to put the IRQ flag
> > tracing and the context
On Thu, Mar 21, 2019 at 11:21 AM Andy Lutomirski wrote:
>
> I dunno. Lots of people at least use to have serious commercial interest in
> it.
Yes, it used to be a big deal. But full virtualization has gotten a
lot more common and better.
> Hey Xen folks, how close are we to being able to say
On March 21, 2019 11:18:53 AM PDT, Linus Torvalds
wrote:
>On Thu, Mar 21, 2019 at 11:05 AM Andy Lutomirski
>wrote:
>>
>> In the long run, I think the right solution is to rewrite even more
>of
>> this mess in C. We really ought to be able to put the IRQ flag
>> tracing and the context tracking
syzbot has bisected this bug to:
commit 162f812f23bab583f5d514ca0e4df67797ac9cdf
Author: Loic Poulain
Date: Mon Sep 19 14:29:27 2016 +
Bluetooth: hci_uart: Add Marvell support
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=112f0a3b20
start commit: 162f812f
On Thu, Mar 21, 2019 at 10:25 AM Denys Vlasenko wrote:
>
> >
> > But iirc pushf/popf isn't really that expensive - in fact I think it's
> > pretty cheap when system flags don't change.
>
> I did not see evidence of this. In my testing,
> POPF is always ~20 cycles, even if popped flags are
On Thu, Mar 21, 2019 at 11:19 AM Linus Torvalds
wrote:
>
> On Thu, Mar 21, 2019 at 11:05 AM Andy Lutomirski wrote:
> >
> > In the long run, I think the right solution is to rewrite even more of
> > this mess in C. We really ought to be able to put the IRQ flag
> > tracing and the context
On Thu, Mar 21, 2019 at 06:17:01PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > On Thu, Mar 21, 2019 at 05:45:41PM +0100, Thomas Gleixner wrote:
> > > On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > > > Subject: perf/x86/intel: Initialize TFA MSR
> > > >
> > > >
On March 21, 2019 10:25:05 AM PDT, Denys Vlasenko wrote:
>On 3/18/19 7:10 PM, Linus Torvalds wrote:
>> On Mon, Mar 18, 2019 at 10:51 AM Peter Zijlstra
> wrote:
>>>
>>> How about I do a patch that schedules EFLAGS for both 32bit and
>64bit,
>>> mark this for backporting to infinity.
>>>
>>> And
Hi,
Fedora got a bug report of a panic with kernels > 5.0:
Mar 20 10:52:38 kernel: BUG: unable to handle kernel NULL pointer dereference
at 0043
Mar 20 10:52:38 kernel: #PF error: [normal kernel read fault]
Mar 20 10:52:38 kernel: PGD 8003de1d7067 P4D 8003de1d7067 PUD
On Thu, Mar 21, 2019 at 05:39:41PM +0100, Greg KH wrote:
> On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> > Hi,
> >
> > would it be possible to have a git repository with all patches that are
> > submitted to stable@ but don't apply directly?
> >
> > I get notified by mail,
On Thu, Mar 21, 2019 at 11:05 AM Andy Lutomirski wrote:
>
> In the long run, I think the right solution is to rewrite even more of
> this mess in C. We really ought to be able to put the IRQ flag
> tracing and the context tracking into C code.
Tangentially about this long run thing - can we
On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote:
>
> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command
> Set(0x0002) for flash operations, therefore
> drivers/mtd/chips/cfi_cmdset_0002.c
> can be use as is. But these devices do not support DQ polling method of
>
The pull request you sent on Thu, 21 Mar 2019 09:59:50 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
> fsnotify_for_v5.1-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7294fbd4416ab29bfb280f4f84ac78c28957c035
Thank you!
--
On Thu, 21 Mar 2019 11:05:06 -0700
Andy Lutomirski wrote:
> In the long run, I think the right solution is to rewrite even more of
> this mess in C. We really ought to be able to put the IRQ flag
> tracing and the context tracking into C code.
And once we do that, we can work on getting the
The pull request you sent on Thu, 21 Mar 2019 10:03:38 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
> fixes_for_v5.1-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0939221e64687f7df9bc6572ace80ff5a90c9794
Thank you!
--
On Thu, Mar 21, 2019 at 10:22 AM Peter Zijlstra wrote:
>
> On Thu, Mar 21, 2019 at 09:32:42AM -0400, Steven Rostedt wrote:
> > On Thu, 21 Mar 2019 11:45:17 +0100
> > Peter Zijlstra wrote:
> >
> > > - .if \paranoid
> > > + .if \read_cr2
> > > + mov %cr2, %rdx /* XXX
On Tue, Mar 19, 2019 at 09:00:05AM -0400, Phil Auld wrote:
> sched/fair: Limit sched_cfs_period_timer loop to avoid hard lockup
>
> With extremely short cfs_period_us setting on a parent task group with a large
> number of children the for loop in sched_cfs_period_timer can run until the
>
On Wed, Mar 20, 2019 at 08:34:22PM -0400, Joel Fernandes (Google) wrote:
> This is just a resend with scheduler patches split from the driver fixes and
> Paul's Reviewed-by(s) added.
>
> These patches fix various sparse errors ccaused as a result of the recent
> check
> to add rcu_check_sparse()
On Thu, 21 Mar 2019, Stephane Eranian wrote:
> On Thu, Mar 21, 2019 at 9:45 AM Thomas Gleixner wrote:
> >
> > On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > > Subject: perf/x86/intel: Initialize TFA MSR
> > >
> > > Stephane reported that we don't initialize the TFA MSR, which could lead
> > > to
Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming
IP is pretty simple and provides direct memory mapped access to
connected Flash devices.
Add basic support for the IP without DMA. Second ChipSelect is not
supported for now.
Signed-off-by: Vignesh Raghavendra
---
Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate
Bus interface between a host system master and one or more slave
interfaces. Hyperbus is used to connect microprocessor, microcontroller,
or ASIC devices with random access NOR flash memory (called Hyperflash)
or self refresh
On Wed, Mar 20, 2019 at 11:57 AM Eric Biggers wrote:
>
> On Tue, Mar 19, 2019 at 10:09:13AM -0700, Eric Biggers wrote:
> > On Tue, Mar 19, 2019 at 12:54:23PM +0100, Geert Uytterhoeven wrote:
> > > When running the sha1-asm crypto selftest on arm with
> > > CONFIG_HARDENED_USERCOPY_PAGESPAN=y:
> >
Add binding documentation for TI's Hyperbus memory controller present on
AM654 SoC.
Signed-off-by: Vignesh Raghavendra
---
.../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++
MAINTAINERS | 1 +
2 files changed, 28 insertions(+)
create mode
Add DT binding documentation for Hyperbus memory devices. Only
Hyperflash is supported at the moment.
Signed-off-by: Vignesh Raghavendra
---
Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++
1 file changed, 6 insertions(+)
create mode 100644
HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command
Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c
can be use as is. But these devices do not support DQ polling method of
determining chip ready/good status. These flashes provide Status
Register
On 3/21/2019 5:30 PM, Dan Williams wrote:
On Thu, Mar 21, 2019 at 7:27 AM Roberto Sassu wrote:
On 3/21/2019 2:54 PM, Jarkko Sakkinen wrote:
On Mon, Mar 18, 2019 at 04:45:13PM -0700, Dan Williams wrote:
Rather than fail initialization of the trusted.ko module, arrange for
the module to load,
Cypress HyperBus is Low Signal Count, High Performance Double Data Rate Bus
interface between a host system master and one or more slave interfaces.
HyperBus is used to connect microprocessor, microcontroller, or ASIC
devices with random access NOR flash memory(called HyperFlash) or
self refresh
On Thu, Mar 21, 2019 at 04:43:26PM +0100, Fabien Dessenne wrote:
> Unlike 'client_ops' which is initialized to 'default_client_ops', the
> port operations 'ops' may be left to NULL.
> Check the 'ops' value before checking the 'ops->x' value.
>
> Signed-off-by: Fabien Dessenne
> ---
>
Hi Linus,
Please pull the arm64 changes below. It's mostly fixes apart from the
kprobe blacklist checking which was deferred because of conflicting with
a fix merged after I pinned the arm64 for-next/core branch (f2b3d8566d81
"arm64: kprobe: Always blacklist the KVM world-switch code").
Thanks.
On Thu, Mar 21, 2019 at 10:03 AM David Howells wrote:
>
> Kees Cook wrote:
>
> > Why the separation between parse and apply now? Is this due to the
> > reconfigure calls? (i.e. why not call pstore_set_kmsg_bytes() in
> > pstore_parse_param()?
>
> Because parameter parsing is now done up front,
On Thu, Mar 21, 2019 at 05:39:41PM +0100, Greg KH wrote:
> On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> > Hi,
> >
> > would it be possible to have a git repository with all patches that are
> > submitted to stable@ but don't apply directly?
> >
> > I get notified by mail,
Bisection is inconclusive: the bug happens on the oldest tested release.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b1becf20
start commit: [unknown
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=1471becf20
console output:
On 03/20, Michal Hocko wrote:
>
> So we need
> freezable_schedule_unsafe unsafe here to workaround the original problem
> and do not trigger the warning.
Yes, but note the comment above freezable_schedule_unsafe() ;)
that is why I didn't even try to suggest to use _unsafe() instead of reverting.
On 3/21/19 9:51 AM, Michal Hocko wrote:
On Thu 21-03-19 09:21:39, Yang Shi wrote:
On 3/21/19 7:57 AM, Michal Hocko wrote:
On Wed 20-03-19 08:27:39, Yang Shi wrote:
MPOL_MF_LAZY was added by commit b24f53a0bea3 ("mm: mempolicy: Add
MPOL_MF_LAZY"), then it was disabled by commit
On 3/18/19 7:10 PM, Linus Torvalds wrote:
On Mon, Mar 18, 2019 at 10:51 AM Peter Zijlstra wrote:
How about I do a patch that schedules EFLAGS for both 32bit and 64bit,
mark this for backporting to infinity.
And then at the end, after the objtool-ac bits land, I do a patch
removing the EFLAGS
On Thu, Mar 21, 2019 at 9:45 AM Thomas Gleixner wrote:
>
> On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > Subject: perf/x86/intel: Initialize TFA MSR
> >
> > Stephane reported that we don't initialize the TFA MSR, which could lead
> > to trouble if the RESET value is not 0 or on kexec.
>
> That
On Thu, Mar 21, 2019 at 6:55 AM Steven Rostedt wrote:
>
> Looks to be an issue with the save_stack_trace_user() not checking if
> the address is canonical before reading it. I guess access_ok() doesn't
> check that.
access_ok() definitely does check for non-canonical.
But it only does so when
On Thu, Mar 21, 2019 at 09:32:42AM -0400, Steven Rostedt wrote:
> On Thu, 21 Mar 2019 11:45:17 +0100
> Peter Zijlstra wrote:
>
> > - .if \paranoid
> > + .if \read_cr2
> > + mov %cr2, %rdx /* XXX paravirt crap */
> > + .endif
> > +
>
> I'm guessing this breaks
On Thu, Mar 21, 2019 at 10:02 AM Nick Desaulniers
wrote:
>
> On Wed, Mar 20, 2019 at 7:11 PM Andrew Morton
> wrote:
> > I guess we should backport this into -stable so that older kernels can
> > be built with newer Clang.
>
> Ah, you're right. I always forget. Is it too late to add
>
> Cc:
Expose a reset controller that the phy will later use to control its
own PHY reset in the UFS controller. This will enable the combining
of PHY init functionality into a single function.
Signed-off-by: Evan Green
Reviewed-by: Stephen Boyd
---
Note: The remaining changes in this series need
Add the reset controller for the UFS controller, and wire it up
so that the UFS PHY can initialize itself without relying on
implicit sequencing between the two drivers.
Signed-off-by: Evan Green
Reviewed-by: Stephen Boyd
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes
Add a resets property to the PHY that represents the PHY reset
register in the UFS controller itself. This better describes the
complete specification of the PHY, and allows the PHY to perform
its initialization in a single function, rather than relying on
back-channel sequencing of initialization
Enable Qualcomm UFS controllers to expose the PHY reset via a reset
controller.
Signed-off-by: Evan Green
Reviewed-by: Rob Herring
Reviewed-by: Stephen Boyd
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
301 - 400 of 847 matches
Mail list logo
