On Wed, May 20, 2020 at 1:33 AM Will Deacon <will@xxxxxxxxxx> wrote:
>
> On Tue, May 19, 2020 at 12:51:25PM -0600, Rob Herring wrote:
> > On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
> > > +static ssize_t ddr_perf_identifier_show(struct device *dev,
> > > + struct device_attribute *attr,
> > > + char *page)
> > > +{
> > > + struct ddr_pmu *pmu = dev_get_drvdata(dev);
> > > +
> > > + return sprintf(page, "%s\n", pmu->devtype_data->identifier);
> >
> > Why do we need yet another way to identify the SoC from userspace?
>
> I also really dislike this. What's the preferred way to identify the SoC
> from userspace?
/proc/cpuinfo? ;)
For an non-firmware specific case, I'd say soc_device should be. I'd
guess ACPI systems don't use it and for them it's dmidecode typically.
The other problem I have with soc_device is it is optional.
> It's needed so that the perf userspace tool can describe
> perf events that are supported for the PMU, as this isn't probe-able
> directly from the hardware. We have the same issue with the SMMUv3 PMCG [1],
> and so we need to solve the problem for both DT and ACPI.
>
> Will
>
> [1] https://lore.kernel.org/r/1587120634-19666-1-git-send-email-john.garry@xxxxxxxxxx
At a minimum, it seems like 'identifier' should be moved into the perf
core if that's an attr we want to keep.
Rob
