Add several debug mechanism on PCIE operation.
Wright Feng (3):
brcmfmac: add a timer to read console periodically in PCIE bus
brcmfmac: return error when getting invalid max_flowrings from dongle
brcmfmac: dump dongle memory when attaching failed
.../broadcom/brcm80211/brcmfmac/bus.h | 6 +
.../broadcom/brcm80211/brcmfmac/core.c | 3 +-
.../broadcom/brcm80211/brcmfmac/pcie.c | 139 +++++++++++++++++-
.../broadcom/brcm80211/brcmfmac/sdio.c | 2 -
4 files changed, 144 insertions(+), 6 deletions(-)
--
2.25.0
From: Wright Feng <[email protected]>
Currently, host only reads console buffer when receiving mailbox data or
hit crash with PCIE bus. Therefore, we add timer in PCIE code to read
console buffer periodically to help developer and user check firmware
message when there is no data transmission between host and dongle.
Signed-off-by: Wright Feng <[email protected]>
Signed-off-by: Chi-hsien Lin <[email protected]>
Signed-off-by: Ian Lin <[email protected]>
---
.../broadcom/brcm80211/brcmfmac/bus.h | 6 +
.../broadcom/brcm80211/brcmfmac/pcie.c | 125 ++++++++++++++++++
.../broadcom/brcm80211/brcmfmac/sdio.c | 2 -
3 files changed, 131 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
index 2208ab3aa795..60f5645aead3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
@@ -24,6 +24,12 @@
#define BRCMF_NROF_COMMON_MSGRINGS (BRCMF_NROF_H2D_COMMON_MSGRINGS + \
BRCMF_NROF_D2H_COMMON_MSGRINGS)
+/* The interval to poll console */
+#define BRCMF_CONSOLE 10
+
+/* The maximum console interval value (5 mins) */
+#define MAX_CONSOLE_INTERVAL (5 * 60)
+
/* The level of bus communication with the dongle */
enum brcmf_bus_state {
BRCMF_BUS_DOWN, /* Not ready for frame transfers */
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 80083f9ea311..2b7ebbd7b5b4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -12,6 +12,8 @@
#include <linux/interrupt.h>
#include <linux/bcma/bcma.h>
#include <linux/sched.h>
+#include <linux/sched/signal.h>
+#include <linux/kthread.h>
#include <linux/io.h>
#include <asm/unaligned.h>
@@ -340,6 +342,11 @@ struct brcmf_pciedev_info {
u16 value);
struct brcmf_mp_device *settings;
struct brcmf_otp_params otp;
+#ifdef DEBUG
+ u32 console_interval;
+ bool console_active;
+ struct timer_list timer;
+#endif
};
struct brcmf_pcie_ringbuf {
@@ -440,6 +447,9 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
struct brcmf_fw_request *fwreq);
static struct brcmf_fw_request *
brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo);
+static void
+brcmf_pcie_fwcon_timer(struct brcmf_pciedev_info *devinfo, bool active);
+static void brcmf_pcie_debugfs_create(struct device *dev);
static u16
brcmf_pcie_read_reg16(struct brcmf_pciedev_info *devinfo, u32 reg_offset)
@@ -1413,6 +1423,11 @@ static int brcmf_pcie_init_scratchbuffers(struct brcmf_pciedev_info *devinfo)
static void brcmf_pcie_down(struct device *dev)
{
+ struct brcmf_bus *bus_if = dev_get_drvdata(dev);
+ struct brcmf_pciedev *pcie_bus_dev = bus_if->bus_priv.pcie;
+ struct brcmf_pciedev_info *devinfo = pcie_bus_dev->devinfo;
+
+ brcmf_pcie_fwcon_timer(devinfo, false);
}
static int brcmf_pcie_preinit(struct device *dev)
@@ -1547,6 +1562,7 @@ static const struct brcmf_bus_ops brcmf_pcie_bus_ops = {
.get_memdump = brcmf_pcie_get_memdump,
.get_blob = brcmf_pcie_get_blob,
.reset = brcmf_pcie_reset,
+ .debugfs_create = brcmf_pcie_debugfs_create,
};
@@ -2123,6 +2139,8 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
brcmf_pcie_bus_console_read(devinfo, false);
+ brcmf_pcie_fwcon_timer(devinfo, true);
+
return;
fail:
@@ -2197,6 +2215,105 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo)
return fwreq;
}
+#ifdef DEBUG
+static void
+brcmf_pcie_fwcon_timer(struct brcmf_pciedev_info *devinfo, bool active)
+{
+ if (!active) {
+ if (devinfo->console_active) {
+ del_timer_sync(&devinfo->timer);
+ devinfo->console_active = false;
+ }
+ return;
+ }
+
+ /* don't start the timer */
+ if (devinfo->state != BRCMFMAC_PCIE_STATE_UP ||
+ !devinfo->console_interval || !BRCMF_FWCON_ON())
+ return;
+
+ if (!devinfo->console_active) {
+ devinfo->timer.expires = jiffies + devinfo->console_interval;
+ add_timer(&devinfo->timer);
+ devinfo->console_active = true;
+ } else {
+ /* Reschedule the timer */
+ mod_timer(&devinfo->timer, jiffies + devinfo->console_interval);
+ }
+}
+
+static void
+brcmf_pcie_fwcon(struct timer_list *t)
+{
+ struct brcmf_pciedev_info *devinfo = from_timer(devinfo, t, timer);
+
+ if (!devinfo->console_active)
+ return;
+
+ brcmf_pcie_bus_console_read(devinfo, false);
+
+ /* Reschedule the timer if console interval is not zero */
+ mod_timer(&devinfo->timer, jiffies + devinfo->console_interval);
+}
+
+static int brcmf_pcie_console_interval_get(void *data, u64 *val)
+{
+ struct brcmf_pciedev_info *devinfo = data;
+
+ *val = devinfo->console_interval;
+
+ return 0;
+}
+
+static int brcmf_pcie_console_interval_set(void *data, u64 val)
+{
+ struct brcmf_pciedev_info *devinfo = data;
+
+ if (val > MAX_CONSOLE_INTERVAL)
+ return -EINVAL;
+
+ devinfo->console_interval = val;
+
+ if (!val && devinfo->console_active)
+ brcmf_pcie_fwcon_timer(devinfo, false);
+ else if (val)
+ brcmf_pcie_fwcon_timer(devinfo, true);
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(brcmf_pcie_console_interval_fops,
+ brcmf_pcie_console_interval_get,
+ brcmf_pcie_console_interval_set,
+ "%llu\n");
+
+static void brcmf_pcie_debugfs_create(struct device *dev)
+{
+ struct brcmf_bus *bus_if = dev_get_drvdata(dev);
+ struct brcmf_pub *drvr = bus_if->drvr;
+ struct brcmf_pciedev *pcie_bus_dev = bus_if->bus_priv.pcie;
+ struct brcmf_pciedev_info *devinfo = pcie_bus_dev->devinfo;
+ struct dentry *dentry = brcmf_debugfs_get_devdir(drvr);
+
+ if (IS_ERR_OR_NULL(dentry))
+ return;
+
+ devinfo->console_interval = BRCMF_CONSOLE;
+
+ debugfs_create_file("console_interval", 0644, dentry, devinfo,
+ &brcmf_pcie_console_interval_fops);
+}
+
+#else
+void brcmf_pcie_fwcon_timer(struct brcmf_pciedev_info *devinfo, bool active)
+{
+}
+
+static void brcmf_pcie_debugfs_create(struct device *dev)
+{
+}
+#endif
+
static int
brcmf_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
@@ -2278,6 +2395,11 @@ brcmf_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto fail_brcmf;
}
+#ifdef DEBUG
+ /* Set up the fwcon timer */
+ timer_setup(&devinfo->timer, brcmf_pcie_fwcon, 0);
+#endif
+
fwreq = brcmf_pcie_prepare_fw_request(devinfo);
if (!fwreq) {
ret = -ENOMEM;
@@ -2323,6 +2445,7 @@ brcmf_pcie_remove(struct pci_dev *pdev)
devinfo = bus->bus_priv.pcie->devinfo;
brcmf_pcie_bus_console_read(devinfo, false);
+ brcmf_pcie_fwcon_timer(devinfo, false);
devinfo->state = BRCMFMAC_PCIE_STATE_DOWN;
if (devinfo->ci)
@@ -2366,6 +2489,7 @@ static int brcmf_pcie_pm_enter_D3(struct device *dev)
bus = dev_get_drvdata(dev);
devinfo = bus->bus_priv.pcie->devinfo;
+ brcmf_pcie_fwcon_timer(devinfo, false);
brcmf_bus_change_state(bus, BRCMF_BUS_DOWN);
devinfo->mbdata_completed = false;
@@ -2409,6 +2533,7 @@ static int brcmf_pcie_pm_leave_D3(struct device *dev)
brcmf_bus_change_state(bus, BRCMF_BUS_UP);
brcmf_pcie_intr_enable(devinfo);
brcmf_pcie_hostready(devinfo);
+ brcmf_pcie_fwcon_timer(devinfo, true);
return 0;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 465d95d83759..deb0199fcf8c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -135,8 +135,6 @@ struct rte_console {
#define BRCMF_FIRSTREAD (1 << 6)
-#define BRCMF_CONSOLE 10 /* watchdog interval to poll console */
-
/* SBSDIO_DEVICE_CTL */
/* 1: device will assert busy signal when receiving CMD53 */
--
2.25.0
From: Wright Feng <[email protected]>
To enhance FW debugging, we add dongle memory dump when hitting attaching
failure with PCIE bus. It can help developer to get more information
about dongle trap reason and root cause.
Signed-off-by: Wright Feng <[email protected]>
Signed-off-by: Chi-hsien Lin <[email protected]>
Signed-off-by: Ian Lin <[email protected]>
---
.../net/wireless/broadcom/brcm80211/brcmfmac/core.c | 3 ++-
.../net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 10 +++++++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 595ae3ae561e..d354f79fd0ac 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -1399,7 +1399,8 @@ void brcmf_fw_crashed(struct device *dev)
brcmf_dev_coredump(dev);
- schedule_work(&drvr->bus_reset);
+ if (drvr->bus_reset.func)
+ schedule_work(&drvr->bus_reset);
}
void brcmf_detach(struct device *dev)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 1becd50038ab..cf564adc612a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -2068,13 +2068,14 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
struct brcmf_commonring **flowrings;
u32 i, nvram_len;
+ bus = dev_get_drvdata(dev);
+ pcie_bus_dev = bus->bus_priv.pcie;
+ devinfo = pcie_bus_dev->devinfo;
+
/* check firmware loading result */
if (ret)
goto fail;
- bus = dev_get_drvdata(dev);
- pcie_bus_dev = bus->bus_priv.pcie;
- devinfo = pcie_bus_dev->devinfo;
brcmf_pcie_attach(devinfo);
fw = fwreq->items[BRCMF_PCIE_FW_CODE].binary;
@@ -2148,6 +2149,9 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
return;
fail:
+ brcmf_err(bus, "Dongle setup failed\n");
+ brcmf_pcie_bus_console_read(devinfo, true);
+ brcmf_fw_crashed(dev);
device_release_driver(dev);
}
--
2.25.0
From: Wright Feng <[email protected]>
When firmware hit trap at initialization, host will read abnormal
max_flowrings number from dongle, and it will cause kernel panic when
doing iowrite to initialize dongle ring.
To detect this error at early stage, we directly return error when getting
invalid max_flowrings(>256).
Signed-off-by: Wright Feng <[email protected]>
Signed-off-by: Chi-hsien Lin <[email protected]>
Signed-off-by: Ian Lin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 2b7ebbd7b5b4..1becd50038ab 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1228,6 +1228,10 @@ static int brcmf_pcie_init_ringbuffers(struct brcmf_pciedev_info *devinfo)
BRCMF_NROF_H2D_COMMON_MSGRINGS;
max_completionrings = BRCMF_NROF_D2H_COMMON_MSGRINGS;
}
+ if (max_flowrings > 256) {
+ brcmf_err(bus, "invalid max_flowrings(%d)\n", max_flowrings);
+ return -EIO;
+ }
if (devinfo->dma_idx_sz != 0) {
bufsz = (max_submissionrings + max_completionrings) *
--
2.25.0
Ian Lin <[email protected]> writes:
> From: Wright Feng <[email protected]>
>
> Currently, host only reads console buffer when receiving mailbox data or
> hit crash with PCIE bus. Therefore, we add timer in PCIE code to read
> console buffer periodically to help developer and user check firmware
> message when there is no data transmission between host and dongle.
>
> Signed-off-by: Wright Feng <[email protected]>
> Signed-off-by: Chi-hsien Lin <[email protected]>
> Signed-off-by: Ian Lin <[email protected]>
[...]
> @@ -340,6 +342,11 @@ struct brcmf_pciedev_info {
> u16 value);
> struct brcmf_mp_device *settings;
> struct brcmf_otp_params otp;
> +#ifdef DEBUG
> + u32 console_interval;
> + bool console_active;
> + struct timer_list timer;
> +#endif
> };
I was wondering where that DEBUG is defined and found that it's done in
the Makefile:
subdir-ccflags-$(CONFIG_BRCMDBG) += -DDEBUG
I think that DEBUG define should be removed and instead CONFIG_BRCMDBG
should be used all over the brcmfmac and brcmsmac code. A cleanup patch
doing this is very welcome.
This would be a good task for someone new to kernel development, is
there a way to report these kind of simple tasks?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Ian Lin <[email protected]> wrote:
> From: Wright Feng <[email protected]>
>
> Currently, host only reads console buffer when receiving mailbox data or
> hit crash with PCIE bus. Therefore, we add timer in PCIE code to read
> console buffer periodically to help developer and user check firmware
> message when there is no data transmission between host and dongle.
>
> Signed-off-by: Wright Feng <[email protected]>
> Signed-off-by: Chi-hsien Lin <[email protected]>
> Signed-off-by: Ian Lin <[email protected]>
3 patches applied to wireless-next.git, thanks.
dcb485dfc83b brcmfmac: add a timer to read console periodically in PCIE bus
2aca4f3734bd brcmfmac: return error when getting invalid max_flowrings from dongle
5671c8b56c32 brcmfmac: dump dongle memory when attaching failed
--
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 9/29/2022 5:09 AM, Ian Lin wrote:
> From: Wright Feng <[email protected]>
>
> Currently, host only reads console buffer when receiving mailbox data or
> hit crash with PCIE bus. Therefore, we add timer in PCIE code to read
> console buffer periodically to help developer and user check firmware
> message when there is no data transmission between host and dongle.
These patches are already applied, but wanted to respond still. I know
the proprietary driver does use a timer, but it was a design decision to
drop that. It adds overhead and complexity which is not resulting in
more information about the firmware. Maybe I am missing the exact
scenarios in which this would be useful. Also description above says it
would help the user, but I very much doubt that. Not much users are
fiddling with debugfs and if they are we can call them developers ;-)
Regards,
Arend
On 9/29/2022 5:10 AM, Ian Lin wrote:
> From: Wright Feng <[email protected]>
>
> When firmware hit trap at initialization, host will read abnormal
> max_flowrings number from dongle, and it will cause kernel panic when
> doing iowrite to initialize dongle ring.
> To detect this error at early stage, we directly return error when getting
> invalid max_flowrings(>256).
>
> Signed-off-by: Wright Feng <[email protected]>
> Signed-off-by: Chi-hsien Lin <[email protected]>
> Signed-off-by: Ian Lin <[email protected]>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 2b7ebbd7b5b4..1becd50038ab 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -1228,6 +1228,10 @@ static int brcmf_pcie_init_ringbuffers(struct brcmf_pciedev_info *devinfo)
> BRCMF_NROF_H2D_COMMON_MSGRINGS;
> max_completionrings = BRCMF_NROF_D2H_COMMON_MSGRINGS;
> }
> + if (max_flowrings > 256) {
This limit is a bit of a magic value. I do know there are chipsets that
support more that 256 flowrings so this is a hard limitation. I should
really get the multi-vendor support in place so we can have the
limitation only for Infineon/Cypress chips. I will try to revive that
thread.
Regards,
Arend
Hi! This patch:
https://lore.kernel.org/all/[email protected]/
causes my Asus PCE-AC88 (1043:86fb) to stop working, because when modprobe
loads brcmfmac it throws this error:
---
[ 2740.647600] brcmfmac 0000:0d:00.0: brcmf_pcie_init_ringbuffers: invalid
max_flowrings(264).
---
This is also being reported on reddit:
https://www.reddit.com/r/archlinux/comments/104pqv9/
no_wifi_since_kernel_update_yesterday/
(also, see https://forum.manjaro.org/t/brcmfmac-fails-to-load/131128)
I think that the check on value > 256 is used as a kind of red herring to
indirectly spot an inconsistent properties report from the PCI bus (?) about
the network card.
Before that patch, the driver was correctly working for me and I could not
observe any kernel panic. Maybe, at least in my case, the wrong value was
still reported but could be safely ignored, as at a later point in time, when
the card is initialised, everything worked fine.
I am now stuck at kernel 6.1.1, if I upgrade I cannot use the card.
Is there anything I can do to circumvent this issue? May I help somehow with
debugging & testing? Please let me know...
Thanks,
(c)
On 1/8/2023 9:53 PM, chainofflowers wrote:
> Hi! This patch:
> https://lore.kernel.org/all/[email protected]/
>
> causes my Asus PCE-AC88 (1043:86fb) to stop working, because when modprobe
> loads brcmfmac it throws this error:
> ---
> [ 2740.647600] brcmfmac 0000:0d:00.0: brcmf_pcie_init_ringbuffers: invalid
> max_flowrings(264).
> ---
>
> This is also being reported on reddit:
> https://www.reddit.com/r/archlinux/comments/104pqv9/
> no_wifi_since_kernel_update_yesterday/
>
> (also, see https://forum.manjaro.org/t/brcmfmac-fails-to-load/131128)
>
> I think that the check on value > 256 is used as a kind of red herring to
> indirectly spot an inconsistent properties report from the PCI bus (?) about
> the network card.
The firmware loaded into the wifi device requests the host for 264
flowrings. This was apparently not expected to be a valid value, but
your device shows it is.
> Before that patch, the driver was correctly working for me and I could not
> observe any kernel panic. Maybe, at least in my case, the wrong value was
> still reported but could be safely ignored, as at a later point in time, when
> the card is initialised, everything worked fine.
>
> I am now stuck at kernel 6.1.1, if I upgrade I cannot use the card.
> Is there anything I can do to circumvent this issue? May I help somehow with
> debugging & testing? Please let me know...
6.2 is not formally released so I suppose you are an early adopter and
aware of the risk that implies ;-) There is no real debugging needed. I
will figure out what a sensible value would be and come up with a patch.
If you can test that that would be great. Will let you know.
Regards,
Arend
On 09.01.23 09:52, Arend van Spriel wrote:
> 6.2 is not formally released so I suppose you are an early adopter and
> aware of the risk that implies ;-) There is no real debugging needed. I
> will figure out what a sensible value would be and come up with a patch.
I am on 6.1. Version 6.1.1 works, 6.1.3 does not.
Will this patch be provided with 6.1.4? Or shall I wait until 6.2.0?
> If you can test that that would be great. Will let you know.
Sure! :)