> -Original Message-
> From: Horia Geantă
> Sent: Tuesday, February 06, 2018 9:18 AM
> To: Bogdan Purcareata ; gre...@linuxfoundation.org;
> Laurentiu Tudor ; Ruxandra Ioana Ciocoi Radulescu
>
> Cc: stuyo...@gmail.com; a...@arndb.de; r...@kernel.org; Razvan Stefanescu
> ; Ioana Ciornei ; N
On Tue, 2018-02-06 at 01:08 +0530, Shreeya Patel wrote:
> In the ade7758 file, read raw does not require iio_dev->mlock for
> reads. It can run concurrently as resource protection is handled
> by buf_lock in read register.
Removed linux-kernel list and Greg from reply list.
>
> Signed-off-by: Sh
From: pr0gr4m
---
drivers/staging/rtl8723bs/hal/odm.h | 17 +
drivers/staging/rtl8723bs/hal/rtl8723b_dm.c | 16 ++--
drivers/staging/rtl8723bs/include/rtw_rf.h| 15 ++-
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 12
Oops, Sorry for being stupid cuz of first time to use git email.
RF_TYPE and ODM_RF_TYPE on staging/rtl8723bs is different from
staging/rtlwifi 's - updated from v 4.14 -
So, I try to update code on staging/rtl8723bs in comparison with
staging/rtlwifi.
commit message is "Update rf_type and odm_rf_t
iio_dev->mlock is to be used only by the IIO core for protecting
device mode changes between INDIO_DIRECT and INDIO_BUFFER.
This patch replaces the use of mlock with the already established
buf_lock mutex.
Introducing 'unlocked' forms of read and write registers. The
read/write frequency function
On Wed, 2018-02-07 at 00:57 +0900, Kangmin Park wrote:
> From: pr0gr4m
This needs a commit message. I don't understand what the code is trying
to do.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/lis
From: Kangmin Park
enum RT_RF_TYPE_DEFINITION on rtl8723bs/include/rtw_rf.h
is different from enum tag_HAL_RF_Type_Definition on
rtl8723bs/include/HalVerDef.h
So, update them to be the same reference from
enum rf_type on rtlwifi/wifi.h which recent version.
As a result, ODM_RF_TYPE_E needs to b
On 01/26/2018 09:48 AM, Liam Mark wrote:
Since commit 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
the CMA API is now used directly and therefore the allocated memory is no
longer automatically zeroed.
Explicitly zero CMA allocated memory to ensure that no data is exposed to
use
On 01/30/2018 08:01 PM, Yisheng Xie wrote:
ion_buffer_fault_user_mappings's definition has been removed and not be
used anymore, just remove its useless declaration.
Acked-by: Laura Abbott
Signed-off-by: Yisheng Xie
---
drivers/staging/android/ion/ion.h | 9 -
1 file changed, 9
On 01/31/2018 01:50 AM, Yisheng Xie wrote:
ion_page_pool.c now is used to apply pool APIs for system heap, which do
not need do any initial at device_initcall.
Meanwhile, this patch also remove some useless include files.
Acked-by: Laura Abbott
Signed-off-by: Yisheng Xie
---
drivers/sta
On 02/01/2018 04:34 AM, Yisheng Xie wrote:
If we failed to create debugfs for ion at ion_device_create, the
debug_root of ion_device will be NULL, and then when try to create debug
file for shrinker of heap it will be create on the top of debugfs. If we
also failed to create this the debug file,
On 02/01/2018 04:34 AM, Yisheng Xie wrote:
When failed to create debug_root, we will go on initail other part of
ion, so we can just info this message to user and do not need a lable
to jump.
Acked-by: Laura Abbott
Signed-off-by: Yisheng Xie
---
drivers/staging/android/ion/ion.c | 5 +---
On 02/04/2018 07:26 PM, Yisheng Xie wrote:
ion_page_pool_add will always return 0, however ion_page_pool_free will
call ion_page_pool_free_pages when ion_page_pool_add's return value is
not 0, so it is a dead code which can be removed.
Can you clean up ion_page_pool_add to be a void return as
On 02/06/2018 03:10 PM, Laura Abbott wrote:
On 02/04/2018 07:26 PM, Yisheng Xie wrote:
ion_page_pool_add will always return 0, however ion_page_pool_free will
call ion_page_pool_free_pages when ion_page_pool_add's return value is
not 0, so it is a dead code which can be removed.
Can you clean
Fixed the following checkpatch warning
WARNING: braces {} are not necessary for any arm of this statement
Signed-off-by: Santha Meena Ramamoorthy
---
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media
On 01/28/2018 08:24 AM, Alexey Skidanov wrote:
Hi,
According to my understanding, the allocation fall back order
completely depends on heap->id that is assigned during the heap
creation:
plist_for_each_entry(heap, &dev->heaps, node) {
/* if the caller didn't specify this heap id */
On 01/31/2018 10:10 PM, Alexey Skidanov wrote:
On 01/31/2018 03:00 PM, Greg KH wrote:
On Wed, Jan 31, 2018 at 02:03:42PM +0200, Alexey Skidanov wrote:
Any driver may access shared buffers, created by ion, using dma_buf_vmap and
dma_buf_vunmap dma-buf API that maps/unmaps previosuly allocated b
Michael,
> Update the algorithm in storvsc_do_io to look for a channel starting
> with the current CPU + 1 and wrap around (within the current NUMA
> node). This spreads VMbus interrupts more evenly across CPUs. Previous
> code always started with first CPU in the current NUMA node, skewing
> the
Michael,
> Increase cmd_per_lun to allow more I/Os in progress per device,
> particularly for NVMe's. The Hyper-V host side can handle the higher
> count with no issues.
Applied to 4.16/scsi-fixes. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
Hi Laura,
On 2018/2/7 6:51, Laura Abbott wrote:
> On 01/31/2018 01:50 AM, Yisheng Xie wrote:
>> ion_page_pool.c now is used to apply pool APIs for system heap, which do
>> not need do any initial at device_initcall.
>>
>> Meanwhile, this patch also remove some useless include files.
>>
>
> Acked-
Hi Laura,
On 2018/2/7 7:11, Laura Abbott wrote:
> On 02/06/2018 03:10 PM, Laura Abbott wrote:
>> On 02/04/2018 07:26 PM, Yisheng Xie wrote:
>>> ion_page_pool_add will always return 0, however ion_page_pool_free will
>>> call ion_page_pool_free_pages when ion_page_pool_add's return value is
>>> not
ion_page_pool_alloc_pages calls alloc_pages to allocate pages for page
pools. If alloc_pages return NULL, it will return NULL, or it will
return the pages allocate from alloc_pages. So we can just return
alloc_pages without any judgement.
Signed-off-by: Yisheng Xie
---
drivers/staging/android/io
Now we call dma_map in the dma_buf API callbacks and handle explicit
caching by the dma_buf sync API, which make cache and uncache pools
in the same handling flow, which can be combined.
Signed-off-by: Yisheng Xie
---
drivers/staging/android/ion/ion.c | 5 --
drivers/staging/android
On 02/07/2018 01:56 AM, Laura Abbott wrote:
> On 01/31/2018 10:10 PM, Alexey Skidanov wrote:
>>
>> On 01/31/2018 03:00 PM, Greg KH wrote:
>>> On Wed, Jan 31, 2018 at 02:03:42PM +0200, Alexey Skidanov wrote:
Any driver may access shared buffers, created by ion, using
dma_buf_vmap and
>>>
> Yup, you've hit upon a key problem. Having fallbacks be stable
> was always a problem and the recommendation these days is to
> not rely on them. You can specify a heap at a time and fallback
> manually if you want that behavior.
>
> If you have a proposal to make fallbacks work reliably witho
25 matches
Mail list logo
