summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-03-24clk: sprd: support to get regmap from parent nodeChunyan Zhang
Some SC9863a clock nodes would be the child of a syscon node, clocks can use the regmap of syscon device directly for this kind of cases. Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Link: https://lkml.kernel.org/r/20200304072730.9193-7-zhang.lyra@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-24clk: sprd: Add macros for referencing parents without stringsChunyan Zhang
With the new clk parenting code, clk_init_data was expanded to include .parent_hws and .parent_data, for clk drivers to specify parents without name strings of clocks. Also some macros were added for using these two items to reference clock parents. Based on that to expand macros for sprd clocks: - SPRD_*_DATA, take an array of struct clk_parent_data * as its parents which should be a combination of .fw_name (devicetree clock-names), .hw (pointers to a local struct clk_hw). - SPRD_*_HW, take a local struct clk_hw pointer, instead of a string, as its parent. - SPRD_*_FW_NAME, take a string of clock-names decleared in the device tree as the clock parent. Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Link: https://lkml.kernel.org/r/20200304072730.9193-6-zhang.lyra@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-24clk: sprd: add gate for pll clocksXiaolong Zhang
Some sprd's gate clocks are used to the switch of pll, which need to wait a certain time for stable after being enabled. Signed-off-by: Xiaolong Zhang <xiaolong.zhang@unisoc.com> Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Link: https://lkml.kernel.org/r/20200304072730.9193-2-zhang.lyra@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-24bcache: remove dupplicated declaration from btree.hColy Li
Commit 253a99d95d5b ("bcache: move macro btree() and btree_root() into btree.h") makes two duplicated declaration into btree.h, typedef int (btree_map_keys_fn)(); int bch_btree_map_keys(); The kbuild test robot <lkp@intel.com> detects and reports this problem and this patch fixes it by removing the duplicated ones. Fixes: 253a99d95d5b ("bcache: move macro btree() and btree_root() into btree.h") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-25powerpc/eeh: Make early EEH init pseries specificOliver O'Halloran
The eeh_ops->probe() function is called from two different contexts: 1. On pseries, where we set EEH_PROBE_MODE_DEVTREE, it's called in eeh_add_device_early() which is supposed to run before we create a pci_dev. 2. On PowerNV, where we set EEH_PROBE_MODE_DEV, it's called in eeh_device_add_late() which is supposed to run *after* the pci_dev is created. The "early" probe is required because PAPR requires that we perform an RTAS call to enable EEH support on a device before we start interacting with it via config space or MMIO. This requirement doesn't exist on PowerNV and shoehorning two completely separate initialisation paths into a common interface just results in a convoluted code everywhere. Additionally the early probe requires the probe function to take an pci_dn rather than a pci_dev argument. We'd like to make pci_dn a pseries specific data structure since there's no real requirement for them on PowerNV. To help both goals move the early probe into the pseries containment zone so the platform depedence is more explicit. Reviewed-by: Sam Bobroff <sbobroff@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200306073904.4737-5-oohall@gmail.com
2020-03-25powerpc/eeh: Do early EEH init only when requiredOliver O'Halloran
The pci hotplug helper (pci_hp_add_devices()) calls eeh_add_device_tree_early() to scan the device-tree for new PCI devices and do the early EEH probe before the device is scanned. This early probe is a no-op in a lot of cases because: a) The early init is only required to satisfy a PAPR requirement that EEH be configured before we start doing config accesses. On PowerNV it is a no-op. b) It's a no-op for devices that have already had their eeh_dev initialised. There are four callers of pci_hp_add_devices(): 1. arch/powerpc/kernel/eeh_driver.c Here the hotplug helper is called when re-scanning pci_devs that were removed during an EEH recovery pass. The EEH stat for each removed device (the eeh_dev) is retained across a recovery pass so the early init is a no-op in this case. 2. drivers/pci/hotplug/pnv_php.c This is also a no-op since the PowerNV hotplug driver is, suprisingly, PowerNV specific. 3. drivers/pci/hotplug/rpaphp_core.c 4. drivers/pci/hotplug/rpaphp_pci.c In these two cases new devices have been hotplugged and FW has provided new DT nodes for each. These are the only two cases where the EEH we might have new PCI device nodes in the DT so these are the only two cases where the early EEH probe needs to be done. We can move the calls to eeh_add_device_tree_early() to the locations where it's needed and remove it from the generic path. This is preparation for making the early EEH probe pseries specific. Reviewed-by: Sam Bobroff <sbobroff@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200306073904.4737-3-oohall@gmail.com
2020-03-25cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_work_fnPratik Rajesh Sampat
The patch avoids allocating cpufreq_policy on stack hence fixing frame size overflow in 'powernv_cpufreq_work_fn' Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling") Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com> Reviewed-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200316135743.57735-1-psampat@linux.ibm.com
2020-03-25PCI: rpaphp: Remove unused variable 'value'Chen Zhou
Fixes gcc '-Wunused-but-set-variable' warning: drivers/pci/hotplug/rpaphp_core.c: In function is_php_type: drivers/pci/hotplug/rpaphp_core.c:291:16: warning: variable value set but not used [-Wunused-but-set-variable] Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200312140412.32373-1-chenzhou10@huawei.com
2020-03-24Merge tag 'mlx5-fixes-2020-03-24' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== Mellanox, mlx5 fixes 2020-03-24 This series introduces some fixes to mlx5 driver. From Aya, Fixes to the RX error recovery flows From Leon, Fix IB capability mask Please pull and let me know if there is any problem. For -stable v5.5 ('net/mlx5_core: Set IB capability mask1 to fix ib_srpt connection failure') For -stable v5.4 ('net/mlx5e: Fix ICOSQ recovery flow with Striding RQ') ('net/mlx5e: Do not recover from a non-fatal syndrome') ('net/mlx5e: Fix missing reset of SW metadata in Striding RQ reset') ('net/mlx5e: Enhance ICOSQ WQE info fields') The above patch ('net/mlx5e: Enhance ICOSQ WQE info fields') will fail to apply cleanly on v5.4 due to a trivial contextual conflict, but it is an important fix, do I need to do something about it or just assume Greg will know how to handle this ? ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24r8169: re-enable MSI on RTL8168cHeiner Kallweit
The original change fixed an issue on RTL8168b by mimicking the vendor driver behavior to disable MSI on chip versions before RTL8168d. This however now caused an issue on a system with RTL8168c, see [0]. Therefore leave MSI disabled on RTL8168b, but re-enable it on RTL8168c. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1792839 Fixes: 003bd5b4a7b4 ("r8169: don't use MSI before RTL8168d") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24soc: fsl: qe: fix sparse warnings for ucc_slow.cLi Yang
Fixes the following sparse warnings, some of these endian issues are real issues that need to be fixed. drivers/soc/fsl/qe/ucc_slow.c:78:17: warning: incorrect type in assignment (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:78:17: expected struct ucc_slow *us_regs drivers/soc/fsl/qe/ucc_slow.c:78:17: got struct ucc_slow [noderef] <asn:2> *us_regs drivers/soc/fsl/qe/ucc_slow.c:81:18: warning: incorrect type in argument 1 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:81:18: expected void const volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:81:18: got restricted __be32 * drivers/soc/fsl/qe/ucc_slow.c:90:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:90:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:90:9: got restricted __be32 * drivers/soc/fsl/qe/ucc_slow.c:99:17: warning: incorrect type in assignment (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:99:17: expected struct ucc_slow *us_regs drivers/soc/fsl/qe/ucc_slow.c:99:17: got struct ucc_slow [noderef] <asn:2> *us_regs drivers/soc/fsl/qe/ucc_slow.c:102:18: warning: incorrect type in argument 1 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:102:18: expected void const volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:102:18: got restricted __be32 * drivers/soc/fsl/qe/ucc_slow.c:111:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:111:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:111:9: got restricted __be32 * drivers/soc/fsl/qe/ucc_slow.c:172:28: warning: Using plain integer as NULL pointer drivers/soc/fsl/qe/ucc_slow.c:174:25: warning: cast removes address space '<asn:2>' of expression drivers/soc/fsl/qe/ucc_slow.c:175:25: warning: cast removes address space '<asn:2>' of expression drivers/soc/fsl/qe/ucc_slow.c:194:23: warning: incorrect type in assignment (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:194:23: expected struct ucc_slow_pram *us_pram drivers/soc/fsl/qe/ucc_slow.c:194:23: got void [noderef] <asn:2> * drivers/soc/fsl/qe/ucc_slow.c:204:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:204:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:204:9: got restricted __be16 * drivers/soc/fsl/qe/ucc_slow.c:229:41: warning: incorrect type in assignment (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:229:41: expected struct qe_bd *tx_bd drivers/soc/fsl/qe/ucc_slow.c:229:41: got void [noderef] <asn:2> * drivers/soc/fsl/qe/ucc_slow.c:232:17: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:232:17: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:232:17: got restricted __be32 * drivers/soc/fsl/qe/ucc_slow.c:234:17: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:234:17: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:234:17: got unsigned int [usertype] * drivers/soc/fsl/qe/ucc_slow.c:238:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:238:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:238:9: got restricted __be32 * drivers/soc/fsl/qe/ucc_slow.c:239:9: warning: cast from restricted __be32 drivers/soc/fsl/qe/ucc_slow.c:239:9: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/ucc_slow.c:239:9: expected unsigned int [usertype] val drivers/soc/fsl/qe/ucc_slow.c:239:9: got restricted __be32 [usertype] drivers/soc/fsl/qe/ucc_slow.c:239:9: warning: cast from restricted __be32 drivers/soc/fsl/qe/ucc_slow.c:239:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:239:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:239:9: got unsigned int [usertype] * drivers/soc/fsl/qe/ucc_slow.c:242:26: warning: incorrect type in assignment (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:242:26: expected struct qe_bd *rx_bd drivers/soc/fsl/qe/ucc_slow.c:242:26: got void [noderef] <asn:2> * drivers/soc/fsl/qe/ucc_slow.c:245:17: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:245:17: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:245:17: got unsigned int [usertype] * drivers/soc/fsl/qe/ucc_slow.c:247:17: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:247:17: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:247:17: got restricted __be32 * drivers/soc/fsl/qe/ucc_slow.c:251:9: warning: cast from restricted __be32 drivers/soc/fsl/qe/ucc_slow.c:251:9: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/ucc_slow.c:251:9: expected unsigned int [usertype] val drivers/soc/fsl/qe/ucc_slow.c:251:9: got restricted __be32 [usertype] drivers/soc/fsl/qe/ucc_slow.c:251:9: warning: cast from restricted __be32 drivers/soc/fsl/qe/ucc_slow.c:251:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:251:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:251:9: got unsigned int [usertype] * drivers/soc/fsl/qe/ucc_slow.c:252:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:252:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:252:9: got restricted __be32 * drivers/soc/fsl/qe/ucc_slow.c:276:39: warning: mixing different enum types: drivers/soc/fsl/qe/ucc_slow.c:276:39: unsigned int enum ucc_slow_tx_oversampling_rate drivers/soc/fsl/qe/ucc_slow.c:276:39: unsigned int enum ucc_slow_rx_oversampling_rate drivers/soc/fsl/qe/ucc_slow.c:296:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:296:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:296:9: got restricted __be16 * drivers/soc/fsl/qe/ucc_slow.c:297:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc_slow.c:297:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc_slow.c:297:9: got restricted __be16 * Signed-off-by: Li Yang <leoyang.li@nxp.com>
2020-03-24soc: fsl: qe: ucc_slow: remove 0 assignment for kzalloc'ed structureLi Yang
Not necessary to set to 0 for the kzalloc'ed area so remove these assignements. Signed-off-by: Li Yang <leoyang.li@nxp.com>
2020-03-24soc: fsl: qe: fix sparse warnings for qe_ic.cLi Yang
Fixes the following sparse warnings: drivers/soc/fsl/qe/qe_ic.c:253:32: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:253:32: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:253:32: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:254:26: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:254:26: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:254:26: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:269:32: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:269:32: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:269:32: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:270:26: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:270:26: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:270:26: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:341:31: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:341:31: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:341:31: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:357:31: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:357:31: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:357:31: got unsigned int [noderef] [usertype] <asn:2> *regs drivers/soc/fsl/qe/qe_ic.c:450:26: warning: incorrect type in argument 1 (different base types) drivers/soc/fsl/qe/qe_ic.c:450:26: expected restricted __be32 [noderef] [usertype] <asn:2> *base drivers/soc/fsl/qe/qe_ic.c:450:26: got unsigned int [noderef] [usertype] <asn:2> *regs Signed-off-by: Li Yang <leoyang.li@nxp.com> Reviewed-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
2020-03-24soc: fsl: qe: fix sparse warnings for ucc.cLi Yang
Fixes the following sparse warnings: drivers/soc/fsl/qe/ucc.c:637:20: warning: incorrect type in assignment (different address spaces) drivers/soc/fsl/qe/ucc.c:637:20: expected struct qe_mux *qe_mux_reg drivers/soc/fsl/qe/ucc.c:637:20: got struct qe_mux [noderef] <asn:2> * drivers/soc/fsl/qe/ucc.c:652:9: warning: incorrect type in argument 1 (different address spaces) drivers/soc/fsl/qe/ucc.c:652:9: expected void const volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc.c:652:9: got restricted __be32 * drivers/soc/fsl/qe/ucc.c:652:9: warning: incorrect type in argument 2 (different address spaces) drivers/soc/fsl/qe/ucc.c:652:9: expected void volatile [noderef] <asn:2> *addr drivers/soc/fsl/qe/ucc.c:652:9: got restricted __be32 * Signed-off-by: Li Yang <leoyang.li@nxp.com> Reviewed-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
2020-03-24soc: fsl: qe: fix sparse warning for qe_common.cLi Yang
Fixes the following sparse warning: drivers/soc/fsl/qe/qe_common.c:75:48: warning: incorrect type in argument 2 (different base types) drivers/soc/fsl/qe/qe_common.c:75:48: expected restricted __be32 const [usertype] *addr drivers/soc/fsl/qe/qe_common.c:75:48: got unsigned int * Signed-off-by: Li Yang <leoyang.li@nxp.com> Reviewed-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
2020-03-24soc: fsl: qe: fix sparse warnings for qe.cLi Yang
Fixes the following sparse warnings: drivers/soc/fsl/qe/qe.c:426:9: warning: cast to restricted __be32 drivers/soc/fsl/qe/qe.c:528:41: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/qe.c:528:41: expected unsigned long long static [addressable] [toplevel] [usertype] extended_modes drivers/soc/fsl/qe/qe.c:528:41: got restricted __be64 const [usertype] extended_modes Signed-off-by: Li Yang <leoyang.li@nxp.com>
2020-03-24net: phy: mdio-bcm-unimac: Fix clock handlingAndre Przywara
The DT binding for this PHY describes an *optional* clock property. Due to a bug in the error handling logic, we are actually ignoring this clock *all* of the time so far. Fix this by using devm_clk_get_optional() to handle this clock properly. Fixes: b78ac6ecd1b6b ("net: phy: mdio-bcm-unimac: Allow configuring MDIO clock divider") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: phy: mscc: consolidate a common RGMII delay implementationVladimir Oltean
It looks like the VSC8584 PHY driver is rolling its own RGMII delay configuration code, despite the fact that the logic is mostly the same. In fact only the register layout and position for the RGMII controls has changed. So we need to adapt and parameterize the PHY-dependent bit fields when calling the new generic function. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-25PM / devfreq: Fix handling dev_pm_qos_remove_request resultLeonard Crestez
The dev_pm_qos_remove_request function can return 1 if "aggregated constraint value has changed" so only negative values should be reported as errors. Fixes: 27dbc542f651 ("PM / devfreq: Use PM QoS for sysfs min/max_freq") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-03-25PM / devfreq: Fix a typo in a commentChristophe JAILLET
'govenror' was used in place of 'governor' Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-03-25PM / devfreq: Change to DEVFREQ_GOV_UPDATE_INTERVAL event nameChanwoo Choi
DEVFREQ_GOV_INTERVAL event indicates that update the interval for polling mode of devfreq device. But, this event name doesn't specify exactly what to do. Change DEVFREQ_GOV_INTERVAL event name to DEVFREQ_GOV_UPDATE_INTERVAL which specifies what to do by event name. And modify the function name to DEVFREQ_GOV_UPDATE_INTERVAL with 'devfreq_' prefix + verb + object as following: - devfreq_interval_update -> devfreq_updatee_interval Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-03-25PM / devfreq: Remove unneeded extern keywordChanwoo Choi
Remove unneeded extern keyword from devfreq-related header file and adjust the indentation of function parameter to keep the consistency in header file Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-03-25PM / devfreq: Use constant name of userspace governorpierre Kuo
Based on commit aa7c352f9841 ("PM / devfreq: Define the constant governor name"), use constant name for userspace governor. Signed-off-by: pierre Kuo <vichy.kuo@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-03-24net: axienet: Allow DMA to beyond 4GBAndre Przywara
With all DMA address accesses wrapped, we can actually support 64-bit DMA if this option was chosen at IP integration time. If the IP has been configured for an address width greater than 32 bits, we assume the full 64 bit DMA width is working. In practise this will be limited by the actual system address bus width, which will ideally be the same as the DMA IP address width. If this is not the case, the actual width can still be configured using a dma-ranges property in the parent of the MAC node. This increases the DMA mask on those systems to let the kernel choose buffers from memory at higher addresses. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Autodetect 64-bit DMA capabilityAndre Przywara
When newer revisions of the Axienet IP are configured for a 64-bit bus, we *need* to write to the MSB part of the an address registers, otherwise the IP won't recognise this as a DMA start condition. This is even true when the actual DMA address comes from the lower 4 GB. To autodetect this configuration, at probe time we write all 1's to such an MSB register, and see if any bits stick. If this is configured for a 32-bit bus, those MSB registers are RES0, so reading back 0 indicates that no MSB writes are necessary. On the other hands reading anything other than 0 indicated the need to write the MSB registers, so we set the respective flag. The actual DMA mask stays at 32-bit for now. To help bisecting, a separate patch will enable allocations from higher addresses. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Upgrade descriptors to hold 64-bit addressesAndre Przywara
Newer revisions of the AXI DMA IP (>= v7.1) support 64-bit addresses, both for the descriptors itself, as well as for the buffers they are pointing to. This is realised by adding "MSB" words for the next and phys pointer right behind the existing address word, now named "LSB". These MSB words live in formerly reserved areas of the descriptor. If the hardware supports it, write both words when setting an address. The buffer address is handled by two wrapper functions, the two occasions where we set the next pointers are open coded. For now this is guarded by a flag which we don't set yet. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Wrap DMA pointer writes to prepare for 64 bitAndre Przywara
Newer versions of the Xilink DMA IP support busses with more than 32 address bits, by introducing an MSB word for the registers holding DMA pointers (tail/current, RX/TX descriptor addresses). On IP configured for more than 32 bits, it is also *required* to write both words, to let the IP recognise this as a start condition for an MM2S request, for instance. Wrap the DMA pointer writes with a separate function, to add this functionality later. For now we stick to the lower 32 bits. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Add mii-tool supportAndre Przywara
mii-tool is useful for debugging, and all it requires to work is to wire up the ioctl ops function pointer. Add this to the axienet driver to enable mii-tool. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Drop MDIO interrupt registers from ethtools dumpAndre Przywara
Newer revisions of the IP don't have these registers. Since we don't really use them, just drop them from the ethtools dump. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Mark eth_irq as optionalAndre Przywara
According to the DT binding, the Ethernet core interrupt is optional. Use platform_get_irq_optional() to avoid the error message when the IRQ is not specified. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Check for DMA mapping errorsAndre Przywara
Especially with the default 32-bit DMA mask, DMA buffers are a limited resource, so their allocation can fail. So as the DMA API documentation requires, add error checking code after dma_map_single() calls to catch the case where we run out of "low" memory. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Factor out TX descriptor chain cleanupAndre Przywara
Factor out the code that cleans up a number of connected TX descriptors, as we will need it to properly roll back a failed _xmit() call. There are subtle differences between cleaning up a successfully sent chain (unknown number of involved descriptors, total data size needed) and a chain that was about to set up (number of descriptors known), so cater for those variations with some extra parameters. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Improve DMA error handlingAndre Przywara
Since 0 is a valid DMA address, we cannot use the physical address to check whether a TX descriptor is valid and is holding a DMA mapping. Use the "cntrl" member of the descriptor to make this decision, as it contains at least the length of the buffer, so 0 points to an uninitialised buffer. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Fix DMA descriptor cleanup pathAndre Przywara
When axienet_dma_bd_init() bails out during the initialisation process, it might do so with parts of the structure already allocated and initialised, while other parts have not been touched yet. Before returning in this case, we call axienet_dma_bd_release(), which does not take care of this corner case. This is most obvious by the first loop happily dereferencing lp->rx_bd_v, which we actually check to be non NULL *afterwards*. Make sure we only unmap or free already allocated structures, by: - directly returning with -ENOMEM if nothing has been allocated at all - checking for lp->rx_bd_v to be non-NULL *before* using it - only unmapping allocated DMA RX regions This avoids NULL pointer dereferences when initialisation fails. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Propagate failure of DMA descriptor setupAndre Przywara
When we fail allocating the DMA buffers in axienet_dma_bd_init(), we report this error, but carry on with initialisation nevertheless. This leads to a kernel panic when the driver later wants to send a packet, as it uses uninitialised data structures. Make the axienet_device_reset() routine return an error value, as it contains the DMA buffer initialisation. Make sure we propagate the error up the chain and eventually fail the driver initialisation, to avoid relying on non-initialised buffers. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: axienet: Convert DMA error handler to a work queueAndre Przywara
The DMA error handler routine is currently a tasklet, scheduled to run after the DMA error IRQ was handled. However it needs to take the MDIO mutex, which is not allowed to do in a tasklet. A kernel (with debug options) complains consequently: [ 614.050361] net eth0: DMA Tx error 0x174019 [ 614.064002] net eth0: Current BD is at: 0x8f84aa0ce [ 614.080195] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:935 [ 614.109484] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 40, name: kworker/u4:4 [ 614.135428] 3 locks held by kworker/u4:4/40: [ 614.149075] #0: ffff000879863328 ((wq_completion)rpciod){....}, at: process_one_work+0x1f0/0x6a8 [ 614.177528] #1: ffff80001251bdf8 ((work_completion)(&task->u.tk_work)){....}, at: process_one_work+0x1f0/0x6a8 [ 614.209033] #2: ffff0008784e0110 (sk_lock-AF_INET-RPC){....}, at: tcp_sendmsg+0x24/0x58 [ 614.235429] CPU: 0 PID: 40 Comm: kworker/u4:4 Not tainted 5.6.0-rc3-00926-g4a165a9d5921 #26 [ 614.260854] Hardware name: ARM Test FPGA (DT) [ 614.274734] Workqueue: rpciod rpc_async_schedule [ 614.289022] Call trace: [ 614.296871] dump_backtrace+0x0/0x1a0 [ 614.308311] show_stack+0x14/0x20 [ 614.318751] dump_stack+0xbc/0x100 [ 614.329403] ___might_sleep+0xf0/0x140 [ 614.341018] __might_sleep+0x4c/0x80 [ 614.352201] __mutex_lock+0x5c/0x8a8 [ 614.363348] mutex_lock_nested+0x1c/0x28 [ 614.375654] axienet_dma_err_handler+0x38/0x388 [ 614.389999] tasklet_action_common.isra.15+0x160/0x1a8 [ 614.405894] tasklet_action+0x24/0x30 [ 614.417297] efi_header_end+0xe0/0x494 [ 614.429020] irq_exit+0xd0/0xd8 [ 614.439047] __handle_domain_irq+0x60/0xb0 [ 614.451877] gic_handle_irq+0xdc/0x2d0 [ 614.463486] el1_irq+0xcc/0x180 [ 614.473451] __tcp_transmit_skb+0x41c/0xb58 [ 614.486513] tcp_write_xmit+0x224/0x10a0 [ 614.498792] __tcp_push_pending_frames+0x38/0xc8 [ 614.513126] tcp_rcv_established+0x41c/0x820 [ 614.526301] tcp_v4_do_rcv+0x8c/0x218 [ 614.537784] __release_sock+0x5c/0x108 [ 614.549466] release_sock+0x34/0xa0 [ 614.560318] tcp_sendmsg+0x40/0x58 [ 614.571053] inet_sendmsg+0x40/0x68 [ 614.582061] sock_sendmsg+0x18/0x30 [ 614.593074] xs_sendpages+0x218/0x328 [ 614.604506] xs_tcp_send_request+0xa0/0x1b8 [ 614.617461] xprt_transmit+0xc8/0x4f0 [ 614.628943] call_transmit+0x8c/0xa0 [ 614.640028] __rpc_execute+0xbc/0x6f8 [ 614.651380] rpc_async_schedule+0x28/0x48 [ 614.663846] process_one_work+0x298/0x6a8 [ 614.676299] worker_thread+0x40/0x490 [ 614.687687] kthread+0x134/0x138 [ 614.697804] ret_from_fork+0x10/0x18 [ 614.717319] xilinx_axienet 7fe00000.ethernet eth0: Link is Down [ 615.748343] xilinx_axienet 7fe00000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off Since tasklets are not really popular anymore anyway, lets convert this over to a work queue, which can sleep and thus can take the MDIO mutex. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24net: xilinx: temac: Relax Kconfig dependenciesAndre Przywara
Similar to axienet, the temac driver is now architecture agnostic, and can be at least compiled for several architectures. Especially the fact that this is a soft IP for implementing in FPGAs makes the current restriction rather pointless, as it could literally appear on any architecture, as long as an FPGA is connected to the bus. The driver hasn't been actually tried on any hardware, it is just a drive-by patch when doing the same for axienet (a similar patch for axienet is already merged). This (temac and axienet) have been compile-tested for: alpha hppa64 microblaze mips64 powerpc powerpc64 riscv64 s390 sparc64 (using kernel.org cross compilers). Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24cxgb4/ptp: pass the sign of offset delta in FW CMDRaju Rangoju
cxgb4_ptp_fineadjtime() doesn't pass the signedness of offset delta in FW_PTP_CMD. Fix it by passing correct sign. Signed-off-by: Raju Rangoju <rajur@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24IB/mlx5: Generally use the WC auto detection test resultYishai Hadas
Now that we have direct and reliable detection of WC support by the system, use is broadly. The only case we have to worry about is when the WC autodetector cannot run. For this fringe case generally assume that that WC is available, except in the well defined case of no PAT support on x86 which is tested by calling arch_can_pci_mmap_wc(). If WC is wrongly assumed to be available then it causes a small performance hit on paths in userspace that are tuned to the assumption that WC is available. There is no functional loss. It is very unlikely that any platforms exist that lack WC and also care about the micro optimization of WC in the fringe case where autodetection does not work. By removing the fairly bogus CONFIG tests this makes WC work broadly on all arches and all platforms. Link: https://lore.kernel.org/r/20200318100323.46659-1-leon@kernel.org Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Reviewed-by: Michael Guralnik <michaelgur@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-03-24net: phy: mdio-mux-bcm-iproc: use readl_poll_timeout() to simplify codeDejin Zheng
use readl_poll_timeout() to replace the poll codes for simplify iproc_mdio_wait_for_idle() function Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24RDMA/hns: Optimize mhop put flow for multi-hop addressingXi Wang
Optimizes hns_roce_table_mhop_get() by encapsulating code about clearing hem into clear_mhop_hem(), which will make the code flow clearer. Link: https://lore.kernel.org/r/1584417324-2255-3-git-send-email-liweihang@huawei.com Signed-off-by: Xi Wang <wangxi11@huawei.com> Signed-off-by: Weihang Li <liweihang@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-03-24RDMA/hns: Optimize mhop get flow for multi-hop addressingXi Wang
Splits hns_roce_table_mhop_get() into 4 sub-functions to make the code flow clearer. Link: https://lore.kernel.org/r/1584417324-2255-2-git-send-email-liweihang@huawei.com Signed-off-by: Xi Wang <wangxi11@huawei.com> Signed-off-by: Weihang Li <liweihang@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-03-25extcon: axp288: Add wakeup supportHans de Goede
On devices with an AXP288, we need to wakeup from suspend when a charger is plugged in, so that we can do charger-type detection and so that the axp288-charger driver, which listens for our extcon events, can configure the input-current-limit accordingly. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-03-25extcon: Mark extcon_get_edev_name() function as exported symbolMayank Rana
extcon_get_edev_name() function provides client driver to request extcon dev's name. If extcon driver and client driver are compiled as loadable modules, extcon_get_edev_name() function symbol is not visible to client driver. Hence mark extcon_find_edev_name() function as exported symbol. Signed-off-by: Mayank Rana <mrana@codeaurora.org> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-03-25extcon: palmas: Hide error messages if gpio returns -EPROBE_DEFERH. Nikolaus Schaller
If the gpios are probed after this driver (e.g. if they come from an i2c expander) there is no need to print an error message. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-03-24Merge tag 'wireless-drivers-next-2020-03-24' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.7 Second set of patches for v5.7. Lots of cleanup patches this time, but of course various new features as well fixes. When merging with wireless-drivers this pull request has a conflict in: drivers/net/wireless/intel/iwlwifi/pcie/drv.c To solve that just drop the changes from commit cf52c8a776d1 in wireless-drivers and take the hunk from wireless-drivers-next as is. The list of specific subsystem device IDs are not necessary after commit d6f2134a3831 (in wireless-drivers-next) anymore, the detection is based on other characteristics of the devices. Major changes: qtnfmac * support WPA3 SAE and OWE in AP mode ath10k * support for getting btcoex settings from Device Tree * support QCA9377 SDIO device ath11k * add HE rate accounting * add thermal sensor and cooling devices mt76 * MT7663 support for the MT7615 driver ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-24RDMA/bnxt_re: Wait for all the CQ events before freeing CQ data structuresSelvin Xavier
Destroy CQ command to firmware returns the num_cnq_events as a response. This indicates the driver about the number of CQ events generated for this CQ. Driver should wait for all these events before freeing the CQ host structures. Also, add routine to clean all the pending notification for the CQs getting destroyed. This avoids the possibility of accessing the CQ data structures after its freed. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Link: https://lore.kernel.org/r/1584120842-3200-1-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-03-24RDMA/mlx5: Fix access to wrong pointer while performing flush due to errorLeon Romanovsky
The main difference between send and receive SW completions is related to separate treatment of WQ queue. For receive completions, the initial index to be flushed is stored in "tail", while for send completions, it is in deleted "last_poll". CPU: 54 PID: 53405 Comm: kworker/u161:0 Kdump: loaded Tainted: G OE --------- -t - 4.18.0-147.el8.ppc64le #1 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] NIP: c000003c7c00a000 LR: c00800000e586af4 CTR: c000003c7c00a000 REGS: c0000036cc9db940 TRAP: 0400 Tainted: G OE --------- -t - (4.18.0-147.el8.ppc64le) MSR: 9000000010009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24004488 XER: 20040000 CFAR: c00800000e586af0 IRQMASK: 0 GPR00: c00800000e586ab4 c0000036cc9dbbc0 c00800000e5f1a00 c0000037d8433800 GPR04: c000003895a26800 c0000037293f2000 0000000000000201 0000000000000011 GPR08: c000003895a26c80 c000003c7c00a000 0000000000000000 c00800000ed30438 GPR12: c000003c7c00a000 c000003fff684b80 c00000000017c388 c00000396ec4be40 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: c00000000151e498 0000000000000010 c000003895a26848 0000000000000010 GPR24: 0000000000000010 0000000000010000 c000003895a26800 0000000000000000 GPR28: 0000000000000010 c0000037d8433800 c000003895a26c80 c000003895a26800 NIP [c000003c7c00a000] 0xc000003c7c00a000 LR [c00800000e586af4] __ib_process_cq+0xec/0x1b0 [ib_core] Call Trace: [c0000036cc9dbbc0] [c00800000e586ab4] __ib_process_cq+0xac/0x1b0 [ib_core] (unreliable) [c0000036cc9dbc40] [c00800000e586c88] ib_cq_poll_work+0x40/0xb0 [ib_core] [c0000036cc9dbc70] [c000000000171f44] process_one_work+0x2f4/0x5c0 [c0000036cc9dbd10] [c000000000172a0c] worker_thread+0xcc/0x760 [c0000036cc9dbdc0] [c00000000017c52c] kthread+0x1ac/0x1c0 [c0000036cc9dbe30] [c00000000000b75c] ret_from_kernel_thread+0x5c/0x80 Fixes: 8e3b68830186 ("RDMA/mlx5: Delete unreachable handle_atomic code by simplifying SW completion") Link: https://lore.kernel.org/r/20200318091640.44069-1-leon@kernel.org Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-03-24RDMA/core: Ensure security pkey modify is not lostMike Marciniszyn
The following modify sequence (loosely based on ipoib) will lose a pkey modifcation: - Modify (pkey index, port) - Modify (new pkey index, NO port) After the first modify, the qp_pps list will have saved the pkey and the unit on the main list. During the second modify, get_new_pps() will fetch the port from qp_pps and read the new pkey index from qp_attr->pkey_index. The state will still be zero, or IB_PORT_PKEY_NOT_VALID. Because of the invalid state, the new values will never replace the one in the qp pps list, losing the new pkey. This happens because the following if statements will never correct the state because the first term will be false. If the code had been executed, it would incorrectly overwrite valid values. if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask & IB_QP_PORT)) new_pps->main.state = IB_PORT_PKEY_VALID; if (!(qp_attr_mask & (IB_QP_PKEY_INDEX | IB_QP_PORT)) && qp_pps) { new_pps->main.port_num = qp_pps->main.port_num; new_pps->main.pkey_index = qp_pps->main.pkey_index; if (qp_pps->main.state != IB_PORT_PKEY_NOT_VALID) new_pps->main.state = IB_PORT_PKEY_VALID; } Fix by joining the two if statements with an or test to see if qp_pps is non-NULL and in the correct state. Fixes: 1dd017882e01 ("RDMA/core: Fix protection fault in get_pkey_idx_qp_list") Link: https://lore.kernel.org/r/20200313124704.14982.55907.stgit@awfm-01.aw.intel.com Reviewed-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-03-24IB/mlx5: Fix a NULL vs IS_ERR() checkDan Carpenter
The kzalloc() function returns NULL, not error pointers. Fixes: 30f2fe40c72b ("IB/mlx5: Introduce UAPIs to manage packet pacing") Link: https://lore.kernel.org/r/20200320132641.GF95012@mwanda Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
generated by cgit (git 2.34.1) at 2025-09-20 11:05:25 +0000