linux-kernel - Re: [PATCH RESEND] ARM: PCI: Use PCI_CLASS

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]

Date:	Mon, 8 Sep 2014 13:39:40 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	Rostislav Lisovy <lisovy@...il.com>,
	Russell King <linux@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Murali Karicheri <m-karicheri2@...com>,
	Yijing Wang <wangyijing@...wei.com>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH RESEND] ARM: PCI: Use PCI_CLASS_* defines for PCI class

[-cc Mike's old email address]

On Mon, Sep 8, 2014 at 12:03 PM, Jason Gunthorpe
<jgunthorpe@...idianresearch.com> wrote:
> On Mon, Sep 08, 2014 at 10:36:36AM -0600, Bjorn Helgaas wrote:
>
>> Presumably these devices have PCI BARs (since that's how dev->resource
>> got filled in), and we want to somehow ignore them, not assign
>> resources to them, and not allow drivers to use whatever is mapped by
>> the BARs.  But clearing out the struct resources isn't really safe by
>> itself.  The hardware BAR still contains some value, and may still be
>> enabled, which means that it may conflict with other devices.
>
> I've seen this pattern before in the old mvebu stuff.
>
> Essentially for that case the mvebu HW is a repurposed end port core,
> so when working as a root port it presents an end port config space
> (not a root port bridge config space). The BAR in that config space is
> not relevant, so the old mvebu used code like this to hide it from the
> PCI core. Otherwise the core will try to program it from the aperture,
> and the default BAR size is really big, so it runs out of space.

How does mvebu deal with this now?  I don't see anything similar in pci-mvebu.c.

If the BAR is still a functioning PCI BAR, i.e., it decodes address
space and potentially responds to accesses there, we really should pay
attention to it.  That doesn't mean we have to assign space to it, but
for example, we might want to make sure we have PCI_COMMAND_MEM turned
off.  If we just clear out the resource start/end/flags, the PCI core
doesn't have enough information to do that.

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