linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: eric.y.miao@gmail.com (Eric Miao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: pxa: Fix pxa3xx-u2d crash when ULPI not used
Date: Sun, 5 Sep 2010 21:58:25 +0800	[thread overview]
Message-ID: <AANLkTik7Hzs8OUKSL+6HRgvR1iRWg4LE_v0LMUC2VxVZ@mail.gmail.com> (raw)
In-Reply-To: <4C839F26.4050107@compulab.co.il>

On Sun, Sep 5, 2010 at 9:46 PM, Igor Grinberg <grinberg@compulab.co.il> wrote:
> ?On 09/05/10 13:43, Eric Miao wrote:
>> On Sun, Sep 5, 2010 at 4:35 PM, Igor Grinberg <grinberg@compulab.co.il> wrote:
>>> ?On 09/05/10 11:25, Marek Vasut wrote:
>>>> Dne Ne 5. z??? 2010 10:16:48 Igor Grinberg napsal(a):
>>>>> ?On 09/05/10 11:01, Marek Vasut wrote:
>>>>>> Dne Ne 5. z??? 2010 09:54:31 Igor Grinberg napsal(a):
>>>>>>> ?On 09/03/10 23:35, Marek Vasut wrote:
>>>>>>>> In case the pxa3xx-u2d driver isn't used, probing of ohci-pxa27x will
>>>>>>>> cause an ugly kernel crash (NULL pointer dereference in
>>>>>>>> pxa3xx_u2d_start_hc(), because struct u2d is NULL and clk_enable() call
>>>>>>>> will crash the kernel, trying to access it).
>>>>>>> ohci code checks for pxa3xx cpu and only then runs start/stop hc.
>>>>>> Exactly ... and in case "struct pxa3xx_u2d_ulpi *u2d" is NULL, clk_enable
>>>>>> will crash the kernel.
>>>>>>
>>>>>>> pxa3xx_ulpi.c is compiled if CONFIG_PXA3xx is selected.
>>>>>>> The device <-> driver binding should not be a problem, so the
>>>>>>> pxa3xx_u2d_probe() will run.
>>>>>>> The only case, I see, when struct u2d does not exist is failure of the
>>>>>>> probe function. If this is the case, we are having an abnormal execution
>>>>>>> and if your patch is dealing with this issue, shouldn't you comment it
>>>>>>> as such?
>>>>>> Not at all ... if the pxa3xx-u2d driver isn't loaded at all, the function
>>>>>> (start/stop hc) is still called, but struct pxa3xx_u2d_ulpi *u2d is NULL.
>>>>>> In this case, if you call clk_enable(u2d->clk), you crash the kernel
>>>>>> (because u2d is NULL).
>>>>> How, can it happen, that "pxa3xx-u2d driver isn't loaded at all"?
>>>>> This can happen only if you rip out the device registration or hack a
>>>>> Makefile. I don't see any other way... is there?
>>>> If you don't call pxa3xx_set_u2d_info() ?
>>> Oh... right.
>>> I've added it this way, so boards can control u2d existence and forgot it is there...
>>> Buggy me... :(
>>>
>> Igor,
>>
>> So do you this as a proper fix, or there is better way out?
>
> If we want to keep it the most straight-forward way so it is fine.
>
> Another possible ways would be:
>
> 1) create a new flag, lets say PORT2_USE_U2DC in pxaohci_platform_data.
> This is a relatively clean way of making ohci aware of
> u2d existence at runtime and eliminates the calls to functions
> of non-existing (not loaded) driver...
>
> 2) use something like:
> struct u2d_hc_ops {
> ? ?int (*start_hc)(...);
> ? ?void (*stop_hc)(...);
> }
>
> in board init code register the ops structure via the pxa_ohci platform data.
>
> This way adds some more pollution to the pxa_ohci glue with code
> relevant only to pxa3xx, achieving the same as the 1st way, but also
> can be useful for u2dc otg/peripheral driver (if it will come some day...).
>
> I'm fine with both (Marek's patch or my proposal), so tell me what
> looks better to you.
>

That sounds to be a cleaner way, but may require more changes. What
if we get this patch into -rc phase as is first, and get a cleaner patch for
-next?

> --
> Regards,
> Igor.
>
>

  reply	other threads:[~2010-09-05 13:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-03 20:35 [PATCH] ARM: pxa: Fix pxa3xx-u2d crash when ULPI not used Marek Vasut
2010-09-04  5:38 ` Eric Miao
2010-09-05  7:54 ` Igor Grinberg
2010-09-05  8:01   ` Marek Vasut
2010-09-05  8:16     ` Igor Grinberg
2010-09-05  8:25       ` Marek Vasut
2010-09-05  8:35         ` Igor Grinberg
2010-09-05 10:43           ` Eric Miao
2010-09-05 13:46             ` Igor Grinberg
2010-09-05 13:58               ` Eric Miao [this message]
2010-09-05 14:31                 ` Igor Grinberg
2010-09-05 19:23                   ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTik7Hzs8OUKSL+6HRgvR1iRWg4LE_v0LMUC2VxVZ@mail.gmail.com \
    --to=eric.y.miao@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).