From: Wolfram Sang <wsa@the-dreams.de>
To: York Sun <yorksun@freescale.com>
Cc: linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
Paul Bolle <pebolle@tiscali.nl>,
Peter Korsgaard <peter.korsgaard@barco.com>,
Alexander Sverdlin <alexander.sverdlin@nokia.com>
Subject: Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg
Date: Tue, 11 Aug 2015 17:39:16 +0200 [thread overview]
Message-ID: <20150811153916.GD1525@katana> (raw)
In-Reply-To: <1434657458-16553-1-git-send-email-yorksun@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]
On Thu, Jun 18, 2015 at 12:57:38PM -0700, York Sun wrote:
> Based on i2c-mux-gpio driver, similarly the register-based mux
> switch from one bus to another by setting a single register.
> The register can be on PCIe bus, local bus, or any memory-mapped
> address. The endianness of such register can be specified in device
> tree if used, or in platform data.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
Thanks for this driver!
...
> +- no-read: The existence indicates reading the register is not allowed.
Given that we have "read-only" properties already, I'd prefer this one
to be "write-only".
> +For each i2c child node, an I2C child bus will be created. They will
> +be numbered based on their order in the device tree.
This is a Linux specific detail (which can be overridden by aliases), so
it should not be in this document, I'd say.
> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
> index f6d313e..77c1257 100644
> --- a/drivers/i2c/muxes/Kconfig
> +++ b/drivers/i2c/muxes/Kconfig
> @@ -29,6 +29,17 @@ config I2C_MUX_GPIO
> This driver can also be built as a module. If so, the module
> will be called i2c-mux-gpio.
>
> +config I2C_MUX_REG
> + tristate "Register-based I2C multiplexer"
> + help
> + If you say yes to this option, support will be included for a
> + register based I2C multiplexer. This driver provides access to
> + I2C busses connected through a MUX, which is controlled
> + by a sinple register.
Typo here. And keep the sorting, please.
> obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
> +obj-$(CONFIG_I2C_MUX_REG) += i2c-mux-reg.o
Keep the sorting, please.
> obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
> obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
> obj-$(CONFIG_I2C_MUX_PINCTRL) += i2c-mux-pinctrl.o
> + adapter = of_find_i2c_adapter_by_node(adapter_np);
> + if (!adapter) {
> + dev_err(&pdev->dev, "Cannot find parent bus\n");
I don't think we should print something when deferring.
> + return -EPROBE_DEFER;
> + }
> + mux->parent = adapter;
> + mux->data.parent = i2c_adapter_id(adapter);
> + put_device(&adapter->dev);
> +
> + mux->data.n_values = of_get_child_count(np);
> + if (of_find_property(np, "little-endian", NULL)) {
You should check for a "big-endian" property as well, no?
> + parent = i2c_get_adapter(mux->data.parent);
> + if (!parent) {
> + dev_err(&pdev->dev, "Parent adapter (%d) not found\n",
> + mux->data.parent);
> + return -EPROBE_DEFER;
Ditto about printing when deferred probing.
> +static int i2c_mux_reg_remove(struct platform_device *pdev)
> +{
> + struct regmux *mux = platform_get_drvdata(pdev);
> + int i;
> +
> + for (i = 0; i < mux->data.n_values; i++)
> + i2c_del_mux_adapter(mux->adap[i]);
> +
> + i2c_put_adapter(mux->parent);
> +
> + dev_dbg(&pdev->dev, "Removed\n");
No need for that debug. The driver core has debug output for that.
Thanks,
Wolfram
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-08-11 15:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 19:57 [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg York Sun
2015-06-19 6:28 ` Alexander Sverdlin
2015-08-11 15:39 ` Wolfram Sang [this message]
2015-08-11 15:55 ` York Sun
2015-08-11 16:16 ` Wolfram Sang
2015-08-11 16:36 ` York Sun
2015-08-11 20:02 ` Wolfram Sang
2015-08-11 21:04 ` York Sun
2015-08-12 1:35 ` Wolfram Sang
2015-08-13 15:57 ` York Sun
2015-08-14 18:27 ` Wolfram Sang
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=20150811153916.GD1525@katana \
--to=wsa@the-dreams.de \
--cc=alexander.sverdlin@nokia.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pebolle@tiscali.nl \
--cc=peter.korsgaard@barco.com \
--cc=yorksun@freescale.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).