linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Prashant Malani <pmalani@chromium.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Benson Leung <bleung@chromium.org>,
	"open list:USB NETWORKING DRIVERS" <linux-usb@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org,
	Tim Wawrzynczak <twawrzynczak@chromium.org>
Subject: Re: [PATCH 2/4] usb: typec: mux: intel_pmc_mux: Support for static SBU/HSL orientation
Date: Fri, 15 May 2020 15:05:52 +0300	[thread overview]
Message-ID: <20200515120552.GC1511@kuha.fi.intel.com> (raw)
In-Reply-To: <CACeCKad4BebiBJS_wO=FdWVWypgOD822Dir7HeRBf0uXUuJusA@mail.gmail.com>

Hi Prashant,

> I just realized, the issue I initially pointed out would apply to the
> connect message too, i.e I'm not sure if "normal" orientation setting
> handles the case where port orientation is reversed correctly.
> Overall, I am not sure that re-using the typec_orientations[] string
> list is the best option for this use-case.
> we're looking for "normal" (i.e follows port->orientation) and "fixed"
> (i.e is always the same orientation, regardless of what
> port->orientation is), so it is perhaps better to just define a new
> array just for this driver.

Sorry, I got sidetracked with that Alternate-Direct Request stuff.
Let's start over..

The property itself is the indicator that the orientation is fixed for
those lines, not its value. If the property exists, we know the
orientation is fixed, and if it doesn't exist, we know we need to use
the cable plug orientation. So if we only want to use the property as
a flag, then it does not need to have any value at all. It would be a
boolean property.

But we would then always leave the ORI-HSL field with value 0 when the
orientation is fixed, and that would rule out the possibility of
supporting a platform where we have to use a fixed value of 1 there
(fixed-reversed). If we ever needed to support configuration like
that, then we would need to add a new property.

That scenario may not be relevant on this platform, and it may seem
like an unlikely, or even impossible case now, but experience (and the
north mux-agent documentation) tells me we should prepare also for
that. That is why I use the typec_orientation strings as the values
for these properties. Then the fixed-reversed orientation is also
covered with the same properties if we ever need to support it.

Maybe this code would be better, or more clear in the driver:

/*
 * Returns the value for the HSL-ORI field.
 */
static int hsl_orientation(struct pmc_usb_port *port)
{
        enum typec_orientation orientation;

        /*
         * Is the orientation fixed:
         *   Yes, use the fixed orientation.
         *   No, use cable plug orientation.
         */
        if (port->hsl_orientation)
                orientation = hsl_orientation;
        else
                orientation = port->orientation;

        switch (orientation) {
        case TYPEC_ORIENTATION_NORMAL:
                return 0;
        case TYPEC_ORIENTATION_REVERSE:
                return 1;
        }

        return -EINVAL;
}

thanks,

-- 
heikki

  reply	other threads:[~2020-05-15 12:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 15:08 [PATCH 0/4] usb: typec: Intel PMC driver changes Heikki Krogerus
2020-05-07 15:08 ` [PATCH 1/4] usb: typec: Add typec_find_orientation() Heikki Krogerus
2020-05-07 15:08 ` [PATCH 2/4] usb: typec: mux: intel_pmc_mux: Support for static SBU/HSL orientation Heikki Krogerus
2020-05-07 22:40   ` Prashant Malani
2020-05-08 11:18     ` Heikki Krogerus
2020-05-08 11:36       ` Prashant Malani
2020-05-11 13:32       ` Heikki Krogerus
2020-05-11 17:57         ` Prashant Malani
2020-05-12 14:22           ` Heikki Krogerus
2020-05-12 19:19             ` Prashant Malani
2020-05-14 20:51               ` Prashant Malani
2020-05-15 12:05                 ` Heikki Krogerus [this message]
2020-05-07 15:08 ` [PATCH 3/4] usb: typec: Add firmware documentation for the Intel PMC mux control Heikki Krogerus
2020-05-07 15:09 ` [PATCH 4/4] MAINTAINERS: Add entry for Intel PMC mux driver 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=20200515120552.GC1511@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=bleung@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pmalani@chromium.org \
    --cc=twawrzynczak@chromium.org \
    /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;
as well as URLs for NNTP newsgroup(s).