On Mon, 24 Oct 2022 14:40:20 +0300 Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > On Mon, Oct 24, 2022 at 12:22:19PM +0200, Nuno Sá wrote: > > On Mon, 2022-10-24 at 12:46 +0300, Andy Shevchenko wrote: > > > On Mon, Oct 24, 2022 at 11:14:56AM +0200, Uwe Kleine-König wrote: > > ... > > > > > There is no win in postponing, is there?[1] What would be your > > > > preferred > > > > way to rework? > > > > > > My understand of the probe_new is that an attempt to unify i2c with > > > how spi > > > does. So, why not teach i2c_match_id() to handle this nicely for the > > > caller? > > > > > > This will allow to leave tables where they are (or move closer to > > > struct > > > driver), reduce churn with the using of current i2c_match_id() as you > > > showed the long line to get that table. This might need a new API to > > > avoid > > > changing many drivers at once. But it's business as usual. > > > > I guess something like spi_get_device_id() > > Right, that one I have had in mind when responding. > Agreed an i2c_client_get_device_id() seems like a good addition to me. Jonathan
