Received: by 10.213.65.68 with SMTP id h4csp552193imn; Tue, 13 Mar 2018 12:47:28 -0700 (PDT) X-Google-Smtp-Source: AG47ELtrtXi53Z5yp0H+R20PRoKFRdlLQN7IsPGGzfkau91VGMd+Ce7GiMO5bzNQFvSbEC+qltW6 X-Received: by 10.98.19.146 with SMTP id 18mr1719114pft.3.1520970448105; Tue, 13 Mar 2018 12:47:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520970448; cv=none; d=google.com; s=arc-20160816; b=oPTOUcLnYV7sAtQy54IT222hAJ2qXTLV+pwSRqLixRukgtprTMyDk7CVaGhzfSbh8a o8rcMdEIlhJC2HKPeafjW87Cmpuz2vI/d35eA0btXEOu+bPJcLJDJ5qLO0k//zJVAFAi psWgEVocK4gNNM860F6EyWxyFtH+K8jhnSDyl3Yo2dXciLfKbAcj3hbbhtDhuJcaSxrG p4nBy3H078UTc9sB0jDHw4Gnu5RaMqeIH9zm8f6HJQJPO+EqAMf9vRsfmUfcjL0aUEvG ZEgdQHcXHjVVisk18PLB2OtlcuZQ+DC+eDinF4BLAeemrTWG0xei7za6QZct71Qt3L/C Ihsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:dkim-signature:arc-authentication-results; bh=M/2omy9bW4HljjMzkzkVZNElxcKB3muL4HrYUnMIGNo=; b=gmYe/Hlx7umLuGRTs/BvQOzM2S59bEX29ddle0LI3oYLBkmLPg2d28tnzCN8vbV3sa Y9PO445dAwUNzzUdEhyK4D+sWq+WDPeXO2XWA1H0B/Jm4IGgbr4m6+Hm7rmqgPXtImB7 OwCNyL399iCA+e5mT5fT0bun+jPjNEqw74xCl+fWbIksH7q4fzsXFKU+X1GS+Vvi1YAU 8Nvx5wZMXRj/Dq3y3iKkCaRII5VEvX79tsSJY1eh74qrXK5y73UqvPn1CFtIMtpwHjxc 1USAPp/uy/EBp2eVg8wB6pvpTlnKwJg4vjt8VxDdfhSoK0j4lGyo16bNosm9Bdw9usG6 mDOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PhDr7Xsa; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x9si578780pgt.225.2018.03.13.12.47.13; Tue, 13 Mar 2018 12:47:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PhDr7Xsa; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752648AbeCMTqL (ORCPT + 99 others); Tue, 13 Mar 2018 15:46:11 -0400 Received: from mail-wr0-f170.google.com ([209.85.128.170]:45862 "EHLO mail-wr0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751714AbeCMTqJ (ORCPT ); Tue, 13 Mar 2018 15:46:09 -0400 Received: by mail-wr0-f170.google.com with SMTP id h2so2075428wre.12; Tue, 13 Mar 2018 12:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=M/2omy9bW4HljjMzkzkVZNElxcKB3muL4HrYUnMIGNo=; b=PhDr7XsavpQvqJSmZSa8Od7zd1jC83wOtpw1VuQASUxDySnUrNLqgkCVb/vWVED0Rm dAUA9eZ+kG1JyXt1OJMagnRj9K7mg5djtqXGiNEbgenA9pm6UXv/4HblGokDwtptI4Vg NceL0XPyW7nFV1lwK2IPPouw88mA7Ekw2MmETN+KnCwnyXAVm/wncfHoON98bt0E6BdM 8oaAtz0SKfV0m2U7SkItum4h6JKhN/4FEzNcUrq5r/wNL5t9JVIKuqW4xYGgUL+WSYQ3 VuZJz7E8uzHhK6uP/DXhzfQLkPg820k2NzWi3kNyofAQSCRp1Hm1u9AFZRLwOrTARi3k 0SYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=M/2omy9bW4HljjMzkzkVZNElxcKB3muL4HrYUnMIGNo=; b=hpoapefqJdGa6xPEssaGly6Z07dOVT6PH6e4Jx986zxTb9AGiwgvgvP1wWiToKfwpm wfkFvjFkGyTc0uEm/qa2CVsBK0iU3LePO7w57W2/dRJp0zO2eXSGHd1Yrf1Yb3uGE6F6 34jYa9VCCSvpLHCUCtydJt7XogTCRCwClBJIq5ibEnShZ1F3QmILdoZzINThVqkuHLPC KZ0nQMmr/lSrSVjlRxEtBr7bhtD5xtCI5Xg30Q9jq/9w4ICZh4am8Jall1IeRj0ioJOV uHmvyHD4OZFY3ypPxMb637sko3cC0p2+DirIA+57gd9NXCgS25MRtKnNrc8dRf+nSNC5 1Hog== X-Gm-Message-State: AElRT7FSGaH1URchV2u3o1k6BA9U60SYA14h5tG8vQvA+SQO8yQ7lQdR NAK/yijlsTE8Sg3Bhgbb4NiYQYkl X-Received: by 10.223.178.26 with SMTP id u26mr1652290wra.63.1520970367305; Tue, 13 Mar 2018 12:46:07 -0700 (PDT) Received: from [192.168.1.18] (dnp104.neoplus.adsl.tpnet.pl. [83.24.97.104]) by smtp.gmail.com with ESMTPSA id x10sm906152wrc.64.2018.03.13.12.46.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 12:46:06 -0700 (PDT) Subject: Re: [PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when setting delay_off=0 To: Pavel Machek , Greg KH References: <20180204090531.GA29468@amd> <20180204111500.GB14797@kroah.com> <20180204171736.GA1388@amd> <20180206020210.m6gl7vai4p6azb6s@sasha-lappy> <713113d8-7662-d80c-c62f-af020469d0bf@gmail.com> <20180312152811.GB16944@kroah.com> <5747831a-b237-aa2c-cb47-9773cd2b5956@universe-factory.net> <0cd72fe4-2b98-e6f7-6ae7-530524786cec@gmail.com> <20180313093703.GB27669@kroah.com> <20180313132748.GA20246@amd> Cc: Matthias Schiffer , Sasha Levin , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , Matthieu CASTET , "linux-leds@vger.kernel.org" From: Jacek Anaszewski X-Enigmail-Draft-Status: N1010 Message-ID: <7a59c129-60be-9c4b-6002-242b873e8468@gmail.com> Date: Tue, 13 Mar 2018 20:44:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20180313132748.GA20246@amd> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/13/2018 02:27 PM, Pavel Machek wrote: > Hi! > >>>> At least 7b6af2c531 ("leds: core: Fix regression caused by commit >>>> 2b83ff96f51d") is missing, causing visible regressions (LEDs not working at >>>> all) on some OpenWrt devices. This was fixed in 4.4.121 by reverting the >>>> offending commit, but if I followed the discussion correctly, 4.9 should >>>> get the follow-up commit 7b6af2c531 instead (like 4.14 already did). >>>> >>>> Jacek's mail I replied to mentions that eb1610b4c273 ("led: core: Fix >>>> blink_brightness setting race") should be included in 4.9 as well, but I >>>> don't know the impact of the issue it fixes. >>> >>> It doesn't fix any reported issue, but is just an improvement >>> aiming at preventing potential races while changing blink brightness. >>> >>> After taking closer look it turns out that for the patches in question >>> to apply cleanly we need in 4.9 also a patch which introduces atomic >>> bit fields for blink flags. >>> >>> Effectively, here is the list of patches required in 4.9 stable: >>> >>> Revert "led: core: Fix brightness setting when setting delay_off=0" >>> >>> followed by: >>> >>> a9c6ce57ec ("led: core: Use atomic bit-field for the blink-flags") >>> eb1610b4c2 ("led: core: Fix blink_brightness setting race") >>> 2b83ff96f5 ("led: core: Fix brightness setting when setting delay_off=0") >>> 7b6af2c531 ("leds: core: Fix regression caused by commit 2b83ff96f51d") >> >> Odd, I just got another report that the 4.9.87 release fixed some >> reported LED issues, so why do I need all of these? Because 2b83ff96f5 introduces another bug, fixed in 7b6af2c531. 7b6af2c531 in turn uses atomic blink flags introduced in a9c6ce57ec. eb1610b4c2 fixes theoretical races, actually we can do without it in stable. In order to avoid applying patch a9c6ce57ec, we could come up with the below change which does exactly what 7b6af2c531 intended, but without atomic blink flags, which are irrelevant for this bug. diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c index 3bce448..454ed4d 100644 --- a/drivers/leds/led-core.c +++ b/drivers/leds/led-core.c @@ -188,6 +188,7 @@ void led_blink_set(struct led_classdev *led_cdev, { del_timer_sync(&led_cdev->blink_timer); + led_cdev->flags &= ~LED_BLINK_SW; led_cdev->flags &= ~LED_BLINK_ONESHOT; led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP; I can submit it to stable if it is preferred. In every case tha patch 2b83ff96f5 needs to be reverted beforehand, since otherwise none of the discussed patches will apply cleanly (besides the aforementioned reasoning it has a truncated commit message). >> Should I just revert the single 2b83ff96f51d commit here instead? > > I believe so, yes. > > I'm not aware of any _really bad_ issues with LED subsystem in > 4.9. Take a look at changelog of > 2b83ff96f51d0b039c4561b9f95c824d7bddb85c -- it fixes rather > theoretical issue; user can reproduce it by hand in shell, but, > well... don't do it then. Greg mentioned that 4.9.87 release fixed some LED issue for someone, and it was the only LED related patch in that release. > The rest of fixes ... fix some more theoretical races. I don't think > it is -stable material, as I pointed out before. -- Best regards, Jacek Anaszewski