From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] GPIO: Extend the cmd_gpio API by gpio_{from, to}_string()
Date: Tue, 15 May 2012 07:53:10 +0200 [thread overview]
Message-ID: <201205150753.10461.marex@denx.de> (raw)
In-Reply-To: <201205150111.58898.vapier@gentoo.org>
Dear Mike Frysinger,
> On Monday 14 May 2012 14:25:14 Marek Vasut wrote:
> > Dear Mike Frysinger,
> >
> > > On Monday 14 May 2012 07:31:35 Marek Vasut wrote:
> > > > Dear Mike Frysinger,
> > > >
> > > > > On Tuesday 01 May 2012 16:50:14 Marek Vasut wrote:
> > > > > > The gpio_from_string() call shall parse the incoming GPIO name
> > > > > > taken from the command line and return the GPIO number used
> > > > > > within U-Boot or return -1 on error.
> > > > >
> > > > > i.e. the already existing name_to_gpio() func
> > > >
> > > > You mean blackfin specific macro crap? Let's actually drop that and
> > > > switch over to this one. That was my intention from start.
> > >
> > > don't spout this crap. try reading the actual history on the lists for
> > > the background on the naming, and then try actually grepping the tree
> > > to see that multiple targets implement it.
> >
> > Can you point me to something? This is the result of git grep, so I odn't
> > see it used at all.
> >
> > arch/blackfin/include/asm/gpio.h:static inline int name_to_gpio(const
> > char *name)
> > arch/blackfin/include/asm/gpio.h:#define name_to_gpio(n) name_to_gpio(n)
> > common/cmd_gpio.c:#ifndef name_to_gpio
> > common/cmd_gpio.c:#define name_to_gpio(name) simple_strtoul(name, NULL,
> > 10) common/cmd_gpio.c: return name_to_gpio(name);
>
> seems like the patches posted and i've been through haven't been merged.
Well ... that sucks. So there was some improvement in that direction already?
Why werent those patches merged, can you repost?
> gpio_status() is the only one to gain wider support.
What gpio_status()?
> the naming style however has been discussed on list and wasn't pulled out
> of nowhere. it follows the Linux GPIO API conventions whereas your
> proposed naming does not.
Fine with me either way.
> > > > > > The gpio_to_string() on the other hand allows nicer reporting of
> > > > > > GPIO name in the output of cmd_gpio.
> > > > >
> > > > > i don't see the value in this. we already have the string name
> > > > > from the
> > > > >
> > > > > user, so all you've implemented is:
> > > > > gpio_to_string(gpio_from_string(argv[]))
> > > > >
> > > > > at which point, argv[] works fine.
> > > >
> > > > This allows for taking multiple different inputs, while reporting one
> > > > unified output.
> > >
> > > sounds like unnecessary bloat
> >
> > Now you're spouting crap, it makes sense to be able to report the name
> > consistently.
>
> except the output is for user's eyes only and doesn't make a lick of a
> difference to runtime behavior. either they know the GPIO # (because they
> looked it up), or they're using the friendly name (which came from a
> datasheet). in either case, things continue to work regardless of the
> input. the "value add" here doesn't justify the overhead imo.
Well how often do you use cmd_gpio in a timing-critical aplication?
> -mike
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-05-15 5:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-01 20:50 [U-Boot] [PATCH 1/2] GPIO: Extend the cmd_gpio API by gpio_{from, to}_string() Marek Vasut
2012-05-01 20:50 ` [U-Boot] [PATCH 2/2] GPIO: Implement gpio_{from, to}_string on M28EVK Marek Vasut
2012-05-09 18:29 ` [U-Boot] [PATCH 1/2] GPIO: Extend the cmd_gpio API by gpio_{from, to}_string() Marek Vasut
2012-05-14 5:51 ` Mike Frysinger
2012-05-14 11:31 ` Marek Vasut
2012-05-14 16:14 ` Mike Frysinger
2012-05-14 18:25 ` Marek Vasut
2012-05-15 5:11 ` Mike Frysinger
2012-05-15 5:53 ` Marek Vasut [this message]
2012-05-18 2:53 ` Mike Frysinger
2012-08-02 10:05 ` Marek Vasut
2012-08-02 17:50 ` Mike Frysinger
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=201205150753.10461.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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