On 02/27/2018 10:07 PM, Vladimir Zapolskiy wrote:
> On 02/27/2018 09:39 PM, Kim Phillips wrote:
>> On Tue, 27 Feb 2018 18:53:08 +0200
>> Vladimir Zapolskiy <vz@xxxxxxxxx> wrote:
>>
>>> On 02/27/2018 05:49 PM, Kim Phillips wrote:
>>>> On Mon, 26 Feb 2018 20:38:49 +0200
>>>> Vladimir Zapolskiy <vz@xxxxxxxxx> wrote:
>>>>
>>>>> +#ifdef CONFIG_OF
>>>>> +static const struct of_device_id mxc_rnga_of_match[] = {
>>>>> + { .compatible = "fsl,imx31-rnga", },
>>>>> + { /* sentinel */ },
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(of, mxc_rnga_of_match);
>>>>> +#endif
>>>>> +
>>>>> static struct platform_driver mxc_rnga_driver = {
>>>>> .driver = {
>>>>> - .name = "mxc_rnga",
>>>>> - },
>>>>> + .name = "mxc_rnga",
>>>>> + .of_match_table = of_match_ptr(mxc_rnga_of_match),
>>>>
>>>> Does this build if CONFIG_OF is not set?
>>>
>>> Definitely it is expected to be built, you can verify it directly or
>>> check of_match_ptr() macro definition from include/linux/of.h
>>
>> Thanks, I verified it by removing the SOC_IMX31 dependency, and with
>> netwinder_defconfig as a base. I also verified that the #ifdef
>> CONFIG_OF protecting the mxc_rnga_of_match definition is also not
>> needed.
>
> That's a commonplace observation, but I have serious doubts, if it
> has become a common practice to remove CONFIG_OF and CONFIG_ACPI
> macro guards around device id lists. Still I would prefer to save
> compiled code size.
>
I checked that all flavours of i.MX SoCs are under multiplatform build.
FWIW only 1 iMX31 board has DT support and 10 of them use platform
data, and I'd like to change the ratio. So it would be proper to
remove the set CONFIG_OF guard.
But what is significantly more important is that i.MX31 RNGA should
be defined as compatible with i.MX21 RNGA, and it obligates me to send
v2 with the corrected compatible name, I'll make both changes.
Thanks Kim for attracting my attention to possible improvements.
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
