* [PATCH v3] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
From: Tony Lindgren @ 2012-10-15 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210150523190.15973@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121014 22:26]:
>
> After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
> saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
> started crashing during boot with omap2plus_defconfig:
>
> [ 3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
> [ 3.915954] mmcblk0: p1
> [ 4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> [ 4.093719] Modules linked in:
> [ 4.096954] CPU: 0 Not tainted (3.6.0-02232-g759e00b #570)
> [ 4.103149] PC is at vfp_reload_hw+0x1c/0x44
> [ 4.107666] LR is at __und_usr_fault_32+0x0/0x8
>
> It turns out that the context save/restore fix unmasked a latent bug
> in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make
> VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is
> booted on a pre-VFPv3 core, the code attempts to save and restore the
> d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so
> this results in an undefined instruction exception. The code didn't
> crash before commit 846a136 because the save and restore code was
> only touching d0-d15, present on all VFP.
>
> Fix by implementing a request from Russell King to add a new HWCAP
> flag that affirmatively indicates the presence of the d16-d31
> registers:
>
> http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2
>
> and some feedback from M?ns to clarify the name of the HWCAP flag.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Martin <dave.martin@linaro.org>
> Cc: M?ns Rullg?rd <mans.rullgard@linaro.org>
This fixes the error above on my 2430sdp:
Tested-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 9/9] ARM: add uprobes support
From: Dave Martin @ 2012-10-15 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH+eYFC1fr0vpK2T4hz9LK=Nz5bzQBQ4O-o0f9tsnj-_D9ZEJg@mail.gmail.com>
On Mon, Oct 15, 2012 at 01:44:55PM +0200, Rabin Vincent wrote:
> 2012/10/15 Dave Martin <dave.martin@linaro.org>:
> > On Sun, Oct 14, 2012 at 09:23:13PM +0200, Rabin Vincent wrote:
> >> Add basic uprobes support for ARM.
> >>
> >> perf probe --exec and SystemTap's userspace probing work. The ARM
> >> kprobes test code has also been run in a userspace harness to test the
> >> uprobe instruction decoding.
> >
> > The assumption that the target code is ARM appears to be buried all over
> > the place.
>
> Right, as stated:
>
> >> Caveats:
> >> - Thumb is not supported
>
> > Certainly this code as currently written must depend on !THUMB2_KERNEL.
>
> Why? It currently works for ARM userspace even if the kernel is
> Thumb-2.
My bad, I misread what was happening in the Makefile changes.
My concern is about whether we can build the ARM and Thumb-2 kprobes
code into the same kernel. If so, no problem, but I believe this is
not a tested configuration for kprobes itself.
If you've not already done so, it should be possible to test this
by adding CONFIG_THUMB2_KERNEL=y to your config, providing your
hardware is Thumb-2 capable.
> > However, there's an underlying problem here which we'd need to solve.
> > The kprobes code can take advantage of the fact that the kernel is all
> > ARM or (almost) all Thumb code. So there is no support for kprobes
> > supporting ARM and Thumb at the same time.
> >
> > With userspace, we don't have this luxury. With Debian armhf, Ubuntu
> > and Linaro building Thumb-2 userspaces, it may be an increasingly common
> > configuration independently of whether the kernel is built in Thumb-2
> > or not.
> >
> > Furthermode, there is no such thing as a pure Thumb-2 system in practice:
> > PLTs are always ARM, for example. For uprobes to work well in userspace,
> > both should be supported together.
>
> Right. I don't think it's difficult to support both of them together,
> my thought was just to have userspace tell us if they want to probe a
> Thumb instruction via the usual 0th-bit set convention, and then take it
> from there. I didn't do the Thumb handling currently because I didn't
> really look into modifying the kprobes Thumb instruction decoding and
> the IT handling for uprobes.
Having looked at the code a little more closely, it looks more closely
aligned with this goal than I thought at first.
I agree with your suggestion to require the caller to specify explicitly
whether they want to insert an ARM or Thumb probe (indeed, I think
there's no other way to do it, since guessing the target instruction
set can't be done reliably). The code for setting a probe can then
switch trivially on that low bit.
Additional undef_hooks would be needed for the Thumb case, but this
looks relatively straightforward, as you say.
General question which I'm not sure I understand yet: is is possible
to combine uprobes/kprobes decode more completely? It's not obvious
to me whether the uprobes-specific decoding only relates to features
which architecturally execute differently in user mode versus
privileged mode. Some explanation somewhere could be helpful.
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/4] leds: leds-ns2: add device tree binding
From: Jason Cooper @ 2012-10-15 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350315295-14567-2-git-send-email-simon.guinot@sequanux.org>
On Mon, Oct 15, 2012 at 05:34:52PM +0200, Simon Guinot wrote:
> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> ---
> .../devicetree/bindings/gpio/leds-ns2.txt | 26 ++++++
> drivers/leds/leds-ns2.c | 84 +++++++++++++++++++-
> 2 files changed, 107 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/leds-ns2.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/leds-ns2.txt b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
> new file mode 100644
> index 0000000..1a84969
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
> @@ -0,0 +1,26 @@
> +Binding for dual-GPIO LED found on Network Space v2 (and parents).
> +
> +Required properties:
> +- compatible: "ns2-leds".
> +
> +Each LED is represented as a sub-node of the ns2-leds device.
> +
> +Required sub-node properties:
> +- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
> +- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
> +
> +Optional sub-node properties:
> +- label: Name for this LED. If omitted, the label is taken from the node name.
> +- linux,default-trigger: Trigger assigned to the LED.
> +
> +Example:
> +
> +ns2-leds {
> + compatible = "ns2-leds";
> +
> + blue-sata {
> + label = "ns2:blue:sata";
> + slow-gpio = <&gpio0 29 0>;
> + cmd-gpio = <&gpio0 30 0>;
> + };
> +};
> diff --git a/drivers/leds/leds-ns2.c b/drivers/leds/leds-ns2.c
> index d176ec8..55d199b 100644
> --- a/drivers/leds/leds-ns2.c
> +++ b/drivers/leds/leds-ns2.c
> @@ -30,6 +30,7 @@
> #include <linux/leds.h>
> #include <linux/module.h>
> #include <linux/platform_data/leds-kirkwood-ns2.h>
> +#include <linux/of_gpio.h>
>
> /*
> * The Network Space v2 dual-GPIO LED is wired to a CPLD and can blink in
> @@ -263,6 +264,68 @@ static void delete_ns2_led(struct ns2_led_data *led_dat)
> gpio_free(led_dat->slow);
> }
>
> +#ifdef CONFIG_OF_GPIO
> +/*
> + * Translate OpenFirmware node properties into platform_data.
> + */
> +static int __devinit
> +ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
> +{
> + struct device_node *np = dev->of_node;
> + struct device_node *child;
> + struct ns2_led *leds;
> + int num_leds = 0;
> + int i = 0;
> +
> + num_leds = of_get_child_count(np);
> + if (!num_leds)
> + return -ENODEV;
> +
> + leds = devm_kzalloc(dev, num_leds * sizeof(struct ns2_led),
> + GFP_KERNEL);
> + if (!leds)
> + return -ENOMEM;
> +
> + for_each_child_of_node(np, child) {
> + const char *string;
> + int ret;
> +
> + ret = of_get_named_gpio(child, "cmd-gpio", 0);
> + if (ret < 0)
> + return ret;
free leds?
> + leds[i].cmd = ret;
> + ret = of_get_named_gpio(child, "slow-gpio", 0);
> + if (ret < 0)
> + return ret;
same here.
> + leds[i].slow = ret;
> + ret = of_property_read_string(child, "label", &string);
> + leds[i].name = (ret == 0) ? string : child->name;
> + ret = of_property_read_string(child, "linux,default-trigger",
> + &string);
> + if (ret == 0)
> + leds[i].default_trigger = string;
> +
> + i++;
> + }
> +
> + pdata->leds = leds;
> + pdata->num_leds = num_leds;
> +
> + return 0;
> +}
> +
> +static const struct of_device_id of_ns2_leds_match[] = {
> + { .compatible = "ns2-leds", },
Is this LaCie-specific? eg "lacie,ns2-leds"?
> + {},
> +};
> +#else
> +static int __devinit
> +ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
> +{
> + return -ENODEV;
> +}
> +#endif /* CONFIG_OF_GPIO */
The above doesn't look right to me. The only time
ns2_leds_get_of_pdata() gets called is when OF_GPIO is enabled. You
should be able to remove the #else block.
> +
> static int __devinit ns2_led_probe(struct platform_device *pdev)
> {
> struct ns2_led_platform_data *pdata = pdev->dev.platform_data;
> @@ -270,11 +333,25 @@ static int __devinit ns2_led_probe(struct platform_device *pdev)
> int i;
> int ret;
>
> +#ifdef CONFIG_OF_GPIO
> + if (!pdata) {
> + pdata = devm_kzalloc(&pdev->dev,
> + sizeof(struct ns2_led_platform_data),
> + GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + ret = ns2_leds_get_of_pdata(&pdev->dev, pdata);
> + if (ret)
> + return ret;
> + }
> +#else
> if (!pdata)
> return -EINVAL;
> +#endif /* CONFIG_OF_GPIO */
>
> leds_data = devm_kzalloc(&pdev->dev, sizeof(struct ns2_led_data) *
> - pdata->num_leds, GFP_KERNEL);
> + pdata->num_leds, GFP_KERNEL);
> if (!leds_data)
> return -ENOMEM;
>
> @@ -312,8 +389,9 @@ static struct platform_driver ns2_led_driver = {
> .probe = ns2_led_probe,
> .remove = __devexit_p(ns2_led_remove),
> .driver = {
> - .name = "leds-ns2",
> - .owner = THIS_MODULE,
> + .name = "leds-ns2",
> + .owner = THIS_MODULE,
nit. whitespace before '=', above two lines.
> + .of_match_table = of_match_ptr(of_ns2_leds_match),
Have you tried this with OF_GPIO=n? of_match_ptr() handles CONFIG_OF
being enabled/disabled. Which means the case of CONFIG_OF=y,
CONFIG_OF_GPIO=n appears to be unhandled.
thx,
Jason.
> },
> };
>
> --
> 1.7.10
>
^ permalink raw reply
* [PATCH] ARM: tegra: update *.dts for regulator-compatible deprecation
From: Stephen Warren @ 2012-10-15 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349204824-21758-1-git-send-email-swarren@wwwdotorg.org>
On 10/02/2012 01:07 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Commit 13511de "regulator: deprecate regulator-compatible DT property"
> now allows for simpler content within the regulators node within a PMIC.
> Modify all the Tegra device tree files to take advantage of this.
Applied to Tegra's for-3.8/cleanup.
^ permalink raw reply
* [PATCH 9/9] ARM: add uprobes support
From: Dave Martin @ 2012-10-15 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350242593-17761-9-git-send-email-rabin@rab.in>
On Sun, Oct 14, 2012 at 09:23:13PM +0200, Rabin Vincent wrote:
> Add basic uprobes support for ARM.
>
> perf probe --exec and SystemTap's userspace probing work. The ARM
> kprobes test code has also been run in a userspace harness to test the
> uprobe instruction decoding.
>
> Caveats:
>
> - Thumb is not supported
> - XOL abort/trap handling is not implemented
[...]
> diff --git a/arch/arm/kernel/uprobes.c b/arch/arm/kernel/uprobes.c
> new file mode 100644
> index 0000000..f25a4af
> --- /dev/null
> +++ b/arch/arm/kernel/uprobes.c
[...]
> +bool is_swbp_insn(uprobe_opcode_t *insn)
> +{
> + return (__mem_to_opcode_arm(*insn) & 0x0fffffff) == UPROBE_SWBP_INSN;
You should take care not to match any instruction whose top bits are
0xF0000000. That could be some completely different instruction.
[...]
> +static int uprobe_trap_handler(struct pt_regs *regs, unsigned int instr)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + if ((instr & 0x0fffffff) == UPROBE_SWBP_INSN)
Is the check unnecessary here? I think the same comparison will
happen as a result of evaluating the associated undef_hook.
However, as above you must still check for and reject cases where
(instr & 0xF0000000) == 0xF0000000.
[...]
> +static struct undef_hook uprobes_arm_break_hook = {
> + .instr_mask = 0x0fffffff,
> + .instr_val = UPROBE_SWBP_INSN,
> + .cpsr_mask = MODE_MASK,
> + .cpsr_val = USR_MODE,
> + .fn = uprobe_trap_handler,
> +};
> +
> +static struct undef_hook uprobes_arm_ss_hook = {
> + .instr_mask = 0x0fffffff,
> + .instr_val = UPROBE_SS_INSN,
> + .cpsr_mask = MODE_MASK,
> + .cpsr_val = USR_MODE,
> + .fn = uprobe_trap_handler,
> +};
^ permalink raw reply
* [PATCH RFC 1/6 v3] gpio: Add a block GPIO API to gpiolib
From: Roland Stigge @ 2012-10-15 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507B9D05.1000204@gmail.com>
Hi Ryan,
thank you for your feedback, I will include it, except for some points
noted below:
On 10/15/2012 07:20 AM, Ryan Mallon wrote:
>> +The above described interface concentrates on handling single GPIOs. However,
>> +in applications where it is critical to set several GPIOs at once, this
>> +interface doesn't work well, e.g. bit-banging protocols via grouped GPIO lines.
>> +Consider a GPIO controller that is connected via a slow I2C line. When
>> +switching two or more GPIOs one after another, there can be considerable time
>> +between those events. This is solved by an interface called Block GPIO:
>
> The emulate behaviour of gpio block switches gpios one after the other.
> Is the problem only solved if the block_get/block_set callbacks can be
> implemented?
Right, this is documented some lines away:
>> +struct gpio_block *gpio_block_create(unsigned int *gpios, size_t size);
>> +
>> +This creates a new block of GPIOs as a list of GPIO numbers with the specified
>> +size which are accessible via the returned struct gpio_block and the accessor
>> +functions described below. Please note that you need to request the GPIOs
>> +separately via gpio_request(). An arbitrary list of globally valid GPIOs can be
>> +specified, even ranging over several gpio_chips. Actual handling of I/O
>> +operations will be done on a best effort base, i.e. simultaneous I/O only where
>> +possible by hardware and implemented in the respective GPIO driver. The number
>> +of GPIOs in one block is limited to 32 on a 32 bit system, and 64 on a 64 bit
>> +system. However, several blocks can be defined at once.
>> +
>> +unsigned gpio_block_get(struct gpio_block *block);
>> +void gpio_block_set(struct gpio_block *block, unsigned value);
>> +
>> +With those accessor functions, setting and getting the GPIO values is possible,
>> +analogous to gpio_get_value() and gpio_set_value(). Each bit in the return
>> +value of gpio_block_get() and in the value argument of gpio_block_set()
>> +corresponds to a bit specified on gpio_block_create(). Block operations in
>> +hardware are only possible where the respective GPIO driver implements it,
>> +falling back to using single GPIO operations where the driver only implements
>> +single GPIO access.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
... here.
>> +struct gpio_block *gpio_block_create(unsigned *gpios, size_t size,
>> + const char *name)
>> +{
>> + struct gpio_block *block;
>> + struct gpio_block_chip *gbc;
>> + struct gpio_remap *remap;
>> + int i;
>> +
>> + if (size < 1 || size > sizeof(unsigned) * 8)
>> + return ERR_PTR(-EINVAL);
>> +
>> + block = kzalloc(sizeof(struct gpio_block), GFP_KERNEL);
>> + if (!block)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + block->name = name;
>> + block->ngpio = size;
>> + block->gpio = kzalloc(sizeof(*block->gpio) * size, GFP_KERNEL);
>> + if (!block->gpio)
>> + goto err1;
>> +
>> + memcpy(block->gpio, gpios, sizeof(*block->gpio) * size);
>> +
>> + for (i = 0; i < size; i++)
>> + if (!gpio_is_valid(gpios[i]))
>> + goto err2;
>
> This loop should probably go at the start of the function, so you can
> avoid doing the kzalloc/memcpy if it fails.
OK.
> This function doesn't call gpio_request. Either it should, or it should
> rely on the caller to have already done so, and call
> gpio_ensure_requested here. There is also an implicit rule that any
> gpios inside a block must not be freed as long as the block exists.
The idea is analogous to GPIOs itself. Just the existence of it doesn't
require it being requested. This way, it is possible to e.g. instantiate
a block via device tree and let the user itself take care for direction,
requesting and so on. Look at the sysfs binding: Only when someone
exports the actual block values to userspace (write 0/1 to "exported"),
the GPIOs in the block are requested by "sysfs".
Please note that this is already documented above (look for "Please note").
>> +
>> + for (i = 0; i < size; i++) {
>> + struct gpio_chip *gc = gpio_to_chip(gpios[i]);
>> + int bit = gpios[i] - gc->base;
>> + int index = gpio_block_chip_index(block, gc);
>> +
>> + if (index < 0) {
>> + block->nchip++;
>> + block->gbc = krealloc(block->gbc,
>> + sizeof(struct gpio_block_chip) *
>> + block->nchip, GFP_KERNEL);
>
> krealloc is a bit nasty. Can't you add a struct list_head to struct
> gpio_block_chip or something?
I also hesitated. But having it this way provides quite efficient access
later on.
> This also leaks memory if the krealloc fails, since the original pointer
> is lost. You need to use a temporary for the re-allocation.
OK.
>> + /* represents the mask necessary on calls to the driver's
>> + * .get_block() and .set_block()
>> + */
>
> /*
> * Nitpick - multi-line comment style looks like this.
> * However, other comments in this file use this style
> * so maybe keep for consistency.
> */
Right, decided for the latter.
>> + gbc->mask |= BIT(bit);
>> +
>> + /* collect gpios that are specified together, represented by
>> + * neighboring bits
>> + */
>> + remap = &gbc->remap[gbc->nremap - 1];
>
> This looks broken. If gbc was re-alloced above (index < 0) then
> gbc->remap == NULL and this will oops?
No, because I took care that even though index can be < 0, the resulting
pointer is never dereferenced for -1.
>
>> + if (!gbc->nremap || (bit - i != remap->offset)) {
>
> gbc->nremap would have to be non-zero here, otherwise you have:
>
> gbc->remap[0 - 1]
>
> above.
>
>> + gbc->nremap++;
^^^^^^^^^^^^^^
... here it is: in the gbc->nremap == 0 case, it gets incremented
immediately and remap is not dereferenced. Even in the above ( || ), the
right side is only evaluated if gbc->nremap > 0.
>> + if (!gbc->remap)
>> + goto err3;
>> + remap = &gbc->remap[gbc->nremap - 1];
>> + remap->offset = bit - i;
>> + remap->mask = 0;
>> + }
>> +
>> + /* represents the mask necessary for bit reordering between
>> + * gpio_block (i.e. as specified on gpio_block_get() and
>> + * gpio_block_set()) and gpio_chip domain (i.e. as specified on
>> + * the driver's .set_block() and .get_block())
>> + */
>> + remap->mask |= BIT(i);
>> + }
>
> The remap functionality isn't very well explained
Documenting now in gpio.h like this:
/*
* struct gpio_remap - a structure for describing a bit mapping
* @mask: a bit mask
* @offset: how many bits to shift to the left (negative: to the
* right)
*
* When we are mapping bit values from one word to another (here: from
* GPIO block domain to GPIO driver domain), we first mask them out
* with mask and shift them as specified with offset. More complicated
* mappings are done by grouping several of those structs and adding
* the results together.
*/
struct gpio_remap {
int mask;
int offset;
};
> (and looks like it doesn't work properly anyway).
If you find an issue, please let me know. Works fine for me. Have you
tried? :-)
>> +unsigned gpio_block_get(const struct gpio_block *block)
>> +{
>> + struct gpio_block_chip *gbc;
>> + int i, j;
>> + unsigned values = 0;
>> +
>> + for (i = 0; i < block->nchip; i++) {
>> + unsigned remapped = 0;
>> +
>> + gbc = &block->gbc[i];
>> +
>> + if (gbc->gc->get_block) {
>> + remapped = gbc->gc->get_block(gbc->gc, gbc->mask);
>> + } else { /* emulate */
>> + unsigned bit = 1;
>> +
>> + for (j = 0; j < sizeof(unsigned) * 8; j++, bit <<= 1) {
>> + if (gbc->mask & bit)
>
> A proper bitmask might be more ideal for this. It would remove the
> sizeof(unsigned) restriction and allow you to use for_each_set_bit for
> these loops.
In a previous version of these patches, I actually had a generic bit
mask which was in turn awkward to handle, especially for the bit
remapping. Stijn brought me to the idea that for pragmatic reasons, 32
bit access is fully sufficient in most cases.
I also needed userland access (via sysfs), so there was no way of
accessing a block except via an int.
When there are GPIO drivers where we seriously need (and can handle
simultaneously) more than 32 bits, we can still extend the API. For now,
the cases where it is used is typically creating 8/16/32 bit busses with
GPIO lines, and on 64bit architectures even 64bit busses.
For this, the current API is working fine, even enabling userland access
via sysfs.
>> + unsigned bit = 1;
>> +
>> + for (j = 0; j < sizeof(unsigned) * 8; j++, bit <<= 1) {
>> + if (gbc->mask & bit)
>> + gbc->gc->set(gbc->gc, gbc->gc->base + j,
>> + (remapped >> j) & 1);
>> + }
>
> This doesn't clear pins which are set to zero?
It does. gbc->mask only masks which bits to set and clear. remapped
contains the actual bit values to set. 0 or 1.
Including all the other suggestions in the next update.
Thanks,
Roland
^ permalink raw reply
* [PATCH 1/9] uprobes: move function declarations out of arch
From: Srikar Dronamraju @ 2012-10-15 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350242593-17761-1-git-send-email-rabin@rab.in>
* Rabin Vincent <rabin@rab.in> [2012-10-14 21:23:05]:
> It seems odd to keep the function declarations in the arch header where
> they will need to be copy/pasted verbatim across arches. Move them to
> the common header.
>
> Signed-off-by: Rabin Vincent <rabin@rab.in>
> ---
> arch/x86/include/asm/uprobes.h | 6 ------
> include/linux/uprobes.h | 8 ++++++++
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
You need to take care of the powerpc port
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=8b7b80b9ebb46dd88fbb94e918297295cf312b59
Also as Oleg pointed out, He has already posted changes on top of -tip.
So it probably makes sense to redo these patches on top of those
patches.
--
Thanks and Regards
Srikar
^ permalink raw reply
* [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
From: Catalin Marinas @ 2012-10-15 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015162732.GG2616@ZenIV.linux.org.uk>
On Mon, Oct 15, 2012 at 05:27:32PM +0100, Al Viro wrote:
> On Mon, Oct 15, 2012 at 05:07:10PM +0100, Catalin Marinas wrote:
> > On Sun, Oct 14, 2012 at 08:56:11PM +0100, Al Viro wrote:
> > > On Sun, Oct 14, 2012 at 08:24:03PM +0100, Al Viro wrote:
> > >
> > > > Russell, could you recall what those had been about? I'm not sure if that
> > > > had been oopsable that far back (again, oops scenario is userland stack
> > > > page getting swapped out before we get to start_thread(), leading to
> > > > direct read from an absent page in start_thread() by plain ldr, without
> > > > anything in exception table about that insn), but it looks very odd
> > > > regardless of that problem.
> > >
> > > BTW, arm64 has copied that logics, so it also seems to be unsafe and very
> > > odd - there we definitely have only ELF to cope with. arm64 folks Cc'd...
> >
> > Good point. We don't need this on arm64 and probably neither on arm (at
> > least since EABI).
> >
> > Setting x0 may cause other issues as well. The dynamic loader simply
> > ignores the startup registers but for static binaries the _start code in
> > glibc expects r0 to contain a function pointer to be registered with
> > atexit() in __libc_start_main() or NULL. Since we pass argc in there,
> > for static binaries the rtld_fini argument to __libc_start_main() is
> > neither NULL nor something meaningful.
>
> The value left there by start_thread() will not reach the userland anyway...
Ah, yes. So not causing any user issues (apart from the possible fault
in the kernel while accessing the user stack).
--
Catalin
^ permalink raw reply
* [PATCH 0/4] Add DT support for Network Space v2 and parents
From: Jason Cooper @ 2012-10-15 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350315295-14567-1-git-send-email-simon.guinot@sequanux.org>
Hey Simon,
On Mon, Oct 15, 2012 at 05:34:51PM +0200, Simon Guinot wrote:
> This patch series provides DT support for LaCie NAS Network Space v2 and
> parents. This includes the following machines:
> - Internet Space v2
> - Network Space v2
> - Network Space Max v2
> - Network Space Lite v2
> - Network Space Mini v2
>
> Note that the three first boards are already supported by the Linux
> kernel via an "old-fashion" board setup. The two lasts (Lite and Mini)
> are new boards.
Have you checked building support for the old and new in one kernel? On
a quick check, it looks okay, but I only checked that ns2_init() wasn't
the _init function for the legacy board files.
> Also note that the first patch of the series is related with the LED
> subsystem. It adds device tree binding to the driver leds-ns2.
>
> Simon Guinot (4):
> leds: leds-ns2: add device tree binding
> ARM: kirkwood: DT board setup for Network Space v2 and parents
> ARM: kirkwood: DT board setup for Network Space Lite v2
> ARM: kirkwood: DT board setup for Network Space Mini v2
I'm pretty sure this isn't the first version of this patch series ;-)
No need to resend, but could you attach a version number and changelog?
thx,
Jason.
>
> .../devicetree/bindings/gpio/leds-ns2.txt | 26 ++++++
> arch/arm/boot/dts/Makefile | 5 ++
> arch/arm/boot/dts/kirkwood-is2.dts | 30 +++++++
> arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 63 ++++++++++++++
> arch/arm/boot/dts/kirkwood-ns2.dts | 30 +++++++
> arch/arm/boot/dts/kirkwood-ns2lite.dts | 30 +++++++
> arch/arm/boot/dts/kirkwood-ns2max.dts | 49 +++++++++++
> arch/arm/boot/dts/kirkwood-ns2mini.dts | 49 +++++++++++
> arch/arm/mach-kirkwood/Kconfig | 36 ++++++++
> arch/arm/mach-kirkwood/Makefile | 5 ++
> arch/arm/mach-kirkwood/board-dt.c | 12 +++
> arch/arm/mach-kirkwood/board-ns2.c | 87 ++++++++++++++++++++
> arch/arm/mach-kirkwood/common.h | 10 +++
> drivers/leds/Kconfig | 4 +-
> drivers/leds/leds-ns2.c | 84 ++++++++++++++++++-
> 15 files changed, 516 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/leds-ns2.txt
> create mode 100644 arch/arm/boot/dts/kirkwood-is2.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ns2-common.dtsi
> create mode 100644 arch/arm/boot/dts/kirkwood-ns2.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ns2lite.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ns2max.dts
> create mode 100644 arch/arm/boot/dts/kirkwood-ns2mini.dts
> create mode 100644 arch/arm/mach-kirkwood/board-ns2.c
>
> --
> 1.7.10
>
^ permalink raw reply
* [PATCH 6/9] uprobes: flush cache after xol write
From: Oleg Nesterov @ 2012-10-15 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350242593-17761-6-git-send-email-rabin@rab.in>
On 10/14, Rabin Vincent wrote:
>
> Flush the cache so that the instructions written to the XOL area are
> visible.
>
> Signed-off-by: Rabin Vincent <rabin@rab.in>
> ---
> kernel/events/uprobes.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index ca000a9..8c52f93 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1246,6 +1246,7 @@ static unsigned long xol_get_insn_slot(struct uprobe *uprobe, unsigned long slot
> offset = current->utask->xol_vaddr & ~PAGE_MASK;
> vaddr = kmap_atomic(area->page);
> arch_uprobe_xol_copy(&uprobe->arch, vaddr + offset);
> + flush_dcache_page(area->page);
> kunmap_atomic(vaddr);
I agree... but why under kmap_atomic?
Oleg.
^ permalink raw reply
* [PATCH 3/9] uprobes: allow ignoring of probe hits
From: Oleg Nesterov @ 2012-10-15 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350242593-17761-3-git-send-email-rabin@rab.in>
On 10/14, Rabin Vincent wrote:
>
> Allow arches to decided to ignore a probe hit. ARM will use this to
> only call handlers if the conditions to execute a conditionally executed
> instruction are satisfied.
Not sure I understand why we shouldn't call handlers in this case,
but OK, I know nothing about arm.
> static struct uprobe *find_active_uprobe(unsigned long bp_vaddr, int *is_swbp)
> {
> struct mm_struct *mm = current->mm;
> @@ -1469,6 +1474,7 @@ static void handle_swbp(struct pt_regs *regs)
> struct uprobe *uprobe;
> unsigned long bp_vaddr;
> int uninitialized_var(is_swbp);
> + bool ignored = false;
>
> bp_vaddr = uprobe_get_swbp_addr(regs);
> uprobe = find_active_uprobe(bp_vaddr, &is_swbp);
> @@ -1499,6 +1505,12 @@ static void handle_swbp(struct pt_regs *regs)
> goto cleanup_ret;
> }
> utask->active_uprobe = uprobe;
> +
> + if (arch_uprobe_ignore(&uprobe->arch, regs)) {
> + ignored = true;
> + goto cleanup_ret;
> + }
> +
> handler_chain(uprobe, regs);
> if (uprobe->flags & UPROBE_SKIP_SSTEP && can_skip_sstep(uprobe, regs))
> goto cleanup_ret;
> @@ -1514,7 +1526,7 @@ cleanup_ret:
> utask->active_uprobe = NULL;
> utask->state = UTASK_RUNNING;
> }
> - if (!(uprobe->flags & UPROBE_SKIP_SSTEP))
> + if (!ignored && !(uprobe->flags & UPROBE_SKIP_SSTEP))
>
> /*
> * cannot singlestep; cannot skip instruction;
This conflicts with other changes in
git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes/core
Could you re-diff?
I'll try to read 1-7 tomorrow.
Oleg.
^ permalink raw reply
* Use coupled cpuidle on imx6q
From: Shawn Guo @ 2012-10-15 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRRGyPB1DvXqkmNpF=hA-3ya5Y+JLV-KY5BW+FX_RoEc9g@mail.gmail.com>
Changed subject (was: Re: [PATCH 7/7] ARM: tegra30: cpuidle: add LP2
driver for CPU0) ...
On Fri, Oct 12, 2012 at 01:50:35PM -0700, Colin Cross wrote:
> Current coupled cpuidle requires all cpus to wake up together and go
> back to the idle governor to select a new state, because that's what
> all available ARM cpus did when I wrote it. You should be able to
> implement coupled idle on a cpu that does not need to wake all the
> cpus if you wake them anyways,
Can you please elaborate it a little bit? I do not quite understand
what you mean.
Basically, imx6q has a low-power mode named WAIT. When all 4 cores
are in WFI, imx6q will go into WAIT mode, and whenever there is a
wakeup interrupt, it will exit WAIT mode. Software can configure
hardware behavior during WAIT mode, clock gating or power gating for
ARM core.
I'm trying to implement this low-power mode with coupled cpuidle.
I initially have the following code as the coupled cpuidle enter
function for clock gating case.
static int imx6q_enter_wait_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
{
int cpu = dev->cpu;
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
if (atomic_inc_return(&master) == num_online_cpus())
imx6q_set_lpm(WAIT_UNCLOCKED);
cpu_do_idle();
if (atomic_dec_return(&master) == num_online_cpus() - 1)
imx6q_set_lpm(WAIT_CLOCKED);
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
return index;
}
However I think there are a couple of problems. The first one is the
extra wakeups you have mentioned. When last cpu is in call
imx6q_set_lpm(), some of the first 3 cpus that are already in WFI may
exit from there. The second one is when hardware exits WAIT mode and
has ARM clock resumed, some cpus may stay in WFI if scheduler has
nothing to wake them up. This breaks the requirement of coupled cpuidle
that all cpus need to exit together. I can force the function to work
around the problems by adding cpuidle_coupled_parallel_barrier() just
above cpu_do_idle() and arch_send_wakeup_ipi_mask(cpu_online_mask)
right after imx6q_set_lpm(WAIT_CLOCKED). But I doubt it's appropriate.
So I rewrite the function as below to not use coupled cpuidle, and it
works fine.
static int imx6q_enter_wait(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
{
int cpu = dev->cpu;
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
if (atomic_inc_return(&master) == num_online_cpus()) {
/*
* With this lock, we prevent the other cpu to exit and
* enter this function again and become the master.
*/
if (!spin_trylock(&master_lock))
goto idle;
imx6q_set_lpm(WAIT_UNCLOCKED);
cpu_do_idle();
imx6q_set_lpm(WAIT_CLOCKED);
spin_unlock(&master_lock);
goto out;
}
idle:
cpu_do_idle();
out:
atomic_dec(&master);
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
return index;
}
For power gating case, it may better fit coupled cpuidle usage model,
since all the cores will have to run resume routine and thus will not
be in WFI when hardware exits from WAIT mode. But we still need to
work out the extra wakeup issue which will also be seen in this case.
> and then later you can optimize it to
> avoid the extra wakeups when the extension to coupled cpuidle that I
> discussed previously gets implemented.
Do you have a pointer to the initial discussion for the extension, or
you have a draft patch for that already (hopefully:)?
Shawn
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: Brian Norris @ 2012-10-15 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350307104.4115.23.camel@sauron.fi.intel.com>
On Mon, Oct 15, 2012 at 6:18 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> First thing which comes to mind is that in modern kernels memory
> fragmentation is not that big issue as it used to be. So may be
> kmalloc() the memory is not that bad nowadays? We have page migration,
> memory compaction, etc?
>
> I'd really prefer to just switch to kmalloc() everywhere instead of
> adding hacks like this to the drivers. Then if this is a problem for
> someone, he can fix it by either switching to smaller buffers (possible
> in many places), or by improving memory fragmentation issues on his
> system, or by just using CMA.
I think I can suggest that this is already a problem on real systems.
In bringing up a board on v3.3 kernel, I experienced a kernel memory
allocation error when trying to memdup_user() in eraseblock-size
regions. I believe I would experience more of these if all
eraseblock-sized buffers were kmalloc()'d.
See the commit description for the following commit in mtd-utils.git:
commit 71c76e74661492b4f68f670514866cfc85f47089
libmtd: fix mtd_write() issues for large data-only writes
> We can even have an mtd-wide funcion which will try kmalloc(), and if
> that fails, fall-back to CMA.
I would prefer not building a solution that hopes kmalloc() can get a
large contiguous buffer (remember, eraseblock sizes come as large as
2MB these days). A real solution like CMA or scatter-gather seems like
a better idea.
Brian
^ permalink raw reply
* [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
From: Al Viro @ 2012-10-15 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015160710.GC30907@arm.com>
On Mon, Oct 15, 2012 at 05:07:10PM +0100, Catalin Marinas wrote:
> On Sun, Oct 14, 2012 at 08:56:11PM +0100, Al Viro wrote:
> > On Sun, Oct 14, 2012 at 08:24:03PM +0100, Al Viro wrote:
> >
> > > Russell, could you recall what those had been about? I'm not sure if that
> > > had been oopsable that far back (again, oops scenario is userland stack
> > > page getting swapped out before we get to start_thread(), leading to
> > > direct read from an absent page in start_thread() by plain ldr, without
> > > anything in exception table about that insn), but it looks very odd
> > > regardless of that problem.
> >
> > BTW, arm64 has copied that logics, so it also seems to be unsafe and very
> > odd - there we definitely have only ELF to cope with. arm64 folks Cc'd...
>
> Good point. We don't need this on arm64 and probably neither on arm (at
> least since EABI).
>
> Setting x0 may cause other issues as well. The dynamic loader simply
> ignores the startup registers but for static binaries the _start code in
> glibc expects r0 to contain a function pointer to be registered with
> atexit() in __libc_start_main() or NULL. Since we pass argc in there,
> for static binaries the rtld_fini argument to __libc_start_main() is
> neither NULL nor something meaningful.
The value left there by start_thread() will not reach the userland anyway...
^ permalink raw reply
* [PATCH] ARM: SAMSUNG: Add naming of s3c64xx-spi devices
From: José Miguel Gonçalves @ 2012-10-15 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507C2492.8010408@samsung.com>
On 15-10-2012 15:58, Sylwester Nawrocki wrote:
> Hi Heiko,
>
> On 10/02/2012 02:43 PM, Heiko St?bner wrote:
>> Commit a5238e360b71 (spi: s3c64xx: move controller information into driver
>> data) introduced separate device names for the different subtypes of the
>> spi controller but forgot to set these in the relevant machines.
>>
>> To fix this introduce a s3c64xx_spi_setname function and populate all
>> Samsung arches with the correct names. The function resides in a new
>> header, as the s3c64xx-spi.h contains driver platform data and should
>> therefore at some later point move out of the Samsung include dir.
>>
>> Tested on a s3c2416-based machine.
>>
>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>> Cc: stable at vger.kernel.org
> This patch looks good to me. I've tested it on Exynos4412 SoC based
> board. And it fixes quite serious problem - broken SPI support on
> a all Samsung machs (non-dt) except s3c64xx in mainline v3.6 kernel.
>
>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> (mach-exynos only)
>
> Jos? Miguel, can you confirm it solves the problem for you ?
The driver initialization problem is solved by this patch on my S3C2416 based
board. Nevertheless, I didn?t have the time yet to test an actual SPI device
connected to the bus.
BTW, I think the two debug messages at the end of the s3c64xx_spi_probe() routine
should be promoted from dev_dbg to dev_info in order to be shown on a normal
kernel boot.
Best regards,
Jos? Gon?alves
^ permalink raw reply
* [PATCH 15/25] powerpc/fsl_msi: add a const qualifier
From: Tabi Timur-B04825 @ 2012-10-15 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1343034810-3386-16-git-send-email-u.kleine-koenig@pengutronix.de>
On Mon, Jul 23, 2012 at 4:13 AM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> This prepares *of_device_id.data becoming const. Without this change
> the following warning would occur:
>
> arch/powerpc/sysdev/fsl_msi.c: In function 'fsl_of_msi_probe':
> arch/powerpc/sysdev/fsl_msi.c:379:11: error: assignment discards 'const' qualifier from pointer target type [-Werror]
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH 1/2] mmc: core: Support all MMC capabilities when booting from Device Tree
From: Lee Jones @ 2012-10-15 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210151420.29930.arnd@arndb.de>
> On Monday 15 October 2012, Lee Jones wrote:
> > Capabilities are an important part of the MMC subsystem. Much
> > supported functionality would be lost if we didn't provide the
> > same level of support when booting Device Tree as we currently
> > do when the subsystem is passed capabilities via platform data.
> > This patch supplies this support with one simple call to a
> > DT parsing function.
>
> We already document all the commonly used properties
> in Documentation/devicetree/bindings/mmc/mmc.txt
<snip>
> and so on. What are you actually missing in the properties that
> are already there?
MMC_CAP_ERASE
MMC_CAP_UHS_SDR12
MMC_CAP_UHS_SDR25
MMC_CAP_UHS_DDR50
MMC_CAP_1_8V_DDR
MMC_CAP2_DETECT_ON_ERR
MMC_CAP2_NO_SLEEP_CMD
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
From: Catalin Marinas @ 2012-10-15 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121014195611.GA2616@ZenIV.linux.org.uk>
On Sun, Oct 14, 2012 at 08:56:11PM +0100, Al Viro wrote:
> On Sun, Oct 14, 2012 at 08:24:03PM +0100, Al Viro wrote:
>
> > Russell, could you recall what those had been about? I'm not sure if that
> > had been oopsable that far back (again, oops scenario is userland stack
> > page getting swapped out before we get to start_thread(), leading to
> > direct read from an absent page in start_thread() by plain ldr, without
> > anything in exception table about that insn), but it looks very odd
> > regardless of that problem.
>
> BTW, arm64 has copied that logics, so it also seems to be unsafe and very
> odd - there we definitely have only ELF to cope with. arm64 folks Cc'd...
Good point. We don't need this on arm64 and probably neither on arm (at
least since EABI).
Setting x0 may cause other issues as well. The dynamic loader simply
ignores the startup registers but for static binaries the _start code in
glibc expects r0 to contain a function pointer to be registered with
atexit() in __libc_start_main() or NULL. Since we pass argc in there,
for static binaries the rtld_fini argument to __libc_start_main() is
neither NULL nor something meaningful.
Russell, do you know whether setting these registers is needed for OABI?
--
Catalin
^ permalink raw reply
* [PATCH v2] i2c: i2c-gpio: fix name issue when i2c gpio node GT 1
From: Stephen Warren @ 2012-10-15 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350287477-30936-1-git-send-email-voice.shen@atmel.com>
On 10/15/2012 01:51 AM, Bo Shen wrote:
> When i2c-gpio node number is greater than 1, the name for each is same
> So add the patch to fix it.
>
> The adap->name printing information is add by myself
>
> without this patch the log information is as following
> ---<8---
> adap->name = i2c-gpio-1
> i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL)
> adap->name = i2c-gpio-1
> i2c-gpio i2c.3: using pins 64 (SDA) and 65 (SCL)
> --->8---
>
> with this patch, the log information is as following
> ---<8---
> adap->name = i2c.2
> i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL)
> adap->name = i2c.3
> i2c-gpio i2c.3: using pins 64 (SDA) and 65 (SCL)
> --->8---
I think this is reasonable, although I imagine this has zero effect on
the I2C bus number that's assigned to the device, so I'm not sure how it
interacts with or supports the other Atmel patch series you sent, which
I didn't really look at in much detail.
Reviewed-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* [PATCH 0/4] OMAP-GPMC generic timing migration
From: Tony Lindgren @ 2012-10-15 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93E9FCEC9@DBDE01.ent.ti.com>
* Mohammed, Afzal <afzal@ti.com> [121015 05:42]:
> Hi Tony,
>
> On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote:
> > * Mohammed, Afzal <afzal@ti.com> [121011 05:48]:
>
> > After -rc1 is out, let's plan on adding the minimal
> > set required for removing plat and mach includes from
> > drivers into a clean-up branch. Afzal, can you maybe
> > do a pull request for that set against -rc1 when it's
> > out? Just the minimal set of patches.
>
> Pull request on gpmc cleanup for common ARM zImage has
> been sent.
Thanks.
> > Yes, then please do a second pull request for what's needed
> > to apply the minimal DT bindings. For the DT binding, let's
> > just leave out the timings for now as we can load those from
> > auxdata. Then the binding for the timings can be added
> > later on. So just the minimal binding using standard features
> > for the iorange and interrupt.
>
> Ok, I will keep timings aside for now and proceed with DT
> (avoiding auxdata usage with generic routine looked to me a
> saner approach though, with an initial DT'fy delay)
Oh well if you think it's easier to do the timings too in
the DT binding, please go ahead with that. It may take some
longer discussion on the lists for the binding though. But
up to you.
Regards,
Tony
^ permalink raw reply
* [PATCH 7/7] ARM: tegra30: cpuidle: add LP2 driver for CPU0
From: Stephen Warren @ 2012-10-15 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350287799.23354.23.camel@jlo-ubuntu-64.nvidia.com>
On 10/15/2012 01:56 AM, Joseph Lo wrote:
> On Sat, 2012-10-13 at 05:04 +0800, Stephen Warren wrote:
>> On 10/12/2012 01:07 AM, Joseph Lo wrote:
>>> On Fri, 2012-10-12 at 00:37 +0800, Stephen Warren wrote:
>>>> On 10/11/2012 05:24 AM, Joseph Lo wrote:
>>>>> On Wed, 2012-10-10 at 06:49 +0800, Stephen Warren wrote:
>>>>>> On 10/08/2012 04:26 AM, Joseph Lo wrote:
>>>>>>> The cpuidle LP2 is a power gating idle mode. It support power gating
>>>>>>> vdd_cpu rail after all cpu cores in LP2. For Tegra30, the CPU0 must
>>>>>>> be last one to go into LP2. We need to take care and make sure whole
>>>>>>> secondary CPUs were in LP2 by checking CPU and power gate status.
>>>>>>> After that, the CPU0 can go into LP2 safely. Then power gating the
>>>>>>> CPU rail.
>>>>>>
>>>>>>> diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
>>>> b) If CPUn can't trigger rail-gating, then when CPUn is the last to
>>>> enter LP2 of the whole complex, it needs to IPI to CPU0 to tell it to
>>>> rail-gate, and simply power-gate itself. I believe this IPI interaction
>>>> is exactly what coupled cpuidle is about, isn't it?
>>>
>>> Yes, indeed. Actually, I had tried the coupled cpuidle on Tegra20. I
>>> knew it a lot. But I met issues when porting it. It looks like a race
>>> condition and becomes a dead lock caused by IPI missing. Anyway, we can
>>> talk about it more detail when I try to upstream the coupled cpuidle
>>> support for Tegra later.
>>
>> Hmm. That sounds a little churny. Why can't we just use coupled cpuidle
>> right from the start if the plan is to use it eventually anyway? From
>> other comments, it sounds like you even already have the code basically
>> working, but just need to iron out a bug or two?
>
> Stephen,
>
> Even though we have plan to use coupled cpuidle, I still prefer to go
> with the LP2 driver first. Then adding one more patch to support coupled
> cpuidle based on LP2 driver. This is good for history. And if there is
> any issue, it's more easy to roll back to the stable one.
I don't think that implementing it one way and then changing to a
different way will benefit history at all. It'll make the history more
complicated. What exactly is the problem with just using coupled cpuidle
from the start? If we did merge this implementation now, then switch to
coupled cpuidle later, when do you think the switch would happen?
> There is still one thing you should know. Because we are planning to
> upstream "CPUquiet" framework that is a CPU auto hotplug mechanism. It
> will auto hotplug the CPUs depends on the system is busy or not. So when
> system is idle, there will be only one CPU online (i.e, CPU0). The
> secondary CPUs will all be hot plugged (i.e, offline and power gate). We
> need to think about do we still need coupled cpuidle on Tegra30 if we
> are going to use "CPUquiet".
CPUquiet isn't relevant at all. First, a user may presumably disable
CPUquiet's Kconfig option (it had better have one, and the system had
better work with it disabled). Second, even if CPUquiet is enabled, I
don't imagine there is a 100% guarantee that hot(un)plug will happen
before cpuidle kicks in, is there? Finally, is there any guarantee that
CPUquiet will actually be accepted upstream?
^ permalink raw reply
* [PATCH] Boottime: A tool for automatic measurement of kernel/bootloader boot time
From: Dan Murphy @ 2012-10-15 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012164221.GN12567@gmail.com>
On 10/12/2012 11:42 AM, Lee Jones wrote:
> On Fri, 12 Oct 2012, Dan Murphy wrote:
>
>> On 10/12/2012 09:01 AM, Lee Jones wrote:
>>> On Fri, 12 Oct 2012, Arnd Bergmann wrote:
>>>
>>>> On Friday 12 October 2012, Russell King - ARM Linux wrote:
>>>>>> root at ME:/ cat /sys/kernel/debug/boottime/bootgraph
>>>>>> [ 0.185254] calling splash+0x0/0x0
>>>>>> [ 2.984335] initcall splash+0x0/0x0 returned 0 after 2799 msecs.
>>>>>> [ 2.984335] calling autoboot_delay+0x0/0x0
>>>>>> [ 4.089513] initcall autoboot_delay+0x0/0x0 returned 0 after 1105 msecs.
>>>>>> [ 4.089513] calling load_kernel+0x0/0x0
>>>>>> [ 4.239174] initcall load_kernel+0x0/0x0 returned 0 after 149 msecs.
>>>>>> [ 4.239174] calling boot_kernel+0x0/0x0
>>>>>> [ 4.276260] initcall boot_kernel+0x0/0x0 returned 0 after 37 msecs.
>>>>>> [ 4.276260] calling uncompress_ll_init+0x0/0x0
>>>>>> [ 4.276260] initcall uncompress_ll_init+0x0/0x0 returned 0 after 0 msecs.
>>>>>> [ 4.276260] Freeing init memory: 0K
>>>>> Umm, what happened to sysfs not becoming procfs v2? I thought we had
>>>>> a fairly strict requirement for "one value per file and not nicely
>>>>> formatted" for sysfs?
>>>>>
>>>> I was thinking the same thing at first, but then I noticed it's actually
>>>> debugfs, which has no such rules.
>>> Right. :)
>>>
>> OK I don't see when boottime_activate is called.
>>
>> Where would this call actually be made from?
>>
>> I see the call to deactivate but no call to activate.
> Here perhaps (Jonas, alerted me to the missing patch):
>
> commit 4c49a18bcfd2d041cbad7f41c6e6b39d90008382 (HEAD, refs/heads/dt-snowball-pre-rc1)
> Author: Jonas Aaberg<jonas.aberg@stericsson.com>
> Date: Wed Sep 14 09:29:20 2011 +0200
>
> drivers: clocksource: dbx500-prcmu: Add boottime support
>
> Change-Id: I9b5e3d050131c08c08786ae84cb76619c0525049
> Signed-off-by: Jonas Aaberg<jonas.aberg@stericsson.com>
> Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/32055
>
> diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c b/drivers/clocksource/clksrc-dbx500-prcmu.c
> index c26c369..0069cd9 100644
> --- a/drivers/clocksource/clksrc-dbx500-prcmu.c
> +++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
> @@ -14,6 +14,7 @@
> */
> #include<linux/clockchips.h>
> #include<linux/clksrc-dbx500-prcmu.h>
> +#include<linux/boottime.h>
>
> #include<asm/sched_clock.h>
>
> @@ -68,6 +69,23 @@ static u32 notrace dbx500_prcmu_sched_clock_read(void)
>
> #endif
>
> +#ifdef CONFIG_BOOTTIME
> +static unsigned long __init boottime_get_time(void)
> +{
> + return div_s64(clocksource_cyc2ns(clocksource_dbx500_prcmu.read(
> + &clocksource_dbx500_prcmu),
> + clocksource_dbx500_prcmu.mult,
> + clocksource_dbx500_prcmu.shift),
> + 1000);
> +}
> +
> +static struct boottime_timer __initdata boottime_timer = {
> + .init = NULL,
> + .get_time = boottime_get_time,
> + .finalize = NULL,
> +};
> +#endif
> +
> void __init clksrc_dbx500_prcmu_init(void __iomem *base)
> {
> clksrc_dbx500_timer_base = base;
> @@ -90,4 +108,6 @@ void __init clksrc_dbx500_prcmu_init(void __iomem *base)
> 32, RATE_32K);
> #endif
> clocksource_register_hz(&clocksource_dbx500_prcmu, RATE_32K);
> +
> + boottime_activate(&boottime_timer);
> }
>
OK So has this been validated and tested on any other IC then a ST part?
This boottime_activate patch seems to be only for the dbx500. If this
is supposed to be a generic solution I would expect
a generic patch for ARM to enable boot time activation.
Have you profiled how much time the boot time logging has added to the
over all boot?
Also the boottime commit message should explain a little more what it is
measuring.
i.e. This patch enables logging the boot time from point x to point y
for the kernel only. This does not include init.
What about adding the boot time from the init sequence to init complete?
^ permalink raw reply
* [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers
From: Karicheri, Muralidharan @ 2012-10-15 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5077F466.6020707@ti.com>
--Cut----
>> Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use
>> common clk drivers
>>
>> >>> You have chosen to keep all clock related data in platform files
>> >>> while using the common clock framework to provide just the
>> >>> infrastructure. If you look at how mxs and spear have been migrated, they have
>> migrated the soc specific clock data to drivers/clk as well.
>> >>> See "drivers/clk/spear/spear3xx_clock.c" or
>> >>> "drivers/clk/mxs/clk-imx23.c
>> >
>> > I have to disagree on this one. I had investigated these code already
>> > and came up with a way that we can re-use code across all of the
>> > davinci platforms as well as other architectures that re-uses the clk hardware IPs.
>>
>> Which code you are talking about here? Even if you introduce clk-dm644x.c, clk-
>> keystone.c etc in drivers/clk/davinci/ you can reuse the code you introduce in patches 1-
>> 3. I cant see how that will be prevented.
I was talking about re-use of davinci_common_clk_init in drivers/clk/davinci/davinci-clock.c.
This is meant to be re-used across all of the DaVinci devices.
>>
>> > spear3xx_clock.c has initialization code for each of the platforms and
>> > so is the case with imx23.c.
>>
>> By each of the platforms, you mean they all cater to a family of devices? This depends on
>> how close together the family of devices are.
>> Otherwise, there would be a file per soc. DM644x also represents a family for that matter.
>>
>> > By using platform_data approach, we are able to define clks for each of the SoC and
>> then use davinci_common_clk_init() to do initialize the clk drivers based on platform
>> data.
>>
>> You need to define and register the clocks present on each SoC either which way. I don't
>> see why just the platform_data approach allows this.
>> And looking closely, you have defined platform data, but don't actually have a platform
>> device, making things more confusing.
>>
Ok. There are multiple ways to implement this software. We had discussed this
internally and picked the platform_data approach. The clk drivers are written not
following the platform driver model. But I don't see why we can't use platform data
to configure this drivers. Down below, you have made two interesting points, one is
ARM code reduction. This patch already does this by moving the API that initializes
the clk drivers (davinci_common_clk_init()) out of ARM to drivers/clk/davinci. So
this + removal of existing clk driver under arm/mach-davinci/clock.[ch], we have
achieved this goal. The second point is the moving of SoC specific clk data out of SoC
code to drive. Are you 100% sure this is the right thing to do for these drivers. If so,
I can start working on this change right away. As I am working on this as a background
activity, I want to be double or triple sure before doing the rework of these patches :).
So please confirm.
>> > Later once we migrate to device tree, davinci_common_clk_init() will
>> > go way and also the clk structures defined in the SoC file. I have prototyped this on
>> one of the device that I am working on. davinci_common_clk_init() will be replaced with a
>> of_davinci_clk_init() that will use device tree to get all of the platform data for the clk
>> providers and do the initialization based on that. See highbank_clocks_init() in clk-
>> highbank.c. I have used this model for device tree based clk initialization.
>>
>> I don't think we should wait till DT migration to get rid of clock data from platform code.
>> For many of the older DaVinci platforms, DT migration is a big if and when. This approach
>> you gave above might work for newer DT-only platforms, but even if there is one board
>> that is not migrated to DT, the entire clock data will have to stay. I have very less hope
>> this will happen for DaVinci (at least in the near term). So, I would rather take the
>> opportunity of common clock tree migration to move clock data out of mach-davinci.
>>
>> Also, just moving soc-specific clk data to drivers/clk/davinci/* does not impede a future
>> DT conversion, no?
>>
>> > So it make sense to keep the design the way it is. Otherwise we will
>> > end up writing dm644x_clk_init(), dm355_clk_init(), etc for each of the platforms and
>> these code will get thrown away once we migrate to device tree.
>>
>> I still don't see why davinci/keystone cannot follow the same approach taken by multiple
>> other socs - spear, mxs and ux500. I am unconvinced that we have a significantly
>> different case.
>>
>> >>> ". I feel the
>> >>> latter way is better and I also think it will simplify some of the
>> >>> look-up infrastructure you had to build. This will also help some real code reduction
>> from arch/arm/mach-davinci/.
>> >>>
>> >
>> > The look-up infrastructure is pretty much re-use of the existing code base in SoC
>> specific file.
>>
>> Yes, but that's no reason to keep maintaining it.
>>
>> > About code reduction, I can't say I agree, as we need to add platform_specific clock
>> initialization code if we follow spear3xx_clock.c model and end up probably adding more
>> code.
>> > SoC specific file (for example dm644x.c) has only data structures and all of SoC will re-
>> use davinci_common_clk_init() to do the initialization. So I am not sure how you conclude
>> we will have code reduction?
>>
>> Is about code reduction from arch/arm/. That's what ARM community is working towards.
>>
>> Thanks,
>> Sekhar
>>
>> PS: When replying, can you please hit an enter after every 70 or so characters.
>> Otherwise quoting from your mails is becoming very difficult. I tried manually adjusting it
>> but finally gave up.
^ permalink raw reply
* [PATCH 4/4] ARM: kirkwood: DT board setup for Network Space Mini v2
From: Simon Guinot @ 2012-10-15 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350315295-14567-1-git-send-email-simon.guinot@sequanux.org>
This patch adds DT board setup for the LaCie NAS Network Space Mini v2
(aka SafeBox). The hardware characteristics are very close to those of
the Network Space Lite v2. The main difference are:
- A GPIO fan which is only available on the NS2 Mini.
- A single USB host port is wired on the NS2 Mini. The NS2 Lite provides
an additional dual-mode USB port (host/device).
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/kirkwood-ns2mini.dts | 49 ++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 8 ++++++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/board-dt.c | 4 ++-
arch/arm/mach-kirkwood/board-ns2.c | 3 +-
arch/arm/mach-kirkwood/common.h | 3 +-
drivers/leds/Kconfig | 2 +-
8 files changed, 67 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/kirkwood-ns2mini.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 42b3e90..f2af858 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
kirkwood-ns2.dtb \
kirkwood-ns2lite.dtb \
kirkwood-ns2max.dtb \
+ kirkwood-ns2mini.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-ns2mini.dts b/arch/arm/boot/dts/kirkwood-ns2mini.dts
new file mode 100644
index 0000000..b58fd3d
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2mini.dts
@@ -0,0 +1,49 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Network Space Mini v2";
+ compatible = "lacie,netspace_mini_v2", "marvell,kirkwood-88f6192", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x8000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
+ };
+
+ gpio_fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio0 22 1
+ &gpio0 7 1
+ &gpio1 1 1
+ &gpio0 23 1>;
+ gpio-fan,speed-map =
+ < 0 0
+ 3000 15
+ 3180 14
+ 4140 13
+ 4570 12
+ 6760 11
+ 7140 10
+ 7980 9
+ 9200 8>;
+ alarm-gpios = <&gpio0 25 1>;
+ };
+
+ ns2-leds {
+ compatible = "ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 83df331..757bdb3 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -158,6 +158,14 @@ config MACH_NETSPACE_LITE_V2_DT
Say 'Y' here if you want your kernel to support the LaCie
Network Space Lite v2 NAS, using Flattened Device Tree.
+config MACH_NETSPACE_MINI_V2_DT
+ bool "LaCie Network Space Mini v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Network Space Mini v2 NAS (aka SafeBox), using Flattened
+ Device Tree.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 4d4b7d4..3ff4aa1 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_MACH_INETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT) += board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_MINI_V2_DT) += board-ns2.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index ab7595e..c3dd5d2 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -99,7 +99,8 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("lacie,inetspace_v2") ||
of_machine_is_compatible("lacie,netspace_v2") ||
of_machine_is_compatible("lacie,netspace_max_v2") ||
- of_machine_is_compatible("lacie,netspace_lite_v2"))
+ of_machine_is_compatible("lacie,netspace_lite_v2") ||
+ of_machine_is_compatible("lacie,netspace_mini_v2"))
ns2_init();
of_platform_populate(NULL, kirkwood_dt_match_table,
@@ -122,6 +123,7 @@ static const char *kirkwood_dt_board_compat[] = {
"lacie,netspace_max_v2",
"lacie,netspace_v2",
"lacie,netspace_lite_v2",
+ "lacie,netspace_mini_v2",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
index da8c4c5..78596c4 100644
--- a/arch/arm/mach-kirkwood/board-ns2.c
+++ b/arch/arm/mach-kirkwood/board-ns2.c
@@ -74,7 +74,8 @@ void __init ns2_init(void)
kirkwood_mpp_conf(ns2_mpp_config);
kirkwood_ehci_init();
- if (of_machine_is_compatible("lacie,netspace_lite_v2"))
+ if (of_machine_is_compatible("lacie,netspace_lite_v2") ||
+ of_machine_is_compatible("lacie,netspace_mini_v2"))
ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
kirkwood_ge00_init(&ns2_ge00_data);
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 6949d81..95eb69b 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -115,7 +115,8 @@ static inline void km_kirkwood_init(void) {};
#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
defined(CONFIG_MACH_NETSPACE_V2_DT) || \
defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
- defined(CONFIG_MACH_NETSPACE_LITE_V2_DT)
+ defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
+ defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
void ns2_init(void);
#else
static inline void ns2_init(void) {};
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index e455c08..b58bc8a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -381,7 +381,7 @@ config LEDS_NS2
depends on MACH_NETSPACE_V2 || MACH_INETSPACE_V2 || \
MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2 || \
MACH_NETSPACE_V2_DT || MACH_INETSPACE_V2_DT || \
- MACH_NETSPACE_MAX_V2_DT
+ MACH_NETSPACE_MAX_V2_DT || MACH_NETSPACE_MINI_V2_DT
default y
help
This option enable support for the dual-GPIO LED found on the
--
1.7.10
^ permalink raw reply related
* [PATCH 3/4] ARM: kirkwood: DT board setup for Network Space Lite v2
From: Simon Guinot @ 2012-10-15 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350315295-14567-1-git-send-email-simon.guinot@sequanux.org>
This patch adds DT board setup for the LaCie NAS Network Space Lite v2.
This board is derived from the Network Space v2 and a lot of hardware
characteristics are shared.
- CPU: Marvell 88F6192 800Mhz
- SDRAM memory: 128MB DDR2 200Mhz
- 1 SATA port: internal
- Gigabit ethernet: PHY Marvell 88E1318
- Flash memory: SPI NOR 512KB (Macronix MX25L4005A)
- i2c EEPROM: 512 bytes (24C04 type)
- 2 USB2 ports: host and host/device
- 1 push button
- 1 SATA LED (bi-color, blue and red)
Note that the SATA LED is not compatible with the driver leds-ns2. The
LED behaviour ("on", "off" or "SATA activity blink") is controlled via
a single MPP (21).
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/kirkwood-ns2lite.dts | 30 ++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 7 +++++++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/board-dt.c | 4 +++-
arch/arm/mach-kirkwood/board-ns2.c | 3 +++
arch/arm/mach-kirkwood/common.h | 3 ++-
7 files changed, 47 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/kirkwood-ns2lite.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6201b6..42b3e90 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
kirkwood-lschlv2.dtb \
kirkwood-lsxhl.dtb \
kirkwood-ns2.dtb \
+ kirkwood-ns2lite.dtb \
kirkwood-ns2max.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb
diff --git a/arch/arm/boot/dts/kirkwood-ns2lite.dts b/arch/arm/boot/dts/kirkwood-ns2lite.dts
new file mode 100644
index 0000000..b02eb4e
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2lite.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Network Space Lite v2";
+ compatible = "lacie,netspace_lite_v2", "marvell,kirkwood-88f6192", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x8000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ gpios = <&gpio0 30 1>;
+ linux,default-trigger = "default-on";
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 847e0c2..83df331 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -151,6 +151,13 @@ config MACH_NETSPACE_MAX_V2_DT
Say 'Y' here if you want your kernel to support the LaCie
Network Space Max v2 NAS, using Flattened Device Tree.
+config MACH_NETSPACE_LITE_V2_DT
+ bool "LaCie Network Space Lite v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Network Space Lite v2 NAS, using Flattened Device Tree.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 1f63d80..4d4b7d4 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_MACH_KM_KIRKWOOD_DT) += board-km_kirkwood.o
obj-$(CONFIG_MACH_INETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT) += board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT) += board-ns2.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index b3e0519..ab7595e 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -98,7 +98,8 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("lacie,inetspace_v2") ||
of_machine_is_compatible("lacie,netspace_v2") ||
- of_machine_is_compatible("lacie,netspace_max_v2"))
+ of_machine_is_compatible("lacie,netspace_max_v2") ||
+ of_machine_is_compatible("lacie,netspace_lite_v2"))
ns2_init();
of_platform_populate(NULL, kirkwood_dt_match_table,
@@ -120,6 +121,7 @@ static const char *kirkwood_dt_board_compat[] = {
"lacie,inetspace_v2",
"lacie,netspace_max_v2",
"lacie,netspace_v2",
+ "lacie,netspace_lite_v2",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
index b36c55c..da8c4c5 100644
--- a/arch/arm/mach-kirkwood/board-ns2.c
+++ b/arch/arm/mach-kirkwood/board-ns2.c
@@ -16,6 +16,7 @@
#include <linux/platform_device.h>
#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
+#include <linux/of.h>
#include "common.h"
#include "mpp.h"
@@ -73,6 +74,8 @@ void __init ns2_init(void)
kirkwood_mpp_conf(ns2_mpp_config);
kirkwood_ehci_init();
+ if (of_machine_is_compatible("lacie,netspace_lite_v2"))
+ ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
kirkwood_ge00_init(&ns2_ge00_data);
if (gpio_request(NS2_GPIO_POWER_OFF, "power-off") == 0 &&
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 2f75f3f..6949d81 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -114,7 +114,8 @@ static inline void km_kirkwood_init(void) {};
#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
defined(CONFIG_MACH_NETSPACE_V2_DT) || \
- defined(CONFIG_MACH_NETSPACE_MAX_V2_DT)
+ defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
+ defined(CONFIG_MACH_NETSPACE_LITE_V2_DT)
void ns2_init(void);
#else
static inline void ns2_init(void) {};
--
1.7.10
^ 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