cron job: media_tree daily build: ERRORS

[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:   Fri Mar 31 05:00:16 CEST 2017
media-tree git hash:c3d4fb0fb41f4b5eafeee51173c14e50be12f839
media_build git hash:   bc4c2a205c087c8deff3cd14ed663c4767dd2016
v4l-utils git hash: 984caeac9a41f8d4f636b933dfba4f29c5257f96
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: 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: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
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-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
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-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Helen Koike]

On 2017-03-30 11:39 PM, Helen Koike wrote:

Hi Laurent,

Thanks for reviewing

On 2017-03-30 04:56 PM, Laurent Pinchart wrote:

Hi Helen,

Thank you for the patch.

On Thursday 30 Mar 2017 13:02:17 Helen Koike wrote:

Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
used when no inputs are available in the device

Signed-off-by: Helen Koike 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
 include/media/v4l2-ioctl.h   | 26 ++
 include/uapi/linux/videodev2.h   |  1 +
 3 files changed, 54 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct
video_device
*vdev, unsigned cmd) return vdev->lock;
 }

+int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
+  struct v4l2_input *i)
+{
+if (i->index > 0)
+return -EINVAL;
+
+memset(i, 0, sizeof(*i));
+i->type = V4L2_INPUT_TYPE_DEFAULT;
+strlcpy(i->name, "Default", sizeof(i->name));
+
+return 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);


V4L2 tends to use EXPORT_SYMBOL_GPL.


The whole v4l2-ioctl.c file is using EXPORT_SYMBOL instead of
EXPORT_SYMBOL_GPL, should we change it all to EXPORT_SYMBOL_GPL then (in
another patch) ?



What would you think about calling those default functions directly
from the
core when the input ioctl handlers are not set ? You wouldn't need to
modify
drivers.


Sure, I'll add them in ops inside __video_register_device when it
validates the ioctls


I just realize I can not simply override struct v4l2_ioctl_ops as it is 
declared as a const inside strut video_device. I'll call those default 
functions only when the ioctls are handled to not modify vdev->ops.







+
+int v4l2_ioctl_g_input_default(struct file *file, void *priv,
unsigned int
*i) +{
+*i = 0;
+return 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
+
+int v4l2_ioctl_s_input_default(struct file *file, void *priv,
unsigned int
i) +{
+return i ? -EINVAL : 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
+
 /* Common ioctl debug function. This function can be used by
external ioctl messages as well as internal V4L ioctl */
 void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 6cd94e5..accc470 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -652,6 +652,32 @@ struct video_device;
  */
 struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev,
unsigned int
cmd);

+
+/**
+ * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for
VIDIOC_ENUM_INPUT
ioctl + *
+ * Plug this function in vidioc_enum_input field of the struct
v4l2_ioctl_ops to + * enumerate a single input as
V4L2_INPUT_TYPE_DEFAULT
+ */
+int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
+  struct v4l2_input *i);
+
+/**
+ * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT
ioctl
+ *
+ * Plug this function in vidioc_g_input field of the struct
v4l2_ioctl_ops
+ * when using v4l2_ioctl_enum_input_default
+ */
+int v4l2_ioctl_g_input_default(struct file *file, void *priv,
unsigned int
*i); +
+/**
+ * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT
ioctl
+ *
+ * Plug this function in vidioc_s_input field of the struct
v4l2_ioctl_ops
+ * when using v4l2_ioctl_enum_input_default
+ */
+int v4l2_ioctl_s_input_default(struct file *file, void *priv,
unsigned int
i); +
 /* names for fancy debug output */
 extern const char *v4l2_field_names[];
 extern const char *v4l2_type_names[];
diff --git a/include/uapi/linux/videodev2.h
b/include/uapi/linux/videodev2.h
index 316be62..c10bbde 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1477,6 +1477,7 @@ struct v4l2_input {
 };

 /*  Values for the 'type' field */
+#define V4L2_INPUT_TYPE_DEFAULT0
 #define V4L2_INPUT_TYPE_TUNER1
 #define V4L2_INPUT_TYPE_CAMERA2
 #define V4L2_INPUT_TYPE_TOUCH3




Helen


Helen

[PATCH] treewide: Correct diffrent[iate] and banlance typos

[Joe Perches]

Add these misspellings to scripts/spelling.txt too

Signed-off-by: Joe Perches 
---
 drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h | 2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c  | 2 +-
 drivers/net/ethernet/hisilicon/hns/hns_enet.c   | 2 +-
 drivers/net/ethernet/qlogic/qed/qed_int.c   | 2 +-
 drivers/net/ethernet/qlogic/qed/qed_main.c  | 2 +-
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 2 +-
 include/linux/mlx4/device.h | 2 +-
 scripts/spelling.txt| 3 +++
 8 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h 
b/drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h
index 354ec07eae87..23ae72468025 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h
+++ b/drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h
@@ -70,7 +70,7 @@
 * (3) both long and short but short preferred and long only when necesarry
 *
 * These modes must be selected compile time via compile switches.
-* Compile switch settings for the diffrent modes:
+* Compile switch settings for the different modes:
 * (1) DRXDAPFASI_LONG_ADDR_ALLOWED=0, DRXDAPFASI_SHORT_ADDR_ALLOWED=1
 * (2) DRXDAPFASI_LONG_ADDR_ALLOWED=1, DRXDAPFASI_SHORT_ADDR_ALLOWED=0
 * (3) DRXDAPFASI_LONG_ADDR_ALLOWED=1, DRXDAPFASI_SHORT_ADDR_ALLOWED=1
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
index cea6bdcde33f..8baf9d3eb4b1 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
@@ -1591,7 +1591,7 @@ static int __bnx2x_vlan_mac_execute_step(struct bnx2x *bp,
if (rc != 0) {
__bnx2x_vlan_mac_h_pend(bp, o, *ramrod_flags);
 
-   /* Calling function should not diffrentiate between this case
+   /* Calling function should not differentiate between this case
 * and the case in which there is already a pending ramrod
 */
rc = 1;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index fca37e2c7f01..e70324f4fe84 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -1207,7 +1207,7 @@ static void hns_set_irq_affinity(struct hns_nic_priv 
*priv)
if (!alloc_cpumask_var(&mask, GFP_KERNEL))
return;
 
-   /*diffrent irq banlance for 16core and 32core*/
+   /* different irq balance for 16core and 32core */
if (h->q_num == num_possible_cpus()) {
for (i = 0; i < h->q_num * 2; i++) {
rd = &priv->ring_data[i];
diff --git a/drivers/net/ethernet/qlogic/qed/qed_int.c 
b/drivers/net/ethernet/qlogic/qed/qed_int.c
index 84310b60849b..c6b348f00e7b 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_int.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_int.c
@@ -3057,7 +3057,7 @@ int qed_int_igu_read_cam(struct qed_hwfn *p_hwfn, struct 
qed_ptt *p_ptt)
 
/* There's a possibility the igu_sb_cnt_iov doesn't properly reflect
 * the number of VF SBs [especially for first VF on engine, as we can't
-* diffrentiate between empty entries and its entries].
+* differentiate between empty entries and its entries].
 * Since we don't really support more SBs than VFs today, prevent any
 * such configuration by sanitizing the number of SBs to equal the
 * number of VFs.
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c 
b/drivers/net/ethernet/qlogic/qed/qed_main.c
index d4edb993b1b0..b595f7dd4a58 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -951,7 +951,7 @@ static int qed_slowpath_start(struct qed_dev *cdev,
if (rc)
goto err2;
 
-   /* First Dword used to diffrentiate between various sources */
+   /* First Dword used to differentiate between various sources */
data = cdev->firmware->data + sizeof(u32);
 
qed_dbg_pf_init(cdev);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 18fc6e62ca41..a69774b19712 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -625,7 +625,7 @@ int qed_iov_hw_info(struct qed_hwfn *p_hwfn)
 *  - If !ARI, VFs would start on next device.
 *so offset - (256 - pf_id) would provide the number.
 * Utilize the fact that (256 - pf_id) is achieved only by later
-* to diffrentiate between the two.
+* to differentiate between the two.
 */
 
if (p_hwfn->cdev->p_iov_info->offset < (256 - p_hwfn->abs_pf_id)) {
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 1beb1ec2fbdf..eb1a51a6617b 100644
--- a/include/linux/mlx4/

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Helen Koike]

Hi Laurent,

Thanks for reviewing

On 2017-03-30 04:56 PM, Laurent Pinchart wrote:

Hi Helen,

Thank you for the patch.

On Thursday 30 Mar 2017 13:02:17 Helen Koike wrote:

Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
used when no inputs are available in the device

Signed-off-by: Helen Koike 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
 include/media/v4l2-ioctl.h   | 26 ++
 include/uapi/linux/videodev2.h   |  1 +
 3 files changed, 54 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct video_device
*vdev, unsigned cmd) return vdev->lock;
 }

+int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
+ struct v4l2_input *i)
+{
+   if (i->index > 0)
+   return -EINVAL;
+
+   memset(i, 0, sizeof(*i));
+   i->type = V4L2_INPUT_TYPE_DEFAULT;
+   strlcpy(i->name, "Default", sizeof(i->name));
+
+   return 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);


V4L2 tends to use EXPORT_SYMBOL_GPL.


The whole v4l2-ioctl.c file is using EXPORT_SYMBOL instead of 
EXPORT_SYMBOL_GPL, should we change it all to EXPORT_SYMBOL_GPL then (in 
another patch) ?




What would you think about calling those default functions directly from the
core when the input ioctl handlers are not set ? You wouldn't need to modify
drivers.


Sure, I'll add them in ops inside __video_register_device when it 
validates the ioctls





+
+int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int
*i) +{
+   *i = 0;
+   return 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
+
+int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int
i) +{
+   return i ? -EINVAL : 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
+
 /* Common ioctl debug function. This function can be used by
external ioctl messages as well as internal V4L ioctl */
 void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 6cd94e5..accc470 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -652,6 +652,32 @@ struct video_device;
  */
 struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned int
cmd);

+
+/**
+ * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for VIDIOC_ENUM_INPUT
ioctl + *
+ * Plug this function in vidioc_enum_input field of the struct
v4l2_ioctl_ops to + * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT
+ */
+int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
+ struct v4l2_input *i);
+
+/**
+ * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT ioctl
+ *
+ * Plug this function in vidioc_g_input field of the struct v4l2_ioctl_ops
+ * when using v4l2_ioctl_enum_input_default
+ */
+int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int
*i); +
+/**
+ * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT ioctl
+ *
+ * Plug this function in vidioc_s_input field of the struct v4l2_ioctl_ops
+ * when using v4l2_ioctl_enum_input_default
+ */
+int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int
i); +
 /* names for fancy debug output */
 extern const char *v4l2_field_names[];
 extern const char *v4l2_type_names[];
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 316be62..c10bbde 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1477,6 +1477,7 @@ struct v4l2_input {
 };

 /*  Values for the 'type' field */
+#define V4L2_INPUT_TYPE_DEFAULT0
 #define V4L2_INPUT_TYPE_TUNER  1
 #define V4L2_INPUT_TYPE_CAMERA 2
 #define V4L2_INPUT_TYPE_TOUCH  3




Helen

[PATCH 2/2 V2] staging: atomisp: use local variable to reduce the number of reference

[Daeseok Youn]

Define new local variable to reduce the number of reference.
The new local variable is added to save the addess of dfs
and used in atomisp_freq_scaling() function.

Signed-off-by: Daeseok Youn 
---
V2: this patch was rebased since the patch 1/2 was improved.

 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   | 37 --
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 87224d6..9f4041a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -251,6 +251,7 @@ int atomisp_freq_scaling(struct atomisp_device *isp,
 {
/* FIXME! Only use subdev[0] status yet */
struct atomisp_sub_device *asd = &isp->asd[0];
+   const struct atomisp_dfs_config *dfs;
unsigned int new_freq;
struct atomisp_freq_scaling_rule curr_rules;
int i, ret;
@@ -264,20 +265,22 @@ int atomisp_freq_scaling(struct atomisp_device *isp,
if (ATOMISP_IS_CHT(isp) && ATOMISP_USE_YUVPP(asd))
isp->dfs = &dfs_config_cht_soc;
 
-   if (isp->dfs->lowest_freq == 0 || isp->dfs->max_freq_at_vmin == 0 ||
-   isp->dfs->highest_freq == 0 || isp->dfs->dfs_table_size == 0 ||
-   !isp->dfs->dfs_table) {
+   dfs = isp->dfs;
+
+   if (dfs->lowest_freq == 0 || dfs->max_freq_at_vmin == 0 ||
+   dfs->highest_freq == 0 || dfs->dfs_table_size == 0 ||
+   !dfs->dfs_table) {
dev_err(isp->dev, "DFS configuration is invalid.\n");
return -EINVAL;
}
 
if (mode == ATOMISP_DFS_MODE_LOW) {
-   new_freq = isp->dfs->lowest_freq;
+   new_freq = dfs->lowest_freq;
goto done;
}
 
if (mode == ATOMISP_DFS_MODE_MAX) {
-   new_freq = isp->dfs->highest_freq;
+   new_freq = dfs->highest_freq;
goto done;
}
 
@@ -303,26 +306,26 @@ int atomisp_freq_scaling(struct atomisp_device *isp,
}
 
/* search for the target frequency by looping freq rules*/
-   for (i = 0; i < isp->dfs->dfs_table_size; i++) {
-   if (curr_rules.width != isp->dfs->dfs_table[i].width &&
-   isp->dfs->dfs_table[i].width != ISP_FREQ_RULE_ANY)
+   for (i = 0; i < dfs->dfs_table_size; i++) {
+   if (curr_rules.width != dfs->dfs_table[i].width &&
+   dfs->dfs_table[i].width != ISP_FREQ_RULE_ANY)
continue;
-   if (curr_rules.height != isp->dfs->dfs_table[i].height &&
-   isp->dfs->dfs_table[i].height != ISP_FREQ_RULE_ANY)
+   if (curr_rules.height != dfs->dfs_table[i].height &&
+   dfs->dfs_table[i].height != ISP_FREQ_RULE_ANY)
continue;
-   if (curr_rules.fps != isp->dfs->dfs_table[i].fps &&
-   isp->dfs->dfs_table[i].fps != ISP_FREQ_RULE_ANY)
+   if (curr_rules.fps != dfs->dfs_table[i].fps &&
+   dfs->dfs_table[i].fps != ISP_FREQ_RULE_ANY)
continue;
-   if (curr_rules.run_mode != isp->dfs->dfs_table[i].run_mode &&
-   isp->dfs->dfs_table[i].run_mode != ISP_FREQ_RULE_ANY)
+   if (curr_rules.run_mode != dfs->dfs_table[i].run_mode &&
+   dfs->dfs_table[i].run_mode != ISP_FREQ_RULE_ANY)
continue;
break;
}
 
-   if (i == isp->dfs->dfs_table_size)
-   new_freq = isp->dfs->max_freq_at_vmin;
+   if (i == dfs->dfs_table_size)
+   new_freq = dfs->max_freq_at_vmin;
else
-   new_freq = isp->dfs->dfs_table[i].isp_freq;
+   new_freq = dfs->dfs_table[i].isp_freq;
 
 done:
dev_dbg(isp->dev, "DFS target frequency=%d.\n", new_freq);
-- 
2.7.4

[PATCH 1/2 V2] staging: atomisp: simplify the if condition in atomisp_freq_scaling()

[Daeseok Youn]

The condition line in if-statement is needed to be shorthen to
improve readability.

Add a new definition to check the CHT with atomisp_device structure.

Signed-off-by: Daeseok Youn 
---
V2: replace the assigment line with macro to check CHT type.

 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c  | 3 +--
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h | 4 
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 94bc793..87224d6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -261,8 +261,7 @@ int atomisp_freq_scaling(struct atomisp_device *isp,
return -EINVAL;
}
 
-   if ((isp->pdev->device & ATOMISP_PCI_DEVICE_SOC_MASK) ==
-   ATOMISP_PCI_DEVICE_SOC_CHT && ATOMISP_USE_YUVPP(asd))
+   if (ATOMISP_IS_CHT(isp) && ATOMISP_USE_YUVPP(asd))
isp->dfs = &dfs_config_cht_soc;
 
if (isp->dfs->lowest_freq == 0 || isp->dfs->max_freq_at_vmin == 0 ||
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
index d366713..97dc5f88 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
@@ -72,6 +72,10 @@
 #define ATOMISP_PCI_DEVICE_SOC_ANN 0x1478
 #define ATOMISP_PCI_DEVICE_SOC_CHT 0x22b8
 
+#define ATOMISP_IS_CHT(isp) \
+   (((isp)->pdev->device & ATOMISP_PCI_DEVICE_SOC_MASK) == \
+   ATOMISP_PCI_DEVICE_SOC_CHT)
+
 #define ATOMISP_PCI_REV_MRFLD_A0_MAX   0
 #define ATOMISP_PCI_REV_BYT_A0_MAX 4
 
-- 
2.7.4

Re: [PATCH 01/22] driver-api/basics.rst: add device table header

[kbuild test robot]

Hi Mauro,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc4 next-20170330]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/driver-api-basics-rst-add-device-table-header/20170331-041911
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/linux/init.h:1: warning: no structured comments found
>> include/linux/mod_devicetable.h:676: warning: Excess 
>> struct/union/enum/typedef member 'ver_major' description in 
>> 'fsl_mc_device_id'
>> include/linux/mod_devicetable.h:676: warning: Excess 
>> struct/union/enum/typedef member 'ver_minor' description in 
>> 'fsl_mc_device_id'
   kernel/sched/core.c:2085: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2085: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   drivers/regulator/core.c:1467: warning: Excess function parameter 'ret' 
description in 'regulator_dev_lookup'
   include/drm/drm_drv.h:438: warning: No description found for parameter 'open'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'preclose'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'postclose'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'lastclose'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'debugfs_cleanup'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:438: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:438: warning: No description found for parameter 'name'
   include/drm/drm_d

Re: [PATCHv5 04/11] exynos_hdmi: add CEC notifier support

[Russell King - ARM Linux]

On Wed, Mar 29, 2017 at 04:15:36PM +0200, Hans Verkuil wrote:
> + cec_notifier_set_phys_addr(hdata->notifier,
> +cec_get_edid_phys_addr(edid));

This pattern causes problems - can we have the notifier taking the EDID
please, and stubs in cec-notifier.h to stub that out?

Maybe something like cec_notifier_set_phys_addr_from_edid(edid) ?

Having converted the tda998x code over to your new notifier, the 0-day
builder reported this tonight:

>> ERROR: "cec_get_edid_phys_addr" [drivers/gpu/drm/i2c/tda998x.ko] undefined!

which is caused exactly by this problem.  I can add #ifdefs into the
tda998x driver, but as you're already stubbing out
cec_notifier_set_phys_addr() in cec-notifier.h, it would be stupid to
have to resort to #ifdefs in driver code to solve this issue.

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCHv5 07/11] s5p-cec: add cec-notifier support, move out of staging

[Krzysztof Kozlowski]

On Wed, Mar 29, 2017 at 04:15:39PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> By using the CEC notifier framework there is no longer any reason
> to manually set the physical address. This was the one blocking
> issue that prevented this driver from going out of staging, so do
> this move as well.
> 
> Update the bindings documenting the new hdmi phandle and
> update exynos4.dtsi accordingly.
> 
> Tested with my Odroid U3.
> 
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> CC: linux-samsung-...@vger.kernel.org
> CC: Krzysztof Kozlowski 
> ---
>  drivers/media/platform/Kconfig | 18 +++
>  drivers/media/platform/Makefile|  1 +
>  .../media => media/platform}/s5p-cec/Makefile  |  0
>  .../platform}/s5p-cec/exynos_hdmi_cec.h|  0
>  .../platform}/s5p-cec/exynos_hdmi_cecctrl.c|  0
>  .../media => media/platform}/s5p-cec/regs-cec.h|  0
>  .../media => media/platform}/s5p-cec/s5p_cec.c | 35 
> ++
>  .../media => media/platform}/s5p-cec/s5p_cec.h |  3 ++
>  drivers/staging/media/Kconfig  |  2 --
>  drivers/staging/media/Makefile |  1 -
>  drivers/staging/media/s5p-cec/Kconfig  |  9 --
>  drivers/staging/media/s5p-cec/TODO |  7 -
>  12 files changed, 52 insertions(+), 24 deletions(-)
>  rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h 
> (100%)
>  rename drivers/{staging/media => 
> media/platform}/s5p-cec/exynos_hdmi_cecctrl.c (100%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
>  delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
>  delete mode 100644 drivers/staging/media/s5p-cec/TODO
> 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCHv5 06/11] s5p-cec.txt: document the HDMI controller phandle

[Krzysztof Kozlowski]

On Wed, Mar 29, 2017 at 04:15:38PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Update the bindings documenting the new hdmi phandle.
> 
> Signed-off-by: Hans Verkuil 
> CC: linux-samsung-...@vger.kernel.org
> CC: devicet...@vger.kernel.org
> CC: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCHv5 04/11] exynos_hdmi: add CEC notifier support

[Krzysztof Kozlowski]

On Wed, Mar 29, 2017 at 04:15:36PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Implement the CEC notifier support to allow CEC drivers to
> be informed when there is a new physical address.
> 
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 

Acked-by: Krzysztof Kozlowski 
(you still need Exynos DRM maintainer ack)

Best regards,
Krzysztof

Re: [PATCHv5 05/11] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi

[Krzysztof Kozlowski]

On Wed, Mar 29, 2017 at 04:15:37PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the
> s5p-cec driver to initialize the CEC notifier framework.
> 
> Tested with my Odroid U3.
> 
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> CC: linux-samsung-...@vger.kernel.org
> CC: devicet...@vger.kernel.org
> CC: Krzysztof Kozlowski 
> ---
>  arch/arm/boot/dts/exynos4.dtsi | 1 +
>  1 file changed, 1 insertion(+)
>

Thanks, applied. Now I noticed that you need it for maintaining the
bisectability for this driver (although it is a staging driver). In that
case, if anyone needs this as well then:


The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-dt-hdmi-cec-4.12

for you to fetch changes up to 192c1df4a75499a6ab70aca38c6a7e5e40013d77:

  ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi (2017-03-31 
00:21:18 +0300)


Add to hdmi-cec node a phandle to hdmi node for new hdmi-cec notifier.


Hans Verkuil (1):
  ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi

 arch/arm/boot/dts/exynos4.dtsi | 1 +
 1 file changed, 1 insertion(+)


Best regards,
Krzysztof

Re: [PATCH 9/9] kernel-api.rst: fix a series of errors when parsing C files

[Bjorn Helgaas]

On Thu, Mar 30, 2017 at 05:11:36PM -0300, Mauro Carvalho Chehab wrote:
> ./lib/string.c:134: WARNING: Inline emphasis start-string without end-string.
> ./mm/filemap.c:522: WARNING: Inline interpreted text or phrase reference 
> start-string without end-string.
> ./mm/filemap.c:1283: ERROR: Unexpected indentation.
> ./mm/filemap.c:3003: WARNING: Inline interpreted text or phrase reference 
> start-string without end-string.
> ./mm/vmalloc.c:1544: WARNING: Inline emphasis start-string without end-string.
> ./mm/page_alloc.c:4245: ERROR: Unexpected indentation.
> ./ipc/util.c:676: ERROR: Unexpected indentation.
> ./drivers/pci/irq.c:35: WARNING: Block quote ends without a blank line; 
> unexpected unindent.
> ./security/security.c:109: ERROR: Unexpected indentation.
> ./security/security.c:110: WARNING: Definition list ends without a blank 
> line; unexpected unindent.
> ./block/genhd.c:275: WARNING: Inline strong start-string without end-string.
> ./block/genhd.c:283: WARNING: Inline strong start-string without end-string.
> ./include/linux/clk.h:134: WARNING: Inline emphasis start-string without 
> end-string.
> ./include/linux/clk.h:134: WARNING: Inline emphasis start-string without 
> end-string.
> ./ipc/util.c:477: ERROR: Unknown target name: "s".
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Bjorn Helgaas# for drivers/pci/irq.c

> diff --git a/drivers/pci/irq.c b/drivers/pci/irq.c
> index 6684f153ab57..f9f2a0324ecc 100644
> --- a/drivers/pci/irq.c
> +++ b/drivers/pci/irq.c
> @@ -31,7 +31,7 @@ static void pci_note_irq_problem(struct pci_dev *pdev, 
> const char *reason)
>   * driver).
>   *
>   * Returns:
> - *  a suggestion for fixing it (although the driver is not required to
> + * a suggestion for fixing it (although the driver is not required to
>   * act on this).
>   */
>  enum pci_lost_interrupt_reason pci_lost_interrupt(struct pci_dev *pdev)

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Oliver Neukum]

Am Donnerstag, den 30.03.2017, 11:55 -0400 schrieb Alan Stern:
> 
> I'm pretty sure that usb-storage does not do this, at least, not when 
> operating in its normal Bulk-Only-Transport mode.  It never tries to 
> read the results of an earlier transfer after carrying out a later 
> transfer to any part of the same buffer.

The storage driver takes buffers as the block layer (or sg) provide
them, does it not?

Regards
Oliver

Re: [PATCHv5 00/11] video/exynos/sti/cec: add CEC notifier & use in drivers

[Krzysztof Kozlowski]

On Thu, Mar 30, 2017 at 09:47:00AM +0200, Daniel Vetter wrote:
> On Wed, Mar 29, 2017 at 09:59:34PM +0200, Hans Verkuil wrote:
> > Hi Daniel,
> > 
> > On 29/03/17 19:47, Daniel Vetter wrote:
> > > On Wed, Mar 29, 2017 at 04:15:32PM +0200, Hans Verkuil wrote:
> > >> From: Hans Verkuil 
> > >>
> > >> This patch series adds the CEC physical address notifier code, based on
> > >> Russell's code:
> > >>
> > >> https://patchwork.kernel.org/patch/9277043/
> > >>
> > >> It adds support for it to the exynos_hdmi drm driver, adds support for
> > >> it to the CEC framework and finally adds support to the s5p-cec driver,
> > >> which now can be moved out of staging.
> > >>
> > >> Also included is similar code for the STI platform, contributed by
> > >> Benjamin Gaignard.
> > >>
> > >> Tested the exynos code with my Odroid U3 exynos4 devboard.
> > >>
> > >> After discussions with Daniel Vetter and Russell King I have removed
> > >> the EDID/ELD/HPD connect/disconnect events from the notifier and now
> > >> just use it to report the CEC physical address. This also means that
> > >> it is now renamed to CEC notifier instead of HPD notifier and that
> > >> it is now in drivers/media. The block_notifier was dropped as well
> > >> and instead a simple callback is registered. This means that the
> > >> relationship between HDMI and CEC is now 1:1 and no longer 1:n, but
> > >> should this be needed in the future, then that can easily be added
> > >> back.
> > >>
> > >> Daniel, regarding your suggestions here:
> > >>
> > >> http://www.spinics.net/lists/dri-devel/msg133907.html
> > >>
> > >> this patch series maps to your mail above as follows:
> > >>
> > >> struct cec_pin == struct cec_notifier
> > >> cec_(un)register_pin == cec_notifier_get/put
> > >> cec_set_address == cec_notifier_set_phys_addr
> > >> cec_(un)register_callbacks == cec_notifier_(un)register
> > >>
> > >> Comments are welcome. I'd like to get this in for the 4.12 kernel as
> > >> this is a missing piece needed to integrate CEC drivers.
> > >>
> > >> Regards,
> > >>
> > >>  Hans
> > >>
> > >> Changes since v4:
> > >> - Dropped EDID/ELD/connect/disconnect support. Instead, just report the
> > >>   CEC physical address (and use INVALID when disconnecting).
> > >> - Since this is now completely CEC specific, move it to drivers/media
> > >>   and rename to cec-notifier.
> > >> - Drop block_notifier. Instead just set a callback for the notifier.
> > >> - Use 'hdmi-phandle' in the bindings for both exynos and sti. So no
> > >>   vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'.
> > >> - Make struct cec_notifier opaque. Add a helper function to get the
> > >>   physical address from a cec_notifier struct.
> > >> - Provide dummy functions in cec-notifier.h so it can be used when
> > >>   CONFIG_MEDIA_CEC_NOTIFIER is undefined.
> > >> - Don't select the CEC notifier in the HDMI drivers. It should only
> > >>   be enabled by actual CEC drivers.
> > > 
> > > I just quickly scaned through it, but this seems to address all my
> > > concerns fully. Thanks for respinning. On the entire pile (or just the
> > > core cec notifier bits):
> > > 
> > > Acked-by: Daniel Vetter 
> > 
> > Fantastic! Thank you very much for your comments.
> > 
> > One last question: the patches for drivers/gpu/drm: can they go through
> > the media subsystem or do you want to take them? They do depend on the first
> > two patches of this series (cec-edid and cec-notifier), so it is a bit more
> > coordination if they have to go through the drm subsystem.
> 
> Doesn't seem to touch anything where I expect conflicts, so as long as it
> shows up in linux-next timely I think that's good. Please poke driver
> maintainers for their ack though, but if they fail to respond within a few
> days you can take my ack for merging the entire pile through media.
> 
> Cheers, Daniel

Hi Hans,

I will take the exynos DTS patch through samsung-soc. If anyone needs it
for bisectability, I can provide a tag.

For the drm and media exynos code, I am not the one to ack.

Best regards,
Krzysztof

Re: [PATCH 2/2] [media] docs-rst: add V4L2_INPUT_TYPE_DEFAULT

[Sakari Ailus]

Hi Helen and others,

On Thu, Mar 30, 2017 at 01:02:18PM -0300, Helen Koike wrote:
> add documentation for V4L2_INPUT_TYPE_DEFAULT
> 
> Signed-off-by: Helen Koike 
> ---
>  Documentation/media/uapi/v4l/vidioc-enuminput.rst | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/vidioc-enuminput.rst 
> b/Documentation/media/uapi/v4l/vidioc-enuminput.rst
> index 17aaaf9..0237e10 100644
> --- a/Documentation/media/uapi/v4l/vidioc-enuminput.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-enuminput.rst
> @@ -112,6 +112,9 @@ at index zero, incrementing by one until the driver 
> returns ``EINVAL``.
>  :stub-columns: 0
>  :widths:   3 1 4
>  
> +* - ``V4L2_INPUT_TYPE_DEFAULT``
> +  - 0
> +  - This is the default value returned when no input is supported.
>  * - ``V4L2_INPUT_TYPE_TUNER``
>- 1
>- This input uses a tuner (RF demodulator).

What would you think of calling this input as "unknown" instead of
"default"? That's what an input which isn't really specified actually is.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Laurent Pinchart]

Hi Alan,

On Thursday 30 Mar 2017 11:55:18 Alan Stern wrote:
> On Thu, 30 Mar 2017, Mauro Carvalho Chehab wrote:
> > Em Thu, 30 Mar 2017 10:26:32 -0400 (EDT) Alan Stern escreveu:
> >> On Thu, 30 Mar 2017, Oliver Neukum wrote:
>  Btw, I'm a lot more concerned about USB storage drivers. When I was
>  discussing about this issue at the #raspberrypi-devel IRC channel,
>  someone complained that, after switching from the RPi downstream
>  Kernel to upstream, his USB data storage got corrupted. Well, if the
>  USB storage drivers also assume that the buffer can be continuous,
>  that can corrupt data.
> >>> 
> >>> They do assume that.
> >> 
> >> Wait a minute.  Where does that assumption occur?
> >> 
> >> And exactly what is the assumption?  Mauro wrote "the buffer can be
> >> continuous", but that is certainly not what he meant.
> > 
> > What I meant to say is that drivers like the uvcdriver (and maybe network
> > and usb-storage drivers) may allocate a big buffer and get data there on
> > some random order, e. g.:
> > 
> > int get_from_buf_pos(char *buf, int pos, int size)
> > {
> > /* or an equivalent call to usb_submit_urb() */
> > usb_control_msg(..., buf + pos, size, ...);
> > }
> > 
> > some_function ()
> > {
> > ...
> > 
> > chr *buf = kzalloc(4, GFP_KERNEL);
> > 
> > /*
> >  * Access the bytes at the array on a random order, with random size,
> >  * Like:
> >  */
> > get_from_buf_pos(buf, 2, 2);/* should read 0x56, 0x78 */
> > get_from_buf_pos(buf, 0, 2);/* should read 0x12, 0x34 */
> > 
> > /*
> >  * the expected value for the buffer would be:
> >  *  { 0x12, 0x34, 0x56, 0x78 }
> >  */
> > 
> > E. g. they assume that the transfer URB can work with any arbitrary
> > pointer and size, without needing of pre-align them.
> > 
> > This doesn't work with HCD drivers like dwc2, as each USB_IN operation
> > will actually write 4 bytes to the buffer.
> > 
> > So, what happens, instead, is that each data transfer will get four
> > bytes. Due to a hack inside dwc2, with checks if the transfer_buffer
> > is DWORD aligned. So, the first transfer will do what's expected: it will
> > read 4 bytes to a temporary buffer, allocated inside the driver,
> > copying just two bytes to buf. So, after the first read, the
> > 
> > buffer content will be:
> > buf = { 0x00, x00, 0x56, 0x78 }
> > 
> > But, on the second read, it won't be using any temporary
> > buffer. So, instead of reading a 16-bits word (0x5678),
> > it will actually read 32 bits, with 16-bits with some random value,
> > 
> > causing a buffer overflow. E. g. buffer content will now be:
> > buf = { 0x12, x34, 0xde, 0xad }
> > 
> > In other words, the second transfer corrupted the data from the
> > first transfer.
> 
> I'm pretty sure that usb-storage does not do this, at least, not when
> operating in its normal Bulk-Only-Transport mode.  It never tries to
> read the results of an earlier transfer after carrying out a later
> transfer to any part of the same buffer.

The uvcvideo driver does something similar. Given the size of the transfer a 
bounce buffer shouldn't affect performances. Handling this in the USB core 
sounds like the best solution to me.

-- 
Regards,

Laurent Pinchart

Re: dvb-tools: dvbv5-scan segfaults with DVB-T2 HD service that just started in Germany

[Mauro Carvalho Chehab]

Hi Gregor,

Em Wed, 29 Mar 2017 20:45:06 +0200
Gregor Jasny  escreveu:

> Hello Mauro & list,
> 
> could you please have a look at the dvbv5-scan crash report below?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859008
> 
> Is there anything else you need to debug this?

I'm able to reproduce it on a Debian machine here too, but so far,
I was unable to discover what's causing it. I'll try to find some time
to take a better look on it.

> 
> Thanks,
> Gregor
> 
> On 3/29/17 4:42 PM, Tino Mettler wrote:
> > 
> > $ gdb --args ./utils/dvb/dvbv5-scan ~/tmp/dvb-t2/init2 
> > GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later 
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from ./utils/dvb/dvbv5-scan...done.
> > (gdb) run
> > Starting program: /home/scorpion/build/9643/v4l-utils/utils/dvb/dvbv5-scan 
> > /home/scorpion/tmp/dvb-t2/init2
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > Scanning frequency #1 55400
> > Lock   (0x1f) C/N= 23.75dB
> > Service Das Erste HD, provider BR: reserved
> > Service arte HD, provider BR: reserved
> > Service PHOENIX HD, provider BR: reserved
> > Service tagesschau24 HD, provider BR: reserved
> > Service ONE HD, provider BR: reserved
> > New transponder/channel found: #11: -1776415946
> > New transponder/channel found: #12: 504706590
> > New transponder/channel found: #13: 523640360
> > New transponder/channel found: #14: 907948854
> > New transponder/channel found: #15: -397832490
> > New transponder/channel found: #16: 0
> > New transponder/channel found: #17: 0
> > New transponder/channel found: #18: 0
> > New transponder/channel found: #19: 0
> > New transponder/channel found: #20: 0
> > New transponder/channel found: #21: 0
> > New transponder/channel found: #22: 0
> > New transponder/channel found: #23: 0
> > New transponder/channel found: #24: 0
> > New transponder/channel found: #25: 0
> > New transponder/channel found: #26: 0
> > New transponder/channel found: #27: 0
> > New transponder/channel found: #28: 0
> > New transponder/channel found: #29: 0
> > New transponder/channel found: #30: 0
> > New transponder/channel found: #31: 0
> > New transponder/channel found: #32: 0
> > New transponder/channel found: #33: 0
> > New transponder/channel found: #34: 0
> > New transponder/channel found: #35: 0
> > New transponder/channel found: #36: 0
> > New transponder/channel found: #37: 0
> > New transponder/channel found: #38: 0
> > New transponder/channel found: #39: 0
> > New transponder/channel found: #40: 0
> > New transponder/channel found: #41: 0
> > New transponder/channel found: #42: 0
> > New transponder/channel found: #43: 0
> > New transponder/channel found: #44: 0
> > New transponder/channel found: #45: 0
> > New transponder/channel found: #46: 0
> > New transponder/channel found: #47: 0
> > New transponder/channel found: #48: 0
> > New transponder/channel found: #49: 0
> > New transponder/channel found: #50: 0
> > New transponder/channel found: #51: 0
> > New transponder/channel found: #52: 0
> > New transponder/channel found: #53: 0
> > New transponder/channel found: #54: 0
> > New transponder/channel found: #55: 0
> > New transponder/channel found: #56: 0
> > New transponder/channel found: #57: 0
> > New transponder/channel found: #58: 0
> > New transponder/channel found: #59: 0
> > New transponder/channel found: #60: 0
> > New transponder/channel found: #61: 0
> > New transponder/channel found: #62: 0
> > New transponder/channel found: #63: 0
> > New transponder/channel found: #64: 0
> > New transponder/channel found: #65: 0
> > New transponder/channel found: #66: 0
> > New transponder/channel found: #67: 0
> > New transponder/channel found: #68: 0
> > New transponder/channel found: #69: 0
> > New transponder/channel found: #70: 0
> > New transponder/channel found: #71: 0
> > New transponder/channel found: #72: 0
> > New transponder/channel found: #73: 0
> > New transponder/channel found: #74: 0
> > New transponder/channel found: #75: 0
> > Scanning frequency #2 65000
> >(0x00) Signal= -69.00dBm
> > Scanning frequency #3 73800
> >(0x00) Signal= -76.00dBm
> > Scanning frequency #4 57800
> > Lock   (0x1f) Signal= -76.00dBm C/N= 27.25dB
> > *** Erro

[PATCH 1/9] scripts/kernel-doc: fix parser for apostrophes

[Mauro Carvalho Chehab]

On ReST, adding a text like ``literal`` is valid. However,
the kernel-doc script won't handle it fine.

We really need this feature, in order to escape things like
%ph, with is found on some C files.

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kernel-doc | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 33c85dfdfce9..a4e5cc3b38e8 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -202,6 +202,7 @@ EOF
 # '&struct_name.member' - name of a structure member
 # '@parameter' - name of a parameter
 # '%CONST' - name of a constant.
+# '``LITERAL``' - literal string without any spaces on it.
 
 ## init lots of data
 
@@ -210,7 +211,8 @@ my $warnings = 0;
 my $anon_struct_union = 0;
 
 # match expressions used to find embedded type information
-my $type_constant = '\%([-_\w]+)';
+my $type_constant = '\b``([^\`]+)``\b';
+my $type_constant2 = '\%([-_\w]+)';
 my $type_func = '(\w+)\(\)';
 my $type_param = '\@(\w+(\.\.\.)?)';
 my $type_fp_param = '\@(\w+)\(\)';  # Special RST handling for func ptr params
@@ -235,6 +237,7 @@ my $type_member_func = $type_member . '\(\)';
 # these work fairly well
 my @highlights_html = (
[$type_constant, "\$1"],
+   [$type_constant2, "\$1"],
[$type_func, "\$1"],
[$type_enum_xml, "\$1"],
[$type_struct_xml, "\$1"],
@@ -252,6 +255,7 @@ my $blankline_html = $local_lt . "p" . $local_gt;   # was 
""
 # html version 5
 my @highlights_html5 = (
 [$type_constant, "\$1"],
+[$type_constant2, "\$1"],
 [$type_func, "\$1"],
 [$type_enum_xml, "\$1"],
 [$type_struct_xml, "\$1"],
@@ -268,6 +272,7 @@ my $blankline_html5 = $local_lt . "br /" . $local_gt;
 my @highlights_xml = (
   ["([^=])\\\"([^\\\"<]+)\\\"", "\$1\$2"],
   [$type_constant, "\$1"],
+  [$type_constant2, "\$1"],
   [$type_enum_xml, "\$1"],
   [$type_struct_xml, "\$1"],
   [$type_typedef_xml, "\$1"],
@@ -283,6 +288,7 @@ my $blankline_xml = $local_lt . "/para" . $local_gt . 
$local_lt . "para" . $loca
 # gnome, docbook format
 my @highlights_gnome = (
 [$type_constant, "\$1"],
+[$type_constant2, "\$1"],
 [$type_func, "\$1"],
 [$type_enum, "\$1"],
 [$type_struct, "\$1"],
@@ -298,6 +304,7 @@ my $blankline_gnome = "\n";
 # these are pretty rough
 my @highlights_man = (
   [$type_constant, "\$1"],
+  [$type_constant2, "\$1"],
   [$type_func, "fB\$1fP"],
   [$type_enum, "fI\$1fP"],
   [$type_struct, "fI\$1fP"],
@@ -312,6 +319,7 @@ my $blankline_man = "";
 # text-mode
 my @highlights_text = (
[$type_constant, "\$1"],
+   [$type_constant2, "\$1"],
[$type_func, "\$1"],
[$type_enum, "\$1"],
[$type_struct, "\$1"],
@@ -326,6 +334,7 @@ my $blankline_text = "";
 # rst-mode
 my @highlights_rst = (
[$type_constant, "``\$1``"],
+   [$type_constant2, "``\$1``"],
# Note: need to escape () to avoid func matching later
[$type_member_func, "\\:c\\:type\\:`\$1\$2\$3() 
<\$1>`"],
[$type_member, "\\:c\\:type\\:`\$1\$2\$3 <\$1>`"],
@@ -344,6 +353,7 @@ my $blankline_rst = "\n";
 # list mode
 my @highlights_list = (
[$type_constant, "\$1"],
+   [$type_constant2, "\$1"],
[$type_func, "\$1"],
[$type_enum, "\$1"],
[$type_struct, "\$1"],
-- 
2.9.3

[PATCH 6/9] kernel-api.rst: fix output of the vsnprintf() documentation

[Mauro Carvalho Chehab]

The vsnprintf() kernel-doc comment uses % character with a special
meaning other than escaping a constant. As ReST already defines
``literal`` as an escape sequence, let's make kernel-doc handle it,
and use it at lib/vsprintf.c.

Signed-off-by: Mauro Carvalho Chehab 
---
 lib/vsprintf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index e3bf4e0f10b5..176641cc549d 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1954,13 +1954,13 @@ set_precision(struct printf_spec *spec, int prec)
  * This function generally follows C99 vsnprintf, but has some
  * extensions and a few limitations:
  *
- * %n is unsupported
- * %p* is handled by pointer()
+ *  - ``%n`` is unsupported
+ *  - ``%p*`` is handled by pointer()
  *
  * See pointer() or Documentation/printk-formats.txt for more
  * extensive description.
  *
- * ** Please update the documentation in both places when making changes **
+ * **Please update the documentation in both places when making changes**
  *
  * The return value is the number of characters which would
  * be generated for the given input, excluding the trailing
-- 
2.9.3

[PATCH 7/9] kernel-api.rst: make it handle lib/crc32.c

[Mauro Carvalho Chehab]

This file has only "internal" functions:
./lib/crc32.c:1: warning: no structured comments found

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/core-api/kernel-api.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/core-api/kernel-api.rst 
b/Documentation/core-api/kernel-api.rst
index e820247e90d3..9a3d3597a6b7 100644
--- a/Documentation/core-api/kernel-api.rst
+++ b/Documentation/core-api/kernel-api.rst
@@ -80,7 +80,6 @@ CRC Functions
:export:
 
 .. kernel-doc:: lib/crc32.c
-   :export:
 
 .. kernel-doc:: lib/crc-ccitt.c
:export:
-- 
2.9.3

[PATCH 0/9] convert genericirq.tmpl and kernel-api.tmpl to DocBook

[Mauro Carvalho Chehab]

Jani proposed to batch-convert the remaining DocBooks for us
to get rid of it.

Well, I tried ;) 

The conversion itself can easily done, but the problem is that
it hits several errors/warnings when parsing kernel-doc tags.

It ends that it takes some time to fix those.

Also, it seems that the "!I" and "!E" tags at the DocBook
template are not quite right. So, despite being properly
converted to the corresponding kernel-doc tags at ReST, they
didn't produce all that it was needed. I manually fixed a
few, but I guess there are more to be fixed there. Anyway,
this is something that the subsystem maintainers can fix later,
as they understand better what functions they want exported at
the public API documentation, and what functions they want to
hide.

This series converts just two documents, adding them to the
core-api.rst book. It addresses the errors/warnings that popup
after the conversion.

I had to add two fixes to scripts/kernel-doc, in order to solve
some of the issues.

If I have some time during this weekend, I may try to convert
some additional documents to DocBook.


Mauro Carvalho Chehab (9):
  scripts/kernel-doc: fix parser for apostrophes
  scripts/kernel-doc: fix handling of parameters with parenthesis
  genericirq.tmpl: convert it to ReST
  genericirq.rst: add cross-reference links and use monospaced fonts
  kernel-api.tmpl: convert it to ReST
  kernel-api.rst: fix output of the vsnprintf() documentation
  kernel-api.rst: make it handle lib/crc32.c
  kernel-api.rst: fix some complex tags at lib/bitmap.c
  kernel-api.rst: fix a series of errors when parsing C files

 Documentation/DocBook/Makefile|   4 +-
 Documentation/DocBook/genericirq.tmpl | 520 --
 Documentation/DocBook/kernel-api.tmpl | 331 --
 Documentation/core-api/genericirq.rst | 440 
 Documentation/core-api/index.rst  |   2 +
 Documentation/core-api/kernel-api.rst | 418 +++
 block/genhd.c |   7 +-
 drivers/pci/irq.c |   2 +-
 include/linux/clk.h   |   4 +-
 ipc/util.c|  12 +-
 lib/bitmap.c  |  28 +-
 lib/string.c  |   2 +-
 lib/vsprintf.c|   6 +-
 mm/filemap.c  |  18 +-
 mm/page_alloc.c   |   3 +-
 mm/vmalloc.c  |   2 +-
 scripts/kernel-doc|  19 +-
 security/security.c   |  12 +-
 18 files changed, 932 insertions(+), 898 deletions(-)
 delete mode 100644 Documentation/DocBook/genericirq.tmpl
 delete mode 100644 Documentation/DocBook/kernel-api.tmpl
 create mode 100644 Documentation/core-api/genericirq.rst
 create mode 100644 Documentation/core-api/kernel-api.rst

-- 
2.9.3

[PATCH 9/9] kernel-api.rst: fix a series of errors when parsing C files

[Mauro Carvalho Chehab]

./lib/string.c:134: WARNING: Inline emphasis start-string without end-string.
./mm/filemap.c:522: WARNING: Inline interpreted text or phrase reference 
start-string without end-string.
./mm/filemap.c:1283: ERROR: Unexpected indentation.
./mm/filemap.c:3003: WARNING: Inline interpreted text or phrase reference 
start-string without end-string.
./mm/vmalloc.c:1544: WARNING: Inline emphasis start-string without end-string.
./mm/page_alloc.c:4245: ERROR: Unexpected indentation.
./ipc/util.c:676: ERROR: Unexpected indentation.
./drivers/pci/irq.c:35: WARNING: Block quote ends without a blank line; 
unexpected unindent.
./security/security.c:109: ERROR: Unexpected indentation.
./security/security.c:110: WARNING: Definition list ends without a blank line; 
unexpected unindent.
./block/genhd.c:275: WARNING: Inline strong start-string without end-string.
./block/genhd.c:283: WARNING: Inline strong start-string without end-string.
./include/linux/clk.h:134: WARNING: Inline emphasis start-string without 
end-string.
./include/linux/clk.h:134: WARNING: Inline emphasis start-string without 
end-string.
./ipc/util.c:477: ERROR: Unknown target name: "s".

Signed-off-by: Mauro Carvalho Chehab 
---
 block/genhd.c   |  7 ---
 drivers/pci/irq.c   |  2 +-
 include/linux/clk.h |  4 ++--
 ipc/util.c  | 12 +++-
 lib/string.c|  2 +-
 mm/filemap.c| 18 ++
 mm/page_alloc.c |  3 ++-
 mm/vmalloc.c|  2 +-
 security/security.c | 12 
 9 files changed, 36 insertions(+), 26 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index b26a5ea115d0..a53bfd19a0ec 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -271,16 +271,17 @@ void blkdev_show(struct seq_file *seqf, off_t offset)
 /**
  * register_blkdev - register a new block device
  *
- * @major: the requested major device number [1..255]. If @major=0, try to
+ * @major: the requested major device number [1..255]. If @major = 0, try to
  * allocate any unused major number.
  * @name: the name of the new block device as a zero terminated string
  *
  * The @name must be unique within the system.
  *
- * The return value depends on the @major input parameter.
+ * The return value depends on the @major input parameter:
+ *
  *  - if a major device number was requested in range [1..255] then the
  *function returns zero on success, or a negative error code
- *  - if any unused major number was requested with @major=0 parameter
+ *  - if any unused major number was requested with @major = 0 parameter
  *then the return value is the allocated major number in range
  *[1..255] or a negative error code otherwise
  */
diff --git a/drivers/pci/irq.c b/drivers/pci/irq.c
index 6684f153ab57..f9f2a0324ecc 100644
--- a/drivers/pci/irq.c
+++ b/drivers/pci/irq.c
@@ -31,7 +31,7 @@ static void pci_note_irq_problem(struct pci_dev *pdev, const 
char *reason)
  * driver).
  *
  * Returns:
- *  a suggestion for fixing it (although the driver is not required to
+ * a suggestion for fixing it (although the driver is not required to
  * act on this).
  */
 enum pci_lost_interrupt_reason pci_lost_interrupt(struct pci_dev *pdev)
diff --git a/include/linux/clk.h b/include/linux/clk.h
index e9d36b3e49de..024cd07870d0 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -132,8 +132,8 @@ int clk_get_phase(struct clk *clk);
  * @q: clk compared against p
  *
  * Returns true if the two struct clk pointers both point to the same hardware
- * clock node. Put differently, returns true if struct clk *p and struct clk *q
- * share the same struct clk_core object.
+ * clock node. Put differently, returns true if @p and @q
+ * share the same &struct clk_core object.
  *
  * Returns false otherwise. Note that two NULL clks are treated as matching.
  */
diff --git a/ipc/util.c b/ipc/util.c
index 798cad18dd87..3459a16a9df9 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -474,7 +474,7 @@ void ipc_rcu_free(struct rcu_head *head)
  * Check user, group, other permissions for access
  * to ipc resources. return 0 if allowed
  *
- * @flag will most probably be 0 or S_...UGO from 
+ * @flag will most probably be 0 or ``S_...UGO`` from 
  */
 int ipcperms(struct ipc_namespace *ns, struct kern_ipc_perm *ipcp, short flag)
 {
@@ -672,10 +672,12 @@ int ipc_update_perm(struct ipc64_perm *in, struct 
kern_ipc_perm *out)
  *
  * This function does some common audit and permissions check for some IPC_XXX
  * cmd and is called from semctl_down, shmctl_down and msgctl_down.
- * It must be called without any lock held and
- *  - retrieves the ipc with the given id in the given table.
- *  - performs some audit and permission check, depending on the given cmd
- *  - returns a pointer to the ipc object or otherwise, the corresponding 
error.
+ * It must be called without any lock held and:
+ *
+ *   - retrieves the ipc with the given id in the given table.
+ *   - performs some audit and permission check, depending on the given cmd
+ *   - ret

[PATCH 2/9] scripts/kernel-doc: fix handling of parameters with parenthesis

[Mauro Carvalho Chehab]

lib/crc32c defines one parameter as:
const u32 (*tab)[256]

Better handle parenthesis, to avoid those warnings:

./lib/crc32.c:149: warning: No description found for parameter 'tab)[256]'
./lib/crc32.c:149: warning: Excess function parameter 'tab' description in 
'crc32_le_generic'
./lib/crc32.c:294: warning: No description found for parameter 'tab)[256]'
./lib/crc32.c:294: warning: Excess function parameter 'tab' description in 
'crc32_be_generic'

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kernel-doc | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index a4e5cc3b38e8..a26a5f2dce39 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -2402,8 +2402,7 @@ sub push_parameter($$$) {
}
 
$anon_struct_union = 0;
-   my $param_name = $param;
-   $param_name =~ s/\[.*//;
+   $param =~ s/[\[\)].*//;
 
if ($type eq "" && $param =~ /\.\.\.$/)
{
@@ -2434,9 +2433,9 @@ sub push_parameter($$$) {
# but inline preprocessor statements);
# also ignore unnamed structs/unions;
if (!$anon_struct_union) {
-   if (!defined $parameterdescs{$param_name} && $param_name !~ /^#/) {
+   if (!defined $parameterdescs{$param} && $param !~ /^#/) {
 
-   $parameterdescs{$param_name} = $undescribed;
+   $parameterdescs{$param} = $undescribed;
 
if (($type eq 'function') || ($type eq 'enum')) {
print STDERR "${file}:$.: warning: Function parameter ".
-- 
2.9.3

[PATCH 8/9] kernel-api.rst: fix some complex tags at lib/bitmap.c

[Mauro Carvalho Chehab]

Fix the following issues:

./lib/bitmap.c:869: WARNING: Definition list ends without a blank line; 
unexpected unindent.
./lib/bitmap.c:876: WARNING: Inline emphasis start-string without end-string.
./lib/bitmap.c:508: ERROR: Unexpected indentation.

And make sure that a table and a footnote will use the right tags.

Signed-off-by: Mauro Carvalho Chehab 
---
 lib/bitmap.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 0b66f0e5eb6b..08c6ef3a2b6f 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -502,11 +502,11 @@ EXPORT_SYMBOL(bitmap_print_to_pagebuf);
  * Syntax: range:used_size/group_size
  * Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
  *
- * Returns 0 on success, -errno on invalid input strings.
- * Error values:
- *%-EINVAL: second number in range smaller than first
- *%-EINVAL: invalid character in string
- *%-ERANGE: bit number specified too large for mask
+ * Returns: 0 on success, -errno on invalid input strings. Error values:
+ *
+ *   - ``-EINVAL``: second number in range smaller than first
+ *   - ``-EINVAL``: invalid character in string
+ *   - ``-ERANGE``: bit number specified too large for mask
  */
 static int __bitmap_parselist(const char *buf, unsigned int buflen,
int is_user, unsigned long *maskp,
@@ -864,14 +864,16 @@ EXPORT_SYMBOL(bitmap_bitremap);
  *  11 was set in @orig had no affect on @dst.
  *
  * Example [2] for bitmap_fold() + bitmap_onto():
- *  Let's say @relmap has these ten bits set:
+ *  Let's say @relmap has these ten bits set::
+ *
  * 40 41 42 43 45 48 53 61 74 95
+ *
  *  (for the curious, that's 40 plus the first ten terms of the
  *  Fibonacci sequence.)
  *
  *  Further lets say we use the following code, invoking
  *  bitmap_fold() then bitmap_onto, as suggested above to
- *  avoid the possibility of an empty @dst result:
+ *  avoid the possibility of an empty @dst result::
  *
  * unsigned long *tmp; // a temporary bitmap's bits
  *
@@ -882,22 +884,26 @@ EXPORT_SYMBOL(bitmap_bitremap);
  *  various @orig's.  I list the zero-based positions of each set bit.
  *  The tmp column shows the intermediate result, as computed by
  *  using bitmap_fold() to fold the @orig bitmap modulo ten
- *  (the weight of @relmap).
+ *  (the weight of @relmap):
  *
+ *  === == =
  *  @orig   tmp@dst
  *  00 40
  *  11 41
  *  99 95
- *  10   0 40 (*)
+ *  10   0 40 [#f1]_
  *  1 3 5 7  1 3 5 7   41 43 48 61
  *  0 1 2 3 40 1 2 3 4 40 41 42 43 45
  *  0 9 18 270 9 8 7   40 61 74 95
  *  0 10 20 30   0 40
  *  0 11 22 33   0 1 2 3   40 41 42 43
  *  0 12 24 36   0 2 4 6   40 42 45 53
- *  78 102 211   1 2 8 41 42 74 (*)
+ *  78 102 211   1 2 8 41 42 74 [#f1]_
+ *  === == =
  *
- * (*) For these marked lines, if we hadn't first done bitmap_fold()
+ * .. [#f1]
+ *
+ * For these marked lines, if we hadn't first done bitmap_fold()
  * into tmp, then the @dst result would have been empty.
  *
  * If either of @orig or @relmap is empty (no set bits), then @dst
-- 
2.9.3

[PATCH 5/9] kernel-api.tmpl: convert it to ReST

[Mauro Carvalho Chehab]

Brainless conversion of genericirq.tmpl book to ReST, via
Documentation/sphinx/tmplcvt

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/DocBook/Makefile|   2 +-
 Documentation/DocBook/kernel-api.tmpl | 331 ---
 Documentation/core-api/index.rst  |   1 +
 Documentation/core-api/kernel-api.rst | 419 ++
 4 files changed, 421 insertions(+), 332 deletions(-)
 delete mode 100644 Documentation/DocBook/kernel-api.tmpl
 create mode 100644 Documentation/core-api/kernel-api.rst

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index e0c13655f770..13056d40e11b 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -9,7 +9,7 @@
 DOCBOOKS := z8530book.xml  \
kernel-hacking.xml kernel-locking.xml \
networking.xml \
-   kernel-api.xml filesystems.xml lsm.xml kgdb.xml \
+   filesystems.xml lsm.xml kgdb.xml \
libata.xml mtdnand.xml librs.xml rapidio.xml \
s390-drivers.xml scsi.xml \
sh.xml w1.xml
diff --git a/Documentation/DocBook/kernel-api.tmpl 
b/Documentation/DocBook/kernel-api.tmpl
deleted file mode 100644
index ecfd0ea40661..
--- a/Documentation/DocBook/kernel-api.tmpl
+++ /dev/null
@@ -1,331 +0,0 @@
-
-http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []>
-
-
- 
-  The Linux Kernel API
-  
-  
-   
- This documentation 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.
-   
-  
-   
- 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.
-   
-  
-   
- You should have received a copy of the GNU General Public
- License along with this program; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
-   
-  
-   
- For more details see the file COPYING in the source
- distribution of Linux.
-   
-  
- 
-
-
-
-  
- Data Types
- Doubly Linked Lists
-!Iinclude/linux/list.h
- 
-  
-
-  
- Basic C Library Functions
-
- 
-   When writing drivers, you cannot in general use routines which are
-   from the C Library.  Some of the functions have been found generally
-   useful and they are listed below.  The behaviour of these functions
-   may vary slightly from those defined by ANSI, and these deviations
-   are noted in the text.
- 
-
- String Conversions
-!Elib/vsprintf.c
-!Finclude/linux/kernel.h kstrtol
-!Finclude/linux/kernel.h kstrtoul
-!Elib/kstrtox.c
- 
- String Manipulation
-
-!Elib/string.c
- 
- Bit Operations
-!Iarch/x86/include/asm/bitops.h
- 
-  
-
-  
- Basic Kernel Library Functions
-
- 
-   The Linux kernel provides more basic utility functions.
- 
-
- Bitmap Operations
-!Elib/bitmap.c
-!Ilib/bitmap.c
- 
-
- Command-line Parsing
-!Elib/cmdline.c
- 
-
- CRC Functions
-!Elib/crc7.c
-!Elib/crc16.c
-!Elib/crc-itu-t.c
-!Elib/crc32.c
-!Elib/crc-ccitt.c
- 
-
- idr/ida Functions
-!Pinclude/linux/idr.h idr sync
-!Plib/idr.c IDA description
-!Elib/idr.c
- 
-  
-
-  
- Memory Management in Linux
- The Slab Cache
-!Iinclude/linux/slab.h
-!Emm/slab.c
-!Emm/util.c
- 
- User Space Memory Access
-!Iarch/x86/include/asm/uaccess_32.h
-!Earch/x86/lib/usercopy_32.c
- 
- More Memory Management Functions
-!Emm/readahead.c
-!Emm/filemap.c
-!Emm/memory.c
-!Emm/vmalloc.c
-!Imm/page_alloc.c
-!Emm/mempool.c
-!Emm/dmapool.c
-!Emm/page-writeback.c
-!Emm/truncate.c
- 
-  
-
-
-  
- Kernel IPC facilities
-
- IPC utilities
-!Iipc/util.c
- 
-  
-
-  
- FIFO Buffer
- kfifo interface
-!Iinclude/linux/kfifo.h
- 
-  
-
-  
- relay interface support
-
- 
-   Relay interface support
-   is designed to provide an efficient mechanism for tools and
-   facilities to relay large amounts of data from kernel space to
-   user space.
- 
-
- relay interface
-!Ekernel/relay.c
-!Ikernel/relay.c
- 
-  
-
-  
- Module Support
- Module Loading
-!Ekernel/kmod.c
- 
- Inter Module support
-
-   Refer to the file kernel/module.c for more information.
-
-
- 
-  
-
-  
- Hardware Interfaces
- Interrupt Handling
-!Ekernel/irq/manage.c
- 
-
- DMA Channels
-!Ekernel/dma.c
- 
-
- Resources Management
-!Ikernel/resource.c
-!Ekernel/resource.c
- 
-
- MTRR Handling
-!Earch/x86/kernel/cpu/mtrr/main.c
- 
-
- PCI Support Library
-!Edrivers/pci/pci.c
-!Edrivers/pci/pci-drive

[PATCH 3/9] genericirq.tmpl: convert it to ReST

[Mauro Carvalho Chehab]

Brainless conversion of genericirq.tmpl book to ReST, via
Documentation/sphinx/tmplcvt

Copyright information inserted manually.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/DocBook/Makefile|   2 +-
 Documentation/DocBook/genericirq.tmpl | 520 --
 Documentation/core-api/genericirq.rst | 445 +
 Documentation/core-api/index.rst  |   1 +
 4 files changed, 447 insertions(+), 521 deletions(-)
 delete mode 100644 Documentation/DocBook/genericirq.tmpl
 create mode 100644 Documentation/core-api/genericirq.rst

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 7d94db2b53cd..e0c13655f770 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -11,7 +11,7 @@ DOCBOOKS := z8530book.xml  \
networking.xml \
kernel-api.xml filesystems.xml lsm.xml kgdb.xml \
libata.xml mtdnand.xml librs.xml rapidio.xml \
-   genericirq.xml s390-drivers.xml scsi.xml \
+   s390-drivers.xml scsi.xml \
sh.xml w1.xml
 
 ifeq ($(DOCBOOKS),)
diff --git a/Documentation/DocBook/genericirq.tmpl 
b/Documentation/DocBook/genericirq.tmpl
deleted file mode 100644
index 59fb5c077541..
--- a/Documentation/DocBook/genericirq.tmpl
+++ /dev/null
@@ -1,520 +0,0 @@
-
-http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []>
-
-
- 
-  Linux generic IRQ handling
-
-  
-   
-Thomas
-Gleixner
-
- 
-  t...@linutronix.de
- 
-
-   
-   
-Ingo
-Molnar
-
- 
-  mi...@elte.hu
- 
-
-   
-  
-
-  
-   2005-2010
-   Thomas Gleixner
-  
-  
-   2005-2006
-   Ingo Molnar
-  
-
-  
-   
- This documentation is free software; you can redistribute
- it and/or modify it under the terms of the GNU General Public
- License version 2 as published by the Free Software Foundation.
-   
-
-   
- 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.
-   
-
-   
- You should have received a copy of the GNU General Public
- License along with this program; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
-   
-
-   
- For more details see the file COPYING in the source
- distribution of Linux.
-   
-  
- 
-
-
-
-  
-Introduction
-
-   The generic interrupt handling layer is designed to provide a
-   complete abstraction of interrupt handling for device drivers.
-   It is able to handle all the different types of interrupt controller
-   hardware. Device drivers use generic API functions to request, enable,
-   disable and free interrupts. The drivers do not have to know anything
-   about interrupt hardware details, so they can be used on different
-   platforms without code changes.
-
-
-   This documentation is provided to developers who want to implement
-   an interrupt subsystem based for their architecture, with the help
-   of the generic IRQ handling layer.
-
-  
-
-  
-Rationale
-   
-   The original implementation of interrupt handling in Linux uses
-   the __do_IRQ() super-handler, which is able to deal with every
-   type of interrupt logic.
-   
-   
-   Originally, Russell King identified different types of handlers to
-   build a quite universal set for the ARM interrupt handler
-   implementation in Linux 2.5/2.6. He distinguished between:
-   
- Level type
- Edge type
- Simple type
-   
-   During the implementation we identified another type:
-   
- Fast EOI type
-   
-   In the SMP world of the __do_IRQ() super-handler another type
-   was identified:
-   
- Per CPU type
-   
-   
-   
-   This split implementation of high-level IRQ handlers allows us to
-   optimize the flow of the interrupt handling for each specific
-   interrupt type. This reduces complexity in that particular code path
-   and allows the optimized handling of a given type.
-   
-   
-   The original general IRQ implementation used hw_interrupt_type
-   structures and their ->ack(), ->end() [etc.] callbacks to
-   differentiate the flow control in the super-handler. This leads to
-   a mix of flow logic and low-level hardware logic, and it also leads
-   to unnecessary code duplication: for example in i386, there is an
-   ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many
-   of the low-level details but have different flow handling.
-   
-   
-   A more natural abstraction is the clean separation of the
-   'irq flow' and the 'chip details'.
-   
-

[PATCH 4/9] genericirq.rst: add cross-reference links and use monospaced fonts

[Mauro Carvalho Chehab]

The document describes several functions that are documented
there via kernel doc macros. Add cross-references to them.

In order to be consistend with other documents, use monospaced
fonts for fields.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/core-api/genericirq.rst | 97 +--
 1 file changed, 46 insertions(+), 51 deletions(-)

diff --git a/Documentation/core-api/genericirq.rst 
b/Documentation/core-api/genericirq.rst
index 65d023b26864..0054bd48be84 100644
--- a/Documentation/core-api/genericirq.rst
+++ b/Documentation/core-api/genericirq.rst
@@ -26,7 +26,7 @@ Rationale
 =
 
 The original implementation of interrupt handling in Linux uses the
-__do_IRQ() super-handler, which is able to deal with every type of
+:c:func:`__do_IRQ` super-handler, which is able to deal with every type of
 interrupt logic.
 
 Originally, Russell King identified different types of handlers to build
@@ -43,7 +43,7 @@ During the implementation we identified another type:
 
 -  Fast EOI type
 
-In the SMP world of the __do_IRQ() super-handler another type was
+In the SMP world of the :c:func:`__do_IRQ` super-handler another type was
 identified:
 
 -  Per CPU type
@@ -54,11 +54,11 @@ type. This reduces complexity in that particular code path 
and allows
 the optimized handling of a given type.
 
 The original general IRQ implementation used hw_interrupt_type
-structures and their ->ack(), ->end() [etc.] callbacks to differentiate
+structures and their ``->ack``, ``->end`` [etc.] callbacks to differentiate
 the flow control in the super-handler. This leads to a mix of flow logic
 and low-level hardware logic, and it also leads to unnecessary code
-duplication: for example in i386, there is an ioapic_level_irq and an
-ioapic_edge_irq IRQ-type which share many of the low-level details but
+duplication: for example in i386, there is an ``ioapic_level_irq`` and an
+``ioapic_edge_irq`` IRQ-type which share many of the low-level details but
 have different flow handling.
 
 A more natural abstraction is the clean separation of the 'irq flow' and
@@ -83,7 +83,7 @@ IRQ-flow implementation for 'level type' interrupts and add a
 (sub)architecture specific 'edge type' implementation.
 
 To make the transition to the new model easier and prevent the breakage
-of existing implementations, the __do_IRQ() super-handler is still
+of existing implementations, the :c:func:`__do_IRQ` super-handler is still
 available. This leads to a kind of duality for the time being. Over time
 the new model should be used in more and more architectures, as it
 enables smaller and cleaner IRQ subsystems. It's deprecated for three
@@ -116,7 +116,7 @@ status information and pointers to the interrupt flow 
method and the
 interrupt chip structure which are assigned to this interrupt.
 
 Whenever an interrupt triggers, the low-level architecture code calls
-into the generic interrupt code by calling desc->handle_irq(). This
+into the generic interrupt code by calling :c:func:`desc->handle_irq`. This
 high-level IRQ handling function only uses desc->irq_data.chip
 primitives referenced by the assigned chip descriptor structure.
 
@@ -125,27 +125,27 @@ High-level Driver API
 
 The high-level Driver API consists of following functions:
 
--  request_irq()
+-  :c:func:`request_irq`
 
--  free_irq()
+-  :c:func:`free_irq`
 
--  disable_irq()
+-  :c:func:`disable_irq`
 
--  enable_irq()
+-  :c:func:`enable_irq`
 
--  disable_irq_nosync() (SMP only)
+-  :c:func:`disable_irq_nosync` (SMP only)
 
--  synchronize_irq() (SMP only)
+-  :c:func:`synchronize_irq` (SMP only)
 
--  irq_set_irq_type()
+-  :c:func:`irq_set_irq_type`
 
--  irq_set_irq_wake()
+-  :c:func:`irq_set_irq_wake`
 
--  irq_set_handler_data()
+-  :c:func:`irq_set_handler_data`
 
--  irq_set_chip()
+-  :c:func:`irq_set_chip`
 
--  irq_set_chip_data()
+-  :c:func:`irq_set_chip_data`
 
 See the autogenerated function documentation for details.
 
@@ -154,19 +154,19 @@ High-level IRQ flow handlers
 
 The generic layer provides a set of pre-defined irq-flow methods:
 
--  handle_level_irq
+-  :c:func:`handle_level_irq`
 
--  handle_edge_irq
+-  :c:func:`handle_edge_irq`
 
--  handle_fasteoi_irq
+-  :c:func:`handle_fasteoi_irq`
 
--  handle_simple_irq
+-  :c:func:`handle_simple_irq`
 
--  handle_percpu_irq
+-  :c:func:`handle_percpu_irq`
 
--  handle_edge_eoi_irq
+-  :c:func:`handle_edge_eoi_irq`
 
--  handle_bad_irq
+-  :c:func:`handle_bad_irq`
 
 The interrupt flow handlers (either pre-defined or architecture
 specific) are assigned to specific interrupts by the architecture either
@@ -225,9 +225,9 @@ interrupts.
 
 The following control flow is implemented (simplified excerpt)::
 
-desc->irq_data.chip->irq_mask_ack();
+:c:func:`desc->irq_data.chip->irq_mask_ack`;
 handle_irq_event(desc->action);
-desc->irq_data.chip->irq_unmask();
+:c:func:`desc->irq_data.chip->irq_unmask`;
 
 
 Default Fast EOI IRQ flow handler
@@ -239,7 +239,7 @@ which only 

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Laurent Pinchart]

Hi Helen,

Thank you for the patch.

On Thursday 30 Mar 2017 13:02:17 Helen Koike wrote:
> Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
> used when no inputs are available in the device
> 
> Signed-off-by: Helen Koike 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
>  include/media/v4l2-ioctl.h   | 26 ++
>  include/uapi/linux/videodev2.h   |  1 +
>  3 files changed, 54 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct video_device
> *vdev, unsigned cmd) return vdev->lock;
>  }
> 
> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> +   struct v4l2_input *i)
> +{
> + if (i->index > 0)
> + return -EINVAL;
> +
> + memset(i, 0, sizeof(*i));
> + i->type = V4L2_INPUT_TYPE_DEFAULT;
> + strlcpy(i->name, "Default", sizeof(i->name));
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);

V4L2 tends to use EXPORT_SYMBOL_GPL.

What would you think about calling those default functions directly from the 
core when the input ioctl handlers are not set ? You wouldn't need to modify 
drivers.

> +
> +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int
> *i) +{
> + *i = 0;
> + return 0;
> +}
> +EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
> +
> +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int
> i) +{
> + return i ? -EINVAL : 0;
> +}
> +EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
> +
>  /* Common ioctl debug function. This function can be used by
> external ioctl messages as well as internal V4L ioctl */
>  void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
> diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
> index 6cd94e5..accc470 100644
> --- a/include/media/v4l2-ioctl.h
> +++ b/include/media/v4l2-ioctl.h
> @@ -652,6 +652,32 @@ struct video_device;
>   */
>  struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned int
> cmd);
> 
> +
> +/**
> + * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for VIDIOC_ENUM_INPUT
> ioctl + *
> + * Plug this function in vidioc_enum_input field of the struct
> v4l2_ioctl_ops to + * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT
> + */
> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> +   struct v4l2_input *i);
> +
> +/**
> + * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT ioctl
> + *
> + * Plug this function in vidioc_g_input field of the struct v4l2_ioctl_ops
> + * when using v4l2_ioctl_enum_input_default
> + */
> +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int
> *i); +
> +/**
> + * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT ioctl
> + *
> + * Plug this function in vidioc_s_input field of the struct v4l2_ioctl_ops
> + * when using v4l2_ioctl_enum_input_default
> + */
> +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int
> i); +
>  /* names for fancy debug output */
>  extern const char *v4l2_field_names[];
>  extern const char *v4l2_type_names[];
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 316be62..c10bbde 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1477,6 +1477,7 @@ struct v4l2_input {
>  };
> 
>  /*  Values for the 'type' field */
> +#define V4L2_INPUT_TYPE_DEFAULT  0
>  #define V4L2_INPUT_TYPE_TUNER1
>  #define V4L2_INPUT_TYPE_CAMERA   2
>  #define V4L2_INPUT_TYPE_TOUCH3

-- 
Regards,

Laurent Pinchart

Re: dvb-tools: dvbv5-scan segfaults with DVB-T2 HD service that just started in Germany

[Gregor Jasny]

Hello Mauro,

could you please take a look?

Thanks,
Gregor

On 3/30/17 9:36 PM, Frank Heckenbach wrote:
> I got the same problem, only on some channels though, e.g. ZDF using
> this input:
> 
> [CH34]
> DELIVERY_SYSTEM = DVBT2
> FREQUENCY = 57800
> BANDWIDTH_HZ = 800
> MODULATION = QAM/16
> 
> *** Error in `dvbv5-scan': malloc(): memory corruption: 0x00fe13c0 ***
> 
> I did some debugging with gdb and valgrind (using the upstream
> version v4l-utils-1.12.3.tar.bz2 since I needed to recompile anyway
> to get debug info).
> 
> I found an invalid access in descriptors/desc_t2_delivery.c:55
> 
>   memcpy(&d->centre_frequency, p, len);
> 
> Before this, dvb_extension_descriptor_init had
> 
>   desc_type == 4 (T2_delivery_system_descriptor)
> 
> and
> 
>   dvb_ext_descriptors[4].size == sizeof(struct dvb_desc_t2_delivery) (23)
> 
> so it allocated only 23 bytes, but didn't change desc_len which was
> still 68, causing the overflow.
> 
> Setting desc_len to 23 didn't help, but just allocating 68 bytes
> did:
> 
> --- v4l-utils-1.12.3/lib/libdvbv5/descriptors/desc_extension.c
> +++ v4l-utils-1.12.3/lib/libdvbv5/descriptors/desc_extension.c
> @@ -149,7 +149,7 @@
>   if (!size)
>   size = desc_len;
>  
> - ext->descriptor = calloc(1, size);
> + ext->descriptor = calloc(1, desc_len);
>  
>   if (init) {
>   if (init(parms, p, ext, ext->descriptor) != 0)
> 
> NOTE: This is probably not a proper fix, just a bandaid. Since
> scanning channels is mostly a one-off job, I'm happy now that I got
> my channels list and don't plan to invest more time resarching the
> issue.
> 

[RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

[Philipp Zabel]

The TVP5150 DT bindings specify a single output port (port 0) that
corresponds to the video output pad (pad 1, DEMOD_PAD_VID_OUT).

Signed-off-by: Philipp Zabel 
---
I'm trying to get this to work with a TVP5150 analog TV decoder, and the
first problem is that this device doesn't have pad 0 as its single
output pad. Instead, as a MEDIA_ENT_F_ATV_DECODER entity, it has for
pads (input, video out, vbi out, audio out), and video out is pad 1,
whereas the device tree only defines a single port (0).
---

 drivers/staging/media/imx/imx-media-dev.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index 17e2386a3ca3a..c52d6ca797965 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -267,6 +267,15 @@ static int imx_media_create_link(struct imx_media_dev 
*imxmd,
source_pad = link->local_pad;
sink_pad = link->remote_pad;
 
+   /*
+* If the source subdev is an analog video decoder with a single source
+* port, assume that this port 0 corresponds to the DEMOD_PAD_VID_OUT
+* entity pad.
+*/
+   if (source->entity.function == MEDIA_ENT_F_ATV_DECODER &&
+   local_sd->num_sink_pads == 0 && local_sd->num_src_pads == 1)
+   source_pad = DEMOD_PAD_VID_OUT;
+
v4l2_info(&imxmd->v4l2_dev, "%s: %s:%d -> %s:%d\n", __func__,
  source->name, source_pad, sink->name, sink_pad);
 
-- 
2.11.0

[GIT PULL] Samsung SoC related updates

[Sylwester Nawrocki]

Hi Mauro,

The following changes since commit c3d4fb0fb41f4b5eafeee51173c14e50be12f839:

  [media] rc: sunxi-cir: simplify optional reset handling (2017-03-24 08:30:03 
-0300)

are available in the git repository at:

  git://linuxtv.org/snawrocki/samsung.git for-v4.12/media/next

for you to fetch changes up to b51f9a138838daeed695af086167eaf51cd905d8:

  s5p-g2d: Fix error handling (2017-03-30 18:13:18 +0200)


Christophe JAILLET (1):
  s5p-g2d: Fix error handling

Marek Szyprowski (19):
  s5p-mfc: Fix initialization of internal structures
  s5p-mfc: Fix race between interrupt routine and device functions
  s5p-mfc: Remove unused structures and dead code
  s5p-mfc: Use generic of_device_get_match_data helper
  s5p-mfc: Replace mem_dev_* entries with an array
  s5p-mfc: Replace bank1/bank2 entries with an array
  s5p-mfc: Simplify alloc/release private buffer functions
  s5p-mfc: Move setting DMA max segment size to DMA configure function
  s5p-mfc: Put firmware to private buffer structure
  s5p-mfc: Move firmware allocation to DMA configure function
  s5p-mfc: Allocate firmware with internal private buffer alloc function
  s5p-mfc: Reduce firmware buffer size for MFC v6+ variants
  s5p-mfc: Split variant DMA memory configuration into separate functions
  s5p-mfc: Add support for probe-time preallocated block based allocator
  s5p-mfc: Remove special configuration of IOMMU domain
  s5p-mfc: Use preallocated block allocator always for MFC v6+
  s5p-mfc: Rename BANK1/2 to BANK_L/R to better match documentation
  s5p-mfc: Fix unbalanced call to clock management
  s5p-mfc: Don't allocate codec buffers from pre-allocated region

Shuah Khan (2):
  s5p_mfc: Remove unneeded io_modes initialization in s5p_mfc_open()
  s5p-mfc: Print buf pointer in hex constistently

 .../devicetree/bindings/media/s5p-mfc.txt   |   2 +-
 drivers/media/platform/s5p-g2d/g2d.c|   2 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v6.h|   2 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v7.h|   2 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v8.h|   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 245 ---
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c |   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  43 ++--
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |  72 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h   |   1 -
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|   8 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  10 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h  |  51 +---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.c|  93 +--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|  12 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |  48 ++--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |  16 +-
 17 files changed, 316 insertions(+), 295 deletions(-)

-- 
Thanks,
Sylwester

[PATCH v4 4/4] media-ctl: add colorimetry support

[Philipp Zabel]

media-ctl can be used to propagate v4l2 subdevice pad formats from
source pads of one subdevice to another one's sink pads. These formats
include colorimetry information, so media-ctl should be able to print
or change it using the --set/get-v4l2 option.

Signed-off-by: Philipp Zabel 
Acked-by: Sakari Ailus 
---
 utils/media-ctl/libv4l2subdev.c | 262 
 utils/media-ctl/media-ctl.c |  17 +++
 utils/media-ctl/options.c   |  22 +++-
 utils/media-ctl/v4l2subdev.h|  80 
 4 files changed, 380 insertions(+), 1 deletion(-)

diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 51e7990d..ac0c8cfa 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -511,6 +511,118 @@ static struct media_pad *v4l2_subdev_parse_pad_format(
continue;
}
 
+   if (strhazit("colorspace:", &p)) {
+   enum v4l2_colorspace colorspace;
+   char *strfield;
+
+   for (end = (char *)p; isalnum(*end) || *end == '-';
+++end);
+
+   strfield = strndup(p, end - p);
+   if (!strfield) {
+   *endp = (char *)p;
+   return NULL;
+   }
+
+   colorspace = v4l2_subdev_string_to_colorspace(strfield);
+   free(strfield);
+   if (colorspace == (enum v4l2_colorspace)-1) {
+   media_dbg(media, "Invalid colorspace value 
'%*s'\n",
+ end - p, p);
+   *endp = (char *)p;
+   return NULL;
+   }
+
+   format->colorspace = colorspace;
+
+   p = end;
+   continue;
+   }
+
+   if (strhazit("xfer:", &p)) {
+   enum v4l2_xfer_func xfer_func;
+   char *strfield;
+
+   for (end = (char *)p; isalnum(*end) || *end == '-';
+++end);
+
+   strfield = strndup(p, end - p);
+   if (!strfield) {
+   *endp = (char *)p;
+   return NULL;
+   }
+
+   xfer_func = v4l2_subdev_string_to_xfer_func(strfield);
+   free(strfield);
+   if (xfer_func == (enum v4l2_xfer_func)-1) {
+   media_dbg(media, "Invalid transfer function 
value '%*s'\n",
+ end - p, p);
+   *endp = (char *)p;
+   return NULL;
+   }
+
+   format->xfer_func = xfer_func;
+
+   p = end;
+   continue;
+   }
+
+   if (strhazit("ycbcr:", &p)) {
+   enum v4l2_ycbcr_encoding ycbcr_enc;
+   char *strfield;
+
+   for (end = (char *)p; isalnum(*end) || *end == '-';
+++end);
+
+   strfield = strndup(p, end - p);
+   if (!strfield) {
+   *endp = (char *)p;
+   return NULL;
+   }
+
+   ycbcr_enc = 
v4l2_subdev_string_to_ycbcr_encoding(strfield);
+   free(strfield);
+   if (ycbcr_enc == (enum v4l2_ycbcr_encoding)-1) {
+   media_dbg(media, "Invalid YCbCr encoding value 
'%*s'\n",
+ end - p, p);
+   *endp = (char *)p;
+   return NULL;
+   }
+
+   format->ycbcr_enc = ycbcr_enc;
+
+   p = end;
+   continue;
+   }
+
+   if (strhazit("quantization:", &p)) {
+   enum v4l2_quantization quantization;
+   char *strfield;
+
+   for (end = (char *)p; isalnum(*end) || *end == '-';
+++end);
+
+   strfield = strndup(p, end - p);
+   if (!strfield) {
+   *endp = (char *)p;
+   return NULL;
+   }
+
+   quantization = 
v4l2_subdev_string_to_quantization(strfield);
+   free(strfield);
+   if (quantization == (enum v4l2_quantization)-1) {
+   media_dbg(media, "Invalid quantization value 
'%*s'\n",
+ end - p, p)

[PATCH v4 2/4] media-ctl: print the configured frame interval

[Philipp Zabel]

After the pad format, also print the frame interval, if already configured.

Signed-off-by: Philipp Zabel 
Acked-by: Sakari Ailus 
---
Changes since v3:
 - Ignore EINVAL error of VIDIOC_SUBDEV_G_FRAME_INTERVAL as that
   is a valid return value if the pad doesn't support frame intervals,
   according to the documentation.
---
 utils/media-ctl/media-ctl.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/utils/media-ctl/media-ctl.c b/utils/media-ctl/media-ctl.c
index 572bcf75..3dbac256 100644
--- a/utils/media-ctl/media-ctl.c
+++ b/utils/media-ctl/media-ctl.c
@@ -79,6 +79,7 @@ static void v4l2_subdev_print_format(struct media_entity 
*entity,
unsigned int pad, enum v4l2_subdev_format_whence which)
 {
struct v4l2_mbus_framefmt format;
+   struct v4l2_fract interval = { 0, 0 };
struct v4l2_rect rect;
int ret;
 
@@ -86,10 +87,17 @@ static void v4l2_subdev_print_format(struct media_entity 
*entity,
if (ret != 0)
return;
 
+   ret = v4l2_subdev_get_frame_interval(entity, &interval, pad);
+   if (ret != 0 && ret != -ENOTTY && ret != -EINVAL)
+   return;
+
printf("\t\t[fmt:%s/%ux%u",
   v4l2_subdev_pixelcode_to_string(format.code),
   format.width, format.height);
 
+   if (interval.numerator || interval.denominator)
+   printf("@%u/%u", interval.numerator, interval.denominator);
+
if (format.field)
printf(" field:%s", v4l2_subdev_field_to_string(format.field));
 
-- 
2.11.0

[PATCH v4 3/4] media-ctl: propagate frame interval

[Philipp Zabel]

Same as the media bus format, the frame interval should be propagated
from output pads to connected entities' input pads.

Signed-off-by: Philipp Zabel 
Acked-by: Sakari Ailus 
---
Changes since v3:
 - Ignore frame interval propagation errors if the sink pad doesn't
   support VIDIOC_SUBDEV_S_FRAME_INTERVAL.
---
 utils/media-ctl/libv4l2subdev.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 2f2ac8ee..51e7990d 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -694,8 +694,8 @@ static int v4l2_subdev_parse_setup_format(struct 
media_device *media,
return ret;
 
 
-   /* If the pad is an output pad, automatically set the same format on
-* the remote subdev input pads, if any.
+   /* If the pad is an output pad, automatically set the same format and
+* frame interval on the remote subdev input pads, if any.
 */
if (pad->flags & MEDIA_PAD_FL_SOURCE) {
for (i = 0; i < pad->entity->num_links; ++i) {
@@ -709,6 +709,10 @@ static int v4l2_subdev_parse_setup_format(struct 
media_device *media,
link->sink->entity->info.type == 
MEDIA_ENT_T_V4L2_SUBDEV) {
remote_format = format;
set_format(link->sink, &remote_format);
+
+   ret = set_frame_interval(link->sink, &interval);
+   if (ret < 0 && ret != -EINVAL && ret != -ENOTTY)
+   return ret;
}
}
}
-- 
2.11.0

[PATCH v4 1/4] media-ctl: add pad support to set/get_frame_interval

[Philipp Zabel]

This allows to set and get the frame interval on pads other than pad 0.

Signed-off-by: Philipp Zabel 
Acked-by: Sakari Ailus 
---
 utils/media-ctl/libv4l2subdev.c | 24 ++--
 utils/media-ctl/v4l2subdev.h|  4 ++--
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 3dcf943c..2f2ac8ee 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -262,7 +262,8 @@ int v4l2_subdev_set_dv_timings(struct media_entity *entity,
 }
 
 int v4l2_subdev_get_frame_interval(struct media_entity *entity,
-  struct v4l2_fract *interval)
+  struct v4l2_fract *interval,
+  unsigned int pad)
 {
struct v4l2_subdev_frame_interval ival;
int ret;
@@ -272,6 +273,7 @@ int v4l2_subdev_get_frame_interval(struct media_entity 
*entity,
return ret;
 
memset(&ival, 0, sizeof(ival));
+   ival.pad = pad;
 
ret = ioctl(entity->fd, VIDIOC_SUBDEV_G_FRAME_INTERVAL, &ival);
if (ret < 0)
@@ -282,7 +284,8 @@ int v4l2_subdev_get_frame_interval(struct media_entity 
*entity,
 }
 
 int v4l2_subdev_set_frame_interval(struct media_entity *entity,
-  struct v4l2_fract *interval)
+  struct v4l2_fract *interval,
+  unsigned int pad)
 {
struct v4l2_subdev_frame_interval ival;
int ret;
@@ -292,6 +295,7 @@ int v4l2_subdev_set_frame_interval(struct media_entity 
*entity,
return ret;
 
memset(&ival, 0, sizeof(ival));
+   ival.pad = pad;
ival.interval = *interval;
 
ret = ioctl(entity->fd, VIDIOC_SUBDEV_S_FRAME_INTERVAL, &ival);
@@ -617,7 +621,7 @@ static int set_selection(struct media_pad *pad, unsigned 
int target,
return 0;
 }
 
-static int set_frame_interval(struct media_entity *entity,
+static int set_frame_interval(struct media_pad *pad,
  struct v4l2_fract *interval)
 {
int ret;
@@ -625,20 +629,20 @@ static int set_frame_interval(struct media_entity *entity,
if (interval->numerator == 0)
return 0;
 
-   media_dbg(entity->media,
- "Setting up frame interval %u/%u on entity %s\n",
+   media_dbg(pad->entity->media,
+ "Setting up frame interval %u/%u on pad %s/%u\n",
  interval->numerator, interval->denominator,
- entity->info.name);
+ pad->entity->info.name, pad->index);
 
-   ret = v4l2_subdev_set_frame_interval(entity, interval);
+   ret = v4l2_subdev_set_frame_interval(pad->entity, interval, pad->index);
if (ret < 0) {
-   media_dbg(entity->media,
+   media_dbg(pad->entity->media,
  "Unable to set frame interval: %s (%d)",
  strerror(-ret), ret);
return ret;
}
 
-   media_dbg(entity->media, "Frame interval set: %u/%u\n",
+   media_dbg(pad->entity->media, "Frame interval set: %u/%u\n",
  interval->numerator, interval->denominator);
 
return 0;
@@ -685,7 +689,7 @@ static int v4l2_subdev_parse_setup_format(struct 
media_device *media,
return ret;
}
 
-   ret = set_frame_interval(pad->entity, &interval);
+   ret = set_frame_interval(pad, &interval);
if (ret < 0)
return ret;
 
diff --git a/utils/media-ctl/v4l2subdev.h b/utils/media-ctl/v4l2subdev.h
index 9c8fee89..413094d5 100644
--- a/utils/media-ctl/v4l2subdev.h
+++ b/utils/media-ctl/v4l2subdev.h
@@ -200,7 +200,7 @@ int v4l2_subdev_set_dv_timings(struct media_entity *entity,
  */
 
 int v4l2_subdev_get_frame_interval(struct media_entity *entity,
-   struct v4l2_fract *interval);
+   struct v4l2_fract *interval, unsigned int pad);
 
 /**
  * @brief Set the frame interval on a sub-device.
@@ -217,7 +217,7 @@ int v4l2_subdev_get_frame_interval(struct media_entity 
*entity,
  * @return 0 on success, or a negative error code on failure.
  */
 int v4l2_subdev_set_frame_interval(struct media_entity *entity,
-   struct v4l2_fract *interval);
+   struct v4l2_fract *interval, unsigned int pad);
 
 /**
  * @brief Parse a string and apply format, crop and frame interval settings.
-- 
2.11.0

Re: [PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix

[A Sun]

On 3/30/2017 3:12 AM, Sean Young wrote:
> On Wed, Mar 29, 2017 at 06:04:58PM -0400, A Sun wrote:
>> On 3/29/2017 5:06 PM, Sean Young wrote:
>> 
>>>
>>> Anyway, you're right and this patch looks ok. It would be nice to have the
>>> tx case handled too though.
>>>
>>> Thanks
>>> Sean
>>>
>>
>> Thanks; I'm looking at handling the tx case. If I can figure out the 
>> details, I'll post a new patch proposal separate, and likely dependent, on 
>> this one.
>>
>> My main obstacle at the moment, is I'm looking for a way to get mceusb 
>> device to respond with a USB TX error halt/stall (rather than the typical 
>> ACK and NAK) on a TX endpoint, in order to test halt/stall error detection 
>> and recovery for TX. ..A Sun
> 
> If you send IR, the drivers send a usb packet. However, the kernel will
> sleep for however long the IR is in ir_lirc_transmit_ir, so your other option
> is to set the transmit carrier repeatedly instead. You'd have to set the
> carrier to a different value every time.
> 
> 
> {
>   int fd, carrier;
> 
>   fd = open("/dev/lirc0", O_RDWR);
>   carrier = 38000;
>   for (;;) {
>   ioctl(fd, LIRC_SET_SEND_CARRIER, &carrier);
>   if (++carrier >= 4)
>   carrier = 38000;
>   }
> }
> 
> 
> Sean
> 

Thanks, this is good to know, for testing where multiple TX I/Os are pending 
prior to fault. 

I found a way to set up the TX -EPIPE fault administratively:

retval = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
USB_REQ_SET_FEATURE, USB_RECIP_ENDPOINT,
USB_ENDPOINT_HALT, usb_pipeendpoint(ir->pipe_out),
NULL, 0, USB_CTRL_SET_TIMEOUT);
dev_dbg(ir->dev, "set halt retval, %d", retval);

and have replications now for TX error and lock -out. Error occurs for every 
TX. No message flooding otherwise, as we expect. The RX side remains working.

...
[  249.986174] mceusb 1-1.2:1.0: requesting 38000 HZ carrier
[  249.986210] mceusb 1-1.2:1.0: send request called (size=0x4)
[  249.986256] mceusb 1-1.2:1.0: send request complete (res=0)
[  249.986403] mceusb 1-1.2:1.0: Error: request urb status = -32 (TX HALT)
[  249.999885] mceusb 1-1.2:1.0: send request called (size=0x3)
[  249.29] mceusb 1-1.2:1.0: send request complete (res=0)
[  250.13] mceusb 1-1.2:1.0: Error: request urb status = -32 (TX HALT)
[  250.019830] mceusb 1-1.2:1.0: send request called (size=0x21)
[  250.019868] mceusb 1-1.2:1.0: send request complete (res=0)
[  250.020007] mceusb 1-1.2:1.0: Error: request urb status = -32 (TX HALT)
...

Re: [PATCH v6 00/39] i.MX Media Driver

[Russell King - ARM Linux]

On Thu, Mar 30, 2017 at 09:12:29AM -0700, Steve Longerbeam wrote:
> 
> 
> On 03/30/2017 04:02 AM, Russell King - ARM Linux wrote:
> >This fails at step 1.  The removal of the frame interval support now
> >means my setup script fails when trying to set the frame interval on
> >the camera:
> >
> >Enumerating pads and links
> >Setting up format SRGGB8_1X8 816x616 on pad imx219 0-0010/0
> >Format set: SRGGB8_1X8 816x616
> >Setting up frame interval 1/25 on pad imx219 0-0010/0
> >Frame interval set: 1/25
> >Setting up format SRGGB8_1X8 816x616 on pad imx6-mipi-csi2/0
> >Format set: SRGGB8_1X8 816x616
> >Setting up frame interval 1/25 on pad imx6-mipi-csi2/0
> >Unable to set frame interval: Inappropriate ioctl for device (-25)Unable to 
> >setup formats: Inappropriate ioctl for device (25)
> >
> >This is because media-ctl tries to propagate it from the imx219 source
> >pad to the csi2 sink pad, and the csi2 now fails that ioctl.
> 
> I assume you're using Philipp's frame interval patches to media-ctl.
> Can you make the frame interval propagation optional in those patches?
> I.e. don't error-out with a failure code if the ioctl returns ENOTTY.

Damn, you're right.  There's way too much stuff to try and keep track
of with this stuff.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v6 00/39] i.MX Media Driver

[Steve Longerbeam]

On 03/30/2017 04:02 AM, Russell King - ARM Linux wrote:

This fails at step 1.  The removal of the frame interval support now
means my setup script fails when trying to set the frame interval on
the camera:

Enumerating pads and links
Setting up format SRGGB8_1X8 816x616 on pad imx219 0-0010/0
Format set: SRGGB8_1X8 816x616
Setting up frame interval 1/25 on pad imx219 0-0010/0
Frame interval set: 1/25
Setting up format SRGGB8_1X8 816x616 on pad imx6-mipi-csi2/0
Format set: SRGGB8_1X8 816x616
Setting up frame interval 1/25 on pad imx6-mipi-csi2/0
Unable to set frame interval: Inappropriate ioctl for device (-25)Unable to 
setup formats: Inappropriate ioctl for device (25)

This is because media-ctl tries to propagate it from the imx219 source
pad to the csi2 sink pad, and the csi2 now fails that ioctl.


I assume you're using Philipp's frame interval patches to media-ctl.
Can you make the frame interval propagation optional in those patches?
I.e. don't error-out with a failure code if the ioctl returns ENOTTY.

Steve



This makes media-ctl return a failure code, which means that it's not
possible for a script to determine whether the failure was due to the
camera setup or something else.  So, we have to assume that the
whole command failed.

This is completely broken, and I'm even more convinced that those
arguing for this behaviour really have not thought it through well
enough before demanding that this code was removed.

As far as I'm concerned, the end result is completely broken and
unusable.  I'm going to be merging the frame interval support back
into my test tree, because that's the only sane thing to do.

If v4l2 people want to object to having frame interval support present
for all subdevs, then _they_ need to make sure that the rest of their
software conforms to what they're telling people to do.

[PATCH 2/2] [media] docs-rst: add V4L2_INPUT_TYPE_DEFAULT

[Helen Koike]

add documentation for V4L2_INPUT_TYPE_DEFAULT

Signed-off-by: Helen Koike 
---
 Documentation/media/uapi/v4l/vidioc-enuminput.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-enuminput.rst 
b/Documentation/media/uapi/v4l/vidioc-enuminput.rst
index 17aaaf9..0237e10 100644
--- a/Documentation/media/uapi/v4l/vidioc-enuminput.rst
+++ b/Documentation/media/uapi/v4l/vidioc-enuminput.rst
@@ -112,6 +112,9 @@ at index zero, incrementing by one until the driver returns 
``EINVAL``.
 :stub-columns: 0
 :widths:   3 1 4
 
+* - ``V4L2_INPUT_TYPE_DEFAULT``
+  - 0
+  - This is the default value returned when no input is supported.
 * - ``V4L2_INPUT_TYPE_TUNER``
   - 1
   - This input uses a tuner (RF demodulator).
-- 
2.7.4

[PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Helen Koike]

Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
used when no inputs are available in the device

Signed-off-by: Helen Koike 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
 include/media/v4l2-ioctl.h   | 26 ++
 include/uapi/linux/videodev2.h   |  1 +
 3 files changed, 54 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 0c3f238..ccaf04b 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct video_device 
*vdev, unsigned cmd)
return vdev->lock;
 }
 
+int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
+ struct v4l2_input *i)
+{
+   if (i->index > 0)
+   return -EINVAL;
+
+   memset(i, 0, sizeof(*i));
+   i->type = V4L2_INPUT_TYPE_DEFAULT;
+   strlcpy(i->name, "Default", sizeof(i->name));
+
+   return 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);
+
+int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int *i)
+{
+   *i = 0;
+   return 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
+
+int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int i)
+{
+   return i ? -EINVAL : 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
+
 /* Common ioctl debug function. This function can be used by
external ioctl messages as well as internal V4L ioctl */
 void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 6cd94e5..accc470 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -652,6 +652,32 @@ struct video_device;
  */
 struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned int cmd);
 
+
+/**
+ * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for VIDIOC_ENUM_INPUT 
ioctl
+ *
+ * Plug this function in vidioc_enum_input field of the struct v4l2_ioctl_ops 
to
+ * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT
+ */
+int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
+ struct v4l2_input *i);
+
+/**
+ * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT ioctl
+ *
+ * Plug this function in vidioc_g_input field of the struct v4l2_ioctl_ops
+ * when using v4l2_ioctl_enum_input_default
+ */
+int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int *i);
+
+/**
+ * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT ioctl
+ *
+ * Plug this function in vidioc_s_input field of the struct v4l2_ioctl_ops
+ * when using v4l2_ioctl_enum_input_default
+ */
+int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int i);
+
 /* names for fancy debug output */
 extern const char *v4l2_field_names[];
 extern const char *v4l2_type_names[];
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 316be62..c10bbde 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1477,6 +1477,7 @@ struct v4l2_input {
 };
 
 /*  Values for the 'type' field */
+#define V4L2_INPUT_TYPE_DEFAULT0
 #define V4L2_INPUT_TYPE_TUNER  1
 #define V4L2_INPUT_TYPE_CAMERA 2
 #define V4L2_INPUT_TYPE_TOUCH  3
-- 
2.7.4

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Alan Stern]

On Thu, 30 Mar 2017, Mauro Carvalho Chehab wrote:

> Em Thu, 30 Mar 2017 10:26:32 -0400 (EDT)
> Alan Stern  escreveu:
> 
> > On Thu, 30 Mar 2017, Oliver Neukum wrote:
> > 
> > > > Btw, I'm a lot more concerned about USB storage drivers. When I was
> > > > discussing about this issue at the #raspberrypi-devel IRC channel,
> > > > someone complained that, after switching from the RPi downstream Kernel
> > > > to upstream, his USB data storage got corrupted. Well, if the USB
> > > > storage drivers also assume that the buffer can be continuous,
> > > > that can corrupt data.  
> > 
> > > 
> > > They do assume that.  
> > 
> > Wait a minute.  Where does that assumption occur?
> > 
> > And exactly what is the assumption?  Mauro wrote "the buffer can be 
> > continuous", but that is certainly not what he meant.
> 
> What I meant to say is that drivers like the uvcdriver (and maybe network and
> usb-storage drivers) may allocate a big buffer and get data there on some
> random order, e. g.: 
> 
> int get_from_buf_pos(char *buf, int pos, int size)
> {
>   /* or an equivalent call to usb_submit_urb() */
>   usb_control_msg(..., buf + pos, size, ...);
> }
> 
> some_function ()
> {
>   ...
> 
>   chr *buf = kzalloc(4, GFP_KERNEL);
> 
>   /* 
>* Access the bytes at the array on a random order, with random size,
>* Like:
>*/
>   get_from_buf_pos(buf, 2, 2);/* should read 0x56, 0x78 */
>   get_from_buf_pos(buf, 0, 2);/* should read 0x12, 0x34 */
> 
>   /*
>* the expected value for the buffer would be:
>*  { 0x12, 0x34, 0x56, 0x78 }
>*/
> 
> E. g. they assume that the transfer URB can work with any arbitrary
> pointer and size, without needing of pre-align them.
> 
> This doesn't work with HCD drivers like dwc2, as each USB_IN operation will
> actually write 4 bytes to the buffer.
> 
> So, what happens, instead, is that each data transfer will get four
> bytes. Due to a hack inside dwc2, with checks if the transfer_buffer
> is DWORD aligned. So, the first transfer will do what's expected: it will
> read 4 bytes to a temporary buffer, allocated inside the driver,
> copying just two bytes to buf. So, after the first read, the
> buffer content will be:
> 
>   buf = { 0x00, x00, 0x56, 0x78 }
> 
> But, on the second read, it won't be using any temporary
> buffer. So, instead of reading a 16-bits word (0x5678),
> it will actually read 32 bits, with 16-bits with some random value,
> causing a buffer overflow. E. g. buffer content will now be:
> 
>   buf = { 0x12, x34, 0xde, 0xad }
> 
> In other words, the second transfer corrupted the data from the
> first transfer.

I'm pretty sure that usb-storage does not do this, at least, not when 
operating in its normal Bulk-Only-Transport mode.  It never tries to 
read the results of an earlier transfer after carrying out a later 
transfer to any part of the same buffer.

Alan Stern

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 10:26:32 -0400 (EDT)
Alan Stern  escreveu:

> On Thu, 30 Mar 2017, Oliver Neukum wrote:
> 
> > > Btw, I'm a lot more concerned about USB storage drivers. When I was
> > > discussing about this issue at the #raspberrypi-devel IRC channel,
> > > someone complained that, after switching from the RPi downstream Kernel
> > > to upstream, his USB data storage got corrupted. Well, if the USB
> > > storage drivers also assume that the buffer can be continuous,
> > > that can corrupt data.  
> 
> > 
> > They do assume that.  
> 
> Wait a minute.  Where does that assumption occur?
> 
> And exactly what is the assumption?  Mauro wrote "the buffer can be 
> continuous", but that is certainly not what he meant.

What I meant to say is that drivers like the uvcdriver (and maybe network and
usb-storage drivers) may allocate a big buffer and get data there on some
random order, e. g.: 

int get_from_buf_pos(char *buf, int pos, int size)
{
/* or an equivalent call to usb_submit_urb() */
usb_control_msg(..., buf + pos, size, ...);
}

some_function ()
{
...

chr *buf = kzalloc(4, GFP_KERNEL);

/* 
 * Access the bytes at the array on a random order, with random size,
 * Like:
 */
get_from_buf_pos(buf, 2, 2);/* should read 0x56, 0x78 */
get_from_buf_pos(buf, 0, 2);/* should read 0x12, 0x34 */

/*
 * the expected value for the buffer would be:
 *  { 0x12, 0x34, 0x56, 0x78 }
 */

E. g. they assume that the transfer URB can work with any arbitrary
pointer and size, without needing of pre-align them.

This doesn't work with HCD drivers like dwc2, as each USB_IN operation will
actually write 4 bytes to the buffer.

So, what happens, instead, is that each data transfer will get four
bytes. Due to a hack inside dwc2, with checks if the transfer_buffer
is DWORD aligned. So, the first transfer will do what's expected: it will
read 4 bytes to a temporary buffer, allocated inside the driver,
copying just two bytes to buf. So, after the first read, the
buffer content will be:

buf = { 0x00, x00, 0x56, 0x78 }

But, on the second read, it won't be using any temporary
buffer. So, instead of reading a 16-bits word (0x5678),
it will actually read 32 bits, with 16-bits with some random value,
causing a buffer overflow. E. g. buffer content will now be:

buf = { 0x12, x34, 0xde, 0xad }

In other words, the second transfer corrupted the data from the
first transfer.

Thanks,
Mauro

[PATCH v2 3/8] ARM: dts: stm32: Enable DCMI support on STM32F429 MCU

[Hugues Fruchet]

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32f429.dtsi | 37 +
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index ee0da97..e1ff978 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -736,6 +736,29 @@
slew-rate = <3>;
};
};
+
+   dcmi_pins: dcmi_pins@0 {
+   pins {
+   pinmux = 
,
+
,
+
,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <3>;
+   };
+   };
};
 
rcc: rcc@40023810 {
@@ -805,6 +828,20 @@
status = "disabled";
};
 
+   dcmi: dcmi@5005 {
+   compatible = "st,stm32-dcmi";
+   reg = <0x5005 0x400>;
+   interrupts = <78>;
+   resets = <&rcc STM32F4_AHB2_RESET(DCMI)>;
+   clocks = <&rcc 0 STM32F4_AHB2_CLOCK(DCMI)>;
+   clock-names = "mclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <&dcmi_pins>;
+   dmas = <&dma2 1 1 0x414 0x3>;
+   dma-names = "tx";
+   status = "disabled";
+   };
+
rng: rng@50060800 {
compatible = "st,stm32-rng";
reg = <0x50060800 0x400>;
-- 
1.9.1

[PATCH v2 1/8] dt-bindings: Document STM32 DCMI bindings

[Hugues Fruchet]

This adds documentation of device tree bindings for the STM32 DCMI
(Digital Camera Memory Interface).

Signed-off-by: Hugues Fruchet 
---
 .../devicetree/bindings/media/st,stm32-dcmi.txt| 85 ++
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt

diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt 
b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
new file mode 100644
index 000..8180f63
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
@@ -0,0 +1,85 @@
+STMicroelectronics STM32 Digital Camera Memory Interface (DCMI)
+
+Required properties:
+- compatible: "st,stm32-dcmi"
+- reg: physical base address and length of the registers set for the device
+- interrupts: should contain IRQ line for the DCMI
+- clocks: list of clock specifiers, corresponding to entries in
+  the clock-names property
+- clock-names: must contain "mclk", which is the DCMI peripherial clock
+- resets: reference to a reset controller
+- reset-names: see Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
+
+DCMI supports a single port node with parallel bus. 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.
+
+Example:
+
+Device node example
+---
+   dcmi: dcmi@5005 {
+   compatible = "st,stm32-dcmi";
+   reg = <0x5005 0x400>;
+   interrupts = <78>;
+   resets = <&rcc STM32F4_AHB2_RESET(DCMI)>;
+   clocks = <&rcc 0 STM32F4_AHB2_CLOCK(DCMI)>;
+   clock-names = "mclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <&dcmi_pins>;
+   dmas = <&dma2 1 1 0x414 0x3>;
+   dma-names = "tx";
+   status = "disabled";
+   };
+
+Board setup example
+---
+This example is extracted from STM32F429-EVAL board devicetree.
+Please note that on this board, the camera sensor reset & power-down
+line level are inverted (so reset is active high and power-down is
+active low).
+
+/ {
+   [...]
+   clocks {
+   clk_ext_camera: clk-ext-camera {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   };
+   };
+   [...]
+};
+
+&dcmi {
+   status = "okay";
+
+   port {
+   dcmi_0: endpoint@0 {
+   remote-endpoint = <&ov2640_0>;
+   bus-width = <8>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   };
+   };
+};
+
+&i2c@1 {
+   [...]
+   ov2640: camera@30 {
+   compatible = "ovti,ov2640";
+   reg = <0x30>;
+   resetb-gpios = <&stmpegpio 2 GPIO_ACTIVE_HIGH>;
+   pwdn-gpios = <&stmpegpio 0 GPIO_ACTIVE_LOW>;
+   clocks = <&clk_ext_camera>;
+   clock-names = "xvclk";
+   status = "okay";
+
+   port {
+   ov2640_0: endpoint {
+   remote-endpoint = <&dcmi_0>;
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH v2 4/8] ARM: dts: stm32: Enable DCMI camera interface on STM32F429-EVAL board

[Hugues Fruchet]

Enable DCMI camera interface on STM32F429-EVAL board.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 3c99466..87733d3 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -141,6 +141,15 @@
clock-frequency = <2500>;
 };
 
+&dcmi {
+   status = "okay";
+
+   port {
+   dcmi_0: endpoint@0 {
+   };
+   };
+};
+
 &i2c1 {
pinctrl-0 = <&i2c1_pins>;
pinctrl-names = "default";
-- 
1.9.1

[PATCH v2 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series

[Hugues Fruchet]

This patchset introduces a basic support for Digital Camera Memory Interface
(DCMI) of STMicroelectronics STM32 SoC series.

This first basic support implements RGB565 & YUV frame grabbing.
Cropping and JPEG support will be added later on.

This has been tested on STM324x9I-EVAL evaluation board embedding
an OV2640 camera sensor.

This driver depends on:
  - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers 
http://www.spinics.net/lists/linux-media/msg113480.html

===
= history =
===
version 2:
  - Fix a Kbuild warning in probe:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg110678.html
  - Fix a warning in dcmi_queue_setup()
  - dt-bindings: warn on sensor signals level inversion in board example
  - Typos fixing

version 1:
  - Initial submission

===
= v4l2-compliance =
===
Below is the v4l2-compliance report for this current version of the DCMI camera 
interface.
v4l2-compliance has been built from v4l-utils-1.12.3.

v4l2-compliance SHA   : f5f45e17ee98a0ebad7836ade2b34ceec909d751

Driver Info:
Driver name   : stm32-dcmi
Card type : STM32 Digital Camera Memory Int
Bus info  : platform:dcmi
Driver version: 4.11.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
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 3 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:

Streaming ioctls:
test read/write: OK
test MMAP: OK
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device


Total: 46, Succeeded: 46, Failed: 0, Warnings: 0

Hugues Fruchet (8):
  dt-bindings: Document STM32 DCMI bindings
  [media] stm32-dcmi: STM32 DCMI camera interface driver
  ARM: dts: stm32: Enable DCMI support on STM32F429 MCU
  ARM: dts: stm32: Enable DCMI camera interface on STM32F429-EVAL board
  ARM: dts: stm32: Enable STMPE1600 gpio expander of STM32F429-EVAL
board
  ARM: dts: stm32: Enable OV2640 camera support of STM32F429-EVAL board
  ARM: configs: stm32: STMPE1600 GPIO expander
  ARM: configs: stm32: DCMI + OV2640 camera support

 .../devicetree/bindings/media/st,stm32-d

Re: [PATCH 1/2] staging: atomisp: simplify the if condition in atomisp_freq_scaling()

[DaeSeok Youn]

2017-03-30 19:52 GMT+09:00 Alan Cox :
> On Thu, 2017-03-30 at 15:24 +0900, Daeseok Youn wrote:
>> The condition line in if-statement is needed to be shorthen to
>> improve readability.
>>
>> Signed-off-by: Daeseok Youn 
>> ---
>
> How about a define for ATOMISP_IS_CHT(isp) instead - as we will need
hmm.. I think there is another way to get a *device*(unsigned short or
__u32) to mask with "ATOMISP_PCI_DEVICE_SOC_MASK".
In the atomisp_freq_scaling() function, the "device" value is getting
started from "isp" structure.
(isp->pdev->device)

if the function has only "pci_dev" struction as a parameter and it
need to check the CHT. Then we cannot use the definition like
ATOMISP_IS_CHT(isp). it means we have another definition to check the
CHT.

Am I right?

> these tests in other places where there are ISP2400/ISP2401 ifdefs ?
I am not sure whether these tests are needed in other place or not.
(Actually, I didn't find good H/W reference for Atom ISP device - Can
you please share the link to refer document like H/W manual to
develop?) I have tried to clean up the code first. in the meantime, I
will have a look at the document if I have good reference manual.

Thanks.
Regards,
Daeseok.
>
> Alan
>

[PATCH] [media] docs-rst: clarify field vs frame height in the subdev API

[Philipp Zabel]

VIDIOC_SUBDEV_G/S_FMT take the field size if V4L2_FIELD_ALTERNATE field
order is set, but the VIDIOC_SUBDEV_G/S_SELECTION rectangles still refer
to frame size, regardless of the field order setting.
VIDIOC_SUBDEV_ENUM_FRAME_SIZES always returns frame sizes as opposed to
field sizes.

This was not immediately clear to me when reading the documentation, so
this patch adds some clarifications in the relevant places.

Suggested-by: Laurent Pinchart 
Signed-off-by: Philipp Zabel 
---
 Documentation/media/uapi/v4l/dev-subdev.rst  | 16 
 Documentation/media/uapi/v4l/subdev-formats.rst  |  3 ++-
 .../media/uapi/v4l/vidioc-subdev-enum-frame-size.rst |  4 
 .../media/uapi/v4l/vidioc-subdev-g-selection.rst |  2 ++
 4 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/Documentation/media/uapi/v4l/dev-subdev.rst 
b/Documentation/media/uapi/v4l/dev-subdev.rst
index cd28701802086..2f0a41f3796f0 100644
--- a/Documentation/media/uapi/v4l/dev-subdev.rst
+++ b/Documentation/media/uapi/v4l/dev-subdev.rst
@@ -82,7 +82,8 @@ Pad-level Formats
 .. note::
 
 For the purpose of this section, the term *format* means the
-combination of media bus data format, frame width and frame height.
+combination of media bus data format, frame width and frame height,
+unless otherwise noted.
 
 Image formats are typically negotiated on video capture and output
 devices using the format and
@@ -120,7 +121,9 @@ can expose pad-level image format configuration to 
applications. When
 they do, applications can use the
 :ref:`VIDIOC_SUBDEV_G_FMT ` and
 :ref:`VIDIOC_SUBDEV_S_FMT ` ioctls. to
-negotiate formats on a per-pad basis.
+negotiate formats on a per-pad basis. Note that when those ioctls are
+called with or return the field order set to ``V4L2_FIELD_ALTERNATE``,
+the format contains the field height, which is half the frame height.
 
 Applications are responsible for configuring coherent parameters on the
 whole pipeline and making sure that connected pads have compatible
@@ -379,7 +382,10 @@ is supported by the hardware.
pad for further processing.
 
 2. Sink pad actual crop selection. The sink pad crop defines the crop
-   performed to the sink pad format.
+   performed to the sink pad format. The crop rectangle always refers to
+   the frame size, even if the sink pad format has field order set to
+   ``V4L2_FIELD_ALTERNATE`` and the actual processed images are only
+   field sized.
 
 3. Sink pad actual compose selection. The size of the sink pad compose
rectangle defines the scaling ratio compared to the size of the sink
@@ -393,7 +399,9 @@ is supported by the hardware.
 5. Source pad format. The source pad format defines the output pixel
format of the subdev, as well as the other parameters with the
exception of the image width and height. Width and height are defined
-   by the size of the source pad actual crop selection.
+   by the size of the source pad actual crop selection. If the source pad
+   format has field order set to ``V4L2_FIELD_ALTERNATE``, the source pad
+   field height is half the source pad crop selection height.
 
 Accessing any of the above rectangles not supported by the subdev will
 return ``EINVAL``. Any rectangle referring to a previous unsupported
diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index d6152c907b8ba..f7195e5ee6e78 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -19,7 +19,8 @@ Media Bus Formats
   - Image width, in pixels.
 * - __u32
   - ``height``
-  - Image height, in pixels.
+  - Image height, in pixels. This is the field height for
+``V4L2_FIELD_ALTERNATE`` field order, or the frame height otherwise.
 * - __u32
   - ``code``
   - Format code, from enum
diff --git a/Documentation/media/uapi/v4l/vidioc-subdev-enum-frame-size.rst 
b/Documentation/media/uapi/v4l/vidioc-subdev-enum-frame-size.rst
index 746c24ed97a05..a78ae138f8a87 100644
--- a/Documentation/media/uapi/v4l/vidioc-subdev-enum-frame-size.rst
+++ b/Documentation/media/uapi/v4l/vidioc-subdev-enum-frame-size.rst
@@ -55,6 +55,10 @@ maximum values. Applications must use the
 :ref:`VIDIOC_SUBDEV_S_FMT ` ioctl to try the
 sub-device for an exact supported frame size.
 
+Note that if ``V4L2_FIELD_ALTERNATE`` field order is chosen in the
+:ref:`VIDIOC_SUBDEV_S_FMT ` ioctls, those take
+the field size, which is only half the height of the frame size.
+
 Available frame sizes may depend on the current 'try' formats at other
 pads of the sub-device, as well as on the current active links and the
 current values of V4L2 controls. See
diff --git a/Documentation/media/uapi/v4l/vidioc-subdev-g-selection.rst 
b/Documentation/media/uapi/v4l/vidioc-subdev-g-selection.rst
index 071d9c033db6b..253e0ccb78224 100644
--- a/Documentation/media/uapi/v4l/vidioc-subdev-g-selection.rst
+++ b/Docume

[PATCH v2 5/8] ARM: dts: stm32: Enable STMPE1600 gpio expander of STM32F429-EVAL board

[Hugues Fruchet]

Enable STMPE1600 gpio expander of STM32F429-EVAL board.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 87733d3..7ffcf07 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -154,6 +154,23 @@
pinctrl-0 = <&i2c1_pins>;
pinctrl-names = "default";
status = "okay";
+
+   stmpe1600: stmpe1600@42 {
+   compatible = "st,stmpe1600";
+   reg = <0x42>;
+   irq-gpio = <&gpioi 8 0>;
+   irq-trigger = <3>;
+   interrupts = <8 3>;
+   interrupt-parent = <&exti>;
+   interrupt-controller;
+   wakeup-source;
+
+   stmpegpio: stmpe_gpio {
+   compatible = "st,stmpe-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+   };
 };
 
 &mac {
-- 
1.9.1

[PATCH v2 8/8] ARM: configs: stm32: DCMI + OV2640 camera support

[Hugues Fruchet]

Enable DCMI camera interface and OV2640 camera sensor drivers.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/configs/stm32_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 84adc88..3f2e4ce 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -53,6 +53,13 @@ CONFIG_GPIO_STMPE=y
 CONFIG_MFD_STMPE=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 # CONFIG_USB_SUPPORT is not set
+CONFIG_VIDEO_V4L2=y
+CONFIG_MEDIA_SUBDRV_AUTOSELECT=n
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_VIDEO_STM32_DCMI=y
+CONFIG_VIDEO_OV2640=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
-- 
1.9.1

[PATCH v2 7/8] ARM: configs: stm32: STMPE1600 GPIO expander

[Hugues Fruchet]

Enable STMPE1600 GPIO expander.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/configs/stm32_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index a9d8e3c..84adc88 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -49,6 +49,8 @@ CONFIG_SERIAL_STM32_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
 CONFIG_REGULATOR=y
+CONFIG_GPIO_STMPE=y
+CONFIG_MFD_STMPE=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_NEW_LEDS=y
-- 
1.9.1

[PATCH v2 2/8] [media] stm32-dcmi: STM32 DCMI camera interface driver

[Hugues Fruchet]

This V4L2 subdev driver enables Digital Camera Memory Interface (DCMI)
of STMicroelectronics STM32 SoC series.

Signed-off-by: Yannick Fertre 
Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig|   12 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/stm32/Makefile |1 +
 drivers/media/platform/stm32/stm32-dcmi.c | 1417 +
 4 files changed, 1432 insertions(+)
 create mode 100644 drivers/media/platform/stm32/Makefile
 create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ab0bb48..3421965 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -114,6 +114,18 @@ config VIDEO_S3C_CAMIF
  To compile this driver as a module, choose M here: the module
  will be called s3c-camif.
 
+config VIDEO_STM32_DCMI
+   tristate "Digital Camera Memory Interface (DCMI) support"
+   depends on VIDEO_V4L2 && OF && HAS_DMA
+   depends on ARCH_STM32 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ This module makes the STM32 Digital Camera Memory Interface (DCMI)
+ available as a v4l2 device.
+
+ To compile this driver as a module, choose M here: the module
+ will be called stm32-dcmi.
+
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 8959f6e..d747715 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -64,6 +64,8 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)  += rcar-vin/
 
 obj-$(CONFIG_VIDEO_ATMEL_ISC)  += atmel/
 
+obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32/
+
 ccflags-y += -I$(srctree)/drivers/media/i2c
 
 obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
diff --git a/drivers/media/platform/stm32/Makefile 
b/drivers/media/platform/stm32/Makefile
new file mode 100644
index 000..9b606a7
--- /dev/null
+++ b/drivers/media/platform/stm32/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32-dcmi.o
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c 
b/drivers/media/platform/stm32/stm32-dcmi.c
new file mode 100644
index 000..cd22835
--- /dev/null
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -0,0 +1,1417 @@
+/*
+ * Driver for STM32 Digital Camera Memory Interface
+ *
+ * Copyright (C) STMicroelectronics SA 2017
+ * Authors: Yannick Fertre 
+ *  Hugues Fruchet 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ * This driver is based on atmel_isi.c
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "stm32-dcmi"
+
+/* Registers offset for DCMI */
+#define DCMI_CR0x00 /* Control Register */
+#define DCMI_SR0x04 /* Status Register */
+#define DCMI_RIS   0x08 /* Raw Interrupt Status register */
+#define DCMI_IER   0x0C /* Interrupt Enable Register */
+#define DCMI_MIS   0x10 /* Masked Interrupt Status register */
+#define DCMI_ICR   0x14 /* Interrupt Clear Register */
+#define DCMI_ESCR  0x18 /* Embedded Synchronization Code Register */
+#define DCMI_ESUR  0x1C /* Embedded Synchronization Unmask Register */
+#define DCMI_CWSTRT0x20 /* Crop Window STaRT */
+#define DCMI_CWSIZE0x24 /* Crop Window SIZE */
+#define DCMI_DR0x28 /* Data Register */
+#define DCMI_IDR   0x2C /* IDentifier Register */
+
+/* Bits definition for control register (DCMI_CR) */
+#define CR_CAPTURE BIT(0)
+#define CR_CM  BIT(1)
+#define CR_CROPBIT(2)
+#define CR_JPEGBIT(3)
+#define CR_ESS BIT(4)
+#define CR_PCKPOL  BIT(5)
+#define CR_HSPOL   BIT(6)
+#define CR_VSPOL   BIT(7)
+#define CR_FCRC_0  BIT(8)
+#define CR_FCRC_1  BIT(9)
+#define CR_EDM_0   BIT(10)
+#define CR_EDM_1   BIT(11)
+#define CR_ENABLE  BIT(14)
+
+/* Bits definition for status register (DCMI_SR) */
+#define SR_HSYNC   BIT(0)
+#define SR_VSYNC   BIT(1)
+#define SR_FNE BIT(2)
+
+/*
+ * Bits definition for interrupt registers
+ * (DCMI_RIS, DCMI_IER, DCMI_MIS, DCMI_ICR)
+ */
+#define IT_FRAME   BIT(0)
+#define IT_OVR BIT(1)
+#define IT_ERR BIT(2)
+#define IT_VSYNC   BIT(3)
+#define IT_LINEBIT(4)
+
+enum state {
+   STOPPED = 0,
+   RUNNING,
+   STOPPING,
+};
+
+#define MAX_BUS_WIDTH  14
+#define MAX_SUPPORT_WIDTH  2048
+#define MAX_SUPPORT_HEIGHT 2048
+#define MIN_SUPPORT_WIDTH  16
+#define MIN_SUPPORT_HEIGHT 16
+#define TIMEOUT_MS   

[PATCH v2 6/8] ARM: dts: stm32: Enable OV2640 camera support of STM32F429-EVAL board

[Hugues Fruchet]

Enable OV2640 camera support of STM32F429-EVAL board.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 7ffcf07..b7d127c 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -48,6 +48,7 @@
 /dts-v1/;
 #include "stm32f429.dtsi"
 #include 
+#include 
 
 / {
model = "STMicroelectronics STM32429i-EVAL board";
@@ -66,6 +67,14 @@
serial0 = &usart1;
};
 
+   clocks {
+   clk_ext_camera: clk-ext-camera {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   };
+   };
+
soc {
dma-ranges = <0xc000 0x0 0x1000>;
};
@@ -146,6 +155,11 @@
 
port {
dcmi_0: endpoint@0 {
+   remote-endpoint = <&ov2640_0>;
+   bus-width = <8>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
};
};
 };
@@ -155,6 +169,22 @@
pinctrl-names = "default";
status = "okay";
 
+   ov2640: camera@30 {
+   compatible = "ovti,ov2640";
+   reg = <0x30>;
+   resetb-gpios = <&stmpegpio 2 GPIO_ACTIVE_HIGH>;
+   pwdn-gpios = <&stmpegpio 0 GPIO_ACTIVE_LOW>;
+   clocks = <&clk_ext_camera>;
+   clock-names = "xvclk";
+   status = "okay";
+
+   port {
+   ov2640_0: endpoint {
+   remote-endpoint = <&dcmi_0>;
+   };
+   };
+   };
+
stmpe1600: stmpe1600@42 {
compatible = "st,stmpe1600";
reg = <0x42>;
-- 
1.9.1

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Alan Stern]

On Thu, 30 Mar 2017, Oliver Neukum wrote:

> > Btw, I'm a lot more concerned about USB storage drivers. When I was
> > discussing about this issue at the #raspberrypi-devel IRC channel,
> > someone complained that, after switching from the RPi downstream Kernel
> > to upstream, his USB data storage got corrupted. Well, if the USB
> > storage drivers also assume that the buffer can be continuous,
> > that can corrupt data.

> 
> They do assume that.

Wait a minute.  Where does that assumption occur?

And exactly what is the assumption?  Mauro wrote "the buffer can be 
continuous", but that is certainly not what he meant.

Alan Stern

Re: [PATCH 3/3] [media] cobalt: Use v4l2_calc_timeperframe helper

[Hans Verkuil]

Hi Jose,

On 21/03/17 12:49, Jose Abreu wrote:
> Currently, cobalt driver always returns 60fps in g_parm.
> This patch uses the new v4l2_calc_timeperframe helper to
> calculate the time per frame value.

I can verify that g_parm works, so:

Tested-by: Hans Verkuil 

However, the adv7604 pixelclock detection resolution is only 0.25 MHz, so it
can't tell the difference between 24 and 23.97 Hz. I can't set the new
V4L2_DV_FL_CAN_DETECT_REDUCED_FPS flag there.

It might be possible to implement this for the adv7842 receiver, I think that
that hardware is much more precise.

I would have to try this, but that will have to wait until Friday next week.

Regards,

Hans

> 
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Mauro Carvalho Chehab 
> Cc: Hans Verkuil 
> Cc: linux-media@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/media/pci/cobalt/cobalt-v4l2.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c 
> b/drivers/media/pci/cobalt/cobalt-v4l2.c
> index def4a3b..25532ae 100644
> --- a/drivers/media/pci/cobalt/cobalt-v4l2.c
> +++ b/drivers/media/pci/cobalt/cobalt-v4l2.c
> @@ -1076,10 +1076,15 @@ static int cobalt_subscribe_event(struct v4l2_fh *fh,
>  
>  static int cobalt_g_parm(struct file *file, void *fh, struct v4l2_streamparm 
> *a)
>  {
> + struct cobalt_stream *s = video_drvdata(file);
> + struct v4l2_fract fps;
> +
>   if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>   return -EINVAL;
> - a->parm.capture.timeperframe.numerator = 1;
> - a->parm.capture.timeperframe.denominator = 60;
> +
> + fps = v4l2_calc_timeperframe(&s->timings);
> + a->parm.capture.timeperframe.numerator = fps.numerator;
> + a->parm.capture.timeperframe.denominator = fps.denominator;
>   a->parm.capture.readbuffers = 3;
>   return 0;
>  }
> 

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Oliver Neukum]

Am Donnerstag, den 30.03.2017, 07:28 -0300 schrieb Mauro Carvalho
Chehab:
> Em Thu, 30 Mar 2017 12:34:32 +0300
> Laurent Pinchart  escreveu:
> 
> > 

Hi,

> > > That effectively changes the API. Many network drivers are written with
> > > the assumption that any contiguous buffer is valid. In fact you could
> > > argue that those drivers are buggy and must use bounce buffers in those
> > > cases.
> 
> Blaming the dwc2 driver was my first approach, but such patch got nacked ;)

That I am afraid was a mistake in a certain sense. This belongs into
usbcore. It does not belong into controller drivers or device drivers.

> Btw, the dwc2 driver has a routine that creates a temporary buffer if the
> buffer pointer is not DWORD aligned. My first approach were to add
> a logic there to also use the temporary buffer if the buffer size is
> not DWORD aligned:
>   https://patchwork.linuxtv.org/patch/40093/
> 
> While debugging this issue, I saw *a lot* of network-generated URB
> traffic from RPi3 Ethernet port drivers that were using non-aligned 
> buffers and were subject to the temporary buffer conversion.
> 
> My understanding here is that having a temporary bounce buffer sucks,
> as the performance and latency are affected. So, I see the value of

If you need it, you need it. Doing this in the device driver isn't any
less problematic in terms of performance. The only thing we can do
is do it in a central place to avoid code duplication.

> adding this constraint to the API, pushing the task of getting 
> aligned buffers to the USB drivers, but you're right: that means a lot
> of work, as all USB drivers should be reviewed.

And it is wrong. To be blunt: The important drivers are EHCI and XHCI.
We must not degrade performance with them for the sake of controllers
with less capabilities.

> Btw, I'm a lot more concerned about USB storage drivers. When I was
> discussing about this issue at the #raspberrypi-devel IRC channel,
> someone complained that, after switching from the RPi downstream Kernel
> to upstream, his USB data storage got corrupted. Well, if the USB
> storage drivers also assume that the buffer can be continuous,
> that can corrupt data.
> 
> That's why I think that being verbose here is a good idea.

They do assume that.

> I'll rework on this patch to put more emphasis about this issue.

For now that is the best. But even in the medium term this sucks.
At a minimum controller drivers need to export what they can do.

Regards
Oliver

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 15:05:30 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Thursday 30 Mar 2017 07:28:00 Mauro Carvalho Chehab wrote:
> > Em Thu, 30 Mar 2017 12:34:32 +0300 Laurent Pinchart escreveu:  
> > > On Thursday 30 Mar 2017 10:11:31 Oliver Neukum wrote:  
> > >> Am Donnerstag, den 30.03.2017, 01:15 +0300 schrieb Laurent Pinchart:  
> >  +   may also override PAD bytes at the end of the
> >  ``transfer_buffer``, up to the
> >  +   size of the CPU word.  
> > >>> 
> > >>> "May" is quite weak here. If some host controller drivers require
> > >>> buffers to be aligned, then it's an API requirement, and all buffers
> > >>> must be aligned. I'm not even sure I would mention that some host
> > >>> drivers require it, I think we should just state that the API requires
> > >>> buffers to be aligned.  
> > >> 
> > >> That effectively changes the API. Many network drivers are written with
> > >> the assumption that any contiguous buffer is valid. In fact you could
> > >> argue that those drivers are buggy and must use bounce buffers in those
> > >> cases.  
> > 
> > Blaming the dwc2 driver was my first approach, but such patch got nacked ;)
> > 
> > Btw, the dwc2 driver has a routine that creates a temporary buffer if the
> > buffer pointer is not DWORD aligned. My first approach were to add
> > a logic there to also use the temporary buffer if the buffer size is
> > not DWORD aligned:
> > https://patchwork.linuxtv.org/patch/40093/
> > 
> > While debugging this issue, I saw *a lot* of network-generated URB
> > traffic from RPi3 Ethernet port drivers that were using non-aligned
> > buffers and were subject to the temporary buffer conversion.
> > 
> > My understanding here is that having a temporary bounce buffer sucks,
> > as the performance and latency are affected. So, I see the value of
> > adding this constraint to the API, pushing the task of getting
> > aligned buffers to the USB drivers,  
> 
> This could however degrade performances when the HCD can handle unaligned 
> buffers.

No, it won't degrade performance out there, except if the driver
would need to do double buffering due to such constraint. 

It will just waste memory.

> 
> > but you're right: that means a lot of work, as all USB drivers should be
> > reviewed.  
> 
> If we decide in the end to push the constraint on the USB device driver side, 
> then the dwc2 HCD driver should return an error when the buffer isn't 
> correctly aligned.

Yeah, with such constraint, either the HCD drivers or the USB core
should complain.

There is another option: to add a field, filled by te USB driver,
telling the core that the buffer is aligned, e. g. drivers would
be doing something like:

urb->transfer_buffer_align = 4;

Something similar could be filled by the HCD driver:

hc_driver->transfer_buffer_align = 4;

The core will then check if the alignment required by the HCD driver
is compatible with the buffer alignment ensured by the USB driver.
If it doesn't, then the core would create a temporary buffer for the
transfers.

No idea about how easy/hard would be to implement something like
that.

In such case, it could make sense to generate a warning that
the driver should be fixed, or that the performance would
decrease due to double-buffering.

Thanks,
Mauro

Re: [PATCH 02/22] docs-rst: convert usb docbooks to ReST

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 13:17:16 +0200
Markus Heiser  escreveu:

> Am 30.03.2017 um 12:12 schrieb Mauro Carvalho Chehab 
> :
> >>> At this point I'd just go with what Mauro has. It's here now, as
> >>> patches. We've seen from the GPU documentation that polishing the
> >>> one-time initial conversion is, after a point, wasted effort. Having the
> >>> documentation in rst attracts more attention and contributions, and any
> >>> remaining issues will get ironed out in rst.
> >> 
> >> I totally agree with you (I have never said something different)
> >>   
> >>> This is also one reason I'm in favor of just bulk converting the rest of
> >>> the .tmpl files using Documentation/sphinx/tmplcvt, get rid of DocBook
> >>> and be done with it, and have the crowds focus on rst.
> >> 
> >> I also agree with that. The tmplcvt script is good enough for this task,
> >> the dbxml2rst tool is more elaborate.  
> > 
> > I like the idea of a bulk conversion. My personal preference here is to
> > use the tmplcvt for such task, at least for simple books like the ones
> > I converted from USB.
> > 
> > The advantage is that it places everything on a single rst file, with,
> > IMHO, works best for books that aren't too complex.
> > Of course, it doesn't hurt to compare the end result with dbxml2rst
> > and see if something could be improved.  
> 
> If it helps ... dbxml2rst also supports single file conversion  ... I updated:
> 
>   
> https://github.com/return42/sphkerneldoc/tree/master/Documentation/books_migrated

Ok, I double-checked the results from dbxml2rst with pandoc (via
the script). Those are the differences after running the following commands:

$ wget 
https://raw.githubusercontent.com/return42/sphkerneldoc/master/Documentation/books_migrated/writing_usb_driver/index.rst
$ Documentation/sphinx/tmplcvt 
Documentation/DocBook/writing_usb_driver.tmpl writing_usb_driver.rst
$ diff -uprBw writing_usb_driver.rst index.rst 

1) Author data:

-:Author: Greg Kroah-Hartman
+:author:Kroah-Hartman Greg
+:address:   g...@kroah.com

dbxml2rst inverted the author's name.  It also added author's e-mail.

IMHO, it is better to not have email address there, as it could be
outdated, but this is just my personal preference.

2) dbxml2rst added a copyright information:

+**Copyright** 2001-2002 : Greg Kroah-Hartman

This is a good thing.

3) dbxml2rst added a GPL information.

IMHO, we should add just one GPL information, per hole book
(and not per converted file).

4) dbxml2rst created some references that won't be unique:

+.. _intro:

That's a bad thing, as I bet most converted documents will have "intro"
sections.

5) dbxml2rst use ".. code-block:: c" instead of "::"

I prefer using "::"

6) dbxml2rst appends a commentary at the end:

+.. 
--
+.. This file was automatically converted from DocBook-XML with the dbxml
+.. library (https://github.com/return42/dbxml2rst). The origin XML comes
+.. from the linux kernel:
+..
+..   http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
+.. 
--

7) dbxml2rst did a worse job with URB conversions:

-USB Home Page: http://www.usb.org
+USB Home Page: `http://www.usb.org `__

So, in summary, at least for this document, the only thing good with
dbxml2rst was that it filled the copyright info.

Maybe for more complex documents, it would do a better job.

Yet, in order to standardize it everywhere, I guess the best would be to
produce copyright data like:

.. include:: 

:Copyright: |copy| 2001-2002 : Greg Kroah-Hartman

Regards,
Mauro

[PATCH] v4l2-compat-ioctl32: VIDIOC_S_EDID should return all fields on error.

[Hans Verkuil]

Most ioctls do not have to write back the contents of the argument
if an error is returned. But VIDIOC_S_EDID is an exception together
with the EXT_CTRLS ioctls (already handled correctly).

Add this exception to v4l2-compat-ioctl32.

This fixes a compliance error when using compat32 and trying to
set a new EDID with more blocks than the hardware supports. In
that case the driver will return -E2BIG and set edid.blocks to the
actual maximum number of blocks. This field was never copied back
to userspace due to this bug.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index b9caaf7fa828..5f29e18868f8 100755
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -956,6 +956,10 @@ static long do_video_ioctl(struct file *file, unsigned int 
cmd, unsigned long ar
if (put_v4l2_ext_controls32(&karg.v2ecs, up))
err = -EFAULT;
break;
+   case VIDIOC_S_EDID:
+   if (put_v4l2_edid32(&karg.v2edid, up))
+   err = -EFAULT;
+   break;
}
if (err)
return err;
@@ -977,7 +981,6 @@ static long do_video_ioctl(struct file *file, unsigned int 
cmd, unsigned long ar
break;

case VIDIOC_G_EDID:
-   case VIDIOC_S_EDID:
err = put_v4l2_edid32(&karg.v2edid, up);
break;

-- 
2.11.0

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Laurent Pinchart]

Hi Mauro,

On Thursday 30 Mar 2017 07:28:00 Mauro Carvalho Chehab wrote:
> Em Thu, 30 Mar 2017 12:34:32 +0300 Laurent Pinchart escreveu:
> > On Thursday 30 Mar 2017 10:11:31 Oliver Neukum wrote:
> >> Am Donnerstag, den 30.03.2017, 01:15 +0300 schrieb Laurent Pinchart:
>  +   may also override PAD bytes at the end of the
>  ``transfer_buffer``, up to the
>  +   size of the CPU word.
> >>> 
> >>> "May" is quite weak here. If some host controller drivers require
> >>> buffers to be aligned, then it's an API requirement, and all buffers
> >>> must be aligned. I'm not even sure I would mention that some host
> >>> drivers require it, I think we should just state that the API requires
> >>> buffers to be aligned.
> >> 
> >> That effectively changes the API. Many network drivers are written with
> >> the assumption that any contiguous buffer is valid. In fact you could
> >> argue that those drivers are buggy and must use bounce buffers in those
> >> cases.
> 
> Blaming the dwc2 driver was my first approach, but such patch got nacked ;)
> 
> Btw, the dwc2 driver has a routine that creates a temporary buffer if the
> buffer pointer is not DWORD aligned. My first approach were to add
> a logic there to also use the temporary buffer if the buffer size is
> not DWORD aligned:
>   https://patchwork.linuxtv.org/patch/40093/
> 
> While debugging this issue, I saw *a lot* of network-generated URB
> traffic from RPi3 Ethernet port drivers that were using non-aligned
> buffers and were subject to the temporary buffer conversion.
> 
> My understanding here is that having a temporary bounce buffer sucks,
> as the performance and latency are affected. So, I see the value of
> adding this constraint to the API, pushing the task of getting
> aligned buffers to the USB drivers,

This could however degrade performances when the HCD can handle unaligned 
buffers.

> but you're right: that means a lot of work, as all USB drivers should be
> reviewed.

If we decide in the end to push the constraint on the USB device driver side, 
then the dwc2 HCD driver should return an error when the buffer isn't 
correctly aligned.

> Btw, I'm a lot more concerned about USB storage drivers. When I was
> discussing about this issue at the #raspberrypi-devel IRC channel,
> someone complained that, after switching from the RPi downstream Kernel
> to upstream, his USB data storage got corrupted. Well, if the USB
> storage drivers also assume that the buffer can be continuous,
> that can corrupt data.
> 
> That's why I think that being verbose here is a good idea.
> 
> I'll rework on this patch to put more emphasis about this issue.
> 
> >> So we need to include the full story here.
> > 
> > I personally don't care much about whose side is responsible for handling
> > the alignment constraints, but I want it to be documented before "fixing"
> > any USB driver.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 01/22] tmplcvt: make the tool more robust

[Jani Nikula]

On Thu, 30 Mar 2017, Mauro Carvalho Chehab  wrote:
> Currently, the script just assumes to be called at
> Documentation/sphinx/. Change it to work on any directory,
> and make it abort if something gets wrong.
>
> Also, be sure that both parameters are specified.
>
> That should avoid troubles like this:
>
> $ Documentation/sphinx/tmplcvt Documentation/DocBook/writing_usb_driver.tmpl
> sed: couldn't open file convert_template.sed: No such file or directory
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/sphinx/tmplcvt | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/sphinx/tmplcvt b/Documentation/sphinx/tmplcvt
> index 909a73065e0a..31df8eb7feca 100755
> --- a/Documentation/sphinx/tmplcvt
> +++ b/Documentation/sphinx/tmplcvt
> @@ -7,13 +7,22 @@
>  # fix \_
>  # title line?
>  #
> +set -eu
> +
> +if [ "$2" == "" ]; then

if [ "$#" != "2" ]; then

otherwise with set -u you'll get unbound variable error if you don't
provide $2.

BR,
Jani.

> + echo "$0  "
> + exit
> +fi
> +
> +DIR=$(dirname $0)
>  
>  in=$1
>  rst=$2
>  tmp=$rst.tmp
>  
>  cp $in $tmp
> -sed --in-place -f convert_template.sed $tmp
> +sed --in-place -f $DIR/convert_template.sed $tmp
>  pandoc -s -S -f docbook -t rst -o $rst $tmp
> -sed --in-place -f post_convert.sed $rst
> +sed --in-place -f $DIR/post_convert.sed $rst
>  rm $tmp
> +echo "book writen to $rst"

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 02/22] docs-rst: convert usb docbooks to ReST

[Markus Heiser]

Am 30.03.2017 um 13:17 schrieb Markus Heiser :
> 
> If it helps ... dbxml2rst also supports single file conversion  ... I updated:
> 
>  
> https://github.com/return42/sphkerneldoc/tree/master/Documentation/books_migrated
> 
> There you find a folder for each DocBook conversion with only one rst file 
> (index.rst)
> in .. If you like, use it for comparison.

Forget to mentioning one of the main benefits: 

The conversion with dbxml2rst produce tables with directive ".. flat-table::"
instead of building ASCII tables (like pandoc does).

-- Markus --

Re: [PATCH 02/22] docs-rst: convert usb docbooks to ReST

[Markus Heiser]

Am 30.03.2017 um 12:12 schrieb Mauro Carvalho Chehab :
>>> At this point I'd just go with what Mauro has. It's here now, as
>>> patches. We've seen from the GPU documentation that polishing the
>>> one-time initial conversion is, after a point, wasted effort. Having the
>>> documentation in rst attracts more attention and contributions, and any
>>> remaining issues will get ironed out in rst.  
>> 
>> I totally agree with you (I have never said something different)
>> 
>>> This is also one reason I'm in favor of just bulk converting the rest of
>>> the .tmpl files using Documentation/sphinx/tmplcvt, get rid of DocBook
>>> and be done with it, and have the crowds focus on rst.  
>> 
>> I also agree with that. The tmplcvt script is good enough for this task,
>> the dbxml2rst tool is more elaborate.
> 
> I like the idea of a bulk conversion. My personal preference here is to
> use the tmplcvt for such task, at least for simple books like the ones
> I converted from USB.
> 
> The advantage is that it places everything on a single rst file, with,
> IMHO, works best for books that aren't too complex.
> Of course, it doesn't hurt to compare the end result with dbxml2rst
> and see if something could be improved.

If it helps ... dbxml2rst also supports single file conversion  ... I updated:

  
https://github.com/return42/sphkerneldoc/tree/master/Documentation/books_migrated

There you find a folder for each DocBook conversion with only one rst file 
(index.rst)
in .. If you like, use it for comparison.

-- Markus --

RE: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[David Laight]

From: Mauro Carvalho Chehab
> Sent: 30 March 2017 11:28
...
> While debugging this issue, I saw *a lot* of network-generated URB
> traffic from RPi3 Ethernet port drivers that were using non-aligned
> buffers and were subject to the temporary buffer conversion.

Buffers from the network stack will almost always be 4n+2 aligned.
Receive data being fed into the network stack really needs to be
4n=2 aligned.

The USB stack almost certainly has to live with that.

If the USB ethernet device doesn't have two bytes of 'pad' before
the frame data (destination MAC address) then you have to solve
the problem within the USB stack.

For transmits it might be possible to send an initial 2 byte fragment
from a separate buffer - but only if arbitrary fragment sizes are
allowed.
A normal USB3 controller should allow this - but you have to be very
careful about what happens at the end of the ring.

David

Re: [PATCH v2 01/22] tmplcvt: make the tool more robust

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 07:45:35 -0300
Mauro Carvalho Chehab  escreveu:

> Currently, the script just assumes to be called at
> Documentation/sphinx/. Change it to work on any directory,
> and make it abort if something gets wrong.
> 
> Also, be sure that both parameters are specified.
> 
> That should avoid troubles like this:
> 
> $ Documentation/sphinx/tmplcvt Documentation/DocBook/writing_usb_driver.tmpl
> sed: couldn't open file convert_template.sed: No such file or directory
> 
> Signed-off-by: Mauro Carvalho Chehab 

Forgot to mention. The entire USB book, after this patch series,
generated with Sphinx 1.4.9, can be seen, in HTML, at:

http://www.infradead.org/~mchehab/kernel_docs/driver-api/usb/index.html

Thanks,
Mauro

Re: [PATCH v6 00/39] i.MX Media Driver

[Russell King - ARM Linux]

This fails at step 1.  The removal of the frame interval support now
means my setup script fails when trying to set the frame interval on
the camera:

Enumerating pads and links
Setting up format SRGGB8_1X8 816x616 on pad imx219 0-0010/0
Format set: SRGGB8_1X8 816x616
Setting up frame interval 1/25 on pad imx219 0-0010/0
Frame interval set: 1/25
Setting up format SRGGB8_1X8 816x616 on pad imx6-mipi-csi2/0
Format set: SRGGB8_1X8 816x616
Setting up frame interval 1/25 on pad imx6-mipi-csi2/0
Unable to set frame interval: Inappropriate ioctl for device (-25)Unable to 
setup formats: Inappropriate ioctl for device (25)

This is because media-ctl tries to propagate it from the imx219 source
pad to the csi2 sink pad, and the csi2 now fails that ioctl.

This makes media-ctl return a failure code, which means that it's not
possible for a script to determine whether the failure was due to the
camera setup or something else.  So, we have to assume that the
whole command failed.

This is completely broken, and I'm even more convinced that those
arguing for this behaviour really have not thought it through well
enough before demanding that this code was removed.

As far as I'm concerned, the end result is completely broken and
unusable.  I'm going to be merging the frame interval support back
into my test tree, because that's the only sane thing to do.

If v4l2 people want to object to having frame interval support present
for all subdevs, then _they_ need to make sure that the rest of their
software conforms to what they're telling people to do.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 1/2] staging: atomisp: simplify the if condition in atomisp_freq_scaling()

[Alan Cox]

On Thu, 2017-03-30 at 15:24 +0900, Daeseok Youn wrote:
> The condition line in if-statement is needed to be shorthen to
> improve readability.
> 
> Signed-off-by: Daeseok Youn 
> ---

How about a define for ATOMISP_IS_CHT(isp) instead - as we will need
these tests in other places where there are ISP2400/ISP2401 ifdefs ?

Alan

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 12:38:42 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Wednesday 29 Mar 2017 22:06:33 Mauro Carvalho Chehab wrote:
> > Em Thu, 30 Mar 2017 01:15:27 +0300 Laurent Pinchart escreveu:  
> > > On Wednesday 29 Mar 2017 15:54:21 Mauro Carvalho Chehab wrote:  
> > > > Several host controllers, commonly found on ARM, like dwc2,
> > > > require buffers that are CPU-word aligned for they to work.
> > > > 
> > > > Failing to do that will cause random troubles at the caller
> > > > drivers, causing them to fail.
> > > > 
> > > > Document it.
> > > > 
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > > ---
> > > > 
> > > >  Documentation/driver-api/usb/URB.rst | 18 ++
> > > >  drivers/usb/core/message.c   | 15 +++
> > > >  include/linux/usb.h  | 18 ++
> > > >  3 files changed, 51 insertions(+)
> > > > 
> > > > diff --git a/Documentation/driver-api/usb/URB.rst
> > > > b/Documentation/driver-api/usb/URB.rst index d9ea6a3996e7..b83b557e9891
> > > > 100644
> > > > --- a/Documentation/driver-api/usb/URB.rst
> > > > +++ b/Documentation/driver-api/usb/URB.rst
> > > > @@ -274,6 +274,24 @@ If you specify your own start frame, make sure it's
> > > > several frames in advance of the current frame.  You might want this
> > > > model
> > > > if you're synchronizing ISO data with some other event stream.
> > > > 
> > > > +.. note::
> > > > +
> > > > +   Several host drivers require that the ``transfer_buffer`` to be
> > > > aligned
> > > > +   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64
> > > > bits).  
> > > 
> > > Is it the CPU word size or the DMA transfer size ? I assume the latter,
> > > and I wouldn't be surprised if the alignment requirement was 32-bit on at
> > > least some of the 64-bit platforms.  
> > 
> > Yeah, it is actually the DMA transfer size. Yet, worse case scenario is that
> > the DMA transfer size to be 64 bits on 64 bits CPU.
> >   
> > > > +   It is up to USB drivers should ensure that they'll only pass buffers
> > > > +   with such alignments.
> > > > +
> > > > +   Please also notice that, due to such restriction, the host driver  
> > > 
> > > s/notice/note/ (and below as well) ?  
> > 
> > OK.
> >   
> > > > +   may also override PAD bytes at the end of the ``transfer_buffer``,
> > > > up to the
> > > > +   size of the CPU word.  
> > > 
> > > "May" is quite weak here. If some host controller drivers require buffers
> > > to be aligned, then it's an API requirement, and all buffers must be
> > > aligned. I'm not even sure I would mention that some host drivers require
> > > it, I think we should just state that the API requires buffers to be
> > > aligned.  
> > 
> > What I'm trying to say here is that, on a 32-bits system, if the driver do
> > a USB_DIR_IN transfer using some code similar to:
> > 
> > size = 4;
> > buffer = kmalloc(size, GFP_KERNEL);
> > 
> > usb_control_msg(udev, pipe, req, type, val, idx, buffer + 2, 2,   
> timeout);
> > usb_control_msg(udev, pipe, req, type, val, idx, buffer, size,   
> timeout);
> > 
> > Drivers like dwc2 will mess with the buffer.
> > 
> > The first transfer will actually work, due to a workaround inside the
> > driver that will create a temporary DWORD-aligned buffer, avoiding it
> > to go past the buffer.
> > 
> > However, the second transfer will destroy the data received from the
> > first usb_control_msg(), as it will write 4 bytes at the buffer.
> > 
> > Not all drivers would do that, though.
> > 
> > Please notice that, as kmalloc will always return a CPU-aligned buffer,
> > if the client do something like:
> > 
> > size = 2;
> > buffer = kmalloc(size, GFP_KERNEL);
> > 
> > usb_control_msg(udev, pipe, req, type, val, idx, buffer, 2, timeout);
> > 
> > What happens there is that the DMA engine will still write 4 bytes at
> > the buffer, but the 2 bytes that go past the end of buffer will be
> > written on a memory that will never be used.  
> 
> I understand that, but stating that host controller drivers "may" do this 
> won't help much. If they *may*, all USB device drivers *must* align buffers 
> correctly. That's the part that needs to be documented. Let's not confuse 
> developers by only stating that something may happened, let's be clear and 
> tell what they must do.

Ok, rewrote the entire text. Please see if the new version
works better.

> 
> > > > +   Please notice that ancillary routines that transfer URBs, like
> > > > +   usb_control_msg() also have such restriction.
> > > > +
> > > > +   Such word alignment condition is normally ensured if the buffer is
> > > > +   allocated with kmalloc(), but this may not be the case if the driver
> > > > +   allocates a bigger buffer and point to a random place inside it.
> > > > +
> > > > 
> > > >  How to start interrupt (INT) transfers?
> > > >  ===
> > > > 
> > > > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/messa

[PATCH v2 14/22] usb/hotplug.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../hotplug.txt => driver-api/usb/hotplug.rst} | 66 --
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 37 insertions(+), 30 deletions(-)
 rename Documentation/{usb/hotplug.txt => driver-api/usb/hotplug.rst} (76%)

diff --git a/Documentation/usb/hotplug.txt 
b/Documentation/driver-api/usb/hotplug.rst
similarity index 76%
rename from Documentation/usb/hotplug.txt
rename to Documentation/driver-api/usb/hotplug.rst
index 5b243f315b2c..79663e653ca1 100644
--- a/Documentation/usb/hotplug.txt
+++ b/Documentation/driver-api/usb/hotplug.rst
@@ -1,4 +1,9 @@
-LINUX HOTPLUGGING
+USB hotplugging
+~~~
+
+Linux Hotplugging
+=
+
 
 In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
 into the bus with power on.  In most cases, users expect the devices to become
@@ -30,11 +35,11 @@ Because some of those actions rely on information about 
drivers (metadata)
 that is currently available only when the drivers are dynamically linked,
 you get the best hotplugging when you configure a highly modular system.
 
+Kernel Hotplug Helper (``/sbin/hotplug``)
+=
 
-KERNEL HOTPLUG HELPER (/sbin/hotplug)
-
-There is a kernel parameter: /proc/sys/kernel/hotplug, which normally
-holds the pathname "/sbin/hotplug".  That parameter names a program
+There is a kernel parameter: ``/proc/sys/kernel/hotplug``, which normally
+holds the pathname ``/sbin/hotplug``.  That parameter names a program
 which the kernel may invoke at various times.
 
 The /sbin/hotplug program can be invoked by any subsystem as part of its
@@ -51,26 +56,26 @@ Hotplug software and other resources is available at:
 Mailing list information is also available at that site.
 
 
---
+USB Policy Agent
+
 
-
-USB POLICY AGENT
-
-The USB subsystem currently invokes /sbin/hotplug when USB devices
+The USB subsystem currently invokes ``/sbin/hotplug`` when USB devices
 are added or removed from system.  The invocation is done by the kernel
 hub workqueue [hub_wq], or else as part of root hub initialization
 (done by init, modprobe, kapmd, etc).  Its single command line parameter
 is the string "usb", and it passes these environment variables:
 
-ACTION ... "add", "remove"
-PRODUCT ... USB vendor, product, and version codes (hex)
-TYPE ... device class codes (decimal)
-INTERFACE ... interface 0 class codes (decimal)
+== 
+ACTION ``add``, ``remove``
+PRODUCTUSB vendor, product, and version codes (hex)
+TYPE   device class codes (decimal)
+INTERFACE  interface 0 class codes (decimal)
+== 
 
 If "usbdevfs" is configured, DEVICE and DEVFS are also passed.  DEVICE is
 the pathname of the device, and is useful for devices with multiple and/or
 alternate interfaces that complicate driver selection.  By design, USB
-hotplugging is independent of "usbdevfs":  you can do most essential parts
+hotplugging is independent of ``usbdevfs``:  you can do most essential parts
 of USB device setup without using that filesystem, and without running a
 user mode daemon to detect changes in system configuration.
 
@@ -79,19 +84,20 @@ modules, and can invoke driver-specific setup scripts.  The 
newest ones
 leverage USB module-init-tools support.  Later agents might unload drivers.
 
 
-USB MODUTILS SUPPORT
+USB Modutils Support
+
 
-Current versions of module-init-tools will create a "modules.usbmap" file
-which contains the entries from each driver's MODULE_DEVICE_TABLE.  Such
+Current versions of module-init-tools will create a ``modules.usbmap`` file
+which contains the entries from each driver's ``MODULE_DEVICE_TABLE``.  Such
 files can be used by various user mode policy agents to make sure all the
 right driver modules get loaded, either at boot time or later.
 
-See  for full information about such table entries; or look
+See ``linux/usb.h`` for full information about such table entries; or look
 at existing drivers.  Each table entry describes one or more criteria to
 be used when matching a driver to a device or class of devices.  The
 specific criteria are identified by bits set in "match_flags", paired
 with field values.  You can construct the criteria directly, or with
-macros such as these, and use driver_info to store more information.
+macros such as these, and use driver_info to store more information::
 
 USB_DEVICE (vendorId, productId)
... matching devices with specified vendor and product ids
@@ -103,7 +109,7 @@ macros such as these, and use driver_info to store more 
information.
... matching specified device class info
 
 A short example, for a driver that supports 

[PATCH v2 13/22] error-codes.rst: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/error-codes.rst | 205 +++
 Documentation/driver-api/usb/index.rst   |   1 +
 Documentation/usb/error-codes.txt| 175 ---
 3 files changed, 206 insertions(+), 175 deletions(-)
 create mode 100644 Documentation/driver-api/usb/error-codes.rst
 delete mode 100644 Documentation/usb/error-codes.txt

diff --git a/Documentation/driver-api/usb/error-codes.rst 
b/Documentation/driver-api/usb/error-codes.rst
new file mode 100644
index ..9c11a0fd16cb
--- /dev/null
+++ b/Documentation/driver-api/usb/error-codes.rst
@@ -0,0 +1,205 @@
+USB Error codes
+~~~
+
+:Revised: 2004-Oct-21
+
+This is the documentation of (hopefully) all possible error codes (and
+their interpretation) that can be returned from usbcore.
+
+Some of them are returned by the Host Controller Drivers (HCDs), which
+device drivers only see through usbcore.  As a rule, all the HCDs should
+behave the same except for transfer speed dependent behaviors and the
+way certain faults are reported.
+
+
+Error codes returned by :c:func:`usb_submit_urb`
+
+
+Non-USB-specific:
+
+
+=== ===
+0  URB submission went fine
+
+``-ENOMEM``no memory for allocation of internal structures
+=== ===
+
+USB-specific:
+
+===
===
+``-EBUSY`` The URB is already active.
+
+``-ENODEV``specified USB-device or bus doesn't exist
+
+``-ENOENT``specified interface or endpoint does not exist or
+   is not enabled
+
+``-ENXIO`` host controller driver does not support queuing of
+   this type of urb.  (treat as a host controller bug.)
+
+``-EINVAL``a) Invalid transfer type specified (or not supported)
+   b) Invalid or unsupported periodic transfer interval
+   c) ISO: attempted to change transfer interval
+   d) ISO: ``number_of_packets`` is < 0
+   e) various other cases
+
+``-EXDEV`` ISO: ``URB_ISO_ASAP`` wasn't specified and all the
+   frames the URB would be scheduled in have already
+   expired.
+
+``-EFBIG`` Host controller driver can't schedule that many ISO
+   frames.
+
+``-EPIPE`` The pipe type specified in the URB doesn't match the
+   endpoint's actual type.
+
+``-EMSGSIZE``  (a) endpoint maxpacket size is zero; it is not usable
+   in the current interface altsetting.
+   (b) ISO packet is larger than the endpoint maxpacket.
+   (c) requested data transfer length is invalid: negative
+   or too large for the host controller.
+
+``-ENOSPC``This request would overcommit the usb bandwidth reserved
+   for periodic transfers (interrupt, isochronous).
+
+``-ESHUTDOWN`` The device or host controller has been disabled due to
+   some problem that could not be worked around.
+
+``-EPERM`` Submission failed because ``urb->reject`` was set.
+
+``-EHOSTUNREACH``  URB was rejected because the device is suspended.
+
+``-ENOEXEC``   A control URB doesn't contain a Setup packet.
+===
===
+
+Error codes returned by ``in urb->status`` or in ``iso_frame_desc[n].status`` 
(for ISO)
+===
+
+USB device drivers may only test urb status values in completion handlers.
+This is because otherwise there would be a race between HCDs updating
+these values on one CPU, and device drivers testing them on another CPU.
+
+A transfer's actual_length may be positive even when an error has been
+reported.  That's because transfers often involve several packets, so that
+one or more packets could finish before an error stops further endpoint I/O.
+
+For isochronous URBs, the urb status value is non-zero only if the URB is
+unlinked, the device is removed, the host controller is disabled, or the total
+transferred length is less than the requested length and the
+``URB_SHORT_NOT_OK`` flag is set.  Completion handlers for isochronous URBs
+should only see ``urb->status`` set to zero, ``-ENOENT``, ``-ECONNRESET``,
+``-ESHUTDOWN``, or ``-EREMOTEIO``. Individual frame descriptor status fields
+may report more status codes.
+
+
+===
=

[PATCH v2 11/22] usb/power-management.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/index.rst |   1 +
 .../usb/power-management.rst}  | 404 +++--
 2 files changed, 214 insertions(+), 191 deletions(-)
 rename Documentation/{usb/power-management.txt => 
driver-api/usb/power-management.rst} (69%)

diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 441c5dacdf27..23c76c17fc19 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -9,6 +9,7 @@ Linux USB API
anchors
bulk-streams
callbacks
+   power-management
writing_usb_driver
writing_musb_glue_layer
 
diff --git a/Documentation/usb/power-management.txt 
b/Documentation/driver-api/usb/power-management.rst
similarity index 69%
rename from Documentation/usb/power-management.txt
rename to Documentation/driver-api/usb/power-management.rst
index 00e706997130..c068257f6d27 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/driver-api/usb/power-management.rst
@@ -1,10 +1,12 @@
-   Power Management for USB
+.. _usb-power-management:
 
-Alan Stern 
-
-  Last-updated: February 2014
+Power Management for USB
+
 
+:Author: Alan Stern 
+:Date: Last-updated: February 2014
 
+..
Contents:
-
* What is Power Management?
@@ -25,14 +27,14 @@
* Suggested Userspace Port Power Policy
 
 
-   What is Power Management?
-   -
+What is Power Management?
+-
 
 Power Management (PM) is the practice of saving energy by suspending
 parts of a computer system when they aren't being used.  While a
-component is "suspended" it is in a nonfunctional low-power state; it
+component is ``suspended`` it is in a nonfunctional low-power state; it
 might even be turned off completely.  A suspended component can be
-"resumed" (returned to a functional full-power state) when the kernel
+``resumed`` (returned to a functional full-power state) when the kernel
 needs to use it.  (There also are forms of PM in which components are
 placed in a less functional but still usable state instead of being
 suspended; an example would be reducing the CPU's clock rate.  This
@@ -44,22 +46,25 @@ device is turned off while the system as a whole remains 
running, we
 call it a "dynamic suspend" (also known as a "runtime suspend" or
 "selective suspend").  This document concentrates mostly on how
 dynamic PM is implemented in the USB subsystem, although system PM is
-covered to some extent (see Documentation/power/*.txt for more
+covered to some extent (see ``Documentation/power/*.txt`` for more
 information about system PM).
 
-System PM support is present only if the kernel was built with CONFIG_SUSPEND
-or CONFIG_HIBERNATION enabled.  Dynamic PM support for USB is present whenever
-the kernel was built with CONFIG_PM enabled.
+System PM support is present only if the kernel was built with
+``CONFIG_SUSPEND`` or ``CONFIG_HIBERNATION`` enabled.  Dynamic PM support
+
+for USB is present whenever
+the kernel was built with ``CONFIG_PM`` enabled.
 
 [Historically, dynamic PM support for USB was present only if the
-kernel had been built with CONFIG_USB_SUSPEND enabled (which depended on
-CONFIG_PM_RUNTIME).  Starting with the 3.10 kernel release, dynamic PM support
-for USB was present whenever the kernel was built with CONFIG_PM_RUNTIME
-enabled.  The CONFIG_USB_SUSPEND option had been eliminated.]
+kernel had been built with ``CONFIG_USB_SUSPEND`` enabled (which depended on
+``CONFIG_PM_RUNTIME``).  Starting with the 3.10 kernel release, dynamic PM
+support for USB was present whenever the kernel was built with
+``CONFIG_PM_RUNTIME`` enabled.  The ``CONFIG_USB_SUSPEND`` option had been
+eliminated.]
 
 
-   What is Remote Wakeup?
-   --
+What is Remote Wakeup?
+--
 
 When a device has been suspended, it generally doesn't resume until
 the computer tells it to.  Likewise, if the entire computer has been
@@ -76,8 +81,8 @@ event.  Examples include a suspended keyboard resuming when a 
key is
 pressed, or a suspended USB hub resuming when a device is plugged in.
 
 
-   When is a USB device idle?
-   --
+When is a USB device idle?
+--
 
 A device is idle whenever the kernel thinks it's not busy doing
 anything important and thus is a candidate for being suspended.  The
@@ -92,11 +97,11 @@ If a USB device has no driver, its usbfs file isn't open, 
and it isn't
 being accessed through sysfs, then it definitely is idle.
 
 
-   Forms of dynamic PM
-   ---
+Forms of dynamic PM
+---
 
 Dynamic suspends occur when the kernel decides to suspend an idle
-device.  This is c

[PATCH v2 06/22] writing_usb_driver.rst: Enrich its ReST representation

[Mauro Carvalho Chehab]

The pandoc conversion is not perfect. Do handwork in order to:

- add a title to this chapter;
- adjust function and struct references;
- use monospaced fonts for C code names;
- some other minor adjustments to make it better to read in
  text mode and in html.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../driver-api/usb/writing_usb_driver.rst  | 182 ++---
 1 file changed, 82 insertions(+), 100 deletions(-)

diff --git a/Documentation/driver-api/usb/writing_usb_driver.rst 
b/Documentation/driver-api/usb/writing_usb_driver.rst
index c18dbd74152b..69f077dcdb78 100644
--- a/Documentation/driver-api/usb/writing_usb_driver.rst
+++ b/Documentation/driver-api/usb/writing_usb_driver.rst
@@ -1,3 +1,5 @@
+.. _writing-usb-driver:
+
 ==
 Writing USB Device Drivers
 ==
@@ -48,25 +50,23 @@ The first thing a Linux USB driver needs to do is register 
itself with
 the Linux USB subsystem, giving it some information about which devices
 the driver supports and which functions to call when a device supported
 by the driver is inserted or removed from the system. All of this
-information is passed to the USB subsystem in the usb_driver structure.
-The skeleton driver declares a usb_driver as:
-
-::
+information is passed to the USB subsystem in the :c:type:`usb_driver`
+structure. The skeleton driver declares a :c:type:`usb_driver` as::
 
 static struct usb_driver skel_driver = {
-.name= "skeleton",
-.probe   = skel_probe,
-.disconnect  = skel_disconnect,
-.fops= &skel_fops,
-.minor   = USB_SKEL_MINOR_BASE,
-.id_table= skel_table,
+   .name= "skeleton",
+   .probe   = skel_probe,
+   .disconnect  = skel_disconnect,
+   .fops= &skel_fops,
+   .minor   = USB_SKEL_MINOR_BASE,
+   .id_table= skel_table,
 };
 
 
 The variable name is a string that describes the driver. It is used in
 informational messages printed to the system log. The probe and
 disconnect function pointers are called when a device that matches the
-information provided in the id_table variable is either seen or
+information provided in the ``id_table`` variable is either seen or
 removed.
 
 The fops and minor variables are optional. Most USB drivers hook into
@@ -76,78 +76,70 @@ subsystem, and any user-space interactions are provided 
through that
 interface. But for drivers that do not have a matching kernel subsystem,
 such as MP3 players or scanners, a method of interacting with user space
 is needed. The USB subsystem provides a way to register a minor device
-number and a set of file_operations function pointers that enable this
-user-space interaction. The skeleton driver needs this kind of
+number and a set of :c:type:`file_operations` function pointers that enable
+this user-space interaction. The skeleton driver needs this kind of
 interface, so it provides a minor starting number and a pointer to its
-file_operations functions.
+:c:type:`file_operations` functions.
 
-The USB driver is then registered with a call to usb_register, usually
-in the driver's init function, as shown here:
-
-::
+The USB driver is then registered with a call to :c:func:`usb_register`,
+usually in the driver's init function, as shown here::
 
 static int __init usb_skel_init(void)
 {
-int result;
+   int result;
 
-/* register this driver with the USB subsystem */
-result = usb_register(&skel_driver);
-if (result < 0) {
-err("usb_register failed for the "__FILE__ "driver."
-"Error number %d", result);
-return -1;
-}
+   /* register this driver with the USB subsystem */
+   result = usb_register(&skel_driver);
+   if (result < 0) {
+   err("usb_register failed for the "__FILE__ "driver."
+   "Error number %d", result);
+   return -1;
+   }
 
-return 0;
+   return 0;
 }
 module_init(usb_skel_init);
 
 
 When the driver is unloaded from the system, it needs to deregister
-itself with the USB subsystem. This is done with the usb_deregister
-function:
-
-::
+itself with the USB subsystem. This is done with the :c:func:`usb_deregister`
+function::
 
 static void __exit usb_skel_exit(void)
 {
-/* deregister this driver with the USB subsystem */
-usb_deregister(&skel_driver);
+   /* deregister this driver with the USB subsystem */
+   usb_deregister(&skel_driver);
 }
 module_exit(usb_skel_exit);
 
 
 To enable the linux-hotplug system to load the driver automatically when
-the device is plugged in, you need to create a MODULE_DEVICE_TABLE.
+the device is plugged in, you need to create a ``MODULE_DEVICE_TABLE``.
 The following 

[PATCH v2 15/22] usb/persist.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/index.rst |  1 +
 .../persist.txt => driver-api/usb/persist.rst} | 22 +-
 2 files changed, 14 insertions(+), 9 deletions(-)
 rename Documentation/{usb/persist.txt => driver-api/usb/persist.rst} (94%)

diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 43f0a8b72b11..3f08cb5d5feb 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -12,6 +12,7 @@ Linux USB API
dma
power-management
hotplug
+   persist
error-codes
writing_usb_driver
writing_musb_glue_layer
diff --git a/Documentation/usb/persist.txt 
b/Documentation/driver-api/usb/persist.rst
similarity index 94%
rename from Documentation/usb/persist.txt
rename to Documentation/driver-api/usb/persist.rst
index 35d70eda9ad6..ea1b43f0559e 100644
--- a/Documentation/usb/persist.txt
+++ b/Documentation/driver-api/usb/persist.rst
@@ -1,11 +1,12 @@
-   USB device persistence during system suspend
+USB device persistence during system suspend
+
 
-  Alan Stern 
+:Author: Alan Stern 
+:Date: September 2, 2006 (Updated February 25, 2008)
 
-   September 2, 2006 (Updated February 25, 2008)
 
-
-   What is the problem?
+What is the problem?
+
 
 According to the USB specification, when a USB bus is suspended the
 bus must continue to supply suspend current (around 1-5 mA).  This
@@ -63,7 +64,8 @@ suspended -- but it will crash as soon as it wakes up, which 
isn't
 much better.)
 
 
-   What is the solution?
+What is the solution?
+=
 
 The kernel includes a feature called USB-persist.  It tries to work
 around these issues by allowing the core USB device data structures to
@@ -99,7 +101,7 @@ now a good and happy place.
 
 Note that the "USB-persist" feature will be applied only to those
 devices for which it is enabled.  You can enable the feature by doing
-(as root):
+(as root)::
 
echo 1 >/sys/bus/usb/devices/.../power/persist
 
@@ -110,7 +112,8 @@ doesn't even exist, so you only have to worry about setting 
it for
 devices where it really matters.
 
 
-   Is this the best solution?
+Is this the best solution?
+==
 
 Perhaps not.  Arguably, keeping track of mounted filesystems and
 memory mappings across device disconnects should be handled by a
@@ -130,7 +133,8 @@ just mass-storage devices.  It might turn out to be equally 
useful for
 other device types, such as network interfaces.
 
 
-   WARNING: USB-persist can be dangerous!!
+WARNING: USB-persist can be dangerous!!
+===
 
 When recovering an interrupted power session the kernel does its best
 to make sure the USB device hasn't been changed; that is, the same
-- 
2.9.3

[PATCH v2 10/22] usb/callbacks.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../callbacks.txt => driver-api/usb/callbacks.rst} | 61 +++---
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 43 insertions(+), 19 deletions(-)
 rename Documentation/{usb/callbacks.txt => driver-api/usb/callbacks.rst} (78%)

diff --git a/Documentation/usb/callbacks.txt 
b/Documentation/driver-api/usb/callbacks.rst
similarity index 78%
rename from Documentation/usb/callbacks.txt
rename to Documentation/driver-api/usb/callbacks.rst
index 9e85846bdb98..93a8d53e27e7 100644
--- a/Documentation/usb/callbacks.txt
+++ b/Documentation/driver-api/usb/callbacks.rst
@@ -1,3 +1,6 @@
+USB core callbacks
+~~
+
 What callbacks will usbcore do?
 ===
 
@@ -11,30 +14,42 @@ The callbacks defined in the driver structure are:
 
 1. Hotplugging callbacks:
 
- * @probe: Called to see if the driver is willing to manage a particular
- * interface on a device.
- * @disconnect: Called when the interface is no longer accessible, usually
- * because its device has been (or is being) disconnected or the
- * driver module is being unloaded.
+ - @probe:
+   Called to see if the driver is willing to manage a particular
+   interface on a device.
+
+ - @disconnect:
+   Called when the interface is no longer accessible, usually
+   because its device has been (or is being) disconnected or the
+   driver module is being unloaded.
 
 2. Odd backdoor through usbfs:
 
- * @ioctl: Used for drivers that want to talk to userspace through
- * the "usbfs" filesystem.  This lets devices provide ways to
- * expose information to user space regardless of where they
- * do (or don't) show up otherwise in the filesystem.
+ - @ioctl:
+   Used for drivers that want to talk to userspace through
+   the "usbfs" filesystem.  This lets devices provide ways to
+   expose information to user space regardless of where they
+   do (or don't) show up otherwise in the filesystem.
 
 3. Power management (PM) callbacks:
 
- * @suspend: Called when the device is going to be suspended.
- * @resume: Called when the device is being resumed.
- * @reset_resume: Called when the suspended device has been reset instead
- * of being resumed.
+ - @suspend:
+   Called when the device is going to be suspended.
+
+ - @resume:
+   Called when the device is being resumed.
+
+ - @reset_resume:
+   Called when the suspended device has been reset instead
+   of being resumed.
 
 4. Device level operations:
 
- * @pre_reset: Called when the device is about to be reset.
- * @post_reset: Called after the device has been reset
+ - @pre_reset:
+   Called when the device is about to be reset.
+
+ - @post_reset:
+   Called after the device has been reset
 
 The ioctl interface (2) should be used only if you have a very good
 reason. Sysfs is preferred these days. The PM callbacks are covered
@@ -58,7 +73,9 @@ an interface. A driver's bond to an interface is exclusive.
 The probe() callback
 
 
-int (*probe) (struct usb_interface *intf,
+::
+
+  int (*probe) (struct usb_interface *intf,
const struct usb_device_id *id);
 
 Accept or decline an interface. If you accept the device return 0,
@@ -75,7 +92,9 @@ initialisation that doesn't take too long is a good idea here.
 The disconnect() callback
 -
 
-void (*disconnect) (struct usb_interface *intf);
+::
+
+  void (*disconnect) (struct usb_interface *intf);
 
 This callback is a signal to break any connection with an interface.
 You are not allowed any IO to a device after returning from this
@@ -93,7 +112,9 @@ Device level callbacks
 pre_reset
 -
 
-int (*pre_reset)(struct usb_interface *intf);
+::
+
+  int (*pre_reset)(struct usb_interface *intf);
 
 A driver or user space is triggering a reset on the device which
 contains the interface passed as an argument. Cease IO, wait for all
@@ -107,7 +128,9 @@ are in atomic context.
 post_reset
 --
 
-int (*post_reset)(struct usb_interface *intf);
+::
+
+  int (*post_reset)(struct usb_interface *intf);
 
 The reset has completed.  Restore any saved device state and begin
 using the device again.
diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 6fe7611f7332..441c5dacdf27 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -8,6 +8,7 @@ Linux USB API
gadget
anchors
bulk-streams
+   callbacks
writing_usb_driver
writing_musb_glue_layer
 
-- 
2.9.3

[PATCH v2 01/22] tmplcvt: make the tool more robust

[Mauro Carvalho Chehab]

Currently, the script just assumes to be called at
Documentation/sphinx/. Change it to work on any directory,
and make it abort if something gets wrong.

Also, be sure that both parameters are specified.

That should avoid troubles like this:

$ Documentation/sphinx/tmplcvt Documentation/DocBook/writing_usb_driver.tmpl
sed: couldn't open file convert_template.sed: No such file or directory

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/sphinx/tmplcvt | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/sphinx/tmplcvt b/Documentation/sphinx/tmplcvt
index 909a73065e0a..31df8eb7feca 100755
--- a/Documentation/sphinx/tmplcvt
+++ b/Documentation/sphinx/tmplcvt
@@ -7,13 +7,22 @@
 # fix \_
 # title line?
 #
+set -eu
+
+if [ "$2" == "" ]; then
+   echo "$0  "
+   exit
+fi
+
+DIR=$(dirname $0)
 
 in=$1
 rst=$2
 tmp=$rst.tmp
 
 cp $in $tmp
-sed --in-place -f convert_template.sed $tmp
+sed --in-place -f $DIR/convert_template.sed $tmp
 pandoc -s -S -f docbook -t rst -o $rst $tmp
-sed --in-place -f post_convert.sed $rst
+sed --in-place -f $DIR/post_convert.sed $rst
 rm $tmp
+echo "book writen to $rst"
-- 
2.9.3

[PATCH v2 05/22] gadget.rst: Enrich its ReST representation and add kernel-doc tag

[Mauro Carvalho Chehab]

The pandoc conversion is not perfect. Do handwork in order to:

- add a title to this chapter;
- use the proper warning and note markups;
- use kernel-doc to include Kernel header and c files;
- remove legacy notes with regards to DocBook;
- some other minor adjustments to make it better to read in
  text mode and in html.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/gadget.rst | 127 +---
 1 file changed, 52 insertions(+), 75 deletions(-)

diff --git a/Documentation/driver-api/usb/gadget.rst 
b/Documentation/driver-api/usb/gadget.rst
index 52b299b1ca6d..3e8a3809c0b8 100644
--- a/Documentation/driver-api/usb/gadget.rst
+++ b/Documentation/driver-api/usb/gadget.rst
@@ -38,7 +38,7 @@ address a number of important problems, including:
resources.
 
 Most Linux developers will not be able to use this API, since they have
-USB "host" hardware in a PC, workstation, or server. Linux users with
+USB ``host`` hardware in a PC, workstation, or server. Linux users with
 embedded systems are more likely to have USB peripheral hardware. To
 distinguish drivers running inside such hardware from the more familiar
 Linux "USB device drivers", which are host side proxies for the real USB
@@ -64,7 +64,7 @@ Structure of Gadget Drivers
 
 A system running inside a USB peripheral normally has at least three
 layers inside the kernel to handle USB protocol processing, and may have
-additional layers in user space code. The "gadget" API is used by the
+additional layers in user space code. The ``gadget`` API is used by the
 middle layer to interact with the lowest level (which directly handles
 hardware).
 
@@ -143,13 +143,13 @@ In Linux, from the bottom up, these layers are:
 *Additional Layers*
 Other layers may exist. These could include kernel layers, such as
 network protocol stacks, as well as user mode applications building
-on standard POSIX system call APIs such as *open()*, *close()*,
-*read()* and *write()*. On newer systems, POSIX Async I/O calls may
+on standard POSIX system call APIs such as ``open()``, ``close()``,
+``read()`` and ``write()``. On newer systems, POSIX Async I/O calls may
 be an option. Such user mode code will not necessarily be subject to
 the GNU General Public License (GPL).
 
 OTG-capable systems will also need to include a standard Linux-USB host
-side stack, with *usbcore*, one or more *Host Controller Drivers*
+side stack, with ``usbcore``, one or more *Host Controller Drivers*
 (HCDs), *USB Device Drivers* to support the OTG "Targeted Peripheral
 List", and so forth. There will also be an *OTG Controller Driver*,
 which is visible to gadget and device driver developers only indirectly.
@@ -174,24 +174,20 @@ combined, to implement composite devices.
 Kernel Mode Gadget API
 ==
 
-Gadget drivers declare themselves through a *struct
-usb_gadget_driver*, which is responsible for most parts of enumeration
-for a *struct usb_gadget*. The response to a set_configuration usually
-involves enabling one or more of the *struct usb_ep* objects exposed by
-the gadget, and submitting one or more *struct usb_request* buffers to
+Gadget drivers declare themselves through a struct
+:c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration
+for a struct :c:type:`usb_gadget`. The response to a set_configuration usually
+involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by
+the gadget, and submitting one or more struct :c:type:`usb_request` buffers to
 transfer data. Understand those four data types, and their operations,
 and you will understand how this API works.
 
-**Note**
+.. Note::
 
-This documentation was prepared using the standard Linux kernel
-``docproc`` tool, which turns text and in-code comments into SGML
-DocBook and then into usable formats such as HTML or PDF. Other than
-the "Chapter 9" data types, most of the significant data types and
-functions are described here.
+Other than the "Chapter 9" data types, most of the significant data
+types and functions are described here.
 
-However, docproc does not understand all the C constructs that are
-used, so some relevant information is likely omitted from what you
+However, some relevant information is likely omitted from what you
 are reading. One example of such information is endpoint
 autoconfiguration. You'll have to read the header file, and use
 example source code (such as that for "Gadget Zero"), to fully
@@ -199,10 +195,10 @@ and you will understand how this API works.
 
 The part of the API implementing some basic driver capabilities is
 specific to the version of the Linux kernel that's in use. The 2.6
-kernel includes a *driver model* framework that has no analogue on
-earlier kernels; so those parts of the gadget API are not fully
-portable. (They are implemented on 2.4 kernels, but in a different
-  

[PATCH v2 07/22] writing_musb_glue_layer.rst: Enrich its ReST representation

[Mauro Carvalho Chehab]

This file is actually quite complex, and required several
manual handwork:

- add a title for the document;
- use the right tags for monospaced fonts;
- use c references where needed;
- adjust cross-reference to writing_usb_driver.rst
- hightlight cross-referenced lines.

With regards to C code snippet line highlights, the better would be
to use :linenos: for the C code snippets that are referenced by
the line number. However, at least with Sphinx 1.4.9, enabling
it cause the line number to be misaligned with the code,
making it even more confusing. So, instead, let's use
:emphasize-lines: tag to mark the lines that are referenced
at the text.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../driver-api/usb/writing_musb_glue_layer.rst | 598 ++---
 1 file changed, 292 insertions(+), 306 deletions(-)

diff --git a/Documentation/driver-api/usb/writing_musb_glue_layer.rst 
b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
index 52700c7031f9..e90e8fa95600 100644
--- a/Documentation/driver-api/usb/writing_musb_glue_layer.rst
+++ b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
@@ -1,6 +1,6 @@
-==
-Writing an MUSB Glue Layer
-==
+=
+Writing a MUSB Glue Layer
+=
 
 :Author: Apelete Seketeli
 
@@ -21,10 +21,12 @@ design.
 As a self-taught exercise I have written an MUSB glue layer for the
 Ingenic JZ4740 SoC, modelled after the many MUSB glue layers in the
 kernel source tree. This layer can be found at
-drivers/usb/musb/jz4740.c. In this documentation I will walk through the
-basics of the jz4740.c glue layer, explaining the different pieces and
+``drivers/usb/musb/jz4740.c``. In this documentation I will walk through the
+basics of the ``jz4740.c`` glue layer, explaining the different pieces and
 what needs to be done in order to write your own device glue layer.
 
+.. _musb-basics:
+
 Linux MUSB Basics
 =
 
@@ -39,33 +41,30 @@ USB Device Drivers documentation (again, see Resources).
 
 Linux USB stack is a layered architecture in which the MUSB controller
 hardware sits at the lowest. The MUSB controller driver abstract the
-MUSB controller hardware to the Linux USB stack.
+MUSB controller hardware to the Linux USB stack::
 
-::
-
-  
-  |  | <--- drivers/usb/gadget
-  | Linux USB Core Stack | <--- drivers/usb/host
-  |  | <--- drivers/usb/core
-  
- ⬍
- --
- || <-- drivers/usb/musb/musb_gadget.c
- | MUSB Controller driver | <-- drivers/usb/musb/musb_host.c
- || <-- drivers/usb/musb/musb_core.c
- --
- ⬍
+ 
+ |  | <--- drivers/usb/gadget
+ | Linux USB Core Stack | <--- drivers/usb/host
+ |  | <--- drivers/usb/core
+ 
+⬍
+--
+|| <-- drivers/usb/musb/musb_gadget.c
+| MUSB Controller driver | <-- drivers/usb/musb/musb_host.c
+|| <-- drivers/usb/musb/musb_core.c
+--
+⬍
   -
   | MUSB Platform Specific Driver |
   |   | <-- drivers/usb/musb/jz4740.c
   |   aka "Glue Layer"|
   -
- ⬍
+⬍
   -
   |   MUSB Controller Hardware|
   -
 
-
 As outlined above, the glue layer is actually the platform specific code
 sitting in between the controller driver and the controller hardware.
 
@@ -78,37 +77,32 @@ about an embedded controller chip here, so no insertion or 
removal at
 run-time.
 
 All of this information is passed to the MUSB controller driver through
-a platform_driver structure defined in the glue layer as:
-
-::
+a :c:type:`platform_driver` structure defined in the glue layer as::
 
 static struct platform_driver jz4740_driver = {
-.probe  = jz4740_probe,
-.remove = jz4740_remove,
-.driver = {
-.name   = "musb-jz4740",
-},
+   .probe  = jz4740_probe,
+   .remove = jz4740_remove,
+   .driver = {
+   .name   = "musb-jz4740",
+   },
 };
 
-
 The probe and remove function pointers are called when a matching device
 is detected and, respectively, released. The name string describes the
 device supported by this glue layer. In the current case it matches a
-platform_device structure declared in a

[PATCH v2 04/22] usb.rst: Enrich its ReST representation

[Mauro Carvalho Chehab]

- use the proper warning and note markups;
- add references for parts of the document that will be
  cross-referenced on other USB docs;
- some minor adjustments to make it better to read in
  text mode and in html.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/usb.rst | 48 +---
 1 file changed, 17 insertions(+), 31 deletions(-)

diff --git a/Documentation/driver-api/usb/usb.rst 
b/Documentation/driver-api/usb/usb.rst
index b856abb3200e..7e820768ee4f 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -102,6 +102,8 @@ disconnect testing (while the device is active) with each 
different host
 controller driver, to make sure drivers don't have bugs of their own as
 well as to make sure they aren't relying on some HCD-specific behavior.
 
+.. _usb_chapter9:
+
 USB-Standard Types
 ==
 
@@ -112,6 +114,8 @@ USB, and in APIs including this host side API, gadget APIs, 
and usbfs.
 .. kernel-doc:: include/linux/usb/ch9.h
:internal:
 
+.. _usb_header:
+
 Host-Side Data Types and Macros
 ===
 
@@ -209,7 +213,7 @@ library that wraps it. Such libraries include
 `libusb `__ for C/C++, and
 `jUSB `__ for Java.
 
-**Note**
+.. note::
 
 This particular documentation is incomplete, especially with respect
 to the asynchronous mode. As of kernel 2.5.66 the code and this
@@ -319,9 +323,7 @@ files. For information about the current format of this 
file, see the
 sources.
 
 This file, in combination with the poll() system call, can also be used
-to detect when devices are added or removed:
-
-::
+to detect when devices are added or removed::
 
 int fd;
 struct pollfd pfd;
@@ -407,9 +409,7 @@ The ioctl() Requests
 
 
 To use these ioctls, you need to include the following headers in your
-userspace program:
-
-::
+userspace program::
 
 #include 
 #include 
@@ -458,9 +458,7 @@ USBDEVFS_CLAIMINTERFACE
 
 USBDEVFS_CONNECTINFO
 Says whether the device is lowspeed. The ioctl parameter points to a
-structure like this:
-
-::
+structure like this::
 
struct usbdevfs_connectinfo {
unsigned int   devnum;
@@ -477,9 +475,7 @@ USBDEVFS_CONNECTINFO
 USBDEVFS_GETDRIVER
 Returns the name of the kernel driver bound to a given interface (a
 string). Parameter is a pointer to this structure, which is
-modified:
-
-::
+modified::
 
struct usbdevfs_getdriver {
unsigned int  interface;
@@ -490,9 +486,7 @@ USBDEVFS_GETDRIVER
 
 USBDEVFS_IOCTL
 Passes a request from userspace through to a kernel driver that has
-an ioctl entry in the *struct usb_driver* it registered.
-
-::
+an ioctl entry in the *struct usb_driver* it registered::
 
struct usbdevfs_ioctl {
int ifno;
@@ -534,7 +528,7 @@ USBDEVFS_RELEASEINTERFACE
 the number of the interface (bInterfaceNumber from descriptor); File
 modification time is not updated by this request.
 
-   **Warning**
+.. warning::
 
*No security check is made to ensure that the task which made
the claim is the one which is releasing it. This means that user
@@ -574,9 +568,7 @@ a time.
 
 USBDEVFS_BULK
 Issues a bulk read or write request to the device. The ioctl
-parameter is a pointer to this structure:
-
-::
+parameter is a pointer to this structure::
 
struct usbdevfs_bulktransfer {
unsigned int  ep;
@@ -606,9 +598,7 @@ USBDEVFS_CLEAR_HALT
 
 USBDEVFS_CONTROL
 Issues a control request to the device. The ioctl parameter points
-to a structure like this:
-
-::
+to a structure like this::
 
struct usbdevfs_ctrltransfer {
__u8   bRequestType;
@@ -638,7 +628,7 @@ USBDEVFS_RESET
 the reset, this rebinds all device interfaces. File modification
 time is not updated by this request.
 
-   **Warning**
+.. warning::
 
*Avoid using this call* until some usbcore bugs get fixed, since
it does not fully synchronize device, interface, and driver (not
@@ -646,9 +636,7 @@ USBDEVFS_RESET
 
 USBDEVFS_SETINTERFACE
 Sets the alternate setting for an interface. The ioctl parameter is
-a pointer to a structure like this:
-
-::
+a pointer to a structure like this::
 
struct usbdevfs_setinterface {
unsigned int  interface;
@@ -669,7 +657,7 @@ USBDEVFS_SETCONFIGURATION
 configuration (bConfigurationValue from descriptor). File
 modification time is not updated by this request.
 
-   **Warning**
+.. warning::
 
*Avoid using this call* until some usbcore bugs get fixed, since
it does not fully synchronize device, interface, and driver (not
@@ -702,9 +690,7 @@ When usbfs returns these urbs, the status value is updated, 
and the
 buffer may have been modified. Exc

[PATCH v2 08/22] usb/anchors.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../anchors.txt => driver-api/usb/anchors.rst} | 36 --
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 21 insertions(+), 16 deletions(-)
 rename Documentation/{usb/anchors.txt => driver-api/usb/anchors.rst} (75%)

diff --git a/Documentation/usb/anchors.txt 
b/Documentation/driver-api/usb/anchors.rst
similarity index 75%
rename from Documentation/usb/anchors.txt
rename to Documentation/driver-api/usb/anchors.rst
index fe6a99a32bbd..4b248e691bd6 100644
--- a/Documentation/usb/anchors.txt
+++ b/Documentation/driver-api/usb/anchors.rst
@@ -1,3 +1,6 @@
+USB Anchors
+~~~
+
 What is anchor?
 ===
 
@@ -13,7 +16,7 @@ Allocation and Initialisation
 =
 
 There's no API to allocate an anchor. It is simply declared
-as struct usb_anchor. init_usb_anchor() must be called to
+as struct usb_anchor. :c:func:`init_usb_anchor` must be called to
 initialise the data structure.
 
 Deallocation
@@ -26,52 +29,53 @@ Association and disassociation of URBs with anchors
 ===
 
 An association of URBs to an anchor is made by an explicit
-call to usb_anchor_urb(). The association is maintained until
+call to :c:func:`usb_anchor_urb`. The association is maintained until
 an URB is finished by (successful) completion. Thus disassociation
 is automatic. A function is provided to forcibly finish (kill)
 all URBs associated with an anchor.
-Furthermore, disassociation can be made with usb_unanchor_urb()
+Furthermore, disassociation can be made with :c:func:`usb_unanchor_urb`
 
 Operations on multitudes of URBs
 
 
-usb_kill_anchored_urbs()
-
+:c:func:`usb_kill_anchored_urbs`
+
 
 This function kills all URBs associated with an anchor. The URBs
 are called in the reverse temporal order they were submitted.
 This way no data can be reordered.
 
-usb_unlink_anchored_urbs()
---
+:c:func:`usb_unlink_anchored_urbs`
+--
+
 
 This function unlinks all URBs associated with an anchor. The URBs
 are processed in the reverse temporal order they were submitted.
-This is similar to usb_kill_anchored_urbs(), but it will not sleep.
+This is similar to :c:func:`usb_kill_anchored_urbs`, but it will not sleep.
 Therefore no guarantee is made that the URBs have been unlinked when
 the call returns. They may be unlinked later but will be unlinked in
 finite time.
 
-usb_scuttle_anchored_urbs()

+:c:func:`usb_scuttle_anchored_urbs`
+---
 
 All URBs of an anchor are unanchored en masse.
 
-usb_wait_anchor_empty_timeout()

+:c:func:`usb_wait_anchor_empty_timeout`
+---
 
 This function waits for all URBs associated with an anchor to finish
 or a timeout, whichever comes first. Its return value will tell you
 whether the timeout was reached.
 
-usb_anchor_empty()
---
+:c:func:`usb_anchor_empty`
+--
 
 Returns true if no URBs are associated with an anchor. Locking
 is the caller's responsibility.
 
-usb_get_from_anchor()
--
+:c:func:`usb_get_from_anchor`
+-
 
 Returns the oldest anchored URB of an anchor. The URB is unanchored
 and returned with a reference. As you may mix URBs to several
diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index cf2fa2e8d236..5dfb04b2d730 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -6,6 +6,7 @@ Linux USB API
 
usb
gadget
+   anchors
writing_usb_driver
writing_musb_glue_layer
 
-- 
2.9.3

[PATCH v2 20/22] usb: gadget.h: be consistent at kernel doc macros

[Mauro Carvalho Chehab]

There's one value that use spaces instead of tabs to ident.
That causes the following warning:

./include/linux/usb/gadget.h:193: ERROR: Unexpected indentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/usb/gadget.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e4516e9ded0f..fbc22a39e7bc 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -188,7 +188,7 @@ struct usb_ep_caps {
  * @caps:The structure describing types and directions supported by endoint.
  * @maxpacket:The maximum packet size used on this endpoint.  The initial
  * value can sometimes be reduced (hardware allowing), according to
- *  the endpoint descriptor used to configure the endpoint.
+ * the endpoint descriptor used to configure the endpoint.
  * @maxpacket_limit:The maximum packet size value which can be handled by this
  * endpoint. It's set once by UDC driver when endpoint is initialized, and
  * should not be changed. Should not be confused with maxpacket.
-- 
2.9.3

[PATCH v2 12/22] usb/dma.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../{usb/dma.txt => driver-api/usb/dma.rst}| 51 --
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 28 insertions(+), 24 deletions(-)
 rename Documentation/{usb/dma.txt => driver-api/usb/dma.rst} (79%)

diff --git a/Documentation/usb/dma.txt b/Documentation/driver-api/usb/dma.rst
similarity index 79%
rename from Documentation/usb/dma.txt
rename to Documentation/driver-api/usb/dma.rst
index 444651e70d95..59d5aee89e37 100644
--- a/Documentation/usb/dma.txt
+++ b/Documentation/driver-api/usb/dma.rst
@@ -1,16 +1,19 @@
+USB DMA
+~~~
+
 In Linux 2.5 kernels (and later), USB device drivers have additional control
 over how DMA may be used to perform I/O operations.  The APIs are detailed
 in the kernel usb programming guide (kerneldoc, from the source code).
 
-
-API OVERVIEW
+API overview
+
 
 The big picture is that USB drivers can continue to ignore most DMA issues,
 though they still must provide DMA-ready buffers (see
-Documentation/DMA-API-HOWTO.txt).  That's how they've worked through
-the 2.4 (and earlier) kernels.
+``Documentation/DMA-API-HOWTO.txt``).  That's how they've worked through
+the 2.4 (and earlier) kernels, or they can now be DMA-aware.
 
-OR:  they can now be DMA-aware.
+DMA-aware usb drivers:
 
 - New calls enable DMA-aware drivers, letting them allocate dma buffers and
   manage dma mappings for existing dma-ready buffers (see below).
@@ -20,15 +23,15 @@ OR:  they can now be DMA-aware.
   drivers must not use it.)
 
 - "usbcore" will map this DMA address, if a DMA-aware driver didn't do
-  it first and set URB_NO_TRANSFER_DMA_MAP.  HCDs
+  it first and set ``URB_NO_TRANSFER_DMA_MAP``.  HCDs
   don't manage dma mappings for URBs.
 
 - There's a new "generic DMA API", parts of which are usable by USB device
   drivers.  Never use dma_set_mask() on any USB interface or device; that
   would potentially break all devices sharing that bus.
 
-
-ELIMINATING COPIES
+Eliminating copies
+==
 
 It's good to avoid making CPUs copy data needlessly.  The costs can add up,
 and effects like cache-trashing can impose subtle penalties.
@@ -41,7 +44,7 @@ and effects like cache-trashing can impose subtle penalties.
   For those specific cases, USB has primitives to allocate less expensive
   memory.  They work like kmalloc and kfree versions that give you the right
   kind of addresses to store in urb->transfer_buffer and urb->transfer_dma.
-  You'd also set URB_NO_TRANSFER_DMA_MAP in urb->transfer_flags:
+  You'd also set ``URB_NO_TRANSFER_DMA_MAP`` in urb->transfer_flags::
 
void *usb_alloc_coherent (struct usb_device *dev, size_t size,
int mem_flags, dma_addr_t *dma);
@@ -49,15 +52,15 @@ and effects like cache-trashing can impose subtle penalties.
void usb_free_coherent (struct usb_device *dev, size_t size,
void *addr, dma_addr_t dma);
 
-  Most drivers should *NOT* be using these primitives; they don't need
+  Most drivers should **NOT** be using these primitives; they don't need
   to use this type of memory ("dma-coherent"), and memory returned from
-  kmalloc() will work just fine.
+  :c:func:`kmalloc` will work just fine.
 
   The memory buffer returned is "dma-coherent"; sometimes you might need to
   force a consistent memory access ordering by using memory barriers.  It's
   not using a streaming DMA mapping, so it's good for small transfers on
   systems where the I/O would otherwise thrash an IOMMU mapping.  (See
-  Documentation/DMA-API-HOWTO.txt for definitions of "coherent" and
+  ``Documentation/DMA-API-HOWTO.txt`` for definitions of "coherent" and
   "streaming" DMA mappings.)
 
   Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
@@ -75,15 +78,15 @@ and effects like cache-trashing can impose subtle penalties.
   way to expose these capabilities ... and in any case, HIGHMEM is mostly a
   design wart specific to x86_32.  So your best bet is to ensure you never
   pass a highmem buffer into a USB driver.  That's easy; it's the default
-  behavior.  Just don't override it; e.g. with NETIF_F_HIGHDMA.
+  behavior.  Just don't override it; e.g. with ``NETIF_F_HIGHDMA``.
 
   This may force your callers to do some bounce buffering, copying from
   high memory to "normal" DMA memory.  If you can come up with a good way
   to fix this issue (for x86_32 machines with over 1 GByte of memory),
   feel free to submit patches.
 
-
-WORKING WITH EXISTING BUFFERS
+Working with existing buffers
+=
 
 Existing buffers aren't usable for DMA without first being mapped into the
 DMA address space of the device.  However, most buffers passed to your
@@ -92,7 +95,7 @@ of Documentation/DMA-API-HOWTO.txt, titled "What memory is 
DMA-able?")
 
 - When you're using scatterlists, you can map everything at once.  O

[PATCH v2 17/22] usb.rst: get rid of some Sphinx errors

[Mauro Carvalho Chehab]

Get rid of those warnings:

Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: 
"usb_type".
Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: 
"usb_dir".
Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: 
"usb_recip".
Documentation/driver-api/usb/usb.rst:679: ERROR: Unknown target name: 
"usbdevfs_urb_type".

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/usb.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/driver-api/usb/usb.rst 
b/Documentation/driver-api/usb/usb.rst
index d15ab8ae5239..5ebaf669704c 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -615,8 +615,8 @@ USBDEVFS_CONTROL
 The first eight bytes of this structure are the contents of the
 SETUP packet to be sent to the device; see the USB 2.0 specification
 for details. The bRequestType value is composed by combining a
-USB_TYPE_\* value, a USB_DIR_\* value, and a USB_RECIP_\*
-value (from **). If wLength is nonzero, it describes
+``USB_TYPE_*`` value, a ``USB_DIR_*`` value, and a ``USB_RECIP_*``
+value (from ``linux/usb.h``). If wLength is nonzero, it describes
 the length of the data buffer, which is either written to the device
 (USB_DIR_OUT) or read from the device (USB_DIR_IN).
 
@@ -678,7 +678,7 @@ the blocking is separate.
 
 These requests are packaged into a structure that resembles the URB used
 by kernel device drivers. (No POSIX Async I/O support here, sorry.) It
-identifies the endpoint type (USBDEVFS_URB_TYPE_\*), endpoint
+identifies the endpoint type (``USBDEVFS_URB_TYPE_*``), endpoint
 (number, masked with USB_DIR_IN as appropriate), buffer and length,
 and a user "context" value serving to uniquely identify each request.
 (It's usually a pointer to per-request data.) Flags can modify requests
-- 
2.9.3

[PATCH v2 16/22] usb/URB.txt: convert to ReST and update it

[Mauro Carvalho Chehab]

The URB doc describes the Kernel mechanism that do USB transfers.
While the functions are already described at urb.h, there are a
number of concepts and theory that are important for USB driver
developers.

Convert it to ReST and use C ref links to point to the places
at usb.h where each function and struct is located.

A few of those descriptions were incomplete. While here, update
to reflect the current API status.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../{usb/URB.txt => driver-api/usb/URB.rst}| 205 -
 Documentation/driver-api/usb/index.rst |   1 +
 Documentation/driver-api/usb/usb.rst   |   2 +
 3 files changed, 119 insertions(+), 89 deletions(-)
 rename Documentation/{usb/URB.txt => driver-api/usb/URB.rst} (52%)

diff --git a/Documentation/usb/URB.txt b/Documentation/driver-api/usb/URB.rst
similarity index 52%
rename from Documentation/usb/URB.txt
rename to Documentation/driver-api/usb/URB.rst
index 50da0d455444..2bcd06c2c5aa 100644
--- a/Documentation/usb/URB.txt
+++ b/Documentation/driver-api/usb/URB.rst
@@ -1,16 +1,22 @@
-Revised: 2000-Dec-05.
-Again:   2002-Jul-06
-Again:   2005-Sep-19
+USB Request Block (URB)
+~~~
 
-NOTE:
+:Revised: 2000-Dec-05
+:Again:   2002-Jul-06
+:Again:   2005-Sep-19
+:Again:   2017-Mar-29
 
-The USB subsystem now has a substantial section in "The Linux Kernel API"
-guide (in Documentation/DocBook), generated from the current source
-code.  This particular documentation file isn't particularly current or
-complete; don't rely on it except for a quick overview.
 
+.. note::
 
-1.1. Basic concept or 'What is an URB?'
+The USB subsystem now has a substantial section at :ref:`usb-hostside-api`
+section, generated from the current source code.
+This particular documentation file isn't complete and may not be
+updated to the last version; don't rely on it except for a quick
+overview.
+
+Basic concept or 'What is an URB?'
+==
 
 The basic idea of the new driver is message passing, the message itself is 
 called USB Request Block, or URB for short. 
@@ -19,10 +25,11 @@ called USB Request Block, or URB for short.
   and deliver the data and status back. 
 
 - Execution of an URB is inherently an asynchronous operation, i.e. the 
-  usb_submit_urb(urb) call returns immediately after it has successfully
+  :c:func:`usb_submit_urb` call returns immediately after it has successfully
   queued the requested action.
 
-- Transfers for one URB can be canceled with usb_unlink_urb(urb) at any time. 
+- Transfers for one URB can be canceled with :c:func:`usb_unlink_urb`
+  at any time.
 
 - Each URB has a completion handler, which is called after the action
   has been successfully completed or canceled. The URB also contains a
@@ -35,53 +42,55 @@ called USB Request Block, or URB for short.
   of data to (or from) devices when using periodic transfer modes.
 
 
-1.2. The URB structure
+The URB structure
+=
 
-Some of the fields in an URB are:
+Some of the fields in struct :c:type:`urb` are::
 
-struct urb
-{
-// (IN) device and pipe specify the endpoint queue
+  struct urb
+  {
+  // (IN) device and pipe specify the endpoint queue
struct usb_device *dev; // pointer to associated USB device
unsigned int pipe;  // endpoint information
 
-   unsigned int transfer_flags;// ISO_ASAP, SHORT_NOT_OK, etc.
+   unsigned int transfer_flags;// URB_ISO_ASAP, URB_SHORT_NOT_OK, etc.
 
-// (IN) all urbs need completion routines
+  // (IN) all urbs need completion routines
void *context;  // context for completion routine
-   void (*complete)(struct urb *); // pointer to completion routine
+   usb_complete_t complete;// pointer to completion routine
 
-// (OUT) status after each completion
+  // (OUT) status after each completion
int status; // returned status
 
-// (IN) buffer used for data transfers
+  // (IN) buffer used for data transfers
void *transfer_buffer;  // associated data buffer
-   int transfer_buffer_length; // data buffer length
+   u32 transfer_buffer_length; // data buffer length
int number_of_packets;  // size of iso_frame_desc
 
-// (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
-   int actual_length;  // actual data buffer length
+  // (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
+   u32 actual_length;  // actual data buffer length
 
-// (IN) setup stage for CTRL (pass a struct usb_ctrlrequest)
-   unsigned char* setup_packet;// setup packet (control only)
+  // (IN) setup stage for CTRL (pass a struct usb_ctrlrequest)
+   unsigned char *setup_packet;// setup packet (control only)
 
-// Only for PERIODIC transfers (ISO, INTERRUPT)
-// (IN/OUT) start_frame is set un

[PATCH v2 18/22] usb: get rid of some ReST doc build errors

[Mauro Carvalho Chehab]

We need an space before a numbered list to avoid those warnings:

./drivers/usb/core/message.c:478: ERROR: Unexpected indentation.
./drivers/usb/core/message.c:479: WARNING: Block quote ends without a blank 
line; unexpected unindent.
./include/linux/usb/composite.h:455: ERROR: Unexpected indentation.
./include/linux/usb/composite.h:456: WARNING: Block quote ends without a blank 
line; unexpected unindent.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/usb/core/message.c| 1 +
 include/linux/usb/composite.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 2184ef40a82a..4c38ea41ae96 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -474,6 +474,7 @@ EXPORT_SYMBOL_GPL(usb_sg_init);
  * significantly improve USB throughput.
  *
  * There are three kinds of completion for this function.
+ *
  * (1) success, where io->status is zero.  The number of io->bytes
  * transferred is as requested.
  * (2) error, where io->status is a negative errno value.  The number
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 4616a49a1c2e..30a063e98c19 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -451,6 +451,7 @@ static inline struct usb_composite_driver *to_cdriver(
  * sure doing that won't hurt too much.
  *
  * One notion for how to handle Wireless USB devices involves:
+ *
  * (a) a second gadget here, discovery mechanism TBD, but likely
  * needing separate "register/unregister WUSB gadget" calls;
  * (b) updates to usb_gadget to include flags "is it wireless",
-- 
2.9.3

[PATCH v2 19/22] usb: composite.h: fix two warnings when building docs

[Mauro Carvalho Chehab]

By definition, we use /* private: */ tag when we won't be documenting
a parameter. However, those two parameters are documented:

./include/linux/usb/composite.h:510: warning: Excess struct/union/enum/typedef 
member 'setup_pending' description in 'usb_composite_dev'
./include/linux/usb/composite.h:510: warning: Excess struct/union/enum/typedef 
member 'os_desc_pending' description in 'usb_composite_dev'

So, we need to use /* public: */ to avoid a warning.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/usb/composite.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 30a063e98c19..f665d2ceac20 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -504,8 +504,9 @@ struct usb_composite_dev {
/* protects deactivations and delayed_status counts*/
spinlock_t  lock;
 
-   unsignedsetup_pending:1;
-   unsignedos_desc_pending:1;
+   /* public: */
+   unsigned intsetup_pending:1;
+   unsigned intos_desc_pending:1;
 };
 
 extern int usb_string_id(struct usb_composite_dev *c);
-- 
2.9.3

[PATCH v2 22/22] usb: document that URB transfer_buffer should be aligned

[Mauro Carvalho Chehab]

Several host controllers, commonly found on ARM, like dwc2,
require buffers that are CPU-word aligned for they to work.

Failing to do that will cause random troubles at the caller
drivers, causing them to fail.

Document it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/URB.rst | 12 
 drivers/usb/core/message.c   | 15 +++
 include/linux/usb.h  | 12 
 3 files changed, 39 insertions(+)

diff --git a/Documentation/driver-api/usb/URB.rst 
b/Documentation/driver-api/usb/URB.rst
index 810ceb0e71bb..2f3db660e613 100644
--- a/Documentation/driver-api/usb/URB.rst
+++ b/Documentation/driver-api/usb/URB.rst
@@ -271,6 +271,18 @@ If you specify your own start frame, make sure it's 
several frames in advance
 of the current frame.  You might want this model if you're synchronizing
 ISO data with some other event stream.
 
+ .. warning::
+
+   Several host drivers have a 32-bits or 64-bits DMA transfer word size,
+   with usually matches the CPU word. Due to such restriction, you should
+   warrant that the @transfer_buffer is DWORD aligned, on 32 bits system, or
+   QDWORD aligned, on 64 bits system. You should also ensure that the
+   buffer has enough space for PAD bits.
+
+   This condition is satisfied if you pass a buffer directly allocated by
+   kmalloc(), but this may not be the case if the driver allocates a bigger
+   buffer and point to a random place inside it.
+
 
 How to start interrupt (INT) transfers?
 ===
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 4c38ea41ae96..1662a4446475 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -128,6 +128,21 @@ static int usb_internal_control_msg(struct usb_device 
*usb_dev,
  * make sure your disconnect() method can wait for it to complete. Since you
  * don't have a handle on the URB used, you can't cancel the request.
  *
+ * .. note::
+ *
+ *   Several host drivers require that the @data buffer to be aligned
+ *   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).
+ *   It is up to USB drivers should ensure that they'll only pass buffers
+ *   with such alignments.
+ *
+ *   Please also notice that, due to such restriction, the host driver
+ *   may also override PAD bytes at the end of the @data buffer, up to the
+ *   size of the CPU word.
+ *
+ *   Such word alignment condition is normally ensured if the buffer is
+ *   allocated with kmalloc(), but this may not be the case if the driver
+ *   allocates a bigger buffer and point to a random place inside it.
+ *
  * Return: If successful, the number of bytes transferred. Otherwise, a 
negative
  * error number.
  */
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 7e68259360de..5739d4422343 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -1373,6 +1373,18 @@ typedef void (*usb_complete_t)(struct urb *);
  * capable, assign NULL to it, so that usbmon knows not to use the value.
  * The setup_packet must always be set, so it cannot be located in highmem.
  *
+ * .. warning::
+ *
+ *   Several host drivers have a 32-bits or 64-bits DMA transfer word size,
+ *   with usually matches the CPU word. Due to such restriction, you should
+ *   warrant that the @transfer_buffer is DWORD aligned, on 32 bits system, or
+ *   QDWORD aligned, on 64 bits system. You should also ensure that the
+ *   buffer has enough space for PAD bits.
+ *
+ *   This condition is satisfied if you pass a buffer directly allocated by
+ *   kmalloc(), but this may not be the case if the driver allocates a bigger
+ *   buffer and point to a random place inside it.
+ *
  * Initialization:
  *
  * All URBs submitted must initialize the dev, pipe, transfer_flags (may be
-- 
2.9.3

[PATCH v2 21/22] docs-rst: fix usb cross-references

[Mauro Carvalho Chehab]

As some USB documentation files got moved, adjust their
cross-references to their new place.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/ABI/stable/sysfs-bus-usb| 2 +-
 Documentation/driver-api/usb/URB.rst  | 2 ++
 Documentation/driver-api/usb/callbacks.rst| 4 ++--
 Documentation/driver-api/usb/error-codes.rst  | 2 ++
 Documentation/driver-api/usb/persist.rst  | 2 ++
 Documentation/driver-api/usb/power-management.rst | 2 +-
 Documentation/driver-api/usb/usb.rst  | 4 ++--
 Documentation/power/swsusp.txt| 2 +-
 drivers/staging/most/hdm-usb/hdm_usb.c| 2 +-
 drivers/usb/core/Kconfig  | 2 +-
 10 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-bus-usb 
b/Documentation/ABI/stable/sysfs-bus-usb
index 831f15d9672f..b832eeff 100644
--- a/Documentation/ABI/stable/sysfs-bus-usb
+++ b/Documentation/ABI/stable/sysfs-bus-usb
@@ -9,7 +9,7 @@ Description:
hubs this facility is always enabled and their device
directories will not contain this file.
 
-   For more information, see Documentation/usb/persist.txt.
+   For more information, see 
Documentation/driver-api/usb/persist.rst.
 
 What:  /sys/bus/usb/devices/.../power/autosuspend
 Date:  March 2007
diff --git a/Documentation/driver-api/usb/URB.rst 
b/Documentation/driver-api/usb/URB.rst
index 2bcd06c2c5aa..810ceb0e71bb 100644
--- a/Documentation/driver-api/usb/URB.rst
+++ b/Documentation/driver-api/usb/URB.rst
@@ -1,3 +1,5 @@
+.. _usb-urb:
+
 USB Request Block (URB)
 ~~~
 
diff --git a/Documentation/driver-api/usb/callbacks.rst 
b/Documentation/driver-api/usb/callbacks.rst
index 93a8d53e27e7..2b80cf54bcc3 100644
--- a/Documentation/driver-api/usb/callbacks.rst
+++ b/Documentation/driver-api/usb/callbacks.rst
@@ -8,7 +8,7 @@ Usbcore will call into a driver through callbacks defined in 
the driver
 structure and through the completion handler of URBs a driver submits.
 Only the former are in the scope of this document. These two kinds of
 callbacks are completely independent of each other. Information on the
-completion callback can be found in Documentation/usb/URB.txt.
+completion callback can be found in :ref:`usb-urb`.
 
 The callbacks defined in the driver structure are:
 
@@ -53,7 +53,7 @@ The callbacks defined in the driver structure are:
 
 The ioctl interface (2) should be used only if you have a very good
 reason. Sysfs is preferred these days. The PM callbacks are covered
-separately in Documentation/usb/power-management.txt.
+separately in :ref:`usb-power-management`.
 
 Calling conventions
 ===
diff --git a/Documentation/driver-api/usb/error-codes.rst 
b/Documentation/driver-api/usb/error-codes.rst
index 9c11a0fd16cb..a3e84bfac776 100644
--- a/Documentation/driver-api/usb/error-codes.rst
+++ b/Documentation/driver-api/usb/error-codes.rst
@@ -1,3 +1,5 @@
+.. _usb-error-codes:
+
 USB Error codes
 ~~~
 
diff --git a/Documentation/driver-api/usb/persist.rst 
b/Documentation/driver-api/usb/persist.rst
index ea1b43f0559e..08cafc6292c1 100644
--- a/Documentation/driver-api/usb/persist.rst
+++ b/Documentation/driver-api/usb/persist.rst
@@ -1,3 +1,5 @@
+.. _usb-persist:
+
 USB device persistence during system suspend
 
 
diff --git a/Documentation/driver-api/usb/power-management.rst 
b/Documentation/driver-api/usb/power-management.rst
index c068257f6d27..79beb807996b 100644
--- a/Documentation/driver-api/usb/power-management.rst
+++ b/Documentation/driver-api/usb/power-management.rst
@@ -328,7 +328,7 @@ possible to work around the hibernation-forces-disconnect 
problem by
 using the USB Persist facility.)
 
 The ``reset_resume`` method is used by the USB Persist facility (see
-``Documentation/usb/persist.txt``) and it can also be used under certain
+:ref:`usb-persist`) and it can also be used under certain
 circumstances when ``CONFIG_USB_PERSIST`` is not enabled.  Currently, if a
 device is reset during a resume and the driver does not have a
 ``reset_resume`` method, the driver won't receive any notification about
diff --git a/Documentation/driver-api/usb/usb.rst 
b/Documentation/driver-api/usb/usb.rst
index 5ebaf669704c..6824089ef4c8 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -424,8 +424,8 @@ header.
 Unless noted otherwise, the ioctl requests described here will update
 the modification time on the usbfs file to which they are applied
 (unless they fail). A return of zero indicates success; otherwise, a
-standard USB error code is returned. (These are documented in
-``Documentation/usb/error-codes.txt`` in your kernel sources.)
+standard USB error code is returned (These are documented in
+:ref:`usb-error-codes`).
 
 Each of these files multiplexes access to several I/O streams, 

[PATCH v2 02/22] driver-api/basics.rst: add device table header

[Mauro Carvalho Chehab]

The structs there at device table are used by other documentation
at the Kernel. So, add it to the driver API.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/basics.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/driver-api/basics.rst 
b/Documentation/driver-api/basics.rst
index 935b9b8d456c..472e7a664d13 100644
--- a/Documentation/driver-api/basics.rst
+++ b/Documentation/driver-api/basics.rst
@@ -7,6 +7,12 @@ Driver Entry and Exit points
 .. kernel-doc:: include/linux/init.h
:internal:
 
+Driver device table
+---
+
+.. kernel-doc:: include/linux/mod_devicetable.h
+   :internal:
+
 Atomic and pointer manipulation
 ---
 
-- 
2.9.3

[PATCH v2 09/22] usb/bulk-streams.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../bulk-streams.txt => driver-api/usb/bulk-streams.rst}| 13 +
 Documentation/driver-api/usb/index.rst  |  1 +
 2 files changed, 10 insertions(+), 4 deletions(-)
 rename Documentation/{usb/bulk-streams.txt => driver-api/usb/bulk-streams.rst} 
(94%)

diff --git a/Documentation/usb/bulk-streams.txt 
b/Documentation/driver-api/usb/bulk-streams.rst
similarity index 94%
rename from Documentation/usb/bulk-streams.txt
rename to Documentation/driver-api/usb/bulk-streams.rst
index ffc02021863e..99b515babdeb 100644
--- a/Documentation/usb/bulk-streams.txt
+++ b/Documentation/driver-api/usb/bulk-streams.rst
@@ -1,3 +1,6 @@
+USB bulk streams
+
+
 Background
 ==
 
@@ -25,7 +28,9 @@ time.
 Driver implications
 ===
 
-int usb_alloc_streams(struct usb_interface *interface,
+::
+
+  int usb_alloc_streams(struct usb_interface *interface,
struct usb_host_endpoint **eps, unsigned int num_eps,
unsigned int num_streams, gfp_t mem_flags);
 
@@ -53,7 +58,7 @@ controller driver, and may change in the future.
 
 
 Picking new Stream IDs to use
-
+=
 
 Stream ID 0 is reserved, and should not be used to communicate with devices.  
If
 usb_alloc_streams() returns with a value of N, you may use streams 1 though N.
@@ -68,9 +73,9 @@ Clean up
 
 
 If a driver wishes to stop using streams to communicate with the device, it
-should call
+should call::
 
-void usb_free_streams(struct usb_interface *interface,
+  void usb_free_streams(struct usb_interface *interface,
struct usb_host_endpoint **eps, unsigned int num_eps,
gfp_t mem_flags);
 
diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 5dfb04b2d730..6fe7611f7332 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -7,6 +7,7 @@ Linux USB API
usb
gadget
anchors
+   bulk-streams
writing_usb_driver
writing_musb_glue_layer
 
-- 
2.9.3

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 12:34:32 +0300
Laurent Pinchart  escreveu:

> Hi Oliver,
> 
> On Thursday 30 Mar 2017 10:11:31 Oliver Neukum wrote:
> > Am Donnerstag, den 30.03.2017, 01:15 +0300 schrieb Laurent Pinchart:  
> > > > +   may also override PAD bytes at the end of the ``transfer_buffer``,
> > > > up to the
> > > > +   size of the CPU word.  
> > > 
> > > "May" is quite weak here. If some host controller drivers require buffers
> > > to be aligned, then it's an API requirement, and all buffers must be
> > > aligned. I'm not even sure I would mention that some host drivers require
> > > it, I think we should just state that the API requires buffers to be
> > > aligned.  
> > 
> > That effectively changes the API. Many network drivers are written with
> > the assumption that any contiguous buffer is valid. In fact you could
> > argue that those drivers are buggy and must use bounce buffers in those
> > cases.

Blaming the dwc2 driver was my first approach, but such patch got nacked ;)

Btw, the dwc2 driver has a routine that creates a temporary buffer if the
buffer pointer is not DWORD aligned. My first approach were to add
a logic there to also use the temporary buffer if the buffer size is
not DWORD aligned:
https://patchwork.linuxtv.org/patch/40093/

While debugging this issue, I saw *a lot* of network-generated URB
traffic from RPi3 Ethernet port drivers that were using non-aligned 
buffers and were subject to the temporary buffer conversion.

My understanding here is that having a temporary bounce buffer sucks,
as the performance and latency are affected. So, I see the value of
adding this constraint to the API, pushing the task of getting 
aligned buffers to the USB drivers, but you're right: that means a lot
of work, as all USB drivers should be reviewed.

Btw, I'm a lot more concerned about USB storage drivers. When I was
discussing about this issue at the #raspberrypi-devel IRC channel,
someone complained that, after switching from the RPi downstream Kernel
to upstream, his USB data storage got corrupted. Well, if the USB
storage drivers also assume that the buffer can be continuous,
that can corrupt data.

That's why I think that being verbose here is a good idea.

I'll rework on this patch to put more emphasis about this issue.

> > 
> > So we need to include the full story here.  
> 
> I personally don't care much about whose side is responsible for handling the 
> alignment constraints, but I want it to be documented before "fixing" any USB 
> driver.
> 



Thanks,
Mauro

Re: [PATCH 2/2] staging: atomisp: use local variable to reduce the number of reference

[DaeSeok Youn]

2017-03-30 16:19 GMT+09:00 walter harms :
>
>
> Am 30.03.2017 08:25, schrieb Daeseok Youn:
>> Define new local variable to reduce the number of reference.
>> The new local variable is added to save the addess of dfs
>> and used in atomisp_freq_scaling() function.
>>
>> Signed-off-by: Daeseok Youn 
>> ---
>>  .../media/atomisp/pci/atomisp2/atomisp_cmd.c   | 37 
>> --
>>  1 file changed, 20 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
>> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
>> index eebfccd..d76a95c 100644
>> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
>> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
>> @@ -251,6 +251,7 @@ int atomisp_freq_scaling(struct atomisp_device *isp,
>>  {
>>   /* FIXME! Only use subdev[0] status yet */
>>   struct atomisp_sub_device *asd = &isp->asd[0];
>> + const struct atomisp_dfs_config *dfs;
>>   unsigned int new_freq;
>>   struct atomisp_freq_scaling_rule curr_rules;
>>   int i, ret;
>> @@ -268,20 +269,22 @@ int atomisp_freq_scaling(struct atomisp_device *isp,
>>   ATOMISP_USE_YUVPP(asd))
>>   isp->dfs = &dfs_config_cht_soc;
>>
>> - if (isp->dfs->lowest_freq == 0 || isp->dfs->max_freq_at_vmin == 0 ||
>> - isp->dfs->highest_freq == 0 || isp->dfs->dfs_table_size == 0 ||
>> - !isp->dfs->dfs_table) {
>> + dfs = isp->dfs;
>> +
>> + if (dfs->lowest_freq == 0 || dfs->max_freq_at_vmin == 0 ||
>> + dfs->highest_freq == 0 || dfs->dfs_table_size == 0 ||
>> + !dfs->dfs_table) {
>>   dev_err(isp->dev, "DFS configuration is invalid.\n");
>>   return -EINVAL;
>>   }
>>
>>   if (mode == ATOMISP_DFS_MODE_LOW) {
>> - new_freq = isp->dfs->lowest_freq;
>> + new_freq = dfs->lowest_freq;
>>   goto done;
>>   }
>>
>>   if (mode == ATOMISP_DFS_MODE_MAX) {
>> - new_freq = isp->dfs->highest_freq;
>> + new_freq = dfs->highest_freq;
>>   goto done;
>>   }
>>
>> @@ -307,26 +310,26 @@ int atomisp_freq_scaling(struct atomisp_device *isp,
>>   }
>>
>>   /* search for the target frequency by looping freq rules*/
>> - for (i = 0; i < isp->dfs->dfs_table_size; i++) {
>> - if (curr_rules.width != isp->dfs->dfs_table[i].width &&
>> - isp->dfs->dfs_table[i].width != ISP_FREQ_RULE_ANY)
>> + for (i = 0; i < dfs->dfs_table_size; i++) {
>> + if (curr_rules.width != dfs->dfs_table[i].width &&
>> + dfs->dfs_table[i].width != ISP_FREQ_RULE_ANY)
>>   continue;
>> - if (curr_rules.height != isp->dfs->dfs_table[i].height &&
>> - isp->dfs->dfs_table[i].height != ISP_FREQ_RULE_ANY)
>> + if (curr_rules.height != dfs->dfs_table[i].height &&
>> + dfs->dfs_table[i].height != ISP_FREQ_RULE_ANY)
>>   continue;
>> - if (curr_rules.fps != isp->dfs->dfs_table[i].fps &&
>> - isp->dfs->dfs_table[i].fps != ISP_FREQ_RULE_ANY)
>> + if (curr_rules.fps != dfs->dfs_table[i].fps &&
>> + dfs->dfs_table[i].fps != ISP_FREQ_RULE_ANY)
>>   continue;
>> - if (curr_rules.run_mode != isp->dfs->dfs_table[i].run_mode &&
>> - isp->dfs->dfs_table[i].run_mode != ISP_FREQ_RULE_ANY)
>> + if (curr_rules.run_mode != dfs->dfs_table[i].run_mode &&
>> + dfs->dfs_table[i].run_mode != ISP_FREQ_RULE_ANY)
>>   continue;
>>   break;
>>   }
>
>>
>> - if (i == isp->dfs->dfs_table_size)
>> - new_freq = isp->dfs->max_freq_at_vmin;
>> + if (i == dfs->dfs_table_size)
>> + new_freq = dfs->max_freq_at_vmin;
>>   else
>> - new_freq = isp->dfs->dfs_table[i].isp_freq;
>> + new_freq = dfs->dfs_table[i].isp_freq;
>>
>
> you can eliminate the last block by setting
>
>  new_freq = dfs->max_freq_at_vmin;
>
>   for(i=0;) {
> 
> new_freq = dfs->dfs_table[i].isp_freq;
> break;
> }
Yes, it could be. I will make another patch to improve it as your comment.
>
> unfortunately i have no good idea how to make the loop more readable.
I am not sure whether the for-loop is possible to improve for
readability or not. :-)

Thanks for comment.
Regards,
Daeseok.
>
>
> re,
>  wh
>
>
>>  done:
>>   dev_dbg(isp->dev, "DFS target frequency=%d.\n", new_freq);

Re: [PATCH 02/22] docs-rst: convert usb docbooks to ReST

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 11:20:14 +0200
Markus Heiser  escreveu:

> Am 30.03.2017 um 10:21 schrieb Jani Nikula :
> 
> > On Thu, 30 Mar 2017, Markus Heiser  wrote:  
> >> Hi Mauro,
> >> 
> >> Am 29.03.2017 um 20:54 schrieb Mauro Carvalho Chehab 
> >> :
> >>   
> >>> As we're moving out of DocBook, let's convert the remaining
> >>> USB docbooks to ReST.
> >>> 
> >>> The transformation itself on this patch is a no-brainer
> >>> conversion using pandoc.  
> >> 
> >> right, its a no-brainer ;-) I'am not very happy with this
> >> conversions, some examples see below.
> >> 
> >> I recommend to use a more elaborate conversion as starting point,
> >> e.g. from my sphkerneldoc project:
> >> 
> >> * 
> >> https://github.com/return42/sphkerneldoc/tree/master/Documentation/books_migrated/gadget
> >> * 
> >> https://github.com/return42/sphkerneldoc/tree/master/Documentation/books_migrated/writing_musb_glue_layer
> >> * 
> >> https://github.com/return42/sphkerneldoc/tree/master/Documentation/books_migrated/writing_usb_driver
> >> 
> >> Since these DocBooks hasn't been changed in the last month, the linked reST
> >> should be up to date.  
> > 
> > Markus, I know you've done a lot of work on your conversions, and you
> > like to advocate them, but AFAICT you have never posted the conversions
> > as patches to the list. Your project isn't a clone of the kernel
> > tree. It's a pile of .rst files that nobody knows how to produce from
> > current upstream DocBook .tmpl files. I'm sorry, but this just doesn't
> > work that way.  
> 
> The conversion is done with the dbxml2rst tool:
> 
>   https://github.com/return42/dbxml2rst
> 
> But you are right, the links I send are decoupled from kernel. It is
> a 5 month old snapshot of a DocBook to reST conversion (now updated,
> with no affect to the linked files, since they have not been patched
> in the meantime) ...
> 
> > At this point I'd just go with what Mauro has. It's here now, as
> > patches. We've seen from the GPU documentation that polishing the
> > one-time initial conversion is, after a point, wasted effort. Having the
> > documentation in rst attracts more attention and contributions, and any
> > remaining issues will get ironed out in rst.  
> 
> I totally agree with you (I have never said something different)
> 
> > This is also one reason I'm in favor of just bulk converting the rest of
> > the .tmpl files using Documentation/sphinx/tmplcvt, get rid of DocBook
> > and be done with it, and have the crowds focus on rst.  
> 
> I also agree with that. The tmplcvt script is good enough for this task,
> the dbxml2rst tool is more elaborate.

I like the idea of a bulk conversion. My personal preference here is to
use the tmplcvt for such task, at least for simple books like the ones
I converted from USB.

The advantage is that it places everything on a single rst file, with,
IMHO, works best for books that aren't too complex.

Of course, it doesn't hurt to compare the end result with dbxml2rst
and see if something could be improved.

> 
> If Jonathan also likes to have a bulk conversion of the rest DocBooks,
> we can use tmplcvt or even dbxml2rst for this task. Everything under
> 
>   
> https://github.com/return42/sphkerneldoc/tree/master/Documentation/books_migrated
> 
> is just a "make dbxm2rst", I can update every time and if a bulk conversion
> is the way ... I can send such patches or you send a tmplcvt conversion.
> 
> @Jon: what do you think about a bulk conversion?
> 
>  -- Markus --
>   


Thanks,
Mauro

[PATCH] staging/atomisp: fix spelling mistake: "falied" -> "failed"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in dev_err error message

Signed-off-by: Colin Ian King 
---
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c
index 87090cea5b9d..d22a2d2388c2 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c
@@ -59,7 +59,7 @@ int hmm_bo_device_init(struct hmm_bo_device *bdev,
 
ret = hmm_vm_init(&bdev->vaddr_space, vaddr_start, size);
if (ret) {
-   dev_err(atomisp_dev, "hmm_vm_init falied. vaddr_start = 0x%x, 
size = %d\n",
+   dev_err(atomisp_dev, "hmm_vm_init failed. vaddr_start = 0x%x, 
size = %d\n",
vaddr_start, size);
goto vm_init_err;
}
-- 
2.11.0

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Laurent Pinchart]

Hi Mauro,

On Wednesday 29 Mar 2017 22:06:33 Mauro Carvalho Chehab wrote:
> Em Thu, 30 Mar 2017 01:15:27 +0300 Laurent Pinchart escreveu:
> > On Wednesday 29 Mar 2017 15:54:21 Mauro Carvalho Chehab wrote:
> > > Several host controllers, commonly found on ARM, like dwc2,
> > > require buffers that are CPU-word aligned for they to work.
> > > 
> > > Failing to do that will cause random troubles at the caller
> > > drivers, causing them to fail.
> > > 
> > > Document it.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab 
> > > ---
> > > 
> > >  Documentation/driver-api/usb/URB.rst | 18 ++
> > >  drivers/usb/core/message.c   | 15 +++
> > >  include/linux/usb.h  | 18 ++
> > >  3 files changed, 51 insertions(+)
> > > 
> > > diff --git a/Documentation/driver-api/usb/URB.rst
> > > b/Documentation/driver-api/usb/URB.rst index d9ea6a3996e7..b83b557e9891
> > > 100644
> > > --- a/Documentation/driver-api/usb/URB.rst
> > > +++ b/Documentation/driver-api/usb/URB.rst
> > > @@ -274,6 +274,24 @@ If you specify your own start frame, make sure it's
> > > several frames in advance of the current frame.  You might want this
> > > model
> > > if you're synchronizing ISO data with some other event stream.
> > > 
> > > +.. note::
> > > +
> > > +   Several host drivers require that the ``transfer_buffer`` to be
> > > aligned
> > > +   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64
> > > bits).
> > 
> > Is it the CPU word size or the DMA transfer size ? I assume the latter,
> > and I wouldn't be surprised if the alignment requirement was 32-bit on at
> > least some of the 64-bit platforms.
> 
> Yeah, it is actually the DMA transfer size. Yet, worse case scenario is that
> the DMA transfer size to be 64 bits on 64 bits CPU.
> 
> > > +   It is up to USB drivers should ensure that they'll only pass buffers
> > > +   with such alignments.
> > > +
> > > +   Please also notice that, due to such restriction, the host driver
> > 
> > s/notice/note/ (and below as well) ?
> 
> OK.
> 
> > > +   may also override PAD bytes at the end of the ``transfer_buffer``,
> > > up to the
> > > +   size of the CPU word.
> > 
> > "May" is quite weak here. If some host controller drivers require buffers
> > to be aligned, then it's an API requirement, and all buffers must be
> > aligned. I'm not even sure I would mention that some host drivers require
> > it, I think we should just state that the API requires buffers to be
> > aligned.
> 
> What I'm trying to say here is that, on a 32-bits system, if the driver do
> a USB_DIR_IN transfer using some code similar to:
> 
>   size = 4;
>   buffer = kmalloc(size, GFP_KERNEL);
> 
>   usb_control_msg(udev, pipe, req, type, val, idx, buffer + 2, 2, 
timeout);
>   usb_control_msg(udev, pipe, req, type, val, idx, buffer, size, 
timeout);
> 
> Drivers like dwc2 will mess with the buffer.
> 
> The first transfer will actually work, due to a workaround inside the
> driver that will create a temporary DWORD-aligned buffer, avoiding it
> to go past the buffer.
> 
> However, the second transfer will destroy the data received from the
> first usb_control_msg(), as it will write 4 bytes at the buffer.
> 
> Not all drivers would do that, though.
> 
> Please notice that, as kmalloc will always return a CPU-aligned buffer,
> if the client do something like:
> 
>   size = 2;
>   buffer = kmalloc(size, GFP_KERNEL);
> 
>   usb_control_msg(udev, pipe, req, type, val, idx, buffer, 2, timeout);
> 
> What happens there is that the DMA engine will still write 4 bytes at
> the buffer, but the 2 bytes that go past the end of buffer will be
> written on a memory that will never be used.

I understand that, but stating that host controller drivers "may" do this 
won't help much. If they *may*, all USB device drivers *must* align buffers 
correctly. That's the part that needs to be documented. Let's not confuse 
developers by only stating that something may happened, let's be clear and 
tell what they must do.

> > > +   Please notice that ancillary routines that transfer URBs, like
> > > +   usb_control_msg() also have such restriction.
> > > +
> > > +   Such word alignment condition is normally ensured if the buffer is
> > > +   allocated with kmalloc(), but this may not be the case if the driver
> > > +   allocates a bigger buffer and point to a random place inside it.
> > > +
> > > 
> > >  How to start interrupt (INT) transfers?
> > >  ===
> > > 
> > > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > > index 4c38ea41ae96..1662a4446475 100644
> > > --- a/drivers/usb/core/message.c
> > > +++ b/drivers/usb/core/message.c
> > > @@ -128,6 +128,21 @@ static int usb_internal_control_msg(struct
> > > usb_device
> > > *usb_dev, * make sure your disconnect() method can wait for it to
> > > complete.
> > > Since you * don't have a handle on the URB used, you can't cancel the
> >

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Laurent Pinchart]

Hi Oliver,

On Thursday 30 Mar 2017 10:11:31 Oliver Neukum wrote:
> Am Donnerstag, den 30.03.2017, 01:15 +0300 schrieb Laurent Pinchart:
> > > +   may also override PAD bytes at the end of the ``transfer_buffer``,
> > > up to the
> > > +   size of the CPU word.
> > 
> > "May" is quite weak here. If some host controller drivers require buffers
> > to be aligned, then it's an API requirement, and all buffers must be
> > aligned. I'm not even sure I would mention that some host drivers require
> > it, I think we should just state that the API requires buffers to be
> > aligned.
> 
> That effectively changes the API. Many network drivers are written with
> the assumption that any contiguous buffer is valid. In fact you could
> argue that those drivers are buggy and must use bounce buffers in those
> cases.
> 
> So we need to include the full story here.

I personally don't care much about whose side is responsible for handling the 
alignment constraints, but I want it to be documented before "fixing" any USB 
driver.

-- 
Regards,

Laurent Pinchart

Re: [PATCHv5 11/11] arm: sti: update sti-cec for CEC notifier support

[Hans Verkuil]

On 03/30/2017 11:30 AM, Patrice CHOTARD wrote:
> Hi Benjamin
> 
> On 03/30/2017 09:41 AM, Benjamin Gaignard wrote:
>> + Patrice for sti DT
> 
> In order to be coherent with all previous STi DT patches,
> 
> can you update the commit message with "ARM: dts: STiH410: update 
> sti-cec for CEC notifier support"

Done.

Regards,

Hans

> 
> Thanks
> 
> Patrice
> 
>>
>> 2017-03-29 16:15 GMT+02:00 Hans Verkuil :
>>> From: Benjamin Gaignard 
>>>
>>> To use CEC notifier sti CEC driver needs to get phandle
>>> of the hdmi device.
>>>
>>> Signed-off-by: Benjamin Gaignard 
>>> Signed-off-by: Hans Verkuil 
>>> CC: devicet...@vger.kernel.org
>>> ---
>>>  arch/arm/boot/dts/stih407-family.dtsi | 12 
>>>  arch/arm/boot/dts/stih410.dtsi| 13 +
>>>  2 files changed, 13 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
>>> b/arch/arm/boot/dts/stih407-family.dtsi
>>> index d753ac36788f..044184580326 100644
>>> --- a/arch/arm/boot/dts/stih407-family.dtsi
>>> +++ b/arch/arm/boot/dts/stih407-family.dtsi
>>> @@ -742,18 +742,6 @@
>>>  <&clk_s_c0_flexgen CLK_ETH_PHY>;
>>> };
>>>
>>> -   cec: sti-cec@094a087c {
>>> -   compatible = "st,stih-cec";
>>> -   reg = <0x94a087c 0x64>;
>>> -   clocks = <&clk_sysin>;
>>> -   clock-names = "cec-clk";
>>> -   interrupts = ;
>>> -   interrupt-names = "cec-irq";
>>> -   pinctrl-names = "default";
>>> -   pinctrl-0 = <&pinctrl_cec0_default>;
>>> -   resets = <&softreset STIH407_LPM_SOFTRESET>;
>>> -   };
>>> -
>>> rng10: rng@08a89000 {
>>> compatible  = "st,rng";
>>> reg = <0x08a89000 0x1000>;
>>> diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
>>> index 3c9672c5b09f..21fe72b183d8 100644
>>> --- a/arch/arm/boot/dts/stih410.dtsi
>>> +++ b/arch/arm/boot/dts/stih410.dtsi
>>> @@ -281,5 +281,18 @@
>>>  <&clk_s_c0_flexgen CLK_ST231_DMU>,
>>>  <&clk_s_c0_flexgen CLK_FLASH_PROMIP>;
>>> };
>>> +
>>> +   sti-cec@094a087c {
>>> +   compatible = "st,stih-cec";
>>> +   reg = <0x94a087c 0x64>;
>>> +   clocks = <&clk_sysin>;
>>> +   clock-names = "cec-clk";
>>> +   interrupts = ;
>>> +   interrupt-names = "cec-irq";
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <&pinctrl_cec0_default>;
>>> +   resets = <&softreset STIH407_LPM_SOFTRESET>;
>>> +   hdmi-phandle = <&sti_hdmi>;
>>> +   };
>>> };
>>>  };
>>> --
>>> 2.11.0
>>>
>>
>>
>>
> 

Re: [PATCHv5 11/11] arm: sti: update sti-cec for CEC notifier support

[Patrice CHOTARD]

Hi Benjamin

On 03/30/2017 09:41 AM, Benjamin Gaignard wrote:
> + Patrice for sti DT

In order to be coherent with all previous STi DT patches,

can you update the commit message with "ARM: dts: STiH410: update 
sti-cec for CEC notifier support"

Thanks

Patrice

>
> 2017-03-29 16:15 GMT+02:00 Hans Verkuil :
>> From: Benjamin Gaignard 
>>
>> To use CEC notifier sti CEC driver needs to get phandle
>> of the hdmi device.
>>
>> Signed-off-by: Benjamin Gaignard 
>> Signed-off-by: Hans Verkuil 
>> CC: devicet...@vger.kernel.org
>> ---
>>  arch/arm/boot/dts/stih407-family.dtsi | 12 
>>  arch/arm/boot/dts/stih410.dtsi| 13 +
>>  2 files changed, 13 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
>> b/arch/arm/boot/dts/stih407-family.dtsi
>> index d753ac36788f..044184580326 100644
>> --- a/arch/arm/boot/dts/stih407-family.dtsi
>> +++ b/arch/arm/boot/dts/stih407-family.dtsi
>> @@ -742,18 +742,6 @@
>>  <&clk_s_c0_flexgen CLK_ETH_PHY>;
>> };
>>
>> -   cec: sti-cec@094a087c {
>> -   compatible = "st,stih-cec";
>> -   reg = <0x94a087c 0x64>;
>> -   clocks = <&clk_sysin>;
>> -   clock-names = "cec-clk";
>> -   interrupts = ;
>> -   interrupt-names = "cec-irq";
>> -   pinctrl-names = "default";
>> -   pinctrl-0 = <&pinctrl_cec0_default>;
>> -   resets = <&softreset STIH407_LPM_SOFTRESET>;
>> -   };
>> -
>> rng10: rng@08a89000 {
>> compatible  = "st,rng";
>> reg = <0x08a89000 0x1000>;
>> diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
>> index 3c9672c5b09f..21fe72b183d8 100644
>> --- a/arch/arm/boot/dts/stih410.dtsi
>> +++ b/arch/arm/boot/dts/stih410.dtsi
>> @@ -281,5 +281,18 @@
>>  <&clk_s_c0_flexgen CLK_ST231_DMU>,
>>  <&clk_s_c0_flexgen CLK_FLASH_PROMIP>;
>> };
>> +
>> +   sti-cec@094a087c {
>> +   compatible = "st,stih-cec";
>> +   reg = <0x94a087c 0x64>;
>> +   clocks = <&clk_sysin>;
>> +   clock-names = "cec-clk";
>> +   interrupts = ;
>> +   interrupt-names = "cec-irq";
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <&pinctrl_cec0_default>;
>> +   resets = <&softreset STIH407_LPM_SOFTRESET>;
>> +   hdmi-phandle = <&sti_hdmi>;
>> +   };
>> };
>>  };
>> --
>> 2.11.0
>>
>
>
>

Re: [PATCH 04/22] gadget.rst: Enrich its ReST representation and add kernel-doc tag

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 10:04:32 +0300
Jani Nikula  escreveu:

> On Thu, 30 Mar 2017, Jani Nikula  wrote:
> > On Wed, 29 Mar 2017, Mauro Carvalho Chehab  
> > wrote:  
> >> The pandoc conversion is not perfect. Do handwork in order to:
> >>
> >> - add a title to this chapter;
> >> - use the proper warning and note markups;
> >> - use kernel-doc to include Kernel header and c files;  
> >
> > Please look at Documentation/sphinx/tmplcvt which takes care of all of
> > that.  
> 
> That said, since you've already manually done the work, you might want
> to do another conversion using the script, and diff the results to see
> if there's something you've perhaps missed. I'm pretty sure nobody's
> going to read patch 2 line-by-line...

Done. The only thing left was the original docbook title and author
information.

The diff also showed that I was a little lazy manually adjust the
gadget.rst document ;) The enclosed patch should fix those issues.

I'll likely fold it with other patches when sending a version 2.

Regards,
Mauro

[PATCH] docs-rst: improve docbook-converted documents

The output of Documentation/sphinx/tmplcvt showed that a few
adjustments could be done in order to improve the output of
the two files that were converted from docbook:

- Use the original title from docbook;
- Add author info;
- Add C references for source code xrefs;
- Use monospaced fonts to be consistent with other docs.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/driver-api/usb/gadget.rst 
b/Documentation/driver-api/usb/gadget.rst
index 0488b89de21c..4b02c61a389d 100644
--- a/Documentation/driver-api/usb/gadget.rst
+++ b/Documentation/driver-api/usb/gadget.rst
@@ -1,6 +1,9 @@
-Linux-USB "Gadget" kernel mode API
-~~
+
+USB Gadget API for Linux
+
 
+:Author: David Brownell
+:Date:   20 August 2004
 
 Introduction
 
@@ -35,7 +38,7 @@ address a number of important problems, including:
resources.
 
 Most Linux developers will not be able to use this API, since they have
-USB "host" hardware in a PC, workstation, or server. Linux users with
+USB ``host`` hardware in a PC, workstation, or server. Linux users with
 embedded systems are more likely to have USB peripheral hardware. To
 distinguish drivers running inside such hardware from the more familiar
 Linux "USB device drivers", which are host side proxies for the real USB
@@ -61,7 +64,7 @@ Structure of Gadget Drivers
 
 A system running inside a USB peripheral normally has at least three
 layers inside the kernel to handle USB protocol processing, and may have
-additional layers in user space code. The "gadget" API is used by the
+additional layers in user space code. The ``gadget`` API is used by the
 middle layer to interact with the lowest level (which directly handles
 hardware).
 
@@ -140,13 +143,13 @@ In Linux, from the bottom up, these layers are:
 *Additional Layers*
 Other layers may exist. These could include kernel layers, such as
 network protocol stacks, as well as user mode applications building
-on standard POSIX system call APIs such as *open()*, *close()*,
-*read()* and *write()*. On newer systems, POSIX Async I/O calls may
+on standard POSIX system call APIs such as ``open()``, ``close()``,
+``read()`` and ``write()``. On newer systems, POSIX Async I/O calls may
 be an option. Such user mode code will not necessarily be subject to
 the GNU General Public License (GPL).
 
 OTG-capable systems will also need to include a standard Linux-USB host
-side stack, with *usbcore*, one or more *Host Controller Drivers*
+side stack, with ``usbcore``, one or more *Host Controller Drivers*
 (HCDs), *USB Device Drivers* to support the OTG "Targeted Peripheral
 List", and so forth. There will also be an *OTG Controller Driver*,
 which is visible to gadget and device driver developers only indirectly.
@@ -171,11 +174,11 @@ combined, to implement composite devices.
 Kernel Mode Gadget API
 ==
 
-Gadget drivers declare themselves through a *struct
-usb\_gadget\_driver*, which is responsible for most parts of enumeration
-for a *struct usb\_gadget*. The response to a set\_configuration usually
-involves enabling one or more of the *struct usb\_ep* objects exposed by
-the gadget, and submitting one or more *struct usb\_request* buffers to
+Gadget drivers declare themselves through a struct
+:c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration
+for a struct :c:type:`usb_gadget`. The response to a set_configuration usually
+involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by
+the gadget, and submitting one or more struct :c:type:`usb_request` buffers to
 transfer data. Understand those four data types, and their operations,
 and you will understand how this API works.
 
@@ -239,28 +242,28 @@ needs to handle some differences. Use the API like this:
 1. Register a driver f

Dear user

[ADMIN]

Dear user

Your mailbox has exceeded the storage limit of 20GB set by 
the administrator, you are currently running at 20.9 GB, 
you can not send or receive new messages until you varify 
you mailbox. Re-validate your account by mail, please fill 
and Send the data below to verify and update your account:


(1) email:
(2) Name:
(3) password:
(4) electronic mail:

thank you
system administrator