From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
James Hogan <jhogan@kernel.org>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 00/3] MIPS: SGI-IP27 rework part2
Date: Tue, 7 May 2019 17:30:41 +0100 [thread overview]
Message-ID: <20190507163041.GA640@e121166-lin.cambridge.arm.com> (raw)
In-Reply-To: <20190507174820.381fd56f678609416fd8b617@suse.de>
On Tue, May 07, 2019 at 05:48:20PM +0200, Thomas Bogendoerfer wrote:
> On Tue, 7 May 2019 16:31:17 +0100
> Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>
> > On Thu, Apr 18, 2019 at 03:57:26PM -0500, Bjorn Helgaas wrote:
> > > Hi Thomas,
> > >
> > > On Tue, Mar 19, 2019 at 04:47:49PM +0100, Thomas Bogendoerfer wrote:
> > > > SGI IP27 (Origin/Onyx2) and SGI IP30 (Octane) have a similair
> > > > architecture and share some hardware (ioc3/bridge). To share
> > > > the software parts this patchset reworks SGI IP27 interrupt
> > > > and pci bridge code. By using features Linux gained during the
> > > > many years since SGI IP27 code was integrated this even results
> > > > in code reduction and IMHO cleaner code.
> > > >
> > > > Tests have been done on a two module O200 (4 CPUs) and an
> > > > Origin 2000 (8 CPUs).
> > >
> > > Thanks for doing all this work! It seems like it basically converts
> > > some of the SGI PCI code to the structure typical of current host
> > > controller drivers and moves it to drivers/pci/controller, which all
> > > seems great to me.
> >
> > I had a look and the code is really, really MIPS specific, actually
> > I would be interested in understanding how many platforms it supports,
> > it is not even FW configurable.
>
> it's MIPS only and used in basically 3 different SGI platforms.
>
> > With hard-coded resources, <asm/...> includes in driver code and MIPS
> > specific kludges even if it does reuse some APIs shared with controller
> > drivers I am not 100% certain that moving it to drivers/pci/controller
> > buys us anything, this is really arch specific code, however we slice
> > it.
>
> hmm, I thought the idea of having one drivers/pci/controller directory
> is to have all of them in one place.
Well, drivers/pci/controller code should at least try to be arch
agnostic to belong there, there are exceptions, as I said but
they are the exception not the rule.
> > The line between what stays in arch and what goes to
> > drivers/pci/controller is thin but this code is definitely more on the
> > arch side IMHO.
>
> what makes the xgene driver different from the xtalk-bridge driver ? Ok
> it used DT, but it's still just for a specific type of SOCs from one
> vendor, isn't it ?
Eg no <asm/...> includes required; its code can in principle be
reused on other arches, this series can't, it is arch code IMO.
> > I do not question Thomas' effort, which I appreciate, I question
> > the end result and its usefulness, this series is even increasing
> > lines of kernel code, I would like to see the benefits.
>
> the move from arch/mips/pci to drivers/pci/controller increases lines of
> code by two lines. The whole patchset adds 155 lines, but also adds
> functionality to be able to use the driver with different platforms.
I am not convinced it will buy you much to be honest, I might be wrong.
If we move the code we have to have a compelling reason for it to
happen and at the moment I do not necessarily see one, happy to
be proven wrong if you extend it to support other platforms cleanly
(eg with firmware bindings) on top of this series.
> Anyway I can live with not moving to drivers/pci/controller if you don't
> like it there.
I can't certainly maintain it, it is too MIPS specific and I do not like
this code either but that's certainly not your fault.
- Hardcoded resources
- No firmware bindings
- Lots of MIPS specific workarounds
- arch code dependency
I do not think that as it stands it belongs in driver/pci/controller,
no.
Thanks,
Lorenzo
next prev parent reply other threads:[~2019-05-07 16:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-19 15:47 [PATCH v3 00/3] MIPS: SGI-IP27 rework part2 Thomas Bogendoerfer
2019-03-19 15:47 ` [PATCH v3 1/3] MIPS: SGI-IP27: move IP27 specific code out of pci-ip27.c into new file Thomas Bogendoerfer
2019-03-19 15:47 ` [PATCH v3 2/3] MIPS: SGI-IP27: use generic PCI driver Thomas Bogendoerfer
2019-03-19 15:47 ` [PATCH v3 3/3] MIPS: SGI-IP27: abstract chipset irq from bridge Thomas Bogendoerfer
2019-03-19 15:47 ` [PATCH v3 00/3] MIPS: SGI-IP27 rework part2 Thomas Bogendoerfer
2019-04-18 20:57 ` Bjorn Helgaas
2019-05-06 10:37 ` Thomas Bogendoerfer
2019-05-07 9:42 ` Lorenzo Pieralisi
2019-05-07 15:31 ` Lorenzo Pieralisi
2019-05-07 15:48 ` Thomas Bogendoerfer
2019-05-07 16:30 ` Lorenzo Pieralisi [this message]
2019-05-08 6:24 ` Christoph Hellwig
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=20190507163041.GA640@e121166-lin.cambridge.arm.com \
--to=lorenzo.pieralisi@arm.com \
--cc=helgaas@kernel.org \
--cc=jhogan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=paul.burton@mips.com \
--cc=ralf@linux-mips.org \
--cc=tbogendoerfer@suse.de \
/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).