lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 20 Mar 2014 12:17:22 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Liviu Dudau <Liviu.Dudau@....com>
Cc:	Catalin Marinas <Catalin.Marinas@....com>,
	"linux-pci" <linux-pci@...r.kernel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Will Deacon <Will.Deacon@....com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	"linaro-kernel" <linaro-kernel@...ts.linaro.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	LAKML <linux-arm-kernel@...ts.infradead.org>,
	Tanmay Inamdar <tinamdar@....com>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH v7 3/3] arm64: Add architecture support for PCI

On Thursday 20 March 2014, Liviu Dudau wrote:
> On Wed, Mar 19, 2014 at 06:37:51PM +0000, Arnd Bergmann wrote:
> > On Wednesday 19 March 2014 17:21:41 Liviu Dudau wrote:
> > > 
> > > My ultimate point is that no matter how long we argue about the shape of the functions that
> > > I've added into arch/arm64/kernel/pci.c I don't think we can get away without having that
> > > file, or at least not in the first phase if we want speedy integration into mainline.
> > 
> > Let me simplify the discussion here:
> > 
> > NAK to adding yet another architecture specific implementation.
> 
> So what would be your approach for handling pci_address_to_pio() in a non-arch specific way?
> 
> unsigned long __weak pci_address_to_pio(phys_addr_t address)
> {
> #ifdef ARCH_HAS_IOSPACE
>         if (address > IO_SPACE_LIMIT)
>                 return (unsigned long)-1;
> 
>         return (unsigned long) address;
> #else
>         struct ioresource *res;
> 
>         list_for_each_entry(res, &io_list, list) {
>                 if (address >= res->start &&
>                         address < res->start + res->size) {
>                         return res->start - address;
>                 }
>         }
> 
>         return (unsigned long)-1;
> #endif
> }
> 
> 
> Either that, or you have more magic rabbits than me.

I don't even understand why you want to create a generic pci_address_to_pio
implementation, when we don't need that for arm64 at all. Unless I'm
missing something important, that function is only called in case of
PCI_PROBE_DEVTREE with pci_of_scan on PowerPC. I don't expect any
architecture to do the same thing, and the only other architecture that
needs something like it (sparc) has a different implementation.

The regular (non-DEVTREE) PCI bus scan should just be able to translate
the BUS I/O addresses into Linux I/O port numbers using io_offset,
without going through an intermediate step of translating into a CPU
physical address first, so the entire lookup method won't get used.

The reason why PowerPC needs it is that they traditionally don't
use PCI config space access to assign or look at resources, but
instead rely on the firmware to have set it up in advance and then
put matching information into DT and the BARs. For Solaris and AIX,
it's probably easier to use the information from DT, but in Linux,
we already need to implement the manual bus scan, e.g. to do
PCI device hotplugging if nothing else.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists