| Message ID | 20230411033928.30397-1-Sergey.Semin@baikalelectronics.ru (mailing list archive) |
|---|---|
| Headers | show |
| Series | PCI: dwc: Relatively simple fixes and cleanups | expand |
On Tue, Apr 11, 2023 at 06:39:18AM +0300, Serge Semin wrote: > It turns out the recent DW PCIe-related patchset was merged in with > several relatively trivial issues left unsettled (noted by Bjorn and > Manivannan). All of these lefovers have been fixed in this patchset. > Namely the series starts with two bug-fixes. The first one concerns the > improper link-mode initialization in case if the CDM-check is enabled. The > second unfortunate mistake I made in the IP-core version type helper. In > particular instead of testing the IP-core version type the macro function > referred to the just IP-core version which obviously wasn't what I > intended. > > Afterwards two @Mani-noted fixes follow. Firstly the dma-ranges related warning > message is fixed to start with "DMA-ranges" word instead of "Dma-ranges". > Secondly the Baikal-T1 PCIe Host driver is converted to perform the > asynchronous probe type which saved us of about 15% of bootup time if no any > PCIe peripheral device attached to the port. > > Then the patchset contains the Baikal-T1 PCIe driver fix. The > corresponding patch removes the false error message printed during the > controller probe procedure. I accidentally added the unconditional > dev_err_probe() method invocation. It was obviously wrong. > > Then two trivial cleanups are introduced. The first one concerns the > duplicated fast-link-mode flag unsetting. The second one implies > dropping a redundant empty line from the dw_pcie_link_set_max_speed() > function. > > The series continues with a patch inspired by the last @Bjorn note > regarding the generic resources request interface. As @Bjorn correctly > said it would be nice to have the new interface used wider in the DW PCIe > subsystem. Aside with the Baikal-T1 PCIe Host driver the Toshiba Visconti > PCIe driver can be easily converted to using the generic clock names. > That's what is done in the noted patch. > > The patchset is closed with a series of MAINTAINERS-list related patches. > Firstly after getting the DW PCIe RP/EP DT-schemas refactored I forgot to > update the MAINTAINER-list with the new files added in the framework of > that procedure. All the snps,dw-pcie* schemas shall be maintained by the > DW PCIe core driver maintainers. Secondly seeing how long it took for my > patchsets to review and not having any comments from the original driver > maintainers I'd suggest to add myself as the reviewer to the DW PCIe and > eDMA drivers. Thus hopefully the new updates review process will be > performed with much less latencies. For the same reason I would also like > to suggest to add @Manivannan as the DW PCIe/eDMA drivers maintainer if > he isn't against that idea. What do you think about the last suggestion? > I'm willing to co-maintain the drivers. - Mani > Link: https://lore.kernel.org/linux-pci/20230217093956.27126-1-Sergey.Semin@baikalelectronics.ru/ > Changelog v2: > - Rebase onto the kernel 6.3-rc2. > > Link: https://lore.kernel.org/linux-pci/20230313200816.30105-1-Sergey.Semin@baikalelectronics.ru/ > Changelog v3: > - Drop the patch: > [PATCH v2 01/11] PCI: dwc: Fix port link CSR improper init if CDM check enabled > and rebase onto the already submitted by @Yoshihiro fix: > commit cdce67099117 ("PCI: dwc: Fix PORT_LINK_CONTROL update when CDM check enabled") > - Just resend. > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> > Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru> > Cc: linux-pci@vger.kernel.org > Cc: dmaengine@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > > Serge Semin (10): > PCI: dwc: Fix erroneous version type test helper > PCI: dwc: Fix inbound iATU entries out-of-bounds warning message > PCI: bt1: Enable async probe type > PCI: bt1: Fix printing false error message > PCI: dwc: Drop duplicated fast-link-mode flag unsetting > PCI: dwc: Drop empty line from dw_pcie_link_set_max_speed() > PCI: visconti: Convert to using generic resources getter > MAINTAINERS: Add all generic DW PCIe RP/EP DT-schemas > MAINTAINERS: Add myself as the DW PCIe core reviewer > MAINTAINERS: Add myself as the DW eDMA driver reviewer > > MAINTAINERS | 5 ++- > drivers/pci/controller/dwc/pcie-bt1.c | 5 ++- > .../pci/controller/dwc/pcie-designware-host.c | 2 +- > drivers/pci/controller/dwc/pcie-designware.c | 2 - > drivers/pci/controller/dwc/pcie-designware.h | 7 +++- > drivers/pci/controller/dwc/pcie-visconti.c | 37 +++++++++---------- > 6 files changed, 30 insertions(+), 28 deletions(-) > > -- > 2.40.0 > >
On Tue, Apr 11, 2023 at 04:32:40PM +0530, Manivannan Sadhasivam wrote: > On Tue, Apr 11, 2023 at 06:39:18AM +0300, Serge Semin wrote: > > It turns out the recent DW PCIe-related patchset was merged in with > > several relatively trivial issues left unsettled (noted by Bjorn and > > Manivannan). All of these lefovers have been fixed in this patchset. > > Namely the series starts with two bug-fixes. The first one concerns the > > improper link-mode initialization in case if the CDM-check is enabled. The > > second unfortunate mistake I made in the IP-core version type helper. In > > particular instead of testing the IP-core version type the macro function > > referred to the just IP-core version which obviously wasn't what I > > intended. > > > > Afterwards two @Mani-noted fixes follow. Firstly the dma-ranges related warning > > message is fixed to start with "DMA-ranges" word instead of "Dma-ranges". > > Secondly the Baikal-T1 PCIe Host driver is converted to perform the > > asynchronous probe type which saved us of about 15% of bootup time if no any > > PCIe peripheral device attached to the port. > > > > Then the patchset contains the Baikal-T1 PCIe driver fix. The > > corresponding patch removes the false error message printed during the > > controller probe procedure. I accidentally added the unconditional > > dev_err_probe() method invocation. It was obviously wrong. > > > > Then two trivial cleanups are introduced. The first one concerns the > > duplicated fast-link-mode flag unsetting. The second one implies > > dropping a redundant empty line from the dw_pcie_link_set_max_speed() > > function. > > > > The series continues with a patch inspired by the last @Bjorn note > > regarding the generic resources request interface. As @Bjorn correctly > > said it would be nice to have the new interface used wider in the DW PCIe > > subsystem. Aside with the Baikal-T1 PCIe Host driver the Toshiba Visconti > > PCIe driver can be easily converted to using the generic clock names. > > That's what is done in the noted patch. > > > > The patchset is closed with a series of MAINTAINERS-list related patches. > > Firstly after getting the DW PCIe RP/EP DT-schemas refactored I forgot to > > update the MAINTAINER-list with the new files added in the framework of > > that procedure. All the snps,dw-pcie* schemas shall be maintained by the > > DW PCIe core driver maintainers. Secondly seeing how long it took for my > > patchsets to review and not having any comments from the original driver > > maintainers I'd suggest to add myself as the reviewer to the DW PCIe and > > eDMA drivers. Thus hopefully the new updates review process will be > > performed with much less latencies. For the same reason I would also like > > to suggest to add @Manivannan as the DW PCIe/eDMA drivers maintainer if > > he isn't against that idea. What do you think about the last suggestion? > > > > I'm willing to co-maintain the drivers. Awesome! @Bjorn, @Lorenzo, @Vinod what do you think about this? If you are ok with that shall I resubmit the series with @Mani added to the DW PCIe/eDMA maintainers list or will you create the respective patches yourself? -Serge(y) > > - Mani > > > Link: https://lore.kernel.org/linux-pci/20230217093956.27126-1-Sergey.Semin@baikalelectronics.ru/ > > Changelog v2: > > - Rebase onto the kernel 6.3-rc2. > > > > Link: https://lore.kernel.org/linux-pci/20230313200816.30105-1-Sergey.Semin@baikalelectronics.ru/ > > Changelog v3: > > - Drop the patch: > > [PATCH v2 01/11] PCI: dwc: Fix port link CSR improper init if CDM check enabled > > and rebase onto the already submitted by @Yoshihiro fix: > > commit cdce67099117 ("PCI: dwc: Fix PORT_LINK_CONTROL update when CDM check enabled") > > - Just resend. > > > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> > > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> > > Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru> > > Cc: linux-pci@vger.kernel.org > > Cc: dmaengine@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > > > Serge Semin (10): > > PCI: dwc: Fix erroneous version type test helper > > PCI: dwc: Fix inbound iATU entries out-of-bounds warning message > > PCI: bt1: Enable async probe type > > PCI: bt1: Fix printing false error message > > PCI: dwc: Drop duplicated fast-link-mode flag unsetting > > PCI: dwc: Drop empty line from dw_pcie_link_set_max_speed() > > PCI: visconti: Convert to using generic resources getter > > MAINTAINERS: Add all generic DW PCIe RP/EP DT-schemas > > MAINTAINERS: Add myself as the DW PCIe core reviewer > > MAINTAINERS: Add myself as the DW eDMA driver reviewer > > > > MAINTAINERS | 5 ++- > > drivers/pci/controller/dwc/pcie-bt1.c | 5 ++- > > .../pci/controller/dwc/pcie-designware-host.c | 2 +- > > drivers/pci/controller/dwc/pcie-designware.c | 2 - > > drivers/pci/controller/dwc/pcie-designware.h | 7 +++- > > drivers/pci/controller/dwc/pcie-visconti.c | 37 +++++++++---------- > > 6 files changed, 30 insertions(+), 28 deletions(-) > > > > -- > > 2.40.0 > > > > > > -- > மணிவண்ணன் சதாசிவம்
On 11-04-23, 19:59, Serge Semin wrote: > On Tue, Apr 11, 2023 at 04:32:40PM +0530, Manivannan Sadhasivam wrote: > > On Tue, Apr 11, 2023 at 06:39:18AM +0300, Serge Semin wrote: > > > It turns out the recent DW PCIe-related patchset was merged in with > > > several relatively trivial issues left unsettled (noted by Bjorn and > > > Manivannan). All of these lefovers have been fixed in this patchset. > > > Namely the series starts with two bug-fixes. The first one concerns the > > > improper link-mode initialization in case if the CDM-check is enabled. The > > > second unfortunate mistake I made in the IP-core version type helper. In > > > particular instead of testing the IP-core version type the macro function > > > referred to the just IP-core version which obviously wasn't what I > > > intended. > > > > > > Afterwards two @Mani-noted fixes follow. Firstly the dma-ranges related warning > > > message is fixed to start with "DMA-ranges" word instead of "Dma-ranges". > > > Secondly the Baikal-T1 PCIe Host driver is converted to perform the > > > asynchronous probe type which saved us of about 15% of bootup time if no any > > > PCIe peripheral device attached to the port. > > > > > > Then the patchset contains the Baikal-T1 PCIe driver fix. The > > > corresponding patch removes the false error message printed during the > > > controller probe procedure. I accidentally added the unconditional > > > dev_err_probe() method invocation. It was obviously wrong. > > > > > > Then two trivial cleanups are introduced. The first one concerns the > > > duplicated fast-link-mode flag unsetting. The second one implies > > > dropping a redundant empty line from the dw_pcie_link_set_max_speed() > > > function. > > > > > > The series continues with a patch inspired by the last @Bjorn note > > > regarding the generic resources request interface. As @Bjorn correctly > > > said it would be nice to have the new interface used wider in the DW PCIe > > > subsystem. Aside with the Baikal-T1 PCIe Host driver the Toshiba Visconti > > > PCIe driver can be easily converted to using the generic clock names. > > > That's what is done in the noted patch. > > > > > > The patchset is closed with a series of MAINTAINERS-list related patches. > > > Firstly after getting the DW PCIe RP/EP DT-schemas refactored I forgot to > > > update the MAINTAINER-list with the new files added in the framework of > > > that procedure. All the snps,dw-pcie* schemas shall be maintained by the > > > DW PCIe core driver maintainers. Secondly seeing how long it took for my > > > patchsets to review and not having any comments from the original driver > > > maintainers I'd suggest to add myself as the reviewer to the DW PCIe and > > > eDMA drivers. Thus hopefully the new updates review process will be > > > performed with much less latencies. For the same reason I would also like > > > to suggest to add @Manivannan as the DW PCIe/eDMA drivers maintainer if > > > he isn't against that idea. What do you think about the last suggestion? > > > > > > > I'm willing to co-maintain the drivers. > > Awesome! @Bjorn, @Lorenzo, @Vinod what do you think about this? If you > are ok with that shall I resubmit the series with @Mani added to the > DW PCIe/eDMA maintainers list or will you create the respective > patches yourself? Pls send the patch, that is preferred.
On Wed, Apr 12, 2023 at 10:28:05PM +0530, Vinod Koul wrote: > On 11-04-23, 19:59, Serge Semin wrote: > > On Tue, Apr 11, 2023 at 04:32:40PM +0530, Manivannan Sadhasivam wrote: > > > On Tue, Apr 11, 2023 at 06:39:18AM +0300, Serge Semin wrote: > > > > It turns out the recent DW PCIe-related patchset was merged in with > > > > several relatively trivial issues left unsettled (noted by Bjorn and > > > > Manivannan). All of these lefovers have been fixed in this patchset. > > > > Namely the series starts with two bug-fixes. The first one concerns the > > > > improper link-mode initialization in case if the CDM-check is enabled. The > > > > second unfortunate mistake I made in the IP-core version type helper. In > > > > particular instead of testing the IP-core version type the macro function > > > > referred to the just IP-core version which obviously wasn't what I > > > > intended. > > > > > > > > Afterwards two @Mani-noted fixes follow. Firstly the dma-ranges related warning > > > > message is fixed to start with "DMA-ranges" word instead of "Dma-ranges". > > > > Secondly the Baikal-T1 PCIe Host driver is converted to perform the > > > > asynchronous probe type which saved us of about 15% of bootup time if no any > > > > PCIe peripheral device attached to the port. > > > > > > > > Then the patchset contains the Baikal-T1 PCIe driver fix. The > > > > corresponding patch removes the false error message printed during the > > > > controller probe procedure. I accidentally added the unconditional > > > > dev_err_probe() method invocation. It was obviously wrong. > > > > > > > > Then two trivial cleanups are introduced. The first one concerns the > > > > duplicated fast-link-mode flag unsetting. The second one implies > > > > dropping a redundant empty line from the dw_pcie_link_set_max_speed() > > > > function. > > > > > > > > The series continues with a patch inspired by the last @Bjorn note > > > > regarding the generic resources request interface. As @Bjorn correctly > > > > said it would be nice to have the new interface used wider in the DW PCIe > > > > subsystem. Aside with the Baikal-T1 PCIe Host driver the Toshiba Visconti > > > > PCIe driver can be easily converted to using the generic clock names. > > > > That's what is done in the noted patch. > > > > > > > > The patchset is closed with a series of MAINTAINERS-list related patches. > > > > Firstly after getting the DW PCIe RP/EP DT-schemas refactored I forgot to > > > > update the MAINTAINER-list with the new files added in the framework of > > > > that procedure. All the snps,dw-pcie* schemas shall be maintained by the > > > > DW PCIe core driver maintainers. Secondly seeing how long it took for my > > > > patchsets to review and not having any comments from the original driver > > > > maintainers I'd suggest to add myself as the reviewer to the DW PCIe and > > > > eDMA drivers. Thus hopefully the new updates review process will be > > > > performed with much less latencies. For the same reason I would also like > > > > to suggest to add @Manivannan as the DW PCIe/eDMA drivers maintainer if > > > > he isn't against that idea. What do you think about the last suggestion? > > > > > > > > > > I'm willing to co-maintain the drivers. > > > > Awesome! @Bjorn, @Lorenzo, @Vinod what do you think about this? If you > > are ok with that shall I resubmit the series with @Mani added to the > > DW PCIe/eDMA maintainers list or will you create the respective > > patches yourself? > > Pls send the patch, that is preferred. Ok. I'll resubmit the series with the new patches replacing @Gustavo with @Mani as the DW PCIe/eDMA drivers maintainer. -Serge(y) > > -- > ~Vinod
On Thu, Apr 13, 2023 at 04:34:54PM +0300, Serge Semin wrote: > On Wed, Apr 12, 2023 at 10:28:05PM +0530, Vinod Koul wrote: > > On 11-04-23, 19:59, Serge Semin wrote: > > > On Tue, Apr 11, 2023 at 04:32:40PM +0530, Manivannan Sadhasivam wrote: > > > > On Tue, Apr 11, 2023 at 06:39:18AM +0300, Serge Semin wrote: > > > > > It turns out the recent DW PCIe-related patchset was merged in with > > > > > several relatively trivial issues left unsettled (noted by Bjorn and > > > > > Manivannan). All of these lefovers have been fixed in this patchset. > > > > > Namely the series starts with two bug-fixes. The first one concerns the > > > > > improper link-mode initialization in case if the CDM-check is enabled. The > > > > > second unfortunate mistake I made in the IP-core version type helper. In > > > > > particular instead of testing the IP-core version type the macro function > > > > > referred to the just IP-core version which obviously wasn't what I > > > > > intended. > > > > > > > > > > Afterwards two @Mani-noted fixes follow. Firstly the dma-ranges related warning > > > > > message is fixed to start with "DMA-ranges" word instead of "Dma-ranges". > > > > > Secondly the Baikal-T1 PCIe Host driver is converted to perform the > > > > > asynchronous probe type which saved us of about 15% of bootup time if no any > > > > > PCIe peripheral device attached to the port. > > > > > > > > > > Then the patchset contains the Baikal-T1 PCIe driver fix. The > > > > > corresponding patch removes the false error message printed during the > > > > > controller probe procedure. I accidentally added the unconditional > > > > > dev_err_probe() method invocation. It was obviously wrong. > > > > > > > > > > Then two trivial cleanups are introduced. The first one concerns the > > > > > duplicated fast-link-mode flag unsetting. The second one implies > > > > > dropping a redundant empty line from the dw_pcie_link_set_max_speed() > > > > > function. > > > > > > > > > > The series continues with a patch inspired by the last @Bjorn note > > > > > regarding the generic resources request interface. As @Bjorn correctly > > > > > said it would be nice to have the new interface used wider in the DW PCIe > > > > > subsystem. Aside with the Baikal-T1 PCIe Host driver the Toshiba Visconti > > > > > PCIe driver can be easily converted to using the generic clock names. > > > > > That's what is done in the noted patch. > > > > > > > > > > The patchset is closed with a series of MAINTAINERS-list related patches. > > > > > Firstly after getting the DW PCIe RP/EP DT-schemas refactored I forgot to > > > > > update the MAINTAINER-list with the new files added in the framework of > > > > > that procedure. All the snps,dw-pcie* schemas shall be maintained by the > > > > > DW PCIe core driver maintainers. Secondly seeing how long it took for my > > > > > patchsets to review and not having any comments from the original driver > > > > > maintainers I'd suggest to add myself as the reviewer to the DW PCIe and > > > > > eDMA drivers. Thus hopefully the new updates review process will be > > > > > performed with much less latencies. For the same reason I would also like > > > > > to suggest to add @Manivannan as the DW PCIe/eDMA drivers maintainer if > > > > > he isn't against that idea. What do you think about the last suggestion? > > > > > > > > > > > > > I'm willing to co-maintain the drivers. > > > > > > Awesome! @Bjorn, @Lorenzo, @Vinod what do you think about this? If you > > > are ok with that shall I resubmit the series with @Mani added to the > > > DW PCIe/eDMA maintainers list or will you create the respective > > > patches yourself? > > > > > Pls send the patch, that is preferred. > > Ok. I'll resubmit the series with the new patches replacing @Gustavo with > @Mani as the DW PCIe/eDMA drivers maintainer. > I talked to Vinod about the non-responsive maintainers and he suggested first demoting them as Reviewers instead of dropping altogether. So you can move Gustavo as a Reviewer. - Mani > -Serge(y) > > > > > -- > > ~Vinod
On Thu, Apr 13, 2023 at 07:30:24PM +0530, Manivannan Sadhasivam wrote: > On Thu, Apr 13, 2023 at 04:34:54PM +0300, Serge Semin wrote: > > On Wed, Apr 12, 2023 at 10:28:05PM +0530, Vinod Koul wrote: > > > On 11-04-23, 19:59, Serge Semin wrote: > > > > On Tue, Apr 11, 2023 at 04:32:40PM +0530, Manivannan Sadhasivam wrote: > > > > > On Tue, Apr 11, 2023 at 06:39:18AM +0300, Serge Semin wrote: > > > > > > It turns out the recent DW PCIe-related patchset was merged in with > > > > > > several relatively trivial issues left unsettled (noted by Bjorn and > > > > > > Manivannan). All of these lefovers have been fixed in this patchset. > > > > > > Namely the series starts with two bug-fixes. The first one concerns the > > > > > > improper link-mode initialization in case if the CDM-check is enabled. The > > > > > > second unfortunate mistake I made in the IP-core version type helper. In > > > > > > particular instead of testing the IP-core version type the macro function > > > > > > referred to the just IP-core version which obviously wasn't what I > > > > > > intended. > > > > > > > > > > > > Afterwards two @Mani-noted fixes follow. Firstly the dma-ranges related warning > > > > > > message is fixed to start with "DMA-ranges" word instead of "Dma-ranges". > > > > > > Secondly the Baikal-T1 PCIe Host driver is converted to perform the > > > > > > asynchronous probe type which saved us of about 15% of bootup time if no any > > > > > > PCIe peripheral device attached to the port. > > > > > > > > > > > > Then the patchset contains the Baikal-T1 PCIe driver fix. The > > > > > > corresponding patch removes the false error message printed during the > > > > > > controller probe procedure. I accidentally added the unconditional > > > > > > dev_err_probe() method invocation. It was obviously wrong. > > > > > > > > > > > > Then two trivial cleanups are introduced. The first one concerns the > > > > > > duplicated fast-link-mode flag unsetting. The second one implies > > > > > > dropping a redundant empty line from the dw_pcie_link_set_max_speed() > > > > > > function. > > > > > > > > > > > > The series continues with a patch inspired by the last @Bjorn note > > > > > > regarding the generic resources request interface. As @Bjorn correctly > > > > > > said it would be nice to have the new interface used wider in the DW PCIe > > > > > > subsystem. Aside with the Baikal-T1 PCIe Host driver the Toshiba Visconti > > > > > > PCIe driver can be easily converted to using the generic clock names. > > > > > > That's what is done in the noted patch. > > > > > > > > > > > > The patchset is closed with a series of MAINTAINERS-list related patches. > > > > > > Firstly after getting the DW PCIe RP/EP DT-schemas refactored I forgot to > > > > > > update the MAINTAINER-list with the new files added in the framework of > > > > > > that procedure. All the snps,dw-pcie* schemas shall be maintained by the > > > > > > DW PCIe core driver maintainers. Secondly seeing how long it took for my > > > > > > patchsets to review and not having any comments from the original driver > > > > > > maintainers I'd suggest to add myself as the reviewer to the DW PCIe and > > > > > > eDMA drivers. Thus hopefully the new updates review process will be > > > > > > performed with much less latencies. For the same reason I would also like > > > > > > to suggest to add @Manivannan as the DW PCIe/eDMA drivers maintainer if > > > > > > he isn't against that idea. What do you think about the last suggestion? > > > > > > > > > > > > > > > > I'm willing to co-maintain the drivers. > > > > > > > > Awesome! @Bjorn, @Lorenzo, @Vinod what do you think about this? If you > > > > are ok with that shall I resubmit the series with @Mani added to the > > > > DW PCIe/eDMA maintainers list or will you create the respective > > > > patches yourself? > > > > > > > > Pls send the patch, that is preferred. > > > > Ok. I'll resubmit the series with the new patches replacing @Gustavo with > > @Mani as the DW PCIe/eDMA drivers maintainer. > > > > I talked to Vinod about the non-responsive maintainers and he suggested first > demoting them as Reviewers instead of dropping altogether. So you can move > Gustavo as a Reviewer. Got it. Thanks for the note. -Serge(y) > > - Mani > > > -Serge(y) > > > > > > > > -- > > > ~Vinod > > -- > மணிவண்ணன் சதாசிவம்
It turns out the recent DW PCIe-related patchset was merged in with several relatively trivial issues left unsettled (noted by Bjorn and Manivannan). All of these lefovers have been fixed in this patchset. Namely the series starts with two bug-fixes. The first one concerns the improper link-mode initialization in case if the CDM-check is enabled. The second unfortunate mistake I made in the IP-core version type helper. In particular instead of testing the IP-core version type the macro function referred to the just IP-core version which obviously wasn't what I intended. Afterwards two @Mani-noted fixes follow. Firstly the dma-ranges related warning message is fixed to start with "DMA-ranges" word instead of "Dma-ranges". Secondly the Baikal-T1 PCIe Host driver is converted to perform the asynchronous probe type which saved us of about 15% of bootup time if no any PCIe peripheral device attached to the port. Then the patchset contains the Baikal-T1 PCIe driver fix. The corresponding patch removes the false error message printed during the controller probe procedure. I accidentally added the unconditional dev_err_probe() method invocation. It was obviously wrong. Then two trivial cleanups are introduced. The first one concerns the duplicated fast-link-mode flag unsetting. The second one implies dropping a redundant empty line from the dw_pcie_link_set_max_speed() function. The series continues with a patch inspired by the last @Bjorn note regarding the generic resources request interface. As @Bjorn correctly said it would be nice to have the new interface used wider in the DW PCIe subsystem. Aside with the Baikal-T1 PCIe Host driver the Toshiba Visconti PCIe driver can be easily converted to using the generic clock names. That's what is done in the noted patch. The patchset is closed with a series of MAINTAINERS-list related patches. Firstly after getting the DW PCIe RP/EP DT-schemas refactored I forgot to update the MAINTAINER-list with the new files added in the framework of that procedure. All the snps,dw-pcie* schemas shall be maintained by the DW PCIe core driver maintainers. Secondly seeing how long it took for my patchsets to review and not having any comments from the original driver maintainers I'd suggest to add myself as the reviewer to the DW PCIe and eDMA drivers. Thus hopefully the new updates review process will be performed with much less latencies. For the same reason I would also like to suggest to add @Manivannan as the DW PCIe/eDMA drivers maintainer if he isn't against that idea. What do you think about the last suggestion? Link: https://lore.kernel.org/linux-pci/20230217093956.27126-1-Sergey.Semin@baikalelectronics.ru/ Changelog v2: - Rebase onto the kernel 6.3-rc2. Link: https://lore.kernel.org/linux-pci/20230313200816.30105-1-Sergey.Semin@baikalelectronics.ru/ Changelog v3: - Drop the patch: [PATCH v2 01/11] PCI: dwc: Fix port link CSR improper init if CDM check enabled and rebase onto the already submitted by @Yoshihiro fix: commit cdce67099117 ("PCI: dwc: Fix PORT_LINK_CONTROL update when CDM check enabled") - Just resend. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru> Cc: linux-pci@vger.kernel.org Cc: dmaengine@vger.kernel.org Cc: linux-kernel@vger.kernel.org Serge Semin (10): PCI: dwc: Fix erroneous version type test helper PCI: dwc: Fix inbound iATU entries out-of-bounds warning message PCI: bt1: Enable async probe type PCI: bt1: Fix printing false error message PCI: dwc: Drop duplicated fast-link-mode flag unsetting PCI: dwc: Drop empty line from dw_pcie_link_set_max_speed() PCI: visconti: Convert to using generic resources getter MAINTAINERS: Add all generic DW PCIe RP/EP DT-schemas MAINTAINERS: Add myself as the DW PCIe core reviewer MAINTAINERS: Add myself as the DW eDMA driver reviewer MAINTAINERS | 5 ++- drivers/pci/controller/dwc/pcie-bt1.c | 5 ++- .../pci/controller/dwc/pcie-designware-host.c | 2 +- drivers/pci/controller/dwc/pcie-designware.c | 2 - drivers/pci/controller/dwc/pcie-designware.h | 7 +++- drivers/pci/controller/dwc/pcie-visconti.c | 37 +++++++++---------- 6 files changed, 30 insertions(+), 28 deletions(-)