test0r
64eae76f4e
Following the conversion of the factory-calibration READ path to request_firmware() (earlier in this series), the factory-calibration WRITE path in factory_section_write_file() was still using filp_open(O_CREAT | O_TRUNC | O_RDWR) + kernel_write() to persist updated calibration data back to FACTORY_PATH (default /lib/firmware/bes2600/bes2600_factory.txt). Writing to files under /lib/firmware/ from kernel code is a standing upstream blocker for staging and for drivers/net/wireless/ submission generally: - filp_open()/kernel_write() bypass the firmware-class abstraction, the LSM framework, and user/group/mode enforcement that governs the firmware search paths. They have been repeatedly called out in staging-prep reviews. - The kernel runs with capabilities that userspace does not (CAP_ DAC_OVERRIDE effectively); quietly rewriting firmware blobs that userspace owns is a surprise contract. - A module unload / reboot immediately after the write races the writeback and can leave a truncated calibration file on disk. Remove factory_section_write_file() and its two call sites in bes2600_wifi_cali_table_save(). The in-memory factory_save_p remains authoritative for the duration of the session: the WSM command handlers that triggered this path (power-cali-table, freq-cali, efuse-flag, power-cali-flag) already update the live struct factory_t, and reads served from file_buffer pick up the rebuilt serialised form immediately. On the next probe the firmware-class file is re-read read-only via request_firmware(), as set up by the earlier patch. If cross-reboot persistence of runtime-updated calibration becomes a requirement, the expected route is a userspace-visible dump interface -- a read-only debugfs file exporting the serialised blob, or an nl80211 vendor command -- that lets userspace copy the values to a chosen location under its own privileges. Such a facility can land as a follow-up without touching the core driver write path again. Signed-off-by: Markus Fritsche <fritsche.markus@gmail.com>