On 04/21/2015 01:15 PM, Sumit Saxena wrote: >> -----Original Message----- >> From: Hannes Reinecke [mailto:h...@suse.de] >> Sent: Tuesday, April 21, 2015 3:54 PM >> To: sumit.sax...@avagotech.com; linux-scsi@vger.kernel.org >> Cc: the...@redhat.com; martin.peter...@oracle.com; h...@infradead.org; >> jbottom...@parallels.com; kashyap.de...@avagotech.com >> Subject: Re: [PATCH RESEND 5/18] megaraid_sas : Enhanced few prints >> >> On 04/20/2015 02:33 PM, sumit.sax...@avagotech.com wrote: >>> This patch will update few prints. >>> >>> Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com> >>> >>> --- >>> drivers/scsi/megaraid/megaraid_sas_base.c | 49 > ++++++++++++++--------- >> ------ >>> 1 files changed, 24 insertions(+), 25 deletions(-) >>> >>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c >>> b/drivers/scsi/megaraid/megaraid_sas_base.c >>> index 7f426e0..d8e7075 100644 >>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c >>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c >>> @@ -4091,12 +4091,11 @@ static void >> megasas_update_ext_vd_details(struct megasas_instance *instance) >>> instance->fw_supported_vd_count = MAX_LOGICAL_DRIVES; >>> instance->fw_supported_pd_count = >> MAX_PHYSICAL_DEVICES; >>> } >>> - dev_info(&instance->pdev->dev, "Firmware supports %d VD %d >> PD\n", >>> - instance->fw_supported_vd_count, >>> - instance->fw_supported_pd_count); >>> - dev_info(&instance->pdev->dev, "Driver supports %d VD %d PD\n", >>> - instance->drv_supported_vd_count, >>> - instance->drv_supported_pd_count); >>> + >>> + dev_info(&instance->pdev->dev, >>> + "firmware type\t: %s\n", >>> + instance->supportmax256vd ? "Extended VD(240 >> VD)firmware" : >>> + "Legacy(64 VD) firmware"); >>> >>> old_map_sz = sizeof(struct MR_FW_RAID_MAP) + >>> (sizeof(struct MR_LD_SPAN_MAP) * >>> @@ -4713,9 +4712,6 @@ static int megasas_init_fw(struct >> megasas_instance *instance) >>> ctrl_info->adapterOperations2.supportUnevenSpans; >>> if (instance->UnevenSpanSupport) { >>> struct fusion_context *fusion = instance->ctrl_context; >>> - >>> - dev_info(&instance->pdev->dev, "FW supports: " >>> - "UnevenSpanSupport=%x\n", instance- >>> UnevenSpanSupport); >>> if (MR_ValidateMapInfo(instance)) >>> fusion->fast_path_io = 1; >>> else >>> @@ -4742,13 +4738,11 @@ static int megasas_init_fw(struct >> megasas_instance *instance) >>> instance->crash_dump_drv_support = >>> (instance->crash_dump_fw_support && >>> instance->crash_dump_buf); >>> - if (instance->crash_dump_drv_support) { >>> - dev_info(&instance->pdev->dev, "Firmware Crash dump " >>> - "feature is supported\n"); >>> + if (instance->crash_dump_drv_support) >>> megasas_set_crash_dump_params(instance, >>> MR_CRASH_BUF_TURN_OFF); >>> >>> - } else { >>> + else { >>> if (instance->crash_dump_buf) >>> pci_free_consistent(instance->pdev, >>> CRASH_DMA_BUF_SIZE, >>> @@ -4759,8 +4753,23 @@ static int megasas_init_fw(struct >>> megasas_instance *instance) >>> >>> instance->secure_jbod_support = >>> ctrl_info->adapterOperations3.supportSecurityonJBOD; >>> - if (instance->secure_jbod_support) >>> - dev_info(&instance->pdev->dev, "Firmware supports Secure >> JBOD\n"); >>> + >>> + dev_info(&instance->pdev->dev, >>> + "pci id\t\t: (0x%04x)/(0x%04x)/(0x%04x)/(0x%04x)\n", >>> + le16_to_cpu(ctrl_info->pci.vendor_id), >>> + le16_to_cpu(ctrl_info->pci.device_id), >>> + le16_to_cpu(ctrl_info->pci.sub_vendor_id), >>> + le16_to_cpu(ctrl_info->pci.sub_device_id)); >>> + dev_info(&instance->pdev->dev, "unevenspan support : >> %s\n", >>> + instance->UnevenSpanSupport ? "yes" : "no"); >>> + dev_info(&instance->pdev->dev, "disable ocr : %s\n", >>> + instance->disableOnlineCtrlReset ? "yes" : "no"); >>> + dev_info(&instance->pdev->dev, "firmware crash dump : >> %s\n", >>> + instance->crash_dump_drv_support ? "yes" : "no"); >>> + dev_info(&instance->pdev->dev, "secure jbod : %s\n", >>> + instance->secure_jbod_support ? "yes" : "no"); >>> + >>> + >> Hmm. This has a good chance of being broken up into several lines (ie one > line >> per 'dev_info' call. >> I'd prefer to have it modified to use one line eg by merging it into one > call to >> dev_info(). > > Understood.. We can go either way. Can we do it(one call to dev_info()) in > next updates(not in to be resent patches) to avoid regression/rework for > patches?
Sure. Nothing critical, but I just wanted to make you aware of this. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
