Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a6d6484d-583b-c5f3-bc3e-3a87037b9716@collabora.com>
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" <rafael@kernel.org>,
        Len Brown <lenb@kernel.org>,
        Hans de Goede <hdegoede@redhat.com>,
        Mark Gross <markgross@kernel.org>,
        Collabora Kernel ML <kernel@collabora.com>,
        groeck@chromium.org, bleung@chromium.org, dtor@chromium.org,
        gwendal@chromium.org, vbendeb@chromium.org, andy@infradead.org,
        Ayman Bagabas <ayman.bagabas@gmail.com>,
        Benjamin Tissoires <benjamin.tissoires@redhat.com>,
        =?UTF-8?Q?Bla=c5=be_Hrastnik?= <blaz@mxxn.io>,
        Darren Hart <dvhart@infradead.org>,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jeremy Soller <jeremy@system76.com>,
        Mattias Jacobsson <2pi@mok.nu>,
        Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
        Rajat Jain <rajatja@google.com>,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-acpi@vger.kernel.org,
        "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
        Enric Balletbo i Serra <eballetbo@gmail.com>
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?= <pobrn@protonmail.com>
References: <Ylmmf03fewXEjRr0@debian-BULLSEYE-live-builder-AMD64>
 <eygNMwL4gadqjJuOq-syanavJ5sAb5_dHTcQ0V9TU5kM5uh5TZUQXdYsNFTtnSm1ZI5WKhw7BgzG8lXEwJKEZz4agWq5_HkFDGWiFuuo7fE=@protonmail.com>
 <78e3e1e9-e21f-052a-ecff-1d13714b4303@collabora.com>
From:   Muhammad Usama Anjum <usama.anjum@collabora.com>
In-Reply-To: <78e3e1e9-e21f-052a-ecff-1d13714b4303@collabora.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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