| Message ID | 20201003013123.20269-2-david.e.box@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | Intel Platform Monitoring Technology | expand |
Hi Bjorn, This patch has been acked and unchanged for weeks. Is it possible to get this pulled into next? We have SIOV and CXL related work that is using these definitions. Thanks. David On Fri, 2020-10-02 at 18:31 -0700, David E. Box wrote: > Add PCIe Designated Vendor-Specific Extended Capability (DVSEC) and > defines > for the header offsets. Defined in PCIe r5.0, sec 7.9.6. > > Signed-off-by: David E. Box <david.e.box@linux.intel.com> > Acked-by: Bjorn Helgaas <bhelgaas@google.com> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > --- > include/uapi/linux/pci_regs.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/include/uapi/linux/pci_regs.h > b/include/uapi/linux/pci_regs.h > index f9701410d3b5..beafeee39e44 100644 > --- a/include/uapi/linux/pci_regs.h > +++ b/include/uapi/linux/pci_regs.h > @@ -720,6 +720,7 @@ > #define PCI_EXT_CAP_ID_DPC 0x1D /* Downstream Port > Containment */ > #define PCI_EXT_CAP_ID_L1SS 0x1E /* L1 PM Substates */ > #define PCI_EXT_CAP_ID_PTM 0x1F /* Precision Time Measurement > */ > +#define PCI_EXT_CAP_ID_DVSEC 0x23 /* Designated Vendor-Specific > */ > #define PCI_EXT_CAP_ID_DLF 0x25 /* Data Link Feature */ > #define PCI_EXT_CAP_ID_PL_16GT 0x26 /* Physical Layer > 16.0 GT/s */ > #define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PL_16GT > @@ -1062,6 +1063,10 @@ > #define PCI_L1SS_CTL1_LTR_L12_TH_SCALE 0xe0000000 /* > LTR_L1.2_THRESHOLD_Scale */ > #define PCI_L1SS_CTL2 0x0c /* Control 2 Register > */ > > +/* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */ > +#define PCI_DVSEC_HEADER1 0x4 /* Designated Vendor- > Specific Header1 */ > +#define PCI_DVSEC_HEADER2 0x8 /* Designated Vendor- > Specific Header2 */ > + > /* Data Link Feature */ > #define PCI_DLF_CAP 0x04 /* Capabilities Register */ > #define PCI_DLF_EXCHANGE_ENABLE 0x80000000 /* Data Link > Feature Exchange Enable */
On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote: > Hi Bjorn, > > This patch has been acked and unchanged for weeks. Is it possible to > get this pulled into next? We have SIOV and CXL related work that is > using these definitions. Thanks. I acked it because I expected you to merge it along with the rest of the series. I guess I could merge this patch via the PCI tree if you really want, but that ends up being a hassle because we have to worry about which order things get merged to Linus' tree. Better if the whole series is merged via the same tree. > On Fri, 2020-10-02 at 18:31 -0700, David E. Box wrote: > > Add PCIe Designated Vendor-Specific Extended Capability (DVSEC) and > > defines > > for the header offsets. Defined in PCIe r5.0, sec 7.9.6. > > > > Signed-off-by: David E. Box <david.e.box@linux.intel.com> > > Acked-by: Bjorn Helgaas <bhelgaas@google.com> > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > --- > > include/uapi/linux/pci_regs.h | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/include/uapi/linux/pci_regs.h > > b/include/uapi/linux/pci_regs.h > > index f9701410d3b5..beafeee39e44 100644 > > --- a/include/uapi/linux/pci_regs.h > > +++ b/include/uapi/linux/pci_regs.h > > @@ -720,6 +720,7 @@ > > #define PCI_EXT_CAP_ID_DPC 0x1D /* Downstream Port > > Containment */ > > #define PCI_EXT_CAP_ID_L1SS 0x1E /* L1 PM Substates */ > > #define PCI_EXT_CAP_ID_PTM 0x1F /* Precision Time Measurement > > */ > > +#define PCI_EXT_CAP_ID_DVSEC 0x23 /* Designated Vendor-Specific > > */ > > #define PCI_EXT_CAP_ID_DLF 0x25 /* Data Link Feature */ > > #define PCI_EXT_CAP_ID_PL_16GT 0x26 /* Physical Layer > > 16.0 GT/s */ > > #define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PL_16GT > > @@ -1062,6 +1063,10 @@ > > #define PCI_L1SS_CTL1_LTR_L12_TH_SCALE 0xe0000000 /* > > LTR_L1.2_THRESHOLD_Scale */ > > #define PCI_L1SS_CTL2 0x0c /* Control 2 Register > > */ > > > > +/* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */ > > +#define PCI_DVSEC_HEADER1 0x4 /* Designated Vendor- > > Specific Header1 */ > > +#define PCI_DVSEC_HEADER2 0x8 /* Designated Vendor- > > Specific Header2 */ > > + > > /* Data Link Feature */ > > #define PCI_DLF_CAP 0x04 /* Capabilities Register */ > > #define PCI_DLF_EXCHANGE_ENABLE 0x80000000 /* Data Link > > Feature Exchange Enable */ >
On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote: > On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote: > > Hi Bjorn, > > > > This patch has been acked and unchanged for weeks. Is it possible > > to > > get this pulled into next? We have SIOV and CXL related work that > > is > > using these definitions. Thanks. > > I acked it because I expected you to merge it along with the rest of > the series. > > I guess I could merge this patch via the PCI tree if you really want, > but that ends up being a hassle because we have to worry about which > order things get merged to Linus' tree. Better if the whole series > is > merged via the same tree. Agreed. The hope is that this series is ready for the next merge window but no ack yet on V8. And if the series does not make it I'd like this patch to at least get in.
On Tue, 06 Oct 2020, David E. Box wrote: > On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote: > > On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote: > > > Hi Bjorn, > > > > > > This patch has been acked and unchanged for weeks. Is it possible > > > to > > > get this pulled into next? We have SIOV and CXL related work that > > > is > > > using these definitions. Thanks. > > > > I acked it because I expected you to merge it along with the rest of > > the series. > > > > I guess I could merge this patch via the PCI tree if you really want, > > but that ends up being a hassle because we have to worry about which > > order things get merged to Linus' tree. Better if the whole series > > is > > merged via the same tree. > > Agreed. The hope is that this series is ready for the next merge window > but no ack yet on V8. And if the series does not make it I'd like this > patch to at least get in. If Bjorn is happy to take this patch so late in the release cycle then please go ahead. The other patches are due for v5.11.
Hi, On 10/7/20 8:54 AM, Lee Jones wrote: > On Tue, 06 Oct 2020, David E. Box wrote: > >> On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote: >>> On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote: >>>> Hi Bjorn, >>>> >>>> This patch has been acked and unchanged for weeks. Is it possible >>>> to >>>> get this pulled into next? We have SIOV and CXL related work that >>>> is >>>> using these definitions. Thanks. >>> >>> I acked it because I expected you to merge it along with the rest of >>> the series. >>> >>> I guess I could merge this patch via the PCI tree if you really want, >>> but that ends up being a hassle because we have to worry about which >>> order things get merged to Linus' tree. Better if the whole series >>> is >>> merged via the same tree. >> >> Agreed. The hope is that this series is ready for the next merge window >> but no ack yet on V8. And if the series does not make it I'd like this >> patch to at least get in. > > If Bjorn is happy to take this patch so late in the release cycle then > please go ahead. The other patches are due for v5.11. I agree (that the other patches are for 5.11) talking about merging this series patch 2 is a mfd patch and patches 3-5 are drivers/platform/x86 patches. Lee, FYI I'm taking over drivers/platform/x86 maintainership from Andy. I suggest that we merge the entire series through a single tree (with acks or reviewed-by-s from the other maintainer) either through the mfd tree or through the drivers/platform/x86 tree. Since most changes are in drivers/platform/x86 the latter probably makes more sense, but either way works for me. So how would you like to proceed with this series ? Regards, Hans
On Wed, 07 Oct 2020, Hans de Goede wrote: > Hi, > > On 10/7/20 8:54 AM, Lee Jones wrote: > > On Tue, 06 Oct 2020, David E. Box wrote: > > > > > On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote: > > > > On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote: > > > > > Hi Bjorn, > > > > > > > > > > This patch has been acked and unchanged for weeks. Is it possible > > > > > to > > > > > get this pulled into next? We have SIOV and CXL related work that > > > > > is > > > > > using these definitions. Thanks. > > > > > > > > I acked it because I expected you to merge it along with the rest of > > > > the series. > > > > > > > > I guess I could merge this patch via the PCI tree if you really want, > > > > but that ends up being a hassle because we have to worry about which > > > > order things get merged to Linus' tree. Better if the whole series > > > > is > > > > merged via the same tree. > > > > > > Agreed. The hope is that this series is ready for the next merge window > > > but no ack yet on V8. And if the series does not make it I'd like this > > > patch to at least get in. > > > > If Bjorn is happy to take this patch so late in the release cycle then > > please go ahead. The other patches are due for v5.11. > > I agree (that the other patches are for 5.11) talking about merging > this series patch 2 is a mfd patch and patches 3-5 are drivers/platform/x86 > patches. > > Lee, FYI I'm taking over drivers/platform/x86 maintainership from Andy. Congratulations, Hans. > I suggest that we merge the entire series through a single tree > (with acks or reviewed-by-s from the other maintainer) > either through the mfd tree or through the drivers/platform/x86 > tree. Since most changes are in drivers/platform/x86 the latter > probably makes more sense, but either way works for me. > So how would you like to proceed with this series ? I'm happy either way, but bear in mind that, due to the intrinsic heterogeneous nature of MFD, I already have infrastructure to easily apply (and send pull-requests for) cross-subsystem patch-sets. If however, you decide that you'd really like to take the set, that's also fine but I will require a pull-request from an immutable branch.
Hi, On 10/8/20 9:29 AM, Lee Jones wrote: > On Wed, 07 Oct 2020, Hans de Goede wrote: > >> Hi, >> >> On 10/7/20 8:54 AM, Lee Jones wrote: >>> On Tue, 06 Oct 2020, David E. Box wrote: >>> >>>> On Tue, 2020-10-06 at 19:51 -0500, Bjorn Helgaas wrote: >>>>> On Tue, Oct 06, 2020 at 03:45:54PM -0700, David E. Box wrote: >>>>>> Hi Bjorn, >>>>>> >>>>>> This patch has been acked and unchanged for weeks. Is it possible >>>>>> to >>>>>> get this pulled into next? We have SIOV and CXL related work that >>>>>> is >>>>>> using these definitions. Thanks. >>>>> >>>>> I acked it because I expected you to merge it along with the rest of >>>>> the series. >>>>> >>>>> I guess I could merge this patch via the PCI tree if you really want, >>>>> but that ends up being a hassle because we have to worry about which >>>>> order things get merged to Linus' tree. Better if the whole series >>>>> is >>>>> merged via the same tree. >>>> >>>> Agreed. The hope is that this series is ready for the next merge window >>>> but no ack yet on V8. And if the series does not make it I'd like this >>>> patch to at least get in. >>> >>> If Bjorn is happy to take this patch so late in the release cycle then >>> please go ahead. The other patches are due for v5.11. >> >> I agree (that the other patches are for 5.11) talking about merging >> this series patch 2 is a mfd patch and patches 3-5 are drivers/platform/x86 >> patches. >> >> Lee, FYI I'm taking over drivers/platform/x86 maintainership from Andy. > > Congratulations, Hans. > >> I suggest that we merge the entire series through a single tree >> (with acks or reviewed-by-s from the other maintainer) >> either through the mfd tree or through the drivers/platform/x86 >> tree. Since most changes are in drivers/platform/x86 the latter >> probably makes more sense, but either way works for me. >> So how would you like to proceed with this series ? > > I'm happy either way, but bear in mind that, due to the intrinsic > heterogeneous nature of MFD, I already have infrastructure to easily > apply (and send pull-requests for) cross-subsystem patch-sets. Ok, you applying the entire series to the mfd tree is fine with me. I'll try to review the entire series next week and then we'll see from there. Regards, Hans
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h index f9701410d3b5..beafeee39e44 100644 --- a/include/uapi/linux/pci_regs.h +++ b/include/uapi/linux/pci_regs.h @@ -720,6 +720,7 @@ #define PCI_EXT_CAP_ID_DPC 0x1D /* Downstream Port Containment */ #define PCI_EXT_CAP_ID_L1SS 0x1E /* L1 PM Substates */ #define PCI_EXT_CAP_ID_PTM 0x1F /* Precision Time Measurement */ +#define PCI_EXT_CAP_ID_DVSEC 0x23 /* Designated Vendor-Specific */ #define PCI_EXT_CAP_ID_DLF 0x25 /* Data Link Feature */ #define PCI_EXT_CAP_ID_PL_16GT 0x26 /* Physical Layer 16.0 GT/s */ #define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PL_16GT @@ -1062,6 +1063,10 @@ #define PCI_L1SS_CTL1_LTR_L12_TH_SCALE 0xe0000000 /* LTR_L1.2_THRESHOLD_Scale */ #define PCI_L1SS_CTL2 0x0c /* Control 2 Register */ +/* Designated Vendor-Specific (DVSEC, PCI_EXT_CAP_ID_DVSEC) */ +#define PCI_DVSEC_HEADER1 0x4 /* Designated Vendor-Specific Header1 */ +#define PCI_DVSEC_HEADER2 0x8 /* Designated Vendor-Specific Header2 */ + /* Data Link Feature */ #define PCI_DLF_CAP 0x04 /* Capabilities Register */ #define PCI_DLF_EXCHANGE_ENABLE 0x80000000 /* Data Link Feature Exchange Enable */