linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Stephen Warren <swarren@wwwdotorg.org>,
	Laurent Meunier <laurent.meunier@st.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Stephen Warren <swarren@nvidia.com>,
	Anmar Oueja <anmar.oueja@linaro.org>
Subject: Re: [PATCH] pinctrl/pinconfig: add debug interface
Date: Fri, 15 Feb 2013 20:32:41 +0100	[thread overview]
Message-ID: <CACRpkdYhwbpvfeoSiL1pfhVC+3O+8yMnA-raGimr0RpZdffRHA@mail.gmail.com> (raw)
In-Reply-To: <511A7478.8040506@wwwdotorg.org>

On Tue, Feb 12, 2013 at 5:57 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 02/12/2013 05:54 AM, Linus Walleij wrote:

>> Of course, if this unsigned long is a pointer, this is just a
>> fantastic recipe for shooting oneself in the foot, but again
>> debugfs is just one big gun aimed at ones foot anyway, that's
>> the whole point of debugfs.
>
> But it'd be possible to handle this if the code to modify the map called
> into the individual pinctrl driver to convert the data the user wrote
> into the value to store in the map, just like it does for DT.
>
> Then, it'd work in all cases.

You are right, this is way more elegant. So Laurent, can you add
some optional function pointer to struct pinconf_ops to translate
the passed parameter, and if that function is not assigned we do
not open the debugfs interface for config at all. This will be
quite elegant.

Something like:

int (*pin_config_group_dbg_set) (struct pinctrl_dev *pctldev,
                                           const char *arg,
                                           unsigned long *config);

> Plus, it could convert e.g. "pull up" to 0x10001 rather than requiring
> the user to manually encode the 0x10001 themselves; much more useful.

You are right.

Reconfiguring muxes from debugfs will be different, I guess
that may be handled entirely by the core. But it's a separate thing.

Yours,
Linus Walleij

  reply	other threads:[~2013-02-15 19:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-10 20:11 [PATCH] pinctrl/pinconfig: add debug interface Linus Walleij
2013-02-11 20:53 ` Stephen Warren
2013-02-11 21:00   ` Tony Lindgren
2013-02-11 21:13     ` Stephen Warren
2013-02-11 21:21       ` Tony Lindgren
2013-02-11 21:23         ` Stephen Warren
2013-02-11 21:33           ` Tony Lindgren
2013-02-12 12:54   ` Linus Walleij
2013-02-12 15:32     ` Haojian Zhuang
2013-02-12 16:57     ` Stephen Warren
2013-02-15 19:32       ` Linus Walleij [this message]
2013-04-03 19:31 Linus Walleij

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=CACRpkdYhwbpvfeoSiL1pfhVC+3O+8yMnA-raGimr0RpZdffRHA@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=anmar.oueja@linaro.org \
    --cc=laurent.meunier@st.com \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.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).