All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: "Pallala, Ramakrishna" <ramakrishna.pallala@intel.com>
Cc: Mika Westerberg <mika.westerberg@iki.fi>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] smb347_charger: Cleanup power supply registration code in probe
Date: Sat, 5 May 2012 05:51:53 -0700	[thread overview]
Message-ID: <20120505125153.GA31018@lizard> (raw)
In-Reply-To: <D854C92F57B1B347B57E531E78D05EAD10EC08@BGSMSX102.gar.corp.intel.com>

On Fri, Apr 20, 2012 at 03:48:35AM +0000, Pallala, Ramakrishna wrote:
> > Subject: Re: [PATCH v2] smb347_charger: Cleanup power supply registration code in probe
> > 
> > On Thu, Apr 19, 2012 at 10:00:18AM +0530, Ramakrishna Pallala wrote:
> > > This patch checks if the usb or mains charging is enabled by the
> > > platform before registering with the power supply class.
> > 
> > I still don't like the idea of having the power-supplies registered conditionally. Now
> > you need to check in every place whether the corresponding power-supply is registered or
> > not which makes the code uglier and more prone to errors.

Yes, I understand. There's a bit more code in the kernel,
true. But it saves tons of code in userland and makes things
more reliable for the latter.

> These are the reasons behind this patch submission:
> 1. if we don't support USB/AC charging don't enable it, saves
> 	kernel resources and don't give user wrong idea about charging capabilities.
> 2. if a platform driver or any other chip can do USB/AC charging they will register with PS and
> 	user/userspace will not get confused b/w two sysfs interfaces.
> 
> I will leave the decision the Anton.

Well, as I always said, it was somewhat a mistake to introduce
'present' property. It was supposed to be something like 'battery
cells present, if hot-swappable' property.

If the device itself doesn't have a feature (i.e. no USB
socket), you should not register it, otherwise userland
will have to bother detecting actual information (because
the kernel literally lies to the userland if it registers
absent hw features).

So, I'm all for this patch -- it is now applied.

Thank you!

-- 
Anton Vorontsov
Email: cbouatmailru@gmail.com

  reply	other threads:[~2012-05-05 12:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19  4:30 [PATCH v2] smb347_charger: Cleanup power supply registration code in probe Ramakrishna Pallala
2012-04-19 19:08 ` Mika Westerberg
2012-04-20  3:48   ` Pallala, Ramakrishna
2012-05-05 12:51     ` Anton Vorontsov [this message]
2012-05-05 10:42   ` Pallala, Ramakrishna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120505125153.GA31018@lizard \
    --to=cbouatmailru@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@iki.fi \
    --cc=ramakrishna.pallala@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.