In the structure perf_c2c for shared cache line stats, replace
"hitm_stats" with "shared_clines_stats", and rename function
resort_hitm_cb() to resort_shared_cl_cb().
Signed-off-by: Leo Yan
---
tools/perf/builtin-c2c.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --
On Thu, Oct 15, 2020 at 9:17 AM wrote:
>
>
> On 10/15/20 9:10 AM, Andrew Cooper wrote:
> > On 15/10/2020 13:37, boris.ostrov...@oracle.com wrote:
> >> On 10/14/20 1:53 PM, Jason Andryuk wrote:
> >>> +config XEN_512GB
> >>> + bool "Limit Xen pv-domain memory to 512GB"
> >>> + depends on XEN_PV
Since the new display option 'llc' is introduced, this patch is to
update the documentation to reflect it.
Signed-off-by: Leo Yan
---
tools/perf/Documentation/perf-c2c.txt | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Documentation/perf-c2c.tx
Since Arm64 SPE trace data doesn't support HITM, we still want to
explore "perf c2c" tool to analyze cache false sharing. If without HITM
tag, the tool cannot give out accurate result for cache false sharing,
a candidate solution is to sort the LLC hit and connect with the info of
multiple threads
Except the existed three display options 'tot', 'rmt', 'lcl', this patch
adds option 'llc' so that can sort on LLC load metrics. The new
introduced option can work as a choice if the memory event doesn't
contain HITM tags.
For the display with option 'llc', both the "Shared Data Cache Line
Table"
Add new field c2c_stats::tot_llchit to count total number for LLC hit:
c2c_stats::tot_llchit = c2c_stats::lcl_hitm + c2c_stats::ld_llchit
This is the preparation for additional sorting with total LLC hit, and
will be used in perf c2c report in following patches.
Signed-off-by: Leo Yan
---
to
The display and filter macros are named with suffix "_HITM", it is bound
to HITM metrics and isn't general if we want to sort cache lines with
other metrics (like LLC load hit) rather than HITM metrics.
This patch changes to use more general naming for macros:
s/DISPLAY_HITM/DISPLAY_ENTRY
s/F
This patch has no any functionality change but only refactors hist entry
validation for cacheline resorting.
It renames function "valid_hitm_or_store()" to "is_valid_hist_entry()",
changes return type from integer type to bool type. In the function,
it uses switch-case instead of ternary operator
If the memory event doesn't contain HITM tag (like Arm SPE), it cannot
rely on HITM display to report cache false sharing. Alternatively, we
can use the LLC access and multi-threads info to locate the potential
false sharing's data address, and if we connect with source code and
analyze the multi-
Add dimensions for LLC load hit and its associated percentage
calculation, which is to be displayed in the single cache line output.
Signed-off-by: Leo Yan
---
tools/perf/builtin-c2c.c | 51
1 file changed, 51 insertions(+)
diff --git a/tools/perf/builti
> "Sagar" == Sagar Shrikant Kadam writes:
> The FU540-C000 has a broken IRQ and support was added earlier
> so that it will operate in polling mode, but seems to work only
> in case interrupts property is missing from the i2c0 dt-node.
> This should not be the case and the driver should h
On 10/15, Jens Axboe wrote:
>
> On 10/15/20 8:37 AM, Oleg Nesterov wrote:
> > On 10/15, Jens Axboe wrote:
> >>
> >> On 10/15/20 8:31 AM, Oleg Nesterov wrote:
> >>> On 10/15, Jens Axboe wrote:
>
> static inline int signal_pending(struct task_struct *p)
> {
> +#if defined(CONFIG
Hello,
On Thu, Feb 06, 2020 at 12:25:18AM -0300, Leonardo Bras wrote:
> On Thu, 2020-02-06 at 00:08 -0300, Leonardo Bras wrote:
> > gup_pgd_range(addr, end, gup_flags, pages, &nr);
> > - local_irq_enable();
> > + end_lockless_pgtbl_walk(IRQS_ENABLED);
>
From: Borislav Petkov
Now that all in-kernel-tree users are converted to using the sysfs file,
remove the MSR from the "allowlist".
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/msr.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index
Local and remote HITM use the headers 'Lcl' and 'Rmt' respectively,
suppose if we want to extend the tool to display these two dimensions
under any one metrics, users cannot understand the semantics if only
based on the header string 'Lcl' or 'Rmt'.
To explicit express the meaning for HITM items,
"rmt_hit" is accounted into two metrics: one is accounted into the
metrics "LLC Ld Miss" (see the function llc_miss() for calculation
"llcmiss"); and it's accounted into metrics "LLC Load Hit". Thus,
for the literal meaning, it is contradictory that "rmt_hit" is
accounted for both "LLC Ld Miss" (L
From: Borislav Petkov
... and stop poking at the MSR directly.
Signed-off-by: Borislav Petkov
---
.../x86_energy_perf_policy.c | 109 --
1 file changed, 99 insertions(+), 10 deletions(-)
diff --git a/tools/power/x86/x86_energy_perf_policy/x86_energy_perf_polic
From: Borislav Petkov
Hi all,
here's something from my todo list: remove all in-kernel tools use of
that MSR and lastly drop it from the allowed-MSRs-list in the filtering.
Out-of-tree tools should do a similar, trivial conversion.
Constructive comments are, as always, appreciated.
Thx.
Bori
Replace the header string "Lcl" with "LclHit", which is more explicit
to express the event type is LLC local hit.
Signed-off-by: Leo Yan
Tested-by: Joe Mario
---
tools/perf/builtin-c2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/bu
From: Borislav Petkov
... instead of poking at the MSR. For that, move the accessor functions
to misc.c and add a sysfs-writing function too.
There should be no functional changes resulting from this.
Signed-off-by: Borislav Petkov
Cc: Thomas Renninger
Cc: Shuah Khan
---
tools/power/cpupowe
The output format for metrics has been reorganized, update documentation
to reflect the changes for it.
Signed-off-by: Leo Yan
---
tools/perf/Documentation/perf-c2c.txt | 34 ++-
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/tools/perf/Documentation/perf
The metrics "LLC Ld Miss" and "Load Dram" overlap with each other for
accouting items:
"LLC Ld Miss" = "lcl_dram" + "rmt_dram" + "rmt_hit" + "rmt_hitm"
"Load Dram" = "lcl_dram" + "rmt_dram"
Furthermore, the metrics "LLC Ld Miss" is not directive to show
statistics due to it contains summary
From: Borislav Petkov
... instead of poking at the MSR directly.
Signed-off-by: Borislav Petkov
Cc: Len Brown
Cc: linux...@vger.kernel.org
---
tools/power/x86/turbostat/turbostat.c | 29 ++-
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/tools/power/x86
The total stores is displayed under the metrics "Store Reference", to
output the same format with total records and all loads, extract the
total stores number as a standalone metrics "Total Stores".
After this patch, the tool shows the summary numbers ("Total records",
"Total loads", "Total Stores
To view the statistics with "breakdown" mode, it's good to show the
summary numbers for the total records, all stores and all loads, then
the sequential conlumns can be used to break into more detailed items.
To achieve this purpose, this patch displays the summary numbers for
records/stores/loads
This patch set is to refine metrics output organization.
If we reivew the current memory metrics in Perf c2c tool, it doesn't
organize the metrics with directive approach; thus user needs to take
time to dig into every statistics item. On the other hand, if use the
"summary and breakdown" approac
The metrics "LLC Load Hitm" contains two items: one is "local Hitm" and
another is "remote Hitm".
"local Hitm" means: L3 HIT and was serviced by another processor core
with a cross core snoop where modified copies were found; it's no doubt
that "local Hitm" belongs to LLC access.
But for "remote
The metrics are not organized based on memory hierarchy, e.g. the tool
doesn't organize the metrics order based on memory nodes from the close
node (e.g. L1/L2 cache) to far node (e.g. L3 cache and DRAM).
To output metrics with more friendly form, this patch refines the
metrics order based on memo
On Thu, Oct 15, 2020 at 08:50:05AM +, David Laight wrote:
> From: Arvind Sankar
> > Sent: 14 October 2020 22:27
> ...
> > +/*
> > + * This version is i.e. to prevent dead stores elimination on @ptr
> > + * where gcc and llvm may behave differently when otherwise using
> > + * normal barrier():
This patch allows to unregister a governor. If the unregistered
governor is the current one, it will be replaced by the governor with
the highest rating. If it is the last governor, the cpuidle framework
will be switched off.
Signed-off-by: Daniel Lezcano
---
drivers/cpuidle/governor.c | 37
The cpuidle.h header is declaring functions with an empty stub when
cpuidle is not enabled. However these functions are only called from
the governors which depends on cpuidle. In other words, when the
function is called it is when cpuidle is enabled, there is no
situation when it is called with cp
On 10/15, Jens Axboe wrote:
>
> We already get the ti_work passed in arch_do_signal(), define
> TIF_NOTIFY_SIGNAL and take the appropriate action in the signal handling
> based on _TIF_NOTIFY_SIGNAL and _TIF_SIGPENDING being set.
>
> Signed-off-by: Jens Axboe
Reviewed-by: Oleg Nesterov
The next patch will introduce the ability to unregister a governor
which will share part of the register function code. Instead of
duplicating, let's encapuslate the common parts into functions, so
they can be called from different places.
Signed-off-by: Daniel Lezcano
---
drivers/cpuidle/govern
In the next patch, the governors will be converted to modules. Export
the symbols of the different functions used by the governors.
Signed-off-by: Daniel Lezcano
---
drivers/cpuidle/governor.c | 3 +++
include/linux/tick.h | 2 ++
kernel/sched/core.c| 1 +
kernel/time/tick-sched.c
On Thu, Oct 15, 2020 at 04:37:52PM +0200, Jürgen Groß wrote:
> On 15.10.20 16:24, Roger Pau Monne wrote:
> > Assume that reads and writes to the variable will be atomic. The worse
> > that could happen is that one of the purges removes a partially
> > written percentage of grants, but the cache its
On 10/15, Jens Axboe wrote:
>
> This adds TIF_NOTIFY_SIGNAL handling in the generic code, which if set,
> will return true if signal_pending() is used in a wait loop. That causes
> an exit of the loop so that notify_signal tracehooks can be run. If the
> wait loop is currently inside a system call,
This patch converts the cpuidle governors into modules. Even if it is
not the utmost importance, that will be consistent with the devfreq,
the watchdog and the cpufreq governors.
Signed-off-by: Daniel Lezcano
---
drivers/cpuidle/Kconfig | 8
drivers/cpuidle/governors/haltp
On 10/15/20 8:42 AM, Oleg Nesterov wrote:
> On 10/15, Jens Axboe wrote:
>>
>> All the callers currently do this, clean it up and move the clearing
>> into tracehook_notify_resume() instead.
>>
>> Reviewed-by: Thomas Gleixner
>> Signed-off-by: Jens Axboe
>
> in case you didn't notice I already ac
On Thu, Oct 15, 2020 at 11:35:30AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Please do *not* rebase/rewrite your linux-next included tree and then
> immediately send it to Linus. Or if you do, the please also update
> what you have in linux-next (so you can sneak it past me :-().
> (mutter, mu
On 10/15/20 8:37 AM, Oleg Nesterov wrote:
> On 10/15, Jens Axboe wrote:
>>
>> On 10/15/20 8:31 AM, Oleg Nesterov wrote:
>>> On 10/15, Jens Axboe wrote:
static inline int signal_pending(struct task_struct *p)
{
+#if defined(CONFIG_GENERIC_ENTRY) && defined(TIF_NOTIFY_SIGNAL)
>>
On 10/15, Jens Axboe wrote:
>
> This is in preparation for maintaining signal_pending() as the decider
> of whether or not a schedule() loop should be broken, or continue
> sleeping. This is different than the core signal use cases, where we
> really want to know if an actual signal is pending or n
On 10/15, Jens Axboe wrote:
>
> All the callers currently do this, clean it up and move the clearing
> into tracehook_notify_resume() instead.
>
> Reviewed-by: Thomas Gleixner
> Signed-off-by: Jens Axboe
in case you didn't notice I already acked this change ;)
Reviewed-by: Oleg Nesterov
On 10/15/20 8:36 AM, Oleg Nesterov wrote:
> On 10/15, Jens Axboe wrote:
>>
>> static void handle_signal_work(ti_work, regs)
>> {
>> if (ti_work & _TIF_NOTIFY_SIGNAL)
>> tracehook_notify_signal();
>>
>> if (ti_work & _TIF_SIGPENDING)
>> arch_do_signal(regs);
>> }
On Wed, 14 Oct 2020 at 22:44, Andrey Konovalov wrote:
> This patchset is not complete (see particular TODOs in the last patch),
> and I haven't performed any benchmarking yet, but I would like to start the
> discussion now and hear people's opinions regarding the questions mentioned
> below.
>
> =
Hi folks,
I've updated the lock documentation according to our finding for
transaction_t.
Does this patch look good to you?
Cheers,
Alex
commit 13ac907c45c5da7d691f6e10972de5e56e0072c6
Author: Alexander Lochmann
Date: Thu Oct 15 15:24:52 2020 +0200
Updated locking documentation for transa
Dear Ville Syrjälä,
Thank you for responding so quickly.
I was occupied with work and life for the past two weeks, sorry about
the wait, but have now managed to find some time to continue pursuing
this issue again.
On Thu, 2020-10-01 at 18:23 +0300, Ville Syrjälä wrote:
> Argh. If only I had mana
On 15.10.20 16:24, Roger Pau Monne wrote:
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the purges removes a partially
written percentage of grants, but the cache itself will recover.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszut
On 10/15, Jens Axboe wrote:
>
> On 10/15/20 8:31 AM, Oleg Nesterov wrote:
> > On 10/15, Jens Axboe wrote:
> >>
> >> static inline int signal_pending(struct task_struct *p)
> >> {
> >> +#if defined(CONFIG_GENERIC_ENTRY) && defined(TIF_NOTIFY_SIGNAL)
> >> + /*
> >> + * TIF_NOTIFY_SIGNAL isn't re
On 10/15, Jens Axboe wrote:
>
> static void handle_signal_work(ti_work, regs)
> {
> if (ti_work & _TIF_NOTIFY_SIGNAL)
> tracehook_notify_signal();
>
> if (ti_work & _TIF_SIGPENDING)
> arch_do_signal(regs);
> }
>
> and then we can skip modifying arch_do_signal
On 10/15/20 8:34 AM, Thomas Gleixner wrote:
> On Thu, Oct 15 2020 at 08:31, Jens Axboe wrote:
>> On 10/15/20 8:11 AM, Thomas Gleixner wrote:
>> We could, should probably make it:
>>
>> static void handle_signal_work(ti_work, regs)
>> {
>> if (ti_work & _TIF_NOTIFY_SIGNAL)
>> trace
On 10/15, Thomas Gleixner wrote:
>
> On Thu, Oct 15 2020 at 07:17, Jens Axboe wrote:
> > --- a/arch/x86/kernel/signal.c
> > +++ b/arch/x86/kernel/signal.c
> > @@ -808,7 +808,10 @@ void arch_do_signal(struct pt_regs *regs, unsigned
> > long ti_work)
> > {
> > struct ksignal ksig;
> >
> > -
On Thu, Oct 15 2020 at 08:31, Jens Axboe wrote:
> On 10/15/20 8:11 AM, Thomas Gleixner wrote:
> We could, should probably make it:
>
> static void handle_signal_work(ti_work, regs)
> {
> if (ti_work & _TIF_NOTIFY_SIGNAL)
> tracehook_notify_signal();
>
> if (ti_work & _TIF_
On 10/15/20 8:31 AM, Oleg Nesterov wrote:
> On 10/15, Jens Axboe wrote:
>>
>> static inline int signal_pending(struct task_struct *p)
>> {
>> +#if defined(CONFIG_GENERIC_ENTRY) && defined(TIF_NOTIFY_SIGNAL)
>> +/*
>> + * TIF_NOTIFY_SIGNAL isn't really a signal, but it requires the same
>>
Hi,
On Thu, Oct 15, 2020 at 11:40:11AM +1100, Stephen Rothwell wrote:
> Hi David,
> On Mon, 12 Oct 2020 22:25:02 +0200 David Sterba wrote:
> >
> > Mishaps:
> >
> > - commit 62cf5391209a ("btrfs: move btrfs_rm_dev_replace_free_srcdev
> > outside of all locks") is a rebase leftover after the pat
On 10/15, Jens Axboe wrote:
>
> static inline int signal_pending(struct task_struct *p)
> {
> +#if defined(CONFIG_GENERIC_ENTRY) && defined(TIF_NOTIFY_SIGNAL)
> + /*
> + * TIF_NOTIFY_SIGNAL isn't really a signal, but it requires the same
> + * behavior in terms of ensuring that we b
On 10/15/20 8:11 AM, Thomas Gleixner wrote:
> On Thu, Oct 15 2020 at 07:17, Jens Axboe wrote:
>> --- a/arch/x86/kernel/signal.c
>> +++ b/arch/x86/kernel/signal.c
>> @@ -808,7 +808,10 @@ void arch_do_signal(struct pt_regs *regs, unsigned long
>> ti_work)
>> {
>> struct ksignal ksig;
>>
>> -
On Tue, Oct 13, 2020 at 05:17:36PM +0200, Giuseppe Scrivano wrote:
> "Serge E. Hallyn" writes:
>
> > On Mon, Oct 12, 2020 at 07:05:10PM +0200, Giuseppe Scrivano wrote:
> >> Josh Triplett writes:
> >>
> >> > On Fri, Oct 09, 2020 at 11:26:06PM -0500, Serge E. Hallyn wrote:
> >> >> > 3. Find a way
'snprintf' returns the number of characters which would have been written
if enough space had been available, excluding the terminating null byte.
Thus, the return value of 'buflen' means that the last character
was dropped.
Signed-off-by: Fedor Tokarev
---
tools/lib/traceevent/parse-filter.c |
On 15.10.20 16:24, Roger Pau Monne wrote:
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the LRU intervals is not calculated
properly if a partially written value is read, but that would only be
a transient issue.
Signed-off-by: Roger Pau
Hi Jerome,
On Thursday 15 Oct 2020 at 15:58:30 (+0200), Jerome Brunet wrote:
>
> On Thu 15 Oct 2020 at 15:46, Ionela Voinescu wrote:
>
> > Hi guys,
> >
> > On Wednesday 23 Sep 2020 at 14:39:16 (+0200), Jerome Brunet wrote:
> >> If the txdone is done by polling, it is possible for msg_submit() t
> On Oct 15, 2020, at 9:59 AM, Trond Myklebust wrote:
>
> On Thu, 2020-10-15 at 09:36 -0400, Chuck Lever wrote:
>>> On Oct 15, 2020, at 8:06 AM, Trond Myklebust <
>>> tron...@hammerspace.com> wrote:
>>>
>>> On Thu, 2020-10-15 at 00:39 +0530, Ashish Sangwan wrote:
On Wed, Oct 14, 2020 at
Hi Sai,
On 10/15/2020 01:45 PM, Sai Prakash Ranjan wrote:
On production systems with ETMs enabled, it is preferred to
exclude kernel mode(NS EL1) tracing for security concerns and
support only userspace(NS EL0) tracing. So provide an option
via kconfig to exclude kernel mode tracing if it is req
Use @kernel.org address as the main communications end point. Update the
corresponding M-entries and .mailmap (for git shortlog translation).
Signed-off-by: Jarkko Sakkinen
---
v2:
* Update the .mailmap (suggested by Joe Perches).
https://lore.kernel.org/lkml/b1ccdfbb3119528490ea10f40e1da084b1
On Wed, Oct 14, 2020 at 02:46:46PM -0500, Eric W. Biederman wrote:
> "Serge E. Hallyn" writes:
>
> > On Mon, Oct 12, 2020 at 12:01:09AM -0500, Eric W. Biederman wrote:
> >> Andy Lutomirski writes:
> >>
> >> > On Sun, Oct 11, 2020 at 1:53 PM Josh Triplett
> >> > wrote:
> >> >>
> >> >> On Fri,
On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
From: Ard Biesheuvel
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the purges removes a partially
written percentage of grants, but the cache itself will recover.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Jens Axboe
Cc: Boris Ostrovsky
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the LRU intervals is not calculated
properly if a partially written value is read, but that would only be
a transient issue.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Je
Add the LRU parameters as tunables.
Roger Pau Monne (2):
xen/blkback: turn the cache purge LRU interval into a parameter
xen/blkback: turn the cache purge percent into a parameter
.../ABI/testing/sysfs-driver-xen-blkback | 19 +++
drivers/block/xen-blkback/blkback.c
On Thu, Oct 15 2020 at 12:12, Pavel Machek wrote:
Cc+ Marc
> I'm getting build problems in 5.10-rc0 in config for n900. ARM board.
>
> CONFIG_SMP=y
> CONFIG_SMP_ON_UP=y
>
>
> CC net/devres.o
> kernel/irq/ipi.c: In function ‘irq_reserve_ipi’:
> kernel/irq/ipi.c:84:9: error: implicit dec
On Thu, Oct 15, 2020 at 02:54:53PM +0100, Valentin Schneider wrote:
>
> On 15/10/20 12:05, Peter Zijlstra wrote:
> > +static int affine_move_task(struct rq *rq, struct rq_flags *rf,
> > + struct task_struct *p, int dest_cpu, unsigned int
> > flags)
> > +{
> > + struct set_
On Thu, Oct 15, 2020 at 08:14:39AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Oct 15, 2020 at 02:51:05AM +0300, Serge Semin wrote:
> > >
> > > > So to speak thanks for suggesting it. I'll try it to validate the
> > > > proposed
> > > > changes.
> > > >
> > > > Two questions:
> > > > 1) Any advis
On Thu, 15 Oct 2020 at 15:39, Mark Rutland wrote:
> On Wed, Oct 14, 2020 at 09:12:37PM +0200, Marco Elver wrote:
> > On Thu, 8 Oct 2020 at 12:45, Mark Rutland wrote:
> > > On Thu, Oct 08, 2020 at 11:40:52AM +0200, Marco Elver wrote:
> > > > On Thu, 1 Oct 2020 at 19:58, Mark Rutland wrote:
>
> >
On Thu, Oct 15 2020 at 14:26, Dmitry Safonov wrote:
> On 10/15/20 8:29 AM, Andrei Vagin wrote:
>> For all commands except FUTEX_WAIT, timeout is interpreted as an
>> absolute value. This absolute value is inside the task's time namespace
>> and has to be converted to the host's time.
>>
>> Cc:
>
On Thu, Oct 15 2020 at 07:17, Jens Axboe wrote:
> --- a/arch/x86/kernel/signal.c
> +++ b/arch/x86/kernel/signal.c
> @@ -808,7 +808,10 @@ void arch_do_signal(struct pt_regs *regs, unsigned long
> ti_work)
> {
> struct ksignal ksig;
>
> - if (get_signal(&ksig)) {
> + if (ti_work & _
On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> > In rose_send_frame(), when comparing two ax.25 addresses, it assigns
> > rose_call to
> > either global ROSE callsign or default port, but when the former block
> > triggers
The polling mode workaround for the FU540-C000 on HiFive Unleashed A00
board was added earlier. The logic for this seems to work only in case
the interrupt property was missing/not added into the i2c0 device node.
Here we address this issue by identifying the SOC based on compatibility
string and
> On Oct 15, 2020, at 9:59 AM, Trond Myklebust wrote:
>
> On Thu, 2020-10-15 at 09:36 -0400, Chuck Lever wrote:
>>> On Oct 15, 2020, at 8:06 AM, Trond Myklebust <
>>> tron...@hammerspace.com> wrote:
>>>
>>> On Thu, 2020-10-15 at 00:39 +0530, Ashish Sangwan wrote:
On Wed, Oct 14, 2020 at
The FU540-C000 has a broken IRQ and support was added earlier
so that it will operate in polling mode, but seems to work only
in case interrupts property is missing from the i2c0 dt-node.
This should not be the case and the driver should handle polling
mode with the interrupt property present in i2
On 2020-10-15 10:52, Jisheng Zhang wrote:
On Thu, 15 Oct 2020 01:48:13 -0700
Saravana Kannan wrote:
On Thu, Oct 15, 2020 at 1:15 AM Jisheng Zhang
wrote:
On Wed, 14 Oct 2020 22:04:24 -0700 Saravana Kannan wrote:
On Wed, Oct 14, 2020 at 9:02 PM Jisheng Zhang
wrote:
On Wed, 14 Oct 202
This patch adds an extcon driver for the TI TUSB320 USB Type-C device.
This can be used to detect whether the port is configured as a
downstream or upstream facing port.
Signed-off-by: Michael Auchter
---
Changes since v1:
- Drop license text that's redundant with SPDX tag
- Cleanup, sort list of
Add a device tree binding for the TI TUSB320.
Signed-off-by: Michael Auchter
Reviewed-by: Rob Herring
---
Changes since v1:
- use tusb320 instead of extcon in the unit name
since v2:
- None
.../bindings/extcon/extcon-usbc-tusb320.yaml | 41 +++
1 file changed, 41 insertions(
On Thu, Oct 15, 2020 at 10:06:51AM +0100, Christoph Hellwig wrote:
> Don't we also need to handle the new return value in a few other places
> like cachefiles_read_reissue swap_readpage? Maybe those don't get
> called on the currently converted instances, but just leaving them
> without handling A
The judgement of first do not need to be in the critical region.
So move it out.
Signed-off-by: Hui Su
---
kernel/async.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/async.c b/kernel/async.c
index 33258e6e20f8..9d33ffcc84c7 100644
--- a/kernel/async.c
+++ b/kernel/
On Thu, Oct 15, 2020 at 01:15:37PM +0300, Felipe Balbi wrote:
> Serge Semin writes:
>
> > On Wed, Oct 14, 2020 at 05:09:37PM +0300, Felipe Balbi wrote:
> >>
> >> Hi Serge,
> >>
> >> Serge Semin writes:
> >> > In accordance with the DWC USB3 bindings the corresponding node name is
> >> > suppos
On Wednesday 14 October 2020 14:43:34 CEST Pali Rohár wrote:
> On Wednesday 14 October 2020 13:52:15 Jérôme Pouiller wrote:
> > On Tuesday 13 October 2020 22:11:56 CEST Pali Rohár wrote:
> > > On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote:
> > > > +#define SDIO_VENDOR_ID_SILABS0x
On Thu, Oct 15, 2020 at 1:53 PM Kuppuswamy, Sathyanarayanan
wrote:
>
>
>
> On 10/14/20 10:05 PM, Ethan Zhao wrote:
> > On Thu, Oct 15, 2020 at 11:04 AM Kuppuswamy, Sathyanarayanan
> > wrote:
> >>
> >>
> >>
> >> On 10/14/20 6:58 PM, Ethan Zhao wrote:
> >>> On Thu, Oct 15, 2020 at 1:06 AM Kuppuswam
Hi Viresh,
On 25/08/2020 06:50, Viresh Kumar wrote:
> On 24-08-20, 15:59, Jon Hunter wrote:
>> Commit 6cc3d0e9a097 ("cpufreq: tegra186: add
>> CPUFREQ_NEED_INITIAL_FREQ_CHECK flag") fixed CPUFREQ support for
>> Tegra186 but as a consequence the following warnings are now seen on
>> boot ...
>>
>>
On Thu, 2020-10-15 at 09:36 -0400, Chuck Lever wrote:
> > On Oct 15, 2020, at 8:06 AM, Trond Myklebust <
> > tron...@hammerspace.com> wrote:
> >
> > On Thu, 2020-10-15 at 00:39 +0530, Ashish Sangwan wrote:
> > > On Wed, Oct 14, 2020 at 11:47 PM Trond Myklebust
> > > wrote:
> > > > On Tue, 2020-10
Hi all,
On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote:
> Peilin Ye (1):
> drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
This patch is already in mainline:
commit 543e8669ed9bfb30545fd52bc0e047ca4df7fb31
Author: Peilin Ye
Date: Tue Jul 28 15:29:24 2020 -0400
Hi Masami,
On Wed, 2020-10-14 at 11:06 +0900, Masami Hiramatsu wrote:
> Hi Tom,
>
> On Tue, 13 Oct 2020 09:17:58 -0500
> Tom Zanussi wrote:
>
> > Add a selftest that verifies that the syntax error messages and
> > caret
> > positions are correct for most of the possible synthetic event
> > synt
Le 15/10/2020 à 15:25, Segher Boessenkool a écrit :
Hi!
On Thu, Oct 15, 2020 at 10:52:20AM +, Christophe Leroy wrote:
With gcc9 I get:
With gcc10 I get:
gcc10 defines multiple versions of csum_partial() which are just
an unconditionnal branch to __csum_partial().
It doesn't i
'snprintf' returns the number of characters which would have been written
if enough space had been available, excluding the terminating null byte.
Thus, the return value of 'sizeof(buf)' means that the last character
has been dropped.
Signed-off-by: Fedor Tokarev
---
net/sunrpc/debugfs.c | 4 ++-
On Thu 15 Oct 2020 at 15:46, Ionela Voinescu wrote:
> Hi guys,
>
> On Wednesday 23 Sep 2020 at 14:39:16 (+0200), Jerome Brunet wrote:
>> If the txdone is done by polling, it is possible for msg_submit() to start
>> the timer while txdone_hrtimer() callback is running. If the timer needs
>> rech
On Wed, 14 Oct 2020 at 22:45, Andrey Konovalov wrote:
>
> TODO: no meaningful description here yet, please see the cover letter
> for this RFC series.
>
> Signed-off-by: Andrey Konovalov
> Link:
> https://linux-review.googlesource.com/id/If7d37003875b2ed3e0935702c8015c223d6416a4
> ---
> m
On Wed, Oct 14, 2020 at 5:00 PM Kuppuswamy Sathyanarayanan
wrote:
>
> Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
> merged fatal and non-fatal error recovery paths, and also made
> recovery code depend on hotplug handler for "remove affected
> device + rescan" support. But this ch
On 15/10/20 12:05, Peter Zijlstra wrote:
> +static int affine_move_task(struct rq *rq, struct rq_flags *rf,
> + struct task_struct *p, int dest_cpu, unsigned int
> flags)
> +{
> + struct set_affinity_pending my_pending = { }, *pending = NULL;
> + struct migration_
On 06:38 Thu 15 Oct 2020, Joe Perches wrote:
On Thu, 2020-10-15 at 18:53 +0530, Bhaskar Chowdhury wrote:
Fix the space in the middle in below entry.
memry||memory
[]
diff --git a/scripts/spelling.txt b/scripts/spelling.txt
[]
@@ -885,7 +885,7 @@ meetign||meeting
memeory||memory
memmber||m
Hi Steve,
On Tue, 2020-10-13 at 15:48 -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> After having a typo for writing a histogram trigger.
>
> Wrote:
> echo 'hist:key=pid:ts=common_timestamp.usec' >
> events/sched/sched_waking/trigger
>
> Instead of:
> echo 'hist:key=pid
Greeting!
I am contacting you to receive and share with me an abandoned fund (
$21,537.000.00 ) left in our bank by a deceased customer. I was going through
the Internet search when I found your email address. My name is Mr. Kim Leang.
I want to utilize this opportunity and make use of this fun
On Thu, Oct 15, 2020 at 01:15:37PM +0300, Felipe Balbi wrote:
> Serge Semin writes:
>
> > On Wed, Oct 14, 2020 at 05:09:37PM +0300, Felipe Balbi wrote:
> >>
> >> Hi Serge,
> >>
> >> Serge Semin writes:
> >> > In accordance with the DWC USB3 bindings the corresponding node name is
> >> > suppos
501 - 600 of 947 matches
Mail list logo
