On 5/7/2019 5:38 PM, Hans de Goede wrote:
Hi,
On 06-05-19 21:30, Arend Van Spriel wrote:
+ Luis (for real this time)
On 5/6/2019 6:05 PM, Hans de Goede wrote:
Hi,
On 06-05-19 17:24, Victor Bravo wrote:
On Mon, May 06, 2019 at 03:26:28PM +0300, Kalle Valo wrote:
Hans de Goede writes:
If
In previous kernel versions I could do:
make M=net/wireless cfg80211.ko
However, in 5.3-rc1 I now get:
$ make M=net/wireless cfg80211.ko
make[1]: *** No rule to make target `cfg80211.ko'. Stop.
make: *** [sub-make] Error 2
The 'modules' target is working, but sometimes there are multiple
mod
On 6/25/2019 10:02 AM, Johannes Berg wrote:
On Tue, 2019-06-25 at 01:00 -0700, Tony Lindgren wrote:
Hi,
* Johannes Berg [190625 07:47]:
On Tue, 2019-06-25 at 00:38 -0700, Tony Lindgren wrote:
Hi,
Looks like at least drivers/net/wireless/ti wlcore driver has stopped
working in Linux next wit
On 7/2/2019 11:50 AM, Markus Elfring wrote:
From: Markus Elfring
Date: Tue, 2 Jul 2019 11:31:07 +0200
A line break and a single string should be put into a sequence.
Thus use the corresponding output functions.
This issue was detected by using the Coccinelle software.
pot-ato, po-tato
Sign
On June 6, 2019 11:37:22 PM Doug Anderson wrote:
In the case of dw_mmc, which I'm most familiar with, we don't have any
sort of automated or timed-based retuning. ...so we'll only re-tune
when we see the CRC error. If I'm understanding things correctly then
that for dw_mmc my solution and you
On June 7, 2019 2:40:04 PM Adrian Hunter wrote:
On 7/06/19 8:12 AM, Arend Van Spriel wrote:
On June 6, 2019 11:37:22 PM Doug Anderson wrote:
In the case of dw_mmc, which I'm most familiar with, we don't have any
sort of automated or timed-based retuning. ...so we'll only
On June 7, 2019 8:06:30 PM Doug Anderson wrote:
Hi,
On Fri, Jun 7, 2019 at 6:32 AM Arend Van Spriel
wrote:
Right. I know it supports initial tuning, but I'm not sure about subsequent
retuning initiated by the host controller.
My evidence says that it supports subsequent tuning. In
On 1/8/2019 5:43 PM, Kalle Valo wrote:
Kangjie Lu writes:
usb_register() may fail, so let's check its status and issue an error
message if it fails.
Signed-off-by: Kangjie Lu
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 6 +-
The title prefix should be "brcmfmac: " but
On 3/11/2019 8:32 AM, Kangjie Lu wrote:
In case kmemdup fails, the fix returns -ENOMEM to avoid NULL
pointer dereferences.
Hi Kangjie Lu,
Are you fixing any reported issue with this? If you looked further you
would see that this function is called in two places and the return
value is not ch
On 3/19/2018 2:40 AM, Alexey Roslyakov wrote:
In case if the host has higher align requirements for SG items, allow
setting device-specific aligns for scatterlist items.
Signed-off-by: Alexey Roslyakov
---
Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 5 +
1 file
On 4/20/2018 12:26 PM, Kalle Valo wrote:
Andres Rodriguez writes:
This reduces the unnecessary spew when trying to load optional firmware:
"Direct firmware load for ... failed with error -2"
So what happened with the request_firmware_nowarn() api (discussed in
another thread). Did it get lo
On 3/14/2018 10:06 AM, Arend van Spriel wrote:
On 2/9/2018 10:13 AM, Arend van Spriel wrote:
Commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") added
a new callback in struct device_driver, but not a kerneldoc description
so here it is.
Hi Greg,
Revisiting the hea
The check for the .coredump() callback in coredump_store() is
redundant. It is already assured the device driver implements
the callback upon creating the coredump sysfs entry.
Signed-off-by: Arend van Spriel
---
drivers/base/dd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
Instead of referring to kernel internals, describe the ABI from user-space
perspective to clarify what can be expected when using it.
Signed-off-by: Arend van Spriel
---
Documentation/ABI/testing/sysfs-devices-coredump | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff
changing it to void.
[1] https://patchwork.kernel.org/patch/10231933/
Signed-off-by: Arend van Spriel
---
include/linux/device.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index b093405..f08c25b 100644
--- a/include/linux
Not sure if this can be considered as fix for v4.16. Upon submitting
the driver patches I received valuable feedback that I would like to
address with this series.
The patch apply to master and driver-core-next of the driver-core
repository so you can take it either way.
Arend van Spriel (3
On 3/15/2018 6:05 PM, Brian Norris wrote:
On Thu, Mar 15, 2018 at 10:55:23AM +0100, Arend van Spriel wrote:
Instead of referring to kernel internals, describe the ABI from user-space
perspective to clarify what can be expected when using it.
Signed-off-by: Arend van Spriel
---
Documentation
On Sun, Apr 8, 2018 at 11:57 PM, Arend van Spriel wrote:
> Upon submitting a patch for mwifiex [1] it was discussed whether this
> callback function could fail. To keep things simple there is no need
> for the error code so the driver can do the task synchronous or not
> wit
On 8-12-2016 1:40, Pan Bian wrote:
> Function orinoco_ioctl_commit() returns 0 (indicates success) when the
> call to orinoco_lock() fails. Thus, the return value is inconsistent with
> the execution status. It may be better to return "-EBUSY" when the call
> to orinoco_lock() fails.
>
> Bugzilla
On 22-11-2016 18:05, Pali Rohár wrote:
> On Tuesday 22 November 2016 17:14:28 Michal Kazior wrote:
>> On 22 November 2016 at 16:31, Pali Rohár wrote:
>>> On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
On 21 November 2016 at 16:51, Pali Rohár
wrote:
> On Friday 11 November
On 27-1-2017 10:43, Pali Rohár wrote:
> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
>> Pali Rohár writes:
>>
>>> NVS calibration data for wl1251 are model specific. Every one device with
>>> wl1251 chip has different and calibrated in factory.
>>>
>>> Not all wl1251 chips have own EEPROM
On 27-1-2017 11:10, Pali Rohár wrote:
> On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
>> On 27-1-2017 10:43, Pali Rohár wrote:
>>> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
>>>> Pali Rohár writes:
>>>>
>>>>> NVS
On 27-1-2017 13:26, Kalle Valo wrote:
> Pali Rohár writes:
>
>> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
>>> Pali Rohár writes:
>>>
> So
> for those other platforms there will be a delay waiting for user-mode
> helper to fail, before trying to get nvs file from /lib/firmw
On 27-1-2017 8:33, Kalle Valo wrote:
> Pali Rohár writes:
>
>> NVS calibration data for wl1251 are model specific. Every one device with
>> wl1251 chip has different and calibrated in factory.
>>
>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
>> in that case there
A question for whoever can provide the answer. I have a kernel defconfig
with everything built-in. However, I want to compile a driver module
against it for testing. So I enabled CONFING_MODULES, but as a
side-effect several implicitly selected config options changed from
CONFIG_FOO=y to CONFIG_FOO
nels
>before preparing limits).
> 3) It modifies mbss code to use i variable just like other combos do.
Acked-by: Arend van Spriel
> Signed-off-by: Rafał Miłecki
> ---
> .../broadcom/brcm80211/brcmfmac/cfg80211.c | 37
> ++
> 1 file changed,
On 26-05-16 01:44, Rafał Miłecki wrote:
> The old implementation was overcomplicated and slightly bugged in some
> corner cases.
>
> Consider following state of BSS-es (limited to 6 for simplification):
> drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, }
> drvr->iflist[1]: (null)
> drvr->iflist
On 14-06-16 13:44, Jakub Kicinski wrote:
> C bitfields are problematic and best avoided. Developers
> interacting with hardware registers find themselves searching
> for easy-to-use alternatives. Common approach is to define
> structures or sets of macros containing mask and shift pair.
> Operati
?
For the module I noticed it uses command line parameter -mcmodel=large
so I suppose that could be how I ended up with PREL32.
In arch/arm64/Makefile there is this:
ifeq ($(CONFIG_ARM64_ERRATUM_843419), y)
KBUILD_CFLAGS_MODULE += -mcmodel=large
endif
And that Kconfig item is indeed set.
On 01-06-16 11:01, Arend Van Spriel wrote:
>
>
> On 31-5-2016 22:58, Ard Biesheuvel wrote:
>> On 31 May 2016 at 22:24, Dmitry Shmidt wrote:
>>> On Mon, May 30, 2016 at 4:30 AM, Ard Biesheuvel
>>> wrote:
>>>> This is likely caused by the fact that t
On 01-06-16 16:36, Rafał Miłecki wrote:
> We already support adding extra (AP) interfaces so it also makes an
> obvious sense to allow deleting them.
>
> Adding a new interface is implemented by sending request to firmware for
> creating a new BSS and waiting for a proper event. Ideally deleting
>
On 31-5-2016 13:46, Grey Christoforo wrote:
> Hi,
>
> I found the following in my dmesg today when I tried out 4.7-rc1 on my
> Dell XPS15 9550. My WiFi doesn't work.
>
> Relevant bits of my lsusb & lspci are:
>
> $ lsusb
> ...
> Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp.
> ...
> $ lspci
> .
I got myself an arm64 HiKey board from LeMaker and build an Android AOSP
image for it (see [1]). For development I would like to use
CONFIG_MODULES. However, when I try to insmod the build module I get:
[ 287.903653] module cfg80211: overflow in relocation type 261 val
ffbffc006530
Looking A
ile command line twice. To no avail so that ain't
working.
Regards,
Arend
>> On 30 mei 2016, at 12:21, Arend Van Spriel
>> wrote:
>>
>> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP
>> image for it (see [1]). For development I would li
On 21-12-2016 23:23, Ozgur Karatas wrote:
>
> The patch fixed to struct uses in reg.c, I think doesn't need to be use to
> "struct".
> There is dataype not have to logical link and each is different definitons.
>
> I'm undecided on this patch. I compiled and didn't to errors.
There must be s
On 23-12-2016 1:43, Colin King wrote:
> From: Colin Ian King
>
> Trivial fixes to spelling mistake "Ivalid" to "Invalid" in
> brcmf_err error messages.
Acked-by: Arend van Spriel
> Signed-off-by: Colin Ian King
> ---
> drivers/net/wireless/broadcom/br
On 24-12-2016 17:52, Pali Rohár wrote:
> NVS calibration data for wl1251 are model specific. Every one device with
> wl1251 chip has different and calibrated in factory.
>
> Not all wl1251 chips have own EEPROM where are calibration data stored. And
> in that case there is no "standard" place. Eve
On 15-12-2016 16:33, Pali Rohár wrote:
> On Thu Dec 15 09:18:44 2016 Kalle Valo wrote:
>> (Adding Luis because he has been working on request_firmware() lately)
>>
>> Pali Rohár writes:
>>
> So no, there is no argument against... request_firmware() in
> fallback mode with userspace helper
> drivers/net/wireless/ath/wil6210/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
For brcm80211 drivers:
Acked-by: Arend van Spriel
Regards,
Arend
On 16-12-2016 11:40, Pali Rohár wrote:
> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>>> For the new API a solution for "fallback mechanisms" should be
>>> clean though and I am looking to stay as far as possible from the
>>> existing
On 18-12-2016 11:49, Jiri Slaby wrote:
> On 12/18/2016, 12:59 AM, Linus Torvalds wrote:
>> On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby wrote:
>>>
>>> Yes, disk drivers won't load:
>>> [2.141973] virtio_pci: disagrees about version of symbol mcount
>>> [2.144415] virtio_pci: Unknown symbol
On 18-12-2016 12:04, Pali Rohár wrote:
> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
>> On 16-12-2016 11:40, Pali Rohár wrote:
>>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>>>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>&g
On 18-12-2016 13:09, Pali Rohár wrote:
> On Sunday 18 December 2016 12:54:00 Arend Van Spriel wrote:
>> On 18-12-2016 12:04, Pali Rohár wrote:
>>> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
>>>> On 16-12-2016 11:40, Pali Rohár wrote:
>>>
On 12-12-2016 9:32, Rafał Miłecki wrote:
> On 12 December 2016 at 09:12, Johannes Berg wrote:
>> On Sat, 2016-12-10 at 16:54 +0100, Rafał Miłecki wrote:
>>> In brcmfmac we use request_firmware_nowait and if fetching firmware
>>> with NVRAM variables fails then we try to fallback to the platform
>>
On 7-3-2017 10:44, Kalle Valo wrote:
> Arnd Bergmann writes:
>
>> On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo wrote:
>>> Arend Van Spriel writes:
>>>
>>>> On 2-3-2017 17:38, Arnd Bergmann wrote:
>>>>> With KASAN and a couple of o
brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of
> 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>
> Here, I'm reducing the stack size by marking as many local variables as
> 'static const' as I can without changing the actual code.
Acked-by: A
me.
>
> I'm leaving the original indentation to make the review easier.
Thanks ;-)
Acked-by: Arend van Spriel
> Signed-off-by: Arnd Bergmann
> ---
> .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 178
> -
> 1 file changed, 104 insertions
tespace are intended here.
Acked-by: Arend van Spriel
> Signed-off-by: Arnd Bergmann
> ---
> .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1507
> +---
> 1 file changed, 697 insertions(+), 810 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/b
On 2-3-2017 17:38, Arnd Bergmann wrote:
> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an
> object
> on the stack, which will each require a redzone with KASAN and lead to
> possible
> stack overflow:
>
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:
On 6-3-2017 11:38, Arnd Bergmann wrote:
> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel
> wrote:
>> On 2-3-2017 17:38, Arnd Bergmann wrote:
>>> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put
>>> an object
>>> on the stack,
On 17-06-16 14:30, Rafał Miłecki wrote:
> On 1 June 2016 at 21:00, Arend van Spriel
> wrote:
>> On 01-06-16 16:36, Rafał Miłecki wrote:
>>> We already support adding extra (AP) interfaces so it also makes an
>>> obvious sense to allow deleting them.
>>>
&g
On 18-06-16 20:18, Rafał Miłecki wrote:
> So far when receiving event about in-firmware-interface removal we were
> notifying our listener and afterwards we were removing Linux interface.
>
[snip]
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
> b/drivers/net/wireless
On 18-06-16 20:18, Rafał Miłecki wrote:
> New firmwares (e.g. 10.10.69.36 for BCM4366) support "interface_remove"
> for removing interfaces. Try to use this method on cfg80211 request. In
> case of older firmwares (e.g. 7.35.177.56 for BCM43602 as I tested) this
> will just result in firmware rejec
On 1-3-2017 9:59, Romain Perier wrote:
> Currently, mmc_power_up calls the pre_power_on callback, enables the
> power supply of the mmc by calling mmc_set_ios() and then call
> post_power_on. WiFi chipsets like the AP6335 require a specific power
> sequence ordering before being used. You must enab
ls as well, then it's a
> right moment to print an error.
>
> This should reduce amount of false reports from users seeing this
> warning while having wireless working perfectly fine.
I think FW_OPT_NO_WARN does not cover all warnings in firmware_class
although I did not chec
On 22-2-2017 18:14, Tahia Khan wrote:
> Fixes multiple camel case checks on struct tstrRSSI from checkpatch.pl:
>
> Avoid CamelCase:
> Avoid CamelCase:
> Avoid CamelCase:
Just a generic remark that may help you with other changes you will be
making in the linux kernel. Warnings from checkpatch
On 23-2-2017 8:08, Julia Lawall wrote:
>> Thanks for the feedback Arend, I really appreciate it. I've decided to go
>> with
>> these changes in my follow-up patch request:
>>
>> - rename tstrRSSI to 'rssi_history_buffer' as Aren suggested since it makes
>> the
>> purpose of the struct clear
>> -
On 16-2-2017 8:26, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Failing to load NVRAM file isn't critical if we manage to get platform
> one in the fallback path. It means warnings like:
> [ 10.801506] brcmfmac :01:00.0: Direct firmware load for
> brcm/brcmfmac43602-pcie.txt failed with
On 16-2-2017 10:04, Rafał Miłecki wrote:
> On 2017-02-16 09:38, Arend Van Spriel wrote:
>> On 16-2-2017 8:26, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> Failing to load NVRAM file isn't critical if we manage to get platform
>>>
On 16-2-2017 10:39, Rafał Miłecki wrote:
> On 02/16/2017 10:31 AM, Kalle Valo wrote:
>> (Adding linux-wireless)
>>
>> Randy Dunlap writes:
>>
>>> On 02/07/17 02:02, kbuild test robot wrote:
Hi Kalle,
FYI, the error/warning still remains.
tree:
https://git.kernel.org
On 16-2-2017 10:32, Rafał Miłecki wrote:
> On 2017-02-16 10:18, Arend Van Spriel wrote:
>> On 16-2-2017 10:04, Rafał Miłecki wrote:
>>> On 2017-02-16 09:38, Arend Van Spriel wrote:
>>>> On 16-2-2017 8:26, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki
On 16-2-2017 11:01, Kalle Valo wrote:
> Arend Van Spriel writes:
>
>> On 16-2-2017 10:39, Rafał Miłecki wrote:
>>> On 02/16/2017 10:31 AM, Kalle Valo wrote:
>>>> (Adding linux-wireless)
>>>>
>>>> Randy Dunlap writes:
>>>&
On 10-8-2016 20:32, Luis R. Rodriguez wrote:
> On Fri, Jun 17, 2016 at 08:35:03PM +0200, Luis R. Rodriguez wrote:
>> On Thu, Jun 16, 2016 at 05:09:30PM -1000, Linus Torvalds wrote:
>>> On Thu, Jun 16, 2016 at 3:36 PM, Luis R. Rodriguez
>>> wrote:
Reason this could not wait is folks seem
On 03-08-16 09:42, Dmitry Torokhov wrote:
> On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez wrote:
>> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
>>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
>> Th
On 03-08-16 17:35, Dmitry Torokhov wrote:
>> In my opinion the kernel should provide functionality to user-space and
>> > user-space providing functionality to the kernel should be avoided.
> Why? We have bunch of stuff running in userspace for the kernel. Fuse
> for example. I am sure there are
On 27-8-2016 8:08, Baoyou Xie wrote:
> We get 1 warning when biuld kernel with W=1:
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c:23:6: warning:
> no previous prototype for '__brcmf_err' [-Wmissing-
> prototypes]
>
> In fact, this function is declared in brcmfmac/debug.h, so thi
On 18-08-16 16:17, Javier Martinez Canillas wrote:
> If request_irq() fails in mwifiex_sdio_probe_of(), only an error message
> is printed but the actual error is not propagated to the caller function.
Hmm. The caller function, ie. mwifiex_sdio_probe(), does not seem to care.
The device may still
On 18-08-16 21:29, Javier Martinez Canillas wrote:
> Hello Arend,
>
> Thanks a lot for your feedback.
>
> On 08/18/2016 03:14 PM, Arend van Spriel wrote:
>> On 18-08-16 16:17, Javier Martinez Canillas wrote:
>>> If request_irq() fails in mwifiex_sdio_probe_of()
On 09-06-16 21:16, Arend van Spriel wrote:
> On 26-05-16 01:44, Rafał Miłecki wrote:
>> The old implementation was overcomplicated and slightly bugged in some
>> corner cases.
>>
[...]
>> New code is simpler, placed in file where it's really used, handles
&
On 29-03-16 16:02, Al Viro wrote:
> On Tue, Mar 29, 2016 at 01:11:55PM +0200, Arend Van Spriel wrote:
>> Hi Al,
>>
>> Moved to 4.6-rc1 and found NFS mounts were failing moving to the new
>> kernel. The NFS mounts are done using autofs. Below is the bisect log
>>
On 08/20/2015 11:46 PM, Murali Karicheri wrote:
All,
Please help me understand the procedure to add a firmware ihex file to
kernel source tree under firmware/ folder. The README.AddingFirmware
file explains that file should be added to
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux
On 07/10/2015 06:49 AM, Vineet Gupta wrote:
On Thursday 09 July 2015 11:55 PM, Arend van Spriel wrote:
On 07/09/2015 10:13 AM, Vineet Gupta wrote:
There's already a generic implementation so use that instead.
There is or there was? If there is now I am fine with this patch, but if
it al
I guess we need this fix for
now so...
Acked-by: Arend van Spriel
> Signed-off-by: Sjoerd Simons
>
> ---
Still would like to know whether it is firmware initialization or some
mmc stack procedure. Any suggestions to debug this are welcome.
Regards,
Arend
---
>
> drivers/net/wir
On 25-01-16 12:06, Julian Calaby wrote:
> Hi Sjoerd,
>
> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
> wrote:
>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>> the card responds very quickly most of the time, unfortunately during
>> initialisation it sometimes seem
On 25-1-2016 20:23, Doug Anderson wrote:
> Hi,
>
> On Mon, Jan 25, 2016 at 7:36 AM, Arend van Spriel wrote:
>> On 25-01-16 11:47, Sjoerd Simons wrote:
>>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>>> the card responds very quickl
On 26-01-16 00:41, Julian Calaby wrote:
> Hi Arend,
>
> On Tue, Jan 26, 2016 at 2:39 AM, Arend van Spriel wrote:
>> On 25-01-16 12:06, Julian Calaby wrote:
>>> Hi Sjoerd,
>>>
>>> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
>>> wrote:
>&g
+ Jes
On 10/5/2020 4:12 PM, Kalle Valo wrote:
Greg Kroah-Hartman writes:
On Fri, Oct 02, 2020 at 01:53:58PM +0200, Sebastian Andrzej Siewior wrote:
On 2020-10-02 13:37:25 [+0200], Greg Kroah-Hartman wrote:
Is it possible to end up here in softirq context or is this a relic?
I think it's a
_rx_frame(isirq = true)
brcmf_rx_frame()
brcmf_proto_rxreorder()
brcmf_proto_bcdc_rxreorder()
brcmf_fws_rxreorder()
brcmf_netif_rx()
brcmf_netif_rx()
Thanks for taking the dive.
Reviewed-by: Arend van Spriel
Signed-off-by: Thomas Gleixner
Cc: Arend van Spriel
Cc: K
ns will be detected by the
memory allocator for all GFP_KERNEL allocations.
Reviewed-by: Arend van Spriel
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
V2: Adopt to the 'inirq' changes
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 10
+ Uffe
On 9/27/2020 9:49 PM, Thomas Gleixner wrote:
@@ -85,7 +85,7 @@ static void brcmf_sdiod_ib_irqhandler(st
brcmf_dbg(INTR, "IB intr triggered\n");
- brcmf_sdio_isr(sdiodev->bus);
+ brcmf_sdio_isr(sdiodev->bus, false);
}
Hi Uffe,
I assume the above code is okay, but want
On 9/27/2020 9:49 PM, Thomas Gleixner wrote:
From: Sebastian Andrzej Siewior
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.
brcmfmac uses in_interupt() to selec
On 9/27/2020 10:47 AM, Dmitry Vyukov wrote:
On Sun, Sep 27, 2020 at 10:38 AM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:748d1c8a Merge branch 'devlink-Use-nla_policy-to-validate-..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt
On 9/27/2020 9:49 PM, Thomas Gleixner wrote:
From: Sebastian Andrzej Siewior
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
On 9/28/2020 11:19 AM, Ulf Hansson wrote:
On Mon, 28 Sep 2020 at 09:35, Arend Van Spriel
wrote:
+ Uffe
On 9/27/2020 9:49 PM, Thomas Gleixner wrote:
@@ -85,7 +85,7 @@ static void brcmf_sdiod_ib_irqhandler(st
brcmf_dbg(INTR, "IB intr triggered\n");
- brcmf_sdio_isr(sd
, so add an argument `in_isr' to brcmf_sdio_isr() and let
the callers pass the information about the calling context.
After getting confirmation here is my ...
Reviewed-by: Arend van Spriel
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Arend van Spriel
Cc: F
On 9/28/2020 12:04 PM, Dmitry Vyukov wrote:
On Mon, Sep 28, 2020 at 11:31 AM Arend Van Spriel
wrote:
On 9/27/2020 10:47 AM, Dmitry Vyukov wrote:
On Sun, Sep 27, 2020 at 10:38 AM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:748d1c8a Merge branch 'devlin
driver and it's the same as the
value used for the BCM4339 chip, hence let's re-use it for BCM4329.
one comment, but when fixed you can add my
Reviewed-by: Arend van Spriel
Signed-off-by: Dmitry Osipenko
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 +
1 fi
On 8/17/2020 11:06 AM, Allen Pais wrote:
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Acked-by: Arend van Spriel
On 9/7/2020 6:22 PM, Keita Suzuki wrote:
When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy,
the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be
freed in the caller function.
Fix this by calling wlc_phy_detach_lcnphy in the error handler of
wlc_phy_txpwr_sr
On 9/8/2020 2:13 AM, Keita Suzuki wrote:
When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy,
the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be
freed in the caller function.
Fix this by calling wlc_phy_detach_lcnphy in the error handler of
wlc_phy_txpwr_srom_
On 9/8/2020 2:02 PM, Keita Suzuki wrote:
Thank you for your comment. I am relatively new to the Linux
kernel community, so I am more than happy to receive comments.
Please let me know if I'm violating any other rules.
Sure ;-)
Here a useful link that Kalle (wireless drivers maintainer) is alwa
On September 13, 2020 4:35:44 PM t...@redhat.com wrote:
From: Tom Rix
clang static analysis flags this problem
sdio.c:3265:13: warning: Branch condition evaluates to
a garbage value
} else if (pending) {
^~~
brcmf_sdio_dcmd_resp_wait() only sets pending to true.
On 5/27/2019 2:08 PM, Adrian Hunter wrote:
On 27/05/19 12:37 PM, Brian Masney wrote:
On Sun, May 26, 2019 at 03:58:19PM -0400, Brian Masney wrote:
I attached a patch that shows how I was able to determine what had
already claimed the host.
On Mon, May 27, 2019 at 10:48:24AM +0300, Adrian Hunte
On June 4, 2019 6:01:26 PM Doug Anderson wrote:
Hi,
On Mon, Jun 3, 2019 at 8:20 PM Wright Feng wrote:
On 2019/5/29 上午 12:11, Arend Van Spriel wrote:
> On May 28, 2019 6:09:21 PM Arend Van Spriel
> wrote:
>
>> On May 28, 2019 5:52:10 PM Doug Anderson wrote:
>>
>&g
On 6/3/2019 8:37 PM, Douglas Anderson wrote:
Normally when the MMC core sees an "-EILSEQ" error returned by a host
controller then it will trigger a retuning of the card. This is
generally a good idea.
However, if a command is expected to sometimes cause transfer errors
then these transfer erro
On 6/12/2019 12:10 PM, Ulf Hansson wrote:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:
mmc_set_data_timeout(md, func->card);
mmc_wait_for_req(func->card->host, mr);
These are not okay, none of these things calls should really be done
from an SDIO func driver.
It tells me tha
On 6/12/2019 1:48 PM, Ulf Hansson wrote:
On Wed, 12 Jun 2019 at 13:11, Arend Van Spriel
wrote:
On 6/12/2019 12:10 PM, Ulf Hansson wrote:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:
mmc_set_data_timeout(md, func->card);
mmc_wait_for_req(func->card->host, mr
On 5/28/2019 12:04 PM, Adrian Hunter wrote:
On 26/05/19 9:42 PM, Arend Van Spriel wrote:
On 5/18/2019 12:54 AM, Douglas Anderson wrote:
Normally when the MMC core sees an "-EILSEQ" error returned by a host
controller then it will trigger a retuning of the card. This is
genera
On May 28, 2019 5:52:10 PM Doug Anderson wrote:
Hi,
On Tue, May 28, 2019 at 5:18 AM Kalle Valo wrote:
Douglas Anderson wrote:
> In commit 29f6589140a1 ("brcmfmac: disable command decode in
> sdio_aos") we disabled something called "command decode in sdio_aos"
> for a whole bunch of Broadc
On May 28, 2019 6:09:21 PM Arend Van Spriel
wrote:
On May 28, 2019 5:52:10 PM Doug Anderson wrote:
Hi,
On Tue, May 28, 2019 at 5:18 AM Kalle Valo wrote:
Douglas Anderson wrote:
> In commit 29f6589140a1 ("brcmfmac: disable command decode in
> sdio_aos") we disabled
401 - 500 of 545 matches
Mail list logo
