Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1584578 > unrolled thread
| Started by | Michal Hocko <mhocko@kernel.org> |
|---|---|
| First post | 2017-02-20 13:40 +0100 |
| Last post | 2017-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.
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
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2017-02-20 13:40 +0100 |
| Subject | Re: [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]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-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