From: Thorsten Leemhuis <firstname.lastname@example.org> To: Stanislaw Gruszka <email@example.com>, Exuvo <firstname.lastname@example.org> Cc: Kalle Valo <email@example.com>, Stanislaw Gruszka <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Helmut Schaa <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: Re: [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Date: Thu, 18 Nov 2021 07:16:45 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20211111141003.GA134627@wp.pl> Hi, this is your Linux kernel regression tracker speaking. Thx for this fix. On 11.11.21 15:10, Stanislaw Gruszka wrote: > As reported by Exuvo is possible that we have lot's of EPROTO errors > during device start i.e. firmware load. But after that device works > correctly. Hence marking device gone by few EPROTO errors done by > commit e383c70474db ("rt2x00: check number of EPROTO errors") caused > regression - Exuvo device stop working after kernel update. To fix > disable the check during device start. > > Reported-and-tested-by: Exuvo <email@example.com> FWIW: In case you need to send an improved patch, could you please add this before the 'Reported-by:' (see at (¹) below for the reasoning): Link: https://firstname.lastname@example.org/ And if the patch is already good to go: could the subsystem maintainer please add it when applying? > Fixes: e383c70474db ("rt2x00: check number of EPROTO errors") What's the plan to getting this merged? Just wondering, because there *afaics* wasn't any activity for a week now. Yes, e383c70474db was a commit for v5.2-rc1, so it's not a new regression that needs to be handled really urgently. But it's still a regression that would be good to get fixed rather sooner than later, as there might be still people out there then might run into this on a update. Ciao, Thorsten (carrying his Linux kernel regression tracker hat) (¹) Long story: The commit message would benefit from a link to the regression report, for reasons explained in Documentation/process/submitting-patches.rst. To quote: ``` If related discussions or any other background information behind the change can be found on the web, add 'Link:' tags pointing to it. In case your patch fixes a bug, for example, add a tag with a URL referencing the report in the mailing list archives or a bug tracker; [...] ``` This concept is old, but the text was reworked recently to make this use case for the Link: tag clearer. For details see: https://git.kernel.org/linus/1f57bd42b77c Yes, that "Link:" is not really crucial; but it's good to have if someone needs to look into the backstory of this change sometime in the future. But I care for a different reason. I'm tracking this regression (and others) with regzbot, my Linux kernel regression tracking bot. This bot will notice if a patch with a Link: tag to a tracked regression gets posted and record that, which allowed anyone looking into the regression to quickly gasp the current status from regzbot's webui (https://linux-regtracking.leemhuis.info/regzbot ) or its reports. The bot will also notice if a commit with a Link: tag to a regression report is applied by Linus and then automatically mark the regression as resolved then. IOW: this tag makes my life a regression tracker a lot easier, as I otherwise have to tell regzbot manually when the fix lands. :-/ P.S.: As a Linux kernel regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them. Unfortunately therefore I sometimes will get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me about it in a public reply. That's in everyone's interest, as what I wrote above might be misleading to everyone reading this; any suggestion I gave they thus might sent someone reading this down the wrong rabbit hole, which none of us wants. BTW, I have no personal interest in this issue, which is tracked using regzbot, my Linux kernel regression tracking bot (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting this mail to get things rolling again and hence don't need to be CC on all further activitie wrt to this regression. Ohh, and feel free to ignore the following lines, they are meant for regzbot: #regzbot poke > Cc: email@example.com > Signed-off-by: Stanislaw Gruszka <firstname.lastname@example.org> > --- > drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > index e4473a551241..74c3d8cb3100 100644 > --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > @@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status) > if (status == -ENODEV || status == -ENOENT) > return true; > > + if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) > + return false; > + > if (status == -EPROTO || status == -ETIMEDOUT) > rt2x00dev->num_proto_errs++; > else >
next prev parent reply other threads:[~2021-11-18 6:16 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <email@example.com> [not found] ` <20190927080303.GA7667@redhat.com> [not found] ` <CA+GwT0B5SyRZnGLqwqOeuJK4CWMVc=dKaWre9VN8KQC6kBzKGw@mail.gmail.com> [not found] ` <20191203075736.GA701@redhat.com> [not found] ` <firstname.lastname@example.org> [not found] ` <email@example.com> [not found] ` <firstname.lastname@example.org> [not found] ` <email@example.com> 2021-10-01 6:56 ` rt2x00 regression Kalle Valo 2021-10-01 8:24 ` Thorsten Leemhuis 2021-11-30 9:16 ` rt2x00 regression #forregzbot Thorsten Leemhuis 2021-11-05 13:25 ` rt2x00 regression Thorsten Leemhuis 2021-11-08 18:00 ` Thorsten Leemhuis [not found] ` <firstname.lastname@example.org> 2021-11-09 7:31 ` Stanislaw Gruszka 2021-11-09 12:07 ` Stanislaw Gruszka 2021-11-09 15:22 ` Exuvo [not found] ` <email@example.com> 2021-11-10 6:59 ` Kalle Valo 2021-11-10 8:01 ` Stanislaw Gruszka 2021-11-11 10:54 ` Exuvo 2021-11-11 14:10 ` [PATCH] rt2x00: do not mark device gone on EPROTO errors during start Stanislaw Gruszka 2021-11-18 6:16 ` Thorsten Leemhuis [this message] 2021-11-19 14:19 ` Kalle Valo 2021-11-29 10:54 ` Kalle Valo [not found] <firstname.lastname@example.org>
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] rt2x00: do not mark device gone on EPROTO errors during start' \ /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: link
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).