On Thu, Mar 14, 2019 at 12:15 PM Kangjie Lu wrote:
>
> ida_simple_get could fail. The fix inserts a check for its
> return value.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/staging/greybus/audio_manager.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git
On Thu, 2019-03-14 at 15:07 +0100, Jean Delvare wrote:
> My principle is that if a script
> is present in the kernel tree then it can and should be maintained. If
> it is deemed not worth the maintenance effort then it should be
> deleted.
I've suggested deleting Lindent in the past.
On Thu, Mar 14, 2019 at 11:16:41PM -0400, Steven Rostedt wrote:
> How would you implement such a method in userspace? kill() doesn't take
> any parameters but the pid of the process you want to send a signal to,
> and the signal to send. This would require a new system call, and be
> quite a bit
On Thu, Mar 14, 2019 at 10:54:48PM -0400, Joel Fernandes wrote:
> I'm not sure if that makes much semantic sense for how the signal handling is
> supposed to work. Imagine a parent sends SIGKILL to its child, and then does
> a wait(2). Because the SIGKILL blocks in your idea, then the wait cannot
On Thu, 14 Mar 2019 13:49:11 -0700
Sultan Alsawaf wrote:
> Perhaps I'm missing something, but if you want to know when a process has died
> after sending a SIGKILL to it, then why not just make the SIGKILL optionally
> block until the process has died completely? It'd be rather trivial to just
>
On Thu, Mar 14, 2019 at 01:49:11PM -0700, Sultan Alsawaf wrote:
> On Thu, Mar 14, 2019 at 10:47:17AM -0700, Joel Fernandes wrote:
> > About the 100ms latency, I wonder whether it is that high because of
> > the way Android's lmkd is observing that a process has died. There is
> > a gap between
Hi All,
I would like to explain more for the purpose of this patch. During our
daily test on android system, we found that there is always showing
the memory fragmentation after some test cases(etc camera snapshot),
which lead to huge amount of order0 pages which other page blocks
remain none(200M
On Thu, Mar 14, 2019 at 10:47:17AM -0700, Joel Fernandes wrote:
> About the 100ms latency, I wonder whether it is that high because of
> the way Android's lmkd is observing that a process has died. There is
> a gap between when a process memory is freed and when it disappears
> from the
Hi Tim,
Thanks for the detailed and excellent write-up. It will serve as a
good future reference for low memory killer requirements. I made some
comments below on the "how to kill" part.
On Tue, Mar 12, 2019 at 10:17 AM Tim Murray wrote:
>
> On Tue, Mar 12, 2019 at 9:37 AM Sultan Alsawaf wrote:
On 14/03/2019 14:24, Stefan Roese wrote:
> On 14.03.19 14:14, Matthias Brugger wrote:
>>
>>
>> On 14/03/2019 12:37, Armando Miraglia wrote:
>>> Absolutely!
>>
>> Please don't top post :)
>>
>>>
>>> Cheers,
>>> A.
>>>
>>> On Thu, Mar 14, 2019 at 12:36 PM Stefan Roese wrote:
>> [...]
Signed-off-by: David Howells
Reviewed-by: Christian Brauner
cc: Greg Kroah-Hartman
cc: "Arve Hjønnevåg"
cc: Todd Kjos
cc: Martijn Coenen
cc: Joel Fernandes
cc: de...@driverdev.osuosl.org
---
drivers/android/binderfs.c | 173
1 file changed, 96
Hi,
On 14-03-19 16:21, Sidong Yang wrote:
In function vbox_dumb_create() of vbox_main.c, It calls vbox_gem_create()
for creating drm_gem_object. and it calls vbox_gem_handle_create() for handle.
If handle creation fails only, drm_gem_object should be released by calling
In function vbox_dumb_create() of vbox_main.c, It calls vbox_gem_create()
for creating drm_gem_object. and it calls vbox_gem_handle_create() for handle.
If handle creation fails only, drm_gem_object should be released by calling
drm_gem_object_put_unlocked().
Signed-off-by: Sidong Yang
---
Hi Dan,
On Thu, 14 Mar 2019 14:27:32 +0300, Dan Carpenter wrote:
> On Thu, Mar 14, 2019 at 12:13:15PM +0100, Armando Miraglia wrote:
> > Is there an explicit intent to deprecate Lindent in favor of checkpatch.pl
> > --fix? If one would like to contribute to fixing the tooling for linting
> >
On 14.03.19 14:14, Matthias Brugger wrote:
On 14/03/2019 12:37, Armando Miraglia wrote:
Absolutely!
Please don't top post :)
Cheers,
A.
On Thu, Mar 14, 2019 at 12:36 PM Stefan Roese wrote:
[...]
Would it be possible for you to wait a bit with this minor cleanup?
As I'm preparing a
This series adds support for the PCIe PHY found in the Mediatek
MT7621 SoC.
This is the first attempt to get feedback of what is missing in
this driver to be promoted from staging.
There is also a 'mt7621-pci' driver which is the controller part
which is still in staging and is a client of this
This patch adds a driver for the PCIe PHY of MT7621 SoC.
Signed-off-by: Sergio Paracuellos
---
drivers/phy/ralink/Kconfig | 7 +
drivers/phy/ralink/Makefile | 1 +
drivers/phy/ralink/phy-mt7621-pci.c | 387
3 files changed, 395 insertions(+)
Add bindings to describe Mediatek MT7621 PCIe PHY.
Signed-off-by: Sergio Paracuellos
---
.../bindings/phy/mediatek,mt7621-pci-phy.txt | 54 +++
1 file changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.txt
diff --git
On 14/03/2019 12:37, Armando Miraglia wrote:
> Absolutely!
Please don't top post :)
>
> Cheers,
> A.
>
> On Thu, Mar 14, 2019 at 12:36 PM Stefan Roese wrote:
[...]
>>
>> Would it be possible for you to wait a bit with this minor cleanup?
>> As I'm preparing a patch to move this driver out
This patch moves the MT7621 SPI driver, which is used on some Ralink /
MediaTek MT76xx MIPS SoC's, out of the staging directory. No changes to
the source code are done in this patch.
This driver version was tested successfully on an MT7688 based platform
with an SPI NOR on CS0 and an SPI NAND on
Absolutely!
Cheers,
A.
On Thu, Mar 14, 2019 at 12:36 PM Stefan Roese wrote:
>
> Hi Armando,
>
> On 14.03.19 12:13, Armando Miraglia wrote:
> > My answers are in-line below. BTW bare with me as this is my attempt to get
> > my
> > feet wet in how to contribute to the linux kernel for my own
Hi Armando,
On 14.03.19 12:13, Armando Miraglia wrote:
My answers are in-line below. BTW bare with me as this is my attempt to get my
feet wet in how to contribute to the linux kernel for my own pleasure and
interest :)
On Wed, Mar 13, 2019 at 03:34:54PM +0300, Dan Carpenter wrote:
On Wed,
On Thu, Mar 14, 2019 at 12:13:15PM +0100, Armando Miraglia wrote:
> My answers are in-line below. BTW bare with me as this is my attempt to get my
> feet wet in how to contribute to the linux kernel for my own pleasure and
> interest :)
>
No problem at all.
> Is there an explicit intent to
My answers are in-line below. BTW bare with me as this is my attempt to get my
feet wet in how to contribute to the linux kernel for my own pleasure and
interest :)
On Wed, Mar 13, 2019 at 03:34:54PM +0300, Dan Carpenter wrote:
> On Wed, Mar 13, 2019 at 01:24:04PM +0100, Armando Miraglia wrote:
>
From: Zhaoyang Huang
Two action for this patch:
1. set a batch size for system heap's shrinker, which can have it buffer
reasonable page blocks in pool for future allocation.
2. reverse the order sequence when free page blocks, the purpose is also
to have system heap keep as more big blocks as
Hi Arnd,
Thanks for the patch.
On Wed 13 Mar 2019 at 21:17, Arnd Bergmann wrote:
When CONFIG_DEBUGFS is enabled, we get a warning about an
incorrect section annotation that can lead to undefined
behavior:
WARNING: vmlinux.o(.text+0xd3c7c4): Section mismatch in
reference from the function
On 14-03-19, 01:45, Kangjie Lu wrote:
> ida_simple_get could fail. The fix inserts a check for its
> return value.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/staging/greybus/audio_manager.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/greybus/audio_manager.c
A trivial patch.
cpu_to_le16() is capable enough to detect __builtin_constant_p()
and to use an appropriate compile time ___constant_swahbXX()
function.
So we can use cpu_to_le16() instead of __constant_cpu_to_le16().
Signed-off-by: Sergey Senozhatsky
---
ida_simple_get could fail. The fix inserts a check for its
return value.
Signed-off-by: Kangjie Lu
---
drivers/staging/greybus/audio_manager.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/greybus/audio_manager.c
b/drivers/staging/greybus/audio_manager.c
index
29 matches
Mail list logo
