Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3108642pxb; Fri, 4 Feb 2022 01:14:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJyrvJfel/+CDqjoa+H+LshB/y7IPrMHbekvW9s8VcOruLso9tP8nko1vTJzJzYH+qaA80GR X-Received: by 2002:a17:90b:4c8d:: with SMTP id my13mr2111475pjb.6.1643966060303; Fri, 04 Feb 2022 01:14:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643966060; cv=none; d=google.com; s=arc-20160816; b=ACFr5aMEpp+4anTVYK1dQaNsHG7lLotbg4m+jfkXLFtp+3zJLD2nlxpj1SqTsEimlJ y9R4bvk+URvr1B7czxniPFwISdEWv/49EAjtXscNazJF8RBDiEhCJov3+rLpXWb9CoaN 0Xu0BWHKx72R5JAUkg+VHl2x2DeJFfeg/0kgDlhjN+55V7OaqN6/2YDlg4kijqahmYYP eyxt5cFZUycMoN9LhHwp4xEu8r72DeVVuErpV+SvcBbiOFDKjxEvOdV1YjM54c9fAoPm CVKn/1Vw2kc4FXfzWSy9l9Gxb+YyaHlaUT62DckI7V52bIFzdPY+pAWo4aiFlqpUmpYn JnjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=DDn0OEYaJh2cBPEWFWDF8JPSQKdPvz0LCZ7ZGvA6bSg=; b=nzkRpjDzHwmOg+nfaA2mRQKW4KrPoFXrhptQcBCsBW6hoNJ8hDOnz7hG559YZm6hlo hVsK5CQrkyGIA6lIbJKDZJoHZMEe37xjRl5nL6/dpxgtxroKMbB9R/pjsU5aKyvESJ4k FrXd5eSyZTNjSiVhPi3i3v5nvHi+7OaXBq7Ze7UG/sadhSTWS0zZHtuP/T8/8fEVE9TA dag9vIvmS1RW62YglRQ4tgYobIYKxraMmlgEfk+2OJIjJ4TwQacF+ckOwB8vCosbMxFT 1DGkNGuZ0UUQ6iKLA/9KXPDFuxUaYVt0fQte2VUa5sLRZYmz9tbpyxKtUNZv4Mye3pbg Mekw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kuMXRLy4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 71si1275583pgb.830.2022.02.04.01.14.06; Fri, 04 Feb 2022 01:14:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kuMXRLy4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351330AbiBCOqs (ORCPT + 99 others); Thu, 3 Feb 2022 09:46:48 -0500 Received: from mga06.intel.com ([134.134.136.31]:37909 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351282AbiBCOqq (ORCPT ); Thu, 3 Feb 2022 09:46:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643899606; x=1675435606; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=G1NEaO4YfV+ndngmjLH9H1KfbSPd0dgTl8bo+81+nzU=; b=kuMXRLy42m+amXIIullowRFx9hzSQRmtexgGFvHp4/qqE3eC9kT+Ud18 c9Ixo3eh4RXw04dwznRQ1ben1p9/hfKy+Ta4rDuGVaYpeDhsqNWJGDXXT y7cWxUqILflAsM/fSC2iIyQF+7Lwfz5GC/Qfc29+5a2WmrJtNwgqoeXZ3 tyQyQIxX/YlsOwHsFxrnTudKvZ6PTm0dZYEdfhM+Ja4ToDpBgzNy9I9Fq 5rATs2TES7v043tbW6n2PKCs30KtMWtrZCEdOhAXTPaArwU7vRwQpUDSt GSkwhI2IrR+onens0BzxTLg5HoZwhntdQ/oPZ37WlPAVe9aeU5fUDTmfD w==; X-IronPort-AV: E=McAfee;i="6200,9189,10246"; a="308882989" X-IronPort-AV: E=Sophos;i="5.88,340,1635231600"; d="scan'208";a="308882989" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2022 06:46:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,340,1635231600"; d="scan'208";a="676788140" Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 03 Feb 2022 06:46:43 -0800 From: Heikki Krogerus To: Greg Kroah-Hartman Cc: Guenter Roeck , Benson Leung , Prashant Malani , Jameson Thies , "Regupathy, Rajaram" , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v1 0/3] usb: typec: Separate sysfs directory for all USB PD objects Date: Thu, 3 Feb 2022 17:46:54 +0300 Message-Id: <20220203144657.16527-1-heikki.krogerus@linux.intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Ideally after this there should be no need to add any new USB Power Delivery specific attribute files directly to the USB Type-C devices in sysfs. They now have their own directory. The idea of the series is that any device (so not just USB Type-C connectors and the partners attached to them) that supports USB Power Delivery can have this separate sub-directory "usb_power_delivery" in sysfs, and that sub-directory will have all the USB Power Delivery objects and all the other USB Power Delivery details. There are already ways that allow us to read the USB Power Delivery capabilities from potentially any USB PD capable USB device attached to the bus - one way is defined in the USB Type-C Bridge Specification. Initially the Capability Messages (i.e. PDOs) are exposed. This is an example (tree view) of the capabilities that the ports on a normal x86 system advertise to the partner. First you have the message directory (source_capabilities and sink_capabilities), and that will have a sub-directory for each PDO that capability message has. The PDO sub-directories are named by their type. The number in front of the name is the object position of the PDO: /sys/class/typec/port0/usb_power_delivery |-- revision |-- sink_capabilities/ | |-- 1:fixed_supply/ | | |-- dual_role_data | | |-- dual_role_power | | |-- fast_role_swap_current | | |-- operational_current | | |-- unchunked_extended_messages_supported | | |-- unconstrained_power | | |-- usb_communication_capable | | |-- usb_suspend_supported | | `-- voltage | |-- 2:variable_supply/ | | |-- maximum_voltage | | |-- minimum_voltage | | `-- operational_current | `-- 3:battery/ | |-- maximum_voltage | |-- minimum_voltage | `-- operational_power `-- source_capabilities/ `-- 1:fixed_supply/ |-- dual_role_data |-- dual_role_power |-- maximum_current |-- unchunked_extended_messages_supported |-- unconstrained_power |-- usb_communication_capable |-- usb_suspend_supported `-- voltage And these are the capabilities of my Thunderbolt3 dock: /sys/class/typec/port0-partner/usb_power_delivery |-- revision |-- sink_capabilities/ | `-- 1:fixed_supply/ | |-- dual_role_data | |-- dual_role_power | |-- fast_role_swap_current | |-- operational_current | |-- unchunked_extended_messages_supported | |-- unconstrained_power | |-- usb_communication_capable | |-- usb_suspend_supported | `-- voltage `-- source_capabilities/ |-- 1:fixed_supply/ | |-- dual_role_data | |-- dual_role_power | |-- maximum_current | |-- unchunked_extended_messages_supported | |-- unconstrained_power | |-- usb_communication_capable | |-- usb_suspend_supported | `-- voltage |-- 2:fixed_supply/ | |-- maximum_current | `-- voltage |-- 3:fixed_supply/ | |-- maximum_current | `-- voltage |-- 4:fixed_supply/ | |-- maximum_current | `-- voltage `-- 5:fixed_supply/ |-- maximum_current `-- voltage thanks, Heikki Krogerus (3): usb: typec: Separate USB Power Delivery from USB Type-C usb: typec: Functions for USB PD capabilities registration usb: typec: ucsi: Register USB Power Delivery Capabilities Documentation/ABI/testing/sysfs-class-typec | 22 + .../testing/sysfs-devices-usb_power_delivery | 273 ++++++++ drivers/usb/typec/Makefile | 2 +- drivers/usb/typec/class.c | 328 +++++++++ drivers/usb/typec/class.h | 8 + drivers/usb/typec/pd.c | 651 ++++++++++++++++++ drivers/usb/typec/pd.h | 39 ++ drivers/usb/typec/ucsi/ucsi.c | 128 +++- drivers/usb/typec/ucsi/ucsi.h | 8 + include/linux/usb/pd.h | 30 + include/linux/usb/typec.h | 25 + 11 files changed, 1502 insertions(+), 12 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-devices-usb_power_delivery create mode 100644 drivers/usb/typec/pd.c create mode 100644 drivers/usb/typec/pd.h -- 2.34.1