The struct i2c_board_info has of_node and fwnode members. This is
quite confusing as they are of the same semantics and it's tend
to have an issue if user assigns both. Luckily there is only a
single driver that does this and fix was sent today. Nevertheless
the series moves the client handling code to use fwnode and deprecates
the of_node member in the respective documentation.

Tomi, can you test this series + the patch we discussed earlier so it works as
expected?

In v2:
- covered i2c-core-slave.c where it makes sense
- covered i2c-core-of.c where it makes sense
- rebased on top of the latest code base

Andy Shevchenko (6):
  i2c: core: Drop duplicate check before calling OF APIs
  i2c: core: Unify the firmware node type check
  i2c: core: Switch to fwnode APIs to get IRQ
  i2c: core: Reuse fwnode variable where it makes sense
  i2c: core: Do not dereference fwnode in struct device
  i2c: core: Deprecate of_node in struct i2c_board_info

 drivers/i2c/i2c-core-base.c  | 59 ++++++++++++++++++------------------
 drivers/i2c/i2c-core-of.c    |  1 -
 drivers/i2c/i2c-core-slave.c | 11 ++++---
 include/linux/i2c.h          |  2 +-
 4 files changed, 37 insertions(+), 36 deletions(-)

-- 
2.47.2

Hi Andy,

On 07/04/2025 12:55, Andy Shevchenko wrote:
> The struct i2c_board_info has of_node and fwnode members. This is
> quite confusing as they are of the same semantics and it's tend
> to have an issue if user assigns both. Luckily there is only a
> single driver that does this and fix was sent today. Nevertheless
> the series moves the client handling code to use fwnode and deprecates
> the of_node member in the respective documentation.
> 
> Tomi, can you test this series + the patch we discussed earlier so it works as
> expected?

I tested this series, and then tested this series + "[PATCH v1 1/1] 
media: i2c: ds90ub960: Remove of_node assignment". I didn't see anything 
amiss in either case.

Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

I assume the ds90ub960 patch is the "single driver that does this and 
fix was sent today"? If so, I think that patch could have been included 
in this series as well, there's hardly a chance of conflicts with the 
one liner. And if applied separately, we probably need to apply the 
ub960 patch one kernel version later than this series.

  Tomi

> 
> In v2:
> - covered i2c-core-slave.c where it makes sense
> - covered i2c-core-of.c where it makes sense
> - rebased on top of the latest code base
> 
> Andy Shevchenko (6):
>    i2c: core: Drop duplicate check before calling OF APIs
>    i2c: core: Unify the firmware node type check
>    i2c: core: Switch to fwnode APIs to get IRQ
>    i2c: core: Reuse fwnode variable where it makes sense
>    i2c: core: Do not dereference fwnode in struct device
>    i2c: core: Deprecate of_node in struct i2c_board_info
> 
>   drivers/i2c/i2c-core-base.c  | 59 ++++++++++++++++++------------------
>   drivers/i2c/i2c-core-of.c    |  1 -
>   drivers/i2c/i2c-core-slave.c | 11 ++++---
>   include/linux/i2c.h          |  2 +-
>   4 files changed, 37 insertions(+), 36 deletions(-)
>

On Mon, Apr 07, 2025 at 02:34:48PM +0300, Tomi Valkeinen wrote:
> On 07/04/2025 12:55, Andy Shevchenko wrote:
> > The struct i2c_board_info has of_node and fwnode members. This is
> > quite confusing as they are of the same semantics and it's tend
> > to have an issue if user assigns both. Luckily there is only a
> > single driver that does this and fix was sent today. Nevertheless
> > the series moves the client handling code to use fwnode and deprecates
> > the of_node member in the respective documentation.
> > 
> > Tomi, can you test this series + the patch we discussed earlier so it works as
> > expected?
> 
> I tested this series, and then tested this series + "[PATCH v1 1/1] media:
> i2c: ds90ub960: Remove of_node assignment". I didn't see anything amiss in
> either case.
> 
> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

Thank you very much for the testing!

> I assume the ds90ub960 patch is the "single driver that does this and fix
> was sent today"? If so, I think that patch could have been included in this
> series as well, there's hardly a chance of conflicts with the one liner. And
> if applied separately, we probably need to apply the ub960 patch one kernel
> version later than this series.

Yeah, I forgot to update the cover letter to point to that one out.
I agree on everything you said above. But let's wait a bit for Wolfram
to comment on / apply this first. It would be nice to have it in, so
we prevent new ambiguous users from appearing.

-- 
With Best Regards,
Andy Shevchenko