* [PATCH] PCI: Fix bit definitions for LNKCAP2 register
@ 2018-08-03 6:51 Felipe Balbi
2018-08-06 18:23 ` Bjorn Helgaas
0 siblings, 1 reply; 6+ messages in thread
From: Felipe Balbi @ 2018-08-03 6:51 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, Felipe Balbi, stable
Even thhough commit b891b4dc1eed claimed that original bit definitions
were wrong, that's not really the case. After verifying PCI
Specification Revisions 3.0, 3.1 and 4.0, Link Capabilites 2
Register's bit definitions were always starting from Bit 0.
This has been causing issues reporting correct link speeds on sysfs.
Fixes: b891b4dc1eed ("PCI: Fix bit definitions of PCI_EXP_LNKCAP2 register")
Cc: <stable@vger.kernel.org> # v3.8+
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
---
PCI Spec References:
- 4.0 https://members.pcisig.com/wg/PCI-SIG/document/10912?downloadRevision=active
- 3.1 https://members.pcisig.com/wg/PCI-SIG/document/download/8257
- 3.0 https://members.pcisig.com/wg/PCI-SIG/document/download/8265
include/uapi/linux/pci_regs.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index 796d12910791..6ad597b3d082 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -652,10 +652,10 @@
#define PCI_EXP_DEVSTA2 42 /* Device Status 2 */
#define PCI_CAP_EXP_RC_ENDPOINT_SIZEOF_V2 44 /* v2 endpoints without link end here */
#define PCI_EXP_LNKCAP2 44 /* Link Capabilities 2 */
-#define PCI_EXP_LNKCAP2_SLS_2_5GB 0x00000002 /* Supported Speed 2.5GT/s */
-#define PCI_EXP_LNKCAP2_SLS_5_0GB 0x00000004 /* Supported Speed 5GT/s */
-#define PCI_EXP_LNKCAP2_SLS_8_0GB 0x00000008 /* Supported Speed 8GT/s */
-#define PCI_EXP_LNKCAP2_SLS_16_0GB 0x00000010 /* Supported Speed 16GT/s */
+#define PCI_EXP_LNKCAP2_SLS_2_5GB 0x00000001 /* Supported Speed 2.5GT/s */
+#define PCI_EXP_LNKCAP2_SLS_5_0GB 0x00000002 /* Supported Speed 5GT/s */
+#define PCI_EXP_LNKCAP2_SLS_8_0GB 0x00000004 /* Supported Speed 8GT/s */
+#define PCI_EXP_LNKCAP2_SLS_16_0GB 0x00000008 /* Supported Speed 16GT/s */
#define PCI_EXP_LNKCAP2_CROSSLINK 0x00000100 /* Crosslink supported */
#define PCI_EXP_LNKCTL2 48 /* Link Control 2 */
#define PCI_EXP_LNKCTL2_TLS 0x000f
--
2.16.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] PCI: Fix bit definitions for LNKCAP2 register
2018-08-03 6:51 [PATCH] PCI: Fix bit definitions for LNKCAP2 register Felipe Balbi
@ 2018-08-06 18:23 ` Bjorn Helgaas
2018-08-07 8:20 ` Felipe Balbi
0 siblings, 1 reply; 6+ messages in thread
From: Bjorn Helgaas @ 2018-08-06 18:23 UTC (permalink / raw)
To: Felipe Balbi; +Cc: Bjorn Helgaas, linux-pci, stable, Jingoo Han
[+cc Jingoo]
On Fri, Aug 03, 2018 at 09:51:20AM +0300, Felipe Balbi wrote:
> Even thhough commit b891b4dc1eed claimed that original bit definitions
> were wrong, that's not really the case. After verifying PCI
> Specification Revisions 3.0, 3.1 and 4.0, Link Capabilites 2
> Register's bit definitions were always starting from Bit 0.
>
> This has been causing issues reporting correct link speeds on sysfs.
Can you elaborate on this a bit? b891b4dc1eed still looks correct to
me. I'm looking at PCIe r4.0, sec 7.5.3.18, where it shows:
bit 0 RsvdP
bits 7:1 Supported Link Speeds Vector
bit 8 Crosslink Supported
...
The text in table 7-32 does say:
Bit definitions within this field are:
Bit 0 2.5 GT/s
Bit 1 5.0 GT/s
...
It says "Bit 0" there, but it's referring to bit 0 of the *field*,
which is bits 7:1 of the LNKCAP2 register, so bit 0 of the field is
bit 1 of the 32-bit LNKCAP2 register.
I guess you must be looking at this path, since it's the only generic
path that uses PCI_EXP_LNKCAP2_SLS_2_5GB:
max_link_speed_show()
speed = pcie_get_speed_cap(pdev)
pcie_capability_read_dword(dev, PCI_EXP_LNKCAP2, &lnkcap2)
if (lnkcap2)
...
else if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
return PCIE_SPEED_2_5GT
PCIE_SPEED2STR(speed)
...
(speed) == PCIE_SPEED_2_5GT ? "2.5 GT/s"
We don't extract the Supported Speeds Vector by masking and shifting,
so PCI_EXP_LNKCAP2_SLS_2_5GB and related definitions should be based
on the entire 32-bit register, not just the individual field within
that register.
Can you attach the output of "sudo lspci -vvxxx" for a relevant
device and the contents of the sysfs file that is wrong?
> Fixes: b891b4dc1eed ("PCI: Fix bit definitions of PCI_EXP_LNKCAP2 register")
> Cc: <stable@vger.kernel.org> # v3.8+
> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
> ---
>
> PCI Spec References:
>
> - 4.0 https://members.pcisig.com/wg/PCI-SIG/document/10912?downloadRevision=active
> - 3.1 https://members.pcisig.com/wg/PCI-SIG/document/download/8257
> - 3.0 https://members.pcisig.com/wg/PCI-SIG/document/download/8265
>
> include/uapi/linux/pci_regs.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 796d12910791..6ad597b3d082 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -652,10 +652,10 @@
> #define PCI_EXP_DEVSTA2 42 /* Device Status 2 */
> #define PCI_CAP_EXP_RC_ENDPOINT_SIZEOF_V2 44 /* v2 endpoints without link end here */
> #define PCI_EXP_LNKCAP2 44 /* Link Capabilities 2 */
> -#define PCI_EXP_LNKCAP2_SLS_2_5GB 0x00000002 /* Supported Speed 2.5GT/s */
> -#define PCI_EXP_LNKCAP2_SLS_5_0GB 0x00000004 /* Supported Speed 5GT/s */
> -#define PCI_EXP_LNKCAP2_SLS_8_0GB 0x00000008 /* Supported Speed 8GT/s */
> -#define PCI_EXP_LNKCAP2_SLS_16_0GB 0x00000010 /* Supported Speed 16GT/s */
> +#define PCI_EXP_LNKCAP2_SLS_2_5GB 0x00000001 /* Supported Speed 2.5GT/s */
> +#define PCI_EXP_LNKCAP2_SLS_5_0GB 0x00000002 /* Supported Speed 5GT/s */
> +#define PCI_EXP_LNKCAP2_SLS_8_0GB 0x00000004 /* Supported Speed 8GT/s */
> +#define PCI_EXP_LNKCAP2_SLS_16_0GB 0x00000008 /* Supported Speed 16GT/s */
> #define PCI_EXP_LNKCAP2_CROSSLINK 0x00000100 /* Crosslink supported */
> #define PCI_EXP_LNKCTL2 48 /* Link Control 2 */
> #define PCI_EXP_LNKCTL2_TLS 0x000f
> --
> 2.16.1
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] PCI: Fix bit definitions for LNKCAP2 register
2018-08-06 18:23 ` Bjorn Helgaas
@ 2018-08-07 8:20 ` Felipe Balbi
2018-08-07 18:18 ` Jingoo Han
2018-08-07 20:13 ` Bjorn Helgaas
0 siblings, 2 replies; 6+ messages in thread
From: Felipe Balbi @ 2018-08-07 8:20 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Bjorn Helgaas, linux-pci, stable, Jingoo Han
Hi,
Bjorn Helgaas <helgaas@kernel.org> writes:
> On Fri, Aug 03, 2018 at 09:51:20AM +0300, Felipe Balbi wrote:
>> Even thhough commit b891b4dc1eed claimed that original bit definitions
>> were wrong, that's not really the case. After verifying PCI
>> Specification Revisions 3.0, 3.1 and 4.0, Link Capabilites 2
>> Register's bit definitions were always starting from Bit 0.
>>
>> This has been causing issues reporting correct link speeds on sysfs.
>
> Can you elaborate on this a bit? b891b4dc1eed still looks correct to
> me. I'm looking at PCIe r4.0, sec 7.5.3.18, where it shows:
>
> bit 0 RsvdP
> bits 7:1 Supported Link Speeds Vector
I had missed this detail, actually. It was a misinterpretation of the
spec. Sorry for the noise.
--
balbi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] PCI: Fix bit definitions for LNKCAP2 register
2018-08-07 8:20 ` Felipe Balbi
@ 2018-08-07 18:18 ` Jingoo Han
2018-08-07 20:13 ` Bjorn Helgaas
1 sibling, 0 replies; 6+ messages in thread
From: Jingoo Han @ 2018-08-07 18:18 UTC (permalink / raw)
To: 'Felipe Balbi', 'Bjorn Helgaas'
Cc: 'Bjorn Helgaas', linux-pci, stable
On Tuesday, August 7, 2018 4:21 AM, Felipe Balbi wrote:
>
>
> Hi,
>
> Bjorn Helgaas <helgaas@kernel.org> writes:
> > On Fri, Aug 03, 2018 at 09:51:20AM +0300, Felipe Balbi wrote:
> >> Even thhough commit b891b4dc1eed claimed that original bit definitions
> >> were wrong, that's not really the case. After verifying PCI
> >> Specification Revisions 3.0, 3.1 and 4.0, Link Capabilites 2
> >> Register's bit definitions were always starting from Bit 0.
> >>
> >> This has been causing issues reporting correct link speeds on sysfs.
> >
> > Can you elaborate on this a bit? b891b4dc1eed still looks correct to
> > me. I'm looking at PCIe r4.0, sec 7.5.3.18, where it shows:
> >
> > bit 0 RsvdP
> > bits 7:1 Supported Link Speeds Vector
>
> I had missed this detail, actually. It was a misinterpretation of the
> spec. Sorry for the noise.
Hi Balbi,
I can understand your situation. The detail of PCIe spec is very confusing.
Actually, I was one of those who misunderstood. However, after reviewing
the PCIe spec carefully, I found that the bit definition was wrong. At that
time,
I already checked that my patch works properly with Exynos SoCs. Thank you.
Best regards,
Jingoo Han
>
> --
> balbi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] PCI: Fix bit definitions for LNKCAP2 register
2018-08-07 8:20 ` Felipe Balbi
2018-08-07 18:18 ` Jingoo Han
@ 2018-08-07 20:13 ` Bjorn Helgaas
2018-08-08 6:30 ` Felipe Balbi
1 sibling, 1 reply; 6+ messages in thread
From: Bjorn Helgaas @ 2018-08-07 20:13 UTC (permalink / raw)
To: felipe.balbi; +Cc: Bjorn Helgaas, linux-pci, stable, Jingoo Han
On Tue, Aug 7, 2018 at 3:24 AM Felipe Balbi
<felipe.balbi@linux.intel.com> wrote:
>
>
> Hi,
>
> Bjorn Helgaas <helgaas@kernel.org> writes:
> > On Fri, Aug 03, 2018 at 09:51:20AM +0300, Felipe Balbi wrote:
> >> Even thhough commit b891b4dc1eed claimed that original bit definitions
> >> were wrong, that's not really the case. After verifying PCI
> >> Specification Revisions 3.0, 3.1 and 4.0, Link Capabilites 2
> >> Register's bit definitions were always starting from Bit 0.
> >>
> >> This has been causing issues reporting correct link speeds on sysfs.
> >
> > Can you elaborate on this a bit? b891b4dc1eed still looks correct to
> > me. I'm looking at PCIe r4.0, sec 7.5.3.18, where it shows:
> >
> > bit 0 RsvdP
> > bits 7:1 Supported Link Speeds Vector
>
> I had missed this detail, actually. It was a misinterpretation of the
> spec. Sorry for the noise.
No problem. You were seeing something incorrect in sysfs, so if we
can help diagnose or fix whatever the real problem is, don't hesitate
to ask!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] PCI: Fix bit definitions for LNKCAP2 register
2018-08-07 20:13 ` Bjorn Helgaas
@ 2018-08-08 6:30 ` Felipe Balbi
0 siblings, 0 replies; 6+ messages in thread
From: Felipe Balbi @ 2018-08-08 6:30 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Bjorn Helgaas, linux-pci, stable, Jingoo Han
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
Hi,
Bjorn Helgaas <bhelgaas@google.com> writes:
>> Bjorn Helgaas <helgaas@kernel.org> writes:
>> > On Fri, Aug 03, 2018 at 09:51:20AM +0300, Felipe Balbi wrote:
>> >> Even thhough commit b891b4dc1eed claimed that original bit definitions
>> >> were wrong, that's not really the case. After verifying PCI
>> >> Specification Revisions 3.0, 3.1 and 4.0, Link Capabilites 2
>> >> Register's bit definitions were always starting from Bit 0.
>> >>
>> >> This has been causing issues reporting correct link speeds on sysfs.
>> >
>> > Can you elaborate on this a bit? b891b4dc1eed still looks correct to
>> > me. I'm looking at PCIe r4.0, sec 7.5.3.18, where it shows:
>> >
>> > bit 0 RsvdP
>> > bits 7:1 Supported Link Speeds Vector
>>
>> I had missed this detail, actually. It was a misinterpretation of the
>> spec. Sorry for the noise.
>
> No problem. You were seeing something incorrect in sysfs, so if we
> can help diagnose or fix whatever the real problem is, don't hesitate
> to ask!
Sure thing, but I think this is a problem elsewhere :)
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-08-08 6:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-08-03 6:51 [PATCH] PCI: Fix bit definitions for LNKCAP2 register Felipe Balbi
2018-08-06 18:23 ` Bjorn Helgaas
2018-08-07 8:20 ` Felipe Balbi
2018-08-07 18:18 ` Jingoo Han
2018-08-07 20:13 ` Bjorn Helgaas
2018-08-08 6:30 ` Felipe Balbi
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).