linux-kernel - Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI properties

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 4 Jan 2022 02:22:50 +0900
From:   Hector Martin <marcan@...can.st>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Kalle Valo <kvalo@...eaurora.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Arend van Spriel <aspriel@...il.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-hsien Lin <chi-hsien.lin@...ineon.com>,
        Wright Feng <wright.feng@...ineon.com>,
        Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Mark Kettenis <kettenis@...nbsd.org>,
        Rafał Miłecki <zajec5@...il.com>,
        Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Hans de Goede <hdegoede@...hat.com>,
        "John W. Linville" <linville@...driver.com>,
        "brian m. carlson" <sandals@...stytoothpaste.net>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "brcm80211-dev-list.pdl@...adcom.com" 
        <brcm80211-dev-list.pdl@...adcom.com>,
        "SHA-cyfmac-dev-list@...ineon.com" <SHA-cyfmac-dev-list@...ineon.com>
Subject: Re: [PATCH 16/34] brcmfmac: acpi: Add support for fetching Apple ACPI
 properties

On 2022/01/04 1:20, Andy Shevchenko wrote:
>     +void brcmf_acpi_probe(struct device *dev, enum brcmf_bus_type bus_type,
>     +                     struct brcmf_mp_device *settings)
>     +{
>     +       acpi_status status;
>     +       struct acpi_device *adev = ACPI_COMPANION(dev);
> 
> 
> Please, move the assignment closer to its first user 

So... two lines down? :-)

>   
> 
>     +       const union acpi_object *o;
>     +       struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
>     +
>     +       if (!adev)
>     +               return;
>     +
>     +       if (!ACPI_FAILURE(acpi_dev_get_property(adev, "module-instance",
>     +                                               ACPI_TYPE_STRING,
>     &o))) {
>     +               const char *prefix = "apple,";
>     +               int len = strlen(prefix) + o->string.length + 1;
>     +               char *board_type = devm_kzalloc(dev, len, GFP_KERNEL);
>     +
>     +               strscpy(board_type, prefix, len);
>     +               strlcat(board_type, o->string.pointer, 
> 
> 
> NIH devm_kasprintf()?

That sounds useful, didn't know that existed. Thanks!

>  
> 
>     +               brcmf_dbg(INFO, "ACPI module-instance=%s\n",
>     o->string.pointer);
>     +               settings->board_type = board_type;
>     +       } else {
>     +               brcmf_dbg(INFO, "No ACPI module-instance\n");
>     +       }
>     +
>     +       status = acpi_evaluate_object(adev->handle, "RWCV", NULL, &buf);
>     +       o = buf.pointer;
>     +       if (!ACPI_FAILURE(status) && o && o->type == ACPI_TYPE_BUFFER &&
>     +           o->buffer.length >= 2) {
>     +               char *antenna_sku = devm_kzalloc(dev, 3, GFP_KERNEL);
>     +
>     +               memcpy(antenna_sku, o->buffer.pointer, 2);
> 
> 
> NIH devm_kmemdup()?

Not *quite*. I take the first two bytes of the returned buffer and turn
them into a null-terminated 3-byte string. kmemdup wouldn't
null-terminate or would copy too much, depending on length.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub