Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1944688imm; Thu, 18 Oct 2018 06:49:47 -0700 (PDT) X-Google-Smtp-Source: ACcGV62crVbBSy9y1Za6tD0fSHpPZdCIFBe39TVTZVA+JNHaRqJqR4XEzBzj4NDCzdu47HiMhqCh X-Received: by 2002:a63:4e18:: with SMTP id c24-v6mr23964818pgb.6.1539870587249; Thu, 18 Oct 2018 06:49:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539870587; cv=none; d=google.com; s=arc-20160816; b=N4O6KOAcX6Uvb8rMkJkCeMcIwdS22ar7gQbcEqFF6UjBiPHOpos1cdqnQwwCEs0oJJ d59vnPcACC4505itlRKrtLqQOjBnf8/diVI03fpfqAcGlmRhRRpumNPesvD/v8cUlupd YgOy63WfBAVKqDAh+pEciq9JNlPRJSn0K5r0Xm8UZ3MbtnirHdGvOcFu6EoOgtvz+oAD 7kfL5/B8Nx/F522GkUNWb05BHMBJHz9iK+QBxt8DJVHSo2NDB+pz1yEJ4J4VuIN2Hgwk up/jlYGVP5n131DglDhwHDvwnB5CTyPFsBIaMs+eTScHbgXIDHpVoilC7wmByPMqs90u CfPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=nOUqgsLalH2b3niyB618xYBjNP3sFmj4HBaC5HNiQmg=; b=uDrnhhaRhgpVpkB3Ve0qExQhACRLibbzbSkpny8Ue8rJyw5YfwvB/hzhJYdqq0nF9c C37RI9s1RWtxkPR8nbQ7wBnd/jk8+x5/EcZSqpJQiYEoRP2Y0pZbApwWV14+QstlGtIz kAiLZs+95uqmu0Z5bBUzvP4rhPEkvqFZ+8ACqWo73gMOhw5PDYz+D+7d3JreeIbcNyEl 6McGvah+xQ45z/pEAZkfdZwOUg0sMhs/6Bg3HAmlHFBImaYuu7QXziZNZp9QUB7z1Stb PybzTr0cRtpVrZOarfNLX3beeT7j+B1xlBpf854BqO6me/XWMEzaziwaUrMwBziPDlAR 7SLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=PTnGF1hL; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b65-v6si21760231pfa.92.2018.10.18.06.49.31; Thu, 18 Oct 2018 06:49:47 -0700 (PDT) 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=fail header.i=@gmail.com header.s=20161025 header.b=PTnGF1hL; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728192AbeJRVsI (ORCPT + 99 others); Thu, 18 Oct 2018 17:48:08 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:43824 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728143AbeJRVsI (ORCPT ); Thu, 18 Oct 2018 17:48:08 -0400 Received: by mail-pl1-f195.google.com with SMTP id 30-v6so14339310plb.10; Thu, 18 Oct 2018 06:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nOUqgsLalH2b3niyB618xYBjNP3sFmj4HBaC5HNiQmg=; b=PTnGF1hL1pc8hODZgOKbZFSI+0SPc1Teq4EGlaWtA6+bxrN7J4NZSkZ/KZQ19BNRai RnGWdtXJv1AL1x7ApZoU8TU1knUx5AHYOKG/aylHMqKv789xp+OpQTqtInMIa+5lhQZv Dcy+5iaTUWnbGDLhE+d/9rsEpBrwsThzXyEpHUJgA6ZWkpyGDDvmRKbvbuOk1AIc/Kzy KBQoOBT39e4s3y1vpYAmyLU2/7xFPGL/rHEgyA4bc4r2LIqh0/6Uh9z49mJ/Hzxx0afd HOztuT9qVqkuChba4J3D1l38eNFFgWp/N3xRp51USThCwKM0DV2x3hlxbaFYNqfEiO71 7jaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nOUqgsLalH2b3niyB618xYBjNP3sFmj4HBaC5HNiQmg=; b=NsU7AaYe5TF8/jf0bANiQxS0tQG0nOAt5SSYsWsOZHCNumgi8FSRt/w0vm0kNbeO35 rk3osPfPOm06uF2zLiJ9W/OoVD0j+eFBCvj4MntcEvFtw+uNfF/ERmXU6/oDz2UkVwi6 1HOPFIAsLj68RKhelHrn+SKLJAkG2IQG0onz8jrThk0uAHeGm2ZVBKWAn5mlyrNwLISt nisELEN1Xt659ckX+YBoxSI/6Ac7pK74bi6nbJ1g8wOWIfz/XI64itjxwQAhJqjdQM9M Z0VpwHCoRTmR7X2cOsYSYyPN3+PPuuP3VN274toQgK3lP4pk8dpOBIdTm0GdZI4+aAxX OUtg== X-Gm-Message-State: ABuFfoiv9bu1cjvZ/RpqeNxS5ApU2kEz7CuZbqFJpZRqteAV+BUJG+AA cqCKdXI5nmRYXXhO8ry6fU5wC/XX X-Received: by 2002:a17:902:7203:: with SMTP id ba3-v6mr20037993plb.321.1539870420969; Thu, 18 Oct 2018 06:47:00 -0700 (PDT) Received: from server.roeck-us.net (108-223-40-66.lightspeed.sntcca.sbcglobal.net. [108.223.40.66]) by smtp.gmail.com with ESMTPSA id o2-v6sm35079045pgi.62.2018.10.18.06.46.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Oct 2018 06:47:00 -0700 (PDT) Subject: Re: [PATCH 2/2] hwmon: (isl68137) add accessors to enable/disable AVS mode To: Kun Yi Cc: openbmc@lists.ozlabs.org, Robert Lippert , Jean Delvare , linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org References: <20181017225622.8366-1-kunyi@google.com> From: Guenter Roeck Message-ID: <8c1fdf5d-0d54-da8b-a11d-0e74ea8ce974@roeck-us.net> Date: Thu, 18 Oct 2018 06:46:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181017225622.8366-1-kunyi@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/17/2018 03:56 PM, Kun Yi wrote: > From: Robert Lippert > > This patch adds sysfs files avs(0|1)_enabled underneath the I2C device > to control the AVS state of each rail and perform the appropriate > hacks when enabling AVS. > > The ISL68137 has issues wrt AVS operation mode that require it > to be enabled/disabled at runtime. > This is quite unusual. This would usually be handled in ROMMON/BIOS for devices like this. What are those issues ? > Additionally enabling AVS mode requires a hack to set the VOUT value > before enabling to make sure that the device does not switch to > an old cached AVS provided value and is instead in a "clean" state > before booting. > > Signed-off-by: Robert Lippert > Signed-off-by: Kun Yi > --- > drivers/hwmon/pmbus/isl68137.c | 120 ++++++++++++++++++++++++++++++++- > 1 file changed, 118 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwmon/pmbus/isl68137.c b/drivers/hwmon/pmbus/isl68137.c > index 2a5322e4a286..94e2894f13bc 100644 > --- a/drivers/hwmon/pmbus/isl68137.c > +++ b/drivers/hwmon/pmbus/isl68137.c > @@ -19,8 +19,11 @@ > #include > #include > #include > +#include > #include "pmbus.h" > > +#define ISL68137_VOUT_AVS 0x30 > + > static struct pmbus_driver_info isl68137_info = { > .pages = 2, > .format[PSC_VOLTAGE_IN] = direct, > @@ -56,10 +59,123 @@ static struct pmbus_driver_info isl68137_info = { > | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT | PMBUS_HAVE_POUT, > }; > > +static ssize_t isl68137_avs_enable_show_page(struct i2c_client *client, > + int page, > + char *buf) > +{ > + int val = pmbus_read_byte_data(client, page, PMBUS_OPERATION); > + > + return sprintf(buf, "%d\n", > + (val & ISL68137_VOUT_AVS) == ISL68137_VOUT_AVS ? 1 : 0); > +} > + > +static ssize_t isl68137_avs_enable_store_page(struct i2c_client *client, > + int page, > + const char *buf, size_t count) > +{ > + int rc, op_val; > + > + if (count < 1) { > + rc = -EINVAL; > + goto out; > + } > + > + switch (buf[0]) { > + case '0': > + op_val = 0; > + break; > + case '1': > + op_val = ISL68137_VOUT_AVS; > + break; > + default: > + rc = -EINVAL; > + goto out; > + } > + Please use kstrtobool(). > + /* > + * Writes to VOUT setpoint over AVSBus will persist after the VRM is > + * switched to PMBus control. Switching back to AVSBus control > + * restores this persisted setpoint rather than re-initializing to > + * PMBus VOUT_COMMAND. Writing VOUT_COMMAND first over PMBus before > + * enabling AVS control is the workaround. > + */ > + if (op_val == ISL68137_VOUT_AVS) { > + int vout_command = pmbus_read_word_data(client, page, > + PMBUS_VOUT_COMMAND); > + rc = pmbus_write_word_data(client, page, PMBUS_VOUT_COMMAND, > + vout_command); > + if (rc) > + goto out; Does it make a difference if bit 1 is set in the operation register ? > + } > + > + rc = pmbus_update_byte_data(client, page, PMBUS_OPERATION, > + ISL68137_VOUT_AVS, op_val); > + > +out: > + return rc < 0 ? rc : count; > +} > + > +static ssize_t isl68137_avs_enable_show(struct device *dev, > + struct device_attribute *devattr, > + char *buf) > +{ > + struct i2c_client *client = kobj_to_i2c_client(&dev->kobj); > + struct sensor_device_attribute_2 *attr = to_sensor_dev_attr_2(devattr); > + > + return isl68137_avs_enable_show_page(client, attr->index, buf); > +} > + > +static ssize_t isl68137_avs_enable_store(struct device *dev, > + struct device_attribute *devattr, > + const char *buf, size_t count) > +{ > + struct i2c_client *client = kobj_to_i2c_client(&dev->kobj); > + struct sensor_device_attribute_2 *attr = to_sensor_dev_attr_2(devattr); > + > + return isl68137_avs_enable_store_page(client, attr->index, buf, count); > +} > + > +static SENSOR_DEVICE_ATTR_2(avs0_enabled, 0644, > + isl68137_avs_enable_show, isl68137_avs_enable_store, > + 0, 0); > +static SENSOR_DEVICE_ATTR_2(avs1_enabled, 0644, > + isl68137_avs_enable_show, isl68137_avs_enable_store, > + 0, 1); > + Why ATTR_2 ? That seems quite pointless. I would suggest to use _enable as attribute name, but I understand this is POV, so I won't insist on it. > +static int isl68137_remove(struct i2c_client *client); > + Please move the remove function to this location. > static int isl68137_probe(struct i2c_client *client, > const struct i2c_device_id *id) > { > - return pmbus_do_probe(client, id, &isl68137_info); > + int rc; > + > + rc = pmbus_do_probe(client, id, &isl68137_info); > + if (rc) > + return rc; > + > + rc = device_create_file(&client->dev, > + &sensor_dev_attr_avs0_enabled.dev_attr); > + if (rc) > + goto out_fail; > + rc = device_create_file(&client->dev, > + &sensor_dev_attr_avs1_enabled.dev_attr); > + if (rc) > + goto out_fail; > + This creadtes the device files after the hwmon device is created, which may confuse userspace if it is triggered by the creation of the hwmon device. You might consider creating the device files before registering the hwmon device. That makes removal on error a bit more complex, though, so I'll leave it up to you. > + return rc; > + > +out_fail: > + isl68137_remove(client); > + return rc; > +} > + > +static int isl68137_remove(struct i2c_client *client) > +{ > + device_remove_file(&client->dev, > + &sensor_dev_attr_avs1_enabled.dev_attr); > + device_remove_file(&client->dev, > + &sensor_dev_attr_avs0_enabled.dev_attr); > + return pmbus_do_remove(client); > } > > static const struct i2c_device_id isl68137_id[] = { > @@ -75,7 +191,7 @@ static struct i2c_driver isl68137_driver = { > .name = "isl68137", > }, > .probe = isl68137_probe, > - .remove = pmbus_do_remove, > + .remove = isl68137_remove, > .id_table = isl68137_id, > }; > >