[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <16b56fe39f0.2764.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
Date: Fri, 14 Jun 2019 19:17:10 +0200
From: Arend Van Spriel <arend.vanspriel@...adcom.com>
To: Doug Anderson <dianders@...omium.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Adrian Hunter <adrian.hunter@...el.com>
CC: Kalle Valo <kvalo@...eaurora.org>,
<brcm80211-dev-list.pdl@...adcom.com>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
Double Lo <double.lo@...ress.com>,
Brian Norris <briannorris@...omium.org>,
"linux-wireless" <linux-wireless@...r.kernel.org>,
Naveen Gupta <naveen.gupta@...ress.com>,
Madhan Mohan R <madhanmohan.r@...ress.com>,
Matthias Kaehlcke <mka@...omium.org>,
Wright Feng <wright.feng@...ress.com>,
"Chi-Hsien Lin" <chi-hsien.lin@...ress.com>,
netdev <netdev@...r.kernel.org>,
"brcm80211-dev-list" <brcm80211-dev-list@...ress.com>,
<linux-mmc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
Avri Altman <avri.altman@....com>
Subject: Re: [PATCH v4 4/5] mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()
On June 14, 2019 6:38:51 PM Doug Anderson <dianders@...omium.org> wrote:
> Hi,
>
> On Fri, Jun 14, 2019 at 5:10 AM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>>
>> On Fri, 14 Jun 2019 at 01:42, Douglas Anderson <dianders@...omium.org> wrote:
>> >
>> > We want SDIO drivers to be able to temporarily stop retuning when the
>> > driver knows that the SDIO card is not in a state where retuning will
>> > work (maybe because the card is asleep). We'll move the relevant
>> > functions to a place where drivers can call them.
>> >
>> > Signed-off-by: Douglas Anderson <dianders@...omium.org>
>>
>> This looks good to me.
>>
>> BTW, seems like this series is best funneled via my mmc tree, no? In
>> such case, I need acks for the brcmfmac driver patches.
>
> For patch #1 I think it could just go in directly to the wireless
> tree. It should be fine to land the rest of the patches separately.
Agree.
> For patch #2 - #5 then what you say makes sense to me. I suppose
> you'd want at least a Reviewed-by from Arend and an Ack from Kalle on
> the Broadcom patches?
Will do.
> I'd also suggest that we Cc stable explicitly when applying. That's
> easy for #2 and #3 since they have a Fixes tag. For #4 and #5 I guess
> the question is how far back to go. Maybe Adrian has an opinion here
> since I think he's the one who experienced these problems.
I see if I can come up wit a fixes tag for #5.
Regards,
Arend
Powered by blists - more mailing lists