summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-12-11iwlwifi: iwl-phy-db: Add missing struct member description for 'trans'Lee Jones
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/intel/iwlwifi/iwl-phy-db.c:97: warning: Function parameter or member 'trans' not described in 'iwl_phy_db' Cc: Johannes Berg <johannes.berg@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Intel Linux Wireless <linuxwifi@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201126133152.3211309-14-lee.jones@linaro.org
2020-12-11iwlwifi: iwl-eeprom-parse: Fix 'struct iwl_eeprom_enhanced_txpwr's headerLee Jones
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c:340: warning: cannot understand function prototype: 'struct iwl_eeprom_enhanced_txpwr ' Cc: Johannes Berg <johannes.berg@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Intel Linux Wireless <linuxwifi@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201126133152.3211309-9-lee.jones@linaro.org
2020-12-11iwlwifi: iwl-eeprom-read: Demote one nonconformant function headerLee Jones
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function parameter or member 'trans' not described in 'iwl_read_eeprom' drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function parameter or member 'eeprom' not described in 'iwl_read_eeprom' drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function parameter or member 'eeprom_size' not described in 'iwl_read_eeprom' Cc: Johannes Berg <johannes.berg@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Intel Linux Wireless <linuxwifi@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201126133152.3211309-8-lee.jones@linaro.org
2020-12-11iwlwifi: mvm: rs: Demote non-conformant function documentation headersLee Jones
Also add documentation for 'mvm'. Fixes the following W=1 kernel build warning(s): drivers/net/wireless/intel/iwlwifi/mvm/rs.c:400: warning: cannot understand function prototype: 'const u16 expected_tpt_legacy[IWL_RATE_COUNT] = ' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'mvm' not described in '_rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'tbl' not described in '_rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'scale_index' not described in '_rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'attempts' not described in '_rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'successes' not described in '_rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Function parameter or member 'window' not described in '_rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2677: warning: duplicate section name 'NOTE' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'mvm' not described in 'rs_initialize_lq' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'sta' not described in 'rs_initialize_lq' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'lq_sta' not described in 'rs_initialize_lq' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:2682: warning: Function parameter or member 'band' not described in 'rs_initialize_lq' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:3761: warning: Function parameter or member 'mvm' not described in 'rs_program_fix_rate' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:3761: warning: Function parameter or member 'lq_sta' not described in 'rs_program_fix_rate' drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4213: warning: Function parameter or member 'mvm' not described in 'iwl_mvm_tx_protection' Cc: Johannes Berg <johannes.berg@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Intel Linux Wireless <linuxwifi@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201126133152.3211309-3-lee.jones@linaro.org
2020-12-11Merge tag 'v5.10-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "These are hopefully the last GPIO fixes for this cycle. All are driver fixes except a small resource leak for pin ranges in the gpiolib. Two are PM related, which is nice because when developers start to find PM bugs it is usually because they have smoked out the bugs of more severe nature. Summary: - Fix runtime PM balancing on the errorpath of the Arizona driver - Fix a suspend NULL pointer reference in the dwapb driver - Balance free:ing in gpiochip_generic_free() - Fix runtime PM balancing on the errorpath of the zynq driver - Fix irqdomain use-after-free in the mvebu driver - Break an eternal loop in the spreadtrum EIC driver" * tag 'v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: eic-sprd: break loop when getting NULL device resource gpio: mvebu: fix potential user-after-free on probe gpio: zynq: fix reference leak in zynq_gpio functions gpiolib: Don't free if pin ranges are not defined gpio: dwapb: fix NULL pointer dereference at dwapb_gpio_suspend() gpio: arizona: disable pm_runtime in case of failure
2020-12-11iwlwifi: iwl-drv: Fix fall-through warnings for ClangGustavo A. R. Silva
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by replacing a /* fall through */ comment with the new pseudo-keyword macro fallthrough; instead of letting the code fall through to the next case. Notice that Clang doesn't recognize /* fall through */ comments as implicit fall-through markings. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/edd98d194bfc98b4be93a9bdc303630b719c0e66.1605896060.git.gustavoars@kernel.org
2020-12-11iwlwifi: dvm: Fix fall-through warnings for ClangGustavo A. R. Silva
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly using the fallthrough pseudo-keyword as a replacement for a number of "fall through" markings. Notice that Clang doesn't recognize "fall through" comments as implicit fall-through. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201117155904.GA14551@embeddedor
2020-12-11iwlwifi: mvm: Fix fall-through warnings for ClangGustavo A. R. Silva
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly using the fallthrough pseudo-keyword as a replacement for a number of "fall through" markings. Notice that Clang doesn't recognize "fall through" comments as implicit fall-through. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201117135053.GA13248@embeddedor
2020-12-11Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "Two small clk driver build fixes - Remove __packed from a Renesas struct to improve portability - Fix a linking problem with i.MX when config options don't agree" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: renesas: r9a06g032: Drop __packed for portability clk: imx: scu: fix MXC_CLK_SCU module build break
2020-12-11Merge remote-tracking branch 'spi/for-5.11' into spi-nextMark Brown
2020-12-11Merge remote-tracking branch 'regulator/for-5.11' into regulator-nextMark Brown
2020-12-11serial: 8250_pci: Drop bogus __refdata annotationGeert Uytterhoeven
Since commit d73dfc6a4199e0e3 ("serial: 8250_pci: remove __devexit usage") in v3.9, the 8250/16550 PCI serial driver no longer has any code or data located in initmem, hence there is no need to annotate the pci_serial_quirks 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/20201211133907.2970460-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11tty: serial: meson: enable console as moduleKevin Hilman
Enable serial driver to be built as a module. To do so, init the console support on driver/module load instead of using console_initcall(). Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20201211005744.12855-1-khilman@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11usb: phy: convert comma to semicolonZheng Yongjun
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Link: https://lore.kernel.org/r/20201211085428.2871-1-zhengyongjun3@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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
generated by cgit (git 2.34.1) at 2025-09-14 02:21:44 +0000