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:   Tue, 7 Dec 2021 18:21:03 -0800
From:   Katherine Perez <kaperez@...ux.microsoft.com>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Felipe Balbi <balbi@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] arm64: dts: sm8350: fix tlmm base address

On Tue, Dec 07, 2021 at 05:16:14PM +0530, Vinod Koul wrote:
> On 30-11-21, 21:15, Bjorn Andersson wrote:
> > On Mon 22 Nov 22:03 CST 2021, Vinod Koul wrote:
> > 
> > > On 22-11-21, 11:05, Katherine Perez wrote:
> > > > TLMM controller base address is incorrect and will hang on some platforms.
> > > > Fix by giving the correct address.
> > > 
> > > Thanks, recheck the spec this looks correct. We should have tlmm reg
> > > space here and not tlmm base which also contains xpu region (thus hang)
> > > 
> > 
> > Aren't you reading the patch backwards?
> 
> I guess :(
> 
> > Afaict downstream the driver carries an offset of 0x100000, which we
> > dropped as we upstreamed the driver. As such changing reg to 0x0f000000
> > should cause most gpio register accesses to fall outside the actual
> > register window.
> > 
> > Or perhaps I'm missing something here?
> 
> I relooked and XPU is at 0xF000000 and Reg at 0xF100000
> So this patch should be dropped as such. The size mentioned in
> documentation is also correct
> 
> Katherine, can you elaborate more on the hang you have observed? Any
> specific pins you use which causes this?

Hi Vinod,

Yes, it seems to hang in msm_pinctrl_probe. Specifically, line 734 in
gpiolib.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpiolib.c#n734.
On i=4, it hangs on assign_bit and the system goes into a reboot loop.
When I set the TLMM address to f000000, I don't see this issue at all.

> 
> 
> -- 
> ~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ