5.0.20-stable review
Subsystems (12)
Greg Kroah-Hartman
maintainerPATCH 314/346 scsi: lpfc: Fix SLI3 commands being issued on SLI4 devices
In reply to Greg Kroah-Hartman[ Upstream commit c95a3b4b0fb8d351e2329a96f87c4fc96a149505 ]
During debug, it was seen that the driver is issuing commands specific to SLI3 on SLI4 devices. Although the adapter correctly rejected the command, this should not be done.
Revise the code to stop sending these commands on a SLI4 adapter.
--- drivers/scsi/lpfc/lpfc_hbadisc.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_hbadisc.c +10 -1
@@ -935,7 +935,11 @@ lpfc_linkdown(struct lpfc_hba *phba) } }lpfc_destroy_vport_work_array (phba, vports); -/* Clean up any firmware default rpi's */ + +/* Clean up any SLI3 firmware default rpi's */ +if (phba->sli_rev >LPFC_SLI_REV3 ) + goto skip_unreg_did; + mb =mempool_alloc (phba->mbox_mem_pool,GFP_KERNEL );if (mb) {lpfc_unreg_did (phba,0xffff ,LPFC_UNREG_ALL_DFLT_RPIS , mb);
@@ -947,6 +951,7 @@ lpfc_linkdown(struct lpfc_hba *phba) } } + skip_unreg_did:/* Setup myDID for link up if we are in pt2pt mode */ if (phba->pport->fc_flag &FC_PT2PT ) { mb =mempool_alloc (phba->mbox_mem_pool,GFP_KERNEL );
@@ -4985,6 +4990,10 @@ lpfc_unreg_default_rpis(struct lpfc_vport *vport)LPFC_MBOXQ_t *mbox;int rc; +/* Unreg DID is an SLI3 operation. */ +if (phba->sli_rev >LPFC_SLI_REV3 ) +return ; + mbox =mempool_alloc (phba->mbox_mem_pool,GFP_KERNEL );if (mbox) { lpfc_unreg_did(phba, vport->vpi, LPFC_UNREG_ALL_DFLT_RPIS,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 315/346 scsi: lpfc: Fix use-after-free mailbox cmd completion
In reply to Greg Kroah-Hartman[ Upstream commit 9b1640686470fbbd1c6efb35ada6fe1427ea8d0f ]
When unloading the driver, mailbox commands may be sent without holding a reference on the ndlp. By the time the mailbox command completes, the ndlp may have reduced its ref counts and been freed. The problem was reported by KASAN.
While unregistering due to driver unload, have the completion noop'd by setting the ndlp context NULL'd. Due to the unload, no further action was necessary. Also, while reviewing this path, the generic nulling of the context after handling should be slightly moved.
Reported by: Bart Van Assche <[email protected]>
--- drivers/scsi/lpfc/lpfc_hbadisc.c | 4 ++++ drivers/scsi/lpfc/lpfc_sli.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_hbadisc.c +4 -0
@@ -4879,6 +4879,10 @@ lpfc_unreg_rpi(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp)* accept PLOGIs after unreg_rpi_cmpl */ acc_plogi =0 ; + }else if (vport->load_flag &FC_UNLOADING ) { + mbox->ctx_ndlp =NULL ; + mbox->mbox_cmpl = + lpfc_sli_def_mbox_cmpl; }else { mbox->ctx_ndlp = ndlp; mbox->mbox_cmpl =
drivers/scsi/lpfc/lpfc_sli.c +1 -1
@@ -2518,8 +2518,8 @@ lpfc_sli_def_mbox_cmpl(struct lpfc_hba *phba, LPFC_MBOXQ_t *pmb) }else { ndlp->nlp_flag &= ~NLP_UNREG_INP ; } + pmb->ctx_ndlp =NULL ; } - pmb->ctx_ndlp =NULL ; }/* Check security permission status on INIT_LINK mailbox command */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 316/346 audit: fix a memleak caused by auditing load module
In reply to Greg Kroah-Hartman[ Upstream commit 95e0b46fcebd7dbf6850dee96046e4c4ddc7f69c ]
module.name will be allocated unconditionally when auditing load module, and audit_log_start() can fail with other reasons, or audit_log_exit maybe not called, caused module.name is not freed
so free module.name in audit_free_context and __audit_syscall_exit
unreferenced object 0xffff88af90837d20 (size 8):
comm "modprobe", pid 1036, jiffies 4294704867 (age 3069.138s) hex dump (first 8 bytes):
69 78 67 62 65 00 ff ff ixgbe...
backtrace:
[<0000000008da28fe>] __audit_log_kern_module+0x33/0x80
[<00000000c1491e61>] load_module+0x64f/0x3850
[<000000007fc9ae3f>] __do_sys_init_module+0x218/0x250
[<0000000000d4a478>] do_syscall_64+0x117/0x400
[<000000004924ded8>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[<000000007dc331dd>] 0xffffffffffffffff--- kernel/auditsc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
kernel/auditsc.c +9 -1
@@ -837,6 +837,13 @@ static inline void audit_proctitle_free(struct audit_context *context) context->proctitle.len =0 ; } +static inline void audit_free_module (struct audit_context *context) +{ +if (context->type ==AUDIT_KERN_MODULE ) { +kfree (context->module.name); + context->module.name =NULL ; + } +}static inline void audit_free_names (struct audit_context *context) {struct audit_names *n, *next;
@@ -920,6 +927,7 @@ int audit_alloc(struct task_struct *tsk)static inline void audit_free_context (struct audit_context *context) { +audit_free_module (context);audit_free_names (context);unroll_tree_refs (context,NULL ,0 );free_tree_refs (context);
@@ -1237,7 +1245,6 @@ static void show_special(struct audit_context *context, int *call_panic)audit_log_format (ab,"name=" );if (context->module.name) {audit_log_untrustedstring (ab, context->module.name); -kfree (context->module.name); }else audit_log_format (ab,"(null)" );
@@ -1574,6 +1581,7 @@ void __audit_syscall_exit(int success, long return_code) context->in_syscall =0 ; context->prio = context->state ==AUDIT_RECORD_CONTEXT ? ~0ULL :0 ; +audit_free_module (context);audit_free_names (context);unroll_tree_refs (context,NULL ,0 );audit_free_aux (context);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 317/346 spi : spi-topcliff-pch: Fix to handle empty DMA buffers
In reply to Greg Kroah-Hartman[ Upstream commit f37d8e67f39e6d3eaf4cc5471e8a3d21209843c6 ]
pch_alloc_dma_buf allocated tx, rx DMA buffers which can fail. Further, these buffers are used without a check. The patch checks for these failures and sends the error upstream.
--- drivers/spi/spi-topcliff-pch.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/spi/spi-topcliff-pch.c +13 -2
@@ -1294,18 +1294,27 @@ static void pch_free_dma_buf(struct pch_spi_board_data *board_dat, dma->rx_buf_virt, dma->rx_buf_dma); } -static void pch_alloc_dma_buf (struct pch_spi_board_data *board_dat, +static int pch_alloc_dma_buf (struct pch_spi_board_data *board_dat,struct pch_spi_data *data) {struct pch_spi_dma_ctrl *dma; +int ret; dma = &data->dma; + ret =0 ;/* Get Consistent memory for Tx DMA */ dma->tx_buf_virt =dma_alloc_coherent (&board_dat->pdev->dev,PCH_BUF_SIZE , &dma->tx_buf_dma,GFP_KERNEL ); +if (!dma->tx_buf_virt) + ret = -ENOMEM ; +/* Get Consistent memory for Rx DMA */ dma->rx_buf_virt =dma_alloc_coherent (&board_dat->pdev->dev,PCH_BUF_SIZE , &dma->rx_buf_dma,GFP_KERNEL ); +if (!dma->rx_buf_virt) + ret = -ENOMEM ; + +return ret; }static int pch_spi_pd_probe (struct platform_device *plat_dev)
@@ -1382,7 +1391,9 @@ static int pch_spi_pd_probe(struct platform_device *plat_dev)if (use_dma) {dev_info (&plat_dev->dev,"Use DMA for data transfers\n" ); -pch_alloc_dma_buf (board_dat, data); + ret =pch_alloc_dma_buf (board_dat, data); +if (ret) + goto err_spi_register_master; } ret =spi_register_master (master);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 318/346 drm: writeback: Fix leak of writeback job
In reply to Greg Kroah-Hartman[ Upstream commit e482ae9b5fdc01a343f22f52930e85a6cfdf85eb ]
Writeback jobs are allocated when the WRITEBACK_FB_ID is set, and deleted when the jobs complete. This results in both a memory leak of the job and a leak of the framebuffer if the atomic commit returns before the job is queued for processing, for instance if the atomic check fails or if the commit runs in test-only mode.
Fix this by implementing the drm_writeback_cleanup_job() function and calling it from __drm_atomic_helper_connector_destroy_state(). As writeback jobs are removed from the state when they're queued for processing, any job left in the state when the state gets destroyed needs to be cleaned up.
The existing declaration of the drm_writeback_cleanup_job() function without an implementation hints that this problem was considered, but never addressed.
--- drivers/gpu/drm/drm_atomic_state_helper.c | 4 ++++ drivers/gpu/drm/drm_writeback.c | 14 +++++++++++--- 2 files changed, 15 insertions(+), 3 deletions(-)
drivers/gpu/drm/drm_atomic_state_helper.c +4 -0
@@ -30,6 +30,7 @@#include <drm/drm_connector.h> #include <drm/drm_atomic.h> #include <drm/drm_device.h> +#include <drm/drm_writeback.h> #include <linux/slab.h> #include <linux/dma-fence.h>
@@ -412,6 +413,9 @@ __drm_atomic_helper_connector_destroy_state(struct drm_connector_state *state)if (state->commit)drm_crtc_commit_put (state->commit); + +if (state->writeback_job) +drm_writeback_cleanup_job (state->writeback_job); }EXPORT_SYMBOL (__drm_atomic_helper_connector_destroy_state);
drivers/gpu/drm/drm_writeback.c +11 -3
@@ -268,6 +268,15 @@ void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector, }EXPORT_SYMBOL (drm_writeback_queue_job); +void drm_writeback_cleanup_job (struct drm_writeback_job *job) +{ +if (job->fb) +drm_framebuffer_put (job->fb); + +kfree (job); +} +EXPORT_SYMBOL (drm_writeback_cleanup_job); +/* * @cleanup_work: deferred cleanup of a writeback job *
@@ -280,10 +289,9 @@ static void cleanup_work(struct work_struct *work)struct drm_writeback_job *job =container_of (work, struct drm_writeback_job, cleanup_work); -drm_framebuffer_put (job->fb); -kfree (job); -} +drm_writeback_cleanup_job (job); +}/** * drm_writeback_signal_completion - Signal the completion of a writeback job
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 319/346 drm/omap: dsi: Fix PM for display blank with paired dss_pll calls
In reply to Greg Kroah-Hartman[ Upstream commit fe4ed1b457943113ee1138c939fbdeede4af6cf3 ]
Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves the DSS clocks enabled when the display is blanked wasting about extra 5mW of power while idle.
The clock that is left on by not calling dss_pll_disable() is DSS_CLKCTRL bit 10 OPTFCLKEN_SYS_CLK that is the source clock for DSI PLL.
We can fix this issue by by making the current dsi_pll_uninit() into dsi_pll_disable(). This way we can just call dss_pll_disable() from dsi_display_uninit_dsi() and the code becomes a bit easier to follow.
However, we need to also consider that DSI PLL can be muxed for DVI too as pointed out by Tomi Valkeinen <[email protected]>. In the DVI case, we want to unconditionally disable the clocks. To get around this issue, we separate out the DSI lane handling from dsi_pll_enable() and dsi_pll_disable() as suggested by Tomi in an earlier experimental patch.
So we must only toggle the DSI regulator based on the vdds_dsi_enabled flag from dsi_display_init_dsi() and dsi_display_uninit_dsi().
We need to make these two changes together to avoid breaking things for DVI when fixing the DSI clock handling. And this all causes a slight renumbering of the error path for dsi_display_init_dsi().
--- drivers/gpu/drm/omapdrm/dss/dsi.c | 60 ++++++++++++++++--------------- 1 file changed, 31 insertions(+), 29 deletions(-)
drivers/gpu/drm/omapdrm/dss/dsi.c +31 -29
@@ -1342,12 +1342,9 @@ static int dsi_pll_enable(struct dss_pll *pll)*/ dsi_enable_scp_clk (dsi); -if (!dsi->vdds_dsi_enabled) { - r =regulator_enable (dsi->vdds_dsi_reg); -if (r) - goto err0; - dsi->vdds_dsi_enabled = true; - } + r =regulator_enable (dsi->vdds_dsi_reg); +if (r) + goto err0;/* XXX PLL does not come out of reset without this... */ dispc_pck_free_enable (dsi->dss->dispc,1 );
@@ -1372,36 +1369,25 @@ static int dsi_pll_enable(struct dss_pll *pll)return 0 ; err1: -if (dsi->vdds_dsi_enabled) { -regulator_disable (dsi->vdds_dsi_reg); - dsi->vdds_dsi_enabled = false; - } +regulator_disable (dsi->vdds_dsi_reg); err0:dsi_disable_scp_clk (dsi);dsi_runtime_put (dsi);return r; } -static void dsi_pll_uninit (struct dsi_data *dsi,bool disconnect_lanes) +static void dsi_pll_disable (struct dss_pll *pll) { + struct dsi_data *dsi = container_of(pll, struct dsi_data, pll); +dsi_pll_power (dsi,DSI_PLL_POWER_OFF ); -if (disconnect_lanes) { -WARN_ON (!dsi->vdds_dsi_enabled); -regulator_disable (dsi->vdds_dsi_reg); - dsi->vdds_dsi_enabled = false; - } + +regulator_disable (dsi->vdds_dsi_reg);dsi_disable_scp_clk (dsi);dsi_runtime_put (dsi); -DSSDBG ("PLL uninit done\n" ); -} - -static void dsi_pll_disable (struct dss_pll *pll) -{ - struct dsi_data *dsi = container_of(pll, struct dsi_data, pll); - -dsi_pll_uninit (dsi, true); +DSSDBG ("PLL disable done\n" ); }static int dsi_dump_dsi_clocks (struct seq_file *s,void *p)
@@ -4096,11 +4082,11 @@ static int dsi_display_init_dsi(struct dsi_data *dsi) r =dss_pll_enable (&dsi->pll);if (r) - goto err0; +return r; r =dsi_configure_dsi_clocks (dsi);if (r) - goto err1; + goto err0; dss_select_dsi_clk_source(dsi->dss, dsi->module_id, dsi->module_id == 0 ?
@@ -4108,6 +4094,14 @@ static int dsi_display_init_dsi(struct dsi_data *dsi)DSSDBG ("PLL OK\n" ); +if (!dsi->vdds_dsi_enabled) { + r =regulator_enable (dsi->vdds_dsi_reg); +if (r) + goto err1; + + dsi->vdds_dsi_enabled = true; + } + r =dsi_cio_init (dsi);if (r) goto err2;
@@ -4136,10 +4130,13 @@ static int dsi_display_init_dsi(struct dsi_data *dsi) err3:dsi_cio_uninit (dsi); err2: -dss_select_dsi_clk_source (dsi->dss, dsi->module_id,DSS_CLK_SRC_FCK ); +regulator_disable (dsi->vdds_dsi_reg); + dsi->vdds_dsi_enabled = false; err1: -dss_pll_disable (&dsi->pll); +dss_select_dsi_clk_source (dsi->dss, dsi->module_id,DSS_CLK_SRC_FCK ); err0: +dss_pll_disable (&dsi->pll); +return r; }
@@ -4158,7 +4155,12 @@ static void dsi_display_uninit_dsi(struct dsi_data *dsi, bool disconnect_lanes,dss_select_dsi_clk_source (dsi->dss, dsi->module_id,DSS_CLK_SRC_FCK );dsi_cio_uninit (dsi); -dsi_pll_uninit (dsi, disconnect_lanes); +dss_pll_disable (&dsi->pll); + +if (disconnect_lanes) { +regulator_disable (dsi->vdds_dsi_reg); + dsi->vdds_dsi_enabled = false; + } }static int dsi_display_enable (struct omap_dss_device *dssdev)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 320/346 drm/omap: Notify all devices in the pipeline of output disconnection
In reply to Greg Kroah-Hartman[ Upstream commit 27a7e3e18419869cdcc414a404f3fe66f1b4e644 ]
For HDMI pipelines, when the output gets disconnected the device handling CEC needs to be notified. Instead of guessing which device that would be (and sometimes getting it wrong), notify all devices in the pipeline.
--- drivers/gpu/drm/omapdrm/omap_connector.c | 28 ++++++++++++++---------- 1 file changed, 16 insertions(+), 12 deletions(-)
drivers/gpu/drm/omapdrm/omap_connector.c +16 -12
@@ -36,18 +36,22 @@ struct omap_connector { };static void omap_connector_hpd_notify (struct drm_connector *connector, -struct omap_dss_device *src,enum drm_connector_status status) { -if (status == connector_status_disconnected) { -/* -* If the source is an HDMI encoder, notify it of disconnection. -* This is required to let the HDMI encoder reset any internal -* state related to connection status, such as the CEC address. -*/ -if (src && src->type ==OMAP_DISPLAY_TYPE_HDMI && - src->ops->hdmi.lost_hotplug) - src->ops->hdmi.lost_hotplug (src); +struct omap_connector *omap_connector =to_omap_connector (connector); +struct omap_dss_device *dssdev; + +if (status != connector_status_disconnected) +return ; + +/* +* Notify all devics in the pipeline of disconnection. This is required +* to let the HDMI encoders reset their internal state related to +* connection status, such as the CEC address. +*/ +for (dssdev = omap_connector->output; dssdev; dssdev = dssdev->next) { +if (dssdev->ops && dssdev->ops->hdmi.lost_hotplug) + dssdev->ops->hdmi.lost_hotplug (dssdev); } }
@@ -67,7 +71,7 @@ static void omap_connector_hpd_cb(void *cb_data,if (old_status == status)return ; -omap_connector_hpd_notify (connector, omap_connector->hpd, status); +omap_connector_hpd_notify (connector, status);drm_kms_helper_hotplug_event (dev); }
@@ -128,7 +132,7 @@ static enum drm_connector_status omap_connector_detect( ? connector_status_connected : connector_status_disconnected; -omap_connector_hpd_notify (connector, dssdev->src, status); +omap_connector_hpd_notify (connector, status); }else {switch (omap_connector->display->type) {case OMAP_DISPLAY_TYPE_DPI :
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 321/346 spi: rspi: Fix sequencer reset during initialization
In reply to Greg Kroah-Hartman[ Upstream commit 26843bb128590edd7eba1ad7ce22e4b9f1066ce3 ]
While the sequencer is reset after each SPI message since commit 880c6d114fd79a69 ("spi: rspi: Add support for Quad and Dual SPI Transfers on QSPI"), it was never reset for the first message, thus relying on reset state or bootloader settings.
Fix this by initializing it explicitly during configuration.
--- drivers/spi/spi-rspi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/spi/spi-rspi.c +6 -3
@@ -271,7 +271,8 @@ static int rspi_set_config_register(struct rspi_data *rspi, int access_size)/* Sets parity, interrupt mask */ rspi_write8 (rspi,0x00 ,RSPI_SPCR2 ); -/* Sets SPCMD */ +/* Resets sequencer */ +rspi_write8 (rspi,0 ,RSPI_SPSCR ); rspi->spcmd |=SPCMD_SPB_8_TO_16 (access_size);rspi_write16 (rspi, rspi->spcmd,RSPI_SPCMD0 );
@@ -315,7 +316,8 @@ static int rspi_rz_set_config_register(struct rspi_data *rspi, int access_size)rspi_write8 (rspi,0x00 ,RSPI_SSLND );rspi_write8 (rspi,0x00 ,RSPI_SPND ); -/* Sets SPCMD */ +/* Resets sequencer */ +rspi_write8 (rspi,0 ,RSPI_SPSCR ); rspi->spcmd |=SPCMD_SPB_8_TO_16 (access_size);rspi_write16 (rspi, rspi->spcmd,RSPI_SPCMD0 );
@@ -366,7 +368,8 @@ static int qspi_set_config_register(struct rspi_data *rspi, int access_size)/* Sets buffer to allow normal operation */ rspi_write8 (rspi,0x00 ,QSPI_SPBFCR ); -/* Sets SPCMD */ +/* Resets sequencer */ +rspi_write8 (rspi,0 ,RSPI_SPSCR );rspi_write16 (rspi, rspi->spcmd,RSPI_SPCMD0 );/* Sets RSPI mode */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 322/346 regulator: wm831x ldo: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 8be64b6d87bd47d81753b60ddafe70102ebfd76b ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/wm831x-ldo.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/regulator/wm831x-ldo.c +2 -0
@@ -51,9 +51,11 @@ static irqreturn_t wm831x_ldo_uv_irq(int irq, void *data) {struct wm831x_ldo *ldo = data; +regulator_lock (ldo->regulator);regulator_notifier_call_chain (ldo->regulator,REGULATOR_EVENT_UNDER_VOLTAGE ,NULL ); +regulator_unlock (ldo->regulator);return IRQ_HANDLED ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 323/346 regulator: wm831x isink: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit f7a621728a6a23bfd2c6ac4d3e42e1303aefde0f ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/wm831x-isink.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/regulator/wm831x-isink.c +2 -0
@@ -140,9 +140,11 @@ static irqreturn_t wm831x_isink_irq(int irq, void *data) {struct wm831x_isink *isink = data; +regulator_lock (isink->regulator);regulator_notifier_call_chain (isink->regulator,REGULATOR_EVENT_OVER_CURRENT ,NULL ); +regulator_unlock (isink->regulator);return IRQ_HANDLED ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 324/346 regulator: ltc3676: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 769fc8d4182c1d1875db7859852afeb436714c5c ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/ltc3676.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/regulator/ltc3676.c +8 -2
@@ -338,17 +338,23 @@ static irqreturn_t ltc3676_isr(int irq, void *dev_id)if (irqstat <C3676_IRQSTAT_THERMAL_WARN ) {dev_warn (dev,"Over-temperature Warning\n" ); event =REGULATOR_EVENT_OVER_TEMP ; -for (i =0 ; i <LTC3676_NUM_REGULATORS ; i++) +for (i =0 ; i <LTC3676_NUM_REGULATORS ; i++) { +regulator_lock (ltc3676->regulators[i]);regulator_notifier_call_chain (ltc3676->regulators[i], event,NULL ); +regulator_unlock (ltc3676->regulators[i]); + } }if (irqstat <C3676_IRQSTAT_UNDERVOLT_WARN ) {dev_info (dev,"Undervoltage Warning\n" ); event =REGULATOR_EVENT_UNDER_VOLTAGE ; -for (i =0 ; i <LTC3676_NUM_REGULATORS ; i++) +for (i =0 ; i <LTC3676_NUM_REGULATORS ; i++) { +regulator_lock (ltc3676->regulators[i]);regulator_notifier_call_chain (ltc3676->regulators[i], event,NULL ); +regulator_unlock (ltc3676->regulators[i]); + } }/* Clear warning condition */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 325/346 regulator: ltc3589: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit f132da2534ec6599c78c4adcef15340cff2e9dd9 ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/ltc3589.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/regulator/ltc3589.c +8 -2
@@ -419,16 +419,22 @@ static irqreturn_t ltc3589_isr(int irq, void *dev_id)if (irqstat <C3589_IRQSTAT_THERMAL_WARN ) { event =REGULATOR_EVENT_OVER_TEMP ; -for (i =0 ; i <LTC3589_NUM_REGULATORS ; i++) +for (i =0 ; i <LTC3589_NUM_REGULATORS ; i++) { +regulator_lock (ltc3589->regulators[i]);regulator_notifier_call_chain (ltc3589->regulators[i], event,NULL ); +regulator_unlock (ltc3589->regulators[i]); + } }if (irqstat <C3589_IRQSTAT_UNDERVOLT_WARN ) { event =REGULATOR_EVENT_UNDER_VOLTAGE ; -for (i =0 ; i <LTC3589_NUM_REGULATORS ; i++) +for (i =0 ; i <LTC3589_NUM_REGULATORS ; i++) { +regulator_lock (ltc3589->regulators[i]);regulator_notifier_call_chain (ltc3589->regulators[i], event,NULL ); +regulator_unlock (ltc3589->regulators[i]); + } }/* Clear warning condition */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 326/346 regulator: pv88060: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit f58213637206e190453e3bd91f98f535566290a3 ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/pv88060-regulator.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/regulator/pv88060-regulator.c +4 -0
@@ -276,9 +276,11 @@ static irqreturn_t pv88060_irq_handler(int irq, void *data)if (reg_val &PV88060_E_VDD_FLT ) {for (i =0 ; i <PV88060_MAX_REGULATORS ; i++) {if (chip->rdev[i] !=NULL ) { +regulator_lock (chip->rdev[i]);regulator_notifier_call_chain (chip->rdev[i],REGULATOR_EVENT_UNDER_VOLTAGE ,NULL ); +regulator_unlock (chip->rdev[i]); } }
@@ -293,9 +295,11 @@ static irqreturn_t pv88060_irq_handler(int irq, void *data)if (reg_val &PV88060_E_OVER_TEMP ) {for (i =0 ; i <PV88060_MAX_REGULATORS ; i++) {if (chip->rdev[i] !=NULL ) { +regulator_lock (chip->rdev[i]);regulator_notifier_call_chain (chip->rdev[i],REGULATOR_EVENT_OVER_TEMP ,NULL ); +regulator_unlock (chip->rdev[i]); } }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 327/346 spi: imx: stop buffer overflow in RX FIFO flush
In reply to Greg Kroah-Hartman[ Upstream commit c842749ea1d32513f9e603c074d60d7aa07cb2ef ]
Commit 71abd29057cb ("spi: imx: Add support for SPI Slave mode") added an RX FIFO flush before start of a transfer. In slave mode, the master may have sent more data than expected and this data will still be in the RX FIFO at the start of the next transfer, and so needs to be flushed.
However, the code to do the flush was accidentally saving this data into the previous transfer's RX buffer, clobbering the contents of whatever followed that buffer.
Change it to empty the FIFO and throw away the data. Every one of the RX functions for the different eCSPI versions and modes reads the RX FIFO data using the same readl() call, so just use that, rather than using the spi_imx->rx function pointer and making sure all the different rx functions have a working "throw away" mode.
There is another issue, which affects master mode when switching from DMA to PIO. There can be extra data in the RX FIFO which triggers this flush code, causing memory corruption in the same manner. I don't know why this data is unexpectedly in the FIFO. It's likely there is a different bug or erratum responsible for that. But regardless of that, I think this is proper fix the for bug at hand here.
--- drivers/spi/spi-imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-imx.c +1 -1
@@ -1494,7 +1494,7 @@ static int spi_imx_transfer(struct spi_device *spi,/* flush rxfifo before transfer */ while (spi_imx->devtype_data->rx_available (spi_imx)) - spi_imx->rx (spi_imx); +readl (spi_imx->base +MXC_CSPIRXDATA );if (spi_imx->slave_mode)return spi_imx_pio_transfer_slave (spi, transfer);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 328/346 regulator: lp8755: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 89b2758c192c35068b07766a6830433bfbdc1f44 ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/lp8755.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
drivers/regulator/lp8755.c +12 -3
@@ -372,10 +372,13 @@ static irqreturn_t lp8755_irq_handler(int irq, void *data)for (icnt =0 ; icnt <LP8755_BUCK_MAX ; icnt++)if ((flag0 & (0x4 << icnt)) && (pchip->irqmask & (0x04 << icnt)) - && (pchip->rdev[icnt] !=NULL )) + && (pchip->rdev[icnt] !=NULL )) { +regulator_lock (pchip->rdev[icnt]);regulator_notifier_call_chain (pchip->rdev[icnt],LP8755_EVENT_PWR_FAULT ,NULL ); +regulator_unlock (pchip->rdev[icnt]); + }/* read flag1 register */ ret =lp8755_read (pchip,0x0E , &flag1);
@@ -389,18 +392,24 @@ static irqreturn_t lp8755_irq_handler(int irq, void *data)/* send OCP event to all regualtor devices */ if ((flag1 &0x01 ) && (pchip->irqmask &0x01 ))for (icnt =0 ; icnt <LP8755_BUCK_MAX ; icnt++) -if (pchip->rdev[icnt] !=NULL ) +if (pchip->rdev[icnt] !=NULL ) { +regulator_lock (pchip->rdev[icnt]);regulator_notifier_call_chain (pchip->rdev[icnt],LP8755_EVENT_OCP ,NULL ); +regulator_unlock (pchip->rdev[icnt]); + }/* send OVP event to all regualtor devices */ if ((flag1 &0x02 ) && (pchip->irqmask &0x02 ))for (icnt =0 ; icnt <LP8755_BUCK_MAX ; icnt++) -if (pchip->rdev[icnt] !=NULL ) +if (pchip->rdev[icnt] !=NULL ) { +regulator_lock (pchip->rdev[icnt]);regulator_notifier_call_chain (pchip->rdev[icnt],LP8755_EVENT_OVP ,NULL ); +regulator_unlock (pchip->rdev[icnt]); + }return IRQ_HANDLED ; err_i2c:
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 329/346 regulator: da9211: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 65378de3359d30ebce44762d8b8027f372b5b1c4 ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/da9211-regulator.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/regulator/da9211-regulator.c +4 -0
@@ -322,8 +322,10 @@ static irqreturn_t da9211_irq_handler(int irq, void *data) goto error_i2c;if (reg_val &DA9211_E_OV_CURR_A ) { +regulator_lock (chip->rdev[0 ]);regulator_notifier_call_chain (chip->rdev[0 ],REGULATOR_EVENT_OVER_CURRENT ,NULL ); +regulator_unlock (chip->rdev[0 ]); err =regmap_write (chip->regmap,DA9211_REG_EVENT_B ,DA9211_E_OV_CURR_A );
@@ -334,8 +336,10 @@ static irqreturn_t da9211_irq_handler(int irq, void *data) }if (reg_val &DA9211_E_OV_CURR_B ) { +regulator_lock (chip->rdev[1 ]);regulator_notifier_call_chain (chip->rdev[1 ],REGULATOR_EVENT_OVER_CURRENT ,NULL ); +regulator_unlock (chip->rdev[1 ]); err =regmap_write (chip->regmap,DA9211_REG_EVENT_B ,DA9211_E_OV_CURR_B );
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 330/346 regulator: da9063: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 29d40b4a5776ec4727c9f0e00a884423dd5e3366 ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/da9063-regulator.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/regulator/da9063-regulator.c +4 -1
@@ -615,9 +615,12 @@ static irqreturn_t da9063_ldo_lim_event(int irq, void *data)if (regl->info->oc_event.reg !=DA9063_REG_STATUS_D )continue ; -if (BIT (regl->info->oc_event.lsb) & bits) +if (BIT (regl->info->oc_event.lsb) & bits) { +regulator_lock (regl->rdev);regulator_notifier_call_chain (regl->rdev,REGULATOR_EVENT_OVER_CURRENT ,NULL ); +regulator_unlock (regl->rdev); + } }return IRQ_HANDLED ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 331/346 regulator: pv88080: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 1867af94cfdf37fc70fe67b3d522e78352800196 ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/pv88080-regulator.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/regulator/pv88080-regulator.c +4 -0
@@ -384,9 +384,11 @@ static irqreturn_t pv88080_irq_handler(int irq, void *data)if (reg_val &PV88080_E_VDD_FLT ) {for (i =0 ; i <PV88080_MAX_REGULATORS ; i++) {if (chip->rdev[i] !=NULL ) { +regulator_lock (chip->rdev[i]);regulator_notifier_call_chain (chip->rdev[i],REGULATOR_EVENT_UNDER_VOLTAGE ,NULL ); +regulator_unlock (chip->rdev[i]); } }
@@ -401,9 +403,11 @@ static irqreturn_t pv88080_irq_handler(int irq, void *data)if (reg_val &PV88080_E_OVER_TEMP ) {for (i =0 ; i <PV88080_MAX_REGULATORS ; i++) {if (chip->rdev[i] !=NULL ) { +regulator_lock (chip->rdev[i]);regulator_notifier_call_chain (chip->rdev[i],REGULATOR_EVENT_OVER_TEMP ,NULL ); +regulator_unlock (chip->rdev[i]); } }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 332/346 regulator: wm831x: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 119c4f5085c45b60cb23c5595e45d06135b89518 ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/wm831x-dcdc.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/regulator/wm831x-dcdc.c +4 -0
@@ -183,9 +183,11 @@ static irqreturn_t wm831x_dcdc_uv_irq(int irq, void *data) {struct wm831x_dcdc *dcdc = data; +regulator_lock (dcdc->regulator);regulator_notifier_call_chain (dcdc->regulator,REGULATOR_EVENT_UNDER_VOLTAGE ,NULL ); +regulator_unlock (dcdc->regulator);return IRQ_HANDLED ; }
@@ -194,9 +196,11 @@ static irqreturn_t wm831x_dcdc_oc_irq(int irq, void *data) {struct wm831x_dcdc *dcdc = data; +regulator_lock (dcdc->regulator);regulator_notifier_call_chain (dcdc->regulator,REGULATOR_EVENT_OVER_CURRENT ,NULL ); +regulator_unlock (dcdc->regulator);return IRQ_HANDLED ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 333/346 regulator: pv88090: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 275513b7695a61b75b2546406ecd0f8e3d9fc8be ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/pv88090-regulator.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/regulator/pv88090-regulator.c +4 -0
@@ -274,9 +274,11 @@ static irqreturn_t pv88090_irq_handler(int irq, void *data)if (reg_val &PV88090_E_VDD_FLT ) {for (i =0 ; i <PV88090_MAX_REGULATORS ; i++) {if (chip->rdev[i] !=NULL ) { +regulator_lock (chip->rdev[i]);regulator_notifier_call_chain (chip->rdev[i],REGULATOR_EVENT_UNDER_VOLTAGE ,NULL ); +regulator_unlock (chip->rdev[i]); } }
@@ -291,9 +293,11 @@ static irqreturn_t pv88090_irq_handler(int irq, void *data)if (reg_val &PV88090_E_OVER_TEMP ) {for (i =0 ; i <PV88090_MAX_REGULATORS ; i++) {if (chip->rdev[i] !=NULL ) { +regulator_lock (chip->rdev[i]);regulator_notifier_call_chain (chip->rdev[i],REGULATOR_EVENT_OVER_TEMP ,NULL ); +regulator_unlock (chip->rdev[i]); } }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 334/346 regulator: da9062: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 978995def0f6030aa6b3b494682f673aca13881b ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/da9062-regulator.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/regulator/da9062-regulator.c +2 -0
@@ -974,8 +974,10 @@ static irqreturn_t da9062_ldo_lim_event(int irq, void *data)continue ;if (BIT (regl->info->oc_event.lsb) & bits) { +regulator_lock (regl->rdev);regulator_notifier_call_chain (regl->rdev,REGULATOR_EVENT_OVER_CURRENT ,NULL ); +regulator_unlock (regl->rdev); handled =IRQ_HANDLED ; } }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 335/346 regulator: da9055: Fix notifier mutex lock warning
In reply to Greg Kroah-Hartman[ Upstream commit 5e6afb3832bedf420dd8e4c5b32ed85117c5087d ]
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function.
Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API.
--- drivers/regulator/da9055-regulator.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/regulator/da9055-regulator.c +2 -0
@@ -515,8 +515,10 @@ static irqreturn_t da9055_ldo5_6_oc_irq(int irq, void *data) {struct da9055_regulator *regulator = data; +regulator_lock (regulator->rdev);regulator_notifier_call_chain (regulator->rdev,REGULATOR_EVENT_OVER_CURRENT ,NULL ); +regulator_unlock (regulator->rdev);return IRQ_HANDLED ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 336/346 spi: Fix zero length xfer bug
In reply to Greg Kroah-Hartman[ Upstream commit 5442dcaa0d90fc376bdfc179a018931a8f43dea4 ]
This fixes a bug for messages containing both zero length and unidirectional xfers.
The function spi_map_msg will allocate dummy tx and/or rx buffers for use with unidirectional transfers when the hardware can only do a bidirectional transfer. That dummy buffer will be used in place of a NULL buffer even when the xfer length is 0.
Then in the function __spi_map_msg, if he hardware can dma, the zero length xfer will have spi_map_buf called on the dummy buffer.
Eventually, __sg_alloc_table is called and returns -EINVAL because nents == 0.
This fix prevents the error by not using the dummy buffer when the xfer length is zero.
--- drivers/spi/spi.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/spi/spi.c +2 -0
@@ -1024,6 +1024,8 @@ static int spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)if (max_tx || max_rx) {list_for_each_entry (xfer, &msg->transfers, transfer_list) { +if (!xfer->len) +continue ;if (!xfer->tx_buf) xfer->tx_buf = ctlr->dummy_tx;if (!xfer->rx_buf)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 337/346 ASoC: davinci-mcasp: Fix clang warning without CONFIG_PM
In reply to Greg Kroah-Hartman[ Upstream commit 8ca5104715cfd14254ea5aecc390ae583b707607 ]
Building with clang shows a variable that is only used by the suspend/resume functions but defined outside of their #ifdef block:
sound/soc/ti/davinci-mcasp.c:48:12: error: variable 'context_regs' is not needed and will not be emitted
We commonly fix these by marking the PM functions as __maybe_unused, but here that would grow the davinci_mcasp structure, so instead add another #ifdef here.
--- sound/soc/ti/davinci-mcasp.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/ti/davinci-mcasp.c +2 -0
@@ -44,6 +44,7 @@#define MCASP_MAX_AFIFO_DEPTH 64 +#ifdef CONFIG_PM static u32 context_regs[] = {DAVINCI_MCASP_TXFMCTL_REG , DAVINCI_MCASP_RXFMCTL_REG,
@@ -66,6 +67,7 @@ struct davinci_mcasp_context {u32 *xrsr_regs;/* for serializer configuration */ bool pm_state; }; +#endif struct davinci_mcasp_ruledata {struct davinci_mcasp *mcasp;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 338/346 ASoC: ti: fix davinci_mcasp_probe dependencies
In reply to Greg Kroah-Hartman[ Upstream commit 7d7b25d05ef1c5a1a9320190e1eeb55534847558 ]
The SND_SOC_DAVINCI_MCASP driver can use either edma or sdma as a back-end, and it takes the presence of the respective dma engine drivers in the configuration as an indication to which ones should be built. However, this is flawed in multiple ways:
- With CONFIG_TI_EDMA=m and CONFIG_SND_SOC_DAVINCI_MCASP=y,
is enabled as =m, and we get a link error:
sound/soc/ti/davinci-mcasp.o: In function `davinci_mcasp_probe':
davinci-mcasp.c:(.text+0x930): undefined reference to `edma_pcm_platform_register'
- When CONFIG_SND_SOC_DAVINCI_MCASP=m has already been selected by another driver, the same link error appears even if CONFIG_TI_EDMA is disabled
There are possibly other issues here, but it seems that the only reasonable solution is to always build both SND_SOC_TI_EDMA_PCM and SND_SOC_TI_SDMA_PCM as a dependency here. Both are fairly small and do not have any other compile-time dependencies, so the cost is very small, and makes the configuration stage much more consistent.
--- sound/soc/ti/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/soc/ti/Kconfig +2 -2
@@ -21,8 +21,8 @@ config SND_SOC_DAVINCI_ASP config SND_SOC_DAVINCI_MCASP tristate "Multichannel Audio Serial Port (McASP) support" - select SND_SOC_TI_EDMA_PCM if TI_EDMA - select SND_SOC_TI_SDMA_PCM if DMA_OMAP + select SND_SOC_TI_EDMA_PCM + select SND_SOC_TI_SDMA_PCM help Say Y or M here if you want to have support for McASP IP found in various Texas Instruments SoCs like:
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 339/346 drm/v3d: Handle errors from IRQ setup.
In reply to Greg Kroah-Hartman[ Upstream commit fc22771547e7e8a63679f0218e943d72b107de65 ]
Noted in review by Dave Emett for V3D 4.2 support.
--- drivers/gpu/drm/v3d/v3d_drv.c | 8 ++++++-- drivers/gpu/drm/v3d/v3d_drv.h | 2 +- drivers/gpu/drm/v3d/v3d_irq.c | 13 +++++++++++-- 3 files changed, 18 insertions(+), 5 deletions(-)
drivers/gpu/drm/v3d/v3d_drv.c +6 -2
@@ -312,14 +312,18 @@ static int v3d_platform_drm_probe(struct platform_device *pdev)if (ret) goto dev_destroy; -v3d_irq_init (v3d); + ret =v3d_irq_init (v3d); +if (ret) + goto gem_destroy; ret =drm_dev_register (drm,0 );if (ret) - goto gem_destroy; + goto irq_disable;return 0 ; +irq_disable: +v3d_irq_disable (v3d); gem_destroy:v3d_gem_destroy (drm); dev_destroy:
drivers/gpu/drm/v3d/v3d_drv.h +1 -1
@@ -311,7 +311,7 @@ void v3d_invalidate_caches(struct v3d_dev *v3d);void v3d_flush_caches (struct v3d_dev *v3d);/* v3d_irq.c */ -void v3d_irq_init (struct v3d_dev *v3d); +int v3d_irq_init (struct v3d_dev *v3d);void v3d_irq_enable (struct v3d_dev *v3d);void v3d_irq_disable (struct v3d_dev *v3d);void v3d_irq_reset (struct v3d_dev *v3d);
drivers/gpu/drm/v3d/v3d_irq.c +11 -2
@@ -156,7 +156,7 @@ v3d_hub_irq(int irq, void *arg)return status; } -void +int v3d_irq_init (struct v3d_dev *v3d) {int ret, core;
@@ -173,13 +173,22 @@ v3d_irq_init(struct v3d_dev *v3d) ret =devm_request_irq (v3d->dev,platform_get_irq (v3d->pdev,0 ), v3d_hub_irq,IRQF_SHARED ,"v3d_hub" , v3d); +if (ret) + goto fail; + ret =devm_request_irq (v3d->dev,platform_get_irq (v3d->pdev,1 ), v3d_irq,IRQF_SHARED ,"v3d_core0" , v3d);if (ret) -dev_err (v3d->dev,"IRQ setup failed: %d\n" , ret); + goto fail;v3d_irq_enable (v3d); +return 0 ; + +fail: +if (ret != -EPROBE_DEFER ) +dev_err (v3d->dev,"IRQ setup failed: %d\n" , ret); +return ret; }void
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 340/346 drm/drv: Hold ref on parent device during drm_device lifetime
In reply to Greg Kroah-Hartman[ Upstream commit 56be6503aab2bc3a30beae408071b9be5e1bae51 ]
This makes it safe to access drm_device->dev after the parent device has been removed/unplugged.
--- drivers/gpu/drm/drm_drv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/drm_drv.c +4 -1
@@ -499,7 +499,7 @@ int drm_dev_init(struct drm_device *dev,BUG_ON (!parent);kref_init (&dev->ref); - dev->dev = parent; + dev->dev =get_device (parent); dev->driver = driver;/* no per-device feature limits by default */
@@ -569,6 +569,7 @@ int drm_dev_init(struct drm_device *dev,drm_minor_free (dev,DRM_MINOR_RENDER );drm_fs_inode_free (dev->anon_inode); err_free: +put_device (dev->dev);mutex_destroy (&dev->master_mutex);mutex_destroy (&dev->ctxlist_mutex);mutex_destroy (&dev->clientlist_mutex);
@@ -604,6 +605,8 @@ void drm_dev_fini(struct drm_device *dev)drm_minor_free (dev,DRM_MINOR_PRIMARY );drm_minor_free (dev,DRM_MINOR_RENDER ); +put_device (dev->dev); +mutex_destroy (&dev->master_mutex);mutex_destroy (&dev->ctxlist_mutex);mutex_destroy (&dev->clientlist_mutex);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 341/346 drm: Wake up next in drm_read() chain if we are forced to putback the event
In reply to Greg Kroah-Hartman[ Upstream commit 60b801999c48b6c1dd04e653a38e2e613664264e ]
After an event is sent, we try to copy it into the user buffer of the first waiter in drm_read() and if the user buffer doesn't have enough room we put it back onto the list. However, we didn't wake up any subsequent waiter, so that event may sit on the list until either a new vblank event is sent or a new waiter appears. Rare, but in the worst case may lead to a stuck process.
Testcase: igt/drm_read/short-buffer-wakeup
--- drivers/gpu/drm/drm_file.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/drm_file.c +1 -0
@@ -567,6 +567,7 @@ ssize_t drm_read(struct file *filp, char __user *buffer, file_priv->event_space -= length;list_add (&e->link, &file_priv->event_list);spin_unlock_irq (&dev->event_lock); +wake_up_interruptible (&file_priv->event_wait);break ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 342/346 drm/sun4i: dsi: Change the start delay calculation
In reply to Greg Kroah-Hartman[ Upstream commit da676c6aa6413d59ab0a80c97bbc273025e640b2 ]
The current calculation for the video start delay in the current DSI driver is that it is the total vertical size, minus the front porch and sync length, plus 1. This equals to the active vertical size plus the back porch plus 1.
That 1 is coming in the Allwinner BSP from an variable that is set to 1. However, if we look at the Allwinner BSP more closely, and especially in the "legacy" code for the display (in drivers/video/sunxi/legacy/), we can see that this variable is actually computed from the porches and the sync minus 10, clamped between 8 and 100.
This fixes the start delay symptom we've seen on some panels (vblank timeouts with vertical white stripes at the bottom of the panel).
--- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +3 -1
@@ -357,7 +357,9 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,static u16 sun6i_dsi_get_video_start_delay (struct sun6i_dsi *dsi,struct drm_display_mode *mode) { -return mode->vtotal - (mode->vsync_end - mode->vdisplay) +1 ; +u16 start =clamp (mode->vtotal - mode->vdisplay -10 ,8 ,100 ); + +return mode->vtotal - (mode->vsync_end - mode->vdisplay) + start; } static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 343/346 vfio-ccw: Prevent quiesce function going into an infinite loop
In reply to Greg Kroah-Hartman[ Upstream commit d1ffa760d22aa1d8190478e5ef555c59a771db27 ]
The quiesce function calls cio_cancel_halt_clear() and if we get an -EBUSY we go into a loop where we:
- wait for any interrupts
- flush all I/O in the workqueue
- retry cio_cancel_halt_clear
During the period where we are waiting for interrupts or flushing all I/O, the channel subsystem could have completed a halt/clear action and turned off the corresponding activity control bits in the subchannel status word. This means the next time we call cio_cancel_halt_clear(), we will again start by calling cancel subchannel and so we can be stuck between calling cancel and halt forever.
Rather than calling cio_cancel_halt_clear() immediately after waiting, let's try to disable the subchannel. If we succeed in disabling the subchannel then we know nothing else can happen with the device.
Message-Id: <4d5a4b98ab1b41ac6131b5c36de18b76c5d66898.1555449329.git.alifm@linux.ibm.com>
--- drivers/s390/cio/vfio_ccw_drv.c | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-)
drivers/s390/cio/vfio_ccw_drv.c +18 -14
@@ -40,26 +40,30 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch)if (ret != -EBUSY ) goto out_unlock; + iretry =255 ;do { - iretry =255 ; ret =cio_cancel_halt_clear (sch, &iretry); -while (ret == -EBUSY ) { -/* -* Flush all I/O and wait for -* cancel/halt/clear completion. -*/ - private->completion = &completion; -spin_unlock_irq (sch->lock); -wait_for_completion_timeout (&completion,3 *HZ ); +if (ret == -EIO ) { +pr_err ("vfio_ccw: could not quiesce subchannel 0.%x.%04x!\n" , + sch->schid.ssid, sch->schid.sch_no); +break ; + } + +/* +* Flush all I/O and wait for +* cancel/halt/clear completion. +*/ + private->completion = &completion; +spin_unlock_irq (sch->lock); - private->completion =NULL ; -flush_workqueue (vfio_ccw_work_q); -spin_lock_irq (sch->lock); - ret =cio_cancel_halt_clear (sch, &iretry); - }; +if (ret == -EBUSY ) +wait_for_completion_timeout (&completion,3 *HZ ); + private->completion =NULL ; +flush_workqueue (vfio_ccw_work_q); +spin_lock_irq (sch->lock); ret =cio_disable_subchannel (sch); }while (ret == -EBUSY ); out_unlock:
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 344/346 ice: Put __ICE_PREPARED_FOR_RESET check in ice_prepare_for_reset
In reply to Greg Kroah-Hartman[ Upstream commit 5abac9d7e1bb9a373673811154774d4c89a7f85e ]
Currently we check if the __ICE_PREPARED_FOR_RESET bit is set prior to calling ice_prepare_for_reset in ice_reset_subtask(), but we aren't checking that bit in ice_do_reset() before calling ice_prepare_for_reset(). This is not consistent and can cause issues if ice_prepare_for_reset() is called prior to ice_do_reset(). Fix this by checking if the __ICE_PREPARED_FOR_RESET bit is set internal to ice_prepare_for_reset().
--- drivers/net/ethernet/intel/ice/ice_main.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/ice/ice_main.c +5 -2
@@ -342,6 +342,10 @@ ice_prepare_for_reset(struct ice_pf *pf) {struct ice_hw *hw = &pf->hw; +/* already prepared for reset */ +if (test_bit (__ICE_PREPARED_FOR_RESET, pf->state)) +return ; +/* Notify VFs of impending reset */ if (ice_check_sq_alive (hw, &hw->mailboxq))ice_vc_notify_reset (pf);
@@ -424,8 +428,7 @@ static void ice_reset_subtask(struct ice_pf *pf)/* return if no valid reset type requested */ if (reset_type ==ICE_RESET_INVAL )return ; -if (!test_bit (__ICE_PREPARED_FOR_RESET, pf->state)) -ice_prepare_for_reset (pf); +ice_prepare_for_reset (pf);/* make sure we are ready to rebuild */ if (ice_check_reset (&pf->hw)) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 345/346 drm/sun4i: dsi: Enforce boundaries on the start delay
In reply to Greg Kroah-Hartman[ Upstream commit efa31801203ac2f5c6a82a28cb991c7163ee0f1d ]
The Allwinner BSP makes sure that we don't end up with a null start delay or with a delay larger than vtotal.
The former condition is likely to happen now with the reworked start delay, so make sure we enforce the same boundaries.
--- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +5 -1
@@ -358,8 +358,12 @@ static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi, struct drm_display_mode *mode) {u16 start =clamp (mode->vtotal - mode->vdisplay -10 ,8 ,100 ); +u16 delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start; -return mode->vtotal - (mode->vsync_end - mode->vdisplay) + start; +if (delay > mode->vtotal) + delay = delay % mode->vtotal; + +return max_t (u16, delay,1 ); } static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 346/346 NFS: Fix a double unlock from nfs_match,get_client
In reply to Greg Kroah-Hartman[ Upstream commit c260121a97a3e4df6536edbc2f26e166eff370ce ]
Now that nfs_match_client drops the nfs_client_lock, we should be careful
to always return it in the same condition: locked.
--- fs/nfs/client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfs/client.c +1 -1
@@ -299,9 +299,9 @@ static struct nfs_client *nfs_match_client(const struct nfs_client_initdata *datspin_unlock (&nn->nfs_client_lock); error =nfs_wait_client_init_complete (clp);nfs_put_client (clp); +spin_lock (&nn->nfs_client_lock);if (error <0 )return ERR_PTR (error); -spin_lock (&nn->nfs_client_lock); goto again; }
Signature · 1 line
2.20.1
stable-rc/linux-5.0.y boot: 124 boots: 0 failed, 124 passed (v5.0.19-347-g79c6130942fe)
stable-rc/linux-5.0.y boot: 124 boots: 0 failed, 124 passed (v5.0.19-347-g79c6130942fe)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.0.y/kernel/v5.0.19-347-g79c6130942fe/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.0.y/kernel/v5.0.19-347-g79c6130942fe/
Tree: stable-rc
Branch: linux-5.0.y
Git Describe: v5.0.19-347-g79c6130942fe
Git Commit: 79c6130942fe2bc8d8cc92c526e93cce6a068262
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 68 unique boards, 22 SoC families, 14 builds out of 207
---
For more info write to <[email protected]>
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.0.20 release. There are 346 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 Sat 01 Jun 2019 03:02:10 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.20-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.0.y
and the diffstat can be found below.thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.0:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
32 tests: 32 pass, 0 failLinux version: 5.0.20-rc1-g79c6130
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04Cheers
Jon
Signature · 1 line
nvpublic
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.0.20 release. There are 346 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 Sat 01 Jun 2019 03:02:10 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.20-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.0.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 5.0.20-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.0.y
git commit: 79c6130942fe2bc8d8cc92c526e93cce6a068262
git describe: v5.0.19-347-g79c6130942fe
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.0-oe/build/v5.0.19-347-g79c6130942fe
No regressions (compared to build v5.0.19)
Fixes (compared to build v5.0.19)
Ran 22805 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-cpuhotplug-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-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-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* v4l2-compliance
* ltp-fs-tests
* network-basic-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-open-posix-tests
* spectre-meltdown-checker-test
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 17 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.0.20 release. There are 346 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 Sat 01 Jun 2019 03:02:10 AM UTC. 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/v5.x/stable-review/patch-5.0.20-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.0.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 3 lines
thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.
Thanks for testing 4 of these and letting me know.
greg k-h
Quoted 18 lines · Greg Kroah-Hartman
Quoted 17 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.0.20 release. There are 346 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 Sat 01 Jun 2019 03:02:10 AM UTC. 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/v5.x/stable-review/patch-5.0.20-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.0.y
and the diffstat can be found below.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.Thanks for testing 4 of these and letting me know.
5.1 sent out now. We were just waiting for the remaining test jobs to finish before sending it.
Dan
Quoted 2 lines
greg k-h
Signature · 1 line
Linaro - Kernel Validation
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.0.20 release. There are 346 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 Sat 01 Jun 2019 03:02:10 AM UTC. Anything received after that time might be too late.
Build results:
total: 159 pass: 159 fail: 0 Qemu test results: total: 349 pass: 349 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.0.20 release. There are 346 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 Sat 01 Jun 2019 03:02:10 AM UTC. 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/v5.x/stable-review/patch-5.0.20-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.0.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.0.20 release. There are 346 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 Sat 01 Jun 2019 03:02:10 AM UTC. 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/v5.x/stable-review/patch-5.0.20-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.0.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah