On 05/09/2023 09:13, wangweidong.a@awinic.com wrote:
Thank you very much for your reply.
On 05/09/2023 15:05, krzysztof.kozlowski@linaro.org wrote:
On 05/09/2023 04:46, wangweidong.a@awinic.com wrote:
Even though it does not look like from the diff, the property is not actually used by the driver, because once set, it is read only in loops depending on ddt_num (prof_hdr->ddt_num, cfg_hdr->ddt_num). The variable ddt_num is never set and is always 0, so the loops do not have any iteration. Dropping sound-channel and ddt_num-related loops allows to drop empty functions which in turn drop quite a lot of code. This entire code was not possible to execute.
The ddt_num variable is not always 0, this variable is defined in the configuration file. The "prof_hdr" variable is assigned by the "cfg_hdr" variable. The "cfg_hdr" variable is assigned by "aw_cfg" aw_cfg is the data obtained through request_firmware.The specific process is as follows:
request_firmware ---> cont->data ---> aw_cfg->data --> cfg_hdr --> prof_hdr
Hm. So you load user-space provided file and assign it directly, without any validation (aw88395_dev_load_acf_check() checks only for magic), to a kernel structure. Sounds bullet-proof. Why using known kernel interfaces, better to implement some conf-file-parsing.
Could you please tell me what known kernel interfaces can be used to parse files?
With exception of Audio topology and FDT, I do not think we parse user-provided files in Linux kernel.
Best regards, Krzysztof