Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3242134imu; Sat, 24 Nov 2018 00:54:16 -0800 (PST) X-Google-Smtp-Source: AJdET5fplfXZ67zaGrI8/tyKSYnHbEBxswJKFfQLqPMuWgTQ6WsFUPuOv/XVFFrjfr+48YnVKYlH X-Received: by 2002:a63:fc49:: with SMTP id r9mr16773415pgk.209.1543049656882; Sat, 24 Nov 2018 00:54:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543049656; cv=none; d=google.com; s=arc-20160816; b=bYOkFrQdfP8KmIE9AUuUF/Oe097Zr/kudlhcd42FhMVgNwzLeQ3j6xUo62+pMj7oFr hp8oo/979SMDYPQtwBnJObMfALERPaL3xtQ9F3vC3a4HVnHbSDPqufyytT1bEBRqPjpC BdQ0MqSRcjv823kc5TBziD5QqDZqR0tXNxjrLyJKsCfkxEkDXJSfvgVB3udbQT/S0dK1 CcYVNFeKhCJXHSCYOmocLFrK0I6YwplfbAdeQrWMhL/MLv1y5cz8dPNhfk58IYaszKU2 r1prjvxnAns6at+qiyYm8cRP6uNvTGAK96hERE5sSeCprFEZK6GDLgUfM6wrBGo9e55B bSvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=wWwgYELQR4NJiCKnpyiIpG6SBEFLfyCHNdh9san7iC8=; b=mguLM8crSea4HQWWZr8ny78qR4lTEpzkApczlCvg4HL7gAQ9LONg9C7Pf2P/MR7+M3 hT4FlsjZZGNZ44zRbXBg9nXZbsjVw1y6RQ8BesRvb4E1O7oJe9j+B+NDnEoY/mcuZyAd x+7qm/xDlhsU28BpHrf7eWm/mT9Kkbu5/Yyg84B/K2MnzxwVBbOp6JbIgoCOifGhmJFt FWZQbf3VuAk/Xo1ONKRYLcaOkEhQjUyDUuc584zmlWGtBuW69bETkQ7cuqlLoacJffV0 Ao2oMJGgejJRebrQTshGUis5dvaTJyQiWLqmIVfRHNrXbJc83j94Yi2kKIRTukvPzBC3 Lktw== ARC-Authentication-Results: i=1; mx.google.com; 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 v9si48791093pgt.464.2018.11.24.00.54.02; Sat, 24 Nov 2018 00:54:16 -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; 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 S1727716AbeKXKIT (ORCPT + 99 others); Sat, 24 Nov 2018 05:08:19 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:40720 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727607AbeKXKIT (ORCPT ); Sat, 24 Nov 2018 05:08:19 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id A367B8080F; Sat, 24 Nov 2018 00:22:02 +0100 (CET) Date: Sat, 24 Nov 2018 00:22:04 +0100 From: Pavel Machek To: Enric Balletbo i Serra Cc: linux-pm@vger.kernel.org, sre@kernel.org, Sameer Nanda , gwendal@chromium.org, linux-kernel@vger.kernel.org, groeck@chromium.org, Adam.Thomson.Opensource@diasemi.com, kernel@collabora.com, bleung@chromium.org, "Rafael J. Wysocki" , Len Brown Subject: Re: [PATCH v2 1/2] power: supply: add input voltage limit property. Message-ID: <20181123232203.GA3852@amd> References: <20181122101119.29194-1-enric.balletbo@collabora.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20181122101119.29194-1-enric.balletbo@collabora.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > We have a problem with USBPD chargers which under certain conditions > can result in system overheating if the voltage provided by the USBPD > port is too high. While the preferred means to control this would be > through devicetree or ACPI settings, this is not always possible, and > we need to have a means to set a voltage limit. >=20 > This patch exposes a new property, similar to input current limit, to > re-configure the maximum voltage from the external supply at runtime > based on system-level knowledge or user input. First, this should really be handled by dt / ACPI. If it is broken, that's a hardware bug, and we can do DMI-based blacklists in kernel. How are you supposed to fsck a system, for example? > +What: /sys/class/power_supply//input_voltage_limit > +Date: Nov 2018 > +Contact: linux-pm@vger.kernel.org > +Description: > + Details the incoming VBUS voltage limit currently set in the > + supply. Normally this is configured based on the type of > + connection made. "Details"? Who can write to this value and when? What is the limit? If USB charger is plugged in, should it show 5.0V (because that's nominal on the USB) or 5.25V (because that is the real limit)? Who can write to this and when. And what happens on write? What happens if I write value that charger can't provide there? Does it set the voltage power supply should produce? Or maximal it can choose to produce? This really needs better documentation. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlv4i5sACgkQMOfwapXb+vLmQACfX+ba61v27dkM11pVow8bPETy A+QAnjhSC4iTF6CvFqR/AUcL8p7j1D8i =fgBu -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--