The host asks the guest to scan when a LUN is removed or added.
The only way a guest can identify the removed LUN is when an I/O is
attempted on a removed LUN - the SRB status code indicates that the LUN
is invalid. We currently handle this SRB status and remove the device.
Rather than waiting for
The virtual HBA that storvsc implements can support multiple channels and
targets. So, scan the host when the host notifies that a scan is needed.
Signed-off-by: K. Y. Srinivasan
---
drivers/scsi/storvsc_drv.c | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --
This patch-set addresses issues with LUN hot-add and remove. When the host
notifies the guest that a scan is needed, scan the host. Also, prior to
discovering new devices that may have been added, ensure we handle the
LUN remove case first.
K. Y. Srinivasan (2):
Drivers: scsi: storvsc: In respon
On Sat, Aug 16, 2014 at 4:14 PM, Rickard Strandqvist
wrote:
> 2014-08-12 16:58 GMT+02:00 Kees Cook :
>> On Sat, Aug 9, 2014 at 4:46 PM, Rickard Strandqvist
>> wrote:
>>> Added a guaranteed null-terminate after call to strncpy.
>>>
>>> Signed-off-by: Rickard Strandqvist
>>> ---
>>> drivers/stagi
2014-08-12 16:58 GMT+02:00 Kees Cook :
> On Sat, Aug 9, 2014 at 4:46 PM, Rickard Strandqvist
> wrote:
>> Added a guaranteed null-terminate after call to strncpy.
>>
>> Signed-off-by: Rickard Strandqvist
>> ---
>> drivers/staging/lustre/lustre/libcfs/workitem.c |1 +
>> 1 file changed, 1 inse
This patch fixes the following error using checkpatch.pl
Error: do not use assignment in if condition
Signed-off-by: Hema Prathaban
---
drivers/staging/lustre/lustre/libcfs/debug.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/debug
This patch fixes the following warning using checkpatch.pl
WARNING: Prefer [subsystem eg: netdev]_warn([subsystem]dev, ... then
dev_warn(dev, ... then pr_warn(... to printk(KERN_WARNING ...
Signed-off-by: Hema Prathaban
---
drivers/staging/lustre/lustre/libcfs/debug.c | 6 +++---
1 file changed
The relevant sequences consist of two I/O memory writes. The second write
depends on the first one. mmiowb() was inserted to make sure that no other
thread inserts a "first write" before the current one finished its second.
As a mutex protects this critical sequence, mmiowb() is unnecessary.
Sign
The comment (also removed) explains why it was there in the first place, but
that doesn't make much sense.
Signed-off-by: Eli Billauer
---
drivers/staging/xillybus/xillybus_core.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/xillybus/xillybus_co
mmiowb() was used to make sure that iowrite32() take place in the correct
order, which is an unnecessary precuation.
Signed-off-by: Eli Billauer
---
drivers/staging/xillybus/xillybus_core.c | 17 ++---
1 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/
According to Documentation/memory-barriers.txt, a memory barrier is put
in place by wait_event_*()
Signed-off-by: Eli Billauer
---
drivers/staging/xillybus/xillybus_core.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/xillybus/xillybus_core.c
b/drive
According to Documentation/memory-barriers.txt, a memory barrier is put
in place by wait_event_*()
Signed-off-by: Eli Billauer
---
drivers/staging/xillybus/xillybus_core.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/xillybus/xillybus_core.c
b/dri
This patchset removes several memory barriers that seem to be unnecessary.
Most of them were originally inserted in a "better safe than sorry" spirit,
but these may turn out confusing in the long run.
Each patch removes memory barriers based upon a different argument, in order
to simplify their re
These memory barriers were added "just to be safe".
Signed-off-by: Eli Billauer
---
drivers/staging/xillybus/xillybus_core.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/xillybus/xillybus_core.c
b/drivers/staging/xillybus/xillybus_core.c
index f48e
The dgnc_Major_Control_Registered variable purpose was to act as a flag
to indicate if the character device has been successfully registered
into the kernel. This flag was later checked in the module cleanup
function to know if the character device needs to be deregistered.
However the {device,cla
The dgnc_driver_start variable purpose was to indicate if the driver
'start' routine has been called. Now, because the 'start' routine can
only be called once this variable is not needed thus this commit
removes it.
Signed-off-by: Konrad Zapalowicz
---
drivers/staging/dgnc/dgnc_driver.c | 5
The polling counter variable is only exposed via sysfs and has no other
purpose.
Now, since the polling shall be implemented as a board specific feature
rather than being global in the driver this counter is obsolete.
Signed-off-by: Konrad Zapalowicz
---
drivers/staging/dgnc/dgnc_driver.c | 3
This commit removes the driver's global state variable. This is ok
because the state was changed only once at the end of init phase thus
the future usage of this variable is pointless.
Signed-off-by: Konrad Zapalowicz
---
drivers/staging/dgnc/dgnc_driver.c | 19 ---
drivers/stagi
This is the fist stage of removal of unnecessary static, global
variables of this driver.
Konrad Zapalowicz (4):
staging: dgnc: Remove driver-wide state variable
staging: dgnc: Remove driver-wide polling counter variable
staging: dgnc: Remove not needed dgnc_driver_start variable
staging:
19 matches
Mail list logo
