Re: [PATCH] i2c: rcar: fix a possible NULL dereference

2015-11-12 Thread Uwe Kleine-König
Hello Wolfram, On Thu, Nov 12, 2015 at 08:52:38AM +0100, Wolfram Sang wrote: > On Thu, Nov 12, 2015 at 08:44:47AM +0100, Uwe Kleine-König wrote: > > Other than that, the NULL pointer dereference should only happen if the > > device was bound using the driver name. That might be worth to point out

Re: [PATCH] i2c: rcar: fix a possible NULL dereference

2015-11-12 Thread Wolfram Sang
On Thu, Nov 12, 2015 at 09:09:26AM +0100, Uwe Kleine-König wrote: > Hello Wolfram, > > On Thu, Nov 12, 2015 at 08:52:38AM +0100, Wolfram Sang wrote: > > On Thu, Nov 12, 2015 at 08:44:47AM +0100, Uwe Kleine-König wrote: > > > Other than that, the NULL pointer dereference should only happen if the >

Re: [PATCH] i2c: rcar: fix a possible NULL dereference

2015-11-12 Thread Uwe Kleine-König
On Thu, Nov 12, 2015 at 09:48:37AM +0100, Wolfram Sang wrote: > On Thu, Nov 12, 2015 at 09:09:26AM +0100, Uwe Kleine-König wrote: > > Hello Wolfram, > > > > On Thu, Nov 12, 2015 at 08:52:38AM +0100, Wolfram Sang wrote: > > > On Thu, Nov 12, 2015 at 08:44:47AM +0100, Uwe Kleine-König wrote: > > > >

Re: [PATCH] i2c: rcar: fix a possible NULL dereference

2015-11-12 Thread Wolfram Sang
> Try adding the following to a device tree: > > i2c-rcar { > > } "Better safe than sorry" won again ;) signature.asc Description: Digital signature

Re: [PATCH] i2c: tegra: fix a possible NULL dereference

2015-11-12 Thread Thierry Reding
On Thu, Nov 12, 2015 at 08:26:03AM +0100, LABBE Corentin wrote: > of_match_device could return NULL, and so cause a NULL pointer No. There is no way that of_match_device() can ever fail. The driver core uses the same table to match the OF device to the driver, so the only case where of_match_devic

Re: [PATCH] i2c: tegra: fix a possible NULL dereference

2015-11-12 Thread LABBE Corentin
On Thu, Nov 12, 2015 at 01:29:23PM +0100, Thierry Reding wrote: > On Thu, Nov 12, 2015 at 08:26:03AM +0100, LABBE Corentin wrote: > > of_match_device could return NULL, and so cause a NULL pointer > > No. There is no way that of_match_device() can ever fail. The driver > core uses the same table t

Re: [PATCH] i2c: tegra: fix a possible NULL dereference

2015-11-12 Thread Thierry Reding
On Thu, Nov 12, 2015 at 01:54:22PM +0100, LABBE Corentin wrote: > On Thu, Nov 12, 2015 at 01:29:23PM +0100, Thierry Reding wrote: > > On Thu, Nov 12, 2015 at 08:26:03AM +0100, LABBE Corentin wrote: > > > of_match_device could return NULL, and so cause a NULL pointer > > > > No. There is no way tha

Re: [PATCH] i2c: tegra: fix a possible NULL dereference

2015-11-12 Thread Jon Hunter
On 12/11/15 12:29, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Thu, Nov 12, 2015 at 08:26:03AM +0100, LABBE Corentin wrote: >> of_match_device could return NULL, and so cause a NULL pointer > > No. There is no way that of_match_device() can ever fail. The driver > core uses the

[PATCH] i2c: core: fix wakeup irq parsing

2015-11-12 Thread Grygorii Strashko
This patch fixes obvious copy-past error in wake up irq parsing code which leads to the fact that dev_pm_set_wake_irq() will be called with wrong IRQ number when "wakeup" IRQ is not defined in DT. Cc: Dmitry Torokhov Cc: Felipe Balbi Cc: # v4.3 Fixes: 3fffd1283927 ("i2c: allow specifying separa

Re: [PATCH] i2c: tegra: fix a possible NULL dereference

2015-11-12 Thread Uwe Kleine-König
On Thu, Nov 12, 2015 at 02:28:37PM +0100, Thierry Reding wrote: > On Thu, Nov 12, 2015 at 01:54:22PM +0100, LABBE Corentin wrote: > > On Thu, Nov 12, 2015 at 01:29:23PM +0100, Thierry Reding wrote: > > > On Thu, Nov 12, 2015 at 08:26:03AM +0100, LABBE Corentin wrote: > > > > of_match_device could r

Re: [PATCH] i2c: tegra: fix a possible NULL dereference

2015-11-12 Thread Thierry Reding
On Thu, Nov 12, 2015 at 02:45:20PM +0100, Uwe Kleine-König wrote: > On Thu, Nov 12, 2015 at 02:28:37PM +0100, Thierry Reding wrote: > > On Thu, Nov 12, 2015 at 01:54:22PM +0100, LABBE Corentin wrote: > > > On Thu, Nov 12, 2015 at 01:29:23PM +0100, Thierry Reding wrote: > > > > On Thu, Nov 12, 2015

Re: [PATCH] i2c: tegra: fix a possible NULL dereference

2015-11-12 Thread Thierry Reding
On Thu, Nov 12, 2015 at 01:40:56PM +, Jon Hunter wrote: > > On 12/11/15 12:29, Thierry Reding wrote: > > * PGP Signed by an unknown key > > > > On Thu, Nov 12, 2015 at 08:26:03AM +0100, LABBE Corentin wrote: > >> of_match_device could return NULL, and so cause a NULL pointer > > > > No. Ther

[PATCH v2 01/10] i2c: rcar: make sure clocks are on when doing clock calculation

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang When calculating the bus speed, the clock should be on, of course. Most bootloaders left them on, so this went unnoticed so far. Move the ioremapping out of this clock-enabled-block and prepare for adding hw initialization there, too. Reported-by: Laurent Pinchart Reported-b

[PATCH v2 00/10] i2c: rcar: tackle race conditions in the driver

2015-11-12 Thread Wolfram Sang
Hello RCar Fans! So, here is V2 of this series. Thanks to Geert's MSTP clock manipulation series, I could finally reproduce something which looks like the issues Laurent was seeing with his Koelsch board. The outcome is Patch 1/10 which fixes also issues reported by Morimoto-san using a Salvator b

[PATCH v2 02/10] i2c: rcar: rework hw init

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang We don't need to init HW before every transfer since we know the HW state then. HW init at probe time is enough. While here, add setting the clock register which belongs to init HW. Also, set MDBS bit since not setting it is prohibited according to the manual. Signed-off-by: W

[PATCH v2 04/10] i2c: rcar: remove spinlock

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang After making sure to reinit the HW and clear interrupts in the timeout case, we know that interrupts are always disabled in the sections protected by the spinlock. Thus, we can simply remove it which is a preparation for further refactoring. While here, rename the timeout varia

[PATCH v2 05/10] i2c: rcar: refactor setup of a msg

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang We want to reuse this function later. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-rcar.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c index 0f2dc74ab8bcc1..4bd3099

[PATCH v2 07/10] i2c: rcar: don't issue stop when HW does it automatically

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang The manual says (55.4.8.6) that HW does automatically send STOP after NACK was received. My measuerments confirm that. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-rcar.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c

[PATCH v2 06/10] i2c: rcar: init new messages in irq

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang Setting up new messages was done in process context while handling a message was in interrupt context. Because of the HW design, this IP core is sensitive to timing, so the context switches were too expensive. Move this setup to interrupt context as well. In my test setup, thi

[PATCH v2 03/10] i2c: rcar: remove unused IOERROR state

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-rcar.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c index efc8de6cc8a2f9..746406923a5825 100644 --- a/drivers/i2c/busses/i2c-rcar.c +++ b/drivers/i

[PATCH v2 08/10] i2c: rcar: check master irqs before slave irqs

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang Due to the HW design, master IRQs are timing critical, so give them precedence over slave IRQ. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-rcar.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/i2c/busses/i2c-rcar.c b/driv

[PATCH v2 10/10] i2c: rcar: clean up after refactoring

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang Update the comments to match current behaviour. Shorten some comments. Update copyrights. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-rcar.c | 32 +--- 1 file changed, 9 insertions(+), 23 deletions(-) diff --git a/drivers/i2c/busses/i2

[PATCH v2 09/10] i2c: rcar: revoke START request early

2015-11-12 Thread Wolfram Sang
From: Wolfram Sang If we don't clear START generation as soon as possible, it may cause another message to be generated, e.g. when receiving NACK in address phase. To keep the race window as small as possible, we clear it right at the beginning of the interrupt. We don't need any checks since we

Re: [PATCH] i2c: tegra: fix a possible NULL dereference

2015-11-12 Thread LABBE Corentin
On Thu, Nov 12, 2015 at 02:55:00PM +0100, Thierry Reding wrote: > On Thu, Nov 12, 2015 at 02:45:20PM +0100, Uwe Kleine-König wrote: > > On Thu, Nov 12, 2015 at 02:28:37PM +0100, Thierry Reding wrote: > > > On Thu, Nov 12, 2015 at 01:54:22PM +0100, LABBE Corentin wrote: > > > > On Thu, Nov 12, 2015

Re: [PATCH v2 04/10] i2c: rcar: remove spinlock

2015-11-12 Thread Sergei Shtylyov
Hello. On 11/12/2015 5:31 PM, Wolfram Sang wrote: From: Wolfram Sang After making sure to reinit the HW and clear interrupts in the timeout case, we know that interrupts are always disabled in the sections protected by the spinlock. What about SMP? Spinlocks are mostly necessary for the

Re: [PATCH v2 04/10] i2c: rcar: remove spinlock

2015-11-12 Thread Wolfram Sang
On Thu, Nov 12, 2015 at 06:04:27PM +0300, Sergei Shtylyov wrote: > Hello. > > On 11/12/2015 5:31 PM, Wolfram Sang wrote: > > >From: Wolfram Sang > > > >After making sure to reinit the HW and clear interrupts in the timeout > >case, we know that interrupts are always disabled in the sections > >p

Re: [PATCH] i2c: tegra: fix a possible NULL dereference

2015-11-12 Thread Thierry Reding
On Thu, Nov 12, 2015 at 03:54:58PM +0100, LABBE Corentin wrote: > On Thu, Nov 12, 2015 at 02:55:00PM +0100, Thierry Reding wrote: > > On Thu, Nov 12, 2015 at 02:45:20PM +0100, Uwe Kleine-König wrote: > > > On Thu, Nov 12, 2015 at 02:28:37PM +0100, Thierry Reding wrote: > > > > On Thu, Nov 12, 2015

[PATCH] i2c: rcar: handle difference in setting up non-first message

2015-11-12 Thread Wolfram Sang
Signed-off-by: Ryo Kataoka Signed-off-by: Hiromitsu Yamasaki Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-rcar.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c index ef963d195a4eb

Re: [PATCH] i2c: core: fix wakeup irq parsing

2015-11-12 Thread Dmitry Torokhov
On Thu, Nov 12, 2015 at 03:42:26PM +0200, Grygorii Strashko wrote: > This patch fixes obvious copy-past error in wake up irq parsing > code which leads to the fact that dev_pm_set_wake_irq() will > be called with wrong IRQ number when "wakeup" IRQ is not > defined in DT. > > Cc: Dmitry Torokhov >

Re: [PATCH v2 01/10] i2c: rcar: make sure clocks are on when doing clock calculation

2015-11-12 Thread Sergei Shtylyov
Hello. On 11/12/2015 05:31 PM, Wolfram Sang wrote: From: Wolfram Sang When calculating the bus speed, the clock should be on, of course. Most bootloaders left them on, so this went unnoticed so far. s/them/it/. Move the ioremapping out of this clock-enabled-block and prepare for adding

Re: [PATCH v2 00/10] i2c: rcar: tackle race conditions in the driver

2015-11-12 Thread Kuninori Morimoto
Hi > Hello RCar Fans! > > So, here is V2 of this series. Thanks to Geert's MSTP clock manipulation > series, I could finally reproduce something which looks like the issues > Laurent > was seeing with his Koelsch board. The outcome is Patch 1/10 which fixes also > issues reported by Morimoto-sa