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 1/7] usb: typec: Copy everything from struct typec_capability during registration
Date: Wed, 2 Oct 2019 21:29:33 +0300	[thread overview]
Message-ID: <20191002182933.GA19870@kuha.fi.intel.com> (raw)
In-Reply-To: <20191002163639.GA30400@roeck-us.net>

On Wed, Oct 02, 2019 at 09:36:39AM -0700, Guenter Roeck wrote:
> port->cap->type used to be the role provided by the low level driver.
> That was static, and it was not possible to override it. It did not
> resemble the current port type, or a configured port type, it resembled
> port capabilities.
> 
> Your code changes that, meaning even if the low level driver (effectively
> the hardware) states that it can not support DRP, it is now configurable
> anyway. That seems to me like a substantial change to the original meaning
> of this attribute.
> 
> Effectiv ely there are now three values,
> - port->port_type	the current port tyle
> - port->fixed_type	the type selected by the user
> - port->cap->type	the type provided by low level code,
> 			now no longer available / used
> 
> Even if the low level driver (hardware) says that it can not support
> TYPEC_PORT_DRP, that can be overwritten by the user. Maybe there is a
> good reason for that, but I don't see it, sorry.

No, that was not my intention. Clearly there is a bug in my code.

> Maybe it would make sense to introduce port->fixed_type in a separate patch.
> As part of that patch you could explain why port->cap->type, ie a reflection
> of the port capabilities, is no longer needed.

Or, I could make this really simple. I could just copy the content of
the cap as is to another struct typec_capability during port
registration. My goal is really just remove the need for the device
drivers keep the struct typec_capability instance if they don't need
it, and I don't need to remove the cap member to achieve that.

Nevertheless, IMO this attribute file really needs to be deprecated.
On top of making things unnecessarily complicated for the userspace,
it's making it difficult to make changes to the rest of the class
code. We may not be able to get rid of the file, but there is nothing
preventing us from supplying a better solution as an option.

thanks,

-- 
heikki

  reply	other threads:[~2019-10-02 18:29 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 [this message]
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
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=20191002182933.GA19870@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.