[v8,0/9] iio: adc: introduce Qualcomm SPMI Round Robin ADC

Message ID	20220221220743.541704-1-caleb.connolly@linaro.org
Headers	show Return-Path: <devicetree-owner@vger.kernel.org> From: Caleb Connolly <caleb.connolly@linaro.org> To: caleb.connolly@linaro.org, Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Rob Herring <robh+dt@kernel.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Lee Jones <lee.jones@linaro.org>, Stephen Boyd <sboyd@kernel.org>, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org Cc: sumit.semwal@linaro.org, amit.pundir@linaro.org, john.stultz@linaro.org Subject: [PATCH v8 0/9] iio: adc: introduce Qualcomm SPMI Round Robin ADC Date: Mon, 21 Feb 2022 22:07:34 +0000 Message-Id: <20220221220743.541704-1-caleb.connolly@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk
Series	iio: adc: introduce Qualcomm SPMI Round Robin ADC \| expand [v8,0/9] iio: adc: introduce Qualcomm SPMI Round Robin ADC [v8,4/9] dt-bindings: iio: adc: document qcom-spmi-rradc

Caleb Connolly Feb. 21, 2022, 10:07 p.m. UTC

The RRADC is responsible for reading data about the current and
voltage from the USB or DC in jacks, it can also read the battery
ID (resistence) and some temperatures. It is found on the PMI8998 and
PM660 Qualcomm PMICs.

The RRADC has to calibrate some ADC values based on which chip fab
the PMIC was produced in, to facilitate this the patches
("mfd: qcom-spmi-pmic: expose the PMIC revid information to clients")
and ("mfd: qcom-spmi-pmic: read fab id on supported PMICs")
expose the PMIC revision information and fab_id as a struct and register
them as driver data in the Qualcomm SPMI PMIC driver so that it can be
read by the RRADC.

The first 3 patches add support for looking up an SPMI device from a
struct device_node, as well as introducing support for looking up the
base USID of a Qcom PMIC, see patch comments for more details. These
Address Bjorns comments on v2.

Changes since v7:
 * Addressed Jonathans comments
 * Fixed bug reported by LKP

Changes since v6:
 * Fix printf format warning in rradc

Changes since v5:
 * Add missing EXPORT_SYMBOL_GPL() to
   ("spmi: add a helper to look up an SPMI device from a device node")

Changes since v4:
 * Addressed Jonathan's comments on v4
 * Reworked the qcom-spmi-pmic patches to properly walk the devicetree
   to find the base USID. I've tested this on SDM845 which has two PMICs
   (pm8998 and pmi8998) and I'm able to look up the PMIC revid from all
   4 USIDs.

Changes since v3:
 * Split PMIC patch in two, rework to support function drivers on a
   sibling USID
 * Completely rework RRADC driver to make use of the modern IIO
   framework. This required re-arranging a lot of the equations and
   results in some lost precision, where relevant I've left comments to
   explain this. I don't think any of it is significant enough to
   justify doing post-processing in driver.
	Thanks a lot Jonathan and John Stultz for helping me out with
	this 

Changes since v2:
 * Add missing include (thanks kernel test robot :D)
 * Rework some confusing function return values, specifically
   rradc_read_status_in_cont_mode and rradc_prepare_batt_id_conversion
   both of which didn't correctly handle "ret". This also bought up an
   issue as the previous implementation didn't actually wait for the
   channel to be ready. It doesn't seem like that's strictly necessary
   (same data is reported if I wait for the status to be good or not)
   but I've included it anyway for good measure.

Changes since v1:
 * Rework the RRADC driver based on Jonathan's feedback
 * Pick up Rob's reviewed by for the dt-binding patch.

 --

Caleb Connolly (9):
  spmi: add a helper to look up an SPMI device from a device node
  mfd: qcom-spmi-pmic: expose the PMIC revid information to clients
  mfd: qcom-spmi-pmic: read fab id on supported PMICs
  dt-bindings: iio: adc: document qcom-spmi-rradc
  iio: adc: qcom-spmi-rradc: introduce round robin adc
  arm64: dts: qcom: pmi8998: add rradc node
  arm64: dts: qcom: sdm845-oneplus: enable rradc
  arm64: dts: qcom: sdm845-db845c: enable rradc
  arm64: dts: qcom: sdm845-xiaomi-beryllium: enable rradc

 .../bindings/iio/adc/qcom,spmi-rradc.yaml     |   54 +
 arch/arm64/boot/dts/qcom/pmi8998.dtsi         |    8 +
 arch/arm64/boot/dts/qcom/sdm845-db845c.dts    |    4 +
 .../boot/dts/qcom/sdm845-oneplus-common.dtsi  |    4 +
 .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts |    4 +
 drivers/iio/adc/Kconfig                       |   12 +
 drivers/iio/adc/Makefile                      |    1 +
 drivers/iio/adc/qcom-spmi-rradc.c             | 1011 +++++++++++++++++
 drivers/mfd/qcom-spmi-pmic.c                  |  181 ++-
 drivers/spmi/spmi.c                           |   17 +
 include/linux/spmi.h                          |    2 +
 include/soc/qcom/qcom-spmi-pmic.h             |   61 +
 12 files changed, 1303 insertions(+), 56 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
 create mode 100644 drivers/iio/adc/qcom-spmi-rradc.c
 create mode 100644 include/soc/qcom/qcom-spmi-pmic.h

Bjorn Andersson Feb. 24, 2022, 8:43 p.m. UTC | #1

On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:

> Some PMIC functions such as the RRADC need to be aware of the PMIC
> chip revision information to implement errata or otherwise adjust
> behaviour, export the PMIC information to enable this.
> 
> This is specifically required to enable the RRADC to adjust
> coefficients based on which chip fab the PMIC was produced in,
> this can vary per unique device and therefore has to be read at
> runtime.
> 
> [bugs in previous revision]
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>

This says is that "kernel test robot" and Dan reported that something
needed to be fixed and this patch is the fix for this.

So even though their emails asks for you to give them credit like this
you can't do it for new patches.

Regards,
Bjorn

> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
> ---
>  drivers/mfd/qcom-spmi-pmic.c      | 174 ++++++++++++++++++++----------
>  include/soc/qcom/qcom-spmi-pmic.h |  60 +++++++++++
>  2 files changed, 178 insertions(+), 56 deletions(-)
>  create mode 100644 include/soc/qcom/qcom-spmi-pmic.h
> 
> diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c
> index 1cacc00aa6c9..1ef426a1513b 100644
> --- a/drivers/mfd/qcom-spmi-pmic.c
> +++ b/drivers/mfd/qcom-spmi-pmic.c
> @@ -3,11 +3,16 @@
>   * Copyright (c) 2014, The Linux Foundation. All rights reserved.
>   */
>  
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/gfp.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/spmi.h>
> +#include <linux/types.h>
>  #include <linux/regmap.h>
>  #include <linux/of_platform.h>
> +#include <soc/qcom/qcom-spmi-pmic.h>
>  
>  #define PMIC_REV2		0x101
>  #define PMIC_REV3		0x102
> @@ -17,37 +22,6 @@
>  
>  #define PMIC_TYPE_VALUE		0x51
>  
> -#define COMMON_SUBTYPE		0x00
> -#define PM8941_SUBTYPE		0x01
> -#define PM8841_SUBTYPE		0x02
> -#define PM8019_SUBTYPE		0x03
> -#define PM8226_SUBTYPE		0x04
> -#define PM8110_SUBTYPE		0x05
> -#define PMA8084_SUBTYPE		0x06
> -#define PMI8962_SUBTYPE		0x07
> -#define PMD9635_SUBTYPE		0x08
> -#define PM8994_SUBTYPE		0x09
> -#define PMI8994_SUBTYPE		0x0a
> -#define PM8916_SUBTYPE		0x0b
> -#define PM8004_SUBTYPE		0x0c
> -#define PM8909_SUBTYPE		0x0d
> -#define PM8028_SUBTYPE		0x0e
> -#define PM8901_SUBTYPE		0x0f
> -#define PM8950_SUBTYPE		0x10
> -#define PMI8950_SUBTYPE		0x11
> -#define PM8998_SUBTYPE		0x14
> -#define PMI8998_SUBTYPE		0x15
> -#define PM8005_SUBTYPE		0x18
> -#define PM660L_SUBTYPE		0x1A
> -#define PM660_SUBTYPE		0x1B
> -#define PM8150_SUBTYPE		0x1E
> -#define PM8150L_SUBTYPE		0x1f
> -#define PM8150B_SUBTYPE		0x20
> -#define PMK8002_SUBTYPE		0x21
> -#define PM8009_SUBTYPE		0x24
> -#define PM8150C_SUBTYPE		0x26
> -#define SMB2351_SUBTYPE		0x29
> -
>  static const struct of_device_id pmic_spmi_id_table[] = {
>  	{ .compatible = "qcom,pm660",     .data = (void *)PM660_SUBTYPE },
>  	{ .compatible = "qcom,pm660l",    .data = (void *)PM660L_SUBTYPE },
> @@ -81,42 +55,118 @@ static const struct of_device_id pmic_spmi_id_table[] = {
>  	{ }
>  };
>  
> -static void pmic_spmi_show_revid(struct regmap *map, struct device *dev)
> +/**
> + * qcom_pmic_get() - Get a pointer to the base PMIC device
> + *
> + * @dev: the pmic function device
> + * @return: the struct qcom_spmi_pmic* pointer associated with the function device
> + *
> + * A PMIC can be represented by multiple SPMI devices, but
> + * only the base PMIC device will contain a reference to
> + * the revision information.
> + *
> + * This function takes a pointer to a function device and
> + * returns a pointer to the base PMIC device.
> + */
> +const struct qcom_spmi_pmic *qcom_pmic_get(struct device *dev)
> +{
> +	struct spmi_device *sdev;
> +	struct device_node *spmi_bus;
> +	struct device_node *other_usid = NULL;
> +	int function_parent_usid, ret;
> +	u32 reg[2];
> +
> +	if (!of_match_device(pmic_spmi_id_table, dev->parent))
> +		return ERR_PTR(-EINVAL);
> +
> +	sdev = to_spmi_device(dev->parent);
> +	if (!sdev)
> +		return ERR_PTR(-EINVAL);
> +
> +	/*
> +	 * Quick return if the function device is already in the right
> +	 * USID
> +	 */
> +	if (sdev->usid % 2 == 0)
> +		return spmi_device_get_drvdata(sdev);
> +
> +	function_parent_usid = sdev->usid;
> +
> +	/*
> +	 * Walk through the list of PMICs until we find the sibling USID.
> +	 * The goal is the find to previous sibling. Assuming there is no
> +	 * PMIC with more than 2 USIDs. We know that function_parent_usid
> +	 * is one greater than the base USID.
> +	 */
> +	spmi_bus = of_get_parent(sdev->dev.parent->of_node);
> +	do {
> +		other_usid = of_get_next_child(spmi_bus, other_usid);
> +		ret = of_property_read_u32_array(other_usid, "reg", reg, 2);
> +		if (ret)
> +			return ERR_PTR(ret);
> +		sdev = spmi_device_from_of(other_usid);
> +		if (sdev == NULL) {
> +			/*
> +			 * If the base USID for this PMIC hasn't probed yet
> +			 * but the secondary USID has, then we need to defer
> +			 * the function driver so that it will attempt to
> +			 * probe again when the base USID is ready.
> +			 */
> +			if (reg[0] == function_parent_usid - 1)
> +				return ERR_PTR(-EPROBE_DEFER);
> +
> +			continue;
> +		}
> +
> +		if (reg[0] == function_parent_usid - 1)
> +			return spmi_device_get_drvdata(sdev);
> +	} while (other_usid->sibling);
> +
> +	return ERR_PTR(-ENODATA);
> +}
> +EXPORT_SYMBOL(qcom_pmic_get);
> +
> +static inline void pmic_print_info(struct device *dev, struct qcom_spmi_pmic *pmic)
> +{
> +	dev_dbg(dev, "%x: %s v%d.%d\n",
> +		pmic->subtype, pmic->name, pmic->major, pmic->minor);
> +}
> +
> +static int pmic_spmi_load_revid(struct regmap *map, struct device *dev,
> +				 struct qcom_spmi_pmic *pmic)
>  {
> -	unsigned int rev2, minor, major, type, subtype;
> -	const char *name = "unknown";
>  	int ret, i;
>  
> -	ret = regmap_read(map, PMIC_TYPE, &type);
> +	ret = regmap_read(map, PMIC_TYPE, &pmic->type);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
> -	if (type != PMIC_TYPE_VALUE)
> -		return;
> +	if (pmic->type != PMIC_TYPE_VALUE)
> +		return ret;
>  
> -	ret = regmap_read(map, PMIC_SUBTYPE, &subtype);
> +	ret = regmap_read(map, PMIC_SUBTYPE, &pmic->subtype);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
>  	for (i = 0; i < ARRAY_SIZE(pmic_spmi_id_table); i++) {
> -		if (subtype == (unsigned long)pmic_spmi_id_table[i].data)
> +		if (pmic->subtype == (unsigned long)pmic_spmi_id_table[i].data)
>  			break;
>  	}
>  
>  	if (i != ARRAY_SIZE(pmic_spmi_id_table))
> -		name = pmic_spmi_id_table[i].compatible;
> +		pmic->name = devm_kstrdup_const(dev, pmic_spmi_id_table[i].compatible, GFP_KERNEL);
>  
> -	ret = regmap_read(map, PMIC_REV2, &rev2);
> +	ret = regmap_read(map, PMIC_REV2, &pmic->rev2);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
> -	ret = regmap_read(map, PMIC_REV3, &minor);
> +	ret = regmap_read(map, PMIC_REV3, &pmic->minor);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
> -	ret = regmap_read(map, PMIC_REV4, &major);
> +	ret = regmap_read(map, PMIC_REV4, &pmic->major);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
>  	/*
>  	 * In early versions of PM8941 and PM8226, the major revision number
> @@ -124,14 +174,16 @@ static void pmic_spmi_show_revid(struct regmap *map, struct device *dev)
>  	 * Increment the major revision number here if the chip is an early
>  	 * version of PM8941 or PM8226.
>  	 */
> -	if ((subtype == PM8941_SUBTYPE || subtype == PM8226_SUBTYPE) &&
> -	    major < 0x02)
> -		major++;
> +	if ((pmic->subtype == PM8941_SUBTYPE || pmic->subtype == PM8226_SUBTYPE) &&
> +	    pmic->major < 0x02)
> +		pmic->major++;
> +
> +	if (pmic->subtype == PM8110_SUBTYPE)
> +		pmic->minor = pmic->rev2;
>  
> -	if (subtype == PM8110_SUBTYPE)
> -		minor = rev2;
> +	pmic_print_info(dev, pmic);
>  
> -	dev_dbg(dev, "%x: %s v%d.%d\n", subtype, name, major, minor);
> +	return 0;
>  }
>  
>  static const struct regmap_config spmi_regmap_config = {
> @@ -144,14 +196,24 @@ static const struct regmap_config spmi_regmap_config = {
>  static int pmic_spmi_probe(struct spmi_device *sdev)
>  {
>  	struct regmap *regmap;
> +	struct qcom_spmi_pmic *pmic;
> +	int ret;
>  
>  	regmap = devm_regmap_init_spmi_ext(sdev, &spmi_regmap_config);
>  	if (IS_ERR(regmap))
>  		return PTR_ERR(regmap);
>  
> +	pmic = devm_kzalloc(&sdev->dev, sizeof(*pmic), GFP_KERNEL);
> +	if (!pmic)
> +		return -ENOMEM;
> +
>  	/* Only the first slave id for a PMIC contains this information */
> -	if (sdev->usid % 2 == 0)
> -		pmic_spmi_show_revid(regmap, &sdev->dev);
> +	if (sdev->usid % 2 == 0) {
> +		ret = pmic_spmi_load_revid(regmap, &sdev->dev, pmic);
> +		if (ret < 0)
> +			return ret;
> +		spmi_device_set_drvdata(sdev, pmic);
> +	}
>  
>  	return devm_of_platform_populate(&sdev->dev);
>  }
> diff --git a/include/soc/qcom/qcom-spmi-pmic.h b/include/soc/qcom/qcom-spmi-pmic.h
> new file mode 100644
> index 000000000000..a8a77be22cfc
> --- /dev/null
> +++ b/include/soc/qcom/qcom-spmi-pmic.h
> @@ -0,0 +1,60 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Copyright (c) 2021 Linaro. All rights reserved.
> + * Copyright (c) 2021 Caleb Connolly <caleb.connolly@linaro.org>
> + */
> +
> +#ifndef __QCOM_PMIC_H__
> +#define __QCOM_PMIC_H__
> +
> +#define COMMON_SUBTYPE		0x00
> +#define PM8941_SUBTYPE		0x01
> +#define PM8841_SUBTYPE		0x02
> +#define PM8019_SUBTYPE		0x03
> +#define PM8226_SUBTYPE		0x04
> +#define PM8110_SUBTYPE		0x05
> +#define PMA8084_SUBTYPE		0x06
> +#define PMI8962_SUBTYPE		0x07
> +#define PMD9635_SUBTYPE		0x08
> +#define PM8994_SUBTYPE		0x09
> +#define PMI8994_SUBTYPE		0x0a
> +#define PM8916_SUBTYPE		0x0b
> +#define PM8004_SUBTYPE		0x0c
> +#define PM8909_SUBTYPE		0x0d
> +#define PM8028_SUBTYPE		0x0e
> +#define PM8901_SUBTYPE		0x0f
> +#define PM8950_SUBTYPE		0x10
> +#define PMI8950_SUBTYPE		0x11
> +#define PM8998_SUBTYPE		0x14
> +#define PMI8998_SUBTYPE		0x15
> +#define PM8005_SUBTYPE		0x18
> +#define PM660L_SUBTYPE		0x1A
> +#define PM660_SUBTYPE		0x1B
> +#define PM8150_SUBTYPE		0x1E
> +#define PM8150L_SUBTYPE		0x1f
> +#define PM8150B_SUBTYPE		0x20
> +#define PMK8002_SUBTYPE		0x21
> +#define PM8009_SUBTYPE		0x24
> +#define PM8150C_SUBTYPE		0x26
> +#define SMB2351_SUBTYPE		0x29
> +
> +#define PMI8998_FAB_ID_SMIC	0x11
> +#define PMI8998_FAB_ID_GF	0x30
> +
> +#define PM660_FAB_ID_GF		0x0
> +#define PM660_FAB_ID_TSMC	0x2
> +#define PM660_FAB_ID_MX		0x3
> +
> +struct qcom_spmi_pmic {
> +	unsigned int type;
> +	unsigned int subtype;
> +	unsigned int major;
> +	unsigned int minor;
> +	unsigned int rev2;
> +	const char *name;
> +};
> +
> +struct device;
> +
> +const struct qcom_spmi_pmic *qcom_pmic_get(struct device *dev);
> +
> +#endif /* __QCOM_PMIC_H__ */
> -- 
> 2.35.1
>

Lee Jones Feb. 25, 2022, 8:50 a.m. UTC | #2

On Thu, 24 Feb 2022, Bjorn Andersson wrote:

> On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:
> 
> > Some PMIC functions such as the RRADC need to be aware of the PMIC
> > chip revision information to implement errata or otherwise adjust
> > behaviour, export the PMIC information to enable this.
> > 
> > This is specifically required to enable the RRADC to adjust
> > coefficients based on which chip fab the PMIC was produced in,
> > this can vary per unique device and therefore has to be read at
> > runtime.
> > 
> > [bugs in previous revision]
> > Reported-by: kernel test robot <lkp@intel.com>
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> This says is that "kernel test robot" and Dan reported that something
> needed to be fixed and this patch is the fix for this.
> 
> So even though their emails asks for you to give them credit like this
> you can't do it for new patches.

Right, or else you'd have to give credit to anyone who provided you
with a review.  This could potentially grow to quite a long list.

Dan Carpenter Feb. 25, 2022, 9:04 a.m. UTC | #3

On Fri, Feb 25, 2022 at 08:50:43AM +0000, Lee Jones wrote:
> On Thu, 24 Feb 2022, Bjorn Andersson wrote:
> 
> > On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:
> > 
> > > Some PMIC functions such as the RRADC need to be aware of the PMIC
> > > chip revision information to implement errata or otherwise adjust
> > > behaviour, export the PMIC information to enable this.
> > > 
> > > This is specifically required to enable the RRADC to adjust
> > > coefficients based on which chip fab the PMIC was produced in,
> > > this can vary per unique device and therefore has to be read at
> > > runtime.
> > > 
> > > [bugs in previous revision]
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > 
> > This says is that "kernel test robot" and Dan reported that something
> > needed to be fixed and this patch is the fix for this.
> > 
> > So even though their emails asks for you to give them credit like this
> > you can't do it for new patches.
> 
> Right, or else you'd have to give credit to anyone who provided you
> with a review.  This could potentially grow to quite a long list.
> 

I always feel like people who find crashing bugs should get credit but
no credit for complaining about style.  It's like we reward people for
reporting bugs after it gets merged but not before.

We've had this debate before and people don't agree with me or they say
that it's fine to just include the Reported-by kbuild tags and let
people figure out from the context that probably kbuild didn't tell
people to write a new driver.

Also I think that counting Reviewed-by/Acked-by tags should be
discouraged.  It's useful as a communication between maintainers but it
shouldn't be rewarded.

regards,
dan carpenter

Lee Jones Feb. 25, 2022, 9:23 a.m. UTC | #4

On Fri, 25 Feb 2022, Dan Carpenter wrote:

> On Fri, Feb 25, 2022 at 08:50:43AM +0000, Lee Jones wrote:
> > On Thu, 24 Feb 2022, Bjorn Andersson wrote:
> > 
> > > On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:
> > > 
> > > > Some PMIC functions such as the RRADC need to be aware of the PMIC
> > > > chip revision information to implement errata or otherwise adjust
> > > > behaviour, export the PMIC information to enable this.
> > > > 
> > > > This is specifically required to enable the RRADC to adjust
> > > > coefficients based on which chip fab the PMIC was produced in,
> > > > this can vary per unique device and therefore has to be read at
> > > > runtime.
> > > > 
> > > > [bugs in previous revision]
> > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > 
> > > This says is that "kernel test robot" and Dan reported that something
> > > needed to be fixed and this patch is the fix for this.
> > > 
> > > So even though their emails asks for you to give them credit like this
> > > you can't do it for new patches.
> > 
> > Right, or else you'd have to give credit to anyone who provided you
> > with a review.  This could potentially grow to quite a long list.
> > 
> 
> I always feel like people who find crashing bugs should get credit but
> no credit for complaining about style.  It's like we reward people for
> reporting bugs after it gets merged but not before.
> 
> We've had this debate before and people don't agree with me or they say
> that it's fine to just include the Reported-by kbuild tags and let
> people figure out from the context that probably kbuild didn't tell
> people to write a new driver.

Reviews will often consist of both style and logic recommendations.
If not spotted and remedied, the latter of which would likely result
in undesired behaviour a.k.a. bugs.  So at what point, or what type of
bug would warrant a tag?

If people insist on providing tags for spotting bugs, at least place
them chronologically with a little info.

Signed-off-by: Author <author@example.com>
Reported-by: Bug Blaster <b.b@kernel.org> # off-by-one in .probe()
Signed-off-by: Maintainer <maintainer@kernel.org>

> Also I think that counting Reviewed-by/Acked-by tags should be
> discouraged.  It's useful as a communication between maintainers but it
> shouldn't be rewarded.

100%

Dan Carpenter Feb. 25, 2022, 9:40 a.m. UTC | #5

On Fri, Feb 25, 2022 at 09:23:24AM +0000, Lee Jones wrote:
> On Fri, 25 Feb 2022, Dan Carpenter wrote:
> 
> > On Fri, Feb 25, 2022 at 08:50:43AM +0000, Lee Jones wrote:
> > > On Thu, 24 Feb 2022, Bjorn Andersson wrote:
> > > 
> > > > On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:
> > > > 
> > > > > Some PMIC functions such as the RRADC need to be aware of the PMIC
> > > > > chip revision information to implement errata or otherwise adjust
> > > > > behaviour, export the PMIC information to enable this.
> > > > > 
> > > > > This is specifically required to enable the RRADC to adjust
> > > > > coefficients based on which chip fab the PMIC was produced in,
> > > > > this can vary per unique device and therefore has to be read at
> > > > > runtime.
> > > > > 
> > > > > [bugs in previous revision]
> > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > > 
> > > > This says is that "kernel test robot" and Dan reported that something
> > > > needed to be fixed and this patch is the fix for this.
> > > > 
> > > > So even though their emails asks for you to give them credit like this
> > > > you can't do it for new patches.
> > > 
> > > Right, or else you'd have to give credit to anyone who provided you
> > > with a review.  This could potentially grow to quite a long list.
> > > 
> > 
> > I always feel like people who find crashing bugs should get credit but
> > no credit for complaining about style.  It's like we reward people for
> > reporting bugs after it gets merged but not before.
> > 
> > We've had this debate before and people don't agree with me or they say
> > that it's fine to just include the Reported-by kbuild tags and let
> > people figure out from the context that probably kbuild didn't tell
> > people to write a new driver.
> 
> Reviews will often consist of both style and logic recommendations.
> If not spotted and remedied, the latter of which would likely result
> in undesired behaviour a.k.a. bugs.  So at what point, or what type of
> bug would warrant a tag?
> 

If it's a crash or memory leak.  Style comments and fixing typos are
their own reward.  Basically it's the same rule as Fixes tags.  We
shouldn't use Fixes tags for typos.

regards,
dan carpenter

Bjorn Andersson Feb. 25, 2022, 10:32 p.m. UTC | #6

On Fri 25 Feb 01:04 PST 2022, Dan Carpenter wrote:

> On Fri, Feb 25, 2022 at 08:50:43AM +0000, Lee Jones wrote:
> > On Thu, 24 Feb 2022, Bjorn Andersson wrote:
> > 
> > > On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:
> > > 
> > > > Some PMIC functions such as the RRADC need to be aware of the PMIC
> > > > chip revision information to implement errata or otherwise adjust
> > > > behaviour, export the PMIC information to enable this.
> > > > 
> > > > This is specifically required to enable the RRADC to adjust
> > > > coefficients based on which chip fab the PMIC was produced in,
> > > > this can vary per unique device and therefore has to be read at
> > > > runtime.
> > > > 
> > > > [bugs in previous revision]
> > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > 
> > > This says is that "kernel test robot" and Dan reported that something
> > > needed to be fixed and this patch is the fix for this.
> > > 
> > > So even though their emails asks for you to give them credit like this
> > > you can't do it for new patches.
> > 
> > Right, or else you'd have to give credit to anyone who provided you
> > with a review.  This could potentially grow to quite a long list.
> > 
> 
> I always feel like people who find crashing bugs should get credit but
> no credit for complaining about style.  It's like we reward people for
> reporting bugs after it gets merged but not before.
> 
> We've had this debate before and people don't agree with me or they say
> that it's fine to just include the Reported-by kbuild tags and let
> people figure out from the context that probably kbuild didn't tell
> people to write a new driver.
> 

I certainly would like to be able to recognize any form of review effort
going into the evolution of a patch, but if we use Reported-by for that
purpose we're loosing the ability to credit the effort to find the
regressions in the kernel.

And while it's clear that Reported-by could mean that you spotted a bug
in a previous revision of the patch, should this then be used to denote
anyone that came with any sort of feedback?

Do we want to "repurpose" Reported-by to be a list of anyone providing
any input to any previous revision of the patches? (Reported-by doesn't
sound like the right tag for that to me)

> Also I think that counting Reviewed-by/Acked-by tags should be
> discouraged.  It's useful as a communication between maintainers but it
> shouldn't be rewarded.
> 

For acked-by I definitely agree. At least in my subsystems I see a quite
good flow of Reviewed-bys from community members and am very happy about
that. It communicates that people approves of the patch, in contrast to
the more common case of no one dissaproving the patch and it's merged
just with my S-o-b...

Regards,
Bjorn

Jonathan Cameron Feb. 26, 2022, 5:03 p.m. UTC | #7

On Mon, 21 Feb 2022 22:07:35 +0000
Caleb Connolly <caleb.connolly@linaro.org> wrote:

> The helper function spmi_device_from_of() takes a device node and
> returns the SPMI device associated with it.
> This is like of_find_device_by_node but for SPMI devices.
> 
> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

Hi

I'm assuming this series will end up going in through my IIO tree.
So with that in mind, looking for an Ack from Stephen for this one.

One comment below.

Also, I vaguely wondered about whether this should switch to generic
struct fwnode rather than of/dt specific but that's probably
a question for Stephen.

Thanks,

Jonathan

> ---
>  drivers/spmi/spmi.c  | 17 +++++++++++++++++
>  include/linux/spmi.h |  2 ++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/drivers/spmi/spmi.c b/drivers/spmi/spmi.c
> index b37ead9e2fad..de550b777451 100644
> --- a/drivers/spmi/spmi.c
> +++ b/drivers/spmi/spmi.c
> @@ -386,6 +386,23 @@ static struct bus_type spmi_bus_type = {
>  	.uevent		= spmi_drv_uevent,
>  };
>  
> +/**
> + * spmi_device_from_of() - get the associated SPMI device from a device node
> + *
> + * @np:		device node
> + *
> + * Returns the struct spmi_device associated with a device node or NULL.
> + */
> +inline struct spmi_device *spmi_device_from_of(struct device_node *np)

Drop the inline.  You are exporting it which would make inline rather
hard to do and in general inline markings should be used only where there
is a clear performance argument and there isn't one here.

> +{
> +	struct device *dev = bus_find_device_by_of_node(&spmi_bus_type, np);
> +
> +	if (dev)
> +		return to_spmi_device(dev);
> +	return NULL;
> +}
> +EXPORT_SYMBOL_GPL(spmi_device_from_of);
> +
>  /**
>   * spmi_controller_alloc() - Allocate a new SPMI device
>   * @ctrl:	associated controller
> diff --git a/include/linux/spmi.h b/include/linux/spmi.h
> index 729bcbf9f5ad..6ee476bc1cd6 100644
> --- a/include/linux/spmi.h
> +++ b/include/linux/spmi.h
> @@ -7,6 +7,7 @@
>  #include <linux/types.h>
>  #include <linux/device.h>
>  #include <linux/mod_devicetable.h>
> +#include <linux/of.h>
>  
>  /* Maximum slave identifier */
>  #define SPMI_MAX_SLAVE_ID		16
> @@ -164,6 +165,7 @@ static inline void spmi_driver_unregister(struct spmi_driver *sdrv)
>  	module_driver(__spmi_driver, spmi_driver_register, \
>  			spmi_driver_unregister)
>  
> +inline struct spmi_device *spmi_device_from_of(struct device_node *np);
>  int spmi_register_read(struct spmi_device *sdev, u8 addr, u8 *buf);
>  int spmi_ext_register_read(struct spmi_device *sdev, u8 addr, u8 *buf,
>  			   size_t len);

Jonathan Cameron Feb. 26, 2022, 5:11 p.m. UTC | #8

On Mon, 21 Feb 2022 22:07:36 +0000
Caleb Connolly <caleb.connolly@linaro.org> wrote:

> Some PMIC functions such as the RRADC need to be aware of the PMIC
> chip revision information to implement errata or otherwise adjust
> behaviour, export the PMIC information to enable this.
> 
> This is specifically required to enable the RRADC to adjust
> coefficients based on which chip fab the PMIC was produced in,
> this can vary per unique device and therefore has to be read at
> runtime.
> 
> [bugs in previous revision]
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

Hi Caleb,

One trivial question about a comment below.

Otherwise, looking for mfd ack from Lee.

Is anyone actively maintaining mfd/qcom-spmi-pmic.c?
If some one at least familiar with that code (Bjorn or Stephen maybe?)
could take a quick look that would also be great.

Thanks,

Jonathan


> ---
>  drivers/mfd/qcom-spmi-pmic.c      | 174 ++++++++++++++++++++----------
>  include/soc/qcom/qcom-spmi-pmic.h |  60 +++++++++++
>  2 files changed, 178 insertions(+), 56 deletions(-)
>  create mode 100644 include/soc/qcom/qcom-spmi-pmic.h
> 
> diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c
> index 1cacc00aa6c9..1ef426a1513b 100644
> --- a/drivers/mfd/qcom-spmi-pmic.c
> +++ b/drivers/mfd/qcom-spmi-pmic.c
> @@ -3,11 +3,16 @@
>   * Copyright (c) 2014, The Linux Foundation. All rights reserved.
>   */
>  
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/gfp.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/spmi.h>
> +#include <linux/types.h>
>  #include <linux/regmap.h>
>  #include <linux/of_platform.h>
> +#include <soc/qcom/qcom-spmi-pmic.h>
>  
>  #define PMIC_REV2		0x101
>  #define PMIC_REV3		0x102
> @@ -17,37 +22,6 @@
>  
>  #define PMIC_TYPE_VALUE		0x51
>  
> -#define COMMON_SUBTYPE		0x00
> -#define PM8941_SUBTYPE		0x01
> -#define PM8841_SUBTYPE		0x02
> -#define PM8019_SUBTYPE		0x03
> -#define PM8226_SUBTYPE		0x04
> -#define PM8110_SUBTYPE		0x05
> -#define PMA8084_SUBTYPE		0x06
> -#define PMI8962_SUBTYPE		0x07
> -#define PMD9635_SUBTYPE		0x08
> -#define PM8994_SUBTYPE		0x09
> -#define PMI8994_SUBTYPE		0x0a
> -#define PM8916_SUBTYPE		0x0b
> -#define PM8004_SUBTYPE		0x0c
> -#define PM8909_SUBTYPE		0x0d
> -#define PM8028_SUBTYPE		0x0e
> -#define PM8901_SUBTYPE		0x0f
> -#define PM8950_SUBTYPE		0x10
> -#define PMI8950_SUBTYPE		0x11
> -#define PM8998_SUBTYPE		0x14
> -#define PMI8998_SUBTYPE		0x15
> -#define PM8005_SUBTYPE		0x18
> -#define PM660L_SUBTYPE		0x1A
> -#define PM660_SUBTYPE		0x1B
> -#define PM8150_SUBTYPE		0x1E
> -#define PM8150L_SUBTYPE		0x1f
> -#define PM8150B_SUBTYPE		0x20
> -#define PMK8002_SUBTYPE		0x21
> -#define PM8009_SUBTYPE		0x24
> -#define PM8150C_SUBTYPE		0x26
> -#define SMB2351_SUBTYPE		0x29
> -
>  static const struct of_device_id pmic_spmi_id_table[] = {
>  	{ .compatible = "qcom,pm660",     .data = (void *)PM660_SUBTYPE },
>  	{ .compatible = "qcom,pm660l",    .data = (void *)PM660L_SUBTYPE },
> @@ -81,42 +55,118 @@ static const struct of_device_id pmic_spmi_id_table[] = {
>  	{ }
>  };
>  
> -static void pmic_spmi_show_revid(struct regmap *map, struct device *dev)
> +/**
> + * qcom_pmic_get() - Get a pointer to the base PMIC device
> + *
> + * @dev: the pmic function device
> + * @return: the struct qcom_spmi_pmic* pointer associated with the function device
> + *
> + * A PMIC can be represented by multiple SPMI devices, but
> + * only the base PMIC device will contain a reference to
> + * the revision information.
> + *
> + * This function takes a pointer to a function device and
> + * returns a pointer to the base PMIC device.
> + */
> +const struct qcom_spmi_pmic *qcom_pmic_get(struct device *dev)
> +{
> +	struct spmi_device *sdev;
> +	struct device_node *spmi_bus;
> +	struct device_node *other_usid = NULL;
> +	int function_parent_usid, ret;
> +	u32 reg[2];
> +
> +	if (!of_match_device(pmic_spmi_id_table, dev->parent))
> +		return ERR_PTR(-EINVAL);
> +
> +	sdev = to_spmi_device(dev->parent);
> +	if (!sdev)
> +		return ERR_PTR(-EINVAL);
> +
> +	/*
> +	 * Quick return if the function device is already in the right
> +	 * USID
> +	 */
> +	if (sdev->usid % 2 == 0)
> +		return spmi_device_get_drvdata(sdev);
> +
> +	function_parent_usid = sdev->usid;
> +
> +	/*
> +	 * Walk through the list of PMICs until we find the sibling USID.
> +	 * The goal is the find to previous sibling. Assuming there is no

Probably:  The goal is to find the previous sibling. ?

> +	 * PMIC with more than 2 USIDs. We know that function_parent_usid
> +	 * is one greater than the base USID.
> +	 */
> +	spmi_bus = of_get_parent(sdev->dev.parent->of_node);
> +	do {
> +		other_usid = of_get_next_child(spmi_bus, other_usid);
> +		ret = of_property_read_u32_array(other_usid, "reg", reg, 2);
> +		if (ret)
> +			return ERR_PTR(ret);
> +		sdev = spmi_device_from_of(other_usid);
> +		if (sdev == NULL) {
> +			/*
> +			 * If the base USID for this PMIC hasn't probed yet
> +			 * but the secondary USID has, then we need to defer
> +			 * the function driver so that it will attempt to
> +			 * probe again when the base USID is ready.
> +			 */
> +			if (reg[0] == function_parent_usid - 1)
> +				return ERR_PTR(-EPROBE_DEFER);
> +
> +			continue;
> +		}
> +
> +		if (reg[0] == function_parent_usid - 1)
> +			return spmi_device_get_drvdata(sdev);
> +	} while (other_usid->sibling);
> +
> +	return ERR_PTR(-ENODATA);
> +}
> +EXPORT_SYMBOL(qcom_pmic_get);
> +
> +static inline void pmic_print_info(struct device *dev, struct qcom_spmi_pmic *pmic)
> +{
> +	dev_dbg(dev, "%x: %s v%d.%d\n",
> +		pmic->subtype, pmic->name, pmic->major, pmic->minor);
> +}
> +
> +static int pmic_spmi_load_revid(struct regmap *map, struct device *dev,
> +				 struct qcom_spmi_pmic *pmic)
>  {
> -	unsigned int rev2, minor, major, type, subtype;
> -	const char *name = "unknown";
>  	int ret, i;
>  
> -	ret = regmap_read(map, PMIC_TYPE, &type);
> +	ret = regmap_read(map, PMIC_TYPE, &pmic->type);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
> -	if (type != PMIC_TYPE_VALUE)
> -		return;
> +	if (pmic->type != PMIC_TYPE_VALUE)
> +		return ret;
>  
> -	ret = regmap_read(map, PMIC_SUBTYPE, &subtype);
> +	ret = regmap_read(map, PMIC_SUBTYPE, &pmic->subtype);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
>  	for (i = 0; i < ARRAY_SIZE(pmic_spmi_id_table); i++) {
> -		if (subtype == (unsigned long)pmic_spmi_id_table[i].data)
> +		if (pmic->subtype == (unsigned long)pmic_spmi_id_table[i].data)
>  			break;
>  	}
>  
>  	if (i != ARRAY_SIZE(pmic_spmi_id_table))
> -		name = pmic_spmi_id_table[i].compatible;
> +		pmic->name = devm_kstrdup_const(dev, pmic_spmi_id_table[i].compatible, GFP_KERNEL);
>  
> -	ret = regmap_read(map, PMIC_REV2, &rev2);
> +	ret = regmap_read(map, PMIC_REV2, &pmic->rev2);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
> -	ret = regmap_read(map, PMIC_REV3, &minor);
> +	ret = regmap_read(map, PMIC_REV3, &pmic->minor);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
> -	ret = regmap_read(map, PMIC_REV4, &major);
> +	ret = regmap_read(map, PMIC_REV4, &pmic->major);
>  	if (ret < 0)
> -		return;
> +		return ret;
>  
>  	/*
>  	 * In early versions of PM8941 and PM8226, the major revision number
> @@ -124,14 +174,16 @@ static void pmic_spmi_show_revid(struct regmap *map, struct device *dev)
>  	 * Increment the major revision number here if the chip is an early
>  	 * version of PM8941 or PM8226.
>  	 */
> -	if ((subtype == PM8941_SUBTYPE || subtype == PM8226_SUBTYPE) &&
> -	    major < 0x02)
> -		major++;
> +	if ((pmic->subtype == PM8941_SUBTYPE || pmic->subtype == PM8226_SUBTYPE) &&
> +	    pmic->major < 0x02)
> +		pmic->major++;
> +
> +	if (pmic->subtype == PM8110_SUBTYPE)
> +		pmic->minor = pmic->rev2;
>  
> -	if (subtype == PM8110_SUBTYPE)
> -		minor = rev2;
> +	pmic_print_info(dev, pmic);
>  
> -	dev_dbg(dev, "%x: %s v%d.%d\n", subtype, name, major, minor);
> +	return 0;
>  }
>  
>  static const struct regmap_config spmi_regmap_config = {
> @@ -144,14 +196,24 @@ static const struct regmap_config spmi_regmap_config = {
>  static int pmic_spmi_probe(struct spmi_device *sdev)
>  {
>  	struct regmap *regmap;
> +	struct qcom_spmi_pmic *pmic;
> +	int ret;
>  
>  	regmap = devm_regmap_init_spmi_ext(sdev, &spmi_regmap_config);
>  	if (IS_ERR(regmap))
>  		return PTR_ERR(regmap);
>  
> +	pmic = devm_kzalloc(&sdev->dev, sizeof(*pmic), GFP_KERNEL);
> +	if (!pmic)
> +		return -ENOMEM;
> +
>  	/* Only the first slave id for a PMIC contains this information */
> -	if (sdev->usid % 2 == 0)
> -		pmic_spmi_show_revid(regmap, &sdev->dev);
> +	if (sdev->usid % 2 == 0) {
> +		ret = pmic_spmi_load_revid(regmap, &sdev->dev, pmic);
> +		if (ret < 0)
> +			return ret;
> +		spmi_device_set_drvdata(sdev, pmic);
> +	}
>  
>  	return devm_of_platform_populate(&sdev->dev);
>  }
> diff --git a/include/soc/qcom/qcom-spmi-pmic.h b/include/soc/qcom/qcom-spmi-pmic.h
> new file mode 100644
> index 000000000000..a8a77be22cfc
> --- /dev/null
> +++ b/include/soc/qcom/qcom-spmi-pmic.h
> @@ -0,0 +1,60 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Copyright (c) 2021 Linaro. All rights reserved.
> + * Copyright (c) 2021 Caleb Connolly <caleb.connolly@linaro.org>
> + */
> +
> +#ifndef __QCOM_PMIC_H__
> +#define __QCOM_PMIC_H__
> +
> +#define COMMON_SUBTYPE		0x00
> +#define PM8941_SUBTYPE		0x01
> +#define PM8841_SUBTYPE		0x02
> +#define PM8019_SUBTYPE		0x03
> +#define PM8226_SUBTYPE		0x04
> +#define PM8110_SUBTYPE		0x05
> +#define PMA8084_SUBTYPE		0x06
> +#define PMI8962_SUBTYPE		0x07
> +#define PMD9635_SUBTYPE		0x08
> +#define PM8994_SUBTYPE		0x09
> +#define PMI8994_SUBTYPE		0x0a
> +#define PM8916_SUBTYPE		0x0b
> +#define PM8004_SUBTYPE		0x0c
> +#define PM8909_SUBTYPE		0x0d
> +#define PM8028_SUBTYPE		0x0e
> +#define PM8901_SUBTYPE		0x0f
> +#define PM8950_SUBTYPE		0x10
> +#define PMI8950_SUBTYPE		0x11
> +#define PM8998_SUBTYPE		0x14
> +#define PMI8998_SUBTYPE		0x15
> +#define PM8005_SUBTYPE		0x18
> +#define PM660L_SUBTYPE		0x1A
> +#define PM660_SUBTYPE		0x1B
> +#define PM8150_SUBTYPE		0x1E
> +#define PM8150L_SUBTYPE		0x1f
> +#define PM8150B_SUBTYPE		0x20
> +#define PMK8002_SUBTYPE		0x21
> +#define PM8009_SUBTYPE		0x24
> +#define PM8150C_SUBTYPE		0x26
> +#define SMB2351_SUBTYPE		0x29
> +
> +#define PMI8998_FAB_ID_SMIC	0x11
> +#define PMI8998_FAB_ID_GF	0x30
> +
> +#define PM660_FAB_ID_GF		0x0
> +#define PM660_FAB_ID_TSMC	0x2
> +#define PM660_FAB_ID_MX		0x3
> +
> +struct qcom_spmi_pmic {
> +	unsigned int type;
> +	unsigned int subtype;
> +	unsigned int major;
> +	unsigned int minor;
> +	unsigned int rev2;
> +	const char *name;
> +};
> +
> +struct device;
> +
> +const struct qcom_spmi_pmic *qcom_pmic_get(struct device *dev);
> +
> +#endif /* __QCOM_PMIC_H__ */

Jonathan Cameron Feb. 26, 2022, 5:35 p.m. UTC | #9

On Mon, 21 Feb 2022 22:07:39 +0000
Caleb Connolly <caleb.connolly@linaro.org> wrote:

> The Round Robin ADC is responsible for reading data about the rate of
> charge from the USB or DC input ports, it can also read the battery
> ID (resistence), skin temperature and the die temperature of the pmic.
> It is found on the PMI8998 and PM660 Qualcomm PMICs.
> 
> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

Hi Calib,

Unfortunately this fell for the normal rule that everytime someone
rereads some code they'll find something new :(

All minor stuff though so fingers crossed for v9.
The endian stuff isn't strictly necessary but it is always better to use explicit
endian types where possible as it hardens the code against forgetting to convert
them etc.

Jonathan

> ---


> diff --git a/drivers/iio/adc/qcom-spmi-rradc.c b/drivers/iio/adc/qcom-spmi-rradc.c
> new file mode 100644
> index 000000000000..f69d95103c82
> --- /dev/null
> +++ b/drivers/iio/adc/qcom-spmi-rradc.c
> @@ -0,0 +1,1011 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2022 Linaro Limited.
> + *  Author: Caleb Connolly <caleb.connolly@linaro.org>
> + *
> + * This driver is for the Round Robin ADC found in the pmi8998 and pm660 PMICs.
> + */

...

> +static const int batt_id_delays[] = { 0, 1, 4, 12, 20, 40, 60, 80 };
> +static const struct rradc_channel rradc_chans[RR_ADC_CHAN_MAX];
> +static const struct iio_chan_spec rradc_iio_chans[RR_ADC_CHAN_MAX];
> +
> +static int rradc_read(struct rradc_chip *chip, u16 addr, u8 *data, int len)

This function is only ever called in paths which then convert *data to le16.
As such, pass in __le16 *buf
regmap_bulk_read() takes a void * so that will work fine without casting.
The size should still be bytes to reflect that we are reading multiple 8 bit
registers.

> +{
> +	int ret, retry_cnt = 0;
> +	u8 data_check[RR_ADC_CHAN_MAX_CONTINUOUS_BUFFER_LEN];
elegance would make this __le16 as well but that probably doesn't matter.

Possibly you'll have to do something a bit clever at the memcmp to force
dropping of the endian markings - build with C=1, W=1 and see if it complains.

> +
> +	if (len > RR_ADC_CHAN_MAX_CONTINUOUS_BUFFER_LEN) {
> +		dev_err(chip->dev,
> +			"Can't read more than %d bytes, but asked to read %d bytes.\n",
> +			RR_ADC_CHAN_MAX_CONTINUOUS_BUFFER_LEN, len);
> +		return -EINVAL;
> +	}
> +
> +	while (retry_cnt < RR_ADC_COHERENT_CHECK_RETRY) {
> +		ret = regmap_bulk_read(chip->regmap, chip->base + addr, data,
> +				       len);
> +		if (ret < 0) {
> +			dev_err(chip->dev, "rr_adc reg 0x%x failed :%d\n", addr,
> +				ret);
> +			return ret;
> +		}
> +
> +		ret = regmap_bulk_read(chip->regmap, chip->base + addr,
> +				       data_check, len);
> +		if (ret < 0) {
> +			dev_err(chip->dev, "rr_adc reg 0x%x failed :%d\n", addr,
> +				ret);
> +			return ret;
> +		}
> +
> +		if (memcmp(data, data_check, len) != 0) {
> +			retry_cnt++;
> +			dev_dbg(chip->dev,
> +				"coherent read error, retry_cnt:%d\n",
> +				retry_cnt);
> +			continue;
> +		}
> +
> +		break;
> +	}
> +
> +	if (retry_cnt == RR_ADC_COHERENT_CHECK_RETRY)
> +		dev_err(chip->dev, "Retry exceeded for coherrency check\n");
> +
> +	return ret;
> +}
> +

> +static int rradc_do_conversion(struct rradc_chip *chip,
> +			       enum rradc_channel_id chan_address, u16 *data)
> +{
> +	const struct rradc_channel *chan = &rradc_chans[chan_address];
> +	const struct iio_chan_spec *iio_chan = &rradc_iio_chans[chan_address];
> +	int ret;
> +	u8 buf[6];

I missed this until now, but buf is only ever used as __le16 buf[3]
so give it that type and you can use
le16_to_cpu() as it will be aligned.

 
> +
> +	mutex_lock(&chip->conversion_lock);
> +
> +	switch (chan_address) {
> +	case RR_ADC_BATT_ID:
> +		ret = rradc_prepare_batt_id_conversion(chip, chan_address, data);
> +		if (ret < 0) {
> +			dev_err(chip->dev, "Battery ID conversion failed:%d\n",
> +				ret);
> +			goto unlock_out;
> +		}
> +		break;
> +
> +	case RR_ADC_USBIN_V:
> +	case RR_ADC_DIE_TEMP:
> +		ret = rradc_read_status_in_cont_mode(chip, chan_address);
> +		if (ret < 0) {
> +			dev_err(chip->dev,
> +				"Error reading in continuous mode:%d\n", ret);
> +			goto unlock_out;
> +		}
> +		break;
> +	default:
> +		if (!rradc_is_ready(chip, chan_address)) {
> +			/*
> +			 * Usually this means the channel isn't attached, for example
> +			 * the in_voltage_usbin_v_input channel will not be ready if
> +			 * no USB cable is attached
> +			 */
> +			dev_dbg(chip->dev, "channel '%s' is not ready\n",
> +				iio_chan->extend_name);
> +			ret = -ENODATA;
> +			goto unlock_out;
> +		}
> +		break;
> +	}
> +
> +	ret = rradc_read(chip, chan->lsb, buf, chan->size);
> +	if (ret) {
> +		dev_err(chip->dev, "read data failed\n");
> +		goto unlock_out;
> +	}
> +
> +	/*
> +	 * For the battery ID we read the register for every ID ADC and then
> +	 * see which one is actually connected.
> +	 */
> +	if (chan_address == RR_ADC_BATT_ID) {
> +		u16 batt_id_150 = get_unaligned_le16(buf + 4);
> +		u16 batt_id_15 = get_unaligned_le16(buf + 2);
> +		u16 batt_id_5 = get_unaligned_le16(buf);
> +
> +		if (!batt_id_150 && !batt_id_15 && !batt_id_5) {
> +			dev_err(chip->dev,
> +				"Invalid batt_id values with all zeros\n");
> +			ret = -EINVAL;
> +			goto unlock_out;
> +		}
> +
> +		if (batt_id_150 <= RR_ADC_BATT_ID_RANGE) {
> +			*data = batt_id_150;
> +			chip->batt_id_data = 150;
> +		} else if (batt_id_15 <= RR_ADC_BATT_ID_RANGE) {
> +			*data = batt_id_15;
> +			chip->batt_id_data = 15;
> +		} else {
> +			*data = batt_id_5;
> +			chip->batt_id_data = 5;
> +		}
> +	} else {
> +		/*
> +		 * All of the other channels are either 1 or 2 bytes.
> +		 * We can rely on the second byte being 0 for 1-byte channels.
> +		 */
> +		*data = get_unaligned_le16(buf);
> +	}
> +
> +unlock_out:
> +	mutex_unlock(&chip->conversion_lock);
> +
> +	return ret;
> +}
> +

...


> +
> +static int rradc_read_raw(struct iio_dev *indio_dev,
> +			  struct iio_chan_spec const *chan_spec, int *val,
> +			  int *val2, long mask)
> +{
> +	struct rradc_chip *chip = iio_priv(indio_dev);
> +	const struct rradc_channel *chan;
> +	int ret;
> +	u16 adc_code;
> +
> +	if (chan_spec->address >= RR_ADC_CHAN_MAX) {
> +		dev_err(chip->dev, "Invalid channel index:%lu\n",
> +			chan_spec->address);
> +		return -EINVAL;
> +	}
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_SCALE:
> +		return rradc_read_scale(chip, chan_spec->address, val, val2);
> +	case IIO_CHAN_INFO_OFFSET:
> +		return rradc_read_offset(chip, chan_spec->address, val);
> +	case IIO_CHAN_INFO_RAW:
> +		chan = &rradc_chans[chan_spec->address];

chan unused in this case statement.

> +		ret = rradc_do_conversion(chip, chan_spec->address, &adc_code);
> +		if (ret < 0)
> +			return ret;
> +
> +		*val = adc_code;
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_PROCESSED:
> +		chan = &rradc_chans[chan_spec->address];
> +		if (!chan->scale_fn)
> +			return -EINVAL;
> +		ret = rradc_do_conversion(chip, chan_spec->address, &adc_code);
> +		if (ret < 0)
> +			return ret;
> +
> +		*val = chan->scale_fn(chip, adc_code, val);
> +		return IIO_VAL_INT;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +

...

> +static const struct iio_chan_spec rradc_iio_chans[RR_ADC_CHAN_MAX] = {
> +	{
> +		.type = IIO_RESISTANCE,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> +		.address = RR_ADC_BATT_ID,
> +		.channel = 0,
> +		.indexed = 1,
> +	}, {
> +		.type = IIO_TEMP,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> +		.address = RR_ADC_BATT_THERM,
> +		.channel = 0,
> +		.indexed = 1,
> +	}, {
> +		.type = IIO_TEMP,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE) |
> +				      BIT(IIO_CHAN_INFO_OFFSET),
> +		.address = RR_ADC_SKIN_TEMP,
> +		.channel = 1,
> +		.indexed = 1,
> +	}, {
> +		.type = IIO_CURRENT,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE),
> +		.address = RR_ADC_USBIN_I,
> +		.channel = 0,
> +		.indexed = 1,
> +	}, {
> +		.type = IIO_VOLTAGE,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +			BIT(IIO_CHAN_INFO_SCALE),

Inconsistent indenting vs the other similar cases.

> +		.address = RR_ADC_USBIN_V,
> +		.channel = 0,
> +		.indexed = 1,
> +	}, {
> +		.type = IIO_CURRENT,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE),
> +		.address = RR_ADC_DCIN_I,
> +		.channel = 1,
> +		.indexed = 1,
> +	}, {
> +		.type = IIO_VOLTAGE,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE),
> +		.address = RR_ADC_DCIN_V,
> +		.channel = 1,
> +		.indexed = 1,
> +	}, {
> +		.type = IIO_TEMP,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE) |
> +				      BIT(IIO_CHAN_INFO_OFFSET),
> +		.address = RR_ADC_DIE_TEMP,
> +		.channel = 2,
> +		.indexed = 1,
> +	}, {
> +		.type = IIO_TEMP,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_OFFSET) |
> +				      BIT(IIO_CHAN_INFO_SCALE),
> +		.address = RR_ADC_CHG_TEMP,
> +		.channel = 3,
> +		.indexed = 1,
> +	}, {
> +		.type = IIO_VOLTAGE,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE),
> +		.address = RR_ADC_GPIO,
> +		.channel = 2,
> +		.indexed = 1,
> +	},
> +};
> +
> +static int rradc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct iio_dev *indio_dev;
> +	struct rradc_chip *chip;
> +	int ret, i, batt_id_delay;
> +
> +	indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	chip = iio_priv(indio_dev);
> +	chip->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> +	if (!chip->regmap) {
> +		dev_err(dev, "Couldn't get parent's regmap\n");
> +		return -EINVAL;
> +	}
> +
> +	chip->dev = dev;
> +	mutex_init(&chip->conversion_lock);
> +
> +	ret = device_property_read_u32(dev, "reg", &chip->base);
> +	if (ret < 0) {
> +		dev_err(chip->dev, "Couldn't find reg address, ret = %d\n",
> +			ret);
> +		return ret;
> +	}
> +
> +	batt_id_delay = -1;
> +	ret = device_property_read_u32(dev, "qcom,batt-id-delay-ms",
> +				       &batt_id_delay);
> +	if (!ret) {
> +		for (i = 0; i < RRADC_BATT_ID_DELAY_MAX; i++) {
> +			if (batt_id_delay == batt_id_delays[i])
> +				break;
> +		}
> +		if (i == RRADC_BATT_ID_DELAY_MAX)
> +			batt_id_delay = -1;
> +	}
> +
> +	if (batt_id_delay >= 0) {
> +		batt_id_delay = FIELD_PREP(BATT_ID_SETTLE_MASK, batt_id_delay);
> +		ret = regmap_update_bits(chip->regmap,
> +					 chip->base + RR_ADC_BATT_ID_CFG,
> +					 batt_id_delay, batt_id_delay);
> +		if (ret < 0) {
> +			dev_err(chip->dev,
> +				"BATT_ID settling time config failed:%d\n",
> +				ret);
> +		}
> +	}
> +
> +	/* Get the PMIC revision ID, we need to handle some varying coefficients */
> +	chip->pmic = qcom_pmic_get(chip->dev);
> +	if (IS_ERR(chip->pmic)) {
> +		dev_err(chip->dev, "Unable to get reference to PMIC device\n");
> +		return PTR_ERR(chip->pmic);
> +	}
> +
> +	indio_dev->name = DRIVER_NAME;

I missed this in earlier versions, but this should be the specific
part number if possible, so probably
pm660-rradc / pmi8998-rradc as appropriate.
You can set it based on chip->pmic->sub_type I think


> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->info = &rradc_info;
> +	indio_dev->channels = rradc_iio_chans;
> +	indio_dev->num_channels = ARRAY_SIZE(rradc_iio_chans);
> +
> +	return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static const struct of_device_id rradc_match_table[] = {
> +	{ .compatible = "qcom,pm660-rradc" },
> +	{ .compatible = "qcom,pmi8998-rradc" },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, rradc_match_table);
> +
> +static struct platform_driver rradc_driver = {
> +	.driver		= {
> +		.name		= DRIVER_NAME,
> +		.of_match_table	= rradc_match_table,
> +	},
> +	.probe = rradc_probe,
> +};
> +module_platform_driver(rradc_driver);
> +
> +MODULE_DESCRIPTION("QCOM SPMI PMIC RR ADC driver");
> +MODULE_AUTHOR("Caleb Connolly <caleb.connolly@linaro.org>");
> +MODULE_LICENSE("GPL v2");

Jonathan Cameron Feb. 26, 2022, 5:36 p.m. UTC | #10

On Sat, 26 Feb 2022 17:35:35 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Mon, 21 Feb 2022 22:07:39 +0000
> Caleb Connolly <caleb.connolly@linaro.org> wrote:
> 
> > The Round Robin ADC is responsible for reading data about the rate of
> > charge from the USB or DC input ports, it can also read the battery
> > ID (resistence), skin temperature and the die temperature of the pmic.
> > It is found on the PMI8998 and PM660 Qualcomm PMICs.
> > 
> > Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>  
> 
> Hi Calib,

Caleb that is. Sorry!

> 
> Unfortunately this fell for the normal rule that everytime someone
> rereads some code they'll find something new :(
> 
> All minor stuff though so fingers crossed for v9.
> The endian stuff isn't strictly necessary but it is always better to use explicit
> endian types where possible as it hardens the code against forgetting to convert
> them etc.
> 
> Jonathan
> 
> > ---  
> 
> 
> > diff --git a/drivers/iio/adc/qcom-spmi-rradc.c b/drivers/iio/adc/qcom-spmi-rradc.c
> > new file mode 100644
> > index 000000000000..f69d95103c82
> > --- /dev/null
> > +++ b/drivers/iio/adc/qcom-spmi-rradc.c
> > @@ -0,0 +1,1011 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2022 Linaro Limited.
> > + *  Author: Caleb Connolly <caleb.connolly@linaro.org>
> > + *
> > + * This driver is for the Round Robin ADC found in the pmi8998 and pm660 PMICs.
> > + */  
> 
> ...
> 
> > +static const int batt_id_delays[] = { 0, 1, 4, 12, 20, 40, 60, 80 };
> > +static const struct rradc_channel rradc_chans[RR_ADC_CHAN_MAX];
> > +static const struct iio_chan_spec rradc_iio_chans[RR_ADC_CHAN_MAX];
> > +
> > +static int rradc_read(struct rradc_chip *chip, u16 addr, u8 *data, int len)  
> 
> This function is only ever called in paths which then convert *data to le16.
> As such, pass in __le16 *buf
> regmap_bulk_read() takes a void * so that will work fine without casting.
> The size should still be bytes to reflect that we are reading multiple 8 bit
> registers.
> 
> > +{
> > +	int ret, retry_cnt = 0;
> > +	u8 data_check[RR_ADC_CHAN_MAX_CONTINUOUS_BUFFER_LEN];  
> elegance would make this __le16 as well but that probably doesn't matter.
> 
> Possibly you'll have to do something a bit clever at the memcmp to force
> dropping of the endian markings - build with C=1, W=1 and see if it complains.
> 
> > +
> > +	if (len > RR_ADC_CHAN_MAX_CONTINUOUS_BUFFER_LEN) {
> > +		dev_err(chip->dev,
> > +			"Can't read more than %d bytes, but asked to read %d bytes.\n",
> > +			RR_ADC_CHAN_MAX_CONTINUOUS_BUFFER_LEN, len);
> > +		return -EINVAL;
> > +	}
> > +
> > +	while (retry_cnt < RR_ADC_COHERENT_CHECK_RETRY) {
> > +		ret = regmap_bulk_read(chip->regmap, chip->base + addr, data,
> > +				       len);
> > +		if (ret < 0) {
> > +			dev_err(chip->dev, "rr_adc reg 0x%x failed :%d\n", addr,
> > +				ret);
> > +			return ret;
> > +		}
> > +
> > +		ret = regmap_bulk_read(chip->regmap, chip->base + addr,
> > +				       data_check, len);
> > +		if (ret < 0) {
> > +			dev_err(chip->dev, "rr_adc reg 0x%x failed :%d\n", addr,
> > +				ret);
> > +			return ret;
> > +		}
> > +
> > +		if (memcmp(data, data_check, len) != 0) {
> > +			retry_cnt++;
> > +			dev_dbg(chip->dev,
> > +				"coherent read error, retry_cnt:%d\n",
> > +				retry_cnt);
> > +			continue;
> > +		}
> > +
> > +		break;
> > +	}
> > +
> > +	if (retry_cnt == RR_ADC_COHERENT_CHECK_RETRY)
> > +		dev_err(chip->dev, "Retry exceeded for coherrency check\n");
> > +
> > +	return ret;
> > +}
> > +  
> 
> > +static int rradc_do_conversion(struct rradc_chip *chip,
> > +			       enum rradc_channel_id chan_address, u16 *data)
> > +{
> > +	const struct rradc_channel *chan = &rradc_chans[chan_address];
> > +	const struct iio_chan_spec *iio_chan = &rradc_iio_chans[chan_address];
> > +	int ret;
> > +	u8 buf[6];  
> 
> I missed this until now, but buf is only ever used as __le16 buf[3]
> so give it that type and you can use
> le16_to_cpu() as it will be aligned.
> 
>  
> > +
> > +	mutex_lock(&chip->conversion_lock);
> > +
> > +	switch (chan_address) {
> > +	case RR_ADC_BATT_ID:
> > +		ret = rradc_prepare_batt_id_conversion(chip, chan_address, data);
> > +		if (ret < 0) {
> > +			dev_err(chip->dev, "Battery ID conversion failed:%d\n",
> > +				ret);
> > +			goto unlock_out;
> > +		}
> > +		break;
> > +
> > +	case RR_ADC_USBIN_V:
> > +	case RR_ADC_DIE_TEMP:
> > +		ret = rradc_read_status_in_cont_mode(chip, chan_address);
> > +		if (ret < 0) {
> > +			dev_err(chip->dev,
> > +				"Error reading in continuous mode:%d\n", ret);
> > +			goto unlock_out;
> > +		}
> > +		break;
> > +	default:
> > +		if (!rradc_is_ready(chip, chan_address)) {
> > +			/*
> > +			 * Usually this means the channel isn't attached, for example
> > +			 * the in_voltage_usbin_v_input channel will not be ready if
> > +			 * no USB cable is attached
> > +			 */
> > +			dev_dbg(chip->dev, "channel '%s' is not ready\n",
> > +				iio_chan->extend_name);
> > +			ret = -ENODATA;
> > +			goto unlock_out;
> > +		}
> > +		break;
> > +	}
> > +
> > +	ret = rradc_read(chip, chan->lsb, buf, chan->size);
> > +	if (ret) {
> > +		dev_err(chip->dev, "read data failed\n");
> > +		goto unlock_out;
> > +	}
> > +
> > +	/*
> > +	 * For the battery ID we read the register for every ID ADC and then
> > +	 * see which one is actually connected.
> > +	 */
> > +	if (chan_address == RR_ADC_BATT_ID) {
> > +		u16 batt_id_150 = get_unaligned_le16(buf + 4);
> > +		u16 batt_id_15 = get_unaligned_le16(buf + 2);
> > +		u16 batt_id_5 = get_unaligned_le16(buf);
> > +
> > +		if (!batt_id_150 && !batt_id_15 && !batt_id_5) {
> > +			dev_err(chip->dev,
> > +				"Invalid batt_id values with all zeros\n");
> > +			ret = -EINVAL;
> > +			goto unlock_out;
> > +		}
> > +
> > +		if (batt_id_150 <= RR_ADC_BATT_ID_RANGE) {
> > +			*data = batt_id_150;
> > +			chip->batt_id_data = 150;
> > +		} else if (batt_id_15 <= RR_ADC_BATT_ID_RANGE) {
> > +			*data = batt_id_15;
> > +			chip->batt_id_data = 15;
> > +		} else {
> > +			*data = batt_id_5;
> > +			chip->batt_id_data = 5;
> > +		}
> > +	} else {
> > +		/*
> > +		 * All of the other channels are either 1 or 2 bytes.
> > +		 * We can rely on the second byte being 0 for 1-byte channels.
> > +		 */
> > +		*data = get_unaligned_le16(buf);
> > +	}
> > +
> > +unlock_out:
> > +	mutex_unlock(&chip->conversion_lock);
> > +
> > +	return ret;
> > +}
> > +  
> 
> ...
> 
> 
> > +
> > +static int rradc_read_raw(struct iio_dev *indio_dev,
> > +			  struct iio_chan_spec const *chan_spec, int *val,
> > +			  int *val2, long mask)
> > +{
> > +	struct rradc_chip *chip = iio_priv(indio_dev);
> > +	const struct rradc_channel *chan;
> > +	int ret;
> > +	u16 adc_code;
> > +
> > +	if (chan_spec->address >= RR_ADC_CHAN_MAX) {
> > +		dev_err(chip->dev, "Invalid channel index:%lu\n",
> > +			chan_spec->address);
> > +		return -EINVAL;
> > +	}
> > +
> > +	switch (mask) {
> > +	case IIO_CHAN_INFO_SCALE:
> > +		return rradc_read_scale(chip, chan_spec->address, val, val2);
> > +	case IIO_CHAN_INFO_OFFSET:
> > +		return rradc_read_offset(chip, chan_spec->address, val);
> > +	case IIO_CHAN_INFO_RAW:
> > +		chan = &rradc_chans[chan_spec->address];  
> 
> chan unused in this case statement.
> 
> > +		ret = rradc_do_conversion(chip, chan_spec->address, &adc_code);
> > +		if (ret < 0)
> > +			return ret;
> > +
> > +		*val = adc_code;
> > +		return IIO_VAL_INT;
> > +	case IIO_CHAN_INFO_PROCESSED:
> > +		chan = &rradc_chans[chan_spec->address];
> > +		if (!chan->scale_fn)
> > +			return -EINVAL;
> > +		ret = rradc_do_conversion(chip, chan_spec->address, &adc_code);
> > +		if (ret < 0)
> > +			return ret;
> > +
> > +		*val = chan->scale_fn(chip, adc_code, val);
> > +		return IIO_VAL_INT;
> > +	default:
> > +		return -EINVAL;
> > +	}
> > +}
> > +  
> 
> ...
> 
> > +static const struct iio_chan_spec rradc_iio_chans[RR_ADC_CHAN_MAX] = {
> > +	{
> > +		.type = IIO_RESISTANCE,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > +		.address = RR_ADC_BATT_ID,
> > +		.channel = 0,
> > +		.indexed = 1,
> > +	}, {
> > +		.type = IIO_TEMP,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > +		.address = RR_ADC_BATT_THERM,
> > +		.channel = 0,
> > +		.indexed = 1,
> > +	}, {
> > +		.type = IIO_TEMP,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > +				      BIT(IIO_CHAN_INFO_SCALE) |
> > +				      BIT(IIO_CHAN_INFO_OFFSET),
> > +		.address = RR_ADC_SKIN_TEMP,
> > +		.channel = 1,
> > +		.indexed = 1,
> > +	}, {
> > +		.type = IIO_CURRENT,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > +				      BIT(IIO_CHAN_INFO_SCALE),
> > +		.address = RR_ADC_USBIN_I,
> > +		.channel = 0,
> > +		.indexed = 1,
> > +	}, {
> > +		.type = IIO_VOLTAGE,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > +			BIT(IIO_CHAN_INFO_SCALE),  
> 
> Inconsistent indenting vs the other similar cases.
> 
> > +		.address = RR_ADC_USBIN_V,
> > +		.channel = 0,
> > +		.indexed = 1,
> > +	}, {
> > +		.type = IIO_CURRENT,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > +				      BIT(IIO_CHAN_INFO_SCALE),
> > +		.address = RR_ADC_DCIN_I,
> > +		.channel = 1,
> > +		.indexed = 1,
> > +	}, {
> > +		.type = IIO_VOLTAGE,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > +				      BIT(IIO_CHAN_INFO_SCALE),
> > +		.address = RR_ADC_DCIN_V,
> > +		.channel = 1,
> > +		.indexed = 1,
> > +	}, {
> > +		.type = IIO_TEMP,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > +				      BIT(IIO_CHAN_INFO_SCALE) |
> > +				      BIT(IIO_CHAN_INFO_OFFSET),
> > +		.address = RR_ADC_DIE_TEMP,
> > +		.channel = 2,
> > +		.indexed = 1,
> > +	}, {
> > +		.type = IIO_TEMP,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > +				      BIT(IIO_CHAN_INFO_OFFSET) |
> > +				      BIT(IIO_CHAN_INFO_SCALE),
> > +		.address = RR_ADC_CHG_TEMP,
> > +		.channel = 3,
> > +		.indexed = 1,
> > +	}, {
> > +		.type = IIO_VOLTAGE,
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > +				      BIT(IIO_CHAN_INFO_SCALE),
> > +		.address = RR_ADC_GPIO,
> > +		.channel = 2,
> > +		.indexed = 1,
> > +	},
> > +};
> > +
> > +static int rradc_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct iio_dev *indio_dev;
> > +	struct rradc_chip *chip;
> > +	int ret, i, batt_id_delay;
> > +
> > +	indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
> > +	if (!indio_dev)
> > +		return -ENOMEM;
> > +
> > +	chip = iio_priv(indio_dev);
> > +	chip->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> > +	if (!chip->regmap) {
> > +		dev_err(dev, "Couldn't get parent's regmap\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	chip->dev = dev;
> > +	mutex_init(&chip->conversion_lock);
> > +
> > +	ret = device_property_read_u32(dev, "reg", &chip->base);
> > +	if (ret < 0) {
> > +		dev_err(chip->dev, "Couldn't find reg address, ret = %d\n",
> > +			ret);
> > +		return ret;
> > +	}
> > +
> > +	batt_id_delay = -1;
> > +	ret = device_property_read_u32(dev, "qcom,batt-id-delay-ms",
> > +				       &batt_id_delay);
> > +	if (!ret) {
> > +		for (i = 0; i < RRADC_BATT_ID_DELAY_MAX; i++) {
> > +			if (batt_id_delay == batt_id_delays[i])
> > +				break;
> > +		}
> > +		if (i == RRADC_BATT_ID_DELAY_MAX)
> > +			batt_id_delay = -1;
> > +	}
> > +
> > +	if (batt_id_delay >= 0) {
> > +		batt_id_delay = FIELD_PREP(BATT_ID_SETTLE_MASK, batt_id_delay);
> > +		ret = regmap_update_bits(chip->regmap,
> > +					 chip->base + RR_ADC_BATT_ID_CFG,
> > +					 batt_id_delay, batt_id_delay);
> > +		if (ret < 0) {
> > +			dev_err(chip->dev,
> > +				"BATT_ID settling time config failed:%d\n",
> > +				ret);
> > +		}
> > +	}
> > +
> > +	/* Get the PMIC revision ID, we need to handle some varying coefficients */
> > +	chip->pmic = qcom_pmic_get(chip->dev);
> > +	if (IS_ERR(chip->pmic)) {
> > +		dev_err(chip->dev, "Unable to get reference to PMIC device\n");
> > +		return PTR_ERR(chip->pmic);
> > +	}
> > +
> > +	indio_dev->name = DRIVER_NAME;  
> 
> I missed this in earlier versions, but this should be the specific
> part number if possible, so probably
> pm660-rradc / pmi8998-rradc as appropriate.
> You can set it based on chip->pmic->sub_type I think
> 
> 
> > +	indio_dev->modes = INDIO_DIRECT_MODE;
> > +	indio_dev->info = &rradc_info;
> > +	indio_dev->channels = rradc_iio_chans;
> > +	indio_dev->num_channels = ARRAY_SIZE(rradc_iio_chans);
> > +
> > +	return devm_iio_device_register(dev, indio_dev);
> > +}
> > +
> > +static const struct of_device_id rradc_match_table[] = {
> > +	{ .compatible = "qcom,pm660-rradc" },
> > +	{ .compatible = "qcom,pmi8998-rradc" },
> > +	{}
> > +};
> > +MODULE_DEVICE_TABLE(of, rradc_match_table);
> > +
> > +static struct platform_driver rradc_driver = {
> > +	.driver		= {
> > +		.name		= DRIVER_NAME,
> > +		.of_match_table	= rradc_match_table,
> > +	},
> > +	.probe = rradc_probe,
> > +};
> > +module_platform_driver(rradc_driver);
> > +
> > +MODULE_DESCRIPTION("QCOM SPMI PMIC RR ADC driver");
> > +MODULE_AUTHOR("Caleb Connolly <caleb.connolly@linaro.org>");
> > +MODULE_LICENSE("GPL v2");  
>

Dmitry Baryshkov Feb. 26, 2022, 6:09 p.m. UTC | #11

On Tue, 22 Feb 2022 at 01:08, Caleb Connolly <caleb.connolly@linaro.org> wrote:
>
> Some PMIC functions such as the RRADC need to be aware of the PMIC
> chip revision information to implement errata or otherwise adjust
> behaviour, export the PMIC information to enable this.
>
> This is specifically required to enable the RRADC to adjust
> coefficients based on which chip fab the PMIC was produced in,
> this can vary per unique device and therefore has to be read at
> runtime.
>
> [bugs in previous revision]
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
> ---
>  drivers/mfd/qcom-spmi-pmic.c      | 174 ++++++++++++++++++++----------
>  include/soc/qcom/qcom-spmi-pmic.h |  60 +++++++++++
>  2 files changed, 178 insertions(+), 56 deletions(-)
>  create mode 100644 include/soc/qcom/qcom-spmi-pmic.h
>
> diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c
> index 1cacc00aa6c9..1ef426a1513b 100644
> --- a/drivers/mfd/qcom-spmi-pmic.c
> +++ b/drivers/mfd/qcom-spmi-pmic.c
> @@ -3,11 +3,16 @@
>   * Copyright (c) 2014, The Linux Foundation. All rights reserved.
>   */
>
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/gfp.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/spmi.h>
> +#include <linux/types.h>
>  #include <linux/regmap.h>
>  #include <linux/of_platform.h>
> +#include <soc/qcom/qcom-spmi-pmic.h>
>
>  #define PMIC_REV2              0x101
>  #define PMIC_REV3              0x102
> @@ -17,37 +22,6 @@
>
>  #define PMIC_TYPE_VALUE                0x51
>
> -#define COMMON_SUBTYPE         0x00
> -#define PM8941_SUBTYPE         0x01
> -#define PM8841_SUBTYPE         0x02
> -#define PM8019_SUBTYPE         0x03
> -#define PM8226_SUBTYPE         0x04
> -#define PM8110_SUBTYPE         0x05
> -#define PMA8084_SUBTYPE                0x06
> -#define PMI8962_SUBTYPE                0x07
> -#define PMD9635_SUBTYPE                0x08
> -#define PM8994_SUBTYPE         0x09
> -#define PMI8994_SUBTYPE                0x0a
> -#define PM8916_SUBTYPE         0x0b
> -#define PM8004_SUBTYPE         0x0c
> -#define PM8909_SUBTYPE         0x0d
> -#define PM8028_SUBTYPE         0x0e
> -#define PM8901_SUBTYPE         0x0f
> -#define PM8950_SUBTYPE         0x10
> -#define PMI8950_SUBTYPE                0x11
> -#define PM8998_SUBTYPE         0x14
> -#define PMI8998_SUBTYPE                0x15
> -#define PM8005_SUBTYPE         0x18
> -#define PM660L_SUBTYPE         0x1A
> -#define PM660_SUBTYPE          0x1B
> -#define PM8150_SUBTYPE         0x1E
> -#define PM8150L_SUBTYPE                0x1f
> -#define PM8150B_SUBTYPE                0x20
> -#define PMK8002_SUBTYPE                0x21
> -#define PM8009_SUBTYPE         0x24
> -#define PM8150C_SUBTYPE                0x26
> -#define SMB2351_SUBTYPE                0x29
> -
>  static const struct of_device_id pmic_spmi_id_table[] = {
>         { .compatible = "qcom,pm660",     .data = (void *)PM660_SUBTYPE },
>         { .compatible = "qcom,pm660l",    .data = (void *)PM660L_SUBTYPE },
> @@ -81,42 +55,118 @@ static const struct of_device_id pmic_spmi_id_table[] = {
>         { }
>  };
>
> -static void pmic_spmi_show_revid(struct regmap *map, struct device *dev)
> +/**
> + * qcom_pmic_get() - Get a pointer to the base PMIC device
> + *
> + * @dev: the pmic function device
> + * @return: the struct qcom_spmi_pmic* pointer associated with the function device
> + *
> + * A PMIC can be represented by multiple SPMI devices, but
> + * only the base PMIC device will contain a reference to
> + * the revision information.
> + *
> + * This function takes a pointer to a function device and
> + * returns a pointer to the base PMIC device.
> + */
> +const struct qcom_spmi_pmic *qcom_pmic_get(struct device *dev)
> +{
> +       struct spmi_device *sdev;
> +       struct device_node *spmi_bus;
> +       struct device_node *other_usid = NULL;
> +       int function_parent_usid, ret;
> +       u32 reg[2];
> +
> +       if (!of_match_device(pmic_spmi_id_table, dev->parent))
> +               return ERR_PTR(-EINVAL);
> +
> +       sdev = to_spmi_device(dev->parent);
> +       if (!sdev)
> +               return ERR_PTR(-EINVAL);
> +
> +       /*
> +        * Quick return if the function device is already in the right
> +        * USID
> +        */
> +       if (sdev->usid % 2 == 0)
> +               return spmi_device_get_drvdata(sdev);

> +
> +       function_parent_usid = sdev->usid;
> +
> +       /*
> +        * Walk through the list of PMICs until we find the sibling USID.
> +        * The goal is the find to previous sibling. Assuming there is no
> +        * PMIC with more than 2 USIDs. We know that function_parent_usid
> +        * is one greater than the base USID.
> +        */

I think this is not correct for newer platforms. On SM8450 we have
PMICs which do not share a pair of USIDs.
For example on sm8450-qrd:

PMK8350 @ 0
PM8350 @ 1
PM8350C @ 2
PM8350B @ 3
PMR735A @ 4
PMR735B @ 5
PM8450 @ 7

> +       spmi_bus = of_get_parent(sdev->dev.parent->of_node);
> +       do {
> +               other_usid = of_get_next_child(spmi_bus, other_usid);
> +               ret = of_property_read_u32_array(other_usid, "reg", reg, 2);
> +               if (ret)
> +                       return ERR_PTR(ret);
> +               sdev = spmi_device_from_of(other_usid);
> +               if (sdev == NULL) {
> +                       /*
> +                        * If the base USID for this PMIC hasn't probed yet
> +                        * but the secondary USID has, then we need to defer
> +                        * the function driver so that it will attempt to
> +                        * probe again when the base USID is ready.
> +                        */
> +                       if (reg[0] == function_parent_usid - 1)
> +                               return ERR_PTR(-EPROBE_DEFER);
> +
> +                       continue;
> +               }
> +
> +               if (reg[0] == function_parent_usid - 1)
> +                       return spmi_device_get_drvdata(sdev);
> +       } while (other_usid->sibling);
> +
> +       return ERR_PTR(-ENODATA);
> +}
> +EXPORT_SYMBOL(qcom_pmic_get);
> +
> +static inline void pmic_print_info(struct device *dev, struct qcom_spmi_pmic *pmic)
> +{
> +       dev_dbg(dev, "%x: %s v%d.%d\n",
> +               pmic->subtype, pmic->name, pmic->major, pmic->minor);
> +}
> +
> +static int pmic_spmi_load_revid(struct regmap *map, struct device *dev,
> +                                struct qcom_spmi_pmic *pmic)
>  {
> -       unsigned int rev2, minor, major, type, subtype;
> -       const char *name = "unknown";
>         int ret, i;
>
> -       ret = regmap_read(map, PMIC_TYPE, &type);
> +       ret = regmap_read(map, PMIC_TYPE, &pmic->type);
>         if (ret < 0)
> -               return;
> +               return ret;
>
> -       if (type != PMIC_TYPE_VALUE)
> -               return;
> +       if (pmic->type != PMIC_TYPE_VALUE)
> +               return ret;
>
> -       ret = regmap_read(map, PMIC_SUBTYPE, &subtype);
> +       ret = regmap_read(map, PMIC_SUBTYPE, &pmic->subtype);
>         if (ret < 0)
> -               return;
> +               return ret;
>
>         for (i = 0; i < ARRAY_SIZE(pmic_spmi_id_table); i++) {
> -               if (subtype == (unsigned long)pmic_spmi_id_table[i].data)
> +               if (pmic->subtype == (unsigned long)pmic_spmi_id_table[i].data)
>                         break;
>         }
>
>         if (i != ARRAY_SIZE(pmic_spmi_id_table))
> -               name = pmic_spmi_id_table[i].compatible;
> +               pmic->name = devm_kstrdup_const(dev, pmic_spmi_id_table[i].compatible, GFP_KERNEL);
>
> -       ret = regmap_read(map, PMIC_REV2, &rev2);
> +       ret = regmap_read(map, PMIC_REV2, &pmic->rev2);
>         if (ret < 0)
> -               return;
> +               return ret;
>
> -       ret = regmap_read(map, PMIC_REV3, &minor);
> +       ret = regmap_read(map, PMIC_REV3, &pmic->minor);
>         if (ret < 0)
> -               return;
> +               return ret;
>
> -       ret = regmap_read(map, PMIC_REV4, &major);
> +       ret = regmap_read(map, PMIC_REV4, &pmic->major);
>         if (ret < 0)
> -               return;
> +               return ret;
>
>         /*
>          * In early versions of PM8941 and PM8226, the major revision number
> @@ -124,14 +174,16 @@ static void pmic_spmi_show_revid(struct regmap *map, struct device *dev)
>          * Increment the major revision number here if the chip is an early
>          * version of PM8941 or PM8226.
>          */
> -       if ((subtype == PM8941_SUBTYPE || subtype == PM8226_SUBTYPE) &&
> -           major < 0x02)
> -               major++;
> +       if ((pmic->subtype == PM8941_SUBTYPE || pmic->subtype == PM8226_SUBTYPE) &&
> +           pmic->major < 0x02)
> +               pmic->major++;
> +
> +       if (pmic->subtype == PM8110_SUBTYPE)
> +               pmic->minor = pmic->rev2;
>
> -       if (subtype == PM8110_SUBTYPE)
> -               minor = rev2;
> +       pmic_print_info(dev, pmic);
>
> -       dev_dbg(dev, "%x: %s v%d.%d\n", subtype, name, major, minor);
> +       return 0;
>  }
>
>  static const struct regmap_config spmi_regmap_config = {
> @@ -144,14 +196,24 @@ static const struct regmap_config spmi_regmap_config = {
>  static int pmic_spmi_probe(struct spmi_device *sdev)
>  {
>         struct regmap *regmap;
> +       struct qcom_spmi_pmic *pmic;
> +       int ret;
>
>         regmap = devm_regmap_init_spmi_ext(sdev, &spmi_regmap_config);
>         if (IS_ERR(regmap))
>                 return PTR_ERR(regmap);
>
> +       pmic = devm_kzalloc(&sdev->dev, sizeof(*pmic), GFP_KERNEL);
> +       if (!pmic)
> +               return -ENOMEM;
> +
>         /* Only the first slave id for a PMIC contains this information */
> -       if (sdev->usid % 2 == 0)
> -               pmic_spmi_show_revid(regmap, &sdev->dev);
> +       if (sdev->usid % 2 == 0) {
> +               ret = pmic_spmi_load_revid(regmap, &sdev->dev, pmic);
> +               if (ret < 0)
> +                       return ret;
> +               spmi_device_set_drvdata(sdev, pmic);
> +       }
>
>         return devm_of_platform_populate(&sdev->dev);
>  }
> diff --git a/include/soc/qcom/qcom-spmi-pmic.h b/include/soc/qcom/qcom-spmi-pmic.h
> new file mode 100644
> index 000000000000..a8a77be22cfc
> --- /dev/null
> +++ b/include/soc/qcom/qcom-spmi-pmic.h
> @@ -0,0 +1,60 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Copyright (c) 2021 Linaro. All rights reserved.
> + * Copyright (c) 2021 Caleb Connolly <caleb.connolly@linaro.org>
> + */
> +
> +#ifndef __QCOM_PMIC_H__
> +#define __QCOM_PMIC_H__
> +
> +#define COMMON_SUBTYPE         0x00
> +#define PM8941_SUBTYPE         0x01
> +#define PM8841_SUBTYPE         0x02
> +#define PM8019_SUBTYPE         0x03
> +#define PM8226_SUBTYPE         0x04
> +#define PM8110_SUBTYPE         0x05
> +#define PMA8084_SUBTYPE                0x06
> +#define PMI8962_SUBTYPE                0x07
> +#define PMD9635_SUBTYPE                0x08
> +#define PM8994_SUBTYPE         0x09
> +#define PMI8994_SUBTYPE                0x0a
> +#define PM8916_SUBTYPE         0x0b
> +#define PM8004_SUBTYPE         0x0c
> +#define PM8909_SUBTYPE         0x0d
> +#define PM8028_SUBTYPE         0x0e
> +#define PM8901_SUBTYPE         0x0f
> +#define PM8950_SUBTYPE         0x10
> +#define PMI8950_SUBTYPE                0x11
> +#define PM8998_SUBTYPE         0x14
> +#define PMI8998_SUBTYPE                0x15
> +#define PM8005_SUBTYPE         0x18
> +#define PM660L_SUBTYPE         0x1A
> +#define PM660_SUBTYPE          0x1B
> +#define PM8150_SUBTYPE         0x1E
> +#define PM8150L_SUBTYPE                0x1f
> +#define PM8150B_SUBTYPE                0x20
> +#define PMK8002_SUBTYPE                0x21
> +#define PM8009_SUBTYPE         0x24
> +#define PM8150C_SUBTYPE                0x26
> +#define SMB2351_SUBTYPE                0x29
> +
> +#define PMI8998_FAB_ID_SMIC    0x11
> +#define PMI8998_FAB_ID_GF      0x30
> +
> +#define PM660_FAB_ID_GF                0x0
> +#define PM660_FAB_ID_TSMC      0x2
> +#define PM660_FAB_ID_MX                0x3
> +
> +struct qcom_spmi_pmic {
> +       unsigned int type;
> +       unsigned int subtype;
> +       unsigned int major;
> +       unsigned int minor;
> +       unsigned int rev2;
> +       const char *name;
> +};
> +
> +struct device;
> +
> +const struct qcom_spmi_pmic *qcom_pmic_get(struct device *dev);
> +
> +#endif /* __QCOM_PMIC_H__ */
> --
> 2.35.1
>

Caleb Connolly March 3, 2022, 2:20 a.m. UTC | #12

On 25/02/2022 09:40, Dan Carpenter wrote:
> On Fri, Feb 25, 2022 at 09:23:24AM +0000, Lee Jones wrote:
>> On Fri, 25 Feb 2022, Dan Carpenter wrote:
>>
>>> On Fri, Feb 25, 2022 at 08:50:43AM +0000, Lee Jones wrote:
>>>> On Thu, 24 Feb 2022, Bjorn Andersson wrote:
>>>>
>>>>> On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:
>>>>>
>>>>>> Some PMIC functions such as the RRADC need to be aware of the PMIC
>>>>>> chip revision information to implement errata or otherwise adjust
>>>>>> behaviour, export the PMIC information to enable this.
>>>>>>
>>>>>> This is specifically required to enable the RRADC to adjust
>>>>>> coefficients based on which chip fab the PMIC was produced in,
>>>>>> this can vary per unique device and therefore has to be read at
>>>>>> runtime.
>>>>>>
>>>>>> [bugs in previous revision]
>>>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>>>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>>>>>
>>>>> This says is that "kernel test robot" and Dan reported that something
>>>>> needed to be fixed and this patch is the fix for this.
>>>>>
>>>>> So even though their emails asks for you to give them credit like this
>>>>> you can't do it for new patches.
>>>>
>>>> Right, or else you'd have to give credit to anyone who provided you
>>>> with a review.  This could potentially grow to quite a long list.
>>>>
>>>
>>> I always feel like people who find crashing bugs should get credit but
>>> no credit for complaining about style.  It's like we reward people for
>>> reporting bugs after it gets merged but not before.
>>>
>>> We've had this debate before and people don't agree with me or they say
>>> that it's fine to just include the Reported-by kbuild tags and let
>>> people figure out from the context that probably kbuild didn't tell
>>> people to write a new driver.
>>
>> Reviews will often consist of both style and logic recommendations.
>> If not spotted and remedied, the latter of which would likely result
>> in undesired behaviour a.k.a. bugs.  So at what point, or what type of
>> bug would warrant a tag?
>>
> 
> If it's a crash or memory leak.  Style comments and fixing typos are
> their own reward.  Basically it's the same rule as Fixes tags.  We
> shouldn't use Fixes tags for typos.

Hi Dan,

How (if at all) would you like me to reference the bug reported by LKP
in my next revision of this patch? It doesn't seem like a fixed conclusion
was reached here.

It seems like Reported-by doesn't really represent things well, perhaps we
could try for "Bugchecked-by" or something like that?
> 
> regards,
> dan carpenter
>

Philip Li March 3, 2022, 2:28 a.m. UTC | #13

On Thu, Mar 03, 2022 at 02:20:58AM +0000, Caleb Connolly wrote:
> 
> 
> On 25/02/2022 09:40, Dan Carpenter wrote:
> > On Fri, Feb 25, 2022 at 09:23:24AM +0000, Lee Jones wrote:
> > > On Fri, 25 Feb 2022, Dan Carpenter wrote:
> > > 
> > > > On Fri, Feb 25, 2022 at 08:50:43AM +0000, Lee Jones wrote:
> > > > > On Thu, 24 Feb 2022, Bjorn Andersson wrote:
> > > > > 
> > > > > > On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:
> > > > > > 
> > > > > > > Some PMIC functions such as the RRADC need to be aware of the PMIC
> > > > > > > chip revision information to implement errata or otherwise adjust
> > > > > > > behaviour, export the PMIC information to enable this.
> > > > > > > 
> > > > > > > This is specifically required to enable the RRADC to adjust
> > > > > > > coefficients based on which chip fab the PMIC was produced in,
> > > > > > > this can vary per unique device and therefore has to be read at
> > > > > > > runtime.
> > > > > > > 
> > > > > > > [bugs in previous revision]
> > > > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > > > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > > > > 
> > > > > > This says is that "kernel test robot" and Dan reported that something
> > > > > > needed to be fixed and this patch is the fix for this.
> > > > > > 
> > > > > > So even though their emails asks for you to give them credit like this
> > > > > > you can't do it for new patches.
> > > > > 
> > > > > Right, or else you'd have to give credit to anyone who provided you
> > > > > with a review.  This could potentially grow to quite a long list.
> > > > > 
> > > > 
> > > > I always feel like people who find crashing bugs should get credit but
> > > > no credit for complaining about style.  It's like we reward people for
> > > > reporting bugs after it gets merged but not before.
> > > > 
> > > > We've had this debate before and people don't agree with me or they say
> > > > that it's fine to just include the Reported-by kbuild tags and let
> > > > people figure out from the context that probably kbuild didn't tell
> > > > people to write a new driver.
> > > 
> > > Reviews will often consist of both style and logic recommendations.
> > > If not spotted and remedied, the latter of which would likely result
> > > in undesired behaviour a.k.a. bugs.  So at what point, or what type of
> > > bug would warrant a tag?
> > > 
> > 
> > If it's a crash or memory leak.  Style comments and fixing typos are
> > their own reward.  Basically it's the same rule as Fixes tags.  We
> > shouldn't use Fixes tags for typos.
> 
> Hi Dan,
> 
> How (if at all) would you like me to reference the bug reported by LKP
> in my next revision of this patch? It doesn't seem like a fixed conclusion
> was reached here.

Hi Caleb, this is Philip who maintains the LKP (0-day ci). You can ignore
the Reported-by tag freely.

This is confusing sometimes for this Reported-by tag, even we mention to
add it "as appropriately" to allow judgement from author for author's own
situation. Some author uses the style like "Reported-by: xxx # compiling bug fix"
but not all. We will look for how to improve this.

There's one discussion recently at https://lore.kernel.org/lkml/YfPzNNvK8Sy8YmGW@casper.infradead.org/T/
which also encourages to add Reported-by for new features or upstreamed code.

Thanks

> 
> It seems like Reported-by doesn't really represent things well, perhaps we
> could try for "Bugchecked-by" or something like that?
> > 
> > regards,
> > dan carpenter
> > 
> 
> -- 
> Kind Regards,
> Caleb (they/them)
>

Dan Carpenter March 3, 2022, 9:05 a.m. UTC | #14

On Thu, Mar 03, 2022 at 02:20:58AM +0000, Caleb Connolly wrote:
> 
> 
> On 25/02/2022 09:40, Dan Carpenter wrote:
> > On Fri, Feb 25, 2022 at 09:23:24AM +0000, Lee Jones wrote:
> > > On Fri, 25 Feb 2022, Dan Carpenter wrote:
> > > 
> > > > On Fri, Feb 25, 2022 at 08:50:43AM +0000, Lee Jones wrote:
> > > > > On Thu, 24 Feb 2022, Bjorn Andersson wrote:
> > > > > 
> > > > > > On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:
> > > > > > 
> > > > > > > Some PMIC functions such as the RRADC need to be aware of the PMIC
> > > > > > > chip revision information to implement errata or otherwise adjust
> > > > > > > behaviour, export the PMIC information to enable this.
> > > > > > > 
> > > > > > > This is specifically required to enable the RRADC to adjust
> > > > > > > coefficients based on which chip fab the PMIC was produced in,
> > > > > > > this can vary per unique device and therefore has to be read at
> > > > > > > runtime.
> > > > > > > 
> > > > > > > [bugs in previous revision]
> > > > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > > > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > > > > 
> > > > > > This says is that "kernel test robot" and Dan reported that something
> > > > > > needed to be fixed and this patch is the fix for this.
> > > > > > 
> > > > > > So even though their emails asks for you to give them credit like this
> > > > > > you can't do it for new patches.
> > > > > 
> > > > > Right, or else you'd have to give credit to anyone who provided you
> > > > > with a review.  This could potentially grow to quite a long list.
> > > > > 
> > > > 
> > > > I always feel like people who find crashing bugs should get credit but
> > > > no credit for complaining about style.  It's like we reward people for
> > > > reporting bugs after it gets merged but not before.
> > > > 
> > > > We've had this debate before and people don't agree with me or they say
> > > > that it's fine to just include the Reported-by kbuild tags and let
> > > > people figure out from the context that probably kbuild didn't tell
> > > > people to write a new driver.
> > > 
> > > Reviews will often consist of both style and logic recommendations.
> > > If not spotted and remedied, the latter of which would likely result
> > > in undesired behaviour a.k.a. bugs.  So at what point, or what type of
> > > bug would warrant a tag?
> > > 
> > 
> > If it's a crash or memory leak.  Style comments and fixing typos are
> > their own reward.  Basically it's the same rule as Fixes tags.  We
> > shouldn't use Fixes tags for typos.
> 
> Hi Dan,
> 
> How (if at all) would you like me to reference the bug reported by LKP
> in my next revision of this patch? It doesn't seem like a fixed conclusion
> was reached here.
> 
> It seems like Reported-by doesn't really represent things well, perhaps we
> could try for "Bugchecked-by" or something like that?

Just leave it out.  Those are automated emails and I just look them
over and hit forward or delete.

The thing is that I've been arguing for a new Fixes-from: tag since
before the kbuild-bot existed and on the last kernel summit email list
someone said to just use Reported-by so I've been trying to help people
consider that as an option...

regards,
dan carpenter

Lee Jones March 3, 2022, 9:52 a.m. UTC | #15

On Thu, 03 Mar 2022, Dan Carpenter wrote:

> On Thu, Mar 03, 2022 at 02:20:58AM +0000, Caleb Connolly wrote:
> > 
> > 
> > On 25/02/2022 09:40, Dan Carpenter wrote:
> > > On Fri, Feb 25, 2022 at 09:23:24AM +0000, Lee Jones wrote:
> > > > On Fri, 25 Feb 2022, Dan Carpenter wrote:
> > > > 
> > > > > On Fri, Feb 25, 2022 at 08:50:43AM +0000, Lee Jones wrote:
> > > > > > On Thu, 24 Feb 2022, Bjorn Andersson wrote:
> > > > > > 
> > > > > > > On Mon 21 Feb 16:07 CST 2022, Caleb Connolly wrote:
> > > > > > > 
> > > > > > > > Some PMIC functions such as the RRADC need to be aware of the PMIC
> > > > > > > > chip revision information to implement errata or otherwise adjust
> > > > > > > > behaviour, export the PMIC information to enable this.
> > > > > > > > 
> > > > > > > > This is specifically required to enable the RRADC to adjust
> > > > > > > > coefficients based on which chip fab the PMIC was produced in,
> > > > > > > > this can vary per unique device and therefore has to be read at
> > > > > > > > runtime.
> > > > > > > > 
> > > > > > > > [bugs in previous revision]
> > > > > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > > > > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > > > > > 
> > > > > > > This says is that "kernel test robot" and Dan reported that something
> > > > > > > needed to be fixed and this patch is the fix for this.
> > > > > > > 
> > > > > > > So even though their emails asks for you to give them credit like this
> > > > > > > you can't do it for new patches.
> > > > > > 
> > > > > > Right, or else you'd have to give credit to anyone who provided you
> > > > > > with a review.  This could potentially grow to quite a long list.
> > > > > > 
> > > > > 
> > > > > I always feel like people who find crashing bugs should get credit but
> > > > > no credit for complaining about style.  It's like we reward people for
> > > > > reporting bugs after it gets merged but not before.
> > > > > 
> > > > > We've had this debate before and people don't agree with me or they say
> > > > > that it's fine to just include the Reported-by kbuild tags and let
> > > > > people figure out from the context that probably kbuild didn't tell
> > > > > people to write a new driver.
> > > > 
> > > > Reviews will often consist of both style and logic recommendations.
> > > > If not spotted and remedied, the latter of which would likely result
> > > > in undesired behaviour a.k.a. bugs.  So at what point, or what type of
> > > > bug would warrant a tag?
> > > > 
> > > 
> > > If it's a crash or memory leak.  Style comments and fixing typos are
> > > their own reward.  Basically it's the same rule as Fixes tags.  We
> > > shouldn't use Fixes tags for typos.
> > 
> > Hi Dan,
> > 
> > How (if at all) would you like me to reference the bug reported by LKP
> > in my next revision of this patch? It doesn't seem like a fixed conclusion
> > was reached here.
> > 
> > It seems like Reported-by doesn't really represent things well, perhaps we
> > could try for "Bugchecked-by" or something like that?
> 
> Just leave it out.  Those are automated emails and I just look them
> over and hit forward or delete.
> 
> The thing is that I've been arguing for a new Fixes-from: tag since
> before the kbuild-bot existed and on the last kernel summit email list
> someone said to just use Reported-by so I've been trying to help people
> consider that as an option...

Nothing wrong with using Reported-by if located chronologically and
annotated correctly.  Example was provided in a previous mail.

[v8,0/9] iio: adc: introduce Qualcomm SPMI Round Robin ADC

Message

Comments