mbox series

[RFC,0/2] Extend device_get_match_data() to struct bus_type

Message ID 20230723083721.35384-1-biju.das.jz@bp.renesas.com
Headers show
Series Extend device_get_match_data() to struct bus_type | expand

Message

Biju Das July 23, 2023, 8:37 a.m. UTC
This patch series extend device_get_match_data() to struct bus_type,
so that buses like I2C can get matched data.

Biju Das (2):
  drivers: fwnode: Extend device_get_match_data() to struct bus_type
  i2c: Add i2c_device_get_match_data() callback

 drivers/base/property.c     |  8 +++++++-
 drivers/i2c/i2c-core-base.c | 38 +++++++++++++++++++++++++++++--------
 include/linux/device/bus.h  |  3 +++
 3 files changed, 40 insertions(+), 9 deletions(-)

Comments

Andy Shevchenko July 24, 2023, 11:06 a.m. UTC | #1
On Sun, Jul 23, 2023 at 09:37:20AM +0100, Biju Das wrote:

Thank you for your contribution!
My comments below.

> Extend device_get_match_data() to buses (for eg: I2C) by adding a
> callback device_get_match_data() to struct bus_type() and call this method
> as a fallback for generic fwnode based device_get_match_data().

> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

You can't just throw one's SoB tag without clear understanding what's going on
here (either wrong authorship or missing Co-developed-by or...?).

> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>

...

>  const void *device_get_match_data(const struct device *dev)
>  {
> -	return fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data, dev);
> +	const void *data;
> +
> +	data = fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data, dev);
> +	if (!data && dev->bus && dev->bus->get_match_data)
> +		data = dev->bus->get_match_data(dev);
> +
> +	return data;

Much better looking is

	data = fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data, dev);
	if (data)
		return data;

	if (dev->bus && dev->bus->get_match_data)
		return dev->bus->get_match_data(dev);

	return NULL;

>  }
Andy Shevchenko July 24, 2023, 11:07 a.m. UTC | #2
On Mon, Jul 24, 2023 at 02:06:07PM +0300, Andy Shevchenko wrote:
> On Sun, Jul 23, 2023 at 09:37:20AM +0100, Biju Das wrote:
> 
> Thank you for your contribution!
> My comments below.
> 
> > Extend device_get_match_data() to buses (for eg: I2C) by adding a
> > callback device_get_match_data() to struct bus_type() and call this method
> > as a fallback for generic fwnode based device_get_match_data().
> 
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> You can't just throw one's SoB tag without clear understanding what's going on
> here (either wrong authorship or missing Co-developed-by or...?).
> 
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>

...

> >  const void *device_get_match_data(const struct device *dev)

Btw, this needs a documentation update to explain how it works now.

> >  {
> > -	return fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data, dev);
> > +	const void *data;
> > +
> > +	data = fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data, dev);
> > +	if (!data && dev->bus && dev->bus->get_match_data)
> > +		data = dev->bus->get_match_data(dev);
> > +
> > +	return data;
> 
> Much better looking is
> 
> 	data = fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data, dev);
> 	if (data)
> 		return data;
> 
> 	if (dev->bus && dev->bus->get_match_data)
> 		return dev->bus->get_match_data(dev);
> 
> 	return NULL;
> 
> >  }
Biju Das July 24, 2023, 11:46 a.m. UTC | #3
Hi Andy,

Thanks for the feedback.

> Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> device_get_match_data() to struct bus_type
> 
> On Mon, Jul 24, 2023 at 02:06:07PM +0300, Andy Shevchenko wrote:
> > On Sun, Jul 23, 2023 at 09:37:20AM +0100, Biju Das wrote:
> >
> > Thank you for your contribution!
> > My comments below.
> >
> > > Extend device_get_match_data() to buses (for eg: I2C) by adding a
> > > callback device_get_match_data() to struct bus_type() and call this
> > > method as a fallback for generic fwnode based
> device_get_match_data().
> >
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >
> > You can't just throw one's SoB tag without clear understanding what's
> > going on here (either wrong authorship or missing Co-developed-by
> or...?).
> >
> > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> 
> ...
> 
> > >  const void *device_get_match_data(const struct device *dev)
> 
> Btw, this needs a documentation update to explain how it works now.

Can you please point me to the location where I need to update?

Cheers,
Biju

> 
> > >  {
> > > -	return fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data,
> dev);
> > > +	const void *data;
> > > +
> > > +	data = fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data,
> dev);
> > > +	if (!data && dev->bus && dev->bus->get_match_data)
> > > +		data = dev->bus->get_match_data(dev);
> > > +
> > > +	return data;
> >
> > Much better looking is
> >
> > 	data = fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data,
> dev);
> > 	if (data)
> > 		return data;
> >
> > 	if (dev->bus && dev->bus->get_match_data)
> > 		return dev->bus->get_match_data(dev);
> >
> > 	return NULL;
> >
> > >  }
> 
> --
> With Best Regards,
> Andy Shevchenko
>
Biju Das July 24, 2023, 12:02 p.m. UTC | #4
Hi Andy Shevchenko,

Thanks for the feedback.

> Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> device_get_match_data() to struct bus_type
> 
> On Sun, Jul 23, 2023 at 09:37:20AM +0100, Biju Das wrote:
> 
> Thank you for your contribution!
> My comments below.
> 
> > Extend device_get_match_data() to buses (for eg: I2C) by adding a
> > callback device_get_match_data() to struct bus_type() and call this
> > method as a fallback for generic fwnode based device_get_match_data().
> 
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> You can't just throw one's SoB tag without clear understanding what's
> going on here (either wrong authorship or missing Co-developed-by
> or...?).

Dmitry feels instead of having separate bus based match_data() like i2c_get_match_data[2] and spi_get_device_match_data[3], it is
better to have a generic approach like a single API device_get_match_data()
for getting match_data for OF/ACPI/I2C/SPI tables.

So, he came with a proposal and shared some code here[1].
Since,I have send this patch, I put my signed -off.

If this patch is accepted, then we can get rid of bus based match_data.

[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20230717131756.240645-2-biju.das.jz@bp.renesas.com/#25436207

[2] https://elixir.bootlin.com/linux/v6.5-rc3/source/drivers/i2c/i2c-core-base.c#L117

[3] https://elixir.bootlin.com/linux/v6.5-rc3/source/drivers/spi/spi.c#L364

Cheers,
Biju


> 
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> 
> ...
> 
> >  const void *device_get_match_data(const struct device *dev)  {
> > -	return fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data,
> dev);
> > +	const void *data;
> > +
> > +	data = fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data,
> dev);
> > +	if (!data && dev->bus && dev->bus->get_match_data)
> > +		data = dev->bus->get_match_data(dev);
> > +
> > +	return data;
> 
> Much better looking is
> 
> 	data = fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data,
> dev);
> 	if (data)
> 		return data;

OK.

Cheers,
Biju

> 
> 	if (dev->bus && dev->bus->get_match_data)
> 		return dev->bus->get_match_data(dev);
> 
> 	return NULL;
> 
> >  }
> 
> --
> With Best Regards,
> Andy Shevchenko
>
Andy Shevchenko July 24, 2023, 12:57 p.m. UTC | #5
On Mon, Jul 24, 2023 at 11:46:44AM +0000, Biju Das wrote:
> > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > device_get_match_data() to struct bus_type
> > On Mon, Jul 24, 2023 at 02:06:07PM +0300, Andy Shevchenko wrote:
> > > On Sun, Jul 23, 2023 at 09:37:20AM +0100, Biju Das wrote:

...

> > > >  const void *device_get_match_data(const struct device *dev)

(1)

> > Btw, this needs a documentation update to explain how it works now.
> 
> Can you please point me to the location where I need to update?

Sure. It's just on top of the (1). It looks like no documentation
yet existed, so you need to create one.

Not sure if fwnode.h has to be updated. At least it doesn't contradict
with the added code, while not describing all details.
Andy Shevchenko July 24, 2023, 1 p.m. UTC | #6
On Mon, Jul 24, 2023 at 12:02:27PM +0000, Biju Das wrote:
> > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > device_get_match_data() to struct bus_type
> > On Sun, Jul 23, 2023 at 09:37:20AM +0100, Biju Das wrote:

...

> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > 
> > You can't just throw one's SoB tag without clear understanding what's
> > going on here (either wrong authorship or missing Co-developed-by
> > or...?).
> 
> Dmitry feels instead of having separate bus based match_data() like
> i2c_get_match_data[2] and spi_get_device_match_data[3], it is better to have
> a generic approach like a single API device_get_match_data() for getting
> match_data for OF/ACPI/I2C/SPI tables.
> 
> So, he came with a proposal and shared some code here[1].

Yes, I'm pretty much following the discussion.

> Since,I have send this patch, I put my signed -off.

I'm not talking about this. There is no evidence that Dmitry gives you
any approval to use or clear SoB tag. Again, you may not do like this.

> If this patch is accepted, then we can get rid of bus based match_data.

This is unrelated to what I talking about.

> [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20230717131756.240645-2-biju.das.jz@bp.renesas.com/#25436207
Biju Das July 24, 2023, 1:19 p.m. UTC | #7
Hi Andy,

Thanks for the feedback.

> Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> device_get_match_data() to struct bus_type
> 
> On Mon, Jul 24, 2023 at 12:02:27PM +0000, Biju Das wrote:
> > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > device_get_match_data() to struct bus_type On Sun, Jul 23, 2023 at
> > > 09:37:20AM +0100, Biju Das wrote:
> 
> ...
> 
> > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > >
> > > You can't just throw one's SoB tag without clear understanding
> > > what's going on here (either wrong authorship or missing
> > > Co-developed-by or...?).
> >
> > Dmitry feels instead of having separate bus based match_data() like
> > i2c_get_match_data[2] and spi_get_device_match_data[3], it is better
> > to have a generic approach like a single API device_get_match_data()
> > for getting match_data for OF/ACPI/I2C/SPI tables.
> >
> > So, he came with a proposal and shared some code here[1].
> 
> Yes, I'm pretty much following the discussion.
> 
> > Since,I have send this patch, I put my signed -off.
> 
> I'm not talking about this. There is no evidence that Dmitry gives you
> any approval to use or clear SoB tag. Again, you may not do like this.

Here Dmitry is acknowledging, he is ok with the patch I posted.

https://patchwork.kernel.org/project/linux-renesas-soc/patch/20230717131756.240645-2-biju.das.jz@bp.renesas.com/#25437032

Cheers,
Biju
Biju Das July 24, 2023, 1:35 p.m. UTC | #8
Hi Andy Shevchenko,

Thanks for the feedback.

> Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> device_get_match_data() to struct bus_type
> 
> On Mon, Jul 24, 2023 at 11:46:44AM +0000, Biju Das wrote:
> > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > device_get_match_data() to struct bus_type On Mon, Jul 24, 2023 at
> > > 02:06:07PM +0300, Andy Shevchenko wrote:
> > > > On Sun, Jul 23, 2023 at 09:37:20AM +0100, Biju Das wrote:
> 
> ...
> 
> > > > >  const void *device_get_match_data(const struct device *dev)
> 
> (1)
> 
> > > Btw, this needs a documentation update to explain how it works now.
> >
> > Can you please point me to the location where I need to update?
> 
> Sure. It's just on top of the (1). It looks like no documentation yet
> existed, so you need to create one.
> 
> Not sure if fwnode.h has to be updated. At least it doesn't contradict
> with the added code, while not describing all details.

OK, will do.

Cheers,
Biju
Andy Shevchenko July 24, 2023, 1:50 p.m. UTC | #9
On Mon, Jul 24, 2023 at 01:19:02PM +0000, Biju Das wrote:
> > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > device_get_match_data() to struct bus_type
> > On Mon, Jul 24, 2023 at 12:02:27PM +0000, Biju Das wrote:
> > > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > > device_get_match_data() to struct bus_type On Sun, Jul 23, 2023 at
> > > > 09:37:20AM +0100, Biju Das wrote:

...

> > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > >
> > > > You can't just throw one's SoB tag without clear understanding
> > > > what's going on here (either wrong authorship or missing
> > > > Co-developed-by or...?).
> > >
> > > Dmitry feels instead of having separate bus based match_data() like
> > > i2c_get_match_data[2] and spi_get_device_match_data[3], it is better
> > > to have a generic approach like a single API device_get_match_data()
> > > for getting match_data for OF/ACPI/I2C/SPI tables.
> > >
> > > So, he came with a proposal and shared some code here[1].
> > 
> > Yes, I'm pretty much following the discussion.
> > 
> > > Since,I have send this patch, I put my signed -off.
> > 
> > I'm not talking about this. There is no evidence that Dmitry gives you
> > any approval to use or clear SoB tag. Again, you may not do like this.
> 
> Here Dmitry is acknowledging, he is ok with the patch I posted.
> 
> https://patchwork.kernel.org/project/linux-renesas-soc/patch/20230717131756.240645-2-biju.das.jz@bp.renesas.com/#25437032

No, you just misinterpreted his message.

See https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
for the explanation. The SoB has to be explicitly given. Dmitry had _not_
put it like this.
Biju Das July 24, 2023, 1:58 p.m. UTC | #10
Hi Andy,

Thanks for the feedback.

> Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> device_get_match_data() to struct bus_type
> 
> On Mon, Jul 24, 2023 at 01:19:02PM +0000, Biju Das wrote:
> > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > device_get_match_data() to struct bus_type On Mon, Jul 24, 2023 at
> > > 12:02:27PM +0000, Biju Das wrote:
> > > > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > > > device_get_match_data() to struct bus_type On Sun, Jul 23, 2023
> > > > > at 09:37:20AM +0100, Biju Das wrote:
> 
> ...
> 
> > > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > >
> > > > > You can't just throw one's SoB tag without clear understanding
> > > > > what's going on here (either wrong authorship or missing
> > > > > Co-developed-by or...?).
> > > >
> > > > Dmitry feels instead of having separate bus based match_data()
> > > > like i2c_get_match_data[2] and spi_get_device_match_data[3], it is
> > > > better to have a generic approach like a single API
> > > > device_get_match_data() for getting match_data for OF/ACPI/I2C/SPI
> tables.
> > > >
> > > > So, he came with a proposal and shared some code here[1].
> > >
> > > Yes, I'm pretty much following the discussion.
> > >
> > > > Since,I have send this patch, I put my signed -off.
> > >
> > > I'm not talking about this. There is no evidence that Dmitry gives
> > > you any approval to use or clear SoB tag. Again, you may not do like
> this.
> >
> > Here Dmitry is acknowledging, he is ok with the patch I posted.
> >
> 
> No, you just misinterpreted his message.
> 

Dmitry,

As you are the author of code, either you post a patch or provide your SoB as per the guideline mentioned here to avoid confusion.

 https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

Cheers,
Biju
Dmitry Torokhov July 24, 2023, 4:38 p.m. UTC | #11
On Mon, Jul 24, 2023 at 01:58:55PM +0000, Biju Das wrote:
> Hi Andy,
> 
> Thanks for the feedback.
> 
> > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > device_get_match_data() to struct bus_type
> > 
> > On Mon, Jul 24, 2023 at 01:19:02PM +0000, Biju Das wrote:
> > > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > > device_get_match_data() to struct bus_type On Mon, Jul 24, 2023 at
> > > > 12:02:27PM +0000, Biju Das wrote:
> > > > > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > > > > device_get_match_data() to struct bus_type On Sun, Jul 23, 2023
> > > > > > at 09:37:20AM +0100, Biju Das wrote:
> > 
> > ...
> > 
> > > > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > > >
> > > > > > You can't just throw one's SoB tag without clear understanding
> > > > > > what's going on here (either wrong authorship or missing
> > > > > > Co-developed-by or...?).
> > > > >
> > > > > Dmitry feels instead of having separate bus based match_data()
> > > > > like i2c_get_match_data[2] and spi_get_device_match_data[3], it is
> > > > > better to have a generic approach like a single API
> > > > > device_get_match_data() for getting match_data for OF/ACPI/I2C/SPI
> > tables.
> > > > >
> > > > > So, he came with a proposal and shared some code here[1].
> > > >
> > > > Yes, I'm pretty much following the discussion.
> > > >
> > > > > Since,I have send this patch, I put my signed -off.
> > > >
> > > > I'm not talking about this. There is no evidence that Dmitry gives
> > > > you any approval to use or clear SoB tag. Again, you may not do like
> > this.
> > >
> > > Here Dmitry is acknowledging, he is ok with the patch I posted.
> > >
> > 
> > No, you just misinterpreted his message.
> > 
> 
> Dmitry,
> 
> As you are the author of code, either you post a patch or provide your SoB as per the guideline mentioned here to avoid confusion.
> 
>  https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

It was not really proper patch, consider it as an email with parts
written in unified diff, as sometimes it is easier than to explain in
words, and I do not want to take much credit for it.

If you wish you can put "Suggested-by" for me, or just drop my name off
the patch description altogether.

Thanks.
Biju Das July 26, 2023, 5:33 a.m. UTC | #12
> Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> device_get_match_data() to struct bus_type
> 
> On Mon, Jul 24, 2023 at 01:58:55PM +0000, Biju Das wrote:
> > Hi Andy,
> >
> > Thanks for the feedback.
> >
> > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > device_get_match_data() to struct bus_type
> > >
> > > On Mon, Jul 24, 2023 at 01:19:02PM +0000, Biju Das wrote:
> > > > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > > > device_get_match_data() to struct bus_type On Mon, Jul 24, 2023
> > > > > at 12:02:27PM +0000, Biju Das wrote:
> > > > > > > Subject: Re: [PATCH RFC 1/2] drivers: fwnode: Extend
> > > > > > > device_get_match_data() to struct bus_type On Sun, Jul 23,
> > > > > > > 2023 at 09:37:20AM +0100, Biju Das wrote:
> > >
> > > ...
> > >
> > > > > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > > > >
> > > > > > > You can't just throw one's SoB tag without clear
> > > > > > > understanding what's going on here (either wrong authorship
> > > > > > > or missing Co-developed-by or...?).
> > > > > >
> > > > > > Dmitry feels instead of having separate bus based match_data()
> > > > > > like i2c_get_match_data[2] and spi_get_device_match_data[3],
> > > > > > it is better to have a generic approach like a single API
> > > > > > device_get_match_data() for getting match_data for
> > > > > > OF/ACPI/I2C/SPI
> > > tables.
> > > > > >
> > > > > > So, he came with a proposal and shared some code here[1].
> > > > >
> > > > > Yes, I'm pretty much following the discussion.
> > > > >
> > > > > > Since,I have send this patch, I put my signed -off.
> > > > >
> > > > > I'm not talking about this. There is no evidence that Dmitry
> > > > > gives you any approval to use or clear SoB tag. Again, you may
> > > > > not do like
> > > this.
> > > >
> > > > Here Dmitry is acknowledging, he is ok with the patch I posted.
> > > >
> > >
> > > No, you just misinterpreted his message.
> > >
> >
> > Dmitry,
> >
> > As you are the author of code, either you post a patch or provide your
> SoB as per the guideline mentioned here to avoid confusion.
> >
> >
> It was not really proper patch, consider it as an email with parts
> written in unified diff, as sometimes it is easier than to explain in
> words, and I do not want to take much credit for it.
> 
> If you wish you can put "Suggested-by" for me, or just drop my name off
> the patch description altogether.

Sure, will add Suggested-by tag.

Cheers,
Biju