On Mon, Feb 29, 2016 at 3:20 AM, Petr Kulhavy <petr@xxxxxxxxx> wrote: > > > On 26.02.2016 15:23, Bin Liu wrote: >> >> Hi, >> >> On Fri, Feb 26, 2016 at 10:29:12AM +0100, Petr Kulhavy wrote: >>> >>> On 26.02.2016 04:15, Bin Liu wrote: >>>> >>>> On Thu, Feb 25, 2016 at 01:04:13PM +0100, Petr Kulhavy wrote: >>>> >>>>> Well, so we're still at the same point - there is a fundamental >>>>> mismatch in the different developers' view how the "power" parameter >>>>> should be represented. >>>>> There already 3 opinions at the moment: >>>>> 1) hard code - Felipe, Rob >>>>> 2) use the "mentor,power" - Sergei, Petr >>>>> 3) use a regulator - Rob >>>>> >>>>> So unless this conflict is resolved it is slightly difficult to >>>>> submit a patch that would get accepted. >>>>> How can we resolve this conflict ? >>>> >>>> This power property is used by core to control the hub port power >>>> budget, which is sourced by vbus. But vbus is not coming from musb, but >>>> a board power rail. So hardcode it does not make sense. >>>> >>>> Regards, >>>> -Bin. >>> >>> So what would be your take then? >> >> Don't hardcode in 5/5, and drop musb_get_power() in this patch. > > > Hi Bin, > > I will drop the musb_get_power and use the "mentor,power" property. > However Rob is not willing to accept that, he's insisting on a regulator. I believe I said setting it in the driver is fine as the list above says. If you have 10 boards and 10 different current limits, then yes it should be in DT (as a regulator). Rob -- 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
