On Thu, Apr 06, 2017 at 02:40:09PM +0530, ps.harsha@xxxxxxxxxxxxxxxxxx wrote: > We are working on a platform which will not support RFKILL functionality. > So we tried to disable RFKILL in wpa_supplicant. Disabling NEED_RFKILL > config option in drivers.mak and drivers.mk was not disabling the > complete RFKILL functionality in wpa_supplicant. So provided an option > (CONFIG_RFKILL) in defconfig to enable and disable rfkill functionality in > wpa_supplicant. CONFIG_RFKILL macro is used to protect RFKILL part of code > in wpa_supplicant. > > RFKILL functionality disable option is required in the case > where execution platform doesnot support RFKILL functionality. Why would this be needed? Surely the implementation needs to be fixed to work on a platform that does not support rfkill by default, if there really is an issue there. Please share a debug log showing such a problem. I don't really like the part about disabling rfkill support by default which is what this patch is really doing even though the defconfig change claims that it has "default is y". This gets disabled whenever someone were to update wpa_supplicant without updating wpa_supplicant/.config. To make this somewhat more acceptable (e.g., with the justification being reduced code size), a truly enabled-by-default parameter should be used (e.g., CONFIG_NO_RFKILL=y being used to remove rfkill functionality). That said, I would still like to understand what exactly causes a noticeable issue with the current rfkill implementation on a platform that does not support rfkill. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
