* Re: [PATCH v2 4/4] gpio: pca953x: fix an incorrect lockdep warning
From: Wolfram Sang @ 2016-09-24 8:55 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Alexandre Courbot, Andy Shevchenko,
Vignesh R, Yong Li, Geert Uytterhoeven, Peter Zijlstra,
Ingo Molnar, Peter Rosin, linux-i2c, linux-gpio, LKML
In-Reply-To: <CACRpkdbYgetpYntO6KsVLh1n_7DU+1AD3AwVVkmV5ud5A6Q31g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
On Fri, Sep 23, 2016 at 10:10:57AM +0200, Linus Walleij wrote:
> On Wed, Sep 21, 2016 at 7:45 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
> >> In order to get rid of the warning, retrieve the adapter nesting depth
> >> and use it as lockdep subclass for chip->i2c_lock.
> >>
> >> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > Linus, we'd like that in 4.9. Can I get your ack for the gpio part?
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Sorry for not attending quick enough, I was down in the
> block layer.
Well, it was close but still quick enough. Glad to see that one can come
back from the depths of the block layer ;)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Wolfram Sang @ 2016-09-24 8:41 UTC (permalink / raw)
To: Rob Herring
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman,
linux-i2c@vger.kernel.org, Carlo Caione, linux-amlogic,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqJGQ2az=eO0PbfcTrAPxUsym=UaDOOy1Rsw0-AbzMjnXg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 813 bytes --]
> I did state some reasons previously. Consistent rules for submitters
> of DT bindings and being able to trace history beyond git. Now, I
> guess you aren't changing the rules, but you probably aren't
> requesting people to split DT bindings either? You might not be aware,
> but we also generate a DT only tree with git-filter-branch[1] for
> non-kernel projects to use bindings and dts files. For that, sure they
> will only get the DT binding part of it, but what commit text do they
> get? Finally, DT maintainer acks (which from me is a review really)
> apply to the bindings only. Sometimes I review the drivers, but not
> often. So I would like the git history of my reviews to be accurate in
> terms of what I actually reviewed.
Points taken. Will keep them seperate from now on.
Thanks,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Rob Herring @ 2016-09-24 1:02 UTC (permalink / raw)
To: Wolfram Sang
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman,
linux-i2c@vger.kernel.org, Carlo Caione, linux-amlogic,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20160923232641.GB5683@katana>
On Fri, Sep 23, 2016 at 6:26 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> > I intentionally don't ask people to send me the patches squashed. So,
>> > you will have them seperate in patchwork et al. I only squash them just
>> > before commiting to my tree. That's because I found that when digging
>> > through git history, it is much more convenient to have all the
>> > information in one commit.
>>
>> If git history was the only thing that mattered, then that would be
>> fine. But it is not. Maintainers should apply what's on the list.
>> Period.
>
> Huh? If you would *ask* me to stop squashing, I am listening to reasons.
I did state some reasons previously. Consistent rules for submitters
of DT bindings and being able to trace history beyond git. Now, I
guess you aren't changing the rules, but you probably aren't
requesting people to split DT bindings either? You might not be aware,
but we also generate a DT only tree with git-filter-branch[1] for
non-kernel projects to use bindings and dts files. For that, sure they
will only get the DT binding part of it, but what commit text do they
get? Finally, DT maintainer acks (which from me is a review really)
apply to the bindings only. Sometimes I review the drivers, but not
often. So I would like the git history of my reviews to be accurate in
terms of what I actually reviewed.
> If you want to force arbitrary rules on me, I am not. There are reasons
> where squashing/modifying patches makes more sense compared to forcing
> the author to resend. DTS bindings may not be one, we can discuss that.
> But that rule without allowing exceptions seems impractical to me.
Okay, "period" was a bit much. Exceptions are perfectly fine, we all
do some minor fixups time to time. It just shouldn't be the norm IMO.
Rob
[1] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
^ permalink raw reply
* [PULL REQUEST] i2c for 4.8
From: Wolfram Sang @ 2016-09-23 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-i2c, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
Linus,
I2C has 3 driver bugfixes for you, fixing uninitialized memory pointers
(eg20t), pm/clock imbalance (qup), and a wrongly set cached variable
(pc954x). Please pull.
Thanks,
Wolfram
The following changes since commit 3be7988674ab33565700a37b210f502563d932e6:
Linux 4.8-rc7 (2016-09-18 17:27:41 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current
for you to fetch changes up to 331dcf421c34d227784d07943eb01e4023a42b0a:
i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended (2016-09-22 20:11:14 +0200)
----------------------------------------------------------------
Peter Rosin (1):
i2c: mux: pca954x: retry updating the mux selection on failure
Sudeep Holla (1):
i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended
Yadi.hu (1):
i2c-eg20t: fix race between i2c init and interrupt enable
drivers/i2c/busses/i2c-eg20t.c | 18 +++++++++++-------
drivers/i2c/busses/i2c-qup.c | 3 ++-
drivers/i2c/muxes/i2c-mux-pca954x.c | 2 +-
3 files changed, 14 insertions(+), 9 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Wolfram Sang @ 2016-09-23 23:26 UTC (permalink / raw)
To: Rob Herring
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman,
linux-i2c@vger.kernel.org, Carlo Caione, linux-amlogic,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqKi9Dk5-nF9xFD-89TTUinaGjMv5s1=N2b-Xyu98b+S3w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
> > I intentionally don't ask people to send me the patches squashed. So,
> > you will have them seperate in patchwork et al. I only squash them just
> > before commiting to my tree. That's because I found that when digging
> > through git history, it is much more convenient to have all the
> > information in one commit.
>
> If git history was the only thing that mattered, then that would be
> fine. But it is not. Maintainers should apply what's on the list.
> Period.
Huh? If you would *ask* me to stop squashing, I am listening to reasons.
If you want to force arbitrary rules on me, I am not. There are reasons
where squashing/modifying patches makes more sense compared to forcing
the author to resend. DTS bindings may not be one, we can discuss that.
But that rule without allowing exceptions seems impractical to me.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Rob Herring @ 2016-09-23 23:04 UTC (permalink / raw)
To: Wolfram Sang
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman,
linux-i2c@vger.kernel.org, Carlo Caione, linux-amlogic,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20160923221312.GA5683@katana>
On Fri, Sep 23, 2016 at 5:13 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Fri, Sep 23, 2016 at 10:01:13AM -0500, Rob Herring wrote:
>> On Thu, Sep 15, 2016 at 2:41 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>> > On Wed, Sep 14, 2016 at 11:49:15AM +0200, Jerome Brunet wrote:
>> >> This patchset adds a specific compatible string in the Meson I2C driver
>> >> for the Amlogic Meson gxbb SoC.
>> >>
>> >> Other patch series (pinctrl and device tree) are being sent to complete
>> >> the i2c support on meson gxbb
>> >>
>> >> Neil Armstrong (2):
>> >> i2c: meson: add gxbb compatible string
>> >> dt-bindings: i2c-meson: add gxbb compatible string
>> >
>> > Squashed both patches and applied to for-next, thanks!
>>
>> Please don't squash. We ask people to split DT bindings for a reason
>> being reviews and bindings may not go thru subsystem maintainers in
>> the future. It also makes it harder to find things in the archives or
>> patchwork (as does maintainer fixups of subject lines).
>
> I intentionally don't ask people to send me the patches squashed. So,
> you will have them seperate in patchwork et al. I only squash them just
> before commiting to my tree. That's because I found that when digging
> through git history, it is much more convenient to have all the
> information in one commit.
If git history was the only thing that mattered, then that would be
fine. But it is not. Maintainers should apply what's on the list.
Period. You wouldn't fixup pull requests to make the commit history
more to your liking, would you?
Rob
^ permalink raw reply
* Re: [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Wolfram Sang @ 2016-09-23 22:13 UTC (permalink / raw)
To: Rob Herring
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman,
linux-i2c@vger.kernel.org, Carlo Caione, linux-amlogic,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqKNFzo6RWJO5WOvsyO3e4UTo5Zn48aaDac=+uL_CQWerQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]
On Fri, Sep 23, 2016 at 10:01:13AM -0500, Rob Herring wrote:
> On Thu, Sep 15, 2016 at 2:41 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> > On Wed, Sep 14, 2016 at 11:49:15AM +0200, Jerome Brunet wrote:
> >> This patchset adds a specific compatible string in the Meson I2C driver
> >> for the Amlogic Meson gxbb SoC.
> >>
> >> Other patch series (pinctrl and device tree) are being sent to complete
> >> the i2c support on meson gxbb
> >>
> >> Neil Armstrong (2):
> >> i2c: meson: add gxbb compatible string
> >> dt-bindings: i2c-meson: add gxbb compatible string
> >
> > Squashed both patches and applied to for-next, thanks!
>
> Please don't squash. We ask people to split DT bindings for a reason
> being reviews and bindings may not go thru subsystem maintainers in
> the future. It also makes it harder to find things in the archives or
> patchwork (as does maintainer fixups of subject lines).
I intentionally don't ask people to send me the patches squashed. So,
you will have them seperate in patchwork et al. I only squash them just
before commiting to my tree. That's because I found that when digging
through git history, it is much more convenient to have all the
information in one commit.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 4/4] i2c-dev: Adjust checks for null pointers in three functions
From: SF Markus Elfring @ 2016-09-23 19:47 UTC (permalink / raw)
To: linux-i2c, Wolfram Sang; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <cedc3865-a884-a10e-6c93-0163fd36af92@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 23 Sep 2016 21:30:20 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script "checkpatch.pl" can point information out like the following.
Comparison to NULL could be written !…
Thus fix the affected source code places.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/i2c/i2c-dev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index 7d3e3ca..8f7eddd 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -147,7 +147,7 @@ static ssize_t i2cdev_read(struct file *file, char __user *buf, size_t count,
count = 8192;
tmp = kmalloc(count, GFP_KERNEL);
- if (tmp == NULL)
+ if (!tmp)
return -ENOMEM;
pr_debug("i2c-dev: i2c-%d reading %zu bytes.\n",
@@ -263,7 +263,7 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client *client,
data_ptrs = kmalloc_array(rdwr_arg.nmsgs,
sizeof(*data_ptrs),
GFP_KERNEL);
- if (data_ptrs == NULL) {
+ if (!data_ptrs) {
kfree(rdwr_pa);
return -ENOMEM;
}
@@ -374,7 +374,7 @@ static noinline int i2cdev_ioctl_smbus(struct i2c_client *client,
client->flags, data_arg.read_write,
data_arg.command, data_arg.size, NULL);
- if (data_arg.data == NULL) {
+ if (!data_arg.data) {
dev_dbg(&client->adapter->dev,
"data is NULL pointer in ioctl I2C_SMBUS.\n");
return -EINVAL;
--
2.10.0
^ permalink raw reply related
* [PATCH 3/4] i2c-dev: Rename jump labels in i2cdev_attach_adapter()
From: SF Markus Elfring @ 2016-09-23 19:46 UTC (permalink / raw)
To: linux-i2c, Wolfram Sang; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <cedc3865-a884-a10e-6c93-0163fd36af92@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 23 Sep 2016 21:21:39 +0200
Adjust jump labels according to the current Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/i2c/i2c-dev.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index a6e35ce..7d3e3ca 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -555,7 +555,7 @@ static int i2cdev_attach_adapter(struct device *dev, void *dummy)
i2c_dev->cdev.owner = THIS_MODULE;
res = cdev_add(&i2c_dev->cdev, MKDEV(I2C_MAJOR, adap->nr), 1);
if (res)
- goto error_cdev;
+ goto put_i2c;
/* register this i2c device with the driver core */
i2c_dev->dev = device_create(i2c_dev_class, &adap->dev,
@@ -563,15 +563,15 @@ static int i2cdev_attach_adapter(struct device *dev, void *dummy)
"i2c-%d", adap->nr);
if (IS_ERR(i2c_dev->dev)) {
res = PTR_ERR(i2c_dev->dev);
- goto error;
+ goto delete_cdev;
}
pr_debug("i2c-dev: adapter [%s] registered as minor %d\n",
adap->name, adap->nr);
return 0;
-error:
+delete_cdev:
cdev_del(&i2c_dev->cdev);
-error_cdev:
+put_i2c:
put_i2c_dev(i2c_dev);
return res;
}
--
2.10.0
^ permalink raw reply related
* [PATCH 2/4] i2c-dev: Improve another size determination in i2cdev_ioctl_rdwr()
From: SF Markus Elfring @ 2016-09-23 19:45 UTC (permalink / raw)
To: linux-i2c, Wolfram Sang; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <cedc3865-a884-a10e-6c93-0163fd36af92@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 23 Sep 2016 20:45:40 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/i2c/i2c-dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index 6d8226d..a6e35ce 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -256,7 +256,7 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client *client,
return -EINVAL;
rdwr_pa = memdup_user(rdwr_arg.msgs,
- rdwr_arg.nmsgs * sizeof(struct i2c_msg));
+ rdwr_arg.nmsgs * sizeof(*rdwr_pa));
if (IS_ERR(rdwr_pa))
return PTR_ERR(rdwr_pa);
--
2.10.0
^ permalink raw reply related
* Re: [PATCH v5 3/6] Documentation: Add sbs-manager device tree node documentation
From: Rob Herring @ 2016-09-23 19:44 UTC (permalink / raw)
To: Phil Reid
Cc: wsa, mark.rutland, sre, andrea.merello, karl-heinz, arnd,
linux-i2c, devicetree, linux-pm
In-Reply-To: <1474447274-90821-4-git-send-email-preid@electromag.com.au>
On Wed, Sep 21, 2016 at 04:41:11PM +0800, Phil Reid wrote:
> From: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
>
> This patch adds device tree documentation for the sbs-manager
>
> Reviewed-by: Phil Reid <preid@electromag.com.au>
> Signed-off-by: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
> Signed-off-by: Phil Reid <preid@electromag.com.au>
> ---
> .../bindings/power/supply/sbs,sbs-manager.txt | 62 ++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt
>
> diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt
> new file mode 100644
> index 0000000..2a04b30
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.txt
> @@ -0,0 +1,62 @@
> +Binding for sbs-manager
> +
> +Required properties:
> +- compatible: should be "lltc,ltc1760" or use "sbs,sbs-manager" as fallback.
> +- reg: integer, i2c address of the device. Should be <0xa>.
> +Optional properties:
> +- gpio-controller: Marks the port as GPIO controller.
> + See "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
> +- #gpio-cells: Should be <2>. The first cell is the pin number, the second cell
> + is used to specify optional parameters:
> + See "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
Is this leftover from the last version? It doesn't look like you are
using any GPIOs in the example.
> +
> +From OS view the device is basically an i2c-mux used to communicate with up to
> +four smart battery devices at address 0xb. The driver actually implements this
> +behaviour. So standard i2c-mux nodes can be used to register up to four slave
> +batteries. See Documentation/devicetree/bindings/i2c/i2c-mux.txt for more
> +information on i2c-mux nodes. Channels will be numerated starting from 1 to 4.
> +
> +Example:
> +
> +batman@0a {
> + compatible = "lltc,ltc1760";
> + reg = <0x0a>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + i2c@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + battery@b {
> + compatible = "ti,bq2060", "sbs,sbs-battery";
> + reg = <0xb>;
> + };
> + };
> +
> + i2c@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <2>;
> +
> + battery@b {
> + compatible = "ti,bq2060", "sbs,sbs-battery";
> + reg = <0xb>;
> + };
> + };
> +
> + i2c@3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <3>;
> +
> + battery@b {
> + compatible = "ti,bq2060", "sbs,sbs-battery";
> + reg = <0xb>;
> + };
> + };
> +};
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/4] i2c-dev: Use kmalloc_array() in i2cdev_ioctl_rdwr()
From: SF Markus Elfring @ 2016-09-23 19:44 UTC (permalink / raw)
To: linux-i2c, Wolfram Sang; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <cedc3865-a884-a10e-6c93-0163fd36af92@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 23 Sep 2016 20:30:07 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data type by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/i2c/i2c-dev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index 66f323f..6d8226d 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -260,7 +260,9 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client *client,
if (IS_ERR(rdwr_pa))
return PTR_ERR(rdwr_pa);
- data_ptrs = kmalloc(rdwr_arg.nmsgs * sizeof(u8 __user *), GFP_KERNEL);
+ data_ptrs = kmalloc_array(rdwr_arg.nmsgs,
+ sizeof(*data_ptrs),
+ GFP_KERNEL);
if (data_ptrs == NULL) {
kfree(rdwr_pa);
return -ENOMEM;
--
2.10.0
^ permalink raw reply related
* [PATCH 0/4] i2c-dev: Fine-tuning for four function implementations
From: SF Markus Elfring @ 2016-09-23 19:42 UTC (permalink / raw)
To: linux-i2c, Wolfram Sang; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <566ABCD9.1060404@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 23 Sep 2016 21:38:21 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (4):
Use kmalloc_array() in i2cdev_ioctl_rdwr()
Improve another size determination in i2cdev_ioctl_rdwr()
Rename jump labels in i2cdev_attach_adapter()
Adjust checks for null pointers in three functions
drivers/i2c/i2c-dev.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--
2.10.0
^ permalink raw reply
* Re: [PATCH v5 1/6] I2C: i2c-smbus: add device tree support
From: Rob Herring @ 2016-09-23 19:42 UTC (permalink / raw)
To: Phil Reid
Cc: wsa, mark.rutland, sre, andrea.merello, karl-heinz, arnd,
linux-i2c, devicetree, linux-pm
In-Reply-To: <1474447274-90821-2-git-send-email-preid@electromag.com.au>
On Wed, Sep 21, 2016 at 04:41:09PM +0800, Phil Reid wrote:
> From: Andrea Merello <andrea.merello@gmail.com>
>
> According to Documentation/i2c/smbus-protocol, a smbus controller driver
> that wants to hook-in smbus extensions support, can call
> i2c_setup_smbus_alert(). There are very few drivers that are currently
> doing this.
>
> However the i2c-smbus module can also work with any
> smbus-extensions-unaware I2C controller, as long as we provide an extra
> IRQ line connected to the I2C bus ALARM signal.
>
> This patch makes it possible to go this way via DT. Note that the DT node
> will indeed describe a (little) piece of HW, that is the routing of the
> ALARM signal to an IRQ line (so it seems a fair DT use to me, but RFC).
>
> Note that AFAICT, by design, i2c-smbus module pretends to be an I2C slave
> with address 0x0C (that is the alarm response address), and IMHO this is
> quite consistent with usage in the DT as a I2C child node.
>
> Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
> Signed-off-by: Phil Reid <preid@electromag.com.au>
> ---
> Documentation/devicetree/bindings/i2c/i2c-smbus.txt | 20 ++++++++++++++++++++
> drivers/i2c/i2c-smbus.c | 20 +++++++++++++++-----
> 2 files changed, 35 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-smbus.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-smbus.txt b/Documentation/devicetree/bindings/i2c/i2c-smbus.txt
> new file mode 100644
> index 0000000..da83127
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-smbus.txt
> @@ -0,0 +1,20 @@
> +* i2c-smbus extensions
> +
> +Required Properties:
> + - compatible: Must contain "smbus_alert"
> + - interrupts: The irq line for smbus ALERT signal
> + - reg: I2C slave address. Set to 0x0C (alert response address).
This is not right. The 0xC address is special, not an actual device
address. The bindings should just have the actual device's compatible
string and address.
> +
> +Note: The i2c-smbus module registers itself as a slave I2C device. Whenever
> +a smbus controller directly support smbus extensions (and its driver supports
> +this), there is no need to add anything special to the DT. Otherwise, for using
> +i2c-smbus with any smbus-extensions-unaware I2C controllers, you need to
> +route the smbus ALARM signal to an extra IRQ line, thus you need to describe
> +this in the DT.
Now, I guess what you need in the kernel is a common handler for
SMBALERT# and to know which interrupt line is SMBALERT#.
The drivers should know this. A given h/w device will or will not handle
the "SMB Alert Response Address". So the drivers should register their
interrupt with the I2C/SMBus core.
If a controller handles the SMBALERT, then it should make itself an
interrupt controller and that's what slave devices 'interrupts' property
will point to.
Rob
^ permalink raw reply
* Re: [PATCH v3 2/2] i2c: aspeed: added documentation for Aspeed I2C driver
From: Rob Herring @ 2016-09-23 18:02 UTC (permalink / raw)
To: Brendan Higgins
Cc: wsa-z923LK4zBo2bacvFa/9K2g, mark.rutland-5wv7dgnIgG8,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
openbmc-uLR06cmDAlY/bJ5BZ2RsiQ, joel-U3u1mxZcP9KHXe+LvDLADg,
jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <1474327414-651-2-git-send-email-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Mon, Sep 19, 2016 at 04:23:34PM -0700, Brendan Higgins wrote:
> Added device tree binding documentation for Aspeed I2C controller and
> busses.
>
> Signed-off-by: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
> Changes for v2:
> - None
> Changes for v3:
> - Removed reference to "bus" device tree param
> ---
> .../devicetree/bindings/i2c/i2c-aspeed.txt | 61 ++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH resend v3] i2c: hibvt: add Hisilicon BVT I2C controller driver
From: Rob Herring @ 2016-09-23 17:49 UTC (permalink / raw)
To: Pan Wen
Cc: wsa, mark.rutland, linux-i2c, devicetree, linux-kernel,
howell.yang, xuejiancheng, jalen.hsu, lvkuanliang, suwenping,
raojun, kevin.lixu
In-Reply-To: <1474284590-12652-1-git-send-email-wenpan@hisilicon.com>
On Mon, Sep 19, 2016 at 07:29:50PM +0800, Pan Wen wrote:
> add Hisilicon BVT I2C controller driver support.
>
> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
> ---
> .../devicetree/bindings/i2c/i2c-hibvt.txt | 24 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-hibvt.c | 737 +++++++++++++++++++++
> 4 files changed, 772 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-hibvt.txt
> create mode 100644 drivers/i2c/busses/i2c-hibvt.c
^ permalink raw reply
* RE: [patch v5] i2c: mux: mellanox: add driver
From: Vadim Pasternak @ 2016-09-23 11:57 UTC (permalink / raw)
To: Peter Rosin, wsa@the-dreams.de
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
jiri@resnulli.us, Michael Shych
In-Reply-To: <c530714e-b61e-8a38-a054-9d335f0e8a71@axentia.se>
> -----Original Message-----
> From: Peter Rosin [mailto:peda@axentia.se]
> Sent: Friday, September 23, 2016 12:36 PM
> To: Vadim Pasternak <vadimp@mellanox.com>; wsa@the-dreams.de
> Cc: linux-i2c@vger.kernel.org; linux-kernel@vger.kernel.org; jiri@resnulli.us;
> Michael Shych <michaelsh@mellanox.com>
> Subject: Re: [patch v5] i2c: mux: mellanox: add driver
>
> On 2016-09-13 22:37, vadimp@mellanox.com wrote:
> > From: Vadim Pasternak <vadimp@mellanox.com>
> >
> > This driver allows I2C routing controlled through CPLD select
> > registers on a wide range of Mellanox systems (CPLD Lattice device).
> > MUX selection is provided by digital and analog HW. Analog part is not
> > under SW control.
> > Digital part is under CPLD control (channel selection/de-selection).
> >
> > Connectivity schema.
> > i2c-mlxcpld Digital Analog
> > driver
> > *--------* * -> mux1 (virt bus2) -> mux ->|
> > | I2CLPC | i2c physical * -> mux2 (virt bus3) -> mux ->|
> > | bridge | bus 1 *---------* |
> > | logic |---------------------> * mux reg * |
> > | in CPLD| *---------* |
> > *--------* i2c-mux-mlxpcld ^ * -> muxn (virt busn) -> mux ->|
> > | driver | |
> > | *---------------* | Devices
> > | * CPLD (i2c bus)* select |
> > | * registers for *--------*
> > | * mux selection * deselect
> > | *---------------*
> > | |
> > <--------> <----------->
> > i2c cntrl Board cntrl reg
> > reg space space (mux select,
> > IO, LED, WD, info)
>
> Hmm, I'm wondering about the above schematics, which seems a bit overly
> complex. I mean, it's not relevant to this driver how the I2CLPC bridge logic in
> the CPLD is controlled. Particularly so since it does not need to be a this
> particular i2c adapter that is muxed.
>
> But what I'm really wondering is if this mux can mux same other bus than is used
> to control the mux. I.e. is it possible to do something like this:
>
> .---. .-------------.
> | | | |-- i2c2 --
> | l |-- i2c0 --| mlxcpld mux |
> | i | | |-- i2c3 --
> | n | '-------------'
> | u | |
> | x |-- i2c1 ---------'
> | |
> '---'
>
> Or is it always as below, with the mux being controlled from the same i2c bus it
> muxes?
>
> .---. .-------------.
> | l | | |-- i2c1 --
> | i |-- i2c0 --+--| mlxcpld mux |
> | n | | | |-- i2c2 --
> | u | | '-------------'
> | x | | |
> '---' '---------'
>
Hi Peter,
Thank you very much for this and all previous feedbacks.
Yes, it is not coupled with I2CLPC bridge logic.
When I sent my initial patch, it was marked as 1/2, while 1/1 was patch for i2c-mlxcpld controller.
So, maybe my comment here is redundant I can make it simpler.
Actual description you provided is better.
Would you like me to submit patch with this modification only?
Just as an example to show how we are going to use this driver.
This is x86 systems, when we do have LPCI2C as controller (we have on these systems management CPLD attached to LPC on carrier board and I2C attached CLPD on switch board:
.---. .-------------.
| l | | |-- i2cx1 -- i2cy8
| i |-- i2c1 --+--| mlxcpld mux |
| n | | | |-- i2y1 -- i2cy8
| u | | '-------------'
| x | | |
'---' '---------'
I2C CPLD is attached to bus 1 at 0x62, and has register 0x81 - 0x85 for access to 4 or 5 banks of QSFP ports (each bank of 8).
This is coming systems equipped with BMC Aspeed 2520 SoC ARM11 based (by the way this driver now also in review process):
.---. .-------------.
| l | | |-- i2cx1 -- i2cy8
| i |-- i2cn --+--| mlxcpld mux |
| n | | | |-- i2y1 -- i2cy8
| u | | '-------------'
| x | | |
'---' '---------
I2C CPLD is attached to bus n (SoC equipped with 14 I2C busses) at 0x62, and has register 0xz1 - 0xz1 for access to 4 or 5 banks of QSFP ports (each bank of 8).
Cheers,
Vadim.
> Cheers,
> Peter
^ permalink raw reply
* Re: [patch v5] i2c: mux: mellanox: add driver
From: Peter Rosin @ 2016-09-23 9:36 UTC (permalink / raw)
To: vadimp, wsa; +Cc: linux-i2c, linux-kernel, jiri, Michael Shych
In-Reply-To: <1473799071-12830-1-git-send-email-vadimp@mellanox.com>
On 2016-09-13 22:37, vadimp@mellanox.com wrote:
> From: Vadim Pasternak <vadimp@mellanox.com>
>
> This driver allows I2C routing controlled through CPLD select registers on
> a wide range of Mellanox systems (CPLD Lattice device).
> MUX selection is provided by digital and analog HW. Analog part is not
> under SW control.
> Digital part is under CPLD control (channel selection/de-selection).
>
> Connectivity schema.
> i2c-mlxcpld Digital Analog
> driver
> *--------* * -> mux1 (virt bus2) -> mux ->|
> | I2CLPC | i2c physical * -> mux2 (virt bus3) -> mux ->|
> | bridge | bus 1 *---------* |
> | logic |---------------------> * mux reg * |
> | in CPLD| *---------* |
> *--------* i2c-mux-mlxpcld ^ * -> muxn (virt busn) -> mux ->|
> | driver | |
> | *---------------* | Devices
> | * CPLD (i2c bus)* select |
> | * registers for *--------*
> | * mux selection * deselect
> | *---------------*
> | |
> <--------> <----------->
> i2c cntrl Board cntrl reg
> reg space space (mux select,
> IO, LED, WD, info)
Hmm, I'm wondering about the above schematics, which seems a bit
overly complex. I mean, it's not relevant to this driver how the
I2CLPC bridge logic in the CPLD is controlled. Particularly so
since it does not need to be a this particular i2c adapter that
is muxed.
But what I'm really wondering is if this mux can mux same other
bus than is used to control the mux. I.e. is it possible to do
something like this:
.---. .-------------.
| | | |-- i2c2 --
| l |-- i2c0 --| mlxcpld mux |
| i | | |-- i2c3 --
| n | '-------------'
| u | |
| x |-- i2c1 ---------'
| |
'---'
Or is it always as below, with the mux being controlled from
the same i2c bus it muxes?
.---. .-------------.
| l | | |-- i2c1 --
| i |-- i2c0 --+--| mlxcpld mux |
| n | | | |-- i2c2 --
| u | | '-------------'
| x | | |
'---' '---------'
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Rob Herring @ 2016-09-23 15:01 UTC (permalink / raw)
To: Wolfram Sang
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman,
linux-i2c@vger.kernel.org, Carlo Caione, linux-amlogic,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20160915194146.GB7863@katana>
On Thu, Sep 15, 2016 at 2:41 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Wed, Sep 14, 2016 at 11:49:15AM +0200, Jerome Brunet wrote:
>> This patchset adds a specific compatible string in the Meson I2C driver
>> for the Amlogic Meson gxbb SoC.
>>
>> Other patch series (pinctrl and device tree) are being sent to complete
>> the i2c support on meson gxbb
>>
>> Neil Armstrong (2):
>> i2c: meson: add gxbb compatible string
>> dt-bindings: i2c-meson: add gxbb compatible string
>
> Squashed both patches and applied to for-next, thanks!
Please don't squash. We ask people to split DT bindings for a reason
being reviews and bindings may not go thru subsystem maintainers in
the future. It also makes it harder to find things in the archives or
patchwork (as does maintainer fixups of subject lines).
Rob
^ permalink raw reply
* [PATCH v2] i2c: uniphier-f: fix misdetection of incomplete STOP condition
From: Masahiro Yamada @ 2016-09-23 13:34 UTC (permalink / raw)
To: linux-i2c; +Cc: Masahiro Yamada, linux-arm-kernel, linux-kernel, Wolfram Sang
Currently, the status register FI2C_SR is checked immediately after
a STOP condition is issued in case of the deferred STOP condition.
It takes typically 5-10 usec until the corresponding bits in the
register are set, so the error check for "stop condition was not
completed" is very likely to be false positive.
Add wait code to relax the status register check.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- use readl_poll_timeout()
drivers/i2c/busses/i2c-uniphier-f.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c b/drivers/i2c/busses/i2c-uniphier-f.c
index 829df91..db9105e 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -14,6 +14,7 @@
#include <linux/clk.h>
#include <linux/i2c.h>
+#include <linux/iopoll.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/module.h>
@@ -348,14 +349,19 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter *adap,
dev_dbg(&adap->dev, "complete\n");
if (unlikely(priv->flags & UNIPHIER_FI2C_DEFER_STOP_COMP)) {
- u32 status = readl(priv->membase + UNIPHIER_FI2C_SR);
-
- if (!(status & UNIPHIER_FI2C_SR_STS) ||
- status & UNIPHIER_FI2C_SR_BB) {
+ u32 status;
+ int ret;
+
+ ret = readl_poll_timeout(priv->membase + UNIPHIER_FI2C_SR,
+ status,
+ (status & UNIPHIER_FI2C_SR_STS) &&
+ !(status & UNIPHIER_FI2C_SR_BB),
+ 1, 20);
+ if (ret) {
dev_err(&adap->dev,
"stop condition was not completed.\n");
uniphier_fi2c_recover(priv);
- return -EBUSY;
+ return ret;
}
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] i2c: uniphier-f: fix misdetection of incomplete STOP condition
From: Masahiro Yamada @ 2016-09-23 13:33 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-i2c, linux-arm-kernel, Linux Kernel Mailing List
In-Reply-To: <20160923121245.GA1580@katana>
Hi Wolfram,
2016-09-23 21:12 GMT+09:00 Wolfram Sang <wsa@the-dreams.de>:
> On Fri, Sep 23, 2016 at 09:04:01PM +0900, Masahiro Yamada wrote:
>> Currently, the status register FI2C_SR is checked immediately after
>> a STOP condition is issued in case of the deferred STOP condition.
>> It takes typically 5-10 usec until the corresponding bits in the
>> register are set, so the error check for "stop condition was not
>> completed" is very likely to be false positive.
>>
>> Add wait code to relax the status register check.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> Use readl_poll_timeout?
>
Yes, thanks for your advice!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH] i2c: uniphier-f: fix misdetection of incomplete STOP condition
From: Wolfram Sang @ 2016-09-23 12:12 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: linux-i2c, linux-arm-kernel, linux-kernel
In-Reply-To: <1474632241-10440-1-git-send-email-yamada.masahiro@socionext.com>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
On Fri, Sep 23, 2016 at 09:04:01PM +0900, Masahiro Yamada wrote:
> Currently, the status register FI2C_SR is checked immediately after
> a STOP condition is issued in case of the deferred STOP condition.
> It takes typically 5-10 usec until the corresponding bits in the
> register are set, so the error check for "stop condition was not
> completed" is very likely to be false positive.
>
> Add wait code to relax the status register check.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Use readl_poll_timeout?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] i2c: uniphier-f: fix misdetection of incomplete STOP condition
From: Masahiro Yamada @ 2016-09-23 12:04 UTC (permalink / raw)
To: linux-i2c; +Cc: Masahiro Yamada, linux-arm-kernel, linux-kernel, Wolfram Sang
Currently, the status register FI2C_SR is checked immediately after
a STOP condition is issued in case of the deferred STOP condition.
It takes typically 5-10 usec until the corresponding bits in the
register are set, so the error check for "stop condition was not
completed" is very likely to be false positive.
Add wait code to relax the status register check.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/i2c/busses/i2c-uniphier-f.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c b/drivers/i2c/busses/i2c-uniphier-f.c
index 829df91..e5886eb 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -13,6 +13,7 @@
*/
#include <linux/clk.h>
+#include <linux/delay.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/io.h>
@@ -348,10 +349,19 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter *adap,
dev_dbg(&adap->dev, "complete\n");
if (unlikely(priv->flags & UNIPHIER_FI2C_DEFER_STOP_COMP)) {
- u32 status = readl(priv->membase + UNIPHIER_FI2C_SR);
+ time_left = 20;
- if (!(status & UNIPHIER_FI2C_SR_STS) ||
- status & UNIPHIER_FI2C_SR_BB) {
+ while (--time_left) {
+ u32 status = readl(priv->membase + UNIPHIER_FI2C_SR);
+
+ if ((status & UNIPHIER_FI2C_SR_STS) &&
+ !(status & UNIPHIER_FI2C_SR_BB))
+ break;
+
+ udelay(1);
+ }
+
+ if (!time_left) {
dev_err(&adap->dev,
"stop condition was not completed.\n");
uniphier_fi2c_recover(priv);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] i2c: octeon: thunderx: Check bus state before starting a transaction
From: Jan Glauber @ 2016-09-23 9:40 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-kernel, linux-i2c, Dmitry Bazhenov, Jan Glauber
In-Reply-To: <cover.1474565039.git.jglauber@cavium.com>
Add an additional status check before starting a transaction. If the
check fails wait for some time to tolerate multi-master mode. After the
timeout expires trigger the recovery.
Signed-off-by: Jan Glauber <jglauber@cavium.com>
---
drivers/i2c/busses/i2c-octeon-core.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/i2c/busses/i2c-octeon-core.c b/drivers/i2c/busses/i2c-octeon-core.c
index 5e63b17..f526511 100644
--- a/drivers/i2c/busses/i2c-octeon-core.c
+++ b/drivers/i2c/busses/i2c-octeon-core.c
@@ -630,6 +630,31 @@ static int octeon_i2c_hlc_comp_write(struct octeon_i2c *i2c, struct i2c_msg *msg
return ret;
}
+static int octeon_i2c_check_bus(struct octeon_i2c *i2c)
+{
+ u64 end = get_jiffies_64() + i2c->adap.timeout;
+ int stat, lines;
+
+ while (time_before64(get_jiffies_64(), end)) {
+ stat = octeon_i2c_stat_read(i2c);
+
+ /* get I2C line state */
+ lines = octeon_i2c_read_int(i2c) & (TWSI_INT_SCL | TWSI_INT_SDA);
+
+ if (stat == STAT_IDLE && lines == (TWSI_INT_SCL | TWSI_INT_SDA))
+ return 0;
+
+ if (stat == STAT_LOST_ARB_38 || stat == STAT_LOST_ARB_68 ||
+ stat == STAT_LOST_ARB_78 || stat == STAT_LOST_ARB_B0)
+ break;
+
+ usleep_range(I2C_OCTEON_EVENT_WAIT / 2, I2C_OCTEON_EVENT_WAIT);
+ }
+
+ /* bus check failed, try to recover */
+ return octeon_i2c_recovery(i2c);
+}
+
/**
* octeon_i2c_xfer - The driver's master_xfer function
* @adap: Pointer to the i2c_adapter structure
@@ -643,6 +668,10 @@ int octeon_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
struct octeon_i2c *i2c = i2c_get_adapdata(adap);
int i, ret = 0;
+ ret = octeon_i2c_check_bus(i2c);
+ if (ret)
+ goto out;
+
if (num == 1) {
if (msgs[0].len > 0 && msgs[0].len <= 8) {
if (msgs[0].flags & I2C_M_RD)
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/2] i2c: octeon: thunderx: Recovery fixes and improvements
From: Jan Glauber @ 2016-09-23 9:40 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-kernel, linux-i2c, Dmitry Bazhenov, Jan Glauber
Hi Wolfram,
here are the remaining two patches with iopoll.h usage and a timed wait
before entering the recovery on a failed bus check.
thanks,
Jan
---------------------
Jan Glauber (2):
i2c: octeon: thunderx: Check bus state before starting a transaction
i2c: octeon: thunderx: Limit register access retries
drivers/i2c/busses/i2c-octeon-core.c | 33 ++++++++++++++++++++++++++++++++-
drivers/i2c/busses/i2c-octeon-core.h | 27 ++++++++++++++++-----------
2 files changed, 48 insertions(+), 12 deletions(-)
--
1.9.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox