On Mon, 15 Jun 2015 15:41:02 +0800
Li Jun <b47624@xxxxxxxxxxxxx> wrote:
> On Fri, Jun 12, 2015 at 11:31:02AM +0300, Roger Quadros wrote:
> >
> >
> >
> > Agreed. We still need to determine legacy platform if
> > none of the features are set.
> >
> > How about defining the followong enum for gadget->xyz_support
> >
> > enum otg_feature {
> > OTG_FEATURE_UNDEFINED = 0,
> > OTG_FEATURE_ENABLED,
> > OTG_FEATURE_DISABLED,
> > };
> >
> > for legacy platforms this will be UNDEFINED for all so you can detect it
> > and continue legacy behaviour i.e. enable HNP/SRP, disable ADP.
> >
> > For new platforms at least one of them won't be UNDEFINED so you can
> > enable the feature if ENABLED and disable if UNDEFINED/DISABLED.
> >
> > We can still keep disable flags so that users can disable all 3 OTG features
> > while in OTG mode.
> >
> > cheers,
> > -roger
>
> Regarding use of "xyz-disable" flags:
> After more thinking this, I just realize that we can use "otg-rev" property
> to handle the case of none of xyz-disable properties passed, for legacy
> platforms, the new "otg-rev" not passed either, so it's a legacy platform,
> if new platform does support all 3 features(SRP/HNP/ADP), the otg-rev
> should be passed and also should be 2.0 or above, because ADP is
> introduced in OTG 2.0(maybe that's why in current gadget driver, only
> enable SRP/HNP).
>
> So:
> 1) new platform with full otg feature support:
> dr_mode = "otg";
> otg-rev = "0x0200";
>
> 2) legacy platform
> dr_mode = "otg"
>
> Then I think we are okay to use disable flags.
I just agreed that it is ok to use enable flags and then read this mail :)
I like this approach of using otg-rev to decide if OTG capabilities will be
read from DT or not.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
