Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1375614imu; Tue, 11 Dec 2018 18:49:28 -0800 (PST) X-Google-Smtp-Source: AFSGD/Ume1p2pHMNB/BRWEB7zEKVAQJw5c/7QbaN92Hn6tjiGQEUSsY8WN6RimVGtS/XPMYDYIuh X-Received: by 2002:a63:a112:: with SMTP id b18mr16936122pgf.440.1544582968308; Tue, 11 Dec 2018 18:49:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544582968; cv=none; d=google.com; s=arc-20160816; b=qX7dN3dHByFSL91aGTegBobgWgipUNmkXHhep6C7fuLhcbifnSquHuJ86vvI5BTtji tOsmtNQp6XNbZ5f0neXblJ2vnRNXd/Luh/0av7I5V0cwWFcKtjP1fUSJ8UxQcZF+j9EI 9X7REyJ8v7iDYvSVnhmozQGifHKPx+A2IgYkWuWc5pABANLoGnuLb0FQeCNg+RsXydkK DktHIqOTM3zncNS2si+Ybx16EwNsscVJMnpvIEkbfo3f4/xqpaPG+qDt9FBJbbzrhFT6 7tuj6SuCP7nyL3hu3C1cVsM+vRq0kZWJVAgA0hz2kkXdtJrCAQHH2hkDI0KW1QPO9T1p Vwow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=WgEp1E5C6Qu8djtqrwabIex9jJmfchIPo+nfg3wWEGI=; b=DtnqN35CjRFCdoIKJ4Qf/MeNl+O52rvgUN0AUTjUh1PxSrsOeoFyQxxTD2hGni/yJa qtLn2nN1qNg4KDZCKm/OFBRTLhpW3houciS+sgeWCTXKCXTKXxo1SneVS7pe9/Qlhqf+ EylaJZlJ1cjwu5OlGJQ1mWMEqa5asbDQ1xqhpOfSjebOG+882IszaYkWSusKImHEAOUT ORMqKW5jJaWg2/vjcAkSaTL5+Ej7iwM8nf0pa9KnS4YWAIVFLCc0He3egILZRTl9n4nB DuRZmixjsQIYXz1GQ+av08GP06A9Jvq4rqhgbWBLxRrvdCVUy+Gwa36u74lxd/8UMyHV LFIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=c0YhQLm9; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z14si13012263pga.349.2018.12.11.18.48.54; Tue, 11 Dec 2018 18:49:28 -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=pass header.i=@google.com header.s=20161025 header.b=c0YhQLm9; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726298AbeLLCrD (ORCPT + 99 others); Tue, 11 Dec 2018 21:47:03 -0500 Received: from mail-qt1-f171.google.com ([209.85.160.171]:43646 "EHLO mail-qt1-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726239AbeLLCrD (ORCPT ); Tue, 11 Dec 2018 21:47:03 -0500 Received: by mail-qt1-f171.google.com with SMTP id i7so18917376qtj.10 for ; Tue, 11 Dec 2018 18:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WgEp1E5C6Qu8djtqrwabIex9jJmfchIPo+nfg3wWEGI=; b=c0YhQLm9sMVeFuGWYuCYYnzSsPxkbEtrOqjrJdeIytA44LPcWs4KXlgxpjxhhGrQ/m XqTMTZu288obYrKK4p/9nyodeoAyELrUgDzs+yVbFEfN4T/1yoxe3hqA1mRcAZi4bsvo yYnIqn9QFiekwudhEZWH9F1Ep2vEEzi+nzoMBKizEoyav+EUx48XVaK5TUKEAi1sw62Q gdWT47C9/OLpzrLl7a2ZSjdfmoUBJww0akIXvE/WweeTWCFq3TWSGcXUMEh4GnZMzeRi urn1ALV7BDaYzr4Sqx3ttzhDglIPbKV2GAp78TCgPZGmFVL7E8M9AWXAsBwRBRG77faT OEXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WgEp1E5C6Qu8djtqrwabIex9jJmfchIPo+nfg3wWEGI=; b=gbQqMFHT+vhQByfT+Q/+6OLxBgJspyevkwfK/P4iJg+ua8+Oy9dpE5KcuWbVFw51bd dpyD8bqXqFQgcVaQoiwNSH9DwlluIG4oNgf4zpwKOJEjltrmjHt3cjcrCVZvf/GI2zpx rxSM/PQ1lAi4ROszZBnOqYZHCXL2/rMP0dPc9Oz32fBpH6AG2wns3tqVpFAJWrf0jQYF xgbNoXtzYiyJA51UqMULrdkBxClGnKqf3nKbqleveuLrBw2fRvqnVGJ+6lksLfM1NYln m/u3uaJS11tONcJ8kkOin6cSDUmF+veTR9BOt7qJMoSletOnasZdskO8GDursUK11CPw CXhw== X-Gm-Message-State: AA+aEWYpD0/Cx1iLYwA1JrAddVpjZ3crdMj5sVav7mNnvZdk4KoFhVny uI1jeU+f6QWXvNx7+OeWcPsPWMRXlJteMxw+u+Hh9Q== X-Received: by 2002:a0c:8665:: with SMTP id p92mr16732660qva.182.1544582821451; Tue, 11 Dec 2018 18:47:01 -0800 (PST) MIME-Version: 1.0 References: <20181206030227.9507-1-kyletso@google.com> In-Reply-To: From: Kyle Tso Date: Wed, 12 Dec 2018 10:46:49 +0800 Message-ID: Subject: Re: [PATCH] usb: typec: tcpm: Extend the matching rules on PPS APDO selection To: Adam.Thomson.Opensource@diasemi.com Cc: linux@roeck-us.net, heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org, Badhri Jagan Sridharan , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 10, 2018 at 7:36 PM Adam Thomson wrote: > > On 10 December 2018 09:01, Adam Thomson wrote: > > > On 06 December 2018 03:02, Kyle Tso wrote: > > > > > Current matching rules ensure that the voltage range of selected > > > Source Capability is entirely within the range defined in one of the > > > Sink Capabilities. This is reasonable but not practical because Sink > > > may not support wide range of voltage when sinking power while Source > > > could advertise its capabilities in raletively wider range. For > > > example, a Source PDO advertising 3.3V-11V@3A (9V Prog of Fixed > > > Nominal Voltage) will not be selected if the Sink requires 5V- 12V@3A > > > PPS power. However, the Sink could work well if the requested voltage range in > > RDOs is 5V-11V@3A. > > > > Is there a real world example of a sink requiring the 5V - 12V range? In that > > scenario could we not add an additional sink capability which allows for this range > > to be supported, and the current implementation should work just fine? > > Ok, I maybe should have waited until after my morning coffee to respond. So > because the lower limit on the sink side, is higher than the advertised source's > PPS minimum voltage it never gets selected? Personally I'd prefer to keep the > upper limit checking as is as I think that's an additional safety benefit > helping to prevent over-voltage scenarios. I think if a PPS APDO can supply up > to 11V then the system should be capable of handling that voltage, otherwise > it shouldn't be considered at all. The Source provides limits checking as well > to make sure the Sink doesn't request a value above the maximum voltage limit > for that selected APDO. > If the over-voltage occurs, it means: 1. the adapter malfunctioned. or 2. the code on the Sink accidentally requests a voltage level which is over the limit of the Sink. For 1., it is difficult to predict the behaviors of a malfunctioned adapter. The over-voltage event may happen even if the Sink doesn't select the APDO from this broken adapter. For 2., it is difficult to predict the behaviors from the careless code as well. > For the lower limit I'm more inclined to agree with allowing a higher minimum > on the sink side as that's less of a safety/damage issue as I understand it. > FWIW, what is the real world scenario? What happens if voltage drops below 5V? > Some products (in Sink mode) have under-voltage protection (the lower bound might be around 3.8V - 4V before the calculation of IR-drop) that will cause the disconnection. thanks, Kyle