From: Dmitry Osipenko <digetx@gmail.com>
To: Hector Martin <marcan@marcan.st>,
Kalle Valo <kvalo@codeaurora.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, Arend van Spriel <aspriel@gmail.com>,
Franky Lin <franky.lin@broadcom.com>,
Hante Meuleman <hante.meuleman@broadcom.com>,
Chi-hsien Lin <chi-hsien.lin@infineon.com>,
Wright Feng <wright.feng@infineon.com>
Cc: "Sven Peter" <sven@svenpeter.dev>,
"Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
"Mark Kettenis" <kettenis@openbsd.org>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Pieter-Paul Giesberts" <pieter-paul.giesberts@broadcom.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Hans de Goede" <hdegoede@redhat.com>,
"John W. Linville" <linville@tuxdriver.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
"Andy Shevchenko" <andy.shevchenko@gmail.com>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com,
SHA-cyfmac-dev-list@infineon.com
Subject: Re: [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths
Date: Thu, 6 Jan 2022 20:40:34 +0300 [thread overview]
Message-ID: <57716712-024d-af7e-394b-72ca9cb008d0@gmail.com> (raw)
In-Reply-To: <6a936aea-ada4-fe2d-7ce6-7a42788e4d63@marcan.st>
05.01.2022 16:22, Hector Martin пишет:
> On 05/01/2022 07.09, Dmitry Osipenko wrote:
>> 04.01.2022 11:43, Hector Martin пишет:
>>>>> +static int brcm_alt_fw_paths(const char *path, const char *board_type,
>>>>> + const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS])> {
>>>>> char alt_path[BRCMF_FW_NAME_LEN];
>>>>> const char *suffix;
>>>>>
>>>>> + memset(alt_paths, 0, array_size(sizeof(*alt_paths),
>>>>> + BRCMF_FW_MAX_ALT_PATHS));
>>>> You don't need to use array_size() since size of a fixed array is
>>>> already known.
>>>>
>>>> memset(alt_paths, 0, sizeof(alt_paths));
>>> It's a function argument, so that doesn't work and actually throws a
>>> warning. Array function argument notation is informative only; they
>>> behave strictly equivalent to pointers. Try it:
>>>
>>> $ cat test.c
>>> #include <stdio.h>
>>>
>>> void foo(char x[42])
>>> {
>>> printf("%ld\n", sizeof(x));
>>> }
>>>
>>> int main() {
>>> char x[42];
>>>
>>> foo(x);
>>> }
>>> $ gcc test.c
>>> test.c: In function ‘foo’:
>>> test.c:5:31: warning: ‘sizeof’ on array function parameter ‘x’ will
>>> return size of ‘char *’ [-Wsizeof-array-argument]
>>> 5 | printf("%ld\n", sizeof(x));
>>> | ^
>>> test.c:3:15: note: declared here
>>> 3 | void foo(char x[42])
>>> | ~~~~~^~~~~
>>> $ ./a.out
>>> 8
>>
>> Then please use "const char **alt_paths" for the function argument to
>> make code cleaner and add another argument to pass the number of array
>> elements.
>
> So you want me to do the ARRAY_SIZE at the caller side then?
>
>>
>> static int brcm_alt_fw_paths(const char *path, const char *board_type,
>> const char **alt_paths, unsigned int num_paths)
>> {
>> size_t alt_paths_size = array_size(sizeof(*alt_paths), num_paths);
>>
>> memset(alt_paths, 0, alt_paths_size);
>> }
>>
>> ...
>>
>> Maybe even better create a dedicated struct for the alt_paths:
>>
>> struct brcmf_fw_alt_paths {
>> const char *alt_paths[BRCMF_FW_MAX_ALT_PATHS];
>> unsigned int index;
>> };
>>
>> and then use the ".index" in the brcm_free_alt_fw_paths(). I suppose
>> this will make code a bit nicer and easier to follow.
>>
>
> I'm confused; the array size is constant. What would index contain and
> why would would brcm_free_alt_fw_paths use it? Just as an iterator
> variable instead of using a local variable? Or do you mean count?
Yes, use index for the count of active entries in the alt_paths[].
for (i = 0; i < alt_paths.index; i++)
kfree(alt_paths.path[i]);
alt_paths.index = 0;
or
while (alt_paths.index)
kfree(alt_paths.path[--alt_paths.index]);
> Though, to be honest, at this point I'm considering rethinking the whole
> patch for this mechanism because I'm not terribly happy with the current
> approach and clearly you aren't either :-) Maybe it makes more sense to
> stop trying to compute all the alt_paths ahead of time, and just have
> the function compute a single one to be used just-in-time at firmware
> request time, and just iterate over board_types.
>
The just-in-time approach sounds like a good idea.
next prev parent reply other threads:[~2022-01-06 17:40 UTC|newest]
Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 7:26 [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Hector Martin
2022-01-04 7:26 ` [PATCH v2 01/35] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips Hector Martin
2022-01-11 18:45 ` Rob Herring
2022-01-04 7:26 ` [PATCH v2 02/35] brcmfmac: pcie: Declare missing firmware files in pcie.c Hector Martin
2022-01-06 9:56 ` Arend van Spriel
2022-01-06 11:10 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 03/35] brcmfmac: firmware: Handle per-board clm_blob files Hector Martin
2022-01-06 10:19 ` Arend van Spriel
2022-01-06 10:59 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 04/35] brcmfmac: firmware: Support having multiple alt paths Hector Martin
2022-01-04 8:26 ` Dmitry Osipenko
2022-01-04 8:43 ` Hector Martin
2022-01-04 22:09 ` Dmitry Osipenko
2022-01-05 13:22 ` Hector Martin
2022-01-06 17:40 ` Dmitry Osipenko [this message]
2022-01-06 17:58 ` Andy Shevchenko
2022-01-07 3:12 ` Dmitry Osipenko
2022-01-07 9:55 ` Andy Shevchenko
2022-01-04 22:36 ` Dmitry Osipenko
2022-01-04 22:38 ` Dmitry Osipenko
2022-01-06 10:43 ` Arend van Spriel
2022-01-06 11:12 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 05/35] brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanism Hector Martin
2022-01-06 10:48 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 06/35] brcmfmac: firmware: Support passing in multiple board_types Hector Martin
2022-01-04 10:22 ` Arend van Spriel
2022-01-04 10:30 ` Hector Martin
2022-01-04 11:28 ` Andy Shevchenko
2022-01-07 2:50 ` Hector Martin
2022-01-06 12:16 ` Arend van Spriel
2022-01-07 4:02 ` Hector Martin
2022-01-07 6:17 ` Arend Van Spriel
2022-01-07 7:12 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 07/35] brcmfmac: pcie: Read Apple OTP information Hector Martin
2022-01-04 11:26 ` Andy Shevchenko
2022-01-07 3:53 ` Hector Martin
2022-01-06 12:37 ` Arend van Spriel
2022-01-06 13:08 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 08/35] brcmfmac: of: Fetch Apple properties Hector Martin
2022-01-04 11:17 ` Andy Shevchenko
2022-01-07 3:54 ` Hector Martin
2022-01-08 20:03 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms Hector Martin
2022-01-04 14:24 ` Andy Shevchenko
2022-01-06 13:12 ` Hector Martin
2022-01-08 20:03 ` Arend van Spriel
2022-01-17 6:36 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 10/35] brcmfmac: firmware: Allow platform to override macaddr Hector Martin
2022-01-04 14:23 ` Andy Shevchenko
2022-01-05 13:26 ` Hector Martin
2022-01-06 14:20 ` Andy Shevchenko
2022-01-07 2:39 ` Hector Martin
2022-01-08 20:14 ` Arend van Spriel
2022-01-17 6:38 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 11/35] brcmfmac: msgbuf: Increase RX ring sizes to 1024 Hector Martin
2022-01-10 7:17 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 12/35] brcmfmac: pcie: Fix crashes due to early IRQs Hector Martin
2022-01-04 14:12 ` Andy Shevchenko
2022-01-06 13:10 ` Hector Martin
2022-01-10 13:54 ` Kalle Valo
2022-01-10 7:19 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 13/35] brcmfmac: pcie: Support PCIe core revisions >= 64 Hector Martin
2022-01-10 7:31 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 14/35] brcmfmac: pcie: Add IDs/properties for BCM4378 Hector Martin
2022-01-10 9:10 ` Arend van Spriel
2022-01-10 11:04 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 15/35] ACPI / property: Support strings in Apple _DSM props Hector Martin
2022-01-04 7:26 ` [PATCH v2 16/35] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
2022-01-04 10:21 ` Arend van Spriel
2022-01-04 11:00 ` Hector Martin
2022-01-10 14:01 ` Kalle Valo
2022-01-10 9:11 ` Arend van Spriel
2022-01-10 11:07 ` Hector Martin
2022-01-10 11:26 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 17/35] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
2022-01-10 9:11 ` Arend van Spriel
2022-01-10 11:09 ` Hector Martin
2022-01-10 11:28 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 18/35] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
2022-01-10 9:12 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 19/35] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
2022-01-10 9:12 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 20/35] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin
2022-01-10 9:12 ` Arend van Spriel
2022-01-10 11:20 ` Hector Martin
2022-01-10 12:02 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 21/35] brcmfmac: chip: Only disable D11 cores; handle an arbitrary number Hector Martin
2022-01-19 12:36 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 22/35] brcmfmac: chip: Handle 1024-unit sizes for TCM blocks Hector Martin
2022-01-19 12:36 ` Arend van Spriel
2022-01-20 8:49 ` Arend van Spriel
2022-01-31 16:21 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 23/35] brcmfmac: cfg80211: Add support for scan params v2 Hector Martin
2022-01-04 19:46 ` Arend Van Spriel
2022-01-17 6:57 ` Hector Martin
2022-01-11 8:50 ` Arend van Spriel
2022-01-17 6:58 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 24/35] brcmfmac: feature: Add support for setting feats based on WLC version Hector Martin
2022-01-21 7:35 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 25/35] brcmfmac: cfg80211: Add support for PMKID_V3 operations Hector Martin
2022-01-21 7:35 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 26/35] brcmfmac: cfg80211: Pass the PMK in binary instead of hex Hector Martin
2022-01-21 7:35 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 27/35] brcmfmac: pcie: Add IDs/properties for BCM4387 Hector Martin
2022-01-21 7:35 ` Arend van Spriel
2022-01-31 16:37 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 28/35] brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio Hector Martin
2022-01-04 7:26 ` [PATCH v2 29/35] brcmfmac: pcie: Read the console on init and shutdown Hector Martin
2022-01-04 7:26 ` [PATCH v2 30/35] brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path Hector Martin
2022-01-04 7:26 ` [PATCH v2 31/35] brcmfmac: firmware: Allocate space for default boardrev in nvram Hector Martin
2022-01-04 7:26 ` [PATCH v2 32/35] brcmfmac: fwil: Constify iovar name arguments Hector Martin
2022-01-04 7:26 ` [PATCH v2 33/35] brcmfmac: common: Add support for downloading TxCap blobs Hector Martin
2022-01-21 7:36 ` Arend van Spriel
2022-01-31 16:28 ` Hector Martin
2022-01-04 7:26 ` [PATCH v2 34/35] brcmfmac: pcie: Load and provide " Hector Martin
2022-01-21 7:36 ` Arend van Spriel
2022-01-04 7:26 ` [PATCH v2 35/35] brcmfmac: common: Add support for external calibration blobs Hector Martin
2022-01-21 7:35 ` Arend van Spriel
2022-01-04 14:28 ` [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms Andy Shevchenko
2022-01-10 10:14 ` Kalle Valo
2022-01-10 11:21 ` Hector Martin
2022-01-10 13:46 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57716712-024d-af7e-394b-72ca9cb008d0@gmail.com \
--to=digetx@gmail.com \
--cc=SHA-cyfmac-dev-list@infineon.com \
--cc=alyssa@rosenzweig.io \
--cc=andy.shevchenko@gmail.com \
--cc=aspriel@gmail.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=chi-hsien.lin@infineon.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=franky.lin@broadcom.com \
--cc=hante.meuleman@broadcom.com \
--cc=hdegoede@redhat.com \
--cc=kettenis@openbsd.org \
--cc=kuba@kernel.org \
--cc=kvalo@codeaurora.org \
--cc=lenb@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=marcan@marcan.st \
--cc=netdev@vger.kernel.org \
--cc=pieter-paul.giesberts@broadcom.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sandals@crustytoothpaste.net \
--cc=sven@svenpeter.dev \
--cc=wright.feng@infineon.com \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).