All of lore.kernel.org
 help / color / mirror / Atom feed
From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
To: Brian Norris <briannorris@chromium.org>,
	Guenter Roeck <groeck@google.com>
Cc: Benson Leung <bleung@chromium.org>,
	Guenter Roeck <groeck@chromium.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK
Date: Thu, 23 Jul 2020 10:08:22 +0200	[thread overview]
Message-ID: <c03a678c-e288-c541-0fee-59b3585f2b43@collabora.com> (raw)
In-Reply-To: <CA+ASDXNeTp0z7M6rR62rJEa3tF52BYjXdodFTQvuR4b43o0e-Q@mail.gmail.com>

Hi Brian,

On 23/7/20 2:43, Brian Norris wrote:
> On Wed, Jul 22, 2020 at 2:13 PM Guenter Roeck <groeck@google.com> wrote:
>> On Wed, Jul 22, 2020 at 1:50 PM Brian Norris <briannorris@chromium.org> wrote:
>>> Other than perhaps taking a lesson not to propagate -ENOTSUPP, I don't
>>> think this series should block on that, as this is a bugfix IMO.
>>
>> My patch will return -EOPNOTSUPP for EC_RES_INVALID_COMMAND, so maybe
>> you could do the same. In my latest version (not yet submitted) I
>> extracted the conversion into a separate function, so if your patch is
>> accepted now I can just add another patch on top of it to start using
>> that function.
> 
> Sure, I can use EOPNOTSUPP in v2.
> 

Yes, please, can you send a v2 using EOPNOTSUPP

> BTW, the error code is completely internal to cros_ec_proto.c in my
> patch, so it seems even less-related to your series, unless I got
> refactor cros_ec_get_host_event_wake_mask() to use
> cros_ec_cmd_xfer_status() instead of send_command(). I'm actually not
> sure why we don't do that, now that I think about it...
> 
> So WDYT? Should I rebase on your eventual v3 and refactor to
> cros_ec_cmd_xfer_status()? Or (re)submit this first, and add one more
> cros_ec_cmd_xfer_status() usage for you to tweak in your series?
> 

No need to rebase on top of Guenter patches, as I plan to pick your patches first.

Regards,
Enric

> I don't mind a lot either way, except that I would like to port this
> to older kernels soon.
> 
> Brian
> 

  parent reply	other threads:[~2020-07-23  8:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22  1:57 [PATCH 1/2] platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs Brian Norris
2020-07-22  1:57 ` [PATCH 2/2] platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK Brian Norris
2020-07-22 10:19   ` Enric Balletbo i Serra
2020-07-22 20:50     ` Brian Norris
2020-07-22 21:13       ` Guenter Roeck
2020-07-23  0:43         ` Brian Norris
2020-07-23  0:50           ` Brian Norris
2020-07-23  0:54             ` Guenter Roeck
2020-07-23  8:08           ` Enric Balletbo i Serra [this message]
2020-07-23  8:04       ` Enric Balletbo i Serra
2020-07-24 19:39         ` Brian Norris

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=c03a678c-e288-c541-0fee-59b3585f2b43@collabora.com \
    --to=enric.balletbo@collabora.com \
    --cc=bleung@chromium.org \
    --cc=briannorris@chromium.org \
    --cc=groeck@chromium.org \
    --cc=groeck@google.com \
    --cc=linux-kernel@vger.kernel.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.