| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <8e4bcf7d-aa43-6745-2ade-9123c8d182ef@linux.intel.com>
Date: Wed, 2 Jan 2019 10:22:18 -0800
From: Jae Hyun Yoo <jae.hyun.yoo@...ux.intel.com>
To: Lee Jones <lee.jones@...aro.org>
Cc: Rob Herring <robh+dt@...nel.org>, Jean Delvare <jdelvare@...e.com>,
Guenter Roeck <linux@...ck-us.net>,
Mark Rutland <mark.rutland@....com>,
Joel Stanley <joel@....id.au>,
Andrew Jeffery <andrew@...id.au>,
Jonathan Corbet <corbet@....net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
Kishon Vijay Abraham I <kishon@...com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
"Darrick J . Wong" <darrick.wong@...cle.com>,
Eric Sandeen <sandeen@...hat.com>,
Arnd Bergmann <arnd@...db.de>, Wu Hao <hao.wu@...el.com>,
Tomohiro Kusumi <kusumi.tomohiro@...il.com>,
"Bryant G . Ly" <bryantly@...ux.vnet.ibm.com>,
Frederic Barrat <fbarrat@...ux.vnet.ibm.com>,
"David S . Miller" <davem@...emloft.net>,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Randy Dunlap <rdunlap@...radead.org>,
Philippe Ombredanne <pombredanne@...b.com>,
Vinod Koul <vkoul@...nel.org>,
Stephen Boyd <sboyd@...eaurora.org>,
David Kershner <david.kershner@...sys.com>,
Uwe Kleine-Konig <u.kleine-koenig@...gutronix.de>,
Sagar Dharia <sdharia@...eaurora.org>,
Johan Hovold <johan@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Juergen Gross <jgross@...e.com>,
Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
openbmc@...ts.ozlabs.org,
James Feist <james.feist@...ux.intel.com>,
Jason M Biils <jason.m.bills@...ux.intel.com>,
Vernon Mauery <vernon.mauery@...ux.intel.com>
Subject: Re: [PATCH v9 08/12] mfd: intel-peci-client: Add PECI client MFD
driver
Hi Lee,
On 12/21/2018 6:46 AM, Lee Jones wrote:
> On Tue, 18 Dec 2018, Jae Hyun Yoo wrote:
>
>> This commit adds PECI client MFD driver.
>>
<snip>
>>
>> +config MFD_INTEL_PECI_CLIENT
>> + bool "Intel PECI client"
>> + depends on (PECI || COMPILE_TEST)
>> + select MFD_CORE
>> + help
>> + If you say yes to this option, support will be included for the
>> + Intel PECI (Platform Environment Control Interface) client. PECI is a
>> + one-wire bus interface that provides a communication channel from PECI
>> + clients in Intel processors and chipset components to external
>> + monitoring or control devices.
>
> This driver doesn't appear to actually do anything that can't be done
> in a header file i.e. match some static data with a CPU ID. The child
> devices can be registered by whatever registers this device.
>
> It seems superfluous. Why do you need it?
>
The main reason I added it is to provide a way for sharing the same unit
address from multiple side-band function drivers that read 'reg'
property setting from the parent node (this driver's node). The 'reg'
property reading code is not in this driver but it will be performed in
peci-core when this driver is registered using
module_peci_driver(peci_client_driver), and then it will provides
client->addr information for all its child node drivers.
<snip>
>> +#include <linux/bitfield.h>
>> +#include <linux/mfd/core.h>
>> +#include <linux/mfd/intel-peci-client.h>
>> +#include <linux/module.h>
>> +#include <linux/peci.h>
>> +#include <linux/of_device.h>
>
> Alphabetical.
>
Will fix it. Thanks!
<snip>
>> +enum cpu_gens {
>> + CPU_GEN_HSX = 0, /* Haswell Xeon */
>> + CPU_GEN_BRX, /* Broadwell Xeon */
>> + CPU_GEN_SKX, /* Skylake Xeon */
>> +};
>
> This is unused.
>
This is being used in 8 lines below but actually the static array can be
initialized without using this enum type. Will remove it.
>> +static struct mfd_cell peci_functions[] = {
>> + { .name = "peci-cputemp", },
>> + { .name = "peci-dimmtemp", },
>> + /* TODO: Add additional PECI sideband functions into here */
>> +};
>> +
>> +static const struct cpu_gen_info cpu_gen_info_table[] = {
>> + [CPU_GEN_HSX] = {
>> + .family = 6, /* Family code */
>> + .model = INTEL_FAM6_HASWELL_X,
>> + .core_max = CORE_MAX_ON_HSX,
>> + .chan_rank_max = CHAN_RANK_MAX_ON_HSX,
>> + .dimm_idx_max = DIMM_IDX_MAX_ON_HSX },
>> + [CPU_GEN_BRX] = {
>> + .family = 6, /* Family code */
>> + .model = INTEL_FAM6_BROADWELL_X,
>> + .core_max = CORE_MAX_ON_BDX,
>> + .chan_rank_max = CHAN_RANK_MAX_ON_BDX,
>> + .dimm_idx_max = DIMM_IDX_MAX_ON_BDX },
>> + [CPU_GEN_SKX] = {
>> + .family = 6, /* Family code */
>> + .model = INTEL_FAM6_SKYLAKE_X,
>> + .core_max = CORE_MAX_ON_SKX,
>> + .chan_rank_max = CHAN_RANK_MAX_ON_SKX,
>> + .dimm_idx_max = DIMM_IDX_MAX_ON_SKX },
>> +};
>> +
>> +static int peci_client_get_cpu_gen_info(struct peci_client_manager *priv)
>> +{
>> + u32 cpu_id;
>> + u16 family;
>> + u8 model;
>> + int rc;
>
> ret is almost ubiquitous in the kernel. Please use it instead.
>
Okay. Will change rc to ret.
<snip>
>> +static int peci_client_probe(struct peci_client *client)
>> +{
>> + struct device *dev = &client->dev;
>> + struct peci_client_manager *priv;
>> + uint cpu_no;
>> + int ret;
>> +
>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + dev_set_drvdata(dev, priv);
>> + priv->client = client;
>> + priv->dev = dev;
>
> If you have client (Which contains dev, you don't need dev).
>
Makes sense. Will remove the 'dev' member.
<snip>
Powered by blists - more mailing lists