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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160322192951.GP9329@atomide.com>
Date:	Tue, 22 Mar 2016 12:29:52 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Peter Ujfalusi <peter.ujfalusi@...com>
Cc:	Paul Walmsley <paul@...an.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Jarkko Nikula <jarkko.nikula@...mer.com>,
	Tero Kristo <t-kristo@...com>, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, alsa-devel@...a-project.org
Subject: Re: [PATCH 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone

* Peter Ujfalusi <peter.ujfalusi@...com> [160322 01:54]:
> Tony,
> 
> On 03/21/16 22:21, Tony Lindgren wrote:
> > Hi,
> > 
> > * Peter Ujfalusi <peter.ujfalusi@...com> [160321 01:39]:
> >>
> >> This is also interesting:
> >> McBSP2 sidetone is in region 39 and 40 (module and L4 interconnect) which is
> >> unique in case of OMAP34xx and OMAP35xx, but it is overlapping with GPIO6 on
> >> OMAP36xx. Not sure what are the implications.
> > 
> > Hmm GPIO6 is in a different L4 segment though? Maybe
> > you did not account for the segments?
> > 
> > 0x49000000 + 0x20000 + 0x2000/0x4000/0x6000 for McBSP
> > 0x49000000 + 0x50000 + 0x8000 for GPIO6
> > 
> > Or maybe I don't understand at which physical address the
> > overlap is? :)
> 
> The addresses are not overlapping, but the Region Numbers for GPIO6 and McBSP2
> sidetone in Table 9-114 "Region Allocation for
> L4-Per Interconnect". But only in case of OMAP36xx

Oh OK, yeah the TRM region numbers are wrong, they skip unused
entries compared to the hardware AP table :) Basically the
TRM AP region numbering is useless and wrong.

Regards,

Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ