From: "Paul E. McKenney"
Knowing the number of batches that kvm.sh will split a run into allows
estimation of the duration of a test, give or take the number of builds.
This commit therefore adds a line of output to "--dryrun sched" that
gives the number of batches that will be run.
Hi Geert!
On Wed, 6 Jan 2021 09:37:11 +0100, Geert Uytterhoeven
wrote:
> Hi Thomas,
>
> CC Nemoto-san (de-facto TX49XX maintainer)
>
> On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
> wrote:
>> I couldn't find any buyable product other than reference boards using
>> TX49xx CPUs. And
Hello!
This series contains torture-test updates for the rcutorture scripting in
tools/testing/selftests/rcutorture.
1. Make --kcsan specify lockdep.
2. Make kvm.sh "--dryrun sched" summarize number of batches.
3. Make kvm.sh "--dryrun sched" summarize number of builds.
4.
On Wed, Jan 06, 2021 at 01:52:53PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 11:53:59AM +, Mark Rutland wrote:
> > ... and are you using defconfig or something else?
>
> Not sure I replied to this. I'm not using the defconfig, I've my own
> .config
>
> As I
On 1/5/21 8:42 PM, Martin K. Petersen wrote:
>
> Tyrel,
>
>> Drain the command queue and place all commands on a completion list.
>> Perform command completion on that list outside the host/queue locks.
>> Further, move purged command compeletions outside the host_lock as well.
>
> Please
From: "Paul E. McKenney"
The TREE01 rcutorture scenario intentionally creates confusion as to the
number of available CPUs by specifying the "maxcpus=8 nr_cpus=43" kernel
boot parameters. This can disable rcutorture's load shedding, which
currently uses num_online_cpus(), which would count the
From: "Paul E. McKenney"
This commit adds a short delay for verbose_batched-throttled printk()s
to further decrease console flooding.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/refscale.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/refscale.c
From: "Paul E. McKenney"
Full testing of the new SRCU polling API requires that the fake writers
also use it in order to test concurrent calls to all of the API members,
especially start_poll_synchronize_srcu(). This commit prepares the ground
for this by making the synctype[] and nsynctype
From: "Paul E. McKenney"
This commit adds kernel boot parameters torture.verbose_sleep_frequency
and torture.verbose_sleep_duration, which allow VERBOSE_TOROUT_*() output
to be throttled with periodic sleeps on large systems.
Signed-off-by: Paul E. McKenney
---
From: "Paul E. McKenney"
RCU guarantees that anything seen by a given reader will also be seen
after any grace period that must wait on that reader. This is very likely
to hold based on inspection, but the advantage of having rcutorture do
the inspecting is that rcutorture doesn't mind
From: "Paul E. McKenney"
Currently, the rcu_torture_writer() function checks that all required
grace periods elapse during a stutter interval, which is a multi-second
time period during which the test load is removed. However, this check
is suppressed during early boot (that is, before init is
From: "Paul E. McKenney"
The refscale test prints enough per-kthread console output to provoke RCU
CPU stall warnings on large systems. This commit therefore allows this
output to be summarized. For example, the refscale.verbose_batched=32
boot parameter would causes only every 32nd line of
From: "Paul E. McKenney"
This commit adds the desired CPU, the actual CPU, and nr_cpu_ids to
the wrong-CPU warning in scftorture_invoker(), the better to help with
debugging.
Signed-off-by: Paul E. McKenney
---
kernel/scftorture.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
From: "Paul E. McKenney"
Full testing of the new SRCU polling API requires that the fake
writers also use it in order to test concurrent calls to all of the API
members, especially start_poll_synchronize_srcu(). This commit makes
rcu_torture_fakewriter() use all available blocking
From: "Paul E. McKenney"
Because rcu_torture_writer() and rcu_torture_fakewriter() predate
hrtimers, they do timer-wheel-decoupled timed waits by using the
timer-wheel-based schedule_timeout_interruptible() functions in
conjunction with a random udelay()-based wait. This latter unnecessarily
On Wed 06-01-21 16:47:39, Muchun Song wrote:
> The page_huge_active() can be called from scan_movable_pages() which
> do not hold a reference count to the HugeTLB page. So when we call
> page_huge_active() from scan_movable_pages(), the HugeTLB page can
> be freed parallel. Then we will trigger a
From: "Paul E. McKenney"
This commit adds torture_hrtimeout_ns(), torture_hrtimeout_us(),
torture_hrtimeout_ms(), torture_hrtimeout_jiffies(), and
torture_hrtimeout_s(), each of which uses hrtimers to block for a fuzzed
time interval. These functions are intended to be used by the various
From: "Paul E. McKenney"
This commit saves a few lines of code by making the stutter_wait()
and torture_stutter() functions use torture_hrtimeout_jiffies() and
torture_hrtimeout_us().
Signed-off-by: Paul E. McKenney
---
kernel/torture.c | 20 +---
1 file changed, 5
From: "Paul E. McKenney"
RCU's rcutree.use_softirq=0 kernel boot parameter substitutes the per-CPU
rcuc kthreads for softirq, which is used in real-time installations.
However, none of the rcutorture scenarios test this parameter.
This commit therefore adds rcutree.use_softirq=0 to the RUDE01
From: "Paul E. McKenney"
This commit replaces schedule_timeout_uninterruptible() and
schedule_timeout_interruptible() with torture_hrtimeout_us() and
torture_hrtimeout_jiffies() to avoid timer-wheel synchronization.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 7 +++
1
From: "Paul E. McKenney"
This commit puts all CPUs back online at the end of a torture test,
and also unconditionally puts them online at the beginning of the test,
rather than just in the case of built-in tests. This allows torture tests
to behave in a predictable manner, whether built-in or
From: "Paul E. McKenney"
The advent of commit 06249738a41a ("workqueue: Manually break affinity
on hotplug") means that the scheduler no longer silently breaks affinity
for kthreads pinned to the outgoing CPU. This can happen for many of
rcutorture's kthreads due to shuffling, which
From: "Paul E. McKenney"
This commit provides a test for call_rcu() printing the allocation address
of a double-freed callback by double-freeing a callback allocated via
kmalloc(). However, this commit does not depend on any other commit.
Signed-off-by: Paul E. McKenney
---
Hello!
This series provides torture-test updates, and must be applied on top
of the SRCU series.
1. Add testing for RCU's global memory ordering.
2. Add debug output for wrong-CPU warning.
3. Allow summarization of verbose output.
4. Require entire stutter period be
On Thu 31-12-20 00:55:59, Shiyang Ruan wrote:
> With the support of ->rmap(), it is possible to obtain the superblock on
> a mapped device.
>
> If a pmem device is used as one target of mapped device, we cannot
> obtain its superblock directly. With the help of SYSFS, the mapped
> device can be
On Tue, Jan 5, 2021 at 10:32 PM Dongseok Yi wrote:
>
> On 2021-01-06 12:07, Willem de Bruijn wrote:
> >
> > On Tue, Jan 5, 2021 at 8:29 PM Dongseok Yi wrote:
> > >
> > > On 2021-01-05 06:03, Willem de Bruijn wrote:
> > > >
> > > > On Mon, Jan 4, 2021 at 4:00 AM Dongseok Yi wrote:
> > > > >
> >
On Wed, Jan 06, 2021 at 09:09:44AM -0800, Florian Fainelli wrote:
> BCM72116 features a 28nm integrated EPHY, add an entry to match this PHY
> OUI.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
Hi Eric,
The patch looks correct to me. kvm_vgic_addr() masks out all the bits except
index
from addr, so we don't need to do it in vgic_get_common_attr():
Reviewed-by: Alexandru Elisei
One nitpick below.
On 12/12/20 6:50 PM, Eric Auger wrote:
> The doc says:
> "The characteristics of a
On Wed 06-01-21 16:47:38, Muchun Song wrote:
> There is a race between isolate_huge_page() and __free_huge_page().
>
> CPU0: CPU1:
>
> if (PageHuge(page))
> put_page(page)
>
On Wed, Jan 06, 2021, Vitaly Kuznetsov wrote:
> Nitesh Narayan Lal writes:
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 3f7c1fc7a3ce..3e17c9ffcad8 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -9023,18 +9023,7 @@ static int vcpu_enter_guest(struct
On Wed, Jan 6, 2021 at 11:54 AM David Woodhouse wrote:
>
> On Tue, 2021-01-05 at 16:40 +0100, Christian König wrote:
> > Am 05.01.21 um 13:20 schrieb Huang Rui:
> > > On Tue, Jan 05, 2021 at 07:43:51PM +0800, Borislav Petkov wrote:
> > > > On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui
BCM72116 features a 28nm integrated EPHY, add an entry to match this PHY
OUI.
Signed-off-by: Florian Fainelli
---
drivers/net/phy/bcm7xxx.c | 2 ++
include/linux/brcmphy.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index
On 1/6/21 6:42 AM, Sieng Piaw Liew wrote:
> Use existing rx processed count to track against budget, thereby making
> budget decrement operation redundant.
>
> rx_desc_count can be calculated outside the rx loop, making the loop a
> bit smaller.
>
> Signed-off-by: Sieng Piaw Liew
Acked-by:
On 1/6/21 6:42 AM, Sieng Piaw Liew wrote:
> We can increase the efficiency of rx path by using buffers to receive
> packets then build SKBs around them just before passing into the network
> stack. In contrast, preallocating SKBs too early reduces CPU cache
> efficiency.
>
> Check if we're in
On Wed 06-01-21 16:47:37, Muchun Song wrote:
> When dissolve_free_huge_page() races with __free_huge_page(), we can
> do a retry. Because the race window is small.
Is this a bug fix or mere optimization. I have hard time to tell from
the description.
> Signed-off-by: Muchun Song
> ---
>
On 1/6/21 6:42 AM, Sieng Piaw Liew wrote:
> The rx SKB ring use the same code for cleanup at various points.
> Combine them into a function to reduce lines of code.
>
> Signed-off-by: Sieng Piaw Liew
Acked-by: Florian Fainelli
--
Florian
On 1/6/21 6:42 AM, Sieng Piaw Liew wrote:
> Use netdev_alloc_skb_ip_align on newer SoCs with integrated switch
> (enetsw) when refilling RX. Increases packet processing performance
> by 30% (with netif_receive_skb_list).
>
> Non-enetsw SoCs cannot function with the extra pad so continue to use
>
On 1/6/21 6:42 AM, Sieng Piaw Liew wrote:
> Support bulking hardware TX queue by using netdev_xmit_more().
>
> Signed-off-by: Sieng Piaw Liew
Acked-by: Florian Fainelli
--
Florian
On 1/6/21 6:42 AM, Sieng Piaw Liew wrote:
> Add Byte Queue Limits support to reduce/remove bufferbloat in
> bcm63xx_enet.
>
> Signed-off-by: Sieng Piaw Liew
Acked-by: Florian Fainelli
--
Florian
On 1/6/21 6:42 AM, Sieng Piaw Liew wrote:
> Use netif_receive_skb_list to batch process rx skb.
> Tested on BCM6328 320 MHz using iperf3 -M 512, increasing performance
> by 12.5%.
>
> Before:
> [ ID] Interval Transfer Bandwidth Retr
> [ 4] 0.00-30.00 sec 120 MBytes 33.7
On 1/6/21 6:42 AM, Sieng Piaw Liew wrote:
> This patch series aim to improve the bcm63xx_enet driver by integrating the
> latest networking features, i.e. batched rx processing, BQL, build_skb,
> etc.
>
> The newer enetsw SoCs are found to be able to do unaligned rx DMA by adding
> NET_IP_ALIGN
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index b0ea17da8ff6..654649556306 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -273,6 +273,24 @@ Contact: Daniel Vetter, Noralf Tronnes
Level: Advanced
+Garbage collect fbdev scrolling
I'm announcing the release of the 5.4.87 kernel.
All users of the 5.4 kernel series must upgrade.
The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-5.4.y
and can be browsed at the normal kernel.org git web browser:
On Wed, 6 Jan 2021 08:16:47 +0900 Bongsu Jeon wrote:
> On Tue, Jan 5, 2021 at 4:48 AM Jakub Kicinski wrote:
> > > thank you for your answer.
> > > I think that neard(NFC deamon) is necessary to test the NCI subsystem
> > > meaningfully.
> > > The NCI virtual device in user space can communicate
diff --git a/Makefile b/Makefile
index e1a94c8d278e..71968b4bb313 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 4
-SUBLEVEL = 86
+SUBLEVEL = 87
EXTRAVERSION =
NAME = Kleptomaniac Octopus
diff --git
I'm announcing the release of the 5.10.5 kernel.
All users of the 5.10 kernel series must upgrade.
The updated 5.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-5.10.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Makefile b/Makefile
index d02af6881a5f..e636c2143295 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
-SUBLEVEL = 164
+SUBLEVEL = 165
EXTRAVERSION =
NAME = "People's Front"
diff --git
I'm announcing the release of the 4.19.165 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.19.y
and can be browsed at the normal kernel.org git web
How about this?
David
---
commit 5d370a9db65a6fae82f09a009430ae40c564b0ef
Author: David Howells
Date: Wed Jan 6 16:21:40 2021 +
rxrpc: Fix handling of an unsupported token type in rxrpc_read()
Clang static analysis reports the following:
net/rxrpc/key.c:657:11:
On Tue, Jan 5, 2021 at 7:47 PM Liang Li wrote:
>
> Use the page order as the only threshold for page reporting
> is not flexible and has some flaws. Because scan a long free
> list is not cheap, it's better to wake up the page reporting
> worker when there are more pages, wake it up for a sigle
On Wed 06-01-21 16:47:36, Muchun Song wrote:
> There is a race condition between __free_huge_page()
> and dissolve_free_huge_page().
>
> CPU0: CPU1:
>
> // page_count(page) == 1
> put_page(page)
> __free_huge_page(page)
>
From: "Paul E. McKenney"
This commit adds writer-side testing of the polling grace-period API.
One test verifies that the polling API sees a grace period caused by
some other mechanism. Another test verifies that using the polling API
to wait for a grace period does not result in too-short
From: "Paul E. McKenney"
This commit adds reader-side testing of the polling grace-period API.
This testing verifies that a cookie obtained in an SRCU read-side critical
section does not get a true return from poll_state_synchronize_srcu()
within that same critical section.
Link:
From: "Paul E. McKenney"
This commit adds to the poll_state_synchronize_srcu() header comment
describing the issues surrounding SRCU cookie overflow/wrap for the
different kernel configurations.
Link: https://lore.kernel.org/rcu/20201112201547.gf3365...@moria.home.lan/
Reported-by: Kent
From: "Paul E. McKenney"
There is a need for a polling interface for SRCU grace periods.
This polling needs to initiate an SRCU grace period without having
to queue (and manage) a callback. This commit therefore splits the
Tree SRCU __call_srcu() function into callback-initialization and
From: "Paul E. McKenney"
The new get_state_synchronize_srcu(), start_poll_synchronize_srcu() and
poll_state_synchronize_srcu() functions need to be tested, and so this
commit prepares by renaming the rcu_torture_ops field ->get_state to
->get_gp_state in order to be consistent with the upcoming
From: "Paul E. McKenney"
There is a need for a polling interface for SRCU grace
periods, so this commit supplies get_state_synchronize_srcu(),
start_poll_synchronize_srcu(), and poll_state_synchronize_srcu() for this
purpose. The first can be used if future grace periods are inevitable
(perhaps
From: "Paul E. McKenney"
This commit adds requirements documentation for the
get_state_synchronize_srcu(), start_poll_synchronize_srcu(), and
poll_state_synchronize_srcu() functions.
Link: https://lore.kernel.org/rcu/20201112201547.gf3365...@moria.home.lan/
Reported-by: Kent Overstreet
From: "Paul E. McKenney"
There is a need for a polling interface for SRCU grace
periods, so this commit supplies get_state_synchronize_srcu(),
start_poll_synchronize_srcu(), and poll_state_synchronize_srcu() for this
purpose. The first can be used if future grace periods are inevitable
(perhaps
From: "Paul E. McKenney"
There is a need for a polling interface for SRCU grace periods. This
polling needs to distinguish between an SRCU instance being idle on the
one hand or in the middle of a grace period on the other. This commit
therefore converts the Tiny SRCU srcu_struct structure's
From: "Paul E. McKenney"
There is a need for a polling interface for SRCU grace periods.
This polling needs to initiate an SRCU grace period without
having to queue (and manage) a callback. This commit therefore
splits the Tiny SRCU call_srcu() function into callback-queuing and
Hello!
This series contains SRCU updates, most notably the polling grace-period
API requested by Kent Overstreet.
1. Make Tiny SRCU use multi-bit grace-period counter.
2. Provide internal interface to start a Tiny SRCU grace period.
3. Provide internal interface to start a Tree
On Tue, 2021-01-05 at 16:40 +0100, Christian König wrote:
> Am 05.01.21 um 13:20 schrieb Huang Rui:
> > On Tue, Jan 05, 2021 at 07:43:51PM +0800, Borislav Petkov wrote:
> > > On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui wrote:
> > > > Ah, this asic is a bit old and still use radeon driver.
From: Neeraj Upadhyay
For a new grace period request, the RCU GP kthread transitions through
following states:
a. [RCU_GP_WAIT_GPS] -> [RCU_GP_DONE_GPS]
The RCU_GP_WAIT_GPS state is where the GP kthread waits for a request
for a new GP. Once it receives a request (for example, when a new RCU
From: "Paul E. McKenney"
Currently, RCU CPU stall warning messages will NMI whatever CPU looks
like it is blocking either the current grace period or the grace-period
kthread. This can produce confusing output if the target CPU is offline.
This commit therefore checks for offline CPUs.
From: "Paul E. McKenney"
When the RCU CPU stall-warning code detects that the RCU grace-period
kthread is being starved, it dumps that kthread's stack. This can
sometimes be useful, but it is also useful to know what is running on the
CPU that this kthread is attempting to run on. This commit
From: "Paul E. McKenney"
There is a rather obtuse string that can be printed as part of an
expedited RCU CPU stall-warning message that starts with "blocking
rcu_node structures". Under normal conditions, most of this message
is just repeating the list of CPUs blocking the current expedited
Hello!
This series enhances RCU CPU stall-warning messages.
1. Mark obtuse portion of stall warning as internal debug.
2. For RCU grace-period kthread starvation, dump last CPU it ran on.
3. Do not NMI offline CPUs.
4. Check and report missed fqs timer wakeup on RCU stall,
On Tue, Jan 05, 2021 at 08:03:20AM +, tudor.amba...@microchip.com wrote:
> On 1/4/21 1:02 PM, Greg KH wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Wed, Sep 23, 2020 at 08:19:18AM +, tudor.amba...@microchip.com wrote:
On 1/5/21 7:30 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210105:
on x86_64:
ld: drivers/gpu/drm/imx/dw_hdmi-imx.o: in function `dw_hdmi_imx_probe':
dw_hdmi-imx.c:(.text+0x29f): undefined reference to `of_drm_find_bridge'
Full randconfig file is attached.
--
~Randy
From: Scott Wood
PREEMPT_RT systems have long used the rcutree.use_softirq kernel
boot parameter to avoid use of RCU_SOFTIRQ handlers, which can disrupt
real-time applications by invoking callbacks during return from interrupts
that arrived while executing time-critical code. This kernel boot
From: Julia Cartwright
Expedited RCU grace periods send IPIs to all non-idle CPUs, and thus can
disrupt time-critical code in real-time applications. However, there
is a portion of boot-time processing (presumably before any real-time
applications have started) where expedited RCU grace periods
From: Sebastian Andrzej Siewior
On PREEMPT_RT kernels, RCU callbacks are deferred to the `rcuc' kthread.
This can stall RCU grace periods due to lengthy preemption not only of RCU
readers but also of 'rcuc' kthreads, either of which prevent grace periods
from completing, which can in turn result
Hi,
On Wednesday 06 Jan 2021 at 16:13:53 (+), Al Viro wrote:
> On Wed, Jan 06, 2021 at 03:52:14PM +, Ionela Voinescu wrote:
> > > > > > vim +367 arch/arm64/kernel/topology.c
> > > > > >
> > > > > >362
> > > > > >363 int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64
On Wed 06 Jan 06:53 CST 2021, Manivannan Sadhasivam wrote:
> Hi Bjorn,
>
> This series updates devicetree for the SDX55 platform and the MTP board.
> Most of the SDX55 specific driver codes are already merged and some of
> existing driver support got reused.
>
> Thanks,
> Mani
>
Thanks Mani,
Hello!
This series provides some real-time enhancements:
1. Make RCU_BOOST default on CONFIG_PREEMPT_RT, courtesy of Sebastian
Andrzej Siewior.
2. Unconditionally use rcuc threads on PREEMPT_RT, courtesy of
Scott Wood.
3. Enable rcu_normal_after_boot
On Wed, Jan 06, 2021 at 01:10:05PM +0300, Dan Carpenter wrote:
> Syzbot discovered that the probe error handling doesn't clean up the
> resources allocated in zr364xx_board_init(). There are several
> related bugs in this code so I have re-written the error handling.
Dan:
I recently sent in a
Hi,
On Fri, Dec 11, 2020 at 2:25 PM Douglas Anderson wrote:
>
> +static const struct goodix_i2c_hid_timing_data goodix_gt7375p_timing_data = {
> + .post_power_delay_ms = 10,
> + .post_gpio_reset_delay_ms = 120,
As I've been going through my holiday email I found that Goodix has
On Wed, 6 Jan 2021 18:56:23 +0800 (GMT+08:00) dinghao@zju.edu.cn
wrote:
> > I used this one for a test:
> >
> > https://patchwork.kernel.org/project/netdevbpf/patch/1609312994-121032-1-git-send-email-abaci-bug...@linux.alibaba.com/
> >
> > I'm not getting the Fixes tag when I download the
On Wed, Jan 06, 2021 at 03:52:01PM +, Matthias Maennich wrote:
> With commit e722a295cf49 ("staging: ion: remove from the tree"), ION and
> its corresponding config CONFIG_ION is gone. Remove stale references
> from drivers/staging/media/atomisp/pci and from the recommended Android
> kernel
On Tue, Jan 05, 2021 at 10:05:20PM -0800, Shakeel Butt wrote:
> On Tue, Jan 5, 2021 at 8:22 PM Roman Gushchin wrote:
> >
> > Imran Khan reported a regression in hackbench results caused by the
> > commit f2fe7b09a52b ("mm: memcg/slab: charge individual slab objects
> > instead of pages"). The
On Wed, Jan 6, 2021 at 6:53 AM Michal Hocko wrote:
>
> On Thu 31-12-20 18:39:55, Shakeel Butt wrote:
> > This patch adds swapcache stat for the cgroup v2. The swapcache
> > represents the memory that is accounted against both the memory and the
> > swap limit of the cgroup. The main motivation
On Wed, Jan 06, 2021 at 04:35:29PM +, Vincenzo Frascino wrote:
>
> On 1/6/21 11:55 AM, Vincenzo Frascino wrote:
> > This patchset implements the asynchronous mode support for ARMv8.5-A
> > Memory Tagging Extension (MTE), which is a debugging feature that allows
> > to detect with the help of
une markup and formatting for better presentation in the HTML view.
>
> Signed-off-by: Lukas Bulwahn
> ---
> v1 -> v2: minor stylistic tuning as suggested by Randy
>
> applies cleanly on current master (v5.11-rc2) and next-20210106
>
> George, please ack.
> Jon
Hi,
On Mon, Jan 04, 2021 at 01:05:13PM +, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a dev_dbg message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/power/supply/max8997_charger.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Hi, Yongqiang:
Yongqiang Niu 於 2021年1月5日 週二 上午11:17寫道：
>
> add mt8192 mmsys support
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/soc/mediatek/mmsys/Makefile | 1 +
> drivers/soc/mediatek/mmsys/mt8192-mmsys.c | 149
> ++
>
On Wed, Dec 30, 2020 at 11:42:05AM +0100, Dylan Van Assche wrote:
> All revisions of the PinePhone share most of the hardware.
> This patch makes it easier to detect PinePhone hardware without
> having to check for each possible revision.
>
> Signed-off-by: Dylan Van Assche
Applied, thanks
On Wed 06-01-21 16:47:35, Muchun Song wrote:
> Because we only can isolate a active page via isolate_huge_page()
> and hugetlbfs_fallocate() forget to mark it as active, we cannot
> isolate and migrate those pages.
I've little bit hard time to understand this initially and had to dive
into the
On Thu, Dec 24, 2020 at 10:41:38AM +0800, Icenowy Zheng wrote:
> As the original PineTab DT (which uses sun50i-a64-pinetab name) is only
> for development samples, document this.
>
> Signed-off-by: Icenowy Zheng
Applied all three patches, thanks for your persistence on this
Maxime
On 1/6/21 2:56 AM, Masanari Iida wrote:
> This patch fixes some spelling typos in Kconfig.
>
> Signed-off-by: Masanari Iida
> ---
> arch/arm/mach-ixp4xx/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-ixp4xx/Kconfig
Hi Eric,
On 12/12/20 6:50 PM, Eric Auger wrote:
> KVM_DEV_ARM_VGIC_GRP_ADDR group doc says we should return
> -EEXIST in case the base address of the redist is already set.
> We currently return -EINVAL.
>
> However we need to return -EINVAL in case a legacy REDIST address
> is attempted to be
On 1/6/21 11:55 AM, Vincenzo Frascino wrote:
> This patchset implements the asynchronous mode support for ARMv8.5-A
> Memory Tagging Extension (MTE), which is a debugging feature that allows
> to detect with the help of the architecture the C and C++ programmatic
> memory errors like buffer
On Tue, 2021-01-05 at 16:41 -0800, paul...@kernel.org wrote:
>
> @@ -203,7 +204,6 @@ static void
> clocksource_watchdog_inject_delay(void)
> injectfail = inject_delay_run;
> if (!(++injectfail / inject_delay_run % inject_delay_freq)) {
> printk("%s(): Injecting
On Wed, 6 Jan 2021 at 09:35, Barry Song wrote:
>
> ARM64 server chip Kunpeng 920 has 6 clusters in each NUMA node, and each
> cluster has 4 cpus. All clusters share L3 cache data, but each cluster
> has local L3 tag. On the other hand, each clusters will share some
> internal system bus. This
Clean probe and remove port deinit by moving clk_disable_unprepare in a
new dedicated deinit_port function.
Signed-off-by: Erwan Le Ray
Signed-off-by: Etienne Carriere
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 0d6c7f3375f0..9d73f6976586 100644
---
The transmission complete error message provides the status of the
ISR_USART_TC bit. This bit, when set, indicates that the transmission
has not been completed.
The bit status indication is not a very understandable information.
The error message sent on console should indicate that the
The comment for conflicting RTS/CTS config refers to "st, hw-flow-ctrl",
but this property is deprecated since the generic RTS/CTS property has
been introduced by the patch 'serial: stm32: Use generic DT binding for
announcing RTS/CTS lines'.
Update the comment to refer to both generic and
On Tue, Jan 05, 2021 at 11:04:15PM +, Dexuan Cui wrote:
> > From: Wei Liu
> > Sent: Tuesday, January 5, 2021 4:58 AM
> > > ...
> > > Documentation/ABI/stable/sysfs-bus-vmbus | 7 +++
> > > drivers/hv/vmbus_drv.c | 20
> >
> > > 2 files changed, 27
Update rts-gpios and cts-gpios:
- remove max-items as already defined in serial.yaml
- add a note describing rts-gpios and cts-gpios usage with stm32
Document the use of cts-gpios and rts-gpios for flow control in STM32 UART
controller. These properties can be used instead of 'uart-has-rtscts' or
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Tony-Lindgren/Lost-key-up-interrupt-handling-for-omap4-keypad/20210106-210045
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
601 - 700 of 1126 matches
Mail list logo
