* [PATCH] ARM: dts: NSP: Fix DT ranges error
From: Jon Mason @ 2017-01-12 15:50 UTC (permalink / raw)
To: linux-arm-kernel
The range size for axi is 0x2 bytes too small, as the QSPI needs
0x11c408 + 0x004 (which is 0x0011c40c, not 0x0011c40a). No errors have
been observed with this shortcoming, but fixing it for correctness.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 6c58c78..832795b 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -160,7 +160,7 @@
axi {
compatible = "simple-bus";
- ranges = <0x00000000 0x18000000 0x0011c40a>;
+ ranges = <0x00000000 0x18000000 0x0011c40c>;
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Nicolas Dichtel @ 2017-01-12 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109125638.GA15506@infradead.org>
Le 09/01/2017 ? 13:56, Christoph Hellwig a ?crit :
> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>> Regularly, when a new header is created in include/uapi/, the developer
>> forgets to add it in the corresponding Kbuild file. This error is usually
>> detected after the release is out.
>>
>> In fact, all headers under uapi directories should be exported, thus it's
>> useless to have an exhaustive list.
>>
>> After this patch, the following files, which were not exported, are now
>> exported (with make headers_install_all):
>
> ... snip ...
>
>> linux/genwqe/.install
>> linux/genwqe/..install.cmd
>> linux/cifs/.install
>> linux/cifs/..install.cmd
>
> I'm pretty sure these should not be exported!
>
Those files are created in every directory:
$ find usr/include/ -name '\.\.install.cmd' | wc -l
71
$ find usr/include/ -name '\.install' | wc -l
71
See also
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.headersinst#n32
Thank you,
Nicolas
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Catalin Marinas @ 2017-01-12 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <278a45c0-bd49-b8a2-63ae-80ad851bab9b@arm.com>
On Wed, Jan 11, 2017 at 06:22:08PM +0000, Marc Zyngier wrote:
> On 11/01/17 18:06, Catalin Marinas wrote:
> > On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote:
> >> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> >> index 32682be..9ee46df 100644
> >> --- a/arch/arm64/mm/proc.S
> >> +++ b/arch/arm64/mm/proc.S
> >> @@ -23,6 +23,7 @@
> >> #include <asm/assembler.h>
> >> #include <asm/asm-offsets.h>
> >> #include <asm/hwcap.h>
> >> +#include <asm/mmu_context.h>
> >> #include <asm/pgtable.h>
> >> #include <asm/pgtable-hwdef.h>
> >> #include <asm/cpufeature.h>
> >> @@ -140,6 +141,18 @@ ENDPROC(cpu_do_resume)
> >> ENTRY(cpu_do_switch_mm)
> >> mmid x1, x1 // get mm->context.id
> >> bfi x0, x1, #48, #16 // set the ASID
> >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
> >> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
> >> + mrs x2, ttbr0_el1
> >> + mov x3, #FALKOR_RESERVED_ASID
> >> + bfi x2, x3, #48, #16 // reserved ASID + old BADDR
> >> + msr ttbr0_el1, x2
> >> + isb
> >> + bfi x2, x0, #0, #48 // reserved ASID + new BADDR
> >> + msr ttbr0_el1, x2
> >> + isb
> >> +alternative_else_nop_endif
> >> +#endif
> >> msr ttbr0_el1, x0 // set TTBR0
> >> isb
> >> post_ttbr0_update_workaround
> >
> > Please move the above hunk to a pre_ttbr0_update_workaround macro for
> > consistency with post_ttbr0_update_workaround.
>
> In which case (and also for consistency), should we add that pre_ttbr0
> macro to entry.S, just before __uaccess_ttbr0_enable? It may not be
> needed in the SW pan case, but it is probably worth entertaining the
> idea that there may be something to do there...
It may actually be needed in entry.S as well. With SW PAN, we move the
context switching from cpu_do_switch_mm to the kernel_exit macro when
returning to user. In this case we are switching from the reserved ASID
0 and reserved TTBR0_EL1 (pointing to a zeroed page) to the user's
TTBR0_EL1 and ASID. If the ASID switch isn't taken into account, we may
end up with new TLB entries being tagged with the reserved ASID. Apart
from a potential loss of protection with TTBR0 PAN, is there anything
else that could go wrong? Maybe a TLB conflict if we mix TLBs from
multiple address spaces tagged with the same reserved ASID.
If the above is an issue, we would need to patch
__uaccess_ttbr0_enable() as well, though I'm more inclined to make this
erratum not selectable when TTBR0 PAN is enabled.
--
Catalin
^ permalink raw reply
* [RFC 00/13] vITS save/restore
From: Eric Auger @ 2017-01-12 15:56 UTC (permalink / raw)
To: linux-arm-kernel
This series specifies and implements an API aimed at saving and restoring
the state of the in-kernel emulated ITS device.
The ITS is programmed through registers and tables. Those later tables
are allocated by the guest. Their base address is programmed in
registers or table entries before the ITS is enabled.
The ITS is free to use some of them to flush its internal caches. This
is likely to be used when entering low power state.
Therefore, for save/restore use case, it looks natural to use this
guest RAM allocated space to save the table related data. However,
currently,The ITS in-kernel emulated device does not use all of those
tables and for those it uses, it does not always sync them with its
cached data. Additional sync must happen for:
- the collection table
- the device table
- the per-device translation tables
- the LPI pending tables.
The LPI configration table and the command queues do not need extra
syncs.
So the bulk of the work in this series consists in the table
save/restore rather than register save/restore.
An alternative to flushing the tables into guest RAM could have been
to flush them into a separate user-space buffer. However the drawback
of this alternative is that the virtualizer would allocate dedicated
buffers to store the data that should normally be laid out in guest
RAM. It would also be obliged to re-compute their size from
register/table content.
So saving the tables in guest RAM better fit the ITS programming
model and optimizes the memory usage. The drawback of this solution
is it brings additional challenges at user-space level to make sure
the guest RAM is frozen after table sync.
The code is functional while saving/restoring a guest using
virtio-net-pci. However many points deserve additional tests.
I share the series at that stage to get the documentation reviewed
and main principles discussed.
The series applies on top of Vijaya's series:
- [PATCH v10 0/8] arm/arm64: vgic: Implement API for vGICv3 live
migration
http://www.spinics.net/lists/arm-kernel/msg546383.html
Best Regards
Eric
Git: complete series available at
https://github.com/eauger/linux/tree/v4.10-rc3-its-mig-rfc-v1
* Testing:
- on Cavium using a virtio-net-pci guest and virsh save/restore
commands
Eric Auger (13):
KVM: arm/arm64: Add vITS save/restore API documentation
arm/arm64: vgic: turn vgic_find_mmio_region into public
KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_REGS group
KVM: arm64: ITS: Implement vgic_its_has_attr_regs and attr_regs_access
KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_creadr
KVM: arm64: ITS: Expose ITT_Entry_Size in GITS_TYPER
KVM: arm64: ITS: Change entry_size and indirect bit in BASER
KVM: arm64: ITS: On MAPD interpret and store itt_addr and size
KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_TABLES group
KVM: arm64: ITS: vgic_its_alloc_itte/device
KVM: arm64: ITS: Collection table save/restore
KVM: arm64: ITS: Device and translation table flush
KVM: arm64: ITS: Pending table save/restore
Documentation/virtual/kvm/devices/arm-vgic-its.txt | 70 +++
arch/arm/include/uapi/asm/kvm.h | 2 +
arch/arm64/include/uapi/asm/kvm.h | 2 +
include/kvm/arm_vgic.h | 3 +
include/linux/irqchip/arm-gic-v3.h | 1 +
virt/kvm/arm/vgic/vgic-its.c | 655 +++++++++++++++++++--
virt/kvm/arm/vgic/vgic-mmio.c | 3 +-
virt/kvm/arm/vgic/vgic-mmio.h | 14 +-
8 files changed, 705 insertions(+), 45 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH] arm64: assembler: make adr_l work in modules under KASLR
From: Catalin Marinas @ 2017-01-12 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112154420.GE13843@arm.com>
On Thu, Jan 12, 2017 at 03:44:20PM +0000, Will Deacon wrote:
> On Wed, Jan 11, 2017 at 02:54:53PM +0000, Ard Biesheuvel wrote:
> > When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
> > modules and the core kernel may exceed 4 GB, putting symbols exported
> > by the core kernel out of the reach of the ordinary adrp/add instruction
> > pairs used to generate relative symbol references. So make the adr_l
> > macro emit a movz/movk sequence instead when executing in module context.
> >
> > While at it, remove the pointless special case for the stack pointer.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > arch/arm64/include/asm/assembler.h | 36 +++++++++++++++-----
> > 1 file changed, 27 insertions(+), 9 deletions(-)
>
> Given that you need this for 4.11, I suggest Catalin takes it as a fix
> for 4.10 to avoid the crypto dependency.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
That's fine by me. Thanks for the ack.
--
Catalin
^ permalink raw reply
* [PATCH v3] arm64: mm: Fix NOMAP page initialization
From: Will Deacon @ 2017-01-12 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109115320.GI4930@rric.localdomain>
Hi Robert,
On Mon, Jan 09, 2017 at 12:53:20PM +0100, Robert Richter wrote:
> On 06.01.17 08:37:25, Ard Biesheuvel wrote:
> > Any comments on the performance impact (including boot time) ?
>
> I did a kernel compile test and kernel mode time increases by about
> 2.2%. Though this is already significant, we need a more suitable mem
> benchmark here for further testing.
Thanks for doing this.
> For boot time I dont see significant changes.
>
> -Robert
>
>
> Boot times:
>
> pfn_valid_within():
> [ 25.929134]
> [ 25.548830]
> [ 25.503225]
>
> early_pfn_valid() v3:
> [ 25.773814]
> [ 25.548428]
> [ 25.765290]
>
>
> Kernel compile times (3 runs each):
>
> pfn_valid_within():
>
> real 6m4.088s
> user 372m57.607s
> sys 16m55.158s
>
> real 6m1.532s
> user 372m48.453s
> sys 16m50.370s
>
> real 6m4.061s
> user 373m18.753s
> sys 16m57.027s
Did you reboot the machine between each build here, or only when changing
kernel? If the latter, do you see variations in kernel build time by simply
rebooting the same Image?
Will
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Will Deacon @ 2017-01-12 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112155558.ud4ln3lk5lpwxrq3@localhost>
On Thu, Jan 12, 2017 at 03:55:58PM +0000, Catalin Marinas wrote:
> On Wed, Jan 11, 2017 at 06:22:08PM +0000, Marc Zyngier wrote:
> > On 11/01/17 18:06, Catalin Marinas wrote:
> > > On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote:
> > >> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> > >> index 32682be..9ee46df 100644
> > >> --- a/arch/arm64/mm/proc.S
> > >> +++ b/arch/arm64/mm/proc.S
> > >> @@ -23,6 +23,7 @@
> > >> #include <asm/assembler.h>
> > >> #include <asm/asm-offsets.h>
> > >> #include <asm/hwcap.h>
> > >> +#include <asm/mmu_context.h>
> > >> #include <asm/pgtable.h>
> > >> #include <asm/pgtable-hwdef.h>
> > >> #include <asm/cpufeature.h>
> > >> @@ -140,6 +141,18 @@ ENDPROC(cpu_do_resume)
> > >> ENTRY(cpu_do_switch_mm)
> > >> mmid x1, x1 // get mm->context.id
> > >> bfi x0, x1, #48, #16 // set the ASID
> > >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
> > >> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
> > >> + mrs x2, ttbr0_el1
> > >> + mov x3, #FALKOR_RESERVED_ASID
> > >> + bfi x2, x3, #48, #16 // reserved ASID + old BADDR
> > >> + msr ttbr0_el1, x2
> > >> + isb
> > >> + bfi x2, x0, #0, #48 // reserved ASID + new BADDR
> > >> + msr ttbr0_el1, x2
> > >> + isb
> > >> +alternative_else_nop_endif
> > >> +#endif
> > >> msr ttbr0_el1, x0 // set TTBR0
> > >> isb
> > >> post_ttbr0_update_workaround
> > >
> > > Please move the above hunk to a pre_ttbr0_update_workaround macro for
> > > consistency with post_ttbr0_update_workaround.
> >
> > In which case (and also for consistency), should we add that pre_ttbr0
> > macro to entry.S, just before __uaccess_ttbr0_enable? It may not be
> > needed in the SW pan case, but it is probably worth entertaining the
> > idea that there may be something to do there...
>
> It may actually be needed in entry.S as well. With SW PAN, we move the
> context switching from cpu_do_switch_mm to the kernel_exit macro when
> returning to user. In this case we are switching from the reserved ASID
> 0 and reserved TTBR0_EL1 (pointing to a zeroed page) to the user's
> TTBR0_EL1 and ASID. If the ASID switch isn't taken into account, we may
> end up with new TLB entries being tagged with the reserved ASID. Apart
> from a potential loss of protection with TTBR0 PAN, is there anything
> else that could go wrong? Maybe a TLB conflict if we mix TLBs from
> multiple address spaces tagged with the same reserved ASID.
>
> If the above is an issue, we would need to patch
> __uaccess_ttbr0_enable() as well, though I'm more inclined to make this
> erratum not selectable when TTBR0 PAN is enabled.
I don't think that's a reasonable approach. By all means change the
default, but we need to support kernel images with both of these kconfig
options enabled.
Will
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-12 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112154548.twj2ktbfzbsarzbc@localhost>
On Thu, Jan 12, 2017 at 03:45:48PM +0000, Catalin Marinas wrote:
> On Wed, Jan 11, 2017 at 06:40:52PM +0000, Mark Rutland wrote:
> > Likewise, I beleive we may need to modify cpu_set_reserved_ttbr0().
>
> This may be fine if my assumptions about this erratum are correct. In
> the cpu_set_reserved_ttbr0() case we set TTBR0_EL1 to a table without
> any entries, so no new entries could be tagged with the old ASID.
For some reason, I was under the impression that the issue was old table
entries being allocated to the new ASID. Looking over the series again,
it's not clear to me precisely which cases can occur.
It would be good to see that clarified.
Thanks,
Mark.
^ permalink raw reply
* [Question] New mmap64 syscall?
From: Florian Weimer @ 2017-01-12 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103205437.GA22548@amd>
On 01/03/2017 09:54 PM, Pavel Machek wrote:
> ...actually, with strace and batched interface, it will be impossible
> to see what is going on because of races. So I'm not sure if I like
> the batched interface at all...
I'm not sure if I understand this problem.
ioctl, fcntl, most socket system calls, even open all have this problem
as well, right?
Thanks,
Florian
^ permalink raw reply
* [PATCH] KVM: arm/arm64: vgic: Fix deadlock on error handling
From: Marc Zyngier @ 2017-01-12 16:16 UTC (permalink / raw)
To: linux-arm-kernel
Dmitry Vyukov reported that the syzkaller fuzzer triggered a
deadlock in the vgic setup code when an error was detected, as
the cleanup code tries to take a lock that is already held by
the setup code.
The fix is to avoid retaking the lock when cleaning up, by
telling the cleanup function that we already hold it.
Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-init.c | 18 +++++++++++++-----
virt/kvm/arm/vgic/vgic-v2.c | 2 --
virt/kvm/arm/vgic/vgic-v3.c | 2 --
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 5114391..c737ea0 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -268,15 +268,11 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
{
struct vgic_dist *dist = &kvm->arch.vgic;
- mutex_lock(&kvm->lock);
-
dist->ready = false;
dist->initialized = false;
kfree(dist->spis);
dist->nr_spis = 0;
-
- mutex_unlock(&kvm->lock);
}
void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
@@ -286,7 +282,8 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
INIT_LIST_HEAD(&vgic_cpu->ap_list_head);
}
-void kvm_vgic_destroy(struct kvm *kvm)
+/* To be called with kvm->lock held */
+static void __kvm_vgic_destroy(struct kvm *kvm)
{
struct kvm_vcpu *vcpu;
int i;
@@ -297,6 +294,13 @@ void kvm_vgic_destroy(struct kvm *kvm)
kvm_vgic_vcpu_destroy(vcpu);
}
+void kvm_vgic_destroy(struct kvm *kvm)
+{
+ mutex_lock(&kvm->lock);
+ __kvm_vgic_destroy(kvm);
+ mutex_unlock(&kvm->lock);
+}
+
/**
* vgic_lazy_init: Lazy init is only allowed if the GIC exposed to the guest
* is a GICv2. A GICv3 must be explicitly initialized by the guest using the
@@ -348,6 +352,10 @@ int kvm_vgic_map_resources(struct kvm *kvm)
ret = vgic_v2_map_resources(kvm);
else
ret = vgic_v3_map_resources(kvm);
+
+ if (ret)
+ __kvm_vgic_destroy(kvm);
+
out:
mutex_unlock(&kvm->lock);
return ret;
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index 9bab867..834137e 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -293,8 +293,6 @@ int vgic_v2_map_resources(struct kvm *kvm)
dist->ready = true;
out:
- if (ret)
- kvm_vgic_destroy(kvm);
return ret;
}
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index 7df1b90..a4c7fff 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -308,8 +308,6 @@ int vgic_v3_map_resources(struct kvm *kvm)
dist->ready = true;
out:
- if (ret)
- kvm_vgic_destroy(kvm);
return ret;
}
--
2.1.4
^ permalink raw reply related
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-12 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn2pW20VPP_yGtvJ_ufvj6Xj1poBiiA2WqkALiaLyyONug@mail.gmail.com>
>>> > I don't understand scl_period = 1 ?s for Fast Mode. For a bus freqency
>>> > of 400 kHz we need low + high = 2.5 ?s. Is there a factor 10 missing
>>> > somewhere?
>>>
>>> As CCR = SCL_period * I2C parent clk frequency with minimal freq =
>>> 2Mhz and SCL_period = 1 we have:
>>> CCR = 1 * 2Mhz = 2.
>>> But to compute, scl_low and scl_high in Fast mode, we have to do the
>>> following thing as Duty=1:
>>> scl_high = 9 * CCR * I2C parent clk period
>>> scl_low = 16 * CCR * I2C parent clk period
>>> In our example:
>>> scl_high = 9 * 2 * 0,0000005 = 0,000009 sec = 9 ?s
>>> scl_low = 16 * 2 * 0.0000005 = 0,000016 sec = 16 ?s
>>> So low + high = 27 ?s > 2,5 ?s
>>
>> For me 9 ?s + 16 ?s is 25 ?s, resulting in 40 kHz. That's why I wondered
>> if there is a factor 10 missing somewhere.
>
> Hum ok. I am going to double-check what is wrong because when I check
> with the scope I always reach 400Khz for SCL.
> I will let you know.
There is one point I miss here that is described in the reference manual:
To reach the 400 kHz maximum I?C fast mode clock, the I2C parent rate
must be a multiple of 10 MHz.
So, contrary to what we said in a previous thread, 400 kHz could not
be reached with low frequencies.
In that way, we could compute CCR with duty = 0 by default.
So, I find another formula very close to the first one I pushed in the
first version:
In fast mode, we compute CCR with duty = 0:
t_scl_high = CCR * I2C parent clk period
t_scl_low = 2 *CCR * I2C parent clk period
So, CCR = I2C parent rate / 400 kHz / 3
For example with parent rate = 40 MHz:
CCR = 40000000 / 400000 / 3 = 33.333333333 = 33
t_scl_high = 33 * (1 / 2000000) = 825 ns > 600 ns
t_scl_low = 2 * 16 * (1 / 2000000) = 1650 ns > 1300 ns
It seems ok now.
Best regards,
Cedric
^ permalink raw reply
* [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Jan Engelhardt @ 2017-01-12 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <464a1323-4450-e563-ff59-9e6d57b75959@6wind.com>
On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:
>Le 09/01/2017 ? 13:56, Christoph Hellwig a ?crit :
>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>> Regularly, when a new header is created in include/uapi/, the developer
>>> forgets to add it in the corresponding Kbuild file. This error is usually
>>> detected after the release is out.
>>>
>>> In fact, all headers under uapi directories should be exported, thus it's
>>> useless to have an exhaustive list.
>>>
>>> After this patch, the following files, which were not exported, are now
>>> exported (with make headers_install_all):
>>
>> ... snip ...
>>
>>> linux/genwqe/.install
>>> linux/genwqe/..install.cmd
>>> linux/cifs/.install
>>> linux/cifs/..install.cmd
>>
>> I'm pretty sure these should not be exported!
>>
>Those files are created in every directory:
>$ find usr/include/ -name '\.\.install.cmd' | wc -l
>71
That still does not mean they should be exported.
Anything but headers (and directories as a skeleton structure) is maximally suspicious.
^ permalink raw reply
* [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Nicolas Dichtel @ 2017-01-12 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LSU.2.20.1701121727180.19188@erq.vanv.qr>
Le 12/01/2017 ? 17:28, Jan Engelhardt a ?crit :
> On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:
>
>> Le 09/01/2017 ? 13:56, Christoph Hellwig a ?crit :
>>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>>> Regularly, when a new header is created in include/uapi/, the developer
>>>> forgets to add it in the corresponding Kbuild file. This error is usually
>>>> detected after the release is out.
>>>>
>>>> In fact, all headers under uapi directories should be exported, thus it's
>>>> useless to have an exhaustive list.
>>>>
>>>> After this patch, the following files, which were not exported, are now
>>>> exported (with make headers_install_all):
>>>
>>> ... snip ...
>>>
>>>> linux/genwqe/.install
>>>> linux/genwqe/..install.cmd
>>>> linux/cifs/.install
>>>> linux/cifs/..install.cmd
>>>
>>> I'm pretty sure these should not be exported!
>>>
>> Those files are created in every directory:
>> $ find usr/include/ -name '\.\.install.cmd' | wc -l
>> 71
>
> That still does not mean they should be exported.
>
> Anything but headers (and directories as a skeleton structure) is maximally suspicious.
>
What I was trying to say is that I export those directories like other are.
Removing those files is not related to that series.
Regards,
Nicolas
^ permalink raw reply
* [PATCH] arm64: Advertise support for Rounding double multiply instructions
From: Suzuki K Poulose @ 2017-01-12 16:37 UTC (permalink / raw)
To: linux-arm-kernel
ARM v8.1 extensions include support for rounding double multiply
add/subtract instructions to the A64 SIMD instructions set. Let
the userspace know about it via a HWCAP bit.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Applies on top of the MRS CPUID feature emulation series [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/478007.html
---
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/cpuinfo.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 773c90b..61c263c 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -31,5 +31,6 @@
#define HWCAP_FPHP (1 << 9)
#define HWCAP_ASIMDHP (1 << 10)
#define HWCAP_CPUID (1 << 11)
+#define HWCAP_ASIMDRDM (1 << 12)
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index fa707e3..936a129 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -872,6 +872,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SHA2),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_CRC32_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_CRC32),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_ATOMICS_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_ATOMICS),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RDM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDRDM),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_FP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_FPHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 4d44edd..5b22c68 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -64,6 +64,7 @@ static const char *const hwcap_str[] = {
"fphp",
"asimdhp",
"cpuid",
+ "asimdrdm",
NULL
};
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] crypto: picoxcell - Cleanups removing non-DT code
From: Herbert Xu @ 2017-01-12 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483376819-26726-1-git-send-email-javier@osg.samsung.com>
On Mon, Jan 02, 2017 at 02:06:56PM -0300, Javier Martinez Canillas wrote:
> Hello,
>
> This small series contains a couple of cleanups that removes some driver's code
> that isn't needed due the driver being for a DT-only platform.
>
> The changes were suggested by Arnd Bergmann as a response to a previous patch:
> https://lkml.org/lkml/2017/1/2/342
>
> Patch #1 allows the driver to be built when the COMPILE_TEST option is enabled.
> Patch #2 removes the platform ID table since isn't needed for DT-only drivers.
> Patch #3 removes a wrapper function that's also not needed if driver is DT-only.
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: mediatek: don't return garbage err on successful return
From: Herbert Xu @ 2017-01-12 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103132122.26900-1-colin.king@canonical.com>
On Tue, Jan 03, 2017 at 01:21:22PM +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> In the case where keylen <= bs mtk_sha_setkey returns an uninitialized
> return value in err. Fix this by returning 0 instead of err.
>
> Issue detected by static analysis with cppcheck.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/2] crypto: mediatek - remove ARM dependencies
From: Herbert Xu @ 2017-01-12 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111135104.3961730-1-arnd@arndb.de>
On Wed, Jan 11, 2017 at 02:50:19PM +0100, Arnd Bergmann wrote:
> Building the mediatek driver on an older ARM architecture results in a
> harmless warning:
>
> warning: (ARCH_OMAP2PLUS_TYPICAL && CRYPTO_DEV_MEDIATEK) selects NEON which has unmet direct dependencies (VFPv3 && CPU_V7)
>
> We could add an explicit dependency on CPU_V7, but it seems nicer to
> open up the build to additional configurations. This replaces the ARM
> optimized algorithm selection with the normal one that all other drivers
> use, and that in turn lets us relax the dependency on ARM and drop
> a number of the unrelated 'select' statements.
>
> Obviously a real user would still select those other optimized drivers
> as a fallback, but as there is no strict dependency, we can leave that
> up to the user.
>
> Fixes: 785e5c616c84 ("crypto: mediatek - Add crypto driver support for some MediaTek chips")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 2/2] crypto: mediatek - fix format string for 64-bit builds
From: Herbert Xu @ 2017-01-12 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111135601.4047225-1-arnd@arndb.de>
On Wed, Jan 11, 2017 at 02:55:20PM +0100, Arnd Bergmann wrote:
> After I enabled COMPILE_TEST for non-ARM targets, I ran into these
> warnings:
>
> crypto/mediatek/mtk-aes.c: In function 'mtk_aes_info_map':
> crypto/mediatek/mtk-aes.c:224:28: error: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Werror=format=]
> dev_err(cryp->dev, "dma %d bytes error\n", sizeof(*info));
> crypto/mediatek/mtk-sha.c:344:28: error: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Werror=format=]
> crypto/mediatek/mtk-sha.c:550:21: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'size_t {aka long unsigned int}' [-Werror=format=]
>
> The correct format for size_t is %zu, so use that in all three
> cases.
>
> Fixes: 785e5c616c84 ("crypto: mediatek - Add crypto driver support for some MediaTek chips")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11
From: Herbert Xu @ 2017-01-12 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484152915-26517-1-git-send-email-ard.biesheuvel@linaro.org>
On Wed, Jan 11, 2017 at 04:41:48PM +0000, Ard Biesheuvel wrote:
> This adds ARM and arm64 implementations of ChaCha20, scalar AES and SIMD
> AES (using bit slicing). The SIMD algorithms in this series take advantage
> of the new skcipher walksize attribute to iterate over the input in the most
> efficient manner possible.
>
> Patch #1 adds a NEON implementation of ChaCha20 for ARM.
>
> Patch #2 adds a NEON implementation of ChaCha20 for arm64.
>
> Patch #3 modifies the existing NEON and ARMv8 Crypto Extensions implementations
> of AES-CTR to be available as a synchronous skcipher as well. This is intended
> for the mac80211 code, which uses synchronous encapsulations of ctr(aes)
> [ccm, gcm] in softirq context, during which arm64 supports use of SIMD code.
>
> Patch #4 adds a scalar implementation of AES for arm64, using the key schedule
> generation routines and lookup tables of the generic code in crypto/aes_generic.
>
> Patch #5 does the same for ARM, replacing existing scalar code that originated
> in the OpenSSL project, and contains redundant key schedule generation routines
> and lookup tables (and is slightly slower on modern cores)
>
> Patch #6 replaces the ARM bit sliced NEON code with a new implementation that
> has a number of advantages over the original code (which also originated in the
> OpenSSL project.) The performance should be identical.
>
> Patch #7 adds a port of the ARM bit-sliced AES code to arm64, in ECB, CBC, CTR
> and XTS modes.
>
> Due to the size of patch #7, it may be difficult to apply these patches from
> patchwork, so I pushed them here as well:
It seems to have made it.
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] ASoC: sun4i-spdif: Add support for the H3 SoC
From: codekipper at gmail.com @ 2017-01-12 16:45 UTC (permalink / raw)
To: linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
The H3 SoC uses the same SPDIF block as found in earlier SoCs, but its
TXFIFO is mapped to another address.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
sound/soc/sunxi/sun4i-spdif.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index fec62ee1fc72..c03cd07a9b19 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -103,6 +103,8 @@
#define SUN4I_SPDIF_ISTA_RXOSTA BIT(1)
#define SUN4I_SPDIF_ISTA_RXASTA BIT(0)
+#define SUN8I_SPDIF_TXFIFO (0x20)
+
#define SUN4I_SPDIF_TXCNT (0x24)
#define SUN4I_SPDIF_RXCNT (0x28)
@@ -417,6 +419,11 @@ static const struct sun4i_spdif_quirks sun6i_a31_spdif_quirks = {
.has_reset = true,
};
+static const struct sun4i_spdif_quirks sun8i_h3_spdif_quirks = {
+ .reg_dac_txdata = SUN8I_SPDIF_TXFIFO,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_spdif_of_match[] = {
{
.compatible = "allwinner,sun4i-a10-spdif",
@@ -426,6 +433,10 @@ static const struct of_device_id sun4i_spdif_of_match[] = {
.compatible = "allwinner,sun6i-a31-spdif",
.data = &sun6i_a31_spdif_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-h3-spdif",
+ .data = &sun8i_h3_spdif_quirks,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
--
2.11.0
^ permalink raw reply related
* [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11
From: Ard Biesheuvel @ 2017-01-12 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112164504.GD20313@gondor.apana.org.au>
On 12 January 2017 at 16:45, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Jan 11, 2017 at 04:41:48PM +0000, Ard Biesheuvel wrote:
>> This adds ARM and arm64 implementations of ChaCha20, scalar AES and SIMD
>> AES (using bit slicing). The SIMD algorithms in this series take advantage
>> of the new skcipher walksize attribute to iterate over the input in the most
>> efficient manner possible.
>>
>> Patch #1 adds a NEON implementation of ChaCha20 for ARM.
>>
>> Patch #2 adds a NEON implementation of ChaCha20 for arm64.
>>
>> Patch #3 modifies the existing NEON and ARMv8 Crypto Extensions implementations
>> of AES-CTR to be available as a synchronous skcipher as well. This is intended
>> for the mac80211 code, which uses synchronous encapsulations of ctr(aes)
>> [ccm, gcm] in softirq context, during which arm64 supports use of SIMD code.
>>
>> Patch #4 adds a scalar implementation of AES for arm64, using the key schedule
>> generation routines and lookup tables of the generic code in crypto/aes_generic.
>>
>> Patch #5 does the same for ARM, replacing existing scalar code that originated
>> in the OpenSSL project, and contains redundant key schedule generation routines
>> and lookup tables (and is slightly slower on modern cores)
>>
>> Patch #6 replaces the ARM bit sliced NEON code with a new implementation that
>> has a number of advantages over the original code (which also originated in the
>> OpenSSL project.) The performance should be identical.
>>
>> Patch #7 adds a port of the ARM bit-sliced AES code to arm64, in ECB, CBC, CTR
>> and XTS modes.
>>
>> Due to the size of patch #7, it may be difficult to apply these patches from
>> patchwork, so I pushed them here as well:
>
> It seems to have made it.
>
> All applied. Thanks.
Actually, patch #6 was the huge one not #7, and I don't see it in your tree yet.
https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/commit/?h=crypto-arm-v4.11&id=cbf03b255f7c
The order does not matter, though, so could you please put it on top? Thanks.
--
Ard.
^ permalink raw reply
* [PATCH v3 2/3] arm64: dts: juno: fix CoreSight support for Juno r1/r2 variants
From: Mathieu Poirier @ 2017-01-12 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484234410-7670-3-git-send-email-sudeep.holla@arm.com>
On 12 January 2017 at 08:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
> From: Mike Leach <mike.leach@linaro.org>
>
> The CoreSight support added for Juno is valid for only Juno r0.
> The Juno r1 and r2 variants have additional components and alternative
> connection routes between trace source and sinks.
>
> This patch builds on top of the existing r0 support and extends it to
> Juno r1/r2 variants.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> [sudeep.holla at arm.com: minor changelog update and reorganising the common
> coresight components back into juno-base.dtsi to avoid duplication]
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 102 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/arm/juno-r1.dts | 9 +++
> arch/arm64/boot/dts/arm/juno-r2.dts | 9 +++
> 3 files changed, 120 insertions(+)
> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>
> diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> new file mode 100644
> index 000000000000..89fcef366ff9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> @@ -0,0 +1,102 @@
> + csys1_funnel at 20130000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x20130000 0 0x1000>;
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* input port */
> + port at 0 {
> + reg = <0>;
> + csys1_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&etf1_in_port>;
> + };
> + };
> +
> + /* output port */
> + port at 1 {
> + reg = <0>;
> + csys1_funnel_in_port0: endpoint {
> + slave-mode;
> + };
> + };
The comments related to the input and output port are reversed.
> +
> + };
> + };
> +
> + etf1 at 20140000 {
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0 0x20140000 0 0x1000>;
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* input port */
> + port at 0 {
> + reg = <0>;
> + etf1_in_port: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&csys1_funnel_out_port>;
> + };
> + };
> +
> + /* output port */
> + port at 1 {
> + reg = <0>;
> + etf1_out_port: endpoint {
> + remote-endpoint =
> + <&csys2_funnel_in_port1>;
> + };
> + };
> + };
> + };
> +
> + csys2_funnel at 20150000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x20150000 0 0x1000>;
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* output port */
> + port at 0 {
> + reg = <0>;
> + csys2_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&replicator_in_port0>;
> + };
> + };
> +
> + /* input ports */
> + port at 1 {
> + reg = <0>;
> + csys2_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etf0_out_port>;
> + };
> + };
> +
> + port at 2 {
> + reg = <1>;
> + csys2_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etf1_out_port>;
> + };
> + };
> +
> + };
> + };
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> index eec37feee8fc..d4b85d9d343e 100644
> --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -178,6 +178,7 @@
> };
>
> #include "juno-base.dtsi"
> + #include "juno-cs-r1r2.dtsi"
> };
>
> &memtimer {
> @@ -227,3 +228,11 @@
> &gpu1_thermal_zone {
> status = "okay";
> };
> +
> +&etf0_out_port {
> + remote-endpoint = <&csys2_funnel_in_port0>;
> +};
> +
> +&replicator_in_port0 {
> + remote-endpoint = <&csys2_funnel_out_port>;
> +};
> diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
> index 28f40ec44090..14b29517065c 100644
> --- a/arch/arm64/boot/dts/arm/juno-r2.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r2.dts
> @@ -178,6 +178,7 @@
> };
>
> #include "juno-base.dtsi"
> + #include "juno-cs-r1r2.dtsi"
> };
>
> &memtimer {
> @@ -227,3 +228,11 @@
> &gpu1_thermal_zone {
> status = "okay";
> };
> +
> +&etf0_out_port {
> + remote-endpoint = <&csys2_funnel_in_port0>;
> +};
> +
> +&replicator_in_port0 {
> + remote-endpoint = <&csys2_funnel_out_port>;
> +};
> --
> 2.7.4
>
> _______________________________________________
> CoreSight mailing list
> CoreSight at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 4/5] ARM: dts: sunxi: add dtsi file for V3s SoC
From: Maxime Ripard @ 2017-01-12 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111065638.uW1SQ7Kq@smtp3m.mail.yandex.net>
On Wed, Jan 11, 2017 at 11:56:32AM +0800, Icenowy Zheng wrote:
>
> 2017?1?11? 02:21? Maxime Ripard <maxime.ripard@free-electrons.com>???
> >
> > On Tue, Jan 03, 2017 at 11:16:28PM +0800, Icenowy Zheng wrote:
> > > + uart0_pins_a: uart0 at 0 {
> > > + pins = "PB8", "PB9";
> > > + function = "uart0";
> > > + bias-pull-up;
> >
> > Why do you need a pullup here?
>
> I think TX needs one, but RX do not need.
That's (at best) board specific. So it belongs in the DTS if it's
truely needed.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170112/f8f7e9e4/attachment-0001.sig>
^ permalink raw reply
* [RFC 01/13] KVM: arm/arm64: Add vITS save/restore API documentation
From: Marc Zyngier @ 2017-01-12 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484236613-24633-2-git-send-email-eric.auger@redhat.com>
Hi Eric,
On 12/01/17 15:56, Eric Auger wrote:
> Add description for how to access vITS registers and how to flush/restore
> vITS tables into/from memory
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> Documentation/virtual/kvm/devices/arm-vgic-its.txt | 70 ++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> index 6081a5b..bd74613 100644
> --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> @@ -36,3 +36,73 @@ Groups:
> -ENXIO: ITS not properly configured as required prior to setting
> this attribute
> -ENOMEM: Memory shortage when allocating ITS internal data
> +
> + KVM_DEV_ARM_VGIC_GRP_ITS_REGS
> + Attributes:
> + The attr field of kvm_device_attr encodes the offset of the
> + ITS register, relative to the ITS control frame base address
> + (ITS_base).
> +
> + kvm_device_attr.addr points to a __u64 value whatever the width
> + of the addressed register (32/64 bits).
> +
> + Writes to read-only registers are ignored by the kernel except
> + for a single register, GITS_READR. Normally this register is RO
> + but it needs to be restored otherwise commands in the queue will
> + be re-executed after CWRITER setting.
> +
> + For other registers, Getting or setting a register has the same
> + effect as reading/writing the register on real hardware.
> + Errors:
> + -ENXIO: Offset does not correspond to any supported register
> + -EFAULT: Invalid user pointer for attr->addr
> + -EINVAL: Offset is not 64-bit aligned
> +
> + KVM_DEV_ARM_VGIC_GRP_ITS_TABLES
> + Attributes
> + The attr field of kvm_device_attr is not used.
> +
> + request the flush-save/restore of the ITS tables, namely
> + the device table, the collection table, all the ITT tables,
> + the LPI pending tables. On save, the tables are flushed
> + into guest memory at the location provisionned by the guest
provisioned
> + in GITS_BASER (device and collection tables), on MAPD command
> + (ITT_addr), GICR_PENDBASERs (pending tables).
> +
> + This means the GIC should be restored before the ITS and all
> + ITS registers but the GITS_CTRL must be restored before
> + restoring the ITS tables.
> +
> + Note the LPI configuration table is read-only for the
> + in-kernel ITS and its save/restore goes through the standard
> + RAM save/restore.
> +
> + The layout of the tables in guest memory defines an ABI.
> + The entries are laid out in memory as follows;
> +
> + Device Table Entry (DTE) layout: entry size = 16 bytes
> +
> + bits: | 63 ... 32 | 31 ... 6 | 5 | 4 ... 0 |
> + values: | DeviceID | Resv | V | Size |
> +
> + bits: | 63 ... 44 | 43 ... 0 |
> + values: | Resv | ITT_addr |
While I appreciate this layout represents the absolute maximum an ITS
could implement, I'm a bit concerned about the amount of memory we may
end-up requiring here. All the ITSs implementations I know of seem to
get away with 8 bytes per entry. Maybe I'm just too worried.
Also, please mention that ITT_addr is actually ITT_addr[51:8], as we're
guaranteed to have an ITT that is 256 byte aligned.
> +
> + Collection Table Entry (CTE) layout: entry size = 8 bytes
> +
> + bits: | 63| 62 .. 52 | 51 ... 16 | 15 ... 0 |
> + values: | V | RES0 | RDBase | ICID |
> +
> + Interrupt Translation Table Entry (ITTE) layout: entry size = 16 bytes
The actual name is Interrupt Translation Entry (ITE). I have a patch
renaming this all over the vgic-its.c file...
> +
> + bits: | 63 ... 32 | 31 ... 17 | 16 | 15 ... 0 |
> + values: | DeviceID | RES0 | V | ICID |
> +
> + bits: | 63 ... 32 | 31 ... 0 |
> + values: | pINTID | EventID |
Same concern here. 32bit DevID, EventID and INTID seem a bit over the
top. But maybe we shouldn't be concerned about memory... ;-)
> +
> + LPI Pending Table layout:
> +
> + As specified in the ARM Generic Interrupt Controller Architecture
> + Specification GIC Architecture version 3.0 and version 4. The first
> + 1kB contains only zeros.
>
You definitely want to relax this. An ITS implementation is allowed (and
actually encouraged) to maintain a coarse map in the first kB, and use
this to quickly scan the table, which would be very useful on restore.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH v4 0/5] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2017-01-12 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6abvJV1RJtZhD1ixrnVhC5V3PL1+7DdwB+_tVg+vTkaw@mail.gmail.com>
On 12/01/17 10:55, Benjamin Gaignard wrote:
> 2017-01-12 11:35 GMT+01:00 Benjamin Gaignard <benjamin.gaignard@linaro.org>:
>> 2017-01-11 15:34 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>> On 11/01/17 13:17, Benjamin Gaignard wrote:
>>>> 2017-01-10 15:18 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>> Hi,
>>>>>
>>>>> It seem that addition of cache support for M-class cpus uncovered
>>>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>>>> always consistent; however, for R/M classes of cpu memory can be
>>>>> covered by MPU which in turn might configure RAM as Normal
>>>>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>>>>> friends, since data can stuck in caches now or be buffered.
>>>>>
>>>>> This patch set is trying to address the issue by providing region of
>>>>> memory suitable for consistent DMA operations. It is supposed that
>>>>> such region is marked by MPU as non-cacheable. Robin suggested to
>>>>> advertise such memory as reserved shared-dma-pool, rather then using
>>>>> homebrew command line option, and extend dma-coherent to provide
>>>>> default DMA area in the similar way as it is done for CMA (PATCH
>>>>> 2/5). It allows us to offload all bookkeeping on generic coherent DMA
>>>>> framework, and it is seems that it might be reused by other
>>>>> architectures like c6x and blackfin.
>>>>>
>>>>> Dedicated DMA region is required for cases other than:
>>>>> - MMU/MPU is off
>>>>> - cpu is v7m w/o cache support
>>>>> - device is coherent
>>>>>
>>>>> In case one of the above conditions is true dma operations are forced
>>>>> to be coherent and wired with dma_noop_ops.
>>>>>
>>>>> To make life easier NOMMU dma operations are kept in separate
>>>>> compilation unit.
>>>>>
>>>>> Since the issue was reported in the same time as Benjamin sent his
>>>>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>>>>> series (PATCH 1/5 and PATCH 3/5).
>>>>>
>>>>> Thanks!
>>>>
>>>> I have tested this v4 on my setup (stm32f4, no cache, no MPU) and unfortunately
>>>> it doesn't work with my drm/kms driver.
>>>
>>> I guess the same is for fbmem, but would be better to have confirmation since
>>> amba-clcd I use has not been ported to drm/kms (yet), so I can't test.
>>>
>>>> I haven't any errors but nothing is displayed unlike what I have when
>>>> using current dma-mapping
>>>> code.
>>>> I guess the issue is coming from dma-noop where __get_free_pages() is
>>>> used instead of alloc_pages()
>>>> in dma-mapping.
>>>
>>> Unless I've missed something bellow is a call stack for both
>>>
>>> #1
>>> __alloc_simple_buffer
>>> __dma_alloc_buffer
>>> alloc_pages
>>> split_page
>>> __dma_clear_buffer
>>> memset
>>> page_address
>>>
>>> #2
>>> __get_free_pages
>>> alloc_pages
>>> page_address
>>>
>>> So the difference is that nommu case in dma-mapping.c memzeros memory, handles
>>> DMA_ATTR_NO_KERNEL_MAPPING and does optimisation of memory usage.
>>>
>>> Is something from above critical for your driver?
>>
>> I have removed all the diff (split_page, __dma_clear_buffer, memset)
>> from #1 and it is still working.
>> DMA_ATTR_NO_KERNEL_MAPPING flag is not set when allocating the buffer.
>>
>> I have investigated more and found that dma-noop doesn't take care of
>> "dma-ranges" property which is set in DT.
>> I believed that is the root cause of my problem with your patches.
>
> After testing changing virt_to_phys to virt_to_dma in dma-noop.c fix the issue
> modetest and fbdemo are now still functional.
>
Thanks for narrowing it down! I did not noticed that stm32f4 remap its memory,
so dma-ranges property is in use.
It looks like virt_to_dma is ARM specific, so I probably have to discard idea
of reusing dma-noop-ops and switch logic into dma-mapping-nommu.c based on
is_device_dma_coherent(dev) check.
Meanwhile, I'm quite puzzled on how such memory remaping should work together
with reserved memory. It seem it doesn't account dma-ranges while reserving
memory (it is too early) nor while allocating/mapping/etc.
Cheers
Vladimir
>>
>> Benjamin
>>
>>>
>>>>
>>>> Since my hardware doesn't have cache or MPU (and so use dma-noop) I
>>>> haven't reserved specific memory region.
>>>> Buffer addresses and vma parameters look correct... What could I have
>>>> miss here ?
>>>
>>> No ideas, sorry...
>>>
>>> Cheers
>>> Vladimir
>>>
>>>>
>>>> Benjamin
>>>>
>>>>>
>>>>> [1] http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
>>>>>
>>>>> Vladimir Murzin (5):
>>>>> dma: Add simple dma_noop_mmap
>>>>> drivers: dma-coherent: Introduce default DMA pool
>>>>> ARM: NOMMU: Introduce dma operations for noMMU
>>>>> ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
>>>>> ARM: dma-mapping: Remove traces of NOMMU code
>>>>>
>>>>> .../bindings/reserved-memory/reserved-memory.txt | 3 +
>>>>> arch/arm/include/asm/dma-mapping.h | 3 +-
>>>>> arch/arm/mm/Kconfig | 2 +-
>>>>> arch/arm/mm/Makefile | 5 +-
>>>>> arch/arm/mm/dma-mapping-nommu.c | 252 +++++++++++++++++++++
>>>>> arch/arm/mm/dma-mapping.c | 26 +--
>>>>> drivers/base/dma-coherent.c | 59 ++++-
>>>>> lib/dma-noop.c | 21 ++
>>>>> 8 files changed, 335 insertions(+), 36 deletions(-)
>>>>> create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>>>>>
>>>>> --
>>>>> 2.0.0
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Benjamin Gaignard
>>
>> Graphic Study Group
>>
>> Linaro.org ? Open source software for ARM SoCs
>>
>> Follow Linaro: Facebook | Twitter | Blog
>
>
>
^ 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