All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>,
	linux-wireless@vger.kernel.org,
	brcm80211-dev-list.pdl@broadcom.com,
	brcm80211-dev-list@cypress.com, netdev@vger.kernel.org,
	hdegoede@redhat.com, franky.lin@broadcom.com,
	hante.meuleman@broadcom.com, chi-hsien.lin@cypress.com,
	wright.feng@cypress.com, kvalo@codeaurora.org,
	davem@davemloft.net
Subject: Re: [PATCH] brcmfmac: sdio: Fix OOB interrupt initialization on brcm43362
Date: Tue, 7 Jan 2020 19:23:32 +0300	[thread overview]
Message-ID: <34dbd037-0a40-bf5f-4988-6b821811ffcd@gmail.com> (raw)
In-Reply-To: <20200107072354.GA832497@myrica>

07.01.2020 10:23, Jean-Philippe Brucker пишет:
> On Tue, Jan 07, 2020 at 02:15:18AM +0300, Dmitry Osipenko wrote:
>> 06.01.2020 22:19, Jean-Philippe Brucker пишет:
>>> Hi Dmitry,
>>>
>>> On Thu, Dec 26, 2019 at 05:37:58PM +0300, Dmitry Osipenko wrote:
>>>> I haven't seen any driver probe failures due to OOB on NVIDIA Tegra,
>>>> only suspend-resume was problematic due to the unbalanced OOB
>>>> interrupt-wake enabling.
>>>>
>>>> But maybe checking whether OOB interrupt-wake works by invoking
>>>> enable_irq_wake() during brcmf_sdiod_intr_register() causes trouble for
>>>> the cubietruck board.
>>>>
>>>> @Jean-Philippe, could you please try this change (on top of recent
>>>> linux-next):
>>>
>>> Sorry for the delay, linux-next doesn't boot for me at the moment and I
>>> have little time to investigate why, so I might retry closer to the merge
>>> window.
>>>
>>> However, isn't the interrupt-wake issue independent from the problem
>>> (introduced in v4.17) that my patch fixes? I applied "brcmfmac: Keep OOB
>>> wake-interrupt disabled when it shouldn't be enabled" on v5.5-rc5 and it
>>> doesn't seem to cause a regression, but the wifi only works if I apply my
>>> patch as well.
>>>
>>> Thanks,
>>> Jean
>>>
>>>>
>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>> index b684a5b6d904..80d7106b10a9 100644
>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>> @@ -115,13 +115,6 @@ int brcmf_sdiod_intr_register(struct brcmf_sdio_dev
>>>> *sdiodev)
>>>>                 }
>>>>                 sdiodev->oob_irq_requested = true;
>>>>
>>>> -               ret = enable_irq_wake(pdata->oob_irq_nr);
>>>> -               if (ret != 0) {
>>>> -                       brcmf_err("enable_irq_wake failed %d\n", ret);
>>>> -                       return ret;
>>>> -               }
>>>> -               disable_irq_wake(pdata->oob_irq_nr);
>>>> -
>>>>                 sdio_claim_host(sdiodev->func1);
>>>>
>>>>                 if (sdiodev->bus_if->chip == BRCM_CC_43362_CHIP_ID) {
>>
>> Hello Jean,
>>
>> Could you please clarify whether you applied [1] and then the above
>> snippet on top of it or you only applied [1] without the snippet?
> 
> I applied [1] without the snippet
> 
> Thanks,
> Jean
> 
>>
>> [1] brcmfmac: Keep OOB wake-interrupt disabled when it shouldn't be enabled

Will you be able to test *with* the snippet? I guess chances that it
will make any difference are not high, nevertheless will be good to know
for sure.

  reply	other threads:[~2020-01-07 16:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-26  9:20 [PATCH] brcmfmac: sdio: Fix OOB interrupt initialization on brcm43362 Jean-Philippe Brucker
2019-12-26  9:47 ` Arend Van Spriel
2019-12-26 14:37   ` Dmitry Osipenko
2020-01-06 19:19     ` Jean-Philippe Brucker
2020-01-06 23:15       ` Dmitry Osipenko
2020-01-07  7:23         ` Jean-Philippe Brucker
2020-01-07 16:23           ` Dmitry Osipenko [this message]
2020-01-08  7:39             ` Jean-Philippe Brucker
2020-01-08 14:57               ` Dmitry Osipenko
2020-01-26 15:41 ` 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=34dbd037-0a40-bf5f-4988-6b821811ffcd@gmail.com \
    --to=digetx@gmail.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=brcm80211-dev-list@cypress.com \
    --cc=chi-hsien.lin@cypress.com \
    --cc=davem@davemloft.net \
    --cc=franky.lin@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=hdegoede@redhat.com \
    --cc=jean-philippe@linaro.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wright.feng@cypress.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.