[RESEND,v3,00/10] PCI: dwc: Relatively simple fixes and cleanups

  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(-)
  

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
> 
> -- 
> மணிவண்ணன் சதாசிவம்