3.7 kernel hangs when doing scp

3.7 kernel hangs when doing scp

[Fabio Estevam]

Hi,

Booting a 3.7 kernel on a mx6qsabrelite board via NFS and using an
asix USB/Ethernet adapter and then I try to transfer a 10MB file from
the target to the host:

root at freescale /home$ scp test.tar.gz fabio at 192.168.1.100:/home/fabio
fabio at 192.168.1.100's password:
test.tar.gz                                      0%    0     0.0KB/s   --:-- ETA
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x2cc/0x2f0()
NETDEV WATCHDOG: eth0 (asix): transmit queue 0 timed out
Modules linked in:
Backtrace:
[<80011c94>] (dump_backtrace+0x0/0x10c) from [<804d3a5c>] (dump_stack+0x18/0x1c)
 r6:000000ff r5:80412388 r4:80685dc0 r3:80696cc0
[<804d3a44>] (dump_stack+0x0/0x1c) from [<80021868>]
(warn_slowpath_common+0x54/0x6c)
[<80021814>] (warn_slowpath_common+0x0/0x6c) from [<80021924>]
(warn_slowpath_fmt+0x38/0x40)
 r8:00000000 r7:806c6ec7 r6:806860c0 r5:00000000 r4:bf0cd800
r3:00000009
[<800218ec>] (warn_slowpath_fmt+0x0/0x40) from [<80412388>]
(dev_watchdog+0x2cc/0x2f0)
 r3:bf0cd800 r2:8060b170
[<804120bc>] (dev_watchdog+0x0/0x2f0) from [<8002ef90>]
(call_timer_fn.isra.29+0x2c/0x8c)
[<8002ef64>] (call_timer_fn.isra.29+0x0/0x8c) from [<8002f220>]
(run_timer_softirq+0x230/0x24c)
 r7:80709954 r6:806860c0 r5:00000000 r4:80709140
[<8002eff0>] (run_timer_softirq+0x0/0x24c) from [<8002938c>]
(__do_softirq+0xd4/0x198)
[<800292b8>] (__do_softirq+0x0/0x198) from [<8002977c>] (irq_exit+0x88/0x90)
[<800296f4>] (irq_exit+0x0/0x90) from [<8000ee98>] (handle_IRQ+0x58/0xb4)
 r4:8068d170 r3:00000180
[<8000ee40>] (handle_IRQ+0x0/0xb4) from [<80008500>] (gic_handle_irq+0x30/0x64)
 r8:00000000 r7:f4000100 r6:80685f28 r5:8068c974 r4:f400010c
r3:00000000
[<800084d0>] (gic_handle_irq+0x0/0x64) from [<8000e100>] (__irq_svc+0x40/0x54)
Exception stack(0x80685f28 to 0x80685f70)
BUG: scheduling while atomic: swapper/0/0/0x40000100
Modules linked in:
Backtrace:
[<80011c94>] (dump_backtrace+0x0/0x10c) from [<804d3a5c>] (dump_stack+0x18/0x1c)
 r6:80684000 r5:8068fc28 r4:80f2e240 r3:60000113
[<804d3a44>] (dump_stack+0x0/0x1c) from [<804d4148>] (__schedule_bug+0x48/0x5c)
[<804d4100>] (__schedule_bug+0x0/0x5c) from [<804d8b08>]
(__schedule+0x52c/0x580)
[<804d85dc>] (__schedule+0x0/0x580) from [<8004a208>] (__cond_resched+0x28/0x38)
[<8004a1e0>] (__cond_resched+0x0/0x38) from [<804d8bf0>]
(_cond_resched+0x38/0x48)
 r4:80685f28 r3:00000100
[<804d8bb8>] (_cond_resched+0x0/0x48) from [<80011c0c>] (dump_mem+0x11c/0x1a4)
[<80011af0>] (dump_mem+0x0/0x1a4) from [<80011e20>]
(dump_backtrace_entry+0x60/0x7c)
[<80011dc0>] (dump_backtrace_entry+0x0/0x7c) from [<8024c464>]
(for_each_frame+0x3c/0x88)
 r5:80685f7c r4:80685f24
[<80011c94>] (dump_backtrace+0x0/0x10c) from [<804d3a5c>] (dump_stack+0x18/0x1c)
 r6:000000ff r5:80412388 r4:80685dc0 r3:80696cc0
[<804d3a44>] (dump_stack+0x0/0x1c) from [<80021868>]
(warn_slowpath_common+0x54/0x6c)
[<80021814>] (warn_slowpath_common+0x0/0x6c) from [<80021924>]
(warn_slowpath_fmt+0x38/0x40)
 r8:00000000 r7:806c6ec7 r6:806860c0 r5:00000000 r4:bf0cd800
r3:00000009
[<800218ec>] (warn_slowpath_fmt+0x0/0x40) from [<80412388>]
(dev_watchdog+0x2cc/0x2f0)
 r3:bf0cd800 r2:8060b170
[<804120bc>] (dev_watchdog+0x0/0x2f0) from [<8002ef90>]
(call_timer_fn.isra.29+0x2c/0x8c)
[<8002ef64>] (call_timer_fn.isra.29+0x0/0x8c) from [<8002f220>]
(run_timer_softirq+0x230/0x24c)
 r7:80709954 r6:806860c0 r5:00000000 r4:80709140
[<8002eff0>] (run_timer_softirq+0x0/0x24c) from [<8002938c>]
(__do_softirq+0xd4/0x198)
[<800292b8>] (__do_softirq+0x0/0x198) from [<8002977c>] (irq_exit+0x88/0x90)
[<800296f4>] (irq_exit+0x0/0x90) from [<8000ee98>] (handle_IRQ+0x58/0xb4)
 r4:8068d170 r3:00000180
[<8000ee40>] (handle_IRQ+0x0/0xb4) from [<80008500>] (gic_handle_irq+0x30/0x64)
 r8:00000000 r7:f4000100 r6:80685f28 r5:8068c974 r4:f400010c
r3:00000000
[<800084d0>] (gic_handle_irq+0x0/0x64) from [<8000e100>] (__irq_svc+0x40/0x54)
Exception stack(0x80685f28 to 0x80685f70)
5f20:                   00000000 00000000 0000000f 80018fa0 80684000 80684000
5f40: 806c7008 804dbe24 00000000 80684000 80690968 80685f7c 80685f80 80685f70
5f60: 8000f168 8000f16c 60000013 ffffffff
 r7:80685f5c r6:ffffffff r5:60000013 r4:8000f16c
[<8000f134>] (default_idle+0x0/0x44) from [<8000f324>] (cpu_idle+0xa8/0xf4)
[<8000f27c>] (cpu_idle+0x0/0xf4) from [<804c3744>] (rest_init+0x64/0x7c)
[<804c36e0>] (rest_init+0x0/0x7c) from [<8063c820>] (start_kernel+0x29c/0x2ec)
[<8063c584>] (start_kernel+0x0/0x2ec) from [<10008078>] (0x10008078)
5f20:                   00000000 00000000 0000000f 80018fa0 80684000 80684000
5f40: 806c7008 804dbe24 00000000 80684000 80690968 80685f7c 80685f80 80685f70
5f60: 8000f168 8000f16c 60000013 ffffffff
 r7:80685f5c r6:ffffffff r5:60000013 r4:8000f16c
[<8000f134>] (default_idle+0x0/0x44) from [<8000f324>] (cpu_idle+0xa8/0xf4)
[<8000f27c>] (cpu_idle+0x0/0xf4) from [<804c3744>] (rest_init+0x64/0x7c)
[<804c36e0>] (rest_init+0x0/0x7c) from [<8063c820>] (start_kernel+0x29c/0x2ec)
[<8063c584>] (start_kernel+0x0/0x2ec) from [<10008078>] (0x10008078)
---[ end trace 12cd5962244d1a4c ]---
nfs: server 192.168.1.100 not responding, still trying
nfs: server 192.168.1.100 not responding, still trying
nfs: server 192.168.1.100 not responding, still trying
nfs: server 192.168.1.100 not responding, still trying
(system hang)

The scp transfer works fine when using the FEC interface instead of
USB to Ethernet.

I haven't started bisecting this yet, but any suggestions are welcome.

Regards,

Fabio Estevam

3.7 kernel hangs when doing scp

[Greg KH]

On Tue, Dec 18, 2012 at 12:01:35AM -0200, Fabio Estevam wrote:
> Hi,
> 
> Booting a 3.7 kernel on a mx6qsabrelite board via NFS and using an
> asix USB/Ethernet adapter and then I try to transfer a 10MB file from
> the target to the host:

Has this ever worked before on any older kernel?

thanks,

greg k-h

3.7 kernel hangs when doing scp

[Sebastian Andrzej Siewior]

On Tue, Dec 18, 2012 at 12:01:35AM -0200, Fabio Estevam wrote:
> Booting a 3.7 kernel on a mx6qsabrelite board via NFS and using an
> asix USB/Ethernet adapter and then I try to transfer a 10MB file from
> the target to the host:

That backtrace shows only that nothing is going on. Can you attach that asix
thingy to another USB-host and test?
Is your host working well with other devices say usb-storage?

Sebastian

3.7 kernel hangs when doing scp

[Fabio Estevam]

Hi Greg,

On Tue, Dec 18, 2012 at 12:43 AM, Greg KH <greg@kroah.com> wrote:
> On Tue, Dec 18, 2012 at 12:01:35AM -0200, Fabio Estevam wrote:
>> Hi,
>>
>> Booting a 3.7 kernel on a mx6qsabrelite board via NFS and using an
>> asix USB/Ethernet adapter and then I try to transfer a 10MB file from
>> the target to the host:
>
> Has this ever worked before on any older kernel?

We did more experiments on this and we noticed that:

- mx51 running kernel 3.7 does not show this problem (tested a non-dt
mx51 kernel, which uses drivers/usb/host/ehci-mxc.c instead of the
chipidea driver.)
- x86 running 3.2 kernel does not show this problem
- usb support on mx6 has appeared on 3.6, but running an out-of-tree
3.0.35 kernel also shows the same issue.
- Doing long file transfers via mass storage on mx6 running 3.7 works fine.

Shawn/Sascha/Peter,

Any suggestions as to how debug this? By looking at the kernel dumps
it seems to point to 'gic_handle_irq' area.

Thanks,

Fabio Estevam

3.7 kernel hangs when doing scp

[Peter Chen]

On Wed, Dec 19, 2012 at 12:56:12PM -0200, Fabio Estevam wrote:
> Hi Greg,
> 
> On Tue, Dec 18, 2012 at 12:43 AM, Greg KH <greg@kroah.com> wrote:
> > On Tue, Dec 18, 2012 at 12:01:35AM -0200, Fabio Estevam wrote:
> >> Hi,
> >>
> >> Booting a 3.7 kernel on a mx6qsabrelite board via NFS and using an
> >> asix USB/Ethernet adapter and then I try to transfer a 10MB file from
> >> the target to the host:
> >
> > Has this ever worked before on any older kernel?
> 
> We did more experiments on this and we noticed that:
> 
> - mx51 running kernel 3.7 does not show this problem (tested a non-dt
> mx51 kernel, which uses drivers/usb/host/ehci-mxc.c instead of the
> chipidea driver.)
> - x86 running 3.2 kernel does not show this problem
> - usb support on mx6 has appeared on 3.6, but running an out-of-tree
> 3.0.35 kernel also shows the same issue.
> - Doing long file transfers via mass storage on mx6 running 3.7 works fine.
> 
> Shawn/Sascha/Peter,
> 
> Any suggestions as to how debug this? By looking at the kernel dumps
> it seems to point to 'gic_handle_irq' area.
Hi Fabio,

Please to see if the Stream mode disable (bit4, usbmode) is set or not?
If it is not, please try below patch

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c97503b..258bc02 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -227,6 +227,7 @@ static void tdi_reset (struct ehci_hcd *ehci)
 
 	tmp = ehci_readl(ehci, &ehci->regs->usbmode);
 	tmp |= USBMODE_CM_HC;
+	tmp |= (1 << 4); /* disable stream mode */
 	/* The default byte access to MMR space is LE after
 	 * controller reset. Set the required endian mode
 	 * for transfer buffers to match the host microprocessor

> 
> Thanks,
> 
> Fabio Estevam
> 

-- 

Best Regards,
Peter Chen

3.7 kernel hangs when doing scp

[Fabio Estevam]

Hi Peter,

On Thu, Dec 20, 2012 at 2:39 AM, Peter Chen <peter.chen@freescale.com> wrote:

> Please to see if the Stream mode disable (bit4, usbmode) is set or not?
> If it is not, please try below patch
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index c97503b..258bc02 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -227,6 +227,7 @@ static void tdi_reset (struct ehci_hcd *ehci)
>
>         tmp = ehci_readl(ehci, &ehci->regs->usbmode);
>         tmp |= USBMODE_CM_HC;
> +       tmp |= (1 << 4); /* disable stream mode */
>         /* The default byte access to MMR space is LE after
>          * controller reset. Set the required endian mode
>          * for transfer buffers to match the host microprocessor

Excellent! Your suggestion made scp work with mx6 on 3.7.

I assume that this "fix" or workaround would need a better place, right?

Should this fix go into the chipidea host driver instead?

Also, I wonder on how "standard" this USBMODE register is. i.e. there
is a deviation from the FSL EHCI USBMODE register.
I found it in include/linux/usb/ehci_def.h:

#define USBMODE_SDIS            (1<<3)          /* Stream disable */

, which is at a different bit position from the i.MX6 Reference Manual:

4 SDIS Stream Disable Mode. (0 - Inactive [default]; 1 - Active)

Also interested to know more details@to why disabling stream mode
make things work.

Thanks a lot!

Fabio Estevam

3.7 kernel hangs when doing scp

[Fabio Estevam]

On Thu, Dec 20, 2012 at 8:20 AM, Fabio Estevam <festevam@gmail.com> wrote:

> Excellent! Your suggestion made scp work with mx6 on 3.7.
>
> I assume that this "fix" or workaround would need a better place, right?
>
> Should this fix go into the chipidea host driver instead?

Also, we are already passing the CI13XXX_DISABLE_STREAMING flag:

static struct ci13xxx_platform_data ci13xxx_imx_platdata  = {
	.name			= "ci13xxx_imx",
	.flags			= CI13XXX_REQUIRE_TRANSCEIVER |
				  CI13XXX_PULLUP_ON_VBUS |
				  CI13XXX_DISABLE_STREAMING,
	.capoffset		= DEF_CAPOFFSET,
};

Regards,

Fabio Estevam

3.7 kernel hangs when doing scp

[Fabio Estevam]

On Thu, Dec 20, 2012 at 8:20 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Peter,
>
> On Thu, Dec 20, 2012 at 2:39 AM, Peter Chen <peter.chen@freescale.com> wrote:
>
>> Please to see if the Stream mode disable (bit4, usbmode) is set or not?
>> If it is not, please try below patch
>>
>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
>> index c97503b..258bc02 100644
>> --- a/drivers/usb/host/ehci-hcd.c
>> +++ b/drivers/usb/host/ehci-hcd.c
>> @@ -227,6 +227,7 @@ static void tdi_reset (struct ehci_hcd *ehci)
>>
>>         tmp = ehci_readl(ehci, &ehci->regs->usbmode);
>>         tmp |= USBMODE_CM_HC;
>> +       tmp |= (1 << 4); /* disable stream mode */
>>         /* The default byte access to MMR space is LE after
>>          * controller reset. Set the required endian mode
>>          * for transfer buffers to match the host microprocessor
>
> Excellent! Your suggestion made scp work with mx6 on 3.7.
>
> I assume that this "fix" or workaround would need a better place, right?
>
> Should this fix go into the chipidea host driver instead?
>
> Also, I wonder on how "standard" this USBMODE register is. i.e. there
> is a deviation from the FSL EHCI USBMODE register.
> I found it in include/linux/usb/ehci_def.h:
>
> #define USBMODE_SDIS            (1<<3)          /* Stream disable */
>
> , which is at a different bit position from the i.MX6 Reference Manual:
>
> 4 SDIS Stream Disable Mode. (0 - Inactive [default]; 1 - Active)

Would this be the correct fix?

--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -18,7 +18,7 @@ struct ci13xxx_platform_data {
 #define CI13XXX_REGS_SHARED            BIT(0)
 #define CI13XXX_REQUIRE_TRANSCEIVER    BIT(1)
 #define CI13XXX_PULLUP_ON_VBUS         BIT(2)
-#define CI13XXX_DISABLE_STREAMING      BIT(3)
+#define CI13XXX_DISABLE_STREAMING      BIT(4)

3.7 kernel hangs when doing scp

[Fabio Estevam]

On Thu, Dec 20, 2012 at 8:45 AM, Fabio Estevam <festevam@gmail.com> wrote:

> Would this be the correct fix?
>
> --- a/include/linux/usb/chipidea.h
> +++ b/include/linux/usb/chipidea.h
> @@ -18,7 +18,7 @@ struct ci13xxx_platform_data {
>  #define CI13XXX_REGS_SHARED            BIT(0)
>  #define CI13XXX_REQUIRE_TRANSCEIVER    BIT(1)
>  #define CI13XXX_PULLUP_ON_VBUS         BIT(2)
> -#define CI13XXX_DISABLE_STREAMING      BIT(3)
> +#define CI13XXX_DISABLE_STREAMING      BIT(4)

Ops, these are just the platform data flags.

I will take a look on why the chipidea driver is not properly
disabling stream mode.

Regards,

Fabio Estevam

3.7 kernel hangs when doing scp

[Peter Chen]

On Thu, Dec 20, 2012 at 09:18:43AM -0200, Fabio Estevam wrote:
> On Thu, Dec 20, 2012 at 8:45 AM, Fabio Estevam <festevam@gmail.com> wrote:
> 
> > Would this be the correct fix?
> >
> > --- a/include/linux/usb/chipidea.h
> > +++ b/include/linux/usb/chipidea.h
> > @@ -18,7 +18,7 @@ struct ci13xxx_platform_data {
> >  #define CI13XXX_REGS_SHARED            BIT(0)
> >  #define CI13XXX_REQUIRE_TRANSCEIVER    BIT(1)
> >  #define CI13XXX_PULLUP_ON_VBUS         BIT(2)
> > -#define CI13XXX_DISABLE_STREAMING      BIT(3)
> > +#define CI13XXX_DISABLE_STREAMING      BIT(4)
> 
> Ops, these are just the platform data flags.
> 
> I will take a look on why the chipidea driver is not properly
> disabling stream mode.

Current chipidea driver only considers disable stream mode at device
mode, in fact, it may be related to below chipidea bug, and needs
to consider all usb modes.

STAR 9000378958
Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to Hang on OUT Retry 
www.synopsys.com/dw/star.php?c=dwc_usb2_hs_otg_controller&fixedIn=2.20a

To fix this, we need to add CI13XXX_DISABLE_STREAMING after role->start/init.


> 
> Regards,
> 
> Fabio Estevam
> 

-- 

Best Regards,
Peter Chen

3.7 kernel hangs when doing scp

[Fabio Estevam]

Hi Peter,

On Fri, Dec 21, 2012 at 12:22 AM, Peter Chen <peter.chen@freescale.com> wrote:

> Current chipidea driver only considers disable stream mode at device
> mode, in fact, it may be related to below chipidea bug, and needs
> to consider all usb modes.
>
> STAR 9000378958
> Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to Hang on OUT Retry
> www.synopsys.com/dw/star.php?c=dwc_usb2_hs_otg_controller&fixedIn=2.20a
>
> To fix this, we need to add CI13XXX_DISABLE_STREAMING after role->start/init.

Yes, setting CI13XXX_DISABLE_STREAMING inside ci_role_start does work.

If you think the patch below is fine I can properly submit it.

---
 drivers/usb/chipidea/ci.h |   39 +++++++++++++++++++++++----------------
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index e25d126..7fe652a 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -18,6 +18,8 @@
 #include <linux/usb.h>
 #include <linux/usb/gadget.h>

+#define USBMODE_CI_SDIS       BIT(4)
+
 /******************************************************************************
  * DEFINE
  *****************************************************************************/
@@ -173,22 +175,6 @@ static inline struct ci_role_driver
*ci_role(struct ci13xxx *ci)
 	return ci->roles[ci->role];
 }

-static inline int ci_role_start(struct ci13xxx *ci, enum ci_role role)
-{
-	int ret;
-
-	if (role >= CI_ROLE_END)
-		return -EINVAL;
-
-	if (!ci->roles[role])
-		return -ENXIO;
-
-	ret = ci->roles[role]->start(ci);
-	if (!ret)
-		ci->role = role;
-	return ret;
-}
-
 static inline void ci_role_stop(struct ci13xxx *ci)
 {
 	enum ci_role role = ci->role;
@@ -307,6 +293,27 @@ static inline u32 hw_test_and_write(struct
ci13xxx *ci, enum ci13xxx_regs reg,
 	return (val & mask) >> ffs_nr(mask);
 }

+
+static inline int ci_role_start(struct ci13xxx *ci, enum ci_role role)
+{
+	int ret;
+
+	if (role >= CI_ROLE_END)
+		return -EINVAL;
+
+	if (!ci->roles[role])
+		return -ENXIO;
+
+	ret = ci->roles[role]->start(ci);
+	if (!ret)
+		ci->role = role;
+
+	if (ci->platdata->flags & CI13XXX_DISABLE_STREAMING)
+		hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS);
+
+	return ret;
+}
+
 int hw_device_reset(struct ci13xxx *ci, u32 mode);

 int hw_port_test_set(struct ci13xxx *ci, u8 mode);
--

3.7 kernel hangs when doing scp

[Wolfram Sang]

On Fri, Dec 21, 2012 at 07:24:14AM -0200, Fabio Estevam wrote:
> Hi Peter,
> 
> On Fri, Dec 21, 2012 at 12:22 AM, Peter Chen <peter.chen@freescale.com> wrote:
> 
> > Current chipidea driver only considers disable stream mode at device
> > mode, in fact, it may be related to below chipidea bug, and needs
> > to consider all usb modes.
> >
> > STAR 9000378958
> > Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to Hang on OUT Retry
> > www.synopsys.com/dw/star.php?c=dwc_usb2_hs_otg_controller&fixedIn=2.20a
> >
> > To fix this, we need to add CI13XXX_DISABLE_STREAMING after role->start/init.
> 
> Yes, setting CI13XXX_DISABLE_STREAMING inside ci_role_start does work.
> 
> If you think the patch below is fine I can properly submit it.

Why did you need to move this function?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121221/9bb22a4b/attachment.sig>

3.7 kernel hangs when doing scp

[Fabio Estevam]

On Fri, Dec 21, 2012 at 9:49 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:

>> Yes, setting CI13XXX_DISABLE_STREAMING inside ci_role_start does work.
>>
>> If you think the patch below is fine I can properly submit it.
>
> Why did you need to move this function?

Only to make the compiler happy. hw_write() is now used by
ci_role_start(), so I re-ordered so that  hw_write comes first in the
code and compiler does not complain.

Regards,

Fabio Estevam

3.7 kernel hangs when doing scp

[Wolfram Sang]

> Only to make the compiler happy. hw_write() is now used by
> ci_role_start(), so I re-ordered so that  hw_write comes first in the
> code and compiler does not complain.

Yup, spotted this on second glance. If you submit the patch, might be
helpful to mention this.

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121221/2a121596/attachment.sig>