linux-kernel - Re: [RFC v3 4/7] phy: qcom: Add QCOM SNPS eUSB2 repeater driver

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:   Tue, 7 Feb 2023 15:10:49 +0200
From:   Abel Vesa <abel.vesa@...aro.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Lee Jones <lee@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-phy@...ts.infradead.org
Subject: Re: [RFC v3 4/7] phy: qcom: Add QCOM SNPS eUSB2 repeater driver

On 23-02-07 15:03:39, Dmitry Baryshkov wrote:
> On Tue, 7 Feb 2023 at 14:25, Abel Vesa <abel.vesa@...aro.org> wrote:
> >
> > On 23-02-03 18:51:13, Dmitry Baryshkov wrote:
> > > On 02/02/2023 15:38, Abel Vesa wrote:
> > > > PM8550B contains a eUSB2 repeater used for making the eUSB2 from
> > > > SM8550 USB 2.0 compliant. This can be modelled SW-wise as a Phy.
> > > > So add a new phy driver for it.
> > > >
> > > > Signed-off-by: Abel Vesa <abel.vesa@...aro.org>
> > > > ---
> > > >   drivers/phy/qualcomm/Kconfig                  |   9 +
> > > >   drivers/phy/qualcomm/Makefile                 |   1 +
> > > >   .../phy/qualcomm/phy-qcom-eusb2-repeater.c    | 278 ++++++++++++++++++
> > > >   3 files changed, 288 insertions(+)
> > > >   create mode 100644 drivers/phy/qualcomm/phy-qcom-eusb2-repeater.c
> > > >
> >
> > [ ... ]
> >
> > > > +
> > > > +static int eusb2_repeater_init(struct phy *phy)
> > > > +{
> > > > +   struct eusb2_repeater *rptr = phy_get_drvdata(phy);
> > > > +   const struct eusb2_repeater_init_tbl *init_tbl = rptr->cfg->init_tbl;
> > > > +   int num = rptr->cfg->init_tbl_num;
> > > > +   int ret = 0;
> > > > +   u32 val;
> > > > +   int i;
> > > > +
> > > > +   ret = regulator_bulk_enable(rptr->cfg->num_vregs, rptr->vregs);
> > > > +   if (ret)
> > > > +           return ret;
> > > > +
> > > > +   regmap_update_bits(rptr->regmap, rptr->base + EUSB2_EN_CTL1,
> > > > +                           EUSB2_RPTR_EN, EUSB2_RPTR_EN);
> > > > +
> > > > +   for (i = 0; i < num; i++)
> > > > +           regmap_update_bits(rptr->regmap,
> > > > +                                   rptr->base + init_tbl[i].offset,
> > > > +                                   init_tbl[i].val, init_tbl[i].val);
> > >
> > > I'd move this to a separate function. Then you can use it in the set_mode()
> > > too.
> > >
> >
> > I don't think this is necessary in set_mode.
> 
> It's not necessary. However as set_mode() is also a sequence of simple
> register updates, it might be easy to have everything as an
> offset-mask-value table.

Yeah, but then you would reinit the repeater on set_mode, which should
not be done.

> 
> >
> > > > +
> > > > +   ret = regmap_read_poll_timeout(rptr->regmap,
> > > > +                                   rptr->base + EUSB2_RPTR_STATUS, val,
> > > > +                                   val & RPTR_OK, 10, 5);
> > > > +   if (ret)
> > > > +           dev_err(rptr->dev, "initialization timed-out\n");
> > > > +
> > > > +   return ret;
> > > > +}
> > > > +
> >
> > [ ... ]
> 
> 
> 
> -- 
> With best wishes
> Dmitry