| Message ID | 20181009124755.25402-5-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | [1/6] brcmfmac: Remove firmware-loading code duplication | expand |
Hans de Goede <hdegoede@redhat.com> writes: > For x86 based machines, set the board_type used for nvram file selection > based on the DMI sys-vendor and product-name strings. > > Since on some models these strings are too generic, this commit also adds > a quirk table overriding the strings for models listed in that table. > > The board_type setting is used to load the board-specific nvram file with > a board-specific name so that we can ship files for each supported board > in linux-firmware. > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> [...] > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c > @@ -0,0 +1,104 @@ > +// SPDX-License-Identifier: ISC I don't see the ISC file in LICENSES directory[1] and I don't feel comfortable taking SPDX tags which which don't have a license file. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICENSES
Hi, On 10-10-18 09:09, Kalle Valo wrote: > Hans de Goede <hdegoede@redhat.com> writes: > >> For x86 based machines, set the board_type used for nvram file selection >> based on the DMI sys-vendor and product-name strings. >> >> Since on some models these strings are too generic, this commit also adds >> a quirk table overriding the strings for models listed in that table. >> >> The board_type setting is used to load the board-specific nvram file with >> a board-specific name so that we can ship files for each supported board >> in linux-firmware. >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > [...] > >> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c >> @@ -0,0 +1,104 @@ >> +// SPDX-License-Identifier: ISC > > I don't see the ISC file in LICENSES directory[1] and I don't feel > comfortable taking SPDX tags which which don't have a license file. Ok. I need to do a patch for the LICENSES directory anyways, so I will also submit the ISC license upstream while at it, I will hopefully get around to doing that today. So how do you want to proceed with this, do you want me to just put the full ISC text in the header for now as the rest of brcmfmac does? Then later someone (me if I get around to it) can replace all of the headers with // SPDX-License-Identifier: ISC once it has been added under LICENSES. Regards, Hans
Hans de Goede <hdegoede@redhat.com> writes: > Hi, > > On 10-10-18 09:09, Kalle Valo wrote: >> Hans de Goede <hdegoede@redhat.com> writes: >> >>> For x86 based machines, set the board_type used for nvram file selection >>> based on the DMI sys-vendor and product-name strings. >>> >>> Since on some models these strings are too generic, this commit also adds >>> a quirk table overriding the strings for models listed in that table. >>> >>> The board_type setting is used to load the board-specific nvram file with >>> a board-specific name so that we can ship files for each supported board >>> in linux-firmware. >>> >>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> >> [...] >> >>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c >>> @@ -0,0 +1,104 @@ >>> +// SPDX-License-Identifier: ISC >> >> I don't see the ISC file in LICENSES directory[1] and I don't feel >> comfortable taking SPDX tags which which don't have a license file. > > Ok. I need to do a patch for the LICENSES directory anyways, so I will > also submit the ISC license upstream while at it, I will hopefully > get around to doing that today. That would be awesome, thanks! Then I could do the SPDX conversion also on ath10k. > So how do you want to proceed with this, do you want me to just > put the full ISC text in the header for now as the rest of brcmfmac > does? Yeah, I think this is the fastest way. > Then later someone (me if I get around to it) can replace all of > the headers with // SPDX-License-Identifier: ISC once it has been > added under LICENSES. Sounds good to me.
On 10/10/2018 9:28 AM, Hans de Goede wrote: > So how do you want to proceed with this, do you want me to just > put the full ISC text in the header for now as the rest of brcmfmac > does? This is not entirely true as far as I know. I assume you are referring to this: /* * Copyright (c) 2010 Broadcom Corporation * * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ As far as I recall we opted for BSD license and ISC is equivalent. However, The BSD license are already in place so why not use that. I would say BSD-2-Clause should cover it. As this is a new file I guess it is up to you although I would prefer to stick with a permissive license. Regards, Arend
Arend van Spriel <arend.vanspriel@broadcom.com> writes: > On 10/10/2018 9:28 AM, Hans de Goede wrote: >> So how do you want to proceed with this, do you want me to just >> put the full ISC text in the header for now as the rest of brcmfmac >> does? > > This is not entirely true as far as I know. I assume you are referring > to this: > > /* > * Copyright (c) 2010 Broadcom Corporation > * > * Permission to use, copy, modify, and/or distribute this software for any > * purpose with or without fee is hereby granted, provided that the above > * copyright notice and this permission notice appear in all copies. > * > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE > FOR ANY > * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > AN ACTION > * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN > * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > */ > > As far as I recall we opted for BSD license and ISC is equivalent. Oh, sorry for missing that. > However, The BSD license are already in place so why not use that. I > would say BSD-2-Clause should cover it. As this is a new file I guess > it is up to you although I would prefer to stick with a permissive > license. From maintainer's point of view I very much prefer that a driver uses the same license in all files. It's very confusing if the license changes within different files.
Hi Arend, On 10-10-18 09:52, Arend van Spriel wrote: > On 10/10/2018 9:28 AM, Hans de Goede wrote: >> So how do you want to proceed with this, do you want me to just >> put the full ISC text in the header for now as the rest of brcmfmac >> does? > > This is not entirely true as far as I know. I assume you are referring to this: > > /* > * Copyright (c) 2010 Broadcom Corporation > * > * Permission to use, copy, modify, and/or distribute this software for any > * purpose with or without fee is hereby granted, provided that the above > * copyright notice and this permission notice appear in all copies. > * > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY > * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION > * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN > * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > */ > > As far as I recall we opted for BSD license and ISC is equivalent. I believe it is the other way around, you opted for the ISC license which is more or less equivalent to the 2 clause BSD, see: https://spdx.org/licenses/BSD-2-Clause.html https://spdx.org/licenses/ISC The ISC text is a 1:1 match to the license used in brcmfmac, and it seems sensible to me to be consistent and use the same license for all brcmfmac files even if the 2 are more or less equivalent. > However, The BSD license are already in place so why not use that. I would say BSD-2-Clause should cover it. As this is a new file I guess it is up to you although I would prefer to stick with a permissive license. I've no problem with a permissive license, I will just stick with the ISC / same header as the rest of brcmfmac for consistency. Regards, Hans p.s. Any chance you could do a patch-review of this series?
Hi, On 10-10-18 09:57, Kalle Valo wrote: > Arend van Spriel <arend.vanspriel@broadcom.com> writes: > >> On 10/10/2018 9:28 AM, Hans de Goede wrote: >>> So how do you want to proceed with this, do you want me to just >>> put the full ISC text in the header for now as the rest of brcmfmac >>> does? >> >> This is not entirely true as far as I know. I assume you are referring >> to this: >> >> /* >> * Copyright (c) 2010 Broadcom Corporation >> * >> * Permission to use, copy, modify, and/or distribute this software for any >> * purpose with or without fee is hereby granted, provided that the above >> * copyright notice and this permission notice appear in all copies. >> * >> * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES >> * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF >> * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE >> FOR ANY >> * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES >> * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN >> AN ACTION >> * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN >> * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >> */ >> >> As far as I recall we opted for BSD license and ISC is equivalent. > > Oh, sorry for missing that. > >> However, The BSD license are already in place so why not use that. I >> would say BSD-2-Clause should cover it. As this is a new file I guess >> it is up to you although I would prefer to stick with a permissive >> license. > > From maintainer's point of view I very much prefer that a driver uses > the same license in all files. It's very confusing if the license > changes within different files. Ack, I will just copy over the header from other brcmfmac files for v2 of the series. Which FWIW is a 1:1 copy of: https://spdx.org/licenses/ISC (I checked before setting the SPDX tag) Regards, Hans
On 10/10/2018 9:59 AM, Hans de Goede wrote: > Hi Arend, > > On 10-10-18 09:52, Arend van Spriel wrote: >> On 10/10/2018 9:28 AM, Hans de Goede wrote: >>> So how do you want to proceed with this, do you want me to just >>> put the full ISC text in the header for now as the rest of brcmfmac >>> does? >> >> This is not entirely true as far as I know. I assume you are referring >> to this: >> >> /* >> * Copyright (c) 2010 Broadcom Corporation >> * >> * Permission to use, copy, modify, and/or distribute this software >> for any >> * purpose with or without fee is hereby granted, provided that the >> above >> * copyright notice and this permission notice appear in all copies. >> * >> * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL >> WARRANTIES >> * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF >> * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE >> LIABLE FOR ANY >> * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES >> * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN >> AN ACTION >> * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF >> OR IN >> * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >> */ >> >> As far as I recall we opted for BSD license and ISC is equivalent. > > I believe it is the other way around, you opted for the ISC license > which is more or less equivalent to the 2 clause BSD, see: > > https://spdx.org/licenses/BSD-2-Clause.html > https://spdx.org/licenses/ISC > > The ISC text is a 1:1 match to the license used in brcmfmac, and it seems > sensible to me to be consistent and use the same license for all > brcmfmac files even if the 2 are more or less equivalent. Looking at the ISC text you are probably right. My recollection was from a verbal notification and the person telling probably was mistaken. So I am fine with a follow-up patch to change all files to use ISC SPDX tag once the ISC license is listed under LICENSES. > > Hans > > p.s. > > Any chance you could do a patch-review of this series? Yup and test for regressions with some of the chipsets I have here. Regards, Arend
Hi, On 10-10-18 10:15, Arend van Spriel wrote: > On 10/10/2018 9:59 AM, Hans de Goede wrote: >> Any chance you could do a patch-review of this series? > > Yup and test for regressions with some of the chipsets I have here. Have you gotten around to review and testing this series yet? it would be nice to get this upstream. Also a review of the 2 patch series starting with: "brcmfmac: Add support for getting nvram contents from EFI variables" would be appreciated. Regards, Hans
On 10/9/2018 2:47 PM, Hans de Goede wrote: > For x86 based machines, set the board_type used for nvram file selection > based on the DMI sys-vendor and product-name strings. > > Since on some models these strings are too generic, this commit also adds > a quirk table overriding the strings for models listed in that table. > > The board_type setting is used to load the board-specific nvram file with > a board-specific name so that we can ship files for each supported board > in linux-firmware. some comments below.... Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > .../broadcom/brcm80211/brcmfmac/Makefile | 2 + > .../broadcom/brcm80211/brcmfmac/common.c | 3 +- > .../broadcom/brcm80211/brcmfmac/common.h | 7 ++ > .../broadcom/brcm80211/brcmfmac/dmi.c | 104 ++++++++++++++++++ > 4 files changed, 115 insertions(+), 1 deletion(-) > create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile > index 1f5a9b948abf..22fd95a736a8 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile > @@ -54,3 +54,5 @@ brcmfmac-$(CONFIG_BRCM_TRACING) += \ > tracepoint.o > brcmfmac-$(CONFIG_OF) += \ > of.o > +brcmfmac-$(CONFIG_DMI) += \ > + dmi.o Assuming OF and DMI are mutual exclusive, right? > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c > new file mode 100644 > index 000000000000..fadc0ec745b8 > --- /dev/null > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c [...] > +static const struct dmi_system_id dmi_platform_data[] = { maybe call this dmi_platform_quirk as in brcmf_dmi_probe() you call this a "quirk table".
Hi, On 05-11-18 12:41, Arend van Spriel wrote: > On 10/9/2018 2:47 PM, Hans de Goede wrote: >> For x86 based machines, set the board_type used for nvram file selection >> based on the DMI sys-vendor and product-name strings. >> >> Since on some models these strings are too generic, this commit also adds >> a quirk table overriding the strings for models listed in that table. >> >> The board_type setting is used to load the board-specific nvram file with >> a board-specific name so that we can ship files for each supported board >> in linux-firmware. > > some comments below.... > > Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> .../broadcom/brcm80211/brcmfmac/Makefile | 2 + >> .../broadcom/brcm80211/brcmfmac/common.c | 3 +- >> .../broadcom/brcm80211/brcmfmac/common.h | 7 ++ >> .../broadcom/brcm80211/brcmfmac/dmi.c | 104 ++++++++++++++++++ >> 4 files changed, 115 insertions(+), 1 deletion(-) >> create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c >> >> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile >> index 1f5a9b948abf..22fd95a736a8 100644 >> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile >> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile >> @@ -54,3 +54,5 @@ brcmfmac-$(CONFIG_BRCM_TRACING) += \ >> tracepoint.o >> brcmfmac-$(CONFIG_OF) += \ >> of.o >> +brcmfmac-$(CONFIG_DMI) += \ >> + dmi.o > > Assuming OF and DMI are mutual exclusive, right? Not necessarily ACPI tables can embed of/devicetree data now, so an x86 machine could have of-data, but having both compiled in is not an issue I would expect only one of them to actually be present (so either of-data or an entry in the DMI platform-data table). >> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c >> new file mode 100644 >> index 000000000000..fadc0ec745b8 >> --- /dev/null >> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c > > [...] > >> +static const struct dmi_system_id dmi_platform_data[] = { > > maybe call this dmi_platform_quirk as in brcmf_dmi_probe() you call this a "quirk table". OK, will fix for v3. I will also switch back to the SPDX license header for v3, since the ISC license text is now in Linus' tree. Regards, Hans
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile index 1f5a9b948abf..22fd95a736a8 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile @@ -54,3 +54,5 @@ brcmfmac-$(CONFIG_BRCM_TRACING) += \ tracepoint.o brcmfmac-$(CONFIG_OF) += \ of.o +brcmfmac-$(CONFIG_DMI) += \ + dmi.o diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c index cd3651069d0c..a4bcbd1a57ac 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c @@ -450,8 +450,9 @@ struct brcmf_mp_device *brcmf_get_module_param(struct device *dev, } } if (!found) { - /* No platform data for this device, try OF (Open Firwmare) */ + /* No platform data for this device, try OF and DMI data */ brcmf_of_probe(dev, bus_type, settings); + brcmf_dmi_probe(settings, chip, chiprev); } return settings; } diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h index e63a273642e9..4ce56be90b74 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h @@ -75,4 +75,11 @@ void brcmf_release_module_param(struct brcmf_mp_device *module_param); /* Sets dongle media info (drv_version, mac address). */ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp); +#ifdef CONFIG_DMI +void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev); +#else +static inline void +brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev) {} +#endif + #endif /* BRCMFMAC_COMMON_H */ diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c new file mode 100644 index 000000000000..fadc0ec745b8 --- /dev/null +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c @@ -0,0 +1,104 @@ +// SPDX-License-Identifier: ISC +/* + * Copyright 2018 Hans de Goede <hdegoede@redhat.com> + */ +#include <linux/dmi.h> +#include <linux/mod_devicetable.h> +#include "core.h" +#include "common.h" +#include "brcm_hw_ids.h" + +/* The DMI data never changes so we can use a static buf for this */ +static char dmi_board_type[128]; + +struct brcmf_dmi_data { + u32 chip; + u32 chiprev; + const char *board_type; +}; + +/* NOTE: Please keep all entries sorted alphabetically */ + +static const struct brcmf_dmi_data gpd_win_pocket_data = { + BRCM_CC_4356_CHIP_ID, 2, "gpd-win-pocket" +}; + +static const struct brcmf_dmi_data jumper_ezpad_mini3_data = { + BRCM_CC_43430_CHIP_ID, 0, "jumper-ezpad-mini3" +}; + +static const struct brcmf_dmi_data meegopad_t08_data = { + BRCM_CC_43340_CHIP_ID, 2, "meegopad-t08" +}; + +static const struct dmi_system_id dmi_platform_data[] = { + { + /* Match for the GPDwin which unfortunately uses somewhat + * generic dmi strings, which is why we test for 4 strings. + * Comparing against 23 other byt/cht boards, board_vendor + * and board_name are unique to the GPDwin, where as only one + * other board has the same board_serial and 3 others have + * the same default product_name. Also the GPDwin is the + * only device to have both board_ and product_name not set. + */ + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), + DMI_MATCH(DMI_BOARD_NAME, "Default string"), + DMI_MATCH(DMI_BOARD_SERIAL, "Default string"), + DMI_MATCH(DMI_PRODUCT_NAME, "Default string"), + }, + .driver_data = (void *)&gpd_win_pocket_data, + }, + { + /* Jumper EZpad mini3 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Insyde"), + DMI_MATCH(DMI_PRODUCT_NAME, "CherryTrail"), + /* jumperx.T87.KFBNEEA02 with the version-nr dropped */ + DMI_MATCH(DMI_BIOS_VERSION, "jumperx.T87.KFBNEEA"), + }, + .driver_data = (void *)&jumper_ezpad_mini3_data, + }, + { + /* Meegopad T08 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Default string"), + DMI_MATCH(DMI_PRODUCT_NAME, "Default string"), + DMI_MATCH(DMI_BOARD_NAME, "T3 MRD"), + DMI_MATCH(DMI_BOARD_VERSION, "V1.1"), + }, + .driver_data = (void *)&meegopad_t08_data, + }, + {} +}; + +void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev) +{ + const struct dmi_system_id *match; + const struct brcmf_dmi_data *data; + const char *sys_vendor; + const char *product_name; + + /* Some models have DMI strings which are too generic, e.g. + * "Default string", we use a quirk table for these. + */ + for (match = dmi_first_match(dmi_platform_data); + match; + match = dmi_first_match(match + 1)) { + data = match->driver_data; + + if (data->chip == chip && data->chiprev == chiprev) { + settings->board_type = data->board_type; + return; + } + } + + /* Not found in the quirk-table, use sys_vendor-product_name */ + sys_vendor = dmi_get_system_info(DMI_SYS_VENDOR); + product_name = dmi_get_system_info(DMI_PRODUCT_NAME); + if (sys_vendor && product_name) { + snprintf(dmi_board_type, sizeof(dmi_board_type), "%s-%s", + sys_vendor, product_name); + settings->board_type = dmi_board_type; + } +}
For x86 based machines, set the board_type used for nvram file selection based on the DMI sys-vendor and product-name strings. Since on some models these strings are too generic, this commit also adds a quirk table overriding the strings for models listed in that table. The board_type setting is used to load the board-specific nvram file with a board-specific name so that we can ship files for each supported board in linux-firmware. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- .../broadcom/brcm80211/brcmfmac/Makefile | 2 + .../broadcom/brcm80211/brcmfmac/common.c | 3 +- .../broadcom/brcm80211/brcmfmac/common.h | 7 ++ .../broadcom/brcm80211/brcmfmac/dmi.c | 104 ++++++++++++++++++ 4 files changed, 115 insertions(+), 1 deletion(-) create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c