From: Will Deacon <will.deacon@arm.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Rob Herring <robh@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Alan Douglas <adouglas@cadence.com>,
Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>,
Michal Simek <michal.simek@xilinx.com>,
linux-pci@vger.kernel.org,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] PCI: remove unnecessary check of device_type == pci
Date: Thu, 20 Sep 2018 10:02:22 +0100 [thread overview]
Message-ID: <20180920090222.GA17617@arm.com> (raw)
In-Reply-To: <20180919163301.GA21474@e107981-ln.cambridge.arm.com>
On Wed, Sep 19, 2018 at 05:33:01PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Sep 18, 2018 at 12:05:40PM -0700, Rob Herring wrote:
> > On Thu, Sep 13, 2018 at 7:51 AM Lorenzo Pieralisi
> > <lorenzo.pieralisi@arm.com> wrote:
> > >
> > > On Wed, Aug 29, 2018 at 01:34:40PM -0500, Rob Herring wrote:
> > > > PCI host drivers have already matched on compatible strings, so checking
> > > > device_type is redundant. Also, device_type is considered deprecated for
> > > > FDT though we've still been requiring it for PCI hosts as it is useful
> > > > for finding PCI buses.
> > >
> > > Hi Rob,
> > >
> > > I have no problem with the patch per-se, I can't parse though the second
> > > paragraph, in particular what you mean by "useful for finding PCI
> > > buses".
> >
> > Device_type is the only generic way we can identify PCI buses which is
> > useful for dtc for example to do PCI binding checks. Maybe we can use
> > the node name which is what I'm doing for cpu nodes, but we've been
> > less consistent about that for PCI.
> >
> > >
> > > What about the corresponding dts files ? I suspect we had better leave
> > > them alone lest we can trigger regressions with new dts and older
> > > kernels.
> >
> > Yes. it will take some time before we can remove from dts files. Or
> > maybe only new ones change.
>
> OK, thanks. What about PCI host controllers bindings ? I assume we leave
> the bindings (that enforce device_type) unchanged too.
>
> If Will and Michal have no objections I will queue this patch as-is
> for v4.20.
Fine by me!
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PCI: remove unnecessary check of device_type == pci
Date: Thu, 20 Sep 2018 10:02:22 +0100 [thread overview]
Message-ID: <20180920090222.GA17617@arm.com> (raw)
In-Reply-To: <20180919163301.GA21474@e107981-ln.cambridge.arm.com>
On Wed, Sep 19, 2018 at 05:33:01PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Sep 18, 2018 at 12:05:40PM -0700, Rob Herring wrote:
> > On Thu, Sep 13, 2018 at 7:51 AM Lorenzo Pieralisi
> > <lorenzo.pieralisi@arm.com> wrote:
> > >
> > > On Wed, Aug 29, 2018 at 01:34:40PM -0500, Rob Herring wrote:
> > > > PCI host drivers have already matched on compatible strings, so checking
> > > > device_type is redundant. Also, device_type is considered deprecated for
> > > > FDT though we've still been requiring it for PCI hosts as it is useful
> > > > for finding PCI buses.
> > >
> > > Hi Rob,
> > >
> > > I have no problem with the patch per-se, I can't parse though the second
> > > paragraph, in particular what you mean by "useful for finding PCI
> > > buses".
> >
> > Device_type is the only generic way we can identify PCI buses which is
> > useful for dtc for example to do PCI binding checks. Maybe we can use
> > the node name which is what I'm doing for cpu nodes, but we've been
> > less consistent about that for PCI.
> >
> > >
> > > What about the corresponding dts files ? I suspect we had better leave
> > > them alone lest we can trigger regressions with new dts and older
> > > kernels.
> >
> > Yes. it will take some time before we can remove from dts files. Or
> > maybe only new ones change.
>
> OK, thanks. What about PCI host controllers bindings ? I assume we leave
> the bindings (that enforce device_type) unchanged too.
>
> If Will and Michal have no objections I will queue this patch as-is
> for v4.20.
Fine by me!
Will
next prev parent reply other threads:[~2018-09-20 9:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 18:34 [PATCH] PCI: remove unnecessary check of device_type == pci Rob Herring
2018-08-29 18:34 ` Rob Herring
2018-08-29 18:34 ` Rob Herring
2018-08-30 14:33 ` Alan Douglas
2018-08-30 14:33 ` Alan Douglas
2018-08-30 14:33 ` Alan Douglas
2018-09-11 7:26 ` Subrahmanya Lingappa
2018-09-11 7:26 ` Subrahmanya Lingappa
2018-09-11 7:26 ` Subrahmanya Lingappa
2018-09-13 14:51 ` Lorenzo Pieralisi
2018-09-13 14:51 ` Lorenzo Pieralisi
2018-09-13 14:51 ` Lorenzo Pieralisi
2018-09-18 19:05 ` Rob Herring
2018-09-18 19:05 ` Rob Herring
2018-09-18 19:05 ` Rob Herring
2018-09-19 16:33 ` Lorenzo Pieralisi
2018-09-19 16:33 ` Lorenzo Pieralisi
2018-09-19 16:33 ` Lorenzo Pieralisi
2018-09-20 9:02 ` Will Deacon [this message]
2018-09-20 9:02 ` Will Deacon
2018-09-21 9:29 ` Lorenzo Pieralisi
2018-09-21 9:29 ` Lorenzo Pieralisi
2018-09-25 6:20 ` Michal Simek
2018-09-25 6:20 ` Michal Simek
2018-09-25 9:11 ` Lorenzo Pieralisi
2018-09-25 9:11 ` Lorenzo Pieralisi
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=20180920090222.GA17617@arm.com \
--to=will.deacon@arm.com \
--cc=adouglas@cadence.com \
--cc=bhelgaas@google.com \
--cc=l.subrahmanya@mobiveil.co.in \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=michal.simek@xilinx.com \
--cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.