RE: [PATCH] storvsc: Avoid excessive host scan on controller change

> From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Monday, November 6, 2017 7:40 PM > To: Long Li > Cc: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger > ; James E . J . Bottomley >

Re: [PATCH] storvsc: Avoid excessive host scan on controller change

Long, > When there are multiple disks attached to the same SCSI controller, > the host may send several VSTOR_OPERATION_REMOVE_DEVICE or > VSTOR_OPERATION_ENUMERATE_BUS messages in a row, to indicate there is > a change on the SCSI controller. In response, storvsc rescans the SCSI > host.

Re: [REVIEW REQUEST] staging: unisys: review request for visorbus

On Mon, Nov 06, 2017 at 04:56:40PM +0300, Dan Carpenter wrote: > On Mon, Nov 06, 2017 at 07:17:11PM +1100, Tobin C. Harding wrote: > > > > @@ -260,9 +261,10 @@ int visorchannel_signalremove(struct visorchannel > > > > *channel, u32 queue, > > > > void *msg) > > > >

Re: [PATCH 3/3] staging: ccree: simplify ioread/iowrite

On Mon, Nov 06, 2017 at 04:46:54PM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 06, 2017 at 10:59:47AM +0200, Gilad Ben-Yossef wrote: > > On Mon, Nov 6, 2017 at 10:37 AM, Tobin C. Harding wrote: > > > On Mon, Nov 06, 2017 at 06:55:52AM +, Gilad Ben-Yossef wrote: > > >>

Re: [PATCH v2] staging: fsl-mc: move bus driver out of staging

>> struct dpaa2_io { >> atomic_t refs; >> >> That's a kref, please use it instead of trying to roll your own. >> >> And even for this, your locking is not correct (i.e. you do not have >> any), that needs to be fixed so that teardown works correctly. > > I think we can drop this

Re: [PATCH] storvsc: Avoid excessive host scan on controller change

On 10/31/2017 05:58 PM, Long Li wrote: From: Long Li When there are multiple disks attached to the same SCSI controller, the host may send several VSTOR_OPERATION_REMOVE_DEVICE or VSTOR_OPERATION_ENUMERATE_BUS messages in a row, to indicate there is a change on the SCSI

[PATCH v6 2/2] staging: ion: create one device entry per heap

Instead a getting only one common device "/dev/ion" for all the heaps this patch allow to create one device entry ("/dev/ionX") per heap. Getting an entry per heap could allow to set security rules per heap and global ones for all heaps. Allocation requests will be only allowed if the mask_id

[PATCH v6 0/2] staging: ion: get one device per heap

version 6: - add an ION bus so heap are show as devices in /sys/bus/ion/ instead of platform bus. - split the patch in two: one for include reordering and one for per heap device change - rebased on top of next-2017110 tag version 5: - create a configuration flag to keep legacy Ion misc

[PATCH v6 1/2] staging: ion: reorder include

Put include in alphabetic order Signed-off-by: Benjamin Gaignard --- drivers/staging/android/ion/ion.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index

Re: [PATCH 3/3] staging: ccree: simplify ioread/iowrite

On Mon, Nov 06, 2017 at 10:59:47AM +0200, Gilad Ben-Yossef wrote: > On Mon, Nov 6, 2017 at 10:37 AM, Tobin C. Harding wrote: > > On Mon, Nov 06, 2017 at 06:55:52AM +, Gilad Ben-Yossef wrote: > >> Registers ioread/iowrite operations were done via macros, > >> sometime using a

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

On Mon, Nov 06, 2017 at 03:42:04PM +0100, Benjamin Gaignard wrote: > 2017-11-02 12:10 GMT+01:00 Mark Brown : > > On Thu, Nov 02, 2017 at 11:44:07AM +0100, Greg KH wrote: > >> On Tue, Oct 31, 2017 at 07:11:53PM +, Mark Brown wrote: > > > >> > There was a discussion a while

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

2017-11-02 12:10 GMT+01:00 Mark Brown : > On Thu, Nov 02, 2017 at 11:44:07AM +0100, Greg KH wrote: >> On Tue, Oct 31, 2017 at 07:11:53PM +, Mark Brown wrote: > >> > There was a discussion a while ago in the context of I2C/SPI MFDs >> > which concluded that if you need a bus

Re: [PATCH v2] staging: fsl-mc: move bus driver out of staging

On 11/03/2017 05:17 PM, Greg KH wrote: > On Thu, Aug 31, 2017 at 06:04:30PM +0200, Greg KH wrote: >> On Mon, Aug 28, 2017 at 01:54:05PM +0300, laurentiu.tu...@nxp.com wrote: >>> From: Stuart Yoder >>> >>> Move the source files out of staging into their final locations: >>>

Re: [REVIEW REQUEST] staging: unisys: review request for visorbus

On Mon, Nov 06, 2017 at 07:17:11PM +1100, Tobin C. Harding wrote: > > > @@ -260,9 +261,10 @@ int visorchannel_signalremove(struct visorchannel > > > *channel, u32 queue, > > > void *msg) > > > { > > > int rc; > > > - unsigned long flags; > > > > > > if

Re: [RFC 05/12] dt-bindings: mtd: add Marvell NAND controller documentation

Hi Rob, > > +Required properties: > > +C'est faux, t'en a rajouté un y a pas longtps :). > > +Je conseille de mettre ça sous forme de liste, genre > > Humm. Oops! > > > + > > +- compatible: can be one of the following: > > +* "marvell,armada-8k-nand-controller" > > +*

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

2017-11-06 18:10 GMT+08:00 Vitaly Kuznetsov : > Wanpeng Li writes: > >> 2017-11-06 17:14 GMT+08:00 Vitaly Kuznetsov : >>> Wanpeng Li writes: >>> 2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

Wanpeng Li writes: > 2017-11-06 17:14 GMT+08:00 Vitaly Kuznetsov : >> Wanpeng Li writes: >> >>> 2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov : Changes since v9: - Rebase to 4.13-rc3. - Drop PATCH1

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

2017-11-06 17:14 GMT+08:00 Vitaly Kuznetsov : > Wanpeng Li writes: > >> 2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov : >>> Changes since v9: >>> - Rebase to 4.13-rc3. >>> - Drop PATCH1 as it was already taken by Greg to char-misc tree.

Re: [PATCH v3 4/4] staging: greybus: loopback: convert loopback to use generic async operations

On Mon, Nov 06, 2017 at 01:32:22AM +, Bryan O'Donoghue wrote: > Loopback has its own internal method for tracking and timing out > asynchronous operations however previous patches make it possible to use > functionality provided by operation.c to do this instead. Using the code in >

Re: [PATCH v3 2/4] staging: greybus: loopback: Fix iteration count on async path

On Mon, Nov 06, 2017 at 01:32:20AM +, Bryan O'Donoghue wrote: > Commit 12927835d211 ("greybus: loopback: Add asynchronous bi-directional > support") does what it says on the tin - namely, adds support for > asynchronous bi-directional loopback operations. > > What it neglects to do though is

Re: [PATCH v3 1/4] staging: greybus: loopback: Hold per-connection mutex across operations

On Mon, Nov 06, 2017 at 01:32:19AM +, Bryan O'Donoghue wrote: > Commit d9fb3754ecf8 ("greybus: loopback: Relax locking during loopback > operations") changes the holding of the per-connection mutex to be less > restrictive because at the time of that commit per-connection mutexes were >

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

Wanpeng Li writes: > 2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov : >> Changes since v9: >> - Rebase to 4.13-rc3. >> - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no >> functional dependencies on this patch so the series can

Re: [PATCH 3/3] staging: ccree: simplify ioread/iowrite

On Mon, Nov 6, 2017 at 10:37 AM, Tobin C. Harding wrote: > On Mon, Nov 06, 2017 at 06:55:52AM +, Gilad Ben-Yossef wrote: >> Registers ioread/iowrite operations were done via macros, >> sometime using a "magical" implicit parameter. >> >> Replace all register access with simple

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov : > Changes since v9: > - Rebase to 4.13-rc3. > - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no > functional dependencies on this patch so the series can go through a > different tree > (and it

Re: [PATCH 3/3] staging: ccree: simplify ioread/iowrite

On Mon, Nov 06, 2017 at 06:55:52AM +, Gilad Ben-Yossef wrote: > Registers ioread/iowrite operations were done via macros, > sometime using a "magical" implicit parameter. > > Replace all register access with simple inline macros. > > Signed-off-by: Gilad Ben-Yossef Hi,

Re: [REVIEW REQUEST] staging: unisys: review request for visorbus

On Mon, Nov 06, 2017 at 07:17:11PM +1100, Tobin C. Harding wrote: > On Mon, Nov 06, 2017 at 09:02:21AM +0100, gre...@linuxfoundation.org wrote: > > On Mon, Nov 06, 2017 at 03:30:48PM +1100, Tobin C. Harding wrote: > > > On Mon, Oct 02, 2017 at 05:49:52PM +0200, gre...@linuxfoundation.org > > >

Re: [REVIEW REQUEST] staging: unisys: review request for visorbus

On Mon, Nov 06, 2017 at 09:02:21AM +0100, gre...@linuxfoundation.org wrote: > On Mon, Nov 06, 2017 at 03:30:48PM +1100, Tobin C. Harding wrote: > > On Mon, Oct 02, 2017 at 05:49:52PM +0200, gre...@linuxfoundation.org wrote: > > > On Mon, Oct 02, 2017 at 03:41:42PM +, Kershner, David A wrote: >

Re: [REVIEW REQUEST] staging: unisys: review request for visorbus

On Mon, Nov 06, 2017 at 03:30:48PM +1100, Tobin C. Harding wrote: > On Mon, Oct 02, 2017 at 05:49:52PM +0200, gre...@linuxfoundation.org wrote: > > On Mon, Oct 02, 2017 at 03:41:42PM +, Kershner, David A wrote: > > > Hey Greg, we think the code for visorbus is ready to be moved out > > > of