linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	James Hogan <jhogan@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	linux-pci@vger.kernel.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Paul Burton <paul.burton@mips.com>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH 6/7] MIPS: SGI-IP27: use generic PCI driver
Date: Mon, 28 Jan 2019 05:32:15 -0800	[thread overview]
Message-ID: <20190128133215.GC744@infradead.org> (raw)
In-Reply-To: <20190124174728.28812-7-tbogendoerfer@suse.de>

On Thu, Jan 24, 2019 at 06:47:27PM +0100, Thomas Bogendoerfer wrote:
> Converted bridge code to a platform driver using the PCI generic driver
> framework and use adding platform devices during xtalk scan. This allows
> easier sharing bridge drvier for other SGI platforms like IP30 (Octane) and

Typo: s/drvier/driver/.

In theory this would also have allowed sharing the code with ia64/SN,
except that instead of porting the old mess to Linux 2.6 and cleaning it
up SGI moved the support into the firmware hidden behind PAL calls :(

> +#ifdef CONFIG_NUMA
> +int pcibus_to_node(struct pci_bus *bus)
> +{
> +	struct bridge_controller *bc = BRIDGE_CONTROLLER(bus);
> +
> +	return bc->nasid;
> +}
> +EXPORT_SYMBOL(pcibus_to_node);
> +#endif /* CONFIG_NUMA */

From an abstraction point of view this doesn't really belong into
a bridge driver as it is a global exported function.  I guess we can
keep it here with a fixme comment, but we should probably move this
into a method call instead.

> +dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
> +{
> +	struct pci_dev *pdev = to_pci_dev(dev);
> +	struct bridge_controller *bc = BRIDGE_CONTROLLER(pdev->bus);
> +
> +	return bc->baddr + paddr;
> +}
> +
> +phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dma_addr)
> +{
> +	return dma_addr & ~(0xffUL << 56);
> +}

Similarly here - these are global platform-wide hooks, so having them
in a pci bridge driver is not the proper abstraction level.

Note that we could probably fix these by just switching IP27 and
other users of the bridge chip to use the dma_pfn_offset field
in struct device and stop overriding these functions.

  reply	other threads:[~2019-01-28 13:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 17:47 [PATCH 0/7] MIPS: SGI-IP27 rework Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 1/7] MIPS: SGI-IP27: get rid of volatile and hubreg_t Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 2/7] MIPS: SGI-IP27: clean up bridge access and header files Thomas Bogendoerfer
2019-01-28 13:20   ` Christoph Hellwig
2019-01-28 13:24     ` Thomas Bogendoerfer
2019-01-28 13:33       ` Christoph Hellwig
2019-01-24 17:47 ` [PATCH 3/7] MIPS: SGI-IP27: use pr_info/pr_emerg and pr_cont to fix output Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 4/7] MIPS: SGI-IP27: do xtalk scanning later Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 5/7] MIPS: SGI-IP27: rework HUB interrupts Thomas Bogendoerfer
2019-01-28 13:26   ` Christoph Hellwig
2019-01-24 17:47 ` [PATCH 6/7] MIPS: SGI-IP27: use generic PCI driver Thomas Bogendoerfer
2019-01-28 13:32   ` Christoph Hellwig [this message]
2019-01-29 15:24     ` Thomas Bogendoerfer
2019-01-30  9:17       ` Christoph Hellwig
2019-01-30 17:25         ` Thomas Bogendoerfer
2019-01-30 17:28           ` Christoph Hellwig
2019-02-18 10:58     ` Thomas Bogendoerfer
2019-02-20 15:10       ` Christoph Hellwig
2019-02-20 15:20         ` Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 7/7] MIPS: SGI-IP27: abstract chipset irq from bridge Thomas Bogendoerfer
2019-01-28 13:33   ` Christoph Hellwig
2019-01-28 14:01     ` Thomas Bogendoerfer
2019-01-28 16:27       ` Christoph Hellwig
2019-02-01 14:37         ` Thomas Bogendoerfer

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=20190128133215.GC744@infradead.org \
    --to=hch@infradead.org \
    --cc=bhelgaas@google.com \
    --cc=jhogan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=paul.burton@mips.com \
    --cc=ralf@linux-mips.org \
    --cc=tbogendoerfer@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).