| 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
| ||
|
Message-ID: <20180417194755.GE244487@google.com>
Date: Tue, 17 Apr 2018 12:47:55 -0700
From: Matthias Kaehlcke <mka@...omium.org>
To: David Collins <collinsd@...eaurora.org>
Cc: broonie@...nel.org, lgirdwood@...il.com, robh+dt@...nel.org,
mark.rutland@....com, linux-arm-msm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, rnayak@...eaurora.org,
sboyd@...nel.org, dianders@...omium.org
Subject: Re: [v2,2/2] regulator: add QCOM RPMh regulator driver
On Tue, Apr 17, 2018 at 12:15:18PM -0700, David Collins wrote:
> On 04/17/2018 11:23 AM, Matthias Kaehlcke wrote:
> > On Fri, Apr 13, 2018 at 07:50:35PM -0700, David Collins wrote:
> >> Add the QCOM RPMh regulator driver to manage PMIC regulators
> >> which are controlled via RPMh on some Qualcomm Technologies, Inc.
> >> SoCs. RPMh is a hardware block which contains several
> >> accelerators which are used to manage various hardware resources
> >> that are shared between the processors of the SoC. The final
> >> hardware state of a regulator is determined within RPMh by
> >> performing max aggregation of the requests made by all of the
> >> processors.
> >> [...]
> >> +/**
> >> + * struct rpmh_vreg_hw_data - RPMh regulator hardware configurations
> >> + * @regulator_type: RPMh accelerator type used to manage this
> >> + * regulator
> >> + * @ops: Pointer to regulator ops callback structure
> >> + * @voltage_range: The single range of voltages supported by this
> >> + * PMIC regulator type
> >> + * @n_voltages: The number of unique voltage set points defined
> >> + * by voltage_range
> >> + * @pmic_mode_map: Array indexed by regulator framework mode
> >> + * containing PMIC hardware modes. Must be large
> >> + * enough to index all framework modes supported
> >> + * by this regulator hardware type.
> >> + * @of_map_mode: Maps an RPMH_REGULATOR_MODE_* mode value defined
> >> + * in device tree to a regulator framework mode
> >
> > The name of the field is a bit misleading, this is a map of RPMh mode
> > to regulator framework mode, the device tree just happens to be the
> > place where this mapping is defined.
>
> of_map_mode name is used here to match the struct regulator_desc field by
> the same name that it is assigned to [1]. Do you think that the name
> should be changed to something else?
Thanks, I missed that it's the name of the field in struct
regulator_desc field, in that case it certainly makes sense to use the
same name.
> >> +/**
> >> + * struct rpmh_vreg - individual rpmh regulator data structure encapsulating a
> >> + * single regulator device
> >> + * @rpmh_client: Handle used for rpmh communications
> >
> > nit: RPMh
>
> I'll change this.
>
>
> >> +struct rpmh_vreg {
> >> + struct rpmh_client *rpmh_client;
> >> + u32 addr;
> >> + struct regulator_desc rdesc;
> >> + const struct rpmh_vreg_hw_data *hw_data;
> >> + enum rpmh_regulator_type regulator_type;
> >
> > This value is already available via rpmh_vreg->hw_data->regulator_type,
> > why duplicate it? The field is assigned in rpmh_regulator_init_vreg()
> > and only read once in the same function, there seems to be no need for
> > it, not even to improve readability.
>
> This is present to specifically allow for a future change to support
> overriding the regulator_type value from device tree in order to force
> RPMh resources to be handled via XOB instead of VRM in a board-specific
> manner. I included support of the property qcom,rpmh-resource-type in the
> first version of this patch. I removed this property from the second
> version of the patch based upon review feedback since SDM845 does not
> explicitly need it (though an upcoming chip will).
>
> I'll remove regulator_type from struct rpmh_vreg. It shouldn't be
> particularly painful to add it back in when needed for XOB override support.
>
>
> >> +static int rpmh_regulator_vrm_set_load(struct regulator_dev *rdev, int load_uA)
> >> +{
> >> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> >> + int i;
> >> +
> >> + for (i = 0; i < vreg->drms_mode_count - 1; i++)
> >> + if (load_uA < vreg->drms_mode_max_uA[i])
> >
> > Shouldn't this be '<='?
> >
> > nit: IMO 'vreg->drms_mode_max_uA[i] >= load_uA' would be more readable.
>
> I chose to use '<' here in order to maintain the non-inclusive limit
> semantics of the downstream RPMh regulator driver. E.g. with an LPM
> threshold of 10000 uA, load_uA == 10000 would result in a request for HPM
> instead of LPM.
>
> I suppose that I can change this to '<=' to be more logically consistent.
>
>
> >> +static const u32 pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = {
> >> + [REGULATOR_MODE_STANDBY] = 4,
> >> + [REGULATOR_MODE_IDLE] = 5,
> >> + [REGULATOR_MODE_NORMAL] = -EINVAL,
> >> + [REGULATOR_MODE_FAST] = 7,
> >> +};
> >
> > Define constants for the modes on the PMIC4 side?
>
> Are you suggesting something like this?
>
> #define PMIC4_LDO_MODE_RETENTION 4
> #define PMIC4_LDO_MODE_LPM 5
> #define PMIC4_LDO_MODE_HPM 7
>
> static const u32 pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = {
> [REGULATOR_MODE_STANDBY] = PMIC4_LDO_MODE_RETENTION,
> [REGULATOR_MODE_IDLE] = PMIC4_LDO_MODE_LPM,
> [REGULATOR_MODE_NORMAL] = -EINVAL,
> [REGULATOR_MODE_FAST] = PMIC4_LDO_MODE_HPM,
> };
>
> #define PMIC4_SMPS_MODE_RETENTION 4
> #define PMIC4_SMPS_MODE_PFM 5
> #define PMIC4_SMPS_MODE_AUTO 6
> #define PMIC4_SMPS_MODE_PWM 7
>
> static const u32 pmic_mode_map_pmic4_smps[REGULATOR_MODE_STANDBY + 1] = {
> [REGULATOR_MODE_STANDBY] = PMIC4_SMPS_MODE_RETENTION,
> [REGULATOR_MODE_IDLE] = PMIC4_SMPS_MODE_PFM,
> [REGULATOR_MODE_NORMAL] = PMIC4_SMPS_MODE_AUTO,
> [REGULATOR_MODE_FAST] = PMIC4_SMPS_MODE_PWM,
> };
>
> I considered using this approach, but it didn't seem like it increased
> readability and did increase the line count. Each of the constants would
> only be used once. Would you prefer this style (or something else)?
Personally I prefer this style, since the constants are more
expressive than the literals. I agree that the 'inline' constant
definition is a bit noisy, perhaps it would be better to move the
definitions to the top of the file or group them before the definition
of pmic_mode_map_pmic4_ldo. Alteratively you could create a
drivers/regulator/qcom_rpmh-regulator.h and also move the definitions
of struct struct rpmh_vreg_hw_data, rpmh_vreg, ... there.
Thanks
Matthias
Powered by blists - more mailing lists