Re: RTL8189ETV

Hi, On 31-08-15 22:31, poma wrote: Let's see if Hans knows what type of this device is RTL8189ETV. Assuming you are talking about the wifi module of the Allwinner H3 based Orangepi2 as shown here: http://linux-sunxi.org/images/9/96/Xunlong_OrangePi2_front.jpg Then we are talking about a

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

Hi, On 29-06-16 20:51, 'Arend Van Spriel' via linux-sunxi wrote: On 29-6-2016 20:01, Hans de Goede wrote: Hi, On 29-06-16 19:00, Kalle Valo wrote: Hans de Goede <hdego...@redhat.com> writes: Hi, On 29-06-16 16:42, Jonas Gorski wrote: Hi, On 29 June 2016 at 16:04, Hans de Goede

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

Hi, On 30-06-16 11:02, Kalle Valo wrote: Priit Laes writes: What is the size of this nvram file? As it's board specific, I wonder if we can simply include it inside of the DT verbatim. I remember doing that (in the pre-dtb days, on real open firmware) for the "spidernet"

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

Hi, On 30-06-16 12:18, Jonas Gorski wrote: Hi, On 30 June 2016 at 12:04, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 30-06-16 11:58, Kalle Valo wrote: Hans de Goede <hdego...@redhat.com> writes: Hi, On 30-06-16 11:02, Kalle Valo wrote: Priit Laes <pl...@pl

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

Hi, On 30-06-16 10:46, Kalle Valo wrote: Arend Van Spriel writes: Since we are dealing with a per-board config-file here, which is loaded from the os filesystem we really need to specify a basename here as the list of possible boards is endless, so we cannot

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

Hi, On 30-06-16 11:58, Kalle Valo wrote: Hans de Goede <hdego...@redhat.com> writes: Hi, On 30-06-16 11:02, Kalle Valo wrote: Priit Laes <pl...@plaes.org> writes: What is the size of this nvram file? As it's board specific, I wonder if we can simply include it inside of the DT

Re: [linux-sunxi] Re: [PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name

HI, On 29-06-16 19:01, Kalle Valo wrote: Hans de Goede <hdego...@redhat.com> writes: The cubietruck uses an ap6210 sdio wifi module, set brcm,nvram_file_name to brcmfmac43362-ap6210.txt so that we can ship the ap6210 specific nvram file in linunx-firmware to get the wifi to wo

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

Hi, On 29-06-16 19:00, Kalle Valo wrote: Hans de Goede <hdego...@redhat.com> writes: Hi, On 29-06-16 16:42, Jonas Gorski wrote: Hi, On 29 June 2016 at 16:04, Hans de Goede <hdego...@redhat.com> wrote: Add a brcm,nvram_file_name dt property to allow overruling the default nv

[PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name

a downside of this patch is that users who have already manually installed the nvram file will need to rename it. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/sun7i-a20-cubietru

[PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

of the box, without requiring users to find and then manually install the right nvram file for their board. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++ drivers/net/wireless/broadcom/brcm80211/brcmfma

[PATCH 3/4] ARM: dts: sun7i-a20-wits-pro-a20-dkt: Set brcm,nvram_file_name

to work out of the box without users needing to download and install the nvram file themselves. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.

[PATCH 4/4] ARM: dts: sun5i-a10s-auxtek-t004: Set brcm,nvram_file_name

to ship the ap6210 specific nvram file in linux-firmware to get the wifi to work out of the box without users needing to download and install the nvram file themselves. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts | 6 ++ 1 file chan

Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

Hi, On 29-06-16 16:42, Jonas Gorski wrote: Hi, On 29 June 2016 at 16:04, Hans de Goede <hdego...@redhat.com> wrote: Add a brcm,nvram_file_name dt property to allow overruling the default nvram filename for sdio devices. The idea is that we can specify a board specific nvram fil

[PATCH 0/4] brcmfmac: Remove a bunch of false positive error logs

Hi All, Here is a small series to stop brcmfmac from spamming dmesg with errors which are not really errors at all. Note the 4th patch actually contains a small behavior change rather then just changing logging, so it needs a bit of extra review attention. Regards, Hans

[PATCH 4/4] brcmfmac: Handle status == BRCMF_E_STATUS_ABORT in cfg80211_escan_handler

ORT and in this case simply cleanly exit the cfg80211_escan_handler. This also avoids a BRCMF_E_STATUS_ABORT event arriving after a new scan has been started causing the new scan to complete prematurely without any data. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/net

[PATCH v2 1/4] brcmfmac: Do not print the firmware version as an error

Using pr_err for things which are not errors is a bad idea. E.g. it will cause the plymouth bootsplash screen to drop back to the text console so that the user can see the error, which is not what we normally want to happen. Instead add a new brcmf_info macro and use that. Signed-off-by: Hans de

[PATCH v2 3/4] brcmfmac: Do not complain about country code "00"

The country code gets set to "00" by default at boot, ignore this rather then logging an error about it. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 1 file changed, 4 insertions(+) diff --git a/driv

[PATCH v2 2/4] brcmfmac: p2p and normal ap access are not always possible at the same time

The firmware responding with -EBUSY when trying to add an extra virtual-if is a normal thing, do not print an error for this. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++ drivers/net/wireless/br

[PATCH 1/4] brcmfmac: Do not print the firmware version as an error

Using pr_err for things which are not errors is a bad idea. E.g. it will cause the plymouth bootsplash screen to drop back to the text console so that the user can see the error, which is not what we normally want to happen. Instead add a new brcmf_info macro and use that. Signed-off-by: Hans de

[PATCH 3/4] brcmfmac: Do not complain about country code "00"

The country code gets set to "00" by default at boot, ignore this rather then logging an error about it. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 1 file changed, 4 insertions(+) diff --git a/driv

[PATCH 2/4] brcmfmac: p2p and normal ap access are not always possible at the same time

The firmware responding with -EBUSY when trying to add an extra virtual-if is a normal thing, do not print an error for this. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++ drivers/net/wireless/br

[PATCH] net: wireless: rtl8xxxu: Make rtl8xxxu_ampdu_action less chatty

On my home network rtl8xxxu is spamming the log with IEEE80211_AMPDU_RX_START / IEEE80211_AMPDU_RX_STOP every few seconds turn these messages into debug messages. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 10 +-

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

Hi All, I forgot to add --compose so I could add the cover letter I had already written, so here it goes: Hi Greg, all, I'm hereby submitting the rtl8723bs driver which Bastien Nocera and Larry Finger have been maintaining at: https://github.com/hadess/rtl8723bs For inclusion into staging,

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

Hi, On 04/04/2017 11:38 PM, Arend Van Spriel wrote: On 4-4-2017 20:53, Hans de Goede wrote: Hi, On 04/04/2017 08:31 PM, Larry Finger wrote: On 03/29/2017 12:47 PM, Hans de Goede wrote: The rtl8723bs is found on quite a few systems used by Linux users, such as on Atom systems (Intel

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

Hi, On 04/04/2017 08:31 PM, Larry Finger wrote: On 03/29/2017 12:47 PM, Hans de Goede wrote: The rtl8723bs is found on quite a few systems used by Linux users, such as on Atom systems (Intel Computestick and various other Atom based devices) and on many (budget) ARM boards such as the CHIP

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

Hi, On 05-04-17 01:41, Larry Finger wrote: On 04/04/2017 04:53 PM, Hans de Goede wrote: Hi, On 04/04/2017 11:38 PM, Arend Van Spriel wrote: On 4-4-2017 20:53, Hans de Goede wrote: Hi, On 04/04/2017 08:31 PM, Larry Finger wrote: On 03/29/2017 12:47 PM, Hans de Goede wrote: The rtl8723bs

Re: [PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

Hi, On 09-04-17 10:01, Marcel Holtmann wrote: Hi Hans, The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets for bluetooth rfkill functionality. Tested-by: russianneuroman...@ya.ru <russianneuroman...@ya.ru> Signed-off-by: Hans de Goede <hdego...@redhat.com> --

[PATCH] staging: rtl8723bs: Add missing include to fix compile error

As reported by Stephen Rothwell when merging staging-next, drivers/staging/rtl8723bs/core/rtw_ieee80211.c does not compile due to of_get_property not being declared. Explicitly include to fix this compile error. Cc: Stephen Rothwell <s...@canb.auug.org.au> Signed-off-by: Hans de Goede

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

Hi, On 05-04-17 18:32, Larry Finger wrote: On 04/05/2017 04:36 AM, Hans de Goede wrote: Hi, On 05-04-17 01:41, Larry Finger wrote: On 04/04/2017 04:53 PM, Hans de Goede wrote: Hi, On 04/04/2017 11:38 PM, Arend Van Spriel wrote: On 4-4-2017 20:53, Hans de Goede wrote: Hi, On 04/04/2017

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

Hi, On 06-04-17 11:04, Bastien Nocera wrote: On Thu, 2017-04-06 at 08:55 +0200, Hans de Goede wrote: Good thank you. So what is the plan with the github version ? Note that my submission contains a few small fixes on top of the github version, for which I intended to submit a pull-req

[PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets for bluetooth rfkill functionality. Tested-by: russianneuroman...@ya.ru <russianneuroman...@ya.ru> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- net/rfkill/rfkill-gpio.c | 1 + 1 file changed, 1 insert

[PATCH] staging: rtl8188eu: force driver to be built as a module

The rtl8188eu driver defines a ton of global symbols which tend to conflict with other realtek wifi drivers, force it to be built as a module. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/staging/rtl8188eu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/d

Re: [PATCH v3] brcmfmac: Do not print the firmware version as an error

Hi all, On 08-03-17 21:44, Arend Van Spriel wrote: On 8-3-2017 18:53, Joe Perches wrote: On Wed, 2017-03-08 at 17:57 +0100, Hans de Goede wrote: Hi, And hello back to you. Also hello. On 08-03-17 17:34, Joe Perches wrote: On Wed, 2017-03-08 at 09:23 +0100, Hans de Goede wrote: Using

Re: [PATCH v3] brcmfmac: Do not print the firmware version as an error

Hi, On 09-03-17 09:17, Arend Van Spriel wrote: On 9-3-2017 9:09, Hans de Goede wrote: Hi all, On 08-03-17 21:44, Arend Van Spriel wrote: On 8-3-2017 18:53, Joe Perches wrote: On Wed, 2017-03-08 at 17:57 +0100, Hans de Goede wrote: Hi, And hello back to you. Also hello. On 08-03-17

Re: [PATCH v3] brcmfmac: Do not print the firmware version as an error

Hi, On 08-03-17 17:34, Joe Perches wrote: On Wed, 2017-03-08 at 09:23 +0100, Hans de Goede wrote: Using pr_err for things which are not errors is a bad idea. E.g. it will cause the plymouth bootsplash screen to drop back to the text console so that the user can see the error, which is not what

Re: [PATCH v2 2/4] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, On 08-03-17 11:15, Arend Van Spriel wrote: On 8-3-2017 10:26, Arend Van Spriel wrote: On 8-3-2017 9:24, Hans de Goede wrote: Hi, On 07-03-17 11:03, Arend Van Spriel wrote: On 27-2-2017 22:45, Hans de Goede wrote: The firmware responding with -EBUSY when trying to add an extra virtual

[PATCH v3 2/3] brcmfmac: Do not complain about country code "00"

The country code gets set to "00" by default at boot, ignore this rather then logging an error about it. Signed-off-by: Hans de Goede <hdego...@redhat.com> Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com> --- Changes in v3: -Add Arend's Acked-by --- drivers

[PATCH v3 3/3] brcmfmac: Handle status == BRCMF_E_STATUS_ABORT in cfg80211_escan_handler

ORT and in this case simply cleanly exit the cfg80211_escan_handler. This also avoids a BRCMF_E_STATUS_ABORT event arriving after a new scan has been started causing the new scan to complete prematurely without any data. Signed-off-by: Hans de Goede <hdego...@redhat.com> Acked-by: Arend v

[PATCH v3 1/3] brcmfmac: Do not print the firmware version as an error

Using pr_err for things which are not errors is a bad idea. E.g. it will cause the plymouth bootsplash screen to drop back to the text console so that the user can see the error, which is not what we normally want to happen. Instead add a new brcmf_info macro and use that. Signed-off-by: Hans de

[PATCH v2 4/4] brcmfmac: Handle status == BRCMF_E_STATUS_ABORT in cfg80211_escan_handler

ORT and in this case simply cleanly exit the cfg80211_escan_handler. This also avoids a BRCMF_E_STATUS_ABORT event arriving after a new scan has been started causing the new scan to complete prematurely without any data. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/net

Re: [PATCH v2 1/4] brcmfmac: Do not print the firmware version as an error

Hi, On 07-03-17 10:59, Arend Van Spriel wrote: On 27-2-2017 22:45, Hans de Goede wrote: Using pr_err for things which are not errors is a bad idea. E.g. it will cause the plymouth bootsplash screen to drop back to the text console so that the user can see the error, which is not what we

[PATCH v3] brcmfmac: Do not print the firmware version as an error

Using pr_err for things which are not errors is a bad idea. E.g. it will cause the plymouth bootsplash screen to drop back to the text console so that the user can see the error, which is not what we normally want to happen. Instead add a new brcmf_info macro and use that. Signed-off-by: Hans de

Re: [PATCH v2 2/4] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, On 07-03-17 11:03, Arend Van Spriel wrote: On 27-2-2017 22:45, Hans de Goede wrote: The firmware responding with -EBUSY when trying to add an extra virtual-if is a normal thing, do not print an error for this. This may be something we need to look into. It seems to me the interface

Re: [PATCH v2 1/4] brcmfmac: Do not print the firmware version as an error

HI, On 08-03-17 10:57, Kalle Valo wrote: Arend Van Spriel <arend.vanspr...@broadcom.com> writes: On 8-3-2017 9:23, Hans de Goede wrote: Hi, On 07-03-17 10:59, Arend Van Spriel wrote: On 27-2-2017 22:45, Hans de Goede wrote: Using pr_err for things which are not errors is a bad ide

Re: brcmfmac: don't warn user if requested nvram fails

Hi, On 07-04-17 23:43, Arend Van Spriel wrote: On 6-4-2017 14:14, Hans de Goede wrote: Hi, I noticed your patch-series on the lwn.net kernel page, and I took a peek :) I don't think that this patch: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20170329

Re: brcmfmac: don't warn user if requested nvram fails

Hi, I noticed your patch-series on the lwn.net kernel page, and I took a peek :) I don't think that this patch: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20170329-driver-data-v2-try3=3968dd3031d1ff7e7be4acfb810948c70c2d4490 Is a good idea, specifically

[4.13 REGRESSION] Re: brcm43430 sdio wifi regression with 4.13-rc1

Hi, On 23-07-17 09:08, Hans de Goede wrote: Hi, On 22-07-17 21:53, Arend van Spriel wrote: On 22-07-17 21:19, Ian Molton wrote: On 22/07/17 20:18, Ian Molton wrote: On 22/07/17 19:43, Hans de Goede wrote: Hi, When upgrading my devel environment to 4.13-rc1+ I noticed that the brcm43430

Re: [4.13 REGRESSION] Re: brcm43430 sdio wifi regression with 4.13-rc1

Hi, On 14-08-17 17:46, Kalle Valo wrote: Hans de Goede <hdego...@redhat.com> writes: diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c index d21258d..def120c 100644 --- a/drivers/net/wireless/broadcom/brc

Re: brcmfmac4356-pci device not seeing 2.4Ghz channel 12 and 13

Hi, On 28-06-17 14:35, Arend Van Spriel wrote: Op 28 jun. 2017 12:07 schreef "Hans de Goede" <hdego...@redhat.com <mailto:hdego...@redhat.com>>: > > Hi, > > I noticed today that my GPD Win (x86 clamshell mini laptop) > which uses a brcmfmac43

brcm43430 sdio wifi regression with 4.13-rc1

Hi, When upgrading my devel environment to 4.13-rc1+ I noticed that the brcm43430 sdio wifi on a Chuwi Hi8 plus stopped working: jul 22 14:13:23 localhost.localdomain kernel: brcmfmac: brcmf_sdio_probe: Loading firmware brcm/brcmfmac43430-sdio.bin for chip a9a6 rev 0001 jul 22 14:13:23

brcmfmac4356-pcie 4.13 regression (frequent kernel panics) not fixed by recent 4.13 regression fix

Hi, I've been seeing frequent kernel panics on wifi activity (scp-ing a lot of files) with 4.13 on 2 different systems which both use a brcmfmac4356-pcie wifi chip. This is with this fix: https://www.spinics.net/lists/linux-wireless/msg164178.html already applied. Here is a picture of the

brcmfmac4356-pci device not seeing 2.4Ghz channel 12 and 13

Hi, I noticed today that my GPD Win (x86 clamshell mini laptop) which uses a brcmfmac4356-pci wifi does not see an APs which is using channel 13. I've tried updating brcmfmac4356-pci.txt changing "ccode=US" to "ccode=EU" and then rebooted, but that does not help. I believe that the Linux wifi

Re: New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

Hi, On 14-05-17 10:21, Arend Van Spriel wrote: On 13-5-2017 16:55, Hans de Goede wrote: Hi, On 13-05-17 15:39, Heiner Kallweit wrote: Am 13.05.2017 um 14:35 schrieb Hans de Goede: Hi, On 13-05-17 14:19, Hans de Goede wrote: Hi, I've just rebased my personal kernel tree to what

Re: New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

Hi, On 13-05-17 14:19, Hans de Goede wrote: Hi, I've just rebased my personal kernel tree to what will soon be 4.12-rc1 and I'm getting my dmesg log filled with the following errors: [ 32.528271] brcmfmac: brcmf_sdio_rxglom: sublen 524 not multiple of 8 [ 32.528296] brcmfmac

New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

Hi, I've just rebased my personal kernel tree to what will soon be 4.12-rc1 and I'm getting my dmesg log filled with the following errors: [ 32.528271] brcmfmac: brcmf_sdio_rxglom: sublen 524 not multiple of 8 [ 32.528296] brcmfmac: brcmf_sdio_rxglom: sublen 84 not multiple of 8 [

Re: New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

Hi, On 13-05-17 14:19, Hans de Goede wrote: Hi, I've just rebased my personal kernel tree to what will soon be 4.12-rc1 and I'm getting my dmesg log filled with the following errors: [ 32.528271] brcmfmac: brcmf_sdio_rxglom: sublen 524 not multiple of 8 [ 32.528296] brcmfmac

Re: New brcmfmac errors in 4.12: brcmf_sdio_rxglom: sublen ... not multiple of 8

Hi, On 13-05-17 15:39, Heiner Kallweit wrote: Am 13.05.2017 um 14:35 schrieb Hans de Goede: Hi, On 13-05-17 14:19, Hans de Goede wrote: Hi, I've just rebased my personal kernel tree to what will soon be 4.12-rc1 and I'm getting my dmesg log filled with the following errors: [ 32.528271

[PATCH 4.12 REGRESSION fix] brcmfmac: Use ALIGNMENT rather then hardcoded "4" for bus:txglomalign

rxglom: sublen 1492 not multiple of 8 Fixes: 6e84ab604bde ("properly align buffers ... with 64 bit DMA") Suggested-by: Arend van Spriel <arend.vanspr...@broadcom.com> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio

[PATCH resend 0/1] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, This is a resend of a patch which I send a while ago, back then there was some discussion to come up with a better fix, but that has not lead to anything and the driver is still periodically spamming the logs. As such I would like to move forward with this patch for now, which makes no

[PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

The firmware responding with -EBUSY when trying to add an extra virtual-if is a normal thing, do not print an error for this. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++ drivers/net/wireless/br

Re: [PATCH 4.12 REGRESSION fix] brcmfmac: Use ALIGNMENT rather then hardcoded "4" for bus:txglomalign

Hi, On 26-05-17 13:15, Kalle Valo wrote: Hans de Goede <hdego...@redhat.com> writes: From: Arend Van Spriel <arend.vanspr...@broadcom.com> Ah I see I set the Author to Arend when I added this to my tree a while back, that is fine as he did all the work for this one.

[PATCH 1/2] brcmfmac: Log chip id and revision

For debugging some problems, it is useful to know the chip revision add a brcmf_info message logging this. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wi

[PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

chips is not changed, ideally those would load brcmfmac43430a1-sdio.bin, but that will break existing setups. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff

Re: brcmfmac: don't warn user if requested nvram fails

Hi, On 27-04-17 02:36, Luis R. Rodriguez wrote: On Tue, Apr 11, 2017 at 10:53:57AM +0200, Hans de Goede wrote: Right, sorry. For the pcie device I'm looking at the name is brcmfmac4356-pcie.txt and I would like to propose to first check for "brcmfmac4356--.txt" So who is going

Re: [PATCH v2] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

to me: Reviewed-by: Hans de Goede <hdego...@redhat.com> Regards, Hans --- drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c index f17f4fb..2e

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, On 30-08-17 12:24, Hans de Goede wrote: Hi Arend, Sorry I was a bit slow to respond to this. On 04-08-17 14:35, Arend van Spriel wrote: On 5/26/2017 12:57 PM, Hans de Goede wrote: The firmware responding with -EBUSY when trying to add an extra virtual-if is a normal thing, do not print

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi Arend, Sorry I was a bit slow to respond to this. On 04-08-17 14:35, Arend van Spriel wrote: On 5/26/2017 12:57 PM, Hans de Goede wrote: The firmware responding with -EBUSY when trying to add an extra virtual-if is a normal thing, do not print an error for this. Hi Hans, First of all

Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

Hi, On 25-08-17 15:55, Jörg Krause wrote: Hi, On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote: The brcm43430 chip needs different firmware files for chip revision 0 and 1. The file currently in linux-firmware is for revision 1 only. This commit makes brcmfmac request brcmfmac43430a0

Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

Hi, On 25-08-17 16:49, Jörg Krause wrote: Thanks for the files! I've tested with brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020 and brcmfmac is happy: brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul 1 2016 18:02:40 version 7.10.1 (A0 Station/P2P feature) FWID 01-bae8afee

Re: brcmfmac4356-pci device not seeing 2.4Ghz channel 12 and 13

Hi, On 06-07-17 21:43, Arend van Spriel wrote: On 06-07-17 21:23, Hans de Goede wrote: Hi, On 28-06-17 14:35, Arend Van Spriel wrote: Op 28 jun. 2017 12:07 schreef "Hans de Goede" <hdego...@redhat.com <mailto:hdego...@redhat.com>>: > > Hi, > > I

[PATCH v2] brcmfmac: Log chip id and revision

For debugging some problems, it is useful to know the chip revision add a brcmf_info message logging this. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -Put the brcmf_info in brcmf_fw_map_chip_to_name() so that it works for e.g. pcie devices too --- drivers/net/wi

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, On 30-08-17 12:30, Hans de Goede wrote: Hi, On 30-08-17 12:24, Hans de Goede wrote: Hi Arend, Sorry I was a bit slow to respond to this. On 04-08-17 14:35, Arend van Spriel wrote: On 5/26/2017 12:57 PM, Hans de Goede wrote: The firmware responding with -EBUSY when trying to add

[PATCH 1/3] staging: rtl8188eu: Revert part of "staging: rtl8188eu: fix comments with lines over 80 characters"

int and can have values such as -2 and -3. Note for the next time, please only make one type of changes in a single clean-up commit. Fixes: 74e1e498e84e ("staging: rtl8188eu: fix comments with lines over 80 ...") Cc: Juliana Rodrigues <juliana.o...@gmail.com> Signed-off-by: Ha

[PATCH 2/3] staging: rtl8188eu: Fix bug introduced by convert timers to use timer_setup()

Cc: Kees Cook <keesc...@chromium.org> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c b/drivers/staging/rtl8188eu/core/r

[PATCH 3/3] staging: r8188eu: Revert 4 commits breaking ARP

rypt() and also place it after rtl88eu_mon_recv_hook()") This is the commit actually breaking ARP. Note this commit is a straight-forward squash of the revert of these 4 commits, without any changes. Cc: sta...@vger.kernel.org Cc: Ivan Safonov <insafo...@gmail.com> Signed-off-by: H

Re: [PATCH V3 0/5] Update brcm firmware files

Hi, On 15-05-18 10:43, Arend van Spriel wrote: On 5/14/2018 2:05 PM, Josh Boyer wrote: n Mon, May 14, 2018 at 6:11 AM Arend van Spriel < arend.vanspr...@broadcom.com> wrote: On 3/16/2018 3:08 PM, Chi-Hsien Lin wrote: Update brcm firmware files and WHENCE accordingly. Hi

Re: [PATCH V3 0/5] Update brcm firmware files

Hi, On 18-05-18 11:00, Arend van Spriel wrote: On 5/18/2018 9:04 AM, Hans de Goede wrote: Hi, On 15-05-18 10:43, Arend van Spriel wrote: On 5/14/2018 2:05 PM, Josh Boyer wrote: n Mon, May 14, 2018 at 6:11 AM Arend van Spriel < arend.vanspr...@broadcom.com> wrote: On 3/16/2018 3:08 P

Re: [PATCH V3 0/5] Update brcm firmware files

Hi, On 30-05-18 09:28, Chi-Hsien Lin wrote: On 05/27/2018 10:37, Hans de Goede wrote: Hi, On 18-05-18 09:04, Hans de Goede wrote: Hi, On 15-05-18 10:43, Arend van Spriel wrote: On 5/14/2018 2:05 PM, Josh Boyer wrote: n Mon, May 14, 2018 at 6:11 AM Arend van Spriel < arend.van

Re: [PATCH V3 0/5] Update brcm firmware files

Hi, On 18-05-18 09:04, Hans de Goede wrote: Hi, On 15-05-18 10:43, Arend van Spriel wrote: On 5/14/2018 2:05 PM, Josh Boyer wrote: n Mon, May 14, 2018 at 6:11 AM Arend van Spriel < arend.vanspr...@broadcom.com> wrote: On 3/16/2018 3:08 PM, Chi-Hsien Lin wrote: Update brcm firmware

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

Hi, On 02/20/2018 03:36 PM, Carlo Caione wrote: On Tue, Feb 20, 2018 at 2:01 PM, Hans de Goede <hdego...@redhat.com> wrote: Hi Carlo, Hi Hans, Is this for devices with a RTL8723BS chip? If so then they still will not work after this since there also no longer is a /dev/ttyS4 c

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

Hi Carlo, Is this for devices with a RTL8723BS chip? If so then they still will not work after this since there also no longer is a /dev/ttyS4 created for the UART for the bluetooth, instead you probably want:

[PATCH 4.17 REGRESSION fix 0/1] Revert "staging:r8188eu: Use lib80211 to support TKIP"

Hi Greg, While running some ASOC tests on a VIOS LTH17 laptop I noticed that wifi was broken and often the machine would hard freeze shortly after bringing up the wifi connection. One of the oopses pointed to the commit which this patch reverts and that fixes both the wifi being broken and the

[PATCH 4.17 REGRESSION fix] Revert "staging:r8188eu: Use lib80211 to support TKIP"

o all lead to scenario 2. Until I reverted the commit again. Revert the commit fixes both issues making the laptop usable again. Cc: sta...@vger.kernel.org Cc: Ivan Safonov Signed-off-by: Hans de Goede --- drivers/staging/rtl8188eu/Kconfig | 1 - drivers/staging/rtl8188eu/core/

[PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

h is the correct way to specify the worldwide broadcast regime. This has been tested on the following models: Asus T100CHI, Asus T100HA, Asus T100TA and Asus T200TA Tested-by: Hans de Goede <hdego...@redhat.com> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- .../broadcom/brcm80211/

Re: [PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

Hi, On 12-03-18 09:55, Arend van Spriel wrote: On 3/11/2018 10:47 PM, Hans de Goede wrote: Various models Asus laptops with a SDIO attached brcmfmac wifi chip, store the nvram contents in a special EFI variable. This commit adds support for getting nvram directly from this EFI variable

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

HI, On 28-02-18 20:43, Arend van Spriel wrote: On 2/28/2018 3:52 PM, Hans de Goede wrote: Hi, On 27-02-18 00:04, Arend van Spriel wrote: On 2/26/2018 12:22 PM, Hans de Goede wrote: Hi, On 26-02-18 12:01, Arend van Spriel wrote: On 2/26/2018 11:29 AM, Hans de Goede wrote: Hi, On 26-02-18

Re: [PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

Hi, On 13-03-18 21:19, Arend van Spriel wrote: On 3/12/2018 10:45 AM, Hans de Goede wrote: Actually had a Sony device with nvram in EFI. Why not just drop this optimization. Ok, do you know if that variable had the same name and guid though ? Because if it doesn't then this code

Re: [PATCH 1/2] NFC: pn533: Use kmalloc-ed memory for USB transfer buffers

Samuel, Can I get an ack for these please? Anything I need to do to get these picked up / merged? Regards, Hans On 19-03-18 17:40, Hans de Goede wrote: Commit 8b55d7581fc5 ("NFC: pn533: use constant off-stack buffer for sending acks"), fixed the ack case of using on

Re: [PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

Hi, On 16-03-18 21:41, Arend van Spriel wrote: On 3/14/2018 9:43 AM, Hans de Goede wrote: Hi, On 13-03-18 21:19, Arend van Spriel wrote: On 3/12/2018 10:45 AM, Hans de Goede wrote: Actually had a Sony device with nvram in EFI. Why not just drop this optimization. Ok, do you know

[PATCH v2] brcmfmac: Add support for getting nvram contents from EFI variables

is never correct) or ccode=XV we fix it up to the right value (XV or X2) for the firmware, assuming the firmware from linux-firmware is used. This has been tested on the following models: Asus T100CHI, Asus T100HA, Asus T100TA and Asus T200TA Tested-by: Hans de Goede <hdego...@redhat.com>

[PATCH 1/2] NFC: pn533: Use kmalloc-ed memory for USB transfer buffers

hat.com/show_bug.cgi?id=1514134 Fixes: 8b55d7581fc5 ("NFC: pn533: use constant off-stack buffer ...") Cc: Michał Mirosław <mirq-li...@rere.qmqm.pl> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/nfc/pn533/usb.c | 22 +++--- 1 file changed, 15

[PATCH 2/2] NFC: pn533: Fix wrong GFP flag usage

=1514134 Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from ...") Cc: Michael Thalmeier <michael.thalme...@hale.at> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/nfc/pn533/usb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --g

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, On 01-03-18 20:54, Arend van Spriel wrote: On 3/1/2018 9:35 AM, Hans de Goede wrote: HI, On 28-02-18 20:43, Arend van Spriel wrote: On 2/28/2018 3:52 PM, Hans de Goede wrote: Hi, On 27-02-18 00:04, Arend van Spriel wrote: On 2/26/2018 12:22 PM, Hans de Goede wrote: Hi, On 26-02-18

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, On 26-02-18 12:01, Arend van Spriel wrote: On 2/26/2018 11:29 AM, Hans de Goede wrote: Hi, On 26-02-18 11:22, Arend van Spriel wrote: On 2/25/2018 3:52 PM, Hans de Goede wrote: Hi, On 26-05-17 12:57, Hans de Goede wrote: The firmware responding with -EBUSY when trying to add an extra

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, On 26-02-18 11:22, Arend van Spriel wrote: On 2/25/2018 3:52 PM, Hans de Goede wrote: Hi, On 26-05-17 12:57, Hans de Goede wrote: The firmware responding with -EBUSY when trying to add an extra virtual-if is a normal thing, do not print an error for this. Signed-off-by: Hans de Goede

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, On 26-05-17 12:57, Hans de Goede wrote: The firmware responding with -EBUSY when trying to add an extra virtual-if is a normal thing, do not print an error for this. Signed-off-by: Hans de Goede <hdego...@redhat.com> I'm now seeing this on another device too, but this time the

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

Hi, On 27-02-18 00:04, Arend van Spriel wrote: On 2/26/2018 12:22 PM, Hans de Goede wrote: Hi, On 26-02-18 12:01, Arend van Spriel wrote: On 2/26/2018 11:29 AM, Hans de Goede wrote: Hi, On 26-02-18 11:22, Arend van Spriel wrote: On 2/25/2018 3:52 PM, Hans de Goede wrote: Hi, On 26-05-17

Re: [PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

Hi, On 10-10-18 10:15, Arend van Spriel wrote: On 10/10/2018 9:59 AM, Hans de Goede wrote: Any chance you could do a patch-review of this series? Yup and test for regressions with some of the chipsets I have here. Have you gotten around to review and testing this series yet? it would

Re: [PATCH 3/6] brcmfmac: Add support for first trying to get a board specific nvram file

Hi, Thank you for the reviews. On 05-11-18 12:41, Arend van Spriel wrote: On 10/9/2018 2:47 PM, Hans de Goede wrote: The nvram files which some brcmfmac chips need are board-specific. To be able to distribute these as part of linux-firmware, so that devices with such a wifi chip will work

Re: [PATCH 6/6] brcmfmac: Cleanup brcmf_fw_request_done()

Hi, On 05-11-18 12:42, Arend van Spriel wrote: On 10/9/2018 2:47 PM, Hans de Goede wrote: The "cur" variable is now only used for a debug print and we already print the same info from brcmf_fw_complete_request(), so the debug print does not provide any extra info and we can remo

  1   2   >