Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

[Asutosh Das (asd)]

Vivek,

On 8/11/2017 12:42 PM, Vivek Gautam wrote:

On Fri, Aug 11, 2017 at 5:33 AM, Martin K. Petersen
 wrote:


Vivek,


Can you kindly review this patch series (for UFS controller changes)
and consider giving your Ack so that Kishon can pull in the series
through phy tree.


SCSI piece looks OK.


Thank you Martin for your review.


Would still like Subhash to review the rest.


Subhash is on vacation with limited access to emails. I will ask
his team to take a look.


Looks good to me.

regards
Vivek



--
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






--
Asutosh Das (asd)
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

[PATCH] Revert "scsi: default to scsi-mq"

[Christoph Hellwig]

Defaulting to scsi-mq in 4.13-rc has shown various regressions
on setups that we didn't previously consider.  Fixes for them are
in progress, but too invasive to make it in this cycle.  So for
now revert the commit that defaults to blk-mq for SCSI.  For 4.14
we'll plan to try again with these fixes.

This reverts commit 5c279bd9e40624f4ab6e688671026d6005b066fa.

Signed-off-by: Christoph Hellwig 
---
 drivers/scsi/Kconfig | 11 +++
 drivers/scsi/scsi.c  |  4 
 2 files changed, 15 insertions(+)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index f4538d7a3016..d145e0d90227 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -47,6 +47,17 @@ config SCSI_NETLINK
default n
depends on NET
 
+config SCSI_MQ_DEFAULT
+   bool "SCSI: use blk-mq I/O path by default"
+   depends on SCSI
+   ---help---
+ This option enables the new blk-mq based I/O path for SCSI
+ devices by default.  With the option the scsi_mod.use_blk_mq
+ module/boot option defaults to Y, without it to N, but it can
+ still be overridden either way.
+
+ If unsure say N.
+
 config SCSI_PROC_FS
bool "legacy /proc/scsi/ support"
depends on SCSI && PROC_FS
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 3d38c6d463b8..1bf274e3b2b6 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -800,7 +800,11 @@ MODULE_LICENSE("GPL");
 module_param(scsi_logging_level, int, S_IRUGO|S_IWUSR);
 MODULE_PARM_DESC(scsi_logging_level, "a bit mask of logging levels");
 
+#ifdef CONFIG_SCSI_MQ_DEFAULT
 bool scsi_use_blk_mq = true;
+#else
+bool scsi_use_blk_mq = false;
+#endif
 module_param_named(use_blk_mq, scsi_use_blk_mq, bool, S_IWUSR | S_IRUGO);
 
 static int __init init_scsi(void)
-- 
2.11.0

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

[Christoph Hellwig]

On Fri, Aug 11, 2017 at 06:01:42PM +0200, Benjamin Block wrote:
> When the BSG interface is used with bsg-lib, and the user sends a
> Bidirectional command - so when he gives an input- and output-buffer
> (most users of our interface will likely do that, if they wanna get the
> transport-level response data) - bsg will allocate two requests from the
> queue. The first request's bio is used to map the input and the second
> request's bio for the output (see bsg_map_hdr() in the if-statement with
> (op == REQ_OP_SCSI_OUT && hdr->din_xfer_len)).
> 
> When we now allocate the full space of bsg_job, sense, dd_data for each
> request, these will be wasted on the (linked) second request. They will
> go unused all the time, as only the first request's bsg_job, sense and
> dd_data is used by the LLDs and BSG itself.
> 
> Right now, because we don't allocate this on each request, those spaces
> are only allocated for the first request in bsg-lib.
> 
> Maybe we can ignore this, if it gets to complicated, I don't wanne
> prolong this unnecessary.

We have the same 'issue' with bidirection scsi commands - it's a side
effect of having two request structures for these commands, and the
only real fix would be to have a single request structure, which would
be nice especially if we can't do it without growing struct request.

Re: [PATCH 0/6] constify pci_error_handlers structures

[Christoph Hellwig]

On Sat, Aug 12, 2017 at 01:51:21PM +0200, Julia Lawall wrote:
> Another issue arises in the files drivers/infiniband/hw/hfi1/pcie.c and
> drivers/infiniband/hw/qib/qib_pcie.c, where the pci_error_handlers
> structure is defined in one file and used in another file.  The structure
> definition references various functions that are static in the same file.
> Should I try to move those functions to the file containing the pci_driver
> structure?  Or leave the functions where they are and remove the static
> annotation?

I'd just leave them as-is and remove the static for now.