Re: mapcount corruption regression

not reproduce this issue with my regression test now, feel free to add: Tested-by: Yi Zhang Thanks Yi

Re: [IB/srpt] c804af2c1d: last_state.test.blktests.exit_code.143

Tested-by: Yi Zhang This patch fixed the issue I filed[1] which use rdma_rxe for nvme-rdma testing. [1] http://lists.infradead.org/pipermail/linux-nvme/2020-August/018988.html Thanks Yi On 9/12/20 6:00 AM, Bart Van Assche wrote: On 2020-09-08 19:01, Bart Van Assche wrote: The above

Re: [PATCH V2 1/1] device-dax: check for vma range while dax_mmap.

On 2018-12-10 at 16:10:31 -0800, Dan Williams wrote: > On Tue, Aug 21, 2018 at 12:38 AM Yi Zhang wrote: > > > > On 2018-08-20 at 12:50:31 -0700, Dave Jiang wrote: > > > > > > > > > On 08/20/2018 10:53 AM, Verma, Vishal L wrote: > > > > >

Re: [RFC PATCH V2 00/11] Intel EPT-Based Sub-page Protection Support

On 2018-12-03 at 05:56:13 +0200, Mihai Donțu wrote: > Hi Paolo, > > On Fri, 2018-11-30 at 11:07 +0100, Paolo Bonzini wrote: > > On 30/11/18 08:52, Zhang Yi wrote: > > > Here is a patch-series which adding EPT-Based Sub-page Write Protection > > > Support. > > > > > > Introduction: > > > > > >

Re: [RFC PATCH V2 00/11] Intel EPT-Based Sub-page Protection Support

On 2018-12-03 at 05:56:13 +0200, Mihai Donțu wrote: > Hi Paolo, > > On Fri, 2018-11-30 at 11:07 +0100, Paolo Bonzini wrote: > > On 30/11/18 08:52, Zhang Yi wrote: > > > Here is a patch-series which adding EPT-Based Sub-page Write Protection > > > Support. > > > > > > Introduction: > > > > > >

Re: [PATCH V5 1/4] kvm: remove redundant reserved page check

On 2018-09-08 at 02:03:28 +0800, Zhang Yi wrote: > PageReserved() is already checked inside kvm_is_reserved_pfn(), > remove it from kvm_set_pfn_dirty(). > > Signed-off-by: Zhang Yi > Signed-off-by: Zhang Yu > Reviewed-by: David Hildenbrand > Acked-by: Pankaj Gupta > --- > virt/kvm/kvm_main.c

Re: [PATCH V5 1/4] kvm: remove redundant reserved page check

On 2018-09-08 at 02:03:28 +0800, Zhang Yi wrote: > PageReserved() is already checked inside kvm_is_reserved_pfn(), > remove it from kvm_set_pfn_dirty(). > > Signed-off-by: Zhang Yi > Signed-off-by: Zhang Yu > Reviewed-by: David Hildenbrand > Acked-by: Pankaj Gupta > --- > virt/kvm/kvm_main.c

bug report - kernel BUG at mm/slub.c:3894!

b 00 be fd 00 00 00 48 8b 40 30 ff e0 89 fe 48 c7 c7 78 29 05 a1 e8 ba c4 03 00 <0f> ff c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 53 be 20 00 08 01 [ 286.461854] ---[ end trace 5a3846fe48038f60 ]--- Best Regards, Yi Zhang

bug report - kernel BUG at mm/slub.c:3894!

b 00 be fd 00 00 00 48 8b 40 30 ff e0 89 fe 48 c7 c7 78 29 05 a1 e8 ba c4 03 00 <0f> ff c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 53 be 20 00 08 01 [ 286.461854] ---[ end trace 5a3846fe48038f60 ]--- Best Regards, Yi Zhang

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-11-10 at 16:39:27 +0100, Paolo Bonzini wrote: > On 04/11/2017 17:54, Paolo Bonzini wrote: > > On 04/11/2017 01:12, Yi Zhang wrote: > >>> > >> Adding Ravi, > >> > >> Does anyone have further comments on current implementation, it is a > &

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-11-10 at 16:39:27 +0100, Paolo Bonzini wrote: > On 04/11/2017 17:54, Paolo Bonzini wrote: > > On 04/11/2017 01:12, Yi Zhang wrote: > >>> > >> Adding Ravi, > >> > >> Does anyone have further comments on current implementation, it is a > &

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-14 at 07:11:28 +0800, Zhang Yi wrote: > From: Zhang Yi Z > > Hi All, > > Here is a patch-series which adding EPT-Based Sub-page Write Protection > Support. You can get It's software developer manuals from: > >

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-14 at 07:11:28 +0800, Zhang Yi wrote: > From: Zhang Yi Z > > Hi All, > > Here is a patch-series which adding EPT-Based Sub-page Write Protection > Support. You can get It's software developer manuals from: > >

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-20 at 20:06:47 +0300, Mihai Donțu wrote: > On Fri, 2017-10-20 at 16:47 +0800, Yi Zhang wrote: > > Could you mind to provide more information and history about your > > investigation? > > We are using VMI to secure certain parts of a guest kernel in memory > (lik

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-20 at 20:06:47 +0300, Mihai Donțu wrote: > On Fri, 2017-10-20 at 16:47 +0800, Yi Zhang wrote: > > Could you mind to provide more information and history about your > > investigation? > > We are using VMI to secure certain parts of a guest kernel in memory > (lik

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-19 at 13:57:12 +0200, Paolo Bonzini wrote: > > I would leave out the ioctl without a use case. It's always tricky to > add APIs without a user, as the risk of bit rot is high. But if > somebody comes up with a matching useful patch for QEMU or kvmtool, it's > fine. That's fine,

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-19 at 13:57:12 +0200, Paolo Bonzini wrote: > > I would leave out the ioctl without a use case. It's always tricky to > add APIs without a user, as the risk of bit rot is high. But if > somebody comes up with a matching useful patch for QEMU or kvmtool, it's > fine. That's fine,

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-18 at 17:13:18 +0300, Mihai Donțu wrote: > On Wed, 2017-10-18 at 11:35 +0200, Paolo Bonzini wrote: > > On 16/10/2017 02:08, Yi Zhang wrote: > > > > And the introspection facility by Mihai uses a completely > > > > different API for the introspector, ba

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-18 at 17:13:18 +0300, Mihai Donțu wrote: > On Wed, 2017-10-18 at 11:35 +0200, Paolo Bonzini wrote: > > On 16/10/2017 02:08, Yi Zhang wrote: > > > > And the introspection facility by Mihai uses a completely > > > > different API for the introspector, ba

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-18 at 11:35:12 +0200, Paolo Bonzini wrote: > > > > Currently, We only block the write access, As far as I know an example, > > we now using it in a security daemon: > > Understood. However, I think QEMU is the wrong place to set this up. > > If the kernel wants to protect _itself_,

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-18 at 11:35:12 +0200, Paolo Bonzini wrote: > > > > Currently, We only block the write access, As far as I know an example, > > we now using it in a security daemon: > > Understood. However, I think QEMU is the wrong place to set this up. > > If the kernel wants to protect _itself_,

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-18 at 00:09:36 -0700, Christoph Hellwig wrote: > > We introduced 2 ioctls to let user application to set/get subpage write > > protection bitmap per gfn, each gfn corresponds to a bitmap. > > The user application, qemu, or some other security control daemon. will set > > the

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

On 2017-10-18 at 00:09:36 -0700, Christoph Hellwig wrote: > > We introduced 2 ioctls to let user application to set/get subpage write > > protection bitmap per gfn, each gfn corresponds to a bitmap. > > The user application, qemu, or some other security control daemon. will set > > the

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

Thanks for your quick response Paolo. On 2017-10-13 at 17:13:25 -0400, Paolo Bonzini wrote: > > > I'll ask before Paolo does: Can you please add kvm-unit-tests to > > exercise all of this new code? > > More specifically it should be the api/ unit tests because this code > can only be triggered

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

Thanks for your quick response Paolo. On 2017-10-13 at 17:13:25 -0400, Paolo Bonzini wrote: > > > I'll ask before Paolo does: Can you please add kvm-unit-tests to > > exercise all of this new code? > > More specifically it should be the api/ unit tests because this code > can only be triggered

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

Thanks for your review Jim. On 2017-10-13 at 09:57:45 -0700, Jim Mattson wrote: > I'll ask before Paolo does: Can you please add kvm-unit-tests to > exercise all of this new code? it is should be a API/ioctl tools rather than a kvm-unit-test. Actually, I have prepared a draft version of tools

Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

Thanks for your review Jim. On 2017-10-13 at 09:57:45 -0700, Jim Mattson wrote: > I'll ask before Paolo does: Can you please add kvm-unit-tests to > exercise all of this new code? it is should be a API/ioctl tools rather than a kvm-unit-test. Actually, I have prepared a draft version of tools

Re: [PATCH] device-dax: fix sysfs attribute deadlock

Verified this patch on 4.11. Tested-by: Yi Zhang <yiz...@redhat.com> Best Regards, Yi Zhang - Original Message - From: "Dan Williams" <dan.j.willi...@intel.com> To: linux-nvd...@lists.01.org Cc: linux-kernel@vger.kernel.org, sta...@vger.kernel.org, "Yi

Re: [PATCH] device-dax: fix sysfs attribute deadlock

Verified this patch on 4.11. Tested-by: Yi Zhang Best Regards, Yi Zhang - Original Message - From: "Dan Williams" To: linux-nvd...@lists.01.org Cc: linux-kernel@vger.kernel.org, sta...@vger.kernel.org, "Yi Zhang" Sent: Sunday, April 30, 2017 10:21:54 PM Sub

Re: [PATCH 1/2] blk-mq: don't complete un-started request in timeout handler

Thanks Ming. Tested-by: Yi Zhang <yiz...@redhat.com> Best Regards, Yi Zhang - Original Message - From: "Ming Lei" <tom.leim...@gmail.com> To: "Jens Axboe" <ax...@fb.com>, linux-kernel@vger.kernel.org, linux-bl...@vger.kernel.org, "Chri

Re: [PATCH 1/2] blk-mq: don't complete un-started request in timeout handler

Thanks Ming. Tested-by: Yi Zhang Best Regards, Yi Zhang - Original Message - From: "Ming Lei" To: "Jens Axboe" , linux-kernel@vger.kernel.org, linux-bl...@vger.kernel.org, "Christoph Hellwig" Cc: "Yi Zhang" , "Ming Lei" , sta...@

[PATCH] fs: ext3/ext4: increase the protection of nlink dec and inode destroy

From: zhangyi Because of the disk and hardware issue, the ext3/4 filesystem have many errors, the inode->i_nlink of ext3/4 becomes zero abnormally but the dentry is still positive, it will cause memory corruption after the following process: 1) Due to the inode->i_nlink is

[PATCH] fs: ext3/ext4: increase the protection of nlink dec and inode destroy

From: zhangyi Because of the disk and hardware issue, the ext3/4 filesystem have many errors, the inode->i_nlink of ext3/4 becomes zero abnormally but the dentry is still positive, it will cause memory corruption after the following process: 1) Due to the inode->i_nlink is 0, this inode will

[PATCH 1/2] vfs: add detection of inode validation

When we open/rename/unlink a file and open/rmdir a directory, the inode nlink can't be zero, if it does, the file system is inconsistency, and it can cause some unexpected errors, so add aggressive detection. Signed-off-by: yi zhang <yi.zh...@huawei.com> --- fs/namei.c

[PATCH 2/2] ext4: add detection of i_nlink

ule, when the ext4 filesystem change the orphan list, it will trample other module's data and then may cause oops. This patch detect inode->i_nlink in i_op->valitate, if it becomes zero abnormally, we call ext4_error and return -EFSCORRUPTED. Signed-off-by: yi zhang <yi.zh...@huawei.com>

[PATCH 1/2] vfs: add detection of inode validation

When we open/rename/unlink a file and open/rmdir a directory, the inode nlink can't be zero, if it does, the file system is inconsistency, and it can cause some unexpected errors, so add aggressive detection. Signed-off-by: yi zhang --- fs/namei.c | 44

[PATCH 2/2] ext4: add detection of i_nlink

ule, when the ext4 filesystem change the orphan list, it will trample other module's data and then may cause oops. This patch detect inode->i_nlink in i_op->valitate, if it becomes zero abnormally, we call ext4_error and return -EFSCORRUPTED. Signed-off-by: yi zhang --- fs/ext4/ext4.h| 1 +

[PATCH v3] ext4: increase the protection of nlink dec and ext4 inode destroy

Because of the disk and hardware issue, the ext4 filesystem have many errors, the inode->i_nlink of ext4 becomes zero abnormally but the dentry is still positive, it will cause memory corruption after the following process: 1) Due to the inode->i_nlink is 0, this inode will be added into the

[PATCH v3] ext4: increase the protection of nlink dec and ext4 inode destroy

Because of the disk and hardware issue, the ext4 filesystem have many errors, the inode->i_nlink of ext4 becomes zero abnormally but the dentry is still positive, it will cause memory corruption after the following process: 1) Due to the inode->i_nlink is 0, this inode will be added into the

[RFC PATCH V2] ext4: increase the protection of drop nlink and ext4 inode destroy

ifficulty of locating problems. This patch avoid inode->i_nlink reverse and remove the inode from the orphan list when destroy it if the list is not empty. changes since: v1 - correct a spelling mistake. - change the style of the WARN string. Signed-off-by: yi zhang <yi.zh...@huawei.co

[RFC PATCH V2] ext4: increase the protection of drop nlink and ext4 inode destroy

ifficulty of locating problems. This patch avoid inode->i_nlink reverse and remove the inode from the orphan list when destroy it if the list is not empty. changes since: v1 - correct a spelling mistake. - change the style of the WARN string. Signed-off-by: yi zhang --- fs/ext4/super

[RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

ifficulty of locating problems. This patch avoid inode->i_nlink reverse and remove the inode form the orphan list when destroy it if the list is not empty. Signed-off-by: yi zhang <yi.zh...@huawei.com> --- fs/ext4/super.c | 1 + fs/inode.c | 5 - 2 files changed, 5 inserti

[RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

ifficulty of locating problems. This patch avoid inode->i_nlink reverse and remove the inode form the orphan list when destroy it if the list is not empty. Signed-off-by: yi zhang --- fs/ext4/super.c | 1 + fs/inode.c | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) diff --g

[PATCH] base: dd: don't remove driver_data in -EPROBE_DEFER case

the driver_data may be used for sanity check, it fails the probe() if driver_data is NULL after it is re-triggered. for example, soc_probe() in sound/soc/soc-core.c Signed-off-by: Yi Zhang <yizhang_h...@163.com> --- drivers/base/dd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH] base: dd: don't remove driver_data in -EPROBE_DEFER case

the driver_data may be used for sanity check, it fails the probe() if driver_data is NULL after it is re-triggered. for example, soc_probe() in sound/soc/soc-core.c Signed-off-by: Yi Zhang --- drivers/base/dd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/base

Re: [PATCH V2 2/2] mfd: 88pm88x: initialize 88pm886/88pm880 base support

On Wed, Jul 01, 2015 at 01:20:18PM +0100, Lee Jones wrote: > On Fri, 26 Jun 2015, Yi Zhang wrote: > > On Thu, Jun 25, 2015 at 09:32:48AM +0100, Lee Jones wrote: > > > On Fri, 12 Jun 2015, Yi Zhang wrote: > > > > > > > 88pm886 and 88pm880 are combo PMIC c

Re: [PATCH V2 2/2] mfd: 88pm88x: initialize 88pm886/88pm880 base support

On Wed, Jul 01, 2015 at 01:20:18PM +0100, Lee Jones wrote: On Fri, 26 Jun 2015, Yi Zhang wrote: On Thu, Jun 25, 2015 at 09:32:48AM +0100, Lee Jones wrote: On Fri, 12 Jun 2015, Yi Zhang wrote: 88pm886 and 88pm880 are combo PMIC chip, which integrates regulator, onkey, rtc, gpadc

Re: [PATCH V2 2/2] mfd: 88pm88x: initialize 88pm886/88pm880 base support

On Thu, Jun 25, 2015 at 09:32:48AM +0100, Lee Jones wrote: > On Fri, 12 Jun 2015, Yi Zhang wrote: > > > 88pm886 and 88pm880 are combo PMIC chip, which integrates > > regulator, onkey, rtc, gpadc, charger, fuelgauge function; > > > > this patch add the basic su

Re: [PATCH-v4 1/3] mfd: 88pm800: Add device tree support

On Fri, Jun 26, 2015 at 11:29:29AM +0530, Vaibhav Hiremath wrote: > > > On Friday 26 June 2015 11:23 AM, Yi Zhang wrote: > >On Thu, Jun 25, 2015 at 08:57:49PM +0530, Vaibhav Hiremath wrote: > >> > >> > >>On Thursday 25 June 2015 08:18 PM, Lee Jone

Re: [PATCH-v4 3/3] mfd: devicetree: bindings: Add new 88pm800 mfd binding

On Thu, Jun 25, 2015 at 03:26:29PM +0800, Vaibhav Hiremath wrote: > With addition of DT support to 88pm800 mfd driver, this patch > adds new DT binding documentation along with respective properties. > > Signed-off-by: Vaibhav Hiremath > --- > Documentation/devicetree/bindings/mfd/88pm800.txt |

Re: [PATCH-v4 3/3] mfd: devicetree: bindings: Add new 88pm800 mfd binding

On Thu, Jun 25, 2015 at 03:26:29PM +0800, Vaibhav Hiremath wrote: With addition of DT support to 88pm800 mfd driver, this patch adds new DT binding documentation along with respective properties. Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org ---

Re: [PATCH-v4 1/3] mfd: 88pm800: Add device tree support

On Fri, Jun 26, 2015 at 11:29:29AM +0530, Vaibhav Hiremath wrote: On Friday 26 June 2015 11:23 AM, Yi Zhang wrote: On Thu, Jun 25, 2015 at 08:57:49PM +0530, Vaibhav Hiremath wrote: On Thursday 25 June 2015 08:18 PM, Lee Jones wrote: On Thu, 25 Jun 2015, Vaibhav Hiremath wrote

Re: [PATCH V2 2/2] mfd: 88pm88x: initialize 88pm886/88pm880 base support

On Thu, Jun 25, 2015 at 09:32:48AM +0100, Lee Jones wrote: On Fri, 12 Jun 2015, Yi Zhang wrote: 88pm886 and 88pm880 are combo PMIC chip, which integrates regulator, onkey, rtc, gpadc, charger, fuelgauge function; this patch add the basic support for them, adding related resource

Re: [PATCH-v4 1/3] mfd: 88pm800: Add device tree support

On Thu, Jun 25, 2015 at 08:57:49PM +0530, Vaibhav Hiremath wrote: > > > On Thursday 25 June 2015 08:18 PM, Lee Jones wrote: > >On Thu, 25 Jun 2015, Vaibhav Hiremath wrote: > >>On Thursday 25 June 2015 03:49 PM, Lee Jones wrote: > >>>On Thu, 25 Jun 2015, Vaibhav Hiremath wrote: > >>> > Add DT

Re: [PATCH V2 1/2] mfd: add Marvell 88pm88x description

On Tue, Jun 23, 2015 at 08:16:01PM +0530, Vaibhav Hiremath wrote: > > > On Tuesday 23 June 2015 08:01 PM, Rob Herring wrote: > >On Fri, Jun 12, 2015 at 3:43 AM, Yi Zhang wrote: > >>88pm880 and 88pm886 are two combo PMIC chips, most of the function and the > >

Re: [PATCH V2 1/2] mfd: add Marvell 88pm88x description

On Tue, Jun 23, 2015 at 09:31:00AM -0500, Rob Herring wrote: > On Fri, Jun 12, 2015 at 3:43 AM, Yi Zhang wrote: > > 88pm880 and 88pm886 are two combo PMIC chips, most of the function and the > > register mapping are the same > > How do they compare to 80x/822/860 PMICs?

Re: [PATCH-v4 1/3] mfd: 88pm800: Add device tree support

On Thu, Jun 25, 2015 at 08:57:49PM +0530, Vaibhav Hiremath wrote: On Thursday 25 June 2015 08:18 PM, Lee Jones wrote: On Thu, 25 Jun 2015, Vaibhav Hiremath wrote: On Thursday 25 June 2015 03:49 PM, Lee Jones wrote: On Thu, 25 Jun 2015, Vaibhav Hiremath wrote: Add DT support to the

Re: [PATCH V2 1/2] mfd: add Marvell 88pm88x description

On Tue, Jun 23, 2015 at 09:31:00AM -0500, Rob Herring wrote: On Fri, Jun 12, 2015 at 3:43 AM, Yi Zhang yizh...@marvell.com wrote: 88pm880 and 88pm886 are two combo PMIC chips, most of the function and the register mapping are the same How do they compare to 80x/822/860 PMICs? Hi, Rob

Re: [PATCH V2 1/2] mfd: add Marvell 88pm88x description

On Tue, Jun 23, 2015 at 08:16:01PM +0530, Vaibhav Hiremath wrote: On Tuesday 23 June 2015 08:01 PM, Rob Herring wrote: On Fri, Jun 12, 2015 at 3:43 AM, Yi Zhang yizh...@marvell.com wrote: 88pm880 and 88pm886 are two combo PMIC chips, most of the function and the register mapping

Re: [PATCH V2 0/2] add basic support to Marvell 88pm880/88pm886 PMIC chip

On Fri, Jun 12, 2015 at 04:43:19PM +0800, Yi Zhang wrote: Hi, Samuel and Lee: Could you please share your comments on this patch? then I can modify accordingly; thanks very much; > - 88pm880 and 88pm886 are PMIC chips which integrates regulator, > gpadc, charger, fuelgaug

Re: [PATCH V2 0/2] add basic support to Marvell 88pm880/88pm886 PMIC chip

On Fri, Jun 12, 2015 at 04:43:19PM +0800, Yi Zhang wrote: Hi, Samuel and Lee: Could you please share your comments on this patch? then I can modify accordingly; thanks very much; - 88pm880 and 88pm886 are PMIC chips which integrates regulator, gpadc, charger, fuelgauge, etc

[PATCH V2 1/2] mfd: add Marvell 88pm88x description

88pm880 and 88pm886 are two combo PMIC chips, most of the function and the register mapping are the same Signed-off-by: Yi Zhang --- Documentation/devicetree/bindings/mfd/88pm88x.txt | 33 +++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree

[PATCH V2 2/2] mfd: 88pm88x: initialize 88pm886/88pm880 base support

88pm886 and 88pm880 are combo PMIC chip, which integrates regulator, onkey, rtc, gpadc, charger, fuelgauge function; this patch add the basic support for them, adding related resource, such as interrupt, preparing for the client-device driver Signed-off-by: Yi Zhang --- drivers/mfd/88pm880

[PATCH V2 0/2] add basic support to Marvell 88pm880/88pm886 PMIC chip

- 88pm880 and 88pm886 are PMIC chips which integrates regulator, gpadc, charger, fuelgauge, etc; they share most of the functions and register mapping - this version removes the redundant EXPORT_SYMBOL_GPL, compared with the first version Yi Zhang (2): mfd: add Marvell

[PATCH V2 0/2] add basic support to Marvell 88pm880/88pm886 PMIC chip

- 88pm880 and 88pm886 are PMIC chips which integrates regulator, gpadc, charger, fuelgauge, etc; they share most of the functions and register mapping - this version removes the redundant EXPORT_SYMBOL_GPL, compared with the first version Yi Zhang (2): mfd: add Marvell

[PATCH V2 2/2] mfd: 88pm88x: initialize 88pm886/88pm880 base support

88pm886 and 88pm880 are combo PMIC chip, which integrates regulator, onkey, rtc, gpadc, charger, fuelgauge function; this patch add the basic support for them, adding related resource, such as interrupt, preparing for the client-device driver Signed-off-by: Yi Zhang yizh...@marvell.com

[PATCH V2 1/2] mfd: add Marvell 88pm88x description

88pm880 and 88pm886 are two combo PMIC chips, most of the function and the register mapping are the same Signed-off-by: Yi Zhang yizh...@marvell.com --- Documentation/devicetree/bindings/mfd/88pm88x.txt | 33 +++ 1 file changed, 33 insertions(+) create mode 100644

Re: [PATCH 2/2] mfd: 88pm88x: initial 88pm886/88pm880 base support

On Tue, Jun 09, 2015 at 02:14:11PM +0200, Paul Bolle wrote: Hi, Paul: Thanks very much for your review; > On Mon, 2015-06-08 at 20:55 +0800, Yi Zhang wrote: > > --- /dev/null > > +++ b/drivers/mfd/88pm880-table.c > > > +#include > > I'm _guessing_ this co

Re: [PATCH 2/2] mfd: 88pm88x: initial 88pm886/88pm880 base support

On Tue, Jun 09, 2015 at 02:14:11PM +0200, Paul Bolle wrote: Hi, Paul: Thanks very much for your review; On Mon, 2015-06-08 at 20:55 +0800, Yi Zhang wrote: --- /dev/null +++ b/drivers/mfd/88pm880-table.c +#include linux/module.h I'm _guessing_ this could as well be linux/export.h

[PATCH 1/2] mfd: add Marvell 88pm88x description

88pm880 and 88pm886 are two combo PMIC chips, most of the function and the register mapping are the same Signed-off-by: Yi Zhang --- Documentation/devicetree/bindings/mfd/88pm88x.txt | 33 +++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree

[PATCH 2/2] mfd: 88pm88x: initial 88pm886/88pm880 base support

88pm886 and 88pm880 are combo PMIC chip, which integrates regulator, onkey, rtc, gpadc, charger, fuelgauge function; this patch add the basic support for them, adding related resource, such as interrupt, preparing for the client-device driver Signed-off-by: Yi Zhang --- drivers/mfd/88pm880

[PATCH 1/2] mfd: add Marvell 88pm88x description

88pm880 and 88pm886 are two combo PMIC chips, most of the function and the register mapping are the same Signed-off-by: Yi Zhang yizh...@marvell.com --- Documentation/devicetree/bindings/mfd/88pm88x.txt | 33 +++ 1 file changed, 33 insertions(+) create mode 100644

[PATCH 2/2] mfd: 88pm88x: initial 88pm886/88pm880 base support

88pm886 and 88pm880 are combo PMIC chip, which integrates regulator, onkey, rtc, gpadc, charger, fuelgauge function; this patch add the basic support for them, adding related resource, such as interrupt, preparing for the client-device driver Signed-off-by: Yi Zhang yizh...@marvell.com

Re:Re: [Question] should we export set_suspend_voltage()?

At 2015-02-07 06:10:58, "Mark Brown" wrote: >On Fri, Feb 06, 2015 at 10:57:49AM +0800, Yi Zhang wrote: > >Please fix your mailer to word wrap within paragraphs, your mail is very >difficult to read and reply to. > Thanks Mark for pointing this out; >> d

Re:Re: [Question] should we export set_suspend_voltage()?

At 2015-02-07 06:10:58, Mark Brown broo...@kernel.org wrote: On Fri, Feb 06, 2015 at 10:57:49AM +0800, Yi Zhang wrote: Please fix your mailer to word wrap within paragraphs, your mail is very difficult to read and reply to. Thanks Mark for pointing this out; do you think it's good to export

[Question] should we export set_suspend_voltage()?

Hi, Liam & Mark: seems at present, the set_suspend_voltage() is designed to cover the suspend voltage handling from board level, when the system enters into the suspend; but the behavior of my chip is as following: a) there are two sets of registers to configure one regulator's voltage

[Question] should we export set_suspend_voltage()?

Hi, Liam Mark: seems at present, the set_suspend_voltage() is designed to cover the suspend voltage handling from board level, when the system enters into the suspend; but the behavior of my chip is as following: a) there are two sets of registers to configure one regulator's voltage

[Question] is it a race condition in acking PMIC sub-interrupt?

Hi, Mark: Sorry to trouble you, I met a question related the interrupt ack sequence in regmap framework; could you please share your advice on this? thank you very much; 1) the following is the connection related to PMIC on my development board: PMIC ---> GPIO --> GIC the GPIO is

[Question] is it a race condition in acking PMIC sub-interrupt?

Hi, Mark: Sorry to trouble you, I met a question related the interrupt ack sequence in regmap framework; could you please share your advice on this? thank you very much; 1) the following is the connection related to PMIC on my development board: PMIC --- GPIO -- GIC the GPIO is edge

Re: [Question] Should we make the primary interrupt handler configurable for regmap_add_irq_chip()?

2014/1/15 Mark Brown : > On Sat, Jan 11, 2014 at 12:15:21PM +0800, Yi Zhang wrote: > >> I met a scenario: >> As soon as the interrupt is triggered, a wakelock is needed to be held >> until the threaded handler finishes, >> I think we may hold it in the primary i

Re: [Question] Should we make the primary interrupt handler configurable for regmap_add_irq_chip()?

2014/1/15 Mark Brown broo...@kernel.org: On Sat, Jan 11, 2014 at 12:15:21PM +0800, Yi Zhang wrote: I met a scenario: As soon as the interrupt is triggered, a wakelock is needed to be held until the threaded handler finishes, I think we may hold it in the primary interrupt handler, but now

[Question] Should we make the primary interrupt handler configurable for regmap_add_irq_chip()?

Hi, Mark: Sorry to trouble you; I have a question about the regmap_add_irq_chip(): at present, we use the default primary interrupt handler to handle the parent interrupt from a mfd device; I met a scenario: As soon as the interrupt is triggered, a wakelock is needed to be held until the

[Question] Should we make the primary interrupt handler configurable for regmap_add_irq_chip()?

Hi, Mark: Sorry to trouble you; I have a question about the regmap_add_irq_chip(): at present, we use the default primary interrupt handler to handle the parent interrupt from a mfd device; I met a scenario: As soon as the interrupt is triggered, a wakelock is needed to be held until the

[PATCH v3] regmap: irq: clear status when disable irq

is not cleared), and it's ignored; 4) if the irq is still asserted because of the uncleared status bit, the irq storm happens; Signed-off-by: Yi Zhang --- drivers/base/regmap/regmap-irq.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/base/regmap/regmap

[PATCH v3] regmap: irq: clear status when disable irq

is not cleared), and it's ignored; 4) if the irq is still asserted because of the uncleared status bit, the irq storm happens; Signed-off-by: Yi Zhang yizh...@marvell.com --- drivers/base/regmap/regmap-irq.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers

[PATCH v2] regmap: irq: clear status when disable irq

is not cleared), and it's ignored; 4) if the irq is still asserted because of the uncleared status bit, the irq storm happens; Signed-off-by: Yi Zhang --- drivers/base/regmap/regmap-irq.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git

Re: [PATCH] regmap: irq: clear status when disable irq

2013/10/15 Mark Brown : > On Tue, Oct 15, 2013 at 01:03:58PM +0800, Yi Zhang wrote: > >> + bits_length = d->map->format.val_bytes * BITS_PER_BYTE; >> + for (j = 0; j < bits_length; j++) { >> +

Re: [PATCH] regmap: irq: clear status when disable irq

2013/10/15 Mark Brown broo...@kernel.org: On Tue, Oct 15, 2013 at 01:03:58PM +0800, Yi Zhang wrote: + bits_length = d-map-format.val_bytes * BITS_PER_BYTE; + for (j = 0; j bits_length; j++) { + d-mask_buf[i] = (0x1 j); Yes

[PATCH v2] regmap: irq: clear status when disable irq

is not cleared), and it's ignored; 4) if the irq is still asserted because of the uncleared status bit, the irq storm happens; Signed-off-by: Yi Zhang yizh...@marvell.com --- drivers/base/regmap/regmap-irq.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion

[PATCH] regmap: irq: clear status when disable irq

is not cleared), and it's ignored; 4) if the irq is still asserted because of the uncleared status bit, the irq storm happens; Signed-off-by: Yi Zhang --- drivers/base/regmap/regmap-irq.c | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git

Re: [PATCH] regmap: irq: clear status when disable irq

2013/10/14 Mark Brown : > On Mon, Oct 14, 2013 at 12:23:53PM +0800, Yi Zhang wrote: > >> Change-Id: I371201f365c5a8470073a393068cfeb4e3d14a03 > > Don't include noise like this in upstream submissions. > Thanks Mark, it's my fault; I'll remove it; >> + /* Ac

Re: [PATCH] regmap: irq: clear status when disable irq

2013/10/14 Mark Brown broo...@kernel.org: On Mon, Oct 14, 2013 at 12:23:53PM +0800, Yi Zhang wrote: Change-Id: I371201f365c5a8470073a393068cfeb4e3d14a03 Don't include noise like this in upstream submissions. Thanks Mark, it's my fault; I'll remove it; + /* Ack masked but set

[PATCH] regmap: irq: clear status when disable irq

is not cleared), and it's ignored; 4) if the irq is still asserted because of the uncleared status bit, the irq storm happens; Signed-off-by: Yi Zhang yizh...@marvell.com --- drivers/base/regmap/regmap-irq.c | 26 +- 1 file changed, 25 insertions(+), 1 deletion

[PATCH] regmap: irq: clear status when disable irq

is not cleared), and it's ignored; 4) if the irq is still asserted because of the uncleared status bit, the irq storm happens; Change-Id: I371201f365c5a8470073a393068cfeb4e3d14a03 Signed-off-by: Yi Zhang --- drivers/base/regmap/regmap-irq.c | 21 + 1 file changed, 21

[PATCH] regmap: irq: clear status when disable irq

is not cleared), and it's ignored; 4) if the irq is still asserted because of the uncleared status bit, the irq storm happens; Change-Id: I371201f365c5a8470073a393068cfeb4e3d14a03 Signed-off-by: Yi Zhang yizh...@marvell.com --- drivers/base/regmap/regmap-irq.c | 21

Re: [Question]should we not ignore the masked interrupt in regmap?

2013/10/12 Mark Brown : > On Sat, Oct 12, 2013 at 11:14:27AM +0800, yi zhang wrote: > >> 1) interrupt is triggered; >> 2) a thread disables it(then the mask bit is set); >> 3) _Then_ the interrupt thread is executed, it _ignore _ and doesn’t >> handle this interrup

Re: [Question]should we not ignore the masked interrupt in regmap?

2013/10/12 Mark Brown broo...@kernel.org: On Sat, Oct 12, 2013 at 11:14:27AM +0800, yi zhang wrote: 1) interrupt is triggered; 2) a thread disables it(then the mask bit is set); 3) _Then_ the interrupt thread is executed, it _ignore _ and doesn’t handle this interrupt; because

[Question]should we not ignore the masked interrupt in regmap?

because the interrupt is not ACKed, the interrupt status is not cleared; 4) in Marvell's PMIC, the interrupt line to SOC is always asserted, then irq storm happens; -------- Yi Zhang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

[Question]should we not ignore the masked interrupt in regmap?

the interrupt is not ACKed, the interrupt status is not cleared; 4) in Marvell's PMIC, the interrupt line to SOC is always asserted, then irq storm happens; Yi Zhang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: [PATCH] regulator: 88pm800: add regulator driver

HI, Brown: 2013/5/26 Mark Brown : > On Fri, May 24, 2013 at 11:01:45AM +0800, yi zhang wrote: >> 2013/5/23 Mark Brown : >> > On Wed, May 22, 2013 at 08:10:53PM +0800, yizhang.m...@gmail.com wrote: > >> >> +static const unsigned int BUCK1_table[] = { >> >

  1   2   >