linux-kernel - Re: [PATCH v3 3/5] PCI: st: Provide support for the sti PCIe controller

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: <CAG374jDUPK5hCZBLR_r5om8mh8wy1NyxDaZ-DP_A-xjNN6f2pQ@mail.gmail.com>
Date:	Mon, 13 Apr 2015 09:35:34 +0200
From:	Gabriel Fernandez <gabriel.fernandez@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Paul Bolle <pebolle@...cali.nl>,
	Gabriel FERNANDEZ <gabriel.fernandez@...com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Srinivas Kandagatla <srinivas.kandagatla@...il.com>,
	Maxime Coquelin <maxime.coquelin@...com>,
	Patrice Chotard <patrice.chotard@...com>,
	Russell King <linux@....linux.org.uk>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jingoo Han <jg1.han@...sung.com>,
	Lucas Stach <l.stach@...gutronix.de>,
	Fabrice Gasnier <fabrice.gasnier@...com>,
	Kishon Vijay Abraham I <kishon@...com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Greg KH <gregkh@...uxfoundation.org>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Joe Perches <joe@...ches.com>, Tejun Heo <tj@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Thierry Reding <treding@...dia.com>,
	Phil Edworthy <phil.edworthy@...esas.com>,
	Minghuan Lian <Minghuan.Lian@...escale.com>,
	Tanmay Inamdar <tinamdar@....com>,
	Muralidharan Karicheri <m-karicheri2@...com>,
	Sachin Kamat <sachin.kamat@...sung.com>,
	Andrew Lunn <andrew@...n.ch>,
	Liviu Dudau <liviu.dudau@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"kernel@...inux.com" <kernel@...inux.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH v3 3/5] PCI: st: Provide support for the sti PCIe controller

Hi

Thanks for reviewing.

On 11 April 2015 at 16:55, Arnd Bergmann <arnd@...db.de> wrote:
> On Saturday 11 April 2015 12:17:57 Paul Bolle wrote:
>> Something I didn't spot in my first look at this patch.
>>
>> On Fri, 2015-04-10 at 11:12 +0200, Gabriel FERNANDEZ wrote:
>> > --- a/drivers/pci/host/Kconfig
>> > +++ b/drivers/pci/host/Kconfig
>> >
>> > +config PCI_ST
>> > +     bool "ST PCIe controller"
>> > +     depends on ARCH_STI || (ARM && COMPILE_TEST)
>> > +     select PCIE_DW
>> > +     help
>> > +       Enable PCIe controller support on ST Socs. This controller is based
>> > +       on Designware hardware and therefore the driver re-uses the
>> > +       Designware core functions to implement the driver.
>>
>> You can't have ARCH_STI without ARM, so ARM will always be set if this
>> driver is enabled. Correct?
>
> Right, though the ARM dependency could soon be dropped, once the PCIE_DW
> driver can use generic infrastructure in the few places it relies on
> ARM specific code today.
>
>> > --- /dev/null
>> > +++ b/drivers/pci/host/pci-st.c
>>
>> > +     if (IS_ENABLED(CONFIG_ARM)) {
>> > +             /*
>> > +              * We have to hook the abort handler so that we can intercept
>> > +              * bus errors when doing config read/write that return UR,
>> > +              * which is flagged up as a bus error
>> > +              */
>> > +             hook_fault_code(16+6, st_pcie_abort_handler, SIGBUS, 0,
>> > +                             "imprecise external abort");
>> > +     }
>>
>> So, unless I'm missing something obvious here, IS_ENABLED(CONFIG_ARM)
>> will always evaluate to 1. Can't that test be dropped?
>
> I would leave it in, as it's quite likely to get reused with ARM64 at some
> point in the future (no, I don't know anything about ST's product plans,
> but everybody seems to be doing this).
>
>         Arnd

Yes i agree with that.

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