Re: [PATCH v8 01/20] crypto: change transient busy return code to -EAGAIN

[Herbert Xu]

On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 5e92bd2..3b3c154 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -39,6 +39,20 @@ struct algif_hash_tfm {
>   bool has_key;
>  };
>  
> +/* Previous versions of crypto_* ops used to return -EBUSY
> + * rather than -EAGAIN to indicate being tied up. The in
> + * kernel API changed but we don't want to break the user
> + * space API. As only the hash user interface exposed this
> + * error ever to the user, do the translation here.
> + */
> +static inline int crypto_user_err(int err)
> +{
> + if (err == -EAGAIN)
> + return -EBUSY;
> +
> + return err;

I don't see the need to carry along this baggage.  Does anyone
in user-space actually rely on EBUSY?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v8 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Anthony Yznaga]

> On Sep 25, 2017, at 9:49 AM, Khalid Aziz  wrote:
> 
> ADI is a new feature supported on SPARC M7 and newer processors to allow
> hardware to catch rogue accesses to memory. ADI is supported for data
> fetches only and not instruction fetches. An app can enable ADI on its
> data pages, set version tags on them and use versioned addresses to
> access the data pages. Upper bits of the address contain the version
> tag. On M7 processors, upper four bits (bits 63-60) contain the version
> tag. If a rogue app attempts to access ADI enabled data pages, its
> access is blocked and processor generates an exception. Please see
> Documentation/sparc/adi.txt for further details.
> 
> This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable
> MCD (Memory Corruption Detection) on selected memory ranges, enable
> TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI
> version tags on page swap out/in or migration. ADI is not enabled by

I still don't believe migration is properly supported.  Your
implementation is relying on a fault happening on a page while its
migration is in progress so that do_swap_page() will be called, but
I don't see how do_swap_page() will be called if a fault does not
happen until after the migration has completed.


> default for any task. A task must explicitly enable ADI on a memory
> range and set version tag for ADI to be effective for the task.
> 
> Signed-off-by: Khalid Aziz 
> Cc: Khalid Aziz 
> ---
> v8: 
>   - Added note to doc about non-faulting loads not triggering
> ADI tag mismatch and more details on special tag values
> of 0x0 and 0xf, as suggested by Anthony Yznaga)
>   - Added an IPI on mprotect(...PROT_ADI...) call to set
> TSTATE.MCDE on threads running on other processors and
> restore of TSTATE.MCDE on context switch (suggested by
> David Miller)
>   - Removed restriction on enabling ADI on read-only memory
> (suggested by Anthony Yznaga)
>   - Changed kzalloc() for tag storage to use GFP_NOWAIT
>   - Added code to handle overflow and underflow when allocating
> tag storage, as suggested by Anthony Yznaga
>   - Replaced sun_m7_patch_1insn_range() with sun4v_patch_1insn_range()
> which is functionally identical (suggested by Anthony Yznaga)
>   - Added membar after restoring ADI tags in copy_user_highpage(),
> as suggested by David Miller
> 
> v7:
>   - Enhanced arch_validate_prot() to enable ADI only on writable
> addresses backed by physical RAM
>   - Added support for saving/restoring ADI tags for each ADI
> block size address range on a page on swap in/out
>   - Added code to copy ADI tags on COW
>   - Updated values for auxiliary vectors to not conflict with
> values on other architectures to avoid conflict in glibc. glibc
> consolidates all auxiliary vectors into its headers and
> duplicate values in consolidated header are problematic
>   - Disable same page merging on ADI enabled pages since ADI tags
> may not match on pages with identical data
>   - Broke the patch up further into smaller patches
> 
> v6:
>   - Eliminated instructions to read and write PSTATE as well as
> MCDPER and PMCDPER on every access to userspace addresses
> by setting PSTATE and PMCDPER correctly upon entry into
> kernel. PSTATE.mcde and PMCDPER are set upon entry into
> kernel when running on an M7 processor. PSTATE.mcde being
> set only affects memory accesses that have TTE.mcd set.
> PMCDPER being set only affects writes to memory addresses
> that have TTE.mcd set. This ensures any faults caused by
> ADI tag mismatch on a write are exposed before kernel returns
> to userspace.
> 
> v5:
>   - Fixed indentation issues and instrcuctions in assembly code
>   - Removed CONFIG_SPARC64 from mdesc.c
>   - Changed to maintain state of MCDPER register in thread info
> flags as opposed to in mm context. MCDPER is a per-thread
> state and belongs in thread info flag as opposed to mm context
> which is shared across threads. Added comments to clarify this
> is a lazily maintained state and must be updated on context
> switch and copy_process()
>   - Updated code to use the new arch_do_swap_page() and
> arch_unmap_one() functions
> 
> v4:
>   - Broke patch up into smaller patches
> 
> v3:
>   - Removed CONFIG_SPARC_ADI
>   - Replaced prctl commands with mprotect
>   - Added auxiliary vectors for ADI parameters
>   - Enabled ADI for swappable pages
> 
> v2:
>   - Fixed a build error
> 
> Documentation/sparc/adi.txt | 278 ++
> arch/sparc/include/asm/mman.h   |  84 +-
> arch/sparc/include/asm/mmu_64.h |  17 

[PATCH v3] cpuset: Enable cpuset controller in default hierarchy

[Waiman Long]

Given the fact that thread mode had been merged into 4.14, it is now
time to enable cpuset to be used in the default hierarchy (cgroup v2)
as it is clearly threaded.

The cpuset controller had experienced feature creep since its
introduction more than a decade ago. Besides the core cpus and mems
control files to limit cpus and memory nodes, there are a bunch of
additional features that can be controlled from the userspace. Some of
the features are of doubtful usefulness and may not be actively used.

After examining the source code of some sample users like systemd,
libvirt and lxc for their use of those additional features, only
memory_migrate is used by libvirt.

This patch enables cpuset controller in the default hierarchy with a
minimal set of features. Currently, only memory_migrate is supported.
We can certainly add more features to the default hierarchy if there
is a real user need for them later on.

For features that are actually flags which are set internally, they are
being combined into a single "cpuset.flags" control file. That includes
the memory_migrate feature which is the only flag that is currently
supported. When the "cpuset.flags" file is read, it contains either
"+mem_migrate" (enabled) or "-mem_migrate" (disabled).

To enable it, use

  # echo +mem_migrate > cpuset.flags

To disable it, use

  # echo -mem_migrate > cpuset.flags

Note that the flag name is changed to "mem_migrate" for better naming
consistency.

v3:
 - Further trim the additional features down to just memory_migrate.
 - Update Documentation/cgroup-v2.txt.

Signed-off-by: Waiman Long 
---
 Documentation/cgroup-v2.txt | 122 
 kernel/cgroup/cpuset.c  | 112 +++-
 2 files changed, 223 insertions(+), 11 deletions(-)

diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index 0bbdc72..f9fea87 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -48,15 +48,17 @@ v1 is available under Documentation/cgroup-v1/.
5-2-1. Memory Interface Files
5-2-2. Usage Guidelines
5-2-3. Memory Ownership
- 5-3. IO
-   5-3-1. IO Interface Files
-   5-3-2. Writeback
- 5-4. PID
-   5-4-1. PID Interface Files
- 5-5. RDMA
-   5-5-1. RDMA Interface Files
- 5-6. Misc
-   5-6-1. perf_event
+ 5-3. Cpuset
+   5.3-1. Cpuset Interface Files
+ 5-4. IO
+   5-4-1. IO Interface Files
+   5-4-2. Writeback
+ 5-5. PID
+   5-5-1. PID Interface Files
+ 5-6. RDMA
+   5-6-1. RDMA Interface Files
+ 5-7. Misc
+   5-7-1. perf_event
6. Namespace
  6-1. Basics
  6-2. The Root and Views
@@ -1235,6 +1237,108 @@ POSIX_FADV_DONTNEED to relinquish the ownership of 
memory areas
 belonging to the affected files to ensure correct memory ownership.
 
 
+Cpuset
+--
+
+The "cpuset" controller provides a mechanism for constraining
+the CPU and memory node placement of tasks to only the resources
+specified in the cpuset interface files in a task's current cgroup.
+This is especially valuable on large NUMA systems where placing jobs
+on properly sized subsets of the systems with careful processor and
+memory placement to reduce cross-node memory access and contention
+can improve overall system performance.
+
+The "cpuset" controller is hierarchical.  That means the controller
+cannot use CPUs or memory nodes not allowed in its parent.
+
+
+Cpuset Interface Files
+~~
+
+  cpuset.cpus
+   A read-write multiple values file which exists on non-root
+   cgroups.
+
+   It lists the CPUs allowed to be used by tasks within this
+   cgroup.  The CPU numbers are comma-separated numbers or
+   ranges.  For example:
+
+ # cat cpuset.cpus
+ 0-4,6,8-10
+
+   An empty value indicates that the cgroup is using the same
+   setting as the nearest cgroup ancestor with a non-empty
+   "cpuset.cpus" or all the available CPUs if none is found.
+
+   The value of "cpuset.cpus" stays constant until the next update
+   and won't be affected by any CPU hotplug events.
+
+  cpuset.effective_cpus
+   A read-only multiple values file which exists on non-root
+   cgroups.
+
+   It lists the onlined CPUs that are actually allowed to be
+   used by tasks within the current cgroup. It is a subset of
+   "cpuset.cpus". Its value will be affected by CPU hotplug
+   events.
+
+  cpuset.mems
+   A read-write multiple values file which exists on non-root
+   cgroups.
+
+   It lists the memory nodes allowed to be used by tasks within
+   this cgroup.  The memory node numbers are comma-separated
+   numbers or ranges.  For example:
+
+ # cat cpuset.mems
+ 0-1,3
+
+   An empty value indicates that the cgroup is using the same
+   setting as the nearest cgroup ancestor with a non-empty
+   "cpuset.mems" or all the 

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Jacek Anaszewski]

On 10/06/2017 01:48 PM, Pavel Machek wrote:
> On Wed 2017-09-20 22:08:42, Jacek Anaszewski wrote:
>> On 09/20/2017 01:29 PM, Pavel Machek wrote:
>>> I'd leave the decision to the user. We could add a note to the
>>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>>> should be preferable choice for driving vibrate devices.
>>> However only if following conditions are met:
>>
>> What I meant is that it is my decision, as a LED subsystem maintainer,
>> to accept the addition of a note about some other subsystem offering
>> an equivalent or even better substitute of the feature being available
>> in the subsystem I am responsible for. And I will accept such a patch
>> only if mentioned conditions are met.
>
> Having the wording in documentation does not in any way stops Android
> folks from continuing [ab]using the transient trigger. But this is
> their choice. The purpose of documentation is to document the best
> practices, not all possible crazy solutions one can come up with.

 Yes. but if the information has been in place for years, we can't
 just remove it without giving an instruction on how to use the
 substitute.
>>>
>>> I gave you information how to use the substitute.
>>
>> That information was quite vague. I'd like to see a sample application
>> in tools/input.
> 
> So please write it.

This is my demand as a reviewer. I've already laid out the conditions
under which I'll accept the patch. It seems that you're proficient
in the subject enough to cope with this task.

>>> I already suggested patch to documentation. If you do the same, maybe
>>> we can agree on documentation update.
>>
>> Your patch was just removing few lines of documentation. I'd expect more
>> empathic approach to the current users, i.e.:
>>
>> - pointer to the sample application in tools/input showing how to
>>   setup gpio driven vibrate device with use of ff interface with
>>   1kHz vibration frequency.
> 
> Yes, my patch is removing dangerously misleading documentation about
> LED subsystem.

It's neither dangerous nor misleading.

> Please apply it.

Right after I'll get the patch with the tool showing how to use
input subsystem to achieve the same effect as with use of
ledtrig-transient.

-- 
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: [PATCH] Documentation: add Kernel Driver Statement to the kernel

[Jonathan Corbet]

On Fri, 6 Oct 2017 11:10:38 +0200
Greg Kroah-Hartman  wrote:

> Way back in 2008 we didn't have "robust" in-kernel documentation system,
> so the idea of putting something like the kernel driver statement in the
> kernel tree wasn't even imagined.  But now that has changed, so add the
> old document to the kernel source itself to allow for us to properly
> reference it in one canonical place (as the LF wiki keeps moving things
> around.)
> 
> This also will allow people to add their names to it, as I seem to have
> lost the ability to do that by not knowing how to edit things on the
> original document.
> 
> Signed-off-by: Greg Kroah-Hartman 
> ---
> 
> Jon, if this isn't the correct place to put the document, I'd be glad to
> move it elsewhere, I just picked the first place that it seemed to fit
> into.

It seems like the perfect place to me, I went ahead and applied it.

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] Documentation: add Kernel Driver Statement to the kernel

[Mauro Carvalho Chehab]

Em Fri, 6 Oct 2017 11:10:38 +0200
Greg Kroah-Hartman  escreveu:

> Way back in 2008 we didn't have "robust" in-kernel documentation system,
> so the idea of putting something like the kernel driver statement in the
> kernel tree wasn't even imagined.  But now that has changed, so add the
> old document to the kernel source itself to allow for us to properly
> reference it in one canonical place (as the LF wiki keeps moving things
> around.)
> 
> This also will allow people to add their names to it, as I seem to have
> lost the ability to do that by not knowing how to edit things on the
> original document.
> 
> Signed-off-by: Greg Kroah-Hartman 

From my side:

Acked-by: Mauro Carvalho Chehab 


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: [PATCH v7 4/7] media: open.rst: document devnode-centric and mc-centric types

[Sakari Ailus]

Hi Mauro,

On Wed, Sep 27, 2017 at 07:23:46PM -0300, Mauro Carvalho Chehab wrote:
> When we added support for omap3, back in 2010, we added a new
> type of V4L2 devices that aren't fully controlled via the V4L2
> device node.
> 
> Yet, we have never clearly documented in the V4L2 specification
> the differences between the two types.
> 
> Let's document them based on the the current implementation.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/v4l/open.rst | 40 
> +++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/open.rst 
> b/Documentation/media/uapi/v4l/open.rst
> index 18030131ef77..f603bc9b49a0 100644
> --- a/Documentation/media/uapi/v4l/open.rst
> +++ b/Documentation/media/uapi/v4l/open.rst
> @@ -7,6 +7,46 @@ Opening and Closing Devices
>  ***
>  
>  
> +.. _v4l2_hardware_control:
> +
> +
> +Types of V4L2 media hardware control
> +
> +
> +V4L2 hardware periferal is usually complex: support for it is
> +implemented via a V4L2 main driver and often by several additional drivers.
> +The main driver always exposes one or more **V4L2 device nodes**
> +(see :ref:`v4l2_device_naming`) with are responsible for implementing
> +data streaming, if applicable.
> +
> +The other drivers are called **V4L2 sub-devices** and provide control to

s/drivers/devices/

> +other hardware components usually connected via a serial bus (like
> +I²C, SMBus or SPI). Depending on the main driver, they can be implicitly
> +controlled directly by the main driver or explicitly via
> +the **V4L2 sub-device API** (see :ref:`subdev`).
> +
> +When V4L2 was originally designed, there was only one type of
> +media hardware control: via the **V4L2 device nodes**. We refer to this kind
> +of control as **V4L2 device node centric** (or, simply, 
> "**vdevnode-centric**").

I think this could be easier understood if we start with the differences
instead of what we call the types. I'd also refer to interfaces rather than
their instances.

How about (pending finalising discussion on naming):

When **V4L2** was originally designed, the **V4L2 device** served the
purpose of both control and data interfaces and there was no separation
between the two interface-wise. V4L2 controls, setting inputs and outputs,
format configuration and buffer related operations were all performed
through the same **V4L2 device nodes**. Devices offering such interface are
called **V4L2 device node centric**.

Later on, support for the **Media controller** interface was added to V4L2
in order to better support complex **V4L2 aggregate devices** where the
**V4L2** interface alone could no longer meaningfully serve as both a
control and a data interface. On such aggregate devices, **V4L2** interface
remains a data interface whereas control takes place through the **Media
controller** and **V4L2 sub-device** interfaces. Stream control is an
exception to this: streaming is enabled and disabled through the **V4L2**
interface. These devices are called **Media controller centric**.

**MC-centric** aggregate devices provide more versatile control of the
hardware than **V4L2 device node centric** devices. On **MC-centric**
aggregate devices the **V4L2 sub-device nodes** represent specific parts of
the **V4L2 aggregate device**, to which they enable control.

Also, the additional versatility of **MC-centric** aggregate devices comes
with additional responsibilities, the main one of which is the requirements
of the user configuring the device pipeline before starting streaming. This
typically involves configuring the links using the **Media controller**
interface and the media bus formats on pads (at both ends of the links)
using the **V4L2 sub-device** interface.

> +
> +Later (kernel 2.6.39), a new type of periferal control was
> +added in order to support complex media hardware that are common for embedded
> +systems. This type of periferal is controlled mainly via the media
> +controller and V4L2 sub-devices. So, it is called
> +**Media controller centric** (or, simply, "**MC-centric**") control.
> +
> +For **vdevnode-centric** media hardware control, the media hardware is
> +controlled via the **V4L2 device nodes**. They may optionally support the
> +:ref:`media controller API ` as well,
> +in order to inform the application which device nodes are available
> +(see :ref:`related`).
> +
> +For **MC-centric** media hardware control it is required to configure
> +the pipelines via the :ref:`media controller API ` before
> +the periferal can be used. For such devices, the sub-devices' configuration
> +can be controlled via the :ref:`sub-device API `, which creates one
> +device node per sub-device.
> +
>  .. _v4l2_device_naming:
>  
>  V4L2 Device Node Naming

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in

Re: [v11 4/6] mm, oom: introduce memory.oom_group

[Michal Hocko]

On Fri 06-10-17 13:04:35, Roman Gushchin wrote:
> On Thu, Oct 05, 2017 at 04:31:04PM +0200, Michal Hocko wrote:
> > Btw. here is how I would do the recursive oom badness. The diff is not
> > the nicest one because there is some code moving but the resulting code
> > is smaller and imho easier to grasp. Only compile tested though
> 
> Thanks!
> 
> I'm not against this approach, and maybe it can lead to a better code,
> but the version you sent is just not there yet.
> 
> There are some problems with it:
> 
> 1) If there are nested cgroups with oom_group set, you will calculate
> a badness multiple times, and rely on the fact, that top memcg will
> become the largest score. It can be optimized, of course, but it's
> additional code.

right. As I've said we can introduce iterator helper to skip the subtree
but I suspect it will not make much of a difference.

> 
> 2) cgroup_has_tasks() probably requires additional locking.
> Maybe it's ok to read nr_populated_csets without explicit locking,
> but it's not obvious for me.

I do not see why. Tasks are free to come and go and you only know at the
time you are killing.

> 3) Returning -1 from memcg_oom_badness() if eligible is equal to 0
> is suspicious.

I didn't spend too much time on it. I merely wanted to point out my
thinking more specifically than the pseudo code posted earlier. But this
should be ok, because that would mean that either all tasks are
OOM_SCORE_ADJ_MIN (eligible = 0) or there is a inflight victim (eligible
= -1). Anyway the initialization should go inside the tree walk

> Right now your version has exactly the same amount of code
> (skipping comments). I assume, this approach just requires some additional
> thinking/rework.

Well, this is not about the amount of code but more about the clear
logic implemented at the correct level. It is simply much easier when
you evaluate the killable entity at one place rather open code it.

But as I've said nothing I would want to enforce.
-- 
Michal Hocko
SUSE Labs
--
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 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

Hi Mauro,

On Fri, Oct 06, 2017 at 01:22:29PM +0300, Sakari Ailus wrote:
> > +V4L2 device node
> > +   A device node that is associated to a V4L2 main driver,
> > +   as specified in :ref:`v4l2_device_naming`.

I think we need to name the interface, not so much their instances.

How about adding:

V4L2
Video4Linux 2 interface. The interface implemented by **V4L2 device
nodes**.

and:

V4L2 device node
A device node implementing the **V4L2** interface.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi
--
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: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

On Wed 2017-09-20 22:08:42, Jacek Anaszewski wrote:
> On 09/20/2017 01:29 PM, Pavel Machek wrote:
> > I'd leave the decision to the user. We could add a note to the
> > Documentation/leds/ledtrig-transient.txt that force feedback interface
> > should be preferable choice for driving vibrate devices.
> > However only if following conditions are met:
> 
>  What I meant is that it is my decision, as a LED subsystem maintainer,
>  to accept the addition of a note about some other subsystem offering
>  an equivalent or even better substitute of the feature being available
>  in the subsystem I am responsible for. And I will accept such a patch
>  only if mentioned conditions are met.
> >>>
> >>> Having the wording in documentation does not in any way stops Android
> >>> folks from continuing [ab]using the transient trigger. But this is
> >>> their choice. The purpose of documentation is to document the best
> >>> practices, not all possible crazy solutions one can come up with.
> >>
> >> Yes. but if the information has been in place for years, we can't
> >> just remove it without giving an instruction on how to use the
> >> substitute.
> > 
> > I gave you information how to use the substitute.
> 
> That information was quite vague. I'd like to see a sample application
> in tools/input.

So please write it.

> > I already suggested patch to documentation. If you do the same, maybe
> > we can agree on documentation update.
> 
> Your patch was just removing few lines of documentation. I'd expect more
> empathic approach to the current users, i.e.:
> 
> - pointer to the sample application in tools/input showing how to
>   setup gpio driven vibrate device with use of ff interface with
>   1kHz vibration frequency.

Yes, my patch is removing dangerously misleading documentation about
LED subsystem.

Please apply it.
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 v6 2/7] media: open.rst: better document device node naming

[Sakari Ailus]

On Tue, Aug 29, 2017 at 10:17:51AM -0300, Mauro Carvalho Chehab wrote:
> Right now, only kAPI documentation describes the device naming.
> However, such description is needed at the uAPI too. Add it,
> and describe how to get an unique identify for a given device.
> 
> Acked-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi
--
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: add Kernel Driver Statement to the kernel

[Greg Kroah-Hartman]

Way back in 2008 we didn't have "robust" in-kernel documentation system,
so the idea of putting something like the kernel driver statement in the
kernel tree wasn't even imagined.  But now that has changed, so add the
old document to the kernel source itself to allow for us to properly
reference it in one canonical place (as the LF wiki keeps moving things
around.)

This also will allow people to add their names to it, as I seem to have
lost the ability to do that by not knowing how to edit things on the
original document.

Signed-off-by: Greg Kroah-Hartman 
---

Jon, if this isn't the correct place to put the document, I'd be glad to
move it elsewhere, I just picked the first place that it seemed to fit
into.


 Documentation/process/index.rst   |   1 +
 Documentation/process/kernel-driver-statement.rst | 199 ++
 2 files changed, 200 insertions(+)
 create mode 100644 Documentation/process/kernel-driver-statement.rst

diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index 82fc399fcd33..68454319f006 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -25,6 +25,7 @@ Below are the essential guides that every developer should 
read.
submitting-patches
coding-style
email-clients
+   kernel-driver-statement
 
 Other guides to the community that are of interest to most developers are: 
 
diff --git a/Documentation/process/kernel-driver-statement.rst 
b/Documentation/process/kernel-driver-statement.rst
new file mode 100644
index ..60d9d868f300
--- /dev/null
+++ b/Documentation/process/kernel-driver-statement.rst
@@ -0,0 +1,199 @@
+Kernel Driver Statement
+---
+
+Position Statement on Linux Kernel Modules
+==
+
+
+We, the undersigned Linux kernel developers, consider any closed-source
+Linux kernel module or driver to be harmful and undesirable. We have
+repeatedly found them to be detrimental to Linux users, businesses, and
+the greater Linux ecosystem. Such modules negate the openness,
+stability, flexibility, and maintainability of the Linux development
+model and shut their users off from the expertise of the Linux
+community. Vendors that provide closed-source kernel modules force their
+customers to give up key Linux advantages or choose new vendors.
+Therefore, in order to take full advantage of the cost savings and
+shared support benefits open source has to offer, we urge vendors to
+adopt a policy of supporting their customers on Linux with open-source
+kernel code.
+
+We speak only for ourselves, and not for any company we might work for
+today, have in the past, or will in the future.
+
+ - Dave Airlie
+ - Nick Andrew
+ - Jens Axboe
+ - Ralf Baechle
+ - Felipe Balbi
+ - Ohad Ben-Cohen
+ - Muli Ben-Yehuda
+ - Jiri Benc
+ - Arnd Bergmann
+ - Thomas Bogendoerfer
+ - Vitaly Bordug
+ - James Bottomley
+ - Josh Boyer
+ - Neil Brown
+ - Mark Brown
+ - David Brownell
+ - Michael Buesch
+ - Franck Bui-Huu
+ - Adrian Bunk
+ - François Cami
+ - Ralph Campbell
+ - Luiz Fernando N. Capitulino
+ - Mauro Carvalho Chehab
+ - Denis Cheng
+ - Jonathan Corbet
+ - Glauber Costa
+ - Alan Cox
+ - Magnus Damm
+ - Ahmed S. Darwish
+ - Robert P. J. Day
+ - Hans de Goede
+ - Arnaldo Carvalho de Melo
+ - Helge Deller
+ - Jean Delvare
+ - Mathieu Desnoyers
+ - Sven-Thorsten Dietrich
+ - Alexey Dobriyan
+ - Daniel Drake
+ - Alex Dubov
+ - Randy Dunlap
+ - Michael Ellerman
+ - Pekka Enberg
+ - Jan Engelhardt
+ - Mark Fasheh
+ - J. Bruce Fields
+ - Larry Finger
+ - Jeremy Fitzhardinge
+ - Mike Frysinger
+ - Kumar Gala
+ - Robin Getz
+ - Liam Girdwood
+ - Jan-Benedict Glaw
+ - Thomas Gleixner
+ - Brice Goglin
+ - Cyrill Gorcunov
+ - Andy Gospodarek
+ - Thomas Graf
+ - Krzysztof Halasa
+ - Harvey Harrison
+ - Stephen Hemminger
+ - Michael Hennerich
+ - Tejun Heo
+ - Benjamin Herrenschmidt
+ - Kristian Høgsberg
+ - Henrique de Moraes Holschuh
+ - Marcel Holtmann
+ - Mike Isely
+ - Takashi Iwai
+ - Olof Johansson
+ - Dave Jones
+ - Jesper Juhl
+ - Matthias Kaehlcke
+ - Kenji Kaneshige
+ - Jan Kara
+ - Jeremy Kerr
+ - Russell King
+ - Olaf Kirch
+ - Roel Kluin
+ - Hans-Jürgen Koch
+ - Auke Kok
+ - Peter Korsgaard
+ - Jiri Kosina
+ - Mariusz Kozlowski
+ - Greg Kroah-Hartman
+ - Michael Krufky
+ - Aneesh Kumar
+ - Clemens Ladisch
+ - Christoph Lameter
+ - Gunnar Larisch
+ - Anders Larsen
+ - Grant Likely
+ - John W. Linville
+ - Yinghai Lu
+ - Tony Luck
+ - Pavel Machek
+ - Matt Mackall
+ - Paul Mackerras
+ - Roland McGrath
+ - Patrick McHardy
+ - Kyle McMartin
+ - Paul Menage
+ - Thierry Merle
+ - Eric Miao
+ - Akinobu Mita
+ - Ingo Molnar
+ - James Morris
+ - Andrew Morton
+ - Paul Mundt
+ - Oleg Nesterov
+ - Luca Olivetti
+ - S.Çağlar Onur
+ - Pierre Ossman
+ - Keith Owens
+ - Venkatesh Pallipadi
+ - Nick Piggin
+ - Nicolas Pitre
+ - Evgeniy Polyakov
+ - Richard Purdie
+ - Mike Rapoport
+ - Sam Ravnborg
+ - Gerrit Renker
+ - 

Re: [PATCH v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

Hi Mauro,

On Thu, Oct 05, 2017 at 09:26:51AM -0300, Mauro Carvalho Chehab wrote:
> > > > > +
> > > > > + See :ref:`media_controller`.
> > > > > +
> > > > > +MC-centric
> > > > > + V4L2 hardware that requires a Media controller.
> > > > > +
> > > > > + See :ref:`v4l2_hardware_control`.
> > > > > +
> > > > > +Microprocessor
> > > > > + An electronic circuitry that carries out the instructions
> > > > > + of a computer program by performing the basic arithmetic, 
> > > > > logical,
> > > > > + control and input/output (I/O) operations specified by the
> > > > > + instructions on a single integrated circuit.
> > > > > +
> > > > > +SMBus
> > > > > + A subset of I²C, with defines a stricter usage of the bus.
> > > > > +
> > > > > +Serial Peripheral Interface Bus - SPI
> > > > 
> > > > We don't have "Bus" in I²C, I'd leave it out here, too.  
> > > 
> > > I2C is a serial bus (and it is implemented as a bus inside the Kernel).
> > > Take a look at Documentation/i2c/summary.  
> > 
> > I don't disagree with that, but at the same time this is not related to my
> > suggestion.
> > 
> > "Bus" is not part of the abbreviation SPI, therefore we should not suggest
> > that here.
> 
> Ah, so you proposal here is just to replace:
> 
>   Serial Peripheral Interface Bus - SPI
> 
> To
>   Serial Peripheral Interface - SPI
> 
> Right? If so, it sounds OK.

Yes, please. That's exactly what I had in mind.

...

> > > > > +V4L2 hardware
> > > > > + A hardware used to on a media device supported by the V4L2
> > > > > + subsystem.
> > > > > +
> > > > > +V4L2 hardware control
> > > > > + The type of hardware control that a device supports.
> > > > > +
> > > > > + See :ref:`v4l2_hardware_control`.
> > > > > +
> > > > > +V4L2 main driver
> > > > > + The V4L2 device driver that implements the main logic to talk 
> > > > > with
> > > > > + the V4L2 hardware.
> > > > > +
> > > > > + Also known as bridge driver.
> > > > 
> > > > Is UVC driver a bridge driver? How about instead:  
> > > 
> > > Yes, sure: UVC driver is a bridge driver/main driver. It is the UVC driver
> > > that sends/receives data from the USB bus and send to the sensors.
> > > It also sends data via URB to the USB host driver, with, in turn send it
> > > to send to CPU (usually via DMA - although some USB drivers actually 
> > > implement direct I/O for short messages).
> > >   
> > > > Bridge and ISP drivers typically are V4L2 main drivers.  
> > > 
> > > We don't have a concept of an "ISP driver". Adding it sounds very  
> > 
> > I think we do have that roughly as much as we do have bridge driver. We
> > definitely also support devices that are called ISPs, therefore we do have
> > ISP drivers.
> 
> We have drivers for things implemented via ISP. However, right now,
> there's no distinction at the driver if the functionality is implemented
> on software (ISP) or in hardware. 
> 
> > 
> > > confusing, as an ISP hardware may actually implement different
> > > functions - so it ends by being supported by multiple drivers.  
> > 
> > Typically ISPs are controlled by a single driver as the sub-blocks in an
> > ISP usually can only be found in that very ISP.
> 
> I'm almost sure that this is not true for Exynos drivers. There are
> m2m drivers and normal drivers for the same ISP (doing different things,
> like format conversion, scaling, etc).

I don't know the Exynos hardware. There are exceptions but they tend to be
increasingly rare as extra memory hops hurt performance and increase power
consumption in common use cases.

If there is a split to multiple devices, then usually the first device is
CSI-2 receiver plus DMA (bridge) and the second is the ISP (i.e. where the
processing happens).

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi
--
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 v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

On Thu, Oct 05, 2017 at 03:39:29PM -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 5 Oct 2017 11:21:07 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > My apologies for the late reply.
> > 
> > On Tue, Aug 29, 2017 at 10:07:50AM -0300, Mauro Carvalho Chehab wrote:
> > > Em Tue, 29 Aug 2017 10:47:48 +0300
> > > Sakari Ailus  escreveu:
> > >   
> > > > Hi Mauro,
> > > > 
> > > > Thanks for the update. A few comments below.
> > > > 
> > > > On Mon, Aug 28, 2017 at 09:53:55AM -0300, Mauro Carvalho Chehab wrote:  
> > > > > Add a glossary of terms for V4L2, as several concepts are complex
> > > > > enough to cause misunderstandings.
> > > > > 
> > > > > Signed-off-by: Mauro Carvalho Chehab 
> > > > > ---
> > > > >  Documentation/media/uapi/v4l/glossary.rst | 147 
> > > > > ++
> > > > >  Documentation/media/uapi/v4l/v4l2.rst |   1 +
> > > > >  2 files changed, 148 insertions(+)
> > > > >  create mode 100644 Documentation/media/uapi/v4l/glossary.rst
> > > > > 
> > > > > diff --git a/Documentation/media/uapi/v4l/glossary.rst 
> > > > > b/Documentation/media/uapi/v4l/glossary.rst
> > > > > new file mode 100644
> > > > > index ..0b6ab5adec81
> > > > > --- /dev/null
> > > > > +++ b/Documentation/media/uapi/v4l/glossary.rst
> > > > > @@ -0,0 +1,147 @@
> > > > > +
> > > > > +Glossary
> > > > > +
> > > > > +
> > > > > +.. note::
> > > > > +
> > > > > +   This goal of section is to standardize the terms used within the 
> > > > > V4L2
> > > > > +   documentation. It is written incrementally as they are 
> > > > > standardized in
> > > > > +   the V4L2 documentation. So, it is a Work In Progress.
> > > > 
> > > > I'd leave the WiP part out.  
> > > 
> > > IMO, it is important to mention it, as the glossary, right now, covers
> > > only what's used on the first two sections of the API book. There are
> > > a lot more to be covered.  
> > 
> > Works for me.
> > 
> > >   
> > > >   
> > > > > +
> > > > > +.. Please keep the glossary entries in alphabetical order
> > > > > +
> > > > > +.. glossary::
> > > > > +
> > > > > +Bridge driver
> > > > > + The same as V4L2 main driver.
> > > > 
> > > > I've understood bridges being essentially a bus receiver + DMA. Most 
> > > > ISPs
> > > > contain both but have more than that. How about:
> > > > 
> > > > A driver for a bus (e.g. parallel, CSI-2) receiver and DMA. Bridge 
> > > > drivers
> > > > typically act as V4L2 main drivers.  
> > > 
> > > No, only on some drivers the bridge driver has DMA. A vast amount of
> > > drivers (USB ones) don't implement any DMA inside the driver, as it is
> > > up to the USB host driver to implement support for DMA.
> > > 
> > > There are even some USB host drivers that don't always use DMA for I/O 
> > > transfers, using direct I/O if the message is smaller than a threshold
> > > or not multiple of the bus word. This is pretty common on SoC USB host
> > > drivers.
> > > 
> > > In any case, for the effect of this spec, and for all discussions we
> > > ever had about it, bridge driver == V4L2 main driver. I don't
> > > see any reason why to distinguish between them.  
> > 
> > I think you should precisely define what a bridge driver means. Generally
> > ISP drivers aren't referred to as bridge drivers albeit they, too, function
> > as V4L2 main drivers.
> 
> Btw, this is already defined, currently, at v4l2-subdev.h:
> 
>  * Sub-devices are devices that are connected somehow to the main bridge
>  * device. These devices are usually audio/video muxers/encoders/decoders or
>  * sensors and webcam controllers.
>  *
>  * Usually these devices are controlled through an i2c bus, but other busses
>  * may also be used.
> 
> Please notice that there it says: "main bridge" :-)
> 
> Such definition was added since the beginning of the subdev concept, back in
> 2008 and was reviewed by several V4L core developers:

A lot has happened since 2008. :-)

Anyway, I'll review the latest set.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi
--
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