On Tue, 20 Jan 2015, Krzysztof Kozlowski wrote:
> On wto, 2015-01-20 at 15:51 +0000, Lee Jones wrote:
> > On Tue, 20 Jan 2015, Krzysztof Kozlowski wrote:
> >
> > > On wto, 2015-01-20 at 13:36 +0000, Lee Jones wrote:
> > > > On Mon, 05 Jan 2015, Krzysztof Kozlowski wrote:
> > > >
> > > > > Replace direct calls to power supply function attributes with wrappers.
> > > > > Wrappers provide safe access in case of unregistering the power
> > > > > supply (e.g. by removing the driver). Replace:
> > > > > - get_property -> power_supply_get_property
> > > > >
> > > > > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@xxxxxxxxxxx>
> > > > > Acked-by: Jonghwa Lee <jonghwa3.lee@xxxxxxxxxxx>
> > > > > Acked-by: Pavel Machek <pavel@xxxxxx>
> > > > > Acked-by: Lee Jones <lee.jones@xxxxxxxxxx>
> > > >
> > > > You've sent this to me already Acked. I don't see 00/00, so I have no
> > > > idea what's going on. Do you want me to take this patch? Can it be
> > > > taking on its own?
> > >
> > > git send-email automatically CC-you because you acked this. The depends
> > > on previous patches adding this API so please do not pick it up.
> >
> > You should always send MFD related patches to me (either
> > automatically, or manually).
> >
> > > Everything (with respective acks) should go through one power supply
> > > tree.
> >
> > That's not how it works. We need to decide that amongst ourselves
> > and it needs to culminate in pull-requests being sent out to all of
> > the effected Maintainers.
>
> OK, I understand. My reply sounded kind a imperative but that was not
> what I wanted to say...
It did, hence my response. Thanks for the clarification.
> The patchset adds some API first so most of
> patches cannot be picked independently.
I appreciate that and I'm happy for the patches to go in via whichever
tree is the most appropriate.
> Thank you for proactive concern about the patch.
You are welcome.
> So go ahead and decide. If the patches are ok, I see no problem in it
> going through power supply tree, and neither should you. I feel you
> are making it more complex than it is.
I think you are missing the point -- Krzysztof got it. It's probably
okay for some patches from one subsystem to go in via another, but
it's usually prudent to at least tag them and offer others the chance
of pulling them in to other trees. This significantly aids in
lessening the chances of a merge conflict during the merge-window and
mitigates the possibility of an upset Linus.
As I've already said, I'm happy for this set to go in via the Power
Supply tree, but assumptions shouldn't be made and all affected
Maintainers should at least have a vote in cases like this.
> > > The same applies to patch 18/19.
> > >
> > > Best regards,
> > > Krzysztof
> > >
> > > >
> > > > > ---
> > > > > drivers/mfd/ab8500-sysctrl.c | 7 ++++---
> > > > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
> > > > > index cfff0b643f1b..d4a4b24be7c6 100644
> > > > > --- a/drivers/mfd/ab8500-sysctrl.c
> > > > > +++ b/drivers/mfd/ab8500-sysctrl.c
> > > > > @@ -49,7 +49,8 @@ static void ab8500_power_off(void)
> > > > > if (!psy)
> > > > > continue;
> > > > >
> > > > > - ret = psy->get_property(psy, POWER_SUPPLY_PROP_ONLINE, &val);
> > > > > + ret = power_supply_get_property(psy, POWER_SUPPLY_PROP_ONLINE,
> > > > > + &val);
> > > > >
> > > > > if (!ret && val.intval) {
> > > > > charger_present = true;
> > > > > @@ -63,8 +64,8 @@ static void ab8500_power_off(void)
> > > > > /* Check if battery is known */
> > > > > psy = power_supply_get_by_name("ab8500_btemp");
> > > > > if (psy) {
> > > > > - ret = psy->get_property(psy, POWER_SUPPLY_PROP_TECHNOLOGY,
> > > > > - &val);
> > > > > + ret = power_supply_get_property(psy,
> > > > > + POWER_SUPPLY_PROP_TECHNOLOGY, &val);
> > > > > if (!ret && val.intval != POWER_SUPPLY_TECHNOLOGY_UNKNOWN) {
> > > > > printk(KERN_INFO
> > > > > "Charger \"%s\" is connected with known battery."
> > > >
> > >
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
