On Fri, 12 Nov 2021 09:25:20 -0600 Rob Herring <robh@xxxxxxxxxx> wrote: > On Sun, Oct 31, 2021 at 04:07:05PM +0100, Marek Behún wrote: > > From: Pali Rohár <pali@xxxxxxxxxx> > > > > This property specifies slot power limit in mW unit. It is a form-factor > > and board specific value and must be initialized by hardware. > > > > Some PCIe controllers delegate this work to software to allow hardware > > flexibility and therefore this property basically specifies what should > > host bridge program into PCIe Slot Capabilities registers. > > > > The property needs to be specified in mW unit instead of the special format > > defined by Slot Capabilities (which encodes scaling factor or different > > unit). Host drivers should convert the value from mW to needed format. > > > > Signed-off-by: Pali Rohár <pali@xxxxxxxxxx> > > Signed-off-by: Marek Behún <kabel@xxxxxxxxxx> > > --- > > Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt > > index 6a8f2874a24d..7296d599c5ac 100644 > > --- a/Documentation/devicetree/bindings/pci/pci.txt > > +++ b/Documentation/devicetree/bindings/pci/pci.txt > > @@ -32,6 +32,12 @@ driver implementation may support the following properties: > > root port to downstream device and host bridge drivers can do programming > > which depends on CLKREQ signal existence. For example, programming root port > > not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal. > > +- slot-power-limit-miliwatt: > > Typo. > > But we shouldn't be adding to pci.txt. This needs to go in the > schema[1]. Patch to devicetree-spec list or GH PR is fine. Hello Rob, Pali's PR draft https://github.com/devicetree-org/dt-schema/pull/64 looks like it's going to take some time to work out. In the meantime, is it possible to somehow get the slot-power-limit-milliwatt property merged into pci.txt so that we can start putting it into existing device-trees? Or would it break dt_bindings_check if it isn't put into dt-schema's pci-bus.yaml? Or should we simply put it into current version of pci-bus.yaml and work out the split proposed by Pali's PR afterwards? Marek