mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
To: Prashant Malani <pmalani@chromium.org>
Cc: Stephen Boyd <swboyd@chromium.org>,
	Benson Leung <bleung@chromium.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Gwendal Grignou <gwendal@chromium.org>,
	Guenter Roeck <groeck@chromium.org>
Subject: Re: [PATCH] platform/chrome: cros_ec_debugfs: Support pd_info v2 format
Date: Wed, 16 Sep 2020 11:38:56 +0200	[thread overview]
Message-ID: <7b391f5e-8200-ddc5-eb56-164c6006a134@collabora.com> (raw)
In-Reply-To: <CACeCKacudCkMoT40UJaf8PKUQu9G0csBmhih8cBO2Y3TAhV-0Q@mail.gmail.com>

Hi Prashant,

On 15/9/20 17:34, Prashant Malani wrote:
> HI Enric,
> 
> On Tue, Sep 15, 2020 at 5:48 AM Enric Balletbo i Serra
> <enric.balletbo@collabora.com> wrote:
>>
>> Hi Stephen, Prashant,
>>
>> On 9/9/20 6:04, Stephen Boyd wrote:
>>> Let's try to read more information out of more modern cros_ec devices by
>>> using the v2 format first and then fall back to the v1 format. This
>>> gives us more information about things such as DP mode of the typec pins
>>> and the CC state, along with some more things.
>>>
>>> Cc: Gwendal Grignou <gwendal@chromium.org>
>>> Cc: Prashant Malani <pmalani@chromium.org>
>>> Cc: Guenter Roeck <groeck@chromium.org>
>>> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>>> ---
>>>
>>
>> I saw some discussion going on in gerrit (a pity the discussion didn't happen in
>> mainline) Did you end with a conclusion? Can I remove this patch from my backlog?
> 
> My apologies for not posting the comment here.
> To summarize: the userspace EC utility ectool [1] can offer the
> equivalent output, but with better formatting. So I believe the
> decision is to use that instead of this patch.
> I also posed a counter-question: can we remove this debugfs pdinfo
> file entirely, since we can pull this information using ectool?
> 

If I am not mistaken pdinfo is used by your userspace, so, assuming we don't
break (or we have a plan to not break) things I'm fine with it. In general,
delegating things to userspace and get rid of kernel code is good for everyone.

Thanks,
 Enric

> [1]: https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/util/ectool.c
> 
> Best regards,
> 

  reply	other threads:[~2020-09-16  9:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09  4:04 Stephen Boyd
2020-09-15 12:48 ` Enric Balletbo i Serra
2020-09-15 15:34   ` Prashant Malani
2020-09-16  9:38     ` Enric Balletbo i Serra [this message]
2020-09-16 15:11       ` Prashant Malani

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=7b391f5e-8200-ddc5-eb56-164c6006a134@collabora.com \
    --to=enric.balletbo@collabora.com \
    --cc=bleung@chromium.org \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmalani@chromium.org \
    --cc=swboyd@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

all inboxes | Powered by JetHome®