Message ID | 9f8a0fc3-1d9a-b271-3c26-4f7373b8a3e9@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp1396370wru; Sat, 29 Oct 2022 08:27:42 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4eCXXS4C5qJeCepAmJWMllD1Tsxg+Yk4zdbAmy3MLYLqdzFBgOFEZRkBNn6GBgevJk4klx X-Received: by 2002:a17:902:eb92:b0:186:7067:3e9a with SMTP id q18-20020a170902eb9200b0018670673e9amr4873210plg.80.1667057262157; Sat, 29 Oct 2022 08:27:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667057262; cv=none; d=google.com; s=arc-20160816; b=Slo0CRYjJgv/8pAD4hqpoBHsH98Au4dXYI+vAoamgeFx+ByohuKRs7ODbi5nP9+qS/ tn7ckikMYoKhiwF927EhrgbO9Nama8OT6q3+ck4cPyc30AJT17o0aB/71sDQyxYmxEXS auGlQpcTz5IQl0NBj1vTpu/xQ1iJK/U5MBXe53NB6lXd+5P96qnBDAeKVoYsMFcER40c wj5hDg72s3kmwr2ykxDh5klyF365GbOhDNU1dZ/GRG+ul4I2QpzzNnWpnCeMP3Ws7uEI en6vu5UNCjnf4mEKqXFzYBQIUBeh+RrXvWG4cN1HypeFOBQMN/2kbwhJJlZYC//SsYsU tnMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:user-agent:date:message-id:subject:from:cc:to :dkim-signature; bh=LM0zNyCG6vu1EkX5rDqFjfE2Q0rAIzB1wYhK7YvnQns=; b=lpXs4dcoQROds4QFoou0dP4B+cX69wiicGjOd/0nNyIDXwWeDEvzUYwxHN46HaOD7P NmyMqcJYrnD7R8jEvEa4RufW9pdWLGGHBONmKc9twkO7GZgrO4FC4sXhWvRiClzHCZDN BBgmFBKpLw2+AW5jaybPERo2PXGAIVCF3GIhFoUMAiEs0F+pMMc7ZLS1pRWhJ5pIVfo+ af8WQmgAKT9or+L5MOQtpIEFriXfU9pLmvK3+yFFWFs54I4WBuNk4EYaRU9z4W7yIA/g DrIC52mc6YSkODWE6G8c8XWTBjlz05mx6yfGSKh9Bqe7Irw991zXFa6Wxdn6Rau6OI86 nYHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=juD2ya3o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d16-20020a170902ced000b00186abc34277si2059960plg.263.2022.10.29.08.27.28; Sat, 29 Oct 2022 08:27:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=juD2ya3o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S229729AbiJ2PXu (ORCPT <rfc822;pusanteemu@gmail.com> + 99 others); Sat, 29 Oct 2022 11:23:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229528AbiJ2PXt (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 29 Oct 2022 11:23:49 -0400 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20FC651A0B for <linux-kernel@vger.kernel.org>; Sat, 29 Oct 2022 08:23:48 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id f27so19542965eje.1 for <linux-kernel@vger.kernel.org>; Sat, 29 Oct 2022 08:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:content-language:mime-version:user-agent :date:message-id:subject:from:cc:to:from:to:cc:subject:date :message-id:reply-to; bh=LM0zNyCG6vu1EkX5rDqFjfE2Q0rAIzB1wYhK7YvnQns=; b=juD2ya3o94qMIsY8wraqg+F+Qd2G6JeimGfqSmHC2B1NwGQ0B3tn65TlxYbQAu8iOe sm/SU/BP21gVtp/zaXfagzyJPVRX2bJVtW1WPI9aF8/V+tS3+ErGABMslZgJUZle8Eru J4avK/5g/EmAlL93IR7KcbCgIzjKuC+RTTsJhKspyG4pXD2JUOsZsrP/pSo3PGGvmlpK L52/k8K6AUjBejickvlE5qICWZV4xDfvo+sftFbUSjW9XLL5vxzShdumRtJDwLDNCsjq sjvP1fyfEKmJtIjY82ShMZD29FGDnSpIvncz7K57KfHytH/AI56iP9jIpXkc9Gb3S8KL 1g+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:mime-version:user-agent :date:message-id:subject:from:cc:to:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LM0zNyCG6vu1EkX5rDqFjfE2Q0rAIzB1wYhK7YvnQns=; b=DVP6axDjIZqDKirxskWPje4JdWWIYhy96ZGjPbs6oCN6yEa6jjsC0ibrUZNQjZc562 cW3VcseP3l4o/0QDxZjBgw7B5o2EVRa+PafSh5JiKi1yVIA1+HoQfXzivMCi/4POaHC6 fgjQLK8eYg4N8N28p9rsXhuF754enWXaXV4HEqvFPzo+No6jZ/eM518f5wXyIn/Uz0gV kXXvrMniM1cSgr6iESVlKAszFEkHZFSvlNQwDpZ2tsqUVgvoJSDc3+t6SEPP9d7kfWdV SDqmfewjqBQud80cppID4IEUmHEH8est5t7KLWVywlzY4O4+eCHgcv5Mym6xMXl4me3u 6Aaw== X-Gm-Message-State: ACrzQf3LgdZgJq0ctfV3wSWnZSziteCyGPkT7HmOGeZ2XO0lpwdlhkX2 FFVVVLZ8a+9HAkkbH9Xyl7J6pLGByt/0FQ== X-Received: by 2002:a17:907:97c3:b0:79b:3f8d:a354 with SMTP id js3-20020a17090797c300b0079b3f8da354mr4285123ejc.461.1667057026596; Sat, 29 Oct 2022 08:23:46 -0700 (PDT) Received: from [192.168.1.10] ([46.249.74.23]) by smtp.googlemail.com with ESMTPSA id gg33-20020a17090689a100b0078b03d57fa7sm787034ejc.34.2022.10.29.08.23.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2022 08:23:46 -0700 (PDT) To: wens@csie.org, samuel@sholland.org Cc: mripard@kernel.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Merlijn Wajer <merlijn@wizzup.org> From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Subject: [BISECTED] Allwinner A33 tablet does not fully power off Message-ID: <9f8a0fc3-1d9a-b271-3c26-4f7373b8a3e9@gmail.com> Date: Sat, 29 Oct 2022 18:23:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748036236039877721?= X-GMAIL-MSGID: =?utf-8?q?1748036236039877721?= |
Series |
[BISECTED] Allwinner A33 tablet does not fully power off
|
|
Commit Message
Ivaylo Dimitrov
Oct. 29, 2022, 3:23 p.m. UTC
Hi, After commit 843107498f91e57d1d4b22cd8787112726fdaeb4 (bus: sunxi-rsb: Implement suspend/resume/shutdown callbacks) Q8 A33 tablet I have here cannot be powered-on after power-off, it needs press-and-hold of the power button for 10 seconds (I guess some HW assisted power down happens) before it can be powered-on again. The following patch makes it behave correctly: static const struct dev_pm_ops sunxi_rsb_dev_pm_ops = { I guess the issue comes from the fact that by the time 'power off' command to the power management IC has to be send, the bus it lives on is already down, so the device is left in semi-powered down state. Ofc this is a wild guess, however, preventing the bus being turned off on shutdown fixes the issue. Please LMK if the above is the correct approach so I will send a proper patch or something else shall be fixed. Ivo
Comments
Hi Ivo, On 10/29/22 10:23, Ivaylo Dimitrov wrote: > After commit 843107498f91e57d1d4b22cd8787112726fdaeb4 (bus: sunxi-rsb: > Implement suspend/resume/shutdown callbacks) Q8 A33 tablet I have here > cannot be powered-on after power-off, it needs press-and-hold of the > power button for 10 seconds (I guess some HW assisted power down > happens) before it can be powered-on again. > > The following patch makes it behave correctly: > > diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c > index 60b082fe2ed0..30016d62044c 100644 > --- a/drivers/bus/sunxi-rsb.c > +++ b/drivers/bus/sunxi-rsb.c > @@ -818,10 +818,7 @@ static int sunxi_rsb_remove(struct platform_device > *pdev) > > static void sunxi_rsb_shutdown(struct platform_device *pdev) > { > - struct sunxi_rsb *rsb = platform_get_drvdata(pdev); > - > pm_runtime_disable(&pdev->dev); > - sunxi_rsb_hw_exit(rsb); > } > > static const struct dev_pm_ops sunxi_rsb_dev_pm_ops = { > > > I guess the issue comes from the fact that by the time 'power off' > command to the power management IC has to be send, the bus it lives on > is already down, so the device is left in semi-powered down state. Ofc > this is a wild guess, however, preventing the bus being turned off on > shutdown fixes the issue. Your guess is correct. The controller gets shut down in kernel_power_off() kernel_shutdown_prepare() device_shutdown() but the PMIC communication needs to happen later in kernel_power_off() machine_power_off() pm_power_off() > Please LMK if the above is the correct approach so I will send a proper > patch or something else shall be fixed. Yes, this is exactly the right approach. The whole sunxi_rsb_shutdown() function should be removed. When you send a patch, please add a Fixes: tag referencing the commit that you bisected to. Regards, Samuel
Hi Samuel, On 5.11.22 г. 4:21 ч., Samuel Holland wrote: > Hi Ivo, > > On 10/29/22 10:23, Ivaylo Dimitrov wrote: >> After commit 843107498f91e57d1d4b22cd8787112726fdaeb4 (bus: sunxi-rsb: >> Implement suspend/resume/shutdown callbacks) Q8 A33 tablet I have here >> cannot be powered-on after power-off, it needs press-and-hold of the >> power button for 10 seconds (I guess some HW assisted power down >> happens) before it can be powered-on again. >> >> The following patch makes it behave correctly: >> >> diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c >> index 60b082fe2ed0..30016d62044c 100644 >> --- a/drivers/bus/sunxi-rsb.c >> +++ b/drivers/bus/sunxi-rsb.c >> @@ -818,10 +818,7 @@ static int sunxi_rsb_remove(struct platform_device >> *pdev) >> >> static void sunxi_rsb_shutdown(struct platform_device *pdev) >> { >> - struct sunxi_rsb *rsb = platform_get_drvdata(pdev); >> - >> pm_runtime_disable(&pdev->dev); >> - sunxi_rsb_hw_exit(rsb); >> } >> >> static const struct dev_pm_ops sunxi_rsb_dev_pm_ops = { >> >> >> I guess the issue comes from the fact that by the time 'power off' >> command to the power management IC has to be send, the bus it lives on >> is already down, so the device is left in semi-powered down state. Ofc >> this is a wild guess, however, preventing the bus being turned off on >> shutdown fixes the issue. > > Your guess is correct. The controller gets shut down in > > kernel_power_off() > kernel_shutdown_prepare() > device_shutdown() > > but the PMIC communication needs to happen later in > > kernel_power_off() > machine_power_off() > pm_power_off() > >> Please LMK if the above is the correct approach so I will send a proper >> patch or something else shall be fixed. > > Yes, this is exactly the right approach. The whole sunxi_rsb_shutdown() Don't we need pm_runtime_disable() on shutdown? As IIUC, the controller might be suspended and we have to resume it to put it in state to accept commands later on(in pm_power_off()). Regards, Ivo > function should be removed. When you send a patch, please add a Fixes: > tag referencing the commit that you bisected to. > > Regards, > Samuel >
On 11/5/22 03:23, Ivaylo Dimitrov wrote: > Hi Samuel, > > On 5.11.22 г. 4:21 ч., Samuel Holland wrote: >> Hi Ivo, >> >> On 10/29/22 10:23, Ivaylo Dimitrov wrote: >>> After commit 843107498f91e57d1d4b22cd8787112726fdaeb4 (bus: sunxi-rsb: >>> Implement suspend/resume/shutdown callbacks) Q8 A33 tablet I have here >>> cannot be powered-on after power-off, it needs press-and-hold of the >>> power button for 10 seconds (I guess some HW assisted power down >>> happens) before it can be powered-on again. >>> >>> The following patch makes it behave correctly: >>> >>> diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c >>> index 60b082fe2ed0..30016d62044c 100644 >>> --- a/drivers/bus/sunxi-rsb.c >>> +++ b/drivers/bus/sunxi-rsb.c >>> @@ -818,10 +818,7 @@ static int sunxi_rsb_remove(struct platform_device >>> *pdev) >>> >>> static void sunxi_rsb_shutdown(struct platform_device *pdev) >>> { >>> - struct sunxi_rsb *rsb = platform_get_drvdata(pdev); >>> - >>> pm_runtime_disable(&pdev->dev); >>> - sunxi_rsb_hw_exit(rsb); >>> } >>> >>> static const struct dev_pm_ops sunxi_rsb_dev_pm_ops = { >>> >>> >>> I guess the issue comes from the fact that by the time 'power off' >>> command to the power management IC has to be send, the bus it lives on >>> is already down, so the device is left in semi-powered down state. Ofc >>> this is a wild guess, however, preventing the bus being turned off on >>> shutdown fixes the issue. >> >> Your guess is correct. The controller gets shut down in >> >> kernel_power_off() >> kernel_shutdown_prepare() >> device_shutdown() >> >> but the PMIC communication needs to happen later in >> >> kernel_power_off() >> machine_power_off() >> pm_power_off() >> >>> Please LMK if the above is the correct approach so I will send a proper >>> patch or something else shall be fixed. >> >> Yes, this is exactly the right approach. The whole sunxi_rsb_shutdown() > > Don't we need pm_runtime_disable() on shutdown? As IIUC, the controller > might be suspended and we have to resume it to put it in state to accept > commands later on(in pm_power_off()). sunxi_rsb_write() takes care of resuming the controller, so the controller being suspended prior to pm_power_off() is fine. pm_runtime_disable() would actually prevent resuming the controller later in sunxi_rsb_write(). >> function should be removed. When you send a patch, please add a Fixes: >> tag referencing the commit that you bisected to. I found a couple of other issues as well, so I'll send out some fixes with you CC'd. Regards, Samuel
On 5.11.22 г. 21:18 ч., Samuel Holland wrote: > On 11/5/22 03:23, Ivaylo Dimitrov wrote: >> Hi Samuel, >> >> On 5.11.22 г. 4:21 ч., Samuel Holland wrote: >>> Hi Ivo, >>> >>> On 10/29/22 10:23, Ivaylo Dimitrov wrote: >>>> After commit 843107498f91e57d1d4b22cd8787112726fdaeb4 (bus: sunxi-rsb: >>>> Implement suspend/resume/shutdown callbacks) Q8 A33 tablet I have here >>>> cannot be powered-on after power-off, it needs press-and-hold of the >>>> power button for 10 seconds (I guess some HW assisted power down >>>> happens) before it can be powered-on again. >>>> >>>> The following patch makes it behave correctly: >>>> >>>> diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c >>>> index 60b082fe2ed0..30016d62044c 100644 >>>> --- a/drivers/bus/sunxi-rsb.c >>>> +++ b/drivers/bus/sunxi-rsb.c >>>> @@ -818,10 +818,7 @@ static int sunxi_rsb_remove(struct platform_device >>>> *pdev) >>>> >>>> static void sunxi_rsb_shutdown(struct platform_device *pdev) >>>> { >>>> - struct sunxi_rsb *rsb = platform_get_drvdata(pdev); >>>> - >>>> pm_runtime_disable(&pdev->dev); >>>> - sunxi_rsb_hw_exit(rsb); >>>> } >>>> >>>> static const struct dev_pm_ops sunxi_rsb_dev_pm_ops = { >>>> >>>> >>>> I guess the issue comes from the fact that by the time 'power off' >>>> command to the power management IC has to be send, the bus it lives on >>>> is already down, so the device is left in semi-powered down state. Ofc >>>> this is a wild guess, however, preventing the bus being turned off on >>>> shutdown fixes the issue. >>> >>> Your guess is correct. The controller gets shut down in >>> >>> kernel_power_off() >>> kernel_shutdown_prepare() >>> device_shutdown() >>> >>> but the PMIC communication needs to happen later in >>> >>> kernel_power_off() >>> machine_power_off() >>> pm_power_off() >>> >>>> Please LMK if the above is the correct approach so I will send a proper >>>> patch or something else shall be fixed. >>> >>> Yes, this is exactly the right approach. The whole sunxi_rsb_shutdown() >> >> Don't we need pm_runtime_disable() on shutdown? As IIUC, the controller >> might be suspended and we have to resume it to put it in state to accept >> commands later on(in pm_power_off()). > > sunxi_rsb_write() takes care of resuming the controller, so the > controller being suspended prior to pm_power_off() is fine. > pm_runtime_disable() would actually prevent resuming the controller > later in sunxi_rsb_write(). > I see. >>> function should be removed. When you send a patch, please add a Fixes: >>> tag referencing the commit that you bisected to. > > I found a couple of other issues as well, so I'll send out some fixes > with you CC'd. > Ok, thanks. What about stable kernels, poweroff is broken since 843107498f91e57d1d4b22cd8787112726fdaeb4? Regards, Ivo > Regards, > Samuel >
Dne nedelja, 06. november 2022 ob 08:15:40 CET je Ivaylo Dimitrov napisal(a): > On 5.11.22 г. 21:18 ч., Samuel Holland wrote: > > On 11/5/22 03:23, Ivaylo Dimitrov wrote: > >> Hi Samuel, > >> > >> On 5.11.22 г. 4:21 ч., Samuel Holland wrote: > >>> Hi Ivo, > >>> > >>> On 10/29/22 10:23, Ivaylo Dimitrov wrote: > >>>> After commit 843107498f91e57d1d4b22cd8787112726fdaeb4 (bus: sunxi-rsb: > >>>> Implement suspend/resume/shutdown callbacks) Q8 A33 tablet I have here > >>>> cannot be powered-on after power-off, it needs press-and-hold of the > >>>> power button for 10 seconds (I guess some HW assisted power down > >>>> happens) before it can be powered-on again. > >>>> > >>>> The following patch makes it behave correctly: > >>>> > >>>> diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c > >>>> index 60b082fe2ed0..30016d62044c 100644 > >>>> --- a/drivers/bus/sunxi-rsb.c > >>>> +++ b/drivers/bus/sunxi-rsb.c > >>>> @@ -818,10 +818,7 @@ static int sunxi_rsb_remove(struct platform_device > >>>> *pdev) > >>>> > >>>> static void sunxi_rsb_shutdown(struct platform_device *pdev) > >>>> { > >>>> > >>>> - struct sunxi_rsb *rsb = platform_get_drvdata(pdev); > >>>> - > >>>> > >>>> pm_runtime_disable(&pdev->dev); > >>>> > >>>> - sunxi_rsb_hw_exit(rsb); > >>>> > >>>> } > >>>> > >>>> static const struct dev_pm_ops sunxi_rsb_dev_pm_ops = { > >>>> > >>>> I guess the issue comes from the fact that by the time 'power off' > >>>> command to the power management IC has to be send, the bus it lives on > >>>> is already down, so the device is left in semi-powered down state. Ofc > >>>> this is a wild guess, however, preventing the bus being turned off on > >>>> shutdown fixes the issue. > >>> > >>> Your guess is correct. The controller gets shut down in > >>> > >>> kernel_power_off() > >>> kernel_shutdown_prepare() > >>> device_shutdown() > >>> > >>> but the PMIC communication needs to happen later in > >>> > >>> kernel_power_off() > >>> machine_power_off() > >>> pm_power_off() > >>> > >>>> Please LMK if the above is the correct approach so I will send a proper > >>>> patch or something else shall be fixed. > >>> > >>> Yes, this is exactly the right approach. The whole sunxi_rsb_shutdown() > >> > >> Don't we need pm_runtime_disable() on shutdown? As IIUC, the controller > >> might be suspended and we have to resume it to put it in state to accept > >> commands later on(in pm_power_off()). > > > > sunxi_rsb_write() takes care of resuming the controller, so the > > controller being suspended prior to pm_power_off() is fine. > > pm_runtime_disable() would actually prevent resuming the controller > > later in sunxi_rsb_write(). > > I see. > > >>> function should be removed. When you send a patch, please add a Fixes: > >>> tag referencing the commit that you bisected to. > > > > I found a couple of other issues as well, so I'll send out some fixes > > with you CC'd. > > Ok, thanks. What about stable kernels, poweroff is broken since > 843107498f91e57d1d4b22cd8787112726fdaeb4? All changes must first hit latest development branch. If they are marked with fixes tag, they get automatically backported in all currently maintained kernels (mostly LTS) if applicable. But this will take a while. Best regards, Jernej > > Regards, > Ivo > > > Regards, > > Samuel
diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c index 60b082fe2ed0..30016d62044c 100644 --- a/drivers/bus/sunxi-rsb.c +++ b/drivers/bus/sunxi-rsb.c @@ -818,10 +818,7 @@ static int sunxi_rsb_remove(struct platform_device *pdev) static void sunxi_rsb_shutdown(struct platform_device *pdev) { - struct sunxi_rsb *rsb = platform_get_drvdata(pdev); - pm_runtime_disable(&pdev->dev); - sunxi_rsb_hw_exit(rsb); }