July 2019 - Linux-stable-mirror

[PATCH] ALSA: firewire-lib/fireworks: fix miss detection of received MIDI messages

by Takashi Sakamoto

In IEC 61883-6, 8 MIDI data streams are multiplexed into single MIDI conformant data channel. The index of stream is calculated by modulo 8 of the value of data block counter. In fireworks, the value of data block counter in CIP header has a quirk with firmware version v5.0.0, v5.7.3 and v5.8.0. This brings ALSA IEC 61883-1/6 packet streaming engine to miss detection of MIDI messages. This commit fixes the miss detection to modify the value of data block counter for the modulo calculation. For maintainers, this bug exists since a commit 18f5ed365d3f ("ALSA: fireworks/firewire-lib: add support for recent firmware quirk") in Linux kernel v4.2. There're many changes since the commit. This fix can be backported to Linux kernel v4.4 or later. I tagged a base commit to the backport for your convenience. Besides, my work for Linux kernel v5.3 brings heavy code refactoring and some structure members are renamed in 'sound/firewire/amdtp-stream.h'. The content of this patch brings conflict when merging -rc tree with this patch to the latest tree. I request maintainers to solve the conflict by replacing 'tx_first_dbc' with 'ctx_data.tx.first_dbc'. Fixes: df075feefbd3 ("ALSA: firewire-lib: complete AM824 data block processing layer") Cc: <stable(a)vger.kernel.org> # v4.4+ Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/amdtp-am824.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/firewire/amdtp-am824.c b/sound/firewire/amdtp-am824.c index 4210e5c6262e..4d677fcb4fc2 100644 --- a/sound/firewire/amdtp-am824.c +++ b/sound/firewire/amdtp-am824.c @@ -321,6 +321,7 @@ static void read_midi_messages(struct amdtp_stream *s, u8 *b; for (f = 0; f < frames; f++) { + port = (8 - s->tx_first_dbc + s->data_block_counter + f) % 8; port = (s->data_block_counter + f) % 8; b = (u8 *)&buffer[p->midi_position]; -- 2.20.1

4 years, 10 months

2
4
0 0

[PATCH] mt76: round up length on mt76_wr_copy

by Felix Fietkau

When beacon length is not a multiple of 4, the beacon could be sent with the last 1-3 bytes corrupted. The skb data is guaranteed to have enough room for reading beyond the end, because it is always followed by skb_shared_info, so rounding up is safe. All other callers of mt76_wr_copy have multiple-of-4 length already. Cc: stable(a)vger.kernel.org Signed-off-by: Felix Fietkau <nbd(a)nbd.name> --- drivers/net/wireless/mediatek/mt76/mmio.c | 2 +- drivers/net/wireless/mediatek/mt76/usb.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mmio.c b/drivers/net/wireless/mediatek/mt76/mmio.c index 38368d19aa6f..83c96a47914f 100644 --- a/drivers/net/wireless/mediatek/mt76/mmio.c +++ b/drivers/net/wireless/mediatek/mt76/mmio.c @@ -43,7 +43,7 @@ static u32 mt76_mmio_rmw(struct mt76_dev *dev, u32 offset, u32 mask, u32 val) static void mt76_mmio_copy(struct mt76_dev *dev, u32 offset, const void *data, int len) { - __iowrite32_copy(dev->mmio.regs + offset, data, len >> 2); + __iowrite32_copy(dev->mmio.regs + offset, data, DIV_ROUND_UP(len, 4)); } static int mt76_mmio_wr_rp(struct mt76_dev *dev, u32 base, diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c index 61b27f3ec6e4..87ecbe290f99 100644 --- a/drivers/net/wireless/mediatek/mt76/usb.c +++ b/drivers/net/wireless/mediatek/mt76/usb.c @@ -164,7 +164,7 @@ static void mt76u_copy(struct mt76_dev *dev, u32 offset, int i, ret; mutex_lock(&usb->usb_ctrl_mtx); - for (i = 0; i < (len / 4); i++) { + for (i = 0; i < DIV_ROUND_UP(len, 4); i++) { put_unaligned_le32(val[i], usb->data); ret = __mt76u_vendor_request(dev, MT_VEND_MULTI_WRITE, USB_DIR_OUT | USB_TYPE_VENDOR, -- 2.17.0

4 years, 10 months

1
0
0 0

[PATCH] rt2x00: fix rx queue hang

by Soeren Moch

Since commit ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler") the handlers rt2x00usb_interrupt_rxdone() and rt2x00usb_interrupt_txdone() are not running with interrupts disabled anymore. So these handlers are not guaranteed to run completely before workqueue processing starts. So only mark entries ready for workqueue processing after proper accounting in the dma done queue. Note that rt2x00usb_work_rxdone() processes all available entries, not only such for which queue_work() was called. This fixes a regression on a RT5370 based wifi stick in AP mode, which suddenly stopped data transmission after some period of heavy load. Also stopping the hanging hostapd resulted in the error message "ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush". Other operation modes are probably affected as well, this just was the used testcase. Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler") Cc: Stanislaw Gruszka <sgruszka(a)redhat.com> Cc: Helmut Schaa <helmut.schaa(a)googlemail.com> Cc: Kalle Valo <kvalo(a)codeaurora.org> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: linux-wireless(a)vger.kernel.org Cc: netdev(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # 4.20+ Signed-off-by: Soeren Moch <smoch(a)web.de> --- drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c index 1b08b01db27b..9c102a501ee6 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c @@ -263,9 +263,9 @@ EXPORT_SYMBOL_GPL(rt2x00lib_dmastart); void rt2x00lib_dmadone(struct queue_entry *entry) { - set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags); clear_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags); rt2x00queue_index_inc(entry, Q_INDEX_DMA_DONE); + set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags); } EXPORT_SYMBOL_GPL(rt2x00lib_dmadone); -- 2.17.1

4 years, 10 months

2
7
0 0

patch "usb: gadget: ether: Fix race between gether_disconnect and rx_submit" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: ether: Fix race between gether_disconnect and rx_submit to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From d29fcf7078bc8be2b6366cbd4418265b53c94fac Mon Sep 17 00:00:00 2001 From: Kiruthika Varadarajan <Kiruthika.Varadarajan(a)harman.com> Date: Tue, 18 Jun 2019 08:39:06 +0000 Subject: usb: gadget: ether: Fix race between gether_disconnect and rx_submit On spin lock release in rx_submit, gether_disconnect get a chance to run, it makes port_usb NULL, rx_submit access NULL port USB, hence null pointer crash. Fixed by releasing the lock in rx_submit after port_usb is used. Fixes: 2b3d942c4878 ("usb ethernet gadget: split out network core") Cc: <stable(a)vger.kernel.org> Signed-off-by: Kiruthika Varadarajan <Kiruthika.Varadarajan(a)harman.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> --- drivers/usb/gadget/function/u_ether.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c index 737bd77a575d..2929bb47a618 100644 --- a/drivers/usb/gadget/function/u_ether.c +++ b/drivers/usb/gadget/function/u_ether.c @@ -186,11 +186,12 @@ rx_submit(struct eth_dev *dev, struct usb_request *req, gfp_t gfp_flags) out = dev->port_usb->out_ep; else out = NULL; - spin_unlock_irqrestore(&dev->lock, flags); if (!out) + { + spin_unlock_irqrestore(&dev->lock, flags); return -ENOTCONN; - + } /* Padding up to RX_EXTRA handles minor disagreements with host. * Normally we use the USB "terminate on short read" convention; @@ -214,6 +215,7 @@ rx_submit(struct eth_dev *dev, struct usb_request *req, gfp_t gfp_flags) if (dev->port_usb->is_fixed) size = max_t(size_t, size, dev->port_usb->fixed_out_len); + spin_unlock_irqrestore(&dev->lock, flags); skb = __netdev_alloc_skb(dev->net, size + NET_IP_ALIGN, gfp_flags); if (skb == NULL) { -- 2.22.0

4 years, 10 months

1
0
0 0

patch "usb: gadget: f_fs: data_len used before properly set" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: f_fs: data_len used before properly set to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From 4833a94eb383f5b22775077ff92ddaae90440921 Mon Sep 17 00:00:00 2001 From: Fei Yang <fei.yang(a)intel.com> Date: Wed, 12 Jun 2019 15:13:26 -0700 Subject: usb: gadget: f_fs: data_len used before properly set The following line of code in function ffs_epfile_io is trying to set flag io_data->use_sg in case buffer required is larger than one page. io_data->use_sg = gadget->sg_supported && data_len > PAGE_SIZE; However at this point of time the variable data_len has not been set to the proper buffer size yet. The consequence is that io_data->use_sg is always set regardless what buffer size really is, because the condition (data_len > PAGE_SIZE) is effectively an unsigned comparison between -EINVAL and PAGE_SIZE which would always result in TRUE. Fixes: 772a7a724f69 ("usb: gadget: f_fs: Allow scatter-gather buffers") Signed-off-by: Fei Yang <fei.yang(a)intel.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> --- drivers/usb/gadget/function/f_fs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 47be961f1bf3..c7ed90084d1a 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -997,7 +997,6 @@ static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data) * earlier */ gadget = epfile->ffs->gadget; - io_data->use_sg = gadget->sg_supported && data_len > PAGE_SIZE; spin_lock_irq(&epfile->ffs->eps_lock); /* In the meantime, endpoint got disabled or changed. */ @@ -1012,6 +1011,8 @@ static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data) */ if (io_data->read) data_len = usb_ep_align_maybe(gadget, ep->ep, data_len); + + io_data->use_sg = gadget->sg_supported && data_len > PAGE_SIZE; spin_unlock_irq(&epfile->ffs->eps_lock); data = ffs_alloc_buffer(io_data, data_len); -- 2.22.0

4 years, 10 months

1
0
0 0

[PATCH v2 2/5] coresight: etm4x: use explicit barriers on enable/disable

by Andrew Murray

Synchronization is recommended before disabling the trace registers to prevent any start or stop points being speculative at the point of disabling the unit (section 7.3.77 of ARM IHI 0064D). Synchronization is also recommended after programming the trace registers to ensure all updates are committed prior to normal code resuming (section 4.3.7 of ARM IHI 0064D). Let's ensure these syncronization points are present in the code and clearly commented. Note that we could rely on the barriers in CS_LOCK and coresight_disclaim_device_unlocked or the context switch to user space - however coresight may be of use in the kernel. Signed-off-by: Andrew Murray <andrew.murray(a)arm.com> CC: stable(a)vger.kernel.org --- drivers/hwtracing/coresight/coresight-etm4x.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c index c89190d464ab..68e8e3954cef 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x.c +++ b/drivers/hwtracing/coresight/coresight-etm4x.c @@ -188,6 +188,10 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) dev_err(etm_dev, "timeout while waiting for Idle Trace Status\n"); + /* As recommended by 4.3.7 of ARM IHI 0064D */ + dsb(sy); + isb(); + done: CS_LOCK(drvdata->base); @@ -454,7 +458,8 @@ static void etm4_disable_hw(void *info) control &= ~0x1; /* make sure everything completes before disabling */ - mb(); + /* As recommended by 7.3.77 of ARM IHI 0064D */ + dsb(sy); isb(); writel_relaxed(control, drvdata->base + TRCPRGCTLR); -- 2.21.0

4 years, 10 months

3
9
0 0

patch "iio: adc: stm32-adc: add missing vdda-supply" added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: stm32-adc: add missing vdda-supply to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From 7685010fca2ba0284f31fd1380df3cffc96d847e Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier <fabrice.gasnier(a)st.com> Date: Wed, 19 Jun 2019 14:29:55 +0200 Subject: iio: adc: stm32-adc: add missing vdda-supply Add missing vdda-supply, analog power supply, to STM32 ADC. When vdda is an independent supply, it needs to be properly turned on or off to supply the ADC. Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com> Fixes: 1add69880240 ("iio: adc: Add support for STM32 ADC core"). Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/stm32-adc-core.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c index 2327ec18b40c..1f7ce5186dfc 100644 --- a/drivers/iio/adc/stm32-adc-core.c +++ b/drivers/iio/adc/stm32-adc-core.c @@ -87,6 +87,7 @@ struct stm32_adc_priv_cfg { * @domain: irq domain reference * @aclk: clock reference for the analog circuitry * @bclk: bus clock common for all ADCs, depends on part used + * @vdda: vdda analog supply reference * @vref: regulator reference * @cfg: compatible configuration data * @common: common data for all ADC instances @@ -97,6 +98,7 @@ struct stm32_adc_priv { struct irq_domain *domain; struct clk *aclk; struct clk *bclk; + struct regulator *vdda; struct regulator *vref; const struct stm32_adc_priv_cfg *cfg; struct stm32_adc_common common; @@ -394,10 +396,16 @@ static int stm32_adc_core_hw_start(struct device *dev) struct stm32_adc_priv *priv = to_stm32_adc_priv(common); int ret; + ret = regulator_enable(priv->vdda); + if (ret < 0) { + dev_err(dev, "vdda enable failed %d\n", ret); + return ret; + } + ret = regulator_enable(priv->vref); if (ret < 0) { dev_err(dev, "vref enable failed\n"); - return ret; + goto err_vdda_disable; } if (priv->bclk) { @@ -425,6 +433,8 @@ static int stm32_adc_core_hw_start(struct device *dev) clk_disable_unprepare(priv->bclk); err_regulator_disable: regulator_disable(priv->vref); +err_vdda_disable: + regulator_disable(priv->vdda); return ret; } @@ -441,6 +451,7 @@ static void stm32_adc_core_hw_stop(struct device *dev) if (priv->bclk) clk_disable_unprepare(priv->bclk); regulator_disable(priv->vref); + regulator_disable(priv->vdda); } static int stm32_adc_probe(struct platform_device *pdev) @@ -468,6 +479,14 @@ static int stm32_adc_probe(struct platform_device *pdev) return PTR_ERR(priv->common.base); priv->common.phys_base = res->start; + priv->vdda = devm_regulator_get(&pdev->dev, "vdda"); + if (IS_ERR(priv->vdda)) { + ret = PTR_ERR(priv->vdda); + if (ret != -EPROBE_DEFER) + dev_err(&pdev->dev, "vdda get failed, %d\n", ret); + return ret; + } + priv->vref = devm_regulator_get(&pdev->dev, "vref"); if (IS_ERR(priv->vref)) { ret = PTR_ERR(priv->vref); -- 2.22.0

4 years, 10 months

1
0
0 0

patch "staging: wilc1000: fix error path cleanup in wilc_wlan_initialize()" added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: wilc1000: fix error path cleanup in wilc_wlan_initialize() to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From 6419f818ababebc1116fb2d0e220bd4fe835d0e3 Mon Sep 17 00:00:00 2001 From: Ajay Singh <ajay.kathat(a)microchip.com> Date: Wed, 26 Jun 2019 12:40:48 +0000 Subject: staging: wilc1000: fix error path cleanup in wilc_wlan_initialize() For the error path in wilc_wlan_initialize(), the resources are not cleanup in the correct order. Reverted the previous changes and use the correct order to free during error condition. Fixes: b46d68825c2d ("staging: wilc1000: remove COMPLEMENT_BOOT") Cc: <stable(a)vger.kernel.org> Signed-off-by: Ajay Singh <ajay.kathat(a)microchip.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/wilc1000/wilc_netdev.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/wilc1000/wilc_netdev.c b/drivers/staging/wilc1000/wilc_netdev.c index c4efec277255..0e0a4eec5486 100644 --- a/drivers/staging/wilc1000/wilc_netdev.c +++ b/drivers/staging/wilc1000/wilc_netdev.c @@ -530,17 +530,17 @@ static int wilc_wlan_initialize(struct net_device *dev, struct wilc_vif *vif) goto fail_locks; } - if (wl->gpio_irq && init_irq(dev)) { - ret = -EIO; - goto fail_locks; - } - ret = wlan_initialize_threads(dev); if (ret < 0) { ret = -EIO; goto fail_wilc_wlan; } + if (wl->gpio_irq && init_irq(dev)) { + ret = -EIO; + goto fail_threads; + } + if (!wl->dev_irq_num && wl->hif_func->enable_interrupt && wl->hif_func->enable_interrupt(wl)) { @@ -596,7 +596,7 @@ static int wilc_wlan_initialize(struct net_device *dev, struct wilc_vif *vif) fail_irq_init: if (wl->dev_irq_num) deinit_irq(dev); - +fail_threads: wlan_deinitialize_threads(dev); fail_wilc_wlan: wilc_wlan_cleanup(dev); -- 2.22.0

4 years, 10 months

1
0
0 0

patch "staging: mt7621-pci: fix PCIE_FTS_NUM_LO macro" added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: mt7621-pci: fix PCIE_FTS_NUM_LO macro to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From 0ae0cf509d28d8539b88b5f7f24558f5bfe57cdf Mon Sep 17 00:00:00 2001 From: Sergio Paracuellos <sergio.paracuellos(a)gmail.com> Date: Wed, 26 Jun 2019 14:43:18 +0200 Subject: staging: mt7621-pci: fix PCIE_FTS_NUM_LO macro Add missing parenthesis to PCIE_FTS_NUM_LO macro to do the same it was being done in original code. Fixes: a4b2eb912bb1 ("staging: mt7621-pci: rewrite RC FTS configuration") Signed-off-by: Sergio Paracuellos <sergio.paracuellos(a)gmail.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/mt7621-pci/pci-mt7621.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c b/drivers/staging/mt7621-pci/pci-mt7621.c index a981f4f0ed03..89fa813142ab 100644 --- a/drivers/staging/mt7621-pci/pci-mt7621.c +++ b/drivers/staging/mt7621-pci/pci-mt7621.c @@ -42,7 +42,7 @@ /* MediaTek specific configuration registers */ #define PCIE_FTS_NUM 0x70c #define PCIE_FTS_NUM_MASK GENMASK(15, 8) -#define PCIE_FTS_NUM_L0(x) ((x) & 0xff << 8) +#define PCIE_FTS_NUM_L0(x) (((x) & 0xff) << 8) /* rt_sysc_membase relative registers */ #define RALINK_CLKCFG1 0x30 -- 2.22.0

4 years, 10 months

1
0
0 0

patch "staging: bcm2835-camera: Restore return behavior of" added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: bcm2835-camera: Restore return behavior of to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From f816db1dc17b99b059325f41ed5a78f85d15368c Mon Sep 17 00:00:00 2001 From: Stefan Wahren <wahrenst(a)gmx.net> Date: Wed, 26 Jun 2019 17:48:11 +0200 Subject: staging: bcm2835-camera: Restore return behavior of ctrl_set_bitrate() The commit 52c4dfcead49 ("Staging: vc04_services: Cleanup in ctrl_set_bitrate()") changed the return behavior of ctrl_set_bitrate(). We cannot do this because of a bug in the firmware, which breaks probing of bcm2835-camera: bcm2835-v4l2: mmal_init: failed to set all camera controls: -3 Cleanup: Destroy video encoder Cleanup: Destroy image encoder Cleanup: Destroy video render Cleanup: Destroy camera bcm2835-v4l2: bcm2835_mmal_probe: mmal init failed: -3 bcm2835-camera: probe of bcm2835-camera failed with error -3 So restore the old behavior, add an explaining comment and a debug message to verify that the bug has been fixed in firmware. Fixes: 52c4dfcead49 ("Staging: vc04_services: Cleanup in ctrl_set_bitrate()") Signed-off-by: Stefan Wahren <wahrenst(a)gmx.net> Cc: stable <stable(a)vger.kernel.org> Acked-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- .../vc04_services/bcm2835-camera/controls.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c b/drivers/staging/vc04_services/bcm2835-camera/controls.c index d60e378bdfce..c251164655ba 100644 --- a/drivers/staging/vc04_services/bcm2835-camera/controls.c +++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c @@ -604,15 +604,28 @@ static int ctrl_set_bitrate(struct bm2835_mmal_dev *dev, struct v4l2_ctrl *ctrl, const struct bm2835_mmal_v4l2_ctrl *mmal_ctrl) { + int ret; struct vchiq_mmal_port *encoder_out; dev->capture.encode_bitrate = ctrl->val; encoder_out = &dev->component[MMAL_COMPONENT_VIDEO_ENCODE]->output[0]; - return vchiq_mmal_port_parameter_set(dev->instance, encoder_out, - mmal_ctrl->mmal_id, &ctrl->val, - sizeof(ctrl->val)); + ret = vchiq_mmal_port_parameter_set(dev->instance, encoder_out, + mmal_ctrl->mmal_id, &ctrl->val, + sizeof(ctrl->val)); + + v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev, + "%s: After: mmal_ctrl:%p ctrl id:0x%x ctrl val:%d ret %d(%d)\n", + __func__, mmal_ctrl, ctrl->id, ctrl->val, ret, + (ret == 0 ? 0 : -EINVAL)); + + /* + * Older firmware versions (pre July 2019) have a bug in handling + * MMAL_PARAMETER_VIDEO_BIT_RATE that result in the call + * returning -MMAL_MSG_STATUS_EINVAL. So ignore errors from this call. + */ + return 0; } static int ctrl_set_bitrate_mode(struct bm2835_mmal_dev *dev, -- 2.22.0

4 years, 10 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2019