* [PATCH v5] KVM: arm/arm64: Route vtimer events to user space
From: Alexander Graf @ 2016-09-23 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63a1e3a2-f551-017f-b6be-593b53a0b407@redhat.com>
On 23.09.16 10:57, Paolo Bonzini wrote:
>
>
> On 23/09/2016 09:14, Alexander Graf wrote:
>>>> +/*
>>>> + * Synchronize the timer IRQ state with the interrupt controller.
>>>> + */
>>>> static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
>>>> {
>>>> int ret;
>>>> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>>>
>>>> timer->active_cleared_last = false;
>>>> timer->irq.level = new_level;
>>>> - trace_kvm_timer_update_irq(vcpu->vcpu_id, timer->irq.irq,
>>>> + trace_kvm_timer_update_irq(vcpu->vcpu_id, host_vtimer_irq,
>>>> timer->irq.level);
>>>> + [...]
>>>> + struct kvm_sync_regs *regs = &vcpu->run->s.regs;
>>>> +
>>>> + /* Populate the timer bitmap for user space */
>>>> + regs->kernel_timer_pending &= ~KVM_ARM_TIMER_VTIMER;
>>>> + if (new_level)
>>>> + regs->kernel_timer_pending |= KVM_ARM_TIMER_VTIMER;
>>>
>>> I think if you got here, it means you have to exit to userspace to
>>> update it of the new state. If you don't want to propagate a return
>>
>> Yes, but we can't exit straight away with our own exit reason because we
>> might be inside an MMIO exit path here which already occupies the
>> exit_reason.
>
> So the idea is that whenever you're here you have one of the following
> cases:
>
> - are coming from kvm_timer_flush_hwstate, and then you exit immediately
> with KVM_EXIT_INTR if needed
>
> - you are coming from the kvm_timer_sync_hwstate just before
> handle_exit. Then if there's a vmexit you have already set
> regs->kernel_timer_pending, if not you'll do a kvm_timer_flush_hwstate soon.
>
> - you are coming from the kvm_timer_sync_hwstate in the middle of
> kvm_arch_vcpu_ioctl_run, and then "continue" will either exit the loop
> immediately (if ret <= 0) or go to kvm_timer_flush_hwstate as in the
> previous case
>
> Right?
Yup :)
>
>>> Maybe I'm misunderstanding and user_timer_pending is just a cached
>>> verison of what you said last, but as I said above, I think you can just
>>> compare timer->irq.level with the last value the kvm_run struct, and if
>>> something changed, you have to exit.
>>
>> So how would user space know whether the line went up or down? Or didn't
>> change at all (if we coalesce with an MMIO exit)?
>
> It would save the status of the line somewhere in its own variable,
> without introducing a relatively delicate API between kernel and user.
>
> I agree that you cannot update kernel_timer_pending only in
> flush_hwstate; otherwise you miss on case (2) when there is a vmexit.
> That has to stay in kvm_timer_sync_hwstate (or it could become a new
> function called at the very end of kvm_arch_vcpu_ioctl_run).
The beauty of having it in the timer update function is that it gets
called from flush_hwstate() as well. That way we catch the update also
in cases where we need it before we enter the vcpu.
> However, I'm not sure why user_timer_pending is necessary. If it is
> just the value you assigned to regs->kernel_timer_pending at the time of
> the previous vmexit, can kvm_timer_flush_hwstate just do
>
> if (timer->prev_kernel_timer_pending != regs->kernel_timer_pending) {
> timer->prev_kernel_timer_pending = regs->kernel_timer_pending;
> return 1;
> }
>
> ? Or even
>
> if (timer->prev_irq_level != timer->irq.level) {
> timer->prev_irq_level = regs->irq.level;
> return 1;
> }
>
> so that regs->kernel_timer_pending remains exclusively
> kvm_timer_sync_hwstate's business?
We could do that too, yes. But it puts more burden on user space - it
would have to ensure that it *always* checks for the pending timer
status. With this approach, user space may opt to only check for timer
state changes on -EINTR and things would still work.
Alex
^ permalink raw reply
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Linus Walleij @ 2016-09-23 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919161314.25858-2-eric@anholt.net>
On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt <eric@anholt.net> wrote:
> This driver will be used for accessing the FXL6408 GPIO exander on the
> Pi3. We can't drive it directly from Linux because the firmware is
> continuously polling one of the expander's lines to do its
> undervoltage detection.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
(...)
> +config GPIO_RASPBERRYPI
> + tristate "Raspberry Pi firmware-based GPIO access"
> + depends on OF_GPIO && RASPBERRYPI_FIRMWARE && (ARCH_BCM2835 || COMPILE_TEST)
> + help
> + Turns on support for using the Raspberry Pi firmware to
> + control GPIO pins. Used for access to the FXL6408 GPIO
> + expander on the Pi 3.
Maybe it should be named GPIO_RPI_FXL6408 ?
(No strong opinion.)
> +#include <linux/err.h>
> +#include <linux/gpio.h>
No, only #include <linux/gpio/driver.h>
> +static int rpi_gpio_dir_in(struct gpio_chip *gc, unsigned off)
> +{
> + /* We don't have direction control. */
> + return -EINVAL;
> +}
> +
> +static int rpi_gpio_dir_out(struct gpio_chip *gc, unsigned off, int val)
> +{
> + /* We don't have direction control. */
> + return -EINVAL;
> +}
IMO this should return OK if you try to set it to the direction
that the line is hardwired for in that case, not just fail everything.
If you return errors here, any generic driver that tries to
set the line as input or output will fail and then require a
second workaround in that driver if it is used on rpi etc etc.
Try to return zero if the consumer asks for the direction that
the line is set to.
Also implement .get_direction(). Doing so will show how to
do the above two calls in the right way.
> +static void rpi_gpio_set(struct gpio_chip *gc, unsigned off, int val)
> +{
> + struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
> + u32 packet[2] = { rpi->offset + off, val };
> + int ret;
> +
> + ret = rpi_firmware_property(rpi->firmware,
> + RPI_FIRMWARE_SET_GPIO_STATE,
> + &packet, sizeof(packet));
> + if (ret)
> + dev_err(rpi->dev, "Error setting GPIO %d state: %d\n", off, ret);
> +}
> +
> +static int rpi_gpio_get(struct gpio_chip *gc, unsigned off)
> +{
> + struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
> + u32 packet[2] = { rpi->offset + off, 0 };
> + int ret;
> +
> + ret = rpi_firmware_property(rpi->firmware,
> + RPI_FIRMWARE_GET_GPIO_STATE,
> + &packet, sizeof(packet));
> + if (ret) {
> + dev_err(rpi->dev, "Error getting GPIO state: %d\n", ret);
> + return ret;
> + } else if (packet[0]) {
> + dev_err(rpi->dev, "Firmware error getting GPIO state: %d\n",
> + packet[0]);
> + return -EINVAL;
> + } else {
> + return packet[1];
> + }
You can just remove the last } else { } clause and return on a
single line.
Please do it like this though:
return !!packet[1];
So you clamp the returned value to a boolean.
> +static int rpi_gpio_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *fw_node;
> + struct rpi_gpio *rpi;
> + u32 ngpio;
> + int ret;
> +
> + rpi = devm_kzalloc(dev, sizeof *rpi, GFP_KERNEL);
> + if (!rpi)
> + return -ENOMEM;
> + rpi->dev = dev;
> +
> + fw_node = of_parse_phandle(np, "firmware", 0);
> + if (!fw_node) {
> + dev_err(dev, "Missing firmware node\n");
> + return -ENOENT;
> + }
> +
> + rpi->firmware = rpi_firmware_get(fw_node);
> + if (!rpi->firmware)
> + return -EPROBE_DEFER;
> +
> + if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpio)) {
> + dev_err(dev, "Missing ngpios");
> + return -ENOENT;
> + }
This is suspect you could skip and just hardcode to 8.
> + if (of_property_read_u32(pdev->dev.of_node,
> + "raspberrypi,firmware-gpio-offset",
> + &rpi->offset)) {
> + dev_err(dev, "Missing raspberrypi,firmware-gpio-offset");
> + return -ENOENT;
> + }
Can't you just hardcode this into the driver as well?
> + rpi->gc.label = np->full_name;
> + rpi->gc.owner = THIS_MODULE;
> + rpi->gc.of_node = np;
> + rpi->gc.ngpio = ngpio;
> + rpi->gc.direction_input = rpi_gpio_dir_in;
> + rpi->gc.direction_output = rpi_gpio_dir_out;
Implement .get_direction()
> + rpi->gc.get = rpi_gpio_get;
> + rpi->gc.set = rpi_gpio_set;
> + rpi->gc.can_sleep = true;
> +
> + ret = gpiochip_add(&rpi->gc);
> + if (ret)
> + return ret;
Use devm_gpiochip_add_data() and pass NULL as data
so you can still use the devm* function.
> + platform_set_drvdata(pdev, rpi);
Should not be needed after that.
> + return 0;
> +}
> +
> +static int rpi_gpio_remove(struct platform_device *pdev)
> +{
> + struct rpi_gpio *rpi = platform_get_drvdata(pdev);
> +
> + gpiochip_remove(&rpi->gc);
> +
> + return 0;
> +}
Should be possible to drop after using devm_gpiochip_add_data()
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
> index 3fb357193f09..671ccd00aea2 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -73,11 +73,13 @@ enum rpi_firmware_property_tag {
> RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE = 0x00030014,
> RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
> RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
> + RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
> RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
> RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
> RPI_FIRMWARE_SET_VOLTAGE = 0x00038003,
> RPI_FIRMWARE_SET_TURBO = 0x00038009,
> RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
> + RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
Can you please merge this orthogonally into the rpi tree to ARM SoC?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5] KVM: arm/arm64: Route vtimer events to user space
From: Christoffer Dall @ 2016-09-23 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d90f04d4-b29f-f08e-df39-ec307af44225@suse.de>
On Fri, Sep 23, 2016 at 09:14:13AM +0200, Alexander Graf wrote:
>
>
> On 22.09.16 23:28, Christoffer Dall wrote:
> > On Thu, Sep 22, 2016 at 02:52:49PM +0200, 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 syncing user space's view of the vtimer irq line
> >> with the kvm view of that same line.
> >>
> >> 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
> >>
> >> v4 -> v5:
> >>
> >> - Rewrite to use pending state sync in sregs (marc)
> >> - Remove redundant checks of vgic_initialized()
> >> - qemu tree to try this out: https://github.com/agraf/u-boot.git no-kvm-irqchip-for-v5
> >
> > huh, qemu=u-boot?
>
> Bleks, qemu.git of course.
>
> >
> >> ---
> >> Documentation/virtual/kvm/api.txt | 26 ++++++++
> >> arch/arm/include/uapi/asm/kvm.h | 3 +
> >> arch/arm/kvm/arm.c | 14 ++---
> >> arch/arm64/include/uapi/asm/kvm.h | 3 +
> >> include/kvm/arm_arch_timer.h | 2 +-
> >> include/uapi/linux/kvm.h | 6 ++
> >> virt/kvm/arm/arch_timer.c | 129 ++++++++++++++++++++++++++------------
> >> 7 files changed, 134 insertions(+), 49 deletions(-)
> >>
> >> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> >> index 739db9a..8049327 100644
> >> --- a/Documentation/virtual/kvm/api.txt
> >> +++ b/Documentation/virtual/kvm/api.txt
> >> @@ -3928,3 +3928,29 @@ In order to use SynIC, it has to be activated by setting this
> >> capability via KVM_ENABLE_CAP ioctl on the vcpu fd. Note that this
> >> will disable the use of APIC hardware virtualization even if supported
> >> by the CPU, as it's incompatible with SynIC auto-EOI behavior.
> >> +
> >> +8.3 KVM_CAP_ARM_TIMER
> >> +
> >> +Architectures: arm, arm64
> >> +This capability, if KVM_CHECK_EXTENSION indicates that it is available and no
> >> +in-kernel interrupt controller is in use, means that that the kernel populates
> >> +the vcpu's run->s.regs.kernel_timer_pending field with timers that are currently
> >> +considered pending by kvm.
> >
> > Be careful with the word 'pending' here. I think this could be
> > misleading, because pending is a state in the GIC, but not really
> > something I can find specific to the timer. It would be more
> > descriptive to say that the kernel maintained generic timer's output
> > signal is asserted.
>
> Sure, asserted works for me. Or maybe istatus?
>
I think the concept that most closely describes the generic timer
architecture talks about 'asserting the timer output signal', so I'd
rather we stick to something as close to that as possible.
> >
> >> +
> >> +If active, it also allows user space to propagate its own pending state of timer
> >> +interrupt lines using run->s.regs.user_timer_pending. If those two fields
> >> +mismatch during CPU execution, kvm will exit to user space to give it a chance
> >
> > I don't quite understand the semantics here. The only entity that knows
> > what the level state of the output of the timer is, is the kernel, which
> > emulates the timer. Userspace knows interrupt controller state, but if
> > it has a different view of the timer state than the kernel, it's because
> > the kernel failed to notify userspace of a change or userspace failed to
> > listen?
>
> Right, and the reason we have 2 fields is to get us exit-less (and
> easier) updates whenever we can. In most cases, taking the assertion
> down will coincide with an MMIO exit to user space for an EOI for example.
The assertion of the timer output signal is a completely separate
concept from an EOI. Most often, the signal will be deasserted *before*
the EOI, but only noticed when you trap for the EOI. Just to make that
distinction clear.
>
> Somewhere in between in the development I had a version that explicitly
> triggered a KVM_EXIT for every state change of the timer. But that gets
> messy very quickly. You need to update the state change before an MMIO
> for example, otherwise a sequence like
>
> * set cval to future (which in turns sets istatus=0)
> * read gic pending state
>
> will give you bogus results, as the mmio read to user space did not yet
> have the timer status updated. And I really didn't want to wrap my head
> around restarting MMIO exits ;).
>
> So having this side channel where user space potentially expects a timer
> status change on every exit is much cleaner.
>
Eh, I'm confused. I'm not arguing against the side channel, I
completely agree that this is a reasonable approach: Always just tell
userspace what the timer output level is, no matter why you exit.
What I don't understand is why userspace have to tell the kernel
anything back. The kernel already knows what the state is, and if
userspace forgot what it was told, it did something wrong.
> >
> >> +to update its own interrupt pending status. This usually involves triggering
> >> +an interrupt line on a user space emulated interrupt controller.
> >
> > To me it feels like the semantics should be that userspace can always
> > derive the status of the timer and the level of the output signal from
> > the timer by simply looking at kvm_run structure.
>
> Yes, it can, and it does. That's what the "kernel_timer_pending" field is.
>
> The kernel however also needs to know whether user space's view is in
> sync, because we don't know whether there was an exit between our
> internal state change and the guest entry.
Yes we do, whenever we notice that the computed state is changing (this
is exactly when we call kvm_timer_update_irq), then we will update
timer->irq.level and we will notice that there's now a deviation between
what we last told userspace (kernel_timer_pending) and the current
state, so we update kernel_timer_pending and force an exit to userspace.
Why should we care if userspace has derived something in the mean time
(which I don't even see how it can)?
> That's what the
> "user_timer_pending" field is for.
>
I don't understand the semantics of this field.
Perhaps you can explain me which hardware state (line etc.) this field
represents?
> >
> > The remaining two problems are:
> >
> > (1) when should the kernel trigger exits to userspace? Presumably on
> > any change in the timer's output level, because this change has to be
> > propagated to the userspace interrupt controller.
>
> Yes, but if we can we want to piggy-back on an existing exit.
>
never argued against that.
> > (2) the kernel needs to somehow mask the underlying hardware timer
> > interrupt signal when it's active, because otherwise the guest won't
> > proceed. If we simply mask the hardware signal after telling userspace
> > the output signal is asserted and until the output signal ever becomes
> > deasserted, why do we need to listen to anything userspace has to say?
>
> Because we need to make sure that the cpu IRQ line is updated before we
> enter the guest. Otherwise we might get spurious interrupts.
>
This doesn't mean we need to listen to what userspace says, we just have
to exit to userspace with the updated value before re-entering the
guest.
You shoudl have the exact same semantics between the arch timer and the
gic and between the arch timer and the userspace irqchip: Before
entering the guest, the kernel arch timer code needs to notify the
irqchip (whereever that lives) of a state change.
We've had all sorts of other schemes in the past and they just kept on
breaking for weirdo corner cases. The only thing that works here is to
maintain the semantics of the architecture.
> >> +
> >> +The fields run->s.regs.kernel_timer_pending and run->s.regs.user_timer_pending
> >> +are available independent of run->kvm_valid_regs or run->kvm_dirty_regs bits.
> >> +If no in-kernel interrupt controller is used and the capability exists, they
> >> +will always be available and used.
> >> +
> >> +Currently the following bits are defined for both bitmaps:
> >> +
> >> + KVM_ARM_TIMER_VTIMER - virtual timer
> >> +
> >> +Future versions of kvm may implement additional timer events. These will get
> >> +indicated by additional KVM_CAP extensions.
> >> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
> >> index a2b3eb3..caad81d 100644
> >> --- a/arch/arm/include/uapi/asm/kvm.h
> >> +++ b/arch/arm/include/uapi/asm/kvm.h
> >> @@ -105,6 +105,9 @@ struct kvm_debug_exit_arch {
> >> };
> >>
> >> struct kvm_sync_regs {
> >> + /* Used with KVM_CAP_ARM_TIMER */
> >> + u8 kernel_timer_pending;
> >> + u8 user_timer_pending;
> >> };
> >>
> >> struct kvm_arch_memory_slot {
> >> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> >> index 75f130e..dc19221 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;
> >> }
> >> @@ -588,7 +583,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> >> */
> >> preempt_disable();
> >> kvm_pmu_flush_hwstate(vcpu);
> >> - kvm_timer_flush_hwstate(vcpu);
> >> + if (kvm_timer_flush_hwstate(vcpu)) {
> >> + ret = -EINTR;
> >> + run->exit_reason = KVM_EXIT_INTR;
> >> + }
> >> kvm_vgic_flush_hwstate(vcpu);
> >>
> >> local_irq_disable();
> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> >> index 3051f86..9aac860 100644
> >> --- a/arch/arm64/include/uapi/asm/kvm.h
> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
> >> @@ -143,6 +143,9 @@ struct kvm_debug_exit_arch {
> >> #define KVM_GUESTDBG_USE_HW (1 << 17)
> >>
> >> struct kvm_sync_regs {
> >> + /* Used with KVM_CAP_ARM_TIMER */
> >> + u8 kernel_timer_pending;
> >> + u8 user_timer_pending;
> >> };
> >>
> >> struct kvm_arch_memory_slot {
> >> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> >> index dda39d8..8cd7240 100644
> >> --- a/include/kvm/arm_arch_timer.h
> >> +++ b/include/kvm/arm_arch_timer.h
> >> @@ -63,7 +63,7 @@ void kvm_timer_init(struct kvm *kvm);
> >> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> >> const struct kvm_irq_level *irq);
> >> void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
> >> -void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
> >> +int kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
> >> void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> >> void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu);
> >>
> >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> >> index 300ef25..1fc02d7 100644
> >> --- a/include/uapi/linux/kvm.h
> >> +++ b/include/uapi/linux/kvm.h
> >> @@ -870,6 +870,7 @@ struct kvm_ppc_smmu_info {
> >> #define KVM_CAP_S390_USER_INSTR0 130
> >> #define KVM_CAP_MSI_DEVID 131
> >> #define KVM_CAP_PPC_HTM 132
> >> +#define KVM_CAP_ARM_TIMER 133
> >>
> >> #ifdef KVM_CAP_IRQ_ROUTING
> >>
> >> @@ -1327,4 +1328,9 @@ struct kvm_assigned_msix_entry {
> >> #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0)
> >> #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1)
> >>
> >> +/* Available with KVM_CAP_ARM_TIMER */
> >> +
> >> +/* Bits for run->s.regs.{user,kernel}_timer_pending */
> >> +#define KVM_ARM_TIMER_VTIMER (1 << 0)
> >> +
> >> #endif /* __LINUX_KVM_H */
> >> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> >> index 4309b60..0c6fc38 100644
> >> --- a/virt/kvm/arm/arch_timer.c
> >> +++ b/virt/kvm/arm/arch_timer.c
> >> @@ -166,21 +166,36 @@ bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
> >> return cval <= now;
> >> }
> >>
> >> +/*
> >> + * Synchronize the timer IRQ state with the interrupt controller.
> >> + */
> >> static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
> >> {
> >> int ret;
> >> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> >>
> >> - BUG_ON(!vgic_initialized(vcpu->kvm));
> >> -
> >> timer->active_cleared_last = false;
> >> timer->irq.level = new_level;
> >> - trace_kvm_timer_update_irq(vcpu->vcpu_id, timer->irq.irq,
> >> + trace_kvm_timer_update_irq(vcpu->vcpu_id, host_vtimer_irq,
> >> timer->irq.level);
> >> - ret = kvm_vgic_inject_mapped_irq(vcpu->kvm, vcpu->vcpu_id,
> >> - timer->irq.irq,
> >> - timer->irq.level);
> >> - WARN_ON(ret);
> >> +
> >> + if (irqchip_in_kernel(vcpu->kvm)) {
> >> + BUG_ON(!vgic_initialized(vcpu->kvm));
> >> +
> >> + /* Fire the timer in the VGIC */
> >> + ret = kvm_vgic_inject_mapped_irq(vcpu->kvm, vcpu->vcpu_id,
> >> + timer->irq.irq,
> >> + timer->irq.level);
> >> +
> >> + WARN_ON(ret);
> >> + } else {
> >> + struct kvm_sync_regs *regs = &vcpu->run->s.regs;
> >> +
> >> + /* Populate the timer bitmap for user space */
> >> + regs->kernel_timer_pending &= ~KVM_ARM_TIMER_VTIMER;
> >> + if (new_level)
> >> + regs->kernel_timer_pending |= KVM_ARM_TIMER_VTIMER;
> >
> > I think if you got here, it means you have to exit to userspace to
> > update it of the new state. If you don't want to propagate a return
>
> Yes, but we can't exit straight away with our own exit reason because we
> might be inside an MMIO exit path here which already occupies the
> exit_reason.
>
> > value from here, I think you should just not do anything an then later
> > compare timer->irq.level with whatever was last written to
> > run->kernel_timer_pending (which should be named something else than
> > pending).
>
> Hm, so you're saying we should just update kernel_timer_pending in
> flush_hwstate()? That way we miss out on the piggy backing, no?
>
I don't see why. What I had in mind was something like this (untested,
incomplete, pseudo-code'ish):
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 85a3f90..a78ce7d 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -549,7 +549,7 @@ static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
*/
int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
- int ret;
+ int ret, timer_ret;
sigset_t sigsaved;
if (unlikely(!kvm_vcpu_initialized(vcpu)))
@@ -588,7 +588,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
*/
preempt_disable();
kvm_pmu_flush_hwstate(vcpu);
- kvm_timer_flush_hwstate(vcpu);
+ timer_ret = kvm_timer_flush_hwstate(vcpu);
kvm_vgic_flush_hwstate(vcpu);
local_irq_disable();
@@ -596,7 +596,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
/*
* Re-check atomic conditions
*/
- if (signal_pending(current)) {
+ if (timer_ret || signal_pending(current)) {
ret = -EINTR;
run->exit_reason = KVM_EXIT_INTR;
}
@@ -659,13 +659,17 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
* interrupt line.
*/
kvm_pmu_sync_hwstate(vcpu);
- kvm_timer_sync_hwstate(vcpu);
+ timer_ret = kvm_timer_sync_hwstate(vcpu);
kvm_vgic_sync_hwstate(vcpu);
preempt_enable();
ret = handle_exit(vcpu, run, ret);
+ if (!ret & timer_ret) {
+ ret = -EINTR;
+ run->exit_reason = KVM_EXIT_INTR;
+ }
}
if (vcpu->sigset_active)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 27a1f63..0f7c23d 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -242,6 +242,19 @@ void kvm_timer_unschedule(struct kvm_vcpu *vcpu)
timer_disarm(timer);
}
+static int kvm_timer_update_user_irqchip(struct kvm_vcpu *vcpu)
+{
+ struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+ struct kvm_sync_regs *regs = &vcpu->run->s.regs;
+
+ if (irqchip_in_kernel(vcpu->kvm))
+ return 0;
+
+ if (timer->irq.level != (regs->kernel_timer_pending & KVM_ARM_TIMER_VTIMER))
+ return 1;
+ return 0;
+}
+
/**
* kvm_timer_flush_hwstate - prepare to move the virt timer to the cpu
* @vcpu: The vcpu pointer
@@ -258,6 +271,11 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
if (kvm_timer_update_state(vcpu))
return;
+ if (!irqchip_in_kernel(vcpu->kvm)) {
+ /* do your masking here */
+ return kvm_timer_update_user_irqchip(vcpu);
+ }
+
/*
* If we enter the guest with the virtual input level to the VGIC
* asserted, then we have already told the VGIC what we need to, and
@@ -315,8 +333,10 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
*
* Check if the virtual timer has expired while we were running in the guest,
* and inject an interrupt if that was the case.
+ *
+ * Return 1 to force exit to userspace, 0 otherwise.
*/
-void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
+int kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
@@ -327,6 +347,8 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
* could have expired, update the timer state.
*/
kvm_timer_update_state(vcpu);
+
+ return kvm_timer_update_user_irqchip(vcpu);
}
int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> >
> >> + }
> >> }
> >>
> >> /*
> >> @@ -197,7 +212,8 @@ static int kvm_timer_update_state(struct kvm_vcpu *vcpu)
> >> * because the guest would never see the interrupt. Instead wait
> >> * until we call this function from kvm_timer_flush_hwstate.
> >> */
> >> - if (!vgic_initialized(vcpu->kvm) || !timer->enabled)
> >> + if ((irqchip_in_kernel(vcpu->kvm) && !vgic_initialized(vcpu->kvm)) ||
> >> + !timer->enabled)
> >> return -ENODEV;
> >>
> >> if (kvm_timer_should_fire(vcpu) != timer->irq.level)
> >> @@ -248,15 +264,20 @@ void kvm_timer_unschedule(struct kvm_vcpu *vcpu)
> >> *
> >> * Check if the virtual timer has expired while we were running in the host,
> >> * and inject an interrupt if that was the case.
> >> + *
> >> + * Returns:
> >> + *
> >> + * 0 - success
> >> + * 1 - need exit to user space
> >
> > this is opposite to all other exit-related APIs we have. Why not just
> > return -EINTR?
>
> All functions in the arch timer file are in normal C API notion
> (0=success). I actually had it all in exit-related API notion at first
> and it became very awkward and hard to read to convert exit codes in
> between. Doing it just once in kvm.c felt much cleaner.
>
ok, that's fair.
> >
> >> */
> >> -void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
> >> +int kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
> >> {
> >> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> >> bool phys_active;
> >> int ret;
> >>
> >> if (kvm_timer_update_state(vcpu))
> >> - return;
> >> + return 0;
> >>
> >> /*
> >> * If we enter the guest with the virtual input level to the VGIC
> >> @@ -275,38 +296,61 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
> >> * to ensure that hardware interrupts from the timer triggers a guest
> >> * exit.
> >> */
> >> - phys_active = timer->irq.level ||
> >> - kvm_vgic_map_is_active(vcpu, timer->irq.irq);
> >> -
> >> - /*
> >> - * We want to avoid hitting the (re)distributor as much as
> >> - * possible, as this is a potentially expensive MMIO access
> >> - * (not to mention locks in the irq layer), and a solution for
> >> - * this is to cache the "active" state in memory.
> >> - *
> >> - * Things to consider: we cannot cache an "active set" state,
> >> - * because the HW can change this behind our back (it becomes
> >> - * "clear" in the HW). We must then restrict the caching to
> >> - * the "clear" state.
> >> - *
> >> - * The cache is invalidated on:
> >> - * - vcpu put, indicating that the HW cannot be trusted to be
> >> - * in a sane state on the next vcpu load,
> >> - * - any change in the interrupt state
> >> - *
> >> - * Usage conditions:
> >> - * - cached value is "active clear"
> >> - * - value to be programmed is "active clear"
> >> - */
> >> - if (timer->active_cleared_last && !phys_active)
> >> - return;
> >> -
> >> - ret = irq_set_irqchip_state(host_vtimer_irq,
> >> - IRQCHIP_STATE_ACTIVE,
> >> - phys_active);
> >> - WARN_ON(ret);
> >> + if (irqchip_in_kernel(vcpu->kvm)) {
> >> + phys_active = timer->irq.level ||
> >> + kvm_vgic_map_is_active(vcpu, timer->irq.irq);
> >> +
> >> + /*
> >> + * We want to avoid hitting the (re)distributor as much as
> >> + * possible, as this is a potentially expensive MMIO access
> >> + * (not to mention locks in the irq layer), and a solution for
> >> + * this is to cache the "active" state in memory.
> >> + *
> >> + * Things to consider: we cannot cache an "active set" state,
> >> + * because the HW can change this behind our back (it becomes
> >> + * "clear" in the HW). We must then restrict the caching to
> >> + * the "clear" state.
> >> + *
> >> + * The cache is invalidated on:
> >> + * - vcpu put, indicating that the HW cannot be trusted to be
> >> + * in a sane state on the next vcpu load,
> >> + * - any change in the interrupt state
> >> + *
> >> + * Usage conditions:
> >> + * - cached value is "active clear"
> >> + * - value to be programmed is "active clear"
> >> + */
> >> + if (timer->active_cleared_last && !phys_active)
> >> + return 0;
> >> +
> >> + ret = irq_set_irqchip_state(host_vtimer_irq,
> >> + IRQCHIP_STATE_ACTIVE,
> >> + phys_active);
> >> + WARN_ON(ret);
> >> + } else {
> >> + struct kvm_sync_regs *regs = &vcpu->run->s.regs;
> >> +
> >> + /*
> >> + * User space handles timer events, so we need to check whether
> >> + * its view of the world is in sync with ours.
> >> + */
> >> + if (regs->kernel_timer_pending != regs->user_timer_pending) {
> >> + /* Return to user space */
> >> + return 1;
> >> + }
> >
> > Maybe I'm misunderstanding and user_timer_pending is just a cached
> > verison of what you said last, but as I said above, I think you can just
> > compare timer->irq.level with the last value the kvm_run struct, and if
> > something changed, you have to exit.
>
> So how would user space know whether the line went up or down? Or didn't
> change at all (if we coalesce with an MMIO exit)?
>
It just samples the line on every exit? It is free to cache the old
value if it wants to detect changes as opposed to recomputing the line
on every exit, but I don't understand why it has to feed it back to the
kernel. Surely userspace has its own per-VCPU state?
> >
> >> +
> >> + /*
> >> + * As long as user space is aware that the timer is pending,
> >> + * we do not need to get new host timer events.
> >> + */
> >
> > yes, correct, but I don't think this concept was clearly reflected in
> > your API text above.
> >
> >> + if (timer->irq.level)
> >> + disable_percpu_irq(host_vtimer_irq);
> >> + else
> >> + enable_percpu_irq(host_vtimer_irq, 0);
> >> + }
> >
> > could we move these two blocks into their own functions instead? That
> > would also give nice names to the huge chunk of complicated
> > functionality, e.g. flush_timer_state_to_user() and
> > flush_timer_state_to_vgic().
>
> That's probably a very useful cleanup, yes :).
>
>
Thanks,
-Christoffer
^ permalink raw reply related
* [PATCH v6 0/3] arm64 kexec-tools patches
From: Pratyush Anand @ 2016-09-23 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1474481332.git.geoff@infradead.org>
Hi Geoff,
On 21/09/2016:06:14:25 PM, Geoff Levand wrote:
> This series adds the core support for kexec re-boot on ARM64.
I tested this series with mustang and seattle and they work.
So you can use my "Tested-By: Pratyush Anand <panand@redhat.com>".
Just one Nitpick: In patch 2/3 arm64_header_check_msb(),
arm64_header_page_size() and arm64_header_placement() have been defined but they
have not been used anywhere. So, may be they can be removed.
~Pratyush
>
> Linux kernel support for ARM64 kexec reboot has been merged in v4.8-rc1 with the
> expectation that it will be included in the v4.8 stable kernel release.
>
> For ARM64 kdump support see Takahiro's latest kdump patches [1].
>
> [1] http://lists.infradead.org/pipermail/kexec
>
> Changes for v6 (Sep , 2016, 2m):
>
> o Remove the get_memory_ranges_dt() routine.
> o Rename dtb_[12] to dtb_{proc,sys,user}.
>
> Changes for v5 (Sep 1, 2016, 2m):
>
> o Add common routine arm64_locate_kernel_segment().
>
> Changes for v4 (Aug 18, 2016, 1m):
>
> o Fix some error return values and error messages.
> o Add enum arm64_header_page_size.
> o Rename page_offset to vp_offset.
>
> Changes for v3 (Aug 10, 2016, 1m):
>
> o Rebase to 2.0.13.
> o Add support for flag bits 1-3 to arm64 image-header.h.
> o Fix OPT_ARCH_MAX value.
> o Use fdt_pack() in dtb_set_property().
> o Remove patch ("kexec: (bugfix) calc correct end address of memory ranges in device tree").
>
> Changes for v2 (July 26, 2016, 0m):
>
> o Inline some small routines.
> o Reformat some dbgprintf messages.
> o Remove debug_brk from entry.S
> o Change arm64_image_header.flags to uint64_t.
> o Look in iomem then dt for mem info.
> o Remove check_cpu_nodes.
> o Remove purgatory printing.
>
> First submission v1 (July 20, 2016).
>
> -Geoff
>
> The following changes since commit 67488beb0a6ee8ad2c0b05f721a9e00041fab93a:
>
> kexec-tools 2.0.13 (2016-08-08 12:26:44 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git for-merge-arm64-v6
>
> for you to fetch changes up to a9f1fafd7c248d33768177438742b90bc4338202:
>
> arm64: Add support for binary image files (2016-09-21 11:04:03 -0700)
>
> ----------------------------------------------------------------
> Geoff Levand (2):
> kexec: Add common device tree routines
> arm64: Add arm64 kexec support
>
> Pratyush Anand (1):
> arm64: Add support for binary image files
>
> configure.ac | 3 +
> kexec/Makefile | 5 +
> kexec/arch/arm64/Makefile | 40 +++
> kexec/arch/arm64/crashdump-arm64.c | 21 ++
> kexec/arch/arm64/crashdump-arm64.h | 12 +
> kexec/arch/arm64/image-header.h | 146 ++++++++
> kexec/arch/arm64/include/arch/options.h | 39 ++
> kexec/arch/arm64/kexec-arm64.c | 615 ++++++++++++++++++++++++++++++++
> kexec/arch/arm64/kexec-arm64.h | 71 ++++
> kexec/arch/arm64/kexec-elf-arm64.c | 146 ++++++++
> kexec/arch/arm64/kexec-image-arm64.c | 80 +++++
> kexec/dt-ops.c | 145 ++++++++
> kexec/dt-ops.h | 13 +
> kexec/kexec-syscall.h | 8 +-
> purgatory/Makefile | 1 +
> purgatory/arch/arm64/Makefile | 18 +
> purgatory/arch/arm64/entry.S | 51 +++
> purgatory/arch/arm64/purgatory-arm64.c | 19 +
> 18 files changed, 1431 insertions(+), 2 deletions(-)
> create mode 100644 kexec/arch/arm64/Makefile
> create mode 100644 kexec/arch/arm64/crashdump-arm64.c
> create mode 100644 kexec/arch/arm64/crashdump-arm64.h
> create mode 100644 kexec/arch/arm64/image-header.h
> create mode 100644 kexec/arch/arm64/include/arch/options.h
> create mode 100644 kexec/arch/arm64/kexec-arm64.c
> create mode 100644 kexec/arch/arm64/kexec-arm64.h
> create mode 100644 kexec/arch/arm64/kexec-elf-arm64.c
> create mode 100644 kexec/arch/arm64/kexec-image-arm64.c
> create mode 100644 kexec/dt-ops.c
> create mode 100644 kexec/dt-ops.h
> create mode 100644 purgatory/arch/arm64/Makefile
> create mode 100644 purgatory/arch/arm64/entry.S
> create mode 100644 purgatory/arch/arm64/purgatory-arm64.c
>
> --
> 2.7.4
^ permalink raw reply
* [PATCH v3 0/4] regulator: axp20x: support AXP803/AXP813 variants
From: Jean-Francois Moine @ 2016-09-23 8:58 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for the X-Powers AXP803 and AXP813 PMICs.
It is based on the previous patch series
regulator: axp20x: Simplify various code
v3:
- put the code of the new devices in new files instead of in the common
axp20x file.
- fix errors about the regulators and interrupts
v2:
- fix lack of support of dcdc frequency
- notice that the AXP803 is also handled
- send the patch to the DT maintainers
Jean-Francois Moine (4):
regulator: axp20x: move device independant parts to new files
regulator: axp20x: duplicate the MFD axp20x-rsb code
regulator: axp20x: add the AXP803
regulator: axp20x: add the AXP813
Documentation/devicetree/bindings/mfd/axp20x.txt | 29 ++-
drivers/mfd/axp20x.c | 15 +
drivers/regulator/Makefile | 3 +-
drivers/regulator/axp-regulator.c | 347 +++++++++++++++++++
drivers/regulator/axp-regulator.h | 133 ++++++++
drivers/regulator/axp20x-regulator.c | 415 ++---------------------
drivers/regulator/axp803.c | 225 ++++++++++++
drivers/regulator/axp813.c | 229 +++++++++++++
include/linux/mfd/axp20x.h | 2 +
9 files changed, 1012 insertions(+), 388 deletions(-)
create mode 100644 drivers/regulator/axp-regulator.c
create mode 100644 drivers/regulator/axp-regulator.h
create mode 100644 drivers/regulator/axp803.c
create mode 100644 drivers/regulator/axp813.c
--
2.10.0
^ permalink raw reply
* [PATCH v5] KVM: arm/arm64: Route vtimer events to user space
From: Paolo Bonzini @ 2016-09-23 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d90f04d4-b29f-f08e-df39-ec307af44225@suse.de>
On 23/09/2016 09:14, Alexander Graf wrote:
>>> +/*
>>> + * Synchronize the timer IRQ state with the interrupt controller.
>>> + */
>>> static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
>>> {
>>> int ret;
>>> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>>
>>> timer->active_cleared_last = false;
>>> timer->irq.level = new_level;
>>> - trace_kvm_timer_update_irq(vcpu->vcpu_id, timer->irq.irq,
>>> + trace_kvm_timer_update_irq(vcpu->vcpu_id, host_vtimer_irq,
>>> timer->irq.level);
>>> + [...]
>>> + struct kvm_sync_regs *regs = &vcpu->run->s.regs;
>>> +
>>> + /* Populate the timer bitmap for user space */
>>> + regs->kernel_timer_pending &= ~KVM_ARM_TIMER_VTIMER;
>>> + if (new_level)
>>> + regs->kernel_timer_pending |= KVM_ARM_TIMER_VTIMER;
>>
>> I think if you got here, it means you have to exit to userspace to
>> update it of the new state. If you don't want to propagate a return
>
> Yes, but we can't exit straight away with our own exit reason because we
> might be inside an MMIO exit path here which already occupies the
> exit_reason.
So the idea is that whenever you're here you have one of the following
cases:
- are coming from kvm_timer_flush_hwstate, and then you exit immediately
with KVM_EXIT_INTR if needed
- you are coming from the kvm_timer_sync_hwstate just before
handle_exit. Then if there's a vmexit you have already set
regs->kernel_timer_pending, if not you'll do a kvm_timer_flush_hwstate soon.
- you are coming from the kvm_timer_sync_hwstate in the middle of
kvm_arch_vcpu_ioctl_run, and then "continue" will either exit the loop
immediately (if ret <= 0) or go to kvm_timer_flush_hwstate as in the
previous case
Right?
>> Maybe I'm misunderstanding and user_timer_pending is just a cached
>> verison of what you said last, but as I said above, I think you can just
>> compare timer->irq.level with the last value the kvm_run struct, and if
>> something changed, you have to exit.
>
> So how would user space know whether the line went up or down? Or didn't
> change at all (if we coalesce with an MMIO exit)?
It would save the status of the line somewhere in its own variable,
without introducing a relatively delicate API between kernel and user.
I agree that you cannot update kernel_timer_pending only in
flush_hwstate; otherwise you miss on case (2) when there is a vmexit.
That has to stay in kvm_timer_sync_hwstate (or it could become a new
function called at the very end of kvm_arch_vcpu_ioctl_run).
However, I'm not sure why user_timer_pending is necessary. If it is
just the value you assigned to regs->kernel_timer_pending at the time of
the previous vmexit, can kvm_timer_flush_hwstate just do
if (timer->prev_kernel_timer_pending != regs->kernel_timer_pending) {
timer->prev_kernel_timer_pending = regs->kernel_timer_pending;
return 1;
}
? Or even
if (timer->prev_irq_level != timer->irq.level) {
timer->prev_irq_level = regs->irq.level;
return 1;
}
so that regs->kernel_timer_pending remains exclusively
kvm_timer_sync_hwstate's business?
Thanks,
Paolo
>>
>>> +
>>> + /*
>>> + * As long as user space is aware that the timer is pending,
>>> + * we do not need to get new host timer events.
>>> + */
>>
>> yes, correct, but I don't think this concept was clearly reflected in
>> your API text above.
>>
>>> + if (timer->irq.level)
>>> + disable_percpu_irq(host_vtimer_irq);
>>> + else
>>> + enable_percpu_irq(host_vtimer_irq, 0);
>>> + }
>>
>> could we move these two blocks into their own functions instead? That
>> would also give nice names to the huge chunk of complicated
>> functionality, e.g. flush_timer_state_to_user() and
>> flush_timer_state_to_vgic().
>
> That's probably a very useful cleanup, yes :).
>
>
> Alex
> --
> 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 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Linus Walleij @ 2016-09-23 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919161314.25858-1-eric@anholt.net>
On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt <eric@anholt.net> wrote:
> The RPi firmware exposes all of the board's GPIO lines through
> property calls. Linux chooses to control most lines directly through
> the pinctrl driver, but for the FXL6408 GPIO expander on the Pi3, we
> need to access them through the firmware.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
Aha
> +++ b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> @@ -0,0 +1,22 @@
> +Raspberry Pi power domain driver
Really? :)
> +Required properties:
> +
> +- compatible: Should be "raspberrypi,firmware-gpio"
Usually this is vendor,compat, is the vendors name "raspberrypi"?
> +- gpio-controller: Marks the device node as a gpio controller
> +- #gpio-cells: Should be <2> for GPIO number and flags
> +- ngpios: Number of GPIO lines to control. See gpio.txt
Is this ever anything else than 8? Else omit it and hardcode
8 in the driver instead.
> +- firmware: Reference to the RPi firmware device node
Reference the DT binding for this.
> +- raspberrypi,firmware-gpio-offset:
> + Number the firmware uses for the first GPIO line
> + controlled by this driver
Does this differ between different instances of this hardware or
can it just be open coded in the driver instead?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] arm: dts: zynq: Add MicroZed board support
From: Michal Simek @ 2016-09-23 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6G_RRn0pAF=TsgONQ4yah2VhZXQeBQmeBQ5p46u6R5F8pSqw@mail.gmail.com>
On 23.9.2016 10:42, Jagan Teki wrote:
> On Fri, Sep 23, 2016 at 2:07 PM, Michal Simek <michal.simek@xilinx.com> wrote:
>> On 23.9.2016 09:39, Jagan Teki wrote:
>>> On Fri, Sep 23, 2016 at 11:33 AM, Michal Simek <michal.simek@xilinx.com> wrote:
>>>> On 22.9.2016 22:59, S?ren Brinkmann wrote:
>>>>> On Thu, 2016-09-22 at 18:51:29 +0530, Jagan Teki wrote:
>>>>>> From: Jagan Teki <jteki@openedev.com>
>>>>>>
>>>>>> Added basic dts support for MicroZed board.
>>>>>>
>>>>>> - UART
>>>>>> - SDHCI
>>>>>> - Ethernet
>>>>>>
>>>>>> Cc: Soren Brinkmann <soren.brinkmann@xilinx.com>
>>>>>> Cc: Michal Simek <michal.simek@xilinx.com>
>>>>>> Signed-off-by: Jagan Teki <jteki@openedev.com>
>>>>>> ---
>>>>>> Changes for v2:
>>>>>> - Add SDHCI
>>>>>> - Add Ethernet
>>>>>>
>>>>>> arch/arm/boot/dts/Makefile | 1 +
>>>>>> arch/arm/boot/dts/zynq-microzed.dts | 95 +++++++++++++++++++++++++++++++++++++
>>>>>> 2 files changed, 96 insertions(+)
>>>>>> create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>>>>> index faacd52..4d7b858 100644
>>>>>> --- a/arch/arm/boot/dts/Makefile
>>>>>> +++ b/arch/arm/boot/dts/Makefile
>>>>>> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
>>>>>> wm8750-apc8750.dtb \
>>>>>> wm8850-w70v2.dtb
>>>>>> dtb-$(CONFIG_ARCH_ZYNQ) += \
>>>>>> + zynq-microzed.dtb \
>>>>>> zynq-parallella.dtb \
>>>>>> zynq-zc702.dtb \
>>>>>> zynq-zc706.dtb \
>>>>>> diff --git a/arch/arm/boot/dts/zynq-microzed.dts b/arch/arm/boot/dts/zynq-microzed.dts
>>>>>> new file mode 100644
>>>>>> index 0000000..9e64496
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/boot/dts/zynq-microzed.dts
>>>>>> @@ -0,0 +1,95 @@
>>>>>> +/*
>>>>>> + * Copyright (C) 2015 Jagan Teki <jteki@openedev.com>
>>>>
>>>>
>>>> Did you created only yourself without copying part of this from others?
>>>> There is dts in u-boot which I believe you are aware of.
>>>
>>> I sent the initial one few months back so at that time, I was created
>>> and now I just added USB and Ethernet with the reference of zc702
>>> board.
>>
>> Can you send me a link to that post? I didn't find it.
>
> Here is the link [1]
>
>> Anyway you should keep Xilinx copyright there.
>
> OK then will append Xilinx as well.
>
> [1] http://lkml.iu.edu/hypermail/linux/kernel/1601.1/03236.html
ok. It was lkml and devicetree not arm mailing list that's why I didn't
find it.
Thanks,
Michal
^ permalink raw reply
* [PATCH v4 1/7] pinctrl: bcm2835: add pull defines to dt bindings
From: Linus Walleij @ 2016-09-23 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zin49p9m.fsf@eliezer.anholt.net>
On Mon, Sep 19, 2016 at 12:07 PM, Eric Anholt <eric@anholt.net> wrote:
> Gerd Hoffmann <kraxel@redhat.com> writes:
>
>> Also delete (unused) private enum from driver.
>> The pull defines can be used instead if needed.
>>
>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>
> Acked-by: Eric Anholt <eric@anholt.net>
>
> gpio maintainers, could I pull this through my dt tree? Or does this
> need to be split in two?
You can take it. The bcm2835 driver is not seeing any conflicting
changes in this merge window.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 0/3] arm64: kgdb: fix single stepping
From: Greg KH @ 2016-09-23 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923083257.GL30248@linaro.org>
On Fri, Sep 23, 2016 at 05:32:58PM +0900, AKASHI Takahiro wrote:
> On Fri, Sep 23, 2016 at 10:16:18AM +0200, Greg KH wrote:
> > On Fri, Sep 23, 2016 at 04:33:24PM +0900, AKASHI Takahiro wrote:
> > > Kgdb support on arm64 was merged in v3.15, but from its first appearance,
> > > "signle step" has never worked well.
> > >
> > > This patch fixes all the error cases I found so far.
> > > The original patch[1] was splitted into three pieces, ones for each case.
> > > patch#1, #2 should be applied to all the version, v3.15 and later.
> > > pathc#3 only for v3.16 and later.
> >
> > As this is not a regression (i.e. it has never worked), why is this
> > something for stable releases?
>
> Because, I think, that is a bug.
> The author seems to have believed that it worked.
> Please see:
> commit 44679a4f
> Author: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> Date: Tue Jan 28 11:20:19 2014 +0000
>
> arm64: KGDB: Add step debugging support
Yes, but again, it didn't work, so this would be a new feature. One
that obviously people aren't using in the stable kernels, otherwise they
would have noticed in the past 2 years about it being broken :)
Please read Documentation/stable_kernel_rules.txt for the requirements
of a stable kernel patch. I don't think this series meets those rules.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2] arm: dts: zynq: Add MicroZed board support
From: Jagan Teki @ 2016-09-23 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aa469a8b-7968-1934-1b8e-6978fd0e6922@xilinx.com>
On Fri, Sep 23, 2016 at 2:07 PM, Michal Simek <michal.simek@xilinx.com> wrote:
> On 23.9.2016 09:39, Jagan Teki wrote:
>> On Fri, Sep 23, 2016 at 11:33 AM, Michal Simek <michal.simek@xilinx.com> wrote:
>>> On 22.9.2016 22:59, S?ren Brinkmann wrote:
>>>> On Thu, 2016-09-22 at 18:51:29 +0530, Jagan Teki wrote:
>>>>> From: Jagan Teki <jteki@openedev.com>
>>>>>
>>>>> Added basic dts support for MicroZed board.
>>>>>
>>>>> - UART
>>>>> - SDHCI
>>>>> - Ethernet
>>>>>
>>>>> Cc: Soren Brinkmann <soren.brinkmann@xilinx.com>
>>>>> Cc: Michal Simek <michal.simek@xilinx.com>
>>>>> Signed-off-by: Jagan Teki <jteki@openedev.com>
>>>>> ---
>>>>> Changes for v2:
>>>>> - Add SDHCI
>>>>> - Add Ethernet
>>>>>
>>>>> arch/arm/boot/dts/Makefile | 1 +
>>>>> arch/arm/boot/dts/zynq-microzed.dts | 95 +++++++++++++++++++++++++++++++++++++
>>>>> 2 files changed, 96 insertions(+)
>>>>> create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>>>> index faacd52..4d7b858 100644
>>>>> --- a/arch/arm/boot/dts/Makefile
>>>>> +++ b/arch/arm/boot/dts/Makefile
>>>>> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
>>>>> wm8750-apc8750.dtb \
>>>>> wm8850-w70v2.dtb
>>>>> dtb-$(CONFIG_ARCH_ZYNQ) += \
>>>>> + zynq-microzed.dtb \
>>>>> zynq-parallella.dtb \
>>>>> zynq-zc702.dtb \
>>>>> zynq-zc706.dtb \
>>>>> diff --git a/arch/arm/boot/dts/zynq-microzed.dts b/arch/arm/boot/dts/zynq-microzed.dts
>>>>> new file mode 100644
>>>>> index 0000000..9e64496
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/boot/dts/zynq-microzed.dts
>>>>> @@ -0,0 +1,95 @@
>>>>> +/*
>>>>> + * Copyright (C) 2015 Jagan Teki <jteki@openedev.com>
>>>
>>>
>>> Did you created only yourself without copying part of this from others?
>>> There is dts in u-boot which I believe you are aware of.
>>
>> I sent the initial one few months back so at that time, I was created
>> and now I just added USB and Ethernet with the reference of zc702
>> board.
>
> Can you send me a link to that post? I didn't find it.
Here is the link [1]
> Anyway you should keep Xilinx copyright there.
OK then will append Xilinx as well.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1601.1/03236.html
thanks!
--
Jagan.
^ permalink raw reply
* [PATCH v26 1/7] arm64: kdump: reserve memory for crash dump kernel
From: AKASHI Takahiro @ 2016-09-23 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26b1e4d1-e4a6-a4f7-bdf8-cd97363ce1ee@suse.com>
On Thu, Sep 22, 2016 at 12:23:08PM +0200, Matthias Bruger wrote:
>
>
> On 09/07/2016 06:29 AM, AKASHI Takahiro wrote:
> >On the startup of primary kernel, the memory region used by crash dump
> >kernel must be specified by "crashkernel=" kernel parameter.
> >reserve_crashkernel() will allocate and reserve the region for later use.
> >
> >User space tools, like kexec-tools, will be able to find that region as
> > - "Crash kernel" in /proc/iomem, or
> > - "linux,crashkernel-base" and "linux,crashkernel-size" under
> > /sys/firmware/devicetree/base/chosen
> >
> >Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >Signed-off-by: Mark Salter <msalter@redhat.com>
> >Signed-off-by: Pratyush Anand <panand@redhat.com>
> >Reviewed-by: James Morse <james.morse@arm.com>
> >---
> > arch/arm64/kernel/setup.c | 7 ++-
> > arch/arm64/mm/init.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 119 insertions(+), 1 deletion(-)
> >
> >diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> >index 514b4e3..38589b5 100644
> >--- a/arch/arm64/kernel/setup.c
> >+++ b/arch/arm64/kernel/setup.c
> >@@ -31,7 +31,6 @@
> > #include <linux/screen_info.h>
> > #include <linux/init.h>
> > #include <linux/kexec.h>
> >-#include <linux/crash_dump.h>
> > #include <linux/root_dev.h>
> > #include <linux/cpu.h>
> > #include <linux/interrupt.h>
> >@@ -225,6 +224,12 @@ static void __init request_standard_resources(void)
> > kernel_data.end <= res->end)
> > request_resource(res, &kernel_data);
> > }
> >+
> >+#ifdef CONFIG_KEXEC_CORE
> >+ /* User space tools will find "Crash kernel" region in /proc/iomem. */
> >+ if (crashk_res.end)
> >+ insert_resource(&iomem_resource, &crashk_res);
> >+#endif
> > }
> >
> > u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
> >diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> >index bbb7ee7..dd273ec 100644
> >--- a/arch/arm64/mm/init.c
> >+++ b/arch/arm64/mm/init.c
> >@@ -29,11 +29,13 @@
> > #include <linux/gfp.h>
> > #include <linux/memblock.h>
> > #include <linux/sort.h>
> >+#include <linux/of.h>
> > #include <linux/of_fdt.h>
> > #include <linux/dma-mapping.h>
> > #include <linux/dma-contiguous.h>
> > #include <linux/efi.h>
> > #include <linux/swiotlb.h>
> >+#include <linux/kexec.h>
> >
> > #include <asm/boot.h>
> > #include <asm/fixmap.h>
> >@@ -76,6 +78,114 @@ static int __init early_initrd(char *p)
> > early_param("initrd", early_initrd);
> > #endif
> >
> >+#ifdef CONFIG_KEXEC_CORE
> >+static unsigned long long crash_size, crash_base;
> >+static struct property crash_base_prop = {
> >+ .name = "linux,crashkernel-base",
> >+ .length = sizeof(u64),
> >+ .value = &crash_base
> >+};
> >+static struct property crash_size_prop = {
> >+ .name = "linux,crashkernel-size",
> >+ .length = sizeof(u64),
> >+ .value = &crash_size,
> >+};
> >+
> >+static int __init export_crashkernel(void)
> >+{
> >+ struct device_node *node;
> >+ int ret;
> >+
> >+ if (!crashk_res.end)
> >+ return 0;
> >+
> >+ crash_base = cpu_to_be64(crashk_res.start);
> >+ crash_size = cpu_to_be64(crashk_res.end - crashk_res.start + 1);
> >+
>
> Shouldn't that be the same values as in reserve_crashkernel()?
> IMHO this does not need to be recalculated here.
Right. crashk_res is calculated from crash_base/size.
So I should and will remove those lines.
Thanks,
-Takahiro AKASHI
> Regards,
> Matthias
>
> >+ /* Add /chosen/linux,crashkernel-* properties */
> >+ node = of_find_node_by_path("/chosen");
> >+ if (!node)
> >+ return -ENOENT;
> >+
> >+ /*
> >+ * There might be existing crash kernel properties, but we can't
> >+ * be sure what's in them, so remove them.
> >+ */
> >+ of_remove_property(node, of_find_property(node,
> >+ "linux,crashkernel-base", NULL));
> >+ of_remove_property(node, of_find_property(node,
> >+ "linux,crashkernel-size", NULL));
> >+
> >+ ret = of_add_property(node, &crash_base_prop);
> >+ if (ret)
> >+ goto ret_err;
> >+
> >+ ret = of_add_property(node, &crash_size_prop);
> >+ if (ret)
> >+ goto ret_err;
> >+
> >+ return 0;
> >+
> >+ret_err:
> >+ pr_warn("Exporting crashkernel region to device tree failed\n");
> >+ return ret;
> >+}
> >+late_initcall(export_crashkernel);
> >+
> >+/*
> >+ * reserve_crashkernel() - reserves memory for crash kernel
> >+ *
> >+ * This function reserves memory area given in "crashkernel=" kernel command
> >+ * line parameter. The memory reserved is used by dump capture kernel when
> >+ * primary kernel is crashing.
> >+ */
> >+static void __init reserve_crashkernel(void)
> >+{
> >+ int ret;
> >+
> >+ ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> >+ &crash_size, &crash_base);
> >+ /* no crashkernel= or invalid value specified */
> >+ if (ret || !crash_size)
> >+ return;
> >+
> >+ if (crash_base == 0) {
> >+ /* Current arm64 boot protocol requires 2MB alignment */
> >+ crash_base = memblock_find_in_range(0, ARCH_LOW_ADDRESS_LIMIT,
> >+ crash_size, SZ_2M);
> >+ if (crash_base == 0) {
> >+ pr_warn("Unable to allocate crashkernel (size:%llx)\n",
> >+ crash_size);
> >+ return;
> >+ }
> >+ } else {
> >+ /* User specifies base address explicitly. */
> >+ if (!memblock_is_region_memory(crash_base, crash_size) ||
> >+ memblock_is_region_reserved(crash_base, crash_size)) {
> >+ pr_warn("crashkernel has wrong address or size\n");
> >+ return;
> >+ }
> >+
> >+ if (!IS_ALIGNED(crash_base, SZ_2M)) {
> >+ pr_warn("crashkernel base address is not 2MB aligned\n");
> >+ return;
> >+ }
> >+ }
> >+ memblock_reserve(crash_base, crash_size);
> >+
> >+ pr_info("Reserving %lldMB of memory at %lldMB for crashkernel\n",
> >+ crash_size >> 20, crash_base >> 20);
> >+
> >+ crashk_res.start = crash_base;
> >+ crashk_res.end = crash_base + crash_size - 1;
> >+}
> >+#else
> >+static void __init reserve_crashkernel(void)
> >+{
> >+ ;
> >+}
> >+#endif /* CONFIG_KEXEC_CORE */
> >+
> > /*
> > * Return the maximum physical address for ZONE_DMA (DMA_BIT_MASK(32)). It
> > * currently assumes that for memory starting above 4G, 32-bit devices will
> >@@ -296,6 +406,9 @@ void __init arm64_memblock_init(void)
> > arm64_dma_phys_limit = max_zone_dma_phys();
> > else
> > arm64_dma_phys_limit = PHYS_MASK + 1;
> >+
> >+ reserve_crashkernel();
> >+
> > dma_contiguous_reserve(arm64_dma_phys_limit);
> >
> > memblock_allow_resize();
> >
^ permalink raw reply
* [PATCH v2] arm: dts: zynq: Add MicroZed board support
From: Michal Simek @ 2016-09-23 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6G_RR6JSzd-QCUj3wDC30pXabNqaNR1d1jQm9bUq6z0CP=3g@mail.gmail.com>
On 23.9.2016 09:39, Jagan Teki wrote:
> On Fri, Sep 23, 2016 at 11:33 AM, Michal Simek <michal.simek@xilinx.com> wrote:
>> On 22.9.2016 22:59, S?ren Brinkmann wrote:
>>> On Thu, 2016-09-22 at 18:51:29 +0530, Jagan Teki wrote:
>>>> From: Jagan Teki <jteki@openedev.com>
>>>>
>>>> Added basic dts support for MicroZed board.
>>>>
>>>> - UART
>>>> - SDHCI
>>>> - Ethernet
>>>>
>>>> Cc: Soren Brinkmann <soren.brinkmann@xilinx.com>
>>>> Cc: Michal Simek <michal.simek@xilinx.com>
>>>> Signed-off-by: Jagan Teki <jteki@openedev.com>
>>>> ---
>>>> Changes for v2:
>>>> - Add SDHCI
>>>> - Add Ethernet
>>>>
>>>> arch/arm/boot/dts/Makefile | 1 +
>>>> arch/arm/boot/dts/zynq-microzed.dts | 95 +++++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 96 insertions(+)
>>>> create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>>>>
>>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>>> index faacd52..4d7b858 100644
>>>> --- a/arch/arm/boot/dts/Makefile
>>>> +++ b/arch/arm/boot/dts/Makefile
>>>> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
>>>> wm8750-apc8750.dtb \
>>>> wm8850-w70v2.dtb
>>>> dtb-$(CONFIG_ARCH_ZYNQ) += \
>>>> + zynq-microzed.dtb \
>>>> zynq-parallella.dtb \
>>>> zynq-zc702.dtb \
>>>> zynq-zc706.dtb \
>>>> diff --git a/arch/arm/boot/dts/zynq-microzed.dts b/arch/arm/boot/dts/zynq-microzed.dts
>>>> new file mode 100644
>>>> index 0000000..9e64496
>>>> --- /dev/null
>>>> +++ b/arch/arm/boot/dts/zynq-microzed.dts
>>>> @@ -0,0 +1,95 @@
>>>> +/*
>>>> + * Copyright (C) 2015 Jagan Teki <jteki@openedev.com>
>>
>>
>> Did you created only yourself without copying part of this from others?
>> There is dts in u-boot which I believe you are aware of.
>
> I sent the initial one few months back so at that time, I was created
> and now I just added USB and Ethernet with the reference of zc702
> board.
Can you send me a link to that post? I didn't find it.
Anyway you should keep Xilinx copyright there.
Thanks,
Michal
^ permalink raw reply
* [PATCH v2 0/3] arm64: kgdb: fix single stepping
From: AKASHI Takahiro @ 2016-09-23 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923081618.GH18056@kroah.com>
On Fri, Sep 23, 2016 at 10:16:18AM +0200, Greg KH wrote:
> On Fri, Sep 23, 2016 at 04:33:24PM +0900, AKASHI Takahiro wrote:
> > Kgdb support on arm64 was merged in v3.15, but from its first appearance,
> > "signle step" has never worked well.
> >
> > This patch fixes all the error cases I found so far.
> > The original patch[1] was splitted into three pieces, ones for each case.
> > patch#1, #2 should be applied to all the version, v3.15 and later.
> > pathc#3 only for v3.16 and later.
>
> As this is not a regression (i.e. it has never worked), why is this
> something for stable releases?
Because, I think, that is a bug.
The author seems to have believed that it worked.
Please see:
commit 44679a4f
Author: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Date: Tue Jan 28 11:20:19 2014 +0000
arm64: KGDB: Add step debugging support
Thanks,
-Takahiro AKASHI
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH] ARM: shmobile: Sort Kconfig selections
From: Geert Uytterhoeven @ 2016-09-23 8:28 UTC (permalink / raw)
To: linux-arm-kernel
Sort alphabetically all symbols selected by ARCH_RENESAS
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/mach-shmobile/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 4a48c9f5f72537cd..b5a3cbe81dd1d1f0 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -33,15 +33,15 @@ config ARCH_RMOBILE
menuconfig ARCH_RENESAS
bool "Renesas ARM SoCs"
depends on ARCH_MULTI_V7 && MMU
+ select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select ARCH_SHMOBILE
select ARCH_SHMOBILE_MULTI
+ select ARM_GIC
+ select GPIOLIB
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
- select ARM_GIC
- select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select NO_IOPORT_MAP
select PINCTRL
- select GPIOLIB
select ZONE_DMA if ARM_LPAE
if ARCH_RENESAS
--
1.9.1
^ permalink raw reply related
* [PATCH V3 RFT 3/5] ARM64: dts: bcm283x: Use dtsi for USB host mode
From: Stefan Wahren @ 2016-09-23 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zimz821m.fsf@eliezer.anholt.net>
Am 23.09.2016 um 10:15 schrieb Eric Anholt:
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
>> Am 07.09.2016 um 16:17 schrieb Gerd Hoffmann:
>>> Hi,
>>>
>>>> ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi
>>>> ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm
>>> Picked them up.
>>>
>>>> In case of a multiplatform config with following settings the driver
>>>> isn't able to "detect" the role:
>>>>
>>>> CONFIG_USB=y
>>>> CONFIG_USB_OTG=y
>>>> CONFIG_USB_DWC2=y
>>>> CONFIG_USB_DWC2_DUAL_ROLE=y
>>>> CONFIG_USB_PHY=y
>>>> CONFIG_NOP_USB_XCEIV=y
>>>> CONFIG_USB_GADGET=y
>>>> CONFIG_USB_ZERO=y
>>> Configured my kernel that way so the test actually tests something ;)
>>>
>>> And ... everything looks fine. usb ethernet works, and so does the usb
>>> keyboard. /proc/device-tree/soc/usb at 7e980000/dr_mode exists and
>>> contains "host".
>>>
>>> Tested-by: Gerd Hoffmann <kraxel@redhat.com>
>>>
>> This patch hasn't been merged yet. Is there something wrong?
> I hadn't bumped it back to todo from RFT. Also, is this a priority
> patch, since submitting merges is a pain?
No
> Does USB break in some way
> without it?
No. I only want know if this is still in queue and does someone care
about this patch.
Thanks
Stefan
^ permalink raw reply
* [PATCH v2 0/3] arm64: kgdb: fix single stepping
From: Greg KH @ 2016-09-23 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923073327.9657-1-takahiro.akashi@linaro.org>
On Fri, Sep 23, 2016 at 04:33:24PM +0900, AKASHI Takahiro wrote:
> Kgdb support on arm64 was merged in v3.15, but from its first appearance,
> "signle step" has never worked well.
>
> This patch fixes all the error cases I found so far.
> The original patch[1] was splitted into three pieces, ones for each case.
> patch#1, #2 should be applied to all the version, v3.15 and later.
> pathc#3 only for v3.16 and later.
As this is not a regression (i.e. it has never worked), why is this
something for stable releases?
thanks,
greg k-h
^ permalink raw reply
* [PATCH V3 RFT 3/5] ARM64: dts: bcm283x: Use dtsi for USB host mode
From: Eric Anholt @ 2016-09-23 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aeba1434-3903-3ec4-1a94-e5c8229f4e5f@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Am 07.09.2016 um 16:17 schrieb Gerd Hoffmann:
>> Hi,
>>
>>> ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi
>>> ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm
>> Picked them up.
>>
>>> In case of a multiplatform config with following settings the driver
>>> isn't able to "detect" the role:
>>>
>>> CONFIG_USB=y
>>> CONFIG_USB_OTG=y
>>> CONFIG_USB_DWC2=y
>>> CONFIG_USB_DWC2_DUAL_ROLE=y
>>> CONFIG_USB_PHY=y
>>> CONFIG_NOP_USB_XCEIV=y
>>> CONFIG_USB_GADGET=y
>>> CONFIG_USB_ZERO=y
>> Configured my kernel that way so the test actually tests something ;)
>>
>> And ... everything looks fine. usb ethernet works, and so does the usb
>> keyboard. /proc/device-tree/soc/usb at 7e980000/dr_mode exists and
>> contains "host".
>>
>> Tested-by: Gerd Hoffmann <kraxel@redhat.com>
>>
>
> This patch hasn't been merged yet. Is there something wrong?
I hadn't bumped it back to todo from RFT. Also, is this a priority
patch, since submitting merges is a pain? Does USB break in some way
without it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160923/c5dd2a13/attachment.sig>
^ permalink raw reply
* [PATCHv2 3/3] clk: keystone: Add sci-clk driver support
From: Tero Kristo @ 2016-09-23 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916230101.GM7243@codeaurora.org>
On 17/09/16 02:01, Stephen Boyd wrote:
> On 09/05, Tero Kristo wrote:
>> On 03/09/16 02:32, Stephen Boyd wrote:
>>> I still don't get it. We should be registering hw pointers in
>>> probe and handing them out in the xlate function. Not register
>>> hws in the xlate function and then handing them out as well. I
>>> haven't reviewed anything else in this patch.
>>
>> Ok, let me try to explain the functionality.
>>
>> Probe time hw pointer registration is only needed for special clocks
>> that require extra flags, like adding the spread spectrum flag.
>> There is ever going to be only handful of these.
>>
>> Xlate checks out the sci_clk list, and picks up an existing hw clock
>> if it is there. If not, it will create a new one. The reason this is
>> done like this, the device IDs / clock IDs don't mean anything to
>> the driver itself, the driver just passes these forward to the
>> underlying SCI fwk. And, we don't have inherent knowledge of valid
>> device / clock IDs either, the SCI fwk returns a failure if a
>> specific clock ID is bad. The device / clock IDs are going to be
>> different between different generations of SoC also, and in addition
>> there can be holes in the ID ranges.
>
> Ok. Thanks for the explanation.
>
> I understand the desire to make this SoC agnostic and consumer/dt
> driven. Constructor pattern and all. Unfortunately the OF clk
> provider is a getter pattern; not a constructor pattern. I'm
> seriously concerned about the locking here because we're in the
> framework creating a clk and tying it into a consumer list which
> could cause all sorts of problems if we want to reenter the
> framework and register more clks. Recursion abounds and my head
> explodes! The recursive clk prepare mutex is not something anyone
> should be thrilled about keeping around.
>
> So, just don't do this. Instead, register the clks during probe
> that exist for the firmware. That list could be discoverable with
> firmware calls, or known based on different compatible strings
> from DT that have the soc name in it, or something else. Even
> scanning the entire DT tree for
>
> clocks = <&my_clk_node x y>
>
> would be better, but probably hugely inefficient and outright
> buggy with DT overlays so don't do it. If the firmware can't tell
> us what clks are there, just have a table based on compatible
> string and be done.
Ok, I will add a static mapping of valid clock IDs within the driver and
init all of these during probe. I have a working solution for this
already, but will post it out only once 4.9-rc1 is out.
-Tero
^ permalink raw reply
* [PATCHv2 1/3] Documentation: dt: Add TI SCI clock driver
From: Tero Kristo @ 2016-09-23 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912131038.GA13103@rob-hp-laptop>
On 12/09/16 16:10, Rob Herring wrote:
> On Thu, Sep 01, 2016 at 03:40:33PM +0300, Tero Kristo wrote:
>> Add a clock implementation, TI SCI clock, that will hook to the common
>> clock framework, and allow each clock to be controlled via TI SCI
>> protocol.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> Tested-by: Dave Gerlach <d-gerlach@ti.com>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> .../devicetree/bindings/clock/ti,sci-clk.txt | 51 ++++++++++++++++++++++
>> MAINTAINERS | 1 +
>> 2 files changed, 52 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>> new file mode 100644
>> index 0000000..231cb80
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>> @@ -0,0 +1,51 @@
>> +Texas Instruments TI-SCI Clocks
>> +===============================
>> +
>> +All clocks on Texas Instruments' SoCs that contain a System Controller,
>> +are only controlled by this entity. Communication between a host processor
>> +running an OS and the System Controller happens through a protocol known
>> +as TI-SCI[1]. This clock implementation plugs into the common clock
>> +framework and makes use of the TI-SCI protocol on clock API requests.
>> +
>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> +
>> +Required properties:
>> +-------------------
>> +- compatible: Must be "ti,sci-clk"
>> +- #clock-cells: Shall be 2.
>> + In clock consumers, this cell represents the device ID and clock ID
>> + exposed by the PM firmware. The assignments can be found in the header
>> + files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and
>> + <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where <soc>
>> + is the SoC involved, for example 'k2g'.
>> +- ti,sci: Phandle to the TI SCI device to use for managing the clocks
>> +
>> +Optional properties:
>> +-------------------
>> +- ti,ssc-clocks: Array of phandle clocks that shall enable spread spectrum
>> + clocking while enabled
>> +- ti,allow-freq-change-clocks: Array of phandle clocks that shall allow
>> + dynamic clock frequency changes by firmware
>> +- ti,input-term-clocks: Array of phandle clocks that shall enable input
>> + termination
>
> These seem like a random set of features to control. What determines the
> clocks for these? If it is based on the SoC, then make your compatible
> string SoC specific and don't put this into DT.
Currently nobody seems to be using these flags, so I will just drop the
support for these from the next rev. If anybody will need them at some
point, I will figure out how to support these.
-Tero
^ permalink raw reply
* [PATCH 0/3] regulator: axp20x: Simplify various code
From: Jean-Francois Moine @ 2016-09-23 7:44 UTC (permalink / raw)
To: linux-arm-kernel
This patch series just simplifies a bit the code of the AXP20x driver.
It does not contain any fonctional changes.
It will be used as a base for adding new AXP devices (patches to come).
It applies on linux-next.
Jean-Francois Moine (3):
regulator: axp20x: simplify poly-phase handling
regulator: axp20x: simplify the treatment of linked regulators
regulator: axp20x: simplify device access
drivers/regulator/axp20x-regulator.c | 114 ++++++++++++++++++-----------------
1 file changed, 60 insertions(+), 54 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v2.1] arm64: kgdb: handle read-only text / modules
From: AKASHI Takahiro @ 2016-09-23 7:42 UTC (permalink / raw)
To: linux-arm-kernel
Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
by using aarch64_insn_write() instead of probe_kernel_write().
See how this works:
commit 2f896d586610 ("arm64: use fixmap for text patching")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: <stable@vger.kernel.org> # 3.18-3.19: 2f896d5: arm64: use fixmap
Cc: <stable@vger.kernel.org> # 3.18-3.19: f6242ca: arm64: Fix text
Cc: <stable@vger.kernel.org> # 4.0-
---
arch/arm64/include/asm/debug-monitors.h | 2 --
arch/arm64/kernel/kgdb.c | 36 ++++++++++++++++++++++-----------
2 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index 4b6b3f7..b71420a 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -61,8 +61,6 @@
#define AARCH64_BREAK_KGDB_DYN_DBG \
(AARCH64_BREAK_MON | (KGDB_DYN_DBG_BRK_IMM << 5))
-#define KGDB_DYN_BRK_INS_BYTE(x) \
- ((AARCH64_BREAK_KGDB_DYN_DBG >> (8 * (x))) & 0xff)
#define CACHE_FLUSH_IS_SAFE 1
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index 6732a27..b06a7a2 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -19,6 +19,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/bug.h>
#include <linux/cpumask.h>
#include <linux/irq.h>
#include <linux/irq_work.h>
@@ -26,6 +27,8 @@
#include <linux/kgdb.h>
#include <linux/kprobes.h>
#include <linux/percpu.h>
+#include <asm/debug-monitors.h>
+#include <asm/insn.h>
#include <asm/ptrace.h>
#include <asm/traps.h>
@@ -370,15 +373,24 @@ void kgdb_arch_exit(void)
unregister_die_notifier(&kgdb_notifier);
}
-/*
- * ARM instructions are always in LE.
- * Break instruction is encoded in LE format
- */
-struct kgdb_arch arch_kgdb_ops = {
- .gdb_bpt_instr = {
- KGDB_DYN_BRK_INS_BYTE(0),
- KGDB_DYN_BRK_INS_BYTE(1),
- KGDB_DYN_BRK_INS_BYTE(2),
- KGDB_DYN_BRK_INS_BYTE(3),
- }
-};
+struct kgdb_arch arch_kgdb_ops;
+
+int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
+{
+ int err;
+
+ BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
+
+ err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
+ if (err)
+ return err;
+
+ return aarch64_insn_write((void *)bpt->bpt_addr,
+ (u32)AARCH64_BREAK_KGDB_DYN_DBG);
+}
+
+int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
+{
+ return aarch64_insn_write((void *)bpt->bpt_addr,
+ *(u32 *)bpt->saved_instr);
+}
--
2.10.0
^ permalink raw reply related
* [PATCH v2] arm64: kgdb: handle read-only text / modules
From: AKASHI Takahiro @ 2016-09-23 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921085721.GA18176@leverpostej>
On Wed, Sep 21, 2016 at 09:57:21AM +0100, Mark Rutland wrote:
> On Wed, Sep 21, 2016 at 04:19:55PM +0900, AKASHI Takahiro wrote:
> > Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
> > by using aarch64_insn_write() instead of probe_kernel_write().
> > See how this works:
> > commit 2f896d586610 ("arm64: use fixmap for text patching")
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Jason Wessel <jason.wessel@windriver.com>
> > Cc: <stable@vger.kernel.org> # 3.18-3.19: 2f896d5: arm64: use fixmap
> > Cc: <stable@vger.kernel.org> # 4.0-
>
> For v3.18-v3.19, we also need commit f6242cac10427c54 ("arm64: Fix text
> patching logic when using fixmap"), so as to not break the
> !CONFIG_DEBUG_SET_MODULE_RONX case.
Ah, thank you.
I will post the patch as v2.1.
-Takahiro AKASHI
> With that:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>
> Thanks,
> Mark.
>
> > ---
> > arch/arm64/include/asm/debug-monitors.h | 2 --
> > arch/arm64/kernel/kgdb.c | 36 ++++++++++++++++++++++-----------
> > 2 files changed, 24 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
> > index 4b6b3f7..b71420a 100644
> > --- a/arch/arm64/include/asm/debug-monitors.h
> > +++ b/arch/arm64/include/asm/debug-monitors.h
> > @@ -61,8 +61,6 @@
> >
> > #define AARCH64_BREAK_KGDB_DYN_DBG \
> > (AARCH64_BREAK_MON | (KGDB_DYN_DBG_BRK_IMM << 5))
> > -#define KGDB_DYN_BRK_INS_BYTE(x) \
> > - ((AARCH64_BREAK_KGDB_DYN_DBG >> (8 * (x))) & 0xff)
> >
> > #define CACHE_FLUSH_IS_SAFE 1
> >
> > diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> > index 6732a27..b06a7a2 100644
> > --- a/arch/arm64/kernel/kgdb.c
> > +++ b/arch/arm64/kernel/kgdb.c
> > @@ -19,6 +19,7 @@
> > * along with this program. If not, see <http://www.gnu.org/licenses/>.
> > */
> >
> > +#include <linux/bug.h>
> > #include <linux/cpumask.h>
> > #include <linux/irq.h>
> > #include <linux/irq_work.h>
> > @@ -26,6 +27,8 @@
> > #include <linux/kgdb.h>
> > #include <linux/kprobes.h>
> > #include <linux/percpu.h>
> > +#include <asm/debug-monitors.h>
> > +#include <asm/insn.h>
> > #include <asm/ptrace.h>
> > #include <asm/traps.h>
> >
> > @@ -370,15 +373,24 @@ void kgdb_arch_exit(void)
> > unregister_die_notifier(&kgdb_notifier);
> > }
> >
> > -/*
> > - * ARM instructions are always in LE.
> > - * Break instruction is encoded in LE format
> > - */
> > -struct kgdb_arch arch_kgdb_ops = {
> > - .gdb_bpt_instr = {
> > - KGDB_DYN_BRK_INS_BYTE(0),
> > - KGDB_DYN_BRK_INS_BYTE(1),
> > - KGDB_DYN_BRK_INS_BYTE(2),
> > - KGDB_DYN_BRK_INS_BYTE(3),
> > - }
> > -};
> > +struct kgdb_arch arch_kgdb_ops;
> > +
> > +int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> > +{
> > + int err;
> > +
> > + BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
> > +
> > + err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
> > + if (err)
> > + return err;
> > +
> > + return aarch64_insn_write((void *)bpt->bpt_addr,
> > + (u32)AARCH64_BREAK_KGDB_DYN_DBG);
> > +}
> > +
> > +int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> > +{
> > + return aarch64_insn_write((void *)bpt->bpt_addr,
> > + *(u32 *)bpt->saved_instr);
> > +}
> > --
> > 2.10.0
> >
^ permalink raw reply
* [PATCH 0/2] Add R8A7792 MSIOF support
From: Simon Horman @ 2016-09-23 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19842984-5776-0740-7552-f63ce30d4bdd@cogentembedded.com>
On Fri, Sep 23, 2016 at 12:18:52AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 09/05/2016 11:54 PM, Sergei Shtylyov wrote:
>
> > Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
> >'renesas-devel-20160905-v4.8-rc5' tag. We're adding the R8A7792 MSIOF clocks
> >and device nodes. I'm not posting the board patches because the MSIOF driver
> >seems erratic ATM...
> >
> >[1/2] ARM: dts: r8a7792: add MSIOF clock
> >[2/2] ARM: dts: r8a7792: add MSIOF support
>
> These seem stuck for no apparent reason. Simon?
Thanks, I have queued these up.
^ permalink raw reply
* [PATCH v2] arm: dts: zynq: Add MicroZed board support
From: Jagan Teki @ 2016-09-23 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a586da6-8d94-bfbe-ea0c-58b6f8573e7b@xilinx.com>
On Fri, Sep 23, 2016 at 11:33 AM, Michal Simek <michal.simek@xilinx.com> wrote:
> On 22.9.2016 22:59, S?ren Brinkmann wrote:
>> On Thu, 2016-09-22 at 18:51:29 +0530, Jagan Teki wrote:
>>> From: Jagan Teki <jteki@openedev.com>
>>>
>>> Added basic dts support for MicroZed board.
>>>
>>> - UART
>>> - SDHCI
>>> - Ethernet
>>>
>>> Cc: Soren Brinkmann <soren.brinkmann@xilinx.com>
>>> Cc: Michal Simek <michal.simek@xilinx.com>
>>> Signed-off-by: Jagan Teki <jteki@openedev.com>
>>> ---
>>> Changes for v2:
>>> - Add SDHCI
>>> - Add Ethernet
>>>
>>> arch/arm/boot/dts/Makefile | 1 +
>>> arch/arm/boot/dts/zynq-microzed.dts | 95 +++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 96 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index faacd52..4d7b858 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
>>> wm8750-apc8750.dtb \
>>> wm8850-w70v2.dtb
>>> dtb-$(CONFIG_ARCH_ZYNQ) += \
>>> + zynq-microzed.dtb \
>>> zynq-parallella.dtb \
>>> zynq-zc702.dtb \
>>> zynq-zc706.dtb \
>>> diff --git a/arch/arm/boot/dts/zynq-microzed.dts b/arch/arm/boot/dts/zynq-microzed.dts
>>> new file mode 100644
>>> index 0000000..9e64496
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/zynq-microzed.dts
>>> @@ -0,0 +1,95 @@
>>> +/*
>>> + * Copyright (C) 2015 Jagan Teki <jteki@openedev.com>
>
>
> Did you created only yourself without copying part of this from others?
> There is dts in u-boot which I believe you are aware of.
I sent the initial one few months back so at that time, I was created
and now I just added USB and Ethernet with the reference of zc702
board.
thanks!
--
Jagan.
^ 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