From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.4 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,HTTPS_HTTP_MISMATCH, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,MIME_HTML_MOSTLY, PDS_BAD_THREAD_QP_64,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77BD7C43461 for ; Tue, 11 May 2021 14:04:49 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1939A60200 for ; Tue, 11 May 2021 14:04:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1939A60200 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=amd.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 85FF76E1A3; Tue, 11 May 2021 14:04:48 +0000 (UTC) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2052.outbound.protection.outlook.com [40.107.92.52]) by gabe.freedesktop.org (Postfix) with ESMTPS id 20A366E1A3 for ; Tue, 11 May 2021 14:04:47 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZwkPEthWE9uv6xrWi7qk0YwDVJxCBtF4q4rxG2qZfSF6hs2j801VehFYcwTXtzQ63E76kUmZCQsIzb5FToi/Y8f7jBwlxhVgxhg7keCkS125zrZTzDjNUnDc0zcj029uhG2HpUVNSrwEi82V4DilydIwVy3AAt5LkmZtkTMjU6Zr6+bpwIPFjIy9r/G9dE5WAKB/UT9Lv7ewaqlxdhDCNPTsx5+V02hkKyQleX8uROVNNz8hHh+N79bpXIVRlTDWvj3zXmaz2H77A9iSD65YtCQCc+TsXAfvsIrUo2GbncBbiJciSgrBd77ow2F47fWRdk23bt5QKqtFww7Pu/JFyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F+slpepyUheKJGg9UGvoosTH7lPvlJWfupXlvlUAYr4=; b=arBhZgVIO9CmBOyQU/nndyDg0O1+Pv9OdvHTBhlBBkGR51/Iy5YUofH1cKni8cWKsR45atjwbOHvXkZH9VVpckRM7UYrVyA2lx793am/+sfCMszURPUVkPjkvK8fsVtHuVjReXPVD2SUmITcw9naa4G0+D9vANCyuYiFYsXSMmrAdImzDCzalZNzBoMESu4DMiZdryYZ3JTG9B9z978z1kEGGBQdz+wQyH6DI1UbfC2Qe5xPSIw/D7gLew7orNa0lBNcZSGmQrL1pog8es3B/OQa1LOudYZNWyTKy7cyCAVyrIYRtEgpWnJMFtIl+JDkZLa++2H8R5eqD81i7WfWGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F+slpepyUheKJGg9UGvoosTH7lPvlJWfupXlvlUAYr4=; b=YOcUDveLghAjoz1qK0+1dyQ8+Doqma75/OOUlpjpbBIVI4xeUqUk744OEu60Efo0u3Il2YQYwB/XYbF/rUWIRnX3sHInXdQMRR4GgoCepFzMMaHngZUPF2EKC0um7sguHzQpuEHnp1kdUHgGEkoL2szEUGXSbfXIYlKjxeQ60ts= Received: from MN2PR12MB4488.namprd12.prod.outlook.com (2603:10b6:208:24e::19) by MN2PR12MB4423.namprd12.prod.outlook.com (2603:10b6:208:24f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.24; Tue, 11 May 2021 14:04:45 +0000 Received: from MN2PR12MB4488.namprd12.prod.outlook.com ([fe80::3d98:cefb:476c:c36e]) by MN2PR12MB4488.namprd12.prod.outlook.com ([fe80::3d98:cefb:476c:c36e%8]) with mapi id 15.20.4108.032; Tue, 11 May 2021 14:04:45 +0000 From: "Deucher, Alexander" To: =?Windows-1252?Q?Marek_Ol=9A=E1k?= , =?Windows-1252?Q?Christian_K=F6nig?= Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_info_vbios Thread-Topic: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_info_vbios Thread-Index: AQHXQ9YlvIFc8fppMkC+tA7DX/OMKKrbUMIAgAD0PQCAAAWogIAABYaAgABsrACAAAHZgIAAbT+AgADBMACAAAe/gIAAYE12 Date: Tue, 11 May 2021 14:04:45 +0000 Message-ID: References: <20210508064740.7705-1-Jiawei.Gu@amd.com> <447046CE-6FB4-49D7-A74A-2188654F5D5C@amd.com> <88e868eb-347b-611b-8d88-ba8d9d61c23b@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0d814d60-469d-470c-8cb0-58434e2bf457_Enabled=True; MSIP_Label_0d814d60-469d-470c-8cb0-58434e2bf457_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; MSIP_Label_0d814d60-469d-470c-8cb0-58434e2bf457_SetDate=2021-05-11T14:04:44.505Z; MSIP_Label_0d814d60-469d-470c-8cb0-58434e2bf457_Name=AMD Public; MSIP_Label_0d814d60-469d-470c-8cb0-58434e2bf457_ContentBits=0; MSIP_Label_0d814d60-469d-470c-8cb0-58434e2bf457_Method=Privileged; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=amd.com; x-originating-ip: [192.161.79.245] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8544c091-b5cc-4518-dda3-08d91485bb1d x-ms-traffictypediagnostic: MN2PR12MB4423: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bCqIFzL4ya8+NYUP/kNGbXUZQ1qTPual5c0YnC07FKyEp0KG7SiIjSGAAZ7sSEMika1j4lKtmZ0cIwLbCqfQYnNtOatzB0hOEt+N3o90gbze1P2q2L0D/0IGMkc+6t1V4PrXvDISEceID7GTr+OR3isDJgQjtukshVODqMkof3UE//UidRnaOVIhay1lgsKUO4nfxLnR5i7EjYLDsUYfoa9y0T/kP1+ej5qUDjFEds2Un82wAml25xdaLC64XeyzPOAdhfHEsSdilrawqKaiSkxYTkxfi2wGPc7c6J5FqmJzerugfPOtF9/c7rXljTFhNIpjsEsApSuqgzJ6P+xvDkh1NJ+k2Enjbb7Dd5/oe4HTVXuFtbJBsC4WeG9dHP6mE6i/TMmrqn1QpKPwlrBfaA84qI6BHdUdwsn6GiQ7zi8BlZ8KKFhpzqz/5yePyQuI/nsoT1zu27wxd48nRfZXk4Pj2XnDfubdNvyVzr5hEAO0ZncEalTBtEosEe4miCTnaRATIh8dG0hksmTDHZ73V/3gCVm7epOW9SvIvqgz+DGO1fpjUqmpCjgE5nf2z17sI7Yvl8Qga8qNTUQUzyqofodQnLot5kabm4fOGtsh6GS2j0l6Q7h3/fLRdMhRzVx8a5KsFiEqnNztI8IFBgLf/wcnxSXVWwF7ooFMvqjHsRsfgvCCl02ZcT+6UxFtMP9B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR12MB4488.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39850400004)(366004)(396003)(136003)(346002)(86362001)(45080400002)(66946007)(64756008)(478600001)(76116006)(66446008)(66556008)(66476007)(7696005)(53546011)(6506007)(5660300002)(54906003)(4326008)(52536014)(2906002)(83380400001)(55016002)(110136005)(9686003)(8676002)(66574015)(186003)(966005)(26005)(8936002)(38100700002)(19627405001)(166002)(71200400001)(122000001)(33656002)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?Gec4wHO9jciPPwGWCHAg6nZwzSHIF8yoLKcMIVvbdpyYdTrsW+RPbwpu?= =?Windows-1252?Q?4bj92D8qvVpdbrsIrJ4L3E3Oh9Yw+L1724Jx55FJCCDmybLZ247RpIKm?= =?Windows-1252?Q?AIL0NqHCj5ucoF+Cv4hL7hfLY9TqNIoxEW/PEDXvB2/zY1/rc/ZPM7PH?= =?Windows-1252?Q?gmmVtWSdw9gyG5F2kQMhGXL1GdSGbmy0q09z0Mo3CjDevIdzW84PGXZ/?= =?Windows-1252?Q?n/5XeQ6pn7h1/hzDltm4Kif8YzCZ4y34R9+KhXbH5JPCOB4Skm9/uijs?= =?Windows-1252?Q?4CksYhKXQJVU1uotyrQtA30fblylsrJTg2kbjpZmopBzxzYZJvka4pwo?= =?Windows-1252?Q?lSYIZAoxpfogcfzPdnKtrmuVqhh3qt9jT09DUjiWL7cmWj15ya+BESNI?= =?Windows-1252?Q?WBTaS9hrcJqZS33qKKCVCPF4vwkwBxm7FnhZtTnU4Xp4MXIclLuY7zMm?= =?Windows-1252?Q?UWjn0l0D4b/mJX3tZWQTpVsGJB5MfPV6KmonsVPCDBjeZJd1HrI/AGsk?= =?Windows-1252?Q?euzijFaaCqrwRh3/bc+5ksq2ipmQ11xjdtpZ39zLNcJ4vspYSMZbNyqg?= =?Windows-1252?Q?O5KGSpSREgFOg2GpCXm6u1MSdOcVNp+QUTBZSEbs5p7gHeO63x9P5X7t?= =?Windows-1252?Q?63hx9cLug3BM/a8bWUd3r83r06+F31KhjG3qi6KTP7/7qln7e+cxNXT2?= =?Windows-1252?Q?//sk/q720a5mlWA/DWJ8MiOvoDDQCjqpsoDP/BVmaKZh2O7RkPskWsYt?= =?Windows-1252?Q?nx0XshhWmdlIknt4zFy31KeRJQf51RUlM576sYQSKJ1s/X1hCYc9xRTQ?= =?Windows-1252?Q?lULskrETGnWpvO6TTnrAv8mJ+fyxbr+vJVVC9BcMEOstOGGhp6GaNvHg?= =?Windows-1252?Q?6dS/Hq7+4CeQ72MOgK9tSguucEdXjdIg9VE21eQNlmDXWn8teVSipJHx?= =?Windows-1252?Q?4iKLcWTB0x3IubSoGQm5m+YNvOBniSkZT4pcQEIoeWLQ8WBwt61ZWaUj?= =?Windows-1252?Q?lWXIJOVhm2r00Bo+fgvhLEBoc/P+yP/QKuW6x/RhsV0FImHEciHAtl5d?= =?Windows-1252?Q?2rooVTWkc1pybgYwuAo06er8j01oueV+JH7PSILsBpkrV+gGWsw0hCA6?= =?Windows-1252?Q?9wuB4xnHgM2w/qOT78fsaL5770/QxS1crpQeRXhnTfdy8ofjMtSU4HST?= =?Windows-1252?Q?WsX6kiZ2IjcxrsBYU64cghg+l0dpWmWXnGE+PZ5YsoZGEs8KZyxXaSWc?= =?Windows-1252?Q?hMCozXDN538A4yQcLmB5jLIv6FeEEW4/55Z6rurG0xqM545i77jT7naW?= =?Windows-1252?Q?FIQrWVEUv8Sft5qKLsFIjjQAZVrbQ1esazV/bf2OJK+ZUc21/gC3LavT?= =?Windows-1252?Q?sdJ5xKKSeyAGxg4Me2lapmtI59lu0Jw8zvyBBXaCKQqmBUUnvPN0RCOL?= MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4488.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8544c091-b5cc-4518-dda3-08d91485bb1d X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2021 14:04:45.0684 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tLxK50ixpD3oOBzkH3HE1ksAMH8Y6HgcKZ8xrSrIGnoVCnPYPnSYVas+1ez5idcjnNM/EbG98HYK+Npntf3fGg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4423 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kees Cook , "Gu, JiaWei \(Will\)" , amd-gfx list , "Deng, Emily" , Alex Deucher , "Nieto, David M" Content-Type: multipart/mixed; boundary="===============0482945632==" Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" --===============0482945632== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN2PR12MB4488E0D428871797E08DEE2BF7539MN2PR12MB4488namp_" --_000_MN2PR12MB4488E0D428871797E08DEE2BF7539MN2PR12MB4488namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [AMD Public Use] It's being used by umr and some other smi tools to provide vbios informatio= n for debugging. Alex ________________________________ From: amd-gfx on behalf of Marek Ol= =9A=E1k Sent: Tuesday, May 11, 2021 4:18 AM To: Christian K=F6nig Cc: Kees Cook ; Gu, JiaWei (Will) ; amd-gfx list ; Deng, Emily ; Alex Deucher ; Nieto, David M Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_info_vbios Mesa doesn't use sysfs. Note that this is a uapi, meaning that once it's in the kernel, it can't be= changed like that. What's the use case for this new interface? Isn't it partially redundant wi= th the current device info structure, which seems to have the equivalent of= dev_id and rev_id? Marek On Tue, May 11, 2021 at 3:51 AM Christian K=F6nig > wrote: Marek and other userspace folks need to decide that. Basic question here is if Mesa is already accessing sysfs nodes for OpenGL = or RADV. If that is the case then we should probably expose the information= there as well. If that isn't the case (which I think it is) then we should implement it as= IOCTL. Regards, Christian. Am 10.05.21 um 22:19 schrieb Nieto, David M: One of the primary usecases is to add this information to the renderer stri= ng, I am not sure if there are other cases of UMD drivers accessing sysfs n= odes, but I think if we think permissions, if a client is authenticated and= opens the render device then it can use the IOCTL, it is unclear to me we = can make a such an assumption for sysfs nodes=85 I think there is value in having both tbh. Regards, David From: Christian K=F6nig Date: Monday, May 10, 2021 at 6:48 AM To: "Nieto, David M" , "Gu= , JiaWei (Will)" Cc: Alex Deucher , "De= ng, Emily" , Kees Cook , amd-gfx list Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_info_vbios Well we could add both as sysfs file(s). Question here is rather what is the primary use case of this and if the app= lication has the necessary access permissions to the sysfs files? Regards, Christian. Am 10.05.21 um 15:42 schrieb Nieto, David M: Then the application would need to issue the ioctl and then open a sysfs fi= le to get all the information it needs. It makes little sense from a progra= mming perspective to add an incomplete interface in my opinion ________________________________ From: Gu, JiaWei (Will) Sent: Monday, May 10, 2021 12:13:07 AM To: Nieto, David M Cc: Alex Deucher ; amd= -gfx list ; Kees Cook ; Deng= , Emily Subject: RE: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_info_vbios [AMD Official Use Only - Internal Distribution Only] Hi David, What I meant is to ONLY delete the serial[16] from drm_amdgpu_info_vbios, n= ot the whole struct. struct drm_amdgpu_info_vbios { __u8 name[64]; __u32 dbdf; __u8 vbios_pn[64]; __u32 version; __u8 date[32]; __u8 serial[16]; // jiawei: shall we delete this __u32 dev_id; __u32 rev_id; __u32 sub_dev_id; __u32 sub_ved_id; }; serial[16] in drm_amdgpu_info_vbios copied from adev->serial, but there's = already a sysfs named serial_number, which exposes it already. static ssize_t amdgpu_device_get_serial_number(struct device *dev, struct device_attribute *attr, char *buf) { struct drm_device *ddev =3D dev_get_drvdata(dev); struct amdgpu_device *adev =3D ddev->dev_private; return snprintf(buf, PAGE_SIZE, "%s\n", adev->serial); } Thanks, Jiawei -----Original Message----- From: Nieto, David M Sent: Monday, May 10, 2021 2:53 PM To: Gu, JiaWei (Will) Cc: Alex Deucher ; amd= -gfx list ; Kees Cook ; Deng= , Emily Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_info_vbios No, this structure contains all the details of the vbios: date, serial numb= er, name, etc. The sysfs node only contains the vbios name string > On May 9, 2021, at 23:33, Gu, JiaWei (Will) wrote: > > [AMD Official Use Only - Internal Distribution Only] > > With a second thought, > __u8 serial[16] in drm_amdgpu_info_vbios is a bit redundant, sysfs serial= _number already exposes it. > > Is it fine to abandon it from drm_amdgpu_info_vbios struct? @Alex > Deucher @Nieto, David M > > Best regards, > Jiawei > > -----Original Message----- > From: Alex Deucher > Sent: Sunday, May 9, 2021 11:59 PM > To: Gu, JiaWei (Will) > Cc: amd-gfx list ; Kees Cook > > Subject: Re: [PATCH] drm/amdgpu: Align serial size in > drm_amdgpu_info_vbios > >> On Sat, May 8, 2021 at 2:48 AM Jiawei Gu wrote: >> >> 20 should be serial char size now instead of 16. >> >> Signed-off-by: Jiawei Gu > > Please make sure this keeps proper 64 bit alignment in the structure. > > Alex > > >> --- >> include/uapi/drm/amdgpu_drm.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/include/uapi/drm/amdgpu_drm.h >> b/include/uapi/drm/amdgpu_drm.h index 2b487a8d2727..1c20721f90da >> 100644 >> --- a/include/uapi/drm/amdgpu_drm.h >> +++ b/include/uapi/drm/amdgpu_drm.h >> @@ -957,7 +957,7 @@ struct drm_amdgpu_info_vbios { >> __u8 vbios_pn[64]; >> __u32 version; >> __u8 date[32]; >> - __u8 serial[16]; >> + __u8 serial[20]; >> __u32 dev_id; >> __u32 rev_id; >> __u32 sub_dev_id; >> -- >> 2.17.1 >> >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx@lists.freedesktop.org >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flis >> t >> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-g= fx&data=3D04%7C01%7CJ >> i >> awei.Gu%40amd.com%7Ccea31833184c41e8574508d9130360= cc%7C3dd8961fe4884e >> 6 >> 08e11a82d994e183d%7C0%7C0%7C637561727523880356%7CUnknown%7CTWFpbGZsb3 >> d >> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 >> C >> 1000&sdata=3DkAJiC6WoJUTeExwk6ftrLfMoY2OTAwg9X7mGgJT3kLk%3D&res >> e >> rved=3D0 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx --_000_MN2PR12MB4488E0D428871797E08DEE2BF7539MN2PR12MB4488namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

[AMD Public Use]


It's being used by umr and some other smi tools to provide vbios informatio= n for debugging.

Alex

From: amd-gfx <amd-gfx-b= ounces@lists.freedesktop.org> on behalf of Marek Ol=9A=E1k <maraeo@gm= ail.com>
Sent: Tuesday, May 11, 2021 4:18 AM
To: Christian K=F6nig <ckoenig.leichtzumerken@gmail.com>
Cc: Kees Cook <keescook@chromium.org>; Gu, JiaWei (Will) <J= iaWei.Gu@amd.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>; D= eng, Emily <Emily.Deng@amd.com>; Alex Deucher <alexdeucher@gmail.c= om>; Nieto, David M <David.Nieto@amd.com>
Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_inf= o_vbios
 
Mesa doesn't use sysfs.

Note that this is a uapi, meaning that once it's in the kernel, it can= 't be changed like that.

What's the use case for this new interface? Isn't it partially redunda= nt with the current device info structure, which seems to have the equivale= nt of dev_id and rev_id?

Marek

On Tue, May 11, 2021 at 3:51 AM Chr= istian K=F6nig <ckoenig.leichtzumerken@gmail.com> wrote:
Marek and other userspace folks need to decide that.

Basic question here is if Mesa is already accessing sysfs nodes for OpenGL = or RADV. If that is the case then we should probably expose the information= there as well.

If that isn't the case (which I think it is) then we should implement it as= IOCTL.

Regards,
Christian.

Am 10.05.21 um 22:19 schrieb Nieto, David M:

One of the primary usecases is to add this informa= tion to the renderer string, I am not sure if there are other cases of UMD = drivers accessing sysfs nodes, but I think if we think permissions, if a cl= ient is authenticated and opens the render device then it can use the IOCTL, it is unclear to me we can make a= such an assumption for sysfs nodes=85

 

I think there is value in having both tbh.<= u>

 

Regards,

David

 

Fro= m: Christian K=F6nig <ckoenig.leichtzumerken@gmail.com>
Date: Monday, May 10, 2021 at 6:48 AM
To: "Nieto, David M" <David.Nieto@amd.com>, "Gu, JiaWei (Will)" <JiaWei.Gu@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>, "Deng, Emily" <Emily.Deng@amd.= com>, Kees Cook <keescook@chr= omium.org>, amd-gfx list <amd-= gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_inf= o_vbios

 

Well we could add bot= h as sysfs file(s).

Question here is rather what is the primary use case of this and if the app= lication has the necessary access permissions to the sysfs files?

Regards,
Christian.

Am 10.05.21 um 15:42 schrieb Nieto, David M:

Then the application would need to issue the = ioctl and then open a sysfs file to get all the information it needs. It ma= kes little sense from a programming perspective to add an incomplete interface in my opinion 

 

From: Gu, JiaWei (Will) <JiaWei.Gu@amd.co= m>
Sent: Monday, May 10, 2021 12:13:07 AM
To: Nieto, David M <David.Nieto@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-= gfx@lists.freedesktop.org>; Kees Cook <keescook@chr= omium.org>; Deng, Emily <Emily.Deng@amd.= com>
Subject: RE: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_inf= o_vbios

 

[AMD Official Use Only - Internal Distribution Onl= y]

Hi David,

What I meant is to ONLY delete the serial[16] from drm_amdgpu_info_vbios, n= ot the whole struct.

struct drm_amdgpu_info_vbios {
        __u8 name[64];
        __u32 dbdf;
        __u8 vbios_pn[64];
        __u32 version;
        __u8 date[32];
        __u8 serial[16]; // jiawei: shal= l we delete this
        __u32 dev_id;
        __u32 rev_id;
        __u32 sub_dev_id;
        __u32 sub_ved_id;
};

serial[16] in drm_amdgpu_info_vbios  copied from adev->serial, but = there's already a sysfs named serial_number, which exposes it already.

static ssize_t amdgpu_device_get_serial_number(struct device *dev,
            &nb= sp;   struct device_attribute *attr, char *buf)
{
        struct drm_device *ddev =3D dev_= get_drvdata(dev);
        struct amdgpu_device *adev =3D d= dev->dev_private;

        return snprintf(buf, PAGE_SIZE, = "%s\n", adev->serial);
}

Thanks,
Jiawei


-----Original Message-----
From: Nieto, David M <David.Nieto@amd.com>
Sent: Monday, May 10, 2021 2:53 PM
To: Gu, JiaWei (Will) <JiaWei.Gu@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-= gfx@lists.freedesktop.org>; Kees Cook <keescook@chr= omium.org>; Deng, Emily <Emily.Deng@amd.= com>
Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_info_vbios=

No, this structure contains all the details of the vbios: date, serial numb= er, name, etc.

The sysfs node only contains the vbios name string

> On May 9, 2021, at 23:33, Gu, JiaWei (Will) <JiaWei.Gu@amd.com> wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> With a second thought,
> __u8 serial[16] in drm_amdgpu_info_vbios is a bit redundant, sysfs ser= ial_number already exposes it.
>
> Is it fine to abandon it from drm_amdgpu_info_vbios struct? @Alex
> Deucher @Nieto, David M
>
> Best regards,
> Jiawei
>
> -----Original Message-----
> From: Alex Deucher <alexdeucher@gmail.com>
> Sent: Sunday, May 9, 2021 11:59 PM
> To: Gu, JiaWei (Will) <JiaWei.Gu@amd.com>
> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>; Kees Cook
> <keescoo= k@chromium.org>
> Subject: Re: [PATCH] drm/amdgpu: Align serial size in
> drm_amdgpu_info_vbios
>
>> On Sat, May 8, 2021 at 2:48 AM Jiawei Gu <Jiawei.Gu@amd.com> wrote:
>>
>> 20 should be serial char size now instead of 16.
>>
>> Signed-off-by: Jiawei Gu <Jiawei.Gu@amd.com>
>
> Please make sure this keeps proper 64 bit alignment in the structure.<= br> >
> Alex
>
>
>> ---
>> include/uapi/drm/amdgpu_drm.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/drm/amdgpu_drm.h
>> b/include/uapi/drm/amdgpu_drm.h index 2b487a8d2727..1c20721f90da >> 100644
>> --- a/include/uapi/drm/amdgpu_drm.h
>> +++ b/include/uapi/drm/amdgpu_drm.h
>> @@ -957,7 +957,7 @@ struct drm_amdgpu_info_vbios {
>>        __u8 vbios_pn[64];
>>        __u32 version;
>>        __u8 date[32];
>> -       __u8 serial[16];
>> +       __u8 serial[20];
>>        __u32 dev_id;
>>        __u32 rev_id;
>>        __u32 sub_dev_id;
>> --
>> 2.17.1
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flis=
>> t
>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&amp;data=3D04%7C01= %7CJ
>> i
>> awei.Gu%40amd.com%7Ccea31833184c41e8574508d9130360cc%7C3dd8961fe4884e
>> 6
>> 08e11a82d994e183d%7C0%7C0%7C637561727523880356%7CUnknown%7CTWFpbGZ= sb3
>> d
>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7
>> C
>> 1000&amp;sdata=3DkAJiC6WoJUTeExwk6ftrLfMoY2OTAwg9X7mGgJT3kLk%3= D&amp;res
>> e
>> rved=3D0



_______________________________________________
amd-gfx mailing list
amd=
-gfx@lists.freedesktop.org
https://list=
s.freedesktop.org/mailman/listinfo/amd-gfx




_______________________________________________
amd-gfx mailing list
amd-gfx@= lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
--_000_MN2PR12MB4488E0D428871797E08DEE2BF7539MN2PR12MB4488namp_-- --===============0482945632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx --===============0482945632==--