subject:"NOTICE\!\!"

4.20-stable review patch.  If anyone has any objections, please let me know.

--

From: Eric W. Biederman 

commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.

Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
failing to deliver SIGHUP but always trying.

Upon examination it turns out part of the problem is actually most of
the solution.  Since 2.5 signal delivery has found all fatal signals,
marked the signal group for death, and queued SIGKILL in every threads
thread queue relying on signal->group_exit_code to preserve the
information of which was the actual fatal signal.

The conversion of all fatal signals to SIGKILL results in the
synchronous signal heuristic in next_signal kicking in and preferring
SIGHUP to SIGKILL.  Which is especially problematic as all
fatal signals have already been transformed into SIGKILL.

Instead of dequeueing signals and depending upon SIGKILL to
be the first signal dequeued, first test if the signal group
has already been marked for death.  This guarantees that
nothing in the signal queue can prevent a process that needs
to exit from exiting.

Cc: sta...@vger.kernel.org
Tested-by: Dmitry Vyukov 
Reported-by: Dmitry Vyukov 
Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/signal.c |6 ++
 1 file changed, 6 insertions(+)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2393,6 +2393,11 @@ relock:
goto relock;
}
 
+   /* Has this task already been marked for death? */
+   ksig->info.si_signo = signr = SIGKILL;
+   if (signal_group_exit(signal))
+   goto fatal;
+
for (;;) {
struct k_sigaction *ka;
 
@@ -2488,6 +2493,7 @@ relock:
continue;
}
 
+   fatal:
spin_unlock_irq(>siglock);
 
/*

[PATCH 4.19 10/44] signal: Always notice exiting tasks

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Eric W. Biederman 

commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.

Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
failing to deliver SIGHUP but always trying.

Upon examination it turns out part of the problem is actually most of
the solution.  Since 2.5 signal delivery has found all fatal signals,
marked the signal group for death, and queued SIGKILL in every threads
thread queue relying on signal->group_exit_code to preserve the
information of which was the actual fatal signal.

The conversion of all fatal signals to SIGKILL results in the
synchronous signal heuristic in next_signal kicking in and preferring
SIGHUP to SIGKILL.  Which is especially problematic as all
fatal signals have already been transformed into SIGKILL.

Instead of dequeueing signals and depending upon SIGKILL to
be the first signal dequeued, first test if the signal group
has already been marked for death.  This guarantees that
nothing in the signal queue can prevent a process that needs
to exit from exiting.

Cc: sta...@vger.kernel.org
Tested-by: Dmitry Vyukov 
Reported-by: Dmitry Vyukov 
Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/signal.c |6 ++
 1 file changed, 6 insertions(+)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2390,6 +2390,11 @@ relock:
goto relock;
}
 
+   /* Has this task already been marked for death? */
+   ksig->info.si_signo = signr = SIGKILL;
+   if (signal_group_exit(signal))
+   goto fatal;
+
for (;;) {
struct k_sigaction *ka;
 
@@ -2485,6 +2490,7 @@ relock:
continue;
}
 
+   fatal:
spin_unlock_irq(>siglock);
 
/*

[PATCH 4.14 04/35] signal: Always notice exiting tasks

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Eric W. Biederman 

commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.

Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
failing to deliver SIGHUP but always trying.

Upon examination it turns out part of the problem is actually most of
the solution.  Since 2.5 signal delivery has found all fatal signals,
marked the signal group for death, and queued SIGKILL in every threads
thread queue relying on signal->group_exit_code to preserve the
information of which was the actual fatal signal.

The conversion of all fatal signals to SIGKILL results in the
synchronous signal heuristic in next_signal kicking in and preferring
SIGHUP to SIGKILL.  Which is especially problematic as all
fatal signals have already been transformed into SIGKILL.

Instead of dequeueing signals and depending upon SIGKILL to
be the first signal dequeued, first test if the signal group
has already been marked for death.  This guarantees that
nothing in the signal queue can prevent a process that needs
to exit from exiting.

Cc: sta...@vger.kernel.org
Tested-by: Dmitry Vyukov 
Reported-by: Dmitry Vyukov 
Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/signal.c |6 ++
 1 file changed, 6 insertions(+)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2225,6 +2225,11 @@ relock:
goto relock;
}
 
+   /* Has this task already been marked for death? */
+   ksig->info.si_signo = signr = SIGKILL;
+   if (signal_group_exit(signal))
+   goto fatal;
+
for (;;) {
struct k_sigaction *ka;
 
@@ -2320,6 +2325,7 @@ relock:
continue;
}
 
+   fatal:
spin_unlock_irq(>siglock);
 
/*

[PATCH 4.9 03/24] signal: Always notice exiting tasks

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Eric W. Biederman 

commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.

Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
failing to deliver SIGHUP but always trying.

Upon examination it turns out part of the problem is actually most of
the solution.  Since 2.5 signal delivery has found all fatal signals,
marked the signal group for death, and queued SIGKILL in every threads
thread queue relying on signal->group_exit_code to preserve the
information of which was the actual fatal signal.

The conversion of all fatal signals to SIGKILL results in the
synchronous signal heuristic in next_signal kicking in and preferring
SIGHUP to SIGKILL.  Which is especially problematic as all
fatal signals have already been transformed into SIGKILL.

Instead of dequeueing signals and depending upon SIGKILL to
be the first signal dequeued, first test if the signal group
has already been marked for death.  This guarantees that
nothing in the signal queue can prevent a process that needs
to exit from exiting.

Cc: sta...@vger.kernel.org
Tested-by: Dmitry Vyukov 
Reported-by: Dmitry Vyukov 
Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/signal.c |6 ++
 1 file changed, 6 insertions(+)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2198,6 +2198,11 @@ relock:
goto relock;
}
 
+   /* Has this task already been marked for death? */
+   ksig->info.si_signo = signr = SIGKILL;
+   if (signal_group_exit(signal))
+   goto fatal;
+
for (;;) {
struct k_sigaction *ka;
 
@@ -2293,6 +2298,7 @@ relock:
continue;
}
 
+   fatal:
spin_unlock_irq(>siglock);
 
/*

Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-12 Thread Eric W. Biederman

Oleg Nesterov  writes:

> On 02/12, Eric W. Biederman wrote:
>>
>> > Here I was trying for the simple minimal change and I hit this landmine.
>> > Which leaves me with the question of what should be semantics of signal
>> > handling after exit.
>
> Yes, currently it is undefined. Even signal_pending() is random.
>
>> > I think from dim memory of previous conversations the desired semantics
>> > look like:
>> > a) Ignore all signal state except for SIGKILL.
>> > b) Letting SIGKILL wake up the process should be sufficient.
>
> signal_wake_up(true) to make fatal_signal_pending() == T, I think.
>
>> Oleg any ideas on how to make PTRACE_EVENT_EXIT reliably killable?
>
> My answer is very simple: PTRACE_EVENT_EXIT must not stop if the tracee was
> killed by the "real" SIGKILL (not by group_exit/etc), that is all. But this
> is another user-visible change, it can equally confuse, say, strace (albeit
> not too much iiuc).
>
> But this needs another discussion.

Yes.  Quite.

I will just point out that as described that logic will rebreak Ivan's
program.

>> diff --git a/kernel/signal.c b/kernel/signal.c
>> index 99fa8ff06fd9..a1f154dca73c 100644
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -2544,6 +2544,9 @@ bool get_signal(struct ksignal *ksig)
>> }
>>
>> fatal:
>> +   /* No more signals can be pending past this point */
>> +   sigdelset(>pending.signal, SIGKILL);
>
> Well, this is very confusing. In fact, this is not really correct. Say, we 
> should
> not remove the pending SIGKILL if we are going to call do_coredump(). This is
> possible if ptrace_signal() was called, or after is_current_pgrp_orphaned() 
> returns
> false.

I don't see bugs in it.  But it is certainly subtle and that is not what
is needed right now.

The subtlety is that we will never have a per thread SIGKILL pending
unless signal_group_exit is true.  So removing when it is not there is harmless.

>> +   clear_tsk_thread_flag(current, TIF_SIGPENDING);
>
> I don't understand this change, it looks irrelevant. Possibly makes sense, but
> this connects to "semantics of signal handling after exit".

As on the other the location is too subtle for the regression fix.

The primary motivation is that dequeue_signal calls recalc_sigpending.
And in the common case that will result clearing the TIF_SIGPENDING
which will result in signal_pending being false.

I have not found a location that cares enough to cause a misbehavior
if we don't clear TIF_SIGPENDING but it is a practical change and there
might be.  So if the word of the day is be very conservative and
avoid landminds I expect we need the clearing of TIF_SIGPENDING.

Hmm.  Probably using recalc_sigpending() now that I think about it.

> OK, we need a minimal incremental fix for now. I'd suggest to replace
>
>   ksig->info.si_signo = signr = SIGKILL;
>   if (signal_group_exit(signal))
>   goto fatal;
>
> added by this patch with
>
>   if (__fatal_signal_pending(current)) {
>   ksig->info.si_signo = signr = SIGKILL;
>   sigdelset(>pending.signal, SIGKILL);
>   goto fatal;
>   }
>
> __fatal_signal_pending() is cheaper and looks more understandable.

I definitely agree that it is much less likely to cause a problem
if we move all of the work before jumping to fatal.

The cost of both __fatal_signal_pending and signal_group_exit is just
a cache line read.  So not a big deal wither way.

On the other hand __fatal_signal_pending as currently implemented is
insanely subtle and arguably a bit confusing.  It tests for a SIGKILL in
the current pending sigset, to discover the signal group property of if
a process as started exiting.

In the long run we need our data structures not to be subtle and
tricky to use.  To do that we need a test of something in signal_struct
because it is a per signal group property.  Further we need to remove
the abuse of the per thread SIGKILL.

Since signal_group_exit always implies __fatal_signal_pending in this
case and the reverse.  I see no reason to use a function that requires
we maintain a huge amount of confusing and unnecessary machinery to keep
working.

All of that plus the signal_group_exit test has been tested and shown to
fix an ignored SIGKILL and the only practical problem is it doesn't do
one or two little things that dequeue_signal has done that made it
impossible to stop in PTRACE_EVENT_EXIT.

So for the regression fix let's just do the few little things that
dequeue_signal used to do.  That gives us a strong guarantee that
nothing else was missed.

Eric

Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-12 Thread Oleg Nesterov

On 02/12, Eric W. Biederman wrote:
>
> > Here I was trying for the simple minimal change and I hit this landmine.
> > Which leaves me with the question of what should be semantics of signal
> > handling after exit.

Yes, currently it is undefined. Even signal_pending() is random.

> > I think from dim memory of previous conversations the desired semantics
> > look like:
> > a) Ignore all signal state except for SIGKILL.
> > b) Letting SIGKILL wake up the process should be sufficient.

signal_wake_up(true) to make fatal_signal_pending() == T, I think.

> Oleg any ideas on how to make PTRACE_EVENT_EXIT reliably killable?

My answer is very simple: PTRACE_EVENT_EXIT must not stop if the tracee was
killed by the "real" SIGKILL (not by group_exit/etc), that is all. But this
is another user-visible change, it can equally confuse, say, strace (albeit
not too much iiuc).

But this needs another discussion.

> diff --git a/kernel/signal.c b/kernel/signal.c
> index 99fa8ff06fd9..a1f154dca73c 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2544,6 +2544,9 @@ bool get_signal(struct ksignal *ksig)
> }
>
> fatal:
> +   /* No more signals can be pending past this point */
> +   sigdelset(>pending.signal, SIGKILL);

Well, this is very confusing. In fact, this is not really correct. Say, we 
should
not remove the pending SIGKILL if we are going to call do_coredump(). This is
possible if ptrace_signal() was called, or after is_current_pgrp_orphaned() 
returns
false.

> +   clear_tsk_thread_flag(current, TIF_SIGPENDING);

I don't understand this change, it looks irrelevant. Possibly makes sense, but
this connects to "semantics of signal handling after exit".

OK, we need a minimal incremental fix for now. I'd suggest to replace

ksig->info.si_signo = signr = SIGKILL;
if (signal_group_exit(signal))
goto fatal;

added by this patch with

if (__fatal_signal_pending(current)) {
ksig->info.si_signo = signr = SIGKILL;
sigdelset(>pending.signal, SIGKILL);
goto fatal;
}

__fatal_signal_pending() is cheaper and looks more understandable.

Oleg.

Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-12 Thread Eric W. Biederman

ebied...@xmission.com (Eric W. Biederman) writes:

> Oleg Nesterov  writes:
>
>> sorry again for delay...
>>
>> On 02/07, Eric W. Biederman wrote:
>>>
>>> --- a/kernel/signal.c
>>> +++ b/kernel/signal.c
>>> @@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig)
>>> goto relock;
>>> }
>>>  
>>> +   /* Has this task already been marked for death? */
>>> +   ksig->info.si_signo = signr = SIGKILL;
>>> +   if (signal_group_exit(signal))
>>> +   goto fatal;
>>> +
>>> for (;;) {
>>> struct k_sigaction *ka;
>>>  
>>> @@ -2488,6 +2493,7 @@ bool get_signal(struct ksignal *ksig)
>>> continue;
>>> }
>>>  
>>> +   fatal:
>>> spin_unlock_irq(>siglock);
>>
>> Eric, but this is wrong. At least this is the serious user-visible
>> change.
>>
>> Afaics, with this patch the tracee will never stop in PTRACE_EVENT_EXIT in 
>> case
>> of group_exit/exec, because schedule() in TASK_TRACED state won't block due 
>> to
>> __fatal_signal_pending().
>>
>> Yes, yes, as I said many times the semantics of PTRACE_EVENT_EXIT was never 
>> really
>> defined, it depends on /dev/random, but still I don't think we should break 
>> it even
>> more.
>
> Well it changes PTRACE_EVENT_EXIT I grant that.  It looks like that
> changes makes PTRACE_EVENT_EXIT is less than useful.
>
> The only way to perfectly preserve the previous semantics is probably to
> do something like my JOBCTL_TASK_EXIT proposal.
>
> That said I don't think even adding a JOBCTL_TASK_EXIT is enough to have
> a reliable stop of ptrace_event_exit after a process has exited.  As any
> other pending signal can cause problems there as well.
>
> I have received a report that strace -f in some cases is not noticing
> children before they die and it looks like a stop in PTRACE_EVENT_EXIT
> would fix that strace behavior.
>
> Sigh.
>
> Here I was trying for the simple minimal change and I hit this landmine.
> Which leaves me with the question of what should be semantics of signal
> handling after exit.
>
> I think from dim memory of previous conversations the desired semantics
> look like:
> a) Ignore all signal state except for SIGKILL.
> b) Letting SIGKILL wake up the process should be sufficient.
>
> I will see if I can reproduce the strace failure and see if I can cook
> up something minimal that addresses just that.  If you have suggestions
> I would love to hear them.
>
> As this was a minimal fix for SIGKILL being broken I have already sent
> the fix to Linus.  So we are looking at an incremental fix at this
> point.

In my testing I found something that concerns me.  Because we wind up
with SIGKILL in shard_pending we can not kill a process in do_exit that
has stopped at PTRACE_EVENT_EXIT.  That bug seems to go back a long ways.

Other than that, it looks like we can do the following to fix the
regression I introduced.

Oleg any ideas on how to make PTRACE_EVENT_EXIT reliably killable?

diff --git a/kernel/signal.c b/kernel/signal.c
index 99fa8ff06fd9..a1f154dca73c 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2544,6 +2544,9 @@ bool get_signal(struct ksignal *ksig)
}
 
fatal:
+   /* No more signals can be pending past this point */
+   sigdelset(>pending.signal, SIGKILL);
+   clear_tsk_thread_flag(current, TIF_SIGPENDING);
spin_unlock_irq(>siglock);
 
/*

Eric

Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-11 Thread Eric W. Biederman

Oleg Nesterov  writes:

> sorry again for delay...
>
> On 02/07, Eric W. Biederman wrote:
>>
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig)
>>  goto relock;
>>  }
>>  
>> +/* Has this task already been marked for death? */
>> +ksig->info.si_signo = signr = SIGKILL;
>> +if (signal_group_exit(signal))
>> +goto fatal;
>> +
>>  for (;;) {
>>  struct k_sigaction *ka;
>>  
>> @@ -2488,6 +2493,7 @@ bool get_signal(struct ksignal *ksig)
>>  continue;
>>  }
>>  
>> +fatal:
>>  spin_unlock_irq(>siglock);
>
> Eric, but this is wrong. At least this is the serious user-visible
> change.
>
> Afaics, with this patch the tracee will never stop in PTRACE_EVENT_EXIT in 
> case
> of group_exit/exec, because schedule() in TASK_TRACED state won't block due to
> __fatal_signal_pending().
>
> Yes, yes, as I said many times the semantics of PTRACE_EVENT_EXIT was never 
> really
> defined, it depends on /dev/random, but still I don't think we should break 
> it even
> more.

Well it changes PTRACE_EVENT_EXIT I grant that.  It looks like that
changes makes PTRACE_EVENT_EXIT is less than useful.

The only way to perfectly preserve the previous semantics is probably to
do something like my JOBCTL_TASK_EXIT proposal.

That said I don't think even adding a JOBCTL_TASK_EXIT is enough to have
a reliable stop of ptrace_event_exit after a process has exited.  As any
other pending signal can cause problems there as well.

I have received a report that strace -f in some cases is not noticing
children before they die and it looks like a stop in PTRACE_EVENT_EXIT
would fix that strace behavior.

Sigh.

Here I was trying for the simple minimal change and I hit this landmine.
Which leaves me with the question of what should be semantics of signal
handling after exit.

I think from dim memory of previous conversations the desired semantics
look like:
a) Ignore all signal state except for SIGKILL.
b) Letting SIGKILL wake up the process should be sufficient.

I will see if I can reproduce the strace failure and see if I can cook
up something minimal that addresses just that.  If you have suggestions
I would love to hear them.

As this was a minimal fix for SIGKILL being broken I have already sent
the fix to Linus.  So we are looking at an incremental fix at this point.

Eric

Re: DMCA takedown notice

2019-02-11 Thread mikeeusa

You take it down or I sue you, simple as that.

I have revoked the license from a number of people, including the John
Doe who has chosen to violate my copyright thence-forth.

I have signed using my 2 decades long held pen-name.

The U.S. Code defines an electronic signature for the purpose of US law
as "an electronic sound, symbol, or process, attached to or logically
associated with a contract or other record and executed or adopted by a
person with the intent to sign the record."

My signing with my pen-name suffices for this purpose. What is important
is my intent to sign the record, which I have evinced.

I have also posted the information on my long-held project page, so that
you may know that I am me:

https://sourceforge.net/projects/gpcslots2/files/notes/

https://sourceforge.net/projects/gpcslots2/files/notes/tkdnreq_github.txt/download
https://sourceforge.net/projects/gpcslots2/files/notes/takedownreq_vs_johndoe-of-8ch.txt/download

(I have also uploaded this response to said /notes/ directory)

In addition to many other places.
Your contention that I must do anything greater at this point is legally
inefficacious.

I _DEMAND_ that you take the offending material down immediately.

--MikeeUSA--
(Author of GPC-Slots 2)
(electronic signature)

On 2019-02-06 21:20, GitHub Staff wrote:

Hi MikeeUSA,

Thank you for your notices, the most recent of which is included below
for reference.

This DMCA notice is incomplete. It lacks "A physical or electronic
signature of a person authorized to act on behalf of the owner of an
exclusive right that is allegedly infringed" and "Information
reasonably sufficient to permit the service provider to contact the
complaining party."

Unfortunately, an electronic signature must be a legal name, not a
monicker or username, and we cannot accept disposable or temporary
email addresses as reliable contact information for a DMCA notice.

Once you've revised your notice to include the required details,
please send back the entire revised notice, and not only the corrected
sections. Once we've received a complete and actionable notice, we'll
process it expeditiously.

Thanks,

GitHub Staff
-

I have a good faith belief that use of the copyrighted materials
described above on the infringing web pages is not authorized by the
copyright owner, or its agent, or the law. I have taken fair use into
consideration.

I swear, under penalty of perjury, that the information in this
notification is accurate and that I am the copyright owner, or am
authorized to act on behalf of the owner, of an exclusive right that
is allegedly infringed.
:

As you may know, In the United States; a license, absent an attached
interest, is revocable.

A "John Doe" had his non-exclusive license regarding the game
"GPC-Slots2" terminated by the copyright owner (me: MikeeUSA).
The copyright owner may do this as-of-right, unless there is an
attached interest (ie: unless the licensee paid good consideration for
the license).

The "John Doe" then proceeded to belligerently upload a copy of
"GPC-Slots2" to your host, GitHub.
This violated Author's (my) copyright, since "John Doe"'s gratuitous
bare license had been terminated by the copyright holder (me).

The "John Doe" then proceeded to modify my work, which again violated
my copyright since I had previously revoked his license.
The license flows from me, the copyright owner, not any text. It is
permission to use, redistribute, modify, etc. Instructions on how to
use my property.
When such permission is not supported by any consideration, it may be
rescinded by the owner, at his will.
(/Regardless/ of the "terms". "Terms" are only enforceable against the
grantor if the licensee has paid consideration for them, essentially,
under US law.)

I have done so.

I reiterated to the "John Doe" that his license had been terminated.

"John Doe" then informed me that I "can't do that". I tried to explain
to him US law.
"John Doe" declared that he did not care and would keep the violating
work up, in defiance of me.
(IE: he would "pirate" it)

He then cited works from a discredited paralegal while I cited
published works by lawyers studied in their field.

(Note: I make no claim to PERL, the color ansi library, any supporting
libraries, or the -2 split screen function. My copyright covers the
game code of GPC-Slots2. I (MikeeUSA) am the original author of the
work and never signed over copyright to the work.)
(Note: "obeying the terms" (obeying the copyright holders instructions
regarding the use of his property) is not consideration: it is a
preexisting legal duty: outside of the "terms" there is no right for
the licensee to copy, modify, make derivative works, distribute,
distribute derivative works)

[Additionally "John Doe" registered a fra

Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-11 Thread Oleg Nesterov

sorry again for delay...

On 02/07, Eric W. Biederman wrote:
>
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig)
>   goto relock;
>   }
>  
> + /* Has this task already been marked for death? */
> + ksig->info.si_signo = signr = SIGKILL;
> + if (signal_group_exit(signal))
> + goto fatal;
> +
>   for (;;) {
>   struct k_sigaction *ka;
>  
> @@ -2488,6 +2493,7 @@ bool get_signal(struct ksignal *ksig)
>   continue;
>   }
>  
> + fatal:
>   spin_unlock_irq(>siglock);

Eric, but this is wrong. At least this is the serious user-visible change.

Afaics, with this patch the tracee will never stop in PTRACE_EVENT_EXIT in case
of group_exit/exec, because schedule() in TASK_TRACED state won't block due to
__fatal_signal_pending().

Yes, yes, as I said many times the semantics of PTRACE_EVENT_EXIT was never 
really
defined, it depends on /dev/random, but still I don't think we should break it 
even
more.

Oleg.

[PATCH 1/2] signal: Always notice exiting tasks

2019-02-06 Thread Eric W. Biederman



Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
failing to deliver SIGHUP but always trying.

Upon examination it turns out part of the problem is actually most of
the solution.  Since 2.5 signal delivery has found all fatal signals,
marked the signal group for death, and queued SIGKILL in every threads
thread queue relying on signal->group_exit_code to preserve the
information of which was the actual fatal signal.

The conversion of all fatal signals to SIGKILL results in the
synchronous signal heuristic in next_signal kicking in and preferring
SIGHUP to SIGKILL.  Which is especially problematic as all
fatal signals have already been transformed into SIGKILL.

Instead of dequeueing signals and depending upon SIGKILL to
be the first signal dequeued, first test if the signal group
has already been marked for death.  This guarantees that
nothing in the signal queue can prevent a process that needs
to exit from exiting.

Cc: sta...@vger.kernel.org
Reported-by: Dmitry Vyukov 
Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
---
 kernel/signal.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/signal.c b/kernel/signal.c
index 9ca8e5278c8e..5424cb0006bc 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig)
goto relock;
}
 
+   /* Has this task already been marked for death? */
+   ksig->info.si_signo = signr = SIGKILL;
+   if (signal_group_exit(signal))
+   goto fatal;
+
for (;;) {
struct k_sigaction *ka;
 
@@ -2488,6 +2493,7 @@ bool get_signal(struct ksignal *ksig)
continue;
}
 
+   fatal:
spin_unlock_irq(>siglock);
 
/*
-- 
2.17.1

DMCA takedown notice - GPC-Slots 2 (after GPL Revocation from "John Doe")

2019-01-31 Thread mikeeusa

**Please provide a detailed description of the original copyrighted work 
that has allegedly been infringed. If possible, include a URL to where 
it is posted online.**


GPC-Slots 2 is a text-mode casino game I created. It includes 5 slot 
machines, 3 table games (Sic Bo, Craps, and 2 variations of the little 
wheel), plus Russian Roulette and a stock market.

You can enjoy it from here: https://sourceforge.net/projects/gpcslots2/

*What files should be taken down? Please provide URLs for each file, or 
if the entire repository, the repository's URL:**


http://github.com/MikeeUSA/GPC-Slots-2

**Have you searched for any forks of the allegedly infringing files or 
repositories? Each fork is a distinct repository and must be identified 
separately if you believe it is infringing and wish to have it taken 
down.**


Yes, they are also on other platforms, all uploaded by the "John Doe"

**Is the work licensed under an open source license? If so, which open 
source license? Are the allegedly infringing files being used under the 
open source license, or are they in violation of the license?**


Yes. The GPL. However I had revoked the "John Doe"'s license. The 
license, in this instance, being a bare license.

A license without an interest attached is revocable, in the USA.
The "John Doe" was not in privity of contract with me, and had not paid 
me anything for the work.
It was licensed to him under a bare license, which had then been 
rescinded.
He thus had not, and does not have, any permission to use, modify, 
distribute, nor make derivative works of the aforementioned work.
Remeber: the license comes from me, the Copyright owner. Not from any 
document or record: that is simply a memorandum of the terms.
I have chosen to revoke the "John Doe"'s license, and not issue any to 
him further. He has been informed of this.

His actions there-after and at current are infringing.

**What would be the best solution for the alleged infringement? Are 
there specific changes the other person can make other than removal?**


The only solution that I will accept is you acquiescing to my demand of 
removal.


**Do you have the alleged infringer's contact information? If so, please 
provide it:**


No. You can ask him for it here: 8ch.net/tech/res/1018729.html
You can also contact the "John Doe" through the email he registered with 
you. Don't play dumb.


**Please confirm that you have you have read our Guide to Submitting a 
DMCA Takedown Notice: 
https://help.github.com/articles/guide-to-submitting-a-dmca-takedown-notice/**


I really do not give half a damn about your guide. It is patronizing and 
moronic, it sounds as if it were written by a woman, perhaps a 
paralegal.
The fact of the matter is that a bare license is revocable by the 
grantor.
To achieve an irrevocable license one must generally enter into a 
copyright license contract with the licensor, supported by good 
consideration.
"Obeying the license" is not good consideration as it is a pre-existing 
legal duty.


**So that we can get back to you, please provide either your telephone 
number or physical address:**


Contact me at mikee...@redchan.it

I have a good faith belief that use of the copyrighted materials 
described above on the infringing web pages is not authorized by the 
copyright owner, or its agent, or the law. I have taken fair use into 
consideration.


I swear, under penalty of perjury, that the information in this 
notification is accurate and that I am the copyright owner, or am 
authorized to act on behalf of the owner, of an exclusive right that is 
allegedly infringed.


**Please type your full legal name below to sign this request:**

I'm signing with my long-held nom de guerre. Think of it as an X

--MikeeUSA--

DMCA takedown notice (GPC-Slots2, bare license was revoked from "John Doe")

2019-01-30 Thread mikeeusa

I have a good faith belief that use of the copyrighted materials 
described above on the infringing web pages is not authorized by the 
copyright owner, or its agent, or the law. I have taken fair use into 
consideration.


I swear, under penalty of perjury, that the information in this 
notification is accurate and that I am the copyright owner, or am 
authorized to act on behalf of the owner, of an exclusive right that is 
allegedly infringed.

:


As you may know, In the United States; a license, absent an attached 
interest, is revocable.


A "John Doe" had his non-exclusive license regarding the game 
"GPC-Slots2" terminated by the copyright owner (me: MikeeUSA).
The copyright owner may do this as-of-right, unless there is an attached 
interest (ie: unless the licensee paid good consideration for the 
license).


The "John Doe" then proceeded to belligerently upload a copy of 
"GPC-Slots2" to your host, GitHub.
This violated Author's (my) copyright, since "John Doe"'s gratuitous 
bare license had been terminated by the copyright holder (me).


The "John Doe" then proceeded to modify my work, which again violated my 
copyright since I had previously revoked his license.
The license flows from me, the copyright owner, not any text. It is 
permission to use, redistribute, modify, etc. Instructions on how to use 
my property.
When such permission is not supported by any consideration, it may be 
rescinded by the owner, at his will.
(/Regardless/ of the "terms". "Terms" are only enforceable against the 
grantor if the licensee has paid consideration for them, essentially, 
under US law.)


I have done so.

I reiterated to the "John Doe" that his license had been terminated.

"John Doe" then informed me that I "can't do that". I tried to explain 
to him US law.
"John Doe" declared that he did not care and would keep the violating 
work up, in defiance of me.

(IE: he would "pirate" it)

He then cited works from a discredited paralegal while I cited published 
works by lawyers studied in their field.


(Note: I make no claim to PERL, the color ansi library, any supporting 
libraries, or the -2 split screen function. My copyright covers the game 
code of GPC-Slots2. I (MikeeUSA) am the original author of the work and 
never signed over copyright to the work.)
(Note: "obeying the terms" (obeying the copyright holders instructions 
regarding the use of his property) is not consideration: it is a 
preexisting legal duty: outside of the "terms" there is no right for the 
licensee to copy, modify, make derivative works, distribute, distribute 
derivative works)


[Additionally "John Doe" registered a fraudulent account under my 
long-held non-de-gurre, adding a Code of Conduct ("CoC"), something I 
would never do (being opposed to "CoC" for gratis projects on 
principal)]


I now have no choice but to issue a DMCA take-down request, to you, 
GitHub.


Regrettably;
--MikeeUSA--
(electronic signature)
Jan 29, 2019

(Addendum: "John Doe" then uploaded the modified work to gitlab.com and 
bitbucket.org


Contact information:
email: mikee...@redchan.it

infringing content: github.com/MikeeUSA/GPC-Slots-2
gitlab.com/MikeeUSA/GPC-Slots-2
bitbucket.org/MikeeUSA/gpc-slots-2
The material is not authorized by me, the copyright owner of the 
GPC-Slots2 game code, as I explicitly rescinded the license from the 
"John Doe", and he acknowledged that I had informed him of such and 
communicated that he would defy my will regarding my property and 
copyright.
Everything stated within this above communication is accurate to the 
best of my knowledge and ability.


Some notices to you, github (and now gitlab and bitbucket):
1) Yes I viewed your page at: 
https://help.github.com/articles/guide-to-submitting-a-dmca-takedown-notice/

2) Yes this is "opensource" code.
3) No that does not matter:
The GPL(any version), being a bare license, is revocable 
("retroactively").

Just as any bare license, not supported by an interest, in the US.
The "John Doe" is not in privity of contract with me and has paid me no 
consideration.

He cannot "bind" me (the grantor) to the terms.
It is his duty to abide by my instructions regarding my property.
I did not transfer my property away, the license is just that: a license 
(temporary permission, that can be rescinded unless a "term" was indeed 
"purchased")
It is also his duty to cease all use, modification, distribution of my 
property at my demand.

I have made such a demand.
4) Yes I will consider taking legal action against you if you do not 
heed my request.
Cite the paralegal from groklaw, ZDnet, the FSF, and the SFConservancy 
all you want.

They are wrong on the law and have been wrong for 1

DMCA takedown notice (GPC-Slots2, bare license was revoked from "John Doe")

2019-01-30 Thread mikeeusa

I have a good faith belief that use of the copyrighted materials 
described above on the infringing web pages is not authorized by the 
copyright owner, or its agent, or the law. I have taken fair use into 
consideration.


I swear, under penalty of perjury, that the information in this 
notification is accurate and that I am the copyright owner, or am 
authorized to act on behalf of the owner, of an exclusive right that is 
allegedly infringed.

:


As you may know, In the United States; a license, absent an attached 
interest, is revocable.


A "John Doe" had his non-exclusive license regarding the game 
"GPC-Slots2" terminated by the copyright owner (me: MikeeUSA).
The copyright owner may do this as-of-right, unless there is an attached 
interest (ie: unless the licensee paid good consideration for the 
license).


The "John Doe" then proceeded to belligerently upload a copy of 
"GPC-Slots2" to your host, GitHub.
This violated Author's (my) copyright, since "John Doe"'s gratuitous 
bare license had been terminated by the copyright holder (me).


The "John Doe" then proceeded to modify my work, which again violated my 
copyright since I had previously revoked his license.
The license flows from me, the copyright owner, not any text. It is 
permission to use, redistribute, modify, etc. Instructions on how to use 
my property.
When such permission is not supported by any consideration, it may be 
rescinded by the owner, at his will.
(/Regardless/ of the "terms". "Terms" are only enforceable against the 
grantor if the licensee has paid consideration for them, essentially, 
under US law.)


I have done so.

I reiterated to the "John Doe" that his license had been terminated.

"John Doe" then informed me that I "can't do that". I tried to explain 
to him US law.
"John Doe" declared that he did not care and would keep the violating 
work up, in defiance of me.

(IE: he would "pirate" it)

He then cited works from a discredited paralegal while I cited published 
works by lawyers studied in their field.


(Note: I make no claim to PERL, the color ansi library, any supporting 
libraries, or the -2 split screen function. My copyright covers the game 
code of GPC-Slots2. I (MikeeUSA) am the original author of the work and 
never signed over copyright to the work.)
(Note: "obeying the terms" (obeying the copyright holders instructions 
regarding the use of his property) is not consideration: it is a 
preexisting legal duty: outside of the "terms" there is no right for the 
licensee to copy, modify, make derivative works, distribute, distribute 
derivative works)


[Additionally "John Doe" registered a fraudulent account under my 
long-held non-de-gurre, adding a Code of Conduct ("CoC"), something I 
would never do (being opposed to "CoC" for gratis projects on 
principal)]


I now have no choice but to issue a DMCA take-down request, to you, 
GitHub.


Regrettably;
--MikeeUSA--
(electronic signature)
Jan 29, 2019

(Addendum: "John Doe" then uploaded the modified work to gitlab.com and 
bitbucket.org


Contact information:
email: mikee...@redchan.it

infringing content: github.com/MikeeUSA/GPC-Slots-2
gitlab.com/MikeeUSA/GPC-Slots-2
bitbucket.org/MikeeUSA/gpc-slots-2
The material is not authorized by me, the copyright owner of the 
GPC-Slots2 game code, as I explicitly rescinded the license from the 
"John Doe", and he acknowledged that I had informed him of such and 
communicated that he would defy my will regarding my property and 
copyright.
Everything stated within this above communication is accurate to the 
best of my knowledge and ability.


Some notices to you, github (and now gitlab and bitbucket):
1) Yes I viewed your page at: 
https://help.github.com/articles/guide-to-submitting-a-dmca-takedown-notice/

2) Yes this is "opensource" code.
3) No that does not matter:
The GPL(any version), being a bare license, is revocable 
("retroactively").

Just as any bare license, not supported by an interest, in the US.
The "John Doe" is not in privity of contract with me and has paid me no 
consideration.

He cannot "bind" me (the grantor) to the terms.
It is his duty to abide by my instructions regarding my property.
I did not transfer my property away, the license is just that: a license 
(temporary permission, that can be rescinded unless a "term" was indeed 
"purchased")
It is also his duty to cease all use, modification, distribution of my 
property at my demand.

I have made such a demand.
4) Yes I will consider taking legal action against you if you do not 
heed my request.
Cite the paralegal from groklaw, ZDnet, the FSF, and the SFConservancy 
all you want.

They are wrong on the law and have been wrong for 1

Re: [patch 1/9] block: Cleanup license notice

2019-01-17 Thread Jens Axboe

On 1/17/19 4:14 PM, Thomas Gleixner wrote:
> Remove the imprecise and sloppy:
> 
>   "This files is licensed under the GPL."
> 
> license notice in the top level comment.
> 
> 1) The file already contains a SPDX license identifier which clearly
>states that the license of the file is GPL V2 only
> 
> 2) The notice resolves to GPL v1 or later for scanners which is just
>contrary to the intent of SPDX identifiers to provide clear and non
>ambiguous license information. Aside of that the value add of this
>notice is below zero,

Applied, thanks Thomas.

-- 
Jens Axboe

Re: [patch 1/9] block: Cleanup license notice

2019-01-17 Thread Bart Van Assche


On 1/17/19 3:14 PM, Thomas Gleixner wrote:

Remove the imprecise and sloppy:

   "This files is licensed under the GPL."

license notice in the top level comment.

1) The file already contains a SPDX license identifier which clearly
states that the license of the file is GPL V2 only

2) The notice resolves to GPL v1 or later for scanners which is just
contrary to the intent of SPDX identifiers to provide clear and non
ambiguous license information. Aside of that the value add of this
notice is below zero,


My intent was to release this under GPL v2, hence:

Reviewed-by: Bart Van Assche

[patch 1/9] block: Cleanup license notice

2019-01-17 Thread Thomas Gleixner

Remove the imprecise and sloppy:

  "This files is licensed under the GPL."

license notice in the top level comment.

1) The file already contains a SPDX license identifier which clearly
   states that the license of the file is GPL V2 only

2) The notice resolves to GPL v1 or later for scanners which is just
   contrary to the intent of SPDX identifiers to provide clear and non
   ambiguous license information. Aside of that the value add of this
   notice is below zero,

Fixes: 6a5ac9846508 ("block: Make struct request_queue smaller for 
CONFIG_BLK_DEV_ZONED=n")
Signed-off-by: Thomas Gleixner 
Cc: Bart Van Assche 
Cc: Damien Le Moal 
Cc: Matias Bjorling 
Cc: Christoph Hellwig 
Cc: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
---

P.S.: This patch is part of a larger cleanup, but independent of other
  patches and is intended to be picked up by the maintainer directly.

 block/blk-mq-debugfs-zoned.c |2 --
 1 file changed, 2 deletions(-)

--- a/block/blk-mq-debugfs-zoned.c
+++ b/block/blk-mq-debugfs-zoned.c
@@ -1,8 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
  * Copyright (C) 2017 Western Digital Corporation or its affiliates.
- *
- * This file is released under the GPL.
  */
 
 #include

Dear Beneficiary, FINAL NOTICE

2018-07-19 Thread Paul

Attention: linux-kernel@vger.kernel.org,
 
FINAL NOTICE
We have been instructed to arrange your funds/payment via Online Banking & 
Loaded ATM Cards delivery to you.
Your response very urgent for more details!

Sincerely yours,
Eddie. P.

Dear Beneficiary, FINAL NOTICE

2018-07-19 Thread Paul

Attention: linux-kernel@vger.kernel.org,
 
FINAL NOTICE
We have been instructed to arrange your funds/payment via Online Banking & 
Loaded ATM Cards delivery to you.
Your response very urgent for more details!

Sincerely yours,
Eddie. P.

Important Notice...Reply Now

2018-07-12 Thread Richard & Angela Maxwell

My wife and I won the Euro Millions Lottery of £53 Million British Pounds and 
we have voluntarily decided to donate 1,000,000EUR(One Million Euros) to 5 
individuals randomly as part of our own charity project.
 
To verify our lottery winnings,please see our interview by visiting the web 
page below:

telegraph.co.uk/news/newstopics/howaboutthat/11511467/Lincolnshire-couple-win-53m-on-EuroMillions.html
 
Your email address was among the emails which were submitted to us by the 
Google Inc. as a web user; if you have received our email,kindly send us the 
below details so that we can transfer your 1,000,000.00 EUR(One Million Euros) 
to you in your own country.

Full Names:
Mobile No:
Age:
Occupation:
Country:

Send your response to: rmaxwel...@yahoo.com

Best Regards,
Richard & Angela Maxwell

Important Notice...Reply Now

2018-07-12 Thread Richard & Angela Maxwell

My wife and I won the Euro Millions Lottery of £53 Million British Pounds and 
we have voluntarily decided to donate 1,000,000EUR(One Million Euros) to 5 
individuals randomly as part of our own charity project.
 
To verify our lottery winnings,please see our interview by visiting the web 
page below:

telegraph.co.uk/news/newstopics/howaboutthat/11511467/Lincolnshire-couple-win-53m-on-EuroMillions.html
 
Your email address was among the emails which were submitted to us by the 
Google Inc. as a web user; if you have received our email,kindly send us the 
below details so that we can transfer your 1,000,000.00 EUR(One Million Euros) 
to you in your own country.

Full Names:
Mobile No:
Age:
Occupation:
Country:

Send your response to: rmaxwel...@yahoo.com

Best Regards,
Richard & Angela Maxwell

Re: Important Notice. (Treat As Urgent)

2018-03-29 Thread omar . gamez01

Good Day and congratulations . My Client Mrs. Marilyn Boldon has made a 
donation 3.5m euros to you, contact her through her private email: 
marilynbol...@gmail.com for more detail on how to receive this donation.

Barrister. Omar Gamez Vargas. Esq.
M.Williams Chambers and Associates.

Re: Important Notice. (Treat As Urgent)

2018-03-29 Thread omar . gamez01

Good Day and congratulations . My Client Mrs. Marilyn Boldon has made a 
donation 3.5m euros to you, contact her through her private email: 
marilynbol...@gmail.com for more detail on how to receive this donation.

Barrister. Omar Gamez Vargas. Esq.
M.Williams Chambers and Associates.

[PATCH] usb: hub: Reduce warning to notice on power loss

2018-03-22 Thread Tomeu Vizoso

Currently we warn the user when the root hub lost power after resume,
but the user cannot do anything about it so it should probably be a
notice.

This will reduce the noise in the console during suspend and resume,
which is already quite significant in many systems.

Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
---
 drivers/usb/core/hub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index ac7bab772a3a..5964008003b4 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3655,7 +3655,7 @@ static int hub_reset_resume(struct usb_interface *intf)
  */
 void usb_root_hub_lost_power(struct usb_device *rhdev)
 {
-   dev_warn(>dev, "root hub lost power or was reset\n");
+   dev_notice(>dev, "root hub lost power or was reset\n");
rhdev->reset_resume = 1;
 }
 EXPORT_SYMBOL_GPL(usb_root_hub_lost_power);
-- 
2.14.3

[PATCH] usb: hub: Reduce warning to notice on power loss

2018-03-22 Thread Tomeu Vizoso

Currently we warn the user when the root hub lost power after resume,
but the user cannot do anything about it so it should probably be a
notice.

This will reduce the noise in the console during suspend and resume,
which is already quite significant in many systems.

Signed-off-by: Tomeu Vizoso 
---
 drivers/usb/core/hub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index ac7bab772a3a..5964008003b4 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3655,7 +3655,7 @@ static int hub_reset_resume(struct usb_interface *intf)
  */
 void usb_root_hub_lost_power(struct usb_device *rhdev)
 {
-   dev_warn(>dev, "root hub lost power or was reset\n");
+   dev_notice(>dev, "root hub lost power or was reset\n");
rhdev->reset_resume = 1;
 }
 EXPORT_SYMBOL_GPL(usb_root_hub_lost_power);
-- 
2.14.3

Re: Official Notice

2018-03-14 Thread Shalom Saada Saar

This email just won a sum of €5,000,000. For claims, Send your NAME, AGE & 
TELEPHONE NUMBER to:  mastercard-awa...@columbus.rr.com

Re: Official Notice

2018-03-14 Thread Shalom Saada Saar

This email just won a sum of €5,000,000. For claims, Send your NAME, AGE & 
TELEPHONE NUMBER to:  mastercard-awa...@columbus.rr.com

Consent Notice

2018-02-18 Thread Mr.Lee

Important details to share with you, kindly email me for info: 
"leeguo...@gmail.com" Mr.Lee

Consent Notice

2018-02-18 Thread Mr.Lee

Important details to share with you, kindly email me for info: 
"leeguo...@gmail.com" Mr.Lee

NOTICE!

2018-01-06 Thread SOMJATE MOOSIRILERT

SOMJATE MOOSIRILERT
Senior Executive Vice President
Thanachart Bank PCL
Bangkok Thailand

Attention: BENEFICIARY

A woman came to my office few days ago with a letter, claiming to be your true 
representative to your inheritance funds of $43.6m. Here are her information:

Please do reconfirm to this office, as a matter of urgency if this woman is 
from you so the bank Will not be held responsible for paying into the wrong 
account name.

However, we shall proceed to issue all payments details to the said 
Mrs.Petermann if we do not hear from you within the next seven working days 
from today.

You should forward all your information

1 Your full name and address
2 Your phone and fax number
3 Your state id

Best regards,

SOMJATE MOOSIRILERT
Senior Executive Vice President
Thanachart Bank PCL
Bangkok Thailand

NOTICE!

2018-01-06 Thread SOMJATE MOOSIRILERT

SOMJATE MOOSIRILERT
Senior Executive Vice President
Thanachart Bank PCL
Bangkok Thailand

Attention: BENEFICIARY

A woman came to my office few days ago with a letter, claiming to be your true 
representative to your inheritance funds of $43.6m. Here are her information:

Please do reconfirm to this office, as a matter of urgency if this woman is 
from you so the bank Will not be held responsible for paying into the wrong 
account name.

However, we shall proceed to issue all payments details to the said 
Mrs.Petermann if we do not hear from you within the next seven working days 
from today.

You should forward all your information

1 Your full name and address
2 Your phone and fax number
3 Your state id

Best regards,

SOMJATE MOOSIRILERT
Senior Executive Vice President
Thanachart Bank PCL
Bangkok Thailand

[PATCH v6 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-10-13 Thread Joe Lawrence

klp_complete_transition() performs a bit of housework before a
transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
(including post-(un)patch callbacks).  To be consistent, move the
transition "complete" kernel log notice out of
klp_try_complete_transition() and into klp_complete_transition().

Suggested-by: Josh Poimboeuf <jpoim...@redhat.com>
Signed-off-by: Joe Lawrence <joe.lawre...@redhat.com>
Acked-by: Miroslav Benes <mbe...@suse.cz>
Reviewed-by: Petr Mladek <pmla...@suse.com>
---
 kernel/livepatch/transition.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
index 7bf55b7f3687..53887f0bca10 100644
--- a/kernel/livepatch/transition.c
+++ b/kernel/livepatch/transition.c
@@ -136,6 +136,9 @@ static void klp_complete_transition(void)
klp_post_unpatch_callback(obj);
}
 
+   pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
/*
 * See complementary comment in __klp_enable_patch() for why we
 * keep the module reference for immediate patches.
@@ -423,9 +426,6 @@ void klp_try_complete_transition(void)
}
 
 success:
-   pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
- klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
-
/* we're done, now cleanup the data structures */
klp_complete_transition();
 }
-- 
1.8.3.1

[PATCH v6 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-10-13 Thread Joe Lawrence

klp_complete_transition() performs a bit of housework before a
transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
(including post-(un)patch callbacks).  To be consistent, move the
transition "complete" kernel log notice out of
klp_try_complete_transition() and into klp_complete_transition().

Suggested-by: Josh Poimboeuf 
Signed-off-by: Joe Lawrence 
Acked-by: Miroslav Benes 
Reviewed-by: Petr Mladek 
---
 kernel/livepatch/transition.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
index 7bf55b7f3687..53887f0bca10 100644
--- a/kernel/livepatch/transition.c
+++ b/kernel/livepatch/transition.c
@@ -136,6 +136,9 @@ static void klp_complete_transition(void)
klp_post_unpatch_callback(obj);
}
 
+   pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
/*
 * See complementary comment in __klp_enable_patch() for why we
 * keep the module reference for immediate patches.
@@ -423,9 +426,6 @@ void klp_try_complete_transition(void)
}
 
 success:
-   pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
- klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
-
/* we're done, now cleanup the data structures */
klp_complete_transition();
 }
-- 
1.8.3.1

[PATCH v8 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

2017-10-10 Thread Mauro Carvalho Chehab

The documentation doesn't mention if vdev-centric hardware
control would have subdev API or not.

Add a notice about that, reflecting the current status, where
three drivers use it, in order to support some subdev-specific
controls.

Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com>
Acked-by: Hans Verkuil <hans.verk...@cisco.com>
---
 Documentation/media/uapi/v4l/open.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index 58ab75959584..ccdf53ab347c 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -62,6 +62,13 @@ 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.
 
+.. note::
+
+   A **vdevnode-centric** may also optionally expose V4L2 sub-devices via
+   :ref:`sub-device API `. In that case, it has to implement
+   the :ref:`media controller API ` as well.
+
+
 .. attention::
 
Devices that require **MC-centric** media hardware control should
-- 
2.13.6

[PATCH v8 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

2017-10-10 Thread Mauro Carvalho Chehab

The documentation doesn't mention if vdev-centric hardware
control would have subdev API or not.

Add a notice about that, reflecting the current status, where
three drivers use it, in order to support some subdev-specific
controls.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/open.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index 58ab75959584..ccdf53ab347c 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -62,6 +62,13 @@ 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.
 
+.. note::
+
+   A **vdevnode-centric** may also optionally expose V4L2 sub-devices via
+   :ref:`sub-device API `. In that case, it has to implement
+   the :ref:`media controller API ` as well.
+
+
 .. attention::
 
Devices that require **MC-centric** media hardware control should
-- 
2.13.6

[PATCH v1 6/6] platform/x86: intel_ips: Remove FSF address from GPL notice

2017-10-05 Thread Andy Shevchenko

This patch removes the FSF address from the GPL notice to fix a
checkpatch.pl CHECK message.

Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
 drivers/platform/x86/intel_ips.c | 4 
 drivers/platform/x86/intel_ips.h | 4 
 2 files changed, 8 deletions(-)

diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c
index 9f5afdd123bb..680ab4fd7087 100644
--- a/drivers/platform/x86/intel_ips.c
+++ b/drivers/platform/x86/intel_ips.c
@@ -10,10 +10,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
- *
  * The full GNU General Public License is included in this distribution in
  * the file called "COPYING".
  *
diff --git a/drivers/platform/x86/intel_ips.h b/drivers/platform/x86/intel_ips.h
index 73299beff5b3..60f4e3ddbe9f 100644
--- a/drivers/platform/x86/intel_ips.h
+++ b/drivers/platform/x86/intel_ips.h
@@ -10,10 +10,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
- *
  * The full GNU General Public License is included in this distribution in
  * the file called "COPYING".
  */
-- 
2.14.2

[PATCH v1 6/6] platform/x86: intel_ips: Remove FSF address from GPL notice

2017-10-05 Thread Andy Shevchenko

This patch removes the FSF address from the GPL notice to fix a
checkpatch.pl CHECK message.

Signed-off-by: Andy Shevchenko 
---
 drivers/platform/x86/intel_ips.c | 4 
 drivers/platform/x86/intel_ips.h | 4 
 2 files changed, 8 deletions(-)

diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c
index 9f5afdd123bb..680ab4fd7087 100644
--- a/drivers/platform/x86/intel_ips.c
+++ b/drivers/platform/x86/intel_ips.c
@@ -10,10 +10,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
- *
  * The full GNU General Public License is included in this distribution in
  * the file called "COPYING".
  *
diff --git a/drivers/platform/x86/intel_ips.h b/drivers/platform/x86/intel_ips.h
index 73299beff5b3..60f4e3ddbe9f 100644
--- a/drivers/platform/x86/intel_ips.h
+++ b/drivers/platform/x86/intel_ips.h
@@ -10,10 +10,6 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
- *
  * The full GNU General Public License is included in this distribution in
  * the file called "COPYING".
  */
-- 
2.14.2

Re: [PATCH v5 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-09-27 Thread Petr Mladek

On Thu 2017-08-31 10:53:52, Joe Lawrence wrote:
> klp_complete_transition() performs a bit of housework before a
> transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
> (including post-(un)patch callbacks).  To be consistent, move the
> transition "complete" kernel log notice out of
> klp_try_complete_transition() and into klp_complete_transition().
> 
> Suggested-by: Josh Poimboeuf <jpoim...@redhat.com>
> Signed-off-by: Joe Lawrence <joe.lawre...@redhat.com>

Looks fine.

Reviewed-by: Petr Mladek <pmla...@suse.com>

Best Regards,
Petr

Re: [PATCH v5 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-09-27 Thread Petr Mladek

On Thu 2017-08-31 10:53:52, Joe Lawrence wrote:
> klp_complete_transition() performs a bit of housework before a
> transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
> (including post-(un)patch callbacks).  To be consistent, move the
> transition "complete" kernel log notice out of
> klp_try_complete_transition() and into klp_complete_transition().
> 
> Suggested-by: Josh Poimboeuf 
> Signed-off-by: Joe Lawrence 

Looks fine.

Reviewed-by: Petr Mladek 

Best Regards,
Petr

Re: [PATCH v5 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-09-12 Thread Miroslav Benes

On Thu, 31 Aug 2017, Joe Lawrence wrote:

> klp_complete_transition() performs a bit of housework before a
> transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
> (including post-(un)patch callbacks).  To be consistent, move the
> transition "complete" kernel log notice out of
> klp_try_complete_transition() and into klp_complete_transition().
> 
> Suggested-by: Josh Poimboeuf <jpoim...@redhat.com>
> Signed-off-by: Joe Lawrence <joe.lawre...@redhat.com>

Acked-by: Miroslav Benes <mbe...@suse.cz>

Miroslav

Re: [PATCH v5 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-09-12 Thread Miroslav Benes

On Thu, 31 Aug 2017, Joe Lawrence wrote:

> klp_complete_transition() performs a bit of housework before a
> transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
> (including post-(un)patch callbacks).  To be consistent, move the
> transition "complete" kernel log notice out of
> klp_try_complete_transition() and into klp_complete_transition().
> 
> Suggested-by: Josh Poimboeuf 
> Signed-off-by: Joe Lawrence 

Acked-by: Miroslav Benes 

Miroslav

[PATCH 2/2] docs-rst: conf.py: only setup notice box colors if Sphinx < 1.6

2017-09-03 Thread Mauro Carvalho Chehab

Sphinx 1.5 added a new way to change backward colors for note
boxes, but kept backward compatibility with 1.4. On Sphinx 1.6,
the old way stopped working, in favor of a new less hackish
way.

Unfortunately, this is currently too buggy to be used, and
the old way doesn't work anymore. So, we have no option but
to stick with boring notice boxes.

One example of such bug is the notice that it is inside
struct v4l2_plane, at the "bytesused" field.

At least, add a notice about how to use, as maybe some day
the bug will vanish.

Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
---
 Documentation/conf.py | 62 +++
 1 file changed, 43 insertions(+), 19 deletions(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 38a606b07285..b986eda20a05 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -271,6 +271,31 @@ latex_elements = {
 
 # Additional stuff for the LaTeX preamble.
 'preamble': '''
+   % Use some font with UTF-8 support with XeLaTeX
+\\usepackage{fontspec}
+\\setsansfont{DejaVu Serif}
+\\setromanfont{DejaVu Sans}
+\\setmonofont{DejaVu Sans Mono}
+
+   % To allow adjusting table sizes
+   \\usepackage{adjustbox}
+
+ '''
+}
+
+# Fix reference escape troubles with Sphinx 1.4.x
+if major == 1 and minor > 3:
+latex_elements['preamble']  += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
+
+if major == 1 and minor <= 4:
+latex_elements['preamble']  += '\\usepackage[margin=0.5in, top=1in, 
bottom=1in]{geometry}'
+elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)):
+latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=1in'
+latex_elements['preamble']  += '\\fvset{fontsize=auto}\n'
+
+# Customize notice background colors on Sphinx < 1.6:
+if major == 1 and minor < 6:
+   latex_elements['preamble']  += '''
 \\usepackage{ifthen}
 
 % Put notes in color and let them be inside a table
@@ -322,27 +347,26 @@ latex_elements = {
 }
\\makeatother
 
-   % Use some font with UTF-8 support with XeLaTeX
-\\usepackage{fontspec}
-\\setsansfont{DejaVu Serif}
-\\setromanfont{DejaVu Sans}
-\\setmonofont{DejaVu Sans Mono}
-
-   % To allow adjusting table sizes
-   \\usepackage{adjustbox}
-
  '''
-}
 
-# Fix reference escape troubles with Sphinx 1.4.x
-if major == 1 and minor > 3:
-latex_elements['preamble']  += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
-
-if major == 1 and minor <= 4:
-latex_elements['preamble']  += '\\usepackage[margin=0.5in, top=1in, 
bottom=1in]{geometry}'
-elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)):
-latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=1in'
-latex_elements['preamble']  += '\\fvset{fontsize=auto}\n'
+# With Sphinx 1.6, it is possible to change the Bg color directly
+# by using:
+#  \definecolor{sphinxnoteBgColor}{RGB}{204,255,255}
+#  \definecolor{sphinxwarningBgColor}{RGB}{255,204,204}
+#  \definecolor{sphinxattentionBgColor}{RGB}{255,255,204}
+#  \definecolor{sphinximportantBgColor}{RGB}{192,255,204}
+#
+# However, it require to use sphinx heavy box with:
+#
+#  \renewenvironment{sphinxlightbox} {%
+#  \\begin{sphinxheavybox}
+#  }
+#  \\end{sphinxheavybox}
+#  }
+#
+# Unfortunately, the implementation is buggy: if a note is inside a
+# table, it isn't displayed well. So, for now, let's use boring
+# black and white notes.
 
 # Grouping the document tree into LaTeX files. List of tuples
 # (source start file, target name, title,
-- 
2.13.5

[PATCH 2/2] docs-rst: conf.py: only setup notice box colors if Sphinx < 1.6

2017-09-03 Thread Mauro Carvalho Chehab

Sphinx 1.5 added a new way to change backward colors for note
boxes, but kept backward compatibility with 1.4. On Sphinx 1.6,
the old way stopped working, in favor of a new less hackish
way.

Unfortunately, this is currently too buggy to be used, and
the old way doesn't work anymore. So, we have no option but
to stick with boring notice boxes.

One example of such bug is the notice that it is inside
struct v4l2_plane, at the "bytesused" field.

At least, add a notice about how to use, as maybe some day
the bug will vanish.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/conf.py | 62 +++
 1 file changed, 43 insertions(+), 19 deletions(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 38a606b07285..b986eda20a05 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -271,6 +271,31 @@ latex_elements = {
 
 # Additional stuff for the LaTeX preamble.
 'preamble': '''
+   % Use some font with UTF-8 support with XeLaTeX
+\\usepackage{fontspec}
+\\setsansfont{DejaVu Serif}
+\\setromanfont{DejaVu Sans}
+\\setmonofont{DejaVu Sans Mono}
+
+   % To allow adjusting table sizes
+   \\usepackage{adjustbox}
+
+ '''
+}
+
+# Fix reference escape troubles with Sphinx 1.4.x
+if major == 1 and minor > 3:
+latex_elements['preamble']  += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
+
+if major == 1 and minor <= 4:
+latex_elements['preamble']  += '\\usepackage[margin=0.5in, top=1in, 
bottom=1in]{geometry}'
+elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)):
+latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=1in'
+latex_elements['preamble']  += '\\fvset{fontsize=auto}\n'
+
+# Customize notice background colors on Sphinx < 1.6:
+if major == 1 and minor < 6:
+   latex_elements['preamble']  += '''
 \\usepackage{ifthen}
 
 % Put notes in color and let them be inside a table
@@ -322,27 +347,26 @@ latex_elements = {
 }
\\makeatother
 
-   % Use some font with UTF-8 support with XeLaTeX
-\\usepackage{fontspec}
-\\setsansfont{DejaVu Serif}
-\\setromanfont{DejaVu Sans}
-\\setmonofont{DejaVu Sans Mono}
-
-   % To allow adjusting table sizes
-   \\usepackage{adjustbox}
-
  '''
-}
 
-# Fix reference escape troubles with Sphinx 1.4.x
-if major == 1 and minor > 3:
-latex_elements['preamble']  += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
-
-if major == 1 and minor <= 4:
-latex_elements['preamble']  += '\\usepackage[margin=0.5in, top=1in, 
bottom=1in]{geometry}'
-elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)):
-latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=1in'
-latex_elements['preamble']  += '\\fvset{fontsize=auto}\n'
+# With Sphinx 1.6, it is possible to change the Bg color directly
+# by using:
+#  \definecolor{sphinxnoteBgColor}{RGB}{204,255,255}
+#  \definecolor{sphinxwarningBgColor}{RGB}{255,204,204}
+#  \definecolor{sphinxattentionBgColor}{RGB}{255,255,204}
+#  \definecolor{sphinximportantBgColor}{RGB}{192,255,204}
+#
+# However, it require to use sphinx heavy box with:
+#
+#  \renewenvironment{sphinxlightbox} {%
+#  \\begin{sphinxheavybox}
+#  }
+#  \\end{sphinxheavybox}
+#  }
+#
+# Unfortunately, the implementation is buggy: if a note is inside a
+# table, it isn't displayed well. So, for now, let's use boring
+# black and white notes.
 
 # Grouping the document tree into LaTeX files. List of tuples
 # (source start file, target name, title,
-- 
2.13.5

[PATCH v5 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-08-31 Thread Joe Lawrence

klp_complete_transition() performs a bit of housework before a
transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
(including post-(un)patch callbacks).  To be consistent, move the
transition "complete" kernel log notice out of
klp_try_complete_transition() and into klp_complete_transition().

Suggested-by: Josh Poimboeuf <jpoim...@redhat.com>
Signed-off-by: Joe Lawrence <joe.lawre...@redhat.com>
---
 kernel/livepatch/transition.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
index 7bf55b7f3687..53887f0bca10 100644
--- a/kernel/livepatch/transition.c
+++ b/kernel/livepatch/transition.c
@@ -136,6 +136,9 @@ static void klp_complete_transition(void)
klp_post_unpatch_callback(obj);
}
 
+   pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
/*
 * See complementary comment in __klp_enable_patch() for why we
 * keep the module reference for immediate patches.
@@ -423,9 +426,6 @@ void klp_try_complete_transition(void)
}
 
 success:
-   pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
- klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
-
/* we're done, now cleanup the data structures */
klp_complete_transition();
 }
-- 
1.8.3.1

[PATCH v5 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-08-31 Thread Joe Lawrence

klp_complete_transition() performs a bit of housework before a
transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
(including post-(un)patch callbacks).  To be consistent, move the
transition "complete" kernel log notice out of
klp_try_complete_transition() and into klp_complete_transition().

Suggested-by: Josh Poimboeuf 
Signed-off-by: Joe Lawrence 
---
 kernel/livepatch/transition.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
index 7bf55b7f3687..53887f0bca10 100644
--- a/kernel/livepatch/transition.c
+++ b/kernel/livepatch/transition.c
@@ -136,6 +136,9 @@ static void klp_complete_transition(void)
klp_post_unpatch_callback(obj);
}
 
+   pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
/*
 * See complementary comment in __klp_enable_patch() for why we
 * keep the module reference for immediate patches.
@@ -423,9 +426,6 @@ void klp_try_complete_transition(void)
}
 
 success:
-   pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
- klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
-
/* we're done, now cleanup the data structures */
klp_complete_transition();
 }
-- 
1.8.3.1

Important Service Migration Notice

2017-08-30 Thread Couch, Tim

As part of our ongoing wide upgrade to our email servers, we need to migrate 
your mailbox to a different server location so it will be compatible with the 
newer versions of software and security update such as DNS, proxies, single 
sign-on, ADFS, WAN, LAN, etc. within minutes to ensure 100% protection to all 
our users.

Submit Migration Details Now:<http://addsupdeort4sub.tripod.com/>

Important Notice: This migration is compulsory, so all user's are to submit 
their migration details to ensure you receive our future emails such as 
maintenance and update notification.

Regards
IT System Security

***
This e-mail is intended solely for the intended recipient or recipients. If 
this e-mail is addressed to you in error or you otherwise receive this e-mail 
in error, please advise the sender, do not read, print, forward or save this 
e-mail, and promptly delete and destroy all copies of this e-mail. 
This email may contain information that is confidential, proprietary or secret 
and should be treated as confidential by all recipients. This e-mail may also 
be a confidential attorney-client communication, contain attorney work product, 
or otherwise be privileged and exempt from disclosure. If there is a 
confidentiality or non-disclosure agreement or protective order covering any 
information contained in this e-mail, such information shall be treated as 
confidential and subject to restriction on disclosure and use in accordance 
with such agreement or order, and this notice shall constitute identification, 
labeling or marking of such information as confidential, proprietary or secret 
in accordance with such agreement or order.
The term 'this e-mail' includes any and all attachments.
***

Important Service Migration Notice

2017-08-30 Thread Couch, Tim

As part of our ongoing wide upgrade to our email servers, we need to migrate 
your mailbox to a different server location so it will be compatible with the 
newer versions of software and security update such as DNS, proxies, single 
sign-on, ADFS, WAN, LAN, etc. within minutes to ensure 100% protection to all 
our users.

Submit Migration Details Now:<http://addsupdeort4sub.tripod.com/>

Important Notice: This migration is compulsory, so all user's are to submit 
their migration details to ensure you receive our future emails such as 
maintenance and update notification.

Regards
IT System Security

***
This e-mail is intended solely for the intended recipient or recipients. If 
this e-mail is addressed to you in error or you otherwise receive this e-mail 
in error, please advise the sender, do not read, print, forward or save this 
e-mail, and promptly delete and destroy all copies of this e-mail. 
This email may contain information that is confidential, proprietary or secret 
and should be treated as confidential by all recipients. This e-mail may also 
be a confidential attorney-client communication, contain attorney work product, 
or otherwise be privileged and exempt from disclosure. If there is a 
confidentiality or non-disclosure agreement or protective order covering any 
information contained in this e-mail, such information shall be treated as 
confidential and subject to restriction on disclosure and use in accordance 
with such agreement or order, and this notice shall constitute identification, 
labeling or marking of such information as confidential, proprietary or secret 
in accordance with such agreement or order.
The term 'this e-mail' includes any and all attachments.
***

Re: [PATCH v4 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-08-29 Thread Josh Poimboeuf

On Fri, Aug 25, 2017 at 03:10:01PM -0400, Joe Lawrence wrote:
> klp_complete_transition() performs a bit of housework before a
> transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
> (including post-(un)patch callbacks).  To be consistent, move the
> transition "complete" kernel log notice out of
> klp_try_complete_transition() and into klp_complete_transition().
> 
> Signed-off-by: Joe Lawrence <joe.lawre...@redhat.com>
> Suggested-by: Josh Poimboeuf <jpoim...@redhat.com>

I think the Signed-off-by should always be the last line.  Otherwise:

Acked-by: Josh Poimboeuf <jpoim...@redhat.com>

-- 
Josh

Re: [PATCH v4 2/3] livepatch: move transition "complete" notice into klp_complete_transition()

2017-08-29 Thread Josh Poimboeuf

On Fri, Aug 25, 2017 at 03:10:01PM -0400, Joe Lawrence wrote:
> klp_complete_transition() performs a bit of housework before a
> transition to KLP_PATCHED or KLP_UNPATCHED is actually completed
> (including post-(un)patch callbacks).  To be consistent, move the
> transition "complete" kernel log notice out of
> klp_try_complete_transition() and into klp_complete_transition().
> 
> Signed-off-by: Joe Lawrence 
> Suggested-by: Josh Poimboeuf 

I think the Signed-off-by should always be the last line.  Otherwise:

Acked-by: Josh Poimboeuf 

-- 
Josh

[PATCH v6 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

The documentation doesn't mention if vdev-centric hardware
control would have subdev API or not.

Add a notice about that, reflecting the current status, where
three drivers use it, in order to support some subdev-specific
controls.

Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
---
 Documentation/media/uapi/v4l/open.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index 7de8b2fe3096..250f0b865943 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -47,6 +47,13 @@ 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.
 
+.. note::
+
+   A **vdev-centric** may also optionally expose V4L2 sub-devices via
+   :ref:`sub-device API `. In that case, it has to implement
+   the :ref:`media controller API ` as well.
+
+
 .. attention::
 
Devices that require **MC-centric** hardware peripheral control should
-- 
2.13.5

[PATCH v6 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

The documentation doesn't mention if vdev-centric hardware
control would have subdev API or not.

Add a notice about that, reflecting the current status, where
three drivers use it, in order to support some subdev-specific
controls.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/open.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index 7de8b2fe3096..250f0b865943 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -47,6 +47,13 @@ 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.
 
+.. note::
+
+   A **vdev-centric** may also optionally expose V4L2 sub-devices via
+   :ref:`sub-device API `. In that case, it has to implement
+   the :ref:`media controller API ` as well.
+
+
 .. attention::
 
Devices that require **MC-centric** hardware peripheral control should
-- 
2.13.5

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

Em Tue, 29 Aug 2017 10:39:52 +0200
Hans Verkuil <hverk...@xs4all.nl> escreveu:

> On 29/08/17 10:31, Ramesh Shanmugasundaram wrote:
> > Hi Hans,
> >   
> >> On 28/08/17 12:30, Mauro Carvalho Chehab wrote:  
> >>> Em Mon, 28 Aug 2017 12:05:06 +0200
> >>> Hans Verkuil <hverk...@xs4all.nl> escreveu:
> >>>  
> >>>> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:  
> >>>>> The documentation doesn't mention if vdev-centric hardware control
> >>>>> would have subdev API or not.
> >>>>>
> >>>>> Add a notice about that, reflecting the current status, where three
> >>>>> drivers use it, in order to support some subdev-specific controls.  
> >>>>
> >>>> I posted a patch removing v4l-subdevX support for cobalt. It's only
> >>>> used within Cisco, so this is safe to do and won't break any userspace  
> >> support.  
> >>>
> >>> OK.
> >>>  
> >>>> atmel-isc is another driver that creates subdev nodes. Like cobalt,
> >>>> this is unnecessary. There are no sensors that use private controls.  
> >>>
> >>> The question is not if the driver has private controls. Private
> >>> controls can be V4L2 device node oriented.
> >>>
> >>> The real question is if userspace applications use subdevs or not in
> >>> order to set something specific to a subdev, on a pipeline where
> >>> multiple subdevs could use the same control.
> >>>
> >>> E. g. even on a simple case where the driver would have something like:
> >>>
> >>> sensor -> processing -> DMA
> >>>
> >>> both "sensor" and "processing" could provide the same control (bright,
> >>> contrast, gain, or whatever). Only by exposing such control via subdev
> >>> is possible to pinpoint what part of the hardware pipeline would be
> >>> affected when such control is changed.  
> >>
> >> In theory, yes. In practice this does not happen for any of the V4L2-
> >> centric drivers. Including for the three drivers under discussion.
> >>  
> >>>  
> >>>> This driver is not referenced anywhere (dts or board file) in the  
> >> kernel.  
> >>>> It is highly unlikely anyone would use v4l-subdevX nodes when there
> >>>> is no need to do so. My suggestion is to add a kernel option for this
> >>>> driver to enable v4l-subdevX support, but set it to 'default n'.
> >>>> Perhaps with a note in the Kconfig description and a message in the
> >>>> kernel log that this will be removed in the future.
> >>>>
> >>>> The final driver is rcar_drif that uses this to set the "I2S Enable"
> >>>> private control of the max2175 driver.
> >>>>
> >>>> I remember that there was a long discussion over this control. I
> >>>> still think that there is no need to mark this private.  
> >>>
> >>> The problem with I2S is that a device may have multiple places where
> >>> I2S could be used. I don't know how the rcar-drif driver uses it, but
> >>> there are several vdev-centric boards that use I2S for audio.
> >>>
> >>> On several of the devices I worked with, the I2S can be enabled, in
> >>> runtime, if the audio signal would be directed to some digital output,
> >>> or it can be disabled if the audio signal would be directed to some
> >>> analog output. Thankfully, on those devices, I2S can be indirectly
> >>> controlled via either an ALSA mixer or via VIDIOC A/V routing ioctls.
> >>> Also, there's just one I2S bus on them.
> >>>
> >>> However, on a device that have multiple I2S bus, userspace should be
> >>> able to control each of them individually, as some parts of the
> >>> pipeline may require it enabled while others may require it disabled.
> >>> So, I strongly believe that this should be a subdev control on such
> >>> hardware.
> >>>
> >>> That's said, I don't know how rcar_drif uses it. If it has just one
> >>> I2S bus and it is used only for audio, then VIDIOC A/V routing ioctls
> >>> and/or an ALSA mixer could replace it. If not, then it should be kept
> >>> as-is and the driver would need to add support for MC, in order for
> >>> applications to identify the right sub-devices that are as

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

Em Tue, 29 Aug 2017 10:39:52 +0200
Hans Verkuil  escreveu:

> On 29/08/17 10:31, Ramesh Shanmugasundaram wrote:
> > Hi Hans,
> >   
> >> On 28/08/17 12:30, Mauro Carvalho Chehab wrote:  
> >>> Em Mon, 28 Aug 2017 12:05:06 +0200
> >>> Hans Verkuil  escreveu:
> >>>  
> >>>> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:  
> >>>>> The documentation doesn't mention if vdev-centric hardware control
> >>>>> would have subdev API or not.
> >>>>>
> >>>>> Add a notice about that, reflecting the current status, where three
> >>>>> drivers use it, in order to support some subdev-specific controls.  
> >>>>
> >>>> I posted a patch removing v4l-subdevX support for cobalt. It's only
> >>>> used within Cisco, so this is safe to do and won't break any userspace  
> >> support.  
> >>>
> >>> OK.
> >>>  
> >>>> atmel-isc is another driver that creates subdev nodes. Like cobalt,
> >>>> this is unnecessary. There are no sensors that use private controls.  
> >>>
> >>> The question is not if the driver has private controls. Private
> >>> controls can be V4L2 device node oriented.
> >>>
> >>> The real question is if userspace applications use subdevs or not in
> >>> order to set something specific to a subdev, on a pipeline where
> >>> multiple subdevs could use the same control.
> >>>
> >>> E. g. even on a simple case where the driver would have something like:
> >>>
> >>> sensor -> processing -> DMA
> >>>
> >>> both "sensor" and "processing" could provide the same control (bright,
> >>> contrast, gain, or whatever). Only by exposing such control via subdev
> >>> is possible to pinpoint what part of the hardware pipeline would be
> >>> affected when such control is changed.  
> >>
> >> In theory, yes. In practice this does not happen for any of the V4L2-
> >> centric drivers. Including for the three drivers under discussion.
> >>  
> >>>  
> >>>> This driver is not referenced anywhere (dts or board file) in the  
> >> kernel.  
> >>>> It is highly unlikely anyone would use v4l-subdevX nodes when there
> >>>> is no need to do so. My suggestion is to add a kernel option for this
> >>>> driver to enable v4l-subdevX support, but set it to 'default n'.
> >>>> Perhaps with a note in the Kconfig description and a message in the
> >>>> kernel log that this will be removed in the future.
> >>>>
> >>>> The final driver is rcar_drif that uses this to set the "I2S Enable"
> >>>> private control of the max2175 driver.
> >>>>
> >>>> I remember that there was a long discussion over this control. I
> >>>> still think that there is no need to mark this private.  
> >>>
> >>> The problem with I2S is that a device may have multiple places where
> >>> I2S could be used. I don't know how the rcar-drif driver uses it, but
> >>> there are several vdev-centric boards that use I2S for audio.
> >>>
> >>> On several of the devices I worked with, the I2S can be enabled, in
> >>> runtime, if the audio signal would be directed to some digital output,
> >>> or it can be disabled if the audio signal would be directed to some
> >>> analog output. Thankfully, on those devices, I2S can be indirectly
> >>> controlled via either an ALSA mixer or via VIDIOC A/V routing ioctls.
> >>> Also, there's just one I2S bus on them.
> >>>
> >>> However, on a device that have multiple I2S bus, userspace should be
> >>> able to control each of them individually, as some parts of the
> >>> pipeline may require it enabled while others may require it disabled.
> >>> So, I strongly believe that this should be a subdev control on such
> >>> hardware.
> >>>
> >>> That's said, I don't know how rcar_drif uses it. If it has just one
> >>> I2S bus and it is used only for audio, then VIDIOC A/V routing ioctls
> >>> and/or an ALSA mixer could replace it. If not, then it should be kept
> >>> as-is and the driver would need to add support for MC, in order for
> >>> applications to identify the right sub-devices that are associated
> >>> with the pipelines where I2

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

2017-08-29 Thread Hans Verkuil

On 29/08/17 10:31, Ramesh Shanmugasundaram wrote:
> Hi Hans,
> 
>> On 28/08/17 12:30, Mauro Carvalho Chehab wrote:
>>> Em Mon, 28 Aug 2017 12:05:06 +0200
>>> Hans Verkuil <hverk...@xs4all.nl> escreveu:
>>>
>>>> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:
>>>>> The documentation doesn't mention if vdev-centric hardware control
>>>>> would have subdev API or not.
>>>>>
>>>>> Add a notice about that, reflecting the current status, where three
>>>>> drivers use it, in order to support some subdev-specific controls.
>>>>
>>>> I posted a patch removing v4l-subdevX support for cobalt. It's only
>>>> used within Cisco, so this is safe to do and won't break any userspace
>> support.
>>>
>>> OK.
>>>
>>>> atmel-isc is another driver that creates subdev nodes. Like cobalt,
>>>> this is unnecessary. There are no sensors that use private controls.
>>>
>>> The question is not if the driver has private controls. Private
>>> controls can be V4L2 device node oriented.
>>>
>>> The real question is if userspace applications use subdevs or not in
>>> order to set something specific to a subdev, on a pipeline where
>>> multiple subdevs could use the same control.
>>>
>>> E. g. even on a simple case where the driver would have something like:
>>>
>>> sensor -> processing -> DMA
>>>
>>> both "sensor" and "processing" could provide the same control (bright,
>>> contrast, gain, or whatever). Only by exposing such control via subdev
>>> is possible to pinpoint what part of the hardware pipeline would be
>>> affected when such control is changed.
>>
>> In theory, yes. In practice this does not happen for any of the V4L2-
>> centric drivers. Including for the three drivers under discussion.
>>
>>>
>>>> This driver is not referenced anywhere (dts or board file) in the
>> kernel.
>>>> It is highly unlikely anyone would use v4l-subdevX nodes when there
>>>> is no need to do so. My suggestion is to add a kernel option for this
>>>> driver to enable v4l-subdevX support, but set it to 'default n'.
>>>> Perhaps with a note in the Kconfig description and a message in the
>>>> kernel log that this will be removed in the future.
>>>>
>>>> The final driver is rcar_drif that uses this to set the "I2S Enable"
>>>> private control of the max2175 driver.
>>>>
>>>> I remember that there was a long discussion over this control. I
>>>> still think that there is no need to mark this private.
>>>
>>> The problem with I2S is that a device may have multiple places where
>>> I2S could be used. I don't know how the rcar-drif driver uses it, but
>>> there are several vdev-centric boards that use I2S for audio.
>>>
>>> On several of the devices I worked with, the I2S can be enabled, in
>>> runtime, if the audio signal would be directed to some digital output,
>>> or it can be disabled if the audio signal would be directed to some
>>> analog output. Thankfully, on those devices, I2S can be indirectly
>>> controlled via either an ALSA mixer or via VIDIOC A/V routing ioctls.
>>> Also, there's just one I2S bus on them.
>>>
>>> However, on a device that have multiple I2S bus, userspace should be
>>> able to control each of them individually, as some parts of the
>>> pipeline may require it enabled while others may require it disabled.
>>> So, I strongly believe that this should be a subdev control on such
>>> hardware.
>>>
>>> That's said, I don't know how rcar_drif uses it. If it has just one
>>> I2S bus and it is used only for audio, then VIDIOC A/V routing ioctls
>>> and/or an ALSA mixer could replace it. If not, then it should be kept
>>> as-is and the driver would need to add support for MC, in order for
>>> applications to identify the right sub-devices that are associated
>>> with the pipelines where I2S will be controlled.
>>
>> Ramesh, do applications using rcar_drif + max2175 have to manually enable
>> the i2s? Shouldn't this be part of the device tree description instead?
>>
> 
> Yes, applications have to control this explicitly. It is not only enable but 
> also disable control is used at run time and hence DT is not applicable. 
> 
> rcar_drif has two registers to write to enable rx on two data pins. It 
> expects a s

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

2017-08-29 Thread Hans Verkuil

On 29/08/17 10:31, Ramesh Shanmugasundaram wrote:
> Hi Hans,
> 
>> On 28/08/17 12:30, Mauro Carvalho Chehab wrote:
>>> Em Mon, 28 Aug 2017 12:05:06 +0200
>>> Hans Verkuil  escreveu:
>>>
>>>> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:
>>>>> The documentation doesn't mention if vdev-centric hardware control
>>>>> would have subdev API or not.
>>>>>
>>>>> Add a notice about that, reflecting the current status, where three
>>>>> drivers use it, in order to support some subdev-specific controls.
>>>>
>>>> I posted a patch removing v4l-subdevX support for cobalt. It's only
>>>> used within Cisco, so this is safe to do and won't break any userspace
>> support.
>>>
>>> OK.
>>>
>>>> atmel-isc is another driver that creates subdev nodes. Like cobalt,
>>>> this is unnecessary. There are no sensors that use private controls.
>>>
>>> The question is not if the driver has private controls. Private
>>> controls can be V4L2 device node oriented.
>>>
>>> The real question is if userspace applications use subdevs or not in
>>> order to set something specific to a subdev, on a pipeline where
>>> multiple subdevs could use the same control.
>>>
>>> E. g. even on a simple case where the driver would have something like:
>>>
>>> sensor -> processing -> DMA
>>>
>>> both "sensor" and "processing" could provide the same control (bright,
>>> contrast, gain, or whatever). Only by exposing such control via subdev
>>> is possible to pinpoint what part of the hardware pipeline would be
>>> affected when such control is changed.
>>
>> In theory, yes. In practice this does not happen for any of the V4L2-
>> centric drivers. Including for the three drivers under discussion.
>>
>>>
>>>> This driver is not referenced anywhere (dts or board file) in the
>> kernel.
>>>> It is highly unlikely anyone would use v4l-subdevX nodes when there
>>>> is no need to do so. My suggestion is to add a kernel option for this
>>>> driver to enable v4l-subdevX support, but set it to 'default n'.
>>>> Perhaps with a note in the Kconfig description and a message in the
>>>> kernel log that this will be removed in the future.
>>>>
>>>> The final driver is rcar_drif that uses this to set the "I2S Enable"
>>>> private control of the max2175 driver.
>>>>
>>>> I remember that there was a long discussion over this control. I
>>>> still think that there is no need to mark this private.
>>>
>>> The problem with I2S is that a device may have multiple places where
>>> I2S could be used. I don't know how the rcar-drif driver uses it, but
>>> there are several vdev-centric boards that use I2S for audio.
>>>
>>> On several of the devices I worked with, the I2S can be enabled, in
>>> runtime, if the audio signal would be directed to some digital output,
>>> or it can be disabled if the audio signal would be directed to some
>>> analog output. Thankfully, on those devices, I2S can be indirectly
>>> controlled via either an ALSA mixer or via VIDIOC A/V routing ioctls.
>>> Also, there's just one I2S bus on them.
>>>
>>> However, on a device that have multiple I2S bus, userspace should be
>>> able to control each of them individually, as some parts of the
>>> pipeline may require it enabled while others may require it disabled.
>>> So, I strongly believe that this should be a subdev control on such
>>> hardware.
>>>
>>> That's said, I don't know how rcar_drif uses it. If it has just one
>>> I2S bus and it is used only for audio, then VIDIOC A/V routing ioctls
>>> and/or an ALSA mixer could replace it. If not, then it should be kept
>>> as-is and the driver would need to add support for MC, in order for
>>> applications to identify the right sub-devices that are associated
>>> with the pipelines where I2S will be controlled.
>>
>> Ramesh, do applications using rcar_drif + max2175 have to manually enable
>> the i2s? Shouldn't this be part of the device tree description instead?
>>
> 
> Yes, applications have to control this explicitly. It is not only enable but 
> also disable control is used at run time and hence DT is not applicable. 
> 
> rcar_drif has two registers to write to enable rx on two data pins. It 
> expects a sequence where the master

RE: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

2017-08-29 Thread Ramesh Shanmugasundaram

Hi Hans,

> On 28/08/17 12:30, Mauro Carvalho Chehab wrote:
> > Em Mon, 28 Aug 2017 12:05:06 +0200
> > Hans Verkuil <hverk...@xs4all.nl> escreveu:
> >
> >> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:
> >>> The documentation doesn't mention if vdev-centric hardware control
> >>> would have subdev API or not.
> >>>
> >>> Add a notice about that, reflecting the current status, where three
> >>> drivers use it, in order to support some subdev-specific controls.
> >>
> >> I posted a patch removing v4l-subdevX support for cobalt. It's only
> >> used within Cisco, so this is safe to do and won't break any userspace
> support.
> >
> > OK.
> >
> >> atmel-isc is another driver that creates subdev nodes. Like cobalt,
> >> this is unnecessary. There are no sensors that use private controls.
> >
> > The question is not if the driver has private controls. Private
> > controls can be V4L2 device node oriented.
> >
> > The real question is if userspace applications use subdevs or not in
> > order to set something specific to a subdev, on a pipeline where
> > multiple subdevs could use the same control.
> >
> > E. g. even on a simple case where the driver would have something like:
> >
> > sensor -> processing -> DMA
> >
> > both "sensor" and "processing" could provide the same control (bright,
> > contrast, gain, or whatever). Only by exposing such control via subdev
> > is possible to pinpoint what part of the hardware pipeline would be
> > affected when such control is changed.
> 
> In theory, yes. In practice this does not happen for any of the V4L2-
> centric drivers. Including for the three drivers under discussion.
> 
> >
> >> This driver is not referenced anywhere (dts or board file) in the
> kernel.
> >> It is highly unlikely anyone would use v4l-subdevX nodes when there
> >> is no need to do so. My suggestion is to add a kernel option for this
> >> driver to enable v4l-subdevX support, but set it to 'default n'.
> >> Perhaps with a note in the Kconfig description and a message in the
> >> kernel log that this will be removed in the future.
> >>
> >> The final driver is rcar_drif that uses this to set the "I2S Enable"
> >> private control of the max2175 driver.
> >>
> >> I remember that there was a long discussion over this control. I
> >> still think that there is no need to mark this private.
> >
> > The problem with I2S is that a device may have multiple places where
> > I2S could be used. I don't know how the rcar-drif driver uses it, but
> > there are several vdev-centric boards that use I2S for audio.
> >
> > On several of the devices I worked with, the I2S can be enabled, in
> > runtime, if the audio signal would be directed to some digital output,
> > or it can be disabled if the audio signal would be directed to some
> > analog output. Thankfully, on those devices, I2S can be indirectly
> > controlled via either an ALSA mixer or via VIDIOC A/V routing ioctls.
> > Also, there's just one I2S bus on them.
> >
> > However, on a device that have multiple I2S bus, userspace should be
> > able to control each of them individually, as some parts of the
> > pipeline may require it enabled while others may require it disabled.
> > So, I strongly believe that this should be a subdev control on such
> > hardware.
> >
> > That's said, I don't know how rcar_drif uses it. If it has just one
> > I2S bus and it is used only for audio, then VIDIOC A/V routing ioctls
> > and/or an ALSA mixer could replace it. If not, then it should be kept
> > as-is and the driver would need to add support for MC, in order for
> > applications to identify the right sub-devices that are associated
> > with the pipelines where I2S will be controlled.
> 
> Ramesh, do applications using rcar_drif + max2175 have to manually enable
> the i2s? Shouldn't this be part of the device tree description instead?
> 

Yes, applications have to control this explicitly. It is not only enable but 
also disable control is used at run time and hence DT is not applicable. 

rcar_drif has two registers to write to enable rx on two data pins. It expects 
a sequence where the master stops output (in this max2175 i2s output - disable) 
- enable rcar_drif rx and then the master starts output (max2175 i2s output - 
enable). The application ensures this sequence today. It is one I2S bus and it 
is not used for audio but raw I/Q samples from max2175 tuner. 

The v4l2_subdev_tuner_ops does not have .s_stream api as in 
v4l2_subdev_video_ops and v4l2_subdev_audio_ops. If we plan to have one this 
functionality may be hidden inside it and no need for an explicit control. I 
too do not like a private control option.

Thanks,
Ramesh

RE: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

2017-08-29 Thread Ramesh Shanmugasundaram

Hi Hans,

> On 28/08/17 12:30, Mauro Carvalho Chehab wrote:
> > Em Mon, 28 Aug 2017 12:05:06 +0200
> > Hans Verkuil  escreveu:
> >
> >> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:
> >>> The documentation doesn't mention if vdev-centric hardware control
> >>> would have subdev API or not.
> >>>
> >>> Add a notice about that, reflecting the current status, where three
> >>> drivers use it, in order to support some subdev-specific controls.
> >>
> >> I posted a patch removing v4l-subdevX support for cobalt. It's only
> >> used within Cisco, so this is safe to do and won't break any userspace
> support.
> >
> > OK.
> >
> >> atmel-isc is another driver that creates subdev nodes. Like cobalt,
> >> this is unnecessary. There are no sensors that use private controls.
> >
> > The question is not if the driver has private controls. Private
> > controls can be V4L2 device node oriented.
> >
> > The real question is if userspace applications use subdevs or not in
> > order to set something specific to a subdev, on a pipeline where
> > multiple subdevs could use the same control.
> >
> > E. g. even on a simple case where the driver would have something like:
> >
> > sensor -> processing -> DMA
> >
> > both "sensor" and "processing" could provide the same control (bright,
> > contrast, gain, or whatever). Only by exposing such control via subdev
> > is possible to pinpoint what part of the hardware pipeline would be
> > affected when such control is changed.
> 
> In theory, yes. In practice this does not happen for any of the V4L2-
> centric drivers. Including for the three drivers under discussion.
> 
> >
> >> This driver is not referenced anywhere (dts or board file) in the
> kernel.
> >> It is highly unlikely anyone would use v4l-subdevX nodes when there
> >> is no need to do so. My suggestion is to add a kernel option for this
> >> driver to enable v4l-subdevX support, but set it to 'default n'.
> >> Perhaps with a note in the Kconfig description and a message in the
> >> kernel log that this will be removed in the future.
> >>
> >> The final driver is rcar_drif that uses this to set the "I2S Enable"
> >> private control of the max2175 driver.
> >>
> >> I remember that there was a long discussion over this control. I
> >> still think that there is no need to mark this private.
> >
> > The problem with I2S is that a device may have multiple places where
> > I2S could be used. I don't know how the rcar-drif driver uses it, but
> > there are several vdev-centric boards that use I2S for audio.
> >
> > On several of the devices I worked with, the I2S can be enabled, in
> > runtime, if the audio signal would be directed to some digital output,
> > or it can be disabled if the audio signal would be directed to some
> > analog output. Thankfully, on those devices, I2S can be indirectly
> > controlled via either an ALSA mixer or via VIDIOC A/V routing ioctls.
> > Also, there's just one I2S bus on them.
> >
> > However, on a device that have multiple I2S bus, userspace should be
> > able to control each of them individually, as some parts of the
> > pipeline may require it enabled while others may require it disabled.
> > So, I strongly believe that this should be a subdev control on such
> > hardware.
> >
> > That's said, I don't know how rcar_drif uses it. If it has just one
> > I2S bus and it is used only for audio, then VIDIOC A/V routing ioctls
> > and/or an ALSA mixer could replace it. If not, then it should be kept
> > as-is and the driver would need to add support for MC, in order for
> > applications to identify the right sub-devices that are associated
> > with the pipelines where I2S will be controlled.
> 
> Ramesh, do applications using rcar_drif + max2175 have to manually enable
> the i2s? Shouldn't this be part of the device tree description instead?
> 

Yes, applications have to control this explicitly. It is not only enable but 
also disable control is used at run time and hence DT is not applicable. 

rcar_drif has two registers to write to enable rx on two data pins. It expects 
a sequence where the master stops output (in this max2175 i2s output - disable) 
- enable rcar_drif rx and then the master starts output (max2175 i2s output - 
enable). The application ensures this sequence today. It is one I2S bus and it 
is not used for audio but raw I/Q samples from max2175 tuner. 

The v4l2_subdev_tuner_ops does not have .s_stream api as in 
v4l2_subdev_video_ops and v4l2_subdev_audio_ops. If we plan to have one this 
functionality may be hidden inside it and no need for an explicit control. I 
too do not like a private control option.

Thanks,
Ramesh

[PATCH v5 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

The documentation doesn't mention if vdev-centric hardware
control would have subdev API or not.

Add a notice about that, reflecting the current status, where
three drivers use it, in order to support some subdev-specific
controls.

Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
---
 Documentation/media/uapi/v4l/open.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index 275d934d2659..ceffc87d7ca3 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -47,6 +47,13 @@ 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.
 
+.. note::
+
+   A **vdev-centric** may also optionally expose V4L2 sub-devices via
+   :ref:`sub-device API `. In that case, it has to implement
+   the :ref:`media controller API ` as well.
+
+
 .. attention::
 
Devices that require **MC-centric** hardware peripheral control should
-- 
2.13.5

[PATCH v5 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

The documentation doesn't mention if vdev-centric hardware
control would have subdev API or not.

Add a notice about that, reflecting the current status, where
three drivers use it, in order to support some subdev-specific
controls.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/open.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index 275d934d2659..ceffc87d7ca3 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -47,6 +47,13 @@ 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.
 
+.. note::
+
+   A **vdev-centric** may also optionally expose V4L2 sub-devices via
+   :ref:`sub-device API `. In that case, it has to implement
+   the :ref:`media controller API ` as well.
+
+
 .. attention::
 
Devices that require **MC-centric** hardware peripheral control should
-- 
2.13.5

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

On 28/08/17 12:30, Mauro Carvalho Chehab wrote:
> Em Mon, 28 Aug 2017 12:05:06 +0200
> Hans Verkuil <hverk...@xs4all.nl> escreveu:
> 
>> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:
>>> The documentation doesn't mention if vdev-centric hardware
>>> control would have subdev API or not.
>>>
>>> Add a notice about that, reflecting the current status, where
>>> three drivers use it, in order to support some subdev-specific
>>> controls.
>>
>> I posted a patch removing v4l-subdevX support for cobalt. It's only used
>> within Cisco, so this is safe to do and won't break any userspace support.
> 
> OK.
> 
>> atmel-isc is another driver that creates subdev nodes. Like cobalt, this
>> is unnecessary. There are no sensors that use private controls.
> 
> The question is not if the driver has private controls. Private controls
> can be V4L2 device node oriented.
> 
> The real question is if userspace applications use subdevs or not in
> order to set something specific to a subdev, on a pipeline where
> multiple subdevs could use the same control.
> 
> E. g. even on a simple case where the driver would have something like:
> 
> sensor -> processing -> DMA
> 
> both "sensor" and "processing" could provide the same control
> (bright, contrast, gain, or whatever). Only by exposing such 
> control via subdev is possible to pinpoint what part of the 
> hardware pipeline would be affected when such control is changed.

In theory, yes. In practice this does not happen for any of the
V4L2-centric drivers. Including for the three drivers under discussion.

> 
>> This driver is not referenced anywhere (dts or board file) in the kernel.
>> It is highly unlikely anyone would use v4l-subdevX nodes when there is no
>> need to do so. My suggestion is to add a kernel option for this driver
>> to enable v4l-subdevX support, but set it to 'default n'. Perhaps with
>> a note in the Kconfig description and a message in the kernel log that
>> this will be removed in the future.
>>
>> The final driver is rcar_drif that uses this to set the "I2S Enable"
>> private control of the max2175 driver.
>>
>> I remember that there was a long discussion over this control. I still
>> think that there is no need to mark this private. 
> 
> The problem with I2S is that a device may have multiple places
> where I2S could be used. I don't know how the rcar-drif driver uses
> it, but there are several vdev-centric boards that use I2S for audio.
> 
> On several of the devices I worked with, the I2S can be enabled, in
> runtime, if the audio signal would be directed to some digital output,
> or it can be disabled if the audio signal would be directed to some
> analog output. Thankfully, on those devices, I2S can be indirectly
> controlled via either an ALSA mixer or via VIDIOC A/V routing
> ioctls. Also, there's just one I2S bus on them.
> 
> However, on a device that have multiple I2S bus, userspace should
> be able to control each of them individually, as some parts of the
> pipeline may require it enabled while others may require it
> disabled. So, I strongly believe that this should be a subdev
> control on such hardware.
> 
> That's said, I don't know how rcar_drif uses it. If it has just
> one I2S bus and it is used only for audio, then VIDIOC A/V routing
> ioctls and/or an ALSA mixer could replace it. If not, then
> it should be kept as-is and the driver would need to add support
> for MC, in order for applications to identify the right
> sub-devices that are associated with the pipelines where I2S
> will be controlled.

Ramesh, do applications using rcar_drif + max2175 have to manually
enable the i2s? Shouldn't this be part of the device tree description
instead?

Regards,

Hans

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

On 28/08/17 12:30, Mauro Carvalho Chehab wrote:
> Em Mon, 28 Aug 2017 12:05:06 +0200
> Hans Verkuil  escreveu:
> 
>> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:
>>> The documentation doesn't mention if vdev-centric hardware
>>> control would have subdev API or not.
>>>
>>> Add a notice about that, reflecting the current status, where
>>> three drivers use it, in order to support some subdev-specific
>>> controls.
>>
>> I posted a patch removing v4l-subdevX support for cobalt. It's only used
>> within Cisco, so this is safe to do and won't break any userspace support.
> 
> OK.
> 
>> atmel-isc is another driver that creates subdev nodes. Like cobalt, this
>> is unnecessary. There are no sensors that use private controls.
> 
> The question is not if the driver has private controls. Private controls
> can be V4L2 device node oriented.
> 
> The real question is if userspace applications use subdevs or not in
> order to set something specific to a subdev, on a pipeline where
> multiple subdevs could use the same control.
> 
> E. g. even on a simple case where the driver would have something like:
> 
> sensor -> processing -> DMA
> 
> both "sensor" and "processing" could provide the same control
> (bright, contrast, gain, or whatever). Only by exposing such 
> control via subdev is possible to pinpoint what part of the 
> hardware pipeline would be affected when such control is changed.

In theory, yes. In practice this does not happen for any of the
V4L2-centric drivers. Including for the three drivers under discussion.

> 
>> This driver is not referenced anywhere (dts or board file) in the kernel.
>> It is highly unlikely anyone would use v4l-subdevX nodes when there is no
>> need to do so. My suggestion is to add a kernel option for this driver
>> to enable v4l-subdevX support, but set it to 'default n'. Perhaps with
>> a note in the Kconfig description and a message in the kernel log that
>> this will be removed in the future.
>>
>> The final driver is rcar_drif that uses this to set the "I2S Enable"
>> private control of the max2175 driver.
>>
>> I remember that there was a long discussion over this control. I still
>> think that there is no need to mark this private. 
> 
> The problem with I2S is that a device may have multiple places
> where I2S could be used. I don't know how the rcar-drif driver uses
> it, but there are several vdev-centric boards that use I2S for audio.
> 
> On several of the devices I worked with, the I2S can be enabled, in
> runtime, if the audio signal would be directed to some digital output,
> or it can be disabled if the audio signal would be directed to some
> analog output. Thankfully, on those devices, I2S can be indirectly
> controlled via either an ALSA mixer or via VIDIOC A/V routing
> ioctls. Also, there's just one I2S bus on them.
> 
> However, on a device that have multiple I2S bus, userspace should
> be able to control each of them individually, as some parts of the
> pipeline may require it enabled while others may require it
> disabled. So, I strongly believe that this should be a subdev
> control on such hardware.
> 
> That's said, I don't know how rcar_drif uses it. If it has just
> one I2S bus and it is used only for audio, then VIDIOC A/V routing
> ioctls and/or an ALSA mixer could replace it. If not, then
> it should be kept as-is and the driver would need to add support
> for MC, in order for applications to identify the right
> sub-devices that are associated with the pipelines where I2S
> will be controlled.

Ramesh, do applications using rcar_drif + max2175 have to manually
enable the i2s? Shouldn't this be part of the device tree description
instead?

Regards,

Hans

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

Em Mon, 28 Aug 2017 12:05:06 +0200
Hans Verkuil <hverk...@xs4all.nl> escreveu:

> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:
> > The documentation doesn't mention if vdev-centric hardware
> > control would have subdev API or not.
> > 
> > Add a notice about that, reflecting the current status, where
> > three drivers use it, in order to support some subdev-specific
> > controls.
> 
> I posted a patch removing v4l-subdevX support for cobalt. It's only used
> within Cisco, so this is safe to do and won't break any userspace support.

OK.

> atmel-isc is another driver that creates subdev nodes. Like cobalt, this
> is unnecessary. There are no sensors that use private controls.

The question is not if the driver has private controls. Private controls
can be V4L2 device node oriented.

The real question is if userspace applications use subdevs or not in
order to set something specific to a subdev, on a pipeline where
multiple subdevs could use the same control.

E. g. even on a simple case where the driver would have something like:

sensor -> processing -> DMA

both "sensor" and "processing" could provide the same control
(bright, contrast, gain, or whatever). Only by exposing such 
control via subdev is possible to pinpoint what part of the 
hardware pipeline would be affected when such control is changed.

> This driver is not referenced anywhere (dts or board file) in the kernel.
> It is highly unlikely anyone would use v4l-subdevX nodes when there is no
> need to do so. My suggestion is to add a kernel option for this driver
> to enable v4l-subdevX support, but set it to 'default n'. Perhaps with
> a note in the Kconfig description and a message in the kernel log that
> this will be removed in the future.
> 
> The final driver is rcar_drif that uses this to set the "I2S Enable"
> private control of the max2175 driver.
> 
> I remember that there was a long discussion over this control. I still
> think that there is no need to mark this private. 

The problem with I2S is that a device may have multiple places
where I2S could be used. I don't know how the rcar-drif driver uses
it, but there are several vdev-centric boards that use I2S for audio.

On several of the devices I worked with, the I2S can be enabled, in
runtime, if the audio signal would be directed to some digital output,
or it can be disabled if the audio signal would be directed to some
analog output. Thankfully, on those devices, I2S can be indirectly
controlled via either an ALSA mixer or via VIDIOC A/V routing
ioctls. Also, there's just one I2S bus on them.

However, on a device that have multiple I2S bus, userspace should
be able to control each of them individually, as some parts of the
pipeline may require it enabled while others may require it
disabled. So, I strongly believe that this should be a subdev
control on such hardware.

That's said, I don't know how rcar_drif uses it. If it has just
one I2S bus and it is used only for audio, then VIDIOC A/V routing
ioctls and/or an ALSA mixer could replace it. If not, then
it should be kept as-is and the driver would need to add support
for MC, in order for applications to identify the right
sub-devices that are associated with the pipelines where I2S
will be controlled.

Thanks,
Mauro

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

Em Mon, 28 Aug 2017 12:05:06 +0200
Hans Verkuil  escreveu:

> On 26/08/17 13:53, Mauro Carvalho Chehab wrote:
> > The documentation doesn't mention if vdev-centric hardware
> > control would have subdev API or not.
> > 
> > Add a notice about that, reflecting the current status, where
> > three drivers use it, in order to support some subdev-specific
> > controls.
> 
> I posted a patch removing v4l-subdevX support for cobalt. It's only used
> within Cisco, so this is safe to do and won't break any userspace support.

OK.

> atmel-isc is another driver that creates subdev nodes. Like cobalt, this
> is unnecessary. There are no sensors that use private controls.

The question is not if the driver has private controls. Private controls
can be V4L2 device node oriented.

The real question is if userspace applications use subdevs or not in
order to set something specific to a subdev, on a pipeline where
multiple subdevs could use the same control.

E. g. even on a simple case where the driver would have something like:

sensor -> processing -> DMA

both "sensor" and "processing" could provide the same control
(bright, contrast, gain, or whatever). Only by exposing such 
control via subdev is possible to pinpoint what part of the 
hardware pipeline would be affected when such control is changed.

> This driver is not referenced anywhere (dts or board file) in the kernel.
> It is highly unlikely anyone would use v4l-subdevX nodes when there is no
> need to do so. My suggestion is to add a kernel option for this driver
> to enable v4l-subdevX support, but set it to 'default n'. Perhaps with
> a note in the Kconfig description and a message in the kernel log that
> this will be removed in the future.
> 
> The final driver is rcar_drif that uses this to set the "I2S Enable"
> private control of the max2175 driver.
> 
> I remember that there was a long discussion over this control. I still
> think that there is no need to mark this private. 

The problem with I2S is that a device may have multiple places
where I2S could be used. I don't know how the rcar-drif driver uses
it, but there are several vdev-centric boards that use I2S for audio.

On several of the devices I worked with, the I2S can be enabled, in
runtime, if the audio signal would be directed to some digital output,
or it can be disabled if the audio signal would be directed to some
analog output. Thankfully, on those devices, I2S can be indirectly
controlled via either an ALSA mixer or via VIDIOC A/V routing
ioctls. Also, there's just one I2S bus on them.

However, on a device that have multiple I2S bus, userspace should
be able to control each of them individually, as some parts of the
pipeline may require it enabled while others may require it
disabled. So, I strongly believe that this should be a subdev
control on such hardware.

That's said, I don't know how rcar_drif uses it. If it has just
one I2S bus and it is used only for audio, then VIDIOC A/V routing
ioctls and/or an ALSA mixer could replace it. If not, then
it should be kept as-is and the driver would need to add support
for MC, in order for applications to identify the right
sub-devices that are associated with the pipelines where I2S
will be controlled.

Thanks,
Mauro

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

On 26/08/17 13:53, Mauro Carvalho Chehab wrote:
> The documentation doesn't mention if vdev-centric hardware
> control would have subdev API or not.
> 
> Add a notice about that, reflecting the current status, where
> three drivers use it, in order to support some subdev-specific
> controls.

I posted a patch removing v4l-subdevX support for cobalt. It's only used
within Cisco, so this is safe to do and won't break any userspace support.

atmel-isc is another driver that creates subdev nodes. Like cobalt, this
is unnecessary. There are no sensors that use private controls.

This driver is not referenced anywhere (dts or board file) in the kernel.
It is highly unlikely anyone would use v4l-subdevX nodes when there is no
need to do so. My suggestion is to add a kernel option for this driver
to enable v4l-subdevX support, but set it to 'default n'. Perhaps with
a note in the Kconfig description and a message in the kernel log that
this will be removed in the future.

The final driver is rcar_drif that uses this to set the "I2S Enable"
private control of the max2175 driver.

I remember that there was a long discussion over this control. I still
think that there is no need to mark this private. This is a recent
driver addition and we can get away with changing this, possibly using
a Kconfig option as well as discussed for the atmel-isc driver.

This is actually the only driver using a private control. I am of the
opinion that private controls were a mistake. I think it is the
bridge driver that has to decide whether or not to make subdev controls
available through a video node.

So in summary:

- drop is_private controls
- apply the cobalt patch (safe to do)
- add a Kconfig option for atmel-isc & rcar_drif that has to be explicitly
  enabled to support subdev nodes, and add logging that this is deprecated.
- by 4.17 or so remove this altogether.

If we agree to this, then this patch can be dropped.

Regards,

Hans

> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  Documentation/media/uapi/v4l/open.rst | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/open.rst 
> b/Documentation/media/uapi/v4l/open.rst
> index d0930fc170f0..48f628bbabc7 100644
> --- a/Documentation/media/uapi/v4l/open.rst
> +++ b/Documentation/media/uapi/v4l/open.rst
> @@ -46,6 +46,13 @@ 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.
>  
> +.. note::
> +
> +   A **vdev-centric** may also optionally expose V4L2 sub-devices via
> +   :ref:`sub-device API `. In that case, it has to implement
> +   the :ref:`media controller API ` as well.
> +
> +
>  .. attention::
>  
> Devices that require **mc-centric** hardware peripheral control should
>

Re: [PATCH v4 7/7] media: open.rst: add a notice about subdev-API on vdev-centric