On Saturday, March 29, 2014 7:04 PM Rashika Kheria rashika.khe...@gmail.com
wrote:
Mark function as static in isci/phy.c because it is not used outside
this file.
This eliminates the following warning in isci/phy.c:
drivers/scsi/isci/phy.c:672:6: warning: no previous prototype for
On Saturday, March 29, 2014 7:07 PM Rashika Kheria rashika.khe...@gmail.com
wrote:
Mark function as static in isci/port.c because they are not used outside
this file.
This eliminates the following warning in isci/port.c:
drivers/scsi/isci/port.c:65:13: warning: no previous prototype for
On Saturday, March 29, 2014 7:05 PM Rashika Kheria rashika.khe...@gmail.com
wrote:
Mark function as static in isci/remote_device.c because it is not used
outside this file.
This eliminates the following warning in isci/remote_device.c:
drivers/scsi/isci/remote_device.c:1387:6: warning: no
On Monday, March 31, 2014 11:36 AM Josh Triplett j...@joshtriplett.org wrote:
On Mon, Mar 31, 2014 at 08:54:49AM +, Dorau, Lukasz wrote:
On Saturday, March 29, 2014 7:04 PM Rashika Kheria
rashika.khe...@gmail.com wrote:
Mark function as static in isci/phy.c because it is not used
On Monday, February 24, 2014 9:02 AM Alexander Gordeev agord...@redhat.com
wrote:
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or
On Tuesday, February 04, 2014 12:17 PM Alexander Gordeev agord...@redhat.com
wrote:
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and
On Thursday, January 23, 2014 10:39 AM Lukasz Dorau lukasz.do...@intel.com
wrote:
The version of isci driver has not been updated for 2 years.
It was 83 isci commits ago. Suspend/resume support has been implemented
and many bugs have been fixed since 1.1. Now update the version to 1.2.
On Monday, January 20, 2014 7:26 PM Dan Williams dan.j.willi...@intel.com
wrote:
On Mon, Jan 20, 2014 at 8:54 AM, Lukasz Dorau lukasz.do...@intel.com wrote:
In the first place, the loop 'for' in the macro 'for_each_isci_host'
(drivers/scsi/isci/host.h:314) is incorrect, because it accesses
On Thursday, January 16, 2014 2:16 PM Lukasz Dorau lukasz.do...@intel.com
wrote:
The loop 'for' in macro 'for_each_isci_host' (drivers/scsi/isci/init.c:717)
is executed more times than it can be. Regardless the condition:
'id ARRAY_SIZE(to_pci_info(pdev)-hosts)'
alexei.starovoi...@gmail.com wrote:
On Fri, Jan 17, 2014 at 5:37 AM, Dorau, Lukasz lukasz.do...@intel.com
wrote:
Hi
My story is very simply...
I applied the following patch:
diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
--- a/drivers/scsi/isci/init.c
+++ b
Hi
My story is very simply...
I applied the following patch:
diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isci/init.c
@@ -698,8 +698,11 @@ static int isci_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
On Friday, January 17, 2014 2:37 PM Dorau, Lukasz lukasz.do...@intel.com
wrote:
Hi
My story is very simply...
I applied the following patch:
diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isci/init.c
@@ -698,8
On Friday, January 17, 2014 2:58 PM Richard Weinberger
richard.weinber...@gmail.com wrote:
Can you reproduce this using a standalone test?
I.e:
#include assert.h
int main()
{
assert(2 2 != 1);
return 0;
}
No, I can't of course.
Lukasz
--
To unsubscribe from
On Friday, January 17, 2014 5:40 PM Sebastian Riemer
sebastian.rie...@profitbricks.com wrote:
On 17.01.2014 14:55, Dorau, Lukasz wrote:
Some additional information:
The loop 'for' in macro ' for_each_isci_host ' defined as
(drivers/scsi/isci/host.h:313):
#define for_each_isci_host
On Monday, December 09, 2013 8:47 PM Williams, Dan J dan.j.willi...@intel.com
wrote:
Remove an erroneous BUG_ON() in the case of a hard reset timeout. If a
SATA device is unable to restore the link in time we expect the port to
go back to the awaiting link-up state. Since the timeout path
On Sunday, September 22, 2013 12:28 AM Peter Senna Tschudin
peter.se...@gmail.com wrote:
The variable success is only assigned the values true and false.
Change its type to bool.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@exists@
On 07/19/2013 Xinghai Yu yuxing...@cn.fujitsu.com wrote:
The sci_phy_link_layer_initialization() was called only once in
sci_phy_initialize() and it is called before a call of
sci_change_state(iphy-
sm, SCI_PHY_STOPPED). So the same call in the end of
sci_phy_link_layer_initialization() is
On Wednesday, July 17, 2013 4:54 AM Xinghai Yu yuxing...@cn.fujitsu.com wrote:
It seems the phy_index++; have been placed in wrong place, without it
the while circle up will do a infinite loop.
Signed-off-by: Xinghai Yu yuxing...@cn.fujitsu.com
Acked-by: Lukasz Dorau lukasz.do...@intel.com
On Tue, 26 Mar 2013 00:01:38 -0700 Jingoo Han jg1@samsung.com wrote:
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
the
Hi James
What are you going to do with the following four ISCI patches from isci-for-3.6
tag?:
6734092e66011def7875bd67beef889d0fee1cc9isci: add a couple __iomem
annotations
67787c330762eb884bf8c169fe942263d55ec162isci: make function declaration
match implementation
20 matches
Mail list logo
