devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Rob Herring <robh@kernel.org>
Cc: Lizhi Hou <lizhi.hou@amd.com>, 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: Tue, 24 Jan 2023 14:15:11 +0100	[thread overview]
Message-ID: <Y8/Z3+clVN4MbH/i@axis.com> (raw)
In-Reply-To: <CAL_JsqLHi_1QJ4s28uM1b_Z2f+Nsu_CusAsqsx6vVOCCAPLMgw@mail.gmail.com>

On Mon, Jan 23, 2023 at 05:36:06PM +0100, Rob Herring wrote:
> On Mon, Jan 23, 2023 at 10:02 AM Vincent Whitchurch
> <vincent.whitchurch@axis.com> wrote:
> dtc should complain about this...

It probably does, the test framework currently doesn't report these to
the test runner/writer; maybe it should.

> >         compatible = "virtio,uml";
> 
> Binding?

There was some discussion earlier about whether a binding was needed
here (you were on CC):

 https://lore.kernel.org/lkml/20211222103417.GB25135@axis.com/

> 
> >         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.

I think it's there since I based this tree off from
arch/x86/platform/ce4100/falconfalls.dts.  I see that there is some code
in arch/x86/kernel/devicetree.c to handle this compatible and register
all platform devices under that.  Do we need something like that for UML
instead of this patch?

> 
> >                 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.

Yes, this ranges stuff can be fixed in the Python code which generates
these trees.

In my cases the devicetree blob contains all the devices under the PCI
devices, see my other email.

> 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.

Anyone can run what I'm running since it uses UML and there is no real
hardware, but the setup is a bit more complicated than an in-kernel
unit test since there is a virtio backend in userspace which implements
the "hardware".  If you want to try it:

 git remote add vwax https://github.com/vwax/linux.git
 git fetch vwax
 git checkout vmax/roadtest/platform-wip
 make -C tools/testing/roadtest/ -j24 OPTS="-v -k platform"

You should see a "PASSED roadtest/tests/base/test_platform.py::test_foo"
if it works.  See Documentation/dev-tools/roadtest.rst for more info.
As mentioned in the other email, the only patches to the kernel proper
in that tree are already posted ones and WIP fixes.

  parent reply	other threads:[~2023-01-24 13:15 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
2023-01-24  2:30       ` Lizhi Hou
2023-01-24 13:15       ` Vincent Whitchurch [this message]
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=Y8/Z3+clVN4MbH/i@axis.com \
    --to=vincent.whitchurch@axis.com \
    --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=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 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).