Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754416AbdHZDrA (ORCPT ); Fri, 25 Aug 2017 23:47:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:50688 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754091AbdHZDq6 (ORCPT ); Fri, 25 Aug 2017 23:46:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C26A521A2E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=shawnguo@kernel.org Date: Sat, 26 Aug 2017 11:46:38 +0800 From: Shawn Guo To: Stephen Boyd Cc: Kiran Gunda , gregkh@linuxfoundation.org, Rob Herring , Mark Rutland , Abhijeet Dharmapurikar , David Collins , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-msm-owner@vger.kernel.org Subject: Re: [PATCH V2] spmi: pmic-arb: Enforce the ownership check optionally Message-ID: <20170826034636.GG3685@dragon> References: <1503070110-15018-1-git-send-email-kgunda@codeaurora.org> <20170822085541.GB3685@dragon> <20170822203132.GC21656@codeaurora.org> <20170824121818.GE3685@dragon> <20170824183701.GN21656@codeaurora.org> <20170825074324.GF3685@dragon> <20170825231818.GP21656@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170825231818.GP21656@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2431 Lines: 55 On Fri, Aug 25, 2017 at 04:18:18PM -0700, Stephen Boyd wrote: > On 08/25, Shawn Guo wrote: > > On Thu, Aug 24, 2017 at 11:37:01AM -0700, Stephen Boyd wrote: > > > On 08/24, Shawn Guo wrote: > > > > On Tue, Aug 22, 2017 at 01:31:32PM -0700, Stephen Boyd wrote: > > > > > Also, I see that on v4.13-rc series the read/write checks are > > > > > causing the led driver to fail in a different way: > > > > > > > > > > spmi spmi-0: error: impermissible write to peripheral sid:0 addr:0xc040 > > > > > qcom-spmi-gpio 200f000.spmi:pm8916@0:gpios@c000: write 0x40 failed > > > > > leds-gpio soc:leds: Error applying setting, reverse things back > > > > > spmi spmi-0: error: impermissible write to peripheral sid:0 addr:0xc041 > > > > > qcom-spmi-gpio 200f000.spmi:pm8916@0:gpios@c000: write 0x41 failed > > > > > leds-gpio: probe of soc:leds failed with error -1 > > > > > > > > > > Are you seeing similar behavior? > > > > > > > > Yes. I forgot to mention that, and leds-gpio failure is gone after > > > > applying Kiran's patch below. > > > > > > > > spmi: pmic-arb: remove the read/write access checks > > > > > > > > > > Sure. Removing the checks will silence the warnings, but it still > > > means that we're attempting to configure GPIOs that we shouldn't > > > be configuring. > > > > The driver is attempting to configure the GPIOs that device tree tells > > to. > > > > led@3 { > > label = "apq8016-sbc:green:user3"; > > gpios = <&pm8916_gpios 1 GPIO_ACTIVE_HIGH>; > > linux,default-trigger = "mmc1"; > > default-state = "off"; > > }; > > > > Are you saying, in case of user3 led above, device tree shouldn't use > > GPIO <&pm8916_gpios 1> there at all? > > Right. Does the GPIO work? If so, it sounds like the read/write > access checks in spmi pmic arb don't work properly. The check works. With the check in there, PM8916 GPIO doesn't work. However, the consequence is that not only user3 but all GPIO leds under 'leds' node will fail to register, because any GPIO led's failing on create_gpio_led() makes leds-gpio driver probe fail as a while. That's how leds-gpio driver works. Also, per schematics, PM8916 GPIO1 is indeed routed to user3 LED on db410c board. Why do you think apq8016-sbc device tree shouldn't use the GPIO for that at all? Isn't it firmware's fault that the ownership of the peripheral is not properly configured? Shawn