* Re: [PATCH] wifi: mt76: mt7915: add support for MT7981 [not found] ` <ZGENDwGXkuhrCGFY@pidgin.makrotopia.org> @ 2023-05-15 11:08 ` Kalle Valo 2023-05-15 11:26 ` Simon Horman 0 siblings, 1 reply; 2+ messages in thread From: Kalle Valo @ 2023-05-15 11:08 UTC (permalink / raw) To: Daniel Golle Cc: Simon Horman, linux-wireless, netdev, linux-mediatek, linux-arm-kernel, linux-kernel, Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen, Sean Wang, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger, AngeloGioacchino Del Regno, Alexander Couzens, Sujuan Chen, Bo Jiao, Nicolas Cavallari, Howard Hsu, MeiChia Chiu, Peter Chiu, Johannes Berg, Wang Yufen, Lorenz Brun Daniel Golle <daniel@makrotopia.org> writes: > On Sun, May 14, 2023 at 04:53:43PM +0200, Simon Horman wrote: >> On Sat, May 13, 2023 at 03:35:51PM +0200, Daniel Golle wrote: >> > From: Alexander Couzens <lynxis@fe80.eu> >> > >> > Add support for the MediaTek MT7981 SoC which is similar to the MT7986 >> > but with a newer IP cores and only 2x ARM Cortex-A53 instead of 4x. >> > Unlike MT7986 the MT7981 can only connect a single wireless frontend, >> > usually MT7976 is used for DBDC. >> > >> > Signed-off-by: Alexander Couzens <lynxis@fe80.eu> >> > Signed-off-by: Daniel Golle <daniel@makrotopia.org> >> >> ... >> >> > @@ -489,7 +516,10 @@ static int mt7986_wmac_adie_patch_7976(struct mt7915_dev *dev, u8 adie) >> > rg_xo_01 = 0x1d59080f; >> > rg_xo_03 = 0x34c00fe0; >> > } else { >> > - rg_xo_01 = 0x1959f80f; >> > + if (is_mt7981(&dev->mt76)) >> > + rg_xo_01 = 0x1959c80f; >> > + else if (is_mt7986(&dev->mt76)) >> > + rg_xo_01 = 0x1959f80f; >> >> Hi Daniel, >> >> rg_xo_01 will be used uninitialised below if we get here >> and neither of the conditions above are true. >> >> Can this occur? > > No, it cannot occur. Either of is_mt7981() or is_mt7986() will return > true, as the driver is bound via one of the two compatibles > 'mediatek,mt7986-wmac' or newly added 'mediatek,mt7981-wmac'. > Based on that the match_data is either 0x7986 or 0x7981, which is then > used as chip_id, which is used by the is_mt7981() and is_mt7986() > functions. But what if later more changes are made, for example a third compatible is added? It would be good to add a warning or something else to protect that. And I would not be a surpised if a compiler or static analyser would even warn about the uninitialised variable. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] wifi: mt76: mt7915: add support for MT7981 2023-05-15 11:08 ` [PATCH] wifi: mt76: mt7915: add support for MT7981 Kalle Valo @ 2023-05-15 11:26 ` Simon Horman 0 siblings, 0 replies; 2+ messages in thread From: Simon Horman @ 2023-05-15 11:26 UTC (permalink / raw) To: Kalle Valo Cc: Daniel Golle, linux-wireless, netdev, linux-mediatek, linux-arm-kernel, linux-kernel, Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen, Sean Wang, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger, AngeloGioacchino Del Regno, Alexander Couzens, Sujuan Chen, Bo Jiao, Nicolas Cavallari, Howard Hsu, MeiChia Chiu, Peter Chiu, Johannes Berg, Wang Yufen, Lorenz Brun On Mon, May 15, 2023 at 02:08:22PM +0300, Kalle Valo wrote: > Daniel Golle <daniel@makrotopia.org> writes: > > > On Sun, May 14, 2023 at 04:53:43PM +0200, Simon Horman wrote: > >> On Sat, May 13, 2023 at 03:35:51PM +0200, Daniel Golle wrote: > >> > From: Alexander Couzens <lynxis@fe80.eu> > >> > > >> > Add support for the MediaTek MT7981 SoC which is similar to the MT7986 > >> > but with a newer IP cores and only 2x ARM Cortex-A53 instead of 4x. > >> > Unlike MT7986 the MT7981 can only connect a single wireless frontend, > >> > usually MT7976 is used for DBDC. > >> > > >> > Signed-off-by: Alexander Couzens <lynxis@fe80.eu> > >> > Signed-off-by: Daniel Golle <daniel@makrotopia.org> > >> > >> ... > >> > >> > @@ -489,7 +516,10 @@ static int mt7986_wmac_adie_patch_7976(struct mt7915_dev *dev, u8 adie) > >> > rg_xo_01 = 0x1d59080f; > >> > rg_xo_03 = 0x34c00fe0; > >> > } else { > >> > - rg_xo_01 = 0x1959f80f; > >> > + if (is_mt7981(&dev->mt76)) > >> > + rg_xo_01 = 0x1959c80f; > >> > + else if (is_mt7986(&dev->mt76)) > >> > + rg_xo_01 = 0x1959f80f; > >> > >> Hi Daniel, > >> > >> rg_xo_01 will be used uninitialised below if we get here > >> and neither of the conditions above are true. > >> > >> Can this occur? > > > > No, it cannot occur. Either of is_mt7981() or is_mt7986() will return > > true, as the driver is bound via one of the two compatibles > > 'mediatek,mt7986-wmac' or newly added 'mediatek,mt7981-wmac'. > > Based on that the match_data is either 0x7986 or 0x7981, which is then > > used as chip_id, which is used by the is_mt7981() and is_mt7986() > > functions. > > But what if later more changes are made, for example a third compatible > is added? It would be good to add a warning or something else to protect > that. > > And I would not be a surpised if a compiler or static analyser would > even warn about the uninitialised variable. FWIIW, gcc-12 [-Wmaybe-uninitialized], clang-16 [-Wsometimes-uninitialized] and smatch warn about this. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-05-15 11:27 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <ZF-SN-sElZB_g_bA@pidgin.makrotopia.org>
[not found] ` <ZGD192iDcUqoUwo3@corigine.com>
[not found] ` <ZGENDwGXkuhrCGFY@pidgin.makrotopia.org>
2023-05-15 11:08 ` [PATCH] wifi: mt76: mt7915: add support for MT7981 Kalle Valo
2023-05-15 11:26 ` Simon Horman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).