| Message ID | 20190225065044.11023-1-vaishali.thakkar@linaro.org |
|---|---|
| Headers | show |
| Series | soc: qcom: Add SoC info driver | expand |
Quoting Vaishali Thakkar (2019-02-24 22:50:40) > From: Bjorn Andersson <bjorn.andersson@linaro.org> > > Add new attribute named "serial_number" as a standard interface for > user space to acquire the serial number of the device. > > For ST-Ericsson SoCs this is exposed by the cryptically named "soc_id" > attribute, but this provides a human readable standardized name for this > property. > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> > Signed-off-by: Vaishali Thakkar <vaishali.thakkar@linaro.org> > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > --- Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Quoting Vaishali Thakkar (2019-02-24 22:50:42) > diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c > index f80d040601fd..efe0b053ef82 100644 > --- a/drivers/soc/qcom/smem.c > +++ b/drivers/soc/qcom/smem.c > @@ -971,11 +972,18 @@ static int qcom_smem_probe(struct platform_device *pdev) > > __smem = smem; > > + smem->socinfo = platform_device_register_data(&pdev->dev, "qcom-socinfo", > + PLATFORM_DEVID_NONE, NULL, > + 0); > + if (IS_ERR(smem->socinfo)) > + dev_err(&pdev->dev, "failed to register socinfo device\n"); But we don't fail the probe? Maybe a comment should be added indicating why it's ok to not fail here, and dev_err should be changed to dev_dbg() then. > + > return 0; > } > > static int qcom_smem_remove(struct platform_device *pdev) > { > + Nitpick: Drop this change? Or add the code to remove the socinfo device that is created in probe? > hwspin_lock_free(__smem->hwlock); > __smem = NULL; > > diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c > new file mode 100644 > index 000000000000..02078049fac7 > --- /dev/null > +++ b/drivers/soc/qcom/socinfo.c > @@ -0,0 +1,197 @@ [...] > + > +struct soc_of_id { > + unsigned int id; > + const char *name; > +}; > + > +static const struct soc_of_id soc_of_id[] = { > + {87, "MSM8960"}, Nitpick: Please space out the numbers and strings: { 87, "MSM8960" }, > +}; > + > +static const char *socinfo_machine(struct device *dev, unsigned int id) > +{ > + int idx; > + > + for (idx = 0; idx < ARRAY_SIZE(soc_of_id); idx++) { > + if (soc_of_id[idx].id == id) > + return soc_of_id[idx].name; Why is it called soc_of_id? Is that supposed to be "SoC of ID" or is it DT based and is "SoC OF ID"? If it's the latter, I'd prefer some non-DT type of name to provide more clarity that this has nothing to do with DeviceTree. > + } > + > + if (IS_ERR(soc_of_id[idx].name)) > + dev_err(dev, "Unknown soc id\n"); > + > + return NULL; > +} > + > +static int qcom_socinfo_probe(struct platform_device *pdev) > +{ > + struct qcom_socinfo *qs; > + struct socinfo *info; > + size_t item_size; > + > + info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, > + &item_size); > + if (IS_ERR(info)) { > + dev_err(&pdev->dev, "Couldn't find socinfo\n"); > + return -EINVAL; Why not return PTR_ERR(info)? > + } > + > + qs = devm_kzalloc(&pdev->dev, sizeof(*qs), GFP_KERNEL); > + if (!qs) > + return -ENOMEM; > + > + qs->attr.family = "Snapdragon"; > + qs->attr.machine = socinfo_machine(&pdev->dev, > + le32_to_cpu(info->id)); > + qs->attr.revision = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%u.%u", > + SOCINFO_MAJOR(le32_to_cpu(info->ver)), > + SOCINFO_MINOR(le32_to_cpu(info->ver))); > + if (le32_to_cpu(info->fmt) >= 10) Maybe this would make more sense if it was written with item_size and offset of info->fmt? Something like if (offsetof(struct qcom_socinfo, serial_num) <= item_size) > + qs->attr.serial_number = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "%u", > + le32_to_cpu(info->serial_num)); > + > + qs->soc_dev = soc_device_register(&qs->attr); > + if (IS_ERR(qs->soc_dev)) > + return PTR_ERR(qs->soc_dev); > + > + /* Feed the soc specific unique data into entropy pool */ > + add_device_randomness(info, item_size); > + > + platform_set_drvdata(pdev, qs->soc_dev); Weird, this is setting it to qs->soc_dev.... > + > + return 0; > +} > + > +static int qcom_socinfo_remove(struct platform_device *pdev) > +{ > + struct qcom_socinfo *qs = platform_get_drvdata(pdev); And then extracting this as qs only... > + > + soc_device_unregister(qs->soc_dev); And so it looks wrong? Probably already have qs->soc_dev from the platform_get_drvdata() call? > + > + return 0; > +} > + > +static struct platform_driver qcom_socinfo_driver = { > + .probe = qcom_socinfo_probe, > + .remove = qcom_socinfo_remove, > + .driver = { > + .name = "qcom-socinfo", > + }, > +}; > + > +module_platform_driver(qcom_socinfo_driver); > + > +MODULE_DESCRIPTION("Qualcomm socinfo driver"); Maybe write socinfo as SoCinfo here? > +MODULE_LICENSE("GPL v2"); > +MODULE_ALIAS("platform:qcom-socinfo");
Quoting Vaishali Thakkar (2019-02-24 22:50:43) > diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c > index 02078049fac7..ccadeba69a81 100644 > --- a/drivers/soc/qcom/socinfo.c > +++ b/drivers/soc/qcom/socinfo.c > @@ -70,6 +93,10 @@ struct socinfo { > struct qcom_socinfo { > struct soc_device *soc_dev; > struct soc_device_attribute attr; > +#ifdef CONFIG_DEBUG_FS > + struct dentry *dbg_root; > +#endif /* CONFIG_DEBUG_FS */ > + struct socinfo *socinfo; This doesn't look necessary, instead just pass it through to the functions that need the pointer. > }; > > struct soc_of_id { > @@ -133,6 +160,171 @@ static const char *socinfo_machine(struct device *dev, unsigned int id) > return NULL; > } > > +#ifdef CONFIG_DEBUG_FS > + > +#define UINT_SHOW(name, attr) \ > +static int qcom_show_##name(struct seq_file *seq, void *p) \ > +{ \ > + struct socinfo *socinfo = seq->private; \ > + seq_printf(seq, "%u\n", le32_to_cpu(socinfo->attr)); \ > + return 0; \ > +} \ > +static int qcom_open_##name(struct inode *inode, struct file *file) \ > +{ \ > + return single_open(file, qcom_show_##name, inode->i_private); \ > +} \ > + \ > +static const struct file_operations qcom_ ##name## _ops = { \ > + .open = qcom_open_##name, \ > + .read = seq_read, \ > + .llseek = seq_lseek, \ > + .release = single_release, \ > +} Why can't we use the debugfs_create_u32 function? It would make things clearer if there was either a debugfs_create_le32() function or if the socinfo structure stored in smem was unmarshalled from little endian to the cpu native endian format during probe time and then all the rest of the code can treat it as a native endian u32 values. > + > +#define DEBUGFS_UINT_ADD(name) \ > + debugfs_create_file(__stringify(name), 0400, \ > + qcom_socinfo->dbg_root, \ > + qcom_socinfo->socinfo, &qcom_ ##name## _ops) > + > +#define HEX_SHOW(name, attr) \ > +static int qcom_show_##name(struct seq_file *seq, void *p) \ > +{ \ > + struct socinfo *socinfo = seq->private; \ > + seq_printf(seq, "0x%x\n", le32_to_cpu(socinfo->attr)); \ Use "%#x\n" format? > + return 0; \ > +} \ > +static int qcom_open_##name(struct inode *inode, struct file *file) \ > +{ \ > + return single_open(file, qcom_show_##name, inode->i_private); \ > +} \ > + \ > +static const struct file_operations qcom_ ##name## _ops = { \ > + .open = qcom_open_##name, \ > + .read = seq_read, \ > + .llseek = seq_lseek, \ > + .release = single_release, \ > +} > + > +#define DEBUGFS_HEX_ADD(name) \ > + debugfs_create_file(__stringify(name), 0400, \ > + qcom_socinfo->dbg_root, \ > + qcom_socinfo->socinfo, &qcom_ ##name## _ops) > + > + > +#define QCOM_OPEN(name, _func) \ > +static int qcom_open_##name(struct inode *inode, struct file *file) \ > +{ \ > + return single_open(file, _func, inode->i_private); \ > +} \ > + \ > +static const struct file_operations qcom_ ##name## _ops = { \ > + .open = qcom_open_##name, \ > + .read = seq_read, \ > + .llseek = seq_lseek, \ > + .release = single_release, \ > +} > + > +#define DEBUGFS_ADD(name) \ > + debugfs_create_file(__stringify(name), 0400, \ > + qcom_socinfo->dbg_root, \ > + qcom_socinfo->socinfo, &qcom_ ##name## _ops) > + > + > +static int qcom_show_build_id(struct seq_file *seq, void *p) > +{ > + struct socinfo *socinfo = seq->private; > + > + seq_printf(seq, "%s\n", socinfo->build_id); > + > + return 0; > +} > + > +static int qcom_show_accessory_chip(struct seq_file *seq, void *p) > +{ > + struct socinfo *socinfo = seq->private; > + > + seq_printf(seq, "%d\n", le32_to_cpu(socinfo->accessory_chip)); > + > + return 0; > +} > + > +static int qcom_show_platform_subtype(struct seq_file *seq, void *p) > +{ > + struct socinfo *socinfo = seq->private; > + int subtype = le32_to_cpu(socinfo->hw_plat_subtype); > + > + if (subtype < 0) > + return -EINVAL; Can it ever be negative? Why is it assigned to int type at all? > + > + seq_printf(seq, "%u\n", subtype); And then we print it as an unsigned value? Why not use %d to match the type? > + > + return 0; > +} > + > +static int qcom_show_pmic_model(struct seq_file *seq, void *p) > +{ > + struct socinfo *socinfo = seq->private; > + int model = SOCINFO_MINOR(le32_to_cpu(socinfo->pmic_model)); > + > + if (model < 0) > + return -EINVAL; > + > + seq_printf(seq, "%s\n", pmic_model[model]); Is there a debugfs_create_file_string()? > + > + return 0; > +} > + > +static int qcom_show_pmic_die_revision(struct seq_file *seq, void *p) > +{ > + struct socinfo *socinfo = seq->private; > + > + seq_printf(seq, "%u.%u\n", > + SOCINFO_MAJOR(le32_to_cpu(socinfo->pmic_die_rev)), > + SOCINFO_MINOR(le32_to_cpu(socinfo->pmic_die_rev))); > + > + return 0; > +} > +
Quoting Vaishali Thakkar (2019-02-24 22:50:44) > + qcom_socinfo->dbg_root); > + > + DEBUGFS_IMAGE_NAME(name, apps, SMEM_IMAGE_TABLE_APPS_INDEX); > + DEBUGFS_IMAGE_VARIANT(variant, apps, SMEM_IMAGE_TABLE_APPS_INDEX); > + DEBUGFS_IMAGE_OEM(oem, apps, SMEM_IMAGE_TABLE_APPS_INDEX); > + > + qcom_socinfo->mpss = debugfs_create_dir("mpss", > + qcom_socinfo->dbg_root); > + > + DEBUGFS_IMAGE_NAME(name, mpss, SMEM_IMAGE_TABLE_MPSS_INDEX); > + DEBUGFS_IMAGE_VARIANT(variant, mpss, SMEM_IMAGE_TABLE_MPSS_INDEX); > + DEBUGFS_IMAGE_OEM(oem, mpss, SMEM_IMAGE_TABLE_MPSS_INDEX); > + > + qcom_socinfo->adsp = debugfs_create_dir("adsp", > + qcom_socinfo->dbg_root); > + > + DEBUGFS_IMAGE_NAME(name, adsp, SMEM_IMAGE_TABLE_ADSP_INDEX); > + DEBUGFS_IMAGE_VARIANT(variant, adsp, SMEM_IMAGE_TABLE_ADSP_INDEX); > + DEBUGFS_IMAGE_OEM(oem, adsp, SMEM_IMAGE_TABLE_ADSP_INDEX); > + > + qcom_socinfo->cnss = debugfs_create_dir("cnss", > + qcom_socinfo->dbg_root); > + > + DEBUGFS_IMAGE_NAME(name, cnss, SMEM_IMAGE_TABLE_CNSS_INDEX); > + DEBUGFS_IMAGE_VARIANT(variant, cnss, SMEM_IMAGE_TABLE_CNSS_INDEX); > + DEBUGFS_IMAGE_OEM(oem, cnss, SMEM_IMAGE_TABLE_CNSS_INDEX); > + > + qcom_socinfo->video = debugfs_create_dir("video", > + qcom_socinfo->dbg_root); > + > + DEBUGFS_IMAGE_NAME(name, video, SMEM_IMAGE_TABLE_VIDEO_INDEX); > + DEBUGFS_IMAGE_VARIANT(variant, video, SMEM_IMAGE_TABLE_VIDEO_INDEX); > + DEBUGFS_IMAGE_OEM(oem, video, SMEM_IMAGE_TABLE_VIDEO_INDEX); Couldn't these four lines be a function itself that takes the name, dbg_root, index, etc and create a directory? Looks like a lot of copy paste right now. > } > > static void socinfo_debugfs_exit(struct qcom_socinfo *qcom_socinfo) > -- > 2.17.1 >
On Sun 24 Feb 22:50 PST 2019, Vaishali Thakkar wrote: [..] > diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile > index f25b54cd6cf8..c817da4f4140 100644 > --- a/drivers/soc/qcom/Makefile > +++ b/drivers/soc/qcom/Makefile > @@ -14,6 +14,7 @@ qcom_rpmh-y += rpmh-rsc.o > qcom_rpmh-y += rpmh.o > obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o > obj-$(CONFIG_QCOM_SMEM) += smem.o > +obj-$(CONFIG_QCOM_SOCINFO) += socinfo.o Try to keep these sorted by moving this entry down a few steps. > obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o > obj-$(CONFIG_QCOM_SMP2P) += smp2p.o > obj-$(CONFIG_QCOM_SMSM) += smsm.o > diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c > index f80d040601fd..efe0b053ef82 100644 > --- a/drivers/soc/qcom/smem.c > +++ b/drivers/soc/qcom/smem.c > @@ -276,6 +276,7 @@ struct qcom_smem { > struct smem_partition_header *partitions[SMEM_HOST_COUNT]; > size_t cacheline[SMEM_HOST_COUNT]; > u32 item_count; > + struct platform_device *socinfo; > > unsigned num_regions; > struct smem_region regions[]; > @@ -971,11 +972,18 @@ static int qcom_smem_probe(struct platform_device *pdev) > > __smem = smem; > > + smem->socinfo = platform_device_register_data(&pdev->dev, "qcom-socinfo", > + PLATFORM_DEVID_NONE, NULL, > + 0); > + if (IS_ERR(smem->socinfo)) > + dev_err(&pdev->dev, "failed to register socinfo device\n"); > + > return 0; > } > > static int qcom_smem_remove(struct platform_device *pdev) > { > + Let's platform_device_unregister(smem->socinfo) here. Note that it will handle being passed a ERR_PTR, so no need to make the call conditional on socinfo being valid. > hwspin_lock_free(__smem->hwlock); > __smem = NULL; > > diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c > new file mode 100644 > index 000000000000..02078049fac7 > --- /dev/null > +++ b/drivers/soc/qcom/socinfo.c > @@ -0,0 +1,197 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2009-2017, The Linux Foundation. All rights reserved. > + * Copyright (c) 2017-2019, Linaro Ltd. > + */ > + > +#include <linux/err.h> > +#include <linux/module.h> > +#include <linux/platform_device.h> > +#include <linux/random.h> > +#include <linux/slab.h> > +#include <linux/soc/qcom/smem.h> > +#include <linux/string.h> > +#include <linux/sys_soc.h> > +#include <linux/types.h> > + > +/* > + * SoC version type with major number in the upper 16 bits and minor > + * number in the lower 16 bits. > + */ > +#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0xffff) > +#define SOCINFO_MINOR(ver) ((ver) & 0xffff) > + > +#define SMEM_SOCINFO_BUILD_ID_LENGTH 32 > + > +/* > + * SMEM item ids, used to acquire handles to respective > + * SMEM region. There's only one socinfo SMEM item, so this sentence should be turned singular. > + */ > +#define SMEM_HW_SW_BUILD_ID 137 > + > +/* Socinfo SMEM item structure */ > +struct socinfo { > + __le32 fmt; > + __le32 id; > + __le32 ver; > + char build_id[SMEM_SOCINFO_BUILD_ID_LENGTH]; > + /* Version 2 */ > + __le32 raw_id; > + __le32 raw_ver; > + /* Version 3 */ > + __le32 hw_plat; > + /* Version 4 */ > + __le32 plat_ver; > + /* Version 5 */ > + __le32 accessory_chip; > + /* Version 6 */ > + __le32 hw_plat_subtype; > + /* Version 7 */ > + __le32 pmic_model; > + __le32 pmic_die_rev; > + /* Version 8 */ > + __le32 pmic_model_1; > + __le32 pmic_die_rev_1; > + __le32 pmic_model_2; > + __le32 pmic_die_rev_2; > + /* Version 9 */ > + __le32 foundry_id; > + /* Version 10 */ > + __le32 serial_num; > + /* Version 11 */ > + __le32 num_pmics; > + __le32 pmic_array_offset; > + /* Version 12 */ > + __le32 chip_family; > + __le32 raw_device_family; > + __le32 raw_device_num; > +}; > + > +struct qcom_socinfo { > + struct soc_device *soc_dev; > + struct soc_device_attribute attr; > +}; > + > +struct soc_of_id { > + unsigned int id; > + const char *name; > +}; > + > +static const struct soc_of_id soc_of_id[] = { > + {87, "MSM8960"}, > + {109, "APQ8064"}, > + {122, "MSM8660A"}, > + {123, "MSM8260A"}, > + {124, "APQ8060A"}, > + {126, "MSM8974"}, > + {130, "MPQ8064"}, > + {138, "MSM8960AB"}, > + {139, "APQ8060AB"}, > + {140, "MSM8260AB"}, > + {141, "MSM8660AB"}, > + {178, "APQ8084"}, > + {184, "APQ8074"}, > + {185, "MSM8274"}, > + {186, "MSM8674"}, > + {194, "MSM8974PRO"}, > + {206, "MSM8916"}, > + {208, "APQ8074-AA"}, > + {209, "APQ8074-AB"}, > + {210, "APQ8074PRO"}, > + {211, "MSM8274-AA"}, > + {212, "MSM8274-AB"}, > + {213, "MSM8274PRO"}, > + {214, "MSM8674-AA"}, > + {215, "MSM8674-AB"}, > + {216, "MSM8674PRO"}, > + {217, "MSM8974-AA"}, > + {218, "MSM8974-AB"}, > + {246, "MSM8996"}, > + {247, "APQ8016"}, > + {248, "MSM8216"}, > + {249, "MSM8116"}, > + {250, "MSM8616"}, > + {291, "APQ8096"}, > + {305, "MSM8996SG"}, > + {310, "MSM8996AU"}, > + {311, "APQ8096AU"}, > + {312, "APQ8096SG"}, > +}; > + > +static const char *socinfo_machine(struct device *dev, unsigned int id) > +{ > + int idx; > + > + for (idx = 0; idx < ARRAY_SIZE(soc_of_id); idx++) { > + if (soc_of_id[idx].id == id) > + return soc_of_id[idx].name; > + } > + > + if (IS_ERR(soc_of_id[idx].name)) idx will be == ARRAY_SIZE(soc_of_id) here, so you're reading outside the array. You can write your error unconditionally here, because you didn't find a match - or just skip the error message completely. If you decide to keep it, that would be to facilitate adding new entries to the list, so include the value of "id". > + dev_err(dev, "Unknown soc id\n"); > + > + return NULL; > +} > + > +static int qcom_socinfo_probe(struct platform_device *pdev) > +{ > + struct qcom_socinfo *qs; > + struct socinfo *info; > + size_t item_size; > + > + info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, > + &item_size); > + if (IS_ERR(info)) { > + dev_err(&pdev->dev, "Couldn't find socinfo\n"); > + return -EINVAL; > + } > + > + qs = devm_kzalloc(&pdev->dev, sizeof(*qs), GFP_KERNEL); > + if (!qs) > + return -ENOMEM; > + > + qs->attr.family = "Snapdragon"; > + qs->attr.machine = socinfo_machine(&pdev->dev, > + le32_to_cpu(info->id)); > + qs->attr.revision = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%u.%u", > + SOCINFO_MAJOR(le32_to_cpu(info->ver)), > + SOCINFO_MINOR(le32_to_cpu(info->ver))); > + if (le32_to_cpu(info->fmt) >= 10) > + qs->attr.serial_number = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "%u", > + le32_to_cpu(info->serial_num)); > + > + qs->soc_dev = soc_device_register(&qs->attr); > + if (IS_ERR(qs->soc_dev)) > + return PTR_ERR(qs->soc_dev); > + > + /* Feed the soc specific unique data into entropy pool */ > + add_device_randomness(info, item_size); > + > + platform_set_drvdata(pdev, qs->soc_dev); > + > + return 0; > +} Regards, Bjorn
On Sun 24 Feb 22:50 PST 2019, Vaishali Thakkar wrote: > +#define IMAGE_SHOW_OEM(attr) \ > +static int show_ ##attr## _oem(struct seq_file *seq, void *p) \ > +{ \ > + struct smem_image_version *image_version = seq->private; \ > + seq_puts(seq, image_version->oem); \ > + seq_puts(seq, "\n"); \ > + return 0; \ > +} \ > +static int open_ ##attr## _oem(struct inode *inode, struct file *file) \ > +{ \ > + return single_open(file, show_ ##attr## _oem, inode->i_private); \ > +} \ > + \ > +static const struct file_operations qcom_ ##attr## _oem_ops = { \ > + .open = open_ ##attr## _oem, \ > + .read = seq_read, \ > + .llseek = seq_lseek, \ > + .release = single_release, \ > +} > + > +#define DEBUGFS_IMAGE_OEM(fname, attr, index) \ > +debugfs_create_file(__stringify(fname), 0400, qcom_socinfo->attr, \ > + &smem_image_version[index], &qcom_ ##attr## _oem_ops) > + > +#define IMAGE_SHOW(name) \ > + IMAGE_SHOW_NAME(name); \ > + IMAGE_SHOW_VARIANT(name); \ > + IMAGE_SHOW_OEM(name) \ > + > +IMAGE_SHOW(boot); Given that you pass &smem_image_version[index] as "data" it seems that these instances will only differ in the function name. So you should be able to have one set of these functions to handle all the images. > +IMAGE_SHOW(tz); > +IMAGE_SHOW(rpm); > +IMAGE_SHOW(apps); > +IMAGE_SHOW(mpss); > +IMAGE_SHOW(adsp); > +IMAGE_SHOW(cnss); > +IMAGE_SHOW(video); > + Regards, Bjorn
On Fri, 1 Mar 2019 at 03:02, Stephen Boyd <swboyd@chromium.org> wrote: > > Quoting Vaishali Thakkar (2019-02-24 22:50:43) > > diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c > > index 02078049fac7..ccadeba69a81 100644 > > --- a/drivers/soc/qcom/socinfo.c > > +++ b/drivers/soc/qcom/socinfo.c > > @@ -70,6 +93,10 @@ struct socinfo { > > struct qcom_socinfo { > > struct soc_device *soc_dev; > > struct soc_device_attribute attr; > > +#ifdef CONFIG_DEBUG_FS > > + struct dentry *dbg_root; > > +#endif /* CONFIG_DEBUG_FS */ > > + struct socinfo *socinfo; > > This doesn't look necessary, instead just pass it through to the > functions that need the pointer. > > > }; > > > > struct soc_of_id { > > @@ -133,6 +160,171 @@ static const char *socinfo_machine(struct device *dev, unsigned int id) > > return NULL; > > } > > > > +#ifdef CONFIG_DEBUG_FS > > + > > +#define UINT_SHOW(name, attr) \ > > +static int qcom_show_##name(struct seq_file *seq, void *p) \ > > +{ \ > > + struct socinfo *socinfo = seq->private; \ > > + seq_printf(seq, "%u\n", le32_to_cpu(socinfo->attr)); \ > > + return 0; \ > > +} \ > > +static int qcom_open_##name(struct inode *inode, struct file *file) \ > > +{ \ > > + return single_open(file, qcom_show_##name, inode->i_private); \ > > +} \ > > + \ > > +static const struct file_operations qcom_ ##name## _ops = { \ > > + .open = qcom_open_##name, \ > > + .read = seq_read, \ > > + .llseek = seq_lseek, \ > > + .release = single_release, \ > > +} > > Why can't we use the debugfs_create_u32 function? It would make things > clearer if there was either a debugfs_create_le32() function or if the > socinfo structure stored in smem was unmarshalled from little endian > to the cpu native endian format during probe time and then all the rest > of the code can treat it as a native endian u32 values. Thanks for the review. I've worked on the next version with all the changes you suggested in the patchset but I'm kind of not sure what would be the best solution in this case. I'm bit skeptical about introducing debugfs_create_le32 as we don't really have any endian specific functions in the debugfs core at the moment. And if I do that, should I also introduce debugfs_create_be32 [and to an extent debugfs_create_le{16,64}]? More importantly, would it be useful to introduce them in core? In the case of converting it to cpu native during probe, I'll need to declare an extra struct with u32 being the parsed version for it to be correct. Wouldn't it add extra overhead? > > + > > +#define DEBUGFS_UINT_ADD(name) \ > > + debugfs_create_file(__stringify(name), 0400, \ > > + qcom_socinfo->dbg_root, \ > > + qcom_socinfo->socinfo, &qcom_ ##name## _ops) > > + > > +#define HEX_SHOW(name, attr) \ > > +static int qcom_show_##name(struct seq_file *seq, void *p) \ > > +{ \ > > + struct socinfo *socinfo = seq->private; \ > > + seq_printf(seq, "0x%x\n", le32_to_cpu(socinfo->attr)); \ > > Use "%#x\n" format? > > > + return 0; \ > > +} \ > > +static int qcom_open_##name(struct inode *inode, struct file *file) \ > > +{ \ > > + return single_open(file, qcom_show_##name, inode->i_private); \ > > +} \ > > + \ > > +static const struct file_operations qcom_ ##name## _ops = { \ > > + .open = qcom_open_##name, \ > > + .read = seq_read, \ > > + .llseek = seq_lseek, \ > > + .release = single_release, \ > > +} > > + > > +#define DEBUGFS_HEX_ADD(name) \ > > + debugfs_create_file(__stringify(name), 0400, \ > > + qcom_socinfo->dbg_root, \ > > + qcom_socinfo->socinfo, &qcom_ ##name## _ops) > > + > > + > > +#define QCOM_OPEN(name, _func) \ > > +static int qcom_open_##name(struct inode *inode, struct file *file) \ > > +{ \ > > + return single_open(file, _func, inode->i_private); \ > > +} \ > > + \ > > +static const struct file_operations qcom_ ##name## _ops = { \ > > + .open = qcom_open_##name, \ > > + .read = seq_read, \ > > + .llseek = seq_lseek, \ > > + .release = single_release, \ > > +} > > + > > +#define DEBUGFS_ADD(name) \ > > + debugfs_create_file(__stringify(name), 0400, \ > > + qcom_socinfo->dbg_root, \ > > + qcom_socinfo->socinfo, &qcom_ ##name## _ops) > > + > > + > > +static int qcom_show_build_id(struct seq_file *seq, void *p) > > +{ > > + struct socinfo *socinfo = seq->private; > > + > > + seq_printf(seq, "%s\n", socinfo->build_id); > > + > > + return 0; > > +} > > + > > +static int qcom_show_accessory_chip(struct seq_file *seq, void *p) > > +{ > > + struct socinfo *socinfo = seq->private; > > + > > + seq_printf(seq, "%d\n", le32_to_cpu(socinfo->accessory_chip)); > > + > > + return 0; > > +} > > + > > +static int qcom_show_platform_subtype(struct seq_file *seq, void *p) > > +{ > > + struct socinfo *socinfo = seq->private; > > + int subtype = le32_to_cpu(socinfo->hw_plat_subtype); > > + > > + if (subtype < 0) > > + return -EINVAL; > > Can it ever be negative? Why is it assigned to int type at all? > > > + > > + seq_printf(seq, "%u\n", subtype); > > And then we print it as an unsigned value? Why not use %d to match the > type? > > > + > > + return 0; > > +} > > + > > +static int qcom_show_pmic_model(struct seq_file *seq, void *p) > > +{ > > + struct socinfo *socinfo = seq->private; > > + int model = SOCINFO_MINOR(le32_to_cpu(socinfo->pmic_model)); > > + > > + if (model < 0) > > + return -EINVAL; > > + > > + seq_printf(seq, "%s\n", pmic_model[model]); > > Is there a debugfs_create_file_string()? > > > + > > + return 0; > > +} > > + > > +static int qcom_show_pmic_die_revision(struct seq_file *seq, void *p) > > +{ > > + struct socinfo *socinfo = seq->private; > > + > > + seq_printf(seq, "%u.%u\n", > > + SOCINFO_MAJOR(le32_to_cpu(socinfo->pmic_die_rev)), > > + SOCINFO_MINOR(le32_to_cpu(socinfo->pmic_die_rev))); > > + > > + return 0; > > +} > > +
Quoting Vaishali Thakkar (2019-03-14 04:25:16) > On Fri, 1 Mar 2019 at 03:02, Stephen Boyd <swboyd@chromium.org> wrote: > > > > Why can't we use the debugfs_create_u32 function? It would make things > > clearer if there was either a debugfs_create_le32() function or if the > > socinfo structure stored in smem was unmarshalled from little endian > > to the cpu native endian format during probe time and then all the rest > > of the code can treat it as a native endian u32 values. > > Thanks for the review. I've worked on the next version with all the > changes you suggested in the patchset but I'm kind of not sure > what would be the best solution in this case. Alright, thanks. > > I'm bit skeptical about introducing debugfs_create_le32 as we don't > really have any endian specific functions in the debugfs core at the > moment. And if I do that, should I also introduce debugfs_create_be32 > [and to an extent debugfs_create_le{16,64}]? More importantly, would > it be useful to introduce them in core? I suppose it's ambiguous if the endianness should be swapped to be CPU native, or if it should just export them as little endian or big endian to userspace. I wouldn't introduce any APIs that aren't used, because it's just dead code. If the code is documented clearly and indicates what it does then it should be fine. This patch has pretty much already written the code, so it's just a matter of moving it into debugfs core now and getting gregkh to approve. > > In the case of converting it to cpu native during probe, I'll need to > declare an extra struct with u32 being the parsed version for it to be > correct. Wouldn't it add extra overhead? Yes it would be some small extra overhead that could be allocated on the kernel's heap. What's the maximum size? A hundred bytes or so? I don't see much of a problem with this approach. It simplifies the patch series because nothing new is introduced in debugfs core and the endian conversion is done once in one place instead of being scattered throughout the code. Sounds like a good improvement to me.
On Thu, 14 Mar 2019 at 21:28, Stephen Boyd <swboyd@chromium.org> wrote: > > Quoting Vaishali Thakkar (2019-03-14 04:25:16) > > On Fri, 1 Mar 2019 at 03:02, Stephen Boyd <swboyd@chromium.org> wrote: > > > > > > Why can't we use the debugfs_create_u32 function? It would make things > > > clearer if there was either a debugfs_create_le32() function or if the > > > socinfo structure stored in smem was unmarshalled from little endian > > > to the cpu native endian format during probe time and then all the rest > > > of the code can treat it as a native endian u32 values. > > > > Thanks for the review. I've worked on the next version with all the > > changes you suggested in the patchset but I'm kind of not sure > > what would be the best solution in this case. > > Alright, thanks. > > > > > I'm bit skeptical about introducing debugfs_create_le32 as we don't > > really have any endian specific functions in the debugfs core at the > > moment. And if I do that, should I also introduce debugfs_create_be32 > > [and to an extent debugfs_create_le{16,64}]? More importantly, would > > it be useful to introduce them in core? > > I suppose it's ambiguous if the endianness should be swapped to be CPU > native, or if it should just export them as little endian or big endian > to userspace. I wouldn't introduce any APIs that aren't used, because > it's just dead code. If the code is documented clearly and indicates > what it does then it should be fine. This patch has pretty much already > written the code, so it's just a matter of moving it into debugfs core > now and getting gregkh to approve. > > > > > In the case of converting it to cpu native during probe, I'll need to > > declare an extra struct with u32 being the parsed version for it to be > > correct. Wouldn't it add extra overhead? > > Yes it would be some small extra overhead that could be allocated on the > kernel's heap. What's the maximum size? A hundred bytes or so? > > I don't see much of a problem with this approach. It simplifies the > patch series because nothing new is introduced in debugfs core and the > endian conversion is done once in one place instead of being scattered > throughout the code. Sounds like a good improvement to me. > Yes, it's true that this approach is better than introducing new endian functions in debugfs core but we should also keep in mind that this is applicable only for 4 use cases. For other usecases, we want to print string and hex values. So, I would either need new debugfs core functions for the same. I tried introducing debugfs_create_str for string values but we're ending up with introducing bunch of other helpers in the core as simple_attr_read expects integer values. Similarly, for hex values , I can't use debugfs_create_u32 as defined attributes in the core has unsigned int as a specifier, will need to introduce some extra helpers over there again. Also, in case of keeping all other cases as it is, it'll look quite asymmetric to use debugfs u32 function in init and using local macros for other cases. I can have DEBUGFS_UINT_ADD like wrapper macro for debugfs_create_u32 but again not sure if doing all of this looks better than what we have at the moment as just having 3 local macros covering our all cases without having lot of duplicated code. Let me know if about your opinion on the same. Thanks.
Quoting Vaishali Thakkar (2019-03-20 22:51:20) > On Thu, 14 Mar 2019 at 21:28, Stephen Boyd <swboyd@chromium.org> wrote: > > > > Quoting Vaishali Thakkar (2019-03-14 04:25:16) > > > On Fri, 1 Mar 2019 at 03:02, Stephen Boyd <swboyd@chromium.org> wrote: > > > > > > > > In the case of converting it to cpu native during probe, I'll need to > > > declare an extra struct with u32 being the parsed version for it to be > > > correct. Wouldn't it add extra overhead? > > > > Yes it would be some small extra overhead that could be allocated on the > > kernel's heap. What's the maximum size? A hundred bytes or so? > > > > I don't see much of a problem with this approach. It simplifies the > > patch series because nothing new is introduced in debugfs core and the > > endian conversion is done once in one place instead of being scattered > > throughout the code. Sounds like a good improvement to me. > > > > Yes, it's true that this approach is better than introducing new endian > functions in debugfs core but we should also keep in mind that this is > applicable only for 4 use cases. For other usecases, we want to print > string and hex values. So, I would either need new debugfs core > functions for the same. I tried introducing debugfs_create_str for string > values but we're ending up with introducing bunch of other helpers in > the core as simple_attr_read expects integer values. Similarly, for hex > values , I can't use debugfs_create_u32 as defined attributes in the > core has unsigned int as a specifier, will need to introduce some extra > helpers over there again. I imagine there are other uses of printing a string and hex value in debugfs. There's debugfs_create_x32() and debugfs_create_x64() for the hex value printing part (if you want that format). There's also debugfs_create_devm_seqfile() which may work to print a string from some struct member. I'm not sure why you're using simple_attr_read(). Where does that become important? > > Also, in case of keeping all other cases as it is, it'll look quite > asymmetric to use debugfs u32 function in init and using local macros > for other cases. I can have DEBUGFS_UINT_ADD like wrapper > macro for debugfs_create_u32 but again not sure if doing > all of this looks better than what we have at the moment as just having > 3 local macros covering our all cases without having lot of duplicated > code. > > Let me know if about your opinion on the same. Thanks. My opinion is still that it would be best to push things that aren't SoC specific into the debugfs core and try to use as much from the core as possible. There doesn't seem to be anything very SoC specific here so I'm lost why this isn't doable.
On Sat, 23 Mar 2019 at 05:31, Stephen Boyd <swboyd@chromium.org> wrote: > > Quoting Vaishali Thakkar (2019-03-20 22:51:20) > > On Thu, 14 Mar 2019 at 21:28, Stephen Boyd <swboyd@chromium.org> wrote: > > > > > > Quoting Vaishali Thakkar (2019-03-14 04:25:16) > > > > On Fri, 1 Mar 2019 at 03:02, Stephen Boyd <swboyd@chromium.org> wrote: > > > > > > > > > > > In the case of converting it to cpu native during probe, I'll need to > > > > declare an extra struct with u32 being the parsed version for it to be > > > > correct. Wouldn't it add extra overhead? > > > > > > Yes it would be some small extra overhead that could be allocated on the > > > kernel's heap. What's the maximum size? A hundred bytes or so? > > > > > > I don't see much of a problem with this approach. It simplifies the > > > patch series because nothing new is introduced in debugfs core and the > > > endian conversion is done once in one place instead of being scattered > > > throughout the code. Sounds like a good improvement to me. > > > > > > > Yes, it's true that this approach is better than introducing new endian > > functions in debugfs core but we should also keep in mind that this is > > applicable only for 4 use cases. For other usecases, we want to print > > string and hex values. So, I would either need new debugfs core > > functions for the same. I tried introducing debugfs_create_str for string > > values but we're ending up with introducing bunch of other helpers in > > the core as simple_attr_read expects integer values. Similarly, for hex > > values , I can't use debugfs_create_u32 as defined attributes in the > > core has unsigned int as a specifier, will need to introduce some extra > > helpers over there again. > > I imagine there are other uses of printing a string and hex value in > debugfs. There's debugfs_create_x32() and debugfs_create_x64() for the > hex value printing part (if you want that format). There's also Ok. > debugfs_create_devm_seqfile() which may work to print a string from some > struct member. I'm not sure why you're using simple_attr_read(). Where > does that become important? DEFINE_DEBUGFS_ATTRIBUTE has simple_attr helpers which expects int value. So, in the case of a string it requires to implement similar macro and separate helpers for the same. > > > > Also, in case of keeping all other cases as it is, it'll look quite > > asymmetric to use debugfs u32 function in init and using local macros > > for other cases. I can have DEBUGFS_UINT_ADD like wrapper > > macro for debugfs_create_u32 but again not sure if doing > > all of this looks better than what we have at the moment as just having > > 3 local macros covering our all cases without having lot of duplicated > > code. > > > > Let me know if about your opinion on the same. Thanks. > > My opinion is still that it would be best to push things that aren't SoC > specific into the debugfs core and try to use as much from the core as > possible. There doesn't seem to be anything very SoC specific here so > I'm lost why this isn't doable. Yes, that's true. We don't have much of SoC specific code here. >
On Mon, 25 Mar 2019 at 21:31, Stephen Boyd <swboyd@chromium.org> wrote: > > Quoting Vaishali Thakkar (2019-03-24 10:42:36) > > On Sat, 23 Mar 2019 at 05:31, Stephen Boyd <swboyd@chromium.org> wrote: > > > > > debugfs_create_devm_seqfile() which may work to print a string from some > > > struct member. I'm not sure why you're using simple_attr_read(). Where > > > does that become important? > > > > DEFINE_DEBUGFS_ATTRIBUTE has simple_attr helpers which > > expects int value. So, in the case of a string it requires to implement > > similar macro and separate helpers for the same. > > Why does DEFINE_DEBUGFS_ATTRIBUTE need to be used? For defining files inside the debugfs code [with get/set functions]. Also, most of the similar functions in the debugfs core seems to be using it. >
This patchset adds SoC info driver which can provide information such as Chip ID, Chip family and serial number about Qualcomm SoCs to user space via sysfs. Furthermore, it allows userspace to get information about custom attributes and various image version information via debugfs. The patchset cleanly applies on top of v5.0-rc6. Changes since v1: - Align ifdefs to left, remove unnecessary debugfs dir creation check and fix function signatures in patch 3 - Fix comment for teh case when serial number is not available in patch 1 Changes since v2: - Reorder patches [patch five -> patch two] Changes since v3: - Add reviewed-bys from Greg - Fix build warning when debugfs is disabled - Remove extra checks for dir creations in patch 5 Vaishali Thakkar (5): base: soc: Add serial_number attribute to soc base: soc: Export soc_device_register/unregister APIs soc: qcom: Add socinfo driver soc: qcom: socinfo: Expose custom attributes soc: qcom: socinfo: Expose image information Documentation/ABI/testing/sysfs-devices-soc | 7 + drivers/base/soc.c | 9 + drivers/soc/qcom/Kconfig | 8 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/smem.c | 8 + drivers/soc/qcom/socinfo.c | 573 ++++++++++++++++++++ include/linux/sys_soc.h | 1 + 7 files changed, 607 insertions(+) create mode 100644 drivers/soc/qcom/socinfo.c -- 2.17.1