Re: [PATCH 03/15] staging: comedi: ni_routing: Add NI signal routing info

On Mon, 2017-10-09 at 12:01 -0600, Spencer E Olson wrote: > On Mon, 2017-10-09 at 10:56 +0100, Ian Abbott wrote: > > On 08/10/17 07:44, Spencer E Olson wrote: > > > On Thu, 2016-11-10 at 18:16 +, Ian Abbott wrote: > > >> On 10/11/16 17:54, Greg Kroah-Hartman wrote: > > >>> On Thu, Nov 10, 2016

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

On Wed, Oct 11, 2017 at 06:02:47PM +0530, Shreeya Patel wrote: > On Tue, 2017-10-10 at 11:06 +1100, Tobin C. Harding wrote: > > On Tue, Oct 10, 2017 at 02:48:58AM +0530, Shreeya Patel wrote: > > > > > > Remove NULL pointer dereference as it results in undefined > > > behaviour, and will usually

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

On Thu, Oct 12, 2017 at 12:06:33AM +0100, Russell King - ARM Linux wrote: > Now, if you mean "known" to be equivalent with "recognised by > imx-media" then, as I've pointed out several times already, that > statement is FALSE. I'm not sure how many times I'm going to have to > state this fact.

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

On 10/11/2017 04:06 PM, Russell King - ARM Linux wrote: On Wed, Oct 11, 2017 at 03:14:26PM -0700, Steve Longerbeam wrote: On 10/11/2017 02:49 PM, Russell King - ARM Linux wrote: On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote: imx_media_link_notify() should not return

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

On Wed, Oct 11, 2017 at 03:14:26PM -0700, Steve Longerbeam wrote: > > > On 10/11/2017 02:49 PM, Russell King - ARM Linux wrote: > >On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote: > >>imx_media_link_notify() should not return error if the source subdevice > >>is not recognized

Re: [PATCH v3 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

On 11.10.2017 23:47, Nicolas Dufresne wrote: > Le mercredi 11 octobre 2017 à 23:08 +0300, Dmitry Osipenko a écrit : >> diff --git a/drivers/staging/tegra-vde/TODO b/drivers/staging/tegra- >> vde/TODO >> new file mode 100644 >> index ..e98bbc7b3c19 >> --- /dev/null >> +++

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

On 10/11/2017 02:49 PM, Russell King - ARM Linux wrote: On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote: imx_media_link_notify() should not return error if the source subdevice is not recognized by imx-media, that isn't an error. If the subdev has controls they will be

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote: > imx_media_link_notify() should not return error if the source subdevice > is not recognized by imx-media, that isn't an error. If the subdev has > controls they will be inherited starting from a known subdev. What does "a known

Re: [PATCH v3 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

Le mercredi 11 octobre 2017 à 23:08 +0300, Dmitry Osipenko a écrit : > diff --git a/drivers/staging/tegra-vde/TODO b/drivers/staging/tegra- > vde/TODO > new file mode 100644 > index ..e98bbc7b3c19 > --- /dev/null > +++ b/drivers/staging/tegra-vde/TODO > @@ -0,0 +1,5 @@ > +TODO: > +

[PATCH v3 2/2] ARM: dts: tegra20: Add video decoder node

Add a device node for the video decoder engine found on Tegra20. Signed-off-by: Dmitry Osipenko --- arch/arm/boot/dts/tegra20.dtsi | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi index

[PATCH v3 0/2] NVIDIA Tegra20 video decoder driver

This driver provides accelerated video decoding to NVIDIA Tegra20 SoC's, it is a result of reverse-engineering efforts. Driver has been tested on Toshiba AC100 and Acer A500, it should work on any Tegra20 device. In userspace this driver is utilized by libvdpau-tegra [0] that implements VDPAU

[PATCH v3 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports decoding of CAVLC H.264 only. Signed-off-by: Dmitry Osipenko --- .../bindings/arm/tegra/nvidia,tegra20-vde.txt | 44 +

[PATCH 5/5] staging: pi433: rf69.c style fix - space before asterisk

This patch fixes the following checkpatch.pl error: ERROR: "(foo*)" should be "(foo *)" in rf69.c file as requested by TODO file. Additionally some style warnings remain valid here and could be fixed by another patch. Signed-off-by: Marcin Ciupak ---

[PATCH 4/5] staging: pi433: rf69.c style fix - code indent should use tabs

This patch fixes the following checkpatch.pl error: ERROR: code indent should use tabs where possible in rf69.c file as requested by TODO file. Additionally some style warnings remain valid here and could be fixed by another patch. Signed-off-by: Marcin Ciupak ---

[PATCH 3/5] staging: pi433: rf69.c style fix - spaces before/after

his patch fixes the following checkpatch.pl errors: ERROR: space prohibited after that open parenthesis '(' ERROR: space prohibited before that ',' (ctx:WxV) ERROR: space prohibited before that close parenthesis ')' ERROR: space required after that ',' (ctx:VxV) ERROR: space required before the

[PATCH 2/5] staging: pi433: rf69.c style fix - spaces required around

This patch fixes the following checkpatch.pl errors: ERROR: spaces required around that '+=' (ctx:WxV) ERROR: spaces required around that '=' (ctx:VxV) ERROR: spaces required around that '<' (ctx:VxV) in rf69.c file as requested by TODO file. Additionally some style warnings remain valid here

[PATCH 1/5] staging: pi433: rf69.c style fix - trailing statements

This patch fixes the following checkpatch.pl error: ERROR: trailing statements should be on next line in rf69.c file as requested by TODO file. Note: ERROR: spaces required around that '=' (ctx:VxV) remains valid here and is going to be fixed by the next patch in set. Additionally some style

[PATCH 0/5] staging: pi433: rf69.c coding style errors cleanup

This set of patches is intended to fix coding style errors in rf69.c file in order to comply with kernel coding style guide as requested by TODO file. The following errors were fixed: ERROR: trailing statements should be on next line ERROR: spaces required around that '+=' (ctx:WxV) ERROR: spaces

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

Hi Shreeya, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.14-rc4 next-20171009] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: Two rtlwifi drivers?

On 10/11/2017 08:13 AM, Greg Kroah-Hartman wrote: On Wed, Oct 11, 2017 at 12:06:00PM +0300, Kalle Valo wrote: (Sorry for taking so long with the reply, I wanted first to check what the rtlwifi in staging contains.) Larry Finger writes: On 08/24/2017 07:14 AM,

RE: [PATCH 1/1] vmbus: hvsock: add proper sync for vmbus_hvsock_device_unregister()

Thanks Dan. Will do. K. Y > -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Wednesday, October 11, 2017 2:42 AM > To: KY Srinivasan > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org;

Re: Two rtlwifi drivers?

On Wed, Oct 11, 2017 at 03:13:10PM +0200, Greg Kroah-Hartman wrote: > And it seems like the company isn't willing to do the real work, so > dumping this in staging is the best we can do at the moment. I'm more optimistic. There are a lot of @realtek.com addresses in the CC list and that's a new

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote: > I assume it's easy to produce an actual failure here? Why haven't we > seen bug reports about this? The bug was detected with static analysis. You have to enable a debug feature in the .config if you want sleeping with spinlock

[PATCH 7/9] staging: fsl-dpaa2/eth: Use implicit clear of link interrupt

dpni_get_irq_status() also looks at the input value of its status parameter, and if not null it automatically clears from pending state the bits that are set there. Use this feature to avoid a separate MC command for clearing the interrupt event bits after reading the status. Signed-off-by:

[PATCH 9/9] staging: fsl-dpaa2/eth: Add firmware version

Include firmware version in the driver information exported through ethtool. Signed-off-by: Ioana Radulescu --- drivers/staging/fsl-dpaa2/ethernet/dpaa2-ethtool.c | 14 +- drivers/staging/fsl-dpaa2/ethernet/dpni-cmd.h | 5

[PATCH 1/9] staging: fsl-dpaa2/eth: Fix potential endless loop

We incorrectly assumed that dpaa2_io_release() can only return -EBUSY as an error code, when in fact it can also fail in case some of its arguments don't have valid values. Make sure we only retry the operation while the portal is busy and abort for all other error cases, otherwise we risk

[PATCH 2/9] staging: fsl-dpaa2/eth: Account for Rx FD buffers on error path

On Rx path, if we fail to build an skb from the incoming FD, we still need to update the channel buffer count accordingly, otherwise we risk depleting the pool while the software counter still sees available buffers. Signed-off-by: Ioana Radulescu ---

[PATCH 5/9] staging: fsl-dpaa2/eth: Refactor interrupt arming in NAPI poll

Take into consideration the return value of napi_complete_done(), since there might be an indication that it's not suitable to enable driver interrupts yet. Signed-off-by: Bogdan Purcareata --- drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 3 +-- 1 file changed, 1

[PATCH 3/9] staging: fsl-dpaa2/eth: Check SGT final bit is present

For scatter-gather ingress frames, we expect to receive a list of fragments from the hardware, last of which is marked with a "final" bit. Add a check to make sure the Rx frame has this bit set correctly; there's not much we can do in case of a malformed frame, but at least issue a warning.

[PATCH 4/9] staging: fsl-dpaa2/eth: Check if notification rearm is successful

In case dpaa2_io_service_rearm() fails with an error other then EBUSY, it will do so silently; add a check for this and a warning message, as a failure here means we're unable to receive any more traffic on the current cpu. Signed-off-by: Ioana Radulescu ---

[PATCH 8/9] staging: fsl-dpaa2/eth: Don't use netdev_err too early

Early during probe the netdevice name is not initialized yet, so use dev_err instead of netdev_err when printing error messages. Signed-off-by: Ioana Radulescu --- drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 6/9] staging: fsl-dpaa2/eth: Fix double DMA unmap

In case we fail to allocate a skb for a fragmented ingress frame, the cleanup function will attempt to unmap again the first frame fragment, which had already been unmapped during early Rx processing. Avoid this by freeing the first buffer immediately in case we hit an error, leaving the cleanup

Re: Two rtlwifi drivers?

On Wed, Oct 11, 2017 at 12:06:00PM +0300, Kalle Valo wrote: > (Sorry for taking so long with the reply, I wanted first to check what > the rtlwifi in staging contains.) > > Larry Finger writes: > > > On 08/24/2017 07:14 AM, Kalle Valo wrote: > >> Dan Carpenter

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

On Tue, 2017-10-10 at 11:06 +1100, Tobin C. Harding wrote: > On Tue, Oct 10, 2017 at 02:48:58AM +0530, Shreeya Patel wrote: > > > > Remove NULL pointer dereference as it results in undefined > > behaviour, and will usually lead to a runtime error. > The diff does not show any pointer dereference

Re: [PATCH 1/1] vmbus: hvsock: add proper sync for vmbus_hvsock_device_unregister()

On Tue, Oct 10, 2017 at 10:38:51PM -0700, k...@exchange.microsoft.com wrote: > From: Dexuan Cui > > Without the patch, vmbus_hvsock_device_unregister() can destroy the device > prematurely when close() is called, and can cause NULl dereferencing or > potential data loss (the

Re: Two rtlwifi drivers?

(Sorry for taking so long with the reply, I wanted first to check what the rtlwifi in staging contains.) Larry Finger writes: > On 08/24/2017 07:14 AM, Kalle Valo wrote: >> Dan Carpenter writes: >> >>> Smatch is distrustful of the "capab"