mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jun Li <jun.li@nxp.com>, Mats Karrman <mats.dev.list@gmail.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v3 0/5] usb: typec: Support for Alternate Modes
Date: Sat, 12 May 2018 14:42:47 -0700	[thread overview]
Message-ID: <f82856a4-5841-0656-e9a5-68b035ca91df@roeck-us.net> (raw)
In-Reply-To: <20180511131838.62064-1-heikki.krogerus@linux.intel.com>

On 05/11/2018 06:18 AM, Heikki Krogerus wrote:
> Hi,
> 
> This is the third version of my proposal for more complete alternate
> mode support. In this version I'm including a proposal for the mux
> handling. Basically, I'm proposing that every supported alternate will
> have its own mux handle. That should allow us to support multiple
> alternate modes at the same time. There is also a small change to how
> I handled enter/exit mode commands. Now the alternate mode drivers
> will need to check if Enter Mode command ACK/NAK. The ->enter callback
> is not called in those cases separately. The typec_altmode_enter/exit
> functions are used only when the command is initiated. Other than
> that, only minor tuning.
> 

I like the both the idea and the approach. I browsed through the code,
but I don't see anything obviously wrong with it. Too bad I wont have
the time for an actual alternate mode implementation. Are you working
on one, by any chance ? I would like to see this move forward, and an
actual implementation would help to get there.

Thanks,
Guenter

> 
> v2 commit message:
> 
> This is second version of my proposal for more complete USB Type-C
> Alternate Mode support. The original proposal can be read from here:
> https://www.spinics.net/lists/linux-usb/msg161098.html
> 
> These patches now depend on series from Hans where he is introducing
> mux handling support for USB Type-C and USB in general:
> https://lkml.org/lkml/2018/3/2/340
> 
> The major difference compared to v1 is that I'm proposing change to
> the sysfs ABI we have for the alternate mode devices. The files are
> not changed, but they are moved to the parent directory from the
> mode<index> folder. Since the alternate mode devices are not yet used
> and in practice not supported in mainline, I felt brave enough to
> propose that.
> 
> The reason for removing the mode<index> folder is because as in patch
> 1/3 I now create a device for every mode of every SVID, there will
> never be more then one mode folder. I.e. the folder serves no purpose.
> The mode<index> is still kept for now, but it's just deprecated.
> 
> There are no alternate mode drivers included yet in this version.
> 
> 
> Original commit message (subject was "usb: typec: alternate mode
> bus"):
> 
> The bus allows SVID specific communication with the partners to be
> handled in separate drivers for each alternate mode.
> 
> Alternate mode handling happens with two separate logical devices:
> 1. Partner alternate mode devices which represent the alternate modes
>     on the partner. The driver for them will handle the alternate mode
>     specific communication with the partner using VDMs.
> 2. Port alternate mode devices which represent connections from the
>     USB Type-C port to devices on the platform.
> 
> The drivers will be bind to the partner alternate modes. The alternate
> mode drivers will need to deliver the result of the negotiated pin
> configurations to the rest of the platform (towards the port alternate
> mode devices). This series includes API for that, however, not the
> final implementation yet.
> 
> The connections to the other devices on the platform the ports have
> can be described by using the remote endpoint concept [1][2] on ACPI
> and DT platforms, but I have no solution for the "platform data" case
> where we have neither DT nor ACPI to describe the connections for us.
> 
> [1] Documentation/devicetree/bindings/graph.txt
> [2] Documentation/acpi/dsd/graph.txt
> 
> 
> Heikki Krogerus (5):
>    usb: typec: mux: Get the mux identifier from function parameter
>    usb: typec: Register a device for every mode
>    usb: typec: Bus type for alternate modes
>    usb: typec: pi3usb30532: Start using generic state values
>    usb: typec: tcpm: Support for Alternate Modes
> 
>   Documentation/ABI/obsolete/sysfs-class-typec |  48 ++
>   Documentation/ABI/testing/sysfs-bus-typec    |  51 ++
>   Documentation/ABI/testing/sysfs-class-typec  |  62 +--
>   Documentation/driver-api/usb/typec_bus.rst   | 136 ++++++
>   drivers/usb/typec/Makefile                   |   2 +-
>   drivers/usb/typec/bus.c                      | 423 +++++++++++++++++
>   drivers/usb/typec/bus.h                      |  38 ++
>   drivers/usb/typec/class.c                    | 472 ++++++++++++-------
>   drivers/usb/typec/mux.c                      |   6 +-
>   drivers/usb/typec/mux/pi3usb30532.c          |  11 +-
>   drivers/usb/typec/tcpm.c                     | 179 +++++--
>   include/linux/mod_devicetable.h              |  15 +
>   include/linux/usb/tcpm.h                     |   9 -
>   include/linux/usb/typec.h                    |  51 +-
>   include/linux/usb/typec_altmode.h            | 142 ++++++
>   include/linux/usb/typec_mux.h                |   2 +-
>   scripts/mod/devicetable-offsets.c            |   4 +
>   scripts/mod/file2alias.c                     |  13 +
>   18 files changed, 1347 insertions(+), 317 deletions(-)
>   create mode 100644 Documentation/ABI/obsolete/sysfs-class-typec
>   create mode 100644 Documentation/ABI/testing/sysfs-bus-typec
>   create mode 100644 Documentation/driver-api/usb/typec_bus.rst
>   create mode 100644 drivers/usb/typec/bus.c
>   create mode 100644 drivers/usb/typec/bus.h
>   create mode 100644 include/linux/usb/typec_altmode.h
> 


  parent reply	other threads:[~2018-05-12 21:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 13:18 Heikki Krogerus
2018-05-11 13:18 ` [RFC PATCH v3 1/5] usb: typec: mux: Get the mux identifier from function parameter Heikki Krogerus
2018-05-11 13:18 ` [RFC PATCH v3 2/5] usb: typec: Register a device for every mode Heikki Krogerus
2018-05-11 13:18 ` [RFC PATCH v3 3/5] usb: typec: Bus type for alternate modes Heikki Krogerus
2018-05-13  1:25   ` Randy Dunlap
2018-05-14 10:42     ` Heikki Krogerus
2018-05-11 13:18 ` [RFC PATCH v3 4/5] usb: typec: pi3usb30532: Start using generic state values Heikki Krogerus
2018-05-11 13:18 ` [RFC PATCH v3 5/5] usb: typec: tcpm: Support for Alternate Modes Heikki Krogerus
2018-05-12 21:30   ` Andy Shevchenko
2018-05-14 10:40     ` Heikki Krogerus
2018-05-12 21:42 ` Guenter Roeck [this message]
2018-05-14 10:56   ` [RFC PATCH v3 0/5] usb: typec: " Heikki Krogerus

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=f82856a4-5841-0656-e9a5-68b035ca91df@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=jun.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mats.dev.list@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®