From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:37170 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726275AbeJZTf4 (ORCPT ); Fri, 26 Oct 2018 15:35:56 -0400 Date: Fri, 26 Oct 2018 06:59:16 -0400 From: Sasha Levin To: Johan Hovold Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org, =?iso-8859-1?Q?Bj=F8rn?= Mork Subject: Re: [PATCH AUTOSEL 3.18 04/98] USB: qcserial: Fix support for HP lt4112 LTE/HSPA+ Gobi 4G Modem Message-ID: <20181026105916.GE2015@sasha-vm> References: <20181025141853.214051-1-sashal@kernel.org> <20181025141853.214051-4-sashal@kernel.org> <20181026084920.GB27852@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20181026084920.GB27852@localhost> Sender: stable-owner@vger.kernel.org List-ID: On Fri, Oct 26, 2018 at 10:49:20AM +0200, Johan Hovold wrote: >On Thu, Oct 25, 2018 at 10:17:19AM -0400, Sasha Levin wrote: >> From: Bj�rn Mork >> >> [ Upstream commit 59536da34513c594af2a6fd35ba65ea45b6960a1 ] >> >> The DEVICE_HWI type was added under the faulty assumption that Huawei >> devices based on Qualcomm chipsets and firmware use the static USB >> interface numbering known from Gobi devices. But this model does >> not apply to Huawei devices like the HP branded lt4112 (Huawei me906e). >> Huawei firmwares will dynamically assign interface numbers. Functions >> are renumbered when the firmware is reconfigured. >> >> Fix by changing the DEVICE_HWI type to use a simplified version >> of Huawei's subclass + protocol scheme: Blacklisting known network >> interface combinations and assuming the rest are serial. >> >> Reported-and-tested-by: Muri Nicanor >> Tested-by: Martin Hauke >> Cc: >> Fixes: e7181d005e84 ("USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem") >> Signed-off-by: Bj�rn Mork >> Signed-off-by: Johan Hovold >> Signed-off-by: Sasha Levin > >This one is interesting though; it was marked for stable and has a >proper fixes tag for a commit that went into 4.19. That patch in turn >had a stable tag (new device id type patch) and was backported also to >other active stable trees at the time. > >Guess the stable maintainers need to check if the offending patch has >already been backported when determining how far back to apply a follow >up fix. > >Note that the stable tag above lacks a version comment (e.g. "# 4.19"), >but I can see how that may be too subtle to convey this (and not all >maintainers use those). Perhaps an explicit comment should just be added >in such cases. Right, the whole "fix for a fix" issue is what this patch series tries to address (you'll notice that *most* commits follow this pattern). I'm not sure why Greg's tools missed it to begin with, but hopefully this patch series will catch up with that. -- Thanks, Sasha