From: Kalle Valo <kvalo@qca.qualcomm.com> To: Ben Greear <greearb@candelatech.com> Cc: <ath10k@lists.infradead.org>, <linux-wireless@vger.kernel.org> Subject: Re: [ath9k-devel] [PATCH] ath10k: Fix crash when using v1 hardware. Date: Fri, 12 Jul 2013 17:51:54 +0300 [thread overview] Message-ID: <87d2qn4yr9.fsf@kamboji.qca.qualcomm.com> (raw) In-Reply-To: <51DEC9A7.2080207@candelatech.com> (Ben Greear's message of "Thu, 11 Jul 2013 08:05:11 -0700") Ben Greear <greearb@candelatech.com> writes: > On 07/11/2013 02:36 AM, Kalle Valo wrote: >> greearb@candelatech.com writes: >> >>> + /* On v1 hardware at least, setup can fail, causing ce_id_state to >>> + * be cleaned up, but this method is still called a few times. Check >>> + * for NULL here so we don't crash. Probably a better fix is to stop >>> + * the ath10k_pci_ce_tasklet sooner. >>> + */ >>> + if (WARN_ONCE(!ce_state, "ce_id_to_state[%i] is NULL\n", ce_id)) >>> + return; >>> + >>> + ctrl_addr = ce_state->ctrl_addr; >>> + >> >> The tests you add look like workarounds. I would prefer to try fix these >> by going to the source of the problem. Maybe we should add >> ath10k_pci_wake() and ath10k_do_pci_wake()? Doh, dropped an essential word from a sentence, again. That's what I get when trying to do multiple things at the same time. What I was trying to say: Maybe we should add proper error hanling to ath10k_pci_wake() and ath10k_do_pci_wake() and that way avoid this? > These are work-arounds, but you should not let a bad piece of > hardware/firmware crash the entire OS just because you don't want to > do sanity checking on the values you get from the firmware. Perhaps > there is a better fix for the code above, but the warning splat should > still provide incentive to get it right, while not crashing the OS in > the meantime. Sure, the driver should not crash if HW is not functioning correctly. I'm just saying that adding odd checks at random places is not the "kernel way" to do things, only GTK people do that ;) I was thinking that the proper way is to check that wakeup succeeds and not enable interrupts or something like that. >> Can you enable few debug logs, like ATH10K_DBG_PCI, and post them? That >> would give more hint there things are going wrong. > > Yes, I can do that. Thanks. Oh, did you mention something that ath10k detect the device as hw2.0? Maybe the PCI ids are wrong? Then you could also force the same workaround for hw2.0 as hw1.0 has: --- a/drivers/net/wireless/ath/ath10k/pci.c +++ b/drivers/net/wireless/ath/ath10k/pci.c @@ -2145,10 +2145,8 @@ static int ath10k_pci_probe(struct pci_dev *pdev, switch (pci_dev->device) { case QCA988X_1_0_DEVICE_ID: - set_bit(ATH10K_PCI_FEATURE_HW_1_0_WARKAROUND, ar_pci->features); - break; case QCA988X_2_0_DEVICE_ID: - set_bit(ATH10K_PCI_FEATURE_MSI_X, ar_pci->features); + set_bit(ATH10K_PCI_FEATURE_HW_1_0_WARKAROUND, ar_pci->features); break; default: ret = -ENODEV;
WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@qca.qualcomm.com> To: Ben Greear <greearb@candelatech.com> Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org Subject: Re: [ath9k-devel] [PATCH] ath10k: Fix crash when using v1 hardware. Date: Fri, 12 Jul 2013 17:51:54 +0300 [thread overview] Message-ID: <87d2qn4yr9.fsf@kamboji.qca.qualcomm.com> (raw) In-Reply-To: <51DEC9A7.2080207@candelatech.com> (Ben Greear's message of "Thu, 11 Jul 2013 08:05:11 -0700") Ben Greear <greearb@candelatech.com> writes: > On 07/11/2013 02:36 AM, Kalle Valo wrote: >> greearb@candelatech.com writes: >> >>> + /* On v1 hardware at least, setup can fail, causing ce_id_state to >>> + * be cleaned up, but this method is still called a few times. Check >>> + * for NULL here so we don't crash. Probably a better fix is to stop >>> + * the ath10k_pci_ce_tasklet sooner. >>> + */ >>> + if (WARN_ONCE(!ce_state, "ce_id_to_state[%i] is NULL\n", ce_id)) >>> + return; >>> + >>> + ctrl_addr = ce_state->ctrl_addr; >>> + >> >> The tests you add look like workarounds. I would prefer to try fix these >> by going to the source of the problem. Maybe we should add >> ath10k_pci_wake() and ath10k_do_pci_wake()? Doh, dropped an essential word from a sentence, again. That's what I get when trying to do multiple things at the same time. What I was trying to say: Maybe we should add proper error hanling to ath10k_pci_wake() and ath10k_do_pci_wake() and that way avoid this? > These are work-arounds, but you should not let a bad piece of > hardware/firmware crash the entire OS just because you don't want to > do sanity checking on the values you get from the firmware. Perhaps > there is a better fix for the code above, but the warning splat should > still provide incentive to get it right, while not crashing the OS in > the meantime. Sure, the driver should not crash if HW is not functioning correctly. I'm just saying that adding odd checks at random places is not the "kernel way" to do things, only GTK people do that ;) I was thinking that the proper way is to check that wakeup succeeds and not enable interrupts or something like that. >> Can you enable few debug logs, like ATH10K_DBG_PCI, and post them? That >> would give more hint there things are going wrong. > > Yes, I can do that. Thanks. Oh, did you mention something that ath10k detect the device as hw2.0? Maybe the PCI ids are wrong? Then you could also force the same workaround for hw2.0 as hw1.0 has: --- a/drivers/net/wireless/ath/ath10k/pci.c +++ b/drivers/net/wireless/ath/ath10k/pci.c @@ -2145,10 +2145,8 @@ static int ath10k_pci_probe(struct pci_dev *pdev, switch (pci_dev->device) { case QCA988X_1_0_DEVICE_ID: - set_bit(ATH10K_PCI_FEATURE_HW_1_0_WARKAROUND, ar_pci->features); - break; case QCA988X_2_0_DEVICE_ID: - set_bit(ATH10K_PCI_FEATURE_MSI_X, ar_pci->features); + set_bit(ATH10K_PCI_FEATURE_HW_1_0_WARKAROUND, ar_pci->features); break; default: ret = -ENODEV; _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2013-07-12 14:52 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-02 22:42 [PATCH] ath10k: Fix crash when using v1 hardware greearb 2013-07-02 22:42 ` [ath9k-devel] " greearb at candelatech.com 2013-07-02 23:08 ` Ben Greear 2013-07-02 23:08 ` [ath9k-devel] " Ben Greear 2013-07-11 9:37 ` Kalle Valo 2013-07-11 9:37 ` Kalle Valo 2013-07-11 15:06 ` Ben Greear 2013-07-11 15:06 ` Ben Greear 2013-07-11 9:36 ` Kalle Valo 2013-07-11 9:36 ` Kalle Valo 2013-07-11 15:05 ` Ben Greear 2013-07-11 15:05 ` Ben Greear 2013-07-12 14:51 ` Kalle Valo [this message] 2013-07-12 14:51 ` Kalle Valo 2013-07-12 15:34 ` Ben Greear 2013-07-12 15:34 ` Ben Greear 2013-07-15 6:55 ` Michal Kazior 2013-07-15 6:55 ` Michal Kazior
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=87d2qn4yr9.fsf@kamboji.qca.qualcomm.com \ --to=kvalo@qca.qualcomm.com \ --cc=ath10k@lists.infradead.org \ --cc=greearb@candelatech.com \ --cc=linux-wireless@vger.kernel.org \ /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.