On Sun, May 07, 2023 at 09:34:10PM +0200, Felix Fietkau wrote: > On 07.05.23 15:00, Gokul Sivakumar wrote: > > On Fri, Apr 28, 2023 at 02:46:53PM +0200, Felix Fietkau wrote: > > > On 25.04.23 18:02, Gokul Sivakumar wrote: > > > > Use a new Vendor header file to maintain Infineon specific vendor subcmds, > > > > attributes and events. And the vendor subcmds and event NL80211 messages > > > > are nested under NL80211_CMD_VENDOR with IFX OUI. > > > > > > > > IFX OUI: 00:03:19 (Refer "Infineon AG" in https://standards-oui.ieee.org/) > > > > > > > > And introduce a new build flag CONFIG_DRIVER_NL80211_IFX for Infineon WiFi. > > > > > > > > Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@xxxxxxxxxxxx> > > > What's the reason for putting all of this into vendor/driver specific > > > hackery instead of adding proper upstream nl80211 APIs? > > > > > > - Felix > > > > The subcmds listed here in this new vendor NL80211 header file are used for > > triggering a vendor specific configurations/implementations in the WLAN > > driver/firmware layers for the Infineon chips which wouldn't be suitable > > to add into the standard NL80211 header. > > > > For Example, "IFX_VENDOR_SCMD_FRAMEBURST" is a proprietary feature which is > > supported by the Infineon vendor hardware & software. > > I agree that it makes sense to use vendor specific code for proprietary > features. It just seems to me that for some of the things in there it > would make more sense to extend the upstream API instead of polluting > hostapd with vendor specific hacks. > Understood the concern here. Will shortly send an updated v3 patchset after removing some of the newly introduced generic IFX vendor specific NL80211 API from the v2 patchset, which could be potentially supported later by extending the standard NL80211 API. - Gokul _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
