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()
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
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
> ---
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
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?
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()
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()
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 fed b
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 fed b
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
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
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
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
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)
> > +{
> > +
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)
> > +{
> > +
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
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
Hi,
As I've already fed back to Sascha about this, this patch on its own
does not fix anything, and is not a stable kernel candidate without
a patch that makes use of it (iow, the spectre fixes.) It is a
preparatory patch for mainline commit 383fb3ee8024.
Every commit in:
$ git rev-list
Hi,
As I've already fed back to Sascha about this, this patch on its own
does not fix anything, and is not a stable kernel candidate without
a patch that makes use of it (iow, the spectre fixes.) It is a
preparatory patch for mainline commit 383fb3ee8024.
Every commit in:
$ git rev-list
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 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 has b
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 has b
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 +0000, Russell King - ARM Linux wrote:
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 +0000, 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 +0000, 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 +0000, 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: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's ta
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's ta
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 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 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 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 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, w
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, w
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 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/omap
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/omap
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(-)
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(-)
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
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
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 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:
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:
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
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
Same comments as for the 4.9 version of these patches, and also applies
to the two 3.18 patches as well. They aren't fixes, but preparation
for fixes, and should not be backported without the actual Spectre fix
patch (which probably requires manual backport effort.)
On Thu, Nov 22, 2018 at
Same comments as for the 4.9 version of these patches, and also applies
to the two 3.18 patches as well. They aren't fixes, but preparation
for fixes, and should not be backported without the actual Spectre fix
patch (which probably requires manual backport effort.)
On Thu, Nov 22, 2018 at
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
> from the rest of
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
> from the rest of
This, and your patch 11 aren't fixes on their own. They're part of a
rework for the "ARM: spectre-v2: per-CPU vtables to work around
big.Little systems" patch. It doesn't make sense to back port these
without that patch, even though they can be applied without.
On Thu, Nov 22, 2018 at
This, and your patch 11 aren't fixes on their own. They're part of a
rework for the "ARM: spectre-v2: per-CPU vtables to work around
big.Little systems" patch. It doesn't make sense to back port these
without that patch, even though they can be applied without.
On Thu, Nov 22, 2018 at
Hi Sasha,
We need to keep track of which Spectre patches have been backported
and which haven't. David Long has been doing the backport work,
which doesn't include all the patches in my present spectre branch.
You've picked up the last five, meaning there's a bunch in the middle
of the entire
Hi Sasha,
We need to keep track of which Spectre patches have been backported
and which haven't. David Long has been doing the backport work,
which doesn't include all the patches in my present spectre branch.
You've picked up the last five, meaning there's a bunch in the middle
of the entire
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
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
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 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 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
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
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 the
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 the
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 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
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
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
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
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
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
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
>
>
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
>
>
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 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
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
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.
> >
> >
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.
> >
> >
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: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
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
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
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
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
>
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
>
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
801 - 900 of 8578 matches
Mail list logo
