linux-kernel - RE: [RFC] intel_mid: Intel MSIC battery driver

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:	Tue, 14 Dec 2010 13:51:56 +0530
From:	"Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, "cbou@...l.ru" <cbou@...l.ru>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] intel_mid: Intel MSIC battery driver

Hi Mark,

Thanks for the comments.

> > +static enum power_supply_property msic_usb_props[] = {
> > +	POWER_SUPPLY_PROP_TYPE,
> > +	POWER_SUPPLY_PROP_CHARGE_TYPE,
> > +	POWER_SUPPLY_PROP_PRESENT,
> > +	POWER_SUPPLY_PROP_HEALTH,
> > +	POWER_SUPPLY_PROP_VOLTAGE_NOW,
> > +	POWER_SUPPLY_PROP_MODEL_NAME,
> > +	POWER_SUPPLY_PROP_MANUFACTURER,
> 
> It seems a bit odd that the USB interface has a charge related property
> - while it may be the current supply for the charger the thing that's
> actually being charged is the battery which doesn't have a charge type.
> See also below...
Agreed will fix it.

> 
> > +static int mdf_read_adc_regs(int sensor,
> > +			struct msic_power_module_info *mbi)
> 
> Might it be useful to push these into the core code for whatever you're
> talking to so that you can expose both power supply and hwmon interface
> versions of the supply monitoring?
Generic ADC driver development is in progress. I will remove this code as soon as the ADC driver comes in.
 

> > +static void msic_handle_exception(struct msic_power_module_info *mbi,
> > +		uint8_t CHRINT_reg_value, uint8_t CHRINT1_reg_value)
> > +{
> > +	enum msic_event exception;
> 
> I'd expect this to generate a power_supply_changed() too - it's possible
> I'm just missing the code for that somewhere else, though.
> 
Agreed will fix it.

> > +       if (mbi->ch_params.vinilmt == CHRG_CURR_SDP_LOW)
> > +               mbi->usb_chrg_props.charger_type =
> POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
> > +       else
> > +               mbi->usb_chrg_props.charger_type =
> > +                                       POWER_SUPPLY_CHARGE_TYPE_FAST;
> 
> This isn't what fast and trickle charge are, they're not static
> properties but rather reflect the kind of charging that's being done.
> Broadly speaking trickle charge means that charge is being fed slowly
> into the battery (usually at either extreme of the charge curve when the
> battery is either near full or near discharge) while fast charge means
> that charge is being pushed into the battery much more rapidly.  This
> will vary throughout the charge cycle.
> 
> It's likely that if the supply is constrained (eg, 100mA USB) then there
> won't be enough current to ever do a fast charge but the availability of
> more supply doesn't mean that we're in fast charge.

If I understand correctly trickle charging will happen during full(or deeply discharge) charge conditions.
But as soon as I hit the charge full condition I am stopping the charging and will go into maintenance mode.
In maintenance mode I will check battery voltage to hit for lower threshold value and then enable the charging.
During maintenance mode battery voltage is near to FULL charge value, So can I set the charging type to trickle during maintenance  mode?


--
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/