On Thu, Aug 29, 2024 at 11:26 AM Andrea della Porta
[off-list ref] wrote:

Hi Rob,

On 08:18 Thu 29 Aug     , Rob Herring wrote:

quoted

On Thu, Aug 29, 2024 at 5:13 AM Andrea della Porta
[off-list ref] wrote:

quoted

Hi Rob,

BTW, I noticed your email replies set "reply-to" to everyone in To and
Cc. The result (with Gmail) is my reply lists everyone twice (in both
To and Cc). "reply-to" is just supposed to be the 1 address you want
replies sent to instead of the "from" address.

IIUC you're probably referring to Mail-Reply-To, that address only one recipient
at a time (i.e. you want to reply only to the author). Reply-To is a catch-all
that will work as a fallback when you hit either reply or reply-all in your client.
In fact, neither Reply-To nor Mail-Reply-To are included in my emails, the
interesting one being Mail-Followup-To, that should override any of the above
mentioned headers (including To: and Cc:) for the reply all function. How these
headers are interpreted depends solely on the mail client, I'm afraid.
Is it possible that your client is mistakenly merging both Mail-Followup-To
plus To and Cc lists?

Indeed, the UI displays 'reply-to' but the source shows
Mail-Followup-To which I'd never heard of. From reading up on it, I
agree the client, Gmail web interface, handles it incorrectly. Not
really anything I can do to fix Gmail though...

Anyway, I've disabled Mail-followup-To as it's added by mutt, can you please
confirm that this mail now works for you? Hopefully it will not clobber the
recipent list too much, since AFAIK that header was purposely invented to avoid
such inconsistencies.

Seems fine now.

My brief read of the header is it is to avoid receiving multiple
copies depending if you are subscribed to a list or not. But listing
out every other address except your own seems like an odd way to
implement "omit From" in replies. You're still going to get N copies
from N lists as well. I guess it made some sense to some people...

quoted

quoted

On 16:29 Mon 26 Aug     , Rob Herring wrote:

quoted

On Wed, Aug 21, 2024 at 3:19 AM Andrea della Porta
[off-list ref] wrote:

quoted

Hi Rob,

On 19:16 Tue 20 Aug     , Rob Herring wrote:

quoted

On Tue, Aug 20, 2024 at 04:36:06PM +0200, Andrea della Porta wrote:

quoted

A missing or empty dma-ranges in a DT node implies a 1:1 mapping for dma
translations. In this specific case, rhe current behaviour is to zero out

typo

Fixed, thanks!

quoted

quoted

the entire specifier so that the translation could be carried on as an
offset from zero.  This includes address specifier that has flags (e.g.
PCI ranges).
Once the flags portion has been zeroed, the translation chain is broken
since the mapping functions will check the upcoming address specifier

What does "upcoming address" mean?

Sorry for the confusion, this means "address specifier (with valid flags) fed
to the translating functions and for which we are looking for a translation".
While this address has some valid flags set, it will fail the translation step
since the ranges it is matched against have flags zeroed out by the 1:1 mapping
condition.

quoted

quoted

against mismatching flags, always failing the 1:1 mapping and its entire
purpose of always succeeding.
Set to zero only the address portion while passing the flags through.

Can you point me to what the failing DT looks like. I'm puzzled how
things would have worked for anyone.

The following is a simplified and lightly edited) version of the resulting DT
from RPi5:

 pci@0,0 {
        #address-cells = <0x03>;
        #size-cells = <0x02>;
        ......
        device_type = "pci";
        compatible = "pci14e4,2712\0pciclass,060400\0pciclass,0604";
        ranges = <0x82000000 0x00 0x00   0x82000000 0x00 0x00   0x00 0x600000>;
        reg = <0x00 0x00 0x00   0x00 0x00>;

        ......

        rp1@0 {

What does 0 represent here? There's no 0 address in 'ranges' below.
Since you said the parent is a PCI-PCI bridge, then the unit-address
would have to be the PCI devfn and you are missing 'reg' (or omitted
it).

There's no reg property because the registers for RP1 are addressed
starting at 0x40108000 offset from BAR1. The devicetree specs says
that a missing reg node should not have any unit address specified
(and AFAIK there's no other special directives for simple-bus specified
in dt-bindings).
I've added @0 just to get rid of the following warning:

 Warning (unit_address_vs_reg): /fragment@0/__overlay__/rp1: node has
 a reg or ranges property, but no unit name

It's still wrong as dtc only checks the unit-address is correct in a
few cases with known bus types.

Sorry, I don't follow you on this, I'm probably missing something. Could
you please add some details?

dtc only checks unit-address matches reg/ranges for simple-bus, pci,
i2c, and spi. Since this case is none of them, there is no warning and
it is left to reviewers to check. The warnings are often a clue
something is wrong and the easy fix is often not the right one. This
is still an area the tooling needs improvements on.

quoted

quoted

coming from make W=1 CHECK_DTBS=y broadcom/rp1.dtbo.
This is the exact same approach used by Bootlin patchset from:

https://lore.kernel.org/all/20240808154658.247873-2-herve.codina@bootlin.com/ (local)

It is not. First, that has a node for the PCI device (i.e. the
LAN966x). You do not. You only have a PCI-PCI bridge and that is
wrong.

I'm a little confused now, but I think the confusion is generated by
the label node names I've chosen that are, admittedly, a bit sloppy.
I'll try to make some clarity, please see below.

quoted

BTW, you should Cc Herve and others that are working on this feature.
It is by no means fully sorted as you have found.

Sure, just added, thanks for the heads up.

quoted

quoted

replied here below for convenience:

+       pci-ep-bus@0 {
+               compatible = "simple-bus";
+               #address-cells = <1>;
+               #size-cells = <1>;
+
+               /*
+                * map @0xe2000000 (32MB) to BAR0 (CPU)
+                * map @0xe0000000 (16MB) to BAR1 (AMBA)
+                */
+               ranges = <0xe2000000 0x00 0x00 0x00 0x2000000

The 0 parent address here matches the unit-address, so all good in this case.

Just to be sure, the parent address being the triple zeros in the ranges property,
right?

Yes.

quoted

quoted

+                         0xe0000000 0x01 0x00 0x00 0x1000000>;

Also, I think it's not possible to know the devfn in advance, since the
DT part is pre-compiled as an overlay while the devfn number is coming from
bus enumeration.

No. devfn is fixed unless you are plugging in a card in different
slots. The bus number is the part that is not known and assigned by
the OS, but you'll notice that is omitted.

In any case, the RP1 node should be generated, so its devfn is irrelevant.

Which is a possibility, since the driver should possibly work also with RP1
mounted on a PCI card, one day. But as you pointed out, since this is automatically
generated, should not be a concern.

quoted

quoted

Since the registers for sub-peripherals will start (as stated in ranges
property) from 0xc040000000, I'd be inclined to use rp1@c040000000 as the
node name and address unit. Is it feasible?

Yes, but that would be in nodes underneath ranges. Above, it is the
parent bus we are talking about.

Right.

quoted

quoted

quoted

quoted

                #address-cells = <0x02>;
                #size-cells = <0x02>;
                compatible = "simple-bus";

The parent is a PCI-PCI bridge. Child nodes have to be PCI devices and
"simple-bus" is not a PCI device.

The simple-bus is needed to automatically traverse and create platform
devices in of_platform_populate(). It's true that RP1 is a PCI device,
but sub-peripherals of RP1 are platform devices so I guess this is
unavoidable right now.

You are missing the point. A PCI-PCI bridge does not have a
simple-bus. However, I think it's just what you pasted here that's
wrong. From the looks of the RP1 driver and the overlay, it should be
correct.

Trying to clarify: at first I thought of my rp1 node (in the dtso) as the pci
endpoint device, but I now see that it should be intended as just the bus
attached to the real endpoint device (which is the dynamically generated dev@0,0).
In this sense, rp1 is probably a really wrong name, let's say we use the same
name from Bootlin, i.e. pci-ep-bus. The DT tree would then be:

pci@0,0         <- auto generated, this represent the pci bridge

Or root port specifically.

  dev@0,0       <- auto generated, this represent the pci ednpoint device, a.k.a. the RP1
    pci-ep-bus  <- added from dtbo, this is the simple-bus to which peripherals are attached

this view is much like Bootlin's approach, also my pci-ep-bus node now would look
like this:
 ...
 pci-ep-bus@0 {
        ranges = <0xc0 0x40000000
                  0x01 0x00 0x00000000
                  0x00 0x00400000>;
        ...
 };

and also the correct unit address here is 0 again, since the parent address in
ranges is 0x01 0x00 0x00000000 (0x01 is the flags and in this case represent
BAR1, I assume that for the unit address I should use only the address part that
is 0, right?).

No, it should be 1 for BAR1. It's 1 node per BAR.

quoted

It would also help if you dumped out what "lspci -tvnn" prints.

Here it is:

localhost:~ # lspci -tvnn
-[0002:00]---00.0-[01]----00.0  Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge [1de4:0001]

Right, so that matches what you now have above.

quoted

quoted

quoted

The assumption so far with all of this is that you have some specific
PCI device (and therefore a driver). The simple-buses under it are
defined per BAR. Not really certain if that makes sense in all cases,
but since the address assignment is dynamic, it may have to. I'm also
not completely convinced we should reuse 'simple-bus' here or define
something specific like 'pci-bar-bus' or something.

Good point. Labeling a new bus for this kind of 'appliance' could be
beneficial to unify the dt overlay approach, and I guess it could be
adopted by the aforementioned Bootlin's Microchip patchset too.
However, since the difference with simple-bus would be basically non
existent, I believe that this could be done in a future patch due to
the fact that the dtbo is contained into the driver itself, so we do
not suffer from the proliferation that happens when dtb are managed
outside.

It's an ABI, so we really need to decide first.

Okay. How should we proceed?

I think simple-bus where you have it is fine. It is really 1 level up
that needs to be specified. Basically something that's referenced from
the specific PCI device's schema (e.g. the RP1 schema (which you are
missing)).

That schema needs to roughly look like this:

properties:
  "#address-cells":
    const: 3
  "#size-cells":
    const: 2
  ranges:
    minItems: 1
    maxItems: 6
    items:
      additionalItems: true
      items:
        - maximum: 5  # The BAR number
        - const: 0
        - const: 0
        - # TODO: valid PCI memory flags

patternProperties:
  "^bar-bus@[0-5]$":
    type: object
    additionalProperties: true
    properties:
      compatible:
        const: simple-bus
      ranges: true

There were some discussions around interrupt handling that might also
factor into this.

Rob