From: Petr Štetiar Sent: Tuesday, May 7, 2019 5:25 AM
> There was NVMEM support added to of_get_mac_address, so it could now
> return ERR_PTR encoded error values, so we need to adjust all current users
> of of_get_mac_address to this new fact.
>
> While at it, remove superfluous is_valid_ether_a
The pull request you sent on Tue, 7 May 2019 19:58:53 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> tags/staging-5.2-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e0dccbdf5ac7ccb9da5612100dedba302f3ebcfe
Thank you!
--
Deet-doot-do
On 05/06, Ardelean, Alexandru wrote:
> On Sat, 2019-05-04 at 13:43 +0300, Alexandru Ardelean wrote:
> > [External]
> >
> >
> > On Sat, May 4, 2019 at 1:25 AM Melissa Wen wrote:
> > >
> > > Use the bitfield macro FIELD_GET, and GENMASK to do the shift and mask
> > > in
> > > one go. This makes t
On 05/05, Jonathan Cameron wrote:
> On Sat, 4 May 2019 14:12:22 +0300
> Alexandru Ardelean wrote:
>
> > On Sat, May 4, 2019 at 1:24 AM Melissa Wen wrote:
> > >
> > > This patchset solves readability issues in AD7150 code, such as clarify
> > > register and mask definition, fashion improvement of
On Tue, May 7, 2019 at 10:59 AM Greg KH wrote:
>
> All of these have been in linux-next for a while with no reported
> issues, other than an odd gcc warning for one of the new drivers that
> should be fixed up soon.
Ok, that's truly a funky warning.
But since I don't deal well with warnings, par
From: Sultan Alsawaf
Date: Tue, May 7, 2019 at 9:53 AM
To: Suren Baghdasaryan
Cc: Christian Brauner, Greg Kroah-Hartman, open list:ANDROID DRIVERS,
Daniel Colascione, Todd Kjos, Kees Cook, Peter Zijlstra, Martijn
Coenen, LKML, Tim Murray, Michal Hocko, linux-mm, Arve Hjønnevåg, Ingo
Molnar, Steven
From: Petr Štetiar
Date: Mon, 6 May 2019 23:24:43 +0200
> this patch series is an attempt to fix the mess, I've somehow managed to
> introduce.
>
> First patch in this series is defacto v5 of the previous 05/10 patch in the
> series, but since the v4 of this 05/10 patch wasn't picked up by the
On Tue, May 07, 2019 at 09:28:47AM -0700, Suren Baghdasaryan wrote:
> From: Christian Brauner
> Date: Tue, May 7, 2019 at 3:58 AM
> To: Sultan Alsawaf
> Cc: Greg Kroah-Hartman, open list:ANDROID DRIVERS, Daniel Colascione,
> Todd Kjos, Kees Cook, Peter Zijlstra, Martijn Coenen, LKML, Tim
> Murray,
The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb:
Linux 5.1-rc6 (2019-04-21 10:45:57 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-5.2-rc1
for you to fetch changes up to e2a5be107f52ce
On Tue, May 07, 2019 at 07:58:53PM +0200, Greg KH wrote:
> The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb:
>
> Linux 5.1-rc6 (2019-04-21 10:45:57 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.g
On Tue, May 07, 2019 at 10:17:11AM -0700, Sultan Alsawaf wrote:
> On Tue, May 07, 2019 at 01:09:21PM +0200, Greg Kroah-Hartman wrote:
> > > It's even more odd that although a userspace solution is touted as the
> > > proper
> > > way to go on LKML, almost no Android OEMs are using it, and even in
On Tue, May 07, 2019 at 12:58:27PM +0200, Christian Brauner wrote:
> This is work that is ongoing and requires kernel changes to make it
> feasible. One of the things that I have been working on for quite a
> while is the whole file descriptor for processes thing that is important
> for LMKD (Even
On Tue, May 07, 2019 at 09:28:47AM -0700, Suren Baghdasaryan wrote:
> Hi Sultan,
> Looks like you are posting this patch for devices that do not use
> userspace LMKD solution due to them using older kernels or due to
> their vendors sticking to in-kernel solution. If so, I see couple
> logistical i
On Tue, May 07, 2019 at 09:28:47AM -0700, Suren Baghdasaryan wrote:
> From: Christian Brauner
> Date: Tue, May 7, 2019 at 3:58 AM
> To: Sultan Alsawaf
> Cc: Greg Kroah-Hartman, open list:ANDROID DRIVERS, Daniel Colascione,
> Todd Kjos, Kees Cook, Peter Zijlstra, Martijn Coenen, LKML, Tim
> Murray,
On Tue, May 07, 2019 at 05:31:54PM +0200, Oleg Nesterov wrote:
> I am not going to comment the intent, but to be honest I am skeptical too.
The general sentiment has been that this is a really bad idea, but I'm just a
frustrated Android user who wants his phone to not require mountains of zRAM
onl
From: Christian Brauner
Date: Tue, May 7, 2019 at 3:58 AM
To: Sultan Alsawaf
Cc: Greg Kroah-Hartman, open list:ANDROID DRIVERS, Daniel Colascione,
Todd Kjos, Kees Cook, Peter Zijlstra, Martijn Coenen, LKML, Tim
Murray, Michal Hocko, Suren Baghdasaryan, linux-mm, Arve Hjønnevåg,
Ingo Molnar, Steven
Remove braces from single if statement to solve style issue found using
checkpatch,pl
Signed-off-by: Puranjay Mohan
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/stagi
I am not going to comment the intent, but to be honest I am skeptical too.
On 05/06, Sultan Alsawaf wrote:
>
> +static unsigned long find_victims(struct victim_info *varr, int *vindex,
> + int vmaxlen, int min_adj, int max_adj)
> +{
> + unsigned long pages_found =
On Tue, 7 May 2019 at 00:26, Petr Štetiar wrote:
>
> There was NVMEM support added to of_get_mac_address, so it could now
> return ERR_PTR encoded error values, so we need to adjust all current
> users of of_get_mac_address to this new fact.
>
> While at it, remove superfluous is_valid_ether_addr
From: Dexuan Cui Sent: Tuesday, May 7, 2019 12:47 AM
>
> In the case of X86_PAE, unsigned long is u32, but the physical address type
> should be u64. Due to the bug here, the netvsc driver can not load
> successfully, and sometimes the VM can panic due to memory corruption (the
> hypervisor write
On Mon 06-05-19 19:16:22, Sultan Alsawaf wrote:
> This is a complete low memory killer solution for Android that is small
> and simple. Processes are killed according to the priorities that
> Android gives them, so that the least important processes are always
> killed first. Processes are killed u
On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote:
> On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote:
> > Given that any "new" android device that gets shipped "soon" should be
> > using 4.9.y or newer, is this a real issue?
>
> It's certainly a real issue for those
On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote:
> On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote:
> > Given that any "new" android device that gets shipped "soon" should be
> > using 4.9.y or newer, is this a real issue?
>
> It's certainly a real issue for those
Oh crap. You did add a Fixes tag. My bad.
I should have been more clear/pro-active on Friday and we could have
avoided this... Next time.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.o
Hi Petr,
On Mon, May 6, 2019 at 11:25 PM Petr Štetiar wrote:
> this patch series is an attempt to fix the mess, I've somehow managed to
> introduce.
>
> First patch in this series is defacto v5 of the previous 05/10 patch in the
> series, but since the v4 of this 05/10 patch wasn't picked up by t
Petr Štetiar [2019-05-07 10:39:18]:
[adding Jeremy to the Cc: loop]
> it was applied[2] to David's net-next tree, but unfortunately partialy, just 9
> patches out of 10, as the patch 05/10 in that series (which is patch 1/4 in
> this series) never reached netdev mailing list and patchwork, proba
Dan Carpenter [2019-05-07 10:19:14]:
Hi,
> On Mon, May 06, 2019 at 11:24:43PM +0200, Petr Štetiar wrote:
> >
> > this patch series is an attempt to fix the mess, I've somehow managed to
> > introduce.
> >
> > First patch in this series is defacto v5 of the previous 05/10 patch in the
> > serie
On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote:
> Given that any "new" android device that gets shipped "soon" should be
> using 4.9.y or newer, is this a real issue?
It's certainly a real issue for those who can't buy brand new Android devices
without software bugs every six m
In the case of X86_PAE, unsigned long is u32, but the physical address type
should be u64. Due to the bug here, the netvsc driver can not load
successfully, and sometimes the VM can panic due to memory corruption (the
hypervisor writes data to the wrong location).
Fixes: 6ba34171bcbd ("Drivers: hv
On Tue, May 07, 2019 at 10:19:14AM +0300, Dan Carpenter wrote:
> On Mon, May 06, 2019 at 11:24:43PM +0200, Petr Štetiar wrote:
> > Hi,
> >
> > this patch series is an attempt to fix the mess, I've somehow managed to
> > introduce.
> >
> > First patch in this series is defacto v5 of the previous 0
On Tue, May 07, 2019 at 12:27:21AM -0700, Sultan Alsawaf wrote:
> On Tue, May 07, 2019 at 09:04:30AM +0200, Greg Kroah-Hartman wrote:
> > Um, why can't "all" Android devices take the same patches that the Pixel
> > phones are using today? They should all be in the public android-common
> > kernel
On Tue, May 07, 2019 at 09:04:30AM +0200, Greg Kroah-Hartman wrote:
> Um, why can't "all" Android devices take the same patches that the Pixel
> phones are using today? They should all be in the public android-common
> kernel repositories that all Android devices should be syncing with on a
> week
On Mon, May 06, 2019 at 11:24:43PM +0200, Petr Štetiar wrote:
> Hi,
>
> this patch series is an attempt to fix the mess, I've somehow managed to
> introduce.
>
> First patch in this series is defacto v5 of the previous 05/10 patch in the
> series, but since the v4 of this 05/10 patch wasn't picke
On Mon, May 06, 2019 at 07:16:22PM -0700, Sultan Alsawaf wrote:
> This is a complete low memory killer solution for Android that is small
> and simple. Processes are killed according to the priorities that
> Android gives them, so that the least important processes are always
> killed first. Proces
34 matches
Mail list logo
