The patch
regulator: core: Fix size limit of supply_map
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
spi: imx: dynamic burst length adjust for PIO mode
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
On Thu, Jun 29, 2017 at 09:03:42PM -0700, Linus Torvalds wrote:
> On Thu, Jun 29, 2017 at 12:15 PM, Marcelo Tosatti wrote:
> > On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote:
> >>
> >> swait uses special locking and has odd semantics that are not at all
> >> the same as the defaul
On Fri, Jun 30, 2017 at 12:42:38PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 6/30/2017 8:22 AM, Gustavo A. R. Silva wrote:
>
> > Print error message and propagate the return value of
> > platform_get_irq on failure.
>
>You should have probably mentioned that this function no longer retur
The patch
ASoC: fix semicolon.cocci warnings
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
The patch
ASoC: rsnd: make arrays path and cmd_case static const
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
ASoC: rsnd: constify dev_pm_ops structures.
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Lin
On 30/06/17 12:36, Benjamin Gaignard wrote:
> 2017-06-28 11:16 GMT+02:00 Vladimir Murzin :
>> These two patches are folloups on "[PATCH v6 0/7] ARM: Fix
>> dma_alloc_coherent() and friends for NOMMU" which has been partly
>> merged in [1]. PATCH 1/2 is done per Christoph's suggestion [2] to
>> elim
From: Nandor Han
Avoid the situation when `dma_is_rxing` could incorrectly signal that
DMA RX channel is receiving data in case DMA preparation or sg mapping
fails.
Signed-off-by: Nandor Han
Signed-off-by: Romain Perier
---
drivers/tty/serial/imx.c | 9 +
1 file changed, 5 insertions(
During shutdown when a userspace service is disabled (which generates
an uart close), we got kernel crashes in the imx serial driver :
[ 1257.657423] Unhandled fault: external abort on non-linefetch (0x1008) at
0xf0938000
[ 1257.665122] pgd = ecf2
[ 1257.667838] [f0938000] *pgd=de819811, *pte
From: Nandor Han
During DMA startup we have a data race condition since UART port can
receive data that can generate different type of errors.
This is not necessarily an error since DMA didn't yet started. The
situation is minimized but still present even if we try to clear up the
error before s
From: Nandor Han
Initialize both dma_is_{rx|tx}ing variables when DMA is enabled to avoid
checking uninitialized variables if port shutdown is requested before
DMA channels get a chance to start.
Signed-off-by: Nandor Han
Signed-off-by: Romain Perier
---
drivers/tty/serial/imx.c | 3 +++
1 fi
From: Nandor Han
This commits unmaps sg buffers when the DMA channel is released
Signed-off-by: Nandor Han
Signed-off-by: Romain Perier
---
drivers/tty/serial/imx.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e8cf
From: Nandor Han
This commits simplify the function imx_disable_dma() by moving
the code for disabling RX and TX DMAs to dedicated functions.
Also move away CTSC and CTS as this is not related to DMA.
Signed-off-by: Nandor Han
Signed-off-by: Romain Perier
---
drivers/tty/serial/imx.c | 31 +++
From: Nandor Han
According to "Documentation/serial/driver" both procedures should stop
receiving or sending data. Based on this the procedures should stop the
activity regardless if DMA is enabled or not.
This commit updates both imx_stop_{rx|tx} procedures to stop the
activity and disable the
From: Nandor Han
In some cases, It looks that interrupts can happen after the dma was
disabled and port was not yet shutdown. This will result in interrupts
handled by imx_rxint.
This commits updates the shutdown function to ensure that underlying
components are disabled in the right order. This
The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCPI protocol to signal a
request for some action to be taken by the mana
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work with const
attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
4622 304 849341346 drive
On Fri, Jun 30, 2017 at 12:22:13PM +0800, Chen-Yu Tsai wrote:
> What I'm saying is for the DT case, the constraints are already limited
> to the intersection of all users, regardless of whether they are turned
> on or not. At least this is what I believe makes sense. You really don't
> want to set
Hi,
On Fri, 30 Jun 2017 14:04:42 +0200 Romain Perier wrote:
> From: Nandor Han
>
> Initialize both dma_is_{rx|tx}ing variables when DMA is enabled to avoid
> checking uninitialized variables if port shutdown is requested before
> DMA channels get a chance to start.
>
> Signed-off-by: Nandor Han
Hi Mark,
On Fri, Jun 30, 2017 at 01:00:22PM +0100, Mark Brown wrote:
> The patch
>
>spi: imx: dynamic burst length adjust for PIO mode
>
> has been applied to the spi tree at
>
>git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
Argh, I wasn't fast enough. I just ran spi-lo
On Fri, Jun 30, 2017 at 02:13:30PM +0530, Viresh Kumar wrote:
> On 30-06-17, 14:36, Chen-Yu Tsai wrote:
> Operable ranges of the regulator: 1.8 - 3.0 V
> Range required by LCD: 2.0 - 3.0 V
> Range required by DMA: 1.8 - 2.5 V
> Here DMA can't work with regulator voltages > 2.5 V, but regulator ca
On Thu 2017-06-29 16:56:30, Sergey Senozhatsky wrote:
> yeah, I agree and understand that per-CPU printk kthreads
> is a bit... too much.
>
> it was just a quick idea and I just gave it a try. but there
> are some potential takeaways from the series (not sure if you
> looked at the last patches of
On Fri, Jun 30, 2017 at 01:37:32PM +0200, Waldemar Rymarkiewicz wrote:
> I am not sure if I understand. Do you mean, a regulator should
> determine a voltage and update a register with a right selector when
> system boots, so the regulator framework reading reg register knows
> actual voltage?
Ju
Hi Clemens,
On Wed, Jun 21, 2017 at 11:12 AM, Fabio Estevam wrote:
>> I'd also prefer fixing the underlying problem.
>
> Yes, that would be much better.
Just saw Romain's patch series that addresses several imx uart DMA issues:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/516
On Thu, Jun 29, 2017 at 11:33 PM, Thomas Gleixner wrote:
> The irq chip callbacks irq_request/release_resources() have absolutely no
> business with masking and unmasking the irq.
>
> The core code unmasks the interrupt after complete setup and masks it
> before invoking irq_release_resources().
On Fri, 30 Jun 2017, Linus Walleij wrote:
> On Thu, Jun 29, 2017 at 11:33 PM, Thomas Gleixner wrote:
>
> > The irq chip callbacks irq_request/release_resources() have absolutely no
> > business with masking and unmasking the irq.
> >
> > The core code unmasks the interrupt after complete setup an
On Thu, Jun 29, 2017 at 9:28 PM, Alan Cox wrote:
>> General-purpose input/output - yeah that sounds like something
>> going in/out of the system right?
>
> It's become an ACPI interface for controlling all sorts of system state
> in a way that works nicely in Windows. Rightly or wrongly that's th
Hi Baruch, Alexandre
On 29.06.2017 15:16, Alexandre Belloni wrote:
> On 29/06/2017 at 14:59:31 +0300, Baruch Siach wrote:
>> Hi Claudiu,
>>
>> On Thu, Jun 29, 2017 at 02:44:34PM +0300, Claudiu Beznea wrote:
>>> Add specifig DTS files and bindings for sama5d27 SoM1 EK board.
>>
>> Is there any publ
Hi Mark,
The problem is that our used regulator TPS65273V from TI do not have the
possibility to read the current voltage defined by the HW, means by the circuit
of the regulator.
In this case the register holding the voltage to be set later by software has a
reset value which is normally the m
Hi,
On Fri, Jun 30, 2017 at 10:56:00AM +0100, Andre Przywara wrote:
> The remaining patches demonstrate usage of this feature to drive SCPI services
> implemented as part of the ARM Trusted Firmware implementation used for
> AArch64 based Allwinner SoCs, the Allwinner A64 in this example.
> It all
On Thu, 29 Jun 2017 22:17:22 -0700
Joel Fernandes wrote:
> Hi Steven,
>
> Did you have any comments about this patch? It was sent a while ago
> and if you can provide me your initial thoughts on it, I would
> appreciate it. (Sorry to ping you about it during the busy merge
> window time, but I w
Hi Ludovic,
On 29.06.2017 18:04, Ludovic Desroches wrote:
> On Thu, Jun 29, 2017 at 02:44:34PM +0300, Claudiu Beznea wrote:
>> Add specifig DTS files and bindings for sama5d27 SoM1 EK board.
>>
>> Signed-off-by: Claudiu Beznea
>> Signed-off-by: Cristian Birsan
>> ---
>> arch/arm/boot/dts/Makefi
On 06/30/2017 12:42 PM, Sergei Shtylyov wrote:
Print error message and propagate the return value of
platform_get_irq on failure.
You should have probably mentioned that this function no longer returns 0
on error.
It's prolly also worth mentioning that enforcing the error # on return
On Fri, Jun 30, 2017 at 12:31:50PM +0200, Arnd Bergmann wrote:
> On Fri, Jun 30, 2017 at 2:01 AM, Paul E. McKenney
> wrote:
> > There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> > and it appears that all callers could do just as well with a lock/unlock
> > pair. This commit
On Thu, Jun 29, 2017 at 10:11:34AM +0100, Richard Fitzgerald wrote:
> There are build dependencies between the subsystems but I don't know how
> the maintainers prefer to deal with that - keep the patches as a set or
> cross-merge branches.
It's good to at least have the option to have the code i
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work with const
attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/acpi/bgrt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
On Fri, Jun 30, 2017 at 09:41:35AM +0300, Tomi Valkeinen wrote:
> On 29/06/17 21:50, Aaro Koskinen wrote:
> > Hi,
> >
> > On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> >> On 15/06/17 01:11, Aaro Koskinen wrote:
> >>> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe
Sergey Senozhatsky wrote:
> On (06/30/17 19:18), Tetsuo Handa wrote:
> > > I'm still thinking about Steven's proposals; but we will need offloading
> > > anyways, so the bits we are talking about here are important regardless
> > > the direction printk design will take, I think.
> >
> > Is there a
On Fri, Jun 30, 2017 at 10:19:29AM +0100, Will Deacon wrote:
> On Thu, Jun 29, 2017 at 05:01:16PM -0700, Paul E. McKenney wrote:
> > There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> > and it appears that all callers could do just as well with a lock/unlock
> > pair. This com
Hi Ludovic,
On 29.06.2017 17:58, Ludovic Desroches wrote:
> On Thu, Jun 29, 2017 at 02:44:33PM +0300, Claudiu Beznea wrote:
>> Add specific DTS file and bindings for sama5d27 SoM1 board.
>>
>> Signed-off-by: Claudiu Beznea
>> Signed-off-by: Cristian Birsan
>> ---
>> arch/arm/boot/dts/at91-sama5
Hello,
On (06/30/17 13:54), Petr Mladek wrote:
> > but.
> > the opposite possibility is that messages either won't be printed
> > soon (until next printk or console_unlock()) or won't be printed
> > ever at all (in case of sudden system death). I don't think it's
> > a good alternative.
>
> I
Today sending a signal with rt_sigqueueinfo and receving it on
a signalfd does not work reliably. The issue is that reading
a signalfd instead of returning a siginfo returns a signalfd_siginfo and
the kernel must convert from one to the other.
The kernel does not currently have the code to deduc
On Thu, 29 Jun, at 08:53:12AM, Andy Lutomirski wrote:
> *** Ingo, even if this misses 4.13, please apply the first patch before
> *** the merge window.
>
> There are three performance benefits here:
>
> 1. TLB flushing is slow. (I.e. the flush itself takes a while.)
>This avoids many of them
On (06/30/17 14:11), Petr Mladek wrote:
> > 2) can offload printing to other CPUs from vprintk_emit()
> >and avoid any of scheduler->timekeeping->etc. paths. which will
> >replace printk_deferred().
>
> I probably miss something. There is still called wake_up_process()
> in this patchset a
Setting si_code to __SI_FAULT results in a userspace seeing
an si_code of 0. This is the same si_code as SI_USER. Posix
and common sense requires that SI_USER not be a signal specific
si_code. As such this use of 0 for the si_code is a pretty
horribly broken ABI.
Given that alpha is on it's las
Setting si_code to __SI_FAULT results in a userspace seeing
an si_code of 0. This is the same si_code as SI_USER. Posix
and common sense requires that SI_USER not be a signal specific
si_code. As such this use of 0 for the si_code is a pretty
horribly broken ABI.
Given that ia64 is on it's last
While examining the code I realized that we don't copy si_call_addr to
32bit callers. Fix it.
It looks like no one has used this code path in the last 5 years.
Cc: Will Drewry
Cc: H. Peter Anvin
Cc: Eric Paris
Cc: Serge Hallyn
Cc: James Morris
Fixes: a0727e8ce513 ("signal, x86: add SIGSYS i
We have a weird and problematic intersection of features that when
they all come together result in ambiguous siginfo values, that
we can not support properly.
- Supporting fcntl(F_SETSIG,...) with arbitrary valid signals.
- Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc
that i
Setting si_code to __SI_FAULT results in a userspace seeing
an si_code of 0. This is the same si_code as SI_USER. Posix
and common sense requires that SI_USER not be a signal specific
si_code. As such this use of 0 for the si_code is a pretty
horribly broken ABI.
This use of of __SI_FAULT is on
struct siginfo is a union and the kernel since 2.4 has been hiding a union
tag in the high 16bits of si_code using the values:
__SI_KILL
__SI_TIMER
__SI_POLL
__SI_FAULT
__SI_CHLD
__SI_RT
__SI_MESGQ
__SI_SYS
While this looks plausible on the surface, in practice this situation has
not worked well.
Fix the debug print statements in these tests where they reference
si_codes and in particular __SI_FAULT. __SI_FAULT is a kernel
internal value and should never be seen by userspace.
While I am in there also fix si_code_str. si_codes are an enumeration
there are not a bitmap so == and not & is t
Setting si_code to __SI_FAULT results in a userspace seeing
an si_code of 0. This is the same si_code as SI_USER. Posix
and common sense requires that SI_USER not be a signal specific
si_code. As such this use of 0 for the si_code is a pretty
horribly broken ABI.
This was introduced in 2.3.41 s
Hi,
On 29-06-17 16:22, Andy Shevchenko wrote:
+Cc: Hans (he might give some advice regarding to the below)
Thank you for the Cc, so here we have the opposite situation as
with the devices with the AXP288 PMIC and the Cherry Trail
Whiskey Cove PMIC combined with the TI bq24292i charger and max1
On Fri, Jun 30, 2017 at 01:04:45PM +0200, Oleg Nesterov wrote:
> On 06/29, Paul E. McKenney wrote:
> >
> > --- a/kernel/task_work.c
> > +++ b/kernel/task_work.c
> > @@ -109,7 +109,8 @@ void task_work_run(void)
> > * the first entry == work, cmpxchg(task_works) should
> > *
On (06/30/17 21:35), Tetsuo Handa wrote:
> Date: Fri, 30 Jun 2017 21:35:28 +0900
> From: Tetsuo Handa
> To: sergey.senozhatsky.w...@gmail.com
> Cc: pmla...@suse.com, sergey.senozhat...@gmail.com, rost...@goodmis.org,
> j...@suse.cz, a...@linux-foundation.org, pet...@infradead.org,
> r...@rjwysoc
On Fri, Jun 30, 2017 at 5:45 AM, Michael Ellerman wrote:
> "Rafael J. Wysocki" writes:
>
>> On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman
>> wrote:
>>> On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote:
local_irq_enable can cause interrupts to be taken which could
take sign
On Tue, 11 Apr 2017 22:38:51 -0700
Joel Fernandes wrote:
> diff --git a/include/trace/events/critical.h b/include/trace/events/critical.h
> new file mode 100644
> index ..bfd58dd4f48f
> --- /dev/null
> +++ b/include/trace/events/critical.h
> @@ -0,0 +1,55 @@
> +#undef TRACE_SYSTEM
> +
Hi Vincent,
On 06/28/2017 08:45 PM, Vincent Guittot wrote:
> Hi Georgi,
>
> On 27 June 2017 at 19:49, Georgi Djakov wrote:
>
> [snip]
>
>> +
>> +static int interconnect_aggregate(struct interconnect_node *node,
>> + struct interconnect_creq *creq)
>> +{
>> +
On Fri, Jun 30, 2017 at 09:45:58AM +0100, Will Deacon wrote:
> On Fri, Jun 30, 2017 at 02:19:20PM +0800, kernel test robot wrote:
> >
> > FYI, we noticed the following commit:
> >
> > commit: 46a4746d9a364a9b0267c19be0f8419e9b72ad37 ("task_work: Replace
> > spin_unlock_wait() with lock/unlock pa
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work with const
attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/acpi/acpi_lpss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi Dieter,
thanks a lot for testing that.
But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470
(Nehalem), PCIe 2.0, 24 GB is to old for this stuff...
Well, actually you only need to figure out how to enable a PCIe window
above the 4GB limit.
Could be that the BIOS supports this
On Fri, Jun 30, 2017 at 03:38:22PM +0300, m18063 wrote:
> Hi Ludovic,
>
> On 29.06.2017 17:58, Ludovic Desroches wrote:
> > On Thu, Jun 29, 2017 at 02:44:33PM +0300, Claudiu Beznea wrote:
> >> Add specific DTS file and bindings for sama5d27 SoM1 board.
> >>
> >> Signed-off-by: Claudiu Beznea
> >>
On Fri, Jun 30, 2017 at 11:28 AM, John Garry wrote:
> On 30/06/2017 10:05, Mika Westerberg wrote:
>>
>> On Thu, Jun 29, 2017 at 05:16:15PM +0100, John Garry wrote:
>>>
>>> On 16/06/2017 12:24, Rafael J. Wysocki wrote:
>>
>>
>> It causes acpi_default_enumeration() to be call
Hi Rob,
On 06/30/2017 12:32 AM, Rob Herring wrote:
> On Tue, Jun 27, 2017 at 08:49:03PM +0300, Georgi Djakov wrote:
>> The interconnect API is not yet using DT bindings for expressing
>> the relations between the API consumers and providers. This is
>> posted a separate patch as it needs further d
Hi,
thanks for having a look!
On 30/06/17 13:25, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jun 30, 2017 at 10:56:00AM +0100, Andre Przywara wrote:
>> The remaining patches demonstrate usage of this feature to drive SCPI
>> services
>> implemented as part of the ARM Trusted Firmware implementation
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work with const
attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
904 496 01400 578 drive
On Fri, 30 Jun 2017, Andrey Ryabinin wrote:
> On 06/30/2017 01:15 PM, Thomas Gleixner wrote:
> > On Fri, 30 Jun 2017, Michal Hocko wrote:
> >> So I like this simplification a lot! Even if we can get rid of the
> >> stop_machine eventually this patch would be an improvement. A short
> >> comment on
On 30.06.2017 15:57, Ludovic Desroches wrote:
> On Fri, Jun 30, 2017 at 03:38:22PM +0300, m18063 wrote:
>> Hi Ludovic,
>>
>> On 29.06.2017 17:58, Ludovic Desroches wrote:
>>> On Thu, Jun 29, 2017 at 02:44:33PM +0300, Claudiu Beznea wrote:
Add specific DTS file and bindings for sama5d27 SoM1
Hi Varadarajan,
[auto build test ERROR on pinctrl/devel]
[also build test ERROR on v4.12-rc7]
[cannot apply to robh/for-next next-20170630]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
+CC Kernel List
On Fri, Jun 30, 2017 at 08:33:56AM -0300, Pedro H. Penna wrote:
> Usually, hardware implicitly acknowledges interruts when
> reading them. However, if this is not the case, the IRQ
> gets fired over and over again in the current implementation.
>
> This patch uses the right mask a
On 2017-06-29 19:58, Steven Rostedt wrote:
> On Thu, 29 Jun 2017 17:21:22 -0400
> Richard Guy Briggs wrote:
>
> > > Looking at this again today, why would we want to clear name->dentry
> > > in audit_copy_inode() if it is already set? Does that ever happen?
> > > I'm not sure it does ...
> >
On 30/06/17 14:04, Stafford Horne wrote:
> +CC Kernel List
>
> On Fri, Jun 30, 2017 at 08:33:56AM -0300, Pedro H. Penna wrote:
>> Usually, hardware implicitly acknowledges interruts when
>> reading them. However, if this is not the case, the IRQ
>> gets fired over and over again in the current imp
On Fri, Jun 30, 2017 at 11:47:35AM +0200, Michal Hocko wrote:
> [CC John, the thread started
> http://lkml.kernel.org/r/9363561f-a9cd-7ab6-9c11-ab9a99dc8...@oracle.com]
>
> On Thu 29-06-17 14:41:22, prakash.sangappa wrote:
> >
> >
> > On 06/29/2017 01:09 AM, Michal Hocko wrote:
> > >On Wed 28-06
On Thu, 29 Jun, at 08:49:13PM, Josef Bacik wrote:
>
> It may be worth to try with schedbench and trace it to see how this turns out
> in
> practice, as that's the workload that generated all this discussion before. I
> imagine generally speaking this works out properly. The small regression I
>
On Thu, Jun 29, 2017 at 10:41:44PM -0700, Andy Lutomirski wrote:
> On Thu, Jun 29, 2017 at 10:05 PM, Andy Lutomirski wrote:
> > Hmm. There's another option that might be considerably nicer, though:
> > put the IRQ stack at a known (at link time) position *in percpu
> > space*. (Presumably it alr
Hi,
On 29/06/17 12:49, Maxime Ripard wrote:
> On Thu, Jun 29, 2017 at 11:57:05AM +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 25/06/17 21:45, Priit Laes wrote:
>>> Convert sun7i-a20.dtsi to new CCU driver.
>>
>> I know that some people hat^Wget annoyed by me asking this, but anyway:
>>
>> Why do w
Commit-ID: b892cb873ced2af57dc5a018557d128c53ed6ae0
Gitweb: http://git.kernel.org/tip/b892cb873ced2af57dc5a018557d128c53ed6ae0
Author: Baoquan He
AuthorDate: Tue, 27 Jun 2017 20:39:05 +0800
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 08:53:14 +0200
x86/boot/KASLR: Add checking
Commit-ID: 8eabf42ae5237e6b699aeac687b5b629e3537c8d
Gitweb: http://git.kernel.org/tip/8eabf42ae5237e6b699aeac687b5b629e3537c8d
Author: Baoquan He
AuthorDate: Tue, 27 Jun 2017 20:39:06 +0800
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 08:53:14 +0200
x86/boot/KASLR: Fix kexec cra
Commit-ID: 48365b38849fdb1ee6dc65beac044ca59f669683
Gitweb: http://git.kernel.org/tip/48365b38849fdb1ee6dc65beac044ca59f669683
Author: Daniel Bristot de Oliveira
AuthorDate: Mon, 26 Jun 2017 17:07:14 +0200
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 09:32:07 +0200
sched/debug:
On Fri, 2017-06-30 at 02:42:47 -0500, Gustavo A. R. Silva wrote:
> Print error message and propagate the return value of
> platform_get_irq on failure.
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Sören Brinkmann
Sören
Commit-ID: e91c8d97eac74e603481840d950536bcb62b471b
Gitweb: http://git.kernel.org/tip/e91c8d97eac74e603481840d950536bcb62b471b
Author: Colin Ian King
AuthorDate: Thu, 29 Jun 2017 10:14:06 +0100
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 09:00:56 +0200
perf/x86/intel: Constify
On Fri, Jun 30, 2017 at 05:38:15AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 30, 2017 at 10:19:29AM +0100, Will Deacon wrote:
> > On Thu, Jun 29, 2017 at 05:01:16PM -0700, Paul E. McKenney wrote:
> > > There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> > > and it appears tha
Commit-ID: a24261d70e00e4ce03cf45bbf18398f52a7b9229
Gitweb: http://git.kernel.org/tip/a24261d70e00e4ce03cf45bbf18398f52a7b9229
Author: Kirill A. Shutemov
AuthorDate: Wed, 28 Jun 2017 15:17:30 +0300
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 08:56:53 +0200
x86/KASLR: Fix detect
Commit-ID: 993647a293814dd47ae41d38657fda6e4ab04e33
Gitweb: http://git.kernel.org/tip/993647a293814dd47ae41d38657fda6e4ab04e33
Author: Arvind Yadav
AuthorDate: Thu, 29 Jun 2017 17:40:47 +0530
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 09:34:39 +0200
cpu/hotplug: Constify attri
Commit-ID: 72298e5c92c50edd8cb7cfda4519483ce65fa166
Gitweb: http://git.kernel.org/tip/72298e5c92c50edd8cb7cfda4519483ce65fa166
Author: Gustavo A. R. Silva
AuthorDate: Thu, 29 Jun 2017 13:41:28 -0500
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 09:37:59 +0200
sched/cputime: Refac
Dear user
Your mailbox has exceeded the storage limit of 20GB set by the
administrator, you are currently running at 20.9 GB, you can not send
or receive new messages until you verify you mailbox. Re-validate your
account by mail, please fill and Send the data below to verify and
update
On Fri 2017-06-30 16:01:31, Sergey Senozhatsky wrote:
> we are doing our best in order to avoid lockups caused by console_unlock(),
> but the top priority remains messages print out. If we can't guarantee that
> anything will take over and print the messages, we continue printing from
> the current
Commit-ID: dcc914f44f065ef73685b37e59877a5bb3cb7358
Gitweb: http://git.kernel.org/tip/dcc914f44f065ef73685b37e59877a5bb3cb7358
Author: Josh Poimboeuf
AuthorDate: Wed, 28 Jun 2017 10:11:05 -0500
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 10:19:19 +0200
objtool: Move checking co
On Wed 28-06-17 19:52:58, Oleg Nesterov wrote:
> expand_stack(vma) fails if address < stack_guard_gap even if there is no
> vma->vm_prev. I don't think this makes sense, and we didn't do this before
> the recent commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas").
> We do not need a ga
Commit-ID: c207aee48037abca71c669cbec407b9891965c34
Gitweb: http://git.kernel.org/tip/c207aee48037abca71c669cbec407b9891965c34
Author: Josh Poimboeuf
AuthorDate: Wed, 28 Jun 2017 10:11:06 -0500
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 10:19:19 +0200
objtool, x86: Add several
Commit-ID: bc0d5a89fbe3c83ac45438d7ba88309f4713615d
Gitweb: http://git.kernel.org/tip/bc0d5a89fbe3c83ac45438d7ba88309f4713615d
Author: Andy Lutomirski
AuthorDate: Thu, 29 Jun 2017 08:53:13 -0700
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 10:12:35 +0200
x86/mm: Don't reenter fl
Commit-ID: baa41469a7b992c1e3db2a39854219cc7442e48f
Gitweb: http://git.kernel.org/tip/baa41469a7b992c1e3db2a39854219cc7442e48f
Author: Josh Poimboeuf
AuthorDate: Wed, 28 Jun 2017 10:11:07 -0500
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 10:19:19 +0200
objtool: Implement stack
Commit-ID: 236222d39347e0e486010f10c1493e83dbbdfba8
Gitweb: http://git.kernel.org/tip/236222d39347e0e486010f10c1493e83dbbdfba8
Author: Paolo Abeni
AuthorDate: Thu, 29 Jun 2017 15:55:58 +0200
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 09:52:51 +0200
x86/uaccess: Optimize copy_u
Commit-ID: 8781fb7e9749da424e01daacd14834b674658c63
Gitweb: http://git.kernel.org/tip/8781fb7e9749da424e01daacd14834b674658c63
Author: Andy Lutomirski
AuthorDate: Thu, 29 Jun 2017 08:53:14 -0700
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 10:12:35 +0200
x86/mm: Delete a big out
Hello, Peter.
On Tue, Jun 27, 2017 at 09:01:43AM +0200, Peter Zijlstra wrote:
>
> I'm slowly getting back to things...
Welcome back.
> On Mon, Jun 12, 2017 at 05:27:53PM -0400, Tejun Heo wrote:
> > That's where the "join" thing comes from because we wanna be able to
> > tell apart whether a cgr
On Fri, Jun 30, 2017 at 10:32:03AM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > This is a major rewrite of objtool. Instead of only tracking frame
> > pointer changes, it now tracks all stack-related operations, including
> > all register saves/restores.
> >
> > In addition to m
On Fri, Jun 30, 2017 at 11:06:46AM +0800, Chen Yu wrote:
> Hi Bjorn,
> On Thu, Jun 29, 2017 at 09:39:31PM -0500, Bjorn Helgaas wrote:
> > On Thu, Jun 29, 2017 at 02:19:26PM -0500, Bjorn Helgaas wrote:
> > > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote:
> > > > People reported that they c
On Wed 28-06-17 16:26:33, Linus Torvalds wrote:
[...]
> In fact, I'd even be quite open to adding a kernel warning about badly
> behaved binaries that grow their stack by a big amount in one go. Not
> only is it bad taste (and we really should encourage compilers to do
> probing every page when gro
On Fri, Jun 30, 2017 at 08:23:36AM -0500, Josh Poimboeuf wrote:
> On Fri, Jun 30, 2017 at 10:32:03AM +0200, Ingo Molnar wrote:
> >
> > * Josh Poimboeuf wrote:
> >
> > > This is a major rewrite of objtool. Instead of only tracking frame
> > > pointer changes, it now tracks all stack-related oper
201 - 300 of 763 matches
Mail list logo
