On 10/05/2022 12:18, Yicong Yang wrote:
> On 2022/5/10 17:46, James Clark wrote:
>>
>>
>> On 07/04/2022 13:58, Yicong Yang wrote:
>>> HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated
>>> Endpoint(RCiEP) device, providing the capability to dynamically monitor and
>>> tune the PCIe traffic, and trace the TLP headers.
>>>
>>> Add the driver for the device to enable the trace function. Register PMU
>>> device of PTT trace, then users can use trace through perf command. The
>>> driver makes use of perf AUX trace and support following events to
>>> configure the trace:
>>>
>>> - filter: select Root port or Endpoint to trace
>>> - type: select the type of traced TLP headers
>>> - direction: select the direction of traced TLP headers
>>> - format: select the data format of the traced TLP headers
>>>
>>> This patch adds the driver part of PTT trace. The perf command support of
>>> PTT trace is added in the following patch.
>>>
>>> Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com>
>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
>>> ---
>>> drivers/Makefile | 1 +
>>> drivers/hwtracing/Kconfig | 2 +
>>> drivers/hwtracing/ptt/Kconfig | 12 +
>>> drivers/hwtracing/ptt/Makefile | 2 +
>>> drivers/hwtracing/ptt/hisi_ptt.c | 874 +++++++++++++++++++++++++++++++
>>> drivers/hwtracing/ptt/hisi_ptt.h | 166 ++++++
>>> 6 files changed, 1057 insertions(+)
>>> create mode 100644 drivers/hwtracing/ptt/Kconfig
>>> create mode 100644 drivers/hwtracing/ptt/Makefile
>>> create mode 100644 drivers/hwtracing/ptt/hisi_ptt.c
>>> create mode 100644 drivers/hwtracing/ptt/hisi_ptt.h
>>>
>>> diff --git a/drivers/Makefile b/drivers/Makefile
>>> index 020780b6b4d2..662d50599467 100644
>>> --- a/drivers/Makefile
>>> +++ b/drivers/Makefile
>>> @@ -175,6 +175,7 @@ obj-$(CONFIG_USB4) += thunderbolt/
>>> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
>>> obj-y += hwtracing/intel_th/
>>> obj-$(CONFIG_STM) += hwtracing/stm/
>>> +obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
>>> obj-$(CONFIG_ANDROID) += android/
>>> obj-$(CONFIG_NVMEM) += nvmem/
>>> obj-$(CONFIG_FPGA) += fpga/
>>> diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
>>> index 13085835a636..911ee977103c 100644
>>> --- a/drivers/hwtracing/Kconfig
>>> +++ b/drivers/hwtracing/Kconfig
>>> @@ -5,4 +5,6 @@ source "drivers/hwtracing/stm/Kconfig"
>>>
>>> source "drivers/hwtracing/intel_th/Kconfig"
>>>
>>> +source "drivers/hwtracing/ptt/Kconfig"
>>> +
>>> endmenu
>>> diff --git a/drivers/hwtracing/ptt/Kconfig b/drivers/hwtracing/ptt/Kconfig
>>> new file mode 100644
>>> index 000000000000..8902a6f27563
>>> --- /dev/null
>>> +++ b/drivers/hwtracing/ptt/Kconfig
>>> @@ -0,0 +1,12 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only
>>> +config HISI_PTT
>>> + tristate "HiSilicon PCIe Tune and Trace Device"
>>> + depends on ARM64 || (COMPILE_TEST && 64BIT)
>>> + depends on PCI && HAS_DMA && HAS_IOMEM && PERF_EVENTS
>>> + help
>>> + HiSilicon PCIe Tune and Trace Device exists as a PCIe RCiEP
>>> + device, and it provides support for PCIe traffic tuning and
>>> + tracing TLP headers to the memory.
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called hisi_ptt.
>>> diff --git a/drivers/hwtracing/ptt/Makefile b/drivers/hwtracing/ptt/Makefile
>>> new file mode 100644
>>> index 000000000000..908c09a98161
>>> --- /dev/null
>>> +++ b/drivers/hwtracing/ptt/Makefile
>>> @@ -0,0 +1,2 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +obj-$(CONFIG_HISI_PTT) += hisi_ptt.o
>>> diff --git a/drivers/hwtracing/ptt/hisi_ptt.c b/drivers/hwtracing/ptt/hisi_ptt.c
>>> new file mode 100644
>>> index 000000000000..242b41870380
>>> --- /dev/null
>>> +++ b/drivers/hwtracing/ptt/hisi_ptt.c
>>> @@ -0,0 +1,874 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Driver for HiSilicon PCIe tune and trace device
>>> + *
>>> + * Copyright (c) 2022 HiSilicon Technologies Co., Ltd.
>>> + * Author: Yicong Yang <yangyicong(a)hisilicon.com>
>>> + */
>>> +
>>> +#include <linux/bitfield.h>
>>> +#include <linux/bitops.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/dma-iommu.h>
>>> +#include <linux/dma-mapping.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/io.h>
>>> +#include <linux/iommu.h>
>>> +#include <linux/iopoll.h>
>>> +#include <linux/module.h>
>>> +#include <linux/sysfs.h>
>>> +#include <linux/vmalloc.h>
>>> +
>>> +#include "hisi_ptt.h"
>>> +
>>> +static u16 hisi_ptt_get_filter_val(struct pci_dev *pdev)
>>> +{
>>> + if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
>>> + return BIT(HISI_PCIE_CORE_PORT_ID(PCI_SLOT(pdev->devfn)));
>>> +
>>> + return PCI_DEVID(pdev->bus->number, pdev->devfn);
>>> +}
>>> +
>>> +static bool hisi_ptt_wait_trace_hw_idle(struct hisi_ptt *hisi_ptt)
>>> +{
>>> + u32 val;
>>> +
>>> + return !readl_poll_timeout_atomic(hisi_ptt->iobase + HISI_PTT_TRACE_STS,
>>> + val, val & HISI_PTT_TRACE_IDLE,
>>> + HISI_PTT_WAIT_POLL_INTERVAL_US,
>>> + HISI_PTT_WAIT_TRACE_TIMEOUT_US);
>>> +}
>>> +
>>> +static bool hisi_ptt_wait_dma_reset_done(struct hisi_ptt *hisi_ptt)
>>> +{
>>> + u32 val;
>>> +
>>> + return !readl_poll_timeout_atomic(hisi_ptt->iobase + HISI_PTT_TRACE_WR_STS,
>>> + val, !val, HISI_PTT_RESET_POLL_INTERVAL_US,
>>> + HISI_PTT_RESET_TIMEOUT_US);
>>> +}
>>> +
>>> +static void hisi_ptt_free_trace_buf(struct hisi_ptt *hisi_ptt)
>>> +{
>>> + struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
>>> + struct device *dev = &hisi_ptt->pdev->dev;
>>> + int i;
>>> +
>>> + if (!ctrl->trace_buf)
>>> + return;
>>> +
>>> + for (i = 0; i < HISI_PTT_TRACE_BUF_CNT; i++) {
>>> + if (ctrl->trace_buf[i].addr)
>>> + dmam_free_coherent(dev, HISI_PTT_TRACE_BUF_SIZE,
>>> + ctrl->trace_buf[i].addr,
>>> + ctrl->trace_buf[i].dma);
>>> + }
>>> +
>>> + devm_kfree(dev, ctrl->trace_buf);
>>> + ctrl->trace_buf = NULL;
>>> +}
>>> +
>>> +static int hisi_ptt_alloc_trace_buf(struct hisi_ptt *hisi_ptt)
>>> +{
>>> + struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
>>> + struct device *dev = &hisi_ptt->pdev->dev;
>>> + int i;
>>> +
>>> + hisi_ptt->trace_ctrl.buf_index = 0;
>>> +
>>> + /* If the trace buffer has already been allocated, zero it. */
>>> + if (ctrl->trace_buf) {
>>> + for (i = 0; i < HISI_PTT_TRACE_BUF_CNT; i++)
>>> + memset(ctrl->trace_buf[i].addr, 0, HISI_PTT_TRACE_BUF_SIZE);
>>> + return 0;
>>> + }
>>> +
>>> + ctrl->trace_buf = devm_kcalloc(dev, HISI_PTT_TRACE_BUF_CNT,
>>> + sizeof(struct hisi_ptt_dma_buffer), GFP_KERNEL);
>>> + if (!ctrl->trace_buf)
>>> + return -ENOMEM;
>>> +
>>> + for (i = 0; i < HISI_PTT_TRACE_BUF_CNT; ++i) {
>>> + ctrl->trace_buf[i].addr = dmam_alloc_coherent(dev, HISI_PTT_TRACE_BUF_SIZE,
>>> + &ctrl->trace_buf[i].dma,
>>> + GFP_KERNEL);
>>> + if (!ctrl->trace_buf[i].addr) {
>>> + hisi_ptt_free_trace_buf(hisi_ptt);
>>> + return -ENOMEM;
>>> + }
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void hisi_ptt_trace_end(struct hisi_ptt *hisi_ptt)
>>> +{
>>> + writel(0, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>>> + hisi_ptt->trace_ctrl.started = false;
>>> +}
>>> +
>>> +static int hisi_ptt_trace_start(struct hisi_ptt *hisi_ptt)
>>> +{
>>> + struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
>>> + u32 val;
>>> + int i;
>>> +
>>> + /* Check device idle before start trace */
>>> + if (!hisi_ptt_wait_trace_hw_idle(hisi_ptt)) {
>>> + pci_err(hisi_ptt->pdev, "Failed to start trace, the device is still busy\n");
>>> + return -EBUSY;
>>> + }
>>> +
>>> + ctrl->started = true;
>>> +
>>> + /* Reset the DMA before start tracing */
>>> + val = readl(hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>>> + val |= HISI_PTT_TRACE_CTRL_RST;
>>> + writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>>> +
>>> + hisi_ptt_wait_dma_reset_done(hisi_ptt);
>>> +
>>> + val = readl(hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>>> + val &= ~HISI_PTT_TRACE_CTRL_RST;
>>> + writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>>> +
>>> + /* Clear the interrupt status */
>>> + writel(HISI_PTT_TRACE_INT_STAT_MASK, hisi_ptt->iobase + HISI_PTT_TRACE_INT_STAT);
>>> + writel(0, hisi_ptt->iobase + HISI_PTT_TRACE_INT_MASK);
>>> +
>>> + /* Configure the trace DMA buffer */
>>> + for (i = 0; i < HISI_PTT_TRACE_BUF_CNT; i++) {
>>> + writel(lower_32_bits(ctrl->trace_buf[i].dma),
>>> + hisi_ptt->iobase + HISI_PTT_TRACE_ADDR_BASE_LO_0 +
>>> + i * HISI_PTT_TRACE_ADDR_STRIDE);
>>> + writel(upper_32_bits(ctrl->trace_buf[i].dma),
>>> + hisi_ptt->iobase + HISI_PTT_TRACE_ADDR_BASE_HI_0 +
>>> + i * HISI_PTT_TRACE_ADDR_STRIDE);
>>> + }
>>> + writel(HISI_PTT_TRACE_BUF_SIZE, hisi_ptt->iobase + HISI_PTT_TRACE_ADDR_SIZE);
>>> +
>>> + /* Set the trace control register */
>>> + val = FIELD_PREP(HISI_PTT_TRACE_CTRL_TYPE_SEL, ctrl->type);
>>> + val |= FIELD_PREP(HISI_PTT_TRACE_CTRL_RXTX_SEL, ctrl->direction);
>>> + val |= FIELD_PREP(HISI_PTT_TRACE_CTRL_DATA_FORMAT, ctrl->format);
>>> + val |= FIELD_PREP(HISI_PTT_TRACE_CTRL_TARGET_SEL, hisi_ptt->trace_ctrl.filter);
>>> + if (!hisi_ptt->trace_ctrl.is_port)
>>> + val |= HISI_PTT_TRACE_CTRL_FILTER_MODE;
>>> +
>>> + /* Start the Trace */
>>> + val |= HISI_PTT_TRACE_CTRL_EN;
>>> + writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int hisi_ptt_update_aux(struct hisi_ptt *hisi_ptt, int index, bool stop)
>>> +{
>>> + struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
>>> + struct perf_output_handle *handle = &ctrl->handle;
>>> + struct perf_event *event = handle->event;
>>> + struct hisi_ptt_pmu_buf *buf;
>>> + void *addr;
>>> +
>>> + buf = perf_get_aux(handle);
>>> + if (!buf || !handle->size)
>>> + return -EINVAL;
>>> +
>>> + addr = ctrl->trace_buf[ctrl->buf_index].addr;
>>> +
>>> + memcpy(buf->base + buf->pos, addr, HISI_PTT_TRACE_BUF_SIZE);
>>> + memset(addr, 0, HISI_PTT_TRACE_BUF_SIZE);
>>
>> Hi Kicong,
>>
>> I also have the same comment as Leo here, I don't think the memset is
>> required.
>>
>
> It's necessary in the current approach as we always commit HISI_PTT_TRACE_BUF_SIZE
> data but the buffer maybe partly filled (called when perf going to stopp, not by the
> interrupt). The buffer is cleared so the unfilled part of the buffer will have
> empty data (normal traced TLP headers won't be all 0), then the user can distinguish
> the valid part of the data.
>
> I'm trying to only copy the traced data rather than the whole buffer then the
> clear operation here will be unnecessary. The hardware provide a register indicating
> which offset of which buffer it's currently writing to and it canbe used here.
If only the traced data is copied rather than the full buffer, isn't that what
perf_aux_output_end() is for? Perf will only read up to the point where you
say the buffer is filled to, it won't go and read the zeros if you didn't tell
it to by emitting perf_aux_output_end() for more data than was written.
If you are having to write zeros to detect which bits of the buffer is filled
or not it sounds like those zero parts are making it into the perf file and are
wasting disk space and CPU cycles to copy them.
>
>>> + buf->pos += HISI_PTT_TRACE_BUF_SIZE;
>>> +
>>> + if (stop) {
>>> + perf_aux_output_end(handle, buf->pos);
>>> + } else if (buf->length - buf->pos < HISI_PTT_TRACE_BUF_SIZE) {
>>> + perf_aux_output_skip(handle, buf->length - buf->pos);
>>
>> perf_aux_output_skip() can also return an error so should probably also
>> be checked like perf_aux_output_begin()
>>
>
> ok it should be checked.
>
>> I'm also wondering why there is a skip for every output_end()? Is that
>> to avoid having two memcpy calls to handle the wrap around if the data
>> to be copied goes past the end of the aux buffer?
>>
>> For example if your buffers are 4MB each and the aux buffer that the
>> user picked isn't a multiple of 4 I can see you needing to write the
>> first part of the 4MB to the end of the aux buffer and then the last
>> part to the beginning which would be two memcpy() calls. And then a
>> skip wouldn't be required.
>>
>
> I intended to handle the case that AUX buffer is not a multiple of 4 MiB.
> When the resident AUX buffer size is less than 4MiB, we're not going to
> commit data to it and will apply a new AUX buffer instead. I think you're
> right that the perf_aux_output_skip() is unnecessary here. Thanks for
> catching this.
>
>> I looked at all the other uses of perf_output_end() and perf_output_skip()
>> in the kernel and didn't see a pattern like yours so it seems suspicous to
>> me. Maybe at least some comments around this section are needed.
>>
>
> Will add some comments of the handling here.
>
> Regards,
> Yicong
Add support for UltraSoc System Memory Buffer.
Change since v4:
- Add a simple document of SMB driver according to Suzuki's comment.
- Address the comments from Suzuki.
- https://lore.kernel.org/linux-arm-kernel/20220128061755.31909-1-liuqi115@hu…
Change since v3:
- Modify the file header according to community specifications.
- Address the comments from Mathieu.
- Link:https://lore.kernel.org/linux-arm-kernel/20211118110016.40398-1-liuqi1…
Change since v2:
- Move ultrasoc driver to drivers/hwtracing/coresight.
- Link:https://lists.linaro.org/pipermail/coresight/2021-November/007310.html
Change since v1:
- Drop the document of UltraSoc according to Mathieu's comment.
- Add comments to explain some private hardware settings.
- Address the comments from Mathieu.
- Link: https://lists.linaro.org/pipermail/coresight/2021-August/006842.html
Change since RFC:
- Move driver to drivers/hwtracing/coresight/ultrasoc.
- Remove ultrasoc-axi-com.c, as AXI-COM doesn't need to be configured in
basic tracing function.
- Remove ultrasoc.c as SMB does not need to register with the ultrasoc core.
- Address the comments from Mathieu and Suzuki.
- Link: https://lists.linaro.org/pipermail/coresight/2021-June/006535.html
Qi Liu (2):
drivers/coresight: Add UltraSoc System Memory Buffer driver
Documentation: Add document for UltraSoc SMB drivers
.../trace/coresight/ultrasoc-smb.rst | 79 +++
drivers/hwtracing/coresight/Kconfig | 10 +
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/ultrasoc-smb.c | 643 ++++++++++++++++++
drivers/hwtracing/coresight/ultrasoc-smb.h | 106 +++
5 files changed, 839 insertions(+)
create mode 100644 Documentation/trace/coresight/ultrasoc-smb.rst
create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.c
create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.h
--
2.24.0
Hi Jinlong
On 09/03/2022 14:22, Mao Jinlong wrote:
> It is possibe that probe failure issue happens when the device
> and its child_device's probe happens at the same time.
> In coresight_make_links, has_conns_grp is true for parent, but
> has_conns_grp is false for child device as has_conns_grp is set
> to true in coresight_create_conns_sysfs_group. The probe of parent
> device will fail at this condition. Add has_conns_grp check for
> child device before make the links and make the process from
> device_register to connection_create be atomic to avoid this
> probe failure issue.
>
> Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Suggested-by: Mike Leach <mike.leach(a)linaro.org>
> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com>
Thanks for the rework. The patch looks good to me.
Suzuki
This allows enabling branch broadcast for Perf hosted sessions (the option
is currently only available for the sysfs interface). Hopefully this could
be useful for testing the decode in perf, for example does a determinisitic
run with branch broadcast enabled look the same as with it disabled? It
could also be used for scenarios like OpenJ9's support for JIT code:
java -Xjit:perfTool hello.java
Currently this is not working and you get the usual errors of a missing
DSO, but branch broadcast would have to be enabled anyway before working
through this next issue:
CS ETM Trace: Debug data not found for address 0xffff7b94b058 in /tmp/perf-29360.map
Address range support in Perf for branch broadcast has also not been added
here, but could be added later.
The documentation has been refactored slightly to allow updates to be made
that link the Perf format arguments with the existing documentation.
For Suzuki's comment, I will do it as a separate change that converts all
the other hard coded values to a more consistent sysreg.h style:
nit: While at this, please could you change the hard coded value
to ETM4_CFG_BIT_RETSTK ?
Changes since v1:
* Added Leo's reviewed by on patch 3
* Fix bracket styling
* Add documentation
Applies on top of coresight/next efa56eddf5d5c. But this docs fix is also
required to get the links to work:
https://marc.info/?l=linux-doc&m=164139331923986&w=2
Also available at: https://gitlab.arm.com/linux-arm/linux-jc/-/tree/james-branch-broadcast-v2
James Clark (6):
coresight: Add config flag to enable branch broadcast
coresight: Fail to open with return stacks if they are unavailable
perf cs-etm: Update deduction of TRCCONFIGR register for branch
broadcast
Documentation: coresight: Turn numbered subsections into real
subsections
Documentation: coresight: Link config options to existing
documentation
Documentation: coresight: Expand branch broadcast documentation
.../coresight/coresight-etm4x-reference.rst | 14 ++++-
Documentation/trace/coresight/coresight.rst | 56 +++++++++++++++++--
.../hwtracing/coresight/coresight-etm-perf.c | 2 +
.../coresight/coresight-etm4x-core.c | 23 ++++++--
include/linux/coresight-pmu.h | 2 +
tools/include/linux/coresight-pmu.h | 2 +
tools/perf/arch/arm/util/cs-etm.c | 3 +
7 files changed, 92 insertions(+), 10 deletions(-)
--
2.28.0
Hi,
I'm Sending this sysfs addition to the etm4x driver in order to expose
the timestamp source of the trace (given by the TRFCR_ELx.TS register).
As mentioned in [1/2], having this information is useful for assigning
Kernel times to the perf samples.
Thanks,
German
German Gomez (3):
coresight: etm4x: Expose default timestamp source in sysfs
coresight: etm4x: docs: Add documentation for 'ts_source' sysfs
interface
perf cs_etm: Store ts_source in AUXTRACE_INFO fields
.../testing/sysfs-bus-coresight-devices-etm4x | 8 +++
.../coresight/coresight-etm4x-reference.rst | 14 ++++
arch/arm64/include/asm/sysreg.h | 1 +
.../coresight/coresight-etm4x-sysfs.c | 34 ++++++++++
tools/perf/arch/arm/util/cs-etm.c | 64 +++++++++++++++++--
tools/perf/util/cs-etm.c | 61 +++++++++---------
tools/perf/util/cs-etm.h | 13 +++-
7 files changed, 159 insertions(+), 36 deletions(-)
--
2.25.1
Hi Mike,
We would like to know if the perf decode script (cs-trace-disasm.py) mentioned
in the OpenCSD HOWTO page is hosted anywhere ?
https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md#trace-decoding-with-…
Also, does the script support generating instruction trace for both user space
and kernel space ?
With Regards,
Tanmay
On Sun, Apr 24, 2022 at 02:57:24PM +0800, Shile Zhang wrote:
>
>
> On 2022/4/22 23:45, Mathieu Poirier wrote:
> > On Fri, Apr 22, 2022 at 10:02:39AM +0800, Shile Zhang wrote:
> > > The function etm4_remove_dev() always return 0, and the former function
> > > etm4_remove has been changed to void in commit 3fd269e74f2fe ("amba: Make
> > > the remove callback return void"). But now its changed back to int type
> > > for some reason, which is different to the stable branch linux-5.10.y.
> >
> > Please spend time understanding why function etm4_remove_dev()'s return value
> > has been changed back to an "int". From there you will likely come to the
> > conclusion that adding the above to the changelog doesn't make sense.
>
> Sorry, I means "some reason" here actually I cannot find out why.
>
> 1. From the git log of the file
> `drivers/hwtracing/coresight/coresight-etm4x-core.c', only log of
> etm4_remove changes to void in commit 3fd269e74f2fe. no any log record when
> it change back to int.
> 2. from the commit 'git log --pretty="%h %ci %cn %s"
> drivers/hwtracing/coresight/coresight-etm4x-core.c'
> ...
> b8336ad947e19 2021-02-04 17:00:32 +0100 Greg Kroah-Hartman coresight: etm4x:
> add AMBA id for Cortex-A55 and Cortex-A75
> 3fd269e74f2fe 2021-02-02 14:25:50 +0100 Uwe Kleine-König amba: Make the
> remove callback return void
> ...
>
> The commit 'b8336ad947e19' does not change the etm4_remove:
> https://github.com/torvalds/linux/commit/b8336ad947e1913b9bb5cdf4f54b687654…
>
> But the different between the commit 'b8336ad947e19' and '3fd269e74f2fe'
> contains the changes of etm4_remove back to int, as following:
> ---
> ...
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 82787cba537d3..8c4b0c46c8f32 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -1680,7 +1680,7 @@ static void clear_etmdrvdata(void *info)
> etmdrvdata[cpu] = NULL;
> }
>
> -static void etm4_remove(struct amba_device *adev)
> +static int etm4_remove(struct amba_device *adev)
> {
> struct etmv4_drvdata *drvdata = dev_get_drvdata(&adev->dev);
>
> @@ -1703,6 +1703,8 @@ static void etm4_remove(struct amba_device *adev)
> cpus_read_unlock();
>
> coresight_unregister(drvdata->csdev);
> +
> + return 0;
> }
>
> static const struct amba_id etm4_ids[] = {
> @@ -1711,6 +1713,8 @@ static const struct amba_id etm4_ids[] = {
> CS_AMBA_ID(0x000bb95a), /* Cortex-A72 */
> CS_AMBA_ID(0x000bb959), /* Cortex-A73 */
> CS_AMBA_UCI_ID(0x000bb9da, uci_id_etm4),/* Cortex-A35 */
> + CS_AMBA_UCI_ID(0x000bbd05, uci_id_etm4),/* Cortex-A55 */
> + CS_AMBA_UCI_ID(0x000bbd0a, uci_id_etm4),/* Cortex-A75 */
> CS_AMBA_UCI_ID(0x000bbd0c, uci_id_etm4),/* Neoverse N1 */
> CS_AMBA_UCI_ID(0x000f0205, uci_id_etm4),/* Qualcomm Kryo */
> CS_AMBA_UCI_ID(0x000f0211, uci_id_etm4),/* Qualcomm Kryo */
> ...
> ---
>
> I really don't know how to check which commit change it back.
> Could you please help to give me some guidance?
Have a look at "git blame" - it is really useful to know what commit introduced a
change. In this case, and using coresight next (c86dd9869128), the command
would be:
$ git blame -L 2059,2059 drivers/hwtracing/coresight/coresight-etm4x-core.c
That will tell you how function etm4_remove_dev() got to return an 'int' again.
But this is really about understanding the current code rather than trying to
understand the history of it. With commit 3fd269e74f2fe, Uwe was making amba
remove callback functions return a 'void'. And this is what we see here[1] in
v5.10.112. Note that etm4_remove() is the callback to the amba driver.
In the mainline code, the amba callback function is now etm4_remove_amba() and
still returns a 'void'. Function etm4_remove() is now etm4_remove_dev() and is
called by both etm4_remove_amba() and etm4_remove_platform_dev(), to avoid code
duplication.
The conclusion is that because etm4_remove_dev() no longer interfaces with the
amba subsystem, its return value can be 'int'. But in this case the return
value is not used and as such can be changed to a 'void', regardless of commit
3fd269e74f2fe.
Mathieu
[1]. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drive…
>
> Thanks!
>
>
> >
> > >
> > > Just let it return void and return 0 directly in it's caller function
> > > etm4_remove_platform_dev.
> >
> > The only rational for this patch is that etm4_remove_dev() always returns '0'.
> > And even if it was to return anything else, the return value it not checked.
> > And even if the return value was checked, there is nothing to do about an error
> > condition since the driver is being removed.
> >
> > >
> > > Signed-off-by: Shile Zhang <shile.zhang(a)linux.alibaba.com>
> > > ---
> > > v2: re-work the commit log from Mathieu's suggestion.
> > > v1: https://lore.kernel.org/linux-arm-kernel/20220421164217.GB1596562@p14s/T/
> > > ---
> > > drivers/hwtracing/coresight/coresight-etm4x-core.c | 11 +++++------
> > > 1 file changed, 5 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > index 7f416a12000eb..141f8209a152a 100644
> > > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > @@ -2104,7 +2104,7 @@ static void clear_etmdrvdata(void *info)
> > > etmdrvdata[cpu] = NULL;
> > > }
> > > -static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata)
> > > +static void __exit etm4_remove_dev(struct etmv4_drvdata *drvdata)
> > > {
> > > etm_perf_symlink(drvdata->csdev, false);
> > > /*
> > > @@ -2125,8 +2125,6 @@ static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata)
> > > cscfg_unregister_csdev(drvdata->csdev);
> > > coresight_unregister(drvdata->csdev);
> > > -
> > > - return 0;
> > > }
> > > static void __exit etm4_remove_amba(struct amba_device *adev)
> > > @@ -2139,13 +2137,14 @@ static void __exit etm4_remove_amba(struct amba_device *adev)
> > > static int __exit etm4_remove_platform_dev(struct platform_device *pdev)
> > > {
> > > - int ret = 0;
> > > struct etmv4_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
> > > if (drvdata)
> > > - ret = etm4_remove_dev(drvdata);
> > > + etm4_remove_dev(drvdata);
> > > +
> > > pm_runtime_disable(&pdev->dev);
> > > - return ret;
> > > +
> > > + return 0;
> > > }
> > > static const struct amba_id etm4_ids[] = {
> > > --
> > > 2.33.0.rc2
> > >