On Fri, Jan 18, 2019 at 06:08:01PM +0100, Hugo Lefeuvre wrote:
[...]
> > > +/*
> > > + * like wait_event_hrtimeout() -- except it uses TASK_INTERRUPTIBLE to
> > > avoid
> > > + * increasing load and is freezable.
> > > + */
> > > +#define wait_event_freezable_hrtimeout(wq_head, condition,
From: Haiyang Zhang Sent: Monday, January 14, 2019
4:52 PM
>
> Changing mtu, channels, or buffer sizes ops call to netvsc_attach(),
> rndis_set_subchannel(), which always reset the hash key to default
> value. That will override hash key changed previously. This patch
> fixes the problem by
From: Haiyang Zhang Sent: Monday, January 14, 2019
4:52 PM
>
> These assignments occur in multiple places. The patch refactor them
> to a function for simplicity. It also puts the struct to heap area
> for future expension.
>
> Signed-off-by: Haiyang Zhang
> ---
>
From: Haiyang Zhang Sent: Monday, January 14, 2019
4:52 PM
>
> Hyper-V hosts require us to disable RSS before changing RSS key,
> otherwise the changing request will fail. This patch fixes the
> coding error.
>
> Fixes: ff4a44199012 ("netvsc: allow get/set of RSS indirection table")
>
Disable the SMFC before disabling the IDMA channel, instead of after,
in csi_idmac_unsetup().
This fixes a complete system hard lockup on the SabreAuto when streaming
from the ADV7180, by repeatedly sending a stream off immediately followed
by stream on:
while true; do v4l2-ctl -d4
Upstream must be stopped immediately after receiving the last EOF and
before disabling the IDMA channel. This can be accomplished by moving
upstream stream off to just after receiving the last EOF completion in
prp_stop(). For symmetry also move upstream stream on to end of
prp_start().
This
On 1/18/19 11:01 AM, Steve Longerbeam wrote:
On 1/18/19 2:24 AM, Philipp Zabel wrote:
On Thu, 2019-01-17 at 12:49 -0800, Steve Longerbeam wrote:
Disable the CSI immediately after receiving the last EOF before stream
off (and thus before disabling the IDMA channel).
This fixes a complete
On Fri, Jan 18, 2019 at 03:53:39PM +0100, Christian Brauner wrote:
> Hey everyone,
>
> Al gave me a really helpful review of binderfs and pointed out a range
> of bugs. The most obvious and serious ones have fortunately already been
> taken care of by patches sitting in Greg's char-misc-linus
On Fri, Jan 18, 2019 at 03:53:42PM +0100, Christian Brauner wrote:
> static int binderfs_fill_super(struct super_block *sb, void *data, int
> silent)
> {
> + int ret;
> struct binderfs_info *info;
> - int ret = -ENOMEM;
> struct inode *inode = NULL;
> struct
On Fri, Jan 18, 2019 at 03:53:41PM +0100, Christian Brauner wrote:
> We don't allow to unlink it since it is crucial for binderfs to be useable
> but if we allow to rename it we make the unlink trivial to bypass. So
> prevent renaming too and simply treat the control dentry as immutable.
>
> Take
On 1/18/19 1:32 PM, Liam Mark wrote:
On Fri, 18 Jan 2019, Laura Abbott wrote:
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
---
On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> On 1/17/19 7:04 PM, Liam Mark wrote:
> > On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/16/19 4:48 PM, Liam Mark wrote:
> >>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> >>>
> On 1/15/19 1:05 PM, Laura Abbott wrote:
> > On
On Fri, 18 Jan 2019, Laura Abbott wrote:
> On 1/18/19 10:37 AM, Liam Mark wrote:
> > Add support for configuring dma mapping attributes when mapping
> > and unmapping memory through dma_buf_map_attachment and
> > dma_buf_unmap_attachment.
> >
> > Signed-off-by: Liam Mark
> > ---
> >
On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> On 1/18/19 12:37 PM, Liam Mark wrote:
> > The ION begin_cpu_access and end_cpu_access functions use the
> > dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
> > maintenance.
> >
> > Currently it is possible to apply cache
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
---
include/linux/dma-buf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 1/18/19 12:43 PM, Andrew F. Davis wrote:
On 1/18/19 2:31 PM, Laura Abbott wrote:
On 1/17/19 8:13 AM, Andrew F. Davis wrote:
On 1/16/19 4:48 PM, Liam Mark wrote:
On Wed, 16 Jan 2019, Andrew F. Davis wrote:
On 1/15/19 1:05 PM, Laura Abbott wrote:
On 1/15/19 10:38 AM, Andrew F. Davis
On 1/18/19 2:31 PM, Laura Abbott wrote:
> On 1/17/19 8:13 AM, Andrew F. Davis wrote:
>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
On 1/15/19 1:05 PM, Laura Abbott wrote:
> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
>> On 1/15/19 11:45
On 1/18/19 10:37 AM, Liam Mark wrote:
Often userspace doesn't know when the kernel will be calling dma_buf_detach
on the buffer.
If userpace starts its CPU access at the same time as the sg list is being
freed it could end up accessing the sg list after it has been freed.
Thread A
On 1/17/19 8:13 AM, Andrew F. Davis wrote:
On 1/16/19 4:48 PM, Liam Mark wrote:
On Wed, 16 Jan 2019, Andrew F. Davis wrote:
On 1/15/19 1:05 PM, Laura Abbott wrote:
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/18/19 12:37 PM, Liam Mark wrote:
> The ION begin_cpu_access and end_cpu_access functions use the
> dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
> maintenance.
>
> Currently it is possible to apply cache maintenance, via the
> begin_cpu_access and end_cpu_access APIs,
On 1/16/19 8:05 AM, Andrew F. Davis wrote:
On 1/15/19 12:58 PM, Laura Abbott wrote:
On 1/15/19 9:47 AM, Andrew F. Davis wrote:
On 1/14/19 8:39 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
Hi,
Sorry for the (extremely) late reply.
Comments inline.
Renato
On 12/01, Jonathan Cameron wrote:
On Thu, 29 Nov 2018 11:02:46 -0200
Giuliano Augusto Faulin Belinassi wrote:
Hi
A few follow ups from me having read the result in patch 2.
Jonathan
On Thu, Nov 29, 2018 at 9:18 AM
On 1/18/19 1:59 AM, Greg Kroah-Hartman wrote:
On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
When enabled the helpers functions for creating carveout and chunk heaps
should have declarations in the ION header.
Why? No one calls these from what I can tell.
Which makes me
On 1/16/19 9:12 AM, Andrew F. Davis wrote:
On 1/16/19 9:28 AM, Brian Starkey wrote:
Hi Andrew,
On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
The heap name can be used for debugging but otherwise does not seem
to be required and no other part of the code will fail if left
On 1/18/19 12:37 PM, Liam Mark wrote:
> Often userspace doesn't know when the kernel will be calling dma_buf_detach
> on the buffer.
> If userpace starts its CPU access at the same time as the sg list is being
> freed it could end up accessing the sg list after it has been freed.
>
> Thread A
On 1/18/19 2:24 AM, Philipp Zabel wrote:
On Thu, 2019-01-17 at 12:49 -0800, Steve Longerbeam wrote:
Disable the CSI immediately after receiving the last EOF before stream
off (and thus before disabling the IDMA channel).
This fixes a complete system hard lockup on the SabreAuto when
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
For example this will allow ION clients to skip cache maintenance, by
using DMA_ATTR_SKIP_CPU_SYNC, for buffers which are clean and haven't been
The ION begin_cpu_access and end_cpu_access functions use the
dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
maintenance.
Currently it is possible to apply cache maintenance, via the
begin_cpu_access and end_cpu_access APIs, to ION buffers which are not
dma mapped.
The dma
Often userspace doesn't know when the kernel will be calling dma_buf_detach
on the buffer.
If userpace starts its CPU access at the same time as the sg list is being
freed it could end up accessing the sg list after it has been freed.
Thread AThread B
-
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
---
include/linux/dma-buf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/dma-buf.h
Some stability changes to improve ION robustness and a perf related
change to make it easier for clients to avoid unnecessary cache
maintenance, such as when buffers are clean and haven't had any CPU
access.
Liam Mark (4):
staging: android: ion: Support cpu access during dma_buf_detach
Oi Fabio,
On Fri 18 Jan 2019 at 16:49, Fabio Estevam wrote:
Hi Rui,
On Fri, Dec 7, 2018 at 10:44 AM Hans Verkuil
wrote:
I got a few checkpatch warnings about coding style:
CHECK: Alignment should match open parenthesis
#953: FILE: drivers/staging/media/imx/imx7-media-csi.c:911:
+static
On 1/17/19 7:11 PM, Liam Mark wrote:
> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 4:54 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
On 1/16/19 9:19 AM, Brian Starkey wrote:
> Hi :-)
>
> On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew
On Fri, Jan 18, 2019 at 10:19:41AM -0500, Joel Fernandes wrote:
> You should document the variable names in the header comments.
>
> Also, this new API appears to conflict with definition of 'freezable' in
> wait_event_freezable I think,
>
> wait_event_freezable - sleep or freeze until condition
Hi Joel,
Thanks for your review.
> I believe these should be 2 patches. In the first patch you introduce the
> new API, in the second one you would simplify the VSOC driver.
>
> In fact, in one part of the patch you are using wait_event_freezable which
> already exists so that's unrelated to
On 1/17/19 7:04 PM, Liam Mark wrote:
> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
On 1/15/19 1:05 PM, Laura Abbott wrote:
> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
>> On 1/15/19 11:45
Hi Rui,
On Fri, Dec 7, 2018 at 10:44 AM Hans Verkuil wrote:
> I got a few checkpatch warnings about coding style:
>
> CHECK: Alignment should match open parenthesis
> #953: FILE: drivers/staging/media/imx/imx7-media-csi.c:911:
> +static struct v4l2_mbus_framefmt *imx7_csi_get_format(struct
> On 17/01/19, 8:37 PM, "Bjorn Helgaas" wrote:
>
> > On Fri, Jan 18, 2019 at 02:17:18AM +0530, Ajay Kaher wrote:
> > Update the Hyper-V vPCI driver to use the Server-2016 version of the vPCI
> > protocol, fixing MSI creation and retargeting issues.
> >
> > Replaced hv_tmp_cpu_nr_to_vp_nr()
On 1/18/19 3:59 AM, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
>> When enabled the helpers functions for creating carveout and chunk heaps
>> should have declarations in the ION header.
>
> Why? No one calls these from what I can tell.
>
> Which
Hi Hugo,
On Thu, Jan 17, 2019 at 11:41:35PM +0100, Hugo Lefeuvre wrote:
> introduce wait_event_freezable_hrtimeout, an interruptible and freezable
> version of wait_event_hrtimeout.
>
> simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this
> newly added helper and remove
Al pointed out that first calling kill_litter_super() before cleaning up
info is more correct since destroying info doesn't depend on the state of
the dentries and inodes. That the opposite remains true is not guaranteed.
Suggested-by: Al Viro
Signed-off-by: Christian Brauner
---
The comment stems from an early version of that patchset and is just
confusing now.
Cc: Al Viro
Signed-off-by: Christian Brauner
---
drivers/android/binderfs.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index
The binderfs_binder_ctl_create() call is a no-op on subsequent calls and
the first call is done before we unlock the suberblock. Hence, there is no
need to take inode_lock() in there. Let's remove it.
Suggested-by: Al Viro
Signed-off-by: Christian Brauner
---
Note, that
Al pointed out that on binderfs_fill_super() error
deactivate_locked_super() will call binderfs_kill_super() so all of the
freeing and putting we currently do in binderfs_fill_super() is unnecessary
and buggy. Let's simply return errors and let binderfs_fill_super() take
care of cleaning up on
We don't allow to unlink it since it is crucial for binderfs to be useable
but if we allow to rename it we make the unlink trivial to bypass. So
prevent renaming too and simply treat the control dentry as immutable.
Take the opportunity and turn the check for the control dentry into a
separate
Hey everyone,
Al gave me a really helpful review of binderfs and pointed out a range
of bugs. The most obvious and serious ones have fortunately already been
taken care of by patches sitting in Greg's char-misc-linus tree. The
others are hopefully all covered in this patchset.
Thanks!
Christian
Steve, all,
On 1/17/19 3:49 PM, Steve Longerbeam wrote:
The CSI must be disabled immediately after receiving the last EOF before
stream off (and thus before disabling the IDMA channel). This can be
accomplished by moving upstream stream off to just after receiving the
last EOF completion in
Steeve, all,
On 1/17/19 3:49 PM, Steve Longerbeam wrote:
Disable the CSI immediately after receiving the last EOF before stream
off (and thus before disabling the IDMA channel).
This fixes a complete system hard lockup on the SabreAuto when streaming
from the ADV7180, by repeatedly sending a
On Thu, 2019-01-17 at 12:49 -0800, Steve Longerbeam wrote:
> Disable the CSI immediately after receiving the last EOF before stream
> off (and thus before disabling the IDMA channel).
>
> This fixes a complete system hard lockup on the SabreAuto when streaming
> from the ADV7180, by repeatedly
On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
> When enabled the helpers functions for creating carveout and chunk heaps
> should have declarations in the ION header.
Why? No one calls these from what I can tell.
Which makes me believe we should just delete the
On Fri, Jan 11, 2019 at 12:05:09PM -0600, Andrew F. Davis wrote:
> Hello all,
>
> This is a set of (hopefully) non-controversial cleanups for the ION
> framework and current set of heaps. These were found as I start to
> familiarize myself with the framework to help in whatever way I
> can in
On Thu, Jan 17, 2019 at 01:21:06PM +, ajay.kat...@microchip.com wrote:
> From: Ajay Singh
>
> This series contains changes to address few of the review comments[1].
> It mainly has the modification to remove the use of scan shadow
> buffer, make use of kernel provided API, avoid typedef's
52 matches
Mail list logo
