Re: [PATCH 5/7] media: use the BIT() macro

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Thu, Aug 22, 2019 at 04:39:32PM -0300, Mauro Carvalho Chehab wrote:
> As warned by cppcheck:
> 
>   [drivers/media/dvb-frontends/cx24123.c:434]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
>   [drivers/media/pci/bt8xx/bttv-input.c:87]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
>   [drivers/media/pci/bt8xx/bttv-input.c:98]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
>   ...
>   [drivers/media/v4l2-core/v4l2-ioctl.c:1391]: (error) Shifting signed 
> 32-bit value by 31 bits is undefined behaviour
> 
> There are lots of places where we're doing 1 << 31. That's bad,
> as, depending on the architecture, this has an undefined behavior.
> 
> The BIT() macro is already prepared to handle this, so, let's
> just switch all "1 << number" macros by BIT(number) at the header files
> with has 1 << 31.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/pci/cobalt/cobalt-driver.h  |  63 +-
>  drivers/media/pci/ivtv/ivtv-irq.h |  28 +-
>  drivers/media/pci/mantis/mantis_reg.h | 156 ++---
>  drivers/media/pci/solo6x10/solo6x10-regs.h| 290 -
>  .../media/platform/am437x/am437x-vpfe_regs.h  |  28 +-
>  .../media/platform/davinci/dm644x_ccdc_regs.h |  22 +-
>  .../media/platform/exynos4-is/fimc-lite-reg.h |  86 +--
>  drivers/media/platform/exynos4-is/fimc-reg.h  | 172 ++---
>  drivers/media/platform/omap3isp/ispreg.h  | 592 +-
>  drivers/media/platform/s3c-camif/camif-regs.h | 128 ++--
>  drivers/media/platform/tegra-cec/tegra_cec.h  |  80 +--
>  drivers/media/platform/ti-vpe/vpe_regs.h  |  94 +--
>  drivers/media/platform/vsp1/vsp1_regs.h   | 254 
>  drivers/media/platform/xilinx/xilinx-vip.h|  33 +-
>  drivers/media/radio/wl128x/fmdrv_common.h |  88 +--
>  drivers/staging/media/ipu3/ipu3-tables.h  |   4 +-
>  16 files changed, 1065 insertions(+), 1053 deletions(-)
> 
> diff --git a/drivers/media/pci/cobalt/cobalt-driver.h 
> b/drivers/media/pci/cobalt/cobalt-driver.h
> index 429bee4ef79c..14b8ca2daa17 100644
> --- a/drivers/media/pci/cobalt/cobalt-driver.h
> +++ b/drivers/media/pci/cobalt/cobalt-driver.h
> @@ -10,6 +10,7 @@
>  
>  #ifndef COBALT_DRIVER_H
>  #define COBALT_DRIVER_H
> +#include 
>  

The blank line should go before the header, not after.

>  #include 
>  #include 

[snip]

> diff --git a/drivers/media/platform/omap3isp/ispreg.h 
> b/drivers/media/platform/omap3isp/ispreg.h
> index 38e2b99b3f10..197f8f43c8fc 100644
> --- a/drivers/media/platform/omap3isp/ispreg.h
> +++ b/drivers/media/platform/omap3isp/ispreg.h
> @@ -45,7 +45,7 @@
>  
>  #define ISPCCP2_REVISION (0x000)
>  #define ISPCCP2_SYSCONFIG(0x004)
> -#define ISPCCP2_SYSCONFIG_SOFT_RESET (1 << 1)
> +#define ISPCCP2_SYSCONFIG_SOFT_RESET BIT(1)
>  #define ISPCCP2_SYSCONFIG_AUTO_IDLE  0x1
>  #define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT12
>  #define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_FORCE\
> @@ -55,44 +55,44 @@
>  #define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART\
>   (0x2 << ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT)
>  #define ISPCCP2_SYSSTATUS(0x008)
> -#define ISPCCP2_SYSSTATUS_RESET_DONE (1 << 0)
> +#define ISPCCP2_SYSSTATUS_RESET_DONE BIT(0)
>  #define ISPCCP2_LC01_IRQENABLE   (0x00C)
>  #define ISPCCP2_LC01_IRQSTATUS   (0x010)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQ(1 << 11)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_LE_IRQ(1 << 10)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_LS_IRQ(1 << 9)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FE_IRQ(1 << 8)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_COUNT_IRQ (1 << 7)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FIFO_OVF_IRQ  (1 << 5)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_CRC_IRQ   (1 << 4)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FSP_IRQ   (1 << 3)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FW_IRQ(1 << 2)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_FSC_IRQ   (1 << 1)
> -#define ISPCCP2_LC01_IRQSTATUS_LC0_SSC_IRQ   (1 << 0)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQBIT(11)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_LE_IRQBIT(10)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_LS_IRQBIT(9)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FE_IRQBIT(8)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_COUNT_IRQ BIT(7)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FIFO_OVF_IRQ  BIT(5)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_CRC_IRQ   BIT(4)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FSP_IRQ   BIT(3)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FW_IRQBIT(2)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_FSC_IRQ   BIT(1)
> +#define ISPCCP2_LC01_IRQSTATUS_LC0_SSC_IRQ   BIT(0)
>  
>  #define ISPCCP2_LC23_IRQENABLE   (0x014)
>  #define ISPCCP2_LC23_IRQSTATUS   (0x018)
>  #define ISPCCP2_LCM_IRQENABLE(0x02C)
> -#define ISPCCP2_LCM_IRQSTATUS_EOF_IRQ(1 << 0)
> -#define 

rtl8192u - meaning of TO_DO_LIST?

[stephen]

Hi all,

Similar to Colin's question yesterday about the rtl8192u driver, is
anybody familiar with the TO_DO_LIST define? As I looked through
checkpatch warnings I saw a particular concerning pattern in
drivers/staging/rtl8192u/r8192U.h:2183:

#ifdef TO_DO_LIST
if (Adapter->bInHctTest)
/* long statement here */
else
#endif
/* unindented statement here */

It seems this code would break if TO_DO_LIST were defined, and I verified
that it is the case. I can't find any comment or documentation about what
the goal of this "to do" item is.

Does anybody know what this is there for? If not, does it make sense to
just go ahead and remove the code there?

Stephen

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

COMPENSATION PAYMENT OF $4,800,000 MILLION DOLLAR

[Bandile Macartney]

COMPENSATION PAYMENT OF $4,800,000 MILLION DOLLAR

Attention please,
This is to bring to your kind attention that the World Bank in affiliation with 
the (IMF) has sanctioned some African countries to compensate the scam victims, 
including people that had an unfinished transaction or international business 
that failed due to Government problems or due to corrupt Government officials. 
The compensation includes those that had lost their hard-earned money to 
scammers. Each of the victims will be compensated with the sum of $4.8 Million 
US dollar, to ensure that justice is done to the scam victims. This is as 
result of numerous reports of frauds perpetuated from some African countries. 
There have been reports that the victims had lost billions of dollars to the 
scammers, with the United States particularly targeted the most.

However, your details were obtained from one of the scammers who were arrested 
by the security operatives. Hence, the inclusion of your name on the list of 
those eligible to be compensated and that is the sole reason for contacting 
you, as one of those entitled to receive the compensation payment. Note, your 
payment reference number is: CP074653BF. The arrested scammer testified that 
there are other scammers and embezzlers of people's hard-earned money, for 
which the combined security agencies are working tirelessly to track them down. 
As security measure, you are hereby warned not to communicate or duplicate this 
message to anybody until all the criminals are apprehended and brought to book. 
Therefore, contact Mr.Alphonse A. NIGNAN immediately with the details as listed 
below for your compensation payment of $4.8 Million US dollar.

1. Your payment reference number:.
2. Your full name:
3. Your address:..
4. Your phone numbers:
5. Scan copy of government issued ID document.

Contact of the payment Manager
Name of the payment manager: Mr.Alphonse A. NIGNAN
Email: wloalb...@gmail.com
Tel: (+226) 6232-4709

Yours faithfully,
Bandile Macartney
The secretary of the Financial Services Vulnerability Taskforce
924 W. 11th St. Tempe, Arizona, United States.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] erofs: move erofs out of staging

[Gao Xiang]

EROFS filesystem has been merged into linux-staging for a year.

EROFS is designed to be a better solution of saving extra storage
space with guaranteed end-to-end performance for read-only files
with the help of reduced metadata, fixed-sized output compression
and decompression inplace technologies.

In the past year, EROFS was greatly improved by many people as
a staging driver, self-tested, betaed by a large number of our
internal users, successfully applied to almost all in-service
HUAWEI smartphones as the part of EMUI 9.1 and proven to be stable
enough to be moved out of staging.

EROFS is a self-contained filesystem driver. Although there are
still some TODOs to be more generic, we have a dedicated team
actively keeping on working on EROFS in order to make it better
with the evolution of Linux kernel as the other in-kernel filesystems.

As Pavel suggested, it's better to do as one commit since git
can do moves and all histories will be saved in this way.

Let's promote it from staging and enhance it more actively as
a "real" part of kernel for more wider scenarios!

Cc: Greg Kroah-Hartman 
Cc: Alexander Viro 
Cc: Andrew Morton 
Cc: Stephen Rothwell 
Cc: Theodore Ts'o 
Cc: Pavel Machek 
Cc: David Sterba 
Cc: Amir Goldstein 
Cc: Christoph Hellwig 
Cc: Darrick J . Wong 
Cc: Dave Chinner 
Cc: Jaegeuk Kim 
Cc: Jan Kara 
Cc: Richard Weinberger 
Cc: Linus Torvalds 
Cc: Chao Yu 
Cc: Miao Xie 
Cc: Li Guifu 
Cc: Fang Wei 
Signed-off-by: Gao Xiang 
---
change log from v1:
 - rebase on the latest staging-next

Hi Greg,
 if something wrong of that patch v1, please apply this one
 based on the latest staging-next.

Thanks,
Gao Xiang

 .../filesystems/erofs.txt |  4 --
 MAINTAINERS   | 14 +++---
 drivers/staging/Kconfig   |  2 -
 drivers/staging/Makefile  |  1 -
 drivers/staging/erofs/TODO| 46 ---
 fs/Kconfig|  1 +
 fs/Makefile   |  1 +
 {drivers/staging => fs}/erofs/Kconfig |  0
 {drivers/staging => fs}/erofs/Makefile|  4 +-
 {drivers/staging => fs}/erofs/compress.h  |  2 -
 {drivers/staging => fs}/erofs/data.c  |  2 -
 {drivers/staging => fs}/erofs/decompressor.c  |  2 -
 {drivers/staging => fs}/erofs/dir.c   |  2 -
 {drivers/staging => fs}/erofs/erofs_fs.h  |  3 --
 {drivers/staging => fs}/erofs/inode.c |  2 -
 {drivers/staging => fs}/erofs/internal.h  |  3 +-
 {drivers/staging => fs}/erofs/namei.c |  2 -
 {drivers/staging => fs}/erofs/super.c |  2 -
 {drivers/staging => fs}/erofs/tagptr.h|  0
 {drivers/staging => fs}/erofs/utils.c |  2 -
 {drivers/staging => fs}/erofs/xattr.c |  2 -
 {drivers/staging => fs}/erofs/xattr.h |  2 -
 {drivers/staging => fs}/erofs/zdata.c |  2 -
 {drivers/staging => fs}/erofs/zdata.h |  2 -
 {drivers/staging => fs}/erofs/zmap.c  |  2 -
 {drivers/staging => fs}/erofs/zpvec.h |  2 -
 .../include => include}/trace/events/erofs.h  |  0
 include/uapi/linux/magic.h|  1 +
 28 files changed, 12 insertions(+), 96 deletions(-)
 rename {drivers/staging/erofs/Documentation => 
Documentation}/filesystems/erofs.txt (98%)
 delete mode 100644 drivers/staging/erofs/TODO
 rename {drivers/staging => fs}/erofs/Kconfig (100%)
 rename {drivers/staging => fs}/erofs/Makefile (68%)
 rename {drivers/staging => fs}/erofs/compress.h (96%)
 rename {drivers/staging => fs}/erofs/data.c (99%)
 rename {drivers/staging => fs}/erofs/decompressor.c (99%)
 rename {drivers/staging => fs}/erofs/dir.c (98%)
 rename {drivers/staging => fs}/erofs/erofs_fs.h (99%)
 rename {drivers/staging => fs}/erofs/inode.c (99%)
 rename {drivers/staging => fs}/erofs/internal.h (99%)
 rename {drivers/staging => fs}/erofs/namei.c (99%)
 rename {drivers/staging => fs}/erofs/super.c (99%)
 rename {drivers/staging => fs}/erofs/tagptr.h (100%)
 rename {drivers/staging => fs}/erofs/utils.c (99%)
 rename {drivers/staging => fs}/erofs/xattr.c (99%)
 rename {drivers/staging => fs}/erofs/xattr.h (98%)
 rename {drivers/staging => fs}/erofs/zdata.c (99%)
 rename {drivers/staging => fs}/erofs/zdata.h (99%)
 rename {drivers/staging => fs}/erofs/zmap.c (99%)
 rename {drivers/staging => fs}/erofs/zpvec.h (98%)
 rename {drivers/staging/erofs/include => include}/trace/events/erofs.h (100%)

diff --git a/drivers/staging/erofs/Documentation/filesystems/erofs.txt 
b/Documentation/filesystems/erofs.txt
similarity index 98%
rename from drivers/staging/erofs/Documentation/filesystems/erofs.txt
rename to Documentation/filesystems/erofs.txt
index 0eab600ca7ca..38aa9126ec98 100644
--- a/drivers/staging/erofs/Documentation/filesystems/erofs.txt
+++ b/Documentation/filesystems/erofs.txt
@@ -49,10 +49,6 @@ Bugs and patches are welcome, please kindly help us and send 
to the following
 linux-erofs mailing list:
 >> linux-erofs 

[PATCH 3/8] media: docs-rst: Document m2m stateless video decoder interface

[Jernej Skrabec]

From: Alexandre Courbot 

Documents the protocol that user-space should follow when
communicating with stateless video decoders.

The stateless video decoding API makes use of the new request and tags
APIs. While it has been implemented with the Cedrus driver so far, it
should probably still be considered staging for a short while.

Signed-off-by: Alexandre Courbot 
Signed-off-by: Jernej Skrabec 
---
 Documentation/media/uapi/v4l/dev-mem2mem.rst  |   1 +
 .../media/uapi/v4l/dev-stateless-decoder.rst  | 424 ++
 2 files changed, 425 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst

diff --git a/Documentation/media/uapi/v4l/dev-mem2mem.rst 
b/Documentation/media/uapi/v4l/dev-mem2mem.rst
index caa05f5f6380..70953958cee6 100644
--- a/Documentation/media/uapi/v4l/dev-mem2mem.rst
+++ b/Documentation/media/uapi/v4l/dev-mem2mem.rst
@@ -46,3 +46,4 @@ devices are given in the following sections.
 :maxdepth: 1
 
 dev-decoder
+dev-stateless-decoder
diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst 
b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
new file mode 100644
index ..4a26646eeec5
--- /dev/null
+++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
@@ -0,0 +1,424 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _stateless_decoder:
+
+**
+Memory-to-memory Stateless Video Decoder Interface
+**
+
+A stateless decoder is a decoder that works without retaining any kind of state
+between processed frames. This means that each frame is decoded independently
+of any previous and future frames, and that the client is responsible for
+maintaining the decoding state and providing it to the decoder with each
+decoding request. This is in contrast to the stateful video decoder interface,
+where the hardware and driver maintain the decoding state and all the client
+has to do is to provide the raw encoded stream and dequeue decoded frames in
+display order.
+
+This section describes how user-space ("the client") is expected to communicate
+with stateless decoders in order to successfully decode an encoded stream.
+Compared to stateful codecs, the decoder/client sequence is simpler, but the
+cost of this simplicity is extra complexity in the client which is responsible
+for maintaining a consistent decoding state.
+
+Stateless decoders make use of the :ref:`media-request-api`. A stateless
+decoder must expose the ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability on its
+``OUTPUT`` queue when :c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS`
+are invoked.
+
+Depending on the encoded formats supported by the decoder, a single decoded
+frame may be the result of several decode requests (for instance, H.264 streams
+with multiple slices per frame). Decoders that support such formats must also
+expose the ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` capability on their
+``OUTPUT`` queue.
+
+Querying capabilities
+=
+
+1. To enumerate the set of coded formats supported by the decoder, the client
+   calls :c:func:`VIDIOC_ENUM_FMT` on the ``OUTPUT`` queue.
+
+   * The driver must always return the full set of supported ``OUTPUT`` 
formats,
+ irrespective of the format currently set on the ``CAPTURE`` queue.
+
+   * Simultaneously, the driver must restrain the set of values returned by
+ codec-specific capability controls (such as H.264 profiles) to the set
+ actually supported by the hardware.
+
+2. To enumerate the set of supported raw formats, the client calls
+   :c:func:`VIDIOC_ENUM_FMT` on the ``CAPTURE`` queue.
+
+   * The driver must return only the formats supported for the format currently
+ active on the ``OUTPUT`` queue.
+
+   * Depending on the currently set ``OUTPUT`` format, the set of supported raw
+ formats may depend on the value of some codec-dependent controls.
+ The client is responsible for making sure that these controls are set
+ before querying the ``CAPTURE`` queue. Failure to do so will result in the
+ default values for these controls being used, and a returned set of 
formats
+ that may not be usable for the media the client is trying to decode.
+
+3. The client may use :c:func:`VIDIOC_ENUM_FRAMESIZES` to detect supported
+   resolutions for a given format, passing desired pixel format in
+   :c:type:`v4l2_frmsizeenum`'s ``pixel_format``.
+
+4. Supported profiles and levels for the current ``OUTPUT`` format, if
+   applicable, may be queried using their respective controls via
+   :c:func:`VIDIOC_QUERYCTRL`.
+
+Initialization
+==
+
+1. Set the coded format on the ``OUTPUT`` queue via :c:func:`VIDIOC_S_FMT`.
+
+   * **Required fields:**
+
+ ``type``
+ a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
+
+ ``pixelformat``
+ a coded pixel format.
+
+ ``width``, ``height``
+ coded width and height 

[PATCH 6/8] media: cedrus: h264: Support multiple slices per frame

[Jernej Skrabec]

With recent changes, support for decoding multi-slice frames can be
easily added now.

Signal VPU if current slice is first in frame or not and add information
about first macroblock coordinates.

Signed-off-by: Jernej Skrabec 
---
 drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
index d6a782703c9b..b7260cfeb6f4 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
@@ -301,6 +301,8 @@ static void cedrus_set_params(struct cedrus_ctx *ctx,
dma_addr_t src_buf_addr;
u32 offset = slice->header_bit_size;
u32 len = (slice->size * 8) - offset;
+   unsigned int pic_width_in_mbs;
+   bool mbaff_pic;
u32 reg;
 
cedrus_write(dev, VE_H264_VLD_LEN, len);
@@ -370,12 +372,19 @@ static void cedrus_set_params(struct cedrus_ctx *ctx,
reg |= VE_H264_SPS_DIRECT_8X8_INFERENCE;
cedrus_write(dev, VE_H264_SPS, reg);
 
+   mbaff_pic = !(slice->flags & V4L2_H264_SLICE_FLAG_FIELD_PIC) &&
+   (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD);
+   pic_width_in_mbs = sps->pic_width_in_mbs_minus1 + 1;
+
// slice parameters
reg = 0;
+   reg |= ((slice->first_mb_in_slice % pic_width_in_mbs) & 0xff) << 24;
+   reg |= (((slice->first_mb_in_slice / pic_width_in_mbs) * (mbaff_pic + 
1)) & 0xff) << 16;
reg |= decode->nal_ref_idc ? BIT(12) : 0;
reg |= (slice->slice_type & 0xf) << 8;
reg |= slice->cabac_init_idc & 0x3;
-   reg |= VE_H264_SHS_FIRST_SLICE_IN_PIC;
+   if (run->first_slice)
+   reg |= VE_H264_SHS_FIRST_SLICE_IN_PIC;
if (slice->flags & V4L2_H264_SLICE_FLAG_FIELD_PIC)
reg |= VE_H264_SHS_FIELD_PIC;
if (slice->flags & V4L2_H264_SLICE_FLAG_BOTTOM_FIELD)
-- 
2.22.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 7/8] media: cedrus: Add support for holding capture buffer

[Jernej Skrabec]

When frame contains multiple slices and driver works in slice mode, it's
more efficient to hold capture buffer in queue until all slices of a
same frame are decoded.

Add support for that to Cedrus driver by exposing and implementing
V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability.

Signed-off-by: Jernej Skrabec 
---
 drivers/staging/media/sunxi/cedrus/cedrus_dec.c   | 9 +
 drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 8 +---
 drivers/staging/media/sunxi/cedrus/cedrus_video.c | 1 +
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index d7b54accfe83..68462b99750e 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -31,6 +31,14 @@ void cedrus_device_run(void *priv)
 
run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+
+   if (v4l2_m2m_release_capture_buf(run.src, run.dst)) {
+   v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+   v4l2_m2m_buf_done(run.dst, VB2_BUF_STATE_DONE);
+   run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+   }
+   run.dst->is_held = run.src->flags & V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
+
run.first_slice =
run.src->vb2_buf.timestamp != run.dst->vb2_buf.timestamp;
 
@@ -46,6 +54,7 @@ void cedrus_device_run(void *priv)
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
run.mpeg2.quantization = cedrus_find_control_data(ctx,
V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
+   run.dst->is_held = false;
break;
 
case V4L2_PIX_FMT_H264_SLICE:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
index a942cd9bed57..99fedec80224 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
@@ -122,7 +122,7 @@ static irqreturn_t cedrus_irq(int irq, void *data)
dev->dec_ops[ctx->current_codec]->irq_clear(ctx);
 
src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
-   dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+   dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 
if (!src_buf || !dst_buf) {
v4l2_err(>v4l2_dev,
@@ -136,8 +136,10 @@ static irqreturn_t cedrus_irq(int irq, void *data)
state = VB2_BUF_STATE_DONE;
 
v4l2_m2m_buf_done(src_buf, state);
-   v4l2_m2m_buf_done(dst_buf, state);
-
+   if (!dst_buf->is_held) {
+   v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+   v4l2_m2m_buf_done(dst_buf, state);
+   }
v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
 
return IRQ_HANDLED;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index 3efd247b..5153b2bba21e 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -515,6 +515,7 @@ int cedrus_queue_init(void *priv, struct vb2_queue *src_vq,
src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
src_vq->io_modes = VB2_MMAP | VB2_DMABUF;
src_vq->drv_priv = ctx;
+   src_vq->subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
src_vq->buf_struct_size = sizeof(struct cedrus_buffer);
src_vq->min_buffers_needed = 1;
src_vq->ops = _qops;
-- 
2.22.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/8] vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF

[Jernej Skrabec]

From: Hans Verkuil 

This patch adds support for the V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF flag.
It also adds a new V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability and
a v4l2_m2m_release_capture_buf() helper function.

Drivers should set vb2_queue->subsystem_flags to
VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF to indicate support for this flag.

The device_run() function should look like this:

if (v4l2_m2m_release_capture_buf(out_vb, cap_vb)) {
v4l2_m2m_dst_buf_remove(m2m_ctx);
v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
cap_vb = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
}
cap_vb->is_held = out_vb->flags & V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;

...

v4l2_m2m_buf_done(out_vb, VB2_BUF_STATE_DONE);
if (!cap_vb->is_held) {
v4l2_m2m_dst_buf_remove(m2m_ctx);
v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
}

In order to handle the corner case where V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF
is always set for the output buffer, and you reached the last frame (so no
new output buffer will be queued with a new timestamp), the driver must
implement support for the V4L2_DEC_CMD_FLUSH command, and that should do:

struct vb2_v4l2_buffer *out_vb = v4l2_m2m_last_src_buf(m2m_ctx);
struct vb2_v4l2_buffer *cap_vb = v4l2_m2m_last_dst_buf(m2m_ctx);

if (out_vb)
out_vb->flags &= ~V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
else if (cap_vb && cap_vb->is_held)
v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);

For formats that do not support slicing (e.g. VP8), the FLUSH command
just does nothing.

Signed-off-by: Hans Verkuil 
Tested-by: Boris Brezillon 
Reviewed-by: Boris Brezillon 
[Adjust example code]
Signed-off-by: Jernej Skrabec 
---
 Documentation/media/uapi/v4l/buffer.rst   | 13 ++
 .../media/uapi/v4l/vidioc-reqbufs.rst |  6 +++
 .../media/common/videobuf2/videobuf2-v4l2.c   |  8 +++-
 include/media/v4l2-mem2mem.h  | 42 +++
 include/media/videobuf2-core.h|  3 ++
 include/media/videobuf2-v4l2.h|  5 +++
 include/uapi/linux/videodev2.h| 13 +++---
 7 files changed, 84 insertions(+), 6 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index 1cbd9cde57f3..afb03906ead9 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -607,6 +607,19 @@ Buffer Flags
applications shall use this flag for output buffers if the data in
this buffer has not been created by the CPU but by some
DMA-capable unit, in which case caches have not been used.
+* .. _`V4L2-BUF-FLAG-M2M-HOLD-CAPTURE-BUF`:
+
+  - ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF``
+  - 0x0200
+  - Only valid if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` is
+set. It is typically used with stateless decoders where multiple
+   output buffers each decode to a slice of the decoded frame.
+   Applications can set this flag when queueing the output buffer
+   to prevent the driver from dequeueing the capture buffer after
+   the output buffer has been decoded (i.e. the capture buffer is
+   'held'). If the timestamp of this output buffer differs from that
+   of the previous output buffer, then that indicates the start of a
+   new frame and the previously held capture buffer is dequeued.
 * .. _`V4L2-BUF-FLAG-LAST`:
 
   - ``V4L2_BUF_FLAG_LAST``
diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst 
b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
index d7faef10e39b..d0c643db477a 100644
--- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
+++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
@@ -125,6 +125,7 @@ aborting or finishing any DMA in progress, an implicit
 .. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
 .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
 .. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS:
+.. _V4L2-BUF-CAP-SUPPORTS-M2M-HOLD-CAPTURE-BUF:
 
 .. cssclass:: longtable
 
@@ -150,6 +151,11 @@ aborting or finishing any DMA in progress, an implicit
   - The kernel allows calling :ref:`VIDIOC_REQBUFS` while buffers are still
 mapped or exported via DMABUF. These orphaned buffers will be freed
 when they are unmapped or when the exported DMABUF fds are closed.
+* - ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF``
+  - 0x0020
+  - Only valid for stateless decoders. If set, then userspace can set the
+``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag to hold off on returning 
the
+   capture buffer until the OUTPUT timestamp changes.
 
 Return Value
 
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 5a9ba3846f0a..699787f48f46 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -50,7 +50,8 @@ module_param(debug, int, 0644);
 V4L2_BUF_FLAG_TIMESTAMP_MASK)
 /* Output 

[PATCH 8/8] media: cedrus: Add support for V4L2_DEC_CMD_FLUSH

[Jernej Skrabec]

This command is useful for explicitly flushing last decoded frame.

Signed-off-by: Jernej Skrabec 
---
 .../staging/media/sunxi/cedrus/cedrus_video.c | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index 5153b2bba21e..9eae69d5741c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -331,6 +331,37 @@ static int cedrus_s_fmt_vid_out(struct file *file, void 
*priv,
return 0;
 }
 
+static int cedrus_try_decoder_cmd(struct file *file, void *fh,
+ struct v4l2_decoder_cmd *dc)
+{
+   if (dc->cmd != V4L2_DEC_CMD_FLUSH)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int cedrus_decoder_cmd(struct file *file, void *fh,
+ struct v4l2_decoder_cmd *dc)
+{
+   struct cedrus_ctx *ctx = cedrus_file2ctx(file);
+   struct vb2_v4l2_buffer *out_vb, *cap_vb;
+   int ret;
+
+   ret = cedrus_try_decoder_cmd(file, fh, dc);
+   if (ret < 0)
+   return ret;
+
+   out_vb = v4l2_m2m_last_src_buf(ctx->fh.m2m_ctx);
+   cap_vb = v4l2_m2m_last_dst_buf(ctx->fh.m2m_ctx);
+
+   if (out_vb)
+   out_vb->flags &= ~V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
+   else if (cap_vb && cap_vb->is_held)
+   v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
+
+   return 0;
+}
+
 const struct v4l2_ioctl_ops cedrus_ioctl_ops = {
.vidioc_querycap= cedrus_querycap,
 
@@ -355,6 +386,9 @@ const struct v4l2_ioctl_ops cedrus_ioctl_ops = {
.vidioc_streamon= v4l2_m2m_ioctl_streamon,
.vidioc_streamoff   = v4l2_m2m_ioctl_streamoff,
 
+   .vidioc_try_decoder_cmd = cedrus_try_decoder_cmd,
+   .vidioc_decoder_cmd = cedrus_decoder_cmd,
+
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
.vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
 };
-- 
2.22.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/8] videodev2.h: add V4L2_DEC_CMD_FLUSH

[Jernej Skrabec]

From: Hans Verkuil 

Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.

Signed-off-by: Hans Verkuil 
Signed-off-by: Jernej Skrabec 
---
 Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++-
 Documentation/media/videodev2.h.rst.exceptions  |  1 +
 include/uapi/linux/videodev2.h  |  1 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst 
b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
index 57f0066f4cff..0bffef6058f7 100644
--- a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
+++ b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
@@ -208,7 +208,16 @@ introduced in Linux 3.3. They are, however, mandatory for 
stateful mem2mem decod
been started yet, the driver will return an ``EPERM`` error code. When
the decoder is already running, this command does nothing. No
flags are defined for this command.
-
+* - ``V4L2_DEC_CMD_FLUSH``
+  - 4
+  - Flush any held capture buffers. Only valid for stateless decoders,
+and only if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` was set.
+   This command is typically used when the application reached the
+   end of the stream and the last output buffer had the
+   ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
+   dequeueing the last capture buffer containing the last decoded frame.
+   So this command can be used to explicitly flush that last decoded
+   frame.
 
 Return Value
 
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index adeb6b7a15cb..a79028e4d929 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -434,6 +434,7 @@ replace define V4L2_DEC_CMD_START decoder-cmds
 replace define V4L2_DEC_CMD_STOP decoder-cmds
 replace define V4L2_DEC_CMD_PAUSE decoder-cmds
 replace define V4L2_DEC_CMD_RESUME decoder-cmds
+replace define V4L2_DEC_CMD_FLUSH decoder-cmds
 
 replace define V4L2_DEC_CMD_START_MUTE_AUDIO decoder-cmds
 replace define V4L2_DEC_CMD_PAUSE_TO_BLACK decoder-cmds
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 4fa9f543742d..91a79e16089c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1978,6 +1978,7 @@ struct v4l2_encoder_cmd {
 #define V4L2_DEC_CMD_STOP(1)
 #define V4L2_DEC_CMD_PAUSE   (2)
 #define V4L2_DEC_CMD_RESUME  (3)
+#define V4L2_DEC_CMD_FLUSH   (4)
 
 /* Flags for V4L2_DEC_CMD_START */
 #define V4L2_DEC_CMD_START_MUTE_AUDIO  (1 << 0)
-- 
2.22.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/8] media: docs-rst: Document memory-to-memory video encoder interface

[Jernej Skrabec]

From: Tomasz Figa 

Due to complexity of the video encoding process, the V4L2 drivers of
stateful encoder hardware require specific sequences of V4L2 API calls
to be followed. These include capability enumeration, initialization,
encoding, encode parameters change, drain and reset.

Specifics of the above have been discussed during Media Workshops at
LinuxCon Europe 2012 in Barcelona and then later Embedded Linux
Conference Europe 2014 in Düsseldorf. The de facto Codec API that
originated at those events was later implemented by the drivers we already
have merged in mainline, such as s5p-mfc or coda.

The only thing missing was the real specification included as a part of
Linux Media documentation. Fix it now and document the encoder part of
the Codec API.

Signed-off-by: Tomasz Figa 
Signed-off-by: Hans Verkuil 
Signed-off-by: Jernej Skrabec 
---
 Documentation/media/uapi/v4l/dev-encoder.rst  | 608 ++
 Documentation/media/uapi/v4l/dev-mem2mem.rst  |   1 +
 Documentation/media/uapi/v4l/pixfmt-v4l2.rst  |   5 +
 Documentation/media/uapi/v4l/v4l2.rst |   2 +
 .../media/uapi/v4l/vidioc-encoder-cmd.rst |  51 +-
 5 files changed, 647 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/dev-encoder.rst

diff --git a/Documentation/media/uapi/v4l/dev-encoder.rst 
b/Documentation/media/uapi/v4l/dev-encoder.rst
new file mode 100644
index ..e9d29d6de67a
--- /dev/null
+++ b/Documentation/media/uapi/v4l/dev-encoder.rst
@@ -0,0 +1,608 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _encoder:
+
+*
+Memory-to-Memory Stateful Video Encoder Interface
+*
+
+A stateful video encoder takes raw video frames in display order and encodes
+them into a bytestream. It generates complete chunks of the bytestream, 
including
+all metadata, headers, etc. The resulting bytestream does not require any
+further post-processing by the client.
+
+Performing software stream processing, header generation etc. in the driver
+in order to support this interface is strongly discouraged. In case such
+operations are needed, use of the Stateless Video Encoder Interface (in
+development) is strongly advised.
+
+Conventions and Notations Used in This Document
+===
+
+1. The general V4L2 API rules apply if not specified in this document
+   otherwise.
+
+2. The meaning of words "must", "may", "should", etc. is as per `RFC
+   2119 `_.
+
+3. All steps not marked "optional" are required.
+
+4. :c:func:`VIDIOC_G_EXT_CTRLS` and :c:func:`VIDIOC_S_EXT_CTRLS` may be used
+   interchangeably with :c:func:`VIDIOC_G_CTRL` and :c:func:`VIDIOC_S_CTRL`,
+   unless specified otherwise.
+
+5. Single-planar API (see :ref:`planar-apis`) and applicable structures may be
+   used interchangeably with multi-planar API, unless specified otherwise,
+   depending on encoder capabilities and following the general V4L2 guidelines.
+
+6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i =
+   [0..2]: i = 0, 1, 2.
+
+7. Given an ``OUTPUT`` buffer A, then A’ represents a buffer on the ``CAPTURE``
+   queue containing data that resulted from processing buffer A.
+
+Glossary
+
+
+Refer to :ref:`decoder-glossary`.
+
+State Machine
+=
+
+.. kernel-render:: DOT
+   :alt: DOT digraph of encoder state machine
+   :caption: Encoder State Machine
+
+   digraph encoder_state_machine {
+   node [shape = doublecircle, label="Encoding"] Encoding;
+
+   node [shape = circle, label="Initialization"] Initialization;
+   node [shape = circle, label="Stopped"] Stopped;
+   node [shape = circle, label="Drain"] Drain;
+   node [shape = circle, label="Reset"] Reset;
+
+   node [shape = point]; qi
+   qi -> Initialization [ label = "open()" ];
+
+   Initialization -> Encoding [ label = "Both queues streaming" ];
+
+   Encoding -> Drain [ label = "V4L2_ENC_CMD_STOP" ];
+   Encoding -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
+   Encoding -> Stopped [ label = "VIDIOC_STREAMOFF(OUTPUT)" ];
+   Encoding -> Encoding;
+
+   Drain -> Stopped [ label = "All CAPTURE\nbuffers 
dequeued\nor\nVIDIOC_STREAMOFF(OUTPUT)" ];
+   Drain -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
+
+   Reset -> Encoding [ label = "VIDIOC_STREAMON(CAPTURE)" ];
+   Reset -> Initialization [ label = "VIDIOC_REQBUFS(OUTPUT, 0)" ];
+
+   Stopped -> Encoding [ label = 
"V4L2_ENC_CMD_START\nor\nVIDIOC_STREAMON(OUTPUT)" ];
+   Stopped -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
+   }
+
+Querying Capabilities
+=
+
+1. To enumerate the set of coded formats supported by the encoder, the
+   client may call :c:func:`VIDIOC_ENUM_FMT` on ``CAPTURE``.
+
+   * The full set of supported formats will be returned, regardless of the
+ format set on ``OUTPUT``.
+
+2. To 

[PATCH 0/8] media: cedrus: h264: Support multi-slice frames

[Jernej Skrabec]

This series is continuation of work from
https://patchwork.linuxtv.org/cover/58186/

It picks up unmerged patches (9-12) from aforementioned series and
adds support for decoding multi-slice H264 frames along with support
for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF in
Cedrus driver.

Code was tested by modified ffmpeg, which can be found here:
https://github.com/jernejsk/FFmpeg, branch mainline-test
It has to be configured with at least following options:
--enable-v4l2-request --enable-libudev --enable-libdrm

Samples used for testing:
http://jernej.libreelec.tv/videos/h264/BA1_FT_C.mp4
http://jernej.libreelec.tv/videos/h264/h264.mp4

Command line used for testing:
ffmpeg -hwaccel drm -hwaccel_device /dev/dri/card0 -i h264.mp4 -pix_fmt bgra -f 
fbdev /dev/fb0

Please note that V4L2_DEC_CMD_FLUSH was not tested because I'm
not sure how. ffmpeg follows exactly which slice is last in frame
and sets hold flag accordingly. Improper usage of hold flag would
corrupt ffmpeg assumptions and it would probably crash. Any ideas
how to test this are welcome!

Thanks to Jonas for adjusting ffmpeg.

Please let me know what you think.

Best regards,
Jernej

Alexandre Courbot (1):
  media: docs-rst: Document m2m stateless video decoder interface

Hans Verkuil (2):
  vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF
  videodev2.h: add V4L2_DEC_CMD_FLUSH

Jernej Skrabec (4):
  media: cedrus: Detect first slice of a frame
  media: cedrus: h264: Support multiple slices per frame
  media: cedrus: Add support for holding capture buffer
  media: cedrus: Add support for V4L2_DEC_CMD_FLUSH

Tomasz Figa (1):
  media: docs-rst: Document memory-to-memory video encoder interface

 Documentation/media/uapi/v4l/buffer.rst   |  13 +
 Documentation/media/uapi/v4l/dev-encoder.rst  | 608 ++
 Documentation/media/uapi/v4l/dev-mem2mem.rst  |   2 +
 .../media/uapi/v4l/dev-stateless-decoder.rst  | 424 
 Documentation/media/uapi/v4l/pixfmt-v4l2.rst  |   5 +
 Documentation/media/uapi/v4l/v4l2.rst |   2 +
 .../media/uapi/v4l/vidioc-decoder-cmd.rst |  11 +-
 .../media/uapi/v4l/vidioc-encoder-cmd.rst |  51 +-
 .../media/uapi/v4l/vidioc-reqbufs.rst |   6 +
 .../media/videodev2.h.rst.exceptions  |   1 +
 .../media/common/videobuf2/videobuf2-v4l2.c   |   8 +-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |   1 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  11 +
 .../staging/media/sunxi/cedrus/cedrus_h264.c  |  11 +-
 .../staging/media/sunxi/cedrus/cedrus_hw.c|   8 +-
 .../staging/media/sunxi/cedrus/cedrus_video.c |  35 +
 include/media/v4l2-mem2mem.h  |  42 ++
 include/media/videobuf2-core.h|   3 +
 include/media/videobuf2-v4l2.h|   5 +
 include/uapi/linux/videodev2.h|  14 +-
 20 files changed, 1230 insertions(+), 31 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/dev-encoder.rst
 create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst

-- 
2.22.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/8] media: cedrus: Detect first slice of a frame

[Jernej Skrabec]

When codec supports multiple slices in one frame, VPU has to know when
first slice of each frame is being processed, presumably to correctly
clear/set data in auxiliary buffers.

Add first_slice field to cedrus_run structure and set it according to
timestamps of capture and output buffers. If timestamps are different,
it's first slice and viceversa.

Signed-off-by: Jernej Skrabec 
---
 drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
 drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 2f017a651848..32cb38e541c6 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
 struct cedrus_run {
struct vb2_v4l2_buffer  *src;
struct vb2_v4l2_buffer  *dst;
+   bool first_slice;
 
union {
struct cedrus_h264_run  h264;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index 56ca4c9ad01c..d7b54accfe83 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
 
run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+   run.first_slice =
+   run.src->vb2_buf.timestamp != run.dst->vb2_buf.timestamp;
 
/* Apply request(s) controls if needed. */
src_req = run.src->vb2_buf.req_obj.req;
-- 
2.22.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8192u: Add space around binary operators

[Sumera Priyadarsini]

This patch fixes the file r8180_93cx6.c to avoid the checkpatch.pl warnings:

CHECK: spaces preferred around that '<<' (ctx:VxV)
CHECK: spaces preferred around that '-' (ctx:VxV)

Signed-off-by: Sumera Priyadarsini 
---
 drivers/staging/rtl8192u/r8180_93cx6.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8180_93cx6.c 
b/drivers/staging/rtl8192u/r8180_93cx6.c
index 6ebf121eac0c..2527cea60e3e 100644
--- a/drivers/staging/rtl8192u/r8180_93cx6.c
+++ b/drivers/staging/rtl8192u/r8180_93cx6.c
@@ -114,7 +114,7 @@ int eprom_read(struct net_device *dev, u32 addr)
ret = 0;
/* enable EPROM programming */
write_nic_byte_E(dev, EPROM_CMD,
-  (EPROM_CMD_PROGRAM

[PATCH] staging: rtl8192u: Fix indentation

[Stephen Brennan]

Checkpatch reports WARNING:SUSPECT_CODE_INDENT in several places. Fix
this by aligning code properly with tabs.

Signed-off-by: Stephen Brennan 
---
 .../rtl8192u/ieee80211/ieee80211_crypt_ccmp.c |   2 +-
 .../staging/rtl8192u/ieee80211/ieee80211_rx.c | 112 +-
 .../staging/rtl8192u/ieee80211/ieee80211_tx.c |  18 +--
 .../staging/rtl8192u/ieee80211/ieee80211_wx.c |   8 +-
 drivers/staging/rtl8192u/r819xU_firmware.c|   2 +-
 5 files changed, 71 insertions(+), 71 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
index aecee42be95e..369c57b63350 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
@@ -346,7 +346,7 @@ static int ieee80211_ccmp_set_key(void *key, int len, u8 
*seq, void *priv)
}
if (crypto_aead_setauthsize(tfm, CCMP_MIC_LEN) ||
crypto_aead_setkey(tfm, data->key, CCMP_TK_LEN))
-   return -1;
+   return -1;
} else if (len == 0) {
data->key_set = 0;
} else {
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index 7ef1e89de269..643e40e4c5fe 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -103,17 +103,17 @@ ieee80211_frag_cache_get(struct ieee80211_device *ieee,
u8 tid;
 
if (((fc & IEEE80211_FCTL_DSTODS) == IEEE80211_FCTL_DSTODS) && 
IEEE80211_QOS_HAS_SEQ(fc)) {
- hdr_4addrqos = (struct rtl_80211_hdr_4addrqos *)hdr;
- tid = le16_to_cpu(hdr_4addrqos->qos_ctl) & IEEE80211_QCTL_TID;
- tid = UP2AC(tid);
- tid++;
+   hdr_4addrqos = (struct rtl_80211_hdr_4addrqos *)hdr;
+   tid = le16_to_cpu(hdr_4addrqos->qos_ctl) & IEEE80211_QCTL_TID;
+   tid = UP2AC(tid);
+   tid++;
} else if (IEEE80211_QOS_HAS_SEQ(fc)) {
- hdr_3addrqos = (struct rtl_80211_hdr_3addrqos *)hdr;
- tid = le16_to_cpu(hdr_3addrqos->qos_ctl) & IEEE80211_QCTL_TID;
- tid = UP2AC(tid);
- tid++;
+   hdr_3addrqos = (struct rtl_80211_hdr_3addrqos *)hdr;
+   tid = le16_to_cpu(hdr_3addrqos->qos_ctl) & IEEE80211_QCTL_TID;
+   tid = UP2AC(tid);
+   tid++;
} else {
- tid = 0;
+   tid = 0;
}
 
if (frag == 0) {
@@ -170,17 +170,17 @@ static int ieee80211_frag_cache_invalidate(struct 
ieee80211_device *ieee,
u8 tid;
 
if (((fc & IEEE80211_FCTL_DSTODS) == IEEE80211_FCTL_DSTODS) && 
IEEE80211_QOS_HAS_SEQ(fc)) {
- hdr_4addrqos = (struct rtl_80211_hdr_4addrqos *)hdr;
- tid = le16_to_cpu(hdr_4addrqos->qos_ctl) & IEEE80211_QCTL_TID;
- tid = UP2AC(tid);
- tid++;
+   hdr_4addrqos = (struct rtl_80211_hdr_4addrqos *)hdr;
+   tid = le16_to_cpu(hdr_4addrqos->qos_ctl) & IEEE80211_QCTL_TID;
+   tid = UP2AC(tid);
+   tid++;
} else if (IEEE80211_QOS_HAS_SEQ(fc)) {
- hdr_3addrqos = (struct rtl_80211_hdr_3addrqos *)hdr;
- tid = le16_to_cpu(hdr_3addrqos->qos_ctl) & IEEE80211_QCTL_TID;
- tid = UP2AC(tid);
- tid++;
+   hdr_3addrqos = (struct rtl_80211_hdr_3addrqos *)hdr;
+   tid = le16_to_cpu(hdr_3addrqos->qos_ctl) & IEEE80211_QCTL_TID;
+   tid = UP2AC(tid);
+   tid++;
} else {
- tid = 0;
+   tid = 0;
}
 
entry = ieee80211_frag_cache_find(ieee, seq, -1, tid, hdr->addr2,
@@ -427,17 +427,17 @@ static int is_duplicate_packet(struct ieee80211_device 
*ieee,
 
//TO2DS and QoS
if (((fc & IEEE80211_FCTL_DSTODS) == IEEE80211_FCTL_DSTODS) && 
IEEE80211_QOS_HAS_SEQ(fc)) {
- hdr_4addrqos = (struct rtl_80211_hdr_4addrqos *)header;
- tid = le16_to_cpu(hdr_4addrqos->qos_ctl) & IEEE80211_QCTL_TID;
- tid = UP2AC(tid);
- tid++;
+   hdr_4addrqos = (struct rtl_80211_hdr_4addrqos *)header;
+   tid = le16_to_cpu(hdr_4addrqos->qos_ctl) & IEEE80211_QCTL_TID;
+   tid = UP2AC(tid);
+   tid++;
} else if (IEEE80211_QOS_HAS_SEQ(fc)) { //QoS
- hdr_3addrqos = (struct rtl_80211_hdr_3addrqos *)header;
- tid = le16_to_cpu(hdr_3addrqos->qos_ctl) & IEEE80211_QCTL_TID;
- tid = UP2AC(tid);
- tid++;
+   hdr_3addrqos = (struct rtl_80211_hdr_3addrqos *)header;
+   tid = le16_to_cpu(hdr_3addrqos->qos_ctl) & IEEE80211_QCTL_TID;
+   tid = UP2AC(tid);
+   tid++;
} else { // no QoS
- tid = 0;
+   tid = 0;
}
 
switch (ieee->iw_mode) {
@@ -999,7 +999,7 @@ int ieee80211_rx(struct 

Re: WARNING in rollback_registered_many (2)

[Andrey Konovalov]

On Thu, Aug 22, 2019 at 3:07 PM Andrey Konovalov  wrote:
>
> On Wed, Aug 7, 2019 at 4:03 PM Andrey Konovalov  wrote:
> >
> > On Fri, Apr 12, 2019 at 1:32 PM Andrey Konovalov  
> > wrote:
> > >
> > > On Fri, Apr 12, 2019 at 1:29 AM syzbot
> > >  wrote:
> > > >
> > > > syzbot has found a reproducer for the following crash on:
> > > >
> > > > HEAD commit:9a33b369 usb-fuzzer: main usb gadget fuzzer driver
> > > > git tree:   https://github.com/google/kasan/tree/usb-fuzzer
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=10d552b720
> > > > kernel config:  
> > > > https://syzkaller.appspot.com/x/.config?x=23e37f59d94ddd15
> > > > dashboard link: 
> > > > https://syzkaller.appspot.com/bug?extid=40918e4d826fb2ff9b96
> > > > compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> > > > syz repro:  
> > > > https://syzkaller.appspot.com/x/repro.syz?x=17a4c1af20
> > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=121b274b20
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the 
> > > > commit:
> > > > Reported-by: syzbot+40918e4d826fb2ff9...@syzkaller.appspotmail.com
> > > >
> > > > usb 1-1: r8712u: MAC Address from efuse = 00:e0:4c:87:00:00
> > > > usb 1-1: r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
> > > > usb 1-1: USB disconnect, device number 2
> > > > usb 1-1: Direct firmware load for rtlwifi/rtl8712u.bin failed with 
> > > > error -2
> > > > usb 1-1: r8712u: Firmware request failed
> > > > WARNING: CPU: 0 PID: 575 at net/core/dev.c:8152
> > > > rollback_registered_many+0x1f3/0xe70 net/core/dev.c:8152
> > > > Kernel panic - not syncing: panic_on_warn set ...
> > > > CPU: 0 PID: 575 Comm: kworker/0:4 Not tainted 5.1.0-rc4-319354-g9a33b36 
> > > > #3
> > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > Google 01/01/2011
> > > > Workqueue: usb_hub_wq hub_event
> > > > Call Trace:
> > > >   __dump_stack lib/dump_stack.c:77 [inline]
> > > >   dump_stack+0xe8/0x16e lib/dump_stack.c:113
> > > >   panic+0x29d/0x5f2 kernel/panic.c:214
> > > >   __warn.cold+0x20/0x48 kernel/panic.c:571
> > > >   report_bug+0x262/0x2a0 lib/bug.c:186
> > > >   fixup_bug arch/x86/kernel/traps.c:179 [inline]
> > > >   fixup_bug arch/x86/kernel/traps.c:174 [inline]
> > > >   do_error_trap+0x130/0x1f0 arch/x86/kernel/traps.c:272
> > > >   do_invalid_op+0x37/0x40 arch/x86/kernel/traps.c:291
> > > >   invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
> > > > RIP: 0010:rollback_registered_many+0x1f3/0xe70 net/core/dev.c:8152
> > > > Code: 05 00 00 31 ff 44 89 fe e8 5a 15 f3 f4 45 84 ff 0f 85 49 ff ff ff 
> > > > e8
> > > > 1c 14 f3 f4 0f 1f 44 00 00 e8 12 14 f3 f4 e8 0d 14 f3 f4 <0f> 0b 4c 89 
> > > > e7
> > > > e8 33 72 f2 f6 31 ff 41 89 c4 89 c6 e8 27 15 f3 f4
> > > > RSP: 0018:88809d087698 EFLAGS: 00010293
> > > > RAX: 88809d058000 RBX: 88809624 RCX: 8c7eb146
> > > > RDX:  RSI: 8c7eb163 RDI: 0001
> > > > RBP: 88809d0877c8 R08: 88809d058000 R09: fbfff2708111
> > > > R10: fbfff2708110 R11: 93840887 R12: 888096240070
> > > > R13: dc00 R14: 88809d087758 R15: 
> > > >   rollback_registered+0xf7/0x1c0 net/core/dev.c:8228
> > > >   unregister_netdevice_queue net/core/dev.c:9275 [inline]
> > > >   unregister_netdevice_queue+0x1dc/0x2b0 net/core/dev.c:9268
> > > >   unregister_netdevice include/linux/netdevice.h:2655 [inline]
> > > >   unregister_netdev+0x1d/0x30 net/core/dev.c:9316
> > > >   r871xu_dev_remove+0xe7/0x223 drivers/staging/rtl8712/usb_intf.c:604
> > > >   usb_unbind_interface+0x1c9/0x980 drivers/usb/core/driver.c:423
> > > >   __device_release_driver drivers/base/dd.c:1082 [inline]
> > > >   device_release_driver_internal+0x436/0x4f0 drivers/base/dd.c:1113
> > > >   bus_remove_device+0x302/0x5c0 drivers/base/bus.c:556
> > > >   device_del+0x467/0xb90 drivers/base/core.c:2269
> > > >   usb_disable_device+0x242/0x790 drivers/usb/core/message.c:1235
> > > >   usb_disconnect+0x298/0x870 drivers/usb/core/hub.c:2197
> > > >   hub_port_connect drivers/usb/core/hub.c:4940 [inline]
> > > >   hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
> > > >   port_event drivers/usb/core/hub.c:5350 [inline]
> > > >   hub_event+0xcd2/0x3b00 drivers/usb/core/hub.c:5432
> > > >   process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
> > > >   process_scheduled_works kernel/workqueue.c:2331 [inline]
> > > >   worker_thread+0x7b0/0xe20 kernel/workqueue.c:2417
> > > >   kthread+0x313/0x420 kernel/kthread.c:253
> > > >   ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
> > > > Kernel Offset: disabled
> > > > Rebooting in 86400 seconds..
> > > >
> > >
> > > +linux-usb mailing list
> >
> > This USB bug is the most frequently triggered one right now with over
> > 27k kernel crashes.
>
> OK, this report is confusing. It was initially reported on the
> upstream instance a long time ago, but since then has 

[PATCH] staging: rtl8192u: Remove unnecessary blank lines

[Sumera Priyadarsini]

This patch fixes the file r8180_93cx6.c to avoid the checkpatch.pl warning:

CHECK: Please don't use multiple blank lines

Signed-off-by: Sumera Priyadarsini 
---
 drivers/staging/rtl8192u/r8180_93cx6.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8180_93cx6.c 
b/drivers/staging/rtl8192u/r8180_93cx6.c
index de83daa0c9ed..6ebf121eac0c 100644
--- a/drivers/staging/rtl8192u/r8180_93cx6.c
+++ b/drivers/staging/rtl8192u/r8180_93cx6.c
@@ -39,7 +39,6 @@ static void eprom_cs(struct net_device *dev, short bit)
udelay(EPROM_DELAY);
 }
 
-
 static void eprom_ck_cycle(struct net_device *dev)
 {
u8 cmdreg;
@@ -58,7 +57,6 @@ static void eprom_ck_cycle(struct net_device *dev)
udelay(EPROM_DELAY);
 }
 
-
 static void eprom_w(struct net_device *dev, short bit)
 {
u8 cmdreg;
@@ -76,7 +74,6 @@ static void eprom_w(struct net_device *dev, short bit)
udelay(EPROM_DELAY);
 }
 
-
 static short eprom_r(struct net_device *dev)
 {
u8 bit;
@@ -94,7 +91,6 @@ static short eprom_r(struct net_device *dev)
return 0;
 }
 
-
 static void eprom_send_bits_string(struct net_device *dev, short b[], int len)
 {
int i;
@@ -105,7 +101,6 @@ static void eprom_send_bits_string(struct net_device *dev, 
short b[], int len)
}
 }
 
-
 int eprom_read(struct net_device *dev, u32 addr)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: WARNING in r871xu_dev_remove

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer still triggered  
crash:

KASAN: use-after-free Read in device_release_driver_internal

==
BUG: KASAN: use-after-free in __mutex_lock_common  
kernel/locking/mutex.c:912 [inline]
BUG: KASAN: use-after-free in __mutex_lock+0xf23/0x1360  
kernel/locking/mutex.c:1077

Read of size 8 at addr 8881d644bd78 by task kworker/0:4/2855

CPU: 0 PID: 2855 Comm: kworker/0:4 Not tainted 5.3.0-rc5+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xca/0x13e lib/dump_stack.c:113
 print_address_description+0x6a/0x32c mm/kasan/report.c:351
 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
 kasan_report+0xe/0x12 mm/kasan/common.c:612
 __mutex_lock_common kernel/locking/mutex.c:912 [inline]
 __mutex_lock+0xf23/0x1360 kernel/locking/mutex.c:1077
 device_release_driver_internal+0x23/0x500 drivers/base/dd.c:1162
 bus_remove_device+0x2dc/0x4a0 drivers/base/bus.c:556
 device_del+0x420/0xb10 drivers/base/core.c:2339
 usb_disconnect+0x4c3/0x8d0 drivers/usb/core/hub.c:2225
 hub_port_connect drivers/usb/core/hub.c:4949 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
 port_event drivers/usb/core/hub.c:5359 [inline]
 hub_event+0x1454/0x3640 drivers/usb/core/hub.c:5441
 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
 worker_thread+0x96/0xe20 kernel/workqueue.c:2415
 kthread+0x318/0x420 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

Allocated by task 12:
 save_stack+0x1b/0x80 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_kmalloc mm/kasan/common.c:487 [inline]
 __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
 kmalloc include/linux/slab.h:552 [inline]
 kzalloc include/linux/slab.h:748 [inline]
 usb_alloc_dev+0x51/0xf95 drivers/usb/core/usb.c:583
 hub_port_connect drivers/usb/core/hub.c:5004 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
 port_event drivers/usb/core/hub.c:5359 [inline]
 hub_event+0x15c0/0x3640 drivers/usb/core/hub.c:5441
 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
 worker_thread+0x96/0xe20 kernel/workqueue.c:2415
 kthread+0x318/0x420 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

Freed by task 2855:
 save_stack+0x1b/0x80 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
 slab_free_hook mm/slub.c:1423 [inline]
 slab_free_freelist_hook mm/slub.c:1474 [inline]
 slab_free mm/slub.c:3016 [inline]
 kfree+0xe4/0x2f0 mm/slub.c:3957
 device_release+0x71/0x200 drivers/base/core.c:1064
 kobject_cleanup lib/kobject.c:693 [inline]
 kobject_release lib/kobject.c:722 [inline]
 kref_put include/linux/kref.h:65 [inline]
 kobject_put+0x171/0x280 lib/kobject.c:739
 put_device+0x1b/0x30 drivers/base/core.c:2264
 klist_put+0xce/0x170 lib/klist.c:221
 bus_remove_device+0x3a4/0x4a0 drivers/base/bus.c:552
 device_del+0x420/0xb10 drivers/base/core.c:2339
 usb_disconnect+0x4c3/0x8d0 drivers/usb/core/hub.c:2225
 hub_port_connect drivers/usb/core/hub.c:4949 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
 port_event drivers/usb/core/hub.c:5359 [inline]
 hub_event+0x1454/0x3640 drivers/usb/core/hub.c:5441
 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
 worker_thread+0x96/0xe20 kernel/workqueue.c:2415
 kthread+0x318/0x420 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

The buggy address belongs to the object at 8881d644bb80
 which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 504 bytes inside of
 2048-byte region [8881d644bb80, 8881d644c380)
The buggy address belongs to the page:
page:ea0007591200 refcount:1 mapcount:0 mapping:8881da00c000  
index:0x8881d6448000 compound_mapcount: 0

flags: 0x2010200(slab|head)
raw: 02010200 ea000760ac00 00020002 8881da00c000
raw: 8881d6448000 800f000a 0001 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 8881d644bc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 8881d644bc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

8881d644bd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

^
 8881d644bd80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 8881d644be00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==


Tested on:

commit: eea39f24 usb-fuzzer: main usb gadget fuzzer driver
git tree:   https://github.com/google/kasan.git
console output: https://syzkaller.appspot.com/x/log.txt?x=1018661e60
kernel config:  

Re: WARNING in r871xu_dev_remove

[Oliver Neukum]

Am Donnerstag, den 22.08.2019, 07:28 -0700 schrieb syzbot:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:eea39f24 usb-fuzzer: main usb gadget fuzzer driver
> git tree:   https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=163ae01260
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d0c62209eedfd54e
> dashboard link: https://syzkaller.appspot.com/bug?extid=80899a8a8efe8968cde7
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1739cb0e60
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=154fcc2e60
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+80899a8a8efe8968c...@syzkaller.appspotmail.com

#syz test: https://github.com/google/kasan.git eea39f24

>From 4f21b5aabc448719aa612b9359d90a178cb485d8 Mon Sep 17 00:00:00 2001
From: Oliver Neukum 
Date: Thu, 22 Aug 2019 16:37:33 +0200
Subject: [PATCH] rtl8712: fix race between firmware failing to load and
 disconnect

We have to wait for the attempt to load the firmware to finish
before we evaluate the result.

Reported-by: syzbot+80899a8a8efe8968c...@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum 
---
 drivers/staging/rtl8712/hal_init.c | 3 ++-
 drivers/staging/rtl8712/usb_intf.c | 8 ++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8712/hal_init.c 
b/drivers/staging/rtl8712/hal_init.c
index 40145c0338e4..42c0a3c947f1 100644
--- a/drivers/staging/rtl8712/hal_init.c
+++ b/drivers/staging/rtl8712/hal_init.c
@@ -33,7 +33,6 @@ static void rtl871x_load_fw_cb(const struct firmware 
*firmware, void *context)
 {
struct _adapter *adapter = context;
 
-   complete(>rtl8712_fw_ready);
if (!firmware) {
struct usb_device *udev = adapter->dvobjpriv.pusbdev;
struct usb_interface *usb_intf = adapter->pusb_intf;
@@ -41,11 +40,13 @@ static void rtl871x_load_fw_cb(const struct firmware 
*firmware, void *context)
dev_err(>dev, "r8712u: Firmware request failed\n");
usb_put_dev(udev);
usb_set_intfdata(usb_intf, NULL);
+   complete(>rtl8712_fw_ready);
return;
}
adapter->fw = firmware;
/* firmware available - start netdev */
register_netdev(adapter->pnetdev);
+   complete(>rtl8712_fw_ready);
 }
 
 static const char firmware_file[] = "rtlwifi/rtl8712u.bin";
diff --git a/drivers/staging/rtl8712/usb_intf.c 
b/drivers/staging/rtl8712/usb_intf.c
index d0daae0b8299..8d7b57073592 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -595,10 +595,13 @@ static void r871xu_dev_remove(struct usb_interface 
*pusb_intf)
if (pnetdev) {
struct _adapter *padapter = netdev_priv(pnetdev);
 
-   usb_set_intfdata(pusb_intf, NULL);
-   release_firmware(padapter->fw);
/* never exit with a firmware callback pending */
wait_for_completion(>rtl8712_fw_ready);
+   pnetdev = usb_get_intfdata(pusb_intf);
+   usb_set_intfdata(pusb_intf, NULL);
+   if (!pnetdev)
+   goto raced_with_firmware_failure;
+   release_firmware(padapter->fw);
if (drvpriv.drv_registered)
padapter->surprise_removed = true;
unregister_netdev(pnetdev); /* will call netdev_close() */
@@ -609,6 +612,7 @@ static void r871xu_dev_remove(struct usb_interface 
*pusb_intf)
r871x_dev_unload(padapter);
r8712_free_drv_sw(padapter);
 
+raced_with_firmware_failure:
/* decrease the reference count of the usb device structure
 * when disconnect
 */
-- 
2.16.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WARNING in r871xu_dev_remove

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:eea39f24 usb-fuzzer: main usb gadget fuzzer driver
git tree:   https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=163ae01260
kernel config:  https://syzkaller.appspot.com/x/.config?x=d0c62209eedfd54e
dashboard link: https://syzkaller.appspot.com/bug?extid=80899a8a8efe8968cde7
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1739cb0e60
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=154fcc2e60

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+80899a8a8efe8968c...@syzkaller.appspotmail.com

[ cut here ]
WARNING: CPU: 1 PID: 83 at net/core/dev.c:8167  
rollback_registered_many.cold+0x41/0x1bc net/core/dev.c:8167

Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 83 Comm: kworker/1:2 Not tainted 5.3.0-rc5+ #28
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xca/0x13e lib/dump_stack.c:113
 panic+0x2a3/0x6da kernel/panic.c:219
 __warn.cold+0x20/0x4a kernel/panic.c:576
 report_bug+0x262/0x2a0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:179 [inline]
 fixup_bug arch/x86/kernel/traps.c:174 [inline]
 do_error_trap+0x12b/0x1e0 arch/x86/kernel/traps.c:272
 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:291
 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
RIP: 0010:rollback_registered_many.cold+0x41/0x1bc net/core/dev.c:8167
Code: ff e8 c7 26 90 fc 48 c7 c7 40 ec 63 86 e8 24 c8 7a fc 0f 0b e9 93 be  
ff ff e8 af 26 90 fc 48 c7 c7 40 ec 63 86 e8 0c c8 7a fc <0f> 0b 4c 89 e7  
e8 f9 12 34 fd 31 ff 41 89 c4 89 c6 e8 bd 27 90 fc

RSP: 0018:8881d938f6a8 EFLAGS: 00010286
RAX: 0024 RBX: 8881d2a1 RCX: 
RDX:  RSI: 81288cfd RDI: ed103b271ec7
RBP: 8881d938f7d8 R08: 0024 R09: fbfff11ad794
R10: fbfff11ad793 R11: 88d6bc9f R12: 8881d2a10070
R13: 8881d938f768 R14: dc00 R15: 
 rollback_registered+0xf2/0x1c0 net/core/dev.c:8243
 unregister_netdevice_queue net/core/dev.c:9290 [inline]
 unregister_netdevice_queue+0x1d7/0x2b0 net/core/dev.c:9283
 unregister_netdevice include/linux/netdevice.h:2631 [inline]
 unregister_netdev+0x18/0x20 net/core/dev.c:9331
 r871xu_dev_remove+0xe2/0x215 drivers/staging/rtl8712/usb_intf.c:604
 usb_unbind_interface+0x1bd/0x8a0 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:1134 [inline]
 device_release_driver_internal+0x42f/0x500 drivers/base/dd.c:1165
 bus_remove_device+0x2dc/0x4a0 drivers/base/bus.c:556
 device_del+0x420/0xb10 drivers/base/core.c:2339
 usb_disable_device+0x211/0x690 drivers/usb/core/message.c:1237
 usb_disconnect+0x284/0x8d0 drivers/usb/core/hub.c:2199
 hub_port_connect drivers/usb/core/hub.c:4949 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
 port_event drivers/usb/core/hub.c:5359 [inline]
 hub_event+0x1454/0x3640 drivers/usb/core/hub.c:5441
 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
 process_scheduled_works kernel/workqueue.c:2331 [inline]
 worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417
 kthread+0x318/0x420 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: WARNING in rollback_registered_many (2)

[Oliver Neukum]

Am Mittwoch, den 07.08.2019, 16:03 +0200 schrieb Andrey Konovalov:

I may offer a preliminary analysis.

Regards
Oliver

> On Fri, Apr 12, 2019 at 1:32 PM Andrey Konovalov  
> wrote:
> > 
> > On Fri, Apr 12, 2019 at 1:29 AM syzbot
> >  wrote:
> > > 
> > > syzbot has found a reproducer for the following crash on:
> > > 
> > > HEAD commit:9a33b369 usb-fuzzer: main usb gadget fuzzer driver
> > > git tree:   https://github.com/google/kasan/tree/usb-fuzzer
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=10d552b720
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=23e37f59d94ddd15
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=40918e4d826fb2ff9b96
> > > compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=17a4c1af20
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=121b274b20
> > > 
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+40918e4d826fb2ff9...@syzkaller.appspotmail.com
> > > 
> > > usb 1-1: r8712u: MAC Address from efuse = 00:e0:4c:87:00:00
> > > usb 1-1: r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
> > > usb 1-1: USB disconnect, device number 2

Disconnect will run which leads to

static void r871xu_dev_remove(struct usb_interface *pusb_intf)
{
struct net_device *pnetdev = usb_get_intfdata(pusb_intf);
struct usb_device *udev = interface_to_usbdev(pusb_intf);

if (pnetdev) {

^^^ This is supposed to save us

struct _adapter *padapter = netdev_priv(pnetdev);

usb_set_intfdata(pusb_intf, NULL);
release_firmware(padapter->fw);
/* never exit with a firmware callback pending */
wait_for_completion(>rtl8712_fw_ready);
if (drvpriv.drv_registered)
padapter->surprise_removed = true;
unregister_netdev(pnetdev); /* will call netdev_close() */

So we will call unregister_netdev()


> > > usb 1-1: Direct firmware load for rtlwifi/rtl8712u.bin failed with error 
> > > -2
> > > usb 1-1: r8712u: Firmware request failed

So we ran into the error handling of:


static void rtl871x_load_fw_cb(const struct firmware *firmware, void *context)
{
struct _adapter *adapter = context;


complete(>rtl8712_fw_ready);
if (!firmware) {
struct usb_device *udev = adapter->dvobjpriv.pusbdev;
struct usb_interface *usb_intf = adapter->pusb_intf;


dev_err(>dev, "r8712u: Firmware request failed\n");
usb_put_dev(udev);
usb_set_intfdata(usb_intf, NULL);

^^^ This is supposed to save us from deregistering an unregistered device
but it comes too late. We have already called complete.

return;
}
adapter->fw = firmware;
/* firmware available - start netdev */
register_netdev(adapter->pnetdev);

register_netdev() is not called.
> > > Kernel panic - not syncing: panic_on_warn set ...
> > > CPU: 0 PID: 575 Comm: kworker/0:4 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Workqueue: usb_hub_wq hub_event
> > > Call Trace:
> > >   __dump_stack lib/dump_stack.c:77 [inline]
> > >   dump_stack+0xe8/0x16e lib/dump_stack.c:113
> > >   panic+0x29d/0x5f2 kernel/panic.c:214
> > >   __warn.cold+0x20/0x48 kernel/panic.c:571
> > >   report_bug+0x262/0x2a0 lib/bug.c:186
> > >   fixup_bug arch/x86/kernel/traps.c:179 [inline]
> > >   fixup_bug arch/x86/kernel/traps.c:174 [inline]
> > >   do_error_trap+0x130/0x1f0 arch/x86/kernel/traps.c:272
> > >   do_invalid_op+0x37/0x40 arch/x86/kernel/traps.c:291
> > >   invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973

This kills us.

> > > RIP: 0010:rollback_registered_many+0x1f3/0xe70 net/core/dev.c:8152
> > > Code: 05 00 00 31 ff 44 89 fe e8 5a 15 f3 f4 45 84 ff 0f 85 49 ff ff ff e8
> > > 1c 14 f3 f4 0f 1f 44 00 00 e8 12 14 f3 f4 e8 0d 14 f3 f4 <0f> 0b 4c 89 e7
> > > e8 33 72 f2 f6 31 ff 41 89 c4 89 c6 e8 27 15 f3 f4
> > > RSP: 0018:88809d087698 EFLAGS: 00010293
> > > RAX: 88809d058000 RBX: 88809624 RCX: 8c7eb146
> > > RDX:  RSI: 8c7eb163 RDI: 0001
> > > RBP: 88809d0877c8 R08: 88809d058000 R09: fbfff2708111
> > > R10: fbfff2708110 R11: 93840887 R12: 888096240070
> > > R13: dc00 R14: 88809d087758 R15: 
> > >   rollback_registered+0xf7/0x1c0 net/core/dev.c:8228
> > >   unregister_netdevice_queue net/core/dev.c:9275 [inline]
> > >   unregister_netdevice_queue+0x1dc/0x2b0 net/core/dev.c:9268
> > >   unregister_netdevice include/linux/netdevice.h:2655 [inline]
> > >   unregister_netdev+0x1d/0x30 net/core/dev.c:9316
> > >   r871xu_dev_remove+0xe7/0x223 

Re: [PATCH v8 00/24] erofs: promote erofs from staging v8

[Gao Xiang]

Hi Greg,

On Thu, Aug 15, 2019 at 11:06:03AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 15, 2019 at 12:41:31PM +0800, Gao Xiang wrote:
> > [I strip the previous cover letter, the old one can be found in v6:
> >  https://lore.kernel.org/r/20190802125347.166018-1-gaoxian...@huawei.com/]
> > 
> > We'd like to submit a formal moving patch applied to staging tree
> > for 5.4, before that we'd like to hear if there are some ACKs,
> > suggestions or NAKs, objections of EROFS. Therefore, we can improve
> > it in this round or rethink about the whole thing.
> > 
> > As related materials mentioned [1] [2], the goal of EROFS is to
> > save extra storage space with guaranteed end-to-end performance
> > for read-only files, which has better performance over exist Linux
> > compression filesystems based on fixed-sized output compression
> > and inplace decompression. It even has better performance in
> > a large compression ratio range compared with generic uncompressed
> > filesystems with proper CPU-storage combinations. And we think this
> > direction is correct and a dedicated kernel team is continuously /
> > actively working on improving it, enough testers and beta / end
> > users using it.
> > 
> > EROFS has been applied to almost all in-service HUAWEI smartphones
> > (Yes, the number is still increasing by time) and it seems like
> > a success. It can be used in more wider scenarios. We think it's
> > useful for Linux / Android OS community and it's the time moving
> > out of staging.
> > 
> > In order to get started, latest stable mkfs.erofs is available at
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git -b dev
> > 
> > with README in the repository.
> > 
> > We are still tuning sequential read performance for ultra-fast
> > speed NVME SSDs like Samsung 970PRO, but at least now you can
> > try on your PC with some data with proper compression ratio,
> > the latest Linux kernel, USB stick for convenience sake and
> > a not very old-fashioned CPU. There are also benchmarks available
> > in the above materials mentioned.
> > 
> > EROFS is a self-contained filesystem driver. Although there are
> > still some TODOs to be more generic, we will actively keep on
> > developping / tuning EROFS with the evolution of Linux kernel
> > as the other in-kernel filesystems.
> > 
> > As I mentioned before in LSF/MM 2019, in the future, we'd like
> > to generalize the decompression engine into a library for other
> > fses to use after the whole system is mature like fscrypt.
> > However, such metadata should be designed respectively for
> > each fs, and synchronous metadata read cost will be larger
> > than EROFS because of those ondisk limitation. Therefore EROFS
> > is still a better choice for read-only scenarios.
> > 
> > EROFS is now ready for reviewing and moving, and the code is
> > already cleaned up as shiny floors... Please kindly take some
> > precious time, share your comments about EROFS and let us know
> > your opinion about this. It's really important for us since
> > generally speaking, we like to use Linux _in-tree_ stuffs rather
> > than lack of supported out-of-tree / orphan stuffs as well.
> 
> I know everyone is busy, but given the length this has been in staging,
> and the constant good progress toward cleaning it all up that has been
> happening, I want to get this moved out of staging soon.
> 
> So, unless there are any objections, I'll take this patchset in a week
> into my staging tree to move the filesystem into the "real" part of the
> kernel.

It seem that the time is passed, as a brief conclusion, it seems we don't
get "real" objection in the previous week.

During these days, we have enhanced our robustness against corrupted images
by our first fuzzer based on mkfs.erofs these days (since it's a RO fs, it
will generate reproductable images). Although the original intended use case
of EROFS is on the top of dm-verity for Android, we still want to gain more
wider use so we quickly build a fuzzer and addresses them (yes, we will
develop another independent fuzzer tools as well.)

And thanks all people for all useful suggestions these days, and we think
these wonderful fses (ext4/xfs/btrfs/...) have awesome rich tools, that's
also our next step to address on, especially debugging tools.

As a Newborn communities, we only have a few paid-job people working on
that, but we are doing our best on EROFS, please kindly give us some time
to grow up (I personally speed my all spare/working time on EROFS from its
start), and apply EROFS to more wider use like what we did successfully
for many many HUAWEI smartphones...

As Greg said before [1], we have already proven the advantage of EROFS
solutions, the next step is to develop it more actively... And we would
also like to generalize the decompression engine into a library for other
general fses to use (we're very happy to share our efforts), it seems
interesting to other fs as well [2].

I sent several patchsets from July 4, 

Re: [PATCH] Staging: isdn/gigaset : Fix bare unsigned warnings and trailing lines errors

[Dan Carpenter]

Hi Martin,

These drivers are ancient and going to be deleted soon.  We're not
accepting cleanups for them at this point.

On Wed, Aug 21, 2019 at 03:27:39PM +, Martin Tomes wrote:
> There are many bare use of unsigned warnings and trailing statements should 
> be on next line errors from checkpatch.pl script.
> Change the code by adding 'unsigned int'. Move 'break' statement of 'switch' 
> command to next line.

For future reference, this should be split up so each patch fixes
one kind of style issue.  And the commit message lines of text are too
long.  The limit is 75 characters for commit messages (like an email).

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: isdn/gigaset : Fix bare unsigned warnings and trailing lines errors

[Martin Tomes]

There are many bare use of unsigned warnings and trailing statements should be 
on next line errors from checkpatch.pl script.
Change the code by adding 'unsigned int'. Move 'break' statement of 'switch' 
command to next line.

Signed-off-by: Martin Tomes 
---
 drivers/staging/isdn/gigaset/usb-gigaset.c | 52 ++
 1 file changed, 31 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/isdn/gigaset/usb-gigaset.c 
b/drivers/staging/isdn/gigaset/usb-gigaset.c
index 1b9b436..d565242 100644
--- a/drivers/staging/isdn/gigaset/usb-gigaset.c
+++ b/drivers/staging/isdn/gigaset/usb-gigaset.c
@@ -143,16 +143,16 @@ struct usb_cardstate {
charbchars[6];  /* for request 0x19 */
 };
 
-static inline unsigned tiocm_to_gigaset(unsigned state)
+static inline unsigned int tiocm_to_gigaset(unsigned int state)
 {
return ((state & TIOCM_DTR) ? 1 : 0) | ((state & TIOCM_RTS) ? 2 : 0);
 }
 
-static int gigaset_set_modem_ctrl(struct cardstate *cs, unsigned old_state,
- unsigned new_state)
+static int gigaset_set_modem_ctrl(struct cardstate *cs, unsigned int old_state,
+ unsigned int new_state)
 {
struct usb_device *udev = cs->hw.usb->udev;
-   unsigned mask, val;
+   unsigned int mask, val;
int r;
 
mask = tiocm_to_gigaset(old_state ^ new_state);
@@ -178,7 +178,7 @@ static int set_value(struct cardstate *cs, u8 req, u16 val)
int r, r2;
 
gig_dbg(DEBUG_USBREQ, "request %02x (%04x)",
-   (unsigned)req, (unsigned)val);
+   (unsigned int)req, (unsigned int)val);
r = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0x12, 0x41,
0xf /*?*/, 0, NULL, 0, 2000 /*?*/);
/* no idea what this does */
@@ -191,7 +191,7 @@ static int set_value(struct cardstate *cs, u8 req, u16 val)
val, 0, NULL, 0, 2000 /*?*/);
if (r < 0)
dev_err(>dev, "error %d on request 0x%02x\n",
-   -r, (unsigned)req);
+   -r, (unsigned int)req);
 
r2 = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0x19, 0x41,
 0, 0, cs->hw.usb->bchars, 6, 2000 /*?*/);
@@ -205,7 +205,7 @@ static int set_value(struct cardstate *cs, u8 req, u16 val)
  * set the baud rate on the internal serial adapter
  * using the undocumented parameter setting command
  */
-static int gigaset_baud_rate(struct cardstate *cs, unsigned cflag)
+static int gigaset_baud_rate(struct cardstate *cs, unsigned int cflag)
 {
u16 val;
u32 rate;
@@ -213,16 +213,26 @@ static int gigaset_baud_rate(struct cardstate *cs, 
unsigned cflag)
cflag &= CBAUD;
 
switch (cflag) {
-   caseB300: rate = 300; break;
-   caseB600: rate = 600; break;
-   case   B1200: rate =1200; break;
-   case   B2400: rate =2400; break;
-   case   B4800: rate =4800; break;
-   case   B9600: rate =9600; break;
-   case  B19200: rate =   19200; break;
-   case  B38400: rate =   38400; break;
-   case  B57600: rate =   57600; break;
-   case B115200: rate =  115200; break;
+   caseB300: rate = 300;
+ break;
+   caseB600: rate = 600;
+ break;
+   case   B1200: rate =1200;
+ break;
+   case   B2400: rate =2400;
+ break;
+   case   B4800: rate =4800;
+ break;
+   case   B9600: rate =9600;
+ break;
+   case  B19200: rate =   19200;
+ break;
+   case  B38400: rate =   38400;
+ break;
+   case  B57600: rate =   57600;
+ break;
+   case B115200: rate =  115200;
+ break;
default:
rate =  9600;
dev_err(cs->dev, "unsupported baudrate request 0x%x,"
@@ -345,7 +355,7 @@ static void gigaset_read_int_callback(struct urb *urb)
struct inbuf_t *inbuf = cs->inbuf;
int status = urb->status;
int r;
-   unsigned numbytes;
+   unsigned int numbytes;
unsigned char *src;
unsigned long flags;
 
@@ -357,7 +367,7 @@ static void gigaset_read_int_callback(struct urb *urb)
if (unlikely(*src))
dev_warn(cs->dev,
 "%s: There was no leading 0, but 
0x%02x!\n",
-__func__, (unsigned) *src);
+__func__, (unsigned int) *src);
++src; /* skip leading 0x00 */
--numbytes;
if (gigaset_fill_inbuf(inbuf, src, numbytes)) {
@@ -517,7 +527,7 @@ static int gigaset_write_cmd(struct cardstate *cs, struct 
cmdbuf_t *cb)
 
 

Re: [PATCH] staging: rtl8192u: remove redundant assignment to pointer crypt

[Dan Carpenter]

On Thu, Aug 22, 2019 at 09:46:09AM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The pointer crypt is being set with a value that is never read,
> the assignment is redundant and hence can be removed.
> 
> Thanks to Dan Carpenter for sanity checking that this was indeed
> redundant.
> 
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 

Thanks!

Reviewed-by: Dan Carpenter 

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8192u: remove redundant assignment to pointer crypt

[Colin King]

From: Colin Ian King 

The pointer crypt is being set with a value that is never read,
the assignment is redundant and hence can be removed.

Thanks to Dan Carpenter for sanity checking that this was indeed
redundant.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index e0da0900a4f7..33a6af7aad22 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -743,7 +743,6 @@ static struct sk_buff *ieee80211_probe_resp(struct 
ieee80211_device *ieee, u8 *d
if (ieee->short_slot && (ieee->current_network.capability & 
WLAN_CAPABILITY_SHORT_SLOT))
beacon_buf->capability |= 
cpu_to_le16(WLAN_CAPABILITY_SHORT_SLOT);
 
-   crypt = ieee->crypt[ieee->tx_keyidx];
if (encrypt)
beacon_buf->capability |= cpu_to_le16(WLAN_CAPABILITY_PRIVACY);
 
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Added Realtek rtl8192u driver to staging - static analysis report.

[Dan Carpenter]

On Wed, Aug 21, 2019 at 07:18:39PM +0100, Colin Ian King wrote:
> Hi,
> 
> Static analysis of linux-next picked up an issue with the following commit:
> 
> commit 8fc8598e61f6f384f3eaf1d9b09500c12af47b37
> Author: Jerry Chuang 
> Date:   Tue Nov 3 07:17:11 2009 -0200
> 
> Staging: Added Realtek rtl8192u driver to staging
> 
> In drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c we have:
> 
> CID 48331 (#1 of 1): Unused value (UNUSED_VALUE) assigned_pointer
> 
> Assigning value from ieee->crypt[ieee->tx_keyidx] to crypt here, but
> that stored value is not used.
> 
> 746crypt = ieee->crypt[ieee->tx_keyidx];
> 747if (encrypt)
> 748beacon_buf->capability |=
> cpu_to_le16(WLAN_CAPABILITY_PRIVACY);

Earlir in the function we have:

   695  crypt = ieee->crypt[ieee->tx_keyidx];
   696  
   697  encrypt = ieee->host_encrypt && crypt && crypt->ops &&
   698  ((0 == strcmp(crypt->ops->name, "WEP") || wpa_ie_len));
   699  /* HT ralated element */

So the "crypt" assignment is dublicate and should definitely be removed.
The "if (encrypt) " check looks correct and it sort of matches what we
do in ieee80211_assoc_resp().

   840  encrypt = crypt && crypt->ops;
   841  
   842  if (encrypt)
   843  assoc->capability |= 
cpu_to_le16(WLAN_CAPABILITY_PRIVACY);
   844  

So let's leave it as-is, just delete the crypt assignment.  If you want,
you can send this patch and I can give you a Reviewed-by tag or if you
want I can send the patch and give you Reported-by credit.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel