On Friday 12 November 2021 14:56:26 Rob Herring wrote: > On Fri, Nov 12, 2021 at 11:12 AM Pali Rohár <pali@xxxxxxxxxx> wrote: > > > > On Friday 12 November 2021 10:30:01 Rob Herring wrote: > > > On Fri, Nov 12, 2021 at 9:32 AM Pali Rohár <pali@xxxxxxxxxx> wrote: > > > > > > > > On Friday 12 November 2021 09:25:20 Rob Herring wrote: > > > > > On Sun, Oct 31, 2021 at 04:07:05PM +0100, Marek Behún wrote: > > > > > > + 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? I'm not sure which pointer you want. OpenAPI is used for defining application APIs which use either JSON or YAML (or something other) content over HTTP protocol. Specification of OpenAPI is here: https://swagger.io/specification/ Lot of times API schemas are written in YAML format (even when API content is JSON) and OpenAPI uses JSONSchema-like schemas (at least in version 3.0, they are not same as JSONSchema, it is some subset with own extensions) and looks very similar to DT schemas. > > 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'. Is there any formal definition what this 'deprecated: true' means? It throw some warning during validation? Or it is disallowed to use deprecated properties in newly written DTS files? Or it is just a syntax decorator without any semantic meaning? > 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. This looks like a nice solution. I would propose just one other thing: Do not allow new kernel drivers to use old-pci-bridge.yaml schema, so new drivers would not use old "deprecated" APIs... So should I prepare some schemas and send it for review via github pull request mechanism? (I'm not sure how is that github project related to kernel DTS bindings and how is reviewing on it going...) > > 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/ > > I think we're pretty much in alignment. Look at the Broadcom portdrv > changes proposed if you haven't already. It's all interrelated. Do you have link to DTS file, how it looks like in real usage?
