[<prev] [next>] [day] [month] [year] [list]
Message-ID: <6343ce9e-9d9e-fde9-7242-5ec612438fa1@marcan.st>
Date: Tue, 4 Jan 2022 14:22:57 +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 7:50, Andy Shevchenko wrote:
> > + 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.
>
>
>
> devm_kstrndup() then?
>
>
That doesn't seem to be a thing.
--
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists