linux-kernel - Re: [PATCH v8] platform: x86: Add ChromeOS ACPI device driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a6d6484d-583b-c5f3-bc3e-3a87037b9716@collabora.com>
Date:   Tue, 19 Apr 2022 14:24:55 +0500
From:   Muhammad Usama Anjum <usama.anjum@...labora.com>
To:     Barnabás Pőcze <pobrn@...tonmail.com>
Cc:     usama.anjum@...labora.com, "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <markgross@...nel.org>,
        Collabora Kernel ML <kernel@...labora.com>,
        groeck@...omium.org, bleung@...omium.org, dtor@...omium.org,
        gwendal@...omium.org, vbendeb@...omium.org, andy@...radead.org,
        Ayman Bagabas <ayman.bagabas@...il.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Blaž Hrastnik <blaz@...n.io>,
        Darren Hart <dvhart@...radead.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jeremy Soller <jeremy@...tem76.com>,
        Mattias Jacobsson <2pi@....nu>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Rajat Jain <rajatja@...gle.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Enric Balletbo i Serra <eballetbo@...il.com>
Subject: Re: [PATCH v8] platform: x86: Add ChromeOS ACPI device driver

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