On Tue, Dec 18, 2018 at 01:52:46AM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range to map range of kernel memory
> to user vma.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> ---
> drivers/firewire/core-iso.c | 15 ++-
> 1 file changed, 2 inserti
On Tue, Dec 18, 2018 at 05:34:27PM +0800, Yunsheng Lin wrote:
> On 2018/12/17 22:36, Russell King - ARM Linux wrote:
> > As I've previously stated, the behaviour I've seen is _both_ pause bits
> > clear:
> >
> > If I set bit 10 (pause), and read back to confi
On Tue, Dec 18, 2018 at 01:53:34AM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
> Tested-by: Heiko Stuebner
> Acked-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19
On Tue, Dec 18, 2018 at 01:52:09AM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
> ---
> arch/arm/mm/dma-mapping.c | 21 +++--
> 1 file changed, 7 insertions(+), 14 deletions(-)
>
On Mon, Dec 17, 2018 at 05:42:20PM +0800, Yunsheng Lin wrote:
> On 2018/12/15 18:37, Russell King - ARM Linux wrote:
> > On Sat, Dec 15, 2018 at 04:07:42PM +0800, Yunsheng Lin wrote:
> >> There seems to be some problem with pause subsequent negotiation.
> >> We reverte
On Sat, Dec 15, 2018 at 04:07:42PM +0800, Yunsheng Lin wrote:
> There seems to be some problem with pause subsequent negotiation.
> We reverted the above patch and tried to reproduce the above problem
> by triggering another negotiation by reconnection of the cable, using
> ethtool -a cmd shows bot
On Fri, Dec 14, 2018 at 05:09:44PM +0100, Antoine Tenart wrote:
> Hi Russell,
>
> On Fri, Dec 14, 2018 at 04:02:50PM +, Russell King - ARM Linux wrote:
> > On Fri, Dec 14, 2018 at 10:34:51AM +0100, Antoine Tenart wrote:
> > > The mvpp2_phylink_validate() function
On Fri, Dec 14, 2018 at 10:34:51AM +0100, Antoine Tenart wrote:
> The mvpp2_phylink_validate() function sets all modes that are
> supported by a given PPv2 port. A recent change made all ports to
> advertise they support 10G modes in certain cases. This is not true,
> as only the port #0 can do so.
On Thu, Dec 13, 2018 at 02:24:03PM +0800, Ryder Lee wrote:
> The MediaTek BTIF controller doesn't need to set termios so add
> a new capability 'UART_CAP_NMOD' for the unsupported case.
>
>
> Signed-off-by: Sean Wang
> Signed-off-by: Ryder Lee
> ---
> drivers/tty/serial/8250/8250.h | 1 +
On Tue, Dec 11, 2018 at 07:53:42PM +0200, Baruch Siach wrote:
> That is, something like this, right?
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 125ea99418df..04cb0241ca2b 100644
> --- a/drivers/net/ethernet/marvell/
On Tue, Dec 11, 2018 at 05:32:28PM +0100, Antoine Tenart wrote:
> The mvpp2_phylink_validate() function sets all modes that are
> supported by a given PPv2 port. A recent change made all ports to
> advertise they support 10G modes in certain cases. This is not true,
> as only the port #0 can do so.
On Mon, Dec 10, 2018 at 02:35:55PM +, Robin Murphy wrote:
> On 10/12/2018 14:21, Rafael David Tinoco wrote:
> >On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
> >physical frame number might be so big that zsmalloc obj encoding (to
> >location) will break, causing:
> >
> >
On Sun, Dec 09, 2018 at 06:28:11PM +0800, kbuild test robot wrote:
> Hi Ard,
>
> I love your patch! Perhaps something to improve:
Hi,
This looks to me like a false warning - how can a patch touching arch
code affect the result of lib/test_ubsan.c? Please can you double-
check this result?
Than
On Sun, Dec 02, 2018 at 08:35:09PM +0100, Miquel Raynal wrote:
> Hi Russell,
>
> Russell King - ARM Linux wrote on Fri, 30 Nov
> 2018 19:00:31 +:
>
> > On Fri, Nov 30, 2018 at 03:47:37PM +0100, Miquel Raynal wrote:
> > > So far the PHY ->xlate() call
On Fri, Nov 30, 2018 at 04:18:43PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> > > Hi,
> > >
> > > As I've already
On Fri, Nov 30, 2018 at 03:47:37PM +0100, Miquel Raynal wrote:
> So far the PHY ->xlate() callback was checking if the port was
> "invalid" before continuing, meaning that the port has not been used
> yet. This check is not correct as there is no opposite call to
> ->xlate() once the PHY is release
On Fri, Nov 30, 2018 at 10:25:37AM +, Phil Edworthy wrote:
> Hi Stephen,
>
> On 30 November 2018 09:09 Stephen Boyd wrote:
> > Quoting Phil Edworthy (2018-11-20 06:14:45)
> > > This adds clk_get_optional() and devm_clk_get_optional() functions to
> > > get optional clocks.
> > > They behave th
On Thu, Nov 29, 2018 at 05:12:45PM +0100, Miquel Raynal wrote:
> Hello,
>
> Miquel Raynal wrote on Thu, 22 Nov 2018
> 22:04:16 +0100:
> > +static struct phy *mvebu_a3700_comphy_xlate(struct device *dev,
> > + struct of_phandle_args *args)
> > +{
> > + struc
On Thu, Nov 29, 2018 at 09:10:39AM -0700, Nathan Chancellor wrote:
> On Thu, Nov 29, 2018 at 10:49:03AM +, Will Deacon wrote:
> > On Thu, Nov 29, 2018 at 09:03:54AM +, Julien Thierry wrote:
> > >
> > >
> > > On 29/11/18 04:19, Nick Desaulniers wrote:
> > > > Fixes the warning produced from
g) the secondary startup code during hotplug.
>
> Reviewed-by: Julien Thierry
> Signed-off-by: Russell King
> Signed-off-by: Sasha Levin
> ---
> arch/arm/kernel/head-common.S | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/kern
On Wed, Nov 28, 2018 at 02:25:54PM +0100, Stefan Agner wrote:
> Add a fault handler which handles reads in Thumb-2 mode. Install
> the appropriate handler depending on which mode the kernel has
> been built. This avoids an "Unhandled fault: external abort on
> non-linefetch (0x1008) at 0xf0a8"
On Wed, Nov 28, 2018 at 09:12:52AM -0500, Sasha Levin wrote:
> On Fri, Nov 23, 2018 at 12:02:54AM +0000, Russell King - ARM Linux wrote:
> >Hi Sasha,
> >
> >We need to keep track of which Spectre patches have been backported
> >and which haven't. David Long
On Tue, Nov 27, 2018 at 10:56:20AM +, Russell King - ARM Linux wrote:
> On Tue, Nov 27, 2018 at 08:30:32AM -0200, Rafael David Tinoco wrote:
> > On 11/26/18 9:44 PM, Russell King - ARM Linux wrote:
> > >On Mon, Nov 26, 2018 at 11:41:11PM +, Russell King - ARM Linux wrote:
On Tue, Nov 27, 2018 at 08:30:32AM -0200, Rafael David Tinoco wrote:
> On 11/26/18 9:44 PM, Russell King - ARM Linux wrote:
> >On Mon, Nov 26, 2018 at 11:41:11PM +, Russell King - ARM Linux wrote:
> >>On Mon, Nov 26, 2018 at 11:33:03PM +, Russell King - ARM Linux wrote:
&
On Mon, Nov 26, 2018 at 11:41:11PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 26, 2018 at 11:33:03PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 26, 2018 at 08:53:35PM -0200, Rafael David Tinoco wrote:
> > > Right now, only way for task->thread_info->
On Mon, Nov 26, 2018 at 11:33:03PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 26, 2018 at 08:53:35PM -0200, Rafael David Tinoco wrote:
> > Right now, only way for task->thread_info->syscall to be updated is if
> > if _TIF_SYSCALL_WORK is set in current'
On Mon, Nov 26, 2018 at 08:53:35PM -0200, Rafael David Tinoco wrote:
> Right now, only way for task->thread_info->syscall to be updated is if
> if _TIF_SYSCALL_WORK is set in current's task thread_info->flags
> (similar to what has_syscall_work() checks for arm64).
>
> This means that "->syscall"
On Sun, Nov 25, 2018 at 11:11:05AM +, Russell King - ARM Linux wrote:
> On Sat, Nov 24, 2018 at 05:07:17PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [181124 20:10]:
> > > On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote:
> > > > Hi
On Sat, Nov 24, 2018 at 05:07:17PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [181124 20:10]:
> > On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote:
> > > Hi,
> > >
> > > On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalus
On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote:
> Hi,
>
> On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote:
> > On 22/11/2018 17.12, Russell King - ARM Linux wrote:
> > > I'm also not sure about this:
> > &
On Sat, Nov 24, 2018 at 09:06:48PM +0200, Aaro Koskinen wrote:
> Hello,
>
> On Sat, Nov 24, 2018 at 05:48:23PM +, Russell King - ARM Linux wrote:
> > Hmm, there's more questionable stuff in this driver, and the gadget
> > layer.
>
> [...]
>
> > So,
On Sat, Nov 24, 2018 at 02:17:40AM +0200, Aaro Koskinen wrote:
> Hi,
>
> On Fri, Nov 23, 2018 at 01:45:46PM +0200, Peter Ujfalusi wrote:
> > On 23/11/2018 0.01, Aaro Koskinen wrote:
> > > With that reverted, the DMA works OK (and I can also now confirm that
> > > OMAP_DMA_LCH_2D works). I haven't
On Fri, Nov 23, 2018 at 04:16:59PM +, Russell King - ARM Linux wrote:
> Hi Peter,
>
> Here's the patch, which should now support IN as well as OUT.
> Completely untested, as mentioned before.
Now compile tested...
drivers/usb/gadget/udc
Hi Peter,
Here's the patch, which should now support IN as well as OUT.
Completely untested, as mentioned before.
drivers/usb/gadget/udc/omap_udc.c | 286 ++
drivers/usb/gadget/udc/omap_udc.h | 3 +-
2 files changed, 135 insertions(+), 154 deletions(-)
diff
On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote:
> > Also we can't deal with the omap_set_dma_dest_burst_mode() setting -
> > DMAengine always uses a 64 byte burst, but udc wants a smaller burst
> > setting. Does this matter?
>
> The tusb also fiddled with the burst before the conv
On Fri, Nov 23, 2018 at 11:57:31AM +, Julien Thierry wrote:
>
>
> On 23/11/18 10:50, Russell King - ARM Linux wrote:
> >On Fri, Nov 23, 2018 at 01:57:12AM -0800, h...@zytor.com wrote:
> >>You should never call a sleeping function from a user_access section.
>
On Fri, Nov 23, 2018 at 01:57:12AM -0800, h...@zytor.com wrote:
> You should never call a sleeping function from a user_access section.
> It is intended for very limited regions.
So, what happens if the "unsafe" user access causes a page fault that
ends up sleeping?
--
RMK's Patch system: http:/
On Fri, Nov 23, 2018 at 12:24:26AM +0200, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Nov 22, 2018 at 03:12:36PM +, Russell King - ARM Linux wrote:
> > On Thu, Nov 22, 2018 at 10:29:48AM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Nov 20, 2018 at 11:04:06PM +0
02:57:10PM -0500, Sasha Levin wrote:
> From: Russell King
>
> [ Upstream commit 899a42f836678a595f7d2bc36a5a0c2b03d08cbc ]
>
> Move lookup_processor_type() out of the __init section so it is callable
> from (eg) the secondary startup code during hotplug.
>
> Reviewed-by:
Sorry, I meant this patch, not patch 11.
On Thu, Nov 22, 2018 at 02:56:16PM -0500, Sasha Levin wrote:
> From: Russell King
>
> [ Upstream commit 65987a8553061515b5851b472081aedb9837a391 ]
>
> Split out the lookup of the processor type and associated error handling
>
hu, Nov 22, 2018 at 02:56:15PM -0500, Sasha Levin wrote:
> From: Russell King
>
> [ Upstream commit 899a42f836678a595f7d2bc36a5a0c2b03d08cbc ]
>
> Move lookup_processor_type() out of the __init section so it is callable
> from (eg) the secondary startup code during hotplug.
>
sible manual back-porting where they don't apply.
On Thu, Nov 22, 2018 at 02:54:41PM -0500, Sasha Levin wrote:
> From: Russell King
>
> [ Upstream commit 899a42f836678a595f7d2bc36a5a0c2b03d08cbc ]
>
> Move lookup_processor_type() out of the __init section so it is callable
On Thu, Nov 22, 2018 at 06:40:45PM +0100, Ard Biesheuvel wrote:
> On Thu, 22 Nov 2018 at 17:29, Jessica Yu wrote:
> >
> > +++ Vincent Whitchurch [22/11/18 13:24 +0100]:
> > >On Thu, Nov 22, 2018 at 12:01:54PM +, Dave Martin wrote:
> > >> On Mon, Nov 19, 2018 at 05:25:12PM +0100, Vincent Whitch
On Thu, Nov 22, 2018 at 10:29:48AM +, Russell King - ARM Linux wrote:
> On Tue, Nov 20, 2018 at 11:04:06PM +0200, Aaro Koskinen wrote:
> > I had switched to PIO mode in 2015 since the WARNs about legacy DMA
> > API were too annoying and flooding the console. And now that I trie
On Tue, Nov 20, 2018 at 11:04:06PM +0200, Aaro Koskinen wrote:
> I had switched to PIO mode in 2015 since the WARNs about legacy DMA
> API were too annoying and flooding the console. And now that I tried
> using DMA again with g_ether, it doesn't work anymore. The device get's
> recognized on host
On Thu, Nov 15, 2018 at 03:12:17PM +1100, Finn Thain wrote:
> The thread went way off-topic when Christoph took the opportunity to
> suggest the removal of RPC and EBSA110. That doesn't interest me.
I suspect that is the right solution - I've been trying to get 4.19
to boot on my RPC and it's pro
On Wed, Nov 14, 2018 at 03:58:36PM +0100, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Wed, Nov 14, 2018 at 3:16 PM Russell King - ARM Linux
> wrote:
> > On Wed, Nov 14, 2018 at 02:17:09PM +1100, Finn Thain wrote:
> > > So, even assuming that you're right about
On Wed, Nov 14, 2018 at 02:17:09PM +1100, Finn Thain wrote:
> On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
>
> >
> > A clocksource provides a cycle counter that monotonically changes and
> > does not wrap between clockevent events.
> >
> > A cloc
On Mon, Nov 12, 2018 at 03:12:39PM +1100, Finn Thain wrote:
> Implementations of arch_gettimeoffset are generally not re-entrant
> and assume that interrupts have been disabled. Unfortunately this
> pre-condition got broken in v2.6.32.
To me, it looks way worse than what you think.
The original c
On Wed, Nov 14, 2018 at 02:35:29PM +1300, Michael Schmitz wrote:
> So we'd still have to use jiffies + interpolation from the current timer
> rundown counter as clocksource (since that will be monotonous and won't
> wrap)?
>
> The way Finn did the clocksource for m68k, the clocksource counter does
On Wed, Nov 14, 2018 at 08:55:37AM +1100, Finn Thain wrote:
> On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
>
> > On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
> > >
> > > You could remove the old arch_gettimeoffset API without dropping any
&g
On Tue, Nov 13, 2018 at 02:48:07PM +0100, Emmanuel Vadot wrote:
> Like 4436a371 for 37xx, reserve the PSCI area memory region so kernels
> can call the code there.
> Region address is taken from the ATF code [1] and is 2MiB aligned.
>
> [1] plat/marvell/a8k/common/include/platform_def.h
>
> Signe
On Tue, Nov 13, 2018 at 09:16:16AM +, Bich HEMON wrote:
>
> On 11/12/18 7:22 PM, Olof Johansson wrote:
> > On Thu, Jul 27, 2017 at 04:50:20PM +, Bich HEMON wrote:
> >> From: Gerald Baeza
> >>
> >> This adds low-level debug support on USART1 for STM32F4
> >> and STM32F7.
> >> Compiled via
On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
> On Mon, 12 Nov 2018, Christoph Hellwig wrote:
>
> > On Mon, Nov 12, 2018 at 03:12:39PM +1100, Finn Thain wrote:
> > > Implementations of arch_gettimeoffset are generally not re-entrant and
> > > assume that interrupts have been disable
On Fri, Nov 09, 2018 at 12:40:06PM +0100, Arnd Bergmann wrote:
> On Fri, Nov 9, 2018 at 8:04 AM Chris Packham
> wrote:
> >
> > Add documentation for the marvell,ecc-enable and marvell,ecc-disable
> > properties which can be used to enable/disable ECC on the Marvell aurora
> > cache.
> >
> > Signed
On Tue, Nov 06, 2018 at 04:29:54PM +, Julien Thierry wrote:
> Hi Russel, David,
>
> On 06/11/18 16:20, Russell King - ARM Linux wrote:
> >On Mon, Nov 05, 2018 at 01:53:13PM +, David Binderman wrote:
> >>Hello there,
> >>
> >>2nd try. Plain
On Tue, Nov 06, 2018 at 04:33:26PM +, David Binderman wrote:
> hello there Russell,
>
> > linux-4.20-rc1/arch/arm/vfp/vfpmodule.c:576]: (warning) Redundant
> > assignment of >'ufp_exc->fpinst2' to itself.
>
> >Thanks for the report - it most certainly is a bug introduced by
> >Julien's patch
On Mon, Nov 05, 2018 at 01:53:13PM +, David Binderman wrote:
> Hello there,
>
> 2nd try. Plain text might help.
Yep, Linux kernel development generally doesn't like wasteful html
emails, sorry.
> linux-4.20-rc1/arch/arm/vfp/vfpmodule.c:576]: (warning) Redundant assignment
> of 'ufp_exc->fpi
On Fri, Nov 02, 2018 at 10:31:27AM +0800, wangyufen wrote:
> In case panic() and panic() called at the same time on different CPUS.
> For example:
> CPU 0:
> panic()
> __crash_kexec
>machine_crash_shutdown
> crash_smp_send_stop
>machine_kexec
> BUG_ON(num_on
On Thu, Nov 01, 2018 at 07:20:49PM +0800, Wang Yufen wrote:
> From: Yufen Wang
>
> In case panic() and panic() called at the same time on different CPUS.
> For example:
> CPU 0:
> panic()
> __crash_kexec
>machine_crash_shutdown
> crash_smp_send_stop
>machine_kexec
On Mon, Oct 29, 2018 at 04:52:04PM -0700, Florian Fainelli wrote:
> If the architecture implements ARCH_HAS_PHYS_INITRD, make the FDT
> scanning code populate the physical address of the start of the FDT and
> its size.
>
> Signed-off-by: Florian Fainelli
> ---
> arch/arm/mm/init.c | 2 +-
> dri
On Mon, Oct 29, 2018 at 03:54:36PM +, Mark Rutland wrote:
> On Mon, Oct 29, 2018 at 02:20:51PM +, Wiebe, Wladislav (Nokia - DE/Ulm)
> wrote:
> > When running into situations like:
> > "Unhandled fault: synchronous external abort (0x210) at 0xXXX"
> > or
> > "Unhandled prefetch abort: synch
On Mon, Oct 29, 2018 at 02:20:51PM +, Wiebe, Wladislav (Nokia - DE/Ulm)
wrote:
> When running into situations like:
> "Unhandled fault: synchronous external abort (0x210) at 0xXXX"
> or
> "Unhandled prefetch abort: synchronous external abort (0x210) at 0xXXX"
> it is useful to know the content
RS is
> > enabled in the kernel.
> >
> > Facilitate the debugging of such situations by printing a debug message
> > to the kernel log showing the task name and the faulting address.
> >
> > Suggested-by: Russell King
> > Signed-off-by: Florian Fainelli
On Thu, Oct 25, 2018 at 10:53:12AM -0700, Florian Fainelli wrote:
> Something like this below? It does not have to be an alternative
> solution, I would find it useful for perf to make sure the vectors page
> is present in the virtual address space by having an explicit test. perf
> maintains, what
On Thu, Oct 25, 2018 at 10:19:54AM -0700, Florian Fainelli wrote:
> On 10/24/18 7:10 PM, Andrew Lunn wrote:
> > On Wed, Oct 24, 2018 at 05:09:05PM -0700, Florian Fainelli wrote:
> >> perf on ARM requires CONFIG_KUSER_HELPERS to be turned on to allow some
> >> independance with respect to the ARM CP
On Thu, Oct 25, 2018 at 08:25:04AM -0500, Rob Herring wrote:
> On Wed, Oct 24, 2018 at 7:17 PM Florian Fainelli wrote:
> >
> > ARM64 is the only architecture that requires a re-definition of
> > __early_init_dt_declare_initrd(), absorb its custom implemention in
> > drivers/of/fdt.c.
> >
> > Sugge
On Thu, Oct 25, 2018 at 09:37:59AM -0300, Rafael David Tinoco wrote:
> Is it okay to propose using only MAX_PHYSMEM_BITS for zsmalloc (like
> it was before commit 02390b87) instead, and make sure *at least* ARM
> 32/64 and x86/x64, for now, have it defined outside sparsemem headers
> as well ?
It
On Wed, Oct 24, 2018 at 10:27:44PM -0300, Rafael David Tinoco wrote:
> On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
> physical frame number might be so big that zsmalloc obj encoding (to
> location) will break IF architecture does not re-define
> MAX_PHYSMEM_BITS, causing:
On Wed, Oct 24, 2018 at 04:20:03PM +0530, shubhrajyoti.da...@gmail.com wrote:
> From: Shubhrajyoti Datta
>
> In some cases we are waiting in a loop. Replace the infinite wait with
> the timeout.
>
> Signed-off-by: Shubhrajyoti Datta
> ---
> drivers/i2c/busses/i2c-cadence.c | 30 ++
On Wed, Oct 24, 2018 at 07:35:46AM +, Corentin Labbe wrote:
> This patchset adds a new set of functions which are open-coded in lot of
> place.
> Basicly the pattern is always the same, "read, modify a bit, write"
> some driver and the powerpc arch already have thoses pattern them as
> functio
On Tue, Oct 23, 2018 at 10:47:05AM +0200, Clément Péron wrote:
> Hi Dinh / Russell,
>
> Could you have a look at these patchs please ?
Nothing to do with me - it's up to the socfpga maintainer and arm-soc
maintainers.
> Thanks,
> Clement
>
> On Tue, 9 Oct 2018 at 13:20, Clément Péron wrote:
>
On Thu, Oct 18, 2018 at 02:16:47PM +0800, Teng Fei Fan wrote:
> This patch adds support for cacheinfo on 32bit ARMv8 platform.
> Add support for detecting cpu cache information cpu cache information
> via sysfs for 32bit armv8 platform. And export to sysfs then userspace
> can get from /sys/devices
On Tue, Oct 16, 2018 at 04:55:00PM +0300, Andy Shevchenko wrote:
> On Tue, Oct 16, 2018 at 3:55 PM Andrzej Hajda wrote:
> > On 16.10.2018 13:29, Andrzej Hajda wrote:
> > > On 16.10.2018 13:01, Andy Shevchenko wrote:
> > >> On Tue, Oct 16, 2018 at 10:22 AM Andrzej Hajda
> > >> wrote:
> > >>> Duri
On Wed, Oct 17, 2018 at 11:04:17AM +0200, Arnd Bergmann wrote:
> The constraints were originally added in commit 9a40ac86152c ("ARM:
> 6164/1: Add kto and kfrom to input operands list.") as a gcc-4.5
> workaround. Another workaround for the same problem was added in commit
> 9c695203a7dd ("compiler
On Tue, Oct 16, 2018 at 10:00:19AM +0200, Linus Walleij wrote:
> On Tue, Oct 16, 2018 at 12:16 AM Stefan Agner wrote:
>
> > When functions incoming parameters are not in input operands list gcc
> > 4.5 does not load the parameters into registers before calling this
> > function but the inline ass
On Mon, Oct 15, 2018 at 07:27:43PM -0400, Nicolas Pitre wrote:
> It's hard to see what that commit was actually fixing, but the operands
> usage is wrong as explained already. Maybe the generated code has been
> OK for all those years but that is due to luck rather than correctness.
...
> No idea
On Tue, Oct 16, 2018 at 12:52:58AM +0200, Stefan Agner wrote:
> On 16.10.2018 00:46, Russell King - ARM Linux wrote:
> > On Tue, Oct 16, 2018 at 12:39:54AM +0200, Stefan Agner wrote:
> >> On 16.10.2018 00:23, Russell King - ARM Linux wrote:
> >> > On Tue, Oct 16, 20
On Mon, Oct 15, 2018 at 06:54:49PM -0400, Nicolas Pitre wrote:
> On Mon, 15 Oct 2018, Russell King - ARM Linux wrote:
>
> > On Mon, Oct 15, 2018 at 06:35:33PM -0400, Nicolas Pitre wrote:
> > > On Tue, 16 Oct 2018, Stefan Agner wrote:
> > >
> > > > GCC
On Tue, Oct 16, 2018 at 12:39:54AM +0200, Stefan Agner wrote:
> On 16.10.2018 00:23, Russell King - ARM Linux wrote:
> > On Tue, Oct 16, 2018 at 12:16:29AM +0200, Stefan Agner wrote:
> >> When functions incoming parameters are not in input operands list gcc
> >> 4.5 d
On Mon, Oct 15, 2018 at 06:35:33PM -0400, Nicolas Pitre wrote:
> On Tue, 16 Oct 2018, Stefan Agner wrote:
>
> > GCC documentation says naked functions should only use basic ASM
> > syntax. The extended ASM or mixture of basic ASM and "C" code is
> > not guaranteed. Currently it seems to work thoug
On Tue, Oct 16, 2018 at 12:16:29AM +0200, Stefan Agner wrote:
> When functions incoming parameters are not in input operands list gcc
> 4.5 does not load the parameters into registers before calling this
> function but the inline assembly assumes valid addresses inside this
> function. This breaks
On Fri, Oct 12, 2018 at 11:43:13AM +, Marcel Ziswiler wrote:
> I don't think it is that fictitious as it makes it crystal clear that
> there is something shared with all its pros and cons. E.g. what happens
> if one of them regulators wants to turn off while the other one still
> needs power? T
On Fri, Oct 12, 2018 at 11:39:15AM +0100, Jon Hunter wrote:
> We had the same situation for Tegra124 Jetson TK1 but I don't think that
> adding a pseudo intermediate regulator is cleaner. If the GPIO controls
> more than one regulator, I don't see why is it necessary to change the
> DT. There are s
On Wed, Oct 10, 2018 at 02:04:14PM +0200, Stefan Wahren wrote:
> Hi,
>
> Am 10.10.2018 um 13:19 schrieb Rob Herring:
> > On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> > wrote:
> >> Hi,
> >>
> >>
> >> I see a bunch of vendor (or SoC) names in
> >> Documentation/device/bindings/arm/
> >>
> >> .
On Wed, Oct 10, 2018 at 08:07:52PM +0900, Masahiro Yamada wrote:
> Hi,
>
>
> I see a bunch of vendor (or SoC) names in
> Documentation/device/bindings/arm/
>
> ./Documentation/devicetree/bindings/arm/altera
> ./Documentation/devicetree/bindings/arm/amlogic
> ./Documentation/devicetree/bindings/a
On Tue, Oct 09, 2018 at 04:58:18PM +0100, Will Deacon wrote:
> On Tue, Oct 09, 2018 at 05:43:59PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 09, 2018 at 05:39:27PM +0200, Lukasz Luba wrote:
> > > This patch add some warning related to performance drop.
> > > It should be mentioned that this is no
On Fri, Oct 05, 2018 at 10:15:57AM +0530, Manjeet Pawar wrote:
> From: Rohit Thapliyal
>
> During user undefined instruction exception, the arm exception
> handler currently results in application crash through SIGILL.
> The bad instruction can be due to ddr/hardware issue.
> For such cases, exc
On Fri, Oct 05, 2018 at 10:27:48AM +0200, Nicolas Cavallari wrote:
> On 04/10/2018 18:49, Russell King - ARM Linux wrote:
> > This isn't going to work.
> >
> > For example, sysrq processing (which can happen in IRQ context) calls
> > emergency_restart() for the r
On Thu, Oct 04, 2018 at 06:23:38PM +0200, Nicolas Cavallari wrote:
> Many users of restart_handlers are sleeping in their callbacks. Some
> are doing infinite loops or calling driver code that may sleep or
> perform operation on slow busses, like i2c.
>
> This is not allowed in an atomic notifier
On Thu, Oct 04, 2018 at 05:45:13PM +0530, Souptick Joarder wrote:
> On Thu, Oct 4, 2018 at 3:45 AM Russell King - ARM Linux
> wrote:
> >
> > On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> > > On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joard
On Thu, Oct 04, 2018 at 10:54:15AM +0200, Clément Péron wrote:
> From: Dinh Nguyen
>
> Turn on these ARM and PL310 errata for SoCFPGA:
>
> ARM_ERRATA_754322
> ARM_ERRATA_764369
> ARM_ERRATA_775420
>
> PL310_ERRATA_588369
> PL310_ERRATA_727915
> PL310_ERRATA_753970
> PL310_ERRATA_769419
>
> Fix
On Mon, Oct 01, 2018 at 01:44:52PM -0700, Mark Salyzyn wrote:
> Despite the gain of 0.4% for screen-on battery life, where Android has a mix
> of 64 and 32 bit applications, thus still relevant _today_ on 64 bit
> architectures (providing vDSO32 for 32-bit applications).
I don't think the issue is
On Mon, Oct 01, 2018 at 08:10:26PM +0200, Ard Biesheuvel wrote:
> On 1 October 2018 at 19:56, Russell King - ARM Linux
> wrote:
> > On Sun, Sep 30, 2018 at 04:49:04AM +0200, Jason A. Donenfeld wrote:
> >> Per the discussion about half-way down in [1], the kernel doesn't
On Sun, Sep 30, 2018 at 04:49:04AM +0200, Jason A. Donenfeld wrote:
> Per the discussion about half-way down in [1], the kernel doesn't
> actually support the ARMv3 ISA, but selects it for some ARMv4 ISA
> hardware that benefits from ARMv3 code generation.
The issue is to do with the half-word sto
On Sun, Sep 30, 2018 at 04:48:20PM -0700, Joe Perches wrote:
> On Mon, 2018-10-01 at 00:22 +0200, Stefan Agner wrote:
> > The kernel passes the ArmV6K architecture to the compiler when
> > using the multi platform selection and enabling ARMv6. Clang
> > older than version 8.0 emit assembly with an
On Sat, Sep 29, 2018 at 01:20:36PM +0800, Jisheng Zhang wrote:
> Hi,
>
> Recently I found I could trigger sleep in atomic bug on berlin after commit
> d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling"). The path looks
> like:
>
> dw8250_probe => serial850_register_8250_port => uart_add_on
On Mon, Sep 24, 2018 at 12:26:14PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote:
>
> > > Thanks for the testing. I'll wait for Russell to say if he is happy
> > > (or not) with the addition of
On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote:
> > On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > > What about something like the below. I tested it, including the error
> > > case by forcing
On Thu, Sep 20, 2018 at 10:13:57PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> For years arm has been using serial.h from asm-generic which sets
> BASE_BAUD value to the (1843200 / 16). This is incorrect as:
> 1) This value obviously isn't correct for all devices
> 2) There are no devic
801 - 900 of 5260 matches
Mail list logo
