Re: [PATCH 7/7] block: allocate block_pc data separate from struct request
On Wed, May 06, 2015 at 02:46:18PM +0300, Boaz Harrosh wrote:
> > - memset(rq->__cmd, 0, sizeof(rq->__cmd));
> > +
> > + rq->block_pc = kzalloc(sizeof(*rq->block_pc) + cmd_len, gfp);
>
> I wish you would not embed a dynamic allocation here for any
> driver regardless. This extra allocation does hurt a lot. See how in
> SCSI fs commands you embedded it in scsi_cmnd so it catches as well
> for multi-Q pre-allocation.
>
> I think you need to just make it the same as *sense pass it from outside
> and the allocation is the caller responsibility. The caller must have
> an end-request call back set. (Or is a sync call)
>
> Usually all users already have a structure to put this in. The only bit
> more work is to take care of the free. If they are already passing sense
> then they already need to free at end of request. Those that are synchronous
> can have it on the stack. Only very few places need a bit of extra work.
Actually most don't have a structure ready, that's why I ressorted to this
version. But once this is in you can easily add low-level version that
allows passing a preallocate cdb buffer for the OSD case.
> > +struct block_pc_request {
> > + unsigned short cmd_len;
> > + unsigned int sense_len;
> > + void *sense;
>
> Better move cmd_len here the short will combine well
> with the char array.
Thanks.
> > + union {
> > + struct block_pc_request *block_pc;
> > + void *drv_private;
> > + };
> > +
>
> Exactly. drv_private is allocated by caller we can do the same for
> block_pc. Also If (theoretically) a driver needs both it is just the
> same pointer right? (container_of)
I probably need to rename the field. It's only driver private when
the low-level driver itself submits the request, e.g. internal commands
in the LLDD. But in that particular case what you suggest is fine.
--
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 02/17] scsi_dh_alua: Disable ALUA handling for non-disk devices
On 05/11/2015 08:46 AM, Christoph Hellwig wrote:
> On Mon, May 04, 2015 at 02:42:08PM +0200, Hannes Reinecke wrote:
>> Non-disk devices should be ignored when detecting
>> ALUA capabilities.
>
> Hmm. I don't think we should even attach the alua handler in this case,
> e.g. refine the check in scsi_dh_find_driver. But then again I don't
> remember how the spec wording actually disallows this, and a quick grep
> of SPC-4 can't find anything either. Can you put a reference to the spec
> section that disallows attachment to non-disk devices into the code?
>
The spec wording doesn't explicitly disallowing you from doing so
(unless you're using referrals).
But in realiter we're using the ALUA device handler only when
multipathing is used, which in turn runs on disk devices only.
So we can limit ourselves to disk devices, too.
Everything else (like tapes or tape changers) will have to
implement their own logic anyway; tape support in multipathing
with or without ALUA is too horrible to contemplate ...
>> +if (sdev->type != TYPE_DISK &&
>> +sdev->type != TYPE_RBC &&
>> +sdev->type != TYPE_OSD) {
>
> And does it really allow RBC (but not ZBC)?
>
Thought so, but I'll have to cross-check.
Maybe it's time to implement a 'scsi_is_disk_type()' macro...
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (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
[PATCH v1 2/2] phy: update obsolete configuration of ARCH_MSM into ARCH_QCOM
Since ARCH_MSM is no longer supported as configuration definition, it should be modified into ARCH_QCOM in order to add support for Qualcomm platforms. Signed-off-by: Yaniv Gardi --- drivers/phy/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index a53bd5b..33e703e 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -304,7 +304,7 @@ config PHY_STIH41X_USB config PHY_QCOM_UFS tristate "Qualcomm UFS PHY driver" - depends on OF && ARCH_MSM + depends on OF && ARCH_QCOM select GENERIC_PHY help Support for UFS PHY on QCOM chipsets. -- 1.8.5.2 -- QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 v1 2/2] phy: update obsolete configuration of ARCH_MSM into ARCH_QCOM
On 05/11/15 08:15, Yaniv Gardi wrote: > Since ARCH_MSM is no longer supported as configuration definition, > it should be modified into ARCH_QCOM in order to add support for > Qualcomm platforms. > > Signed-off-by: Yaniv Gardi > > --- I've already sent this patch[1]. Can you please ack it? [1] https://lkml.org/lkml/2015/4/10/862 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 v5 8/9] snic:Add event tracing to capture IO events.
On 04/22/2015 11:24 AM, Narsimhulu Musini wrote: > snic_trc.h contains global trace structure definitions for snic driver > > snic_trc.c adds tracing functionality to capture various IO events. > It maintains global trace buffer to maintain recent history of IO events. > It helps to understand the sequence of events prior to particular IO event, > or hung, panic, etc,. > > Signed-off-by: Narsimhulu Musini > Signed-off-by: Sesidhar Baddela > --- Reviewed-by: Hannes Reinecke 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
