From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753534AbcE0Lqp (ORCPT ); Fri, 27 May 2016 07:46:45 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:65318 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752711AbcE0Lqn (ORCPT ); Fri, 27 May 2016 07:46:43 -0400 X-AuditID: cbfec7f5-f792a6d000001302-01-5748339f43d1 Subject: Re: [PATCH] arm64: defconfig: Enable cros-ec and battery driver To: Jon Hunter , Rhyland Klein , Thierry Reding , Sebastian Reichel , David Woodhouse , Dmitry Eremin-Solenikov References: <1462290318-9074-1-git-send-email-rklein@nvidia.com> <5744609A.1000008@nvidia.com> <324dfe74-4fc0-d500-91ac-2a802562e92f@nvidia.com> <5745853B.1040304@nvidia.com> <57458693.3050700@nvidia.com> <20160525154618.GD13765@ulmo.ba.sec> <9411ff33-e375-8286-8690-fe7fcac1c14b@nvidia.com> <5745CE75.7010603@nvidia.com> <5745D2DD.6080300@nvidia.com> <1c6df907-ea1f-201b-a36e-8311c5b2b3b1@nvidia.com> <5745E031.7010406@nvidia.com> <5c03a025-f31d-fa18-b973-0b026ede9c5c@nvidia.com> <5748073F.1030704@samsung.com> <57482162.20306@nvidia.com> Cc: Stephen Warren , Alexandre Courbot , linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org From: Krzysztof Kozlowski X-Enigmail-Draft-Status: N1110 Message-id: <5748339E.9080504@samsung.com> Date: Fri, 27 May 2016 13:46:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-version: 1.0 In-reply-to: <57482162.20306@nvidia.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42I5/e/4Vd35xh7hBp/XaVpMevKe2WLiysnM FudePWKxaJm1iMXi9QtDi8u75rBZdH6ZxWax7PhqVovTu0ssXh1sY7G4/ZvPgdtj56y77B6b V2h5bFrVyebR2/yOzaNvyypGj8+b5Dw2zg0NYI/isklJzcksSy3St0vgyjj5fTJTwWThiv8X rzA2MB7j72Lk5JAQMJF4MO8mC4QtJnHh3nq2LkYuDiGBpYwSP8+2M4IkhASeMUrsX6kNYgsL eEg862gBaxAReMco8aOtAqJhA4vEi75/rCAOs0A/o8TLX+vAutkEjCU2L1/CBrFCTqK3exJY N6+AlsS1OQfBalgEVCV2z33JBGKLCkRIzNr+gwmiRlDix+R7YPWcAhoSD/4fYu9i5ABaoCdx /6IWSJhZQF5i85q3zBMYBWch6ZiFUDULSdUCRuZVjKKppckFxUnpuUZ6xYm5xaV56XrJ+bmb GCHx8nUH49JjVocYBTgYlXh4I1zdw4VYE8uKK3MPMUpwMCuJ8DobeYQL8aYkVlalFuXHF5Xm pBYfYpTmYFES5525632IkEB6YklqdmpqQWoRTJaJg1OqgdHps0e9Z9aM2SW3FY9+e+PGYt/a +fas3f3zLtsMVzFeyFjMe0r53yUF0Q5tl8jT0q+q5185ncq+u0/A8kiguoJgycz+XZ/a3Y1Y Lytzrz+SU6NusjqMP2brtgDJ9Cvz4kOmuS94qaZ2jlUpyXtX14blc49c+mSuX3Yt482r5+Lz p/5yCJnDukSJpTgj0VCLuag4EQBmu8nwkwIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/27/2016 12:28 PM, Jon Hunter wrote: > Hi Krzysztof, > > On 27/05/16 09:37, Krzysztof Kozlowski wrote: > > ... > >> Indeed I was struggling with similar issue in bq27x00_battery. The issue >> was introduced by... me :( when moving the ownership of power supply >> structure from driver to the core. However IMHO my change exposed the >> fundamental problem with power supply. >> >> Anyway a fix for this issue was: >> 7f1a57fdd6cb6e7b (power_supply: Fix possible NULL pointer dereference on >> early uevent) >> AFAIU, this fix no longer fixes all the issues, right? >> >> As for the fundamental problem, the power supply core should not call >> back the driver (get_property()) until the probe ends. Even if the >> di->bat was initialized, some other fields of driver could not be set >> yet. In general, the probe did not end so we should avoid calling driver >> internal functions. > > For my understanding, can you elaborate why the power-supply core should > not call back to the drivers ->get_property() before the probe ends? I > assume that registering the power-supply should be the last thing done > in the probe and so the power-supply should be configured at that point. It is not only about power supply but other resources allocated by the driver. If the power_supply_register() is a last call, then no problem. But if not, then these resources won't be available. Actually I exaggerated a little bit as a fundamental problem as this is quite common pattern. When driver provides something (like power supply) then after registration it should be ready for calls coming from the core or user space. It does not have to be power supply. It might be exposing sysfs entries or file operations (exposed before calling power_supply_register()). > The problems with the bq27xxx seem to stem from the periodic update of > the bq27xxx status and so it is not clear to me that this is a generic > problem for all power-supply devices. Initially, the generic problem was that the core would call back the driver from power_supply_register() in a synchronous way through power_supply_changed(). The commit 7f1a57fdd6c changed it to an asynchronous call. Here it looks like the same problem - the power_supply_register() calls thermal which calls thermal_zone_device_update() and we are back at the driver... before finishing power_supply_register() call. Best regards, Krzysztof