From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751657AbdF1Shd convert rfc822-to-8bit (ORCPT ); Wed, 28 Jun 2017 14:37:33 -0400 Received: from mx12-04.smtp.antispamcloud.com ([46.165.232.174]:47427 "EHLO mx12-04.smtp.antispamcloud.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751552AbdF1ShY (ORCPT ); Wed, 28 Jun 2017 14:37:24 -0400 X-Greylist: delayed 3814 seconds by postgrey-1.27 at vger.kernel.org; Wed, 28 Jun 2017 14:37:23 EDT Subject: Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes To: Tom Levens , Guenter Roeck CC: , , , , , References: <1479384616-12479-1-git-send-email-tom.levens@cern.ch> <1479384616-12479-3-git-send-email-tom.levens@cern.ch> <410de6c9-a13e-51f7-4d66-6f4e2537c574@roeck-us.net> <97eb089f-e0e2-1146-6e17-8f9f790433d8@topic.nl> <20170628150130.GC30968@roeck-us.net> <20170628160048.GA8915@roeck-us.net> From: Mike Looijmans Organization: Topic Message-ID: Date: Wed, 28 Jun 2017 19:33:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8BIT X-Originating-IP: [85.150.144.104] X-EXCLAIMER-MD-CONFIG: 9833cda7-5b21-4d34-9a38-8d025ddc3664 X-EXCLAIMER-MD-BIFURCATION-INSTANCE: 0 X-Originating-IP: 37.74.225.130 X-SpamExperts-Domain: topic.nl X-SpamExperts-Username: 37.74.225.128/28 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=37.74.225.128/28@topic.nl X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: SB/global_tokens (0.00352708645617) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgWMD8gia7lRmdoHJ3n0cm6Vtfp9X1ZBchZ wvx8a7dTUQWF0kx98HH3GX+iQK7NiP6LBDMrD7q/cJogwbqzsuokIXMJ1U4MKKnQ5SAJ1V9dkP9x bu57BDazLmklZgT7xzZqY5dfi5RkdBN6Knhl3jvqOzOV9JWZk8Nt9HxXbg2Yo7DfejW6sacPfXAE /f5z7808CVsONrMJuGzuoGnKTKcygLJjfy2/hUPxxGqITycuLMdYaphGvYopQ24KJ9kgRDN3pbXn aMbbC1QSUBxihEsjBWOBqoptsYkcljagCMIDypReAQCFQo+KUtaSCrVTlxOfVsst/QEVbupaaYfx KYRJ8ar4sO9kYmr7/nmchPR9GwS0RTbIegwn2yn+XE4z9zMbAT/bTGM3eqpSRQBxZnohuyBbIx9U xSOli5tujyyPNWHibQ3+V3iYt+afP2Sd1OkZQGxcFxcrkq+IKIlinlm7VgW9/bktU41htiJ8fk7N kPOW6bvL9DC431WlF1LxckxMBAJkcsAhDD4OTTRkzMU8KuR9h4rJ1IhRjQc5xQiShHo5ONIssfIU D5m5CWmx71BFRFR4qXE7Cn+3zlGq5KdMR0tMwLh/UfgIMsW8UawravVdyPOcJwZf+mGEJuzRRI9j 8a0kKat+q1pDwG1CWLxsLs5/vZ6iv59Wo734FSnl5VkcaDlGvF6Pw75S1086vWfgm2M8nhHp+3/+ WJ/XJiksqOOz7IUQtphxWIUbM+lycZ4p8ZaiLmU7c9qpkE1nyDDnsXEBAaJKYpjfiKWbEgl33T/9 5Zg5CE3AhA2+uctitKL22lf4d/8+AtNKUJvxp4twfjb4YkpLfRRl121wddJvjRhAjL9lMIHF5vgg O8MHjwB47UPjgLhl68nWrF2U7GblysSYiQm4L0ASxbMDmwKRFELkruE7aM/cu4JjzYS68fnYbpxM 21arqL72ZU4Vz5gsrnEOub1CRMaKL4fy8bjRp+t5Fd+NyNribdE3ety/gOpO6OZGArYx3jVR0FzG bpLh0p3Bsb0ltx9a12F9jKjdrLpd9qo77oWEEd2hipSN+A2FxVgE7SkvtWKxkgySOE0DTOh+1u7U VCWKDvp+B6is X-Report-Abuse-To: spam@quarantine2.antispamcloud.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28-06-17 19:02, Tom Levens wrote: > > On Wed, 28 Jun 2017, Guenter Roeck wrote: > >> On Wed, Jun 28, 2017 at 05:29:38PM +0200, Tom Levens wrote: >>> >> [ ... ] >> >>>> >>>>> Whatever happened to this patch though? It didn't make it to mainline, >>>>> otherwise I'd have found it sooner... >>>>> >>>> I'll have to look it up, but I guess I didn't get an updated version. >>> >>> As far as I remember I had a working V3 of this patch, but it is >>> entirely >>> possible that it was never submitted as I have been busy with other >>> projects >>> recently. I'll dig it out and check that it is complete. >>> >> FWIW, I don't see it at >> https://patchwork.kernel.org/project/linux-hwmon/list/?submitter=171225&state=* >> >> >> Maybe you were waiting for a reply from Rob. Either case, it might make >> sense to only provide valid modes, ie to abstract the mode bits from the >> hardware, such as >> >> 0 - internal temp only >> 1 - Tr1 >> 2 - V1 >> 3 - V1-V2 >> 4 - Tr2 >> 5 - V3 >> 6 - V3-V4 >> 7 to 14 - per bit 0..2 >> >> Guenter >> > > You are right, there was still an open question about how best to handle > the mode selection in DT. > > In the latest version of my patch I have it implemented as an array for > setting the two values, for example: > > lltc,meas-mode = <7 3>; > > This sets bits [2..0] = 7 and [4..3] = 3. Of course these could be split > into two DT properties, but I was unsure what to name them as both > fields are called "mode" in the datasheet and "mode-43"/"mode-20" (or > similar) is ugly. > > With regards to your proposal, it is not clear to me whether the modes > which have the same result are exactly equivalent. Does disabling a > measurement with the mode[4..3] bits really leaves the part in a safe > state for all possible HW connections? With this doubt in my head, I > would prefer to keep the option available to the user to select any > specific mode. But I am open to suggestions. Well, the input restrictions always apply, so disabling V3 measurement doesn't imply that you can apply 20V to that input safely now. I'd suggest to set unused input to plain voltage measurement. That is "passive" and safe for external components. So I'd suggest just setting the mode as per device datasheet, I can see no real advantage in abstracting it away and forcing users to read yet another document to get it right, e.g.: lltc,mode = <6>; As for the input disabling, since I doubt anyone would use it (why purchase a 4-channel device and use only 2), just add two booleans, e.g. "disable-inputs-34" and "disable-inputs-12" which set the command bits appropriately, and change the mode such that the disabled inputs are voltage readout only. A case could even be made for changing mode at runtime. This allows using it to measure both current and voltage on two inputs, by reading V1, and V3, and then switch mode to obtain (accurate) V1-V2 and V4-V3. That might be a viable way to handle not setting the mode at all. If the mode can be selected via sysfs, the driver can keep the device in a "safe" mode until the mode has been selected. > Mike, if you would like to test it, the latest version of my code is here: > > https://github.com/levens/ltc2990/blob/dev/drivers/hwmon/ltc2990.c Sure, I even have a board with 2 of these devices now :) -- Mike Looijmans Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijmans@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail