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