- Linux-stable-mirror - lists.linaro.org

request for 4.14-stable: 8d4068810d9926250dd2435719a080b889eb44c3

by Sudip Mukherjee

Hi Greg, This was missing in 4.14-stable. Please apply to your queue. -- Regards Sudip

7 years, 1 month

2
1
0 0

FAILED: patch "[PATCH] net: lan78xx: Fix race in tx pending skb size calculation" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From dea39aca1d7aef1e2b95b07edeacf04cc8863a2e Mon Sep 17 00:00:00 2001 From: Stefan Wahren <stefan.wahren(a)i2se.com> Date: Sun, 15 Jul 2018 21:53:20 +0200 Subject: [PATCH] net: lan78xx: Fix race in tx pending skb size calculation The skb size calculation in lan78xx_tx_bh is in race with the start_xmit, which could lead to rare kernel oopses. So protect the whole skb walk with a spin lock. As a benefit we can unlink the skb directly. This patch was tested on Raspberry Pi 3B+ Link: https://github.com/raspberrypi/linux/issues/2608 Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Floris Bos <bos(a)je-eigen-domein.nl> Signed-off-by: Stefan Wahren <stefan.wahren(a)i2se.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c index 2e4130746c40..ed10d49eb5e0 100644 --- a/drivers/net/usb/lan78xx.c +++ b/drivers/net/usb/lan78xx.c @@ -3344,6 +3344,7 @@ static void lan78xx_tx_bh(struct lan78xx_net *dev) pkt_cnt = 0; count = 0; length = 0; + spin_lock_irqsave(&tqp->lock, flags); for (skb = tqp->next; pkt_cnt < tqp->qlen; skb = skb->next) { if (skb_is_gso(skb)) { if (pkt_cnt) { @@ -3352,7 +3353,8 @@ static void lan78xx_tx_bh(struct lan78xx_net *dev) } count = 1; length = skb->len - TX_OVERHEAD; - skb2 = skb_dequeue(tqp); + __skb_unlink(skb, tqp); + spin_unlock_irqrestore(&tqp->lock, flags); goto gso_skb; } @@ -3361,6 +3363,7 @@ static void lan78xx_tx_bh(struct lan78xx_net *dev) skb_totallen = skb->len + roundup(skb_totallen, sizeof(u32)); pkt_cnt++; } + spin_unlock_irqrestore(&tqp->lock, flags); /* copy to a single skb */ skb = alloc_skb(skb_totallen, GFP_ATOMIC);

7 years, 1 month

1
0
0 0

Linux 4.4.142

by Greg KH

I'm announcing the release of the 4.4.142 kernel. It's not an "essencial" upgrade, but a number of build problems with perf are now resolved, and an x86 issue that some people might have hit is now handled properly. If those were problems for you, please upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Makefile | 2 +- arch/x86/kernel/cpu/common.c | 7 ++++--- scripts/Kbuild.include | 5 +++-- tools/arch/x86/include/asm/unistd_32.h | 9 +++++++++ tools/arch/x86/include/asm/unistd_64.h | 9 +++++++++ tools/build/Build.include | 5 +++-- tools/perf/config/Makefile | 1 + tools/perf/perf-sys.h | 18 ------------------ tools/perf/util/include/asm/unistd_32.h | 1 - tools/perf/util/include/asm/unistd_64.h | 1 - tools/scripts/Makefile.include | 2 ++ 11 files changed, 32 insertions(+), 28 deletions(-) Andy Lutomirski (1): x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6 Arnaldo Carvalho de Melo (1): perf tools: Move syscall number fallbacks from perf-sys.h to tools/arch/x86/include/asm/ Greg Kroah-Hartman (1): Linux 4.4.142 Rasmus Villemoes (1): Kbuild: fix # escaping in .cmd files for future Make

7 years, 1 month

1
1
0 0

[PATCH 4.4 0/3] 4.4.142-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.142 release. There are 3 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Jul 20 14:51:50 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.142-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.4.142-rc1 Arnaldo Carvalho de Melo <acme(a)redhat.com> perf tools: Move syscall number fallbacks from perf-sys.h to tools/arch/x86/include/asm/ Andy Lutomirski <luto(a)kernel.org> x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6 Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Kbuild: fix # escaping in .cmd files for future Make ------------- Diffstat: Makefile | 4 ++-- arch/x86/kernel/cpu/common.c | 7 ++++--- scripts/Kbuild.include | 5 +++-- tools/arch/x86/include/asm/unistd_32.h | 9 +++++++++ tools/arch/x86/include/asm/unistd_64.h | 9 +++++++++ tools/build/Build.include | 5 +++-- tools/perf/config/Makefile | 1 + tools/perf/perf-sys.h | 18 ------------------ tools/perf/util/include/asm/unistd_32.h | 1 - tools/perf/util/include/asm/unistd_64.h | 1 - tools/scripts/Makefile.include | 2 ++ 11 files changed, 33 insertions(+), 29 deletions(-)

7 years, 1 month

3
6
0 0

[PATCH] ACPI: save NVS memory for ASUS 1025C laptop

by Willy Tarreau

Every time I tried to upgrade my laptop from 3.10.x to 4.x I faced an issue by which the fan would run at full speed upon resume. Bisecting it showed me the issue was introduced in 3.17 by commit 821d6f0359b0 (ACPI / sleep: Do not save NVS for new machines to accelerate S3). This code only affects machines built starting as of 2012, but this Asus 1025C laptop was made in 2012 and apparently needs the NVS data to be saved, otherwise the CPU's thermal state is not properly reported on resume and the fan runs at full speed upon resume. Here's a very simple way to check if such a machine is affected : # cat /sys/class/thermal/thermal_zone0/temp 55000 ( now suspend, wait one second and resume ) # cat /sys/class/thermal/thermal_zone0/temp 0 (and after ~15 seconds the fan starts to spin) Let's apply the same quirk as commit cbc00c13 (ACPI: save NVS memory for Lenovo G50-45) and reuse the function it provides. Note that this commit was already backported to 4.9.x but not 4.4.x. Cc: <linux-acpi(a)vger.kernel.org> Cc: <stable(a)vger.kernel.org> # 3.17+: requires cbc00c13 Signed-off-by: Willy Tarreau <w(a)1wt.eu> --- drivers/acpi/sleep.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c index 974e584..af54d7b 100644 --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -338,6 +338,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] __initconst = { DMI_MATCH(DMI_PRODUCT_NAME, "K54HR"), }, }, + { + .callback = init_nvs_save_s3, + .ident = "Asus 1025C", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_PRODUCT_NAME, "1025C"), + }, + }, /* * https://bugzilla.kernel.org/show_bug.cgi?id=189431 * Lenovo G50-45 is a platform later than 2012, but needs nvs memory -- 2.8.0.rc2.1.gbe9624a

7 years, 1 month

2
1
0 0

[PATCH] cpufreq: armada-37xx: Fix clock leak

by Gregory CLEMENT

There was no clk_put() balancing the clk_get(). This commit fixes it. Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") Cc: <stable(a)vger.kernel.org> Reported-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> --- drivers/cpufreq/armada-37xx-cpufreq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c index c6ebc88a7d8d..72a2975499db 100644 --- a/drivers/cpufreq/armada-37xx-cpufreq.c +++ b/drivers/cpufreq/armada-37xx-cpufreq.c @@ -202,6 +202,7 @@ static int __init armada37xx_cpufreq_driver_init(void) cur_frequency = clk_get_rate(clk); if (!cur_frequency) { dev_err(cpu_dev, "Failed to get clock rate for CPU\n"); + clk_put(clk); return -EINVAL; } @@ -210,6 +211,7 @@ static int __init armada37xx_cpufreq_driver_init(void) return -EINVAL; armada37xx_cpufreq_dvfs_setup(nb_pm_base, clk, dvfs->divider); + clk_put(clk); for (load_lvl = ARMADA_37XX_DVFS_LOAD_0; load_lvl < LOAD_LEVEL_NR; load_lvl++) { -- 2.16.3

7 years, 1 month

3
2
0 0

FAILED: patch "[PATCH] net/mlx5e: Avoid dealing with vport representors if not being" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 733d3e5497070d05971352ca5087bac83c197c3d Mon Sep 17 00:00:00 2001 From: Or Gerlitz <ogerlitz(a)mellanox.com> Date: Thu, 31 May 2018 11:32:56 +0300 Subject: [PATCH] net/mlx5e: Avoid dealing with vport representors if not being e-switch manager In smartnic env, the host (PF) driver might not be an e-switch manager, hence the switchdev mode representors are running on the embedded cpu (EC) and not at the host. As such, we should avoid dealing with vport representors if not being esw manager. While here, make sure to disallow eswitch switchdev related setups through devlink if we are not esw managers. Fixes: cb67b832921c ('net/mlx5e: Introduce SRIOV VF representors') Signed-off-by: Or Gerlitz <ogerlitz(a)mellanox.com> Reviewed-by: Eli Cohen <eli(a)mellanox.com> Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c index 56c1b6f5593e..dae4156a710d 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c @@ -2846,7 +2846,7 @@ void mlx5e_activate_priv_channels(struct mlx5e_priv *priv) mlx5e_activate_channels(&priv->channels); netif_tx_start_all_queues(priv->netdev); - if (MLX5_VPORT_MANAGER(priv->mdev)) + if (MLX5_ESWITCH_MANAGER(priv->mdev)) mlx5e_add_sqs_fwd_rules(priv); mlx5e_wait_channels_min_rx_wqes(&priv->channels); @@ -2857,7 +2857,7 @@ void mlx5e_deactivate_priv_channels(struct mlx5e_priv *priv) { mlx5e_redirect_rqts_to_drop(priv); - if (MLX5_VPORT_MANAGER(priv->mdev)) + if (MLX5_ESWITCH_MANAGER(priv->mdev)) mlx5e_remove_sqs_fwd_rules(priv); /* FIXME: This is a W/A only for tx timeout watch dog false alarm when @@ -4597,7 +4597,7 @@ static void mlx5e_build_nic_netdev(struct net_device *netdev) mlx5e_set_netdev_dev_addr(netdev); #if IS_ENABLED(CONFIG_MLX5_ESWITCH) - if (MLX5_VPORT_MANAGER(mdev)) + if (MLX5_ESWITCH_MANAGER(mdev)) netdev->switchdev_ops = &mlx5e_switchdev_ops; #endif @@ -4753,7 +4753,7 @@ static void mlx5e_nic_enable(struct mlx5e_priv *priv) mlx5e_enable_async_events(priv); - if (MLX5_VPORT_MANAGER(priv->mdev)) + if (MLX5_ESWITCH_MANAGER(priv->mdev)) mlx5e_register_vport_reps(priv); if (netdev->reg_state != NETREG_REGISTERED) @@ -4788,7 +4788,7 @@ static void mlx5e_nic_disable(struct mlx5e_priv *priv) queue_work(priv->wq, &priv->set_rx_mode_work); - if (MLX5_VPORT_MANAGER(priv->mdev)) + if (MLX5_ESWITCH_MANAGER(priv->mdev)) mlx5e_unregister_vport_reps(priv); mlx5e_disable_async_events(priv); @@ -4972,7 +4972,7 @@ static void *mlx5e_add(struct mlx5_core_dev *mdev) return NULL; #ifdef CONFIG_MLX5_ESWITCH - if (MLX5_VPORT_MANAGER(mdev)) { + if (MLX5_ESWITCH_MANAGER(mdev)) { rpriv = mlx5e_alloc_nic_rep_priv(mdev); if (!rpriv) { mlx5_core_warn(mdev, "Failed to alloc NIC rep priv data\n"); diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c index 60236f73373c..2b8040a3cdbd 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c @@ -823,7 +823,7 @@ bool mlx5e_is_uplink_rep(struct mlx5e_priv *priv) struct mlx5e_rep_priv *rpriv = priv->ppriv; struct mlx5_eswitch_rep *rep; - if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager)) + if (!MLX5_ESWITCH_MANAGER(priv->mdev)) return false; rep = rpriv->rep; diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c index cecd201f0b73..91f1209886ff 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c @@ -1079,8 +1079,8 @@ static int mlx5_devlink_eswitch_check(struct devlink *devlink) if (MLX5_CAP_GEN(dev, port_type) != MLX5_CAP_PORT_TYPE_ETH) return -EOPNOTSUPP; - if (!MLX5_CAP_GEN(dev, vport_group_manager)) - return -EOPNOTSUPP; + if(!MLX5_ESWITCH_MANAGER(dev)) + return -EPERM; if (dev->priv.eswitch->mode == SRIOV_NONE) return -EOPNOTSUPP;

7 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] net/mlx5: E-Switch, Avoid setup attempt if not being e-switch" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 0efc8562491b7d36f6bbc4fbc8f3348cb6641e9c Mon Sep 17 00:00:00 2001 From: Or Gerlitz <ogerlitz(a)mellanox.com> Date: Thu, 31 May 2018 11:16:18 +0300 Subject: [PATCH] net/mlx5: E-Switch, Avoid setup attempt if not being e-switch manager In smartnic env, the host (PF) driver might not be an e-switch manager, hence the FW will err on driver attempts to deal with setting/unsetting the eswitch and as a result the overall setup of sriov will fail. Fix that by avoiding the operation if e-switch management is not allowed for this driver instance. While here, move to use the correct name for the esw manager capability name. Fixes: 81848731ff40 ('net/mlx5: E-Switch, Add SR-IOV (FDB) support') Signed-off-by: Or Gerlitz <ogerlitz(a)mellanox.com> Reported-by: Guy Kushnir <guyk(a)mellanox.com> Reviewed-by: Eli Cohen <eli(a)melloanox.com> Tested-by: Eli Cohen <eli(a)melloanox.com> Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c index 378ad74518ec..60236f73373c 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c @@ -839,7 +839,7 @@ static bool mlx5e_is_vf_vport_rep(struct mlx5e_priv *priv) struct mlx5e_rep_priv *rpriv = priv->ppriv; struct mlx5_eswitch_rep *rep; - if (!MLX5_CAP_GEN(priv->mdev, eswitch_flow_table)) + if (!MLX5_ESWITCH_MANAGER(priv->mdev)) return false; rep = rpriv->rep; diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c index f63dfbcd29fe..103fd6a0cc65 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c @@ -1604,7 +1604,7 @@ int mlx5_eswitch_enable_sriov(struct mlx5_eswitch *esw, int nvfs, int mode) if (!ESW_ALLOWED(esw)) return 0; - if (!MLX5_CAP_GEN(esw->dev, eswitch_flow_table) || + if (!MLX5_ESWITCH_MANAGER(esw->dev) || !MLX5_CAP_ESW_FLOWTABLE_FDB(esw->dev, ft_support)) { esw_warn(esw->dev, "E-Switch FDB is not supported, aborting ...\n"); return -EOPNOTSUPP; diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c index 49a75d31185e..f1a86cea86a0 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c @@ -32,6 +32,7 @@ #include <linux/mutex.h> #include <linux/mlx5/driver.h> +#include <linux/mlx5/eswitch.h> #include "mlx5_core.h" #include "fs_core.h" @@ -2652,7 +2653,7 @@ int mlx5_init_fs(struct mlx5_core_dev *dev) goto err; } - if (MLX5_CAP_GEN(dev, eswitch_flow_table)) { + if (MLX5_ESWITCH_MANAGER(dev)) { if (MLX5_CAP_ESW_FLOWTABLE_FDB(dev, ft_support)) { err = init_fdb_root_ns(steering); if (err) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fw.c b/drivers/net/ethernet/mellanox/mlx5/core/fw.c index afd9f4fa22f4..41ad24f0de2c 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/fw.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/fw.c @@ -32,6 +32,7 @@ #include <linux/mlx5/driver.h> #include <linux/mlx5/cmd.h> +#include <linux/mlx5/eswitch.h> #include <linux/module.h> #include "mlx5_core.h" #include "../../mlxfw/mlxfw.h" @@ -159,13 +160,13 @@ int mlx5_query_hca_caps(struct mlx5_core_dev *dev) } if (MLX5_CAP_GEN(dev, vport_group_manager) && - MLX5_CAP_GEN(dev, eswitch_flow_table)) { + MLX5_ESWITCH_MANAGER(dev)) { err = mlx5_core_get_caps(dev, MLX5_CAP_ESWITCH_FLOW_TABLE); if (err) return err; } - if (MLX5_CAP_GEN(dev, eswitch_flow_table)) { + if (MLX5_ESWITCH_MANAGER(dev)) { err = mlx5_core_get_caps(dev, MLX5_CAP_ESWITCH); if (err) return err; diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sriov.c b/drivers/net/ethernet/mellanox/mlx5/core/sriov.c index 2a8b529ce6dd..a0674962f02c 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/sriov.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/sriov.c @@ -88,6 +88,9 @@ static int mlx5_device_enable_sriov(struct mlx5_core_dev *dev, int num_vfs) return -EBUSY; } + if (!MLX5_ESWITCH_MANAGER(dev)) + goto enable_vfs_hca; + err = mlx5_eswitch_enable_sriov(dev->priv.eswitch, num_vfs, SRIOV_LEGACY); if (err) { mlx5_core_warn(dev, @@ -95,6 +98,7 @@ static int mlx5_device_enable_sriov(struct mlx5_core_dev *dev, int num_vfs) return err; } +enable_vfs_hca: for (vf = 0; vf < num_vfs; vf++) { err = mlx5_core_enable_hca(dev, vf + 1); if (err) { @@ -140,7 +144,8 @@ static void mlx5_device_disable_sriov(struct mlx5_core_dev *dev) } out: - mlx5_eswitch_disable_sriov(dev->priv.eswitch); + if (MLX5_ESWITCH_MANAGER(dev)) + mlx5_eswitch_disable_sriov(dev->priv.eswitch); if (mlx5_wait_for_vf_pages(dev)) mlx5_core_warn(dev, "timeout reclaiming VFs pages\n"); diff --git a/include/linux/mlx5/eswitch.h b/include/linux/mlx5/eswitch.h index d3c9db492b30..fab5121ffb8f 100644 --- a/include/linux/mlx5/eswitch.h +++ b/include/linux/mlx5/eswitch.h @@ -8,6 +8,8 @@ #include <linux/mlx5/driver.h> +#define MLX5_ESWITCH_MANAGER(mdev) MLX5_CAP_GEN(mdev, eswitch_manager) + enum { SRIOV_NONE, SRIOV_LEGACY, diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h index 27134c4fcb76..ac281f5ec9b8 100644 --- a/include/linux/mlx5/mlx5_ifc.h +++ b/include/linux/mlx5/mlx5_ifc.h @@ -922,7 +922,7 @@ struct mlx5_ifc_cmd_hca_cap_bits { u8 vnic_env_queue_counters[0x1]; u8 ets[0x1]; u8 nic_flow_table[0x1]; - u8 eswitch_flow_table[0x1]; + u8 eswitch_manager[0x1]; u8 device_memory[0x1]; u8 mcam_reg[0x1]; u8 pcam_reg[0x1];

7 years, 1 month

1
0
0 0

[PATCHES] Networking

by David Miller

==================== READ ME. I have this stale email in my outgoing draft folder, and I have no idea if I actually sent this out successfully or not. Please double check, thanks! ==================== Please queue up the following networking bug fixes for v4.14 and v4.17 -stable, repectively. Thank you!

7 years, 1 month

2
1
0 0

[PATCH v2] powerpc/powernv : Save/Restore SPRG3 on entry/exit from stop.

by Gautham R. Shenoy

From: "Gautham R. Shenoy" <ego(a)linux.vnet.ibm.com> On 64-bit servers, SPRN_SPRG3 and its userspace read-only mirror SPRN_USPRG3 are used as userspace VDSO write and read registers respectively. SPRN_SPRG3 is lost when we enter stop4 and above, and is currently not restored. As a result, any read from SPRN_USPRG3 returns zero on an exit from stop4 and above. Thus in this situation, on POWER9, any call from sched_getcpu() always returns zero, as on powerpc, we call __kernel_getcpu() which relies upon SPRN_USPRG3 to report the CPU and NUMA node information. Fix this by restoring SPRN_SPRG3 on wake up from a deep stop state with the sprg_vdso value that is cached in PACA. Fixes: e1c1cfed5432 ("powerpc/powernv: Save/Restore additional SPRs for stop4 cpuidle") Reported-by: Florian Weimer <fweimer(a)redhat.com> Cc: <stable(a)vger.kernel.org> # 4.14 Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Michael Neuling <mikey(a)neuling.org> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com> Signed-off-by: Gautham R. Shenoy <ego(a)linux.vnet.ibm.com> --- Change from v1: Restoring the SPRG3 from paca->sprg_vdso instead of saving it separately during stop-entry, as suggested by Mikey. arch/powerpc/kernel/idle_book3s.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S index d85d551..672ead8 100644 --- a/arch/powerpc/kernel/idle_book3s.S +++ b/arch/powerpc/kernel/idle_book3s.S @@ -144,7 +144,9 @@ power9_restore_additional_sprs: mtspr SPRN_MMCR1, r4 ld r3, STOP_MMCR2(r13) + ld r4, PACA_SPRG_VDSO(r13) mtspr SPRN_MMCR2, r3 + mtspr SPRN_SPRG3, r4 blr /* -- 1.8.3.1

7 years, 1 month

2
1
0 0

[PATCH] mtd: rawnand: fsmc: Stop using chip->read_buf()

by Boris Brezillon

chip->read_buf is left unassigned since commit 4da712e70294 ("mtd: nand: fsmc: use ->exec_op()"), leading to a NULL pointer dereference when it's called from fsmc_read_page_hwecc(). Fix that by using the appropriate helper to read data out of the NAND. Fixes: 4da712e70294 ("mtd: nand: fsmc: use ->exec_op()") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> --- drivers/mtd/nand/raw/fsmc_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c index f4a5a317d4ae..e1086a010b88 100644 --- a/drivers/mtd/nand/raw/fsmc_nand.c +++ b/drivers/mtd/nand/raw/fsmc_nand.c @@ -740,7 +740,7 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip, for (i = 0, s = 0; s < eccsteps; s++, i += eccbytes, p += eccsize) { nand_read_page_op(chip, page, s * eccsize, NULL, 0); chip->ecc.hwctl(mtd, NAND_ECC_READ); - chip->read_buf(mtd, p, eccsize); + nand_read_data_op(chip, p, eccsize, false); for (j = 0; j < eccbytes;) { struct mtd_oob_region oobregion; -- 2.14.1

7 years, 1 month

2
1
0 0

[PATCH 2/2] drm/probe_helper: Add drm_helper_probe_single_connector_modes_with_rpm()

by Lyude Paul

For nouveau, while the GPU is guaranteed to be on when a hotplug has been received, the same assertion does not hold true if a connector probe has been started by userspace without having had received a sysfs event. So ensure that any connector probing keeps the GPU alive for the duration of the probe by introducing drm_helper_probe_single_connector_modes_with_rpm(). It's the same as drm_helper_probe_single_connector_modes, but it handles holding a power reference to the device for the duration of the connector probe. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Karol Herbst <karolherbst(a)gmail.com> Cc: Lukas Wunner <lukas(a)wunner.de> Cc: stable(a)vger.kernel.org --- Changes since v1: - Add a generic helper to DRM to handle this drivers/gpu/drm/drm_probe_helper.c | 31 +++++++++++++++++++++ drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 4 +-- include/drm/drm_crtc_helper.h | 7 +++-- 4 files changed, 38 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c index 527743394150..0a9d6748b854 100644 --- a/drivers/gpu/drm/drm_probe_helper.c +++ b/drivers/gpu/drm/drm_probe_helper.c @@ -31,6 +31,7 @@ #include <linux/export.h> #include <linux/moduleparam.h> +#include <linux/pm_runtime.h> #include <drm/drmP.h> #include <drm/drm_crtc.h> @@ -541,6 +542,36 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector, } EXPORT_SYMBOL(drm_helper_probe_single_connector_modes); +/** + * drm_helper_probe_single_connector_modes_with_rpm - get complete set of + * display modes + * @connector: connector to probe + * @maxX: max width for modes + * @maxY: max height for modes + * + * Same as drm_helper_probe_single_connector_modes, except that it makes sure + * that the device is active by synchronously grabbing a runtime power + * reference while probing. + * + * Returns: + * The number of modes found on @connector. + */ +int drm_helper_probe_single_connector_modes_with_rpm(struct drm_connector *connector, + uint32_t maxX, uint32_t maxY) +{ + int ret; + + ret = pm_runtime_get_sync(connector->dev->dev); + if (ret < 0 && ret != -EACCES) + return ret; + + ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY); + + pm_runtime_put(connector->dev->dev); + return ret; +} +EXPORT_SYMBOL(drm_helper_probe_single_connector_modes_with_rpm); + /** * drm_kms_helper_hotplug_event - fire off KMS hotplug events * @dev: drm_device whose connector state changed diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index fa3ab618a0f9..c54767b50fd8 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -858,7 +858,7 @@ static const struct drm_connector_funcs nv50_mstc = { .reset = nouveau_conn_reset, .detect = nv50_mstc_detect, - .fill_modes = drm_helper_probe_single_connector_modes, + .fill_modes = drm_helper_probe_single_connector_modes_with_rpm, .destroy = nv50_mstc_destroy, .atomic_duplicate_state = nouveau_conn_atomic_duplicate_state, .atomic_destroy_state = nouveau_conn_atomic_destroy_state, diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 2a45b4c2ceb0..8d9070779261 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -1088,7 +1088,7 @@ nouveau_connector_funcs = { .reset = nouveau_conn_reset, .detect = nouveau_connector_detect, .force = nouveau_connector_force, - .fill_modes = drm_helper_probe_single_connector_modes, + .fill_modes = drm_helper_probe_single_connector_modes_with_rpm, .set_property = nouveau_connector_set_property, .destroy = nouveau_connector_destroy, .atomic_duplicate_state = nouveau_conn_atomic_duplicate_state, @@ -1103,7 +1103,7 @@ nouveau_connector_funcs_lvds = { .reset = nouveau_conn_reset, .detect = nouveau_connector_detect_lvds, .force = nouveau_connector_force, - .fill_modes = drm_helper_probe_single_connector_modes, + .fill_modes = drm_helper_probe_single_connector_modes_with_rpm, .set_property = nouveau_connector_set_property, .destroy = nouveau_connector_destroy, .atomic_duplicate_state = nouveau_conn_atomic_duplicate_state, diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h index 6914633037a5..8f3f6d6fcc8c 100644 --- a/include/drm/drm_crtc_helper.h +++ b/include/drm/drm_crtc_helper.h @@ -64,9 +64,10 @@ int drm_helper_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y, struct drm_framebuffer *old_fb); /* drm_probe_helper.c */ -int drm_helper_probe_single_connector_modes(struct drm_connector - *connector, uint32_t maxX, - uint32_t maxY); +int drm_helper_probe_single_connector_modes(struct drm_connector *connector, + uint32_t maxX, uint32_t maxY); +int drm_helper_probe_single_connector_modes_with_rpm(struct drm_connector *connector, + uint32_t maxX, uint32_t maxY); int drm_helper_probe_detect(struct drm_connector *connector, struct drm_modeset_acquire_ctx *ctx, bool force); -- 2.17.1

7 years, 1 month

1
0
0 0

[PATCH 1/2] drm/fb_helper: Add drm_fb_helper_output_poll_changed_with_rpm()

by Lyude Paul

When DP MST hubs get confused, they can occasionally stop responding for a good bit of time up until the point where the DRM driver manages to do the right DPCD accesses to get it to start responding again. In a worst case scenario however, this process can take upwards of 10+ seconds. Currently we use the default output_poll_changed handler drm_fb_helper_output_poll_changed() to handle output polling, which doesn't happen to grab any power references on the device when polling. If we're unlucky enough to have a hub (such as Lenovo's infamous laptop docks for the P5x/P7x series) that's easily startled and confused, this can lead to a pretty nasty deadlock situation that looks like this: - Hotplug event from hub happens, we enter drm_fb_helper_output_poll_changed() and start communicating with the hub - While we're in drm_fb_helper_output_poll_changed() and attempting to communicate with the hub, we end up confusing it and cause it to stop responding for at least 10 seconds - After 5 seconds of being in drm_fb_helper_output_poll_changed(), the pm core attempts to put the GPU into autosuspend, which ends up calling drm_kms_helper_poll_disable() - While the runtime PM core is waiting in drm_kms_helper_poll_disable() for the output poll to finish, we end up finally detecting an MST display - We notice the new display and tries to enable it, which triggers an atomic commit which triggers a call to pm_runtime_get_sync() - the output poll thread deadlocks the pm core waiting for the pm core to finish the autosuspend request while the pm core waits for the output poll thread to finish Sample: [ 246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds. [ 246.673398] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.676527] kworker/4:0 D 0 37 2 0x80000000 [ 246.677580] Workqueue: events output_poll_execute [drm_kms_helper] [ 246.678704] Call Trace: [ 246.679753] __schedule+0x322/0xaf0 [ 246.680916] schedule+0x33/0x90 [ 246.681924] schedule_preempt_disabled+0x15/0x20 [ 246.683023] __mutex_lock+0x569/0x9a0 [ 246.684035] ? kobject_uevent_env+0x117/0x7b0 [ 246.685132] ? drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.686179] mutex_lock_nested+0x1b/0x20 [ 246.687278] ? mutex_lock_nested+0x1b/0x20 [ 246.688307] drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.689420] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper] [ 246.690462] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper] [ 246.691570] output_poll_execute+0x198/0x1c0 [drm_kms_helper] [ 246.692611] process_one_work+0x231/0x620 [ 246.693725] worker_thread+0x214/0x3a0 [ 246.694756] kthread+0x12b/0x150 [ 246.695856] ? wq_pool_ids_show+0x140/0x140 [ 246.696888] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.697998] ret_from_fork+0x3a/0x50 [ 246.699034] INFO: task kworker/0:1:60 blocked for more than 120 seconds. [ 246.700153] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.701182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.702278] kworker/0:1 D 0 60 2 0x80000000 [ 246.703293] Workqueue: pm pm_runtime_work [ 246.704393] Call Trace: [ 246.705403] __schedule+0x322/0xaf0 [ 246.706439] ? wait_for_completion+0x104/0x190 [ 246.707393] schedule+0x33/0x90 [ 246.708375] schedule_timeout+0x3a5/0x590 [ 246.709289] ? mark_held_locks+0x58/0x80 [ 246.710208] ? _raw_spin_unlock_irq+0x2c/0x40 [ 246.711222] ? wait_for_completion+0x104/0x190 [ 246.712134] ? trace_hardirqs_on_caller+0xf4/0x190 [ 246.713094] ? wait_for_completion+0x104/0x190 [ 246.713964] wait_for_completion+0x12c/0x190 [ 246.714895] ? wake_up_q+0x80/0x80 [ 246.715727] ? get_work_pool+0x90/0x90 [ 246.716649] flush_work+0x1c9/0x280 [ 246.717483] ? flush_workqueue_prep_pwqs+0x1b0/0x1b0 [ 246.718442] __cancel_work_timer+0x146/0x1d0 [ 246.719247] cancel_delayed_work_sync+0x13/0x20 [ 246.720043] drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper] [ 246.721123] nouveau_pmops_runtime_suspend+0x3d/0xb0 [nouveau] [ 246.721897] pci_pm_runtime_suspend+0x6b/0x190 [ 246.722825] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.723737] __rpm_callback+0x7a/0x1d0 [ 246.724721] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.725607] rpm_callback+0x24/0x80 [ 246.726553] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.727376] rpm_suspend+0x142/0x6b0 [ 246.728185] pm_runtime_work+0x97/0xc0 [ 246.728938] process_one_work+0x231/0x620 [ 246.729796] worker_thread+0x44/0x3a0 [ 246.730614] kthread+0x12b/0x150 [ 246.731395] ? wq_pool_ids_show+0x140/0x140 [ 246.732202] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.732878] ret_from_fork+0x3a/0x50 [ 246.733768] INFO: task kworker/4:2:422 blocked for more than 120 seconds. [ 246.734587] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.735393] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.736113] kworker/4:2 D 0 422 2 0x80000080 [ 246.736789] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] [ 246.737665] Call Trace: [ 246.738490] __schedule+0x322/0xaf0 [ 246.739250] schedule+0x33/0x90 [ 246.739908] rpm_resume+0x19c/0x850 [ 246.740750] ? finish_wait+0x90/0x90 [ 246.741541] __pm_runtime_resume+0x4e/0x90 [ 246.742370] nv50_disp_atomic_commit+0x31/0x210 [nouveau] [ 246.743124] drm_atomic_commit+0x4a/0x50 [drm] [ 246.743775] restore_fbdev_mode_atomic+0x1c8/0x240 [drm_kms_helper] [ 246.744603] restore_fbdev_mode+0x31/0x140 [drm_kms_helper] [ 246.745373] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 [drm_kms_helper] [ 246.746220] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] [ 246.746884] drm_fb_helper_hotplug_event.part.28+0x96/0xb0 [drm_kms_helper] [ 246.747675] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper] [ 246.748544] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper] [ 246.749439] nv50_mstm_hotplug+0x15/0x20 [nouveau] [ 246.750111] drm_dp_send_link_address+0x177/0x1c0 [drm_kms_helper] [ 246.750764] drm_dp_check_and_send_link_address+0xa8/0xd0 [drm_kms_helper] [ 246.751602] drm_dp_mst_link_probe_work+0x51/0x90 [drm_kms_helper] [ 246.752314] process_one_work+0x231/0x620 [ 246.752979] worker_thread+0x44/0x3a0 [ 246.753838] kthread+0x12b/0x150 [ 246.754619] ? wq_pool_ids_show+0x140/0x140 [ 246.755386] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.756162] ret_from_fork+0x3a/0x50 [ 246.756847] Showing all locks held in the system: [ 246.758261] 3 locks held by kworker/4:0/37: [ 246.759016] #0: 00000000f8df4d2d ((wq_completion)"events"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.759856] #1: 00000000e6065461 ((work_completion)(&(&dev->mode_config.output_poll_work)->work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.760670] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.761516] 2 locks held by kworker/0:1/60: [ 246.762274] #0: 00000000fff6be0f ((wq_completion)"pm"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.762982] #1: 000000005ab44fb4 ((work_completion)(&dev->power.work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.763890] 1 lock held by khungtaskd/64: [ 246.764664] #0: 000000008cb8b5c3 (rcu_read_lock){....}, at: debug_show_all_locks+0x23/0x185 [ 246.765588] 5 locks held by kworker/4:2/422: [ 246.766440] #0: 00000000232f0959 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.767390] #1: 00000000bb59b134 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.768154] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0xb0 [drm_kms_helper] [ 246.768966] #3: 000000004c8f0b6b (crtc_ww_class_acquire){+.+.}, at: restore_fbdev_mode_atomic+0x4b/0x240 [drm_kms_helper] [ 246.769921] #4: 000000004c34a296 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8a/0x1b0 [drm] [ 246.770839] 1 lock held by dmesg/1038: [ 246.771739] 2 locks held by zsh/1172: [ 246.772650] #0: 00000000836d0438 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40 [ 246.773680] #1: 000000001f4f4d48 (&ldata->atomic_read_lock){+.+.}, at: n_tty_read+0xc1/0x870 [ 246.775522] ============================================= So, to fix this (and any other possible deadlock issues like this that could occur in the output_poll_changed patch) we make sure that nouveau's output_poll_changed functions grab a runtime power ref before sending any hotplug events, and hold it until we're finished. We introduce this through adding a generic DRM helper which other drivers may reuse. This fixes deadlock issues when in fbcon with nouveau on my P50, and should fix it for everyone else's as well! Signed-off-by: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Karol Herbst <karolherbst(a)gmail.com> Cc: Lukas Wunner <lukas(a)wunner.de> Cc: stable(a)vger.kernel.org --- Changes since v1: - Add a generic helper for DRM to handle this drivers/gpu/drm/drm_fb_helper.c | 23 +++++++++++++++++++++++ drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- include/drm/drm_fb_helper.h | 5 +++++ 3 files changed, 29 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 2ee1eaa66188..1ab2f3646526 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -34,6 +34,7 @@ #include <linux/sysrq.h> #include <linux/slab.h> #include <linux/module.h> +#include <linux/pm_runtime.h> #include <drm/drmP.h> #include <drm/drm_crtc.h> #include <drm/drm_fb_helper.h> @@ -2928,6 +2929,28 @@ void drm_fb_helper_output_poll_changed(struct drm_device *dev) } EXPORT_SYMBOL(drm_fb_helper_output_poll_changed); +/** + * drm_fb_helper_output_poll_changed_with_rpm - DRM mode + * config \.output_poll_changed + * helper for fbdev emulation + * @dev: DRM device + * + * Same as drm_fb_helper_output_poll_changed, except that it makes sure that + * the device is active by synchronously grabbing a runtime power reference + * while probing. + */ +void drm_fb_helper_output_poll_changed_with_rpm(struct drm_device *dev) +{ + int ret; + + ret = pm_runtime_get_sync(dev->dev); + if (WARN_ON(ret < 0 && ret != -EACCES)) + return; + drm_fb_helper_hotplug_event(dev->fb_helper); + pm_runtime_put(dev->dev); +} +EXPORT_SYMBOL(drm_fb_helper_output_poll_changed_with_rpm); + /* The Kconfig DRM_KMS_HELPER selects FRAMEBUFFER_CONSOLE (if !EXPERT) * but the module doesn't depend on any fb console symbols. At least * attempt to load fbcon to avoid leaving the system without a usable console. diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index eb3e41a78806..fa3ab618a0f9 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -2015,7 +2015,7 @@ nv50_disp_atomic_state_alloc(struct drm_device *dev) static const struct drm_mode_config_funcs nv50_disp_func = { .fb_create = nouveau_user_framebuffer_create, - .output_poll_changed = drm_fb_helper_output_poll_changed, + .output_poll_changed = drm_fb_helper_output_poll_changed_with_rpm, .atomic_check = nv50_disp_atomic_check, .atomic_commit = nv50_disp_atomic_commit, .atomic_state_alloc = nv50_disp_atomic_state_alloc, diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h index b069433e7fc1..ca809bfbaebb 100644 --- a/include/drm/drm_fb_helper.h +++ b/include/drm/drm_fb_helper.h @@ -330,6 +330,7 @@ void drm_fb_helper_fbdev_teardown(struct drm_device *dev); void drm_fb_helper_lastclose(struct drm_device *dev); void drm_fb_helper_output_poll_changed(struct drm_device *dev); +void drm_fb_helper_output_poll_changed_with_rpm(struct drm_device *dev); #else static inline void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, @@ -564,6 +565,10 @@ static inline void drm_fb_helper_output_poll_changed(struct drm_device *dev) { } +static inline void drm_fb_helper_output_poll_changed_with_rpm(struct drm_device *dev) +{ +} + #endif static inline int -- 2.17.1

7 years, 1 month

1
0
0 0

Dear Beneficiary....28

by Mr. Jimy

Dear Beneficiary) stable(a)vger.kernel.org,, Good day! I have important information for you here. Please accept my sincere apologizes if my email disturbs your business or personal ethics and let me first introduce myself to you before telling you my reason for contacting you My name is Mr. Jim Boke Lawson from Sierra Leon and a staff in the Card Accounts Management Section of a very well-known bank, here at London United Kingdom. One of our bank accounts here has a current deposit balance of (Nine Million Three Hundred and Forty Six Thousand, One Hundred and Fifty two Great British Pounds Sterling and Point Seven Pence Only) and the Card account has been classified AS DORMANT (Lack of activities on the account (deposited or withdrawal) for last operated (11yrs) now. >From my private investigations and confirmation, the owner of this said bank account, a Foreigner by name, Mr. Jonce Ludwig died on the 4th of January 2007 in a boat accident that occurred here at Birmingham, UK Since then, nobody has done anything as regards claiming this money as no traces of family member or next of kin with any knowledge as to the existence of this bank account or the funds here. Further inquiry from our National Immigration Services here also indicated that he (Mr. Jonce Ludwig) was ONLY on a single entry into the UK, and had had intention to establish a Real Estate Firm here at United Kingdom, hence the deposit of this very fund with our bank. I have been in search for a reliable and trusted foreign partner to work with and transfer this money to you that is why I am contacting you to seek your consent to partner with me and get this funds out to you urgently. This is totally free and 100% risk free because I am the bank officer in charge of this particular account and it’s my duty at the bank to sign off the deposit to whoever I present as the administrator. I therefore propose to do this business with you, and I want you to stand in as the Next of Kin to attest to this fund, so that we can have the fund and Bank Account details released to you after due processes have been followed. Also, all the legal documents are readily available and valid to be signed and stamped in your name and it will be done without any problem as the fund is 100% legitimate and does not originate from drug money laundering, or terrorism fund or any other illegal act. As soon as the deal is done successfully, you will take 50% while 50% come to me. Please let me know your interest to work with me by responding to this through my private email address as follows: Thanking you for accepting to do this with us. I remain sincerely, Mr. Jimy Boke Lawson.

7 years, 1 month

1
0
0 0

[PATCH] Input: i8042 - add Lenovo LaVie Z to the i8042 reset list

by Chen-Yu Tsai

The Lenovo LaVie Z laptop requires i8042 to be reset in order to consistently detect its Elantech touchpad. The nomux and kbdreset quirks are not sufficient. It's possible the other LaVie Z models from NEC require this as well. Cc: stable(a)vger.kernel.org Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> --- drivers/input/serio/i8042-x86ia64io.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h index b353d494ad40..136f6e7bf797 100644 --- a/drivers/input/serio/i8042-x86ia64io.h +++ b/drivers/input/serio/i8042-x86ia64io.h @@ -527,6 +527,13 @@ static const struct dmi_system_id __initconst i8042_dmi_nomux_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "N24_25BU"), }, }, + { + /* Lenovo LaVie Z */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo LaVie Z"), + }, + }, { } }; -- 2.18.0

7 years, 1 month

2
1
0 0

[PATCH for-4.9.y 0/5] Stable commits picked up from lede project

by Amit Pundir

Hi Greg, For your consideration, stable commits picked up from lede source tree https://git.lede-project.org/?p=source.git for 4.9.y. Cherry-picked and build tested on Linux v4.9.112. Regards, Amit Pundir Heiner Kallweit (1): mtd: m25p80: consider max message size in m25p80_read Jonas Gorski (4): spi/bcm63xx: make spi subsystem aware of message size limits spi/bcm63xx: fix typo in bcm63xx_spi_max_length breaking compilation bcm63xx_enet: correct clock usage bcm63xx_enet: do not write to random DMA channel on BCM6345 drivers/mtd/devices/m25p80.c | 3 ++- drivers/net/ethernet/broadcom/bcm63xx_enet.c | 34 ++++++++++++++++++++-------- drivers/spi/spi-bcm63xx.c | 9 ++++++++ 3 files changed, 36 insertions(+), 10 deletions(-) -- 2.7.4

7 years, 1 month

3
8
0 0

[PATCH 4.17 0/1] 4.17.8-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.17.8 release. There are 1 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Jul 19 11:47:15 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.17.8-rc1… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.17.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.17.8-rc1 Pavel Tatashin <pasha.tatashin(a)oracle.com> mm: don't do zero_resv_unavail if memmap is not allocated ------------- Diffstat: Makefile | 4 ++-- include/linux/mm.h | 2 +- mm/page_alloc.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-)

7 years, 1 month

3
5
0 0

[PATCH for-4.14.y 0/5] Stable commits picked up from lede project

by Amit Pundir

Hi Greg, For your consideration, stable commits picked up from lede source tree https://git.lede-project.org/?p=source.git for 4.14.y. Cherry-picked and build tested on Linux v4.14.55. Regards, Amit Pundir Christian Lamparter (2): crypto: crypto4xx - remove bad list_del crypto: crypto4xx - fix crypto4xx_build_pdr, crypto4xx_build_sdr leak Jaehoon Chung (1): PCI: exynos: Fix a potential init_clk_resources NULL pointer dereference Jonas Gorski (2): bcm63xx_enet: correct clock usage bcm63xx_enet: do not write to random DMA channel on BCM6345 drivers/crypto/amcc/crypto4xx_core.c | 23 +++++++++---------- drivers/net/ethernet/broadcom/bcm63xx_enet.c | 34 ++++++++++++++++++++-------- drivers/pci/dwc/pci-exynos.c | 3 ++- 3 files changed, 38 insertions(+), 22 deletions(-) -- 2.7.4

7 years, 1 month

3
8
0 0

Please apply 3e4c56d41eef5595035872a2ec5a483f42e8917f ("ocfs2: ip_alloc_sem should be taken in ocfs2_get_block()") to v4.9.y

by Salvatore Bonaccorso

Hi Greg, Please apply 3e4c56d41eef5595035872a2ec5a483f42e8917f ("ocfs2: ip_alloc_sem should be taken in ocfs2_get_block()") to v4.9.y to fix CVE-2017-18224. Regards, Salvatore

7 years, 1 month

2
1
0 0

Please apply 853bc26a7ea39e354b9f8889ae7ad1492ffa28d2 ("ocfs2: subsystem.su_mutex is required while accessing the item->ci_parent") to v4.9.y

by Salvatore Bonaccorso

Hi Greg, Please apply commit 853bc26a7ea39e354b9f8889ae7ad1492ffa28d2 ("ocfs2: subsystem.su_mutex is required while accessing the item->ci_parent") to v4.9.y to address CVE-2017-18216. It has been already applied for instance to 3.16.57 (d9b4d618a22bf30a1c82dffc5c7cb3b1abda48dc) and 3.2.102 (dfd9f20a2db71ca01033040ecf69d5c0e67db629). Regards, Salvatore

7 years, 1 month

2
1
0 0

stable request: 4.4.y: Revert "sit: reload iphdr in ipip6_rcv"

by Dmitry Tunin

Please backport the f4eb17e1efe538d4da7d574bedb00a8dafcc26b7 ("Revert "sit: reload iphdr in ipip6_rcv"") to 4.4.y. It has been applied to 4.9.112 recently, but in 4.4.y the problem still exists. The original commit was CCed to 'stable' but the reversal wasn't. It causes a regression with non-working ping6 and log spam from sit.

7 years, 1 month

2
1
0 0

FAILED: patch "[PATCH] pinctrl: mt7622: fix that pinctrl_claim_hogs cannot work" failed to apply to 4.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.17-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ae6efcae79dd2888243634b69fce51208b650192 Mon Sep 17 00:00:00 2001 From: Sean Wang <sean.wang(a)mediatek.com> Date: Fri, 22 Jun 2018 11:49:06 +0800 Subject: [PATCH] pinctrl: mt7622: fix that pinctrl_claim_hogs cannot work To allow claiming hogs by pinctrl, we cannot enable pinctrl until all groups and functions are being added done. Also, it's necessary that the corresponding gpiochip is being added when the pinctrl device is enabled. Cc: stable(a)vger.kernel.org Fixes: d6ed93551320 ("pinctrl: mediatek: add pinctrl driver for MT7622 SoC") Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7622.c b/drivers/pinctrl/mediatek/pinctrl-mt7622.c index e9eba62da233..42155d4e7f1b 100644 --- a/drivers/pinctrl/mediatek/pinctrl-mt7622.c +++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c @@ -1695,9 +1695,10 @@ static int mtk_pinctrl_probe(struct platform_device *pdev) mtk_desc.custom_conf_items = mtk_conf_items; #endif - hw->pctrl = devm_pinctrl_register(&pdev->dev, &mtk_desc, hw); - if (IS_ERR(hw->pctrl)) - return PTR_ERR(hw->pctrl); + err = devm_pinctrl_register_and_init(&pdev->dev, &mtk_desc, hw, + &hw->pctrl); + if (err) + return err; /* Setup groups descriptions per SoC types */ err = mtk_build_groups(hw); @@ -1713,11 +1714,19 @@ static int mtk_pinctrl_probe(struct platform_device *pdev) return err; } + /* For able to make pinctrl_claim_hogs, we must not enable pinctrl + * until all groups and functions are being added one. + */ + err = pinctrl_enable(hw->pctrl); + if (err) + return err; + err = mtk_build_eint(hw, pdev); if (err) dev_warn(&pdev->dev, "Failed to add EINT, but pinctrl still can work\n"); + /* Build gpiochip should be after pinctrl_enable is done */ err = mtk_build_gpiochip(hw, pdev->dev.of_node); if (err) { dev_err(&pdev->dev, "Failed to add gpio_chip\n");

7 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] pinctrl: mt7622: fix initialization sequence between eint and" failed to apply to 4.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.17-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 8875059d2165f22236e87ed10188b0e18f116b93 Mon Sep 17 00:00:00 2001 From: Sean Wang <sean.wang(a)mediatek.com> Date: Fri, 22 Jun 2018 11:49:05 +0800 Subject: [PATCH] pinctrl: mt7622: fix initialization sequence between eint and gpiochip Because gpichip applied in the driver must depend on mtk eint to implement the input data debouncing and the translation between gpio and irq, it's better to keep logic consistent with mtk eint being built prior to gpiochip being added. Cc: stable(a)vger.kernel.org Fixes: e6dabd38d8e7 ("pinctrl: mediatek: add EINT support to MT7622 SoC") Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7622.c b/drivers/pinctrl/mediatek/pinctrl-mt7622.c index 9ad8cb7730d3..e9eba62da233 100644 --- a/drivers/pinctrl/mediatek/pinctrl-mt7622.c +++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c @@ -1713,17 +1713,17 @@ static int mtk_pinctrl_probe(struct platform_device *pdev) return err; } + err = mtk_build_eint(hw, pdev); + if (err) + dev_warn(&pdev->dev, + "Failed to add EINT, but pinctrl still can work\n"); + err = mtk_build_gpiochip(hw, pdev->dev.of_node); if (err) { dev_err(&pdev->dev, "Failed to add gpio_chip\n"); return err; } - err = mtk_build_eint(hw, pdev); - if (err) - dev_warn(&pdev->dev, - "Failed to add EINT, but pinctrl still can work\n"); - platform_set_drvdata(pdev, hw); return 0;

7 years, 1 month

1
0
0 0

[PATCH Resend 4.4] MIPS: Use async IPIs for arch_trigger_cpumask_backtrace()

by Huacai Chen

From: Paul Burton <paul.burton(a)mips.com> The current MIPS implementation of arch_trigger_cpumask_backtrace() is broken because it attempts to use synchronous IPIs despite the fact that it may be run with interrupts disabled. This means that when arch_trigger_cpumask_backtrace() is invoked, for example by the RCU CPU stall watchdog, we may: - Deadlock due to use of synchronous IPIs with interrupts disabled, causing the CPU that's attempting to generate the backtrace output to hang itself. - Not succeed in generating the desired output from remote CPUs. - Produce warnings about this from smp_call_function_many(), for example: [42760.526910] INFO: rcu_sched detected stalls on CPUs/tasks: [42760.535755] 0-...!: (1 GPs behind) idle=ade/140000000000000/0 softirq=526944/526945 fqs=0 [42760.547874] 1-...!: (0 ticks this GP) idle=e4a/140000000000000/0 softirq=547885/547885 fqs=0 [42760.559869] (detected by 2, t=2162 jiffies, g=266689, c=266688, q=33) [42760.568927] ------------[ cut here ]------------ [42760.576146] WARNING: CPU: 2 PID: 1216 at kernel/smp.c:416 smp_call_function_many+0x88/0x20c [42760.587839] Modules linked in: [42760.593152] CPU: 2 PID: 1216 Comm: sh Not tainted 4.15.4-00373-gee058bb4d0c2 #2 [42760.603767] Stack : 8e09bd20 8e09bd20 8e09bd20 fffffff0 00000007 00000006 00000000 8e09bca8 [42760.616937] 95b2b379 95b2b379 807a0080 00000007 81944518 0000018a 00000032 00000000 [42760.630095] 00000000 00000030 80000000 00000000 806eca74 00000009 8017e2b8 000001a0 [42760.643169] 00000000 00000002 00000000 8e09baa4 00000008 808b8008 86d69080 8e09bca0 [42760.656282] 8e09ad50 805e20aa 00000000 00000000 00000000 8017e2b8 00000009 801070ca [42760.669424] ... [42760.673919] Call Trace: [42760.678672] [<27fde568>] show_stack+0x70/0xf0 [42760.685417] [<84751641>] dump_stack+0xaa/0xd0 [42760.692188] [<699d671c>] __warn+0x80/0x92 [42760.698549] [<68915d41>] warn_slowpath_null+0x28/0x36 [42760.705912] [<f7c76c1c>] smp_call_function_many+0x88/0x20c [42760.713696] [<6bbdfc2a>] arch_trigger_cpumask_backtrace+0x30/0x4a [42760.722216] [<f845bd33>] rcu_dump_cpu_stacks+0x6a/0x98 [42760.729580] [<796e7629>] rcu_check_callbacks+0x672/0x6ac [42760.737476] [<059b3b43>] update_process_times+0x18/0x34 [42760.744981] [<6eb94941>] tick_sched_handle.isra.5+0x26/0x38 [42760.752793] [<478d3d70>] tick_sched_timer+0x1c/0x50 [42760.759882] [<e56ea39f>] __hrtimer_run_queues+0xc6/0x226 [42760.767418] [<e88bbcae>] hrtimer_interrupt+0x88/0x19a [42760.775031] [<6765a19e>] gic_compare_interrupt+0x2e/0x3a [42760.782761] [<0558bf5f>] handle_percpu_devid_irq+0x78/0x168 [42760.790795] [<90c11ba2>] generic_handle_irq+0x1e/0x2c [42760.798117] [<1b6d462c>] gic_handle_local_int+0x38/0x86 [42760.805545] [<b2ada1c7>] gic_irq_dispatch+0xa/0x14 [42760.812534] [<90c11ba2>] generic_handle_irq+0x1e/0x2c [42760.820086] [<c7521934>] do_IRQ+0x16/0x20 [42760.826274] [<9aef3ce6>] plat_irq_dispatch+0x62/0x94 [42760.833458] [<6a94b53c>] except_vec_vi_end+0x70/0x78 [42760.840655] [<22284043>] smp_call_function_many+0x1ba/0x20c [42760.848501] [<54022b58>] smp_call_function+0x1e/0x2c [42760.855693] [<ab9fc705>] flush_tlb_mm+0x2a/0x98 [42760.862730] [<0844cdd0>] tlb_flush_mmu+0x1c/0x44 [42760.869628] [<cb259b74>] arch_tlb_finish_mmu+0x26/0x3e [42760.877021] [<1aeaaf74>] tlb_finish_mmu+0x18/0x66 [42760.883907] [<b3fce717>] exit_mmap+0x76/0xea [42760.890428] [<c4c8a2f6>] mmput+0x80/0x11a [42760.896632] [<a41a08f4>] do_exit+0x1f4/0x80c [42760.903158] [<ee01cef6>] do_group_exit+0x20/0x7e [42760.909990] [<13fa8d54>] __wake_up_parent+0x0/0x1e [42760.917045] [<46cf89d0>] smp_call_function_many+0x1a2/0x20c [42760.924893] [<8c21a93b>] syscall_common+0x14/0x1c [42760.931765] ---[ end trace 02aa09da9dc52a60 ]--- [42760.938342] ------------[ cut here ]------------ [42760.945311] WARNING: CPU: 2 PID: 1216 at kernel/smp.c:291 smp_call_function_single+0xee/0xf8 ... This patch switches MIPS' arch_trigger_cpumask_backtrace() to use async IPIs & smp_call_function_single_async() in order to resolve this problem. We ensure use of the pre-allocated call_single_data_t structures is serialized by maintaining a cpumask indicating that they're busy, and refusing to attempt to send an IPI when a CPU's bit is set in this mask. This should only happen if a CPU hasn't responded to a previous backtrace IPI - ie. if it's hung - and we print a warning to the console in this case. I've marked this for stable branches as far back as v4.9, to which it applies cleanly. Strictly speaking the faulty MIPS implementation can be traced further back to commit 856839b76836 ("MIPS: Add arch_trigger_all_cpu_backtrace() function") in v3.19, but kernel versions v3.19 through v4.8 will require further work to backport due to the rework performed in commit 9a01c3ed5cdb ("nmi_backtrace: add more trigger_*_cpu_backtrace() methods"). Signed-off-by: Paul Burton <paul.burton(a)mips.com> Patchwork: https://patchwork.linux-mips.org/patch/19597/ Cc: James Hogan <jhogan(a)kernel.org> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: stable(a)vger.kernel.org Fixes: 856839b76836 ("MIPS: Add arch_trigger_all_cpu_backtrace() function") Fixes: 9a01c3ed5cdb ("nmi_backtrace: add more trigger_*_cpu_backtrace() methods") [ Huacai: backported to 4.4: Restruction since generic NMI solution is unavailable ] Signed-off-by: Huacai Chen <chenhc(a)lemote.com> --- arch/mips/kernel/process.c | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c index f96048a..354b99f 100644 --- a/arch/mips/kernel/process.c +++ b/arch/mips/kernel/process.c @@ -629,21 +629,48 @@ unsigned long arch_align_stack(unsigned long sp) return sp & ALMASK; } +static DEFINE_PER_CPU(struct call_single_data, backtrace_csd); +static struct cpumask backtrace_csd_busy; + static void arch_dump_stack(void *info) { struct pt_regs *regs; + static arch_spinlock_t lock = __ARCH_SPIN_LOCK_UNLOCKED; + arch_spin_lock(&lock); regs = get_irq_regs(); if (regs) show_regs(regs); else dump_stack(); + arch_spin_unlock(&lock); + + cpumask_clear_cpu(smp_processor_id(), &backtrace_csd_busy); } void arch_trigger_all_cpu_backtrace(bool include_self) { - smp_call_function(arch_dump_stack, NULL, 1); + struct call_single_data *csd; + int cpu; + + for_each_cpu(cpu, cpu_online_mask) { + /* + * If we previously sent an IPI to the target CPU & it hasn't + * cleared its bit in the busy cpumask then it didn't handle + * our previous IPI & it's not safe for us to reuse the + * call_single_data_t. + */ + if (cpumask_test_and_set_cpu(cpu, &backtrace_csd_busy)) { + pr_warn("Unable to send backtrace IPI to CPU%u - perhaps it hung?\n", + cpu); + continue; + } + + csd = &per_cpu(backtrace_csd, cpu); + csd->func = arch_dump_stack; + smp_call_function_single_async(cpu, csd); + } } int mips_get_process_fp_mode(struct task_struct *task) -- 2.7.0

7 years, 1 month

2
3
0 0

[PATCH -stable] pinctrl: sh-pfc: r8a77970: remove SH_PFC_PIN_CFG_DRIVE_STRENGTH flag

by Niklas Söderlund

The datasheet does not document any registers to control drive strength, and no drive strength registers are for this reason described for this SoC. The flags indicating that drive strength can be controlled are however set for some pins in the driver. This leads to a NULL pointer dereference when the sh-pfc core tries to access the struct describing the drive strength registers, for example when reading the sysfs file pinconf-pins. Fix this by removing the SH_PFC_PIN_CFG_DRIVE_STRENGTH from all pins Fixes: b92ac66a1819602b ("pinctrl: sh-pfc: Add R8A77970 PFC support") Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> --- drivers/pinctrl/sh-pfc/pfc-r8a77970.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- Hi, This is a backport of commit 550b6f7e8cf93fc2753aa01e655ed5471012ab5a from Linusw linux-pinctrl.git tree. It's applicable for v4.16 and v4.17. This is my first backport patch submission for stable, please let me know if I can improve the format of this patch commit message or subject in any way. diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77970.c b/drivers/pinctrl/sh-pfc/pfc-r8a77970.c index b1bb7263532b3bf9..049b374aa4ae4698 100644 --- a/drivers/pinctrl/sh-pfc/pfc-r8a77970.c +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77970.c @@ -22,12 +22,12 @@ #include "sh_pfc.h" #define CPU_ALL_PORT(fn, sfx) \ - PORT_GP_CFG_22(0, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \ - PORT_GP_CFG_28(1, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \ - PORT_GP_CFG_17(2, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \ - PORT_GP_CFG_17(3, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \ - PORT_GP_CFG_6(4, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \ - PORT_GP_CFG_15(5, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH) + PORT_GP_22(0, fn, sfx), \ + PORT_GP_28(1, fn, sfx), \ + PORT_GP_17(2, fn, sfx), \ + PORT_GP_17(3, fn, sfx), \ + PORT_GP_6(4, fn, sfx), \ + PORT_GP_15(5, fn, sfx) /* * F_() : just information * FM() : macro for FN_xxx / xxx_MARK -- 2.18.0

7 years, 1 month

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror