Re: iwx not getting to status: active
Confirmed it is also work. iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x00, msix Regards, zxystd
Re: iwm(4): use new firmware images with fragattack fixes
Hi Stefan,
Did we missed the 'umac_prph_offset' constant value in
iwm_clear_persistence_bit function? From linux code, it is read_umac_prph, not
read_prph, so the function should be looks like this:
int
+iwm_clear_persistence_bit(struct iwm_softc *sc)
+{
+ uint32_t hpm, wprot;
+
+ hpm = iwm_read_prph_unlocked(sc, umac_prph_offset + IWM_HPM_DEBUG);
+ if (hpm != 0xa5a5a5a0 && (hpm & IWM_HPM_PERSISTENCE_BIT)) {
+ wprot = iwm_read_prph_unlocked(sc, umac_prph_offset +
IWM_PREG_PRPH_WPROT_9000);
+ if (wprot & IWM_PREG_WFPM_ACCESS) {
+ printf("%s: cannot clear persistence bit\n",
+ DEVNAME(sc));
+ return EPERM;
+ }
+ iwm_write_prph_unlocked(sc, umac_prph_offset + IWM_HPM_DEBUG,
+ hpm & ~IWM_HPM_PERSISTENCE_BIT);
+ }
Thank you for the big work!
-- Original --
From: "Stefan Sperling" ;
Date: Tue, May 25, 2021 09:48 PM
To: "tech";
Subject: iwm(4): use new firmware images with fragattack fixes
This patch allows iwm(4) to use new firmware images which are part
of the iwm-20210512 firmware package, available via fw_update (you
need to run fw_update *before* booting with this patch).
The new firmware images were published right after the fragattacks
embargo period ended. An advisory was published by Intel:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html
I have tested the following cards successfully:
7265, 8265, 9260, 9560
I cannot test any other devices myself right now; help with testing this
patch would be much appreciated. It is likely that all devices will work.
But I would still prefer to see test reports for the following cards before
committing this patch:
7260, 3160, 3165, 3168, 8260
The 7260 and 3160 cards did not receive firmware updates from Intel. Which
could be good or bad news, depending on whether the devices are vulnerable
to fragattacks. The fragattacks test tools might shed light on this if you
are curious. I'd be interested to learn more if you have test results or
any other solid information regarding this.
Re: iwm(4): use new firmware images with fragattack fixes
Got it!
I am trying to upgrade iwx firmwares version to -59 to support future gen3
devices and I found this section, so I post the info, that's my fault, thank
you for correct me!
Regards,
zxystd
-- Original --
From: "Stefan Sperling" ;
Date: Mon, Jun 14, 2021 05:23 PM
To: "zxystd";
Cc: "tech";
Subject: Re: iwm(4): use new firmware images with fragattack fixes
On Mon, Jun 14, 2021 at 03:58:39PM +0800, zxystd wrote:
> Hi Stefan,
>
> Did we missed the 'umac_prph_offset' constant value in
> iwm_clear_persistence_bit function? From linux code, it is read_umac_prph,
> not read_prph, so the function should be looks like this:
>
> int
> +iwm_clear_persistence_bit(struct iwm_softc *sc)
> +{
> + uint32_t hpm, wprot;
> +
> + hpm = iwm_read_prph_unlocked(sc, umac_prph_offset + IWM_HPM_DEBUG);
This patch is about iwm(4) only, so we don't need umac_prph_offset here.
As far as I can tell, umac_prph_offset is 0 on every device, except on
AX201 devices where it is 0x30. See cfg/22000.c in iwlwifi:
#define IWL_DEVICE_AX210\
IWL_DEVICE_22000_COMMON,\
.trans.umac_prph_offset = 0x30, \
I don't see this constant being set anywhere else.
iwm(4) will never support AX201 devices. We only need to take care of
this offset in iwx(4) which could eventually add support for AX201.
Re: iwm(4): use new firmware images with fragattack fixes
Hi,
Did we missed the 'umac_prph_offset' constant value in
iwm_clear_persistence_bit function? From linux code, it is read_umac_prph, not
read_prph, so the function should be looks like this:
int
+iwm_clear_persistence_bit(struct iwm_softc *sc)
+{
+ uint32_t hpm, wprot;
+
+ hpm = iwm_read_prph_unlocked(sc, umac_prph_offset + IWM_HPM_DEBUG);
+ if (hpm != 0xa5a5a5a0 && (hpm & IWM_HPM_PERSISTENCE_BIT)) {
+ wprot = iwm_read_prph_unlocked(sc, umac_prph_offset +
IWM_PREG_PRPH_WPROT_9000);
+ if (wprot & IWM_PREG_WFPM_ACCESS) {
+ printf("%s: cannot clear persistence bit\n",
+ DEVNAME(sc));
+ return EPERM;
+ }
+ iwm_write_prph_unlocked(sc, umac_prph_offset + IWM_HPM_DEBUG,
+ hpm & ~IWM_HPM_PERSISTENCE_BIT);
+ }
Thank you for the big work!
-- Original --
From: "Stefan Sperling" ;
Date: Tue, May 25, 2021 09:48 PM
To: "tech";
Subject: iwm(4): use new firmware images with fragattack fixes
This patch allows iwm(4) to use new firmware images which are part
of the iwm-20210512 firmware package, available via fw_update (you
need to run fw_update *before* booting with this patch).
The new firmware images were published right after the fragattacks
embargo period ended. An advisory was published by Intel:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html
I have tested the following cards successfully:
7265, 8265, 9260, 9560
I cannot test any other devices myself right now; help with testing this
patch would be much appreciated. It is likely that all devices will work.
But I would still prefer to see test reports for the following cards before
committing this patch:
7260, 3160, 3165, 3168, 8260
The 7260 and 3160 cards did not receive firmware updates from Intel. Which
could be good or bad news, depending on whether the devices are vulnerable
to fragattacks. The fragattacks test tools might shed light on this if you
are curious. I'd be interested to learn more if you have test results or
any other solid information regarding this.
clean iwx unused firmware dma allocation
It is not a functionality change. The firmware dma is not actually used and it
is due to ported from iwm, this patch remove this allocation.
By the way, firmware monitor code is not ported done and not work, right?
Index: sys/dev/pci/if_iwx.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
retrieving revision 1.50
diff -u -p -u -r1.50 if_iwx.c
--- sys/dev/pci/if_iwx.c 17 Mar 2021 15:59:27 - 1.50
+++ sys/dev/pci/if_iwx.c 2 Apr 2021 05:31:06 -
@@ -7928,7 +7928,6 @@ iwx_attach(struct device *parent, struct
case PCI_PRODUCT_INTEL_WL_22500_1:
sc->sc_fwname = "iwx-cc-a0-48";
sc->sc_device_family = IWX_DEVICE_FAMILY_22000;
- sc->sc_fwdmasegsz = IWX_FWDMASEGSZ_8000;
sc->sc_integrated = 1;
sc->sc_ltr_delay = IWX_SOC_FLAGS_LTR_APPLY_DELAY_NONE;
sc->sc_low_latency_xtal = 0;
@@ -7945,7 +7944,6 @@ iwx_attach(struct device *parent, struct
sc->sc_fwname = "iwx-QuZ-a0-hr-b0-48";
sc->sc_device_family = IWX_DEVICE_FAMILY_22000;
- sc->sc_fwdmasegsz = IWX_FWDMASEGSZ_8000;
sc->sc_integrated = 1;
sc->sc_ltr_delay = IWX_SOC_FLAGS_LTR_APPLY_DELAY_200;
sc->sc_low_latency_xtal = 0;
@@ -7956,7 +7954,6 @@ iwx_attach(struct device *parent, struct
case PCI_PRODUCT_INTEL_WL_22500_4:
sc->sc_fwname = "iwx-Qu-c0-hr-b0-48";
sc->sc_device_family = IWX_DEVICE_FAMILY_22000;
- sc->sc_fwdmasegsz = IWX_FWDMASEGSZ_8000;
sc->sc_integrated = 1;
sc->sc_ltr_delay = IWX_SOC_FLAGS_LTR_APPLY_DELAY_200;
sc->sc_low_latency_xtal = 0;
@@ -8016,24 +8013,12 @@ iwx_attach(struct device *parent, struct
return;
}
- /*
- * Allocate DMA memory for firmware transfers.
- * Must be aligned on a 16-byte boundary.
- */
- err = iwx_dma_contig_alloc(sc->sc_dmat, >fw_dma,
- sc->sc_fwdmasegsz, 16);
- if (err) {
- printf("%s: could not allocate memory for firmware transfers\n",
- DEVNAME(sc));
- goto fail0;
- }
-
/* Allocate interrupt cause table (ICT).*/
err = iwx_dma_contig_alloc(sc->sc_dmat, >ict_dma,
IWX_ICT_SIZE, 1rxq);
if (err) {
printf("%s: could not allocate RX ring\n", DEVNAME(sc));
- goto fail4;
+ goto fail2;
}
sc->sc_nswq = taskq_create("iwxns", 1, IPL_NET, 0);
if (sc->sc_nswq == NULL)
- goto fail4;
+ goto fail2;
ic->ic_phytype = IEEE80211_T_OFDM; /* not only, but not used */
ic->ic_opmode = IEEE80211_M_STA; /* default to BSS mode */
@@ -8141,14 +8126,13 @@ iwx_attach(struct device *parent, struct
return;
-fail4: while (--txq_i >= 0)
+fail2: while (--txq_i >= 0)
iwx_free_tx_ring(sc, >txq[txq_i]);
iwx_free_rx_ring(sc, >rxq);
iwx_dma_contig_free(>sched_dma);
-fail3: if (sc->ict_dma.vaddr != NULL)
+fail1: if (sc->ict_dma.vaddr != NULL)
iwx_dma_contig_free(>ict_dma);
-fail1: iwx_dma_contig_free(>fw_dma);
fail0: iwx_dma_contig_free(>ctxt_info_dma);
return;
}
Index: sys/dev/pci/if_iwxvar.h
===
RCS file: /cvs/src/sys/dev/pci/if_iwxvar.h,v
retrieving revision 1.13
diff -u -p -u -r1.13 if_iwxvar.h
--- sys/dev/pci/if_iwxvar.h 11 Oct 2020 07:05:28 - 1.13
+++ sys/dev/pci/if_iwxvar.h 2 Apr 2021 05:31:06 -
@@ -124,8 +124,6 @@ struct iwx_tx_radiotap_header {
(1 << IEEE80211_RADIOTAP_CHANNEL))
#define IWX_UCODE_SECT_MAX 42
-#define IWX_FWDMASEGSZ (192*1024)
-#define IWX_FWDMASEGSZ_8000 (320*1024)
/* sanity check value */
#define IWX_FWMAXSIZE (2*1024*1024)
@@ -401,8 +399,6 @@ struct iwx_softc {
#define IWX_DEVICE_FAMILY_22000 1
#define IWX_DEVICE_FAMILY_22560 2
- struct iwx_dma_info fw_dma;
-
struct iwx_dma_info ctxt_info_dma;
struct iwx_self_init_dram init_dram;
@@ -438,7 +434,6 @@ struct iwx_softc {
int sc_cap_off; /* PCIe caps */
const char *sc_fwname;
- bus_size_t sc_fwdmasegsz;
struct iwx_fw_info sc_fw;
struct iwx_dma_info fw_mon;
int sc_fw_phy_config;
Re: Fix iwx wrong ac indexs.
OK. seems it is the only reason why I can see the difference. Thank you. ---Original--- From: "Stefan Sperling"
Fix iwx wrong ac indexs.
The indexes into the ac array in the iwx_mac_ctxt_cmd_common are from the
iwx_ac enum and not the txfs. The current code therefore puts the edca params
in the wrong indexes of the array, causing wrong priority for data-streams of
different ACs. This bug is not exists in iwm as its txf number is equal to the
corresponding ac in the iwx_ac enum.
Index: src/sys/dev/pci/if_iwx.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
retrieving revision 1.50
diff -u -p -u -r1.50 if_iwx.c
--- src/sys/dev/pci/if_iwx.c17 Mar 2021 15:59:27 - 1.50
+++ src/sys/dev/pci/if_iwx.c18 Mar 2021 03:28:04 -
@@ -5135,6 +5135,17 @@ iwx_ack_rates(struct iwx_softc *sc, stru
*ofdm_rates = ofdm;
}
+static uint8_t iwx_mac80211_ac_to_ucode_ac(enum ieee80211_edca_ac ac)
+{
+ static const uint8_t iwx_ac_to_ucode_ac[] = {
+ IWX_AC_VO,
+ IWX_AC_VI,
+ IWX_AC_BE,
+ IWX_AC_BK
+ };
+ return iwx_ac_to_ucode_ac[ac];
+}
+
void
iwx_mac_ctxt_cmd_common(struct iwx_softc *sc, struct iwx_node *in,
struct iwx_mac_ctx_cmd *cmd, uint32_t action)
@@ -5181,12 +5192,13 @@ iwx_mac_ctxt_cmd_common(struct iwx_softc
for (i = 0; i < EDCA_NUM_AC; i++) {
struct ieee80211_edca_ac_params *ac = >ic_edca_ac[i];
int txf = iwx_ac_to_tx_fifo[i];
+ uint8_t ucode_ac = iwx_mac80211_ac_to_ucode_ac(i);
- cmd->ac[txf].cw_min = htole16(IWX_EXP2(ac->ac_ecwmin));
- cmd->ac[txf].cw_max = htole16(IWX_EXP2(ac->ac_ecwmax));
- cmd->ac[txf].aifsn = ac->ac_aifsn;
- cmd->ac[txf].fifos_mask = (1 << txf);
- cmd->ac[txf].edca_txop = htole16(ac->ac_txoplimit * 32);
+ cmd->ac[ucode_ac].cw_min = htole16(IWX_EXP2(ac->ac_ecwmin));
+ cmd->ac[ucode_ac].cw_max = htole16(IWX_EXP2(ac->ac_ecwmax));
+ cmd->ac[ucode_ac].aifsn = ac->ac_aifsn;
+ cmd->ac[ucode_ac].fifos_mask = (1 << txf);
+ cmd->ac[ucode_ac].edca_txop = htole16(ac->ac_txoplimit * 32);
}
if (ni->ni_flags & IEEE80211_NODE_QOS)
cmd->qos_flags |= htole32(IWX_MAC_QOS_FLG_UPDATE_EDCA);
