So I understand the reasoning behind using ETH_DATA_LEN, but would it be more future proof / obvious to the next dev to calculate the size given the interface's parameters/defines--- I get that the values were chosen to align with this but just worried if things were to change over time this would not be resilient/obvious thing to fix up? I was curious if these changes would have any impact on things like WEP where the frames are a little larger? I came across a random post about 80211 mdsu/mtus here https://www.cwnp.com/forums/posts?postNum=307311 and they had mentioned it, so it got me curious On Tue, Nov 26, 2019 at 7:00 PM Wen Gong <wgong@xxxxxxxxxxxxxx> wrote: > > For sdio chip, the max credit size in firmware is 1556, the 1556 > include payload, ieee80211 header, htt header, htc header. So it > need to set the max mtu to 1500 to forbidden TX packet which exceed > 1500 form application. > > Tested with QCA6174 SDIO with firmware > WLAN.RMH.4.4.1-00017-QCARMSWP-1. > > Signed-off-by: Wen Gong <wgong@xxxxxxxxxxxxxx> > --- > drivers/net/wireless/ath/ath10k/sdio.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c > index 60849ab8088f..8aa8ebc1d8e9 100644 > --- a/drivers/net/wireless/ath/ath10k/sdio.c > +++ b/drivers/net/wireless/ath/ath10k/sdio.c > @@ -2185,6 +2185,8 @@ static int ath10k_sdio_probe(struct sdio_func *func, > bus_params.chip_id = 0; > bus_params.hl_msdu_ids = true; > > + ar->hw->max_mtu = ETH_DATA_LEN; > + > ret = ath10k_core_register(ar, &bus_params); > if (ret) { > ath10k_err(ar, "failed to register driver core: %d\n", ret); > -- > 2.23.0 >
