+Cc: Peter to look from the i2c mux point of view on the issue. On Tue, Sep 05, 2023 at 02:43:19PM +0300, Tomas Melin wrote: > On 04/09/2023 16:12, Jonathan Cameron wrote: > > On Mon, 4 Sep 2023 14:23:29 +0300 > > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > >> On Mon, Sep 04, 2023 at 01:15:22PM +0300, Tomas Melin wrote: > >>> Support deferred probe for cases where communication on > >>> i2c bus fails. These failures could happen for a variety of > >>> reasons including bus arbitration error or power failure. ... > >>> +out: > >>> + if ((ret == -EAGAIN) || (ret == -ENXIO)) > >>> + return -EPROBE_DEFER; > >>> + return ret; > >> > >> Oh my... This looks so-o hackish. > > > > Agreed. This is a non starter. > > > >> If anything, it has to be fixed on the level of regmap I2C APIs or so. > >> > >> Maybe something like regmap_i2c_try_write()/try_read() new APIs that > >> will provide the above. Otherwise you want to fix _every single driver_ > >> in the Linux kernel > > > > Any probe ordering dependencies should be described by the > > firmware and the driver should 'get' the relevant resource. > > If there is anything not describable today then that is what we need > > to fix, not paper over the holes > > > > So can we have specifics of what is happening here? > > > > If it's arbitration with some other entity then fix the arbitration > > locking / hand over. If it's power, then make sure the relevant > > regulator get gotten and turned on + has the right delays etc. > > Yes, right. In this use case, the ads1015 is connected to a channel of > a i2c multiplexer. When the mux is probed, it also enumerates all the > multiplexed buses and probes devices connected to them. > For some reason, it behaves so that the ads1015 is not detected on the > first attempt. Since it's a mux, connected to main i2c line, perhaps > there really is some bus arbitration issue, or then something else. > > Anyways, when deferring the probe for the ads1015, and attempting later > again it probes fine. > > So, it might be I've taken the wrong angle at this issue, but > it does solve the issue at hand. Obviously, there could be some issue > with the i2c mux driver, or then on hardware level too. > > Point is, that if the communication to the i2c bus has some temporary > error like EAGAIN, why could it not be reasonable to try again at a > later time instead of giving up completely. -- With Best Regards, Andy Shevchenko
