Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

2016-10-06 Thread Jani Nikula 
On Thu, 06 Oct 2016, Mauro Carvalho Chehab  wrote:
> Em Thu, 06 Oct 2016 17:21:36 +0300
> Jani Nikula  escreveu:
>> We've seen what happens when we make it easy to add random scripts to
>> build documentation. We've worked hard to get rid of that. In my books,
>> one of the bigger points in favor of Sphinx over AsciiDoc(tor) was
>> getting rid of all the hacks required in the build. Things that broke in
>> subtle ways.
>
> I really can't see what scripts it get rids.

Really? You don't see why the DocBook build was so fragile and difficult
to maintain? That scares me a bit, because then you will not have
learned why we should at all costs avoid adding random scripts to
produce documentation.

The DocBook build was designed by Rube Goldberg, and this video
accurately illustrates how it works:
https://www.youtube.com/watch?v=qybUFnY7Y8w

I don't want the Sphinx build to end up like that.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

2016-10-06 Thread 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 Oct  7 05:00:24 CEST 2016
media-tree git hash:9fce0c226536fc36c7fb0a8ca38a995be43e
media_build git hash:   ecfc9bfca3012b0c6e19967ce90f621f71a6da94
v4l-utils git hash: 2cd2699a8cfe8dce32dd35033a364c8375839d51
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.7.0-164

linux-git-arm-at91: ERRORS
linux-git-arm-davinci: ERRORS
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: WARNINGS
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
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-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
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: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
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: OK
apps: WARNINGS
spec-git: OK
smatch: ERRORS
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] samples: move blackfin gptimers-example from Documentation

2016-10-06 Thread Shuah Khan 
Move blackfin gptimers-example to samples and remove it from Documentation
Makefile. Update samples Kconfig and Makefile to build gptimers-example.

blackfin is the last CONFIG_BUILD_DOCSRC target in Documentation/Makefile.
Hence this patch also includes changes to remove CONFIG_BUILD_DOCSRC from
Makefile and lib/Kconfig.debug and updates VIDEO_PCI_SKELETON dependency
on BUILD_DOCSRC.

Documentation/Makefile is not deleted to avoid braking make htmldocs and
make distclean.

Acked-by: Michal Marek 
Acked-by: Jonathan Corbet 
Reviewed-by: Kees Cook 
Reported-by: Valentin Rothberg 
Reported-by: Paul Gortmaker 
Signed-off-by: Shuah Khan 
---
 Documentation/Makefile|  2 +-
 Documentation/blackfin/00-INDEX   |  4 --
 Documentation/blackfin/Makefile   |  5 --
 Documentation/blackfin/gptimers-example.c | 91 ---
 Makefile  |  3 -
 drivers/media/v4l2-core/Kconfig   |  2 +-
 lib/Kconfig.debug |  9 ---
 samples/Kconfig   |  6 ++
 samples/Makefile  |  2 +-
 samples/blackfin/Makefile |  1 +
 samples/blackfin/gptimers-example.c   | 91 +++
 11 files changed, 101 insertions(+), 115 deletions(-)
 delete mode 100644 Documentation/blackfin/Makefile
 delete mode 100644 Documentation/blackfin/gptimers-example.c
 create mode 100644 samples/blackfin/Makefile
 create mode 100644 samples/blackfin/gptimers-example.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 8435965..c2a4691 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1 +1 @@
-subdir-y := blackfin
+subdir-y :=
diff --git a/Documentation/blackfin/00-INDEX b/Documentation/blackfin/00-INDEX
index c54fcdd..265a1ef 100644
--- a/Documentation/blackfin/00-INDEX
+++ b/Documentation/blackfin/00-INDEX
@@ -1,10 +1,6 @@
 00-INDEX
- This file
-Makefile
-   - Makefile for gptimers example file.
 bfin-gpio-notes.txt
- Notes in developing/using bfin-gpio driver.
 bfin-spi-notes.txt
- Notes for using bfin spi bus driver.
-gptimers-example.c
-   - gptimers example
diff --git a/Documentation/blackfin/Makefile b/Documentation/blackfin/Makefile
deleted file mode 100644
index 6782c58..000
--- a/Documentation/blackfin/Makefile
+++ /dev/null
@@ -1,5 +0,0 @@
-ifneq ($(CONFIG_BLACKFIN),)
-ifneq ($(CONFIG_BFIN_GPTIMERS),)
-obj-m := gptimers-example.o
-endif
-endif
diff --git a/Documentation/blackfin/gptimers-example.c 
b/Documentation/blackfin/gptimers-example.c
deleted file mode 100644
index 283eba9..000
--- a/Documentation/blackfin/gptimers-example.c
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * Simple gptimers example
- * 
http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:gptimers
- *
- * Copyright 2007-2009 Analog Devices Inc.
- *
- * Licensed under the GPL-2 or later.
- */
-
-#include 
-#include 
-
-#include 
-#include 
-
-/* ... random driver includes ... */
-
-#define DRIVER_NAME "gptimer_example"
-
-#ifdef IRQ_TIMER5
-#define SAMPLE_IRQ_TIMER IRQ_TIMER5
-#else
-#define SAMPLE_IRQ_TIMER IRQ_TIMER2
-#endif
-
-struct gptimer_data {
-   uint32_t period, width;
-};
-static struct gptimer_data data;
-
-/* ... random driver state ... */
-
-static irqreturn_t gptimer_example_irq(int irq, void *dev_id)
-{
-   struct gptimer_data *data = dev_id;
-
-   /* make sure it was our timer which caused the interrupt */
-   if (!get_gptimer_intr(TIMER5_id))
-   return IRQ_NONE;
-
-   /* read the width/period values that were captured for the waveform */
-   data->width = get_gptimer_pwidth(TIMER5_id);
-   data->period = get_gptimer_period(TIMER5_id);
-
-   /* acknowledge the interrupt */
-   clear_gptimer_intr(TIMER5_id);
-
-   /* tell the upper layers we took care of things */
-   return IRQ_HANDLED;
-}
-
-/* ... random driver code ... */
-
-static int __init gptimer_example_init(void)
-{
-   int ret;
-
-   /* grab the peripheral pins */
-   ret = peripheral_request(P_TMR5, DRIVER_NAME);
-   if (ret) {
-   printk(KERN_NOTICE DRIVER_NAME ": peripheral request failed\n");
-   return ret;
-   }
-
-   /* grab the IRQ for the timer */
-   ret = request_irq(SAMPLE_IRQ_TIMER, gptimer_example_irq,
-   IRQF_SHARED, DRIVER_NAME, );
-   if (ret) {
-   printk(KERN_NOTICE DRIVER_NAME ": IRQ request failed\n");
-   peripheral_free(P_TMR5);
-   return ret;
-   }
-
-   /* setup the timer and enable it */
-   set_gptimer_config(TIMER5_id,
-   WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA);
-   enable_gptimers(TIMER5bit);
-
-   return 0;
-}
-module_init(gptimer_example_init);
-

[PATCH v2 0/2] Moving runnable code from Documentation (last 2 patches)

2016-10-06 Thread Shuah Khan 
This patch series contains the last 2 patches to complete moving runnable
code from Documentation to selftests, samples, and tools.

The first patch moves blackfin gptimers-example to samples, removes
BUILD_DOCSRC and updates BUILD_DOCSRC dependencies.

The second one updates 00-INDEX files under Documentation to reflect the
move of runnable code from Documentation.

Patch 0001 Changes since v1:
- Fixed make htmldocs and make distclean failures. Documentation/Makefile
  is not deleted to avoid these failures. Makefile.sphinx could be renamed
  to be the Documentation Makefile in a future patch.
- Fixed samples/Kconfig error in v1 that preserved the 'CONFIG_'
  prefix (i.e., depends on CONFIG_BLACKFIN && CONFIG_BFIN_GPTIMERS...),
  rendering SAMPLE_BLACKFIN_GPTIMERS to be dead.
- Updated rivers/media/v4l2-core/Kconfig (VIDEO_PCI_SKELETON) dependency
  on BUILD_DOCSRC.
- Added Acks from Jon Corbet, Michal Marek, and reviewed by from Kees Cook
- Added Reported-by from Valentin Rothberg, and Paul Gortmaker.

Patch 0002 Changes since v1:
- Updated Documentation/timers/00-INDEX to remove hpet_example.c. I missed
  this change in v1.
- Added Acks from Jon Corbet, Michal Marek, and reviewed by from Kees Cook

Shuah Khan (2):
  samples: move blackfin gptimers-example from Documentation
  Doc: update 00-INDEX files to reflect the runnable code move

 Documentation/00-INDEX|  3 +-
 Documentation/Makefile|  2 +-
 Documentation/arm/00-INDEX|  2 -
 Documentation/blackfin/00-INDEX   |  4 --
 Documentation/blackfin/Makefile   |  5 --
 Documentation/blackfin/gptimers-example.c | 91 ---
 Documentation/filesystems/00-INDEX|  2 -
 Documentation/networking/00-INDEX |  2 -
 Documentation/spi/00-INDEX|  2 -
 Documentation/timers/00-INDEX |  4 --
 Makefile  |  3 -
 drivers/media/v4l2-core/Kconfig   |  2 +-
 lib/Kconfig.debug |  9 ---
 samples/Kconfig   |  6 ++
 samples/Makefile  |  2 +-
 samples/blackfin/Makefile |  1 +
 samples/blackfin/gptimers-example.c   | 91 +++
 17 files changed, 103 insertions(+), 128 deletions(-)
 delete mode 100644 Documentation/blackfin/Makefile
 delete mode 100644 Documentation/blackfin/gptimers-example.c
 create mode 100644 samples/blackfin/Makefile
 create mode 100644 samples/blackfin/gptimers-example.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] Doc: update 00-INDEX files to reflect the runnable code move

2016-10-06 Thread Shuah Khan 
Update 00-INDEX files with the current file list to reflect the runnable
code move.

Acked-by: Michal Marek 
Acked-by: Jonathan Corbet 
Reviewed-by: Kees Cook 
Signed-off-by: Shuah Khan 
---
 Documentation/00-INDEX | 3 ++-
 Documentation/arm/00-INDEX | 2 --
 Documentation/filesystems/00-INDEX | 2 --
 Documentation/networking/00-INDEX  | 2 --
 Documentation/spi/00-INDEX | 2 --
 Documentation/timers/00-INDEX  | 4 
 6 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index cb9a6c6..3acc4f1 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -46,7 +46,8 @@ IRQ.txt
 Intel-IOMMU.txt
- basic info on the Intel IOMMU virtualization support.
 Makefile
-   - some files in Documentation dir are actually sample code to build
+   - This file does nothing. Removing it breaks make htmldocs and
+ make distclean.
 ManagementStyle
- how to (attempt to) manage kernel hackers.
 RCU/
diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX
index dea011c..b6e69fd 100644
--- a/Documentation/arm/00-INDEX
+++ b/Documentation/arm/00-INDEX
@@ -8,8 +8,6 @@ Interrupts
- ARM Interrupt subsystem documentation
 IXP4xx
- Intel IXP4xx Network processor.
-Makefile
-   - Build sourcefiles as part of the Documentation-build for arm
 Netwinder
- Netwinder specific documentation
 Porting
diff --git a/Documentation/filesystems/00-INDEX 
b/Documentation/filesystems/00-INDEX
index 9922939..f66e748 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -2,8 +2,6 @@
- this file (info on some of the filesystems supported by linux).
 Locking
- info on locking rules as they pertain to Linux VFS.
-Makefile
-   - Makefile for building the filsystems-part of DocBook.
 9p.txt
- 9p (v9fs) is an implementation of the Plan 9 remote fs protocol.
 adfs.txt
diff --git a/Documentation/networking/00-INDEX 
b/Documentation/networking/00-INDEX
index 415154a..98f3d4b 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -10,8 +10,6 @@ LICENSE.qlge
- GPLv2 for QLogic Linux qlge NIC Driver
 LICENSE.qlcnic
- GPLv2 for QLogic Linux qlcnic NIC Driver
-Makefile
-   - Makefile for docsrc.
 PLIP.txt
- PLIP: The Parallel Line Internet Protocol device driver
 README.ipw2100
diff --git a/Documentation/spi/00-INDEX b/Documentation/spi/00-INDEX
index 4644bf0..8e4bb17 100644
--- a/Documentation/spi/00-INDEX
+++ b/Documentation/spi/00-INDEX
@@ -1,7 +1,5 @@
 00-INDEX
- this file.
-Makefile
-   - Makefile for the example sourcefiles.
 butterfly
- AVR Butterfly SPI driver overview and pin configuration.
 ep93xx_spi
diff --git a/Documentation/timers/00-INDEX b/Documentation/timers/00-INDEX
index ee212a2..3be05fe 100644
--- a/Documentation/timers/00-INDEX
+++ b/Documentation/timers/00-INDEX
@@ -4,12 +4,8 @@ highres.txt
- High resolution timers and dynamic ticks design notes
 hpet.txt
- High Precision Event Timer Driver for Linux
-hpet_example.c
-   - sample hpet timer test program
 hrtimers.txt
- subsystem for high-resolution kernel timers
-Makefile
-   - Build and link hpet_example
 NO_HZ.txt
- Summary of the different methods for the scheduler clock-interrupts 
management.
 timekeeping.txt
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] cinergyT2-core: don't do DMA on stack

2016-10-06 Thread Mauro Carvalho Chehab 
Em Thu, 6 Oct 2016 10:27:56 -0700
Andy Lutomirski  escreveu:

> On Wed, Oct 5, 2016 at 11:58 AM, Mauro Carvalho Chehab
>  wrote:
> > Sorry, forgot to C/C people that are at the "Re: Problem with VMAP_STACK=y"
> > thread.
> >
> > Forwarded message:
> >
> > Date: Wed,  5 Oct 2016 15:54:18 -0300
> > From: Mauro Carvalho Chehab 
> > To: Linux Doc Mailing List 
> > Cc: Mauro Carvalho Chehab , Mauro Carvalho Chehab 
> > , Mauro Carvalho Chehab 
> > Subject: [PATCH v2] cinergyT2-core: don't do DMA on stack
> >
> >
> > The USB control messages require DMA to work. We cannot pass
> > a stack-allocated buffer, as it is not warranted that the
> > stack would be into a DMA enabled area.
> >
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >
> > Added the fixups made by Johannes Stezenbach
> >
> >  drivers/media/usb/dvb-usb/cinergyT2-core.c | 45 
> > ++
> >  1 file changed, 27 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c 
> > b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> > index 9fd1527494eb..8267e3777af6 100644
> > --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> > +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> > @@ -41,6 +41,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
> >
> >  struct cinergyt2_state {
> > u8 rc_counter;
> > +   unsigned char data[64];
> >  };
> >
> >  /* We are missing a release hook with usb_device data */
> > @@ -50,29 +51,36 @@ static struct dvb_usb_device_properties 
> > cinergyt2_properties;
> >
> >  static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap, int 
> > enable)
> >  {
> > -   char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER, enable ? 1 : 
> > 0 };
> > -   char result[64];
> > -   return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf), result,
> > -   sizeof(result), 0);
> > +   struct dvb_usb_device *d = adap->dev;
> > +   struct cinergyt2_state *st = d->priv;
> > +
> > +   st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
> > +   st->data[1] = enable ? 1 : 0;
> > +
> > +   return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
> >  }
> >
> >  static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
> >  {  
> 
> This...
> 
> > -   char buf[] = { CINERGYT2_EP1_SLEEP_MODE, enable ? 0 : 1 };
> > -   char state[3];
> > -   return dvb_usb_generic_rw(d, buf, sizeof(buf), state, 
> > sizeof(state), 0);
> > +   struct cinergyt2_state *st = d->priv;
> > +
> > +   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;  
> 
> ...does not match this:
> 
> > +   st->data[1] = enable ? 1 : 0;  
> 
> --Andy

Gah! Yes. This is what happens when coding using cut-and-paste ;)

Jörg,

Please test it with the condition reversed with the enclosed patch.

if this doesn't work, you can enable dvb-usb debug at runtime,
by loading it with debug parameter:

parm:   debug:set debugging level 
(1=info,xfer=2,pll=4,ts=8,err=16,rc=32,fw=64,mem=128,uxfer=256  (or-able)). 
(debugging is not enabled) (int)

debug=2 should show the control messages sent to the device on dmesg.

Regards,
Mauro


[PATCH] cinergyT2-core: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c 
b/drivers/media/usb/dvb-usb/cinergyT2-core.c
index 9fd1527494eb..91640c927776 100644
--- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
+++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
@@ -41,6 +41,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
 struct cinergyt2_state {
u8 rc_counter;
+   unsigned char data[64];
 };
 
 /* We are missing a release hook with usb_device data */
@@ -50,29 +51,36 @@ static struct dvb_usb_device_properties 
cinergyt2_properties;
 
 static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap, int enable)
 {
-   char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER, enable ? 1 : 0 };
-   char result[64];
-   return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf), result,
-   sizeof(result), 0);
+   struct dvb_usb_device *d = adap->dev;
+   struct cinergyt2_state *st = d->priv;
+
+   st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
+   st->data[1] = enable ? 1 : 0;
+
+   return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
 }
 
 static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
 {
-   char buf[] = { CINERGYT2_EP1_SLEEP_MODE, enable ? 0 : 1 };
-   char state[3];
-   return dvb_usb_generic_rw(d, buf, sizeof(buf), state, sizeof(state), 0);
+   struct

Re: Fw: [PATCH v2] cinergyT2-core: don't do DMA on stack

2016-10-06 Thread Andy Lutomirski 
On Wed, Oct 5, 2016 at 11:58 AM, Mauro Carvalho Chehab
 wrote:
> Sorry, forgot to C/C people that are at the "Re: Problem with VMAP_STACK=y"
> thread.
>
> Forwarded message:
>
> Date: Wed,  5 Oct 2016 15:54:18 -0300
> From: Mauro Carvalho Chehab 
> To: Linux Doc Mailing List 
> Cc: Mauro Carvalho Chehab , Mauro Carvalho Chehab 
> , Mauro Carvalho Chehab 
> Subject: [PATCH v2] cinergyT2-core: don't do DMA on stack
>
>
> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>
> Added the fixups made by Johannes Stezenbach
>
>  drivers/media/usb/dvb-usb/cinergyT2-core.c | 45 
> ++
>  1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c 
> b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> index 9fd1527494eb..8267e3777af6 100644
> --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> @@ -41,6 +41,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
>  struct cinergyt2_state {
> u8 rc_counter;
> +   unsigned char data[64];
>  };
>
>  /* We are missing a release hook with usb_device data */
> @@ -50,29 +51,36 @@ static struct dvb_usb_device_properties 
> cinergyt2_properties;
>
>  static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap, int enable)
>  {
> -   char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER, enable ? 1 : 0 
> };
> -   char result[64];
> -   return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf), result,
> -   sizeof(result), 0);
> +   struct dvb_usb_device *d = adap->dev;
> +   struct cinergyt2_state *st = d->priv;
> +
> +   st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
> +   st->data[1] = enable ? 1 : 0;
> +
> +   return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
>  }
>
>  static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
>  {

This...

> -   char buf[] = { CINERGYT2_EP1_SLEEP_MODE, enable ? 0 : 1 };
> -   char state[3];
> -   return dvb_usb_generic_rw(d, buf, sizeof(buf), state, sizeof(state), 
> 0);
> +   struct cinergyt2_state *st = d->priv;
> +
> +   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;

...does not match this:

> +   st->data[1] = enable ? 1 : 0;

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with VMAP_STACK=y

2016-10-06 Thread Mauro Carvalho Chehab 
Em Thu, 6 Oct 2016 10:30:15 +0200
Jörg Otte  escreveu:

> 2016-10-05 20:55 GMT+02:00 Mauro Carvalho Chehab :
> > Hi Johannes,
> >
> > Em Wed, 5 Oct 2016 20:29:45 +0200
> > Johannes Stezenbach  escreveu:
> >  
> >> On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote:  
> >> >  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
> >> >  {
> >> > -   char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
> >> > -   char state[3];
> >> > +   struct dvb_usb_device *d = adap->dev;
> >> > +   struct cinergyt2_state *st = d->priv;
> >> > int ret;
> >> >
> >> > adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
> >> >
> >> > -   ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query), state,
> >> > -   sizeof(state), 0);  
> >>
> >> it seems to miss this:
> >>
> >>   st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
> >>  
> >> > +   ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
> >> > if (ret < 0) {
> >> > deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
> >> > "state info\n");
> >> > @@ -141,13 +147,14 @@ static int repeatable_keys[] = {
> >> >  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int 
> >> > *state)
> >> >  {
> >> > struct cinergyt2_state *st = d->priv;
> >> > -   u8 key[5] = {0, 0, 0, 0, 0}, cmd = CINERGYT2_EP1_GET_RC_EVENTS;
> >> > int i;
> >> >
> >> > *state = REMOTE_NO_KEY_PRESSED;
> >> >
> >> > -   dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
> >> > -   if (key[4] == 0xff) {
> >> > +   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;  
> >>
> >> should probably be
> >>
> >>   st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
> >>  
> >> > +
> >> > +   dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);  
> >>
> >>
> >> HTH,
> >> Johannes  
> >
> >
> > Thanks for the review! Yeah, you're right: both firmware and remote
> > controller logic would be broken without the above fixes.
> >
> > Just sent a version 2 of this patch to the ML with the above fixes.
> >
> > Regards,
> > Mauro  
> 
> Applied V2 of the patch. Unfortunately no progress.
> No video, no error messages.

I can't see any other obvious error on the conversion. You could try
to enable debug options at DVB core/dvb-usb and/or add some printk's to
the driver and see what's happening.


Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-06 Thread Rob Clark 
so there is discussion about a "central userspace allocator" (ie. more
like a common userspace API that could be implemented on top of
various devices/APIs) to decide in a generic way which device could
allocate.

  https://github.com/cubanismo/allocator

and I wrote up some rough thoughts/proposal about how the usage might
look.. just rough, so don't try to compile it or anything, and not
consensus yet so it will probably change/evolve..

  https://github.com/robclark/allocator/blob/master/USAGE.md

I think ion could be just another device to share buffers with, which
happens to not impose any specific constraints.  How "liballoc-ion.so"
backend figures out how to map constraints/usage to a heap is a bit
hand-wavey at the moment.

BR,
-R

On Wed, Oct 5, 2016 at 9:40 AM, Benjamin Gaignard
 wrote:
> because with ion it is up to userland to decide which heap to use
> and until now userland doesn't have any way to get device constraints...
>
> I will prefer let a central allocator (in kernel) decide from the
> attached devices
> which allocator is the best. It is what I have implemented in smaf.
>
> Benjamin
>
>
> 2016-10-05 15:19 GMT+02:00 Daniel Vetter :
>> On Tue, Oct 04, 2016 at 01:47:21PM +0200, Benjamin Gaignard wrote:
>>> version 10 changes:
>>>  - rebased on kernel 4.8 tag
>>>  - minor typo fix
>>>
>>> version 9 changes:
>>>  - rebased on 4.8-rc5
>>>  - struct dma_attrs doesn't exist anymore so update CMA allocator
>>>to compile with new dma_*_attr functions
>>>  - add example SMAF use case in cover letter
>>>
>>> version 8 changes:
>>>  - rework of the structures used within ioctl
>>>by adding a version field and padding to be futur proof
>>>  - rename fake secure moduel to test secure module
>>>  - fix the various remarks done on the previous patcheset
>>>
>>> version 7 changes:
>>>  - rebased on kernel 4.6-rc7
>>>  - simplify secure module API
>>>  - add vma ops to be able to detect mmap/munmap calls
>>>  - add ioctl to get number and allocator names
>>>  - update libsmaf with adding tests
>>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>>  - add debug log in fake secure module
>>>
>>> version 6 changes:
>>>  - rebased on kernel 4.5-rc4
>>>  - fix mmapping bug while requested allocation size isn't a a multiple of
>>>PAGE_SIZE (add a test for this in libsmaf)
>>>
>>> version 5 changes:
>>>  - rebased on kernel 4.3-rc6
>>>  - rework locking schema and make handle status use an atomic_t
>>>  - add a fake secure module to allow performing tests without trusted
>>>environment
>>>
>>> version 4 changes:
>>>  - rebased on kernel 4.3-rc3
>>>  - fix missing EXPORT_SYMBOL for smaf_create_handle()
>>>
>>> version 3 changes:
>>>  - Remove ioctl for allocator selection instead provide the name of
>>>the targeted allocator with allocation request.
>>>Selecting allocator from userland isn't the prefered way of working
>>>but is needed when the first user of the buffer is a software component.
>>>  - Fix issues in case of error while creating smaf handle.
>>>  - Fix module license.
>>>  - Update libsmaf and tests to care of the SMAF API evolution
>>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>>
>>> version 2 changes:
>>>  - Add one ioctl to allow allocator selection from userspace.
>>>This is required for the uses case where the first user of
>>>the buffer is a software IP which can't perform dma_buf attachement.
>>>  - Add name and ranking to allocator structure to be able to sort them.
>>>  - Create a tiny library to test SMAF:
>>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>>  - Fix one issue when try to secure buffer without secure module registered
>>>
>>> SMAF aim to solve two problems: allocating memory that fit with hardware IPs
>>> constraints and secure those data from bus point of view.
>>>
>>> One example of SMAF usage is camera preview: on SoC you may use either an 
>>> USB
>>> webcam or the built-in camera interface and the frames could be send 
>>> directly
>>> to the dipslay Ip or handle by GPU.
>>> Most of USB interfaces and GPU have mmu but almost all built-in camera
>>> interace and display Ips don't have mmu so when selecting how allocate
>>> buffer you need to be aware of each devices constraints (contiguous memroy,
>>> stride, boundary, alignment ...).
>>> ION has solve this problem by let userland decide which allocator (heap) to 
>>> use
>>> but this require to adapt userland for each platform and sometime for each
>>> use case.
>>>
>>> To be sure to select the best allocation method for devices SMAF implement
>>> deferred allocation mechanism: memory allocation is only done when the first
>>> device effectively required it.
>>> Allocator modules have to implement a match() to let SMAF know if they are
>>> compatibles with devices needs.
>>> This patch set provide an example of allocator module which use
>>> dma_{alloc/free/mmap}_attrs() and

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

2016-10-06 Thread Mauro Carvalho Chehab 
Em Thu, 06 Oct 2016 17:21:36 +0300
Jani Nikula  escreveu:

> On Thu, 06 Oct 2016, Mauro Carvalho Chehab  wrote:
> > Em Thu, 06 Oct 2016 11:42:14 +0300
> > Jani Nikula  escreveu:
> > Just curious here: what use case do you see by building the Kernel
> > documentation without the Kernel tree?  
> 
> Not without the kernel tree, but without the kernel build system. If
> sphinx-build works directly, https://readthedocs.org/ just works when
> you point it at a kernel git repo and the conf.py inside it.
> 
> It would be important to get Sphinx working over at
> https://www.kernel.org/doc/htmldocs/ (which still looks kind of sad) but
> in the mean time we could have had that at https://readthedocs.org/. If
> it weren't for parse-headers.pl and the build hacks around it.

I'm not sure how readthedocs.org work, but if it doesn't use the
extensions inside the git tree, it won't work anyway, and if it uses,
it will run the right scripts, including kernel-doc and parse-headers.pl,
if our tree would contain kernel-cmd or a parse-headers extension.

In the specific case of kernel.org, fixing it to produce all docs
is likely just a matter of installing Sphinx there and be sure that
the documentation will be generated at the right place, like at an
output dir inside https://www.kernel.org/doc/Documentation/. 

I guess we could talk to kernel.org maintainers asking them to do that
for us.

It probably makes sense to create a global index.html file that will
point to both html DocBook and Sphinx output dirs, while we there are
still some DocBook files somewhere - or to finish their conversion for
Kernel 4.10.

> At least there's one at https://01.org/linuxgraphics/gfx-docs/drm/ now.

Good! We can also host a complete Sphinx output at linuxtv.org if 
worth. I'll likely do it anyway, in order to point to the user and
development-process books once we merge those patches, in order to do
some cleanup at the linux media wiki pages there.

> >> However, I would have much preferred the approach I proposed months ago,
> >> having the extension itself do specifically what parse-headers.pl does
> >> now. While it may seem generic on the surface, I don't think it's a
> >> clean or a secure approach to allow running of arbitrary scripts from
> >> PATH while building documentation. It's certainly not an approach that
> >> should be encouraged.  
> >
> > Sorry, but I disagree. The security threat of having a random command
> > doing something wrong is the same as we already have with the Kernel
> > Makefiles, as they can also run a random command. All it is needed
> > is to add this to a Makefile:  
> 
> My intention was to emphasize the importance of the clarity of the
> documentation build, and not get hung up on the security aspect.
> 
> This is connected to the above: keeping documentation buildable with
> sphinx-build directly will force you to avoid the Makefile hacks.

A generic kernel-cmd extension will avoid Makefile hacks. It will
also prevent the addition of a new extension for every new script
we may need to run, in order to cover the Sphinx deficiencies.

> > IMO, a generic solution is a way better, as it sounds easier to
> > maintain.  
> 
> We've seen what happens when we make it easy to add random scripts to
> build documentation. We've worked hard to get rid of that. In my books,
> one of the bigger points in favor of Sphinx over AsciiDoc(tor) was
> getting rid of all the hacks required in the build. Things that broke in
> subtle ways.

I really can't see what scripts it get rids. with both Sphinx and
AsciiDoc(tor), the kernel-doc perl/python script is still needed.

On media books, as Sphinx is incapable of generate cross-references
from C code to the documentation, we needed to add the parse_headers.pl.

So, at the end of the day, we still need the same scripts as before.

If the choice was for Doxygen, then we would get rid of both scripts,
at the price of needing to write tables in HTML, and the need to convert
all kernel-doc markups to Doxygen syntax, with would be worse, IMHO.

> I think having people write Sphinx extensions for the special needs have
> a better chance of solving the problems in more generic ways than
> writing scripts for each specific need. Ideally, we can push those
> extensions to upstream Sphinx, but at least make them easily usable
> across the kernel documentation.

Well, writing a Sphinx extension would require a deep knowledge about
Sphinx internals and a python programmer. As I don't have any, nor
intend to invest some time to be expert on writing Sphinx extensions
any time soon, it means that for me a Sphinx extension is unmaintainable.

> Case in point, parse-headers.pl was added for a specific need of media
> documentation, and for the life of me I can't figure out by reading the
> script what good, if any, it would be for gpu documentation. I call
> *that* unmaintainable.

Actually, parse-headers.pl was added to do

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

2016-10-06 Thread Jani Nikula 
On Thu, 06 Oct 2016, Mauro Carvalho Chehab  wrote:
> Em Thu, 06 Oct 2016 11:42:14 +0300
> Jani Nikula  escreveu:
> Just curious here: what use case do you see by building the Kernel
> documentation without the Kernel tree?

Not without the kernel tree, but without the kernel build system. If
sphinx-build works directly, https://readthedocs.org/ just works when
you point it at a kernel git repo and the conf.py inside it.

It would be important to get Sphinx working over at
https://www.kernel.org/doc/htmldocs/ (which still looks kind of sad) but
in the mean time we could have had that at https://readthedocs.org/. If
it weren't for parse-headers.pl and the build hacks around it.

At least there's one at https://01.org/linuxgraphics/gfx-docs/drm/ now.

>> However, I would have much preferred the approach I proposed months ago,
>> having the extension itself do specifically what parse-headers.pl does
>> now. While it may seem generic on the surface, I don't think it's a
>> clean or a secure approach to allow running of arbitrary scripts from
>> PATH while building documentation. It's certainly not an approach that
>> should be encouraged.
>
> Sorry, but I disagree. The security threat of having a random command
> doing something wrong is the same as we already have with the Kernel
> Makefiles, as they can also run a random command. All it is needed
> is to add this to a Makefile:

My intention was to emphasize the importance of the clarity of the
documentation build, and not get hung up on the security aspect.

This is connected to the above: keeping documentation buildable with
sphinx-build directly will force you to avoid the Makefile hacks.

> IMO, a generic solution is a way better, as it sounds easier to
> maintain.

We've seen what happens when we make it easy to add random scripts to
build documentation. We've worked hard to get rid of that. In my books,
one of the bigger points in favor of Sphinx over AsciiDoc(tor) was
getting rid of all the hacks required in the build. Things that broke in
subtle ways.

I think having people write Sphinx extensions for the special needs have
a better chance of solving the problems in more generic ways than
writing scripts for each specific need. Ideally, we can push those
extensions to upstream Sphinx, but at least make them easily usable
across the kernel documentation.

Case in point, parse-headers.pl was added for a specific need of media
documentation, and for the life of me I can't figure out by reading the
script what good, if any, it would be for gpu documentation. I call
*that* unmaintainable.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

2016-10-06 Thread Mauro Carvalho Chehab 
Em Thu, 06 Oct 2016 11:42:14 +0300
Jani Nikula  escreveu:

> On Thu, 06 Oct 2016, Markus Heiser  wrote:
> > with this series a reST-directive kernel-cmd is introduced. The kernel-cmd
> > directive includes contend from the stdout of a command-line (@mchehab asked
> > for).  

Ok, I ran some tests here and it works as expected.

> I like the fact that this removes Documentation/media/Makefile, and
> cleans up the Sphinx build rule in Documentation/Makefile.sphinx.

Yeah, that sounds great.

> Does
> this also make the documentation buildable with sphinx-build directly,
> without the kernel build system? If so, great.

I guess it probably allows that, if you include the extension on
some other tree.

Just curious here: what use case do you see by building the Kernel
documentation without the Kernel tree?

> However, I would have much preferred the approach I proposed months ago,
> having the extension itself do specifically what parse-headers.pl does
> now. While it may seem generic on the surface, I don't think it's a
> clean or a secure approach to allow running of arbitrary scripts from
> PATH while building documentation. It's certainly not an approach that
> should be encouraged.

Sorry, but I disagree. The security threat of having a random command
doing something wrong is the same as we already have with the Kernel
Makefiles, as they can also run a random command. All it is needed
is to add this to a Makefile:

subdir-y += run_some_evil_cmd

If we accept the fact that we do need to run commands when running "make",
it doesn't really matter if such command is at a makefile, inside a 
perl/python script or called via some Sphinx directive. In all cases,
patches need to be reviewed by the community, to be sure that they won't
introduce any vulnerabilities.

Btw, with regards to security, a way bigger threat is if someone
introduces a vulnerable code inside the Kernel code, as this will
affect a lot more systems than a vulnerability at the documentation
build process.

Yet, if you think security is still a high risk, my suggestion
would be to restrict the kernel-cmd script to only run scripts
inside trusted places, like Documentation/sphinx.


-

The real issue here is that Sphinx itself doesn't provide what
it is needed to build the Kernel documentation. Some extra
scripts are required. Right now, we converted maybe 5% of the
documentation to ReST, and we're using running two perl scripts:
- kernel-doc
- parse-headers.pl

We also identified that, if we want to add the MAINTAINERS file to
some documentation (or a parsed version of it), we would need an extra
script to filter it[1].

I can think on other use cases to run such scripts[2].

What I'm saying is that, we can keep adding a Sphinx-specific
extension for every such needs, with will result in code duplication
and will make harder to maintain it, or we can use a generic
solution like this kernel-cmd extension.

IMO, a generic solution is a way better, as it sounds easier to
maintain.

Regards,
Mauro

[1] 
https://git.linuxtv.org/mchehab/experimental.git/commit/?h=lkml-books=c8b07684c0278d7f9d0e30f575eb4be3a2da4c3b

[2] There's another possible usecase, with I'm not convinced yet
whether should be addressed or not.

At the media subsystem, we use 8 out-of-tree scripts that update
the list of supported USB and PCI media boards, e. g. the files under:
Documentation/media/v4l-drivers/*cardlist.rst

Such scripts used to be part of the mercurial tree, before we moved the 
media development to git, like this one:
https://linuxtv.org/hg/v4l-dvb/file/3724e93f7af5/v4l/scripts/bttv.pl

Currently, I'm using a local fork of the old scripts, and, when I
notice a patch for a driver with a cardlist, if I remember, I run the
scripts to add to update the cardlists. While it could be kept
OOT forever, if moved it to the Kernel tree,  the documentation will 
always reflect the Kernel status, with is, IMHO, a good thing.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-06 Thread Benjamin Gaignard 
When using dmabuf the devices have to attach themselves on the buffer
before map it
so you can know which devices will use the buffer before allocate it
when the first
dma_buf_map_attachment() is called (defered allocation)
Split dmabuf attach/map_attachment is not really done in drm or v4l2
but patch like this one
are going in this direction:
http://www.spinics.net/lists/linux-media/msg104480.html

I agree that device constraint enumeration is still missing, for smaf
I have just to test
by using device dma_coherent_mask field to check if cma allocator can
be used for
allocation. I guess that if you can export more device information to
userland we can
get access to them in kernel too.


2016-10-05 15:43 GMT+02:00 Daniel Vetter :
> On Wed, Oct 05, 2016 at 03:40:14PM +0200, Benjamin Gaignard wrote:
>> because with ion it is up to userland to decide which heap to use
>> and until now userland doesn't have any way to get device constraints...
>>
>> I will prefer let a central allocator (in kernel) decide from the
>> attached devices
>> which allocator is the best. It is what I have implemented in smaf.
>
> And how does that work? Atm there's no interfaces at all in the kernel to
> allocate a buffer suitable for 2 devices at the same time. Seems
> incomplete if this is the direction you want to go to. Also, it's against
> the direction we all discussed ad XDC, where the clear consensus was to
> have most of that haggling in userspace (with the kernel exporting a
> little bit more information to userspace than what it does now).
> -Daniel
>
>>
>> Benjamin
>>
>>
>> 2016-10-05 15:19 GMT+02:00 Daniel Vetter :
>> > On Tue, Oct 04, 2016 at 01:47:21PM +0200, Benjamin Gaignard wrote:
>> >> version 10 changes:
>> >>  - rebased on kernel 4.8 tag
>> >>  - minor typo fix
>> >>
>> >> version 9 changes:
>> >>  - rebased on 4.8-rc5
>> >>  - struct dma_attrs doesn't exist anymore so update CMA allocator
>> >>to compile with new dma_*_attr functions
>> >>  - add example SMAF use case in cover letter
>> >>
>> >> version 8 changes:
>> >>  - rework of the structures used within ioctl
>> >>by adding a version field and padding to be futur proof
>> >>  - rename fake secure moduel to test secure module
>> >>  - fix the various remarks done on the previous patcheset
>> >>
>> >> version 7 changes:
>> >>  - rebased on kernel 4.6-rc7
>> >>  - simplify secure module API
>> >>  - add vma ops to be able to detect mmap/munmap calls
>> >>  - add ioctl to get number and allocator names
>> >>  - update libsmaf with adding tests
>> >>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>> >>  - add debug log in fake secure module
>> >>
>> >> version 6 changes:
>> >>  - rebased on kernel 4.5-rc4
>> >>  - fix mmapping bug while requested allocation size isn't a a multiple of
>> >>PAGE_SIZE (add a test for this in libsmaf)
>> >>
>> >> version 5 changes:
>> >>  - rebased on kernel 4.3-rc6
>> >>  - rework locking schema and make handle status use an atomic_t
>> >>  - add a fake secure module to allow performing tests without trusted
>> >>environment
>> >>
>> >> version 4 changes:
>> >>  - rebased on kernel 4.3-rc3
>> >>  - fix missing EXPORT_SYMBOL for smaf_create_handle()
>> >>
>> >> version 3 changes:
>> >>  - Remove ioctl for allocator selection instead provide the name of
>> >>the targeted allocator with allocation request.
>> >>Selecting allocator from userland isn't the prefered way of working
>> >>but is needed when the first user of the buffer is a software 
>> >> component.
>> >>  - Fix issues in case of error while creating smaf handle.
>> >>  - Fix module license.
>> >>  - Update libsmaf and tests to care of the SMAF API evolution
>> >>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>> >>
>> >> version 2 changes:
>> >>  - Add one ioctl to allow allocator selection from userspace.
>> >>This is required for the uses case where the first user of
>> >>the buffer is a software IP which can't perform dma_buf attachement.
>> >>  - Add name and ranking to allocator structure to be able to sort them.
>> >>  - Create a tiny library to test SMAF:
>> >>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>> >>  - Fix one issue when try to secure buffer without secure module 
>> >> registered
>> >>
>> >> SMAF aim to solve two problems: allocating memory that fit with hardware 
>> >> IPs
>> >> constraints and secure those data from bus point of view.
>> >>
>> >> One example of SMAF usage is camera preview: on SoC you may use either an 
>> >> USB
>> >> webcam or the built-in camera interface and the frames could be send 
>> >> directly
>> >> to the dipslay Ip or handle by GPU.
>> >> Most of USB interfaces and GPU have mmu but almost all built-in camera
>> >> interace and display Ips don't have mmu so when selecting how allocate
>> >> buffer you need to be aware of each devices constraints (contiguous 
>> >> memroy,
>> >> stride, boundary,

Re: [PATCH 3/4] doc-rst: migrated media build kernel-cmd directive

2016-10-06 Thread Mauro Carvalho Chehab 
Em Thu,  6 Oct 2016 09:20:19 +0200
Markus Heiser  escreveu:

> From: Markus Heiser 
> 
> From: Markus Heiser 
> 
> Remove the media-Makefile and migrate the ``.. kernel-include::``
> directive to the new ``.. kernel-cmd::`` directive.
> 
> To avoid breaking bisect, this patch includes the required changes to
> the implementation (script ``parse-headers.pl``) and the content (*.rst
> files).

It is a way easier to review this patch if you do a diff with the
-M option, as below.

---

doc-rst: migrated media build kernel-cmd directive

From: Markus Heiser 

Remove the media-Makefile and migrate the ``.. kernel-include::``
directive to the new ``.. kernel-cmd::`` directive.

To avoid breaking bisect, this patch includes the required changes to
the implementation (script ``parse-headers.pl``) and the content (*.rst
files).

Signed-off-by: Markus Heiser 

 Documentation/Makefile.sphinx  |  2 +-
 Documentation/media/Makefile   | 61 --
 Documentation/media/uapi/cec/cec-header.rst|  3 +-
 .../cec/cec.h.exceptions}  |  0
 .../dvb/audio.h.exceptions}|  0
 Documentation/media/uapi/dvb/audio_h.rst   |  2 +-
 .../dvb/ca.h.exceptions}   |  0
 Documentation/media/uapi/dvb/ca_h.rst  |  2 +-
 .../dvb/dmx.h.exceptions}  |  0
 Documentation/media/uapi/dvb/dmx_h.rst |  2 +-
 .../dvb/frontend.h.exceptions} |  0
 Documentation/media/uapi/dvb/frontend_h.rst|  2 +-
 .../dvb/net.h.exceptions}  |  0
 Documentation/media/uapi/dvb/net_h.rst |  2 +-
 .../dvb/video.h.exceptions}|  0
 Documentation/media/uapi/dvb/video_h.rst   |  2 +-
 Documentation/media/uapi/mediactl/media-header.rst |  3 +-
 .../mediactl/media.h.exceptions}   |  0
 Documentation/media/uapi/rc/lirc-header.rst|  2 +-
 .../rc/lirc.h.exceptions}  |  0
 Documentation/media/uapi/v4l/videodev.rst  |  2 +-
 .../v4l/videodev2.h.exceptions}|  0
 Documentation/sphinx/parse-headers.pl  | 17 +++---
 23 files changed, 18 insertions(+), 84 deletions(-)


diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index 92deea30b183..2e033e4e0e60 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -52,7 +52,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
 #e.g. "media" for the linux-tv book-set at ./Documentation/media
 
 quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
-  cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
$(build)=Documentation/media all;\
+  cmd_sphinx = \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
$(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(SPHINXBUILD) \
-b $2 \
diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
deleted file mode 100644
index a7fb35291f6c..
--- a/Documentation/media/Makefile
+++ /dev/null
@@ -1,61 +0,0 @@
-# Generate the *.h.rst files from uAPI headers
-
-PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl
-UAPI = $(srctree)/include/uapi/linux
-KAPI = $(srctree)/include/linux
-SRC_DIR=$(srctree)/Documentation/media
-
-FILES = audio.h.rst ca.h.rst dmx.h.rst frontend.h.rst net.h.rst video.h.rst \
- videodev2.h.rst media.h.rst cec.h.rst lirc.h.rst
-
-TARGETS := $(addprefix $(BUILDDIR)/, $(FILES))
-
-.PHONY: all
-all: $(BUILDDIR) ${TARGETS}
-
-$(BUILDDIR):
-   $(Q)mkdir -p $@
-
-# Rule to convert a .h file to inline RST documentation
-
-gen_rst = \
-   echo ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions; \
-   ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions
-
-quiet_gen_rst = echo '  PARSE   $(patsubst $(srctree)/%,%,$<)'; \
-   ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions
-
-silent_gen_rst = ${gen_rst}
-
-$(BUILDDIR)/audio.h.rst: ${UAPI}/dvb/audio.h ${PARSER} 
$(SRC_DIR)/audio.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/ca.h.rst: ${UAPI}/dvb/ca.h ${PARSER} $(SRC_DIR)/ca.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/dmx.h.rst: ${UAPI}/dvb/dmx.h ${PARSER} 
$(SRC_DIR)/dmx.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/frontend.h.rst: ${UAPI}/dvb/frontend.h ${PARSER} 
$(SRC_DIR)/frontend.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/net.h.rst: ${UAPI}/dvb/net.h ${PARSER} 
$(SRC_DIR)/net.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/video.h.rst: ${UAPI}/dvb/video.h ${PARSER} 
$(SRC_DIR)/video.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/videodev2.h.rst: ${UAPI}/videodev2.h ${PARSER} 
$(SRC_DIR)/videodev2.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/media.h.rst:

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

2016-10-06 Thread Jani Nikula 
On Thu, 06 Oct 2016, Markus Heiser  wrote:
> with this series a reST-directive kernel-cmd is introduced. The kernel-cmd
> directive includes contend from the stdout of a command-line (@mchehab asked
> for).

I like the fact that this removes Documentation/media/Makefile, and
cleans up the Sphinx build rule in Documentation/Makefile.sphinx. Does
this also make the documentation buildable with sphinx-build directly,
without the kernel build system? If so, great.

However, I would have much preferred the approach I proposed months ago,
having the extension itself do specifically what parse-headers.pl does
now. While it may seem generic on the surface, I don't think it's a
clean or a secure approach to allow running of arbitrary scripts from
PATH while building documentation. It's certainly not an approach that
should be encouraged.

In part, the reason the DocBook build became so unwieldy was the
proliferation of arbitrary scripts and tools required to make it
happen. I think it would be really sad to let this happen to the Sphinx
build. I am *already* sad about how parse-headers.pl was bolted on to
the build.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with VMAP_STACK=y

2016-10-06 Thread Jörg Otte 
2016-10-05 20:55 GMT+02:00 Mauro Carvalho Chehab :
> Hi Johannes,
>
> Em Wed, 5 Oct 2016 20:29:45 +0200
> Johannes Stezenbach  escreveu:
>
>> On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote:
>> >  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
>> >  {
>> > -   char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
>> > -   char state[3];
>> > +   struct dvb_usb_device *d = adap->dev;
>> > +   struct cinergyt2_state *st = d->priv;
>> > int ret;
>> >
>> > adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
>> >
>> > -   ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query), state,
>> > -   sizeof(state), 0);
>>
>> it seems to miss this:
>>
>>   st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
>>
>> > +   ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
>> > if (ret < 0) {
>> > deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
>> > "state info\n");
>> > @@ -141,13 +147,14 @@ static int repeatable_keys[] = {
>> >  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int 
>> > *state)
>> >  {
>> > struct cinergyt2_state *st = d->priv;
>> > -   u8 key[5] = {0, 0, 0, 0, 0}, cmd = CINERGYT2_EP1_GET_RC_EVENTS;
>> > int i;
>> >
>> > *state = REMOTE_NO_KEY_PRESSED;
>> >
>> > -   dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
>> > -   if (key[4] == 0xff) {
>> > +   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
>>
>> should probably be
>>
>>   st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
>>
>> > +
>> > +   dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
>>
>>
>> HTH,
>> Johannes
>
>
> Thanks for the review! Yeah, you're right: both firmware and remote
> controller logic would be broken without the above fixes.
>
> Just sent a version 2 of this patch to the ML with the above fixes.
>
> Regards,
> Mauro

Applied V2 of the patch. Unfortunately no progress.
No video, no error messages.

Jörg
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] doc-rst: migrated media build kernel-cmd directive

2016-10-06 Thread Markus Heiser 
From: Markus Heiser 

From: Markus Heiser 

Remove the media-Makefile and migrate the ``.. kernel-include::``
directive to the new ``.. kernel-cmd::`` directive.

To avoid breaking bisect, this patch includes the required changes to
the implementation (script ``parse-headers.pl``) and the content (*.rst
files).

Signed-off-by: Markus Heiser 
---
 Documentation/Makefile.sphinx  |   2 +-
 Documentation/media/Makefile   |  61 ---
 Documentation/media/audio.h.rst.exceptions |  20 -
 Documentation/media/ca.h.rst.exceptions|  24 -
 Documentation/media/cec.h.rst.exceptions   | 492 ---
 Documentation/media/dmx.h.rst.exceptions   |  63 ---
 Documentation/media/frontend.h.rst.exceptions  |  47 --
 Documentation/media/lirc.h.rst.exceptions  |  43 --
 Documentation/media/media.h.rst.exceptions |  30 --
 Documentation/media/net.h.rst.exceptions   |  11 -
 Documentation/media/uapi/cec/cec-header.rst|   3 +-
 Documentation/media/uapi/cec/cec.h.exceptions  | 492 +++
 Documentation/media/uapi/dvb/audio.h.exceptions|  20 +
 Documentation/media/uapi/dvb/audio_h.rst   |   2 +-
 Documentation/media/uapi/dvb/ca.h.exceptions   |  24 +
 Documentation/media/uapi/dvb/ca_h.rst  |   2 +-
 Documentation/media/uapi/dvb/dmx.h.exceptions  |  63 +++
 Documentation/media/uapi/dvb/dmx_h.rst |   2 +-
 Documentation/media/uapi/dvb/frontend.h.exceptions |  47 ++
 Documentation/media/uapi/dvb/frontend_h.rst|   2 +-
 Documentation/media/uapi/dvb/net.h.exceptions  |  11 +
 Documentation/media/uapi/dvb/net_h.rst |   2 +-
 Documentation/media/uapi/dvb/video.h.exceptions|  40 ++
 Documentation/media/uapi/dvb/video_h.rst   |   2 +-
 Documentation/media/uapi/mediactl/media-header.rst |   3 +-
 .../media/uapi/mediactl/media.h.exceptions |  30 ++
 Documentation/media/uapi/rc/lirc-header.rst|   2 +-
 Documentation/media/uapi/rc/lirc.h.exceptions  |  43 ++
 Documentation/media/uapi/v4l/videodev.rst  |   2 +-
 .../media/uapi/v4l/videodev2.h.exceptions  | 535 +
 Documentation/media/video.h.rst.exceptions |  40 --
 Documentation/media/videodev2.h.rst.exceptions | 535 -
 Documentation/sphinx/parse-headers.pl  |  17 +-
 33 files changed, 1323 insertions(+), 1389 deletions(-)
 delete mode 100644 Documentation/media/Makefile
 delete mode 100644 Documentation/media/audio.h.rst.exceptions
 delete mode 100644 Documentation/media/ca.h.rst.exceptions
 delete mode 100644 Documentation/media/cec.h.rst.exceptions
 delete mode 100644 Documentation/media/dmx.h.rst.exceptions
 delete mode 100644 Documentation/media/frontend.h.rst.exceptions
 delete mode 100644 Documentation/media/lirc.h.rst.exceptions
 delete mode 100644 Documentation/media/media.h.rst.exceptions
 delete mode 100644 Documentation/media/net.h.rst.exceptions
 create mode 100644 Documentation/media/uapi/cec/cec.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/audio.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/ca.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/dmx.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/frontend.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/net.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/video.h.exceptions
 create mode 100644 Documentation/media/uapi/mediactl/media.h.exceptions
 create mode 100644 Documentation/media/uapi/rc/lirc.h.exceptions
 create mode 100644 Documentation/media/uapi/v4l/videodev2.h.exceptions
 delete mode 100644 Documentation/media/video.h.rst.exceptions
 delete mode 100644 Documentation/media/videodev2.h.rst.exceptions

diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index 92deea3..2e033e4 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -52,7 +52,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
 #e.g. "media" for the linux-tv book-set at ./Documentation/media
 
 quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
-  cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
$(build)=Documentation/media all;\
+  cmd_sphinx = \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
$(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(SPHINXBUILD) \
-b $2 \
diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
deleted file mode 100644
index a7fb352..000
--- a/Documentation/media/Makefile
+++ /dev/null
@@ -1,61 +0,0 @@
-# Generate the *.h.rst files from uAPI headers
-
-PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl
-UAPI = $(srctree)/include/uapi/linux
-KAPI = $(srctree)/include/linux
-SRC_DIR=$(srctree)/Documentation/media
-
-FILES = audio.h.rst

[PATCH 2/4] doc-rst: customize RTD theme; literal-block

2016-10-06 Thread Markus Heiser 
From: Markus Heiser 

From: Markus Heiser 

Format the literal-block like other code-block elements, with 12px and a
line-high of 1.5.

Signed-off-by: Markus Heiser 
---
 Documentation/sphinx-static/theme_overrides.css | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/sphinx-static/theme_overrides.css 
b/Documentation/sphinx-static/theme_overrides.css
index 8c00f84..47026e4 100644
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -69,4 +69,11 @@
 .rst-content tt.literal,.rst-content tt.literal,.rst-content code.literal {
 color: inherit;
 }
+
+/* literal blocks (e.g. parsed-literal directive) */
+
+pre.literal-block {
+font-size: 12px;
+line-height: 1.5;
+}
 }
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] doc-rst: reST-directive kernel-cmd / include contentent from scripts

2016-10-06 Thread Markus Heiser 
From: Markus Heiser 

From: Markus Heiser 

The ``kernel-cmd`` directive includes contend from the stdout of a
command-line. With the ``kernel-cmd`` directive we can include the
output of any (Perl or whatever) script. This is a more general solution
for other workarounds like the "kernel_include + parseheaders" solution.

Overview of directive's argument and options.

.. code-block:: rst

.. kernel-cmd:: 
:depends: 
:code-block: 
:debug:

The argument  is required, it is a command line to be
executed. The stdout stream of the command is captured and is inserted as
reST content. The command line is executed in a system shell where the PATH
environment is extended with the paths ::

PATH=$(srctree)/scripts:$(srctree)/Documentation/sphinx:...

A very simple example, which includes the output as ``code-block``::

  .. kernel-cmd:: ls -la $srctree
:code-block: sh

The ``code-block`` is optional, leaving it will include the output as
pure (hopefully well) formated reST.

.. warning::

   The kernel-cmd directive **executes** commands, whatever poses a risk
   (shell injection) in itself!

   The command might depend on local installations, don't use commands which
   are not available in some OS (be clear about the dependencies).

Signed-off-by: Markus Heiser 
---
 Documentation/conf.py  |   2 +-
 Documentation/sphinx/kernel_cmd.py | 206 +
 2 files changed, 207 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/sphinx/kernel_cmd.py

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 0cc8765..64231e1 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,7 +34,7 @@ from load_config import loadConfig
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain']
+extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain', 
'kernel_cmd']
 
 # The name of the math extension changed on Sphinx 1.4
 if minor > 3:
diff --git a/Documentation/sphinx/kernel_cmd.py 
b/Documentation/sphinx/kernel_cmd.py
new file mode 100644
index 000..ddb2a27
--- /dev/null
+++ b/Documentation/sphinx/kernel_cmd.py
@@ -0,0 +1,206 @@
+# -*- coding: utf-8; mode: python -*-
+u"""
+kernel-cmd
+~~
+
+Implementation of the ``kernel-cmd`` reST-directive.
+
+:copyright:  Copyright (C) 2016  Markus Heiser
+:license:GPL Version 2, June 1991 see Linux/COPYING for details.
+
+The ``kernel-cmd`` (:py:class:`KernelCmd`) directive includes contend
+from the stdout of a comand-line.
+
+Overview of directive's argument and options.
+
+.. code-block:: rst
+
+.. kernel-cmd:: 
+:depends: 
+:code-block: 
+:debug:
+
+The argument  is required, it is a command line to be
+executed. The stdout stream of the command is captured and is inserted as
+reST content. The command line is executed in a system shell where the PATH
+environment is extended with the paths ::
+
+PATH=$(srctree)/scripts:$(srctree)/Documentation/sphinx:...
+
+``depends ``
+
+  If the stdout of the command line depends on files, you can add them as
+  dependency, which means: if one of the listed files is changed, the
+  sphinx-build (environment) is newly build.
+
+``code-block ``
+
+  If the called script outputs a code-block, use the ``code-block`` option
+  with an *language* as argument.  The valid values for the highlighting
+  language are:
+
+  * none (no highlighting)
+  * guess (let Pygments guess the lexer based on contents, only works
+with certain well-recognizable languages)
+  * rest
+  * c
+  * and any other lexer alias that `Pygments
+`_ supports.
+
+``debug``
+  Inserts a code-block with the *raw* reST. Sometimes it is helpful to see
+  what reST is generated.
+
+.. warning::
+
+   The kernel-cmd directive **executes** commands, whatever poses a risk
+   (shell injection) in itself!
+
+   The command might depend on local installations, don't use commands 
which
+   are not available in some OS (be clear about the dependencies).
+
+"""
+
+import sys
+import os
+from os import path
+import subprocess
+
+from sphinx.ext.autodoc import AutodocReporter
+
+from docutils import nodes
+from docutils.parsers.rst import Directive, directives
+from docutils.statemachine import ViewList
+from docutils.utils.error_reporting import ErrorString
+
+
+__version__  = '1.0'
+
+# We can't assume that six is installed
+PY3 = sys.version_info[0] == 3
+PY2 = sys.version_info[0] == 2
+if PY3:
+# pylint: disable=C0103, W0622
+unicode = str
+basestring

[PATCH 4/4] doc-rst: remove the kernel-include directive

2016-10-06 Thread Markus Heiser 
From: Markus Heiser 

From: Markus Heiser 

The kernel-include directive is no longer needed, so lets remove this
out-of-favor solution.

BTW: fixed a C typo in the Documentation/Makefile

Signed-off-by: Markus Heiser 
---
 Documentation/Makefile.sphinx  |   2 +-
 Documentation/conf.py  |   2 +-
 Documentation/sphinx/kernel_include.py | 190 -
 3 files changed, 2 insertions(+), 192 deletions(-)
 delete mode 100755 Documentation/sphinx/kernel_include.py

diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index 2e033e4..36b8c41 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -51,7 +51,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
 # $5 reST source folder relative to $(srctree)/$(src),
 #e.g. "media" for the linux-tv book-set at ./Documentation/media
 
-quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
+quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
   cmd_sphinx = \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
$(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(SPHINXBUILD) \
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 64231e1..a165b53 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,7 +34,7 @@ from load_config import loadConfig
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain', 
'kernel_cmd']
+extensions = ['kernel-doc', 'rstFlatTable', 'cdomain', 'kernel_cmd']
 
 # The name of the math extension changed on Sphinx 1.4
 if minor > 3:
diff --git a/Documentation/sphinx/kernel_include.py 
b/Documentation/sphinx/kernel_include.py
deleted file mode 100755
index f523aa6..000
--- a/Documentation/sphinx/kernel_include.py
+++ /dev/null
@@ -1,190 +0,0 @@
-#!/usr/bin/env python3
-# -*- coding: utf-8; mode: python -*-
-# pylint: disable=R0903, C0330, R0914, R0912, E0401
-
-u"""
-kernel-include
-~~
-
-Implementation of the ``kernel-include`` reST-directive.
-
-:copyright:  Copyright (C) 2016  Markus Heiser
-:license:GPL Version 2, June 1991 see linux/COPYING for details.
-
-The ``kernel-include`` reST-directive is a replacement for the ``include``
-directive. The ``kernel-include`` directive expand environment variables in
-the path name and allows to include files from arbitrary locations.
-
-.. hint::
-
-  Including files from arbitrary locations (e.g. from ``/etc``) is a
-  security risk for builders. This is why the ``include`` directive from
-  docutils *prohibit* pathnames pointing to locations *above* the 
filesystem
-  tree where the reST document with the include directive is placed.
-
-Substrings of the form $name or ${name} are replaced by the value of
-environment variable name. Malformed variable names and references to
-non-existing variables are left unchanged.
-"""
-
-# 
==
-# imports
-# 
==
-
-import os.path
-
-from docutils import io, nodes, statemachine
-from docutils.utils.error_reporting import SafeString, ErrorString
-from docutils.parsers.rst import directives
-from docutils.parsers.rst.directives.body import CodeBlock, NumberLines
-from docutils.parsers.rst.directives.misc import Include
-
-__version__  = '1.0'
-
-# 
==
-def setup(app):
-# 
==
-
-app.add_directive("kernel-include", KernelInclude)
-return dict(
-version = __version__,
-parallel_read_safe = True,
-parallel_write_safe = True
-)
-
-# 
==
-class KernelInclude(Include):
-# 
==
-
-u"""KernelInclude (``kernel-include``) directive"""
-
-def run(self):
-path = os.path.realpath(
-os.path.expandvars(self.arguments[0]))
-
-# to get a bit security back, prohibit /etc:
-if path.startswith(os.sep + "etc"):
-raise self.severe(
-'Problems with "%s" directive, prohibited path: %s'
-% (self.name, path))
-
-self.arguments[0] = path
-
-#return super(KernelInclude, self).run() # won't work, see HINTs in 
_run()
-return self._run()
-
-def _run(self):
-"""Include a file as part of the content of this reST file."""
-
-# HINT: I had to copy the whole Include.run method. I'am not 
happy
-#

[PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

2016-10-06 Thread Markus Heiser 
From: Markus Heiser 

Hi Jon, Mauro, and Jani,

with this series a reST-directive kernel-cmd is introduced. The kernel-cmd
directive includes contend from the stdout of a command-line (@mchehab asked
for).

Including content from a command's stdout is a more general solution for other
workarounds like the "kernel_include + parseheaders" solution. This series also
migrates the kernel-include uses to kernel-cmd directives and drops the Makefile
in the media sub-folder. With the last patch, the (no longer needed)
kernel-include directive is removed.

-- Markus --

Markus Heiser (4):
  doc-rst: reST-directive kernel-cmd / include contentent from scripts
  doc-rst: customize RTD theme; literal-block
  doc-rst: migrated media build kernel-cmd directive
  doc-rst: remove the kernel-include directive

 Documentation/Makefile.sphinx  |   4 +-
 Documentation/conf.py  |   2 +-
 Documentation/media/Makefile   |  61 ---
 Documentation/media/audio.h.rst.exceptions |  20 -
 Documentation/media/ca.h.rst.exceptions|  24 -
 Documentation/media/cec.h.rst.exceptions   | 492 ---
 Documentation/media/dmx.h.rst.exceptions   |  63 ---
 Documentation/media/frontend.h.rst.exceptions  |  47 --
 Documentation/media/lirc.h.rst.exceptions  |  43 --
 Documentation/media/media.h.rst.exceptions |  30 --
 Documentation/media/net.h.rst.exceptions   |  11 -
 Documentation/media/uapi/cec/cec-header.rst|   3 +-
 Documentation/media/uapi/cec/cec.h.exceptions  | 492 +++
 Documentation/media/uapi/dvb/audio.h.exceptions|  20 +
 Documentation/media/uapi/dvb/audio_h.rst   |   2 +-
 Documentation/media/uapi/dvb/ca.h.exceptions   |  24 +
 Documentation/media/uapi/dvb/ca_h.rst  |   2 +-
 Documentation/media/uapi/dvb/dmx.h.exceptions  |  63 +++
 Documentation/media/uapi/dvb/dmx_h.rst |   2 +-
 Documentation/media/uapi/dvb/frontend.h.exceptions |  47 ++
 Documentation/media/uapi/dvb/frontend_h.rst|   2 +-
 Documentation/media/uapi/dvb/net.h.exceptions  |  11 +
 Documentation/media/uapi/dvb/net_h.rst |   2 +-
 Documentation/media/uapi/dvb/video.h.exceptions|  40 ++
 Documentation/media/uapi/dvb/video_h.rst   |   2 +-
 Documentation/media/uapi/mediactl/media-header.rst |   3 +-
 .../media/uapi/mediactl/media.h.exceptions |  30 ++
 Documentation/media/uapi/rc/lirc-header.rst|   2 +-
 Documentation/media/uapi/rc/lirc.h.exceptions  |  43 ++
 Documentation/media/uapi/v4l/videodev.rst  |   2 +-
 .../media/uapi/v4l/videodev2.h.exceptions  | 535 +
 Documentation/media/video.h.rst.exceptions |  40 --
 Documentation/media/videodev2.h.rst.exceptions | 535 -
 Documentation/sphinx-static/theme_overrides.css|   7 +
 Documentation/sphinx/kernel_cmd.py | 206 
 Documentation/sphinx/kernel_include.py | 190 
 Documentation/sphinx/parse-headers.pl  |  17 +-
 37 files changed, 1538 insertions(+), 1581 deletions(-)
 delete mode 100644 Documentation/media/Makefile
 delete mode 100644 Documentation/media/audio.h.rst.exceptions
 delete mode 100644 Documentation/media/ca.h.rst.exceptions
 delete mode 100644 Documentation/media/cec.h.rst.exceptions
 delete mode 100644 Documentation/media/dmx.h.rst.exceptions
 delete mode 100644 Documentation/media/frontend.h.rst.exceptions
 delete mode 100644 Documentation/media/lirc.h.rst.exceptions
 delete mode 100644 Documentation/media/media.h.rst.exceptions
 delete mode 100644 Documentation/media/net.h.rst.exceptions
 create mode 100644 Documentation/media/uapi/cec/cec.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/audio.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/ca.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/dmx.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/frontend.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/net.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/video.h.exceptions
 create mode 100644 Documentation/media/uapi/mediactl/media.h.exceptions
 create mode 100644 Documentation/media/uapi/rc/lirc.h.exceptions
 create mode 100644 Documentation/media/uapi/v4l/videodev2.h.exceptions
 delete mode 100644 Documentation/media/video.h.rst.exceptions
 delete mode 100644 Documentation/media/videodev2.h.rst.exceptions
 create mode 100644 Documentation/sphinx/kernel_cmd.py
 delete mode 100755 Documentation/sphinx/kernel_include.py

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html