Convert fs/locks.c to access fl_core fields direcly rather than using
the backward-compatibility macros. Most of this was done with
coccinelle, with a few by-hand fixups.
Signed-off-by: Jeff Layton
---
fs/locks.c | 467
include/trace/
Convert fs/locks.c to access fl_core fields direcly rather than using
the backward-compatability macros. Most of this was done with
coccinelle, with a few by-hand fixups.
Signed-off-by: Jeff Layton
---
fs/locks.c | 479
include/trace/
Some are used inside debug prints. These get marked as __maybe_unused.
Others are used within #ifery. These are defined inside the same #ifery.
Lastly, ones that are truly unused are removed entirely.
Fixes the following W=1 kernel build warning(s):
drivers/staging/rtl8723bs/core/rtw_mlme_ex
From: Coiby Xu
devlink_health_reporter_create may fail. In that case, do the cleanup
work.
Reported-by: Dan Carpenter
Signed-off-by: Coiby Xu
---
drivers/staging/qlge/qlge_devlink.c | 10 +++---
drivers/staging/qlge/qlge_devlink.h | 2 +-
drivers/staging/qlge/qlge_main.c| 8 +++-
From: Greg Kroah-Hartman
From: Vladimir Oltean
[ Upstream commit 86c4ad9a7876777c12fd5a7010152e4141fcb94d ]
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Cc: Per Forlin
Cc: Oleksij Re
From: Greg Kroah-Hartman
From: Vladimir Oltean
[ Upstream commit 9b9826ae117f211bcbdc75db844d5fd8b159fc59 ]
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
This one is interesting, the D
From: Greg Kroah-Hartman
From: Vladimir Oltean
[ Upstream commit 952a06345015867e3bd37f8d9045fc1429637d43 ]
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Similar to the EtherType DSA t
From: Greg Kroah-Hartman
From: Vladimir Oltean
[ Upstream commit 2f0d030c5ffec6660f79a32b4f522155f75a9d71 ]
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Cc: Florian Fainelli
Signed-o
From: Greg Kroah-Hartman
From: Vladimir Oltean
[ Upstream commit c6c4e1237dfe731644e79fa06d073625f28cd945 ]
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Note that the VLAN code path n
From: Greg Kroah-Hartman
From: Vladimir Oltean
[ Upstream commit 941f66beb7bb4e0e4726aa31336d9ccc1c3a3dc2 ]
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Cc: DENG Qingfang
Cc: Sean Wa
From: Greg Kroah-Hartman
From: Vladimir Oltean
[ Upstream commit 6ed94135f58372cdec34cafb60f7596893b0b371 ]
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Signed-off-by: Vladimir Oltean
From: Greg Kroah-Hartman
From: Vladimir Oltean
[ Upstream commit 9c5c3bd00557e57c1049f7861f11e5e39f0fb42d ]
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Signed-off-by: Vladimir Oltean
From: Greg Kroah-Hartman
From: Vladimir Oltean
[ Upstream commit 9bbda29ae1044bc4c1c01a5b7c44688c4765785f ]
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Cc: John Crispin
Cc: Alexande
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
This patch introduces the capability to detach a remote processor
that has been attached to by the remoteproc core. For that to happen
a rproc::ops::detach() operation needs to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_cdev.c
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the case with the running state, the command can't be
carried out if the remote processor is already in operation.
Signed-off-by: Mathieu Poirier
Reviewed-by
Allow a remote processor that was started by another entity to be
switched off by the remoteproc core. For that to happen a
rproc::ops::stop() operation needs to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_cdev.c | 3 ++-
driver
);
+
+ /*
+* The clean resource table is no longer needed. Allocated in
+* rproc_set_rsc_table().
+*/
+ kfree(rproc->clean_table);
+
+ return 0;
+}
+
/*
* Attach to remote processor - similar to rproc_fw_boot() but without
* the steps that deal with
r of the
+* shutdown process.
+*/
+ rproc->table_ptr = rproc->cached_table;
+ return 0;
+}
+
/*
* Attach to remote processor - similar to rproc_fw_boot() but without
* the steps that deal with the firmware image.
@@ -1759,7 +1800,12 @@ static int rproc_stop(struct rproc *rproc, b
the clean table
> > +* won't be needed. Allocated in rproc_set_rsc_table().
> > +*/
> > + kfree(rproc->clean_table);
> > +
> > +out:
> > + /*
> > +* Use a copy of the resource table for the remainder of the
> > +* shutdo
_sz, GFP_KERNEL);
>> +if (!rproc->cached_table)
>> +return -ENOMEM;
>> +
>> +/*
>> + * Since the remote processor is being switched off the clean table
>> + * won't be needed. Allocated in rproc_set_rsc_table().
>> +
is clean and ready to be used again.
> + */
> + memcpy(table_ptr, rproc->clean_table, rproc->table_sz);
> +
> + /*
> + * The clean resource table is no longer needed. Allocated in
> + * rproc_set_rsc_table().
> + */
> + kfree(rproc-
* Since the remote processor is being switched off the clean table
> + * won't be needed. Allocated in rproc_set_rsc_table().
> + */
> + kfree(rproc->clean_table);
> +
> +out:
> + /*
> + * Use a copy of the resource table for the remainder of
Hi Mathieu,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.12-rc2 next-20210310]
[cannot apply to remoteproc/for-next rpmsg/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
This patch introduces the capability to detach a remote processor
that has been attached to by the remoteproc core. For that to happen
a rproc::ops::detach() operation needs to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_cdev.c
Allow a remote processor that was started by another entity to be
switched off by the remoteproc core. For that to happen a
rproc::ops::stop() operation needs to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_cdev.c | 3 ++-
driver
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
+ /*
+* Use a copy of the resource table for the remainder of the
+* shutdown process.
+*/
+ rproc->table_ptr = rproc->cached_table;
+ return 0;
+}
+
/*
* Attach to remote processor - similar to rproc_fw_boot() but without
* the steps that deal
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the case with the running state, the command can't be
carried out if the remote processor is already in operation.
Signed-off-by: Mathieu Poirier
Reviewed-by
clean resource table is no longer needed. Allocated in
+* rproc_set_rsc_table().
+*/
+ kfree(rproc->clean_table);
+
+ return 0;
+}
+
/*
* Attach to remote processor - similar to rproc_fw_boot() but without
* the steps that deal with the firmware image.
@@ -1721,6 +1792,9
(!rproc->cached_table)
> > + return -ENOMEM;
> > +
> > + /*
> > +* Use a copy of the resource table for the remainder of the
> > +* shutdown process.
> > +*/
> > + rproc->table_ptr = rproc->cached_table;
> > +
> > + /*
> > +* Res
On 2/24/21 12:35 AM, Mathieu Poirier wrote:
> This patch introduces the capability to detach a remote processor
> that has been attached by the remoteproc core. For that to happen
> a rproc::ops::detach() operation needs to be available.
>
> Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud
On 2/24/21 12:35 AM, Mathieu Poirier wrote:
> Allow a remote processor that was started by another entity to be
> switched off by the remoteproc core. For that to happen a
> rproc::ops::stop() operation needs to be available.
>
> Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
et the memory area where the firmware loaded the resource table
> + * to its original value. That way when we re-attach the remote
> + * processor the resource table is clean and ready to be used again.
> + */
> + memcpy(table_ptr, rproc->clean_table, rproc->table_sz);
> +
> + /*
>
set_loaded_rsc_table().
+*/
+ kfree(rproc->clean_table);
+
+ return 0;
+}
+
/*
* Attach to remote processor - similar to rproc_fw_boot() but without
* the steps that deal with the firmware image.
@@ -1688,7 +1762,11 @@ static int rproc_stop(struct rproc *rproc, bool c
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the case with the running state, the command can't be
carried out if the remote processor is already in operation.
Signed-off-by: Mathieu Poirier
Reviewed-by
Allow a remote processor that was started by another entity to be
switched off by the remoteproc core. For that to happen a
rproc::ops::stop() operation needs to be available.
Signed-off-by: Mathieu Poirier
---
New for V6:
- Removed state check in rproc_shutdown() as it is already done in
in c
This patch introduces the capability to detach a remote processor
that has been attached by the remoteproc core. For that to happen
a rproc::ops::detach() operation needs to be available.
Signed-off-by: Mathieu Poirier
---
New for V6:
- The RPROC_RUNNING -> RPROC_DETACHED transition is no longer
t; + * table for the rest of the detach process since ->table_ptr will
> + * become invalid as soon as carveouts are released in
> + * rproc_resource_cleanup().
> + *
> + * If the remote processor was started by an external entity the
> + * cached_tab
Hi Mathieu,
url:
https://github.com/0day-ci/linux/commits/Mathieu-Poirier/remoteproc-Add-support-for-detaching-a-remote-processor/20210212-075607
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: ia64-randconfig-m031-20210209 (attached as .config)
compiler
There are identical kfrees on lines 2078 and 2080.
julia
-- Forwarded message --
Date: Fri, 12 Feb 2021 10:45:50 +0800
From: kernel test robot
To: kbu...@lists.01.org
Cc: l...@intel.com, Julia Lawall
Subject: Re: [PATCH v5 13/19] remoteproc: Properly deal with the resource
Committer: Paul E. McKenney
CommitterDate: Wed, 06 Jan 2021 17:03:42 -08:00
torture: Make torture.sh rcuscale and refscale deal with allmodconfig
The .mod.c files created by allmodconfig builds interfers with the approach
torture.sh uses to enumerate types of rcuscale and refscale runs. This
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
driver
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the "running" case, the command can't be carried out if the
remote processor is already in operation.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Poul
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/r
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
->table_ptr will
+* become invalid as soon as carveouts are released in
+* rproc_resource_cleanup().
+*
+* If the remote processor was started by an external entity the
+* cached_table is NULL and the rest of the cleanup code in
+* rproc_free_vring()
Now that the core bitmap parse code respects the "all" parameter, there
is no need for RCU to have its own special check for it.
Cc: Yury Norov
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
Signed-off-by: Paul Gortmaker
---
Documentation/admin-guide/kernel-parameters.txt | 4 +---
kernel/rcu/tre
Silence is consent.
Are there FOSS developers making decent money via Patreon, GoFundMe,
whatever?
Yes, Grsecurity is making good money.
They simply added a no-redistribution agreement to their patch of the
Linux Kernel.
(
https://perens.com/2017/06/28/warning-grsecurity-potential-contribut
From: "Paul E. McKenney"
The .mod.c files created by allmodconfig builds interfers with the approach
torture.sh uses to enumerate types of rcuscale and refscale runs. This
commit therefore tightens the pattern matching to avoid this interference.
Signed-off-by: Paul E. McKenney
---
tools/test
Silence is consent.
Are there FOSS developers making decent money via Patreon, GoFundMe,
whatever?
Yes, Grsecurity is making good money.
They simply added a no-redistribution agreement to their patch of the
Linux Kernel.
(
https://perens.com/2017/06/28/warning-grsecurity-potential-contribut
reference leak. It has been discussed a lot[0][1]. So we add a function
to deal with the usage counter for better coding.
[0]https://lkml.org/lkml/2020/6/14/88
[1]https://patchwork.ozlabs.org/project/linux-tegra/list/?series=178139
Signed-off-by: Zhang Qilong
Acked-by: Rafael J. Wysocki
Signed
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
driver
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/r
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the "running" case, the command can't be carried out if the
remote processor is already in operation.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Poul
On 11/26/20 10:06 PM, Mathieu Poirier wrote:
> This patch introduces the capability to detach a remote processor
> that has been attached to or booted by the remoteproc core. For
> that to happen a rproc::ops::detach() operation need to be
> available.
>
> Signed-off-by: Mathieu Poirier
> Rev
On 11/26/20 10:06 PM, Mathieu Poirier wrote:
> This patch takes into account scenarios where a remote processor
> has been attached to when receiving a "start" command from sysfs.
>
> As with the "running" case, the command can't be carried out if the
> remote processor is already in operation.
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
---
drivers/remoteproc/remoteproc_cdev.c
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the "running" case, the command can't be carried out if the
remote processor is already in operation.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/r
reference leak. It has been discussed a lot[0][1]. So we add a function
to deal with the usage counter for better coding.
[0]https://lkml.org/lkml/2020/6/14/88
[1]https://patchwork.ozlabs.org/project/linux-tegra/list/?series=178139
Signed-off-by: Zhang Qilong
Acked-by: Rafael J. Wysocki
Signed
0>] vfs_statx+0x89/0xe0
[<0>] __do_sys_newstat+0x39/0x70
[<0>] do_syscall_64+0x55/0x1c0
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
We have no idea to deal with the bug. Here, we have some
question about that:
1. Why not use timeout mechanism?
2. If timeout mechanism i
Good Day,
I am Mr. Eric Axford a director with Financial Conduct Authority (FCA) UK. I'm
soliciting your assistance for transfer of $65.9M into your bank account.
Please respond back for more details about this transaction.
Yours Truly,
Mr. Eric Axford
So far most of the drivers with the MBUS quirks had to duplicate the
code to deal with DT compatibility and enforcing the DMA offsets.
Let's move for a more maintainable solution by putting everything in a
notifier that would take care of setting up the DMA offsets for all the
MBUS de
From: Ard Biesheuvel
commit d32de9130f6c79533508e2c7879f18997bfbe2a0 upstream.
Currently, on arm64, we abort on any failure from efi_get_random_bytes()
other than EFI_NOT_FOUND when it comes to setting the physical seed for
KASLR, but ignore such failures when obtaining the seed for virtual
KASL
From: Ard Biesheuvel
commit d32de9130f6c79533508e2c7879f18997bfbe2a0 upstream.
Currently, on arm64, we abort on any failure from efi_get_random_bytes()
other than EFI_NOT_FOUND when it comes to setting the physical seed for
KASLR, but ignore such failures when obtaining the seed for virtual
KASL
> Subject: [PATCH 11/13] remoteproc: Properly deal with detach request
>
> This patch introduces the capability to detach a remote processor that has
> been attached to or booted by the remoteproc core. For that to happen a
> rproc::ops::detach() operation need to be available.
> Subject: [PATCH 10/13] remoteproc: Properly deal with a stop request when
> attached
>
> This patch introduces the capability to stop a remote processor that has been
> attached to by the remoteproc core. For that to happen a rproc::ops::stop()
> operation need to be availabl
> Subject: [PATCH 13/13] remoteproc: Properly deal with a kernel panic when
> attached
>
> The panic handler operation of registered remote processors should also be
> called when remote processors have been attached to.
>
> Signed-off-by: Mathieu Poirier
> -
Committer: Ard Biesheuvel
CommitterDate: Tue, 29 Sep 2020 15:41:52 +02:00
efi/arm64: libstub: Deal gracefully with EFI_RNG_PROTOCOL failure
Currently, on arm64, we abort on any failure from efi_get_random_bytes()
other than EFI_NOT_FOUND when it comes to setting the physical seed for
KASLR, but
On Fri, Sep 25, 2020 at 06:51:37AM +0200, Christoph Hellwig wrote:
> Hi Al,
>
> this series changes import_iovec to transparently deal with compat iovec
> structures, and then cleanups up a lot of code dupliation.
OK, I can live with that. Applied, let's see if it passes smoke
Hi Al,
this series changes import_iovec to transparently deal with compat iovec
structures, and then cleanups up a lot of code dupliation.
Changes since v3:
- fix up changed prototypes in compat.h as well
Changes since v2:
- revert the switch of the access process vm sysclls to iov_iter
Hi Al,
this series changes import_iovec to transparently deal with comat iovec
structures, and then cleanups up a lot of code dupliation.
Changes since v2:
- revert the switch of the access process vm sysclls to iov_iter
- refactor the import_iovec internals differently
- switch aio to use
Hi Al,
this series changes import_iovec to transparently deal with comat iovec
structures, and then cleanups up a lot of code dupliation.
Changes since v1:
- improve a commit message
- drop a pointless unlikely
- drop the PF_FORCE_COMPAT flag
- add a few more cleanups (including two from
> On Sat, Sep 19, 2020 at 02:24:10PM +, David Laight wrote:
> > I thought about that change while writing my import_iovec() =>
> > iovec_import()
> > patch - and thought that the io_uring code would (as usual) cause grief.
> >
> > Christoph - did you see those patches?
Link to cover email.
h
On Sat, Sep 19, 2020 at 02:24:10PM +, David Laight wrote:
> I thought about that change while writing my import_iovec() => iovec_import()
> patch - and thought that the io_uring code would (as usual) cause grief.
>
> Christoph - did you see those patches?
No.
From: Christoph Hellwig
> Sent: 18 September 2020 13:45
>
> this series changes import_iovec to transparently deal with comat iovec
> structures, and then cleanups up a lot of code dupliation. But to get
> there it first has to fix the pre-existing bug that io_uring compat
&
Hi Al,
this series changes import_iovec to transparently deal with comat iovec
structures, and then cleanups up a lot of code dupliation. But to get
there it first has to fix the pre-existing bug that io_uring compat
contexts don't trigger the in_compat_syscall() check. This has so far
Some of the HDMI pixelvalves in vc5 output two pixels per clock cycle.
Let's put the number of pixel output per clock cycle in the CRTC data and
update the various calculations to reflect that.
Reviewed-by: Eric Anholt
Tested-by: Chanwoo Choi
Tested-by: Hoegeun Kwon
Tested-by: Stefan Wahren
Si
The HDMI driver was registering a single debugfs file so far with the name
hdmi_regs.
Obviously, this is not going to work anymore when will have multiple HDMI
controllers since we will end up trying to register two files with the same
name.
Let's use the variant to avoid that name conflict.
Rev
The HDMI driver was registering a single ALSA card so far with the name
vc4-hdmi.
Obviously, this is not going to work anymore when we will have multiple
HDMI controllers since we will end up trying to register two files with the
same name.
Let's use the variant to avoid that name conflict.
Revi
From: Thomas Gleixner
commit 784a0830377d0761834e385975bc46861fea9fa0 upstream.
Most of the CPU mask operations behave the same way, but for_each_cpu() and
it's variants ignore the cpumask argument and claim that CPU0 is always in
the mask. This is historical, inconsistent and annoying behaviour
From: Thomas Gleixner
commit 784a0830377d0761834e385975bc46861fea9fa0 upstream.
Most of the CPU mask operations behave the same way, but for_each_cpu() and
it's variants ignore the cpumask argument and claim that CPU0 is always in
the mask. This is historical, inconsistent and annoying behaviour
From: Thomas Gleixner
commit 784a0830377d0761834e385975bc46861fea9fa0 upstream.
Most of the CPU mask operations behave the same way, but for_each_cpu() and
it's variants ignore the cpumask argument and claim that CPU0 is always in
the mask. This is historical, inconsistent and annoying behaviour
Committer: Thomas Gleixner
CommitterDate: Sun, 30 Aug 2020 19:17:28 +02:00
genirq/matrix: Deal with the sillyness of for_each_cpu() on UP
Most of the CPU mask operations behave the same way, but for_each_cpu() and
it's variants ignore the cpumask argument and claim that CPU0 is always in
the
;> irq_exit+0x16c/0x178
>> ---[ end trace 56a3ea4fa00c37c8 ]---
>> ...
>> axg-sound-card sound: ASoC: no DMI vendor name!
>>
>> The warning is repeated 10 times.
> That's the probe defferal mechanism causing the repeat
>
>> The bisect between v5.8
ound: ASoC: no DMI vendor name!
>
> The warning is repeated 10 times.
That's the probe defferal mechanism causing the repeat
>
> The bisect between v5.8-rc1 and v5.9-rc1 points to the commit
> c8f7dbdbaa15 ("Merge remote-tracking branch 'asoc/for-5.8' into
>
27; into
asoc-linus"), which introduced a branch with this patch.
The commit with this patch is applied on the earlier kernel release
(da3f23fde9d7 "ASoC: meson: cards: deal dpcm flag change" on top of
v5.7-rc1) worked fine, so it looks that there is an interference with
something m
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_cdev.c | 5 +++--
drivers/remoteproc/remote
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remo
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_cdev.c | 6 ++
drivers/re
'vif' is a function parameter which is oddly overwritten within the
function, but never read back. 'timeout' is set, but never checked.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c: In function
‘brcmf_p2p_scan_prep’:
drivers/net/wirel
From: Jerome Brunet
[ Upstream commit da3f23fde9d7b4a7e0ca9a9a096cec3104df1b82 ]
Commit b73287f0b074 ("ASoC: soc-pcm: dpcm: fix playback/capture checks")
changed the meaning of dpcm_playback/dpcm_capture and now requires the
CPU DAI BE to aligned with those flags.
This broke all Amlogic cards w
On Thu, Aug 13, 2020 at 07:49:24AM +0100, Chris Wilson wrote:
> Quoting Jordan Crouse (2020-08-13 00:55:44)
> > This is an RFC because I'm still trying to grok the correct behavior.
> >
> > Consider a dma_fence_array created two two fence and signal_on_any is true.
> > A reference to dma_fence_arr
Several functions aren't used outside the mfd driver. So,
either remove or make them static.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 147
1 file changed, 24 insertions(+), 123 deletions(-)
diff --git a/drivers/staging/hikey9xx/
Am 13.08.20 um 01:55 schrieb Jordan Crouse:
This is an RFC because I'm still trying to grok the correct behavior.
Consider a dma_fence_array created two two fence and signal_on_any is true.
A reference to dma_fence_array is taken for each waiting fence.
Ok, that sounds like you seem to mix a c
This is an RFC because I'm still trying to grok the correct behavior.
Consider a dma_fence_array created two two fence and signal_on_any is true.
A reference to dma_fence_array is taken for each waiting fence.
When the client calls dma_fence_wait() only one of the fences is signaled.
The client r
1 - 100 of 1001 matches
Mail list logo
