Message ID | 20221227233020.284266-1-martin.blumenstingl@googlemail.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp1629720wrt; Tue, 27 Dec 2022 15:33:35 -0800 (PST) X-Google-Smtp-Source: AMrXdXs+LOKzlvtQPuQ2+ozwlyBc+DzlJ6wRf+ypfkWEXIvm3nvESaeL+Atv/VcgoyhF4NN5k4pO X-Received: by 2002:a17:90a:206:b0:219:440f:667e with SMTP id c6-20020a17090a020600b00219440f667emr26126280pjc.16.1672184014901; Tue, 27 Dec 2022 15:33:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672184014; cv=none; d=google.com; s=arc-20160816; b=HaEewV+pCtGDWU5emTrBL2ObL9IkmqOiLniLpJxsZ/Xuei4nQmNVnyay8AKGHl6peJ Hfy7H2EkR5SJeVr8EFKm3JA5q2fnayqfqvDEGBQ1ts4QTo7LzZbrZAZ0TjVC8LKJ4fAY ZeiRgaJVjB9W6kxPG4UN2xupQqh70OQj2MCg8+ApJCOelruVsavLSyESSdy5uSFfk/QX shvmrjNgddxWQMM8Wzez2D3yzszVKc32VBOAYr0DNJm1NL47rlh5qW40raQ7o4aPxQMj tryWARFXBHvWZbe9JmRn1bU50fyQEtDegXOaUQBI5zGJWKA7yRt5fawpTLyYtsrgf2l/ +kjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=gNI4glAP8RCHIX0Vc1rrjcz+Kvrw2hTC3GBQO91dTzE=; b=rPxyxoLPUZ75wnw05owia6rTsWoNvedwm+s7G+CmI7+Ab0sE7EH6cYyucfTlNiFD6j zfTvJp5qKzcKLSoBkym+QlnCPBSzlKhixpCtCDk4PJ0msDGZWVLNYmfXygkdbMN7hR12 kcj9NZD51mFzE+IwXCPKQa2I4aK4gQBI01Yqg4FLr3X+kMywwgYDB93/ezkJyrOEyY0U bsMWXT/B0A7vaW8rsYoHWjNuquLQaP+u3YmGDiigd5Lt9YqKhsnKOVrzj7dQjzm6ypOg yC9VVq2xhA2D+lGJ2kZ0k472QoYGUuMjptAdI72yWzMHskp+toxWR4OSomS+G+qI3L6D EXzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20210112 header.b=PgAZ5aZt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pf1-20020a17090b1d8100b00218ceebbcafsi20782202pjb.130.2022.12.27.15.33.22; Tue, 27 Dec 2022 15:33:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20210112 header.b=PgAZ5aZt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231785AbiL0Xal (ORCPT <rfc822;eddaouddi.ayoub@gmail.com> + 99 others); Tue, 27 Dec 2022 18:30:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229583AbiL0Xai (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 27 Dec 2022 18:30:38 -0500 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5A52B1D; Tue, 27 Dec 2022 15:30:36 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id m21so20870944edc.3; Tue, 27 Dec 2022 15:30:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=gNI4glAP8RCHIX0Vc1rrjcz+Kvrw2hTC3GBQO91dTzE=; b=PgAZ5aZt60CG6sLLPDEVEddXtgBvZGHfbo1q7Kaoz+jVwewez6JV0OjWtiLxgYp3go ZB/sbiE+D/1GRwsm29iOS73d+TJblGHu+/6dMjl7e/jSdgsbZ/tGayRqj4SlrwUkN/FZ 20AzPMvBQCXMRBBOu0pmzBPTV+LKLIwmHCYIzCZ9Byq6xzVZc808I0LoDRtTCmanS219 exX6w96YxESVe38a7SieSwm7goZ0V3nfc3KZvT99EgrQY61Oj4Pn8V5Xk4wj0DchHoqf QTAZxF1fH6HQJ3toICNcXwmpSgvjPw8fM9I8ujGwxoGCvJsV8013XlMduN9sXK9gJDN9 Z4tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gNI4glAP8RCHIX0Vc1rrjcz+Kvrw2hTC3GBQO91dTzE=; b=VOrEV6O+1RjGwO4f3/HGUDBv0qC4KE3TjMviH2gG1xZGiEZCmSnchLvIhWt5ZwTfND IHdpgpN26/moSnH+rCHmt4agaoJGwgToAtyT2oUPypkDvq4olhr+47B0+jGEVAY3Dbz6 8H4bsFwv2VZdHwHANy9JYD2AzD7DKdGN9w/oFPIl42yJr7Usy//7ODNmTyHh2ZMKfm74 529x9FoIdFhSwwd/ltQvbT+EvcNxg6UPFyDKUMkUtKCcjdpI0rMjxuj1+NSmzuD8BO9y ERvux4ECYoFKuc3wE62owLURxv0CaE5yliHrDIH/k/LjIcNNvvKtJtGofXZ0LDfkyKE7 KnXA== X-Gm-Message-State: AFqh2kpjcIzhUbpNiXXevs7B73TYFp9mtSj6UueOZdTehN46SwzQ9EqQ wtIoxxp6N3frBG/ufdcyxHAng6jnWVA= X-Received: by 2002:a50:ec19:0:b0:46c:fabe:837b with SMTP id g25-20020a50ec19000000b0046cfabe837bmr19326490edr.41.1672183834861; Tue, 27 Dec 2022 15:30:34 -0800 (PST) Received: from localhost.localdomain (dynamic-2a01-0c23-c4cf-d900-0000-0000-0000-0e63.c23.pool.telefonica.de. [2a01:c23:c4cf:d900::e63]) by smtp.googlemail.com with ESMTPSA id r7-20020aa7c147000000b0046cbcc86bdesm6489978edp.7.2022.12.27.15.30.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Dec 2022 15:30:34 -0800 (PST) From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> To: linux-wireless@vger.kernel.org Cc: Yan-Hsuan Chuang <tony0620emma@gmail.com>, Kalle Valo <kvalo@kernel.org>, Ulf Hansson <ulf.hansson@linaro.org>, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-mmc@vger.kernel.org, Chris Morgan <macroalpha82@gmail.com>, Nitin Gupta <nitin.gupta981@gmail.com>, Neo Jou <neojou@gmail.com>, Pkshih <pkshih@realtek.com>, Jernej Skrabec <jernej.skrabec@gmail.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com> Subject: [RFC PATCH v1 00/19] rtw88: Add SDIO support Date: Wed, 28 Dec 2022 00:30:01 +0100 Message-Id: <20221227233020.284266-1-martin.blumenstingl@googlemail.com> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753412025785753079?= X-GMAIL-MSGID: =?utf-8?q?1753412025785753079?= |
Series |
rtw88: Add SDIO support
|
|
Message
Martin Blumenstingl
Dec. 27, 2022, 11:30 p.m. UTC
Recently the rtw88 driver has gained locking support for the "slow" bus types (USB, SDIO) as part of USB support. Thanks to everyone who helped make this happen! Based on the USB work (especially the locking part and various bugfixes) this series adds support for SDIO based cards. It's the result of a collaboration between Jernej and myself. Neither of us has access to the rtw88 datasheets. All of our work is based on studying the RTL8822BS and RTL8822CS vendor drivers and trial and error. Jernej and myself have tested this with RTL8822BS and RTL8822CS cards. Other users have confirmed that RTL8821CS support is working as well. RTL8723DS may also work (we tried our best to handle rtw_chip_wcpu_11n where needed) but has not been tested at this point. Jernej's results with a RTL8822BS: - Main functionality works - Had a case where no traffic got across the link until he issued a scan My results with a RTL8822CS: - 2.4GHz and 5GHz bands are both working - TX throughput on a 5GHz network is between 50 Mbit/s and 90 Mbit/s - RX throughput on a 5GHz network is at 19 Mbit/s - Sometimes there are frequent reconnects (once every 1-5 minutes) after the link has been up for a long time (multiple hours). Today I was unable to reproduce this though (I only had reconnect in 8 hours). Why is this an RFC? - It needs a through review especially by the rtw88 maintainers - It's not clear to me how the "mmc: sdio" patch will be merged (will Ulf take this or can we merge it thorugh the rtw88/linux wireless driver tree?) - Any comments / debugging hints on the reconnect / no traffic issues (see above) are welcome - My understanding is that there's a discussion about the rtw88 Kconfig symbols. We're adding four new ones within this series. It's not clear to me what the conclusion is on this topic though. - As with most patches: testing is very welcome. If things are working fine then a Tested-by is appreciated (with some details about the card, throughput, ...). If something doesn't work for you: please still report back so we can investigate that problem! Jernej Skrabec (2): rtw88: ps: Increase LEAVE_LPS_TRY_CNT for SDIO based chipsets rtw88: Add support for the SDIO based RTL8822BS chipset Martin Blumenstingl (17): rtw88: mac: Use existing interface mask macros in rtw_pwr_seq_parser() rtw88: pci: Change type of rtw_hw_queue_mapping() and ac_to_hwq to enum rtw88: pci: Change queue datatype from u8 to enum rtw_tx_queue_type rtw88: Move enum rtw_tx_queue_type mapping code to tx.{c,h} mmc: sdio: add Realtek SDIO vendor ID and various wifi device IDs rtw88: rtw8821c: Add support for parsing the RTL8821CS (SDIO) efuse rtw88: rtw8822b: Add support for parsing the RTL8822BS (SDIO) efuse rtw88: rtw8822c: Add support for parsing the RTL8822CS (SDIO) efuse rtw88: hci: Add an optional power_switch() callback to rtw_hci_ops rtw88: mac: Add support for the SDIO HCI in rtw_pwr_seq_parser() rtw88: mac: Add support for the SDIO HCI in the TX/page table setup rtw88: sdio: Add HCI implementation for SDIO based chipsets rtw88: mac: Add support for SDIO specifics in the power on sequence rtw88: main: Add the rpwm_addr and cpwm_addr for SDIO based chipsets rtw88: main: Reserve 8 bytes of extra TX headroom for SDIO based cards rtw88: Add support for the SDIO based RTL8822CS chipset rtw88: Add support for the SDIO based RTL8821CS chipset drivers/net/wireless/realtek/rtw88/Kconfig | 36 + drivers/net/wireless/realtek/rtw88/Makefile | 12 + drivers/net/wireless/realtek/rtw88/debug.h | 1 + drivers/net/wireless/realtek/rtw88/hci.h | 8 + drivers/net/wireless/realtek/rtw88/mac.c | 62 +- drivers/net/wireless/realtek/rtw88/mac.h | 1 - drivers/net/wireless/realtek/rtw88/main.c | 9 +- drivers/net/wireless/realtek/rtw88/pci.c | 50 +- drivers/net/wireless/realtek/rtw88/ps.h | 2 +- drivers/net/wireless/realtek/rtw88/reg.h | 10 + drivers/net/wireless/realtek/rtw88/rtw8821c.c | 9 + drivers/net/wireless/realtek/rtw88/rtw8821c.h | 6 + .../net/wireless/realtek/rtw88/rtw8821cs.c | 34 + drivers/net/wireless/realtek/rtw88/rtw8822b.c | 10 + drivers/net/wireless/realtek/rtw88/rtw8822b.h | 6 + .../net/wireless/realtek/rtw88/rtw8822bs.c | 34 + drivers/net/wireless/realtek/rtw88/rtw8822c.c | 9 + drivers/net/wireless/realtek/rtw88/rtw8822c.h | 6 + .../net/wireless/realtek/rtw88/rtw8822cs.c | 34 + drivers/net/wireless/realtek/rtw88/sdio.c | 1242 +++++++++++++++++ drivers/net/wireless/realtek/rtw88/sdio.h | 175 +++ drivers/net/wireless/realtek/rtw88/tx.c | 41 + drivers/net/wireless/realtek/rtw88/tx.h | 3 + include/linux/mmc/sdio_ids.h | 9 + 24 files changed, 1763 insertions(+), 46 deletions(-) create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8821cs.c create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822bs.c create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822cs.c create mode 100644 drivers/net/wireless/realtek/rtw88/sdio.c create mode 100644 drivers/net/wireless/realtek/rtw88/sdio.h
Comments
> -----Original Message----- > From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > Sent: Wednesday, December 28, 2022 7:30 AM > To: linux-wireless@vger.kernel.org > Cc: Yan-Hsuan Chuang <tony0620emma@gmail.com>; Kalle Valo <kvalo@kernel.org>; Ulf Hansson > <ulf.hansson@linaro.org>; linux-kernel@vger.kernel.org; netdev@vger.kernel.org; > linux-mmc@vger.kernel.org; Chris Morgan <macroalpha82@gmail.com>; Nitin Gupta <nitin.gupta981@gmail.com>; > Neo Jou <neojou@gmail.com>; Ping-Ke Shih <pkshih@realtek.com>; Jernej Skrabec <jernej.skrabec@gmail.com>; > Martin Blumenstingl <martin.blumenstingl@googlemail.com> > Subject: [RFC PATCH v1 00/19] rtw88: Add SDIO support > > Recently the rtw88 driver has gained locking support for the "slow" bus > types (USB, SDIO) as part of USB support. Thanks to everyone who helped > make this happen! > > Based on the USB work (especially the locking part and various > bugfixes) this series adds support for SDIO based cards. It's the > result of a collaboration between Jernej and myself. Neither of us has > access to the rtw88 datasheets. All of our work is based on studying > the RTL8822BS and RTL8822CS vendor drivers and trial and error. > > Jernej and myself have tested this with RTL8822BS and RTL8822CS cards. > Other users have confirmed that RTL8821CS support is working as well. > RTL8723DS may also work (we tried our best to handle rtw_chip_wcpu_11n > where needed) but has not been tested at this point. > > Jernej's results with a RTL8822BS: > - Main functionality works > - Had a case where no traffic got across the link until he issued a > scan > > My results with a RTL8822CS: > - 2.4GHz and 5GHz bands are both working > - TX throughput on a 5GHz network is between 50 Mbit/s and 90 Mbit/s > - RX throughput on a 5GHz network is at 19 Mbit/s I have a suggestion about RX throughput, please check below registers with vendor driver: REG_RXDMA_AGG_PG_TH REG_TXDMA_PQ_MAP(0x10c) BIT_RXDMA_AGG_EN (bit2) REG_RXDMA_MODE(0290) BIT_DMA_MODE (bit1) Try to adjust AGG_PG_TH to see if it can help. -- Ping-Ke
Hi Ping-Ke, thanks again for all your input! On Thu, Dec 29, 2022 at 5:19 AM Ping-Ke Shih <pkshih@realtek.com> wrote: [...] > > - RX throughput on a 5GHz network is at 19 Mbit/s > > I have a suggestion about RX throughput, please check below registers with > vendor driver: > > REG_RXDMA_AGG_PG_TH > REG_TXDMA_PQ_MAP(0x10c) BIT_RXDMA_AGG_EN (bit2) > REG_RXDMA_MODE(0290) BIT_DMA_MODE (bit1) Unfortunately I didn't manage to get the vendor driver to work with mainline Linux. The Android installation on my board (which is how it was shipped) uses the vendor driver but unlike some Amlogic code the Realtek (vendor) wireless driver does not allow reading arbitrary registers through sysfs. So I can't check the values that the vendor driver uses. > Try to adjust AGG_PG_TH to see if it can help. I tried a few values and I can say that it does change the RX throughput, but the result is always lower than 19 Mbit/s, meaning that it's worse than RX aggregation disabled (on my RTL8822CS). Currently we're disabling RX aggregation in the driver. But Jernej mentioned previously that for his RTL8822BS he found that RX aggregation seems to improve performance. Independent of this I did some investigation on my own and found that when reducing the TX throughput the RX throughput increases. For this I tried using ieee80211_{stop,wake}_queue() in the sdio.c HCI sub-driver. RX throughput is now at 23.5 Mbit/s (that +25% compared to before) on my RTL8822CS (with RX aggregation still disabled, just like in the 19 Mbit/s test). Unfortunately TX throughput is now way below 10 Mbit/s. Additionally I think that the antenna of my board is worse than my access point's antenna. So TX from rtw88 to my AP may be faster (because the AP can "hear better") than RX (rtw88 "hearing is worse"). For today I'm tired and will stop here. Best regards, Martin [0] https://github.com/xdarklight/linux/commit/3f2e6b9cd40dc785b5c72dbc9c8b471a2e205344
On Fri, 2022-12-30 at 00:18 +0100, Martin Blumenstingl wrote: > Hi Ping-Ke, > > thanks again for all your input! > > On Thu, Dec 29, 2022 at 5:19 AM Ping-Ke Shih <pkshih@realtek.com> wrote: > [...] > > > - RX throughput on a 5GHz network is at 19 Mbit/s > > > > I have a suggestion about RX throughput, please check below registers with > > vendor driver: > > > > REG_RXDMA_AGG_PG_TH > > REG_TXDMA_PQ_MAP(0x10c) BIT_RXDMA_AGG_EN (bit2) > > REG_RXDMA_MODE(0290) BIT_DMA_MODE (bit1) > Unfortunately I didn't manage to get the vendor driver to work with > mainline Linux. > The Android installation on my board (which is how it was shipped) > uses the vendor driver but unlike some Amlogic code the Realtek > (vendor) wireless driver does not allow reading arbitrary registers > through sysfs. > So I can't check the values that the vendor driver uses. > > > Try to adjust AGG_PG_TH to see if it can help. > I tried a few values and I can say that it does change the RX > throughput, but the result is always lower than 19 Mbit/s, meaning > that it's worse than RX aggregation disabled (on my RTL8822CS). > Currently we're disabling RX aggregation in the driver. But Jernej > mentioned previously that for his RTL8822BS he found that RX > aggregation seems to improve performance. > > Independent of this I did some investigation on my own and found that > when reducing the TX throughput the RX throughput increases. > For this I tried using ieee80211_{stop,wake}_queue() in the sdio.c HCI > sub-driver. > RX throughput is now at 23.5 Mbit/s (that +25% compared to before) on > my RTL8822CS (with RX aggregation still disabled, just like in the 19 > Mbit/s test). > Unfortunately TX throughput is now way below 10 Mbit/s. > > Additionally I think that the antenna of my board is worse than my > access point's antenna. So TX from rtw88 to my AP may be faster > (because the AP can "hear better") than RX (rtw88 "hearing is worse"). > Without equipment like CAT-C, it is hard to investigate SDIO usb aggregation, so I suggest to capture WiFi packets in the air to make sure things work as expected. After that, we can focus on bus aggregation tuning. The instructions to use another WiFi card to capture packets are: 1. sudo iw dev wlan0 interface add mon0 type monitor 2. sudo wireshark // select mon0 to capture Please check AMPDU and AMSDU size during doing TX/RX throughput test. Normally, expected AMSDU size is 3000+ bytes, and AMPDU number is around 32 MSDUs. If RX is too slow resulting in buffer overflow, AP could resend (check sequence number and 'R' bit, or BA of 8822CS). Also, check TX/RX rates to know if RF calibration and PHY dynamic mechanism work well. Normally, with 50cm distance long from AP, it must yield the highest rate, no doubt. I hope this can narrow down the problems you met. --- Ping-Ke
(Jakub, a question for you below) Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes: > Recently the rtw88 driver has gained locking support for the "slow" bus > types (USB, SDIO) as part of USB support. Thanks to everyone who helped > make this happen! > > Based on the USB work (especially the locking part and various > bugfixes) this series adds support for SDIO based cards. It's the > result of a collaboration between Jernej and myself. Neither of us has > access to the rtw88 datasheets. All of our work is based on studying > the RTL8822BS and RTL8822CS vendor drivers and trial and error. > > Jernej and myself have tested this with RTL8822BS and RTL8822CS cards. > Other users have confirmed that RTL8821CS support is working as well. > RTL8723DS may also work (we tried our best to handle rtw_chip_wcpu_11n > where needed) but has not been tested at this point. Very nice, good work. Our recommendation is to have maximum of 10-12 patches per patchset to make it easier for us maintainers, any chance to split the patchset into two? For example, get the easy preparation patches into wireless-next first and later submit the actual SDIO support. [...] > Why is this an RFC? [...] > - My understanding is that there's a discussion about the rtw88 Kconfig > symbols. We're adding four new ones within this series. It's not > clear to me what the conclusion is on this topic though. Yeah, there were no conclusions about that. Jakub, do you have any opinions? For example, do we keep per device Kconfig options (eg. CONFIG_RTW88_8822BS, RTW88_8822CS and so on) or should we have only one more bus level option (eg. CONFIG_RTW88_SDIO)? rtw88 now uses the former and IIRC so does mt76. ath10k/ath11k/ath12k again use the latter :)
On Mon, 16 Jan 2023 18:01:05 +0200 Kalle Valo wrote: > > - My understanding is that there's a discussion about the rtw88 Kconfig > > symbols. We're adding four new ones within this series. It's not > > clear to me what the conclusion is on this topic though. > > Yeah, there were no conclusions about that. Jakub, do you have any > opinions? For example, do we keep per device Kconfig options (eg. > CONFIG_RTW88_8822BS, RTW88_8822CS and so on) or should we have only one > more bus level option (eg. CONFIG_RTW88_SDIO)? rtw88 now uses the former > and IIRC so does mt76. ath10k/ath11k/ath12k again use the latter :) No strong feelings. Larry (IIRC) provided a fair justification for the RTW symbols. If the module binary grows noticeably then having the kconfig does indeed make sense.
Jakub Kicinski <kuba@kernel.org> writes: > On Mon, 16 Jan 2023 18:01:05 +0200 Kalle Valo wrote: >> > - My understanding is that there's a discussion about the rtw88 Kconfig >> > symbols. We're adding four new ones within this series. It's not >> > clear to me what the conclusion is on this topic though. >> >> Yeah, there were no conclusions about that. Jakub, do you have any >> opinions? For example, do we keep per device Kconfig options (eg. >> CONFIG_RTW88_8822BS, RTW88_8822CS and so on) or should we have only one >> more bus level option (eg. CONFIG_RTW88_SDIO)? rtw88 now uses the former >> and IIRC so does mt76. ath10k/ath11k/ath12k again use the latter :) > > No strong feelings. Larry (IIRC) provided a fair justification for > the RTW symbols. If the module binary grows noticeably then having > the kconfig does indeed make sense. Thanks, makes sense. So the plan is that rtw88 continues to use per device Kconfig symbols with SDIO.