* [PATCH 4/4] ARM: dts: cm-fx6: add support for USB host port 1
From: Igor Grinberg @ 2014-01-21 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390320812-25100-1-git-send-email-grinberg@compulab.co.il>
Setup pin control, vbus regulator and the usb host port 1 node
to enable the USB host port 1 support.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
arch/arm/boot/dts/imx6q-cm-fx6.dts | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index 039a155..cf4c186 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -46,6 +46,16 @@
gpio = <&gpio3 22 0>;
enable-active-high;
};
+
+ reg_usb_h1_vbus: regulator at 1 {
+ compatible = "regulator-fixed";
+ reg = <1>;
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio7 8 0>;
+ enable-active-high;
+ };
};
};
@@ -66,6 +76,12 @@
pinctrl_usbotg: usbotggrp {
fsl,pins = <MX6QDL_USBOTG_PINGRP2>;
};
+
+ pinctrl_usbh1: usbh1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x80000000
+ >;
+ };
};
};
@@ -99,3 +115,10 @@
dr_mode = "otg";
status = "okay";
};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1>;
+ status = "okay";
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 08/15] watchdog: orion: Introduce per-compatible of_device_id data
From: Guenter Roeck @ 2014-01-21 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390310774-20781-9-git-send-email-ezequiel.garcia@free-electrons.com>
On Tue, Jan 21, 2014 at 10:26:07AM -0300, Ezequiel Garcia wrote:
> This commit adds an orion_watchdog_data structure to holda compatible-data
s/holda/hold/
> information. This allows to remove the driver-wide definition and to
> future add support for multiple compatible-strings.
Maybe "and to be able to add support for multiple compatible-strings in the
future" ?
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> drivers/watchdog/orion_wdt.c | 62 ++++++++++++++++++++++++++++++++------------
> 1 file changed, 46 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
> index 9a904be..5108496 100644
> --- a/drivers/watchdog/orion_wdt.c
> +++ b/drivers/watchdog/orion_wdt.c
> @@ -24,36 +24,47 @@
> #include <linux/clk.h>
> #include <linux/err.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
>
> /*
> * Watchdog timer block registers.
> */
> #define TIMER_CTRL 0x0000
> -#define WDT_EN 0x0010
> -#define WDT_VAL 0x0024
>
> #define WDT_MAX_CYCLE_COUNT 0xffffffff
> #define WDT_IN_USE 0
> #define WDT_OK_TO_CLOSE 1
>
While looking at the new defines below, I noticed that WDT_IN_USE and
WDT_OK_TO_CLOSE are not used (anymore ?) and thus should be removed
(separate patch, though).
> -#define WDT_RESET_OUT_EN BIT(1)
> +#define WDT_A370_RATIO_MASK(v) ((v) << 16)
> +#define WDT_A370_RATIO_SHIFT 5
> +#define WDT_A370_RATIO (1 << WDT_A370_RATIO_SHIFT)
> +
> +#define WDT_AXP_FIXED_ENABLE_BIT BIT(10)
>
Those new defines are not used. They should be introduced if and when used.
> static bool nowayout = WATCHDOG_NOWAYOUT;
> static int heartbeat = -1; /* module parameter (seconds) */
>
> +struct orion_watchdog_data {
> + int wdt_counter_offset;
> + int wdt_enable_bit;
> + int rstout_enable_bit;
> +};
> +
> struct orion_watchdog {
> struct watchdog_device wdt;
> void __iomem *reg;
> void __iomem *rstout;
> unsigned long clk_rate;
> struct clk *clk;
> + struct orion_watchdog_data *data;
> };
>
> static int orion_wdt_ping(struct watchdog_device *wdt_dev)
> {
> struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
> /* Reload watchdog duration */
> - writel(dev->clk_rate * wdt_dev->timeout, dev->reg + WDT_VAL);
> + writel(dev->clk_rate * wdt_dev->timeout,
> + dev->reg + dev->data->wdt_counter_offset);
> return 0;
> }
>
> @@ -62,13 +73,16 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
> struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
>
> /* Set watchdog duration */
> - writel(dev->clk_rate * wdt_dev->timeout, dev->reg + WDT_VAL);
> + writel(dev->clk_rate * wdt_dev->timeout,
> + dev->reg + dev->data->wdt_counter_offset);
>
> /* Enable watchdog timer */
> - atomic_io_modify(dev->reg + TIMER_CTRL, WDT_EN, WDT_EN);
> + atomic_io_modify(dev->reg + TIMER_CTRL, dev->data->wdt_enable_bit,
> + dev->data->wdt_enable_bit);
>
> /* Enable reset on watchdog */
> - atomic_io_modify(dev->rstout, WDT_RESET_OUT_EN, WDT_RESET_OUT_EN);
> + atomic_io_modify(dev->rstout, dev->data->rstout_enable_bit,
> + dev->data->rstout_enable_bit);
>
> return 0;
> }
> @@ -78,10 +92,10 @@ static int orion_wdt_stop(struct watchdog_device *wdt_dev)
> struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
>
> /* Disable reset on watchdog */
> - atomic_io_modify(dev->rstout, WDT_RESET_OUT_EN, 0);
> + atomic_io_modify(dev->rstout, dev->data->rstout_enable_bit, 0);
>
> /* Disable watchdog timer */
> - atomic_io_modify(dev->reg + TIMER_CTRL, WDT_EN, 0);
> + atomic_io_modify(dev->reg + TIMER_CTRL, dev->data->wdt_enable_bit, 0);
>
> return 0;
> }
> @@ -89,7 +103,7 @@ static int orion_wdt_stop(struct watchdog_device *wdt_dev)
> static unsigned int orion_wdt_get_timeleft(struct watchdog_device *wdt_dev)
> {
> struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
> - return readl(dev->reg + WDT_VAL) / dev->clk_rate;
> + return readl(dev->reg + dev->data->wdt_counter_offset) / dev->clk_rate;
> }
>
> static int orion_wdt_set_timeout(struct watchdog_device *wdt_dev,
> @@ -119,9 +133,25 @@ static irqreturn_t orion_wdt_irq(int irq, void *devid)
> return IRQ_HANDLED;
> }
>
> +static const struct orion_watchdog_data orion_data = {
> + .rstout_enable_bit = BIT(1),
> + .wdt_enable_bit = BIT(4),
> + .wdt_counter_offset = 0x24,
> +};
> +
> +static const struct of_device_id orion_wdt_of_match_table[] = {
> + {
> + .compatible = "marvell,orion-wdt",
> + .data = &orion_data,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, orion_wdt_of_match_table);
> +
> static int orion_wdt_probe(struct platform_device *pdev)
> {
> struct orion_watchdog *dev;
> + const struct of_device_id *match;
> unsigned int wdt_max_duration; /* (seconds) */
> struct resource *res;
> int ret, irq;
> @@ -131,9 +161,15 @@ static int orion_wdt_probe(struct platform_device *pdev)
> if (!dev)
> return -ENOMEM;
>
> + match = of_match_device(orion_wdt_of_match_table, &pdev->dev);
> + if (!match)
> + /* Default legacy match */
> + match = &orion_wdt_of_match_table[0];
> +
> dev->wdt.info = &orion_wdt_info;
> dev->wdt.ops = &orion_wdt_ops;
> dev->wdt.min_timeout = 1;
> + dev->data = (struct orion_watchdog_data *)match->data;
match->data is a void *, so the typecast should not be needed here.
You might want to declare 'data' to be of type
'const struct orion_watchdog_data *' because otherwise you loose the
'const' attribute of match->data (which may be the reason for the typecast ?).
Guenter
^ permalink raw reply
* [PATCH 1/2] ohci-platform: Add support for controllers with big-endian regs / descriptors
From: Alan Stern @ 2014-01-21 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390319315-8391-1-git-send-email-hdegoede@redhat.com>
On Tue, 21 Jan 2014, Hans de Goede wrote:
> Note this commit uses the same devicetree booleans for this as the ones
> already existing in the usb-ehci bindings.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -512,6 +512,10 @@ config USB_CNS3XXX_OHCI
>
> config USB_OHCI_HCD_PLATFORM
> tristate "Generic OHCI driver for a platform device"
> + # Always support LE, support BE on architectures which have readl_be
> + select USB_OHCI_LITTLE_ENDIAN
> + select USB_OHCI_BIG_ENDIAN_DESC if (AVR32 || MIPS || MICROBLAZE || SPARC || PPC32 || PPC64)
> + select USB_OHCI_BIG_ENDIAN_MMIO if (AVR32 || MIPS || MICROBLAZE || SPARC || PPC32 || PPC64)
> default n
The comment line above is slightly misleading. USB_OHCI_LITTLE_ENDIAN
doesn't exactly mean to include support for little-endian controllers;
it means include mixed-endian support if either
USB_OHCI_BIG_ENDIAN_DESC or USB_OHCI_BIG_ENDIAN_MMIO is set. That is,
the driver determines at runtime whether a particular controller is
big-endian or little-endian, rather than choosing to support one or the
other at compile time.
In any case, the style we have adopted is that these select lines go in
the arch-specific defconfig, not here. For example, check out the
occurrences of EHCI in arch/mips/Kconfig. Also, I'm not sure how you
came up with that list of architectures for the two selects; it's hard
to say if they are right. For instance, why did you include AVR32?
The changes to the driver itself look fine.
Similar comments apply to the ehci-platform patch.
Alan Stern
^ permalink raw reply
* [PATCH v3 11/15] watchdog: orion: Add support for Armada 370 and Armada XP SoC
From: Guenter Roeck @ 2014-01-21 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390310774-20781-12-git-send-email-ezequiel.garcia@free-electrons.com>
On Tue, Jan 21, 2014 at 10:26:10AM -0300, Ezequiel Garcia wrote:
> Using the added infrastructure for handling SoC differences,
> this commit adds support for the watchdog controller available
> in Armada 370 and Armada XP SoCs.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> drivers/watchdog/orion_wdt.c | 93 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
> index c2beb9f..a5e157c 100644
> --- a/drivers/watchdog/orion_wdt.c
> +++ b/drivers/watchdog/orion_wdt.c
> @@ -30,6 +30,7 @@
> * Watchdog timer block registers.
> */
> #define TIMER_CTRL 0x0000
> +#define TIMER_A370_STATUS 0x04
>
> #define WDT_MAX_CYCLE_COUNT 0xffffffff
> #define WDT_IN_USE 0
> @@ -41,6 +42,12 @@
>
> #define WDT_AXP_FIXED_ENABLE_BIT BIT(10)
>
> +#define WDT_A370_RATIO_MASK(v) ((v) << 16)
> +#define WDT_A370_RATIO_SHIFT 5
> +#define WDT_A370_RATIO (1 << WDT_A370_RATIO_SHIFT)
> +
Are those introduced twice ? I seem to recall seeing those defines in patch 8.
> +#define WDT_A370_EXPIRED BIT(31)
> +
> static bool nowayout = WATCHDOG_NOWAYOUT;
> static int heartbeat = -1; /* module parameter (seconds) */
>
> @@ -80,6 +87,48 @@ static int orion_wdt_clock_init(struct platform_device *pdev,
> return 0;
> }
>
> +static int armada370_wdt_clock_init(struct platform_device *pdev,
> + struct orion_watchdog *dev)
> +{
> + int ret;
> +
> + dev->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(dev->clk))
> + return PTR_ERR(dev->clk);
> + ret = clk_prepare_enable(dev->clk);
> + if (ret)
> + return ret;
> +
> + /* Setup watchdog input clock */
> + atomic_io_modify(dev->reg + TIMER_CTRL,
> + WDT_A370_RATIO_MASK(WDT_A370_RATIO_SHIFT),
> + WDT_A370_RATIO_MASK(WDT_A370_RATIO_SHIFT));
> +
> + dev->clk_rate = clk_get_rate(dev->clk) / WDT_A370_RATIO;
> + return 0;
> +}
> +
> +static int armadaxp_wdt_clock_init(struct platform_device *pdev,
> + struct orion_watchdog *dev)
> +{
> + int ret;
> +
> + dev->clk = of_clk_get_by_name(pdev->dev.of_node, "fixed");
> + if (IS_ERR(dev->clk))
> + return PTR_ERR(dev->clk);
> + ret = clk_prepare_enable(dev->clk);
> + if (ret)
> + return ret;
> +
> + /* Enable the fixed watchdog clock input */
> + atomic_io_modify(dev->reg + TIMER_CTRL,
> + WDT_AXP_FIXED_ENABLE_BIT,
> + WDT_AXP_FIXED_ENABLE_BIT);
Who am I to complain, but your continuation line indentation isn't really
consistent ;-).
> +
> + dev->clk_rate = clk_get_rate(dev->clk);
> + return 0;
> +}
> +
> static int orion_wdt_ping(struct watchdog_device *wdt_dev)
> {
> struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
> @@ -89,6 +138,26 @@ static int orion_wdt_ping(struct watchdog_device *wdt_dev)
> return 0;
> }
>
> +static int armada370_start(struct watchdog_device *wdt_dev)
> +{
> + struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
> +
> + /* Set watchdog duration */
> + writel(dev->clk_rate * wdt_dev->timeout,
> + dev->reg + dev->data->wdt_counter_offset);
> +
> + /* Clear the watchdog expiration bit */
> + atomic_io_modify(dev->reg + TIMER_A370_STATUS, WDT_A370_EXPIRED, 0);
> +
> + /* Enable watchdog timer */
> + atomic_io_modify(dev->reg + TIMER_CTRL, dev->data->wdt_enable_bit,
> + dev->data->wdt_enable_bit);
> +
> + atomic_io_modify(dev->rstout, dev->data->rstout_enable_bit,
> + dev->data->rstout_enable_bit);
> + return 0;
> +}
> +
> static int orion_start(struct watchdog_device *wdt_dev)
> {
> struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
> @@ -170,11 +239,35 @@ static const struct orion_watchdog_data orion_data = {
> .start = orion_start,
> };
>
> +static const struct orion_watchdog_data armada370_data = {
> + .rstout_enable_bit = BIT(8),
> + .wdt_enable_bit = BIT(8),
> + .wdt_counter_offset = 0x34,
> + .clock_init = armada370_wdt_clock_init,
> + .start = armada370_start,
> +};
> +
> +static const struct orion_watchdog_data armadaxp_data = {
> + .rstout_enable_bit = BIT(8),
> + .wdt_enable_bit = BIT(8),
> + .wdt_counter_offset = 0x34,
> + .clock_init = armadaxp_wdt_clock_init,
> + .start = armada370_start,
> +};
> +
> static const struct of_device_id orion_wdt_of_match_table[] = {
> {
> .compatible = "marvell,orion-wdt",
> .data = &orion_data,
> },
> + {
> + .compatible = "marvell,armada-370-wdt",
> + .data = &armada370_data,
> + },
> + {
> + .compatible = "marvell,armada-xp-wdt",
> + .data = &armadaxp_data,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, orion_wdt_of_match_table);
> --
> 1.8.1.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v4 15/16] ARM: add uprobes support
From: David Long @ 2014-01-21 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387564464.3404.106.camel@linaro1.home>
On 12/20/13 13:34, Jon Medhurst (Tixy) wrote:
> On Sun, 2013-12-15 at 23:08 -0500, David Long wrote:
>> From: "David A. Long" <dave.long@linaro.org>
>>
>> Using Rabin Vincent's ARM uprobes patches as a base, enable uprobes
>> support on ARM.
>>
>> Caveats:
>>
>> - Thumb is not supported
>> - XOL abort/trap handling is not implemented
>
> I shall repeat my comment from version one of the patch...
>
> What are the consequences of this, e.g. is it possible for a probe to
> get stuck in an infinite loop of faulting? I hope there are no integrity
> issues for the kernel itself.
>
> Would be good if someone familiar with uprobes working could answer
> that.
Testing shows it does indeed get stuck continuously trapping. The
process is killable. Fortunately all the infrastructure is already
there for fixing this. I've patched the code to detect the trap and
allow it to be processed, using the powerpc uprobes code as a model.
The changes required are fairly small and entirely in the
architecture-specific code.
As mentioned before, thumb support is a follow-on project.
> I've a few other comments...
[snip]
>
>
>> +const union decode_item uprobes_probes_actions[] = {
>> + [PROBES_EMULATE_NONE] {.handler = probes_simulate_nop},
>
> There is a missing '=' in the line above. Interesting that GCC doesn't
> complain (I tried compiling this patch and it didn't).
>
That is indeed odd. I have fixed it (my code, not the compiler).
[snip]
>> +bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe, struct pt_regs *regs)
>> +{
>> + void *addr;
>
> 'addr' is not used so this line can be deleted
>
>> + probes_opcode_t opcode;
>> +
>> + if (!auprobe->simulate)
>> + return false;
>> +
>> + addr = (void *) regs->ARM_pc;
>
> and so can this line ^^^
Fixed.
>
>> + opcode = __mem_to_opcode_arm(*(unsigned int *) auprobe->insn);
>> +
>> + auprobe->asi.insn_singlestep(opcode, &auprobe->asi, regs);
>> +
>> + return true;
>> +}
>> +
>
Fixed.
> [rest of patch snipped]
>
-dl
^ permalink raw reply
* [PATCH 1/2] ohci-platform: Add support for controllers with big-endian regs / descriptors
From: Hans de Goede @ 2014-01-21 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1401211116370.1272-100000@iolanthe.rowland.org>
Hi,
On 01/21/2014 05:40 PM, Alan Stern wrote:
> On Tue, 21 Jan 2014, Hans de Goede wrote:
>
>> Note this commit uses the same devicetree booleans for this as the ones
>> already existing in the usb-ehci bindings.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -512,6 +512,10 @@ config USB_CNS3XXX_OHCI
>>
>> config USB_OHCI_HCD_PLATFORM
>> tristate "Generic OHCI driver for a platform device"
>> + # Always support LE, support BE on architectures which have readl_be
>> + select USB_OHCI_LITTLE_ENDIAN
>> + select USB_OHCI_BIG_ENDIAN_DESC if (AVR32 || MIPS || MICROBLAZE || SPARC || PPC32 || PPC64)
>> + select USB_OHCI_BIG_ENDIAN_MMIO if (AVR32 || MIPS || MICROBLAZE || SPARC || PPC32 || PPC64)
>> default n
>
> The comment line above is slightly misleading. USB_OHCI_LITTLE_ENDIAN
> doesn't exactly mean to include support for little-endian controllers;
> it means include mixed-endian support if either
> USB_OHCI_BIG_ENDIAN_DESC or USB_OHCI_BIG_ENDIAN_MMIO is set. That is,
> the driver determines at runtime whether a particular controller is
> big-endian or little-endian, rather than choosing to support one or the
> other at compile time.
Right I already knew that, that is what the "Always" tried to summarize.
> In any case, the style we have adopted is that these select lines go in
> the arch-specific defconfig, not here.
Ok, so I should drop the Kconfig parts of both patches ?
> For example, check out the
> occurrences of EHCI in arch/mips/Kconfig. Also, I'm not sure how you
> came up with that list of architectures for the two selects; it's hard
> to say if they are right. For instance, why did you include AVR32?
I included all archs which defines readl_be in asm/io.h
Regards,
Hans
^ permalink raw reply
* [PATCH v7 1/2] ohci-platform: Add support for devicetree instantiation
From: Hans de Goede @ 2014-01-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DEB57C.8080700@cogentembedded.com>
Hi,
On 01/21/2014 06:59 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 01/15/2014 10:24 PM, Hans de Goede wrote:
>
>> Add support for ohci-platform instantiation from devicetree, including
>> optionally getting clks and a phy from devicetree, and enabling / disabling
>> those on power_on / off.
>
>> This should allow using ohci-platform from devicetree in various cases.
>> Specifically after this commit it can be used for the ohci controller found
>> on Allwinner sunxi SoCs.
>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> Acked-by: Alan Stern <stern@rowland.harvard.edu>
> [...]
>
> Have only found time to fully read the patches just now...
>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt
>> new file mode 100644
>> index 0000000..f9d6c73
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
>> @@ -0,0 +1,22 @@
>> +USB OHCI controllers
>> +
>> +Required properties:
>> +- compatible : "usb-ohci"
>> +- reg : ohci controller register range (address and length)
>> +- interrupts : ohci controller interrupt
>> +
>> +Optional properties:
>> +- clocks : a list of phandle + clock specifier pairs
>> +- phys : phandle + phy specifier pair
>> +- phy-names : "usb"
>> +
>> +Example:
>> +
>> + ohci0: ohci at 0x01c14400 {
>
> Two minor nits: there should be no "0x" in the address part of the node name. And according to ePAPR [1], "the name of a node should be somewhat generic, reflecting the function of the device and not its precise programming model. If appropriate, the name should be one of the following choices:
> [...]
> - usb".
>
> Same comments for "usb-ehci" binding.
You're right on both accounts, I'll do a v8 tomorrow, including a re-spin of the
big-endian patches.
Regards,
Hans
^ permalink raw reply
* [PATCH 1/4 v3] mfd: tc3589x: Add device tree bindings
From: Lee Jones @ 2014-01-21 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZoEwgRALT0R8vWB1aWxR_WCR2U0b1yF0Mr0qNm0LDGug@mail.gmail.com>
> > This defines the device tree bindings for the Toshiba TC3589x
> > series of multi-purpose expanders. Only the stuff I can test
> > is defined: GPIO and keypad. Others may implement more
> > subdevices further down the road.
> >
> > This is to complement
> > commit a435ae1d51e2f18414f2a87219fdbe068231e692
> > "mfd: Enable the tc3589x for Device Tree" which left off
> > the definition of the device tree bindings.
> >
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > ChangeLog v2->v3:
> > - Fix the keys/rows bindings to be u32 rather than
> > /bits/ 8, inconsistency noted by Mark Rutland.
> > ChangeLog v1->v2:
> > - Include a verbose example in the DT bindings.
> > - Explain why this is a stand-alone bindings patch.
>
> So will this since Nov 12 uncommented-upon patch be merged or
> do you want me to do some change?
>
> There was some back-and-forth regarding the (existing, already
> in use) linux-specific input bindings but the only thing I can
> see is some back and forth leaning toward just letting these
> be used.
We still need a DT Ack.
> I am happy to change this in whatever way but no directions
> for two months....
If it had slipped though the gaps, I'd probably suggest poking or
re-sending before the middle of the merge-window though.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v6 00/10] USB Host support for OMAP5 uEVM (for 3.14)
From: Lee Jones @ 2014-01-21 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
> This patchset brings up USB Host ports and Ethernet port on
> the OMAP5 uEVM board.
I'd keep hold of this and send it out again when the merge-window is
closed.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Laura Abbott @ 2014-01-21 17:26 UTC (permalink / raw)
To: linux-arm-kernel
arm64 currently lacks support for -fstack-protector. Add
similar functionality to arm to detect stack corruption.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
---
arch/arm64/Kconfig | 12 +++++++++
arch/arm64/Makefile | 4 +++
arch/arm64/include/asm/stackprotector.h | 38 +++++++++++++++++++++++++++++++
arch/arm64/kernel/process.c | 9 +++++++
4 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 arch/arm64/include/asm/stackprotector.h
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d4dd22..4f86874 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -168,6 +168,18 @@ config HOTPLUG_CPU
Say Y here to experiment with turning CPUs off and on. CPUs
can be controlled through /sys/devices/system/cpu.
+config CC_STACKPROTECTOR
+ bool "Enable -fstack-protector buffer overflow detection"
+ help
+ This option turns on the -fstack-protector GCC feature. This
+ feature puts, at the beginning of functions, a canary value on
+ the stack just before the return address, and validates
+ the value just before actually returning. Stack based buffer
+ overflows (that need to overwrite this return address) now also
+ overwrite the canary, which gets detected and the attack is then
+ neutralized via a kernel panic.
+ This feature requires gcc version 4.2 or above.
+
source kernel/Kconfig.preempt
config HZ
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 2fceb71..1ce221e 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -48,6 +48,10 @@ core-$(CONFIG_XEN) += arch/arm64/xen/
libs-y := arch/arm64/lib/ $(libs-y)
libs-y += $(LIBGCC)
+ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
+KBUILD_CFLAGS +=-fstack-protector
+endif
+
# Default target when executing plain make
KBUILD_IMAGE := Image.gz
KBUILD_DTBS := dtbs
diff --git a/arch/arm64/include/asm/stackprotector.h b/arch/arm64/include/asm/stackprotector.h
new file mode 100644
index 0000000..de00332
--- /dev/null
+++ b/arch/arm64/include/asm/stackprotector.h
@@ -0,0 +1,38 @@
+/*
+ * GCC stack protector support.
+ *
+ * Stack protector works by putting predefined pattern at the start of
+ * the stack frame and verifying that it hasn't been overwritten when
+ * returning from the function. The pattern is called stack canary
+ * and gcc expects it to be defined by a global variable called
+ * "__stack_chk_guard" on ARM. This unfortunately means that on SMP
+ * we cannot have a different canary value per task.
+ */
+
+#ifndef _ASM_STACKPROTECTOR_H
+#define _ASM_STACKPROTECTOR_H 1
+
+#include <linux/random.h>
+#include <linux/version.h>
+
+extern unsigned long __stack_chk_guard;
+
+/*
+ * Initialize the stackprotector canary value.
+ *
+ * NOTE: this must only be called from functions that never return,
+ * and it must always be inlined.
+ */
+static __always_inline void boot_init_stack_canary(void)
+{
+ unsigned long canary;
+
+ /* Try to get a semi random initial value. */
+ get_random_bytes(&canary, sizeof(canary));
+ canary ^= LINUX_VERSION_CODE;
+
+ current->stack_canary = canary;
+ __stack_chk_guard = current->stack_canary;
+}
+
+#endif /* _ASM_STACKPROTECTOR_H */
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index de17c89..592d630 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -50,6 +50,12 @@
#include <asm/processor.h>
#include <asm/stacktrace.h>
+#ifdef CONFIG_CC_STACKPROTECTOR
+#include <linux/stackprotector.h>
+unsigned long __stack_chk_guard __read_mostly;
+EXPORT_SYMBOL(__stack_chk_guard);
+#endif
+
static void setup_restart(void)
{
/*
@@ -288,6 +294,9 @@ struct task_struct *__switch_to(struct task_struct *prev,
{
struct task_struct *last;
+#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
+ __stack_chk_guard = next->stack_canary;
+#endif
fpsimd_thread_switch(next);
tls_thread_switch(next);
hw_breakpoint_thread_switch(next);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
From: Nishanth Menon @ 2014-01-21 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120233941.GG6516@saruman.home>
On 01/20/2014 05:39 PM, Felipe Balbi wrote:
> On Mon, Jan 20, 2014 at 05:29:02PM -0600, Nishanth Menon wrote:
>> When device is booted using devicetree, platforms impacted by
>> Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum
>> indicates that the module cannot do multi-block transfers.
>>
>> Handle this by providing a boolean flag to indicate to driver that it is
>> working on a hardware with mentioned limitation.
>
> sure there's no way of reading the revision register to figure this one
> out without having to add a new DT attribute ?
>
I did a quick patch to read the Module revision register:
http://slexy.org/view/s21TKvlWlR
sdp2430: Revision: 1.2, Spec: 0.0, normal interrupt
OMAP3430-ldp: (ES2.1): Revision: 2.6, Spec: 0.0, normal interrupt
SDP3430:(ES3.0) Revision: 2.6, Spec: 0.0, normal interrupt
AM3517-evm: (ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt
AM3517-crane:(ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt
AM37x-evm: (ES1.2) Revision: 2.6, Spec: 0.0, normal interrupt
OMAP3630-beag-xm (ES1.2): Revision: 2.6, Spec: 0.0, normal interrupt
am335x-evm:(ES1.0): Revision: 3.1, Spec: 0.1, normal interrupt
am335x-sk: (ES2.1): Revision: 3.1, Spec: 0.1, normal interrupt
am335x-beaglebone-black:(ES2.0): Revision: 3.1, Spec: 0.1, normal
interrupt
sdp4430.txt: (ES2.2): Revision: 3.1, Spec: 0.1, normal interrupt
OMAP4460-panda-es (ES1.1): Revision: 3.1, Spec: 0.1, normal interrupt
OMAP5uevm:(ES2.0): Revision: 3.3, Spec: 0.2, normal interrupt
dra7-evm (es1.1): Revision: 3.3, Spec: 0.2, normal interrupt
OMAP3430-ldp seems to be the only one impacted with module revision
2.6 -> so using revision information is not really helpful here. Hence
the usage of a flag in dt attribute to indicate hardware impacted by
erratum.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Varun Sethi @ 2014-01-21 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120222814.GI3471@alberich>
> -----Original Message-----
> From: Andreas Herrmann [mailto:andreas.herrmann at calxeda.com]
> Sent: Tuesday, January 21, 2014 3:58 AM
> To: Will Deacon
> Cc: iommu at lists.linux-foundation.org; linux-arm-
> kernel at lists.infradead.org; Andreas Herrmann; Sethi Varun-B16395
> Subject: [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier
> block
>
>
> At the moment just handle IOMMU_GROUP_NOTIFY_BIND_DRIVER to conditionally
> isolate all master devices for an SMMU.
>
> Depending on DT information each device is put into its own protection
> domain (if possible). For configuration with one or just a few masters
> per SMMU that is easy to achieve.
>
> In case of many devices per SMMU (e.g. MMU-500 with it's distributed
> translation support) isolation of each device might not be possible --
> depending on number of available SMR groups and/or context banks.
>
> Default is that device isolation is contolled per SMMU with SMMU node
> property "arm,smmu-isolate-devices" in a DT. If this property is set for
> an SMMU node, device isolation is performed.
>
> W/o device isolation the driver detects SMMUs but no translation is
> configured (transactions just bypass translation process).
>
> Note that for device isolation dma_base and size are fixed as 0 and
> SZ_128M at the moment. Additional patches will address this restriction
> and allow automatic growth of mapping size.
>
> Cc: Varun Sethi <Varun.Sethi@freescale.com>
> Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
> ---
> drivers/iommu/arm-smmu.c | 44
> ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> Hi Will,
>
> This new patch addresses Varun's comments:
> - use iommu_group notifier instead of bus notifier
> - remove superfluous call to arm_smmu_add_device in
> notifier function
>
> This patch depends on commit "iommu/arm-smmu: add devices attached to the
> SMMU to an IOMMU group" as found in your git tree (e.g. in branch
> iommu/devel or for-joerg/arm-smmu/updates).
>
>
> Andreas
>
> PS: This time with a proper adaption of the notifier function.
>
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
> 0a5649f..da19bd6 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -46,6 +46,7 @@
> #include <linux/amba/bus.h>
>
> #include <asm/pgalloc.h>
> +#include <asm/dma-iommu.h>
>
> /* Driver options */
> #define ARM_SMMU_OPT_ISOLATE_DEVICES (1 << 0)
> @@ -1517,6 +1518,47 @@ static int arm_smmu_domain_has_cap(struct
> iommu_domain *domain,
> return !!(cap & caps);
> }
>
> +static int arm_smmu_group_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct device *dev = data;
> + struct dma_iommu_mapping *mapping;
> + struct arm_smmu_device *smmu;
> + int ret;
> +
> + switch (action) {
> + case IOMMU_GROUP_NOTIFY_BIND_DRIVER:
> +
> + smmu = dev->archdata.iommu;
> + if (!smmu || !(smmu->options & ARM_SMMU_OPT_ISOLATE_DEVICES))
> + break;
[Sethi Varun-B16395] Should this check be really done here? The "Isolate devices" property would allow us to set up iommu groups. My understanding is that if we specify the isolate devices property, then each device would have a separate iommu group otherwise all devices connected to the SMMU would share the iommu group.
With that logic, we should link the mapping to the iommu group.
-Varun
> +
> + mapping = arm_iommu_create_mapping(&platform_bus_type,
> + 0, SZ_128M, 0);
> + if (IS_ERR(mapping)) {
> + ret = PTR_ERR(mapping);
> + dev_info(dev, "arm_iommu_create_mapping failed\n");
> + break;
> + }
> +
> + ret = arm_iommu_attach_device(dev, mapping);
> + if (ret < 0) {
> + dev_info(dev, "arm_iommu_attach_device failed\n");
> + arm_iommu_release_mapping(mapping);
> + }
> +
> + break;
> + default:
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static struct notifier_block group_nb = {
> + .notifier_call = arm_smmu_group_notifier, };
> +
> static int arm_smmu_add_device(struct device *dev) {
> struct arm_smmu_device *child, *parent, *smmu; @@ -1566,6 +1608,8
> @@ static int arm_smmu_add_device(struct device *dev)
> return PTR_ERR(group);
> }
>
> + iommu_group_register_notifier(group, &group_nb);
> +
> ret = iommu_group_add_device(group, dev);
> iommu_group_put(group);
> dev->archdata.iommu = smmu;
> --
> 1.7.9.5
>
>
^ permalink raw reply
* [PATCH v7 1/2] ohci-platform: Add support for devicetree instantiation
From: Sergei Shtylyov @ 2014-01-21 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389813883-567-2-git-send-email-hdegoede@redhat.com>
Hello.
On 01/15/2014 10:24 PM, Hans de Goede wrote:
> Add support for ohci-platform instantiation from devicetree, including
> optionally getting clks and a phy from devicetree, and enabling / disabling
> those on power_on / off.
> This should allow using ohci-platform from devicetree in various cases.
> Specifically after this commit it can be used for the ohci controller found
> on Allwinner sunxi SoCs.
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
[...]
Have only found time to fully read the patches just now...
> diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt
> new file mode 100644
> index 0000000..f9d6c73
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
> @@ -0,0 +1,22 @@
> +USB OHCI controllers
> +
> +Required properties:
> +- compatible : "usb-ohci"
> +- reg : ohci controller register range (address and length)
> +- interrupts : ohci controller interrupt
> +
> +Optional properties:
> +- clocks : a list of phandle + clock specifier pairs
> +- phys : phandle + phy specifier pair
> +- phy-names : "usb"
> +
> +Example:
> +
> + ohci0: ohci at 0x01c14400 {
Two minor nits: there should be no "0x" in the address part of the node
name. And according to ePAPR [1], "the name of a node should be somewhat
generic, reflecting the function of the device and not its precise programming
model. If appropriate, the name should be one of the following choices:
[...]
- usb".
Same comments for "usb-ehci" binding.
> + compatible = "allwinner,sun4i-a10-ohci", "usb-ohci";
> + reg = <0x01c14400 0x100>;
> + interrupts = <64>;
> + clocks = <&usb_clk 6>, <&ahb_gates 2>;
> + phys = <&usbphy 1>;
> + phy-names = "usb";
> + };
[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
WBR, Sergei
^ permalink raw reply
* [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
From: Felipe Balbi @ 2014-01-21 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DEB078.5030005@ti.com>
Hi,
On Tue, Jan 21, 2014 at 11:38:00AM -0600, Nishanth Menon wrote:
> On 01/20/2014 05:39 PM, Felipe Balbi wrote:
> > On Mon, Jan 20, 2014 at 05:29:02PM -0600, Nishanth Menon wrote:
> >> When device is booted using devicetree, platforms impacted by
> >> Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum
> >> indicates that the module cannot do multi-block transfers.
> >>
> >> Handle this by providing a boolean flag to indicate to driver that it is
> >> working on a hardware with mentioned limitation.
> >
> > sure there's no way of reading the revision register to figure this one
> > out without having to add a new DT attribute ?
> >
> I did a quick patch to read the Module revision register:
> http://slexy.org/view/s21TKvlWlR
>
> sdp2430: Revision: 1.2, Spec: 0.0, normal interrupt
>
> OMAP3430-ldp: (ES2.1): Revision: 2.6, Spec: 0.0, normal interrupt
> SDP3430:(ES3.0) Revision: 2.6, Spec: 0.0, normal interrupt
> AM3517-evm: (ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt
> AM3517-crane:(ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt
>
> AM37x-evm: (ES1.2) Revision: 2.6, Spec: 0.0, normal interrupt
> OMAP3630-beag-xm (ES1.2): Revision: 2.6, Spec: 0.0, normal interrupt
>
> am335x-evm:(ES1.0): Revision: 3.1, Spec: 0.1, normal interrupt
> am335x-sk: (ES2.1): Revision: 3.1, Spec: 0.1, normal interrupt
> am335x-beaglebone-black:(ES2.0): Revision: 3.1, Spec: 0.1, normal
> interrupt
>
> sdp4430.txt: (ES2.2): Revision: 3.1, Spec: 0.1, normal interrupt
>
> OMAP4460-panda-es (ES1.1): Revision: 3.1, Spec: 0.1, normal interrupt
>
> OMAP5uevm:(ES2.0): Revision: 3.3, Spec: 0.2, normal interrupt
> dra7-evm (es1.1): Revision: 3.3, Spec: 0.2, normal interrupt
>
>
> OMAP3430-ldp seems to be the only one impacted with module revision
> 2.6 -> so using revision information is not really helpful here. Hence
> the usage of a flag in dt attribute to indicate hardware impacted by
> erratum.
alright, that's too bad. Seems like revision in this module isn't very
useful :-(
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140121/fde09f0c/attachment.sig>
^ permalink raw reply
* [PATCH v2 5/7] ARM: perf_event: Fully support Krait CPU PMU events
From: Will Deacon @ 2014-01-21 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389808535-23852-6-git-send-email-sboyd@codeaurora.org>
Hi Stephen,
Thanks for the updates. A few more comments inline.
On Wed, Jan 15, 2014 at 05:55:33PM +0000, Stephen Boyd wrote:
> Krait supports a set of performance monitor region event
> selection registers (PMRESR) sitting behind a cp15 based
> interface that extend the architected PMU events to include Krait
> CPU and Venum VFP specific events. To use these events the user
> is expected to program the region register (PMRESRn) with the
> event code shifted into the group they care about and then point
> the PMNx event at that region+group combo by writing a
> PMRESRn_GROUPx event. Add support for this hardware.
>
> Note: the raw event number is a pure software construct that
> allows us to map the multi-dimensional number space of regions,
> groups, and event codes into a flat event number space suitable
> for use by the perf framework.
[...]
> +static u32 krait_read_pmresrn(int n)
> +{
> + u32 val;
> +
> + switch (n) {
> + case 0:
> + asm volatile("mrc p15, 1, %0, c9, c15, 0" : "=r" (val));
> + break;
> + case 1:
> + asm volatile("mrc p15, 1, %0, c9, c15, 1" : "=r" (val));
> + break;
> + case 2:
> + asm volatile("mrc p15, 1, %0, c9, c15, 2" : "=r" (val));
> + break;
> + default:
> + BUG(); /* Should be validated in krait_pmu_get_event_idx() */
> + }
> +
> + return val;
> +}
> +
> +static void krait_write_pmresrn(int n, u32 val)
> +{
> + switch (n) {
> + case 0:
> + asm volatile("mcr p15, 1, %0, c9, c15, 0" : : "r" (val));
> + break;
> + case 1:
> + asm volatile("mcr p15, 1, %0, c9, c15, 1" : : "r" (val));
> + break;
> + case 2:
> + asm volatile("mcr p15, 1, %0, c9, c15, 2" : : "r" (val));
> + break;
> + default:
> + BUG(); /* Should be validated in krait_pmu_get_event_idx() */
> + }
> +}
Do you need isbs to ensure the pmresrn side-effects have happened, or are
the registers self-synchronising? Similarly for your other IMP DEF
registers.
> +static void krait_pre_vpmresr0(u32 *venum_orig_val, u32 *fp_orig_val)
> +{
> + u32 venum_new_val;
> + u32 fp_new_val;
> +
> + /* CPACR Enable CP10 and CP11 access */
> + *venum_orig_val = get_copro_access();
> + venum_new_val = *venum_orig_val | CPACC_SVC(10) | CPACC_SVC(11);
> + set_copro_access(venum_new_val);
> +
> + /* Enable FPEXC */
> + *fp_orig_val = fmrx(FPEXC);
> + fp_new_val = *fp_orig_val | FPEXC_EN;
> + fmxr(FPEXC, fp_new_val);
Messing around with the lot (especially with kernel-mode neon now in
mainline) does scare me. I'd like some BUG_ON(preemptible()) and you could
consider using kernel_neon_{begin,end} but they're a lot heavier than you
need (due to non-lazy switching)
Finally, I'd really like to see this get some test coverage, but I don't
want to try running mainline on my phone :) Could you give your patches a
spin with Vince's perf fuzzer please?
https://github.com/deater/perf_event_tests.git
(then build the contents of the fuzzer directory and run it for as long as
you can).
Cheers,
Will
^ permalink raw reply
* [PATCH v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
From: Will Deacon @ 2014-01-21 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390311864-19119-1-git-send-email-stefano.stabellini@eu.citrix.com>
On Tue, Jan 21, 2014 at 01:44:24PM +0000, Stefano Stabellini wrote:
> Remove !GENERIC_ATOMIC64 build dependency:
> - introduce xen_atomic64_xchg
> - use it to implement xchg_xen_ulong
>
> Remove !CPU_V6 build dependency:
> - introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef
> CONFIG_CPU_V6
> - implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: arnd at arndb.de
> CC: linux at arm.linux.org.uk
> CC: will.deacon at arm.com
> CC: catalin.marinas at arm.com
> CC: linux-arm-kernel at lists.infradead.org
> CC: linux-kernel at vger.kernel.org
> CC: xen-devel at lists.xenproject.org
Reviewed-by: Will Deacon <will.deacon@arm.com>
Cheers Stefano,
Will
^ permalink raw reply
* [PATCH 1/2] ohci-platform: Add support for controllers with big-endian regs / descriptors
From: Alan Stern @ 2014-01-21 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DEA7CD.5070107@redhat.com>
On Tue, 21 Jan 2014, Hans de Goede wrote:
> Hi,
>
> On 01/21/2014 05:40 PM, Alan Stern wrote:
> > On Tue, 21 Jan 2014, Hans de Goede wrote:
> >
> >> Note this commit uses the same devicetree booleans for this as the ones
> >> already existing in the usb-ehci bindings.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >
> >> --- a/drivers/usb/host/Kconfig
> >> +++ b/drivers/usb/host/Kconfig
> >> @@ -512,6 +512,10 @@ config USB_CNS3XXX_OHCI
> >>
> >> config USB_OHCI_HCD_PLATFORM
> >> tristate "Generic OHCI driver for a platform device"
> >> + # Always support LE, support BE on architectures which have readl_be
> >> + select USB_OHCI_LITTLE_ENDIAN
> >> + select USB_OHCI_BIG_ENDIAN_DESC if (AVR32 || MIPS || MICROBLAZE || SPARC || PPC32 || PPC64)
> >> + select USB_OHCI_BIG_ENDIAN_MMIO if (AVR32 || MIPS || MICROBLAZE || SPARC || PPC32 || PPC64)
> >> default n
> > In any case, the style we have adopted is that these select lines go in
> > the arch-specific defconfig, not here.
>
> Ok, so I should drop the Kconfig parts of both patches ?
That's rigt. They are likely to cause trouble, and if the selects were
needed then they should already be present somewhere else.
Alan Stern
^ permalink raw reply
* Question: about wm8904's regulator consumer nodes
From: Mark Brown @ 2014-01-21 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B256D81BAE5131468A838E5D7A24364172F64369@penmbx01>
On Tue, Jan 21, 2014 at 07:10:24AM +0000, Yang, Wenyou wrote:
> DCVDD-supply = <&vcc_1v8_reg>;
> DBVDD-supply = <&vddana_reg>;
> AVDD-supply = <&vcc_1v8_reg>;
> CPVDD-supply = <&vcc_1v8_reg>;
> MICVDD-supply = <&vddana_reg>;
> But the power of DCVDD, DBVDD, AVDD, CPVDD and MICVDD is not supplied by any regulators, not the above regulator nodes.
> How do I deal with this case? Could you give me some advice?
You should set up the supplies to point to whatever regulator is
supplying the power. If there are supplies on the board which are
generated using fixed voltage regulators then you should register those
using the fixed regulator driver. Recent kernels are more tolerant of
missing supplies but it's still better to be explicit if you can be.
-------------- 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/20140121/c4ed9767/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Olof Johansson @ 2014-01-21 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFpfrs=e3bDvdFRpnD3RkmD8ZvAJgFi6XvCRAOocqAKkKw@mail.gmail.com>
On Tue, Jan 21, 2014 at 12:55 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
[pruning quotes a bit]
>>> Is the above regulator related to host->ocr_avail mask? Could the
>>> above regulator be replaced by vmmc?
>>
>> I have to admit that I don't know MMC as well as I could, but OCR seems to be
>> something that's between the driver/controller/device, not related to external
>> power control in this case?
>
> This is related to the power of the card, typically external
> regulators controlled by the host driver.
>
> Both the card and the host supports a voltage range. This range is
> exactly what the OCR mask describes. At initialization of the card,
> the host ocr is validated against the card ocr.
Ok, so they specify the voltage needed, but there's no way to
determine what regulator is wired up to control. So that information
is still needed (possibly through vmmc though).
>>> At the moment host drivers uses mmc_regulator_get_supply(), which
>>> fetches regulators called "vmmc" and "vqmmc". It is also common to
>>> have these defined in DT like "vmmc-supply". This has not been
>>> properly documented for most host cases, and we should fix that. I
>>> also think it would make sense to include these in the documentation
>>> for the common mmc bindings, instead of host specific bindings.
>>
>> Hm, I had been of the impression that the vmmc stuff is to control
>> power/voltage on the signal lines, not for external card power. Still, even in
>> that case there's need for the reset line handling and clock control.
>
> vmmc: the power to the card.
> vqmmc: the I/O voltage levels (for the signal lines).
Ah, ok. So vmmc seems like it's the same then. I'll try to get some
cycles to look at it today.
> Regarding reset, I agree, those seems to be needed.
>
> Regarding clock control. I suppose you are referring to separate
> external clocks, not affecting the SDIO/SD/MMC interface speed!?
>
> That could make sense, but still I wonder how those shall be handled
> in a fine grained power management setup. In other words, when shall
> those be gated/ungated? Is the mmc core able to take the correct
> decision about these?
The reference clock is in most cases I've seen 32kHz, and not
something that's under fine-grained power management. So it's not used
to regulate interface speed, etc.
-Olof
^ permalink raw reply
* [PATCH v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
From: Stefano Stabellini @ 2014-01-21 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121180750.GO30706@mudshark.cambridge.arm.com>
On Tue, 21 Jan 2014, Will Deacon wrote:
> On Tue, Jan 21, 2014 at 01:44:24PM +0000, Stefano Stabellini wrote:
> > Remove !GENERIC_ATOMIC64 build dependency:
> > - introduce xen_atomic64_xchg
> > - use it to implement xchg_xen_ulong
> >
> > Remove !CPU_V6 build dependency:
> > - introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef
> > CONFIG_CPU_V6
> > - implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: arnd at arndb.de
> > CC: linux at arm.linux.org.uk
> > CC: will.deacon at arm.com
> > CC: catalin.marinas at arm.com
> > CC: linux-arm-kernel at lists.infradead.org
> > CC: linux-kernel at vger.kernel.org
> > CC: xen-devel at lists.xenproject.org
>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
>
> Cheers Stefano,
Thanks!!
^ permalink raw reply
* [PATCH v3 16/24] drm/i2c: tda998x: add DT documentation
From: Olof Johansson @ 2014-01-21 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120105410.15705f32@armhf>
On Mon, Jan 20, 2014 at 1:54 AM, Jean-Francois Moine <moinejf@free.fr> wrote:
> On Sun, 19 Jan 2014 20:06:09 -0800
> Olof Johansson <olof@lixom.net> wrote:
>
>> Hi,
>>
>> On Sun, Jan 19, 2014 at 10:58 AM, Jean-Francois Moine <moinejf@free.fr> wrote:
>> > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
>> > ---
>> > .../devicetree/bindings/drm/i2c/tda998x.txt | 24 ++++++++++++++++++++++
>> > 1 file changed, 24 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/drm/i2c/tda998x.txt
>>
>> Please cc bindings for review to devicetree at vger.kernel.org (cc:d here now)
>>
>> > diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
>> > new file mode 100644
>> > index 0000000..72da71d
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
>> > @@ -0,0 +1,24 @@
>> > +Device-Tree bindings for the NXP TDA998x HDMI transmitter
>> > +
>> > +Required properties;
>> > + - compatible: must be "nxp,tda998x"
>> > +
>> > +Optional properties:
>> > + - interrupts: interrupt number for HDMI exchanges - default: by polling
>>
>> What are HDMI exchanges, and how do they differ from other interrupts?
>
> The used HDMI interrupt events are screen plug/unplug and EDID read.
> There are also CEC read/write which are not yet implemented in the
> tda998x driver.
>
> There is no difference from normal interrupts, except that the events
> may be get by polling, so, the interrupt number is optional.]
Ok, then it looks like the property description is a little confusing.
I'd remove the mentioning of HDMI exchanges from it.
>> > +
>> > + - pinctrl-0: pin control group to be used for this controller (IRQ).
>> > +
>> > + - pinctrl-names: must contain a "default" entry.
>> > +
>> > + - video-ports: 24 bits value - default: <0x230145>
>>
>> What is this?
>
> The video-ports value defines how the video controller is connected to
> the tda998x chip. Each 4 bits value tells from which input pins comes
> the video data and if there is any bit inversion. Each byte of this
> video-ports is used to load the VIP_CNTRL_{0,1,2} registers. These ones
> are described in the TDA9983B documentation which is the closer
> available document about the TDA998x family.
>
> The default value is the one defined for TI boards.
> A known other value is <0x234501> which is used for Russell's Armada
> DRM driver in the Cubox (Marvell A510), but this driver has no DT
> support.
Ok, this is a classic case where the binding should describe how
things are configured/wired up instead of hardcoding a register value
like this. From the data sheet there seems to be a _lot_ of settings,
so selecting the needed subset for now might be acceptable (and go
with defaults on the rest).
-Olof
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Tomasz Figa @ 2014-01-21 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390190215-22700-2-git-send-email-olof@lixom.net>
Hi,
On 20.01.2014 04:56, Olof Johansson wrote:
> This patch enables support for power-on sequencing of SDIO peripherals through DT.
>
> In general, it's quite common that wifi modules and other similar
> peripherals have several signals in addition to the SDIO interface that
> needs wiggling before the module will power on. It's common to have a
> reference clock, one or several power rails and one or several lines
> for reset/enable type functions.
>
> The binding as written today introduces a number of reset gpios,
> a regulator and a clock specifier. The code will handle up to 2 gpio
> reset lines, but it's trivial to increase to more than that if needed
> at some point.
>
> Implementation-wise, the MMC core has been changed to handle this during
> host power up, before the host interface is powered on. I have not yet
> implemented the power-down side, I wanted people to have a chance for
> reporting back w.r.t. issues (or comments on the bindings) first.
>
> I have not tested the regulator portion, since the system and module
> I'm working on doesn't need one (Samsung Chromebook with Marvell
> 8797-based wifi). Testing of those portions (and reporting back) would
> be appreciated.
While I fully agree that this is an important problem that needs to be
solved, I really don't think this is the right way, because:
a) power-up sequence is really specific to the MMC device and often it's
not simply a matter of switching on one regulator or one clock, e.g.
specific time constraints need to be met.
b) you can have WLAN chips in which SDIO is just one of the options to
use as host interface, which may be also HSIC, I2C or UART. Really. See [1].
c) this is leaking device specific details to generic host code, which
isn't really elegant.
Now, to make this a bit more constructive, [2] is a solution that I came
up with (not perfect either), which simply adds a separate platform
device for the low level part of the chip. I believe this is a better
solution because:
a) you can often see such WLAN/BT combo chip as a set of separate
devices, e.g. SDIO WLAN, UART BT and a simple PMIC or management IC,
which provides power/reset control, out of band signalling and etc. for
the first two, so it isn't that bad to have a separate device node for
the last one,
b) you have full freedom of defining your DT binding with whatever data
you need, any number of clocks, regulators, GPIOs and even out of band
interrupts (IMHO the most important one).
c) you can implement power-on, power-off sequences as needed for your
particular device,
d) you have full separation of device-specific data from MMC core (or
any other subsystem simply used as a way to perform I/O to the chip).
Now what's missing there is a way to signal the MMC core or any other
transport that a device showed up and the controller should be woken up
out of standby and scan of the bus initialized. This could be done by
explicitly specifying the device as a subnode of the
MMC/UART/USB(HSIC)/I2C or whatever with a link (phandle) to the power
controller of the chip or the other way around - a link to the
MMC/UART/... controller from the power controller node.
What do you think?
Best regards,
Tomasz
References:
[1] - http://www.marvell.com/wireless/assets/marvell_avastar_88w8797.pdf
[2] -
https://review.tizen.org/git/?p=platform/kernel/linux-3.10.git;a=commitdiff;h=978bc9523622248271e4007330ae1a0eee6e0254
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++
> drivers/mmc/core/core.c | 42 +++++++++++++++++++++++++
> drivers/mmc/core/host.c | 30 +++++++++++++++++-
> include/linux/mmc/host.h | 5 +++
> 4 files changed, 87 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
> index 458b57f..962e0ee 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> @@ -5,6 +5,8 @@ these definitions.
> Interpreted by the OF core:
> - reg: Registers location and length.
> - interrupts: Interrupts used by the MMC controller.
> +- clocks: Clocks needed for the host controller, if any.
> +- clock-names: Goes with clocks above.
>
> Card detection:
> If no property below is supplied, host native card detect is used.
> @@ -30,6 +32,15 @@ Optional properties:
> - cap-sdio-irq: enable SDIO IRQ signalling on this interface
> - full-pwr-cycle: full power cycle of the card is supported
>
> +Card power and reset control:
> +The following properties can be specified for cases where the MMC
> +peripheral needs additional reset, regulator and clock lines. It is for
> +example common for WiFi/BT adapters to have these separate from the main
> +MMC bus:
> + - card-reset-gpios: Specify GPIOs for card reset (reset active low)
> + - card-external-vcc-supply: Regulator to drive (independent) card VCC
> + - clock with name "card_ext_clock": External clock provided to the card
> +
> *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
> polarity properties, we have to fix the meaning of the "normal" and "inverted"
> line levels. We choose to follow the SDHCI standard, which specifies both those
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 098374b..c43e6c8 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -13,11 +13,13 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> +#include <linux/clk.h>
> #include <linux/completion.h>
> #include <linux/device.h>
> #include <linux/delay.h>
> #include <linux/pagemap.h>
> #include <linux/err.h>
> +#include <linux/gpio.h>
> #include <linux/leds.h>
> #include <linux/scatterlist.h>
> #include <linux/log2.h>
> @@ -1519,6 +1521,43 @@ void mmc_set_driver_type(struct mmc_host *host, unsigned int drv_type)
> mmc_host_clk_release(host);
> }
>
> +static void mmc_card_power_up(struct mmc_host *host)
> +{
> + int i;
> + struct gpio_desc **gds = host->card_reset_gpios;
> +
> + for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
> + if (gds[i]) {
> + dev_dbg(host->parent, "Asserting reset line %d", i);
> + gpiod_set_value(gds[i], 1);
> + }
> + }
> +
> + if (host->card_regulator) {
> + dev_dbg(host->parent, "Enabling external regulator");
> + if (regulator_enable(host->card_regulator))
> + dev_err(host->parent, "Failed to enable external regulator");
> + }
> +
> + if (host->card_clk) {
> + dev_dbg(host->parent, "Enabling external clock");
> + clk_prepare_enable(host->card_clk);
> + }
> +
> + /* 2ms delay to let clocks and power settle */
> + mmc_delay(20);
> +
> + for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
> + if (gds[i]) {
> + dev_dbg(host->parent, "Deasserting reset line %d", i);
> + gpiod_set_value(gds[i], 0);
> + }
> + }
> +
> + /* 2ms delay to after reset release */
> + mmc_delay(20);
> +}
> +
> /*
> * Apply power to the MMC stack. This is a two-stage process.
> * First, we enable power to the card without the clock running.
> @@ -1535,6 +1574,9 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
> if (host->ios.power_mode == MMC_POWER_ON)
> return;
>
> + /* Power up the card/module first, if needed */
> + mmc_card_power_up(host);
> +
> mmc_host_clk_hold(host);
>
> host->ios.vdd = fls(ocr) - 1;
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 49bc403..e6b850b 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -12,14 +12,18 @@
> * MMC host class device management
> */
>
> +#include <linux/kernel.h>
> +#include <linux/clk.h>
> #include <linux/device.h>
> #include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/idr.h>
> #include <linux/of.h>
> #include <linux/of_gpio.h>
> #include <linux/pagemap.h>
> #include <linux/export.h>
> #include <linux/leds.h>
> +#include <linux/regulator/consumer.h>
> #include <linux/slab.h>
> #include <linux/suspend.h>
>
> @@ -312,7 +316,7 @@ int mmc_of_parse(struct mmc_host *host)
> u32 bus_width;
> bool explicit_inv_wp, gpio_inv_wp = false;
> enum of_gpio_flags flags;
> - int len, ret, gpio;
> + int i, len, ret, gpio;
>
> if (!host->parent || !host->parent->of_node)
> return 0;
> @@ -415,6 +419,30 @@ int mmc_of_parse(struct mmc_host *host)
> if (explicit_inv_wp ^ gpio_inv_wp)
> host->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
>
> + /* Parse card power/reset/clock control */
> + if (of_find_property(np, "card-reset-gpios", NULL)) {
> + struct gpio_desc *gpd;
> + for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
> + gpd = devm_gpiod_get_index(host->parent, "card-reset", i);
> + if (IS_ERR(gpd))
> + break;
> + gpiod_direction_output(gpd, 0);
> + host->card_reset_gpios[i] = gpd;
> + }
> +
> + gpd = devm_gpiod_get_index(host->parent, "card-reset", ARRAY_SIZE(host->card_reset_gpios));
> + if (!IS_ERR(gpd)) {
> + dev_warn(host->parent, "More reset gpios than we can handle");
> + gpiod_put(gpd);
> + }
> + }
> +
> + host->card_clk = of_clk_get_by_name(np, "card_ext_clock");
> + if (IS_ERR(host->card_clk))
> + host->card_clk = NULL;
> +
> + host->card_regulator = regulator_get(host->parent, "card-external-vcc");
> +
> if (of_find_property(np, "cap-sd-highspeed", &len))
> host->caps |= MMC_CAP_SD_HIGHSPEED;
> if (of_find_property(np, "cap-mmc-highspeed", &len))
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 99f5709..6781887 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -297,6 +297,11 @@ struct mmc_host {
> unsigned long clkgate_delay;
> #endif
>
> + /* card specific properties to deal with power and reset */
> + struct regulator *card_regulator; /* External VCC needed by the card */
> + struct gpio_desc *card_reset_gpios[2]; /* External resets, active low */
> + struct clk *card_clk; /* External clock needed by the card */
> +
> /* host specific block data */
> unsigned int max_seg_size; /* see blk_queue_max_segment_size */
> unsigned short max_segs; /* see blk_queue_max_segments */
>
^ permalink raw reply
* [PATCH v2 5/7] ARM: perf_event: Fully support Krait CPU PMU events
From: Stephen Boyd @ 2014-01-21 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121180711.GN30706@mudshark.cambridge.arm.com>
On 01/21/14 10:07, Will Deacon wrote:
> Hi Stephen,
>
> Thanks for the updates. A few more comments inline.
>
> On Wed, Jan 15, 2014 at 05:55:33PM +0000, Stephen Boyd wrote:
>> Krait supports a set of performance monitor region event
>> selection registers (PMRESR) sitting behind a cp15 based
>> interface that extend the architected PMU events to include Krait
>> CPU and Venum VFP specific events. To use these events the user
>> is expected to program the region register (PMRESRn) with the
>> event code shifted into the group they care about and then point
>> the PMNx event at that region+group combo by writing a
>> PMRESRn_GROUPx event. Add support for this hardware.
>>
>> Note: the raw event number is a pure software construct that
>> allows us to map the multi-dimensional number space of regions,
>> groups, and event codes into a flat event number space suitable
>> for use by the perf framework.
> [...]
>
>> +static u32 krait_read_pmresrn(int n)
>> +{
>> + u32 val;
>> +
>> + switch (n) {
>> + case 0:
>> + asm volatile("mrc p15, 1, %0, c9, c15, 0" : "=r" (val));
>> + break;
>> + case 1:
>> + asm volatile("mrc p15, 1, %0, c9, c15, 1" : "=r" (val));
>> + break;
>> + case 2:
>> + asm volatile("mrc p15, 1, %0, c9, c15, 2" : "=r" (val));
>> + break;
>> + default:
>> + BUG(); /* Should be validated in krait_pmu_get_event_idx() */
>> + }
>> +
>> + return val;
>> +}
>> +
>> +static void krait_write_pmresrn(int n, u32 val)
>> +{
>> + switch (n) {
>> + case 0:
>> + asm volatile("mcr p15, 1, %0, c9, c15, 0" : : "r" (val));
>> + break;
>> + case 1:
>> + asm volatile("mcr p15, 1, %0, c9, c15, 1" : : "r" (val));
>> + break;
>> + case 2:
>> + asm volatile("mcr p15, 1, %0, c9, c15, 2" : : "r" (val));
>> + break;
>> + default:
>> + BUG(); /* Should be validated in krait_pmu_get_event_idx() */
>> + }
>> +}
> Do you need isbs to ensure the pmresrn side-effects have happened, or are
> the registers self-synchronising? Similarly for your other IMP DEF
> registers.
There aren't any isbs in the downstream android sources so I assume
they're self synchronizing. I'll confirm with the CPU designers to make
sure.
>
>> +static void krait_pre_vpmresr0(u32 *venum_orig_val, u32 *fp_orig_val)
>> +{
>> + u32 venum_new_val;
>> + u32 fp_new_val;
>> +
>> + /* CPACR Enable CP10 and CP11 access */
>> + *venum_orig_val = get_copro_access();
>> + venum_new_val = *venum_orig_val | CPACC_SVC(10) | CPACC_SVC(11);
>> + set_copro_access(venum_new_val);
>> +
>> + /* Enable FPEXC */
>> + *fp_orig_val = fmrx(FPEXC);
>> + fp_new_val = *fp_orig_val | FPEXC_EN;
>> + fmxr(FPEXC, fp_new_val);
> Messing around with the lot (especially with kernel-mode neon now in
> mainline) does scare me. I'd like some BUG_ON(preemptible()) and you could
> consider using kernel_neon_{begin,end} but they're a lot heavier than you
> need (due to non-lazy switching)
>
> Finally, I'd really like to see this get some test coverage, but I don't
> want to try running mainline on my phone :) Could you give your patches a
> spin with Vince's perf fuzzer please?
>
> https://github.com/deater/perf_event_tests.git
>
> (then build the contents of the fuzzer directory and run it for as long as
> you can).
>
Ok. I'll see what I can do.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Arnd Bergmann @ 2014-01-21 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKFfAvSPYLmvWV5jjT-peZFJ8sJ2bbh4F=JAYoWLhjZpA@mail.gmail.com>
On Tuesday 21 January 2014, Alexandre Courbot wrote:
> >> As discussed earlier in this thread I'm not sure the con_id is
> >> suitable for labelling GPIOs. It'd be better to have a proper name
> >> specified in DT/ACPI instead.
> >
> > +1
>
> I wonder why you guys prefer to have the name defined in the GPIO
> mapping. Having the driver decide the label makes it easier to look up
> which GPIO does what in debugfs, whereas nothing prevents people to
> name GPIOs whatever inadequate name they want in the device DT node.
> What am I overlooking here?
I should have another look at the debugfs representation, but isn't
there a global namespace that gets used for all gpios? Neither the
con_id nor the name that the driver picks would be globally unique
and stable across kernel versions, so they don't make a good user
interface.
I think what we want here is a system-wide unique identifier for
each gpio line that may get represented in debugfs, and use a new
DT mechanism to communicate that.
Arnd
^ permalink raw reply
* [Intel-gfx] [PATCH 1/2] drm: share drm_add_fake_info_node
From: Ben Widawsky @ 2014-01-21 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115234222.GA4770@phenom.ffwll.local>
On Thu, Jan 16, 2014 at 12:42:22AM +0100, Daniel Vetter wrote:
> On Wed, Jan 15, 2014 at 12:08:19PM -0800, Ben Widawsky wrote:
> > On Wed, Jan 15, 2014 at 09:45:28AM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 15, 2014 at 9:39 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > On Wed, Jan 15, 2014 at 12:40 AM, Russell King - ARM Linux
> > > > <linux@arm.linux.org.uk> wrote:
> > > >> On Wed, Jan 15, 2014 at 12:25:10AM +0100, Daniel Vetter wrote:
> > > >>> On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote:
> > > >>> > Both i915 and Armada had the exact same implementation. For an upcoming
> > > >>> > patch, I'd like to call this function from two different source files in
> > > >>> > i915, and having it available externally helps there too.
> > > >>> >
> > > >>> > While moving, add 'debugfs_' to the name in order to match the other drm
> > > >>> > debugfs helper functions.
> > > >>> >
> > > >>> > Cc: linux-arm-kernel at lists.infradead.org
> > > >>> > Cc: intel-gfx at lists.freedesktop.org
> > > >>> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> > > >>>
> > > >>> drm_debugfs_create_files in drm_debugfs.c has the almost same code again.
> > > >>> Now the problem here is that the interface is a bit botched up, since all
> > > >>> the users in i915 and armada actaully faile to clean up teh debugfs dentry
> > > >>> if drm_add_fake_info_node.
> > > >>
> > > >> That's not correct - armada does clean up these, I think you need to
> > > >> take a closer look at the code.
> > > >>
> > > >> We do this by setting node->info_ent to the file operations structure,
> > > >> which is a unique key to the file being registered.
> > > >>
> > > >> Upon failure to create the fake node, we appropriately call
> > > >> drm_debugfs_remove_files() with the first argument being a pointer to
> > > >> the file operations. This causes drm_debugfs_remove_files() to match
> > > >> the fake entry, call debugfs_remove() on the dentry, and remove the
> > > >> node from the list, and free the node structure we allocated.
> > > >>
> > > >> Upon driver teardown, we also call drm_debugfs_remove_files() but with
> > > >> each fops which should be registered, thus cleaning up each fake node
> > > >> which was created.
> > > >>
> > > >> So, Armada does clean up these entries properly.
> > > >
> > > > Indeed I've missed that and it's just i915 that botches this. I still
> > > > think the helper would be saner if it cleans up all its leftovers in
> > > > the failure case.
> > >
> > > Ok, now I've actually page all the stuff back in - if
> > > drm_add_fake_info_node fails we don't set up a drm_info_node structure
> > > and link it anywhere. Which means drm_debugfs_remove_files won't ever
> > > find it and hence can't possibly call debugfs_remove. Which means the
> > > debugfs dentry is leaked. So I think the semantics of that new debugfs
> > > helper should get fixed to also allocate and clean up the debugfs
> > > node.
> > >
> > > I agree that i915 is even worse since it doesn't bother to clean up
> > > any debugfs files at all in the failure case.
> > > -Daniel
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >
> > Perhaps I don't understand what you want here. The only failure path in
> > the fake entry creation does already call debugfs_remove.
> >
> > if (node == NULL) {
> > debugfs_remove(ent);
> > return -ENOMEM;
> > }
> >
> > So long as the function succeeds, the node will be findable and removable.
>
> Oh dear, I didn't see that. Still stand by my opinion though that we
> should shovel the debugfs_create_file into the helper - callers allocating
> something and then the helper freeing it (but only if it fails) is rather
> funky semantics.
> -Daniel
This actually falls apart for the one usage I originally cared about.
For CRC, we store our own info structure instead of fops as the key in
the drm debug list. Therefore, it doesn't align with the usage in ours
or other drivers. One option is to make the helper function take both a
fops as well as a key (an ugly interface if you ask me).
I've already written the patches as you wanted, so I can submit them -
it's just unfortunate that the duplication I was hoping to get rid of
will need to remain.
--
Ben Widawsky, Intel Open Source Technology Center
^ permalink raw reply
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