Re: [PATCH v2 2/2] brcmfmac: support parse country code map from DT

Guo Reviewed-by: Arend van Spriel --- .../wireless/broadcom/brcm80211/brcmfmac/of.c | 57 ++- 1 file changed, 55 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c index a7554265f

Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map

On 09-04-2021 20:46, Rob Herring wrote: On Thu, Apr 08, 2021 at 07:30:21PM +0800, Shawn Guo wrote: Add optional brcm,ccode-map property to support translation from ISO3166 country code to brcmfmac firmware country code and revision. Signed-off-by: Shawn Guo ---

Re: [PATCH 2/2] brcmfmac: support parse country code map from DT

On 13-04-2021 09:45, Shawn Guo wrote: On Mon, Apr 12, 2021 at 10:09:38AM +0200, Arend van Spriel wrote: On 08-04-2021 13:30, Shawn Guo wrote: With any regulatory domain requests coming from either user space or 802.11 IE (Information Element), the country is coded in ISO3166 standard

Re: [PATCH] brcmfmac: Add support for BCM43596 PCIe Wi-Fi

On 07-03-2021 12:35, Konrad Dybcio wrote: Add support for BCM43596 dual-band AC chip, found in SONY Xperia X Performance, XZ and XZs smartphones (and *possibly* other devices from other manufacturers). The chip doesn't require any special handling and seems to work just fine OOTB. PCIe IDs

Re: [PATCH 2/2] brcmfmac: support parse country code map from DT

On 08-04-2021 13:30, Shawn Guo wrote: With any regulatory domain requests coming from either user space or 802.11 IE (Information Element), the country is coded in ISO3166 standard. It needs to be translated to firmware country code and revision with the mapping info in settings->country_codes

Re: [PATCH 2/2] brcmfmac: support parse country code map from DT

des table. Support populate country_codes table by parsing the mapping from DT. comment below, but you may add... Reviewed-by: Arend van Spriel Signed-off-by: Shawn Guo --- .../wireless/broadcom/brcm80211/brcmfmac/of.c | 53 +++ 1 file changed, 53 insertions(+) diff --

Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map

On 08-04-2021 13:30, Shawn Guo wrote: Add optional brcm,ccode-map property to support translation from ISO3166 country code to brcmfmac firmware country code and revision. Reviewed-by: Arend van Spriel Signed-off-by: Shawn Guo --- .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt

Re: [PATCH v2] brcmfmac: add support for CQM RSSI notifications

monitoring purposes. Reviewed-by: Arend van Spriel Signed-off-by: Alvin Šipraga --- v1 -> v2: - clarify firmware behaviour in a comment - fix detection of upper bound RSSI transition - improve clamping of min/max RSSI values - remove unnecessary check on last RSSI value --- .../broadcom/brcm80

Re: [PATCH v2] brcmfmac: add support for CQM RSSI notifications

On 1/15/2021 3:57 PM, Alvin Šipraga wrote: Hi Arend, On 1/15/21 3:10 PM, Arend Van Spriel wrote: + Johannes - netdevs On 1/14/2021 5:36 PM, 'Alvin Šipraga' via BRCM80211-DEV-LIST,PDL wrote: Add support for CQM RSSI measurement reporting and advertise the NL80211_EXT_FEATURE_CQM_RSSI_LIST

Re: [PATCH v2] brcmfmac: add support for CQM RSSI notifications

On 1/15/2021 3:51 PM, Andrew Zaborowski wrote: On Fri, 15 Jan 2021 at 15:12, Arend Van Spriel wrote:> + Johannes - netdevs On 1/14/2021 5:36 PM, 'Alvin Šipraga' via BRCM80211-DEV-LIST,PDL wrote: Add support for CQM RSSI measurement reporting and advert

Re: [PATCH v2] brcmfmac: add support for CQM RSSI notifications

+ Johannes - netdevs On 1/14/2021 5:36 PM, 'Alvin Šipraga' via BRCM80211-DEV-LIST,PDL wrote: Add support for CQM RSSI measurement reporting and advertise the NL80211_EXT_FEATURE_CQM_RSSI_LIST feature. This enables a userspace supplicant such as iwd to be notified of changes in the RSSI for

Re: [PATCH] brcmfmac: add support for CQM RSSI notifications

On 12-01-2021 12:13, 'Alvin Šipraga' via BRCM80211-DEV-LIST,PDL wrote: Add support for CQM RSSI measurement reporting and advertise the NL80211_EXT_FEATURE_CQM_RSSI_LIST feature. This enables a userspace supplicant such as iwd to be notified of changes in the RSSI for roaming and signal

Re: [RFC] Status of orinoco_usb

+ 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

Re: [patch V2 27/36] net: brcmfmac: Convey allocation mode as argument

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 ++ drivers

Re: [patch V2 26/36] net: brcmfmac: Convey execution context via argument to brcmf_netif_rx()

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: Kalle Valo

Re: WARNING: CPU: 1

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 'devlink-Use

Re: [patch 24/35] net: brcmfmac: Replace in_interrupt()

, 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: Franky

Re: [patch 24/35] net: brcmfmac: Replace in_interrupt()

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

Re: [patch 26/35] net: brcmfmac: Convey allocation mode as argument

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

Re: WARNING: CPU: 1

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:

Re: [patch 25/35] net: brcmfmac: Use netif_rx_any_context().

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

Re: [patch 24/35] net: brcmfmac: Replace in_interrupt()

+ 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

Re: [PATCH] brcmfmac: initialize variable

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.

Re: [PATCH] brcmsmac: fix memory leak in wlc_phy_attach_lcnphy

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

Re: [PATCH] brcmsmac: fix memory leak in wlc_phy_attach_lcnphy

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

Re: [PATCH] brcmsmac: fix potential memory leak in wlc_phy_attach_lcnphy

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

Re: [PATCH v1] brcmfmac: increase F2 watermark for BCM4329

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 file changed

Re: [PATCH 07/16] wireless: brcm80211: convert tasklets to use new tasklet_setup() API

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

Re: [PATCH] brcmfmac: no need to check return value of debugfs_create functions

as no one was even paying attention to the return value. Cc: Arend van Spriel Cc: Franky Lin Cc: Hante Meuleman Cc: Chi-Hsien Lin Cc: Wright Feng Cc: Kalle Valo Cc: "David S. Miller" Cc: Pieter-Paul Giesberts Cc: Greg Kroah-Hartman Cc: "Rafał Miłecki" Cc: linux-wirel..

Re: [PATCH 00/20] Add support for Silicon Labs WiFi chip WF200 and further

On 9/19/2019 1:25 PM, Greg Kroah-Hartman wrote: - I also kept compatibility code for earlier Linux kernel version. I may drop it in future. Maybe I will maintain compatibility with older kernels in a external set of patches. That has to be dropped for the in-kernel version. There

Re: [PATCH] brcmsmac: remove a useless test

On 9/15/2019 9:32 PM, Christophe JAILLET wrote: 'pih' is known to be non-NULL at this point, so the test can be removed. Acked-by: Arend van Spriel Signed-off-by: Christophe JAILLET --- drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 3 +-- 1 file changed, 1 insertion(+), 2

Re: [PATCH] brcmfmac: replace strncpy() by strscpy()

/brcmfmac/cfg80211.c:4227:2: warning: 'strncpy' output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation] strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1); ^~~~ Acked-by: Arend van Spriel

[BUILD REGRESSION] building single .ko not working in 5.3-rc1

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

Re: [PATCH] brcmfmac: Replace two seq_printf() calls in brcmf_feat_fwcap_debugfs_read()

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

Re: nl80211 wlcore regression in next

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

Re: [PATCH v4 5/5] brcmfmac: sdio: Don't tune while the card is off

es. The term "sleep command" is a bit confusing. There actually is a CMD14 defined in the eSD spec, but that is not what we are using (unless we program the chip to do so) here. It is simply a specific register access using CMD52. Apart from that Reviewed-by: Arend van Spriel Signed-

Re: [PATCH v4 3/5] brcmfmac: sdio: Disable auto-tuning around commands expected to fail

traffic to the card until it's done. Let's disable retuning around the commands we expect might fail. Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors") Reviewed-by: Arend van Spriel Signed-off-by: Douglas Anderson

Re: [PATCH v4 4/5] mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()

On June 14, 2019 6:38:51 PM Doug Anderson wrote: Hi, On Fri, Jun 14, 2019 at 5:10 AM Ulf Hansson wrote: On Fri, 14 Jun 2019 at 01:42, Douglas Anderson wrote: > > We want SDIO drivers to be able to temporarily stop retuning when the > driver knows that the SDIO card is not in a state where

Re: [PATCH v3 3/5] brcmfmac: sdio: Disable auto-tuning around commands expected to fail

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->

Re: [PATCH v3 3/5] brcmfmac: sdio: Disable auto-tuning around commands expected to fail

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

Re: [PATCH v2 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail

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 fact

Re: [PATCH v2 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail

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 re-tune when we

Re: [PATCH v2 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail

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

Re: [PATCH v2 2/3] mmc: core: API for temporarily disabling auto-retuning due to errors

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

Re: [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354

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

Re: Issue with Broadcom wireless in 5.2rc1 (was Re: [PATCH] mmc: sdhci: queue work after sdhci_defer_done())

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

Re: [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354

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

Re: [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354

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

Re: [PATCH 2/3] mmc: core: API for temporarily disabling auto-retuning due to errors

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

Re: Issue with Broadcom wireless in 5.2rc1 (was Re: [PATCH] mmc: sdhci: queue work after sdhci_defer_done())

On 5/26/2019 2:21 PM, Brian Masney wrote: + Broadcom wireless maintainers On Fri, May 24, 2019 at 11:49:58AM -0400, Brian Masney wrote: On Fri, May 24, 2019 at 03:17:13PM +0300, Adrian Hunter wrote: On 24/05/19 2:10 PM, Brian Masney wrote: WiFi stopped working on the LG Nexus 5 phone and the

Re: [PATCH 2/3] mmc: core: API for temporarily disabling auto-retuning due to errors

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 generally a good idea. Probably a question for Adrian, but how is this retuning scheduled. I recall seeing

Re: [PATCH 0/3] brcmfmac: sdio: Deal better w/ transmission errors waking from sleep

On 5/18/2019 12:54 AM, Douglas Anderson wrote: This series attempts to deal better with the expected transmission errors that we get when waking up the SDIO-based WiFi on rk3288-veyron-minnie, rk3288-veyron-speedy, and rk3288-veyron-mickey. Some details about those errors can be found in

Re: [PATCH 2/3] mmc: core: API for temporarily disabling auto-retuning due to errors

On 5/19/2019 11:06 AM, Wolfram Sang wrote: Let's add an API that the SDIO card drivers can call that will temporarily disable the auto-tuning functionality. Then we can add a call to this in the Broadcom WiFi driver and any other driver that might have similar needs. Can't you fix the WiFi

Re: [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354

On 5/18/2019 12:54 AM, 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 Broadcom SDIO WiFi parts. After that patch landed I find that my kernel log on

Re: [PATCH RFC] brcmfmac: sanitize DMI strings v2

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

Re: [PATCH] net: brcm80211: fix potential NULL pointer dereferences

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

Re: Realtek r8822be kernel module does not negotiate 802.11ac connection

Op 2 maart 2019 04:52:46 schreef "David R. Bergstein" : Larry, Sorry about all these extra replies.  Shortly after I sent my last message my access point started recognizing the connection as 802.11ac with PHY Rate / Modulation Rate of 866.6 Mbps.  What is somewhat misleading is the

Re: [PATCH] brcm80211: no need to check return value of debugfs_create functions

is true it would be better to make the debugfs function return void, but I won't ;-p In start_creating() the parent dentry is indeed checked for IS_ERR() so... Acked-by: Arend van Spriel Cc: Arend van Spriel Cc: Franky Lin Cc: Hante Meuleman Cc: Chi-Hsien Lin Cc: Wright Feng Cc: Kalle Valo

Re: [PATCH] wireless: remove unneeded semicolon

On 1/18/2019 4:32 AM, YueHaibing wrote: remove unneeded semicolon Acked-by: Arend van Spriel Signed-off-by: YueHaibing --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-

Re: [PATCH] net: brcm80211: add a check for the status of usb_register

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: "

[tip:efi/core] firmware/efi: Add NULL pointer checks in efivars API functions

Commit-ID: ab2180a15ce54739fed381efb4cb12e78dfb1561 Gitweb: https://git.kernel.org/tip/ab2180a15ce54739fed381efb4cb12e78dfb1561 Author: Arend van Spriel AuthorDate: Thu, 29 Nov 2018 18:12:27 +0100 Committer: Ingo Molnar CommitDate: Fri, 30 Nov 2018 09:06:32 +0100 firmware/efi: Add

[tip:efi/core] firmware/efi: Add NULL pointer checks in efivars API functions

Commit-ID: ab2180a15ce54739fed381efb4cb12e78dfb1561 Gitweb: https://git.kernel.org/tip/ab2180a15ce54739fed381efb4cb12e78dfb1561 Author: Arend van Spriel AuthorDate: Thu, 29 Nov 2018 18:12:27 +0100 Committer: Ingo Molnar CommitDate: Fri, 30 Nov 2018 09:06:32 +0100 firmware/efi: Add

Re: [PATCH] hostap: hide unused procfs helpers

+ Randy On 7/13/2018 9:03 AM, YueHaibing wrote: When CONFIG_PROC_FS isn't set, gcc warning this: drivers/net/wireless/intersil/hostap/hostap_hw.c:2901:12: warning: ‘prism2_registers_proc_show’ defined but not used [-Wunused-function] static int prism2_registers_proc_show(struct seq_file *m,

Re: [PATCH] hostap: hide unused procfs helpers

+ Randy On 7/13/2018 9:03 AM, YueHaibing wrote: When CONFIG_PROC_FS isn't set, gcc warning this: drivers/net/wireless/intersil/hostap/hostap_hw.c:2901:12: warning: ‘prism2_registers_proc_show’ defined but not used [-Wunused-function] static int prism2_registers_proc_show(struct seq_file *m,

Re: [PATCH 10/18] brcmsmac: change strncpy+truncation to strlcpy

On 7/13/2018 3:25 AM, Dominique Martinet wrote: Generated by scripts/coccinelle/misc/strncpy_truncation.cocci Acked-by: Arend van Spriel Signed-off-by: Dominique Martinet --- Please see https://marc.info/?l=linux-kernel=153144450722324=2 (the first patch of the serie) for the motivation

Re: [PATCH 10/18] brcmsmac: change strncpy+truncation to strlcpy

On 7/13/2018 3:25 AM, Dominique Martinet wrote: Generated by scripts/coccinelle/misc/strncpy_truncation.cocci Acked-by: Arend van Spriel Signed-off-by: Dominique Martinet --- Please see https://marc.info/?l=linux-kernel=153144450722324=2 (the first patch of the serie) for the motivation

Re: [PATCH] brcmfmac: stop watchdog before detach and free everything

On 5/28/2018 9:50 AM, Michael Trimarchi wrote: Watchdog need to be stopped in brcmf_sdio_remove to avoid i The system is going down NOW! [ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 02f8 Sent SIGTERM to all processes [ 1348.121412] Mem abort info: [

Re: [PATCH] brcmfmac: stop watchdog before detach and free everything

On 5/28/2018 9:50 AM, Michael Trimarchi wrote: Watchdog need to be stopped in brcmf_sdio_remove to avoid i The system is going down NOW! [ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 02f8 Sent SIGTERM to all processes [ 1348.121412] Mem abort info: [

Re: [PATCH 9/9] brcmfmac: use request_firmware_nowait2 to load firmware without warnings

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

Re: [PATCH 9/9] brcmfmac: use request_firmware_nowait2 to load firmware without warnings

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

Re: [RESEND PATCH] drivers: change struct device_driver::coredump() return type to void

On Sun, Apr 8, 2018 at 11:57 PM, Arend van Spriel <aspr...@gmail.com> 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 t

Re: [RESEND PATCH] drivers: change struct device_driver::coredump() return type to void

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

[RESEND PATCH] drivers: change struct device_driver::coredump() return type to void

changing it to void. [1] https://patchwork.kernel.org/patch/10231933/ Signed-off-by: Arend van Spriel <aspr...@gmail.com> --- Hi Greg, Here is a resend of my patch that got lost. See if it makes it this time ;-) Regards, Arend --- include/linux/device.h | 6 -- 1 file changed, 4 insertions

[RESEND PATCH] drivers: change struct device_driver::coredump() return type to void

changing it to void. [1] https://patchwork.kernel.org/patch/10231933/ Signed-off-by: Arend van Spriel --- Hi Greg, Here is a resend of my patch that got lost. See if it makes it this time ;-) Regards, Arend --- include/linux/device.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

Op vr 6 apr. 2018 4:46 PM schreef Greg Kroah-Hartman <gre...@linuxfoundation.org>: > > On Fri, Apr 06, 2018 at 12:13:38PM +0200, Arend van Spriel wrote: > > On Sat, Mar 24, 2018 at 10:04 AM, Greg Kroah-Hartman > > <gre...@linuxfoundation.org> wrote: > > > O

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

Op vr 6 apr. 2018 4:46 PM schreef Greg Kroah-Hartman : > > On Fri, Apr 06, 2018 at 12:13:38PM +0200, Arend van Spriel wrote: > > On Sat, Mar 24, 2018 at 10:04 AM, Greg Kroah-Hartman > > wrote: > > > On Sat, Mar 24, 2018 at 09:50:05AM +0100, Arend van Spriel wrote: >

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

On Sat, Mar 24, 2018 at 10:04 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Sat, Mar 24, 2018 at 09:50:05AM +0100, Arend van Spriel wrote: >> On Fri, Mar 23, 2018 at 5:55 PM, Greg Kroah-Hartman >> <gre...@linuxfoundation.org> wrote: >> > On T

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

On Sat, Mar 24, 2018 at 10:04 AM, Greg Kroah-Hartman wrote: > On Sat, Mar 24, 2018 at 09:50:05AM +0100, Arend van Spriel wrote: >> On Fri, Mar 23, 2018 at 5:55 PM, Greg Kroah-Hartman >> wrote: >> > On Thu, Mar 15, 2018 at 10:55:24AM +0100, Arend van Spriel wrote: >&

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

On 4/5/2018 3:10 PM, Kalle Valo wrote: Ulf Hansson <ulf.hans...@linaro.org> writes: On 20 March 2018 at 10:55, Kalle Valo <kv...@codeaurora.org> wrote: Arend van Spriel <arend.vanspr...@broadcom.com> writes: If I get it right, you mean something like this:

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

On 4/5/2018 3:10 PM, Kalle Valo wrote: Ulf Hansson writes: On 20 March 2018 at 10:55, Kalle Valo wrote: Arend van Spriel writes: If I get it right, you mean something like this: mmc3: mmc@1c12000 { ... broken-sg-support; sd-head-align = 4; sd-sgentry-align

Re: [PATCH 07/12] brcmfmac: Convert ALLFFMAC to ether_broadcast_addr

-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Joe Perches <j...@perches.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 -- drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h | 2 -- drivers/net/wireless/broadcom/brcm80

Re: [PATCH 07/12] brcmfmac: Convert ALLFFMAC to ether_broadcast_addr

-by: Arend van Spriel Signed-off-by: Joe Perches --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 -- drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h | 2 -- drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c | 8 3 files changed, 4 insertions

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

+ Marcel On Sat, Mar 24, 2018 at 10:04 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Sat, Mar 24, 2018 at 09:50:05AM +0100, Arend van Spriel wrote: >> On Fri, Mar 23, 2018 at 5:55 PM, Greg Kroah-Hartman >> <gre...@linuxfoundation.org> wrote: >>

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

+ Marcel On Sat, Mar 24, 2018 at 10:04 AM, Greg Kroah-Hartman wrote: > On Sat, Mar 24, 2018 at 09:50:05AM +0100, Arend van Spriel wrote: >> On Fri, Mar 23, 2018 at 5:55 PM, Greg Kroah-Hartman >> wrote: >> > On Thu, Mar 15, 2018 at 10:55:24AM +0100, Arend van Spriel wrot

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

On Fri, Mar 23, 2018 at 5:55 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Thu, Mar 15, 2018 at 10:55:24AM +0100, Arend van Spriel wrote: >> Upon submitting a patch for mwifiex [1] it was discussed whether this >> callback function could fail.

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

On Fri, Mar 23, 2018 at 5:55 PM, Greg Kroah-Hartman wrote: > On Thu, Mar 15, 2018 at 10:55:24AM +0100, 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 >>

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

iption and these do not describe the wifi device. They are applicable to the wifi device because it is a limitation of the host controller and as such should be described in the DT binding of the host controller. Regards, Arend Regards, Alex On 20 March 2018 at 06:16, Arend van Spriel <are

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

iption and these do not describe the wifi device. They are applicable to the wifi device because it is a limitation of the host controller and as such should be described in the DT binding of the host controller. Regards, Arend Regards, Alex On 20 March 2018 at 06:16, Arend van Spriel wrote: + Uffe

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

make any difference. Are you using some chromebook. I have some lying around here so I could also look into it. What broadcom chipset do you have? Regards, Arend All the best, Alex. On 19 March 2018 at 16:31, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: On 3/19/2018 2:40

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

make any difference. Are you using some chromebook. I have some lying around here so I could also look into it. What broadcom chipset do you have? Regards, Arend All the best, Alex. On 19 March 2018 at 16:31, Arend van Spriel wrote: On 3/19/2018 2:40 AM, Alexey Roslyakov wrote: In case if

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

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 ---

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

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

Re: [PATCH for-4.16 1/3] sysfs: improve devices-coredump description with user-space perspective

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 <aspr...@gmail.

Re: [PATCH for-4.16 1/3] sysfs: improve devices-coredump description with user-space perspective

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

[PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

changing it to void. [1] https://patchwork.kernel.org/patch/10231933/ Signed-off-by: Arend van Spriel <aspr...@gmail.com> --- 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

[PATCH for-4.16 0/3] drivers: base: revise coredump ABI

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

[PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

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

[PATCH for-4.16 0/3] drivers: base: revise coredump ABI

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

[PATCH for-4.16 1/3] sysfs: improve devices-coredump description with user-space perspective

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 <aspr...@gmail.com> --- Documentation/ABI/testing/sysfs-devices-coredump | 14 +- 1 file changed, 9 insertions

[PATCH for-4.16 1/3] sysfs: improve devices-coredump description with user-space perspective

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

  1   2   3   4   5   6   7   8   9   10   >