From: Kalle Valo <kvalo@codeaurora.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>,
Govind Singh <govinds@codeaurora.org>,
linux-wireless@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
ath10k@lists.infradead.org
Subject: Re: [PATCH 4/4] ath10k: snoc: fix unbalanced clock error handling
Date: Tue, 06 Nov 2018 18:14:40 +0200 [thread overview]
Message-ID: <87wopqb2tr.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CAD=FV=XFUeyYZ-LQwYHeQH=b0kBf_wM5ZywpQDS74+_zqeDhEw@mail.gmail.com> (Doug Anderson's message of "Tue, 16 Oct 2018 16:53:52 -0700")
Doug Anderson <dianders@chromium.org> writes:
> Hi,
> On Fri, Oct 12, 2018 at 5:55 PM Brian Norris <briannorris@chromium.org> wrote:
>>
>> Similar to regulator error handling, we should only start tearing down
>> the 'i - 1' clock when clock 'i' fails to enable. Otherwise, we might
>> end up with an unbalanced clock, where we never successfully enabled the
>> clock, but we try to disable it anyway.
>>
>> Signed-off-by: Brian Norris <briannorris@chromium.org>
>
> Presumably you could have a Fixes tag just to help folks, like:
>
> Fixes: a6a793f98786 ("ath10k: vote for hardware resources for WCN3990")
Thanks, I added that in the pending branch.
--
Kalle Valo
WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Govind Singh <govinds@codeaurora.org>,
Brian Norris <briannorris@chromium.org>,
linux-wireless@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
ath10k@lists.infradead.org
Subject: Re: [PATCH 4/4] ath10k: snoc: fix unbalanced clock error handling
Date: Tue, 06 Nov 2018 18:14:40 +0200 [thread overview]
Message-ID: <87wopqb2tr.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CAD=FV=XFUeyYZ-LQwYHeQH=b0kBf_wM5ZywpQDS74+_zqeDhEw@mail.gmail.com> (Doug Anderson's message of "Tue, 16 Oct 2018 16:53:52 -0700")
Doug Anderson <dianders@chromium.org> writes:
> Hi,
> On Fri, Oct 12, 2018 at 5:55 PM Brian Norris <briannorris@chromium.org> wrote:
>>
>> Similar to regulator error handling, we should only start tearing down
>> the 'i - 1' clock when clock 'i' fails to enable. Otherwise, we might
>> end up with an unbalanced clock, where we never successfully enabled the
>> clock, but we try to disable it anyway.
>>
>> Signed-off-by: Brian Norris <briannorris@chromium.org>
>
> Presumably you could have a Fixes tag just to help folks, like:
>
> Fixes: a6a793f98786 ("ath10k: vote for hardware resources for WCN3990")
Thanks, I added that in the pending branch.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2018-11-06 16:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-13 0:55 [PATCH 1/4] ath10k: snoc: remove 'wcn3990' from generic resource handling Brian Norris
2018-10-13 0:55 ` Brian Norris
2018-10-13 0:55 ` [PATCH 2/4] ath10k: snoc: fix unabalanced regulator error handling Brian Norris
2018-10-13 0:55 ` Brian Norris
2018-10-18 17:54 ` Doug Anderson
2018-10-18 17:54 ` Doug Anderson
2018-10-24 22:10 ` Brian Norris
2018-10-24 22:10 ` Brian Norris
2018-10-13 0:55 ` [PATCH 3/4] ath10k: snoc: relax voltage requirements Brian Norris
2018-10-13 0:55 ` Brian Norris
2018-10-18 17:56 ` Doug Anderson
2018-10-18 17:56 ` Doug Anderson
2018-10-18 18:14 ` Brian Norris
2018-10-18 18:14 ` Brian Norris
2018-10-13 0:55 ` [PATCH 4/4] ath10k: snoc: fix unbalanced clock error handling Brian Norris
2018-10-13 0:55 ` Brian Norris
2018-10-16 23:53 ` Doug Anderson
2018-10-16 23:53 ` Doug Anderson
2018-11-06 16:14 ` Kalle Valo [this message]
2018-11-06 16:14 ` Kalle Valo
2018-10-16 23:43 ` [PATCH 1/4] ath10k: snoc: remove 'wcn3990' from generic resource handling Doug Anderson
2018-10-16 23:43 ` Doug Anderson
2018-10-16 23:47 ` Brian Norris
2018-10-16 23:47 ` Brian Norris
2018-11-05 13:04 ` Kalle Valo
2018-11-05 13:04 ` Kalle Valo
[not found] ` <20181105130403.93B6560600@smtp.codeaurora.org>
2018-11-05 21:17 ` Brian Norris
2018-11-05 21:17 ` Brian Norris
2018-11-06 16:18 ` Kalle Valo
2018-11-06 16:18 ` Kalle Valo
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=87wopqb2tr.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=briannorris@chromium.org \
--cc=dianders@chromium.org \
--cc=govinds@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.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 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.