* [PATCH 1/3] arm64: hw_breakpoint: Add get_hwbkt_alignment_mask
From: Pavel Labath @ 2016-09-23 15:18 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds a utility function for computing the alignment mask of a
hardware breakpoint and fixes arch_validate_hwbkpt_settings to use that
instead.
Signed-off-by: Pavel Labath <labath@google.com>
---
arch/arm64/kernel/hw_breakpoint.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 26a6bf7..14562ae 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -473,6 +473,16 @@ static int arch_build_bp_info(struct perf_event *bp)
return 0;
}
+static unsigned int get_hwbkpt_alignment_mask(struct perf_event *bp)
+{
+ const struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+
+ if (is_compat_bp(bp))
+ return info->ctrl.len == ARM_BREAKPOINT_LEN_8 ? 0x7 : 0x3;
+ else
+ return info->ctrl.type == ARM_BREAKPOINT_EXECUTE ? 0x3 : 0x7;
+}
+
/*
* Validate the arch-specific HW Breakpoint register settings.
*/
@@ -496,11 +506,8 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
* AArch32 tasks expect some simple alignment fixups, so emulate
* that here.
*/
+ alignment_mask = get_hwbkpt_alignment_mask(bp);
if (is_compat_bp(bp)) {
- if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
- alignment_mask = 0x7;
- else
- alignment_mask = 0x3;
offset = info->address & alignment_mask;
switch (offset) {
case 0:
@@ -521,10 +528,6 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
info->address &= ~alignment_mask;
info->ctrl.len <<= offset;
} else {
- if (info->ctrl.type == ARM_BREAKPOINT_EXECUTE)
- alignment_mask = 0x3;
- else
- alignment_mask = 0x7;
if (info->address & alignment_mask)
return -EINVAL;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Robin Murphy @ 2016-09-23 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2017806.nj5EEu7nrO@wuerfel>
On 23/09/16 15:44, Arnd Bergmann wrote:
> On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
>> On 23/09/16 15:01, Stuart Yoder wrote:
>> Otherwise you can
>> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
>> need to trap and translate subsequent SMC calls for e.g. PSCI).
>>
>>> If there is such a requirement, it's something begging for standardization.
>>> Doesn't make sense for multiple divergent approaches for switching from
>>> aarch64/EL2 to aarch32/EL2.
>>
>> Perhaps - I did briefly look into how hard it would be to write a proper
>> SMC service handler to do this (since ATF does have a framework for such
>> things), but concluded it would be more than 10 minutes' work and just
>> cheated instead. It's certainly something which could be raised with the
>> firmware folks.
>
> If we end up allowing all arm64 platforms to be enabled in arch/arm,
> we could perhaps create a generic implementation that does both of
> those things, i.e.
>
> - Take the arm32 kernel Image or zImage file, wrap it inside of a binary
> that implements the arm64 boot protocol.
> - When that starts up, try to use the new PSCI call to jump into
> the arm32 kernel
> - If PSCI failed and we are running in EL2, implement the shim
> and start the arm32 kernel in EL1 mode
Really, though, the firmware call thing is an incredibly niche use-case.
Beyond development, the only real benefit of starting an AArch32 kernel
in Hyp is that you can run AArch32 KVM guests, which you can do equally
well (if not better) under an AArch64 kernel.
The standalone EL2 shim probably has legs, though, if the one currently
found in arch/arm64 is too heavyweight ;) My first version was
essentially that, albeit implemented by a load of .inst directives in
head.S.
Robin.
>
> Arnd
>
^ permalink raw reply
* [PATCH 19/19] reset: sti: softreset: Remove obsolete platforms from dt binding doc.
From: Rob Herring @ 2016-09-23 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-20-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:57PM +0100, Peter Griffin wrote:
> STiH415/6 SoC support is being removed from the kernel.
> This patch updates the sti dt softreset bindings and
> removes references to these obsolete platforms.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <p.zabel@pengutronix.de>
> ---
> Documentation/devicetree/bindings/reset/st,sti-softreset.txt | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 18/19] stmmac: dwmac-sti: Remove obsolete STi platforms
From: Rob Herring @ 2016-09-23 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-19-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:56PM +0100, Peter Griffin wrote:
> This patch removes support for STiH415/6 SoC's from the
> dwmac-sti driver and dt binding doc, as support for these
> platforms is being removed from the kernel. It also removes
> STiD127 related code, which has never actually been supported
> upstream.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <peppe.cavallaro@st.com>
> Cc: <alexandre.torgue@st.com>
> Cc: <netdev@vger.kernel.org>
> ---
> .../devicetree/bindings/net/sti-dwmac.txt | 3 +-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 37 ----------------------
> 2 files changed, 1 insertion(+), 39 deletions(-)
^ permalink raw reply
* [PATCH 12/19] reset: sti: Remove obsolete platforms from dt binding doc.
From: Rob Herring @ 2016-09-23 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-13-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:50PM +0100, Peter Griffin wrote:
> STiH415/6 SoC support is being removed from the kernel.
> This patch updates the sti dt powerdown bindings and
> removes references to these obsolete platforms.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <p.zabel@pengutronix.de>
> Cc: <robh+dt@kernel.org>
> ---
> Documentation/devicetree/bindings/reset/st,sti-powerdown.txt | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
> index 1cfd21d..9252713 100644
> --- a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
> +++ b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
> @@ -16,15 +16,14 @@ Please refer to reset.txt in this directory for common reset
> controller binding usage.
>
> Required properties:
> -- compatible: Should be "st,<chip>-powerdown"
> - ex: "st,stih415-powerdown", "st,stih416-powerdown"
> +- compatible: Should be "st,stih407-powerdown"
> - #reset-cells: 1, see below
>
> example:
>
> powerdown: powerdown-controller {
> + compatible = "st,stih407-powerdown";
> #reset-cells = <1>;
> - compatible = "st,stih415-powerdown";
> };
>
>
> @@ -37,11 +36,10 @@ index specifying which channel to use, as described in reset.txt
>
> example:
>
> - usb1: usb at fe200000 {
> - resets = <&powerdown STIH41X_USB1_POWERDOWN>;
> + st_dwc3: dwc3 at 8f94000 {
usb@ was correct here. With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 10/19] watchdog: bindings: Remove obsolete platforms from dt doc.
From: Rob Herring @ 2016-09-23 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-11-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:48PM +0100, Peter Griffin wrote:
> STiH415/6 SoC support is being removed from the kernel
> so update the dt bding document to reflect this.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <wim@iguana.be>
> Cc: <linux@roeck-us.net>
> Cc: <robh+dt@kernel.org>
> Cc: <linux-watchdog@vger.kernel.org>
> ---
> Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 08/19] thermal: sti: Remove obsolete platforms from the DT doc.
From: Rob Herring @ 2016-09-23 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-9-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:46PM +0100, Peter Griffin wrote:
> STiH415/6 SoC's are being removed from the kernel. This
> patch removes the compatibles from the dt doc and also
> updates the example to a supported platform.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <rui.zhang@intel.com>
> Cc: <edubezval@gmail.com>
> Cc: <robh+dt@kernel.org>
> ---
> .../devicetree/bindings/thermal/st-thermal.txt | 28 +++++++---------------
> 1 file changed, 9 insertions(+), 19 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 07/19] ahci: st: Remove STiH416 dt example
From: Rob Herring @ 2016-09-23 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-8-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:45PM +0100, Peter Griffin wrote:
> This platform is being removed from the kernel so remove
> the dt example.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <tj@kernel.org>
> Cc: <robh+dt@kernel.org>
> Cc: <linux-ide@vger.kernel.org>
> ---
> Documentation/devicetree/bindings/ata/ahci-st.txt | 15 ---------------
> 1 file changed, 15 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 02/19] phy: stih41x-usb: Remove usb phy driver and dt binding documentation.
From: Rob Herring @ 2016-09-23 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-3-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:40PM +0100, Peter Griffin wrote:
> This phy is only used on STiH415/6 based silicon, and support for
> these SoC's is being removed from the kernel.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <kishon@ti.com>
> ---
> .../devicetree/bindings/phy/phy-stih41x-usb.txt | 24 ---
Acked-by: Rob Herring <robh@kernel.org>
> drivers/phy/Kconfig | 8 -
> drivers/phy/Makefile | 1 -
> drivers/phy/phy-stih41x-usb.c | 188 ---------------------
> 4 files changed, 221 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/phy/phy-stih41x-usb.txt
> delete mode 100644 drivers/phy/phy-stih41x-usb.c
^ permalink raw reply
* [PATCH 01/19] phy: phy-miphy365x: Remove miphy365 driver and dt binding documentation.
From: Rob Herring @ 2016-09-23 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-2-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:39PM +0100, Peter Griffin wrote:
> This phy is only used on STiH415/6 based silicon, and support for
> these SoC's is being removed from the kernel.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <kishon@ti.com>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 77 ---
Acked-by: Rob Herring <robh@kernel.org>
> drivers/phy/Kconfig | 10 -
> drivers/phy/Makefile | 1 -
> drivers/phy/phy-miphy365x.c | 625 ---------------------
> 4 files changed, 713 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> delete mode 100644 drivers/phy/phy-miphy365x.c
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: fix endpoint name
From: Greg Kroah-Hartman @ 2016-09-23 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <331f5819-1f65-980d-486d-732342877f2c@atmel.com>
On Fri, Sep 23, 2016 at 04:20:45PM +0200, Nicolas Ferre wrote:
> Le 16/09/2016 ? 10:36, Nicolas Ferre a ?crit :
> > Le 15/09/2016 ? 17:07, Alexandre Belloni a ?crit :
> >> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
> >> atmel_usba_udc fails with:
> >>
> >> ------------[ cut here ]------------
> >> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
> >> ecm_do_notify+0x188/0x1a0
> >> Modules linked in:
> >> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
> >> Hardware name: Atmel SAMA5
> >> [<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
> >> [<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
> >> [<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
> >> [<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
> >> [<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
> >> [<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
> >> [<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
> >> [<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
> >> [<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
> >> [<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
> >> [<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
> >> [<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
> >> [<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
> >> [<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
> >> [<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
> >> [<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
> >> [<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
> >> ---[ end trace e7cf9dcebf4815a6 ]---
> >>
> >> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
> >> Reported-by: Richard Genoud <richard.genoud@gmail.com>
> >> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> >
> > Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> >
> > Felipe, Greg,
> > It is clearly a regression and material for 4.8-fixes. But I do know
> > that we are very late in the process :-(
> > Please do what you can to make it progress before 4.8-final but I'm
> > truly aware of the challenge.
>
> Any chance that we can have it (aka ping)?
It's Felipe's area, not mine :)
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Sudeep Holla @ 2016-09-23 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923150004.GV8917@e106497-lin.cambridge.arm.com>
On 23/09/16 16:00, Liviu Dudau wrote:
> On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
>> Current vexpress smp init code detects whether to override the
>> default smp ops with MCPM smp ops by matching the "cci-400"
>> compatible string, in that MCPM requires control over CCI ports
>> to manage low-power states entry/exit.
>>
>> The "cci-400" compatible string check is a necessary but not
>> sufficient condition for MCPM to work, because the cci-400
>> can be made visible to the kernel, but firmware can nonetheless
>> disable non-secure CCI ports control, while still allowing PMU
>> access; if booted in non-secure world, the kernel would still
>> blindly override smp operations with MCPM operations, resulting
>> in kernel faults when the CCI ports programming interface is
>> accessed from non-secure world.
>>
>> This means that the "cci-400" compatible string check would
>> result in a false positive in systems that eg boot in HYP mode,
>> where CCI ports non-secure access is explicitly not allowed,
>> and it is reported in the respective device tree nodes with
>> CCI ports marked as disabled.
>
> I remember seeing a patch from Marc this week exactly on this
> subject, but I can't find it again today. However, I remember that
> his patch was explicitly testing for the HYP presence.
>
>>
>> Refactor the smp operations initialization to make sure that
>> the kernel is actually allowed to take control over CCI ports
>> (by enabling MCPM smp operations) before overriding default
>> vexpress smp operations.
>>
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
>> 1 file changed, 24 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
>> index 8b8d072..6cfd782 100644
>> --- a/arch/arm/mach-vexpress/platsmp.c
>> +++ b/arch/arm/mach-vexpress/platsmp.c
>> @@ -26,17 +26,34 @@
>> bool __init vexpress_smp_init_ops(void)
>> {
>> #ifdef CONFIG_MCPM
>> + int cpu;
>> + struct device_node *cpu_node, *cci_node;
>> +
>> /*
>> - * The best way to detect a multi-cluster configuration at the moment
>> - * is to look for the presence of a CCI in the system.
>> + * The best way to detect a multi-cluster configuration
>> + * is to detect if the kernel can take over CCI ports
>> + * control. Loop over possible CPUs and check if CCI
>> + * port control is available.
>> * Override the default vexpress_smp_ops if so.
>> */
>> - struct device_node *node;
>> - node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
>> - if (node && of_device_is_available(node)) {
>> - mcpm_smp_set_ops();
>> - return true;
>> + for_each_possible_cpu(cpu) {
>> + bool available;
>> +
>> + cpu_node = of_get_cpu_node(cpu, NULL);
>> + if (WARN(!cpu_node, "Missing cpu device node!"))
>> + return false;
>> +
>> + cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
>> + available = cci_node && of_device_is_available(cci_node);
>
> of_device_is_available() only checks the DT node for status = "enabled";
>
> Does the HYP modify the DT to disable the cci-control-port? If not, then I guess
> this patch is not enough?
>
Correct, I will send out the u-boot patch to disable the cci ports soon.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Rob Herring @ 2016-09-23 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915194146.GB7863@katana>
On Thu, Sep 15, 2016 at 2:41 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Wed, Sep 14, 2016 at 11:49:15AM +0200, Jerome Brunet wrote:
>> This patchset adds a specific compatible string in the Meson I2C driver
>> for the Amlogic Meson gxbb SoC.
>>
>> Other patch series (pinctrl and device tree) are being sent to complete
>> the i2c support on meson gxbb
>>
>> Neil Armstrong (2):
>> i2c: meson: add gxbb compatible string
>> dt-bindings: i2c-meson: add gxbb compatible string
>
> Squashed both patches and applied to for-next, thanks!
Please don't squash. We ask people to split DT bindings for a reason
being reviews and bindings may not go thru subsystem maintainers in
the future. It also makes it harder to find things in the archives or
patchwork (as does maintainer fixups of subject lines).
Rob
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Liviu Dudau @ 2016-09-23 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923130907.4187-1-lorenzo.pieralisi@arm.com>
On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
> Current vexpress smp init code detects whether to override the
> default smp ops with MCPM smp ops by matching the "cci-400"
> compatible string, in that MCPM requires control over CCI ports
> to manage low-power states entry/exit.
>
> The "cci-400" compatible string check is a necessary but not
> sufficient condition for MCPM to work, because the cci-400
> can be made visible to the kernel, but firmware can nonetheless
> disable non-secure CCI ports control, while still allowing PMU
> access; if booted in non-secure world, the kernel would still
> blindly override smp operations with MCPM operations, resulting
> in kernel faults when the CCI ports programming interface is
> accessed from non-secure world.
>
> This means that the "cci-400" compatible string check would
> result in a false positive in systems that eg boot in HYP mode,
> where CCI ports non-secure access is explicitly not allowed,
> and it is reported in the respective device tree nodes with
> CCI ports marked as disabled.
I remember seeing a patch from Marc this week exactly on this
subject, but I can't find it again today. However, I remember that
his patch was explicitly testing for the HYP presence.
>
> Refactor the smp operations initialization to make sure that
> the kernel is actually allowed to take control over CCI ports
> (by enabling MCPM smp operations) before overriding default
> vexpress smp operations.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> index 8b8d072..6cfd782 100644
> --- a/arch/arm/mach-vexpress/platsmp.c
> +++ b/arch/arm/mach-vexpress/platsmp.c
> @@ -26,17 +26,34 @@
> bool __init vexpress_smp_init_ops(void)
> {
> #ifdef CONFIG_MCPM
> + int cpu;
> + struct device_node *cpu_node, *cci_node;
> +
> /*
> - * The best way to detect a multi-cluster configuration at the moment
> - * is to look for the presence of a CCI in the system.
> + * The best way to detect a multi-cluster configuration
> + * is to detect if the kernel can take over CCI ports
> + * control. Loop over possible CPUs and check if CCI
> + * port control is available.
> * Override the default vexpress_smp_ops if so.
> */
> - struct device_node *node;
> - node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
> - if (node && of_device_is_available(node)) {
> - mcpm_smp_set_ops();
> - return true;
> + for_each_possible_cpu(cpu) {
> + bool available;
> +
> + cpu_node = of_get_cpu_node(cpu, NULL);
> + if (WARN(!cpu_node, "Missing cpu device node!"))
> + return false;
> +
> + cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
> + available = cci_node && of_device_is_available(cci_node);
of_device_is_available() only checks the DT node for status = "enabled";
Does the HYP modify the DT to disable the cci-control-port? If not, then I guess
this patch is not enough?
Best regards,
Liviu
> + of_node_put(cci_node);
> + of_node_put(cpu_node);
> +
> + if (!available)
> + return false;
> }
> +
> + mcpm_smp_set_ops();
> + return true;
> #endif
> return false;
> }
> --
> 2.10.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-09-23 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10705430.q2aqv5uYO3@wuerfel>
Hi Arnd
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 23 September 2016 14:43
> To: Gabriele Paoloni
> Cc: zhichang.yuan; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; lorenzo.pieralisi at arm.com; minyard at acm.org;
> linux-pci at vger.kernel.org; gregkh at linuxfoundation.org; John Garry;
> will.deacon at arm.com; linux-kernel at vger.kernel.org; Yuanzhichang;
> Linuxarm; xuwei (O); linux-serial at vger.kernel.org;
> benh at kernel.crashing.org; zourongrong at gmail.com; liviu.dudau at arm.com;
> kantyzc at 163.com
> Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, September 23, 2016 10:23:30 AM CEST Gabriele Paoloni wrote:
> > Hi Arnd
> >
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Sent: 23 September 2016 10:52
> > > To: zhichang.yuan
> > > Cc: Gabriele Paoloni; linux-arm-kernel at lists.infradead.org;
> > > devicetree at vger.kernel.org; lorenzo.pieralisi at arm.com;
> minyard at acm.org;
> > > linux-pci at vger.kernel.org; gregkh at linuxfoundation.org; John Garry;
> > > will.deacon at arm.com; linux-kernel at vger.kernel.org; Yuanzhichang;
> > > Linuxarm; xuwei (O); linux-serial at vger.kernel.org;
> > > benh at kernel.crashing.org; zourongrong at gmail.com;
> liviu.dudau at arm.com;
> > > kantyzc at 163.com
> > > Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on
> > > Hip06
> > >
> > > On Friday, September 23, 2016 12:27:17 AM CEST zhichang.yuan wrote:
> > > > For this patch sketch, I have a question.
> > > > Do we call pci_address_to_pio in arch_of_address_to_pio to get
> the
> > > > corresponding logical IO port
> > > > for LPC??
> > >
> > >
> > > No, of course not, that would be silly:
> > >
> > > The argument to pci_address_to_pio() is a phys_addr_t, and we we
> don't
> > > have one because there is no address associated with your PIO, that
> > > is the entire point of your driver!
> > >
> > > Also, we already know the mapping because this is what the inb/outb
> > > workaround is looking at, so there is absolutely no reason to call
> it
> > > either.
> >
> > Ok assume that we do not call pci_address_to_pio() for the ISA bus...
> > The LPC driver will register its phys address range in io_range_list,
> > then the IPMI driver probe will retrieve its physical address calling
> > of_address_to_resource and will use the indirect io to access this
> > address.
> >
> > From the perspective of the indirect IO function the input parameter
> > is an unsigned long addr that (now) can be either:
> > 1) an IO token coming from a legacy pci device
> > 2) a phys address that lives on the LPC bus
> >
> > These are conceptually two separate address spaces (and actually they
> > both start from 0).
>
> Why? Any IORESOURCE_IO address always refers to the logical I/O port
> range in Linux, not the physical address that is used on a bus.
If I read the code correctly when you get an I/O token you just add it
to PCI_IOBASE.
This is enough since pci_remap_iospace set the virtual address to
PCI_IOBASE + the I/O token offset; so we can read/write to
vaddr = PCI_IOBASE + token as pci_remap_iospace has mapped it correctly
to the respective PCI cpu address (that is set in the I/O range property
of the host controller)
In the patchset accessors LPC operates directly on the cpu addresses
and the input parameter of the accessors can be either an IO token or
a cpu address
+static inline void outb(u8 value, unsigned long addr)
+{
+#ifdef CONFIG_ARM64_INDIRECT_PIO
+ if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
+ addr <= arm64_extio_ops->end)
Here below we operate on cpu address
+ extio_outb(value, addr);
+ else
+#endif
In the case below we have an I/O token added to PCI_IOBASE
to calculate the virtual address
+ writeb(value, PCI_IOBASE + addr);
+}
My point is that if do not call pci_address_to_pio() in
__of_address_to_resource for the ISA LPC exception then the accessors
are called either by passing an IO token or a cpu address...and from
the accessors perspective we do not know...
Thanks
Gab
>
> > If the input parameter can live on different address spaces that are
> > overlapped, even if I save the used LPC range in arm64_extio_ops-
> >start/end
> > there is no way for the indirect IO to tell if the input parameter is
> > an I/O token or a phys address that belongs to LPC...
>
> The start address is the offset: if you get an address between 'start'
> and 'end', you subtract the 'start' from it, and use that to call
> the registered driver function. That works because we can safely
> assume that the bus address range that the LPC driver registers starts
> zero.
>
> Arnd
^ permalink raw reply
* [PATCH] arm64: fix dump_backtrace with NULL tsk
From: Mark Rutland @ 2016-09-23 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In some places, dump_backtrace() is called with a NULL tsk parameter,
e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in
core code. The expectation is that this is treated as if current were
passed instead of NULL.
Commit a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust") didn't
take this into account, and compares tsk against current *before* we
check if tsk is NULL.
Due to this, we won't initialise irq_stack_ptr, and when we try to dump
the exception regs we may call dump_mem() for memory immediately above
the IRQ stack range, rather than for the relevant range on the task
stack.
This will result in misleading, though should not be otherwise
problematic. The initial percpu areas (including the IRQ stacks) are
allocated in the linear map, and dump_mem uses __get_user(), so we
shouldn't access anything with side-effects, and will handle holes
safely.
This patch fixes the issue by handling the NULL tsk case before we do
anything else with tsk.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Fixes: a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust")
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Yang Shi <yang.shi@linaro.org>
---
arch/arm64/kernel/traps.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index e04f838..df06750 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -142,6 +142,11 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
unsigned long irq_stack_ptr;
int skip;
+ pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+
+ if (!tsk)
+ tsk = current;
+
/*
* Switching between stacks is valid when tracing current and in
* non-preemptible context.
@@ -151,11 +156,6 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
else
irq_stack_ptr = 0;
- pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
-
- if (!tsk)
- tsk = current;
-
if (tsk == current) {
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.sp = current_stack_pointer;
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 08/11] pci: controller: dra7xx: Add EP mode support
From: Rob Herring @ 2016-09-23 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473829927-20466-9-git-send-email-kishon@ti.com>
On Wed, Sep 14, 2016 at 10:42:04AM +0530, Kishon Vijay Abraham I wrote:
> The PCIe controller integrated in dra7xx SoCs is capable of operating
> in endpoint mode. Add support for dra7xx SoCs to operate in endpoint
> mode.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> Documentation/devicetree/bindings/pci/ti-pci.txt | 30 ++-
> drivers/pci/controller/Kconfig | 21 +++
> drivers/pci/controller/pci-dra7xx.c | 211 +++++++++++++++++++---
> 3 files changed, 225 insertions(+), 37 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
> index 60e2516..b0e76f6 100644
> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> @@ -1,17 +1,22 @@
> TI PCI Controllers
>
> PCIe Designware Controller
> - - compatible: Should be "ti,dra7-pcie""
> - - reg : Two register ranges as listed in the reg-names property
> - - reg-names : The first entry must be "ti-conf" for the TI specific registers
> - The second entry must be "rc-dbics" for the designware pcie
> - registers
> - The third entry must be "config" for the PCIe configuration space
> + - compatible: Should be "ti,dra7-pcie" for RC
> + Should be "ti,dra7-pcie-ep" for EP
> - phys : list of PHY specifiers (used by generic PHY framework)
> - phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
> number of PHYs as specified in *phys* property.
> - ti,hwmods : Name of the hwmod associated to the pcie, "pcie<X>",
> where <X> is the instance number of the pcie from the HW spec.
> + - num-lanes as specified in ../designware-pcie.txt
> +
> +HOST MODE
> +=========
> + - reg : Two register ranges as listed in the reg-names property
> + - reg-names : The first entry must be "ti-conf" for the TI specific registers
> + The second entry must be "rc-dbics" for the designware pcie
> + registers
> + The third entry must be "config" for the PCIe configuration space
> - interrupts : Two interrupt entries must be specified. The first one is for
> main interrupt line and the second for MSI interrupt line.
> - #address-cells,
> @@ -19,13 +24,24 @@ PCIe Designware Controller
> #interrupt-cells,
> device_type,
> ranges,
> - num-lanes,
> interrupt-map-mask,
> interrupt-map : as specified in ../designware-pcie.txt
>
> Optional Property:
> - gpios : Should be added if a gpio line is required to drive PERST# line
Don't you need gpios as the input side of GPIO outputs in RC mode? Or
for EP mode they are all handled by h/w?
>
> +DEVICE MODE
> +===========
> + - reg : Two register ranges as listed in the reg-names property
> + - reg-names : "ti-conf" for the TI specific registers
> + "ep_dbics" for the standard configuration registers as
> + they are locally accessed within the DIF CS space
> + "ep_dbics2" for the standard configuration registers as
> + they are locally accessed within the DIF CS2 space
> + - interrupts : one interrupt entries must be specified for main interrupt.
> + - num-ib-windows : number of inbound address translation windows
> + - num-ob-windows : number of outbound address translation windows
> +
> Example:
> axi {
> compatible = "simple-bus";
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index 8574828..4d70981 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -23,6 +23,27 @@ config PCI_DRA7XX_HOST
> Enables support for the PCIe controller in the DRA7xx SoC to work in
> host mode.
>
> +config PCI_DRA7XX_EP
> + bool "Endpoint Only Mode"
> + depends on PCI_ENDPOINT
> + select PCIE_DW_EP
> + help
> + Enables support for the PCIe controller in the DRA7xx SoC to work in
> + endpoint mode.
> +
> +config PCI_DRA7XX_HOST_EP
I'd make these 2 options just RC and EP depending on PCI_DRA7XX_HOST
with RC option being default yes.
> + bool "Both Host and Endpoint Mode"
> + depends on PCI_MSI_IRQ_DOMAIN
> + depends on PCI
> + depends on PCI_ENDPOINT
> + select PCIE_DW_HOST
> + select PCIE_DW_EP
> + help
> + Enables support for the PCIe controller in the DRA7xx SoC to work in
> + both endpoint mode and host mode. If the board has 2 PCIe ports and
> + one of them has to work in host mode and the other has to work in
> + EP mode then this option has to be enabled.
> +
> endchoice
>
> endif
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Arnd Bergmann @ 2016-09-23 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15d69a29-6997-6af8-f121-ff253388626c@arm.com>
On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
> On 23/09/16 15:01, Stuart Yoder wrote:
> Otherwise you can
> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
> need to trap and translate subsequent SMC calls for e.g. PSCI).
>
> > If there is such a requirement, it's something begging for standardization.
> > Doesn't make sense for multiple divergent approaches for switching from
> > aarch64/EL2 to aarch32/EL2.
>
> Perhaps - I did briefly look into how hard it would be to write a proper
> SMC service handler to do this (since ATF does have a framework for such
> things), but concluded it would be more than 10 minutes' work and just
> cheated instead. It's certainly something which could be raised with the
> firmware folks.
If we end up allowing all arm64 platforms to be enabled in arch/arm,
we could perhaps create a generic implementation that does both of
those things, i.e.
- Take the arm32 kernel Image or zImage file, wrap it inside of a binary
that implements the arm64 boot protocol.
- When that starts up, try to use the new PSCI call to jump into
the arm32 kernel
- If PSCI failed and we are running in EL2, implement the shim
and start the arm32 kernel in EL1 mode
Arnd
^ permalink raw reply
* [PATCH v6 2/4] arm64: dts: Add timer erratum property for LS2080A and LS1043A
From: Marc Zyngier @ 2016-09-23 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-2-git-send-email-oss@buserror.net>
With a commit message along the lines of:
Both the LS1043A and LS2080A platforms are affected by the Freescale
A008585 erratum. Advertise it in their respective device trees.
On 22/09/16 09:35, Scott Wood wrote:
> Signed-off-by: Scott Wood <oss@buserror.net>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> index e669fbd..952531d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> @@ -123,6 +123,7 @@
> <1 14 0x1>, /* Physical Non-Secure PPI */
> <1 11 0x1>, /* Virtual PPI */
> <1 10 0x1>; /* Hypervisor PPI */
> + fsl,erratum-a008585;
> };
>
> pmu {
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 21023a3..9d3ac19 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -195,6 +195,7 @@
> <1 14 0x8>, /* Physical Non-Secure PPI, active-low */
> <1 11 0x8>, /* Virtual PPI, active-low */
> <1 10 0x8>; /* Hypervisor PPI, active-low */
> + fsl,erratum-a008585;
> };
>
> pmu {
>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6] KVM: arm/arm64: Route vtimer events to user space
From: Paolo Bonzini @ 2016-09-23 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923124048.GI9101@cbox>
On 23/09/2016 14:40, Christoffer Dall wrote:
> On Fri, Sep 23, 2016 at 02:11:41PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 23/09/2016 13:07, Alexander Graf wrote:
>>> + timer_ret = kvm_timer_sync_hwstate(vcpu);
>>>
>>> kvm_vgic_sync_hwstate(vcpu);
>>>
>>> preempt_enable();
>>>
>>> ret = handle_exit(vcpu, run, ret);
>>> +
>>> + if ((ret == 1) && timer_ret) {
>>> + /*
>>> + * We have to exit straight away to ensure that we only
>>> + * ever notify user space once about a level change
>>> + */
>>
>> Is this really a requirement? It complicates the logic noticeably.
>>
>
> If we skip this, then we have to somehow remember that the sync may have
> updated the line level when we reach the flush state (and didn't exit),
> and I would like maintaining that state even less than doing this check.
>
> What we could do is to compare the timer->irq.level with the kvm_run
> state outside of the run loop (on the way to userspace) and update the
> kvm_run state if there's a discrepancy. That way, we can maintain the
> 'timer->irq.level != kvm_run' means, we have to exit, and whenever we
> are exiting, we are reporting the most recent state to user space
> anyway.
>
> Would that work?
It seems clearer at least.
> (By the way, the check should be via a call into the arch timer code,
> kvm_timer_update_user_state() or something like that).
Makes sense.
Paolo
> Also, the comment above is confusing, because that's not why this check
> is here, the check is here so that we don't loose track of the timer
> output level change if there's no exit to userspace.
>
> Thanks,
> -Christoffer
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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 v6 1/4] arm64: arch_timer: Add device tree binding for A-008585 erratum
From: Marc Zyngier @ 2016-09-23 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-1-git-send-email-oss@buserror.net>
On 22/09/16 09:35, Scott Wood wrote:
> This erratum describes a bug in logic outside the core, so MIDR can't be
> used to identify its presence, and reading an SoC-specific revision
> register from common arch timer code would be awkward. So, describe it
> in the device tree.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH 07/11] pci: controller: designware: Add EP mode support
From: Rob Herring @ 2016-09-23 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473829927-20466-8-git-send-email-kishon@ti.com>
On Wed, Sep 14, 2016 at 10:42:03AM +0530, Kishon Vijay Abraham I wrote:
> Add endpoint mode support to designware driver. This uses the
> EP Core layer introduced recently to add endpoint mode support.
> *Any* function driver can now use this designware device
> to achieve the EP functionality.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> .../devicetree/bindings/pci/designware-pcie.txt | 26 ++-
> drivers/pci/controller/Kconfig | 5 +
> drivers/pci/controller/Makefile | 1 +
> drivers/pci/controller/pcie-designware-ep.c | 228 ++++++++++++++++++++
> drivers/pci/controller/pcie-designware.c | 30 +++
> drivers/pci/controller/pcie-designware.h | 45 ++++
> 6 files changed, 324 insertions(+), 11 deletions(-)
> create mode 100644 drivers/pci/controller/pcie-designware-ep.c
>
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index 6c5322c..bb0b789 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -6,23 +6,27 @@ Required properties:
> - reg-names: Must be "config" for the PCIe configuration space.
> (The old way of getting the configuration address space from "ranges"
> is deprecated and should be avoided.)
> -- #address-cells: set to <3>
> -- #size-cells: set to <2>
> -- device_type: set to "pci"
> -- ranges: ranges for the PCI memory and I/O regions
> -- #interrupt-cells: set to <1>
> -- interrupt-map-mask and interrupt-map: standard PCI properties
> - to define the mapping of the PCIe interface to interrupt
> +- #address-cells (only for host mode): set to <3>
> +- #size-cells (only for host mode): set to <2>
> +- device_type (only for host mode): set to "pci"
> +- ranges (only for host mode): ranges for the PCI memory and I/O regions
> +- num-ib-windows (only for EP mode): number of inbound address translation
> + windows
> +- num-ob-windows (only for EP mode): number of outbound address translation
> + windows
> +- #interrupt-cells (only for host mode): set to <1>
> +- interrupt-map-mask and interrupt-map (only for host mode): standard PCI
> + properties to define the mapping of the PCIe interface to interrupt
It may be clearer to just document EP mode in a separate section even if
there's some duplication of properties. Other standard PCI binding
properties probably also don't apply.
Rob
^ permalink raw reply
* [PATCH v6 4/4] arm/arm64: arch_timer: Use archdata to indicate vdso suitability
From: Marc Zyngier @ 2016-09-23 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-4-git-send-email-oss@buserror.net>
On 22/09/16 09:35, Scott Wood wrote:
> Instead of comparing the name to a magic string, use archdata to
> explicitly communicate whether the arch timer is suitable for
> direct vdso access.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Acked-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/clocksource.h | 8 ++++++++
> arch/arm/kernel/vdso.c | 2 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/clocksource.h | 8 ++++++++
> arch/arm64/kernel/vdso.c | 2 +-
> drivers/clocksource/arm_arch_timer.c | 11 +++--------
> 7 files changed, 23 insertions(+), 10 deletions(-)
> create mode 100644 arch/arm/include/asm/clocksource.h
> create mode 100644 arch/arm64/include/asm/clocksource.h
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Rob Herring @ 2016-09-23 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147384330268.13546.17843140335600627152@sboyd-linaro>
On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> Quoting Stephen Boyd (2016-09-13 18:42:46)
> > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > board to mux the D+/D- lines from the SoC between a micro usb
> > "device" port and a USB hub for "host" roles. Upon a role switch,
> > we need to change this mux to forward the D+/D- lines to either
> > the port or the hub. Therefore, introduce a driver for this
> > device that intercepts extcon USB_HOST events and logically
> > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > attached. When the cable goes away, it will logically deassert
> > the gpio and mux the "device" lines.
> >
> > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> >
> > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > Cc: <devicetree@vger.kernel.org>
> > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > ---
> >
> > Should I make the extcon part optional? I could see a case where there are two
> > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > software may want to mux between them at runtime. If we mandate an extcon,
> > that won't be possible to support. Perhaps it would be better to have
> > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > endpoints would be useful too) so that when the controller wants to mux over
> > a port it can do so.
I've mentioned my opinion on extcon before. The first clue that it needs
work is a Linux subsystem name is used for the binding.
> Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> haven't written any code around it, but the idea is to allow the binding
> to specify how the mux is connected to upstream and downstream D+/D-
> lines. This way, we can do some dt parsing of the endpoints and their
> parent nodes to figure out if the mux needs to be set high or low to use
> a device connector or a usb hub based on if the id cable is present.
> Maybe I'm over thinking things though and we could just have a DT
> property for that.
I think the connector nodes are on the right track, but of-graph doesn't
work here because we already have a way to describe USB buses in DT.
Following that, would something like this work for you? The vbus-supply
and id-gpios are just examples and may not always be there like if the
hub controls each port's vbus directly.
usb-controller at 1234 {
usb-switch at 0 {
compatible = "toshiba,tc7usb40mu";
hub at 0 {
compatible = "some-hub";
port at 0 {
compatible = "usb-A-connector"
vbus-supply = ...;
};
port at 1 {
compatible = "usb-A-connector"
vbus-supply = ...;
};
};
connector at 1 {
compatible = "usb-ub-connector";
vbus-supply = ...;
id-gpios = <>;
};
};
};
Rob
^ permalink raw reply
* [PATCH v6 4/4] arm/arm64: arch_timer: Use archdata to indicate vdso suitability
From: Russell King - ARM Linux @ 2016-09-23 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-4-git-send-email-oss@buserror.net>
It helps to add the appropriate people to your email if you want to get
a change into the kernel. Will has had to point this message out to me.
On Thu, Sep 22, 2016 at 03:35:18AM -0500, Scott Wood wrote:
> Instead of comparing the name to a magic string, use archdata to
> explicitly communicate whether the arch timer is suitable for
> direct vdso access.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Acked-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/clocksource.h | 8 ++++++++
> arch/arm/kernel/vdso.c | 2 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/clocksource.h | 8 ++++++++
> arch/arm64/kernel/vdso.c | 2 +-
> drivers/clocksource/arm_arch_timer.c | 11 +++--------
> 7 files changed, 23 insertions(+), 10 deletions(-)
> create mode 100644 arch/arm/include/asm/clocksource.h
> create mode 100644 arch/arm64/include/asm/clocksource.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index a9c4e48..b2113c2 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1,6 +1,7 @@
> config ARM
> bool
> default y
> + select ARCH_CLOCKSOURCE_DATA
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> diff --git a/arch/arm/include/asm/clocksource.h b/arch/arm/include/asm/clocksource.h
> new file mode 100644
> index 0000000..0b350a7
> --- /dev/null
> +++ b/arch/arm/include/asm/clocksource.h
> @@ -0,0 +1,8 @@
> +#ifndef _ASM_CLOCKSOURCE_H
> +#define _ASM_CLOCKSOURCE_H
> +
> +struct arch_clocksource_data {
> + bool vdso_direct; /* Usable for direct VDSO access? */
> +};
> +
> +#endif
> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
> index 994e971..a0affd1 100644
> --- a/arch/arm/kernel/vdso.c
> +++ b/arch/arm/kernel/vdso.c
> @@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk)
> if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
> return false;
>
> - if (strcmp(tk->tkr_mono.clock->name, "arch_sys_counter") != 0)
> + if (!tk->tkr_mono.clock->archdata.vdso_direct)
> return false;
>
> return true;
For the ARM bits:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ 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