Re: [RFC PATCH v1 0/2] perf/smmuv3: dts get opt and simplify code
From: Rob Herring <robh@kernel.org>
Date: 2020-07-14 22:28:54
On Tue, Jul 14, 2020 at 1:48 AM Will Deacon [off-list ref] wrote:
Hi Rob, On Mon, Jul 13, 2020 at 05:15:55PM -0600, Rob Herring wrote:quoted
On Mon, Jul 13, 2020 at 09:46:58PM +0100, Will Deacon wrote:quoted
On Mon, 6 Jul 2020 19:22:44 +0800, Jay Chen wrote:quoted
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.quoted
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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel