linux-kernel - Re: [PATCH v5 06/11] drivers: of: initialize and assign reserved memory to newly created devices

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: <530F0F24.2080903@samsung.com>
Date:	Thu, 27 Feb 2014 11:10:44 +0100
From:	Marek Szyprowski <m.szyprowski@...sung.com>
To:	Grant Likely <grant.likely@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linaro-mm-sig@...ts.linaro.org, devicetree@...r.kernel.org,
	linux-doc@...r.kernel.org
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Arnd Bergmann <arnd@...db.de>,
	Michal Nazarewicz <mina86@...a86.com>,
	Tomasz Figa <t.figa@...sung.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Laura Abbott <lauraa@...eaurora.org>,
	Rob Herring <robh+dt@...nel.org>,
	Olof Johansson <olof@...om.net>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Kumar Gala <galak@...eaurora.org>,
	Nishanth Peethambaran <nishanth.p@...il.com>,
	Marc <marc.ceeeee@...il.com>,
	Josh Cartwright <joshc@...eaurora.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH v5 06/11] drivers: of: initialize and assign reserved
 memory to newly created devices

Hello,

On 2014-02-26 13:14, Grant Likely wrote:
> On Fri, 21 Feb 2014 13:25:22 +0100, Marek Szyprowski <m.szyprowski@...sung.com> wrote:
> > Use recently introduced of_reserved_mem_device_init() function to
> > automatically assign respective reserved memory region to the newly created
> > platform and amba device.
> >
> > Signed-off-by: Marek Szyprowski <m.szyprowski@...sung.com>
>
> I'm wary on this patch. It hides the assignment of regions into the core
> code and I worry that it is the wrong level of abstraction. I would
> think that drivers should know that they need a reserved memory region
> and should be calling the API to obtain the region directly rather than
> doing it for them. The reason being is that there may be some situations
> where the common code isn't quite right and the driver needs to override
> the behaviour. If it is called automatically then the driver cannot do
> that.
>
> Is it really a big burden to have the driver call the reserved memory
> init function?

If a device requires very special handling of the reserved memory region,
it may simply provide its own reserved memory region driver which will do
the required early initialization.

If we assume that driver needs to initialize reserved region manually, then
why do we ever bother with adding support for custom reserved memory drivers
and assigning regions to a device node? We can simply stick with just a set
of reserved regions and tell drivers to use them.

In my opinion for most typical use cases a board designer will assign
'dma-shared-pool' driver to the given set of devices, which in turn ensures
that all memory allocations for dma purposes for those device will be
served from that region. It is really not a driver role to initialize it
in such case. Driver should focus on controlling hw operations, regardless
the way the hardware module has been integrated to the system.

I can perfectly imagine a generic driver which operates the same way in any
of the following cases (depends mainly on the hw version): 1) restricted
dma window, 2) iommu for all dma for the given device, 3) fully featured
memory master for dma for the given device (no restrictions), if the
respective kernel subsystems did the correct initialization and provide
their own methods for managing DMA operation. I already have a working
platform glue code for the above cases tested with Samsung multimedia
drivers. No changes to the drivers were required.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
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/