Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1584578 > unrolled thread

Re: [PATCH 3/8] mm: cma: Export a few symbols

Started byMichal Hocko <mhocko@kernel.org>
First post2017-02-20 13:40 +0100
Last post2017-02-24 00:10 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 3/8] mm: cma: Export a few symbols Michal Hocko <mhocko@kernel.org> - 2017-02-20 13:40 +0100
    Re: [PATCH 3/8] mm: cma: Export a few symbols Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-02-24 00:10 +0100

#1584578 — Re: [PATCH 3/8] mm: cma: Export a few symbols

FromMichal Hocko <mhocko@kernel.org>
Date2017-02-20 13:40 +0100
SubjectRe: [PATCH 3/8] mm: cma: Export a few symbols
Message-ID<tcVq2-4F1-29@gated-at.bofh.it>
On Mon 13-02-17 14:44:16, Maxime Ripard wrote:
> Hi Michal,
> 
> On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote:
> > [CC CMA people]
> > 
> > On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> > > Modules might want to check their CMA pool size and address for debugging
> > > and / or have additional checks.
> > > 
> > > The obvious way to do this would be through dev_get_cma_area and
> > > cma_get_base and cma_get_size, that are currently not exported, which
> > > results in a build failure.
> > > 
> > > Export them to prevent such a failure.
> > 
> > Who actually uses those exports. None of the follow up patches does
> > AFAICS.
> 
> This is for the ARM Mali GPU driver that is out of tree, unfortunately.

We do not export symbols which do not have any in-tree users.

> In one case (using the legacy fbdev API), the driver wants to (and
> probably should) validate that the buffer as indeed been allocated
> from the memory allocation pool.
> 
> Rob suggested that instead of hardcoding it to cover the whole RAM
> (which defeats the purpose of that check in the first place), we used
> the memory-region bindings in the DT and follow that, which does work
> great, but we still have to retrieve the base address and size of that
> region, hence why this patches are needed.

Anyway I would suggest talking to CMA people to find a better API for
modules to use...

-- 
Michal Hocko
SUSE Labs

[toc] | [next] | [standalone]


#1587162

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2017-02-24 00:10 +0100
Message-ID<teaGl-7ZC-13@gated-at.bofh.it>
In reply to#1584578

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 20, 2017 at 01:35:50PM +0100, Michal Hocko wrote:
> On Mon 13-02-17 14:44:16, Maxime Ripard wrote:
> > Hi Michal,
> > 
> > On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote:
> > > [CC CMA people]
> > > 
> > > On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> > > > Modules might want to check their CMA pool size and address for debugging
> > > > and / or have additional checks.
> > > > 
> > > > The obvious way to do this would be through dev_get_cma_area and
> > > > cma_get_base and cma_get_size, that are currently not exported, which
> > > > results in a build failure.
> > > > 
> > > > Export them to prevent such a failure.
> > > 
> > > Who actually uses those exports. None of the follow up patches does
> > > AFAICS.
> > 
> > This is for the ARM Mali GPU driver that is out of tree, unfortunately.
> 
> We do not export symbols which do not have any in-tree users.

Ok, sorry for the noise.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web