Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp882143pxb; Wed, 27 Oct 2021 14:24:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxPEvR+ZnCioNrDUzmquSiYX82KgnZek5bkcZ/8hkr3BsAPl+kbrjMSGe0L+pAJSZjlI9lU X-Received: by 2002:a17:907:868b:: with SMTP id qa11mr30648ejc.383.1635369842086; Wed, 27 Oct 2021 14:24:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635369842; cv=none; d=google.com; s=arc-20160816; b=F73q0CbJIqHGqPoQLpwz75Yt4Z+u+wkq5EBQIiao9Z6opRQD8etHjY303YMvhGpTr9 f4VtbN+iknlc047pT32xQtYmdQtdhdpwys2h63LEI8I39r9nOPmG8HdHNUWey9LWm+8i T5YDCDCgAuEyXGU8eTg63up8LCLhP0iIUFvCTJh6uzrpm+h4Saq7CzJuKGSrWV7Me+aU 3NDYs+92Itqz1lcefMEkMECXVjzSt8q7J3MFRLaQnfYZF1J2oYqhIBdoBIF8n+TbDFPJ 8AcmjXqidS82cSryE+3sQqVORce72vLQU73K7HDNLVeL/7OPK9fUwb1czl8ubaYWvSYe kuiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=JExWOCAi5urhJ6z4PBRVlL/VsU3Z1fBNBr2vSu2DdNY=; b=WAcFwzZQEgG0A8aw6O6uB6M6Koy+BwP/1nDacHzPHKRin7ZINTTgk+vx9LUAvVv0a1 RXYflQLtgjeJiEBtQzrYAEx+GoMspMBZ7nijauGXBrrdu9o6zGg6fXcV5UpXAWHQ7Hz6 oGChAnRxh4e9+8OtSDEb4LhWrMhkTXE7CrgqJrbGYDQWhf3m/5t++m9qqsik3DbavVaw 5+u6Ex2Bqs8k4UXsnSbaxDjd7HAIWl4bOjOxOR2v/JKKj/92j0/LzuUd/62MEcgPCXvP NerbIOjB7jZIKupsN0RJkHT9NEUczWdi5VPe3lRDdT8EIuEW70TQ3aY5PhtumEq5RW9x sevA== 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 m8si1409982edl.0.2021.10.27.14.23.38; Wed, 27 Oct 2021 14:24:02 -0700 (PDT) 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 S241570AbhJ0LFN (ORCPT + 97 others); Wed, 27 Oct 2021 07:05:13 -0400 Received: from mga17.intel.com ([192.55.52.151]:50613 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239782AbhJ0LFM (ORCPT ); Wed, 27 Oct 2021 07:05:12 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10149"; a="210914508" X-IronPort-AV: E=Sophos;i="5.87,186,1631602800"; d="scan'208";a="210914508" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2021 04:02:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,186,1631602800"; d="scan'208";a="635681271" Received: from kuha.fi.intel.com ([10.237.72.166]) by fmsmga001.fm.intel.com with SMTP; 27 Oct 2021 04:02:43 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Wed, 27 Oct 2021 14:02:42 +0300 Date: Wed, 27 Oct 2021 14:02:42 +0300 From: Heikki Krogerus To: Greg KH Cc: Prashant Malani , Benson Leung , Adam Thomson , Guenter Roeck , Badhri Jagan Sridharan , Jack Pham , "Gopal, Saranya" , "Regupathy, Rajaram" , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/4] USB Power Delivery character device interface Message-ID: References: <20211026143352.78387-1-heikki.krogerus@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, On Tue, Oct 26, 2021 at 05:06:28PM +0200, Greg KH wrote: > So, why not sysfs? :) This is about allowing the user space to take over the USB Power Delivery communication and policy decisions in some cases. The user space needs to be able to send and receive raw USB Power Delivery messages one way or the other. I don't care about what's the interface that we use. Here we are talking about the PDOs, so basically the power contract. Even if we figured out a way how to expose all the information from the Capability, Status, Alert and what ever messages you need to the user space via sysfs, and then allow the user to separately send the Request Message, we would have only covered the power contract. That does not cover everything, but it would also be unnecessarily complicated to handle with separate sysfs files IMO. Even with the power contract it would make more sense to me to just allow the user space to simply read and write the raw messages, but when we go the other things like Vendor Specific Messages, I don't think there is any other way. So we really do need to be able to tap into the USB Power Delivery protocol layer directly from user space. I don't care about how we do that - character device is just a suggestion, although, it does still feel correct to me. Is there some other way we could do this? thanks, -- heikki