From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 095D6376E0 for ; Mon, 25 Nov 2024 11:56:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732535810; cv=none; b=nLh9dg0jQRUg3nzNOB1SbGeuwjK4mWo4kbUWFhSMMO5kPDF1iNE7IAKwh5uv4IKZ1V50y6g8k0DdCHIfrWXe4tDom6UqKw7kxvVvw4n001CrjLsQxJ7mfmhRh7+afxU710ZNSYB3fb1BbVqN2GK7Y2kS2PeorieDXQuG19aiHcw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732535810; c=relaxed/simple; bh=dyGAREdF6wLZko5THPZ7TK3rOCw1V/U5p4cXPE5bkXE=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qY7+WT9S4zv7IBx0lhgHMJ9i25cKZUdqJ6dc50FmbnS50w/7xjiL76t7PASOcx+8yaVI8U9m58sDSQry2RqZC8QZoMKDr4VC7ZDWeZpM3NYQHaA1Sxx5/Mn4OTnpuaQ/l794kUy6PiXw7mNIEUFulwmZGrJ56uATbE0FJMoibnY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Xxkgg4lh4z6LDHJ; Mon, 25 Nov 2024 19:56:15 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id C523E140C98; Mon, 25 Nov 2024 19:56:45 +0800 (CST) Received: from localhost (10.203.177.66) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 25 Nov 2024 12:56:45 +0100 Date: Mon, 25 Nov 2024 11:56:43 +0000 From: Jonathan Cameron To: Mauro Carvalho Chehab CC: Igor Mammedov , Shiju Jose , "Michael S. Tsirkin" , Ani Sinha , Dongjiu Geng , , , Subject: Re: [PATCH v4 08/15] acpi/ghes: make the GHES record generation more generic Message-ID: <20241125115643.00002923@huawei.com> In-Reply-To: References: X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100010.china.huawei.com (7.191.174.197) To frapeml500008.china.huawei.com (7.182.85.71) On Fri, 22 Nov 2024 10:11:25 +0100 Mauro Carvalho Chehab wrote: > Split the code into separate functions to allow using the > common CPER filling code by different error sources. > > The generic code was moved to ghes_record_cper_errors(), > and ghes_gen_err_data_uncorrectable_recoverable() now contains > only a logic to fill the Generic Error Data part of the record, > as described at: > > ACPI 6.2: 18.3.2.7.1 Generic Error Data > > The remaining code to generate a memory error now belongs to > acpi_ghes_record_errors() function. > > A further patch will give it a better name. > > Signed-off-by: Mauro Carvalho Chehab One trivial follow up that is enabled by the change you are discussing with Igor. Up to you that one. Reviewed-by: Jonathan Cameron > + > +int acpi_ghes_record_errors(uint16_t source_id, uint64_t physical_address) > +{ > + /* Memory Error Section Type */ > + const uint8_t guid[] = > + UUID_LE(0xA5BC1114, 0x6F64, 0x4EDE, 0xB8, 0x63, 0x3E, 0x83, \ > + 0xED, 0x7C, 0x83, 0xB1); > + Error *errp = NULL; > + int data_length; > + GArray *block; > + > + if (!physical_address) { > + error_report("can not find Generic Error Status Block for source id %d", > + source_id); > + return -1; > + } With this error check gone (as per discussion with Igor) you could use g_autofree to deal with freeing block. That would bring the errp check right next to the call that would result in errp potentially being set and slightly improve readability. Mind you there are no uses of this in hw/acpi currently so maybe this isn't a good time to start :) > + > + block = g_array_new(false, true /* clear */, 1); > + > + data_length = ACPI_GHES_DATA_LENGTH + ACPI_GHES_MEM_CPER_LENGTH; > + /* > + * It should not run out of the preallocated memory if adding a new generic > + * error data entry > + */ > + assert((data_length + ACPI_GHES_GESB_SIZE) <= > + ACPI_GHES_MAX_RAW_DATA_LENGTH); > + > + ghes_gen_err_data_uncorrectable_recoverable(block, guid, > + data_length); > + > + /* Build the memory section CPER for above new generic error data entry */ > + acpi_ghes_build_append_mem_cper(block, physical_address); > + > + /* Report the error */ > + ghes_record_cper_errors(block->data, block->len, source_id, &errp); > + > + g_array_free(block, true); > + > + if (errp) { > + error_report_err(errp); > + return -1; > + } > + > + return 0; > }