linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: "Limonciello, Mario" <mario.limonciello@amd.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>, linux-gpio@vger.kernel.org
Subject: Re: [bug report] pinctrl: amd: Use unicode for debugfs output
Date: Tue, 9 Aug 2022 09:30:23 +0800	[thread overview]
Message-ID: <YvG4r7AyRMNuEMp7@sol> (raw)
In-Reply-To: <234a1945-d09b-8d55-a6ae-fd5f7e05943a@amd.com>

On Mon, Aug 08, 2022 at 01:21:07PM -0500, Limonciello, Mario wrote:
> On 8/8/2022 11:06, Kent Gibson wrote:
> > On Mon, Aug 08, 2022 at 07:33:07AM -0500, Mario Limonciello wrote:
> > > On 8/8/22 05:28, Dan Carpenter wrote:
> > > > Hello Mario Limonciello,
> > > > 
> > > > The patch e8129a076a50: "pinctrl: amd: Use unicode for debugfs
> > > > output" from Jul 22, 2022, leads to the following Smatch static
> > > > checker warning:
> > > > 
> > > > drivers/pinctrl/pinctrl-amd.c:249 amd_gpio_dbg_show() warn: format string contains non-ascii character '\x8c'
> > > > drivers/pinctrl/pinctrl-amd.c:288 amd_gpio_dbg_show() warn: format string contains non-ascii character '\x8e'
> > > > drivers/pinctrl/pinctrl-amd.c:294 amd_gpio_dbg_show() warn: format string contains non-ascii character '\x85'
> > > > drivers/pinctrl/pinctrl-amd.c:300 amd_gpio_dbg_show() warn: format string contains non-ascii character '\x85'
> > > > drivers/pinctrl/pinctrl-amd.c:306 amd_gpio_dbg_show() warn: format string contains non-ascii character '\x85'
> > > > drivers/pinctrl/pinctrl-amd.c:320 amd_gpio_dbg_show() warn: format string contains non-ascii character '\x86'
> > > > drivers/pinctrl/pinctrl-amd.c:326 amd_gpio_dbg_show() warn: format string contains non-ascii character '\x86'
> > > > drivers/pinctrl/pinctrl-amd.c:326 amd_gpio_dbg_show() warn: format string contains non-ascii character '\xe2'
> > > > drivers/pinctrl/pinctrl-amd.c:370 amd_gpio_dbg_show() warn: format string contains non-ascii character '\xe2'
> > > > 
> > > > I didn't add this Smatch check and I don't know the rules for this so
> > > > when someone adds something that basically looks sane, I don't report
> > > > it.
> > > > 
> > > 
> > > All of those are expected to me.  If there are rules against this type of
> > > change then we should (unfortunately) revert that patch and the follow on
> > > patch that fixed an unused variable.
> > > 
> > > > 
> > > > drivers/pinctrl/pinctrl-amd.c
> > > >       247                 seq_printf(s, "GPIO bank%d\n", bank);
> > > >       248                 for (; i < pin_num; i++) {
> > > >       249                         seq_printf(s, "📌%d\t", i);
> > > >                                                  ^
> > > > In Gnome this looks like a thumbtack.
> > > 
> > > Right, it's replacing "Pin".
> > 
> > Umm, #?
> 
> I guess if paired with a heading that is a great suggestion, thanks.
> 
> > 
> > > 
> > > > 
> > > > ...
> > > > 
> > > >       279
> > > >       280                         if (pin_reg & BIT(INTERRUPT_MASK_OFF))
> > > >       281                                 interrupt_mask = "-";
> > > >       282                         else
> > > >       283                                 interrupt_mask = "+";
> > > >       284                         seq_printf(s, "int %s (🎭 %s)| active-%s| %s-🔫| ",
> > > > 
> > > > Gnome emojis seem difficult to read.  Theatre masks and a water gun?
> > > 
> > > "Mask" and "Trigger"
> > > 
> > 
> > 🙈 and 💥?
> > 
> > If you would consider seperate symbols for masked and unmasked, rather
> > than appending "-" or "+", then 😷 and 😛.
> > 
> Oh duh.
> 
> Separate symbols makes perfect sense for mask/unmasked.
> I'm not sure that 💥 is any better than 🔫 though.
> 

I was looking for something more visually distinctive - it is hard to
tell what the pistol is.  I was also thinking "spark" so ⚡, but again
the collision symbol looked more distinctive to me.  YMMV.

You are after level triggered and edge triggered, right?
So "-💥" and "/💥"?

> > > > 
> > > >       285                                    interrupt_enable,
> > > >       286                                    interrupt_mask,
> > > >       287                                    active_level,
> > > > --> 288                                    level_trig);
> > > >       289
> > > >       290                         if (pin_reg & BIT(WAKE_CNTRL_OFF_S0I3))
> > > >       291                                 wake_cntrl0 = "+";
> > > >       292                         else
> > > >       293                                 wake_cntrl0 = "∅";
> > > >       294                         seq_printf(s, "S0i3 🌅 %s| ", wake_cntrl0);
> > > > 
> > > > 
> > > > Sunrise emoji?
> > > 
> > > "S0i3 Wakeup"
> > > 
> > 
> > Somehow ⏰ makes more sense here to me.
> 
> In this context it feels like a timer though, not sure on this one.
> 

Well it is an alarm, which is why it is inappropriate for the debounce,
as that is more of a filter.

With an alarm clock you will wake, else you will continue to sleep.

> > And if you were to use separate symbols then 😴 for wake disabled?
> > 
> > > > 
> > > > ...
> > > > 
> > > >       369                         snprintf(debounce_value, sizeof(debounce_value), "%u", time * unit);
> > > >       370                         seq_printf(s, "debounce %s (⏰ %sus)| ", debounce_enable, debounce_value);
> > > > 
> > > > Alarm clock.
> > > 
> > > "Debounce time"
> > > 
> > 
> > 🕑 or ⏲ or nothing?
> > 
> > Sorry - couldn't resist chipping in - poor old dan.
> > 
> > Cheers,
> > Kent.
> > 
> 
> Thanks for your suggestions.  I'll work out something later this week to
> change to some of them and leave you a Suggested-by tag in the commit.
> 

No problem - just my 2¢, plus it was the highlight of the day 😂.

Cheers,
Kent.

> > 
> > > > 
> > > >       371                         seq_printf(s, " 0x%x\n", pin_reg);
> > > >       372                 }
> > > >       373         }
> > > >       374 }
> > > > 
> > > > regards,
> > > > dan carpenter
> > > 
> > > Yeah all of those emoji are the ones I intended.  Details above.  The point
> > > of this patch was to shrink the length of the line in debugfs output into
> > > something more manageable that it didn't need to be imported into a CSV
> > > processor to look at the data.  It can be used with something like "less"
> > > now.
> > > 
> > > If you (or anyone else) has a better proposal for any of those symbols I'm
> > > happy to make a change.  My goal remains to keep the lines ultra short
> > > though.
> 

      reply	other threads:[~2022-08-09  1:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-08 10:28 [bug report] pinctrl: amd: Use unicode for debugfs output Dan Carpenter
2022-08-08 12:33 ` Mario Limonciello
2022-08-08 12:47   ` Dan Carpenter
2022-08-08 16:06   ` Kent Gibson
2022-08-08 18:21     ` Limonciello, Mario
2022-08-09  1:30       ` Kent Gibson [this message]

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=YvG4r7AyRMNuEMp7@sol \
    --to=warthog618@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mario.limonciello@amd.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;
as well as URLs for NNTP newsgroup(s).