Re: [RFC PATCH v2 3/7] sched/idle: Add poll before enter real idle path

[Quan Xu]

on 2017/8/29 20:45, Peter Zijlstra wrote:


On Tue, Aug 29, 2017 at 11:46:37AM +, Yang Zhang wrote:

Add poll in do_idle. For UP VM, if there are running task, it will not
goes into idle path, so we only enable poll in SMP VM.

Signed-off-by: Yang Zhang 
Signed-off-by: Quan Xu 

Broken SoB chain.

  Peter,  I can't follow 'Broken SoB chain'.. could you more about it?

  -Quan


diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 6c23e30..b374744 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -74,6 +74,7 @@ static noinline int __cpuidle cpu_idle_poll(void)
  }
  
  /* Weak implementations for optional arch specific functions */

+void __weak arch_cpu_idle_poll(void) { }
  void __weak arch_cpu_idle_prepare(void) { }
  void __weak arch_cpu_idle_enter(void) { }

And not a word on why we need a new arch hook. What's wrong with
arch_cpu_idle_enter() for instance?


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

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Anthony Yznaga]

Hi Khalid,

> On Aug 30, 2017, at 3:27 PM, Khalid Aziz  wrote:
> 
> Hi Anthony,
> 
> Thanks for taking the time to provide feedback. My comments inline below.
> 
> On 08/25/2017 04:31 PM, Anthony Yznaga wrote:
>>> On Aug 9, 2017, at 2:26 PM, Khalid Aziz  wrote:
>>> ..deleted..
>>> +provided by the hypervisor to the kernel.  Kernel returns the value of
>>> +ADI block size to userspace using auxiliary vector along with other ADI
>>> +info. Following auxiliary vectors are provided by the kernel:
>>> +
>>> +   AT_ADI_BLKSZADI block size. This is the granularity and
>>> +   alignment, in bytes, of ADI versioning.
>>> +   AT_ADI_NBITSNumber of ADI version bits in the VA
>> The previous patch series also defined AT_ADI_UEONADI.  Why was that
>> removed?
> 
> This was based upon a conversation we had when you mentioned future 
> processors may not implement this or change the way this is interpreted and 
> any applications depending upon this value would break at that point. I 
> removed it to eliminate building an unreliable dependency. If I misunderstood 
> what you said, please let me know.

On M7 there is an array of versions maintained for cachelines in the L2
cache. If a UE is detected in this array it results in the flush of all
eight ways of the array.  Clean lines go away, but dirty lines are
written back to memory with the version forced to 0xE.  The ue-on-adp MD
property communicates this tag value that may result from a UE in order
to give the guest the opportunity to avoid using the tag value.  An
application that intentionally used ADI in a way that relied on ADI
exceptions for its functionality may not want to have to consider
whether the mismatch was legitimate or due to a UE.

On M8 the HW implementation is changed and a tag value will never be
forced to another value.  That said, I think the ue-on-adp property
value was unfortunately inadvertently carried forward to M8.

It could probably be argued that the likelihood of seeing the UE is so
low that SW can ignore the possibility, but including the information
in an auxvec shouldn't break anything.


> 
>>> +
>>> +
>>> +IMPORTANT NOTES:
>>> +
>>> +- Version tag values of 0x0 and 0xf are reserved.
>> The documentation should probably state more specifically that an
>> in-memory tag value of 0x0 or 0xf is treated as "match all" by the HW
>> meaning that a mismatch exception will never be generated regardless
>> of the tag bits set in the VA accessing the memory.
> 
> Will do.
> 
>>> +
>>> +- Version tags are set on virtual addresses from userspace even though
>>> +  tags are stored in physical memory. Tags are set on a physical page
>>> +  after it has been allocated to a task and a pte has been created for
>>> +  it.
>>> +
>>> +- When a task frees a memory page it had set version tags on, the page
>>> +  goes back to free page pool. When this page is re-allocated to a task,
>>> +  kernel clears the page using block initialization ASI which clears the
>>> +  version tags as well for the page. If a page allocated to a task is
>>> +  freed and allocated back to the same task, old version tags set by the
>>> +  task on that page will no longer be present.
>> The specifics should be included here, too, so someone doesn't have
>> to guess what's going on if they make changes and the tags are no longer
>> cleared.  The HW clears the tag for a cacheline for block initializing
>> stores to 64-byte aligned addresses if PSTATE.mcde=0 or TTE.mcd=0.
>> PSTATE.mce is set when executing in the kernel, but pages are cleared
>> using kernel physical mapping VAs which are mapped with TTE.mcd=0.
>> Another HW behavior that should be mentioned is that tag mismatches
>> are not detected for non-faulting loads.
> 
> Sure, I can add that.
> 
>>> +
>>> +- Kernel does not set any tags for user pages and it is entirely a
>>> +  task's responsibility to set any version tags. Kernel does ensure the
>>> +  version tags are preserved if a page is swapped out to the disk and
>>> +  swapped back in. It also preserves that version tags if a page is
>>> +  migrated.
>> I only have a cursory understanding of how page migration works, but
>> I could not see how the tags would be preserved if a page were migrated.
>> I figured the place to copy the tags would be migrate_page_copy(), but
>> I don't see changes there.
> 
> For migrating user pages, the way I understand the code works is if the page 
> is mapped (which is the only time ADI tags are even in place), try_to_unmap() 
> is called with TTU_MIGRATION flag set. try_to_unmap() will call 
> arch_unmap_one() which saves the tags from currently mapped page. When the 
> new page has been allocated, contents of the old page are faulted in through 
> do_swap_page() which will call arch_do_swap_page(). arch_do_swap_page() then 
> restores the ADI tags.

My understanding from reading the code is that __unmap_and_move() calls
try_to_unmap() which unmaps the 

[PATCH v2] fscrypt: add a documentation file for filesystem-level encryption

[Eric Biggers]

From: Eric Biggers 

Perhaps long overdue, add a documentation file for filesystem-level
encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
directory.  The new file is based loosely on the latest version of the
"EXT4 Encryption Design Document (public version)" Google Doc, but with
many improvements made, including:

- Reflect the reality that it is not specific to ext4 anymore.
- More thoroughly document the design and user-visible API/behavior.
- Replace outdated information, such as the outdated explanation of how
  encrypted filenames are hashed for indexed directories and how
  encrypted filenames are presented to userspace without the key.
  (This was changed just before release.)

For now the focus is on the design and user-visible API/behavior, not on
how to add encryption support to a filesystem --- since the internal API
is still pretty messy and any standalone documentation for it would
become outdated as things get refactored over time.

Signed-off-by: Eric Biggers 
---
Changes since v1:
- Mention that using existing userspace tools is preferred
- Don't start an argument about the best way to get random numbers
- Make it clear that backup/restore of encrypted files without key is
  not supported yet
- Mention a reason why the encryption xattr should not be exposed
  via the xattr system calls

 Documentation/filesystems/fscrypt.rst | 597 ++
 Documentation/filesystems/index.rst   |  11 +
 MAINTAINERS   |   1 +
 3 files changed, 609 insertions(+)
 create mode 100644 Documentation/filesystems/fscrypt.rst

diff --git a/Documentation/filesystems/fscrypt.rst 
b/Documentation/filesystems/fscrypt.rst
new file mode 100644
index ..ec4cad049dde
--- /dev/null
+++ b/Documentation/filesystems/fscrypt.rst
@@ -0,0 +1,597 @@
+=
+Filesystem-level encryption (fscrypt)
+=
+
+Introduction
+
+
+fscrypt is a library which filesystems can hook into to support
+transparent encryption of files and directories.
+
+Note: "fscrypt" in this document refers to the kernel-level portion,
+implemented in ``fs/crypto/``, as opposed to the userspace tool
+`fscrypt `_.  This document only
+covers the kernel-level portion.  For command-line examples of how to
+use encryption, see the documentation for the userspace tool `fscrypt
+`_.  Also, it is strongly
+recommended to use the fscrypt userspace tool, or other existing
+userspace tools such as Android's key management system, over using
+the kernel's API directly.  Using existing tools reduces the chance of
+introducing your own security bugs.  (Nevertheless, for completeness
+this documentation covers the kernel's API anyway.)
+
+Unlike dm-crypt, fscrypt operates at the filesystem level rather than
+at the block device level.  This allows it to encrypt different files
+with different keys and to have unencrypted files on the same
+filesystem.  This is useful for multi-user systems where each user's
+data-at-rest needs to be cryptographically isolated from the others.
+However, except for filenames, fscrypt does not encrypt filesystem
+metadata.
+
+Unlike eCryptfs, which is a stacked filesystem, fscrypt is integrated
+directly into supported filesystems --- currently ext4, F2FS, and
+UBIFS.  This allows encrypted files to be read and written without
+caching both the decrypted and encrypted pages in the pagecache,
+thereby halving the memory used and bringing it in line with
+unencrypted files.  Similarly, half as many dentries and inodes are
+needed.  eCryptfs also limits filenames to 143 bytes, causing
+application compatibility issues; fscrypt allows the full 255 bytes
+(NAME_MAX).  Finally, unlike eCryptfs, the fscrypt API can be used by
+unprivileged users, with no need to mount anything.
+
+fscrypt does not support encrypting files in-place.  Instead, it
+supports marking an empty directory as encrypted.  Then, after
+userspace provides the key, all regular files, directories, and
+symbolic links created in that directory tree are transparently
+encrypted.
+
+Threat model
+
+
+Offline attacks
+---
+
+Provided that userspace chooses a strong encryption key, fscrypt
+protects the confidentiality of file contents and filenames in the
+event of a single point-in-time permanent offline compromise of the
+block device content.  fscrypt does not protect the confidentiality of
+non-filename metadata, e.g. file sizes, file permissions, file
+timestamps, and extended attributes.  Also, the existence and location
+of holes (unallocated blocks which logically contain all zeroes) in
+files is not protected.
+
+fscrypt is not guaranteed to protect confidentiality or authenticity
+if an attacker is able to manipulate the filesystem offline prior to
+an authorized user later accessing the 

[PATCH 01/15] media: dvb/intro: use the term Digital TV to refer to the system

[Mauro Carvalho Chehab]

On several places at the introduction, a digital TV board and its
kernel support is called as DVB. The reason is simple: by the
time the document was written, there were no other digital TV
standards :-)

Modernize the specs by referring to them as Digital TV.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/intro.rst | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/media/uapi/dvb/intro.rst 
b/Documentation/media/uapi/dvb/intro.rst
index 20bd7aec2665..de432ffcba50 100644
--- a/Documentation/media/uapi/dvb/intro.rst
+++ b/Documentation/media/uapi/dvb/intro.rst
@@ -13,7 +13,7 @@ What you need to know
 =
 
 The reader of this document is required to have some knowledge in the
-area of digital video broadcasting (DVB) and should be familiar with
+area of digital video broadcasting (Digital TV) and should be familiar with
 part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222), i.e
 you should know what a program/transport stream (PS/TS) is and what is
 meant by a packetized elementary stream (PES) or an I-frame.
@@ -59,14 +59,14 @@ Overview
 :alt:   dvbstb.svg
 :align: center
 
-Components of a DVB card/STB
+Components of a Digital TV card/STB
 
-A DVB PCI card or DVB set-top-box (STB) usually consists of the
+A Digital TV card or set-top-box (STB) usually consists of the
 following main hardware components:
 
--  Frontend consisting of tuner and DVB demodulator
+-  Frontend consisting of tuner and digital TV demodulator
 
-   Here the raw signal reaches the DVB hardware from a satellite dish or
+   Here the raw signal reaches the digital TV hardware from a satellite dish or
antenna or directly from cable. The frontend down-converts and
demodulates this signal into an MPEG transport stream (TS). In case
of a satellite frontend, this includes a facility for satellite
@@ -105,10 +105,10 @@ conditional access hardware.
 
 .. _dvb_devices:
 
-Linux DVB Devices
-=
+Linux Digital TV Devices
+
 
-The Linux DVB API lets you control these hardware components through
+The Linux Digital TV API lets you control these hardware components through
 currently six Unix-style character devices for video, audio, frontend,
 demux, CA and IP-over-DVB networking. The video and audio devices
 control the MPEG2 decoder hardware, the frontend device the tuner and
@@ -137,8 +137,8 @@ individual devices are called:
 
 -  ``/dev/dvb/adapterN/caM``,
 
-where ``N`` enumerates the DVB PCI cards in a system starting from 0, and ``M``
-enumerates the devices of each type within each adapter, starting
+where ``N`` enumerates the Digital TV cards in a system starting from 0, and
+``M`` enumerates the devices of each type within each adapter, starting
 from 0, too. We will omit the “``/dev/dvb/adapterN/``\ ” in the further
 discussion of these devices.
 
@@ -151,8 +151,8 @@ devices are described in the following chapters.
 API include files
 =
 
-For each of the DVB devices a corresponding include file exists. The DVB
-API include files should be included in application sources with a
+For each of the Digital TV devices a corresponding include file exists. The
+Digital TV API include files should be included in application sources with a
 partial path like:
 
 
-- 
2.13.5

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

[PATCH 04/15] media: dvb/intro: adjust the notices about optional hardware

[Mauro Carvalho Chehab]

Both CA and decoders are optional. Also, the presence or
absence has nothing to do on being a PCI card or not.

Nowadays, most hardware leaves the decoders to either the
GPU or to some ISP inside the SoC, instead of implementing
it inside the Digital TV part of the device.

So, change the wording to reflect the hardware changes.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/intro.rst | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/Documentation/media/uapi/dvb/intro.rst 
b/Documentation/media/uapi/dvb/intro.rst
index 4e1594816ef4..aeafc9ab96c1 100644
--- a/Documentation/media/uapi/dvb/intro.rst
+++ b/Documentation/media/uapi/dvb/intro.rst
@@ -71,8 +71,7 @@ Overview
 A Digital TV card or set-top-box (STB) usually consists of the
 following main hardware components:
 
--  Frontend consisting of tuner and digital TV demodulator
-
+Frontend consisting of tuner and digital TV demodulator
Here the raw signal reaches the digital TV hardware from a satellite dish or
antenna or directly from cable. The frontend down-converts and
demodulates this signal into an MPEG transport stream (TS). In case
@@ -80,34 +79,40 @@ following main hardware components:
equipment control (SEC), which allows control of LNB polarization,
multi feed switches or dish rotors.
 
--  Conditional Access (CA) hardware like CI adapters and smartcard slots
-
+Conditional Access (CA) hardware like CI adapters and smartcard slots
The complete TS is passed through the CA hardware. Programs to which
the user has access (controlled by the smart card) are decoded in
real time and re-inserted into the TS.
 
--  Demultiplexer which filters the incoming DVB stream
+   .. note::
 
+  Not every digital TV hardware provides conditional access hardware.
+
+Demultiplexer which filters the incoming DVB stream
The demultiplexer splits the TS into its components like audio and
video streams. Besides usually several of such audio and video
streams it also contains data streams with information about the
programs offered in this or other streams of the same provider.
 
--  MPEG2 audio and video decoder
-
+MPEG2 audio and video decoder
The main targets of the demultiplexer are the MPEG2 audio and video
decoders. After decoding they pass on the uncompressed audio and
video to the computer screen or (through a PAL/NTSC encoder) to a TV
set.
 
+   .. note::
+
+  Modern hardware usually doesn't have a separate decoder hardware, as
+  such functionality can be provided by the main CPU, by the graphics
+  adapter of the system or by a signal processing hardware embedded on
+  a Systems on a Chip (SoC) integrated circuit.
+
+  It may also not be needed for certain usages (e.g. for data-only
+  uses like “internet over satellite”).
+
 :ref:`stb_components` shows a crude schematic of the control and data
 flow between those components.
 
-On a DVB PCI card not all of these have to be present since some
-functionality can be provided by the main CPU of the PC (e.g. MPEG
-picture and sound decoding) or is not needed (e.g. for data-only uses
-like “internet over satellite”). Also not every card or STB provides
-conditional access hardware.
 
 
 .. _dvb_devices:
-- 
2.13.5

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

[PATCH 03/15] media: dvb/intro: update the history part of the document

[Mauro Carvalho Chehab]

Convergence doesn't exist anymore. The community itself maintains
the spec. Update accordingly.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/intro.rst | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/Documentation/media/uapi/dvb/intro.rst 
b/Documentation/media/uapi/dvb/intro.rst
index 991643d3b461..4e1594816ef4 100644
--- a/Documentation/media/uapi/dvb/intro.rst
+++ b/Documentation/media/uapi/dvb/intro.rst
@@ -39,15 +39,19 @@ grabber cards. As such it was not really well suited to be 
used for DVB
 cards and their new features like recording MPEG streams and filtering
 several section and PES data streams at the same time.
 
-In early 2000, we were approached by Nokia with a proposal for a new
+In early 2000, Convergence was approached by Nokia with a proposal for a new
 standard Linux DVB API. As a commitment to the development of terminals
 based on open standards, Nokia and Convergence made it available to all
 Linux developers and published it on https://linuxtv.org in September
-2000. Convergence is the maintainer of the Linux DVB API. Together with
-the LinuxTV community (i.e. you, the reader of this document), the Linux
-DVB API will be constantly reviewed and improved. With the Linux driver
-for the Siemens/Hauppauge DVB PCI card Convergence provides a first
-implementation of the Linux DVB API.
+2000. With the Linux driver for the Siemens/Hauppauge DVB PCI card,
+Convergence provided a first implementation of the Linux DVB API.
+Convergence was the maintainer of the Linux DVB API in the early
+days.
+
+Now, the API is maintained by the LinuxTV community (i.e. you, the reader
+of this document). The Linux  Digital TV API is constantly reviewed and
+improved together with the improvements at the subsystem's core at the
+Kernel.
 
 
 .. _overview:
-- 
2.13.5

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

[PATCH 10/15] media: dmx.h: get rid of unused DMX_KERNEL_CLIENT

[Mauro Carvalho Chehab]

There's a flag defined for Digital TV demux that is not used
anywhere, called DMX_KERNEL_CLIENT. Get rid of it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/dmx.h.rst.exceptions   | 1 -
 Documentation/media/uapi/dvb/dmx_types.rst | 1 -
 include/uapi/linux/dvb/dmx.h   | 1 -
 3 files changed, 3 deletions(-)

diff --git a/Documentation/media/dmx.h.rst.exceptions 
b/Documentation/media/dmx.h.rst.exceptions
index 2fdb458564ba..933ca5a61ce1 100644
--- a/Documentation/media/dmx.h.rst.exceptions
+++ b/Documentation/media/dmx.h.rst.exceptions
@@ -56,7 +56,6 @@ replace symbol DMX_SOURCE_DVR3 :c:type:`dmx_source`
 replace define DMX_CHECK_CRC :c:type:`dmx_sct_filter_params`
 replace define DMX_ONESHOT :c:type:`dmx_sct_filter_params`
 replace define DMX_IMMEDIATE_START :c:type:`dmx_sct_filter_params`
-replace define DMX_KERNEL_CLIENT :c:type:`dmx_sct_filter_params`
 
 # some typedefs should point to struct/enums
 replace typedef dmx_caps_t :c:type:`dmx_caps`
diff --git a/Documentation/media/uapi/dvb/dmx_types.rst 
b/Documentation/media/uapi/dvb/dmx_types.rst
index 80dd659860d7..0f0113205c94 100644
--- a/Documentation/media/uapi/dvb/dmx_types.rst
+++ b/Documentation/media/uapi/dvb/dmx_types.rst
@@ -147,7 +147,6 @@ struct dmx_sct_filter_params
 #define DMX_CHECK_CRC   1
 #define DMX_ONESHOT 2
 #define DMX_IMMEDIATE_START 4
-#define DMX_KERNEL_CLIENT   0x8000
 };
 
 
diff --git a/include/uapi/linux/dvb/dmx.h b/include/uapi/linux/dvb/dmx.h
index 427e4899ed69..d4934e650e6b 100644
--- a/include/uapi/linux/dvb/dmx.h
+++ b/include/uapi/linux/dvb/dmx.h
@@ -105,7 +105,6 @@ struct dmx_sct_filter_params
 #define DMX_CHECK_CRC   1
 #define DMX_ONESHOT 2
 #define DMX_IMMEDIATE_START 4
-#define DMX_KERNEL_CLIENT   0x8000
 };
 
 
-- 
2.13.5

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

[PATCH 15/15] media: net.rst: Fix the level of a section of the net chapter

[Mauro Carvalho Chehab]

Due to a mistake, the DVB net chapter was actually broken
into two different chapters. Fix it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/net.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/media/uapi/dvb/net.rst 
b/Documentation/media/uapi/dvb/net.rst
index eca42dd53261..00ae5df0c321 100644
--- a/Documentation/media/uapi/dvb/net.rst
+++ b/Documentation/media/uapi/dvb/net.rst
@@ -28,7 +28,6 @@ header.
 
 .. _net_fcalls:
 
-##
 DVB net Function Calls
 ##
 
-- 
2.13.5

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

[PATCH 02/15] media: dvb/intro: update references for TV standards

[Mauro Carvalho Chehab]

The references there are only for DVB. Add missing references for
ATSC and ISDB standards.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/intro.rst | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/media/uapi/dvb/intro.rst 
b/Documentation/media/uapi/dvb/intro.rst
index de432ffcba50..991643d3b461 100644
--- a/Documentation/media/uapi/dvb/intro.rst
+++ b/Documentation/media/uapi/dvb/intro.rst
@@ -18,10 +18,13 @@ part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T 
H.222), i.e
 you should know what a program/transport stream (PS/TS) is and what is
 meant by a packetized elementary stream (PES) or an I-frame.
 
-Various DVB standards documents are available from http://www.dvb.org
-and/or http://www.etsi.org.
+Various Digital TV standards documents are available for download at:
 
-It is also necessary to know how to access unix/linux devices and how to
+- European standards (DVB): http://www.dvb.org and/or http://www.etsi.org.
+- American standards (ATSC): https://www.atsc.org/standards/
+- Japanese standards (ISDB): http://www.dibeg.org/
+
+It is also necessary to know how to access Linux devices and how to
 use ioctl calls. This also includes the knowledge of C or C++.
 
 
-- 
2.13.5

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

[PATCH 12/15] media: dmx.h: get rid of DMX_SET_SOURCE

[Mauro Carvalho Chehab]

No driver uses this ioctl, nor it is documented anywhere.

So, get rid of it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/dmx.h.rst.exceptions| 13 
 Documentation/media/uapi/dvb/dmx-set-source.rst | 44 -
 Documentation/media/uapi/dvb/dmx_fcalls.rst |  1 -
 Documentation/media/uapi/dvb/dmx_types.rst  | 20 ---
 include/uapi/linux/dvb/dmx.h| 12 ---
 5 files changed, 90 deletions(-)
 delete mode 100644 Documentation/media/uapi/dvb/dmx-set-source.rst

diff --git a/Documentation/media/dmx.h.rst.exceptions 
b/Documentation/media/dmx.h.rst.exceptions
index 5572d2dc9d0e..d2dac35bb84b 100644
--- a/Documentation/media/dmx.h.rst.exceptions
+++ b/Documentation/media/dmx.h.rst.exceptions
@@ -40,18 +40,6 @@ replace enum dmx_input :c:type:`dmx_input`
 replace symbol DMX_IN_FRONTEND :c:type:`dmx_input`
 replace symbol DMX_IN_DVR :c:type:`dmx_input`
 
-# dmx_source_t symbols
-replace enum dmx_source :c:type:`dmx_source`
-replace symbol DMX_SOURCE_FRONT0 :c:type:`dmx_source`
-replace symbol DMX_SOURCE_FRONT1 :c:type:`dmx_source`
-replace symbol DMX_SOURCE_FRONT2 :c:type:`dmx_source`
-replace symbol DMX_SOURCE_FRONT3 :c:type:`dmx_source`
-replace symbol DMX_SOURCE_DVR0 :c:type:`dmx_source`
-replace symbol DMX_SOURCE_DVR1 :c:type:`dmx_source`
-replace symbol DMX_SOURCE_DVR2 :c:type:`dmx_source`
-replace symbol DMX_SOURCE_DVR3 :c:type:`dmx_source`
-
-
 # Flags for struct dmx_sct_filter_params
 replace define DMX_CHECK_CRC :c:type:`dmx_sct_filter_params`
 replace define DMX_ONESHOT :c:type:`dmx_sct_filter_params`
@@ -61,4 +49,3 @@ replace define DMX_IMMEDIATE_START 
:c:type:`dmx_sct_filter_params`
 replace typedef dmx_filter_t :c:type:`dmx_filter`
 replace typedef dmx_pes_type_t :c:type:`dmx_pes_type`
 replace typedef dmx_input_t :c:type:`dmx_input`
-replace typedef dmx_source_t :c:type:`dmx_source`
diff --git a/Documentation/media/uapi/dvb/dmx-set-source.rst 
b/Documentation/media/uapi/dvb/dmx-set-source.rst
deleted file mode 100644
index ac7f77b25e06..
--- a/Documentation/media/uapi/dvb/dmx-set-source.rst
+++ /dev/null
@@ -1,44 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _DMX_SET_SOURCE:
-
-==
-DMX_SET_SOURCE
-==
-
-Name
-
-
-DMX_SET_SOURCE
-
-
-Synopsis
-
-
-.. c:function:: int ioctl(fd, DMX_SET_SOURCE, struct dmx_source *src)
-:name: DMX_SET_SOURCE
-
-
-Arguments
--
-
-
-``fd``
-File descriptor returned by :c:func:`open() `.
-
-``src``
-   Undocumented.
-
-
-Description

-
-.. note:: This ioctl is undocumented. Documentation is welcome.
-
-
-Return Value
-
-
-On success 0 is returned, on error -1 and the ``errno`` variable is set
-appropriately. The generic error codes are described at the
-:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/dvb/dmx_fcalls.rst 
b/Documentation/media/uapi/dvb/dmx_fcalls.rst
index 49e013d4540f..be98d60877f2 100644
--- a/Documentation/media/uapi/dvb/dmx_fcalls.rst
+++ b/Documentation/media/uapi/dvb/dmx_fcalls.rst
@@ -21,6 +21,5 @@ Demux Function Calls
 dmx-get-event
 dmx-get-stc
 dmx-get-pes-pids
-dmx-set-source
 dmx-add-pid
 dmx-remove-pid
diff --git a/Documentation/media/uapi/dvb/dmx_types.rst 
b/Documentation/media/uapi/dvb/dmx_types.rst
index 9e907b85cf16..a205c02ccdc1 100644
--- a/Documentation/media/uapi/dvb/dmx_types.rst
+++ b/Documentation/media/uapi/dvb/dmx_types.rst
@@ -197,23 +197,3 @@ struct dmx_stc
unsigned int base;  /* output: divisor for stc to get 90 kHz clock */
__u64 stc;  /* output: stc in 'base'*90 kHz units */
 };
-
-
-
-enum dmx_source
-===
-
-.. c:type:: dmx_source
-
-.. code-block:: c
-
-typedef enum dmx_source {
-   DMX_SOURCE_FRONT0 = 0,
-   DMX_SOURCE_FRONT1,
-   DMX_SOURCE_FRONT2,
-   DMX_SOURCE_FRONT3,
-   DMX_SOURCE_DVR0   = 16,
-   DMX_SOURCE_DVR1,
-   DMX_SOURCE_DVR2,
-   DMX_SOURCE_DVR3
-} dmx_source_t;
diff --git a/include/uapi/linux/dvb/dmx.h b/include/uapi/linux/dvb/dmx.h
index c0ee44fbdb13..dd2b832c02ce 100644
--- a/include/uapi/linux/dvb/dmx.h
+++ b/include/uapi/linux/dvb/dmx.h
@@ -117,17 +117,6 @@ struct dmx_pes_filter_params
__u32  flags;
 };
 
-typedef enum dmx_source {
-   DMX_SOURCE_FRONT0 = 0,
-   DMX_SOURCE_FRONT1,
-   DMX_SOURCE_FRONT2,
-   DMX_SOURCE_FRONT3,
-   DMX_SOURCE_DVR0   = 16,
-   DMX_SOURCE_DVR1,
-   DMX_SOURCE_DVR2,
-   DMX_SOURCE_DVR3
-} dmx_source_t;
-
 struct dmx_stc {
unsigned int num;   /* input : which STC? 0..N */
unsigned int base;  /* output: divisor for stc to get 90 kHz clock 
*/
@@ -140,7 +129,6 @@ struct dmx_stc {
 #define DMX_SET_PES_FILTER   _IOW('o', 44, struct dmx_pes_filter_params)
 #define DMX_SET_BUFFER_SIZE  _IO('o', 45)
 #define DMX_GET_PES_PIDS _IOR('o', 47, __u16[5])
-#define 

[PATCH 08/15] media: fe_property_parameters.rst: better define properties usage

[Mauro Carvalho Chehab]

Several frontend properties are specific to a subset of the
delivery systems. Make it clearer when describing each
property.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/dvb/fe_property_parameters.rst  | 82 --
 1 file changed, 75 insertions(+), 7 deletions(-)

diff --git a/Documentation/media/uapi/dvb/fe_property_parameters.rst 
b/Documentation/media/uapi/dvb/fe_property_parameters.rst
index c6eb74f59b00..e085e84fef38 100644
--- a/Documentation/media/uapi/dvb/fe_property_parameters.rst
+++ b/Documentation/media/uapi/dvb/fe_property_parameters.rst
@@ -111,6 +111,8 @@ DTV_BANDWIDTH_HZ
 
 Bandwidth for the channel, in HZ.
 
+Should be set only for terrestrial delivery systems.
+
 Possible values: ``1712000``, ``500``, ``600``, ``700``,
 ``800``, ``1000``.
 
@@ -148,6 +150,7 @@ Specifies if the frontend should do spectral inversion or 
not.
 
 The acceptable values are defined by :c:type:`fe_spectral_inversion`.
 
+
 .. _DTV-DISEQC-MASTER:
 
 DTV_DISEQC_MASTER
@@ -161,8 +164,9 @@ Currently not implemented.
 DTV_SYMBOL_RATE
 ===
 
-Digital TV symbol rate, in bauds (symbols/second). Used on cable
-standards.
+Used on cable and satellite delivery systems.
+
+Digital TV symbol rate, in bauds (symbols/second).
 
 
 .. _DTV-INNER-FEC:
@@ -170,7 +174,7 @@ standards.
 DTV_INNER_FEC
 =
 
-Used cable/satellite transmissions.
+Used on cable and satellite delivery systems.
 
 The acceptable values are defined by :c:type:`fe_code_rate`.
 
@@ -180,6 +184,8 @@ The acceptable values are defined by :c:type:`fe_code_rate`.
 DTV_VOLTAGE
 ===
 
+Used on satellite delivery systems.
+
 The voltage is usually used with non-DiSEqC capable LNBs to switch the
 polarzation (horizontal/vertical). When using DiSEqC epuipment this
 voltage has to be switched consistently to the DiSEqC commands as
@@ -201,6 +207,8 @@ Currently not used.
 DTV_PILOT
 =
 
+Used on DVB-S2.
+
 Sets DVB-S2 pilot.
 
 The acceptable values are defined by :c:type:`fe_pilot`.
@@ -211,7 +219,9 @@ The acceptable values are defined by :c:type:`fe_pilot`.
 DTV_ROLLOFF
 ===
 
-Sets DVB-S2 rolloff
+Used on DVB-S2.
+
+Sets DVB-S2 rolloff.
 
 The acceptable values are defined by :c:type:`fe_rolloff`.
 
@@ -245,7 +255,7 @@ Currently not implemented.
 DTV_DELIVERY_SYSTEM
 ===
 
-Specifies the type of Delivery system.
+Specifies the type of the delivery system.
 
 The acceptable values are defined by :c:type:`fe_delivery_system`.
 
@@ -255,6 +265,8 @@ The acceptable values are defined by 
:c:type:`fe_delivery_system`.
 DTV_ISDBT_PARTIAL_RECEPTION
 ===
 
+Used only on ISDB.
+
 If ``DTV_ISDBT_SOUND_BROADCASTING`` is '0' this bit-field represents
 whether the channel is in partial reception mode or not.
 
@@ -273,6 +285,8 @@ Possible values: 0, 1, -1 (AUTO)
 DTV_ISDBT_SOUND_BROADCASTING
 
 
+Used only on ISDB.
+
 This field represents whether the other DTV_ISDBT_*-parameters are
 referring to an ISDB-T and an ISDB-Tsb channel. (See also
 ``DTV_ISDBT_PARTIAL_RECEPTION``).
@@ -285,6 +299,8 @@ Possible values: 0, 1, -1 (AUTO)
 DTV_ISDBT_SB_SUBCHANNEL_ID
 ==
 
+Used only on ISDB.
+
 This field only applies if ``DTV_ISDBT_SOUND_BROADCASTING`` is '1'.
 
 (Note of the author: This might not be the correct description of the
@@ -320,6 +336,8 @@ Possible values: 0 .. 41, -1 (AUTO)
 DTV_ISDBT_SB_SEGMENT_IDX
 
 
+Used only on ISDB.
+
 This field only applies if ``DTV_ISDBT_SOUND_BROADCASTING`` is '1'.
 
 ``DTV_ISDBT_SB_SEGMENT_IDX`` gives the index of the segment to be
@@ -336,6 +354,8 @@ Note: This value cannot be determined by an automatic 
channel search.
 DTV_ISDBT_SB_SEGMENT_COUNT
 ==
 
+Used only on ISDB.
+
 This field only applies if ``DTV_ISDBT_SOUND_BROADCASTING`` is '1'.
 
 ``DTV_ISDBT_SB_SEGMENT_COUNT`` gives the total count of connected
@@ -351,6 +371,8 @@ Note: This value cannot be determined by an automatic 
channel search.
 DTV-ISDBT-LAYER[A-C] parameters
 ===
 
+Used only on ISDB.
+
 ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
 ISDB-T hierarchical layers can be decoded simultaneously. For that
 reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.
@@ -367,6 +389,8 @@ There are 3 parameter sets, for Layers A, B and C.
 DTV_ISDBT_LAYER_ENABLED
 ---
 
+Used only on ISDB.
+
 Hierarchical reception in ISDB-T is achieved by enabling or disabling
 layers in the decoding process. Setting all bits of
 ``DTV_ISDBT_LAYER_ENABLED`` to '1' forces all layers (if applicable) to
@@ -397,6 +421,8 @@ Only the values of the first 3 bits are used. Other bits 
will be silently ignore
 DTV_ISDBT_LAYER[A-C]_FEC
 
 
+Used only on ISDB.
+
 The Forward Error Correction mechanism used by a given ISDB Layer, as
 defined by 

[PATCH 14/15] media: dmx.h: add kernel-doc markups and use it at Documentation/

[Mauro Carvalho Chehab]

The demux documentation is pretty poor nowadays: most of the
structs and enums aren't documented at all.

Add proper kernel-doc markups for them and use it.

Now, the demux API is fully documented :-)

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/dmx.h.rst.exceptions   |   5 +
 Documentation/media/uapi/dvb/dmx_types.rst | 173 +
 include/uapi/linux/dvb/dmx.h   | 152 +++--
 3 files changed, 127 insertions(+), 203 deletions(-)

diff --git a/Documentation/media/dmx.h.rst.exceptions 
b/Documentation/media/dmx.h.rst.exceptions
index d2dac35bb84b..629db384104a 100644
--- a/Documentation/media/dmx.h.rst.exceptions
+++ b/Documentation/media/dmx.h.rst.exceptions
@@ -49,3 +49,8 @@ replace define DMX_IMMEDIATE_START 
:c:type:`dmx_sct_filter_params`
 replace typedef dmx_filter_t :c:type:`dmx_filter`
 replace typedef dmx_pes_type_t :c:type:`dmx_pes_type`
 replace typedef dmx_input_t :c:type:`dmx_input`
+
+ignore symbol DMX_OUT_DECODER
+ignore symbol DMX_OUT_TAP
+ignore symbol DMX_OUT_TS_TAP
+ignore symbol DMX_OUT_TSDEMUX_TAP
diff --git a/Documentation/media/uapi/dvb/dmx_types.rst 
b/Documentation/media/uapi/dvb/dmx_types.rst
index 171205ed86a4..2a023a4f516c 100644
--- a/Documentation/media/uapi/dvb/dmx_types.rst
+++ b/Documentation/media/uapi/dvb/dmx_types.rst
@@ -6,175 +6,4 @@
 Demux Data Types
 
 
-Output for the demux
-
-
-.. c:type:: dmx_output
-
-.. tabularcolumns:: |p{5.0cm}|p{12.5cm}|
-
-.. flat-table:: enum dmx_output
-:header-rows:  1
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  ID
-
-   -  Description
-
--  .. row 2
-
-   -  .. _DMX-OUT-DECODER:
-
- DMX_OUT_DECODER
-
-   -  Streaming directly to decoder.
-
--  .. row 3
-
-   -  .. _DMX-OUT-TAP:
-
- DMX_OUT_TAP
-
-   -  Output going to a memory buffer (to be retrieved via the read
- command). Delivers the stream output to the demux device on which
- the ioctl is called.
-
--  .. row 4
-
-   -  .. _DMX-OUT-TS-TAP:
-
- DMX_OUT_TS_TAP
-
-   -  Output multiplexed into a new TS (to be retrieved by reading from
- the logical DVR device). Routes output to the logical DVR device
- ``/dev/dvb/adapter?/dvr?``, which delivers a TS multiplexed from
- all filters for which ``DMX_OUT_TS_TAP`` was specified.
-
--  .. row 5
-
-   -  .. _DMX-OUT-TSDEMUX-TAP:
-
- DMX_OUT_TSDEMUX_TAP
-
-   -  Like :ref:`DMX_OUT_TS_TAP ` but retrieved
- from the DMX device.
-
-
-dmx_input_t
-===
-
-.. c:type:: dmx_input
-
-.. code-block:: c
-
-typedef enum
-{
-   DMX_IN_FRONTEND, /* Input from a front-end device.  */
-   DMX_IN_DVR   /* Input from the logical DVR device.  */
-} dmx_input_t;
-
-
-dmx_pes_type_t
-==
-
-.. c:type:: dmx_pes_type
-
-
-.. code-block:: c
-
-typedef enum
-{
-   DMX_PES_AUDIO0,
-   DMX_PES_VIDEO0,
-   DMX_PES_TELETEXT0,
-   DMX_PES_SUBTITLE0,
-   DMX_PES_PCR0,
-
-   DMX_PES_AUDIO1,
-   DMX_PES_VIDEO1,
-   DMX_PES_TELETEXT1,
-   DMX_PES_SUBTITLE1,
-   DMX_PES_PCR1,
-
-   DMX_PES_AUDIO2,
-   DMX_PES_VIDEO2,
-   DMX_PES_TELETEXT2,
-   DMX_PES_SUBTITLE2,
-   DMX_PES_PCR2,
-
-   DMX_PES_AUDIO3,
-   DMX_PES_VIDEO3,
-   DMX_PES_TELETEXT3,
-   DMX_PES_SUBTITLE3,
-   DMX_PES_PCR3,
-
-   DMX_PES_OTHER
-} dmx_pes_type_t;
-
-
-struct dmx_filter
-=
-
-.. c:type:: dmx_filter
-
-.. code-block:: c
-
- typedef struct dmx_filter
-{
-   __u8  filter[DMX_FILTER_SIZE];
-   __u8  mask[DMX_FILTER_SIZE];
-   __u8  mode[DMX_FILTER_SIZE];
-} dmx_filter_t;
-
-
-.. c:type:: dmx_sct_filter_params
-
-struct dmx_sct_filter_params
-
-
-
-.. code-block:: c
-
-struct dmx_sct_filter_params
-{
-   __u16  pid;
-   dmx_filter_t   filter;
-   __u32  timeout;
-   __u32  flags;
-#define DMX_CHECK_CRC   1
-#define DMX_ONESHOT 2
-#define DMX_IMMEDIATE_START 4
-};
-
-
-struct dmx_pes_filter_params
-
-
-.. c:type:: dmx_pes_filter_params
-
-.. code-block:: c
-
-struct dmx_pes_filter_params
-{
-   __u16  pid;
-   dmx_input_tinput;
-   dmx_output_t   output;
-   dmx_pes_type_t pes_type;
-   __u32  flags;
-};
-
-struct dmx_stc
-==
-
-.. c:type:: dmx_stc
-
-.. code-block:: c
-
-struct dmx_stc {
-   unsigned int num;   /* input : which STC? 0..N */
-   unsigned int base;  /* output: divisor for stc to get 90 kHz clock */
-   __u64 stc;  /* output: stc in 'base'*90 kHz units */
-};
+.. kernel-doc:: include/uapi/linux/dvb/dmx.h
diff --git a/include/uapi/linux/dvb/dmx.h b/include/uapi/linux/dvb/dmx.h
index dd2b832c02ce..8357885fc11c 100644
--- 

[PATCH 11/15] media: dmx.h: get rid of DMX_GET_CAPS

[Mauro Carvalho Chehab]

There's no driver currently using it; it is also not
documented about what it would be supposed to do.

So, get rid of it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/dmx.h.rst.exceptions  |  1 -
 Documentation/media/uapi/dvb/dmx-get-caps.rst | 41 ---
 Documentation/media/uapi/dvb/dmx_fcalls.rst   |  1 -
 Documentation/media/uapi/dvb/dmx_types.rst| 12 
 include/uapi/linux/dvb/dmx.h  |  6 
 5 files changed, 61 deletions(-)
 delete mode 100644 Documentation/media/uapi/dvb/dmx-get-caps.rst

diff --git a/Documentation/media/dmx.h.rst.exceptions 
b/Documentation/media/dmx.h.rst.exceptions
index 933ca5a61ce1..5572d2dc9d0e 100644
--- a/Documentation/media/dmx.h.rst.exceptions
+++ b/Documentation/media/dmx.h.rst.exceptions
@@ -58,7 +58,6 @@ replace define DMX_ONESHOT :c:type:`dmx_sct_filter_params`
 replace define DMX_IMMEDIATE_START :c:type:`dmx_sct_filter_params`
 
 # some typedefs should point to struct/enums
-replace typedef dmx_caps_t :c:type:`dmx_caps`
 replace typedef dmx_filter_t :c:type:`dmx_filter`
 replace typedef dmx_pes_type_t :c:type:`dmx_pes_type`
 replace typedef dmx_input_t :c:type:`dmx_input`
diff --git a/Documentation/media/uapi/dvb/dmx-get-caps.rst 
b/Documentation/media/uapi/dvb/dmx-get-caps.rst
deleted file mode 100644
index 145fb520d779..
--- a/Documentation/media/uapi/dvb/dmx-get-caps.rst
+++ /dev/null
@@ -1,41 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _DMX_GET_CAPS:
-
-
-DMX_GET_CAPS
-
-
-Name
-
-
-DMX_GET_CAPS
-
-
-Synopsis
-
-
-.. c:function:: int ioctl(fd, DMX_GET_CAPS, struct dmx_caps *caps)
-:name: DMX_GET_CAPS
-
-Arguments
--
-
-``fd``
-File descriptor returned by :c:func:`open() `.
-
-``caps``
-Pointer to struct :c:type:`dmx_caps`
-
-
-Description

-
-.. note:: This ioctl is undocumented. Documentation is welcome.
-
-Return Value
-
-
-On success 0 is returned, on error -1 and the ``errno`` variable is set
-appropriately. The generic error codes are described at the
-:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/dvb/dmx_fcalls.rst 
b/Documentation/media/uapi/dvb/dmx_fcalls.rst
index 77a1554d9834..49e013d4540f 100644
--- a/Documentation/media/uapi/dvb/dmx_fcalls.rst
+++ b/Documentation/media/uapi/dvb/dmx_fcalls.rst
@@ -21,7 +21,6 @@ Demux Function Calls
 dmx-get-event
 dmx-get-stc
 dmx-get-pes-pids
-dmx-get-caps
 dmx-set-source
 dmx-add-pid
 dmx-remove-pid
diff --git a/Documentation/media/uapi/dvb/dmx_types.rst 
b/Documentation/media/uapi/dvb/dmx_types.rst
index 0f0113205c94..9e907b85cf16 100644
--- a/Documentation/media/uapi/dvb/dmx_types.rst
+++ b/Documentation/media/uapi/dvb/dmx_types.rst
@@ -199,18 +199,6 @@ struct dmx_stc
 };
 
 
-struct dmx_caps
-===
-
-.. c:type:: dmx_caps
-
-.. code-block:: c
-
- typedef struct dmx_caps {
-   __u32 caps;
-   int num_decoders;
-} dmx_caps_t;
-
 
 enum dmx_source
 ===
diff --git a/include/uapi/linux/dvb/dmx.h b/include/uapi/linux/dvb/dmx.h
index d4934e650e6b..c0ee44fbdb13 100644
--- a/include/uapi/linux/dvb/dmx.h
+++ b/include/uapi/linux/dvb/dmx.h
@@ -117,11 +117,6 @@ struct dmx_pes_filter_params
__u32  flags;
 };
 
-typedef struct dmx_caps {
-   __u32 caps;
-   int num_decoders;
-} dmx_caps_t;
-
 typedef enum dmx_source {
DMX_SOURCE_FRONT0 = 0,
DMX_SOURCE_FRONT1,
@@ -145,7 +140,6 @@ struct dmx_stc {
 #define DMX_SET_PES_FILTER   _IOW('o', 44, struct dmx_pes_filter_params)
 #define DMX_SET_BUFFER_SIZE  _IO('o', 45)
 #define DMX_GET_PES_PIDS _IOR('o', 47, __u16[5])
-#define DMX_GET_CAPS _IOR('o', 48, dmx_caps_t)
 #define DMX_SET_SOURCE   _IOW('o', 49, dmx_source_t)
 #define DMX_GET_STC  _IOWR('o', 50, struct dmx_stc)
 #define DMX_ADD_PID  _IOW('o', 51, __u16)
-- 
2.13.5

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

[PATCH 07/15] media: dvb frontend docs: use kernel-doc documentation

[Mauro Carvalho Chehab]

Now that frontend.h contains most documentation for the frontend,
remove the duplicated information from Documentation/ and use the
kernel-doc auto-generated one instead.

That should simplify maintainership of DVB frontend uAPI, as most
of the documentation will stick with the header file.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/frontend.h.rst.exceptions  |  185 ++-
 Documentation/media/uapi/dvb/dtv-fe-stats.rst  |   17 -
 Documentation/media/uapi/dvb/dtv-properties.rst|   15 -
 Documentation/media/uapi/dvb/dtv-property.rst  |   31 -
 Documentation/media/uapi/dvb/dtv-stats.rst |   18 -
 Documentation/media/uapi/dvb/dvbproperty-006.rst   |   12 -
 Documentation/media/uapi/dvb/dvbproperty.rst   |   28 +-
 .../media/uapi/dvb/fe-diseqc-recv-slave-reply.rst  |   40 +-
 .../media/uapi/dvb/fe-diseqc-send-burst.rst|   31 +-
 .../media/uapi/dvb/fe-diseqc-send-master-cmd.rst   |   29 +-
 Documentation/media/uapi/dvb/fe-get-info.rst   |  370 +-
 Documentation/media/uapi/dvb/fe-get-property.rst   |2 +-
 Documentation/media/uapi/dvb/fe-read-status.rst|   83 --
 Documentation/media/uapi/dvb/fe-set-tone.rst   |   30 -
 .../media/uapi/dvb/fe_property_parameters.rst  | 1277 ++--
 Documentation/media/uapi/dvb/frontend-header.rst   |4 +
 include/uapi/linux/dvb/frontend.h  |8 +-
 17 files changed, 317 insertions(+), 1863 deletions(-)
 delete mode 100644 Documentation/media/uapi/dvb/dtv-fe-stats.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-properties.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-property.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-stats.rst
 delete mode 100644 Documentation/media/uapi/dvb/dvbproperty-006.rst
 create mode 100644 Documentation/media/uapi/dvb/frontend-header.rst

diff --git a/Documentation/media/frontend.h.rst.exceptions 
b/Documentation/media/frontend.h.rst.exceptions
index 7656770f1936..f7c4df620a52 100644
--- a/Documentation/media/frontend.h.rst.exceptions
+++ b/Documentation/media/frontend.h.rst.exceptions
@@ -25,19 +25,9 @@ ignore define DTV_MAX_COMMAND
 ignore define MAX_DTV_STATS
 ignore define DTV_IOCTL_MAX_MSGS
 
-# Stats enum is documented altogether
-replace enum fecap_scale_params :ref:`frontend-stat-properties`
-replace symbol FE_SCALE_COUNTER frontend-stat-properties
-replace symbol FE_SCALE_DECIBEL frontend-stat-properties
-replace symbol FE_SCALE_NOT_AVAILABLE frontend-stat-properties
-replace symbol FE_SCALE_RELATIVE frontend-stat-properties
-
 # the same reference is used for both get and set ioctls
 replace ioctl FE_SET_PROPERTY :c:type:`FE_GET_PROPERTY`
 
-# Ignore struct used only internally at Kernel
-ignore struct dtv_cmds_h
-
 # Typedefs that use the enum reference
 replace typedef fe_sec_voltage_t :c:type:`fe_sec_voltage`
 
@@ -45,3 +35,178 @@ replace typedef fe_sec_voltage_t :c:type:`fe_sec_voltage`
 replace define FE_TUNE_MODE_ONESHOT :c:func:`FE_SET_FRONTEND_TUNE_MODE`
 replace define LNA_AUTO dtv-lna
 replace define NO_STREAM_ID_FILTER dtv-stream-id
+
+# Those enums are defined at the frontend.h header, and not externally
+
+ignore symbol FE_IS_STUPID
+ignore symbol FE_CAN_INVERSION_AUTO
+ignore symbol FE_CAN_FEC_1_2
+ignore symbol FE_CAN_FEC_2_3
+ignore symbol FE_CAN_FEC_3_4
+ignore symbol FE_CAN_FEC_4_5
+ignore symbol FE_CAN_FEC_5_6
+ignore symbol FE_CAN_FEC_6_7
+ignore symbol FE_CAN_FEC_7_8
+ignore symbol FE_CAN_FEC_8_9
+ignore symbol FE_CAN_FEC_AUTO
+ignore symbol FE_CAN_QPSK
+ignore symbol FE_CAN_QAM_16
+ignore symbol FE_CAN_QAM_32
+ignore symbol FE_CAN_QAM_64
+ignore symbol FE_CAN_QAM_128
+ignore symbol FE_CAN_QAM_256
+ignore symbol FE_CAN_QAM_AUTO
+ignore symbol FE_CAN_TRANSMISSION_MODE_AUTO
+ignore symbol FE_CAN_BANDWIDTH_AUTO
+ignore symbol FE_CAN_GUARD_INTERVAL_AUTO
+ignore symbol FE_CAN_HIERARCHY_AUTO
+ignore symbol FE_CAN_8VSB
+ignore symbol FE_CAN_16VSB
+ignore symbol FE_HAS_EXTENDED_CAPS
+ignore symbol FE_CAN_MULTISTREAM
+ignore symbol FE_CAN_TURBO_FEC
+ignore symbol FE_CAN_2G_MODULATION
+ignore symbol FE_NEEDS_BENDING
+ignore symbol FE_CAN_RECOVER
+ignore symbol FE_CAN_MUTE_TS
+
+ignore symbol QPSK
+ignore symbol QAM_16
+ignore symbol QAM_32
+ignore symbol QAM_64
+ignore symbol QAM_128
+ignore symbol QAM_256
+ignore symbol QAM_AUTO
+ignore symbol VSB_8
+ignore symbol VSB_16
+ignore symbol PSK_8
+ignore symbol APSK_16
+ignore symbol APSK_32
+ignore symbol DQPSK
+ignore symbol QAM_4_NR
+
+ignore symbol SEC_VOLTAGE_13
+ignore symbol SEC_VOLTAGE_18
+ignore symbol SEC_VOLTAGE_OFF
+
+ignore symbol SEC_TONE_ON
+ignore symbol SEC_TONE_OFF
+
+ignore symbol SEC_MINI_A
+ignore symbol SEC_MINI_B
+
+ignore symbol FE_NONE
+ignore symbol FE_HAS_SIGNAL
+ignore symbol FE_HAS_CARRIER
+ignore symbol FE_HAS_VITERBI
+ignore symbol FE_HAS_SYNC
+ignore symbol FE_HAS_LOCK
+ignore symbol FE_REINIT
+ignore symbol FE_TIMEDOUT
+
+ignore symbol FEC_NONE
+ignore symbol FEC_1_2
+ignore symbol 

[PATCH 06/15] media: dvb/frontend.h: document the uAPI file

[Mauro Carvalho Chehab]

Most of the stuff at the Digital TV frontend header file
are documented only at the Documentation. However, a few
kernel-doc markups are there, several of them with parsing
issues.

Add the missing documentation, copying definitions from the
Documentation when it applies, fixing some bugs.

Please notice that DVBv3 stuff that were deprecated weren't
commented by purpose. Instead, they were clearly tagged as
such.

This patch prepares to move part of the documentation from
Documentation/ to kernel-doc comments.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/uapi/linux/dvb/frontend.h | 578 --
 1 file changed, 496 insertions(+), 82 deletions(-)

diff --git a/include/uapi/linux/dvb/frontend.h 
b/include/uapi/linux/dvb/frontend.h
index 3a80f3d1da1c..c7f2124b7851 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -28,13 +28,46 @@
 
 #include 
 
-enum fe_type {
-   FE_QPSK,
-   FE_QAM,
-   FE_OFDM,
-   FE_ATSC
-};
-
+/**
+ * enum fe_caps - Frontend capabilities
+ *
+ * @FE_IS_STUPID:  There's something wrong at the
+ * frontend, and it can't report its
+ * capabilities.
+ * @FE_CAN_INVERSION_AUTO: Can auto-detect frequency spectral
+ * band inversion
+ * @FE_CAN_FEC_1_2:Supports FEC 1/2
+ * @FE_CAN_FEC_2_3:Supports FEC 2/3
+ * @FE_CAN_FEC_3_4:Supports FEC 3/4
+ * @FE_CAN_FEC_4_5:Supports FEC 4/5
+ * @FE_CAN_FEC_5_6:Supports FEC 5/6
+ * @FE_CAN_FEC_6_7:Supports FEC 6/7
+ * @FE_CAN_FEC_7_8:Supports FEC 7/8
+ * @FE_CAN_FEC_8_9:Supports FEC 8/9
+ * @FE_CAN_FEC_AUTO:   Can auto-detect FEC
+ * @FE_CAN_QPSK:   Supports QPSK modulation
+ * @FE_CAN_QAM_16: Supports 16-QAM modulation
+ * @FE_CAN_QAM_32: Supports 32-QAM modulation
+ * @FE_CAN_QAM_64: Supports 64-QAM modulation
+ * @FE_CAN_QAM_128:Supports 128-QAM modulation
+ * @FE_CAN_QAM_256:Supports 256-QAM modulation
+ * @FE_CAN_QAM_AUTO:   Can auto-detect QAM modulation
+ * @FE_CAN_TRANSMISSION_MODE_AUTO: Can auto-detect transmission mode
+ * @FE_CAN_BANDWIDTH_AUTO: Can auto-detect bandwidth
+ * @FE_CAN_GUARD_INTERVAL_AUTO:Can auto-detect guard interval
+ * @FE_CAN_HIERARCHY_AUTO: Can auto-detect hierarchy
+ * @FE_CAN_8VSB:   Supports 8-VSB modulation
+ * @FE_CAN_16VSB:  Supporta 16-VSB modulation
+ * @FE_HAS_EXTENDED_CAPS:  Unused
+ * @FE_CAN_MULTISTREAM:Supports multistream filtering
+ * @FE_CAN_TURBO_FEC:  Supports "turbo FEC" modulation
+ * @FE_CAN_2G_MODULATION:  Supports "2nd generation" modulation,
+ * e. g. DVB-S2, DVB-T2, DVB-C2
+ * @FE_NEEDS_BENDING:  Unused
+ * @FE_CAN_RECOVER:Can recover from a cable unplug
+ * automatically
+ * @FE_CAN_MUTE_TS:Can stop spurious TS data output
+ */
 enum fe_caps {
FE_IS_STUPID= 0,
FE_CAN_INVERSION_AUTO   = 0x1,
@@ -60,15 +93,47 @@ enum fe_caps {
FE_CAN_HIERARCHY_AUTO   = 0x10,
FE_CAN_8VSB = 0x20,
FE_CAN_16VSB= 0x40,
-   FE_HAS_EXTENDED_CAPS= 0x80,   /* We need more bitspace 
for newer APIs, indicate this. */
-   FE_CAN_MULTISTREAM  = 0x400,  /* frontend supports 
multistream filtering */
-   FE_CAN_TURBO_FEC= 0x800,  /* frontend supports 
"turbo fec modulation" */
-   FE_CAN_2G_MODULATION= 0x1000, /* frontend supports "2nd 
generation modulation" (DVB-S2) */
-   FE_NEEDS_BENDING= 0x2000, /* not supported anymore, 
don't use (frontend requires frequency bending) */
-   FE_CAN_RECOVER  = 0x4000, /* frontend can recover 
from a cable unplug automatically */
-   FE_CAN_MUTE_TS  = 0x8000  /* frontend can stop 
spurious TS data output */
+   FE_HAS_EXTENDED_CAPS= 0x80,
+   FE_CAN_MULTISTREAM  = 0x400,
+   FE_CAN_TURBO_FEC= 0x800,
+   FE_CAN_2G_MODULATION= 0x1000,
+   FE_NEEDS_BENDING= 0x2000,
+   FE_CAN_RECOVER  = 0x4000,
+   FE_CAN_MUTE_TS  = 0x8000
 };
 
+enum fe_type type;
+
+/**
+ * struct dvb_frontend_info - Frontend properties and capabilities
+ *
+ * @name: 

[PATCH 00/15] Improve DVB documentation and reduce its gap

[Mauro Carvalho Chehab]

The DVB documentation was negligected for a long time, with
resulted on several gaps between the API description and its
documentation.

I'm doing a new reading at the documentation. As result of it,
this series:

- improves the introductory chapter, making it more generic;
- Do some adjustments at the frontend API, using kernel-doc
  when possible.
- Remove unused APIs at DVB demux. I suspect that the drivers
  implementing such APIs were either never merged upstream,
  or the API itself  were never used or was deprecated a long
  time ago. In any case, it doesn't make any sense to carry
  on APIs that aren't properly documented, nor are used on the
  upstream Kernel.

With this patch series, the gap between documentation and
code is solved for 3 DVB APIs:

  - Frontend API;
  - Demux API;
  - Net API.

There is still a gap at the CA API that I'll try to address when I
have some time[1].

[1] There's a gap also on the legacy audio, video and OSD APIs,
but, as those are used only by a single very old deprecated
hardware (av7110), it is probably not worth the efforts.

Mauro Carvalho Chehab (15):
  media: dvb/intro: use the term Digital TV to refer to the system
  media: dvb/intro: update references for TV standards
  media: dvb/intro: update the history part of the document
  media: dvb/intro: adjust the notices about optional hardware
  media: dvb/frontend.h: move out a private internal structure
  media: dvb/frontend.h: document the uAPI file
  media: dvb frontend docs: use kernel-doc documentation
  media: fe_property_parameters.rst: better define properties usage
  media: fe_property_parameters.rst: better document bandwidth
  media: dmx.h: get rid of unused DMX_KERNEL_CLIENT
  media: dmx.h: get rid of DMX_GET_CAPS
  media: dmx.h: get rid of DMX_SET_SOURCE
  media: dmx.h: get rid of GET_DMX_EVENT
  media: dmx.h: add kernel-doc markups and use it at Documentation/
  media: net.rst: Fix the level of a section of the net chapter

 Documentation/media/dmx.h.rst.exceptions   |   20 +-
 Documentation/media/frontend.h.rst.exceptions  |  185 ++-
 Documentation/media/uapi/dvb/dmx-get-caps.rst  |   41 -
 Documentation/media/uapi/dvb/dmx-get-event.rst |   60 -
 Documentation/media/uapi/dvb/dmx-set-source.rst|   44 -
 Documentation/media/uapi/dvb/dmx_fcalls.rst|3 -
 Documentation/media/uapi/dvb/dmx_types.rst |  225 +---
 Documentation/media/uapi/dvb/dtv-fe-stats.rst  |   17 -
 Documentation/media/uapi/dvb/dtv-properties.rst|   15 -
 Documentation/media/uapi/dvb/dtv-property.rst  |   31 -
 Documentation/media/uapi/dvb/dtv-stats.rst |   18 -
 Documentation/media/uapi/dvb/dvbproperty-006.rst   |   12 -
 Documentation/media/uapi/dvb/dvbproperty.rst   |   28 +-
 .../media/uapi/dvb/fe-diseqc-recv-slave-reply.rst  |   40 +-
 .../media/uapi/dvb/fe-diseqc-send-burst.rst|   31 +-
 .../media/uapi/dvb/fe-diseqc-send-master-cmd.rst   |   29 +-
 Documentation/media/uapi/dvb/fe-get-info.rst   |  370 +-
 Documentation/media/uapi/dvb/fe-get-property.rst   |2 +-
 Documentation/media/uapi/dvb/fe-read-status.rst|   83 --
 Documentation/media/uapi/dvb/fe-set-tone.rst   |   30 -
 .../media/uapi/dvb/fe_property_parameters.rst  | 1383 +++-
 Documentation/media/uapi/dvb/frontend-header.rst   |4 +
 Documentation/media/uapi/dvb/intro.rst |   76 +-
 Documentation/media/uapi/dvb/net.rst   |1 -
 drivers/media/dvb-core/dvb_frontend.c  |   11 +
 include/uapi/linux/dvb/dmx.h   |  171 ++-
 include/uapi/linux/dvb/frontend.h  |  589 +++--
 27 files changed, 1082 insertions(+), 2437 deletions(-)
 delete mode 100644 Documentation/media/uapi/dvb/dmx-get-caps.rst
 delete mode 100644 Documentation/media/uapi/dvb/dmx-get-event.rst
 delete mode 100644 Documentation/media/uapi/dvb/dmx-set-source.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-fe-stats.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-properties.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-property.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-stats.rst
 delete mode 100644 Documentation/media/uapi/dvb/dvbproperty-006.rst
 create mode 100644 Documentation/media/uapi/dvb/frontend-header.rst

-- 
2.13.5


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

[PATCH 13/15] media: dmx.h: get rid of GET_DMX_EVENT

[Mauro Carvalho Chehab]

This seems to be a pure fictional API :-)

It only exists at the DVB book, with no code implemeting it.

So, just get rid of it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/dmx-get-event.rst | 60 --
 Documentation/media/uapi/dvb/dmx_fcalls.rst|  1 -
 Documentation/media/uapi/dvb/dmx_types.rst | 19 
 3 files changed, 80 deletions(-)
 delete mode 100644 Documentation/media/uapi/dvb/dmx-get-event.rst

diff --git a/Documentation/media/uapi/dvb/dmx-get-event.rst 
b/Documentation/media/uapi/dvb/dmx-get-event.rst
deleted file mode 100644
index 8be626c29158..
--- a/Documentation/media/uapi/dvb/dmx-get-event.rst
+++ /dev/null
@@ -1,60 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _DMX_GET_EVENT:
-
-=
-DMX_GET_EVENT
-=
-
-Name
-
-
-DMX_GET_EVENT
-
-
-Synopsis
-
-
-.. c:function:: int ioctl( int fd, DMX_GET_EVENT, struct dmx_event *ev)
-:name: DMX_GET_EVENT
-
-
-Arguments
--
-
-``fd``
-File descriptor returned by :c:func:`open() `.
-
-``ev``
-Pointer to the location where the event is to be stored.
-
-
-Description

-
-This ioctl call returns an event if available. If an event is not
-available, the behavior depends on whether the device is in blocking or
-non-blocking mode. In the latter case, the call fails immediately with
-errno set to ``EWOULDBLOCK``. In the former case, the call blocks until an
-event becomes available.
-
-
-Return Value
-
-
-On success 0 is returned, on error -1 and the ``errno`` variable is set
-appropriately. The generic error codes are described at the
-:ref:`Generic Error Codes ` chapter.
-
-
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  ``EWOULDBLOCK``
-
-   -  There is no event pending, and the device is in non-blocking mode.
diff --git a/Documentation/media/uapi/dvb/dmx_fcalls.rst 
b/Documentation/media/uapi/dvb/dmx_fcalls.rst
index be98d60877f2..a17289143220 100644
--- a/Documentation/media/uapi/dvb/dmx_fcalls.rst
+++ b/Documentation/media/uapi/dvb/dmx_fcalls.rst
@@ -18,7 +18,6 @@ Demux Function Calls
 dmx-set-filter
 dmx-set-pes-filter
 dmx-set-buffer-size
-dmx-get-event
 dmx-get-stc
 dmx-get-pes-pids
 dmx-add-pid
diff --git a/Documentation/media/uapi/dvb/dmx_types.rst 
b/Documentation/media/uapi/dvb/dmx_types.rst
index a205c02ccdc1..171205ed86a4 100644
--- a/Documentation/media/uapi/dvb/dmx_types.rst
+++ b/Documentation/media/uapi/dvb/dmx_types.rst
@@ -166,25 +166,6 @@ struct dmx_pes_filter_params
__u32  flags;
 };
 
-
-struct dmx_event
-
-
-.. c:type:: dmx_event
-
-.. code-block:: c
-
- struct dmx_event
- {
-dmx_event_t  event;
-time_t   timeStamp;
-union
-{
-dmx_scrambling_status_t scrambling;
-} u;
- };
-
-
 struct dmx_stc
 ==
 
-- 
2.13.5

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

[PATCH 09/15] media: fe_property_parameters.rst: better document bandwidth

[Mauro Carvalho Chehab]

Use a table to document the supported bandwidths. That makes
it clearer to readers.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/dvb/fe_property_parameters.rst  | 44 +-
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/Documentation/media/uapi/dvb/fe_property_parameters.rst 
b/Documentation/media/uapi/dvb/fe_property_parameters.rst
index e085e84fef38..49470f7dda02 100644
--- a/Documentation/media/uapi/dvb/fe_property_parameters.rst
+++ b/Documentation/media/uapi/dvb/fe_property_parameters.rst
@@ -116,30 +116,38 @@ Should be set only for terrestrial delivery systems.
 Possible values: ``1712000``, ``500``, ``600``, ``700``,
 ``800``, ``1000``.
 
+=== ===
+Terrestrial Standard   Possible values for bandwidth
+=== ===
+ATSC (version 1)   No need to set. It is always 6MHz.
+DMTB   No need to set. It is always 8MHz.
+DVB-T  6MHz, 7MHz and 8MHz.
+DVB-T2 1.172 MHz, 5MHz, 6MHz, 7MHz, 8MHz and 10MHz
+ISDB-T 5MHz, 6MHz, 7MHz and 8MHz, although most places
+   use 6MHz.
+=== ===
+
+
 .. note::
 
-  #. DVB-T supports 6, 7 and 8MHz.
 
-  #. DVB-T2 supports 1.172, 5, 6, 7, 8 and 10MHz.
+  #. For ISDB-Tsb, the bandwidth can vary depending on the number of
+ connected segments.
 
-  #. ISDB-T supports 5MHz, 6MHz, 7MHz and 8MHz, although most
- places use 6MHz.
-
-  #. On DVB-C and DVB-S/S2, the bandwidth depends on the symbol rate.
- So, the Kernel will silently ignore setting :ref:`DTV-BANDWIDTH-HZ`.
-
-  #. For DVB-C and DVB-S/S2, the Kernel will return an estimation of the
- bandwidth, calculated from :ref:`DTV-SYMBOL-RATE` and from
- the rolloff, with is fixed for DVB-C and DVB-S.
-
-  #. For DVB-S2, the bandwidth estimation will use :ref:`DTV-ROLLOFF`.
-
-  #. For ISDB-Tsb, it can vary depending on the number of connected
- segments.
-
-  #. Bandwidth in ISDB-Tsb can be easily derived from other parameters
+ It can be easily derived from other parameters
  (DTV_ISDBT_SB_SEGMENT_IDX, DTV_ISDBT_SB_SEGMENT_COUNT).
 
+  #. On Satellite and Cable delivery systems, the bandwidth depends on
+ the symbol rate. So, the Kernel will silently ignore any setting
+ :ref:`DTV-BANDWIDTH-HZ`. I will however fill it back with a
+ bandwidth estimation.
+
+ Such bandwidth estimation takes into account the symbol rate set with
+ :ref:`DTV-SYMBOL-RATE`, and the rolloff factor, with is fixed for
+ DVB-C and DVB-S.
+
+ For DVB-S2, the rolloff should also be set via :ref:`DTV-ROLLOFF`.
+
 
 .. _DTV-INVERSION:
 
-- 
2.13.5

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

[PATCH 05/15] media: dvb/frontend.h: move out a private internal structure

[Mauro Carvalho Chehab]

struct dtv_cmds_h is just an ancillary struct used by the
dvb_frontend.c to internally store frontend commands.

It doesn't belong to the userspace header, nor it is used anywhere,
except inside the DVB core. So, remove it from the header.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_frontend.c | 11 +++
 include/uapi/linux/dvb/frontend.h | 11 ---
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 114994ca0929..2fcba1616168 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -1000,6 +1000,17 @@ static int dvb_frontend_clear_cache(struct dvb_frontend 
*fe)
.buffer = b \
 }
 
+struct dtv_cmds_h {
+   char*name;  /* A display name for debugging purposes */
+
+   __u32   cmd;/* A unique ID */
+
+   /* Flags */
+   __u32   set:1;  /* Either a set or get property */
+   __u32   buffer:1;   /* Does this property use the buffer? */
+   __u32   reserved:30;/* Align */
+};
+
 static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_TUNE, 1, 0),
_DTV_CMD(DTV_CLEAR, 1, 0),
diff --git a/include/uapi/linux/dvb/frontend.h 
b/include/uapi/linux/dvb/frontend.h
index afc3972b0879..3a80f3d1da1c 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -384,17 +384,6 @@ enum atscmh_rs_code_mode {
 #define NO_STREAM_ID_FILTER(~0U)
 #define LNA_AUTO(~0U)
 
-struct dtv_cmds_h {
-   char*name;  /* A display name for debugging purposes */
-
-   __u32   cmd;/* A unique ID */
-
-   /* Flags */
-   __u32   set:1;  /* Either a set or get property */
-   __u32   buffer:1;   /* Does this property use the buffer? */
-   __u32   reserved:30;/* Align */
-};
-
 /**
  * Scale types for the quality parameters.
  * @FE_SCALE_NOT_AVAILABLE: That QoS measure is not available. That
-- 
2.13.5

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

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

[Rob Herring]

On Thu, Aug 31, 2017 at 3:17 PM, Jacek Anaszewski
 wrote:
> Hi,
>
> On 08/31/2017 10:09 AM, Pavel Machek wrote:
>> On Wed 2017-08-30 22:44:00, Jacek Anaszewski wrote:
>>> Hi,
>>>
>>> On 08/29/2017 10:38 PM, Pavel Machek wrote:
 Hi!

>> -As a specific example of this use-case, let's look at vibrate feature on
>> -phones. Vibrate function on phones is implemented using PWM pins on SoC 
>> or
>> -PMIC. There is a need to activate one shot timer to control the vibrate
>> -feature, to prevent user space crashes leaving the phone in vibrate mode
>> -permanently causing the battery to drain.
>
> I'm not sure if it is a good idea to remove this description. Users will
> still be able to use transient trigger this way. It has been around for
> five years already and there are users which employ it in this
> particular way [0].
>>
>> Actually, I checked, and no ARM mainline board does that.
>
> There might be user space clients like the Android one [0].

I don't think there is much to worry about there. Unfortunately,
Android is still pretty detached from mainline. Or to put it another
way, this is the least of the problems. We removed timed-gpio which if
anyone had a fixed Android userspace (and tracked mainline) that would
have broken them.

And you're not going to break me, because in fact I have no h/w with a
vibrator and tested all this with an LED and hacks to the DT.

 I am. Yes, people were doing that, but no, vibration motor is not a
 LED. PWM behaviour is different, for example, motor is likely to stop
 at low PWM values. We do not want people to do that.
>>>
>>> Could you elaborate on how it can be harmful?
>>
>> Well, you can safely route low current to the LEDs. What will it to do
>> vibration motor, if you leave it on forever? Can the motor safely be
>> run forever on high current? Not sure.
>
> It's actually one of the main advantages of the "transient" trigger -
> you have to re-activate it after the end of each transition cycle,
>
> If you execute the following sequence of commands, then you're getting
> 1s blink every 3s as long as the while loop is iterating. If you break
> the loop the LED output state will be always brought down after the
> duration period, No risk that output will be left in the high state
> unless transient state was deliberately set to 0.
>
> # echo 1 > state
> # echo 1000 > duration
> # while [ 1 ] ;do echo 1 > activate ; sleep 3; done
>
>
>>> I really don't see any merit in removing this from documentation.
>>
>> There's right API to use for vibrations, and that's force-feedback
>> support in input/. Not here.
>
> Is is as easy to use as this one? It seems that it requires an application
> to call ioctl's.
>
>>> You can convince me by collecting some acks from involved people.
>>> I'd like to especially see Rob's opinion. Adding Rob to this thread.
>>
>> Rob is device tree maintainer. This has little to do with device tree.

Is that all I'm known for? My path of destruction is much wider.

It does affect DT though as we're changing the binding based on what
subsystem we use. Or more accurately, describing as an LED was a
shortcut using an existing binding and perhaps the wrong choice.

> I added him because his is the author of the Android patch [0], that
> mentions using transient trigger for the LED device named "vibrator".

IIRC, the transient trigger was added in the first place for the
vibrator usecase.

> Apart from that it's the only documented kernel API for vibrate devices
> AFAICT.

 Input subsystem has force-feedback protocol, which is very often just
 vibrations. Documentation/input/ff.rst . Nokia N900 phone actually
 uses that API.
>>>
>>> Word "vibration" doesn't appear there, so what this patch does
>>> is remove explicit advertisement of kernel support for vibrate
>>> devices without redirecting people to the replacement.
>>
>> Well... this is LED documentation. If there's other documentation
>> missing somewhere else... we can fix it :-).
>
> We can fix it, but not necessarily remove the valuable information
> from this one :-)

Beyond documentation, using a GPIO or PWM (or GPIO as a PWM) works
today for at least simple vibrator control (in particular, anyone that
used the timed-gpio Android driver). The force-feedback protocol
should at least support that h/w before we steer folks away from it.

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

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

[Jacek Anaszewski]

Hi,

On 08/31/2017 10:09 AM, Pavel Machek wrote:
> On Wed 2017-08-30 22:44:00, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 08/29/2017 10:38 PM, Pavel Machek wrote:
>>> Hi!
>>>
> -As a specific example of this use-case, let's look at vibrate feature on
> -phones. Vibrate function on phones is implemented using PWM pins on SoC 
> or
> -PMIC. There is a need to activate one shot timer to control the vibrate
> -feature, to prevent user space crashes leaving the phone in vibrate mode
> -permanently causing the battery to drain.

 I'm not sure if it is a good idea to remove this description. Users will
 still be able to use transient trigger this way. It has been around for
 five years already and there are users which employ it in this
 particular way [0].
> 
> Actually, I checked, and no ARM mainline board does that.

There might be user space clients like the Android one [0].

>>> I am. Yes, people were doing that, but no, vibration motor is not a
>>> LED. PWM behaviour is different, for example, motor is likely to stop
>>> at low PWM values. We do not want people to do that.
>>
>> Could you elaborate on how it can be harmful?
> 
> Well, you can safely route low current to the LEDs. What will it to do
> vibration motor, if you leave it on forever? Can the motor safely be
> run forever on high current? Not sure.

It's actually one of the main advantages of the "transient" trigger -
you have to re-activate it after the end of each transition cycle,

If you execute the following sequence of commands, then you're getting
1s blink every 3s as long as the while loop is iterating. If you break
the loop the LED output state will be always brought down after the
duration period, No risk that output will be left in the high state
unless transient state was deliberately set to 0.

# echo 1 > state
# echo 1000 > duration
# while [ 1 ] ;do echo 1 > activate ; sleep 3; done


>> I really don't see any merit in removing this from documentation.
> 
> There's right API to use for vibrations, and that's force-feedback
> support in input/. Not here.

Is is as easy to use as this one? It seems that it requires an application
to call ioctl's.

>> You can convince me by collecting some acks from involved people.
>> I'd like to especially see Rob's opinion. Adding Rob to this thread.
> 
> Rob is device tree maintainer. This has little to do with device tree.

I added him because his is the author of the Android patch [0], that
mentions using transient trigger for the LED device named "vibrator".

 Apart from that it's the only documented kernel API for vibrate devices
 AFAICT.
>>>
>>> Input subsystem has force-feedback protocol, which is very often just
>>> vibrations. Documentation/input/ff.rst . Nokia N900 phone actually
>>> uses that API.
>>
>> Word "vibration" doesn't appear there, so what this patch does
>> is remove explicit advertisement of kernel support for vibrate
>> devices without redirecting people to the replacement.
> 
> Well... this is LED documentation. If there's other documentation
> missing somewhere else... we can fix it :-).

We can fix it, but not necessarily remove the valuable information
from this one :-)

[0]
https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9

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

Re: [v6 2/4] mm, oom: cgroup-aware OOM killer

[David Rientjes]

On Thu, 31 Aug 2017, Roman Gushchin wrote:

> So, it looks to me that we're close to an acceptable version,
> and the only remaining question is the default behavior
> (when oom_group is not set).
> 

Nit: without knowledge of the implementation, I still don't think I would 
know what an "out of memory group" is.  Out of memory doesn't necessarily 
imply a kill.  I suggest oom_kill_all or something that includes the verb.

> Michal suggests to ignore non-oom_group memcgs, and compare tasks with
> memcgs with oom_group set. This makes the whole thing completely opt-in,
> but then we probably need another knob (or value) to select between
> "select memcg, kill biggest task" and "select memcg, kill all tasks".

It seems like that would either bias toward or bias against cgroups that 
opt-in.  I suggest comparing memory cgroups at each level in the hierarchy 
based on your new badness heuristic, regardless of any tunables it has 
enabled.  Then kill either the largest process or all the processes 
attached depending on oom_group or oom_kill_all.

> Also, as the whole thing is based on comparison between processes and
> memcgs, we probably need oom_priority for processes.

I think with the constraints of cgroup v2 that a victim memcg must first 
be chosen, and then a victim process attached to that memcg must be chosen 
or all eligible processes attached to it be killed, depending on the 
tunable.

The simplest and most clear way to define this, in my opinion, is to 
implement a heuristic that compares sibling memcgs based on usage, as you 
have done.  This can be overridden by a memory.oom_priority that userspace 
defines, and is enough support for them to change victim selection (no 
mount option needed, just set memory.oom_priority).  Then kill the largest 
process or all eligible processes attached.  We only use per-process 
priority to override process selection compared to sibling memcgs, but 
with cgroup v2 process constraints it doesn't seem like that is within the 
scope of your patchset.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/sphinx: fix kernel-doc decode for non-utf-8 locale

[Jonathan Corbet]

On Thu, 31 Aug 2017 22:21:29 +0300
Jani Nikula  wrote:

> On python3, Popen() universal_newlines=True converts the subprocess
> stdout to unicode text using a codec based on user preferences. Given
> LANG indicating ascii and utf-8 stdout from the subprocess, you'd get:
> 
> WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno
> ../drivers/media/dvb-core/demux.h' processing failed with: 'ascii' codec can't
> decode byte 0xe2 in position 6368: ordinal not in range(128)
> 
> Fix this by dropping universal_newlines=True and replacing the implicit
> LANG specific decode with an explicit utf-8 decode. This also gets rid
> of the annoying conditional code for python 2 vs. 3.
> 
> Fixes: ba3501859354 ("Documentation/sphinx: fix kernel-doc extension on 
> python3")
> Reference: 
> 54c23e8e-89c0-5cea-0dcc-e938952c5642@infradead.org">http://mid.mail-archive.com/54c23e8e-89c0-5cea-0dcc-e938952c5642@infradead.org
> Reported-and-tested-by: Randy Dunlap 
> Cc: Jonathan Corbet 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Jani Nikula 

Cool...I go out to run some errands and the problem's fixed! :)

Patch applied, thanks to everybody for figuring this out.

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

[PATCH] Documentation/sphinx: fix kernel-doc decode for non-utf-8 locale

[Jani Nikula]

On python3, Popen() universal_newlines=True converts the subprocess
stdout to unicode text using a codec based on user preferences. Given
LANG indicating ascii and utf-8 stdout from the subprocess, you'd get:

WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno
../drivers/media/dvb-core/demux.h' processing failed with: 'ascii' codec can't
decode byte 0xe2 in position 6368: ordinal not in range(128)

Fix this by dropping universal_newlines=True and replacing the implicit
LANG specific decode with an explicit utf-8 decode. This also gets rid
of the annoying conditional code for python 2 vs. 3.

Fixes: ba3501859354 ("Documentation/sphinx: fix kernel-doc extension on 
python3")
Reference: 
54c23e8e-89c0-5cea-0dcc-e938952c5642@infradead.org">http://mid.mail-archive.com/54c23e8e-89c0-5cea-0dcc-e938952c5642@infradead.org
Reported-and-tested-by: Randy Dunlap 
Cc: Jonathan Corbet 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Jani Nikula 
---
 Documentation/sphinx/kerneldoc.py | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/Documentation/sphinx/kerneldoc.py 
b/Documentation/sphinx/kerneldoc.py
index d15e07f36881..39aa9e8697cc 100644
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -27,6 +27,7 @@
 # Please make sure this works on both python2 and python3.
 #
 
+import codecs
 import os
 import subprocess
 import sys
@@ -88,13 +89,10 @@ class KernelDocDirective(Directive):
 try:
 env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
 
-p = subprocess.Popen(cmd, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE, universal_newlines=True)
+p = subprocess.Popen(cmd, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)
 out, err = p.communicate()
 
-# python2 needs conversion to unicode.
-# python3 with universal_newlines=True returns strings.
-if sys.version_info.major < 3:
-out, err = unicode(out, 'utf-8'), unicode(err, 'utf-8')
+out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
 
 if p.returncode != 0:
 sys.stderr.write(err)
-- 
2.11.0

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

Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption

[Eric Biggers]

On Mon, Aug 28, 2017 at 08:18:55PM +0800, Anand Jain wrote:
> 
> 
> On 08/23/2017 01:36 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 11:35:20PM +0800, Anand Jain wrote:
> 
>    I think AE is the only good solution for this, File-name encryption at
> this stage won't solve any kind of Evil Maid attack, (as it was quoted
> somewhere else in ML).
> 
> 
>   Further, below,  is define but not used.
> -
>   #define FS_AES_256_GCM_KEY_SIZE 32
> -
> 
> >>>
> >>>Yes, authenticated encryption with AES-256-GCM was in an older version of 
> >>>the
> >>>ext4 encryption design document.  But unfortunately it was never really 
> >>>thought
> >>>through. The primary problem, even ignoring rollback protection, is that 
> >>>there
> >>>is nowhere to store the per-block metadata (GCM authentication tag and IV) 
> >>>*and*
> >>>have it updated atomicly with the block contents.  Recently, dm-integrity 
> >>>solves
> >>>this at the block device layer, but it uses data journaling which is very
> >>>inefficient.  This maybe could be implemented more efficiently on a COW
> >>>filesystem like BTRFS.  But even after that, another problem is that
> >>>authenticated encryption of file contents only would not stop an attacker 
> >>>from
> >>>swapping around blocks, files, directories, or creating links, etc.
> >>
> >>
> >>  Some of the problems to be solved in this area are quite
> >>interesting and challenging and IMO BTRFS fits nicely. Per extent AE
> >>for BTRFS is drafted, it needs scrutiny and constructive feedback.
> >>
> >>Thanks, Anand
> >>
> >>
> >>>Eric
> >>>
> >
> >Where is the code?  Is there a design document, and it is it readable by 
> >people
> >not as familiar with btrfs?  Is the API compatible with ext4, f2fs, and 
> >ubifs?
> >
> >Eric
> 
>  (sorry for the delay in replay due to my vacation).
> 
>  Eric, No code yet, proposed encryption method is seeking review.
> Link sent to you.
> 
> Thanks, Anand

Thanks, I'll review it when I have time.  Can you please consider sending out a
public link to linux-fscrypt, linux-fsdevel, linux-btrfs, etc. so that other
people can review it too?

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

Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption

[Eric Biggers]

Hi Anand,

On Tue, Aug 29, 2017 at 11:54:47AM +0800, Anand Jain wrote:
> 
>  BTRFS has an experimental fscrypt implementation[1] which does not
> include the file-name encryption part it should be included but as
> an optional since not all uses cases saves sensitive information in
> the file-name. OR even if the attacker is able to identify a file
> called secrete.txt and break it then its still points at the
> weakness of the file-data encryption. Can we say that ? apparently
> from the discussion here it seems the answer is yes.
> 

Filenames by themselves can be sensitive information, since a filename can serve
as a strong indicator of what a file is.  For example, a filename could be used
as evidence that a person had access to a certain document.

> >Hence, making the encryption of the filenames optional doesn't just to
> >make life easier for backup/restore isn't a compelling argument, since
> >the backup/restore program is going to have to have special case
> >handling for fscrypt protected file systems *anyway*.
> 
>  fscrypt backup and restore does not work even without file-name
> encryption because the Extended Attribute needs special ioctl in the
> fscrypt (I did rise this objection before).
> 
>  But its entirely possible to create a string based encryption
> metadata which can be updated/retrieved using the legacy backup
> tools such as
> 
>   rsync --xattrs
> 
>  That will be a design for fscryptv2 probably..
> 
>  OR I mean to say possible optional file-name encryption is not the
> ground reason for the encrypted backup and restore challenge.
> 

This was already discussed.  You cannot simply add and remove the encryption
xattr from random files and directories; what happens to all the open file
descriptors, memory maps, pagecache pages, dcache entries, etc.?  Are the
existing contents and directory entries supposed to be left unencrypted, or are
they supposed to be already encrypted, or is the filesystem supposed to
automatically encrypt them when the xattr is set?  What about when the xattr is
removed?  Again, you're of course free to propose a design which takes into
account all of this and makes the argument for adding an xattr-based API, but I
haven't seen it yet.

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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/31/17 10:55, Jani Nikula wrote:
> On Thu, 31 Aug 2017, Randy Dunlap  wrote:
>> On 08/31/17 09:36, Jani Nikula wrote:
>>> On Thu, 31 Aug 2017, Jani Nikula  wrote:
 On Thu, 31 Aug 2017, Randy Dunlap  wrote:
> On 08/31/17 07:17, Jonathan Corbet wrote:
>> On Thu, 31 Aug 2017 10:56:26 -0300
>> Mauro Carvalho Chehab  wrote:
>>
>>> It should have something to do with python version and/or to some
>>> locale info at the system, as neither I or Jon can reproduce it.
>>
>> I can't reproduce it here, but I have certainly seen situations where
>> Python 2 wants to run with the ascii codec by default.
>>
>> Note that the exception happens in our Sphinx extension, not in Sphinx
>> itself.  We've had other non-ascii text in our docs, so I think Sphinx is
>> doing the right thing.  The problem is with our own code.  If I could
>> reproduce it, it shouldn't be too hard to track down - take out that
>> massive "except anything" block and see where it explodes.
>>
>> Randy, which distribution are you running, and are you using their 
>> version
>> of Sphinx?
>
> opensuse LEAP 42.2
> Yes, their sphinx 1.3.1.

 What's your LANG setting? I think that's what it boils down to, and
 trying to work around non-UTF-8 LANG in both python 2 and 3 compatible
 ways.

 The odd thing is that I can reproduce the issue using a small python
 snippet, but not through Sphinx.
>>>
>>> Your original error message suggests your Sphinx actually uses python
>>> 3. Can you check that? The clue is that it's the *decode* that fails.
>>
>> Where do you see that clue?
> 
> The message, "'ascii' codec can't decode byte 0xe2 in position 6368:
> ordinal not in range(128)". In my testing I could only get that *decode*
> error message using python 3.
> 
>> My /usr/bin/python is linked to python2.7:
>>
>>> ll /usr/bin/python
>> lrwxrwxrwx 1 root root 9 Jun 10 19:59 /usr/bin/python -> python2.7*
> 
> Sure, but how about 'head $(which sphinx-build)'?

You are correct:

#!/usr/bin/python3

> I could be completely mistaken too. ;)


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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Jani Nikula]

On Thu, 31 Aug 2017, Randy Dunlap  wrote:
> On 08/31/17 09:36, Jani Nikula wrote:
>> On Thu, 31 Aug 2017, Jani Nikula  wrote:
>>> On Thu, 31 Aug 2017, Randy Dunlap  wrote:
 On 08/31/17 07:17, Jonathan Corbet wrote:
> On Thu, 31 Aug 2017 10:56:26 -0300
> Mauro Carvalho Chehab  wrote:
>
>> It should have something to do with python version and/or to some
>> locale info at the system, as neither I or Jon can reproduce it.
>
> I can't reproduce it here, but I have certainly seen situations where
> Python 2 wants to run with the ascii codec by default.
>
> Note that the exception happens in our Sphinx extension, not in Sphinx
> itself.  We've had other non-ascii text in our docs, so I think Sphinx is
> doing the right thing.  The problem is with our own code.  If I could
> reproduce it, it shouldn't be too hard to track down - take out that
> massive "except anything" block and see where it explodes.
>
> Randy, which distribution are you running, and are you using their version
> of Sphinx?

 opensuse LEAP 42.2
 Yes, their sphinx 1.3.1.
>>>
>>> What's your LANG setting? I think that's what it boils down to, and
>>> trying to work around non-UTF-8 LANG in both python 2 and 3 compatible
>>> ways.
>>>
>>> The odd thing is that I can reproduce the issue using a small python
>>> snippet, but not through Sphinx.
>> 
>> Your original error message suggests your Sphinx actually uses python
>> 3. Can you check that? The clue is that it's the *decode* that fails.
>
> Where do you see that clue?

The message, "'ascii' codec can't decode byte 0xe2 in position 6368:
ordinal not in range(128)". In my testing I could only get that *decode*
error message using python 3.

> My /usr/bin/python is linked to python2.7:
>
>> ll /usr/bin/python
> lrwxrwxrwx 1 root root 9 Jun 10 19:59 /usr/bin/python -> python2.7*

Sure, but how about 'head $(which sphinx-build)'?

I could be completely mistaken too. ;)

>> Does the below patch help? It avoids the implicit ascii decoding due to
>> universal_newlines=True and your LANG setting, and does explicit utf-8
>> decoding instead.
>> 
>> Fingers crossed.
>
> testing now.

Thanks.

BR,
Jani.

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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/31/17 10:34, Randy Dunlap wrote:
> On 08/31/17 09:36, Jani Nikula wrote:
>> On Thu, 31 Aug 2017, Jani Nikula  wrote:
>>> On Thu, 31 Aug 2017, Randy Dunlap  wrote:
 On 08/31/17 07:17, Jonathan Corbet wrote:
> On Thu, 31 Aug 2017 10:56:26 -0300
> Mauro Carvalho Chehab  wrote:
>
>> It should have something to do with python version and/or to some
>> locale info at the system, as neither I or Jon can reproduce it.
>
> I can't reproduce it here, but I have certainly seen situations where
> Python 2 wants to run with the ascii codec by default.
>
> Note that the exception happens in our Sphinx extension, not in Sphinx
> itself.  We've had other non-ascii text in our docs, so I think Sphinx is
> doing the right thing.  The problem is with our own code.  If I could
> reproduce it, it shouldn't be too hard to track down - take out that
> massive "except anything" block and see where it explodes.
>
> Randy, which distribution are you running, and are you using their version
> of Sphinx?

 opensuse LEAP 42.2
 Yes, their sphinx 1.3.1.
>>>
>>> What's your LANG setting? I think that's what it boils down to, and
>>> trying to work around non-UTF-8 LANG in both python 2 and 3 compatible
>>> ways.
>>>
>>> The odd thing is that I can reproduce the issue using a small python
>>> snippet, but not through Sphinx.
>>
>> Your original error message suggests your Sphinx actually uses python
>> 3. Can you check that? The clue is that it's the *decode* that fails.
> 
> Where do you see that clue?
> My /usr/bin/python is linked to python2.7:
> 
>> ll /usr/bin/python
> lrwxrwxrwx 1 root root 9 Jun 10 19:59 /usr/bin/python -> python2.7*
> 
>> Does the below patch help? It avoids the implicit ascii decoding due to
>> universal_newlines=True and your LANG setting, and does explicit utf-8
>> decoding instead.
>>
>> Fingers crossed.
> 
> testing now.

Yes, that works for me.  Thanks.

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

Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption

[Eric Biggers]

Hi Anand,

On Mon, Aug 28, 2017 at 08:18:46PM +0800, Anand Jain wrote:
> 
> 
> On 08/23/2017 01:07 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote:
> >>
> >>
> >>On 08/22/2017 10:55 AM, Eric Biggers wrote:
> >>>On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
> 
> Hi Eric,
> 
>    How about a section on the threat model specific to the file-name ?
> 
>    (Sorry if I am missing something).
> 
> Thanks, Anand
> >>>
> >>>It's already mentioned that filenames are encrypted: "fscrypt protects the
> >>>confidentiality of file contents and filenames in the event of a single
> >>>point-in-time permanent offline compromise of the block device content."
> >>>There's not much more to it than that; all the other points in the "Threat
> >>>model" section (offline manipulations, timing attacks, access control, key
> >>>eviction, etc.) are essentially the same between contents and filenames
> >>>encryption.
> >>
> >>  Do you think if application does not keep the sensitive information
> >>in the file-name, would that remove the file-name from the list of
> >>items that should be protected ?
> >>
> >
> >If *no* applications care whether the filenames are encrypted or not, sure.
> >But are you absolutely sure that no applications care?  How do you know?  
> >And what
> >is the advantage of not encrypting the filenames anyway?  It is better to
> >encrypt by default.
> >
> >Eric
> 
>  (sorry for the delay in reply due to my vacation).
> 
>  It all depends on the use case, Android is one such use case. Some
> data center use a known set of application. Again it all depends on
> the use case.
> 
>  File-name is a kind of File-system semantic and altering based on
> the on the user key context does not guarantee the system will be
> compatible with all their legacy applications.
> 

You really need to give more detail about why filename encryption specifically
is a problem.  What "legacy applications" is a problem for, and why?  What do
you mean by a "data center" use case?  Isn't contents encryption a "problem" for
some "legacy applications" as well?  Contents encryption changes filesystem
semantics as well.

>  Also a section on backup and restore in this doc will be a good
> idea. As I think that will be affected IMO. And needing to have the
> user master key to restore encrypted file isn't practical in some
> data center multi tenanted solutions. Albeit it may work in some
> cases but hard to generalize.
> 

The proposed documentation already mentions that there is no way to backup the
raw ciphertext currently.  I'll try to make this a bit clearer, but in any case
I am documenting the current state of things; the new documentation file is
*not* a plan for things that don't exist yet.  If/when someone proposes a
patchset which adds a backup+restore API they can propose a documentation update
along with it.

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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/31/17 09:36, Jani Nikula wrote:
> On Thu, 31 Aug 2017, Jani Nikula  wrote:
>> On Thu, 31 Aug 2017, Randy Dunlap  wrote:
>>> On 08/31/17 07:17, Jonathan Corbet wrote:
 On Thu, 31 Aug 2017 10:56:26 -0300
 Mauro Carvalho Chehab  wrote:

> It should have something to do with python version and/or to some
> locale info at the system, as neither I or Jon can reproduce it.

 I can't reproduce it here, but I have certainly seen situations where
 Python 2 wants to run with the ascii codec by default.

 Note that the exception happens in our Sphinx extension, not in Sphinx
 itself.  We've had other non-ascii text in our docs, so I think Sphinx is
 doing the right thing.  The problem is with our own code.  If I could
 reproduce it, it shouldn't be too hard to track down - take out that
 massive "except anything" block and see where it explodes.

 Randy, which distribution are you running, and are you using their version
 of Sphinx?
>>>
>>> opensuse LEAP 42.2
>>> Yes, their sphinx 1.3.1.
>>
>> What's your LANG setting? I think that's what it boils down to, and
>> trying to work around non-UTF-8 LANG in both python 2 and 3 compatible
>> ways.
>>
>> The odd thing is that I can reproduce the issue using a small python
>> snippet, but not through Sphinx.
> 
> Your original error message suggests your Sphinx actually uses python
> 3. Can you check that? The clue is that it's the *decode* that fails.

Where do you see that clue?
My /usr/bin/python is linked to python2.7:

> ll /usr/bin/python
lrwxrwxrwx 1 root root 9 Jun 10 19:59 /usr/bin/python -> python2.7*

> Does the below patch help? It avoids the implicit ascii decoding due to
> universal_newlines=True and your LANG setting, and does explicit utf-8
> decoding instead.
> 
> Fingers crossed.

testing now.

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

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Khalid Aziz]

On 08/30/2017 06:09 PM, David Miller wrote:

From: Khalid Aziz 
Date: Wed, 30 Aug 2017 17:23:37 -0600


That is an interesting idea. This would enable TSTATE_MCDE on all
threads of a process as soon as one thread enables it. If we consider
the case where the parent creates a shared memory area and spawns a
bunch of threads. These threads access the shared memory without ADI
enabled. Now one of the threads decides to enable ADI on the shared
memory. As soon as it does that, we enable TSTATE_MCDE across all
threads and since threads are all using the same TTE for the shared
memory, every thread becomes subject to ADI verification. If one of
the other threads was in the middle of accessing the shared memory, it
will get a sigsegv. If we did not enable TSTATE_MCDE across all
threads, it could have continued execution without fault. In other
words, updating TSTATE_MCDE across all threads will eliminate the
option of running some threads with ADI enabled and some not while
accessing the same shared memory. This could be necessary at least for
short periods of time before threads can communicate with each other
and all switch to accessing shared memory with ADI enabled using same
tag. Does that sound like a valid use case or am I off in the weeds
here?


A threaded application needs to synchronize and properly orchestrate
access to shared memory.

When a change is made to a mappping, in this case setting ADI
attributes, it's being done for the address space not the thread.

And the address space is shared amongst threads.

Therefore ADI is not really a per-thread property but rather
a per-address-space property.



That does make sense.

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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Jani Nikula]

On Thu, 31 Aug 2017, Jani Nikula  wrote:
> On Thu, 31 Aug 2017, Randy Dunlap  wrote:
>> On 08/31/17 07:17, Jonathan Corbet wrote:
>>> On Thu, 31 Aug 2017 10:56:26 -0300
>>> Mauro Carvalho Chehab  wrote:
>>> 
 It should have something to do with python version and/or to some
 locale info at the system, as neither I or Jon can reproduce it.
>>> 
>>> I can't reproduce it here, but I have certainly seen situations where
>>> Python 2 wants to run with the ascii codec by default.
>>> 
>>> Note that the exception happens in our Sphinx extension, not in Sphinx
>>> itself.  We've had other non-ascii text in our docs, so I think Sphinx is
>>> doing the right thing.  The problem is with our own code.  If I could
>>> reproduce it, it shouldn't be too hard to track down - take out that
>>> massive "except anything" block and see where it explodes.
>>> 
>>> Randy, which distribution are you running, and are you using their version
>>> of Sphinx?
>>
>> opensuse LEAP 42.2
>> Yes, their sphinx 1.3.1.
>
> What's your LANG setting? I think that's what it boils down to, and
> trying to work around non-UTF-8 LANG in both python 2 and 3 compatible
> ways.
>
> The odd thing is that I can reproduce the issue using a small python
> snippet, but not through Sphinx.

Your original error message suggests your Sphinx actually uses python
3. Can you check that? The clue is that it's the *decode* that fails.

Does the below patch help? It avoids the implicit ascii decoding due to
universal_newlines=True and your LANG setting, and does explicit utf-8
decoding instead.

Fingers crossed.

BR,
Jani.


diff --git a/Documentation/sphinx/kerneldoc.py 
b/Documentation/sphinx/kerneldoc.py
index d15e07f36881..39aa9e8697cc 100644
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -27,6 +27,7 @@
 # Please make sure this works on both python2 and python3.
 #
 
+import codecs
 import os
 import subprocess
 import sys
@@ -88,13 +89,10 @@ class KernelDocDirective(Directive):
 try:
 env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
 
-p = subprocess.Popen(cmd, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE, universal_newlines=True)
+p = subprocess.Popen(cmd, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)
 out, err = p.communicate()
 
-# python2 needs conversion to unicode.
-# python3 with universal_newlines=True returns strings.
-if sys.version_info.major < 3:
-out, err = unicode(out, 'utf-8'), unicode(err, 'utf-8')
+out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
 
 if p.returncode != 0:
 sys.stderr.write(err)



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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/31/17 09:05, Jani Nikula wrote:
> On Thu, 31 Aug 2017, Randy Dunlap  wrote:
>> On 08/31/17 07:17, Jonathan Corbet wrote:
>>> On Thu, 31 Aug 2017 10:56:26 -0300
>>> Mauro Carvalho Chehab  wrote:
>>>
 It should have something to do with python version and/or to some
 locale info at the system, as neither I or Jon can reproduce it.
>>>
>>> I can't reproduce it here, but I have certainly seen situations where
>>> Python 2 wants to run with the ascii codec by default.
>>>
>>> Note that the exception happens in our Sphinx extension, not in Sphinx
>>> itself.  We've had other non-ascii text in our docs, so I think Sphinx is
>>> doing the right thing.  The problem is with our own code.  If I could
>>> reproduce it, it shouldn't be too hard to track down - take out that
>>> massive "except anything" block and see where it explodes.
>>>
>>> Randy, which distribution are you running, and are you using their version
>>> of Sphinx?
>>
>> opensuse LEAP 42.2
>> Yes, their sphinx 1.3.1.
> 
> What's your LANG setting? I think that's what it boils down to, and
> trying to work around non-UTF-8 LANG in both python 2 and 3 compatible
> ways.

(default)
LANG=C

until I add the patch:
+LANG=C.utf-8

> The odd thing is that I can reproduce the issue using a small python
> snippet, but not through Sphinx.



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

Re: [PATCH 2/2 v10] printk: Add monotonic, boottime, and realtime timestamps

[Thomas Gleixner]

On Mon, 28 Aug 2017, Prarit Bhargava wrote:
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index d111039e0245..9463606951b1 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -509,6 +509,19 @@ u64 notrace ktime_get_boot_fast_ns(void)
>  EXPORT_SYMBOL_GPL(ktime_get_boot_fast_ns);

Why is this still in the middle of the printk hodgepodge?

>  /**
> + * __ktime_get_real_fast_ns_unsafe: - Return an unsafe realtime value
> + * On 32-bit systems may lead to unlikely situations where the result is 
> wrong
> + * because the real time offset is read without the protection of a sequence
> + * lock.
> + */
> +u64 __ktime_get_real_fast_ns_unsafe(void)
> +{
> + struct timekeeper *tk = _core.timekeeper;
> +
> + return (ktime_get_mono_fast_ns() + ktime_to_ns(tk->offs_real));
> +}

And no, this function is just horrible, both in name and
implementation. This can be done without that unprotected and racy access
to the realtime offset. Patch below.

Thanks,

tglx

8<---
Subject: timekeeping: Provide NMI safe access to clock realtime
From: Thomas Gleixner 
Date: Thu, 31 Aug 2017 17:12:48 +0200

The configurable printk timestamping wants access to clock realtime. Right
now there is no ktime_get_real_fast_ns() accessor because reading the
monotonic base and the realtime offset cannot be done atomically. Contrary
to boot time this offset can change during runtime and cause half updated
readouts.

struct tk_read_base was fully packed when the fast timekeeper access was
implemented. commit ceea5e3771ed ("time: Fix clock->read(clock) race around
clocksource changes") removed the 'read' function pointer from the
structure, but of course left the comment stale.

So now the structure can fit a new 64bit member w/o violating the cache
line constraints.

Add real_base to tk_read_base and update it in the fast timekeeper update
sequence.

Implement an accessor which follows the same scheme as the accessor to
clock monotonic, but uses the new real_base to access clock real time.

The runtime overhead for updating real_base is minimal as it just adds two
cache hot values and stores into the same an already dirtied cache line.

Signed-off-by: Thomas Gleixner 
---
 include/linux/timekeeper_internal.h |6 +-
 include/linux/timekeeping.h |1 +
 kernel/time/timekeeping.c   |   35 +++
 3 files changed, 41 insertions(+), 1 deletion(-)

--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -13,19 +13,22 @@
 /**
  * struct tk_read_base - base structure for timekeeping readout
  * @clock: Current clocksource used for timekeeping.
- * @read:  Read function of @clock
  * @mask:  Bitmask for two's complement subtraction of non 64bit clocks
  * @cycle_last: @clock cycle value at last update
  * @mult:  (NTP adjusted) multiplier for scaled math conversion
  * @shift: Shift value for scaled math conversion
  * @xtime_nsec: Shifted (fractional) nano seconds offset for readout
  * @base:  ktime_t (nanoseconds) base time for readout
+ * @base_real: Nanoseconds base value for clock REALTIME readout
  *
  * This struct has size 56 byte on 64 bit. Together with a seqcount it
  * occupies a single 64byte cache line.
  *
  * The struct is separate from struct timekeeper as it is also used
  * for a fast NMI safe accessors.
+ *
+ * @base_real is for the fast NMI safe accessor to allow reading clock
+ * realtime from any context.
  */
 struct tk_read_base {
struct clocksource  *clock;
@@ -35,6 +38,7 @@ struct tk_read_base {
u32 shift;
u64 xtime_nsec;
ktime_t base;
+   u64 base_real;
 };
 
 /**
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -239,6 +239,7 @@ static inline u64 ktime_get_raw_ns(void)
 extern u64 ktime_get_mono_fast_ns(void);
 extern u64 ktime_get_raw_fast_ns(void);
 extern u64 ktime_get_boot_fast_ns(void);
+extern u64 ktime_get_real_fast_ns(void);
 
 /*
  * Timespec interfaces utilizing the ktime based ones
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -496,6 +496,39 @@ u64 notrace ktime_get_boot_fast_ns(void)
 }
 EXPORT_SYMBOL_GPL(ktime_get_boot_fast_ns);
 
+
+/*
+ * See comment for __ktime_get_fast_ns() vs. timestamp ordering
+ */
+static __always_inline u64 __ktime_get_real_fast_ns(struct tk_fast *tkf)
+{
+   struct tk_read_base *tkr;
+   unsigned int seq;
+   u64 now;
+
+   do {
+   seq = raw_read_seqcount_latch(>seq);
+   tkr = tkf->base + (seq & 0x01);
+   now = ktime_to_ns(tkr->base_real);
+
+   now += timekeeping_delta_to_ns(tkr,
+   clocksource_delta(
+   tk_clock_read(tkr),
+   

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Jani Nikula]

On Thu, 31 Aug 2017, Randy Dunlap  wrote:
> On 08/31/17 07:17, Jonathan Corbet wrote:
>> On Thu, 31 Aug 2017 10:56:26 -0300
>> Mauro Carvalho Chehab  wrote:
>> 
>>> It should have something to do with python version and/or to some
>>> locale info at the system, as neither I or Jon can reproduce it.
>> 
>> I can't reproduce it here, but I have certainly seen situations where
>> Python 2 wants to run with the ascii codec by default.
>> 
>> Note that the exception happens in our Sphinx extension, not in Sphinx
>> itself.  We've had other non-ascii text in our docs, so I think Sphinx is
>> doing the right thing.  The problem is with our own code.  If I could
>> reproduce it, it shouldn't be too hard to track down - take out that
>> massive "except anything" block and see where it explodes.
>> 
>> Randy, which distribution are you running, and are you using their version
>> of Sphinx?
>
> opensuse LEAP 42.2
> Yes, their sphinx 1.3.1.

What's your LANG setting? I think that's what it boils down to, and
trying to work around non-UTF-8 LANG in both python 2 and 3 compatible
ways.

The odd thing is that I can reproduce the issue using a small python
snippet, but not through Sphinx.

BR,
Jani.

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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/31/17 02:49, Mauro Carvalho Chehab wrote:
> Em Wed, 30 Aug 2017 15:02:59 -0700
> Randy Dunlap  escreveu:
> 
>> On 08/30/17 14:23, Jonathan Corbet wrote:
>>> On Mon, 28 Aug 2017 16:10:09 -0700
>>> Randy Dunlap  wrote:
>>>   
 kernel-doc parsing uses as ASCII codec, so let people know that
 kernel-doc comments should be in ASCII characters only.

 WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno 
 ../drivers/media/dvb-core/demux.h' processing failed with: 'ascii' codec 
 can't decode byte 0xe2 in position 6368: ordinal not in range(128)  
>>>
>>> So I don't get this error.  What kind of system are you running the docs
>>> build on?  I would really rather that the docs system could handle modern
>>> text if possible, so it would be better to figure out what's going on
>>> here...  
>>
>> I'm OK with that. Source files in general don't need to be ASCII (0-127).
>>
>> I did this patch based on this (private) comment:
>>
>>> Yes, using ASCII should fix the problem.  
>>
>> what kind of system?  HP laptop.
>>
>> Linux midway.site 4.4.79-18.26-default #1 SMP Thu Aug 10 20:30:05 UTC 2017 
>> (fa5a935) x86_64 x86_64 x86_64 GNU/Linux
>>
>>> sphinx-build --version  
>> Sphinx (sphinx-build) 1.3.1
> 
> I tried hard to reproduce the error here... I even added some Chinese
> chars on a kernel-doc markup and changed the language on my system
> to LANG=en_US.iso885915.
> 
> No luck. 
> 
> As Documentation/conf.py has:
> 
>   # -*- coding: utf-8 -*-
> 
> on its first line, I suspect that the error you're getting is likely
> due to the usage of a python version that doesn't recognize this.
> 
> It seems that such dialect was introduced on python version 2.3:
> 
>   https://docs.python.org/2.3/whatsnew/section-encodings.html
> 
> Yet, the documentation there seems to require a line before it,
> e. g.:
> 
>   #!/usr/bin/env python
>   # -*- coding: UTF-8 -*-
> 
> I suspect, however, that, if such line is added, on some systems it
> may not work, e. g. if both python 2 and 3 are installed, it could
> use the python version that doesn't have Sphinx installed.
> 
> So, I suspect that the safest way to fix it is with something like the
> enclosed patch. Still, it could be useful to know what's happening,
> just in case we get other reports.
> 
> Randy,
> 
> What's your python version?

> python --version
Python 2.7.13



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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Randy Dunlap]

On 08/31/17 07:17, Jonathan Corbet wrote:
> On Thu, 31 Aug 2017 10:56:26 -0300
> Mauro Carvalho Chehab  wrote:
> 
>> It should have something to do with python version and/or to some
>> locale info at the system, as neither I or Jon can reproduce it.
> 
> I can't reproduce it here, but I have certainly seen situations where
> Python 2 wants to run with the ascii codec by default.
> 
> Note that the exception happens in our Sphinx extension, not in Sphinx
> itself.  We've had other non-ascii text in our docs, so I think Sphinx is
> doing the right thing.  The problem is with our own code.  If I could
> reproduce it, it shouldn't be too hard to track down - take out that
> massive "except anything" block and see where it explodes.
> 
> Randy, which distribution are you running, and are you using their version
> of Sphinx?

opensuse LEAP 42.2
Yes, their sphinx 1.3.1.


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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Jonathan Corbet]

On Thu, 31 Aug 2017 10:56:26 -0300
Mauro Carvalho Chehab  wrote:

> It should have something to do with python version and/or to some
> locale info at the system, as neither I or Jon can reproduce it.

I can't reproduce it here, but I have certainly seen situations where
Python 2 wants to run with the ascii codec by default.

Note that the exception happens in our Sphinx extension, not in Sphinx
itself.  We've had other non-ascii text in our docs, so I think Sphinx is
doing the right thing.  The problem is with our own code.  If I could
reproduce it, it shouldn't be too hard to track down - take out that
massive "except anything" block and see where it explodes.

Randy, which distribution are you running, and are you using their version
of Sphinx?

Thanks,

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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Mauro Carvalho Chehab]

Em Thu, 31 Aug 2017 16:26:44 +0300
Jani Nikula  escreveu:

> On Thu, 31 Aug 2017, Mauro Carvalho Chehab  wrote:
> > As Documentation/conf.py has:
> >
> > # -*- coding: utf-8 -*-
> >
> > on its first line, I suspect that the error you're getting is likely
> > due to the usage of a python version that doesn't recognize this.  
> 
> AFAIK that has nothing to do with python I/O, and everything to do with
> the encoding of that specific python source file.

Jani,

It should have something to do with python version and/or to some
locale info at the system, as neither I or Jon can reproduce it.

Can you reproduce it on your system?

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

Re: [v6 2/4] mm, oom: cgroup-aware OOM killer

[Roman Gushchin]

On Wed, Aug 30, 2017 at 01:56:22PM -0700, David Rientjes wrote:
> On Wed, 30 Aug 2017, Roman Gushchin wrote:
> 
> > I've spent some time to implement such a version.
> > 
> > It really became shorter and more existing code were reused,
> > howewer I've met a couple of serious issues:
> > 
> > 1) Simple summing of per-task oom_score doesn't make sense.
> >First, we calculate oom_score per-task, while should sum per-process 
> > values,
> >or, better, per-mm struct. We can take only threa-group leader's score
> >into account, but it's also not 100% accurate.
> >And, again, we have a question what to do with per-task oom_score_adj,
> >if we don't task the task's oom_score into account.
> > 
> >Using memcg stats still looks to me as a more accurate and consistent
> >way of estimating memcg memory footprint.
> > 
> 
> The patchset is introducing a new methodology for selecting oom victims so 
> you can define how cgroups are compared vs other cgroups with your own 
> "badness" calculation.  I think your implementation based heavily on anon 
> and unevictable lrus and unreclaimable slab is fine and you can describe 
> that detail in the documentation (along with the caveat that it is only 
> calculated for nodes in the allocation's mempolicy).  With 
> memory.oom_priority, the user has full ability to change that selection.  
> Process selection heuristics have changed over time themselves, it's not 
> something that must be backwards compatibile and trying to sum the usage 
> from each of the cgroup's mm_struct's and respect oom_score_adj is 
> unnecessarily complex.

I agree.

So, it looks to me that we're close to an acceptable version,
and the only remaining question is the default behavior
(when oom_group is not set).

Michal suggests to ignore non-oom_group memcgs, and compare tasks with
memcgs with oom_group set. This makes the whole thing completely opt-in,
but then we probably need another knob (or value) to select between
"select memcg, kill biggest task" and "select memcg, kill all tasks".
Also, as the whole thing is based on comparison between processes and
memcgs, we probably need oom_priority for processes.
I'm not necessary against this options, but I do worry about the complexity
of resulting interface.

In my implementation we always select a victim memcg first (or a task
in root memcg), and then kill the biggest task inside.
It actually changes the victim selection policy. By doing this
we achieve per-memcg fairness, which makes sense in a containerized
environment.
I believe it's acceptable, but I can also add a cgroup v2 mount option
to completely revert to the per-process OOM killer for those users, who
for some reasons depend on the existing victim selection policy.

Any thoughts/objections?

Thanks!

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

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

[Jani Nikula]

On Thu, 31 Aug 2017, Mauro Carvalho Chehab  wrote:
> As Documentation/conf.py has:
>
>   # -*- coding: utf-8 -*-
>
> on its first line, I suspect that the error you're getting is likely
> due to the usage of a python version that doesn't recognize this.

AFAIK that has nothing to do with python I/O, and everything to do with
the encoding of that specific python source file.

BR,
Jani.

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

[no subject]

[1.10.1102011201470.7894]

52503216625202.doc
Description: MS-Word document

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

[Pavel Machek]

Hi!

> >> > -As a specific example of this use-case, let's look at vibrate feature on
> >> > -phones. Vibrate function on phones is implemented using PWM pins on SoC 
> >> > or
> >> > -PMIC. There is a need to activate one shot timer to control the vibrate
> >> > -feature, to prevent user space crashes leaving the phone in vibrate mode
> >> > -permanently causing the battery to drain.
> >> 
> >> I'm not sure if it is a good idea to remove this description. Users will
> >> still be able to use transient trigger this way. It has been around for
> >> five years already and there are users which employ it in this
> >> particular way [0].
> >
> > I am. Yes, people were doing that, but no, vibration motor is not a
> > LED. PWM behaviour is different, for example, motor is likely to stop
> > at low PWM values. We do not want people to do that.
> >
> >> Apart from that it's the only documented kernel API for vibrate devices
> >> AFAICT.
> >
> > Input subsystem has force-feedback protocol, which is very often just
> > vibrations. Documentation/input/ff.rst . Nokia N900 phone actually
> > uses that API.
> 
> N900 as shipped by Nokia used an ad hoc sysfs interface. Because that
> sucked, I advocated using the force feedback API for N950 and
> N9. Because what is vibration but force feedback? It's a much more
> versatile API for vibration than a simple trigger. You get to upload
> effects and have the kernel play them for you, also stopping them in a
> timely manner regardless of the userspace dying and whatnot. I didn't
> double check now, but IIRC you could also link the input to force
> feedback, e.g. for touch vibrations.

Ok, N900 support in mainline actually uses force feedback, as in N9,
N950. It is the right interface.

AFAICT, no mainline ARM board uses LEDs for vibrations. And I hope to
keep it that way :-).

(OpenMoko gta01 did that, IIRC. But that is not mainline, good).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

[Jani Nikula]

On Tue, 29 Aug 2017, Pavel Machek  wrote:
> Hi!
>
>> > -As a specific example of this use-case, let's look at vibrate feature on
>> > -phones. Vibrate function on phones is implemented using PWM pins on SoC or
>> > -PMIC. There is a need to activate one shot timer to control the vibrate
>> > -feature, to prevent user space crashes leaving the phone in vibrate mode
>> > -permanently causing the battery to drain.
>> 
>> I'm not sure if it is a good idea to remove this description. Users will
>> still be able to use transient trigger this way. It has been around for
>> five years already and there are users which employ it in this
>> particular way [0].
>
> I am. Yes, people were doing that, but no, vibration motor is not a
> LED. PWM behaviour is different, for example, motor is likely to stop
> at low PWM values. We do not want people to do that.
>
>> Apart from that it's the only documented kernel API for vibrate devices
>> AFAICT.
>
> Input subsystem has force-feedback protocol, which is very often just
> vibrations. Documentation/input/ff.rst . Nokia N900 phone actually
> uses that API.

N900 as shipped by Nokia used an ad hoc sysfs interface. Because that
sucked, I advocated using the force feedback API for N950 and
N9. Because what is vibration but force feedback? It's a much more
versatile API for vibration than a simple trigger. You get to upload
effects and have the kernel play them for you, also stopping them in a
timely manner regardless of the userspace dying and whatnot. I didn't
double check now, but IIRC you could also link the input to force
feedback, e.g. for touch vibrations.


BR,
Jani.


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