Re: [PATCH v5 6/7] phy: mediatek: Add UFS M-PHY driver
Hi,
On 14/03/19 9:38 AM, Stanley Chu wrote:
> Add UFS M-PHY driver on MediaTek chipsets.
>
> Signed-off-by: Stanley Chu
> Reviewed-by: Chunfeng Yun
> ---
> drivers/phy/mediatek/Kconfig | 11 ++
> drivers/phy/mediatek/Makefile | 1 +
> drivers/phy/mediatek/phy-mtk-ufs.c | 239 +
> 3 files changed, 251 insertions(+)
> create mode 100644 drivers/phy/mediatek/phy-mtk-ufs.c
>
> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> index 8857d00b3c65..2152d5619c8f 100644
> --- a/drivers/phy/mediatek/Kconfig
> +++ b/drivers/phy/mediatek/Kconfig
> @@ -13,6 +13,16 @@ config PHY_MTK_TPHY
> multi-ports is first version, otherwise is second veriosn,
> so you can easily distinguish them by banks layout.
>
> +config PHY_MTK_UFS
> + tristate "MediaTek UFS M-PHY driver"
> + depends on ARCH_MEDIATEK && OF
> + select GENERIC_PHY
> + help
> + Support for UFS M-PHY on MediaTek chipsets.
> + Enable this to provide vendor-specific probing,
> + initialization, power on and power off flow of
> + specified M-PHYs.
> +
> config PHY_MTK_XSPHY
> tristate "MediaTek XS-PHY Driver"
> depends on ARCH_MEDIATEK && OF
> @@ -21,3 +31,4 @@ config PHY_MTK_XSPHY
> Enable this to support the SuperSpeedPlus XS-PHY transceiver for
> USB3.1 GEN2 controllers on MediaTek chips. The driver supports
> multiple USB2.0, USB3.1 GEN2 ports.
> +
spurious blank space.
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index ee49edc97ee9..08a8e6a97b1e 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -4,4 +4,5 @@
> #
>
> obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> +obj-$(CONFIG_PHY_MTK_UFS)+= phy-mtk-ufs.o
> obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> diff --git a/drivers/phy/mediatek/phy-mtk-ufs.c
> b/drivers/phy/mediatek/phy-mtk-ufs.c
> new file mode 100644
> index ..71c29ff83f27
> --- /dev/null
> +++ b/drivers/phy/mediatek/phy-mtk-ufs.c
> @@ -0,0 +1,239 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 MediaTek Inc.
> + * Author: Stanley Chu
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* mphy register and offsets */
> +#define MP_GLB_DIG_8C 0x008C
> +#define FRC_PLL_ISO_EN BIT(8)
> +#define PLL_ISO_EN BIT(9)
> +#define FRC_FRC_PWR_ON BIT(10)
> +#define PLL_PWR_ON BIT(11)
> +
> +#define MP_LN_DIG_RX_9C 0xA09C
> +#define FSM_DIFZ_FRCBIT(18)
> +
> +#define MP_LN_DIG_RX_AC 0xA0AC
> +#define FRC_RX_SQ_ENBIT(0)
> +#define RX_SQ_ENBIT(1)
> +
> +#define MP_LN_RX_44 0xB044
> +#define FRC_CDR_PWR_ON BIT(17)
> +#define CDR_PWR_ON BIT(18)
> +#define FRC_CDR_ISO_EN BIT(19)
> +#define CDR_ISO_EN BIT(20)
> +
> +#define mphy_readl(phy, ofs) readl((phy)->mmio + (ofs))
> +#define mphy_writel(phy, val, ofs) writel((val), (phy)->mmio + (ofs))
These are better implemented as inline functions.
> +
> +struct ufs_mtk_phy {
> + struct device *dev;
> + void __iomem *mmio;
> + struct clk *mp_clk;
> + struct clk *unipro_clk;
> +};
> +
> +static void mphy_set_bit(struct ufs_mtk_phy *phy, u32 reg, u32 bit)
> +{
> + u32 val;
> +
> + val = mphy_readl(phy, reg);
> + val |= bit;
> + mphy_writel(phy, val, reg);
> +}
> +
> +static void mphy_clr_bit(struct ufs_mtk_phy *phy, u32 reg, u32 bit)
> +{
> + u32 val;
> +
> + val = mphy_readl(phy, reg);
> + val &= ~bit;
> + mphy_writel(phy, val, reg);
> +}
> +
> +static struct ufs_mtk_phy *get_ufs_mtk_phy(struct phy *generic_phy)
> +{
> + return (struct ufs_mtk_phy *)phy_get_drvdata(generic_phy);
> +}
> +
> +static int ufs_mtk_phy_clk_init(struct ufs_mtk_phy *phy)
> +{
> + struct device *dev = phy->dev;
> +
> + phy->unipro_clk = devm_clk_get(dev, "unipro");
> + if (IS_ERR(phy->unipro_clk)) {
> + dev_err(dev, "failed to get clock: unipro");
> + return PTR_ERR(phy->unipro_clk);
> + }
> +
> + phy->mp_clk = devm_clk_get(dev, "mp");
> + if (IS_ERR(phy->mp_clk)) {
> + dev_err(dev, "failed to get clock: mp");
> + return PTR_ERR(phy->mp_clk);
> + }
> +
> + return 0;
> +}
> +
> +static void ufs_mtk_phy_set_active(struct ufs_mtk_phy *phy)
> +{
> + /* release DA_MP_PLL_PWR_ON */
> + mphy_set_bit(phy, MP_GLB_DIG_8C, PLL_PWR_ON);
> + mphy_clr_bit(phy, MP_GLB_DIG_8C, FRC_FRC_PWR_ON);
> +
> + /* release DA_MP_PLL_ISO_EN */
> + mphy_clr_bit(phy, MP_GLB_DIG_8C, PLL_ISO_EN);
> + mphy_clr_bit(phy, MP_GLB_DIG_8C, FRC_PLL_ISO_EN);
> +
> + /* release DA_MP_CDR_PWR_ON */
> + mphy_set_bit(phy, MP_LN_RX_44, CDR_PWR_ON);
> + mphy_clr
RE: [PATCH v5 0/7] scsi: ufs-mediatek: Add UFS support for Mediatek SoC chips
> > Hello, > > This patch series adds UFS M-PHY and UFS host driver support in MediaTek > chipsets. > > In the meantime, re-factors ufshcd_get_pwr_dev_param in vendors' drivers. > This function is for vendors to decide finally agreed attributes for power > mode > change if vendors define > their host capability in struct ufs_dev_params. Because it is using by both > ufs- > qcom and ufs-hisi and also used in ufs-mediatek in this serious, simply > re-factor > it and then every vendors can reuse it. As there are other comments, you might want to get this typo as well: serious= series Thanks, Avri
Re: [PATCH v5 6/7] phy: mediatek: Add UFS M-PHY driver
Hi Kishon,
On Thu, 2019-03-14 at 16:06 +0800, Kishon Vijay Abraham I wrote:
> Hi,
>
> On 14/03/19 9:38 AM, Stanley Chu wrote:
> > Add UFS M-PHY driver on MediaTek chipsets.
> >
> > Signed-off-by: Stanley Chu
> > Reviewed-by: Chunfeng Yun
> > ---
> > drivers/phy/mediatek/Kconfig | 11 ++
> > drivers/phy/mediatek/Makefile | 1 +
> > drivers/phy/mediatek/phy-mtk-ufs.c | 239 +
> > 3 files changed, 251 insertions(+)
> > create mode 100644 drivers/phy/mediatek/phy-mtk-ufs.c
> >
> > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> > index 8857d00b3c65..2152d5619c8f 100644
> > --- a/drivers/phy/mediatek/Kconfig
> > +++ b/drivers/phy/mediatek/Kconfig
> > @@ -13,6 +13,16 @@ config PHY_MTK_TPHY
> > multi-ports is first version, otherwise is second veriosn,
> > so you can easily distinguish them by banks layout.
> >
> > +config PHY_MTK_UFS
> > + tristate "MediaTek UFS M-PHY driver"
> > + depends on ARCH_MEDIATEK && OF
> > + select GENERIC_PHY
> > + help
> > + Support for UFS M-PHY on MediaTek chipsets.
> > + Enable this to provide vendor-specific probing,
> > + initialization, power on and power off flow of
> > + specified M-PHYs.
> > +
> > config PHY_MTK_XSPHY
> > tristate "MediaTek XS-PHY Driver"
> > depends on ARCH_MEDIATEK && OF
> > @@ -21,3 +31,4 @@ config PHY_MTK_XSPHY
> > Enable this to support the SuperSpeedPlus XS-PHY transceiver for
> > USB3.1 GEN2 controllers on MediaTek chips. The driver supports
> > multiple USB2.0, USB3.1 GEN2 ports.
> > +
>
> spurious blank space.
Will remove it.
> > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> > index ee49edc97ee9..08a8e6a97b1e 100644
> > --- a/drivers/phy/mediatek/Makefile
> > +++ b/drivers/phy/mediatek/Makefile
> > @@ -4,4 +4,5 @@
> > #
> >
> > obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> > +obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
> > obj-$(CONFIG_PHY_MTK_XSPHY)+= phy-mtk-xsphy.o
> > diff --git a/drivers/phy/mediatek/phy-mtk-ufs.c
> > b/drivers/phy/mediatek/phy-mtk-ufs.c
> > new file mode 100644
> > index ..71c29ff83f27
> > --- /dev/null
> > +++ b/drivers/phy/mediatek/phy-mtk-ufs.c
> > @@ -0,0 +1,239 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 MediaTek Inc.
> > + * Author: Stanley Chu
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* mphy register and offsets */
> > +#define MP_GLB_DIG_8C 0x008C
> > +#define FRC_PLL_ISO_EN BIT(8)
> > +#define PLL_ISO_EN BIT(9)
> > +#define FRC_FRC_PWR_ON BIT(10)
> > +#define PLL_PWR_ON BIT(11)
> > +
> > +#define MP_LN_DIG_RX_9C 0xA09C
> > +#define FSM_DIFZ_FRCBIT(18)
> > +
> > +#define MP_LN_DIG_RX_AC 0xA0AC
> > +#define FRC_RX_SQ_ENBIT(0)
> > +#define RX_SQ_ENBIT(1)
> > +
> > +#define MP_LN_RX_44 0xB044
> > +#define FRC_CDR_PWR_ON BIT(17)
> > +#define CDR_PWR_ON BIT(18)
> > +#define FRC_CDR_ISO_EN BIT(19)
> > +#define CDR_ISO_EN BIT(20)
> > +
> > +#define mphy_readl(phy, ofs) readl((phy)->mmio + (ofs))
> > +#define mphy_writel(phy, val, ofs) writel((val), (phy)->mmio + (ofs))
>
> These are better implemented as inline functions.
OK. Will be done in next version.
> > +
> > +struct ufs_mtk_phy {
> > + struct device *dev;
> > + void __iomem *mmio;
> > + struct clk *mp_clk;
> > + struct clk *unipro_clk;
> > +};
> > +
> > +static void mphy_set_bit(struct ufs_mtk_phy *phy, u32 reg, u32 bit)
> > +{
> > + u32 val;
> > +
> > + val = mphy_readl(phy, reg);
> > + val |= bit;
> > + mphy_writel(phy, val, reg);
> > +}
> > +
> > +static void mphy_clr_bit(struct ufs_mtk_phy *phy, u32 reg, u32 bit)
> > +{
> > + u32 val;
> > +
> > + val = mphy_readl(phy, reg);
> > + val &= ~bit;
> > + mphy_writel(phy, val, reg);
> > +}
> > +
> > +static struct ufs_mtk_phy *get_ufs_mtk_phy(struct phy *generic_phy)
> > +{
> > + return (struct ufs_mtk_phy *)phy_get_drvdata(generic_phy);
> > +}
> > +
> > +static int ufs_mtk_phy_clk_init(struct ufs_mtk_phy *phy)
> > +{
> > + struct device *dev = phy->dev;
> > +
> > + phy->unipro_clk = devm_clk_get(dev, "unipro");
> > + if (IS_ERR(phy->unipro_clk)) {
> > + dev_err(dev, "failed to get clock: unipro");
> > + return PTR_ERR(phy->unipro_clk);
> > + }
> > +
> > + phy->mp_clk = devm_clk_get(dev, "mp");
> > + if (IS_ERR(phy->mp_clk)) {
> > + dev_err(dev, "failed to get clock: mp");
> > + return PTR_ERR(phy->mp_clk);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void ufs_mtk_phy_set_active(struct ufs_mtk_phy *phy)
> > +{
> > + /* release DA_MP_PLL_PWR_ON */
> > + mphy_set_bit(phy,
RE: [PATCH v5 0/7] scsi: ufs-mediatek: Add UFS support for Mediatek SoC chips
Hi Avri, On Thu, 2019-03-14 at 16:28 +0800, Avri Altman wrote: > > > > Hello, > > > > This patch series adds UFS M-PHY and UFS host driver support in MediaTek > > chipsets. > > > > In the meantime, re-factors ufshcd_get_pwr_dev_param in vendors' drivers. > > This function is for vendors to decide finally agreed attributes for power > > mode > > change if vendors define > > their host capability in struct ufs_dev_params. Because it is using by both > > ufs- > > qcom and ufs-hisi and also used in ufs-mediatek in this serious, simply > > re-factor > > it and then every vendors can reuse it. > As there are other comments, you might want to get this typo as well: > serious= series Will fix it in next version. > Thanks, > Avri Thanks, Stanley > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v3 5/7] dt-bindings: scsi: ufs: Add document for ufs-mediatek
On 13/03/2019 20:48, Rob Herring wrote: Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions: - -fixed-regulator : boolean property specifying that -supply is a fixed regulator. > There are no users of that property in tree and doesn't look like > adding it was ever reviewed. We have standard ways to handle this and > don't need a custom property. FWIW, it seems to come from downstream: https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/?h=LE.UM.1.3.r3.25 $ git grep fixed-regulator vendor -- arch/arm/boot/dts/qcom/ vendor:arch/arm/boot/dts/qcom/msm8996.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-interposer-sdm660-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-interposer-sdm660-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd-skuk.dtsi:vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd-vr1.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-rumi.dtsi:vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-sim.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-svr20.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-v2.1-interposer-sdm660-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-pm660a-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-pm660a-sim.dts:vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-sim.dts: vdd-hba-fixed-regulator;
Re: [PATCH v3 5/7] dt-bindings: scsi: ufs: Add document for ufs-mediatek
On 13/03/2019 20:48, Rob Herring wrote: Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions: - -fixed-regulator : boolean property specifying that -supply is a fixed regulator. > There are no users of that property in tree and doesn't look like > adding it was ever reviewed. We have standard ways to handle this and > don't need a custom property. FWIW, it seems to come from downstream: https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/?h=LE.UM.1.3.r3.25 $ git grep fixed-regulator vendor -- arch/arm/boot/dts/qcom/ vendor:arch/arm/boot/dts/qcom/msm8996.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-interposer-sdm660-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-interposer-sdm660-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd-skuk.dtsi:vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd-vr1.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-rumi.dtsi:vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-sim.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-svr20.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-v2.1-interposer-sdm660-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-pm660a-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-pm660a-sim.dts:vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-sim.dts: vdd-hba-fixed-regulator;
scsi: ufs: fix up regulator operations
Hi, This patch series tries to clean-up and fix-up regulator operations in ufs driver. [PATCH 1/2] scsi: ufs: cleanup unused min_uA in struct ufs_vreg - min_uA in strcut ufs_vreg is not used by any ufs drivers thus remove it. [PATCH 2/2] scsi: ufs: fix regulator set load and icc-level re-configuration - Fix up "regulator_set_load" condition and icc_level value during icc_level configuration flow. Stanley Chu (2): scsi: ufs: cleanup unused min_uA in struct ufs_vreg scsi: ufs: fix regulator set load and icc-level configuration drivers/scsi/ufs/ufs.h | 1 - drivers/scsi/ufs/ufshcd-pltfrm.c | 1 - drivers/scsi/ufs/ufshcd.c| 15 --- 3 files changed, 12 insertions(+), 5 deletions(-)
[PATCH v1 0/2] scsi: ufs: fix up regulator operations
Hi, This patch series tries to clean-up and fix-up regulator operations in ufs driver. [PATCH 1/2] scsi: ufs: cleanup unused min_uA in struct ufs_vreg - min_uA in strcut ufs_vreg is not used by any ufs drivers thus remove it. [PATCH 2/2] scsi: ufs: fix regulator set load and icc-level re-configuration - Fix up "regulator_set_load" condition and icc_level value during icc_level configuration flow. Stanley Chu (2): scsi: ufs: cleanup unused min_uA in struct ufs_vreg scsi: ufs: fix regulator set load and icc-level configuration drivers/scsi/ufs/ufs.h | 1 - drivers/scsi/ufs/ufshcd-pltfrm.c | 1 - drivers/scsi/ufs/ufshcd.c| 15 --- 3 files changed, 12 insertions(+), 5 deletions(-) -- 2.18.0
[PATCH v1 1/2] scsi: ufs: cleanup unused min_uA in struct ufs_vreg
min_uA in strcut ufs_vreg is not used by any ufs
drivers thus remove it.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs.h | 1 -
drivers/scsi/ufs/ufshcd-pltfrm.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 7da7318eb6a6..0f23ac80bacd 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -516,7 +516,6 @@ struct ufs_vreg {
bool enabled;
int min_uV;
int max_uV;
- int min_uA;
int max_uA;
};
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index 895a9b5ac989..588079286e8a 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -164,7 +164,6 @@ static int ufshcd_populate_vreg(struct device *dev, const
char *name,
goto out;
}
- vreg->min_uA = 0;
if (!strcmp(name, "vcc")) {
if (of_property_read_bool(np, "vcc-supply-1p8")) {
vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
--
2.18.0
[PATCH v1 2/2] scsi: ufs: fix regulator set load and icc-level configuration
Currently if a regulator has "-fixed-regulator"
property in device tree, it will skip "max_uA" configuration.
However, "regulator_set_load" operation shall be required
on those regulators which specifically configured current
limitation, i.e., "max_uA". Otherwise zero max_uA value may
cause unexpected behavior when this regulator is enabled
or set as high power mode.
Similarly, in icc_level configuration flow, icc_level shall be
updated if specified regulator has configured "max_uA", otherwise
wrong icc_level may be written to device and cause unexpected results.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 8b9a01073d62..61cdae74de62 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6279,19 +6279,19 @@ static u32 ufshcd_find_max_sup_active_icc_level(struct
ufs_hba *hba,
goto out;
}
- if (hba->vreg_info.vcc)
+ if (hba->vreg_info.vcc && hba->vreg_info.vcc->max_uA)
icc_level = ufshcd_get_max_icc_level(
hba->vreg_info.vcc->max_uA,
POWER_DESC_MAX_ACTV_ICC_LVLS - 1,
&desc_buf[PWR_DESC_ACTIVE_LVLS_VCC_0]);
- if (hba->vreg_info.vccq)
+ if (hba->vreg_info.vccq && hba->vreg_info.vccq->max_uA)
icc_level = ufshcd_get_max_icc_level(
hba->vreg_info.vccq->max_uA,
icc_level,
&desc_buf[PWR_DESC_ACTIVE_LVLS_VCCQ_0]);
- if (hba->vreg_info.vccq2)
+ if (hba->vreg_info.vccq2 && hba->vreg_info.vccq2->max_uA)
icc_level = ufshcd_get_max_icc_level(
hba->vreg_info.vccq2->max_uA,
icc_level,
@@ -6989,6 +6989,15 @@ static int ufshcd_config_vreg_load(struct device *dev,
struct ufs_vreg *vreg,
if (!vreg)
return 0;
+ /*
+* "set_load" operation shall be required on those regulators
+* which specifically configured current limitation. Otherwise
+* zero max_uA may cause unexpected behavior when regulator is
+* enabled or set as high power mode.
+*/
+ if (!vreg->max_uA)
+ return 0;
+
ret = regulator_set_load(vreg->reg, ua);
if (ret < 0) {
dev_err(dev, "%s: %s set load (ua=%d) failed, err=%d\n",
--
2.18.0
Re: [PATCH] scsi: lpfc: Fix error codes in lpfc_sli4_pci_mem_setup()
Dan, > It used to be that "error" was set to -ENODEV at the start of the > function but we shifted some code around an now "error" is set to zero > for most error paths. There is a mix of direct returns and "goto out" > but I changed everything to direct returns for consistency. Applied to 5.1/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: aacraid: Fix performance issue(QD) on logical drives
Hi Sagar, > From: Sagar Biradar > > To: Martin K. Petersen > To: James Bottomley > cc: linux-scsi > cc: aacr...@microsemi.com > cc: Dave Carroll > cc: Scott Benesh > cc: sta...@vger.kernel.org > > Fix performance issue where the queue depth for SmartIOC logical > volumes is set to 1, and allow the usual logical volume code > to be executed This wasn't a correctly formatted patch. Please see: Documentation/process/submitting-patches.rst and remember to run checkpatch prior to submission. I fixed it up. Applied to 5.1/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] simscsi: use request tag instead of serial_number
Hannes, > Use the request tag for logging instead of the scsi command serial > number. Applied to 5.1/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v1 1/2] scsi: ufs: cleanup unused min_uA in struct ufs_vreg
On 14/03/2019 11:40, Stanley Chu wrote:
> scsi: ufs: cleanup unused min_uA in struct ufs_vreg
cleanup => drop/remove/delete
> min_uA in strcut ufs_vreg is not used by any ufs
> drivers thus remove it.
Nits:
min_uA => min_uA field (?)
strcut => struct
not used by any ufs drivers => not used anywhere (?)
Why do you make your lines so short? You're allowed 72 characters.
> drivers/scsi/ufs/ufs.h | 1 -
> drivers/scsi/ufs/ufshcd-pltfrm.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> index 7da7318eb6a6..0f23ac80bacd 100644
> --- a/drivers/scsi/ufs/ufs.h
> +++ b/drivers/scsi/ufs/ufs.h
> @@ -516,7 +516,6 @@ struct ufs_vreg {
> bool enabled;
> int min_uV;
> int max_uV;
> - int min_uA;
> int max_uA;
> };
>
> diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c
> b/drivers/scsi/ufs/ufshcd-pltfrm.c
> index 895a9b5ac989..588079286e8a 100644
> --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
> +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
> @@ -164,7 +164,6 @@ static int ufshcd_populate_vreg(struct device *dev, const
> char *name,
> goto out;
> }
>
> - vreg->min_uA = 0;
> if (!strcmp(name, "vcc")) {
> if (of_property_read_bool(np, "vcc-supply-1p8")) {
> vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
>
Reviewed-by: Marc Gonzalez
Re: [PATCH v1 1/2] scsi: ufs: cleanup unused min_uA in struct ufs_vreg
Hi Marc,
On Thu, 2019-03-14 at 19:57 +0800, Marc Gonzalez wrote:
> On 14/03/2019 11:40, Stanley Chu wrote:
>
> > scsi: ufs: cleanup unused min_uA in struct ufs_vreg
>
> cleanup => drop/remove/delete
>
> > min_uA in strcut ufs_vreg is not used by any ufs
> > drivers thus remove it.
>
> Nits:
>
> min_uA => min_uA field (?)
> strcut => struct
> not used by any ufs drivers => not used anywhere (?)
>
> Why do you make your lines so short? You're allowed 72 characters.
>
Thanks for review.
I'll try to describe this patch more clearly in next version.
> > drivers/scsi/ufs/ufs.h | 1 -
> > drivers/scsi/ufs/ufshcd-pltfrm.c | 1 -
> > 2 files changed, 2 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> > index 7da7318eb6a6..0f23ac80bacd 100644
> > --- a/drivers/scsi/ufs/ufs.h
> > +++ b/drivers/scsi/ufs/ufs.h
> > @@ -516,7 +516,6 @@ struct ufs_vreg {
> > bool enabled;
> > int min_uV;
> > int max_uV;
> > - int min_uA;
> > int max_uA;
> > };
> >
> > diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c
> > b/drivers/scsi/ufs/ufshcd-pltfrm.c
> > index 895a9b5ac989..588079286e8a 100644
> > --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
> > +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
> > @@ -164,7 +164,6 @@ static int ufshcd_populate_vreg(struct device *dev,
> > const char *name,
> > goto out;
> > }
> >
> > - vreg->min_uA = 0;
> > if (!strcmp(name, "vcc")) {
> > if (of_property_read_bool(np, "vcc-supply-1p8")) {
> > vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
> >
>
> Reviewed-by: Marc Gonzalez
Thanks,
Stanley
Re: ideas for fix to scsi_ioctl_reset
On Wed, 2019-03-13 at 23:52 -0400, Douglas Gilbert wrote: > On 2019-03-13 10:39 p.m., Bart Van Assche wrote: > > On 3/13/19 6:32 PM, Douglas Gilbert wrote: > > > I agree that scsi_ioctl_reset() should be taught how to produce a request > > > that doesn't blow up intermediate code expecting all requests to be well > > > made with respect to mq. > > > > Hi Doug, > > > > Do you perhaps have a proposal for how to do that without allocating a new > > request from the error handler and without reserving a request for error > > handling purposes. > > Well yes. The SCSI ML could tell the block layer that the LU/device > was unavailable (temporarily) and then the ML would communicate > directly with the LLD. A block layer/mq bypass ... > > Probably don't like that one. Why rule out reserving a request (e.g. one > per host)? The lowest supported queue depth is one so we reserving a request may break some SCSI LLDs. Additionally, reserving one request may have a performance impact. BTW, it is not clear to me why a struct scsi_cmnd pointer is passed to the eh_*_reset_handler() callbacks. Has it ever been considered to pass a struct scsi_device pointer to these callback functions instead? In other words, are there any eh_*_reset_handler() callbacks that use more information from struct scsi_cmnd than the device pointer? Bart.
Re: ideas for fix to scsi_ioctl_reset
On 2019-03-14 11:19 a.m., Bart Van Assche wrote: On Wed, 2019-03-13 at 23:52 -0400, Douglas Gilbert wrote: On 2019-03-13 10:39 p.m., Bart Van Assche wrote: On 3/13/19 6:32 PM, Douglas Gilbert wrote: I agree that scsi_ioctl_reset() should be taught how to produce a request that doesn't blow up intermediate code expecting all requests to be well made with respect to mq. Hi Doug, Do you perhaps have a proposal for how to do that without allocating a new request from the error handler and without reserving a request for error handling purposes. Well yes. The SCSI ML could tell the block layer that the LU/device was unavailable (temporarily) and then the ML would communicate directly with the LLD. A block layer/mq bypass ... Probably don't like that one. Why rule out reserving a request (e.g. one per host)? The lowest supported queue depth is one so we reserving a request may break some SCSI LLDs. Additionally, reserving one request may have a performance impact. Then the SCSI ML could copy the scsi_debug driver and give itself a pseudo host and hold a couple of well known (wn) scsi_cmnd objects (fakes) that are repurposed for resets. Then when the ML/LLD is finished with that wn request, it is placed back in the ML pool. BTW, it is not clear to me why a struct scsi_cmnd pointer is passed to the eh_*_reset_handler() callbacks. Has it ever been considered to pass a struct scsi_device pointer to these callback functions instead? In other words, are there any eh_*_reset_handler() callbacks that use more information from struct scsi_cmnd than the device pointer? Looks like an OO paradigm giving that set of eh_* functions the same signature where the common argument can be reduced to the appropriate object. Perhaps new signatures could be added to struct scsi_host_template: int (* eh_act_lu_reset_handler)(struct scsi_device *); int (* eh_act_target_reset_handler)(struct scsi_host *); int (* eh_act_bus_reset_handler)(struct scsi_host *); int (* eh_act_host_reset_handler)(struct scsi_host *); or collapse the last 3 into: int (* eh_host_managed_reset_handler)(struct scsi_host *, enum shost_man_reset); Doug Gilbert
Re: [PATCH v5 4/7] dt-bindings: phy: Add document for phy-mtk-ufs
On Wed, Mar 13, 2019 at 11:09 PM Stanley Chu wrote: > > Add UFS M-PHY node document for MediaTek SoC chips. > > Signed-off-by: Stanley Chu > --- > .../devicetree/bindings/phy/phy-mtk-ufs.txt | 38 +++ > 1 file changed, 38 insertions(+) > create mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt Reviewed-by: Rob Herring
Re: [PATCH v3 5/7] dt-bindings: scsi: ufs: Add document for ufs-mediatek
On Thu, Mar 14, 2019 at 3:46 AM Marc Gonzalez wrote: > > On 13/03/2019 20:48, Rob Herring wrote: > > Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions: > - -fixed-regulator : boolean property specifying that -supply is > a fixed regulator. > > > There are no users of that property in tree and doesn't look like > > adding it was ever reviewed. We have standard ways to handle this and > > don't need a custom property. > > FWIW, it seems to come from downstream: The question would be is downstream compliant with the upstream binding. If so, then we shouldn't really break things as that's just out of tree which is fine. Or we just need a better explanation of why it is needed. MMC has some properties related to card voltages for example. Maybe the need is similar. Rob
[PATCH 0/5] smartpqi updates
These patches are based on Linus's tree The changes are: - smartpqi-increase-LUN-reset-timeout . resets can take longer than 30 seconds. - smartpqi-add-H3C-controller-IDs . add support for H3C controllers - smartpqi-update-copyright . add in Microchip, update Microsemi - smartpqi-add-spdx . add in spdx - smartpqi-bump-driver-version --- Ajish Koshy (1): smartpqi: add H3C controller IDs Don Brace (3): smartpqi: update copyright smartpqi: add spdx smartpqi: bump driver version Kevin Barnett (1): smartpqi: increase LUN reset timeout drivers/scsi/smartpqi/Makefile |1 drivers/scsi/smartpqi/smartpqi.h | 15 ++- drivers/scsi/smartpqi/smartpqi_init.c | 49 +++- drivers/scsi/smartpqi/smartpqi_sas_transport.c | 15 ++- drivers/scsi/smartpqi/smartpqi_sis.c | 15 ++- drivers/scsi/smartpqi/smartpqi_sis.h | 15 ++- 6 files changed, 48 insertions(+), 62 deletions(-) -- Signature
[PATCH 1/5] smartpqi: increase LUN reset timeout
From: Kevin Barnett
Reviewed-by: Scott Benesh
Reviewed-by: David Carroll
Reviewed-by: Kevin Barnett
Signed-off-by: Kevin Barnett
Signed-off-by: Don Brace
---
drivers/scsi/smartpqi/smartpqi_init.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/smartpqi/smartpqi_init.c
b/drivers/scsi/smartpqi/smartpqi_init.c
index 5d9ccbab7581..90ce0f3097a0 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -5654,9 +5654,11 @@ static int pqi_lun_reset(struct pqi_ctrl_info *ctrl_info,
return rc;
}
+/* Performs a reset at the LUN level. */
+
#define PQI_LUN_RESET_RETRIES 3
#define PQI_LUN_RESET_RETRY_INTERVAL_MSECS 1
-/* Performs a reset at the LUN level. */
+#define PQI_LUN_RESET_PENDING_IO_TIMEOUT_SECS 120
static int _pqi_device_reset(struct pqi_ctrl_info *ctrl_info,
struct pqi_scsi_dev *device)
@@ -5667,12 +5669,12 @@ static int _pqi_device_reset(struct pqi_ctrl_info
*ctrl_info,
for (retries = 0;;) {
rc = pqi_lun_reset(ctrl_info, device);
- if (rc != -EAGAIN ||
- ++retries > PQI_LUN_RESET_RETRIES)
+ if (rc != -EAGAIN || ++retries > PQI_LUN_RESET_RETRIES)
break;
msleep(PQI_LUN_RESET_RETRY_INTERVAL_MSECS);
}
- timeout_secs = rc ? PQI_LUN_RESET_TIMEOUT_SECS : NO_TIMEOUT;
+
+ timeout_secs = rc ? PQI_LUN_RESET_PENDING_IO_TIMEOUT_SECS : NO_TIMEOUT;
rc |= pqi_device_wait_for_pending_io(ctrl_info, device, timeout_secs);
@@ -5701,6 +5703,7 @@ static int pqi_device_reset(struct pqi_ctrl_info
*ctrl_info,
pqi_device_reset_done(device);
mutex_unlock(&ctrl_info->lun_reset_mutex);
+
return rc;
}
@@ -5731,6 +5734,7 @@ static int pqi_eh_device_reset_handler(struct scsi_cmnd
*scmd)
pqi_wait_until_ofa_finished(ctrl_info);
rc = pqi_device_reset(ctrl_info, device);
+
out:
dev_err(&ctrl_info->pci_dev->dev,
"reset of scsi %d:%d:%d:%d: %s\n",
[PATCH 4/5] smartpqi: add spdx
Reviewed-by: David Carroll Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Reviewed-by: Kevin Barnett Signed-off-by: Don Brace --- drivers/scsi/smartpqi/Makefile |1 + drivers/scsi/smartpqi/smartpqi.h | 10 +- drivers/scsi/smartpqi/smartpqi_init.c | 10 +- drivers/scsi/smartpqi/smartpqi_sas_transport.c | 10 +- drivers/scsi/smartpqi/smartpqi_sis.c | 10 +- drivers/scsi/smartpqi/smartpqi_sis.h | 10 +- 6 files changed, 6 insertions(+), 45 deletions(-) diff --git a/drivers/scsi/smartpqi/Makefile b/drivers/scsi/smartpqi/Makefile index a03a6edb0060..28985e508b5c 100644 --- a/drivers/scsi/smartpqi/Makefile +++ b/drivers/scsi/smartpqi/Makefile @@ -1,2 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_SCSI_SMARTPQI) += smartpqi.o smartpqi-objs := smartpqi_init.o smartpqi_sis.o smartpqi_sas_transport.o diff --git a/drivers/scsi/smartpqi/smartpqi.h b/drivers/scsi/smartpqi/smartpqi.h index 3ceaba9b24d9..e8e768849c70 100644 --- a/drivers/scsi/smartpqi/smartpqi.h +++ b/drivers/scsi/smartpqi/smartpqi.h @@ -1,18 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* *driver for Microsemi PQI-based storage controllers *Copyright (c) 2019 Microchip Technology Inc. and its subsidiaries *Copyright (c) 2016-2018 Microsemi Corporation *Copyright (c) 2016 PMC-Sierra, Inc. * - *This program is free software; you can redistribute it and/or modify - *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; version 2 of the License. - * - *This program is distributed in the hope that it will be useful, - *but WITHOUT ANY WARRANTY; without even the implied warranty of - *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - *NON INFRINGEMENT. See the GNU General Public License for more details. - * *Questions/Comments/Bugfixes to storage...@microchip.com * */ diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c index 9859426e2756..d0187bfa816a 100644 --- a/drivers/scsi/smartpqi/smartpqi_init.c +++ b/drivers/scsi/smartpqi/smartpqi_init.c @@ -1,18 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0 /* *driver for Microsemi PQI-based storage controllers *Copyright (c) 2019 Microchip Technology Inc. and its subsidiaries *Copyright (c) 2016-2018 Microsemi Corporation *Copyright (c) 2016 PMC-Sierra, Inc. * - *This program is free software; you can redistribute it and/or modify - *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; version 2 of the License. - * - *This program is distributed in the hope that it will be useful, - *but WITHOUT ANY WARRANTY; without even the implied warranty of - *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - *NON INFRINGEMENT. See the GNU General Public License for more details. - * *Questions/Comments/Bugfixes to storage...@microchip.com * */ diff --git a/drivers/scsi/smartpqi/smartpqi_sas_transport.c b/drivers/scsi/smartpqi/smartpqi_sas_transport.c index 4c4c6b1cd1e6..5cca1b9ef1f1 100644 --- a/drivers/scsi/smartpqi/smartpqi_sas_transport.c +++ b/drivers/scsi/smartpqi/smartpqi_sas_transport.c @@ -1,18 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0 /* *driver for Microsemi PQI-based storage controllers *Copyright (c) 2019 Microchip Technology Inc. and its subsidiaries *Copyright (c) 2016-2018 Microsemi Corporation *Copyright (c) 2016 PMC-Sierra, Inc. * - *This program is free software; you can redistribute it and/or modify - *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; version 2 of the License. - * - *This program is distributed in the hope that it will be useful, - *but WITHOUT ANY WARRANTY; without even the implied warranty of - *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - *NON INFRINGEMENT. See the GNU General Public License for more details. - * *Questions/Comments/Bugfixes to storage...@microchip.com * */ diff --git a/drivers/scsi/smartpqi/smartpqi_sis.c b/drivers/scsi/smartpqi/smartpqi_sis.c index fa365d02f88d..f0d6e88ba2c1 100644 --- a/drivers/scsi/smartpqi/smartpqi_sis.c +++ b/drivers/scsi/smartpqi/smartpqi_sis.c @@ -1,18 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0 /* *driver for Microsemi PQI-based storage controllers *Copyright (c) 2019 Microchip Technology Inc. and its subsidiaries *Copyright (c) 2016-2018 Microsemi Corporation *Copyright (c) 2016 PMC-Sierra, Inc. * - *This program is free software; you can redistribute it and/or modify - *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; version 2 of the License. - * - *This program is
[PATCH 2/5] smartpqi: add H3C controller IDs
From: Ajish Koshy
Reviewed-by: Scott Teel
Reviewed-by: Scott Benesh
Reviewed-by: David Carroll
Reviewed-by: Kevin Barnett
Signed-off-by: Ajish Koshy
Signed-off-by: Don Brace
---
drivers/scsi/smartpqi/smartpqi_init.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/scsi/smartpqi/smartpqi_init.c
b/drivers/scsi/smartpqi/smartpqi_init.c
index 90ce0f3097a0..d0ccf4f84ffb 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -7944,6 +7944,22 @@ static const struct pci_device_id pqi_pci_id_table[] = {
PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
0x152d, 0x8a37)
},
+ {
+ PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+ 0x193d, 0x1104)
+ },
+ {
+ PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+ 0x193d, 0x1105)
+ },
+ {
+ PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+ 0x193d, 0x1106)
+ },
+ {
+ PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+ 0x193d, 0x1107)
+ },
{
PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
0x193d, 0x8460)
[PATCH 5/5] smartpqi: bump driver version
Reviewed-by: Gerry Morong Reviewed-by: David Carroll Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Reviewed-by: Kevin Barnett Signed-off-by: Don Brace --- drivers/scsi/smartpqi/smartpqi_init.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c index d0187bfa816a..7100e80d0ab5 100644 --- a/drivers/scsi/smartpqi/smartpqi_init.c +++ b/drivers/scsi/smartpqi/smartpqi_init.c @@ -33,11 +33,11 @@ #define BUILD_TIMESTAMP #endif -#define DRIVER_VERSION "1.2.4-070" +#define DRIVER_VERSION "1.2.6-015" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 2 -#define DRIVER_RELEASE 4 -#define DRIVER_REVISION70 +#define DRIVER_RELEASE 6 +#define DRIVER_REVISION15 #define DRIVER_NAME"Microsemi PQI Driver (v" \ DRIVER_VERSION BUILD_TIMESTAMP ")"
[PATCH 3/5] smartpqi: update copyright
Reviewed-by: Gerry Morong Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Reviewed-by: David Carroll Reviewed-by: Kevin Barnett Signed-off-by: Don Brace --- drivers/scsi/smartpqi/smartpqi.h |5 +++-- drivers/scsi/smartpqi/smartpqi_init.c |5 +++-- drivers/scsi/smartpqi/smartpqi_sas_transport.c |5 +++-- drivers/scsi/smartpqi/smartpqi_sis.c |5 +++-- drivers/scsi/smartpqi/smartpqi_sis.h |5 +++-- 5 files changed, 15 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/smartpqi/smartpqi.h b/drivers/scsi/smartpqi/smartpqi.h index af962368818b..3ceaba9b24d9 100644 --- a/drivers/scsi/smartpqi/smartpqi.h +++ b/drivers/scsi/smartpqi/smartpqi.h @@ -1,6 +1,7 @@ /* *driver for Microsemi PQI-based storage controllers - *Copyright (c) 2016-2017 Microsemi Corporation + *Copyright (c) 2019 Microchip Technology Inc. and its subsidiaries + *Copyright (c) 2016-2018 Microsemi Corporation *Copyright (c) 2016 PMC-Sierra, Inc. * *This program is free software; you can redistribute it and/or modify @@ -12,7 +13,7 @@ *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or *NON INFRINGEMENT. See the GNU General Public License for more details. * - *Questions/Comments/Bugfixes to esc.storage...@microsemi.com + *Questions/Comments/Bugfixes to storage...@microchip.com * */ diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c index d0ccf4f84ffb..9859426e2756 100644 --- a/drivers/scsi/smartpqi/smartpqi_init.c +++ b/drivers/scsi/smartpqi/smartpqi_init.c @@ -1,6 +1,7 @@ /* *driver for Microsemi PQI-based storage controllers - *Copyright (c) 2016-2017 Microsemi Corporation + *Copyright (c) 2019 Microchip Technology Inc. and its subsidiaries + *Copyright (c) 2016-2018 Microsemi Corporation *Copyright (c) 2016 PMC-Sierra, Inc. * *This program is free software; you can redistribute it and/or modify @@ -12,7 +13,7 @@ *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or *NON INFRINGEMENT. See the GNU General Public License for more details. * - *Questions/Comments/Bugfixes to esc.storage...@microsemi.com + *Questions/Comments/Bugfixes to storage...@microchip.com * */ diff --git a/drivers/scsi/smartpqi/smartpqi_sas_transport.c b/drivers/scsi/smartpqi/smartpqi_sas_transport.c index 0e4ef215115f..4c4c6b1cd1e6 100644 --- a/drivers/scsi/smartpqi/smartpqi_sas_transport.c +++ b/drivers/scsi/smartpqi/smartpqi_sas_transport.c @@ -1,6 +1,7 @@ /* *driver for Microsemi PQI-based storage controllers - *Copyright (c) 2016-2017 Microsemi Corporation + *Copyright (c) 2019 Microchip Technology Inc. and its subsidiaries + *Copyright (c) 2016-2018 Microsemi Corporation *Copyright (c) 2016 PMC-Sierra, Inc. * *This program is free software; you can redistribute it and/or modify @@ -12,7 +13,7 @@ *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or *NON INFRINGEMENT. See the GNU General Public License for more details. * - *Questions/Comments/Bugfixes to esc.storage...@microsemi.com + *Questions/Comments/Bugfixes to storage...@microchip.com * */ diff --git a/drivers/scsi/smartpqi/smartpqi_sis.c b/drivers/scsi/smartpqi/smartpqi_sis.c index dcd11c6418cc..fa365d02f88d 100644 --- a/drivers/scsi/smartpqi/smartpqi_sis.c +++ b/drivers/scsi/smartpqi/smartpqi_sis.c @@ -1,6 +1,7 @@ /* *driver for Microsemi PQI-based storage controllers - *Copyright (c) 2016-2017 Microsemi Corporation + *Copyright (c) 2019 Microchip Technology Inc. and its subsidiaries + *Copyright (c) 2016-2018 Microsemi Corporation *Copyright (c) 2016 PMC-Sierra, Inc. * *This program is free software; you can redistribute it and/or modify @@ -12,7 +13,7 @@ *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or *NON INFRINGEMENT. See the GNU General Public License for more details. * - *Questions/Comments/Bugfixes to esc.storage...@microsemi.com + *Questions/Comments/Bugfixes to storage...@microchip.com * */ diff --git a/drivers/scsi/smartpqi/smartpqi_sis.h b/drivers/scsi/smartpqi/smartpqi_sis.h index d018cb9c3f82..eea3dd9d4ac9 100644 --- a/drivers/scsi/smartpqi/smartpqi_sis.h +++ b/drivers/scsi/smartpqi/smartpqi_sis.h @@ -1,6 +1,7 @@ /* *driver for Microsemi PQI-based storage controllers - *Copyright (c) 2016-2017 Microsemi Corporation + *Copyright (c) 2019 Microchip Technology Inc. and its subsidiaries + *Copyright (c) 2016-2018 Microsemi Corporation *Copyright (c) 2016 PMC-Sierra, Inc. * *This program is free software; you can redistribute it and/or modify @@ -12,7 +13,7 @@ *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or *NON INFRINGEMENT. See the GNU General Public License for more details. * - *Questions/Comments/Bugf
Re: [PATCH v3 5/7] dt-bindings: scsi: ufs: Add document for ufs-mediatek
Hi Rob and all, On Fri, 2019-03-15 at 00:44 +0800, Rob Herring wrote: > On Thu, Mar 14, 2019 at 3:46 AM Marc Gonzalez wrote: > > > > On 13/03/2019 20:48, Rob Herring wrote: > > > > Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions: > > - -fixed-regulator : boolean property specifying that -supply > > is a fixed regulator. > > > > > There are no users of that property in tree and doesn't look like > > > adding it was ever reviewed. We have standard ways to handle this and > > > don't need a custom property. > > > > FWIW, it seems to come from downstream: > > The question would be is downstream compliant with the upstream > binding. If so, then we shouldn't really break things as that's just > out of tree which is fine. > > Or we just need a better explanation of why it is needed. MMC has some > properties related to card voltages for example. Maybe the need is > similar. > For short-term, could this patch series be merged without "vcc" related property defined in dt-bindings (like PATCH V5 does)? Or using "vcc-supply" along with "vcc-fixed-regulator" with a detailed explanation can be accepted? ufs-mediatek can work fine without "vcc" related property but with a limitation that driver cannot control "vcc" power which is enabled by-default on MediaTek chipsets. For long-term, it seems to me that "-fixed-regulator" can be removed from both dt-bindings and UFS driver without impact, even for downstream usage found by Marc. If "-fixed-regulator" property is defined in device tree, such regulator will skip "current limit" assignment from "-max-microamp" property, and voltage range assignment from "vcc-supply-lp8" property (for vcc, vccq, and vccq2 only). If driver can handle above both cases correctly, "-fixed-regulator" can be removed. In MediaTek chipsets, "vcc-supply" can ignore above two properties. However if "vcc-fixed-regulator" is not added, driver will get fail during device tree probing due to undefined "vcc-max-microamp". If our target is removing "-fixed-regulator", we could try to fix and resolve above all. And if we do not merge "vcc" related property this time, after that we can add "vcc-supply" back to dt-bindings to provide vcc control capability in ufs-mediatek driver. Would you please provide any suggestions? > Rob
Re: [PATCH 00/26] qedf: Misc fixes for the driver.
Hi Martin, Kindly share the latest update on this. Thanks, ~Saurav -Original Message- From: Saurav Kashyap Date: Tuesday, 5 March 2019 at 4:29 PM To: "martin.peter...@oracle.com" Cc: "qlogic-storage-upstr...@cavium.com" , "linux-scsi@vger.kernel.org" Subject: [PATCH 00/26] qedf: Misc fixes for the driver. Resent-From: Resent-Date: Tuesday, 5 March 2019 at 4:29 PM Hi Martin, This series has misc bug fixes and code enchancements in flush routine, abort and TMF path. Kindly apply this series to scsi-queue at your earliest convenience. Thanks, ~Saurav Andrew Vasquez (1): qedf: Correct the memory barriers in qedf_ring_doorbell. Chad Dupuis (10): qedf: Do not retry ELS request if qedf_alloc_cmd fails. qedf: Correct xid range overlap between offloaded requests and libfc requests. qedf: Add missing return in qedf_post_io_req() in the fcport offload check. qedf: Simplify s/g list mapping. qedf: Use a separate completion for cleanup commands. qedf: Add missing fc_disc_init call after allocating lport. qedf: Add additional checks for io_req->sc_cmd validity. qedf: Wait for upload and link down processing during soft ctx reset. qedf: Add missing return in qedf_scsi_done(). qedf: Check both the FCF and fabric ID before servicing clear virtual link. Hannes Reinecke (4): qedf: missing kref_put in qedf_xmit() qedf: fixup locking in qedf_restart_rport() qedf: fixup bit operations. qedf: fc_rport_priv reference counting fixes Saurav Kashyap (7): qedf: Modify abort and tmf handler to handle edge condition and flush. qedf: Check for link state before processing LL2 packets and send fipvlan retries. qedf: Don't send ABTS for under run scenario. qedf: Check for tm_flags instead of cmd_type during cleanup. qedf: Correctly handle refcounting of rdata. qedf: Fix lport may be used uninitialezed warning. qedf: Update the driver version to 8.37.25.19. Shyam Sundar (4): qedf: Modify flush routine to handle all I/Os and TMF. qedf: Don't queue anything if upload is in progress. qedf: Add a flag to help debugging io_req which could not be cleaned. qedf: Cleanup rrq_work after QEDF_CMD_OUTSTANDING is cleared. drivers/scsi/qedf/qedf.h | 51 ++- drivers/scsi/qedf/qedf_debugfs.c | 2 - drivers/scsi/qedf/qedf_els.c | 72 +++- drivers/scsi/qedf/qedf_fip.c | 76 ++-- drivers/scsi/qedf/qedf_io.c | 736 ++- drivers/scsi/qedf/qedf_main.c| 249 + drivers/scsi/qedf/qedf_version.h | 8 +- 7 files changed, 903 insertions(+), 291 deletions(-) -- 1.8.3.1
