Re: [U-Boot] [PATCH] TRATS: Fix uart gpio config
Dear Chander Kashyap,
On 25 January 2012 14:25, Chander Kashyap chander.kash...@linaro.org wrote:
It updates the missing gpio configuration of UART port.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Cc: HeungJun, Kim riverful@samsung.com
---
board/samsung/trats/trats.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index f795ff0..4c9773d 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -337,7 +337,7 @@ static void board_uart_init(void)
int i;
/* UART0-UART1 GPIOs (part1) : 0x */
- for (i = 0; i 7; i++) {
+ for (i = 0; i 8; i++) {
s5p_gpio_set_pull(gpio1-a0, i, GPIO_PULL_NONE);
s5p_gpio_cfg_pin(gpio1-a0, i, GPIO_FUNC(0x2));
}
@@ -347,7 +347,7 @@ static void board_uart_init(void)
* GPA1CON[3] = I2C_3_SCL (3)
* GPA1CON[2] = I2C_3_SDA (3)
*/
- for (i = 0; i 5; i++) {
+ for (i = 0; i 6; i++) {
s5p_gpio_set_pull(gpio1-a1, i, GPIO_PULL_NONE);
s5p_gpio_cfg_pin(gpio1-a1, i,
GPIO_FUNC((i == 2 || i == 3) ? 0x3 : 0x2));
--
Actually we don't have to set all of UARTs.
Because, we only use UART2 for serial.
I will post new patch for it.
Thanks
Minkyu Kang.
--
from. prom.
www.promsoft.net
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announcing Linarotv-xmbc image
Thank you, Ricardo! By your experience,do you think xbmc can perform well on boards without hardware OpenGL ES acceleration? or have you ever done such experiment? 在 2012-1-26 上午11:03，Ricardo Salveti ricardo.salv...@linaro.org写道： On Wed, Jan 25, 2012 at 11:55 PM, Hui Zhang son...@gmail.com wrote: Hi Tom, Can Linarotv-XBMC work well on boards with hardware video acceleration but WITHOUT hardware OpenGL ESv2 acceleration? (BTW, the board has 2D hardware acceleration) Thanks in advance! Not right now, as our initial goal was to get it working fully accelerated at Panda. We're planning on updating it to Eden beta2 in the next few weeks, and I hope we get it at least generic enough for other use cases. Problem right now is that using or not opengles is a build-time decision, so we might need some tweaks at the packaging side (to provide both), or enabling run-time detection. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On 25 Jan 2012, at 20:53, Zygmunt Krynicki wrote: It takes a _long_ while to get to raw serial console login prompt of a stripped-down ubuntu nano image. On my core i7 (first gen) the simulator can sometimes reach around 1M instructions per second but is usually slower. On top of that I don't know if it has any kind of support for graphics. Depends what you mean, but I've run stuff with graphical output on a FastModel before, most notably the Mandelbrot generator. Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Sources for 11.11 kernel release
On Wed, Jan 25, 2012 at 04:14:10PM -0200, Christian Robottom Reis wrote: On Tue, Jan 24, 2012 at 10:50:51AM -0500, Chris Lalancette wrote: In terms of finding things in the future, I have to say that there is a bit of a forest of git trees in linaro. At the very least, I would make sure that the .dsc file in the released deb points to the correct tree+tag that it was generated from. That's not a bad idea. John, can we make that happen? 1) Attempt to reduce the number of trees on git.linaro.org. I understand that there is probably a lot going on, but the sheer number of trees makes it confusing. It might be a good idea to remove some of the very stale or no longer active trees. What do Deepak and Lo?c think of this in general? 2) Document on the wiki where the releases are built from, so there is a running record per release Where would we record this, Deepak, Alexander, Lo?c? For Ubuntu, I think the (only) correct way to track this is to represent linaro releases as actual releases in the package archive. i.e., sources.list will look like deb http://ports.ubuntu.com/ubuntu-ports precise main deb http://ppa.launchpad.net/linaro-maintainers/overlay linaro-12.02 main And http://ppa.launchpad.net/linaro-maintainers/overlay/ubuntu/dists/linaro-12.02/Release and the things it points to would then be authoritative definition of what was in that release for evermore (or at least, the GPL-requisite 3 years). Once we have this, we can document robustly how to find out, because the means to do so will be stable and not constantly changing. Do you know if this is sensible/doable, or is launchpad very tied the ubuntu release names? Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Sources for 11.11 kernel release
(dropping linaro-kernel@) On Thu, Jan 26, 2012, Dave Martin wrote: deb http://ports.ubuntu.com/ubuntu-ports precise main deb http://ppa.launchpad.net/linaro-maintainers/overlay linaro-12.02 main And http://ppa.launchpad.net/linaro-maintainers/overlay/ubuntu/dists/linaro-12.02/Release and the things it points to would then be authoritative definition of what was in that release for evermore (or at least, the GPL-requisite 3 years). [...] Do you know if this is sensible/doable, or is launchpad very tied the ubuntu release names? It's not possible with the current web UI of PPAs, but the Launchpad code is flexible in this area and it would likely be possible to do things like that, albeit it would be a bit weird to combine distros together (precise from Ubuntu with linaro-12.02 from Linaro). Launchpad gained over the last year improved support for derivatives but that means forking Ubuntu for Linaro and then constantly merging from it, having our own archive etc.; the only entry would be: deb http://archive.linaro.org linaro-12.02 main This is something we envisioned doing in the early stages of Linaro, but Launchpad wasn't ready and it was costly to maintain, now it would be costly to switch; perhaps the incentive is strong enough though. Another way to solve this could be to defer to some automated service for publishing our bits rather than uploading them ourselves; for instance we would point a robot at the git repo where the TI LT kernel for release is kept, and it would be assembling a source package from it and publishing that to some Vcs and to the release PPA. That way we would ensure we always now where we took the source from, how it was built etc. and can enforce any rule we like. This would be comparable to the automated merges of some bzr branches in Launchpad where a robot tries running the testsuite and then merges the branch in tip if that passes, but humans never push to tip. Availibility of the original (git or not) source is a long standing problem which is partly due to the PPA rules (which are dropping some sources after being superseded for a while) and partly to relying on humans to document things like Vcs-Git properly. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Finding source code for Linaro kernels
On Wed, Jan 25, 2012 at 6:52 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: On 25 January 2012 12:18, Dave Martin dave.mar...@linaro.org wrote: On Tue, Jan 24, 2012 at 9:40 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: [...] For Android we have: https://android-build.linaro.org/builds/~linaro-android/panda-12.01-release/ we should have the same thing for Ubuntu: ubuntu-build.linaro.org with the similar information. I'm not sure about that: for Debian/Ubuntu there are established methods for getting source and provenance info. It's a solved problem, so we should just use the mature solution instead of insisting on inventing our own. A key issue is that there is a fundamental difference between the way building and versioning works between the Debian and Android worlds. In Android, if I understand correctly, the whole build is effectively done from a single tree, so you can meaningfully tag a whole release and bungle source for it without tagging individual components. Am I correct here? In the Debian way of doing things, builds are incremental and continuous there is no single tree containing all the source for a release. Bootstrapping a whole release from pure source is a rare event, and involves a significant manual effort. Rather, a release is a particular set of versions of particular packages, not built as part of the release process, but instead the set of newest pre-built versions of the chosen packages at the time the release was defined. Also, once you have the platform running you can upgrade it piecemeal, package by package. So establishing metadata at the release level only is hard and makes little sense: the metadata must be tracked at the package level in any case. All this means that the way we track a source project (such as the Linux kernel) which is common between both worlds must accommodate both worlds. If it fails to accommodate either, we will encounter trouble in one world or the other. For the kernels, we do almost get things right for Ubuntu-land, but just not right _enough_ that finding the source works reliably in the same way as for every other package. A UI is a good thing if it is built on firm foundations, but I fear that if we don't get the fundamentals correct, no amount of UI polishing is going to hide the instability that lurks beneath. That's all well and good, but the point is you need to answer the following question: What kernel was used. Where can I get it. How can I rebuild it. You may as well put that on a 'page' so that people who are not Debian people can easily find what they're looking for. The point of the android-build pages is that it answers specific questions: How do I use this? How do I rebuild this? Where does this come from? What works? Where can I get help? Take a look at: https://android-build.linaro.org/builds/~linaro-android/landing-panda-12.01-release/ Everything's in one place. Its not the way Android does this, but that doesn't matter, it giving our customers exactly what they want. That's why an ubuntu-build.linaro.org is so important. Right now its hard to find Ubuntu stuff which is bad. As a Linaro user I should be able to find everything I need on one page without digging through out of date wikis or knowing someone. I do agree -- it's just that when building such a thing for ubuntu, we need to build it on a firm foundation. The foundation is called the apt archive, and it's already there. We don't quite use it right in some cases, though it sounds like jcrigby has already made good progress for the kernel CI builds. We also don't document it enough. Once we can track and generate those reports automatically, then we can freely choose how to present them. There's no reason not to have a nice web page for it, so long as the underlying infrastructure is coherent. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
Adding Amit. Looks like getting a big cloud instance running may help. Is the simulator I/O or compute bound? On 26 January 2012 03:22, Dave Pigott dave.pig...@linaro.org wrote: On 25 Jan 2012, at 20:53, Zygmunt Krynicki wrote: It takes a _long_ while to get to raw serial console login prompt of a stripped-down ubuntu nano image. On my core i7 (first gen) the simulator can sometimes reach around 1M instructions per second but is usually slower. On top of that I don't know if it has any kind of support for graphics. Depends what you mean, but I've run stuff with graphical output on a FastModel before, most notably the Mandelbrot generator. Dave -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On 26 January 2012 16:26, Zach Pfeffer zach.pfef...@linaro.org wrote: Looks like getting a big cloud instance running may help. Is the simulator I/O or compute bound? It is typically compute bound (unless you're short on RAM: 6GB the figure I've been bandying around as a plausible minimum). With rate limiting enabled it will artificially limit its speed, in which case it may use less than 100% CPU. Running in the cloud probably introduces difficulties with the flexlm licensing. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On Wed, Jan 25, 2012 at 09:53:21PM +0100, Zygmunt Krynicki wrote: Hi Zach It takes a _long_ while to get to raw serial console login prompt of a stripped-down ubuntu nano image. On my core i7 (first gen) the simulator can sometimes reach around 1M instructions per second but is usually slower. On top of that I don't know if it has any kind of support for graphics. We've noticed that for some reason running MAKEDEV takes seriously ages, so if you don't have CONFIG_DEVTMPFS enabled in your kernel, make sure you turn it on in the kernel config. This causes the bootscripts to bypass MAKEDEV. You may also find that the model uses a lot less RAM if you turn adress space layout randomisation off -- something to do with the way memory mappings are cached: echo 0 /proc/sys/kernel/randomize_va_space This is especially helpful on machines where the memory usage would otherwise run into swap. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On Thu, Jan 26, 2012 at 5:26 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: Adding Amit. Looks like getting a big cloud instance running may help. Is the simulator I/O or compute bound? Compute bound. It also requires a license from arm for each machine that runs it (it binds to mac address) and a lot of memory (6GB is a good start). On 26 January 2012 03:22, Dave Pigott dave.pig...@linaro.org wrote: On 25 Jan 2012, at 20:53, Zygmunt Krynicki wrote: It takes a _long_ while to get to raw serial console login prompt of a stripped-down ubuntu nano image. On my core i7 (first gen) the simulator can sometimes reach around 1M instructions per second but is usually slower. On top of that I don't know if it has any kind of support for graphics. Depends what you mean, but I've run stuff with graphical output on a FastModel before, most notably the Mandelbrot generator. Dave -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On Wed, Jan 25, 2012 at 09:33:35PM +0100, Zygmunt Krynicki wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider The basic A15 CPU support is upstream, but no board support. The board support emulation on the model is for obscure reasons not exactly the same as a real VExpress, but it's pretty close. With Pawel Moll's VExpress device tree support patches on top of mainline, we can produce a single kernel config and a set of device trees which allow booting on all the A15-based model variants. I'll be pushing a tree onto git.linaro.org soon with that stuff. The ARM landing team guys should be able to advice on the amount of effort required to merge android with such a kernel. I don't currently know anything in that area. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On Thu, Jan 26, 2012 at 7:24 PM, Dave Martin dave.mar...@linaro.org wrote: On Wed, Jan 25, 2012 at 09:33:35PM +0100, Zygmunt Krynicki wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider The basic A15 CPU support is upstream, but no board support. The board support emulation on the model is for obscure reasons not exactly the same as a real VExpress, but it's pretty close. With Pawel Moll's VExpress device tree support patches on top of mainline, we can produce a single kernel config and a set of device trees which allow booting on all the A15-based model variants. I'll be pushing a tree onto git.linaro.org soon with that stuff. Would you mind telling me which git tree to watch and which config to build? I'll be building it locally for testing before we get the CI loop into place. Thanks ZK The ARM landing team guys should be able to advice on the amount of effort required to merge android with such a kernel. I don't currently know anything in that area. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On 12-01-26 01:24 PM, Dave Martin wrote: On Wed, Jan 25, 2012 at 09:33:35PM +0100, Zygmunt Krynicki wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider The basic A15 CPU support is upstream, but no board support. The board support emulation on the model is for obscure reasons not exactly the same as a real VExpress, but it's pretty close. With Pawel Moll's VExpress device tree support patches on top of mainline, we can produce a single kernel config and a set of device trees which allow booting on all the A15-based model variants. I'll be pushing a tree onto git.linaro.org soon with that stuff. Why don't you push the changes to the ARM LT and let them manage pushing the tree out. Then we can maintain it and take the burden off of you. I suspect you will be rather busy. Scott -- Scott Bambrough Technical Director, Member Services Linaro Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro kernel tree for A15 for daily builds
On 26 January 2012 13:52, Ryan Harkin ryan.har...@linaro.org wrote: On 26 January 2012 19:34, Scott Bambrough scott.bambro...@linaro.org wrote: On 12-01-26 01:24 PM, Dave Martin wrote: On Wed, Jan 25, 2012 at 09:33:35PM +0100, Zygmunt Krynicki wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider The basic A15 CPU support is upstream, but no board support. The board support emulation on the model is for obscure reasons not exactly the same as a real VExpress, but it's pretty close. With Pawel Moll's VExpress device tree support patches on top of mainline, we can produce a single kernel config and a set of device trees which allow booting on all the A15-based model variants. I'll be pushing a tree onto git.linaro.org soon with that stuff. Why don't you push the changes to the ARM LT and let them manage pushing the tree out. Then we can maintain it and take the burden off of you. I suspect you will be rather busy. Indeed, my tree is already hosting your (dmart's) AMBA Device Discovery fixes and Pawel's Device Tree additions, so placing your A15 model stuff on top is not a problem for me. Here's our current working tree: http://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=summary This is already booting real A15 Versatile Express hardware, so we're part the way there already. Amit, once you get your test written would you send it to the ARM LT with installation and build instructions? We don't have to wait for the proc node, once that's done we can just recompile and be done. R. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Linaro kernel tree for A15 for daily builds
On Thu, Jan 26, 2012 at 8:52 PM, Ryan Harkin ryan.har...@linaro.org wrote: On 26 January 2012 19:34, Scott Bambrough scott.bambro...@linaro.org wrote: On 12-01-26 01:24 PM, Dave Martin wrote: On Wed, Jan 25, 2012 at 09:33:35PM +0100, Zygmunt Krynicki wrote: HI. I'm building a LAVA service for running fast models. Quite soon (*) we'll be ready to open an alpha access. Right now you will need to bring your own root filesystem and kernel image to use it. With that in mind I wanted to start a discussion about the state of A15 support in Linaro kernel(s). I need to understand two things: 1) Are we ready to do automatic builds for A15 kernels? 2) If so, which configs and trees should we consider The basic A15 CPU support is upstream, but no board support. The board support emulation on the model is for obscure reasons not exactly the same as a real VExpress, but it's pretty close. With Pawel Moll's VExpress device tree support patches on top of mainline, we can produce a single kernel config and a set of device trees which allow booting on all the A15-based model variants. About device trees, does the simulator need an explicitly provided device tree (in a way we currently provide the kernel image and ramdisk) or is the dt table built into the image? I'll be pushing a tree onto git.linaro.org soon with that stuff. Why don't you push the changes to the ARM LT and let them manage pushing the tree out. Then we can maintain it and take the burden off of you. I suspect you will be rather busy. Indeed, my tree is already hosting your (dmart's) AMBA Device Discovery fixes and Pawel's Device Tree additions, so placing your A15 model stuff on top is not a problem for me. Here's our current working tree: http://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=summary This is already booting real A15 Versatile Express hardware, so we're part the way there already. R. ___ linaro-validation mailing list linaro-validat...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Audio development ideas for 12.02 and beyond
Hi all, Here is a brain dump for some things I see on the horizon for audio work. Is this complete? Absolutely not. This is meant to be a place to capture and refine ideas before creating cards and/or blueprints for them. In other words, this should compliment the existing work and backlog already in LP. https://wiki.linaro.org/KurtTaylor/AudioBacklog Please edit or send any comments to me. Thanks! -- Kurt Taylor (irc krtaylor) Linaro Multimedia Linaro.org http://www.linaro.org/* **│ *Open source software for ARM SoCs Follow *Linaro: *Facebook http://www.facebook.com/pages/Linaro | Twitterhttp://twitter.com/#%21/linaroorg| Blog http://www.linaro.org/linaro-blog/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Linaro kernel tree for A15 for daily builds
On 26 January 2012 20:19, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: About device trees, does the simulator need an explicitly provided device tree (in a way we currently provide the kernel image and ramdisk) or is the dt table built into the image? The simulator doesn't care whether you're using device tree or not, it is merely emulating a CPU. The boot-wrapper code currently does not support passing a device tree blob in, so you'll need to use the kernel config option to support appending the device tree to the uImage, or alternatively not use a device tree at all. The bootwrapper could probably be enhanced to be device-tree aware; I was talking to Dave about this the other day. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] module: avoid call vmalloc if init size is zero
For the architectures with it's own module_alloc(), if module init
size is zero, avoiding module_alloc_update_bounds() and memset()
no-op calls also eliminates warn_alloc_failed() zero-size warning
in __vmalloc_node_range().
Signed-off-by: Dmitry Antipov dmitry.anti...@linaro.org
---
kernel/module.c | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 2c93276..bbe1c5b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2644,20 +2644,23 @@ static int move_module(struct module *mod, struct
load_info *info)
memset(ptr, 0, mod-core_size);
mod-module_core = ptr;
- ptr = module_alloc_update_bounds(mod-init_size);
- /*
-* The pointer to this block is stored in the module structure
-* which is inside the block. This block doesn't need to be
-* scanned as it contains data and code that will be freed
-* after the module is initialized.
-*/
- kmemleak_ignore(ptr);
- if (!ptr mod-init_size) {
- module_free(mod, mod-module_core);
- return -ENOMEM;
- }
- memset(ptr, 0, mod-init_size);
- mod-module_init = ptr;
+ if (mod-init_size) {
+ ptr = module_alloc_update_bounds(mod-init_size);
+ /*
+* The pointer to this block is stored in the module structure
+* which is inside the block. This block doesn't need to be
+* scanned as it contains data and code that will be freed
+* after the module is initialized.
+*/
+ kmemleak_ignore(ptr);
+ if (!ptr) {
+ module_free(mod, mod-module_core);
+ return -ENOMEM;
+ }
+ memset(ptr, 0, mod-init_size);
+ mod-module_init = ptr;
+ } else
+ mod-module_init = NULL;
/* Transfer each section which specifies SHF_ALLOC */
pr_debug(final section addresses:\n);
--
1.7.7.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
