Thread (22 messages) 22 messages, 5 authors, 2022-02-18

Re: [PATCH dt + pci 1/2] dt-bindings: Add 'slot-power-limit-milliwatt' PCIe port property

From: Rob Herring <robh@kernel.org>
Date: 2021-11-12 20:56:40
Also in: linux-pci

On Fri, Nov 12, 2021 at 11:12 AM Pali Rohár [off-list ref] wrote:
On Friday 12 November 2021 10:30:01 Rob Herring wrote:
quoted
On Fri, Nov 12, 2021 at 9:32 AM Pali Rohár [off-list ref] wrote:
quoted
On Friday 12 November 2021 09:25:20 Rob Herring wrote:
quoted
On Sun, Oct 31, 2021 at 04:07:05PM +0100, Marek Behún wrote:
quoted
+   If present, this property specifies slot power limit in milliwatts. Host
+   drivers can parse this property and use it for programming Root Port or host
+   bridge, or for composing and sending PCIe Set_Slot_Power_Limit messages
+   through the Root Port or host bridge when transitioning PCIe link from a
+   non-DL_Up Status to a DL_Up Status.
If your slots are behind a switch, then doesn't this apply to any bridge
port?
The main issue here is that pci.txt (and also scheme on github) is
mixing host bridge and root ports into one node. This new property
should be defined at the same place where is supports-clkreq or
reset-gpios, as it belongs to them.
Unfortunately that ship has already sailed. So we can split things up,
but we still have to allow for the existing cases. I'm happy to take
changes splitting up pci-bus.yaml to 2 or 3 schemas (host bridge,
root-port, and PCI(e)-PCI(e) bridge?).
Well, no problem. I just need to know how you want to handle backward
compatibility definitions in YAML. Because it is possible via versioning
(like in JSONSchema-like structures in OpenAPI versioning) or via
Got a pointer to that?
deprecated attributes or via defining two schemas (one strict and one
loose)... There are lot of options and I saw all these options in
different projects which use YAML or JSON.
The short answer is we don't have a defined way beyond deprecating
properties within a given binding with 'deprecated: true'. The only
versioning we have ATM is the kernel requires a minimum version of
dtschema (which we'll have to bump for all this).

We could have something like:

old-pci-bridge.yaml:
  allOf:
    - $ref: pci-host-bridge.yaml#
    - $ref: pcie-port.yaml#

new-pci-bridge.yaml:
  allOf:
    - $ref: pci-host-bridge.yaml#
  properties:
    pci@0:
      $ref: pcie-port.yaml#

And then both of the above schemas will have $ref to a pci-bridge.yaml
schema which should be most of pci-bus.yaml. linux,pci-domain and
dma-ranges? go to pci-host-bridge.yaml. max-link-speed, num-lanes,
reset-gpios, slot-power-limit-milliwatt, and the pending supply
additions (Broadcom) go to pcie-port.yaml.
I did not know about github repository, I always looked at schemas and
definitions only in linux kernel tree and external files which were
mentioned in kernel tree.

Something I wrote in my RFC email, but I wrote this email patch...
https://lore.kernel.org/linux-pci/20211023144252.z7ou2l2tvm6cvtf7@pali/ (local)
I think we're pretty much in alignment. Look at the Broadcom portdrv
changes proposed if you haven't already. It's all interrelated.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help