Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1293474pxb; Thu, 28 Oct 2021 00:38:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzjColROHNHwjDTEz0SAVY9NFy3KLol6rHcepX3tb1QY/6RkxkXSSkgmyytRQKVzukOd4ve X-Received: by 2002:a17:906:258d:: with SMTP id m13mr3512503ejb.208.1635406711741; Thu, 28 Oct 2021 00:38:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635406711; cv=none; d=google.com; s=arc-20160816; b=wtGOP+DQKZzNLiUs9ZAGhXhcM5brOJE/23qs/yKzscYcTxqDNFbCkDN6LbAYm5yOff MQtgZ6j8PcUPahUyYYD67iw8CqVFlXjnrHr3b0x4LQ05ufxuZ1tc21sIdQakuAJGNvPv DAGrqQX7+PgBWe4LT4sndc4fw/eOjka5GDFXzttedQZEN1TF47F8MeA4srd8NSP5Aygs X1Ze1eDOAc7wwUWaWa7JUIvMvUIJ9e/o5WkChlMBnsoXP40tQNgCfpOZwBi2u4fhnGLB Z+Mu8+WdNNnYaIL7pHeF9+LCrXjd38Tj3Zb+9W7qk3S5JEbX4/J7GEpWkmRWdH5ww194 fc1A== 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=XFBKIeMHyFQwyqYttp1t8L6Eq12wVpyZklkzCgqbli4=; b=KtYHUo6ao+5boh4cxU56lzU9v+0wdzaBHFwfN9UKJ4LpQ/IWRsdDC84OlFWaNyyb5y y9FfLLimH4SvUk/EnXxn1NABYFLzAp9qQWRULcWevHGjQY2q6nZSZDGd/ERSXUEWfCBz MbYLiDRzglQxXZVfmqboDetf+9lFaKSj7YL0R0NgkTLffSSzPjnTzWfv2vkrMS77UKE9 IP4LEFsY1XcZtz/atN1ihXX6xi0uhEP4WHZGAICGa/f+BIr9edPZQ3V5HsT9yz0vxjnv ZzyHrC/MSZAWYZRgjjHqSgiOPNQ24UB8o1qwNHWFyLoq+W5lShAeUOlmWCVa5gGRs2Xc Q2DA== 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 m14si3118539edb.327.2021.10.28.00.38.08; Thu, 28 Oct 2021 00:38:31 -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 S229887AbhJ1Hil (ORCPT + 99 others); Thu, 28 Oct 2021 03:38:41 -0400 Received: from mga11.intel.com ([192.55.52.93]:30868 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229771AbhJ1Hik (ORCPT ); Thu, 28 Oct 2021 03:38:40 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10150"; a="227799890" X-IronPort-AV: E=Sophos;i="5.87,189,1631602800"; d="scan'208";a="227799890" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2021 00:36:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,189,1631602800"; d="scan'208";a="636115701" Received: from kuha.fi.intel.com ([10.237.72.166]) by fmsmga001.fm.intel.com with SMTP; 28 Oct 2021 00:36:08 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Thu, 28 Oct 2021 10:36:07 +0300 Date: Thu, 28 Oct 2021 10:36:07 +0300 From: Heikki Krogerus To: Prashant Malani Cc: 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 2/4] usb: typec: Character device for USB Power Delivery devices Message-ID: References: <20211026143352.78387-1-heikki.krogerus@linux.intel.com> <20211026143352.78387-3-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, On Wed, Oct 27, 2021 at 06:03:08PM -0700, Prashant Malani wrote: > Why is USBPDDEV_SUBMIT_MESSAGE different from USBPDDEV_SET_MESSAGE? > Shouldn't "setting" a PDO or property automatically "submit" it (using TCPM > or whatever interface is actually performing the PD messaging) if > appropriate (e.g Source Caps?). Is there a situation where one would > want to "set" a property but not "send" it? > > It seems to me that the two can be combined into 1 rather than having > a separate command just for ports. USBPDDEV_SUBMIT_MESSAGE you use to send message directly to the partner. USBPDDEV_SET_MESSAGE is meant to be used to store the values to a cached message that the port manager should use next time there is communication, but it does not send the message to the partner. So you can use it even when there is no connection with a port, for example, to store the values like the initial USB mode that should be used by setting the EUDO message. Maybe the ioctl should be named USBPDDEV_STORE_MESSAGE... I used "set" because it is sort of a counterpart to USBPDDEV_GET_MESSAGE. There is an explanation in include/uapi/linux/usb/pd_dev.h, please check it. I'm curious also what you think about the idea with USBPDDEV_CONFIGURE. thanks, -- heikki