mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Yinghai Lu <yinghai@kernel.org>, Ram Pai <linuxram@us.ibm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v4 27/29] PCI: Make piix4 quirk to use addon_res
Date: Fri, 26 Apr 2013 22:29:29 +0200	[thread overview]
Message-ID: <1614149.2EDsY9ltHk@vostro.rjw.lan> (raw)
In-Reply-To: <CAErSpo42D-jyY+7f66fYUprDgh-3E0qV1O1cpXjWK2+iBZ_bBQ@mail.gmail.com>

On Friday, April 26, 2013 09:22:47 AM Bjorn Helgaas wrote:
> [+cc Rafael, linux-acpi]
> 
> On Thu, Apr 25, 2013 at 2:39 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > On Fri, Apr 12, 2013 at 4:44 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> >> After they are put in add-on resources, they will be safely claimed later.
> >
> > It took me a while to understand what's going on here, but this is
> > actually a pretty cool idea.  It would be nice to explain a little
> > about what the patch is doing and how these "pseudo-BARs" work, though
> > :)
> 
> After thinking about this overnight, I'm not so sure about this.  I
> think the point of this is to manage resources that are consumed by
> the device but don't conform to the PCI spec.  Most resources don't
> need quirks because they're either described by standard BAR registers
> or by the exceptions for "legacy I/O devices," e.g., IDE or VGA.
> 
> I would expect that the "architected" way to deal with non-standard
> resources like this is to describe them via a PNP0C02 or similar ACPI
> device.  That way, the OS would not need device-specific quirks like
> this.
> 
> If we do add something like this patch, we're also adding a way for
> Linux to *write* these non-standard BARs, which means they can become
> out-of-sync with the ACPI description of them.  I think the BIOS is
> entitled to assume that if it describes a resource via _CRS and it
> doesn't provide a corresponding _SRS, the resource will remain
> unchanged by the OS.

Agreed.

Thanks,
Rafael


> >> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> >> ---
> >>  drivers/pci/quirks.c | 95 +++++++++++++++++++++++++++++++++++++++++++---------
> >>  1 file changed, 79 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> >> index 2dac170..6706182 100644
> >> --- a/drivers/pci/quirks.c
> >> +++ b/drivers/pci/quirks.c
> >> @@ -382,14 +382,14 @@ static void quirk_ali7101_acpi(struct pci_dev *dev)
> >>  }
> >>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL,     PCI_DEVICE_ID_AL_M7101,         quirk_ali7101_acpi);
> >>
> >> -static void piix4_io_quirk(struct pci_dev *dev, const char *name, unsigned int port, unsigned int enable)
> >> +static int piix4_read_io(struct pci_dev *dev, struct resource *res, int port)
> >
> > We're reading from "port," which is really the address of a dword in
> > config space, not a port, so I would have called it "pos" like
> > __pci_read_base() did.  If I understand correctly, we're reading a
> > BAR-like register that contains the base address of an I/O port
> > region.
> >
> > "piix4_read_io_base(struct pci_dev *dev, struct resource *res, int
> > pos)" would make more sense to me.
> >
> >>  {
> >>         u32 devres;
> >>         u32 mask, size, base;
> >> +       struct pci_bus_region bus_region;
> >>
> >>         pci_read_config_dword(dev, port, &devres);
> >> -       if ((devres & enable) != enable)
> >> -               return;
> >> +
> >>         mask = (devres >> 16) & 15;
> >>         base = devres & 0xffff;
> >>         size = 16;
> >> @@ -399,23 +399,54 @@ static void piix4_io_quirk(struct pci_dev *dev, const char *name, unsigned int p
> >>                         break;
> >>                 size = bit;
> >>         }
> >> -       /*
> >> -        * For now we only print it out. Eventually we'll want to
> >> -        * reserve it (at least if it's in the 0x1000+ range), but
> >> -        * let's get enough confirmation reports first.
> >> -        */
> >>         base &= -size;
> >> -       dev_info(&dev->dev, "%s PIO at %04x-%04x\n", name, base, base + size - 1);
> >> +
> >> +       bus_region.start = base;
> >> +       bus_region.end = base + size - 1;
> >> +       res->flags |= IORESOURCE_IO;
> >> +       pcibios_bus_to_resource(dev, res, &bus_region);
> >> +       dev_info(&dev->dev, "PIO at %pR\n", res);
> >> +
> >> +       return 0;
> >>  }
> >> +static int piix4_write_io(struct pci_dev *dev, struct resource *res, int port)
> >> +{
> >> +       u32 devres;
> >> +       struct pci_bus_region bus_region;
> >> +       unsigned size = to_pci_dev_addon_resource(res)->size;
> >>
> >> -static void piix4_mem_quirk(struct pci_dev *dev, const char *name, unsigned int port, unsigned int enable)
> >> +       pcibios_resource_to_bus(dev, &bus_region, res);
> >> +
> >> +       pci_read_config_dword(dev, port, &devres);
> >> +       devres &= 0xffff0000 | (size - 1);
> >> +       devres |= bus_region.start & 0xffff & (~(size - 1));
> >> +       pci_write_config_dword(dev, port, devres);
> >> +
> >> +       return 0;
> >> +}
> >> +static struct resource_ops piix4_io_ops = {
> >> +       .read = piix4_read_io,
> >> +       .write = piix4_write_io,
> >> +};
> >> +static void piix4_io_quirk(struct pci_dev *dev, char *name, unsigned int port,
> >> +                               unsigned int enable)
> >
> > I think these (piix4_io_quirk() and piix4_mem_quirk()) would read
> > better if they were something like:
> >
> >     piix4_add_io_bar(struct pci_dev *dev, unsigned int pos, u32
> > enable, char *name);
> >
> >>  {
> >>         u32 devres;
> >> -       u32 mask, size, base;
> >>
> >>         pci_read_config_dword(dev, port, &devres);
> >>         if ((devres & enable) != enable)
> >>                 return;
> >> +
> >> +       pci_add_dev_addon_resource(dev, port, 0, &piix4_io_ops, name);
> >> +}
> >> +
> >> +static int piix4_read_mem(struct pci_dev *dev, struct resource *res, int port)
> >> +{
> >> +       u32 devres;
> >> +       u32 mask, size, base;
> >> +       struct pci_bus_region bus_region;
> >> +
> >> +       pci_read_config_dword(dev, port, &devres);
> >>         base = devres & 0xffff0000;
> >>         mask = (devres & 0x3f) << 16;
> >>         size = 128 << 16;
> >> @@ -425,12 +456,44 @@ static void piix4_mem_quirk(struct pci_dev *dev, const char *name, unsigned int
> >>                         break;
> >>                 size = bit;
> >>         }
> >> -       /*
> >> -        * For now we only print it out. Eventually we'll want to
> >> -        * reserve it, but let's get enough confirmation reports first.
> >> -        */
> >>         base &= -size;
> >> -       dev_info(&dev->dev, "%s MMIO at %04x-%04x\n", name, base, base + size - 1);
> >> +       bus_region.start = base;
> >> +       bus_region.end = base + size - 1;
> >> +       res->flags |= IORESOURCE_MEM;
> >> +       pcibios_bus_to_resource(dev, res, &bus_region);
> >> +       dev_info(&dev->dev, "MMIO at %pR\n", res);
> >> +
> >> +       return 0;
> >> +}
> >> +static int piix4_write_mem(struct pci_dev *dev, struct resource *res, int port)
> >> +{
> >> +       u32 devres;
> >> +       struct pci_bus_region bus_region;
> >> +       unsigned size = to_pci_dev_addon_resource(res)->size;
> >> +
> >> +       pcibios_resource_to_bus(dev, &bus_region, res);
> >> +
> >> +       pci_read_config_dword(dev, port, &devres);
> >> +       devres &= 0x0000ffff | ((size - 1) & 0xffff0000);
> >> +       devres |= bus_region.start & 0xffff0000 & (~(size - 1));
> >> +       pci_write_config_dword(dev, port, devres);
> >> +
> >> +       return 0;
> >> +}
> >> +static struct resource_ops piix4_mem_ops = {
> >> +       .read = piix4_read_mem,
> >> +       .write = piix4_write_mem,
> >> +};
> >> +static void piix4_mem_quirk(struct pci_dev *dev, char *name, unsigned int port,
> >> +                               unsigned int enable)
> >> +{
> >> +       u32 devres;
> >> +
> >> +       pci_read_config_dword(dev, port, &devres);
> >> +       if ((devres & enable) != enable)
> >> +               return;
> >> +
> >> +       pci_add_dev_addon_resource(dev, port, 0, &piix4_mem_ops, name);
> >>  }
> >>
> >>  /*
> >> --
> >> 1.8.1.4
> >>
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

  reply	other threads:[~2013-04-26 20:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-12 22:44 [PATCH v4 00/29] PCI: Add for_each_pci_resource and addon_res support Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 01/29] PCI: Clean up quirk_io_region Yinghai Lu
2013-04-15 18:23   ` Bjorn Helgaas
2013-04-12 22:44 ` [PATCH v4 02/29] PCI: Add pci_dev_resource_n() Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 03/29] PCI: Update pci_resource_start etc to use pci_dev_resource_n() Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 04/29] PCI: Add pci_dev_resource_idx() helper Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 05/29] PCI: Add is_pci_*_resource_idx() helpers Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 06/29] PCI: pci resource iterator Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 07/29] PCI, x86: Use for_each_pci_resource() with pci_allocate_bridge_resources Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 08/29] PCI, x86: Use for_each_pci_resource() with pci_allocate_dev_resources Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 09/29] PCI: Use for_each_pci_resource() with IOV releated functions Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 10/29] PCI, acpiphp: Use for_each_pci_resource() helper Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 11/29] PCI, pciehp: " Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 12/29] PCI: Use for_each_pci_resource() in pci_enable_dev Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 13/29] PCI: Use for_each_pci_resource() in pci_reassigndev Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 14/29] PCI: Use for_each_pci_resource() with pci bar reassign funcs Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 15/29] PCI: Use for_each_pci_resource() in pci_assign_resource Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 16/29] PCI, x86: Use for_each_pci_resource() with noassign_bars Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 17/29] PCI: Use for_each_pci_resource() in pci_dev_driver() Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 18/29] PCI: Use for_each_pci_resource() in pci resource release Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 19/29] PCI: Use for_each_pci_resource() in pci bases reading Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 20/29] PCI, x86: Use for_each_pci_resource() with mrst Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 21/29] PCI, xen: Use for_each_pci_resource() with xen pci Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 22/29] PCI: Add addon_resource support for pci devices Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 23/29] PCI: Treat addon res as std resources Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 24/29] PCI: Add helpers to add addon_resource Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 25/29] PCI: Update pci_resource_bar() to support addon_resource Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 26/29] PCI: Assign/update resource to addon_res Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 27/29] PCI: Make piix4 quirk to use addon_res Yinghai Lu
2013-04-25 20:39   ` Bjorn Helgaas
2013-04-26 15:22     ` Bjorn Helgaas
2013-04-26 20:29       ` Rafael J. Wysocki [this message]
2013-04-12 22:44 ` [PATCH v4 28/29] PCI: Make quirk_io_region " Yinghai Lu
2013-04-12 22:44 ` [PATCH v4 29/29] PCI: Use addon_fixed_resource with ati fixed resource Yinghai Lu
2013-04-25 19:53 ` [PATCH v4 00/29] PCI: Add for_each_pci_resource and addon_res support Bjorn Helgaas

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=1614149.2EDsY9ltHk@vostro.rjw.lan \
    --to=rjw@sisk.pl \
    --cc=bhelgaas@google.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=yinghai@kernel.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

Powered by JetHome