public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org,
	Rusty Russell <rusty@rustcorp.com.au>,
	virtualization@lists.linux-foundation.org,
	linux-sh@vger.kernel.org,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux390@de.ibm.com, Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	linux-s390@vger.kernel.org
Subject: Re: [PATCH RFC 2/5] s390: add pci_iomap_range
Date: Fri, 19 Dec 2014 16:28:29 +0200	[thread overview]
Message-ID: <20141219142829.GA13440@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1412191456480.1794@denkbrett>

On Fri, Dec 19, 2014 at 03:13:37PM +0100, Sebastian Ott wrote:
> On Mon, 15 Dec 2014, Michael S. Tsirkin wrote:
> > From: Michael S Tsirkin <mst@redhat.com>
> > 
> > Virtio drivers should map the part of the range they need, not
> > necessarily all of it.
> > To this end, support mapping ranges within BAR on s390.
> > Since multiple ranges can now be mapped within a BAR, we keep track of
> > the number of mappings created, and only clear out the mapping for a BAR
> > when this number reaches 0.
> > 
> 
> I can't say much about the users of this interface but in principle I'm
> OK with such a change.

I don't have an s390 system with pci for testing - could you help me out
by testing this and confirming it doesn't break things?

> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >  arch/s390/include/asm/pci_io.h |  1 +
> >  arch/s390/pci/pci.c            | 34 +++++++++++++++++++++++++++-------
> >  2 files changed, 28 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/s390/include/asm/pci_io.h b/arch/s390/include/asm/pci_io.h
> > index d194d54..25228b3 100644
> > --- a/arch/s390/include/asm/pci_io.h
> > +++ b/arch/s390/include/asm/pci_io.h
> > @@ -16,6 +16,7 @@
> >  struct zpci_iomap_entry {
> >  	u32 fh;
> >  	u8 bar;
> > +	u16 count;
> >  };
> > 
> >  extern struct zpci_iomap_entry *zpci_iomap_start;
> > diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> > index 2fa7b14..51cb653 100644
> > --- a/arch/s390/pci/pci.c
> > +++ b/arch/s390/pci/pci.c
> > @@ -259,7 +259,10 @@ void __iowrite64_copy(void __iomem *to, const void *from, size_t count)
> >  }
> > 
> >  /* Create a virtual mapping cookie for a PCI BAR */
> > -void __iomem *pci_iomap(struct pci_dev *pdev, int bar, unsigned long max)
> > +void __iomem *pci_iomap_range(struct pci_dev *pdev,
> > +			      int bar,
> > +			      unsigned long offset,
> > +			      unsigned long max)
> >  {
> >  	struct zpci_dev *zdev =	get_zdev(pdev);
> >  	u64 addr;
> > @@ -270,14 +273,27 @@ void __iomem *pci_iomap(struct pci_dev *pdev, int bar, unsigned long max)
> > 
> >  	idx = zdev->bars[bar].map_idx;
> >  	spin_lock(&zpci_iomap_lock);
> > -	zpci_iomap_start[idx].fh = zdev->fh;
> > -	zpci_iomap_start[idx].bar = bar;
> > +	if (zpci_iomap_start[idx].count++) {
> > +		BUG_ON(zpci_iomap_start[idx].fh != zdev->fh ||
> > +		       zpci_iomap_start[idx].bar != bar);
> > +	} else {
> > +		zpci_iomap_start[idx].fh = zdev->fh;
> > +		zpci_iomap_start[idx].bar = bar;
> > +	}
> > +	/* Detect overrun */
> > +	BUG_ON(!zpci_iomap_start[idx].count);
> >  	spin_unlock(&zpci_iomap_lock);
> > 
> >  	addr = ZPCI_IOMAP_ADDR_BASE | ((u64) idx << 48);
> > -	return (void __iomem *) addr;
> > +	return (void __iomem *) addr + offset;
> >  }
> > -EXPORT_SYMBOL_GPL(pci_iomap);
> > +EXPORT_SYMBOL_GPL(pci_iomap_range);
> > +
> > +void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
> > +{
> > +	return pci_iomap_range(dev, bar, 0, maxlen);
> > +}
> > +EXPORT_SYMBOL(pci_iomap);
> 
> This was EXPORT_SYMBOL_GPL. I guess, for this patch, it should stay that
> way. ...Hm, everyone else has this stuff as EXPORT_SYMBOL looks like we
> should use that too.
> 
> Regards,
> Sebastian

OK, so you want two patches: one with new functionality,
one switching to EXPORT_SYMBOL?


> > 
> >  void pci_iounmap(struct pci_dev *pdev, void __iomem *addr)
> >  {
> > @@ -285,8 +301,12 @@ void pci_iounmap(struct pci_dev *pdev, void __iomem *addr)
> > 
> >  	idx = (((__force u64) addr) & ~ZPCI_IOMAP_ADDR_BASE) >> 48;
> >  	spin_lock(&zpci_iomap_lock);
> > -	zpci_iomap_start[idx].fh = 0;
> > -	zpci_iomap_start[idx].bar = 0;
> > +	/* Detect underrun */
> > +	BUG_ON(!zpci_iomap_start[idx].count);
> > +	if (!--zpci_iomap_start[idx].count) {
> > +		zpci_iomap_start[idx].fh = 0;
> > +		zpci_iomap_start[idx].bar = 0;
> > +	}
> >  	spin_unlock(&zpci_iomap_lock);
> >  }
> >  EXPORT_SYMBOL_GPL(pci_iounmap);
> > -- 
> > MST
> > 
> > 

  reply	other threads:[~2014-12-19 14:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-15 21:33 [PATCH RFC 0/5] virtio pci: virtio 1.0 support Michael S. Tsirkin
2014-12-15 21:33 ` [PATCH RFC 1/5] pci: add pci_iomap_range Michael S. Tsirkin
2014-12-15 21:33 ` [PATCH RFC 2/5] s390: " Michael S. Tsirkin
2014-12-19 14:13   ` Sebastian Ott
2014-12-19 14:28     ` Michael S. Tsirkin [this message]
2014-12-19 15:13       ` Sebastian Ott
2014-12-15 21:33 ` [PATCH RFC 3/5] virtio-pci: define layout for virtio 1.0 Michael S. Tsirkin
2014-12-15 21:33 ` [PATCH RFC 4/5] virtio_pci: modern driver Michael S. Tsirkin
2014-12-15 21:33 ` [PATCH RFC 5/5] virtio_pci: macros for PCI layout offsets Michael S. Tsirkin

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=20141219142829.GA13440@redhat.com \
    --to=mst@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux390@de.ibm.com \
    --cc=rusty@rustcorp.com.au \
    --cc=schwidefsky@de.ibm.com \
    --cc=sebott@linux.vnet.ibm.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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