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
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 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: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
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 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
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 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 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.
>
> -
> -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 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 +++
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:
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
> -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...
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
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/
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(
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 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
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
> 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
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
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
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 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 '-
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
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.
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 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,
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:
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/
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
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
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
> > @@ -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 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
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
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
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
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
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
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
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/
I need your assistance, Reply for more details. davidbrown1...@juno.com or
Call: + 1 918 397 9602
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 "
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 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) {
>
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
I need your assistance, Reply for more details. davidbrown1...@juno.com or
Call: + 1 918 397 9602
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
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
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
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_
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
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
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 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
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
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
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 +-
>
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 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
>
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
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
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
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
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
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
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-
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
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
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
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
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
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 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:58:03 +0800, Yu Kuai wrote:
> The sparse tool complains as follows:
>
> drivers/macintosh/via-pmu.c:183:5: warning:
> symbol 'pmu_cur_battery' was not declared. Should it be static?
> drivers/macintosh/via-pmu.c:190:5: warning:
> symbol '__fake_sleep' was not declared. Shou
On Thu, 11 Feb 2021 12:24:35 -0600, Tyrel Datwyler wrote:
> The pci_bus->bridge reference may no longer be valid after
> pci_bus_remove() resulting in passing a bad value to device_unregister()
> for the associated bridge device.
>
> Store the host_bridge reference in a separate variable prior to
On Thu, 8 Apr 2021 14:20:12 +0800, Pu Lehui wrote:
> Fix sparse warnings:
>
> arch/powerpc/platforms/pseries/rtas-fadump.c:250:6: warning:
> symbol 'rtas_fadump_set_regval' was not declared. Should it be static?
Applied to powerpc/next.
[1/1] powerpc/fadump: make symbol 'rtas_fadump_set_regval'
On Fri, 9 Apr 2021 15:01:51 +0800, Pu Lehui wrote:
> Fix sparse warning:
>
> arch/powerpc/xmon/xmon.c:4216:1: warning:
> symbol 'spu_inst_dump' was not declared. Should it be static?
>
> This symbol is not used outside of xmon.c, so make it static.
Applied to powerpc/next.
[1/1] powerpc/xmon:
On Wed, 14 Apr 2021 19:00:33 +0800, Xiongwei Song wrote:
> Define macros to list ppc interrupt types in interttupt.h, replace the
> reference of the trap hex values with these macros.
>
> Referred the hex numbers in arch/powerpc/kernel/exceptions-64e.S,
> arch/powerpc/kernel/exceptions-64s.S, arch
On Thu, 8 Apr 2021 11:58:02 +0800, Li Huafei wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/kernel/mce.c:43:1: warning:
> symbol 'mce_ue_event_work' was not declared. Should it be static?
>
> This symbol is not used outside of mce.c, so this commit marks it
> static.
Applied to
On Thu, 8 Apr 2021 17:19:16 -0300, Leonardo Bras wrote:
> According to LoPAR, ibm,query-pe-dma-window output named "IO Page Sizes"
> will let the OS know all possible pagesizes that can be used for creating a
> new DDW.
>
> Currently Linux will only try using 3 of the 8 available options:
> 4K, 64
On Fri, 9 Apr 2021 17:01:24 +0800, Bixuan Cui wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/perf/hv-24x7.c:229:1: warning:
> symbol '__pcpu_scope_hv_24x7_txn_flags' was not declared. Should it be
> static?
> arch/powerpc/perf/hv-24x7.c:230:1: warning:
> symbol '__pcpu_scope_hv
On Thu, 8 Apr 2021 11:39:51 +0800, Li Huafei wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/kernel/security.c:253:6: warning:
> symbol 'stf_barrier' was not declared. Should it be static?
>
> This symbol is not used outside of security.c, so this commit marks it
> static.
Appli
On Tue, 2 Mar 2021 00:30:18 +0900, Masahiro Yamada wrote:
> Many architectures duplicate similar shell scripts.
>
> This commit converts powerpc to use scripts/syscalltbl.sh. This also
> unifies syscall_table_32.h and syscall_table_c32.h.
Applied to powerpc/next.
[1/2] powerpc: syscalls: switch
On Fri, 26 Mar 2021 19:17:20 +, Dmitry Safonov wrote:
> Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front")
> VVAR page is in front of the VDSO area. In result it breaks CRIU
> (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]"
> from /proc/../maps point
On Fri, 9 Apr 2021 17:01:14 +0800, Bixuan Cui wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/platforms/pseries/pmem.c:142:27: warning:
> symbol 'drc_pmem_match' was not declared. Should it be static?
>
> This symbol is not used outside of pmem.c, so this
> commit marks it static
On Fri, 9 Apr 2021 17:01:09 +0800, Bixuan Cui wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/platforms/pseries/hvCall_inst.c:29:1: warning:
> symbol '__pcpu_scope_hcall_stats' was not declared. Should it be static?
>
> This symbol is not used outside of hvCall_inst.c, so this
>
On Fri, 9 Apr 2021 14:38:55 +0800, Bixuan Cui wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/platforms/powernv/opal-core.c:74:16: warning:
> symbol 'mpipl_kobj' was not declared.
>
> This symbol is not used outside of opal-core.c, so marks it static.
Applied to powerpc/next.
[
On Fri, 9 Apr 2021 17:01:19 +0800, Bixuan Cui wrote:
> The sparse tool complains as follows:
>
> arch/powerpc/perf/isa207-common.c:24:18: warning:
> symbol 'isa207_pmu_format_attr' was not declared. Should it be static?
>
> This symbol is not used outside of isa207-common.c, so this
> commit mar
On Wed, 31 Mar 2021 16:48:43 + (UTC), Christophe Leroy wrote:
> [Sorry, resending with complete destination list, I used the wrong script on
> the first delivery]
>
> This series adds support for time namespaces on powerpc.
>
> All timens selftests are successfull.
>
> Christophe Leroy (3):
On Thu, 8 Apr 2021 15:30:24 + (UTC), Christophe Leroy wrote:
> Cache flushing functions are in the middle of completely
> unrelated stuff in mm/mem.c
>
> Create a dedicated mm/cacheflush.c for those functions.
>
> Also cleanup the list of included headers.
Applied to powerpc/next.
[1/9] pow
The MAC device name can now be set within DTS file instead of always
being "ethX". This is helpful for DSA to clearly label the DSA master
device and distinguish it from DSA slave ports.
For example, some devices, such as the Ubiquiti EdgeRouter X, may have
ports labeled ethX. Labeling the master
1 - 100 of 382 matches
Mail list logo
