On Wed, Sep 09, 2020 at 11:48:21PM -0700, Stephen Boyd wrote: > Quoting Stephen Boyd (2020-09-09 17:48:53) > > This binding only describes the USB phy inside the USB3 + DP "combo" > > phy. Add information for the DP phy and describe the sub-nodes that > > represent the DP and USB3 phys that exist inside the combo wrapper. > > Remove reg-names from required properties because it isn't required nor > > used by the kernel driver. > > > > Cc: Jeykumar Sankaran <[email protected]> > > Cc: Chandan Uddaraju <[email protected]> > > Cc: Vara Reddy <[email protected]> > > Cc: Tanmay Shah <[email protected]> > > Cc: Bjorn Andersson <[email protected]> > > Cc: Manu Gautam <[email protected]> > > Cc: Sandeep Maheswaram <[email protected]> > > Cc: Douglas Anderson <[email protected]> > > Cc: Sean Paul <[email protected]> > > Cc: Jonathan Marek <[email protected]> > > Cc: Dmitry Baryshkov <[email protected]> > > Cc: <[email protected]> > > Cc: Rob Herring <[email protected]> > > Cc: Rob Clark <[email protected]> > > Signed-off-by: Stephen Boyd <[email protected]> > > --- > > .../bindings/phy/qcom,qmp-usb3-dp-phy.yaml | 91 +++++++++++++++++-- > > 1 file changed, 81 insertions(+), 10 deletions(-) > > I noticed that I didn't document the new compatible string I'm using, > qcom,sc7180-qmp-usb3-dp-phy, ugh. > > Should I copy the whole file over and make a new document for the new > compatible string? That feels like the better solution vs. making this > binding have min/max stuff where it fails to enforce the DP part of the > phy. We can delete this binding once the kernel tree isn't using it, > right?
It generally depends on how much if/then schema you have (or should have) vs. how much is common, but it's a judgement call. It looks like you are just extending the binding for the most part. If there's dtb warnings until the existing stuff gets updated, that's fine. Rob
