linux-kernel - Re: [PATCH 09/15] twl4030_charger: allow max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Mar 2015 17:26:00 +1100
From:	NeilBrown <neilb@...e.de>
To:	Pavel Machek <pavel@....cz>
Cc:	Samuel Ortiz <sameo@...ux.intel.com>,
	Tony Lindgren <tony@...mide.com>,
	Lee Jones <lee.jones@...aro.org>,
	Sebastian Reichel <sre@...nel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	GTA04 owners <gta04-owner@...delico.com>,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org
Subject: Re: [PATCH 09/15] twl4030_charger: allow max_current to be managed
 via sysfs.

On Mon, 2 Mar 2015 22:05:26 +0100 Pavel Machek <pavel@....cz> wrote:

> On Tue 2015-02-24 15:33:52, NeilBrown wrote:
> > 'max_current' sysfs attributes are created which allow the
> > max to be set.
> > Whenever a current source changes, the default is restored.
> > This will be followed by a uevent, so user-space can decide to
> > update again.
> 
> Does this need Documentation update?

Oh all right... I've created the relevant documentation in Documentation/ABI.

It seems persistence pays off :-)


> 
> > Signed-off-by: NeilBrown <neilb@...e.de>
> > ---
> >  drivers/power/twl4030_charger.c |   76 +++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 76 insertions(+)
> > 
> > diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
> > index bfc9b808301e..b0242786d047 100644
> > --- a/drivers/power/twl4030_charger.c
> > +++ b/drivers/power/twl4030_charger.c
> > @@ -527,6 +529,67 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void *arg)
> >  	return IRQ_HANDLED;
> >  }
> >  
> > +/*
> > + * sysfs max_current store
> > + */
> 
> That's not exactly useful comment.

Now:

 * Provide "max_current" attribute in sysfs.

> 
> > +static ssize_t
> > +twl4030_bci_max_current_store(struct device *dev, struct device_attribute *attr,
> > +	const char *buf, size_t n)
> > +{
> > +	struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
> > +	int cur = 0;
> > +	int status = 0;
> > +	status = kstrtoint(buf, 10, &cur);
> > +	if (status)
> > +		return status;
> > +	if (cur < 0)
> > +		return -EINVAL;
> > +	if (dev == bci->ac.dev) {
> > +		if (bci->ac_cur == cur)
> > +			return n;
> > +		bci->ac_cur = cur;
> > +	} else {
> > +		if (bci->usb_cur == cur)
> > +			return n;
> > +		bci->usb_cur = cur;
> > +	}
> > +	twl4030_charger_update_current(bci);
> > +	return (status == 0) ? n : status;
> > +}
> 
> Uff. but we know that status == 0 at this point, no? 

Yes.  Fixed.

>                                                       Also... is
> optimalization of not calling update_current() when nothing changed
> worth it?

Probably not... and  code looks a lot nicer if I remove that.
So I have.


> 
> > +/*
> > + * sysfs max_current show
> > + */
> > +static ssize_t twl4030_bci_max_current_show(struct device *dev,
> > +	struct device_attribute *attr, char *buf)
> > +{
> > +	int status = 0;
> > +	int cur = -1;
> > +	u8 bcictl1;
> > +	struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
> > +
> > +	if (dev == bci->ac.dev) {
> > +		if (!bci->ac_is_active)
> > +			cur = bci->ac_cur;
> > +	} else {
> > +		if (bci->ac_is_active)
> > +			cur = bci->usb_cur;
> > +	}
> > +	if (cur < 0) {
> > +		cur = twl4030bci_read_adc_val(TWL4030_BCIIREF1);
> > +		if (cur < 0)
> > +			return cur;
> > +		status = twl4030_bci_read(TWL4030_BCICTL1, &bcictl1);
> > +		if (status < 0)
> > +			return status;
> > +		cur = regval2ua(cur, bcictl1 & TWL4030_CGAIN);
> > +	}
> > +	return scnprintf(buf, PAGE_SIZE, "%u\n", cur);
> > +}
> 
> Is this in uA or mA? uA. Ok.

uA, now described in Documentation/ABI/testing/sysfs-class-power-twl4030

+What: /sys/class/power_supply/twl4030_ac/max_current
+      /sys/class/power_supply/twl4030_usb/max_current
+Description:
+       Read/Write limit on current which which may
+       be drawn from the ac (Accessory Charger) or
+       USB port.
+
+       Value is in micro-Amps.
+
+       Value is set automatically to an appropriate
+       value when a cable is plugged on unplugged.
+
+       Value can the set by writing to the attribute.
+       The change will only persist until the next
+       plug event.  These event are reported via udev.


> 
> Acked-by: Pavel Machek <pavel@....cz>
> 									Pavel
> 

Thanks,
NeilBrown

Content of type "application/pgp-signature" skipped