* [PATCH v2 0/5] mt76: move common beacon code in mt76 module
From: Lorenzo Bianconi @ 2019-04-29 8:12 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka
Move beacon data structures shared between mt76x02 and mt7603 drivers
in mt76_dev.
Enable/disable pre_tbtt_tasklet tasklet in mt7603_set_channel
Changes since v1:
- added new patch: 'mt76: do not enable/disable pre_tbtt_tasklet in
scan_start/scan_complete'
Lorenzo Bianconi (5):
mt76: do not enable/disable pre_tbtt_tasklet in
scan_start/scan_complete
mt76: move beacon_int in mt76_dev
mt76: move beacon_mask in mt76_dev
mt76: move pre_tbtt_tasklet in mt76_dev
mt76: mt7603: enable/disable pre_tbtt_tasklet in mt7603_set_channel
drivers/net/wireless/mediatek/mt76/mt76.h | 4 ++++
.../wireless/mediatek/mt76/mt7603/beacon.c | 19 ++++++++++---------
.../net/wireless/mediatek/mt76/mt7603/core.c | 2 +-
.../net/wireless/mediatek/mt76/mt7603/init.c | 4 ++--
.../net/wireless/mediatek/mt76/mt7603/mac.c | 6 +++---
.../net/wireless/mediatek/mt76/mt7603/main.c | 11 +++++++----
.../wireless/mediatek/mt76/mt7603/mt7603.h | 5 -----
.../net/wireless/mediatek/mt76/mt76x0/pci.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x02.h | 3 ---
.../wireless/mediatek/mt76/mt76x02_beacon.c | 18 +++++++++---------
.../net/wireless/mediatek/mt76/mt76x02_mac.c | 2 +-
.../net/wireless/mediatek/mt76/mt76x02_mmio.c | 18 +++++++++---------
.../wireless/mediatek/mt76/mt76x02_usb_core.c | 11 ++++++-----
.../net/wireless/mediatek/mt76/mt76x02_util.c | 7 +------
.../wireless/mediatek/mt76/mt76x2/pci_init.c | 2 +-
.../wireless/mediatek/mt76/mt76x2/pci_main.c | 4 ++--
16 files changed, 57 insertions(+), 61 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH v2] ath10k: add support for simulate crash on SDIO chip
From: Wen Gong @ 2019-04-29 7:54 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
The command to simulate firmware crash:
echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash
It will send WMI_FORCE_FW_HANG_ASSERT to firmware, then it will trigger
CPU interrupt status register for SDIO chip, ath10k driver need to
configure it while enable SDIO interrupt, otherwise ath10k driver will
not get the assert error info.
After this change, it will success for simulate firmware crash.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
v2: add MBOX_CPU_STATUS_ENABLE_ASSERT_MASK for fw assert check
drivers/net/wireless/ath/ath10k/hw.h | 1 +
drivers/net/wireless/ath/ath10k/sdio.c | 10 ++++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 7131499..60521ed 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -1095,6 +1095,7 @@ struct ath10k_hw_ops {
#define MBOX_CPU_INT_STATUS_ENABLE_ADDRESS 0x00000819
#define MBOX_CPU_INT_STATUS_ENABLE_BIT_LSB 0
#define MBOX_CPU_INT_STATUS_ENABLE_BIT_MASK 0x000000ff
+#define MBOX_CPU_STATUS_ENABLE_ASSERT_MASK 0x00000001
#define MBOX_ERROR_STATUS_ENABLE_ADDRESS 0x0000081a
#define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_LSB 1
#define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_MASK 0x00000002
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
index fae56c6..1a3a7bf 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -850,6 +850,10 @@ static int ath10k_sdio_mbox_proc_cpu_intr(struct ath10k *ar)
out:
mutex_unlock(&irq_data->mtx);
+ if (cpu_int_status & MBOX_CPU_STATUS_ENABLE_ASSERT_MASK) {
+ ath10k_err(ar, "firmware crashed!\n");
+ queue_work(ar->workqueue, &ar->restart_work);
+ }
return ret;
}
@@ -1495,8 +1499,10 @@ static int ath10k_sdio_hif_enable_intrs(struct ath10k *ar)
regs->int_status_en |=
FIELD_PREP(MBOX_INT_STATUS_ENABLE_MBOX_DATA_MASK, 1);
- /* Set up the CPU Interrupt status Register */
- regs->cpu_int_status_en = 0;
+ /* Set up the CPU Interrupt Status Register, enable CPU sourced interrupt #0
+ * #0 is used for report assertion from target
+ */
+ regs->cpu_int_status_en = FIELD_PREP(MBOX_CPU_STATUS_ENABLE_ASSERT_MASK, 1);
/* Set up the Error Interrupt status Register */
regs->err_int_status_en =
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v8 12/15] kvm/vmx: Emulate MSR TEST_CTL
From: Thomas Gleixner @ 2019-04-29 7:31 UTC (permalink / raw)
To: Xiaoyao Li
Cc: Fenghua Yu, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Christopherson Sean J, Kalle Valo, Michael Chan,
linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <87ef9a01-fc99-20be-ec20-2c65e6a012a1@linux.intel.com>
On Sun, 28 Apr 2019, Xiaoyao Li wrote:
> On 4/28/2019 3:09 PM, Thomas Gleixner wrote:
> > On Sat, 27 Apr 2019, Xiaoyao Li wrote:
> > > Indeed, if we use split lock detection for protection purpose, when host
> > > has it enabled we should directly pass it to guest and forbid guest from
> > > disabling it. And only when host disables split lock detection, we can
> > > expose it and allow the guest to turn it on.
> > ?
> > > If it is used for protection purpose, then it should follow what you said
> > > and
> > > this feature needs to be disabled by default. Because there are split lock
> > > issues in old/current kernels and BIOS. That will cause the existing guest
> > > booting failure and killed due to those split lock.
> >
> > Rightfully so.
>
> So, the patch 13 "Enable split lock detection by default" needs to be removed?
Why? No. We enable it by default and everything which violates the rules
gets what it deserves. If there is an issue, boot with ac_splitlock_off and
be done with it.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v8 12/15] kvm/vmx: Emulate MSR TEST_CTL
From: Xiaoyao Li @ 2019-04-29 5:21 UTC (permalink / raw)
To: Thomas Gleixner, Xiaoyao Li, Paolo Bonzini
Cc: Fenghua Yu, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Dave Hansen, Ashok Raj, Peter Zijlstra, Ravi V Shankar,
Christopherson Sean J, Kalle Valo, Michael Chan, linux-kernel,
x86, kvm, netdev, linux-wireless
In-Reply-To: <alpine.DEB.2.21.1904280903520.1757@nanos.tec.linutronix.de>
Hi, Thomas,
Base on your comments, I plan to make the design as following:
1) When host enables this feature, there is no switch between host and
guest that guest running with it enabled by force. Since #AC in
exception bitmap is set in current kvm, every #AC in guest will be
trapped. And in handle_exception() handler in kvm, if #AC is caused by
alignment check, kvm injects #AC back to guest; if #AC is caused by
split lock, kvm sends a SIGBUS to userspace.
2) When host disables this feature, there needs atomic switch between
host and guest if different. And in handle_exception() handler in kvm,
we can just inject #AC back to guest, and let guest to handle it.
Besides, I think there might be an optimization for case #1.
When host has it enabled and guest also has it enabled, I think it's OK
to inject #AC back to guest, not directly kill the guest.
Because guest kernel has it enabled means it knows what this feature is
and it also want to get aware of and fault every split lock.
At this point, if guest has it enabled, we can leave it to guest. Only
when guest's configuration is having it disabled, can it be regards as
potentially harmful that we kill the guest once there is a #AC due to
split lock.
How do you think about the design and this optimization?
Hi, Paolo,
What's your opinion about this design of split lock in KVM?
Thanks.
On 4/28/2019 3:09 PM, Thomas Gleixner wrote:
> On Sat, 27 Apr 2019, Xiaoyao Li wrote:
>> On Thu, 2019-04-25 at 09:42 +0200, Thomas Gleixner wrote:
>>> But the way more interesting question is why are you exposing the MSR and
>>> the bit to the guest at all if the host has split lock detection enabled?
>>>
>>> That does not make any sense as you basically allow the guest to switch it
>>> off and then launch a slowdown attack. If the host has it enabled, then a
>>> guest has to be treated like any other process and the #AC trap has to be
>>> caught by the hypervisor which then kills the guest.
>>>
>>> Only if the host has split lock detection disabled, then you can expose it
>>> and allow the guest to turn it on and handle it on its own.
>>
>> Indeed, if we use split lock detection for protection purpose, when host
>> has it enabled we should directly pass it to guest and forbid guest from
>> disabling it. And only when host disables split lock detection, we can
>> expose it and allow the guest to turn it on.
> ?
>> If it is used for protection purpose, then it should follow what you said and
>> this feature needs to be disabled by default. Because there are split lock
>> issues in old/current kernels and BIOS. That will cause the existing guest
>> booting failure and killed due to those split lock.
>
> Rightfully so.
>
>> If it is only used for debug purpose, I think it might be OK to enable this
>> feature by default and make it indepedent between host and guest?
>
> No. It does not make sense.
>
>> So I think how to handle this feature between host and guest depends on how we
>> use it? Once you give me a decision, I will follow it in next version.
>
> As I said: The host kernel makes the decision.
>
> If the host kernel has it enabled then the guest is not allowed to change
> it. If the guest triggers an #AC it will be killed.
>
> If the host kernel has it disabled then the guest can enable it for it's
> own purposes.
>
> Thanks,
>
> tglx
>
^ permalink raw reply
* Re: [PATCH] ath10k: add support for simulate crash on SDIO chip
From: Nicolas Boichat @ 2019-04-29 5:20 UTC (permalink / raw)
To: Wen Gong; +Cc: ath10k, linux-wireless, Claire Chang
In-Reply-To: <1555406865-21514-1-git-send-email-wgong@codeaurora.org>
On Tue, Apr 16, 2019 at 5:28 PM Wen Gong <wgong@codeaurora.org> wrote:
>
> The command to simulate firmware crash:
> echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash
>
> It will send WMI_FORCE_FW_HANG_ASSERT to firmware, then it will trigger
> CPU interrupt status register for SDIO chip, ath10k driver need to
> configure it while enable SDIO interrupt, otherwise ath10k driver will
> not get the assert error info.
>
> After this change, it will success for simulate firmware crash.
>
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-00007-QCARMSWP-1.
>
> Signed-off-by: Wen Gong <wgong@codeaurora.org>
> ---
> drivers/net/wireless/ath/ath10k/hw.h | 1 +
> drivers/net/wireless/ath/ath10k/sdio.c | 8 ++++++--
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
> index 7131499..60521ed 100644
> --- a/drivers/net/wireless/ath/ath10k/hw.h
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> @@ -1095,6 +1095,7 @@ struct ath10k_hw_ops {
> #define MBOX_CPU_INT_STATUS_ENABLE_ADDRESS 0x00000819
> #define MBOX_CPU_INT_STATUS_ENABLE_BIT_LSB 0
> #define MBOX_CPU_INT_STATUS_ENABLE_BIT_MASK 0x000000ff
> +#define MBOX_CPU_STATUS_ENABLE_ASSERT_MASK 0x00000001
> #define MBOX_ERROR_STATUS_ENABLE_ADDRESS 0x0000081a
> #define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_LSB 1
> #define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_MASK 0x00000002
> diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
> index fae56c6..78a2f3b 100644
> --- a/drivers/net/wireless/ath/ath10k/sdio.c
> +++ b/drivers/net/wireless/ath/ath10k/sdio.c
> @@ -850,6 +850,8 @@ static int ath10k_sdio_mbox_proc_cpu_intr(struct ath10k *ar)
>
> out:
> mutex_unlock(&irq_data->mtx);
> + ath10k_err(ar, "firmware crashed!\n");
> + queue_work(ar->workqueue, &ar->restart_work);
Err, so you consider _any_ CPU interrupt to be caused by the FW
crashing? Is that correct? If so, please at least add a comment.
Otherwise, maybe you should run this only if
MBOX_CPU_STATUS_ENABLE_ASSERT_MASK is set in cpu_int_status?
> return ret;
> }
>
> @@ -1495,8 +1497,10 @@ static int ath10k_sdio_hif_enable_intrs(struct ath10k *ar)
> regs->int_status_en |=
> FIELD_PREP(MBOX_INT_STATUS_ENABLE_MBOX_DATA_MASK, 1);
>
> - /* Set up the CPU Interrupt status Register */
> - regs->cpu_int_status_en = 0;
> + /* Set up the CPU Interrupt Status Register, enable CPU sourced interrupt #0
> + * #0 is used for report assertion from target
> + */
> + regs->cpu_int_status_en = FIELD_PREP(MBOX_CPU_STATUS_ENABLE_ASSERT_MASK, 1);
>
> /* Set up the Error Interrupt status Register */
> regs->err_int_status_en =
> --
> 1.9.1
>
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the wireless-drivers tree
From: Luca Coelho @ 2019-04-29 5:19 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking, Kalle Valo, Wireless
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman
In-Reply-To: <20190429115338.5decb50b@canb.auug.org.au>
Hi Stephen,
On Mon, 2019-04-29 at 11:54 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
>
> between commits:
>
> 154d4899e411 ("iwlwifi: mvm: properly check debugfs dentry before using it")
> d156e67d3f58 ("iwlwifi: mvm: fix merge damage in iwl_mvm_vif_dbgfs_register()")
>
> from the wireless-drivers tree and commit:
>
> c9af7528c331 ("iwlwifi: mvm: no need to check return value of debugfs_create functions")
>
> from the net-next tree.
>
> I fixed it up (the latter removed the code modified by the former, so I
> just did that) and can carry the fix as necessary. This is now fixed as
> far as linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging. You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.
I checked your merge and it looks good, thanks!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] brcmfmac: allocate msgbuf pktid from 1 to pktids array size
From: Wright Feng @ 2019-04-29 4:50 UTC (permalink / raw)
To: Arend Van Spriel, franky.lin@broadcom.com,
hante.meuleman@broadcom.com, kvalo@codeaurora.org, Chi-Hsien Lin
Cc: linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
In-Reply-To: <66165629-aa4d-afbe-5b09-3a592ff44a82@broadcom.com>
On 2019/4/25 下午 07:22, Arend Van Spriel wrote:
> On 4/25/2019 10:04 AM, Wright Feng wrote:
>> Some PCIE firmwares drop txstatus if pktid is 0 and make packet held in
>> host side and not be released. If that packet type is 802.1x, the
>> pend_8021x_cnt value will be always greater than 0 and show "Timed out
>> waiting for no pending 802.1x packets" error message when sending key to
>> dongle.
>>
>> To be compatible with all firmwares, host should allocate msgbuf pktid
>> from 1 instead of from 0.
>
> looking at it we are wasting entry 0 with this patch. Could we avoid that?
>
> Regards,
> Arend
>
Hi Arend,
Thanks for the suggestion.
To avoid wasting index zero entry, I just increase request ID in TXflow
and decrease request ID when handling txstatus. I've posted patch v2.
Regards,
Wright
>> Signed-off-by: Wright Feng <wright.feng@cypress.com>
>> ---
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
>> index d3780ea..b2fab3c 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
>> @@ -348,7 +348,7 @@ brcmf_msgbuf_alloc_pktid(struct device *dev,
>> do {
>> (*idx)++;
>> if (*idx == pktids->array_size)
>> - *idx = 0;
>> + *idx = 1;
>> if (array[*idx].allocated.counter == 0)
>> if (atomic_cmpxchg(&array[*idx].allocated, 0, 1) == 0)
>> break;
>>
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the wireless-drivers tree
From: Stephen Rothwell @ 2019-04-29 1:54 UTC (permalink / raw)
To: David Miller, Networking, Kalle Valo, Wireless
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Luca Coelho
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
between commits:
154d4899e411 ("iwlwifi: mvm: properly check debugfs dentry before using it")
d156e67d3f58 ("iwlwifi: mvm: fix merge damage in iwl_mvm_vif_dbgfs_register()")
from the wireless-drivers tree and commit:
c9af7528c331 ("iwlwifi: mvm: no need to check return value of debugfs_create functions")
from the net-next tree.
I fixed it up (the latter removed the code modified by the former, so I
just did that) and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] brcmfmac: print firmware messages after a firmware crash
From: Rafał Miłecki @ 2019-04-28 21:35 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Rafał Miłecki, Kalle Valo, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list
In-Reply-To: <2ccb4482-7561-0812-92dc-5de3d639cc3e@broadcom.com>
On 2019-04-28 23:06, Arend Van Spriel wrote:
> On 4/27/2019 8:30 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> Normally firmware messages are printed with debugging enabled only.
>> It's
>> a good idea as firmware may print a lot of messages that normal users
>> don't need to care about.
>>
>> However, on firmware crash, it may be very helpful to log all recent
>> messages. There is almost always a backtrace available as well as
>> rought
>> info on the latest actions/state.
>
> nice... there is one minor nit below, but other than that...
>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>> ---
>> .../broadcom/brcm80211/brcmfmac/pcie.c | 24
>> ++++++++++++++-----
>> 1 file changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> index 637973fe8928..f519b050aff3 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> @@ -764,15 +764,22 @@ static void brcmf_pcie_bus_console_init(struct
>> brcmf_pciedev_info *devinfo)
>> console->base_addr, console->buf_addr, console->bufsize);
>> }
>> -
>> -static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info
>> *devinfo)
>> +/**
>> + * brcmf_pcie_bus_console_read - reads firmware messages
>> + *
>> + * @error: specifies if error has occurred (prints messages
>> unconditionally)
>> + */
>> +static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info
>> *devinfo,
>> + int error)
>
> Given how it is called I would say 'bool error' makes a bit more sense.
I even call that function passing "true" or "false" as argument. Nice
catch!
^ permalink raw reply
* [PATCH V2] brcmfmac: print firmware messages after a firmware crash
From: Rafał Miłecki @ 2019-04-28 21:38 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190427183008.27111-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
Normally firmware messages are printed with debugging enabled only. It's
a good idea as firmware may print a lot of messages that normal users
don't need to care about.
However, on firmware crash, it may be very helpful to log all recent
messages. There is almost always a backtrace available as well as rought
info on the latest actions/state.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
V2: Use "bool" for brcmf_pcie_bus_console_read() error argument
---
.../broadcom/brcm80211/brcmfmac/pcie.c | 24 ++++++++++++++-----
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 637973fe8928..594c14be5df0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -764,15 +764,22 @@ static void brcmf_pcie_bus_console_init(struct brcmf_pciedev_info *devinfo)
console->base_addr, console->buf_addr, console->bufsize);
}
-
-static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo)
+/**
+ * brcmf_pcie_bus_console_read - reads firmware messages
+ *
+ * @error: specifies if error has occurred (prints messages unconditionally)
+ */
+static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo,
+ bool error)
{
+ struct pci_dev *pdev = devinfo->pdev;
+ struct brcmf_bus *bus = dev_get_drvdata(&pdev->dev);
struct brcmf_pcie_console *console;
u32 addr;
u8 ch;
u32 newidx;
- if (!BRCMF_FWCON_ON())
+ if (!error && !BRCMF_FWCON_ON())
return;
console = &devinfo->shared.console;
@@ -796,7 +803,10 @@ static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo)
}
if (ch == '\n') {
console->log_str[console->log_idx] = 0;
- pr_debug("CONSOLE: %s", console->log_str);
+ if (error)
+ brcmf_err(bus, "CONSOLE: %s", console->log_str);
+ else
+ pr_debug("CONSOLE: %s", console->log_str);
console->log_idx = 0;
}
}
@@ -857,7 +867,7 @@ static irqreturn_t brcmf_pcie_isr_thread(int irq, void *arg)
&devinfo->pdev->dev);
}
}
- brcmf_pcie_bus_console_read(devinfo);
+ brcmf_pcie_bus_console_read(devinfo, false);
if (devinfo->state == BRCMFMAC_PCIE_STATE_UP)
brcmf_pcie_intr_enable(devinfo);
devinfo->in_irq = false;
@@ -1426,6 +1436,8 @@ static int brcmf_pcie_reset(struct device *dev)
struct brcmf_fw_request *fwreq;
int err;
+ brcmf_pcie_bus_console_read(devinfo, true);
+
brcmf_detach(dev);
brcmf_pcie_release_irq(devinfo);
@@ -1824,7 +1836,7 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
if (brcmf_attach(&devinfo->pdev->dev, devinfo->settings) == 0)
return;
- brcmf_pcie_bus_console_read(devinfo);
+ brcmf_pcie_bus_console_read(devinfo, false);
fail:
device_release_driver(dev);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] brcmfmac: print firmware messages after a firmware crash
From: Arend Van Spriel @ 2019-04-28 21:06 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Rafał Miłecki
In-Reply-To: <20190427183008.27111-1-zajec5@gmail.com>
On 4/27/2019 8:30 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Normally firmware messages are printed with debugging enabled only. It's
> a good idea as firmware may print a lot of messages that normal users
> don't need to care about.
>
> However, on firmware crash, it may be very helpful to log all recent
> messages. There is almost always a backtrace available as well as rought
> info on the latest actions/state.
nice... there is one minor nit below, but other than that...
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> .../broadcom/brcm80211/brcmfmac/pcie.c | 24 ++++++++++++++-----
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 637973fe8928..f519b050aff3 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -764,15 +764,22 @@ static void brcmf_pcie_bus_console_init(struct brcmf_pciedev_info *devinfo)
> console->base_addr, console->buf_addr, console->bufsize);
> }
>
> -
> -static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo)
> +/**
> + * brcmf_pcie_bus_console_read - reads firmware messages
> + *
> + * @error: specifies if error has occurred (prints messages unconditionally)
> + */
> +static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo,
> + int error)
Given how it is called I would say 'bool error' makes a bit more sense.
Gr. AvS
^ permalink raw reply
* Re: [PATCH] mt7603: wait for pre_tbtt_tasklet before scanning
From: Lorenzo Bianconi @ 2019-04-28 20:57 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <e7bc3645ce73a15ef9fa16a40f2bdb8577494769.1556280002.git.lorenzo@kernel.org>
>
> Disable pre_tbtt_tasklet tasklet before performing frequency scanning
>
Hi Felix,
please drop this patch and 'mt76: move common beacon code in mt76
module' series, I will send a v2 rebasing on a new patch
Regards,
Lorenzo
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/wireless/mediatek/mt76/mt7603/main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
> index 18a33d921601..184ed4cead0a 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
> @@ -535,6 +535,7 @@ mt7603_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> struct mt7603_dev *dev = hw->priv;
>
> set_bit(MT76_SCANNING, &dev->mt76.state);
> + tasklet_disable(&dev->pre_tbtt_tasklet);
> mt7603_beacon_set_timer(dev, -1, 0);
> }
>
> @@ -545,6 +546,7 @@ mt7603_sw_scan_complete(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
>
> clear_bit(MT76_SCANNING, &dev->mt76.state);
> mt7603_beacon_set_timer(dev, -1, dev->beacon_int);
> + tasklet_enable(&dev->pre_tbtt_tasklet);
> }
>
> static void
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: doc: Reflect new NVMEM of_get_mac_address behaviour
From: Andrew Lunn @ 2019-04-28 16:53 UTC (permalink / raw)
To: Petr Štetiar
Cc: netdev, devicetree, linux-kernel, David S. Miller, Rob Herring,
Mark Rutland, Vivien Didelot, Florian Fainelli, Yisen Zhuang,
Salil Mehta, Woojung Huh, Microchip Linux Driver Support,
Kunihiko Hayashi, Masahiro Yamada, Jassi Brar, Kalle Valo,
Matthias Brugger, Heiner Kallweit, Frank Rowand,
Srinivas Kandagatla, Maxime Ripard, Alban Bedel, linux-arm-kernel,
linux-wireless, linux-mediatek
In-Reply-To: <1556456002-13430-3-git-send-email-ynezz@true.cz>
On Sun, Apr 28, 2019 at 02:53:20PM +0200, Petr Štetiar wrote:
> As of_get_mac_address now supports NVMEM under the hood, we need to update
> the bindings documentation with the new nvmem-cell* properties, which would
> mean copy&pasting a lot of redundant information to every binding
> documentation currently referencing some of the MAC address properties.
>
> So I've just removed all the references to the optional MAC address
> properties and replaced them with the reference to the net/ethernet.txt
> file. While at it, I've also removed other optional Ethernet properties.
Hi Petr
I think each individual binding needs to give a hint if
of_get_mac_address() is used, and hence if these optional properties
are respected. The same is true for other optional properties. I don't
want to have to look at the driver to know which optional properties
are implemented, the binding should tell me. What the optional
properties mean, and which order they are used in can then be defined
in ethernet.txt.
So i would suggests something like:
The MAC address will be determined using the optional properties
defined in ethernet.txt.
And leave all the other optional parameters in the bindings.
Andrew
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: doc: Reflect new NVMEM of_get_mac_address behaviour
From: Petr Štetiar @ 2019-04-28 12:53 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel, David S. Miller, Rob Herring,
Mark Rutland, Andrew Lunn, Vivien Didelot, Florian Fainelli,
Yisen Zhuang, Salil Mehta, Woojung Huh,
Microchip Linux Driver Support, Kunihiko Hayashi, Masahiro Yamada,
Jassi Brar, Kalle Valo, Matthias Brugger
Cc: Heiner Kallweit, Frank Rowand, Srinivas Kandagatla, Maxime Ripard,
Alban Bedel, Petr Štetiar, linux-arm-kernel, linux-wireless,
linux-mediatek
In-Reply-To: <1556456002-13430-1-git-send-email-ynezz@true.cz>
As of_get_mac_address now supports NVMEM under the hood, we need to update
the bindings documentation with the new nvmem-cell* properties, which would
mean copy&pasting a lot of redundant information to every binding
documentation currently referencing some of the MAC address properties.
So I've just removed all the references to the optional MAC address
properties and replaced them with the reference to the net/ethernet.txt
file. While at it, I've also removed other optional Ethernet properties.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
---
Changes since v1:
* instead of updating all bindings documentation with nvmem properties,
I've just updated those docs which were already referencing MAC address
properties and replaced them with reference to common net/ethernet.txt
Documentation/devicetree/bindings/net/altera_tse.txt | 5 ++---
Documentation/devicetree/bindings/net/amd-xgbe.txt | 5 +++--
Documentation/devicetree/bindings/net/brcm,amac.txt | 4 ++--
Documentation/devicetree/bindings/net/cpsw.txt | 5 +++--
Documentation/devicetree/bindings/net/davinci_emac.txt | 5 +++--
Documentation/devicetree/bindings/net/dsa/dsa.txt | 13 ++-----------
Documentation/devicetree/bindings/net/ethernet.txt | 6 ++++--
Documentation/devicetree/bindings/net/hisilicon-femac.txt | 6 ++----
.../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt | 7 +++----
Documentation/devicetree/bindings/net/keystone-netcp.txt | 8 +++-----
Documentation/devicetree/bindings/net/macb.txt | 5 ++---
Documentation/devicetree/bindings/net/marvell-pxa168.txt | 5 +++--
.../devicetree/bindings/net/microchip,enc28j60.txt | 3 ++-
Documentation/devicetree/bindings/net/microchip,lan78xx.txt | 5 ++---
Documentation/devicetree/bindings/net/qca,qca7000.txt | 4 +++-
Documentation/devicetree/bindings/net/samsung-sxgbe.txt | 6 ++----
.../devicetree/bindings/net/snps,dwc-qos-ethernet.txt | 6 +++---
.../devicetree/bindings/net/socionext,uniphier-ave4.txt | 4 ++--
Documentation/devicetree/bindings/net/socionext-netsec.txt | 7 +++----
.../devicetree/bindings/net/wireless/mediatek,mt76.txt | 5 +++--
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 4 ++--
21 files changed, 54 insertions(+), 64 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/altera_tse.txt b/Documentation/devicetree/bindings/net/altera_tse.txt
index 0e21df9..c85a589 100644
--- a/Documentation/devicetree/bindings/net/altera_tse.txt
+++ b/Documentation/devicetree/bindings/net/altera_tse.txt
@@ -46,9 +46,8 @@ Required properties:
- reg: phy id used to communicate to phy.
- device_type: Must be "ethernet-phy".
-Optional properties:
-- local-mac-address: See ethernet.txt in the same directory.
-- max-frame-size: See ethernet.txt in the same directory.
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Example:
diff --git a/Documentation/devicetree/bindings/net/amd-xgbe.txt b/Documentation/devicetree/bindings/net/amd-xgbe.txt
index 93dcb79..b607765 100644
--- a/Documentation/devicetree/bindings/net/amd-xgbe.txt
+++ b/Documentation/devicetree/bindings/net/amd-xgbe.txt
@@ -24,8 +24,6 @@ Required properties:
- phy-mode: See ethernet.txt file in the same directory
Optional properties:
-- mac-address: mac address to be assigned to the device. Can be overridden
- by UEFI.
- dma-coherent: Present if dma operations are coherent
- amd,per-channel-interrupt: Indicates that Rx and Tx complete will generate
a unique interrupt for each DMA channel - this requires an additional
@@ -48,6 +46,9 @@ property is used.
- amd,serdes-dfe-tap-config: DFE taps available to run
- amd,serdes-dfe-tap-enable: DFE taps to enable
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
+
Example:
xgbe@e0700000 {
compatible = "amd,xgbe-seattle-v1a";
diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
index 0bfad65..5e0ba27 100644
--- a/Documentation/devicetree/bindings/net/brcm,amac.txt
+++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
@@ -16,8 +16,8 @@ Required properties:
registers (required for Northstar2)
- interrupts: Interrupt number
-Optional properties:
-- mac-address: See ethernet.txt file in the same directory
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Examples:
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
index 3264e19..370161c9 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -49,9 +49,10 @@ Required properties:
Optional properties:
- dual_emac_res_vlan : Specifies VID to be used to segregate the ports
-- mac-address : See ethernet.txt file in the same directory
- phy_id : Specifies slave phy id (deprecated, use phy-handle)
-- phy-handle : See ethernet.txt file in the same directory
+
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Slave sub-nodes:
- fixed-link : See fixed-link.txt file in the same directory
diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt
index ca83dcc..d250c8e 100644
--- a/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ b/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -20,11 +20,12 @@ Required properties:
Optional properties:
- phy-handle: See ethernet.txt file in the same directory.
If absent, davinci_emac driver defaults to 100/FULL.
-- nvmem-cells: phandle, reference to an nvmem node for the MAC address
-- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used
- ti,davinci-rmii-en: 1 byte, 1 means use RMII
- ti,davinci-no-bd-ram: boolean, does EMAC have BD RAM?
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
+
Example (enbw_cmc board):
eth0: emac@1e20000 {
compatible = "ti,davinci-dm6467-emac";
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.txt b/Documentation/devicetree/bindings/net/dsa/dsa.txt
index d66a529..6c8da44 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa.txt
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.txt
@@ -58,22 +58,13 @@ A user port has the following optional property:
Port child nodes may also contain the following optional standardised
properties, described in binding documents:
-- phy-handle : Phandle to a PHY on an MDIO bus. See
- Documentation/devicetree/bindings/net/ethernet.txt
- for details.
-
-- phy-mode : See
- Documentation/devicetree/bindings/net/ethernet.txt
- for details.
-
- fixed-link : Fixed-link subnode describing a link to a non-MDIO
managed entity. See
Documentation/devicetree/bindings/net/fixed-link.txt
for details.
-- local-mac-address : See
- Documentation/devicetree/bindings/net/ethernet.txt
- for details.
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Example
diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
index 2974e63..e6e01e0 100644
--- a/Documentation/devicetree/bindings/net/ethernet.txt
+++ b/Documentation/devicetree/bindings/net/ethernet.txt
@@ -4,12 +4,14 @@ NOTE: All 'phy*' properties documented below are Ethernet specific. For the
generic PHY 'phys' property, see
Documentation/devicetree/bindings/phy/phy-bindings.txt.
-- local-mac-address: array of 6 bytes, specifies the MAC address that was
- assigned to the network device;
- mac-address: array of 6 bytes, specifies the MAC address that was last used by
the boot program; should be used in cases where the MAC address assigned to
the device by the boot program is different from the "local-mac-address"
property;
+- local-mac-address: array of 6 bytes, specifies the MAC address that was
+ assigned to the network device;
+- nvmem-cells: phandle, reference to an nvmem node for the MAC address
+- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used
- max-speed: number, specifies maximum speed in Mbit/s supported by the device;
- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
the maximum frame size (there's contradiction in the Devicetree
diff --git a/Documentation/devicetree/bindings/net/hisilicon-femac.txt b/Documentation/devicetree/bindings/net/hisilicon-femac.txt
index d11af5e..99ad4d5 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-femac.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-femac.txt
@@ -14,15 +14,13 @@ Required properties:
the PHY reset signal(optional).
- reset-names: should contain the reset signal name "mac"(required)
and "phy"(optional).
-- mac-address: see ethernet.txt [1].
-- phy-mode: see ethernet.txt [1].
-- phy-handle: see ethernet.txt [1].
- hisilicon,phy-reset-delays-us: triplet of delays if PHY reset signal given.
The 1st cell is reset pre-delay in micro seconds.
The 2nd cell is reset pulse in micro seconds.
The 3rd cell is reset post-delay in micro seconds.
-[1] Documentation/devicetree/bindings/net/ethernet.txt
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Example:
hisi_femac: ethernet@10090000 {
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
index eea73ad..f4aad2a 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
@@ -16,9 +16,6 @@ Required properties:
- interrupts: should contain the MAC interrupt.
- #address-cells: must be <1>.
- #size-cells: must be <0>.
-- phy-mode: see ethernet.txt [1].
-- phy-handle: see ethernet.txt [1].
-- mac-address: see ethernet.txt [1].
- clocks: clock phandle and specifier pair.
- clock-names: contain the clock name "mac_core"(required) and "mac_ifc"(optional).
- resets: should contain the phandle to the MAC core reset signal(optional),
@@ -31,9 +28,11 @@ Required properties:
The 2nd cell is reset pulse in micro seconds.
The 3rd cell is reset post-delay in micro seconds.
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
+
- PHY subnode: inherits from phy binding [2]
-[1] Documentation/devicetree/bindings/net/ethernet.txt
[2] Documentation/devicetree/bindings/net/phy.txt
Example:
diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt b/Documentation/devicetree/bindings/net/keystone-netcp.txt
index 04ba1dc..2c9e8ac 100644
--- a/Documentation/devicetree/bindings/net/keystone-netcp.txt
+++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt
@@ -135,14 +135,12 @@ Optional properties:
are swapped. The netcp driver will swap the two DWORDs
back to the proper order when this property is set to 2
when it obtains the mac address from efuse.
-- local-mac-address: the driver is designed to use the of_get_mac_address api
- only if efuse-mac is 0. When efuse-mac is 0, the MAC
- address is obtained from local-mac-address. If this
- attribute is not present, then the driver will use a
- random MAC address.
- "netcp-device label": phandle to the device specification for each of NetCP
sub-module attached to this interface.
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
+
Example binding:
netcp: netcp@2000000 {
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 8b80515..58923f3 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -26,9 +26,8 @@ Required properties:
Optional elements: 'tsu_clk'
- clocks: Phandles to input clocks.
-Optional properties:
-- nvmem-cells: phandle, reference to an nvmem node for the MAC address
-- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Optional properties for PHY child node:
- reset-gpios : Should specify the gpio for phy reset
diff --git a/Documentation/devicetree/bindings/net/marvell-pxa168.txt b/Documentation/devicetree/bindings/net/marvell-pxa168.txt
index 845a148..0d36fcb 100644
--- a/Documentation/devicetree/bindings/net/marvell-pxa168.txt
+++ b/Documentation/devicetree/bindings/net/marvell-pxa168.txt
@@ -10,8 +10,9 @@ Optional properties:
- port-id: Ethernet port number. Should be '0','1' or '2'.
- #address-cells: must be 1 when using sub-nodes.
- #size-cells: must be 0 when using sub-nodes.
-- phy-handle: see ethernet.txt file in the same directory.
-- local-mac-address: see ethernet.txt file in the same directory.
+
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Sub-nodes:
Each PHY can be represented as a sub-node. This is not mandatory.
diff --git a/Documentation/devicetree/bindings/net/microchip,enc28j60.txt b/Documentation/devicetree/bindings/net/microchip,enc28j60.txt
index 24626e0..dc15eba 100644
--- a/Documentation/devicetree/bindings/net/microchip,enc28j60.txt
+++ b/Documentation/devicetree/bindings/net/microchip,enc28j60.txt
@@ -21,8 +21,9 @@ Optional properties:
- spi-max-frequency: Maximum frequency of the SPI bus when accessing the ENC28J60.
According to the ENC28J80 datasheet, the chip allows a maximum of 20 MHz, however,
board designs may need to limit this value.
-- local-mac-address: See ethernet.txt in the same directory.
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Example (for NXP i.MX28 with pin control stuff for GPIO irq):
diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
index 76786a0..7824581 100644
--- a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
+++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@@ -7,9 +7,8 @@ The Device Tree properties, if present, override the OTP and EEPROM.
Required properties:
- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
-Optional properties:
-- local-mac-address: see ethernet.txt
-- mac-address: see ethernet.txt
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Optional properties of the embedded PHY:
- microchip,led-modes: a 0..4 element vector, with each element configuring
diff --git a/Documentation/devicetree/bindings/net/qca,qca7000.txt b/Documentation/devicetree/bindings/net/qca,qca7000.txt
index e4a8a51..26cce1c 100644
--- a/Documentation/devicetree/bindings/net/qca,qca7000.txt
+++ b/Documentation/devicetree/bindings/net/qca,qca7000.txt
@@ -23,7 +23,6 @@ Optional properties:
Numbers smaller than 1000000 or greater than 16000000
are invalid. Missing the property will set the SPI
frequency to 8000000 Hertz.
-- local-mac-address : see ./ethernet.txt
- qca,legacy-mode : Set the SPI data transfer of the QCA7000 to legacy mode.
In this mode the SPI master must toggle the chip select
between each data word. In burst mode these gaps aren't
@@ -31,6 +30,9 @@ Optional properties:
the QCA7000 is setup via GPIO pin strapping. If the
property is missing the driver defaults to burst mode.
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
+
SPI Example:
/* Freescale i.MX28 SPI master*/
diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
index 46e5911..09bd850 100644
--- a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
+++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
@@ -20,10 +20,8 @@ Required properties:
When fixed length is needed for burst mode, it can be set within allowable
range.
-Optional properties:
-- mac-address: 6 bytes, mac address
-- max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather
- than the maximum frame size.
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Example:
diff --git a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
index 36f1aef..db4c698 100644
--- a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
+++ b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
@@ -103,8 +103,6 @@ Required properties:
Optional properties:
- dma-coherent: Present if dma operations are coherent
-- mac-address: See ethernet.txt in the same directory
-- local-mac-address: See ethernet.txt in the same directory
- phy-reset-gpios: Phandle and specifier for any GPIO used to reset the PHY.
See ../gpio/gpio.txt.
- snps,en-lpi: If present it enables use of the AXI low-power interface
@@ -118,7 +116,6 @@ Optional properties:
- snps,rxpbl: DMA Programmable burst length for the RX DMA
- snps,en-tx-lpi-clockgating: Enable gating of the MAC TX clock during
TX low-power mode.
-- phy-handle: See ethernet.txt file in the same directory
- mdio device tree subnode: When the GMAC has a phy connected to its local
mdio, there must be device tree subnode with the following
required properties:
@@ -133,6 +130,9 @@ Optional properties:
- device_type: Must be "ethernet-phy".
- fixed-mode device tree subnode: see fixed-link.txt in the same directory
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
+
Examples:
ethernet2@40010000 {
clock-names = "phy_ref_clk", "apb_pclk";
diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
index fc8f017..d90d27e 100644
--- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
+++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
@@ -31,8 +31,8 @@ Required properties:
- socionext,syscon-phy-mode: A phandle to syscon with one argument
that configures phy mode. The argument is the ID of MAC instance.
-Optional properties:
- - local-mac-address: See ethernet.txt in the same directory.
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Required subnode:
- mdio: A container for child nodes representing phy nodes.
diff --git a/Documentation/devicetree/bindings/net/socionext-netsec.txt b/Documentation/devicetree/bindings/net/socionext-netsec.txt
index 0cff94f..3073c16 100644
--- a/Documentation/devicetree/bindings/net/socionext-netsec.txt
+++ b/Documentation/devicetree/bindings/net/socionext-netsec.txt
@@ -26,10 +26,9 @@ Required properties:
Optional properties: (See ethernet.txt file in the same directory)
- dma-coherent: Boolean property, must only be present if memory
accesses performed by the device are cache coherent.
-- local-mac-address: See ethernet.txt in the same directory.
-- mac-address: See ethernet.txt in the same directory.
-- max-speed: See ethernet.txt in the same directory.
-- max-frame-size: See ethernet.txt in the same directory.
+
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
Example:
eth0: ethernet@522d0000 {
diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
index 7b9a776..bcccbb9 100644
--- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
+++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
@@ -13,11 +13,12 @@ properties:
Optional properties:
-- mac-address: See ethernet.txt in the parent directory
-- local-mac-address: See ethernet.txt in the parent directory
- ieee80211-freq-limit: See ieee80211.txt
- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
+
Optional nodes:
- led: Properties for a connected LED
Optional properties:
diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
index b7396c8..d07542f 100644
--- a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
@@ -34,9 +34,9 @@ Optional properties:
ath9k wireless chip (in this case the calibration /
EEPROM data will be loaded from userspace using the
kernel firmware loader).
-- mac-address: See ethernet.txt in the parent directory
-- local-mac-address: See ethernet.txt in the parent directory
+For all other optional Ethernet properties, please refer to
+Documentation/devicetree/bindings/net/ethernet.txt.
In this example, the node is defined as child node of the PCI controller:
&pci0 {
--
1.9.1
^ permalink raw reply related
* Re: pull-request: iwlwifi-fixes 2019-04-28
From: Kalle Valo @ 2019-04-28 11:27 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi, david.e.box, joe.konno
In-Reply-To: <aab3d1cab0caf00d7c3ae1cc10ca3ec99cc54efd.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> This is the fourth batch of fixes for v5.1. It contains two fixes I
> send in the last patchset plus a patch that I sent separately to fix a
> merge damage caused by the previous pull. More details about the
> contents in the tag description.
>
> I have sent this out before and kbuildbot reported success.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit b82d6c1f8f8288f744a9dcc16cd3085d535decca:
>
> mwifiex: Make resume actually do something useful again on SDIO cards (2019-04-25 14:05:14 +0300)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2019-04-28
>
> for you to fetch changes up to d156e67d3f58c5d3c7ebe1bec80657db534f32d4:
>
> iwlwifi: mvm: fix merge damage in iwl_mvm_vif_dbgfs_register() (2019-04-28 09:59:59 +0300)
>
> ----------------------------------------------------------------
> Fourth batch of patches intended for v5.1
>
> * Fix an oops when we receive a packet with bogus lengths;
> * Fix a bug that prevented 5350 devices from working;
> * Fix a small merge damage from the previous series;
>
> ----------------------------------------------------------------
Pulled, thanks Luca.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v8 12/15] kvm/vmx: Emulate MSR TEST_CTL
From: Xiaoyao Li @ 2019-04-28 7:34 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Fenghua Yu, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Christopherson Sean J, Kalle Valo, Michael Chan,
linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <alpine.DEB.2.21.1904280903520.1757@nanos.tec.linutronix.de>
On 4/28/2019 3:09 PM, Thomas Gleixner wrote:
> On Sat, 27 Apr 2019, Xiaoyao Li wrote:
>> On Thu, 2019-04-25 at 09:42 +0200, Thomas Gleixner wrote:
>>> On Wed, 24 Apr 2019, Fenghua Yu wrote:
>>>>
>>>> +static void atomic_switch_msr_test_ctl(struct vcpu_vmx *vmx)
>>>> +{
>>>> + u64 host_msr_test_ctl;
>>>> +
>>>> + if (!boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
>>>> + return;
>>>
>>> Again: MSR_TST_CTL is not only about LOCK_DETECT. Check the control mask.
>>>
>>>> + host_msr_test_ctl = this_cpu_read(msr_test_ctl_cache);
>>>> +
>>>> + if (host_msr_test_ctl == vmx->msr_test_ctl) {
>>>
>>> This still assumes that the only bit which can be set in the MSR is that
>>> lock detect bit.
>>>
>>>> + clear_atomic_switch_msr(vmx, MSR_TEST_CTL);
>>>> + } else {
>>>> + add_atomic_switch_msr(vmx, MSR_TEST_CTL, vmx->msr_test_ctl,
>>>> + host_msr_test_ctl, false);
>>>
>>> So what happens here is that if any other bit is set on the host, VMENTER
>>> will happily clear it.
>>
>> There are two bits of MSR TEST_CTL defined in Intel SDM now, which is bit
>> 29 and bit 31. Bit 31 is not used in kernel, and here we only need to
>> switch bit 29 between host and guest. So should I also change the name
>> to atomic_switch_split_lock_detect() to indicate that we only switch bit
>> 29?
>
> No. Just because we ony use the split lock bit now, there is no
> jusification to name everything splitlock. This is going to have renamed
> when yet another bit is added in the future. The MSR is exposed to the
> guest and the restriction of bits happens to be splitlock today.
Got it.
>>> guest = (host & ~vmx->test_ctl_mask) | vmx->test_ctl;
>>>
>>> That preserves any bits which are not exposed to the guest.
>>>
>>> But the way more interesting question is why are you exposing the MSR and
>>> the bit to the guest at all if the host has split lock detection enabled?
>>>
>>> That does not make any sense as you basically allow the guest to switch it
>>> off and then launch a slowdown attack. If the host has it enabled, then a
>>> guest has to be treated like any other process and the #AC trap has to be
>>> caught by the hypervisor which then kills the guest.
>>>
>>> Only if the host has split lock detection disabled, then you can expose it
>>> and allow the guest to turn it on and handle it on its own.
>>
>> Indeed, if we use split lock detection for protection purpose, when host
>> has it enabled we should directly pass it to guest and forbid guest from
>> disabling it. And only when host disables split lock detection, we can
>> expose it and allow the guest to turn it on.
> ?
>> If it is used for protection purpose, then it should follow what you said and
>> this feature needs to be disabled by default. Because there are split lock
>> issues in old/current kernels and BIOS. That will cause the existing guest
>> booting failure and killed due to those split lock.
>
> Rightfully so.
So, the patch 13 "Enable split lock detection by default" needs to be
removed?
>> If it is only used for debug purpose, I think it might be OK to enable this
>> feature by default and make it indepedent between host and guest?
>
> No. It does not make sense.
>
>> So I think how to handle this feature between host and guest depends on how we
>> use it? Once you give me a decision, I will follow it in next version.
>
> As I said: The host kernel makes the decision.
>
> If the host kernel has it enabled then the guest is not allowed to change
> it. If the guest triggers an #AC it will be killed.
>
> If the host kernel has it disabled then the guest can enable it for it's
> own purposes.
>
> Thanks,
>
> tglx
>
^ permalink raw reply
* Re: [PATCH v8 12/15] kvm/vmx: Emulate MSR TEST_CTL
From: Thomas Gleixner @ 2019-04-28 7:09 UTC (permalink / raw)
To: Xiaoyao Li
Cc: Fenghua Yu, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Christopherson Sean J, Kalle Valo, Michael Chan,
linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <7395908840acfbf806146f5f20d3509342771a19.camel@linux.intel.com>
On Sat, 27 Apr 2019, Xiaoyao Li wrote:
> On Thu, 2019-04-25 at 09:42 +0200, Thomas Gleixner wrote:
> > On Wed, 24 Apr 2019, Fenghua Yu wrote:
> > >
> > > +static void atomic_switch_msr_test_ctl(struct vcpu_vmx *vmx)
> > > +{
> > > + u64 host_msr_test_ctl;
> > > +
> > > + if (!boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
> > > + return;
> >
> > Again: MSR_TST_CTL is not only about LOCK_DETECT. Check the control mask.
> >
> > > + host_msr_test_ctl = this_cpu_read(msr_test_ctl_cache);
> > > +
> > > + if (host_msr_test_ctl == vmx->msr_test_ctl) {
> >
> > This still assumes that the only bit which can be set in the MSR is that
> > lock detect bit.
> >
> > > + clear_atomic_switch_msr(vmx, MSR_TEST_CTL);
> > > + } else {
> > > + add_atomic_switch_msr(vmx, MSR_TEST_CTL, vmx->msr_test_ctl,
> > > + host_msr_test_ctl, false);
> >
> > So what happens here is that if any other bit is set on the host, VMENTER
> > will happily clear it.
>
> There are two bits of MSR TEST_CTL defined in Intel SDM now, which is bit
> 29 and bit 31. Bit 31 is not used in kernel, and here we only need to
> switch bit 29 between host and guest. So should I also change the name
> to atomic_switch_split_lock_detect() to indicate that we only switch bit
> 29?
No. Just because we ony use the split lock bit now, there is no
jusification to name everything splitlock. This is going to have renamed
when yet another bit is added in the future. The MSR is exposed to the
guest and the restriction of bits happens to be splitlock today.
> > guest = (host & ~vmx->test_ctl_mask) | vmx->test_ctl;
> >
> > That preserves any bits which are not exposed to the guest.
> >
> > But the way more interesting question is why are you exposing the MSR and
> > the bit to the guest at all if the host has split lock detection enabled?
> >
> > That does not make any sense as you basically allow the guest to switch it
> > off and then launch a slowdown attack. If the host has it enabled, then a
> > guest has to be treated like any other process and the #AC trap has to be
> > caught by the hypervisor which then kills the guest.
> >
> > Only if the host has split lock detection disabled, then you can expose it
> > and allow the guest to turn it on and handle it on its own.
>
> Indeed, if we use split lock detection for protection purpose, when host
> has it enabled we should directly pass it to guest and forbid guest from
> disabling it. And only when host disables split lock detection, we can
> expose it and allow the guest to turn it on.
?
> If it is used for protection purpose, then it should follow what you said and
> this feature needs to be disabled by default. Because there are split lock
> issues in old/current kernels and BIOS. That will cause the existing guest
> booting failure and killed due to those split lock.
Rightfully so.
> If it is only used for debug purpose, I think it might be OK to enable this
> feature by default and make it indepedent between host and guest?
No. It does not make sense.
> So I think how to handle this feature between host and guest depends on how we
> use it? Once you give me a decision, I will follow it in next version.
As I said: The host kernel makes the decision.
If the host kernel has it enabled then the guest is not allowed to change
it. If the guest triggers an #AC it will be killed.
If the host kernel has it disabled then the guest can enable it for it's
own purposes.
Thanks,
tglx
^ permalink raw reply
* pull-request: iwlwifi-fixes 2019-04-28
From: Luca Coelho @ 2019-04-28 7:06 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi, david.e.box, joe.konno
[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]
Hi Kalle,
This is the fourth batch of fixes for v5.1. It contains two fixes I
send in the last patchset plus a patch that I sent separately to fix a
merge damage caused by the previous pull. More details about the
contents in the tag description.
I have sent this out before and kbuildbot reported success.
Please let me know if there are any issues.
Cheers,
Luca.
The following changes since commit b82d6c1f8f8288f744a9dcc16cd3085d535decca:
mwifiex: Make resume actually do something useful again on SDIO cards (2019-04-25 14:05:14 +0300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2019-04-28
for you to fetch changes up to d156e67d3f58c5d3c7ebe1bec80657db534f32d4:
iwlwifi: mvm: fix merge damage in iwl_mvm_vif_dbgfs_register() (2019-04-28 09:59:59 +0300)
----------------------------------------------------------------
Fourth batch of patches intended for v5.1
* Fix an oops when we receive a packet with bogus lengths;
* Fix a bug that prevented 5350 devices from working;
* Fix a small merge damage from the previous series;
----------------------------------------------------------------
Emmanuel Grumbach (1):
iwlwifi: fix driver operation for 5350
Luca Coelho (2):
iwlwifi: mvm: check for length correctness in iwl_mvm_create_skb()
iwlwifi: mvm: fix merge damage in iwl_mvm_vif_dbgfs_register()
drivers/net/wireless/intel/iwlwifi/cfg/5000.c | 3 ++-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 6 ------
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 28 ++++++++++++++++++++++++----
3 files changed, 26 insertions(+), 11 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] ath10k: remove mmc_hw_reset while hif power down
From: Wen Gong @ 2019-04-28 2:17 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
For sdio 3.0 chip, the clock will drop from 200M Hz to 50M Hz after load
ath10k driver, it is because mmc_hw_reset will reset the sdio's power,
then mmc will consider it as sdio 2.0 and drop the clock.
Remove mmc_hw_reset will avoid the drop of clock.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/sdio.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
index fae56c6..f1d2af8 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -1433,10 +1433,6 @@ static void ath10k_sdio_hif_power_down(struct ath10k *ar)
return;
}
- ret = mmc_hw_reset(ar_sdio->func->card->host);
- if (ret)
- ath10k_warn(ar, "unable to reset sdio: %d\n", ret);
-
sdio_release_host(ar_sdio->func);
ar_sdio->is_disabled = true;
--
1.9.1
^ permalink raw reply related
* [PATCH] mac80211: fix possible deadlock in TX path
From: Erik Stromdahl @ 2019-04-27 20:41 UTC (permalink / raw)
To: johannes, davem, linux-wireless, linux-kernel; +Cc: Erik Stromdahl
This patch fixes a possible deadlock when updating the TX statistics
(when calling into ieee80211_tx_stats()) from ieee80211_tx_dequeue().
ieee80211_tx_dequeue() might be called from process context.
Since we take a lock without softirq's disabled when updating the TX
statistics (u64_stats_update_begin() takes a lock), there is a risk that
we get an interrupt while in the write critical section (after the call
to u64_stats_update_begin() and before u64_stats_update_end()).
We could then have a softirq (in interrupt context) when the interrupt
exits. The softirq can then end up taking the same lock resulting in a
deadlock of a CPU.
By using the _irqsave and _irqrestore versions of u64_stats_update_begin,
we make sure softirq's are disabled in the critical write section.
This issue was reported by lockdep (see splat below).
In this case lockdep has detected a potential scenario where
ieee80211_tx_dequeue() is called from a threaded IRQ (SDIO IRQ thread).
The thread could be interrupted and a softirq also calling
ieee80211_tx_dequeue() could get scheduled while the lock is held.
================================
WARNING: inconsistent lock state
5.1.0-rc6-wt-ath+ #34 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
irq/64-mmc0/120 [HC0[0]:SC0[0]:HE1:SE1] takes:
2bf4fbe3 (&syncp->seq#4){+.?.}, at: ieee80211_tx_dequeue+0x30c/0xb9c
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0xd0/0x1f4
ieee80211_xmit_fast_finish+0xa8/0x2b4
ieee80211_tx_dequeue+0x30c/0xb9c
ath10k_mac_tx_push_txq+0x78/0x2a4 [ath10k_core]
ath10k_mac_op_wake_tx_queue+0xb0/0xbc [ath10k_core]
ieee80211_queue_skb+0x2e0/0x4c4
__ieee80211_subif_start_xmit+0x6c4/0xc4c
ieee80211_subif_start_xmit+0x4c/0x414
dev_hard_start_xmit+0xd8/0x37c
__dev_queue_xmit+0xcd0/0xe40
dev_queue_xmit+0x1c/0x20
neigh_resolve_output+0x15c/0x21c
ip6_finish_output2+0x200/0xd68
ip6_finish_output+0x124/0x2c8
ip6_output+0x80/0x480
mld_sendpack+0x340/0x7ec
mld_ifc_timer_expire+0x1dc/0x2fc
call_timer_fn+0xd0/0x33c
expire_timers+0xe0/0x1ac
run_timer_softirq+0xfc/0x1e4
__do_softirq+0xf8/0x54c
irq_exit+0x13c/0x190
handle_IPI+0x120/0x3d4
gic_handle_irq+0xb8/0xcc
__irq_svc+0x70/0x98
cpuidle_enter_state+0x188/0x5e4
cpuidle_enter+0x24/0x28
call_cpuidle+0x30/0x4c
do_idle+0x230/0x2d0
cpu_startup_entry+0x28/0x2c
secondary_start_kernel+0x164/0x1ac
0x10102b0c
irq event stamp: 90887157
hardirqs last enabled at (90887157): [<c013417c>] __local_bh_enable_ip+0xb4/0x18c
hardirqs last disabled at (90887155): [<c0134130>] __local_bh_enable_ip+0x68/0x18c
softirqs last enabled at (90887156): [<c0cb4444>] ieee80211_tx_dequeue+0x24c/0xb9c
softirqs last disabled at (90887152): [<c0cb4248>] ieee80211_tx_dequeue+0x50/0xb9c
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&syncp->seq#4);
<Interrupt>
lock(&syncp->seq#4);
*** DEADLOCK ***
1 lock held by irq/64-mmc0/120:
#0: e6439974 (rcu_read_lock){....}, at: ath10k_mac_tx_push_pending+0x48/0x2e0 [ath10k_core]
stack backtrace:
CPU: 0 PID: 120 Comm: irq/64-mmc0 Not tainted 5.1.0-rc6-wt-ath+ #34
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c010ecec>] (dump_backtrace) from [<c010efec>] (show_stack+0x20/0x24)
r7:00000000 r6:60010093 r5:00000000 r4:c14ea35c
[<c010efcc>] (show_stack) from [<c0cfaef4>] (dump_stack+0xdc/0x114)
[<c0cfae18>] (dump_stack) from [<c01867f0>] (print_usage_bug+0x1f4/0x2f0)
r10:d2890000 r9:ff7b9c24 r8:c1415100 r7:c10ca668 r6:00000004 r5:c1994c58
r4:d2890000 r3:fe066f04
[<c01865fc>] (print_usage_bug) from [<c0186a94>] (mark_lock+0x1a8/0x708)
r8:00000004 r7:00000004 r6:d2890000 r5:00000006 r4:d2890518
[<c01868ec>] (mark_lock) from [<c01872bc>] (__lock_acquire+0x250/0x1fa4)
r10:d2890000 r9:ff7b9c24 r8:00000004 r7:d2890518 r6:00000000 r5:00000001
r4:00000420
[<c018706c>] (__lock_acquire) from [<c0189810>] (lock_acquire+0xd0/0x1f4)
r10:c1414970 r9:00000000 r8:00000000 r7:00000000 r6:ff7b9c24 r5:00000000
r4:60010013
[<c0189740>] (lock_acquire) from [<c0cb190c>] (ieee80211_xmit_fast_finish+0xa8/0x2b4)
r10:ff7b9c24 r9:c0cb4504 r8:00000001 r7:00000000 r6:d2d60000 r5:d2f1a900
r4:ff7b9c00
[<c0cb1864>] (ieee80211_xmit_fast_finish) from [<c0cb4504>] (ieee80211_tx_dequeue+0x30c/0xb9c)
r10:d2f1a900 r9:d2d607a4 r8:d2cf20dc r7:d330b29c r6:d2cf2000 r5:d2c342ba
r4:d2899d3c
[<c0cb41f8>] (ieee80211_tx_dequeue) from [<bf057f64>] (ath10k_mac_tx_push_txq+0x78/0x2a4 [ath10k_core])
r10:d2d607cc r9:d2fe06a0 r8:00000000 r7:d2fe1e30 r6:d2fe1d38 r5:d2fe1540
r4:d2cf20dc
[<bf057eec>] (ath10k_mac_tx_push_txq [ath10k_core]) from [<bf058364>] (ath10k_mac_tx_push_pending+0x1d4/0x2e0 [ath10k_core])
r10:d2cf20dc r9:bf0582b4 r8:bf0b1dba r7:00000002 r6:c1429994 r5:00000000
r4:d2fe06a0
[<bf058190>] (ath10k_mac_tx_push_pending [ath10k_core]) from [<bf0e25a4>] (ath10k_sdio_irq_handler+0x30c/0x4d8 [ath10k_sdio])
r10:00005b5a r9:d2fcc040 r8:00180201 r7:d2fe6540 r6:d2fe6a7c r5:00000000
r4:d2fe1540
[<bf0e2298>] (ath10k_sdio_irq_handler [ath10k_sdio]) from [<c08e9d20>] (process_sdio_pending_irqs+0x4c/0x1bc)
r10:d288cb00 r9:d229f400 r8:00000001 r7:00000000 r6:d27fe800 r5:c1414948
r4:d27f3000
[<c08e9cd4>] (process_sdio_pending_irqs) from [<c08e9edc>] (sdio_run_irqs+0x4c/0x68)
r10:d288cb00 r9:d229f400 r8:00000001 r7:00000000 r6:d27f36a0 r5:00000100
r4:d27f3000
[<c08e9e90>] (sdio_run_irqs) from [<c08f5360>] (sdhci_thread_irq+0x80/0xbc)
r5:00000100 r4:d27f34c0
[<c08f52e0>] (sdhci_thread_irq) from [<c019a648>] (irq_thread_fn+0x2c/0x88)
r7:00000000 r6:d288cb24 r5:d229f400 r4:d288cb00
[<c019a61c>] (irq_thread_fn) from [<c019a984>] (irq_thread+0x120/0x22c)
r7:00000000 r6:d288cb24 r5:ffffe000 r4:00000000
[<c019a864>] (irq_thread) from [<c0155214>] (kthread+0x154/0x168)
r10:d2101bd8 r9:c019a864 r8:d288cb00 r7:d2898000 r6:d288cb40 r5:d2198600
r4:00000000
[<c01550c0>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
Exception stack(0xd2899fb0 to 0xd2899ff8)
9fa0: 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c01550c0
r4:d288cb40
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
net/mac80211/tx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 8037384fc06e..b033fbf1d1cd 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -44,12 +44,13 @@
static inline void ieee80211_tx_stats(struct net_device *dev, u32 len)
{
+ unsigned long flags;
struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
- u64_stats_update_begin(&tstats->syncp);
+ flags = u64_stats_update_begin_irqsave(&tstats->syncp);
tstats->tx_packets++;
tstats->tx_bytes += len;
- u64_stats_update_end(&tstats->syncp);
+ u64_stats_update_end_irqrestore(&tstats->syncp, flags);
}
static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
--
2.19.1
^ permalink raw reply related
* [PATCH] brcmfmac: print firmware messages after a firmware crash
From: Rafał Miłecki @ 2019-04-27 18:30 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
Normally firmware messages are printed with debugging enabled only. It's
a good idea as firmware may print a lot of messages that normal users
don't need to care about.
However, on firmware crash, it may be very helpful to log all recent
messages. There is almost always a backtrace available as well as rought
info on the latest actions/state.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../broadcom/brcm80211/brcmfmac/pcie.c | 24 ++++++++++++++-----
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 637973fe8928..f519b050aff3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -764,15 +764,22 @@ static void brcmf_pcie_bus_console_init(struct brcmf_pciedev_info *devinfo)
console->base_addr, console->buf_addr, console->bufsize);
}
-
-static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo)
+/**
+ * brcmf_pcie_bus_console_read - reads firmware messages
+ *
+ * @error: specifies if error has occurred (prints messages unconditionally)
+ */
+static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo,
+ int error)
{
+ struct pci_dev *pdev = devinfo->pdev;
+ struct brcmf_bus *bus = dev_get_drvdata(&pdev->dev);
struct brcmf_pcie_console *console;
u32 addr;
u8 ch;
u32 newidx;
- if (!BRCMF_FWCON_ON())
+ if (!error && !BRCMF_FWCON_ON())
return;
console = &devinfo->shared.console;
@@ -796,7 +803,10 @@ static void brcmf_pcie_bus_console_read(struct brcmf_pciedev_info *devinfo)
}
if (ch == '\n') {
console->log_str[console->log_idx] = 0;
- pr_debug("CONSOLE: %s", console->log_str);
+ if (error)
+ brcmf_err(bus, "CONSOLE: %s", console->log_str);
+ else
+ pr_debug("CONSOLE: %s", console->log_str);
console->log_idx = 0;
}
}
@@ -857,7 +867,7 @@ static irqreturn_t brcmf_pcie_isr_thread(int irq, void *arg)
&devinfo->pdev->dev);
}
}
- brcmf_pcie_bus_console_read(devinfo);
+ brcmf_pcie_bus_console_read(devinfo, false);
if (devinfo->state == BRCMFMAC_PCIE_STATE_UP)
brcmf_pcie_intr_enable(devinfo);
devinfo->in_irq = false;
@@ -1426,6 +1436,8 @@ static int brcmf_pcie_reset(struct device *dev)
struct brcmf_fw_request *fwreq;
int err;
+ brcmf_pcie_bus_console_read(devinfo, true);
+
brcmf_detach(dev);
brcmf_pcie_release_irq(devinfo);
@@ -1824,7 +1836,7 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
if (brcmf_attach(&devinfo->pdev->dev, devinfo->settings) == 0)
return;
- brcmf_pcie_bus_console_read(devinfo);
+ brcmf_pcie_bus_console_read(devinfo, false);
fail:
device_release_driver(dev);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 25/79] docs: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-04-27 18:13 UTC (permalink / raw)
To: Mark Brown
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Sebastian Reichel, Bjorn Helgaas,
Rafael J. Wysocki, Viresh Kumar, Len Brown, Pavel Machek,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mathieu Poirier,
Suzuki K Poulose, Harry Wei, Alex Shi, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Johannes Berg, David S. Miller, linux-pm, linux-pci,
linux-arm-kernel, intel-gfx, dri-devel, linux-wireless, netdev
In-Reply-To: <20190427172551.GI14916@sirena.org.uk>
Em Sun, 28 Apr 2019 02:25:51 +0900
Mark Brown <broonie@kernel.org> escreveu:
> On Fri, Apr 26, 2019 at 06:46:09AM -0300, Mauro Carvalho Chehab wrote:
> > Mark Brown <broonie@kernel.org> escreveu:
>
> > > This is massively CCed covering a large range of subsystems and is patch
> > > 25 of a 79 patch series so I've no context for what's going on here or
> > > why...
>
> > You can see more details at patch 00/79:
> > https://lore.kernel.org/lkml/20190422115110.26443b44@coco.lan/
>
> OK, it would've helped to CC people on that.
I know, but, due to bad experiences in the past, I had to actually
remove people from it, because several servers reject e-mails with
more than ~30 destination addresses, as they consider it to be spam.
> Anyway
>
> Acked-by: Mark Brown <broonie@kernel.org>
Thanks!
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v2 25/79] docs: convert docs to ReST and rename to *.rst
From: Mark Brown @ 2019-04-27 17:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Sebastian Reichel, Bjorn Helgaas,
Rafael J. Wysocki, Viresh Kumar, Len Brown, Pavel Machek,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mathieu Poirier,
Suzuki K Poulose, Harry Wei, Alex Shi, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Johannes Berg, David S. Miller, linux-pm, linux-pci,
linux-arm-kernel, intel-gfx, dri-devel, linux-wireless, netdev
In-Reply-To: <20190426064609.7f00e013@coco.lan>
[-- Attachment #1: Type: text/plain, Size: 501 bytes --]
On Fri, Apr 26, 2019 at 06:46:09AM -0300, Mauro Carvalho Chehab wrote:
> Mark Brown <broonie@kernel.org> escreveu:
> > This is massively CCed covering a large range of subsystems and is patch
> > 25 of a 79 patch series so I've no context for what's going on here or
> > why...
> You can see more details at patch 00/79:
> https://lore.kernel.org/lkml/20190422115110.26443b44@coco.lan/
OK, it would've helped to CC people on that. Anyway
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: doc: Reflect new NVMEM of_get_mac_address behaviour
From: Florian Fainelli @ 2019-04-27 16:56 UTC (permalink / raw)
To: Petr Štetiar, netdev, devicetree, linux-kernel,
David S. Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Vivien Didelot, Heiko Stuebner, Fugang Duan, Claudiu Manoil,
Yisen Zhuang, Salil Mehta, Woojung Huh,
Microchip Linux Driver Support, Neil Armstrong, Kunihiko Hayashi,
Masahiro Yamada, Jassi Brar, Maxime Coquelin, Alexandre Torgue,
Kalle Valo, Matthias Brugger, Li Yang
Cc: Heiner Kallweit, Frank Rowand, Srinivas Kandagatla, Maxime Ripard,
Alban Bedel, linux-arm-kernel, linux-rockchip, linux-oxnas,
linux-stm32, linux-wireless, linux-mediatek, linuxppc-dev
In-Reply-To: <1556320002-26213-3-git-send-email-ynezz@true.cz>
On 4/26/2019 4:06 PM, Petr Štetiar wrote:
> As of_get_mac_address now supports NVMEM under the hood, we should
> update the bindings documentation with the new nvmem-cell* properties.
> While at it, fix also other missing properties supported by
> of_get_mac_address.
>
> Signed-off-by: Petr Štetiar <ynezz@true.cz>
While I appreciate your effort in making the bindings up to date and
consistent, this does really scale well and is an error prone exercise,
how about consolidating all MAC address related properties into the
ethernet.txt document like you just did and update all bindings to
indicate something along the lines of:
For all other standard Ethernet related properties, please refer to
ethernet.txt or something like that?
--
Florian
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: doc: Reflect new NVMEM of_get_mac_address behaviour
From: Andrew Lunn @ 2019-04-27 16:39 UTC (permalink / raw)
To: Petr Štetiar
Cc: netdev, devicetree, linux-kernel, David S. Miller, Rob Herring,
Mark Rutland, Vivien Didelot, Florian Fainelli, Heiko Stuebner,
Fugang Duan, Claudiu Manoil, Yisen Zhuang, Salil Mehta,
Woojung Huh, Microchip Linux Driver Support, Neil Armstrong,
Kunihiko Hayashi, Masahiro Yamada, Jassi Brar, Maxime Coquelin,
Alexandre Torgue, Kalle Valo, Matthias Brugger, Li Yang,
Heiner Kallweit, Frank Rowand, Srinivas Kandagatla, Maxime Ripard,
Alban Bedel, linux-arm-kernel, linux-rockchip, linux-oxnas,
linux-stm32, linux-wireless, linux-mediatek, linuxppc-dev
In-Reply-To: <1556320002-26213-3-git-send-email-ynezz@true.cz>
> diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
> index 8b80515..92c5642 100644
> --- a/Documentation/devicetree/bindings/net/macb.txt
> +++ b/Documentation/devicetree/bindings/net/macb.txt
> @@ -26,15 +26,15 @@ Required properties:
> Optional elements: 'tsu_clk'
> - clocks: Phandles to input clocks.
>
> -Optional properties:
> -- nvmem-cells: phandle, reference to an nvmem node for the MAC address
> -- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used
> -
> Optional properties for PHY child node:
> - reset-gpios : Should specify the gpio for phy reset
> - magic-packet : If present, indicates that the hardware supports waking
> up via magic packet.
> - phy-handle : see ethernet.txt file in the same directory
> +- mac-address: See ethernet.txt in the same directory.
> +- local-mac-address: See ethernet.txt in the same directory.
> +- nvmem-cells: See ethernet.txt in the same directory.
> +- nvmem-cell-names: See ethernet.txt in the same directory.
This looks wrong. The MAC address is not a PHY property, so should not
be inside the PHY child node.
phy-handle is in the wrong place, but that is a separate problem.
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox