[GIT PULL] Qualcomm driver updates for v6.3

[Bjorn Andersson]

On Mon, Jan 30, 2023 at 04:18:45PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 26, 2023, at 17:30, Bjorn Andersson wrote:
> > The following changes since commit 6049aae52392539e505bfb8ccbcff3c26f1d2f0b:
> >
> > ----------------------------------------------------------------
> > Qualcomm driver updates for v6.3
> >
> > This introduces a new driver for the Data Capture and Compare block,
> > which provides a mechanism for capturing hardware state (access MMIO
> > registers) either upon request of triggered automatically e.g. upon a
> > watchdog bite, for post mortem analysis.
> >
> > The remote filesystem memory share driver gains support for having its
> > memory bound to more than a single VMID.
> >
> > The SCM driver gains the minimal support needed to support a new
> > mechanism where secure world can put calls on hold and later request
> > them to be retried.
> >
> > Support for the new SA8775P platform is added to rpmhpd, QDU1000 is
> > added to the SCM driver and a long list of platforms are added to the
> > socinfo driver. Support for socinfo data revision 16 is also introduced.
> >
> > Lastly a driver to program the ramp controller in MSM8976 is introduced.
> 
> Hi Bjorn,
> 
> I don't feel comfortable merging the DCC driver through drivers/soc/
> at this point: This is the first time I see the driver and it introduces
> a complex user space ABI that I have no time to review as part of the
> merge process.
> 

The DCC driver has made 22 versions over the last 23 months, but now
that I look back I do agree that the recipients list has been too
limited.

Further more, due to the complexity of the ABI I steered this towards
debugfs, with the explicit mentioning that we will change the interface
if needed - in particular since not a lot of review interest has
been shown...

> I usually try to avoid adding any custom user space interfaces
> in drivers/soc, as these tend to be things that end up being
> similar to other chips and need a generic interface.
> 

I have no concern with that, but I'm not able to suggest an existing
subsystem where this would fit.

> In particular I don't see an explanation about how the new interface
> relates to the established drivers/hwtracing/ subsystem and why it
> shouldn't be part of that (adding the hwtracing and coresight
> maintainers to Cc in case they have looked at this already).
> 

To my knowledge the hwtracing framework is an interface for
enabling/disabling traces and then you get a stream of trace data out of
it.

With DCC you essentially write a small "program" to be run at the time
of an exception (or triggered manually). When the "program" is run it
acquire data from mmio interfaces and stores data in sram, which can
then be retrieved - possibly after the fatal reset of the system.

Perhaps I've misunderstood the hwtracing framework, please help me steer
Souradeep towards a subsystem you find suitable for this functionality.

> Can you send an updated pull request that leaves out the
> DCC driver until we have clarified these points?
> 

I will send a new pull request, with the driver addition reverted. I
don't think there's anything controversial with the DT binding, so let's
keep that and the dts nodes (we can move the yaml if a better home is
found...).

Regards,
Bjorn