linux-kernel - RE: [PATCH v3 4/5] scsi: ufs-exynos: add UFS host support for Exynos SoCs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 25 Mar 2020 22:00:36 +0530
From:   "Alim Akhtar" <alim.akhtar@...sung.com>
To:     "'Avri Altman'" <Avri.Altman@....com>, <robh+dt@...nel.org>,
        <devicetree@...r.kernel.org>, <linux-scsi@...r.kernel.org>
Cc:     <krzk@...nel.org>, <martin.petersen@...cle.com>,
        <kwmad.kim@...sung.com>, <stanley.chu@...iatek.com>,
        <cang@...eaurora.org>, <linux-samsung-soc@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 4/5] scsi: ufs-exynos: add UFS host support for
 Exynos SoCs

Hi Avri
Thanks for review, see my comment inline below

> -----Original Message-----
> From: Avri Altman <Avri.Altman@....com>
> Sent: 22 March 2020 17:54
> To: Alim Akhtar <alim.akhtar@...sung.com>; robh+dt@...nel.org;
> devicetree@...r.kernel.org; linux-scsi@...r.kernel.org
> Cc: krzk@...nel.org; martin.petersen@...cle.com; kwmad.kim@...sung.com;
> stanley.chu@...iatek.com; cang@...eaurora.org; linux-samsung-
> soc@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; linux-
> kernel@...r.kernel.org
> Subject: RE: [PATCH v3 4/5] scsi: ufs-exynos: add UFS host support for Exynos
> SoCs
> 
> > +static int exynos7_ufs_pre_link(struct exynos_ufs *ufs) {
> > +       struct ufs_hba *hba = ufs->hba;
> > +       u32 val = ufs->drv_data->uic_attr->pa_dbg_option_suite;
> Can pa_dbg_option_suite be replaced by a macro?
> 
Going forward, I have plan to add multiple Samsung/Exynos SoC variants, which will have its own drv_data. For that reason I kept it.
Let me have a relook on this.

> > +       exynos_ufs_disable_ov_tm(hba);
> > +
> > +       ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN),
> > 0xf);
> > +       ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN),
> > 0xf);
> A typo? Set PA_DBG_OPTION_SUITE_DYN twice?
> 
Ack, will change

> > +#define PWR_MODE_STR_LEN       64
> > +static int exynos_ufs_post_pwr_mode(struct ufs_hba *hba,
> > +                               struct ufs_pa_layer_attr *pwr_max,
> > +                               struct ufs_pa_layer_attr *pwr_req) {
> > +       struct exynos_ufs *ufs = ufshcd_get_variant(hba);
> > +       struct phy *generic_phy = ufs->phy;
> > +       struct uic_pwr_mode *pwr = &ufs->pwr_act;
> > +       char pwr_str[PWR_MODE_STR_LEN] = "";
> Un-needed complication IMO - all those snprintf that is.
> 
You mean pwr_str initialization is not needed here?

> > +
> > +static void exynos_ufs_fit_aggr_timeout(struct exynos_ufs *ufs) {
> > +       const u8 cntr_div = 40;
> Can be replaced by a macro?
> 
Sure, will change.

> > +struct exynos_ufs_drv_data exynos_ufs_drvs = {
> > +
> > +       .compatible             = "samsung,exynos7-ufs",
> > +       .uic_attr               = &exynos7_uic_attr,
> > +       .quirks                 = UFSHCD_QUIRK_PRDT_BYTE_GRAN |
> > +                                 UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR |
> > +                                 UFSHCI_QUIRK_BROKEN_HCE |
> > +                                 UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR,
> > +       .opts                   = EXYNOS_UFS_OPT_HAS_APB_CLK_CTRL |
> > +                                 EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL |
> > +                                 EXYNOS_UFS_OPT_BROKEN_RX_SEL_IDX,
> In what way opts are different from quirks?
> 
Similar to quirks, but only specific to controller local control, like related to APB interface and clock control.
These doesn't need a change in common ufshcd core. So kept as opts.
Will fix your comments and submit v4 soon.
Thanks.
> 
> Thanks,
> Avri