Reboot hangs on Kirkwood ns2 boards with 3.8-rc2
Simon Guinot
simon.guinot at sequanux.org
Mon Jan 7 10:32:29 EST 2013
On Mon, Jan 07, 2013 at 04:25:10PM +0100, Andrew Lunn wrote:
> On Mon, Jan 07, 2013 at 04:09:18PM +0100, Simon Guinot wrote:
> > On Sun, Jan 06, 2013 at 09:35:21AM +0100, Andrew Lunn wrote:
> > > On Sun, Jan 06, 2013 at 04:34:55AM +0100, Simon Guinot wrote:
> > > > Hi Andrew and Jason,
> > > >
> > > > While testing 3.8-rc2 on the ns2 boards (DT based), I noticed that
> > > > reboot is not working. After issuing a reboot, the kernel hangs. No
> > > > error messages are displayed. Moreover, on my non-DT Kirkwood boards,
> > > > reboot is working as expected.
> > > >
> > > > Am I the only one to experiment this issue ?
> > >
> > > Hi Simon
> > >
> > > No you are not the only one. There is a patch available, authored by
> > > me, which is identical to what you found.
> >
> > Arf, it's a shame I have missed this reports. It could have spared some
> > time by asking at you earlier.
>
> Hi Simon
>
> Its often worth asking, or at least googling, before heading into a
> git bisect.
>
> > About the issue itself. I understand that a clock is needed by the
> > orion-ehci driver. But even if the clock is not provided by the DT, it
> > should have been fixed by kirkwood_legacy_clk_init(), isn't ? What's
> > wrong with this workaround ?
>
> kirkwood_legacy_clk_init() provides a clock with the old name. When
> using DT, the device has the name "f1050000.ehci" and it looks for a
> clock called "f1050000.ehci ". The legacy clock is called
> "orion-ehci.0", which is what is expected when using old style
> platform drivers instantiated in C.
OK, I get it. Thanks for the explanation.
Simon
-------------- 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/20130107/75f4c8d2/attachment.sig>
More information about the linux-arm-kernel
mailing list