4.18.10-stable review
Subsystems (15)
Greg Kroah-Hartman
maintainerPATCH 166/235 sched/core: Use smp_mb() in wake_woken_function()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrea Parri <[email protected]>
[ Upstream commit 76e079fefc8f62bd9b2cd2950814d1ee806e31a5 ]
wake_woken_function() synchronizes with wait_woken() as follows:
[wait_woken] [wake_woken_function]
entry->flags &= ~wq_flag_woken; condition = true;
smp_mb(); smp_wmb();
if (condition) wq_entry->flags |= wq_flag_woken;
break;This commit replaces the above smp_wmb() with an smp_mb() in order to guarantee that either wait_woken() sees the wait condition being true or the store to wq_entry->flags in woken_wake_function() follows the store in wait_woken() in the coherence order (so that the former can eventually be observed by wait_woken()).
The commit also fixes a comment associated to set_current_state() in wait_woken(): the comment pairs the barrier in set_current_state() to the above smp_wmb(), while the actual pairing involves the barrier in set_current_state() and the barrier executed by the try_to_wake_up() in wake_woken_function().
--- kernel/sched/wait.c | 47 +++++++++++++++++++++-------------------------- 1 file changed, 21 insertions(+), 26 deletions(-)
kernel/sched/wait.c +21 -26
@@ -392,35 +392,36 @@ static inline bool is_kthread_should_sto* if (condition) * break; * -* p->state = mode; condition = true; -* smp_mb(); // A smp_wmb(); // C -* if (!wq_entry->flags & WQ_FLAG_WOKEN) wq_entry->flags |= WQ_FLAG_WOKEN; -* schedule() try_to_wake_up(); -* p->state = TASK_RUNNING; ~~~~~~~~~~~~~~~~~~ -* wq_entry->flags &= ~WQ_FLAG_WOKEN; condition = true; -* smp_mb() // B smp_wmb(); // C -* wq_entry->flags |= WQ_FLAG_WOKEN; -* } -* remove_wait_queue(&wq_head, &wait); +* // in wait_woken() // in woken_wake_function() * +* p->state = mode; wq_entry->flags |= WQ_FLAG_WOKEN; +* smp_mb(); // A try_to_wake_up(): +* if (!(wq_entry->flags & WQ_FLAG_WOKEN)) <full barrier> +* schedule() if (p->state & mode) +* p->state = TASK_RUNNING; p->state = TASK_RUNNING; +* wq_entry->flags &= ~WQ_FLAG_WOKEN; ~~~~~~~~~~~~~~~~~~ +* smp_mb(); // B condition = true; +* } smp_mb(); // C +* remove_wait_queue(&wq_head, &wait); wq_entry->flags |= WQ_FLAG_WOKEN; */ long wait_woken (struct wait_queue_entry *wq_entry,unsigned mode,long timeout) { -set_current_state (mode);/* A */ /* -* The above implies an smp_mb(), which matches with the smp_wmb() from -* woken_wake_function() such that if we observe WQ_FLAG_WOKEN we must -* also observe all state before the wakeup. +* The below executes an smp_mb(), which matches with the full barrier +* executed by the try_to_wake_up() in woken_wake_function() such that +* either we see the store to wq_entry->flags in woken_wake_function() +* or woken_wake_function() sees our store to current->state. */ +set_current_state (mode);/* A */ if (!(wq_entry->flags &WQ_FLAG_WOKEN ) && !is_kthread_should_stop ()) timeout =schedule_timeout (timeout);__set_current_state (TASK_RUNNING );/* -* The below implies an smp_mb(), it too pairs with the smp_wmb() from -* woken_wake_function() such that we must either observe the wait -* condition being true _OR_ WQ_FLAG_WOKEN such that we will not miss -* an event. +* The below executes an smp_mb(), which matches with the smp_mb() (C) +* in woken_wake_function() such that either we see the wait condition +* being true or the store to wq_entry->flags in woken_wake_function() +* follows ours in the coherence order. */ smp_store_mb (wq_entry->flags, wq_entry->flags & ~WQ_FLAG_WOKEN );/* B */
@@ -430,14 +431,8 @@ EXPORT_SYMBOL(wait_woken);int woken_wake_function (struct wait_queue_entry *wq_entry,unsigned mode,int sync,void *key) { -/* -* Although this function is called under waitqueue lock, LOCK -* doesn't imply write barrier and the users expects write -* barrier semantics on wakeup functions. The following -* smp_wmb() is equivalent to smp_wmb() in try_to_wake_up() -* and is paired with smp_store_mb() in wait_woken(). -*/ -smp_wmb ();/* C */ +/* Pairs with the smp_store_mb() in wait_woken(). */ +smp_mb ();/* C */ wq_entry->flags |=WQ_FLAG_WOKEN ;return default_wake_function (wq_entry, mode, sync, key);
Greg Kroah-Hartman
maintainerPATCH 167/235 efi/esrt: Only call efi_mem_reserve() for boot services memory
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ard Biesheuvel <[email protected]>
[ Upstream commit 61f0d55569463a1af897117ff47d202b0ccb2e24 ]
The following commit:
7e1550b8f208 ("efi: Drop type and attribute checks in efi_mem_desc_lookup()")
refactored the implementation of efi_mem_desc_lookup() so that the type check is moved to the callers, one of which is the x86 version of efi_arch_mem_reserve(), where we added a modified check that only takes EFI_BOOT_SERVICES_DATA regions into account.
This is reasonable, since it is the only memory type that requires this, but doing so uncovered some unexpected behavior in the ESRT code, which permits the ESRT table to reside in other types of memory than what the UEFI spec mandates (i.e., EFI_BOOT_SERVICES_DATA), and unconditionally calls efi_mem_reserve() on the region in question. This may result in errors such as
esrt: Reserving ESRT space from 0x000000009c810318 to 0x000000009c810350.
efi: Failed to lookup EFI memory descriptor for 0x000000009c810318
when the ESRT table is not in EFI_BOOT_SERVICES_DATA memory, but we try to reserve it nonetheless.
So make the call to efi_mem_reserve() conditional on the memory type.
--- drivers/firmware/efi/esrt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/firmware/efi/esrt.c +2 -1
@@ -326,7 +326,8 @@ void __init efi_esrt_init(void) end = esrt_data + size;pr_info ("Reserving ESRT space from %pa to %pa.\n" , &esrt_data, &end); -efi_mem_reserve (esrt_data, esrt_data_size); +if (md.type ==EFI_BOOT_SERVICES_DATA ) +efi_mem_reserve (esrt_data, esrt_data_size);pr_debug ("esrt-init: loaded.\n" ); }
Greg Kroah-Hartman
maintainerPATCH 168/235 net: hns3: Reset net device with rtnl_lock
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huazhong Tan <[email protected]>
[ Upstream commit 6d4fab39533f1bcd933d82d1667ceea93e4de260 ]
Since current locking was not covering certain code where netdev was being accessed or manipulated, this patch fixes it.
--- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +2 -3
@@ -2825,15 +2825,13 @@ static void hclge_clear_reset_cause(strustatic void hclge_reset (struct hclge_dev *hdev) {/* perform reset of the stack & ae device for a client */ - +rtnl_lock ();hclge_notify_client (hdev,HNAE3_DOWN_CLIENT );if (!hclge_reset_wait (hdev)) { -rtnl_lock ();hclge_notify_client (hdev,HNAE3_UNINIT_CLIENT );hclge_reset_ae_dev (hdev->ae_dev);hclge_notify_client (hdev,HNAE3_INIT_CLIENT ); -rtnl_unlock ();hclge_clear_reset_cause (hdev); }else {
@@ -2843,6 +2841,7 @@ static void hclge_reset(struct hclge_dev }hclge_notify_client (hdev,HNAE3_UP_CLIENT ); +rtnl_unlock (); }static void hclge_reset_event (struct hnae3_handle *handle)
Greg Kroah-Hartman
maintainerPATCH 169/235 net: hns3: Fix for reset_level default assignment probelm
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yunsheng Lin <[email protected]>
[ Upstream commit 82b5321460005ac5d34996e17f5a51a4004a1e14 ]
handle->reset_level is assigned to HNAE3_NONE_RESET when client is initialized, if a tx timeout happens right after initialization, then handle->reset_level is not resetted to HNAE3_FUNC_RESET in hclge_reset_event, which will cause reset event not properly handled problem.
This patch fixes it by setting handle->reset_level properly when client is initialized.
--- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +5 -1
@@ -3081,7 +3081,6 @@ static int hns3_client_init(struct hnae3 priv->dev = &pdev->dev; priv->netdev = netdev; priv->ae_handle = handle; - priv->ae_handle->reset_level =HNAE3_NONE_RESET ; priv->ae_handle->last_reset_time = jiffies; priv->tx_timeout_count =0 ;
@@ -3102,6 +3101,11 @@ static int hns3_client_init(struct hnae3/* Carrier off reporting is important to ethtool even BEFORE open */ netif_carrier_off (netdev); +if (handle->flags &HNAE3_SUPPORT_VF ) + handle->reset_level =HNAE3_VF_RESET ; +else + handle->reset_level =HNAE3_FUNC_RESET ; + ret =hns3_get_ring_config (priv);if (ret) { ret = -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 170/235 ARM: hisi: handle of_iomap and fix missing of_node_put
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Mc Guire <[email protected]>
[ Upstream commit d396cb185c0337aae5664b250cdd9a73f6eb1503 ]
Relying on an unchecked of_iomap() which can return NULL is problematic here, an explicit check seems mandatory. Also the call to of_find_compatible_node() returns a device node with refcount incremented therefor an explicit of_node_put() is needed here.
--- arch/arm/mach-hisi/hotplug.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)
arch/arm/mach-hisi/hotplug.c +13 -6
@@ -148,13 +148,20 @@ static int hi3xxx_hotplug_init(void)struct device_node *node; node =of_find_compatible_node (NULL ,NULL ,"hisilicon,sysctrl" ); -if (node) { - ctrl_base =of_iomap (node,0 ); - id =HI3620_CTRL ; -return 0 ; +if (!node) { + id =ERROR_CTRL ; +return -ENOENT ; } - id =ERROR_CTRL ; -return -ENOENT ; + + ctrl_base =of_iomap (node,0 ); +of_node_put (node); +if (!ctrl_base) { + id =ERROR_CTRL ; +return -ENOMEM ; + } + + id =HI3620_CTRL ; +return 0 ; }void hi3xxx_set_cpu (int cpu,bool enable)
Greg Kroah-Hartman
maintainerPATCH 171/235 ARM: hisi: fix error handling and missing of_node_put
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Mc Guire <[email protected]>
[ Upstream commit 9f30b5ae0585ca5234fe979294b8f897299dec99 ]
of_iomap() can return NULL which seems critical here and thus should be explicitly flagged so that the cause of system halting can be understood. As of_find_compatible_node() is returning a device node with refcount incremented it must be explicitly decremented here.
--- arch/arm/mach-hisi/hotplug.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm/mach-hisi/hotplug.c +4 -4
@@ -226,10 +226,10 @@ void hip01_set_cpu(int cpu, bool enable)if (!ctrl_base) { np =of_find_compatible_node (NULL ,NULL ,"hisilicon,hip01-sysctrl" ); -if (np) - ctrl_base =of_iomap (np,0 ); -else -BUG (); +BUG_ON (!np); + ctrl_base =of_iomap (np,0 ); +of_node_put (np); +BUG_ON (!ctrl_base); }if (enable) {
Greg Kroah-Hartman
maintainerPATCH 172/235 net: hns3: Fix return value error in hns3_reset_notify_down_enet
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huazhong Tan <[email protected]>
[ Upstream commit 6b1385cc251ae9f26b720fa5c8c00bf19af336ae ]
When doing reset, netdev has not been brought up is not an error, it means that we do not need do the stop operation, so just return zero.
--- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +1 -1
@@ -3422,7 +3422,7 @@ static int hns3_reset_notify_down_enet(sstruct net_device *ndev = kinfo->netdev;if (!netif_running (ndev)) -return -EIO ; +return 0 ;return hns3_nic_net_stop (ndev); }
Greg Kroah-Hartman
maintainerPATCH 173/235 ARM: hisi: check of_iomap and fix missing of_node_put
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Mc Guire <[email protected]>
[ Upstream commit 81646a3d39ef14749301374a3a0b8311384cd412 ]
of_find_compatible_node() returns a device node with refcount incremented and thus needs an explicit of_node_put(). Further relying on an unchecked of_iomap() which can return NULL is problematic here, after all ctrl_base is critical enough for hix5hd2_set_cpu() to call BUG() if not available so a check seems mandated here.
0002 Fixes: commit 06cc5c1d4d73 ("ARM: hisi: enable hix5hd2 SoC")
--- arch/arm/mach-hisi/hotplug.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
arch/arm/mach-hisi/hotplug.c +9 -5
@@ -180,11 +180,15 @@ static bool hix5hd2_hotplug_init(void)struct device_node *np; np =of_find_compatible_node (NULL ,NULL ,"hisilicon,cpuctrl" ); -if (np) { - ctrl_base =of_iomap (np,0 ); -return true; - } -return false; +if (!np) +return false; + + ctrl_base =of_iomap (np,0 ); +of_node_put (np); +if (!ctrl_base) +return false; + +return true; }void hix5hd2_set_cpu (int cpu,bool enable)
Greg Kroah-Hartman
maintainerPATCH 174/235 liquidio: fix hang when re-binding VF host drv after running DPDK VF driver
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rick Farrington <[email protected]>
[ Upstream commit ac13d6d8eaded15c67265eafc32f439ea3a0ac4a ]
When configuring SLI_PKTn_OUTPUT_CONTROL, VF driver was assuming that IPTR mode was disabled by reset, which was not true. Since DPDK driver had set IPTR mode previously, the VF driver (which uses buf-ptr-only mode) was not properly handling DROQ packets (i.e. it saw zero-length packets).
This represented an invalid hardware configuration which the driver could not handle.
--- drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c | 3 +++ drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c | 3 +++ 2 files changed, 6 insertions(+)
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c +3 -0
@@ -493,6 +493,9 @@ static void cn23xx_pf_setup_global_outpufor (q_no = srn; q_no < ern; q_no++) { reg_val =octeon_read_csr (oct,CN23XX_SLI_OQ_PKT_CONTROL (q_no)); +/* clear IPTR */ + reg_val &= ~CN23XX_PKT_OUTPUT_CTL_IPTR ; +/* set DPTR */ reg_val |=CN23XX_PKT_OUTPUT_CTL_DPTR ;
drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c +3 -0
@@ -165,6 +165,9 @@ static void cn23xx_vf_setup_global_outpu reg_val =octeon_read_csr (oct,CN23XX_VF_SLI_OQ_PKT_CONTROL (q_no)); +/* clear IPTR */ + reg_val &= ~CN23XX_PKT_OUTPUT_CTL_IPTR ; +/* set DPTR */ reg_val |=CN23XX_PKT_OUTPUT_CTL_DPTR ;
Greg Kroah-Hartman
maintainerPATCH 175/235 gpu: ipu-v3: csi: pass back mbus_code_to_bus_cfg error codes
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Enrico Scholz <[email protected]>
[ Upstream commit d36d0e6309dd8137cf438cbb680e72eb63c81425 ]
mbus_code_to_bus_cfg() can fail on unknown mbus codes; pass back the error to the caller.
--- drivers/gpu/ipu-v3/ipu-csi.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
drivers/gpu/ipu-v3/ipu-csi.c +16 -4
@@ -318,13 +318,17 @@ static int mbus_code_to_bus_cfg(struct i/* * Fill a CSI bus config struct from mbus_config and mbus_framefmt. */ -static void fill_csi_bus_cfg (struct ipu_csi_bus_config *csicfg, +static int fill_csi_bus_cfg (struct ipu_csi_bus_config *csicfg,struct v4l2_mbus_config *mbus_cfg,struct v4l2_mbus_framefmt *mbus_fmt) { +int ret; +memset (csicfg,0 ,sizeof (*csicfg)); -mbus_code_to_bus_cfg (csicfg, mbus_fmt->code); + ret =mbus_code_to_bus_cfg (csicfg, mbus_fmt->code); +if (ret <0 ) +return ret;switch (mbus_cfg->type) {case V4L2_MBUS_PARALLEL :
@@ -356,6 +360,8 @@ static void fill_csi_bus_cfg(struct ipu_/* will never get here, keep compiler quiet */ break ; } + +return 0 ; } int ipu_csi_init_interface(struct ipu_csi *csi,
@@ -365,8 +371,11 @@ int ipu_csi_init_interface(struct ipu_csstruct ipu_csi_bus_config cfg;unsigned long flags;u32 width, height, data =0 ; +int ret; -fill_csi_bus_cfg (&cfg, mbus_cfg, mbus_fmt); + ret =fill_csi_bus_cfg (&cfg, mbus_cfg, mbus_fmt); +if (ret <0 ) +return ret;/* set default sensor frame width and height */ width = mbus_fmt->width;
@@ -587,11 +596,14 @@ int ipu_csi_set_mipi_datatype(struct ipustruct ipu_csi_bus_config cfg;unsigned long flags;u32 temp; +int ret;if (vc >3 )return -EINVAL ; -mbus_code_to_bus_cfg (&cfg, mbus_fmt->code); + ret =mbus_code_to_bus_cfg (&cfg, mbus_fmt->code); +if (ret <0 ) +return ret;spin_lock_irqsave (&csi->lock, flags);
Greg Kroah-Hartman
maintainerPATCH 176/235 ASoC: hdmi-codec: fix routing
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
[ Upstream commit d30e23d69981a4b665f5ce8711335df986576389 ]
Commit 943fa0228252 ("ASoC: hdmi-codec: Use different name for playback streams") broke hdmi-codec's routing between it's output "TX" widget and the S/PDIF or I2S streams by renaming the streams.
Whether an error occurs or not is dependent on whether there is another widget called "Playback" registered by some other component - if there is, that widget will be (incorrectly) bound to the HDMI codec's "TX" output widget. If we end up connecting "TX" incorrectly, it can result in components not being started, causing no audio output.
Since the I2S and S/PDIF streams now have different names, we can't use a static route at component level to describe the relationship, so arrange to dynamically create the route when the DAI driver is probed.
--- sound/soc/codecs/hdmi-codec.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
sound/soc/codecs/hdmi-codec.c +15 -6
@@ -291,10 +291,6 @@ static const struct snd_soc_dapm_widget SND_SOC_DAPM_OUTPUT("TX"), }; -static const struct snd_soc_dapm_route hdmi_routes[] = { - {"TX" ,NULL ,"Playback" }, -}; -enum {DAI_ID_I2S =0 ,DAI_ID_SPDIF ,
@@ -689,9 +685,23 @@ static int hdmi_codec_pcm_new(struct sndreturn snd_ctl_add (rtd->card->snd_card, kctl); } +static int hdmi_dai_probe (struct snd_soc_dai *dai) +{ +struct snd_soc_dapm_context *dapm; +struct snd_soc_dapm_route route = { + .sink ="TX" , + .source = dai->driver->playback.stream_name, + }; + + dapm =snd_soc_component_get_dapm (dai->component); + +return snd_soc_dapm_add_routes (dapm, &route,1 ); +} +static const struct snd_soc_dai_driver hdmi_i2s_dai = { .name ="i2s-hifi" , .id =DAI_ID_I2S , + .probe = hdmi_dai_probe, .playback = { .stream_name ="I2S Playback" , .channels_min =2 ,
@@ -707,6 +717,7 @@ static const struct snd_soc_dai_driver hstatic const struct snd_soc_dai_driver hdmi_spdif_dai = { .name ="spdif-hifi" , .id =DAI_ID_SPDIF , + .probe = hdmi_dai_probe, .playback = { .stream_name ="SPDIF Playback" , .channels_min =2 ,
@@ -733,8 +744,6 @@ static int hdmi_of_xlate_dai_id(struct sstatic const struct snd_soc_component_driver hdmi_driver = { .dapm_widgets = hdmi_widgets, .num_dapm_widgets =ARRAY_SIZE (hdmi_widgets), - .dapm_routes = hdmi_routes, - .num_dapm_routes =ARRAY_SIZE (hdmi_routes), .of_xlate_dai_id = hdmi_of_xlate_dai_id, .idle_bias_on =1 , .use_pmdown_time =1 ,
Greg Kroah-Hartman
maintainerPATCH 177/235 gpiolib: dont allow userspace to set values of input lines
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
[ Upstream commit e5332d5437764f775cf4e3b8ca3bf592af063a02 ]
User space can currently both read and set values of input lines using the character device. This was not allowed by the old sysfs interface nor is it a correct behavior.
Check the first descriptor in the set for the OUT flag when asked to set values and return -EPERM if the line is input.
--- drivers/gpio/gpiolib.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/gpio/gpiolib.c +7 -1
@@ -449,7 +449,13 @@ static long linehandle_ioctl(struct filereturn 0 ; }else if (cmd ==GPIOHANDLE_SET_LINE_VALUES_IOCTL ) { -/* TODO: check if descriptors are really output */ +/* +* All line descriptors were created at once with the same +* flags so just check if the first one is really output. +*/ +if (!test_bit (FLAG_IS_OUT , &lh->descs[0 ]->flags)) +return -EPERM ; +if (copy_from_user (&ghd, ip,sizeof (ghd)))return -EFAULT ;
Re: [PATCH 4.18 177/235] gpiolib: dont allow userspace to set values of input lines
pon., 24 wrz 2018 o 14:41 Greg Kroah-Hartman
<[email protected]> napisał(a):
Quoted 33 lines
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
[ Upstream commit
e5332d5437764f775cf4e3b8ca3bf592af063a02]User space can currently both read and set values of input lines using the character device. This was not allowed by the old sysfs interface nor is it a correct behavior.
Check the first descriptor in the set for the OUT flag when asked to set values and return
-EPERMif the line is input.Signed-off-by Bartosz Golaszewski <[email protected]>Signed-off-by Linus Walleij <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/gpio/gpiolib.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)drivers/gpio/gpiolib.c +0
-1@@ -449,7 +449,13 @@ static long linehandle_ioctl(struct filereturn 0 ; }else if (cmd ==GPIOHANDLE_SET_LINE_VALUES_IOCTL ) { -/* TODO: check if descriptors are really output */
drivers/gpio/gpiolib.c static long linehandle_ioctl(struct file · line 461
Quoted 10 lines
drivers/gpio/gpiolib.c +7
-0+/* +* All line descriptors were created at once with the same +* flags so just check if the first one is really output. +*/ +if (!test_bit (FLAG_IS_OUT , &lh->descs[0 ]->flags)) +return -EPERM ; +if (copy_from_user (&ghd, ip,sizeof (ghd)))return -EFAULT ;
Hi Greg,
FYI Linus suggested that we don't send this one for stable:
https://lkml.org/lkml/2018/7/20/1065
Best regards,
Bartosz Golaszewski
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 177/235] gpiolib: dont allow userspace to set values of input lines
Quoted 48 lines · Bartosz Golaszewski
pon., 24 wrz 2018 o 14:41 Greg Kroah-Hartman
<[email protected]> napisał(a):Quoted 33 lines
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
[ Upstream commit
e5332d5437764f775cf4e3b8ca3bf592af063a02]User space can currently both read and set values of input lines using the character device. This was not allowed by the old sysfs interface nor is it a correct behavior.
Check the first descriptor in the set for the OUT flag when asked to set values and return
-EPERMif the line is input.Signed-off-by Bartosz Golaszewski <[email protected]>Signed-off-by Linus Walleij <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/gpio/gpiolib.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)drivers/gpio/gpiolib.c +0
-1@@ -449,7 +449,13 @@ static long linehandle_ioctl(struct filereturn 0 ; }else if (cmd ==GPIOHANDLE_SET_LINE_VALUES_IOCTL ) { -/* TODO: check if descriptors are really output */ drivers/gpio/gpiolib.c static long linehandle_ioctl(struct file · line 461
Quoted 10 lines
drivers/gpio/gpiolib.c +7
-0+/* +* All line descriptors were created at once with the same +* flags so just check if the first one is really output. +*/ +if (!test_bit (FLAG_IS_OUT , &lh->descs[0 ]->flags)) +return -EPERM ; +if (copy_from_user (&ghd, ip,sizeof (ghd)))return -EFAULT ;Hi Greg,
Quoted 2 lines
FYI Linus suggested that we don't send this one for stable:
https://lkml.org/lkml/2018/7/20/1065
Ok, that was hard to dig out. This was sent as review last week. I'll go drop it, thanks for letting me know.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 178/235 serial: 8250: of: Correct of_platform_serial_setup() error handling
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Sverdlin <[email protected]>
[ Upstream commit b29330d829042512fabb2bfa3bbfa32df1115594 ]
Don't dispose IRQ mapping before it has been created.
--- drivers/tty/serial/8250/8250_of.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/8250/8250_of.c +1 -1
@@ -124,7 +124,7 @@ static int of_platform_serial_setup(strudev_warn (&ofdev->dev,"unsupported reg-io-width (%d)\n" , prop); ret = -EINVAL ; - goto err_dispose; + goto err_unprepare; } } port->flags |=UPF_IOREMAP ;
Greg Kroah-Hartman
maintainerPATCH 179/235 tty: fix termios input-speed encoding when using BOTHER
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
[ Upstream commit 1cee38f0363a88db374e50b232ca17b9a4c12fa0 ]
When the termios CIBAUD bits are left unset (i.e. B0), we use the same output and input speed and should leave CIBAUD unchanged.
When the user requests a rate using BOTHER and c_ospeed which the driver cannot set exactly, the driver can report back the actual baud rate using tty_termios_encode_baud_rate(). If this rate is close enough to a standard rate however, we could end up setting CIBAUD to a Bfoo value despite the user having left it unset.
This in turn could lead to an unexpected input rate being set on subsequent termios updates.
Fix this by using a zero tolerance value also for the input rate when CIBAUD is clear so that the matching logic works as expected.
--- drivers/tty/tty_baudrate.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/tty/tty_baudrate.c +7 -3
@@ -157,16 +157,20 @@ void tty_termios_encode_baud_rate(struct termios->c_ospeed = obaud;#ifdef BOTHER +if ((termios->c_cflag >>IBSHIFT ) &CBAUD ) + ibinput =1 ;/* An input speed was specified */ +/* If the user asked for a precise weird speed give a precise weird answer. If they asked for a Bfoo speed they may have problems digesting non-exact replies so fuzz a bit */ -if ((termios->c_cflag &CBAUD ) ==BOTHER ) +if ((termios->c_cflag &CBAUD ) ==BOTHER ) { oclose =0 ; +if (!ibinput) + iclose =0 ; + }if (((termios->c_cflag >>IBSHIFT ) &CBAUD ) ==BOTHER ) iclose =0 ; -if ((termios->c_cflag >>IBSHIFT ) &CBAUD ) - ibinput =1 ;/* An input speed was specified */ #endif termios->c_cflag &= ~CBAUD ;
Greg Kroah-Hartman
maintainerPATCH 180/235 tty: fix termios input-speed encoding
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
[ Upstream commit fada18c48d774b9e837928ecdce6a5d5fdd11ee7 ]
Make sure to clear the CIBAUD bits before OR-ing the new mask when encoding the termios input baud rate.
This could otherwise lead to an incorrect input rate being reported back and incidentally set on subsequent termios updates.
--- drivers/tty/tty_baudrate.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/tty/tty_baudrate.c +3 -0
@@ -173,6 +173,9 @@ void tty_termios_encode_baud_rate(struct iclose =0 ;#endif termios->c_cflag &= ~CBAUD ; +#ifdef IBSHIFT + termios->c_cflag &= ~(CBAUD <<IBSHIFT ); +#endif /* * Our goal is to find a close match to the standard baud rate
Greg Kroah-Hartman
maintainerPATCH 181/235 mmc: sdhci-of-esdhc: set proper dma mask for ls104x chips
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurentiu Tudor <[email protected]>
[ Upstream commit 5552d7ad596c3fea953f40fef74170ce0760c04d ]
SDHCI controller in ls1043a and ls1046a generate 40-bit wide addresses when doing DMA. Make sure that the corresponding dma mask is correctly configured.
Context: when enabling smmu on these chips the following problem is
encountered: the smmu input address size is 48 bits so the dma mappings for sdhci end up 48-bit wide. However, on these chips sdhci only use 40-bits of that address size when doing dma.
So you end up with a 48-bit address translation in smmu but the device generates transactions with clipped 40-bit addresses, thus smmu context faults are triggered. Setting up the correct dma mask fixes this situation.
--- drivers/mmc/host/sdhci-of-esdhc.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/mmc/host/sdhci-of-esdhc.c +6 -0
@@ -22,6 +22,7 @@#include <linux/sys_soc.h> #include <linux/clk.h> #include <linux/ktime.h> +#include <linux/dma-mapping.h> #include <linux/mmc/host.h> #include "sdhci-pltfm.h" #include "sdhci-esdhc.h"
@@ -427,6 +428,11 @@ static void esdhc_of_adma_workaround(strstatic int esdhc_of_enable_dma (struct sdhci_host *host) {u32 value; +struct device *dev =mmc_dev (host->mmc); + +if (of_device_is_compatible (dev->of_node,"fsl,ls1043a-esdhc" ) || +of_device_is_compatible (dev->of_node,"fsl,ls1046a-esdhc" )) +dma_set_mask_and_coherent (dev,DMA_BIT_MASK (40 )); value =sdhci_readl (host,ESDHC_DMA_SYSCTL ); value |=ESDHC_DMA_SNOOP ;
Greg Kroah-Hartman
maintainerPATCH 182/235 mmc: tegra: prevent HS200 on Tegra 3
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Agner <[email protected]>
[ Upstream commit 127407e36f4fe3a1d5e8b9998b479956ce83a7dc ]
The stack assumes that SDHC controller which support SD3.0 (SDR104) do support HS200. This is not the case for Tegra 3, which does support SD 3.0
but only supports eMMC spec 4.41.
Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not support HS200.
Note that commit 156e14b126ff ("mmc: sdhci: fix caps2 for HS200") added the tie between SD3.0 (SDR104) and HS200. I don't think that this is necessarly true. It is fully legitimate to support SD3.0 and not support HS200. The quirk naming suggests something is broken in the controller, but this is not the case: The controller simply does not support HS200.
--- drivers/mmc/host/sdhci-tegra.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/mmc/host/sdhci-tegra.c +2 -1
@@ -334,7 +334,8 @@ static const struct sdhci_pltfm_data sdhSDHCI_QUIRK_NO_HISPD_BIT |SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC | SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN, - .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN, + .quirks2 =SDHCI_QUIRK2_PRESET_VALUE_BROKEN | + SDHCI_QUIRK2_BROKEN_HS200, .ops = &tegra_sdhci_ops, };
Greg Kroah-Hartman
maintainerPATCH 183/235 mmc: sdhci: do not try to use 3.3V signaling if not supported
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Agner <[email protected]>
[ Upstream commit 1b5190c2e74c47ebe4bcecf7a072358ad9f1feaa ]
For eMMC devices it is valid to only support 1.8V signaling. When vqmmc is set to a fixed 1.8V regulator the stack tries to set 3.3V initially and prints the following warning:
mmc1: Switching to 3.3V signalling voltage failed
Clear the MMC_SIGNAL_VOLTAGE_330 flag in case 3.3V is signaling is not available. This prevents the stack from even trying to use 3.3V signaling and avoids the above warning.
--- drivers/mmc/host/sdhci.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/mmc/host/sdhci.c +8 -1
@@ -3734,14 +3734,21 @@ int sdhci_setup_host(struct sdhci_host * mmc_gpio_get_cd(host->mmc) < 0) mmc->caps |=MMC_CAP_NEEDS_POLL ; -/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */ if (!IS_ERR (mmc->supply.vqmmc)) { ret =regulator_enable (mmc->supply.vqmmc); + +/* If vqmmc provides no 1.8V signalling, then there's no UHS */ if (!regulator_is_supported_voltage (mmc->supply.vqmmc,1700000 ,1950000 )) host->caps1 &= ~(SDHCI_SUPPORT_SDR104 |SDHCI_SUPPORT_SDR50 |SDHCI_SUPPORT_DDR50 ); + +/* In eMMC case vqmmc might be a fixed 1.8V regulator */ +if (!regulator_is_supported_voltage (mmc->supply.vqmmc,2700000 , +3600000 )) + host->flags &= ~SDHCI_SIGNALING_330 ; +if (ret) {pr_warn ("%s: Failed to enable vqmmc regulator: %d\n" ,mmc_hostname (mmc), ret);
Greg Kroah-Hartman
maintainerPATCH 184/235 drm/nouveau: Fix runtime PM leak in drm_open()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude Paul <[email protected]>
[ Upstream commit 922a8c82fafdec99688bbaea6c5889f562a42cdc ]
Noticed this as I was skimming through, if we fail to allocate memory for cli we'll end up returning without dropping the runtime PM ref we got. Additionally, we'll even return the wrong return code! (ret most likely will == 0 here, we want -ENOMEM).
--- drivers/gpu/drm/nouveau/nouveau_drm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nouveau_drm.c +4 -2
@@ -908,8 +908,10 @@ nouveau_drm_open(struct drm_device *dev,get_task_comm (tmpname, current);snprintf (name,sizeof (name),"%s[%d]" , tmpname,pid_nr (fpriv->pid)); -if (!(cli =kzalloc (sizeof (*cli),GFP_KERNEL ))) -return ret; +if (!(cli =kzalloc (sizeof (*cli),GFP_KERNEL ))) { + ret = -ENOMEM ; + goto done; + } ret =nouveau_cli_init (drm, name, cli);if (ret)
Greg Kroah-Hartman
maintainerPATCH 185/235 drm/nouveau/debugfs: Wake up GPU before doing any reclocking
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karol Herbst <[email protected]>
[ Upstream commit eaeb9010bb4bcdc20e58254fa42f3fe730a7f908 ]
Fixes various reclocking related issues on prime systems.
--- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/nouveau/nouveau_debugfs.c +4 -0
@@ -160,7 +160,11 @@ nouveau_debugfs_pstate_set(struct file * args.ustate = value; } + ret =pm_runtime_get_sync (drm->dev); +if (IS_ERR_VALUE (ret) && ret != -EACCES ) +return ret; ret =nvif_mthd (ctrl,NVIF_CONTROL_PSTATE_USER , &args,sizeof (args)); +pm_runtime_put_autosuspend (drm->dev);if (ret <0 )return ret;
Greg Kroah-Hartman
maintainerPATCH 186/235 drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thierry Reding <[email protected]>
[ Upstream commit b59fb482b52269977ee5de205308e5b236a03917 ]
Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the memory controller). Transparently backing DMA memory with an IOMMU prevents Nouveau from properly handling such memory accesses and causes memory access faults.
As a side-note: buffers other than those allocated in instance memory don't need to be physically contiguous from the GPU's perspective since the GPU can map them into contiguous buffers using its own MMU. Mapping these buffers through the IOMMU is unnecessary and will even lead to performance degradation because of the additional translation. One exception to this are compressible buffers which need large pages. In order to enable these large pages, multiple small pages will have to be combined into one large (I/O virtually contiguous) mapping via the IOMMU. However, that is a topic outside the scope of this fix and isn't currently supported. An implementation will want to explicitly create these large pages in the Nouveau driver, so detaching from a DMA/IOMMU mapping would still be required.
--- drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c +13 -0
@@ -23,6 +23,10 @@#ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER #include "priv.h" +#if IS_ENABLED (CONFIG_ARM_DMA_USE_IOMMU ) +#include <asm/dma-iommu.h> +#endif +static int nvkm_device_tegra_power_up (struct nvkm_device_tegra *tdev) {
@@ -105,6 +109,15 @@ nvkm_device_tegra_probe_iommu(struct nvkunsigned long pgsize_bitmap;int ret; +#if IS_ENABLED (CONFIG_ARM_DMA_USE_IOMMU ) +if (dev->archdata.mapping) { +struct dma_iommu_mapping *mapping =to_dma_iommu_mapping (dev); + +arm_iommu_detach_device (dev); +arm_iommu_release_mapping (mapping); + } +#endif +if (!tdev->func->iommu_bit)return ;
Greg Kroah-Hartman
maintainerPATCH 187/235 tls: Fix zerocopy_from_iter iov handling
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Pismenny <[email protected]>
[ Upstream commit 4718799817c5a30ae723eda21f3a6c7d8701b1a4 ]
zerocopy_from_iter iterates over the message, but it doesn't revert the updates made by the iov iteration. This patch fixes it. Now, the iov can be used after calling zerocopy_from_iter.
--- net/tls/tls_sw.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
net/tls/tls_sw.c +5 -3
@@ -286,7 +286,7 @@ static int zerocopy_from_iter(struct soc int length, int *pages_used, unsigned int *size_used, struct scatterlist *to, int to_max_pages, - bool charge) + bool charge, bool revert) { struct page *pages[MAX_SKB_FRAGS];
@@ -337,6 +337,8 @@ static int zerocopy_from_iter(struct soc out: *size_used = size; *pages_used = num_elem; +if (revert) +iov_iter_revert (from, size);return rc; }
@@ -438,7 +440,7 @@ alloc_encrypted: &ctx->sg_plaintext_size, ctx->sg_plaintext_data,ARRAY_SIZE (ctx->sg_plaintext_data), - true); + true, false);if (ret) goto fallback_to_reg_send;
@@ -826,7 +828,7 @@ int tls_sw_recvmsg(struct sock *sk, err =zerocopy_from_iter (sk, &msg->msg_iter, to_copy, &pages, &chunk, &sgin[1 ], -MAX_SKB_FRAGS , false); +MAX_SKB_FRAGS , false, true);if (err <0 ) goto fallback_to_reg_recv;
Greg Kroah-Hartman
maintainerPATCH 188/235 parport: sunbpp: fix error return code
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julia Lawall <[email protected]>
[ Upstream commit faa1a47388b33623e4d504c23569188907b039a0 ]
Return an error code on failure. Change leading spaces to tab on the first if.
Problem found using Coccinelle.
--- drivers/parport/parport_sunbpp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/parport/parport_sunbpp.c +6 -2
@@ -286,12 +286,16 @@ static int bpp_probe(struct platform_dev ops =kmemdup (&parport_sunbpp_ops,sizeof (struct parport_operations ),GFP_KERNEL ); -if (!ops) +if (!ops) { + err = -ENOMEM ; goto out_unmap; + }dprintk (("register_port\n" )); -if (!(p =parport_register_port ((unsigned long )base, irq, dma, ops))) +if (!(p =parport_register_port ((unsigned long )base, irq, dma, ops))) { + err = -ENOMEM ; goto out_free_ops; + } p->size = size; p->dev = &op->dev;
Greg Kroah-Hartman
maintainerPATCH 189/235 sched/fair: Fix util_avg of new tasks for asymmetric systems
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quentin Perret <[email protected]>
[ Upstream commit 8fe5c5a937d0f4e84221631833a2718afde52285 ]
When a new task wakes-up for the first time, its initial utilization is set to half of the spare capacity of its CPU. The current implementation of post_init_entity_util_avg() uses SCHED_CAPACITY_SCALE directly as a capacity reference. As a result, on a big.LITTLE system, a new task waking up on an idle little CPU will be given ~512 of util_avg, even if the CPU's capacity is significantly less than that.
Fix this by computing the spare capacity with arch_scale_cpu_capacity().
--- kernel/sched/fair.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
kernel/sched/fair.c +6 -4
@@ -735,11 +735,12 @@ static void attach_entity_cfs_rq(struct* To solve this problem, we also cap the util_avg of successive tasks to * only 1/2 of the left utilization budget: * -* util_avg_cap = (1024 - cfs_rq->avg.util_avg) / 2^n +* util_avg_cap = (cpu_scale - cfs_rq->avg.util_avg) / 2^n * -* where n denotes the nth task. +* where n denotes the nth task and cpu_scale the CPU capacity. * -* For example, a simplest series from the beginning would be like: +* For example, for a CPU with 1024 of capacity, a simplest series from +* the beginning would be like: * * task util_avg: 512, 256, 128, 64, 32, 16, 8, ... * cfs_rq util_avg: 512, 768, 896, 960, 992, 1008, 1016, ...
@@ -751,7 +752,8 @@ void post_init_entity_util_avg(struct sc {struct cfs_rq *cfs_rq =cfs_rq_of (se);struct sched_avg *sa = &se->avg; -long cap = (long )(SCHED_CAPACITY_SCALE - cfs_rq->avg.util_avg) /2 ; +long cpu_scale =arch_scale_cpu_capacity (NULL ,cpu_of (rq_of (cfs_rq))); +long cap = (long )(cpu_scale - cfs_rq->avg.util_avg) /2 ;if (cap >0 ) {if (cfs_rq->avg.util_avg !=0 ) {
Greg Kroah-Hartman
maintainerPATCH 190/235 coresight: Handle errors in finding input/output ports
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Suzuki K Poulose <[email protected]>
[ Upstream commit fe470f5f7f684ed15bc49b6183a64237547910ff ]
If we fail to find the input / output port for a LINK component while enabling a path, we should fail gracefully rather than assuming port "0".
--- drivers/hwtracing/coresight/coresight.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/hwtracing/coresight/coresight.c +5 -2
@@ -108,7 +108,7 @@ static int coresight_find_link_inport(stdev_err (&csdev->dev,"couldn't find inport, parent: %s, child: %s\n" ,dev_name (&parent->dev),dev_name (&csdev->dev)); -return 0 ; +return -ENODEV ; } static int coresight_find_link_outport(struct coresight_device *csdev,
@@ -126,7 +126,7 @@ static int coresight_find_link_outport(sdev_err (&csdev->dev,"couldn't find outport, parent: %s, child: %s\n" ,dev_name (&csdev->dev),dev_name (&child->dev)); -return 0 ; +return -ENODEV ; }static int coresight_enable_sink (struct coresight_device *csdev,u32 mode)
@@ -179,6 +179,9 @@ static int coresight_enable_link(structelse refport =0 ; +if (refport <0 ) +return refport; +if (atomic_inc_return (&csdev->refcnt[refport]) ==1 ) {if (link_ops (csdev)->enable) { ret =link_ops (csdev)->enable (csdev, inport, outport);
Greg Kroah-Hartman
maintainerPATCH 191/235 coresight: tpiu: Fix disabling timeouts
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robin Murphy <[email protected]>
[ Upstream commit ccff2dfaceaca4517432f5c149594215fe9098cc ]
Probing the TPIU driver under UBSan triggers an out-of-bounds shift warning in coresight_timeout():
...
[ 5.677530] UBSAN: Undefined behaviour in drivers/hwtracing/coresight/coresight.c:929:16 [ 5.685542] shift exponent 64 is too large for 64-bit type 'long unsigned int'
...
On closer inspection things are exponentially out of whack because we're passing a bitmask where a bit number should be. Amusingly, it seems that both calls will find their expected values by sheer luck and appear to
succeed: 1 << FFCR_FON_MAN ends up at bit 64 which whilst undefined evaluates as zero in practice, while 1 << FFSR_FT_STOPPED finds bit 2 (TCPresent) which apparently is usually tied high.
Following the examples of other drivers, define separate FOO and FOO_BIT macros for masks vs. indices, and put things right.
--- drivers/hwtracing/coresight/coresight-tpiu.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/hwtracing/coresight/coresight-tpiu.c +4 -3
@@ -40,8 +40,9 @@/** register definition **/ /* FFSR - 0x300 */ -#define FFSR_FT_STOPPED BIT(1) +#define FFSR_FT_STOPPED_BIT 1/* FFCR - 0x304 */ +#define FFCR_FON_MAN_BIT 6#define FFCR_FON_MAN BIT(6)#define FFCR_STOP_FI BIT(12)
@@ -86,9 +87,9 @@ static void tpiu_disable_hw(struct tpiu_/* Generate manual flush */ writel_relaxed (FFCR_STOP_FI |FFCR_FON_MAN , drvdata->base +TPIU_FFCR );/* Wait for flush to complete */ -coresight_timeout (drvdata->base,TPIU_FFCR ,FFCR_FON_MAN ,0 ); +coresight_timeout (drvdata->base,TPIU_FFCR ,FFCR_FON_MAN_BIT ,0 );/* Wait for formatter to stop */ -coresight_timeout (drvdata->base,TPIU_FFSR ,FFSR_FT_STOPPED ,1 ); +coresight_timeout (drvdata->base,TPIU_FFSR ,FFSR_FT_STOPPED_BIT ,1 );CS_LOCK (drvdata->base); }
Greg Kroah-Hartman
maintainerPATCH 192/235 coresight: ETM: Add support for Arm Cortex-A73 and Cortex-A35
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Suzuki K Poulose <[email protected]>
[ Upstream commit 5cedd22370a0a460b663c06de1fc10b4ba3c5d0b ]
Add ETM PIDs of the Arm cortex-A CPUs to the white list of ETMs. While at it add a helper macro to make it easier to add the new entries.
--- drivers/hwtracing/coresight/coresight-etm4x.c | 31 +++++++++++--------------- 1 file changed, 14 insertions(+), 17 deletions(-)
drivers/hwtracing/coresight/coresight-etm4x.c +14 -17
@@ -1027,7 +1027,8 @@ static int etm4_probe(struct amba_device }pm_runtime_put (&adev->dev); -dev_info (dev,"%s initialized\n" , (char *)id->data); +dev_info (dev,"CPU%d: ETM v%d.%d initialized\n" , + drvdata->cpu, drvdata->arch >>4 , drvdata->arch &0xf );if (boot_enable) {coresight_enable (drvdata->csdev);
@@ -1045,23 +1046,19 @@ err_arch_supported:return ret; } +#define ETM4x_AMBA_ID (pid) \ + { \ + .id = pid, \ + .mask = 0x000fffff, \ + } +static const struct amba_id etm4_ids[] = { - {/* ETM 4.0 - Cortex-A53 */ - .id =0x000bb95d , - .mask =0x000fffff , - .data ="ETM 4.0" , - }, - {/* ETM 4.0 - Cortex-A57 */ - .id =0x000bb95e , - .mask =0x000fffff , - .data ="ETM 4.0" , - }, - {/* ETM 4.0 - A72, Maia, HiSilicon */ - .id =0x000bb95a , - .mask =0x000fffff , - .data ="ETM 4.0" , - }, - {0 ,0 }, +ETM4x_AMBA_ID (0x000bb95d ),/* Cortex-A53 */ +ETM4x_AMBA_ID (0x000bb95e ),/* Cortex-A57 */ +ETM4x_AMBA_ID (0x000bb95a ),/* Cortex-A72 */ +ETM4x_AMBA_ID (0x000bb959 ),/* Cortex-A73 */ +ETM4x_AMBA_ID (0x000bb9da ),/* Cortex-A35 */ + {}, };static struct amba_driver etm4x_driver = {
Greg Kroah-Hartman
maintainerPATCH 193/235 f2fs: do checkpoint in kill_sb
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jaegeuk Kim <[email protected]>
[ Upstream commit 1cb50f87e10696e8cc61fb62d0d948e11b0e6dc1 ]
When unmounting f2fs in force mode, we can get it stuck by io_schedule() by some pending IOs in meta_inode.
io_schedule+0xd/0x30 wait_on_page_bit_common+0xc6/0x130 __filemap_fdatawait_range+0xbd/0x100 filemap_fdatawait_keep_errors+0x15/0x40 sync_inodes_sb+0x1cf/0x240 sync_filesystem+0x52/0x90 generic_shutdown_super+0x1d/0x110 kill_f2fs_super+0x28/0x80 [f2fs] deactivate_locked_super+0x35/0x60 cleanup_mnt+0x36/0x70 task_work_run+0x79/0xa0 exit_to_usermode_loop+0x62/0x70 do_syscall_64+0xdb/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
0xffffffffffffffff
--- fs/f2fs/super.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
fs/f2fs/super.c +13 -3
@@ -3106,9 +3106,19 @@ static struct dentry *f2fs_mount(structstatic void kill_f2fs_super (struct super_block *sb) {if (sb->s_root) { -set_sbi_flag (F2FS_SB (sb),SBI_IS_CLOSE ); -f2fs_stop_gc_thread (F2FS_SB (sb)); -f2fs_stop_discard_thread (F2FS_SB (sb)); +struct f2fs_sb_info *sbi =F2FS_SB (sb); + +set_sbi_flag (sbi,SBI_IS_CLOSE ); +f2fs_stop_gc_thread (sbi); +f2fs_stop_discard_thread (sbi); + +if (is_sbi_flag_set (sbi,SBI_IS_DIRTY ) || + !is_set_ckpt_flags (sbi,CP_UMOUNT_FLAG )) { +struct cp_control cpc = { + .reason =CP_UMOUNT , + }; +f2fs_write_checkpoint (sbi, &cpc); + } }kill_block_super (sb); }
Greg Kroah-Hartman
maintainerPATCH 194/235 tools/testing/nvdimm: Fix support for emulating controller temperature
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
[ Upstream commit e5d772fbe7685aae0dff99f3b54158a0ec32155e ]
In addition to populating the value the payload also needs to set the "controller temperature valid" flag.
--- tools/testing/nvdimm/test/nfit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
tools/testing/nvdimm/test/nfit.c +2 -1
@@ -1308,7 +1308,8 @@ static void smart_init(struct nfit_test | ND_INTEL_SMART_ALARM_VALID |ND_INTEL_SMART_USED_VALID |ND_INTEL_SMART_SHUTDOWN_VALID - | ND_INTEL_SMART_MTEMP_VALID, + |ND_INTEL_SMART_MTEMP_VALID + | ND_INTEL_SMART_CTEMP_VALID, .health = ND_INTEL_SMART_NON_CRITICAL_HEALTH, .media_temperature = 23 * 16, .ctrl_temperature = 25 * 16,
Greg Kroah-Hartman
maintainerPATCH 195/235 drm/amd/display: support access ddc for mst branch
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Yang <[email protected]>
[ Upstream commit 0a14544661fad1606cc96aece30b2950fd9c4c81 ]
[Why]
Megachip dockings accesses ddc line through display driver when installing FW. Previously, we would fail every transaction because link attached to mst branch did not have their ddc transaction type set.
[How]
Set ddc transaction type when mst branch is connected.
--- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/amd/display/dc/core/dc_link.c +4 -0
@@ -497,6 +497,10 @@ static bool detect_dp( sink_caps->signal =SIGNAL_TYPE_DISPLAY_PORT_MST ; link->type = dc_connection_mst_branch; +dal_ddc_service_set_transaction_type ( + link->ddc, + sink_caps->transaction_type); +/* * This call will initiate MST topology discovery. Which * will detect MST ports and add new DRM connector DRM
Greg Kroah-Hartman
maintainerPATCH 196/235 ASoC: qdsp6: q6afe-dai: fix a range check in of_q6afe_parse_dai_data()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit b8110a87b75f948d978c06e130cc68026645c4a1 ]
The main thing is that the data->priv[] array has AFE_PORT_MAX elements so the > condition should be >=. But we may as well check for negative values as well just to be safe.
--- sound/soc/qcom/qdsp6/q6afe-dai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/qcom/qdsp6/q6afe-dai.c +1 -1
@@ -1180,7 +1180,7 @@ static void of_q6afe_parse_dai_data(struint id, i, num_lines; ret =of_property_read_u32 (node,"reg" , &id); -if (ret || id >AFE_PORT_MAX ) { +if (ret || id <0 || id >=AFE_PORT_MAX ) {dev_err (dev,"valid dai id not found:%d\n" , ret);continue ; }
Greg Kroah-Hartman
maintainerPATCH 197/235 lightnvm: pblk: assume that chunks are closed on 1.2 devices
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Holmberg <[email protected]>
[ Upstream commit f6352103d2e0ad2d2066725eb19bfdfb8763239b ]
We can't know if a block is closed or not on 1.2 devices, so assume closed state to make sure that blocks are erased before writing.
--- drivers/lightnvm/pblk-init.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/lightnvm/pblk-init.c +3 -2
@@ -716,10 +716,11 @@ static int pblk_setup_line_meta_12(struc/* * In 1.2 spec. chunk state is not persisted by the device. Thus -* some of the values are reset each time pblk is instantiated. +* some of the values are reset each time pblk is instantiated, +* so we have to assume that the block is closed. */ if (lun_bb_meta[line->id] ==NVM_BLK_T_FREE ) - chunk->state =NVM_CHK_ST_FREE ; + chunk->state =NVM_CHK_ST_CLOSED ;else chunk->state =NVM_CHK_ST_OFFLINE ;
Greg Kroah-Hartman
maintainerPATCH 198/235 lightnvm: pblk: enable line minor version detection
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matias Bjørling <[email protected]>
[ Upstream commit 99b8dad1b6e52721904220322a947f7b75056303 ]
When recovering a line, an extra check was added when debugging was active, such that minor version where also checked. Unfortunately, this used the ifdef NVM_DEBUG, which is not correct.
Instead use the proper DEBUG def, and now that it compiles, also fix the variable.
--- drivers/lightnvm/pblk-recovery.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/lightnvm/pblk-recovery.c +3 -2
@@ -742,9 +742,10 @@ static int pblk_recov_check_line_versionreturn 1 ; } -#ifdef NVM_DEBUG +#ifdef CONFIG_NVM_PBLK_DEBUG if (header->version_minor >EMETA_VERSION_MINOR ) -pr_info ("pblk: newer line minor version found: %d\n" , line_v); +pr_info ("pblk: newer line minor version found: %d\n" , + header->version_minor);#endif return 0 ;
Greg Kroah-Hartman
maintainerPATCH 199/235 staging: bcm2835-audio: Dont leak workqueue if open fails
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tuomas Tynkkynen <[email protected]>
[ Upstream commit 678c5b119307c40f9a17152512f9c949d0ec7292 ]
Currently, if bcm2835_audio_open() fails partway, the allocated workqueue is leaked. Avoid that.
While at it, propagate the return value of bcm2835_audio_open_connection() on failure instead of returning -1.
--- drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c | 16 +++++++----- 1 file changed, 10 insertions(+), 6 deletions(-)
drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c +10 -6
@@ -439,16 +439,16 @@ int bcm2835_audio_open(struct bcm2835_almy_workqueue_init (alsa_stream); ret =bcm2835_audio_open_connection (alsa_stream); -if (ret) { - ret =-1 ; - goto exit; - } +if (ret) + goto free_wq; + instance = alsa_stream->instance;LOG_DBG (" instance (%p)\n" , instance);if (mutex_lock_interruptible (&instance->vchi_mutex)) {LOG_DBG ("Interrupted whilst waiting for lock on (%d)\n" , instance->num_connections); -return -EINTR ; + ret = -EINTR ; + goto free_wq; }vchi_service_use (instance->vchi_handle[0 ]);
@@ -471,7 +471,11 @@ int bcm2835_audio_open(struct bcm2835_al unlock:vchi_service_release (instance->vchi_handle[0 ]);mutex_unlock (&instance->vchi_mutex); -exit: + +free_wq: +if (ret) +destroy_workqueue (alsa_stream->my_wq); +return ret; }
Greg Kroah-Hartman
maintainerPATCH 200/235 gpio: pxa: Fix potential NULL dereference
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Yongjun <[email protected]>
[ Upstream commit 9506755633d0b32ef76f67c345000178e9b0dfc4 ]
platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference a bit later in the code.
This is detected by Coccinelle semantic patch.
@@
expression pdev, res, n, t, e, e1, e2;
@@
res = platform_get_resource(pdev, t, n);
+ if (!res)
+ return -EINVAL;
... when != res == NULL
e = devm_ioremap(e1, res->start, e2);
--- drivers/gpio/gpio-pxa.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpio/gpio-pxa.c +2 -0
@@ -665,6 +665,8 @@ static int pxa_gpio_probe(struct platfor pchip->irq0 = irq0; pchip->irq1 = irq1; res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); +if (!res) +return -EINVAL ; gpio_reg_base =devm_ioremap (&pdev->dev, res->start,resource_size (res));if (!gpio_reg_base)
Greg Kroah-Hartman
maintainerPATCH 201/235 gpiolib: Mark gpio_suffixes array with __maybe_unused
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
[ Upstream commit b23ec59926faf05b0c43680d05671c484e810ac4 ]
Since we put static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it.
Mark gpio_suffixes array with __maybe_unused to hide a compiler warning:
In file included fromdrivers/gpio/gpiolib-legacy.c:6:0:drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]
static const char * const gpio_suffixes[] = { "gpios", "gpio" };
^~~~~~~~~~~~~
In file included from drivers/gpio/gpiolib-devprop.c:17:0:
drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]
static const char * const gpio_suffixes[] = { "gpios", "gpio" };
^~~~~~~~~~~~~--- drivers/gpio/gpiolib.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpiolib.h +1 -1
@@ -92,7 +92,7 @@ struct acpi_gpio_info { };/* gpio suffixes used for ACPI and device tree lookup */ -static const char *const gpio_suffixes[] = {"gpios" ,"gpio" }; +static __maybe_unused const char *const gpio_suffixes[] = {"gpios" ,"gpio" };#ifdef CONFIG_OF_GPIO struct gpio_desc *of_find_gpio(struct device *dev,
Greg Kroah-Hartman
maintainerPATCH 202/235 net: gemini: Allow multiple ports to instantiate
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <[email protected]>
[ Upstream commit 60cc7767b901dd1e3f70755c3d2505556ba487c2 ]
The code was not tested with two ports actually in use at the same time. (I blame this on lack of actual hardware using that feature.) Now after locating a system using both ports, add necessary fix to make both ports come up.
--- drivers/net/ethernet/cortina/gemini.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/cortina/gemini.c +4 -1
@@ -1753,7 +1753,10 @@ static int gmac_open(struct net_device *phy_start (netdev->phydev); err =geth_resize_freeq (port); -if (err) { +/* It's fine if it's just busy, the other port has set up +* the freeq in that case. +*/ +if (err && (err != -EBUSY )) {netdev_err (netdev,"could not resize freeq\n" ); goto err_stop_phy; }
Greg Kroah-Hartman
maintainerPATCH 203/235 net: mvpp2: make sure we use single queue mode on PPv2.1
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maxime Chevallier <[email protected]>
[ Upstream commit 1e27a628e3f444f53ab8099dfb31c5156e38d112 ]
The PPv2 driver defines 2 "queue_modes" :
- QDIST_SINGLE_MODE, where each port share one rx queue vector between all CPUs
- QDIST_MULTI_MODE, where each port has one rx queue vector per CPU.
Multi queue mode isn't available on PPv2.1, make sure we fallback to single mode when running on this revision.
--- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +6 -0
@@ -5011,6 +5011,12 @@ static int mvpp2_probe(struct platform_d (unsigned long )of_device_get_match_data (&pdev->dev); } +/* multi queue mode isn't supported on PPV2.1, fallback to single +* mode +*/ +if (priv->hw_version ==MVPP21 ) + queue_mode =MVPP2_QDIST_SINGLE_MODE ; + res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); base =devm_ioremap_resource (&pdev->dev, res);if (IS_ERR (base))
Greg Kroah-Hartman
maintainerPATCH 204/235 rcutorture: Use monotonic timestamp for stall detection
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 622be33fcbc93e9b672b99ed338369eb5e843ac3 ]
The get_seconds() call is deprecated because it overflows on 32-bit architectures. The algorithm in rcu_torture_stall() can deal with the overflow, but another problem here is that using a CLOCK_REALTIME stamp can lead to a false-positive stall warning when a settimeofday() happens concurrently.
Using ktime_get_seconds() instead avoids those issues and will never overflow. The added cast to 'unsigned long' however is necessary to make ULONG_CMP_LT() work correctly.
--- kernel/rcu/rcutorture.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
kernel/rcu/rcutorture.c +3 -2
@@ -1446,7 +1446,7 @@ static int rcu_torture_stall(void *args)VERBOSE_TOROUT_STRING ("rcu_torture_stall end holdoff" ); }if (!kthread_should_stop ()) { - stop_at =get_seconds () + stall_cpu; + stop_at =ktime_get_seconds () + stall_cpu;/* RCU CPU stall is expected behavior in following code. */ rcu_read_lock ();if (stall_cpu_irqsoff)
@@ -1455,7 +1455,8 @@ static int rcu_torture_stall(void *args)preempt_disable ();pr_alert ("rcu_torture_stall start on CPU %d.\n" ,smp_processor_id ()); -while (ULONG_CMP_LT (get_seconds (), stop_at)) +while (ULONG_CMP_LT ((unsigned long )ktime_get_seconds (), + stop_at))continue ;/* Induce RCU CPU stall warning. */ if (stall_cpu_irqsoff)local_irq_enable ();
Greg Kroah-Hartman
maintainerPATCH 205/235 mfd: 88pm860x-i2c: switch to i2c_lock_bus(..., I2C_LOCK_SEGMENT)
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Rosin <[email protected]>
[ Upstream commit 8c8f74f327a76604a499fad8c54c15e1c0ee8051 ]
Locking the root adapter for __i2c_transfer will deadlock if the device sits behind a mux-locked I2C mux. Switch to the finer-grained i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not sit behind a mux-locked mux, the two locking variants are equivalent.
--- drivers/mfd/88pm860x-i2c.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/mfd/88pm860x-i2c.c +4 -4
@@ -146,14 +146,14 @@ int pm860x_page_reg_write(struct i2c_cliunsigned char zero;int ret; -i2c_lock_adapter (i2c->adapter); +i2c_lock_bus (i2c->adapter,I2C_LOCK_SEGMENT );read_device (i2c,0xFA ,0 , &zero);read_device (i2c,0xFB ,0 , &zero);read_device (i2c,0xFF ,0 , &zero); ret =write_device (i2c, reg,1 , &data);read_device (i2c,0xFE ,0 , &zero);read_device (i2c,0xFC ,0 , &zero); -i2c_unlock_adapter (i2c->adapter); +i2c_unlock_bus (i2c->adapter,I2C_LOCK_SEGMENT );return ret; }EXPORT_SYMBOL (pm860x_page_reg_write);
@@ -164,14 +164,14 @@ int pm860x_page_bulk_read(struct i2c_cliunsigned char zero =0 ;int ret; -i2c_lock_adapter (i2c->adapter); +i2c_lock_bus (i2c->adapter,I2C_LOCK_SEGMENT );read_device (i2c,0xfa ,0 , &zero);read_device (i2c,0xfb ,0 , &zero);read_device (i2c,0xff ,0 , &zero); ret =read_device (i2c, reg, count, buf);read_device (i2c,0xFE ,0 , &zero);read_device (i2c,0xFC ,0 , &zero); -i2c_unlock_adapter (i2c->adapter); +i2c_unlock_bus (i2c->adapter,I2C_LOCK_SEGMENT );return ret; }EXPORT_SYMBOL (pm860x_page_bulk_read);
Greg Kroah-Hartman
maintainerPATCH 206/235 input: rohm_bu21023: switch to i2c_lock_bus(..., I2C_LOCK_SEGMENT)
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Rosin <[email protected]>
[ Upstream commit 193c2a07cfaacb9249ab0e3d34bce32490879355 ]
Locking the root adapter for __i2c_transfer will deadlock if the device sits behind a mux-locked I2C mux. Switch to the finer-grained i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not sit behind a mux-locked mux, the two locking variants are equivalent.
--- drivers/input/touchscreen/rohm_bu21023.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/input/touchscreen/rohm_bu21023.c +2 -2
@@ -304,7 +304,7 @@ static int rohm_i2c_burst_read(struct i2 msg[1 ].len = len; msg[1 ].buf = buf; -i2c_lock_adapter (adap); +i2c_lock_bus (adap,I2C_LOCK_SEGMENT );for (i =0 ; i <2 ; i++) {if (__i2c_transfer (adap, &msg[i],1 ) <0 ) {
@@ -313,7 +313,7 @@ static int rohm_i2c_burst_read(struct i2 } } -i2c_unlock_adapter (adap); +i2c_unlock_bus (adap,I2C_LOCK_SEGMENT );return ret; }
Greg Kroah-Hartman
maintainerPATCH 207/235 rcu: Fix grace-period hangs due to race with CPU offline
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Paul E. McKenney" <[email protected]>
[ Upstream commit 1e64b15a4b102e1cd059d4d798b7a78f93341333 ]
Without special fail-safe quiescent-state-propagation checks, grace-period hangs can result from the following scenario:
1. CPU 1 goes offline.
2. Because CPU 1 is the only CPU in the system blocking the current
grace period, the grace period ends as soon as rcu_cleanup_dying_idle_cpu()'s call to rcu_report_qs_rnp() returns.
3. At this point, the leaf rcu_node structure's ->lock is no longer
held: rcu_report_qs_rnp() has released it, as it must in order to awaken the RCU grace-period kthread.
4. At this point, that same leaf rcu_node structure's ->qsmaskinitnext
field still records CPU 1 as being online. This is absolutely necessary because the scheduler uses RCU (in this case on the wake-up path while awakening RCU's grace-period kthread), and ->qsmaskinitnext contains RCU's idea as to which CPUs are online. Therefore, invoking rcu_report_qs_rnp() after clearing CPU 1's bit from ->qsmaskinitnext would result in a lockdep-RCU splat due to RCU being used from an offline CPU.
5. RCU's grace-period kthread awakens, sees that the old grace period
has completed and that a new one is needed. It therefore starts a new grace period, but because CPU 1's leaf rcu_node structure's ->qsmaskinitnext field still shows CPU 1 as being online, this new grace period is initialized to wait for a quiescent state from the now-offline CPU 1.
6. Without the fail-safe force-quiescent-state checks, there would
be no quiescent state from the now-offline CPU 1, which would eventually result in RCU CPU stall warnings and memory exhaustion.
It would be good to get rid of the special fail-safe quiescent-state propagation checks, and thus it would be good to fix things so that the above scenario cannot happen. This commit therefore adds a new ->ofl_lock to the rcu_state structure. This lock is held by rcu_gp_init() across the applying of buffered online and offline operations to the rcu_node tree, and it is also held by rcu_cleanup_dying_idle_cpu() when buffering a new offline operation. This prevents rcu_gp_init() from acquiring the leaf rcu_node structure's lock during the interval between when rcu_cleanup_dying_idle_cpu() invokes rcu_report_qs_rnp(), which releases ->lock and the re-acquisition of that same lock. This in turn prevents the failure scenario outlined above, and will hopefully eventually allow removal of the offline-CPU checks from the force-quiescent-state code path.
--- kernel/rcu/tree.c | 6 ++++++ kernel/rcu/tree.h | 4 ++++ 2 files changed, 10 insertions(+)
kernel/rcu/tree.c +6 -0
@@ -102,6 +102,7 @@ struct rcu_state sname##_state = { \ .abbr = sabbr, \ .exp_mutex = __MUTEX_INITIALIZER(sname##_state.exp_mutex), \ .exp_wake_mutex = __MUTEX_INITIALIZER(sname##_state.exp_wake_mutex), \ + .ofl_lock = __SPIN_LOCK_UNLOCKED(sname##_state.ofl_lock), \ }RCU_STATE_INITIALIZER (rcu_sched,'s' , call_rcu_sched);
@@ -1925,11 +1926,13 @@ static bool rcu_gp_init(struct rcu_state*/ rcu_for_each_leaf_node (rsp, rnp) {rcu_gp_slow (rsp, gp_preinit_delay); +spin_lock (&rsp->ofl_lock);raw_spin_lock_irq_rcu_node (rnp);if (rnp->qsmaskinit == rnp->qsmaskinitnext && !rnp->wait_blkd_tasks) {/* Nothing to do on this leaf rcu_node structure. */ raw_spin_unlock_irq_rcu_node (rnp); +spin_unlock (&rsp->ofl_lock);continue ; }
@@ -1964,6 +1967,7 @@ static bool rcu_gp_init(struct rcu_state }raw_spin_unlock_irq_rcu_node (rnp); +spin_unlock (&rsp->ofl_lock); }/*
@@ -3725,9 +3729,11 @@ static void rcu_cleanup_dying_idle_cpu(i/* Remove outgoing CPU from mask in the leaf rcu_node structure. */ mask = rdp->grpmask; +spin_lock (&rsp->ofl_lock);raw_spin_lock_irqsave_rcu_node (rnp, flags);/* Enforce GP memory-order guarantee. */ rnp->qsmaskinitnext &= ~mask;raw_spin_unlock_irqrestore_rcu_node (rnp, flags); +spin_unlock (&rsp->ofl_lock); }/*
kernel/rcu/tree.h +4 -0
@@ -384,6 +384,10 @@ struct rcu_state {const char *name;/* Name of structure. */ char abbr;/* Abbreviated name. */ struct list_head flavors;/* List of RCU flavors. */ + +spinlock_t ofl_lock____cacheline_internodealigned_in_smp ; +/* Synchronize offline with */ +/* GP pre-initialization. */ };/* Values for rcu_state structure's gp_flags field. */
Re: [PATCH 4.18 207/235] rcu: Fix grace-period hangs due to race with CPU offline
Quoted 1 line · Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know.
This should not be needed in 4.18 because of a number of crude but effective grace-period forward-progress failsafes. I have not tested it in isolation. It looks harmless enough, but all testing has been in conjunction with a large number of preceding patches.
I therefore strongly recommend against backporting this one.
Thanx, Paul
Quoted 121 lines
------------------
From: "Paul E. McKenney" <[email protected]>
[ Upstream commit
1e64b15a4b102e1cd059d4d798b7a78f93341333]Without special fail-safe quiescent-state-propagation checks, grace-period hangs can result from the following scenario:
1. CPU 1 goes offline.
2. Because CPU 1 is the only CPU in the system blocking the current
grace period, the grace period ends as soon as rcu_cleanup_dying_idle_cpu()'s call torcu_report_qs_rnp()returns.3. At this point, the leaf
rcu_nodestructure's ->lock is no longer
held:rcu_report_qs_rnp()has released it, as it must in order to awaken the RCU grace-period kthread.4. At this point, that same leaf
rcu_nodestructure's ->qsmaskinitnext
field still records CPU 1 as being online. This is absolutely necessary because the scheduler uses RCU (in this case on the wake-up path while awakening RCU's grace-period kthread), and ->qsmaskinitnext contains RCU's idea as to which CPUs are online. Therefore, invokingrcu_report_qs_rnp()after clearing CPU 1's bit from ->qsmaskinitnext would result in a lockdep-RCU splat due to RCU being used from an offline CPU.5. RCU's grace-period kthread awakens, sees that the old grace period
has completed and that a new one is needed. It therefore starts a new grace period, but because CPU 1's leafrcu_nodestructure's ->qsmaskinitnext field still shows CPU 1 as being online, this new grace period is initialized to wait for a quiescent state from the now-offline CPU 1.6. Without the fail-safe force-quiescent-state checks, there would
be no quiescent state from the now-offline CPU 1, which would eventually result in RCU CPU stall warnings and memory exhaustion.It would be good to get rid of the special fail-safe quiescent-state propagation checks, and thus it would be good to fix things so that the above scenario cannot happen. This commit therefore adds a new ->ofl_lock to the
rcu_statestructure. This lock is held byrcu_gp_init()across the applying of buffered online and offline operations to thercu_nodetree, and it is also held byrcu_cleanup_dying_idle_cpu()when buffering a new offline operation. This preventsrcu_gp_init()from acquiring the leafrcu_nodestructure's lock during the interval between whenrcu_cleanup_dying_idle_cpu()invokesrcu_report_qs_rnp(), which releases ->lock and the re-acquisition of that same lock. This in turn prevents the failure scenario outlined above, and will hopefully eventually allow removal of the offline-CPU checks from the force-quiescent-state code path.Signed-off-by Paul E. McKenney <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- kernel/rcu/tree.c | 6 ++++++ kernel/rcu/tree.h | 4 ++++ 2 files changed, 10 insertions(+)kernel/rcu/tree.c +6
-0@@ -102,6 +102,7 @@ struct rcu_state sname##_state = { \ .abbr = sabbr, \ .exp_mutex = __MUTEX_INITIALIZER(sname##_state.exp_mutex), \ .exp_wake_mutex = __MUTEX_INITIALIZER(sname##_state.exp_wake_mutex), \ + .ofl_lock = __SPIN_LOCK_UNLOCKED(sname##_state.ofl_lock), \ }RCU_STATE_INITIALIZER (rcu_sched,'s' , call_rcu_sched);@@ -1925,11 +1926,13 @@ static bool rcu_gp_init(struct rcu_state*/ rcu_for_each_leaf_node (rsp, rnp) {rcu_gp_slow (rsp, gp_preinit_delay); +spin_lock (&rsp->ofl_lock);raw_spin_lock_irq_rcu_node (rnp);if (rnp->qsmaskinit == rnp->qsmaskinitnext && !rnp->wait_blkd_tasks) {/* Nothing to do on this leaf rcu_node structure. */ raw_spin_unlock_irq_rcu_node (rnp); +spin_unlock (&rsp->ofl_lock);continue ; }@@ -1964,6 +1967,7 @@ static bool rcu_gp_init(struct rcu_state }raw_spin_unlock_irq_rcu_node (rnp); +spin_unlock (&rsp->ofl_lock); }/* @@ -3725,9 +3729,11 @@ static void rcu_cleanup_dying_idle_cpu(i/* Remove outgoing CPU from mask in the leaf rcu_node structure. */ mask = rdp->grpmask; +spin_lock (&rsp->ofl_lock);raw_spin_lock_irqsave_rcu_node (rnp, flags);/* Enforce GP memory-order guarantee. */ rnp->qsmaskinitnext &= ~mask;raw_spin_unlock_irqrestore_rcu_node (rnp, flags); +spin_unlock (&rsp->ofl_lock); }/* kernel/rcu/tree.h +4
-0@@ -384,6 +384,10 @@ struct rcu_state {const char *name;/* Name of structure. */ char abbr;/* Abbreviated name. */ struct list_head flavors;/* List of RCU flavors. */ + +spinlock_t ofl_lock____cacheline_internodealigned_in_smp ; +/* Synchronize offline with */ +/* GP pre-initialization. */ };/* Values for rcu_state structure's gp_flags field. */
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 207/235] rcu: Fix grace-period hangs due to race with CPU offline
Quoted 9 lines · Paul E. McKenney
Quoted 1 line · Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know.
This should not be needed in 4.18 because of a number of crude but effective grace-period forward-progress failsafes. I have not tested it in isolation. It looks harmless enough, but all testing has been in conjunction with a large number of preceding patches.
I therefore strongly recommend against backporting this one.
Now dropped from all 3 queues, thanks for letting me know.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 208/235 drm/amdkfd: Fix kernel queue 64 bit doorbell offset calculation
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shaoyun Liu <[email protected]>
[ Upstream commit 951df6d9cfd07f205f1905bf3b27d994612e0614 ]
The bitmap index calculation should reverse the logic used on allocation so it will clear the same bit used on allocation
--- drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c +5 -4
@@ -188,9 +188,9 @@ void __iomem *kfd_get_kernel_doorbell(st *doorbell_off = kfd->doorbell_id_offset + inx;pr_debug ("Get kernel queue doorbell\n" -" doorbell offset == 0x%08X\n" -" kernel address == %p\n" , - *doorbell_off, (kfd->doorbell_kernel_ptr + inx)); +" doorbell offset == 0x%08X\n" +" doorbell index == 0x%x\n" , + *doorbell_off, inx);return kfd->doorbell_kernel_ptr + inx; }
@@ -199,7 +199,8 @@ void kfd_release_kernel_doorbell(struct {unsigned int inx; - inx = (unsigned int )(db_addr - kfd->doorbell_kernel_ptr); + inx = (unsigned int )(db_addr - kfd->doorbell_kernel_ptr) + *sizeof (u32) / kfd->device_info->doorbell_size;mutex_lock (&kfd->doorbell_mutex);__clear_bit (inx, kfd->doorbell_available_index);
Greg Kroah-Hartman
maintainerPATCH 209/235 drm/amdkfd: Fix error codes in kfd_get_process
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Lu <[email protected]>
[ Upstream commit e47cb828eb3fca3e8999a0b9aa053dda18552071 ]
Return ERR_PTR(-EINVAL) if kfd_get_process fails to find the process. This fixes kernel oopses when a child process calls KFD ioctls with a file descriptor inherited from the parent process.
--- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/amd/amdkfd/kfd_process.c +2 -0
@@ -244,6 +244,8 @@ struct kfd_process *kfd_get_process(consreturn ERR_PTR (-EINVAL ); process =find_process (thread); +if (!process) +return ERR_PTR (-EINVAL );return process; }
Greg Kroah-Hartman
maintainerPATCH 210/235 rtc: bq4802: add error handling for devm_ioremap
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhouyang Jia <[email protected]>
[ Upstream commit 7874b919866ba91bac253fa219d3d4c82bb944df ]
When devm_ioremap fails, the lack of error-handling code may cause unexpected results.
This patch adds error-handling code after calling devm_ioremap.
--- drivers/rtc/rtc-bq4802.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/rtc/rtc-bq4802.c +4 -0
@@ -162,6 +162,10 @@ static int bq4802_probe(struct platform_ }else if (p->r->flags &IORESOURCE_MEM ) { p->regs =devm_ioremap (&pdev->dev, p->r->start,resource_size (p->r)); +if (!p->regs){ + err = -ENOMEM ; + goto out; + } p->read = bq4802_read_mem; p->write = bq4802_write_mem; }else {
Greg Kroah-Hartman
maintainerPATCH 211/235 selftests: vDSO - fix to return KSFT_SKIP when test couldnt be run
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Shuah Khan (Samsung OSG)" <[email protected]>
[ Upstream commit d2d49495b5c0dffee5c4da5ea12ac0da6679bd08 ]
Fix to return KSFT_SKIP when test couldn't be run because AT_SYSINFO_EHDR isn't found and gettimeofday isn't defined.
--- tools/testing/selftests/vDSO/vdso_test.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
tools/testing/selftests/vDSO/vdso_test.c +5 -2
@@ -15,6 +15,8 @@#include <sys/auxv.h> #include <sys/time.h> +#include "../kselftest.h" +extern void *vdso_sym (const char *version,const char *name);extern void vdso_init_from_sysinfo_ehdr (uintptr_t base);extern void vdso_init_from_auxv (void *auxv);
@@ -37,7 +39,7 @@ int main(int argc, char **argv)unsigned long sysinfo_ehdr =getauxval (AT_SYSINFO_EHDR );if (!sysinfo_ehdr) {printf ("AT_SYSINFO_EHDR is not present!\n" ); -return 0 ; +return KSFT_SKIP ; }vdso_init_from_sysinfo_ehdr (getauxval (AT_SYSINFO_EHDR ));
@@ -48,7 +50,7 @@ int main(int argc, char **argv)if (!gtod) {printf ("Could not find %s\n" , name); -return 1 ; +return KSFT_SKIP ; }struct timeval tv;
@@ -59,6 +61,7 @@ int main(int argc, char **argv) (long long)tv.tv_sec, (long long)tv.tv_usec); }else {printf ("%s failed\n" , name); +return KSFT_FAIL ; }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 212/235 selftests/android: initialize heap_type to avoid compiling warning
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Zhijian <[email protected]>
[ Upstream commit cc7c673032fc7427087e74b75f732b43db38a256 ]
Initialize heap_type to ION_HEAP_TYPE_SYSTEM to avoid "used uninitialized" compiler warning. heap_type gets used after initialization, this change is to just keep the compiler happy.
root@vm-lkp-nex04-8G-7 ~/linux-v4.18-rc2/tools/testing/selftests/android# make make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. make[1]: Entering directory '/root/linux-v4.18-rc2/tools/testing/selftests/android/ion'
gcc -I. -I../../../../../drivers/staging/android/uapi/ -I../../../../../usr/include/ -Wall -O2 -g ionapp_export.c ipcsocket.c ionutils.c -o ionapp_exportionapp_export.c: In function 'main':
ionapp_export.c:91:2: warning: 'heap_type' may be used uninitialized in this function [-Wmaybe-uninitialized]
printf("heap_type: %ld, heap_size: %ld\n", heap_type, heap_size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--- tools/testing/selftests/android/ion/ionapp_export.c | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/android/ion/ionapp_export.c +1 -0
@@ -51,6 +51,7 @@ int main(int argc, char *argv[]) heap_size =0 ; flags =0 ; + heap_type =ION_HEAP_TYPE_SYSTEM ;while ((opt =getopt (argc, argv,"hi:s:" )) !=-1 ) {switch (opt) {
Greg Kroah-Hartman
maintainerPATCH 213/235 ALSA: pcm: Fix snd_interval_refine first/last with open min/max
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Timo Wischer <[email protected]>
[ Upstream commit ff2d6acdf6f13d9f8fdcd890844c6d7535ac1f10 ]
Without this commit the following intervals [x y), (x y) were be replaced to (y-1 y) by snd_interval_refine_last(). This was also done if y-1 is part of the previous interval.
With this changes it will be replaced with [y-1 y) in case of y-1 is part of the previous interval. A similar behavior will be used for snd_interval_refine_first().
This commit adapts the changes for alsa-lib of commit 9bb985c ("pcm: snd_interval_refine_first/last: exclude value only if also excluded before")
--- sound/core/pcm_lib.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
sound/core/pcm_lib.c +10 -4
@@ -626,27 +626,33 @@ EXPORT_SYMBOL(snd_interval_refine);static int snd_interval_refine_first (struct snd_interval *i) { +const unsigned int last_max = i->max; +if (snd_BUG_ON (snd_interval_empty (i)))return -EINVAL ;if (snd_interval_single (i))return 0 ; i->max = i->min; - i->openmax = i->openmin; -if (i->openmax) +if (i->openmin) i->max++; +/* only exclude max value if also excluded before refine */ + i->openmax = (i->openmax && i->max >= last_max);return 1 ; }static int snd_interval_refine_last (struct snd_interval *i) { +const unsigned int last_min = i->min; +if (snd_BUG_ON (snd_interval_empty (i)))return -EINVAL ;if (snd_interval_single (i))return 0 ; i->min = i->max; - i->openmin = i->openmax; -if (i->openmin) +if (i->openmax) i->min--; +/* only exclude min value if also excluded before refine */ + i->openmin = (i->openmin && i->min <= last_min);return 1 ; }
Greg Kroah-Hartman
maintainerPATCH 214/235 scsi: libfc: fixup sleeping function called from invalid context
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hannes Reinecke <[email protected]>
[ Upstream commit fa519f701d27198a2858bb108fc18ea9d8c106a7 ]
fc_rport_login() will be calling mutex_lock() while running inside an RCU-protected section, triggering the warning 'sleeping function called from invalid context'. To fix this we can drop the rcu functions here altogether as the disc mutex protecting the list itself is already held, preventing any list manipulation.
--- drivers/scsi/libfc/fc_disc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/scsi/libfc/fc_disc.c +4 -3
@@ -294,9 +294,11 @@ static void fc_disc_done(struct fc_disc* discovery, reverify or log them in. Otherwise, log them out. * Skip ports which were never discovered. These are the dNS port * and ports which were created by PLOGI. +* +* We don't need to use the _rcu variant here as the rport list +* is protected by the disc mutex which is already held on entry. */ -rcu_read_lock (); -list_for_each_entry_rcu (rdata, &disc->rports, peers) { +list_for_each_entry (rdata, &disc->rports, peers) {if (!kref_get_unless_zero (&rdata->kref))continue ;if (rdata->disc_id) {
@@ -307,7 +309,6 @@ static void fc_disc_done(struct fc_disc }kref_put (&rdata->kref, fc_rport_destroy); } -rcu_read_unlock ();mutex_unlock (&disc->disc_mutex); disc->disc_callback (lport, event);mutex_lock (&disc->disc_mutex);
Greg Kroah-Hartman
maintainerPATCH 215/235 scsi: lpfc: Fix NVME Target crash in defer rcv logic
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Smart <[email protected]>
[ Upstream commit 6871e8144f935a1f08e7fc6269c894861ce494aa ]
Kernel occasionally crashed with the following
ops on NVME Target:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 IP: [<ffffffffa042ee50>] lpfc_nvmet_defer_rcv+0x50/0x70 [lpfc]
Callback routine was called for deferred rcv when it should be treated as a normal rcv.
Added code in callback routine to detect this condition and log a message, then bail.
--- drivers/scsi/lpfc/lpfc_nvmet.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_nvmet.c +11 -1
@@ -402,6 +402,7 @@ lpfc_nvmet_ctxbuf_post(struct lpfc_hba */* Process FCP command */ if (rc ==0 ) { + ctxp->rqb_buffer =NULL ;atomic_inc (&tgtp->rcv_fcp_cmd_out); nvmebuf->hrq->rqbp->rqb_free_buffer (phba, nvmebuf);return ;
@@ -1116,8 +1117,17 @@ lpfc_nvmet_defer_rcv(struct nvmet_fc_tarlpfc_nvmeio_data (phba,"NVMET DEFERRCV: xri x%x sz %d CPU %02x\n" , ctxp->oxid, ctxp->size,smp_processor_id ()); +if (!nvmebuf) { +lpfc_printf_log (phba,KERN_INFO ,LOG_NVME_IOERR , +"6425 Defer rcv: no buffer xri x%x: " +"flg %x ste %x\n" , + ctxp->oxid, ctxp->flag, ctxp->state); +return ; + } + tgtp = phba->targetport->private; -atomic_inc (&tgtp->rcv_fcp_cmd_defer); +if (tgtp) +atomic_inc (&tgtp->rcv_fcp_cmd_defer);/* Free the nvmebuf since a new buffer already replaced it */ nvmebuf->hrq->rqbp->rqb_free_buffer (phba, nvmebuf);
Greg Kroah-Hartman
maintainerPATCH 216/235 scsi: lpfc: Fix panic if driver unloaded when port is offline
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Smart <[email protected]>
[ Upstream commit d580c6137476ab307a66e278cf7dbc666230f714 ]
System crashes when the lpfc module is unloaded after making the port offline
The nvme queue pointers were freed during port offline, but were later accessed in pci remove path.
Validate the pointers in pci remove path before accessing them.
--- drivers/scsi/lpfc/lpfc_nvme.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_nvme.c +4 -1
@@ -2976,7 +2976,7 @@ lpfc_nvme_wait_for_io_drain(struct lpfc_struct lpfc_sli_ring *pring;u32 i, wait_cnt =0 ; -if (phba->sli_rev <LPFC_SLI_REV4 ) +if (phba->sli_rev <LPFC_SLI_REV4 || !phba->sli4_hba.nvme_wq)return ;/* Cycle through all NVME rings and make sure all outstanding
@@ -2985,6 +2985,9 @@ lpfc_nvme_wait_for_io_drain(struct lpfc_for (i =0 ; i < phba->cfg_nvme_io_channel; i++) { pring = phba->sli4_hba.nvme_wq[i]->pring; +if (!pring) +continue ; +/* Retrieve everything on the txcmplq */ while (!list_empty (&pring->txcmplq)) {msleep (LPFC_XRI_EXCH_BUSY_WAIT_T1 );
Greg Kroah-Hartman
maintainerPATCH 217/235 remoteproc: qcom: q6v5-pil: fix modem hang on SDM845 after axis2 clk unvote
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sibi Sankar <[email protected]>
[ Upstream commit 7cbb540a3a68e4d4a8bef2d9451afb1635b5d2d3 ]
GCC_MSS_AXIS2 clock is used for disabling boot IMEM (a part of AP boot up). With Boot IMEM disable now a part TZ/ATF, AXIS2 clock is no longer required post AP boot up and expected to remain untouched. However if the clock is turned ON after Q6 is brought out of reset and later turned off, it results in modem hang. When Q6 attempts a power collapse the internal handshaking to check if AXIS2 is idle never goes through since it is turned off preventing the RSC from getting triggered, leaving modem in a funky state. Hence removing AXIS2 clk enable/disable from the driver.
--- drivers/remoteproc/qcom_q6v5_pil.c | 1 - 1 file changed, 1 deletion(-)
drivers/remoteproc/qcom_q6v5_pil.c +0 -1
@@ -1370,7 +1370,6 @@ static const struct rproc_hexagon_res sd .hexagon_mba_image = "mba.mbn", .proxy_clk_names = (char *[]){"xo" , -"axis2" ,"prng" ,NULL },
Greg Kroah-Hartman
maintainerPATCH 218/235 selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET/other clock adjustments are in progress
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
[ Upstream commit 1416270f4a1ae83ea84156ceba19a66a8f88be1f ]
In the past we've warned when ADJ_OFFSET was in progress, usually caused by ntpd or some other time adjusting daemon running in non steady sate, which can cause the skew calculations to be incorrect.
Thus, this patch checks to see if the clock was being adjusted when we fail so that we don't cause false negatives.
---
v2: Widened the checks to look for other clock adjustments that
could happen, as suggested by Miroslav
v3: Fixed up commit message
Signed-off-by: Sasha Levin <alexander.levin at microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
--- tools/testing/selftests/timers/raw_skew.c | 5 +++++ 1 file changed, 5 insertions(+)
tools/testing/selftests/timers/raw_skew.c +5 -0
@@ -134,6 +134,11 @@ int main(int argv, char **argc)printf (" %lld.%i(act)" , ppm/1000 ,abs ((int )(ppm%1000 )));if (llabs (eppm - ppm) >1000 ) { +if (tx1.offset || tx2.offset || + tx1.freq != tx2.freq || tx1.tick != tx2.tick) { +printf (" [SKIP]\n" ); +return ksft_exit_skip ("The clock was adjusted externally. Shutdown NTPd or other time sync daemons\n" ); + }printf (" [FAILED]\n" );return ksft_exit_fail (); }
Greg Kroah-Hartman
maintainerPATCH 219/235 ASoC: rt5651: Fix workqueue cancel vs irq free race on remove
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit 8d2d7bcdc1645dc243f7735278675b083c0e506c ]
On removal we must free the IRQ *before* cancelling the jack-detect work, so that the jack-detect work cannot be rescheduled by the IRQ.
Before this commit we were cancelling the jack-detect work from the driver remove callback, while relying on devm to free the IRQ, which happens after the remove callback.
This is the wrong order. This commit uses a devm-action to register a devm callback which cancels the work, before requesting the IRQ (devm tears things down in reverse order). This also allows us to remove the now empty remove driver callback.
--- sound/soc/codecs/rt5651.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
sound/soc/codecs/rt5651.c +12 -10
@@ -1696,6 +1696,13 @@ static irqreturn_t rt5651_irq(int irq, vreturn IRQ_HANDLED ; } +static void rt5651_cancel_work (void *data) +{ +struct rt5651_priv *rt5651 = data; + +cancel_work_sync (&rt5651->jack_detect_work); +} +static int rt5651_set_jack (struct snd_soc_component *component,struct snd_soc_jack *hp_jack,void *data) {
@@ -2036,6 +2043,11 @@ static int rt5651_i2c_probe(struct i2c_cINIT_WORK (&rt5651->jack_detect_work, rt5651_jack_detect_work); +/* Make sure work is stopped on probe-error / remove */ + ret =devm_add_action_or_reset (&i2c->dev, rt5651_cancel_work, rt5651); +if (ret) +return ret; + ret =devm_snd_soc_register_component (&i2c->dev, &soc_component_dev_rt5651, rt5651_dai,ARRAY_SIZE (rt5651_dai));
@@ -2043,15 +2055,6 @@ static int rt5651_i2c_probe(struct i2c_creturn ret; } -static int rt5651_i2c_remove (struct i2c_client *i2c) -{ -struct rt5651_priv *rt5651 =i2c_get_clientdata (i2c); - -cancel_work_sync (&rt5651->jack_detect_work); - -return 0 ; -} -static struct i2c_driver rt5651_i2c_driver = { .driver = { .name ="rt5651" ,
@@ -2059,7 +2062,6 @@ static struct i2c_driver rt5651_i2c_driv .of_match_table = of_match_ptr(rt5651_of_match), }, .probe = rt5651_i2c_probe, - .remove = rt5651_i2c_remove, .id_table = rt5651_i2c_id, };module_i2c_driver (rt5651_i2c_driver);
Greg Kroah-Hartman
maintainerPATCH 220/235 drm/panel: type promotion bug in s6e8aa0_read_mtp_id()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit cd0e0ca69109d025b1a1b6609f70682db62138b0 ]
The ARRAY_SIZE() macro is type size_t. If s6e8aa0_dcs_read() returns a negative error code, then "ret < ARRAY_SIZE(id)" is false because the negative error code is type promoted to a high positive value.
--- drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c +1 -1
@@ -823,7 +823,7 @@ static void s6e8aa0_read_mtp_id(struct sint ret, i; ret =s6e8aa0_dcs_read (ctx,0xd1 , id,ARRAY_SIZE (id)); -if (ret <ARRAY_SIZE (id) || id[0 ] ==0x00 ) { +if (ret <0 || ret <ARRAY_SIZE (id) || id[0 ] ==0x00 ) {dev_err (ctx->dev,"read id failed\n" ); ctx->error = -EIO ;return ;
Greg Kroah-Hartman
maintainerPATCH 221/235 arm64: perf: Disable PMU while processing counter overflows
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Suzuki K Poulose <[email protected]>
[ Upstream commit 3cce50dfec4a5b0414c974190940f47dd32c6dee ]
The arm64 PMU updates the event counters and reprograms the counters in the overflow IRQ handler without disabling the PMU. This could potentially cause skews in for group counters, where the overflowed counters may potentially loose some event counts, while they are reprogrammed. To prevent this, disable the PMU while we process the counter overflows and enable it right back when we are done.
This patch also moves the PMU stop/start routines to avoid a forward declaration.
--- arch/arm64/kernel/perf_event.c | 50 ++++++++++++++++++++++------------------- 1 file changed, 28 insertions(+), 22 deletions(-)
arch/arm64/kernel/perf_event.c +28 -22
@@ -670,6 +670,28 @@ static void armv8pmu_disable_event(strucraw_spin_unlock_irqrestore (&events->pmu_lock, flags); } +static void armv8pmu_start (struct arm_pmu *cpu_pmu) +{ +unsigned long flags; +struct pmu_hw_events *events =this_cpu_ptr (cpu_pmu->hw_events); + +raw_spin_lock_irqsave (&events->pmu_lock, flags); +/* Enable all counters */ +armv8pmu_pmcr_write (armv8pmu_pmcr_read () |ARMV8_PMU_PMCR_E ); +raw_spin_unlock_irqrestore (&events->pmu_lock, flags); +} + +static void armv8pmu_stop (struct arm_pmu *cpu_pmu) +{ +unsigned long flags; +struct pmu_hw_events *events =this_cpu_ptr (cpu_pmu->hw_events); + +raw_spin_lock_irqsave (&events->pmu_lock, flags); +/* Disable all counters */ +armv8pmu_pmcr_write (armv8pmu_pmcr_read () & ~ARMV8_PMU_PMCR_E ); +raw_spin_unlock_irqrestore (&events->pmu_lock, flags); +} +static irqreturn_t armv8pmu_handle_irq (struct arm_pmu *cpu_pmu) {u32 pmovsr;
@@ -694,6 +716,11 @@ static irqreturn_t armv8pmu_handle_irq(s*/ regs =get_irq_regs (); +/* +* Stop the PMU while processing the counter overflows +* to prevent skews in group events. +*/ +armv8pmu_stop (cpu_pmu);for (idx =0 ; idx < cpu_pmu->num_events; ++idx) {struct perf_event *event = cpuc->events[idx];struct hw_perf_event *hwc;
@@ -718,6 +745,7 @@ static irqreturn_t armv8pmu_handle_irq(sif (perf_event_overflow (event, &data, regs)) cpu_pmu->disable (event); } +armv8pmu_start (cpu_pmu);/* * Handle the pending perf events.
@@ -731,28 +759,6 @@ static irqreturn_t armv8pmu_handle_irq(sreturn IRQ_HANDLED ; } -static void armv8pmu_start (struct arm_pmu *cpu_pmu) -{ -unsigned long flags; -struct pmu_hw_events *events =this_cpu_ptr (cpu_pmu->hw_events); - -raw_spin_lock_irqsave (&events->pmu_lock, flags); -/* Enable all counters */ -armv8pmu_pmcr_write (armv8pmu_pmcr_read () |ARMV8_PMU_PMCR_E ); -raw_spin_unlock_irqrestore (&events->pmu_lock, flags); -} - -static void armv8pmu_stop (struct arm_pmu *cpu_pmu) -{ -unsigned long flags; -struct pmu_hw_events *events =this_cpu_ptr (cpu_pmu->hw_events); - -raw_spin_lock_irqsave (&events->pmu_lock, flags); -/* Disable all counters */ -armv8pmu_pmcr_write (armv8pmu_pmcr_read () & ~ARMV8_PMU_PMCR_E ); -raw_spin_unlock_irqrestore (&events->pmu_lock, flags); -} -static int armv8pmu_get_event_idx (struct pmu_hw_events *cpuc,struct perf_event *event) {
Greg Kroah-Hartman
maintainerPATCH 222/235 drm/amd/pp: Send khz clock values to DC for smu7/8
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harry Wentland <[email protected]>
[ Upstream commit c3cb424a086921f6bb0449b10d998352a756d6d5 ]
The previous change wasn't covering smu 7 and 8 and therefore DC was seeing wrong clock values.
This fixes an issue where the pipes seem to hang with a 4k DP and 1080p HDMI display.
--- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 8 ++++---- drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-)
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +4 -4
@@ -4555,12 +4555,12 @@ static int smu7_get_sclks(struct pp_hwmgreturn -EINVAL ; dep_sclk_table = table_info->vdd_dep_on_sclk;for (i =0 ; i < dep_sclk_table->count; i++) - clocks->clock[i] = dep_sclk_table->entries[i].clk; + clocks->clock[i] = dep_sclk_table->entries[i].clk *10 ; clocks->count = dep_sclk_table->count; }else if (hwmgr->pp_table_version ==PP_TABLE_V0 ) { sclk_table = hwmgr->dyn_state.vddc_dependency_on_sclk;for (i =0 ; i < sclk_table->count; i++) - clocks->clock[i] = sclk_table->entries[i].clk; + clocks->clock[i] = sclk_table->entries[i].clk *10 ; clocks->count = sclk_table->count; }
@@ -4592,7 +4592,7 @@ static int smu7_get_mclks(struct pp_hwmgreturn -EINVAL ; dep_mclk_table = table_info->vdd_dep_on_mclk;for (i =0 ; i < dep_mclk_table->count; i++) { - clocks->clock[i] = dep_mclk_table->entries[i].clk; + clocks->clock[i] = dep_mclk_table->entries[i].clk *10 ; clocks->latency[i] =smu7_get_mem_latency (hwmgr, dep_mclk_table->entries[i].clk); }
@@ -4600,7 +4600,7 @@ static int smu7_get_mclks(struct pp_hwmg }else if (hwmgr->pp_table_version ==PP_TABLE_V0 ) { mclk_table = hwmgr->dyn_state.vddc_dependency_on_mclk;for (i =0 ; i < mclk_table->count; i++) - clocks->clock[i] = mclk_table->entries[i].clk; + clocks->clock[i] = mclk_table->entries[i].clk *10 ; clocks->count = mclk_table->count; }return 0 ;
drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c +3 -3
@@ -1605,17 +1605,17 @@ static int smu8_get_clock_by_type(structswitch (type) {case amd_pp_disp_clock:for (i =0 ; i < clocks->count; i++) - clocks->clock[i] = data->sys_info.display_clock[i]; + clocks->clock[i] = data->sys_info.display_clock[i] *10 ;break ;case amd_pp_sys_clock: table = hwmgr->dyn_state.vddc_dependency_on_sclk;for (i =0 ; i < clocks->count; i++) - clocks->clock[i] = table->entries[i].clk; + clocks->clock[i] = table->entries[i].clk *10 ;break ;case amd_pp_mem_clock: clocks->count =SMU8_NUM_NBPMEMORYCLOCK ;for (i =0 ; i < clocks->count; i++) - clocks->clock[i] = data->sys_info.nbp_memory_clock[clocks->count -1 - i]; + clocks->clock[i] = data->sys_info.nbp_memory_clock[clocks->count -1 - i] *10 ;break ;default :return -1 ;
RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 11 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 2 lines
4.18-stable review patch. If anyone has any objections, please let me know.
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275
Thanks,
Alex
Quoted 88 lines
------------------
From: Harry Wentland <[email protected]>
[ Upstream commit
c3cb424a086921f6bb0449b10d998352a756d6d5]The previous change wasn't covering smu 7 and 8 and therefore DC was seeing wrong clock values.
This fixes an issue where the pipes seem to hang with a 4k DP and 1080p HDMI display.
Fixes c3df50abc84b ("drm/amd/pp: Convert clock unit to KHz as defined")Signed-off-by Harry Wentland <[email protected]>Acked-by Alex Deucher <[email protected]>Signed-off-by Alex Deucher <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 8 ++++---- drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-)drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +3
-3@@ -4555,12 +4555,12 @@ static int smu7_get_sclks(struct pp_hwmgreturn -EINVAL ; dep_sclk_table = table_info->vdd_dep_on_sclk;for (i =0 ; i < dep_sclk_table->count; i++) - clocks->clock[i] = dep_sclk_table->entries[i].clk; + clocks->clock[i] = dep_sclk_table->entries[i].clk *10 ; clocks->count = dep_sclk_table->count; }else if (hwmgr->pp_table_version ==PP_TABLE_V0 ) { sclk_table = hwmgr->dyn_state.vddc_dependency_on_sclk;for (i =0 ; i < sclk_table->count; i++) - clocks->clock[i] = sclk_table->entries[i].clk; + clocks->clock[i] = sclk_table->entries[i].clk *10 ; clocks->count = sclk_table->count; }@@ -4592,7 +4592,7 @@ static int smu7_get_mclks(struct pp_hwmgreturn -EINVAL ; dep_mclk_table = table_info->vdd_dep_on_mclk;for (i =0 ; i < dep_mclk_table->count; i++) { - clocks->clock[i] = dep_mclk_table->entries[i].clk; + clocks->clock[i] = dep_mclk_table->entries[i].clk *10 ; clocks->latency[i] =smu7_get_mem_latency (hwmgr, dep_mclk_table- >entries[i].clk);drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +1
-1}@@ -4600,7 +4600,7 @@ static int smu7_get_mclks(struct pp_hwmg }else if (hwmgr->pp_table_version ==PP_TABLE_V0 ) { mclk_table = hwmgr- >dyn_state.vddc_dependency_on_mclk;for (i =0 ; i < mclk_table->count; i++) - clocks->clock[i] = mclk_table->entries[i].clk; + clocks->clock[i] = mclk_table->entries[i].clk *10 ; clocks->count = mclk_table->count; }drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +0
-0return 0 ;drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c +3
-3@@ -1605,17 +1605,17 @@ static int smu8_get_clock_by_type(structswitch (type) {case amd_pp_disp_clock:for (i =0 ; i < clocks->count; i++) - clocks->clock[i] = data->sys_info.display_clock[i]; + clocks->clock[i] = data->sys_info.display_clock[i] *10 ;break ;case amd_pp_sys_clock: table = hwmgr->dyn_state.vddc_dependency_on_sclk;for (i =0 ; i < clocks->count; i++) - clocks->clock[i] = table->entries[i].clk; + clocks->clock[i] = table->entries[i].clk *10 ;break ;case amd_pp_mem_clock: clocks->count =SMU8_NUM_NBPMEMORYCLOCK ;for (i =0 ; i < clocks->count; i++) - clocks->clock[i] = data- >sys_info.nbp_memory_clock[clocks->count - 1 - i]; + clocks->clock[i] = data-Quoted 1 line
sys_info.nbp_memory_clock[clocks->count - 1
+- i] * 10;
drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c +0
-0break ;default :return -1 ;
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 11 lines · Alexander
Quoted 11 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 5 lines
Quoted 2 lines
4.18-stable review patch. If anyone has any objections, please let me know.
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275
Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.
thanks,
greg k-h
RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 24 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 12 lines · Alexander
Quoted 12 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8Quoted 1 line
Quoted 1 line
4.18-stable review patch. If anyone has any objections, please let me
Quoted 9 lines
know.
Quoted 4 lines
Quoted 1 line
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.
There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.
Alex
Quoted 3 lines
thanks,
greg k-h
RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Hi Alex,
Yes, we have fixed this issue in drm-next.
I am trying to dig out the patches in drm-next and will sent them out.
Regards
Rex
Quoted 55 lines
-----Original Message-----
From: Deucher, Alexander
Sent: Tuesday, October 9, 2018 12:02 AM
To: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 6 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;Sasha
Quoted 19 lines
Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 12 lines · Alexander
Quoted 12 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8Quoted 2 lines
Quoted 2 lines
4.18-stable review patch. If anyone has any objections, please let me
Quoted 9 lines
know.
Quoted 4 lines
Quoted 1 line
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.
There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.
Alex
Quoted 3 lines
thanks,
greg k-h
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
In reply to Deucher, AlexanderQuoted 30 lines · Alexander
Quoted 30 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 12 lines · Alexander
Quoted 12 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8Quoted 1 line
Quoted 1 line
4.18-stable review patch. If anyone has any objections, please let me
know.
Quoted 4 lines
Quoted 1 line
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275
Quoted 7 lines
Quoted 3 lines
Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.
There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.
So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.
confused,
greg k-h
RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 49 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 1:11 PM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 6 lines · Alexander
Quoted 6 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;Sasha
Quoted 5 lines
Quoted 5 lines
Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>;Sasha
Quoted 17 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines
Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/84.18-stable review patch. If anyone has any objections, please let me
know.
Quoted 4 lines
Quoted 1 line
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.
Quoted 6 lines
Quoted 3 lines
There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.
So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.
Sorry, what statement about drm-next? This patch was for 4.19 and was not intended for 4.18. It was picked up by Sasha's auto select system for stable.
Alex
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 49 lines · Alexander
Quoted 49 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 1:11 PM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 6 lines · Alexander
Quoted 6 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;Sasha
Quoted 5 lines
Quoted 5 lines
Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>;Sasha
Quoted 17 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines
Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/84.18-stable review patch. If anyone has any objections, please let me
know.
Quoted 4 lines
Quoted 1 line
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.
So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.
Sorry, what statement about drm-next? This patch was for 4.19 and was not intended for 4.18. It was picked up by Sasha's auto select system for stable.
I thought this thread said that.
Ok, so I should just revert it?
thanks,
greg k-h
RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 72 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Tuesday, October 9, 2018 8:45 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 6 lines · Alexander
Quoted 6 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 1:11 PM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;Sasha
Quoted 18 lines
Quoted 18 lines
Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 7 lines · Alexander
Quoted 7 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;Sasha
Quoted 5 lines
Quoted 5 lines
Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander
Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, RexQuoted 26 lines
Quoted 25 lines
Sasha
Quoted 13 lines
Quoted 13 lines
Quoted 7 lines
Quoted 7 lines
Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/84.18-stable review patch. If anyone has any objections, please let me
know.
Quoted 4 lines
Quoted 1 line
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275Quoted 8 lines
Quoted 3 lines
Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.
There's no breakage in upstream. This patch addressed breakages in
4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.
Quoted 7 lines
Quoted 1 line
Sorry, what statement about drm-next? This patch was for 4.19 and was
not intended for 4.18. It was picked up by Sasha's auto select system for stable.
I thought this thread said that.
Ok, so I should just revert it?
Yes, please.
Thanks,
Alex
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 73 lines · Alexander
Quoted 73 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Tuesday, October 9, 2018 8:45 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 6 lines · Alexander
Quoted 6 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 1:11 PM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;Sasha
Quoted 18 lines
Quoted 18 lines
Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 7 lines · Alexander
Quoted 7 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;Sasha
Quoted 5 lines
Quoted 5 lines
Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander
Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, RexQuoted 27 lines
Quoted 18 lines
Sasha
Quoted 17 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines
Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/84.18-stable review patch. If anyone has any objections, please let me
know.
Quoted 4 lines
Quoted 1 line
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.
Quoted 7 lines
Quoted 4 lines
There's no breakage in upstream. This patch addressed breakages in
4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.
Sorry, what statement about drm-next? This patch was for 4.19 and was
Quoted 8 lines
Quoted 6 lines
not intended for 4.18. It was picked up by Sasha's auto select system for stable.
I thought this thread said that.
Ok, so I should just revert it?
Yes, please.
Now reverted, thanks.
greg k-h
Sasha Levin
maintainerRe: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
In reply to Deucher, AlexanderQuoted 11 lines · Alexander
Quoted 11 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 5 lines
Quoted 2 lines
4.18-stable review patch. If anyone has any objections, please let me know.
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275
Hi Alex,
Thank you for the report.
I'm working on improving this process, I'd be very grateful if you could answer a few questions about this:
1. Is the same breakage seen upstream? (if so, it should be reverted there as well and we can grab the revert into -stable).
2. Does the issue reported by this patch ("pipes seem to hang with a 4k DP and 1080p HDMI display") exist in the 4.18 stable tree?
3. If not, could you briefly explain why?
The algorithm I use was very confident about this patch being stable material, and when I looked at it back then (and again now) I was very confident of the same. If I can understand where I was wrong I could improve my process.
Thank you!
RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 33 lines
-----Original Message-----
From: Sasha Levin <[email protected]>
Sent: Monday, October 8, 2018 10:49 AM
To: Deucher, Alexander <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>; linux- [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 12 lines · Alexander
Quoted 12 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8Quoted 1 line
Quoted 1 line
4.18-stable review patch. If anyone has any objections, please let me
know.
Quoted 4 lines
Quoted 1 line
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275Hi Alex,
Quoted 7 lines
Thank you for the report.
I'm working on improving this process, I'd be very grateful if you could answer a few questions about this:
1. Is the same breakage seen upstream? (if so, it should be reverted there as well and we can grab the revert into -stable).
No regression in 4.19 or -next.
Quoted 2 lines
2. Does the issue reported by this patch ("pipes seem to hang with a 4k DP and 1080p HDMI display") exist in the 4.18 stable tree?
I don't think so, but I'm not 100% sure. Harry, Rex do you know if this is a general issue or was it just fall out from the changes to the interface?
Quoted 1 line
3. If not, could you briefly explain why?
We refactored the interface between the power and display components and this patch fixed up some of that fallout due to the differences in units used in each component.
Quoted 5 lines
The algorithm I use was very confident about this patch being stable material, and when I looked at it back then (and again now) I was very confident of the same. If I can understand where I was wrong I could improve my process.
There are some other dependent patches required that were not flagged in the patch itself. IIRC, they were a bit big for stable.
Alex
Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8
Quoted 41 lines · Alexander
Quoted 33 lines
-----Original Message-----
From: Sasha Levin <[email protected]>
Sent: Monday, October 8, 2018 10:49 AM
To: Deucher, Alexander <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>; linux- [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8Quoted 12 lines · Alexander
Quoted 12 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8Quoted 1 line
Quoted 1 line
4.18-stable review patch. If anyone has any objections, please let me
know.
Quoted 4 lines
Quoted 1 line
This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275Hi Alex,
Quoted 7 lines
Thank you for the report.
I'm working on improving this process, I'd be very grateful if you could answer a few questions about this:
1. Is the same breakage seen upstream? (if so, it should be reverted there as well and we can grab the revert into -stable).
Quoted 7 lines
No regression in 4.19 or -next.
Quoted 2 lines
2. Does the issue reported by this patch ("pipes seem to hang with a 4k DP and 1080p HDMI display") exist in the 4.18 stable tree?
I don't think so, but I'm not 100% sure. Harry, Rex do you know if this is a general issue or was it just fall out from the changes to the interface?
It was intended to deal with fallout to smu7/8 caused by the change to move the kHz-to-10kHz-conversion from display to powerplay. I believe that conversion initially overlooked these blocks. Rex, please correct me if I'm wrong. You probably know more about this than I do.
So yes, I agree, it was never intended to be used without the change to drop the *10 in display code, which was done with this change:
commit 23ec3d1479fd79658cd52c47618d8ddd2f32550b
Author: Rex Zhu <[email protected]> Date: Mon Jun 18 18:15:15 2018 +0800
drm/amd/pp: Convert clock unit to KHz as defined
Convert clock unit 10KHz to KHz as the data sturct defined. e.g.
struct pp_clock_with_latency {
uint32_t clocks_in_khz;
uint32_t latency_in_us;
};
Meanwhile revert the same conversion in display side.
I don't see this change in the 4.18.y stable tree. I probably should've caught that with the initial 4.18-stable review patch.
Harry
Quoted 14 lines
Quoted 1 line
3. If not, could you briefly explain why?
We refactored the interface between the power and display components and this patch fixed up some of that fallout due to the differences in units used in each component.
Quoted 5 lines
The algorithm I use was very confident about this patch being stable material, and when I looked at it back then (and again now) I was very confident of the same. If I can understand where I was wrong I could improve my process.
There are some other dependent patches required that were not flagged in the patch itself. IIRC, they were a bit big for stable.
Alex
Greg Kroah-Hartman
maintainerPATCH 223/235 dmaengine: sh: rcar-dmac: avoid to write CHCR.TE to 1 if TCR is set to 0
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yoshihiro Shimoda <[email protected]>
[ Upstream commit 538603c6026ce769eec633bb79349f5f287519c7 ]
This patch fixes an issue that unexpected retransfering happens if TCR is set to 0 before rcar_dmac_sync_tcr() writes DE bit to the CHCR register. For example, sh-sci driver can reproduce this issue like below:
In rx_timer_fn(): /* CHCR DE bit may be set to 1 */
dmaengine_tx_status()
rcar_dmac_tx_status()
rcar_dmac_chan_get_residue()
rcar_dmac_sync_tcr() /* TCR is possible to be set to 0 */
According to the description of commit 73a47bd0da66 ("dmaengine:
rcar-dmac: use TCRB instead of TCR for residue"), "this buffered data will be transferred if CHCR::DE bit was cleared". So, this patch doesn't need to check TCRB register.
--- drivers/dma/sh/rcar-dmac.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/dma/sh/rcar-dmac.c +3 -2
@@ -774,8 +774,9 @@ static void rcar_dmac_sync_tcr(struct rc/* make sure all remaining data was flushed */ rcar_dmac_chcr_de_barrier (chan); -/* back DE */ -rcar_dmac_chan_write (chan,RCAR_DMACHCR , chcr); +/* back DE if remain data exists */ +if (rcar_dmac_chan_read (chan,RCAR_DMATCR )) +rcar_dmac_chan_write (chan,RCAR_DMACHCR , chcr); }static void rcar_dmac_chan_halt (struct rcar_dmac_chan *chan)
Greg Kroah-Hartman
maintainerPATCH 224/235 staging: fsl-dpaa2/eth: Fix DMA mapping direction
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ioana Radulescu <[email protected]>
[ Upstream commit 466bcdc1fa303be175c45d054bb00effc575033a ]
We are using DMA_FROM_DEVICE when mapping RX frame buffers, but DMA_BIDIRECTIONAL for unmap. Fix the direction for DMA unmapping operation.
--- drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c +1 -1
@@ -767,7 +767,7 @@ static void free_bufs(struct dpaa2_eth_pfor (i =0 ; i < count; i++) { vaddr =dpaa2_iova_to_virt (priv->iommu_domain, buf_array[i]);dma_unmap_single (dev, buf_array[i],DPAA2_ETH_RX_BUF_SIZE , -DMA_BIDIRECTIONAL ); +DMA_FROM_DEVICE );skb_free_frag (vaddr); } }
Greg Kroah-Hartman
maintainerPATCH 225/235 IB/nes: Fix a compiler warning
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <[email protected]>
[ Upstream commit 4c5743bc4fe3233cecc1c184a773c79c8ee45bbe ]
Avoid that the following compiler warning is reported when building with W=1:
drivers/infiniband/hw/nes/nes_hw.c:646:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
--- drivers/infiniband/hw/nes/nes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/hw/nes/nes.h +1 -1
@@ -159,7 +159,7 @@ do { \#define NES_EVENT_TIMEOUT 1200000#else -#define nes_debug(level, fmt, args...) +#define nes_debug(level, fmt, args...) do {} while (0)#define assert (expr) do {} while (0)#define NES_EVENT_TIMEOUT 100000
Greg Kroah-Hartman
maintainerPATCH 226/235 block/DAC960.c: fix defined but not used build warnings
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Randy Dunlap <[email protected]>
[ Upstream commit 3993e501bf853cce85c5114a704b86b8f486790c ]
Fix build warnings in DAC960.c when CONFIG_PROC_FS is not enabled by marking the unused functions as __maybe_unused.
../drivers/block/DAC960.c:6429:12: warning: 'dac960_proc_show' defined but not used [-Wunused-function] ../drivers/block/DAC960.c:6449:12: warning: 'dac960_initial_status_proc_show' defined but not used [-Wunused-function] ../drivers/block/DAC960.c:6456:12: warning: 'dac960_current_status_proc_show' defined but not used [-Wunused-function]
--- drivers/block/DAC960.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/block/DAC960.c +6 -3
@@ -21,6 +21,7 @@#define DAC960_DriverDate "21 Aug 2007" +#include <linux/compiler.h> #include <linux/module.h> #include <linux/types.h> #include <linux/miscdevice.h>
@@ -6426,7 +6427,7 @@ static bool DAC960_V2_ExecuteUserCommandreturn true; } -static int dac960_proc_show (struct seq_file *m,void *v) +static int __maybe_unused dac960_proc_show (struct seq_file *m,void *v) {unsigned char *StatusMessage ="OK\n" ;int ControllerNumber;
@@ -6446,14 +6447,16 @@ static int dac960_proc_show(struct seq_freturn 0 ; } -static int dac960_initial_status_proc_show (struct seq_file *m,void *v) +static int __maybe_unused dac960_initial_status_proc_show (struct seq_file *m, +void *v) {DAC960_Controller_T *Controller = (DAC960_Controller_T *)m->private;seq_printf (m,"%.*s" , Controller->InitialStatusLength, Controller->CombinedStatusBuffer);return 0 ; } -static int dac960_current_status_proc_show (struct seq_file *m,void *v) +static int __maybe_unused dac960_current_status_proc_show (struct seq_file *m, +void *v) {DAC960_Controller_T *Controller = (DAC960_Controller_T *) m->private; unsigned char *StatusMessage =
Greg Kroah-Hartman
maintainerPATCH 227/235 IB/mlx5: fix uaccess beyond "count" in debugfs read/write handlers
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
[ Upstream commit 60e6627f12a78203a093ca05b7bca15627747d81 ]
In general, accessing userspace memory beyond the length of the supplied buffer in VFS read/write handlers can lead to both kernel memory corruption (via kernel_read()/kernel_write(), which can e.g. be triggered via sys_splice()) and privilege escalation inside userspace.
In this case, the affected files are in debugfs (and should therefore only be accessible to root), and the read handlers check that *pos is zero (meaning that at least sys_splice() can't trigger kernel memory corruption). Because of the root requirement, this is not a security fix, but rather a cleanup.
For the read handlers, fix it by using simple_read_from_buffer() instead of custom logic. Add min() calls to the write handlers.
--- drivers/infiniband/hw/mlx5/cong.c | 9 +-------- drivers/infiniband/hw/mlx5/mr.c | 32 ++++++++------------------------ 2 files changed, 9 insertions(+), 32 deletions(-)
drivers/infiniband/hw/mlx5/cong.c +1 -8
@@ -359,9 +359,6 @@ static ssize_t get_param(struct file *fiint ret;char lbuf[11 ]; -if (*pos) -return 0 ; - ret =mlx5_ib_get_cc_params (param->dev, param->port_num, offset, &var);if (ret)return ret;
@@ -370,11 +367,7 @@ static ssize_t get_param(struct file *fiif (ret <0 )return ret; -if (copy_to_user (buf, lbuf, ret)) -return -EFAULT ; - - *pos += ret; -return ret; +return simple_read_from_buffer (buf, count, pos, lbuf, ret); }static const struct file_operations dbg_cc_fops = {
drivers/infiniband/hw/mlx5/mr.c +8 -24
@@ -271,16 +271,16 @@ static ssize_t size_write(struct file *f {struct mlx5_cache_ent *ent = filp->private_data;struct mlx5_ib_dev *dev = ent->dev; -char lbuf[20 ]; +char lbuf[20 ] = {0 };u32 var;int err;int c; -if (copy_from_user (lbuf, buf,sizeof (lbuf))) + count =min (count,sizeof (lbuf) -1 ); +if (copy_from_user (lbuf, buf, count))return -EFAULT ; c =order2idx (dev, ent->order); - lbuf[sizeof (lbuf) -1 ] =0 ;if (sscanf (lbuf,"%u" , &var) !=1 )return -EINVAL ;
@@ -310,19 +310,11 @@ static ssize_t size_read(struct file *fichar lbuf[20 ];int err; -if (*pos) -return 0 ; - err =snprintf (lbuf,sizeof (lbuf),"%d\n" , ent->size);if (err <0 )return err; -if (copy_to_user (buf, lbuf, err)) -return -EFAULT ; - - *pos += err; - -return err; +return simple_read_from_buffer (buf, count, pos, lbuf, err); }static const struct file_operations size_fops = {
@@ -337,16 +329,16 @@ static ssize_t limit_write(struct file * {struct mlx5_cache_ent *ent = filp->private_data;struct mlx5_ib_dev *dev = ent->dev; -char lbuf[20 ]; +char lbuf[20 ] = {0 };u32 var;int err;int c; -if (copy_from_user (lbuf, buf,sizeof (lbuf))) + count =min (count,sizeof (lbuf) -1 ); +if (copy_from_user (lbuf, buf, count))return -EFAULT ; c =order2idx (dev, ent->order); - lbuf[sizeof (lbuf) -1 ] =0 ;if (sscanf (lbuf,"%u" , &var) !=1 )return -EINVAL ;
@@ -372,19 +364,11 @@ static ssize_t limit_read(struct file *fchar lbuf[20 ];int err; -if (*pos) -return 0 ; - err =snprintf (lbuf,sizeof (lbuf),"%d\n" , ent->limit);if (err <0 )return err; -if (copy_to_user (buf, lbuf, err)) -return -EFAULT ; - - *pos += err; - -return err; +return simple_read_from_buffer (buf, count, pos, lbuf, err); }static const struct file_operations limit_fops = {
Greg Kroah-Hartman
maintainerPATCH 228/235 blk-mq: only attempt to merge bio if there is rq in sw queue
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Lei <[email protected]>
[ Upstream commit b04f50ab8a74129b3041a2836c33c916be3c6667 ]
Only attempt to merge bio iff the ctx->rq_list isn't empty, because:
1) for high-performance SSD, most of times dispatch may succeed, then there may be nothing left in ctx->rq_list, so don't try to merge over sw queue if it is empty, then we can save one acquiring of ctx->lock
2) we can't expect good merge performance on per-cpu sw queue, and missing one merge on sw queue won't be a big deal since tasks can be scheduled from one CPU to another.
--- block/blk-mq-sched.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
block/blk-mq-sched.c +2 -1
@@ -339,7 +339,8 @@ bool __blk_mq_sched_bio_merge(struct reqreturn e->type->ops.mq.bio_merge (hctx, bio); } -if (hctx->flags &BLK_MQ_F_SHOULD_MERGE ) { +if ((hctx->flags &BLK_MQ_F_SHOULD_MERGE ) && + !list_empty_careful (&ctx->rq_list)) {/* default per sw-queue merge */ spin_lock (&ctx->lock); ret =blk_mq_attempt_merge (q, ctx, bio);
Greg Kroah-Hartman
maintainerPATCH 229/235 blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Lei <[email protected]>
[ Upstream commit 1311326cf4755c7ffefd20f576144ecf46d9906b ]
SCSI probing may synchronously create and destroy a lot of request_queues for non-existent devices. Any synchronize_rcu() in queue creation or destroy path may introduce long latency during booting, see detailed description in comment of blk_register_queue().
This patch removes one synchronize_rcu() inside blk_cleanup_queue() for this case, commit c2856ae2f315d75(blk-mq: quiesce queue before freeing queue) needs synchronize_rcu() for implementing blk_mq_quiesce_queue(), but when queue isn't initialized, it isn't necessary to do that since only pass-through requests are involved, no original issue in scsi_execute() at all.
Without this patch and previous one, it may take more 20+ seconds for virtio-scsi to complete disk probe. With the two patches, the time becomes less than 100ms.
--- block/blk-core.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
block/blk-core.c +6 -2
@@ -791,9 +791,13 @@ void blk_cleanup_queue(struct request_qu* make sure all in-progress dispatch are completed because * blk_freeze_queue() can only complete all requests, and * dispatch may still be in-progress since we dispatch requests -* from more than one contexts +* from more than one contexts. +* +* No need to quiesce queue if it isn't initialized yet since +* blk_freeze_queue() should be enough for cases of passthrough +* request. */ -if (q->mq_ops) +if (q->mq_ops &&blk_queue_init_done (q))blk_mq_quiesce_queue (q);/* for synchronous bio-based driver finish in-flight integrity i/o */
Greg Kroah-Hartman
maintainerPATCH 230/235 gpiolib: Respect error code of ->get_direction()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
[ Upstream commit 36b312792b97933dc07abe074f50941199bd357c ]
In case we try to lock GPIO pin as IRQ when something going wrong we print a misleading message.
Correct this by checking an error code from ->get_direction() in gpiochip_lock_as_irq() and printing a corresponding message.
--- drivers/gpio/gpiolib.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/gpio/gpiolib.c +6 -0
@@ -3257,6 +3257,12 @@ int gpiochip_lock_as_irq(struct gpio_chiif (!chip->can_sleep && chip->get_direction) {int dir = chip->get_direction (chip, offset); +if (dir <0 ) { +chip_err (chip,"%s: cannot get GPIO direction\n" , + __func__); +return dir; + } +if (dir)clear_bit (FLAG_IS_OUT , &desc->flags);else
Greg Kroah-Hartman
maintainerPATCH 231/235 pinctrl: msm: Fix msm_config_group_get() to be compliant
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Anderson <[email protected]>
[ Upstream commit 05e0c828955c1cab58dd71a04539442e5375d917 ]
If you do this on an sdm845 board:
cat /sys/kernel/debug/pinctrl/3400000.pinctrl/pinconf-groups
...it looks like nonsense. For every pin you see listed:
input bias bus hold, input bias disabled, input bias pull down, input bias pull up
That's because msm_config_group_get() isn't complying with the rules that pinconf_generic_dump_one() expects. Specifically for boolean parameters (anything with a "struct pin_config_item" where has_arg is false) the function expects that the function should return its value not through the "config" parameter but should return "0" if the value is set and "-EINVAL" if the value isn't set.
Let's fix this.
Quoted 1 line
From a quick sample of other pinctrl drivers, it appears to be
tradition to also return 1 through the config parameter for these boolean parameters when they exist. I'm not one to knock tradition, so I'll follow tradition and return 1 in these cases. While I'm at it, I'll also continue searching for four leaf clovers, kocking on wood three times, and trying not to break mirrors.
--- drivers/pinctrl/qcom/pinctrl-msm.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/pinctrl/qcom/pinctrl-msm.c +11 -3
@@ -250,22 +250,30 @@ static int msm_config_group_get(struct p/* Convert register value to pinconf value */ switch (param) {case PIN_CONFIG_BIAS_DISABLE : - arg = arg ==MSM_NO_PULL ; +if (arg !=MSM_NO_PULL ) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_BIAS_PULL_DOWN : - arg = arg ==MSM_PULL_DOWN ; +if (arg !=MSM_PULL_DOWN ) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_BIAS_BUS_HOLD :if (pctrl->soc->pull_no_keeper)return -ENOTSUPP ; - arg = arg ==MSM_KEEPER ; +if (arg !=MSM_KEEPER ) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_BIAS_PULL_UP :if (pctrl->soc->pull_no_keeper) arg = arg ==MSM_PULL_UP_NO_KEEPER ;else arg = arg ==MSM_PULL_UP ; +if (!arg) +return -EINVAL ;break ;case PIN_CONFIG_DRIVE_STRENGTH : arg =msm_regval_to_drive (arg);
Greg Kroah-Hartman
maintainerPATCH 232/235 pinctrl: qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Anderson <[email protected]>
[ Upstream commit 1cf86bc21257a330e3af51f2a4e885f1a705f6a5 ]
If you do this on an sdm845 board:
grep "" /sys/kernel/debug/pinctrl/*spmi:pmic*/pinconf-groups
...it looks like nonsense. For every pin you see listed:
input bias disabled, input bias high impedance, input bias pull down, input bias pull up, ...
That's because pmic_gpio_config_get() isn't complying with the rules that pinconf_generic_dump_one() expects. Specifically for boolean parameters (anything with a "struct pin_config_item" where has_arg is false) the function expects that the function should return its value not through the "config" parameter but should return "0" if the value is set and "-EINVAL" if the value isn't set.
Let's fix this.
Quoted 1 line
From a quick sample of other pinctrl drivers, it appears to be
tradition to also return 1 through the config parameter for these boolean parameters when they exist. I'm not one to knock tradition, so I'll follow tradition and return 1 in these cases. While I'm at it, I'll also continue searching for four leaf clovers, kocking on wood three times, and trying not to break mirrors.
NOTE: This also fixes an apparent typo for reading PIN_CONFIG_BIAS_DISABLE where the old driver was accidentally using "=" instead of "==" and thus was setting some internal state when you tried to query PIN_CONFIG_BIAS_DISABLE. Oops.
--- drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 32 +++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-)
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c +24 -8
@@ -390,31 +390,47 @@ static int pmic_gpio_config_get(struct pswitch (param) {case PIN_CONFIG_DRIVE_PUSH_PULL : - arg = pad->buffer_type ==PMIC_GPIO_OUT_BUF_CMOS ; +if (pad->buffer_type !=PMIC_GPIO_OUT_BUF_CMOS ) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_DRIVE_OPEN_DRAIN : - arg = pad->buffer_type ==PMIC_GPIO_OUT_BUF_OPEN_DRAIN_NMOS ; +if (pad->buffer_type !=PMIC_GPIO_OUT_BUF_OPEN_DRAIN_NMOS ) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_DRIVE_OPEN_SOURCE : - arg = pad->buffer_type ==PMIC_GPIO_OUT_BUF_OPEN_DRAIN_PMOS ; +if (pad->buffer_type !=PMIC_GPIO_OUT_BUF_OPEN_DRAIN_PMOS ) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_BIAS_PULL_DOWN : - arg = pad->pullup ==PMIC_GPIO_PULL_DOWN ; +if (pad->pullup !=PMIC_GPIO_PULL_DOWN ) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_BIAS_DISABLE : - arg = pad->pullup =PMIC_GPIO_PULL_DISABLE ; +if (pad->pullup !=PMIC_GPIO_PULL_DISABLE ) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_BIAS_PULL_UP : - arg = pad->pullup ==PMIC_GPIO_PULL_UP_30 ; +if (pad->pullup !=PMIC_GPIO_PULL_UP_30 ) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_BIAS_HIGH_IMPEDANCE : - arg = !pad->is_enabled; +if (pad->is_enabled) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_POWER_SOURCE : arg = pad->power_source;break ;case PIN_CONFIG_INPUT_ENABLE : - arg = pad->input_enabled; +if (!pad->input_enabled) +return -EINVAL ; + arg =1 ;break ;case PIN_CONFIG_OUTPUT : arg = pad->out_value;
Greg Kroah-Hartman
maintainerPATCH 233/235 clk: tegra: bpmp: Dont crash when a clock fails to register
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikko Perttunen <[email protected]>
[ Upstream commit f7b3182232c82bb9769e2d5471d702bae2972d2b ]
When registering clocks, we just skip any that fail to register (leaving a NULL hole in the clock table). However, our of_xlate function still tries to dereference each entry while looking for the clock with the requested id, causing a crash if any clocks failed to register. Add a check to of_xlate to skip any NULL clocks.
--- drivers/clk/tegra/clk-bpmp.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/clk/tegra/clk-bpmp.c +9 -3
@@ -586,9 +586,15 @@ static struct clk_hw *tegra_bpmp_clk_of_unsigned int id = clkspec->args[0 ], i;struct tegra_bpmp *bpmp = data; -for (i =0 ; i < bpmp->num_clocks; i++) -if (bpmp->clocks[i]->id == id) -return &bpmp->clocks[i]->hw; +for (i =0 ; i < bpmp->num_clocks; i++) { +struct tegra_bpmp_clk *clk = bpmp->clocks[i]; + +if (!clk) +continue ; + +if (clk->id == id) +return &clk->hw; + }return NULL ; }
Greg Kroah-Hartman
maintainerPATCH 234/235 mei: bus: type promotion bug in mei_nfc_if_version()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit b40b3e9358fbafff6a4ba0f4b9658f6617146f9c upstream.
We accidentally removed the check for negative returns without considering the issue of type promotion.
The "if_version_length" variable is type size_t so if __mei_cl_recv() returns a negative then "bytes_recv" is type promoted
to a high positive value and treated as success.
--- drivers/misc/mei/bus-fixup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/misc/mei/bus-fixup.c +1 -1
@@ -267,7 +267,7 @@ static int mei_nfc_if_version(struct mei ret =0 ; bytes_recv =__mei_cl_recv (cl, (u8 *)reply, if_version_length,0 ); -if (bytes_recv < if_version_length) { +if (bytes_recv <0 || bytes_recv < if_version_length) {dev_err (bus->dev,"Could not read IF version\n" ); ret = -EIO ; goto err;
Greg Kroah-Hartman
maintainerPATCH 235/235 crypto: ccp - add timeout support in the SEV command
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brijesh Singh <[email protected]>
commit 3702a0585e64d70d5bf73bf3e943b8d6005b72c1 upstream.
Currently, the CCP driver assumes that the SEV command issued to the PSP will always return (i.e. it will never hang). But recently, firmware bugs have shown that a command can hang. Since of the SEV commands are used in probe routines, this can cause boot hangs and/or loss of virtualization capabilities.
To protect against firmware bugs, add a timeout in the SEV command execution flow. If a command does not complete within the specified timeout then return -ETIMEOUT and stop the driver from executing any further commands since the state of the SEV firmware is unknown.
--- drivers/crypto/ccp/psp-dev.c | 46 ++++++++++++++++++++++++++++++++++++++----- 1 file changed, 41 insertions(+), 5 deletions(-)
drivers/crypto/ccp/psp-dev.c +41 -5
@@ -38,6 +38,17 @@ static DEFINE_MUTEX(sev_cmd_mutex);static struct sev_misc_dev *misc_dev;static struct psp_device *psp_master; +static int psp_cmd_timeout =100 ; +module_param (psp_cmd_timeout, int,0644 ); +MODULE_PARM_DESC (psp_cmd_timeout," default timeout value, in seconds, for PSP commands" ); + +static int psp_probe_timeout =5 ; +module_param (psp_probe_timeout, int,0644 ); +MODULE_PARM_DESC (psp_probe_timeout," default timeout value, in seconds, during PSP device probe" ); + +static bool psp_dead; +static int psp_timeout; +static struct psp_device *psp_alloc_struct (struct sp_device *sp) {struct device *dev = sp->dev;
@@ -82,10 +93,19 @@ done:return IRQ_HANDLED ; } -static void sev_wait_cmd_ioc (struct psp_device *psp,unsigned int *reg) +static int sev_wait_cmd_ioc (struct psp_device *psp, +unsigned int *reg,unsigned int timeout) { -wait_event (psp->sev_int_queue, psp->sev_int_rcvd); +int ret; + + ret =wait_event_timeout (psp->sev_int_queue, + psp->sev_int_rcvd, timeout *HZ ); +if (!ret) +return -ETIMEDOUT ; + *reg =ioread32 (psp->io_regs +PSP_CMDRESP ); + +return 0 ; }static int sev_cmd_buffer_len (int cmd)
@@ -133,12 +153,15 @@ static int __sev_do_cmd_locked(int cmd,if (!psp)return -ENODEV ; +if (psp_dead) +return -EBUSY ; +/* Get the physical address of the command buffer */ phys_lsb = data ?lower_32_bits (__psp_pa (data)) :0 ; phys_msb = data ?upper_32_bits (__psp_pa (data)) :0 ; -dev_dbg (psp->dev,"sev command id %#x buffer 0x%08x%08x\n" , - cmd, phys_msb, phys_lsb); +dev_dbg (psp->dev,"sev command id %#x buffer 0x%08x%08x timeout %us\n" , + cmd, phys_msb, phys_lsb, psp_timeout);print_hex_dump_debug ("(in): " ,DUMP_PREFIX_OFFSET ,16 ,2 , data,sev_cmd_buffer_len (cmd), false);
@@ -154,7 +177,18 @@ static int __sev_do_cmd_locked(int cmd,iowrite32 (reg, psp->io_regs +PSP_CMDRESP );/* wait for command completion */ -sev_wait_cmd_ioc (psp, ®); + ret =sev_wait_cmd_ioc (psp, ®, psp_timeout); +if (ret) { +if (psp_ret) + *psp_ret =0 ; + +dev_err (psp->dev,"sev command %#x timed out, disabling PSP \n" , cmd); + psp_dead = true; + +return ret; + } + + psp_timeout = psp_cmd_timeout;if (psp_ret) *psp_ret = reg &PSP_CMDRESP_ERR_MASK ;
@@ -886,6 +920,8 @@ void psp_pci_init(void) psp_master = sp->psp_data; + psp_timeout = psp_probe_timeout; +if (sev_get_api_version ()) goto err;
Shuah Khan
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.10 release. There are 235 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 Wed Sep 26 11:30:01 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.18.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions since the last release I tested.
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.10 release. There are 235 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.
Quoted 8 lines
Responses should be made by Wed Sep 26 11:30:01 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.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.18.y
and the diffstat can be found below.
-rc2 is out to resolve some reported problems:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc2.gz
Quoted 15 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.10 release. There are 235 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 Wed Sep 26 11:30:01 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.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.18.y
and the diffstat can be found below.
Review
Quoted 2 lines
(quoted diff) +0
-1-rc2 is out to resolve some reported problems: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc2.gz
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.18.10-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.18.y
git commit: a728cc9e2683aba1752aa9a0aacae4bbfc1066d2
git describe: v4.18.9-232-ga728cc9e2683
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.9-232-ga728cc9e2683
No regressions (compared to build v4.18.9)
------------------------------------------------------------------------
Ran 16243 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-timers-tests
* ltp-syscalls-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 16 lines · Dan Rue
Quoted 15 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.10 release. There are 235 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 Wed Sep 26 11:30:01 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.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.18.y
and the diffstat can be found below.
Quoted 5 lines
Review
Quoted 2 lines
(quoted diff) +0
-1-rc2 is out to resolve some reported problems: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc2.gzResults from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.
Great, thanks for testing and glad to see the problem get fixed.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.10 release. There are 235 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 Wed Sep 26 11:30:01 UTC 2018. Anything received after that time might be too late.
Build results:
total: 137 pass: 137 fail: 0 Qemu test results: total: 318 pass: 317 fail: 1
Failed tests:
powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs
The failed test is the result of a crash in devicetree unittest code. It affects all branches. Nothing to worry about; fix is being worked on.
Details are available at https://kerneltests.org/builders/.
Guenter
Greg Kroah-Hartman
maintainerQuoted 11 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.10 release. There are 235 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 Wed Sep 26 11:30:01 UTC 2018. Anything received after that time might be too late.
Build results:
Quoted 8 lines
total: 137 pass: 137 fail: 0 Qemu test results: total: 318 pass: 317 fail: 1Failed tests:
powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfsThe failed test is the result of a crash in devicetree unittest code. It affects all branches. Nothing to worry about; fix is being worked on.
Thanks for testing all of these and letting me know.
greg k-h