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
| ||
|
Message-ID: <87cd5244-501d-1a3a-35d1-2687cf145bb9@marcan.st> 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
Powered by blists - more mailing lists