All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Hans de Goede <hdegoede@redhat.com>, linux-usb@vger.kernel.org
Subject: Re: [PATCH 3/7] usb: typec: Separate the operations vector
Date: Fri, 4 Oct 2019 11:45:12 +0300	[thread overview]
Message-ID: <20191004084512.GF1048@kuha.fi.intel.com> (raw)
In-Reply-To: <6378359b-cf1b-eb8a-997d-8102ee6ee241@roeck-us.net>

On Tue, Oct 01, 2019 at 06:22:36AM -0700, Guenter Roeck wrote:
> On 10/1/19 2:48 AM, Heikki Krogerus wrote:
> > Introducing struct typec_operations which has the same
> > callbacks as struct typec_capability. The old callbacks are
> > kept for now, but after all users have been converted, they
> > will be removed.
> > 
> > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > ---
> >   drivers/usb/typec/class.c | 90 +++++++++++++++++++++++++--------------
> >   include/linux/usb/typec.h | 19 +++++++++
> >   2 files changed, 76 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> > index 9fab0be8f08c..542be63795db 100644
> > --- a/drivers/usb/typec/class.c
> > +++ b/drivers/usb/typec/class.c
> > @@ -59,6 +59,7 @@ struct typec_port {
> >   	struct typec_mux		*mux;
> >   	const struct typec_capability	*cap;
> > +	const struct typec_operations	*ops;
> >   };
> >   #define to_typec_port(_dev_) container_of(_dev_, struct typec_port, dev)
> > @@ -961,11 +962,6 @@ preferred_role_store(struct device *dev, struct device_attribute *attr,
> >   		return -EOPNOTSUPP;
> >   	}
> > -	if (!port->cap->try_role) {
> > -		dev_dbg(dev, "Setting preferred role not supported\n");
> > -		return -EOPNOTSUPP;
> > -	}
> > -
> >   	role = sysfs_match_string(typec_roles, buf);
> >   	if (role < 0) {
> >   		if (sysfs_streq(buf, "none"))
> > @@ -974,9 +970,18 @@ preferred_role_store(struct device *dev, struct device_attribute *attr,
> >   			return -EINVAL;
> >   	}
> > -	ret = port->cap->try_role(port->cap, role);
> > -	if (ret)
> > -		return ret;
> > +	if (port->ops && port->ops->try_role) {
> > +		ret = port->ops->try_role(port, role);
> > +		if (ret)
> > +			return ret;
> > +	} else if (port->cap && port->cap->try_role) {
> > +		ret = port->cap->try_role(port->cap, role);
> > +		if (ret)
> > +			return ret;
> > +	} else {
> > +		dev_dbg(dev, "Setting preferred role not supported\n");
> > +		return -EOPNOTSUPP;
> > +	}
> 
> This is a semantic change: Support is now checked _after_ the string is evaluated.
> I understand the reason, but it should be noted in the patch description
> (not sure if it is worth it, though - it seems to me it makes the code more
> difficult to read).
> 
> >   	port->prefer_role = role;
> >   	return size;
> > @@ -1005,11 +1010,6 @@ static ssize_t data_role_store(struct device *dev,
> >   	struct typec_port *port = to_typec_port(dev);
> >   	int ret;
> > -	if (!port->cap->dr_set) {
> > -		dev_dbg(dev, "data role swapping not supported\n");
> > -		return -EOPNOTSUPP;
> > -	}
> > -
> >   	ret = sysfs_match_string(typec_data_roles, buf);
> >   	if (ret < 0)
> >   		return ret;
> > @@ -1020,9 +1020,19 @@ static ssize_t data_role_store(struct device *dev,
> >   		goto unlock_and_ret;
> >   	}
> > -	ret = port->cap->dr_set(port->cap, ret);
> > -	if (ret)
> > +	if (port->ops && port->ops->dr_set) {
> > +		ret = port->ops->dr_set(port, ret);
> > +		if (ret)
> > +			goto unlock_and_ret;
> > +	} else if (port->cap && port->cap->dr_set) {
> > +		ret = port->cap->dr_set(port->cap, ret);
> > +		if (ret)
> > +			goto unlock_and_ret;
> > +	} else {
> > +		dev_dbg(dev, "data role swapping not supported\n");
> > +		ret = -EOPNOTSUPP;
> >   		goto unlock_and_ret;
> 
> This really makes me wonder if the semantic change makes sense. Support
> is now evaluated _after_ the lock has been obtained. That seems like a
> waste.

OK, I'll re-think this.

> > +	}
> >   	ret = size;
> >   unlock_and_ret:
> > @@ -1055,11 +1065,6 @@ static ssize_t power_role_store(struct device *dev,
> >   		return -EOPNOTSUPP;
> >   	}
> > -	if (!port->cap->pr_set) {
> > -		dev_dbg(dev, "power role swapping not supported\n");
> > -		return -EOPNOTSUPP;
> > -	}
> > -
> >   	if (port->pwr_opmode != TYPEC_PWR_MODE_PD) {
> >   		dev_dbg(dev, "partner unable to swap power role\n");
> >   		return -EIO;
> > @@ -1077,11 +1082,21 @@ static ssize_t power_role_store(struct device *dev,
> >   		goto unlock_and_ret;
> >   	}
> > -	ret = port->cap->pr_set(port->cap, ret);
> > -	if (ret)
> > +	if (port->ops && port->ops->pr_set) {
> > +		ret = port->ops->pr_set(port, ret);
> > +		if (ret)
> > +			goto unlock_and_ret;
> > +	} else if (port->cap && port->cap->pr_set) {
> > +		ret = port->cap->pr_set(port->cap, ret);
> > +		if (ret)
> > +			goto unlock_and_ret;
> > +	} else {
> > +		dev_dbg(dev, "power role swapping not supported\n");
> > +		ret = -EOPNOTSUPP;
> >   		goto unlock_and_ret;
> > -
> > +	}
> >   	ret = size;
> > +
> >   unlock_and_ret:
> >   	mutex_unlock(&port->port_type_lock);
> >   	return ret;
> > @@ -1108,7 +1123,8 @@ port_type_store(struct device *dev, struct device_attribute *attr,
> >   	int ret;
> >   	enum typec_port_type type;
> > -	if (!port->cap->port_type_set || port->fixed_role != TYPEC_PORT_DRP) {
> > +	if ((!port->ops || !port->ops->port_type_set) ||
> > +	    !port->cap->port_type_set || port->fixed_role != TYPEC_PORT_DRP) {
> 
> The above now requires _all_ callbacks to exist, both ops and cap based ones.
> Is that on purpose ? Maybe this should be as follows ?
> 
> 	if (((!port->ops || !port->ops->port_type_set) &&
> 	     !port->cap->port_type_set) || port->fixed_role != TYPEC_PORT_DRP) {
> 
> or a bit better to read
> 	if (port->fixed_role != TYPEC_PORT_DRP ||
> 	    ((!port->ops || !port->ops->port_type_set) && !port->cap->port_type_set))

OK.


thanks,

-- 
heikki

  reply	other threads:[~2019-10-04  8:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01  9:48 [PATCH 0/7] usb: typec: Small API improvement Heikki Krogerus
2019-10-01  9:48 ` [PATCH 1/7] usb: typec: Copy everything from struct typec_capability during registration Heikki Krogerus
2019-10-01 13:08   ` Guenter Roeck
2019-10-02 16:06     ` Heikki Krogerus
2019-10-02 16:36       ` Guenter Roeck
2019-10-02 18:29         ` Heikki Krogerus
2019-10-03  3:45           ` Guenter Roeck
2019-10-03  8:03             ` Heikki Krogerus
2019-10-02 19:16       ` Heikki Krogerus
2019-10-03  3:51         ` Guenter Roeck
2019-10-03 13:29           ` Heikki Krogerus
2019-10-01  9:48 ` [PATCH 2/7] usb: typec: Introduce typec_get_drvdata() Heikki Krogerus
2019-10-01  9:48 ` [PATCH 3/7] usb: typec: Separate the operations vector Heikki Krogerus
2019-10-01 13:22   ` Guenter Roeck
2019-10-04  8:45     ` Heikki Krogerus [this message]
2019-10-01  9:48 ` [PATCH 4/7] usb: typec: tcpm: Start using struct typec_operations Heikki Krogerus
2019-10-01 13:30   ` Guenter Roeck
2019-10-04  8:46     ` Heikki Krogerus
2019-10-01  9:48 ` [PATCH 5/7] usb: typec: tps6598x: " Heikki Krogerus
2019-10-01 13:34   ` Guenter Roeck
2019-10-01 13:35   ` Guenter Roeck
2019-10-04  8:49     ` Heikki Krogerus
2019-10-01  9:48 ` [PATCH 6/7] usb: typec: ucsi: " Heikki Krogerus
2019-10-01 13:35   ` Guenter Roeck
2019-10-01  9:48 ` [PATCH 7/7] usb: typec: Remove the callback members from struct typec_capability Heikki Krogerus
2019-10-01 13:37   ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191004084512.GF1048@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.