All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Schnelle <niks@kernel.org>
To: Niklas Schnelle <schnelle@linux.ibm.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	 Lukas Wunner <lukas@wunner.de>
Cc: linux-pci@vger.kernel.org,
	Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>,
	 Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	"Maciej W. Rozycki" <macro@orcam.me.uk>
Subject: Re: [PATCH for-linus] PCI: Honor Max Link Speed when determining supported speeds
Date: Thu, 12 Dec 2024 20:40:07 +0100	[thread overview]
Message-ID: <0b01d64fa7f6f62d49f39447c5175b44a1011fd5.camel@kernel.org> (raw)
In-Reply-To: <efafe0d864af49d2f496fc6543f619958630869f.camel@linux.ibm.com>

On Thu, 2024-12-12 at 17:58 +0100, Niklas Schnelle wrote:
> On Thu, 2024-12-12 at 10:11 -0600, Bjorn Helgaas wrote:
> > On Thu, Dec 12, 2024 at 09:56:16AM +0100, Lukas Wunner wrote:
> > > The Supported Link Speeds Vector in the Link Capabilities 2 Register
> > > indicates the *supported* link speeds.  The Max Link Speed field in
> > > the Link Capabilities Register indicates the *maximum* of those speeds.
> > > 
> > > Niklas reports that the Intel JHL7540 "Titan Ridge 2018" Thunderbolt
> > > controller supports 2.5-8 GT/s speeds, but indicates 2.5 GT/s as maximum.
> > > Ilpo recalls seeing this inconsistency on more devices.
> > > 
> > > pcie_get_supported_speeds() neglects to honor the Max Link Speed field
> > > and will thus incorrectly deem higher speeds as supported.  Fix it.
> > > 
> > > Fixes: d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds")
> > > Reported-by: Niklas Schnelle <niks@kernel.org>
> > > Closes: https://lore.kernel.org/r/70829798889c6d779ca0f6cd3260a765780d1369.camel@kernel.org/
> > > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> > > Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > 
> > Looks like you want this in v6.13?  Can we make commit log more
> > explicit as to why we need it there?  Is this change enough to resolve
> > the boot hang Niklas reported?
> 
> As for if it fixes my hang I will test this later today when I come
> home. But even if it is not enough on its own, I believe that this will
> be needed as a prerequisite for the fix of my hang issue in that
> without this patch the dev->supported_speeds incorrectly shows multiple
> speeds as supported making it impossible to suppress probing of bwctrl
> for devices that only support a fixed speed.

Ok, gave this a test and as somewhat suspected this patch alone doesn't
fix my boot hang nor do I get more output (also tried Lukas suggestion
with early_printk).

Then I put my patch using the hweight8(dev->supported_speeds) > 1
condition suggested by Lukas on top and with both things work again. I
would now propose that once we've cleared up Ilpo's comment I sent a
series with both patches for you to easily pick together. If you prefer
I can of course also sent my patch stand alone.

Thanks,
Niklas

  reply	other threads:[~2024-12-12 19:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12  8:56 [PATCH for-linus] PCI: Honor Max Link Speed when determining supported speeds Lukas Wunner
2024-12-12 14:33 ` Ilpo Järvinen
2024-12-12 20:10   ` Niklas Schnelle
2024-12-12 22:13   ` Lukas Wunner
2024-12-13 10:12     ` Ilpo Järvinen
2024-12-13 17:21       ` Niklas Schnelle
2024-12-13 17:41       ` Niklas Schnelle
2024-12-13 18:49         ` Niklas Schnelle
2024-12-12 16:11 ` Bjorn Helgaas
2024-12-12 16:58   ` Niklas Schnelle
2024-12-12 19:40     ` Niklas Schnelle [this message]
2024-12-13  9:43       ` Lukas Wunner
2024-12-13 17:22         ` Niklas Schnelle
2024-12-13  9:16   ` Lukas Wunner

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=0b01d64fa7f6f62d49f39447c5175b44a1011fd5.camel@kernel.org \
    --to=niks@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=helgaas@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=macro@orcam.me.uk \
    --cc=mika.westerberg@linux.intel.com \
    --cc=schnelle@linux.ibm.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: link
Be 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.