Re: [PATCH v3 2/2] soc: ti: add k3 platforms chipid module driver

[Grygorii Strashko <grygorii.strashko@ti.com>]

Hi Arnd,

On 11/05/2020 15:43, Arnd Bergmann wrote:
> On Mon, May 11, 2020 at 1:11 PM Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>>
>> Hi Arnd,
>>
>> On 09/05/2020 01:17, Arnd Bergmann wrote:
>>> On Fri, May 8, 2020 at 12:01 PM Grygorii Strashko
>>> <grygorii.strashko@ti.com> wrote:
>>>
>>>> +static int __init k3_chipinfo_init(void)
>>>> +{
>>>> +       struct soc_device_attribute *soc_dev_attr;
>>>> +       struct soc_device *soc_dev;
>>>> +       struct device_node *node;
>>>> +       struct regmap *regmap;
>>>> +       u32 partno_id;
>>>> +       u32 variant;
>>>> +       u32 jtag_id;
>>>> +       u32 mfg;
>>>> +       int ret;
>>>> +
>>>> +       node = of_find_compatible_node(NULL, NULL, "ti,am654-chipid");
>>>> +       if (!node)
>>>> +               return -ENODEV;
>>>
>>> This will fail the initcall and print a warning when the kernel runs on any
>>> other SoC. Would it be possible to just make this a platform_driver?
>>>
>>> If not, I think you should silently return success when the device
>>> node is absent.
>>
>> Thank you for your report.
>> Can' make it platform drv., as the SoC info need to be accessible by divers early.
> 
> Which drivers in particular? In most cases you should be able to still do this
> right by relying on initcall ordering as long as this one can only be built-in
> (or possibly only a module for compile-testing).

Thanks for you review.

As I'm aware of right now, it's going to be: ringacc, dma, net drv and mmc.
So, It seems should work with platform_driver and subsys_initcall.
I'll try it.

-- 
Best regards,
grygorii