From: Yue Haibing
Remove including that don't need it.
Signed-off-by: Yue Haibing
---
drivers/staging/gasket/gasket_interrupt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/gasket/gasket_interrupt.c
b/drivers/staging/gasket/gasket_interrupt.c
index 1cfbc12..176ac2a 1006
On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
> > And who is going to decide which ones to pass? And who documents
> > which ones are safe?
> >
> > I'd much rather have explicit, well documented dma-buf flags that
> > might get translated to the DMA API flags, which are not error
Looks good,
Reviewed-by: Christoph Hellwig
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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.
/* Changelog */
Not
The comment stems from an early version of that patchset and is just
confusing now.
Cc: Al Viro
Signed-off-by: Christian Brauner
---
/* Changelog */
v1:
- patch unchanged
---
drivers/android/binderfs.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/android/binderfs.c b/drivers/
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 erro
In a previous commit we switched from a d_alloc_name() + d_lookup()
combination to setup a new dentry and find potential duplicates to the more
idiomatic lookup_one_len(). As far as I understand, this also means we need
to switch from d_add() to d_instantiate() since lookup_one_len() will
create a
- make binderfs control dentry immutable:
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.
- add is_binderfs_control_device
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 fs/devptfs/inode.c:mknod_
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
---
/* Changelog */
- switch from d_alloc_name() + d_lookup() to lookup_one_len():
Instead of using d_alloc_name() and then doing a d_lookup() with the
allocated dentry to find whether a device with the name we're trying to
create already exists switch to using lookup_one_len(). The latter will
either return
We allow more then 255 binderfs binder devices to be created since there
are workloads that require more than that. If we use __u8 we'll overflow
after 255. So let's use a __u32.
Note that there's no released kernel with binderfs out there so this is
not a regression.
Signed-off-by: Christian Brau
When we switched over from binder_ctl.h to binderfs.h we forgot to change
the include guards. It's minor but it's obviously correct.
Signed-off-by: Christian Brauner
---
include/uapi/linux/android/binderfs.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/l
Hi,
On Fri, 2019-01-18 at 17:04 -0800, Steve Longerbeam wrote:
> 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 imme
Hi,
Sorry for being a bit sporadic on this. I was out travelling last week
with little time for email.
On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:
> 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 wr
On Friday, January 18, 2019 5:04:50 PM CET Peter Zijlstra wrote:
> 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_free
Hi Liam,
On Fri, Jan 18, 2019 at 10:37:47AM -0800, 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.
>
> For example this will allow ION clients to skip cache maintenance, by
> u
On Thu, Jan 17, 2019 at 01:21:10PM +, ajay.kat...@microchip.com wrote:
> From: Ajay Singh
>
> Make use of get_unaligned_le16/le32 framework api's to pack data.
>
> Signed-off-by: Ajay Singh
> ---
> drivers/staging/wilc1000/host_interface.c | 15 +++
> drivers/staging/wilc1000/w
On Fri, Jan 18, 2019 at 02:17:16AM +0530, Ajay Kaher wrote:
> hv_do_hypercall() assumes that we pass a segment from a physically
> contiguous buffer. A buffer allocated on the stack may not work if
> CONFIG_VMAP_STACK=y is set.
>
> Use kmalloc() to allocate this buffer.
>
Since you're going to
On Mon, Jan 21, 2019 at 04:19:42PM +0300, Dan Carpenter wrote:
> On Fri, Jan 18, 2019 at 02:17:16AM +0530, Ajay Kaher wrote:
> > hv_do_hypercall() assumes that we pass a segment from a physically
> > contiguous buffer. A buffer allocated on the stack may not work if
> > CONFIG_VMAP_STACK=y is set.
On 1/18/19 1:53 PM, Laura Abbott wrote:
> 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 b
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: 94081c6f77f3899ac96ae7baa8c7bf13ccc1dfd2
commit: 633d249a0993958bc7f19599639256e46410b305 [115/119] ceph: fix changelog
config: x86_64-randconfig-a0-01211725 (attached as .config)
compiler: gcc-8
On 1/18/19 2:19 PM, Laura Abbott wrote:
> 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,
>>
>>>
On 1/18/19 3:43 PM, Liam Mark wrote:
> 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
Philipp,
On Mon, Jan 21, 2019 at 12:49:10PM +0100, Philipp Zabel wrote:
> Hi,
>
> On Fri, 2019-01-18 at 17:04 -0800, Steve Longerbeam wrote:
> > Disable the SMFC before disabling the IDMA channel, instead of after,
> > in csi_idmac_unsetup().
> >
> > This fixes a complete system hard lockup on t
On Thu, Jan 17, 2019 at 09:11:03AM -0800, Stephen Hemminger wrote:
>
>
> > +static ssize_t channel_intr_in_full_show(const struct vmbus_channel
> > *channel,
> > +char *buf)
> > +{
> > + return sprintf(buf, "%llu\n", channel->intr_in_full);
> > +}
>
>
> int
On Sat, 2019-01-19 at 13:45 -0800, Steve Longerbeam wrote:
> On i.MX6, the nearest upstream entity to the CSI can only be the
> CSI video muxes or the Synopsys DW MIPI CSI-2 receiver.
>
> However the i.MX53 has no CSI video muxes or a MIPI CSI-2 receiver.
> So allow for the nearest upstream entity
On Sat, 2019-01-19 at 13:45 -0800, Steve Longerbeam wrote:
> For the functions that add and remove the internal IPU subdevice
> descriptors and links between them, rename them to make clear they
> are the subdevs and links internal to the IPU. Also rename the
> platform data structure for the inter
On Sat, 2019-01-19 at 13:46 -0800, Steve Longerbeam wrote:
> The second IPU internal sub-devices were being registered and links
> to them created even when the second IPU is not present. This is wrong
> for i.MX6 S/DL and i.MX53 which have only a single IPU.
>
> Fixes: e130291212df5 ("[media] med
On 1/21/19 1:53 AM, YueHaibing wrote:
There is no need to have the 'intrepeat_times' variable static since new
value always be assigned before use it.
Signed-off-by: YueHaibing
---
drivers/staging/rtl8712/rtl8712_efuse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
On 1/21/19 3:49 AM, Philipp Zabel wrote:
Hi,
On Fri, 2019-01-18 at 17:04 -0800, Steve Longerbeam wrote:
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
On 1/21/19 10:43 AM, Steve Longerbeam wrote:
On 1/21/19 3:49 AM, Philipp Zabel wrote:
Also ipu_smfc_disable is refcounted, so if the other CSI is capturing
simultaneously, this change has no effect.
Sigh, you're right. Let me go back to disabling the CSI before the
channel, the CSI enabl
Hello
I want to seek for your assistance and partnership to invest in your country. I
have € 7.5M (Seven million five hundred thousand Euros) that I want to invest
in your country and I am willing to offer you 20% of the money for your
assistance in this project.
If you are interested, kindl
Hello
I want to seek for your assistance and partnership to invest in your country. I
have € 7.5M (Seven million five hundred thousand Euros) that I want to invest
in your country and I am willing to offer you 20% of the money for your
assistance in this project.
If you are interested, kindl
Hello
I want to seek for your assistance and partnership to invest in your country. I
have € 7.5M (Seven million five hundred thousand Euros) that I want to invest
in your country and I am willing to offer you 20% of the money for your
assistance in this project.
If you are interested, kindl
On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
> > > And who is going to decide which ones to pass? And who documents
> > > which ones are safe?
> > >
> > > I'd much rather have explicit, well documented dma-buf flags that
> > > migh
On 1/21/19 1:44 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>
>> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
And who is going to decide which ones to pass? And who documents
which ones are safe?
I'd much rather have explicit, well doc
On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> On 1/18/19 3:43 PM, Liam Mark wrote:
> > 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 J
On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> 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 Mon, 21 Jan 2019, Andrew F. Davis wrote:
> On 1/21/19 1:44 PM, Liam Mark wrote:
> > On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> >
> >> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
> And who is going to decide which ones to pass? And who documents
> which ones ar
On 1/21/19 2:20 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/21/19 1:44 PM, Liam Mark wrote:
>>> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>>>
On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
>> And who is going to decide which ones to pass
On 1/21/19 5:22 AM, Brian Starkey wrote:
> Hi,
>
> Sorry for being a bit sporadic on this. I was out travelling last week
> with little time for email.
>
> On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:
>> On 1/17/19 7:11 PM, Liam Mark wrote:
>>> On Thu, 17 Jan 2019, Andrew F. D
On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote:
> The main use case is for allowing clients to pass in
> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance
> which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In
> ION the buffers aren't usually ac
On Mon, Jan 21, 2019 at 12:20:42PM -0800, Liam Mark wrote:
> I have left this to clients, but if they own the buffer they can have the
> knowledge as to whether CPU access is needed in that use case (example for
> post-processing).
That is an API design which the user is more likely to get wrong
On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote:
> > The main use case is for allowing clients to pass in
> > DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance
> > which happens in dma_buf_map_attachment and dma_buf_un
On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> On Mon, Jan 21, 2019 at 12:20:42PM -0800, Liam Mark wrote:
> > I have left this to clients, but if they own the buffer they can have the
> > knowledge as to whether CPU access is needed in that use case (example for
> > post-processing).
>
> That
On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> On 1/21/19 2:20 PM, Liam Mark wrote:
> > On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/21/19 1:44 PM, Liam Mark wrote:
> >>> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> >>>
> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott
Move upstream stream off to just after receiving the last EOF completion
and disabling the CSI (and thus before disabling the IDMA channel) in
csi_stop(). For symmetry also move upstream stream on to beginning of
csi_start().
Doing this makes csi_s_stream() more symmetric with prp_s_stream() which
Disable the CSI immediately after receiving the last EOF before stream
off (and thus before disabling the IDMA channel). Do this by moving the
wait for EOF completion into a new function csi_idmac_wait_last_eof().
This fixes a complete system hard lockup on the SabreAuto when streaming
from the AD
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 fixes
On 1/21/19 8:50 AM, Philipp Zabel wrote:
On Sat, 2019-01-19 at 13:45 -0800, Steve Longerbeam wrote:
On i.MX6, the nearest upstream entity to the CSI can only be the
CSI video muxes or the Synopsys DW MIPI CSI-2 receiver.
However the i.MX53 has no CSI video muxes or a MIPI CSI-2 receiver.
So
The channel level "_show" functions are vulnerable to race conditions.
Add a mutex lock and unlock around the call to the channel level "_show"
functions in vmbus_chan_attr_show().
This problem was discussed here: https://lkml.org/lkml/2018/10/18/830
Signed-off-by: Kimberly Brown
---
drivers/hv
> From: Kimberly Brown
> Sent: Monday, January 21, 2019 6:08 PM
> Subject: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions
>
> The channel level "_show" functions are vulnerable to race conditions.
> Add a mutex lock and unlock around the call to the channel level "_show"
> f
On Tue, Jan 22, 2019 at 03:46:48AM +, Dexuan Cui wrote:
> > From: Kimberly Brown
> > Sent: Monday, January 21, 2019 6:08 PM
> > Subject: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show
> > functions
> >
> > The channel level "_show" functions are vulnerable to race conditions.
> >
54 matches
Mail list logo
