Re: [PATCH v11 1/4] firmware: qcom: scm: provide a read-modify-write function

[Mukesh Ojha]

On 2/17/2024 12:01 AM, Bjorn Andersson wrote:
> On Tue, Jan 09, 2024 at 02:34:10PM +0100, Linus Walleij wrote:
> > On Tue, Jan 9, 2024 at 2:24 PM Mukesh Ojha <quic_mojha@xxxxxxxxxxx> wrote:
> > > On 1/9/2024 6:44 PM, Linus Walleij wrote:
> > > > On Mon, Jan 8, 2024 at 4:28 PM Mukesh Ojha <quic_mojha@xxxxxxxxxxx> wrote:
> > > >
> > > > > It was realized by Srinivas K. that there is a need of
> > > > > read-modify-write scm exported function so that it can
> > > > > be used by multiple clients.
> > > > >
> > > > > Let's introduce qcom_scm_io_rmw() which masks out the bits
> > > > > and write the passed value to that bit-offset.
> > > > (...)
> > > > > +int qcom_scm_io_rmw(phys_addr_t addr, unsigned int mask, unsigned int val)
> > > > > +{
> > > > > +       unsigned int old, new;
> > > > > +       int ret;
> > > > > +
> > > > > +       if (!__scm)
> > > > > +               return -EINVAL;
> > > > > +
> > > > > +       spin_lock(&__scm->lock);
> > > > > +       ret = qcom_scm_io_readl(addr, &old);
> > > > > +       if (ret)
> > > > > +               goto unlock;
> > > > > +
> > > > > +       new = (old & ~mask) | (val & mask);
> > > > > +
> > > > > +       ret = qcom_scm_io_writel(addr, new);
> > > > > +unlock:
> > > > > +       spin_unlock(&__scm->lock);
> > > > > +       return ret;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(qcom_scm_io_rmw);
> > > >
> > > > This looks a lot like you are starting to re-invent regmaps
> > > > regmap_update_bits().
> > > >
> > > > If you are starting to realize you need more and more of
> > > > regmap, why not use regmap and its functions?
> > >
> > > I think, this discussion has happened already ..
> > >
> > > https://lore.kernel.org/lkml/CACRpkdb95V5GC81w8fiuLfx_V1DtWYpO33FOfMnArpJeC9SDQA@xxxxxxxxxxxxxx/
> >
> > That discussion ended with:
> >
> > [Bjorn]
> > > We'd still need qcom_scm_io_readl() and qcom_scm_io_writel() exported to
> > > implement the new custom regmap implementation - and the struct
> > > regmap_config needed in just pinctrl-msm alone would be larger than the
> > > one function it replaces.
> >
> > When you add more and more accessors the premise starts to
> > change, and it becomes more and more of a reimplementation.
> >
> > It may be time to actually fix this.
>
> Thought I had replied to this already, did we discuss this previously as
> well?
>
> My concern with expressing this as a regmap is that from the provider's
> point of view, the regmap would span the entire 32-bit address space.
> I'm guessing that there's something on the other side limiting what
> subregions are actually accessible for each platform/firmware
> configuration, but I'm not convinced that regmap a good abstraction...

To add more to it, in current series, we are just accessing single 
register for read/write and using regmap for this looks overkill to
me.

-Mukesh
> Regards,
> Bjorn
>
> > Yours,
> > Linus Walleij