summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-12-11dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMAVignesh Raghavendra
This commit adds support for PKTDMA in k3-udma glue driver. Use new psil_endpoint_config struct to get static data for a given channel or a flow during setup. Make sure that the RX flows being mapped to a RX channel is within the range of flows that is been allocated to that RX channel. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-21-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma: Initial support for K3 PKTDMAPeter Ujfalusi
One of the DMAs introduced with AM64 is the Packet DMA (PKTDMA). It serves similar purpose as K3 UDMAP channels in packet mode, but with notable differences, like tflow support and channels being allocated to service specific peripherals. The rings for the PKTDMA is integrated within the DMA itself instead of using rings from the general purpose ringacc. PKTDMA can be used to service PSI-L peripherals, similarly to K3 UDMA channels. Most of the driver code can be reused for PKTDMA tchan/rchan support but new setup and allocation functions are needed to handle the differences between the DMAs. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-20-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handlingPeter Ujfalusi
Unlike UDMAP the BCDMA defines the channel TPL levels per channel type. In UDMAP the number of high and ultra-high channels applies to both tchan and rchan. BCDMA defines the TPL per channel types: bchan, tchan and rchan can have different number of high and ultra-high channels. In order to support BCDMA channel TPL we need to move the tpl information as per channel type property for the DMAs. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-19-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma: Initial support for K3 BCDMAPeter Ujfalusi
One of the DMAs introduced with AM64 is the Block Copy DMA (BCDMA). It serves similar purpose as K3 UDMAP channels in TR mode. The rings for the BCDMA is integrated within the DMA itself instead of using rings from the general purpose ringacc. A BCDMA have two different type of channels: - Block Copy Channels (bchan) - Split Channels (tchan and rchan) tchan and rchan can be used to service PSI-L peripherals, similarly to K3 UDMA channels. bchan can be only used for block copy operation (TR type15) like the paired K3 UDMA tchan/rchan configured in block copy mode. bchans can be also used to service peripherals directly if an external trigger is selected for the channel. Most of the driver code can be reused for BCDMA bchan/tchan/rchan support but new setup and allocation functions are needed to handle the differences between the DMAs. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-18-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11soc: ti: k3-ringacc: add AM64 DMA rings support.Grygorii Strashko
The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a separate and generic ringacc is used. The ring SW interface is similar to ringacc with some major architectural differences, like They are part of the DMA (BCDMA or PKTDMA). They are dual mode rings are modeled as pair of Rings objects which has common configuration and memory buffer, but separate real-time control register sets for each direction mem2dev (forward) and dev2mem (reverse). The ringacc driver must be initialized for DMA rings use with k3_ringacc_dmarings_init() as it is not an independent device as ringacc is. AM64 rings must be requested only using k3_ringacc_request_rings_pair(), and forward ring must always be initialized/configured. After this any other Ringacc APIs can be used without any callers changes. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-17-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-psil: Add initial map for AM64Peter Ujfalusi
Add initial PSI-L map file for AM64. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-15-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: dmatest: Use dmaengine_get_dma_devicePeter Ujfalusi
By using the dmaengine_get_dma_device() to get the device for dma_api use, the dmatest can support per channel coherency if it is supported by the DMA controller. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-11-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: of-dma: Add support for optional router configuration callbackPeter Ujfalusi
Additional configuration for the DMA event router might be needed for a channel which can not be done during device_alloc_chan_resources callback since the router information is not yet present for the drivers. If there is a need for additional configuration for the channel if DMA router is in use, then the driver can implement the device_router_config callback. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-8-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma-glue: Configure the dma_dev for ringsPeter Ujfalusi
Rings in RING mode should be using the DMA device for DMA API as in this mode the ringacc will not access the ring memory in any ways, but the DMA is. Fix up the ring configuration and set the dma_dev unconditionally and let the ringacc driver to select the correct device to use for DMA API. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-7-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma-glue: Get the ringacc from udma_devPeter Ujfalusi
If of_xudma_dev_get() returns with the valid udma_dev then the driver already got the ringacc, there is no need to execute of_k3_ringacc_get_by_phandle() for each channel via the glue layer. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-6-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA APIPeter Ujfalusi
Glue layer users should use the device of the DMA for DMA mapping and allocations as it is the DMA which accesses to descriptors and buffers, not the clients Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-5-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma: Add support for second resource range from sysfwPeter Ujfalusi
Resource allocation via sysfw can use up to two ranges per resource subtype to support more complex resource assignment, mainly for DMA channels. Take the second range also into consideration when setting up the maps for available resources. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-4-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma: Wait for peer teardown completion if supportedPeter Ujfalusi
Set the TDTYPE if it is supported on the platform (j721e) which will cause UDMAP to wait for the remote peer to finish the teardown before returning the teardown completed message. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-3-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma: Correct normal channel offset when uchan_cnt is not 0Peter Ujfalusi
According to different sections of the TRM, the hchan_cnt of CAP3 includes the number of uchan in UDMA, thus the start offset of the normal channels are hchan_cnt. Fixes: daf4ad0499aa4 ("dmaengine: ti: k3-udma: Query throughput level information from hardware") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-2-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11Merge tag 'tags/drivers_soc_for_5.11' into dmaengine/nextVinod Koul
drivers: soc: TI SOC changes for 5.11 - ti_sci changes towards DMSS support - Static warning fixes - Kconfig update for Keystone ARM64 socs - AM64X SOC family support
2020-12-11dmaengine: stm32-mdma: rework interrupt handlerAmelie Delaunay
To avoid multiple entries in MDMA interrupt handler for each flag&interrupt enable, manage all flags set at once. Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20201120143320.30367-5-amelie.delaunay@st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: stm32-dma: take address into account when computing max widthAmelie Delaunay
DMA_SxPAR or DMA_SxM0AR/M1AR registers have to be aligned on PSIZE or MSIZE respectively. This means that bus width needs to be forced to 1 byte when computed width is not aligned with address. Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20201120143320.30367-4-amelie.delaunay@st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: stm32-dma: clean channel configuration when channel is freedAmelie Delaunay
When dma_channel_release is called, it means that the channel won't be used anymore with the configuration it had. To ensure a future client can safely use the channel after it has been released, clean the configuration done when channel was requested. Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20201120143320.30367-3-amelie.delaunay@st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: stm32-dma: rework irq handler to manage error before xfer eventsAmelie Delaunay
To better understand error that can be detected by the DMA controller, manage the error flags before the transfer flags. This way, it is possible to know if the FIFO error flag is set for an over/underrun condition or a FIFO level error. When a FIFO over/underrun condition occurs, the data is not lost because peripheral request is not acknowledged by the stream until the over/ underrun condition is cleared. If this acknowledge takes too much time, the peripheral itself may detect an over/underrun condition of its internal buffer and data might be lost. That's why in case the FIFO error flag is set, we check if the channel is disabled or not, and if a Transfer Complete flag is set, which means that the channel is disabled because of the end of transfer. Because channel is disabled by hardware either by a FIFO level error, or by an end of transfer. Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20201120143320.30367-2-amelie.delaunay@st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11hwmon: (iio_hwmon) Drop bogus __refdata annotationGeert Uytterhoeven
As the IIO hardware monitoring driver does not have any code or data located in initmem, there is no need to annotate the iio_hwmon_driver structure with __refdata. Drop the annotation, to avoid suppressing future section warnings. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201211133512.2969952-1-geert+renesas@glider.be Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-11hwmon: (xgene) Drop bogus __refdata annotationGeert Uytterhoeven
As the X-Gene hardware monitoring driver does not have any code or data located in initmem, there is no need to annotate the xgene_hwmon_driver structure with __refdata. Drop the annotation, to avoid suppressing future section warnings. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201211133531.2970027-1-geert+renesas@glider.be Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-11hwmon: (occ) Add new temperature sensor typeEddie James
The latest version of the On-Chip Controller (OCC) has a different format for the temperature sensor data. Add a new temperature sensor version to handle this data. Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201120010315.190737-4-joel@jms.id.au Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-11fsi: occ: Add support for P10Eddie James
The P10 OCC has a different SRAM address for the command and response buffers. In addition, the SBE commands to access the SRAM have changed format. Add versioning to the driver to handle these differences. Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201120010315.190737-3-joel@jms.id.au Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-11hwmon: (ltc2992) Fix less than zero comparisons with an unsigned integerColin Ian King
There are several occurrances of a less than zero error check on a u32 unsigned integer. These will never be true. Fix this by making reg_value a plain int. Addresses-Coverity: ("Unsigned comparison against zero") Fixes: e126370240e0 ("hwmon: (ltc2992) Add support") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201207142410.168987-1-colin.king@canonical.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-11hwmon: (ltc2992) Add support for GPIOs.Alexandru Tachici
LTC2992 has 4 open-drain GPIOS. This patch exports to user space the 4 GPIOs using the GPIO driver Linux API. Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-11hwmon: (ltc2992) Add supportAlexandru Tachici
LTC2992 is a rail-to-rail system monitor that measures current, voltage, and power of two supplies. Two ADCs simultaneously measure each supply’s current. A third ADC monitors the input voltages and four auxiliary external voltages. Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-11hwmon: (pmbus) Driver for Delta power supplies Q54SJ108A2xiao.ma
The driver supports Q54SJ108A2 series modules of Delta. Standard attributes are in sysfs, and other attributes are in debugfs. Signed-off-by: xiao.ma <xiao.mx.ma@deltaww.com> Link: https://lore.kernel.org/r/20201202025900.1842-1-max701@126.com [groeck: Replaced spaces with tabs, dropped excessive spaces, fixed module prefix in documentation] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-11usb: ucsi: convert comma to semicolonZheng Yongjun
Replace a comma between expression statements by a semicolon. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Link: https://lore.kernel.org/r/20201211085510.2928-1-zhengyongjun3@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11Merge tag 'usb-serial-5.11-rc1' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB-serial updates for 5.11-rc1 Here are the USB-serial updates for 5.11-rc1, including: - keyspan_pda write-implementation fixes - digi_acceleport write-wakeup fix - mos7720 parport-restore fix - mos7720 parport-tasklet removal - cp210x termios-handling cleanups - option device-flag fix - ftdi_sio GPIO CBUS-configuration improvements - removal of in_interrupt() uses Included are also various clean ups. All have been in linux-next with no reported issues. * tag 'usb-serial-5.11-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (30 commits) USB: serial: ftdi_sio: log the CBUS GPIO validity USB: serial: ftdi_sio: drop GPIO line checking dead code USB: serial: ftdi_sio: report the valid GPIO lines to gpiolib USB: serial: option: add interface-number sanity check to flag handling USB: serial: cp210x: clean up dtr_rts() USB: serial: cp210x: refactor flow-control handling USB: serial: cp210x: drop flow-control debugging USB: serial: cp210x: set terminal settings on open USB: serial: cp210x: clean up line-control handling USB: serial: cp210x: return early on unchanged termios USB: serial: mos7720: defer state restore to a workqueue USB: serial: mos7720: fix parallel-port state restore USB: serial: remove write wait queue USB: serial: digi_acceleport: fix write-wakeup deadlocks USB: serial: keyspan_pda: drop redundant usb-serial pointer USB: serial: keyspan_pda: use BIT() macro USB: serial: keyspan_pda: clean up comments and whitespace USB: serial: keyspan_pda: clean up xircom/entrega support USB: serial: keyspan_pda: add write-fifo support USB: serial: keyspan_pda: increase transmitter threshold ...
2020-12-11Revert "scsi: storvsc: Validate length of incoming packet in ↵Andrea Parri (Microsoft)
storvsc_on_channel_callback()" This reverts commit 3b8c72d076c42bf27284cda7b2b2b522810686f8. Dexuan reported a regression where StorVSC fails to probe a device (and where, consequently, the VM may fail to boot). The root-cause analysis led to a long-standing race condition that is exposed by the validation /commit in question. Let's put the new validation aside until a proper solution for that race condition is in place. Link: https://lore.kernel.org/r/20201211131404.21359-1-parri.andrea@gmail.com Fixes: 3b8c72d076c4 ("scsi: storvsc: Validate length of incoming packet in storvsc_on_channel_callback()") Cc: Dexuan Cui <decui@microsoft.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-11driver core: platform: Add devm_platform_get_irqs_affinity()John Garry
Drivers for multi-queue platform devices may also want managed interrupts for handling HW queue completion interrupts, so add support. The function accepts an affinity descriptor pointer, which covers all IRQs expected for the device. The function is devm class as the only current in-tree user will also use devm method for requesting the interrupts; as such, the function is made as devm as it can ensure ordering of freeing the irq and disposing of the mapping. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1606905417-183214-5-git-send-email-john.garry@huawei.com
2020-12-11ACPI: Drop acpi_dev_irqresource_disabled()John Garry
The functionality of acpi_dev_irqresource_disabled() is same as in common irqresource_disabled(), so drop acpi_dev_irqresource_disabled() in favour of that function. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/1606905417-183214-4-git-send-email-john.garry@huawei.com
2020-12-11irqchip/gic-v3-its: Flag device allocation as proxied if behind a PCI bridgeMarc Zyngier
An aliasing PCI bridge is another case where we should flag the corresponding allocation as "proxied", as MSIs are coming with the bridge's RID, and not the originating device's. Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20201129135208.680293-4-maz@kernel.org
2020-12-11irqchip/gic-v3-its: Tag ITS device as shared if allocating for a proxy deviceMarc Zyngier
The ITS already has some notion of "shared" devices. Let's map the MSI_ALLOC_FLAGS_PROXY_DEVICE flag onto this internal property. Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20201129135208.680293-3-maz@kernel.org
2020-12-11platform-msi: Track shared domain allocationMarc Zyngier
We have two flavours of platform-MSI: - MSIs generated by devices for themselves (the usual case) - MSIs generated on behalf of other devices, as the generating device is some form of bridge (either a wire-to-MSI bridge, or even a non-transparent PCI bridge that repaints the PCI requester ID). In the latter case, the underlying interrupt architecture may need to track this in order to keep the mapping alive even when no MSI are currently being generated. Add a set of flags to the generic msi_alloc_info_t structure, as well as the MSI_ALLOC_FLAGS_PROXY_DEVICE flag that will get advertized by the platform-MSI code when allocating an irqdomain for a device. Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20201129135208.680293-2-maz@kernel.org
2020-12-11irqchip/ti-sci-intr: Fix freeing of irqsLokesh Vutla
ti_sci_intr_irq_domain_free() assumes that out_irq of intr is stored in data->chip_data and uses it for calling ti_sci irq_free() and then mark the out_irq as available resource. But ti_sci_intr_irq_domain_alloc() is storing p_hwirq(parent's hardware irq) which is translated from out_irq. This is causing resource leakage and eventually out_irq resources might be exhausted. Fix ti_sci_intr_irq_domain_alloc() by storing the out_irq in data->chip_data. Fixes: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR") Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201102120631.11165-1-lokeshvutla@ti.com
2020-12-11irqchip/ti-sci-inta: Fix printing of inta id on probe successLokesh Vutla
On a successful probe, the driver tries to print a success message with INTA device id. It uses pdev->id for printing the id but id is stored in inta->ti_sci_id. Fix it by correcting the dev_info parameter. Fixes: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC") Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201102120614.11109-1-lokeshvutla@ti.com
2020-12-11drivers/irqchip: Remove EZChip NPS interrupt controllerVineet Gupta
NPS platform has been removed from ARC port and there are no in-tree users of it now. So RIP ! Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <maz@kernel.org> Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20201105212210.1891598-3-vgupta@synopsys.com
2020-12-11irqchip/hip04: Make IPIs use handle_percpu_devid_irq()Valentin Schneider
As done for the Arm GIC irqchips, move IPIs to handle_percpu_devid_irq() as handle_percpu_devid_fasteoi_ipi() isn't actually required. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-5-valentin.schneider@arm.com
2020-12-11irqchip/bcm2836: Make IPIs use handle_percpu_devid_irq()Valentin Schneider
As done for the Arm GIC irqchips, move IPIs to handle_percpu_devid_irq() as handle_percpu_devid_fasteoi_ipi() isn't actually required. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-4-valentin.schneider@arm.com
2020-12-11irqchip/armada-370-xp: Make IPIs use handle_percpu_devid_irq()Valentin Schneider
As done for the Arm GIC irqchips, move IPIs to handle_percpu_devid_irq() as handle_percpu_devid_fasteoi_ipi() isn't actually required. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-3-valentin.schneider@arm.com
2020-12-11irqchip/gic, gic-v3: Make SGIs use handle_percpu_devid_irq()Valentin Schneider
handle_percpu_devid_fasteoi_ipi() states: * The biggest difference with the IRQ version is that the interrupt is * EOIed early, as the IPI could result in a context switch, and we need to * make sure the IPI can fire again All that can actually happen scheduler-wise within the handling of an IPI is the raising of TIF_NEED_RESCHED (and / or folding thereof into preempt_count); see scheduler_ipi() or sched_ttwu_pending() for instance. Said flag / preempt_count is evaluated some time later before returning to whatever context was interrupted, and this gates a call to preempt_schedule_irq() (arm64_preempt_schedule_irq() in arm64). Per the above, SGI's do not need a different handler than PPI's, so make them use the same (handle_percpu_devid_irq). Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-2-valentin.schneider@arm.com
2020-12-11irqchip/ocelot: Add support for Jaguar2 platformsGregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other vcoreiii base platform: Jaguar2. Based on a larger patch from Lars Povlsen <lars.povlsen@microchip.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201125103206.136498-7-gregory.clement@bootlin.com
2020-12-11irqchip/ocelot: Add support for Serval platformsGregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other vcoreiii base platform: Serval. Based on a larger patch from Lars Povlsen <lars.povlsen@microchip.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201125103206.136498-6-gregory.clement@bootlin.com
2020-12-11irqchip/ocelot: Add support for Luton platformsGregory CLEMENT
This patch extends irqchip driver for oceleot to be used with an other vcoreiii base platform: Luton. For this platform there is a few differences: - the interrupt must be enabled for the parent controller - there is no trigger register needed to be managed Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201125103206.136498-5-gregory.clement@bootlin.com
2020-12-11irqchip/ocelot: prepare to support more SoCGregory CLEMENT
This patch extends irqchip driver for oceleot to be used with other vcoreiii base platforms. Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201125103206.136498-4-gregory.clement@bootlin.com
2020-12-11irqchip/gic-v4.1: Reduce the delay when polling GICR_VPENDBASER.DirtyShenming Lu
The 10us delay of the poll on the GICR_VPENDBASER.Dirty bit is too high, which might greatly affect the total scheduling latency of a vCPU in our measurement. So we reduce it to 1 to lessen the impact. Signed-off-by: Shenming Lu <lushenming@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201128141857.983-2-lushenming@huawei.com
2020-12-11irqchip/alpine-msi: Fix freeing of interrupts on allocation error pathMarc Zyngier
The alpine-msi driver has an interesting allocation error handling, where it frees the same interrupts repeatedly. Hilarity follows. This code is probably never executed, but let's fix it nonetheless. Fixes: e6b78f2c3e14 ("irqchip: Add the Alpine MSIX interrupt controller") Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Antoine Tenart <atenart@kernel.org> Cc: Tsahee Zidenberg <tsahee@annapurnalabs.com> Cc: Antoine Tenart <atenart@kernel.org> Link: https://lore.kernel.org/r/20201129135525.396671-1-maz@kernel.org
2020-12-11i2c: remove check that can never be trueUwe Kleine-König
A driver remove callback is only called if the device was bound before. So it's sure that both dev and dev->driver are valid and dev is an i2c device. If the check fails something louder than "return 0" might be appropriate because the problem is grave (something like memory corruption), otherwise the check is useless. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2020-12-11irqchip/ls-extirq: Add LS1043A, LS1088A external interrupt supportHou Zhiqiang
Add an new IRQ chip declaration for LS1043A and LS1088A, and cleanup the use of the "bit_reverse" property, now gated on the Soc type. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Biwen Li <biwen.li@nxp.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201130101515.27431-1-biwen.li@oss.nxp.com
generated by cgit (git 2.34.1) at 2025-09-13 21:42:29 +0000