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 AB0D8C433ED for ; Tue, 11 May 2021 02:52:34 +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 5D95B61400 for ; Tue, 11 May 2021 02:52:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D95B61400 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 D394F6E9A4; Tue, 11 May 2021 02:52:33 +0000 (UTC) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2042.outbound.protection.outlook.com [40.107.236.42]) by gabe.freedesktop.org (Postfix) with ESMTPS id E3F156E9A4 for ; Tue, 11 May 2021 02:52:32 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WCgl/ex51Hep8eyP3bEmdlClw3Wy3a/5SIrwUsza6gpDtFl33ZKF6eF7QVaHl5ngqRzWzok7ve6J/79hqczmZhbEidancliMu+v5IE8CuhJdFzVJSIsaH999wSWAdX41cKXGE+DnC769VVDbT/A4SH0hOihMn89GZRrbGrsXvQwf4VLm+LWgIA9FLdL7dtYCefKzqWlyTXZ3DWvFpiUvGE8oSl5Ewp6tqqfh4Pu7XO1oZL19emTGLSilounNfMryC9ygWcfVuAZvTnlCWVaQH8SVBnkHWzkob5JBaCIDpZhFQ9PJcywfyJQFrQITuVdvjstTD72ZgrY1UDcVPo8NmA== 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=NtidKCknHIa7rp0t9vYt5BgnoV8kC1G6awEIZ7KhzhU=; b=Usq+qzETjQ/nfcg7SJ2KKyHfv43cv3S5OSYUcVXWb71EGweKz5lWoAHGzo+nTg+rXQxcOJEuBaMdEXNghaFA3nD0AT3AL9o9KkiTP99Vugc0OQOmJmvuVl1w7rSy30IZy1evvvcCc/GOVrVwaOlH+d7jggfGebvAY8bkY0k4LE8Gkhdrv3z+wWf8PCrZPjIxjwo9AF0iu/pjShXBIHJzV0E+WeFo0gPjnzwyApTJ9A59arpwZCfhv+ajhZKrCG8YAbnP1QSyeginsxfgoBDv9wAd9xzzpECETnhkFb+XOumqXxOqY215Y6qQ4/nYy637ITjPWVTjyBXWJC2a8HBCng== 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=NtidKCknHIa7rp0t9vYt5BgnoV8kC1G6awEIZ7KhzhU=; b=Oo8QOIjNnNlVDn0ZDwue5ZOjghz/3pWuHmvOnsNBfwALshBepSRqEi5Ev6DJ0GiD8uURlDGRXB2i8GD14Wxkugl7Db9tms98FKn0PAN1kF2Vt9cfPt9jj1I05bbD3WN92SLZnD7cqiVf/wlvk4Q2nb+JxVqtmhcdr5F/PKyPAhc= Received: from BYAPR12MB2840.namprd12.prod.outlook.com (2603:10b6:a03:62::32) by BYAPR12MB3239.namprd12.prod.outlook.com (2603:10b6:a03:137::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.29; Tue, 11 May 2021 02:52:29 +0000 Received: from BYAPR12MB2840.namprd12.prod.outlook.com ([fe80::7c65:7181:6d1d:8616]) by BYAPR12MB2840.namprd12.prod.outlook.com ([fe80::7c65:7181:6d1d:8616%7]) with mapi id 15.20.4108.031; Tue, 11 May 2021 02:52:29 +0000 From: "Nieto, David M" To: "Gu, JiaWei (Will)" , =?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: AQHXQ9Yf8LVbEME0wESo6KxpkiJJJqrbUMIAgADxAdCAAAjk7YAAA0iggABtf0iAAANEgP//9+aAgADU3gCAAA1l1w== Date: Tue, 11 May 2021 02:52:29 +0000 Message-ID: References: <20210508064740.7705-1-Jiawei.Gu@amd.com> <447046CE-6FB4-49D7-A74A-2188654F5D5C@amd.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_76546daa-41b6-470c-bb85-f6f40f044d7f_Enabled=True; MSIP_Label_76546daa-41b6-470c-bb85-f6f40f044d7f_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; MSIP_Label_76546daa-41b6-470c-bb85-f6f40f044d7f_SetDate=2021-05-11T02:52:29.227Z; MSIP_Label_76546daa-41b6-470c-bb85-f6f40f044d7f_Name=Internal Distribution Only; MSIP_Label_76546daa-41b6-470c-bb85-f6f40f044d7f_ContentBits=0; MSIP_Label_76546daa-41b6-470c-bb85-f6f40f044d7f_Method=Standard; authentication-results: amd.com; dkim=none (message not signed) header.d=none;amd.com; dmarc=none action=none header.from=amd.com; x-originating-ip: [165.204.53.104] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 340979de-1416-417d-ed4d-08d91427d14d x-ms-traffictypediagnostic: BYAPR12MB3239: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tFVJQ5GZaPfGj6iM1mgQfRwgNEXt98lzn6Yo//azZKaMynmXdMfpJ9eRCjmarc2GJWfTEhHlT6jIdXg+VQatPp3tPp6pNS0gJ7j7KR2ZDxvVCayhFFgXXYK56CfZerVioQAWxSB1M+NwhqF8wbO9q+xzW7ERyTmuYDs3agdr0aJzYJgYvm+Y5OoaVs0N6u1tnJFQ4PdDfQR/U/ri+wAAd9prrbYEr/n2udwxYgUiRUam924Q/eeUK6VGUwB8kR+UpV62n5NdlnmTby5XK1jZuHKfuPEypihQZ9XeUKFayIc5fyo3e6YrNxMCMGxDeGllgGA0dZvpWkPcsKxEFmFsrM60nTj4a4Cvu5RbO22YDv5Rqhox6ZnyKBTwIt4+4faTjVzerFWzovUi9LHJ7UmAJoWYxTMvurXtXGPBJkF3VJW/t4nB5QMkuoZnCnVXIq14DztzvxyG01MHqXZ5Et9T0gk7gMvsQeSeek3hp23TvANI9TSE52tkOEaDEl8fPhDu7hSChLw6ai8rACw14jVyCLRxQinuFg4x5be8r8X8sVoJ5jIkklXBiPPzlXSTzY/vkAWAq9MrrxpuMFSTOrxBfUD+bOBaJ+dgglHAVm4yFpYUqm4WwsdYrG3BudsNz4y8O4s/G20nFYCT2t571zPxwc8hwFELGI4TJFd0tWAhJTXR+LhyEaOEDvpiPLNSgJdu x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR12MB2840.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(376002)(396003)(136003)(366004)(33656002)(8676002)(26005)(19627235002)(110136005)(66574015)(54906003)(186003)(9686003)(55016002)(5660300002)(83380400001)(122000001)(4326008)(19627405001)(8936002)(2906002)(38100700002)(86362001)(66446008)(64756008)(76116006)(71200400001)(66476007)(478600001)(52536014)(6506007)(66556008)(316002)(166002)(966005)(7696005)(53546011)(45080400002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?vYgEsiPVUjIkppLI4F8GGT7qb4FWNmMr0rMeTXhLyYoYLxFywuZB0EO5?= =?Windows-1252?Q?ZmQ0ICxCBVBTy+YiDxBj/bczfVf9wOLiJixzftMdWhMqiCGYzLTRtXrn?= =?Windows-1252?Q?Pc1NYH+/0cxMPUbAdlLZdWXlK0jtRY6NYCPWZR3NyPO5ErS6NkgsnGrC?= =?Windows-1252?Q?bGjq5UCzViQ29mHP5EgafpXcl4KxeWUL36aQJYqApVQfTTltia9pGlnz?= =?Windows-1252?Q?wBvc1K/BZik85n0WhEopM4P41wzE/ObV/cttuf6KYa/6B8r5ZNmYVzvF?= =?Windows-1252?Q?fEuTmPkeMVsuyQLR9s+OuhCXtoF8WIOM+2NbuvnPCB3oCxlRedDmyzDR?= =?Windows-1252?Q?D3QcZitzs3frTX94UU+BAhBB7ogWEsvLor4G7DEUQz7BkOeoakiEg1/N?= =?Windows-1252?Q?PiLilvKph72dRkF4N6fgA4YV67ESleq77FjGVWPIIc6x+Q5+EBb6AcSv?= =?Windows-1252?Q?3ZjM9fFeXN0n0C7IFnwn/9NEysTyIxmLV1ik7YY5x/taMg0tB5XNuhrI?= =?Windows-1252?Q?UAiUdsMXLcJ6zyV+ned/C+BDqlDqs4TWIFYdwn5hJ4IvRUOJHapOxHfC?= =?Windows-1252?Q?O2yEbJUQixSB/MApFgNkW5SvTd6ilFU9tyxUYsZqpoOS13xAsyxRIugF?= =?Windows-1252?Q?Czoq899UhlWPaVg9HDRorcTbc8j12gZHbgL5i9eRAd6CAIeo2ARBuma+?= =?Windows-1252?Q?gW0yLNJNzKCoikSr9Hk4tJjRMa5HmLBUro2Lt1LIP7GcY4RfdU7lmrZb?= =?Windows-1252?Q?aDtwhRcbLM4uXlupVO4JQ5HYe9FFgLdBwMWCzpzwmrNKFqYEm5vAqczv?= =?Windows-1252?Q?+fdXD3+PK9mYVOGzbiGqFz6ynjyqHxRd4xc05GpFoABt/7MgGFGIqDtc?= =?Windows-1252?Q?jJ36wwu4QitydOx4WEJcvNY+4C4o27oCireX6GPKPzctageIzLgmMVMJ?= =?Windows-1252?Q?vIKMOLjWxU10FE0hT81dEVi7Eyof5iMgFbr5MlZy3tYTP8bvxn2dEsJb?= =?Windows-1252?Q?dS/NW220Dck1eEaCxzI+Z9ButVWN1UAINyWKvcfdmn64KgbzdNeePhuW?= =?Windows-1252?Q?p2mUNATjNZc2SZlyLC1x/LnrfO/d22GP7Yxjcqev5eWSpvqr62oG2TCN?= =?Windows-1252?Q?O7CBR7tICfTMONko5q1UTnYcRfWPdn8ymMoxE9Or1Usp7rst++lYvo7X?= =?Windows-1252?Q?zTgHWs2rmKdeHHr6SFUATjpxDqD9HrDNJqfPPH7lE6U93ZkfyOvqwByZ?= =?Windows-1252?Q?cs0Fzv/igZ6KY29TwEduAiLG4qr1Lz5ySODFdQwfHhWLRY8b0V3GFID8?= =?Windows-1252?Q?IV8343N/rmhiGtKLGaDQPIiS4aQJgrFKP8AlKHA5U+ynMtSTBY7eGsBy?= =?Windows-1252?Q?EzSXGfbh8k5dopOGpDgcWA3vVkZYTeSTfJPFXgb3DmcNRgZ8wmtvQQD+?= MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR12MB2840.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 340979de-1416-417d-ed4d-08d91427d14d X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2021 02:52:29.6581 (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: +G+6Yf6jsX1PCyiG9Xqazk5KyA0h5DaLZ76yoL4RUStMlpTgCRR8vfhJXTT/WMC0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3239 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: Alex Deucher , "Deng, Emily" , Kees Cook , amd-gfx list Content-Type: multipart/mixed; boundary="===============2025523940==" Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" --===============2025523940== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BYAPR12MB284050850E3DD885927F97F1F4539BYAPR12MB2840namp_" --_000_BYAPR12MB284050850E3DD885927F97F1F4539BYAPR12MB2840namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [AMD Official Use Only - Internal Distribution Only] I agree that the serial number should be on number form, but I think we are= still missing one field, which is the vbios name, which is located after t= he P/N, ASIC, PCI and memory type strings (skiping 0xD 0xA David ________________________________ From: Gu, JiaWei (Will) Sent: Monday, May 10, 2021 7:23 PM To: Nieto, David M ; Christian K=F6nig Cc: Alex Deucher ; Deng, Emily ;= Kees Cook ; amd-gfx list Subject: RE: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_info_vbios [AMD Official Use Only - Internal Distribution Only] Got it. Let=92s keep them both. Another idea about drm_amdgpu_info_vbios is Does it make more sense to fill the =93serial info=94 with uint64_t adev->u= nique_id, instead of the current char[] in adev->serial? Sorry about that I was not aware of adev->unique_id exists when I defined d= rm_amdgpu_info_vbios. I think it=92s clearer to use original numeric variable than a string to ex= pose serial. How about that? >> struct drm_amdgpu_info_vbios { >> __u8 vbios_pn[64]; >> __u32 version; >> __u8 date[32]; >> - __u8 serial[16]; >> + __u64 serial; >> __u32 dev_id; >> __u32 rev_id; >> __u32 sub_dev_id; >> -- Best regards, Jiawei From: Nieto, David M Sent: Tuesday, May 11, 2021 4:20 AM To: Christian K=F6nig ; Gu, JiaWei (Will)= Cc: Alex Deucher ; Deng, Emily ;= Kees Cook ; amd-gfx list Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_info_vbios 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-gfx&data=3D04%7C01%7CJ >> i >> awei.Gu%40amd.com%7Ccea31833184c41e8574508d9130360cc%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 --_000_BYAPR12MB284050850E3DD885927F97F1F4539BYAPR12MB2840namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

[AMD Official Use Only - Internal Distribution Only]


I agree that the serial number should be on number form, but I think w= e are still missing one field, which is the vbios name, which is located af= ter the P/N, ASIC, PCI and memory type strings (skiping 0xD 0xA

David
From: Gu, JiaWei (Will) <= ;JiaWei.Gu@amd.com>
Sent: Monday, May 10, 2021 7:23 PM
To: Nieto, David M <David.Nieto@amd.com>; Christian K=F6nig &l= t;ckoenig.leichtzumerken@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; Deng, Emily <Emil= y.Deng@amd.com>; Kees Cook <keescook@chromium.org>; amd-gfx list &= lt;amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_inf= o_vbios
 

[AMD Official Use Only = - Internal Distribution Only]

 

Got it. Let=92s keep them both.

 

Another idea about drm_amdgpu_info_vbios is

Does it make more sense to fill the =93serial info= =94 with uint64_t adev->unique_id, instead of the current char[] in adev= ->serial?

 

Sorry about that I was not aware of adev->uniqu= e_id exists when I defined drm_amdgpu_info_vbios.

I think it=92s clearer to use original numeric var= iable than a string to expose serial.

 

How about that?

 

>> struct drm_amdgpu_info_vbios {
>>        __u8 vbios_pn[64];
>>        __u32 version;
>>        __u8 date[32];
>> -       __u8 serial[16];
>> +       __u64 serial;
>>        __u32 dev_id;
>>        __u32 rev_id;
>>        __u32 sub_dev_id;
>> --

 

Best regards,

Jiawei

 

 

From: Nieto, David M <David.Nieto@amd.co= m>
Sent: Tuesday, May 11, 2021 4:20 AM
To: Christian K=F6nig <ckoenig.leichtzumerken@gmail.com>; Gu, = JiaWei (Will) <JiaWei.Gu@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; Deng, Emily <Emil= y.Deng@amd.com>; Kees Cook <keescook@chromium.org>; amd-gfx list &= lt;amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_inf= o_vbios

 

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.

 

Regards,

David

 

F= rom: Christian K=F6nig <ckoenig.leichtzumerken@gma= il.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 <alexde= ucher@gmail.com>, "Deng, Emily" <Emily.Deng@amd.com>, Kees Cook <keescook@chromium.org>, amd-gfx list <amd-gfx@lists.freedes= ktop.org>
Subject: Re: [PATCH] drm/amdgpu: Align serial size in drm_amdgpu_inf= o_vbios

 

Well we could add b= oth 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 sys= fs file to get all the information it needs. It makes little sense from a p= rogramming perspective to add an incomplete interface in my opinion 

 

From: Gu, JiaWei (Will) <JiaWei.Gu@amd.com>
Sent: Monday, May 10, 2021 12:13:07 AM
To: Nieto, David M <David.= Nieto@amd.com>
Cc: Alex Deucher <alexde= ucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesk= top.org>; Kees Cook <keescook@chromium.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@am= d.com>
Cc: Alex Deucher <alexdeucher@g= mail.com>; amd-gfx list <amd-gfx@lists.freedesk= top.org>; Kees Cook <keescook@chromium.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 <alexde= ucher@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
> <keescook@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.fre= edesktop.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%7C3dd8961fe48= 84e
>> 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.freedes=
ktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

 

--_000_BYAPR12MB284050850E3DD885927F97F1F4539BYAPR12MB2840namp_-- --===============2025523940== 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 --===============2025523940==--