linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Lazar, Lijo" <lijo.lazar@amd.com>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org,
	"Christian König" <christian.koenig@amd.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Hawking Zhang" <Hawking.Zhang@amd.com>,
	"Feifei Xu" <Feifei.Xu@amd.com>, "Likun Gao" <Likun.Gao@amd.com>,
	"Jiawei Gu" <Jiawei.Gu@amd.com>, "Evan Quan" <evan.quan@amd.com>,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	linux-staging@lists.linux.dev, linux-block@vger.kernel.org,
	linux-kbuild@vger.kernel.org, clang-built-linux@googlegroups.com,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2 18/63] drm/amd/pm: Use struct_group() for memcpy() region
Date: Thu, 19 Aug 2021 10:33:43 +0530	[thread overview]
Message-ID: <e56aad3c-a06f-da07-f491-a894a570d78f@amd.com> (raw)
In-Reply-To: <202108181619.B603481527@keescook>



On 8/19/2021 5:29 AM, Kees Cook wrote:
> On Wed, Aug 18, 2021 at 05:12:28PM +0530, Lazar, Lijo wrote:
>>
>> On 8/18/2021 11:34 AM, Kees Cook wrote:
>>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>>> field bounds checking for memcpy(), memmove(), and memset(), avoid
>>> intentionally writing across neighboring fields.
>>>
>>> Use struct_group() in structs:
>>> 	struct atom_smc_dpm_info_v4_5
>>> 	struct atom_smc_dpm_info_v4_6
>>> 	struct atom_smc_dpm_info_v4_7
>>> 	struct atom_smc_dpm_info_v4_10
>>> 	PPTable_t
>>> so the grouped members can be referenced together. This will allow
>>> memcpy() and sizeof() to more easily reason about sizes, improve
>>> readability, and avoid future warnings about writing beyond the end of
>>> the first member.
>>>
>>> "pahole" shows no size nor member offset changes to any structs.
>>> "objdump -d" shows no object code changes.
>>>
>>> Cc: "Christian König" <christian.koenig@amd.com>
>>> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com>
>>> Cc: David Airlie <airlied@linux.ie>
>>> Cc: Daniel Vetter <daniel@ffwll.ch>
>>> Cc: Hawking Zhang <Hawking.Zhang@amd.com>
>>> Cc: Feifei Xu <Feifei.Xu@amd.com>
>>> Cc: Lijo Lazar <lijo.lazar@amd.com>
>>> Cc: Likun Gao <Likun.Gao@amd.com>
>>> Cc: Jiawei Gu <Jiawei.Gu@amd.com>
>>> Cc: Evan Quan <evan.quan@amd.com>
>>> Cc: amd-gfx@lists.freedesktop.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> Acked-by: Alex Deucher <alexander.deucher@amd.com>
>>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCADnq5_Npb8uYvd%2BR4UHgf-w8-cQj3JoODjviJR_Y9w9wqJ71mQ%40mail.gmail.com&amp;data=04%7C01%7Clijo.lazar%40amd.com%7C3861f20094074bf7328808d962a433f2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637649279701053991%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=386LcfJJGfQfHsXBuK17LMqxJ2nFtGoj%2FUjoN2ZtJd0%3D&amp;reserved=0
>>> ---
>>>    drivers/gpu/drm/amd/include/atomfirmware.h           |  9 ++++++++-
>>>    .../gpu/drm/amd/pm/inc/smu11_driver_if_arcturus.h    |  3 ++-
>>>    drivers/gpu/drm/amd/pm/inc/smu11_driver_if_navi10.h  |  3 ++-
>>>    .../gpu/drm/amd/pm/inc/smu13_driver_if_aldebaran.h   |  3 ++-
>>
>> Hi Kees,
> 
> Hi! Thanks for looking into this.
> 
>> The headers which define these structs are firmware/VBIOS interfaces and are
>> picked directly from those components. There are difficulties in grouping
>> them to structs at the original source as that involves other component
>> changes.
> 
> So, can you help me understand this a bit more? It sounds like these are
> generated headers, yes? I'd like to understand your constraints and
> weight them against various benefits that could be achieved here.
> 
> The groupings I made do appear to be roughly documented already,
> for example:
> 
>     struct   atom_common_table_header  table_header;
>       // SECTION: BOARD PARAMETERS
> +  struct_group(dpm_info,
> 
> Something emitted the "BOARD PARAMETERS" section heading as a comment,
> so it likely also would know where it ends, yes? The good news here is
> that for the dpm_info groups, they all end at the end of the existing
> structs, see:
> 	struct atom_smc_dpm_info_v4_5
> 	struct atom_smc_dpm_info_v4_6
> 	struct atom_smc_dpm_info_v4_7
> 	struct atom_smc_dpm_info_v4_10
> 
> The matching regions in the PPTable_t structs are similarly marked with a
> "BOARD PARAMETERS" section heading comment:
> 
> --- a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_arcturus.h
> +++ b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_arcturus.h
> @@ -643,6 +643,7 @@ typedef struct {
>     // SECTION: BOARD PARAMETERS
>   
>     // SVI2 Board Parameters
> +  struct_group(v4_6,
>     uint16_t     MaxVoltageStepGfx; // In mV(Q2) Max voltage step that SMU will request. Multiple steps are taken if voltage change exceeds this value.
>     uint16_t     MaxVoltageStepSoc; // In mV(Q2) Max voltage step that SMU will request. Multiple steps are taken if voltage change exceeds this value.
>   
> @@ -728,10 +729,10 @@ typedef struct {
>     uint32_t     BoardVoltageCoeffB;    // decode by /1000
>   
>     uint32_t     BoardReserved[7];
> +  );
>   
>     // Padding for MMHUB - do not modify this
>     uint32_t     MmHubPadding[8]; // SMU internal use
> -
>   } PPTable_t;
> 
> Where they end seems known as well (the padding switches from a "Board"
> to "MmHub" prefix at exactly the matching size).
> 
> So, given that these regions are already known by the export tool, how
> about just updating the export tool to emit a struct there? I imagine
> the problem with this would be the identifier churn needed, but that's
> entirely mechanical.
> 
> However, I'm curious about another aspect of these regions: they are,
> by definition, the same. Why isn't there a single struct describing
> them already, given the existing redundancy? For example, look at the
> member names: maxvoltagestepgfx vs MaxVoltageStepGfx. Why aren't these
> the same? And then why aren't they described separately?
> 
> Fixing that would cut down on the redundancy here, and in the renaming,
> you can fix the identifiers as well. It should be straight forward to
> write a Coccinelle script to do this renaming for you after extracting
> the structure.
> 
>> The driver_if_* files updates are frequent and it is error prone to manually
>> group them each time we pick them for any update.
> 
> Why are these structs updated? It looks like they're specifically
> versioned, and aren't expected to change (i.e. v4.5, v4.6, v4.10, etc).
> 
>> Our usage of memcpy in this way is restricted only to a very few places.
> 
> True, there's 1 per PPTable_t duplication. With a proper struct, you
> wouldn't even need a memcpy().
> 
> Instead of the existing:
>                 memcpy(smc_pptable->I2cControllers, smc_dpm_table_v4_7->I2cControllers,
>                         sizeof(*smc_dpm_table_v4_7) - sizeof(smc_dpm_table_v4_7->table_header));
> 
> or my proposed:
>                 memcpy(&smc_pptable->v4, &smc_dpm_table_v4_7->dpm_info,
>                        sizeof(smc_dpm_table_v4_7->dpm_info));
> 
> you could just have:
> 		smc_pptable->v4 = smc_dpm_table_v4_7->dpm_info;
> 
> since they'd be explicitly the same type.
> 
> That looks like a much cleaner solution to this. It greatly improves
> readability, reduces the redundancy in the headers, and should be a
> simple mechanical refactoring.
> 
> Oh my, I just noticed append_vbios_pptable() in
> drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_processpptables.c
> which does an open-coded assignment of the entire PPTable_t, including
> padding, and, apparently, the i2c address twice:
> 
>          ppsmc_pptable->Vr2_I2C_address = smc_dpm_table.Vr2_I2C_address;
> 
>          ppsmc_pptable->Vr2_I2C_address = smc_dpm_table.Vr2_I2C_address;
> 
>> As another option - is it possible to have a helper function/macro like
>> memcpy_fortify() which takes the extra arguments and does the extra compile
>> time checks? We will use the helper whenever we have such kind of usage.
> 
> I'd rather avoid special cases just for this, especially when the code
> here is already doing a couple things we try to avoid in the rest of
> the kernel (i.e. open coded redundant struct contents, etc).
> 
> If something mechanically produced append_vbios_pptable() above, I bet
> we can get rid of the memcpy()s entirely and save a lot of code doing a
> member-to-member assignment.
> 
> What do you think?
> 

Hi Kees,

Will give a background on why there are multiple headers and why it's 
structured this way. That may help to better understand this arrangement.

This code is part of driver for AMD GPUs. These GPUs get to the 
consumers through multiple channels - AMD designs a few boards with 
those, there are add-in-board partners like ASRock, Sapphire etc. who 
take these ASICs and design their own boards, and others like OEM 
vendors who have their own design for boards in their laptops.

As you have noticed, this particular section in the structure carries 
information categorized as 'BOARD PARAMETERS'. Since there are multiple 
vendors designing their own boards, this gives the option to customize 
the parameters based on their board design.

There are a few components in AMD GPUs which are interested in these 
board parameters main ones being - Video BIOS (VBIOS) and power 
management firmware (PMFW). There needs to be a single source where a 
vendor can input the information and that is decided as VBIOS. VBIOS 
carries different data tables which carry other information also (some 
of which are used by driver), so this information is added as a separate 
data table in VBIOS. A board vendor can customize the VBIOS build with 
this information.

The data tables (and some other interfaces with driver) carried by VBIOS 
are published in this header - drivers/gpu/drm/amd/include/atomfirmware.h

There are multiple families of AMD GPUs like Navi10, Arcturus, Aldebaran 
etc. and the board specific details change with different families of 
GPUs. However, VBIOS team publishes a common header file for these GPUs 
and any difference in data tables (between GPU families) is maintained 
through a versioning scheme. Thus there are different tables like 
atom_smc_dpm_info_v4_5, atom_smc_dpm_info_v4_6 etc. which are relevant 
for a particular family of GPUs.

With newer VBIOS versions and new GPU families, there could be changes 
in the structs defined in atomfirmware.h and we pick the header accordingly.
	
As mentioned earlier, one other user of the board specific information 
is power management firmware (PMFW). PMFW design is isolated from the 
actual source of board information. In addition to board specific 
information, PMFW needs some other info as well and driver is the one 
responsible for passing this info to the firmware. PMFW gives an 
interface header to driver providing the different struct formats which 
are used in driver<->PMFW interactions. Unlike VBIOS, these interface 
headers are defined per family of ASICs and those are 
smu11_driver_if_arcturus.h, smu11_driver_if_* etc. (in short driver_if_* 
files). Like VBIOS,  with newer firmware versions, there could be 
changes in the different structs defined in these headers and we pick 
them accordingly.

Driver acts the intermediary between actual source of board information 
(VBIOS) and PMFW. So what is being done here is driver picks the board 
information from VBIOS table, strips the VBIOS table header and passes 
it as part of PPTable_t which defines all the information that is needed 
by PMFW from driver for enabling dynamic power management.

In summary, these headers are not generated and not owned by driver. 
They define the interfaces of two different components with driver, and 
are consumed by those components themselves. A simple change to group 
the information as a separate structure involves changes in multiple 
components like VBIOS, PMFW, software used to build VBIOS, Windows 
driver etc.

In all practical cases, this code is harmless as these structs (in both 
headers) are well defined for a specific family of GPUs. There is always 
a reserve field defined with some extra bytes so that the size is not 
affected if at all new fields need to be added.

The patch now makes us to modify the headers for Linux through 
script/manually whenever we pick them, and TBH that strips off the 
coherency with the original source. The other option is field by field 
copy. Now we use memcpy as a safe bet so that a new field added later 
taking some reserve space is not missed even if we miss a header update.

Thanks,
Lijo


  reply	other threads:[~2021-08-19  5:04 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18  6:04 [PATCH v2 00/63] Introduce strict memcpy() bounds checking Kees Cook
2021-08-18  6:04 ` [PATCH v2 01/63] ipw2x00: Avoid field-overflowing memcpy() Kees Cook
2021-08-18  6:04 ` [PATCH v2 02/63] net/mlx5e: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 03/63] rpmsg: glink: Replace strncpy() with strscpy_pad() Kees Cook
2021-08-18  6:04 ` [PATCH v2 04/63] pcmcia: ray_cs: Split memcpy() to avoid bounds check warning Kees Cook
2021-08-18  6:04 ` [PATCH v2 05/63] stddef: Introduce struct_group() helper macro Kees Cook
2021-08-18 22:35   ` Dan Williams
2021-08-18  6:04 ` [PATCH v2 06/63] cxl/core: Replace unions with struct_group() Kees Cook
2021-08-18 22:36   ` Dan Williams
2021-08-18  6:04 ` [PATCH v2 07/63] skbuff: Switch structure bounds to struct_group() Kees Cook
2021-09-01 13:46   ` Jason A. Donenfeld
2021-08-18  6:04 ` [PATCH v2 08/63] bnxt_en: Use struct_group_attr() for memcpy() region Kees Cook
2021-08-18  6:04 ` [PATCH v2 09/63] mwl8k: Use struct_group() " Kees Cook
2021-08-18  6:04 ` [PATCH v2 10/63] libertas: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 11/63] libertas_tf: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 12/63] thermal: intel: int340x_thermal: " Kees Cook
2021-11-23 13:19   ` Rafael J. Wysocki
2021-11-23 23:53     ` Srinivas Pandruvada
2021-11-24 13:33       ` Rafael J. Wysocki
2021-08-18  6:04 ` [PATCH v2 13/63] iommu/amd: " Kees Cook
2021-08-18 11:34   ` Joerg Roedel
2021-08-18  6:04 ` [PATCH v2 14/63] cxgb3: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 15/63] intersil: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 16/63] cxgb4: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 17/63] bnx2x: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 18/63] drm/amd/pm: " Kees Cook
2021-08-18 11:42   ` Lazar, Lijo
2021-08-18 23:59     ` Kees Cook
2021-08-19  5:03       ` Lazar, Lijo [this message]
2021-08-19 19:58         ` Kees Cook
2021-08-18  6:04 ` [PATCH v2 19/63] staging: wlan-ng: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 20/63] drm/mga/mga_ioc32: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 21/63] net/mlx5e: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 22/63] HID: cp2112: " Kees Cook
2021-08-20 13:01   ` Jiri Kosina
2021-08-20 15:48     ` Kees Cook
2021-08-18  6:04 ` [PATCH v2 23/63] media: omap3isp: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 24/63] sata_fsl: " Kees Cook
2021-08-18  6:04 ` [PATCH v2 25/63] compiler_types.h: Remove __compiletime_object_size() Kees Cook
2021-08-18 13:02   ` Miguel Ojeda
2021-08-18  6:04 ` [PATCH v2 26/63] lib/string: Move helper functions out of string.c Kees Cook
2021-08-18  9:35   ` Andy Shevchenko
2021-08-18  6:04 ` [PATCH v2 27/63] fortify: Move remaining fortify helpers into fortify-string.h Kees Cook
2021-08-18 19:05   ` Francis Laniel
2021-08-18  6:04 ` [PATCH v2 28/63] fortify: Explicitly disable Clang support Kees Cook
2021-08-18  6:04 ` [PATCH v2 29/63] fortify: Fix dropped strcpy() compile-time write overflow check Kees Cook
2021-08-18  6:05 ` [PATCH v2 30/63] fortify: Prepare to improve strnlen() and strlen() warnings Kees Cook
2021-08-18  6:05 ` [PATCH v2 31/63] fortify: Allow strlen() and strnlen() to pass compile-time known lengths Kees Cook
2021-08-18  6:05 ` [PATCH v2 32/63] fortify: Add compile-time FORTIFY_SOURCE tests Kees Cook
2021-08-18  6:05 ` [PATCH v2 33/63] lib: Introduce CONFIG_TEST_MEMCPY Kees Cook
2021-08-18  6:05 ` [PATCH v2 34/63] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
2021-08-18  6:05 ` [PATCH v2 35/63] fortify: Detect struct member overflows in memmove() " Kees Cook
2021-08-18  6:05 ` [PATCH v2 36/63] scsi: ibmvscsi: Avoid multi-field memset() overflow by aiming at srp Kees Cook
2021-08-18  6:05 ` [PATCH v2 37/63] string.h: Introduce memset_after() for wiping trailing members/padding Kees Cook
2021-08-18  6:05 ` [PATCH v2 38/63] xfrm: Use memset_after() to clear padding Kees Cook
2021-08-18  6:05 ` [PATCH v2 39/63] ipv6: Use memset_after() to zero rt6_info Kees Cook
2021-08-18  6:05 ` [PATCH v2 40/63] netfilter: conntrack: Use memset_startat() to zero struct nf_conn Kees Cook
2021-08-18  6:05 ` [PATCH v2 41/63] net: 802: Use memset_startat() to clear struct fields Kees Cook
2021-08-18  6:05 ` [PATCH v2 42/63] net: dccp: Use memset_startat() for TP zeroing Kees Cook
2021-08-18  6:05 ` [PATCH v2 43/63] net: qede: Use memset_startat() for counters Kees Cook
2021-08-18  6:05 ` [PATCH v2 44/63] mac80211: Use memset_after() to clear tx status Kees Cook
2021-08-18  7:08   ` Johannes Berg
2021-08-18  8:06     ` Johannes Berg
2021-08-18  9:05       ` Kees Cook
2021-08-18  6:05 ` [PATCH v2 45/63] ath11k: Use memset_startat() for clearing queue descriptors Kees Cook
2021-08-19 13:19   ` Kalle Valo
2021-08-19 16:25     ` Kees Cook
2021-08-21 10:17       ` Kalle Valo
2021-08-22  8:11         ` Kees Cook
2021-08-18  6:05 ` [PATCH v2 46/63] iw_cxgb4: Use memset_startat() for cpl_t5_pass_accept_rpl Kees Cook
2021-08-18  6:05 ` [PATCH v2 47/63] intel_th: msu: Use memset_startat() for clearing hw header Kees Cook
2021-08-24  7:38   ` Alexander Shishkin
2021-08-18  6:05 ` [PATCH v2 48/63] IB/mthca: Use memset_startat() for clearing mpt_entry Kees Cook
2021-08-18  6:05 ` [PATCH v2 49/63] btrfs: Use memset_startat() to clear end of struct Kees Cook
2021-08-18  6:35   ` Nikolay Borisov
2021-08-18  9:28   ` David Sterba
2021-08-18  6:05 ` [PATCH v2 50/63] tracing: Use memset_startat() to zero struct trace_iterator Kees Cook
2021-08-18 13:33   ` Steven Rostedt
2021-08-18 16:21     ` Kees Cook
2021-08-18  6:05 ` [PATCH v2 51/63] drbd: Use struct_group() to zero algs Kees Cook
2021-08-18  6:05 ` [PATCH v2 52/63] cm4000_cs: Use struct_group() to zero struct cm4000_dev region Kees Cook
2021-08-18  6:05 ` [PATCH v2 53/63] KVM: x86: Use struct_group() to zero decode cache Kees Cook
2021-08-18 15:11   ` Sean Christopherson
2021-08-18 16:23     ` Kees Cook
2021-08-18 22:53       ` Sean Christopherson
2021-08-18 23:06         ` Kees Cook
2021-08-18  6:05 ` [PATCH v2 54/63] dm integrity: Use struct_group() to zero struct journal_sector Kees Cook
2021-08-18  6:05 ` [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event Kees Cook
2021-08-20 13:02   ` Jiri Kosina
     [not found]     ` <CAJr-aD=6-g7VRw2Hw0dhs+RrtA=Tago5r6Dukfw_gGPB0YYKOQ@mail.gmail.com>
2021-08-20 15:27       ` Jiri Kosina
2021-08-20 15:49         ` Kees Cook
2021-08-20 15:57         ` Kees Cook
2021-08-20 16:11           ` Jiri Kosina
2021-08-18  6:05 ` [PATCH v2 56/63] RDMA/mlx5: Use struct_group() to zero struct mlx5_ib_mr Kees Cook
2021-08-19 12:27   ` Jason Gunthorpe
2021-08-19 16:19     ` Kees Cook
2021-08-19 16:47       ` Jason Gunthorpe
2021-08-19 18:14         ` Kees Cook
2021-08-20 12:34           ` Jason Gunthorpe
2021-08-20 15:56             ` Kees Cook
2021-08-18  6:05 ` [PATCH v2 57/63] powerpc/signal32: Use struct_group() to zero spe regs Kees Cook
2021-08-20  7:49   ` Michael Ellerman
2021-08-20  7:53     ` Christophe Leroy
2021-08-20 12:13       ` Michael Ellerman
2021-08-20 15:55     ` Kees Cook
2021-08-23  4:55       ` Michael Ellerman
2021-08-18  6:05 ` [PATCH v2 58/63] ethtool: stats: Use struct_group() to clear all stats at once Kees Cook
2021-08-18  6:05 ` [PATCH v2 59/63] can: flexcan: Use struct_group() to zero struct flexcan_regs regions Kees Cook
2021-08-18  6:26   ` Marc Kleine-Budde
2021-08-18  6:05 ` [PATCH v2 60/63] net/af_iucv: Use struct_group() to zero struct iucv_sock region Kees Cook
2021-09-09  6:14   ` Karsten Graul
2021-08-18  6:05 ` [PATCH v2 61/63] powerpc: Split memset() to avoid multi-field overflow Kees Cook
2021-08-18  6:42   ` Christophe Leroy
2021-08-18 22:30     ` Kees Cook
2021-08-18  6:05 ` [PATCH v2 62/63] fortify: Detect struct member overflows in memset() at compile-time Kees Cook
2021-08-18  6:05 ` [PATCH v2 63/63] fortify: Work around Clang inlining bugs Kees Cook

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=e56aad3c-a06f-da07-f491-a894a570d78f@amd.com \
    --to=lijo.lazar@amd.com \
    --cc=Feifei.Xu@amd.com \
    --cc=Hawking.Zhang@amd.com \
    --cc=Jiawei.Gu@amd.com \
    --cc=Likun.Gao@amd.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=evan.quan@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavoars@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=netdev@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 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).