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, 13 Dec 2010 16:20:34 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	ramakrishna.pallala@...el.com, cbou@...l.ru, dwmw2@...radead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] intel_mid: Intel MSIC battery driver

On Mon, Dec 13, 2010 at 03:30:54PM +0000, Alan Cox wrote:

> +/*
> + * msic usb properties
> + */
> +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...

> +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?

> +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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ