* [RFC 0/8] Provide the EL1 physical timer to the VM
From: Jintack Lim @ 2017-01-17 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b15297e4-1b30-27f8-dd43-fb1a85bd2cd5@arm.com>
On Tue, Jan 17, 2017 at 12:09 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 26/12/16 17:11, Jintack Lim wrote:
>> The ARM architecture defines the EL1 physical timer and the virtual
>> timer, and it is reasonable for an OS to expect to be able to access
>> both. However, the current KVM implementation does not provide the EL1
>> physical timer to VMs but terminates VMs on access to the timer.
>>
>> On VHE systems, this would be as simple as allowing full access to the
>> EL1 physical timer to VMs because the KVM host does not use the EL1
>> physical timer. However, on non-VHE systems, the KVM host already uses
>> the EL1 physical timer which prevents us from granting full access of
>> the EL1 physical timer to VMs.
>>
>> This patchset enables VMs to use the EL1 physical timer through
>> trap-and-emulate. The KVM host emulates each EL1 physical timer
>> register access and sets up the background timer accordingly. When the
>> background timer expires, the KVM host injects EL1 physical timer
>> interrupts to the VM. Alternatively, it's also possible to allow VMs to
>> access the EL1 physical timer without trapping. However, this requires
>> somehow using the EL2 physical timer for the Linux host while running
>> the VM instead of the EL1 physical timer. Right now I just implemented
>> trap-and-emulate because this was straightforward to do, and I leave it
>> to future work to determine if transferring the EL1 physical timer state
>> to the EL2 timer provides any performance benefit.
>>
>> This feature will be useful for any OS that wishes to access the EL1
>> physical timer. Nested virtualization is one of those use cases. A
>> nested hypervisor running inside a VM would think it has full access to
>> the hardware and naturally tries to use the EL1 physical timer as Linux
>> would do. Other nested hypervisors may try to use the EL2 physical timer
>> as Xen would do, but supporting the EL2 physical timer to the VM is out
>> of scope of this patchset. This patchset will make it easy to add the
>> EL2 timer support in the future, though.
>>
>> Note, Linux VMs booting in EL1 will be unaffected by this patch set and
>> will continue to use only the virtual timer and this patch set will
>> therefore not introduce any performance degredation as a result of
>> trap-and-emulate.
>
> Hi Jintack,
>
> Any chance you could address Christoffer's comments and respin this
> series? This looks like a good enhancement to our emulation, and
> definitely a requirement for the nested work, so I'm obviously keen on it.
Hi Marc,
Yes, I plan to respin this patch series this week.
Thanks,
Jintack
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
>
^ permalink raw reply
* [PATCH] arm64: mm: fix __page_to_voff definition
From: Mark Rutland @ 2017-01-17 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e57db47e-3c3a-1344-9492-442b37c6897c@gmail.com>
On Tue, Jan 17, 2017 at 07:13:45PM +0200, Oleksandr Andrushchenko wrote:
> On 01/17/2017 06:15 PM, Mark Rutland wrote:
> >On Tue, Jan 17, 2017 at 05:23:53PM +0200, Oleksandr Andrushchenko wrote:
> >>From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
> >>
> >>Fix parameter name for __page_to_voff, to match its definition.
> >>There are other callers of page_to_virt which do not
> >>declare 'page'.
> >>
> >>Fixes: 3fa72fe9c614 ("arm64: mm: fix __page_to_voff definition")
> >>Signed-off-by: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
> >I take it this is because it messes up the 'struct page' at the end of
> >the macro expansion?
> yes, you got it right
> >It would be good to explicitly state that, since that's not immediately
> >obvious.
> Will do that in patch v1
> >
> >With that:
> >
> >Acked-by: Mark Rutland <mark.rutland@arm.com>
> Can I put your ack into the v1?
Yes, with the updated commit message and title, you can add my ack.
W.r.t. wording, I'd recommend:
arm64: mm: avoid name clash in __page_to_voff()
The arm64 __page_to_voff() macro taks a parameter called 'page', and
also refers to 'struct page'. Thus, if the value passed in is not
called 'page', we'll refer to the wrong struct name (which might not
exist).
Rename the parameter so that it doesn't clash.
Thanks,
Mark.
> >
> >Thanks,
> >Mark.
> Thanks,
> Oleksandr
> >>---
> >> arch/arm64/include/asm/memory.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> >>index bfe632808d77..90c39a662379 100644
> >>--- a/arch/arm64/include/asm/memory.h
> >>+++ b/arch/arm64/include/asm/memory.h
> >>@@ -222,7 +222,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> >> #define _virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
> >> #else
> >> #define __virt_to_pgoff(kaddr) (((u64)(kaddr) & ~PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
> >>-#define __page_to_voff(page) (((u64)(page) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
> >>+#define __page_to_voff(kaddr) (((u64)(kaddr) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
> >> #define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET))
> >> #define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) | VMEMMAP_START))
> >>--
> >>2.7.4
> >>
> >>
> >>_______________________________________________
> >>linux-arm-kernel mailing list
> >>linux-arm-kernel at lists.infradead.org
> >>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v7 2/3] input: tm2-touchkey: Add touchkey driver support for TM2
From: Krzysztof Kozlowski @ 2017-01-17 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484632479-3111-3-git-send-email-jcsing.lee@samsung.com>
On Tue, Jan 17, 2017 at 02:54:38PM +0900, Jaechul Lee wrote:
> This patch adds support for the TM2 touch key and led
> functionality.
>
> The driver interfaces with userspace through an input device and
> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
> controlled by "/sys/class/leds/tm2-touchkey/brightness".
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This looks unusual. How did Dmitry's Sob end here?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH V2 1/2] kexec: arm64: create identity page table to be used in purgatory
From: James Morse @ 2017-01-17 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ea98a0045c8d466456f53150f341546810dd47e1.1482129830.git.panand@redhat.com>
Hi Pratyush,
On 19/12/16 07:13, Pratyush Anand wrote:
> Purgatory sha verification is very slow when D-cache is not enabled there.
> We need to enable MMU as well to enable D-Cache.Therefore,we need to an
> identity mapped page table in purgatory.
>
> Since debugging is very difficult in purgatory therefore we prefer to do as
> much work as possible in kexec.
>
> This patch prepares page table for purgatory in advance. We support only 4K
> page table,because it will be available on most of the platform. This page
> table is passed to the purgatory as a new segment.
>
> VA bit is fixed as 48, page table level is 3 where 3rd level page table
> contains 2M block entries.
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 04fd3968bb52..c2c8ff1b6940 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -24,6 +24,45 @@
> #include "kexec-syscall.h"
> #include "arch/options.h"
>
> +/*
> + * kexec creates identity page table to be used in purgatory so that
> + * dcache verification becomes faster.
> + *
> + * These are the definitions to be used by page table creation routine.
> + *
> + * Only 4K page table, 3 level, 2M block mapping, 48bit VA is supported
> + */
> +#define PGDIR_SHIFT 39
> +#define PUD_SHIFT 30
> +#define PMD_SHIFT 21
> +#define PTRS_PER_PGD 0x1FF
> +#define PTRS_PER_PUD 0x1FF
> +#define PTRS_PER_PMD 0x1FF
Aren't these 0x200 for 4K pages in the kernel? It looks like you use them as a
mask instead.
> +#define PMD_TYPE_TABLE (3UL << 0)
> +#define PMD_TYPE_SECT (1UL << 0)
> +#define PMD_SECT_AF (1UL << 10)
> +#define PMD_ATTRINDX(t) ((unsigned long)(t) << 2)
> +#define MT_NORMAL 4
This needs to correspond to the part of MAIR that describes the memory type for
'normal'. You define MT_NORMAL again in the next patch, it would be better to
share the definition so they can't be different. (I don't see why you can't use 0!)
> +#define PMD_FLAGS_NORMAL (PMD_TYPE_SECT | PMD_SECT_AF)
> +#define MMU_FLAGS_NORMAL (PMD_ATTRINDX(MT_NORMAL) | PMD_FLAGS_NORMAL)
The SH and AP bits are left as zero, which means non-shareable, read/writeable,
(which I think is fine).
> +#define SECTION_SIZE (2 * 1024 * 1024)
> +#define PAGE_SIZE (4 * 1024)
> +/* Since we are using 3 level of page tables, therefore minimum number of
> + * table will be 3. Most likely we will never need more than 3. Each entry
> + * in level 3 page table can map 2MB memory area. Thus a level 3 page table
> + * indexed by bit 29:21 can map a total of 1G memory area. Therefore, if
> + * any segment crosses 1G boundary, then we will need one more level 3
> + * table. Similarly, level 2 page table indexed by bit 38:30 can map a
> + * total of 512G memory area. If segment addresses are more than 512G apart
> + * then we will need two more table for each such block. We do not expect
> + * any memory segment to cross 512G boundary, however if we will ever wish
> + * to support uart debugging in purgatory then that might cross the
> + * boundary and therefore additional 2 more table space. Thus we will need
> + * maximum of 6 table space.
Surely we only need 6 page_size table entries if we support uart debugging,
which your 'if we ever' suggests we don't. So surely we only need 3, and a
comment that this needs expanding to 6 if we need to map two distinct areas.
> + */
> +#define MAX_PGTBLE_SZ (6 * 4096)
> +static int next_tbl_cnt = 1;
> +
> /* Global varables the core kexec routines expect. */
>
> unsigned char reuse_initrd;
> @@ -316,6 +355,117 @@ unsigned long arm64_locate_kernel_segment(struct kexec_info *info)
> return hole;
> }
>
> +static unsigned long *create_table_entry(unsigned long *pgtbl_buf,
> + unsigned long pgtbl_mem, unsigned long *tbl,
> + unsigned long virt, int shift,
> + unsigned long ptrs)
> +{
> + unsigned long index, desc, offset;
> +
> + index = (virt >> shift) & ptrs;
> + /* check if we have allocated a table already for this index */
> + if (tbl[index]) {
> + /*
> + * table index will have entry as per purgatory page table
> + * memory. Find out corresponding buffer address of table.
> + */
> + desc = tbl[index] & ~3UL;
> + offset = desc - pgtbl_mem;
wait .. no .. pgtbl_mem is also a guest physical address, so this is fine... its
not obvious at first glance! You could do with a typedef to make it clear which
addresses are the guests (pgtable_mem) and which are the hosts (pgtable_buf).
Something like phys_addr_t?
> + return &pgtbl_buf[offset >> 3];
> + }
> +
> + /*
> + * Always write page table content as per page table memory allocated
> + * for purgaory area, but return corresponding buffer area alloced
Nit: purgatory, allocated,
> + * in kexec
> + */
> + if (next_tbl_cnt > 5)
> + die("%s: No more memory for page table\n", __func__);
die()? With a bit of juggling can't we return an error so we never try to enable
the MMU+dcache instead?
> +
> + tbl[index] = (pgtbl_mem + PAGE_SIZE * next_tbl_cnt) | PMD_TYPE_TABLE;
> +
> + return &pgtbl_buf[(next_tbl_cnt++ * PAGE_SIZE) >> 3];
> +}
> +
> +static void craete_block_entry(unsigned long *tbl, unsigned long flags,
> + unsigned long phys, unsigned long virt)
Why have separate phys and virt parameters if all this ever does is idmap?
> +{
> + unsigned long index;
> + unsigned long desc;
> +
> + index = (virt >> PMD_SHIFT) & PTRS_PER_PMD;
Copying the pmd_index() macro would make this clearer.
> + desc = (phys >> PMD_SHIFT) << PMD_SHIFT;
Looks like you wanted a PMD_MASK.
> + desc |= flags;
> + tbl[index] = desc;
> +}
> +
> +static void create_identity_entry(unsigned long *pgtbl_buf,
> + unsigned long pgtbl_mem, unsigned long virt,
> + unsigned long flags)
> +{
> + unsigned long *tbl = pgtbl_buf;
> +
> + tbl = create_table_entry(pgtbl_buf, pgtbl_mem, tbl, virt,
> + PGDIR_SHIFT, PTRS_PER_PGD);
> + tbl = create_table_entry(pgtbl_buf, pgtbl_mem, tbl, virt,
> + PUD_SHIFT, PTRS_PER_PUD);
> + craete_block_entry(tbl, flags, virt, virt);
Nit: create
> +}
> +
> +/**
> + * arm64_create_pgtbl_segment - Create page table segments to be used by
> + * purgatory. Page table will have entries to access memory area of all
> + * those segments which becomes part of sha verification in purgatory.
> + * Additionaly, we also create page table for purgatory segment as well.
Nit: additionally,
> + */
> +
> +static int arm64_create_pgtbl_segment(struct kexec_info *info,
> + unsigned long hole_min, unsigned long hole_max)
> +{
> + unsigned long *pgtbl_buf;
> + int i;
> + unsigned long mstart, mend, pgtbl_mem;
> + unsigned long purgatory_base, purgatory_len;
> +
> + pgtbl_buf = xmalloc(MAX_PGTBLE_SZ);
> + memset(pgtbl_buf, 0, MAX_PGTBLE_SZ);
> + pgtbl_mem = add_buffer_phys_virt(info, pgtbl_buf, MAX_PGTBLE_SZ,
> + MAX_PGTBLE_SZ, PAGE_SIZE, hole_min, hole_max, 1, 0);
I want to check what this does, but this all looks like it is doing the right thing.
> + for (i = 0; i < info->nr_segments; i++) {
> + if (info->segment[i].mem == (void *)info->rhdr.rel_addr) {
> + purgatory_base = (unsigned long)info->segment[i].mem;
> + purgatory_len = info->segment[i].memsz;
> + }
> + mstart = (unsigned long)info->segment[i].mem;
> + mend = mstart + info->segment[i].memsz;
> + mstart &= ~(SECTION_SIZE - 1);
> + while (mstart < mend) {
> + create_identity_entry(pgtbl_buf, pgtbl_mem,
> + mstart, MMU_FLAGS_NORMAL);
> + mstart += SECTION_SIZE;
> + }
> + }
Thanks,
James
^ permalink raw reply
* [PATCH v2 4/8] ARM: dts: armada-xp-linksys-mamba: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-17 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-5-f.fainelli@gmail.com>
On Thu, Jan 05, 2017 at 11:29:53AM -0800, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
> Document new binding"). The legacy binding node is kept included, but is marked
> disabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v2 6/8] ARM: dts: kirkwood-linksys-viper: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-17 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-7-f.fainelli@gmail.com>
On Thu, Jan 05, 2017 at 11:29:55AM -0800, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
> Document new binding"). The legacy binding node is kept included, but is marked
> disabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v5 3/4] dmaengine: pl330: Store pointer to slave device
From: Krzysztof Kozlowski @ 2017-01-17 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657338-26338-4-git-send-email-m.szyprowski@samsung.com>
On Tue, Jan 17, 2017 at 01:48:57PM +0100, Marek Szyprowski wrote:
> Store the pointer to slave device, which requested our channel. It will be
> later used to implement runtime PM of PL330 DMA controller. Although
> DMA channels might be requested many times, each DMA peripheral channel is
> physically dedicated only for specific hardware, so there should be only
> one slave device for each channel.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Any particular reason for removing my Reviewed-by? Any changes here?
Best regards,
Krzysztof
> ---
> drivers/dma/pl330.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index b6b2cc912380..c77a3494659c 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -450,6 +450,7 @@ struct dma_pl330_chan {
>
> /* for runtime pm tracking */
> bool active;
> + struct device *slave;
> };
>
> struct pl330_dmac {
> @@ -2093,6 +2094,14 @@ static struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
> if (chan_id >= pl330->num_peripherals)
> return NULL;
>
> + if (!pl330->peripherals[chan_id].slave) {
> + pl330->peripherals[chan_id].slave = slave;
> + } else if (pl330->peripherals[chan_id].slave != slave) {
> + dev_err(pl330->ddma.dev,
> + "Can't use same channel with multiple slave devices!\n");
> + return NULL;
> + }
> +
> return dma_get_slave_channel(&pl330->peripherals[chan_id].chan);
> }
>
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v2 7/8] ARM: dts: kirkwood-mv88f6281gtw-ge: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-17 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-8-f.fainelli@gmail.com>
On Thu, Jan 05, 2017 at 11:29:56AM -0800, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
> Document new binding"). The legacy binding node is kept included, but is marked
> disabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v5 4/4] dmaengine: pl330: Don't require irq-safe runtime PM
From: Krzysztof Kozlowski @ 2017-01-17 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657338-26338-5-git-send-email-m.szyprowski@samsung.com>
On Tue, Jan 17, 2017 at 01:48:58PM +0100, Marek Szyprowski wrote:
> This patch replaces irq-safe runtime PM with non-irq-safe version based on
> the new approach. Existing, irq-safe runtime PM implementation for PL330 was
> not bringing much benefits of its own - only clocks were enabled/disabled.
>
> Till now non-irq-safe runtime PM implementation was only possible by calling
> pm_runtime_get/put functions from alloc/free_chan_resources. All other DMA
> engine API functions cannot be called from a context, which permits sleeping.
> Such implementation, in practice would result in keeping DMA controller's
> device active almost all the time, because most of the slave device drivers
> (DMA engine clients) acquire DMA channel in their probe() function and
> released it during driver removal.
>
> This patch provides a new, different approach. It is based on an observation
> that there can be only one slave device using each DMA channel. PL330 hardware
> always has dedicated channels for each peripheral device. Using recently
> introduced device dependencies (links) infrastructure one can ensure proper
> runtime PM state of PL330 DMA controller basing on the runtime PM state of
> the slave device.
>
> In this approach in pl330_alloc_chan_resources() function a new dependency
> is being created between PL330 DMA controller device (as a supplier) and
> given slave device (as a consumer). This way PL330 DMA controller device
> runtime active counter is increased when the slave device is resumed and
> decreased the same time when given slave device is put to suspend. This way
> it has been ensured to keep PL330 DMA controller runtime active if there is
> an active used of any of its DMA channels. Slave device pointer is initially
> stored in per-channel data in of_dma_xlate callback. This is similar to what
> has been already implemented in Exynos IOMMU driver in commit 2f5f44f205cc95
> ("iommu/exynos: Use device dependency links to control runtime pm").
>
> If slave device doesn't implement runtime PM or keeps device runtime active
> all the time, then PL330 DMA controller will be runtime active all the time
> when channel is being allocated. The goal is however to have runtime PM
> added to all devices in the system, because it lets respective power
> domains to be turned off, what gives the best results in terms of power
> saving.
>
> If one requests memory-to-memory channel, runtime active counter is
> increased unconditionally. This might be a drawback of this approach, but
> PL330 is not really used for memory-to-memory operations due to poor
> performance in such operations compared to the CPU.
>
> Introducing non-irq-safe runtime power management finally allows to turn off
> audio power domain on Exynos5 SoCs.
>
> Removal of irq-safe runtime PM is based on the revert of the following
> commits:
> 1. commit 5c9e6c2b2ba3 "dmaengine: pl330: fix runtime pm support"
> 2. commit 81cc6edc0870 "dmaengine: pl330: Fix hang on dmaengine_terminate_all
> on certain boards"
> 3. commit ae43b3289186 "ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12"
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/dma/pl330.c | 124 ++++++++++++++++++++++++++--------------------------
> 1 file changed, 61 insertions(+), 63 deletions(-)
>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 8/8] ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-17 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-9-f.fainelli@gmail.com>
On Thu, Jan 05, 2017 at 11:29:57AM -0800, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
> Document new binding"). The legacy binding node is kept included, but is marked
> disabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts | 11 ++++++++
> arch/arm/boot/dts/kirkwood-rd88f6281.dtsi | 44 +++++++++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
Hi Florian
What about arch/arm/boot/dts/kirkwood-rd88f6281-a.dts
Andrew
^ permalink raw reply
* [PATCH v2 06/13] pinctrl: samsung: Fix samsung_pinctrl_create_functions return value
From: Krzysztof Kozlowski @ 2017-01-17 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-7-git-send-email-m.szyprowski@samsung.com>
On Tue, Jan 17, 2017 at 01:44:37PM +0100, Marek Szyprowski wrote:
> Return proper error code in case of memory allocation failure.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Thanks for fixing.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 09/13] pinctrl: samsung: Use generic of_device_get_match_data helper
From: Krzysztof Kozlowski @ 2017-01-17 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-10-git-send-email-m.szyprowski@samsung.com>
On Tue, Jan 17, 2017 at 01:44:40PM +0100, Marek Szyprowski wrote:
> Replace custom code with generic helper.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
> ---
> drivers/pinctrl/samsung/pinctrl-samsung.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/3] arm64: {adr,ldr}_l cleanup
From: Will Deacon @ 2017-01-17 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484669458-31713-1-git-send-email-mark.rutland@arm.com>
On Tue, Jan 17, 2017 at 04:10:55PM +0000, Mark Rutland wrote:
> While looking at the way we use adrp, I spotted that there are still a few
> open-coded instances of adr_l and ldr_l.
>
> These patches clean those up, making the code a little easier to follow.
Thanks, queued for 4.11.
Will
^ permalink raw reply
* [PATCH] ARM: LPAE: catch pending imprecise abort on unmask
From: Alexander Sverdlin @ 2017-01-17 17:42 UTC (permalink / raw)
To: linux-arm-kernel
Asynchronous external abort is coded differently in DFSR with LPAE enabled.
Fixes: 9254970c "ARM: 8447/1: catch pending imprecise abort on unmask".
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/mm/fault.c | 4 ++--
arch/arm/mm/fault.h | 4 ++++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 3a2e678b8d30..0122ad1a6027 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -610,9 +610,9 @@ static int __init early_abort_handler(unsigned long addr, unsigned int fsr,
void __init early_abt_enable(void)
{
- fsr_info[22].fn = early_abort_handler;
+ fsr_info[FSR_FS_AEA].fn = early_abort_handler;
local_abt_enable();
- fsr_info[22].fn = do_bad;
+ fsr_info[FSR_FS_AEA].fn = do_bad;
}
#ifndef CONFIG_ARM_LPAE
diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
index 67532f242271..afc1f84e763b 100644
--- a/arch/arm/mm/fault.h
+++ b/arch/arm/mm/fault.h
@@ -11,11 +11,15 @@
#define FSR_FS5_0 (0x3f)
#ifdef CONFIG_ARM_LPAE
+#define FSR_FS_AEA 17
+
static inline int fsr_fs(unsigned int fsr)
{
return fsr & FSR_FS5_0;
}
#else
+#define FSR_FS_AEA 22
+
static inline int fsr_fs(unsigned int fsr)
{
return (fsr & FSR_FS3_0) | (fsr & FSR_FS4) >> 6;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 5/8] ARM: dts: kirkwood-dir665: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-17 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-6-f.fainelli@gmail.com>
On Thu, Jan 05, 2017 at 11:29:54AM -0800, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
> Document new binding"). The legacy binding node is kept included, but is marked
> disabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v2 8/8] ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-17 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117173404.GG9470@lunn.ch>
On 01/17/2017 09:34 AM, Andrew Lunn wrote:
> On Thu, Jan 05, 2017 at 11:29:57AM -0800, Florian Fainelli wrote:
>> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
>> Document new binding"). The legacy binding node is kept included, but is marked
>> disabled.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts | 11 ++++++++
>> arch/arm/boot/dts/kirkwood-rd88f6281.dtsi | 44 +++++++++++++++++++++++++++++
>> 2 files changed, 55 insertions(+)
>
> Hi Florian
>
> What about arch/arm/boot/dts/kirkwood-rd88f6281-a.dts
Whoops, missed that one, let me resubmit a change to that file too along
with your tags on the other patches, thanks for testing and reviewing!
--
Florian
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Bjorn Helgaas @ 2017-01-17 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117152548.GB27312@n2100.armlinux.org.uk>
On Tue, Jan 17, 2017 at 03:25:49PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 17, 2017 at 09:14:44AM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 11, 2017 at 08:49:46PM +0100, Uwe Kleine-K?nig wrote:
> > > Hello,
> > >
> > > on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
> > > ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
> > > is enabled:
> > >
> > > # dmesg | grep ath
> > > [ 7.207770] ath10k_pci 0000:02:00.0: Refused to change power state, currently in D3
> > > [ 7.237955] ath10k_pci 0000:02:00.0: failed to wake up device : -110
> > > [ 7.238146] ath10k_pci: probe of 0000:02:00.0 failed with error -110
> > >
> > > if however PCIEASPM is off, the driver probes correctly and the ath10k
> > > adapter works fine.
> > >
> > > I wonder if someone has an idea what needs to be done to fix this
> > > problem. (OK, I could disable PCIEASPM, but I'd like to have a solution
> > > for a distribution kernel where I think PCIEASPM=y is sensible in
> > > general.)
> >
> > Can somebody confirm that this system (Marvell Armada 385-based Turris
> > Omnia) does actually support ASPM in hardware?
>
> What sort of "hardware" are you referring to?
>
> From my reading of the specs, ASPM doesn't require any external hardware.
> It's all done inside the PCIe root hub and PCIe device.
Right. My question is just whether we know that the Marvell PCIe root
hub hardware works correctly with respect to ASPM. The PCI core isn't
doing anything special for Marvell, so problems here are likely to be
either in the Marvell hardware or in the pci-mvebu.c driver.
> The PCIe spec specifically prohibits cutting power supplies and clocks to
> PCIe devices during L0s and L1, with the exception that the PCIe clock may
> be stopped in L1 if CLKREQ# is deasserted. CLKREQ# handling generally
> requires GPIO usage, and as there's no support for that, there's no support
> for stopping the PCIe clock in L1. We do the correct thing there,
> preventing the PCI_EXP_LNKCTL_CLKREQ_EN bit being set.
>
> That all said, it would probably be a good idea to throw some printk()
> debugging into mvebu_sw_pci_bridge_write() and mvebu_sw_pci_bridge_read()
> so we can see what's going on at that level, and maybe also some debug
> in mvebu_pcie_hw_wr_conf() and mvebu_pcie_hw_rd_conf() so we can see
> what's happening at the PCIe device too.
Uwe has already done that; the dmesg logs including this
instrumentation are at
https://bugzilla.kernel.org/show_bug.cgi?id=192441
^ permalink raw reply
* [PATCH v2 11/13] pinctrl: samsung: Move retention control from mach-exynos to the pinctrl driver
From: Krzysztof Kozlowski @ 2017-01-17 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-12-git-send-email-m.szyprowski@samsung.com>
On Tue, Jan 17, 2017 at 01:44:42PM +0100, Marek Szyprowski wrote:
> This patch moves pad retention control from PMU driver to Exynos pin
> controller driver. This helps to avoid possible ordering and logical
> dependencies between machine, PMU and pin control code. Till now it
> worked fine only because sys_ops for PMU and pin controller were called
> in registration order.
> This is also a preparation for adding new features to Exynos pin
> controller driver, like runtime power management and suspending
> individual pin controllers, which might be a part of some power domain.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mach-exynos/suspend.c | 64 --------------
> drivers/pinctrl/samsung/pinctrl-exynos.c | 146 +++++++++++++++++++++++++++++++
> 2 files changed, 146 insertions(+), 64 deletions(-)
>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Russell King - ARM Linux @ 2017-01-17 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117174649.GA11063@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Jan 17, 2017 at 11:46:49AM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 17, 2017 at 03:25:49PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 17, 2017 at 09:14:44AM -0600, Bjorn Helgaas wrote:
> > > On Wed, Jan 11, 2017 at 08:49:46PM +0100, Uwe Kleine-K?nig wrote:
> > > > Hello,
> > > >
> > > > on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
> > > > ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
> > > > is enabled:
> > > >
> > > > # dmesg | grep ath
> > > > [ 7.207770] ath10k_pci 0000:02:00.0: Refused to change power state, currently in D3
> > > > [ 7.237955] ath10k_pci 0000:02:00.0: failed to wake up device : -110
> > > > [ 7.238146] ath10k_pci: probe of 0000:02:00.0 failed with error -110
> > > >
> > > > if however PCIEASPM is off, the driver probes correctly and the ath10k
> > > > adapter works fine.
> > > >
> > > > I wonder if someone has an idea what needs to be done to fix this
> > > > problem. (OK, I could disable PCIEASPM, but I'd like to have a solution
> > > > for a distribution kernel where I think PCIEASPM=y is sensible in
> > > > general.)
> > >
> > > Can somebody confirm that this system (Marvell Armada 385-based Turris
> > > Omnia) does actually support ASPM in hardware?
> >
> > What sort of "hardware" are you referring to?
> >
> > From my reading of the specs, ASPM doesn't require any external hardware.
> > It's all done inside the PCIe root hub and PCIe device.
>
> Right. My question is just whether we know that the Marvell PCIe root
> hub hardware works correctly with respect to ASPM. The PCI core isn't
> doing anything special for Marvell, so problems here are likely to be
> either in the Marvell hardware or in the pci-mvebu.c driver.
>
> > The PCIe spec specifically prohibits cutting power supplies and clocks to
> > PCIe devices during L0s and L1, with the exception that the PCIe clock may
> > be stopped in L1 if CLKREQ# is deasserted. CLKREQ# handling generally
> > requires GPIO usage, and as there's no support for that, there's no support
> > for stopping the PCIe clock in L1. We do the correct thing there,
> > preventing the PCI_EXP_LNKCTL_CLKREQ_EN bit being set.
> >
> > That all said, it would probably be a good idea to throw some printk()
> > debugging into mvebu_sw_pci_bridge_write() and mvebu_sw_pci_bridge_read()
> > so we can see what's going on at that level, and maybe also some debug
> > in mvebu_pcie_hw_wr_conf() and mvebu_pcie_hw_rd_conf() so we can see
> > what's happening at the PCIe device too.
>
> Uwe has already done that; the dmesg logs including this
> instrumentation are at
> https://bugzilla.kernel.org/show_bug.cgi?id=192441
Grr, <swears about SSL incompatibilities>... wget's the URL and then
uses elinks on it...
Umm, not quite. He's done mvebu_pcie_hw_wr_conf() and mvebu_pcie_hw_rd_conf()
but not the bridge from the descriptions given on the attachments.
Obviously, it's going to be a lot of work to manufacture the links to
look at each attachment to thoroughly check, so I'm not going to do
that given quite how broken SSL crap is today.
(Try installing elinks and pointing it at the above URL.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 12/13] pinctrl: samsung: Move retention control from mach-s5pv210 to the pinctrl driver
From: Krzysztof Kozlowski @ 2017-01-17 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-13-git-send-email-m.szyprowski@samsung.com>
On Tue, Jan 17, 2017 at 01:44:43PM +0100, Marek Szyprowski wrote:
> This patch moves pad retention control from S5PV210 machine code to
> Exynos pin controller driver. This helps to avoid possible ordering
> and logical dependencies between machine and pin control code. Till
> now it worked fine only because sys_ops for machine code and pin
> controller were called in registration order.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mach-s5pv210/pm.c | 7 ----
> arch/arm/mach-s5pv210/regs-clock.h | 4 ---
For mach-s5pv210:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Russell King - ARM Linux @ 2017-01-17 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117175115.GD27312@n2100.armlinux.org.uk>
On Tue, Jan 17, 2017 at 05:51:16PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 17, 2017 at 11:46:49AM -0600, Bjorn Helgaas wrote:
> > Uwe has already done that; the dmesg logs including this
> > instrumentation are at
> > https://bugzilla.kernel.org/show_bug.cgi?id=192441
>
> Grr, <swears about SSL incompatibilities>... wget's the URL and then
> uses elinks on it...
>
> Umm, not quite. He's done mvebu_pcie_hw_wr_conf() and mvebu_pcie_hw_rd_conf()
> but not the bridge from the descriptions given on the attachments.
> Obviously, it's going to be a lot of work to manufacture the links to
> look at each attachment to thoroughly check, so I'm not going to do
> that given quite how broken SSL crap is today.
>
> (Try installing elinks and pointing it at the above URL.)
Oh, and looking at some of the debug that's been added:
[ 3.646322] mvebu_pcie_rd_conf(where=16, size=4, val=3892314116) => 0
[ 3.646325] mvebu_pcie_wr_conf(where=16, size=4, val=4294967295)
[ 3.646329] mvebu_pcie_rd_conf(where=16, size=4, val=4292870148) => 0
[ 3.646332] mvebu_pcie_wr_conf(where=16, size=4, val=3892314116)
Please print register values in HEX, not decimal. Same for register
addresses. Hex is the normal base to print this information, which
the human brain can easily comprehend and translate to bits in a
register. Decimal values are useless and might as well be encrypted.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs
From: Stephen Boyd @ 2017-01-17 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116034551.GA27364@b29397-desktop>
Quoting Peter Chen (2017-01-15 19:45:51)
>
> So, you need to call phy_set_mode when switching between host and device.
> Besides, you also need to toggle VBUSVLDEXT when the external vbus
> is on or off at device mode (doesn't need for host mode), is it correct?
Correct.
>
> At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need
> to port it to generic phy framework.
>
Ok. I'll look into that. Can the other patches in this series be picked
up? Otherwise I can resend them all again once I fix the phy_set_mode()
call location and introduce a new phy op.
^ permalink raw reply
* [PATCH] ARM: LPAE: catch pending imprecise abort on unmask
From: Russell King - ARM Linux @ 2017-01-17 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117174210.28122-1-alexander.sverdlin@nokia.com>
On Tue, Jan 17, 2017 at 06:42:10PM +0100, Alexander Sverdlin wrote:
> Asynchronous external abort is coded differently in DFSR with LPAE enabled.
>
> Fixes: 9254970c "ARM: 8447/1: catch pending imprecise abort on unmask".
Please drop it into the patch system, thanks.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
> arch/arm/mm/fault.c | 4 ++--
> arch/arm/mm/fault.h | 4 ++++
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 3a2e678b8d30..0122ad1a6027 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -610,9 +610,9 @@ static int __init early_abort_handler(unsigned long addr, unsigned int fsr,
>
> void __init early_abt_enable(void)
> {
> - fsr_info[22].fn = early_abort_handler;
> + fsr_info[FSR_FS_AEA].fn = early_abort_handler;
> local_abt_enable();
> - fsr_info[22].fn = do_bad;
> + fsr_info[FSR_FS_AEA].fn = do_bad;
> }
>
> #ifndef CONFIG_ARM_LPAE
> diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
> index 67532f242271..afc1f84e763b 100644
> --- a/arch/arm/mm/fault.h
> +++ b/arch/arm/mm/fault.h
> @@ -11,11 +11,15 @@
> #define FSR_FS5_0 (0x3f)
>
> #ifdef CONFIG_ARM_LPAE
> +#define FSR_FS_AEA 17
> +
> static inline int fsr_fs(unsigned int fsr)
> {
> return fsr & FSR_FS5_0;
> }
> #else
> +#define FSR_FS_AEA 22
> +
> static inline int fsr_fs(unsigned int fsr)
> {
> return (fsr & FSR_FS3_0) | (fsr & FSR_FS4) >> 6;
> --
> 2.11.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v7 2/3] input: tm2-touchkey: Add touchkey driver support for TM2
From: Dmitry Torokhov @ 2017-01-17 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117172047.47535bj5xd6toayu@kozik-lap>
On Tue, Jan 17, 2017 at 9:20 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Jan 17, 2017 at 02:54:38PM +0900, Jaechul Lee wrote:
>> This patch adds support for the TM2 touch key and led
>> functionality.
>>
>> The driver interfaces with userspace through an input device and
>> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
>> controlled by "/sys/class/leds/tm2-touchkey/brightness".
>>
>> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
>> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
>> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> This looks unusual. How did Dmitry's Sob end here?
I sent Jaechul a version of the patch to try out.
--
Dmitry
^ permalink raw reply
* [PATCH v7 2/3] input: tm2-touchkey: Add touchkey driver support for TM2
From: Krzysztof Kozlowski @ 2017-01-17 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKdAkRQij9VuG1mguE0FwQMKuHrnyLAZJxOtkoR97uuX+ZBmLQ@mail.gmail.com>
On Tue, Jan 17, 2017 at 10:06:27AM -0800, Dmitry Torokhov wrote:
> On Tue, Jan 17, 2017 at 9:20 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Tue, Jan 17, 2017 at 02:54:38PM +0900, Jaechul Lee wrote:
> >> This patch adds support for the TM2 touch key and led
> >> functionality.
> >>
> >> The driver interfaces with userspace through an input device and
> >> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
> >> controlled by "/sys/class/leds/tm2-touchkey/brightness".
> >>
> >> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> >> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> >> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> >> Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
> >> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> >> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> >> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> >> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >
> > This looks unusual. How did Dmitry's Sob end here?
>
> I sent Jaechul a version of the patch to try out.
Ah, makes sense then.
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