solar lala shared photos with you
Dear sir We supply solar PV system (including solar panels , frame, cable ,inverter and controller , power distribution cabinet) with 1.6$/w FOB shenzhen. Email me or just call me directly if needed. Thank you! Best wishes lala Ecosol PV Tech Co., Ltd Tel: 86-769-8279 2468 Fax: 86-769-879 2478 email:i...@ecsolsolar.com skype:solarlala msn:solarl...@hotmail.com www.ecsolsolar.com <>
Re: [PATCH V2 3/4] [SCSI] ufs: Add Platform glue driver for ufshcd
2012/7/17 vinayak holikatti :
> On Mon, Jul 16, 2012 at 7:19 PM, Namjae Jeon wrote:
>> Hi Vinayak.
>>> + * ufshcd_pltfrm_remove - remove platform driver routine
>>> + * @pdev: pointer to platform device handle
>>> + *
>>> + * Returns 0 on success, non-zero value on failure
>>> + */
>>> +static int __devexit ufshcd_pltfrm_remove(struct platform_device *pdev)
>>> +{
>>> + struct resource *mem_res;
>>> + struct resource *irq_res;
>>> + resource_size_t mem_size;
>>> + struct ufs_hba *hba = platform_get_drvdata(pdev);
>>> +
>>> + ufshcd_remove(hba);
>>> + irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>>> + if (!irq_res)
>>> + dev_err(&pdev->dev, "ufshcd: IRQ resource not available\n");
>>> + free_irq(irq_res->start, hba);
>> Is there no possibility of null pointer dereferencing error ?(irq_res->start)
>> I think that free_irq should be not called if irq_res is NULL.
> I agree, I have overlooked at this logic, the free_irq should have
> been in the else
> part of this section. I will make the modification in the next version
> of patches.
Okay.
You can add my
Reviewed-by: Namjae Jeon
in these patchset
Thanks.
>>> + mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> Looks mem_res is also same with upper case.
>> Thanks.
>>> + mem_size = resource_size(mem_res);
>>> + release_mem_region(mem_res->start, mem_size);
>>> + platform_set_drvdata(pdev, NULL);
>>> + return 0;
>>> +}
>>> +
--
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 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
On Mon, Jul 16, 2012 at 9:52 PM, Arnd Bergmann wrote: > On Monday 16 July 2012, James Bottomley wrote: >> On Fri, 2012-07-13 at 15:45 +, Arnd Bergmann wrote: >> > On Friday 13 July 2012, Vinayak Holikatti wrote: >> > > This patch set adds following features >> > > - Seprates PCI specific code from ufshcd.c to make it as core >> > > - Adds PCI glue driver ufshcd-pci.c >> > > - Adds Platform glue driver ufshcd-pltfrm.c >> > > - Update correct transfer size in Command UPIU >> > >> > Acked-by: Arnd Bergmann >> >> I need a maintainer ack for this to go upstream. >> >> Also, looking at this, I think this patch series isn't bisectable: >> Patch 1 removes PCI support and patch 2 adds it back in a different >> form. However, any PCI based UFS system would stop working if the >> bisect landed at patch 1. I think you can fix this just by combining >> patches 1 and 2. > > I suggested to split the patch in two in a private review that we > did on the linaro mailing list. I gave my Ack because the split > was done, but I failed to notice that it was done differently > from what I suggested in > > On Monday 02 July 2012, Arnd Bergmann wrote: >> I would recommend that you split this patch into two separate >> changesets, where you do all the changes to existing code in the >> first patch, and only move but don't change code in the second one >> that creates the new file. > > I agree that breaking bisectibility by ripping out the PCI code > first is not good. The version 2 is not actually easier to review > at all than the first version, it just splits the changes by > file, which is pointless. I will roll out another patch series which will address the current issue. Firstly will modify existing code with PCI code and then in the second move the code to new file ufshcd-pci.c > > 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
[RESEND] [PATCH] [SCSI] mptfusion: Fix for issue - The device is removed in blocked state
Fix for issue - The device is removed in blocked state.
The device is set to blocked state when I/Os running and the cable is pulled.
Also if the device missing delay timer is started. When the device missing
delay timer expires, the device is removed but the device state is not set to
unblocked state. This will cause problems if there are commands in block
queue.
To fix this issue, added code to unblock the device before removing it.
Signed-off-by: Sreekanth Reddy
Cc:
---
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 551262e..4d02d5d 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -1088,7 +1088,13 @@ mptsas_target_reset(MPT_ADAPTER *ioc, u8 channel, u8 id)
static void
mptsas_block_io_sdev(struct scsi_device *sdev, void *data)
{
- scsi_device_set_state(sdev, SDEV_BLOCK);
+ scsi_internal_device_block(sdev);
+}
+
+static void
+mptsas_ublock_io_sdev(struct scsi_device *sdev, void *data)
+{
+ scsi_internal_device_unblock(sdev);
}
static void
@@ -1098,6 +1104,13 @@ mptsas_block_io_starget(struct scsi_target *starget)
starget_for_each_device(starget, NULL, mptsas_block_io_sdev);
}
+static void
+mptsas_ublock_io_starget(struct scsi_target *starget)
+{
+ if (starget)
+ starget_for_each_device(starget, NULL, mptsas_ublock_io_sdev);
+}
+
/**
* mptsas_target_reset_queue
*
@@ -1502,6 +1515,7 @@ mptsas_del_end_device(MPT_ADAPTER *ioc, struct
mptsas_phyinfo *phy_info)
char *ds = NULL;
u8 fw_id;
u64 sas_address;
+ VirtTarget *vtarget;
if (!phy_info)
return;
@@ -1545,6 +1559,13 @@ mptsas_del_end_device(MPT_ADAPTER *ioc, struct
mptsas_phyinfo *phy_info)
phy_info->attached.id, phy_info->attached.phy_id,
(unsigned long long) sas_address);
+ vtarget = mptsas_find_vtarget(ioc,
+phy_info->attached.channel, phy_info->attached.id);
+ if (vtarget && vtarget->deleted == 1) {
+ mptsas_ublock_io_starget(vtarget->starget);
+ vtarget->deleted = 0; /* unblock IO */
+ }
+
port = mptsas_get_port(phy_info);
if (!port) {
dfailprintk(ioc, printk(MYIOC_s_ERR_FMT
diff --git a/drivers/message/fusion/mptsas.h b/drivers/message/fusion/mptsas.h
index 57e86ab..1567f57 100644
--- a/drivers/message/fusion/mptsas.h
+++ b/drivers/message/fusion/mptsas.h
@@ -189,4 +189,7 @@ struct mptsas_enclosure {
};
/*}-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
+
+extern int scsi_internal_device_block(struct scsi_device *sdev);
+extern int scsi_internal_device_unblock(struct scsi_device *sdev);
#endif
--
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
Fix for issue - The device is removed in blocked state
Fix for issue - The device is removed in blocked state.
The device is set to blocked state when I/Os running and the cable is pulled.
Also if the device missing delay timer is started. When the device missing
delay timer expires, the device is removed but the device state is not set to
unblocked state. This will cause problems if there are commands in block
queue.
To fix this issue, added code to unblock the device before removing it.
Signed-off-by: Sreekanth Reddy
Cc:
---
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 551262e..4d02d5d 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -1088,7 +1088,13 @@ mptsas_target_reset(MPT_ADAPTER *ioc, u8 channel, u8 id)
static void
mptsas_block_io_sdev(struct scsi_device *sdev, void *data)
{
- scsi_device_set_state(sdev, SDEV_BLOCK);
+ scsi_internal_device_block(sdev);
+}
+
+static void
+mptsas_ublock_io_sdev(struct scsi_device *sdev, void *data)
+{
+ scsi_internal_device_unblock(sdev);
}
static void
@@ -1098,6 +1104,13 @@ mptsas_block_io_starget(struct scsi_target *starget)
starget_for_each_device(starget, NULL, mptsas_block_io_sdev);
}
+static void
+mptsas_ublock_io_starget(struct scsi_target *starget)
+{
+ if (starget)
+ starget_for_each_device(starget, NULL, mptsas_ublock_io_sdev);
+}
+
/**
* mptsas_target_reset_queue
*
@@ -1502,6 +1515,7 @@ mptsas_del_end_device(MPT_ADAPTER *ioc, struct
mptsas_phyinfo *phy_info)
char *ds = NULL;
u8 fw_id;
u64 sas_address;
+ VirtTarget *vtarget;
if (!phy_info)
return;
@@ -1545,6 +1559,13 @@ mptsas_del_end_device(MPT_ADAPTER *ioc, struct
mptsas_phyinfo *phy_info)
phy_info->attached.id, phy_info->attached.phy_id,
(unsigned long long) sas_address);
+ vtarget = mptsas_find_vtarget(ioc,
+phy_info->attached.channel, phy_info->attached.id);
+ if (vtarget && vtarget->deleted == 1) {
+ mptsas_ublock_io_starget(vtarget->starget);
+ vtarget->deleted = 0; /* unblock IO */
+ }
+
port = mptsas_get_port(phy_info);
if (!port) {
dfailprintk(ioc, printk(MYIOC_s_ERR_FMT
diff --git a/drivers/message/fusion/mptsas.h b/drivers/message/fusion/mptsas.h
index 57e86ab..1567f57 100644
--- a/drivers/message/fusion/mptsas.h
+++ b/drivers/message/fusion/mptsas.h
@@ -189,4 +189,7 @@ struct mptsas_enclosure {
};
/*}-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
+
+extern int scsi_internal_device_block(struct scsi_device *sdev);
+extern int scsi_internal_device_unblock(struct scsi_device *sdev);
#endif
--
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: [RFC-v2 0/4] tcm_vhost+cmwq fabric driver code for-3.6
Il 19/07/2012 09:28, James Bottomley ha scritto: >> > INQUIRY responses (at least vendor/product/type) should not change. > INQUIRY responses often change for arrays because a firmware upgrade > enables new features and new features have to declare themselves, > usually in the INQUIRY data. What you mean, I think, is that previously > exposed features in INQUIRY data, as well as strings > (vendor/product/type, as you say), shouldn't change, but unexposed data > (read 0 in the fields) may. What I meant is that it's unlikely that Windows fingerprinting is using anything but vendor/product/type, because everything else can change. Paolo -- 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: [RFC-v2 0/4] tcm_vhost+cmwq fabric driver code for-3.6
On Thu, 2012-07-19 at 08:00 +0200, Paolo Bonzini wrote: > Il 18/07/2012 21:12, Anthony Liguori ha scritto: > Windows does this with a points system and I do believe that INQUIRY > > responses from any local disks are included in this tally. > > INQUIRY responses (at least vendor/product/type) should not change. INQUIRY responses often change for arrays because a firmware upgrade enables new features and new features have to declare themselves, usually in the INQUIRY data. What you mean, I think, is that previously exposed features in INQUIRY data, as well as strings (vendor/product/type, as you say), shouldn't change, but unexposed data (read 0 in the fields) may. James -- 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
