airo_get_wireless_stats() is the iw_handler_if::get_wireless_stats()
callback of this driver. This callback was not allowed to sleep until
commit a160ee69c6a46 ("wext: let get_wireless_stats() sleep") in v2.6.32.
airo still delegates the readout to a thread, which is not longer
necessary.
Invoke
hostap_get_wireless_stats() is the iw_handler_if::get_wireless_stats()
callback of this driver. This callback was not allowed to sleep until
commit a160ee69c6a46 ("wext: let get_wireless_stats() sleep") in v2.6.32.
Remove the therefore pointless in_atomic() check.
Signed-off-by: Sebastian Andrzej
halbtc_send_bt_mp_operation() uses in_interrupt() to determine if it is
safe to invoke wait_for_completion().
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveye
The driver uses in_irq() + in_serving_softirq() magic to decide if NAPI
scheduling is required or packet processing.
The usage of in_*() in drivers is phased out and Linus clearly requested
that code which changes behaviour depending on context should either be
seperated or the context be conveyed
The usage of in_atomic() in driver code is deprecated as it can not
always detect all states where it is not allowed to sleep.
All callers are in premptible thread context and all functions invoke core
functions which have checks for invalid calling contexts already.
Signed-off-by: Sebastian Andr
issuecommand() is using in_atomic() to decide if it is safe to invoke
schedule() while waiting for the command to be accepted.
Usage of in_atomic() for this is only half correct as it can not detect all
condition where it is not allowed to schedule(). Also Linus clearly
requested that code which c
The driver uses in_irq() + in_serving_softirq() magic to decide if NAPI
scheduling is required or packet processing.
The usage of in_*() in drivers is phased out and Linus clearly requested
that code which changes behaviour depending on context should either be
seperated or the context be conveyed
dpaa_eth_napi_schedule() and caam_qi_napi_schedule() schedule NAPI if
invoked from:
- Hard interrupt context
- Any context which is not serving soft interrupts
Any context which is not serving soft interrupts includes hard interrupts
so the in_irq() check is redundant. caam_qi_napi_schedule() h
mlx5_eq_async_int() uses in_irq() to decide whether eq::lock needs to be
acquired and released with spin_[un]lock() or the irq saving/restoring
variants.
The usage of in_*() in drivers is phased out and Linus clearly requested
that code which changes behaviour depending on context should either be
is_any_client_connect_to_ap() is using in_interrupt() to determine whether
it should acquire the lock prior accessing the list.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the
issuecommand() is using in_atomic() to decide if it is safe to invoke
schedule() while waiting for the command to be accepted.
Usage of in_atomic() for this is only half correct as it can not detect all
condition where it is not allowed to schedule(). Also Linus clearly
requested that code which c
The driver uses in_irq() to determine if the tlan_priv::lock has to be
acquired in tlan_mii_read_reg() and tlan_mii_write_reg().
The interrupt handler acquires the lock outside of these functions so the
in_irq() check is meant to prevent a lock recursion deadlock. But this
check is incorrect when
The usage of in_irq()/in_interrupt() in drivers is phased out and the
BUG_ON()'s based on those are not covering all contexts in which these
functions cannot be called.
Aside of that BUG_ON() should only be used as last resort, which is clearly
not the case here.
A broad variety of checks in the
Folks,
in the discussion about preempt count consistency across kernel configurations:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
Linus clearly requested that code in drivers and libraries which changes
behaviour based on execution context should either be split up so th
wait_for_cmd_complete() uses in_interrupt() to detect whether it is safe to
sleep or not.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be seperated or the context be conveyed in an argument pas
nv_update_stats() triggers a WARN_ON() when invoked from hard interrupt
context because the locks in use are not hard interrupt safe. It also has
an assert_spin_locked() which was the lock check before the lockdep era.
Lockdep has way broader locking correctness checks and covers both issues,
so r
On 10/27/20 12:46 AM, Nico Pache wrote:
> On Wed, Jul 08, 2020 at 03:51:40PM -0400, Daniel Jordan wrote:
> > (I was away for a while)
> >
> > On Thu, Jul 02, 2020 at 11:55:48AM -0400, Nico Pache wrote:
> > > Allow padata_do_multithreaded function to be called after bootstrap.
> >
> > The function
From: Tom Rix
A semicolon is not needed after a switch statement.
Signed-off-by: Tom Rix
---
drivers/crypto/qat/qat_common/qat_algs.c | 2 +-
drivers/crypto/qat/qat_common/qat_asym_algs.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/qat/qat_c
From: Tom Rix
A semicolon is not needed after a switch statement.
Signed-off-by: Tom Rix
---
drivers/crypto/cavium/nitrox/nitrox_mbx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/cavium/nitrox/nitrox_mbx.c
b/drivers/crypto/cavium/nitrox/nitrox_mbx.c
inde
Hi Rob,
Thanks for reviewing the patch.
On Mon, 2020-10-26 at 08:17 -0500, Rob Herring wrote:
> On Fri, Oct 16, 2020 at 06:27:57PM +0100, Daniele Alessandrelli
> wrote:
> > From: Declan Murphy
> >
> > Add device-tree bindings for the Intel Keem Bay Offload Crypto
> > Subsystem
> > (OCS) Hashing
This rfc will describe
An upcoming treewide cleanup.
How clang tooling was used to programatically do the clean up.
Solicit opinions on how to generally use clang tooling.
The clang warning -Wextra-semi-stmt produces about 10k warnings.
Reviewing these, a subset of semicolon after a switch looks s
The UML random driver creates a dummy device under the guest,
/dev/hw_random. When this file is read from the guest, the driver
reads from the host machine's /dev/random, in-turn reading from
the host kernel's entropy pool. This entropy pool could have been
filled by a hardware random number genera
pm_runtime_get_sync() will increment pm usage counter even
when it returns an error code. We should call put operation
in error handling paths of omap_aes_hw_init.
Signed-off-by: Zhang Qilong
---
drivers/crypto/omap-aes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/omap-a
On 27/10/2020 07:59, Gilad Ben-Yossef wrote:
> On Mon, Oct 26, 2020 at 9:04 PM Milan Broz wrote:
...
>> We had all of disk-IV inside dmcrypt before - but once it is partially moved
>> into crypto API
>> (ESSIV, EBOIV for now), it becomes much more complicated for user to select
>> what he needs.
The README file was converted to ReST format. Update the
references for it accordingly.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c | 2 +-
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c | 2 +-
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c |
On Mon, Oct 26, 2020 at 9:04 PM Milan Broz wrote:
>
>
>
> On 26/10/2020 19:39, Eric Biggers wrote:
> > On Mon, Oct 26, 2020 at 07:29:57PM +0100, Milan Broz wrote:
> >> On 26/10/2020 18:52, Eric Biggers wrote:
> >>> On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
> Replace th
26 matches
Mail list logo
