From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
Joao Pinto <Joao.Pinto@synopsys.com>,
"pawel.moll@arm.com" <pawel.moll@arm.com>,
"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"Alexey.Brodkin@synopsys.com" <Alexey.Brodkin@synopsys.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"CARLOS.PALMINHA@synopsys.com" <CARLOS.PALMINHA@synopsys.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"helgaas@kernel.org" <helgaas@kernel.org>,
"galak@codeaurora.org" <galak@codeaurora.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH v5 1/2] PCI support added to ARC
Date: Thu, 14 Jan 2016 17:41:40 +0530 [thread overview]
Message-ID: <5697907C.4030602@synopsys.com> (raw)
In-Reply-To: <4888629.rSv29HOrHE@wuerfel>
On Thursday 14 January 2016 05:29 PM, Arnd Bergmann wrote:
> On Thursday 14 January 2016 10:51:32 Vineet Gupta wrote:
>>>>
>>>> A somewhat nicer method would be to have callback pointers in struct
>>>> pci_host_bridge, and call those when they are non-NULL so we can
>>>> remove the global pcibios_* functions from the API. That would also
>>>> bring us a big step closer to having PCI support itself as a loadable
>>>> module, and it would better reflect that those functions are really
>>>> host bridge specific rather than architecture specific. When you use
>>>> the same host bridge on multiple architectures, you typically have
>>>> the same requirements for hacks in there, but each architectures may
>>>> need to support multiple host bridges with different requirements.
>>> Since we will be constantly improving the driver and the core itself, I suggest
>>> that this functions be made __weak and in an update we can turn it struct
>>> pointers just like Arnd suggested. Is this good for you?
>>
>> There is no point in making it weak, w/o a fallback version in generic code. For
>> this series, I suggest you just remove the straggler EXPORT_SYMBOL and respin.
>>
>
> To clarify: I don't particularly like __weak functions anywhere, but they
> are already common in drivers/pci, so we can add a couple more to reach
> the goal of removing all architecture specific code.
But I see quite a bit of "weak design pattern" in kernel is common when an API
needs to be implemented across arches and it same for most of them. I agree that
this is not as ideal from code flow analysis but saves a lot of duplication.
> However, there should never be a reason to add a __weak function in
> arch code that gets overridden by common code, that would be very confusing
> and not helpful.
Agree. That was never my suggestion anyways. I'd asked __weak version be defined
in common code so we could reuse it and elide the ARC version and at the same time
not breaking others, and in longer run removing the dups elsewhere.
Thx,
-Vineet
>
> Arnd
>
next prev parent reply other threads:[~2016-01-14 12:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 11:04 [PATCH v6 0/2] adding PCI support to AXS10x Joao Pinto
2016-01-14 11:04 ` [PATCH v6 1/2] PCI support added to ARC Joao Pinto
2016-01-14 5:26 ` [PATCH v5 " Vineet Gupta
2016-01-14 10:22 ` Arnd Bergmann
2016-01-14 10:42 ` Joao Pinto
2016-01-14 10:51 ` Vineet Gupta
2016-01-14 10:54 ` Joao Pinto
2016-01-14 11:59 ` Arnd Bergmann
2016-01-14 12:11 ` Vineet Gupta [this message]
2016-01-14 11:11 ` [PATCH v6 " Vineet Gupta
2016-01-18 11:30 ` Joao Pinto
2016-01-27 14:29 ` Joao Pinto
2016-01-27 21:59 ` Bjorn Helgaas
2016-01-28 17:00 ` Joao Pinto
2016-01-29 20:40 ` Bjorn Helgaas
2016-02-01 9:33 ` Joao Pinto
2016-01-14 11:04 ` [PATCH v6 2/2] add new platform driver for PCI RC Joao Pinto
2016-01-29 20:36 ` Bjorn Helgaas
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=5697907C.4030602@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=Alexey.Brodkin@synopsys.com \
--cc=CARLOS.PALMINHA@synopsys.com \
--cc=Joao.Pinto@synopsys.com \
--cc=arnd@arndb.de \
--cc=galak@codeaurora.org \
--cc=helgaas@kernel.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
/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).