Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp385271pxb; Wed, 18 Nov 2020 07:04:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJzzSynKZZ1MtrYsPXzaNFUa1Ut4rRukNtYV9DrsttqdZQc0sEOY7UE7k1yqUbmd1u6VZ0Wk X-Received: by 2002:a17:906:2857:: with SMTP id s23mr13940132ejc.218.1605711846203; Wed, 18 Nov 2020 07:04:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605711846; cv=none; d=google.com; s=arc-20160816; b=zHLWFCxlThfVYDknS5DXW+z8th7JMl9i163o6ORI3Ov+UlP17s2NThOVmceqVxRgWt mmhPvQcCrv7z7+jcFTRhb3Hwt5fweoIWNBJTSXlnJAtOfXPNryrtJgAiAzxLHqW8aaeX 5yfuhX9yfSglIokO0JdsQwZmfzKQ6LKuFhDs2MAixb/zp6J2tvZv54RrD6BHLYPpWoBC mnncXYY9d3nkgm7Yd8r9f+iXr1sVpqxHNW4m/MGI2DgX4H9Nr0gxU0EwwN8z3JMz+Jnk oO+C6ra4QF6yWy3S6n0XmAKDdsVMtEr+4XchXefwznH9MTGbPwGte6vrVYLkGI/59a7e tlOw== 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:ironport-sdr:ironport-sdr; bh=xLIsiwPYA/+qblZlyYJqbKqYFEJHq68GU5wec5iwY+s=; b=VGsR9qSfogsjpkyiJft6sJFGpvMyVLizcrd31z8WIjalN2DfcqonpaJseCD51qZkkz aLNE5vCeSuVUVt6kxQqK2odfvuj5YxL3P4LH9pp6obfdzy1vFjTN3PgM3iJa53A2CCDy +04q88yMb03ayvRrDeHhcjePv+issJm6TElQ0Smxoh65zHYwyanikOaySmXaA7NdkMlY tzgBi6cn1zxYVnKsVj1Ha4r7FG2oXf7FBSCX0l9owTwVOVIw4aKQnsJLK3A/qpwtbYZK nPRytn7VsblhNzph0C2maRzv3vIF8SR/fG1ef9b2aunL5cwD+ZpgTBerhilORXVR5yI9 TH+Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g19si764536ejz.473.2020.11.18.07.03.42; Wed, 18 Nov 2020 07:04:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727164AbgKRPBE (ORCPT + 99 others); Wed, 18 Nov 2020 10:01:04 -0500 Received: from mga03.intel.com ([134.134.136.65]:37906 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725446AbgKRPBE (ORCPT ); Wed, 18 Nov 2020 10:01:04 -0500 IronPort-SDR: tG4GU5Q94pVoV1ryrPGBK7rlkQXQ+Jy1hEpM2cF650RqSYfWnSWXrkujChr82Gom0ELxePmkRI sfW4aji5T4YA== X-IronPort-AV: E=McAfee;i="6000,8403,9808"; a="171224092" X-IronPort-AV: E=Sophos;i="5.77,486,1596524400"; d="scan'208";a="171224092" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2020 07:01:02 -0800 IronPort-SDR: rsCU8KYkOh3bKEQ93QeGTpCgE1yrihlALPUw1ZGHY5x+Q6FUbtyYDNzBROyXZ52PaYD+xVUbon XNrpE2mQkKLw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,486,1596524400"; d="scan'208";a="430881513" Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 18 Nov 2020 07:01:00 -0800 From: Heikki Krogerus To: Prashant Malani Cc: Benson Leung , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: [RFC PATCH 0/3] usb: typec: Product Type time Date: Wed, 18 Nov 2020 18:00:56 +0300 Message-Id: <20201118150059.3419-1-heikki.krogerus@linux.intel.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Prashant, The original discussion [1]. This proposal is in practice a compromise. I came to the conclusion that we probable should expose the product type separately after all. The reason for that is because we may in some cases actually know the product type even when we don't have access to the Discover Identity response. UCSI for example in practice gives us at least the cable product type even though it does not let us know the response to the Discover Identity command. So my proposal here is that we add an attribute for the product type itself, showing the product type as a string. Then we also add the attribute for the product type specific VDOs which we place under the identity directory more or less the way you originally proposed. Note. I have not tested these at all. [1] https://lore.kernel.org/linux-usb/20201023214328.1262883-2-pmalani@chromium.org/ Heikki Krogerus (2): usb: pd: DFP product types usb: typec: Add product_type sysfs attribute file for partners and cables Prashant Malani (1): usb: typec: Expose Product Type VDOs via sysfs Documentation/ABI/testing/sysfs-class-typec | 55 +++++++ drivers/usb/typec/class.c | 173 +++++++++++++++++++- include/linux/usb/pd_vdo.h | 16 +- 3 files changed, 234 insertions(+), 10 deletions(-) -- 2.29.2