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] [day] [month] [year] [list]
Date:	Tue, 8 Mar 2011 23:46:29 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	MyungJoo Ham <myungjoo.ham@...sung.com>
Cc:	linux-kernel@...r.kernel.org, rtc-linux@...glegroups.com,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	kyungmin.park@...sung.com, myungjoo.ham@...il.com
Subject: Re: [PATCH v4 2/4] MAX8997/8966 PMIC Regulator Driver Initial
 Release

On Tue, Mar 08, 2011 at 05:37:21PM +0900, MyungJoo Ham wrote:
> This patch supports PMIC/Regulator part of MAX8997/MAX8966 MFD.
> In this initial release, selecting voltages or current-limit
> and switching on/off the regulators are supported.

This looks pretty good, it's probably OK to apply as-is and clean up
some more stuff later on.

> +static int max8997_list_voltage_charger_cv(struct regulator_dev *rdev,
> +		unsigned int selector)
> +{
> +	int rid = max8997_get_rid(rdev);
> +
> +	if (rid == MAX8997_CHARGER_CV) {

A little nicer to do if != then error out (saves indentation for the
entire rest of the function.

> +/*
> + * Assess the damage on the voltage setting of BUCK1,2,5 by the change.
> + *
> + * When GPIO-DVS mode is used for multiple bucks, changing the voltage value
> + * of one of the bucks may affect that of another buck, which is the side
> + * effect of the change (set_voltage). This function examines the GPIO-DVS
> + * configurations and checks whether such side-effect exists.
> + */

I'm not 100% sure I understand exactly what the mechanism for side
effects to occur is here (the code is a little abstruse, I'd expect it
to go through and set a flag if it finds a side effect would occur).
However, one thing that occurs to me is that you're not using the fact
that the regulator API passes in voltage ranges in the checks - you're
checking for any change, but it's possible that a side effect could
occur and still be in the range that was requested which should ideally
be allowed.  For example, if the side effect would be to change from
1.1V to 1.2V but the requested range was 1.1-1.3V then while there is
a side effect all the requirements that drivers provided are still being
met so we don't need to worry.

This sort of side effect is something we shouild probably add to the
core, other hardware has the possibility of having similar gang control
of the regulators although the mechanism here seems unusually complex.
I don't think we need to do that for this driver though.
--
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