On Tue, Oct 07, 2025 at 08:24:06AM +0300, Svyatoslav Ryhel wrote: > вт, 7 жовт. 2025 р. о 01:13 Rob Herring <[email protected]> пише: > > > > On Thu, Oct 02, 2025 at 02:35:42PM -0700, Doug Anderson wrote: > > > Hi, > > > > > > On Mon, Sep 29, 2025 at 10:03 PM Svyatoslav Ryhel <[email protected]> > > > wrote: > > > > > > > > вт, 30 вер. 2025 р. о 06:12 Doug Anderson <[email protected]> пише: > > > > > > > > > > Hi, > > > > > > > > > > On Mon, Sep 29, 2025 at 7:25 AM Svyatoslav Ryhel <[email protected]> > > > > > wrote: > > > > > > > > > > > > LG LD070WX3-SL01 was mistakenly documented as a simple DSI panel, > > > > > > which it > > > > > > clearly is not. Address this by adding the proper schema for this > > > > > > panel. > > > > > > > > > > > > Signed-off-by: Svyatoslav Ryhel <[email protected]> > > > > > > --- > > > > > > .../bindings/display/panel/lg,ld070wx3.yaml | 60 > > > > > > +++++++++++++++++++ > > > > > > .../display/panel/panel-simple-dsi.yaml | 2 - > > > > > > 2 files changed, 60 insertions(+), 2 deletions(-) > > > > > > create mode 100644 > > > > > > Documentation/devicetree/bindings/display/panel/lg,ld070wx3.yaml > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/display/panel/lg,ld070wx3.yaml > > > > > > b/Documentation/devicetree/bindings/display/panel/lg,ld070wx3.yaml > > > > > > new file mode 100644 > > > > > > index 000000000000..0a82cf311452 > > > > > > --- /dev/null > > > > > > +++ > > > > > > b/Documentation/devicetree/bindings/display/panel/lg,ld070wx3.yaml > > > > > > @@ -0,0 +1,60 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: http://devicetree.org/schemas/display/panel/lg,ld070wx3.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: LG Corporation 7" WXGA TFT LCD panel > > > > > > + > > > > > > +maintainers: > > > > > > + - Svyatoslav Ryhel <[email protected]> > > > > > > + > > > > > > +allOf: > > > > > > + - $ref: panel-common.yaml# > > > > > > + > > > > > > +properties: > > > > > > + compatible: > > > > > > + items: > > > > > > + - const: lg,ld070wx3-sl01 > > > > > > + > > > > > > + reg: > > > > > > + maxItems: 1 > > > > > > + > > > > > > + vdd-supply: true > > > > > > + vcc-supply: true > > > > > > + > > > > > > + backlight: true > > > > > > + port: true > > > > > > + > > > > > > +required: > > > > > > + - compatible > > > > > > + - vdd-supply > > > > > > + - vcc-supply > > > > > > > > > > I suspect you'll get a NAK here because you're not preserving backward > > > > > compatibility for existing device trees. While there can sometimes be > > > > > reasons to do that, you'd need to provide a very strong justification. > > > > > > > > > > > > > > > It seems like instead of breaking compatibility you could just have > > > > > two supplies: > > > > > > > > > > * power-supply - The name for the "dvdd" supply. > > > > > * avdd-supply - The name for the "avdd" supply. > > > > > > > > > > ...and then you make both of them not "required". Maybe you'd add some > > > > > documentation saying that things might not work 100% correctly if they > > > > > weren't provided but that old device trees didn't specify them? > > > > > > > > Schema describes hardware. If it does not (and in this case it clearly > > > > DOES NOT), then such schema should be adjusted according to hardware. > > > > The priority is: > > > > 1) ABI > > 2) describe h/w accurately > > > > IMO, if there are 2 rails on the h/w and you have 2 supplies in the DT, > > then you have described the h/w. names are less important. > > > > > > If there are any users of such binding, they should be adjusted too > > > > (third commit of this patchset does exactly that). Panel datasheet is > > > > explicit, panel has ONLY vdd supply and vcc supply, names are taken > > > > from there too. > > > > > > I'm more than happy to defer to DT people on this, but the general > > > argument is that "device tree" is supposed to remain forever forward > > > compatible. In other words, someone could have taken a snapshot of the > > > "tegra114-tn7.dts" device tree at any point in time and then shipped > > > it in some BIOS. Presumably the old "tegra114-tn7.dts" (for some > > > reason) managed to init the panel properly in the past and the idea is > > > that there should still be a way to init the panel with the old device > > > tree now. > > > > > > Obviously, that's an ideal version of the world and sometimes > > > hard/impossible to make a reality, but it's supposed to be what we > > > strive for. > > > > > > >From a more practical standpoint, the dts changes and code changes > > > will go through different trees and so making them mutually depend on > > > each other can leave people broken if they happen to have one patch > > > but not the other. > > > > > > I suppose one way to handle this (if DT people like it) is to keep the > > > bindings the way you have it but then add some layer of backward > > > compatibility in the driver. It will mean that anyone with the old DTS > > > would officially not "validate" properly against the new bindings, but > > > I think that could be OK as long as it was explicitly mentioned in the > > > commit message. Obviously, though, DT bindings reviewers would have > > > the last word there... > > > > That's fine, but then I prefer we keep 'power-supply' as deprecated. > > Then if we ever validate that drivers only use documented properties, > > it would pass. We already check drivers use documented compatible > > strings, so that wouldn't be too hard to do. > > > > Sure, but ATM there is only one user of this compatible in the > mainline Linux kernel, which is Nvidia tablet Tegra Note 7 and: > > 1. Node used in its tree is addressed in the third commit of this patchset > 2. Its panel is broken anyway since it cannot init properly if > bootloader does not leave a pre-inited panel, it cannot suspend > properly and it has a loose regulator which relies on always-on > property rather then being hooked to the panel.
Then put all this justification in the commit message. > I can assure you that besides me there seems to be no one interested > in this tablet. Okay, then it is on you if anyone does care. Rob
