[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hpnjrku5e.wl-tiwai@suse.de>
Date: Mon, 23 Sep 2019 15:40:45 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Sasha Levin <sashal@...nel.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.2 072/185] ALSA: hda: Add codec on bus address table lately
On Mon, 23 Sep 2019 15:30:25 +0200,
Sasha Levin wrote:
>
> On Sun, Sep 22, 2019 at 09:06:12PM +0200, Takashi Iwai wrote:
> >On Sun, 22 Sep 2019 20:47:30 +0200,
> >Sasha Levin wrote:
> >>
> >> From: Takashi Iwai <tiwai@...e.de>
> >>
> >> [ Upstream commit ee5f85d9290fe25d460bd320b7fe073075d72d33 ]
> >>
> >> The call of snd_hdac_bus_add_device() is needed only for registering
> >> the codec onto the bus caddr_tbl[] that is referred essentially only
> >> in the unsol event handler. That is, the reason of this call and the
> >> release by the counter-part function snd_hdac_bus_remove_device() is
> >> just to assure that the unsol event gets notified to the codec.
> >>
> >> But the current implementation of the unsol notification wouldn't work
> >> properly when the codec is still in a premature init state. So this
> >> patch tries to work around it by delaying the caddr_tbl[] registration
> >> at the point of snd_hdac_device_register().
> >>
> >> Also, the order of snd_hdac_bus_remove_device() and device_del() calls
> >> are shuffled to make sure that the unsol event is masked before
> >> deleting the device.
> >>
> >> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204565
> >> Signed-off-by: Takashi Iwai <tiwai@...e.de>
> >> Signed-off-by: Sasha Levin <sashal@...nel.org>
> >
> >The upstream commit was reverted later by 246bb4aaa4f4, which has even
> >Fixes tag pointing this. So please drop this.
>
> I'll drop it, thank you.
>
> >BTW, this is the second time AUTOSEL overlooked the existing revert.
> >I'm afraid something is missing in the check.
>
> Usually it's the case that I check for fixes/reverts once I compile the
> series, and again right before I queue it up to a stable tree. In
> between fixes and reverts tend to sneak in just like in this case.
>
> In general, I also check the -rcs for fixes and reverts during their
> review window, so while sometimes we send out mails with patches that
> have a fix or revert upstream, they rarely make it into a released
> stable kernel.
IMO, it'd be great if you have some check before sending for reviews.
The Fixes tag chain can be parsed relatively easily, after all.
thanks,
Takashi
Powered by blists - more mailing lists