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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 7 Feb 2023 15:03:39 +0200
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Abel Vesa <abel.vesa@...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 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.

>
> > > +
> > > +   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