From: "Pali Rohár" <pali@kernel.org> To: "Toke Høiland-Jørgensen" <toke@redhat.com> Cc: vtolkm@gmail.com, "Bjorn Helgaas" <helgaas@kernel.org>, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Rob Herring" <robh@kernel.org>, "Ilias Apalodimas" <ilias.apalodimas@linaro.org>, "Marek Behún" <marek.behun@nic.cz>, "Thomas Petazzoni" <thomas.petazzoni@bootlin.com> Subject: Re: PCI trouble on mvebu (Turris Omnia) Date: Mon, 29 Mar 2021 19:09:29 +0200 [thread overview] Message-ID: <20210329170929.uhpttc4oxbkghkpr@pali> (raw) In-Reply-To: <87ft0hby6p.fsf@toke.dk> On Friday 26 March 2021 18:51:42 Toke Høiland-Jørgensen wrote: > Pali Rohár <pali@kernel.org> writes: > > On Friday 26 March 2021 17:54:38 Toke Høiland-Jørgensen wrote: > >> So we have these > >> cases: > >> > >> ASPM disabled: ath9k, ath10k and mt76 cards all work > >> ASPM enabled, no patch: only mt76 card works > >> ASPM enabled + patch: ath10k and mt76 cards work > >> > >> So IDK, maybe the ath9k card needs a quirk as well? Or the mvebu board > >> is just generally flaky? > > > > I'm not sure. Maybe ASPM is somehow buggy on ath9k or needs some special > > handling. But issue is not at PCI config space as ath9k driver start > > initialization of this card. Needs also some debugging in ath9k driver > > if it prints that strange "mac chip rev" error. > > Well that's just being output because it gets a revision that it doesn't > recognise - which it seems to be just reading from a register: > > https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/ath9k/hw.c#L255 > > The value returned is consistent with the value returned just being > 0xffffffff. Which from looking at ioread32() is the value being returned > on a failed read. So there's a driver bug there - the check against -EIO > here is obviously nonsensical: > > https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/ath9k/hw.c#L290 > > But the underlying cause appears to be that the read from the register > fails, which I suppose is related to something the PCI bus does? > > > I think this issue should be handled separately. Could you report it > > also to ath9k mailing list (and CC me)? Maybe other ath developers would > > know some more details. > > I'll send a patch for the nonsensical check above, but other than that I > think we're still in PCI land here, or? First, can you try to enable my quirk also for this ath9k card with ASPM enabled? I have there another ath9k card which after toggling link retraining changes PCI device ID (really!) to 0xABCD. But lspci ... There is long story about broken ath9k cards that are reporting 0xABCD id on x86 machines with specific BIOS versions. It can be find in ath9k-devel mailing list archive: https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg07529.html Maybe we now found root cause of this ABCD? If yes, then it also answers why above ath9k driver check fails (device id was changed) and also because kernel see correct id (kernel reads id before configuring ASPM and therefore before triggering link retraining). > >> > Can you send PCI device id of your ath9k card (lspci -nn)? Because all > >> > my tested ath9k cards have different PCI device id. > >> > >> [root@omnia-arch ~]# lspci -nn > >> 00:01.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6820] (rev 04) > >> 00:02.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6820] (rev 04) > >> 00:03.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6820] (rev 04) > >> 01:00.0 Network controller [0280]: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) [168c:002e] (rev 01) > >> 02:00.0 Network controller [0280]: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter [168c:003c] > > > > That is fine. Also all ath9k testing cards have id 0x002e. Today I found out that lspci -nn may lie! Please send output from command: lspci -nn -x because real PCI device id can read only from -x hexdump output. > >> >> When booting with the > >> >> patch applied, I get this in dmesg: > >> >> > >> >> [ 3.556599] ath: phy0: Mac Chip Rev 0xfffc0.f is not supported by this driver
WARNING: multiple messages have this Message-ID (diff)
From: "Pali Rohár" <pali@kernel.org> To: "Toke Høiland-Jørgensen" <toke@redhat.com> Cc: vtolkm@gmail.com, "Bjorn Helgaas" <helgaas@kernel.org>, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Rob Herring" <robh@kernel.org>, "Ilias Apalodimas" <ilias.apalodimas@linaro.org>, "Marek Behún" <marek.behun@nic.cz>, "Thomas Petazzoni" <thomas.petazzoni@bootlin.com> Subject: Re: PCI trouble on mvebu (Turris Omnia) Date: Mon, 29 Mar 2021 19:09:29 +0200 [thread overview] Message-ID: <20210329170929.uhpttc4oxbkghkpr@pali> (raw) In-Reply-To: <87ft0hby6p.fsf@toke.dk> On Friday 26 March 2021 18:51:42 Toke Høiland-Jørgensen wrote: > Pali Rohár <pali@kernel.org> writes: > > On Friday 26 March 2021 17:54:38 Toke Høiland-Jørgensen wrote: > >> So we have these > >> cases: > >> > >> ASPM disabled: ath9k, ath10k and mt76 cards all work > >> ASPM enabled, no patch: only mt76 card works > >> ASPM enabled + patch: ath10k and mt76 cards work > >> > >> So IDK, maybe the ath9k card needs a quirk as well? Or the mvebu board > >> is just generally flaky? > > > > I'm not sure. Maybe ASPM is somehow buggy on ath9k or needs some special > > handling. But issue is not at PCI config space as ath9k driver start > > initialization of this card. Needs also some debugging in ath9k driver > > if it prints that strange "mac chip rev" error. > > Well that's just being output because it gets a revision that it doesn't > recognise - which it seems to be just reading from a register: > > https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/ath9k/hw.c#L255 > > The value returned is consistent with the value returned just being > 0xffffffff. Which from looking at ioread32() is the value being returned > on a failed read. So there's a driver bug there - the check against -EIO > here is obviously nonsensical: > > https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/ath9k/hw.c#L290 > > But the underlying cause appears to be that the read from the register > fails, which I suppose is related to something the PCI bus does? > > > I think this issue should be handled separately. Could you report it > > also to ath9k mailing list (and CC me)? Maybe other ath developers would > > know some more details. > > I'll send a patch for the nonsensical check above, but other than that I > think we're still in PCI land here, or? First, can you try to enable my quirk also for this ath9k card with ASPM enabled? I have there another ath9k card which after toggling link retraining changes PCI device ID (really!) to 0xABCD. But lspci ... There is long story about broken ath9k cards that are reporting 0xABCD id on x86 machines with specific BIOS versions. It can be find in ath9k-devel mailing list archive: https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg07529.html Maybe we now found root cause of this ABCD? If yes, then it also answers why above ath9k driver check fails (device id was changed) and also because kernel see correct id (kernel reads id before configuring ASPM and therefore before triggering link retraining). > >> > Can you send PCI device id of your ath9k card (lspci -nn)? Because all > >> > my tested ath9k cards have different PCI device id. > >> > >> [root@omnia-arch ~]# lspci -nn > >> 00:01.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6820] (rev 04) > >> 00:02.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6820] (rev 04) > >> 00:03.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6820] (rev 04) > >> 01:00.0 Network controller [0280]: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) [168c:002e] (rev 01) > >> 02:00.0 Network controller [0280]: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter [168c:003c] > > > > That is fine. Also all ath9k testing cards have id 0x002e. Today I found out that lspci -nn may lie! Please send output from command: lspci -nn -x because real PCI device id can read only from -x hexdump output. > >> >> When booting with the > >> >> patch applied, I get this in dmesg: > >> >> > >> >> [ 3.556599] ath: phy0: Mac Chip Rev 0xfffc0.f is not supported by this driver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-29 17:10 UTC|newest] Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-27 15:43 PCI trouble on mvebu (Turris Omnia) Toke Høiland-Jørgensen 2020-10-27 15:43 ` Toke Høiland-Jørgensen 2020-10-27 17:20 ` Bjorn Helgaas 2020-10-27 17:20 ` Bjorn Helgaas 2020-10-27 17:44 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-27 17:44 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-27 18:59 ` Toke Høiland-Jørgensen 2020-10-27 18:59 ` Toke Høiland-Jørgensen 2020-10-27 20:20 ` Toke Høiland-Jørgensen 2020-10-27 20:20 ` Toke Høiland-Jørgensen 2020-10-27 21:22 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-27 21:22 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-27 21:31 ` Toke Høiland-Jørgensen 2020-10-27 21:31 ` Toke Høiland-Jørgensen 2020-10-27 22:01 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-27 22:01 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-27 22:12 ` Toke Høiland-Jørgensen 2020-10-27 22:12 ` Toke Høiland-Jørgensen 2020-10-27 18:56 ` Toke Høiland-Jørgensen 2020-10-27 18:56 ` Toke Høiland-Jørgensen 2020-10-28 13:36 ` Toke Høiland-Jørgensen 2020-10-28 13:36 ` Toke Høiland-Jørgensen 2020-10-28 14:42 ` Bjorn Helgaas 2020-10-28 14:42 ` Bjorn Helgaas 2020-10-28 15:08 ` Toke Høiland-Jørgensen 2020-10-28 15:08 ` Toke Høiland-Jørgensen 2020-10-28 16:40 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-28 16:40 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-28 23:16 ` Bjorn Helgaas 2020-10-28 23:16 ` Bjorn Helgaas 2020-10-29 10:09 ` Pali Rohár 2020-10-29 10:09 ` Pali Rohár 2020-10-29 10:56 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-29 10:56 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-29 11:12 ` Toke Høiland-Jørgensen 2020-10-29 11:12 ` Toke Høiland-Jørgensen 2020-10-29 19:30 ` Bjorn Helgaas 2020-10-29 19:30 ` Bjorn Helgaas 2020-10-29 19:56 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-29 19:56 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-29 19:57 ` Andrew Lunn 2020-10-29 19:57 ` Andrew Lunn 2020-10-29 21:55 ` Thomas Petazzoni 2020-10-29 21:55 ` Thomas Petazzoni 2020-10-29 20:18 ` Toke Høiland-Jørgensen 2020-10-29 20:18 ` Toke Høiland-Jørgensen 2020-10-29 22:09 ` Toke Høiland-Jørgensen 2020-10-29 22:09 ` Toke Høiland-Jørgensen 2020-10-29 20:58 ` Marek Behun 2020-10-29 20:58 ` Marek Behun 2020-10-30 10:08 ` Pali Rohár 2020-10-30 10:08 ` Pali Rohár 2020-10-30 10:45 ` Marek Behun 2020-10-30 10:45 ` Marek Behun 2020-10-29 21:54 ` Thomas Petazzoni 2020-10-29 21:54 ` Thomas Petazzoni 2020-10-29 23:15 ` Toke Høiland-Jørgensen 2020-10-29 23:15 ` Toke Høiland-Jørgensen 2020-10-30 8:23 ` Thomas Petazzoni 2020-10-30 8:23 ` Thomas Petazzoni 2020-10-30 10:15 ` Pali Rohár 2020-10-30 10:15 ` Pali Rohár 2020-10-29 10:41 ` Toke Høiland-Jørgensen 2020-10-29 10:41 ` Toke Høiland-Jørgensen 2020-10-29 11:18 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-29 11:18 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-30 11:23 ` Pali Rohár 2020-10-30 11:23 ` Pali Rohár 2020-10-30 13:02 ` Toke Høiland-Jørgensen 2020-10-30 13:02 ` Toke Høiland-Jørgensen 2020-10-30 14:23 ` Pali Rohár 2020-10-30 14:23 ` Pali Rohár 2020-10-30 14:54 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-30 14:54 ` ™֟☻̭҇ Ѽ ҉ ® 2020-10-31 12:49 ` Toke Høiland-Jørgensen 2020-10-31 12:49 ` Toke Høiland-Jørgensen 2020-11-02 15:24 ` Pali Rohár 2020-11-02 15:24 ` Pali Rohár 2020-11-02 15:54 ` Toke Høiland-Jørgensen 2020-11-02 15:54 ` Toke Høiland-Jørgensen 2020-11-02 16:18 ` ™֟☻̭҇ Ѽ ҉ ® 2020-11-02 16:18 ` ™֟☻̭҇ Ѽ ҉ ® 2020-11-02 16:33 ` Toke Høiland-Jørgensen 2020-11-02 16:33 ` Toke Høiland-Jørgensen 2021-03-15 19:58 ` Pali Rohár 2021-03-15 19:58 ` Pali Rohár 2021-03-16 9:25 ` Pali Rohár 2021-03-16 9:25 ` Pali Rohár 2021-03-18 22:43 ` Toke Høiland-Jørgensen 2021-03-18 22:43 ` Toke Høiland-Jørgensen 2021-03-18 23:16 ` Pali Rohár 2021-03-18 23:16 ` Pali Rohár 2021-03-26 12:50 ` Pali Rohár 2021-03-26 12:50 ` Pali Rohár 2021-03-26 15:25 ` Toke Høiland-Jørgensen 2021-03-26 15:25 ` Toke Høiland-Jørgensen 2021-03-26 15:34 ` Pali Rohár 2021-03-26 15:34 ` Pali Rohár 2021-03-26 16:54 ` Toke Høiland-Jørgensen 2021-03-26 16:54 ` Toke Høiland-Jørgensen 2021-03-26 17:11 ` Pali Rohár 2021-03-26 17:11 ` Pali Rohár 2021-03-26 17:51 ` Toke Høiland-Jørgensen 2021-03-26 17:51 ` Toke Høiland-Jørgensen 2021-03-29 17:09 ` Pali Rohár [this message] 2021-03-29 17:09 ` Pali Rohár 2021-03-31 14:02 ` Toke Høiland-Jørgensen 2021-03-31 14:02 ` Toke Høiland-Jørgensen 2021-03-31 16:15 ` Pali Rohár 2021-03-31 16:15 ` Pali Rohár 2021-03-31 16:53 ` Toke Høiland-Jørgensen 2021-03-31 16:53 ` Toke Høiland-Jørgensen 2020-10-29 1:21 ` Marek Behun 2020-10-29 1:21 ` Marek Behun 2020-10-29 15:12 ` Rob Herring 2020-10-29 15:12 ` Rob Herring 2020-10-27 18:03 ` Marek Behun 2020-10-27 18:03 ` Marek Behun 2020-10-27 19:00 ` Toke Høiland-Jørgensen 2020-10-27 19:00 ` Toke Høiland-Jørgensen 2020-10-27 20:19 ` Marek Behun 2020-10-27 20:19 ` Marek Behun 2020-10-27 20:49 ` Toke Høiland-Jørgensen 2020-10-27 20:49 ` Toke Høiland-Jørgensen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210329170929.uhpttc4oxbkghkpr@pali \ --to=pali@kernel.org \ --cc=helgaas@kernel.org \ --cc=ilias.apalodimas@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pci@vger.kernel.org \ --cc=marek.behun@nic.cz \ --cc=robh@kernel.org \ --cc=thomas.petazzoni@bootlin.com \ --cc=toke@redhat.com \ --cc=vtolkm@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.