Hi, On Fri, Jun 14, 2019 at 07:37:49AM -0600, Rob Herring wrote: > > > 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. Great, I'll post that. > > 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? You mean in the DTS? It shouldn't matter, we'll want to have a warning anyway. But yeah, I'll update them too. Maxme -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
