Register bit manipulation in DesignWare PCIe controllers currently
uses repetitive read-modify-write sequences across multiple drivers.
This pattern leads to code duplication and increases maintenance
complexity as each driver implements similar logic with minor variations.

This series introduces dw_pcie_clear_and_set_dword() to centralize atomic
register modification. The helper performs read-clear-set-write operations
in a single function, replacing open-coded implementations. Subsequent
patches refactor individual drivers to use this helper, eliminating
redundant code and ensuring consistent bit handling.

The change reduces overall code size by ~350 lines while improving
maintainability. Each controller driver is updated in a separate
patch to preserve bisectability and simplify review.

---
Hi all,

At the beginning, two patches were made, 0001*.patch, and the others were
one patch. After consideration, I still split the patches. If splitting
is not necessary, I will recombine them into two patches in future
versions.
---

Hans Zhang (13):
  PCI: dwc: Add dw_pcie_clear_and_set_dword() for register bit
    manipulation
  PCI: dwc: Refactor dwc to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor dra7xx to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor imx6 to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor meson to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor armada8k to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor bt1 to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor rockchip to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor fu740 to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor qcom common to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor qcom-ep to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor rcar-gen4 to use dw_pcie_clear_and_set_dword()
  PCI: dwc: Refactor tegra194 to use dw_pcie_clear_and_set_dword()

 drivers/pci/controller/dwc/pci-dra7xx.c       |  10 +-
 drivers/pci/controller/dwc/pci-imx6.c         |  26 ++-
 drivers/pci/controller/dwc/pci-meson.c        |  22 +--
 drivers/pci/controller/dwc/pcie-armada8k.c    |  48 ++----
 drivers/pci/controller/dwc/pcie-bt1.c         |   5 +-
 .../controller/dwc/pcie-designware-debugfs.c  |  67 +++-----
 .../pci/controller/dwc/pcie-designware-ep.c   |  20 +--
 .../pci/controller/dwc/pcie-designware-host.c |  27 ++-
 drivers/pci/controller/dwc/pcie-designware.c  |  74 ++++-----
 drivers/pci/controller/dwc/pcie-designware.h  |  27 +--
 drivers/pci/controller/dwc/pcie-dw-rockchip.c |   7 +-
 drivers/pci/controller/dwc/pcie-fu740.c       |   5 +-
 drivers/pci/controller/dwc/pcie-qcom-common.c |  59 ++++---
 drivers/pci/controller/dwc/pcie-qcom-ep.c     |  14 +-
 drivers/pci/controller/dwc/pcie-rcar-gen4.c   |  23 +--
 drivers/pci/controller/dwc/pcie-tegra194.c    | 155 ++++++++----------
 16 files changed, 239 insertions(+), 350 deletions(-)


base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
-- 
2.25.1

On Thu, Jun 12, 2025 at 12:30:47AM +0800, Hans Zhang wrote:
> Register bit manipulation in DesignWare PCIe controllers currently
> uses repetitive read-modify-write sequences across multiple drivers.
> This pattern leads to code duplication and increases maintenance
> complexity as each driver implements similar logic with minor variations.

When you repost this, can you fix whatever is keeping this series from
being threaded?  All the patches should be responses to the 00/13
cover letter.  Don't repost until at least a couple of days have
elapsed and you make non-trivial changes.

My preference is to make the subject lines like:

  PCI: dra7xx: Refactor ...
  PCI: imx6: Refactor ...

etc.  I think including both dwc and dra7xx is overkill.

You can find the prevailing style with:

  git log --no-merges --oneline --pretty=format:"%h (\"%s\")" drivers/pci/controller/dwc

Whoever applies this series can trivially squash patches together if
that seems better.

On 2025/6/12 04:40, Bjorn Helgaas wrote:
> On Thu, Jun 12, 2025 at 12:30:47AM +0800, Hans Zhang wrote:
>> Register bit manipulation in DesignWare PCIe controllers currently
>> uses repetitive read-modify-write sequences across multiple drivers.
>> This pattern leads to code duplication and increases maintenance
>> complexity as each driver implements similar logic with minor variations.
> 
> When you repost this, can you fix whatever is keeping this series from
> being threaded?  All the patches should be responses to the 00/13
> cover letter.  Don't repost until at least a couple of days have
> elapsed and you make non-trivial changes.
> 

Dear Bjorn,

Every time I send an email to the PCI main list, I will send it to 
myself first, but I have encountered the following problems:
Whether I send my personal 163 email, Outlook email, or my company's 
cixtech email, only 10 patches can be sent. So in the end, I sent each 
patch separately.

This is the first time I have sent an email with a series of more than 
10 patches. My configuration is as follows:
smtpserver = smtp.163.com
smtpserverport = 25
smtpenablestarttlsauto = true
smtpuser = 18255117159@163.com
smtppass = xxx

I suspect it's a problem with China's 163 email. Next, I will try to 
send it using the company's environment. Or when I send this series of 
patches next time, I will paste the web link address of each patch in by 
replying 0000-cover-letter.patch.


git send-email --no-chain-reply-to --quiet --to 
hanshuatuo.zhang@outlook.com patch_hans/dwc_set_dword/*
......
Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): a
Sent [PATCH 00/13] PCI: dwc: Refactor register access with 
dw_pcie_clear_and_set_dword helper
Sent [PATCH 01/13] PCI: dwc: Add dw_pcie_clear_and_set_dword() for 
register bit manipulation
Sent [PATCH 02/13] PCI: dwc: Refactor dwc to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 03/13] PCI: dwc: Refactor dra7xx to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 04/13] PCI: dwc: Refactor imx6 to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 05/13] PCI: dwc: Refactor meson to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 06/13] PCI: dwc: Refactor armada8k to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 07/13] PCI: dwc: Refactor bt1 to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 08/13] PCI: dwc: Refactor rockchip to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 09/13] PCI: dwc: Refactor fu740 to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 10/13] PCI: dwc: Refactor qcom common to use 
dw_pcie_clear_and_set_dword()
MI:DMC 163 gzga-smtp-mtada-g0-3,_____wA3YOjZJEpouIVyHg--.2947S13 
1749689566 
http://mail.163.com/help/help_spam_16.htm?ip=222.71.101.198&hostid=gzga-smtp-mtada-g0-3&time=1749689566


or


git send-email --no-chain-reply-to --quiet --to 1053912923@qq.com 
patch_hans/dwc_set_dword/*
......
Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): a
Sent [PATCH 00/13] PCI: dwc: Refactor register access with 
dw_pcie_clear_and_set_dword helper
Sent [PATCH 01/13] PCI: dwc: Add dw_pcie_clear_and_set_dword() for 
register bit manipulation
Sent [PATCH 02/13] PCI: dwc: Refactor dwc to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 03/13] PCI: dwc: Refactor dra7xx to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 04/13] PCI: dwc: Refactor imx6 to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 05/13] PCI: dwc: Refactor meson to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 06/13] PCI: dwc: Refactor armada8k to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 07/13] PCI: dwc: Refactor bt1 to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 08/13] PCI: dwc: Refactor rockchip to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 09/13] PCI: dwc: Refactor fu740 to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 10/13] PCI: dwc: Refactor qcom common to use 
dw_pcie_clear_and_set_dword()
MI:DMC 163 gzga-smtp-mtada-g0-1,_____wBnOhQ_JUpoES6WHw--.47108S13 
1749689667 
http://mail.163.com/help/help_spam_16.htm?ip=222.71.101.198&hostid=gzga-smtp-mtada-g0-1&time=1749689667

or

git send-email --no-chain-reply-to --quiet --to hans.zhang@cixtech.com 
patch_hans/dwc_set_dword/*
......
Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): a
Sent [PATCH 00/13] PCI: dwc: Refactor register access with 
dw_pcie_clear_and_set_dword helper
Sent [PATCH 01/13] PCI: dwc: Add dw_pcie_clear_and_set_dword() for 
register bit manipulation
Sent [PATCH 02/13] PCI: dwc: Refactor dwc to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 03/13] PCI: dwc: Refactor dra7xx to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 04/13] PCI: dwc: Refactor imx6 to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 05/13] PCI: dwc: Refactor meson to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 06/13] PCI: dwc: Refactor armada8k to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 07/13] PCI: dwc: Refactor bt1 to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 08/13] PCI: dwc: Refactor rockchip to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 09/13] PCI: dwc: Refactor fu740 to use 
dw_pcie_clear_and_set_dword()
Sent [PATCH 10/13] PCI: dwc: Refactor qcom common to use 
dw_pcie_clear_and_set_dword()
MI:DMC 163 gzsmtp2,PSgvCgAnBeWGJUpo7GLnCA--.28592S13 1749689739 
http://mail.163.com/help/help_spam_16.htm?ip=222.71.101.198&hostid=gzsmtp2&time=1749689739




I'm deeply sorry for the inconvenience caused to everyone's review. The 
following are the links of each patch.

0001:https://patchwork.kernel.org/project/linux-pci/patch/20250611163057.860353-1-18255117159@163.com/
0002:https://patchwork.kernel.org/project/linux-pci/patch/20250611163106.860438-1-18255117159@163.com/
0003:https://patchwork.kernel.org/project/linux-pci/patch/20250611163113.860528-1-18255117159@163.com/
0004:https://patchwork.kernel.org/project/linux-pci/patch/20250611163121.860619-1-18255117159@163.com/
0005:https://patchwork.kernel.org/project/linux-pci/patch/20250611163131.860729-1-18255117159@163.com/
0006:https://patchwork.kernel.org/project/linux-pci/patch/20250611163137.860795-1-18255117159@163.com/
0007:https://patchwork.kernel.org/project/linux-pci/patch/20250611163148.860884-1-18255117159@163.com/
0008:https://patchwork.kernel.org/project/linux-pci/patch/20250611163154.860976-1-18255117159@163.com/
0009:https://patchwork.kernel.org/project/linux-pci/patch/20250611163200.861064-1-18255117159@163.com/
0010:https://patchwork.kernel.org/project/linux-pci/patch/20250611163209.861171-1-18255117159@163.com/
0011:https://patchwork.kernel.org/project/linux-pci/patch/20250611163215.861242-1-18255117159@163.com/
0012:https://patchwork.kernel.org/project/linux-pci/patch/20250611163221.861314-1-18255117159@163.com/
0013:https://patchwork.kernel.org/project/linux-pci/patch/20250611163227.861403-1-18255117159@163.com/

> My preference is to make the subject lines like:
> 
>    PCI: dra7xx: Refactor ...
>    PCI: imx6: Refactor ...
> 

Will change.

> etc.  I think including both dwc and dra7xx is overkill.
> 
> You can find the prevailing style with:
> 
>    git log --no-merges --oneline --pretty=format:"%h (\"%s\")" drivers/pci/controller/dwc
> 
> Whoever applies this series can trivially squash patches together if
> that seems better.

Thank you very much for the hint you gave.

Best regards,
Hans

Hello Hans,

On Thu, Jun 12, 2025 at 09:07:40AM +0800, Hans Zhang wrote:
> 
> 
> On 2025/6/12 04:40, Bjorn Helgaas wrote:
> > On Thu, Jun 12, 2025 at 12:30:47AM +0800, Hans Zhang wrote:
> > > Register bit manipulation in DesignWare PCIe controllers currently
> > > uses repetitive read-modify-write sequences across multiple drivers.
> > > This pattern leads to code duplication and increases maintenance
> > > complexity as each driver implements similar logic with minor variations.
> > 
> > When you repost this, can you fix whatever is keeping this series from
> > being threaded?  All the patches should be responses to the 00/13
> > cover letter.  Don't repost until at least a couple of days have
> > elapsed and you make non-trivial changes.
> > 
> 
> Dear Bjorn,
> 
> Every time I send an email to the PCI main list, I will send it to myself
> first, but I have encountered the following problems:
> Whether I send my personal 163 email, Outlook email, or my company's cixtech
> email, only 10 patches can be sent. So in the end, I sent each patch
> separately.
> 
> This is the first time I have sent an email with a series of more than 10
> patches. My configuration is as follows:
> smtpserver = smtp.163.com
> smtpserverport = 25
> smtpenablestarttlsauto = true
> smtpuser = 18255117159@163.com
> smtppass = xxx
> 
> I suspect it's a problem with China's 163 email. Next, I will try to send it
> using the company's environment. Or when I send this series of patches next
> time, I will paste the web link address of each patch in by replying
> 0000-cover-letter.patch.

Perhaps the git-send-email options --batch-size and --relogin-delay can be
of help to you:
https://git-scm.com/docs/git-send-email#Documentation/git-send-email.txt---batch-sizenum


Kind regards,
Niklas

On 2025/6/18 22:57, Niklas Cassel wrote:
> Hello Hans,
> 
> On Thu, Jun 12, 2025 at 09:07:40AM +0800, Hans Zhang wrote:
>>
>>
>> On 2025/6/12 04:40, Bjorn Helgaas wrote:
>>> On Thu, Jun 12, 2025 at 12:30:47AM +0800, Hans Zhang wrote:
>>>> Register bit manipulation in DesignWare PCIe controllers currently
>>>> uses repetitive read-modify-write sequences across multiple drivers.
>>>> This pattern leads to code duplication and increases maintenance
>>>> complexity as each driver implements similar logic with minor variations.
>>>
>>> When you repost this, can you fix whatever is keeping this series from
>>> being threaded?  All the patches should be responses to the 00/13
>>> cover letter.  Don't repost until at least a couple of days have
>>> elapsed and you make non-trivial changes.
>>>
>>
>> Dear Bjorn,
>>
>> Every time I send an email to the PCI main list, I will send it to myself
>> first, but I have encountered the following problems:
>> Whether I send my personal 163 email, Outlook email, or my company's cixtech
>> email, only 10 patches can be sent. So in the end, I sent each patch
>> separately.
>>
>> This is the first time I have sent an email with a series of more than 10
>> patches. My configuration is as follows:
>> smtpserver = smtp.163.com
>> smtpserverport = 25
>> smtpenablestarttlsauto = true
>> smtpuser = 18255117159@163.com
>> smtppass = xxx
>>
>> I suspect it's a problem with China's 163 email. Next, I will try to send it
>> using the company's environment. Or when I send this series of patches next
>> time, I will paste the web link address of each patch in by replying
>> 0000-cover-letter.patch.
> 
> Perhaps the git-send-email options --batch-size and --relogin-delay can be
> of help to you:
> https://git-scm.com/docs/git-send-email#Documentation/git-send-email.txt---batch-sizenum
> 
> 

Dear Niklas,

Wow! Thank you very much for your help. My local test is normal.

Best regards,
Hans

> Kind regards,
> Niklas