On 26/03/2022 08:55, ChiYuan Huang wrote: > Mark Brown <broonie@xxxxxxxxxx> 於 2022年3月26日 週六 上午9:07寫道： >> >> On Sat, Mar 26, 2022 at 08:58:47AM +0800, ChiYuan Huang wrote: >> >>> I tried to remove only __maybe_unused and build with x86 config that >>> CONFIG_OF=n. >>> There's no warning or error message when compiling the rt5759 source code. >> >>> If so, I will remove only '__maybe_unused'. >>> May I ask whether 'of_match_ptr' need to be added or not? >> >> If you add of_match_ptr() (which is a little better, though it's >> a tiny different either way) then you shouldn't remove >> __maybe_unused - the thing here is that the __maybe_unused is >> needed because of_match_ptr() is used. > > Sorry, I'm confused. > Originally, Krzysztof's opinion is to tell me why 'of_device_id' is > declared as '__maybe_unused'. > That's why I mentioned that the return value about of_device_get_match_data' Your answer is not related to my question. of_device_get_match_data() has nothing to do with __maybe_unused... > And now we're talking about to add 'of_match_ptr' in struct driver > of_match_table. Because this is one of the solutions. > > Back to the original topic, two ways can solve this. > 1) only remove '__maybe_unused' in of_device_id > 2) keep '__maybe_unused' in of_device_id, and add of_match_ptr for > of_match_table. > But option 2 seems conflict with Krzysztof's gueestion. > > May I ask which option you suggested? Option two does not conflict my suggestion. I pointed out that having ONLY maybe_unused is incorrect. I pointed the mistake. Nothing more... I said that there are two ways to solve it later, just choose one. I don't know why do we talk about such basic issue for so long. This should be one email from my side and one confirmation from you... Obviously maybe_unused it has to be removed if you do not add of_match_ptr. But if you intend to add of_match_ptr, then things change... Just for the record of choosing between options (which I also mentioned that there are two solutions) - having no of_match_ptr allows to match with ACPI PRP0001 (AFAIU also when !OF). Best regards, Krzysztof
