lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 24 Aug 2017 11:37:01 -0700
From:   Stephen Boyd <sboyd@...eaurora.org>
To:     Shawn Guo <shawnguo@...nel.org>
Cc:     Kiran Gunda <kgunda@...eaurora.org>, gregkh@...uxfoundation.org,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Abhijeet Dharmapurikar <adharmap@...eaurora.org>,
        David Collins <collinsd@...eaurora.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-arm-msm-owner@...r.kernel.org
Subject: Re: [PATCH V2] spmi: pmic-arb: Enforce the ownership check optionally

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@...0: 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@...0: 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. Is there some sort of default configuration that
gets applied to all pins by default?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ