- 30 Sep, 2020 11 commits
-
-
Marc Kleine-Budde authored
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes all non user facing occurrence of "mcp25xxfd" to "mcp251xfd" and "MCP25XXFD" to "MCP251XFD". [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-10-mkl@pengutronix.deSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes all user facing strings from "mcp25xxfd" to "mcp251xfd" and "MCP25XXFD" to "MCP251XFD", including: - kconfig symbols - name of kernel module - DT and SPI compatible [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-9-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes the name of the driver subdir and the individual files accordinly. [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-8-mkl@pengutronix.deSigned-off-by:
-
Thomas Kopp authored
The wildcard should be narrowed down to prevent existing and future devices that are not compatible from matching. It is very unlikely that incompatible devices will be released that do not match the wildcard. Discussion Reference: https://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.comReported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Thomas Kopp <thomas.kopp@microchip.com> Link: https://lore.kernel.org/r/20200930091423.755-1-thomas.kopp@microchip.comSigned-off-by:
-
Thomas Kopp authored
The wildcard should be narrowed down to prevent existing and future devices that are not compatible from matching. It is very unlikely that incompatible devices will be released that do not match the wildcard. This is the documentation part of the commit. Discussion Reference: https://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.comReported-by:
-
Oleksij Rempel authored
Apply following fixes: - Use 'interrupts'. (interrupts-extended will automagically be supported by the tools) - *-supply is always a single item. So, drop maxItems=1 - add "additionalProperties: false" flag to detect unneeded properties. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200923125301.27200-1-o.rempel@pengutronix.deReported-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Marc Kleine-Budde authored
This patch fixes the following warning: drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c:2155 mcp25xxfd_irq() error: uninitialized symbol 'set_normal_mode'. by adding the missing initialization. Reported-by:Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Fixes: 55e5b97f ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Link: https://lore.kernel.org/r/20200923114726.2704426-1-mkl@pengutronix.deSigned-off-by:
-
Dan Carpenter authored
This loop doesn't free the first element of the array. The "i > 0" has to be changed to "i >= 0". Fixes: 55e5b97f ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Signed-off-by:
-
Thomas Kopp authored
This patch adds a reference to the recent released MCP2517FD and MCP2518FD errata sheets and paste the explanation. The driver already implements the proposed fix. Signed-off-by:
-
Thomas Kopp authored
This patch adds a reference to the recent released MCP2517FD and MCP2518FD errata sheets and paste the explanation. The single error correction does not always work, so always indicate that a single error occurred. If the location of the ECC error is outside of the TX-RAM always use netdev_notice() to log the problem. For ECC errors in the TX-RAM, there is a recovery procedure. Signed-off-by:
-
Lorenzo Bianconi authored
Do not use rx_desc pointers if possible since rx descriptors are stored in uncached memory and dereferencing rx_desc pointers generate extra loads. This patch improves XDP_DROP performance of ~ 110Kpps (700Kpps vs 590Kpps) on Marvell Espressobin Analyzed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 29 Sep, 2020 29 commits
-
-
Armin Wolf authored
Replace panic() call in lib8390.c with BUILD_BUG_ON() since checking the size of struct e8390_pkt_hdr should happen at compile-time. Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Signed-off-by:
-
David S. Miller authored
Thomas Gleixner says: ==================== net: in_interrupt() cleanup and fixes in the discussion about preempt count consistency accross kernel configurations: https://lore.kernel.org/r/20200914204209.256266093@linutronix.de/ Linus clearly requested that code in drivers and libraries which changes behaviour based on execution context should either be split up so that e.g. task context invocations and BH invocations have different interfaces or if that's not possible the context information has to be provided by the caller which knows in which context it is executing. This includes conditional locking, allocation mode (GFP_*) decisions and avoidance of code paths which might sleep. In the long run, usage of 'preemptible, in_*irq etc.' should be banned from driver code completely. This is the second version of the first batch of related changes. V1 can be found here: https://lore.kernel.org/r/20200927194846.045411263@linutronix.de Changes vs. V1: - Rebased to net-next - Fixed the half done rename sillyness in the ENIC patch. - Fixed the IONIC driver fallout. - Picked up the SFC fix from Edward and adjusted the GFP_KERNEL change accordingly. - Addressed the review comments vs. BCRFMAC. - Collected Reviewed/Acked-by tags as appropriate. ==================== Signed-off-by:
-
Sebastian Andrzej Siewior authored
rtl_lps_enter() and rtl_lps_leave() are using in_interrupt() to detect whether it is safe to acquire a mutex or if it is required to defer to a workqueue. 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 passed by the caller, which usually knows the context. in_interrupt() also is only partially correct because it fails to chose the correct code path when just preemption or interrupts are disabled. Add an argument 'may_block' to both functions and adjust the callers to pass the context information. The following call chains were analyzed to be safe to block: rtl_watchdog_wq_callback() rlf_lps_leave/enter() rtl_op_suspend() rtl_lps_leave() rtl_op_bss_info_changed() rtl_lps_leave() rtl_op_sw_scan_start() rtl_lps_leave() The following call chains were analyzed to be unsafe to block: _rtl_pci_interrupt() _rtl_pci_rx_interrupt() rtl_lps_leave() _rtl_pci_interrupt() _rtl_pci_rx_interrupt() rtl_is_special_data() rtl_lps_leave() _rtl_pci_interrupt() _rtl_pci_rx_interrupt() rtl_is_special_data() setup_special_tx() rtl_lps_leave() _rtl_pci_interrupt() _rtl_pci_tx_isr rtl_lps_leave() halbtc_leave_lps() rtl_lps_leave() This leaves four callers of rtl_lps_enter/leave() where the analyzis stopped dead in the maze of several nested pointer based callchains and lack of rtlwifi hardware to debug this via tracing: halbtc_leave_lps(), halbtc_enter_lps(), halbtc_normal_lps(), halbtc_pre_normal_lps() These four have been cautionally marked to be unable to block which is the safe option, but the rtwifi wizards should be able to clarify that. Signed-off-by:Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Sebastian Andrzej Siewior authored
The usage of in_interrupt() in drivers in is phased out. rtl_dbg() a printk based debug aid is using in_interrupt() in the underlying C function _rtl_dbg_out() which is almost identical to _rtl_dbg_print(). The only difference is the printout of in_interrupt(). The decoding of in_interrupt() as hexvalue is non-trivial and aside of being phased out for driver usage the return value is just by chance the masked preempt count value and not a boolean. These home brewn printk debug aids are tedious to work with and provide only minimal context. They should be replaced by trace_printk() or a debug tracepoint which automatically records all context information. To make progress on the in_interrupt() cleanup, make rtl_dbg() use _rtl_dbg_print() and remove _rtl_dbg_out(). Signed-off-by:
-
Sebastian Andrzej Siewior authored
INIT_DELAYED_WORK() takes two arguments: A pointer to the delayed work and a function reference for the callback. The rtl code casts all function references to (void *) because the callbacks in use are not matching the required function signature. That's error prone and bad pratice. Some of the callback functions are also global, but only used in a single file. Clean the mess up by: - Adding the proper arguments to the callback functions and using them in the container_of() constructs correctly which removes the hideous container_of_dwork_rtl() macro as well. - Removing the type cast at the initializers - Making the unnecessary global functions static Signed-off-by: -
Sebastian Andrzej Siewior authored
The usage of in_interrupt() in non-core code is phased out. Ideally the information of the calling context should be passed by the callers or the functions be split as appropriate. libertas uses in_interupt() to select the netif_rx*() variant which matches the calling context. The attempt to consolidate the code by passing an arguemnt or by distangling it failed due lack of knowledge about this driver and because the call chains are hard to follow. As a stop gap use netif_rx_any_context() which invokes the correct code path depending on context and confines the in_interrupt() usage to core code. Signed-off-by:
-
Sebastian Andrzej Siewior authored
The debug macro prints (INT) when in_interrupt() returns true. The value of this information is dubious as it does not distinguish between the various contexts which are covered by in_interrupt(). As the usage of in_interrupt() in drivers is phased out and the same information can be more precisely obtained with tracing, remove the in_interrupt() conditional from this debug printk. Signed-off-by:
-
Sebastian Andrzej Siewior authored
The usage of in_interrupt() in non-core code is phased out. Ideally the information of the calling context should be passed by the callers or the functions be split as appropriate. mwifiex uses in_interupt() to select the netif_rx*() variant which matches the calling context. The attempt to consolidate the code by passing an arguemnt or by distangling it failed due lack of knowledge about this driver and because the call chains are hard to follow. As a stop gap use netif_rx_any_context() which invokes the correct code path depending on context and confines the in_interrupt() usage to core code. Signed-off-by:
-
Sebastian Andrzej Siewior authored
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. hfa384x_cmd() and prism2_hw_reset() check in_interrupt() at function entry and if true emit a printk at debug loglevel and return. This is clearly debug code. Both functions invoke functions which can sleep. These functions already have appropriate debug checks which cover all invalid contexts, while in_interrupt() fails to detect context which just has preemption or interrupts disabled. Remove both checks as they are incomplete, debug only and already covered by the subsequently invoked functions properly. If called from invalid context the resulting back trace is definitely more helpful to analyze the problem than a printk at debug loglevel. Signed-off-by:
-
Sebastian Andrzej Siewior authored
The usage of in_interrupt) in driver code is phased out. The iwlwifi_dbg tracepoint records in_interrupt() seperately, but that's superfluous because the trace header already records all kind of state and context information like hardirq status, softirq status, preemption count etc. Aside of that the recording of in_interrupt() as boolean does not allow to distinguish between the possible contexts (hard interrupt, soft interrupt, bottom half disabled) while the trace header gives precise information. Remove the duplicate information from the tracepoint and fixup the caller. Signed-off-by:
Luca Coelho <luca@coelho.fi> Acked-by:
-
Sebastian Andrzej Siewior authored
The usage of in_interrupt() in non-core code is phased out. The debugging macros in these drivers use in_interrupt() to print 'I' or 'U' depending on the return value of in_interrupt(). While 'U' is confusing at best and 'I' is not really describing the actual context (hard interupt, soft interrupt, bottom half disabled section) these debug macros originate from the pre ftrace kernel era and their value today is questionable. They probably should be removed completely. The macros weere added initially for ipw2100 and then spreaded when the driver was forked. Remove the in_interrupt() usage at least.. Signed-off-by:
-
Sebastian Andrzej Siewior authored
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 passed by the caller, which usually knows the context. brcmf_fweh_process_event() uses in_interrupt() to select the allocation mode GFP_KERNEL/GFP_ATOMIC. Aside of the above reasons this check is incomplete as it cannot detect contexts which just have preemption or interrupts disabled. All callchains leading to brcmf_fweh_process_event() can clearly identify the calling context. Convey a 'gfp' argument through the callchains and let the callers hand in the appropriate GFP mode. This has also the advantage that any change of execution context or preemption/interrupt state in these callchains will be detected by the memory allocator for all GFP_KERNEL allocations. Signed-off-by:
-
Thomas Gleixner authored
bcrmgf_netif_rx() uses in_interrupt to chose between netif_rx() and netif_rx_ni(). in_interrupt() usage in drivers is phased out. Convey the execution mode via an 'inirq' argument through the various callchains leading to brcmf_netif_rx(): brcmf_pcie_isr_thread() <- Task context brcmf_proto_msgbuf_rx_trigger() brcmf_msgbuf_process_rx() brcmf_msgbuf_process_msgtype() brcmf_msgbuf_process_rx_complete() brcmf_netif_mon_rx() brcmf_netif_rx(isirq = false) brcmf_netif_rx(isirq = false) brcmf_sdio_readframes() <- Task context sdio_claim_host() might sleep brcmf_rx_frame(isirq = false) brcmf_sdio_rxglom() <- Task context sdio_claim_host() might sleep brcmf_rx_frame(isirq = false) brcmf_usb_rx_complete() <- Interrupt context brcmf_rx_frame(isirq = true) brcmf_rx_frame() brcmf_proto_rxreorder() brcmf_proto_bcdc_rxreorder() brcmf_fws_rxreorder() brcmf_netif_rx() brcmf_netif_rx() Signed-off-by: -
Sebastian Andrzej Siewior authored
brcmf_sdio_isr() is using in_interrupt() to distinguish if it is called from a interrupt service routine or from a worker thread. Passing such information from the calling context is preferred and requested by Linus, so add an argument `in_isr' to brcmf_sdio_isr() and let the callers pass the information about the calling context. Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Acked-by:
-
Sebastian Andrzej Siewior authored
lmc_trace() was first introduced in commit e7a392d5 ("Import 2.3.99pre6-5") and was not touched ever since. The reason for looking at this was to get rid of the in_interrupt() usage, but while looking at it the following observations were made: - At least lmc_get_stats() (->ndo_get_stats()) is invoked with disabled preemption which is not detected by the in_interrupt() check, which would cause schedule() to be called from invalid context. - The code is hidden behind #ifdef LMC_TRACE which is not defined within the kernel and wasn't at the time it was introduced. - Three jiffies don't match 50ms. msleep() would be a better match which would also avoid the schedule() invocation. But why have it to begin with? - Nobody would do something like this today. Either netdev_dbg() or trace_printk() or a trace event would be used. If only the functions related to this driver are interesting then ftrace can be used with filtering. As it is obviously broken for years, simply remove it. Signed-off-by:
-
Sebastian Andrzej Siewior authored
The comment above nc_vendor_write() suggests that the function could become async so that is usable in `in_interrupt()' context or that it already is safe to be called from such a context. Eitherway: The function did not become async since v2.4.9.2 (2002) and it must be not be called from `in_interrupt()' context because it sleeps on mutltiple occations. Remove the misleading comment. Signed-off-by:
-
Sebastian Andrzej Siewior authored
kaweth_async_set_rx_mode() invokes kaweth_contol() and has two callers: - kaweth_open() which is invoked from preemptible context . - kaweth_start_xmit() which holds a spinlock and has bottom halfs disabled. If called from kaweth_start_xmit() kaweth_async_set_rx_mode() obviously cannot block, which means it can't call kaweth_control(). This is detected with an in_interrupt() check. Replace the in_interrupt() check in kaweth_async_set_rx_mode() with an argument which is set true by the caller if the context is safe to sleep, otherwise false. Now kaweth_control() is only called from preemptible context which means there is no need for GFP_ATOMIC allocations anymore. Replace it with usb_control_msg(). Cleanup the code a bit while at it. Finally remove kaweth_control() since the last user is gone. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Sebastian Andrzej Siewior authored
kaweth_control() is almost the same as usb_control_msg() except for the memory allocation mode (GFP_ATOMIC vs GFP_NOIO) and the in_interrupt() check. All the invocations of kaweth_control() are within the probe function in fully preemtible context so there is no reason to use atomic allocations, GFP_NOIO which is used by usb_control_msg() is perfectly fine. Replace kaweth_control() invocations from probe with usb_control_msg(). Signed-off-by:
-
Sebastian Andrzej Siewior authored
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. handle_regs_int() is always invoked as part of URB callback which is either invoked from hard or soft interrupt context. Remove the magic assertion. Signed-off-by:
-
Sebastian Andrzej Siewior authored
vxge_os_dma_malloc() and vxge_os_dma_malloc_async() are both called from callchains which use GFP_KERNEL allocations unconditionally or have other requirements to be called from fully preemptible task context.. vxge_os_dma_malloc(): 1) __vxge_hw_blockpool_create() <- GFP_KERNEL 2) __vxge_hw_mempool_grow() <- vzalloc() __vxge_hw_blockpool_malloc() vxge_os_dma_malloc_async(): 1 __vxge_hw_mempool_grow() <- vzalloc() __vxge_hw_blockpool_malloc() __vxge_hw_blockpool_blocks_add() 2) vxge_hw_vpath_open() <- vzalloc() __vxge_hw_blockpool_block_allocate() That means neither of these functions needs a conditional allocation mode. Remove the in_interrupt() conditional and use GFP_KERNEL. Signed-off-by: -
Sebastian Andrzej Siewior authored
lance_interrupt() contains two pointless checks: - A check whether the 'dev_id' argument is NULL. 'dev_id' is the pointer which was handed in to request_irq() and the interrupt handler will always be invoked with that pointer as 'dev_id' argument by the core code. - A check for interrupt reentrancy. The core code already guarantees non-reentrancy of interrupt handlers. Remove these check. Signed-off-by:
-
Sebastian Andrzej Siewior authored
bigmac_init_rings() has an argument signaling if it is called from the interrupt handler. This is used to decide between GFP_KERNEL and GFP_ATOMIC for memory allocations. But it also checks in_interrupt() to handle invocations which come from the timer callback bigmac_timer() via bigmac_hw_init(), which is invoked with 'in_irq = 0'. While the timer callback is clearly not in hard interrupt context it is still not sleepable context. Rename the argument to `non_blocking' and set it to true if invoked from the timer callback or the interrupt handler which allows to remove the in_interrupt() check and makes the code consistent. Signed-off-by:
-
Sebastian Andrzej Siewior authored
efx_ef10_try_update_nic_stats_vf() is now only invoked from thread context and can sleep after efx::stats_lock is dropped. Change the allocation mode from GFP_ATOMIC to GFP_KERNEL. Signed-off-by:
-
Edward Cree authored
efx_ef10_try_update_nic_stats_vf() used in_interrupt() to figure out whether it is safe to sleep (for MCDI) or not. The only caller from which it was not is efx_net_stats(), which can be invoked under dev_base_lock from net-sysfs::netstat_show(). So add a new update_stats_atomic() method to struct efx_nic_type, and call it from efx_net_stats(), removing the need for efx_ef10_try_update_nic_stats_vf() to behave differently for this case (which it wasn't doing correctly anyway). For all nic_types other than EF10 VF, this method is NULL so the the regular update_stats() methods are invoked , which are happy with being called from atomic contexts. Fixes: f00bf230 ("sfc: don't update stats on VF when called in atomic context") Reported-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
Martin Habets <mhabets@solarflare.com> Signed-off-by:
-
Thomas Gleixner authored
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 passed by the caller, which usually knows the context. sonic_quiesce() uses 'in_interrupt() || irqs_disabled()' to chose either udelay() or usleep_range() in the wait loop. In all callchains leading to it the context is well defined and known. Add a 'may_sleep' argument and pass it through the various callchains leading to this function. Signed-off-by:
-
Sebastian Andrzej Siewior authored
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the check covers only parts of the contexts in which these functions cannot be called. It fails to detect preemption or interrupt disabled invocations. As the functions which contain these warnings invoke mutex_lock() which contains a broad variety of checks (always enabled or debug option dependent) and therefore covers all invalid conditions already, there is no point in having inconsistent warnings in those drivers. The conditional return is not really valuable in practice either. Just remove them. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Sebastian Andrzej Siewior authored
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the check covers only parts of the contexts in which these functions cannot be called. It fails to detect preemption or interrupt disabled invocations. As the functions which are invoked from ionic_adminq_post() and ionic_dev_cmd_wait() contain a broad variety of checks (always enabled or debug option dependent) which cover all invalid conditions already, there is no point in having inconsistent warnings in those drivers. Just remove them. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Sebastian Andrzej Siewior authored
The in_interrupt() usage in this driver tries to figure out which context may sleep and which context may not sleep. in_interrupt() is not really suitable as it misses both preemption disabled and interrupt disabled invocations from task context. Conditionals like that in driver code are frowned upon in general because invocations of functions from invalid contexts might not be detected as the conditional papers over it. ionic_lif_addr() and _ionoc_lif_rx_mode() can be called from: 1) ->ndo_set_rx_mode() which is under netif_addr_lock_bh()) so it must not sleep. 2) Init and setup functions which are in fully preemptible task context. ionic_link_status_check_request() has two call paths: 1) NAPI which obviously cannot sleep 2) Setup which is again fully preemptible task context Add arguments which convey the execution context to the affected functions and let the callers provide the context instead of letting the functions deduce it. Signed-off-by: -
Sebastian Andrzej Siewior authored
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the checks cover only parts of the contexts in which these functions cannot be called. They fail to detect preemption or interrupt disabled invocations. As the functions which are invoked from the various places contain already a broad variety of checks (always enabled or debug option dependent) cover all invalid conditions already, there is no point in having inconsistent warnings in those drivers. Just remove them. Signed-off-by:
Alexander Duyck <alexander.h.duyck@linux.intel.com> Signed-off-by:
-
