Re: [PATCH 1/1] dpt_i2o: delete unnecessary null test on array

2014-08-09 Thread Julia Lawall
From nobody Sat Aug  9 08:17:15 CEST 2014
From: Julia Lawall julia.law...@lip6.fr
To: Adaptec OEM Raid Solutions aacr...@adaptec.com
Cc: James E.J. Bottomley 
jbottom...@parallels.com,linux-scsi@vger.kernel.org,linux-ker...@vger.kernel.org
Subject: [PATCH] dpt_i2o: delete unnecessary null test on array

From: Julia Lawall julia.law...@lip6.fr

Convert a NULL test on an array to a NULL test on its element.  Delete a
redundant test and clean up the code a little.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@r@
type T;
T [] e;
position p;
@@
e ==@p NULL

@ disable fld_to_ptr@
expression e;
identifier f;
position r.p;
@@
* e.f ==@p NULL
// /smpl

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
v2: Test instead the array element, and clean up the code a bit.

 drivers/scsi/dpt_i2o.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 67283ef..4647c93 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -1169,15 +1169,14 @@ static struct adpt_device* adpt_find_device(adpt_hba* 
pHba, u32 chan, u32 id, u6
if(chan  0 || chan = MAX_CHANNEL)
return NULL;

-   if( pHba-channel[chan].device == NULL){
-   printk(KERN_DEBUGAdaptec I2O RAID: Trying to find device 
before they are allocated\n);
+   d = pHba-channel[chan].device[id];
+   if (!d) {
+   printk(KERN_DEBUG Adaptec I2O RAID: Trying to find device 
before they are allocated\n);
return NULL;
}
 
-   d = pHba-channel[chan].device[id];
-   if(!d || d-tid == 0) {
+   if (d-tid == 0)
return NULL;
-   }
 
/* If it is the only lun at that address then this should match*/
if(d-scsi_lun == lun){

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/4] driver core: enable drivers to use deferred probe from init

2014-08-09 Thread Luis R. Rodriguez
On Wed, Jul 30, 2014 at 03:11:07PM -0700, David Miller wrote:
 From: Luis R. Rodriguez mcg...@do-not-panic.com
 Date: Mon, 28 Jul 2014 11:28:28 -0700
 
  Tetsuo bisected and found that commit 786235ee kthread: make
  kthread_create() killable modified kthread_create() to bail as
  soon as SIGKILL is received. This is causing some issues with
  some drivers and at times boot. Joseph then found that failures
  occur as the systemd-udevd process sends SIGKILL to modprobe if
  probe on a driver takes over 30 seconds. When this happens probe
  will fail on any driver, its why booting on some system will fail
  if the driver happens to be a storage related driver. Some folks
  have suggested fixing this by modifying kthread_create() to not
  leave upon SIGKILL [3], upon review Oleg rejected this change and
  the discussion was punted out to systemd to see if the default
  timeout could be increased from 30 seconds to 120. The opinion of
  the systemd maintainers is that the driver's behavior should
  be fixed [4]. Linus seems to agree [5], however more recently even
  networking drivers have been reported to fail on probe since just
  writing the firmware to a device and kicking it can take easy over
  60 seconds [6]. Benjamim was able to trace the issues recently
  reported on cxgb4 down to the same systemd-udevd 30 second timeout [6].
  
  This is an alternative solution which enables drivers that are
  known to take long to use deferred probe workqueue. This avoids
  the 30 second timeout and lets us annotate drivers with long
  init sequences.
  
  As drivers determine a component is not yet available and needs
  to defer probe you'll be notified this happen upon init for each
  device but now with a message such as:
  
  pci :03:00.0: Driver cxgb4 requests probe deferral on init
  
  You should see one of these per struct device probed.
 
 It seems we're still discussing this.
 
 I think I understand all of the underlying issues, and what I'll say
 is that perhaps we should use what Greg KH requested but via a helper
 that is easy to grep for.
 
 I don't care if it's something like module_long_probe_init() and
 module_long_probe_exit(), but it just needs to be some properly
 named interface which does the whole kthread or whatever bit.

I've tested the alternative kthread_run() proposal but unfortunately it
does not help resolve the issue, the timeout is still hit and a SIGKILL
still kills the driver probe. Please let me know how you'd all like us
to proceed, these defer probe patches do help cure the issue though.

I should also note that these work around patches can only be done once we
already know a driver fails to go over the timeout, root causing and
associating driver issues to the timeout has been very difficult with a few
drivers already, for this reason I've submitted a change for systemd to issue a
warning instead of killing kmod usage on udev after a timeout, that would make
this regression non-fatal, and let us more easily then hunt drivers that need
fixing much easily [0] [1]. As noted we'd still want to have drivers easily
annotated which require fixing, this orignal series would allow us to do that
by hunting for delay_probe. If there alternative and preferred strategies
please let me know.

[0] http://lists.freedesktop.org/archives/systemd-devel/2014-August/021812.html
[1] http://lists.freedesktop.org/archives/systemd-devel/2014-August/021821.html

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v6 2/2] arm64: Remove the clock and PHY reference from the APM X-Gene SoC AHCI SATA Host controller dts node.

2014-08-09 Thread Arnd Bergmann
On Friday 08 August 2014, Suman Tripathi wrote:
 This patch removes all clocks and PHY references from the APM X-Gene
 SoC AHCI SATA host controller and PHY DTS nodes. The clock and PHY
 are no longer needed as they are handled by the firmware. By removing
 only the reference is not enough as any un-used clock entry will get
 disabled by the clock framework. This patch also updates the APM X-Gene
 SOC AHCI SATA Host controller clock and PHY bindings as optional
 properties.
 
 Signed-off-by: Loc Ho l...@apm.com
 Signed-off-by: Suman Tripathi stripa...@apm.com
 ---
  .../devicetree/bindings/ata/apm-xgene.txt  | 10 +--
  arch/arm64/boot/dts/apm-storm.dtsi | 93 
 --
  2 files changed, 5 insertions(+), 98 deletions(-)
 

What is the upgrade path here? It sounds like this will still break new kernels
running on old firmware if you also upgrade the dtb file. You write in the
introductory email that this will work with old firmware as well, but I don't
understand how.

How about modifying the dtb at boot time by the firmware according to the
requirements of the firmware itself?

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] message: fusion: mptbase.c: Cleaning up missing null-terminate after strncpy call

2014-08-09 Thread Rickard Strandqvist
Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
 drivers/message/fusion/mptbase.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index ebc0af7..66324f8 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -7706,8 +7706,10 @@ mpt_display_event_info(MPT_ADAPTER *ioc, 
EventNotificationReply_t *pEventReply)
ds = Unknown;
break;
}
-   if (ds)
+   if (ds) {
strncpy(evStr, ds, EVENT_DESCR_STR_SZ);
+   evStr[EVENT_DESCR_STR_SZ - 1] = '\0';
+   }
 
 
devtprintk(ioc, printk(MYIOC_s_DEBUG_FMT
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html