On Tue, Mar 08, 2016 at 05:48:07PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 3/8/2016 11:35 AM, Petr Kulhavy wrote:
>
> >>>>>@@ -544,17 +643,25 @@ static int da8xx_probe(struct platform_device *pdev)
> >>>>> pinfo.data = pdata;
> >>>>> pinfo.size_data = sizeof(*pdata);
> >>>>>
> >>>>>+ ret = regulator_enable(glue->vbus_supply);
> >>>>
> >>>> What does this achieve with a regulator that can't be explicitly
> >>>>controlled?
> >>>
> >>>If this is a _real_ regulator, then it needs to be enabled by somebody,
> >>>doesn't it?
> >>
> >> Well, it's possible that Vbus is controlled via GPIO like on DaVinci
> >>DM644x. But so far we haven't seen this on DA8xx...
> >>
> >>>No, as you can see just a few lines above in the patch.
> >>
> >> I'm seeing exactly opposite -- you're enabling the regulator right before
> >>registering the platform device, so after registering generic PHY. It's
> >>therefore not at all clear why you've exchanged the calls above. I can't ACK
> >>this patch.
> >>
> >You are right. I'm wondering that this might be anyway incorrect, since the
> >Vbus should be provided in host mode only.
>
> And there's musb_platform_ops::set_vbus() method for that. The
> regulator should be enabled/disabled there (if at all).
>
> >We're back at the issue of the missing PHY.
>
> Missing PHY driver, you mean?
>
> >And on DA8xx the Vbus is (supposed to be) controlled via the DRVVBUS pin. So
> >it's probably better to not to touch the regulator at all, what do you think?
>
> Yes, enabling it in the probe doesn't make much sense indeed.
Well, first of all, I never used regulator framework, and haven't looked
how to use it in a driver. So my following comments might be wrong.
The problem we are trying to solve is how pass the previous 'mentor,power' value
to musb driver, so how to use the regulator to control vbus is irrelevant
and unnecessary. So if we could set the 500mA value to a property of a
regulator in DT, then read it back in musb driver at the same place
currently reading 'mentor,power', it is done.
Regards,
-Bin.
>
> >>>>[...]
> >>>>>@@ -582,11 +690,20 @@ static int da8xx_remove(struct platform_device *pdev)
> >>>>> return 0;
> >>>>> }
> >>>>>
> >>>>>+static const struct of_device_id da8xx_id_table[] = {
> >>>>>+ {
> >>>>>+ .compatible = "ti,da830-musb",
> >>>>>+ },
> >>>>>+ {},
> >>>>>+};
> >>>>>+MODULE_DEVICE_TABLE(of, da8xx_id_table);
> >>>>>+
> >>>>> static struct platform_driver da8xx_driver = {
> >>>>> .probe = da8xx_probe,
> >>>>> .remove = da8xx_remove,
> >>>>> .driver = {
> >>>>> .name = "musb-da8xx",
> >>>>>+ .of_match_table = of_match_ptr(da8xx_id_table),
> >>>>
> >>>> Doesn't this cause a warning about in non-DT case?
> >>>>
> >>>No, the of_match_table is defined independent of the CONFIG_OF.
> >>
> >> But of_match_ptr() depends on it, IIRC.
> >
> >In include/linux/of.h I do see:
> >
> >#ifdef (CONFIG_OF)
> >[...]
> >
> >#defineof_match_ptr
> ><http://lxr.free-electrons.com/ident?i=of_match_ptr>(_ptr) (_ptr)
> >
> >[...]
> >#else
> >[...]
> >
> >#defineof_match_ptr
> ><http://lxr.free-electrons.com/ident?i=of_match_ptr>(_ptr)NULL
> ><http://lxr.free-electrons.com/ident?i=NULL>
> >[...]
> >#endif
>
> Yes, I was wondering if the warning about da8xx_id_table[] being
> unused was generated when CONFIG_OF=n.
>
> >Regards
> >Petr
>
> MBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
