* 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).