From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Wolfram Sang" <wsa@kernel.org>,
"Luca Ceresoli" <luca.ceresoli@bootlin.com>,
"Matti Vaittinen" <Matti.Vaittinen@fi.rohmeurope.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Peter Rosin" <peda@axentia.se>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>,
"Michael Tretter" <m.tretter@pengutronix.de>,
"Shawn Tu" <shawnx.tu@intel.com>,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Mike Pagano" <mpagano@gentoo.org>,
"Krzysztof Hałasa" <khalasa@piap.pl>,
"Marek Vasut" <marex@denx.de>,
"Luca Ceresoli" <luca@lucaceresoli.net>
Subject: Re: [PATCH v5 2/8] i2c: add I2C Address Translator (ATR) support
Date: Thu, 8 Dec 2022 14:53:24 +0200 [thread overview]
Message-ID: <Y5HeRL6H5vEeDznl@smile.fi.intel.com> (raw)
In-Reply-To: <20221208104006.316606-3-tomi.valkeinen@ideasonboard.com>
On Thu, Dec 08, 2022 at 12:40:00PM +0200, Tomi Valkeinen wrote:
> From: Luca Ceresoli <luca@lucaceresoli.net>
>
> An ATR is a device that looks similar to an i2c-mux: it has an I2C
> slave "upstream" port and N master "downstream" ports, and forwards
> transactions from upstream to the appropriate downstream port. But is
> is different in that the forwarded transaction has a different slave
> address. The address used on the upstream bus is called the "alias"
> and is (potentially) different from the physical slave address of the
> downstream chip.
>
> Add a helper file (just like i2c-mux.c for a mux or switch) to allow
> implementing ATR features in a device driver. The helper takes care or
> adapter creation/destruction and translates addresses at each transaction.
Besides comments given against diff between series versions, see below.
...
> +static int i2c_atr_attach_client(struct i2c_adapter *adapter,
> + const struct i2c_board_info *info,
> + const struct i2c_client *client)
> +{
> + struct i2c_atr_chan *chan = adapter->algo_data;
> + struct i2c_atr *atr = chan->atr;
> + struct i2c_atr_cli2alias_pair *c2a;
> + u16 alias_id;
> + int ret;
> +
> + c2a = kzalloc(sizeof(*c2a), GFP_KERNEL);
> + if (!c2a)
> + return -ENOMEM;
> +
> + ret = atr->ops->attach_client(atr, chan->chan_id, info, client,
> + &alias_id);
> + if (ret)
> + goto err_free;
> + if (alias_id == 0) {
> + ret = -EINVAL;
I'm wondering why attach_client can't return this error and provide a guarantee
that if no error, the alias_id is never be 0?
> + goto err_free;
> + }
> +
> + c2a->client = client;
> + c2a->alias = alias_id;
> + list_add(&c2a->node, &chan->alias_list);
> +
> + return 0;
> +
> +err_free:
> + kfree(c2a);
> + return ret;
> +}
...
> + if (bus_handle) {
> + device_set_node(&chan->adap.dev, fwnode_handle_get(bus_handle));
I believe the correct way, while above still works, is
device_set_node(&chan->adap.dev, bus_handle);
fwnode_handle_get(dev_fwnode(&chan->adap.dev));
But I agree that this looks a bit verbose. And...
> + } else {
> + struct fwnode_handle *atr_node;
> + struct fwnode_handle *child;
> + u32 reg;
> +
> + atr_node = device_get_named_child_node(dev, "i2c-atr");
> +
> + fwnode_for_each_child_node(atr_node, child) {
> + ret = fwnode_property_read_u32(child, "reg", ®);
> + if (ret)
> + continue;
> + if (chan_id == reg)
> + break;
> + }
> +
> + device_set_node(&chan->adap.dev, child);
...OTOH, you set node with bumped reference here. So I leave all this to
the maintainers.
> + fwnode_handle_put(atr_node);
> + }
> + ret = i2c_add_adapter(&chan->adap);
> + if (ret) {
> + dev_err(dev, "failed to add atr-adapter %u (error=%d)\n",
> + chan_id, ret);
> + goto err_mutex_destroy;
> + }
> +
> + snprintf(symlink_name, sizeof(symlink_name), "channel-%u",
> + chan->chan_id);
> +
> + ret = sysfs_create_link(&chan->adap.dev.kobj, &dev->kobj, "atr_device");
> + if (ret)
> + dev_warn(dev, "can't create symlink to atr device\n");
> + ret = sysfs_create_link(&dev->kobj, &chan->adap.dev.kobj, symlink_name);
> + if (ret)
> + dev_warn(dev, "can't create symlink for channel %u\n", chan_id);
> +
> + dev_dbg(dev, "Added ATR child bus %d\n", i2c_adapter_id(&chan->adap));
> +
> + atr->adapter[chan_id] = &chan->adap;
> + return 0;
> +
> +err_mutex_destroy:
Now it's a bit misleading, wouldn't be better
err_put_fwnode:
?
> + fwnode_handle_put(dev_fwnode(&chan->adap.dev));
> + mutex_destroy(&chan->orig_addrs_lock);
> + kfree(chan);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(i2c_atr_add_adapter);
Wondering if we may put this into namespace from day 1.
...
> +/**
> + * i2c_atr_del_adapter - Remove a child ("downstream") I2C bus added by
> + * i2c_atr_del_adapter().
> + * @atr: The I2C ATR
> + * @chan_id: Index of the `adapter to be removed (0 .. max_adapters-1)
> + */
> +void i2c_atr_del_adapter(struct i2c_atr *atr, u32 chan_id)
> +{
> + char symlink_name[ATR_MAX_SYMLINK_LEN];
> +
> + struct i2c_adapter *adap = atr->adapter[chan_id];
> + struct i2c_atr_chan *chan = adap->algo_data;
> + struct fwnode_handle *fwnode = dev_fwnode(&adap->dev);
> + struct device *dev = atr->dev;
> + if (!atr->adapter[chan_id]) {
Isn't it the same as
if (!adap)
?
> + dev_err(dev, "Adapter %d does not exist\n", chan_id);
> + return;
> + }
> +
> + dev_dbg(dev, "Removing ATR child bus %d\n", i2c_adapter_id(adap));
> +
> + atr->adapter[chan_id] = NULL;
> +
> + snprintf(symlink_name, sizeof(symlink_name), "channel-%u",
> + chan->chan_id);
> + sysfs_remove_link(&dev->kobj, symlink_name);
> + sysfs_remove_link(&chan->adap.dev.kobj, "atr_device");
> +
> + i2c_del_adapter(adap);
> + fwnode_handle_put(fwnode);
> + mutex_destroy(&chan->orig_addrs_lock);
> + kfree(chan->orig_addrs);
> + kfree(chan);
> +}
...
> +struct i2c_atr {
> + /* private: internal use only */
What is private? The entire structure? Then why it's defined in
the include/linux/? Can't you make it opaque?
> + struct i2c_adapter *parent;
> + struct device *dev;
> + const struct i2c_atr_ops *ops;
> +
> + void *priv;
> +
> + struct i2c_algorithm algo;
> + /* lock for the I2C bus segment (see struct i2c_lock_operations) */
> + struct mutex lock;
> + int max_adapters;
> +
> + struct i2c_adapter *adapter[];
> +};
...
> +static inline void i2c_atr_set_clientdata(struct i2c_atr *atr, void *data)
> +{
> + atr->priv = data;
> +}
> +
> +static inline void *i2c_atr_get_clientdata(struct i2c_atr *atr)
> +{
> + return atr->priv;
> +}
The function names are misleading, because I would think this is about driver
data that has been set.
I would rather use name like
i2c_atr_get_priv()
i2c_atr_set_priv()
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-12-08 12:53 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 10:39 [PATCH v5 0/8] i2c-atr and FPDLink Tomi Valkeinen
2022-12-08 10:39 ` [PATCH v5 1/8] i2c: core: let adapters be notified of client attach/detach Tomi Valkeinen
2022-12-08 12:30 ` Andy Shevchenko
2022-12-08 16:10 ` Tomi Valkeinen
2022-12-11 16:55 ` Laurent Pinchart
2022-12-19 8:51 ` Luca Ceresoli
2022-12-19 9:48 ` Andy Shevchenko
2022-12-26 16:54 ` Laurent Pinchart
2022-12-27 20:07 ` Andy Shevchenko
2022-12-08 10:40 ` [PATCH v5 2/8] i2c: add I2C Address Translator (ATR) support Tomi Valkeinen
2022-12-08 12:53 ` Andy Shevchenko [this message]
2022-12-08 16:01 ` Tomi Valkeinen
2022-12-08 18:09 ` Andy Shevchenko
2022-12-08 10:40 ` [PATCH v5 3/8] dt-bindings: media: add bindings for TI DS90UB913 Tomi Valkeinen
2022-12-11 17:13 ` Laurent Pinchart
2022-12-11 17:21 ` Laurent Pinchart
2022-12-13 13:36 ` Tomi Valkeinen
2022-12-26 16:46 ` Laurent Pinchart
2023-01-04 8:12 ` Tomi Valkeinen
2023-01-04 12:52 ` Laurent Pinchart
2022-12-13 13:21 ` Tomi Valkeinen
2022-12-08 10:40 ` [PATCH v5 4/8] dt-bindings: media: add bindings for TI DS90UB953 Tomi Valkeinen
2022-12-09 21:27 ` Rob Herring
2023-01-04 8:26 ` Tomi Valkeinen
2022-12-11 17:34 ` Laurent Pinchart
2022-12-13 14:06 ` Tomi Valkeinen
2022-12-08 10:40 ` [PATCH v5 5/8] dt-bindings: media: add bindings for TI DS90UB960 Tomi Valkeinen
2022-12-09 21:30 ` Rob Herring
2022-12-11 17:58 ` Laurent Pinchart
2022-12-13 14:25 ` Tomi Valkeinen
2022-12-26 16:52 ` Laurent Pinchart
2023-01-04 8:59 ` Tomi Valkeinen
2023-01-04 12:57 ` Laurent Pinchart
2023-01-04 14:05 ` Tomi Valkeinen
2023-01-05 6:54 ` Laurent Pinchart
2022-12-08 10:40 ` [PATCH v5 6/8] media: i2c: add DS90UB960 driver Tomi Valkeinen
2022-12-08 13:34 ` kernel test robot
2022-12-08 14:55 ` kernel test robot
2022-12-08 10:40 ` [PATCH v5 7/8] media: i2c: add DS90UB913 driver Tomi Valkeinen
2022-12-08 14:35 ` kernel test robot
2022-12-11 18:33 ` Laurent Pinchart
2022-12-14 6:29 ` Tomi Valkeinen
2022-12-14 6:36 ` Tomi Valkeinen
2022-12-26 16:56 ` Laurent Pinchart
2022-12-26 19:25 ` Tomi Valkeinen
2023-01-04 13:55 ` Laurent Pinchart
2023-01-04 14:13 ` Tomi Valkeinen
2023-01-04 15:32 ` Laurent Pinchart
2023-01-04 15:43 ` Tomi Valkeinen
2022-12-26 17:01 ` Laurent Pinchart
2022-12-27 20:09 ` Andy Shevchenko
2023-01-04 13:29 ` Laurent Pinchart
2022-12-14 6:48 ` Tomi Valkeinen
2022-12-08 10:40 ` [PATCH v5 8/8] media: i2c: add DS90UB953 driver Tomi Valkeinen
2022-12-08 10:42 ` [PATCH v5 0/8] i2c-atr and FPDLink Tomi Valkeinen
2022-12-08 12:26 ` Andy Shevchenko
2022-12-08 14:40 ` Tomi Valkeinen
2022-12-08 15:57 ` Andy Shevchenko
2022-12-08 15:58 ` Andy Shevchenko
2022-12-08 16:05 ` Tomi Valkeinen
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=Y5HeRL6H5vEeDznl@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=Matti.Vaittinen@fi.rohmeurope.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hverkuil@xs4all.nl \
--cc=khalasa@piap.pl \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=lgirdwood@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=luca@lucaceresoli.net \
--cc=m.tretter@pengutronix.de \
--cc=marex@denx.de \
--cc=mchehab@kernel.org \
--cc=mpagano@gentoo.org \
--cc=peda@axentia.se \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=shawnx.tu@intel.com \
--cc=tomi.valkeinen@ideasonboard.com \
--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.