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:	Mon, 7 Jan 2013 05:09:02 +0000
From:	"Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>
To:	Anton Vorontsov <anton@...msg.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Tc, Jenny" <jenny.tc@...el.com>,
	Myungjoo Ham <myungjoo.ham@...sung.com>
Subject: RE: [PATCH 1/2] power_supply: Add charge control struct in power
 supply class

> > +struct power_supply_charger_control {
> > +	const char *name;
> > +	/* get charging status */
> > +	int (*is_charging_enabled)(void);
> > +	int (*is_charger_enabled)(void);
> > +
> > +	/* set charging parameters */
> > +	int (*set_in_current_limit)(int uA);
> > +	int (*set_charge_current)(int uA);
> > +	int (*set_charge_voltage)(int uV);
> > +
> > +	/* control battery charging */
> > +	int (*enable_charging)(void);
> > +	int (*disable_charging)(void);
> > +
> > +	/* control VSYS or system supply */
> > +	int (*turnon_charger)(void);
> > +	int (*turnoff_charger)(void);
> > +};
> > +
> 
> I'm all for this patch, but why do you need to place it into power_supply.h and
> power_supply_core.c? :) I see nothing generic here, it's pure charger-manager
> stuff. So, place everything into charger-manager.{c,h}.

Hi Anton,

The main reason for keeping this stuff in power_supply.h and power_supply_core.c is to make these interfaces uniform
Across multiple charger frameworks and to avoid each charger framework define it's own interfaces. If there is need for new callback
They can add to the existing struct defined above and it will available to all the frameworks. Also the work required to support a new
Framework will be reduced if the driver already support any one of the existing frameworks.
 
Thanks,
Ram

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ