[RESEND,v2,00/11] PCI: dwc: Relatively simple fixes and cleanups

Message

Serge Semin March 13, 2023, 8:08 p.m. UTC

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/[e-mail]/
Changelog v2:
- Rebase onto the kernel 6.3-rc2.

Signed-off-by: Serge Semin <[e-mail]>
Cc: Alexey Malahov <[e-mail]>
Cc: Pavel Parkhomenko <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]

Serge Semin (11):
  PCI: dwc: Fix port link CSR improper init if CDM check enabled
  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  |  3 +-
 drivers/pci/controller/dwc/pcie-designware.h  |  7 +++-
 drivers/pci/controller/dwc/pcie-visconti.c    | 37 +++++++++----------
 6 files changed, 31 insertions(+), 28 deletions(-)

Comments

Bjorn Helgaas March 13, 2023, 9:17 p.m. UTC | #1

On Mon, Mar 13, 2023 at 11:08:04PM +0300, Serge Semin wrote:
> ...
> Link: https://lore.kernel.org/linux-pci/[e-mail]/
> Changelog v2:
> - Rebase onto the kernel 6.3-rc2.

This is fine, but just FYI that there's no need to rebase past -rc1
because PCI patches are applied on topic branches based on the PCI
"main" branch, typically -rc1.

Bjorn

Serge Semin March 13, 2023, 10:21 p.m. UTC | #2

Hi Bjorn

On Mon, Mar 13, 2023 at 04:17:52PM -0500, Bjorn Helgaas wrote:
> On Mon, Mar 13, 2023 at 11:08:04PM +0300, Serge Semin wrote:
> > ...
> > Link: https://lore.kernel.org/linux-pci/[e-mail]/
> > Changelog v2:
> > - Rebase onto the kernel 6.3-rc2.
> 

> This is fine, but just FYI that there's no need to rebase past -rc1
> because PCI patches are applied on topic branches based on the PCI
> "main" branch, typically -rc1.

Thanks for reminding about that. I am not that keen of early rc's
because there is a higher risk to catch instability in unexpected
places. Normally I wait for rc2 or newer kernel is released in order
to rebase onto that mainline kernel. I am using the Linus' master
because most of time I get to develop and submit patchsets for several
subsystems concurrently (currently it's PCIe, EDAC, net and MIPS-arch)
and having them rebased on top of each subsystem' next-branch would be
even more risky. Of course I understand that the subsystem main/topic
branches may have some conflicting changes. So normally I make sure
that the submitted changes are applicable against the subsystem trees
if/when it's necessary. (Can't deny though I forget to do that from
time to time.)

-Serge(y)

> 
> Bjorn