Hello this is Mr Wong again from hongkong,Can we send the Swift as discuss best
regards.
Mr Wong Cheng
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Saurav,
> This series has misc bug fixes and code enchancements in flush
> routine, abort and TMF path.
Applied to 5.2/scsi-queue, thanks.
Next time please try to submit your work in smaller batches.
It is inconceivable that somebody would volunteer to review a series of
25+ patches. It is ha
I have a business Proposal that will be of benefit to the both of us.Kindly
contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.
Stanley,
> +UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER MEDIATEK HOOKS
> +M: Stanley Chu
> +L: linux-scsi@vger.kernel.org
> +L: linux-media...@lists.infradead.org (moderated for non-subscribers)
> +S: Maintained
> +F: drivers/scsi/ufs/ufs-mediatek*
> +
Applied to 5.2/scsi-queue, t
Steffen,
> here are 3 zfcp bug fixes for v5.1-rcX
Applied to 5.1/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
Hi Alim,
On Wed, 2019-03-27 at 22:48 +0530, Alim Akhtar wrote:
> Hi Stanley,
> Please collect all the {review/acked}-by tags when reposting so that
> people are aware which all patches need to review.
> https://www.spinics.net/lists/linux-scsi/msg128818.html
Sorry it's my mistake to miss some tag
Bart,
> The scsi_end_request() function calls scsi_cmd_to_driver() indirectly
> and hence needs the disk->private_data pointer. Avoid that that
> pointer is cleared before all affected I/O requests have
> finished. This patch avoids that the following crash occurs:
Applied to 5.1/scsi-fixes, th
zhengbin,
> prep_to_mq will return BLK_STS_RESOURCE, and scsi_queue_rq will
> transter it to BLK_STS_DEV_RESOURCE, which means that driver can
> guarantee that IO dispatch will be triggered in future when the
> resource is available. Need to follow the rule if we set the device
> state to runni
Bart,
> Now that patch the patch series that includes "driver core: Probe
> devices asynchronously instead of the driver" is upstream I'm
> resubmitting the patch series that makes the sd driver rely on the
> driver core for asynchronous probing. Please consider this patch
> series for kernel v5
On Wed, 2019-03-27 at 09:12 +0100, Christoph Hellwig wrote:
> On Wed, Mar 27, 2019 at 09:58:16AM +0800, Ming Lei wrote:
> > Given it is a IB/SRP specific issue, could you consider the following
> > one-line fix?
>
> It isn't really a IB/SRP specific issue, it is just that the SRP
> maintainer actu
On Wed, 2019-03-27 at 09:46 -0700, Bart Van Assche wrote:
> On Wed, 2019-03-27 at 12:11 -0400, Martin K. Petersen wrote:
> > Commit a83da8a4509d ("scsi: sd: Optimal I/O size should be a
> > multiple
> > of physical block size") split one conditional into several
> > separate
> > statements in an ef
Hi Stanley,
Please collect all the {review/acked}-by tags when reposting so that
people are aware which all patches need to review.
https://www.spinics.net/lists/linux-scsi/msg128818.html
This series looks good, it will be if we get a Tested-by as well.
For this series
Acked-by: Alim Akhtar
On We
On Wed, 2019-03-27 at 12:11 -0400, Martin K. Petersen wrote:
> Commit a83da8a4509d ("scsi: sd: Optimal I/O size should be a multiple
> of physical block size") split one conditional into several separate
> statements in an effort to provide more accurate warning messages when
> a device reports a n
On Tue, Mar 26, 2019 at 01:43:31PM -0700, Bart Van Assche wrote:
> The previous patch guarantees that srp_queuecommand() does not get
> invoked while reconnecting occurs. Hence remove the code from
> srp_queuecommand() that prevents command queueing while reconnecting.
> This patch avoids that the
Some devices come online in write protected state and switch to
read-write once they are ready to process I/O requests. These devices
broke with commit 20bd1d026aac ("scsi: sd: Keep disk read-only when
re-reading partition") because we had no way to distinguish between a
user decision to set a bloc
Commit a83da8a4509d ("scsi: sd: Optimal I/O size should be a multiple
of physical block size") split one conditional into several separate
statements in an effort to provide more accurate warning messages when
a device reports a nonsensical value. However, this reorganization
accidentally dropped t
Hi Avri,
On Wed, 2019-03-27 at 10:57 +, Avri Altman wrote:
> > Hi,
> >
> > Resend this patch series for review.
> >
> > This version (v3) fixed and added more details in commit messages, and added
> > one patch to fix "undefined voltage range" issue as well.
> >
> > This patch series fixes
On 3/25/19 4:32 PM, Bart Van Assche wrote:
On Mon, 2019-03-25 at 10:26 +0100, Hannes Reinecke wrote:
The original issue leading to this patchset was this crash:
[159135.508116] Pid: 2638, comm: ssea Tainted: GWX
3.0.101-0.40-default #1 HP ProLiant BL460c Gen9
[159135.508119] RIP: 0
> Hi,
>
> Resend this patch series for review.
>
> This version (v3) fixed and added more details in commit messages, and added
> one patch to fix "undefined voltage range" issue as well.
>
> This patch series fixes UFS regulator operations, including voltage and
> current
> (re-)configuratio
>
> Currently if a regulator has "-fixed-regulator"
> property in device tree, it will skip current limit initialization.
> This lead to a zero "max_uA" value in struct ufs_vreg.
>
> However, "regulator_set_load" operation shall be required
> on regulators which have valid current limits, otherwi
>
> In dt-bindings for ufs, "-max-microamp" property indicates
> current limit and is mandatory if "-fixed-regulator" is not
> defined on a specified regulator.
>
> However, in some platforms, regulators without "-fixed-regulator"
> property may not need to define their current limit because they
>
> For regulators used by UFS, vcc, vccq and vccq2 will have voltage range
> initialized by ufshcd_populate_vreg(), however other regulators may
> have undefined voltage range if dt-bindings have no such definition.
>
> In above undefined case, both "min_uV" and "max_uV" fields in ufs_vreg
> str
In dt-bindings for ufs, "-max-microamp" property indicates
current limit and is mandatory if "-fixed-regulator" is not
defined on a specified regulator.
However, in some platforms, regulators without "-fixed-regulator"
property may not need to define their current limit because they may
want to de
For regulators used by UFS, vcc, vccq and vccq2 will have voltage range
initialized by ufshcd_populate_vreg(), however other regulators may
have undefined voltage range if dt-bindings have no such definition.
In above undefined case, both "min_uV" and "max_uV" fields in ufs_vreg
struct will be zer
Hi,
Resend this patch series for review.
This version (v3) fixed and added more details in commit messages, and added
one patch to fix "undefined voltage range" issue as well.
This patch series fixes UFS regulator operations, including voltage and current
(re-)configuration flow during UFS ini
There are two fields related to regulator current limit in struct
ufs_vreg: "min_uA" and "max_uA".
"max_uA" is probed by "-max-microamp" property from device
tree and used for
- regulator_set_load operations, and
- icc_level configuration in device.
However "min_uA" field is not used anywhere, t
Currently if a regulator has "-fixed-regulator"
property in device tree, it will skip current limit initialization.
This lead to a zero "max_uA" value in struct ufs_vreg.
However, "regulator_set_load" operation shall be required
on regulators which have valid current limits, otherwise a zero
"max_
"-fixed-regulator" device tree property can be
safely removed because below things are fixed or resolved,
1. "-max-microamp" becomes optional property: Undefined
"-max-microamp" will not cause initialization fail if
"-fixed-regulator" is not defined.
2. Current switching operation (by regul
On Wed, Mar 27, 2019 at 4:44 AM Bart Van Assche wrote:
>
> Several SCSI transport and LLD drivers surround code that does not
> tolerate concurrent calls of .queuecommand() with scsi_target_block() /
> scsi_target_unblock(). These last two functions use
> blk_mq_quiesce_queue() / blk_mq_unquiesce_
On 3/21/19 7:25 PM, Kashyap Desai wrote:
Hannes & Christoph: Please comment on Sreekanth's proposed
approach.
Iterating over all tags from the driver is always wrong. We've
been though this a few times.
Current issue is very easy to be reproduced and it is widely
impacted.
We proposed this
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Mar 27, 2019 at 09:58:16AM +0800, Ming Lei wrote:
> Given it is a IB/SRP specific issue, could you consider the following
> one-line fix?
It isn't really a IB/SRP specific issue, it is just that the SRP
maintainer actually tried to fix this race that others often ignored.
And checking for
>
> Stanley actively join the development and review on
> MediaTek UFS driver.
>
> Signed-off-by: Stanley Chu
Acked-by: Avri Altman
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e17ebf70b548..30f280b560a6 100644
> --- a/
34 matches
Mail list logo
