All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Hans Zhang <18255117159@163.com>
Cc: lpieralisi@kernel.org, bhelgaas@google.com, kw@linux.com,
	 manivannan.sadhasivam@linaro.org, robh@kernel.org,
	jingoohan1@gmail.com,  thomas.richard@bootlin.com,
	linux-pci@vger.kernel.org,  LKML <linux-kernel@vger.kernel.org>
Subject: Re: [v7 2/5] PCI: Refactor capability search functions to eliminate code duplication
Date: Tue, 8 Apr 2025 19:18:28 +0300 (EEST)	[thread overview]
Message-ID: <e4db2248-ed8b-d270-d417-9efdca947e8e@linux.intel.com> (raw)
In-Reply-To: <ef311715-3e61-4bf5-bdae-58fd87a3d5e7@163.com>

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

On Tue, 8 Apr 2025, Hans Zhang wrote:

> 
> 
> On 2025/4/8 01:03, Ilpo Järvinen wrote:
> > > Hi Ilpo,
> > > 
> > > The [v9 3/6]patch I plan to submit is as follows, please review it.
> > > 
> > >  From 6da415d130e76b57ecf401f14bf0b66f20407839 Mon Sep 17 00:00:00 2001
> > > From: Hans Zhang<18255117159@163.com>
> > > Date: Fri, 4 Apr 2025 00:20:29 +0800
> > > Subject: [v9 3/6] PCI: Refactor capability search into common macros
> > > 
> > > - Capability search is done both in PCI core and some controller drivers.
> > > - PCI core's cap search func requires PCI device and bus structs exist.
> > > - Controller drivers cannot use PCI core's cap search func as they
> > >    need to find capabilities before they instantiated the PCI device & bus
> > >    structs.
> > > 
> > > - Move capability search into a macro so it can be reused where normal
> > >    PCI config space accessors cannot yet be used due to lack of the
> > >    instantiated PCI dev.
> > > - Instead, give the config space reading function as an argument to the
> > >    new macro.
> > > - Convert PCI core to use the new macro.
> > None of these bullets are true lists so please write them as normal
> > English paragraphs. Also please extend some of shortened words lke "cap"
> > --> "Capability", "PCI dev" -> PCI Device (for terms, the capitalization
> > of the first letter, you should follow what the PCI specs use).
> > 
> 
> Dear Ilpo,
> 
> Thank you very much for your reply. Is it OK to modify it like this?
> 
> The PCI Capability search functionality is duplicated across the PCI core and
> several controller drivers.  The core's current implementation
> requires fully initialized PCI device and bus structures, which prevents
> controller drivers from using it during early initialization phases before
> these structures are available.
> 
> Move the Capability search logic into a header-based macro that accepts a
> config space accessor function as an argument.  This enables controller
> drivers to perform Capability discovery using their early access mechanisms
> prior to full device initialization while maintaining the original search
> behavior.

... while maintaining ... ->

... while sharing the Capability search code.

> 
> Convert the existing PCI core Capability search implementation to use this new
> macro

I think the rest of this paragraph after this are unnecessary.

> , eliminating code duplication. The refactoring preserves the original
> functionality without behavioral changes, while allowing both the core and
> drivers to share common Capability discovery logic.

Other than that, it seemed good enough for me.

-- 
 i.

> > > The macros now implement, parameterized by the config access method. The
> > > PCI core functions are converted to utilize these macros with the standard
> > > pci_bus_read_config accessors. Controller drivers can later use the same
> > > macros with their early access mechanisms while maintaining the existing
> > > protection against infinite loops through preserved TTL checks.
> > > 
> > > The ttl parameter was originally an additional safeguard to prevent
> > > infinite loops in corrupted config space.  However, the
> > > PCI_FIND_NEXT_CAP_TTL macro already enforces a TTL limit internally.
> > > Removing redundant ttl handling simplifies the interface while maintaining
> > > the safety guarantee. This aligns with the macro's design intent of
> > > encapsulating TTL management.
> > > 
> > > Signed-off-by: Hans Zhang<18255117159@163.com>
> > > ---
> > >   drivers/pci/pci.c | 70 +++++---------------------------------
> > >   drivers/pci/pci.h | 86 +++++++++++++++++++++++++++++++++++++++++++++++
> > >   2 files changed, 95 insertions(+), 61 deletions(-)
> 

  reply	other threads:[~2025-04-08 16:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02  4:20 [v7 0/5] Refactor capability search into common macros Hans Zhang
2025-04-02  4:20 ` [v7 1/5] PCI: " Hans Zhang
2025-04-02 12:42   ` Ilpo Järvinen
2025-04-02 15:31     ` Hans Zhang
2025-04-03  9:10       ` Ilpo Järvinen
2025-04-03 12:22         ` Hans Zhang
2025-04-03 16:31           ` Hans Zhang
2025-04-02  4:20 ` [v7 2/5] PCI: Refactor capability search functions to eliminate code duplication Hans Zhang
2025-04-02  9:19   ` kernel test robot
2025-04-02 10:42     ` Hans Zhang
2025-04-02 12:38   ` Ilpo Järvinen
2025-04-02 15:37     ` Hans Zhang
2025-04-03  9:15       ` Ilpo Järvinen
2025-04-03 12:24         ` Hans Zhang
2025-04-03 16:29           ` Hans Zhang
2025-04-03 16:35           ` Hans Zhang
2025-04-07 17:03             ` Ilpo Järvinen
2025-04-08 12:19               ` Hans Zhang
2025-04-08 16:18                 ` Ilpo Järvinen [this message]
2025-04-09  1:37                   ` Hans Zhang
2025-04-02  4:20 ` [v7 3/5] PCI: dwc: Use common PCI host bridge APIs for finding the capabilities Hans Zhang
2025-04-02 11:58   ` kernel test robot
2025-04-02 12:18     ` Hans Zhang
2025-04-02  4:20 ` [v7 4/5] PCI: cadence: " Hans Zhang
2025-04-02  4:20 ` [v7 5/5] PCI: cadence: Use cdns_pcie_find_*capability to avoid hardcode Hans Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e4db2248-ed8b-d270-d417-9efdca947e8e@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=18255117159@163.com \
    --cc=bhelgaas@google.com \
    --cc=jingoohan1@gmail.com \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=robh@kernel.org \
    --cc=thomas.richard@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.