All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hridya Valsaraju <hridya@google.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Christian Brauner" <christian@brauner.io>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
	"Liam Mark" <lmark@codeaurora.org>,
	"Laura Abbott" <labbott@redhat.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"John Stultz" <john.stultz@linaro.org>,
	"Tejun Heo" <tj@kernel.org>, "Zefan Li" <lizefan.x@bytedance.com>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Dave Airlie" <airlied@redhat.com>,
	"Jason Ekstrand" <jason@jlekstrand.net>,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Li Li" <dualli@google.com>, "Marco Ballesio" <balejs@google.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Hang Lu" <hangl@codeaurora.org>,
	"Wedson Almeida Filho" <wedsonaf@google.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Chris Down" <chris@chrisdown.name>,
	"Vipin Sharma" <vipinsh@google.com>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Arnd Bergmann" <arnd@arndb.de>,
	dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org, cgroups@vger.kernel.org,
	Kenny.Ho@amd.com, daniels@collabora.com, kaleshsingh@google.com,
	tjmercier@google.com
Subject: Re: [RFC 4/6] dma-buf: Add DMA-BUF exporter op to charge a DMA-BUF to a cgroup.
Date: Tue, 18 Jan 2022 10:54:16 -0800	[thread overview]
Message-ID: <CA+wgaPMjCfjQS4LA8hmVwAaGfXZhoJvvTUnOGt3duOhFb3orTw@mail.gmail.com> (raw)
In-Reply-To: <f8c8b196-7d12-6242-97ac-38149f3a3ba3@amd.com>

On Sun, Jan 16, 2022 at 11:46 PM Christian König
<christian.koenig@amd.com> wrote:
>
> Am 15.01.22 um 02:06 schrieb Hridya Valsaraju:
> > The optional exporter op provides a way for processes to transfer
> > charge of a buffer to a different process. This is essential for the
> > cases where a central allocator process does allocations for various
> > subsystems, hands over the fd to the client who
> > requested the memory and drops all references to the allocated memory.
> >
> > Signed-off-by: Hridya Valsaraju <hridya@google.com>
> > ---
> >   include/linux/dma-buf.h | 18 ++++++++++++++++++
> >   1 file changed, 18 insertions(+)
> >
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index 7ab50076e7a6..d5e52f81cc6f 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -13,6 +13,7 @@
> >   #ifndef __DMA_BUF_H__
> >   #define __DMA_BUF_H__
> >
> > +#include <linux/cgroup_gpu.h>
> >   #include <linux/dma-buf-map.h>
> >   #include <linux/file.h>
> >   #include <linux/err.h>
> > @@ -285,6 +286,23 @@ struct dma_buf_ops {
> >
> >       int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> >       void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > +
> > +     /**
> > +      * @charge_to_cgroup:
> > +      *
> > +      * This is called by an exporter to charge a buffer to the specified
> > +      * cgroup.
>
> Well that sentence makes absolutely no sense at all.
>
> The dma_buf_ops are supposed to be called by the DMA-buf subsystem on
> behalves of the importer and never by the exporter itself.
>
> I hope that this is just a documentation mixup.

Thank you for taking a look Christian!

Yes, that was poor wording, sorry about that. It should instead say
that the op would be called by the process the buffer is currently
charged to in order to transfer the buffer's charge to a different
cgroup. This is helpful in the case where a process acts as an
allocator for multiple client processes and we would like the
allocated buffers to be charged to the clients who requested their
allocation(instead of the allocating process as is the default
behavior). In Android, the graphics allocator HAL process[1] does
most of the graphics allocations on behalf of various clients. After
allocation, the HAL process passes the fd to the client over binder
IPC and the binder driver invokes the charge_to_cgroup() DMA-BUF op to
uncharge the buffer from the HAL process and charge it to the client
process instead.

[1]: https://source.android.com/devices/graphics/arch-bq-gralloc

Regards,
Hridya


>
> Regards,
> Christian.
>
> >   The caller must hold a reference to @gpucg obtained via
> > +      * gpucg_get(). The DMA-BUF will be uncharged from the cgroup it is
> > +      * currently charged to before being charged to @gpucg. The caller must
> > +      * belong to the cgroup the buffer is currently charged to.
> > +      *
> > +      * This callback is optional.
> > +      *
> > +      * Returns:
> > +      *
> > +      * 0 on success or negative error code on failure.
> > +      */
> > +     int (*charge_to_cgroup)(struct dma_buf *dmabuf, struct gpucg *gpucg);
> >   };
> >
> >   /**
>

WARNING: multiple messages have this Message-ID (diff)
From: Hridya Valsaraju <hridya@google.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Zefan Li" <lizefan.x@bytedance.com>,
	linux-doc@vger.kernel.org, "David Airlie" <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
	kaleshsingh@google.com, "Joel Fernandes" <joel@joelfernandes.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Matthew Brost" <matthew.brost@intel.com>,
	Kenny.Ho@amd.com, "Daniel Borkmann" <daniel@iogearbox.net>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Martijn Coenen" <maco@android.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Wedson Almeida Filho" <wedsonaf@google.com>,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Dave Airlie" <airlied@redhat.com>,
	"Laura Abbott" <labbott@redhat.com>,
	"Marco Ballesio" <balejs@google.com>,
	"Jason Ekstrand" <jason@jlekstrand.net>,
	linux-media@vger.kernel.org, "Li Li" <dualli@google.com>,
	"Todd Kjos" <tkjos@android.com>, "Arnd Bergmann" <arnd@arndb.de>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Vipin Sharma" <vipinsh@google.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	cgroups@vger.kernel.org, "Suren Baghdasaryan" <surenb@google.com>,
	tjmercier@google.com, "Christian Brauner" <christian@brauner.io>,
	linaro-mm-sig@lists.linaro.org, "Hang Lu" <hangl@codeaurora.org>,
	daniels@collabora.com, "Chris Down" <chris@chrisdown.name>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	linux-kernel@vger.kernel.org, "Liam Mark" <lmark@codeaurora.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Tejun Heo" <tj@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [RFC 4/6] dma-buf: Add DMA-BUF exporter op to charge a DMA-BUF to a cgroup.
Date: Tue, 18 Jan 2022 10:54:16 -0800	[thread overview]
Message-ID: <CA+wgaPMjCfjQS4LA8hmVwAaGfXZhoJvvTUnOGt3duOhFb3orTw@mail.gmail.com> (raw)
In-Reply-To: <f8c8b196-7d12-6242-97ac-38149f3a3ba3@amd.com>

On Sun, Jan 16, 2022 at 11:46 PM Christian König
<christian.koenig@amd.com> wrote:
>
> Am 15.01.22 um 02:06 schrieb Hridya Valsaraju:
> > The optional exporter op provides a way for processes to transfer
> > charge of a buffer to a different process. This is essential for the
> > cases where a central allocator process does allocations for various
> > subsystems, hands over the fd to the client who
> > requested the memory and drops all references to the allocated memory.
> >
> > Signed-off-by: Hridya Valsaraju <hridya@google.com>
> > ---
> >   include/linux/dma-buf.h | 18 ++++++++++++++++++
> >   1 file changed, 18 insertions(+)
> >
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index 7ab50076e7a6..d5e52f81cc6f 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -13,6 +13,7 @@
> >   #ifndef __DMA_BUF_H__
> >   #define __DMA_BUF_H__
> >
> > +#include <linux/cgroup_gpu.h>
> >   #include <linux/dma-buf-map.h>
> >   #include <linux/file.h>
> >   #include <linux/err.h>
> > @@ -285,6 +286,23 @@ struct dma_buf_ops {
> >
> >       int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> >       void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > +
> > +     /**
> > +      * @charge_to_cgroup:
> > +      *
> > +      * This is called by an exporter to charge a buffer to the specified
> > +      * cgroup.
>
> Well that sentence makes absolutely no sense at all.
>
> The dma_buf_ops are supposed to be called by the DMA-buf subsystem on
> behalves of the importer and never by the exporter itself.
>
> I hope that this is just a documentation mixup.

Thank you for taking a look Christian!

Yes, that was poor wording, sorry about that. It should instead say
that the op would be called by the process the buffer is currently
charged to in order to transfer the buffer's charge to a different
cgroup. This is helpful in the case where a process acts as an
allocator for multiple client processes and we would like the
allocated buffers to be charged to the clients who requested their
allocation(instead of the allocating process as is the default
behavior). In Android, the graphics allocator HAL process[1] does
most of the graphics allocations on behalf of various clients. After
allocation, the HAL process passes the fd to the client over binder
IPC and the binder driver invokes the charge_to_cgroup() DMA-BUF op to
uncharge the buffer from the HAL process and charge it to the client
process instead.

[1]: https://source.android.com/devices/graphics/arch-bq-gralloc

Regards,
Hridya


>
> Regards,
> Christian.
>
> >   The caller must hold a reference to @gpucg obtained via
> > +      * gpucg_get(). The DMA-BUF will be uncharged from the cgroup it is
> > +      * currently charged to before being charged to @gpucg. The caller must
> > +      * belong to the cgroup the buffer is currently charged to.
> > +      *
> > +      * This callback is optional.
> > +      *
> > +      * Returns:
> > +      *
> > +      * 0 on success or negative error code on failure.
> > +      */
> > +     int (*charge_to_cgroup)(struct dma_buf *dmabuf, struct gpucg *gpucg);
> >   };
> >
> >   /**
>

WARNING: multiple messages have this Message-ID (diff)
From: Hridya Valsaraju <hridya@google.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Christian Brauner" <christian@brauner.io>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
	"Liam Mark" <lmark@codeaurora.org>,
	"Laura Abbott" <labbott@redhat.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"John Stultz" <john.stultz@li>
Subject: Re: [RFC 4/6] dma-buf: Add DMA-BUF exporter op to charge a DMA-BUF to a cgroup.
Date: Tue, 18 Jan 2022 10:54:16 -0800	[thread overview]
Message-ID: <CA+wgaPMjCfjQS4LA8hmVwAaGfXZhoJvvTUnOGt3duOhFb3orTw@mail.gmail.com> (raw)
In-Reply-To: <f8c8b196-7d12-6242-97ac-38149f3a3ba3@amd.com>

On Sun, Jan 16, 2022 at 11:46 PM Christian König
<christian.koenig@amd.com> wrote:
>
> Am 15.01.22 um 02:06 schrieb Hridya Valsaraju:
> > The optional exporter op provides a way for processes to transfer
> > charge of a buffer to a different process. This is essential for the
> > cases where a central allocator process does allocations for various
> > subsystems, hands over the fd to the client who
> > requested the memory and drops all references to the allocated memory.
> >
> > Signed-off-by: Hridya Valsaraju <hridya@google.com>
> > ---
> >   include/linux/dma-buf.h | 18 ++++++++++++++++++
> >   1 file changed, 18 insertions(+)
> >
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index 7ab50076e7a6..d5e52f81cc6f 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -13,6 +13,7 @@
> >   #ifndef __DMA_BUF_H__
> >   #define __DMA_BUF_H__
> >
> > +#include <linux/cgroup_gpu.h>
> >   #include <linux/dma-buf-map.h>
> >   #include <linux/file.h>
> >   #include <linux/err.h>
> > @@ -285,6 +286,23 @@ struct dma_buf_ops {
> >
> >       int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> >       void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > +
> > +     /**
> > +      * @charge_to_cgroup:
> > +      *
> > +      * This is called by an exporter to charge a buffer to the specified
> > +      * cgroup.
>
> Well that sentence makes absolutely no sense at all.
>
> The dma_buf_ops are supposed to be called by the DMA-buf subsystem on
> behalves of the importer and never by the exporter itself.
>
> I hope that this is just a documentation mixup.

Thank you for taking a look Christian!

Yes, that was poor wording, sorry about that. It should instead say
that the op would be called by the process the buffer is currently
charged to in order to transfer the buffer's charge to a different
cgroup. This is helpful in the case where a process acts as an
allocator for multiple client processes and we would like the
allocated buffers to be charged to the clients who requested their
allocation(instead of the allocating process as is the default
behavior). In Android, the graphics allocator HAL process[1] does
most of the graphics allocations on behalf of various clients. After
allocation, the HAL process passes the fd to the client over binder
IPC and the binder driver invokes the charge_to_cgroup() DMA-BUF op to
uncharge the buffer from the HAL process and charge it to the client
process instead.

[1]: https://source.android.com/devices/graphics/arch-bq-gralloc

Regards,
Hridya


>
> Regards,
> Christian.
>
> >   The caller must hold a reference to @gpucg obtained via
> > +      * gpucg_get(). The DMA-BUF will be uncharged from the cgroup it is
> > +      * currently charged to before being charged to @gpucg. The caller must
> > +      * belong to the cgroup the buffer is currently charged to.
> > +      *
> > +      * This callback is optional.
> > +      *
> > +      * Returns:
> > +      *
> > +      * 0 on success or negative error code on failure.
> > +      */
> > +     int (*charge_to_cgroup)(struct dma_buf *dmabuf, struct gpucg *gpucg);
> >   };
> >
> >   /**
>

  reply	other threads:[~2022-01-18 18:54 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-15  1:05 [RFC 0/6] Proposal for a GPU cgroup controller Hridya Valsaraju
2022-01-15  1:05 ` Hridya Valsaraju
2022-01-15  1:05 ` Hridya Valsaraju
2022-01-15  1:05 ` [RFC 1/6] gpu: rfc: " Hridya Valsaraju
2022-01-15  1:05   ` Hridya Valsaraju
2022-01-15  1:06 ` [RFC 2/6] cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory Hridya Valsaraju
2022-01-15  1:06   ` Hridya Valsaraju
     [not found]   ` <20220115010622.3185921-3-hridya-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2022-01-19 15:40     ` Randy Dunlap
2022-01-19 15:40   ` Randy Dunlap
2022-01-19 15:40     ` Randy Dunlap
2022-01-19 18:24     ` Hridya Valsaraju
2022-01-19 18:24       ` Hridya Valsaraju
2022-01-19 18:24       ` Hridya Valsaraju
2022-01-15  1:06 ` [RFC 3/6] dmabuf: heaps: Use the GPU cgroup charge/uncharge APIs Hridya Valsaraju
2022-01-15  1:06   ` Hridya Valsaraju
     [not found] ` <20220115010622.3185921-1-hridya-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2022-01-15  1:05   ` [RFC 1/6] gpu: rfc: Proposal for a GPU cgroup controller Hridya Valsaraju
2022-01-15  1:06   ` [RFC 2/6] cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory Hridya Valsaraju
2022-01-15  1:06   ` [RFC 3/6] dmabuf: heaps: Use the GPU cgroup charge/uncharge APIs Hridya Valsaraju
2022-01-15  1:06   ` [RFC 4/6] dma-buf: Add DMA-BUF exporter op to charge a DMA-BUF to a cgroup Hridya Valsaraju
2022-01-15  1:06   ` [RFC 6/6] android: binder: Add a buffer flag to relinquish ownership of fds Hridya Valsaraju
2022-01-15  1:06 ` [RFC 4/6] dma-buf: Add DMA-BUF exporter op to charge a DMA-BUF to a cgroup Hridya Valsaraju
2022-01-15  1:06   ` Hridya Valsaraju
2022-01-17  7:46   ` Christian König
2022-01-17  7:46     ` Christian König
2022-01-18 18:54     ` Hridya Valsaraju [this message]
2022-01-18 18:54       ` Hridya Valsaraju
2022-01-18 18:54       ` Hridya Valsaraju
2022-01-19 15:54       ` Daniel Vetter
2022-01-19 15:54         ` Daniel Vetter
2022-01-19 15:54         ` Daniel Vetter
2022-01-19 15:58         ` Christian König
2022-01-19 18:21           ` Hridya Valsaraju
2022-01-19 18:21             ` Hridya Valsaraju
2022-01-19 18:21             ` Hridya Valsaraju
     [not found]         ` <Yeg0GGi0tdnnCLHg-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2022-01-19 15:58           ` Christian König
     [not found]   ` <20220115010622.3185921-5-hridya-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2022-01-17  7:46     ` Christian König
2022-01-15  1:06 ` [RFC 5/6] dmabuf: system_heap: implement dma-buf op for GPU cgroup charge transfer Hridya Valsaraju
2022-01-15  1:06   ` Hridya Valsaraju
2022-01-15  1:06   ` Hridya Valsaraju
2022-01-15  1:06 ` [RFC 6/6] android: binder: Add a buffer flag to relinquish ownership of fds Hridya Valsaraju
2022-01-15  1:06   ` Hridya Valsaraju

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=CA+wgaPMjCfjQS4LA8hmVwAaGfXZhoJvvTUnOGt3duOhFb3orTw@mail.gmail.com \
    --to=hridya@google.com \
    --cc=Brian.Starkey@arm.com \
    --cc=Kenny.Ho@amd.com \
    --cc=airlied@linux.ie \
    --cc=airlied@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=arve@android.com \
    --cc=balejs@google.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=cgroups@vger.kernel.org \
    --cc=chris@chrisdown.name \
    --cc=christian.koenig@amd.com \
    --cc=christian@brauner.io \
    --cc=corbet@lwn.net \
    --cc=daniel@ffwll.ch \
    --cc=daniel@iogearbox.net \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dualli@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hangl@codeaurora.org \
    --cc=hannes@cmpxchg.org \
    --cc=jason@jlekstrand.net \
    --cc=joel@joelfernandes.org \
    --cc=john.stultz@linaro.org \
    --cc=kaleshsingh@google.com \
    --cc=keescook@chromium.org \
    --cc=labbott@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=lmark@codeaurora.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maco@android.com \
    --cc=masahiroy@kernel.org \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=mripard@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=ojeda@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=tjmercier@google.com \
    --cc=tkjos@android.com \
    --cc=tzimmermann@suse.de \
    --cc=vbabka@suse.cz \
    --cc=vipinsh@google.com \
    --cc=wedsonaf@google.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 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.