linux-kernel - Re: [PATCH 2/2] misc: sram: switch to ioremap

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141211145849.GH31456@e104818-lin.cambridge.arm.com>
Date:	Thu, 11 Dec 2014 14:58:49 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Philipp Zabel <p.zabel@...gutronix.de>
Cc:	Will Deacon <Will.Deacon@....com>,
	Abhilash Kesavan <a.kesavan@...sung.com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Tony Lindgren <tony@...mide.com>,
	"heiko@...ech.de" <heiko@...ech.de>,
	"Li.Xiubo@...escale.com" <Li.Xiubo@...escale.com>,
	"shc_work@...l.ru" <shc_work@...l.ru>,
	"nicoleotsuka@...il.com" <nicoleotsuka@...il.com>,
	"arnd@...db.de" <arnd@...db.de>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"corbet@....net" <corbet@....net>,
	"padma.v@...sung.com" <padma.v@...sung.com>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	"shawn.guo@...escale.com" <shawn.guo@...escale.com>,
	"bcousson@...libre.com" <bcousson@...libre.com>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"kgene@...nel.org" <kgene@...nel.org>,
	"kesavan.abhilash@...il.com" <kesavan.abhilash@...il.com>,
	Pawel Moll <Pawel.Moll@....com>
Subject: Re: [PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap

On Thu, Dec 11, 2014 at 11:40:46AM +0000, Philipp Zabel wrote:
> Hi Will,
> 
> Am Donnerstag, den 11.12.2014, 10:39 +0000 schrieb Will Deacon:
> > On Thu, Dec 11, 2014 at 10:08:33AM +0000, Philipp Zabel wrote:
> > > Hi Abhilash,
> > > 
> > > Am Donnerstag, den 11.12.2014, 08:28 +0530 schrieb Abhilash Kesavan:
> > > > Currently, the SRAM allocator returns device memory via ioremap.
> > > > This causes issues on ARM64 when the internal SoC SRAM allocated by
> > > > the generic sram driver is used for audio playback. The destination
> > > > buffer address (which is ioremapped SRAM) is not 64-bit aligned for
> > > > certain streams (e.g. 44.1k sampling rate). In such cases we get
> > > > unhandled alignment faults. Use ioremap_wc in place of ioremap which
> > > > gives us normal non-cacheable memory instead of device memory.
> > > 
> > > Could this break the omap_bus_sync() implementation in
> > > arch/arm/mach-omap2/omap4-common.c?
> > > 
> > >     void omap_bus_sync(void)
> > >     {
> > >             if (dram_sync && sram_sync) {
> > >                     writel_relaxed(readl_relaxed(dram_sync), dram_sync);
> > >                     writel_relaxed(readl_relaxed(sram_sync), sram_sync);
> > >                     isb();
> > >             }
> > >     }
> > > 
> > > It is used in wmb() and omap_do_wfi() to drain interconnect write
> > > buffers on omap4/5. If sram_sync is mapped with write-combining, could
> > > the last write to sram_sync stay stuck in the write-combining buffer
> > > until after the function returns?
> > 
> > I think you have that issue anyway, since you can get an early write
> > response even if you use ioremap. Does the write to sram_sync have
> > side-effects that we need to wait for?
> 
> [Added Tony Lindgren and Santosh Shilimkar to Cc:]
> I don't know.

In addition to Will's question, do you care about the access size?
ioremap() returns Device memory which is bufferable (early
acknowledgement) but it guarantees the access size. With write
combining, you may get a different access size than requested.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/