On Wed, 7 Apr 2021 20:59:03 +0800, Yu Kuai wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/kernel/smp.c:86:1: warning:
> symbol '__pcpu_scope_cpu_coregroup_map' was not declared. Should it be
> static?
> arch/powerpc/kernel/smp.c:125:1: warning:
> symbol '__pcpu_scope_thread_gro
On Wed, 7 Apr 2021 20:57:12 +0800, Yu Kuai wrote:
> The sparse tool complains as follows:
>
> drivers/macintosh/windfarm_pm121.c:436:24: warning:
> symbol 'pm121_sys_state' was not declared. Should it be static?
>
> This symbol is not used outside of windfarm_pm121.c, so this
> commit marks it s
On Wed, 7 Apr 2021 20:57:38 +0800, Yu Kuai wrote:
> The sparse tool complains as follows:
>
> drivers/macintosh/windfarm_core.c:59:20: warning:
> symbol 'wf_thread' was not declared. Should it be static?
>
> This symbol is not used outside of windfarm_core.c, so this
> commit marks it static.
A
On Thu, 17 Sep 2020 06:54:37 -0700, Tony Ambardar wrote:
> A few archs like powerpc have different errno.h values for macros
> EDEADLOCK and EDEADLK. In code including both libc and linux versions of
> errno.h, this can result in multiple definitions of EDEADLOCK in the
> include chain. Definitions
We have a mismatch between RCU and isolation -- in relation to what is
considered the maximum valid CPU number.
This matters because nohz_full= and rcu_nocbs= are joined at the hip; in
fact the former will enforce the latter. So we don't want a CPU mask to
be valid for one and denied for the othe
From: Alice Guo
In patch "soc: imx8m: change to use platform driver", change soc-imx8m.c to use
module platform driver and use NVMEM APIs to ocotp register, the reason is that
directly reading ocotp egister causes kexec kernel hang because kernel will
disable unused clks after kernel boots up. Th
From: Alice Guo
In i.MX8M boards, the registration of SoC device is later than caam
driver which needs it. Caam driver needs soc_device_match to provide
-EPROBE_DEFER when no SoC device is registered and no
early_soc_dev_attr.
Signed-off-by: Alice Guo
---
drivers/base/soc.c | 5 +
1 file c
From: Alice Guo
When imx8_soc_info_driver uses module_platform_driver() to regitser
itself, the caam driver cannot identify the SoC in the machine because
the SoC driver is probed later, so that add return -EPROBE_DEFER.
Signed-off-by: Alice Guo
---
drivers/crypto/caam/ctrl.c | 3 +++
1 file c
From: Alice Guo
Update all the code that use soc_device_match because add support for
soc_device_match returning -EPROBE_DEFER.
Signed-off-by: Alice Guo
---
drivers/bus/ti-sysc.c | 2 +-
drivers/clk/renesas/r8a7795-cpg-mssr.c| 4 +++-
drivers/clk/renesas/rcar-
First comment overall for the whole serie:
Since it is the solution I had suggested when I reported the problem[1]
I have no qualm on the approach, comments for individual patches
follow.
[1] http://lore.kernel.org/r/YGGZJjAxA1IO+/v...@atmark-techno.com
Alice Guo (OSS) wrote on Mon, Apr 19, 2021
Hello!
If there is a sufficient delay between reading the watchdog clock and the
clock under test, the clock under test will be marked unstable through no
fault of its own. This series checks for this, doing limited retries
to get a good set of clock reads. If the clock is marked unstable
and is
When the clocksource watchdog marks a clock as unstable, this might be due
to that clock being unstable or it might be due to delays that happen to
occur between the reads of the two clocks. Yes, interrupts are disabled
across those two reads, but there are no shortage of things that can
delay int
Some sorts of per-CPU clock sources have a history of going out of
synchronization with each other. However, this problem has purportedy
been solved in the past ten years. Except that it is all too possible
that the problem has instead simply been made less likely, which might
mean that some of t
Currently, if skew is detected on a clock marked CLOCK_SOURCE_VERIFY_PERCPU,
that clock is checked on all CPUs. This is thorough, but might not be
what you want on a system with a few tens of CPUs, let alone a few hundred
of them.
Therefore, by default check only up to eight randomly chosen CPUs.
Currently, WATCHDOG_THRESHOLD is set to detect a 62.5-millisecond skew in
a 500-millisecond WATCHDOG_INTERVAL. This requires that clocks be skewed
by more than 12.5% in order to be marked unstable. Except that a clock
that is skewed by that much is probably destroying unsuspecting software
right
Code that checks for clock desynchronization must itself be tested, so
create a new clocksource.inject_delay_shift_percpu= kernel boot parameter
that adds or subtracts a large value from the check read, using the
specified bit of the CPU ID to determine whether to add or to subtract.
Cc: John Stul
When the clocksource watchdog marks a clock as unstable, this might
be due to that clock being unstable or it might be due to delays that
happen to occur between the reads of the two clocks. Yes, interrupts are
disabled across those two reads, but there are no shortage of things that
can delay int
On Sat, Apr 17, 2021 at 12:45:59AM +0800, Zhou Yanjie wrote:
>
> On 2021/4/16 下午5:20, 黄沛 wrote:
> > Is there any log about the panic?
>
>
> Yes, below is the log:
>
>
> [ 195.436017] CPU 0 Unable to handle kernel paging request at virtual
> address 77eb8000, epc == 80117868, ra == 80118208
>
On 4/17/21 1:26 AM, Paul E. McKenney wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Fri, Apr 16, 2021 at 06:51:10PM +0800, Xu, Yanfei wrote:
On 4/16/21 1:07 AM, Paul E. McKenney wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Fri, Apr 16,
On Mon, Apr 19, 2021 at 12:27:22PM +0800, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
>
> Signed-off-by: Alice Guo
> ---
> drivers/bus/ti-sysc.c | 2 +-
>
Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> From: Alice Guo
>
> Update all the code that use soc_device_match
A single patch might be difficult to accept for all components, a each
maintainer will probably want to have a say on their subsystem?
I would suggest to split the
Intel IPU(Image Processing Unit) has its own (IO)MMU hardware,
The IPU driver allocates its own page table that is not mapped
via the DMA, and thus the Intel IOMMU driver blocks access giving
this error:
DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Read] Request device [00:05.0] PASID ff
On 2021-03-30 17:44:27, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> There is more to do in filesystems. Another set will follow.
>
> Lee Jones (31):
...
> fs: ec
On Fri, Apr 16, 2021 at 11:39 AM Alan Stern wrote:
>
> On Fri, Apr 16, 2021 at 09:24:30AM +0800, Chris Chiu wrote:
> > On Fri, Apr 16, 2021 at 2:46 AM Alan Stern
> > wrote:
> > >
> > > On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> > > > One thing worth mentioning here, I never hi
On Wed, Apr 14, 2021 at 01:09:47PM -0700, Shakeel Butt wrote:
> On Wed, Apr 14, 2021 at 12:42 PM Jesper Dangaard Brouer
> wrote:
> >
> [...]
> > > >
> > > > Can this page_pool be used for TCP RX zerocopy? If yes then PageType
> > > > can not be used.
> > >
> > > Yes it can, since it's going to be
Hi Moritz,
Please find my response inline.
> -Original Message-
> From: Moritz Fischer
> Sent: Saturday, April 10, 2021 3:01 AM
> To: Nava kishore Manne
> Cc: m...@kernel.org; t...@redhat.com; robh...@kernel.org; Michal Simek
> ; linux-f...@vger.kernel.org;
> devicet...@vger.ker
From: Pierre-Louis Bossart
Existing devices and implementations only support the required
CLOCK_STOP_MODE0. All the code related to CLOCK_STOP_MODE1 has not
been tested and is highly questionable, with a clear confusion between
CLOCK_STOP_MODE1 and the simple clock stop state machine.
This patch
Existing devices and implementations only support the required
CLOCK_STOP_MODE0. All the code related to CLOCK_STOP_MODE1 has not
been tested and is highly questionable, with a clear confusion between
CLOCK_STOP_MODE1 and the simple clock stop state machine.
This patch removes all usages of CLOCK_
From: Pierre-Louis Bossart
For some reason we never added a description for the clk_stop
callback.
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Rander Wang
Signed-off-by: Bard Liao
---
include/linux/soundwire/sdw.h | 1 +
1 file changed, 1 insertion(+)
From: Pierre-Louis Bossart
If a device lost sync and can no longer ACK a command, it may not be
able to enter a lower-power state but it will still be able to resync
when the clock restarts. In those cases, we want to continue with the
clock stop sequence.
This patch modifies the behavior during
From: Pierre-Louis Bossart
They were missed in previous contributions.
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Rander Wang
Signed-off-by: Bard Liao
---
drivers/soundwire/bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
I need your assistance, Reply for more details. davidbrown1...@juno.com or
Call: + 1 918 397 9602
On Thu, Apr 08, 2021 at 11:51:36PM -0300, Leonardo Bras wrote:
> Hello David, thanks for the feedback!
>
> On Mon, 2021-03-22 at 18:55 +1100, David Gibson wrote:
> > > +void hash_memory_batch_expand_prepare(unsigned long newsize)
> > > +{
> > > + /*
> > > + * Resizing-up HPT should never fail, bu
On Fri, Apr 09, 2021 at 12:31:03AM -0300, Leonardo Bras wrote:
> Hello David, thanks for commenting.
>
> On Tue, 2021-03-23 at 10:45 +1100, David Gibson wrote:
> > > @@ -805,6 +808,10 @@ static int resize_hpt_for_hotplug(unsigned long
> > > new_mem_size, bool shrinking)
> > > if (shrinking) {
>
Hi Salvatore,
Attached is a proposed fix from Paulo for older kernels.
Can you please confirm that this works for you too?
Regards,
Shyam
-Original Message-
From: Salvatore Bonaccorso On Behalf Of
Salvatore Bonaccorso
Sent: Sunday, April 18, 2021 6:11 PM
To: Greg Kroah-Hartman
Cc:
On 2021-02-26 15:00:23, Jeffrey Mitchell wrote:
> When mounting eCryptfs, a null "dev_name" argument to ecryptfs_mount()
> causes a kernel panic if the parsed options are valid. The easiest way to
> reproduce this is to call mount() from userspace with an existing
> eCryptfs mount's options and a "
I need your assistance, Reply for more details. davidbrown1...@juno.com or
Call: + 1 918 397 9602
In preparation for mips supporting ftrace built on other compiler
options, let's have the mips Makefiles remove the $(CC_FLAGS_FTRACE)
flags, whatever these may be, rather than assuming '-pg'.
Signed-off-by: zhaoxiao
---
v2:add this same change be appropriate to all of the below Makefile.
arch/
Hi, Linux mfd reviewers:
It's been three weeks not to get any response from you.
Is there something wrong about this mfd patch?
If yes, please feel free to let me know.
cy_huang 於 2021年3月28日 週日 下午11:24寫道：
>
> From: ChiYuan Huang
>
> This adds support Richtek RT4831 core. It includes four chan
Commit aa2f62cf211a ("Input: add driver for the Hycon HY46XX touchpanel
series") adds the file ./drivers/input/touchscreen/hycon-hy46xx.c, but the
file entry in MAINTAINERS refers to ./drivers/input/touchscreen/hy46xx.c.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning
On Sat, Apr 17, 2021 at 11:51 PM Masahiro Yamada wrote:
>
> Commit 3b9fa0931dd8 ("[PATCH] Kconfig i18n support") added this code,
> and then commit ("kconfig: drop localization support") removed the
> i18n support entirely.
>
> Remove the left-over.
>
> Signed-off-by: Masahiro Yamada
> ---
Both
On Sun, Apr 18, 2021 at 2:51 PM Randy Dunlap wrote:
>
> Mark Kconfig "comment" lines with "*** ***"
> so that it is clear that these lines are comments and not some
> kconfig item that cannot be modified.
>
> This is helpful in some menus to be able to provide a menu
> "sub-heading" for groups of
s/when the camera active/when the camera is active/
s/thus not isr protection/thus no ISR protection/
Signed-off-by: Sebastian Fricke
---
drivers/media/platform/rockchip/rkisp1/rkisp1-params.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/rockchip/rki
Hello,
Svyatoslav and me found that the MPU3050 IIO driver reports temperature
that is x10 larger than it should be on Asus Transformer TF201 and Acer
A500 tablet devices running mainline kernel. The driver uses
(x+23000)/280 formula for the conversion of raw temperature value, which
gives 82C for
On Mon, Apr 19, 2021 at 8:01 AM Waiman Long wrote:
>
> There are two issues with the current refill_obj_stock() code. First of
> all, when nr_bytes reaches over PAGE_SIZE, it calls drain_obj_stock() to
> atomically flush out remaining bytes to obj_cgroup, clear cached_objcg
> and do a obj_cgroup_p
> > @@ -167,6 +168,7 @@ void blk_queue_max_hw_sectors(struct request_queue *q,
> > unsigned int max_hw_secto
> > max_sectors = round_down(max_sectors,
> > limits->logical_block_size >> SECTOR_SHIFT);
> > limits->max_sectors = max_sectors;
> > + limits->bio_ma
On Fri, Apr 16, 2021 at 03:25:03PM +, Michael Kelley wrote:
> From: Andrea Parri (Microsoft) Sent: Friday, April
> 16, 2021 7:40 AM
> >
> > If a malicious or compromised Hyper-V sends a spurious message of type
> > CHANNELMSG_UNLOAD_RESPONSE, the function vmbus_unload_response() will
> > cal
On 4/18/21 5:33 AM, Hillf Danton wrote:
On Sat, 17 Apr 2021 14:37:57 Junxiao Bi wrote:
On 4/17/21 3:10 AM, Hillf Danton wrote:
+ if (acquire_inflight_cb(rqw, private_data))
This function is to increase atomic variable rq_wait->inflight.
You are right.
What's the mutex for?
It cut
Thanks for your advice. I will fix these patches and resend them as soon as
possilble.
On 2021/4/19 11:30, Anshuman Khandual wrote:
>
> On 4/9/21 9:35 AM, Anshuman Khandual wrote:
>> On 4/6/21 10:18 AM, Shixin Liu wrote:
>>> v1->v2:
>>> Modified the commit message.
>> Please avoid change log in
In preparation for x86 supporting ftrace built on other compiler
options, let's have the x86 Makefiles remove the $(CC_FLAGS_FTRACE)
flags, whatever these may be, rather than assuming '-pg'.
Signed-off-by: zhaoxiao
---
v3:add the same change in the arch/x86/um/vdso/Makefile.
arch/x86/entry/vdso/
Hello Mel,
On Mon, Apr 12, 2021 at 11:48:19AM +0100, Mel Gorman wrote:
> On Mon, Apr 12, 2021 at 11:06:19AM +0100, Valentin Schneider wrote:
> > On 12/04/21 10:37, Mel Gorman wrote:
> > > On Mon, Apr 12, 2021 at 11:54:36AM +0530, Srikar Dronamraju wrote:
> > >> * Gautham R. Shenoy [2021-04-02 11:
On 2021/4/19 10:20, Wan Jiabing wrote:
struct dnode_of_data is defined at 897th line.
The declaration here is unnecessary. Remove it.
Signed-off-by: Wan Jiabing
Reviewed-by: Chao Yu
Thanks,
Commit 5a517b5bf687 ("i2c: designware: Get rid of legacy platform data")
removes ./include/linux/platform_data/i2c-designware.h, but misses to
adjust the SYNOPSYS DESIGNWARE I2C DRIVER section in MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file ma
On Mon, Apr 19, 2021 at 09:00:07AM +0900, Nobuhiro Iwamatsu wrote:
> Add driver for the PWM controller on Toshiba Visconti ARM SoC.
>
> Signed-off-by: Nobuhiro Iwamatsu
Reviewed-by: Uwe Kleine-König
Thanks for your endurance to improve the driver
Uwe
--
Pengutronix e.K.
Ilya Lipnitskiy writes:
> Add missing binding documentation for SoC support that has been in place
> since v5.1
>
> Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet
> hardware")
> Cc: Bjørn Mork
> Signed-off-by: Ilya Lipnitskiy
> ---
> Documentation/devicetree/bindin
Hi Rik,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on linux/master linus/master v5.12-rc8 next-20210416]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '-
On Fri, Apr 16, 2021 at 04:27:55PM +0100, Matthew Wilcox wrote:
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > See below patch. Where I swap32 the dma address to satisfy
> > page->compound having bit zero cleared. (It is the simplest fix I could
> > come up with).
>
Hi,
This series is the PCIe driver for Toshiba's ARM SoC, Visconti[0].
This provides DT binding documentation, device driver, MAINTAINER files.
Best regards,
Nobuhiro
[0]:
https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html
dt-bindings
Add entries for Toshiba Visconti PCIe controller binding and driver.
Signed-off-by: Nobuhiro Iwamatsu
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8a154939ae27..3e5187c5b8d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2621,11 +2621,13 @
Add support to PCIe RC controller on Toshiba Visconti ARM SoCs. PCIe controller
is based of Synopsys
DesignWare PCIe core.
This patch does not yet use the clock framework to control the clock. This will
be replaced in the
future.
Signed-off-by: Yuji Ishikawa
Signed-off-by: Nobuhiro Iwamatsu
-
This commit adds the Device Tree binding documentation that allows
to describe the PCIe controller found in Toshiba Visconti SoCs.
Signed-off-by: Nobuhiro Iwamatsu
---
.../bindings/pci/toshiba,visconti-pcie.yaml | 110 ++
1 file changed, 110 insertions(+)
create mode 100644
D
> Message du 19/04/21 01:03
> De : "Bart Van Assche"
> A : "Christophe JAILLET" , t...@kernel.org, jiangshan...@gmail.com,
> sae...@nvidia.com, l...@kernel.org, da...@davemloft.net, k...@kernel.org,
> "Tejun Heo"
> Copie à : net...@vger.kernel.org, linux-r...@vger.kernel.org,
> linux-kernel
On Thu, Apr 15, 2021 at 04:24:15PM -0400, Konrad Rzeszutek Wilk wrote:
> So you are exposing these two:
> EXPORT_SYMBOL_GPL(get_vm_area);
> EXPORT_SYMBOL_GPL(ioremap_page_range);
>
> But if you used vmap wouldn't you get the same thing for free?
Yes, this needs to go into some vmap version, pre
This series enabled Intel FGPA SmartNIC C5000X-PL virtio-blk for vDPA.
This series requires:
Stefano's vdpa block patchset: https://lkml.org/lkml/2021/3/15/2113
my patchset to enable Intel FGPA SmartNIC C5000X-PL virtio-net for vDPA:
https://lkml.org/lkml/2021/3/17/432
changes from V3:
remove (pd
This commit deduces VIRTIO device ID as device type when probe,
then ifcvf_vdpa_get_device_id() can simply return the ID.
ifcvf_vdpa_get_features() and ifcvf_vdpa_get_config_size()
can work properly based on the device ID.
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_base.h | 1 +
d
This commit enabled Intel FPGA SmartNIC C5000X-PL virtio-block
for vDPA.
Signed-off-by: Zhu Lingshan
Reviewed-by: Stefano Garzarella
Acked-by: Jason Wang
---
drivers/vdpa/ifcvf/ifcvf_base.h | 8 +++-
drivers/vdpa/ifcvf/ifcvf_main.c | 19 ++-
2 files changed, 25 insertions(
get_config_size() should return the size based on the decected
device type.
Signed-off-by: Zhu Lingshan
Reviewed-by: Stefano Garzarella
Acked-by: Jason Wang
---
drivers/vdpa/ifcvf/ifcvf_main.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/
Hi Paolo,
On 2021/4/17 21:23, Paolo Bonzini wrote:
On 30/03/21 10:08, Yanan Wang wrote:
In addition to function of CLOCK_MONOTONIC, flag CLOCK_MONOTONIC_RAW can
also shield possiable impact of NTP, which can provide more robustness.
Suggested-by: Vitaly Kuznetsov
Signed-off-by: Yanan Wang
Revi
> -Original Message-
> From: Dominique MARTINET
> Sent: 2021年4月19日 12:49
> To: Alice Guo (OSS)
> Cc: gre...@linuxfoundation.org; raf...@kernel.org; Horia Geanta
> ; Aymen Sghaier ;
> herb...@gondor.apana.org.au; da...@davemloft.net; t...@atomide.com;
> geert+rene...@glider.be; mturque...
From: Shixin Liu
The functions {pmd/pud}_set_huge and {pmd/pud}_clear_huge are not dependent
on THP. Hence move {pmd/pud}_huge_tests out of CONFIG_TRANSPARENT_HUGEPAGE.
Signed-off-by: Shixin Liu
Reviewed-by: Anshuman Khandual
---
v2->v3:
Modified the commit message and fix a checkpatch warning
From: Shixin Liu
Remove redundant pfn_{pmd/pte}() in {pmd/pte}_advanced_tests()
and adjust pfn_pud() in pud_advanced_tests() to make it similar with
other two functions.
In addition, the branch condition should be CONFIG_TRANSPARENT_HUGEPAGE
instead of CONFIG_ARCH_HAS_PTE_DEVMAP.
Signed-off-by:
On 2021/4/19 10:48, Huang, Ying wrote:
> Miaohe Lin writes:
>
>> We will use percpu-refcount to serialize against concurrent swapoff. This
>> patch adds the percpu_ref support for swap.
>>
>> Signed-off-by: Miaohe Lin
>> ---
>> include/linux/swap.h | 3 +++
>> mm/swapfile.c| 33 +++
> -Original Message-
> From: Leon Romanovsky
> Sent: 2021年4月19日 13:02
> To: Alice Guo (OSS)
> Cc: gre...@linuxfoundation.org; raf...@kernel.org; Horia Geanta
> ; Aymen Sghaier ;
> herb...@gondor.apana.org.au; da...@davemloft.net; t...@atomide.com;
> geert+rene...@glider.be; mturque...@b
On Fri Apr 16 2021, Yangbo Lu wrote:
> Optimization could be done on dsa_skb_tx_timestamp(), and dsa device
> drivers should adapt to it.
>
> - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in
> port_txtstamp, so that most skbs not requiring tx timestamp just return.
>
> -
On 2021/4/19 9:53, Huang, Ying wrote:
> Miaohe Lin writes:
>
>> While we released the pte lock, somebody else might faulted in this pte.
>> So we should check whether it's swap pte first to guard against such race
>> or swp_type would be unexpected. But the swap_entry isn't used in this
>> functi
On 2021/4/19 10:15, Huang, Ying wrote:
> Miaohe Lin writes:
>
>> When I was investigating the swap code, I found the below possible race
>> window:
>>
>> CPU 1 CPU 2
>> - -
>> shmem_swapin
>> swap_cluste
On Fri, Apr 16, 2021 at 05:13:44PM +0800, Kai-Heng Feng wrote:
> On AMD platforms that use s2idle, NVMe timeouts on s2idle resume,
> because their SMU FW may cut off NVMe power during sleep.
We're already have a discussion on a proper quirk for thse broken
platforms on the linux-nvme list, please
Hi Bingbu,
On 4/19/21 12:57 PM, Bingbu Cao wrote:
Intel IPU(Image Processing Unit) has its own (IO)MMU hardware,
The IPU driver allocates its own page table that is not mapped
via the DMA, and thus the Intel IOMMU driver blocks access giving
this error:
DMAR: DRHD: handling fault status reg 3
D
On 2021/4/19 10:23, Huang, Ying wrote:
> Miaohe Lin writes:
>
>> When I was investigating the swap code, I found the below possible race
>> window:
>>
>> CPU 1CPU 2
>> --
>> do_swap_page
>
> This is OK for sw
On 18/04/2021 23.26, Christophe JAILLET wrote:
> Improve 'create_workqueue', 'create_freezable_workqueue' and
> 'create_singlethread_workqueue' so that they accept a format
> specifier and a variable number of arguments.
>
> This will put these macros more in line with 'alloc_ordered_workqueue' an
On 2021/4/19 10:54, Huang, Ying wrote:
> Miaohe Lin writes:
>
>> Use percpu_ref to serialize against concurrent swapoff. Also remove the
>> SWP_VALID flag because it's used together with RCU solution.
>>
>> Signed-off-by: Miaohe Lin
>> ---
>> include/linux/swap.h | 3 +--
>> mm/swapfile.c
On Mon, Apr 19, 2021 at 2:50 PM Christoph Hellwig wrote:
>
> On Fri, Apr 16, 2021 at 05:13:44PM +0800, Kai-Heng Feng wrote:
> > On AMD platforms that use s2idle, NVMe timeouts on s2idle resume,
> > because their SMU FW may cut off NVMe power during sleep.
>
> We're already have a discussion on a p
301 - 382 of 382 matches
Mail list logo
