On 2020/7/23 14:27, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:f932d58a Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=152c6a8090
kernel config:
On 2020/5/14 18:54, Phil Sutter wrote:
Hi,
On Wed, May 13, 2020 at 11:20:35PM +0800, Xiubo Li wrote:
Recently I hit one netfilter issue, it seems the API breaks or something
else.
Just for the record, this was caused by a misconfigured kernel.
Yeah, thanks Phil for your help.
BRs
Xiubo
Hi Experts，
Recently I hit one netfilter issue, it seems the API breaks or something
else.
On CentOS8.1 with the recent upstream kernel built from source, such as
5.6.0-rc6/5.7.0-rc4. When running the following command:
$ sudo bash -c 'iptables -A FORWARD -o enp3s0f1 -i ceph-brx -j ACCEPT'
On 2019/9/21 0:06, Eugene Syromiatnikov wrote:
In the (very unlikely) case of config->socks reallocation success
and nsock allocation failure config->nsock will not get updated
with the new pointer to socks array. Fix it by updating config->socks
right after reallocation successfulness check.
On 2019/9/18 16:14, Michal Hocko wrote:
On Wed 18-09-19 16:02:52, Xiubo Li wrote:
On 2019/9/18 15:25, Michal Hocko wrote:
On Wed 18-09-19 04:58:20, xiu...@redhat.com wrote:
From: Xiubo Li
The GFP_NOIO means all further allocations will implicitly drop
both __GFP_IO and __GFP_FS flags and so
On 2019/9/18 15:25, Michal Hocko wrote:
On Wed 18-09-19 04:58:20, xiu...@redhat.com wrote:
From: Xiubo Li
The GFP_NOIO means all further allocations will implicitly drop
both __GFP_IO and __GFP_FS flags and so they are safe for both the
IO critical section and the the critical section from
On 2019/1/3 22:28, liujian wrote:
Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
Signed-off-by: liujian
---
v1->v2:
rename the "err_infoopen" to "err_idev_info"
v2->3:
put the extra info after the "--"
Looks good to me.
Thanks.
BRs
drivers/uio/uio.c | 7 ---
On 2019/1/3 0:26, liujian wrote:
Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
Signed-off-by: liujian
---
drivers/uio/uio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5c10fc7..bde7d7a 100644
---
On 2018/8/12 19:03, gre...@linuxfoundation.org wrote:
On Sun, Aug 12, 2018 at 06:55:58PM +0800, Xiubo Li wrote:
Hi Harris,
Since the lock protection in uio irq handler is useless currently as
discussed in the mail list, so I will revert this commit with small changes
and now the testing based
On 2018/8/12 19:03, gre...@linuxfoundation.org wrote:
On Sun, Aug 12, 2018 at 06:55:58PM +0800, Xiubo Li wrote:
Hi Harris,
Since the lock protection in uio irq handler is useless currently as
discussed in the mail list, so I will revert this commit with small changes
and now the testing based
Hi Harris,
Since the lock protection in uio irq handler is useless currently as
discussed in the mail list, so I will revert this commit with small
changes and now the testing based LIO/TCMU has been finished.
Thanks,
BRs
On 2018/8/11 5:12, Harris, James R wrote:
Hi,
Using Linux kernel
Hi Harris,
Since the lock protection in uio irq handler is useless currently as
discussed in the mail list, so I will revert this commit with small
changes and now the testing based LIO/TCMU has been finished.
Thanks,
BRs
On 2018/8/11 5:12, Harris, James R wrote:
Hi,
Using Linux kernel
after the device is unregistered")
CC: Xiubo Li
Signed-off-by: Hailong Liu
Signed-off-by: Jiang Biao
---
drivers/uio/uio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5d421d7..0ddfda2 100644
--- a/drivers/uio/uio.c
+++ b/d
after the device is unregistered")
CC: Xiubo Li
Signed-off-by: Hailong Liu
Signed-off-by: Jiang Biao
---
drivers/uio/uio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5d421d7..0ddfda2 100644
--- a/drivers/uio/uio.c
+++ b/d
series of yours has caused no regression in our scenario. This was
tested on PPC 64 bit system (NXP T2081).
Hi Hamish,
Cool and thanks very much for your testing about this.
BRs
Xiubo
Thanks for resolving that.
Regards,
Hamish M.
On 07/07/2018 02:05 PM, xiu...@redhat.com wrote:
From: Xiubo Li
series of yours has caused no regression in our scenario. This was
tested on PPC 64 bit system (NXP T2081).
Hi Hamish,
Cool and thanks very much for your testing about this.
BRs
Xiubo
Thanks for resolving that.
Regards,
Hamish M.
On 07/07/2018 02:05 PM, xiu...@redhat.com wrote:
From: Xiubo Li
On 2018/7/10 1:06, Mike Christie wrote:
On 07/06/2018 08:28 PM, Xiubo Li wrote:
On 2018/7/7 2:23, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
static irqreturn_t uio_interrupt(int irq, void *dev_id)
{
struct uio_device *idev = (struct uio_device *)dev_id
On 2018/7/10 1:06, Mike Christie wrote:
On 07/06/2018 08:28 PM, Xiubo Li wrote:
On 2018/7/7 2:23, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
static irqreturn_t uio_interrupt(int irq, void *dev_id)
{
struct uio_device *idev = (struct uio_device *)dev_id
On 2018/7/10 0:40, Mike Christie wrote:
On 07/06/2018 08:47 PM, Xiubo Li wrote:
On 2018/7/7 2:58, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
void uio_event_notify(struct uio_info *info)
{
-struct uio_device *idev = info->uio_dev;
+struct uio_dev
On 2018/7/10 0:40, Mike Christie wrote:
On 07/06/2018 08:47 PM, Xiubo Li wrote:
On 2018/7/7 2:58, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
void uio_event_notify(struct uio_info *info)
{
-struct uio_device *idev = info->uio_dev;
+struct uio_dev
On 2018/7/7 2:58, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
void uio_event_notify(struct uio_info *info)
{
- struct uio_device *idev = info->uio_dev;
+ struct uio_device *idev;
+
+ if (!info)
+ return;
+
+ idev =
On 2018/7/7 2:58, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
void uio_event_notify(struct uio_info *info)
{
- struct uio_device *idev = info->uio_dev;
+ struct uio_device *idev;
+
+ if (!info)
+ return;
+
+ idev =
On 2018/7/7 2:23, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
static irqreturn_t uio_interrupt(int irq, void *dev_id)
{
struct uio_device *idev = (struct uio_device *)dev_id;
- irqreturn_t ret = idev->info->handler(irq, idev->info);
+
On 2018/7/7 2:23, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
static irqreturn_t uio_interrupt(int irq, void *dev_id)
{
struct uio_device *idev = (struct uio_device *)dev_id;
- irqreturn_t ret = idev->info->handler(irq, idev->info);
+
intend to report back to you by July 13th.
Hi Hamish,
Thanks vey much for your quickly review and reply about this. Take
your time :-)
BRs
Xiubo
Thanks,
Hamish M
On 07/06/2018 02:57 PM, xiu...@redhat.com wrote:
From: Xiubo Li
The V2 patch set maybe not post successfully, so post
intend to report back to you by July 13th.
Hi Hamish,
Thanks vey much for your quickly review and reply about this. Take
your time :-)
BRs
Xiubo
Thanks,
Hamish M
On 07/06/2018 02:57 PM, xiu...@redhat.com wrote:
From: Xiubo Li
The V2 patch set maybe not post successfully, so post
On 2018/7/6 4:56, Jann Horn wrote:
On Thu, Jul 5, 2018 at 10:53 PM wrote:
From: Xiubo Li
For the target_core_user use case, after the device is unregistered
it maybe still opened in user space, then the kernel will crash, like:
[...]
Signed-off-by: Xiubo Li
---
drivers/uio/uio.c | 101
On 2018/7/6 4:56, Jann Horn wrote:
On Thu, Jul 5, 2018 at 10:53 PM wrote:
From: Xiubo Li
For the target_core_user use case, after the device is unregistered
it maybe still opened in user space, then the kernel will crash, like:
[...]
Signed-off-by: Xiubo Li
---
drivers/uio/uio.c | 101
On 2018/7/6 0:33, Greg KH wrote:
On Thu, Jul 05, 2018 at 12:27:27PM -0400, xiu...@redhat.com wrote:
From: Xiubo Li
We are hitting a regression with the following commit:
commit a93e7b331568227500186a465fee3c2cb5dffd1f
Author: Hamish Martin
Date: Mon May 14 13:32:23 2018 +1200
uio
On 2018/7/6 0:33, Greg KH wrote:
On Thu, Jul 05, 2018 at 12:27:27PM -0400, xiu...@redhat.com wrote:
From: Xiubo Li
We are hitting a regression with the following commit:
commit a93e7b331568227500186a465fee3c2cb5dffd1f
Author: Hamish Martin
Date: Mon May 14 13:32:23 2018 +1200
uio
Hi Nic & Mike
I will update this just after the issue reported by Bryant on his
environment been fixed later.
Thanks,
BRs
Xiubo
On 2017年06月04日 12:11, Mike Christie wrote:
On 05/04/2017 09:51 PM, lixi...@cmss.chinamobile.com wrote:
From: Xiubo Li <lixi...@cmss.chinamobile.com>
Hi Nic & Mike
I will update this just after the issue reported by Bryant on his
environment been fixed later.
Thanks,
BRs
Xiubo
On 2017年06月04日 12:11, Mike Christie wrote:
On 05/04/2017 09:51 PM, lixi...@cmss.chinamobile.com wrote:
From: Xiubo Li
The fifo type waiter list will
[...]
+
+static bool tcmu_get_empty_blocks(struct tcmu_dev *udev,
+ struct tcmu_cmd *tcmu_cmd,
+ uint32_t blocks_needed)
Can drop blocks_needed.
Will fix it.
[...]
-static void *tcmu_get_block_addr(struct tcmu_dev *udev,
[...]
+
+static bool tcmu_get_empty_blocks(struct tcmu_dev *udev,
+ struct tcmu_cmd *tcmu_cmd,
+ uint32_t blocks_needed)
Can drop blocks_needed.
Will fix it.
[...]
-static void *tcmu_get_block_addr(struct tcmu_dev *udev,
de and
the kunmap is at the end of aasda().
This as the initial patch, the memory is from slab cache now. But since
the second
patch followed will covert to use memory page from the buddy directly.
Thanks,
BRs
Xiubo Li
de and
the kunmap is at the end of aasda().
This as the initial patch, the memory is from slab cache now. But since
the second
patch followed will covert to use memory page from the buddy directly.
Thanks,
BRs
Xiubo Li
On 2017年02月28日 03:32, Andy Grover wrote:
On 02/26/2017 09:59 PM, Xiubo Li wrote:
But, We likely don't want to release memory from the data area anyways
while active, in any case. How about if we set a timer when active
commands go to zero, and then reduce data area to some minimum if no new
On 2017年02月28日 03:32, Andy Grover wrote:
On 02/26/2017 09:59 PM, Xiubo Li wrote:
But, We likely don't want to release memory from the data area anyways
while active, in any case. How about if we set a timer when active
commands go to zero, and then reduce data area to some minimum if no new
For now we will increase the data area size to 1G, and the cmd area
size to 128M. The tcmu-runner should mmap() about (128M + 1G) when
running and the TCMU will dynamically grows the data area from 0 to
max 1G size.
Cool. This is a good approach for an initial patch but this raises
concerns
For now we will increase the data area size to 1G, and the cmd area
size to 128M. The tcmu-runner should mmap() about (128M + 1G) when
running and the TCMU will dynamically grows the data area from 0 to
max 1G size.
Cool. This is a good approach for an initial patch but this raises
concerns
Write throughput is pretty
low at around 150 MB/s.
What's the original write throughput without this patch? Is it also
around 80 MB/s ?
It is around 20-30 MB/s. Same fio args except using --rw=write.
Got it.
Thanks.
BRs
Xiubo
Write throughput is pretty
low at around 150 MB/s.
What's the original write throughput without this patch? Is it also
around 80 MB/s ?
It is around 20-30 MB/s. Same fio args except using --rw=write.
Got it.
Thanks.
BRs
Xiubo
On 02/17/2017 01:24 AM, lixi...@cmss.chinamobile.com wrote:
From: Xiubo Li <lixi...@cmss.chinamobile.com>
Currently for the TCMU, the ring buffer size is fixed to 64K cmd
area + 1M data area, and this will be bottlenecks for high iops.
Hi Xiubo, thanks for your work.
daynmic -> dyna
On 02/17/2017 01:24 AM, lixi...@cmss.chinamobile.com wrote:
From: Xiubo Li
Currently for the TCMU, the ring buffer size is fixed to 64K cmd
area + 1M data area, and this will be bottlenecks for high iops.
Hi Xiubo, thanks for your work.
daynmic -> dynamic
Have you benchmarked this pa
Cool. This is a good approach for an initial patch but this raises
concerns about efficiently managing kernel memory usage -- the data area
grows but never shrinks, and total possible usage increases per
backstore. (What if there are 1000?) Any ideas how we could also improve
these aspects of
Cool. This is a good approach for an initial patch but this raises
concerns about efficiently managing kernel memory usage -- the data area
grows but never shrinks, and total possible usage increases per
backstore. (What if there are 1000?) Any ideas how we could also improve
these aspects of
When N is bigger, the ratio will be smaller. If N >= 1, the ratio
will be [15/1024, 4/1024), for this the ratio 15 : 1024 will be
enough. But maybe some iscsi cmds has no datas, N == 0. So the ratio
should be bigger.
For now we will increase the data area size to 1G, and the cmd area
size to
When N is bigger, the ratio will be smaller. If N >= 1, the ratio
will be [15/1024, 4/1024), for this the ratio 15 : 1024 will be
enough. But maybe some iscsi cmds has no datas, N == 0. So the ratio
should be bigger.
For now we will increase the data area size to 1G, and the cmd area
size to
buffer(uio0 --> map0). Currently the TCMU will using the fixed small
size map
area as the ring buffer, but this will be the bottleneck for high iops.
Without knowing how large it is enough, so the new scheme will use the
fixed
small ring buffer area(about 64M ~ 128M) + dynamically "growing"
buffer(uio0 --> map0). Currently the TCMU will using the fixed small
size map
area as the ring buffer, but this will be the bottleneck for high iops.
Without knowing how large it is enough, so the new scheme will use the
fixed
small ring buffer area(about 64M ~ 128M) + dynamically "growing"
For example, the TCMU will use the map area as ISCSI commands & data ring
buffer(uio0 --> map0). Currently the TCMU will using the fixed small
size map
area as the ring buffer, but this will be the bottleneck for high iops.
Without knowing how large it is enough, so the new scheme will use the
For example, the TCMU will use the map area as ISCSI commands & data ring
buffer(uio0 --> map0). Currently the TCMU will using the fixed small
size map
area as the ring buffer, but this will be the bottleneck for high iops.
Without knowing how large it is enough, so the new scheme will use the
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index fba021f..6ca0ae0 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -708,6 +708,8 @@ static int uio_mmap(struct file *filep, struct
vm_area_struct *vma)
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index fba021f..6ca0ae0 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -708,6 +708,8 @@ static int uio_mmap(struct file *filep, struct
vm_area_struct *vma)
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
best resolution is to move tcmu_handle_completion() between
spin_lock(>commands_lock) and spin_unlock(>commands_lock)?
Thanks.
BRs
Xiubo Li
best resolution is to move tcmu_handle_completion() between
spin_lock(>commands_lock) and spin_unlock(>commands_lock)?
Thanks.
BRs
Xiubo Li
Since the commit f14bbe77a96bb ("blk-mq: pass in suggested NUMA
node to ->alloc_hctx()") has already computed and set the
suggested NUMA node for hctx, so this code here is reduntant.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
block/blk-mq.c | 19 ++--
Since the commit f14bbe77a96bb ("blk-mq: pass in suggested NUMA
node to ->alloc_hctx()") has already computed and set the
suggested NUMA node for hctx, so this code here is reduntant.
Signed-off-by: Xiubo Li
---
block/blk-mq.c | 19 ++-
1 file changed, 2 inse
The 't' in "function" was missing, this patch fixes this typo:
s/funcion/function/g
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
Changes for V2:
- Add changelog text.
drivers/base/attribute_container.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The 't' in "function" was missing, this patch fixes this typo:
s/funcion/function/g
Signed-off-by: Xiubo Li
---
Changes for V2:
- Add changelog text.
drivers/base/attribute_container.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/attribute_cont
On 31/05/2016 23:26, Greg KH wrote:
On Tue, May 31, 2016 at 04:17:15PM +0800, Xiubo Li wrote:
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
I can't take patches without any changelog text, sorry.
My mistake, I will send the v2 one.
Thanks.
On 31/05/2016 23:26, Greg KH wrote:
On Tue, May 31, 2016 at 04:17:15PM +0800, Xiubo Li wrote:
Signed-off-by: Xiubo Li
I can't take patches without any changelog text, sorry.
My mistake, I will send the v2 one.
Thanks.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
drivers/base/attribute_container.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/attribute_container.c
b/drivers/base/attribute_container.c
index 2ba4cac..95e3ef8 100644
--- a/driver
Signed-off-by: Xiubo Li
---
drivers/base/attribute_container.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/attribute_container.c
b/drivers/base/attribute_container.c
index 2ba4cac..95e3ef8 100644
--- a/drivers/base/attribute_container.c
+++ b/drivers/base
Here introduces regcache_get_index_by_order() for regmap cache,
which uses the register stride order and bit rotation, to improve
the performance.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/internal.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/base/regmap/internal.h
I/O accessing.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regcache-flat.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/base/regmap/regcache-flat.c
b/drivers/base/regmap/regcache-flat.c
index 686c9e0..3ee7255 100644
--- a/drivers/base
Please ignore the V1 series.
Changed in V2:
- Introduce regsiter stride order by continue supporting non power of two
strides.
Xiubo Li (3):
regmap: core: Introduce regsiter stride order
regcache: Introduce the index parsing API by stride order
regcache: flat: Introduce register strider
Since the register stride should always equal to 2^N, and bit rotation is
much faster than multiplication and division. So introducing the stride
order and using bit rotation to get the offset of the register from the
index to improve the performance.
Signed-off-by: Xiubo Li
---
drivers/base
Since the register stride should always equal to 2^N, and bit rotation is
much faster than multiplication and division. So introducing the stride
order and using bit rotation to get the offset of the register from the
index to improve the performance.
Signed-off-by: Xiubo Li <l
Here introduces regcache_get_index_by_order() for regmap cache,
which uses the register stride order and bit rotation, to improve
the performance.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
drivers/base/regmap/internal.h | 6 ++
1 file changed, 6 insertions(+)
diff
Please ignore the V1 series.
Changed in V2:
- Introduce regsiter stride order by continue supporting non power of two
strides.
Xiubo Li (3):
regmap: core: Introduce regsiter stride order
regcache: Introduce the index parsing API by stride order
regcache: flat: Introduce register strider
I/O accessing.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
drivers/base/regmap/regcache-flat.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/base/regmap/regcache-flat.c
b/drivers/base/regmap/regcache-flat.c
index 686c9e0..3
like three bytes.
Yes, if so, for this case the non power of two strides should be still
supported.
Thanks for your promotion, and I will think over of this carefully.
BRs
Xiubo Li
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
like three bytes.
Yes, if so, for this case the non power of two strides should be still
supported.
Thanks for your promotion, and I will think over of this carefully.
BRs
Xiubo Li
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
accessing.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regcache-flat.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/base/regmap/regcache-flat.c
b/drivers/base/regmap/regcache-flat.c
index 686c9e0..218cf39 100644
--- a/drivers/base/regmap/regcache
Since the register stride should always equal to 2^N, and bit rotation is
much faster than multiplication and division. So introducing the stride
order and using bit rotation to get the offset of the register from the
index to improve the performance.
Signed-off-by: Xiubo Li
---
drivers/base
Xiubo Li (3):
regmap: core: Introduce register stride order
regcache: Introduce the index parsing API
regcache: flat: Introduce regcache_get_index()
drivers/base/regmap/internal.h | 13 +
drivers/base/regmap/regcache-flat.c | 11 ++-
drivers/base/regmap/regmap.c
Here introduces regcache_get_index() for regmap cache, which uses
the register stride order and bit rotation.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/internal.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
Here introduces regcache_get_index() for regmap cache, which uses
the register stride order and bit rotation.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
drivers/base/regmap/internal.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/base/regmap/intern
accessing.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
drivers/base/regmap/regcache-flat.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/base/regmap/regcache-flat.c
b/drivers/base/regmap/regcache-flat.c
index 686c9e0..218cf39
Since the register stride should always equal to 2^N, and bit rotation is
much faster than multiplication and division. So introducing the stride
order and using bit rotation to get the offset of the register from the
index to improve the performance.
Signed-off-by: Xiubo Li <l
Xiubo Li (3):
regmap: core: Introduce register stride order
regcache: Introduce the index parsing API
regcache: flat: Introduce regcache_get_index()
drivers/base/regmap/internal.h | 13 +
drivers/base/regmap/regcache-flat.c | 11 ++-
drivers/base/regmap/regmap.c
The stride value should always equal to 2^n, so we can use bit
rotation instead of % to improve the performance.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regmap.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers
The stride value should always equal to 2^n, so we can use bit
rotation instead of % to improve the performance.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
drivers/base/regmap/regmap.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/d
ore memory
space wasted. After introducing the register striding here can
save some memeories for the system.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regcache-flat.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/base/regmap/regcache-flat.c
ore memory
space wasted. After introducing the register striding here can
save some memeories for the system.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
drivers/base/regmap/regcache-flat.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/dri
If there is no cache used for the drivers, the register defaults
or the register defaults raw are not need any more. This patch
will check this and print a warning.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regcache.c | 12
1 file changed, 8 insertions(+), 4 deletions
Changed in V2:
- Correct some words in the commit commnet and logs.
- Add register defaults raw check.
- Add [PATCHv2 2/2]
Xiubo Li (2):
regmap: cache: Add warning info for the cache check
regmap: cache: Move the num_reg_defaults check as early as possible
drivers/base/regmap/regcache.c
If the register defaults are provided by the driver without the
number by mistake, it should just return an error with one promotion.
This should be as early as possible, then there is no need to verify
the register defaults' stride and the other code followed.
Signed-off-by: Xiubo Li
On 10/12/2015 20:45, Charles Keepax wrote:
On Thu, Dec 10, 2015 at 10:40:53AM +0800, Xiubo Li wrote:
If there is no cache used for the drivers, the register drfaults
s/drfaults/defaults/
Yes，Thanks.
are not need any more. This patch will check this and print a
warning.
Signed-off
On 10/12/2015 20:45, Charles Keepax wrote:
On Thu, Dec 10, 2015 at 10:40:53AM +0800, Xiubo Li wrote:
If there is no cache used for the drivers, the register drfaults
s/drfaults/defaults/
Yes，Thanks.
are not need any more. This patch will check this and print a
warning.
Signed-off
If the register defaults are provided by the driver without the
number by mistake, it should just return an error with one promotion.
This should be as early as possible, then there is no need to verify
the register defaults' stride and the other code followed.
Signed-off-by: Xiubo Li <l
Changed in V2:
- Correct some words in the commit commnet and logs.
- Add register defaults raw check.
- Add [PATCHv2 2/2]
Xiubo Li (2):
regmap: cache: Add warning info for the cache check
regmap: cache: Move the num_reg_defaults check as early as possible
drivers/base/regmap/regcache.c
If there is no cache used for the drivers, the register defaults
or the register defaults raw are not need any more. This patch
will check this and print a warning.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
drivers/base/regmap/regcache.c | 12
1 file chan
If there is no cache used for the drivers, the register drfaults
are not need any more. This patch will check this and print a
warning.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regcache.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/base/regmap
On 09/12/2015 23:05, Mark Brown wrote:
On Wed, Dec 09, 2015 at 11:17:22AM +0800, Xiubo Li wrote:
Yes, usually when the register cache is not used, the number of the
defaults should be zero, but for some drivers like drv2267.c/led_lp8860.c
will add the defaults register values though
The variable 'u64 *u64' should be only visible on 64-BIT platform.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 1791180..a0d30a0 100644
--- a/drivers/base/regmap
On 09/12/2015 16:45, Arnd Bergmann wrote:
On Thursday 03 December 2015 17:31:52 Xiubo Li wrote:
@@ -2488,11 +2581,17 @@ int regmap_bulk_read(struct regmap *map, unsigned int
reg, void *val,
* we assume that the values are native
On 09/12/2015 16:45, Arnd Bergmann wrote:
On Thursday 03 December 2015 17:31:52 Xiubo Li wrote:
@@ -2488,11 +2581,17 @@ int regmap_bulk_read(struct regmap *map, unsigned int
reg, void *val,
* we assume that the values are native
The variable 'u64 *u64' should be only visible on 64-BIT platform.
Signed-off-by: Xiubo Li <lixi...@cmss.chinamobile.com>
---
drivers/base/regmap/regmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 1791180..a
1 - 100 of 1058 matches
Mail list logo
