summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* habanalabs: allow user to set allocation page sizeOhad Sharabi2022-02-284-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | In future ASICs the MMU will be able to work with multiple page sizes, thus a new flag is added to allow the user to set the requested page size. This flag is added since the whole DRAM is allocated for the user and the user also should be familiar with the memory usage use case. As such, the user may choose to "over allocate" memory in favor of performance (for instance- large page allocations covers more memory in less TLB entries). For example: say available page sizes are of 1MB and 32MB. If user wants to allocate 40MB the user can either set page size to 1MB and allocate the exact amount of memory (but will result in 40 TLB entries) or the user can use 32MB pages, "waste" 8MB of physical memory but occupy only 2 TLB entries. Note that this feature will be available only to ASIC that supports multiple DRAM page sizes. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: avoid using an uninitialized variableTomer Tayar2022-02-281-1/+1
| | | | | | | | | | Fix the following compilation warning in hl_cb_ioctl() @ command_buffer.c: warning: ‘device_va’ may be used uninitialized in this function Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: set max power on device init per ASICTomer Tayar2022-02-284-1/+8
| | | | | | | | | | | | | | | For current devices there is a need to send the max power value to F/W during device init, for example because there might be several card types. In future devices, this info will be programmed in the device's EEPROM and will be read by F/W, and hence the driver should not send it. Modify the sending of the relevant message to be done only for ASIC types that need it. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: use proper max_power variable for device utilizationTomer Tayar2022-02-281-1/+1
| | | | | | | | | | | The max_power variable which is used for calculating the device utilization is the ASIC specific property which is set during init. However, the max value can be modified via sysfs, and thus the updated value in the device structure should be used instead. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: enable stop-on-error debugfs setting per ASICTomer Tayar2022-02-284-0/+12
| | | | | | | | | | | | On Goya and Gaudi, the stop-on-error configuration can be set via debugfs. However, in future devices, this configuration will always be enabled. Modify the debugfs node to be allowed only for ASICs that support this dynamic configuration. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: change function to staticOded Gabbay2022-02-281-1/+1
| | | | | | | handle_registration_node() is called directly from the irq handler in irq.c, so it can be static. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: add missing include of vmalloc.hOded Gabbay2022-02-281-0/+1
| | | | | | | Use of vfree(), vmalloc_user(), vmalloc() and remap_vmalloc_range() requires this include in some architectures. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: fix use-after-free bugOded Gabbay2022-02-281-2/+2
| | | | | | | | | | When the code iterates over the free list of physical pages nodes, it deletes the physical page node which is used as the iterator. Therefore, we need to use the safe version of the iteration to prevent use-after-free. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: rephrase error messages in PCI initializationOded Gabbay2022-02-281-2/+2
| | | | | | | | The iATU is an internal h/w machine inside Habana's PCI controller. Mentioning it by name doesn't say anything to the user. It is better to say the PCI controller initialization was not done successfully. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: fix spelling mistakeOded Gabbay2022-02-281-1/+1
| | | | | | The name of the property is hints_range_reservation Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: Timestamps buffers registrationfarah kassabri2022-02-286-56/+655
| | | | | | | | | | | | | | Timestamp registration API allows the user to register a timestamp record event which will make the driver set timestamp when CQ counter reaches the target value and write it to a specific location specified by the user. This is a non blocking API, unlike the wait_for_interrupt which is a blocking one. Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: fix race when waiting on encaps signalDani Liberman2022-02-281-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Scenario: 1. CS which is part of encaps signal has been completed and now executing kref_put to its encaps signal handle. The refcount of the handle decremented to 0, and called the encaps signal handle release function - hl_encaps_handle_do_release. 2. At this point the user starts waiting on the signal, and finds the encaps signal handle in the handlers list and increment the habdle refcount to 1. 3. Immediately after, hl_encaps_handle_do_release removed the handle from the list and free its memory. 4. Wait function using the handle although it has been freed. This scenario caused the slab area which was previously allocated for the handle to be poison overwritten which triggered kernel bug the next time the OS needed to allocate this slab. Fixed by getting the refcount of the handle only in case it is not zero. Signed-off-by: Dani Liberman <dliberman@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: silence an uninitialized variable warningDan Carpenter2022-02-281-0/+2
| | | | | | | | | | | | | | Smatch warns that: drivers/misc/habanalabs/common/command_buffer.c:471 hl_cb_ioctl() error: uninitialized symbol 'device_va'. Which is true, but harmless. Anyway, it's easy to silence this by adding a error check. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: remove duplicate printOded Gabbay2022-02-281-6/+1
| | | | | | | We print detailed messages inside the internal ioctl functions. No need to print a generic message at the end, it doesn't add any information. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: prevent false heartbeat failure during soft-resetTomer Tayar2022-02-281-2/+5
| | | | | | | | | | | | | | | | | | | | | | | The heartbeat thread is active during soft-reset, and it tries to send messages to CPU-CP core. Within the soft-reset, in the time window in which the device is marked as disabled, any CPU-CP command is "silently" skipped and a success value it returned. However, in addition to the return value, the heartbeat function also checks the F/W result, but because no command is sent in this time window, the result variable won't hold the expected value and we will have a false heartbeat failure. To avoid it, modify the "silent" skip to be done only in hard-reset. The CPU-CP should be able to handle messages during soft-reset. In addition to the heartbeat problem, this should also solve other issues in other flows that send messages during soft-reset and use the F/W result as it w/o being aware to the reset. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: fix race between wait and irqOded Gabbay2022-02-281-1/+5
| | | | | | | | | | | There is a race in the user interrupts code, where between checking the target value and adding the new pend to the list, there is a chance the interrupt happened. In that case, no one will complete the node, and we will get a timeout on it. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: fix user interrupt wait when timeout is 0Oded Gabbay2022-02-281-4/+6
| | | | | | | | | When timeout is 0, we need to return the busy status in case the target value wasn't reached upon entry to the ioctl. Also return the correct timestamp. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: reject host map with mmu disabledOded Gabbay2022-02-281-19/+11
| | | | | | | This is not something we can do a workaround. It is clearly an error and we should notify the user that it is an error. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: expose number of user interruptsOded Gabbay2022-02-281-2/+2
| | | | | | | | Currently we only expose to the user the ID of the first available user interrupt. To make user interrupts allocation truly dynamic, we need to also expose the number of user interrupts. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: update to latest f/w specsOded Gabbay2022-02-281-0/+5
| | | | | | Copy the latest versions of the f/w specs files. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: add missing error check in sysfs max_power_showTomer Tayar2022-02-283-3/+5
| | | | | | | | Add a missing error check in the sysfs show function for max_power. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: fix soft reset flow in case of failureDani Liberman2022-02-281-0/+3
| | | | | | | | | | | | In case of soft reset failure, hard reset should be initiated, but reset flags were not set to enable it, which caused another soft reset followed by another failure. Updated reset flags to enable hard reset flow in case of soft reset failure. Signed-off-by: Dani Liberman <dliberman@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: add missing error check in sysfs clk_freq_mhz_showTomer Tayar2022-02-281-0/+4
| | | | | | | | | Add a missing error check in the sysfs show functions for clk_max_freq_mhz and clk_cur_freq_mhz_show. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: avoid copying pll data if pll_info_get failsTomer Tayar2022-02-281-2/+4
| | | | | | | | | If reading PLL info from F/W fails, the PLL info is not set in the "result" variable, and hence shouldn't be copied to the caller's array. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: don't free phys_pg_pack inside lockOded Gabbay2022-02-282-5/+14
| | | | | | | | | | | | | | Freeing phys_pg_pack includes calling to scrubbing functions of the device's memory, taking locks and possibly even calling reset. This is not something that should be done while holding a device-wide spinlock. Therefore, save the relevant objects on a local linked-list and after releasing the spinlock, traverse that list and free the phys_pg_pack objects. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: duplicate HOP table props to MMU propsOhad Sharabi2022-02-282-0/+9
| | | | | | | | | | | | | | | | | | | In order to support several device MMU blocks with different architectures (e.g. different HOP table size) we need to move to per-MMU properties rather than keeping those properties as ASIC properties. Refactoring the code to use "per-MMU proprties" is a major effort. To start making the transition towards this goal but still support taking the properties from ASIC properties (for code that currently uses them) this patch copies some of the properties to the "per-MMU" properties and later, when implementing the per-MMU properties, we would be able to delete the MMU props from the ASIC props. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: there is no kernel TDR in future ASICsOded Gabbay2022-02-281-4/+13
| | | | | | | | | | | | | | In future ASICs, there is no kernel TDR for new workloads that are submitted directly from user-space to the device. Therefore, the driver can NEVER know that a workload has timed-out. So, when the user asks us to wait for interrupt on the workload's completion, and the wait has timed-out, it doesn't mean the workload has timed-out. It only means the wait has timed-out, which is NOT an error from driver's perspective. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: sysfs support for fw os versionRajaravi Krishna Katta2022-02-282-0/+12
| | | | | | | | | Adds new sysfs entry to display firmware os version /sys/class/habanalabs/hl<n>/fw_os_ver Signed-off-by: Rajaravi Krishna Katta <rkatta@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: use common wrapper for MMU cache invalidationOded Gabbay2022-02-282-6/+5
| | | | | | | | | We have a common function that wraps the call to the MMU cache invalidation function, which is ASIC-specific. The wrapper checks the return value and prints error if necessary. For consistency, try to use the wrapper when possible. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: remove power9 workaround for dma supportOded Gabbay2022-02-284-25/+3
| | | | | | We don't need this workaround anymore. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: add vrm version to sysfsOded Gabbay2022-02-286-26/+77
| | | | | | | infineon version is only applicable to GOYA and GAUDI. For later ASICs, we display the Voltage Regulator Monitor f/w version. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: rename dev_attr_grp to dev_clk_attr_grpOded Gabbay2022-02-284-12/+9
| | | | | | | | In this attribute group we are only adding clocks. This is in preparation for adding a device specific attribute group which is not related to clocks. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: remove asic callback set_pll_profile()Oded Gabbay2022-02-285-9/+7
| | | | | | | | Setting PLL profile is the same for all ASICs, except for GOYA. However, because this function is never called from common code, there is no need to have an asic-specific callback function. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: move more f/w functions to firmware_if.cOded Gabbay2022-02-285-158/+141
| | | | | | | For better maintainability, try to concentrate all the common functions that communicate with the f/w in firmware_if.c Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: remove hwmgr.cOded Gabbay2022-02-286-54/+46
| | | | | | | The two remaining functions in this file belong to firmware_if.c, as they communicate with the firmware. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: get clk is common functionOded Gabbay2022-02-285-18/+15
| | | | | | | | | | | Retrieving the clock from the f/w is done exactly the same in ALL our ASICs. Therefore, no real justification for doing it as an ASIC-specific function. The only thing is we need to check if we are running on simulator, which doesn't require ASIC-specific callback. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: sysfs functions should be in sysfs.cOded Gabbay2022-02-284-76/+71
| | | | | | | | | Move common sysfs store/show functions to sysfs.c file for consistency. This is part of a patch-set to remove hwmgr.c Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: make some MMU functions commonOhad Sharabi2022-02-283-37/+72
| | | | | | | | | Some MMU functions can be used by different versions of our MMUs, so move them to be common. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: remove ASIC functions of clock gatingOded Gabbay2022-02-285-142/+5
| | | | | | | | Now that clock gating is permanently disabled in GAUDI, no need for the ASIC functions of setting and disabling clock gating, as this was a unique scenario in GAUDI. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs/gaudi: disable CGM permanentlyOded Gabbay2022-02-285-203/+65
| | | | | | | | Due to the need of SynapseAI to configure all TPC engines from a single QMAN, the driver must disable CGM and never allow the user to enable it. Otherwise, the configuration of the TPC engines will fail. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: fix possible memory leak in MMU DR finiOhad Sharabi2022-02-281-1/+1
| | | | | | | | | | | This patch fixes what seems to be copy paste error. We will have a memory leak if the host-resident shadow is NULL (which will likely happen as the DR and HR are not dependent). Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* habanalabs: check the return value of hl_cs_poll_fences()Tomer Tayar2022-02-281-1/+1
| | | | | | | | | | | As part of handling of the multi-CS wait ioctl, hl_cs_poll_fences() is called in a "while (true)" loop. This function can fail, but the checking of its return value was missed. Add this check and exit the loop in case of a failure. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
* Merge 5.17-rc6 into char-misc-nextGreg Kroah-Hartman2022-02-28256-1630/+1942
|\ | | | | | | | | | | We need the char-misc fixes in here. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Merge tag 'irq-urgent-2022-02-27' of ↵Linus Torvalds2022-02-271-7/+7
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Thomas Gleixner: "A single fix for a regression caused by the recent PCI/MSI rework which resulted in a recursive locking problem in the VMD driver. The cure is to cache the relevant information upfront instead of retrieving it at runtime" * tag 'irq-urgent-2022-02-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: PCI: vmd: Prevent recursive locking on interrupt allocation
| | * PCI: vmd: Prevent recursive locking on interrupt allocationThomas Gleixner2022-02-211-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tejas reported the following recursive locking issue: swapper/0/1 is trying to acquire lock: ffff8881074fd0a0 (&md->mutex){+.+.}-{3:3}, at: msi_get_virq+0x30/0xc0 but task is already holding lock: ffff8881017cd6a0 (&md->mutex){+.+.}-{3:3}, at: __pci_enable_msi_range+0xf2/0x290 stack backtrace: __mutex_lock+0x9d/0x920 msi_get_virq+0x30/0xc0 pci_irq_vector+0x26/0x30 vmd_msi_init+0xcc/0x210 msi_domain_alloc+0xbf/0x150 msi_domain_alloc_irqs_descs_locked+0x3e/0xb0 __pci_enable_msi_range+0x155/0x290 pci_alloc_irq_vectors_affinity+0xba/0x100 pcie_port_device_register+0x307/0x550 pcie_portdrv_probe+0x3c/0xd0 pci_device_probe+0x95/0x110 This is caused by the VMD MSI code which does a lookup of the Linux interrupt number for an VMD managed MSI[X] vector. The lookup function tries to acquire the already held mutex. Avoid that by caching the Linux interrupt number at initialization time instead of looking it up over and over. Fixes: 82ff8e6b78fc ("PCI/MSI: Use msi_get_virq() in pci_get_vector()") Reported-by: "Surendrakumar Upadhyay, TejaskumarX" <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: "Surendrakumar Upadhyay, TejaskumarX" <tejaskumarx.surendrakumar.upadhyay@intel.com> Cc: linux-pci@vger.kernel.org Link: https://lore.kernel.org/r/87a6euub2a.ffs@tglx
| * | Merge tag 'pinctrl-v5-17-3' of ↵Linus Torvalds2022-02-274-8/+13
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Fix some drive strength and pull-up code in the K210 driver. - Add the Alder Lake-M ACPI ID so it starts to work properly. - Use a static name for the StarFive GPIO irq_chip, forestalling an upcoming fixes series from Marc Zyngier. - Fix an ages old bug in the Tegra 186 driver where we were indexing at random into struct and being lucky getting the right member. * tag 'pinctrl-v5-17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: gpio: tegra186: Fix chip_data type confusion pinctrl: starfive: Use a static name for the GPIO irq_chip pinctrl: tigerlake: Revert "Add Alder Lake-M ACPI ID" pinctrl: k210: Fix bias-pull-up pinctrl: fix loop in k210_pinconf_get_drive()
| | * \ Merge tag 'intel-pinctrl-v5.17-5' of ↵Linus Walleij2022-02-191-1/+0
| | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gitolite.kernel.org:pub/scm/linux/kernel/git/pinctrl/intel into fixes intel-pinctrl for v5.17-5 * Revert misplaced ID The following is an automated git shortlog grouped by driver: tigerlake: - Revert "Add Alder Lake-M ACPI ID"
| | | * | pinctrl: tigerlake: Revert "Add Alder Lake-M ACPI ID"Andy Shevchenko2022-02-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears that last minute change moved ACPI ID of Alder Lake-M to the INTC1055, which is already in the driver. This ID on the other hand will be used elsewhere. This reverts commit 258435a1c8187f559549e515d2f77fa0b57bcd27. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
| | * | | gpio: tegra186: Fix chip_data type confusionMarc Zyngier2022-02-191-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tegra186 GPIO driver makes the assumption that the pointer returned by irq_data_get_irq_chip_data() is a pointer to a tegra_gpio structure. Unfortunately, it is actually a pointer to the inner gpio_chip structure, as mandated by the gpiolib infrastructure. Nice try. The saving grace is that the gpio_chip is the first member of tegra_gpio, so the bug has gone undetected since... forever. Fix it by performing a container_of() on the pointer. This results in no additional code, and makes it possible to understand how the whole thing works. Fixes: 5b2b135a87fc ("gpio: Add Tegra186 support") Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20220211093904.1112679-1-maz@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| | * | | pinctrl: starfive: Use a static name for the GPIO irq_chipMarc Zyngier2022-02-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drop the device name used for the GPIO irq_chip and replace it with something static. The information is still available from debugfs and carried as part of the irqdomain. Suggested-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220211092345.1093332-1-maz@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-10 06:04:54 +0100