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

[Grygorii Strashko]

Hi Arnd,

On 11/05/2020 15:43, Arnd Bergmann wrote:
> On Mon, May 11, 2020 at 1:11 PM Grygorii Strashko
> <grygorii.strashko@xxxxxx> 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@xxxxxx> 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