* [PATCH 2/2] arm64: dts: marvell: fix clocksource for CP110 slave SPI0
From: Gregory CLEMENT @ 2016-09-20 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473183672-12028-3-git-send-email-mw@semihalf.com>
Hi Olof and Arnd,
On mar., sept. 06 2016, Marcin Wojtas <mw@semihalf.com> wrote:
> I2C and SPI interfaces share common clock trees within the CP110 HW block.
> It occurred that SPI0 interface has wrong clock assignment in the device
> tree, which is fixed in this commit to a proper value.
>
> Fixes: c749b8d9de32 ("arm64: dts: marvell: add description for the ...")
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Could you take this patch for 4.9? I didn't realized at first view it
was for 4.9, I though I could put it the PR for fixes for 4.8.
I can do a new PR for dt64 with this single patch if you prefer.
The last option will be to have it as a fix for v4.9-rc2.
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index 37bff70..150675c 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -133,7 +133,7 @@
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> cell-index = <1>;
> - clocks = <&cps_syscon0 0 3>;
> + clocks = <&cps_syscon0 1 21>;
> status = "disabled";
> };
>
> --
> 1.8.3.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 0/3] ARM: aspeed: add support for the BT IPMI interface
From: Corey Minyard @ 2016-09-20 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474354900-5618-1-git-send-email-clg@kaod.org>
On 09/20/2016 02:01 AM, C?dric Le Goater wrote:
> Hello,
>
> This serie adds support for the iBT interface on Aspeed SOCs (AST2400
> and AST2500). The BT (Block Transfer) interface is used to perform
> in-band IPMI communication between a host and its BMC. This driver
> implements the BMC side.
This looks good. I pulled these into my tree, it's ok for 4.9 or
whatever is next, since it's a new driver.
Do patches 2 and 3 go through Joel?
-corey
> Changes since v2:
>
> - limit to one opener
> - protect write/read operations with a mutex.
>
> Changes since v1:
>
> - the driver is now called 'bt-bmc' and the device node '/dev/ipmi-bt-host'
>
> - the code is now under drivers/char/ipmi/. This required a change of
> the top Makefile in drivers/ to compile the bt-bmc driver with the
> ipmi handlers not being selected. That might be an issue.
>
> - changed the read/write operations to use a temporary buffer and get
> rid of the {get,put}_user calls
>
> Thanks,
>
> C.
>
> Alistair Popple (1):
> ipmi: add an Aspeed BT IPMI BMC driver
>
> C?dric Le Goater (2):
> ARM: aspeed: Add defconfigs for CONFIG_ASPEED_BT_IPMI_BMC
> ARM: dts: aspeed: Enable BT IPMI BMC device
>
> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> arch/arm/boot/dts/aspeed-g5.dtsi | 6 +
> arch/arm/configs/aspeed_g4_defconfig | 1 +
> arch/arm/configs/aspeed_g5_defconfig | 1 +
> drivers/Makefile | 2 +-
> drivers/char/ipmi/Kconfig | 7 +
> drivers/char/ipmi/Makefile | 1 +
> drivers/char/ipmi/bt-bmc.c | 510 +++++++++++++++++++++
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/bt-bmc.h | 18 +
> 11 files changed, 575 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
> create mode 100644 drivers/char/ipmi/bt-bmc.c
> create mode 100644 include/uapi/linux/bt-bmc.h
>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: marvell: fix clocksource for CP110 master SPI0
From: Gregory CLEMENT @ 2016-09-20 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473183672-12028-2-git-send-email-mw@semihalf.com>
Hi Marcin,
On mar., sept. 06 2016, Marcin Wojtas <mw@semihalf.com> wrote:
> I2C and SPI interfaces share common clock trees within the CP110 HW block.
> It occurred that SPI0 interface has wrong clock assignment in the device
> tree, which is fixed in this commit to a proper value.
>
> Fixes: 728dacc7f4dd ("arm64: dts: marvell: initial DT description of ...")
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> CC: <stable@vger.kernel.org> v4.7+
Applied on mvebu/fixes
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index db1be4c..903b0f6 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -133,7 +133,7 @@
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> cell-index = <1>;
> - clocks = <&cpm_syscon0 0 3>;
> + clocks = <&cpm_syscon0 1 21>;
> status = "disabled";
> };
>
> --
> 1.8.3.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v7 05/22] Docs: dt: document ARM SMMUv3 generic binding usage
From: Rob Herring @ 2016-09-20 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2273645f1fa5c76b6b98b5fd03804ab8b55a7691.1473695704.git.robin.murphy@arm.com>
On Mon, Sep 12, 2016 at 05:13:43PM +0100, Robin Murphy wrote:
> We're about to ratify our use of the generic binding, so document it.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> ---
>
> - Reference PCI "iommu-map" binding instead, as that's our main concern
> - Fix "IDs" typo
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 00/19] ARM: imx legacy: move peripheral initializations to .init_late
From: Shawn Guo @ 2016-09-20 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474248988-10626-1-git-send-email-vz@mleia.com>
On Mon, Sep 19, 2016 at 04:36:28AM +0300, Vladimir Zapolskiy wrote:
> Vladimir Zapolskiy (19):
> ARM: imx legacy: kzm: move peripheral initialization to .init_late
> ARM: imx legacy: mx31lite: move peripheral initialization to .init_late
> ARM: imx legacy: mx31ads: move peripheral initialization to .init_late
> ARM: imx legacy: mx31lilly: move peripheral initialization to .init_late
> ARM: imx legacy: pcm037: move peripheral initialization to .init_late
> ARM: imx legacy: mx31-3ds: move peripheral initialization to .init_late
> ARM: imx legacy: qong: move peripheral initialization to .init_late
> ARM: imx legacy: armadillo5x0: move peripheral initialization to .init_late
> ARM: imx legacy: mx31moboard: move peripheral initialization to .init_late
> ARM: imx legacy: vpr200: move peripheral initialization to .init_late
> ARM: imx legacy: imx27-visstrim-m10: move peripheral initialization to .init_late
> ARM: imx legacy: mx27-3ds: move peripheral initialization to .init_late
> ARM: imx legacy: mx35-3ds: move peripheral initialization to .init_late
> ARM: imx legacy: apf9328: move peripheral initialization to .init_late
> ARM: imx legacy: scb9328: move peripheral initialization to .init_late
> ARM: imx legacy: pcm043: move peripheral initialization to .init_late
> ARM: imx legacy: mx21ads: move peripheral initialization to .init_late
> ARM: imx legacy: mx27ads: move peripheral initialization to .init_late
> ARM: imx legacy: pca100: move peripheral initialization to .init_late
Applied all, except patch #14 (apf9328) and #15 (scb9328), which are
removed during this development cycle.
Shawn
^ permalink raw reply
* [PATCH resend 2/5] input: touchscreen: Add LED trigger support to the softbutton code
From: Rob Herring @ 2016-09-20 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911184408.11657-3-hdegoede@redhat.com>
On Sun, Sep 11, 2016 at 08:44:05PM +0200, Hans de Goede wrote:
> In some hardware there are 1 or more LEDs behind the touchscreen
> softbuttons, which are intended to provide visual feedback to the
> user that the softbutton has been pressed, this commit adds support
> for this.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../bindings/input/touchscreen/softbuttons.txt | 4 ++
> drivers/input/touchscreen/softbuttons.c | 49 +++++++++++++++++++++-
> 2 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt b/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> index 3eb6f4c..b425b95 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> @@ -17,6 +17,10 @@ Required subnode-properties:
> - softbutton-min-y : Y start of the area the softbutton area covers
> - softbutton-max-y : Y end of the area the softbutton area covers
>
> +Optional subnode-properties:
> +- linux,led-trigger : String for a LED trigger for providing visual
> + feedback that the softbutton has been pressed
This should just be a phandle to the LED if you want to describe the
link. Or standardize the trigger naming (in the kernel) for buttons and
just use the existing 'linux,default-trigger' in the LED node.
Rob
^ permalink raw reply
* [PATCH resend 1/5] input: touchscreen: Add generic touchscreen softbutton handling code
From: Rob Herring @ 2016-09-20 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911184408.11657-2-hdegoede@redhat.com>
On Sun, Sep 11, 2016 at 08:44:04PM +0200, Hans de Goede wrote:
> Some touchscreens extend over the display they cover and have a number
> of capacative softbuttons outside of the display the cover.
>
> With some hardware these softbuttons simply report touches with
> coordinates outside of the normal coordinate space for touches on the
> display.
>
> This commit adds a devicetree binding for describing such buttons in
> devicetree and a bunch of helper functions to easily add support for
> these to existing touchscreen drivers.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../bindings/input/touchscreen/softbuttons.txt | 58 +++++++++
> drivers/input/touchscreen/Makefile | 2 +-
> drivers/input/touchscreen/softbuttons.c | 145 +++++++++++++++++++++
> include/linux/input/touchscreen.h | 9 ++
> 4 files changed, 213 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> create mode 100644 drivers/input/touchscreen/softbuttons.c
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt b/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> new file mode 100644
> index 0000000..3eb6f4c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> @@ -0,0 +1,58 @@
> +General Touchscreen Softbutton Properties:
> +
> +Some touchscreens extend over the display they cover and have a number
> +of capacative softbuttons outside of the display the cover.
> +
> +Some of these softbuttons simply report touches with coordinates outside of
> +the normal coordinate space for touches on the display. This binding is for
> +describing such buttons in devicetree.
> +
> +Each softkey is represented as a sub-node of the touchscreen node.
> +
> +Required subnode-properties:
> + - label : Descriptive name of the key.
> + - linux,code : Keycode to emit.
> + - softbutton-min-x : X start of the area the softbutton area covers
> + - softbutton-max-x : X end of the area the softbutton area covers
> + - softbutton-min-y : Y start of the area the softbutton area covers
> + - softbutton-max-y : Y end of the area the softbutton area covers
Please add the note about these values are signed.
With that,
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Alexander Graf @ 2016-09-20 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E12D98.6080008@arm.com>
On 09/20/2016 02:37 PM, Marc Zyngier wrote:
> On 20/09/16 13:22, Alexander Graf wrote:
>> On 09/20/2016 12:28 PM, Marc Zyngier wrote:
>>> On 20/09/16 11:05, Alexander Graf wrote:
>>>> On 09/20/2016 11:39 AM, Marc Zyngier wrote:
>>>>> On 20/09/16 10:26, Alexander Graf wrote:
>>>>>> On 20.09.16 11:21, Marc Zyngier wrote:
>>>>>>> On 19/09/16 18:39, Alexander Graf wrote:
>>>>>>>> On 19.09.16 16:48, Marc Zyngier wrote:
>>>>>>>>> On 19/09/16 12:14, Alexander Graf wrote:
>>>>>>>>>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>>>>>>>>>> handle them all using hardware acceleration through the vgic or we can emulate
>>>>>>>>>> a gic in user space and only drive CPU IRQ pins from there.
>>>>>>>>>>
>>>>>>>>>> Unfortunately, when driving IRQs from user space, we never tell user space
>>>>>>>>>> about timer events that may result in interrupt line state changes, so we
>>>>>>>>>> lose out on timer events if we run with user space gic emulation.
>>>>>>>>>>
>>>>>>>>>> This patch fixes that by routing vtimer expiration events to user space.
>>>>>>>>>> With this patch I can successfully run edk2 and Linux with user space gic
>>>>>>>>>> emulation.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> v1 -> v2:
>>>>>>>>>>
>>>>>>>>>> - Add back curly brace that got lost
>>>>>>>>>>
>>>>>>>>>> v2 -> v3:
>>>>>>>>>>
>>>>>>>>>> - Split into patch set
>>>>>>>>>>
>>>>>>>>>> v3 -> v4:
>>>>>>>>>>
>>>>>>>>>> - Improve documentation
>>>>>>>>>> ---
>>>>>>>>>> Documentation/virtual/kvm/api.txt | 30 ++++++++-
>>>>>>>>>> arch/arm/include/asm/kvm_host.h | 3 +
>>>>>>>>>> arch/arm/kvm/arm.c | 22 ++++---
>>>>>>>>>> arch/arm64/include/asm/kvm_host.h | 3 +
>>>>>>>>>> include/uapi/linux/kvm.h | 14 +++++
>>>>>>>>>> virt/kvm/arm/arch_timer.c | 125 +++++++++++++++++++++++++++-----------
>>>>>>>>>> 6 files changed, 155 insertions(+), 42 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>>>>>>>>> index 23937e0..1c0bd86 100644
>>>>>>>>>> --- a/Documentation/virtual/kvm/api.txt
>>>>>>>>>> +++ b/Documentation/virtual/kvm/api.txt
>>>>>>>>>> @@ -3202,9 +3202,14 @@ struct kvm_run {
>>>>>>>>>> /* in */
>>>>>>>>>> __u8 request_interrupt_window;
>>>>>>>>>>
>>>>>>>>>> -Request that KVM_RUN return when it becomes possible to inject external
>>>>>>>>>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>>>>>>>>>> interrupts into the guest. Useful in conjunction with KVM_INTERRUPT.
>>>>>>>>>>
>>>>>>>>>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>>>>>>>>>> +trigger forever. These lines are available:
>>>>>>>>>> +
>>>>>>>>>> + KVM_IRQWINDOW_VTIMER - Masks hw virtual timer irq while in guest
>>>>>>>>>> +
>>>>>>>>>> __u8 padding1[7];
>>>>>>>>>>
>>>>>>>>>> /* out */
>>>>>>>>>> @@ -3519,6 +3524,18 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>>>>>>>>>> event/message pages and to enable/disable SynIC messages/events processing
>>>>>>>>>> in userspace.
>>>>>>>>>>
>>>>>>>>>> + /* KVM_EXIT_ARM_TIMER */
>>>>>>>>>> + struct {
>>>>>>>>>> + __u8 timesource;
>>>>>>>>>> + } arm_timer;
>>>>>>>>>> +
>>>>>>>>>> +Indicates that a timer triggered that user space needs to handle and
>>>>>>>>>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>>>>>>>>>> +guest to proceed. This only happens for timers that got enabled through
>>>>>>>>>> +KVM_CAP_ARM_TIMER. The following time sources are available:
>>>>>>>>>> +
>>>>>>>>>> + KVM_ARM_TIMER_VTIMER - virtual cpu timer
>>>>>>>>>> +
>>>>>>>>>> /* Fix the size of the union. */
>>>>>>>>>> char padding[256];
>>>>>>>>>> };
>>>>>>>>>> @@ -3739,6 +3756,17 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>>>>>>>>>> accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>>>>>>>>>> the guest.
>>>>>>>>>>
>>>>>>>>>> +6.11 KVM_CAP_ARM_TIMER
>>>>>>>>>> +
>>>>>>>>>> +Architectures: arm, arm64
>>>>>>>>>> +Target: vcpu
>>>>>>>>>> +Parameters: args[0] contains a bitmap of timers to select (see 5.)
>>>>>>>>>> +
>>>>>>>>>> +This capability allows to route per-core timers into user space. When it's
>>>>>>>>>> +enabled and no in-kernel interrupt controller is in use, the timers selected
>>>>>>>>>> +by args[0] trigger KVM_EXIT_ARM_TIMER guest exits when they are pending,
>>>>>>>>>> +unless masked by vcpu->run->request_interrupt_window (see 5.).
>>>>>>>>>> +
>>>>>>>>>> 7. Capabilities that can be enabled on VMs
>>>>>>>>>> ------------------------------------------
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>>>>>>>>> index de338d9..77d1f73 100644
>>>>>>>>>> --- a/arch/arm/include/asm/kvm_host.h
>>>>>>>>>> +++ b/arch/arm/include/asm/kvm_host.h
>>>>>>>>>> @@ -180,6 +180,9 @@ struct kvm_vcpu_arch {
>>>>>>>>>>
>>>>>>>>>> /* Detect first run of a vcpu */
>>>>>>>>>> bool has_run_once;
>>>>>>>>>> +
>>>>>>>>>> + /* User space wants timer notifications */
>>>>>>>>>> + bool user_space_arm_timers;
>>>>>>>>> Please move this to the timer structure.
>>>>>>>> Sure.
>>>>>>>>
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> struct kvm_vm_stat {
>>>>>>>>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>>>>>>>>> index c84b6ad..57bdb71 100644
>>>>>>>>>> --- a/arch/arm/kvm/arm.c
>>>>>>>>>> +++ b/arch/arm/kvm/arm.c
>>>>>>>>>> @@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>>>>>>> case KVM_CAP_ARM_PSCI_0_2:
>>>>>>>>>> case KVM_CAP_READONLY_MEM:
>>>>>>>>>> case KVM_CAP_MP_STATE:
>>>>>>>>>> + case KVM_CAP_ARM_TIMER:
>>>>>>>>>> r = 1;
>>>>>>>>>> break;
>>>>>>>>>> case KVM_CAP_COALESCED_MMIO:
>>>>>>>>>> @@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>>>>>>>>>> return ret;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> - /*
>>>>>>>>>> - * Enable the arch timers only if we have an in-kernel VGIC
>>>>>>>>>> - * and it has been properly initialized, since we cannot handle
>>>>>>>>>> - * interrupts from the virtual timer with a userspace gic.
>>>>>>>>>> - */
>>>>>>>>>> - if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
>>>>>>>>>> - ret = kvm_timer_enable(vcpu);
>>>>>>>>>> + ret = kvm_timer_enable(vcpu);
>>>>>>>>>>
>>>>>>>>>> return ret;
>>>>>>>>>> }
>>>>>>>>>> @@ -601,6 +596,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>>>>>>>> run->exit_reason = KVM_EXIT_INTR;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> + if (kvm_check_request(KVM_REQ_PENDING_TIMER, vcpu)) {
>>>>>>>>> Since this is a very unlikely event (in the grand scheme of things), how
>>>>>>>>> about making this unlikely()?
>>>>>>>>>
>>>>>>>>>> + /* Tell user space about the pending vtimer */
>>>>>>>>>> + ret = 0;
>>>>>>>>>> + run->exit_reason = KVM_EXIT_ARM_TIMER;
>>>>>>>>>> + run->arm_timer.timesource = KVM_ARM_TIMER_VTIMER;
>>>>>>>>>> + }
>>>>>>>>> More importantly: why does it have to be indirected by a
>>>>>>>>> make_request/check_request, and not be handled as part of the
>>>>>>>>> kvm_timer_sync() call? We do update the state there, and you could
>>>>>>>>> directly find out whether an exit is required.
>>>>>>>> I can try - it seemed like it could easily become quite racy because we
>>>>>>>> call kvm_timer_sync_hwstate() at multiple places.
>>>>>>> It shouldn't. We only do it at exactly two locations (depending whether
>>>>>>> we've entered the guest or not).
>>>>>>>
>>>>>>> Also, take the following scenario:
>>>>>>> (1) guest programs the timer to expire at time T
>>>>>>> (2) guest performs an MMIO access which traps
>>>>>>> (3) during the world switch, the timer expires and we mark the timer
>>>>>>> interrupt as pending
>>>>>>> (4) we exit to handle the MMIO, no sign of the timer being pending
>>>>>>>
>>>>>>> Is the timer event lost? Or simply delayed? I think this indicates that
>>>>>>> the timer state should always be signalled to userspace, no matter what
>>>>>>> the exit reason is.
>>>>>> That's basically what I'm trying to get running right now, yes. I pushed
>>>>>> the interrupt pending status field into the kvm_sync_regs struct and
>>>>>> check it on every exit in user space - to make sure we catch pending
>>>>>> state changes before mmio reads.
>>>>>>
>>>>>> On top of that we also need a force exit event when the state changes,
>>>>>> in case there's no other event pending. Furthermore we probably want to
>>>>>> indicate the user space status of the pending bit into the kernel to not
>>>>>> exit too often.
>>>>> All you need is to do is to stash the line state in the run structure.
>>>> That's what I do now, yes. The sync_regs struct is basically an arch
>>>> specific add-on to the run structure, so we don't modify padding /
>>>> alignment with the change.
>>>>
>>>>> You shouldn't need any other information. And you trigger the exit on
>>>>> "timer line high + timer line unmasked" in order to inject the
>>>>> interrupt. Which is basically what the vgic does. It would greatly help
>>>>> if you adopted a similar behaviour.
>>>> We also need to know "timer line low + timer line masked", as otherwise
>>>> we might get spurious interrupts in the guest, no?
>>> Yes. Though you can't really know about this one, and you'll have to
>>> wait until the next natural exit to find out. As long as the spurious is
>> We can provoke a special exit for it, no?
> How? The guest decides to disable its timer. That doesn't trigger any
> exit whatsoever. You'll have to wait until the next exit from the guest
> to notice it.
Before we inject a timer interrupt, we can check whether the pending
semantics of user space / kernel space match. If they don't match, we
can exit before we inject the interrupt and allow user space to disable
the pending state again.
>
>>> "spurious in the GIC sense" (hence returning 0x3ff) and not a spurious
>>> timer interrupt being presented, you're fine.
>> Imagine
>>
>> * guest configures timer to fire
>> * kvm exits to user space because lines mismatch now
> I suppose you mean timer fired + physical interrupt for the virtual enabled?
In this scheme, I would simply say "user space thinks it's pending" ==
"host vtimer irq is masked". So because user space thinks that no timer
is pending and the guest managed to trigger a vtimer irq on the host,
the guest exited on a physical vtimer irq. Kvm then checks whether the
timer expired and sets the vcpu timer pending status to 1. User space
status is still 0, so kvm exits to user space to update the status.
>
>> * user space sets gic line up, setting vcpu irq line high
>> * guest runs, handles IRQ, calls EOI with IRQs disabled on the core
> Same thing: you mean physical interrupt for the virtual timer disabled?
> or something else?
I mean the guest sets pstate.I = 0.
>
>> * user space handles EOI, but still leaves the vcpu line high
> If there is another pending interrupt, sure. Otherwise, that's a bug.
Why is that a bug? The line really is still pending at this point.
>
>> * guest runs, sets cval, enables IRQs on the core
> What is that interrupt? Please name things, because that's very confusing.
The guest sets pstate.I=1.
>
>> * kvm injects a timer interrupt into the guest
> Why? Has the timer fired?
cntv.ctl.imask = 0 here, but user space doesn't know that yet. So the
"pending" state is still active.
>
>> At this point, the pending state from user space is bogus, as the line
>> really isn't pending anymore. However, when the guest asks the GIC at
>> that point what interrupt is pending, the line down state will have
>> populated into user space before the mmio request gets processed. So you
>> will see a 0x3ff return I guess.
>>
>> Is that reasonable?
> I'm sorry, but you need to put names on things and precisely describe
> the various events. because from the above script, I can derive twenty
> different scenarios...
I'm sure one of them has to be racy? :)
(in fact, there are probably more than what I came up with that really
are...)
Alex
^ permalink raw reply
* [PATCH v2 2/6] Documentation: dt-bindings: Add documentation for the Meson USB2 PHYs
From: Rob Herring @ 2016-09-20 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911134111.31141-3-martin.blumenstingl@googlemail.com>
On Sun, Sep 11, 2016 at 03:41:07PM +0200, Martin Blumenstingl wrote:
> Add the documentation for the bindings for the Meson8b and GXBB USB2
> PHYs.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../devicetree/bindings/phy/meson-usb2-phy.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
> new file mode 100644
> index 0000000..9da5ea2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
> @@ -0,0 +1,27 @@
> +* Amlogic USB2 PHY
> +
> +Required properties:
> +- compatible: Depending on the platform this should be one of:
> + "amlogic,meson8b-usb2-phy"
> + "amlogic,meson-gxbb-usb2-phy"
> +- reg: The base address and length of the registers
> +- #phys-cells: should be 0 (see phy-bindings.txt in this directory)
> +- clocks: phandle and clock identifier for the phy clocks
> +- clock-names: "usb_general" and "usb"
> +
> +Optional properties:
> +- resets: reference to the reset controller
> +- phy-supply: see phy-bindings.txt in this directory
> +
> +
> +Example:
> +
> +usb0_phy: usb_phy at 0 {
usb-phy at 0
With that,
Acked-by: Rob Herring <robh@kernel.org>
> + compatible = "amlogic,meson-gxbb-usb2-phy";
> + #phy-cells = <0>;
> + reg = <0x0 0x0 0x0 0x20>;
> + resets = <&reset RESET_USB_OTG>;
> + clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB0>;
> + clock-names = "usb_general", "usb";
> + phy-supply = <&usb_vbus>;
> +};
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v2 1/6] usb: dwc2: add support for Meson8b and GXBB SoCs
From: Rob Herring @ 2016-09-20 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911134111.31141-2-martin.blumenstingl@googlemail.com>
On Sun, Sep 11, 2016 at 03:41:06PM +0200, Martin Blumenstingl wrote:
> From: Jerome Brunet <jbrunet@baylibre.com>
>
> Add compatible strings for amlogic Meson8b and GXBB SoCs with the
> corresponding configuration parameters.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/usb/dwc2/platform.c | 34 ++++++++++++++++++++++++++
> 2 files changed, 36 insertions(+)
^ permalink raw reply
* [PATCH v2 1/2] Documentation: dt: add bindings for ti-cpufreq
From: Dave Gerlach @ 2016-09-20 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919211400.GA4276@rob-hp-laptop>
Rob,
On 09/19/2016 04:14 PM, Rob Herring wrote:
> On Wed, Aug 31, 2016 at 09:53:27PM -0500, Dave Gerlach wrote:
>> Add the device tree bindings document for the TI CPUFreq/OPP driver
>> on AM33xx, AM43xx, DRA7, and AM57 SoCs. The operating-points-v2 binding
>> allows us to provide an opp-supported-hw property for each OPP to define
>> when it is available. This driver is responsible for reading and parsing
>> registers to determine which OPPs can be selectively enabled based
>> on the specific SoC in use by matching against the opp-supported-hw
>> data.
>
> Sorry, for the delay. Missed this somehow.
>
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> v1->v2:
>> - Dropped all driver/linux specific documentation
>> - Fixed some typos
>> - Add new compatibles for each SoC family to match against
>> - Switched to use am335x example to better demonstrate field one of
>> opp-supported-hw.
>>
>> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 130 +++++++++++++++++++++
>> 1 file changed, 130 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> new file mode 100644
>> index 000000000000..6276ae494121
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> @@ -0,0 +1,130 @@
>> +TI CPUFreq and OPP bindings
>> +================================
>> +
>> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
>> +families support different OPPs depending on the silicon variant in use.
>> +The ti_cpufreq driver can use revision and an efuse value from the SoC to
>> +provide the OPP framework with supported hardware information. This is
>> +used to determine which OPPs from the operating-points-v2 table get enabled
>> +when it is parsed by the OPP framework.
>> +
>> +Required properties:
>> +--------------------
>> +In 'cpus' nodes:
>> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
>> +- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
>> + mask, and efuse register shift to get the relevant bits
>> + that describe OPP availability.
>> +- ti,syscon-rev: Syscon and offset used to look up revision value on SoC.
>
> These have nothing to do with a cpu, so they don't belong here. Maybe
> the first is a property of an OPP table, but the second certainly is
> not.
Yes, I have no issue with this and will move the ti properties into the
operating points table for v3 of the series.
>
>> +
>> +In 'operating-points-v2' table:
>> +- compatible: Should be
>> + - 'operating-points-v2-ti-am3352-cpu' for am335x SoCs
>> + - 'operating-points-v2-ti-am4372-cpu' for am43xx SoCs
>> + - 'operating-points-v2-ti-dra7-cpu' for dra7xx/am57xx SoCs
>> +
>> +- opp-supported-hw: Two bitfields indicating:
>> + 1. Which revision of the SoC the OPP is supported by
>> + 2. Which eFuse bits indicate this OPP is available
>
> I tend to think you should handle this with kernel code (bootloader
> really) fixing up the OPP table as necessary rather than putting in DT.
>
The operating-points-v2 binding here [1] was designed with doing this in
mind, and others are using it and the corresponding functionality
offered by the OPP core to selectively enable OPPs. Why hide this in
u-boot when we already have kernel framework support to do it?
Thanks for your comments, will send v3 moving the appropriate properties
into the OPP table.
Regards,
Dave
[1] Documentation/devicetree/bindings/opp/opp.txt
> Rob
>
^ permalink raw reply
* [PATCH 2/2] arm-cci: Do not probe the CCI ports if booted from HYP
From: Marc Zyngier @ 2016-09-20 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474380833-30121-1-git-send-email-marc.zyngier@arm.com>
Poking the CCI ports from non-secure is likely to end up in fireworks,
so let's not try our luck here, and skip the driver initialization
if booted from HYP (which is always non-secure).
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/bus/arm-cci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index ffa7c9d..70f51a9 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -28,6 +28,7 @@
#include <asm/cacheflush.h>
#include <asm/smp_plat.h>
+#include <asm/virt.h>
static void __iomem *cci_ctrl_base;
static unsigned long cci_ctrl_phys;
@@ -2184,6 +2185,16 @@ static int cci_probe_ports(struct device_node *np)
const char *match_str;
bool is_ace;
+ /*
+ * If we booted in HYP mode, then we're running non-secure,
+ * and there is zero chance that we'll be able to configure
+ * anything on the CCI. Gracefully leave the room...
+ */
+ if (is_hyp_mode_available()) {
+ pr_info("%s: skipping probe (running non-secure)\n",
+ np->full_name);
+ return -ENODEV;
+ }
cci_config = of_match_node(arm_cci_matches, np)->data;
if (!cci_config)
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] ARM: vexpress: Do not enable MCPM if booted from HYP
From: Marc Zyngier @ 2016-09-20 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474380833-30121-1-git-send-email-marc.zyngier@arm.com>
Using MCPM implies being able to tweak the CCI at runtime, which
is impossible to do when running non-secure. Since HYP implies
running non-secure, let's not enable MCPM in that case.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/mach-vexpress/platsmp.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index 8b8d072..09819f1 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -17,6 +17,7 @@
#include <asm/mcpm.h>
#include <asm/smp_scu.h>
+#include <asm/virt.h>
#include <asm/mach/map.h>
#include <plat/platsmp.h>
@@ -29,11 +30,14 @@ bool __init vexpress_smp_init_ops(void)
/*
* The best way to detect a multi-cluster configuration at the moment
* is to look for the presence of a CCI in the system.
- * Override the default vexpress_smp_ops if so.
+ * Override the default vexpress_smp_ops if so, but only if
+ * the kernel is not booted from HYP mode (which indicates
+ * that we're running in non-secure mode, where the CCI is not
+ * accessible).
*/
struct device_node *node;
node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
- if (node && of_device_is_available(node)) {
+ if (node && of_device_is_available(node) && !is_hyp_mode_available()) {
mcpm_smp_set_ops();
return true;
}
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] ARM: Do not mess with CCI if booted from HYP
From: Marc Zyngier @ 2016-09-20 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Some systems (such as the VExpress TC2) are built around a CCI-400,
which is only accessible from secure mode. This obviously breaks if
the system is booted in non-secure mode. Detecting non-secure is
pretty hard to do, unless the system is booted from HYP.
This small patch series makes sure that:
- The CCI ports are not accessed when the kernel is booted from HYP
- MCPM (which depends on CCI) is not enabled on VExpress if booted
from HYP.
This allows a multi_v7_defconfig kernel to be booted on a TC2 booting
from HYP, instead of miserably dying very early on.
Marc Zyngier (2):
ARM: vexpress: Do not enable MCPM if booted from HYP
arm-cci: Do not probe the CCI ports if booted from HYP
arch/arm/mach-vexpress/platsmp.c | 8 ++++++--
drivers/bus/arm-cci.c | 11 +++++++++++
2 files changed, 17 insertions(+), 2 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Hanjun Guo @ 2016-09-20 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920133813.GR25086@rric.localdomain>
On 09/20/2016 09:38 PM, Robert Richter wrote:
> On 20.09.16 19:32:34, Hanjun Guo wrote:
>> On 09/20/2016 06:43 PM, Robert Richter wrote:
>
>>> Instead we need to make sure the set_*numa_node() functions are called
>>> earlier before secondary cpus are booted. My suggested change for that
>>> is this:
>>>
>>>
>>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>>> index d93d43352504..952365c2f100 100644
>>> --- a/arch/arm64/kernel/smp.c
>>> +++ b/arch/arm64/kernel/smp.c
>>> @@ -204,7 +204,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>>> static void smp_store_cpu_info(unsigned int cpuid)
>>> {
>>> store_cpu_topology(cpuid);
>>> - numa_store_cpu_info(cpuid);
>>> }
>>>
>>> /*
>>> @@ -719,6 +718,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>>> continue;
>>>
>>> set_cpu_present(cpu, true);
>>> + numa_store_cpu_info(cpu);
>>> }
>>> }
>>
>> We tried a similar approach which add numa_store_cpu_info() in
>> early_map_cpu_to_node(), and remove it from smp_store_cpu_info,
>> but didn't work for us, we will try your approach to see if works.
And it works :)
>
> Calling it in early_map_cpu_to_node() is probably too early since
> setup_node_to_cpumask_map() is called in numa_init() afterwards
> overwriting it again.
>
> Actually, early_map_cpu_to_node() is used to temporarily store the
> mapping until it can be setup in numa_store_cpu_info().
Thanks for the clarify, let's wait for David's reply on this one.
Thanks
Hanjun
^ permalink raw reply
* ftrace function_graph causes system crash
From: Steven Rostedt @ 2016-09-20 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7d0e88fff8e64591ac31be3adbbf763c@SIWEX5A.sing.micron.com>
On Tue, 20 Sep 2016 13:10:39 +0000
"Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
> Hi, all
> I just use ftrace to do some latency study, found that function_graph can not
> Work, as long as enable it, will cause kernel panic. I searched this online.
> Found that there are also some cause the same as mine. I am a newer of ftrace.
> I want to know who know what root cause? Here is some partial log:
>
>
Can you do a function bisect to find what function this is.
This script is used to help find functions that are being traced by
function tracer or function graph tracing that causes the machine to
reboot, hang, or crash. Here's the steps to take.
First, determine if function graph is working with a single function:
# cd /sys/kernel/debug/tracing
# echo schedule > set_ftrace_filter
# echo function_graph > current_tracer
If this works, then we know that something is being traced that
shouldn't be.
# echo nop > current_tracer
# cat available_filter_functions > ~/full-file
# ftrace-bisect ~/full-file ~/test-file ~/non-test-file
# cat ~/test-file > set_ftrace_filter
*** Note *** this will take several minutes. Setting multiple functions
is an O(n^2) operation, and we are dealing with thousands of functions.
So go have coffee, talk with your coworkers, read facebook. And
eventually, this operation will end.
# echo function_graph > current_tracer
If it crashes, we know that ~/test-file has a bad function.
Reboot back to test kernel.
# cd /sys/kernel/debug/tracing
# mv ~/test-file ~/full-file
If it didn't crash.
# echo nop > current_tracer
# mv ~/non-test-file ~/full-file
Get rid of the other test file from previous run (or save them off
somewhere.
# rm -f ~/test-file ~/non-test-file
And start again:
# ftrace-bisect ~/full-file ~/test-file ~/non-test-file
The good thing is, because this cuts the number of functions in
~/test-file by half, the cat of it into set_ftrace_filter takes half as
long each iteration, so don't talk so much at the water cooler the
second time.
Eventually, if you did this correctly, you will get down to the problem
function, and all we need to do is to notrace it.
The way to figure out if the problem function is bad, just do:
# echo <problem-function> > set_ftrace_notrace
# echo > set_ftrace_filter
# echo function_graph > current_tracer
And if it doesn't crash, we are done.
-- Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ftrace-bisect
Type: application/octet-stream
Size: 1487 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160920/de1e152c/attachment.obj>
^ permalink raw reply
* [PATCH] gpio: Added zynq specific check for special pins on bank zero
From: Sören Brinkmann @ 2016-09-20 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474360324-8168-1-git-send-email-navam@xilinx.com>
On Tue, 2016-09-20 at 14:02:04 +0530, Nava kishore Manne wrote:
> From: Nava kishore Manne <nava.manne@xilinx.com>
>
> This patch adds zynq specific check for bank 0 pins 7 and 8
> are special and cannot be used as inputs
>
> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
> ---
> drivers/gpio/gpio-zynq.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
> index e72794e..eae9d24 100644
> --- a/drivers/gpio/gpio-zynq.c
> +++ b/drivers/gpio/gpio-zynq.c
> @@ -96,6 +96,10 @@
> /* GPIO upper 16 bit mask */
> #define ZYNQ_GPIO_UPPER_MASK 0xFFFF0000
>
> +/* For GPIO quirks */
> +#define ZYNQ_GPIO BIT(0)
> +#define ZYNQMP_GPIO BIT(1)
I'd make sure all quirks are easily identifiable and call them something
like 'ZYNQ_GPIO_QUIRK_FOO'
Apart from that:
Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
S?ren
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-20 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-AE7fft_j2cqBCN=xrsf5Yh=mePf5x3dZJuKAmdxF-Gg@mail.gmail.com>
Hi Ard,
On Tue, Sep 20, 2016 at 02:40:13PM +0100, Ard Biesheuvel wrote:
> On 20 September 2016 at 14:33, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > [+cc Rafael (maybe already cc'd; I didn't recognize rafael at kernel.org, Duc]
> >
> > On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz Nowicki wrote:
> >> On 19.09.2016 20:09, Bjorn Helgaas wrote:
> >> >On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
> >> >>thunder-pem driver stands for being ACPI based PCI host controller.
> >> >>However, there is no standard way to describe its PEM-specific register
> >> >>ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension
> >> >>to obtain hardcoded addresses from static resource array.
> >> >>Although it is not pretty, it prevents from creating standard mechanism to
> >> >>handle similar cases in future.
> >> >>
> >> >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> >> >>---
> >> >> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++--------
> >> >> 1 file changed, 48 insertions(+), 13 deletions(-)
> >> >>
> >> >>diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> >> >>index 6abaf80..b048761 100644
> >> >>--- a/drivers/pci/host/pci-thunder-pem.c
> >> >>+++ b/drivers/pci/host/pci-thunder-pem.c
> >> >>@@ -18,6 +18,7 @@
> >> >> #include <linux/init.h>
> >> >> #include <linux/of_address.h>
> >> >> #include <linux/of_pci.h>
> >> >>+#include <linux/pci-acpi.h>
> >> >> #include <linux/pci-ecam.h>
> >> >> #include <linux/platform_device.h>
> >> >>
> >> >>@@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
> >> >> return pci_generic_config_write(bus, devfn, where, size, val);
> >> >> }
> >> >>
> >> >>+#ifdef CONFIG_ACPI
> >> >>+static struct resource thunder_pem_reg_res[] = {
> >> >>+ [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M),
> >> >>+ [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M),
> >> >>+ [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M),
> >> >>+ [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M),
> >> >>+ [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M),
> >> >>+ [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M),
> >> >>+ [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M),
> >> >>+ [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M),
> >> >>+ [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M),
> >> >>+ [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M),
> >> >>+ [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M),
> >> >>+ [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M),
> >> >
> >> >1) The "correct" way to discover the resources consumed by an ACPI
> >> > device is to use the _CRS method. I know there are some issues
> >> > there for bridges (not the fault of ThunderX!) because there's not
> >> > a good way to distinguish windows from resources consumed directly
> >> > by the bridge.
> >> >
> >> > But we should either do this correctly, or include a comment about
> >> > why we're doing it wrong, so we don't give the impression that this
> >> > is the right way to do it.
> >> >
> >> > I seem to recall some discussion about why we're doing it this way,
> >> > but I don't remember the details. It'd be nice to include a
> >> > summary here.
> >>
> >> OK I will. The reason why we cannot use _CRS for this case is that
> >> CONSUMER flag was not use consistently for the bridge so far.
> >
> > Yes, I'm aware of that problem, but hard-coding resources into drivers
> > is just a disaster. The PCI and ACPI cores need generic ways to learn
> > what resources are consumed by devices. For PCI devices, that's done
> > with BARs. For ACPI devices, it's done with _CRS. Without generic
> > resource discovery, we can't manage resources reliably at the system
> > level [1].
> >
> > You have a PNP0A03/PNP0A08 device for the PCI host bridge. Because of
> > the BIOS bugs in CONSUMER flag usage, we assume everything in its _CRS
> > is a window and not consumed by the bridge itself. What if you added
> > a companion ACPI device with a _CRS that contained the bridge
> > resources? Then you'd have some driver ugliness to find that device,
> > but at least the ACPI core could tell what resources were in use.
> >
> > Maybe Rafael has a better idea?
>
> In the discussions leading up to this, we tried very hard to make this
> arm64/acpi quirks mechanism just as flexible as we need it to be to
> cover the current crop of incompatible hardware, but not more so.
> Going forward, we intend to require all arm64/acpi hardware to be spec
> compliant, and so any parametrization beyond what is required for the
> currently known broken hardware is only going to make it easier for
> others to ship with tweaked ACPI descriptions so that an existing
> quirk is triggered for hardware that it was not intended for. It also
> implies that we have to deal with the ACPI descriptions as they were
> shipped with the current hardware.
>
> That does not mean, of course, that we should use bare constants
> rather than symbolic ones, but anything beyond that exceeds the
> desired scope of quirks handling.
Symbolic vs bare constants is the least of my worries. I'm pretty
happy with the current quirk implementation. It's pretty simple and
straightforward.
Apparently you shipped broken firmware that doesn't accurately
describe system resource usage. Presumably that firmware could be
updated, but maybe it's worthwhile to work around it in the kernel,
depending on where it got shipped.
I'd like to step back and come up with some understanding of how
non-broken firmware *should* deal with this issue. Then, if we *do*
work around this particular broken firmware in the kernel, it would be
nice to do it in a way that fits in with that understanding.
For example, if a companion ACPI device is the preferred solution, an
ACPI quirk could fabricate a device with the required resources. That
would address the problem closer to the source and make it more likely
that the rest of the system will work correctly: /proc/iomem could
make sense, things that look at _CRS generically would work (e.g,
/sys/, an admittedly hypothetical "lsacpi", etc.)
Hard-coding stuff in drivers is a point solution that doesn't provide
any guidance for future platforms and makes it likely that the hack
will get copied into even more drivers.
Bjorn
^ permalink raw reply
* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Thomas Gleixner @ 2016-09-20 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c2c8ad5f-e679-8522-808f-e940b8c6954d@st.com>
On Tue, 20 Sep 2016, Alexandre Torgue wrote:
> On 09/20/2016 02:44 PM, Thomas Gleixner wrote:
> > Free will be called when a interrupt in the child domain is torn down,
> > i.e. when irq_domain_free_irqs() is called. And it will be called for both
> > domains like the alloc callback is invoked on both domains via
> > irq_domain_alloc_irqs().
>
> Thanks Thomas for this clarification (I'm sure now that we need .free
> callbacks).
> irq_domain_free_irqs() is called in 2 scenario:
> 1- when issue occurs in irq_create_fwspec_mapping()
> 2- when irq_dispose_mapping() is called
>
> Case 2 is the one I tested some times ago. In this case, I need to mask
> interrupts in .free callback of EXTI (parent) domain to avoid spurious
> interrupts.
And why would irq_dispose_mapping() be called on an unmasked, i.e. active,
interrupt? The masking is just papering over that.
Thanks,
tglx
^ permalink raw reply
* [PATCH v2 4/6] net: ethernet: bgmac: convert to feature flags
From: Jon Mason @ 2016-09-20 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6rymVcKV1h_PEvRuCQrtOd4rsqV34bMWzVOof15fdc8KEA@mail.gmail.com>
On Tue, Sep 20, 2016 at 1:19 AM, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> On 17 August 2016 at 13:34, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>> On 8 July 2016 at 01:08, Jon Mason <jon.mason@broadcom.com> wrote:
>>> mode = (bgmac_read(bgmac, BGMAC_DEV_STATUS) & BGMAC_DS_MM_MASK) >>
>>> BGMAC_DS_MM_SHIFT;
>>> - if (ci->id != BCMA_CHIP_ID_BCM47162 || mode != 0)
>>> + if (bgmac->feature_flags & BGMAC_FEAT_CLKCTLST || mode != 0)
>>> bgmac_set(bgmac, BCMA_CLKCTLST, BCMA_CLKCTLST_FORCEHT);
>>> - if (ci->id == BCMA_CHIP_ID_BCM47162 && mode == 2)
>>> + if (bgmac->feature_flags & BGMAC_FEAT_CLKCTLST && mode == 2)
>>> bcma_chipco_chipctl_maskset(&bgmac->core->bus->drv_cc, 1, ~0,
>>> BGMAC_CHIPCTL_1_RXC_DLL_BYPASS);
>>
>> Jon, it looks to me you translated two following conditions:
>> ci->id != BCMA_CHIP_ID_BCM47162
>> and
>> ci->id == BCMA_CHIP_ID_BCM47162
>> into the same flag check:
>> bgmac->feature_flags & BGMAC_FEAT_CLKCTLST
>>
>> I don't think it's intentional, is it? Do you have a moment to fix this?
>
> Ping
Sorry, just seeing this now. I'll double check the original code and
verify it (or fix it).
Thanks,
Jon
>
> --
> Rafa?
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Ard Biesheuvel @ 2016-09-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920133327.GB13855@localhost>
On 20 September 2016 at 14:33, Bjorn Helgaas <helgaas@kernel.org> wrote:
> [+cc Rafael (maybe already cc'd; I didn't recognize rafael at kernel.org, Duc]
>
> On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz Nowicki wrote:
>> On 19.09.2016 20:09, Bjorn Helgaas wrote:
>> >On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
>> >>thunder-pem driver stands for being ACPI based PCI host controller.
>> >>However, there is no standard way to describe its PEM-specific register
>> >>ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension
>> >>to obtain hardcoded addresses from static resource array.
>> >>Although it is not pretty, it prevents from creating standard mechanism to
>> >>handle similar cases in future.
>> >>
>> >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> >>---
>> >> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++--------
>> >> 1 file changed, 48 insertions(+), 13 deletions(-)
>> >>
>> >>diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
>> >>index 6abaf80..b048761 100644
>> >>--- a/drivers/pci/host/pci-thunder-pem.c
>> >>+++ b/drivers/pci/host/pci-thunder-pem.c
>> >>@@ -18,6 +18,7 @@
>> >> #include <linux/init.h>
>> >> #include <linux/of_address.h>
>> >> #include <linux/of_pci.h>
>> >>+#include <linux/pci-acpi.h>
>> >> #include <linux/pci-ecam.h>
>> >> #include <linux/platform_device.h>
>> >>
>> >>@@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
>> >> return pci_generic_config_write(bus, devfn, where, size, val);
>> >> }
>> >>
>> >>+#ifdef CONFIG_ACPI
>> >>+static struct resource thunder_pem_reg_res[] = {
>> >>+ [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M),
>> >>+ [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M),
>> >>+ [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M),
>> >>+ [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M),
>> >>+ [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M),
>> >>+ [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M),
>> >>+ [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M),
>> >>+ [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M),
>> >>+ [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M),
>> >>+ [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M),
>> >>+ [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M),
>> >>+ [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M),
>> >
>> >1) The "correct" way to discover the resources consumed by an ACPI
>> > device is to use the _CRS method. I know there are some issues
>> > there for bridges (not the fault of ThunderX!) because there's not
>> > a good way to distinguish windows from resources consumed directly
>> > by the bridge.
>> >
>> > But we should either do this correctly, or include a comment about
>> > why we're doing it wrong, so we don't give the impression that this
>> > is the right way to do it.
>> >
>> > I seem to recall some discussion about why we're doing it this way,
>> > but I don't remember the details. It'd be nice to include a
>> > summary here.
>>
>> OK I will. The reason why we cannot use _CRS for this case is that
>> CONSUMER flag was not use consistently for the bridge so far.
>
> Yes, I'm aware of that problem, but hard-coding resources into drivers
> is just a disaster. The PCI and ACPI cores need generic ways to learn
> what resources are consumed by devices. For PCI devices, that's done
> with BARs. For ACPI devices, it's done with _CRS. Without generic
> resource discovery, we can't manage resources reliably at the system
> level [1].
>
> You have a PNP0A03/PNP0A08 device for the PCI host bridge. Because of
> the BIOS bugs in CONSUMER flag usage, we assume everything in its _CRS
> is a window and not consumed by the bridge itself. What if you added
> a companion ACPI device with a _CRS that contained the bridge
> resources? Then you'd have some driver ugliness to find that device,
> but at least the ACPI core could tell what resources were in use.
>
> Maybe Rafael has a better idea?
>
In the discussions leading up to this, we tried very hard to make this
arm64/acpi quirks mechanism just as flexible as we need it to be to
cover the current crop of incompatible hardware, but not more so.
Going forward, we intend to require all arm64/acpi hardware to be spec
compliant, and so any parametrization beyond what is required for the
currently known broken hardware is only going to make it easier for
others to ship with tweaked ACPI descriptions so that an existing
quirk is triggered for hardware that it was not intended for. It also
implies that we have to deal with the ACPI descriptions as they were
shipped with the current hardware.
That does not mean, of course, that we should use bare constants
rather than symbolic ones, but anything beyond that exceeds the
desired scope of quirks handling.
--
Ard.
^ permalink raw reply
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Robert Richter @ 2016-09-20 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E11E52.8060303@linaro.org>
On 20.09.16 19:32:34, Hanjun Guo wrote:
> On 09/20/2016 06:43 PM, Robert Richter wrote:
> >Instead we need to make sure the set_*numa_node() functions are called
> >earlier before secondary cpus are booted. My suggested change for that
> >is this:
> >
> >
> >diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> >index d93d43352504..952365c2f100 100644
> >--- a/arch/arm64/kernel/smp.c
> >+++ b/arch/arm64/kernel/smp.c
> >@@ -204,7 +204,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> > static void smp_store_cpu_info(unsigned int cpuid)
> > {
> > store_cpu_topology(cpuid);
> >- numa_store_cpu_info(cpuid);
> > }
> >
> > /*
> >@@ -719,6 +718,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
> > continue;
> >
> > set_cpu_present(cpu, true);
> >+ numa_store_cpu_info(cpu);
> > }
> > }
>
> We tried a similar approach which add numa_store_cpu_info() in
> early_map_cpu_to_node(), and remove it from smp_store_cpu_info,
> but didn't work for us, we will try your approach to see if works.
Calling it in early_map_cpu_to_node() is probably too early since
setup_node_to_cpumask_map() is called in numa_init() afterwards
overwriting it again.
Actually, early_map_cpu_to_node() is used to temporarily store the
mapping until it can be setup in numa_store_cpu_info().
-Robert
^ permalink raw reply
* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Alexandre Torgue @ 2016-09-20 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1609201439440.6905@nanos>
Thomas,
On 09/20/2016 02:44 PM, Thomas Gleixner wrote:
> On Tue, 20 Sep 2016, Alexandre Torgue wrote:
>
>> Thomas,
>>
>> On 09/20/2016 11:51 AM, Thomas Gleixner wrote:
>>> On Tue, 20 Sep 2016, Alexandre Torgue wrote:
>>>>> On 09/14/2016 03:34 PM, Thomas Gleixner wrote:
>>>>>> Well, you just used some function in some context which is not
>>>>>> relevant to
>>>>>> the normal operation. So adding that mask() is just paranoia for no
>>>>>> value.
>>>>>
>>>> A gentle reminder ping...
>>>> If ".free" callback is not relevant then I 'll remove it from exti domain.
>>
>> Sorry for discussing about the same thing again (and again) but I just want to
>> be sure before sending a new version. As you know I have 2 domains: EXTI
>> domain (parent) and stm32-pinctrl-bank domain (child one).
>>
>> There does it make sens to have ".free" callbacks defined in both domain
>> (actually if I define one for the child domain I have to define also ".free"
>> callback for parent domain (EXTI) as it is hierarchical) ?
>> If ".free" have no chance to be called then I will send a new version by
>> removing .free callbacks (in both domain).
>
> Free will be called when a interrupt in the child domain is torn down,
> i.e. when irq_domain_free_irqs() is called. And it will be called for both
> domains like the alloc callback is invoked on both domains via
> irq_domain_alloc_irqs().
Thanks Thomas for this clarification (I'm sure now that we need .free
callbacks).
irq_domain_free_irqs() is called in 2 scenario:
1- when issue occurs in irq_create_fwspec_mapping()
2- when irq_dispose_mapping() is called
Case 2 is the one I tested some times ago. In this case, I need to mask
interrupts in .free callback of EXTI (parent) domain to avoid spurious
interrupts.
Regards
Alex
>
> Thanks,
>
> tglx
>
>
>
>
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-20 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com>
[+cc Rafael (maybe already cc'd; I didn't recognize rafael at kernel.org, Duc]
On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz Nowicki wrote:
> On 19.09.2016 20:09, Bjorn Helgaas wrote:
> >On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
> >>thunder-pem driver stands for being ACPI based PCI host controller.
> >>However, there is no standard way to describe its PEM-specific register
> >>ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension
> >>to obtain hardcoded addresses from static resource array.
> >>Although it is not pretty, it prevents from creating standard mechanism to
> >>handle similar cases in future.
> >>
> >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> >>---
> >> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++--------
> >> 1 file changed, 48 insertions(+), 13 deletions(-)
> >>
> >>diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> >>index 6abaf80..b048761 100644
> >>--- a/drivers/pci/host/pci-thunder-pem.c
> >>+++ b/drivers/pci/host/pci-thunder-pem.c
> >>@@ -18,6 +18,7 @@
> >> #include <linux/init.h>
> >> #include <linux/of_address.h>
> >> #include <linux/of_pci.h>
> >>+#include <linux/pci-acpi.h>
> >> #include <linux/pci-ecam.h>
> >> #include <linux/platform_device.h>
> >>
> >>@@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
> >> return pci_generic_config_write(bus, devfn, where, size, val);
> >> }
> >>
> >>+#ifdef CONFIG_ACPI
> >>+static struct resource thunder_pem_reg_res[] = {
> >>+ [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M),
> >>+ [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M),
> >>+ [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M),
> >>+ [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M),
> >>+ [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M),
> >>+ [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M),
> >>+ [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M),
> >>+ [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M),
> >>+ [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M),
> >>+ [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M),
> >>+ [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M),
> >>+ [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M),
> >
> >1) The "correct" way to discover the resources consumed by an ACPI
> > device is to use the _CRS method. I know there are some issues
> > there for bridges (not the fault of ThunderX!) because there's not
> > a good way to distinguish windows from resources consumed directly
> > by the bridge.
> >
> > But we should either do this correctly, or include a comment about
> > why we're doing it wrong, so we don't give the impression that this
> > is the right way to do it.
> >
> > I seem to recall some discussion about why we're doing it this way,
> > but I don't remember the details. It'd be nice to include a
> > summary here.
>
> OK I will. The reason why we cannot use _CRS for this case is that
> CONSUMER flag was not use consistently for the bridge so far.
Yes, I'm aware of that problem, but hard-coding resources into drivers
is just a disaster. The PCI and ACPI cores need generic ways to learn
what resources are consumed by devices. For PCI devices, that's done
with BARs. For ACPI devices, it's done with _CRS. Without generic
resource discovery, we can't manage resources reliably at the system
level [1].
You have a PNP0A03/PNP0A08 device for the PCI host bridge. Because of
the BIOS bugs in CONSUMER flag usage, we assume everything in its _CRS
is a window and not consumed by the bridge itself. What if you added
a companion ACPI device with a _CRS that contained the bridge
resources? Then you'd have some driver ugliness to find that device,
but at least the ACPI core could tell what resources were in use.
Maybe Rafael has a better idea?
Bjorn
[1] I know the ACPI core currently doesn't actually *do* anything with
_CRS. But I think it *should*, and someday it might, so I want to
preserve the principle of using _CRS to document all the resources.
^ permalink raw reply
* [PATCH] tty: amba-pl011: uart_amba_port is not available with earlycon function
From: Shawn Guo @ 2016-09-20 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f503859-0bf3-e031-450b-2597d93e05ce@arm.com>
On Tue, Sep 20, 2016 at 9:15 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Anyways I have now tested it, so you can add:
> Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Sorry for the regression, and thanks much for the effort of issue
reporting and testing.
Shawn
^ 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