Hi, Javier
On Wed, Mar 25, 2026 at 5:14 PM Javier Tia <floss@jetm.me> wrote:
>
> Add PCI device table entries for MT7927 hardware variants:
> - 14c3:7927 (ASUS ROG Crosshair X870E Hero, Lenovo Legion Pro 7)
> - 14c3:6639 (Foxconn/Azurewave modules)
> - 14c3:0738 (AMD RZ738 / MediaTek MT7927)
>
> This is the final patch in the series, enabling MT7927 device
> enumeration after all infrastructure (DMA, IRQ, HW init, band index,
> power management) is in place.
>
> Tested-by: Marcin FM <marcin@lgic.pl>
> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
> Tested-by: George Salukvadze <giosal90@gmail.com>
> Tested-by: Evgeny Kapusta <3193631@gmail.com>
> Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
> Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
> Tested-by: Thibaut François <tibo@humeurlibre.fr>
> Tested-by: 张旭涵 <Loong.0x00@gmail.com>
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
> drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 29 +++++++++++++++----------
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
> index 693e08f35d68..00c3601f14ff 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
> @@ -16,6 +16,12 @@ static const struct pci_device_id mt7925_pci_device_table[] = {
> .driver_data = (kernel_ulong_t)MT7925_FIRMWARE_WM },
> { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x0717),
> .driver_data = (kernel_ulong_t)MT7925_FIRMWARE_WM },
> + { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x7927),
> + .driver_data = (kernel_ulong_t)MT7927_FIRMWARE_WM },
> + { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x6639),
> + .driver_data = (kernel_ulong_t)MT7927_FIRMWARE_WM },
> + { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x0738),
> + .driver_data = (kernel_ulong_t)MT7927_FIRMWARE_WM },
> { },
> };
>
> @@ -530,7 +536,8 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
> if (ret)
> goto err_free_pci_vec;
>
> - is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
> + is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927 ||
> + pdev->device == 0x0738);
>
> /* MT7927: CONNINFRA power domain and WFDMA register access are
> * unreliable with PCIe L1 active, causing throughput to drop
> @@ -546,16 +553,16 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
> goto err_free_pci_vec;
> }
>
> - /* MT7927 firmware lacks the connac2 feature trailer, so
> - * mt792x_get_mac80211_ops() can't detect CNM support and
> - * replaces chanctx/ROC/mgd_prepare_tx ops with stubs.
> - * Force CNM and restore the original mt7925 ops.
> - */
> - if ((pdev->device == 0x6639 || pdev->device == 0x7927) &&
> - !(features & MT792x_FW_CAP_CNM)) {
> - features |= MT792x_FW_CAP_CNM;
> - memcpy(ops, &mt7925_ops, sizeof(*ops));
> - }
> + /* MT7927 firmware lacks the connac2 feature trailer, so
> + * mt792x_get_mac80211_ops() can't detect CNM support and
> + * replaces chanctx/ROC/mgd_prepare_tx ops with stubs.
> + * Force CNM and restore the original mt7925 ops.
> + */
> + if ((pdev->device == 0x6639 || pdev->device == 0x7927 ||
> + pdev->device == 0x0738) && !(features & MT792x_FW_CAP_CNM)) {
> + features |= MT792x_FW_CAP_CNM;
> + memcpy(ops, &mt7925_ops, sizeof(*ops));
> + }
I think the quirk should be applied before the CNM check in
mt792x_get_mac80211_ops().
That helper already owns the fw_features detection and the ops rewrite,
so adding another memcpy() later to restore mt7925_ops feels fragile.
The final ops selection is no longer decided in one place, and the extra
full memcpy() depends on the current call flow and implementation
details of mt792x_get_mac80211_ops().
If MT7927 should force MT792x_FW_CAP_CNM despite the missing trailer,
please fold that into mt792x_get_mac80211_ops() and keep the ops
selection in one place.
>
> mdev = mt76_alloc_device(&pdev->dev, sizeof(*dev), ops, &drv_ops);
> if (!mdev) {
>
> --
> 2.53.0
>
>