linux-kernel - Re: [RFC PATCH] PCI/pci-host-generic: Add support for Cavium Thunder fixed BARs.

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 linux-cve-announce 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]

Message-ID: <5656149D.50704@caviumnetworks.com>
Date:	Wed, 25 Nov 2015 12:05:49 -0800
From:	David Daney <ddaney@...iumnetworks.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	<linux-arm-kernel@...ts.infradead.org>,
	Bjorn Helgaas <helgaas@...nel.org>,
	David Daney <ddaney.cavm@...il.com>,
	David Daney <david.daney@...ium.com>,
	Marc Zyngier <marc.zyngier@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	<linux-kernel@...r.kernel.org>,
	"Sean O. Stalley" <sean.stalley@...el.com>,
	<linux-pci@...r.kernel.org>, Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [RFC PATCH] PCI/pci-host-generic: Add support for Cavium Thunder
 fixed BARs.

On 11/25/2015 11:52 AM, Arnd Bergmann wrote:
> On Wednesday 25 November 2015 11:06:52 Bjorn Helgaas wrote:
>>
>> On Mon, Sep 28, 2015 at 05:56:24PM -0700, David Daney wrote:
>>> From: David Daney <david.daney@...ium.com>
>>>
>>> Early versions of the Cavium Thunder CN88XX processor are missing
>>> Enhanced Allocation (EA) capabilities for the fixed BAR addresses used
>>> by the on-SoC hardware blocks.
>>>
>>> Add config access functions that synthesize the missing EA
>>> capabilities for versions that are missing that information.  Since
>>> this is a little hacky, gate the inclusion of the code with a new
>>> Kconfig variable.
>>>
>>> Signed-off-by: David Daney <david.daney@...ium.com>
>>
>> What about this one?  Do we still need it?  This version looks like it
>> still has some debug code and it feels like a lot of hard-coding of
>> config offsets; it'd be nice if it could be more table-driven.  But
>> maybe this isn't needed anymore anyway.
>
> I still think it doesn't belong into the generic driver. We have the
> abstraction for drivers based on the compatible string to handle
> nonstandard PCI host bridges, and the generic driver should really
> just handle the generic code.

Somebody should make a decision about this point.

Here is what happens:

  1) A driver for non-generic PCI host bridge is submitted.

  2) Comments are received stating that it is just another PCI host 
bridge and please use pci-host-generic instead.

  3) Patches to pci-host-generic are submitted.

  4) Comments are received stating that pci-host-generic is for generic 
things only, and please create a device specific driver.

  5) goto 1


>
> It's easy enough to split out the common parts if we want to reuse
> some of this, or to move them into drivers/pci/*.c for others to
> reuse too.
>

If we do that, do you want "pci-host-cam-generic" and 
"pci-host-ecam-generic" split out too?

They are two completely different things crammed into the single 
pci-host-generic driver source file.  Or is there some set of config 
access methods that are sufficiently generic that they can stay?

David Daney


> 	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/