> This driver is full of lines longer than 80 characters.... I'll see what I can > do. I'm not planning on reworking the entire driver to shorten the line lengths > but if there are obvious places in my patch, like above, I'll do what I can to > conform. sure, no need to fix up existing code - just don't introduce new ones. > I suspect it should be a separate patch to clean up all the white space / style/long line / other issues in this driver. :) yeah, small cleanup patches are always nice, just don't mix them up with real bugfixes or new features. > > Please try to order functions so that forward-prototypes aren't > > needed. (where easily possible) > > In this case, most references are needed for the scsi_host_template > or the fc_function_template and I'm chosing to not move those function > templates. ok > > could you calls this ioc->fc_rescan_work? also no need for the > > void cast. > > I had intended to create a "generic" work_task structure that could be > used by all personalities of the driver as, AFAIK, only one will > own an hba. However, I understand the point and will change it. If > this is important enough to me, I can make it a union later once the > dust settles. ok. > I looked at your patch to mptsas for slave_destroy. I believe that since the > fc_transport retains rport info for the case when the rport returns > after destroy, that mptfc should retain its data structure. indeed, that makes sense. > scsi_scan_host was a delete, not an insert point.... sorry, looks like I misread the patch. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
