* Re: [RFC PATCH v4] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-06-10 10:29 UTC (permalink / raw)
To: Jes Sorensen
Cc: Kalle Valo, David Miller, linux-wireless, netdev, Linux Kernel,
Linux Upstreaming Team
In-Reply-To: <CAB4CAwf3Mi2iuR7nAj1U4EoyU5ZnvY9xoLrv7QT2X-tc_1ex3g@mail.gmail.com>
On Wed, Jun 5, 2019 at 10:17 AM Chris Chiu <chiu@endlessm.com> wrote:
>
> On Tue, Jun 4, 2019 at 3:21 AM Jes Sorensen <jes.sorensen@gmail.com> wrote:
> >
> > On 5/31/19 5:12 AM, Chris Chiu wrote:
> > > We have 3 laptops which connect the wifi by the same RTL8723BU.
> > > The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> > > They have the same problem with the in-kernel rtl8xxxu driver, the
> > > iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> > > Nevertheless, the signal strength is reported as around -40dBm,
> > > which is quite good. From the wireshark capture, the tx rate for each
> > > data and qos data packet is only 1Mbps. Compare to the Realtek driver
> > > at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
> > > ~12Mbps or better. The signal strength is reported similarly around
> > > -40dBm. That's why we want to improve.
> > >
> > > After reading the source code of the rtl8xxxu driver and Realtek's, the
> > > major difference is that Realtek's driver has a watchdog which will keep
> > > monitoring the signal quality and updating the rate mask just like the
> > > rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> > > And this kind of watchdog also exists in rtlwifi driver of some specific
> > > chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> > > the same member function named dm_watchdog and will invoke the
> > > corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> > > mask.
> > >
> > > With this commit, the tx rate of each data and qos data packet will
> > > be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
> > > to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> > > the lowest rate from the rate mask and explains why the tx rate of
> > > data and qos data is always lowest 1Mbps because the default rate mask
> > > passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
> > > and MCS rate. However, with Realtek's driver, the tx rate observed from
> > > wireshark under the same condition is almost 65Mbps or 72Mbps.
> > >
> > > I believe the firmware of RTL8723BU may need fix. And I think we
> > > can still bring in the dm_watchdog as rtlwifi to improve from the
> > > driver side. Please leave precious comments for my commits and
> > > suggest what I can do better. Or suggest if there's any better idea
> > > to fix this. Thanks.
> > >
> > > Signed-off-by: Chris Chiu <chiu@endlessm.com>
> >
> > I am really pleased to see you're investigating some of these issues,
> > since I've been pretty swamped and not had time to work on this driver
> > for a long time.
> >
> > The firmware should allow for two rate modes, either firmware handled or
> > controlled by the driver. Ideally we would want the driver to handle it,
> > but I never was able to make that work reliable.
> >
> > This fix should at least improve the situation, and it may explain some
> > of the performance issues with the 8192eu as well?
> >
> > > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> > > index 8828baf26e7b..216f603827a8 100644
> > > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> > > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> > > @@ -1195,6 +1195,44 @@ struct rtl8723bu_c2h {
> > >
> > > struct rtl8xxxu_fileops;
> > >
> > > +/*mlme related.*/
> > > +enum wireless_mode {
> > > + WIRELESS_MODE_UNKNOWN = 0,
> > > + /* Sub-Element */
> > > + WIRELESS_MODE_B = BIT(0),
> > > + WIRELESS_MODE_G = BIT(1),
> > > + WIRELESS_MODE_A = BIT(2),
> > > + WIRELESS_MODE_N_24G = BIT(3),
> > > + WIRELESS_MODE_N_5G = BIT(4),
> > > + WIRELESS_AUTO = BIT(5),
> > > + WIRELESS_MODE_AC = BIT(6),
> > > + WIRELESS_MODE_MAX = 0x7F,
> > > +};
> > > +
> > > +/* from rtlwifi/wifi.h */
> > > +enum ratr_table_mode_new {
> > > + RATEID_IDX_BGN_40M_2SS = 0,
> > > + RATEID_IDX_BGN_40M_1SS = 1,
> > > + RATEID_IDX_BGN_20M_2SS_BN = 2,
> > > + RATEID_IDX_BGN_20M_1SS_BN = 3,
> > > + RATEID_IDX_GN_N2SS = 4,
> > > + RATEID_IDX_GN_N1SS = 5,
> > > + RATEID_IDX_BG = 6,
> > > + RATEID_IDX_G = 7,
> > > + RATEID_IDX_B = 8,
> > > + RATEID_IDX_VHT_2SS = 9,
> > > + RATEID_IDX_VHT_1SS = 10,
> > > + RATEID_IDX_MIX1 = 11,
> > > + RATEID_IDX_MIX2 = 12,
> > > + RATEID_IDX_VHT_3SS = 13,
> > > + RATEID_IDX_BGN_3SS = 14,
> > > +};
> > > +
> > > +#define RTL8XXXU_RATR_STA_INIT 0
> > > +#define RTL8XXXU_RATR_STA_HIGH 1
> > > +#define RTL8XXXU_RATR_STA_MID 2
> > > +#define RTL8XXXU_RATR_STA_LOW 3
> > > +
> >
> > > extern struct rtl8xxxu_fileops rtl8192cu_fops;
> > > extern struct rtl8xxxu_fileops rtl8192eu_fops;
> > > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > > index 26b674aca125..2071ab9fd001 100644
> > > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > > @@ -1645,6 +1645,148 @@ static void rtl8723bu_init_statistics(struct rtl8xxxu_priv *priv)
> > > rtl8xxxu_write32(priv, REG_OFDM0_FA_RSTC, val32);
> > > }
> > >
> > > +static u8 rtl8723b_signal_to_rssi(int signal)
> > > +{
> > > + if (signal < -95)
> > > + signal = -95;
> > > + return (u8)(signal + 95);
> > > +}
> >
> > Could you make this more generic so it can be used by the other sub-drivers?
> >
> Sure. I'll do that.
>
> > > +static void rtl8723b_refresh_rate_mask(struct rtl8xxxu_priv *priv,
> > > + int signal, struct ieee80211_sta *sta)
> > > +{
> > > + struct ieee80211_hw *hw = priv->hw;
> > > + u16 wireless_mode;
> > > + u8 rssi_level, ratr_idx;
> > > + u8 txbw_40mhz;
> > > + u8 rssi, rssi_thresh_high, rssi_thresh_low;
> > > +
> > > + rssi_level = priv->rssi_level;
> > > + rssi = rtl8723b_signal_to_rssi(signal);
> > > + txbw_40mhz = (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40) ? 1 : 0;
> > > +
> > > + switch (rssi_level) {
> > > + case RTL8XXXU_RATR_STA_HIGH:
> > > + rssi_thresh_high = 50;
> > > + rssi_thresh_low = 20;
> > > + break;
> > > + case RTL8XXXU_RATR_STA_MID:
> > > + rssi_thresh_high = 55;
> > > + rssi_thresh_low = 20;
> > > + break;
> > > + case RTL8XXXU_RATR_STA_LOW:
> > > + rssi_thresh_high = 60;
> > > + rssi_thresh_low = 25;
> > > + break;
> > > + default:
> > > + rssi_thresh_high = 50;
> > > + rssi_thresh_low = 20;
> > > + break;
> > > + }
> >
> > Can we make this use defined values with some explanation rather than
> > hard coded values?
> >
>
> I also thought about this. So I refer to the same refresh_rateadaotive_mask
> in rtlwifi/rtl8192se/dm.c, rtlwifi/rtl8723ae/dm.c, and rtl8188ee...etc. They
> don't give a better explanation. And I also don't know if these values can be
> generally applied to other subdrivers or specifically for 8723b series, for
> example, the rtl8192se use different values for the threshold. It maybe due
> to different noise floor for different chip? I'm not sure. I took these values
> from vendor driver and rtl8188ee. I can simply use defined values to replace
> but I have to admit it's hard to find a good explanation.
>
> > > + if (rssi > rssi_thresh_high)
> > > + rssi_level = RTL8XXXU_RATR_STA_HIGH;
> > > + else if (rssi > rssi_thresh_low)
> > > + rssi_level = RTL8XXXU_RATR_STA_MID;
> > > + else
> > > + rssi_level = RTL8XXXU_RATR_STA_LOW;
> > > +
> > > + if (rssi_level != priv->rssi_level) {
> > > + int sgi = 0;
> > > + u32 rate_bitmap = 0;
> > > +
> > > + rcu_read_lock();
> > > + rate_bitmap = (sta->supp_rates[0] & 0xfff) |
> > > + (sta->ht_cap.mcs.rx_mask[0] << 12) |
> > > + (sta->ht_cap.mcs.rx_mask[1] << 20);
> > > + if (sta->ht_cap.cap &
> > > + (IEEE80211_HT_CAP_SGI_40 | IEEE80211_HT_CAP_SGI_20))
> > > + sgi = 1;
> > > + rcu_read_unlock();
> > > +
> > > + wireless_mode = rtl8xxxu_wireless_mode(hw, sta);
> > > + switch (wireless_mode) {
> > > + case WIRELESS_MODE_B:
> > > + ratr_idx = RATEID_IDX_B;
> > > + if (rate_bitmap & 0x0000000c)
> > > + rate_bitmap &= 0x0000000d;
> > > + else
> > > + rate_bitmap &= 0x0000000f;
> > > + break;
> > > + case WIRELESS_MODE_A:
> > > + case WIRELESS_MODE_G:
> > > + ratr_idx = RATEID_IDX_G;
> > > + if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
> > > + rate_bitmap &= 0x00000f00;
> > > + else
> > > + rate_bitmap &= 0x00000ff0;
> > > + break;
> > > + case (WIRELESS_MODE_B | WIRELESS_MODE_G):
> > > + ratr_idx = RATEID_IDX_BG;
> > > + if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
> > > + rate_bitmap &= 0x00000f00;
> > > + else if (rssi_level == RTL8XXXU_RATR_STA_MID)
> > > + rate_bitmap &= 0x00000ff0;
> > > + else
> > > + rate_bitmap &= 0x00000ff5;
> > > + break;
> >
> > It would be nice as well to get all these masks into generic names.
> >
>
> I also take these mask values from the update_hal_rate_mask of the
> vendor driver and other realtek drivers under rtlwifi. I thought about to
> define the lower 12 bits like RTL8XXXU_BG_RATE_MASK, 13~20 bits
> as RTL8XXXU_MCS0_7_RATE_MASK. But it's still hard to express
> all the combinations here. So I just leave it as it is. I can try to add
> explanations for the rate mapping of each bit. It would be a lot easier.
>
> > > + case WIRELESS_MODE_N_24G:
> > > + case WIRELESS_MODE_N_5G:
> > > + case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
> > > + case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G):
> > > + if (priv->tx_paths == 2 && priv->rx_paths == 2)
> > > + ratr_idx = RATEID_IDX_GN_N2SS;
> > > + else
> > > + ratr_idx = RATEID_IDX_GN_N1SS;
> > > + case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
> > > + case (WIRELESS_MODE_B | WIRELESS_MODE_N_24G):
> > > + if (txbw_40mhz) {
> > > + if (priv->tx_paths == 2 && priv->rx_paths == 2)
> > > + ratr_idx = RATEID_IDX_BGN_40M_2SS;
> > > + else
> > > + ratr_idx = RATEID_IDX_BGN_40M_1SS;
> > > + } else {
> > > + if (priv->tx_paths == 2 && priv->rx_paths == 2)
> > > + ratr_idx = RATEID_IDX_BGN_20M_2SS_BN;
> > > + else
> > > + ratr_idx = RATEID_IDX_BGN_20M_1SS_BN;
> > > + }
> > > +
> > > + if (priv->tx_paths == 2 && priv->rx_paths == 2) {
> > > + if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
> > > + rate_bitmap &= 0x0f8f0000;
> > > + } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
> > > + rate_bitmap &= 0x0f8ff000;
> > > + } else {
> > > + if (txbw_40mhz)
> > > + rate_bitmap &= 0x0f8ff015;
> > > + else
> > > + rate_bitmap &= 0x0f8ff005;
> > > + }
> > > + } else {
> > > + if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
> > > + rate_bitmap &= 0x000f0000;
> > > + } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
> > > + rate_bitmap &= 0x000ff000;
> > > + } else {
> > > + if (txbw_40mhz)
> > > + rate_bitmap &= 0x000ff015;
> > > + else
> > > + rate_bitmap &= 0x000ff005;
> > > + }
> > > + }
> > > + break;
> > > + default:
> > > + ratr_idx = RATEID_IDX_BGN_40M_2SS;
> > > + rate_bitmap &= 0x0fffffff;
> > > + break;
> > > + }
> > > +
> > > + priv->rssi_level = rssi_level;
> > > + priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi);
> > > + }
> > > +}
> > > +
> >
> > In general I think all of this should be fairly generic and the other
> > subdrivers should be able to benefit from it?
> >
> >
> I agree. Mabe separates the rssi level judgement function to be chip specific,
> and move the whole refresh_rate_mask thing generic?
>
> > > struct rtl8xxxu_fileops rtl8723bu_fops = {
> > > .parse_efuse = rtl8723bu_parse_efuse,
> > > .load_firmware = rtl8723bu_load_firmware,
> > > @@ -1665,6 +1807,7 @@ struct rtl8xxxu_fileops rtl8723bu_fops = {
> > > .usb_quirks = rtl8xxxu_gen2_usb_quirks,
> > > .set_tx_power = rtl8723b_set_tx_power,
> > > .update_rate_mask = rtl8xxxu_gen2_update_rate_mask,
> > > + .refresh_rate_mask = rtl8723b_refresh_rate_mask,
> > > .report_connect = rtl8xxxu_gen2_report_connect,
> > > .fill_txdesc = rtl8xxxu_fill_txdesc_v2,
> > > .writeN_block_size = 1024,
> > > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > > index 039e5ca9d2e4..be322402ca01 100644
> > > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > > @@ -4311,7 +4311,8 @@ static void rtl8xxxu_sw_scan_complete(struct ieee80211_hw *hw,
> > > rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
> > > }
> > >
> > > -void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
> > > +void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
> > > + u32 ramask, u8 rateid, int sgi)
> > > {
> > > struct h2c_cmd h2c;
> > >
> > > @@ -4331,7 +4332,7 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
> > > }
> > >
> > > void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
> > > - u32 ramask, int sgi)
> > > + u32 ramask, u8 rateid, int sgi)
> > > {
> > > struct h2c_cmd h2c;
> > > u8 bw = 0;
> > > @@ -4345,7 +4346,7 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
> > > h2c.b_macid_cfg.ramask3 = (ramask >> 24) & 0xff;
> > >
> > > h2c.ramask.arg = 0x80;
> > > - h2c.b_macid_cfg.data1 = 0;
> > > + h2c.b_macid_cfg.data1 = rateid;
> > > if (sgi)
> > > h2c.b_macid_cfg.data1 |= BIT(7);
> > >
> > > @@ -4485,6 +4486,40 @@ static void rtl8xxxu_set_basic_rates(struct rtl8xxxu_priv *priv, u32 rate_cfg)
> > > rtl8xxxu_write8(priv, REG_INIRTS_RATE_SEL, rate_idx);
> > > }
> > >
> > > +u16
> > > +rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
> > > +{
> > > + u16 network_type = WIRELESS_MODE_UNKNOWN;
> > > + u32 rate_mask;
> > > +
> > > + rate_mask = (sta->supp_rates[0] & 0xfff) |
> > > + (sta->ht_cap.mcs.rx_mask[0] << 12) |
> > > + (sta->ht_cap.mcs.rx_mask[0] << 20);
> > > +
> > > + if (hw->conf.chandef.chan->band == NL80211_BAND_5GHZ) {
> > > + if (sta->vht_cap.vht_supported)
> > > + network_type = WIRELESS_MODE_AC;
> > > + else if (sta->ht_cap.ht_supported)
> > > + network_type = WIRELESS_MODE_N_5G;
> > > +
> > > + network_type |= WIRELESS_MODE_A;
> > > + } else {
> > > + if (sta->vht_cap.vht_supported)
> > > + network_type = WIRELESS_MODE_AC;
> > > + else if (sta->ht_cap.ht_supported)
> > > + network_type = WIRELESS_MODE_N_24G;
> > > +
> > > + if (sta->supp_rates[0] <= 0xf)
> > > + network_type |= WIRELESS_MODE_B;
> > > + else if (sta->supp_rates[0] & 0xf)
> > > + network_type |= (WIRELESS_MODE_B | WIRELESS_MODE_G);
> > > + else
> > > + network_type |= WIRELESS_MODE_G;
> > > + }
> > > +
> > > + return network_type;
> > > +}
> >
> > I always hated the wireless_mode nonsense in the realtek driver, but
> > maybe we cannot avoid it :(
> >
> > Cheers,
> > Jes
Jes, look forward to any comments or suggestions from you. I would re-write a
patch with generic refresh_rate_mask for all rtl8xxxu series chips in
short time.
Chris
^ permalink raw reply
* [PATCH v3] ath10k: Enable MSA region dump support for WCN3990
From: Govind Singh @ 2019-06-10 9:17 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Govind Singh
MSA memory region caries the hw descriptors information.
Dump MSA region in core dump as this is very helpful in debugging
hw issues.
Testing: Tested on WCN3990 HW
Tested FW: WLAN.HL.3.1-00959-QCAHLSWMTPLZ-1
Signed-off-by: Govind Singh <govinds@codeaurora.org>
---
Changes from v2:
- Rebased on top of 38faed150438 ath10k: perform crash dump collection in workqueue.
- Removed redundant msa permission call.
---
drivers/net/wireless/ath/ath10k/coredump.c | 21 +++++++
drivers/net/wireless/ath/ath10k/coredump.h | 1 +
drivers/net/wireless/ath/ath10k/qmi.c | 4 ++
drivers/net/wireless/ath/ath10k/snoc.c | 66 ++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/snoc.h | 1 +
5 files changed, 93 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/coredump.c b/drivers/net/wireless/ath/ath10k/coredump.c
index aa04fbf146e0..0ec690b49fb1 100644
--- a/drivers/net/wireless/ath/ath10k/coredump.c
+++ b/drivers/net/wireless/ath/ath10k/coredump.c
@@ -962,6 +962,19 @@ static const struct ath10k_mem_region qca4019_hw10_mem_regions[] = {
},
};
+static const struct ath10k_mem_region wcn399x_hw10_mem_regions[] = {
+ {
+ /* MSA region start is not fixed, hence it is assigned at runtime */
+ .type = ATH10K_MEM_REGION_TYPE_MSA,
+ .len = 0x100000,
+ .name = "DRAM",
+ .section_table = {
+ .sections = NULL,
+ .size = 0,
+ },
+ },
+};
+
static const struct ath10k_hw_mem_layout hw_mem_layouts[] = {
{
.hw_id = QCA6174_HW_1_0_VERSION,
@@ -1059,6 +1072,14 @@ static const struct ath10k_hw_mem_layout hw_mem_layouts[] = {
.size = ARRAY_SIZE(qca4019_hw10_mem_regions),
},
},
+ {
+ .hw_id = WCN3990_HW_1_0_DEV_VERSION,
+ .hw_rev = ATH10K_HW_WCN3990,
+ .region_table = {
+ .regions = wcn399x_hw10_mem_regions,
+ .size = ARRAY_SIZE(wcn399x_hw10_mem_regions),
+ },
+ },
};
static u32 ath10k_coredump_get_ramdump_size(struct ath10k *ar)
diff --git a/drivers/net/wireless/ath/ath10k/coredump.h b/drivers/net/wireless/ath/ath10k/coredump.h
index 5dac653e1649..9802e90483f4 100644
--- a/drivers/net/wireless/ath/ath10k/coredump.h
+++ b/drivers/net/wireless/ath/ath10k/coredump.h
@@ -126,6 +126,7 @@ enum ath10k_mem_region_type {
ATH10K_MEM_REGION_TYPE_IRAM2 = 5,
ATH10K_MEM_REGION_TYPE_IOSRAM = 6,
ATH10K_MEM_REGION_TYPE_IOREG = 7,
+ ATH10K_MEM_REGION_TYPE_MSA = 8,
};
/* Define a section of the region which should be copied. As not all parts
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index ba8f5a8f83d1..8eb0f0f0d3a7 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -817,9 +817,13 @@ ath10k_qmi_driver_event_post(struct ath10k_qmi *qmi,
static void ath10k_qmi_event_server_exit(struct ath10k_qmi *qmi)
{
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
ath10k_qmi_remove_msa_permission(qmi);
ath10k_core_free_board_files(ar);
+ if (!test_bit(ATH10K_SNOC_FLAG_UNREGISTERING, &ar_snoc->flags))
+ ath10k_snoc_fw_crashed_dump(ar);
+
ath10k_snoc_fw_indication(ar, ATH10K_QMI_EVENT_FW_DOWN_IND);
ath10k_dbg(ar, ATH10K_DBG_QMI, "wifi fw qmi service disconnected\n");
}
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index 0be12996beba..ecc0f884b123 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -24,6 +24,7 @@
#include <linux/regulator/consumer.h>
#include "ce.h"
+#include "coredump.h"
#include "debug.h"
#include "hif.h"
#include "htc.h"
@@ -1586,6 +1587,71 @@ static int ath10k_hw_power_off(struct ath10k *ar)
return ret;
}
+static void ath10k_msa_dump_memory(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
+ const struct ath10k_hw_mem_layout *mem_layout;
+ const struct ath10k_mem_region *current_region;
+ struct ath10k_dump_ram_data_hdr *hdr;
+ size_t buf_len;
+ u8 *buf;
+
+ if (!crash_data && !crash_data->ramdump_buf)
+ return;
+
+ mem_layout = ath10k_coredump_get_mem_layout(ar);
+ if (!mem_layout)
+ return;
+
+ current_region = &mem_layout->region_table.regions[0];
+
+ buf = crash_data->ramdump_buf;
+ buf_len = crash_data->ramdump_buf_len;
+ memset(buf, 0, buf_len);
+
+ /* Reserve space for the header. */
+ hdr = (void *)buf;
+ buf += sizeof(*hdr);
+ buf_len -= sizeof(*hdr);
+
+ hdr->region_type = cpu_to_le32(current_region->type);
+ hdr->start = cpu_to_le32(ar_snoc->qmi->msa_va);
+ hdr->length = cpu_to_le32(ar_snoc->qmi->msa_mem_size);
+
+ if (current_region->len < ar_snoc->qmi->msa_mem_size) {
+ memcpy(buf, ar_snoc->qmi->msa_va, current_region->len);
+ ath10k_warn(ar, "msa dump length is less than msa size %x, %x\n",
+ current_region->len, ar_snoc->qmi->msa_mem_size);
+ } else {
+ memcpy(buf, ar_snoc->qmi->msa_va, ar_snoc->qmi->msa_mem_size);
+ }
+}
+
+void ath10k_snoc_fw_crashed_dump(struct ath10k *ar)
+{
+ struct ath10k_fw_crash_data *crash_data;
+ char guid[UUID_STRING_LEN + 1];
+
+ mutex_lock(&ar->dump_mutex);
+
+ spin_lock_bh(&ar->data_lock);
+ ar->stats.fw_crash_counter++;
+ spin_unlock_bh(&ar->data_lock);
+
+ crash_data = ath10k_coredump_new(ar);
+
+ if (crash_data)
+ scnprintf(guid, sizeof(guid), "%pUl", &crash_data->guid);
+ else
+ scnprintf(guid, sizeof(guid), "n/a");
+
+ ath10k_err(ar, "firmware crashed! (guid %s)\n", guid);
+ ath10k_print_driver_info(ar);
+ ath10k_msa_dump_memory(ar, crash_data);
+ mutex_unlock(&ar->dump_mutex);
+}
+
static const struct of_device_id ath10k_snoc_dt_match[] = {
{ .compatible = "qcom,wcn3990-wifi",
.data = &drv_priv,
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index 25383de8f17d..6d28a6290a94 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -101,5 +101,6 @@ static inline struct ath10k_snoc *ath10k_snoc_priv(struct ath10k *ar)
}
int ath10k_snoc_fw_indication(struct ath10k *ar, u64 type);
+void ath10k_snoc_fw_crashed_dump(struct ath10k *ar);
#endif /* _SNOC_H_ */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* RE: [PATCH v3 3/5] brcmfmac: sdio: Disable auto-tuning around commands expected to fail
From: Hunter, Adrian @ 2019-06-10 8:56 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Kalle Valo, Arend van Spriel
Cc: brcm80211-dev-list.pdl@broadcom.com,
linux-rockchip@lists.infradead.org, Double Lo,
briannorris@chromium.org, linux-wireless@vger.kernel.org,
Naveen Gupta, Madhan Mohan R, mka@chromium.org, Wright Feng,
Chi-Hsien Lin, netdev@vger.kernel.org,
brcm80211-dev-list@cypress.com, Franky Lin,
linux-kernel@vger.kernel.org, Madhan Mohan R, Hante Meuleman,
YueHaibing, David S. Miller
In-Reply-To: <20190607223716.119277-4-dianders@chromium.org>
> -----Original Message-----
> From: Douglas Anderson [mailto:dianders@chromium.org]
> Sent: Saturday, June 8, 2019 1:37 AM
> To: Ulf Hansson <ulf.hansson@linaro.org>; Kalle Valo
> <kvalo@codeaurora.org>; Hunter, Adrian <adrian.hunter@intel.com>; Arend
> van Spriel <arend.vanspriel@broadcom.com>
> Cc: brcm80211-dev-list.pdl@broadcom.com; linux-
> rockchip@lists.infradead.org; Double Lo <double.lo@cypress.com>;
> briannorris@chromium.org; linux-wireless@vger.kernel.org; Naveen Gupta
> <naveen.gupta@cypress.com>; Madhan Mohan R
> <madhanmohan.r@cypress.com>; mka@chromium.org; Wright Feng
> <wright.feng@cypress.com>; Chi-Hsien Lin <chi-hsien.lin@cypress.com>;
> netdev@vger.kernel.org; brcm80211-dev-list@cypress.com; Douglas
> Anderson <dianders@chromium.org>; Franky Lin
> <franky.lin@broadcom.com>; linux-kernel@vger.kernel.org; Madhan Mohan
> R <MadhanMohan.R@cypress.com>; Hante Meuleman
> <hante.meuleman@broadcom.com>; YueHaibing
> <yuehaibing@huawei.com>; David S. Miller <davem@davemloft.net>
> Subject: [PATCH v3 3/5] brcmfmac: sdio: Disable auto-tuning around
> commands expected to fail
>
> There are certain cases, notably when transitioning between sleep and active
> state, when Broadcom SDIO WiFi cards will produce errors on the SDIO bus.
> This is evident from the source code where you can see that we try
> commands in a loop until we either get success or we've tried too many
> times. The comment in the code reinforces this by saying "just one write
> attempt may fail"
>
> Unfortunately these failures sometimes end up causing an "-EILSEQ"
> back to the core which triggers a retuning of the SDIO card and that blocks all
> traffic to the card until it's done.
>
> Let's disable retuning around the commands we expect might fail.
>
> Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> Changes in v3:
> - Expect errors for all of brcmf_sdio_kso_control() (Adrian).
>
> Changes in v2: None
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index 4a750838d8cd..4040aae1f9ed 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -16,6 +16,7 @@
> #include <linux/mmc/sdio_ids.h>
> #include <linux/mmc/sdio_func.h>
> #include <linux/mmc/card.h>
> +#include <linux/mmc/core.h>
SDIO function drivers should not really include linux/mmc/core.h
(Also don't know why linux/mmc/card.h is included)
> #include <linux/semaphore.h>
> #include <linux/firmware.h>
> #include <linux/module.h>
> @@ -667,6 +668,8 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool
> on)
>
> brcmf_dbg(TRACE, "Enter: on=%d\n", on);
>
> + mmc_expect_errors_begin(bus->sdiodev->func1->card->host);
> +
> wr_val = (on << SBSDIO_FUNC1_SLEEPCSR_KSO_SHIFT);
> /* 1st KSO write goes to AOS wake up core if device is asleep */
> brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR,
> wr_val, &err); @@ -727,6 +730,8 @@ brcmf_sdio_kso_control(struct
> brcmf_sdio *bus, bool on)
> if (try_cnt > MAX_KSO_ATTEMPTS)
> brcmf_err("max tries: rd_val=0x%x err=%d\n", rd_val, err);
>
> + mmc_expect_errors_end(bus->sdiodev->func1->card->host);
> +
> return err;
> }
>
> --
> 2.22.0.rc2.383.gf4fbbf30c2-goog
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
From: Tony Lindgren @ 2019-06-10 8:30 UTC (permalink / raw)
To: Kalle Valo
Cc: Eugeniu Rosca, Geert Uytterhoeven, Simon Horman, David S. Miller,
Greg Kroah-Hartman, Randy Dunlap, Ulf Hansson, John Stultz,
linux-wireless, netdev, linux-kernel, Spyridon Papageorgiou,
Joshua Frkuska, George G . Davis, Andrey Gusakov, Linux-Renesas,
Eugeniu Rosca, eyalr
In-Reply-To: <87tvcxncuq.fsf@codeaurora.org>
Hi,
* Kalle Valo <kvalo@codeaurora.org> [190610 07:01]:
> Eugeniu Rosca <erosca@de.adit-jv.com> writes:
>
> > The wl1837mod datasheet [1] says about the WL_IRQ pin:
> >
> > ---8<---
> > SDIO available, interrupt out. Active high. [..]
> > Set to rising edge (active high) on powerup.
> > ---8<---
> >
> > That's the reason of seeing the interrupt configured as:
> > - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> > - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
> >
> > We assert that all those platforms have the WL_IRQ pin connected
> > to the SoC _directly_ (confirmed on HiKey 970 [2]).
> >
> > That's not the case for R-Car Kingfisher extension target, which carries
> > a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> > between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> > reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> > configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> > IRQ_TYPE_LEVEL_LOW.
> >
> > Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> > support platform dependent interrupt types") made a special case out
> > of these interrupt types. After this commit, it is impossible to provide
> > an IRQ configuration via DTS which would describe an inverter present
> > between the WL18* chip and the SoC, generating the need for workarounds
> > like [3].
> >
> > Create a boolean OF property, called "invert-irq" to specify that
> > the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
> >
> > This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> > the DTS configuration [4] combined with the "invert-irq" property.
> >
> > [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> > [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> > [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
> > [4] https://patchwork.kernel.org/patch/10895879/
> > ("arm64: dts: ulcb-kf: Add support for TI WL1837")
> >
> > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>
> Tony&Eyal, do you agree with this?
Yeah if there's some hardware between the WLAN device and the SoC
inverting the interrupt, I don't think we have clear a way to deal
with it short of setting up a separate irqchip that does the
translation.
But in some cases we also do not want to invert the interrupt, so
I think this property should take IRQ_TYPE_EDGE_RISING and
IRQ_TYPE_EDGE_RISING values to override the setting for
the WLAN end of the hardware?
Let's wait a bit longer for comments from Eyal too.
Regards,
Tony
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Christoph Hellwig @ 2019-06-10 8:18 UTC (permalink / raw)
To: Larry Finger
Cc: Christoph Hellwig, Aaro Koskinen, Christian Zigotzky,
Michael Ellerman, linux-kernel, linux-wireless, linuxppc-dev
In-Reply-To: <30000803-3772-3edf-f4a9-55122d504f3f@lwfinger.net>
On Sat, Jun 08, 2019 at 04:52:24PM -0500, Larry Finger wrote:
> On 6/7/19 12:29 PM, Christoph Hellwig wrote:
>> I don't think we should work around this in the driver, we need to fix
>> it in the core. I'm curious why my previous patch didn't work. Can
>> you throw in a few printks what failed? I.e. did dma_direct_supported
>> return false? Did the actual allocation fail?
>
> Routine dma_direct_supported() returns true.
>
> The failure is in routine dma_set_mask() in the following if test:
>
> if (!dev->dma_mask || !dma_supported(dev, mask))
> return -EIO;
>
> For b43legacy, dev->dma_mask is 0xc265684800000000.
> dma_supported(dev, mask) is 0xc08b000000000000, mask is 0x3fffffff, and
> the routine returns -EIO.
>
> For b43, dev->dma_mask is 0xc265684800000001,
> dma_supported(dev, mask) is 0xc08b000000000000, mask is 0x77777777, and
> the routine returns 0.
I don't fully understand what values the above map to. Can you send
me your actual debugging patch as well?
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Ryder Lee @ 2019-06-10 7:12 UTC (permalink / raw)
To: Sebastian Gottschall
Cc: Sean Wang, Chih-Min Chen, YF Luo, linux-wireless, linux-kernel,
Yiwei Chung, linux-mediatek, Roy Luo, Lorenzo Bianconi,
Felix Fietkau
In-Reply-To: <64662021-8e5a-91b5-9afb-3c9005564d19@newmedia-net.de>
On Mon, 2019-06-10 at 06:47 +0200, Sebastian Gottschall wrote:
> okay. curious is, that my variant works with sane results too.
> i will test your variant and check the results
>
> Sebastian
Please don't top post as it's hard to track the thread.
More specifically, IBRSSI is obtained from packet's L-STF portion and
MTK HW PD (packet detection) will take it as a reference. (with
variation more or less)
As for RCPI which is calculated from packet's data portion. The other
MTK chipsets may use IBRSSI as their baseband couldn't report RCPI.
Ryder
> Am 10.06.2019 um 06:22 schrieb Ryder Lee:
> > On Mon, 2019-06-10 at 10:09 +0800, Ryder Lee wrote:
> >> On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
> >>> according to my findings
> >>>
> >>> MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
> >>> so it must be rxdg4 = rxd[4] etc.
> >> RXV start from 1 in the code.
> >>
> >> That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
> >>
> >>> however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal calculation.
> >>> i already wrote a similar code for this driver which i sended to felix a long time ago.
> >>> my variant looks like
> >>> status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 2;
> >>> status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 220) / 2;
> >>> status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 220) / 2;
> >>> status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 220) / 2;
> >>> status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 220) / 2;
> > mt7615 actually doesn't use in-band RSSI for signal calculation, but it
> > occurs to me that i should modify the code to compare per-chain's
> > signal. Something like this:
> >
> > status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
> > status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
> > status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
> > status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
> > status->signal = status->chain_signal[0];
> >
> > switch (status->chains) {
> > case 0xf:
> > status->signal = max(status->signal,
> > status->chain_signal[3]);
> > case 0x7:
> > status->signal = max(status->signal,
> > status->chain_signal[2]);
> > case 0x3:
> > status->signal = max(status->signal,
> > status->chain_signal[1]);
> > break;
> > default:
> > break;
> > }
> >
> >
> > I could send a v2 or you can take care of that.
> >
> > Ryder
> >
> >
^ permalink raw reply
* Re: [PATCH] carl9170: fix enum compare splat
From: Kalle Valo @ 2019-06-10 7:06 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <20190608144947.744-1-chunkeey@gmail.com>
Christian Lamparter <chunkeey@gmail.com> writes:
> This patch fixes a noisy warning triggered by -Wenum-compare
>
> |main.c:1390:31: warning: comparison between ‘enum nl80211_ac’
> | and ‘enum ar9170_txq’ [-Wenum-compare]
> | BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> | ^
> | [...]
>
> This is a little bit unfortunate, since the number of queues
> (hence NL80211_NUM_ACS) is a constant based on the IEEE 802.11
> (much like IEEE80211_NUM_ACS) and __AR9170_NUM_TXQ is more or
> less defined by the AR9170 hardware.
Is the warning enabled by default? TBH I'm not seeing how useful this
warning is for kernel development.
> --- a/drivers/net/wireless/ath/carl9170/main.c
> +++ b/drivers/net/wireless/ath/carl9170/main.c
> @@ -1387,7 +1387,7 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
> int ret;
>
> BUILD_BUG_ON(ARRAY_SIZE(ar9170_qmap) != __AR9170_NUM_TXQ);
> - BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> + BUILD_BUG_ON((size_t)NL80211_NUM_ACS > (size_t)__AR9170_NUM_TXQ);
IMHO this just makes the code worse. Does it make sense to workaround
(stupid) compiler warnings like this?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
From: Kalle Valo @ 2019-06-10 7:01 UTC (permalink / raw)
To: Eugeniu Rosca
Cc: Geert Uytterhoeven, Simon Horman, David S. Miller,
Greg Kroah-Hartman, Randy Dunlap, Tony Lindgren, Ulf Hansson,
John Stultz, linux-wireless, netdev, linux-kernel,
Spyridon Papageorgiou, Joshua Frkuska, George G . Davis,
Andrey Gusakov, Linux-Renesas, Eugeniu Rosca, eyalr
In-Reply-To: <20190607172958.20745-1-erosca@de.adit-jv.com>
Eugeniu Rosca <erosca@de.adit-jv.com> writes:
> The wl1837mod datasheet [1] says about the WL_IRQ pin:
>
> ---8<---
> SDIO available, interrupt out. Active high. [..]
> Set to rising edge (active high) on powerup.
> ---8<---
>
> That's the reason of seeing the interrupt configured as:
> - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
>
> We assert that all those platforms have the WL_IRQ pin connected
> to the SoC _directly_ (confirmed on HiKey 970 [2]).
>
> That's not the case for R-Car Kingfisher extension target, which carries
> a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> IRQ_TYPE_LEVEL_LOW.
>
> Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> support platform dependent interrupt types") made a special case out
> of these interrupt types. After this commit, it is impossible to provide
> an IRQ configuration via DTS which would describe an inverter present
> between the WL18* chip and the SoC, generating the need for workarounds
> like [3].
>
> Create a boolean OF property, called "invert-irq" to specify that
> the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
>
> This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> the DTS configuration [4] combined with the "invert-irq" property.
>
> [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
> [4] https://patchwork.kernel.org/patch/10895879/
> ("arm64: dts: ulcb-kf: Add support for TI WL1837")
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Tony&Eyal, do you agree with this?
--
Kalle Valo
^ permalink raw reply
* Re: Should b44_init lead to WARN_ON in drivers/ssb/driver_gpio.c:464?
From: Michael Büsch @ 2019-06-10 6:51 UTC (permalink / raw)
To: H Buus; +Cc: Larry Finger, Kalle Valo, Michael Chan, linux-wireless, netdev
In-Reply-To: <a7c07ad7-1ca2-c16d-4082-6ddc9325a20d@hbuus.com>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Mon, 10 Jun 2019 01:40:17 -0400
H Buus <ubuntu@hbuus.com> wrote:
> Unless I get lucky and figure
> out what commit is making newer kernels unstable on this laptop.
You can use 'git bisect' to quickly find a commit that breaks something.
I'll prepare a patch to get rid of the warning asap.
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: iwlwifi module crash
From: Emmanuel Grumbach @ 2019-06-10 6:50 UTC (permalink / raw)
To: Balakrishnan Balasubramanian; +Cc: linux-wireless
In-Reply-To: <2696773.yqXG4m880n@zadesk>
On Fri, Jun 7, 2019 at 2:41 PM Balakrishnan Balasubramanian
<linux-wireless-list@balki.me> wrote:
>
> > This is because the device is removed from the PCI bus. Nothing from
> > iwlwifi side can be done.
>
> I am sure the device is not physically disturbed. If that was the case, should it not stay down when restarting the system?
Not necessarily. The disturbance may impact ASPM or something alike.
>
> > If that happens upon suspend / resume, I know there are been fixes in
> > PCI bus driver.
>
> To my knowledge I have disabled all power/suspend features and I don't see releated logs in journal except the below. Not sure if relevant.
>
> Jun 03 21:33:14 zadesk kernel: wlan0: Limiting TX power to 14 (17 - 3) dBm as advertised by d4:5d:df:25:ee:90
>
> Is there a way to restart the module safely without restarting the system?
echo 1 > /sys/module/iwlwifi/devices/0000\:02\:00.0/remove
echo 1 > /sys/bus/pci/rescan
>
> Regards,
> Bala
>
>
> On Friday, June 7, 2019 5:25:41 AM EDT Emmanuel Grumbach wrote:
> > On Fri, Jun 7, 2019 at 5:22 AM Balakrishnan Balasubramanian
> >
> > <linux-wireless-list@balki.me> wrote:
> > > I am using iwd demon for wifi. Once a while I loose connectivity.
> > > Restarting the demon does not help. But once I restart the system, it
> > > starts working fine. Attaching stack trace from journal.
> >
> > This is because the device is removed from the PCI bus. Nothing from
> > iwlwifi side can be done.
> > If that happens upon suspend / resume, I know there are been fixes in
> > PCI bus driver. If not, check that the device sits correctly in its
> > socket.
> >
> > > Regards,
> > > Bala
> > >
> > >
> > > ---------- Forwarded message ----------
> > > From: Denis Kenzior <denkenz@gmail.com>
> > > To: Balakrishnan Balasubramanian <iwd-lists@balki.me>, iwd@lists.01.org
> > > Cc:
> > > Bcc:
> > > Date: Thu, 06 Jun 2019 18:07:40 -0500
> > > Subject: Re: iwd crashes randomly
> > > Hi Bala,
> > >
> > > On 06/06/2019 06:00 PM, Balakrishnan Balasubramanian wrote:
> > > > Sometimes after a week and sometimes after two days. Once crashed,
> > > > restarting the service does not help. Had to restart the computer.
> > > > Attaching stack trace from journal.
> > >
> > > That implies that your kernel is crashing, not iwd. The attached log
> > > shows a kernel stack trace somewhere inside iwlwifi module. I would
> > > post this trace to linux-wireless@vger.kernel.org.
> > >
> > > If you have an associated iwd backtrace, then certainly post this here,
> > > but if the kernel module is crashing, there isn't much we can do.
> > >
> > > Regards,
> > > -Denis
>
>
>
>
^ permalink raw reply
* How to debug/show status of intel wifi card?
From: Tetsuji Rai @ 2019-06-10 6:22 UTC (permalink / raw)
To: linux-wireless
Hi all,
I installed kernel-5.2-rc4 and found my intel wireless-ac 7260 card
stops working a moment (some seconds or minutes) after some browsing on
chrome or receiving emails on thunderbird or any other file transfer.
After turning the wifi off and on again, it starts working again, a
short while. It doesn't happen with the stable kernel 5.1.8.
I filed it bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=203851
but I still can't grasp the status of my wifi card while it's locked.
ifconfig, iwconfig, ethtool, trace-cmd show nothing abnormal even when
the wifi card is locked. They say my wifi card detects radio signal
correctly, transfer mode is correct.
So will you tell me how to see what happens with my wifi card? It
should be something like a bug of the new kernel.
Thanks in advance!
-Tetsuji Rai
^ permalink raw reply
* Re: Should b44_init lead to WARN_ON in drivers/ssb/driver_gpio.c:464?
From: H Buus @ 2019-06-10 5:40 UTC (permalink / raw)
To: Larry Finger, Michael Büsch
Cc: Kalle Valo, Michael Chan, linux-wireless, netdev
In-Reply-To: <4fdd3b06-f3f7-87e0-93be-c5d6f2bf5ab4@lwfinger.net>
On 6/9/2019 8:13 PM, Larry Finger wrote:
> On 6/9/19 4:57 PM, Michael Büsch wrote:
>> On Sun, 9 Jun 2019 17:44:10 -0400
>> H Buus <ubuntu@hbuus.com> wrote:
>>
>>> I have an old 32 bit laptop with a BCM4401-B0 100Base-TX ethernet
>>> controller. For every kernel from 4.19-rc1 going forward, I get a
>>> warning and call trace within a few seconds of start up (see dmesg
>>> snippet below). I have traced it to a specific commit (see commit
>>> below). On the face of it, I would think it is a regression, but it
>>> doesn't seem to cause a problem, since networking over ethernet is
>>> working.
>>
>>
>> This warning is not a problem. The commit just exposes a warning, that
>> has always been there.
>> I suggest we just remove the WARN_ON from ssb_gpio_init and
>> ssb_gpio_unregister.
>> I don't see a reason to throw a warning in that case.
>
> Michael,
>
> I agree. Do you want to prepare the patch, or should I?
>
> Larry
Let me know if you would like me to verify a patch when/if it is
available. Since kernels 4.19 thru 5.1 are unstable on this laptop, I
would either need to test with a 4.18 or older kernel, or limit my
testing to recovery mode & verifying that the b44 module is initialized
without causing a warning & call trace. Unless I get lucky and figure
out what commit is making newer kernels unstable on this laptop.
^ permalink raw reply
* possible fix for broken cmac crypto support
From: Sebastian Gottschall @ 2019-06-10 5:11 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Ryder Lee, Felix Fietkau, Roy Luo, YF Luo, Yiwei Chung, Sean Wang,
Chih-Min Chen, linux-wireless, linux-mediatek,
Linux Kernel Mailing List
In-Reply-To: <0eea6d21-1de2-abc3-93f4-70ed04dac3df@newmedia-net.de>
this is no real patch for this mailing list since i havent cloned yet a
git tree. take it as a hint
this fixes the BUG WARN if SAE encryption is used (mandatory for mesh /
802.11s crypto)
that will not fix that mesh is not working (likelly just with other
vendors), but it will fix crypto at least
Sebastian
Index: main.c
===================================================================
--- main.c (revision 4584)
+++ main.c (revision 4585)
@@ -180,6 +180,20 @@ static int mt7615_set_key(struct ieee80211_hw *hw,
!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
return -EOPNOTSUPP;
+ switch (key->cipher) {
+ case WLAN_CIPHER_SUITE_WEP40:
+ case WLAN_CIPHER_SUITE_WEP104:
+ case WLAN_CIPHER_SUITE_TKIP:
+ case WLAN_CIPHER_SUITE_CCMP:
+ case WLAN_CIPHER_SUITE_CCMP_256:
+ case WLAN_CIPHER_SUITE_GCMP:
+ case WLAN_CIPHER_SUITE_GCMP_256:
+ case WLAN_CIPHER_SUITE_SMS4:
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
if (cmd == SET_KEY) {
key->hw_key_idx = wcid->idx;
wcid->hw_key_idx = idx;
Am 09.06.2019 um 16:36 schrieb Sebastian Gottschall:
> by the way. this big fat kernel warning exists in all operation modes
> unless anything else but aes-128 ccmp is used. since the chipset is
> capable of doing gcmp etc. as well
> it would be nice if this issue can be fixed. otherwise encryption
> support can be defined as "broken" for mt7615
>
> Am 06.06.2019 um 18:19 schrieb Lorenzo Bianconi:
>>> i tested your patch against a qca 9984 chipset using SAE and without
>>> encryption. both did not work. the devices are connecting, but no data
>>> connection is possible
>> Hi Sebastian,
>>
>> I tested Ryder's patch using mt76x2 as mesh peer and it works fine
>> for me.
>> Could you please provide some more info?
>>
>> Regards,
>> Lorenzo
>>
>>>
>>> Sebastian
>>>
>>> Am 03.06.2019 um 08:08 schrieb Ryder Lee:
>>>> Enable NL80211_IFTYPE_MESH_POINT and update its path.
>>>>
>>>> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>>>> ---
>>>> Changes since v3 - fix a wrong expression
>>>> Changes since v2 - remove unused definitions
>>>> ---
>>>> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
>>>> drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
>>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 4 +++-
>>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
>>>> 4 files changed, 10 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>>> b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>>> index 59f604f3161f..f860af6a42da 100644
>>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>>> @@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit
>>>> if_limits[] = {
>>>> {
>>>> .max = MT7615_MAX_INTERFACES,
>>>> .types = BIT(NL80211_IFTYPE_AP) |
>>>> +#ifdef CONFIG_MAC80211_MESH
>>>> + BIT(NL80211_IFTYPE_MESH_POINT) |
>>>> +#endif
>>>> BIT(NL80211_IFTYPE_STATION)
>>>> }
>>>> };
>>>> @@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
>>>> dev->mt76.antenna_mask = 0xf;
>>>>
>>>> wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
>>>> +#ifdef CONFIG_MAC80211_MESH
>>>> + BIT(NL80211_IFTYPE_MESH_POINT) |
>>>> +#endif
>>>> BIT(NL80211_IFTYPE_AP);
>>>>
>>>> ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
>>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>>> b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>>> index b0bb7cc12385..585e67fa2728 100644
>>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>>> @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type,
>>>> u32 mask)
>>>>
>>>> switch (type) {
>>>> case NL80211_IFTYPE_AP:
>>>> + case NL80211_IFTYPE_MESH_POINT:
>>>> /* ap use hw bssid 0 and ext bssid */
>>>> if (~mask & BIT(HW_BSSID_0))
>>>> return HW_BSSID_0;
>>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>>> b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>>> index 43f70195244c..e82297048449 100644
>>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>>> @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev
>>>> *dev,
>>>>
>>>> switch (vif->type) {
>>>> case NL80211_IFTYPE_AP:
>>>> + case NL80211_IFTYPE_MESH_POINT:
>>>> tx_wlan_idx = mvif->sta.wcid.idx;
>>>> conn_type = CONNECTION_INFRA_AP;
>>>> break;
>>>> @@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev,
>>>> struct ieee80211_vif *vif,
>>>> .rx_wtbl = {
>>>> .tag = cpu_to_le16(WTBL_RX),
>>>> .len = cpu_to_le16(sizeof(struct wtbl_rx)),
>>>> - .rca1 = vif->type != NL80211_IFTYPE_AP,
>>>> + .rca1 = vif->type == NL80211_IFTYPE_STATION,
>>>> .rca2 = 1,
>>>> .rv = 1,
>>>> },
>>>> @@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum
>>>> nl80211_iftype type, u32 *conn_type)
>>>> {
>>>> switch (type) {
>>>> case NL80211_IFTYPE_AP:
>>>> + case NL80211_IFTYPE_MESH_POINT:
>>>> if (conn_type)
>>>> *conn_type = CONNECTION_INFRA_STA;
>>>> break;
>>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>>> b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>>> index e96efb13fa4d..0915cb735699 100644
>>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>>> @@ -105,25 +105,19 @@ enum {
>>>> #define STA_TYPE_STA BIT(0)
>>>> #define STA_TYPE_AP BIT(1)
>>>> #define STA_TYPE_ADHOC BIT(2)
>>>> -#define STA_TYPE_TDLS BIT(3)
>>>> #define STA_TYPE_WDS BIT(4)
>>>> #define STA_TYPE_BC BIT(5)
>>>>
>>>> #define NETWORK_INFRA BIT(16)
>>>> #define NETWORK_P2P BIT(17)
>>>> #define NETWORK_IBSS BIT(18)
>>>> -#define NETWORK_MESH BIT(19)
>>>> -#define NETWORK_BOW BIT(20)
>>>> #define NETWORK_WDS BIT(21)
>>>>
>>>> #define CONNECTION_INFRA_STA (STA_TYPE_STA | NETWORK_INFRA)
>>>> #define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
>>>> #define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
>>>> #define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
>>>> -#define CONNECTION_MESH_STA (STA_TYPE_STA | NETWORK_MESH)
>>>> -#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
>>>> #define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
>>>> -#define CONNECTION_TDLS (STA_TYPE_STA | NETWORK_INFRA
>>>> | STA_TYPE_TDLS)
>>>> #define CONNECTION_WDS (STA_TYPE_WDS | NETWORK_WDS)
>>>> #define CONNECTION_INFRA_BC (STA_TYPE_BC | NETWORK_INFRA)
>>>>
>
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Sebastian Gottschall @ 2019-06-10 4:47 UTC (permalink / raw)
To: Ryder Lee
Cc: Sean Wang, Chih-Min Chen, YF Luo, linux-wireless, linux-kernel,
Yiwei Chung, linux-mediatek, Roy Luo, Lorenzo Bianconi,
Felix Fietkau
In-Reply-To: <1560140541.5606.12.camel@mtkswgap22>
okay. curious is, that my variant works with sane results too.
i will test your variant and check the results
Sebastian
Am 10.06.2019 um 06:22 schrieb Ryder Lee:
> On Mon, 2019-06-10 at 10:09 +0800, Ryder Lee wrote:
>> On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
>>> according to my findings
>>>
>>> MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
>>> so it must be rxdg4 = rxd[4] etc.
>> RXV start from 1 in the code.
>>
>> That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
>>
>>> however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal calculation.
>>> i already wrote a similar code for this driver which i sended to felix a long time ago.
>>> my variant looks like
>>> status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 2;
>>> status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 220) / 2;
>>> status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 220) / 2;
>>> status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 220) / 2;
>>> status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 220) / 2;
> mt7615 actually doesn't use in-band RSSI for signal calculation, but it
> occurs to me that i should modify the code to compare per-chain's
> signal. Something like this:
>
> status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
> status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
> status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
> status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
> status->signal = status->chain_signal[0];
>
> switch (status->chains) {
> case 0xf:
> status->signal = max(status->signal,
> status->chain_signal[3]);
> case 0x7:
> status->signal = max(status->signal,
> status->chain_signal[2]);
> case 0x3:
> status->signal = max(status->signal,
> status->chain_signal[1]);
> break;
> default:
> break;
> }
>
>
> I could send a v2 or you can take care of that.
>
> Ryder
>
>
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Ryder Lee @ 2019-06-10 4:22 UTC (permalink / raw)
To: Sebastian Gottschall
Cc: Sean Wang, Chih-Min Chen, YF Luo, linux-wireless, linux-kernel,
Yiwei Chung, linux-mediatek, Roy Luo, Lorenzo Bianconi,
Felix Fietkau
In-Reply-To: <1560132590.28258.5.camel@mtkswgap22>
On Mon, 2019-06-10 at 10:09 +0800, Ryder Lee wrote:
> On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
> > according to my findings
> >
> > MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
> > so it must be rxdg4 = rxd[4] etc.
>
> RXV start from 1 in the code.
>
> That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
>
> > however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal calculation.
> > i already wrote a similar code for this driver which i sended to felix a long time ago.
> > my variant looks like
> > status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 2;
> > status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 220) / 2;
> > status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 220) / 2;
> > status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 220) / 2;
> > status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 220) / 2;
mt7615 actually doesn't use in-band RSSI for signal calculation, but it
occurs to me that i should modify the code to compare per-chain's
signal. Something like this:
status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
status->signal = status->chain_signal[0];
switch (status->chains) {
case 0xf:
status->signal = max(status->signal,
status->chain_signal[3]);
case 0x7:
status->signal = max(status->signal,
status->chain_signal[2]);
case 0x3:
status->signal = max(status->signal,
status->chain_signal[1]);
break;
default:
break;
}
I could send a v2 or you can take care of that.
Ryder
^ permalink raw reply
* ath6k : Error: Connection activation failed: (7) Secrets were required, but not provided.
From: Ken Harris @ 2019-06-10 2:54 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
Wizards :
I'm trying to get the wireless on this "Dell Venue 8 Pro (5830)" tablet working.
It has ath6k chip (dmesg attached) :
[ 12.661190] ath6kl: ar6004 hw 3.0 sdio fw 3.5.0.349-1 api 5
[ 12.661206] ath6kl: firmware supports:
64bit-rates,map-lp-endpoint,ratetable-mcs15,no-ip-checksum
[ 12.661849] ath6kl: Firmware lacks RSN-CAP-OVERRIDE, so HT
(802.11n) is disabled.
It used to work intermittently (like 30 minutes on, then 30 minutes
off). I posted about this, but never figured it out.
I noticed it stopped working altogether.
Maybe it stopped working because I updated the software on tablet
(currently Fedora 5.1.6-300.fc30.x86_64 )
Maybe because I updated the Wi-Fi AP (currently OpenWRT 18.06.2 on
ath9k dual band). I did enable 802.11w on the AP.
All the other Wi-Fi devices (Linux laptops, Windoze 10 laptop, Android
phones, OpenWRT clients) on the net work, no problems.
When I do "nmcli c up db120" on the tablet , I get :
Error: Connection activation failed: Secrets were required, but not
provided
Hint: use 'journalctl -xe
NM_CONNECTION=8a528dcf-6c61-41fa-ab78-9d56ff9e7f1b + NM_DEVICE=wlan0'
to get more details
Some journalctl output (details attached) :
NetworkManager[543]: <info> device (wlan0): Activation: (wifi)
access point 'db120' has security, but secrets are required.
NetworkManager[543]: <info> device (wlan0): Activation: (wifi)
connection 'db120' has security, and secrets exist. No new secrets
needed.
The key file ( /etc/sysconfig/network-scripts/keys-db120 ) has the right value.
On the Wi-Fi AP, I get messages :
Sun Jun 9 18:21:50 2019 daemon.info hostapd: wlan0: STA
88:12:4e:01:94:88 IEEE 802.11: authenticated
Sun Jun 9 18:21:50 2019 daemon.info hostapd: wlan0: STA
88:12:4e:01:94:88 IEEE 802.11: No WPA/RSN IE in association request
I tried deleting and setting up the connection again :
nmcli connection delete id db120
nmcli device wifi connect db120 password mumble
... but still got the same message.
I installed ath6k/AR6004/hw3.0 firmware manually (it's not in Fedora
linux-firmware for some reason).
If I use a USB wired ethernet, it works fine.
Any tips are appreciated.
Thanks,
Ken
[-- Attachment #2: journalctl-dv8p-wlan0.txt --]
[-- Type: text/plain, Size: 7006 bytes --]
[root@dv8p network-scripts]# journalctl -xe NM_CONNECTION=8a528dcf-6c61-41fa-ab78-9d56ff9e7f1b + NM_DEVICE=wlan0
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.4650] device (wlan0): state change: config -> deactivating (reason 'new-activation', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.4681] device (wlan0): disconnecting for new activation request.
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.4685] device (wlan0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <warn> [1560129754.4753] device (wlan0): set-hw-addr: failed to set MAC address to 22:3D:91:79:9C:F3 (scanning) (NME_UNSPEC)
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.4798] device (wlan0): Activation: starting connection 'db120' (8a528dcf-6c61-41fa-ab78-9d56ff9e7f1b)
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5017] device (wlan0): supplicant interface state: scanning -> inactive
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5034] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5062] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5074] device (wlan0): Activation: (wifi) access point 'db120' has security, but secrets are required.
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5075] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5123] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5135] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5144] device (wlan0): Activation: (wifi) connection 'db120' has security, and secrets exist. No new secrets needed.
Jun 09 18:22:36 dv8p NetworkManager[543]: <info> [1560129756.5491] device (wlan0): supplicant interface state: inactive -> scanning
Jun 09 18:22:38 dv8p NetworkManager[543]: <info> [1560129758.1116] device (wlan0): supplicant interface state: scanning -> associating
Jun 09 18:22:48 dv8p NetworkManager[543]: <info> [1560129768.1314] device (wlan0): supplicant interface state: associating -> disconnected
Jun 09 18:22:58 dv8p NetworkManager[543]: <info> [1560129778.1418] device (wlan0): supplicant interface state: disconnected -> scanning
Jun 09 18:22:59 dv8p NetworkManager[543]: <warn> [1560129779.4716] device (wlan0): Activation: (wifi) association took too long
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.4718] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:59 dv8p NetworkManager[543]: <warn> [1560129779.4768] device (wlan0): Activation: (wifi) asking for new secrets
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.4838] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.4866] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.4880] device (wlan0): Activation: (wifi) connection 'db120' has security, and secrets exist. No new secrets needed.
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.6987] device (wlan0): supplicant interface state: scanning -> associating
Jun 09 18:23:09 dv8p NetworkManager[543]: <info> [1560129789.7016] device (wlan0): supplicant interface state: associating -> disconnected
Jun 09 18:23:19 dv8p NetworkManager[543]: <info> [1560129799.7029] device (wlan0): supplicant interface state: disconnected -> scanning
Jun 09 18:23:21 dv8p NetworkManager[543]: <info> [1560129801.2521] device (wlan0): supplicant interface state: scanning -> associating
Jun 09 18:23:24 dv8p NetworkManager[543]: <warn> [1560129804.4722] device (wlan0): Activation: (wifi) association took too long
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4724] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Jun 09 18:23:24 dv8p NetworkManager[543]: <warn> [1560129804.4791] device (wlan0): Activation: (wifi) asking for new secrets
Jun 09 18:23:24 dv8p NetworkManager[543]: <warn> [1560129804.4796] sup-iface[0x55e3158eb0e0,wlan0]: connection disconnected (reason -3)
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4817] device (wlan0): supplicant interface state: associating -> disconnected
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4853] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4866] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4876] device (wlan0): Activation: (wifi) connection 'db120' has security, and secrets exist. No new secrets needed.
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.5153] device (wlan0): supplicant interface state: disconnected -> associating
Jun 09 18:23:34 dv8p NetworkManager[543]: <info> [1560129814.5371] device (wlan0): supplicant interface state: associating -> disconnected
Jun 09 18:23:44 dv8p NetworkManager[543]: <info> [1560129824.5442] device (wlan0): supplicant interface state: disconnected -> scanning
Jun 09 18:23:46 dv8p NetworkManager[543]: <info> [1560129826.1141] device (wlan0): supplicant interface state: scanning -> associating
Jun 09 18:23:49 dv8p NetworkManager[543]: <warn> [1560129829.4724] device (wlan0): Activation: (wifi) association took too long
Jun 09 18:23:49 dv8p NetworkManager[543]: <info> [1560129829.4727] device (wlan0): state change: config -> failed (reason 'no-secrets', sys-iface-state: 'managed')
Jun 09 18:23:49 dv8p NetworkManager[543]: <warn> [1560129829.4820] device (wlan0): Activation: failed for connection 'db120'
Jun 09 18:23:49 dv8p NetworkManager[543]: <warn> [1560129829.4822] sup-iface[0x55e3158eb0e0,wlan0]: connection disconnected (reason -3)
Jun 09 18:23:49 dv8p NetworkManager[543]: <info> [1560129829.4846] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Jun 09 18:23:49 dv8p NetworkManager[543]: <warn> [1560129829.4886] device (wlan0): set-hw-addr: failed to set MAC address to 66:4F:93:A6:ED:9E (scanning) (NME_UNSPEC)
Jun 09 18:23:49 dv8p NetworkManager[543]: <info> [1560129829.4915] device (wlan0): supplicant interface state: associating -> disconnected
[-- Attachment #3: dmesg-5.1.6-300.fc30.x86_64-dv8p.txt --]
[-- Type: text/plain, Size: 47985 bytes --]
[ 0.000000] Linux version 5.1.6-300.fc30.x86_64 (mockbuild@bkernel04.phx2.fedoraproject.org) (gcc version 9.1.1 20190503 (Red Hat 9.1.1-1) (GCC)) #1 SMP Fri May 31 17:43:23 UTC 2019
[ 0.000000] Command line: BOOT_IMAGE=(hd0,gpt3)/vmlinuz-5.1.6-300.fc30.x86_64 root=UUID=6d7e5437-2e43-4e3c-bb9e-56f1d698c0d1 ro rhgb quiet
[ 0.000000] x86/fpu: x87 FPU will use FXSAVE
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000008efff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000008f000-0x000000000008ffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000000090000-0x000000000009dfff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000200fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000020100000-0x0000000078d3afff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000078d3b000-0x0000000078d6afff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000078d6b000-0x0000000078d97fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x0000000078d98000-0x00000000795f8fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000795f9000-0x00000000799fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000079a00000-0x0000000079a07fff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000079a08000-0x0000000079a08fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000079a09000-0x0000000079b71fff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000079b72000-0x0000000079ff9fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000079ffa000-0x0000000079ffffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000e00f8000-0x00000000e00f8fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ffa00000-0x00000000ffffffff] reserved
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ACPI=0x78d97000 ACPI 2.0=0x78d97014 ESRT=0x78d6a000 SMBIOS=0x79a08190 TPMEventLog=0x52805010
[ 0.000000] secureboot: Secure boot disabled
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] DMI: Dell Inc. Venue 8 Pro 5830/09RP78, BIOS A14 01/28/2016
[ 0.000000] tsc: Detected 1332.800 MHz processor
[ 0.000030] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[ 0.000036] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000055] last_pfn = 0x7a000 max_arch_pfn = 0x400000000
[ 0.000063] MTRR default type: uncachable
[ 0.000065] MTRR fixed ranges enabled:
[ 0.000069] 00000-9FFFF write-back
[ 0.000073] A0000-FFFFF write-protect
[ 0.000076] MTRR variable ranges enabled:
[ 0.000080] 0 base 000000000 mask FC0000000 write-back
[ 0.000084] 1 base 040000000 mask FE0000000 write-back
[ 0.000088] 2 base 060000000 mask FF0000000 write-back
[ 0.000092] 3 base 070000000 mask FF8000000 write-back
[ 0.000096] 4 base 070000000 mask FF8000000 write-back
[ 0.000099] 5 base 078000000 mask FFC000000 write-back
[ 0.000103] 6 base 07B000000 mask FFF000000 uncachable
[ 0.000107] 7 base 07AE00000 mask FFFE00000 uncachable
[ 0.000397] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
[ 0.009869] esrt: ESRT header is not in the memory map.
[ 0.009893] BRK [0x05e01000, 0x05e01fff] PGTABLE
[ 0.009898] BRK [0x05e02000, 0x05e02fff] PGTABLE
[ 0.009902] BRK [0x05e03000, 0x05e03fff] PGTABLE
[ 0.010105] BRK [0x05e04000, 0x05e04fff] PGTABLE
[ 0.010114] BRK [0x05e05000, 0x05e05fff] PGTABLE
[ 0.010908] BRK [0x05e06000, 0x05e06fff] PGTABLE
[ 0.011324] BRK [0x05e07000, 0x05e07fff] PGTABLE
[ 0.011547] BRK [0x05e08000, 0x05e08fff] PGTABLE
[ 0.011995] BRK [0x05e09000, 0x05e09fff] PGTABLE
[ 0.012144] RAMDISK: [mem 0x5280c000-0x537cdfff]
[ 0.012155] ACPI: Early table checksum verification disabled
[ 0.012162] ACPI: RSDP 0x0000000078D97014 000024 (v02 DELL )
[ 0.012171] ACPI: XSDT 0x0000000078D74188 0000CC (v01 DELL WN09 00000003 MSFT 0100000D)
[ 0.012184] ACPI: FACP 0x0000000078D92000 00010C (v05 DELL WN09 00000003 AMI 0100000D)
[ 0.012198] ACPI: DSDT 0x0000000078D82000 00BB03 (v02 DELL A M I 00000003 AMI 0100000D)
[ 0.012208] ACPI: TCPA 0x0000000078D95000 000032 (v02 00000000 00000000)
[ 0.012217] ACPI: UEFI 0x0000000079593000 000042 (v01 00000000 00000000)
[ 0.012226] ACPI: MSDM 0x0000000078D94000 000055 (v03 DELL WN09 01072009 AMI 00010013)
[ 0.012236] ACPI: DBG2 0x0000000078D93000 000072 (v00 DELL INTLDBG2 00000003 AMI 0100000D)
[ 0.012245] ACPI: HPET 0x0000000078D91000 000038 (v01 DELL WN09 00000003 AMI 0100000D)
[ 0.012254] ACPI: LPIT 0x0000000078D90000 000104 (v01 DELL 00000003 AMI 0100000D)
[ 0.012263] ACPI: APIC 0x0000000078D8F000 00006C (v03 DELL 00000003 AMI 0100000D)
[ 0.012273] ACPI: MCFG 0x0000000078D8E000 00003C (v01 DELL 00000003 AMI 0100000D)
[ 0.012282] ACPI: SSDT 0x0000000078D81000 000673 (v01 DELL CpuDptf 00000003 AMI 0100000D)
[ 0.012291] ACPI: SSDT 0x0000000078D7F000 001A12 (v01 DELL DptfTab 00000003 AMI 0100000D)
[ 0.012300] ACPI: SSDT 0x0000000078D7E000 000058 (v01 DELL LowPwrM 00000003 AMI 0100000D)
[ 0.012310] ACPI: SSDT 0x0000000078D7D000 0000FF (v01 DELL SoCDptf 00000003 AMI 0100000D)
[ 0.012319] ACPI: FPDT 0x0000000078D7C000 000044 (v01 A M I ALASKA 01072009 AMI 00010013)
[ 0.012328] ACPI: SSDT 0x0000000078D7B000 000763 (v01 PmRef CpuPm 00003000 INTL 20061109)
[ 0.012337] ACPI: SSDT 0x0000000078D7A000 000290 (v01 PmRef Cpu0Tst 00003000 INTL 20061109)
[ 0.012347] ACPI: SSDT 0x0000000078D79000 00017A (v01 PmRef ApTst 00003000 INTL 20061109)
[ 0.012356] ACPI: SSDT 0x0000000078D78000 000427 (v01 Intel_ Tpm2Tabl 00001000 INTL 20061109)
[ 0.012365] ACPI: TPM2 0x0000000078D77000 000034 (v03 00000000 00000000)
[ 0.012375] ACPI: BGRT 0x0000000078D76000 000038 (v00 DELL A M I 01072009 AMI 00010013)
[ 0.012384] ACPI: CSRT 0x0000000078D75000 00014C (v00 ALASKA WN09 00000005 MSFT 0100000D)
[ 0.012407] ACPI: Local APIC address 0xfee00000
[ 0.012694] No NUMA configuration found
[ 0.012697] Faking a node at [mem 0x0000000000000000-0x0000000079ffffff]
[ 0.012726] NODE_DATA(0) allocated [mem 0x78b31000-0x78b5bfff]
[ 0.024254] Zone ranges:
[ 0.024258] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.024263] DMA32 [mem 0x0000000001000000-0x0000000079ffffff]
[ 0.024266] Normal empty
[ 0.024269] Device empty
[ 0.024272] Movable zone start for each node
[ 0.024283] Early memory node ranges
[ 0.024286] node 0: [mem 0x0000000000001000-0x000000000008efff]
[ 0.024289] node 0: [mem 0x0000000000090000-0x000000000009dfff]
[ 0.024291] node 0: [mem 0x0000000000100000-0x000000001fffffff]
[ 0.024294] node 0: [mem 0x0000000020100000-0x0000000078d3afff]
[ 0.024297] node 0: [mem 0x0000000079a00000-0x0000000079a07fff]
[ 0.024299] node 0: [mem 0x0000000079a09000-0x0000000079b71fff]
[ 0.024302] node 0: [mem 0x0000000079ffa000-0x0000000079ffffff]
[ 0.024581] Zeroed struct page in unavailable ranges: 4786 pages
[ 0.024586] Initmem setup node 0 [mem 0x0000000000001000-0x0000000079ffffff]
[ 0.024591] On node 0 totalpages: 494926
[ 0.024594] DMA zone: 64 pages used for memmap
[ 0.024597] DMA zone: 28 pages reserved
[ 0.024600] DMA zone: 3996 pages, LIFO batch:0
[ 0.024947] DMA32 zone: 7744 pages used for memmap
[ 0.024950] DMA32 zone: 490930 pages, LIFO batch:63
[ 0.065921] x86/hpet: Will disable the HPET for this platform because it's not reliable
[ 0.065931] Reserving Intel graphics memory at [mem 0x7af00000-0x7eefffff]
[ 0.065993] ACPI: Local APIC address 0xfee00000
[ 0.066023] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-86
[ 0.066029] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.066034] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.066040] Using ACPI (MADT) for SMP configuration information
[ 0.066044] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.066070] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.066136] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[ 0.066143] PM: Registered nosave memory: [mem 0x0008f000-0x0008ffff]
[ 0.066150] PM: Registered nosave memory: [mem 0x0009e000-0x0009ffff]
[ 0.066152] PM: Registered nosave memory: [mem 0x000a0000-0x000fffff]
[ 0.066158] PM: Registered nosave memory: [mem 0x20000000-0x200fffff]
[ 0.066164] PM: Registered nosave memory: [mem 0x78d3b000-0x78d6afff]
[ 0.066167] PM: Registered nosave memory: [mem 0x78d6b000-0x78d97fff]
[ 0.066169] PM: Registered nosave memory: [mem 0x78d98000-0x795f8fff]
[ 0.066172] PM: Registered nosave memory: [mem 0x795f9000-0x799fffff]
[ 0.066178] PM: Registered nosave memory: [mem 0x79a08000-0x79a08fff]
[ 0.066184] PM: Registered nosave memory: [mem 0x79b72000-0x79ff9fff]
[ 0.066189] [mem 0x7ef00000-0xe00f7fff] available for PCI devices
[ 0.066192] Booting paravirtualized kernel on bare hardware
[ 0.066200] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[ 0.492395] random: get_random_bytes called from start_kernel+0x8f/0x512 with crng_init=0
[ 0.492421] setup_percpu: NR_CPUS:1024 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
[ 0.493267] percpu: Embedded 45 pages/cpu s147456 r8192 d28672 u524288
[ 0.493292] pcpu-alloc: s147456 r8192 d28672 u524288 alloc=1*2097152
[ 0.493296] pcpu-alloc: [0] 0 1 2 3
[ 0.493395] Built 1 zonelists, mobility grouping on. Total pages: 487090
[ 0.493398] Policy zone: DMA32
[ 0.493402] Kernel command line: BOOT_IMAGE=(hd0,gpt3)/vmlinuz-5.1.6-300.fc30.x86_64 root=UUID=6d7e5437-2e43-4e3c-bb9e-56f1d698c0d1 ro rhgb quiet
[ 0.510478] Memory: 1801688K/1979704K available (12291K kernel code, 1536K rwdata, 4088K rodata, 2212K init, 4636K bss, 178016K reserved, 0K cma-reserved)
[ 0.511011] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.511027] Kernel/User page tables isolation: enabled
[ 0.511070] ftrace: allocating 39296 entries in 154 pages
[ 0.549555] rcu: Hierarchical RCU implementation.
[ 0.549560] rcu: RCU restricting CPUs from NR_CPUS=1024 to nr_cpu_ids=4.
[ 0.549562] Tasks RCU enabled.
[ 0.549564] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
[ 0.549567] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.560315] NR_IRQS: 65792, nr_irqs: 1024, preallocated irqs: 0
[ 0.560443] Console: colour dummy device 80x25
[ 0.560452] printk: console [tty0] enabled
[ 0.560502] ACPI: Core revision 20190215
[ 0.560927] APIC: Switch to symmetric I/O mode setup
[ 0.560980] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x133626f6b26, max_idle_ns: 440795214178 ns
[ 0.561007] Calibrating delay loop (skipped), value calculated using timer frequency.. 2665.60 BogoMIPS (lpj=1332800)
[ 0.561013] pid_max: default: 32768 minimum: 301
[ 0.561985] LSM: Security Framework initializing
[ 0.561985] Yama: becoming mindful.
[ 0.561985] SELinux: Initializing.
[ 0.561985] *** VALIDATE SELinux ***
[ 0.561985] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.561985] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.561985] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.561985] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.561985] *** VALIDATE proc ***
[ 0.561985] *** VALIDATE cgroup1 ***
[ 0.561985] *** VALIDATE cgroup2 ***
[ 0.561985] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.561985] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[ 0.561985] mce: CPU0: Thermal monitoring enabled (TM1)
[ 0.561985] process: using mwait in idle threads
[ 0.561985] Last level iTLB entries: 4KB 48, 2MB 0, 4MB 0
[ 0.561985] Last level dTLB entries: 4KB 128, 2MB 16, 4MB 16, 1GB 0
[ 0.561985] Spectre V2 : Mitigation: Full generic retpoline
[ 0.561985] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[ 0.561985] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.561985] Freeing SMP alternatives memory: 36K
[ 0.561985] TSC deadline timer enabled
[ 0.561985] smpboot: CPU0: Intel(R) Atom(TM) CPU Z3740D @ 1.33GHz (family: 0x6, model: 0x37, stepping: 0x3)
[ 0.561985] Performance Events: PEBS fmt2+, 8-deep LBR, Silvermont events, 8-deep LBR, full-width counters, Intel PMU driver.
[ 0.561985] ... version: 3
[ 0.561985] ... bit width: 40
[ 0.561985] ... generic registers: 2
[ 0.561985] ... value mask: 000000ffffffffff
[ 0.561985] ... max period: 0000007fffffffff
[ 0.561985] ... fixed-purpose events: 3
[ 0.561985] ... event mask: 0000000700000003
[ 0.561985] rcu: Hierarchical SRCU implementation.
[ 0.562895] random: crng done (trusting CPU's manufacturer)
[ 0.563442] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[ 0.563673] smp: Bringing up secondary CPUs ...
[ 0.564067] x86: Booting SMP configuration:
[ 0.564070] .... node #0, CPUs: #1 #2 #3
[ 0.565470] smp: Brought up 1 node, 4 CPUs
[ 0.565470] smpboot: Max logical packages: 1
[ 0.565470] smpboot: Total of 4 processors activated (10662.40 BogoMIPS)
[ 0.566598] devtmpfs: initialized
[ 0.567105] x86/mm: Memory block size: 128MB
[ 0.567823] PM: Registering ACPI NVS region [mem 0x0008f000-0x0008ffff] (4096 bytes)
[ 0.567823] PM: Registering ACPI NVS region [mem 0x78d98000-0x795f8fff] (8785920 bytes)
[ 0.568532] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[ 0.568532] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.568532] pinctrl core: initialized pinctrl subsystem
[ 0.569111] PM: RTC time: 00:05:54, date: 2019-06-10
[ 0.569522] NET: Registered protocol family 16
[ 0.569682] audit: initializing netlink subsys (disabled)
[ 0.569709] audit: type=2000 audit(1560125154.008:1): state=initialized audit_enabled=0 res=1
[ 0.570103] cpuidle: using governor menu
[ 0.570227] ACPI: bus type PCI registered
[ 0.570231] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.570426] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.570461] PCI: not using MMCONFIG
[ 0.570465] PCI: Using configuration type 1 for base access
[ 0.575312] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[ 0.576016] cryptd: max_cpu_qlen set to 1000
[ 0.576216] ACPI: Added _OSI(Module Device)
[ 0.576219] ACPI: Added _OSI(Processor Device)
[ 0.576222] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.576224] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.576228] ACPI: Added _OSI(Linux-Dell-Video)
[ 0.576231] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 0.576233] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 0.599798] ACPI: 9 ACPI AML tables successfully acquired and loaded
[ 0.606922] ACPI: Dynamic OEM Table Load:
[ 0.606941] ACPI: SSDT 0xFFFF9124363AC800 00045B (v01 PmRef Cpu0Ist 00003000 INTL 20061109)
[ 0.607961] ACPI: Dynamic OEM Table Load:
[ 0.607977] ACPI: SSDT 0xFFFF9124363A9800 000433 (v01 PmRef Cpu0Cst 00003001 INTL 20061109)
[ 0.609389] ACPI: Dynamic OEM Table Load:
[ 0.609405] ACPI: SSDT 0xFFFF912435C20A00 00015F (v01 PmRef ApIst 00003000 INTL 20061109)
[ 0.610064] ACPI: Dynamic OEM Table Load:
[ 0.610079] ACPI: SSDT 0xFFFF9124363DBCC0 00008D (v01 PmRef ApCst 00003000 INTL 20061109)
[ 0.613946] ACPI: Interpreter enabled
[ 0.613985] ACPI: (supports S0)
[ 0.613993] ACPI: Using IOAPIC for interrupt routing
[ 0.614101] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.624626] [Firmware Info]: PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] not reserved in ACPI motherboard resources
[ 0.624631] PCI: not using MMCONFIG
[ 0.624641] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.632057] ACPI: Power Resource [USBC] (on)
[ 0.632857] ACPI: Power Resource [WWPR] (off)
[ 0.639124] ACPI: Power Resource [PLPE] (on)
[ 0.649674] ACPI: Power Resource [CLK0] (on)
[ 0.649790] ACPI: Power Resource [CLK1] (on)
[ 0.650070] ACPI: Power Resource [P28X] (off)
[ 0.650182] ACPI: Power Resource [P18X] (off)
[ 0.652226] ACPI: Power Resource [TCPR] (off)
[ 0.659215] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.659228] acpi PNP0A08:00: _OSC: OS supports [ASPM ClockPM Segments MSI]
[ 0.659359] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM
[ 0.659389] acpi PNP0A08:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[ 0.660374] PCI host bridge to bus 0000:00
[ 0.660381] pci_bus 0000:00: root bus resource [io 0x0070-0x0077]
[ 0.660386] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window]
[ 0.660391] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window]
[ 0.660395] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
[ 0.660400] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 0.660404] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff window]
[ 0.660408] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff window]
[ 0.660412] pci_bus 0000:00: root bus resource [mem 0x90c00000-0x90ffffff window]
[ 0.660416] pci_bus 0000:00: root bus resource [mem 0x7af00001-0x7ef00000 window]
[ 0.660420] pci_bus 0000:00: root bus resource [mem 0x80000000-0x908ffffe window]
[ 0.660424] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed40fff window]
[ 0.660429] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.660445] pci 0000:00:00.0: [8086:0f00] type 00 class 0x060000
[ 0.660713] pci 0000:00:02.0: [8086:0f31] type 00 class 0x030000
[ 0.660734] pci 0000:00:02.0: reg 0x10: [mem 0x90000000-0x903fffff]
[ 0.660748] pci 0000:00:02.0: reg 0x18: [mem 0x80000000-0x8fffffff pref]
[ 0.660762] pci 0000:00:02.0: reg 0x20: [io 0x1000-0x1007]
[ 0.660789] pci 0000:00:02.0: BAR 2: assigned to efifb
[ 0.661046] pci 0000:00:14.0: [8086:0f35] type 00 class 0x0c0330
[ 0.661074] pci 0000:00:14.0: reg 0x10: [mem 0x90800000-0x9080ffff 64bit]
[ 0.661149] pci 0000:00:14.0: PME# supported from D3hot D3cold
[ 0.661396] pci 0000:00:1a.0: [8086:0f18] type 00 class 0x108000
[ 0.661425] pci 0000:00:1a.0: reg 0x10: [mem 0x90700000-0x907fffff]
[ 0.661439] pci 0000:00:1a.0: reg 0x14: [mem 0x90600000-0x906fffff]
[ 0.661535] pci 0000:00:1a.0: PME# supported from D0 D3hot
[ 0.661768] pci 0000:00:1f.0: [8086:0f1c] type 00 class 0x060100
[ 0.663139] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.663339] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.663536] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.663734] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.663932] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.664139] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.664339] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.664552] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.667111] gpio gpiochip1: (INT33FC:01): detected irqchip that is shared with multiple gpiochips: please fix the driver.
[ 0.668207] gpio gpiochip2: (INT33FC:02): detected irqchip that is shared with multiple gpiochips: please fix the driver.
[ 0.680096] pci 0000:00:02.0: vgaarb: setting as boot VGA device
[ 0.680096] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[ 0.680096] pci 0000:00:02.0: vgaarb: bridge control possible
[ 0.680096] vgaarb: loaded
[ 0.680295] SCSI subsystem initialized
[ 0.680333] libata version 3.00 loaded.
[ 0.680333] ACPI: bus type USB registered
[ 0.680333] usbcore: registered new interface driver usbfs
[ 0.680333] usbcore: registered new interface driver hub
[ 0.680333] usbcore: registered new device driver usb
[ 0.828364] pps_core: LinuxPPS API ver. 1 registered
[ 0.828367] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.828377] PTP clock support registered
[ 0.828461] EDAC MC: Ver: 3.0.0
[ 0.828461] Registered efivars operations
[ 0.833052] PCI: Using ACPI for IRQ routing
[ 0.833057] PCI: pci_cache_line_size set to 64 bytes
[ 0.833082] Expanded resource Reserved due to conflict with PCI Bus 0000:00
[ 0.833087] e820: reserve RAM buffer [mem 0x0008f000-0x0008ffff]
[ 0.833091] e820: reserve RAM buffer [mem 0x0009e000-0x0009ffff]
[ 0.833093] e820: reserve RAM buffer [mem 0x78d3b000-0x7bffffff]
[ 0.833097] e820: reserve RAM buffer [mem 0x79a08000-0x7bffffff]
[ 0.833100] e820: reserve RAM buffer [mem 0x79b72000-0x7bffffff]
[ 0.833103] e820: reserve RAM buffer [mem 0x7a000000-0x7bffffff]
[ 0.833390] NetLabel: Initializing
[ 0.833393] NetLabel: domain hash size = 128
[ 0.833394] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 0.833437] NetLabel: unlabeled traffic allowed by default
[ 0.833451] clocksource: Switched to clocksource tsc-early
[ 0.878311] VFS: Disk quotas dquot_6.6.0
[ 0.878357] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.878427] *** VALIDATE hugetlbfs ***
[ 0.878516] pnp: PnP ACPI init
[ 0.878658] pnp 00:00: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.878962] system 00:01: [io 0x0680-0x069f] has been reserved
[ 0.878968] system 00:01: [io 0x0400-0x047f] has been reserved
[ 0.878972] system 00:01: [io 0x0500-0x05fe] has been reserved
[ 0.878977] system 00:01: [io 0x0600-0x061f] has been reserved
[ 0.878982] system 00:01: [io 0x164e-0x164f] has been reserved
[ 0.879014] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.879301] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.883235] pnp: PnP ACPI: found 3 devices
[ 0.888857] pci_bus 0000:00: resource 4 [io 0x0070-0x0077]
[ 0.888863] pci_bus 0000:00: resource 5 [io 0x0000-0x006f window]
[ 0.888867] pci_bus 0000:00: resource 6 [io 0x0078-0x0cf7 window]
[ 0.888872] pci_bus 0000:00: resource 7 [io 0x0d00-0xffff window]
[ 0.888876] pci_bus 0000:00: resource 8 [mem 0x000a0000-0x000bffff window]
[ 0.888880] pci_bus 0000:00: resource 9 [mem 0x000c0000-0x000dffff window]
[ 0.888884] pci_bus 0000:00: resource 10 [mem 0x000e0000-0x000fffff window]
[ 0.888889] pci_bus 0000:00: resource 11 [mem 0x90c00000-0x90ffffff window]
[ 0.888893] pci_bus 0000:00: resource 12 [mem 0x7af00001-0x7ef00000 window]
[ 0.888897] pci_bus 0000:00: resource 13 [mem 0x80000000-0x908ffffe window]
[ 0.888901] pci_bus 0000:00: resource 14 [mem 0xfed40000-0xfed40fff window]
[ 0.889142] NET: Registered protocol family 2
[ 0.889602] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes)
[ 0.889639] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[ 0.889751] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[ 0.889868] TCP: Hash tables configured (established 16384 bind 16384)
[ 0.889963] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[ 0.890022] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[ 0.890182] NET: Registered protocol family 1
[ 0.890202] NET: Registered protocol family 44
[ 0.890227] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[ 0.890665] PCI: CLS 0 bytes, default 64
[ 0.890797] Unpacking initramfs...
[ 1.623726] Freeing initrd memory: 16136K
[ 1.623874] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x133626f6b26, max_idle_ns: 440795214178 ns
[ 1.623921] clocksource: Switched to clocksource tsc
[ 1.630473] Initialise system trusted keyrings
[ 1.630501] Key type blacklist registered
[ 1.630618] workingset: timestamp_bits=36 max_order=19 bucket_order=0
[ 1.635325] zbud: loaded
[ 1.637329] Platform Keyring initialized
[ 2.281569] alg: No test for lzo-rle (lzo-rle-generic)
[ 2.284874] alg: No test for lzo-rle (lzo-rle-scomp)
[ 2.288246] alg: No test for 842 (842-generic)
[ 2.291481] alg: No test for 842 (842-scomp)
[ 2.398687] NET: Registered protocol family 38
[ 2.398695] Key type asymmetric registered
[ 2.398698] Asymmetric key parser 'x509' registered
[ 2.398731] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 244)
[ 2.398857] io scheduler mq-deadline registered
[ 2.398860] io scheduler kyber registered
[ 2.399034] io scheduler bfq registered
[ 2.399220] atomic64_test: passed for x86-64 platform with CX8 and with SSE
[ 2.399522] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 2.399604] efifb: probing for efifb
[ 2.399644] efifb: showing boot graphics
[ 2.401670] efifb: framebuffer at 0x80000000, using 4000k, total 4000k
[ 2.401674] efifb: mode is 800x1280x32, linelength=3200, pages=1
[ 2.401675] efifb: scrolling: redraw
[ 2.401679] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 2.401827] fbcon: Deferring console take-over
[ 2.401830] fb0: EFI VGA frame buffer device
[ 2.401856] intel_idle: MWAIT substates: 0x33000020
[ 2.401859] intel_idle: v0.4.1 model 0x37
[ 2.402649] intel_idle: lapic_timer_reliable_states 0xffffffff
[ 2.416758] ACPI: AC Adapter [ADP1] (off-line)
[ 2.423910] [Firmware Bug]: No valid trip found
[ 2.424636] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 2.436693] battery: ACPI: Battery Slot [BATC] (battery present)
[ 2.444951] 00:02: ttyS0 at I/O 0x3f8 (irq = 31, base_baud = 115200) is a 16550A
[ 2.464511] 80860F0A:00: ttyS4 at MMIO 0x9094d000 (irq = 17, base_baud = 2764800) is a 16550A
[ 2.464706] serial serial0: tty port ttyS4 registered
[ 2.476914] 80860F0A:01: ttyS5 at MMIO 0x90953000 (irq = 18, base_baud = 2764800) is a 16550A
[ 2.478520] hpet: number irqs doesn't agree with number of timers
[ 2.478878] Non-volatile memory driver v1.3
[ 2.479041] Linux agpgart interface v0.103
[ 2.519466] libphy: Fixed MDIO Bus: probed
[ 2.519803] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 2.519826] ehci-pci: EHCI PCI platform driver
[ 2.519860] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 2.519869] ohci-pci: OHCI PCI platform driver
[ 2.519891] uhci_hcd: USB Universal Host Controller Interface driver
[ 2.520239] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 2.520457] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[ 2.521554] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x0000000000009810
[ 2.521563] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[ 2.521932] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.01
[ 2.521937] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.521941] usb usb1: Product: xHCI Host Controller
[ 2.521945] usb usb1: Manufacturer: Linux 5.1.6-300.fc30.x86_64 xhci-hcd
[ 2.521948] usb usb1: SerialNumber: 0000:00:14.0
[ 2.522447] hub 1-0:1.0: USB hub found
[ 2.522475] hub 1-0:1.0: 6 ports detected
[ 3.606722] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 3.607091] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
[ 3.607103] xhci_hcd 0000:00:14.0: Host supports USB 3.0 SuperSpeed
[ 3.607262] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.01
[ 3.607267] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 3.607271] usb usb2: Product: xHCI Host Controller
[ 3.607275] usb usb2: Manufacturer: Linux 5.1.6-300.fc30.x86_64 xhci-hcd
[ 3.607278] usb usb2: SerialNumber: 0000:00:14.0
[ 3.607757] hub 2-0:1.0: USB hub found
[ 3.607782] hub 2-0:1.0: 1 port detected
[ 3.608231] usbcore: registered new interface driver usbserial_generic
[ 3.608248] usbserial: USB Serial support registered for generic
[ 3.608310] i8042: PNP: No PS/2 controller found.
[ 3.608723] mousedev: PS/2 mouse device common for all mice
[ 3.609052] rtc_cmos 00:00: registered as rtc0
[ 3.609057] rtc_cmos 00:00: no alarms, 242 bytes nvram
[ 3.609194] device-mapper: uevent: version 1.0.3
[ 3.609447] device-mapper: ioctl: 4.40.0-ioctl (2019-01-18) initialised: dm-devel@redhat.com
[ 3.610044] intel_pstate: Intel P-state driver initializing
[ 3.612155] hidraw: raw HID events driver (C) Jiri Kosina
[ 3.612432] usbcore: registered new interface driver usbhid
[ 3.612437] usbhid: USB HID core driver
[ 3.613525] drop_monitor: Initializing network drop monitor service
[ 3.613883] Initializing XFRM netlink socket
[ 3.614862] NET: Registered protocol family 10
[ 3.635637] Segment Routing with IPv6
[ 3.635765] mip6: Mobile IPv6
[ 3.635777] NET: Registered protocol family 17
[ 3.638134] mce: Using 6 MCE banks
[ 3.638229] RAS: Correctable Errors collector initialized.
[ 3.638683] microcode: sig=0x30673, pf=0x2, revision=0x321
[ 3.639509] microcode: Microcode Update Driver: v2.2.
[ 3.639583] SSE version of gcm_enc/dec engaged.
[ 3.821617] sched_clock: Marking stable (3820966032, 612125)->(3840697504, -19119347)
[ 3.824161] registered taskstats version 1
[ 3.824213] Loading compiled-in X.509 certificates
[ 3.928912] Loaded X.509 cert 'Fedora kernel signing key: dbc76a31f4e0673968703a103109753cb34fdc40'
[ 3.929021] zswap: loaded using pool lzo/zbud
[ 3.931021] usb 1-2: new high-speed USB device number 2 using xhci_hcd
[ 3.963809] Key type big_key registered
[ 3.981621] Key type encrypted registered
[ 3.981852] integrity: Loading X.509 certificate: UEFI:db
[ 3.981943] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[ 3.981945] integrity: Loading X.509 certificate: UEFI:db
[ 3.982023] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[ 3.982025] integrity: Loading X.509 certificate: UEFI:db
[ 3.982066] integrity: Loaded X.509 cert 'Pegatron - Fabrikam Test OWN: bab9fccfe388de8e4270c21b8cdb7ea3'
[ 3.982832] ima: Allocated hash algorithm: sha1
[ 4.027376] No architecture policies found
[ 4.030647] PM: Magic number: 7:260:51
[ 4.030697] tpmrm tpmrm0: hash matches
[ 4.031557] rtc_cmos 00:00: setting system clock to 2019-06-10T00:05:57 UTC (1560125157)
[ 4.058199] usb 1-2: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
[ 4.058205] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 4.058208] usb 1-2: Product: USB 10/100/1000 LAN
[ 4.058211] usb 1-2: Manufacturer: Realtek
[ 4.058214] usb 1-2: SerialNumber: 000001000000
[ 4.058421] Freeing unused decrypted memory: 2040K
[ 4.060189] Freeing unused kernel image memory: 2212K
[ 4.067474] Write protecting the kernel read-only data: 18432k
[ 4.070313] Freeing unused kernel image memory: 2016K
[ 4.071622] Freeing unused kernel image memory: 8K
[ 4.105559] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[ 4.105569] rodata_test: all tests were successful
[ 4.106004] x86/mm: Checking user space page tables
[ 4.135431] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[ 4.135436] Run /init as init process
[ 4.168579] systemd[1]: systemd v241-8.git9ef65cb.fc30 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[ 4.182022] systemd[1]: Detected architecture x86-64.
[ 4.182040] systemd[1]: Running in initial RAM disk.
[ 4.206668] systemd[1]: Set hostname to <dv8p>.
[ 4.451328] systemd[1]: Reached target Timers.
[ 4.451704] systemd[1]: Listening on Journal Socket (/dev/log).
[ 4.451939] systemd[1]: Listening on udev Control Socket.
[ 4.451972] systemd[1]: Reached target Swap.
[ 4.452029] systemd[1]: Reached target Slices.
[ 4.452332] systemd[1]: Listening on Journal Audit Socket.
[ 5.204697] audit: type=1130 audit(1560125158.672:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 5.237235] audit: type=1130 audit(1560125158.705:3): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 5.451897] audit: type=1130 audit(1560125158.919:4): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 5.739986] audit: type=1130 audit(1560125159.207:5): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 5.743640] i2c_hid i2c-SMO91D0:00: i2c-SMO91D0:00 supply vdd not found, using dummy regulator
[ 5.743682] i2c_hid i2c-SMO91D0:00: i2c-SMO91D0:00 supply vddl not found, using dummy regulator
[ 5.771805] sdhci: Secure Digital Host Controller Interface driver
[ 5.771808] sdhci: Copyright(c) Pierre Ossman
[ 5.797733] mmc0: SDHCI controller on ACPI [80860F14:01] using ADMA
[ 5.798486] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
[ 5.810630] mmc2: SDHCI controller on ACPI [80860F14:00] using ADMA
[ 5.850751] mmc1: queuing unknown CIS tuple 0x01 (3 bytes)
[ 5.858608] mmc1: queuing unknown CIS tuple 0x1a (5 bytes)
[ 5.861775] mmc1: queuing unknown CIS tuple 0x1b (8 bytes)
[ 5.862447] mmc1: queuing unknown CIS tuple 0x14 (0 bytes)
[ 5.865169] mmc1: queuing unknown CIS tuple 0x80 (1 bytes)
[ 5.865245] mmc1: queuing unknown CIS tuple 0x81 (1 bytes)
[ 5.865329] mmc1: queuing unknown CIS tuple 0x82 (1 bytes)
[ 5.865366] mmc1: new high speed SDIO card at address 0001
[ 5.886165] hid-generic 0018:0483:91D1.0001: hidraw0: I2C HID v1.00 Device [SMO91D0:00 0483:91D1] on i2c-SMO91D0:00
[ 5.888450] mmc2: new HS200 MMC card at address 0001
[ 5.928462] mmcblk2: mmc2:0001 MBG4GC 29.1 GiB
[ 5.929295] mmcblk2boot0: mmc2:0001 MBG4GC partition 1 4.00 MiB
[ 5.930642] mmcblk2boot1: mmc2:0001 MBG4GC partition 2 4.00 MiB
[ 5.930778] mmcblk2rpmb: mmc2:0001 MBG4GC partition 3 4.00 MiB, chardev (240:0)
[ 5.937535] mmcblk2: p1 p2 p3 p4
[ 6.209247] i2c_hid i2c-SYNA7500:00: i2c-SYNA7500:00 supply vdd not found, using dummy regulator
[ 6.209309] i2c_hid i2c-SYNA7500:00: i2c-SYNA7500:00 supply vddl not found, using dummy regulator
[ 6.235825] input: SYNA7500:00 06CB:00F2 as /devices/platform/80860F41:05/i2c-5/i2c-SYNA7500:00/0018:06CB:00F2.0002/input/input0
[ 6.236612] input: SYNA7500:00 06CB:00F2 Touchscreen as /devices/platform/80860F41:05/i2c-5/i2c-SYNA7500:00/0018:06CB:00F2.0002/input/input1
[ 6.237262] hid-generic 0018:06CB:00F2.0002: input,hidraw1: I2C HID v1.00 Device [SYNA7500:00 06CB:00F2] on i2c-SYNA7500:00
[ 6.347047] audit: type=1130 audit(1560125159.814:6): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-fsck-root comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.376182] EXT4-fs (mmcblk2p4): mounted filesystem with ordered data mode. Opts: (null)
[ 6.595882] input: SYNA7500:00 06CB:00F2 as /devices/platform/80860F41:05/i2c-5/i2c-SYNA7500:00/0018:06CB:00F2.0002/input/input3
[ 6.596540] input: SYNA7500:00 06CB:00F2 as /devices/platform/80860F41:05/i2c-5/i2c-SYNA7500:00/0018:06CB:00F2.0002/input/input4
[ 6.597175] hid-multitouch 0018:06CB:00F2.0002: input,hidraw0: I2C HID v1.00 Device [SYNA7500:00 06CB:00F2] on i2c-SYNA7500:00
[ 6.864693] audit: type=1130 audit(1560125160.332:7): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=initrd-parse-etc comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.864720] audit: type=1131 audit(1560125160.332:8): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=initrd-parse-etc comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.912411] audit: type=1131 audit(1560125160.380:9): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.915701] audit: type=1131 audit(1560125160.382:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-sysctl comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.922228] audit: type=1131 audit(1560125160.389:11): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.924235] audit: type=1130 audit(1560125160.392:12): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=initrd-cleanup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.924245] audit: type=1131 audit(1560125160.392:13): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=initrd-cleanup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.927690] audit: type=1131 audit(1560125160.395:14): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 7.073745] systemd-journald[278]: Received SIGTERM from PID 1 (systemd).
[ 7.158223] printk: systemd: 22 output lines suppressed due to ratelimiting
[ 8.209700] SELinux: policy capability network_peer_controls=1
[ 8.209703] SELinux: policy capability open_perms=1
[ 8.209705] SELinux: policy capability extended_socket_class=1
[ 8.209706] SELinux: policy capability always_check_network=0
[ 8.209707] SELinux: policy capability cgroup_seclabel=1
[ 8.209709] SELinux: policy capability nnp_nosuid_transition=1
[ 8.256051] systemd[1]: Successfully loaded SELinux policy in 773.455ms.
[ 8.472733] systemd[1]: Relabelled /dev, /dev/shm, /run, /sys/fs/cgroup in 119.376ms.
[ 8.496131] systemd[1]: systemd v241-8.git9ef65cb.fc30 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[ 8.509859] systemd[1]: Detected architecture x86-64.
[ 8.517336] systemd[1]: Set hostname to <dv8p>.
[ 8.780936] systemd[1]: /usr/lib/systemd/system/sssd.service:11: PIDFile= references path below legacy directory /var/run/, updating /var/run/sssd.pid → /run/sssd.pid; please update the unit file accordingly.
[ 9.023206] systemd[1]: initrd-switch-root.service: Succeeded.
[ 9.024615] systemd[1]: Stopped Switch Root.
[ 9.025485] systemd[1]: systemd-journald.service: Service has no hold-off time (RestartSec=0), scheduling restart.
[ 9.025658] systemd[1]: systemd-journald.service: Scheduled restart job, restart counter is at 1.
[ 9.025695] systemd[1]: Stopped Journal Service.
[ 9.030354] systemd[1]: Starting Journal Service...
[ 9.113308] EXT4-fs (mmcblk2p4): re-mounted. Opts: (null)
[ 9.337368] EXT4-fs (mmcblk2p3): mounted filesystem with ordered data mode. Opts: (null)
[ 9.799697] systemd-journald[390]: Received request to flush runtime journal from PID 1
[ 10.275951] int3401 thermal INT3401:00: Creating sysfs group for PROC_THERMAL_PLATFORM_DEV
[ 10.290536] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8 channels
[ 10.316363] dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 channels
[ 10.428424] mei_txe 0000:00:1a.0: can't derive routing for PCI INT A
[ 10.428428] mei_txe 0000:00:1a.0: PCI INT A: not connected
[ 10.490859] usbcore: registered new interface driver r8152
[ 10.522835] usbcore: registered new interface driver cdc_ether
[ 10.528141] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.528238] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.531665] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.532168] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.542669] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.542771] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.601017] intel_sst_acpi 80860F28:00: BYT-CR not detected
[ 10.602177] intel_sst_acpi 80860F28:00: LPE base: 0x90a00000 size:0x200000
[ 10.602181] intel_sst_acpi 80860F28:00: IRAM base: 0x90ac0000
[ 10.602232] intel_sst_acpi 80860F28:00: DRAM base: 0x90b00000
[ 10.602242] intel_sst_acpi 80860F28:00: SHIM base: 0x90b40000
[ 10.602253] intel_sst_acpi 80860F28:00: Mailbox base: 0x90b44000
[ 10.602261] intel_sst_acpi 80860F28:00: DDR base: 0x20000000
[ 10.603150] intel_sst_acpi 80860F28:00: Got drv data max stream 25
[ 10.611694] usb 1-2: reset high-speed USB device number 2 using xhci_hcd
[ 10.739148] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.3)
[ 10.767929] r8152 1-2:1.0 eth0: v1.09.9
[ 10.826649] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 10.828140] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 10.828242] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 10.828246] cfg80211: failed to load regulatory.db
[ 10.964592] checking generic (80000000 3e8000) vs hw (80000000 10000000)
[ 10.964596] fb0: switching to inteldrmfb from EFI VGA
[ 10.968118] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 10.968509] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 10.968510] [drm] Driver supports precise vblank timestamp query.
[ 10.969226] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 10.990654] [drm] Initialized i915 1.6.0 20190207 for 0000:00:02.0 on minor 0
[ 10.992398] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 10.992871] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
[ 10.993243] [drm] HDaudio controller not detected, using LPE audio instead
[ 11.041794] input: gpio-keys as /devices/platform/gpio-keys.9.auto/input/input7
[ 11.042194] input: gpio-keys as /devices/platform/gpio-keys.10.auto/input/input8
[ 11.045436] fbcon: inteldrmfb (fb0) is primary device
[ 11.045439] fbcon: Deferring console take-over
[ 11.045446] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 11.098238] iTCO_vendor_support: vendor-support=0
[ 11.108032] mmc1: queuing unknown CIS tuple 0x01 (3 bytes)
[ 11.116038] mmc1: queuing unknown CIS tuple 0x1a (5 bytes)
[ 11.118485] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[ 11.118634] iTCO_wdt: Found a Bay Trail SoC TCO device (Version=3, TCOBASE=0x0460)
[ 11.119350] mmc1: queuing unknown CIS tuple 0x1b (8 bytes)
[ 11.119978] mmc1: queuing unknown CIS tuple 0x14 (0 bytes)
[ 11.120332] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 11.596969] bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled
[ 11.596975] bytcr_rt5640 bytcr_rt5640: quirk realtek,jack-detect-source 3
[ 11.596978] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-threshold-microamp 2000
[ 11.596981] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-scale-factor 1
[ 11.596984] bytcr_rt5640 bytcr_rt5640: quirk MONO_SPEAKER enabled
[ 11.597010] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled
[ 11.599573] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card1/input9
[ 11.599754] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card1/input10
[ 11.602631] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
[ 11.602693] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
[ 11.605073] bytcr_rt5640 bytcr_rt5640: rt5640-aif1 <-> ssp2-port mapping ok
[ 11.607896] input: bytcr-rt5640 Headset as /devices/platform/80860F28:00/bytcr_rt5640/sound/card0/input11
[ 12.191621] r8152 1-2:1.0 enp0s20u2: renamed from eth0
[ 12.236523] intel_rapl: Found RAPL domain package
[ 12.236530] intel_rapl: Found RAPL domain core
[ 12.377025] kauditd_printk_skb: 24 callbacks suppressed
[ 12.377028] audit: type=1130 audit(1560125165.844:39): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-backlight@backlight:intel_backlight comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 12.496508] audit: type=1130 audit(1560125165.964:40): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-journal-flush comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 12.661190] ath6kl: ar6004 hw 3.0 sdio fw 3.5.0.349-1 api 5
[ 12.661206] ath6kl: firmware supports: 64bit-rates,map-lp-endpoint,ratetable-mcs15,no-ip-checksum
[ 12.661849] ath6kl: Firmware lacks RSN-CAP-OVERRIDE, so HT (802.11n) is disabled.
[ 12.678378] audit: type=1130 audit(1560125166.146:41): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 12.698049] audit: type=1130 audit(1560125166.165:42): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 13.285033] Bluetooth: Core ver 2.22
[ 13.285279] NET: Registered protocol family 31
[ 13.285282] Bluetooth: HCI device and connection manager initialized
[ 13.285291] Bluetooth: HCI socket layer initialized
[ 13.285301] Bluetooth: L2CAP socket layer initialized
[ 13.285316] Bluetooth: SCO socket layer initialized
[ 20.913334] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20u2: link becomes ready
[ 20.913541] r8152 1-2:1.0 enp0s20u2: carrier on
[ 21.171142] fbcon: Taking over console
[ 21.181763] Console: switching to colour frame buffer device 100x80
[ 66.874004] NOHZ: local_softirq_pending 08
[ 80.375146] NOHZ: local_softirq_pending 08
[ 107.897041] NOHZ: local_softirq_pending 08
[ 136.627861] NOHZ: local_softirq_pending 08
[ 184.662661] NOHZ: local_softirq_pending 08
[ 192.417816] NOHZ: local_softirq_pending 08
[ 198.668378] NOHZ: local_softirq_pending 08
[ 210.385733] NOHZ: local_softirq_pending 08
[ 216.931930] NOHZ: local_softirq_pending 08
[ 223.475175] NOHZ: local_softirq_pending 08
[ 1649.534597] xhci_hcd 0000:00:14.0: Refused to change power state, currently in D0
[ 9168.405550] ath6kl: req failed (status:-110, ep:1, len:14 creds:1)
[ 9168.405568] ath6kl: tx complete error: -110
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Ryder Lee @ 2019-06-10 2:09 UTC (permalink / raw)
To: Sebastian Gottschall
Cc: Felix Fietkau, Lorenzo Bianconi, Sean Wang, Chih-Min Chen, YF Luo,
linux-wireless, linux-kernel, Yiwei Chung, linux-mediatek,
Roy Luo
In-Reply-To: <d6cfd2e9-4b2b-36ac-6cae-a34f74204801@newmedia-net.de>
On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
> according to my findings
>
> MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
> so it must be rxdg4 = rxd[4] etc.
RXV start from 1 in the code.
That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
> however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal calculation.
> i already wrote a similar code for this driver which i sended to felix a long time ago.
> my variant looks like
> status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 2;
> status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 220) / 2;
> status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 220) / 2;
> status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 220) / 2;
> status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 220) / 2;
> Am 09.06.2019 um 11:09 schrieb Ryder Lee:
> > Fill in RX status->chain_signal to avoid empty value.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > .../net/wireless/mediatek/mt76/mt7615/mac.c | 30 ++++++++++++++++++-
> > .../net/wireless/mediatek/mt76/mt7615/mac.h | 5 ++++
> > 2 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > index b60d42b5923d..9ee83ea11b8c
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > @@ -13,6 +13,11 @@
> > #include "../dma.h"
> > #include "mac.h"
> >
> > +static inline s8 to_rssi(u32 field, u32 rxv)
> > +{
> > + return (FIELD_GET(field, rxv) - 220) / 2;
> > +}
> > +
> > static struct mt76_wcid *mt7615_rx_get_wcid(struct mt7615_dev *dev,
> > u8 idx, bool unicast)
> > {
> > @@ -120,6 +125,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
> > if (rxd0 & MT_RXD0_NORMAL_GROUP_3) {
> > u32 rxdg0 = le32_to_cpu(rxd[0]);
> > u32 rxdg1 = le32_to_cpu(rxd[1]);
> > + u32 rxdg3 = le32_to_cpu(rxd[3]);
> > u8 stbc = FIELD_GET(MT_RXV1_HT_STBC, rxdg0);
> > bool cck = false;
> >
> > @@ -169,7 +175,29 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
> >
> > status->enc_flags |= RX_ENC_FLAG_STBC_MASK * stbc;
> >
> > - /* TODO: RSSI */
> > + status->chains = dev->mt76.antenna_mask;
> > + status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
> > + status->signal = status->chain_signal[0];
> > +
> > + switch (status->chains) {
> > + case 0x3:
> > + status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
> > + status->signal = max(status->signal,
> > + status->chain_signal[1]);
> > + break;
> > + case 0x7:
> > + status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
> > + status->signal = max(status->signal,
> > + status->chain_signal[2]);
> > + break;
> > + case 0xf:
> > + status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
> > + status->signal = max(status->signal,
> > + status->chain_signal[3]);
> > + break;
> > + default:
> > + break;
> > + }
> > rxd += 6;
> > if ((u8 *)rxd - skb->data >= skb->len)
> > return -EINVAL;
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > index 18ad4b8a3807..b00ce8db58e9
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > @@ -98,6 +98,11 @@ enum rx_pkt_type {
> > #define MT_RXV2_GROUP_ID GENMASK(26, 21)
> > #define MT_RXV2_LENGTH GENMASK(20, 0)
> >
> > +#define MT_RXV4_RCPI3 GENMASK(31, 24)
> > +#define MT_RXV4_RCPI2 GENMASK(23, 16)
> > +#define MT_RXV4_RCPI1 GENMASK(15, 8)
> > +#define MT_RXV4_RCPI0 GENMASK(7, 0)
> > +
> > enum tx_header_format {
> > MT_HDR_FORMAT_802_3,
> > MT_HDR_FORMAT_CMD,
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: Should b44_init lead to WARN_ON in drivers/ssb/driver_gpio.c:464?
From: Larry Finger @ 2019-06-10 0:13 UTC (permalink / raw)
To: Michael Büsch, H Buus
Cc: Kalle Valo, Michael Chan, linux-wireless, netdev
In-Reply-To: <20190609235711.481bbac9@wiggum>
On 6/9/19 4:57 PM, Michael Büsch wrote:
> On Sun, 9 Jun 2019 17:44:10 -0400
> H Buus <ubuntu@hbuus.com> wrote:
>
>> I have an old 32 bit laptop with a BCM4401-B0 100Base-TX ethernet
>> controller. For every kernel from 4.19-rc1 going forward, I get a
>> warning and call trace within a few seconds of start up (see dmesg
>> snippet below). I have traced it to a specific commit (see commit
>> below). On the face of it, I would think it is a regression, but it
>> doesn't seem to cause a problem, since networking over ethernet is working.
>
>
> This warning is not a problem. The commit just exposes a warning, that
> has always been there.
> I suggest we just remove the WARN_ON from ssb_gpio_init and
> ssb_gpio_unregister.
> I don't see a reason to throw a warning in that case.
Michael,
I agree. Do you want to prepare the patch, or should I?
Larry
^ permalink raw reply
* Re: Should b44_init lead to WARN_ON in drivers/ssb/driver_gpio.c:464?
From: Michael Büsch @ 2019-06-09 21:57 UTC (permalink / raw)
To: H Buus; +Cc: Kalle Valo, Michael Chan, linux-wireless, netdev
In-Reply-To: <946c86bf-7e90-a981-b9fc-757adb98adfa@hbuus.com>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
On Sun, 9 Jun 2019 17:44:10 -0400
H Buus <ubuntu@hbuus.com> wrote:
> I have an old 32 bit laptop with a BCM4401-B0 100Base-TX ethernet
> controller. For every kernel from 4.19-rc1 going forward, I get a
> warning and call trace within a few seconds of start up (see dmesg
> snippet below). I have traced it to a specific commit (see commit
> below). On the face of it, I would think it is a regression, but it
> doesn't seem to cause a problem, since networking over ethernet is working.
This warning is not a problem. The commit just exposes a warning, that
has always been there.
I suggest we just remove the WARN_ON from ssb_gpio_init and
ssb_gpio_unregister.
I don't see a reason to throw a warning in that case.
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Should b44_init lead to WARN_ON in drivers/ssb/driver_gpio.c:464?
From: H Buus @ 2019-06-09 21:44 UTC (permalink / raw)
To: Michael Buesch, Kalle Valo, Michael Chan, linux-wireless, netdev
I have an old 32 bit laptop with a BCM4401-B0 100Base-TX ethernet
controller. For every kernel from 4.19-rc1 going forward, I get a
warning and call trace within a few seconds of start up (see dmesg
snippet below). I have traced it to a specific commit (see commit
below). On the face of it, I would think it is a regression, but it
doesn't seem to cause a problem, since networking over ethernet is working.
I might not have noticed the warning except for the fact that something
in the 4.19 time frame is causing this laptop to be unstable. I still
have to identify the source of the instability. The laptop appears
stable with this commit but not with 4.19-rc7 or more recent kernels.
I thought I should at least ask if the following warning is an issue. If
it is, I am happy to help with creating a proper bug report as well as
debugging and testing. Is this an issue that should be addressed to the
netdev or linux-wireless lists, or both, since it appears to be an
interaction between the b44 driver which belongs to netdev and the ssb
driver which belongs to linux-wireless?
--- Begin dmesg snippet ---
[ 5.145764] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
[ 5.265914] b43-pci-bridge 0000:02:03.0: Sonics Silicon Backplane
found on PCI device 0000:02:03.0
[ 5.353718] ssb: Found chip with id 0x4401, rev 0x02 and package 0x00
[ 5.421787] WARNING: CPU: 0 PID: 157 at drivers/ssb/driver_gpio.c:464
ssb_gpio_init+0xa0/0xb0 [ssb]
[ 5.425679] Modules linked in: b44(+) psmouse pata_acpi ssb mii
[ 5.425679] CPU: 0 PID: 157 Comm: systemd-udevd Not tainted
4.19.31-041931-generic #201903231635
[ 5.425679] Hardware name: Dell Inc. ME051
/0DK344, BIOS A10 11/07/2006
[ 5.425679] EIP: ssb_gpio_init+0xa0/0xb0 [ssb]
[ 5.425679] Code: 00 31 c0 85 c9 0f 95 c0 31 c9 f7 d8 89 82 18 05 00
00 8d 82 d8 04 00 00 6a 00 e8 1b b6 17 dd 5a c9 c3 8d b4 26 00 00 00 00
90 <0f> 0b c9 b8 ff ff ff ff c3 8d b4 26 00 00 00 00 3e 8d 74 26 00 55
[ 5.425679] EAX: f58a3800 EBX: f58a3800 ECX: 00000000 EDX: f7e1ef94
[ 5.425679] ESI: 00000000 EDI: f58a3800 EBP: f585bc80 ESP: f585bc80
[ 5.425679] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246
[ 5.425679] CR0: 80050033 CR2: b7ab702b CR3: 3586c000 CR4: 000006f0
[ 5.425679] Call Trace:
[ 5.425679] ssb_attach_queued_buses+0xe2/0x310 [ssb]
[ 5.425679] ssb_bus_register+0x167/0x1c0 [ssb]
[ 5.425679] ? ssb_pci_xtal+0x1d0/0x1d0 [ssb]
[ 5.425679] ssb_bus_pcibus_register+0x29/0x80 [ssb]
[ 5.425679] ssb_pcihost_probe+0xb7/0x110 [ssb]
[ 5.425679] ? ssb_pcihost_remove+0x40/0x40 [ssb]
[ 5.425679] pci_device_probe+0xc7/0x160
[ 5.425679] really_probe+0x1fe/0x390
[ 5.425679] driver_probe_device+0xe1/0x120
[ 5.425679] ? pci_match_device+0xde/0x110
[ 5.425679] ? _cond_resched+0x17/0x30
[ 5.425679] __driver_attach+0xd9/0x100
[ 5.425679] ? driver_probe_device+0x120/0x120
[ 5.425679] bus_for_each_dev+0x5b/0xa0
[ 5.425679] driver_attach+0x19/0x20
[ 5.425679] ? driver_probe_device+0x120/0x120
[ 5.425679] bus_add_driver+0x117/0x210
[ 5.425679] ? pci_bus_num_vf+0x20/0x20
[ 5.425679] driver_register+0x66/0xb0
[ 5.425679] ? 0xf8365000
[ 5.425679] __pci_register_driver+0x3d/0x40
[ 5.425679] ssb_pcihost_register+0x2c/0x30 [ssb]
[ 5.425679] b44_init+0x1d/0x1000 [b44]
[ 5.425679] do_one_initcall+0x42/0x19a
[ 5.425679] ? vunmap_page_range+0x1c9/0x260
[ 5.425679] ? free_pcp_prepare+0x5d/0xf0
[ 5.425679] ? _cond_resched+0x17/0x30
[ 5.425679] ? kmem_cache_alloc_trace+0x15f/0x1b0
[ 5.425679] ? do_init_module+0x21/0x210
[ 5.425679] ? do_init_module+0x21/0x210
[ 5.425679] do_init_module+0x50/0x210
[ 5.425679] load_module+0x1368/0x1630
[ 5.425679] ? security_kernel_post_read_file+0x54/0x60
[ 5.425679] sys_finit_module+0x8a/0xe0
[ 5.425679] do_fast_syscall_32+0x87/0x1e0
[ 5.425679] entry_SYSENTER_32+0x6b/0xbe
[ 5.425679] EIP: 0xb7eead61
[ 5.425679] Code: f6 ff ff 55 89 e5 8b 55 08 8b 80 5c cd ff ff 85 d2
74 02 89 02 5d c3 8b 04 24 c3 8b 1c 24 c3 90 90 51 52 55 89 e5 0f 34 cd
80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
[ 5.425679] EAX: ffffffda EBX: 0000000d ECX: b7cfda15 EDX: 00000000
[ 5.425679] ESI: 00fcaf40 EDI: 00fcca40 EBP: 00000000 ESP: bfa404dc
[ 5.425679] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296
[ 5.425679] ---[ end trace b0d87e1b3433e0ca ]---
[ 6.245890] b44 0000:02:00.0: Sonics Silicon Backplane found on PCI
device 0000:02:00.0
[ 6.260263] b44: Broadcom 44xx/47xx 10/100 PCI ethernet driver
version 2.0
[ 6.299684] b44 ssb1:0 eth0: Broadcom 44xx/47xx 10/100 PCI ethernet
driver 00:14:22:af:83:9b
[ 6.367622] random: fast init done
--- End dmesg snippet ---
--- Begin commit ---
commit 209b43759d65b2cc99ce7757249aacc82b03c4e2
Author: Michael Büsch <m@bues.ch>
Date: Tue Jul 31 22:15:09 2018 +0200
ssb: Remove SSB_WARN_ON, SSB_BUG_ON and SSB_DEBUG
Use the standard WARN_ON instead.
If a small kernel is desired, WARN_ON can be disabled globally.
Also remove SSB_DEBUG. Besides WARN_ON it only adds a tiny debug check.
Include this check unconditionally.
Signed-off-by: Michael Buesch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
--- End commit ---
^ permalink raw reply
* [PATCH v3] ath9k: add loader for AR92XX (and older) pci(e)
From: Christian Lamparter @ 2019-06-09 20:36 UTC (permalink / raw)
To: linux-wireless, QCA ath9k Development; +Cc: Kalle Valo, Julian Calaby
Atheros cards with a AR92XX generation (and older) chip usually
store their pci(e) initialization vectors on an external eeprom chip.
However these chips technically don't need the eeprom chip attached,
the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
"... if the EEPROM content is not valid, a value of 0xFF1C returns
when read from the register". So, they will show up on the system's
pci bus. However in that state, ath9k can't load, since it relies
on having the correct pci-id, otherwise it doesn't know what chip it
actually is. This happens on many embedded devices like routers
and accesspoint since they want to keep the BOM low and store the
pci(e) initialization vectors together with the calibration data
on the system's FLASH, which is out of reach of the ath9k chip.
Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
Teleworker Gateway) need to be able to initialize the PCIe wifi device.
Normally, this should be done as a pci quirk during the early stages of
booting linux. However, this isn't possible for devices which have the
init code for the Atheros chip stored on NAND in an UBI volume.
Hence, this module can be used to initialize the chip when the
user-space is ready to extract the init code.
Martin Blumenstingl prodived the following fixes:
owl-loader: add support for OWL emulation PCI devices
owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
owl-loader: use dev_* instead of pr_* logging functions
owl-loader: auto-generate the eeprom filename as fallback
owl-loader: add a debug message when swapping the eeprom data
owl-loader: add missing newlines in log messages
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
v3: changed module description
v2: address Julian Calaby's comments:
- make it a separate driver again (much like OpenWrt)
- remove ar71xx leftovers (pdata)
---
drivers/net/wireless/ath/ath9k/Kconfig | 16 ++
drivers/net/wireless/ath/ath9k/Makefile | 2 +
.../wireless/ath/ath9k/ath9k_pci_owl_loader.c | 215 ++++++++++++++++++
3 files changed, 233 insertions(+)
create mode 100644 drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index a1ef8769983a..d6a87698a44a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -157,6 +157,22 @@ config ATH9K_PCOEM
depends on ATH9K
default y
+config ATH9K_PCI_NO_EEPROM
+ tristate "Atheros ath9k pci loader for EEPROM-less chips"
+ depends on ATH9K_PCI
+ default n
+ help
+ This separate driver provides a loader in order to support the
+ AR500X to AR92XX-generation of ath9k PCI(e) WiFi chips, which have
+ their initialization data (which contains the real PCI Device ID
+ that ath9k will need) stored together with the calibration data out
+ of reach for the ath9k chip.
+
+ These devices are usually various network appliances, routers or
+ access Points and such.
+
+ If unsure say N.
+
config ATH9K_HTC
tristate "Atheros HTC based wireless cards support"
depends on USB && MAC80211
diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile
index f71b2ad8275c..abd0f61370d9 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -77,3 +77,5 @@ ath9k_htc-y += htc_hst.o \
ath9k_htc-$(CONFIG_ATH9K_HTC_DEBUGFS) += htc_drv_debug.o
obj-$(CONFIG_ATH9K_HTC) += ath9k_htc.o
+
+obj-$(CONFIG_ATH9K_PCI_NO_EEPROM) += ath9k_pci_owl_loader.o
diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
new file mode 100644
index 000000000000..717dee7b6c4c
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Initialize Owl Emulation Devices
+ *
+ * Copyright (C) 2016 Christian Lamparter <chunkeey@gmail.com>
+ * Copyright (C) 2016 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+ *
+ * Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
+ * need to be able to initialize the PCIe wifi device. Normally, this is done
+ * during the early stages as a pci quirk.
+ * However, this isn't possible for devices which have the init code for the
+ * Atheros chip stored on UBI Volume on NAND. Hence, this module can be used to
+ * initialize the chip when the user-space is ready to extract the init code.
+ */
+#include <linux/module.h>
+#include <linux/version.h>
+#include <linux/completion.h>
+#include <linux/etherdevice.h>
+#include <linux/firmware.h>
+#include <linux/pci.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/ath9k_platform.h>
+
+struct owl_ctx {
+ struct completion eeprom_load;
+};
+
+#define EEPROM_FILENAME_LEN 100
+
+#define AR5416_EEPROM_MAGIC 0xa55a
+
+static int ath9k_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
+ size_t cal_len)
+{
+ void __iomem *mem;
+ const void *cal_end = (void *)cal_data + cal_len;
+ const struct {
+ u16 reg;
+ u16 low_val;
+ u16 high_val;
+ } __packed * data;
+ u16 cmd;
+ u32 bar0;
+ bool swap_needed = false;
+
+ if (*cal_data != AR5416_EEPROM_MAGIC) {
+ if (*cal_data != swab16(AR5416_EEPROM_MAGIC)) {
+ dev_err(&pdev->dev, "invalid calibration data\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(&pdev->dev, "calibration data needs swapping\n");
+ swap_needed = true;
+ }
+
+ dev_info(&pdev->dev, "fixup device configuration\n");
+
+ mem = pcim_iomap(pdev, 0, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "ioremap error\n");
+ return -EINVAL;
+ }
+
+ pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &bar0);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0,
+ pci_resource_start(pdev, 0));
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ /* set pointer to first reg address */
+ for (data = (const void *)(cal_data + 3);
+ (const void *)data <= cal_end && data->reg != (u16)~0;
+ data++) {
+ u32 val;
+ u16 reg;
+
+ reg = data->reg;
+ val = data->low_val;
+ val |= ((u32)data->high_val) << 16;
+
+ if (swap_needed) {
+ reg = swab16(reg);
+ val = swahb32(val);
+ }
+
+ __raw_writel(val, mem + reg);
+ usleep_range(100, 120);
+ }
+
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, bar0);
+ pcim_iounmap(pdev, mem);
+
+ pci_disable_device(pdev);
+
+ return 0;
+}
+
+static void owl_fw_cb(const struct firmware *fw, void *context)
+{
+ struct pci_dev *pdev = (struct pci_dev *)context;
+ struct owl_ctx *ctx = (struct owl_ctx *)pci_get_drvdata(pdev);
+ struct pci_bus *bus;
+
+ complete(&ctx->eeprom_load);
+
+ if (!fw) {
+ dev_err(&pdev->dev, "no eeprom data received.\n");
+ goto release;
+ }
+
+ /* also note that we are doing *u16 operations on the file */
+ if (fw->size > 4096 || fw->size < 0x200 || (fw->size & 1) == 1) {
+ dev_err(&pdev->dev, "eeprom file has an invalid size.\n");
+ goto release;
+ }
+
+ if (ath9k_pci_fixup(pdev, (const u16 *)fw->data, fw->size))
+ goto release;
+
+ pci_lock_rescan_remove();
+ bus = pdev->bus;
+ pci_stop_and_remove_bus_device(pdev);
+ /* the device should come back with the proper
+ * ProductId. But we have to initiate a rescan.
+ */
+ pci_rescan_bus(bus);
+ pci_unlock_rescan_remove();
+
+release:
+ release_firmware(fw);
+}
+
+static const char *owl_get_eeprom_name(struct pci_dev *pdev)
+{
+ struct device *dev = &pdev->dev;
+ char *eeprom_name;
+
+ dev_dbg(dev, "using auto-generated eeprom filename\n");
+
+ eeprom_name = devm_kzalloc(dev, EEPROM_FILENAME_LEN, GFP_KERNEL);
+ if (!eeprom_name)
+ return NULL;
+
+ /* this should match the pattern used in ath9k/init.c */
+ scnprintf(eeprom_name, EEPROM_FILENAME_LEN, "ath9k-eeprom-pci-%s.bin",
+ dev_name(dev));
+
+ return eeprom_name;
+}
+
+static int owl_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct owl_ctx *ctx;
+ const char *eeprom_name;
+ int err = 0;
+
+ if (pcim_enable_device(pdev))
+ return -EIO;
+
+ pcim_pin_device(pdev);
+
+ eeprom_name = owl_get_eeprom_name(pdev);
+ if (!eeprom_name) {
+ dev_err(&pdev->dev, "no eeprom filename found.\n");
+ return -ENODEV;
+ }
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ init_completion(&ctx->eeprom_load);
+
+ pci_set_drvdata(pdev, ctx);
+ err = request_firmware_nowait(THIS_MODULE, true, eeprom_name,
+ &pdev->dev, GFP_KERNEL, pdev, owl_fw_cb);
+ if (err)
+ dev_err(&pdev->dev, "failed to request caldata (%d).\n", err);
+
+ return err;
+}
+
+static void owl_remove(struct pci_dev *pdev)
+{
+ struct owl_ctx *ctx = pci_get_drvdata(pdev);
+
+ if (ctx) {
+ wait_for_completion(&ctx->eeprom_load);
+ pci_set_drvdata(pdev, NULL);
+ }
+}
+
+static const struct pci_device_id owl_pci_table[] = {
+ { PCI_VDEVICE(ATHEROS, 0xff1c) }, /* PCIe */
+ { PCI_VDEVICE(ATHEROS, 0xff1d) }, /* PCI */
+ { },
+};
+MODULE_DEVICE_TABLE(pci, owl_pci_table);
+
+static struct pci_driver owl_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = owl_pci_table,
+ .probe = owl_probe,
+ .remove = owl_remove,
+};
+module_pci_driver(owl_driver);
+MODULE_AUTHOR("Christian Lamparter <chunkeey@gmail.com>");
+MODULE_DESCRIPTION("External EEPROM data loader for Atheros AR500X to AR92XX");
+MODULE_LICENSE("GPL v2");
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 2/7] net/mac80211: move WEP handling to ARC4 library interface
From: Johannes Berg @ 2019-06-09 20:08 UTC (permalink / raw)
To: Ard Biesheuvel, linux-crypto
Cc: Herbert Xu, David S. Miller, Eric Biggers, linux-wireless,
John W. Linville
In-Reply-To: <20190609115509.26260-3-ard.biesheuvel@linaro.org>
Hi Ard,
In general, I have no objections to this.
However, with this
> - select CRYPTO_ARC4
> + select CRYPTO_LIB_ARC4
and this
> case WLAN_CIPHER_SUITE_WEP40:
> case WLAN_CIPHER_SUITE_TKIP:
> case WLAN_CIPHER_SUITE_WEP104:
> - if (IS_ERR(local->wep_tx_tfm))
> - return -EINVAL;
> - break;
there's one quirk that I worry about. Does this mean WEP is now *always*
available/enabled?
I had to dig in history a bit, but vaguely remembered this commit:
commit 3473187d2459a078e00e5fac8aafc30af69c57fa
Author: John W. Linville <linville@tuxdriver.com>
Date: Wed Jul 7 15:07:49 2010 -0400
mac80211: remove wep dependency
Since you create the new CRYPTO_LIB_ARC4 in patch 1, I wonder if
something is broken? I can't really seem to figure out how WEP is
disallowed in FIPS mode to start with though.
(This also is the reason for all the code that removes WEP/TKIP from the
list of permitted cipher suites when ARC4 isn't available...)
johannes
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Sebastian Gottschall @ 2019-06-09 14:44 UTC (permalink / raw)
To: Ryder Lee, Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel
In-Reply-To: <3912a2863e858f3623ced61737836e42c7b19149.1560071167.git.ryder.lee@mediatek.com>
according to my findings
MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
so it must be rxdg4 = rxd[4] etc.
however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal calculation.
i already wrote a similar code for this driver which i sended to felix a long time ago.
my variant looks like
status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 2;
status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 220) / 2;
status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 220) / 2;
status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 220) / 2;
status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 220) / 2;
Am 09.06.2019 um 11:09 schrieb Ryder Lee:
> Fill in RX status->chain_signal to avoid empty value.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../net/wireless/mediatek/mt76/mt7615/mac.c | 30 ++++++++++++++++++-
> .../net/wireless/mediatek/mt76/mt7615/mac.h | 5 ++++
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> index b60d42b5923d..9ee83ea11b8c
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> @@ -13,6 +13,11 @@
> #include "../dma.h"
> #include "mac.h"
>
> +static inline s8 to_rssi(u32 field, u32 rxv)
> +{
> + return (FIELD_GET(field, rxv) - 220) / 2;
> +}
> +
> static struct mt76_wcid *mt7615_rx_get_wcid(struct mt7615_dev *dev,
> u8 idx, bool unicast)
> {
> @@ -120,6 +125,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
> if (rxd0 & MT_RXD0_NORMAL_GROUP_3) {
> u32 rxdg0 = le32_to_cpu(rxd[0]);
> u32 rxdg1 = le32_to_cpu(rxd[1]);
> + u32 rxdg3 = le32_to_cpu(rxd[3]);
> u8 stbc = FIELD_GET(MT_RXV1_HT_STBC, rxdg0);
> bool cck = false;
>
> @@ -169,7 +175,29 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
>
> status->enc_flags |= RX_ENC_FLAG_STBC_MASK * stbc;
>
> - /* TODO: RSSI */
> + status->chains = dev->mt76.antenna_mask;
> + status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
> + status->signal = status->chain_signal[0];
> +
> + switch (status->chains) {
> + case 0x3:
> + status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
> + status->signal = max(status->signal,
> + status->chain_signal[1]);
> + break;
> + case 0x7:
> + status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
> + status->signal = max(status->signal,
> + status->chain_signal[2]);
> + break;
> + case 0xf:
> + status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
> + status->signal = max(status->signal,
> + status->chain_signal[3]);
> + break;
> + default:
> + break;
> + }
> rxd += 6;
> if ((u8 *)rxd - skb->data >= skb->len)
> return -EINVAL;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> index 18ad4b8a3807..b00ce8db58e9
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> @@ -98,6 +98,11 @@ enum rx_pkt_type {
> #define MT_RXV2_GROUP_ID GENMASK(26, 21)
> #define MT_RXV2_LENGTH GENMASK(20, 0)
>
> +#define MT_RXV4_RCPI3 GENMASK(31, 24)
> +#define MT_RXV4_RCPI2 GENMASK(23, 16)
> +#define MT_RXV4_RCPI1 GENMASK(15, 8)
> +#define MT_RXV4_RCPI0 GENMASK(7, 0)
> +
> enum tx_header_format {
> MT_HDR_FORMAT_802_3,
> MT_HDR_FORMAT_CMD,
^ permalink raw reply
* Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh
From: Sebastian Gottschall @ 2019-06-09 14:36 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Ryder Lee, Felix Fietkau, Roy Luo, YF Luo, Yiwei Chung, Sean Wang,
Chih-Min Chen, linux-wireless, linux-mediatek,
Linux Kernel Mailing List
In-Reply-To: <CAJ0CqmVBogQrqf4Gckr5gQ6tCrdZG=p60ZiC+-WW-yxt93+40Q@mail.gmail.com>
by the way. this big fat kernel warning exists in all operation modes
unless anything else but aes-128 ccmp is used. since the chipset is
capable of doing gcmp etc. as well
it would be nice if this issue can be fixed. otherwise encryption
support can be defined as "broken" for mt7615
Am 06.06.2019 um 18:19 schrieb Lorenzo Bianconi:
>> i tested your patch against a qca 9984 chipset using SAE and without
>> encryption. both did not work. the devices are connecting, but no data
>> connection is possible
> Hi Sebastian,
>
> I tested Ryder's patch using mt76x2 as mesh peer and it works fine for me.
> Could you please provide some more info?
>
> Regards,
> Lorenzo
>
>>
>> Sebastian
>>
>> Am 03.06.2019 um 08:08 schrieb Ryder Lee:
>>> Enable NL80211_IFTYPE_MESH_POINT and update its path.
>>>
>>> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>>> ---
>>> Changes since v3 - fix a wrong expression
>>> Changes since v2 - remove unused definitions
>>> ---
>>> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
>>> drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 4 +++-
>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
>>> 4 files changed, 10 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>> index 59f604f3161f..f860af6a42da 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>> @@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
>>> {
>>> .max = MT7615_MAX_INTERFACES,
>>> .types = BIT(NL80211_IFTYPE_AP) |
>>> +#ifdef CONFIG_MAC80211_MESH
>>> + BIT(NL80211_IFTYPE_MESH_POINT) |
>>> +#endif
>>> BIT(NL80211_IFTYPE_STATION)
>>> }
>>> };
>>> @@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
>>> dev->mt76.antenna_mask = 0xf;
>>>
>>> wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
>>> +#ifdef CONFIG_MAC80211_MESH
>>> + BIT(NL80211_IFTYPE_MESH_POINT) |
>>> +#endif
>>> BIT(NL80211_IFTYPE_AP);
>>>
>>> ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>> index b0bb7cc12385..585e67fa2728 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>> @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
>>>
>>> switch (type) {
>>> case NL80211_IFTYPE_AP:
>>> + case NL80211_IFTYPE_MESH_POINT:
>>> /* ap use hw bssid 0 and ext bssid */
>>> if (~mask & BIT(HW_BSSID_0))
>>> return HW_BSSID_0;
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>> index 43f70195244c..e82297048449 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>> @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
>>>
>>> switch (vif->type) {
>>> case NL80211_IFTYPE_AP:
>>> + case NL80211_IFTYPE_MESH_POINT:
>>> tx_wlan_idx = mvif->sta.wcid.idx;
>>> conn_type = CONNECTION_INFRA_AP;
>>> break;
>>> @@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
>>> .rx_wtbl = {
>>> .tag = cpu_to_le16(WTBL_RX),
>>> .len = cpu_to_le16(sizeof(struct wtbl_rx)),
>>> - .rca1 = vif->type != NL80211_IFTYPE_AP,
>>> + .rca1 = vif->type == NL80211_IFTYPE_STATION,
>>> .rca2 = 1,
>>> .rv = 1,
>>> },
>>> @@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype type, u32 *conn_type)
>>> {
>>> switch (type) {
>>> case NL80211_IFTYPE_AP:
>>> + case NL80211_IFTYPE_MESH_POINT:
>>> if (conn_type)
>>> *conn_type = CONNECTION_INFRA_STA;
>>> break;
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>> index e96efb13fa4d..0915cb735699 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>> @@ -105,25 +105,19 @@ enum {
>>> #define STA_TYPE_STA BIT(0)
>>> #define STA_TYPE_AP BIT(1)
>>> #define STA_TYPE_ADHOC BIT(2)
>>> -#define STA_TYPE_TDLS BIT(3)
>>> #define STA_TYPE_WDS BIT(4)
>>> #define STA_TYPE_BC BIT(5)
>>>
>>> #define NETWORK_INFRA BIT(16)
>>> #define NETWORK_P2P BIT(17)
>>> #define NETWORK_IBSS BIT(18)
>>> -#define NETWORK_MESH BIT(19)
>>> -#define NETWORK_BOW BIT(20)
>>> #define NETWORK_WDS BIT(21)
>>>
>>> #define CONNECTION_INFRA_STA (STA_TYPE_STA | NETWORK_INFRA)
>>> #define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
>>> #define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
>>> #define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
>>> -#define CONNECTION_MESH_STA (STA_TYPE_STA | NETWORK_MESH)
>>> -#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
>>> #define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
>>> -#define CONNECTION_TDLS (STA_TYPE_STA | NETWORK_INFRA | STA_TYPE_TDLS)
>>> #define CONNECTION_WDS (STA_TYPE_WDS | NETWORK_WDS)
>>> #define CONNECTION_INFRA_BC (STA_TYPE_BC | NETWORK_INFRA)
>>>
^ permalink raw reply
* Re: [RFC PATCH v2] ath9k: add loader for AR92XX (and older) pci(e)
From: Julian Calaby @ 2019-06-09 13:28 UTC (permalink / raw)
To: Christian Lamparter
Cc: QCA ath9k Development, linux-wireless, Hauke Mehrtens,
Martin Blumenstingl
In-Reply-To: <20190608144947.744-2-chunkeey@gmail.com>
Hi Christian,
On Sun, Jun 9, 2019 at 12:49 AM Christian Lamparter <chunkeey@gmail.com> wrote:
>
> Atheros cards with a AR92XX generation (and older) chip usually
> store their pci(e) initialization vectors on an external eeprom chip.
> However these chips technically don't need the eeprom chip attached,
> the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
> "... if the EEPROM content is not valid, a value of 0XFF1C returns
> when read from the register". So the embedded devices like routers
> and accesspoint usually have the pci(e) initialization vectors
> stored on the system's FLASH, which is out of reach of the ath9k
> chip.
>
> Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
> Teleworker Gateway) need to be able to initialize the PCIe wifi device.
> Normally, this should be done as a pci quirk during the early stages of
> booting linux. However, this isn't possible for devices which have the
> init code for the Atheros chip stored on NAND in an UBI volume.
> Hence, this module can be used to initialize the chip when the
> user-space is ready to extract the init code.
>
> Martin Blumenstingl prodived the following fixes:
> owl-loader: add support for OWL emulation PCI devices
> owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> owl-loader: use dev_* instead of pr_* logging functions
> owl-loader: auto-generate the eeprom filename as fallback
> owl-loader: add a debug message when swapping the eeprom data
> owl-loader: add missing newlines in log messages
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> v2: address Julian Calaby's comments:
> - make it a separate driver again (much like OpenWrt)
> - remove ar71xx leftovers (pdata)
This looks sane to me. Thanks for splitting it out.
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 16 ++
> drivers/net/wireless/ath/ath9k/Makefile | 2 +
> .../wireless/ath/ath9k/ath9k_pci_owl_loader.c | 215 ++++++++++++++++++
> 3 files changed, 233 insertions(+)
> create mode 100644 drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> new file mode 100644
> index 000000000000..7ed495a9f1fe
> --- /dev/null
> +++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> @@ -0,0 +1,215 @@
> +module_pci_driver(owl_driver);
> +MODULE_AUTHOR("Christian Lamparter <chunkeey@gmail.com>");
> +MODULE_DESCRIPTION("Initializes Atheros' Owl Emulation devices");
Tiniest nit: something like "External EEPROM data loader for Atheros
AR500X to AR92XX" would make more sense to someone who isn't familiar
with the hardware.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ 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