public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jon Mason <jdmason@kudzu.us>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Tom Rix <trix@redhat.com>,
	kishon@ti.com, lpieralisi@kernel.org, kw@linux.com,
	bhelgaas@google.com, Frank.Li@nxp.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] PCI: endpoint: pci-epf-vntb: reduce several globals to statics
Date: Fri, 12 Aug 2022 10:13:59 -0400	[thread overview]
Message-ID: <YvZgJ4IGEG8levOA@kudzu.us> (raw)
In-Reply-To: <20220712200527.GA791291@bhelgaas>

On Tue, Jul 12, 2022 at 03:05:27PM -0500, Bjorn Helgaas wrote:
> On Mon, Jul 04, 2022 at 09:25:59AM -0400, Tom Rix wrote:
> > sparse reports
> > drivers/pci/endpoint/functions/pci-epf-vntb.c:956:10: warning: symbol 'pci_space' was not declared. Should it be static?
> > drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: symbol 'pci_read' was not declared. Should it be static?
> > drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: symbol 'pci_write' was not declared. Should it be static?
> > drivers/pci/endpoint/functions/pci-epf-vntb.c:989:16: warning: symbol 'vpci_ops' was not declared. Should it be static?
> > 
> > These functions and variables are only used in pci-epf-vntb.c, so their storage
> > class specifiers should be static.
> > 
> > Fixes: ff32fac00d97 ("NTB: EPF: support NTB transfer between PCI RC and EP connection")
> > Signed-off-by: Tom Rix <trix@redhat.com>
> 
> Handled via Jon, I guess?
> 
> I'm unclear on the future direction of pci-epf-vntb.c.  Jon, are you
> signing up to maintain this?  MAINTAINERS doesn't seem to reflect
> that, even in next-20220712, so you're not being copied on everything.
> 
> If you are planning to merge and maintain this file, it would be
> helpful to me if you acknowledge patches you merge so I know to ignore
> them.

I massively dropped the ball on all the EPF stuff.  I appologize profusely.

I'm pulling it into my ntb tree bcause of the patch dependencies.  If
you want me to own this stuff because it has ntb in it, then I can do
a matainers entry to reflect it.  My assumption is that because it is
under the drivers/pci umbrella it is yours (unless you want me to own
it).  100% defer to your decision.

All that being said...
Sorry for the extremely long delay in response.  This series is in my
ntb branch and will be in my pull request for v5.20 which should be
going out later today.

Thanks,
Jon

> 
> > ---
> > v2,3 : Change commit prefix
> > 
> > ---
> >  drivers/pci/endpoint/functions/pci-epf-vntb.c | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c
> > index ebf7e243eefa..6f0775b1fec3 100644
> > --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c
> > +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c
> > @@ -953,7 +953,7 @@ static struct config_group *epf_ntb_add_cfs(struct pci_epf *epf,
> >  
> >  #define VPCI_BUS_NUM 0x10
> >  
> > -uint32_t pci_space[] = {
> > +static uint32_t pci_space[] = {
> >  	(VNTB_VID | (VNTB_PID << 16)),	//DeviceID, Vendor ID
> >  	0,		// status, Command
> >  	0xffffffff,	// Class code, subclass, prog if, revision id
> > @@ -972,7 +972,7 @@ uint32_t pci_space[] = {
> >  	0,		//Max Lat, Min Gnt, interrupt pin, interrupt line
> >  };
> >  
> > -int pci_read(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val)
> > +static int pci_read(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val)
> >  {
> >  	if (devfn == 0) {
> >  		memcpy(val, ((uint8_t *)pci_space) + where, size);
> > @@ -981,12 +981,12 @@ int pci_read(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *
> >  	return -1;
> >  }
> >  
> > -int pci_write(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val)
> > +static int pci_write(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val)
> >  {
> >  	return 0;
> >  }
> >  
> > -struct pci_ops vpci_ops = {
> > +static struct pci_ops vpci_ops = {
> >  	.read = pci_read,
> >  	.write = pci_write,
> >  };
> > -- 
> > 2.27.0
> > 

  reply	other threads:[~2022-08-12 14:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-04 13:25 [PATCH v3] PCI: endpoint: pci-epf-vntb: reduce several globals to statics Tom Rix
2022-07-05 15:14 ` [EXT] " Frank Li
2022-07-12 20:05 ` Bjorn Helgaas
2022-08-12 14:13   ` Jon Mason [this message]
2022-08-12 19:21     ` Bjorn Helgaas
2022-08-12 19:28       ` Jon Mason

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=YvZgJ4IGEG8levOA@kudzu.us \
    --to=jdmason@kudzu.us \
    --cc=Frank.Li@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=kishon@ti.com \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=trix@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox