Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2385411ybv; Mon, 24 Feb 2020 04:23:08 -0800 (PST) X-Google-Smtp-Source: APXvYqwT1rIV0g2uZmgCAXlwxomyshkAJbvYe8nNypc0EKd1n4OCBxbxcIFOSq2cgtHP2bd45OBU X-Received: by 2002:a05:6830:194:: with SMTP id q20mr41147591ota.92.1582546988405; Mon, 24 Feb 2020 04:23:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582546988; cv=none; d=google.com; s=arc-20160816; b=0TvIR9sRR4OLcKFmbXCuLWOE6Pv2MpMLA6fklb9God/bZWka5mMk6zytAnNU/wNwQO IeqvxpiXTQPhcXZHuXqMH07Hf/0Zbz/iPulLkPqq5Ow3Oehjo8lyj1kyGNKAyXw/6n/J VqBoKOsB+WuoJ6ah/A0NHicIpBxzaOBrkTwrDFHb99WNLhCI5pgSkYKRH5KObGLwv9mw sAGrDapBeGg8ZtxACZaI7orNhZbyHlw6+0ptfSEBWq7AydZObE8b/cHq0jSDTAZte/aa v6S1aLrwroT73y/lggjHk6/Ts9GfZnIDp4TzW6lezXFUnWRfOVwIlCqcaS3+w2katQNG VVhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:mime-version :subject:dkim-signature; bh=TYqSvUHnKRu+yShrvah+Qsj8w8sJdF2qEWjg9EH8XEI=; b=ElQ+rjESovj0S2+KcOoohwZOMdcV9tTCq+rTDQLz9vAm+XbY91FMQ0jNUzuVOw7288 EXwl67rOUEB+1t4vknMgDlDQMDHZZWMiqFHLCoSiwaeJIkh7T/EYmFWau7WhAo9ym4dd /ma0W8xdG1R7FJKYx2I9Pt1hw1++Gfry94BuaNBcFrlycvAUBytuaplde7nop5kVfAfh tQvZPTYYkkJDvbfJGHWqVA9WaEQzu6/ua8Qd1Dw5wPZVYJfwz/3tJvidSoMqi6A5Fw9e 65VZWk14AX3BQXsmy9CfVlLRXbhjmbDnjTJLNj2pAinQgVqTaru9h9vsjo0+eFL1voVG Dzjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@goldelico.com header.s=strato-dkim-0002 header.b="KTnt4RV/"; 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 v21si759114otp.189.2020.02.24.04.22.55; Mon, 24 Feb 2020 04:23:08 -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=fail header.i=@goldelico.com header.s=strato-dkim-0002 header.b="KTnt4RV/"; 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 S1727329AbgBXMWf (ORCPT + 99 others); Mon, 24 Feb 2020 07:22:35 -0500 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.51]:36619 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726778AbgBXMWf (ORCPT ); Mon, 24 Feb 2020 07:22:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1582546951; s=strato-dkim-0002; d=goldelico.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=TYqSvUHnKRu+yShrvah+Qsj8w8sJdF2qEWjg9EH8XEI=; b=KTnt4RV/JVk3nNkt58WHNTdwKfvnzq+EJ8Sy1hPROU5AFtFTQCApM7YTk4/9ClpUSH NtZ1/JJcwXI9JRztXtjD7BMDXRPWVs8TKjBxwubnpK5o5Z+sMTrLTFvi0Xe9eqaTROo3 rc6Mlgow680OfsWXrAenAaKT+rYXljRekpoQLytiBDgfNtrCAKatvAyF8VTRisDqmnsZ PYv8F/Abu3i00cgN1mIGhqc7uuPMeNjG3Wg+cTGl8MigRddXB2xEbgWNe4s3cMMNt61B A9o8exNXqKBr3ORD9ibBrP5+wsiKcG7djmrRPO59x2iei0AD0b3k4vHBMrl0m6pYj5w3 GS1w== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj5Qpw97WFDlSbXA0N0JQ=" X-RZG-CLASS-ID: mo00 Received: from imac.fritz.box by smtp.strato.de (RZmta 46.1.12 DYNA|AUTH) with ESMTPSA id U06217w1OCMMojH (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Mon, 24 Feb 2020 13:22:22 +0100 (CET) Subject: Re: [PATCH RFC] regulator: core: fix handling negative voltages e.g. in EPD PMICs Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: "H. Nikolaus Schaller" In-Reply-To: <20200224120512.GG6215@sirena.org.uk> Date: Mon, 24 Feb 2020 13:22:21 +0100 Cc: Andreas Kemnade , j.neuschaefer@gmx.net, contact@paulk.fr, GNUtoo@cyberdimension.org, josua.mayer@jm0.eu, lgirdwood@gmail.com, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <1548203B-9D64-4128-9BED-D3BC30F9DC49@goldelico.com> References: <20200223153502.15306-1-andreas@kemnade.info> <20200224120512.GG6215@sirena.org.uk> To: Mark Brown X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Am 24.02.2020 um 13:05 schrieb Mark Brown : >=20 > On Sun, Feb 23, 2020 at 04:35:01PM +0100, Andreas Kemnade wrote: >=20 >> An alternative would be to handle voltages as absolute values. >> There are probably no regulators with support both negative >> and positive output. >=20 > This is what'd be needed, your approach here is a bit of a hack and > leaves some values unrepresentable if they overlap with errnos which > obviously has issues if someone has a need for those values. Negative ERRNOs have BIT(31) set. Since voltage integers on a 32 bit architecture represent =C2=B5V this = would still allow voltages up to (2^31 - 1) =C2=B5V i.e. 2 kV with BIT(31) not = set. Therefore it seems very unlikely that anyone needs to represent voltages above 2 kV within a Linux system through a regulator. So I'd say any negative return value got regulator_get_voltage() can be treated as an error. And regulators for negative voltages could be represented by their absolute value (and maybe a _neg component in the regulator name). But then it seems to be a little inconsistent that the voltage parameters of regulator_set_voltage_unlocked() are signed integers and not unsigned. So shouldn't that be protected against attempting to set negative = voltages? Just my 2 cts. BR, Nikolaus=