Re: [PATCH v3 0/4] AS3645A fixes

[Sakari Ailus]

Hi Jacek,

(Fixed DT list address.)

Jacek Anaszewski wrote:

Hi Sakari,

On 09/22/2017 11:32 AM, Sakari Ailus wrote:

Hi Jacek and others,

Here are a few fixes for the as3645a DTS as well as changes in bindings.
The driver is not in a release yet.

Jacek: Could you take these to your fixes branch so we don't get faulty DT
bindings to a release? I've dropped the patches related to LED naming and
label property as the discusion appears to continue on that.


No problem. One question - isn't patch 3/4 missing?


Hmm. I can see it on both linux-leds and devicetree.

I've pushed the four patches here, on v4.14-rc1:



--
Sakari Ailus
sakari.ai...@linux.intel.com

[PATCH v4 0/9] bring back stack frame warning with KASAN

[Arnd Bergmann]

This is a new version of patches I originally submitted back in March
[1], and last time in June [2]. This time I have basically rewritten
the entire patch series based on a new approach that came out of GCC
PR81715 that I opened[3]. The upcoming gcc-8 release is now much better
at consolidating stack slots for inline function arguments and would
obsolete most of my workaround patches here, but we still need the
workarounds for gcc-5, gcc-6 and gcc-7. Many thanks to Jakub Jelinek
for the analysis and the gcc-8 patch!

This minimal set of patches only makes sure that we do get frame size
warnings in allmodconfig for x86_64 and arm64 again with a 2048 byte
limit, even with KASAN enabled, but without the new KASAN_EXTRA option.

I set the warning limit with KASAN_EXTRA to 3072, limiting the
allmodconfig+KASAN_EXTRA build output to around 50 legitimate warnings.
These are for stack frames up to 31KB that will cause an immediate stack
overflow, and fixing them would require bringing back my older patches
and more. We can debate whether we want to apply those as a follow-up,
or instead remove the option entirely.

Another follow-up series I have reduces the warning limit with
KASAN to 1536, and without KASAN to 1280 for 64-bit architectures.

I hope we can get all patches merged for v4.14 and most of them
backported into stable kernels. Since we no longer have a dependency
on a preparation patch, my preference would be for the respective
subsystem maintainers to pick up the individual patches.
The last patch introduces a couple of "allmodconfig" build warnings
on x86 and arm64 unless the other patches get merged first, I'll
send that again separately once everything else has been taken
care of.

The remaining contents are:
- -fsanitize-address-use-after-scope is moved to a separate
  CONFIG_KASAN_EXTRA option that increases the warning limit
- CONFIG_KASAN_EXTRA is disabled with CONFIG_COMPILE_TEST,
  improving compile speed and disabling code that leads to
  valid warnings on gcc-7.0.1
- KMEMCHECK conflicts with CONFIG_KASAN
- my inline function workaround is applied to netlink, one
  ethernet driver and a few media drivers.
- The rework for the brcmsmac driver from previous versions is
  still there.

Changes since v3:
- I dropped all "noinline_if_stackbloat" annotations and used
  a workaround that introduces additional local variables in the inline
  functions to copy the function arguments, resulting in much better
  object code at the expense of having rather odd-looking functions.
- The v4 patches now don't help with KASAN_EXTRA any more at all,
  CONFIG_KASAN_EXTRA now depends on CONFIG_DEBUG_KERNEL, as it
  is more dangerous in production systems than it was before
- Rewrote the "em28xx" patch to be small enough for a stable backport.
- The rewritten vt-keyboard patches got merged and are now in
  stable kernels as well.

Changes since v2:
- rewrote the vt-keyboard patch based on feedback
- and made KMEMCHECK mutually exclusive with KASAN
  (rather than KASAN_EXTRA)

Changes since v1:
- dropped patches to fix all the CONFIG_KASAN_EXTRA warnings:
 - READ_ONCE/WRITE_ONCE cause problems in lots of code
 - typecheck() causes huge problems in a few places
 - many more uses of noinline_if_stackbloat

 Arnd

[1] https://www.spinics.net/lists/linux-wireless/msg159819.html
[2] https://www.spinics.net/lists/netdev/msg441918.html
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715

Arnd Bergmann (9):
  brcmsmac: make some local variables 'static const' to reduce stack
size
  brcmsmac: split up wlc_phy_workarounds_nphy
  brcmsmac: reindent split functions
  em28xx: fix em28xx_dvb_init for KASAN
  r820t: fix r820t_write_reg for KASAN
  dvb-frontends: fix i2c access helpers for KASAN
  rocker: fix rocker_tlv_put_* functions for KASAN
  netlink: fix nla_put_{u8,u16,u32} for KASAN
  kasan: rework Kconfig settings

 drivers/media/dvb-frontends/ascot2e.c  |4 +-
 drivers/media/dvb-frontends/cxd2841er.c|4 +-
 drivers/media/dvb-frontends/helene.c   |4 +-
 drivers/media/dvb-frontends/horus3a.c  |4 +-
 drivers/media/dvb-frontends/itd1000.c  |5 +-
 drivers/media/dvb-frontends/mt312.c|4 +-
 drivers/media/dvb-frontends/stb0899_drv.c  |3 +-
 drivers/media/dvb-frontends/stb6100.c  |6 +-
 drivers/media/dvb-frontends/stv0367.c  |4 +-
 drivers/media/dvb-frontends/stv090x.c  |4 +-
 drivers/media/dvb-frontends/stv6110x.c |4 +-
 drivers/media/dvb-frontends/zl10039.c  |4 +-
 drivers/media/tuners/r820t.c   |   13 +-
 drivers/media/usb/em28xx/em28xx-dvb.c  |   30 +-
 drivers/net/ethernet/rocker/rocker_tlv.h   |   48 +-
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1856 ++--
 include/net/netlink.h  |   73 +-
 lib/Kconfig.debug 

[PATCH 5/8] media: v4l2-device.h: document ancillary macros

[Mauro Carvalho Chehab]

There are several widely macros that aren't documented using kernel-docs
markups.

Add it.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-device.h | 238 +---
 1 file changed, 204 insertions(+), 34 deletions(-)

diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
index 8ffa94009d1a..d6d1c4f7d42c 100644
--- a/include/media/v4l2-device.h
+++ b/include/media/v4l2-device.h
@@ -56,7 +56,6 @@ struct v4l2_ctrl_handler;
  *#) @dev->driver_data points to this struct.
  *#) @dev might be %NULL if there is no parent device
  */
-
 struct v4l2_device {
struct device *dev;
 #if defined(CONFIG_MEDIA_CONTROLLER)
@@ -166,7 +165,7 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev);
  * v4l2_device_register_subdev - Registers a subdev with a v4l2 device.
  *
  * @v4l2_dev: pointer to struct _device
- * @sd: pointer to struct _subdev
+ * @sd: pointer to  v4l2_subdev
  *
  * While registered, the subdev module is marked as in-use.
  *
@@ -179,7 +178,7 @@ int __must_check v4l2_device_register_subdev(struct 
v4l2_device *v4l2_dev,
 /**
  * v4l2_device_unregister_subdev - Unregisters a subdev with a v4l2 device.
  *
- * @sd: pointer to struct _subdev
+ * @sd: pointer to  v4l2_subdev
  *
  * .. note ::
  *
@@ -201,7 +200,7 @@ v4l2_device_register_subdev_nodes(struct v4l2_device 
*v4l2_dev);
 /**
  * v4l2_subdev_notify - Sends a notification to v4l2_device.
  *
- * @sd: pointer to struct _subdev
+ * @sd: pointer to  v4l2_subdev
  * @notification: type of notification. Please notice that the notification
  * type is driver-specific.
  * @arg: arguments for the notification. Those are specific to each
@@ -214,13 +213,43 @@ static inline void v4l2_subdev_notify(struct v4l2_subdev 
*sd,
sd->v4l2_dev->notify(sd, notification, arg);
 }
 
-/* Iterate over all subdevs. */
+/* Ancillary macros to iterate over all subdevs. */
+
+/**
+ * v4l2_device_for_each_subdev - Ancillary macro that interates over all
+ * sub-devices
+ *
+ * @sd: pointer that will be filled by the macro with all
+ *  v4l2_subdev sub-devices associated with @v4l2_dev.
+ * @v4l2_dev: pointer to  v4l2_device
+ *
+ * Sometimes, a driver may need to broadcast a command to all subdevices.
+ * This ancillary macro allows interacting to all sub-devices associated
+ * to a device.
+ */
 #define v4l2_device_for_each_subdev(sd, v4l2_dev)  \
list_for_each_entry(sd, &(v4l2_dev)->subdevs, list)
 
-/* Call the specified callback for all subdevs matching the condition.
-   Ignore any errors. Note that you cannot add or delete a subdev
-   while walking the subdevs list. */
+/**
+ * __v4l2_device_call_subdevs_p - Calls the specified callback for
+ * all subdevs matching the condition.
+ *
+ * @v4l2_dev: pointer to  v4l2_device
+ * @sd: pointer that will be filled by the macro with all
+ *  v4l2_subdev sub-devices associated with @v4l2_dev.
+ * @cond: condition to be match
+ * @o: name of the element at  v4l2_subdev_ops that contains @f.
+ * Each element there groups a set of callbacks functions.
+ * @f: callback function that will be called if @cond matches.
+ * The callback functions are defined in groups, according to
+ * each element at  v4l2_subdev_ops.
+ * @args...: arguments for @f.
+ *
+ * Ignore any errors.
+ *
+ * Note: subdevs cannot be added or deleted while walking at
+ * the subdevs list.
+ */
 #define __v4l2_device_call_subdevs_p(v4l2_dev, sd, cond, o, f, args...)
\
do {\
list_for_each_entry((sd), &(v4l2_dev)->subdevs, list)   \
@@ -228,6 +257,24 @@ static inline void v4l2_subdev_notify(struct v4l2_subdev 
*sd,
(sd)->ops->o->f((sd) , ##args); \
} while (0)
 
+/**
+ * __v4l2_device_call_subdevs - Calls the specified callback for
+ * all subdevs matching the condition.
+ *
+ * @v4l2_dev: pointer to  v4l2_device
+ * @cond: condition to be match
+ * @o: name of the element at  v4l2_subdev_ops that contains @f.
+ * Each element there groups a set of callbacks functions.
+ * @f: callback function that will be called if @cond matches.
+ * The callback functions are defined in groups, according to
+ * each element at  v4l2_subdev_ops.
+ * @args...: arguments for @f.
+ *
+ * Ignore any errors.
+ *
+ * Note: subdevs cannot be added or deleted while walking at
+ * the subdevs list.
+ */
 #define __v4l2_device_call_subdevs(v4l2_dev, cond, o, f, args...)  \
do {\
struct v4l2_subdev *__sd;   \
@@ -236,10 +283,29 @@ static inline void v4l2_subdev_notify(struct v4l2_subdev 
*sd,
f , ##args);\
} while (0)
 
-/* Call the specified callback for all subdevs 

[PATCH 4/8] media: v4l2-common.h: document ancillary functions

[Mauro Carvalho Chehab]

There are several ancillary functions that aren't documented.

Document them.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-common.c |  14 -
 include/media/v4l2-common.h   | 104 ++
 2 files changed, 94 insertions(+), 24 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-common.c 
b/drivers/media/v4l2-core/v4l2-common.c
index fb9a2a3c1072..ac404d5083e0 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -320,20 +320,6 @@ static unsigned int clamp_align(unsigned int x, unsigned 
int min,
return x;
 }
 
-/* Bound an image to have a width between wmin and wmax, and height between
- * hmin and hmax, inclusive.  Additionally, the width will be a multiple of
- * 2^walign, the height will be a multiple of 2^halign, and the overall size
- * (width*height) will be a multiple of 2^salign.  The image may be shrunk
- * or enlarged to fit the alignment constraints.
- *
- * The width or height maximum must not be smaller than the corresponding
- * minimum.  The alignments must not be so high there are no possible image
- * sizes within the allowed bounds.  wmin and hmin must be at least 1
- * (don't use 0).  If you don't care about a certain alignment, specify 0,
- * as 2^0 is 1 and one byte alignment is equivalent to no alignment.  If
- * you only want to adjust downward, specify a maximum that's the same as
- * the initial value.
- */
 void v4l_bound_align_image(u32 *w, unsigned int wmin, unsigned int wmax,
   unsigned int walign,
   u32 *h, unsigned int hmin, unsigned int hmax,
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 7ae7840df068..d3f5f907d566 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -174,17 +174,43 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct 
i2c_client *client,
  */
 unsigned short v4l2_i2c_subdev_addr(struct v4l2_subdev *sd);
 
+/**
+ * enum v4l2_i2c_tuner_type - specifies the range of tuner address that
+ * should be used when seeking for I2C devices.
+ *
+ * @ADDRS_RADIO:   Radio tuner addresses.
+ * Represent the following I2C addresses:
+ * 0x10 (if compiled with tea5761 support)
+ * and 0x60.
+ * @ADDRS_DEMOD:   Demod tuner addresses.
+ * Represent the following I2C addresses:
+ * 0x42, 0x43, 0x4a and 0x4b.
+ * @ADDRS_TV:  TV tuner addresses.
+ * Represent the following I2C addresses:
+ * 0x42, 0x43, 0x4a, 0x4b, 0x60, 0x61, 0x62,
+ * 0x63 and 0x64.
+ * @ADDRS_TV_WITH_DEMOD:   TV tuner addresses if demod is present, this
+ * excludes addresses used by the demodulator
+ * from the list of candidates.
+ * Represent the following I2C addresses:
+ * 0x60, 0x61, 0x62, 0x63 and 0x64.
+ *
+ * NOTE: All I2C addresses above use the 7-bit notation.
+ */
 enum v4l2_i2c_tuner_type {
-   ADDRS_RADIO,/* Radio tuner addresses */
-   ADDRS_DEMOD,/* Demod tuner addresses */
-   ADDRS_TV,   /* TV tuner addresses */
-   /* TV tuner addresses if demod is present, this excludes
-  addresses used by the demodulator from the list of
-  candidates. */
+   ADDRS_RADIO,
+   ADDRS_DEMOD,
+   ADDRS_TV,
ADDRS_TV_WITH_DEMOD,
 };
-/* Return a list of I2C tuner addresses to probe. Use only if the tuner
-   addresses are unknown. */
+/**
+ * v4l2_i2c_tuner_addrs - Return a list of I2C tuner addresses to probe.
+ *
+ * @type: type of the tuner type to seek, as defined by
+ *v4l2_i2c_tuner_type.
+ *
+ * NOTE: Use only if the tuner addresses are unknown.
+ */
 const unsigned short *v4l2_i2c_tuner_addrs(enum v4l2_i2c_tuner_type type);
 
 /* - */
@@ -228,6 +254,9 @@ void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct 
spi_device *spi,
  * FIXME: these remaining ioctls/structs should be removed as well, but they
  * are still used in tuner-simple.c (TUNER_SET_CONFIG) and cx18/ivtv (RESET).
  * To remove these ioctls some more cleanup is needed in those modules.
+ *
+ * It doesn't make much sense on documenting them, as what we really want is
+ * to get rid of them.
  */
 
 /* s_config */
@@ -243,17 +272,72 @@ struct v4l2_priv_tun_config {
 
 /* Miscellaneous helper functions */
 
-void v4l_bound_align_image(unsigned int *w, unsigned int wmin,
+/**
+ * v4l_bound_align_image - adjust video dimensions according to
+ * a given criteria.
+ *
+ * @width: pointer to width that will be adjusted if needed.
+ * @wmin:  minimum width.
+ 

[PATCH 6/8] media: v4l2-dv-timings.h: convert comment into kernel-doc markup

[Mauro Carvalho Chehab]

The can_reduce_fps() is already documented, but it is not
using the kernel-doc markup. Convert it, in order to generate
documentation from it.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-dv-timings.h | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/media/v4l2-dv-timings.h b/include/media/v4l2-dv-timings.h
index 61a18893e004..c0855887ad87 100644
--- a/include/media/v4l2-dv-timings.h
+++ b/include/media/v4l2-dv-timings.h
@@ -203,13 +203,15 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8 
hor_landscape, u8 vert_portrait);
  */
 struct v4l2_fract v4l2_dv_timings_aspect_ratio(const struct v4l2_dv_timings 
*t);
 
-/*
- * reduce_fps - check if conditions for reduced fps are true.
- * bt - v4l2 timing structure
+/**
+ * can_reduce_fps - check if conditions for reduced fps are true.
+ * @bt: v4l2 timing structure
+ *
  * For different timings reduced fps is allowed if following conditions
- * are met -
- * For CVT timings: if reduced blanking v2 (vsync == 8) is true.
- * For CEA861 timings: if V4L2_DV_FL_CAN_REDUCE_FPS flag is true.
+ * are met:
+ *
+ *   - For CVT timings: if reduced blanking v2 (vsync == 8) is true.
+ *   - For CEA861 timings: if %V4L2_DV_FL_CAN_REDUCE_FPS flag is true.
  */
 static inline  bool can_reduce_fps(struct v4l2_bt_timings *bt)
 {
-- 
2.13.5

[PATCH 1/8] media: tuner-types: add kernel-doc markups for struct tunertype

[Mauro Carvalho Chehab]

This struct is lacking documentation. Add it.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/tuner-types.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/include/media/tuner-types.h b/include/media/tuner-types.h
index aed539068d2d..55bc14093c0f 100644
--- a/include/media/tuner-types.h
+++ b/include/media/tuner-types.h
@@ -170,6 +170,21 @@ struct tuner_params {
struct tuner_range *ranges;
 };
 
+/**
+ * struct tunertype - describes the known tuners.
+ *
+ * @name:  string with the tuner's name.
+ * @count: size of  tuner_params array.
+ * @params:pointer to  tuner_params array.
+ *
+ * @min:   minimal tuner frequency, in 62.5 kHz step.
+ * should be multiplied to 16 to convert to MHz.
+ * @max:   minimal tuner frequency, in 62.5 kHz step.
+ * Should be multiplied to 16 to convert to MHz.
+ * @stepsize:  frequency step, in Hz.
+ * @initdata:  optional byte sequence to initialize the tuner.
+ * @sleepdata: optional byte sequence to power down the tuner.
+ */
 struct tunertype {
char *name;
unsigned int count;
-- 
2.13.5

[PATCH 8/8] media: v4l2-ioctl.h: convert debug macros into enum and document

[Mauro Carvalho Chehab]

Currently, there's no way to document #define foo 
with kernel-doc. So, convert it to an enum, and document.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-ioctl.h | 33 +++--
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index bd5312118013..136e2cffcf9e 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -588,20 +588,25 @@ struct v4l2_ioctl_ops {
 };
 
 
-/* v4l debugging and diagnostics */
-
-/* Device debug flags to be used with the video device debug attribute */
-
-/* Just log the ioctl name + error code */
-#define V4L2_DEV_DEBUG_IOCTL   0x01
-/* Log the ioctl name arguments + error code */
-#define V4L2_DEV_DEBUG_IOCTL_ARG   0x02
-/* Log the file operations open, release, mmap and get_unmapped_area */
-#define V4L2_DEV_DEBUG_FOP 0x04
-/* Log the read and write file operations and the VIDIOC_(D)QBUF ioctls */
-#define V4L2_DEV_DEBUG_STREAMING   0x08
-/* Log poll() */
-#define V4L2_DEV_DEBUG_POLL0x10
+/**
+ * enum v4l2_debug_flags - Device debug flags to be used with the video
+ * device debug attribute
+ *
+ * @V4L2_DEV_DEBUG_IOCTL:  Just log the ioctl name + error code.
+ * @V4L2_DEV_DEBUG_IOCTL_ARG:  Log the ioctl name arguments + error code.
+ * @V4L2_DEV_DEBUG_FOP:Log the file operations and open, 
release,
+ * mmap and get_unmapped_area syscalls.
+ * @V4L2_DEV_DEBUG_STREAMING:  Log the read and write syscalls and
+ * :c:ref:`VIDIOC_[Q|DQ]BUFF ` ioctls.
+ * @V4L2_DEV_DEBUG_POLL:   Log poll syscalls.
+ */
+enum v4l2_debug_flags {
+   V4L2_DEV_DEBUG_IOCTL= 0x01,
+   V4L2_DEV_DEBUG_IOCTL_ARG= 0x02,
+   V4L2_DEV_DEBUG_FOP  = 0x04,
+   V4L2_DEV_DEBUG_STREAMING= 0x08,
+   V4L2_DEV_DEBUG_POLL = 0x10,
+};
 
 /*  Video standard functions  */
 
-- 
2.13.5

[PATCH 0/8] Document more parts of V4L2 kAPI part 1

[Mauro Carvalho Chehab]

There are several  functions and structs at V4L2 that aren't documented.

This is an effort to document some of those. My plan is to work on other
similar patch series until we have the kAPI in sync with the current
implementation.

Mauro Carvalho Chehab (8):
  media: tuner-types: add kernel-doc markups for struct tunertype
  media: v4l2-common: get rid of v4l2_routing dead struct
  media: v4l2-common: get rid of struct v4l2_discrete_probe
  media: v4l2-common.h: document ancillary functions
  media: v4l2-device.h: document ancillary macros
  media: v4l2-dv-timings.h: convert comment into kernel-doc markup
  media: v4l2-event.rst: improve events description
  media: v4l2-ioctl.h: convert debug macros into enum and document

 Documentation/media/kapi/v4l2-event.rst  |  64 +--
 drivers/media/platform/vivid/vivid-vid-cap.c |   9 +-
 drivers/media/v4l2-core/v4l2-common.c|  27 +--
 include/media/tuner-types.h  |  15 ++
 include/media/v4l2-common.h  | 130 ---
 include/media/v4l2-device.h  | 238 +++
 include/media/v4l2-dv-timings.h  |  14 +-
 include/media/v4l2-event.h   |  34 
 include/media/v4l2-ioctl.h   |  33 ++--
 9 files changed, 411 insertions(+), 153 deletions(-)

-- 
2.13.5

[PATCH 3/8] media: v4l2-common: get rid of struct v4l2_discrete_probe

[Mauro Carvalho Chehab]

This struct is there just two store two arguments of
v4l2_find_nearest_format(). The other two arguments are passed
as parameter.

IMHO, there isn't much sense on doing that, and that will just
add one more struct to document ;)

So, let's get rid of the struct, passing the parameters directly.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/vivid/vivid-vid-cap.c |  9 +++--
 drivers/media/v4l2-core/v4l2-common.c| 13 +++--
 include/media/v4l2-common.h  | 12 
 3 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c 
b/drivers/media/platform/vivid/vivid-vid-cap.c
index 01419455e545..0fbbcde19f0d 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -93,11 +93,6 @@ static const struct v4l2_fract 
webcam_intervals[VIVID_WEBCAM_IVALS] = {
{  1, 60 },
 };
 
-static const struct v4l2_discrete_probe webcam_probe = {
-   webcam_sizes,
-   VIVID_WEBCAM_SIZES
-};
-
 static int vid_cap_queue_setup(struct vb2_queue *vq,
   unsigned *nbuffers, unsigned *nplanes,
   unsigned sizes[], struct device *alloc_devs[])
@@ -578,7 +573,9 @@ int vivid_try_fmt_vid_cap(struct file *file, void *priv,
mp->field = vivid_field_cap(dev, mp->field);
if (vivid_is_webcam(dev)) {
const struct v4l2_frmsize_discrete *sz =
-   v4l2_find_nearest_format(_probe, mp->width, 
mp->height);
+   v4l2_find_nearest_format(webcam_sizes,
+VIVID_WEBCAM_SIZES,
+mp->width, mp->height);
 
w = sz->width;
h = sz->height;
diff --git a/drivers/media/v4l2-core/v4l2-common.c 
b/drivers/media/v4l2-core/v4l2-common.c
index a5ea1f517291..fb9a2a3c1072 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -371,18 +371,19 @@ void v4l_bound_align_image(u32 *w, unsigned int wmin, 
unsigned int wmax,
 }
 EXPORT_SYMBOL_GPL(v4l_bound_align_image);
 
-const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
-   const struct v4l2_discrete_probe *probe,
-   s32 width, s32 height)
+const struct v4l2_frmsize_discrete
+*v4l2_find_nearest_format(const struct v4l2_frmsize_discrete *sizes,
+ const size_t num_sizes,
+ s32 width, s32 height)
 {
int i;
u32 error, min_error = UINT_MAX;
const struct v4l2_frmsize_discrete *size, *best = NULL;
 
-   if (!probe)
-   return best;
+   if (!sizes)
+   return NULL;
 
-   for (i = 0, size = probe->sizes; i < probe->num_sizes; i++, size++) {
+   for (i = 0, size = sizes; i < num_sizes; i++, size++) {
error = abs(size->width - width) + abs(size->height - height);
if (error < min_error) {
min_error = error;
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 7dbecbe3009c..7ae7840df068 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -249,14 +249,10 @@ void v4l_bound_align_image(unsigned int *w, unsigned int 
wmin,
   unsigned int hmax, unsigned int halign,
   unsigned int salign);
 
-struct v4l2_discrete_probe {
-   const struct v4l2_frmsize_discrete  *sizes;
-   int num_sizes;
-};
-
-const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
-   const struct v4l2_discrete_probe *probe,
-   s32 width, s32 height);
+const struct v4l2_frmsize_discrete
+*v4l2_find_nearest_format(const struct v4l2_frmsize_discrete *sizes,
+ const size_t num_sizes,
+ s32 width, s32 height);
 
 void v4l2_get_timestamp(struct timeval *tv);
 
-- 
2.13.5

[PATCH 7/8] media: v4l2-event.rst: improve events description

[Mauro Carvalho Chehab]

Both v4l2-event.rst and v4l2-event.h have an overview of
events, but there are some inconsistencies there:

- at v4l2-event, the event's ringbuffer is called kevent. Its
  name is, instead, v4l2_kevent;

- Some things are mentioned on both places (with different words),
  others are either on one of the files.

In order to cleanup this mess, put everything at v4l2-event.rst
and improve it to be a little more coherent and to have cross
references.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/kapi/v4l2-event.rst | 64 ++---
 include/media/v4l2-event.h  | 34 --
 2 files changed, 52 insertions(+), 46 deletions(-)

diff --git a/Documentation/media/kapi/v4l2-event.rst 
b/Documentation/media/kapi/v4l2-event.rst
index 9938d21ef4d1..7831a503e2aa 100644
--- a/Documentation/media/kapi/v4l2-event.rst
+++ b/Documentation/media/kapi/v4l2-event.rst
@@ -5,27 +5,67 @@ V4L2 events
 The V4L2 events provide a generic way to pass events to user space.
 The driver must use :c:type:`v4l2_fh` to be able to support V4L2 events.
 
-Events are defined by a type and an optional ID. The ID may refer to a V4L2
-object such as a control ID. If unused, then the ID is 0.
+Events are subscribed per-filehandle. An event specification consists of a
+``type`` and is optionally associated with an object identified through the
+``id`` field. If unused, then the ``id`` is 0. So an event is uniquely
+identified by the ``(type, id)`` tuple.
 
-When the user subscribes to an event the driver will allocate a number of
-kevent structs for that event. So every (type, ID) event tuple will have
-its own set of kevent structs. This guarantees that if a driver is generating
-lots of events of one type in a short time, then that will not overwrite
-events of another type.
+The :c:type:`v4l2_fh` struct has a list of subscribed events on its
+``subscribed`` field.
 
-But if you get more events of one type than the number of kevents that were
-reserved, then the oldest event will be dropped and the new one added.
+When the user subscribes to an event, a :c:type:`v4l2_subscribed_event`
+struct is added to :c:type:`v4l2_fh`\ ``.subscribed``, one for every
+subscribed event.
+
+Each :c:type:`v4l2_subscribed_event` struct ends with a
+:c:type:`v4l2_kevent` ringbuffer, with the size given by the caller
+of :c:func:`v4l2_event_subscribe`. Such ringbuffer is used to store any events
+raised by the driver.
+
+So every ``(type, ID)`` event tuple will have its own set of
+:c:type:`v4l2_kevent` ringbuffer. This guarantees that if a driver is
+generating lots of events of one type in a short time, then that will
+not overwrite events of another type.
+
+But if you get more events of one type than the size of the
+:c:type:`v4l2_kevent` ringbuffer, then the oldest event will be dropped
+and the new one added.
+
+The :c:type:`v4l2_kevent` struct links into the ``available``
+list of the :c:type:`v4l2_fh` struct so :ref:`VIDIOC_DQEVENT` will
+know which event to dequeue first.
+
+Finally, if the event subscription is associated with a particular object
+such as a V4L2 control, then that object needs to know about that as well
+so that an event can be raised by that object. So the ``node`` field can
+be used to link the :c:type:`v4l2_subscribed_event` struct into a list of
+such object.
+
+So to summarize:
+
+- struct :c:type:`v4l2_fh` has two lists: one of the ``subscribed`` events,
+  and one of the ``available`` events.
+
+- struct :c:type:`v4l2_subscribed_event` has a ringbuffer of raised
+  (pending) events of that particular type.
+
+- If struct :c:type:`v4l2_subscribed_event` is associated with a specific
+  object, then that object will have an internal list of
+  struct :c:type:`v4l2_subscribed_event` so it knows who subscribed an
+  event to that object.
 
 Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has
 ``merge()`` and ``replace()`` callbacks which drivers can set. These
 callbacks are called when a new event is raised and there is no more room.
+
 The ``replace()`` callback allows you to replace the payload of the old event
 with that of the new event, merging any relevant data from the old payload
 into the new payload that replaces it. It is called when this event type has
-only one kevent struct allocated. The ``merge()`` callback allows you to merge
-the oldest event payload into that of the second-oldest event payload. It is
-called when there are two or more kevent structs allocated.
+only one :c:type:`v4l2_kevent` struct allocated.
+
+The ``merge()`` callback allows you to merge the oldest event payload into
+that of the second-oldest event payload. It is called when there are two
+or more :c:type:`v4l2_kevent` structs allocated.
 
 This way no status information is lost, just the intermediate steps leading
 up to that state.
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 6741910c3a18..4e83529117f7 100644
--- 

[PATCH 2/8] media: v4l2-common: get rid of v4l2_routing dead struct

[Mauro Carvalho Chehab]

This struct is not used anymore. Get rid of it and update
the documentation about what should still be converted.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-common.h | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index aac8b7b6e691..7dbecbe3009c 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -224,10 +224,11 @@ void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct 
spi_device *spi,
 
 /* - */
 
-/* Note: these remaining ioctls/structs should be removed as well, but they are
-   still used in tuner-simple.c (TUNER_SET_CONFIG), cx18/ivtv (RESET) and
-   v4l2-int-device.h (v4l2_routing). To remove these ioctls some more cleanup
-   is needed in those modules. */
+/*
+ * FIXME: these remaining ioctls/structs should be removed as well, but they
+ * are still used in tuner-simple.c (TUNER_SET_CONFIG) and cx18/ivtv (RESET).
+ * To remove these ioctls some more cleanup is needed in those modules.
+ */
 
 /* s_config */
 struct v4l2_priv_tun_config {
@@ -238,11 +239,6 @@ struct v4l2_priv_tun_config {
 
 #define VIDIOC_INT_RESET   _IOW ('d', 102, u32)
 
-struct v4l2_routing {
-   u32 input;
-   u32 output;
-};
-
 /* - */
 
 /* Miscellaneous helper functions */
-- 
2.13.5

[PATCH 0/4] RFC: TDA1997x HDMI video receiver

[Tim Harvey]

This is an RFC for a driver supporting the TDA1997x HDMI video receiver.

I've tested this on a Gateworks GW54xx with an IMX6Q which uses the TDA19971
with 16bits connected to the IMX6 CSI. For this configuration I've tested
both 16bit YUV422 and 8bit BT656 mode. While the driver should support the
TDA1993 I do not have one for testing.

Further potential development efforts include:
 - AUDIO codec support (working on this next)
 - EDID read/write support
 - CEC support
 - HDCP support
 - mbus format selection support for bus widths that support multiple formats
 - TDA19972 support (2 inputs)

Tim Harvey (4):
  MAINTAINERS: add entry for NXP TDA1997x driver
  media: dt-bindings: Add bindings for TDA1997X
  media: i2c: Add TDA1997x HDMI receiver driver
  ARM: DTS: imx: ventana: add TDA19971 HDMI Receiver to GW54xx

 .../devicetree/bindings/media/i2c/tda1997x.txt |  159 +
 MAINTAINERS|8 +
 arch/arm/boot/dts/imx6q-gw54xx.dts |   85 +
 drivers/media/i2c/Kconfig  |9 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/tda1997x.c   | 3065 
 include/dt-bindings/media/tda1997x.h   |   78 +
 include/media/i2c/tda1997x.h   |   53 +
 8 files changed, 3458 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
 create mode 100644 drivers/media/i2c/tda1997x.c
 create mode 100644 include/dt-bindings/media/tda1997x.h
 create mode 100644 include/media/i2c/tda1997x.h

-- 
2.7.4

Re: [PATCH v3 0/4] AS3645A fixes

[Jacek Anaszewski]

Hi Sakari,

On 09/22/2017 11:32 AM, Sakari Ailus wrote:
> Hi Jacek and others,
> 
> Here are a few fixes for the as3645a DTS as well as changes in bindings.
> The driver is not in a release yet.
> 
> Jacek: Could you take these to your fixes branch so we don't get faulty DT
> bindings to a release? I've dropped the patches related to LED naming and
> label property as the discusion appears to continue on that.

No problem. One question - isn't patch 3/4 missing?

Best regards,
Jacek Anaszewski

> Thanks.
> 
> 
> since v2:
> 
> - Drop patches related to LED naming.
> 
> - No other changes.
> 
> since v1:
> 
> - Add LED colour to the name of the LED, this adds two patches to the set.
> 
> - Add a patch to unregister the indicator LED in driver remove function.
> 
> - No changes to v1 patches.
> 
> Sakari Ailus (4):
>   as3645a: Use ams,input-max-microamp as documented in DT bindings
>   dt: bindings: as3645a: Use LED number to refer to LEDs
>   as3645a: Use integer numbers for parsing LEDs
>   as3645a: Unregister indicator LED on device unbind
> 
>  .../devicetree/bindings/leds/ams,as3645a.txt   | 28 +
>  arch/arm/boot/dts/omap3-n950-n9.dtsi   | 10 +---
>  drivers/leds/leds-as3645a.c| 29 
> +++---
>  3 files changed, 51 insertions(+), 16 deletions(-)
> 

[PATCH v4 3/9] brcmsmac: reindent split functions

[Arnd Bergmann]

In the previous commit I left the indentation alone to help reviewing
the patch, this one now runs the three new functions through 'indent -kr -8'
with some manual fixups to avoid silliness.

No changes other than whitespace are intended here.

Signed-off-by: Arnd Bergmann 
Acked-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1507 +---
 1 file changed, 697 insertions(+), 810 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index ed409a80f3d2..763e8ba6b178 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16074,7 +16074,8 @@ static void wlc_phy_workarounds_nphy_rev7(struct 
brcms_phy *pi)
NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
NPHY_REV3_RFSEQ_CMD_END
};
-   static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 
1, 1 };
+   static const u8 rfseq_rx2tx_dlys_rev3_ipa[] =
+   { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
u32 leg_data_weights;
u8 chan_freq_range = 0;
@@ -16114,526 +16115,452 @@ static void wlc_phy_workarounds_nphy_rev7(struct 
brcms_phy *pi)
int coreNum;
 
 
-   if (NREV_IS(pi->pubpi.phy_rev, 7)) {
-   mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
-
-   mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
-   mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
-   mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
-   mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
-   mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
-   mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
-   mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
-   mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
-   mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
-   mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
-   mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
-   mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
-   mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
-   mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
-   mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
-   mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
-   }
-
-   if (NREV_LE(pi->pubpi.phy_rev, 8)) {
-   write_phy_reg(pi, 0x23f, 0x1b0);
-   write_phy_reg(pi, 0x240, 0x1b0);
-   }
+   if (NREV_IS(pi->pubpi.phy_rev, 7)) {
+   mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
+
+   mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
+   mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
+   mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
+   mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
+   mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
+   mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
+   mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
+   mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
+   mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
+   mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
+   mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
+   mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
+   mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
+   mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
+   mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
+   mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
+   }
 
-   if (NREV_GE(pi->pubpi.phy_rev, 8))
-   mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
+   if (NREV_LE(pi->pubpi.phy_rev, 8)) {
+   write_phy_reg(pi, 0x23f, 0x1b0);
+   write_phy_reg(pi, 0x240, 0x1b0);
+   }
 
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x00, 16,
-_control);
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x10, 16,
-_control);
+   if (NREV_GE(pi->pubpi.phy_rev, 8))
+   mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
 
-   wlc_phy_table_read_nphy(pi, NPHY_TBL_ID_CMPMETRICDATAWEIGHTTBL,
-   1, 0, 32, _data_weights);
-   leg_data_weights = leg_data_weights & 0xff;
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_CMPMETRICDATAWEIGHTTBL,
-  

[PATCH v4 7/9] rocker: fix rocker_tlv_put_* functions for KASAN

[Arnd Bergmann]

Inlining these functions creates lots of stack variables that each take
64 bytes when KASAN is enabled, leading to this warning about potential
stack overflow:

drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 
'ofdpa_cmd_flow_tbl_add':
drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 2752 
bytes is larger than 1536 bytes [-Werror=frame-larger-than=]

gcc-8 can now consolidate the stack slots itself, but on older versions
we get the same behavior by using a temporary variable that holds a
copy of the inline function argument.

Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/rocker/rocker_tlv.h | 48 
 1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/rocker/rocker_tlv.h 
b/drivers/net/ethernet/rocker/rocker_tlv.h
index a63ef82e7c72..dfae3c9d57c6 100644
--- a/drivers/net/ethernet/rocker/rocker_tlv.h
+++ b/drivers/net/ethernet/rocker/rocker_tlv.h
@@ -139,40 +139,52 @@ rocker_tlv_start(struct rocker_desc_info *desc_info)
 int rocker_tlv_put(struct rocker_desc_info *desc_info,
   int attrtype, int attrlen, const void *data);
 
-static inline int rocker_tlv_put_u8(struct rocker_desc_info *desc_info,
-   int attrtype, u8 value)
+static inline int
+rocker_tlv_put_u8(struct rocker_desc_info *desc_info, int attrtype, u8 value)
 {
-   return rocker_tlv_put(desc_info, attrtype, sizeof(u8), );
+   u8 tmp = value; /* work around GCC PR81715 */
+
+   return rocker_tlv_put(desc_info, attrtype, sizeof(u8), );
 }
 
-static inline int rocker_tlv_put_u16(struct rocker_desc_info *desc_info,
-int attrtype, u16 value)
+static inline int
+rocker_tlv_put_u16(struct rocker_desc_info *desc_info, int attrtype, u16 value)
 {
-   return rocker_tlv_put(desc_info, attrtype, sizeof(u16), );
+   u16 tmp = value;
+
+   return rocker_tlv_put(desc_info, attrtype, sizeof(u16), );
 }
 
-static inline int rocker_tlv_put_be16(struct rocker_desc_info *desc_info,
- int attrtype, __be16 value)
+static inline int
+rocker_tlv_put_be16(struct rocker_desc_info *desc_info, int attrtype, __be16 
value)
 {
-   return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), );
+   __be16 tmp = value;
+
+   return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), );
 }
 
-static inline int rocker_tlv_put_u32(struct rocker_desc_info *desc_info,
-int attrtype, u32 value)
+static inline int
+rocker_tlv_put_u32(struct rocker_desc_info *desc_info, int attrtype, u32 value)
 {
-   return rocker_tlv_put(desc_info, attrtype, sizeof(u32), );
+   u32 tmp = value;
+
+   return rocker_tlv_put(desc_info, attrtype, sizeof(u32), );
 }
 
-static inline int rocker_tlv_put_be32(struct rocker_desc_info *desc_info,
- int attrtype, __be32 value)
+static inline int
+rocker_tlv_put_be32(struct rocker_desc_info *desc_info, int attrtype, __be32 
value)
 {
-   return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), );
+   __be32 tmp = value;
+
+   return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), );
 }
 
-static inline int rocker_tlv_put_u64(struct rocker_desc_info *desc_info,
-int attrtype, u64 value)
+static inline int
+rocker_tlv_put_u64(struct rocker_desc_info *desc_info, int attrtype, u64 value)
 {
-   return rocker_tlv_put(desc_info, attrtype, sizeof(u64), );
+   u64 tmp = value;
+
+   return rocker_tlv_put(desc_info, attrtype, sizeof(u64), );
 }
 
 static inline struct rocker_tlv *
-- 
2.9.0

[PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

[Arnd Bergmann]

With CONFIG_KASAN, the init function uses a large amount of kernel stack:

drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init.part.4':
drivers/media/usb/em28xx/em28xx-dvb.c:2061:1: error: the frame size of 3232 
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

It seems that this is triggered in part by using strlcpy(), which the
compiler doesn't recognize as copying at most 'len' bytes, since strlcpy
is not part of the C standard.

It does however recognize the standard strncpy() and optimizes away
the extra checks for that, using only 1688 bytes in the end.
I have another larger patch that we could use in addition to this one,
in order to shrink the stack for -fsanitize-address-use-after-scope
(with gcc-7.1.1) as well, but that would not be appropriate for
stable backports, so let's focus on this one first.

Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/em28xx/em28xx-dvb.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 4a7db623fe29..06c363dc55ed 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1440,7 +1440,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
tda10071_pdata.pll_multiplier = 20,
tda10071_pdata.tuner_i2c_addr = 0x14,
memset(_info, 0, sizeof(board_info));
-   strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
+   strncpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE - 1);
board_info.addr = 0x55;
board_info.platform_data = _pdata;
request_module("tda10071");
@@ -1460,7 +1460,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
/* attach SEC */
a8293_pdata.dvb_frontend = dvb->fe[0];
memset(_info, 0, sizeof(board_info));
-   strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
+   strncpy(board_info.type, "a8293", I2C_NAME_SIZE - 1);
board_info.addr = 0x08;
board_info.platform_data = _pdata;
request_module("a8293");
@@ -1643,7 +1643,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
m88ds3103_pdata.ts_clk_pol = 1;
m88ds3103_pdata.agc = 0x99;
memset(_info, 0, sizeof(board_info));
-   strlcpy(board_info.type, "m88ds3103", I2C_NAME_SIZE);
+   strncpy(board_info.type, "m88ds3103", I2C_NAME_SIZE - 1);
board_info.addr = 0x68;
board_info.platform_data = _pdata;
request_module("m88ds3103");
@@ -1664,7 +1664,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
/* attach tuner */
ts2020_config.fe = dvb->fe[0];
memset(_info, 0, sizeof(board_info));
-   strlcpy(board_info.type, "ts2022", I2C_NAME_SIZE);
+   strncpy(board_info.type, "ts2022", I2C_NAME_SIZE - 1);
board_info.addr = 0x60;
board_info.platform_data = _config;
request_module("ts2020");
@@ -1690,7 +1690,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
/* attach SEC */
a8293_pdata.dvb_frontend = dvb->fe[0];
memset(_info, 0, sizeof(board_info));
-   strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
+   strncpy(board_info.type, "a8293", I2C_NAME_SIZE - 1);
board_info.addr = 0x08;
board_info.platform_data = _pdata;
request_module("a8293");
@@ -1729,7 +1729,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
si2168_config.fe = >fe[0];
si2168_config.ts_mode = SI2168_TS_PARALLEL;
memset(, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, "si2168", I2C_NAME_SIZE);
+   strncpy(info.type, "si2168", I2C_NAME_SIZE - 1);
info.addr = 0x64;
info.platform_data = _config;
request_module(info.type);
@@ -1755,7 +1755,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
si2157_config.mdev = dev->media_dev;
 #endif
memset(, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, "si2157", I2C_NAME_SIZE);
+   strncpy(info.type, "si2157", I2C_NAME_SIZE - 1);
info.addr = 0x60;
info.platform_data = _config;
request_module(info.type);
@@ -1793,7 +1793,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
si2168_config.fe = >fe[0];
si2168_config.ts_mode = SI2168_TS_PARALLEL;
memset(, 0, 

[PATCH 4/4] ARM: DTS: imx: ventana: add TDA19971 HDMI Receiver to GW54xx

[Tim Harvey]

The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6q-gw54xx.dts | 85 ++
 1 file changed, 85 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts 
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..efb7dd3 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,6 +12,7 @@
 /dts-v1/;
 #include "imx6q.dtsi"
 #include "imx6qdl-gw54xx.dtsi"
+#include 
 
 / {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
@@ -35,6 +36,60 @@
};
};
};
+
+   tda1997x: tda1997x@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_reg>;
+   DVDD-supply = <_reg>;
+   audio-port = < TDA1997X_I2S16
+  TDA1997X_LAYOUT0
+  TDA1997X_ACLK_128FS >;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+   vidout_portcfg =
+   /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+   < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+   /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+   < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+   /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+   < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+   /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+   < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+   max-pixel-rate = <180>; /* IMX6 CSI max pixel rate 180MP/sec */
+
+   port {
+   tda1997x_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <16>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   data-active = <1>;
+   };
+   };
+   };
+};
+
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <16>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <16>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
 };
 
 _csi1_from_ipu2_csi1_mux {
@@ -63,6 +118,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1_csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x1b0b0
+   MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC   0x1b0b0
+   MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK0x1b0b0
+   MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC  0x1b0b0
+   >;
+   };
+
pinctrl_ipu2_csi1: ipu2_csi1grp {
fsl,pins = <
MX6QDL_PAD_EIM_EB2__IPU2_CSI1_DATA190x1b0b0
@@ -78,4 +157,10 @@
MX6QDL_PAD_EIM_A16__IPU2_CSI1_PIXCLK0x1b0b0
>;
};
+
+   pinctrl_tda1997x: tda1997xgrp {
+   fsl,pins = <
+   MX6QDL_PAD_GPIO_7__GPIO1_IO07   0x1b0b0
+   

[PATCH 3/4] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

Add support for the TDA1997x HDMI receivers.

Signed-off-by: Tim Harvey 
---
 drivers/media/i2c/Kconfig|9 +
 drivers/media/i2c/Makefile   |1 +
 drivers/media/i2c/tda1997x.c | 3065 ++
 include/dt-bindings/media/tda1997x.h |   78 +
 include/media/i2c/tda1997x.h |   53 +
 5 files changed, 3206 insertions(+)
 create mode 100644 drivers/media/i2c/tda1997x.c
 create mode 100644 include/dt-bindings/media/tda1997x.h
 create mode 100644 include/media/i2c/tda1997x.h

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9415389..c2b0400 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -56,6 +56,15 @@ config VIDEO_TDA9840
  To compile this driver as a module, choose M here: the
  module will be called tda9840.
 
+config VIDEO_TDA1997X
+   tristate "NXP TDA1997x HDMI receiver"
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tda1997x.
+
 config VIDEO_TEA6415C
tristate "Philips TEA6415C audio processor"
depends on I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index c843c18..58f2b2e 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
 obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
 obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
+obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o
 obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
 obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
 obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
new file mode 100644
index 000..ca3fec8
--- /dev/null
+++ b/drivers/media/i2c/tda1997x.c
@@ -0,0 +1,3065 @@
+/*
+ * Copyright (C) 2017 Gateworks Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* debug level */
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+/* Page 0x00 - General Control */
+#define REG_VERSION0x
+#define REG_INPUT_SEL  0x0001
+#define REG_SVC_MODE   0x0002
+#define REG_HPD_MAN_CTRL   0x0003
+#define REG_RT_MAN_CTRL0x0004
+#define REG_STANDBY_SOFT_RST   0x000A
+#define REG_HDMI_SOFT_RST  0x000B
+#define REG_HDMI_INFO_RST  0x000C
+#define REG_INT_FLG_CLR_TOP0x000E
+#define REG_INT_FLG_CLR_SUS0x000F
+#define REG_INT_FLG_CLR_DDC0x0010
+#define REG_INT_FLG_CLR_RATE   0x0011
+#define REG_INT_FLG_CLR_MODE   0x0012
+#define REG_INT_FLG_CLR_INFO   0x0013
+#define REG_INT_FLG_CLR_AUDIO  0x0014
+#define REG_INT_FLG_CLR_HDCP   0x0015
+#define REG_INT_FLG_CLR_AFE0x0016
+#define REG_INT_MASK_TOP   0x0017
+#define REG_INT_MASK_SUS   0x0018
+#define REG_INT_MASK_DDC   0x0019
+#define REG_INT_MASK_RATE  0x001A
+#define REG_INT_MASK_MODE  0x001B
+#define REG_INT_MASK_INFO  0x001C
+#define REG_INT_MASK_AUDIO 0x001D
+#define REG_INT_MASK_HDCP  0x001E
+#define REG_INT_MASK_AFE   0x001F
+#define REG_DETECT_5V  0x0020
+#define REG_SUS_STATUS 0x0021
+#define REG_V_PER  0x0022
+#define REG_H_PER  0x0025
+#define REG_HS_WIDTH   0x0027
+#define REG_FMT_H_TOT  0x0029
+#define REG_FMT_H_ACT  0x002b
+#define REG_FMT_H_FRONT0x002d
+#define REG_FMT_H_SYNC 0x002f
+#define REG_FMT_H_BACK 0x0031
+#define REG_FMT_V_TOT  0x0033
+#define REG_FMT_V_ACT  0x0035
+#define REG_FMT_V_FRONT_F1 0x0037
+#define REG_FMT_V_FRONT_F2 0x0038
+#define REG_FMT_V_SYNC 0x0039
+#define REG_FMT_V_BACK_F1  0x003a
+#define REG_FMT_V_BACK_F2  0x003b
+#define REG_FMT_DE_ACT 0x003c
+#define REG_RATE_CTRL  0x0040
+#define REG_CLK_MIN_RATE   0x0043
+#define REG_CLK_MAX_RATE   0x0046
+#define REG_CLK_A_STATUS   0x0049
+#define REG_CLK_A_RATE 0x004A
+#define REG_DRIFT_CLK_A_REG0x004D
+#define REG_CLK_B_STATUS   0x004E
+#define REG_CLK_B_RATE 0x004F
+#define REG_DRIFT_CLK_B_REG0x0052
+#define REG_HDCP_CTRL  0x0060
+#define REG_HDCP_KDS   0x0061
+#define REG_HDCP_BCAPS 0x0063
+#define REG_HDCP_KEY_CTRL  0x0064
+#define 

[PATCH 1/4] MAINTAINERS: add entry for NXP TDA1997x driver

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2093060..de7124e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13019,6 +13019,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git
 S: Maintained
 F: drivers/media/tuners/tda18271*
 
+TDA1997x MEDIA DRIVER
+M: Tim Harvey 
+L: linux-media@vger.kernel.org
+W: https://linuxtv.org
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/i2c/tda1997x.*
+
 TDA827x MEDIA DRIVER
 M: Michael Krufky 
 L: linux-media@vger.kernel.org
-- 
2.7.4

[PATCH 2/4] media: dt-bindings: Add bindings for TDA1997X

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 .../devicetree/bindings/media/i2c/tda1997x.txt | 159 +
 1 file changed, 159 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt 
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..8330733
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,159 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety fo connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible  :
+  - "nxp,tda19971" for the TDA19971
+  - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts  : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - vidout_portcfg  : array of pairs mapping VP output pins to pin groups
+
+Optional Properties:
+ - max-pixel-rate  : Maximum pixel rate supported by the SoC (MP/sec)
+ - audio-port  : parameters defining audio output port connection
+
+Optional Endpoint Properties:
+  The following three properties are defined in video-interfaces.txt and
+  are valid for source endpoints only:
+  - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+  - vsync-active: Vertical synchronization polarity. Defaults to active high.
+  - data-active: Data polarity. Defaults to active high.
+
+The Audio output port consists of A_CLK, A_WS, AP0, AP1, AP2, and AP3 pins
+and can support up to 8-chanenl audio using the following audio bus DAI 
formats:
+ - I2S16
+ - I2S32
+ - SPDIF
+ - OBA (One-Bit-Audio)
+ - I2S16_HBR_STRAIGHT (High Bitrate straight through)
+ - I2S16_HBR_DEMUX (High Bitrate demuxed)
+ - I2S32_HBR_DEMUX (High Bitrate demuxed)
+ - DST (Direct Stream Transfer)
+
+Audio samples can be output in either SPDIF or I2S bus formats.
+In I2S mode, the TDF1997X is the master with 16bit or 32bit words.
+The audio port output is configured by three parameters: DAI format, layout
+and clock scaler.
+
+Each DAI format has two pin layouts shown by the following table:
+   |  SPDIF  |  SPDIF  |   I2S   |   I2S   | HBR demux
+   | Layout0 | Layout1 | Layout0 | Layout1 | SPDIF  | I2S
+ --+-+-+-+-++
+ A_WS  | WS  | WS  | WS  | WS  | WS | WS
+ AP3   | | SPDIF3  | | SD3 | SPDIF[x+3] | SD[x+3]
+ AP2   | | SPDIF2  | | SD2 | SPDIF[x+2] | SD[x+2]
+ AP1   | | SPDIF1  | | SD1 | SPDIF[x+1] | SD[x+1]
+ AP0   | SPDIF   | SPDIF0  | SD  | SD0 | SPDIF[x]   | SD[x]
+ A_CLK | (32*Fs) | (32*Fs) |(32*Fs)  | (32*Fs) | (32*Fs)| (32*Fs)
+   | (64*Fs) | (64*Fs) |(64*Fs)  | (64*Fs) | (64*Fs)| (64*Fs)
+
+Freq(Sysclk) = 2*freq(Aclk)
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+   16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+   hdmi_receiver@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_1p8v>;
+   DVDD-supply = <_1p8v>;
+   /* audio output format */
+   audio-port = < TDA1997X_I2S16
+  

Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label documentation, DT example

[Jacek Anaszewski]

On 09/20/2017 10:53 PM, Rob Herring wrote:
> On Tue, Sep 19, 2017 at 11:01:02PM +0200, Jacek Anaszewski wrote:
>> Hi Pavel,
>>
>> On 09/18/2017 10:54 PM, Pavel Machek wrote:
>>> On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:
 Hi Pavel,

 On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:
> Hi!
>
>> Specify the exact label used if the label property is omitted in DT, as
>> well as use label in the example that conforms to LED device naming.
>>
>> @@ -69,11 +73,11 @@ Example
>>  flash-max-microamp = <32>;
>>  led-max-microamp = <6>;
>>  ams,input-max-microamp = <175>;
>> -label = "as3645a:flash";
>> +label = "as3645a:white:flash";
>>  };
>>  indicator@1 {
>>  reg = <0x1>;
>>  led-max-microamp = <1>;
>> -label = "as3645a:indicator";
>> +label = "as3645a:red:indicator";
>>  };
>>  };
>
> Ok, but userspace still has no chance to determine if this is flash
> from main camera or flash for front camera; todays smartphones have
> flashes on both cameras.
>
> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or
> ?

 If there's just a single one in the device, could you use that?

 Even if we name this so for N9 (and N900), the application still would only
 work with the two devices.
>>>
>>> Well, I'd plan to name it on other devices, too.
>>>
 My suggestion would be to look for a flash LED, and perhaps the maximum
 current as well. That should generally work better than assumptions on the
 label.
>>>
>>> If you just look for flash LED, you don't know if it is front one or
>>> back one. Its true that if you have just one flash it is usually on
>>> the back camera, but you can't know if maybe driver is not available
>>> for the main flash.
>>>
>>> Lets get this right, please "main_camera_flash" is 12 bytes more than
>>> "flash", and it saves application logic.. more than 12 bytes, I'm sure. 
>>
>> What you are trying to introduce is yet another level of LED class
>> device naming standard, one level below devicename:colour:function.
>> It seems you want also to come up with the set of standarized LED
>> function names. This would certainly have to be covered for consistency.
> 
> I really dislike how this naming convention is used for label. label is 
> supposed to be the phyically identifiable name. Having the devicename 
> defeats that. Perhaps color, too. We'd be better off with a color 
> property. It seems we're overloading the naming with too many things. 
> Now we're adding device association.

Regarding devicename - there is indeed inconsistency in the way how LED
DT bindings use label, as some of them use it for defining full LED
class device name, and the rest fill only colour and function, leaving
addition of a devicename to the driver.

The problem is also in current definition of label in LED common
bindings documentation, which says:

"It has to uniquely identify a device, i.e. no other LED class device
can be assigned the same label."

In view of your above words this is not true, and we probably should
remove this sentence (it doesn't have DT maintainer ack btw).

> I do want to see standard names though. On 96boards for example, there 
> are defined LEDs and locations. The function on some are defined (e.g. 
> WiFi/BT) and somewhat undefined on others (user{1-4}). I'd like to see 
> the same label across all boards.

Currently we have following LED functions (obtained with
grep label Documentation/devicetree/bindings/leds/* | sed
s'/^.*label/label/g' | awk -F"=" '{print $2}' | sed '/^$/d' | sed
s'/.*:\(.*\)";/\1/' | sed '/^\s\{1,\}/d' | sort -u)

0
1
2
2g
3
4
5
6
7
adsl
alarm
alive
aux
broadband
chrg
dsl
flash
green
indicator
inet
keypad
phone
power
red
sata
sata0
sata1
tel
tv
upgrading
usb
usr0
usr1
usr35
wan
white
wireless
wps
yellow

By extracting numerical pattern names and replacing numbers with N
we're getting something like this:

N
Ng
colour
adsl
alarm
alive
aux
broadband
chrg
dsl
flash
indicator
inet
keypad
phone
power
sataN
tel
tv
upgrading
usb
usrN
wan
wireless
wps

Is this list something you'd like to see as a base of standard LED
functions? It seems that this list would have to be continuously
supplemented with new positions.

-- 
Best regards,
Jacek Anaszewski

[PATCH v4 1/9] brcmsmac: make some local variables 'static const' to reduce stack size

[Arnd Bergmann]

With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:

broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 
'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 
3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 
2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]

Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.

This is the first of three patches to improve the stack usage in this
driver. It would be good to have this backported to stabl kernels
to get all drivers in 'allmodconfig' below the 2048 byte limit so
we can turn on the frame warning again globally, but I realize that
the patch is larger than the normal limit for stable backports.

The other two patches do not need to be backported.

Acked-by: Arend van Spriel 
Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 197 ++---
 1 file changed, 97 insertions(+), 100 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index b3aab2fe96eb..ef685465f80a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -14764,8 +14764,8 @@ static void 
wlc_phy_ipa_restore_tx_digi_filts_nphy(struct brcms_phy *pi)
 }
 
 static void
-wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, u8 *events, u8 *dlys,
-  u8 len)
+wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, const u8 *events,
+  const u8 *dlys, u8 len)
 {
u32 t1_offset, t2_offset;
u8 ctr;
@@ -15240,16 +15240,16 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev5(struct brcms_phy *pi)
 static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 {
u16 currband;
-   s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
-   s8 *lna1_gain_db = NULL;
-   s8 *lna1_gain_db_2 = NULL;
-   s8 *lna2_gain_db = NULL;
-   s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
-   s8 *tia_gain_db;
-   s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
-   s8 *tia_gainbits;
-   u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
-   u16 *rfseq_init_gain;
+   static const s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
+   const s8 *lna1_gain_db = NULL;
+   const s8 *lna1_gain_db_2 = NULL;
+   const s8 *lna2_gain_db = NULL;
+   static const s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 
};
+   const s8 *tia_gain_db;
+   static const s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
+   const s8 *tia_gainbits;
+   static const u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
+   const u16 *rfseq_init_gain;
u16 init_gaincode;
u16 clip1hi_gaincode;
u16 clip1md_gaincode = 0;
@@ -15310,10 +15310,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 
if ((freq <= 5080) || (freq == 5825)) {
 
-   s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
-   s8 lna1A_gain_db_2_rev7[] = {
-   11, 17, 22, 25};
-   s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
+   static const s8 lna1A_gain_db_rev7[] = { 11, 
16, 20, 24 };
+   static const s8 lna1A_gain_db_2_rev7[] = { 11, 
17, 22, 25};
+   static const s8 lna2A_gain_db_rev7[] = { -1, 6, 
10, 14 };
 
crsminu_th = 0x3e;
lna1_gain_db = lna1A_gain_db_rev7;
@@ -15321,10 +15320,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else if ((freq >= 5500) && (freq <= 5700)) {
 
-   s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
-   s8 lna1A_gain_db_2_rev7[] = {
-   12, 18, 22, 26};
-   s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
+   static const s8 lna1A_gain_db_rev7[] = { 11, 
17, 21, 25 };
+   static const s8 lna1A_gain_db_2_rev7[] = { 12, 
18, 22, 26};
+   static const s8 lna2A_gain_db_rev7[] = { 1, 8, 
12, 16 };
 
crsminu_th = 

[PATCH v4 9/9] kasan: rework Kconfig settings

[Arnd Bergmann]

We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which
can easily cause an overflow of the kernel stack, e.g.

drivers/gpu/drm/i915/gvt/handlers.c:2407:1: error: the frame size of 31216 
bytes is larger than 2048 bytes
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: error: the frame size of 
23632 bytes is larger than 2048 bytes
drivers/scsi/fnic/fnic_trace.c:451:1: error: the frame size of 5152 bytes is 
larger than 2048 bytes
fs/btrfs/relocation.c:1202:1: error: the frame size of 4256 bytes is larger 
than 2048 bytes
fs/fscache/stats.c:287:1: error: the frame size of 6552 bytes is larger than 
2048 bytes
lib/atomic64_test.c:250:1: error: the frame size of 12616 bytes is larger than 
2048 bytes
mm/vmscan.c:1367:1: error: the frame size of 5080 bytes is larger than 2048 
bytes
net/wireless/nl80211.c:1905:1: error: the frame size of 4232 bytes is larger 
than 2048 bytes

To reduce this risk, -fsanitize-address-use-after-scope is now split
out into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
frames that are smaller than 2 kilobytes most of the time on x86_64. An
earlier version of this patch also prevented combining KASAN_EXTRA with
KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.

A lot of warnings with KASAN_EXTRA go away if we disable KMEMCHECK,
as -fsanitize-address-use-after-scope seems to understand the builtin
memcpy, but adds checking code around an extern memcpy call. I had to work
around a circular dependency, as DEBUG_SLAB/SLUB depended on !KMEMCHECK,
while KASAN did it the other way round. Now we handle both the same way
and make KASAN and KMEMCHECK mutually exclusive.

All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
and CONFIG_KASAN_EXTRA=n have been submitted along with this patch, so
we can bring back that default now. KASAN_EXTRA=y still causes lots of
warnings but now defaults to !COMPILE_TEST to disable it in allmodconfig,
and it remains disabled in all other defconfigs since it is a new option.
I arbitrarily raise the warning limit for KASAN_EXTRA to 3072 to reduce
the noise, but an allmodconfig kernel still has around 50 warnings
on gcc-7.

I experimented a bit more with smaller stack frames and have another
follow-up series that reduces the warning limit for 64-bit architectures
to 1280 bytes (without CONFIG_KASAN).

With earlier versions of this patch series, I also had patches to
address the warnings we get with KASAN and/or KASAN_EXTRA, using a
"noinline_if_stackbloat" annotation. That annotation now got replaced with
a gcc-8 bugfix (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715)
and a workaround for older compilers, which means that KASAN_EXTRA is
now just as bad as before and will lead to an instant stack overflow in
a few extreme cases.

This reverts parts of commit commit 3f181b4 ("lib/Kconfig.debug: disable
-Wframe-larger-than warnings with KASAN=y").

Signed-off-by: Arnd Bergmann 
---
 lib/Kconfig.debug  |  4 ++--
 lib/Kconfig.kasan  | 13 -
 lib/Kconfig.kmemcheck  |  1 +
 scripts/Makefile.kasan |  3 +++
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b19c491cbc4e..5755875d4a80 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -217,7 +217,7 @@ config ENABLE_MUST_CHECK
 config FRAME_WARN
int "Warn for stack frames larger than (needs gcc 4.4)"
range 0 8192
-   default 0 if KASAN
+   default 3072 if KASAN_EXTRA
default 2048 if GCC_PLUGIN_LATENT_ENTROPY
default 1024 if !64BIT
default 2048 if 64BIT
@@ -503,7 +503,7 @@ config DEBUG_OBJECTS_ENABLE_DEFAULT
 
 config DEBUG_SLAB
bool "Debug slab memory allocations"
-   depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
+   depends on DEBUG_KERNEL && SLAB && !KMEMCHECK && !KASAN
help
  Say Y here to have the kernel do limited verification on memory
  allocation as well as poisoning memory on free to catch use of freed
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index bd38aab05929..db799e6e9dba 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -5,7 +5,7 @@ if HAVE_ARCH_KASAN
 
 config KASAN
bool "KASan: runtime memory debugger"
-   depends on SLUB || (SLAB && !DEBUG_SLAB)
+   depends on SLUB || SLAB
select CONSTRUCTORS
select STACKDEPOT
help
@@ -20,6 +20,17 @@ config KASAN
  Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB
  (the resulting kernel does not boot).
 
+config KASAN_EXTRA
+   bool "KAsan: extra checks"
+   depends on KASAN && DEBUG_KERNEL && !COMPILE_TEST
+   help
+ This enables further checks in the kernel address sanitizer, for now
+ it only includes the address-use-after-scope check that can lead
+ to excessive kernel stack usage, frame size warnings and longer
+ 

[PATCH v4 2/9] brcmsmac: split up wlc_phy_workarounds_nphy

[Arnd Bergmann]

The stack consumption in this driver is still relatively high, with one
remaining warning if the warning level is lowered to 1536 bytes:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: 
the frame size of 1880 bytes is larger than 1536 bytes 
[-Werror=frame-larger-than=]

The affected function is actually a collection of three separate 
implementations,
and each of them is fairly large by itself. Splitting them up is done easily
and improves readability at the same time.

I'm leaving the original indentation to make the review easier.

Acked-by: Arend van Spriel 
Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 178 -
 1 file changed, 104 insertions(+), 74 deletions(-)

This one and the following patch could be merged for either v4.14 or
v4.15 at this point, whichever the maintainers prefer. No need to
backport them to stable kernels.

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index ef685465f80a..ed409a80f3d2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16061,52 +16061,8 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct 
brcms_phy *pi)
}
 }
 
-static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
+static void wlc_phy_workarounds_nphy_rev7(struct brcms_phy *pi)
 {
-   static const u8 rfseq_rx2tx_events[] = {
-   NPHY_RFSEQ_CMD_NOP,
-   NPHY_RFSEQ_CMD_RXG_FBW,
-   NPHY_RFSEQ_CMD_TR_SWITCH,
-   NPHY_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_RFSEQ_CMD_TX_GAIN,
-   NPHY_RFSEQ_CMD_EXT_PA
-   };
-   u8 rfseq_rx2tx_dlys[] = { 8, 6, 6, 2, 4, 60, 1 };
-   static const u8 rfseq_tx2rx_events[] = {
-   NPHY_RFSEQ_CMD_NOP,
-   NPHY_RFSEQ_CMD_EXT_PA,
-   NPHY_RFSEQ_CMD_TX_GAIN,
-   NPHY_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_RFSEQ_CMD_TR_SWITCH,
-   NPHY_RFSEQ_CMD_RXG_FBW,
-   NPHY_RFSEQ_CMD_CLR_HIQ_DIS
-   };
-   static const u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
-   static const u8 rfseq_tx2rx_events_rev3[] = {
-   NPHY_REV3_RFSEQ_CMD_EXT_PA,
-   NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
-   NPHY_REV3_RFSEQ_CMD_TX_GAIN,
-   NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
-   NPHY_REV3_RFSEQ_CMD_RXG_FBW,
-   NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_REV3_RFSEQ_CMD_END
-   };
-   static const u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
-   u8 rfseq_rx2tx_events_rev3[] = {
-   NPHY_REV3_RFSEQ_CMD_NOP,
-   NPHY_REV3_RFSEQ_CMD_RXG_FBW,
-   NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
-   NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_REV3_RFSEQ_CMD_TX_GAIN,
-   NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
-   NPHY_REV3_RFSEQ_CMD_EXT_PA,
-   NPHY_REV3_RFSEQ_CMD_END
-   };
-   u8 rfseq_rx2tx_dlys_rev3[] = { 8, 6, 6, 4, 4, 18, 42, 1, 1 };
-
static const u8 rfseq_rx2tx_events_rev3_ipa[] = {
NPHY_REV3_RFSEQ_CMD_NOP,
NPHY_REV3_RFSEQ_CMD_RXG_FBW,
@@ -16120,29 +16076,15 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy 
*pi)
};
static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 
1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
-
-   s16 alpha0, alpha1, alpha2;
-   s16 beta0, beta1, beta2;
-   u32 leg_data_weights, ht_data_weights, nss1_data_weights,
-   stbc_data_weights;
+   u32 leg_data_weights;
u8 chan_freq_range = 0;
static const u16 dac_control = 0x0002;
u16 aux_adc_vmid_rev7_core0[] = { 0x8e, 0x96, 0x96, 0x96 };
u16 aux_adc_vmid_rev7_core1[] = { 0x8f, 0x9f, 0x9f, 0x96 };
-   u16 aux_adc_vmid_rev4[] = { 0xa2, 0xb4, 0xb4, 0x89 };
-   u16 aux_adc_vmid_rev3[] = { 0xa2, 0xb4, 0xb4, 0x89 };
-   u16 *aux_adc_vmid;
u16 aux_adc_gain_rev7[] = { 0x02, 0x02, 0x02, 0x02 };
-   u16 aux_adc_gain_rev4[] = { 0x02, 0x02, 0x02, 0x00 };
-   u16 aux_adc_gain_rev3[] = { 0x02, 0x02, 0x02, 0x00 };
-   u16 *aux_adc_gain;
-   static const u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
-   static const u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
s32 min_nvar_val = 0x18d;
s32 min_nvar_offset_6mbps = 20;
u8 pdetrange;
-   u8 triso;
-   u16 regval;
u16 afectrl_adc_ctrl1_rev7 = 0x20;
u16 afectrl_adc_ctrl2_rev7 = 0x0;
u16 rfseq_rx2tx_lpf_h_hpc_rev7 = 0x77;
@@ -16171,17 +16113,6 @@ static void 

[PATCH v4 8/9] netlink: fix nla_put_{u8,u16,u32} for KASAN

[Arnd Bergmann]

When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large
stack frames in some functions. This goes unnoticed normally because
CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit
3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with
KASAN=y").

The kernelci.org build bot however has the warning enabled and that led
me to investigate it a little further, as every build produces these warnings:

net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]

Most of this problem is now solved in gcc-8, which can consolidate
the stack slots for the inline function arguments. On older compilers
we can add a workaround by declaring a local variable in each function
to pass the inline function argument.

Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann 
---
 include/net/netlink.h | 73 ++-
 1 file changed, 55 insertions(+), 18 deletions(-)

diff --git a/include/net/netlink.h b/include/net/netlink.h
index e51cf5f81597..14c289393071 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -773,7 +773,10 @@ static inline int nla_parse_nested(struct nlattr *tb[], 
int maxtype,
  */
 static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value)
 {
-   return nla_put(skb, attrtype, sizeof(u8), );
+   /* temporary variables to work around GCC PR81715 with asan-stack=1 */
+   u8 tmp = value;
+
+   return nla_put(skb, attrtype, sizeof(u8), );
 }
 
 /**
@@ -784,7 +787,9 @@ static inline int nla_put_u8(struct sk_buff *skb, int 
attrtype, u8 value)
  */
 static inline int nla_put_u16(struct sk_buff *skb, int attrtype, u16 value)
 {
-   return nla_put(skb, attrtype, sizeof(u16), );
+   u16 tmp = value;
+
+   return nla_put(skb, attrtype, sizeof(u16), );
 }
 
 /**
@@ -795,7 +800,9 @@ static inline int nla_put_u16(struct sk_buff *skb, int 
attrtype, u16 value)
  */
 static inline int nla_put_be16(struct sk_buff *skb, int attrtype, __be16 value)
 {
-   return nla_put(skb, attrtype, sizeof(__be16), );
+   __be16 tmp = value;
+
+   return nla_put(skb, attrtype, sizeof(__be16), );
 }
 
 /**
@@ -806,7 +813,9 @@ static inline int nla_put_be16(struct sk_buff *skb, int 
attrtype, __be16 value)
  */
 static inline int nla_put_net16(struct sk_buff *skb, int attrtype, __be16 
value)
 {
-   return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, value);
+   __be16 tmp = value;
+
+   return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, tmp);
 }
 
 /**
@@ -817,7 +826,9 @@ static inline int nla_put_net16(struct sk_buff *skb, int 
attrtype, __be16 value)
  */
 static inline int nla_put_le16(struct sk_buff *skb, int attrtype, __le16 value)
 {
-   return nla_put(skb, attrtype, sizeof(__le16), );
+   __le16 tmp = value;
+
+   return nla_put(skb, attrtype, sizeof(__le16), );
 }
 
 /**
@@ -828,7 +839,9 @@ static inline int nla_put_le16(struct sk_buff *skb, int 
attrtype, __le16 value)
  */
 static inline int nla_put_u32(struct sk_buff *skb, int attrtype, u32 value)
 {
-   return nla_put(skb, attrtype, sizeof(u32), );
+   u32 tmp = value;
+
+   return nla_put(skb, attrtype, sizeof(u32), );
 }
 
 /**
@@ -839,7 +852,9 @@ static inline int nla_put_u32(struct sk_buff *skb, int 
attrtype, u32 value)
  */
 static inline int nla_put_be32(struct sk_buff *skb, int attrtype, __be32 value)
 {
-   return nla_put(skb, attrtype, sizeof(__be32), );
+   __be32 tmp = value;
+
+   return nla_put(skb, attrtype, sizeof(__be32), );
 }
 
 /**
@@ -850,7 +865,9 @@ static inline int nla_put_be32(struct sk_buff *skb, int 
attrtype, __be32 value)
  */
 static inline int nla_put_net32(struct sk_buff *skb, int attrtype, __be32 
value)
 {
-   return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, value);
+   __be32 tmp = value;
+
+   return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, tmp);
 }
 
 /**
@@ -861,7 +878,9 @@ static inline int nla_put_net32(struct sk_buff *skb, int 
attrtype, __be32 value)
  */
 static inline int nla_put_le32(struct sk_buff *skb, int attrtype, __le32 value)
 {
-   return nla_put(skb, attrtype, sizeof(__le32), );
+   __le32 tmp = value;
+
+   return nla_put(skb, attrtype, sizeof(__le32), );
 }
 
 /**
@@ -874,7 +893,9 @@ static inline int nla_put_le32(struct sk_buff *skb, int 
attrtype, __le32 value)
 static inline int nla_put_u64_64bit(struct sk_buff *skb, int attrtype,
u64 value, 

Re: [PATCH v2 2/2] [media] imx: ask source subdevice for number of active data lanes

[Steve Longerbeam]

On 09/21/2017 08:30 AM, Philipp Zabel wrote:

Temporarily use g_mbus_config() to determine the number of active data
lanes used by the transmitter. If g_mbus_config is not supported or
does not return the number of active lines, default to using all
connected data lines.

Signed-off-by: Philipp Zabel 


Acked-by: Steve Longerbeam 


---
New in v2:
  - Use the active lanes reported via g_mbus_config(), if available, to
configure the CSI2_N_LANES register correctly.
---
  drivers/staging/media/imx/imx6-mipi-csi2.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c 
b/drivers/staging/media/imx/imx6-mipi-csi2.c
index 5061f3f524fd5..cd19730d0159c 100644
--- a/drivers/staging/media/imx/imx6-mipi-csi2.c
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -135,10 +135,8 @@ static void csi2_enable(struct csi2_dev *csi2, bool enable)
}
  }
  
-static void csi2_set_lanes(struct csi2_dev *csi2)

+static void csi2_set_lanes(struct csi2_dev *csi2, int lanes)
  {
-   int lanes = csi2->bus.num_data_lanes;
-
writel(lanes - 1, csi2->base + CSI2_N_LANES);
  }
  
@@ -301,6 +299,9 @@ static void csi2ipu_gasket_init(struct csi2_dev *csi2)
  
  static int csi2_start(struct csi2_dev *csi2)

  {
+   const u32 mask = V4L2_MBUS_CSI2_LANE_MASK;
+   struct v4l2_mbus_config cfg;
+   int lanes = 0;
int ret;
  
  	ret = clk_prepare_enable(csi2->pix_clk);

@@ -316,7 +317,10 @@ static int csi2_start(struct csi2_dev *csi2)
goto err_disable_clk;
  
  	/* Step 4 */

-   csi2_set_lanes(csi2);
+   ret = v4l2_subdev_call(csi2->src_sd, video, g_mbus_config, );
+   if (ret == 0)
+   lanes = (cfg.flags & mask) >> __ffs(mask);
+   csi2_set_lanes(csi2, lanes ?: csi2->bus.num_data_lanes);
csi2_enable(csi2, true);
  
  	/* Step 5 */

[PATCH v4 6/9] dvb-frontends: fix i2c access helpers for KASAN

[Arnd Bergmann]

A typical code fragment was copied across many dvb-frontend drivers and
causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7:

drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

gcc-8 now solves this by consolidating the stack slots for the argument
variables, but on older compilers we can get the same behavior by taking
the pointer of a local variable rather than the inline function argument.

Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann 
---
I'm undecided here whether there should be a comment pointing
to PR81715 for each file that the bogus local variable workaround
to prevent it from being cleaned up again. It's probably not
necessary since anything that causes actual problems would also
trigger a build warning.
---
 drivers/media/dvb-frontends/ascot2e.c | 4 +++-
 drivers/media/dvb-frontends/cxd2841er.c   | 4 +++-
 drivers/media/dvb-frontends/helene.c  | 4 +++-
 drivers/media/dvb-frontends/horus3a.c | 4 +++-
 drivers/media/dvb-frontends/itd1000.c | 5 +++--
 drivers/media/dvb-frontends/mt312.c   | 4 +++-
 drivers/media/dvb-frontends/stb0899_drv.c | 3 ++-
 drivers/media/dvb-frontends/stb6100.c | 6 --
 drivers/media/dvb-frontends/stv0367.c | 4 +++-
 drivers/media/dvb-frontends/stv090x.c | 4 +++-
 drivers/media/dvb-frontends/stv6110x.c| 4 +++-
 drivers/media/dvb-frontends/zl10039.c | 4 +++-
 12 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/drivers/media/dvb-frontends/ascot2e.c 
b/drivers/media/dvb-frontends/ascot2e.c
index 0ee0df53b91b..1219272ca3f0 100644
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -155,7 +155,9 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
 
 static int ascot2e_write_reg(struct ascot2e_priv *priv, u8 reg, u8 val)
 {
-   return ascot2e_write_regs(priv, reg, , 1);
+   u8 tmp = val;
+
+   return ascot2e_write_regs(priv, reg, , 1);
 }
 
 static int ascot2e_read_regs(struct ascot2e_priv *priv,
diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 48ee9bc00c06..b7574deff5c6 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -257,7 +257,9 @@ static int cxd2841er_write_regs(struct cxd2841er_priv *priv,
 static int cxd2841er_write_reg(struct cxd2841er_priv *priv,
   u8 addr, u8 reg, u8 val)
 {
-   return cxd2841er_write_regs(priv, addr, reg, , 1);
+   u8 tmp = val;
+
+   return cxd2841er_write_regs(priv, addr, reg, , 1);
 }
 
 static int cxd2841er_read_regs(struct cxd2841er_priv *priv,
diff --git a/drivers/media/dvb-frontends/helene.c 
b/drivers/media/dvb-frontends/helene.c
index 4bf5a551ba40..6e93f2d1575b 100644
--- a/drivers/media/dvb-frontends/helene.c
+++ b/drivers/media/dvb-frontends/helene.c
@@ -331,7 +331,9 @@ static int helene_write_regs(struct helene_priv *priv,
 
 static int helene_write_reg(struct helene_priv *priv, u8 reg, u8 val)
 {
-   return helene_write_regs(priv, reg, , 1);
+   u8 tmp = val;
+
+   return helene_write_regs(priv, reg, , 1);
 }
 
 static int helene_read_regs(struct helene_priv *priv,
diff --git a/drivers/media/dvb-frontends/horus3a.c 
b/drivers/media/dvb-frontends/horus3a.c
index 68d759c4c52e..fa9e2d373073 100644
--- a/drivers/media/dvb-frontends/horus3a.c
+++ b/drivers/media/dvb-frontends/horus3a.c
@@ -89,7 +89,9 @@ static int horus3a_write_regs(struct horus3a_priv *priv,
 
 static int horus3a_write_reg(struct horus3a_priv *priv, u8 reg, u8 val)
 {
-   return horus3a_write_regs(priv, reg, , 1);
+   u8 tmp = val;
+
+   return horus3a_write_regs(priv, reg, , 1);
 }
 
 static int horus3a_enter_power_save(struct horus3a_priv *priv)
diff --git a/drivers/media/dvb-frontends/itd1000.c 
b/drivers/media/dvb-frontends/itd1000.c
index 5bb1e73a10b4..1ac5177162f6 100644
--- a/drivers/media/dvb-frontends/itd1000.c
+++ b/drivers/media/dvb-frontends/itd1000.c
@@ -95,8 +95,9 @@ static int itd1000_read_reg(struct itd1000_state *state, u8 
reg)
 
 static inline int itd1000_write_reg(struct itd1000_state *state, u8 r, u8 v)
 {
-   int ret = itd1000_write_regs(state, r, , 1);
-   state->shadow[r] = v;
+   u8 tmp = v;
+   int ret = 

[PATCH v4 5/9] r820t: fix r820t_write_reg for KASAN

[Arnd Bergmann]

With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:

drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is 
larger than 2048 bytes [-Werror=frame-larger-than=]

This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann 
---
 drivers/media/tuners/r820t.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index ba80376a3b86..d097eb04a0e9 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -396,9 +396,11 @@ static int r820t_write(struct r820t_priv *priv, u8 reg, 
const u8 *val,
return 0;
 }
 
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
 {
-   return r820t_write(priv, reg, , 1);
+   u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */
+
+   return r820t_write(priv, reg, , 1);
 }
 
 static int r820t_read_cache_reg(struct r820t_priv *priv, int reg)
@@ -411,17 +413,18 @@ static int r820t_read_cache_reg(struct r820t_priv *priv, 
int reg)
return -EINVAL;
 }
 
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
u8 bit_mask)
 {
+   u8 tmp = val;
int rc = r820t_read_cache_reg(priv, reg);
 
if (rc < 0)
return rc;
 
-   val = (rc & ~bit_mask) | (val & bit_mask);
+   tmp = (rc & ~bit_mask) | (tmp & bit_mask);
 
-   return r820t_write(priv, reg, , 1);
+   return r820t_write(priv, reg, , 1);
 }
 
 static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len)
-- 
2.9.0

Re: [PATCH 0/8] [media] v4l2-core: Fine-tuning for some function implementations

[SF Markus Elfring]

> Sorry Markus, just stay away from the videobuf-* sources.

Will the software evolution be continued for related source files?
Are there any update candidates left over in the directory “v4l2-core”?

Regards,
Markus

Re: [media] spca500: Use common error handling code in spca500_synch310()

[SF Markus Elfring]

> No one needs to argue about keeping it the way it is.

I got an other impression in this case after a bit of information
was presented which seems to be contradictory.


> I don't see any improvement brought by the proposed change,

Do you care if the source code for an error message is present only once
in this function?


> other than making the code harder to read.

I suggest to reconsider this concern.


> I find goto statements hard to read, because they inherently make some
> information non local.  They are justified in error path handling,
> if the error path only unwinds what the function did early on.
> That's not the case here.

I am looking also for change possibilities without such a restriction.

 
> The same applies to dozens of patches you proposed recently.

I proposed some software updates to reduce a bit of code duplication.

Do you find any corresponding approaches useful?

Regards,
Markus

[RESEND PATCH v3 0/4] AS3645A fixes

[Sakari Ailus]

Hi Jacek and others,

(Resending, got devicetree list address wrong.)

Here are a few fixes for the as3645a DTS as well as changes in bindings.
The driver is not in a release yet.

Jacek: Could you take these to your fixes branch so we don't get faulty DT
bindings to a release? I've dropped the patches related to LED naming and
label property as the discusion appears to continue on that.

Thanks.


since v2:

- Drop patches related to LED naming.

- No other changes.

since v1:

- Add LED colour to the name of the LED, this adds two patches to the set.

- Add a patch to unregister the indicator LED in driver remove function.

- No changes to v1 patches.

Sakari Ailus (4):
  as3645a: Use ams,input-max-microamp as documented in DT bindings
  dt: bindings: as3645a: Use LED number to refer to LEDs
  as3645a: Use integer numbers for parsing LEDs
  as3645a: Unregister indicator LED on device unbind

 .../devicetree/bindings/leds/ams,as3645a.txt   | 28 +
 arch/arm/boot/dts/omap3-n950-n9.dtsi   | 10 +---
 drivers/leds/leds-as3645a.c| 29 +++---
 3 files changed, 51 insertions(+), 16 deletions(-)

-- 
2.11.0

[RESEND PATCH v3 1/4] as3645a: Use ams,input-max-microamp as documented in DT bindings

[Sakari Ailus]

DT bindings document the property "ams,input-max-microamp" that limits the
chip's maximum input current. The driver and the DTS however used
"peak-current-limit" property. Fix this by using the property documented
in DT binding documentation.

Signed-off-by: Sakari Ailus 
Acked-by: Pavel Machek 
Acked-by: Jacek Anaszewski 
---
 arch/arm/boot/dts/omap3-n950-n9.dtsi | 2 +-
 drivers/leds/leds-as3645a.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi 
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index cb47ae79a5f9..b86fc83a5a65 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -273,7 +273,7 @@
flash-timeout-us = <15>;
flash-max-microamp = <32>;
led-max-microamp = <6>;
-   peak-current-limit = <175>;
+   ams,input-max-microamp = <175>;
};
indicator {
led-max-microamp = <1>;
diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c
index e0898233..e3f89c6130d2 100644
--- a/drivers/leds/leds-as3645a.c
+++ b/drivers/leds/leds-as3645a.c
@@ -534,7 +534,7 @@ static int as3645a_parse_node(struct as3645a *flash,
of_property_read_u32(flash->flash_node, "voltage-reference",
 >voltage_reference);
 
-   of_property_read_u32(flash->flash_node, "peak-current-limit",
+   of_property_read_u32(flash->flash_node, "ams,input-max-microamp",
 >peak);
cfg->peak = AS_PEAK_mA_TO_REG(cfg->peak);
 
-- 
2.11.0

[RESEND PATCH v3 3/4] as3645a: Use integer numbers for parsing LEDs

[Sakari Ailus]

Use integer numbers for LEDs, 0 is the flash and 1 is the indicator.

Signed-off-by: Sakari Ailus 
Acked-by: Pavel Machek 
Acked-by: Jacek Anaszewski 
---
 arch/arm/boot/dts/omap3-n950-n9.dtsi |  8 ++--
 drivers/leds/leds-as3645a.c  | 26 --
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi 
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index b86fc83a5a65..1b0bd72945f2 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -267,15 +267,19 @@
clock-frequency = <40>;
 
as3645a@30 {
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x30>;
compatible = "ams,as3645a";
-   flash {
+   flash@0 {
+   reg = <0x0>;
flash-timeout-us = <15>;
flash-max-microamp = <32>;
led-max-microamp = <6>;
ams,input-max-microamp = <175>;
};
-   indicator {
+   indicator@1 {
+   reg = <0x1>;
led-max-microamp = <1>;
};
};
diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c
index e3f89c6130d2..605e0c64e974 100644
--- a/drivers/leds/leds-as3645a.c
+++ b/drivers/leds/leds-as3645a.c
@@ -112,6 +112,10 @@
 #define AS_PEAK_mA_TO_REG(a) \
((min_t(u32, AS_PEAK_mA_MAX, a) - 1250) / 250)
 
+/* LED numbers for Devicetree */
+#define AS_LED_FLASH   0
+#define AS_LED_INDICATOR   1
+
 enum as_mode {
AS_MODE_EXT_TORCH = 0 << AS_CONTROL_MODE_SETTING_SHIFT,
AS_MODE_INDICATOR = 1 << AS_CONTROL_MODE_SETTING_SHIFT,
@@ -491,10 +495,29 @@ static int as3645a_parse_node(struct as3645a *flash,
  struct device_node *node)
 {
struct as3645a_config *cfg = >cfg;
+   struct device_node *child;
const char *name;
int rval;
 
-   flash->flash_node = of_get_child_by_name(node, "flash");
+   for_each_child_of_node(node, child) {
+   u32 id = 0;
+
+   of_property_read_u32(child, "reg", );
+
+   switch (id) {
+   case AS_LED_FLASH:
+   flash->flash_node = of_node_get(child);
+   break;
+   case AS_LED_INDICATOR:
+   flash->indicator_node = of_node_get(child);
+   break;
+   default:
+   dev_warn(>client->dev,
+"unknown LED %u encountered, ignoring\n", id);
+   break;
+   }
+   }
+
if (!flash->flash_node) {
dev_err(>client->dev, "can't find flash node\n");
return -ENODEV;
@@ -538,7 +561,6 @@ static int as3645a_parse_node(struct as3645a *flash,
 >peak);
cfg->peak = AS_PEAK_mA_TO_REG(cfg->peak);
 
-   flash->indicator_node = of_get_child_by_name(node, "indicator");
if (!flash->indicator_node) {
dev_warn(>client->dev,
 "can't find indicator node\n");
-- 
2.11.0

[RESEND PATCH v3 4/4] as3645a: Unregister indicator LED on device unbind

[Sakari Ailus]

The indicator LED was registered in probe but was not removed in driver
remove callback. Fix this.

Signed-off-by: Sakari Ailus 
---
 drivers/leds/leds-as3645a.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c
index 605e0c64e974..9a257f969300 100644
--- a/drivers/leds/leds-as3645a.c
+++ b/drivers/leds/leds-as3645a.c
@@ -743,6 +743,7 @@ static int as3645a_remove(struct i2c_client *client)
as3645a_set_control(flash, AS_MODE_EXT_TORCH, false);
 
v4l2_flash_release(flash->vf);
+   v4l2_flash_release(flash->vfind);
 
led_classdev_flash_unregister(>fled);
led_classdev_unregister(>iled_cdev);
-- 
2.11.0

[RESEND PATCH v3 2/4] dt: bindings: as3645a: Use LED number to refer to LEDs

[Sakari Ailus]

Use integers (reg property) to tell the number of the LED to the driver
instead of the node name. While both of these approaches are currently
used by the LED bindings, using integers will require less driver changes
for ACPI support. Additionally, it will make possible LED naming using
chip and LED node names, effectively making the label property most useful
for human-readable names only.

Signed-off-by: Sakari Ailus 
Acked-by: Jacek Anaszewski 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/leds/ams,as3645a.txt   | 28 ++
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt 
b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
index 12c5ef26ec73..fdc40e354a64 100644
--- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
+++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
@@ -15,11 +15,14 @@ Required properties
 
 compatible : Must be "ams,as3645a".
 reg: The I2C address of the device. Typically 0x30.
+#address-cells : 1
+#size-cells: 0
 
 
-Required properties of the "flash" child node
-=
+Required properties of the flash child node (0)
+===
 
+reg: 0
 flash-timeout-us: Flash timeout in microseconds. The value must be in
  the range [10, 85] and divisible by 5.
 flash-max-microamp: Maximum flash current in microamperes. Has to be
@@ -33,20 +36,21 @@ ams,input-max-microamp: Maximum flash controller input 
current. The
and divisible by 5.
 
 
-Optional properties of the "flash" child node
-=
+Optional properties of the flash child node
+===
 
 label  : The label of the flash LED.
 
 
-Required properties of the "indicator" child node
-=
+Required properties of the indicator child node (1)
+===
 
+reg: 1
 led-max-microamp: Maximum indicator current. The allowed values are
  2500, 5000, 7500 and 1.
 
-Optional properties of the "indicator" child node
-=
+Optional properties of the indicator child node
+===
 
 label  : The label of the indicator LED.
 
@@ -55,16 +59,20 @@ Example
 ===
 
as3645a@30 {
+   #address-cells: 1
+   #size-cells: 0
reg = <0x30>;
compatible = "ams,as3645a";
-   flash {
+   flash@0 {
+   reg = <0x0>;
flash-timeout-us = <15>;
flash-max-microamp = <32>;
led-max-microamp = <6>;
ams,input-max-microamp = <175>;
label = "as3645a:flash";
};
-   indicator {
+   indicator@1 {
+   reg = <0x1>;
led-max-microamp = <1>;
label = "as3645a:indicator";
};
-- 
2.11.0

[PATCH v4 0/2] media: v4l: Add support for the Cadence MIPI-CSI2 RX

[Maxime Ripard]

Hi,

Here is the fourth attempt at supporting the MIPI-CSI2 RX block from
Cadence.

This IP block is able to receive CSI data over up to 4 lanes, and
split it to over 4 streams. Those streams are basically the interfaces
to the video grabbers that will perform the capture.

It is able to map streams to both CSI datatypes and virtual channels,
dynamically. This is unclear at this point what the right way to
support it would be, so the driver only uses a static mapping between
the virtual channels and streams, and ignores the data types.

This serie depends on the version 14 of the serie "Unified fwnode
endpoint parser, async sub-device notifier support, N9 flash DTS" by
Sakari Ailus

Let me know what you think!
Maxime

Changes from v3:
  - Removed stale printk
  - Propagate start/stop functions error code to s_stream
  - Renamed the DT bindings files
  - Clarified the output ports wording in the DT binding doc
  - Added a define for the maximum number of lanes
  - Rebased on top of Sakari's serie
  - Gathered tags based on the reviews

Changes from v2:
  - Added reference counting for the controller initialisation
  - Fixed checkpatch warnings
  - Moved the sensor initialisation after the DPHY configuration
  - Renamed the sensor fields to source for consistency
  - Defined some variables
  - Renamed a few structures variables
  - Added internal and external phy errors messages
  - Reworked the binding slighty by making the external D-PHY optional
  - Moved the notifier registration in the probe function
  - Removed some clocks that are not system clocks
  - Added clocks enabling where needed
  - Added the code to remap the data lanes
  - Changed the memory allocator for the non-devm function, and a
comment explaining why
  - Reworked the binding wording

Changes from v1:
  - Amended the DT bindings as suggested by Rob
  - Rebase on top of 4.13-rc1 and latest Niklas' serie iteration

Maxime Ripard (2):
  dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings
  v4l: cadence: Add Cadence MIPI-CSI2 RX driver

 .../devicetree/bindings/media/cdns,csi2rx.txt  |  97 
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cadence/Kconfig |  12 +
 drivers/media/platform/cadence/Makefile|   1 +
 drivers/media/platform/cadence/cdns-csi2rx.c   | 486 +
 6 files changed, 599 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

-- 
2.13.5

[PATCH v4 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings

[Maxime Ripard]

The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to
4 CSI-2 lanes, and can route the frames to up to 4 streams, depending on
the hardware implementation.

It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.

Acked-by: Rob Herring 
Acked-by: Benoit Parrot 
Acked-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2rx.txt  | 97 ++
 1 file changed, 97 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
new file mode 100644
index ..e9c30f964a96
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
@@ -0,0 +1,97 @@
+Cadence MIPI-CSI2 RX controller
+===
+
+The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
+lanes in input, and 4 different pixel streams in output.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* sys_clk: main clock
+* p_clk: register bank clock
+* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+
+Optional properties:
+  - phys: phandle to the external D-PHY, phy-names must be provided
+  - phy-names: must contain dphy, if the implementation uses an
+   external D-PHY
+
+Required subnodes:
+  - ports: A ports node with one port child node per device input and output
+   port, in accordance with the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   port nodes numbered as follows.
+
+   Port Description
+   -
+   0CSI-2 input
+   1Stream 0 output
+   2Stream 1 output
+   3Stream 2 output
+   4Stream 3 output
+
+   The stream output port nodes are optional if they are not connected
+   to anything at the hardware level or implemented in the design.
+
+Example:
+
+csi2rx: csi-bridge@0d06 {
+   compatible = "cdns,csi2rx";
+   reg = <0x0d06 0x1000>;
+   clocks = <>, <>
+<>, <>,
+<>, <>;
+   clock-names = "sys_clk", "p_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2rx_in_sensor: endpoint {
+   remote-endpoint = <_out_csi2rx>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2rx_out_grabber0: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2rx_out_grabber1: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2rx_out_grabber2: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2rx_out_grabber3: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+   };
+};
-- 
2.13.5

[PATCH v4 2/2] v4l: cadence: Add Cadence MIPI-CSI2 RX driver

[Maxime Ripard]

The Cadence CSI-2 RX Controller is an hardware block meant to be used as a
bridge between a CSI-2 bus and pixel grabbers.

It supports operating with internal or external D-PHY, with up to 4 lanes,
or without any D-PHY. The current code only supports the former case.

It also support dynamic mapping of the CSI-2 virtual channels to the
associated pixel grabbers, but that isn't allowed at the moment either.

Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cadence/Kconfig   |  12 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2rx.c | 486 +++
 5 files changed, 502 insertions(+)
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49b8674..adfced50504c 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -26,6 +26,7 @@ config VIDEO_VIA_CAMERA
 #
 # Platform multimedia device configuration
 #
+source "drivers/media/platform/cadence/Kconfig"
 
 source "drivers/media/platform/davinci/Kconfig"
 
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946bf032..44d39b7c7bf7 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -2,6 +2,8 @@
 # Makefile for the video capture/playback device drivers.
 #
 
+obj-$(CONFIG_VIDEO_CADENCE)+= cadence/
+
 obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
 
 obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
new file mode 100644
index ..d1b6bbb6a0eb
--- /dev/null
+++ b/drivers/media/platform/cadence/Kconfig
@@ -0,0 +1,12 @@
+config VIDEO_CADENCE
+   bool "Cadence Video Devices"
+
+if VIDEO_CADENCE
+
+config VIDEO_CADENCE_CSI2RX
+   tristate "Cadence MIPI-CSI2 RX Controller v1.3"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+
+endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
new file mode 100644
index ..99a4086b7448
--- /dev/null
+++ b/drivers/media/platform/cadence/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
new file mode 100644
index ..0a35ad0b697f
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -0,0 +1,486 @@
+/*
+ * Driver for Cadence MIPI-CSI2 RX Controller v1.3
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2RX_DEVICE_CFG_REG  0x000
+
+#define CSI2RX_SOFT_RESET_REG  0x004
+#define CSI2RX_SOFT_RESET_PROTOCOL BIT(1)
+#define CSI2RX_SOFT_RESET_FRONTBIT(0)
+
+#define CSI2RX_STATIC_CFG_REG  0x008
+#define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane)  ((plane) << (16 + 
(llane) * 4))
+#define CSI2RX_STATIC_CFG_LANES_MASK   GENMASK(11, 8)
+
+#define CSI2RX_STREAM_BASE(n)  (((n) + 1) * 0x100)
+
+#define CSI2RX_STREAM_CTRL_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x000)
+#define CSI2RX_STREAM_CTRL_START   BIT(0)
+
+#define CSI2RX_STREAM_DATA_CFG_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x008)
+#define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECTBIT(31)
+#define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n)BIT((n) + 16)
+
+#define CSI2RX_STREAM_CFG_REG(n)   (CSI2RX_STREAM_BASE(n) + 0x00c)
+#define CSI2RX_STREAM_CFG_FIFO_MODE_LARGE_BUF  (1 << 8)
+
+#define CSI2RX_LANES_MAX   4
+#define CSI2RX_STREAMS_MAX 4
+
+enum csi2rx_pads {
+   CSI2RX_PAD_SINK,
+   CSI2RX_PAD_SOURCE_STREAM0,
+   CSI2RX_PAD_SOURCE_STREAM1,
+   CSI2RX_PAD_SOURCE_STREAM2,
+   CSI2RX_PAD_SOURCE_STREAM3,
+   CSI2RX_PAD_MAX,
+};
+
+struct csi2rx_priv {
+   struct device   *dev;
+   atomic_tcount;
+
+   void __iomem*base;
+   struct clk  *sys_clk;
+   struct clk  *p_clk;
+   struct clk  

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

[Yong]

Hello Mylène,

On Fri, 22 Sep 2017 10:44:13 +0200
Mylene JOSSERAND  wrote:

> Hello Yong,
> 
> Thank you for these drivers!
> 
> I tested it with an OV5640 camera on an Nanopi M1 plus (Allwinner H3)
> and I noticed that I got a frame correctly displayed only on a half of
> the frame's size.
> 
> It is related to your "sun6i_csi_set_window" function (see
> below).
> 
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datasheet but by testing and guess.
> > 
> > This patch implement a v4l2 framework driver for it.
> > 
> > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > ISP's support are not included in this patch.
> > 
> > Signed-off-by: Yong Deng 
> > ---
> >  drivers/media/platform/Kconfig   |   1 +
> >  drivers/media/platform/Makefile  |   2 +
> >  drivers/media/platform/sun6i-csi/Kconfig |   9 +
> >  drivers/media/platform/sun6i-csi/Makefile|   3 +
> >  drivers/media/platform/sun6i-csi/sun6i_csi.c | 545
> > +++ drivers/media/platform/sun6i-csi/sun6i_csi.h |
> > 203 ++ drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827
> > +++
> > drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
> > drivers/media/platform/sun6i-csi/sun6i_video.c   | 663
> > ++ drivers/media/platform/sun6i-csi/sun6i_video.h
> > |  61 ++ 10 files changed, 2520 insertions(+) create mode 100644
> > drivers/media/platform/sun6i-csi/Kconfig create mode 100644
> > drivers/media/platform/sun6i-csi/Makefile create mode 100644
> > drivers/media/platform/sun6i-csi/sun6i_csi.c create mode 100644
> > drivers/media/platform/sun6i-csi/sun6i_csi.h create mode 100644
> > drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c create mode 100644
> > drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h create mode 100644
> > drivers/media/platform/sun6i-csi/sun6i_video.c create mode 100644
> > drivers/media/platform/sun6i-csi/sun6i_video.h
> > 
> > diff --git a/drivers/media/platform/Kconfig
> > b/drivers/media/platform/Kconfig index 0c741d1..8371a87 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
> >  source "drivers/media/platform/xilinx/Kconfig"
> >  source "drivers/media/platform/rcar-vin/Kconfig"
> >  source "drivers/media/platform/atmel/Kconfig"
> > +source "drivers/media/platform/sun6i-csi/Kconfig"
> >  
> 
> 
> 
> > +static void sun6i_csi_set_format(struct sun6i_csi_dev *sdev)
> > +{
> > +   struct sun6i_csi *csi = >csi;
> > +   u32 cfg;
> > +   u32 val;
> > +
> > +   regmap_read(sdev->regmap, CSI_CH_CFG_REG, );
> > +
> > +   cfg &= ~(CSI_CH_CFG_INPUT_FMT_MASK |
> > +CSI_CH_CFG_OUTPUT_FMT_MASK | CSI_CH_CFG_VFLIP_EN |
> > +CSI_CH_CFG_HFLIP_EN | CSI_CH_CFG_FIELD_SEL_MASK |
> > +CSI_CH_CFG_INPUT_SEQ_MASK);
> > +
> > +   val = get_csi_input_format(csi->config.code,
> > csi->config.pixelformat);
> > +   cfg |= CSI_CH_CFG_INPUT_FMT(val);
> > +
> > +   val = get_csi_output_format(csi->config.code,
> > csi->config.field);
> > +   cfg |= CSI_CH_CFG_OUTPUT_FMT(val);
> > +
> > +   val = get_csi_input_seq(csi->config.code,
> > csi->config.pixelformat);
> > +   cfg |= CSI_CH_CFG_INPUT_SEQ(val);
> > +
> > +   if (csi->config.field == V4L2_FIELD_TOP)
> > +   cfg |= CSI_CH_CFG_FIELD_SEL_FIELD0;
> > +   else if (csi->config.field == V4L2_FIELD_BOTTOM)
> > +   cfg |= CSI_CH_CFG_FIELD_SEL_FIELD1;
> > +   else
> > +   cfg |= CSI_CH_CFG_FIELD_SEL_BOTH;
> > +
> > +   regmap_write(sdev->regmap, CSI_CH_CFG_REG, cfg);
> > +}
> > +
> > +static void sun6i_csi_set_window(struct sun6i_csi_dev *sdev)
> > +{
> > +   struct sun6i_csi_config *config = >csi.config;
> > +   u32 bytesperline_y;
> > +   u32 bytesperline_c;
> > +   int *planar_offset = sdev->planar_offset;
> > +
> > +   regmap_write(sdev->regmap, CSI_CH_HSIZE_REG,
> > +CSI_CH_HSIZE_HOR_LEN(config->width) |
> > +CSI_CH_HSIZE_HOR_START(0));
> > +   regmap_write(sdev->regmap, CSI_CH_VSIZE_REG,
> > +CSI_CH_VSIZE_VER_LEN(config->height) |
> > +CSI_CH_VSIZE_VER_START(0));
> 
> In my case, the HOR_LEN and VER_LEN were not correctly configured.
> 
> They were configured to width and height (640 * 480) but as I was
> using a YUYV format, the pixel's size is 2 bytes so the
> horizontal/vertical lines' lengths were divided by 2.
> 
> Currently, I fixed that by getting the number of bytes per pixel with
> "v4l2_pixformat_get_bpp()":
> 
> +   int bytes_pixel;
> +
> +   bytes_pixel = v4l2_pixformat_get_bpp(config->pixelformat) / 8;
>  
> regmap_write(sdev->regmap, CSI_CH_HSIZE_REG,
> -CSI_CH_HSIZE_HOR_LEN(config->width) |
> +

[PATCH v3 1/4] as3645a: Use ams,input-max-microamp as documented in DT bindings

[Sakari Ailus]

DT bindings document the property "ams,input-max-microamp" that limits the
chip's maximum input current. The driver and the DTS however used
"peak-current-limit" property. Fix this by using the property documented
in DT binding documentation.

Signed-off-by: Sakari Ailus 
Acked-by: Pavel Machek 
Acked-by: Jacek Anaszewski 
---
 arch/arm/boot/dts/omap3-n950-n9.dtsi | 2 +-
 drivers/leds/leds-as3645a.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi 
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index cb47ae79a5f9..b86fc83a5a65 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -273,7 +273,7 @@
flash-timeout-us = <15>;
flash-max-microamp = <32>;
led-max-microamp = <6>;
-   peak-current-limit = <175>;
+   ams,input-max-microamp = <175>;
};
indicator {
led-max-microamp = <1>;
diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c
index e0898233..e3f89c6130d2 100644
--- a/drivers/leds/leds-as3645a.c
+++ b/drivers/leds/leds-as3645a.c
@@ -534,7 +534,7 @@ static int as3645a_parse_node(struct as3645a *flash,
of_property_read_u32(flash->flash_node, "voltage-reference",
 >voltage_reference);
 
-   of_property_read_u32(flash->flash_node, "peak-current-limit",
+   of_property_read_u32(flash->flash_node, "ams,input-max-microamp",
 >peak);
cfg->peak = AS_PEAK_mA_TO_REG(cfg->peak);
 
-- 
2.11.0

[PATCH v3 0/4] AS3645A fixes

[Sakari Ailus]

Hi Jacek and others,

Here are a few fixes for the as3645a DTS as well as changes in bindings.
The driver is not in a release yet.

Jacek: Could you take these to your fixes branch so we don't get faulty DT
bindings to a release? I've dropped the patches related to LED naming and
label property as the discusion appears to continue on that.

Thanks.


since v2:

- Drop patches related to LED naming.

- No other changes.

since v1:

- Add LED colour to the name of the LED, this adds two patches to the set.

- Add a patch to unregister the indicator LED in driver remove function.

- No changes to v1 patches.

Sakari Ailus (4):
  as3645a: Use ams,input-max-microamp as documented in DT bindings
  dt: bindings: as3645a: Use LED number to refer to LEDs
  as3645a: Use integer numbers for parsing LEDs
  as3645a: Unregister indicator LED on device unbind

 .../devicetree/bindings/leds/ams,as3645a.txt   | 28 +
 arch/arm/boot/dts/omap3-n950-n9.dtsi   | 10 +---
 drivers/leds/leds-as3645a.c| 29 +++---
 3 files changed, 51 insertions(+), 16 deletions(-)

-- 
2.11.0

[PATCH v3 2/4] dt: bindings: as3645a: Use LED number to refer to LEDs

[Sakari Ailus]

Use integers (reg property) to tell the number of the LED to the driver
instead of the node name. While both of these approaches are currently
used by the LED bindings, using integers will require less driver changes
for ACPI support. Additionally, it will make possible LED naming using
chip and LED node names, effectively making the label property most useful
for human-readable names only.

Signed-off-by: Sakari Ailus 
Acked-by: Jacek Anaszewski 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/leds/ams,as3645a.txt   | 28 ++
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt 
b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
index 12c5ef26ec73..fdc40e354a64 100644
--- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
+++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
@@ -15,11 +15,14 @@ Required properties
 
 compatible : Must be "ams,as3645a".
 reg: The I2C address of the device. Typically 0x30.
+#address-cells : 1
+#size-cells: 0
 
 
-Required properties of the "flash" child node
-=
+Required properties of the flash child node (0)
+===
 
+reg: 0
 flash-timeout-us: Flash timeout in microseconds. The value must be in
  the range [10, 85] and divisible by 5.
 flash-max-microamp: Maximum flash current in microamperes. Has to be
@@ -33,20 +36,21 @@ ams,input-max-microamp: Maximum flash controller input 
current. The
and divisible by 5.
 
 
-Optional properties of the "flash" child node
-=
+Optional properties of the flash child node
+===
 
 label  : The label of the flash LED.
 
 
-Required properties of the "indicator" child node
-=
+Required properties of the indicator child node (1)
+===
 
+reg: 1
 led-max-microamp: Maximum indicator current. The allowed values are
  2500, 5000, 7500 and 1.
 
-Optional properties of the "indicator" child node
-=
+Optional properties of the indicator child node
+===
 
 label  : The label of the indicator LED.
 
@@ -55,16 +59,20 @@ Example
 ===
 
as3645a@30 {
+   #address-cells: 1
+   #size-cells: 0
reg = <0x30>;
compatible = "ams,as3645a";
-   flash {
+   flash@0 {
+   reg = <0x0>;
flash-timeout-us = <15>;
flash-max-microamp = <32>;
led-max-microamp = <6>;
ams,input-max-microamp = <175>;
label = "as3645a:flash";
};
-   indicator {
+   indicator@1 {
+   reg = <0x1>;
led-max-microamp = <1>;
label = "as3645a:indicator";
};
-- 
2.11.0

[PATCH v3 3/4] as3645a: Use integer numbers for parsing LEDs

[Sakari Ailus]

Use integer numbers for LEDs, 0 is the flash and 1 is the indicator.

Signed-off-by: Sakari Ailus 
Acked-by: Pavel Machek 
Acked-by: Jacek Anaszewski 
---
 arch/arm/boot/dts/omap3-n950-n9.dtsi |  8 ++--
 drivers/leds/leds-as3645a.c  | 26 --
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi 
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index b86fc83a5a65..1b0bd72945f2 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -267,15 +267,19 @@
clock-frequency = <40>;
 
as3645a@30 {
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x30>;
compatible = "ams,as3645a";
-   flash {
+   flash@0 {
+   reg = <0x0>;
flash-timeout-us = <15>;
flash-max-microamp = <32>;
led-max-microamp = <6>;
ams,input-max-microamp = <175>;
};
-   indicator {
+   indicator@1 {
+   reg = <0x1>;
led-max-microamp = <1>;
};
};
diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c
index e3f89c6130d2..605e0c64e974 100644
--- a/drivers/leds/leds-as3645a.c
+++ b/drivers/leds/leds-as3645a.c
@@ -112,6 +112,10 @@
 #define AS_PEAK_mA_TO_REG(a) \
((min_t(u32, AS_PEAK_mA_MAX, a) - 1250) / 250)
 
+/* LED numbers for Devicetree */
+#define AS_LED_FLASH   0
+#define AS_LED_INDICATOR   1
+
 enum as_mode {
AS_MODE_EXT_TORCH = 0 << AS_CONTROL_MODE_SETTING_SHIFT,
AS_MODE_INDICATOR = 1 << AS_CONTROL_MODE_SETTING_SHIFT,
@@ -491,10 +495,29 @@ static int as3645a_parse_node(struct as3645a *flash,
  struct device_node *node)
 {
struct as3645a_config *cfg = >cfg;
+   struct device_node *child;
const char *name;
int rval;
 
-   flash->flash_node = of_get_child_by_name(node, "flash");
+   for_each_child_of_node(node, child) {
+   u32 id = 0;
+
+   of_property_read_u32(child, "reg", );
+
+   switch (id) {
+   case AS_LED_FLASH:
+   flash->flash_node = of_node_get(child);
+   break;
+   case AS_LED_INDICATOR:
+   flash->indicator_node = of_node_get(child);
+   break;
+   default:
+   dev_warn(>client->dev,
+"unknown LED %u encountered, ignoring\n", id);
+   break;
+   }
+   }
+
if (!flash->flash_node) {
dev_err(>client->dev, "can't find flash node\n");
return -ENODEV;
@@ -538,7 +561,6 @@ static int as3645a_parse_node(struct as3645a *flash,
 >peak);
cfg->peak = AS_PEAK_mA_TO_REG(cfg->peak);
 
-   flash->indicator_node = of_get_child_by_name(node, "indicator");
if (!flash->indicator_node) {
dev_warn(>client->dev,
 "can't find indicator node\n");
-- 
2.11.0

[PATCH v3 4/4] as3645a: Unregister indicator LED on device unbind

[Sakari Ailus]

The indicator LED was registered in probe but was not removed in driver
remove callback. Fix this.

Signed-off-by: Sakari Ailus 
---
 drivers/leds/leds-as3645a.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c
index 605e0c64e974..9a257f969300 100644
--- a/drivers/leds/leds-as3645a.c
+++ b/drivers/leds/leds-as3645a.c
@@ -743,6 +743,7 @@ static int as3645a_remove(struct i2c_client *client)
as3645a_set_control(flash, AS_MODE_EXT_TORCH, false);
 
v4l2_flash_release(flash->vf);
+   v4l2_flash_release(flash->vfind);
 
led_classdev_flash_unregister(>fled);
led_classdev_unregister(>iled_cdev);
-- 
2.11.0

[PATCH] [media] atomisp2: remove cast from memory allocation

[Aishwarya Pant]

Patch removes the following warning issued was coccicheck:
WARNING: casting value returned by memory allocation function to (char *) is
useless.

Signed-off-by: Aishwarya Pant 
---
 drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
index 6358216..53a7891 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
@@ -145,8 +145,8 @@ sh_css_load_blob_info(const char *fw, const struct 
ia_css_fw_info *bi, struct ia
size_t configstruct_size = sizeof(struct 
ia_css_config_memory_offsets);
size_t statestruct_size = sizeof(struct 
ia_css_state_memory_offsets);
 
-   char *parambuf = (char *)kmalloc(paramstruct_size + 
configstruct_size + statestruct_size,
-   GFP_KERNEL);
+   char *parambuf = kmalloc(paramstruct_size + configstruct_size + 
statestruct_size,
+GFP_KERNEL);
if (parambuf == NULL)
return IA_CSS_ERR_CANNOT_ALLOCATE_MEMORY;
 
-- 
2.7.4

Re: [PATCH v3 3/4] [media] bcm2835-unicam: Driver for CCP2/CSI2 camera interface

[Hans Verkuil]

Hi Dave,

Thank you for working on this!

See my review below:

On 20/09/17 18:07, Dave Stevenson wrote:
> Add driver for the Unicam camera receiver block on
> BCM283x processors.
> 
> Signed-off-by: Dave Stevenson 
> ---
> 
> Changes from v2.
> - Don't store the irq value as it isn't used outside the probe.
> - Change PIX_FMT_ALL_ defines to avoid potential clashes with 4CCs.
> - Clock now called "lp" and not "lp_clock".
> - Minor description changes.
> 
>  drivers/media/platform/Kconfig   |1 +
>  drivers/media/platform/Makefile  |1 +
>  drivers/media/platform/bcm2835/Kconfig   |   14 +
>  drivers/media/platform/bcm2835/Makefile  |3 +
>  drivers/media/platform/bcm2835/bcm2835-unicam.c  | 2192 
> ++
>  drivers/media/platform/bcm2835/vc4-regs-unicam.h |  264 +++
>  6 files changed, 2475 insertions(+)
>  create mode 100644 drivers/media/platform/bcm2835/Kconfig
>  create mode 100644 drivers/media/platform/bcm2835/Makefile
>  create mode 100644 drivers/media/platform/bcm2835/bcm2835-unicam.c
>  create mode 100644 drivers/media/platform/bcm2835/vc4-regs-unicam.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 7e7cc49..1e5f004 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -150,6 +150,7 @@ source "drivers/media/platform/am437x/Kconfig"
>  source "drivers/media/platform/xilinx/Kconfig"
>  source "drivers/media/platform/rcar-vin/Kconfig"
>  source "drivers/media/platform/atmel/Kconfig"
> +source "drivers/media/platform/bcm2835/Kconfig"
>  
>  config VIDEO_TI_CAL
>   tristate "TI CAL (Camera Adaptation Layer) driver"
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index c1ef946..045de3f 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -90,3 +90,4 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)  += 
> qcom/camss-8x16/
>  obj-$(CONFIG_VIDEO_QCOM_VENUS)   += qcom/venus/
>  
>  obj-y+= meson/
> +obj-y+= bcm2835/
> diff --git a/drivers/media/platform/bcm2835/Kconfig 
> b/drivers/media/platform/bcm2835/Kconfig
> new file mode 100644
> index 000..6a74842
> --- /dev/null
> +++ b/drivers/media/platform/bcm2835/Kconfig
> @@ -0,0 +1,14 @@
> +# Broadcom VideoCore4 V4L2 camera support
> +
> +config VIDEO_BCM2835_UNICAM
> + tristate "Broadcom BCM2835 Unicam video capture driver"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on ARCH_BCM2835 || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_FWNODE
> + ---help---
> +   Say Y here to enable V4L2 subdevice for CSI2 receiver.
> +   This is a V4L2 subdevice that interfaces directly to the VC4 
> peripheral.
> +
> +To compile this driver as a module, choose M here. The module
> +will be called bcm2835-unicam.
> diff --git a/drivers/media/platform/bcm2835/Makefile 
> b/drivers/media/platform/bcm2835/Makefile
> new file mode 100644
> index 000..a98aba0
> --- /dev/null
> +++ b/drivers/media/platform/bcm2835/Makefile
> @@ -0,0 +1,3 @@
> +# Makefile for BCM2835 Unicam driver
> +
> +obj-$(CONFIG_VIDEO_BCM2835_UNICAM) += bcm2835-unicam.o
> diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam.c 
> b/drivers/media/platform/bcm2835/bcm2835-unicam.c
> new file mode 100644
> index 000..93831fb
> --- /dev/null
> +++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c
> @@ -0,0 +1,2192 @@
> +/*
> + * BCM2835 Unicam capture Driver
> + *
> + * Copyright (C) 2017 - Raspberry Pi (Trading) Ltd.
> + *
> + * Dave Stevenson 
> + *
> + * Based on TI am437x driver by Benoit Parrot and Lad, Prabhakar and
> + * TI CAL camera interface driver by Benoit Parrot.
> + *
> + *
> + * There are two camera drivers in the kernel for BCM283x - this one
> + * and bcm2835-camera (currently in staging).
> + *
> + * This driver directly controls the Unicam peripheral - there is no
> + * involvement with the VideoCore firmware. Unicam receives CSI-2 or
> + * CCP2 data and writes it into SDRAM. The only processing options are
> + * to repack Bayer data into an alternate format, and applying windowing
> + * (currently not implemented).
> + * It should be possible to connect it to any sensor with a
> + * suitable output interface and V4L2 subdevice driver.
> + *
> + * bcm2835-camera uses the VideoCore firmware to control the sensor,
> + * Unicam, ISP, and all tuner control loops. Fully processed frames are
> + * delivered to the driver by the firmware. It only has sensor drivers
> + * for Omnivision OV5647, and Sony IMX219 sensors.
> + *
> + * The two drivers are mutually exclusive for the same Unicam instance.
> + * The VideoCore firmware checks the device tree configuration during boot.
> + * If it finds device tree nodes called csi0 or 

Re: [PATCH v2 0/4] BCM283x Camera Receiver driver

[Hans Verkuil]

On 13/09/17 17:49, Dave Stevenson wrote:
> OV5647
> 
> v4l2-compliance SHA   : f6ecbc90656815d91dc6ba90aac0ad8193a14b38
> 
> Driver Info:
> Driver name   : unicam
> Card type : unicam
> Bus info  : platform:unicam 3f801000.csi1
> Driver version: 4.13.0
> Capabilities  : 0x8521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/video0 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> fail: v4l2-test-controls.cpp(587): g_ext_ctrls does not
> support count == 0

Huh. The issue here is that there are no controls at all, but the
control API is present. The class_check() function in v4l2-ctrls.c expects
that there are controls and if not it returns -EINVAL, causing this test
to fail.

Try to apply this patch:

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index dd1db678718c..4e53a8654690 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2818,7 +2818,7 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
 static int class_check(struct v4l2_ctrl_handler *hdl, u32 which)
 {
if (which == 0 || which == V4L2_CTRL_WHICH_DEF_VAL)
-   return list_empty(>ctrl_refs) ? -EINVAL : 0;
+   return 0;
return find_ref_lock(hdl, which | 1) ? 0 : -EINVAL;
 }


and see if it will pass the compliance test. There may be other issues.
I think that the compliance test should handle the case where there are no
controls, so this is a good test.

That said, another solution is that the driver detects that there are no
controls in unicam_probe_complete() and sets unicam->v4l2_dev.ctrl_handler
to NULL.

I think you should do this in v4. Having control ioctls but no actual controls
is not wrong as such, but it is a bit misleading towards the application.

But let's make sure that v4l2-compliance can handle this case first.

Regards,

Hans

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

[Stefan Wahren]

Hi Dave,

> Dave Stevenson  hat am 20. September 2017 um 
> 18:07 geschrieben:
> 
> 
> Document the DT bindings for the CSI2/CCP2 receiver peripheral
> (known as Unicam) on BCM283x SoCs.
> 
> Signed-off-by: Dave Stevenson 
> ---
> 
> Changes since v2
> - Removed all references to Linux drivers.
> - Reworded section about disabling the firmware driver.
> - Renamed clock from "lp_clock" to "lp" in description and example.
> - Referred to video-interfaces.txt and stated requirements on remote-endpoint
>   and data-lanes.
> - Corrected typo in example from csi to csi1.
> - Removed unnecessary #address-cells and #size-cells in example.
> - Removed setting of status from the example.
> 
>  .../devicetree/bindings/media/bcm2835-unicam.txt   | 85 
> ++
>  1 file changed, 85 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt 
> b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
> new file mode 100644
> index 000..7714fb3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
> @@ -0,0 +1,85 @@
> +Broadcom BCM283x Camera Interface (Unicam)
> +--
> +
> +The Unicam block on BCM283x SoCs is the receiver for either
> +CSI-2 or CCP2 data from image sensors or similar devices.
> +
> +The main platform using this SoC is the Raspberry Pi family of boards.
> +On the Pi the VideoCore firmware can also control this hardware block,
> +and driving it from two different processors will cause issues.
> +To avoid this, the firmware checks the device tree configuration
> +during boot. If it finds device tree nodes called csi0 or csi1 then
> +it will stop the firmware accessing the block, and it can then
> +safely be used via the device tree binding.
> +
> +Required properties:
> +===
> +- compatible : must be "brcm,bcm2835-unicam".
> +- reg: physical base address and length of the register sets 
> for the
> +   device.
> +- interrupts : should contain the IRQ line for this Unicam instance.
> +- clocks : list of clock specifiers, corresponding to entries in
> +   clock-names property.
> +- clock-names: must contain an "lp" entry, matching entries in the
> +   clocks property.
> +
> +Unicam supports a single port node. It should contain one 'port' child node
> +with child 'endpoint' node. Please refer to the bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Within the endpoint node the "remote-endpoint" and "data-lanes" properties
> +are mandatory.
> +Data lane reordering is not supported so the data lanes must be in order,
> +starting at 1. The number of data lanes should represent the number of
> +usable lanes for the hardware block. That may be limited by either the SoC or
> +how the platform presents the interface, and the lower value must be used.
> +
> +Lane reordering is not supported on the clock lane either, so the optional
> +property "clock-lane" will implicitly be <0>.
> +Similarly lane inversion is not supported, therefore "lane-polarities" will
> +implicitly be <0 0 0 0 0>.
> +Neither of these values will be checked.
> +
> +Example:
> + csi1: csi1@7e801000 {
> + compatible = "brcm,bcm2835-unicam";
> + reg = <0x7e801000 0x800>,
> +   <0x7e802004 0x4>;

sorry, i didn't noticed this before. I'm afraid this is using a small range of 
the CMI. Are there possible other users of this range? Does it make sense to 
handle this by a separate clock driver?

Regards

Re: usb/media/hdpvr: trying to register non-static key in hdpvr_probe

[Arvind Yadav]

Hi,

I have a doubt. Why we are calling flush_work in hdpvr_probe for every 
failure.

We are flushing work which is not defined yet.

Here, hdpvr_register_videodev() is responsible for setup and register a 
video device.
Also defining and initializing a worker. we are calling 
hdpvr_register_videodev() at last.

No need to flash any work here.

Please correct me, if I am wrong.

On Thursday 21 September 2017 09:09 PM, Andrey Konovalov wrote:

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #215
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
  __dump_stack lib/dump_stack.c:16
  dump_stack+0x292/0x395 lib/dump_stack.c:52
  register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
  __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
  lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
  flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
  hdpvr_probe+0x233/0x20d0 drivers/media/usb/hdpvr/hdpvr-core.c:400
  usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
  really_probe drivers/base/dd.c:413
  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
  device_add+0xd0b/0x1660 drivers/base/core.c:1835
  usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
  really_probe drivers/base/dd.c:413
  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
  device_add+0xd0b/0x1660 drivers/base/core.c:1835
  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
  hub_port_connect drivers/usb/core/hub.c:4903
  hub_port_connect_change drivers/usb/core/hub.c:5009
  port_event drivers/usb/core/hub.c:5115
  hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
  process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
  worker_thread+0x221/0x1850 kernel/workqueue.c:2253
  kthread+0x3a1/0x470 kernel/kthread.c:231
  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
hdpvr: probe of 1-1:8.217 failed with error -12

~arvind

Re: [PATCH 1/2] dt: bindings: media: Document port and endpoint numbering

[Sakari Ailus]

On Thu, Sep 21, 2017 at 10:58:34AM -0500, Rob Herring wrote:
> On Thu, Sep 21, 2017 at 4:25 AM, Sakari Ailus
>  wrote:
> > Hi Rob,
> >
> > Thanks for the reply.
> >
> > On Wed, Sep 20, 2017 at 03:53:13PM -0500, Rob Herring wrote:
> >> On Mon, Sep 18, 2017 at 11:25:04AM +0300, Sakari Ailus wrote:
> >> > A lot of devices do not need and do not document port or endpoint
> >> > numbering at all, e.g. in case where there's just a single port and a
> >> > single endpoint. Whereas this is just common sense, document it to make 
> >> > it
> >> > explicit.
> >> >
> >> > Signed-off-by: Sakari Ailus 
> >> > ---
> >> >  Documentation/devicetree/bindings/media/video-interfaces.txt | 12 
> >> > 
> >> >  1 file changed, 12 insertions(+)
> >>
> >> This is fine, but bindings should still be explicit. Otherwise, I'm
> >> wondering if it's a single port/endpoint or they just forgot to document
> >> it. And I shouldn't have to look at the example to infer that.
> >>
> >> Acked-by: Rob Herring 
> >
> > The purpose of the patch was to actually document port and endpoint
> > numbering for devices for which it is not documented, not to suggest that
> > this would be omitted in in binding documentation. The fact is that I
> > couldn't find documentation for endpoint numbering for a single device
> > under Documentation/devicetree/bindings/media/ . Yet I haven't come across
> > DT source where other than zero would have been used. And the drivers
> > (mostly?) have ignored endpoint numbers so far.
> 
> That's surprising. I know there are some for display controllers and
> it's a common review comment I give.

On V4L2 side we only have started paying attention recently. See e.g.

Documentation/devicetree/bindings/media/atmel-isc.txt
Documentation/devicetree/bindings/media/ti,omap3isp.txt
Documentation/devicetree/bindings/media/qcom,camss.txt

> 
> >
> > Some bindings have been omitted on the grounds that they're documented in
> > video-interfaces.txt.
> >
> > What would you think of the following? I'm not sure it'd really belong
> > there, but it'd be a small piece of documentation one can easily refer to.
> 
> Looks good.

I'll resend the set, replacing the original patch.

> 
> >
> >
> > From e735979005244eb10597fe5333130b93e41d5a38 Mon Sep 17 00:00:00 2001
> > From: Sakari Ailus 
> > Date: Mon, 18 Sep 2017 11:15:53 +0300
> > Subject: [PATCH 1/1] dt: bindings: media: Document practices for DT 
> > bindings,
> >  ports, endpoints
> >
> > Port and endpoint numbering has been omitted in DT binding documentation
> > for a large number of devices. Also common properties the device uses have
> > been missed in binding documentation. Make it explicit that these things
> > need to be documented.
> >
> > Signed-off-by: Sakari Ailus 
> > ---
> >  .../devicetree/bindings/media/video-interfaces.txt| 15 
> > +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
> > b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > index 852041a..3c5382f 100644
> > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > @@ -55,6 +55,21 @@ divided into two separate ITU-R BT.656 8-bit busses.  In 
> > such case bus-width
> >  and data-shift properties can be used to assign physical data lines to each
> >  endpoint node (logical bus).
> >
> > +Documenting bindings for devices
> > +
> > +
> > +All required and optional bindings the device supports shall be explicitly
> > +documented in device DT binding documentation. This also includes port and
> > +endpoint numbering for the device.
> > +
> > +Port and endpoint numbering
> > +---
> > +
> > +Old binding documentation may have omitted explicitly specifying port and
> > +endpoint numbers. This often applies to devices that have a single port 
> > and a
> > +single endpoint in that port. In this case, the only valid port number for 
> > such
> > +a device is zero. The same applies for devices for which bindings do not
> > +document endpoint numbering: only zero is a valid endpoint.
> >
> >  Required properties
> >  ---
> > --
> > 2.7.4
> >
> > --
> > Sakari Ailus
> > sakari.ai...@linux.intel.com

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

[Mylene JOSSERAND]

Hello Yong,

Thank you for these drivers!

I tested it with an OV5640 camera on an Nanopi M1 plus (Allwinner H3)
and I noticed that I got a frame correctly displayed only on a half of
the frame's size.

It is related to your "sun6i_csi_set_window" function (see
below).

> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> and CSI1 is used for parallel interface. This is not documented in
> datasheet but by testing and guess.
> 
> This patch implement a v4l2 framework driver for it.
> 
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
> 
> Signed-off-by: Yong Deng 
> ---
>  drivers/media/platform/Kconfig   |   1 +
>  drivers/media/platform/Makefile  |   2 +
>  drivers/media/platform/sun6i-csi/Kconfig |   9 +
>  drivers/media/platform/sun6i-csi/Makefile|   3 +
>  drivers/media/platform/sun6i-csi/sun6i_csi.c | 545
> +++ drivers/media/platform/sun6i-csi/sun6i_csi.h |
> 203 ++ drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827
> +++
> drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
> drivers/media/platform/sun6i-csi/sun6i_video.c   | 663
> ++ drivers/media/platform/sun6i-csi/sun6i_video.h
> |  61 ++ 10 files changed, 2520 insertions(+) create mode 100644
> drivers/media/platform/sun6i-csi/Kconfig create mode 100644
> drivers/media/platform/sun6i-csi/Makefile create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi.c create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi.h create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_video.c create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_video.h
> 
> diff --git a/drivers/media/platform/Kconfig
> b/drivers/media/platform/Kconfig index 0c741d1..8371a87 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
>  source "drivers/media/platform/xilinx/Kconfig"
>  source "drivers/media/platform/rcar-vin/Kconfig"
>  source "drivers/media/platform/atmel/Kconfig"
> +source "drivers/media/platform/sun6i-csi/Kconfig"
>  



> +static void sun6i_csi_set_format(struct sun6i_csi_dev *sdev)
> +{
> + struct sun6i_csi *csi = >csi;
> + u32 cfg;
> + u32 val;
> +
> + regmap_read(sdev->regmap, CSI_CH_CFG_REG, );
> +
> + cfg &= ~(CSI_CH_CFG_INPUT_FMT_MASK |
> +  CSI_CH_CFG_OUTPUT_FMT_MASK | CSI_CH_CFG_VFLIP_EN |
> +  CSI_CH_CFG_HFLIP_EN | CSI_CH_CFG_FIELD_SEL_MASK |
> +  CSI_CH_CFG_INPUT_SEQ_MASK);
> +
> + val = get_csi_input_format(csi->config.code,
> csi->config.pixelformat);
> + cfg |= CSI_CH_CFG_INPUT_FMT(val);
> +
> + val = get_csi_output_format(csi->config.code,
> csi->config.field);
> + cfg |= CSI_CH_CFG_OUTPUT_FMT(val);
> +
> + val = get_csi_input_seq(csi->config.code,
> csi->config.pixelformat);
> + cfg |= CSI_CH_CFG_INPUT_SEQ(val);
> +
> + if (csi->config.field == V4L2_FIELD_TOP)
> + cfg |= CSI_CH_CFG_FIELD_SEL_FIELD0;
> + else if (csi->config.field == V4L2_FIELD_BOTTOM)
> + cfg |= CSI_CH_CFG_FIELD_SEL_FIELD1;
> + else
> + cfg |= CSI_CH_CFG_FIELD_SEL_BOTH;
> +
> + regmap_write(sdev->regmap, CSI_CH_CFG_REG, cfg);
> +}
> +
> +static void sun6i_csi_set_window(struct sun6i_csi_dev *sdev)
> +{
> + struct sun6i_csi_config *config = >csi.config;
> + u32 bytesperline_y;
> + u32 bytesperline_c;
> + int *planar_offset = sdev->planar_offset;
> +
> + regmap_write(sdev->regmap, CSI_CH_HSIZE_REG,
> +  CSI_CH_HSIZE_HOR_LEN(config->width) |
> +  CSI_CH_HSIZE_HOR_START(0));
> + regmap_write(sdev->regmap, CSI_CH_VSIZE_REG,
> +  CSI_CH_VSIZE_VER_LEN(config->height) |
> +  CSI_CH_VSIZE_VER_START(0));

In my case, the HOR_LEN and VER_LEN were not correctly configured.

They were configured to width and height (640 * 480) but as I was
using a YUYV format, the pixel's size is 2 bytes so the
horizontal/vertical lines' lengths were divided by 2.

Currently, I fixed that by getting the number of bytes per pixel with
"v4l2_pixformat_get_bpp()":

+   int bytes_pixel;
+
+   bytes_pixel = v4l2_pixformat_get_bpp(config->pixelformat) / 8;
 
regmap_write(sdev->regmap, CSI_CH_HSIZE_REG,
-CSI_CH_HSIZE_HOR_LEN(config->width) |
+CSI_CH_HSIZE_HOR_LEN(config->width * bytes_pixel) |
 CSI_CH_HSIZE_HOR_START(0));
regmap_write(sdev->regmap, CSI_CH_VSIZE_REG,
-CSI_CH_VSIZE_VER_LEN(config->height) |
+CSI_CH_VSIZE_VER_LEN(config->height * bytes_pixel)
  | CSI_CH_VSIZE_VER_START(0));

Re: [PATCH] [media] tc358743: validate lane count and order

[Sakari Ailus]

Hi Philipp,

On Thu, Sep 21, 2017 at 05:31:39PM +0200, Philipp Zabel wrote:
> The TC358743 does not support reordering lanes, or more than 4 data
> lanes.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/media/i2c/tc358743.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
> index a35043cefe128..b7285e45b908a 100644
> --- a/drivers/media/i2c/tc358743.c
> +++ b/drivers/media/i2c/tc358743.c
> @@ -1743,6 +1743,7 @@ static int tc358743_probe_of(struct tc358743_state 
> *state)
>   struct clk *refclk;
>   u32 bps_pr_lane;
>   int ret = -EINVAL;
> + int i;
>  
>   refclk = devm_clk_get(dev, "refclk");
>   if (IS_ERR(refclk)) {
> @@ -1771,6 +1772,21 @@ static int tc358743_probe_of(struct tc358743_state 
> *state)
>   goto free_endpoint;
>   }
>  
> + if (endpoint->bus.mipi_csi2.num_data_lanes > 4) {
> + dev_err(dev, "invalid number of lanes\n");
> + goto free_endpoint;
> + }
> +
> + for (i = 0; i < endpoint->bus.mipi_csi2.num_data_lanes; i++) {
> + if (endpoint->bus.mipi_csi2.data_lanes[i] != i + 1)
> + break;
> + }

No other drivers perform such checks and if the hardware just doesn't
support it, then I'd just care about the number.

Checking that there are no more lanes configured than the hardware supports
makes definitely sense.

> + if (i != endpoint->bus.mipi_csi2.num_data_lanes ||
> + endpoint->bus.mipi_csi2.clock_lane != 0) {
> + dev_err(dev, "invalid lane order\n");
> + goto free_endpoint;
> + }
> +
>   state->bus = endpoint->bus.mipi_csi2;
>  
>   ret = clk_prepare_enable(refclk);

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

[PATCH v2 1/1] ov13858: Use do_div() for dividing a 64-bit number

[Sakari Ailus]

ov13858 contained a 64-bit division. Use do_div() for calculating it.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/ov13858.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
index 2bd659976c30..fdce2befed02 100644
--- a/drivers/media/i2c/ov13858.c
+++ b/drivers/media/i2c/ov13858.c
@@ -951,7 +951,13 @@ static const char * const ov13858_test_pattern_menu[] = {
  * pixel_rate = link_freq * data-rate * nr_of_lanes / bits_per_sample
  * data rate => double data rate; number of lanes => 4; bits per pixel => 10
  */
-#define LINK_FREQ_TO_PIXEL_RATE(f) (((f) * 2 * 4) / 10)
+static u64 link_freq_to_pixel_rate(u64 f)
+{
+   f *= 2 * 4;
+   do_div(f, 10);
+
+   return f;
+}
 
 /* Menu items for LINK_FREQ V4L2 control */
 static const s64 link_freq_menu_items[OV13858_NUM_OF_LINK_FREQS] = {
@@ -1404,7 +1410,7 @@ ov13858_set_pad_format(struct v4l2_subdev *sd,
ov13858->cur_mode = mode;
__v4l2_ctrl_s_ctrl(ov13858->link_freq, mode->link_freq_index);
link_freq = link_freq_menu_items[mode->link_freq_index];
-   pixel_rate = LINK_FREQ_TO_PIXEL_RATE(link_freq);
+   pixel_rate = link_freq_to_pixel_rate(link_freq);
__v4l2_ctrl_s_ctrl_int64(ov13858->pixel_rate, pixel_rate);
 
/* Update limits and set FPS to default */
@@ -1642,8 +1648,8 @@ static int ov13858_init_controls(struct ov13858 *ov13858)
link_freq_menu_items);
ov13858->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
 
-   pixel_rate_max = LINK_FREQ_TO_PIXEL_RATE(link_freq_menu_items[0]);
-   pixel_rate_min = LINK_FREQ_TO_PIXEL_RATE(link_freq_menu_items[1]);
+   pixel_rate_max = link_freq_to_pixel_rate(link_freq_menu_items[0]);
+   pixel_rate_min = link_freq_to_pixel_rate(link_freq_menu_items[1]);
/* By default, PIXEL_RATE is read only */
ov13858->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops,
V4L2_CID_PIXEL_RATE,
-- 
2.11.0

[PATCH v2 2/2] dt: bindings: media: Document data lane numbering without lane reordering

[Sakari Ailus]

Most devices do not support lane reordering and in many cases the
documentation of the data-lanes property is incomplete for such devices.
Document that in case the lane reordering isn't supported, monotonically
incremented values from 0 or 1 shall be used.

Signed-off-by: Sakari Ailus 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/media/video-interfaces.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 3c5382f..4b09a34 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -114,7 +114,10 @@ Optional endpoint properties
   determines the logical lane number, while the value of an entry indicates
   physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have
   "data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0.
-  This property is valid for serial busses only (e.g. MIPI CSI-2).
+  If the hardware does not support lane reordering, monotonically
+  incremented values shall be used from 0 or 1 onwards, depending on
+  whether or not there is also a clock lane. This property is valid for
+  serial busses only (e.g. MIPI CSI-2).
 - clock-lanes: an array of physical clock lane indexes. Position of an entry
   determines the logical lane number, while the value of an entry indicates
   physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
-- 
2.7.4

[PATCH v2 0/2] Improve generic DT binding documentation for media devices

[Sakari Ailus]

Hi folks,

This set improves the DT binding documentation for media devices where
device specific documentation is lacking and also documents that explicit
documentation of all properties supported by the device is required.

- Port and endpoint numbering
- lane numbering for the data-lanes property

Sakari Ailus (2):
  dt: bindings: media: Document practices for DT bindings, ports,
endpoints
  dt: bindings: media: Document data lane numbering without lane
reordering

 .../devicetree/bindings/media/video-interfaces.txt   | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

-- 
2.7.4

[PATCH v2 1/2] dt: bindings: media: Document practices for DT bindings, ports, endpoints

[Sakari Ailus]

Port and endpoint numbering has been omitted in DT binding documentation
for a large number of devices. Also common properties the device uses have
been missed in binding documentation. Make it explicit that these things
need to be documented.

Signed-off-by: Sakari Ailus 
---
 .../devicetree/bindings/media/video-interfaces.txt| 15 +++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 852041a..3c5382f 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -55,6 +55,21 @@ divided into two separate ITU-R BT.656 8-bit busses.  In 
such case bus-width
 and data-shift properties can be used to assign physical data lines to each
 endpoint node (logical bus).
 
+Documenting bindings for devices
+
+
+All required and optional bindings the device supports shall be explicitly
+documented in device DT binding documentation. This also includes port and
+endpoint numbering for the device.
+
+Port and endpoint numbering
+---
+
+Old binding documentation may have omitted explicitly specifying port and
+endpoint numbers. This often applies to devices that have a single port and a
+single endpoint in that port. In this case, the only valid port number for such
+a device is zero. The same applies for devices for which bindings do not
+document endpoint numbering: only zero is a valid endpoint.
 
 Required properties
 ---
-- 
2.7.4

Re: [PATCH 00/11] drm/sun4i: add CEC support

[Maxime Ripard]

On Thu, Sep 21, 2017 at 09:19:43PM +, Hans Verkuil wrote:
> On 21/09/17 22:37, Maxime Ripard wrote:
> > Hi Hans,
> > 
> > On Fri, Sep 08, 2017 at 10:59:44AM +, Hans Verkuil wrote:
> >> Hi Maxime,
> >>
> >> On 07/18/17 18:29, Maxime Ripard wrote:
> >>> Hi,
> >>>
> >>> On Tue, Jul 11, 2017 at 11:06:52PM +0200, Hans Verkuil wrote:
>  On 11/07/17 22:39, Maxime Ripard wrote:
> > On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> This patch series adds CEC support for the sun4i HDMI controller.
> >>
> >> The CEC hardware support for the A10 is very low-level as it just
> >> controls the CEC pin. Since I also wanted to support GPIO-based CEC
> >> hardware most of this patch series is in the CEC framework to
> >> add a generic low-level CEC pin framework. It is only the final patch
> >> that adds the sun4i support.
> >>
> >> This patch series first makes some small changes in the CEC framework
> >> (patches 1-4) to prepare for this CEC pin support.
> >>
> >> Patch 5-7 adds the new API elements and documents it. Patch 6 reworks
> >> the CEC core event handling.
> >>
> >> Patch 8 adds pin monitoring support (allows userspace to see all
> >> CEC pin transitions as they happen).
> >>
> >> Patch 9 adds the core cec-pin implementation that translates low-level
> >> pin transitions into valid CEC messages. Basically this does what any
> >> SoC with a proper CEC hardware implementation does.
> >>
> >> Patch 10 documents the cec-pin kAPI (and also the cec-notifier kAPI
> >> which was missing).
> >>
> >> Finally patch 11 adds the actual sun4i_hdmi CEC implementation.
> >>
> >> I tested this on my cubieboard. There were no errors at all
> >> after 126264 calls of 'cec-ctl --give-device-vendor-id' while at the
> >> same time running a 'make -j4' of the v4l-utils git repository and
> >> doing a continuous scp to create network traffic.
> >>
> >> This patch series is based on top of the mainline kernel as of
> >> yesterday (so with all the sun4i and cec patches for 4.13 merged).
> >
> > For the whole serie:
> > Reviewed-by: Maxime Ripard 
> >
> >> Maxime, patches 1-10 will go through the media subsystem. How do you
> >> want to handle the final patch? It can either go through the media
> >> subsystem as well, or you can sit on it and handle this yourself during
> >> the 4.14 merge window. Another option is to separate the Kconfig change
> >> into its own patch. That way you can merge the code changes and only
> >> have to handle the Kconfig patch as a final change during the merge
> >> window.
> >
> > We'll probably have a number of reworks for 4.14, so it would be
> > better if I merged it.
> >
> > However, I guess if we just switch to a depends on CEC_PIN instead of
> > a select, everything would just work even if we merge your patches in
> > a separate tree, right?
> 
>  This small patch will do it:
> 
>  diff --git a/drivers/gpu/drm/sun4i/Kconfig 
>  b/drivers/gpu/drm/sun4i/Kconfig
>  index e884d265c0b3..ebad80aefc87 100644
>  --- a/drivers/gpu/drm/sun4i/Kconfig
>  +++ b/drivers/gpu/drm/sun4i/Kconfig
>  @@ -25,7 +25,7 @@ config DRM_SUN4I_HDMI_CEC
>  bool "Allwinner A10 HDMI CEC Support"
>  depends on DRM_SUN4I_HDMI
>  select CEC_CORE
>  -   select CEC_PIN
>  +   depends on CEC_PIN
>  help
> Choose this option if you have an Allwinner SoC with an HDMI
> controller and want to use CEC.
> >>
> >> Just a reminder: now that both this driver and the CEC_PIN code has been
> >> merged in 4.14, this 'depends on' can become a 'select' again.
> > 
> > Thanks for the reminder.
> > 
> > Would that commit work for you:
> > http://code.bulix.org/19o9y6-201254
> 
> Acked-by: Hans Verkuil 
> 
> This obviously should be merged for 4.14.

Yep. I just did, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Sat Sep 23 05:00:15 CEST 2017
media-tree git hash:1efdf1776e2253b77413c997bed862410e4b6aaf
media_build git hash:   19087750b61fc0c5528e798c47ff845f9234
v4l-utils git hash: 9ee29df352dad950784f0f6f4a1bb96c0aefacc4
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.12.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-4.13-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: OK
apps: OK
spec-git: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: usb/media/hdpvr: trying to register non-static key in hdpvr_probe

[Andrey Konovalov]

On Fri, Sep 22, 2017 at 9:41 AM, Arvind Yadav  wrote:
> Hi,
>
> I have a doubt. Why we are calling flush_work in hdpvr_probe for every
> failure.
> We are flushing work which is not defined yet.
>
> Here, hdpvr_register_videodev() is responsible for setup and register a
> video device.
> Also defining and initializing a worker. we are calling
> hdpvr_register_videodev() at last.
> No need to flash any work here.
>
> Please correct me, if I am wrong.

Hi Arvind,

I believe you're right, no need to call flush_work() before
dev->worker is initialized.

Could you send a fix?

I'm able to reproduce the issue, so I can test your patches if needed.

Thanks!

>
>
> On Thursday 21 September 2017 09:09 PM, Andrey Konovalov wrote:
>>
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>>
>> INFO: trying to register non-static key.
>> the code is fine but needs lockdep annotation.
>> turning off the locking correctness validator.
>> CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted
>> 4.14.0-rc1-42251-gebb2c2437d80 #215
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
>> 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> Call Trace:
>>   __dump_stack lib/dump_stack.c:16
>>   dump_stack+0x292/0x395 lib/dump_stack.c:52
>>   register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
>>   __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
>>   lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
>>   flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
>>   hdpvr_probe+0x233/0x20d0 drivers/media/usb/hdpvr/hdpvr-core.c:400
>>   usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>>   really_probe drivers/base/dd.c:413
>>   driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>>   __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>>   bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>>   __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>>   device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>>   bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>>   device_add+0xd0b/0x1660 drivers/base/core.c:1835
>>   usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
>>   generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>>   usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>>   really_probe drivers/base/dd.c:413
>>   driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>>   __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>>   bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>>   __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>>   device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>>   bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>>   device_add+0xd0b/0x1660 drivers/base/core.c:1835
>>   usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
>>   hub_port_connect drivers/usb/core/hub.c:4903
>>   hub_port_connect_change drivers/usb/core/hub.c:5009
>>   port_event drivers/usb/core/hub.c:5115
>>   hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
>>   process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
>>   worker_thread+0x221/0x1850 kernel/workqueue.c:2253
>>   kthread+0x3a1/0x470 kernel/kthread.c:231
>>   ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>> hdpvr: probe of 1-1:8.217 failed with error -12
>
> ~arvind

Re: [PATCH 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings

[Sakari Ailus]

On Fri, Sep 22, 2017 at 01:47:02PM +0200, Maxime Ripard wrote:
> The Cadence MIPI-CSI2 RX controller is a CSI2 bridge that supports up to 4

Should this be TX?

I was just thinking what does this chip do, and saw both. RX it at least
less common. :-)

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

[PATCH] videobuf2-core: add queue_busy/idle queue ops

[Hans Verkuil]

Some controls (ROTATE) change the buffer layout. This means that they cannot
be set when buffers are allocated. This can be achieved by calling
v4l2_ctrl_grab(ctrl, true) when the queue becomes busy (i.e. the first buffer
is allocated) and v4l2_ctrl_grab(ctrl, false) when the queue becomes idle (i.e.
the last buffer is released).

However, we do not have such queue ops at the moment. This patch adds a 
queue_busy
and a queue_idle op.

Note that currently queue_busy returns a void, so it assumes that it can't 
return
an error.

Signed-off-by: Hans Verkuil 
---
Jacob, this has only been compile-tested. It's best if you add this patch to 
your
rockchip-rga patch series and test it there.
---
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 14f83cecfa92..e8ad0e9f78d2 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -665,6 +665,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory 
memory,
}

if (*count == 0 || q->num_buffers != 0 || q->memory != memory) {
+   num_buffers = q->num_buffers;
/*
 * We already have buffers allocated, so first check if they
 * are not in use and can be freed.
@@ -686,6 +687,8 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory 
memory,
mutex_unlock(>mmap_lock);
if (ret)
return ret;
+   if (num_buffers)
+   call_void_qop(q, queue_idle, q);

/*
 * In case of REQBUFS(0) return immediately without calling
@@ -752,6 +755,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory 
memory,
 */
}

+   call_void_qop(q, queue_busy, q);
mutex_lock(>mmap_lock);
q->num_buffers = allocated_buffers;

@@ -762,6 +766,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory 
memory,
 */
__vb2_queue_free(q, allocated_buffers);
mutex_unlock(>mmap_lock);
+   call_void_qop(q, queue_idle, q);
return ret;
}
mutex_unlock(>mmap_lock);
@@ -842,6 +847,8 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
vb2_memory memory,
 */
}

+   if (!q->num_buffers)
+   call_void_qop(q, queue_busy, q);
mutex_lock(>mmap_lock);
q->num_buffers += allocated_buffers;

@@ -852,6 +859,8 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
vb2_memory memory,
 */
__vb2_queue_free(q, allocated_buffers);
mutex_unlock(>mmap_lock);
+   if (!q->num_buffers)
+   call_void_qop(q, queue_idle, q);
return -ENOMEM;
}
mutex_unlock(>mmap_lock);
@@ -2011,11 +2020,15 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
read);
 static int __vb2_cleanup_fileio(struct vb2_queue *q);
 void vb2_core_queue_release(struct vb2_queue *q)
 {
+   bool was_busy = vb2_is_busy(q);
+
__vb2_cleanup_fileio(q);
__vb2_queue_cancel(q);
mutex_lock(>mmap_lock);
__vb2_queue_free(q, q->num_buffers);
mutex_unlock(>mmap_lock);
+   if (was_busy)
+   call_void_qop(q, queue_idle, q);
 }
 EXPORT_SYMBOL_GPL(vb2_core_queue_release);

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index cb97c224be73..3aa039fd29ce 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -315,6 +315,10 @@ struct vb2_buffer {
  * \*num_buffers are being allocated additionally to
  * q->num_buffers. If either \*num_planes or the requested
  * sizes are invalid callback must return %-EINVAL.
+ * @queue_busy:called when the queue becomes busy (i.e. at 
least one
+ * buffer has been allocated).
+ * @queue_idle:called when the last buffer from the queue is 
released
+ * and the queue is no longer marked busy.
  * @wait_prepare:  release any locks taken while calling vb2 functions;
  * it is called before an ioctl needs to wait for a new
  * buffer to arrive; required to avoid a deadlock in
@@ -380,6 +384,8 @@ struct vb2_ops {
int (*queue_setup)(struct vb2_queue *q,
   unsigned int *num_buffers, unsigned int *num_planes,
   unsigned int sizes[], struct device *alloc_devs[]);
+   void (*queue_busy)(struct vb2_queue *q);
+   void (*queue_idle)(struct vb2_queue *q);

void (*wait_prepare)(struct vb2_queue *q);
void (*wait_finish)(struct vb2_queue *q);
@@ -547,6 +553,8 @@ struct vb2_queue {
 * called. Used to check for unbalanced ops.
 */
u32  

usb/media/zr364xx: GPF in zr364xx_vidioc_querycap/strlcpy

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 225 has an invalid interface number: 1 but max is 0
usb 1-1: config 225 has no interface number 0
usb 1-1: config 225 interface 1 altsetting 0 endpoint 0x5 has invalid
maxpacket 2047, setting to 64
usb 1-1: config 225 interface 1 altsetting 0 has an invalid endpoint
with address 0xF5, skipping
usb 1-1: config 225 interface 1 altsetting 0 endpoint 0x8A has invalid
maxpacket 2047, setting to 64
usb 1-1: config 225 interface 1 altsetting 0 endpoint 0x81 has an
invalid bInterval 0, changing to 10
usb 1-1: config 225 interface 1 altsetting 0 endpoint 0x81 has invalid
maxpacket 1025, setting to 64
usb 1-1: config 225 interface 1 altsetting 0 has an invalid endpoint
with address 0xF7, skipping
usb 1-1: config 225 interface 1 altsetting 0 has an invalid endpoint
with address 0xB8, skipping
usb 1-1: New USB device found, idVendor=041e, idProduct=4024
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
usb 1-1: SerialNumber: a
gadgetfs: configuration #225
zr364xx 1-1:225.1: Zoran 364xx compatible webcam plugged
zr364xx 1-1:225.1: model 041e:4024 detected
usb 1-1: 320x240 mode selected
usb 1-1: Zoran 364xx controlling device video0
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 4306 Comm: v4l_id Not tainted 4.14.0-rc1-42261-ga67ef73a6f27 #225
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006a27e300 task.stack: 880067f7
RIP: 0010:strlcpy+0x21/0x120 lib/string.c:140
RSP: 0018:880067f777a0 EFLAGS: 00010286
RAX: dc00 RBX: 880067f77c00 RCX: 
RDX: 0020 RSI:  RDI: 880067f77c10
RBP: 880067f777c8 R08: ed000cfeef82 R09: ed000cfeef82
R10: 0002 R11: ed000cfeef81 R12: 880067f77c10
R13: 880063034400 R14: 8000 R15: 880063193180
FS:  7f5561fe8700() GS:88006c80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f5561b16110 CR3: 6b00c000 CR4: 06f0
Call Trace:
 zr364xx_vidioc_querycap+0xb8/0x220 drivers/media/usb/zr364xx/zr364xx.c:709
 v4l_querycap+0x134/0x370 drivers/media/v4l2-core/v4l2-ioctl.c:1008
 __video_do_ioctl+0x9c6/0xa80 drivers/media/v4l2-core/v4l2-ioctl.c:2750
 video_usercopy+0x4ea/0x1580 drivers/media/v4l2-core/v4l2-ioctl.c:2926
 video_ioctl2+0x31/0x40 drivers/media/v4l2-core/v4l2-ioctl.c:2968
 v4l2_ioctl+0x1c5/0x310 drivers/media/v4l2-core/v4l2-dev.c:360
 vfs_ioctl fs/ioctl.c:45
 do_vfs_ioctl+0x1c4/0x15c0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700
 SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x23/0xc2 arch/x86/entry/entry_64.S:202
RIP: 0033:0x7f5561b1b347
RSP: 002b:7ffd403d19a8 EFLAGS: 0202 ORIG_RAX: 0010
RAX: ffda RBX: 7ffd403d1b00 RCX: 7f5561b1b347
RDX: 7ffd403d19b0 RSI: 80685600 RDI: 0003
RBP: 00400884 R08:  R09: 
R10:  R11: 0202 R12: 0003
R13: 7ffd403d1b00 R14:  R15: 
Code: 8b 45 f0 e9 64 ff ff ff 66 90 48 b8 00 00 00 00 00 fc ff df 55
48 89 f1 48 89 e5 48 c1 e9 03 41 55 41 54 49 89 fc 53 48 83 ec 10 <0f>
b6 04 01 48 89 f1 83 e1 07 38 c8 7f 08 84 c0 0f 85 9d 00 00
RIP: strlcpy+0x21/0x120 RSP: 880067f777a0
---[ end trace 23c9876972269088 ]---

usb/media/stkwebcam: use-after-free in v4l2_ctrl_handler_free

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

==
BUG: KASAN: use-after-free in v4l2_ctrl_handler_free+0x9e1/0x9f0
Read of size 8 at addr 88006a189278 by task kworker/0:1/24

CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #224
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x22f/0x340 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 v4l2_ctrl_handler_free+0x9e1/0x9f0 drivers/media/v4l2-core/v4l2-ctrls.c:1765
 stk_camera_disconnect+0xf5/0x160 drivers/media/usb/stkwebcam/stk-webcam.c:1392
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 drivers/base/core.c:1985
 usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
 usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
 hub_port_connect drivers/usb/core/hub.c:4754
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 1844:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
 kmalloc ./include/linux/slab.h:493
 kzalloc ./include/linux/slab.h:666
 stk_camera_probe+0xcf/0xdd0 drivers/media/usb/stkwebcam/stk-webcam.c:1287
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 stk_v4l_dev_release+0xab/0xe0 drivers/media/usb/stkwebcam/stk-webcam.c:1244
 v4l2_device_release+0x2dc/0x390 drivers/media/v4l2-core/v4l2-dev.c:218
 device_release+0x13f/0x210 drivers/base/core.c:814
 kobject_cleanup lib/kobject.c:648
 kobject_release lib/kobject.c:677
 kref_put ./include/linux/kref.h:70
 kobject_put+0x145/0x240 lib/kobject.c:694
 put_device drivers/base/core.c:1931
 device_unregister+0x2d/0x40 drivers/base/core.c:2021
 video_unregister_device+0x80/0x90 drivers/media/v4l2-core/v4l2-dev.c:1028
 stk_camera_disconnect+0xe9/0x160 drivers/media/usb/stkwebcam/stk-webcam.c:1391
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 

usb/media/dib0700: BUG in stk7070p_frontend_attach/symbol_put_addr

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

dib0700: stk7070p_frontend_attach: state->dib7000p_ops.i2c_enumeration
failed.  Cannot continue
[ cut here ]
kernel BUG at kernel/module.c:1081!
invalid opcode:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 1 PID: 1151 Comm: kworker/1:1 Tainted: GW
4.14.0-rc1-42251-gebb2c2437d80 #224
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006a336300 task.stack: 88006a7c8000
RIP: 0010:symbol_put_addr+0x54/0x60 kernel/module.c:1083
RSP: 0018:88006a7ce210 EFLAGS: 00010246
RAX:  RBX: 880062a8d190 RCX: 
RDX: dc20 RSI: 85876d60 RDI: 880062a8d190
RBP: 88006a7ce218 R08: 11000d4f9c12 R09: 11000d4f9ae4
R10: 11000d4f9bed R11:  R12: 880062a8d180
R13: ffed R14: 880062a8d190 R15: 88006947c000
FS:  () GS:88006c90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f6416532000 CR3: 632f5000 CR4: 06e0
Call Trace:
 stk7070p_frontend_attach+0x515/0x610
drivers/media/usb/dvb-usb/dib0700_devices.c:1013
 dvb_usb_adapter_frontend_init+0x32b/0x660
drivers/media/usb/dvb-usb/dvb-usb-dvb.c:286
 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86
 dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:162
 dvb_usb_device_init+0xf70/0x17f0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277
 dib0700_probe+0x171/0x5a0 drivers/media/usb/dvb-usb/dib0700_core.c:886
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: ff ff 48 85 c0 74 24 48 89 c7 e8 48 ea ff ff bf 01 00 00 00 e8
de 20 e3 ff 65 8b 05 b7 2f c2 7e 85 c0 75 c9 e8 f9 0b c1 ff eb c2 <0f>
0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 b8 00 00
RIP: symbol_put_addr+0x54/0x60 RSP: 88006a7ce210
---[ end trace b75b357739e7e116 ]---

[PATCH] [media] hdpvr: Fix an error handling path in hdpvr_probe()

[Arvind Yadav]

Here, hdpvr_register_videodev() is responsible for setup and
register a video device. Also defining and initializing a worker.
hdpvr_register_videodev() is calling by hdpvr_probe at last.
So No need to flash any work here.
Unregister v4l2, free buffers and memory. If hdpvr_probe() will fail.

Signed-off-by: Arvind Yadav 
---
 drivers/media/usb/hdpvr/hdpvr-core.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/media/usb/hdpvr/hdpvr-core.c 
b/drivers/media/usb/hdpvr/hdpvr-core.c
index dbe29c6..1e8cbaf 100644
--- a/drivers/media/usb/hdpvr/hdpvr-core.c
+++ b/drivers/media/usb/hdpvr/hdpvr-core.c
@@ -292,7 +292,7 @@ static int hdpvr_probe(struct usb_interface *interface,
/* register v4l2_device early so it can be used for printks */
if (v4l2_device_register(>dev, >v4l2_dev)) {
dev_err(>dev, "v4l2_device_register failed\n");
-   goto error;
+   goto error_free_dev;
}
 
mutex_init(>io_mutex);
@@ -301,7 +301,7 @@ static int hdpvr_probe(struct usb_interface *interface,
dev->usbc_buf = kmalloc(64, GFP_KERNEL);
if (!dev->usbc_buf) {
v4l2_err(>v4l2_dev, "Out of memory\n");
-   goto error;
+   goto error_v4l2_unregister;
}
 
init_waitqueue_head(>wait_buffer);
@@ -339,13 +339,13 @@ static int hdpvr_probe(struct usb_interface *interface,
}
if (!dev->bulk_in_endpointAddr) {
v4l2_err(>v4l2_dev, "Could not find bulk-in endpoint\n");
-   goto error;
+   goto error_put_usb;
}
 
/* init the device */
if (hdpvr_device_init(dev)) {
v4l2_err(>v4l2_dev, "device init failed\n");
-   goto error;
+   goto error_put_usb;
}
 
mutex_lock(>io_mutex);
@@ -353,7 +353,7 @@ static int hdpvr_probe(struct usb_interface *interface,
mutex_unlock(>io_mutex);
v4l2_err(>v4l2_dev,
 "allocating transfer buffers failed\n");
-   goto error;
+   goto error_put_usb;
}
mutex_unlock(>io_mutex);
 
@@ -361,7 +361,7 @@ static int hdpvr_probe(struct usb_interface *interface,
retval = hdpvr_register_i2c_adapter(dev);
if (retval < 0) {
v4l2_err(>v4l2_dev, "i2c adapter register failed\n");
-   goto error;
+   goto error_free_buffers;
}
 
client = hdpvr_register_ir_rx_i2c(dev);
@@ -394,13 +394,17 @@ static int hdpvr_probe(struct usb_interface *interface,
 reg_fail:
 #if IS_ENABLED(CONFIG_I2C)
i2c_del_adapter(>i2c_adapter);
+error_free_buffers:
 #endif
+   hdpvr_free_buffers(dev);
+error_put_usb:
+   usb_put_dev(dev->udev);
+   kfree(dev->usbc_buf);
+error_v4l2_unregister:
+   v4l2_device_unregister(>v4l2_dev);
+error_free_dev:
+   kfree(dev);
 error:
-   if (dev) {
-   flush_work(>worker);
-   /* this frees allocated memory */
-   hdpvr_delete(dev);
-   }
return retval;
 }
 
-- 
1.9.1

[PATCH 2/2] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

[Maxime Ripard]

The Cadence MIPI-CSI2 TX controller is an hardware block meant to be used
as a bridge between pixel interfaces and a CSI-2 bus.

It supports operating with an internal or external D-PHY, with up to 4
lanes, or without any D-PHY. The current code only supports the former
case.

While the virtual channel input on the pixel interface can be directly
mapped to CSI2, the datatype input is actually a selection signal (3-bits)
mapping to a table of up to 8 preconfigured datatypes/formats (programmed
at start-up)

The block supports up to 8 input datatypes.

Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/cadence/Kconfig   |   6 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c | 479 +++
 3 files changed, 486 insertions(+)
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
index d1b6bbb6a0eb..db49328ee8b2 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -9,4 +9,10 @@ config VIDEO_CADENCE_CSI2RX
depends on VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
 
+config VIDEO_CADENCE_CSI2TX
+   tristate "Cadence MIPI-CSI2 TX Controller"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+
 endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
index 99a4086b7448..7fe992273162 100644
--- a/drivers/media/platform/cadence/Makefile
+++ b/drivers/media/platform/cadence/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
+obj-$(CONFIG_VIDEO_CADENCE_CSI2TX) += cdns-csi2tx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2tx.c 
b/drivers/media/platform/cadence/cdns-csi2tx.c
new file mode 100644
index ..859bbce8772b
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2tx.c
@@ -0,0 +1,479 @@
+/*
+ * Driver for Cadence MIPI-CSI2 TX Controller
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2TX_DEVICE_CONFIG_REG   0x00
+
+#define CSI2TX_CONFIG_REG  0x20
+#define CSI2TX_CONFIG_CFG_REQ  BIT(2)
+#define CSI2TX_CONFIG_SRST_REQ BIT(1)
+
+#define CSI2TX_DPHY_CFG_REG0x28
+#define CSI2TX_DPHY_CFG_CLK_RESET  BIT(16)
+#define CSI2TX_DPHY_CFG_LANE_RESET(n)  BIT((n) + 12)
+#define CSI2TX_DPHY_CFG_MODE_MASK  GENMASK(9, 8)
+#define CSI2TX_DPHY_CFG_MODE_LPDT  (2 << 8)
+#define CSI2TX_DPHY_CFG_MODE_HS(1 << 8)
+#define CSI2TX_DPHY_CFG_MODE_ULPS  (0 << 8)
+#define CSI2TX_DPHY_CFG_CLK_ENABLE BIT(4)
+#define CSI2TX_DPHY_CFG_LANE_ENABLE(n) BIT(n)
+
+#define CSI2TX_DPHY_CLK_WAKEUP_REG 0x2c
+#define CSI2TX_DPHY_CLK_WAKEUP_ULPS_CYCLES(n)  ((n) & 0x)
+
+#define CSI2TX_DT_CFG_REG(n)   (0x80 + (n) * 8)
+#define CSI2TX_DT_CFG_DT(n)(((n) & 0x3f) << 2)
+
+#define CSI2TX_DT_FORMAT_REG(n)(0x84 + (n) * 8)
+#define CSI2TX_DT_FORMAT_BYTES_PER_LINE(n) (((n) & 0x) << 16)
+#define CSI2TX_DT_FORMAT_MAX_LINE_NUM(n)   ((n) & 0x)
+
+#define CSI2TX_STREAM_IF_CFG_REG(n)(0x100 + (n) * 4)
+#define CSI2TX_STREAM_IF_CFG_FILL_LEVEL(n) ((n) & 0x1f)
+
+#define CSI2TX_STREAMS_MAX 4
+
+enum csi2tx_pads {
+   CSI2TX_PAD_SOURCE,
+   CSI2TX_PAD_SINK_STREAM0,
+   CSI2TX_PAD_SINK_STREAM1,
+   CSI2TX_PAD_SINK_STREAM2,
+   CSI2TX_PAD_SINK_STREAM3,
+   CSI2TX_PAD_MAX,
+};
+
+struct csi2tx_fmt {
+   u32 mbus;
+   u32 dt;
+   u32 bpp;
+};
+
+struct csi2tx_priv {
+   struct device   *dev;
+   atomic_tcount;
+
+   void __iomem*base;
+
+   struct clk  *esc_clk;
+   struct clk  *p_clk;
+   struct clk  *pixel_clk[CSI2TX_STREAMS_MAX];
+
+   struct v4l2_subdev  subdev;
+   struct media_padpads[CSI2TX_PAD_MAX];
+   struct v4l2_mbus_framefmt   pad_fmts[CSI2TX_PAD_MAX];
+
+   boolhas_internal_dphy;
+   unsigned intlanes;
+   unsigned intmax_lanes;
+   unsigned intmax_streams;
+};
+
+static struct csi2tx_fmt csi2tx_formats[] = {
+   {
+   .mbus   

[PATCH 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings

[Maxime Ripard]

The Cadence MIPI-CSI2 RX controller is a CSI2 bridge that supports up to 4
video streams and can output on up to 4 CSI-2 lanes, depending on the
hardware implementation.

It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.

Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2tx.txt  | 97 ++
 1 file changed, 97 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2tx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
new file mode 100644
index ..5fb70bba910e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
@@ -0,0 +1,97 @@
+Cadence MIPI-CSI2 TX controller
+===
+
+The Cadence MIPI-CSI2 TX controller is a CSI-2 bridge supporting up to
+4 CSI lanes in output, and up to 4 different pixel streams in input.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2tx"
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* esc_clk: escape mode clock
+* p_clk: register bank clock
+* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+
+Optional properties
+  - phys: phandle to the D-PHY. If it is set, phy-names need to be set
+  - phy-names: must contain dphy
+
+Required subnodes:
+  - ports: A ports node with one port child node per device input and output
+   port, in accordance with the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   port nodes numbered as follows.
+
+   Port Description
+   -
+   0CSI-2 output
+   1Stream 0 input
+   2Stream 1 input
+   3Stream 2 input
+   4Stream 3 input
+
+   The stream input port nodes are optional if they are not
+   connected to anything at the hardware level or implemented
+   in the design.
+
+Example:
+
+csi2tx: csi-bridge@0d0e1000 {
+   compatible = "cdns,csi2tx";
+   reg = <0x0d0e1000 0x1000>;
+   clocks = <>, <>,
+<>, <>,
+<>, <>;
+   clock-names = "p_clk", "esc_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2tx_out: endpoint {
+   remote-endpoint = <_in>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2tx_in_stream0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2tx_in_stream1: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2tx_in_stream2: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2tx_in_stream3: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
-- 
2.13.5

[PATCH 0/2] media: v4l: Add support for the Cadence MIPI-CSI2 TX controller

[Maxime Ripard]

Hi,

Here is an attempt at supporting the MIPI-CSI2 TX block from Cadence.

This IP block is able to receive 4 video streams and stream them over
a MIPI-CSI2 link using up to 4 lanes. Those streams are basically the
interfaces to controllers generating some video signals, like a camera
or a pattern generator.

It is able to map input streams to CSI2 virtual channels and datatypes
dynamically. The streaming devices choose their virtual channels
through an additional signal that is transparent to the CSI2-TX. The
datatypes however are yet another additional input signal, and can be
mapped to any CSI2 datatypes.

Since v4l2 doesn't really allow for that setup at the moment, this
preliminary version is a rather dumb one in order to start the
discussion on how to address this properly.

This serie depends on the version 14 of the serie "Unified fwnode
endpoint parser, async sub-device notifier support, N9 flash DTS" by
Sakari Ailus

Let me know what you think!
Maxime

Maxime Ripard (2):
  dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings
  v4l: cadence: Add Cadence MIPI-CSI2 TX driver

 .../devicetree/bindings/media/cdns,csi2tx.txt  |  97 +
 drivers/media/platform/cadence/Kconfig |   6 +
 drivers/media/platform/cadence/Makefile|   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c   | 479 +
 4 files changed, 583 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

-- 
2.13.5

Re: [PATCH 2/4] [media] usbvision-core: Use common error handling code in usbvision_set_compress_params()

[Dan Carpenter]

On Thu, Sep 21, 2017 at 05:07:06PM +0200, SF Markus Elfring wrote:
> @@ -1913,11 +1908,12 @@ static int usbvision_set_compress_params(struct 
> usb_usbvision *usbvision)
>USB_DIR_OUT | USB_TYPE_VENDOR |
>USB_RECIP_ENDPOINT, 0,
>(__u16) USBVISION_PCM_THR1, value, 6, HZ);
> + if (rc < 0)
> +report_failure:
> + dev_err(>dev->dev,
> + "%s: ERROR=%d. USBVISION stopped - reconnect or reload 
> driver.\n",
> + __func__, rc);

You've been asked several times not to write code like this.  You do
it later in the patch series as well.

regards,
dan carpenter

Re: [PATCH v9 1/4] rockchip/rga: v4l2 m2m support

[Hans Verkuil]

Hi Jacob,

Sorry for the delay, but here is my review.

I noticed that there is no patch for the MAINTAINERS file, please add an entry
there for this driver.

On 14/09/17 03:19, Jacob Chen wrote:
> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> accelerates 2D graphics operations, such as point/line drawing, image
> scaling, rotation, BitBLT, alpha blending and image blur/sharpness
> 
> The drvier is mostly based on s5p-g2d v4l2 m2m driver

drvier -> driver

> And supports various operations from the rendering pipeline.
>  - copy
>  - fast solid color fill
>  - rotation
>  - flip
>  - alpha blending
> 
> The code in rga-hw.c is used to configure regs according to operations
> The code in rga-buf.c is used to create private mmu table for RGA.
> 
> changes in V7:
> - fix some warning reported by "checkpatch --strict"
> 
> Signed-off-by: Jacob Chen 
> ---
>  drivers/media/platform/Kconfig|   11 +
>  drivers/media/platform/Makefile   |2 +
>  drivers/media/platform/rockchip-rga/Makefile  |3 +
>  drivers/media/platform/rockchip-rga/rga-buf.c |  156 
>  drivers/media/platform/rockchip-rga/rga-hw.c  |  435 +++
>  drivers/media/platform/rockchip-rga/rga-hw.h  |  437 +++
>  drivers/media/platform/rockchip-rga/rga.c | 1030 
> +
>  drivers/media/platform/rockchip-rga/rga.h |  110 +++
>  8 files changed, 2184 insertions(+)
>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h

If there are more rockchip v4l2 drivers planned, then I recommend changing
the patch to rockchip/rga. That way other drivers can be added under the
rockchip directory.

> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 7e7cc49..9b79350 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -458,6 +458,17 @@ config VIDEO_RENESAS_VSP1
> To compile this driver as a module, choose M here: the module
> will be called vsp1.
>  
> +config VIDEO_ROCKCHIP_RGA
> + tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
> + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> + depends on ARCH_ROCKCHIP || COMPILE_TEST
> + select VIDEOBUF2_DMA_SG
> + select V4L2_MEM2MEM_DEV
> + default n
> + ---help---
> +   This is a v4l2 driver for Rockchip SOC RGA2
> +   2d graphics accelerator.

This is a bit too short. Why not use the same text as in this commit log?

> +
>  config VIDEO_TI_VPE
>   tristate "TI VPE (Video Processing Engine) driver"
>   depends on VIDEO_DEV && VIDEO_V4L2
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index c1ef946..06039c3 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -62,6 +62,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)+= rcar_fdp1.o
>  obj-$(CONFIG_VIDEO_RENESAS_JPU)  += rcar_jpu.o
>  obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
>  
> +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga/
> +
>  obj-y+= omap/
>  
>  obj-$(CONFIG_VIDEO_AM437X_VPFE)  += am437x/
> diff --git a/drivers/media/platform/rockchip-rga/Makefile 
> b/drivers/media/platform/rockchip-rga/Makefile
> new file mode 100644
> index 000..92fe254
> --- /dev/null
> +++ b/drivers/media/platform/rockchip-rga/Makefile
> @@ -0,0 +1,3 @@
> +rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
> +
> +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
> diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c 
> b/drivers/media/platform/rockchip-rga/rga-buf.c
> new file mode 100644
> index 000..373c36f
> --- /dev/null
> +++ b/drivers/media/platform/rockchip-rga/rga-buf.c
> @@ -0,0 +1,156 @@
> +/*
> + * Copyright (C) 2017 Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Jacob Chen 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "rga-hw.h"
> +#include "rga.h"
> +
> +static int
> +rga_queue_setup(struct vb2_queue *vq,
> + unsigned int *nbuffers, unsigned int *nplanes,
> + unsigned int sizes[], 

Re: [PATCH v8 0/5] Synopsys Designware HDMI Video Capture Controller + PHY

[Hans Verkuil]

Hi Jose,

I'm going to mark this patch series as 'Changes Requested' since it depends on
Sakari's subnotifier work. Once that is accepted I assume you'll make a v9 on 
top
and then this can hopefully be merged.

Regards,

Hans

On 10/07/17 17:46, Jose Abreu wrote:
> The Synopsys Designware HDMI RX controller is an HDMI receiver controller that
> is responsible to process digital data that comes from a phy. The final result
> is a stream of raw video data that can then be connected to a video DMA, for
> example, and transfered into RAM so that it can be displayed.
> 
> The controller + phy available in this series natively support all HDMI 1.4 
> and
> HDMI 2.0 modes, including deep color. Although, the driver is quite in its
> initial stage and unfortunatelly only non deep color modes are supported. 
> Also,
> audio is not yet supported in the driver (the controller has several audio
> output interfaces).
> 
> Version 8 addresses review comments from Rob Herring regarding device tree
> bindings.
> 
> I also added one patch for cec.h which is needed to fix build errors/warnings.
> 
> This series depends on the patch at [1].
> 
> This series was tested in a FPGA platform using an embedded platform called
> ARC AXS101.
> 
> Jose Abreu (5):
>   [media] cec.h: Add stub function for cec_register_cec_notifier()
>   dt-bindings: media: Document Synopsys Designware HDMI RX
>   MAINTAINERS: Add entry for Synopsys Designware HDMI drivers
>   [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver
>   [media] platform: Add Synopsys Designware HDMI RX Controller Driver
> 
> Cc: Carlos Palminha 
> Cc: Mauro Carvalho Chehab 
> Cc: Hans Verkuil 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Sylwester Nawrocki 
> 
> [1] https://patchwork.linuxtv.org/patch/41834/
> 
>  .../devicetree/bindings/media/snps,dw-hdmi-rx.txt  |   58 +
>  MAINTAINERS|7 +
>  drivers/media/platform/Kconfig |2 +
>  drivers/media/platform/Makefile|2 +
>  drivers/media/platform/dwc/Kconfig |   23 +
>  drivers/media/platform/dwc/Makefile|2 +
>  drivers/media/platform/dwc/dw-hdmi-phy-e405.c  |  844 +
>  drivers/media/platform/dwc/dw-hdmi-phy-e405.h  |   63 +
>  drivers/media/platform/dwc/dw-hdmi-rx.c| 1823 
> 
>  drivers/media/platform/dwc/dw-hdmi-rx.h|  441 +
>  include/media/cec.h|8 +
>  include/media/dwc/dw-hdmi-phy-pdata.h  |  128 ++
>  include/media/dwc/dw-hdmi-rx-pdata.h   |   70 +
>  13 files changed, 3471 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
>  create mode 100644 drivers/media/platform/dwc/Kconfig
>  create mode 100644 drivers/media/platform/dwc/Makefile
>  create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c
>  create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h
>  create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
>  create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
>  create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h
>  create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h
> 

Re: [PATCH] [media] hdpvr: Fix an error handling path in hdpvr_probe()

[Andrey Konovalov]

On Fri, Sep 22, 2017 at 3:07 PM, Arvind Yadav  wrote:
> Here, hdpvr_register_videodev() is responsible for setup and
> register a video device. Also defining and initializing a worker.
> hdpvr_register_videodev() is calling by hdpvr_probe at last.
> So No need to flash any work here.
> Unregister v4l2, free buffers and memory. If hdpvr_probe() will fail.
>
> Signed-off-by: Arvind Yadav 

Reported-by: Andrey Konovalov 

Thanks, this fixes the crash!

Tested-by: Andrey Konovalov 

> ---
>  drivers/media/usb/hdpvr/hdpvr-core.c | 26 +++---
>  1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/usb/hdpvr/hdpvr-core.c 
> b/drivers/media/usb/hdpvr/hdpvr-core.c
> index dbe29c6..1e8cbaf 100644
> --- a/drivers/media/usb/hdpvr/hdpvr-core.c
> +++ b/drivers/media/usb/hdpvr/hdpvr-core.c
> @@ -292,7 +292,7 @@ static int hdpvr_probe(struct usb_interface *interface,
> /* register v4l2_device early so it can be used for printks */
> if (v4l2_device_register(>dev, >v4l2_dev)) {
> dev_err(>dev, "v4l2_device_register failed\n");
> -   goto error;
> +   goto error_free_dev;
> }
>
> mutex_init(>io_mutex);
> @@ -301,7 +301,7 @@ static int hdpvr_probe(struct usb_interface *interface,
> dev->usbc_buf = kmalloc(64, GFP_KERNEL);
> if (!dev->usbc_buf) {
> v4l2_err(>v4l2_dev, "Out of memory\n");
> -   goto error;
> +   goto error_v4l2_unregister;
> }
>
> init_waitqueue_head(>wait_buffer);
> @@ -339,13 +339,13 @@ static int hdpvr_probe(struct usb_interface *interface,
> }
> if (!dev->bulk_in_endpointAddr) {
> v4l2_err(>v4l2_dev, "Could not find bulk-in endpoint\n");
> -   goto error;
> +   goto error_put_usb;
> }
>
> /* init the device */
> if (hdpvr_device_init(dev)) {
> v4l2_err(>v4l2_dev, "device init failed\n");
> -   goto error;
> +   goto error_put_usb;
> }
>
> mutex_lock(>io_mutex);
> @@ -353,7 +353,7 @@ static int hdpvr_probe(struct usb_interface *interface,
> mutex_unlock(>io_mutex);
> v4l2_err(>v4l2_dev,
>  "allocating transfer buffers failed\n");
> -   goto error;
> +   goto error_put_usb;
> }
> mutex_unlock(>io_mutex);
>
> @@ -361,7 +361,7 @@ static int hdpvr_probe(struct usb_interface *interface,
> retval = hdpvr_register_i2c_adapter(dev);
> if (retval < 0) {
> v4l2_err(>v4l2_dev, "i2c adapter register failed\n");
> -   goto error;
> +   goto error_free_buffers;
> }
>
> client = hdpvr_register_ir_rx_i2c(dev);
> @@ -394,13 +394,17 @@ static int hdpvr_probe(struct usb_interface *interface,
>  reg_fail:
>  #if IS_ENABLED(CONFIG_I2C)
> i2c_del_adapter(>i2c_adapter);
> +error_free_buffers:
>  #endif
> +   hdpvr_free_buffers(dev);
> +error_put_usb:
> +   usb_put_dev(dev->udev);
> +   kfree(dev->usbc_buf);
> +error_v4l2_unregister:
> +   v4l2_device_unregister(>v4l2_dev);
> +error_free_dev:
> +   kfree(dev);
>  error:
> -   if (dev) {
> -   flush_work(>worker);
> -   /* this frees allocated memory */
> -   hdpvr_delete(dev);
> -   }
> return retval;
>  }
>
> --
> 1.9.1
>

Re: [PATCH 2/2] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

[Sakari Ailus]

Hi Maxime,

On Fri, Sep 22, 2017 at 01:47:03PM +0200, Maxime Ripard wrote:
> The Cadence MIPI-CSI2 TX controller is an hardware block meant to be used
> as a bridge between pixel interfaces and a CSI-2 bus.
> 
> It supports operating with an internal or external D-PHY, with up to 4
> lanes, or without any D-PHY. The current code only supports the former
> case.
> 
> While the virtual channel input on the pixel interface can be directly
> mapped to CSI2, the datatype input is actually a selection signal (3-bits)
> mapping to a table of up to 8 preconfigured datatypes/formats (programmed
> at start-up)
> 
> The block supports up to 8 input datatypes.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/media/platform/cadence/Kconfig   |   6 +
>  drivers/media/platform/cadence/Makefile  |   1 +
>  drivers/media/platform/cadence/cdns-csi2tx.c | 479 
> +++
>  3 files changed, 486 insertions(+)
>  create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c
> 
> diff --git a/drivers/media/platform/cadence/Kconfig 
> b/drivers/media/platform/cadence/Kconfig
> index d1b6bbb6a0eb..db49328ee8b2 100644
> --- a/drivers/media/platform/cadence/Kconfig
> +++ b/drivers/media/platform/cadence/Kconfig
> @@ -9,4 +9,10 @@ config VIDEO_CADENCE_CSI2RX
>   depends on VIDEO_V4L2_SUBDEV_API
>   select V4L2_FWNODE
>  
> +config VIDEO_CADENCE_CSI2TX
> + tristate "Cadence MIPI-CSI2 TX Controller"
> + depends on MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
> +
>  endif
> diff --git a/drivers/media/platform/cadence/Makefile 
> b/drivers/media/platform/cadence/Makefile
> index 99a4086b7448..7fe992273162 100644
> --- a/drivers/media/platform/cadence/Makefile
> +++ b/drivers/media/platform/cadence/Makefile
> @@ -1 +1,2 @@
>  obj-$(CONFIG_VIDEO_CADENCE_CSI2RX)   += cdns-csi2rx.o
> +obj-$(CONFIG_VIDEO_CADENCE_CSI2TX)   += cdns-csi2tx.o
> diff --git a/drivers/media/platform/cadence/cdns-csi2tx.c 
> b/drivers/media/platform/cadence/cdns-csi2tx.c
> new file mode 100644
> index ..859bbce8772b
> --- /dev/null
> +++ b/drivers/media/platform/cadence/cdns-csi2tx.c
> @@ -0,0 +1,479 @@
> +/*
> + * Driver for Cadence MIPI-CSI2 TX Controller
> + *
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CSI2TX_DEVICE_CONFIG_REG 0x00
> +
> +#define CSI2TX_CONFIG_REG0x20
> +#define CSI2TX_CONFIG_CFG_REQBIT(2)
> +#define CSI2TX_CONFIG_SRST_REQ   BIT(1)
> +
> +#define CSI2TX_DPHY_CFG_REG  0x28
> +#define CSI2TX_DPHY_CFG_CLK_RESETBIT(16)
> +#define CSI2TX_DPHY_CFG_LANE_RESET(n)BIT((n) + 12)
> +#define CSI2TX_DPHY_CFG_MODE_MASKGENMASK(9, 8)
> +#define CSI2TX_DPHY_CFG_MODE_LPDT(2 << 8)
> +#define CSI2TX_DPHY_CFG_MODE_HS  (1 << 8)
> +#define CSI2TX_DPHY_CFG_MODE_ULPS(0 << 8)
> +#define CSI2TX_DPHY_CFG_CLK_ENABLE   BIT(4)
> +#define CSI2TX_DPHY_CFG_LANE_ENABLE(n)   BIT(n)
> +
> +#define CSI2TX_DPHY_CLK_WAKEUP_REG   0x2c
> +#define CSI2TX_DPHY_CLK_WAKEUP_ULPS_CYCLES(n)((n) & 0x)
> +
> +#define CSI2TX_DT_CFG_REG(n) (0x80 + (n) * 8)
> +#define CSI2TX_DT_CFG_DT(n)  (((n) & 0x3f) << 2)
> +
> +#define CSI2TX_DT_FORMAT_REG(n)  (0x84 + (n) * 8)
> +#define CSI2TX_DT_FORMAT_BYTES_PER_LINE(n)   (((n) & 0x) << 16)
> +#define CSI2TX_DT_FORMAT_MAX_LINE_NUM(n) ((n) & 0x)
> +
> +#define CSI2TX_STREAM_IF_CFG_REG(n)  (0x100 + (n) * 4)
> +#define CSI2TX_STREAM_IF_CFG_FILL_LEVEL(n)   ((n) & 0x1f)
> +
> +#define CSI2TX_STREAMS_MAX   4
> +
> +enum csi2tx_pads {
> + CSI2TX_PAD_SOURCE,
> + CSI2TX_PAD_SINK_STREAM0,
> + CSI2TX_PAD_SINK_STREAM1,
> + CSI2TX_PAD_SINK_STREAM2,
> + CSI2TX_PAD_SINK_STREAM3,
> + CSI2TX_PAD_MAX,
> +};
> +
> +struct csi2tx_fmt {
> + u32 mbus;
> + u32 dt;
> + u32 bpp;
> +};
> +
> +struct csi2tx_priv {
> + struct device   *dev;
> + atomic_tcount;
> +
> + void __iomem*base;
> +
> + struct clk  *esc_clk;
> + struct clk  *p_clk;
> + struct clk  *pixel_clk[CSI2TX_STREAMS_MAX];
> +
> + struct v4l2_subdev  subdev;
> + struct media_padpads[CSI2TX_PAD_MAX];
> + struct v4l2_mbus_framefmt   pad_fmts[CSI2TX_PAD_MAX];
> 

Re: [PATCH v4 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings

[Sakari Ailus]

Hi Maxime,

On Fri, Sep 22, 2017 at 12:08:22PM +0200, Maxime Ripard wrote:
> The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to
> 4 CSI-2 lanes, and can route the frames to up to 4 streams, depending on
> the hardware implementation.
> 
> It can operate with an external D-PHY, an internal one or no D-PHY at all
> in some configurations.
> 
> Acked-by: Rob Herring 
> Acked-by: Benoit Parrot 
> Acked-by: Sakari Ailus 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Maxime Ripard 
> ---
>  .../devicetree/bindings/media/cdns,csi2rx.txt  | 97 
> ++
>  1 file changed, 97 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt 
> b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> new file mode 100644
> index ..e9c30f964a96
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> @@ -0,0 +1,97 @@
> +Cadence MIPI-CSI2 RX controller
> +===
> +
> +The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
> +lanes in input, and 4 different pixel streams in output.
> +
> +Required properties:
> +  - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
> +  - reg: base address and size of the memory mapped region
> +  - clocks: phandles to the clocks driving the controller
> +  - clock-names: must contain:
> +* sys_clk: main clock
> +* p_clk: register bank clock
> +* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
> + implemented in hardware, between 0 and 3
> +
> +Optional properties:
> +  - phys: phandle to the external D-PHY, phy-names must be provided
> +  - phy-names: must contain dphy, if the implementation uses an
> +   external D-PHY
> +
> +Required subnodes:
> +  - ports: A ports node with one port child node per device input and output
> +   port, in accordance with the video interface bindings defined in
> +   Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +   port nodes numbered as follows.
> +
> +   Port Description
> +   -
> +   0CSI-2 input
> +   1Stream 0 output
> +   2Stream 1 output
> +   3Stream 2 output
> +   4Stream 3 output
> +
> +   The stream output port nodes are optional if they are not 
> connected
> +   to anything at the hardware level or implemented in the design.

Could you add supported endpoint numbers, please?



> +
> +Example:
> +
> +csi2rx: csi-bridge@0d06 {
> + compatible = "cdns,csi2rx";
> + reg = <0x0d06 0x1000>;
> + clocks = <>, <>
> +  <>, <>,
> +  <>, <>;
> + clock-names = "sys_clk", "p_clk",
> +   "pixel_if0_clk", "pixel_if1_clk",
> +   "pixel_if2_clk", "pixel_if3_clk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + csi2rx_in_sensor: endpoint {
> + remote-endpoint = <_out_csi2rx>;
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + csi2rx_out_grabber0: endpoint {
> + remote-endpoint = <_in_csi2rx>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + csi2rx_out_grabber1: endpoint {
> + remote-endpoint = <_in_csi2rx>;
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> +
> + csi2rx_out_grabber2: endpoint {
> + remote-endpoint = <_in_csi2rx>;
> + };
> + };
> +
> + port@4 {
> + reg = <4>;
> +
> + csi2rx_out_grabber3: endpoint {
> + remote-endpoint = <_in_csi2rx>;
> + };
> + };
> + };
> +};
> -- 
> 2.13.5
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 3/4] [media] usbvision-core: Delete unnecessary braces in 11 functions

[Dan Carpenter]

No.  Multi-line indents get curly braces for readability.

regards,
dan carpenter

Re: usb/media/hdpvr: trying to register non-static key in hdpvr_probe

[Arvind Yadav]

Hi Andrey,


On Friday 22 September 2017 05:16 PM, Andrey Konovalov wrote:

On Fri, Sep 22, 2017 at 9:41 AM, Arvind Yadav  wrote:

Hi,

I have a doubt. Why we are calling flush_work in hdpvr_probe for every
failure.
We are flushing work which is not defined yet.

Here, hdpvr_register_videodev() is responsible for setup and register a
video device.
Also defining and initializing a worker. we are calling
hdpvr_register_videodev() at last.
No need to flash any work here.

Please correct me, if I am wrong.

Hi Arvind,

I believe you're right, no need to call flush_work() before
dev->worker is initialized.

Could you send a fix?

I'm able to reproduce the issue, so I can test your patches if needed.
I have send a one patch to you. which will resolve this error. But my 
question is why
hdpvr_probe() is failing. We need to find out. Could please share more 
information and logs.


~arvind

Thanks!



On Thursday 21 September 2017 09:09 PM, Andrey Konovalov wrote:

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #215
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
   __dump_stack lib/dump_stack.c:16
   dump_stack+0x292/0x395 lib/dump_stack.c:52
   register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
   __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
   lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
   flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
   hdpvr_probe+0x233/0x20d0 drivers/media/usb/hdpvr/hdpvr-core.c:400
   usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
   really_probe drivers/base/dd.c:413
   driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
   __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
   bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
   __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
   device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
   bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
   device_add+0xd0b/0x1660 drivers/base/core.c:1835
   usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
   generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
   usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
   really_probe drivers/base/dd.c:413
   driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
   __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
   bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
   __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
   device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
   bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
   device_add+0xd0b/0x1660 drivers/base/core.c:1835
   usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
   hub_port_connect drivers/usb/core/hub.c:4903
   hub_port_connect_change drivers/usb/core/hub.c:5009
   port_event drivers/usb/core/hub.c:5115
   hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
   process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
   worker_thread+0x221/0x1850 kernel/workqueue.c:2253
   kthread+0x3a1/0x470 kernel/kthread.c:231
   ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
hdpvr: probe of 1-1:8.217 failed with error -12

~arvind

Re: usb/media/hdpvr: trying to register non-static key in hdpvr_probe

[Andrey Konovalov]

On Fri, Sep 22, 2017 at 3:09 PM, Arvind Yadav  wrote:
> Hi Andrey,
>
>
> On Friday 22 September 2017 05:16 PM, Andrey Konovalov wrote:
>>
>> On Fri, Sep 22, 2017 at 9:41 AM, Arvind Yadav 
>> wrote:
>>>
>>> Hi,
>>>
>>> I have a doubt. Why we are calling flush_work in hdpvr_probe for every
>>> failure.
>>> We are flushing work which is not defined yet.
>>>
>>> Here, hdpvr_register_videodev() is responsible for setup and register a
>>> video device.
>>> Also defining and initializing a worker. we are calling
>>> hdpvr_register_videodev() at last.
>>> No need to flash any work here.
>>>
>>> Please correct me, if I am wrong.
>>
>> Hi Arvind,
>>
>> I believe you're right, no need to call flush_work() before
>> dev->worker is initialized.
>>
>> Could you send a fix?
>>
>> I'm able to reproduce the issue, so I can test your patches if needed.
>
> I have send a one patch to you. which will resolve this error. But my
> question is why
> hdpvr_probe() is failing. We need to find out. Could please share more
> information and logs.

The patch helps, thanks!

hdpvr_probe() is failing, because I'm attaching a malicious USB device
that pretends to be an hdpvr device, but doesn't have a bulk-in
endpoint.

[   27.722420] gadgetfs: bound to dummy_udc driver
[   27.990245] usb 1-1: new full-speed USB device number 2 using dummy_hcd
[   28.010242] gadgetfs: connected
[   28.011732] gadgetfs: disconnected
[   28.230142] gadgetfs: connected
[   28.330313] usb 1-1: config 8 has an invalid interface number: 217
but max is 0
[   28.331981] usb 1-1: config 8 has no interface number 0
[   28.410315] usb 1-1: New USB device found, idVendor=2040, idProduct=4903
[   28.411826] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=127
[   28.413477] usb 1-1: SerialNumber: a
[   28.440134] gadgetfs: configuration #8
[   28.467705] hdpvr 1-1:8.217: Could not find bulk-in endpoint
[   28.469024] hdpvr: probe of 1-1:8.217 failed with error -12
[   29.446584] gadgetfs: disconnected
[   29.449634] usb 1-1: USB disconnect, device number 2

>
> ~arvind
>
>> Thanks!
>>
>>>
>>> On Thursday 21 September 2017 09:09 PM, Andrey Konovalov wrote:

 Hi!

 I've got the following report while fuzzing the kernel with syzkaller.

 On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

 INFO: trying to register non-static key.
 the code is fine but needs lockdep annotation.
 turning off the locking correctness validator.
 CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted
 4.14.0-rc1-42251-gebb2c2437d80 #215
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
 01/01/2011
 Workqueue: usb_hub_wq hub_event
 Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
__lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
hdpvr_probe+0x233/0x20d0 drivers/media/usb/hdpvr/hdpvr-core.c:400
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
hub_port_connect drivers/usb/core/hub.c:4903
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
 hdpvr: probe of 1-1:8.217 failed with error -12
>>>
>>> ~arvind
>
>

Re: [PATCH v2] [media] staging: atomisp: use clock framework for camera clocks

[Sakari Ailus]

Hi Pierre-Louis,

On Wed, Sep 20, 2017 at 03:53:58PM -0500, Pierre-Louis Bossart wrote:
> The Atom ISP driver initializes and configures PMC clocks which are
> already handled by the clock framework.
> 
> Remove all legacy vlv2_platform_clock stuff and move to the clk API to
> avoid conflicts, e.g. with audio machine drivers enabling the MCLK for
> external codecs
> 
> Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
> Tested-by: Carlo Caione 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Pierre-Louis Bossart 

I've applied the patch with small changes, there were other patches
changing the deleted files.

The tree is here:



-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

[GIT PULL for 4.15] atomisp cleanups and improvements

[Sakari Ailus]

Hi Mauro,

Here are a bunch of atomisp cleanups and improvements.

Please pull.


The following changes since commit 1efdf1776e2253b77413c997bed862410e4b6aaf:

  media: leds: as3645a: add V4L2_FLASH_LED_CLASS dependency (2017-09-05 
16:32:45 -0400)

are available in the git repository at:

  https://linuxtv.org/git/sailus/media_tree.git atomisp

for you to fetch changes up to 18a914f44b00ffeb1b4456bfbf3ae46b16c53e2c:

  staging: atomisp: use clock framework for camera clocks (2017-09-21 15:53:06 
+0300)


Allen Pais (1):
  atomisp:use ARRAY_SIZE() instead of open coding.

Andy Shevchenko (7):
  staging: atomisp: Remove dead code for MID (#1)
  staging: atomisp: Don't override D3 delay settings here
  staging: atomisp: Remove dead code for MID (#2)
  staging: atomisp: Remove dead code for MID (#3)
  staging: atomisp: Move to upstream IOSF MBI API
  staging: atomisp: Remove dead code for MID (#4)
  staging: atomisp: Remove unneeded intel-mid.h inclusion

Arvind Yadav (1):
  Staging: atomisp: constify driver_attribute

Branislav Radocaj (1):
  Staging: atomisp: fix alloc_cast.cocci warnings

Hans Verkuil (1):
  atomisp: fix small Kconfig issues

Himanshu Jha (1):
  atomisp2: Remove null check before kfree

Nicolas Iooss (1):
  staging/atomisp: fix header guards

Pierre-Louis Bossart (1):
  staging: atomisp: use clock framework for camera clocks

Sakari Ailus (1):
  staging: media: atomisp: Use tabs in Kconfig

Srishti Sharma (2):
  Staging: media: atomisp: Merge assignment with return
  Staging: media: atomisp: Use kcalloc instead of kzalloc

Thomas Meyer (1):
  staging/atomisp: Use ARRAY_SIZE macro

 drivers/staging/media/atomisp/Kconfig  |  11 +-
 drivers/staging/media/atomisp/i2c/Kconfig  |  70 ++---
 drivers/staging/media/atomisp/i2c/imx/drv201.c |   1 -
 drivers/staging/media/atomisp/i2c/imx/dw9714.c |   1 -
 drivers/staging/media/atomisp/i2c/imx/imx.c|   1 -
 drivers/staging/media/atomisp/i2c/imx/otp_imx.c|   1 -
 drivers/staging/media/atomisp/i2c/ov5693/Kconfig   |   8 +-
 drivers/staging/media/atomisp/i2c/ov5693/ov5693.c  |  11 +-
 .../atomisp/include/asm/intel_mid_pcihelpers.h |  37 ---
 drivers/staging/media/atomisp/pci/Kconfig  |  17 +-
 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   |  21 +-
 .../media/atomisp/pci/atomisp2/atomisp_drvfs.c |   2 +-
 .../media/atomisp/pci/atomisp2/atomisp_internal.h  |   3 -
 .../media/atomisp/pci/atomisp2/atomisp_ioctl.c |   1 -
 .../media/atomisp/pci/atomisp2/atomisp_subdev.c|   1 -
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |  37 ++-
 .../hrt/input_formatter_subsystem_defs.h   |   2 +-
 .../hrt/input_formatter_subsystem_defs.h   |   2 +-
 .../hrt/input_formatter_subsystem_defs.h   |   2 +-
 .../pci/atomisp2/css2400/runtime/ifmtr/src/ifmtr.c |   3 +-
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c|   6 +-
 .../atomisp/pci/atomisp2/css2400/sh_css_firmware.c |  12 +-
 .../media/atomisp/pci/atomisp2/hmm/hmm_bo.c|   6 +-
 drivers/staging/media/atomisp/platform/Makefile|   1 -
 .../staging/media/atomisp/platform/clock/Makefile  |   6 -
 .../platform/clock/platform_vlv2_plat_clk.c|  40 ---
 .../platform/clock/platform_vlv2_plat_clk.h|  27 --
 .../media/atomisp/platform/clock/vlv2_plat_clock.c | 247 -
 .../media/atomisp/platform/intel-mid/Makefile  |   1 -
 .../platform/intel-mid/atomisp_gmin_platform.c |  63 -
 .../platform/intel-mid/intel_mid_pcihelpers.c  | 297 -
 31 files changed, 149 insertions(+), 789 deletions(-)
 delete mode 100644 
drivers/staging/media/atomisp/include/asm/intel_mid_pcihelpers.h
 delete mode 100644 drivers/staging/media/atomisp/platform/clock/Makefile
 delete mode 100644 
drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.c
 delete mode 100644 
drivers/staging/media/atomisp/platform/clock/platform_vlv2_plat_clk.h
 delete mode 100644 
drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
 delete mode 100644 
drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 2/4] [media] usbvision-core: Use common error handling code in usbvision_set_compress_params()

[SF Markus Elfring]

>> @@ -1913,11 +1908,12 @@ static int usbvision_set_compress_params(struct 
>> usb_usbvision *usbvision)
>>   USB_DIR_OUT | USB_TYPE_VENDOR |
>>   USB_RECIP_ENDPOINT, 0,
>>   (__u16) USBVISION_PCM_THR1, value, 6, HZ);
>> +if (rc < 0)
>> +report_failure:
>> +dev_err(>dev->dev,
>> +"%s: ERROR=%d. USBVISION stopped - reconnect or reload 
>> driver.\n",
>> +__func__, rc);
> 
> You've been asked several times not to write code like this.

This suggestion occurred a few times.

Do you prefer to move this place to the end together with a duplicated 
statement “return rc;”?


> You do it later in the patch series as well.

To which update step do you refer here?

Regards,
Markus

Re: [media] usbvision-core: Delete unnecessary braces in 11 functions

[SF Markus Elfring]

> No.  Multi-line indents get curly braces for readability.

Which of the proposed change possibilities do you not like especially at the 
moment?

Regards,
Markus

Re: [PATCH 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings

[Maxime Ripard]

Hi Sakari,

On Fri, Sep 22, 2017 at 12:01:06PM +, Sakari Ailus wrote:
> On Fri, Sep 22, 2017 at 01:47:02PM +0200, Maxime Ripard wrote:
> > The Cadence MIPI-CSI2 RX controller is a CSI2 bridge that supports up to 4
> 
> Should this be TX?
> 
> I was just thinking what does this chip do, and saw both. RX it at least
> less common. :-)

Yes, definitely :)

This one's a transceiver, the other one a receiver.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v4 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings

[Maxime Ripard]

Hi Sakari,

On Fri, Sep 22, 2017 at 11:35:23AM +, Sakari Ailus wrote:
> Hi Maxime,
> 
> On Fri, Sep 22, 2017 at 12:08:22PM +0200, Maxime Ripard wrote:
> > The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to
> > 4 CSI-2 lanes, and can route the frames to up to 4 streams, depending on
> > the hardware implementation.
> > 
> > It can operate with an external D-PHY, an internal one or no D-PHY at all
> > in some configurations.
> > 
> > Acked-by: Rob Herring 
> > Acked-by: Benoit Parrot 
> > Acked-by: Sakari Ailus 
> > Reviewed-by: Laurent Pinchart 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  .../devicetree/bindings/media/cdns,csi2rx.txt  | 97 
> > ++
> >  1 file changed, 97 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt 
> > b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> > new file mode 100644
> > index ..e9c30f964a96
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
> > @@ -0,0 +1,97 @@
> > +Cadence MIPI-CSI2 RX controller
> > +===
> > +
> > +The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 
> > CSI
> > +lanes in input, and 4 different pixel streams in output.
> > +
> > +Required properties:
> > +  - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
> > +  - reg: base address and size of the memory mapped region
> > +  - clocks: phandles to the clocks driving the controller
> > +  - clock-names: must contain:
> > +* sys_clk: main clock
> > +* p_clk: register bank clock
> > +* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
> > + implemented in hardware, between 0 and 3
> > +
> > +Optional properties:
> > +  - phys: phandle to the external D-PHY, phy-names must be provided
> > +  - phy-names: must contain dphy, if the implementation uses an
> > +   external D-PHY
> > +
> > +Required subnodes:
> > +  - ports: A ports node with one port child node per device input and 
> > output
> > +   port, in accordance with the video interface bindings defined in
> > +   Documentation/devicetree/bindings/media/video-interfaces.txt. 
> > The
> > +   port nodes numbered as follows.
> > +
> > +   Port Description
> > +   -
> > +   0CSI-2 input
> > +   1Stream 0 output
> > +   2Stream 1 output
> > +   3Stream 2 output
> > +   4Stream 3 output
> > +
> > +   The stream output port nodes are optional if they are not 
> > connected
> > +   to anything at the hardware level or implemented in the design.
> 
> Could you add supported endpoint numbers, please?
> 
> 

So in the case where you have a single endpoint, usually you don't
provide an endpoint number at all. Should I document it as zero, or as
"no number"?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH] [media] stk-webcam: Fix use after free on disconnect

[Dan Carpenter]

We free the stk_camera device too early.  It's allocate first in probe
and it should be freed last in stk_camera_disconnect().

Reported-by: Andrey Konovalov 
Signed-off-by: Dan Carpenter 
---
Not tested but these bug reports seem surprisingly straight forward.
Thanks Andrey!

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c 
b/drivers/media/usb/stkwebcam/stk-webcam.c
index c0bba773db25..e748c976d967 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -1241,7 +1241,6 @@ static void stk_v4l_dev_release(struct video_device *vd)
if (dev->sio_bufs != NULL || dev->isobufs != NULL)
pr_err("We are leaking memory\n");
usb_put_intf(dev->interface);
-   kfree(dev);
 }
 
 static const struct video_device stk_v4l_data = {
@@ -1391,6 +1390,7 @@ static void stk_camera_disconnect(struct usb_interface 
*interface)
video_unregister_device(>vdev);
v4l2_ctrl_handler_free(>hdl);
v4l2_device_unregister(>v4l2_dev);
+   kfree(dev);
 }
 
 #ifdef CONFIG_PM

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

[Dave Stevenson]

Hi Stefan

On 22 September 2017 at 07:45, Stefan Wahren  wrote:
> Hi Dave,
>
>> Dave Stevenson  hat am 20. September 2017 um 
>> 18:07 geschrieben:
>>
>>
>> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>> (known as Unicam) on BCM283x SoCs.
>>
>> Signed-off-by: Dave Stevenson 
>> ---
>>
>> Changes since v2
>> - Removed all references to Linux drivers.
>> - Reworded section about disabling the firmware driver.
>> - Renamed clock from "lp_clock" to "lp" in description and example.
>> - Referred to video-interfaces.txt and stated requirements on remote-endpoint
>>   and data-lanes.
>> - Corrected typo in example from csi to csi1.
>> - Removed unnecessary #address-cells and #size-cells in example.
>> - Removed setting of status from the example.
>>
>>  .../devicetree/bindings/media/bcm2835-unicam.txt   | 85 
>> ++
>>  1 file changed, 85 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt 
>> b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>> new file mode 100644
>> index 000..7714fb3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>> @@ -0,0 +1,85 @@
>> +Broadcom BCM283x Camera Interface (Unicam)
>> +--
>> +
>> +The Unicam block on BCM283x SoCs is the receiver for either
>> +CSI-2 or CCP2 data from image sensors or similar devices.
>> +
>> +The main platform using this SoC is the Raspberry Pi family of boards.
>> +On the Pi the VideoCore firmware can also control this hardware block,
>> +and driving it from two different processors will cause issues.
>> +To avoid this, the firmware checks the device tree configuration
>> +during boot. If it finds device tree nodes called csi0 or csi1 then
>> +it will stop the firmware accessing the block, and it can then
>> +safely be used via the device tree binding.
>> +
>> +Required properties:
>> +===
>> +- compatible : must be "brcm,bcm2835-unicam".
>> +- reg: physical base address and length of the register 
>> sets for the
>> +   device.
>> +- interrupts : should contain the IRQ line for this Unicam instance.
>> +- clocks : list of clock specifiers, corresponding to entries in
>> +   clock-names property.
>> +- clock-names: must contain an "lp" entry, matching entries in the
>> +   clocks property.
>> +
>> +Unicam supports a single port node. It should contain one 'port' child node
>> +with child 'endpoint' node. Please refer to the bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +Within the endpoint node the "remote-endpoint" and "data-lanes" properties
>> +are mandatory.
>> +Data lane reordering is not supported so the data lanes must be in order,
>> +starting at 1. The number of data lanes should represent the number of
>> +usable lanes for the hardware block. That may be limited by either the SoC 
>> or
>> +how the platform presents the interface, and the lower value must be used.
>> +
>> +Lane reordering is not supported on the clock lane either, so the optional
>> +property "clock-lane" will implicitly be <0>.
>> +Similarly lane inversion is not supported, therefore "lane-polarities" will
>> +implicitly be <0 0 0 0 0>.
>> +Neither of these values will be checked.
>> +
>> +Example:
>> + csi1: csi1@7e801000 {
>> + compatible = "brcm,bcm2835-unicam";
>> + reg = <0x7e801000 0x800>,
>> +   <0x7e802004 0x4>;
>
> sorry, i didn't noticed this before. I'm afraid this is using a small range 
> of the CMI. Are there possible other users of this range? Does it make sense 
> to handle this by a separate clock driver?

CMI (Clock Manager Image) consists of a total of 4 registers.
0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and
inversion of the clock and data lanes (2 data lanes available on
CAM0).
0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and
inversion of the clock and data lanes (4 data lanes available on
CAM1).
0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.
0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The
default value is the required value. Nothing touches it that I can
find.

The range listed only covers the one register associated with that
Unicam instance, so no other users. The other two aren't touched.
Do 16 active register bits solely for camera clock gating really
warrant a full clock driver?

  Dave

Re: [PATCH 2/2] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

[Maxime Ripard]

Hi Sakari,

I'll address the minor comments you had and that I stripped.

On Fri, Sep 22, 2017 at 12:38:49PM +, Sakari Ailus wrote:
> > +   /*
> > +* Create a static mapping between the CSI virtual channels
> > +* and the input streams.
> 
> Which virtual channel is used here?

Like I was trying to explain in the cover letter, the virtual channel
is not under that block's control. The input video interfaces have an
additional signal that comes from the upstream device which sets the
virtual channel.

It's transparent to the CSI2-TX block, even though it's
there. Depending on the implementation, it can be either fixed or can
change, it's up to the other block's designer. The only restriction is
that it cannot change while a streaming is occuring.

> > +
> > +   /*
> > +* If no-one set a format, we consider this pad
> > +* disabled and just skip it.
> > +*/
> > +   if (!fmt)
> 
> The pad should have a valid format even if the user didn't configure
> it.

Which format should be by default then?

> Instead you should use the link state to determine whether the link is
> active or not.

Ok, will do.

> > +   continue;
> > +
> > +   /*
> > +* We use the stream ID there, but it's wrong.
> > +*
> > +* A stream could very well send a data type that is
> > +* not equal to its stream ID. We need to find a
> > +* proper way to address it.
> 
> Stream IDs will presumably be used in V4L2 for a different purpose. Does
> the hardware documentation call them such?

Input video interfaces are called streams, yes, and then they are
numbered. If it's just confusing because of a collision with one of
v4l2's nomenclature, I'm totally fine to change it to some other name.

> > +*/
> > +   writel(CSI2TX_DT_CFG_DT(fmt->dt),
> > +  csi2tx->base + CSI2TX_DT_CFG_REG(stream));
> > +
> > +   writel(CSI2TX_DT_FORMAT_BYTES_PER_LINE(mfmt->width * fmt->bpp) |
> > +  CSI2TX_DT_FORMAT_MAX_LINE_NUM(mfmt->height + 1),
> > +  csi2tx->base + CSI2TX_DT_FORMAT_REG(stream));
> > +
> > +   /*
> > +* TODO: This needs to be calculated based on the
> > +* clock rate.
> 
> Clock rate of what? Input?

Of the CSI2 link, so output. I guess I should make that clearer.

> 
> > +*/
> > +   writel(CSI2TX_STREAM_IF_CFG_FILL_LEVEL(4),
> > +  csi2tx->base + CSI2TX_STREAM_IF_CFG_REG(stream));
> > +   }
> > +
> > +   /* Disable the configuration mode */
> > +   writel(0, csi2tx->base + CSI2TX_CONFIG_REG);
> 
> Shouldn't you start streaming on the downstream sub-device as well?

I appreciate it's a pretty weak argument, but the current setup we
have is in the FPGA is:

capture <- CSI2-RX <- CSI2-TX <- pattern generator

So far, the CSI2-RX block is calling its remote sub-device, which is
CSI2-TX. If CSI2-RX is calling its remote sub-device (CSI2-RX), we
just found ourselves in an endless loop.

I guess it should be easier, and fixable, when we'll have an actual
device without such a loopback.

> > +
> > +   return 0;
> > +}
> > +
> > +static int csi2tx_stop(struct csi2tx_priv *csi2tx)
> > +{
> > +   /*
> > +* Let the last user turn off the lights
> > +*/
> > +   if (!atomic_dec_and_test(>count))
> > +   return 0;
> > +
> > +   /* FIXME: Disable the IP here */
> 
> Shouldn't this be addressed?

Yes, but it's still unclear how at the moment. It will of course
eventually be implemented.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v2 0/4] BCM283x Camera Receiver driver

[Dave Stevenson]

On 22 September 2017 at 12:00, Hans Verkuil  wrote:
> On 13/09/17 17:49, Dave Stevenson wrote:
>> OV5647
>>
>> v4l2-compliance SHA   : f6ecbc90656815d91dc6ba90aac0ad8193a14b38
>>
>> Driver Info:
>> Driver name   : unicam
>> Card type : unicam
>> Bus info  : platform:unicam 3f801000.csi1
>> Driver version: 4.13.0
>> Capabilities  : 0x8521
>> Video Capture
>> Read/Write
>> Streaming
>> Extended Pix Format
>> Device Capabilities
>> Device Caps   : 0x0521
>> Video Capture
>> Read/Write
>> Streaming
>> Extended Pix Format
>>
>> Compliance test for device /dev/video0 (not using libv4l2):
>>
>> Required ioctls:
>> test VIDIOC_QUERYCAP: OK
>>
>> Allow for multiple opens:
>> test second video open: OK
>> test VIDIOC_QUERYCAP: OK
>> test VIDIOC_G/S_PRIORITY: OK
>> test for unlimited opens: OK
>>
>> Debug ioctls:
>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>> test VIDIOC_LOG_STATUS: OK
>>
>> Input ioctls:
>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>> test VIDIOC_G/S/ENUMINPUT: OK
>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>> Inputs: 1 Audio Inputs: 0 Tuners: 0
>>
>> Output ioctls:
>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>
>> Input/Output configuration ioctls:
>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>
>> Test input 0:
>>
>> Control ioctls:
>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
>> test VIDIOC_QUERYCTRL: OK
>> test VIDIOC_G/S_CTRL: OK
>> fail: v4l2-test-controls.cpp(587): g_ext_ctrls does not
>> support count == 0
>
> Huh. The issue here is that there are no controls at all, but the
> control API is present. The class_check() function in v4l2-ctrls.c expects
> that there are controls and if not it returns -EINVAL, causing this test
> to fail.
>
> Try to apply this patch:
>
> Signed-off-by: Hans Verkuil 
> ---
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index dd1db678718c..4e53a8654690 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -2818,7 +2818,7 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler 
> *hdl,
>  static int class_check(struct v4l2_ctrl_handler *hdl, u32 which)
>  {
> if (which == 0 || which == V4L2_CTRL_WHICH_DEF_VAL)
> -   return list_empty(>ctrl_refs) ? -EINVAL : 0;
> +   return 0;
> return find_ref_lock(hdl, which | 1) ? 0 : -EINVAL;
>  }
>
>
> and see if it will pass the compliance test. There may be other issues.
> I think that the compliance test should handle the case where there are no
> controls, so this is a good test.

Fails.
fail: v4l2-test-controls.cpp(589): g_ext_ctrls worked even
when no controls are present
test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL

> That said, another solution is that the driver detects that there are no
> controls in unicam_probe_complete() and sets unicam->v4l2_dev.ctrl_handler
> to NULL.
>
> I think you should do this in v4. Having control ioctls but no actual controls
> is not wrong as such, but it is a bit misleading towards the application.

OK, will do.

  Dave

[PATCH] [media] sn9c20x: Use common error handling code in sd_init()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 22 Sep 2017 17:45:33 +0200

Add jump targets so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/gspca/sn9c20x.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/media/usb/gspca/sn9c20x.c 
b/drivers/media/usb/gspca/sn9c20x.c
index c605f78d6186..282bbd77d815 100644
--- a/drivers/media/usb/gspca/sn9c20x.c
+++ b/drivers/media/usb/gspca/sn9c20x.c
@@ -1788,10 +1788,8 @@ static int sd_init(struct gspca_dev *gspca_dev)
for (i = 0; i < ARRAY_SIZE(bridge_init); i++) {
value = bridge_init[i][1];
reg_w(gspca_dev, bridge_init[i][0], , 1);
-   if (gspca_dev->usb_err < 0) {
-   pr_err("Device initialization failed\n");
-   return gspca_dev->usb_err;
-   }
+   if (gspca_dev->usb_err < 0)
+   goto report_failure;
}
 
if (sd->flags & LED_REVERSE)
@@ -1800,10 +1798,8 @@ static int sd_init(struct gspca_dev *gspca_dev)
reg_w1(gspca_dev, 0x1006, 0x20);
 
reg_w(gspca_dev, 0x10c0, i2c_init, 9);
-   if (gspca_dev->usb_err < 0) {
-   pr_err("Device initialization failed\n");
-   return gspca_dev->usb_err;
-   }
+   if (gspca_dev->usb_err < 0)
+   goto report_failure;
 
switch (sd->sensor) {
case SENSOR_OV9650:
@@ -1869,6 +1865,11 @@ static int sd_init(struct gspca_dev *gspca_dev)
pr_err("Unsupported sensor\n");
gspca_dev->usb_err = -ENODEV;
}
+   goto exit;
+
+report_failure:
+   pr_err("Device initialization failed\n");
+exit:
return gspca_dev->usb_err;
 }
 
-- 
2.14.1

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

[Eric Anholt]

Dave Stevenson  writes:

> Hi Stefan
>
> On 22 September 2017 at 07:45, Stefan Wahren  wrote:
>> Hi Dave,
>>
>>> Dave Stevenson  hat am 20. September 2017 
>>> um 18:07 geschrieben:
>>>
>>>
>>> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>>> (known as Unicam) on BCM283x SoCs.
>>>
>>> Signed-off-by: Dave Stevenson 
>>> ---
>>>
>>> Changes since v2
>>> - Removed all references to Linux drivers.
>>> - Reworded section about disabling the firmware driver.
>>> - Renamed clock from "lp_clock" to "lp" in description and example.
>>> - Referred to video-interfaces.txt and stated requirements on 
>>> remote-endpoint
>>>   and data-lanes.
>>> - Corrected typo in example from csi to csi1.
>>> - Removed unnecessary #address-cells and #size-cells in example.
>>> - Removed setting of status from the example.
>>>
>>>  .../devicetree/bindings/media/bcm2835-unicam.txt   | 85 
>>> ++
>>>  1 file changed, 85 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt 
>>> b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>> new file mode 100644
>>> index 000..7714fb3
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>> @@ -0,0 +1,85 @@
>>> +Broadcom BCM283x Camera Interface (Unicam)
>>> +--
>>> +
>>> +The Unicam block on BCM283x SoCs is the receiver for either
>>> +CSI-2 or CCP2 data from image sensors or similar devices.
>>> +
>>> +The main platform using this SoC is the Raspberry Pi family of boards.
>>> +On the Pi the VideoCore firmware can also control this hardware block,
>>> +and driving it from two different processors will cause issues.
>>> +To avoid this, the firmware checks the device tree configuration
>>> +during boot. If it finds device tree nodes called csi0 or csi1 then
>>> +it will stop the firmware accessing the block, and it can then
>>> +safely be used via the device tree binding.
>>> +
>>> +Required properties:
>>> +===
>>> +- compatible : must be "brcm,bcm2835-unicam".
>>> +- reg: physical base address and length of the register 
>>> sets for the
>>> +   device.
>>> +- interrupts : should contain the IRQ line for this Unicam instance.
>>> +- clocks : list of clock specifiers, corresponding to entries in
>>> +   clock-names property.
>>> +- clock-names: must contain an "lp" entry, matching entries in the
>>> +   clocks property.
>>> +
>>> +Unicam supports a single port node. It should contain one 'port' child node
>>> +with child 'endpoint' node. Please refer to the bindings defined in
>>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>>> +
>>> +Within the endpoint node the "remote-endpoint" and "data-lanes" properties
>>> +are mandatory.
>>> +Data lane reordering is not supported so the data lanes must be in order,
>>> +starting at 1. The number of data lanes should represent the number of
>>> +usable lanes for the hardware block. That may be limited by either the SoC 
>>> or
>>> +how the platform presents the interface, and the lower value must be used.
>>> +
>>> +Lane reordering is not supported on the clock lane either, so the optional
>>> +property "clock-lane" will implicitly be <0>.
>>> +Similarly lane inversion is not supported, therefore "lane-polarities" will
>>> +implicitly be <0 0 0 0 0>.
>>> +Neither of these values will be checked.
>>> +
>>> +Example:
>>> + csi1: csi1@7e801000 {
>>> + compatible = "brcm,bcm2835-unicam";
>>> + reg = <0x7e801000 0x800>,
>>> +   <0x7e802004 0x4>;
>>
>> sorry, i didn't noticed this before. I'm afraid this is using a small range 
>> of the CMI. Are there possible other users of this range? Does it make sense 
>> to handle this by a separate clock driver?
>
> CMI (Clock Manager Image) consists of a total of 4 registers.
> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and
> inversion of the clock and data lanes (2 data lanes available on
> CAM0).
> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and
> inversion of the clock and data lanes (4 data lanes available on
> CAM1).
> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.
> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The
> default value is the required value. Nothing touches it that I can
> find.

Yeah, my conclusion previously was that it's appropriate to consider
this register as part of the unicam instance.  No other HW block could
want to talk to it.


signature.asc
Description: PGP signature

[PATCH] [media] spca500: Use common error handling code in spca500_synch310()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 22 Sep 2017 18:45:07 +0200

Adjust a jump target so that a bit of exception handling can be better
reused at the end of this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/gspca/spca500.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/media/usb/gspca/spca500.c 
b/drivers/media/usb/gspca/spca500.c
index da2d9027914c..1f224f5e5b19 100644
--- a/drivers/media/usb/gspca/spca500.c
+++ b/drivers/media/usb/gspca/spca500.c
@@ -501,7 +501,6 @@ static int spca500_full_reset(struct gspca_dev *gspca_dev)
 static int spca500_synch310(struct gspca_dev *gspca_dev)
 {
-   if (usb_set_interface(gspca_dev->dev, gspca_dev->iface, 0) < 0) {
-   PERR("Set packet size: set interface error");
-   goto error;
-   }
+   if (usb_set_interface(gspca_dev->dev, gspca_dev->iface, 0) < 0)
+   goto report_failure;
+
spca500_ping310(gspca_dev);
@@ -514,12 +513,12 @@ static int spca500_synch310(struct gspca_dev *gspca_dev)
/* Windoze use pipe with altsetting 6 why 7 here */
-   if (usb_set_interface(gspca_dev->dev,
-   gspca_dev->iface,
-   gspca_dev->alt) < 0) {
-   PERR("Set packet size: set interface error");
-   goto error;
-   }
+   if (usb_set_interface(gspca_dev->dev, gspca_dev->iface, gspca_dev->alt)
+   < 0)
+   goto report_failure;
+
return 0;
-error:
+
+report_failure:
+   PERR("Set packet size: set interface error");
return -EBUSY;
 }
 
-- 
2.14.1

Re: [PATCH] [media] spca500: Use common error handling code in spca500_synch310()

[Julia Lawall]

On Fri, 22 Sep 2017, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Fri, 22 Sep 2017 18:45:07 +0200
>
> Adjust a jump target so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/media/usb/gspca/spca500.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/usb/gspca/spca500.c 
> b/drivers/media/usb/gspca/spca500.c
> index da2d9027914c..1f224f5e5b19 100644
> --- a/drivers/media/usb/gspca/spca500.c
> +++ b/drivers/media/usb/gspca/spca500.c
> @@ -501,7 +501,6 @@ static int spca500_full_reset(struct gspca_dev *gspca_dev)
>  static int spca500_synch310(struct gspca_dev *gspca_dev)
>  {
> - if (usb_set_interface(gspca_dev->dev, gspca_dev->iface, 0) < 0) {
> - PERR("Set packet size: set interface error");
> - goto error;
> - }
> + if (usb_set_interface(gspca_dev->dev, gspca_dev->iface, 0) < 0)
> + goto report_failure;
> +
>   spca500_ping310(gspca_dev);
> @@ -514,12 +513,12 @@ static int spca500_synch310(struct gspca_dev *gspca_dev)
>   /* Windoze use pipe with altsetting 6 why 7 here */
> - if (usb_set_interface(gspca_dev->dev,
> - gspca_dev->iface,
> - gspca_dev->alt) < 0) {
> - PERR("Set packet size: set interface error");
> - goto error;
> - }
> + if (usb_set_interface(gspca_dev->dev, gspca_dev->iface, gspca_dev->alt)
> + < 0)
> + goto report_failure;
> +
>   return 0;
> -error:
> +
> +report_failure:
> + PERR("Set packet size: set interface error");
>   return -EBUSY;
>  }

Why change the label name?  They are both equally uninformative.

julia

Re: [PATCH v2 0/4] BCM283x Camera Receiver driver

[Hans Verkuil]

On 22/09/17 18:31, Dave Stevenson wrote:
> On 22 September 2017 at 12:00, Hans Verkuil  wrote:
>> On 13/09/17 17:49, Dave Stevenson wrote:
>>> OV5647
>>>
>>> v4l2-compliance SHA   : f6ecbc90656815d91dc6ba90aac0ad8193a14b38
>>>
>>> Driver Info:
>>> Driver name   : unicam
>>> Card type : unicam
>>> Bus info  : platform:unicam 3f801000.csi1
>>> Driver version: 4.13.0
>>> Capabilities  : 0x8521
>>> Video Capture
>>> Read/Write
>>> Streaming
>>> Extended Pix Format
>>> Device Capabilities
>>> Device Caps   : 0x0521
>>> Video Capture
>>> Read/Write
>>> Streaming
>>> Extended Pix Format
>>>
>>> Compliance test for device /dev/video0 (not using libv4l2):
>>>
>>> Required ioctls:
>>> test VIDIOC_QUERYCAP: OK
>>>
>>> Allow for multiple opens:
>>> test second video open: OK
>>> test VIDIOC_QUERYCAP: OK
>>> test VIDIOC_G/S_PRIORITY: OK
>>> test for unlimited opens: OK
>>>
>>> Debug ioctls:
>>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>>> test VIDIOC_LOG_STATUS: OK
>>>
>>> Input ioctls:
>>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>>> test VIDIOC_G/S/ENUMINPUT: OK
>>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>>> Inputs: 1 Audio Inputs: 0 Tuners: 0
>>>
>>> Output ioctls:
>>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>>
>>> Input/Output configuration ioctls:
>>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>>
>>> Test input 0:
>>>
>>> Control ioctls:
>>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
>>> test VIDIOC_QUERYCTRL: OK
>>> test VIDIOC_G/S_CTRL: OK
>>> fail: v4l2-test-controls.cpp(587): g_ext_ctrls does not
>>> support count == 0
>>
>> Huh. The issue here is that there are no controls at all, but the
>> control API is present. The class_check() function in v4l2-ctrls.c expects
>> that there are controls and if not it returns -EINVAL, causing this test
>> to fail.
>>
>> Try to apply this patch:
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index dd1db678718c..4e53a8654690 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -2818,7 +2818,7 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler 
>> *hdl,
>>  static int class_check(struct v4l2_ctrl_handler *hdl, u32 which)
>>  {
>> if (which == 0 || which == V4L2_CTRL_WHICH_DEF_VAL)
>> -   return list_empty(>ctrl_refs) ? -EINVAL : 0;
>> +   return 0;
>> return find_ref_lock(hdl, which | 1) ? 0 : -EINVAL;
>>  }
>>
>>
>> and see if it will pass the compliance test. There may be other issues.
>> I think that the compliance test should handle the case where there are no
>> controls, so this is a good test.
> 
> Fails.
> fail: v4l2-test-controls.cpp(589): g_ext_ctrls worked even
> when no controls are present
> test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL

Try this patch:

-
diff --git a/utils/v4l2-compliance/v4l2-test-controls.cpp 
b/utils/v4l2-compliance/v4l2-test-controls.cpp
index 7514459f..508daf05 100644
--- a/utils/v4l2-compliance/v4l2-test-controls.cpp
+++ b/utils/v4l2-compliance/v4l2-test-controls.cpp
@@ -585,8 +585,6 @@ int testExtendedControls(struct node *node)
return ret;
if (ret)
return fail("g_ext_ctrls does not support count == 0\n");
-   if (node->controls.empty())
-   return fail("g_ext_ctrls worked even when no controls are 
present\n");
if (ctrls.which)
return fail("field which changed\n");
if (ctrls.count)
@@ -600,8 +598,6 @@ int testExtendedControls(struct node *node)
return ret;
if (ret)
return fail("try_ext_ctrls does not support count == 0\n");
-   if (node->controls.empty())
-   return fail("try_ext_ctrls worked even when no controls are 
present\n");
if (ctrls.which)
return fail("field which changed\n");
if (ctrls.count)
@@ -687,6 +683,8 @@ int testExtendedControls(struct node *node)
}

ctrls.which = 0;
+   ctrls.count = 1;
+   ctrls.controls = 
ctrl.id = 0;
ctrl.size = 0;

Re: [media] spca500: Use common error handling code in spca500_synch310()

[Julia Lawall]

On Fri, 22 Sep 2017, SF Markus Elfring wrote:

> >>return 0;
> >> -error:
> >> +
> >> +report_failure:
> >> +  PERR("Set packet size: set interface error");
> >>return -EBUSY;
> >>  }
> >
> > Why change the label name?
>
> I find the suggested variant a bi better.
>
>
> > They are both equally uninformative.
>
> Which identifier would you find appropriate there?

error was fine.

julia

Re: [media] spca500: Use common error handling code in spca500_synch310()

[SF Markus Elfring]

>>  return 0;
>> -error:
>> +
>> +report_failure:
>> +PERR("Set packet size: set interface error");
>>  return -EBUSY;
>>  }
> 
> Why change the label name?

I find the suggested variant a bi better.


> They are both equally uninformative.

Which identifier would you find appropriate there?

Regards,
Markus

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

[Stefan Wahren]

Hi Dave,

> Dave Stevenson  hat am 22. September 2017 um 
> 18:07 geschrieben:
> 
> 
> Hi Stefan
> 
> On 22 September 2017 at 07:45, Stefan Wahren  wrote:
> > Hi Dave,
> >
> >> Dave Stevenson  hat am 20. September 2017 
> >> um 18:07 geschrieben:
> >>
> >>
> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral
> >> (known as Unicam) on BCM283x SoCs.
> >>
> >> Signed-off-by: Dave Stevenson 
> >> ---
> >>
> >> Changes since v2
> >> - Removed all references to Linux drivers.
> >> - Reworded section about disabling the firmware driver.
> >> - Renamed clock from "lp_clock" to "lp" in description and example.
> >> - Referred to video-interfaces.txt and stated requirements on 
> >> remote-endpoint
> >>   and data-lanes.
> >> - Corrected typo in example from csi to csi1.
> >> - Removed unnecessary #address-cells and #size-cells in example.
> >> - Removed setting of status from the example.
> >>
> >>  .../devicetree/bindings/media/bcm2835-unicam.txt   | 85 
> >> ++
> >>  1 file changed, 85 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/media/bcm2835-unicam.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt 
> >> b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
> >> new file mode 100644
> >> index 000..7714fb3
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
> >> @@ -0,0 +1,85 @@
> >> +Broadcom BCM283x Camera Interface (Unicam)
> >> +--
> >> +
> >> +The Unicam block on BCM283x SoCs is the receiver for either
> >> +CSI-2 or CCP2 data from image sensors or similar devices.
> >> +
> >> +The main platform using this SoC is the Raspberry Pi family of boards.
> >> +On the Pi the VideoCore firmware can also control this hardware block,
> >> +and driving it from two different processors will cause issues.
> >> +To avoid this, the firmware checks the device tree configuration
> >> +during boot. If it finds device tree nodes called csi0 or csi1 then
> >> +it will stop the firmware accessing the block, and it can then
> >> +safely be used via the device tree binding.
> >> +
> >> +Required properties:
> >> +===
> >> +- compatible : must be "brcm,bcm2835-unicam".
> >> +- reg: physical base address and length of the register 
> >> sets for the
> >> +   device.
> >> +- interrupts : should contain the IRQ line for this Unicam instance.
> >> +- clocks : list of clock specifiers, corresponding to entries in
> >> +   clock-names property.
> >> +- clock-names: must contain an "lp" entry, matching entries in the
> >> +   clocks property.
> >> +
> >> +Unicam supports a single port node. It should contain one 'port' child 
> >> node
> >> +with child 'endpoint' node. Please refer to the bindings defined in
> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> >> +
> >> +Within the endpoint node the "remote-endpoint" and "data-lanes" properties
> >> +are mandatory.
> >> +Data lane reordering is not supported so the data lanes must be in order,
> >> +starting at 1. The number of data lanes should represent the number of
> >> +usable lanes for the hardware block. That may be limited by either the 
> >> SoC or
> >> +how the platform presents the interface, and the lower value must be used.
> >> +
> >> +Lane reordering is not supported on the clock lane either, so the optional
> >> +property "clock-lane" will implicitly be <0>.
> >> +Similarly lane inversion is not supported, therefore "lane-polarities" 
> >> will
> >> +implicitly be <0 0 0 0 0>.
> >> +Neither of these values will be checked.
> >> +
> >> +Example:
> >> + csi1: csi1@7e801000 {
> >> + compatible = "brcm,bcm2835-unicam";
> >> + reg = <0x7e801000 0x800>,
> >> +   <0x7e802004 0x4>;
> >
> > sorry, i didn't noticed this before. I'm afraid this is using a small range 
> > of the CMI. Are there possible other users of this range? Does it make 
> > sense to handle this by a separate clock driver?
> 
> CMI (Clock Manager Image) consists of a total of 4 registers.
> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and
> inversion of the clock and data lanes (2 data lanes available on
> CAM0).
> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and
> inversion of the clock and data lanes (4 data lanes available on
> CAM1).
> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.
> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The
> default value is the required value. Nothing touches it that I can
> find.

thanks for providing these information.

> 
> The range listed only covers the one register associated with that
> Unicam instance, so no other users. The other two aren't touched.
> 

Re: [media] spca500: Use common error handling code in spca500_synch310()

[SF Markus Elfring]

>>> They are both equally uninformative.
>>
>> Which identifier would you find appropriate there?
> 
> error was fine.

How do the different views fit together?

Regards,
Markus

[PATCH] gspca: Convert PERR to gspca_err

[Joe Perches]

Use a more typical kernel logging style.

The current macro hides the gspca_dev argument so add it to the
macro uses instead.

Miscellanea:

o Add missing '\n' terminations to formats
o Realign arguments to open parenthesis

Signed-off-by: Joe Perches 
---
 drivers/media/usb/gspca/benq.c |  6 +--
 drivers/media/usb/gspca/conex.c|  6 +--
 drivers/media/usb/gspca/cpia1.c| 24 ++-
 drivers/media/usb/gspca/dtcs033.c  | 12 +++---
 drivers/media/usb/gspca/etoms.c|  4 +-
 drivers/media/usb/gspca/gl860/gl860.c  |  2 +-
 drivers/media/usb/gspca/gspca.c| 26 +++-
 drivers/media/usb/gspca/gspca.h|  4 +-
 drivers/media/usb/gspca/jeilinj.c  |  2 +-
 drivers/media/usb/gspca/konica.c   | 26 ++--
 drivers/media/usb/gspca/m5602/m5602_core.c |  2 +-
 drivers/media/usb/gspca/mr97310a.c |  6 +--
 drivers/media/usb/gspca/ov519.c| 65 --
 drivers/media/usb/gspca/ov534.c|  4 +-
 drivers/media/usb/gspca/pac7302.c  |  2 +-
 drivers/media/usb/gspca/pac7311.c  |  2 +-
 drivers/media/usb/gspca/sn9c2028.c |  4 +-
 drivers/media/usb/gspca/sonixj.c   |  4 +-
 drivers/media/usb/gspca/spca1528.c |  4 +-
 drivers/media/usb/gspca/spca500.c  | 36 -
 drivers/media/usb/gspca/spca501.c  |  4 +-
 drivers/media/usb/gspca/spca505.c  |  2 +-
 drivers/media/usb/gspca/spca508.c  |  3 +-
 drivers/media/usb/gspca/spca561.c  |  2 +-
 drivers/media/usb/gspca/sq905.c|  2 +-
 drivers/media/usb/gspca/sq905c.c   |  6 +--
 drivers/media/usb/gspca/sq930x.c   |  2 +-
 drivers/media/usb/gspca/stv0680.c  | 16 
 drivers/media/usb/gspca/stv06xx/stv06xx.c  | 10 ++---
 drivers/media/usb/gspca/sunplus.c  |  2 +-
 drivers/media/usb/gspca/touptek.c  | 38 +
 drivers/media/usb/gspca/w996Xcf.c  |  2 +-
 32 files changed, 174 insertions(+), 156 deletions(-)

diff --git a/drivers/media/usb/gspca/benq.c b/drivers/media/usb/gspca/benq.c
index 60a728203b3b..b5955bf0d0fc 100644
--- a/drivers/media/usb/gspca/benq.c
+++ b/drivers/media/usb/gspca/benq.c
@@ -180,9 +180,9 @@ static void sd_isoc_irq(struct urb *urb)
/* check the packet status and length */
if (urb0->iso_frame_desc[i].actual_length != SD_PKT_SZ
|| urb->iso_frame_desc[i].actual_length != SD_PKT_SZ) {
-   PERR("ISOC bad lengths %d / %d",
-   urb0->iso_frame_desc[i].actual_length,
-   urb->iso_frame_desc[i].actual_length);
+   gspca_err(gspca_dev, "ISOC bad lengths %d / %d\n",
+ urb0->iso_frame_desc[i].actual_length,
+ urb->iso_frame_desc[i].actual_length);
gspca_dev->last_packet_type = DISCARD_PACKET;
continue;
}
diff --git a/drivers/media/usb/gspca/conex.c b/drivers/media/usb/gspca/conex.c
index bdcdf7999c56..0223b33156dd 100644
--- a/drivers/media/usb/gspca/conex.c
+++ b/drivers/media/usb/gspca/conex.c
@@ -70,7 +70,7 @@ static void reg_r(struct gspca_dev *gspca_dev,
struct usb_device *dev = gspca_dev->dev;
 
if (len > USB_BUF_SZ) {
-   PERR("reg_r: buffer overflow\n");
+   gspca_err(gspca_dev, "reg_r: buffer overflow\n");
return;
}
 
@@ -109,7 +109,7 @@ static void reg_w(struct gspca_dev *gspca_dev,
struct usb_device *dev = gspca_dev->dev;
 
if (len > USB_BUF_SZ) {
-   PERR("reg_w: buffer overflow\n");
+   gspca_err(gspca_dev, "reg_w: buffer overflow\n");
return;
}
PDEBUG(D_USBO, "reg write [%02x] = %02x..", index, *buffer);
@@ -683,7 +683,7 @@ static void cx11646_jpeg(struct gspca_dev*gspca_dev)
reg_w_val(gspca_dev, 0x0053, 0x00);
} while (--retry);
if (retry == 0)
-   PERR("Damned Errors sending jpeg Table");
+   gspca_err(gspca_dev, "Damned Errors sending jpeg Table\n");
/* send the qtable now */
reg_r(gspca_dev, 0x0001, 1);/* -> 0x18 */
length = 8;
diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c
index e91d00762e94..99b456d64729 100644
--- a/drivers/media/usb/gspca/cpia1.c
+++ b/drivers/media/usb/gspca/cpia1.c
@@ -419,7 +419,8 @@ static int cpia_usb_transferCmd(struct gspca_dev 
*gspca_dev, u8 *command)
pipe = usb_sndctrlpipe(gspca_dev->dev, 0);
requesttype = USB_TYPE_VENDOR | USB_RECIP_DEVICE;
} else {
-   PERR("Unexpected first byte of command: %x", command[0]);
+   gspca_err(gspca_dev, "Unexpected first byte of command: %x\n",
+ 

Re: [media] spca500: Use common error handling code in spca500_synch310()

[Joe Perches]

On Fri, 2017-09-22 at 19:46 +0200, SF Markus Elfring wrote:
> > > > They are both equally uninformative.
> > > 
> > > Which identifier would you find appropriate there?
> > 
> > error was fine.
> 
> How do the different views fit together?

Markus, please respect what others tell you because
your coding style "taste" could be improved.

Re: [media] spca500: Use common error handling code in spca500_synch310()

[Daniele Nicolodi]

On 9/22/17 11:46 AM, SF Markus Elfring wrote:
 They are both equally uninformative.
>>>
>>> Which identifier would you find appropriate there?
>>
>> error was fine.
> 
> How do the different views fit together?

You want to change something.  Changing something requires to spend
energy.  You need to to justify why spending that energy is a good
thing.  No one needs to argue about keeping it the way it is.

What about stopping changing code for the sake of having one more patch
accepted in the kernel?  I don't see any improvement brought by the
proposed change, other than making the code harder to read.  I find goto
statements hard to read, because they inherently make some information
non local.  They are justified in error path handling, if the error path
only unwinds what the function did early on.  That's not the case here.

The same applies to dozens of patches you proposed recently.

By the way, there may be some useful absent minded code churn of the
king you like in that driver: I don't think the PERR macro is the
idiomatic way of doing logging.

Cheers,
Daniele