Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1205219 > unrolled thread

Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg Wolfram Sang <wsa@the-dreams.de> - 2015-08-11 17:40 +0200
    Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg Wolfram Sang <wsa@the-dreams.de> - 2015-08-11 18:20 +0200
      Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg York Sun <yorksun@freescale.com> - 2015-08-11 19:00 +0200
        Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg Wolfram Sang <wsa@the-dreams.de> - 2015-08-11 22:10 +0200
          Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg York Sun <yorksun@freescale.com> - 2015-08-11 23:10 +0200
            Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg Wolfram Sang <wsa@the-dreams.de> - 2015-08-12 03:40 +0200
              Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg York Sun <yorksun@freescale.com> - 2015-08-13 18:40 +0200
                Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg Wolfram Sang <wsa@the-dreams.de> - 2015-08-14 20:30 +0200
    Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg York Sun <yorksun@freescale.com> - 2015-08-11 18:20 +0200

#1205219 — Re: [Patch v3] driver/i2c/mux: Add register-based mux i2c-mux-reg

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#1205256

[Multipart message — attachments visible in raw view] — view raw

> >> +	if (of_find_property(np, "little-endian", NULL)) {
> > 
> > You should check for a "big-endian" property as well, no?
> 
> I use the little-endian as an option to indicate the nature of litten-endian
> register. It is default to big-endian if this property doesn't exist. I prefer
> this way unless you strongly suggest to add both and throw out an error if
> neither exists.

I'd think that "little-endian" or "big-endian" force a setting. If none
is present, we shall take the CPU endianess. Or am I overlooking
something?

Oh, and I forgot the biggest issue: I get build errors, because
__LITTLE_ENDIAN__ should be __LITTLE_ENDIAN. Is this a recent change or
why did it work for you?

Thanks for the quick response,

   Wolfram

[toc] | [prev] | [next] | [standalone]

#1205277

On 08/11/2015 09:16 AM, Wolfram Sang wrote:
>>>> +	if (of_find_property(np, "little-endian", NULL)) {
>>>
>>> You should check for a "big-endian" property as well, no?
>>
>> I use the little-endian as an option to indicate the nature of litten-endian
>> register. It is default to big-endian if this property doesn't exist. I prefer
>> this way unless you strongly suggest to add both and throw out an error if
>> neither exists.
> 
> I'd think that "little-endian" or "big-endian" force a setting. If none
> is present, we shall take the CPU endianess. Or am I overlooking
> something?

You are right. The current code checks for littel-endian property. If missing,
the CPU endianess is used. Do you prefer to check littlen-endian first, if
missing then big-endian, if both missing then use CPU endianess?

> 
> Oh, and I forgot the biggest issue: I get build errors, because
> __LITTLE_ENDIAN__ should be __LITTLE_ENDIAN. Is this a recent change or
> why did it work for you?
> 

I tested it on 4.0.4 kernel. I see a lot of reference of __LITTLE_ENDIAN__. I
will test the new patch on the latest kernel.

York
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205407

[Multipart message — attachments visible in raw view] — view raw

> > I'd think that "little-endian" or "big-endian" force a setting. If none
> > is present, we shall take the CPU endianess. Or am I overlooking
> > something?
> 
> You are right. The current code checks for littel-endian property. If missing,
> the CPU endianess is used. Do you prefer to check littlen-endian first, if
> missing then big-endian, if both missing then use CPU endianess?

Yes. Do it like this.

[toc] | [prev] | [next] | [standalone]

#1205433

On 08/11/2015 01:02 PM, Wolfram Sang wrote:
>>> I'd think that "little-endian" or "big-endian" force a setting. If none
>>> is present, we shall take the CPU endianess. Or am I overlooking
>>> something?
>>
>> You are right. The current code checks for littel-endian property. If missing,
>> the CPU endianess is used. Do you prefer to check littlen-endian first, if
>> missing then big-endian, if both missing then use CPU endianess?
> 
> Yes. Do it like this.
> 

OK. Will do.
Do I have to add myself to MAINTAINER file for this driver?

York


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205544

[Multipart message — attachments visible in raw view] — view raw

> Do I have to add myself to MAINTAINER file for this driver?

Do you want to maintain this driver?

[toc] | [prev] | [next] | [standalone]

#1206956

On 08/11/2015 06:35 PM, Wolfram Sang wrote:
> 
>> Do I have to add myself to MAINTAINER file for this driver?
> 
> Do you want to maintain this driver?
> 

I prefer not, if that is OK.

York
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1207809

> >> Do I have to add myself to MAINTAINER file for this driver?
> > 
> > Do you want to maintain this driver?
> 
> I prefer not, if that is OK.

Not my most favourite answer, but yes, it is ok ;)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205258

On 08/11/2015 08:39 AM, Wolfram Sang wrote:
> 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".

Sure. That's easy to fix.

> 
>> +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.

OK. I can remove it.

> 
>> 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.

Will fix.

> 
>>  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.

OK.

> 
>> +		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?

I use the little-endian as an option to indicate the nature of litten-endian
register. It is default to big-endian if this property doesn't exist. I prefer
this way unless you strongly suggest to add both and throw out an error if
neither exists.

> 
>> +		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.

OK.

> 
>> +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.

Will remove.

Thanks for reviewing. I will send a new version after testing.

York
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web