[RFC PATCH v1 0/2] perf/smmuv3: dts get opt and simplify code

[Rob Herring]

On Tue, Jul 14, 2020 at 1:48 AM Will Deacon <will at kernel.org> wrote:
>
> Hi Rob,
>
> On Mon, Jul 13, 2020 at 05:15:55PM -0600, Rob Herring wrote:
> > On Mon, Jul 13, 2020 at 09:46:58PM +0100, Will Deacon wrote:
> > > On Mon, 6 Jul 2020 19:22:44 +0800, Jay Chen wrote:
> > > > This patch set firstly to simplify the code in smmu pmu probe,
> > > > and then support to get options in dts
> > > >
> > > > Jay Chen (2):
> > > >   perf/smmuv3: To simplify code for ioremap page in pmcg
> > > >   perf/smmuv3: To support the dts to get options
> > > >
> > > > [...]
> > >
> > > Applied to will (for-next/perf), thanks!
> >
> > Without a binding document for the undocumented property and
> > compatible string!?
>
> No, I only took the second patch ("To simplify code...")! It would be nice
> if b4 was a big clearer about that when cherry-picking, but I'm not sure
> exactly what it could do. Maybe if it only replied to the patch being
> picked, rather than the cover letter?

Humm, I thought the default b4 reply did list exactly which patches
were applied. See broonie's replies for example which are using it I
think. Maybe you lose that if not using the default template.

>
> I'm usually pretty careful about avoiding DT changes without your ack.
>
> > Is the 'arm-smmu-v3-pmcg' actually a separate block from the SMMU? Or is
> > this just an add a compatible to instantiate a driver?
>
> Not quite sure how to answer that one... afaik, the PMCG is a bunch of
> distributed counter blocks that may or may not be present and are driven
> entirely independently of the rest of the SMMU, which is a lot more
> standardised. In fact, I'm not sure why ARM_SMMU_V3_PMU depends on
> ARM_SMMU_V3, it builds perfectly fine without that (and with the main
> driver disabled).

Okay, seems that a separate node or nodes is warranted.

Rob