summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-12-11mtd: rawnand: mpc5121: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 6dd09f775b72 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-5-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: gpio: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: f6341f6448e0 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-4-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: au1550: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-3-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: ams-delta: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 59d93473323a ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-2-miquel.raynal@bootlin.com
2020-12-11cpufreq: Fix cpufreq_online() return value on errorsWang ShaoBo
Make cpufreq_online() return negative error codes on all errors that cause the policy to be destroyed, as appropriate. Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-11cpufreq: Fix up several kerneldoc commentsRafael J. Wysocki
Fix up the remaining kerneldoc comments that don't adhere to the expected format and clarify some of them a bit. No functional changes. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-12-11cpufreq: stats: Use local_clock() instead of jiffiesViresh Kumar
local_clock() has better precision and accuracy as compared to jiffies, lets use it for time management in cpufreq stats. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-11cpufreq: intel_pstate: Simplify intel_cpufreq_update_pstate()Rafael J. Wysocki
Avoid doing the same assignment in both branches of a conditional, do it after the whole conditional instead. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-11Merge back cpufreq material for v5.11.Rafael J. Wysocki
2020-12-11Merge tag 'devfreq-next-for-5.11' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux Pull devfreq updates for 5.11 from Chanwoo Choi: 1. Update devfreq core - Add new devfreq_frequency tracepoint to show the frequency change information. - Add governor feature flag. The devfreq governor is able to set the specific flag in order to support a non-common feature. For example, if the governor supports the 'immutable' feature, don't allow user space to change the governor via sysfs. - Add governor sysfs attribute flag for each sysfs file. Prior to that the devfreq subsystem allowed all of the sysfs files to be accessed regardless of the governor type. But some sysfs fils are not supported by specific devfreq governors. In order to only allow the sysfs files supported by the governor to be accessed, clarify the access permissions of sysfs attributes according to the governor. When adding the devfreq governor, specify the available attribute information by using DEVFREQ_GOV_ATTR_* symbols. The user can read or write the sysfs attributes in accordance to the specified access permissions. - Clean-up the code to reduce duplication for the devfreq tracepoint and to remove redundant governor_name field from struct devfreq. 2. Update exynos-bus.c devfreq driver - Add interconnect API support to the Samsung Exynos Bus Frequency driver, exynos-bus.c. Complementing the devfreq driver with interconnect functionality allows to ensure that the QoS requirements regarding devices accessing the system memory (e.g. video processing devices) will be met and allows to avoid issues like DMA underrun. 3. Update tegra devfreq driver - Add interconnect support and OPP interface to tegra30-devfreq.c. Also, it is to guarantee the QoS requirement of some devices like the display controller. - Move tegra20-devfreq.c from drivers/devfreq/ into drivers/memory/tegra/ in order to use the more proper monitoring feature such as EMC_STAT which is located in drivers/memory/tegra/. - Separate the configuration information for different SoCs in tegra30-devfrqe.c. The tegra30-devfreq.c had been supporting both tegra30-actmon and tegra124-actmon devices. In order to use the more correct configuration data, separate them. - Use dev_err_probe() to handle the deferred probe error in tegra30-devfreq.c. 4. Pull the request of 'Tegra SoC and clock controller changes for v5.11' sent by Krzysztof Kozlowski <krzk@kernel.org> in order to avoid a build error." * tag 'devfreq-next-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux: PM / devfreq: tegra30: Separate configurations per-SoC generation PM / devfreq: tegra30: Support interconnect and OPPs from device-tree PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver PM / devfreq: exynos-bus: Add registration of interconnect child device dt-bindings: devfreq: Add documentation for the interconnect properties soc/tegra: fuse: Add stub for tegra_sku_info soc/tegra: fuse: Export tegra_read_ram_code() clk: tegra: Export Tegra20 EMC kernel symbols PM / devfreq: tegra30: Silence deferred probe error PM / devfreq: tegra20: Relax Kconfig dependency PM / devfreq: tegra20: Silence deferred probe error PM / devfreq: Remove redundant governor_name from struct devfreq PM / devfreq: Add governor attribute flag for specifc sysfs nodes PM / devfreq: Add governor feature flag PM / devfreq: Add tracepoint for frequency changes PM / devfreq: Unify frequency change to devfreq_update_target func trace: events: devfreq: Use fixed indentation size to improve readability
2020-12-11PM: domains: create debugfs nodes when adding power domainsThierry Strudel
debugfs nodes were created in genpd_debug_init alled in late_initcall preventing power domains registered though loadable modules to have a debugfs entry. Create/remove debugfs nodes when the power domain is added/removed to/from the internal gpd_list. Signed-off-by: Thierry Strudel <tstrudel@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-11mt76: remove unused variable qSouptick Joarder
Kernel test robot reported warning: drivers/net/wireless/mediatek/mt76/tx.c: In function 'mt76_txq_schedule': >> drivers/net/wireless/mediatek/mt76/tx.c:499:21: warning: variable 'q' >> set but not used [-Wunused-but-set-variable] 499 | struct mt76_queue *q; | ^ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1607542617-4005-1-git-send-email-jrdr.linux@gmail.com
2020-12-11Merge tag 'pinctrl-v5.10-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Here is a late set of pin control fixes for v5.10, most concern some minor and major issues found in the Intel drivers. Some are so hairy that I have no idea what is going on there, but luckily the maintainer knows what's up. We also have an interesting fix for AMD, which makes AMD-based laptops more stable IIUC. Summary: - Fix up some SPI group and a register offset on Intel Jasperlake - Set default bias on Intel Merrifield - Preserve debouncing on Intel Baytrail - Stop .set_type() irqchip callback in the AMD driver from fiddling with the debounce filter - Fix access to GPIO banks that are pass-thru on the Aspeed - Fix a fix for the Intel pin control driver to disable Rx/Tx when requesting a UART line as GPIO" * tag 'pinctrl-v5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: intel: Actually disable Tx and Rx buffers on GPIO request pinctrl: aspeed: Fix GPIO requests on pass-through banks pinctrl: amd: remove debounce filter setting in IRQ type setting pinctrl: baytrail: Avoid clearing debounce value when turning it off pinctrl: merrifield: Set default bias in case no particular value given pinctrl: jasperlake: Fix HOSTSW_OWN offset pinctrl: jasperlake: Unhide SPI group of pins
2020-12-11iwlwifi: fw: acpi: Demote non-conformant function headersLee Jones
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'dev' not described in 'iwl_acpi_get_dsm_object' drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'rev' not described in 'iwl_acpi_get_dsm_object' drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'func' not described in 'iwl_acpi_get_dsm_object' drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter or member 'args' not described in 'iwl_acpi_get_dsm_object' drivers/net/wireless/intel/iwlwifi/fw/acpi.c:142: warning: Function parameter or member 'dev' not described in 'iwl_acpi_get_dsm_u8' drivers/net/wireless/intel/iwlwifi/fw/acpi.c:142: warning: Function parameter or member 'rev' not described in 'iwl_acpi_get_dsm_u8' drivers/net/wireless/intel/iwlwifi/fw/acpi.c:142: warning: Function parameter or member 'func' not described in 'iwl_acpi_get_dsm_u8' 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-17-lee.jones@linaro.org
2020-12-11iwlwifi: fw: dbg: Fix misspelling of 'reg_data' in function headerLee Jones
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/intel/iwlwifi/fw/dbg.c:1932: warning: Function parameter or member 'reg_data' not described in 'iwl_dump_ini_mem' drivers/net/wireless/intel/iwlwifi/fw/dbg.c:1932: warning: Excess function parameter 'reg' description in 'iwl_dump_ini_mem' 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: Shahar S Matityahu <shahar.s.matityahu@intel.com> 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-15-lee.jones@linaro.org
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>
generated by cgit (git 2.34.1) at 2025-09-11 21:53:01 +0000