All of lore.kernel.org
 help / color / mirror / Atom feed
From: Biju Das <biju.das.jz@bp.renesas.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Wolfram Sang" <wsa@kernel.org>,
	"Kieran Bingham" <kieran.bingham@ideasonboard.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Hans Verkuil" <hverkuil-cisco@xs4all.nl>,
	"Alessandro Zummo" <a.zummo@towertech.it>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Corey Minyard" <cminyard@mvista.com>,
	"Marek Behún" <kabel@kernel.org>,
	"Jiasheng Jiang" <jiasheng@iscas.ac.cn>,
	"Antonio Borneo" <antonio.borneo@foss.st.com>,
	"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
	"Ahmad Fatoum" <a.fatoum@pengutronix.de>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Fabrizio Castro" <fabrizio.castro.jz@renesas.com>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH v4 01/11] i2c: Enhance i2c_new_ancillary_device API
Date: Fri, 19 May 2023 15:22:06 +0000	[thread overview]
Message-ID: <OS0PR01MB5922CFC8A55898BDD9FCD911867C9@OS0PR01MB5922.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAMuHMdVHZqwW8e9zCZgx2mTBP_Tzcuswo04fxw-DCo__NDFS1w@mail.gmail.com>

Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH v4 01/11] i2c: Enhance i2c_new_ancillary_device API
> 
> Hi Biju,
> 
> On Thu, May 18, 2023 at 1:37 PM Biju Das <biju.das.jz@bp.renesas.com>
> wrote:
> > Renesas PMIC RAA215300 exposes two separate i2c devices, one for the
> > main device and another for rtc device.
> >
> > Enhance i2c_new_ancillary_device() to instantiate a real device.
> > (eg: Instantiate rtc device from PMIC driver)
> >
> > Added helper function __i2c_new_dummy_device to share the code between
> > i2c_new_dummy_device and i2c_new_ancillary_device().
> >
> > Also added helper function __i2c_new_client_device() to pass parent
> > dev parameter, so that the ancillary device can assign its parent
> > during creation.
> >
> > Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > v3->v4:
> >  * Dropped Rb tag from Geert as there are new changes.
> >  * Introduced __i2c_new_dummy_device() to share the code between
> >    i2c_new_dummy_device and i2c_new_ancillary_device().
> >  * Introduced __i2c_new_client_device() to pass parent dev
> >    parameter, so that the ancillary device can assign its parent
> during
> >    creation.
> 
> Thanks for the update!
> 
> LGTM, a few minor comments below.
> 
> > --- a/drivers/i2c/i2c-core-base.c
> > +++ b/drivers/i2c/i2c-core-base.c
> > @@ -893,24 +893,10 @@ int i2c_dev_irq_from_resources(const struct
> resource *resources,
> >         return 0;
> >  }
> >
> > -/**
> > - * i2c_new_client_device - instantiate an i2c device
> > - * @adap: the adapter managing the device
> > - * @info: describes one I2C device; bus_num is ignored
> > - * Context: can sleep
> > - *
> > - * Create an i2c device. Binding is handled through driver model
> > - * probe()/remove() methods.  A driver may be bound to this device
> > when we
> > - * return from this function, or any later moment (e.g. maybe
> > hotplugging will
> > - * load the driver module).  This call is not appropriate for use by
> > mainboard
> > - * initialization logic, which usually runs during an arch_initcall()
> > long
> > - * before any i2c_adapter could exist.
> > - *
> > - * This returns the new i2c client, which may be saved for later use
> > with
> > - * i2c_unregister_device(); or an ERR_PTR to describe the error.
> > - */
> > -struct i2c_client *
> > -i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info
> > const *info)
> > +static struct i2c_client *
> > +__i2c_new_client_device(struct i2c_adapter *adap,
> > +                       struct i2c_board_info const *info,
> > +                       struct device *dev)
> 
> struct device *parent?

OK. Will use parent below as well(__i2c_new_dummy_device())

> 
> >  {
> >         struct i2c_client       *client;
> >         int                     status;
> 
> > @@ -1054,6 +1062,25 @@ static struct i2c_driver dummy_driver = {
> >         .id_table       = dummy_id,
> >  };
> >
> > +static struct i2c_client *__i2c_new_dummy_device(struct i2c_adapter
> *adapter,
> > +                                                u16 address, const
> char *name,
> > +                                                struct device *dev) {
> > +       struct i2c_board_info info = {
> > +               I2C_BOARD_INFO("dummy", address),
> > +       };
> > +
> > +       if (name) {
> > +               ssize_t ret = strscpy(info.type, name,
> > + sizeof(info.type));
> > +
> > +               if (ret < 0)
> > +                       return ERR_PTR(dev_err_probe(&adapter->dev,
> ret,
> > +                                                    "Invalid device
> > + name\n"));
> 
> %s too long?

Ok, will add %s
			return ERR_PTR(dev_err_probe(&adapter->dev, ret,
						     "Invalid device name: %s\n",
						     name));
> 
> > +       }
> > +
> > +       return __i2c_new_client_device(adapter, &info, dev); }
> > +
> >  /**
> >   * i2c_new_dummy_device - return a new i2c device bound to a dummy
> driver
> >   * @adapter: the adapter managing the device
> 
> > @@ -1122,15 +1145,17 @@ EXPORT_SYMBOL_GPL(devm_i2c_new_dummy_device);
> >   * @client: Handle to the primary client
> >   * @name: Handle to specify which secondary address to get
> >   * @default_addr: Used as a fallback if no secondary address was
> > specified
> > + * @aux_device_name: Ancillary device name
> >   * Context: can sleep
> >   *
> >   * I2C clients can be composed of multiple I2C slaves bound together
> in a single
> >   * component. The I2C client driver then binds to the master I2C
> > slave and needs
> > - * to create I2C dummy clients to communicate with all the other
> slaves.
> > + * to create I2C ancillary clients to communicate with all the other
> slaves.
> >   *
> > - * This function creates and returns an I2C dummy client whose I2C
> > address is
> > - * retrieved from the platform firmware based on the given slave
> > name. If no
> > - * address is specified by the firmware default_addr is used.
> > + * This function creates and returns an I2C ancillary client whose
> > + I2C address
> > + * is retrieved from the platform firmware based on the given slave
> > + name. If no
> > + * address is specified by the firmware default_addr is used. If no
> > + aux_device_
> > + * name is specified by the firmware, it will create an I2C dummy
> client.
> 
> Please add something like:
> 
>     The ancillary's device parent will be set to the primary device.

OK, will add.

> 
> >   *
> >   * On DT-based platforms the address is retrieved from the "reg"
> property entry
> >   * cell whose "reg-names" value matches the slave name.
> 
> > @@ -1153,7 +1179,9 @@ struct i2c_client
> *i2c_new_ancillary_device(struct i2c_client *client,
> >         }
> >
> >         dev_dbg(&client->adapter->dev, "Address for %s : 0x%x\n",
> name, addr);
> > -       return i2c_new_dummy_device(client->adapter, addr);
> > +       return __i2c_new_dummy_device(client->adapter, addr,
> > +                                     aux_device_name ?
> > + aux_device_name : NULL,
> 
> You can just pass aux_device_name.

Agreed.

Cheers,
Biju

WARNING: multiple messages have this Message-ID (diff)
From: Biju Das <biju.das.jz@bp.renesas.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Corey Minyard" <cminyard@mvista.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Antonio Borneo" <antonio.borneo@foss.st.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Marek Behún" <kabel@kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Kieran Bingham" <kieran.bingham@ideasonboard.com>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"Alessandro Zummo" <a.zummo@towertech.it>,
	"Jiasheng Jiang" <jiasheng@iscas.ac.cn>,
	"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
	"Fabrizio Castro" <fabrizio.castro.jz@renesas.com>,
	"Ahmad Fatoum" <a.fatoum@pengutronix.de>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Wolfram Sang" <wsa@kernel.org>,
	"Hans Verkuil" <hverkuil-cisco@xs4all.nl>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: RE: [PATCH v4 01/11] i2c: Enhance i2c_new_ancillary_device API
Date: Fri, 19 May 2023 15:22:06 +0000	[thread overview]
Message-ID: <OS0PR01MB5922CFC8A55898BDD9FCD911867C9@OS0PR01MB5922.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAMuHMdVHZqwW8e9zCZgx2mTBP_Tzcuswo04fxw-DCo__NDFS1w@mail.gmail.com>

Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH v4 01/11] i2c: Enhance i2c_new_ancillary_device API
> 
> Hi Biju,
> 
> On Thu, May 18, 2023 at 1:37 PM Biju Das <biju.das.jz@bp.renesas.com>
> wrote:
> > Renesas PMIC RAA215300 exposes two separate i2c devices, one for the
> > main device and another for rtc device.
> >
> > Enhance i2c_new_ancillary_device() to instantiate a real device.
> > (eg: Instantiate rtc device from PMIC driver)
> >
> > Added helper function __i2c_new_dummy_device to share the code between
> > i2c_new_dummy_device and i2c_new_ancillary_device().
> >
> > Also added helper function __i2c_new_client_device() to pass parent
> > dev parameter, so that the ancillary device can assign its parent
> > during creation.
> >
> > Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > v3->v4:
> >  * Dropped Rb tag from Geert as there are new changes.
> >  * Introduced __i2c_new_dummy_device() to share the code between
> >    i2c_new_dummy_device and i2c_new_ancillary_device().
> >  * Introduced __i2c_new_client_device() to pass parent dev
> >    parameter, so that the ancillary device can assign its parent
> during
> >    creation.
> 
> Thanks for the update!
> 
> LGTM, a few minor comments below.
> 
> > --- a/drivers/i2c/i2c-core-base.c
> > +++ b/drivers/i2c/i2c-core-base.c
> > @@ -893,24 +893,10 @@ int i2c_dev_irq_from_resources(const struct
> resource *resources,
> >         return 0;
> >  }
> >
> > -/**
> > - * i2c_new_client_device - instantiate an i2c device
> > - * @adap: the adapter managing the device
> > - * @info: describes one I2C device; bus_num is ignored
> > - * Context: can sleep
> > - *
> > - * Create an i2c device. Binding is handled through driver model
> > - * probe()/remove() methods.  A driver may be bound to this device
> > when we
> > - * return from this function, or any later moment (e.g. maybe
> > hotplugging will
> > - * load the driver module).  This call is not appropriate for use by
> > mainboard
> > - * initialization logic, which usually runs during an arch_initcall()
> > long
> > - * before any i2c_adapter could exist.
> > - *
> > - * This returns the new i2c client, which may be saved for later use
> > with
> > - * i2c_unregister_device(); or an ERR_PTR to describe the error.
> > - */
> > -struct i2c_client *
> > -i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info
> > const *info)
> > +static struct i2c_client *
> > +__i2c_new_client_device(struct i2c_adapter *adap,
> > +                       struct i2c_board_info const *info,
> > +                       struct device *dev)
> 
> struct device *parent?

OK. Will use parent below as well(__i2c_new_dummy_device())

> 
> >  {
> >         struct i2c_client       *client;
> >         int                     status;
> 
> > @@ -1054,6 +1062,25 @@ static struct i2c_driver dummy_driver = {
> >         .id_table       = dummy_id,
> >  };
> >
> > +static struct i2c_client *__i2c_new_dummy_device(struct i2c_adapter
> *adapter,
> > +                                                u16 address, const
> char *name,
> > +                                                struct device *dev) {
> > +       struct i2c_board_info info = {
> > +               I2C_BOARD_INFO("dummy", address),
> > +       };
> > +
> > +       if (name) {
> > +               ssize_t ret = strscpy(info.type, name,
> > + sizeof(info.type));
> > +
> > +               if (ret < 0)
> > +                       return ERR_PTR(dev_err_probe(&adapter->dev,
> ret,
> > +                                                    "Invalid device
> > + name\n"));
> 
> %s too long?

Ok, will add %s
			return ERR_PTR(dev_err_probe(&adapter->dev, ret,
						     "Invalid device name: %s\n",
						     name));
> 
> > +       }
> > +
> > +       return __i2c_new_client_device(adapter, &info, dev); }
> > +
> >  /**
> >   * i2c_new_dummy_device - return a new i2c device bound to a dummy
> driver
> >   * @adapter: the adapter managing the device
> 
> > @@ -1122,15 +1145,17 @@ EXPORT_SYMBOL_GPL(devm_i2c_new_dummy_device);
> >   * @client: Handle to the primary client
> >   * @name: Handle to specify which secondary address to get
> >   * @default_addr: Used as a fallback if no secondary address was
> > specified
> > + * @aux_device_name: Ancillary device name
> >   * Context: can sleep
> >   *
> >   * I2C clients can be composed of multiple I2C slaves bound together
> in a single
> >   * component. The I2C client driver then binds to the master I2C
> > slave and needs
> > - * to create I2C dummy clients to communicate with all the other
> slaves.
> > + * to create I2C ancillary clients to communicate with all the other
> slaves.
> >   *
> > - * This function creates and returns an I2C dummy client whose I2C
> > address is
> > - * retrieved from the platform firmware based on the given slave
> > name. If no
> > - * address is specified by the firmware default_addr is used.
> > + * This function creates and returns an I2C ancillary client whose
> > + I2C address
> > + * is retrieved from the platform firmware based on the given slave
> > + name. If no
> > + * address is specified by the firmware default_addr is used. If no
> > + aux_device_
> > + * name is specified by the firmware, it will create an I2C dummy
> client.
> 
> Please add something like:
> 
>     The ancillary's device parent will be set to the primary device.

OK, will add.

> 
> >   *
> >   * On DT-based platforms the address is retrieved from the "reg"
> property entry
> >   * cell whose "reg-names" value matches the slave name.
> 
> > @@ -1153,7 +1179,9 @@ struct i2c_client
> *i2c_new_ancillary_device(struct i2c_client *client,
> >         }
> >
> >         dev_dbg(&client->adapter->dev, "Address for %s : 0x%x\n",
> name, addr);
> > -       return i2c_new_dummy_device(client->adapter, addr);
> > +       return __i2c_new_dummy_device(client->adapter, addr,
> > +                                     aux_device_name ?
> > + aux_device_name : NULL,
> 
> You can just pass aux_device_name.

Agreed.

Cheers,
Biju

  reply	other threads:[~2023-05-19 15:22 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-18 11:36 [PATCH v4 00/11] Add Renesas PMIC RAA215300 and built-in RTC support Biju Das
2023-05-18 11:36 ` [PATCH v4 01/11] i2c: Enhance i2c_new_ancillary_device API Biju Das
2023-05-18 11:36   ` Biju Das
2023-05-19 12:29   ` Geert Uytterhoeven
2023-05-19 12:29     ` Geert Uytterhoeven
2023-05-19 15:22     ` Biju Das [this message]
2023-05-19 15:22       ` Biju Das
2023-05-18 11:36 ` [PATCH v4 02/11] dt-bindings: rtc: isl1208: Convert to json-schema Biju Das
2023-05-18 11:36 ` [PATCH v4 03/11] dt-bindings: rtc: isil,isl1208: Document clock and clock-names properties Biju Das
2023-05-18 19:17   ` Conor Dooley
2023-05-19 12:35   ` Geert Uytterhoeven
2023-05-19 16:02     ` Biju Das
2023-05-18 11:36 ` [PATCH v4 04/11] rtc: isl1208: Drop name variable Biju Das
2023-05-19 12:37   ` Geert Uytterhoeven
2023-05-18 11:36 ` [PATCH v4 05/11] rtc: isl1208: Make similar I2C and DT-based matching table Biju Das
2023-05-19 12:38   ` Geert Uytterhoeven
2023-05-19 16:08     ` Biju Das
2023-05-19 16:10       ` Biju Das
2023-05-19 19:43       ` Geert Uytterhoeven
2023-05-22  6:48         ` Biju Das
2023-05-18 11:36 ` [PATCH v4 06/11] rtc: isl1208: Drop enum isl1208_id and split isl1208_configs[] Biju Das
2023-05-19 12:40   ` Geert Uytterhoeven
2023-05-18 11:36 ` [PATCH v4 07/11] rtc: isl1208: Add isl1208_set_xtoscb() Biju Das
2023-05-19 12:48   ` Geert Uytterhoeven
2023-05-19 16:24     ` Biju Das
2023-05-18 11:36 ` [PATCH v4 08/11] rtc: isl1208: Add support for the built-in RTC on the PMIC RAA215300 Biju Das
2023-05-19 12:54   ` Geert Uytterhoeven
2023-05-19 16:47     ` Biju Das
2023-05-18 11:36 ` [PATCH v4 09/11] regulator: dt-bindings: Add Renesas RAA215300 PMIC bindings Biju Das
2023-05-18 19:13   ` Conor Dooley
2023-05-19  6:53     ` Biju Das
2023-05-19 14:10       ` Conor Dooley
2023-05-19 14:39         ` Biju Das
2023-05-19 14:49           ` Geert Uytterhoeven
2023-05-19 14:52             ` Geert Uytterhoeven
2023-05-19 15:20             ` Conor Dooley
2023-05-19 14:58         ` Mark Brown
2023-05-19 12:58   ` Geert Uytterhoeven
2023-05-19 16:49     ` Biju Das
2023-05-18 11:36 ` [PATCH v4 10/11] regulator: Add Renesas PMIC RAA215300 driver Biju Das
2023-05-19 13:02   ` Geert Uytterhoeven
2023-05-19 16:50     ` Biju Das
2023-05-18 11:36 ` [PATCH v4 11/11] arm64: dts: renesas: rzg2l-smarc-som: Enable PMIC and built-in RTC Biju Das

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OS0PR01MB5922CFC8A55898BDD9FCD911867C9@OS0PR01MB5922.jpnprd01.prod.outlook.com \
    --to=biju.das.jz@bp.renesas.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=a.zummo@towertech.it \
    --cc=airlied@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrzej.hajda@intel.com \
    --cc=antonio.borneo@foss.st.com \
    --cc=cminyard@mvista.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fabrizio.castro.jz@renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jernej.skrabec@gmail.com \
    --cc=jiasheng@iscas.ac.cn \
    --cc=jonas@kwiboo.se \
    --cc=kabel@kernel.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=rfoss@kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.