From: jeffy <jeffy.chen@rock-chips.com>
To: Heiko Stuebner <heiko@sntech.de>, Shawn Lin <shawn.lin@rock-chips.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-rockchip@lists.infradead.org,
Douglas Anderson <dianders@chromium.org>,
Brian Norris <briannorris@chromium.org>
Subject: Re: [PATCH v2] PCI: rockchip: fix system hang up if activating CONFIG_DEBUG_SHIRQ
Date: Tue, 22 Aug 2017 10:30:52 +0800 [thread overview]
Message-ID: <599B975C.20807@rock-chips.com> (raw)
In-Reply-To: <3312094.6zR5NuJAgK@phil>
Hi Heiko,
On 08/10/2017 08:22 PM, Heiko Stuebner wrote:
>>
>> >+ devm_add_action_or_reset(dev,
>> >+ rockchip_pcie_disable_clocks, rockchip);
>> >+
> err = devm_add_action_or_reset(...)
> if (err) {
> ...
> }
>
> devm_add_action_or_reset can fail. When it fails, it will call the
> action already, so your error handling does not need to disable
> clocks on its own.
>
>
> Also, as a more general comment, right now you do devm_request_irq
> from rockchip_pcie_parse_dt, which gets called_before_ clocks are
> enabled.
>
> This will likely bite you at some point as well, as the irq can fire at
> any point after it got requested ... including before you enable the
> clocks.
>
> So the order should probably be
>
> - enable clocks
> - register devm_action to shutdown clocks
> - parse_dt including requesting the irq.
>
>
> Heiko
it turns out this irq handler not only depends on clks, but also pm
domain :(
so handling it with devm_* functions would be a little
complicated(https://lkml.org/lkml/2017/8/15/146).
would it make sense to use request_irq/free_irq directly?
or maybe add a flag(for example probed), and check it in the irq handler
before read registers? then we would just need to make sure the priv
struct be freed later than the irq.
>
>
prev parent reply other threads:[~2017-08-22 2:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-10 11:18 [PATCH v2] PCI: rockchip: fix system hang up if activating CONFIG_DEBUG_SHIRQ Shawn Lin
2017-08-10 12:22 ` Heiko Stuebner
2017-08-22 2:30 ` jeffy [this message]
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=599B975C.20807@rock-chips.com \
--to=jeffy.chen@rock-chips.com \
--cc=bhelgaas@google.com \
--cc=briannorris@chromium.org \
--cc=dianders@chromium.org \
--cc=heiko@sntech.de \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=shawn.lin@rock-chips.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.