On August 18, 2021 5:11:10 PM Fabio Estevam wrote:
When running the "hostapd" application on a i.MX7-based board with
an ath10k device connected via SDIO, the following warning is seen:
[ cut here ]
WARNING: CPU: 0 PID: 489 at kernel/dma/mapping.c:427
Hi Paul,
On Wed, Aug 18, 2021 at 1:29 PM Fabio Estevam wrote:
>
> Hi Paul,
>
> On Wed, Aug 18, 2021 at 12:43 PM Paul E. McKenney wrote:
>
> > I believe that you need this commit (and possibly some prerequsites):
> >
> > 47c218dcae65 ("tick/sched: Prevent false positive softirq pending warnings
On Wed, Aug 18, 2021 at 02:02:17PM -0300, Fabio Estevam wrote:
> Hi Paul,
>
> On Wed, Aug 18, 2021 at 1:29 PM Fabio Estevam wrote:
> >
> > Hi Paul,
> >
> > On Wed, Aug 18, 2021 at 12:43 PM Paul E. McKenney
> > wrote:
> >
> > > I believe that you need this commit (and possibly some
Hi,
When launching the hostapd application on a i.MX7 based board with an
ath10k device connected via SDIO, the following "NOHZ tick-stop error"
messages are seen:
# hostapd /etc/wifi.conf
Configuration file: /etc/wifi.conf
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
[ 63.021149] NOHZ
On Wed, Aug 18, 2021 at 12:18:25PM -0300, Fabio Estevam wrote:
> Hi,
>
> When launching the hostapd application on a i.MX7 based board with an
> ath10k device connected via SDIO, the following "NOHZ tick-stop error"
> messages are seen:
>
> # hostapd /etc/wifi.conf
> Configuration file:
Hi Paul,
On Wed, Aug 18, 2021 at 12:43 PM Paul E. McKenney wrote:
> I believe that you need this commit (and possibly some prerequsites):
>
> 47c218dcae65 ("tick/sched: Prevent false positive softirq pending warnings on
> RT")
>
> Adding Qais on CC for his thoughts.
Thanks for the suggestion,
Fix the problem by not calling dma_alloc_coherent() when the device
is not DMA capable, such as SDIO and USB.
ath10k calls dma_alloc_coherent multiple places including
ath10k_htt_rx_alloc.
Do SDIO and USB not use such data path function at all?
Thanks,
Peter
When running the "hostapd" application on a i.MX7-based board with
an ath10k device connected via SDIO, the following warning is seen:
[ cut here ]
WARNING: CPU: 0 PID: 489 at kernel/dma/mapping.c:427 dma_alloc_attrs+0xd0/0x114
Modules linked in: ath10k_sdio ath10k_core
Hi Peter,
On Wed, Aug 18, 2021 at 2:35 PM Peter Oh wrote:
>
>
> >> Fix the problem by not calling dma_alloc_coherent() when the device
> >> is not DMA capable, such as SDIO and USB.
> >>
> ath10k calls dma_alloc_coherent multiple places including
> ath10k_htt_rx_alloc.
>
> Do SDIO and USB not
Hi Peter,
On Wed, Aug 18, 2021 at 2:35 PM Peter Oh wrote:
>
>
> >> Fix the problem by not calling dma_alloc_coherent() when the device
> >> is not DMA capable, such as SDIO and USB.
> >>
> ath10k calls dma_alloc_coherent multiple places including
> ath10k_htt_rx_alloc.
>
> Do SDIO and USB not
On Wed, Aug 18, 2021 at 11:56:35AM +0200, Marc Kleine-Budde wrote:
> On 18.08.2021 01:11:15, Kees Cook wrote:
> > diff --git a/drivers/net/can/usb/etas_es58x/es581_4.h
> > b/drivers/net/can/usb/etas_es58x/es581_4.h
> > index 4bc60a6df697..8657145dc2a9 100644
> > ---
On Wed, Aug 18, 2021 at 10:37 AM Fabio Estevam wrote:
>
> Hi Christoph,
>
> On Wed, Aug 18, 2021 at 10:28 AM Christoph Hellwig wrote:
> >
> > On Wed, Aug 18, 2021 at 06:31:19AM -0300, Fabio Estevam wrote:
> > > Correct, on i.MX7 the ath10k Wifi chip connects via SDIO.
> > >
> > > Is there a way
From: Alagu Sankar
Beacon buffer for high latency devices does not use DMA. other similar
buffer allocation methods in the driver have already been modified for
high latency path. Fix the beacon buffer allocation left out in the
earlier high latency changes.
Signed-off-by: Alagu Sankar
The 0-element arrays that are used as memcpy() destinations are actually
flexible arrays. Adjust their structures accordingly so that memcpy()
can better reason able their destination size (i.e. they need to be seen
as "unknown" length rather than "zero").
In some cases, use of the flex_array()
In support of enabling -Warray-bounds and -Wzero-length-bounds and
correctly handling run-time memcpy() bounds checking, replace all
open-coded flexible arrays (i.e. 0-element arrays) in unions with the
flex_array() helper macro.
This fixes warnings such as:
fs/hpfs/anode.c: In function
Hi Arend,
On Wed, Aug 18, 2021 at 1:51 PM Arend van Spriel wrote:
> Does this mean you can not really setup a beaconing interface type for SDIO
> and USB?
As per the debug message below:
ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev create %d (add interface)
type %d subtype %d bcnmode %s\n",
When running the "hostapd" application on a i.MX7-based board with
an ath10k device connected via SDIO, the following warning is seen:
[ cut here ]
WARNING: CPU: 0 PID: 489 at kernel/dma/mapping.c:427 dma_alloc_attrs+0xd0/0x114
Modules linked in: ath10k_sdio ath10k_core
On 18.08.2021 01:11:15, Kees Cook wrote:
> diff --git a/drivers/net/can/usb/etas_es58x/es581_4.h
> b/drivers/net/can/usb/etas_es58x/es581_4.h
> index 4bc60a6df697..8657145dc2a9 100644
> --- a/drivers/net/can/usb/etas_es58x/es581_4.h
> +++ b/drivers/net/can/usb/etas_es58x/es581_4.h
> @@ -192,7
Hi Christoph,
On Wed, Aug 18, 2021 at 2:11 AM Christoph Hellwig wrote:
>
> On Tue, Aug 17, 2021 at 09:23:26PM -0300, Fabio Estevam wrote:
> >
> > void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t
> > *dma_handle,
> >
> > WARN_ON_ONCE(!dev->coherent_dma_mask);
> >
> > Where
On Wed, Aug 18, 2021 at 06:31:19AM -0300, Fabio Estevam wrote:
> Correct, on i.MX7 the ath10k Wifi chip connects via SDIO.
>
> Is there a way to avoid the WARN_ON_ONCE(!dev->coherent_dma_mask)
> to happen in this case?
The way to avoid it is by stoppind to use dma_alloc_attrs/coherent
on a
Hi Christoph,
On Wed, Aug 18, 2021 at 10:28 AM Christoph Hellwig wrote:
>
> On Wed, Aug 18, 2021 at 06:31:19AM -0300, Fabio Estevam wrote:
> > Correct, on i.MX7 the ath10k Wifi chip connects via SDIO.
> >
> > Is there a way to avoid the WARN_ON_ONCE(!dev->coherent_dma_mask)
> > to happen in this
21 matches
Mail list logo
