| Message ID | 20170331202136.100342-1-briannorris@chromium.org (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Kalle Valo |
| Headers | show |
On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote: > This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836. > > This above-mentioned "fix" does not actually do anything to prevent a > race condition. It simply papers over it so that the issue doesn't > appear. > > If this is a real problem, it should be explained better than the above > commit does, and an alternative, non-racy solution should be found. > > For further reason to revert this: there's ot reason we can't try > resetting the card when it's *actually* stuck in host-sleep mode. So > instead, this is unnecessarily creating scenarios where we can't recover > Wifi. > > Cc: Amitkumar Karwar <akarwar@marvell.com> > Signed-off-by: Brian Norris <briannorris@chromium.org> FWIW: Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > --- > Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you > still think it's needed, can you please propose an alternative? Or at least > explain more why this is needed? Thanks. > > drivers/net/wireless/marvell/mwifiex/init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c > index 756948385b60..0dab77b526de 100644 > --- a/drivers/net/wireless/marvell/mwifiex/init.c > +++ b/drivers/net/wireless/marvell/mwifiex/init.c > @@ -60,7 +60,7 @@ static void wakeup_timer_fn(unsigned long data) > adapter->hw_status = MWIFIEX_HW_STATUS_RESET; > mwifiex_cancel_all_pending_cmd(adapter); > > - if (adapter->if_ops.card_reset && !adapter->hs_activated) > + if (adapter->if_ops.card_reset) > adapter->if_ops.card_reset(adapter); > } > > -- > 2.12.2.564.g063fe858b8-goog >
On Sat, Apr 1, 2017 at 1:51 AM, Brian Norris <briannorris@chromium.org> wrote: > This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836. > > This above-mentioned "fix" does not actually do anything to prevent a > race condition. It simply papers over it so that the issue doesn't > appear. > > If this is a real problem, it should be explained better than the above > commit does, and an alternative, non-racy solution should be found. > > For further reason to revert this: there's ot reason we can't try > resetting the card when it's *actually* stuck in host-sleep mode. So > instead, this is unnecessarily creating scenarios where we can't recover > Wifi. > > Cc: Amitkumar Karwar <akarwar@marvell.com> > Signed-off-by: Brian Norris <briannorris@chromium.org> > --- > Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you > still think it's needed, can you please propose an alternative? Or at least > explain more why this is needed? Thanks. > I agree. Fix just covers the issue. We need to investigate why system hangs when card reset is attempted in host sleep activated scenario. Acked-by: Amitkumar Karwar <amitkarwar@gmail.com> Regards, Amitkumar Karwar
+ Doug, Matthias, who are seeing problems (or, failure to try to recover, as predicted below) + Amit's new email + new maintainers Perhaps it's my fault for marking this RFC. But I changed the status back to "New" in Patchwork, in case that helps: On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote: > This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836. > > This above-mentioned "fix" does not actually do anything to prevent a > race condition. It simply papers over it so that the issue doesn't > appear. > > If this is a real problem, it should be explained better than the above > commit does, and an alternative, non-racy solution should be found. > > For further reason to revert this: there's ot reason we can't try s/ot/no/ ...oops. > resetting the card when it's *actually* stuck in host-sleep mode. So > instead, this is unnecessarily creating scenarios where we can't recover > Wifi. > > Cc: Amitkumar Karwar <akarwar@marvell.com> > Signed-off-by: Brian Norris <briannorris@chromium.org> > --- > Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you > still think it's needed, can you please propose an alternative? Or at least > explain more why this is needed? Thanks. FWIW, I got an Acked-by from Amit when he was still at Marvell. And another Reviewed-by from Dmitry. This still applies. Should I resend? (I'll do that if I don't hear a response within a few days.) Thanks, Brian > drivers/net/wireless/marvell/mwifiex/init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c > index 756948385b60..0dab77b526de 100644 > --- a/drivers/net/wireless/marvell/mwifiex/init.c > +++ b/drivers/net/wireless/marvell/mwifiex/init.c > @@ -60,7 +60,7 @@ static void wakeup_timer_fn(unsigned long data) > adapter->hw_status = MWIFIEX_HW_STATUS_RESET; > mwifiex_cancel_all_pending_cmd(adapter); > > - if (adapter->if_ops.card_reset && !adapter->hs_activated) > + if (adapter->if_ops.card_reset) > adapter->if_ops.card_reset(adapter); > } > > -- > 2.12.2.564.g063fe858b8-goog >
Brian Norris <briannorris@chromium.org> writes: > + Doug, Matthias, who are seeing problems (or, failure to try to > recover, as predicted below) > + Amit's new email > + new maintainers > > Perhaps it's my fault for marking this RFC. But I changed the status > back to "New" in Patchwork, in case that helps: But I still see it marked as RFC. So the patch in question is: https://patchwork.kernel.org/patch/9657277/ Changing the patchwork state to RFC means that it's dropped and out of my radar. Also, if I see "RFC" in the subject I assume that's a patch which I should not apply by default. > On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote: >> This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836. >> >> This above-mentioned "fix" does not actually do anything to prevent a >> race condition. It simply papers over it so that the issue doesn't >> appear. >> >> If this is a real problem, it should be explained better than the above >> commit does, and an alternative, non-racy solution should be found. >> >> For further reason to revert this: there's ot reason we can't try > > s/ot/no/ > > ...oops. > >> resetting the card when it's *actually* stuck in host-sleep mode. So >> instead, this is unnecessarily creating scenarios where we can't recover >> Wifi. >> >> Cc: Amitkumar Karwar <akarwar@marvell.com> >> Signed-off-by: Brian Norris <briannorris@chromium.org> >> --- >> Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you >> still think it's needed, can you please propose an alternative? Or at least >> explain more why this is needed? Thanks. > > FWIW, I got an Acked-by from Amit when he was still at Marvell. And > another Reviewed-by from Dmitry. This still applies. Should I resend? > (I'll do that if I don't hear a response within a few days.) This patch is from 2017 so better to resend, and without RFC markings.
On Fri, Aug 2, 2019 at 6:55 PM Kalle Valo <kvalo@codeaurora.org> wrote: > > Brian Norris <briannorris@chromium.org> writes: > > > + Doug, Matthias, who are seeing problems (or, failure to try to > > recover, as predicted below) > > + Amit's new email > > + new maintainers > > > > Perhaps it's my fault for marking this RFC. But I changed the status > > back to "New" in Patchwork, in case that helps: > > But I still see it marked as RFC. So the patch in question is: > > https://patchwork.kernel.org/patch/9657277/ Oops, I didn't hit the "Update" button :( I changed it now, but I'll change it back again. > Changing the patchwork state to RFC means that it's dropped and out of > my radar. Also, if I see "RFC" in the subject I assume that's a patch > which I should not apply by default. Ack. Well, there were some "RFCs" I sent recently that you *did* apply, so I didn't really know what happens normally. > > On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote: ... > > FWIW, I got an Acked-by from Amit when he was still at Marvell. And > > another Reviewed-by from Dmitry. This still applies. Should I resend? > > (I'll do that if I don't hear a response within a few days.) > > This patch is from 2017 so better to resend, and without RFC markings. Yep, will do. Brian
Brian Norris <briannorris@chromium.org> writes: >> Changing the patchwork state to RFC means that it's dropped and out of >> my radar. Also, if I see "RFC" in the subject I assume that's a patch >> which I should not apply by default. > > Ack. Well, there were some "RFCs" I sent recently that you *did* > apply, so I didn't really know what happens normally. True, I have sometimes applied RFC patches in case they look good enough and I do not want them to get lost (and this is a good example of RFC patches getting lost). But by default I drop RFC patches after a quick glance. >> > On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote: > ... >> > FWIW, I got an Acked-by from Amit when he was still at Marvell. And >> > another Reviewed-by from Dmitry. This still applies. Should I resend? >> > (I'll do that if I don't hear a response within a few days.) >> >> This patch is from 2017 so better to resend, and without RFC markings. > > Yep, will do. Thanks.
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c index 756948385b60..0dab77b526de 100644 --- a/drivers/net/wireless/marvell/mwifiex/init.c +++ b/drivers/net/wireless/marvell/mwifiex/init.c @@ -60,7 +60,7 @@ static void wakeup_timer_fn(unsigned long data) adapter->hw_status = MWIFIEX_HW_STATUS_RESET; mwifiex_cancel_all_pending_cmd(adapter); - if (adapter->if_ops.card_reset && !adapter->hs_activated) + if (adapter->if_ops.card_reset) adapter->if_ops.card_reset(adapter); }
This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836. This above-mentioned "fix" does not actually do anything to prevent a race condition. It simply papers over it so that the issue doesn't appear. If this is a real problem, it should be explained better than the above commit does, and an alternative, non-racy solution should be found. For further reason to revert this: there's ot reason we can't try resetting the card when it's *actually* stuck in host-sleep mode. So instead, this is unnecessarily creating scenarios where we can't recover Wifi. Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Brian Norris <briannorris@chromium.org> --- Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you still think it's needed, can you please propose an alternative? Or at least explain more why this is needed? Thanks. drivers/net/wireless/marvell/mwifiex/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)