From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: David Miller <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Mariusz Bialonczyk <manio@skyboo.net>
Subject: Re: [PATCH net] r8169: fix jumbo packet handling on resume from suspend
Date: Sat, 12 Oct 2019 15:28:45 -0700 [thread overview]
Message-ID: <20191012152845.6ff9430d@cakuba.netronome.com> (raw)
In-Reply-To: <03561754-aec2-7015-4b4d-32707bf3bd2d@gmail.com>
On Fri, 11 Oct 2019 08:03:24 +0200, Heiner Kallweit wrote:
> On 11.10.2019 01:36, Jakub Kicinski wrote:
> > On Wed, 9 Oct 2019 20:55:48 +0200, Heiner Kallweit wrote:
> >> Mariusz reported that invalid packets are sent after resume from
> >> suspend if jumbo packets are active. It turned out that his BIOS
> >> resets chip settings to non-jumbo on resume. Most chip settings are
> >> re-initialized on resume from suspend by calling rtl_hw_start(),
> >> so let's add configuring jumbo to this function.
> >> There's nothing wrong with the commit marked as fixed, it's just
> >> the first one where the patch applies cleanly.
> >>
> >> Fixes: 7366016d2d4c ("r8169: read common register for PCI commit")
> >> Reported-by: Mariusz Bialonczyk <manio@skyboo.net>
> >> Tested-by: Mariusz Bialonczyk <manio@skyboo.net>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >
> > Applied, somewhat begrudgingly - this really isn't the way the Fixes
> > tag should be used, but I appreciate it may be hard at this point to
> > pin down a commit to blame given how many generations of HW this driver
> > supports and how old it is.. perhaps I should have removed the tag in
> > this case, hm.
> >
> > Since the selected commit came in 5.4 I'm not queuing for stable.
> >
> The issue seems to have been there forever, but patch applies from a
> certain kernel version only. I agree that using the Fixes tag to provide
> this information is kind of a misuse. How would you prefer to get that
> information, add a comment below the commit message similar to the list
> of changes in a new version of a patch series?
I'd put the backport help under the --- lines, maybe additionally
mentioning its presence in the commit message (lore link would
complete the picture). Like we do for merges.
Although I think Dave queues for stable immediately when patch is
merged to net, so if the backport is to last release or two I think
the info under --- could be as useful as in the commit message.
Another way would be posting the backported patch (say for the most
recent LTS) if the backport is hard and fix important 🤔
prev parent reply other threads:[~2019-10-12 22:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-09 18:55 [PATCH net] r8169: fix jumbo packet handling on resume from suspend Heiner Kallweit
2019-10-10 23:36 ` Jakub Kicinski
2019-10-11 6:03 ` Heiner Kallweit
2019-10-12 22:28 ` Jakub Kicinski [this message]
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=20191012152845.6ff9430d@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=manio@skyboo.net \
--cc=netdev@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).