kernel/drivers/hwtracing/intel_th/intel_th.h, branch linux-6.9.y

driver core: make struct device_type.devnode() take a const *

2023-01-27T12:45:38Z

The devnode() callback in struct device_type should not be modifying the device that is passed into it, so mark it as a const * and propagate the function signature changes out into all relevant subsystems that use this callback. Cc: Jens Axboe Cc: Alison Schofield Cc: Vishal Verma Cc: Ira Weiny Cc: Ben Widawsky Cc: Jeremy Kerr Cc: Joel Stanley Cc: Alistar Popple Cc: Eddie James Cc: Jonathan Cameron Cc: Jilin Yuan Cc: Heikki Krogerus Cc: Alan Stern Cc: Andy Shevchenko Cc: Thomas Gleixner Cc: Jason Gunthorpe Cc: "Rafael J. Wysocki" Cc: Won Chung Acked-by: Dan Williams Acked-by: Alexander Shishkin Acked-by: Hans de Goede Link: https://lore.kernel.org/r/20230111113018.459199-7-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

intel_th: Wait until port is in reset before programming it

2021-06-24T13:49:32Z

Some devices don't drain their pipelines if we don't make sure that the corresponding output port is in reset before programming it for a new trace capture, resulting in bits of old trace appearing in the new trace capture. Fix that by explicitly making sure the reset is asserted before programming new trace capture. Reviewed-by: Andy Shevchenko Signed-off-by: Alexander Shishkin Link: https://lore.kernel.org/r/20210621151246.31891-5-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman

intel_th: Constify attribute_group structs

2021-04-16T05:26:50Z

The only usage of them is to pass their address to sysfs_create_group() and sysfs_remove_group(), both which have pointers to const attribute_group structs as input. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210414171251.14672-5-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman

intel_th: Constify all drvdata references

2021-04-16T05:26:50Z

Anything that deals with drvdata structures should leave them intact. Reflect this in function signatures. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210414171251.14672-4-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman

intel_th: Disallow multi mode on devices where it's broken

2020-03-18T10:28:22Z

Some versions of Intel TH have an issue that prevents the multi mode of MSU from working correctly, resulting in no trace data and potentially stuck MSU pipeline. Disable multi mode on such devices. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200317062215.15598-2-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman

intel_th: Fix freeing IRQs

2019-12-17T14:45:58Z

Commit aac8da65174a ("intel_th: msu: Start handling IRQs") implicitly relies on the use of devm_request_irq() to subsequently free the irqs on device removal, but in case of the pci_free_irq_vectors() API, the handlers need to be freed before it is called. Therefore, at the moment the driver's remove path trips a BUG_ON(irq_has_action()): > kernel BUG at drivers/pci/msi.c:375! > invalid opcode: 0000 1 SMP > CPU: 2 PID: 818 Comm: rmmod Not tainted 5.5.0-rc1+ #1 > RIP: 0010:free_msi_irqs+0x67/0x1c0 > pci_disable_msi+0x116/0x150 > pci_free_irq_vectors+0x1b/0x20 > intel_th_pci_remove+0x22/0x30 [intel_th_pci] > pci_device_remove+0x3e/0xb0 > device_release_driver_internal+0xf0/0x1c0 > driver_detach+0x4c/0x8f > bus_remove_driver+0x5c/0xd0 > driver_unregister+0x31/0x50 > pci_unregister_driver+0x40/0x90 > intel_th_pci_driver_exit+0x10/0xad6 [intel_th_pci] > __x64_sys_delete_module+0x147/0x290 > ? exit_to_usermode_loop+0xd7/0x120 > do_syscall_64+0x57/0x1b0 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by explicitly freeing irqs before freeing the vectors. We keep using the devm_* variants because they are still useful in early error paths. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Fixes: aac8da65174a ("intel_th: msu: Start handling IRQs") Reported-by: Ammy Yi Tested-by: Ammy Yi Cc: stable@vger.kernel.org # v5.2+ Link: https://lore.kernel.org/r/20191217115527.74383-4-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman

intel_th: Add switch triggering support

2019-05-03T16:16:21Z

Add support for asserting window switch trigger when tracing to MSU output ports. This allows for software controlled switching between windows of the MSU buffer, which can be used for double buffering while exporting the trace data further from the MSU. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

intel_th: msu: Factor out pipeline draining

2019-05-03T16:16:21Z

The code that waits for the pipeline empty condition of the MSU is currently called in the path that disables the trace. We will also need this in the window switch trigger sequence. Therefore, factor out this code and make it accessible to the GTH device. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

intel_th: Only report useful IRQs to subdevices

2019-05-03T16:14:30Z

The only type of IRQ triggering event that is useful to us at the moment is the "last block" interrupt of the MSU. This interrupt can only be enabled via "MINTCTL" register that doesn't exist in earlier version of the Intel TH. Enumerate the presence of MINTCTL via per-device driver data structure and only instantiate the IRQ resource for subdevices if this capability is present. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

intel_th: msu: Start handling IRQs

2019-05-03T16:14:30Z

We intend to use the interrupt to detect Last Block condition in the MSU driver, which we can use for double-buffering software-managed data transfers. Add an interrupt handler to the MSU driver. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman