From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752078AbcJJVAI (ORCPT ); Mon, 10 Oct 2016 17:00:08 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:47460 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751590AbcJJVAF (ORCPT ); Mon, 10 Oct 2016 17:00:05 -0400 Date: Mon, 10 Oct 2016 13:59:26 -0700 From: Guenter Roeck To: Chris Packham Cc: "linux-hwmon@vger.kernel.org" , Masahiko Iwamoto , Joshua Scott , Kevin Tsai , Wolfram Sang , Rob Herring , Mark Rutland , Jean Delvare , Jonathan Corbet , "linux-i2c@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" Subject: Re: [PATCHv3] hwmon: Add tc654 driver Message-ID: <20161010205926.GA16967@roeck-us.net> References: <20161007182939.GA9031@roeck-us.net> <20161009221222.29409-1-chris.packham@alliedtelesis.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 10, 2016 at 08:08:14PM +0000, Chris Packham wrote: > On 10/11/2016 02:22 AM, Guenter Roeck wrote: > >> + if (val) > >> > + data->config |= TC654_REG_CONFIG_DUTYC; > >> > + else > >> > + data->config &= ~TC654_REG_CONFIG_DUTYC; > > I just realized that this won't work as intended. Problem is that you > > only fill data->config when reading an attribute. So, if a set function > > is called prior to reading an attribute, data->config will be 0, and > > you end up overwriting the original configuration. > > > > Should I just read it in the probe function or fill it in with the > documented hardware defaults? Reading it would be better - that leaves the option open that it was configured by ROMMON or BIOS. Guenter