<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/arch/arm, branch v3.18.48</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.48</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.48'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-01-15T14:49:51Z</updated>
<entry>
<title>arm/xen: Use alloc_percpu rather than __alloc_percpu</title>
<updated>2017-01-15T14:49:51Z</updated>
<author>
<name>Julien Grall</name>
<email>julien.grall@arm.com</email>
</author>
<published>2016-12-07T12:24:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=16691059c77a6a444b84843683d3e8190058b3f6'/>
<id>urn:sha1:16691059c77a6a444b84843683d3e8190058b3f6</id>
<content type='text'>
[ Upstream commit 24d5373dda7c00a438d26016bce140299fae675e ]

The function xen_guest_init is using __alloc_percpu with an alignment
which are not power of two.

However, the percpu allocator never supported alignments which are not power
of two and has always behaved incorectly in thise case.

Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
introduced a check which trigger a warning [1] when booting linux-next
on Xen. But in reality this bug was always present.

This can be fixed by replacing the call to __alloc_percpu with
alloc_percpu. The latter will use an alignment which are a power of two.

[1]

[    0.023921] illegal size (48) or align (48) for percpu allocation
[    0.024167] ------------[ cut here ]------------
[    0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
[    0.024584] Modules linked in:
[    0.024708]
[    0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.9.0-rc7-next-20161128 #473
[    0.025012] Hardware name: Foundation-v8A (DT)
[    0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
[    0.025351] PC is at pcpu_alloc+0x88/0x6c0
[    0.025490] LR is at pcpu_alloc+0x88/0x6c0
[    0.025624] pc : [&lt;ffff00000818e678&gt;] lr : [&lt;ffff00000818e678&gt;]
pstate: 60000045
[    0.025830] sp : ffff80003d847cd0
[    0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
[    0.026147] x27: 0000000000000000 x26: 0000000000000000
[    0.026348] x25: 0000000000000000 x24: 0000000000000000
[    0.026549] x23: 0000000000000000 x22: 00000000024000c0
[    0.026752] x21: ffff000008e97000 x20: 0000000000000000
[    0.026953] x19: 0000000000000030 x18: 0000000000000010
[    0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
[    0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
[    0.027573] x13: ffff000008f79c4d x12: 0000000000000041
[    0.027782] x11: 0000000000000006 x10: 0000000000000042
[    0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
[    0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
[    0.028419] x5 : 0000000000000005 x4 : 0000000000000000
[    0.028628] x3 : 0000000000000000 x2 : 000000000000017f
[    0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
[    0.029056]
[    0.029152] ---[ end trace 0000000000000000 ]---
[    0.029297] Call trace:
[    0.029403] Exception stack(0xffff80003d847b00 to
                               0xffff80003d847c30)
[    0.029621] 7b00: 0000000000000030 0001000000000000
ffff80003d847cd0 ffff00000818e678
[    0.029901] 7b20: 0000000000000002 0000000000000004
ffff000008f7c060 0000000000000035
[    0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
ffff80003d847bf0 ffff000008101778
[    0.030402] 7b60: 0000000000000030 0000000000000000
ffff000008e97000 00000000024000c0
[    0.030647] 7b80: 0000000000000000 0000000000000000
0000000000000000 0000000000000000
[    0.030895] 7ba0: 0000000000000035 ffff80003d870000
000000000000017f 0000000000000000
[    0.031144] 7bc0: 0000000000000000 0000000000000005
ffff000008f79c84 6120757063726570
[    0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
0000000000000042 0000000000000006
[    0.031643] 7c00: 0000000000000041 ffff000008f79c4d
ffff000088f79c3f 0000000000000006
[    0.031877] 7c20: 00000000deadbeef 0000000000000a3f
[    0.032051] [&lt;ffff00000818e678&gt;] pcpu_alloc+0x88/0x6c0
[    0.032229] [&lt;ffff00000818ece8&gt;] __alloc_percpu+0x18/0x20
[    0.032409] [&lt;ffff000008d9606c&gt;] xen_guest_init+0x174/0x2f4
[    0.032591] [&lt;ffff0000080830f8&gt;] do_one_initcall+0x38/0x130
[    0.032783] [&lt;ffff000008d90c34&gt;] kernel_init_freeable+0xe0/0x248
[    0.032995] [&lt;ffff00000899a890&gt;] kernel_init+0x10/0x100
[    0.033172] [&lt;ffff000008082ec0&gt;] ret_from_fork+0x10/0x50

Reported-by: Wei Chen &lt;wei.chen@arm.com&gt;
Link: https://lkml.org/lkml/2016/11/28/669
Signed-off-by: Julien Grall &lt;julien.grall@arm.com&gt;
Signed-off-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>ARM: 8617/1: dma: fix dma_max_pfn()</title>
<updated>2016-12-23T14:41:28Z</updated>
<author>
<name>Roger Quadros</name>
<email>rogerq@ti.com</email>
</author>
<published>2016-09-29T07:32:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d884eb7cb82c974de5c8282c06b08edd1d0f2712'/>
<id>urn:sha1:d884eb7cb82c974de5c8282c06b08edd1d0f2712</id>
<content type='text'>
[ Upstream commit d248220f0465b818887baa9829e691fe662b2c5e ]

Since commit 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address translation"),
dma_to_pfn() already returns the PFN with the physical memory start offset
so we don't need to add it again.

This fixes USB mass storage lock-up problem on systems that can't do DMA
over the entire physical memory range (e.g.) Keystone 2 systems with 4GB RAM
can only do DMA over the first 2GB. [K2E-EVM].

What happens there is that without this patch SCSI layer sets a wrong
bounce buffer limit in scsi_calculate_bounce_limit() for the USB mass
storage device. dma_max_pfn() evaluates to 0x8fffff and bounce_limit
is set to 0x8fffff000 whereas maximum DMA'ble physical memory on Keystone 2
is 0x87fffffff. This results in non DMA'ble pages being given to the
USB controller and hence the lock-up.

NOTE: in the above case, USB-SCSI-device's dma_pfn_offset was showing as 0.
This should have really been 0x780000 as on K2e, LOWMEM_START is 0x80000000
and HIGHMEM_START is 0x800000000. DMA zone is 2GB so dma_max_pfn should be
0x87ffff. The incorrect dma_pfn_offset for the USB storage device is because
USB devices are not correctly inheriting the dma_pfn_offset from the
USB host controller. This will be fixed by a separate patch.

Fixes: 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address translation")
Cc: stable@vger.kernel.org
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Santosh Shilimkar &lt;santosh.shilimkar@oracle.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Olof Johansson &lt;olof@lixom.net&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reported-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>ARM: orion: convert the irq_reg_{readl,writel} calls to the new API</title>
<updated>2016-10-10T01:24:19Z</updated>
<author>
<name>Gregory CLEMENT</name>
<email>gregory.clement@free-electrons.com</email>
</author>
<published>2014-11-25T15:19:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fb808fa00a2c784ee1b6b5d38bf557b8a7439f58'/>
<id>urn:sha1:fb808fa00a2c784ee1b6b5d38bf557b8a7439f58</id>
<content type='text'>
[ Upstream commit 2f90bce7ff1f760986d55d9cb3a834e8638b1295 ]

The commit "genirq: Generic chip: Change irq_reg_{readl,writel}
arguments" modified the API. In the same tome the
arch/arm/plat-orion/gpio.c file received a fix with the use of the old
API: "ARM: orion: Fix for certain sequence of request_irq can cause
irq storm". This commit fixes the use of the API.

Signed-off-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Acked-by: Olof Johansson &lt;olof@lixom.net&gt;
Link: https://lkml.kernel.org/r/1416928752-24529-1-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>kvm-arm: Unmap shadow pagetables properly</title>
<updated>2016-10-06T02:40:20Z</updated>
<author>
<name>Suzuki K Poulose</name>
<email>suzuki.poulose@arm.com</email>
</author>
<published>2016-09-08T15:25:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f4e1eb5d3efa7ba4dc1c03495d5fb5dd0838762d'/>
<id>urn:sha1:f4e1eb5d3efa7ba4dc1c03495d5fb5dd0838762d</id>
<content type='text'>
[ Upstream commit 293f293637b55db4f9f522a5a72514e98a541076 ]

On arm/arm64, we depend on the kvm_unmap_hva* callbacks (via
mmu_notifiers::invalidate_*) to unmap the stage2 pagetables when
the userspace buffer gets unmapped. However, when the Hypervisor
process exits without explicit unmap of the guest buffers, the only
notifier we get is kvm_arch_flush_shadow_all() (via mmu_notifier::release
) which does nothing on arm. Later this causes us to access pages that
were already released [via exit_mmap() -&gt; unmap_vmas()] when we actually
get to unmap the stage2 pagetable [via kvm_arch_destroy_vm() -&gt;
kvm_free_stage2_pgd()]. This triggers crashes with CONFIG_DEBUG_PAGEALLOC,
which unmaps any free'd pages from the linear map.

 [  757.644120] Unable to handle kernel paging request at virtual address
  ffff800661e00000
 [  757.652046] pgd = ffff20000b1a2000
 [  757.655471] [ffff800661e00000] *pgd=00000047fffe3003, *pud=00000047fcd8c003,
  *pmd=00000047fcc7c003, *pte=00e8004661e00712
 [  757.666492] Internal error: Oops: 96000147 [#3] PREEMPT SMP
 [  757.672041] Modules linked in:
 [  757.675100] CPU: 7 PID: 3630 Comm: qemu-system-aar Tainted: G      D
 4.8.0-rc1 #3
 [  757.683240] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang Board,
  BIOS 3.06.15 Aug 19 2016
 [  757.692938] task: ffff80069cdd3580 task.stack: ffff8006adb7c000
 [  757.698840] PC is at __flush_dcache_area+0x1c/0x40
 [  757.703613] LR is at kvm_flush_dcache_pmd+0x60/0x70
 [  757.708469] pc : [&lt;ffff20000809dbdc&gt;] lr : [&lt;ffff2000080b4a70&gt;] pstate: 20000145
 ...
 [  758.357249] [&lt;ffff20000809dbdc&gt;] __flush_dcache_area+0x1c/0x40
 [  758.363059] [&lt;ffff2000080b6748&gt;] unmap_stage2_range+0x458/0x5f0
 [  758.368954] [&lt;ffff2000080b708c&gt;] kvm_free_stage2_pgd+0x34/0x60
 [  758.374761] [&lt;ffff2000080b2280&gt;] kvm_arch_destroy_vm+0x20/0x68
 [  758.380570] [&lt;ffff2000080aa330&gt;] kvm_put_kvm+0x210/0x358
 [  758.385860] [&lt;ffff2000080aa524&gt;] kvm_vm_release+0x2c/0x40
 [  758.391239] [&lt;ffff2000082ad234&gt;] __fput+0x114/0x2e8
 [  758.396096] [&lt;ffff2000082ad46c&gt;] ____fput+0xc/0x18
 [  758.400869] [&lt;ffff200008104658&gt;] task_work_run+0x108/0x138
 [  758.406332] [&lt;ffff2000080dc8ec&gt;] do_exit+0x48c/0x10e8
 [  758.411363] [&lt;ffff2000080dd5fc&gt;] do_group_exit+0x6c/0x130
 [  758.416739] [&lt;ffff2000080ed924&gt;] get_signal+0x284/0xa18
 [  758.421943] [&lt;ffff20000808a098&gt;] do_signal+0x158/0x860
 [  758.427060] [&lt;ffff20000808aad4&gt;] do_notify_resume+0x6c/0x88
 [  758.432608] [&lt;ffff200008083624&gt;] work_pending+0x10/0x14
 [  758.437812] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20)

This patch fixes the issue by moving the kvm_free_stage2_pgd() to
kvm_arch_flush_shadow_all().

Cc: &lt;stable@vger.kernel.org&gt; # 3.9+
Tested-by: Itaru Kitayama &lt;itaru.kitayama@riken.jp&gt;
Reported-by: Itaru Kitayama &lt;itaru.kitayama@riken.jp&gt;
Reported-by: James Morse &lt;james.morse@arm.com&gt;
Cc: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Signed-off-by: Suzuki K Poulose &lt;suzuki.poulose@arm.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx</title>
<updated>2016-10-04T04:57:31Z</updated>
<author>
<name>Anson Huang</name>
<email>Anson.Huang@nxp.com</email>
</author>
<published>2016-08-22T15:53:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3294908b6d56d3232c338fac2a2461dafaac93d6'/>
<id>urn:sha1:3294908b6d56d3232c338fac2a2461dafaac93d6</id>
<content type='text'>
[ Upstream commit 8aade778f787305fdbfd3c1d54e6b583601b5902 ]

i.MX6SX has bypass PMIC ready function, as this function
is normally NOT enabled on the board design, so we need
to bypass the PMIC ready pin check during DSM mode resume
flow, otherwise, the internal DSM resume logic will be
waiting for this signal to be ready forever and cause
resume fail.

Signed-off-by: Anson Huang &lt;Anson.Huang@nxp.com&gt;
Fixes: ff843d621bfc ("ARM: imx: add suspend support for i.mx6sx")
Cc: &lt;stable@vger.kernel.org&gt;
Tested-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>ARM: kirkwood: ib62x0: fix size of u-boot environment partition</title>
<updated>2016-10-04T04:53:44Z</updated>
<author>
<name>Simon Baatz</name>
<email>gmbnomis@gmail.com</email>
</author>
<published>2016-08-12T17:12:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d0a2d41031c85163c28df36db153c7a69795c9bf'/>
<id>urn:sha1:d0a2d41031c85163c28df36db153c7a69795c9bf</id>
<content type='text'>
[ Upstream commit a778937888867aac17a33887d1c429120790fbc2 ]

Commit 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment
partition") split the "u-boot" partition into "u-boot" and "u-boot
environment".  However, instead of the size of the environment, an offset
was given, resulting in overlapping partitions.

Signed-off-by: Simon Baatz &lt;gmbnomis@gmail.com&gt;
Fixes: 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment partition")
Cc: Jason Cooper &lt;jason@lakedaemon.net&gt;
Cc: Andrew Lunn &lt;andrew@lunn.ch&gt;
Cc: Gregory Clement &lt;gregory.clement@free-electrons.com&gt;
Cc: Sebastian Hesselbarth &lt;sebastian.hesselbarth@gmail.com&gt;
Cc: Luka Perkov &lt;luka@openwrt.org&gt;
Cc: stable@vger.kernel.org # 3.13+
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>ARM: OMAP3: hwmod data: Add sysc information for DSI</title>
<updated>2016-10-04T04:44:42Z</updated>
<author>
<name>Sebastian Reichel</name>
<email>sre@kernel.org</email>
</author>
<published>2016-06-24T01:59:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=177b489883ed5dbe2238cf65b8162d9024a9a3ee'/>
<id>urn:sha1:177b489883ed5dbe2238cf65b8162d9024a9a3ee</id>
<content type='text'>
[ Upstream commit b46211d6dcfb81a8af66b8684a42d629183670d4 ]

Add missing sysconfig/sysstatus information
to OMAP3 hwmod. The information has been
checked against OMAP34xx and OMAP36xx TRM.

Without this change DSI block is not reset
during boot, which is required for working
Nokia N950 display.

Signed-off-by: Sebastian Reichel &lt;sre@kernel.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>[PATCH] arm: fix handling of F_OFD_... in oabi_fcntl64()</title>
<updated>2016-09-11T13:57:24Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2015-12-29T01:47:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=db9e37a1c5f21cec095da9ed53a2c0cbeeb24ee6'/>
<id>urn:sha1:db9e37a1c5f21cec095da9ed53a2c0cbeeb24ee6</id>
<content type='text'>
[ Upstream commit 76cc404bfdc0d419c720de4daaf2584542734f42 ]

Cc: stable@vger.kernel.org # 3.15+
Reviewed-by: Jeff Layton &lt;jeff.layton@primarydata.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>ARM: dts: sunxi: Add a startup delay for fixed regulator enabled phys</title>
<updated>2016-08-22T16:23:04Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2016-06-04T10:58:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=926d244dfa891826a40d6af950209c3b90868149'/>
<id>urn:sha1:926d244dfa891826a40d6af950209c3b90868149</id>
<content type='text'>
[ Upstream commit fc51b632c7b047c25807023b76f3877aed19c770 ]

It seems that recent kernels have a shorter timeout when scanning for
ethernet phys causing us to hit a timeout on boards where the phy's
regulator gets enabled just before scanning, which leads to non working
ethernet.

A 10ms startup delay seems to be enough to fix it, this commit adds a
20ms startup delay just to be safe.

This has been tested on a sun4i-a10-a1000 and sun5i-a10s-wobo-i5 board,
both of which have non-working ethernet on recent kernels without this
fix.

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Maxime Ripard &lt;maxime.ripard@free-electrons.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>ARM: mvebu: fix HW I/O coherency related deadlocks</title>
<updated>2016-08-08T01:44:33Z</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2016-06-16T13:42:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=06c742fbf4877d958cdf9d225480a45863461a06'/>
<id>urn:sha1:06c742fbf4877d958cdf9d225480a45863461a06</id>
<content type='text'>
[ Upstream commit c5379ba8fccd99d5f99632c789f0393d84a57805 ]

Until now, our understanding for HW I/O coherency to work on the
Cortex-A9 based Marvell SoC was that only the PCIe regions should be
mapped strongly-ordered. However, we were still encountering some
deadlocks, especially when testing the CESA crypto engine. After
checking with the HW designers, it was concluded that all the MMIO
registers should be mapped as strongly ordered for the HW I/O coherency
mechanism to work properly.

This fixes some easy to reproduce deadlocks with the CESA crypto engine
driver (dmcrypt on a sufficiently large disk partition).

Tested-by: Terry Stockert &lt;stockert@inkblotadmirer.me&gt;
Tested-by: Romain Perier &lt;romain.perier@free-electrons.com&gt;
Cc: Terry Stockert &lt;stockert@inkblotadmirer.me&gt;
Cc: Romain Perier &lt;romain.perier@free-electrons.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
</feed>
