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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BEF7C433EF for ; Tue, 19 Apr 2022 09:25:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348105AbiDSJ1x (ORCPT ); Tue, 19 Apr 2022 05:27:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350398AbiDSJ1u (ORCPT ); Tue, 19 Apr 2022 05:27:50 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D2A3BC9B; Tue, 19 Apr 2022 02:25:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: usama.anjum) with ESMTPSA id EC0CB1F42013 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1650360307; bh=a6llNOMgG5c9GRiJFktr/S/R/Vwl5cl+XkvWKZME0hA=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=CqizTF9Ce2vQ2D/wegQIAIsidWCzd0dYTleYYRWjS5bJGSCyK7p222QRMRo70VD4a MqFb6L1xkC6A0CeUdU6t6a2ee3GUnKYUNm87HmitUbpN6YboUImDr3mheXL+ds/DTO kLE0FfxERhsuopC8fn06c0brC4LSL5dvTUGCcnti/ghH7PayrqGgyFdX5ER4naAOm9 nlTGYlAkbbFdBeERWZArDhMysZdxBeSKDC8bpL9DwGjdVvYrx2MgSVsYaFUkFWnw9r fsjFuF6SY+ZywUlUhnuN2A4b6z9+3y71gneiSkJV1BxbEjDWY42aPJbY0ZB3SB7thT vBujHncmIFAXw== Message-ID: Date: Tue, 19 Apr 2022 14:24:55 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Cc: usama.anjum@collabora.com, "Rafael J. Wysocki" , Len Brown , Hans de Goede , Mark Gross , Collabora Kernel ML , groeck@chromium.org, bleung@chromium.org, dtor@chromium.org, gwendal@chromium.org, vbendeb@chromium.org, andy@infradead.org, Ayman Bagabas , Benjamin Tissoires , =?UTF-8?Q?Bla=c5=be_Hrastnik?= , Darren Hart , Dmitry Torokhov , Greg Kroah-Hartman , Jeremy Soller , Mattias Jacobsson <2pi@mok.nu>, Mauro Carvalho Chehab , Rajat Jain , Srinivas Pandruvada , platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, "Rafael J . Wysocki" , Enric Balletbo i Serra Subject: Re: [PATCH v8] platform: x86: Add ChromeOS ACPI device driver Content-Language: en-US To: =?UTF-8?Q?Barnab=c3=a1s_P=c5=91cze?= References: <78e3e1e9-e21f-052a-ecff-1d13714b4303@collabora.com> From: Muhammad Usama Anjum In-Reply-To: <78e3e1e9-e21f-052a-ecff-1d13714b4303@collabora.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On 4/18/22 10:31 PM, Muhammad Usama Anjum wrote: > Hi, > > Thanks for reviewing. > >>> + switch (element->type) { >>> + case ACPI_TYPE_BUFFER: >>> + length = element->buffer.length; >>> + info->data = kmemdup(element->buffer.pointer, >>> + length, GFP_KERNEL); >>> + break; >>> + case ACPI_TYPE_INTEGER: >>> + length = snprintf(buffer, sizeof(buffer), "%d", >>> + (int)element->integer.value); >>> + info->data = kmemdup(buffer, length, GFP_KERNEL); >> >> You can use `kasprintf()` here, no? >> Yeah, I can use sasprintf() in place of snprintf() and kmemdup(). Thanks. > Choosing kmemdup vs k*printf depends on what is being achieved. Usage of > kmemdup indicates that only the memory is being duplicated here. While > in case of k*printf, some transformation is done. Thus in normal memory > duplication cases like this, the usage of kmemdup makes code more > readable and seems preferable to me. > -- Muhammad Usama Anjum