From: Rob Herring <robh@kernel.org>
To: Vincent Whitchurch <vincent.whitchurch@axis.com>,
Lizhi Hou <lizhi.hou@amd.com>
Cc: Lee Jones <lee@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
kernel <kernel@axis.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] mfd: Add Simple PCI MFD driver
Date: Mon, 23 Jan 2023 10:36:06 -0600 [thread overview]
Message-ID: <CAL_JsqLHi_1QJ4s28uM1b_Z2f+Nsu_CusAsqsx6vVOCCAPLMgw@mail.gmail.com> (raw)
In-Reply-To: <Y86vm0zDOeb1G3zh@axis.com>
On Mon, Jan 23, 2023 at 10:02 AM Vincent Whitchurch
<vincent.whitchurch@axis.com> wrote:
>
> On Mon, Jan 23, 2023 at 04:32:55PM +0100, Lee Jones wrote:
> > On Mon, 23 Jan 2023, Vincent Whitchurch wrote:
> > > Add a PCI driver which registers all child nodes specified in the
> > > devicetree. It will allow platform devices to be used on virtual
> > > systems which already support PCI and devicetree, such as UML with
> > > virt-pci.
> > >
> > > The driver has no id_table by default; user space needs to provide one
> > > using the new_id mechanism in sysfs.
> >
> > This feels wrong for several reasons.
> >
> > Firstly, I think Greg (Cc:ed) will have something to say about this.
> >
> > Secondly, this driver does literally nothing.
>
> Well, it does do what the commit message says. If there's another way
> of accomplishing that, I'm all ears.
>
> > Why can't you use of of the other, pre-existing "also register my
> > children" compatibles?
> >
> > See: drivers/bus/simple-pm-bus.c
> > drivers/of/platform.c
>
> simple-pm-bus registers a platform driver, and drivers/of/platform.c
> works on the platform bus. The driver added by this patch is a PCI
> driver. So I don't understand how the files you mention could be used
> here?
>
> In case it helps, the relevant nodes in my UML devicetree look something
> like this:
>
> virtio@2 {
dtc should complain about this...
> compatible = "virtio,uml";
Binding?
> virtio-device-id = <1234>;
> ranges;
>
> pci {
> #address-cells = <3>;
> #size-cells = <2>;
> ranges = <0x0000000 0 0 0 0xf0000000 0 0x20000>;
> compatible = "virtio,device4d2", "pci";
"pci" is not a valid compatible string.
> device_type = "pci";
> bus-range = <0 0>;
>
> platform_parent: device@0,0 {
> compatible = "pci494f,dc8";
> reg = <0x00000 0 0 0x0 0x10000>;
> ranges;
>
> uart@10000 {
> compatible = "google,goldfish-tty";
> reg = <0x00000 0 0x10000 0 0x10000>;
This is not a PCI device, so it shouldn't be using PCI addressing.
'ranges' needs an entry (for each BAR) to translate to just a normal
MMIO bus with 1 or 2 address/size cells. Maybe we want a 'simple-bus'
node for each BAR. The FPGA series needs the same things, but that
aspect hasn't really been addressed as the first issue is populating
the PCI devices dynamically.
The DT address translation code should support all this
(MMIO->PCI->MMIO), but I don't think there's any existing examples. An
example (that I can test) would be great. If the unittest had that
example, I'd be thrilled.
Rob
next prev parent reply other threads:[~2023-01-23 16:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 14:32 [PATCH] mfd: Add Simple PCI MFD driver Vincent Whitchurch
2023-01-23 15:32 ` Lee Jones
2023-01-23 16:02 ` Vincent Whitchurch
2023-01-23 16:36 ` Rob Herring [this message]
2023-01-24 2:30 ` Lizhi Hou
2023-01-24 13:15 ` Vincent Whitchurch
2023-01-23 16:31 ` Greg Kroah-Hartman
2023-01-25 10:15 ` Vincent Whitchurch
2023-01-25 12:29 ` Greg Kroah-Hartman
2023-01-25 13:06 ` Vincent Whitchurch
2023-01-25 13:34 ` Greg Kroah-Hartman
2023-01-25 14:54 ` Rob Herring
2023-01-25 15:00 ` Greg Kroah-Hartman
2023-01-25 15:34 ` Rob Herring
2023-01-31 15:07 ` Greg Kroah-Hartman
2023-01-23 16:13 ` Rob Herring
2023-01-24 12:54 ` Vincent Whitchurch
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=CAL_JsqLHi_1QJ4s28uM1b_Z2f+Nsu_CusAsqsx6vVOCCAPLMgw@mail.gmail.com \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@axis.com \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lizhi.hou@amd.com \
--cc=vincent.whitchurch@axis.com \
/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).