Re: [PATCH -next 1/2] i2c: designware: Switch from using MMIO access to SMN access

[Andy Shevchenko]

On Wed, Sep 21, 2022 at 10:50:53PM +0200, Borislav Petkov wrote:
> On Wed, Sep 21, 2022 at 03:19:26PM -0500, Limonciello, Mario wrote:
> > Jan mentioned this in the commit message:
> > 
> > > The function which registers i2c-designware-platdrv is a
> > > subsys_initcall that is executed before fs_initcall (when enumeration > of
> > NB descriptors occurs).
> > 
> > So if it's not exported again, then it means that we somehow
> > need to get i2c-designware-platdrv to register earlier too.
> 
> So I have this there:
> 
> /* This has to go after the PCI subsystem */
> fs_initcall(init_amd_nbs);
> 
> as I need PCI. It itself does
> 
> arch_initcall(pci_arch_init);
> 
> so I guess init_amd_nbs() could be a subsys_initcall...
> 
> Or why is
> 
> subsys_initcall(dw_i2c_init_driver);
> 
> a subsys initcall in the first place?
> 
> Looking at
> 
>   104522806a7d ("i2c: designware: dw_i2c_init_driver as subsys initcall")
> 
> I don't see a particular reason why it should be a subsys_initcall...
> 
> In any case, this should be fixed without an export which was crap in
> the first place.
> 
> Hm.

I'm speculating here, but IIRC the I2C controllers may serve PMICs on some
platform that are required to be present earlier due to some ACPI code
accessing them. This Hans de Goede can confirm or correct me.

Another case comes to my mind is that I2C framework wants to initialize I2C
peripherals which were supplied via struct i2c_board_info on earlier stages.
And again comes to the specifics of the certain peripherals that needs for
power / reset / etc control, i.o.w. critical hardware for the platforms.

But it's still what I remember and I can be mistaken.

-- 
With Best Regards,
Andy Shevchenko