On Fri, Jun 14, 2019 at 3:50 AM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > > Hi Rob, > > On Thu, Jun 13, 2019 at 11:32:30AM -0600, Rob Herring wrote: > > On Thu, Jun 13, 2019 at 7:25 AM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > > > On Mon, Jun 10, 2019 at 12:59:29PM -0600, Rob Herring wrote: > > > > On Mon, Jun 10, 2019 at 8:31 AM Andrew Lunn <andrew@xxxxxxx> wrote: > > > > > > > > > > > +required: > > > > > > + - compatible > > > > > > + - reg > > > > > > + - interrupts > > > > > > + - clocks > > > > > > + - phy > > > > > > + - allwinner,sram > > > > > > > > > > Quoting ethernet.txt: > > > > > > > > > > - phy: the same as "phy-handle" property, not recommended for new bindings. > > > > > > > > > > - phy-handle: phandle, specifies a reference to a node representing a PHY > > > > > device; this property is described in the Devicetree Specification and so > > > > > preferred; > > > > > > > > > > Can this be expressed in Yaml? Accept phy, but give a warning. Accept > > > > > phy-handle without a warning? Enforce that one or the other is > > > > > present? > > > > > > > > The common schema could have 'phy: false'. This works as long as we've > > > > updated (or plan to) all the dts files to use phy-handle. The issue is > > > > how far back do you need kernels to work with newer dtbs. > > > > > > I guess another question being raised by this is how hard do we want > > > to be a deprecating things, and should the DT validation be a tool to > > > enforce that validation. > > > > > > For example, you've used in you GPIO meta-schema false for anything > > > ending with -gpio, since it's deprecated. This means that we can't > > > convert any binding using a deprecated property without introducing a > > > build error in the schemas, which in turn means that you'll have a lot > > > of friction to support schemas, since you would have to convert your > > > driver to support the new way of doing things, before being able to > > > have a schema for your binding. > > > > I've err'ed on the stricter side. We may need to back off on some > > things to get to warning free builds. Really, I'd like to have levels > > to separate checks for existing bindings, new bindings, and pedantic > > checks. > > That would be awesome. Do you have a plan for that already though? I > can't really think of a way to implement it at the moment. The only idea I have so far is some sort of 'level' property and then we filter schema based on what level we run validation at. I'm not too sure if that would take some restructuring of schema though because it's all a mixture ATM. The other aspect is how to set the 'level' per platform so new platforms have to pass a higher level. We already have that problem just with dtc warnings. Ideally, we should build new platforms with 'W=1' or 'W=12'. Maybe the soc/board schema's can specify the level. > > For '-gpio', we may be okay because the suffix is handled in the GPIO > > core. It should be safe to update the binding to use the preferred > > form. > > It might require a bit of work though in drivers, since the fallback > is only handled if you're using the gpiod API, and not the legacy one. > > > > And then, we need to agree on how to express the deprecation. I guess > > > we could allow the deprecated keyword that will be there in the > > > draft-8, instead of ad-hoc solutions? > > > > Oh, nice! I hadn't seen that. Seems like we should use that. We can > > start even without draft-8 support because unknown keywords are > > ignored (though we probably have to add it to our meta-schema). Then > > at some point we can add a 'disallow deprecated' flag to the tool. > > So, in the generic ethernet binding, we would have: > > properties: > phy-handle: > $ref: /schemas/types.yaml#definitions/phandle > description: > Specifies a reference to a node representing a PHY device. > > phy: > $ref: "#/properties/phy-handle" > deprecated: true > > phy-device: > $ref: "#/properties/phy-handle" > deprecated: true > > Does that sound good? Yes. > Now, how do we handle the case above, in the device specific binding? > We just require the non-deprecated one, or the three? Wouldn't that just depend if all the instances of the device specific binding have been updated? Rob
