[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <1415099366.7941.16.camel@AMDC1943>
Date: Tue, 04 Nov 2014 12:09:26 +0100
From: Krzysztof Kozlowski <k.kozlowski@...sung.com>
To: Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Cc: Mark Brown <broonie@...nel.org>,
Kukjin Kim <kgene.kim@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Olof Johansson <olof@...om.net>,
Chris Zhong <zyw@...k-chips.com>,
Abhilash Kesavan <kesavan.abhilash@...il.com>,
linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v4 02/14] regulator: Add function to map modes to struct
regulator_desc
On wto, 2014-11-04 at 12:02 +0100, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> Thanks a for your feedback.
>
> On 11/04/2014 11:31 AM, Krzysztof Kozlowski wrote:
> >> + *
> >> + * @map_modes: Callback invoked to translate between hardware to standard modes.
> >
> > Initially I thought it should map from standard to hardware. But then I
> > looked at max77802 implementation and it maps from hardware to standard.
> > Anyway I got confused (both are "modes" and both unsigned ints).
> >
> > Could you describe which should be returned?
> >
>
> Sure, maybe rewording to:
>
> "Callback invoked to translate from hardware to standard modes." ?
>
> But I'll add also document that the parameter should be a hardware
> mode and the return value a standard mode.
Great!
>
> >> */
> >> struct regulator_desc {
> >> const char *name;
> >> @@ -285,6 +287,8 @@ struct regulator_desc {
> >> unsigned int enable_time;
> >>
> >> unsigned int off_on_delay;
> >> +
> >> + unsigned int (*map_modes)(unsigned int mode);
> >
> > Shouldn't this be in regulator ops?
> >
>
> regulator ops are for the operations that a regulator support
> (enable, disable, set mode, etc). All the thse are actions but
> how to translate between hardware and standard modes is not an
> action but a non-varying configuration of the regulator.
>
> So I believe that regulator desc was what fit the most. I don't
> have a strong opinion though if people think that it should be
> in regulator ops instead.
I understand, it's fine for me.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists