Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp6284imb; Thu, 28 Feb 2019 14:13:29 -0800 (PST) X-Google-Smtp-Source: AHgI3IawwHeEg30khJ31Kn3UY8vEcxxByw4F45jJBHFix4SGEONtzePvtwcpQ6AhFkctMZ4LvzrE X-Received: by 2002:a62:bd09:: with SMTP id a9mr1907874pff.61.1551392009853; Thu, 28 Feb 2019 14:13:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551392009; cv=none; d=google.com; s=arc-20160816; b=us2hXhE1RzsXbEq9NnBuoDGLrgaDQ62HFUF0TuHjY//EekpfSbU1WygGXZAkFKrncZ 2L3euJXiU2EhomM9lT0HWSc9GBv58wXjbAevE5es7ZYolySHkuqJn2A5PtxK7NrwRVf+ zG+IuY2zCxH5Z5xo8MEKjeCxWGuSI272Uo3AHac2zwE2EocWcSnLuJOsmNbSQsVGtLYm ABwmhRT9blUkcwy77D1ZavkgA35kYrmaNRPy7Ce/ZXgSBMmsTkXI7GYRFjdRuAoatBxV EZZmH0bpv3DDGfzAxmWZCdlhei0tHvM1/9fiLyJq7MNva6EDjTmD/6DhFNwN2mmOyNlr wxNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:user-agent:cc:from:references :message-id:subject:to:in-reply-to:content-transfer-encoding :mime-version:dkim-signature; bh=D1h9ezFO3KPZCHArKSsAZm/MhqFHuOM//IIWptMUdNQ=; b=BjrfVSCLgluu4/GOuBkcbmzcbPG7eI6kNvkoFWyhvo1LMHG8L0yqxDW3qUdVXOJLDd k6O6D1hhQ47mMnKneuZPVQHn2HmvWPMRqvGFv2T6ViD220DFRVtQT/4ftVTHMvAGciIF sSVFu3aP+RXHQOqREymGQ7zK3PI9Z1pQxIIT2Uwxghr0STMXPCzyfQuI/I2fJlyQD8JL 5fxNQdyeVz2od/0a/2iBX2LiLt7nOx9xj+0dGqOQ10rKrllmr11+UyqzjdbXk6md12C5 k7Ilc13YIVbZf5pNFZZAeDN/BYPhwB08nEOL0b8/TTlZ08yvGh65vF3uvOXYcJxhFjnv JRlw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=MAac8nvz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cs19si20951932plb.431.2019.02.28.14.13.14; Thu, 28 Feb 2019 14:13:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=MAac8nvz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729874AbfB1VcV (ORCPT + 99 others); Thu, 28 Feb 2019 16:32:21 -0500 Received: from mail-pg1-f194.google.com ([209.85.215.194]:43776 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727851AbfB1VcU (ORCPT ); Thu, 28 Feb 2019 16:32:20 -0500 Received: by mail-pg1-f194.google.com with SMTP id l11so10319577pgq.10 for ; Thu, 28 Feb 2019 13:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:content-transfer-encoding:in-reply-to:to:subject :message-id:references:from:cc:user-agent:date; bh=D1h9ezFO3KPZCHArKSsAZm/MhqFHuOM//IIWptMUdNQ=; b=MAac8nvzITEjdgwprFXnmCVFB5w062wjvqpzuenii2V/uYZ1GMUZRLF0RY3Z1BEk8L DPDu7UrTStm39s66YvmOaigpxJBJrHMS/0+s/6BWe1EZChpwbZU08rCOsZ4moQUGLBPm 0hSHxEpc1UihBSwxAn8J0RWIk/waDAfoi3nuM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :in-reply-to:to:subject:message-id:references:from:cc:user-agent :date; bh=D1h9ezFO3KPZCHArKSsAZm/MhqFHuOM//IIWptMUdNQ=; b=r3JfCL/Awkqufb/a1TgLo8oY8wp3kxap5bE6LXIrMrHZ/0IRmNAV8PktivU0HJgDlW V/VsvC1cl1NqxAzihosmkvGnPSJH3i/OfWCurdFz0Sr9Ayzdsk2OtLCWThgKfHY9Ayyi d5k/OJEGe/rf8R0cUOj9fE8Uwbcc82UNX9CbE2/Wmgsfh1z5zGWaDH4tLihD0x3bkMPo ApSeuGF/rCBVtALNQzZInRjB19DrpoZUcoUJ9w7er48gF7fN953mr84VV3y1SOdiEJ1R YUO9rpkDax5CskDGCNglkmV34vj4dSmh1463KVa6wjeAvlWYpB33ofsV9hVxv6haKvaO GJeQ== X-Gm-Message-State: APjAAAWn2o3+bBP7WIHKFqLv2gWzFK5PspTzcK2Bs//LUJ2wUreAOunc Tn7ld6B3+YjtqgWfvfI6c5KVDA== X-Received: by 2002:a62:f598:: with SMTP id b24mr1790754pfm.72.1551389539529; Thu, 28 Feb 2019 13:32:19 -0800 (PST) Received: from localhost ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id i126sm10857571pfb.15.2019.02.28.13.32.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 28 Feb 2019 13:32:18 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20190225065044.11023-5-vaishali.thakkar@linaro.org> To: Vaishali Thakkar , andy.gross@linaro.org Subject: Re: [PATCH v4 4/5] soc: qcom: socinfo: Expose custom attributes Message-ID: <155138953788.16805.6820097041346672619@swboyd.mtv.corp.google.com> References: <20190225065044.11023-1-vaishali.thakkar@linaro.org> <20190225065044.11023-5-vaishali.thakkar@linaro.org> From: Stephen Boyd Cc: david.brown@linaro.org, gregkh@linuxfoundation.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, rafael@kernel.org, bjorn.andersson@linaro.org, vkoul@kernel.org, Vaishali Thakkar User-Agent: alot/0.8 Date: Thu, 28 Feb 2019 13:32:17 -0800 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > }; > =20 > struct soc_of_id { > @@ -133,6 +160,171 @@ static const char *socinfo_machine(struct device *d= ev, unsigned int id) > return NULL; > } > =20 > +#ifdef CONFIG_DEBUG_FS > + > +#define UINT_SHOW(name, attr) \ > +static int qcom_show_##name(struct seq_file *seq, void *p) \ > +{ \ > + struct socinfo *socinfo =3D 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 =3D { = \ > + .open =3D qcom_open_##name, = \ > + .read =3D seq_read, = \ > + .llseek =3D seq_lseek, = \ > + .release =3D 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 =3D 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 =3D { = \ > + .open =3D qcom_open_##name, = \ > + .read =3D seq_read, = \ > + .llseek =3D seq_lseek, = \ > + .release =3D 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 =3D { = \ > + .open =3D qcom_open_##name, = \ > + .read =3D seq_read, = \ > + .llseek =3D seq_lseek, = \ > + .release =3D 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 =3D 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 =3D 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 =3D seq->private; > + int subtype =3D 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 =3D seq->private; > + int model =3D 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 =3D 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; > +} > +