* [PATCH 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
From: Florian Fainelli @ 2017-04-25 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425223332.6999-1-f.fainelli@gmail.com>
When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/kernel/module.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 80254b47dc34..503d1a39464a 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -40,8 +40,15 @@
#ifdef CONFIG_MMU
void *module_alloc(unsigned long size)
{
- void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
- GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
+ gfp_t gfp_mask = GFP_KERNEL;
+ void *p;
+
+#if IS_ENABLED(CONFIG_ARM_MODULE_PLTS)
+ /* Silence the initial allocation */
+ gfp_mask |= __GFP_NOWARN;
+#endif
+ p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
+ gfp_mask, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
__builtin_return_address(0));
if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
return p;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] mm: Silence vmap() allocation failures based on caller gfp_flags
From: Florian Fainelli @ 2017-04-25 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425223332.6999-1-f.fainelli@gmail.com>
If the caller has set __GFP_NOWARN don't print the following message:
vmap allocation for size 15736832 failed: use vmalloc=<size> to increase
size.
This can happen with the ARM/Linux module loader built with
CONFIG_ARM_MODULE_PLTS=y which does a first attempt at loading a large
module from module space, then falls back to vmalloc space.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0b057628a7ba..5a788eb58741 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -521,7 +521,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
}
}
- if (printk_ratelimit())
+ if (printk_ratelimit() && !(gfp_mask & __GFP_NOWARN))
pr_warn("vmap allocation for size %lu failed: use vmalloc=<size> to increase size\n",
size);
kfree(va);
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
From: Florian Fainelli @ 2017-04-25 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425223332.6999-1-f.fainelli@gmail.com>
When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm64/kernel/module.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 7f316982ce00..58bd5cfdd544 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -32,11 +32,16 @@
void *module_alloc(unsigned long size)
{
+ gfp_t gfp_mask = GFP_KERNEL;
void *p;
+#if IS_ENABLED(CONFIG_ARM64_MODULE_PLTS)
+ /* Silence the initial allocation */
+ gfp_mask |= __GFP_NOWARN;
+#endif
p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
module_alloc_base + MODULES_VSIZE,
- GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
+ gfp_mask, PAGE_KERNEL_EXEC, 0,
NUMA_NO_NODE, __builtin_return_address(0));
if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
--
2.9.3
^ permalink raw reply related
* [PATCH 0/3] ARM/ARM64: silence large module first time allocation
From: Florian Fainelli @ 2017-04-25 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425223332.6999-1-f.fainelli@gmail.com>
On 04/25/2017 03:33 PM, Florian Fainelli wrote:
> With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
> done from module space will fail, produce a general OOM allocation and also a
> vmap warning. The second allocation from vmalloc space may or may not be
> successful, but is actually the one we are interested about in these cases.
>
> This patch series passed __GFP_NOWARN to silence such allocations from the
> ARM/ARM64 module loader's first time allocation when the MODULES_PLT option is
> enabled, and also makes alloc_vmap_area() react to the caller setting
> __GFP_NOWARN to silence "vmap allocation for size..." messages.
>
> Here is an example of what we would get without these two patches, pretty
> scary huh?
Apologies for sending twice the same patches 1/2 and 2/2 should be
discarded...
>
> # insmod /mnt/nfs/huge.ko
> [ 22.114143] random: nonblocking pool is initialized
> [ 22.183575] vmap allocation for size 15736832 failed: use vmalloc=<size> to increase size.
> [ 22.191873] vmalloc: allocation failure: 15729534 bytes
> [ 22.197112] insmod: page allocation failure: order:0, mode:0xd0
> [ 22.203048] CPU: 2 PID: 1506 Comm: insmod Tainted: G O 4.1.20-1.9pre-01082-gbbbff07bc3ce #9
> [ 22.212536] Hardware name: Broadcom STB (Flattened Device Tree)
> [ 22.218480] [<c0017eec>] (unwind_backtrace) from [<c00135c8>] (show_stack+0x10/0x14)
> [ 22.226238] [<c00135c8>] (show_stack) from [<c0638684>] (dump_stack+0x90/0xa4)
> [ 22.233473] [<c0638684>] (dump_stack) from [<c00aae1c>] (warn_alloc_failed+0x104/0x144)
> [ 22.241490] [<c00aae1c>] (warn_alloc_failed) from [<c00d72e0>] (__vmalloc_node_range+0x170/0x218)
> [ 22.250375] [<c00d72e0>] (__vmalloc_node_range) from [<c00147d0>] (module_alloc+0x50/0xac)
> [ 22.258651] [<c00147d0>] (module_alloc) from [<c008ae2c>] (module_alloc_update_bounds+0xc/0x6c)
> [ 22.267360] [<c008ae2c>] (module_alloc_update_bounds) from [<c008b778>] (load_module+0x8ec/0x2058)
> [ 22.276329] [<c008b778>] (load_module) from [<c008cfd4>] (SyS_init_module+0xf0/0x174)
> [ 22.284170] [<c008cfd4>] (SyS_init_module) from [<c0010140>] (ret_fast_syscall+0x0/0x3c)
> [ 22.292277] Mem-Info:
> [ 22.294567] active_anon:5236 inactive_anon:1773 isolated_anon:0
> [ 22.294567] active_file:1 inactive_file:3822 isolated_file:0
> [ 22.294567] unevictable:0 dirty:0 writeback:0 unstable:0
> [ 22.294567] slab_reclaimable:238 slab_unreclaimable:1594
> [ 22.294567] mapped:855 shmem:2950 pagetables:36 bounce:0
> [ 22.294567] free:39031 free_pcp:198 free_cma:3928
> [ 22.327196] DMA free:156124kB min:1880kB low:2348kB high:2820kB active_anon:20944kB inactive_anon:7092kB active_file:4kB inactive_file:15288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:227676kB mlocked:0kB dirty:0kB writeback:0kB mapped:3420kB shmem:11800kB slab_reclaimable:952kB slab_unreclaimable:6376kB kernel_stack:560kB pagetables:144kB unstable:0kB bounce:0kB free_pcp:792kB local_pcp:68kB free_cma:15712kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [ 22.371631] lowmem_reserve[]: 0 0 0 0
> [ 22.375372] HighMem free:0kB min:128kB low:128kB high:128kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2883584kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
> [ 22.416249] lowmem_reserve[]: 0 0 0 0
> [ 22.419986] DMA: 3*4kB (UEM) 4*8kB (UE) 1*16kB (M) 4*32kB (UEMC) 3*64kB (EMC) 1*128kB (E) 4*256kB (UEMC) 2*512kB (UE) 2*1024kB (MC) 4*2048kB (UEMC) 35*4096kB (MRC) = 156156kB
> [ 22.435922] HighMem: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> [ 22.446130] 6789 total pagecache pages
> [ 22.449889] 0 pages in swap cache
> [ 22.453212] Swap cache stats: add 0, delete 0, find 0/0
> [ 22.458447] Free swap = 0kB
> [ 22.461334] Total swap = 0kB
> [ 22.464222] 786432 pages RAM
> [ 22.467110] 720896 pages HighMem/MovableOnly
> [ 22.471388] 725417 pages reserved
> [ 22.474711] 4096 pages cma reserved
> [ 22.511310] big_init: I am a big module using 3932160 bytes of data!
>
> Florian Fainelli (3):
> mm: Silence vmap() allocation failures based on caller gfp_flags
> ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
> arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
>
> arch/arm/kernel/module.c | 11 +++++++++--
> arch/arm64/kernel/module.c | 7 ++++++-
> mm/vmalloc.c | 2 +-
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
--
Florian
^ permalink raw reply
* [v2,1/2] ARM: module: split core and init PLT sections
From: Ard Biesheuvel @ 2017-04-25 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e82258a-92b5-6ff2-49ee-484cd772650a@gmail.com>
On 25 April 2017 at 23:30, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 02/21/2017 02:12 PM, Ard Biesheuvel wrote:
>> Since commit 35fa91eed817 ("ARM: kernel: merge core and init PLTs"),
>> the ARM module PLT code allocates all PLT entries in a single core
>> section, since the overhead of having a separate init PLT section is
>> not justified by the small number of PLT entries usually required for
>> init code.
>>
>> However, the core and init module regions are allocated independently,
>> and there is a corner case where the core region may be allocated from
>> the VMALLOC region if the dedicated module region is exhausted, but the
>> init region, being much smaller, can still be allocated from the module
>> region. This puts the PLT entries out of reach of the relocated branch
>> instructions, defeating the whole purpose of PLTs.
>>
>> So split the core and init PLT regions, and name the latter ".init.plt"
>> so it gets allocated along with (and sufficiently close to) the .init
>> sections that it serves. Also, given that init PLT entries may need to
>> be emitted for branches that target the core module, modify the logic
>> that disregards defined symbols to only disregard symbols that are
>> defined in the same section.
>>
>> Fixes: 35fa91eed817 ("ARM: kernel: merge core and init PLTs")
>> Reported-by: Angus Clark <angus@angusclark.org>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Ard, has this been submitted to Russell's patch tracker? If not, can you
> do it?
>
It's already queued for v4.12:
b7ede5a1f5905ac394cc8e61712a13e3c5cb7b8f
ARM: 8662/1: module: split core and init PLT sections
Regards,
Ard.
^ permalink raw reply
* Duplicate .plt sections warning with CONFIG_ARM_MODULE_PLTS
From: Florian Fainelli @ 2017-04-25 23:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ard,
While using CONFIG_ARM_MODULES_PLTS=y along with a large kernel module,
I was able to have the kernel/module.c::add_sect_attrs() to complain
about duplicate .plt sections found, each section gets its own sysfs
attribute created under /sys/module/<modname>/sections/<sectname>
And indeed the module has the following section headers and contents
(see below). Is this something that looks legit or should we patch
kernel/module.c to detect such duplicates and generate unique sysfs
attribute section names instead? There does not appear to be any
functional issue with that.
Thanks!
Contents of section .plt:
0000 00 .
Contents of section .init.plt:
0001 00 .
Contents of section .plt:
0000 00
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .text PROGBITS 00000000 000034 48d360 00 AX
0 0 4
[ 2] .rel.text REL 00000000 68d0c4 14a980 08
48 1 4
[ 3] .text.unlikely PROGBITS 00000000 48d394 001a30 00 AX
0 0 4
[ 4] .rel.text.unlikel REL 00000000 7d7a44 000700 08
48 3 4
[ 5] .rodata PROGBITS 00000000 48edc8 0b1fa4 00 A
0 0 8
[ 6] .rel.rodata REL 00000000 7d8144 025938 08
48 5 4
[ 7] .rodata.str1.1 PROGBITS 00000000 540d6c 10b88a 01 AMS
0 0 1
[ 8] .ARM.extab.text.u PROGBITS 00000000 64c5f8 000060 00 A
0 0 4
[ 9] .ARM.exidx.text.u ARM_EXIDX 00000000 64c658 000090 00 AL
3 0 4
[10] .rel.ARM.exidx.te REL 00000000 7fda7c 000148 08
48 9 4
[11] __ksymtab_strings PROGBITS 00000000 64c6e8 00da64 00 A
0 0 1
[12] .modinfo PROGBITS 00000000 65a14c 0000a0 00 A
0 0 4
[13] __param PROGBITS 00000000 65a1ec 000020 00 A
0 0 4
[14] .rel__param REL 00000000 7fdbc4 000030 08
48 13 4
[15] .alt.smp.init PROGBITS 00000000 65a20c 000028 00 A
0 0 4
[16] .rel.alt.smp.init REL 00000000 7fdbf4 000028 08
48 15 4
[17] __ex_table PROGBITS 00000000 65a238 000008 00 A
0 0 8
[18] .rel__ex_table REL 00000000 7fdc1c 000010 08
48 17 4
[19] .ARM.extab PROGBITS 00000000 65a240 002730 00 A
0 0 4
[20] .ARM.exidx ARM_EXIDX 00000000 65c970 01b658 00 AL
1 0 4
[21] .rel.ARM.exidx REL 00000000 7fdc2c 01f798 08
48 20 4
[22] __versions PROGBITS 00000000 677fc8 001840 00 A
0 0 4
[23] .note.gnu.build-i NOTE 00000000 679808 000048 00 A
0 0 4
[24] .plt PROGBITS 00000000 679850 000001 00 WA
0 0 1
[25] .init.plt PROGBITS 00000001 679851 000001 00 WA
0 0 1
[26] .plt PROGBITS 00000000 679852 000001 00 WA
0 0 1
[27] .data PROGBITS 00000000 679854 0039e8 00 WA
0 0 4
[28] .rel.data REL 00000000 81d3c4 001ca0 08
48 27 4
[29] .init.plt PROGBITS 00000000 67d23c 000001 00 WA
0 0 1
[30] .gnu.linkonce.thi PROGBITS 00000000 67d240 000168 00 WA
0 0 4
[31] .rel.gnu.linkonce REL 00000000 81f064 000010 08
48 30 4
[32] .bss NOBITS 00000000 67d3a8 04dbac 00 WA
0 0 8
[33] .comment PROGBITS 00000000 67d3a8 009106 01 MS
0 0 1
[34] .note.GNU-stack PROGBITS 00000000 6864ae 000000 00 X
0 0 1
[35] .ARM.attributes ARM_ATTRIBUTES 00000000 6864ae 000031 00
0 0 1
[36] __ksymtab PROGBITS 00000000 6864e0 0036b8 00 A
0 0 4
[37] .rel__ksymtab REL 00000000 81f074 006d70 08
48 36 4
[38] __kcrctab PROGBITS 00000000 689b98 001b5c 00 A
0 0 4
[39] .rel__kcrctab REL 00000000 825de4 0036b8 08
48 38 4
[40] .debug_info PROGBITS 00000000 68b6f4 000490 00
0 0 1
[41] .rel.debug_info REL 00000000 82949c 000408 08
48 40 4
[42] .debug_abbrev PROGBITS 00000000 68bb84 0000f8 00
0 0 1
[43] .debug_aranges PROGBITS 00000000 68bc7c 000018 00
0 0 1
[44] .rel.debug_arange REL 00000000 8298a4 000008 08
48 43 4
[45] .debug_line PROGBITS 00000000 68bc94 000190 00
0 0 1
[46] .debug_str PROGBITS 00000000 68be24 000900 01 MS
0 0 1
[47] .shstrtab STRTAB 00000000 68c724 0001cd 00
0 0 1
[48] .symtab SYMTAB 00000000 8298ac 0ffc50 10
49 49732 4
[49] .strtab STRTAB 00000000 9294fc 0f5791 00
0 0 1
--
Florian
^ permalink raw reply
* [PATCH v2 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt @ 2017-04-25 23:53 UTC (permalink / raw)
To: linux-arm-kernel
Cygnus is a small family of SoCs, of which we currently have
devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
same as 58xx, just requiring a tiny bit of setup that was previously
missing.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
v2: Reorder the entry in the docs (suggestion by Scott Branden), add
missing '"'
Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
drivers/net/dsa/b53/b53_srab.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
index d6c6e41648d4..eb679e92d525 100644
--- a/Documentation/devicetree/bindings/net/dsa/b53.txt
+++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
@@ -13,6 +13,9 @@ Required properties:
"brcm,bcm5397"
"brcm,bcm5398"
+ For the BCM11360 SoC, must be:
+ "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab" string
+
For the BCM5310x SoCs with an integrated switch, must be one of:
"brcm,bcm53010-srab"
"brcm,bcm53011-srab"
diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
index 8a62b6a69703..c37ffd1b6833 100644
--- a/drivers/net/dsa/b53/b53_srab.c
+++ b/drivers/net/dsa/b53/b53_srab.c
@@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm53018-srab" },
{ .compatible = "brcm,bcm53019-srab" },
{ .compatible = "brcm,bcm5301x-srab" },
+ { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID },
@@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID },
+ { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ /* sentinel */ },
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Eric Anholt @ 2017-04-25 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425235357.7690-1-eric@anholt.net>
Cygnus has a single AMAC controller connected to the B53 switch with 2
PHYs. On the BCM911360_EP platform, those two PHYs are connected to
the external ethernet jacks.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
v2: Call the node "switch", just call the ports "port" (suggestions by
Florian), drop max-speed on the phys (suggestion by Andrew Lunn),
call the other nodes "ethernet" and "ethernet-phy" (suggestions by
Sergei Shtylyov)
arch/arm/boot/dts/bcm-cygnus.dtsi | 58 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
2 files changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 009f1346b817..9fd89be0f5e0 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -142,6 +142,54 @@
interrupts = <0>;
};
+ mdio: mdio at 18002000 {
+ compatible = "brcm,iproc-mdio";
+ reg = <0x18002000 0x8>;
+ #size-cells = <1>;
+ #address-cells = <0>;
+
+ gphy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+
+ gphy1: ethernet-phy at 1 {
+ reg = <1>;
+ };
+ };
+
+ switch: switch at 18007000 {
+ compatible = "brcm,bcm11360-srab", "brcm,cygnus-srab";
+ reg = <0x18007000 0x1000>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ phy-handle = <&gphy0>;
+ phy-mode = "rgmii";
+ };
+
+ port at 1 {
+ reg = <1>;
+ phy-handle = <&gphy1>;
+ phy-mode = "rgmii";
+ };
+
+ port at 8 {
+ reg = <8>;
+ label = "cpu";
+ ethernet = <ð0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+
i2c0: i2c at 18008000 {
compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
reg = <0x18008000 0x100>;
@@ -295,6 +343,16 @@
status = "disabled";
};
+ eth0: ethernet at 18042000 {
+ compatible = "brcm,amac";
+ reg = <0x18042000 0x1000>,
+ <0x18110000 0x1000>;
+ reg-names = "amac_base", "idm_base";
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1000>;
+ status = "disabled";
+ };
+
nand: nand at 18046000 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x18046000 0x600>, <0xf8105408 0x600>,
diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts b/arch/arm/boot/dts/bcm911360_entphn.dts
index 8b3800f46288..e037dea63f4a 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -57,6 +57,14 @@
};
};
+ð0 {
+ status = "okay";
+};
+
+&switch {
+ status = "okay";
+};
+
&uart3 {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Florian Fainelli @ 2017-04-25 23:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425235357.7690-2-eric@anholt.net>
On 04/25/2017 04:53 PM, Eric Anholt wrote:
> Cygnus has a single AMAC controller connected to the B53 switch with 2
> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
> the external ethernet jacks.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>
> v2: Call the node "switch", just call the ports "port" (suggestions by
> Florian), drop max-speed on the phys (suggestion by Andrew Lunn),
> call the other nodes "ethernet" and "ethernet-phy" (suggestions by
> Sergei Shtylyov)
>
> arch/arm/boot/dts/bcm-cygnus.dtsi | 58 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
> 2 files changed, 66 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 009f1346b817..9fd89be0f5e0 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -142,6 +142,54 @@
> interrupts = <0>;
> };
>
> + mdio: mdio at 18002000 {
> + compatible = "brcm,iproc-mdio";
> + reg = <0x18002000 0x8>;
> + #size-cells = <1>;
> + #address-cells = <0>;
Sorry for not noticing earlier, since you override this correctly in the
board-level DTS file can you put a:
status = "disabled"
property in there by default?
Thanks!
> +
> + gphy0: ethernet-phy at 0 {
> + reg = <0>;
> + };
> +
> + gphy1: ethernet-phy at 1 {
> + reg = <1>;
> + };
> + };
> +
> + switch: switch at 18007000 {
> + compatible = "brcm,bcm11360-srab", "brcm,cygnus-srab";
> + reg = <0x18007000 0x1000>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + phy-handle = <&gphy0>;
> + phy-mode = "rgmii";
> + };
> +
> + port at 1 {
> + reg = <1>;
> + phy-handle = <&gphy1>;
> + phy-mode = "rgmii";
> + };
> +
> + port at 8 {
> + reg = <8>;
> + label = "cpu";
> + ethernet = <ð0>;
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> +
> i2c0: i2c at 18008000 {
> compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
> reg = <0x18008000 0x100>;
> @@ -295,6 +343,16 @@
> status = "disabled";
> };
>
> + eth0: ethernet at 18042000 {
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
> + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1000>;
> + status = "disabled";
> + };
> +
> nand: nand at 18046000 {
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
> diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts b/arch/arm/boot/dts/bcm911360_entphn.dts
> index 8b3800f46288..e037dea63f4a 100644
> --- a/arch/arm/boot/dts/bcm911360_entphn.dts
> +++ b/arch/arm/boot/dts/bcm911360_entphn.dts
> @@ -57,6 +57,14 @@
> };
> };
>
> +ð0 {
> + status = "okay";
> +};
> +
> +&switch {
> + status = "okay";
> +};
> +
> &uart3 {
> status = "okay";
> };
>
--
Florian
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Andrew Lunn @ 2017-04-26 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425235357.7690-2-eric@anholt.net>
> + eth0: ethernet at 18042000 {
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
> + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1000>;
Hi Eric
Sorry i missed this the first time. Does this Ethernet controller do >
1Gbps? Does this max-speed do anything useful?
Andrew
^ permalink raw reply
* [PATCH] clk: sunxi-ng: Fix dependency on sunxi_gate
From: Chen-Yu Tsai @ 2017-04-26 2:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425171209.6229-1-clabbe.montjoie@gmail.com>
Hi,
Subject should say CCU_GATE, not sunxi_gate, which doesn't exist.
On Wed, Apr 26, 2017 at 1:12 AM, Corentin Labbe
<clabbe.montjoie@gmail.com> wrote:
> When CONFIG_SUNXI_CCU is set but no other SUNXI_CCU is selected i got
> the following build error:
> drivers/built-in.o: In function `ccu_pll_notifier_cb':
> drivers/clk/sunxi-ng/ccu_common.c:71: undefined reference to `ccu_gate_helper_disable'
> drivers/clk/sunxi-ng/ccu_common.c:73: undefined reference to `ccu_gate_helper_enable'
>
> The problem is the function ccu_pll_notifier_cb in ccu_common.c need
> some function from ccu_gate.c which is not compiled since SUNXI_CCU_GATE
> is not selected.
>
> This patch remove SUNXI_CCU_GATE and compile ccu_gate.c unconditionnaly
> since all other combination of options select SUNXI_CCU_GATE finally.
I think it's worth keeping SUNXI_CCU_GATE a separate Kconfig symbol,
and selecting it from SUNXI_CCU.
I think the new helpers aren't in the best place they should be, and
keeping the symbols would make moving them easier. Plus we have symbols
for all the other base types. Keeping it keeps the symmetry there.
Regards
ChenYu
> Fixes: 02ae2bc6febd ("clk: sunxi-ng: Add clk notifier to gate then ungate PLL clocks")
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> drivers/clk/sunxi-ng/Kconfig | 11 -----------
> drivers/clk/sunxi-ng/Makefile | 2 +-
> 2 files changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
> index 8bee225..d7842f9 100644
> --- a/drivers/clk/sunxi-ng/Kconfig
> +++ b/drivers/clk/sunxi-ng/Kconfig
> @@ -15,9 +15,6 @@ config SUNXI_CCU_DIV
> config SUNXI_CCU_FRAC
> bool
>
> -config SUNXI_CCU_GATE
> - bool
> -
> config SUNXI_CCU_MUX
> bool
>
> @@ -32,24 +29,19 @@ config SUNXI_CCU_PHASE
>
> config SUNXI_CCU_NK
> bool
> - select SUNXI_CCU_GATE
>
> config SUNXI_CCU_NKM
> bool
> - select SUNXI_CCU_GATE
>
> config SUNXI_CCU_NKMP
> bool
> - select SUNXI_CCU_GATE
>
> config SUNXI_CCU_NM
> bool
> select SUNXI_CCU_FRAC
> - select SUNXI_CCU_GATE
>
> config SUNXI_CCU_MP
> bool
> - select SUNXI_CCU_GATE
> select SUNXI_CCU_MUX
>
> # SoC Drivers
> @@ -119,7 +111,6 @@ config SUN8I_A33_CCU
> config SUN8I_A83T_CCU
> bool "Support for the Allwinner A83T CCU"
> select SUNXI_CCU_DIV
> - select SUNXI_CCU_GATE
> select SUNXI_CCU_NKMP
> select SUNXI_CCU_NM
> select SUNXI_CCU_MP
> @@ -154,7 +145,6 @@ config SUN9I_A80_CCU
> bool "Support for the Allwinner A80 CCU"
> select SUNXI_CCU_DIV
> select SUNXI_CCU_MULT
> - select SUNXI_CCU_GATE
> select SUNXI_CCU_NKMP
> select SUNXI_CCU_NM
> select SUNXI_CCU_MP
> @@ -165,7 +155,6 @@ config SUN9I_A80_CCU
> config SUN8I_R_CCU
> bool "Support for Allwinner SoCs' PRCM CCUs"
> select SUNXI_CCU_DIV
> - select SUNXI_CCU_GATE
> default MACH_SUN8I || (ARCH_SUNXI && ARM64)
>
> endif
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
> index 78028c8..52aab41 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -1,11 +1,11 @@
> # Common objects
> obj-$(CONFIG_SUNXI_CCU) += ccu_common.o
> obj-$(CONFIG_SUNXI_CCU) += ccu_reset.o
> +obj-$(CONFIG_SUNXI_CCU) += ccu_gate.o
>
> # Base clock types
> obj-$(CONFIG_SUNXI_CCU_DIV) += ccu_div.o
> obj-$(CONFIG_SUNXI_CCU_FRAC) += ccu_frac.o
> -obj-$(CONFIG_SUNXI_CCU_GATE) += ccu_gate.o
> obj-$(CONFIG_SUNXI_CCU_MUX) += ccu_mux.o
> obj-$(CONFIG_SUNXI_CCU_MULT) += ccu_mult.o
> obj-$(CONFIG_SUNXI_CCU_PHASE) += ccu_phase.o
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH] fs: seq_buf_alloc use vmalloc for high order allocations
From: Chunhui Li @ 2017-04-26 3:08 UTC (permalink / raw)
To: linux-arm-kernel
From: "chunhui.li" <chunhui.li@mediatek.com>
Hi Sirs,
I sent this patch on 2017.4.5 but got no response, could you please check it?
Maybe you have concern about the patch, your comments and suggestions are welcome!
Best Regards
For high order allocations, use vmalloc() to reduce physically
contiguous memory consumption and avoid memory fragmentation issues
Signed-off-by: chunhui.li <chunhui.li@mediatek.com>
---
fs/seq_file.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index ca69fb9..4527e79 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -26,19 +26,17 @@ static void seq_set_overflow(struct seq_file *m)
static void *seq_buf_alloc(unsigned long size)
{
void *buf;
- gfp_t gfp = GFP_KERNEL;
/*
- * For high order allocations, use __GFP_NORETRY to avoid oom-killing -
- * it's better to fall back to vmalloc() than to kill things. For small
- * allocations, just use GFP_KERNEL which will oom kill, thus no need
- * for vmalloc fallback.
- */
+ * For high order allocations, use vmalloc() to reduce physically
+ * contiguous memory usage and avoid memory fragmentation issue.
+ * For small allocations, just use GFP_KERNEL
+ * which will oom kill, thus no need for vmalloc fallback.
+ */
if (size > PAGE_SIZE)
- gfp |= __GFP_NORETRY | __GFP_NOWARN;
- buf = kmalloc(size, gfp);
- if (!buf && size > PAGE_SIZE)
buf = vmalloc(size);
+ else
+ buf = kmalloc(size, GFP_KERNEL);
return buf;
}
--
2.9.2
^ permalink raw reply related
* [PATCH] irqchip/mbigen: Fix the clear register offset
From: Hanjun Guo @ 2017-04-26 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493086563-36396-1-git-send-email-majun258@huawei.com>
Hi Majun,
On 2017/4/25 10:16, Majun wrote:
> From: MaJun <majun258@huawei.com>
>
> Don't minus reserved interrupts (64) when get the clear register offset,because
> the clear register space includes the space of these 64 interrupts.
Could you mention the background that there is a timeout mechanism
to clear the register in the mbigen to make the code work even we clear
the wrong (and noneffective) register? that will help for review I
think.
>
> Signed-off-by: MaJun <majun258@huawei.com>
> ---
> drivers/irqchip/irq-mbigen.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 061cdb8..75818a5 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -108,7 +108,6 @@ static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
> {
> unsigned int ofst;
>
> - hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
> ofst = hwirq / 32 * 4;
>
> *mask = 1 << (hwirq % 32);
How about following to save more lines of code:
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -106,10 +106,7 @@ static inline void
get_mbigen_type_reg(irq_hw_number_t hwirq,
static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
u32 *mask, u32 *addr)
{
- unsigned int ofst;
-
- hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
- ofst = hwirq / 32 * 4;
+ unsigned int ofst = hwirq / 32 * 4;
*mask = 1 << (hwirq % 32);
*addr = ofst + REG_MBIGEN_CLEAR_OFFSET;
Thanks
Hanjun
^ permalink raw reply
* [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1
From: Jon Masters @ 2017-04-26 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDkvY_gZwWYfy1dHzBLRwH1S1h3gTN9ib5ixqG4REJuOow@mail.gmail.com>
On 06/03/2016 06:15 PM, Duc Dang wrote:
> Do you have other suggestions? Otherwise, I will prepare a patch
> following Lorenzo's approach.
Duc has since left Applied for other pastures. I miss him, he's a great
guy. He laid all the right groundwork for this, but the ACPI binding
still needs to be upstreamed. It's a few lines of code matching on
APMC0D0E but without it, upstream kernels wont have working MSI on
X-Gene with ACPI. I need this to be upstreamed soon please :) Can
someone at APM followup with an updated patch, and get it in?
Here's the rub. The average person booting a Linux box (even a good
kernel person) isn't going to say "hey, MSIs aren't setup right on this
ARM server because it's compliant with 1 out of 3 possible ways MSIs
might be done at a high level [let's forget the many others] and all it
needs is this...". What they're going to say is "huh, PCIe card doesn't
work, might be an MSI problem". Which is the email I have after someone
tried using an IB card in an X-Gene box and spent a few hours poking.
We're so close to having "ACPI all the things" but the latest
development builds of RHEL don't do MSI on X-Gene because of the Red Hat
"upstream first" rules. So let's get that fixed.
Thanks,
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Viresh Kumar @ 2017-04-26 4:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AJQ2TJvyuiBLLeS9zZMufMxyuNw+MA+NtZPCzzWJ0NXA@mail.gmail.com>
On 25-04-17, 12:24, Fabio Estevam wrote:
> On Tue, Apr 25, 2017 at 11:35 AM, Adam Ford <aford173@gmail.com> wrote:
>
> > I have a touch screen (using tsc2004 touch controller) on my board. I
> > can run some tests if you tell me how you're able to reproduce your
> > issue. I can at least confirm whether or not I see it too. I won't
> > be able to do it until later tonight or tomorrow however.
>
> Just run:
>
> evtest /dev/input/eventX to capture the touchscreen events and keep
> touching the screen.
>
> After some random time (1-2 minutes) evtest will stop capturing the events.
And set the governor to Powersave to make sure we are running on
lowest OPP.
--
viresh
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD and IIO due for the v4.12 merge window
From: Jonathan Cameron @ 2017-04-26 5:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424110239.cv5nylgvymhwvg4w@dell>
On 24/04/17 12:02, Lee Jones wrote:
> On Fri, 14 Apr 2017, Jonathan Cameron wrote:
>
>> On 11/04/17 11:05, Lee Jones wrote:
>>> Enjoy!
>>>
>>> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>>>
>>> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>>>
>>> are available in the git repository at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-iio-v4.12
>>>
>>> for you to fetch changes up to f2499ab450d3052097ba53a7d763f767935c0c59:
>>>
>>> iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs (2017-04-11 11:02:33 +0100)
>>>
>>> ----------------------------------------------------------------
>>> Immutable branch between MFD and IIO due for the v4.12 merge window
>>>
>>> ----------------------------------------------------------------
>>> Quentin Schulz (1):
>>> iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
>>>
>>> drivers/iio/adc/Kconfig | 10 +
>>> drivers/iio/adc/Makefile | 1 +
>>> drivers/iio/adc/axp20x_adc.c | 617 +++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 628 insertions(+)
>>> create mode 100644 drivers/iio/adc/axp20x_adc.c
>>>
>> Hi Lee,
>>
>> Thanks for doing this, but the reason it was going to go through your
>> tree in the first place was a dependency on
>> commit 4707274714ef ("mfd: axp20x: Correct name of temperature data ADC registers")
>>
>> Not present in the immutable branch.
>>
>> There isn't much time for anything else going on around this driver though
>> so other than a possible merge conflict on the Kconfig and Makefile shouldn't
>> matter if this just goes through mfd. (famous last words ;)
>
> It's not as though you committed it to text and sent it out to a
> public mailing list for us all to reference though is it? Doh!
>
It came up in the original discussions (which was the only reason I knew).
Chen-Yu Tsai in email:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/495789.html
Quentin did put a link in his request that you take it, but removing the
need to click would have been better!
Jonathan
^ permalink raw reply
* [PATCH 0/3] drm/sun4i: More cleanups and fixes
From: Maxime Ripard @ 2017-04-26 6:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425152505.6796-1-wens@csie.org>
On Tue, Apr 25, 2017 at 11:25:02PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> The subject is probably getting old. Here are a few more cleanups.
>
> Patch 1 should have been part of the patch
>
> drm/sun4i: Use lists to track registered display backends and TCONs
>
> from my multiple pipeline support series. Please squash it in if you can.
>
> Patch 2 just moves setting the TCON clocks back inside the TCON driver.
>
> Patch 3 cleans up a DRM driver debug message.
Applied all, thanks!
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/20170426/c32dc853/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] iio: adc: meson-saradc: add Meson8b SoC compatibility
From: Jonathan Cameron @ 2017-04-26 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417182820.26670-3-martin.blumenstingl@googlemail.com>
On 17/04/17 19:28, Martin Blumenstingl wrote:
> Meson GX SoCs however use some magic bits to prevent simultaneous (=
> conflicting, because only consumer should use the FIFO buffer with the
> ADC results) usage by the Linux kernel and the bootloader (the BL30
> bootloader uses the SAR ADC to read the CPU temperature).
> This patch changes guards all BL30 functionality so it is skipped on
> SoCs which don't have it. Since the hardware itself doesn't know whether
> BL30 is available the internal meson_sar_adc_data is extended so this
> information can be provided per of_device_id.data inside the driver.
>
> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
> This is already supported by the meson_saradc driver.
>
> Finally a new of_device_id for the Meson8b SoC is added so it can be
> wired up in the corresponding DT.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Fine apart from what superficially looks like a cut and paste error inline...
Jonathan
> ---
> drivers/iio/adc/meson_saradc.c | 80 +++++++++++++++++++++++++++++-------------
> 1 file changed, 56 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index dd4190b50df6..cf13691009ee 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
> };
>
> struct meson_sar_adc_data {
> + bool has_bl30_integration;
> unsigned int resolution;
> const char *name;
> };
> @@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>
> mutex_lock(&indio_dev->mlock);
>
> - /* prevent BL30 from using the SAR ADC while we are using it */
> - regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> - MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> - MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> -
> - /* wait until BL30 releases it's lock (so we can use the SAR ADC) */
> - do {
> - udelay(1);
> - regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> - } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> -
> - if (timeout < 0)
> - return -ETIMEDOUT;
> + if (priv->data->has_bl30_integration) {
> + /* prevent BL30 from using the SAR ADC while we are using it */
> + regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> + MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> + MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> +
> + /*
> + * wait until BL30 releases it's lock (so we can use the SAR
> + * ADC)
> + */
> + do {
> + udelay(1);
> + regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> + } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> +
> + if (timeout < 0)
> + return -ETIMEDOUT;
> + }
>
> return 0;
> }
> @@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
> {
> struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>
> - /* allow BL30 to use the SAR ADC again */
> - regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> - MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> + if (priv->data->has_bl30_integration)
> + /* allow BL30 to use the SAR ADC again */
> + regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> + MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
>
> mutex_unlock(&indio_dev->mlock);
> }
> @@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> */
> meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>
> - /*
> - * leave sampling delay and the input clocks as configured by BL30 to
> - * make sure BL30 gets the values it expects when reading the
> - * temperature sensor.
> - */
> - regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
> - if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> - return 0;
> + if (priv->data->has_bl30_integration) {
> + /*
> + * leave sampling delay and the input clocks as configured by
> + * BL30 to make sure BL30 gets the values it expects when
> + * reading the temperature sensor.
> + */
> + regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
> + if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> + return 0;
> + }
>
> meson_sar_adc_stop_sample_engine(indio_dev);
>
> @@ -834,23 +843,46 @@ static const struct iio_info meson_sar_adc_iio_info = {
> .driver_module = THIS_MODULE,
> };
>
> +struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> + .has_bl30_integration = false,
> + .resolution = 10,
> + .name = "meson-meson8b-saradc",
Not meson-meson8-saradc?
> +};
> +
> +struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> + .has_bl30_integration = false,
> + .resolution = 10,
> + .name = "meson-meson8b-saradc",
> +};
> +
> struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> + .has_bl30_integration = true,
> .resolution = 10,
> .name = "meson-gxbb-saradc",
> };
>
> struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> + .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxl-saradc",
> };
>
> struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> + .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxm-saradc",
> };
>
> static const struct of_device_id meson_sar_adc_of_match[] = {
> {
> + .compatible = "amlogic,meson8-saradc",
> + .data = &meson_sar_adc_meson8_data,
> + },
> + {
> + .compatible = "amlogic,meson8b-saradc",
> + .data = &meson_sar_adc_meson8b_data,
> + },
> + {
> .compatible = "amlogic,meson-gxbb-saradc",
> .data = &meson_sar_adc_gxbb_data,
> }, {
>
^ permalink raw reply
* [PATCH 3/3] iio: adc: meson-saradc: mark all meson_sar_adc_data static and const
From: Jonathan Cameron @ 2017-04-26 6:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417182820.26670-4-martin.blumenstingl@googlemail.com>
On 17/04/17 19:28, Martin Blumenstingl wrote:
> These are only passed as of_device_id.data and never modified. Thus we
> can mark them as static const, just like the of_device_id instances
> where they are used.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reordering the patches would make this simpler as you'd only have
to do the existing ones.
Not a bit issue though so you could just not bother...
Jonathan
> ---
> drivers/iio/adc/meson_saradc.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index cf13691009ee..8f742b71b165 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -843,31 +843,31 @@ static const struct iio_info meson_sar_adc_iio_info = {
> .driver_module = THIS_MODULE,
> };
>
> -struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> .has_bl30_integration = false,
> .resolution = 10,
> .name = "meson-meson8b-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> .has_bl30_integration = false,
> .resolution = 10,
> .name = "meson-meson8b-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> .has_bl30_integration = true,
> .resolution = 10,
> .name = "meson-gxbb-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxl-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxm-saradc",
>
^ permalink raw reply
* [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support
From: Maxime Ripard @ 2017-04-26 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66n6AXbOAh05V_Gv2UgRp=xEMG9qhJU8JSuy4-F-UOQQQ@mail.gmail.com>
Hi Chen-Yu,
On Fri, Apr 21, 2017 at 11:17:17PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
> > controller.
> >
> > That HDMI controller is able to do audio and CEC, but those have been left
> > out for now.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/gpu/drm/sun4i/Makefile | 5 +-
> > drivers/gpu/drm/sun4i/sun4i_hdmi.h | 124 ++++++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 128 ++++++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 449 +++++++++++++++++++++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 236 +++++++++++-
> > 5 files changed, 942 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi.h
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>
> Applying patch #9608371 using 'git am'
> Description: [13/15] drm/sun4i: Add HDMI support
> Applying: drm/sun4i: Add HDMI support
> .git/rebase-apply/patch:116: trailing whitespace.
>
> .git/rebase-apply/patch:531: trailing whitespace.
>
> .git/rebase-apply/patch:701: trailing whitespace.
>
> warning: 3 lines add whitespace errors.
Fixed.
> > +int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *parent)
> > +{
> > + struct clk_init_data init;
> > + struct sun4i_ddc *ddc;
> > + const char *parent_name;
> > +
> > + parent_name = __clk_get_name(parent);
> > + if (!parent_name)
> > + return -ENODEV;
> > +
> > + ddc = devm_kzalloc(hdmi->dev, sizeof(*ddc), GFP_KERNEL);
> > + if (!ddc)
> > + return -ENOMEM;
> > +
> > + init.name = "hdmi-ddc";
> > + init.ops = &sun4i_ddc_ops;
> > + init.parent_names = &parent_name;
> > + init.num_parents = 1;
> > + init.flags = CLK_SET_RATE_PARENT;
>
> I don't think this is really needed. It probably doesn't hurt though,
> since DDC is used when HDMI is not used for displaying, but it might
> affect any upstream PLLs, which theoretically may affect other users
> of said PLLs. The DDC clock is slow enough that we should be able to
> generate a usable clock rate anyway.
Good point, I removed it.
> > + writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
> > + SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
> > +
> > + x = mode->htotal - mode->hsync_start;
> > + y = mode->vtotal - mode->vsync_start;
>
> I'm a bit skeptical about this one. All the other parameters are not
> inclusive of other, why would this one be different? Shouldn't it
> be "Xtotal - Xsync_end" instead?
By the usual meaning of backporch, you're right. However, Allwinner's
seems to have it's own, which is actually the backporch + sync length.
We also have that on all the other connectors (and TCON), and this was
confirmed at the time using a scope on an RGB signal.
>
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_BP_REG);
> > +
> > + x = mode->hsync_start - mode->hdisplay;
> > + y = mode->vsync_start - mode->vdisplay;
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_FP_REG);
> > +
> > + x = mode->hsync_end - mode->hsync_start;
> > + y = mode->vsync_end - mode->vsync_start;
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_SPW_REG);
> > +
> > + val = SUN4I_HDMI_VID_TIMING_POL_TX_CLK;
> > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > + val |= SUN4I_HDMI_VID_TIMING_POL_HSYNC;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > + val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
> > +
> > + writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
>
> You don't handle the interlaced video here, even though you set
>
> hdmi->connector.interlace_allowed = true
>
> later.
I'll fix that.
> The double clock and double scan flags aren't handled either, though
> I don't understand which one is supposed to represent the need for the
> HDMI pixel repeater. AFAIK this is required for resolutions with pixel
> clocks lower than 25 MHz, the lower limit of HDMI's TMDS link.
I'm not sure about this one though. I'd like to keep things quite
simple for now and build up on that once the basis is working. Is it
common in the wild?
> > + hdmi->base + SUN4I_HDMI_DDC_FIFO_CTRL_REG);
> > + writel(SUN4I_HDMI_DDC_ADDR_SEGMENT(offset >> 8) |
> > + SUN4I_HDMI_DDC_ADDR_EDDC(0x60) |
> > + SUN4I_HDMI_DDC_ADDR_OFFSET(offset) |
> > + SUN4I_HDMI_DDC_ADDR_SLAVE(0x50),
>
> You can use DDC_ADDR from drm_edid.h.
Done.
> > +static enum drm_connector_status
> > +sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
> > +{
> > + struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
> > + unsigned long reg;
> > +
> > + if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
> > + reg & SUN4I_HDMI_HPD_HIGH,
> > + 0, 500000))
>
> We shouldn't need to do polling here. It should just return the status
> at the instance it's called. Instead we should have a worker that does
> polling to check if something is plugged or unplugged. I don't see any
> interrupt bits for this though. :(
As far as I know, polling in detect is okay. Why would you want to
remove it?
> > + ret = drm_encoder_init(drm,
> > + &hdmi->encoder,
> > + &sun4i_hdmi_funcs,
> > + DRM_MODE_ENCODER_TMDS,
> > + NULL);
> > + if (ret) {
> > + dev_err(dev, "Couldn't initialise the HDMI encoder\n");
> > + return ret;
> > + }
> > +
> > + hdmi->encoder.possible_crtcs = BIT(0);
>
> You can use drm_of_find_possible_crtcs() now. See the TV encoder driver.
Ack.
> > +
> > + drm_connector_helper_add(&hdmi->connector,
> > + &sun4i_hdmi_connector_helper_funcs);
> > + ret = drm_connector_init(drm, &hdmi->connector,
> > + &sun4i_hdmi_connector_funcs,
> > + DRM_MODE_CONNECTOR_HDMIA);
> > + if (ret) {
> > + dev_err(dev,
> > + "Couldn't initialise the Composite connector\n");
>
> Wrong connector.
Fixed.
> > + ret = sun4i_ddc_create(hdmi, hdmi->tmds_clk);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Couldn't create the DDC clock\n");
> > + return ret;
> > + }
>
> We do all this in the bind function for all the other components.
> Any particular reason to do it differently here?
Not really, I'll change it.
Thanks!
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/20170426/8bb09588/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
From: Jayachandran C. @ 2017-04-26 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425165259.GS24484@arm.com>
Hi Will,
On Tue, Apr 25, 2017 at 10:23 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Apr 25, 2017 at 09:13:40AM +0530, Ganapatrao Kulkarni wrote:
>> On Mon, Apr 24, 2017 at 9:15 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote:
>> >> On Thu, Apr 20, 2017 at 2:19 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> >> > On Wed, Apr 19, 2017 at 11:14:06PM +0530, Ganapatrao Kulkarni wrote:
>> >> >> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running in HYP)
>> >> >> is returning error for perf syscall with mixed attribute set for exclude_kernel
>> >> >> and exclude_hv. This change is breaking some applications (observed with hhvm)
>> >> >> when ran on VHE enabled platforms.
>> >> >>
>> >> >> Adding fix to consider only exclude_kernel attribute when kernel is
>> >> >> running in HYP. Also adding sysfs file to notify the bhehaviour
>> >> >> of attribute exclude_hv.
>> >> >>
>> >> >> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>> >> >> ---
>> >> >>
>> >> >> Changelog:
>> >> >>
>> >> >> V2:
>> >> >> - Changes as per Will Deacon's suggestion.
>> >> >>
>> >> >> V1: Initial patch
>> >> >>
>> >> >> arch/arm64/kernel/perf_event.c | 28 ++++++++++++++++++++++++----
>> >> >> include/linux/perf/arm_pmu.h | 1 +
>> >> >> 2 files changed, 25 insertions(+), 4 deletions(-)
>> >> >>
>> >> >> @@ -871,14 +890,13 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>> >> >>
>> >> >> if (attr->exclude_idle)
>> >> >> return -EPERM;
>> >> >> - if (is_kernel_in_hyp_mode() &&
>> >> >> - attr->exclude_kernel != attr->exclude_hv)
>> >> >> - return -EINVAL;
>> >> >> + if (is_kernel_in_hyp_mode() && !attr->exclude_kernel)
>> >> >> + config_base |= ARMV8_PMU_INCLUDE_EL2;
>> >> >> if (attr->exclude_user)
>> >> >> config_base |= ARMV8_PMU_EXCLUDE_EL0;
>> >> >> if (!is_kernel_in_hyp_mode() && attr->exclude_kernel)
>> >> >> config_base |= ARMV8_PMU_EXCLUDE_EL1;
>> >> >> - if (!attr->exclude_hv)
>> >> >> + if (!is_kernel_in_hyp_mode() && !attr->exclude_hv)
>> >> >> config_base |= ARMV8_PMU_INCLUDE_EL2;
>> >> >
>> >> > This isn't quite what Will suggested.
>> >> >
>> >> > The idea was that userspace would read sysfs, then use that to determine
>> >> > the correct exclusion parameters [1,2]. This logic was not expected to
>> >> > change; it correctly validates whether we can provide what the user
>> >> > requests.
>> >>
>> >> OK, if you are ok with sysfs part, i can send next version with that
>> >> change only?.
>> >
>> > I think the sysfs part is still a little dodgy, since you still expose the
>> > "exclude_hv" file with a value of 0 when not running at EL2, which would
>> > imply that exclude_hv is forced to zero. I don't think that's correct.
>>
>> okay, i can make exclude_hv visible only when kernel booted in EL2.
>> is it ok to have empty directory "attr" when kernel booted to EL1?
>> attr can be place holder for any other miscellaneous attributes, that
>> can be added in future.
>
> Sounds good to me, although I'll seek comment from the other perf folks
> before merging anything with ABI implications.
Do you really think this is the solution given:
- this is an arm64 specific sysfs interface that is tied to the perf API
- the perf API documentation has to be updated for this
- All the applications that use the perf API have to be modified to
check this sysfs interface
- If the application fails to do so, a very narrow corner case
(exclude_hv != exclude_kernel and VHE enabled) fails.
Any application that really cares can already do see if exclude_hv !=
exclude_kernel case works by calling perf_open_event() with those
options and checking the return value.
Hope I am mistake here, otherwise this does not sound like a good idea.
JC.
^ permalink raw reply
* [RFC PATCH 29/30] vfio: Add support for Shared Virtual Memory
From: Tomasz Nowicki @ 2017-04-26 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170227195441.5170-30-jean-philippe.brucker@arm.com>
Hi Jean,
On 27.02.2017 20:54, Jean-Philippe Brucker wrote:
> Add two new ioctl for VFIO devices. VFIO_DEVICE_BIND_TASK creates a bond
> between a device and a process address space, identified by a
> device-specific ID named PASID. This allows the device to target DMA
> transactions at the process virtual addresses without a need for mapping
> and unmapping buffers explicitly in the IOMMU. The process page tables are
> shared with the IOMMU, and mechanisms such as PCI ATS/PRI may be used to
> handle faults. VFIO_DEVICE_UNBIND_TASK removed a bond identified by a
> PASID.
>
> Also add a capability flag in device info to detect whether the system and
> the device support SVM.
>
> Users need to specify the state of a PASID when unbinding, with flags
> VFIO_PASID_RELEASE_FLUSHED and VFIO_PASID_RELEASE_CLEAN. Even for PCI,
> PASID invalidation is specific to each device and only partially covered
> by the specification:
>
> * Device must have an implementation-defined mechanism for stopping the
> use of a PASID. When this mechanism finishes, the device has stopped
> issuing transactions for this PASID and all transactions for this PASID
> have been flushed to the IOMMU.
>
> * Device may either wait for all outstanding PRI requests for this PASID
> to finish, or issue a Stop Marker message, a barrier that separates PRI
> requests affecting this instance of the PASID from PRI requests
> affecting the next instance. In the first case, we say that the PASID is
> "clean", in the second case it is "flushed" (and the IOMMU has to wait
> for the Stop Marker before reassigning the PASID.)
>
> We expect similar distinctions for platform devices. Ideally there should
> be a callback for each PCI device, allowing the IOMMU to ask the device to
> stop using a PASID. When the callback returns, the PASID is either flushed
> or clean and the return value tells which.
>
> For the moment I don't know how to implement this callback for PCI, so if
> the user forgets to call unbind with either "clean" or "flushed", the
> PASID is never reused. For platform devices, it might be simpler to
> implement since we could associate an invalidate_pasid callback to a DT
> compatible string, as is currently done for reset.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> ---
> drivers/vfio/pci/vfio_pci.c | 24 ++++++++++
> drivers/vfio/vfio.c | 104 ++++++++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/vfio.h | 55 +++++++++++++++++++++++
> 3 files changed, 183 insertions(+)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 324c52e3a1a4..3d7733f94891 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -22,6 +22,7 @@
> #include <linux/mutex.h>
> #include <linux/notifier.h>
> #include <linux/pci.h>
> +#include <linux/pci-ats.h>
> #include <linux/pm_runtime.h>
> #include <linux/slab.h>
> #include <linux/types.h>
> @@ -623,6 +624,26 @@ int vfio_pci_register_dev_region(struct vfio_pci_device *vdev,
> return 0;
> }
>
[...]
>
> kfree(device);
> @@ -1622,6 +1651,75 @@ static int vfio_device_fops_release(struct inode *inode, struct file *filep)
> return 0;
> }
>
> +static long vfio_svm_ioctl(struct vfio_device *device, unsigned int cmd,
> + unsigned long arg)
> +{
> + int ret;
> + unsigned long minsz;
> +
> + struct vfio_device_svm svm;
> + struct vfio_task *vfio_task;
> +
> + minsz = offsetofend(struct vfio_device_svm, pasid);
> +
> + if (copy_from_user(&svm, (void __user *)arg, minsz))
> + return -EFAULT;
> +
> + if (svm.argsz < minsz)
> + return -EINVAL;
> +
> + if (cmd == VFIO_DEVICE_BIND_TASK) {
> + struct task_struct *task = current;
> +
> + ret = iommu_bind_task(device->dev, task, &svm.pasid, 0, NULL);
> + if (ret)
> + return ret;
> +
> + vfio_task = kzalloc(sizeof(*vfio_task), GFP_KERNEL);
> + if (!vfio_task) {
> + iommu_unbind_task(device->dev, svm.pasid,
> + IOMMU_PASID_CLEAN);
> + return -ENOMEM;
> + }
> +
> + vfio_task->pasid = svm.pasid;
> +
> + mutex_lock(&device->tasks_lock);
> + list_add(&vfio_task->list, &device->tasks);
> + mutex_unlock(&device->tasks_lock);
> +
> + } else {
> + int flags = 0;
> +
> + if (svm.flags & ~(VFIO_SVM_PASID_RELEASE_FLUSHED |
> + VFIO_SVM_PASID_RELEASE_CLEAN))
> + return -EINVAL;
> +
> + if (svm.flags & VFIO_SVM_PASID_RELEASE_FLUSHED)
> + flags = IOMMU_PASID_FLUSHED;
> + else if (svm.flags & VFIO_SVM_PASID_RELEASE_CLEAN)
> + flags = IOMMU_PASID_CLEAN;
> +
> + mutex_lock(&device->tasks_lock);
> + list_for_each_entry(vfio_task, &device->tasks, list) {
> + if (vfio_task->pasid != svm.pasid)
> + continue;
> +
> + ret = iommu_unbind_task(device->dev, svm.pasid, flags);
> + if (ret)
> + dev_warn(device->dev, "failed to unbind PASID %u\n",
> + vfio_task->pasid);
> +
> + list_del(&vfio_task->list);
> + kfree(vfio_task);
Please use list_for_each_entry_safe.
Thanks,
Tomasz
^ permalink raw reply
* [PATCH] serial: imx: Enable RTSD only when needed
From: Romain Perier @ 2017-04-26 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Anz_C-pxPke_mqCtD_D9LBxTRWSk5fAZrr6KaMeMZGqQ@mail.gmail.com>
Hello all,
Le 12/04/2017 ? 15:38, Fabio Estevam a ?crit :
> On Wed, Apr 12, 2017 at 10:30 AM, Romain Perier
> <romain.perier@collabora.com> wrote:
>> From: Nandor Han <nandor.han@ge.com>
>>
>> Currently, this IRQ is always enabled. Some devices might mux these pins
>> to other I/Os, like I2C. This could lead to spurious interrupts.
>>
>> This commit makes this IRQ optional, by using the field have_rtscts.
>>
>> Signed-off-by: Nandor Han <nandor.han@ge.com>
>> Signed-off-by: Romain Perier <romain.perier@collabora.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
No more feedback on this patch ?
Regards,
Romain
^ permalink raw reply
* [PATCH 2/2] pinctrl: samsung: remove unneeded (void *) casts in of_match_table
From: Krzysztof Kozlowski @ 2017-04-26 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493156063-8446-3-git-send-email-yamada.masahiro@socionext.com>
On Tue, Apr 25, 2017 at 11:34 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> of_device_id::data is an opaque pointer. No explicit cast is needed.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> drivers/pinctrl/samsung/pinctrl-samsung.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
Looks correct. It is too late for me for v4.12 so I will pick it up
for v4.13. For my reference:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Remove the te-gpios property in the TM2 boards
From: Krzysztof Kozlowski @ 2017-04-26 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493085261-3488-1-git-send-email-hoegeun.kwon@samsung.com>
On Tue, Apr 25, 2017 at 3:54 AM, Hoegeun Kwon <hoegeun.kwon@samsung.com> wrote:
> The decon uses HW-TRIGGER, so TE interrupt is not necessary.
> Therefore, remove the te-gpios property in the TM2 dts.
>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1 -
> 1 file changed, 1 deletion(-)
>
Looks correct. It is too late for me for v4.12 so I will pick it up
for v4.13. For my reference:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ 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