All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zev Weiss <zweiss@equinix.com>
To: Andrew Jeffery <andrew@aj.id.au>
Cc: "Bills, Jason M" <jason.m.bills@linux.intel.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: [PATCH 1/2] pinctrl: aspeed: Enable pass-through on GPIOE1 and GPIOE3 free
Date: Wed, 2 Feb 2022 23:14:17 +0000	[thread overview]
Message-ID: <20220202231417.GM5754@packtop> (raw)
In-Reply-To: <70fda031-ea0a-4155-81d4-74f398134bf8@www.fastmail.com>

On Wed, Feb 02, 2022 at 02:49:13PM PST, Andrew Jeffery wrote:
>
>
>On Thu, 3 Feb 2022, at 06:29, Bills, Jason M wrote:
>> This change adds a gpio_disable_free() implementation that checks
>> if the GPIO being freed is GPIOE1 (33) or GPIOE3 (35) and will
>> re-enable the pass-through mux.
>
>Okay. So trying to pull back from the implementation for a moment:
>
>Perhaps we can view pass-through as a property on a pair of GPIOs, rather than a mux state? I think it would be better if we could, for instance, annotate this in the devicetree?
>
>If we did that I don't think we're require this awkward and pin-specific implementation of the free callback for GPIOs.
>

Agreed, a way to specify this in DT would be nice -- e3c246d4i, for
example, also wants GPIO passthrough, but on GPIOD rather than GPIOE.
Hopefully whatever mechanism we arrive at for this could support either.

I don't have much expertise in the pinctrl subsystem to offer for code
review, but I'm happy to help with testing for this.


Zev

  reply	other threads:[~2022-02-02 23:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02 19:59 [PATCH 1/2] pinctrl: aspeed: Enable pass-through on GPIOE1 and GPIOE3 free Bills, Jason M
2022-02-02 22:49 ` Andrew Jeffery
2022-02-02 23:14   ` Zev Weiss [this message]
2022-02-07  6:45   ` Joel Stanley
2022-02-24 21:03     ` Bills, Jason M
2022-02-25  4:49       ` Joel Stanley
2022-02-25 15:22         ` Bills, Jason M
2022-02-28  0:04           ` Andrew Jeffery

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=20220202231417.GM5754@packtop \
    --to=zweiss@equinix.com \
    --cc=andrew@aj.id.au \
    --cc=jason.m.bills@linux.intel.com \
    --cc=openbmc@lists.ozlabs.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 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.