Arend Van Spriel <aspriel@xxxxxxxxx> writes: > On 7/29/2022 11:32 AM, Arend Van Spriel wrote: >> On 7/28/2022 11:36 AM, Kalle Valo wrote: >>> aspriel@xxxxxxxxx writes: >>> >>>> The driver is being used by multiple vendors who develop the firmware >>>> api independently. So far the firmware api as used by the driver has >>>> not diverged (yet). This change adds framework for supporting multiple >>>> firmware apis. The vendor-specific support code has to provide a number >>>> of callback operations. Right now it is only attach and detach callbacks >>>> so no real functionality as the api is still common. This code only >>>> adds WCC variant anyway, which is selected for all devices right now. >>>> >>>> Reviewed-by: Hante Meuleman <hante.meuleman@xxxxxxxxxxxx> >>>> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@xxxxxxxxxxxx> >>>> Reviewed-by: Franky Lin <franky.lin@xxxxxxxxxxxx> >>>> Signed-off-by: Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> >>> >>> [...] >>> >>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig >>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig >>>> @@ -8,6 +8,22 @@ config BRCMFMAC >>>> . . . . . . . interface support. If you choose to build a module, it'll be >>>> called >>>> . . . . . . . brcmfmac.ko. >>>> >>>> +config BRCMFMAC_VENDOR_MODULES >>>> +. . . bool "Use vendor-specific modules" >>>> +. . . depends on BRCMFMAC = m >>>> +. . . help >>>> +. . . . . This option will build separate modules for the vendor-specific >>>> +. . . . . firmware support. If not selected the vendor-specific support >>>> +. . . . . will be build in brcmfmac.ko. >>>> + >>>> +config BRCMFMAC_VENDOR_WCC >>>> +. . . bool "Broadcom WCC" >>>> +. . . default y >>>> +. . . depends on BRCMFMAC >>>> +. . . . . . . help >>>> +. . . . . . . . . This option will allow the driver to communicate with devices >>>> +. . . . . . . . . shipped by Broadcom WCC division. >>>> + >>> >>> I'm not really a fan of these Kconfig options, I would rather have them >>> always enabled. Why do we need these options, what would be the use case >>> when user disables these? >> >> I assume with "always enabled" you mean "drop these options". Yes, I meant dropping the options altogether. >> Obviously I would prefer to keep them. The default will result in a >> single module with all vendor support built-in, but this allows >> people to trim down their configuration based on what they have. So >> the choices are: >> >> 1) single module with all vendor support built-in >> 2) single module with partial vendor support built-in (as needed) >> >> . . allows users to select vendor for their specific device not carrying >> . . stuff they don't need. If they have a Cypress/Infineon device they >> . . only need support for that. >> >> 3) separate vendor support modules loaded as needed during device probe >> >> . . build all (or some) vendor support modules and they are loaded into >> . . memory only when they are needed for the device detected. > > I wanted to give this series another try, but the conversation above > never came to any conclusion/consensus. Maybe good to finish this before > resending? Sorry, I was supposed to answer but it got piled up with other unanswered emails. So why I'm hesitant about these options is that Linus has multiple times critised of adding unnecessary Kconfig options, and I agree with him. Kconfig is quite a mess already and we need to be careful when adding new options. It's being a long time since I looked these patches so take this with grain of salt, but is the memory savings from this really so significant? From my point of view a faster way to get these to upstream is to submit them without Kconfig options first. The options can be added later if there's still strong need for them, and it's also easier to show numbers to back it up. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
