[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YXpS58zozw93QXig@kuha.fi.intel.com>
Date: Thu, 28 Oct 2021 10:36:07 +0300
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: Prashant Malani <pmalani@...omium.org>
Cc: Benson Leung <bleung@...gle.com>,
Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
Guenter Roeck <linux@...ck-us.net>,
Badhri Jagan Sridharan <badhri@...gle.com>,
Jack Pham <jackp@...eaurora.org>,
"Gopal, Saranya" <saranya.gopal@...el.com>,
"Regupathy, Rajaram" <rajaram.regupathy@...el.com>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/4] usb: typec: Character device for USB Power
Delivery devices
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
Powered by blists - more mailing lists