Message ID | 20220221220743.541704-3-caleb.connolly@linaro.org (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | iio: adc: introduce Qualcomm SPMI Round Robin ADC | expand |
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 >
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.
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
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%
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
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
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__ */
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 >
On 26/02/2022 18:09, Dmitry Baryshkov wrote: > 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. >> + */ > Hi Dmitry, > 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 Huh alright, I see a few ways we can deal with this, as if this is the case then I think the existing logic in probe (which only prints the PMIC information) would need to be fixed either way. Could you clarify if these PMICs have only one USID, or if for example PM8350[ABC] is a PMIC with 4 USIDs? None of these PMICs seem to be referenced in the PMIC match table, they aren't in mainline yet? If I rework the logic to use shared compatible strings to find the base PMIC (by finding the matching USID with the smallest address) maybe that would be an acceptable solution, although that would break if a device has more than one of a single pmic... Perhaps for now we could limit the logic to only run for pm(i)8998 and pm660 and return `-EINVAL` with a WARN for other PMICs, as these two are the only ones with drivers that would use this functionality for now, and it can be fixed up for newer PMICs in the future if needed. Let me know what you think.> >> + 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 >> > >
On Mon, 28 Feb 2022 at 21:08, Caleb Connolly <caleb.connolly@linaro.org> wrote: > > > > On 26/02/2022 18:09, Dmitry Baryshkov wrote: > > 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. > >> + */ > > > Hi Dmitry, > > 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 > Huh alright, I see a few ways we can deal with this, as if this is the case then I think the existing logic in probe > (which only prints the PMIC information) would need to be fixed either way. > > Could you clarify if these PMICs have only one USID, or if for example PM8350[ABC] is a PMIC with 4 USIDs? They are different PMICs. > > None of these PMICs seem to be referenced in the PMIC match table, they aren't in mainline yet? socinfo is added in this patch: https://lore.kernel.org/all/20220210051043.748275-1-bjorn.andersson@linaro.org/ For the qcom-spmi-pmic driver they use the generic "qcom,spmi-pmic" compatibility string. > > If I rework the logic to use shared compatible strings to find the base PMIC (by finding the matching USID with the > smallest address) maybe that would be an acceptable solution, although that would break if a device has more than one of > a single pmic... > > Perhaps for now we could limit the logic to only run for pm(i)8998 and pm660 and return `-EINVAL` with a WARN for other > PMICs, as these two are the only ones with drivers that would use this functionality for now, and it can be fixed up for > newer PMICs in the future if needed. I suspect that the correct way would be to replace the match data with the struct describing whether the PMIC spans two USIDs or just one. I think we can drop current match data, it can be read from the PMIC itself. The single-USID pmics also can be removed from the match table provided the dts files use generic binding too. > > Let me know what you think.> > >> + 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 > >> > > > > > > -- > Kind Regards, > Caleb (they/them)
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 >
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) >
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
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.
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__ */
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