[PATCH v7 09/25] coresight: etm3x: allow etm3x to be built as a module

[Suzuki K Poulose]

On 08/05/2020 01:54 PM, Mike Leach wrote:
> Hi,
> 
> On Wed, 5 Aug 2020 at 12:05, Suzuki K Poulose <suzuki.poulose at arm.com> wrote:
>>
>> On 08/05/2020 03:54 AM, Tingwei Zhang wrote:
>>> From: Kim Phillips <kim.phillips at arm.com>
>>>
>>> Allow to build coresight-etm3x as a module, for ease of development.
>>>
>>> - Kconfig becomes a tristate, to allow =m
>>> - append -core to source file name to allow module to
>>>     be called coresight-etm3x by the Makefile
>>> - add an etm_remove function, for module unload
>>> - add a MODULE_DEVICE_TABLE for autoloading on boot
>>>
>>> Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
>>> Cc: Leo Yan <leo.yan at linaro.org>
>>> Cc: Alexander Shishkin <alexander.shishkin at linux.intel.com>
>>> Cc: Randy Dunlap <rdunlap at infradead.org>
>>> Cc: Suzuki K Poulose <Suzuki.Poulose at arm.com>
>>> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>>> Cc: Russell King <linux at armlinux.org.uk>
>>> Signed-off-by: Kim Phillips <kim.phillips at arm.com>
>>> Signed-off-by: Tingwei Zhang <tingwei at codeaurora.org>
>>> Reviewed-by: Mike Leach <mike.leach at linaro.org>


>>>        bool "CoreSight Embedded Trace Macrocell 4.x driver"
>>>        depends on ARM64
>>> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
>>> index 19497d1d92bf..d619cfd0abd8 100644
>>> --- a/drivers/hwtracing/coresight/Makefile
>>> +++ b/drivers/hwtracing/coresight/Makefile
>>> @@ -11,7 +11,8 @@ obj-$(CONFIG_CORESIGHT_SINK_TPIU) += coresight-tpiu.o
>>>    obj-$(CONFIG_CORESIGHT_SINK_ETBV10) += coresight-etb10.o
>>>    obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
>>>                                           coresight-replicator.o
>>> -obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o \
>>> +obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o
>>> +coresight-etm3x-y := coresight-etm3x-core.o coresight-etm-cp14.o \
>>>                                        coresight-etm3x-sysfs.o
>>>    obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>>>                                        coresight-etm4x-sysfs.o
>>> diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
>>> similarity index 97%
>>> rename from drivers/hwtracing/coresight/coresight-etm3x.c
>>> rename to drivers/hwtracing/coresight/coresight-etm3x-core.c
>>> index bf22dcfd3327..82b333c40006 100644
>>> --- a/drivers/hwtracing/coresight/coresight-etm3x.c
>>> +++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
>>> @@ -895,6 +895,23 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
>>>        return ret;
>>>    }
>>>
>>> +static int __exit etm_remove(struct amba_device *adev)
>>> +{
>>> +     struct etm_drvdata *drvdata = dev_get_drvdata(&adev->dev);
>>> +
>>> +     etm_perf_symlink(drvdata->csdev, false);
>>> +
>>> +     if (--etm_count == 0) {
>>
>> Could there be multiple instances of remove running in parallel ? I
>> believe we need some sort of a protection here to avoid racing.
>>
>> Or even better, I would recommend leaving the notifiers registered
>> at module_init and removed at the cleanup of the module, just like
>> we are doing for etm4x driver, and get rid of this silly scheme.
> 
> I would agree that this needs addressing but this is an independent
> problem that could be better served by a separate patchset, rather

I agree that it is an independent problem, but this series makes it more
exposed, i.e, calling the probe/remove at runtime in any order.
So, pushing this series before that is fixed is going to cause trouble,
if they both end up in different releases.

> than add feature creep to this set. The same schema is used in the CTI
> driver as well and needs fixing there.
> 
>> Like here :
>>
>> https://lkml.kernel.org/r/20200729051310.18436-1-saiprakash.ranjan@codeaurora.org
>>
> 
> This conflicts with the init / exit fns created for module loading in
> the etm4x part of this set..
> 
> A decision needs to be made on which set gets applied first - my view
> is that the module set could go first, then a set fixing the PM
> registration issues for all three affected drivers to be applied next.

I think we should do the opposite. Fixing the hotplug is fairly straight
forward, and need not block on this large series.

Cheers
Suzuki