* [PATCHv2 00/19] ARM: common warning fixes
From: Arnd Bergmann @ 2013-01-26 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126100542.GC23505@n2100.arm.linux.org.uk>
On Saturday 26 January 2013, Russell King - ARM Linux wrote:
> On Fri, Jan 25, 2013 at 10:43:59PM +0000, Arnd Bergmann wrote:
> > I will get to those once this series is sorted out.
> > Since there are no interdepencies between the patches,
> > my preference is to have them applied by the individual
> > subsystem maintainers. Anything that has not at
> > least made it into linux-next by the next merge window
> > and has not received a 'NAK' or been obsoleted by
> > another patch, I plan to submit as part of an arm-soc
> > branch for 3.9.
>
> And, last night we have new warnings. My allnoconfigs no longer build
> cleanly because of new vexpress section mismatches in the mfd code.
Yes, I already sent a patch yesterday. The problem was a regression
that came in through the arm-soc tree unfortunately, but I can easily
fix it then.
> It seems to me that you're on a loosing battle unless you test the tree
> and drop code before propaging it out if it adds new warnings... force
> the pain of these warnings down on to others so that they learn to create
> better code in the first place.
That was always the idea, right now I mainly try to get back to the almost
clean state I had some time ago.
The largest problem right now is gcc-4.7, which adds a lot of new bogus
warnings.
Arnd
^ permalink raw reply
* [PATCH] regulators/db8500: Fix compile failure for drivers/regulator/dbx500-prcmu.c
From: Steven Rostedt @ 2013-01-26 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126073121.GO10580@opensource.wolfsonmicro.com>
On Sat, 2013-01-26 at 15:31 +0800, Mark Brown wrote:
> Applied, thanks. Please use subject lines appropriate for the subsystem
> (I see I let the original one through).
Heh, when making patches for other subsystems, I look at the subject of
the patch that broke to determine what to use.
-- Steve
^ permalink raw reply
* [PATCH V3 8/8] ARM: kirkwood: mv643xx_eth dt conversion
From: Sebastian Hesselbarth @ 2013-01-26 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126123827.GA5786@lunn.ch>
On 01/26/2013 01:38 PM, Andrew Lunn wrote:
>> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
>> index 73b76e4..7ab92e5 100644
>> --- a/arch/arm/mach-kirkwood/board-dt.c
>> +++ b/arch/arm/mach-kirkwood/board-dt.c
>> @@ -48,7 +48,7 @@ static void __init kirkwood_legacy_clk_init(void)
>> clkspec.args_count = 1;
>>
>> clkspec.args[0] = CGC_BIT_GE0;
>> - orion_clkdev_add(NULL, "mv643xx_eth_port.0",
>> + orion_clkdev_add(NULL, "f1072000.egiga0",
>> of_clk_get_from_provider(&clkspec));
>>
>> clkspec.args[0] = CGC_BIT_PEX0;
>> @@ -60,7 +60,7 @@ static void __init kirkwood_legacy_clk_init(void)
>> of_clk_get_from_provider(&clkspec));
>>
>> clkspec.args[0] = CGC_BIT_GE1;
>> - orion_clkdev_add(NULL, "mv643xx_eth_port.1",
>> + orion_clkdev_add(NULL, "f1076000.egiga1",
>> of_clk_get_from_provider(&clkspec));
>> }
>>
> These changes break any platform not yet converted, eg my QNAP box now
> locks up solid.
>
> Something is not right here, or i'm not understanding something. DT
> devices should not need code like this, only devices not yet using
> DT....
Jason, Andrew,
have a look at dove_legacy_clk_init() in arch/arm/mach-dove/common.c.
This is how I handled non-DT clock aliases from DT provided clocks.
Maybe you can also use it for kirkwood.
Sebastian
^ permalink raw reply
* [PATCH V3 8/8] ARM: kirkwood: mv643xx_eth dt conversion
From: Andrew Lunn @ 2013-01-26 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4805edf01c39a374d71fbf4a6b6207dedf6b2bf.1359146831.git.jason@lakedaemon.net>
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
> index 73b76e4..7ab92e5 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -48,7 +48,7 @@ static void __init kirkwood_legacy_clk_init(void)
> clkspec.args_count = 1;
>
> clkspec.args[0] = CGC_BIT_GE0;
> - orion_clkdev_add(NULL, "mv643xx_eth_port.0",
> + orion_clkdev_add(NULL, "f1072000.egiga0",
> of_clk_get_from_provider(&clkspec));
>
> clkspec.args[0] = CGC_BIT_PEX0;
> @@ -60,7 +60,7 @@ static void __init kirkwood_legacy_clk_init(void)
> of_clk_get_from_provider(&clkspec));
>
> clkspec.args[0] = CGC_BIT_GE1;
> - orion_clkdev_add(NULL, "mv643xx_eth_port.1",
> + orion_clkdev_add(NULL, "f1076000.egiga1",
> of_clk_get_from_provider(&clkspec));
> }
>
Hi Jason
These changes break any platform not yet converted, eg my QNAP box now
locks up solid.
Something is not right here, or i'm not understanding something. DT
devices should not need code like this, only devices not yet using
DT....
Andrew
^ permalink raw reply
* [PATCH 11/19] regmap: regmap: avoid spurious warning in regmap_read_debugfs
From: Arnd Bergmann @ 2013-01-26 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126100744.GD23505@n2100.arm.linux.org.uk>
From: Russell King <rmk+kernel@arm.linux.org.uk>
Gcc warns about the case where regmap_read_debugfs tries to walk an
empty map->debugfs_off_cache list, which would results in uninitialized
variable getting returned, if we hadn't checked the same condition
just before that.
After an originally suggested inferior patch from Arnd Bergmann,
this is the solution that Russell King came up with, sidestepping
the problem by merging the error case for an empty list with the
normal path.
Without this patch, building mxs_defconfig results in:
drivers/base/regmap/regmap-debugfs.c: In function 'regmap_read_debugfs':
drivers/base/regmap/regmap-debugfs.c:147:9: : warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
Reported-by: Vincent Stehle <v-stehle@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/base/regmap/regmap-debugfs.c b/drivers/base/regmap/regmap-debugfs.c
index 41b65f6..ef35c25 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -128,10 +128,8 @@ static unsigned int regmap_debugfs_get_dump_start(struct regmap *map,
* allocate and we should never be in this code if there are
* no registers at all.
*/
- if (list_empty(&map->debugfs_off_cache)) {
- WARN_ON(list_empty(&map->debugfs_off_cache));
- return base;
- }
+ WARN_ON(list_empty(&map->debugfs_off_cache));
+ ret = base;
/* Find the relevant block */
list_for_each_entry(c, &map->debugfs_off_cache, list) {
^ permalink raw reply related
* [PATCH 15/19] sunrpc: don't warn for unused variable 'buf'
From: Russell King - ARM Linux @ 2013-01-26 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301252345.25829.arnd@arndb.de>
On Fri, Jan 25, 2013 at 11:45:25PM +0000, Arnd Bergmann wrote:
> On Friday 25 January 2013, Myklebust, Trond wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Marking it as __maybe_unused avoids a harmless gcc warning.
> >
> > Alternatively, just declare it using the RPC_IFDEBUG() macro.
>
> Right, makes sense: that's more consistent with other functions
> doing the same thing. Thanks for taking a look.
NAK.
There is already a fix queued up as a result of a previous report I
sent, but for some reason (which I didn't question) it was decided
not to queue it for -rc.
See Bruce's reply on lkml: 20130108212816.GA24572 at fieldses.org
^ permalink raw reply
* Timer Implementation
From: sanju james @ 2013-01-26 10:17 UTC (permalink / raw)
To: linux-arm-kernel
Hallo ,
Am master student in univeristy of paderborn in Germany. Am doing a
research for my thesis on the KVM-Linux implementation for ARM cortex a8. I
would like to know one important information regarding how
timer interrupts are forwarded to the guest from the host Linux or how
timer interrupts are handled in the software stack of linux kernel, kvm and
qemu. It would be great help if you give some idea regarding this.
Regards,
Sanjul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/0d27a39a/attachment.html>
^ permalink raw reply
* [PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs
From: Russell King - ARM Linux @ 2013-01-26 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126100326.GK30594@opensource.wolfsonmicro.com>
On Sat, Jan 26, 2013 at 06:03:28PM +0800, Mark Brown wrote:
> On Sat, Jan 26, 2013 at 09:59:16AM +0000, Russell King - ARM Linux wrote:
>
> > Why not code the function in a way that avoids the problem altogether?
>
> That'd do the trick too; feel free to submit a patch...
Sorry, got other things which need doing, so if you want that expect it
sometime next month if I even remember.
^ permalink raw reply
* [PATCHv2 00/19] ARM: common warning fixes
From: Russell King - ARM Linux @ 2013-01-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359153858-31992-1-git-send-email-arnd@arndb.de>
On Fri, Jan 25, 2013 at 10:43:59PM +0000, Arnd Bergmann wrote:
> I will get to those once this series is sorted out.
> Since there are no interdepencies between the patches,
> my preference is to have them applied by the individual
> subsystem maintainers. Anything that has not at
> least made it into linux-next by the next merge window
> and has not received a 'NAK' or been obsoleted by
> another patch, I plan to submit as part of an arm-soc
> branch for 3.9.
And, last night we have new warnings. My allnoconfigs no longer build
cleanly because of new vexpress section mismatches in the mfd code.
It seems to me that you're on a loosing battle unless you test the tree
and drop code _before_ propaging it out if it adds new warnings... force
the pain of these warnings down on to others so that they learn to create
better code in the first place.
^ permalink raw reply
* [PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs
From: Mark Brown @ 2013-01-26 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126095916.GB23505@n2100.arm.linux.org.uk>
On Sat, Jan 26, 2013 at 09:59:16AM +0000, Russell King - ARM Linux wrote:
> Why not code the function in a way that avoids the problem altogether?
That'd do the trick too; feel free to submit a patch...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/d93dd193/attachment.sig>
^ permalink raw reply
* [PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs
From: Russell King - ARM Linux @ 2013-01-26 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126094855.GI30594@opensource.wolfsonmicro.com>
On Sat, Jan 26, 2013 at 05:49:29PM +0800, Mark Brown wrote:
> Oh, ffs. This is a false positive from the compiler - there is no case
> where it can actually do this as we will bail out before the walk if the
> list is empty so we'll always take at least one trip through our
> list_for_each_entry() and either return or set ret. It should be smart
> enough to work out that the list_empty() means list_for_each_entry()
> will iterate over at least one entry or more conservative in what it
> warns about.
Why not code the function in a way that avoids the problem altogether?
/*
* This should never happen; we return above if we fail to
* allocate and we should never be in this code if there are
* no registers at all.
*/
- if (list_empty(&map->debugfs_off_cache)) {
- WARN_ON(list_empty(&map->debugfs_off_cache));
- return base;
- }
+ WARN_ON(list_empty(&map->debugfs_off_cache));
+ ret = base;
/* Find the relevant block */
list_for_each_entry(c, &map->debugfs_off_cache, list) {
if (from >= c->min && from <= c->max) {
*pos = c->min;
return c->base_reg;
}
*pos = c->min;
ret = c->base_reg;
}
return ret;
^ permalink raw reply
* [PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs
From: Mark Brown @ 2013-01-26 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301260917.28028.arnd@arndb.de>
On Sat, Jan 26, 2013 at 09:17:27AM +0000, Arnd Bergmann wrote:
> On Saturday 26 January 2013, Mark Brown wrote:
> > On Fri, Jan 25, 2013 at 02:14:28PM +0000, Arnd Bergmann wrote:
> > > Gcc warns about the case where regmap_read_debugfs tries
> > Are you sure about that function name?
> Yes, regmap_read_debugfs uses the return value from
> regmap_debugfs_get_dump_start, for which gcc found
> a path that returns the uninitialized value.
> > > to walk an empty map->debugfs_off_cache list, which results
> > > in uninitialized variable getting returned.
This is the bit that makes me think you're talking about the wrong
function - regmap_debugfs_read() never looks at the off_cache list.
> > > Setting this variable to 0 first avoids the warning and
> > > the potentially undefined value.
> > This probably won't apply against current code as there's already a
> > better fix there, in general just picking a value to initialise masks
> > errors.
> I agree on the general rule not to do this, and I'm trying to avoid it
> in the cases where I can find a better fix, but here I could not
> (mostly because I could not figure out what this code actually
> does. Thanks for taking a look.
> Which code is the current version? Is your fix headed for 3.8 inclusion?
It's all in mainline already.
> I still see the warning in 3.8-rc5 as well as yesterday's linux-next,
> with gcc-4.6, 4.7 and 4.8-pre.
Oh, ffs. This is a false positive from the compiler - there is no case
where it can actually do this as we will bail out before the walk if the
list is empty so we'll always take at least one trip through our
list_for_each_entry() and either return or set ret. It should be smart
enough to work out that the list_empty() means list_for_each_entry()
will iterate over at least one entry or more conservative in what it
warns about.
In any case, your change will break things - this is an example of why
just picking a random value to assign is unhelpful. You'd need to
return base to avoid confusing the callers but even then doing it at the
start of the function is overkill, it excludes a bunch of paths. I
guess we can work around it by putting a redundant assignment of pos and
ret before the loop :/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/252c1e41/attachment.sig>
^ permalink raw reply
* [PATCHv3] ARM: sunxi: gpio: Add Allwinner SoCs GPIO drivers
From: Maxime Ripard @ 2013-01-26 9:31 UTC (permalink / raw)
To: linux-arm-kernel
The IP responsible for the muxing on the Allwinner SoCs are also
handling the GPIOs on the system. This patch adds the needed driver that
relies on the pinctrl driver for most of its operations.
The number of pins available for GPIOs operations are already declared
in the pinctrl driver, we only need to probe a generic driver to handle
the banks available for each SoC.
This driver has been tested on a A13-Olinuxino.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
Changes from v2:
- Removed the call to kzalloc to build the pin name
drivers/pinctrl/pinctrl-sunxi.c | 134 ++++++++++++++++++++++++++++++++++++++-
drivers/pinctrl/pinctrl-sunxi.h | 25 +++++++-
2 files changed, 156 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index 6f02e34..4ed0e7e 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -11,6 +11,7 @@
*/
#include <linux/io.h>
+#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_address.h>
@@ -609,11 +610,53 @@ static int sunxi_pmx_enable(struct pinctrl_dev *pctldev,
return 0;
}
+static int
+sunxi_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
+ struct pinctrl_gpio_range *range,
+ unsigned offset,
+ bool input)
+{
+ struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+ struct sunxi_desc_function *desc;
+ char pin_name[SUNXI_PIN_NAME_MAX_LEN];
+ char *func;
+ u8 bank, pin;
+ int ret;
+
+ bank = (offset) / PINS_PER_BANK;
+ pin = (offset) % PINS_PER_BANK;
+
+ ret = sprintf(pin_name, "P%c%d", 'A' + bank, pin);
+ if (!ret)
+ goto error;
+
+ if (input)
+ func = "gpio_in";
+ else
+ func = "gpio_out";
+
+ desc = sunxi_pinctrl_desc_find_function_by_name(pctl,
+ pin_name,
+ func);
+ if (!desc) {
+ ret = -EINVAL;
+ goto error;
+ }
+
+ sunxi_pmx_set(pctldev, offset, desc->muxval);
+
+ ret = 0;
+
+error:
+ return ret;
+}
+
static struct pinmux_ops sunxi_pmx_ops = {
.get_functions_count = sunxi_pmx_get_funcs_cnt,
.get_function_name = sunxi_pmx_get_func_name,
.get_function_groups = sunxi_pmx_get_func_groups,
.enable = sunxi_pmx_enable,
+ .gpio_set_direction = sunxi_pmx_gpio_set_direction,
};
static struct pinctrl_desc sunxi_pctrl_desc = {
@@ -622,6 +665,60 @@ static struct pinctrl_desc sunxi_pctrl_desc = {
.pmxops = &sunxi_pmx_ops,
};
+static int sunxi_pinctrl_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+ return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void sunxi_pinctrl_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+ pinctrl_free_gpio(chip->base + offset);
+}
+
+static int sunxi_pinctrl_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset)
+{
+ return pinctrl_gpio_direction_input(chip->base + offset);
+}
+
+static int sunxi_pinctrl_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+ struct sunxi_pinctrl *pctl = dev_get_drvdata(chip->dev);
+
+ u32 reg = sunxi_data_reg(offset);
+ u8 index = sunxi_data_offset(offset);
+ u32 val = (readl(pctl->membase + reg) >> index) & DATA_PINS_MASK;
+
+ return val;
+}
+
+static int sunxi_pinctrl_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ return pinctrl_gpio_direction_output(chip->base + offset);
+}
+
+static void sunxi_pinctrl_gpio_set(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ struct sunxi_pinctrl *pctl = dev_get_drvdata(chip->dev);
+ u32 reg = sunxi_data_reg(offset);
+ u8 index = sunxi_data_offset(offset);
+
+ writel((value & DATA_PINS_MASK) << index, pctl->membase + reg);
+}
+
+static struct gpio_chip sunxi_pinctrl_gpio_chip __devinitconst = {
+ .owner = THIS_MODULE,
+ .request = sunxi_pinctrl_gpio_request,
+ .free = sunxi_pinctrl_gpio_free,
+ .direction_input = sunxi_pinctrl_gpio_direction_input,
+ .direction_output = sunxi_pinctrl_gpio_direction_output,
+ .get = sunxi_pinctrl_gpio_get,
+ .set = sunxi_pinctrl_gpio_set,
+ .can_sleep = 0,
+};
+
static struct of_device_id sunxi_pinctrl_match[] = {
{ .compatible = "allwinner,sun5i-a13-pinctrl", .data = (void *)&sun5i_a13_pinctrl_data },
{}
@@ -737,7 +834,7 @@ static int sunxi_pinctrl_probe(struct platform_device *pdev)
const struct of_device_id *device;
struct pinctrl_pin_desc *pins;
struct sunxi_pinctrl *pctl;
- int i, ret;
+ int i, ret, last_pin;
pctl = devm_kzalloc(&pdev->dev, sizeof(*pctl), GFP_KERNEL);
if (!pctl)
@@ -781,9 +878,42 @@ static int sunxi_pinctrl_probe(struct platform_device *pdev)
return -EINVAL;
}
- dev_info(&pdev->dev, "initialized sunXi pin control driver\n");
+ pctl->chip = devm_kzalloc(&pdev->dev, sizeof(*pctl->chip), GFP_KERNEL);
+ if (!pctl->chip) {
+ ret = -ENOMEM;
+ goto pinctrl_error;
+ }
+
+ last_pin = pctl->desc->pins[pctl->desc->npins - 1].pin.number;
+ pctl->chip = &sunxi_pinctrl_gpio_chip;
+ pctl->chip->ngpio = round_up(last_pin, PINS_PER_BANK);
+ pctl->chip->label = dev_name(&pdev->dev);
+ pctl->chip->dev = &pdev->dev;
+ pctl->chip->base = 0;
+
+ ret = gpiochip_add(pctl->chip);
+ if (ret)
+ goto pinctrl_error;
+
+ for (i = 0; i < pctl->desc->npins; i++) {
+ const struct sunxi_desc_pin *pin = pctl->desc->pins + i;
+
+ ret = gpiochip_add_pin_range(pctl->chip, dev_name(&pdev->dev),
+ pin->pin.number,
+ pin->pin.number, 1);
+ if (ret)
+ goto gpiochip_error;
+ }
+
+ dev_info(&pdev->dev, "initialized sunXi PIO driver\n");
return 0;
+
+gpiochip_error:
+ ret = gpiochip_remove(pctl->chip);
+pinctrl_error:
+ pinctrl_unregister(pctl->pctl_dev);
+ return ret;
}
static struct platform_driver sunxi_pinctrl_driver = {
diff --git a/drivers/pinctrl/pinctrl-sunxi.h b/drivers/pinctrl/pinctrl-sunxi.h
index 0dc3b9d..1ee35c0 100644
--- a/drivers/pinctrl/pinctrl-sunxi.h
+++ b/drivers/pinctrl/pinctrl-sunxi.h
@@ -254,8 +254,11 @@
#define SUNXI_PINCTRL_PIN_PG30 PINCTRL_PIN(PG_BASE + 30, "PG30")
#define SUNXI_PINCTRL_PIN_PG31 PINCTRL_PIN(PG_BASE + 31, "PG31")
+#define SUNXI_PIN_NAME_MAX_LEN 5
+
#define BANK_MEM_SIZE 0x24
#define MUX_REGS_OFFSET 0x0
+#define DATA_REGS_OFFSET 0x10
#define DLEVEL_REGS_OFFSET 0x14
#define PULL_REGS_OFFSET 0x1c
@@ -263,6 +266,9 @@
#define MUX_PINS_PER_REG 8
#define MUX_PINS_BITS 4
#define MUX_PINS_MASK 0x0f
+#define DATA_PINS_PER_REG 32
+#define DATA_PINS_BITS 1
+#define DATA_PINS_MASK 0x01
#define DLEVEL_PINS_PER_REG 16
#define DLEVEL_PINS_BITS 2
#define DLEVEL_PINS_MASK 0x03
@@ -283,6 +289,8 @@ struct sunxi_desc_pin {
struct sunxi_pinctrl_desc {
const struct sunxi_desc_pin *pins;
int npins;
+ struct pinctrl_gpio_range *ranges;
+ int nranges;
};
struct sunxi_pinctrl_function {
@@ -299,6 +307,7 @@ struct sunxi_pinctrl_group {
struct sunxi_pinctrl {
void __iomem *membase;
+ struct gpio_chip *chip;
struct sunxi_pinctrl_desc *desc;
struct device *dev;
struct sunxi_pinctrl_function *functions;
@@ -321,7 +330,6 @@ struct sunxi_pinctrl {
.muxval = _val, \
}
-
/*
* The sunXi PIO registers are organized as is:
* 0x00 - 0x0c Muxing values.
@@ -354,6 +362,21 @@ static inline u32 sunxi_mux_offset(u16 pin)
return pin_num * MUX_PINS_BITS;
}
+static inline u32 sunxi_data_reg(u16 pin)
+{
+ u8 bank = pin / PINS_PER_BANK;
+ u32 offset = bank * BANK_MEM_SIZE;
+ offset += DATA_REGS_OFFSET;
+ offset += pin % PINS_PER_BANK / DATA_PINS_PER_REG * 0x04;
+ return round_down(offset, 4);
+}
+
+static inline u32 sunxi_data_offset(u16 pin)
+{
+ u32 pin_num = pin % DATA_PINS_PER_REG;
+ return pin_num * DATA_PINS_BITS;
+}
+
static inline u32 sunxi_dlevel_reg(u16 pin)
{
u8 bank = pin / PINS_PER_BANK;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs
From: Arnd Bergmann @ 2013-01-26 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126044219.GA10580@opensource.wolfsonmicro.com>
On Saturday 26 January 2013, Mark Brown wrote:
> On Fri, Jan 25, 2013 at 02:14:28PM +0000, Arnd Bergmann wrote:
> > Gcc warns about the case where regmap_read_debugfs tries
>
> Are you sure about that function name?
Yes, regmap_read_debugfs uses the return value from
regmap_debugfs_get_dump_start, for which gcc found
a path that returns the uninitialized value.
> > to walk an empty map->debugfs_off_cache list, which results
> > in uninitialized variable getting returned.
>
> > Setting this variable to 0 first avoids the warning and
> > the potentially undefined value.
>
> This probably won't apply against current code as there's already a
> better fix there, in general just picking a value to initialise masks
> errors.
I agree on the general rule not to do this, and I'm trying to avoid it
in the cases where I can find a better fix, but here I could not
(mostly because I could not figure out what this code actually
does. Thanks for taking a look.
Which code is the current version? Is your fix headed for 3.8 inclusion?
I still see the warning in 3.8-rc5 as well as yesterday's linux-next,
with gcc-4.6, 4.7 and 4.8-pre.
Arnd
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Felipe Balbi @ 2013-01-26 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301260838300.19277@utopia.booyaka.com>
Hi,
On Sat, Jan 26, 2013 at 08:40:07AM +0000, Paul Walmsley wrote:
> Boot tests:
>
> * am335xbone: hangs after "Starting kernel"
> - Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
> - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
> - http://marc.info/?l=linux-omap&m=135903184512238&w=2
FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
to help my bone, no matter if I had appended DTB or not.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/ef147159/attachment-0001.sig>
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Paul Walmsley @ 2013-01-26 8:40 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic OMAP test results for Linux v3.8-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc5/20130126003323/
Test summary
------------
Boot to userspace:
Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda, 5912osk,
4460pandaes
FAIL ( 2/11): am335xbone, cmt3517
PM ret/off, suspend + dynamic idle:
Pass (3/3): 3530es3beagle, 3730beaglexm, 37xxevm
PM ret, suspend + dynamic idle:
Pass (1/2): 4460pandaes
FAIL (1/2): 4430es2panda
PM ret, dynamic idle:
FAIL (1/1): 2430sdp
Failing tests: fixed by posted patches
--------------------------------------
Other:
* 2420N800: powers down 30 seconds after boot
- Presumably due to missing CBUS patches for watchdog control
- http://lkml.org/lkml/2012/9/3/265
- http://marc.info/?l=linux-omap&m=135274739624125&w=2
- http://marc.info/?l=linux-omap&m=135664195831104&w=2
Failing tests: needing investigation
------------------------------------
Boot tests:
* am335xbone: hangs after "Starting kernel"
- Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
- http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
- http://marc.info/?l=linux-omap&m=135903184512238&w=2
* 3517EVM & CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
* CM-T3517: boot hangs with MMC root
- Due to missing MMC setup in board file
- http://www.spinics.net/lists/arm-kernel/msg211471.html
Boot warnings:
* 3530es3beagle, 3730beaglexm, 37xxevm: nand_scan_ident() warning
- "at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()"
- http://marc.info/?l=linux-omap&m=135630897110185&w=2
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
- Longstanding issue; does not occur on the 3517EVM
PM tests:
* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
- need to doublecheck wakeup dependencies
* 2430sdp: power domains not entering retention
- Cause unknown
* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock gate ("debug ignore_loglevel")
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter reports this does not appear with the same X-loader/bootloader
on his 4430ES2.3 Panda, so could be ES-level dependent
Failing tests: needing local investigation (may be due to testbed issues)
-------------------------------------------------------------------------
Boot tests:
* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
- May be fixed now, pending retest:
- http://marc.info/?l=linux-omap&m=135082257727502&w=2
- Not yet part of the automated test suite
- Nishanth Menon & Vaibhav Hiremath report that it works for them
* May be due to an old U-boot with FDT support problems used here?
Pending local investigation and re-test
vmlinux object size
(delta in bytes from test_v3.8-rc4
(7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619)):
text data bss total kernel
+512 0 0 +512 am33xx_only
+776 +24 0 +800 n800_multi_omap2xxx
+772 -8 0 +764 n800_only_a
+648 0 0 +648 omap1_defconfig
+648 0 0 +648 omap1_defconfig_1510innovator_only
+664 0 0 +664 omap1_defconfig_5912osk_only
+724 +8 0 +732 omap2plus_defconfig
+504 +24 0 +528 omap2plus_defconfig_2430sdp_only
+788 +8 0 +796 omap2plus_defconfig_cpupm
+628 +8 0 +636 omap2plus_defconfig_no_pm
+724 +8 0 +732 omap2plus_defconfig_omap2_4_only
+504 +16 0 +520 omap2plus_defconfig_omap3_4_only
+328 +8 0 +336 rmk_omap3430_ldp_allnoconfig
+656 0 0 +656 rmk_omap3430_ldp_oldconfig
+328 +8 0 +336 rmk_omap4430_sdp_allnoconfig
+800 +8 0 +808 rmk_omap4430_sdp_oldconfig
^ permalink raw reply
* [PATCH 1/2] spi: spi-gpio: Add checks for the dt properties
From: Mark Brown @ 2013-01-26 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359103175-26304-2-git-send-email-maxime.ripard@free-electrons.com>
On Fri, Jan 25, 2013 at 09:39:34AM +0100, Maxime Ripard wrote:
> The bindings assumed that the gpios properties were always there, which
> made the NO_TX and NO_RX mode not usable from device tree. Add extra
> checks to make sure that the driver can work if either MOSI or MISO is
> not used.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/fa7e46d4/attachment.sig>
^ permalink raw reply
* [PATCH] regulators/db8500: Fix compile failure for drivers/regulator/dbx500-prcmu.c
From: Mark Brown @ 2013-01-26 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359041366.21576.146.camel@gandalf.local.home>
On Thu, Jan 24, 2013 at 10:29:26AM -0500, Steven Rostedt wrote:
> Building for the snowball board, I ran into this compile failure:
Applied, thanks. Please use subject lines appropriate for the subsystem
(I see I let the original one through).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/c718ecd1/attachment.sig>
^ permalink raw reply
* [PATCH] Asoc: Samsung: Add support for I2S runtime S2R
From: Mark Brown @ 2013-01-26 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359030931-27354-1-git-send-email-rcsekar@samsung.com>
On Thu, Jan 24, 2013 at 06:05:30PM +0530, R. Chandrasekar wrote:
> From: "R. Chandrasekar" <rcsekar@samsung.com>
>
> This patch adds runtime suspend to resume support for I2S.
>
> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
> Signed-off-by: R. Chandrasekar <rcsekar@samsung.com>
This is good but doesn't apply against topic/samsung, please check and
resend. Note that the signoffs should be in author order - the author
should be first, then people forwarding on the patch. Other people
should have other tags like Acked-by or Reviewed-by.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/7ce70985/attachment.sig>
^ permalink raw reply
* [PATCH] Asoc: Samsung: Add I2S S/W RST in startup function
From: Mark Brown @ 2013-01-26 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359030931-27354-2-git-send-email-rcsekar@samsung.com>
On Thu, Jan 24, 2013 at 06:05:31PM +0530, R. Chandrasekar wrote:
> From: Padmavathi Venna <padma.v@samsung.com>
>
> I2S module need to be reset after S2R. Keeping the S/W rst
> control part in resume didn't help in playing audio after resume.
> So this patch adds S/W RST control part in startup function which
> gets triggered for every new audio stream playback.
Applied, thanks. Please use subject lines matching the subsystem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/dcf6e4df/attachment.sig>
^ permalink raw reply
* [RFC PATCH] ARM: mm: Fix alloc_init_section bug on LPAE
From: Christoffer Dall @ 2013-01-26 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51036083.4040407@ti.com>
On Fri, Jan 25, 2013 at 11:50 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> Hi Christoffer,
>
>
> On Saturday 26 January 2013 06:01 AM, Christoffer Dall wrote:
>>
>> When using LPAE the call to alloc_init_pte is passed then end address
>> for the entire 1st level page table region, and the code unluckily ends
>> up going over the bounds of the single allocated PTE, which is sad.
>>
>> This caused LPAE boot on omap5 to crash.
>>
>> There may be some hidden mystery in the boot code that I'm unaware of
>> or it may be assumed that all mappings are always mappable as sections
>> on LPAE and therefore omap5 just does something bad, in which case this
>> patch isn't the right fix, but I'd be happy to be told the reason.
>>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Jeremy C. Andrus <jeremya@cs.columbia.edu>
>> Signed-off-by: Christoffer Dall <chris@cloudcar.com>
>> ---
>
>
> I was about to reply on the LPAE boot issue you mentioned in other
> email. We have seen couple of issues with LPAE on OMAP5 and sent the
> fixes.
>
> [1] ARM: LPAE: Fix alloc_init_section to flush all the pmd entries
> [2] ARM: LPAE: Fix mapping in alloc_init_pte for unaligned addresses
>
> Both needs ack from Catalin and RMK's ok to get into the patch system.
>
> Can you please check if they work for you ? I expect the [1] should
> make your board boot on OMAP5.
>
yeah, that patch had the same effect as my patch (with the extra waste
of memory for the ptes as Russell pointed out).
My googling of fixes for this completely failed somehow.
Thanks for pointing it out.
-Christoffer
^ permalink raw reply
* [PATCH RESEND] ARM: dts: max77686: Add DTS file for max77686 PMIC
From: Dongjin Kim @ 2013-01-26 6:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126050618.GD10580@opensource.wolfsonmicro.com>
Hello Mark,
Yes, this is not ARM-specific chip at all. Just wanted to be reviewed
by you and others if the format is ok before integrating to my board
file. I had sent similar one before,
https://patchwork.kernel.org/patch/1287711, and you advised that was
too board specific. And plan to integrate like OMAP boards have with
twl6030.dtsi and twl6040.dtsi.
If would be nice if somewhere you specify a directory for such device files.
Regards,
Dongjin.
On Sat, Jan 26, 2013 at 2:06 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Jan 25, 2013 at 03:46:08AM +0900, Dongjin Kim wrote:
>
>> ---
>> arch/arm/boot/dts/max77686.dtsi | 156 +++++++++++++++++++++++++++++++++++++++
>
> Why is this in arch/arm? This isn't an ARM-specific chip.
^ permalink raw reply
* [PATCH 00/13] ARM: spear multiplatform support
From: Viresh Kumar @ 2013-01-26 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359156956-32404-1-git-send-email-arnd@arndb.de>
On Sat, Jan 26, 2013 at 5:05 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> This is a series I did some time ago but forgot to
> send out earlier. I'd like to get this into v3.9,
> so please give this a test if you can.
Wow!! Awesome work Arnd.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [RFC PATCH 4/4] x86: add support for LZ4-compressed kernels
From: Kyungsik Lee @ 2013-01-26 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359179447-31118-1-git-send-email-kyungsik.lee@lge.com>
This patch integrates the LZ4 decompression code to the x86 pre-boot code.
And it depends on two patchs below
lib: add support for LZ4-compressed kernels
decompressors: add lz4 decompressor module
Signed-off-by: Kyungsik Lee <kyungsik.lee@lge.com>
---
arch/x86/Kconfig | 1 +
arch/x86/boot/compressed/Makefile | 5 ++++-
arch/x86/boot/compressed/misc.c | 4 ++++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8c185d0..7142bef 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -62,6 +62,7 @@ config X86
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_XZ
select HAVE_KERNEL_LZO
+ select HAVE_KERNEL_LZ4
select HAVE_HW_BREAKPOINT
select HAVE_MIXED_BREAKPOINTS_REGS
select PERF_EVENTS
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 8a84501..c275db5 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -4,7 +4,7 @@
# create a compressed vmlinux image from the original vmlinux
#
-targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo head_$(BITS).o misc.o string.o cmdline.o early_serial_console.o piggy.o
+targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4 head_$(BITS).o misc.o string.o cmdline.o early_serial_console.o piggy.o
KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2
KBUILD_CFLAGS += -fno-strict-aliasing -fPIC
@@ -64,12 +64,15 @@ $(obj)/vmlinux.bin.xz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,xzkern)
$(obj)/vmlinux.bin.lzo: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lzo)
+$(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y) FORCE
+ $(call if_changed,lz4)
suffix-$(CONFIG_KERNEL_GZIP) := gz
suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_LZMA) := lzma
suffix-$(CONFIG_KERNEL_XZ) := xz
suffix-$(CONFIG_KERNEL_LZO) := lzo
+suffix-$(CONFIG_KERNEL_LZ4) := lz4
quiet_cmd_mkpiggy = MKPIGGY $@
cmd_mkpiggy = $(obj)/mkpiggy $< > $@ || ( rm -f $@ ; false )
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 88f7ff6..166a0a8 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -145,6 +145,10 @@ static int lines, cols;
#include "../../../../lib/decompress_unlzo.c"
#endif
+#ifdef CONFIG_KERNEL_LZ4
+#include "../../../../lib/decompress_unlz4.c"
+#endif
+
static void scroll(void)
{
int i;
--
1.8.0.3
^ permalink raw reply related
* [RFC PATCH 3/4] arm: add support for LZ4-compressed kernels
From: Kyungsik Lee @ 2013-01-26 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359179447-31118-1-git-send-email-kyungsik.lee@lge.com>
This patch integrates the LZ4 decompression code to the arm pre-boot code.
And it depends on two patchs below
lib: add support for LZ4-compressed kernels
decompressors: add lz4 decompressor module
Signed-off-by: Kyungsik Lee <kyungsik.lee@lge.com>
---
arch/arm/Kconfig | 1 +
arch/arm/boot/compressed/.gitignore | 1 +
arch/arm/boot/compressed/Makefile | 3 ++-
arch/arm/boot/compressed/decompress.c | 4 ++++
arch/arm/boot/compressed/piggy.lz4.S | 6 ++++++
5 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/compressed/piggy.lz4.S
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 91f8d78..1b3621d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -37,6 +37,7 @@ config ARM
select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7))
select HAVE_IDE if PCI || ISA || PCMCIA
select HAVE_KERNEL_GZIP
+ select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_LZO
select HAVE_KERNEL_XZ
diff --git a/arch/arm/boot/compressed/.gitignore b/arch/arm/boot/compressed/.gitignore
index f79a08e..47279aa 100644
--- a/arch/arm/boot/compressed/.gitignore
+++ b/arch/arm/boot/compressed/.gitignore
@@ -6,6 +6,7 @@ piggy.gzip
piggy.lzo
piggy.lzma
piggy.xzkern
+piggy.lz4
vmlinux
vmlinux.lds
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 5cad8a6..8b5c79a 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -88,6 +88,7 @@ suffix_$(CONFIG_KERNEL_GZIP) = gzip
suffix_$(CONFIG_KERNEL_LZO) = lzo
suffix_$(CONFIG_KERNEL_LZMA) = lzma
suffix_$(CONFIG_KERNEL_XZ) = xzkern
+suffix_$(CONFIG_KERNEL_LZ4) = lz4
# Borrowed libfdt files for the ATAG compatibility mode
@@ -112,7 +113,7 @@ targets := vmlinux vmlinux.lds \
font.o font.c head.o misc.o $(OBJS)
# Make sure files are removed during clean
-extra-y += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern \
+extra-y += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern piggy.lz4 \
lib1funcs.S ashldi3.S $(libfdt) $(libfdt_hdrs)
ifeq ($(CONFIG_FUNCTION_TRACER),y)
diff --git a/arch/arm/boot/compressed/decompress.c b/arch/arm/boot/compressed/decompress.c
index 9deb56a..a95f071 100644
--- a/arch/arm/boot/compressed/decompress.c
+++ b/arch/arm/boot/compressed/decompress.c
@@ -53,6 +53,10 @@ extern char * strstr(const char * s1, const char *s2);
#include "../../../../lib/decompress_unxz.c"
#endif
+#ifdef CONFIG_KERNEL_LZ4
+#include "../../../../lib/decompress_unlz4.c"
+#endif
+
int do_decompress(u8 *input, int len, u8 *output, void (*error)(char *x))
{
return decompress(input, len, NULL, NULL, output, NULL, error);
diff --git a/arch/arm/boot/compressed/piggy.lz4.S b/arch/arm/boot/compressed/piggy.lz4.S
new file mode 100644
index 0000000..3d9a575
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.lz4.S
@@ -0,0 +1,6 @@
+ .section .piggydata,#alloc
+ .globl input_data
+input_data:
+ .incbin "arch/arm/boot/compressed/piggy.lz4"
+ .globl input_data_end
+input_data_end:
--
1.8.0.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox