[PATCH] scsi: libiscsi: Fix an error handling path in 'iscsi_session_setup()'

[Christophe JAILLET]

All error handling paths in this function go through
'iscsi_host_dec_session_cnt()' except this one.
Fix it and properly decrement the number of active sessions in such a case.

Signed-off-by: Christophe JAILLET 
---
 drivers/scsi/libiscsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index bd4605a34f54..5d195375ba75 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2779,7 +2779,7 @@ iscsi_session_setup(struct iscsi_transport *iscsit, 
struct Scsi_Host *shost,
   "must be a power of 2.\n", total_cmds);
total_cmds = rounddown_pow_of_two(total_cmds);
if (total_cmds < ISCSI_TOTAL_CMDS_MIN)
-   return NULL;
+   goto dec_session_count;
printk(KERN_INFO "iscsi: Rounding can_queue to %d.\n",
   total_cmds);
}
-- 
2.11.0

[PATCH] scsi: libiscsi: Fix an error handling path in 'iscsi_session_setup()'

[Christophe JAILLET]

All error handling paths in this function go through
'iscsi_host_dec_session_cnt()' except this one.
Fix it and properly decrement the number of active sessions in such a case.

Signed-off-by: Christophe JAILLET 
---
 drivers/scsi/libiscsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index bd4605a34f54..5d195375ba75 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2779,7 +2779,7 @@ iscsi_session_setup(struct iscsi_transport *iscsit, 
struct Scsi_Host *shost,
   "must be a power of 2.\n", total_cmds);
total_cmds = rounddown_pow_of_two(total_cmds);
if (total_cmds < ISCSI_TOTAL_CMDS_MIN)
-   return NULL;
+   goto dec_session_count;
printk(KERN_INFO "iscsi: Rounding can_queue to %d.\n",
   total_cmds);
}
-- 
2.11.0

Re: [PATCH 2/9] Implement containers as kernel objects

[Richard Guy Briggs]

On 2017-09-06 09:03, Serge E. Hallyn wrote:
> Quoting Richard Guy Briggs (r...@redhat.com):
> ...
> > > I believe we are going to need a container ID to container definition
> > > (namespace, etc.) mapping mechanism regardless of if the container ID
> > > is provided by userspace or a kernel generated serial number.  This
> > > mapping should be recorded in the audit log when the container ID is
> > > created/defined.
> > 
> > Agreed.
> > 
> > > > As was suggested in one of the previous threads, if there are any 
> > > > events not
> > > > associated with a task (incoming network packets) we log the namespace 
> > > > ID and
> > > > then only concern ourselves with its container serial number or 
> > > > container name
> > > > once it becomes associated with a task at which point that tracking 
> > > > will be
> > > > more important anyways.
> > > 
> > > Agreed.  After all, a single namespace can be shared between multiple
> > > containers.  For those security officers who need to track individual
> > > events like this they will have the container ID mapping information
> > > in the logs as well so they should be able to trace the unassociated
> > > event to a set of containers.
> > > 
> > > > I'm not convinced that a userspace or kernel generated UUID is that 
> > > > useful
> > > > since they are large, not human readable and may not be globally unique 
> > > > given
> > > > the "pets vs cattle" direction we are going with potentially identical
> > > > conditions in hosts or containers spawning containers, but I see no 
> > > > need to
> > > > restrict them.
> > > 
> > > From a kernel perspective I think an int should suffice; after all,
> > > you can't have more containers then you have processes.  If the
> > > container engine requires something more complex, it can use the int
> > > as input to its own mapping function.
> > 
> > PIDs roll over.  That already causes some ambiguity in reporting.  If a
> > system is constantly spawning and reaping containers, especially
> > single-process containers, I don't want to have to worry about that ID
> > rolling to keep track of it even though there should be audit records of
> > the spawn and death of each container.  There isn't significant cost
> > added here compared with some of the other overhead we're dealing with.
> 
> Strawman proposal:
> 
> 1. Each clone/unshare/setns involving a namespace type generates an audit
> message along the lines of:
> 
> PID 9512 (pid in init_pid_ns) in auditnsid 0001 cloned 
> CLONE_NEWNS|CLONE_NEWNET
> new auditnsid: 0002
> associated namespaces: (list of all namespace filesystem inode numbers)

As you will have seen, this is pretty much what my most recent proposal 
suggests.

> 2. Userspace (i.e. the container logging deamon here) can watch the audit log
> for all messages relating to auditnsid 0002.  Presumably there will be
> messages along the lines of "PID 9513 in auditnsid 0002 cloned...".  The
> container logging daemon can track those messages and add the new auditnsids
> to the list it watches.

Yes.

> 3. If a container is migrated (checkpointed and restored here or elsewhere),
> userspace can just follow the appropriate logs for the new containers.

Yes.

> Userspace does not ever *request* a auditnsid.  They are ephemeral, just a
> tool to track the namespaces through the audit log.  They are however 
> guaranteed
> to never be re-used until reboot.

Well, this is where things get controvertial...  I had wanted this, a
kernel-generated serial number unique to a running kernel to track every
container initiation, but this does have some CRIU challenges pointed
out by Eric Biederman.  Nested containers will not have a consistent
view on a new host and no way to make it consistent.  If we could
guarantee that containers would never be nested, this could be workable.
I think nesting is inevitable in the future given the variety and
creativity of the orchestration tools, so restricting this seems
short-sighted.

At the moment the approch is to let the orchestrator determine the ID of
a container.  Some have argued for as small as u32 and others for a full
UUID.  A u32 runs the risk of rolling, so a u64 seems like a reasonable
step to solve that issue.  Others would like to be able to store a full
UUID which seemed like a good idea on the outset, but on further
thinking, this is something the orchestrator can manage while minimising
the number of bits of required information per audit record to guarantee
we can identify the provenance of a particular audit event.  Let's see
if we can make it work with a u64.

> (Feels like someone must have proposed this before)

Thsee ideas have been thrown around a few times and I'm starting to
understand them better.

> -serge

- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Re: [PATCH 2/9] Implement containers as kernel objects

[Richard Guy Briggs]

On 2017-09-06 09:03, Serge E. Hallyn wrote:
> Quoting Richard Guy Briggs (r...@redhat.com):
> ...
> > > I believe we are going to need a container ID to container definition
> > > (namespace, etc.) mapping mechanism regardless of if the container ID
> > > is provided by userspace or a kernel generated serial number.  This
> > > mapping should be recorded in the audit log when the container ID is
> > > created/defined.
> > 
> > Agreed.
> > 
> > > > As was suggested in one of the previous threads, if there are any 
> > > > events not
> > > > associated with a task (incoming network packets) we log the namespace 
> > > > ID and
> > > > then only concern ourselves with its container serial number or 
> > > > container name
> > > > once it becomes associated with a task at which point that tracking 
> > > > will be
> > > > more important anyways.
> > > 
> > > Agreed.  After all, a single namespace can be shared between multiple
> > > containers.  For those security officers who need to track individual
> > > events like this they will have the container ID mapping information
> > > in the logs as well so they should be able to trace the unassociated
> > > event to a set of containers.
> > > 
> > > > I'm not convinced that a userspace or kernel generated UUID is that 
> > > > useful
> > > > since they are large, not human readable and may not be globally unique 
> > > > given
> > > > the "pets vs cattle" direction we are going with potentially identical
> > > > conditions in hosts or containers spawning containers, but I see no 
> > > > need to
> > > > restrict them.
> > > 
> > > From a kernel perspective I think an int should suffice; after all,
> > > you can't have more containers then you have processes.  If the
> > > container engine requires something more complex, it can use the int
> > > as input to its own mapping function.
> > 
> > PIDs roll over.  That already causes some ambiguity in reporting.  If a
> > system is constantly spawning and reaping containers, especially
> > single-process containers, I don't want to have to worry about that ID
> > rolling to keep track of it even though there should be audit records of
> > the spawn and death of each container.  There isn't significant cost
> > added here compared with some of the other overhead we're dealing with.
> 
> Strawman proposal:
> 
> 1. Each clone/unshare/setns involving a namespace type generates an audit
> message along the lines of:
> 
> PID 9512 (pid in init_pid_ns) in auditnsid 0001 cloned 
> CLONE_NEWNS|CLONE_NEWNET
> new auditnsid: 0002
> associated namespaces: (list of all namespace filesystem inode numbers)

As you will have seen, this is pretty much what my most recent proposal 
suggests.

> 2. Userspace (i.e. the container logging deamon here) can watch the audit log
> for all messages relating to auditnsid 0002.  Presumably there will be
> messages along the lines of "PID 9513 in auditnsid 0002 cloned...".  The
> container logging daemon can track those messages and add the new auditnsids
> to the list it watches.

Yes.

> 3. If a container is migrated (checkpointed and restored here or elsewhere),
> userspace can just follow the appropriate logs for the new containers.

Yes.

> Userspace does not ever *request* a auditnsid.  They are ephemeral, just a
> tool to track the namespaces through the audit log.  They are however 
> guaranteed
> to never be re-used until reboot.

Well, this is where things get controvertial...  I had wanted this, a
kernel-generated serial number unique to a running kernel to track every
container initiation, but this does have some CRIU challenges pointed
out by Eric Biederman.  Nested containers will not have a consistent
view on a new host and no way to make it consistent.  If we could
guarantee that containers would never be nested, this could be workable.
I think nesting is inevitable in the future given the variety and
creativity of the orchestration tools, so restricting this seems
short-sighted.

At the moment the approch is to let the orchestrator determine the ID of
a container.  Some have argued for as small as u32 and others for a full
UUID.  A u32 runs the risk of rolling, so a u64 seems like a reasonable
step to solve that issue.  Others would like to be able to store a full
UUID which seemed like a good idea on the outset, but on further
thinking, this is something the orchestrator can manage while minimising
the number of bits of required information per audit record to guarantee
we can identify the provenance of a particular audit event.  Let's see
if we can make it work with a u64.

> (Feels like someone must have proposed this before)

Thsee ideas have been thrown around a few times and I'm starting to
understand them better.

> -serge

- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

[PATCH] dmaengine: imx-sdma: Correct addr widths

[Nicolin Chen]

The driver also supports 2_BYTES and 1_BYTE in sdma_prep_slave_sg().
So this patch just adds them to the lists.

Signed-off-by: Nicolin Chen 
---
 drivers/dma/imx-sdma.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index a67ec1b..2be8d0d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -178,6 +178,10 @@
 #define SDMA_WATERMARK_LEVEL_HWE   BIT(29)
 #define SDMA_WATERMARK_LEVEL_CONT  BIT(31)
 
+#define SDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
 /*
  * Mode/Count of data node descriptors - IPCv2
  */
@@ -1851,8 +1855,8 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.device_prep_dma_cyclic = sdma_prep_dma_cyclic;
sdma->dma_device.device_config = sdma_config;
sdma->dma_device.device_terminate_all = sdma_disable_channel_with_delay;
-   sdma->dma_device.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
-   sdma->dma_device.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+   sdma->dma_device.src_addr_widths = SDMA_DMA_BUSWIDTHS;
+   sdma->dma_device.dst_addr_widths = SDMA_DMA_BUSWIDTHS;
sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
sdma->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
sdma->dma_device.device_issue_pending = sdma_issue_pending;
-- 
2.1.4

[PATCH] dmaengine: imx-sdma: Correct addr widths

[Nicolin Chen]

The driver also supports 2_BYTES and 1_BYTE in sdma_prep_slave_sg().
So this patch just adds them to the lists.

Signed-off-by: Nicolin Chen 
---
 drivers/dma/imx-sdma.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index a67ec1b..2be8d0d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -178,6 +178,10 @@
 #define SDMA_WATERMARK_LEVEL_HWE   BIT(29)
 #define SDMA_WATERMARK_LEVEL_CONT  BIT(31)
 
+#define SDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
 /*
  * Mode/Count of data node descriptors - IPCv2
  */
@@ -1851,8 +1855,8 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.device_prep_dma_cyclic = sdma_prep_dma_cyclic;
sdma->dma_device.device_config = sdma_config;
sdma->dma_device.device_terminate_all = sdma_disable_channel_with_delay;
-   sdma->dma_device.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
-   sdma->dma_device.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+   sdma->dma_device.src_addr_widths = SDMA_DMA_BUSWIDTHS;
+   sdma->dma_device.dst_addr_widths = SDMA_DMA_BUSWIDTHS;
sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
sdma->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
sdma->dma_device.device_issue_pending = sdma_issue_pending;
-- 
2.1.4

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Guenter Roeck]

On Thu, Sep 14, 2017 at 04:18:03AM +0200, Willy Tarreau wrote:
> On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote:
> > > Yes. I don't recall if it is a direct --force or if you would have to
> > > remove the original tag first (with git push  :refs/tags/).
> > 
> > Ah, but then if someone had pulled the old tag, they would have to
> > delete it locally before they can pull in the new one.  That's the main
> > reason I'll not do this...
> 
> In fact not, the tags are automatically replaced upon pull. I've been
> using such a crappy workflow for some time in the past, sharing human
> errors with coworkers... Git is pretty tolerant to this. It's just
> that it's terribly confusing because you can then have two people with
> the same tag name pointing to different commit IDs, I really hate this,
> it only works when all users are in the same office and you shout
> "sorry I messed up, I'm pushing the tag again".
> 
> > Again, use the make command that we have just for this reason...
> 
> It also has the benefit of always reporting the same version for all
> users including those only downloading the -rc patch.
> 
It reports the same version, but it is not necessarily the same code.
There are cases where a rc is updated, but not the Makefile. That happens
quite a lot, actually. This is similar to mainline, which currently
claims to be v4.13.0 until -rc1, then it claims to be -rc1 until -rc2,
and so on.

Guenter

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Guenter Roeck]

On Thu, Sep 14, 2017 at 04:18:03AM +0200, Willy Tarreau wrote:
> On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote:
> > > Yes. I don't recall if it is a direct --force or if you would have to
> > > remove the original tag first (with git push  :refs/tags/).
> > 
> > Ah, but then if someone had pulled the old tag, they would have to
> > delete it locally before they can pull in the new one.  That's the main
> > reason I'll not do this...
> 
> In fact not, the tags are automatically replaced upon pull. I've been
> using such a crappy workflow for some time in the past, sharing human
> errors with coworkers... Git is pretty tolerant to this. It's just
> that it's terribly confusing because you can then have two people with
> the same tag name pointing to different commit IDs, I really hate this,
> it only works when all users are in the same office and you shout
> "sorry I messed up, I'm pushing the tag again".
> 
> > Again, use the make command that we have just for this reason...
> 
> It also has the benefit of always reporting the same version for all
> users including those only downloading the -rc patch.
> 
It reports the same version, but it is not necessarily the same code.
There are cases where a rc is updated, but not the Makefile. That happens
quite a lot, actually. This is similar to mainline, which currently
claims to be v4.13.0 until -rc1, then it claims to be -rc1 until -rc2,
and so on.

Guenter

Re: [PATCH] checkpatch: support function pointers for unnamed function definition arguments

[Joe Perches]

On Thu, 2017-09-14 at 11:01 +0800, Miles Chen wrote:
> Current unnamed function definition argument does not include function
> pointer cases and it reports warnings like:
> 
> WARNING: function definition argument 'void' should also have an identifier 
> name

> 
> Support function pointers for unnamed function arguments.
> 
> Signed-off-by: Miles Chen 
> ---
>  scripts/checkpatch.pl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index dd2c262..dc6da15 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5957,7 +5957,7 @@ sub process {
>  
>  # check for function declarations that have arguments without identifier 
> names
>   if (defined $stat &&
> - $stat =~ 
> /^.\s*(?:extern\s+)?$Type\s*$Ident\s*\(\s*([^{]+)\s*\)\s*;/s &&
> + $stat =~ 
> /^.\s*(?:extern\s+)?$Type\s*\(?\s*\*?\s*$Ident\s*\)\s*\(\s*([^{]+)\s*\)\s*;/s 
> &&

Better would be to specifically support function pointers like:
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 05dd72693621..7289c1eb0b19 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5957,7 +5957,7 @@ sub process {
 
 # check for function declarations that have arguments without identifier names
    if (defined $stat &&
-   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*$Ident\s*\(\s*([^{]+)\s*\)\s*;/s &&
+   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*(?:$Ident|\(\s*\*\s*$Ident\s*\))\s*\(\s*([^{]+)\s*\)\s*;/s
 &&
    $1 ne "void") {
    my $args = trim($1);
    while ($args =~ 
m/\s*($Type\s*(?:$Ident|\(\s*\*\s*$Ident?\s*\)\s*$balanced_parens)?)/g) {

Re: [PATCH] checkpatch: support function pointers for unnamed function definition arguments

[Joe Perches]

On Thu, 2017-09-14 at 11:01 +0800, Miles Chen wrote:
> Current unnamed function definition argument does not include function
> pointer cases and it reports warnings like:
> 
> WARNING: function definition argument 'void' should also have an identifier 
> name

> 
> Support function pointers for unnamed function arguments.
> 
> Signed-off-by: Miles Chen 
> ---
>  scripts/checkpatch.pl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index dd2c262..dc6da15 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5957,7 +5957,7 @@ sub process {
>  
>  # check for function declarations that have arguments without identifier 
> names
>   if (defined $stat &&
> - $stat =~ 
> /^.\s*(?:extern\s+)?$Type\s*$Ident\s*\(\s*([^{]+)\s*\)\s*;/s &&
> + $stat =~ 
> /^.\s*(?:extern\s+)?$Type\s*\(?\s*\*?\s*$Ident\s*\)\s*\(\s*([^{]+)\s*\)\s*;/s 
> &&

Better would be to specifically support function pointers like:
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 05dd72693621..7289c1eb0b19 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5957,7 +5957,7 @@ sub process {
 
 # check for function declarations that have arguments without identifier names
    if (defined $stat &&
-   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*$Ident\s*\(\s*([^{]+)\s*\)\s*;/s &&
+   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*(?:$Ident|\(\s*\*\s*$Ident\s*\))\s*\(\s*([^{]+)\s*\)\s*;/s
 &&
    $1 ne "void") {
    my $args = trim($1);
    while ($args =~ 
m/\s*($Type\s*(?:$Ident|\(\s*\*\s*$Ident?\s*\)\s*$balanced_parens)?)/g) {

Re: [PATCH] tools: objtool: fix memory leak in elf_create_rela_section()

[Ingo Molnar]

* Josh Poimboeuf  wrote:

> From: Martin Kepplinger 
> 
> Let's free the allocated char array relaname before returning
> in order to avoid leaking memory.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Josh Poimboeuf 
> ---
>  tools/objtool/elf.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> index 6e9f980a7d26..6aacbc31316d 100644
> --- a/tools/objtool/elf.c
> +++ b/tools/objtool/elf.c
> @@ -508,8 +508,12 @@ struct section *elf_create_rela_section(struct elf *elf, 
> struct section *base)
>   strcat(relaname, base->name);
>  
>   sec = elf_create_section(elf, relaname, sizeof(GElf_Rela), 0);
> - if (!sec)
> + if (!sec) {
> + free(relaname);
>   return NULL;
> + }
> +
> + free(relaname);

Erm, I'm quite sure if you read this code a second time you'll see how this 
pattern could be improved! ;-)

Thanks,

Ingo

Re: [PATCH] tools: objtool: fix memory leak in elf_create_rela_section()

[Ingo Molnar]

* Josh Poimboeuf  wrote:

> From: Martin Kepplinger 
> 
> Let's free the allocated char array relaname before returning
> in order to avoid leaking memory.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Josh Poimboeuf 
> ---
>  tools/objtool/elf.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> index 6e9f980a7d26..6aacbc31316d 100644
> --- a/tools/objtool/elf.c
> +++ b/tools/objtool/elf.c
> @@ -508,8 +508,12 @@ struct section *elf_create_rela_section(struct elf *elf, 
> struct section *base)
>   strcat(relaname, base->name);
>  
>   sec = elf_create_section(elf, relaname, sizeof(GElf_Rela), 0);
> - if (!sec)
> + if (!sec) {
> + free(relaname);
>   return NULL;
> + }
> +
> + free(relaname);

Erm, I'm quite sure if you read this code a second time you'll see how this 
pattern could be improved! ;-)

Thanks,

Ingo

Re: RFC: Audit Kernel Container IDs

[Richard Guy Briggs]

On 2017-09-13 14:33, Carlos O'Donell wrote:
> On 09/13/2017 12:13 PM, Richard Guy Briggs wrote:
> > Containers are a userspace concept.  The kernel knows nothing of them.
> 
> I am looking at this RFC from a userspace perspective, particularly from
> the loader's point of view and the unshare syscall and the semantics that
> arise from the use of it.
> 
> At a high level what you are doing is providing a way to group, without
> hierarchy, processes and namespaces. The processes can move between
> container's if they have CAP_CONTAINER_ADMIN and can open and write to
> a special proc file.
> 
> * With unshare a thread may dissociate part of its execution context and
>   therefore see a distinct mount namespace. When you say "process" in this
>   particular RFC do you exclude the fact that a thread might be in a
>   distinct container from the rest of the threads in the process?
> 
> > The Linux audit system needs a way to be able to track the container
> > provenance of events and actions.  Audit needs the kernel's help to do
> > this.
> 
> * Why does the Linux audit system need to tracker container provenance?

- ability to filter unwanted, irrelevant or unimportant messages before
  they fill queue so important messages don't get lost.  This is a
  certification requirement.

- ability to make security claims about containers, require tracking of
  actions within those containers to ensure compliance with established
  security policies.

- ability to route messages from events to relevant audit daemon
  instance or host audit daemon instance or both, as required or
  determined by user-initiated rules

>   - How does it help to provide better audit messages?
> 
>   - Is it be enough to list the namespace that a process occupies?

We started with that approach back more than 4 years ago and found it
helped, but didn't go far enough in terms of quick and inexpensive
record filtering and left some doubt about provenance of events in the
case of non-user context events (incoming network packets).

> * Why does it need the kernel's help?
> 
>   - Is there a race condition that is only fixable with kernel support?

This was a concern, but relatively minor compared with the other benefits.

>   - Or is it easier with kernel help but not required?

It is much easier and much less expensive.

> Providing background on these questions would help clarify the
> design requirements.

Here are some references that should help provide some background:
https://github.com/linux-audit/audit-kernel/issues/32
RFE: add namespace IDs to audit records


https://github.com/linux-audit/audit-documentation/wiki/SPEC-Virtualization-Manager-Guest-Lifecycle-Events
SPEC Virtualization Manager Guest Lifecycle Events

https://lwn.net/Articles/699819/
Audit, namespaces, and containers

https://lwn.net/Articles/723561/
Containers as kernel objects
(my reply, with references: https://lkml.org/lkml/2017/8/14/15 )

https://bugzilla.redhat.com/show_bug.cgi?id=1045666
audit: add namespace IDs to log records

> > Since the concept of a container is entirely a userspace concept, a
> > trigger signal from the userspace container orchestration system
> > initiates this.  This will define a point in time and a set of resources
> > associated with a particular container with an audit container ID.
> 
> Please don't use the word 'signal', I suggest 'register' since you are
> writing to a filesystem.

Ok, that's a very reasonable request.  'signal' has a previous meaning.

> > The trigger is a pseudo filesystem (proc, since PID tree already exists)
> > write of a u64 representing the container ID to a file representing a
> > process that will become the first process in a new container.
> > This might place restrictions on mount namespaces required to define a
> > container, or at least careful checking of namespaces in the kernel to
> > verify permissions of the orchestrator so it can't change its own
> > container ID.
> > A bind mount of nsfs may be necessary in the container orchestrator's
> > mntNS.
> > 
> > Require a new CAP_CONTAINER_ADMIN to be able to write to the pseudo
> > filesystem to have this action permitted.  At that time, record the
> > child container's user-supplied 64-bit container identifier along with
> 
> What is a "child container?" Containers don't have any hierarchy.

Maybe some don't, but that's not likely to last long given the
abstraction and nesting of orchestration tools.  This must be nestable.

> I assume that if you don't have CAP_CONTAINER_ADMIN, that nothing prevents
> your continued operation as we have today?

Correct.  It won't prevent processes that otherwise have permissions
today from creating all the namespaces it wishes.

> > the child container's first process (which may become the container's
> > "init" process) process ID (referenced from the initial PID namespace),
> > all namespace IDs (in the form of a nsfs device 

Re: RFC: Audit Kernel Container IDs

[Richard Guy Briggs]

On 2017-09-13 14:33, Carlos O'Donell wrote:
> On 09/13/2017 12:13 PM, Richard Guy Briggs wrote:
> > Containers are a userspace concept.  The kernel knows nothing of them.
> 
> I am looking at this RFC from a userspace perspective, particularly from
> the loader's point of view and the unshare syscall and the semantics that
> arise from the use of it.
> 
> At a high level what you are doing is providing a way to group, without
> hierarchy, processes and namespaces. The processes can move between
> container's if they have CAP_CONTAINER_ADMIN and can open and write to
> a special proc file.
> 
> * With unshare a thread may dissociate part of its execution context and
>   therefore see a distinct mount namespace. When you say "process" in this
>   particular RFC do you exclude the fact that a thread might be in a
>   distinct container from the rest of the threads in the process?
> 
> > The Linux audit system needs a way to be able to track the container
> > provenance of events and actions.  Audit needs the kernel's help to do
> > this.
> 
> * Why does the Linux audit system need to tracker container provenance?

- ability to filter unwanted, irrelevant or unimportant messages before
  they fill queue so important messages don't get lost.  This is a
  certification requirement.

- ability to make security claims about containers, require tracking of
  actions within those containers to ensure compliance with established
  security policies.

- ability to route messages from events to relevant audit daemon
  instance or host audit daemon instance or both, as required or
  determined by user-initiated rules

>   - How does it help to provide better audit messages?
> 
>   - Is it be enough to list the namespace that a process occupies?

We started with that approach back more than 4 years ago and found it
helped, but didn't go far enough in terms of quick and inexpensive
record filtering and left some doubt about provenance of events in the
case of non-user context events (incoming network packets).

> * Why does it need the kernel's help?
> 
>   - Is there a race condition that is only fixable with kernel support?

This was a concern, but relatively minor compared with the other benefits.

>   - Or is it easier with kernel help but not required?

It is much easier and much less expensive.

> Providing background on these questions would help clarify the
> design requirements.

Here are some references that should help provide some background:
https://github.com/linux-audit/audit-kernel/issues/32
RFE: add namespace IDs to audit records


https://github.com/linux-audit/audit-documentation/wiki/SPEC-Virtualization-Manager-Guest-Lifecycle-Events
SPEC Virtualization Manager Guest Lifecycle Events

https://lwn.net/Articles/699819/
Audit, namespaces, and containers

https://lwn.net/Articles/723561/
Containers as kernel objects
(my reply, with references: https://lkml.org/lkml/2017/8/14/15 )

https://bugzilla.redhat.com/show_bug.cgi?id=1045666
audit: add namespace IDs to log records

> > Since the concept of a container is entirely a userspace concept, a
> > trigger signal from the userspace container orchestration system
> > initiates this.  This will define a point in time and a set of resources
> > associated with a particular container with an audit container ID.
> 
> Please don't use the word 'signal', I suggest 'register' since you are
> writing to a filesystem.

Ok, that's a very reasonable request.  'signal' has a previous meaning.

> > The trigger is a pseudo filesystem (proc, since PID tree already exists)
> > write of a u64 representing the container ID to a file representing a
> > process that will become the first process in a new container.
> > This might place restrictions on mount namespaces required to define a
> > container, or at least careful checking of namespaces in the kernel to
> > verify permissions of the orchestrator so it can't change its own
> > container ID.
> > A bind mount of nsfs may be necessary in the container orchestrator's
> > mntNS.
> > 
> > Require a new CAP_CONTAINER_ADMIN to be able to write to the pseudo
> > filesystem to have this action permitted.  At that time, record the
> > child container's user-supplied 64-bit container identifier along with
> 
> What is a "child container?" Containers don't have any hierarchy.

Maybe some don't, but that's not likely to last long given the
abstraction and nesting of orchestration tools.  This must be nestable.

> I assume that if you don't have CAP_CONTAINER_ADMIN, that nothing prevents
> your continued operation as we have today?

Correct.  It won't prevent processes that otherwise have permissions
today from creating all the namespaces it wishes.

> > the child container's first process (which may become the container's
> > "init" process) process ID (referenced from the initial PID namespace),
> > all namespace IDs (in the form of a nsfs device 

Re: [patch V2 25/29] lockup_detector: Implement init time detection of perf

[Ingo Molnar]

* Thomas Gleixner  wrote:

> On Wed, 13 Sep 2017, Don Zickus wrote:
> > > +/* Return 0, if a NMI watchdog is available. Error code otherwise */
> > > +int __weak __init void watchdog_nmi_probe(void)
> > 
> > ^^^ compile error, can't have 'int' and 'void'.  Removing 'void' fixes it.
> 
> Yes, I know. I feel stupid because I'm 100% sure that I compiled it 

So there a Kconfig dependency on that - defconfig won't show it, which might be 
why you didn't see it?

Thanks,

Ingo

Re: [patch V2 00/29] lockup_detector: Cure hotplug deadlocks and replace duct tape

[Ingo Molnar]

* Don Zickus  wrote:

> On Tue, Sep 12, 2017 at 09:36:54PM +0200, Thomas Gleixner wrote:
> > The lockup detector is broken is several ways:
> > 
> > - It's deadlock prone vs. CPU hotplug in various ways. Some of these
> >   are due to recursive cpus_read_lock() others are due to
> >   cpus_read_lock() from CPU hotplug callbacks which immediately lock
> >   the machine because cpus are write locked.
> > 
> > - The handling of the cpu hotplug threads happens sideways to the
> >   smpboot thread infrastructure, which is racy and pointless
> > 
> > - The handling of the user space sysctl interface is a complete
> >   trainwreck as it fiddles directly with variables which can be
> >   modified or evaluated by the running watchdogs.
> > 
> > - The perf event initialization is a trainwreck as it tries to create
> >   perf events over and over even if perf is not functional (no
> >   hardware, ). To avoid excessive dmesg spam it contains magic
> >   printk ratelimiting along with either wrong or useless messages.
> > 
> > - The code structure is horrible as ifdef sections are scattered all
> >   over the place which makes it unreadable
> > 
> > - There is more wreckage, but see the changelogs for the ugly details.
> >
> 
> Aside from the simple compile issue in patch 25.  I have no issues with this
> patchset.  Thanks Thomas!
> 
> Reviewed-by: Don Zickus 

Thanks guys! I've applied the series and will push it out after some testing.

Thanks,

Ingo

Re: [patch V2 25/29] lockup_detector: Implement init time detection of perf

[Ingo Molnar]

* Thomas Gleixner  wrote:

> On Wed, 13 Sep 2017, Don Zickus wrote:
> > > +/* Return 0, if a NMI watchdog is available. Error code otherwise */
> > > +int __weak __init void watchdog_nmi_probe(void)
> > 
> > ^^^ compile error, can't have 'int' and 'void'.  Removing 'void' fixes it.
> 
> Yes, I know. I feel stupid because I'm 100% sure that I compiled it 

So there a Kconfig dependency on that - defconfig won't show it, which might be 
why you didn't see it?

Thanks,

Ingo

Re: [patch V2 00/29] lockup_detector: Cure hotplug deadlocks and replace duct tape

[Ingo Molnar]

* Don Zickus  wrote:

> On Tue, Sep 12, 2017 at 09:36:54PM +0200, Thomas Gleixner wrote:
> > The lockup detector is broken is several ways:
> > 
> > - It's deadlock prone vs. CPU hotplug in various ways. Some of these
> >   are due to recursive cpus_read_lock() others are due to
> >   cpus_read_lock() from CPU hotplug callbacks which immediately lock
> >   the machine because cpus are write locked.
> > 
> > - The handling of the cpu hotplug threads happens sideways to the
> >   smpboot thread infrastructure, which is racy and pointless
> > 
> > - The handling of the user space sysctl interface is a complete
> >   trainwreck as it fiddles directly with variables which can be
> >   modified or evaluated by the running watchdogs.
> > 
> > - The perf event initialization is a trainwreck as it tries to create
> >   perf events over and over even if perf is not functional (no
> >   hardware, ). To avoid excessive dmesg spam it contains magic
> >   printk ratelimiting along with either wrong or useless messages.
> > 
> > - The code structure is horrible as ifdef sections are scattered all
> >   over the place which makes it unreadable
> > 
> > - There is more wreckage, but see the changelogs for the ugly details.
> >
> 
> Aside from the simple compile issue in patch 25.  I have no issues with this
> patchset.  Thanks Thomas!
> 
> Reviewed-by: Don Zickus 

Thanks guys! I've applied the series and will push it out after some testing.

Thanks,

Ingo

[PATCH] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD

[Yisheng Xie]

According to Spec, it is ILLEGAL to set STE.S1STALLD if STALL_MODEL
is not 0b00, which means we should not disable stall mode if stall
or terminate mode is not configuable.

As Jean-Philippe's suggestion, this patch introduce a feature bit
ARM_SMMU_FEAT_STALL_FORCE, which means smmu only supports stall force.
Therefore, we can avoid the ILLEGAL setting of STE.S1STALLD.by checking
ARM_SMMU_FEAT_STALL_FORCE.

This patch keeps the ARM_SMMU_FEAT_STALLS as the meaning of stall supported
(force or configuable) to easy to expand the future function, i.e. we can
only use ARM_SMMU_FEAT_STALLS to check whether we should register fault
handle or enable master can_stall, etc to supporte platform SVM.

After apply this patch, the feature bit and S1STALLD setting will be like:
STALL_MODEL  FEATURE  S1STALLD
0b00 ARM_SMMU_FEAT_STALLS 0b1
0b01 !ARM_SMMU_FEAT_STALLS && !ARM_SMMU_FEAT_STALL_FORCE  0b0
0b10 ARM_SMMU_FEAT_STALLS && ARM_SMMU_FEAT_STALL_FORCE0b0

Signed-off-by: Yisheng Xie 
---
 drivers/iommu/arm-smmu-v3.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index e67ba6c..d2a3627 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -603,7 +603,8 @@ struct arm_smmu_device {
 #define ARM_SMMU_FEAT_TRANS_S1 (1 << 9)
 #define ARM_SMMU_FEAT_TRANS_S2 (1 << 10)
 #define ARM_SMMU_FEAT_STALLS   (1 << 11)
-#define ARM_SMMU_FEAT_HYP  (1 << 12)
+#define ARM_SMMU_FEAT_STALL_FORCE  (1 << 12)
+#define ARM_SMMU_FEAT_HYP  (1 << 13)
u32 features;
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
@@ -1112,7 +1113,8 @@ static void arm_smmu_write_strtab_ent(struct 
arm_smmu_device *smmu, u32 sid,
 #endif
 STRTAB_STE_1_STRW_NSEL1 << STRTAB_STE_1_STRW_SHIFT);
 
-   if (smmu->features & ARM_SMMU_FEAT_STALLS)
+   if (smmu->features & ARM_SMMU_FEAT_STALLS &&
+  !(smmu->features & ARM_SMMU_FEAT_STALL_FORCE))
dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
 
val |= (ste->s1_cfg->cdptr_dma & STRTAB_STE_0_S1CTXPTR_MASK
@@ -2536,9 +2538,10 @@ static int arm_smmu_device_hw_probe(struct 
arm_smmu_device *smmu)
 coherent ? "true" : "false");
 
switch (reg & IDR0_STALL_MODEL_MASK << IDR0_STALL_MODEL_SHIFT) {
-   case IDR0_STALL_MODEL_STALL:
-   /* Fallthrough */
case IDR0_STALL_MODEL_FORCE:
+   smmu->features |= ARM_SMMU_FEAT_STALL_FORCE;
+   /* Fallthrough */
+   case IDR0_STALL_MODEL_STALL:
smmu->features |= ARM_SMMU_FEAT_STALLS;
}
 
-- 
1.7.12.4

[PATCH] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD

[Yisheng Xie]

According to Spec, it is ILLEGAL to set STE.S1STALLD if STALL_MODEL
is not 0b00, which means we should not disable stall mode if stall
or terminate mode is not configuable.

As Jean-Philippe's suggestion, this patch introduce a feature bit
ARM_SMMU_FEAT_STALL_FORCE, which means smmu only supports stall force.
Therefore, we can avoid the ILLEGAL setting of STE.S1STALLD.by checking
ARM_SMMU_FEAT_STALL_FORCE.

This patch keeps the ARM_SMMU_FEAT_STALLS as the meaning of stall supported
(force or configuable) to easy to expand the future function, i.e. we can
only use ARM_SMMU_FEAT_STALLS to check whether we should register fault
handle or enable master can_stall, etc to supporte platform SVM.

After apply this patch, the feature bit and S1STALLD setting will be like:
STALL_MODEL  FEATURE  S1STALLD
0b00 ARM_SMMU_FEAT_STALLS 0b1
0b01 !ARM_SMMU_FEAT_STALLS && !ARM_SMMU_FEAT_STALL_FORCE  0b0
0b10 ARM_SMMU_FEAT_STALLS && ARM_SMMU_FEAT_STALL_FORCE0b0

Signed-off-by: Yisheng Xie 
---
 drivers/iommu/arm-smmu-v3.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index e67ba6c..d2a3627 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -603,7 +603,8 @@ struct arm_smmu_device {
 #define ARM_SMMU_FEAT_TRANS_S1 (1 << 9)
 #define ARM_SMMU_FEAT_TRANS_S2 (1 << 10)
 #define ARM_SMMU_FEAT_STALLS   (1 << 11)
-#define ARM_SMMU_FEAT_HYP  (1 << 12)
+#define ARM_SMMU_FEAT_STALL_FORCE  (1 << 12)
+#define ARM_SMMU_FEAT_HYP  (1 << 13)
u32 features;
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
@@ -1112,7 +1113,8 @@ static void arm_smmu_write_strtab_ent(struct 
arm_smmu_device *smmu, u32 sid,
 #endif
 STRTAB_STE_1_STRW_NSEL1 << STRTAB_STE_1_STRW_SHIFT);
 
-   if (smmu->features & ARM_SMMU_FEAT_STALLS)
+   if (smmu->features & ARM_SMMU_FEAT_STALLS &&
+  !(smmu->features & ARM_SMMU_FEAT_STALL_FORCE))
dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
 
val |= (ste->s1_cfg->cdptr_dma & STRTAB_STE_0_S1CTXPTR_MASK
@@ -2536,9 +2538,10 @@ static int arm_smmu_device_hw_probe(struct 
arm_smmu_device *smmu)
 coherent ? "true" : "false");
 
switch (reg & IDR0_STALL_MODEL_MASK << IDR0_STALL_MODEL_SHIFT) {
-   case IDR0_STALL_MODEL_STALL:
-   /* Fallthrough */
case IDR0_STALL_MODEL_FORCE:
+   smmu->features |= ARM_SMMU_FEAT_STALL_FORCE;
+   /* Fallthrough */
+   case IDR0_STALL_MODEL_STALL:
smmu->features |= ARM_SMMU_FEAT_STALLS;
}
 
-- 
1.7.12.4

[PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu()

[zijun_hu]

From: zijun_hu 

get_cpu_number() doesn't use existing helper to iterate over possible
CPUs, so error happens in case of discontinuous @cpu_possible_mask
such as 0b0001.

fixed by using existing helper for_each_possible_cpu().

Signed-off-by: zijun_hu 
---
 drivers/irqchip/irq-gic-v3.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 19d642eae096..2a0427c2971e 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -990,7 +990,7 @@ static int get_cpu_number(struct device_node *dn)
 {
const __be32 *cell;
u64 hwid;
-   int i;
+   int cpu;
 
cell = of_get_property(dn, "reg", NULL);
if (!cell)
@@ -1004,9 +1004,9 @@ static int get_cpu_number(struct device_node *dn)
if (hwid & ~MPIDR_HWID_BITMASK)
return -1;
 
-   for (i = 0; i < num_possible_cpus(); i++)
-   if (cpu_logical_map(i) == hwid)
-   return i;
+   for_each_possible_cpu(cpu)
+   if (cpu_logical_map(cpu) == hwid)
+   return cpu;
 
return -1;
 }
-- 
1.9.1

[PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu()

[zijun_hu]

From: zijun_hu 

get_cpu_number() doesn't use existing helper to iterate over possible
CPUs, so error happens in case of discontinuous @cpu_possible_mask
such as 0b0001.

fixed by using existing helper for_each_possible_cpu().

Signed-off-by: zijun_hu 
---
 drivers/irqchip/irq-gic-v3.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 19d642eae096..2a0427c2971e 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -990,7 +990,7 @@ static int get_cpu_number(struct device_node *dn)
 {
const __be32 *cell;
u64 hwid;
-   int i;
+   int cpu;
 
cell = of_get_property(dn, "reg", NULL);
if (!cell)
@@ -1004,9 +1004,9 @@ static int get_cpu_number(struct device_node *dn)
if (hwid & ~MPIDR_HWID_BITMASK)
return -1;
 
-   for (i = 0; i < num_possible_cpus(); i++)
-   if (cpu_logical_map(i) == hwid)
-   return i;
+   for_each_possible_cpu(cpu)
+   if (cpu_logical_map(cpu) == hwid)
+   return cpu;
 
return -1;
 }
-- 
1.9.1

[PATCH v2 3/3] media: ov7670: Add the s_power operation

[Wenyou Yang]

Add the s_power operation which is responsible for manipulating the
power dowm mode through the PWDN pin and the reset operation through
the RESET pin.

Signed-off-by: Wenyou Yang 
---

Changes in v2:
 - Add the patch to support the get_fmt ops.
 - Remove the redundant invoking ov7670_init_gpio().

 drivers/media/i2c/ov7670.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index efc738112e2a..d1211ae48f63 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1530,6 +1530,22 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
const struct v4l2_dbg_regis
 }
 #endif
 
+static int ov7670_s_power(struct v4l2_subdev *sd, int on)
+{
+   struct ov7670_info *info = to_state(sd);
+
+   if (info->pwdn_gpio)
+   gpiod_direction_output(info->pwdn_gpio, !on);
+   if (on && info->resetb_gpio) {
+   gpiod_set_value(info->resetb_gpio, 1);
+   usleep_range(500, 1000);
+   gpiod_set_value(info->resetb_gpio, 0);
+   usleep_range(3000, 5000);
+   }
+
+   return 0;
+}
+
 /* --- */
 
 static const struct v4l2_subdev_core_ops ov7670_core_ops = {
@@ -1539,6 +1555,7 @@ static const struct v4l2_subdev_core_ops ov7670_core_ops 
= {
.g_register = ov7670_g_register,
.s_register = ov7670_s_register,
 #endif
+   .s_power = ov7670_s_power,
 };
 
 static const struct v4l2_subdev_video_ops ov7670_video_ops = {
@@ -1645,23 +1662,25 @@ static int ov7670_probe(struct i2c_client *client,
if (ret)
return ret;
 
-   ret = ov7670_init_gpio(client, info);
-   if (ret)
-   goto clk_disable;
-
info->clock_speed = clk_get_rate(info->clk) / 100;
if (info->clock_speed < 10 || info->clock_speed > 48) {
ret = -EINVAL;
goto clk_disable;
}
 
+   ret = ov7670_init_gpio(client, info);
+   if (ret)
+   goto clk_disable;
+
+   ov7670_s_power(sd, 1);
+
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
v4l_dbg(1, debug, client,
"chip found @ 0x%x (%s) is not an ov7670 chip.\n",
client->addr << 1, client->adapter->name);
-   goto clk_disable;
+   goto power_off;
}
v4l_info(client, "chip found @ 0x%02x (%s)\n",
client->addr << 1, client->adapter->name);
@@ -1734,6 +1753,8 @@ static int ov7670_probe(struct i2c_client *client,
media_entity_cleanup(>sd.entity);
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
+power_off:
+   ov7670_s_power(sd, 0);
 clk_disable:
clk_disable_unprepare(info->clk);
return ret;
@@ -1749,6 +1770,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_ctrl_handler_free(>hdl);
clk_disable_unprepare(info->clk);
media_entity_cleanup(>sd.entity);
+   ov7670_s_power(sd, 0);
return 0;
 }
 
-- 
2.13.0

[PATCH v2 3/3] media: ov7670: Add the s_power operation

[Wenyou Yang]

Add the s_power operation which is responsible for manipulating the
power dowm mode through the PWDN pin and the reset operation through
the RESET pin.

Signed-off-by: Wenyou Yang 
---

Changes in v2:
 - Add the patch to support the get_fmt ops.
 - Remove the redundant invoking ov7670_init_gpio().

 drivers/media/i2c/ov7670.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index efc738112e2a..d1211ae48f63 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1530,6 +1530,22 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
const struct v4l2_dbg_regis
 }
 #endif
 
+static int ov7670_s_power(struct v4l2_subdev *sd, int on)
+{
+   struct ov7670_info *info = to_state(sd);
+
+   if (info->pwdn_gpio)
+   gpiod_direction_output(info->pwdn_gpio, !on);
+   if (on && info->resetb_gpio) {
+   gpiod_set_value(info->resetb_gpio, 1);
+   usleep_range(500, 1000);
+   gpiod_set_value(info->resetb_gpio, 0);
+   usleep_range(3000, 5000);
+   }
+
+   return 0;
+}
+
 /* --- */
 
 static const struct v4l2_subdev_core_ops ov7670_core_ops = {
@@ -1539,6 +1555,7 @@ static const struct v4l2_subdev_core_ops ov7670_core_ops 
= {
.g_register = ov7670_g_register,
.s_register = ov7670_s_register,
 #endif
+   .s_power = ov7670_s_power,
 };
 
 static const struct v4l2_subdev_video_ops ov7670_video_ops = {
@@ -1645,23 +1662,25 @@ static int ov7670_probe(struct i2c_client *client,
if (ret)
return ret;
 
-   ret = ov7670_init_gpio(client, info);
-   if (ret)
-   goto clk_disable;
-
info->clock_speed = clk_get_rate(info->clk) / 100;
if (info->clock_speed < 10 || info->clock_speed > 48) {
ret = -EINVAL;
goto clk_disable;
}
 
+   ret = ov7670_init_gpio(client, info);
+   if (ret)
+   goto clk_disable;
+
+   ov7670_s_power(sd, 1);
+
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
v4l_dbg(1, debug, client,
"chip found @ 0x%x (%s) is not an ov7670 chip.\n",
client->addr << 1, client->adapter->name);
-   goto clk_disable;
+   goto power_off;
}
v4l_info(client, "chip found @ 0x%02x (%s)\n",
client->addr << 1, client->adapter->name);
@@ -1734,6 +1753,8 @@ static int ov7670_probe(struct i2c_client *client,
media_entity_cleanup(>sd.entity);
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
+power_off:
+   ov7670_s_power(sd, 0);
 clk_disable:
clk_disable_unprepare(info->clk);
return ret;
@@ -1749,6 +1770,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_ctrl_handler_free(>hdl);
clk_disable_unprepare(info->clk);
media_entity_cleanup(>sd.entity);
+   ov7670_s_power(sd, 0);
return 0;
 }
 
-- 
2.13.0

[PATCH v2 2/3] media: ov7670: Add the get_fmt callback

[Wenyou Yang]

Add the get_fmt callback, also enable V4L2_SUBDEV_FL_HAS_DEVNODE flag
to make this subdev has device node.

Signed-off-by: Wenyou Yang 
---

Changes in v2: None

 drivers/media/i2c/ov7670.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 5c8460ee65c3..efc738112e2a 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -230,6 +230,7 @@ struct ov7670_info {
struct v4l2_ctrl *saturation;
struct v4l2_ctrl *hue;
};
+   struct v4l2_mbus_framefmt format;
struct ov7670_format_struct *fmt;  /* Current format */
struct clk *clk;
struct gpio_desc *resetb_gpio;
@@ -973,6 +974,29 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
fmt->width = wsize->width;
fmt->height = wsize->height;
fmt->colorspace = ov7670_formats[index].colorspace;
+
+   info->format.code = fmt->code;
+   info->format.width = fmt->width;
+   info->format.height = fmt->height;
+   info->format.colorspace = fmt->colorspace;
+
+   return 0;
+}
+
+static int ov7670_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *format)
+{
+   struct ov7670_info *info = to_state(sd);
+   struct v4l2_mbus_framefmt *fmt;
+
+   if (format->which == V4L2_SUBDEV_FORMAT_TRY)
+   fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
+   else
+   fmt = >format;
+
+   format->format = *fmt;
+
return 0;
 }
 
@@ -1526,6 +1550,7 @@ static const struct v4l2_subdev_pad_ops ov7670_pad_ops = {
.enum_frame_interval = ov7670_enum_frame_interval,
.enum_frame_size = ov7670_enum_frame_size,
.enum_mbus_code = ov7670_enum_mbus_code,
+   .get_fmt = ov7670_get_fmt,
.set_fmt = ov7670_set_fmt,
 };
 
@@ -1698,6 +1723,7 @@ static int ov7670_probe(struct i2c_client *client,
 
v4l2_ctrl_handler_setup(>hdl);
 
+   info->sd.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
ret = v4l2_async_register_subdev(>sd);
if (ret < 0)
goto entity_cleanup;
-- 
2.13.0

[PATCH v2 2/3] media: ov7670: Add the get_fmt callback

[Wenyou Yang]

Add the get_fmt callback, also enable V4L2_SUBDEV_FL_HAS_DEVNODE flag
to make this subdev has device node.

Signed-off-by: Wenyou Yang 
---

Changes in v2: None

 drivers/media/i2c/ov7670.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 5c8460ee65c3..efc738112e2a 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -230,6 +230,7 @@ struct ov7670_info {
struct v4l2_ctrl *saturation;
struct v4l2_ctrl *hue;
};
+   struct v4l2_mbus_framefmt format;
struct ov7670_format_struct *fmt;  /* Current format */
struct clk *clk;
struct gpio_desc *resetb_gpio;
@@ -973,6 +974,29 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
fmt->width = wsize->width;
fmt->height = wsize->height;
fmt->colorspace = ov7670_formats[index].colorspace;
+
+   info->format.code = fmt->code;
+   info->format.width = fmt->width;
+   info->format.height = fmt->height;
+   info->format.colorspace = fmt->colorspace;
+
+   return 0;
+}
+
+static int ov7670_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *format)
+{
+   struct ov7670_info *info = to_state(sd);
+   struct v4l2_mbus_framefmt *fmt;
+
+   if (format->which == V4L2_SUBDEV_FORMAT_TRY)
+   fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
+   else
+   fmt = >format;
+
+   format->format = *fmt;
+
return 0;
 }
 
@@ -1526,6 +1550,7 @@ static const struct v4l2_subdev_pad_ops ov7670_pad_ops = {
.enum_frame_interval = ov7670_enum_frame_interval,
.enum_frame_size = ov7670_enum_frame_size,
.enum_mbus_code = ov7670_enum_mbus_code,
+   .get_fmt = ov7670_get_fmt,
.set_fmt = ov7670_set_fmt,
 };
 
@@ -1698,6 +1723,7 @@ static int ov7670_probe(struct i2c_client *client,
 
v4l2_ctrl_handler_setup(>hdl);
 
+   info->sd.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
ret = v4l2_async_register_subdev(>sd);
if (ret < 0)
goto entity_cleanup;
-- 
2.13.0

[PATCH v2 1/3] media: ov7670: Add entity pads initialization

[Wenyou Yang]

Add the media entity pads initialization.

Signed-off-by: Wenyou Yang 
---

Changes in v2: None

 drivers/media/i2c/ov7670.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e88549f0e704..5c8460ee65c3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -213,6 +213,7 @@ struct ov7670_devtype {
 struct ov7670_format_struct;  /* coming later */
 struct ov7670_info {
struct v4l2_subdev sd;
+   struct media_pad pad;
struct v4l2_ctrl_handler hdl;
struct {
/* gain cluster */
@@ -1688,14 +1689,23 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_auto_cluster(2, >auto_exposure,
   V4L2_EXPOSURE_MANUAL, false);
v4l2_ctrl_cluster(2, >saturation);
+
+   info->pad.flags = MEDIA_PAD_FL_SOURCE;
+   info->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+   ret = media_entity_pads_init(>sd.entity, 1, >pad);
+   if (ret < 0)
+   goto hdl_free;
+
v4l2_ctrl_handler_setup(>hdl);
 
ret = v4l2_async_register_subdev(>sd);
if (ret < 0)
-   goto hdl_free;
+   goto entity_cleanup;
 
return 0;
 
+entity_cleanup:
+   media_entity_cleanup(>sd.entity);
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
 clk_disable:
@@ -1712,6 +1722,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(>hdl);
clk_disable_unprepare(info->clk);
+   media_entity_cleanup(>sd.entity);
return 0;
 }
 
-- 
2.13.0

[PATCH v2 1/3] media: ov7670: Add entity pads initialization

[Wenyou Yang]

Add the media entity pads initialization.

Signed-off-by: Wenyou Yang 
---

Changes in v2: None

 drivers/media/i2c/ov7670.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e88549f0e704..5c8460ee65c3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -213,6 +213,7 @@ struct ov7670_devtype {
 struct ov7670_format_struct;  /* coming later */
 struct ov7670_info {
struct v4l2_subdev sd;
+   struct media_pad pad;
struct v4l2_ctrl_handler hdl;
struct {
/* gain cluster */
@@ -1688,14 +1689,23 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_auto_cluster(2, >auto_exposure,
   V4L2_EXPOSURE_MANUAL, false);
v4l2_ctrl_cluster(2, >saturation);
+
+   info->pad.flags = MEDIA_PAD_FL_SOURCE;
+   info->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+   ret = media_entity_pads_init(>sd.entity, 1, >pad);
+   if (ret < 0)
+   goto hdl_free;
+
v4l2_ctrl_handler_setup(>hdl);
 
ret = v4l2_async_register_subdev(>sd);
if (ret < 0)
-   goto hdl_free;
+   goto entity_cleanup;
 
return 0;
 
+entity_cleanup:
+   media_entity_cleanup(>sd.entity);
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
 clk_disable:
@@ -1712,6 +1722,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(>hdl);
clk_disable_unprepare(info->clk);
+   media_entity_cleanup(>sd.entity);
return 0;
 }
 
-- 
2.13.0

[PATCH v2 0/3] media: ov7670: Add entity init and power operation

[Wenyou Yang]

This patch set is to add the media entity pads initialization,
the s_power operation and get_fmt callback support.

Changes in v2:
 - Add the patch to support the get_fmt ops.
 - Remove the redundant invoking ov7670_init_gpio().

Wenyou Yang (3):
  media: ov7670: Add entity pads initialization
  media: ov7670: Add the get_fmt callback
  media: ov7670: Add the s_power operation

 drivers/media/i2c/ov7670.c | 71 ++
 1 file changed, 65 insertions(+), 6 deletions(-)

-- 
2.13.0

[PATCH v2 0/3] media: ov7670: Add entity init and power operation

[Wenyou Yang]

This patch set is to add the media entity pads initialization,
the s_power operation and get_fmt callback support.

Changes in v2:
 - Add the patch to support the get_fmt ops.
 - Remove the redundant invoking ov7670_init_gpio().

Wenyou Yang (3):
  media: ov7670: Add entity pads initialization
  media: ov7670: Add the get_fmt callback
  media: ov7670: Add the s_power operation

 drivers/media/i2c/ov7670.c | 71 ++
 1 file changed, 65 insertions(+), 6 deletions(-)

-- 
2.13.0

Re: [Outreachy kernel] Re: [PATCH v2 1/2] include: linux: sysfs: Add __ATTR_NAMED macro

[Julia Lawall]

On Wed, 13 Sep 2017, Joe Perches wrote:

> On Thu, 2017-09-14 at 00:43 +0300, Dan Carpenter wrote:
> > He was exagerating a bit to call it a "static checker" warning...
>
> Not really.
>
> False positives and false negatives exist in just about
> every static
> checker.
>
> > It's just checkpatch.pl complaining about adding spaces around the -
> > operator.
>
> checkpatch is a brain-damaged by design static checker.
> regexes can only be sensitive to patterns, not compiled code.
>
> > The sysfs file has a hyphen in the middle.
>
> Another option would be to use an underscore instead.

There are already underscores on either side.

julia

>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1505339903.8969.20.camel%40perches.com.
> For more options, visit https://groups.google.com/d/optout.
>

Re: [Outreachy kernel] Re: [PATCH v2 1/2] include: linux: sysfs: Add __ATTR_NAMED macro

[Julia Lawall]

On Wed, 13 Sep 2017, Joe Perches wrote:

> On Thu, 2017-09-14 at 00:43 +0300, Dan Carpenter wrote:
> > He was exagerating a bit to call it a "static checker" warning...
>
> Not really.
>
> False positives and false negatives exist in just about
> every static
> checker.
>
> > It's just checkpatch.pl complaining about adding spaces around the -
> > operator.
>
> checkpatch is a brain-damaged by design static checker.
> regexes can only be sensitive to patterns, not compiled code.
>
> > The sysfs file has a hyphen in the middle.
>
> Another option would be to use an underscore instead.

There are already underscores on either side.

julia

>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1505339903.8969.20.camel%40perches.com.
> For more options, visit https://groups.google.com/d/optout.
>

Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

[Sekhar Nori]

On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote:
> 
> 
> On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
>> During test transmitting using CAN-FD at high bitrates (4 Mbps) only
>> resulted in errors. Scoping the signals I noticed that only a single bit
>> was being transmitted and with a bit more investigation realized the actual
>> MCAN IP would go back to initialization mode automatically.
>>
>> It appears this issue is due to the MCAN needing to use the Transmitter
>> Delay Compensation Mode as defined in the MCAN User's Guide. When this
>> mode is used the User's Guide indicates that the Transmitter Delay
>> Compensation Offset register should be set. The document mentions that this
>> register should be set to (1/dbitrate)/2*(Func Clk Freq).
>>
>> Additional CAN-CIA's "Bit Time Requirements for CAN FD" document indicates
>> that this TDC mode is only needed for data bit rates above 2.5 Mbps.
>> Therefore, only enable this mode and only set TDCO when the data bit rate
>> is above 2.5 Mbps.
>>
>> Signed-off-by: Franklin S Cooper Jr 
>> ---
>> I'm pretty surprised that this hasn't been implemented already since
>> the primary purpose of CAN-FD is to go beyond 1 Mbps and the MCAN IP
>> supports up to 10 Mbps.
>>
>> So it will be nice to get comments from users of this driver to understand
>> if they have been able to use CAN-FD beyond 2.5 Mbps without this patch.
>> If they haven't what did they do to get around it if they needed higher
>> speeds.
>>
>> Meanwhile I plan on testing this using a more "realistic" CAN bus to insure
>> everything still works at 5 Mbps which is the max speed of my CAN
>> transceiver.
> 
> ping. Anyone has any thoughts on this?

I added Dong who authored the m_can driver and Wenyou who added the only
in-kernel user of the driver for any help.

Thanks,
Sekhar

>>
>>  drivers/net/can/m_can/m_can.c | 24 +++-
>>  1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>> index f4947a7..720e073 100644
>> --- a/drivers/net/can/m_can/m_can.c
>> +++ b/drivers/net/can/m_can/m_can.c
>> @@ -126,6 +126,12 @@ enum m_can_mram_cfg {
>>  #define DBTP_DSJW_SHIFT 0
>>  #define DBTP_DSJW_MASK  (0xf << DBTP_DSJW_SHIFT)
>>  
>> +/* Transmitter Delay Compensation Register (TDCR) */
>> +#define TDCR_TDCO_SHIFT 8
>> +#define TDCR_TDCO_MASK  (0x7F << TDCR_TDCO_SHIFT)
>> +#define TDCR_TDCF_SHIFT 0
>> +#define TDCR_TDCF_MASK  (0x7F << TDCR_TDCO_SHIFT)
>> +
>>  /* Test Register (TEST) */
>>  #define TEST_LBCK   BIT(4)
>>  
>> @@ -977,6 +983,8 @@ static int m_can_set_bittiming(struct net_device *dev)
>>  const struct can_bittiming *dbt = >can.data_bittiming;
>>  u16 brp, sjw, tseg1, tseg2;
>>  u32 reg_btp;
>> +u32 enable_tdc = 0;
>> +u32 tdco;
>>  
>>  brp = bt->brp - 1;
>>  sjw = bt->sjw - 1;
>> @@ -991,9 +999,23 @@ static int m_can_set_bittiming(struct net_device *dev)
>>  sjw = dbt->sjw - 1;
>>  tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
>>  tseg2 = dbt->phase_seg2 - 1;
>> +
>> +/* TDC is only needed for bitrates beyond 2.5 MBit/s
>> + * Specified in the "Bit Time Requirements for CAN FD" document
>> + */
>> +if (dbt->bitrate > 250) {
>> +enable_tdc = DBTP_TDC;
>> +/* Equation based on Bosch's M_CAN User Manual's
>> + * Transmitter Delay Compensation Section
>> + */
>> +tdco = priv->can.clock.freq / (dbt->bitrate * 2);
>> +m_can_write(priv, M_CAN_TDCR, tdco << TDCR_TDCO_SHIFT);
>> +}
>> +
>>  reg_btp = (brp << DBTP_DBRP_SHIFT) | (sjw << DBTP_DSJW_SHIFT) |
>>  (tseg1 << DBTP_DTSEG1_SHIFT) |
>> -(tseg2 << DBTP_DTSEG2_SHIFT);
>> +(tseg2 << DBTP_DTSEG2_SHIFT) | enable_tdc;
>> +
>>  m_can_write(priv, M_CAN_DBTP, reg_btp);
>>  }
>>  
>>

Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

[Sekhar Nori]

On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote:
> 
> 
> On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
>> During test transmitting using CAN-FD at high bitrates (4 Mbps) only
>> resulted in errors. Scoping the signals I noticed that only a single bit
>> was being transmitted and with a bit more investigation realized the actual
>> MCAN IP would go back to initialization mode automatically.
>>
>> It appears this issue is due to the MCAN needing to use the Transmitter
>> Delay Compensation Mode as defined in the MCAN User's Guide. When this
>> mode is used the User's Guide indicates that the Transmitter Delay
>> Compensation Offset register should be set. The document mentions that this
>> register should be set to (1/dbitrate)/2*(Func Clk Freq).
>>
>> Additional CAN-CIA's "Bit Time Requirements for CAN FD" document indicates
>> that this TDC mode is only needed for data bit rates above 2.5 Mbps.
>> Therefore, only enable this mode and only set TDCO when the data bit rate
>> is above 2.5 Mbps.
>>
>> Signed-off-by: Franklin S Cooper Jr 
>> ---
>> I'm pretty surprised that this hasn't been implemented already since
>> the primary purpose of CAN-FD is to go beyond 1 Mbps and the MCAN IP
>> supports up to 10 Mbps.
>>
>> So it will be nice to get comments from users of this driver to understand
>> if they have been able to use CAN-FD beyond 2.5 Mbps without this patch.
>> If they haven't what did they do to get around it if they needed higher
>> speeds.
>>
>> Meanwhile I plan on testing this using a more "realistic" CAN bus to insure
>> everything still works at 5 Mbps which is the max speed of my CAN
>> transceiver.
> 
> ping. Anyone has any thoughts on this?

I added Dong who authored the m_can driver and Wenyou who added the only
in-kernel user of the driver for any help.

Thanks,
Sekhar

>>
>>  drivers/net/can/m_can/m_can.c | 24 +++-
>>  1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>> index f4947a7..720e073 100644
>> --- a/drivers/net/can/m_can/m_can.c
>> +++ b/drivers/net/can/m_can/m_can.c
>> @@ -126,6 +126,12 @@ enum m_can_mram_cfg {
>>  #define DBTP_DSJW_SHIFT 0
>>  #define DBTP_DSJW_MASK  (0xf << DBTP_DSJW_SHIFT)
>>  
>> +/* Transmitter Delay Compensation Register (TDCR) */
>> +#define TDCR_TDCO_SHIFT 8
>> +#define TDCR_TDCO_MASK  (0x7F << TDCR_TDCO_SHIFT)
>> +#define TDCR_TDCF_SHIFT 0
>> +#define TDCR_TDCF_MASK  (0x7F << TDCR_TDCO_SHIFT)
>> +
>>  /* Test Register (TEST) */
>>  #define TEST_LBCK   BIT(4)
>>  
>> @@ -977,6 +983,8 @@ static int m_can_set_bittiming(struct net_device *dev)
>>  const struct can_bittiming *dbt = >can.data_bittiming;
>>  u16 brp, sjw, tseg1, tseg2;
>>  u32 reg_btp;
>> +u32 enable_tdc = 0;
>> +u32 tdco;
>>  
>>  brp = bt->brp - 1;
>>  sjw = bt->sjw - 1;
>> @@ -991,9 +999,23 @@ static int m_can_set_bittiming(struct net_device *dev)
>>  sjw = dbt->sjw - 1;
>>  tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
>>  tseg2 = dbt->phase_seg2 - 1;
>> +
>> +/* TDC is only needed for bitrates beyond 2.5 MBit/s
>> + * Specified in the "Bit Time Requirements for CAN FD" document
>> + */
>> +if (dbt->bitrate > 250) {
>> +enable_tdc = DBTP_TDC;
>> +/* Equation based on Bosch's M_CAN User Manual's
>> + * Transmitter Delay Compensation Section
>> + */
>> +tdco = priv->can.clock.freq / (dbt->bitrate * 2);
>> +m_can_write(priv, M_CAN_TDCR, tdco << TDCR_TDCO_SHIFT);
>> +}
>> +
>>  reg_btp = (brp << DBTP_DBRP_SHIFT) | (sjw << DBTP_DSJW_SHIFT) |
>>  (tseg1 << DBTP_DTSEG1_SHIFT) |
>> -(tseg2 << DBTP_DTSEG2_SHIFT);
>> +(tseg2 << DBTP_DTSEG2_SHIFT) | enable_tdc;
>> +
>>  m_can_write(priv, M_CAN_DBTP, reg_btp);
>>  }
>>  
>>

[PATCH] staging: irda: Remove typedef struct

[Haneen Mohammed]

This patch remove typedef from a structure with all its ocurrences
since using typedefs for structures is discouraged.
Issue found using Coccinelle:

@r1@
type T;
@@

typedef struct { ... } T;

@script:python c1@
T2;
T << r1.T;
@@
if T[-2:] =="_t" or T[-2:] == "_T":
coccinelle.T2 = T[:-2];
else:
coccinelle.T2 = T;

print T, coccinelle.T2

@r2@
type r1.T;
identifier c1.T2;
@@
-typedef
struct
+ T2
{ ... }
-T
;

@r3@
type r1.T;
identifier c1.T2;
@@
-T
+struct T2

Signed-off-by: Haneen Mohammed 
---
 drivers/staging/irda/include/net/irda/qos.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/irda/include/net/irda/qos.h 
b/drivers/staging/irda/include/net/irda/qos.h
index 05a5a24..a0315b5 100644
--- a/drivers/staging/irda/include/net/irda/qos.h
+++ b/drivers/staging/irda/include/net/irda/qos.h
@@ -58,23 +58,23 @@
 #define IR_1600 0x02
 
 /* Quality of Service information */
-typedef struct {
+struct qos_value {
__u32 value;
__u16 bits; /* LSB is first byte, MSB is second byte */
-} qos_value_t;
+};
 
 struct qos_info {
magic_t magic;
 
-   qos_value_t baud_rate;   /* IR_11520O | ... */
-   qos_value_t max_turn_time;
-   qos_value_t data_size;
-   qos_value_t window_size;
-   qos_value_t additional_bofs;
-   qos_value_t min_turn_time;
-   qos_value_t link_disc_time;
+   struct qos_value baud_rate;   /* IR_11520O | ... */
+   struct qos_value max_turn_time;
+   struct qos_value data_size;
+   struct qos_value window_size;
+   struct qos_value additional_bofs;
+   struct qos_value min_turn_time;
+   struct qos_value link_disc_time;

-   qos_value_t power;
+   struct qos_value power;
 };
 
 extern int sysctl_max_baud_rate;
-- 
2.7.4

[PATCH] staging: irda: Remove typedef struct

[Haneen Mohammed]

This patch remove typedef from a structure with all its ocurrences
since using typedefs for structures is discouraged.
Issue found using Coccinelle:

@r1@
type T;
@@

typedef struct { ... } T;

@script:python c1@
T2;
T << r1.T;
@@
if T[-2:] =="_t" or T[-2:] == "_T":
coccinelle.T2 = T[:-2];
else:
coccinelle.T2 = T;

print T, coccinelle.T2

@r2@
type r1.T;
identifier c1.T2;
@@
-typedef
struct
+ T2
{ ... }
-T
;

@r3@
type r1.T;
identifier c1.T2;
@@
-T
+struct T2

Signed-off-by: Haneen Mohammed 
---
 drivers/staging/irda/include/net/irda/qos.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/irda/include/net/irda/qos.h 
b/drivers/staging/irda/include/net/irda/qos.h
index 05a5a24..a0315b5 100644
--- a/drivers/staging/irda/include/net/irda/qos.h
+++ b/drivers/staging/irda/include/net/irda/qos.h
@@ -58,23 +58,23 @@
 #define IR_1600 0x02
 
 /* Quality of Service information */
-typedef struct {
+struct qos_value {
__u32 value;
__u16 bits; /* LSB is first byte, MSB is second byte */
-} qos_value_t;
+};
 
 struct qos_info {
magic_t magic;
 
-   qos_value_t baud_rate;   /* IR_11520O | ... */
-   qos_value_t max_turn_time;
-   qos_value_t data_size;
-   qos_value_t window_size;
-   qos_value_t additional_bofs;
-   qos_value_t min_turn_time;
-   qos_value_t link_disc_time;
+   struct qos_value baud_rate;   /* IR_11520O | ... */
+   struct qos_value max_turn_time;
+   struct qos_value data_size;
+   struct qos_value window_size;
+   struct qos_value additional_bofs;
+   struct qos_value min_turn_time;
+   struct qos_value link_disc_time;

-   qos_value_t power;
+   struct qos_value power;
 };
 
 extern int sysctl_max_baud_rate;
-- 
2.7.4

Re: [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation

[Allen]

> I think the changelog for this series of conversions
> should show that you've validated the change by
> inspecting the return call chain at each modified line.
>
> Also, it seems you've cc'd the same mailing lists for
> all of the patches modified by this series.
>
> It would be better to individually address each patch
> in the series only cc'ing the appropriate maintainers
> and mailing lists.
>
> A cover letter would be good too.

 Point noted. Thanks.

- Allen

Re: [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation

[Allen]

> I think the changelog for this series of conversions
> should show that you've validated the change by
> inspecting the return call chain at each modified line.
>
> Also, it seems you've cc'd the same mailing lists for
> all of the patches modified by this series.
>
> It would be better to individually address each patch
> in the series only cc'ing the appropriate maintainers
> and mailing lists.
>
> A cover letter would be good too.

 Point noted. Thanks.

- Allen

[PATCH] Input: add support for HiDeep touchscreen

[Anthony Kim]

The HiDeep touchscreen device is a capacitive multi-touch controller
mainly for multi-touch supported devices use. It use I2C interface for
communication to IC and provide axis X, Y, Z locations for ten finger
touch through input event interface to userspace.

It support the Crimson and the Lime two type IC. They are different
the number of channel supported and FW size. But the working protocol
is same.

Signed-off-by: Anthony Kim 
---
 .../bindings/input/touchscreen/hideep.txt  |   42 +
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/input/touchscreen/Kconfig  |   11 +
 drivers/input/touchscreen/Makefile |1 +
 drivers/input/touchscreen/hideep.c | 1274 
 5 files changed, 1329 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/hideep.txt
 create mode 100644 drivers/input/touchscreen/hideep.c

diff --git a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt 
b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
new file mode 100644
index 000..86b3a97
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
@@ -0,0 +1,42 @@
+* HiDeep Finger and Stylus touchscreen controller
+
+Required properties:
+- compatible   : must be "hideep,hideep-ts"
+- reg  : I2C slave address, (e.g. 0x6C).
+- interrupt-parent : Interrupt controller to which the chip is connected.
+- interrupts : Interrupt to which the chip is connected.
+
+Optional properties:
+- vdd-supply   : It is the controller supply for controlling
+main voltage(3.3V) through the 
regulator.
+- vid-supply   : It is the controller supply for controlling
+   IO voltage(1.8V) through the regulator.
+- reset-gpios  : Define for reset gpio pin.
+   It is to use for reset IC.
+- touchscreen-size-x   : X axis size of touchscreen
+- touchscreen-size-y   : Y axis size of touchscreen
+- linux,keycodes   : Specifies an array of numeric keycode values to
+   be used for reporting button presses. The array can
+   contain up to 3 entries.
+
+Example:
+
+#include "dt-bindings/input/input.h"
+
+i2c@ {
+
+   /* ... */
+
+   touchscreen@6c {
+   compatible = "hideep,hideep-ts";
+   reg = <0x6c>;
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+   vdd-supply = <_reg>";
+   vid-supply = <_reg>;
+   reset-gpios = < 5 0>;
+   touchscreen-size-x = 1079;
+   touchscreen-size-y = 1919;
+   linux,keycodes = , , ;
+   };
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c03d201..aa2a301 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -131,6 +131,7 @@ gw  Gateworks Corporation
 hannstar   HannStar Display Corporation
 haoyu  Haoyu Microelectronic Co. Ltd.
 hardkernel Hardkernel Co., Ltd
+hideep HiDeep Inc.
 himax  Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 64b30fe..d0c8dafc 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -344,6 +344,17 @@ config TOUCHSCREEN_GOODIX
  To compile this driver as a module, choose M here: the
  module will be called goodix.
 
+config TOUCHSCREEN_HIDEEP
+   tristate "HiDeep Touch IC"
+   depends on I2C
+   help
+ Say Y here if you have a touchscreen using HiDeep.
+
+ If unsure, say N.
+
+ To compile this driver as a moudle, choose M here : the
+ module will be called hideep_ts.
+
 config TOUCHSCREEN_ILI210X
tristate "Ilitek ILI210X based touchscreen"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 6badce8..873b67e 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX)  += egalax_ts.o
 obj-$(CONFIG_TOUCHSCREEN_EGALAX_SERIAL)+= egalax_ts_serial.o
 obj-$(CONFIG_TOUCHSCREEN_FUJITSU)  += fujitsu_ts.o
 obj-$(CONFIG_TOUCHSCREEN_GOODIX)   += goodix.o
+obj-$(CONFIG_TOUCHSCREEN_HIDEEP)   += hideep.o
 obj-$(CONFIG_TOUCHSCREEN_ILI210X)  += ili210x.o
 obj-$(CONFIG_TOUCHSCREEN_IMX6UL_TSC)   += imx6ul_tsc.o
 obj-$(CONFIG_TOUCHSCREEN_INEXIO)   += inexio.o
diff --git a/drivers/input/touchscreen/hideep.c 
b/drivers/input/touchscreen/hideep.c
new file mode 100644
index 000..f1b021b
--- /dev/null
+++ b/drivers/input/touchscreen/hideep.c

[PATCH] Input: add support for HiDeep touchscreen

[Anthony Kim]

The HiDeep touchscreen device is a capacitive multi-touch controller
mainly for multi-touch supported devices use. It use I2C interface for
communication to IC and provide axis X, Y, Z locations for ten finger
touch through input event interface to userspace.

It support the Crimson and the Lime two type IC. They are different
the number of channel supported and FW size. But the working protocol
is same.

Signed-off-by: Anthony Kim 
---
 .../bindings/input/touchscreen/hideep.txt  |   42 +
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/input/touchscreen/Kconfig  |   11 +
 drivers/input/touchscreen/Makefile |1 +
 drivers/input/touchscreen/hideep.c | 1274 
 5 files changed, 1329 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/hideep.txt
 create mode 100644 drivers/input/touchscreen/hideep.c

diff --git a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt 
b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
new file mode 100644
index 000..86b3a97
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
@@ -0,0 +1,42 @@
+* HiDeep Finger and Stylus touchscreen controller
+
+Required properties:
+- compatible   : must be "hideep,hideep-ts"
+- reg  : I2C slave address, (e.g. 0x6C).
+- interrupt-parent : Interrupt controller to which the chip is connected.
+- interrupts : Interrupt to which the chip is connected.
+
+Optional properties:
+- vdd-supply   : It is the controller supply for controlling
+main voltage(3.3V) through the 
regulator.
+- vid-supply   : It is the controller supply for controlling
+   IO voltage(1.8V) through the regulator.
+- reset-gpios  : Define for reset gpio pin.
+   It is to use for reset IC.
+- touchscreen-size-x   : X axis size of touchscreen
+- touchscreen-size-y   : Y axis size of touchscreen
+- linux,keycodes   : Specifies an array of numeric keycode values to
+   be used for reporting button presses. The array can
+   contain up to 3 entries.
+
+Example:
+
+#include "dt-bindings/input/input.h"
+
+i2c@ {
+
+   /* ... */
+
+   touchscreen@6c {
+   compatible = "hideep,hideep-ts";
+   reg = <0x6c>;
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+   vdd-supply = <_reg>";
+   vid-supply = <_reg>;
+   reset-gpios = < 5 0>;
+   touchscreen-size-x = 1079;
+   touchscreen-size-y = 1919;
+   linux,keycodes = , , ;
+   };
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c03d201..aa2a301 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -131,6 +131,7 @@ gw  Gateworks Corporation
 hannstar   HannStar Display Corporation
 haoyu  Haoyu Microelectronic Co. Ltd.
 hardkernel Hardkernel Co., Ltd
+hideep HiDeep Inc.
 himax  Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 64b30fe..d0c8dafc 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -344,6 +344,17 @@ config TOUCHSCREEN_GOODIX
  To compile this driver as a module, choose M here: the
  module will be called goodix.
 
+config TOUCHSCREEN_HIDEEP
+   tristate "HiDeep Touch IC"
+   depends on I2C
+   help
+ Say Y here if you have a touchscreen using HiDeep.
+
+ If unsure, say N.
+
+ To compile this driver as a moudle, choose M here : the
+ module will be called hideep_ts.
+
 config TOUCHSCREEN_ILI210X
tristate "Ilitek ILI210X based touchscreen"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 6badce8..873b67e 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX)  += egalax_ts.o
 obj-$(CONFIG_TOUCHSCREEN_EGALAX_SERIAL)+= egalax_ts_serial.o
 obj-$(CONFIG_TOUCHSCREEN_FUJITSU)  += fujitsu_ts.o
 obj-$(CONFIG_TOUCHSCREEN_GOODIX)   += goodix.o
+obj-$(CONFIG_TOUCHSCREEN_HIDEEP)   += hideep.o
 obj-$(CONFIG_TOUCHSCREEN_ILI210X)  += ili210x.o
 obj-$(CONFIG_TOUCHSCREEN_IMX6UL_TSC)   += imx6ul_tsc.o
 obj-$(CONFIG_TOUCHSCREEN_INEXIO)   += inexio.o
diff --git a/drivers/input/touchscreen/hideep.c 
b/drivers/input/touchscreen/hideep.c
new file mode 100644
index 000..f1b021b
--- /dev/null
+++ b/drivers/input/touchscreen/hideep.c
@@ -0,0 +1,1274 @@
+/*
+ 

[lkp-robot] [kprobes] e1ce3eee7d: BUG:using_smp_processor_id()in_preemptible

[kernel test robot]

FYI, we noticed the following commit:

commit: e1ce3eee7dcda03f2b2f2d64e2cb2f3a993a3b34 ("kprobes: Use 
synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT")
url: 
https://github.com/0day-ci/linux/commits/Masami-Hiramatsu/kprobes-Use-synchronize_rcu_tasks-for-optprobe-with-CONFIG_PREEMPT/20170913-034557


in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 2 
-m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


++++
|| 80cee03bf1 | e1ce3eee7d |
++++
| boot_successes | 28 | 5  |
| boot_failures  | 0  | 23 |
| BUG:using_smp_processor_id()in_preemptible | 0  | 23 |
++++



[   14.675660] BUG: using smp_processor_id() in preemptible [] code: 
swapper/0/1
[   14.700932] caller is debug_smp_processor_id+0x17/0x20
[   14.725623] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0-06467-ge1ce3ee 
#2
[   14.729560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   14.772244] Call Trace:
[   14.772244]  dump_stack+0x65/0x87
[   14.772244]  check_preemption_disabled+0xda/0xe0
[   14.772244]  debug_smp_processor_id+0x17/0x20
[   14.772244]  optimized_callback+0x1f/0xf0
[   14.772244]  0xa0002370
[   14.772244]  ? init_test_probes+0x2cf/0x530
[   14.772244]  init_kprobes+0x1e6/0x1f1
[   14.772244]  ? debugfs_kprobe_init+0xa5/0xa5
[   14.772244]  do_one_initcall+0x4e/0x190
[   14.772244]  kernel_init_freeable+0x113/0x194
[   14.772244]  ? rest_init+0x130/0x130
[   14.772244]  kernel_init+0x9/0xf2
[   14.772244]  ret_from_fork+0x25/0x30
[   16.007679] Kprobe smoke test: passed successfully
[   16.025466] Initialise system trusted keyrings
[   16.062596] workingset: timestamp_bits=46 max_order=17 bucket_order=0
[   16.151965] efs: 1.0a - http://aeschi.ch.eu.org/efs/
[   16.164959] fuse init (API version 7.26)
[   16.183177] orangefs_debugfs_init: called with debug mask: :none: :0:
[   16.196644] orangefs_init: module version upstream loaded
[   16.209245] NILFS version 2 loaded
[   16.226230] gfs2: GFS2 installed
[   16.326266] NET: Registered protocol family 38
[   16.344018] Key type asymmetric registered
[   16.353442] Asymmetric key parser 'x509' registered
[   16.364981] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
249)
[   16.382476] io scheduler noop registered
[   16.392812] io scheduler cfq registered (default)
[   16.405978] test_printf: all 260 tests passed
[   16.432644] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[   16.443171] crc32: self tests passed, processed 225944 bytes in 2307458 nsec
[   16.456977] crc32c: CRC_LE_BITS = 64
[   16.464432] crc32c: self tests passed, processed 225944 bytes in 620214 nsec
[   16.636881] crc32_combine: 8373 self tests passed
[   16.770158] crc32c_combine: 8373 self tests passed
[   16.784290] switchtec: loaded.
[   16.791607] rivafb_setup START
[   16.801335] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[   16.817701] ACPI: Power Button [PWRF]
[   16.848025] HDLC line discipline maxframe=4096
[   16.859952] N_HDLC line discipline registered.
[   16.874756] r3964: Philips r3964 Driver $Revision: 1.10 $
[   16.886652] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[   16.983539] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 
16550A
[   17.114800] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 
16550A
[   17.138674] MOXA Intellio family driver version 6.0k
[   17.151640] SyncLink serial driver $Revision: 4.38 $
[   17.232501] SyncLink serial driver $Revision: 4.38 $, tty major#244
[   17.248116] Non-volatile memory driver v1.3
[   17.258912] telclk_interrupt = 0xf non-mcpbl0010 hw.
[   17.304320] Floppy drive(s): fd0 is 2.88M AMI BIOS
[   17.309997] loop: module loaded
[   17.344349] null: module loaded
[   17.352804] dummy-irq: no IRQ given.  Use irq=N
[   17.365157] Silicon Labs C2 port support v. 0.51.0 - (C) 2007 Rodolfo 
Giometti
[   17.381691] FDC 0 is a S82078B
[   17.395387] c2port c2port0: C2 port uc added
[   17.405402] c2port c2port0: uc flash has 30 blocks x 512 bytes (15360 bytes 
total)
[   17.425464] Uniform Multi-Platform E-IDE driver
[   17.437073] Loading iSCSI transport class v2.0-870.
[   17.455730] aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loaded
[   17.478968] iscsi: registered transport (qla4xxx)
[   17.492261] QLogic iSCSI HBA Driver
[   17.502789] mpt3sas version 15.100.00.00 loaded
[   17.516825] VMware PVSCSI driver - version 1.0.7.0-k
[   17.568251] scsi host0: scsi_debug: version 1.86 [20160430]
[   17.568251]   dev_size_mb=8

[lkp-robot] [kprobes] e1ce3eee7d: BUG:using_smp_processor_id()in_preemptible

[kernel test robot]

FYI, we noticed the following commit:

commit: e1ce3eee7dcda03f2b2f2d64e2cb2f3a993a3b34 ("kprobes: Use 
synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT")
url: 
https://github.com/0day-ci/linux/commits/Masami-Hiramatsu/kprobes-Use-synchronize_rcu_tasks-for-optprobe-with-CONFIG_PREEMPT/20170913-034557


in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 2 
-m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


++++
|| 80cee03bf1 | e1ce3eee7d |
++++
| boot_successes | 28 | 5  |
| boot_failures  | 0  | 23 |
| BUG:using_smp_processor_id()in_preemptible | 0  | 23 |
++++



[   14.675660] BUG: using smp_processor_id() in preemptible [] code: 
swapper/0/1
[   14.700932] caller is debug_smp_processor_id+0x17/0x20
[   14.725623] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0-06467-ge1ce3ee 
#2
[   14.729560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   14.772244] Call Trace:
[   14.772244]  dump_stack+0x65/0x87
[   14.772244]  check_preemption_disabled+0xda/0xe0
[   14.772244]  debug_smp_processor_id+0x17/0x20
[   14.772244]  optimized_callback+0x1f/0xf0
[   14.772244]  0xa0002370
[   14.772244]  ? init_test_probes+0x2cf/0x530
[   14.772244]  init_kprobes+0x1e6/0x1f1
[   14.772244]  ? debugfs_kprobe_init+0xa5/0xa5
[   14.772244]  do_one_initcall+0x4e/0x190
[   14.772244]  kernel_init_freeable+0x113/0x194
[   14.772244]  ? rest_init+0x130/0x130
[   14.772244]  kernel_init+0x9/0xf2
[   14.772244]  ret_from_fork+0x25/0x30
[   16.007679] Kprobe smoke test: passed successfully
[   16.025466] Initialise system trusted keyrings
[   16.062596] workingset: timestamp_bits=46 max_order=17 bucket_order=0
[   16.151965] efs: 1.0a - http://aeschi.ch.eu.org/efs/
[   16.164959] fuse init (API version 7.26)
[   16.183177] orangefs_debugfs_init: called with debug mask: :none: :0:
[   16.196644] orangefs_init: module version upstream loaded
[   16.209245] NILFS version 2 loaded
[   16.226230] gfs2: GFS2 installed
[   16.326266] NET: Registered protocol family 38
[   16.344018] Key type asymmetric registered
[   16.353442] Asymmetric key parser 'x509' registered
[   16.364981] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
249)
[   16.382476] io scheduler noop registered
[   16.392812] io scheduler cfq registered (default)
[   16.405978] test_printf: all 260 tests passed
[   16.432644] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[   16.443171] crc32: self tests passed, processed 225944 bytes in 2307458 nsec
[   16.456977] crc32c: CRC_LE_BITS = 64
[   16.464432] crc32c: self tests passed, processed 225944 bytes in 620214 nsec
[   16.636881] crc32_combine: 8373 self tests passed
[   16.770158] crc32c_combine: 8373 self tests passed
[   16.784290] switchtec: loaded.
[   16.791607] rivafb_setup START
[   16.801335] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[   16.817701] ACPI: Power Button [PWRF]
[   16.848025] HDLC line discipline maxframe=4096
[   16.859952] N_HDLC line discipline registered.
[   16.874756] r3964: Philips r3964 Driver $Revision: 1.10 $
[   16.886652] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[   16.983539] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 
16550A
[   17.114800] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 
16550A
[   17.138674] MOXA Intellio family driver version 6.0k
[   17.151640] SyncLink serial driver $Revision: 4.38 $
[   17.232501] SyncLink serial driver $Revision: 4.38 $, tty major#244
[   17.248116] Non-volatile memory driver v1.3
[   17.258912] telclk_interrupt = 0xf non-mcpbl0010 hw.
[   17.304320] Floppy drive(s): fd0 is 2.88M AMI BIOS
[   17.309997] loop: module loaded
[   17.344349] null: module loaded
[   17.352804] dummy-irq: no IRQ given.  Use irq=N
[   17.365157] Silicon Labs C2 port support v. 0.51.0 - (C) 2007 Rodolfo 
Giometti
[   17.381691] FDC 0 is a S82078B
[   17.395387] c2port c2port0: C2 port uc added
[   17.405402] c2port c2port0: uc flash has 30 blocks x 512 bytes (15360 bytes 
total)
[   17.425464] Uniform Multi-Platform E-IDE driver
[   17.437073] Loading iSCSI transport class v2.0-870.
[   17.455730] aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loaded
[   17.478968] iscsi: registered transport (qla4xxx)
[   17.492261] QLogic iSCSI HBA Driver
[   17.502789] mpt3sas version 15.100.00.00 loaded
[   17.516825] VMware PVSCSI driver - version 1.0.7.0-k
[   17.568251] scsi host0: scsi_debug: version 1.86 [20160430]
[   17.568251]   dev_size_mb=8

Re: [RESEND][PATCH] kvm: x86: Do not handle MMIO request in fast_page_fault

[Du, Changbin]

On Wed, Sep 13, 2017 at 04:39:56PM +0200, Radim Krčmář wrote:
> 2017-09-05 18:37+0800, changbin...@intel.com:
> > From: Changbin Du 
> > 
> > If it is a MMIO request, it should be handled by slow path. This patch
> > actually fixed below warning when mmu debug is enabled.
> > 
> > WARNING: CPU: 5 PID: 2282 at arch/x86/kvm/mmu.c:226 
> > fast_page_fault+0x41b/0x520
> > CPU: 5 PID: 2282 Comm: qemu-system-x86 Not tainted 4.13.0-rc6+ #34
> > task: 9b47f5286000 task.stack: b18d03b28000
> > RIP: 0010:fast_page_fault+0x41b/0x520
> > Call Trace:
> >   tdp_page_fault+0xfb/0x290
> >   kvm_mmu_page_fault+0x61/0x120
> >   handle_ept_misconfig+0x1ba/0x1c0
> >   vmx_handle_exit+0xb8/0xd70
> >   ? kvm_arch_vcpu_ioctl_run+0x9b6/0x18e0
> >   kvm_arch_vcpu_ioctl_run+0xa5a/0x18e0
> >   ? kvm_arch_vcpu_load+0x62/0x230
> >   kvm_vcpu_ioctl+0x340/0x6c0
> >   ? kvm_vcpu_ioctl+0x340/0x6c0
> >   ? lock_acquire+0xf5/0x1f0
> >   do_vfs_ioctl+0xa2/0x670
> >   ? __fget+0x107/0x200
> >   SyS_ioctl+0x79/0x90
> >   entry_SYSCALL_64_fastpath+0x23/0xc2
> > 
> > Signed-off-by: Changbin Du 
> > ---
> >  arch/x86/kvm/mmu.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index 9d3f275..63c3360 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -3180,6 +3180,9 @@ static bool fast_page_fault(struct kvm_vcpu *vcpu, 
> > gva_t gva, int level,
> > iterator.level < level)
> > break;
> >  
> > +   if (is_mmio_spte(spte))
> > +   break;
> 
> Hm, handle_ept_misconfig() calls kvm_mmu_page_fault with error_code =
> PFERR_RSVD_MASK.  This error_code gets propagated and checked at the
> beginning of page_fault_can_be_fast(), where it should break the
> function execution.
> 
> How did the execution get all the way to the loop?
> 
hmm, a recent Paolo's cleanup patch already fixed it.
e08d26f ("KVM: x86: simplify ept_misconfig")

In the past, PFERR_RSVD_MASK is not set.

So this patch doesnt need any more. thanks.

> Thanks.

-- 
Thanks,
Changbin Du


signature.asc
Description: PGP signature

Re: [RESEND][PATCH] kvm: x86: Do not handle MMIO request in fast_page_fault

[Du, Changbin]

On Wed, Sep 13, 2017 at 04:39:56PM +0200, Radim Krčmář wrote:
> 2017-09-05 18:37+0800, changbin...@intel.com:
> > From: Changbin Du 
> > 
> > If it is a MMIO request, it should be handled by slow path. This patch
> > actually fixed below warning when mmu debug is enabled.
> > 
> > WARNING: CPU: 5 PID: 2282 at arch/x86/kvm/mmu.c:226 
> > fast_page_fault+0x41b/0x520
> > CPU: 5 PID: 2282 Comm: qemu-system-x86 Not tainted 4.13.0-rc6+ #34
> > task: 9b47f5286000 task.stack: b18d03b28000
> > RIP: 0010:fast_page_fault+0x41b/0x520
> > Call Trace:
> >   tdp_page_fault+0xfb/0x290
> >   kvm_mmu_page_fault+0x61/0x120
> >   handle_ept_misconfig+0x1ba/0x1c0
> >   vmx_handle_exit+0xb8/0xd70
> >   ? kvm_arch_vcpu_ioctl_run+0x9b6/0x18e0
> >   kvm_arch_vcpu_ioctl_run+0xa5a/0x18e0
> >   ? kvm_arch_vcpu_load+0x62/0x230
> >   kvm_vcpu_ioctl+0x340/0x6c0
> >   ? kvm_vcpu_ioctl+0x340/0x6c0
> >   ? lock_acquire+0xf5/0x1f0
> >   do_vfs_ioctl+0xa2/0x670
> >   ? __fget+0x107/0x200
> >   SyS_ioctl+0x79/0x90
> >   entry_SYSCALL_64_fastpath+0x23/0xc2
> > 
> > Signed-off-by: Changbin Du 
> > ---
> >  arch/x86/kvm/mmu.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index 9d3f275..63c3360 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -3180,6 +3180,9 @@ static bool fast_page_fault(struct kvm_vcpu *vcpu, 
> > gva_t gva, int level,
> > iterator.level < level)
> > break;
> >  
> > +   if (is_mmio_spte(spte))
> > +   break;
> 
> Hm, handle_ept_misconfig() calls kvm_mmu_page_fault with error_code =
> PFERR_RSVD_MASK.  This error_code gets propagated and checked at the
> beginning of page_fault_can_be_fast(), where it should break the
> function execution.
> 
> How did the execution get all the way to the loop?
> 
hmm, a recent Paolo's cleanup patch already fixed it.
e08d26f ("KVM: x86: simplify ept_misconfig")

In the past, PFERR_RSVD_MASK is not set.

So this patch doesnt need any more. thanks.

> Thanks.

-- 
Thanks,
Changbin Du


signature.asc
Description: PGP signature

[PATCH 2/3] drm/rockchip: Add support for Rockchip Soc RGB output interface

[Sandy Huang]

Like rockchip rv1108 crtc can directly output parallel and serial
RGB data to panel or conversion chip, so we add this driver to
probe encoder and connector.

Signed-off-by: Sandy Huang 
---
 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c | 327 
 5 files changed, 340 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0c31f0a..ff1c781 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -8,6 +8,7 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+   select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
  Choose this option if you have a Rockchip soc chipset.
@@ -65,4 +66,12 @@ config ROCKCHIP_LVDS
  Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
  support LVDS, rgb, dual LVDS output mode. say Y to enable its
  driver.
+
+config ROCKCHIP_RGB
+   bool "Rockchip RGB support"
+   help
+ Choose this option to enable support for Rockchip RGB output.
+ Like Rockchip rv1108 SoC CRTC can directly output parallel and
+ serial RGB format to panel or connect to a conversion chip.
+ say Y to enable its driver.
 endif
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a881d2c..f32a17f 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -13,5 +13,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 082c251..36e602a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -449,6 +449,8 @@ static int __init rockchip_drm_init(void)
CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
+   ADD_ROCKCHIP_SUB_DRIVER(rockchip_rgb_driver,
+   CONFIG_ROCKCHIP_RGB);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver,
CONFIG_ROCKCHIP_DW_HDMI);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 498dfbc..6b0ec7e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,5 +70,6 @@ extern struct platform_driver dw_mipi_dsi_driver;
 extern struct platform_driver inno_hdmi_driver;
 extern struct platform_driver rockchip_dp_driver;
 extern struct platform_driver rockchip_lvds_driver;
+extern struct platform_driver rockchip_rgb_driver;
 extern struct platform_driver vop_platform_driver;
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c 
b/drivers/gpu/drm/rockchip/rockchip_rgb.c
new file mode 100644
index 000..0f0e6b464
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Sandy Huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_rgb(c) container_of(c, struct rockchip_rgb, connector)
+#define encoder_to_rgb(c) container_of(c, struct rockchip_rgb, encoder)
+
+struct rockchip_rgb {
+   struct device *dev;
+   struct drm_device *drm_dev;
+   struct drm_panel *panel;
+   struct drm_bridge *bridge;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+   struct dev_pin_info *pins;
+   int 

[PATCH 1/3] dt-bindings: Add document for rockchip RGB output interface

[Sandy Huang]

This path add support rv1108 rgb output interface driver.

Signed-off-by: Sandy Huang 
---
 .../bindings/display/rockchip/rockchip-rgb.txt | 80 ++
 1 file changed, 80 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
new file mode 100644
index 000..4164512
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
@@ -0,0 +1,80 @@
+Rockchip RV1108 RGB interface
+
+
+Required properties:
+- compatible: matching the soc type:
+   - "rockchip,rv1108-rgb";
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this interface.
+
+Required nodes:
+- rockchip,rgb-mode: should be "p888", "p666", "p565", "s888", "s888-dummy"
+   - p888: output r8-g8-b8 at each dclk cycle for per-pixel
+   - p666: output r6-g6-b6 at each dclk cycle for per-pixel
+   - p565: output r5-g6-b5 at each dclk cycle for per-pixel
+   - s888: output r8-g8-b8 in three dclk cycle for per-pixel
+   - s888-dmmy: output r8-g8-b8-dummy in four dclk cycle for per-pixel
+
+The rgb has two video ports described by:
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop
+- video port 1 for either a panel or subsequent encoder
+
+the panel described by:
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+Panel other required properties:
+- ports for remote rgb output.
+
+Example:
+
+panel: panel {
+   compatible = "auo,b101ean01";
+   enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+
+   ports {
+   panel_in_rgb: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+};
+
+For Rockchip RV1108:
+
+   rgb: rgb {
+   compatible = "rockchip,rv1108-rgb";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   rockchip,rgb-mode = "p888";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in_vop: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_rgb>;
+   };
+   };
+
+   rgb_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_out_panel: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_in_rgb>;
+   };
+   };
+   };
+   };
-- 
2.7.4

[PATCH 2/3] drm/rockchip: Add support for Rockchip Soc RGB output interface

[Sandy Huang]

Like rockchip rv1108 crtc can directly output parallel and serial
RGB data to panel or conversion chip, so we add this driver to
probe encoder and connector.

Signed-off-by: Sandy Huang 
---
 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c | 327 
 5 files changed, 340 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0c31f0a..ff1c781 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -8,6 +8,7 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+   select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
  Choose this option if you have a Rockchip soc chipset.
@@ -65,4 +66,12 @@ config ROCKCHIP_LVDS
  Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
  support LVDS, rgb, dual LVDS output mode. say Y to enable its
  driver.
+
+config ROCKCHIP_RGB
+   bool "Rockchip RGB support"
+   help
+ Choose this option to enable support for Rockchip RGB output.
+ Like Rockchip rv1108 SoC CRTC can directly output parallel and
+ serial RGB format to panel or connect to a conversion chip.
+ say Y to enable its driver.
 endif
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a881d2c..f32a17f 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -13,5 +13,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 082c251..36e602a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -449,6 +449,8 @@ static int __init rockchip_drm_init(void)
CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
+   ADD_ROCKCHIP_SUB_DRIVER(rockchip_rgb_driver,
+   CONFIG_ROCKCHIP_RGB);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver,
CONFIG_ROCKCHIP_DW_HDMI);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 498dfbc..6b0ec7e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,5 +70,6 @@ extern struct platform_driver dw_mipi_dsi_driver;
 extern struct platform_driver inno_hdmi_driver;
 extern struct platform_driver rockchip_dp_driver;
 extern struct platform_driver rockchip_lvds_driver;
+extern struct platform_driver rockchip_rgb_driver;
 extern struct platform_driver vop_platform_driver;
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c 
b/drivers/gpu/drm/rockchip/rockchip_rgb.c
new file mode 100644
index 000..0f0e6b464
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Sandy Huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_rgb(c) container_of(c, struct rockchip_rgb, connector)
+#define encoder_to_rgb(c) container_of(c, struct rockchip_rgb, encoder)
+
+struct rockchip_rgb {
+   struct device *dev;
+   struct drm_device *drm_dev;
+   struct drm_panel *panel;
+   struct drm_bridge *bridge;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+   struct dev_pin_info *pins;
+   int output_mode;
+};
+
+static inline int 

[PATCH 1/3] dt-bindings: Add document for rockchip RGB output interface

[Sandy Huang]

This path add support rv1108 rgb output interface driver.

Signed-off-by: Sandy Huang 
---
 .../bindings/display/rockchip/rockchip-rgb.txt | 80 ++
 1 file changed, 80 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
new file mode 100644
index 000..4164512
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
@@ -0,0 +1,80 @@
+Rockchip RV1108 RGB interface
+
+
+Required properties:
+- compatible: matching the soc type:
+   - "rockchip,rv1108-rgb";
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this interface.
+
+Required nodes:
+- rockchip,rgb-mode: should be "p888", "p666", "p565", "s888", "s888-dummy"
+   - p888: output r8-g8-b8 at each dclk cycle for per-pixel
+   - p666: output r6-g6-b6 at each dclk cycle for per-pixel
+   - p565: output r5-g6-b5 at each dclk cycle for per-pixel
+   - s888: output r8-g8-b8 in three dclk cycle for per-pixel
+   - s888-dmmy: output r8-g8-b8-dummy in four dclk cycle for per-pixel
+
+The rgb has two video ports described by:
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop
+- video port 1 for either a panel or subsequent encoder
+
+the panel described by:
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+Panel other required properties:
+- ports for remote rgb output.
+
+Example:
+
+panel: panel {
+   compatible = "auo,b101ean01";
+   enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+
+   ports {
+   panel_in_rgb: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+};
+
+For Rockchip RV1108:
+
+   rgb: rgb {
+   compatible = "rockchip,rv1108-rgb";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   rockchip,rgb-mode = "p888";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in_vop: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_rgb>;
+   };
+   };
+
+   rgb_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_out_panel: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_in_rgb>;
+   };
+   };
+   };
+   };
-- 
2.7.4

[PATCH 0/3] Add support rockchip RGB output interface

[Sandy Huang]

This patches add support some rockchip Soc like rv1108, the VOP can directly
output parallel and serial RGB data to panel or to conversion chip. So we add
this driver to probe encoder and connector to support this case.

Sandy Huang (3):
  dt-bindings: Add document for rockchip RGB output interface
  drm/rockchip: Add support for Rockchip Soc RGB output interface
  drm/rockchip: vop: Add more RGB output interface type

 .../bindings/display/rockchip/rockchip-rgb.txt |  80 +
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   2 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c| 327 +
 7 files changed, 422 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c

-- 
2.7.4

[PATCH 3/3] drm/rockchip: vop: Add more RGB output interface type

[Sandy Huang]

This patch add serial RGB output interface for rockchip vop, the
more info about serial RGB output interface described at the
following file:

Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

Signed-off-by: Sandy Huang 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 56bbd2e..59a01c3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -209,6 +209,8 @@ struct vop_data {
 #define ROCKCHIP_OUT_MODE_P888 0
 #define ROCKCHIP_OUT_MODE_P666 1
 #define ROCKCHIP_OUT_MODE_P565 2
+#define ROCKCHIP_OUT_MODE_S888 8
+#define ROCKCHIP_OUT_MODE_S888_DUMMY   12
 /* for use special outface */
 #define ROCKCHIP_OUT_MODE_ 15
 
-- 
2.7.4

[PATCH 0/3] Add support rockchip RGB output interface

[Sandy Huang]

This patches add support some rockchip Soc like rv1108, the VOP can directly
output parallel and serial RGB data to panel or to conversion chip. So we add
this driver to probe encoder and connector to support this case.

Sandy Huang (3):
  dt-bindings: Add document for rockchip RGB output interface
  drm/rockchip: Add support for Rockchip Soc RGB output interface
  drm/rockchip: vop: Add more RGB output interface type

 .../bindings/display/rockchip/rockchip-rgb.txt |  80 +
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   2 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c| 327 +
 7 files changed, 422 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c

-- 
2.7.4

[PATCH 3/3] drm/rockchip: vop: Add more RGB output interface type

[Sandy Huang]

This patch add serial RGB output interface for rockchip vop, the
more info about serial RGB output interface described at the
following file:

Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

Signed-off-by: Sandy Huang 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 56bbd2e..59a01c3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -209,6 +209,8 @@ struct vop_data {
 #define ROCKCHIP_OUT_MODE_P888 0
 #define ROCKCHIP_OUT_MODE_P666 1
 #define ROCKCHIP_OUT_MODE_P565 2
+#define ROCKCHIP_OUT_MODE_S888 8
+#define ROCKCHIP_OUT_MODE_S888_DUMMY   12
 /* for use special outface */
 #define ROCKCHIP_OUT_MODE_ 15
 
-- 
2.7.4

linux-next: Tree for Sep 14

[Stephen Rothwell]

Hi all,

Please do not add any v4.15 related material to your linux-next
included branches until after v4.14-rc1 has been released.

Changes since 20170913:

The vfs tree gained a conflict against the btrfs-kdave tree.

Non-merge commits (relative to Linus' tree): 746
 1078 files changed, 39588 insertions(+), 9357 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 267 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (46c1e79fee41 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (64236e315955 kbuild: update comments of 
Makefile.asm-generic)
Merging arc-current/for-curr (1ee55a8f7f6b ARC: Re-enable MMU upon Machine 
Check exception)
Merging arm-current/fixes (746a272e4414 ARM: 8692/1: mm: abort uaccess retries 
upon fatal signal)
Merging m68k-current/for-linus (558d5ad276c9 m68k/mac: Avoid soft-lockup 
warning after mach_power_off)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (1a92a80ad386 powerpc/mm: Ensure cpumask update is 
ordered)
Merging sparc/master (6470812e2226 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (6fa9c623a03c MAINTAINERS: review Renesas DT bindings as 
well)
Merging ipsec/master (23e9fcfef1f3 vti: fix NULL dereference in xfrm_input())
Merging netfilter/master (90c4ae4e2c1d netfilter: xt_hashlimit: fix build error 
caused by 64bit division)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (f957dd3c8db2 brcmfmac: feature check for 
multi-scheduled scan fails on bcm4345 devices)
Merging mac80211/master (126f760ca94d rds: Fix incorrect statistics counting)
Merging sound-current/for-linus (fc27fe7e8dee ALSA: seq: Cancel pending 
autoload work at unbinding device)
Merging pci-current/for-linus (8e1101d25164 PCI/MSI: Don't warn when 
irq_create_affinity_masks() returns NULL)
Merging driver-core.current/driver-core-linus (d34fc1adf01f Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (d34fc1adf01f Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (d34fc1adf01f Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (b7d44c36a6f6 usb: renesas_usbhs: gadget: fix 
unused-but-set-variable warning)
Merging usb-serial-fixes/usb-linus (fd1b8668af59 USB: serial: option: add 
D-Link DWM-222 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (f007cad159e9 Revert "firmware: add 
sanity check on shutdown/suspend")
Merging char-misc.current/char-misc-linus (d34fc1adf01f Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (a6cbfa1e6d38 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (2d45a7e89833 crypto: af_alg - get_page upon 
reassignment

linux-next: Tree for Sep 14

[Stephen Rothwell]

Hi all,

Please do not add any v4.15 related material to your linux-next
included branches until after v4.14-rc1 has been released.

Changes since 20170913:

The vfs tree gained a conflict against the btrfs-kdave tree.

Non-merge commits (relative to Linus' tree): 746
 1078 files changed, 39588 insertions(+), 9357 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 267 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (46c1e79fee41 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (64236e315955 kbuild: update comments of 
Makefile.asm-generic)
Merging arc-current/for-curr (1ee55a8f7f6b ARC: Re-enable MMU upon Machine 
Check exception)
Merging arm-current/fixes (746a272e4414 ARM: 8692/1: mm: abort uaccess retries 
upon fatal signal)
Merging m68k-current/for-linus (558d5ad276c9 m68k/mac: Avoid soft-lockup 
warning after mach_power_off)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (1a92a80ad386 powerpc/mm: Ensure cpumask update is 
ordered)
Merging sparc/master (6470812e2226 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (6fa9c623a03c MAINTAINERS: review Renesas DT bindings as 
well)
Merging ipsec/master (23e9fcfef1f3 vti: fix NULL dereference in xfrm_input())
Merging netfilter/master (90c4ae4e2c1d netfilter: xt_hashlimit: fix build error 
caused by 64bit division)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (f957dd3c8db2 brcmfmac: feature check for 
multi-scheduled scan fails on bcm4345 devices)
Merging mac80211/master (126f760ca94d rds: Fix incorrect statistics counting)
Merging sound-current/for-linus (fc27fe7e8dee ALSA: seq: Cancel pending 
autoload work at unbinding device)
Merging pci-current/for-linus (8e1101d25164 PCI/MSI: Don't warn when 
irq_create_affinity_masks() returns NULL)
Merging driver-core.current/driver-core-linus (d34fc1adf01f Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (d34fc1adf01f Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (d34fc1adf01f Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (b7d44c36a6f6 usb: renesas_usbhs: gadget: fix 
unused-but-set-variable warning)
Merging usb-serial-fixes/usb-linus (fd1b8668af59 USB: serial: option: add 
D-Link DWM-222 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (f007cad159e9 Revert "firmware: add 
sanity check on shutdown/suspend")
Merging char-misc.current/char-misc-linus (d34fc1adf01f Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (a6cbfa1e6d38 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (2d45a7e89833 crypto: af_alg - get_page upon 
reassignment

[PATCH v2] ASoC: fsl_ssi: Caculate bit clock rate using slot number and width

[Nicolin Chen]

The set_sysclk() now is used to override the output bit clock rate.
But this is not a common way to implement a set_dai_sysclk(). And
this creates a problem when a general machine driver (simple-card
for example) tries to do set_dai_sysclk() by passing an input clock
rate for the baud clock instead of setting the bit clock rate as
fsl_ssi driver expected.

So this patch solves this problem by firstly removing set_sysclk()
since the hw_params() can calculate the bit clock rate. Secondly,
in order not to break those TDM use cases which previously might
have been using set_sysclk() to override the bit clock rate, this
patch changes the driver to calculate the bit clock rate using the
slot number and the slot width from the via set_tdm_slot().

The patch also removes an obsolete comment of the dir parameter.

Signed-off-by: Nicolin Chen 
---
 sound/soc/fsl/fsl_ssi.c | 46 ++
 1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 64598d1..f2f51e06 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -197,12 +197,13 @@ struct fsl_ssi_soc_data {
  * @use_dma: DMA is used or FIQ with stream filter
  * @use_dual_fifo: DMA with support for both FIFOs used
  * @fifo_deph: Depth of the SSI FIFOs
+ * @slot_width: width of each DAI slot
+ * @slots: number of slots
  * @rxtx_reg_val: Specific register settings for receive/transmit configuration
  *
  * @clk: SSI clock
  * @baudclk: SSI baud clock for master mode
  * @baudclk_streams: Active streams that are using baudclk
- * @bitclk_freq: bitclock frequency set by .set_dai_sysclk
  *
  * @dma_params_tx: DMA transmit parameters
  * @dma_params_rx: DMA receive parameters
@@ -233,12 +234,13 @@ struct fsl_ssi_private {
bool use_dual_fifo;
bool has_ipg_clk_name;
unsigned int fifo_depth;
+   unsigned int slot_width;
+   unsigned int slots;
struct fsl_ssi_rxtx_reg_val rxtx_reg_val;
 
struct clk *clk;
struct clk *baudclk;
unsigned int baudclk_streams;
-   unsigned int bitclk_freq;
 
/* regcache for volatile regs */
u32 regcache_sfcsr;
@@ -700,8 +702,8 @@ static void fsl_ssi_shutdown(struct snd_pcm_substream 
*substream,
  * Note: This function can be only called when using SSI as DAI master
  *
  * Quick instruction for parameters:
- * freq: Output BCLK frequency = samplerate * 32 (fixed) * channels
- * dir: SND_SOC_CLOCK_OUT -> TxBCLK, SND_SOC_CLOCK_IN -> RxBCLK.
+ * freq: Output BCLK frequency = samplerate * slots * slot_width
+ *   (In 2-channel I2S Master mode, slot_width is fixed 32)
  */
 static int fsl_ssi_set_bclk(struct snd_pcm_substream *substream,
struct snd_soc_dai *cpu_dai,
@@ -712,15 +714,21 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream 
*substream,
int synchronous = ssi_private->cpu_dai_drv.symmetric_rates, ret;
u32 pm = 999, div2, psr, stccr, mask, afreq, factor, i;
unsigned long clkrate, baudrate, tmprate;
+   unsigned int slots = params_channels(hw_params);
+   unsigned int slot_width = 32;
u64 sub, savesub = 10;
unsigned int freq;
bool baudclk_is_used;
 
-   /* Prefer the explicitly set bitclock frequency */
-   if (ssi_private->bitclk_freq)
-   freq = ssi_private->bitclk_freq;
-   else
-   freq = params_channels(hw_params) * 32 * params_rate(hw_params);
+   /* Override slots and slot_width if being specifically set... */
+   if (ssi_private->slots)
+   slots = ssi_private->slots;
+   /* ...but keep 32 bits if slots is 2 -- I2S Master mode */
+   if (ssi_private->slot_width && slots != 2)
+   slot_width = ssi_private->slot_width;
+
+   /* Generate bit clock based on the slot number and slot width */
+   freq = slots * slot_width * params_rate(hw_params);
 
/* Don't apply it to any non-baudclk circumstance */
if (IS_ERR(ssi_private->baudclk))
@@ -805,16 +813,6 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream 
*substream,
return 0;
 }
 
-static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
-   int clk_id, unsigned int freq, int dir)
-{
-   struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
-
-   ssi_private->bitclk_freq = freq;
-
-   return 0;
-}
-
 /**
  * fsl_ssi_hw_params - program the sample size
  *
@@ -1095,6 +1093,12 @@ static int fsl_ssi_set_dai_tdm_slot(struct snd_soc_dai 
*cpu_dai, u32 tx_mask,
struct regmap *regs = ssi_private->regs;
u32 val;
 
+   /* The word length should be 8, 10, 12, 16, 18, 20, 22 or 24 */
+   if (slot_width & 1 || slot_width < 8 || slot_width > 24) {
+   dev_err(cpu_dai->dev, "invalid slot width: %d\n", slot_width);
+   return -EINVAL;
+   }
+
/* The slot number should be >= 2 if 

[PATCH v2] ASoC: fsl_ssi: Caculate bit clock rate using slot number and width

[Nicolin Chen]

The set_sysclk() now is used to override the output bit clock rate.
But this is not a common way to implement a set_dai_sysclk(). And
this creates a problem when a general machine driver (simple-card
for example) tries to do set_dai_sysclk() by passing an input clock
rate for the baud clock instead of setting the bit clock rate as
fsl_ssi driver expected.

So this patch solves this problem by firstly removing set_sysclk()
since the hw_params() can calculate the bit clock rate. Secondly,
in order not to break those TDM use cases which previously might
have been using set_sysclk() to override the bit clock rate, this
patch changes the driver to calculate the bit clock rate using the
slot number and the slot width from the via set_tdm_slot().

The patch also removes an obsolete comment of the dir parameter.

Signed-off-by: Nicolin Chen 
---
 sound/soc/fsl/fsl_ssi.c | 46 ++
 1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 64598d1..f2f51e06 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -197,12 +197,13 @@ struct fsl_ssi_soc_data {
  * @use_dma: DMA is used or FIQ with stream filter
  * @use_dual_fifo: DMA with support for both FIFOs used
  * @fifo_deph: Depth of the SSI FIFOs
+ * @slot_width: width of each DAI slot
+ * @slots: number of slots
  * @rxtx_reg_val: Specific register settings for receive/transmit configuration
  *
  * @clk: SSI clock
  * @baudclk: SSI baud clock for master mode
  * @baudclk_streams: Active streams that are using baudclk
- * @bitclk_freq: bitclock frequency set by .set_dai_sysclk
  *
  * @dma_params_tx: DMA transmit parameters
  * @dma_params_rx: DMA receive parameters
@@ -233,12 +234,13 @@ struct fsl_ssi_private {
bool use_dual_fifo;
bool has_ipg_clk_name;
unsigned int fifo_depth;
+   unsigned int slot_width;
+   unsigned int slots;
struct fsl_ssi_rxtx_reg_val rxtx_reg_val;
 
struct clk *clk;
struct clk *baudclk;
unsigned int baudclk_streams;
-   unsigned int bitclk_freq;
 
/* regcache for volatile regs */
u32 regcache_sfcsr;
@@ -700,8 +702,8 @@ static void fsl_ssi_shutdown(struct snd_pcm_substream 
*substream,
  * Note: This function can be only called when using SSI as DAI master
  *
  * Quick instruction for parameters:
- * freq: Output BCLK frequency = samplerate * 32 (fixed) * channels
- * dir: SND_SOC_CLOCK_OUT -> TxBCLK, SND_SOC_CLOCK_IN -> RxBCLK.
+ * freq: Output BCLK frequency = samplerate * slots * slot_width
+ *   (In 2-channel I2S Master mode, slot_width is fixed 32)
  */
 static int fsl_ssi_set_bclk(struct snd_pcm_substream *substream,
struct snd_soc_dai *cpu_dai,
@@ -712,15 +714,21 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream 
*substream,
int synchronous = ssi_private->cpu_dai_drv.symmetric_rates, ret;
u32 pm = 999, div2, psr, stccr, mask, afreq, factor, i;
unsigned long clkrate, baudrate, tmprate;
+   unsigned int slots = params_channels(hw_params);
+   unsigned int slot_width = 32;
u64 sub, savesub = 10;
unsigned int freq;
bool baudclk_is_used;
 
-   /* Prefer the explicitly set bitclock frequency */
-   if (ssi_private->bitclk_freq)
-   freq = ssi_private->bitclk_freq;
-   else
-   freq = params_channels(hw_params) * 32 * params_rate(hw_params);
+   /* Override slots and slot_width if being specifically set... */
+   if (ssi_private->slots)
+   slots = ssi_private->slots;
+   /* ...but keep 32 bits if slots is 2 -- I2S Master mode */
+   if (ssi_private->slot_width && slots != 2)
+   slot_width = ssi_private->slot_width;
+
+   /* Generate bit clock based on the slot number and slot width */
+   freq = slots * slot_width * params_rate(hw_params);
 
/* Don't apply it to any non-baudclk circumstance */
if (IS_ERR(ssi_private->baudclk))
@@ -805,16 +813,6 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream 
*substream,
return 0;
 }
 
-static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
-   int clk_id, unsigned int freq, int dir)
-{
-   struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
-
-   ssi_private->bitclk_freq = freq;
-
-   return 0;
-}
-
 /**
  * fsl_ssi_hw_params - program the sample size
  *
@@ -1095,6 +1093,12 @@ static int fsl_ssi_set_dai_tdm_slot(struct snd_soc_dai 
*cpu_dai, u32 tx_mask,
struct regmap *regs = ssi_private->regs;
u32 val;
 
+   /* The word length should be 8, 10, 12, 16, 18, 20, 22 or 24 */
+   if (slot_width & 1 || slot_width < 8 || slot_width > 24) {
+   dev_err(cpu_dai->dev, "invalid slot width: %d\n", slot_width);
+   return -EINVAL;
+   }
+
/* The slot number should be >= 2 if using Network mode or I2S 

[PATCH] checkpatch: support function pointers for unnamed function definition arguments

[Miles Chen]

Current unnamed function definition argument does not include function
pointer cases and it reports warnings like:

WARNING: function definition argument 'void' should also have an identifier name
+unsigned int (*dummy)(void);

Support function pointers for unnamed function arguments.

Signed-off-by: Miles Chen 
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index dd2c262..dc6da15 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5957,7 +5957,7 @@ sub process {
 
 # check for function declarations that have arguments without identifier names
if (defined $stat &&
-   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*$Ident\s*\(\s*([^{]+)\s*\)\s*;/s &&
+   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*\(?\s*\*?\s*$Ident\s*\)\s*\(\s*([^{]+)\s*\)\s*;/s &&
$1 ne "void") {
my $args = trim($1);
while ($args =~ 
m/\s*($Type\s*(?:$Ident|\(\s*\*\s*$Ident?\s*\)\s*$balanced_parens)?)/g) {
-- 
1.9.1

[PATCH] checkpatch: support function pointers for unnamed function definition arguments

[Miles Chen]

Current unnamed function definition argument does not include function
pointer cases and it reports warnings like:

WARNING: function definition argument 'void' should also have an identifier name
+unsigned int (*dummy)(void);

Support function pointers for unnamed function arguments.

Signed-off-by: Miles Chen 
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index dd2c262..dc6da15 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5957,7 +5957,7 @@ sub process {
 
 # check for function declarations that have arguments without identifier names
if (defined $stat &&
-   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*$Ident\s*\(\s*([^{]+)\s*\)\s*;/s &&
+   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*\(?\s*\*?\s*$Ident\s*\)\s*\(\s*([^{]+)\s*\)\s*;/s &&
$1 ne "void") {
my $args = trim($1);
while ($args =~ 
m/\s*($Type\s*(?:$Ident|\(\s*\*\s*$Ident?\s*\)\s*$balanced_parens)?)/g) {
-- 
1.9.1

[PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

[nixiaoming]

If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink

so, we need add mutex_lock(_mutex) to __unregister_prot_hook
or add spin_lock(>bind_lock) before po-> fanout = match

test on linux 4.1.12:
./trinity -c setsockopt -C 2 -X &

BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: GW  O4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[] dump_backtrace+0x0/0xf8
[] show_stack+0x20/0x28
[] dump_stack+0xac/0xe4
[] panic+0xf8/0x268
[] __unregister_prot_hook+0xa0/0x144
[] packet_set_ring+0x280/0x5b4
[] packet_setsockopt+0x320/0x950
[] SyS_setsockopt+0xa4/0xd4

Signed-off-by: nixiaoming 
Tested-by: wudesheng 
---
 net/packet/af_packet.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 008a45c..0300146 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool 
sync)
 
po->running = 0;
 
+   mutex_lock(_mutex);
if (po->fanout)
__fanout_unlink(sk, po);
else
__dev_remove_pack(>prot_hook);
+   mutex_unlock(_mutex);
 
__sock_put(sk);
 
-- 
2.11.0.1

[PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

[nixiaoming]

If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink

so, we need add mutex_lock(_mutex) to __unregister_prot_hook
or add spin_lock(>bind_lock) before po-> fanout = match

test on linux 4.1.12:
./trinity -c setsockopt -C 2 -X &

BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: GW  O4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[] dump_backtrace+0x0/0xf8
[] show_stack+0x20/0x28
[] dump_stack+0xac/0xe4
[] panic+0xf8/0x268
[] __unregister_prot_hook+0xa0/0x144
[] packet_set_ring+0x280/0x5b4
[] packet_setsockopt+0x320/0x950
[] SyS_setsockopt+0xa4/0xd4

Signed-off-by: nixiaoming 
Tested-by: wudesheng 
---
 net/packet/af_packet.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 008a45c..0300146 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool 
sync)
 
po->running = 0;
 
+   mutex_lock(_mutex);
if (po->fanout)
__fanout_unlink(sk, po);
else
__dev_remove_pack(>prot_hook);
+   mutex_unlock(_mutex);
 
__sock_put(sk);
 
-- 
2.11.0.1

[PATCH] gpio: thunderx: remove unused .map() hook from irq_domain_ops

[Masahiro Yamada]

This driver implements .alloc() hook, so .map() is not used.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpio/gpio-thunderx.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 57efb25..b5adb79 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -417,18 +417,6 @@ static struct irq_chip thunderx_gpio_irq_chip = {
.flags  = IRQCHIP_SET_TYPE_MASKED
 };
 
-static int thunderx_gpio_irq_map(struct irq_domain *d, unsigned int irq,
-irq_hw_number_t hwirq)
-{
-   struct thunderx_gpio *txgpio = d->host_data;
-
-   if (hwirq >= txgpio->chip.ngpio)
-   return -EINVAL;
-   if (!thunderx_gpio_is_gpio_nowarn(txgpio, hwirq))
-   return -EPERM;
-   return 0;
-}
-
 static int thunderx_gpio_irq_translate(struct irq_domain *d,
   struct irq_fwspec *fwspec,
   irq_hw_number_t *hwirq,
@@ -455,7 +443,6 @@ static int thunderx_gpio_irq_alloc(struct irq_domain *d, 
unsigned int virq,
 }
 
 static const struct irq_domain_ops thunderx_gpio_irqd_ops = {
-   .map= thunderx_gpio_irq_map,
.alloc  = thunderx_gpio_irq_alloc,
.translate  = thunderx_gpio_irq_translate
 };
-- 
2.7.4

[PATCH] gpio: thunderx: remove unused .map() hook from irq_domain_ops

[Masahiro Yamada]

This driver implements .alloc() hook, so .map() is not used.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpio/gpio-thunderx.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 57efb25..b5adb79 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -417,18 +417,6 @@ static struct irq_chip thunderx_gpio_irq_chip = {
.flags  = IRQCHIP_SET_TYPE_MASKED
 };
 
-static int thunderx_gpio_irq_map(struct irq_domain *d, unsigned int irq,
-irq_hw_number_t hwirq)
-{
-   struct thunderx_gpio *txgpio = d->host_data;
-
-   if (hwirq >= txgpio->chip.ngpio)
-   return -EINVAL;
-   if (!thunderx_gpio_is_gpio_nowarn(txgpio, hwirq))
-   return -EPERM;
-   return 0;
-}
-
 static int thunderx_gpio_irq_translate(struct irq_domain *d,
   struct irq_fwspec *fwspec,
   irq_hw_number_t *hwirq,
@@ -455,7 +443,6 @@ static int thunderx_gpio_irq_alloc(struct irq_domain *d, 
unsigned int virq,
 }
 
 static const struct irq_domain_ops thunderx_gpio_irqd_ops = {
-   .map= thunderx_gpio_irq_map,
.alloc  = thunderx_gpio_irq_alloc,
.translate  = thunderx_gpio_irq_translate
 };
-- 
2.7.4

[PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

[nixiaoming]

If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink

so, we need add mutex_lock(_mutex) to __unregister_prot_hook
or add spin_lock(>bind_lock) before po-> fanout = match

test on linux 4.1.42:
./trinity -c setsockopt -C 2 -X &

BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: GW  O4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[] dump_backtrace+0x0/0xf8
[] show_stack+0x20/0x28
[] dump_stack+0xac/0xe4
[] panic+0xf8/0x268
[] __unregister_prot_hook+0xa0/0x144
[] packet_set_ring+0x280/0x5b4
[] packet_setsockopt+0x320/0x950
[] SyS_setsockopt+0xa4/0xd4

Signed-off-by: nixiaoming 
Tested-by: wudesheng 
---
 net/packet/af_packet.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 008a45c..0300146 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool 
sync)
 
po->running = 0;
 
+   mutex_lock(_mutex);
if (po->fanout)
__fanout_unlink(sk, po);
else
__dev_remove_pack(>prot_hook);
+   mutex_unlock(_mutex);
 
__sock_put(sk);
 
-- 
2.11.0.1

[PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

[nixiaoming]

If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink

so, we need add mutex_lock(_mutex) to __unregister_prot_hook
or add spin_lock(>bind_lock) before po-> fanout = match

test on linux 4.1.42:
./trinity -c setsockopt -C 2 -X &

BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: GW  O4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[] dump_backtrace+0x0/0xf8
[] show_stack+0x20/0x28
[] dump_stack+0xac/0xe4
[] panic+0xf8/0x268
[] __unregister_prot_hook+0xa0/0x144
[] packet_set_ring+0x280/0x5b4
[] packet_setsockopt+0x320/0x950
[] SyS_setsockopt+0xa4/0xd4

Signed-off-by: nixiaoming 
Tested-by: wudesheng 
---
 net/packet/af_packet.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 008a45c..0300146 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool 
sync)
 
po->running = 0;
 
+   mutex_lock(_mutex);
if (po->fanout)
__fanout_unlink(sk, po);
else
__dev_remove_pack(>prot_hook);
+   mutex_unlock(_mutex);
 
__sock_put(sk);
 
-- 
2.11.0.1

[PATCH 1/1] Coccinelle: array_size: report even if include is missing

[Jérémy Lefaure]

Rule r does not depend on rule i (which is the include of
linux/kernel.h) so the output should not depend on i in
org and report mode.

Signed-off-by: Jérémy Lefaure 
---

I have tested this patch in report mode on the file
drivers/staging/rtlwifi/phydm/rtl8822b/halhwimg8822b_rf.c which does not
use ARRAY_SIZE and does not include linux/kernel.h.

 scripts/coccinelle/misc/array_size.cocci | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/coccinelle/misc/array_size.cocci 
b/scripts/coccinelle/misc/array_size.cocci
index 6ec05710b017..09520f0941f0 100644
--- a/scripts/coccinelle/misc/array_size.cocci
+++ b/scripts/coccinelle/misc/array_size.cocci
@@ -72,13 +72,13 @@ position p;
  (sizeof(E)@p /sizeof(T))
 )
 
-@script:python depends on i&@
+@script:python depends on org@
 p << r.p;
 @@
 
 coccilib.org.print_todo(p[0], "WARNING should use ARRAY_SIZE")
 
-@script:python depends on i&@
+@script:python depends on report@
 p << r.p;
 @@
 
-- 
2.14.1

[PATCH 1/1] Coccinelle: array_size: report even if include is missing

[Jérémy Lefaure]

Rule r does not depend on rule i (which is the include of
linux/kernel.h) so the output should not depend on i in
org and report mode.

Signed-off-by: Jérémy Lefaure 
---

I have tested this patch in report mode on the file
drivers/staging/rtlwifi/phydm/rtl8822b/halhwimg8822b_rf.c which does not
use ARRAY_SIZE and does not include linux/kernel.h.

 scripts/coccinelle/misc/array_size.cocci | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/coccinelle/misc/array_size.cocci 
b/scripts/coccinelle/misc/array_size.cocci
index 6ec05710b017..09520f0941f0 100644
--- a/scripts/coccinelle/misc/array_size.cocci
+++ b/scripts/coccinelle/misc/array_size.cocci
@@ -72,13 +72,13 @@ position p;
  (sizeof(E)@p /sizeof(T))
 )
 
-@script:python depends on i&@
+@script:python depends on org@
 p << r.p;
 @@
 
 coccilib.org.print_todo(p[0], "WARNING should use ARRAY_SIZE")
 
-@script:python depends on i&@
+@script:python depends on report@
 p << r.p;
 @@
 
-- 
2.14.1

[PATCH] signal: remove unused variable

[Dmitry V. Levin]

Reported-by: Stephen Rothwell 
Fixes: 9b24ec57688a ("get_compat_sigset()")
Signed-off-by: Dmitry V. Levin 
---
 kernel/signal.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 3198a7d2e5ff..36a523640894 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3440,7 +3440,6 @@ COMPAT_SYSCALL_DEFINE4(rt_sigaction, int, sig,
 
if (act) {
compat_uptr_t handler;
-   compat_sigset_t mask;
ret = get_user(handler, >sa_handler);
new_ka.sa.sa_handler = compat_ptr(handler);
 #ifdef __ARCH_HAS_SA_RESTORER

-- 
ldv

[PATCH] signal: remove unused variable

[Dmitry V. Levin]

Reported-by: Stephen Rothwell 
Fixes: 9b24ec57688a ("get_compat_sigset()")
Signed-off-by: Dmitry V. Levin 
---
 kernel/signal.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 3198a7d2e5ff..36a523640894 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3440,7 +3440,6 @@ COMPAT_SYSCALL_DEFINE4(rt_sigaction, int, sig,
 
if (act) {
compat_uptr_t handler;
-   compat_sigset_t mask;
ret = get_user(handler, >sa_handler);
new_ka.sa.sa_handler = compat_ptr(handler);
 #ifdef __ARCH_HAS_SA_RESTORER

-- 
ldv

Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit

[Linus Torvalds]

On Wed, Sep 13, 2017 at 7:12 PM, Tim Chen  wrote:
>
> BTW, will you be merging these 2 patches in 4.14?

Yes, and thanks for reminding me.

In fact, would you mind sending me the latest versions, rather than me
digging them out of the disaster area that is my mailbox and possibly
picking an older version?

 Linus

Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit

[Linus Torvalds]

On Wed, Sep 13, 2017 at 7:12 PM, Tim Chen  wrote:
>
> BTW, will you be merging these 2 patches in 4.14?

Yes, and thanks for reminding me.

In fact, would you mind sending me the latest versions, rather than me
digging them out of the disaster area that is my mailbox and possibly
picking an older version?

 Linus

RE: [Intel-wired-lan] [PATCH] igb: check memory allocation failure

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Christophe JAILLET
> Sent: Monday, August 28, 2017 10:13 AM
> To: Waskiewicz Jr, Peter ; Kirsher, Jeffrey T
> 
> Cc: net...@vger.kernel.org; kernel-janit...@vger.kernel.org; intel-wired-
> l...@lists.osuosl.org; linux-kernel@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH] igb: check memory allocation failure
> 
> Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit :
> > On 8/27/17 2:42 AM, Christophe JAILLET wrote:
> >> Check memory allocation failures and return -ENOMEM in such cases, as
> >> already done for other memory allocations in this function.
> >>
> >> This avoids NULL pointers dereference.
> >>
> >> Signed-off-by: Christophe JAILLET 
> >> ---
> >>drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
> >>1 file changed, 2 insertions(+)
> >>

This seems to be fine from a "it does not break in testing" perspective, so...

Tested-by: Aaron Brown  > -PJ
> >
> Hi,
> 
> in fact, there is no leak because the only caller of 'igb_sw_init()'
> (i.e. 'igb_probe()'), already frees these resources in case of error,
> see [1]
> 
> These resources are also freed  in 'igb_remove()'.
> 
> Best reagrds,
> CJ
> 
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> next.git/tree/drivers/net/ethernet/intel/igb/igb_main.c#n2775

But is PJ's comment saying that it is not really necessary?  If so I tend to 
lean towards the don't touch it if it's not broken perspective.
 

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Willy Tarreau]

On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote:
> > Yes. I don't recall if it is a direct --force or if you would have to
> > remove the original tag first (with git push  :refs/tags/).
> 
> Ah, but then if someone had pulled the old tag, they would have to
> delete it locally before they can pull in the new one.  That's the main
> reason I'll not do this...

In fact not, the tags are automatically replaced upon pull. I've been
using such a crappy workflow for some time in the past, sharing human
errors with coworkers... Git is pretty tolerant to this. It's just
that it's terribly confusing because you can then have two people with
the same tag name pointing to different commit IDs, I really hate this,
it only works when all users are in the same office and you shout
"sorry I messed up, I'm pushing the tag again".

> Again, use the make command that we have just for this reason...

It also has the benefit of always reporting the same version for all
users including those only downloading the -rc patch.

Willy

RE: [Intel-wired-lan] [PATCH] igb: check memory allocation failure

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Christophe JAILLET
> Sent: Monday, August 28, 2017 10:13 AM
> To: Waskiewicz Jr, Peter ; Kirsher, Jeffrey T
> 
> Cc: net...@vger.kernel.org; kernel-janit...@vger.kernel.org; intel-wired-
> l...@lists.osuosl.org; linux-kernel@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH] igb: check memory allocation failure
> 
> Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit :
> > On 8/27/17 2:42 AM, Christophe JAILLET wrote:
> >> Check memory allocation failures and return -ENOMEM in such cases, as
> >> already done for other memory allocations in this function.
> >>
> >> This avoids NULL pointers dereference.
> >>
> >> Signed-off-by: Christophe JAILLET 
> >> ---
> >>drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
> >>1 file changed, 2 insertions(+)
> >>

This seems to be fine from a "it does not break in testing" perspective, so...

Tested-by: Aaron Brown  > -PJ
> >
> Hi,
> 
> in fact, there is no leak because the only caller of 'igb_sw_init()'
> (i.e. 'igb_probe()'), already frees these resources in case of error,
> see [1]
> 
> These resources are also freed  in 'igb_remove()'.
> 
> Best reagrds,
> CJ
> 
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> next.git/tree/drivers/net/ethernet/intel/igb/igb_main.c#n2775

But is PJ's comment saying that it is not really necessary?  If so I tend to 
lean towards the don't touch it if it's not broken perspective.
 

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Willy Tarreau]

On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote:
> > Yes. I don't recall if it is a direct --force or if you would have to
> > remove the original tag first (with git push  :refs/tags/).
> 
> Ah, but then if someone had pulled the old tag, they would have to
> delete it locally before they can pull in the new one.  That's the main
> reason I'll not do this...

In fact not, the tags are automatically replaced upon pull. I've been
using such a crappy workflow for some time in the past, sharing human
errors with coworkers... Git is pretty tolerant to this. It's just
that it's terribly confusing because you can then have two people with
the same tag name pointing to different commit IDs, I really hate this,
it only works when all users are in the same office and you shout
"sorry I messed up, I'm pushing the tag again".

> Again, use the make command that we have just for this reason...

It also has the benefit of always reporting the same version for all
users including those only downloading the -rc patch.

Willy

[PATCH] f2fs: show flush list status in sysfs

[Chao Yu]

This patch adds to show flush list status in sysfs.

Signed-off-by: Chao Yu 
---
 fs/f2fs/debug.c | 5 -
 fs/f2fs/f2fs.h  | 3 ++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 87f449845f5f..00c1d4a9f356 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -61,6 +61,8 @@ static void update_general_status(struct f2fs_sb_info *sbi)
atomic_read(_I(sbi)->fcc_info->issued_flush);
si->nr_flushing =
atomic_read(_I(sbi)->fcc_info->issing_flush);
+   si->flush_list_empty =
+   llist_empty(_I(sbi)->fcc_info->issue_list);
}
if (SM_I(sbi) && SM_I(sbi)->dcc_info) {
si->nr_discarded =
@@ -349,10 +351,11 @@ static int stat_show(struct seq_file *s, void *v)
seq_printf(s, "  - Inner Struct Count: tree: %d(%d), node: 
%d\n",
si->ext_tree, si->zombie_tree, si->ext_node);
seq_puts(s, "\nBalancing F2FS Async:\n");
-   seq_printf(s, "  - IO (CP: %4d, Data: %4d, Flush: (%4d %4d), "
+   seq_printf(s, "  - IO (CP: %4d, Data: %4d, Flush: (%4d %4d 
%4d), "
"Discard: (%4d %4d)) cmd: %4d undiscard:%4u\n",
   si->nr_wb_cp_data, si->nr_wb_data,
   si->nr_flushing, si->nr_flushed,
+  si->flush_list_empty,
   si->nr_discarding, si->nr_discarded,
   si->nr_discard_cmd, si->undiscard_blks);
seq_printf(s, "  - inmem: %4d, atomic IO: %4d (Max. %4d), "
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 5d33d5a84b07..c5d3d15b57c9 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2704,7 +2704,8 @@ struct f2fs_stat_info {
int free_nids, avail_nids, alloc_nids;
int total_count, utilization;
int bg_gc, nr_wb_cp_data, nr_wb_data;
-   int nr_flushing, nr_flushed, nr_discarding, nr_discarded;
+   int nr_flushing, nr_flushed, flush_list_empty;
+   int nr_discarding, nr_discarded;
int nr_discard_cmd;
unsigned int undiscard_blks;
int inline_xattr, inline_inode, inline_dir, append, update, orphans;
-- 
2.13.1.388.g69e6b9b4f4a9

[PATCH] f2fs: show flush list status in sysfs

[Chao Yu]

This patch adds to show flush list status in sysfs.

Signed-off-by: Chao Yu 
---
 fs/f2fs/debug.c | 5 -
 fs/f2fs/f2fs.h  | 3 ++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 87f449845f5f..00c1d4a9f356 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -61,6 +61,8 @@ static void update_general_status(struct f2fs_sb_info *sbi)
atomic_read(_I(sbi)->fcc_info->issued_flush);
si->nr_flushing =
atomic_read(_I(sbi)->fcc_info->issing_flush);
+   si->flush_list_empty =
+   llist_empty(_I(sbi)->fcc_info->issue_list);
}
if (SM_I(sbi) && SM_I(sbi)->dcc_info) {
si->nr_discarded =
@@ -349,10 +351,11 @@ static int stat_show(struct seq_file *s, void *v)
seq_printf(s, "  - Inner Struct Count: tree: %d(%d), node: 
%d\n",
si->ext_tree, si->zombie_tree, si->ext_node);
seq_puts(s, "\nBalancing F2FS Async:\n");
-   seq_printf(s, "  - IO (CP: %4d, Data: %4d, Flush: (%4d %4d), "
+   seq_printf(s, "  - IO (CP: %4d, Data: %4d, Flush: (%4d %4d 
%4d), "
"Discard: (%4d %4d)) cmd: %4d undiscard:%4u\n",
   si->nr_wb_cp_data, si->nr_wb_data,
   si->nr_flushing, si->nr_flushed,
+  si->flush_list_empty,
   si->nr_discarding, si->nr_discarded,
   si->nr_discard_cmd, si->undiscard_blks);
seq_printf(s, "  - inmem: %4d, atomic IO: %4d (Max. %4d), "
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 5d33d5a84b07..c5d3d15b57c9 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2704,7 +2704,8 @@ struct f2fs_stat_info {
int free_nids, avail_nids, alloc_nids;
int total_count, utilization;
int bg_gc, nr_wb_cp_data, nr_wb_data;
-   int nr_flushing, nr_flushed, nr_discarding, nr_discarded;
+   int nr_flushing, nr_flushed, flush_list_empty;
+   int nr_discarding, nr_discarded;
int nr_discard_cmd;
unsigned int undiscard_blks;
int inline_xattr, inline_inode, inline_dir, append, update, orphans;
-- 
2.13.1.388.g69e6b9b4f4a9

Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit

[Tim Chen]

On 08/29/2017 09:24 AM, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 9:13 AM, Tim Chen  wrote:
>>
>> It is affecting not a production use, but the customer's acceptance
>> test for their systems.  So I suspect it is a stress test.
> 
> Can you gently poke them and ask if they might make theie stress test
> code available?
> 
> Tell them that we have a fix, but right now it's delayed into 4.14
> because we have no visibility into what it is that it actually fixes,
> and whether it's all that critical or just some microbenchmark.
> 
>

Linus,

Here's what the customer think happened and is willing to tell us.
They have a parent process that spawns off 10 children per core and
kicked them to run. The child processes all access a common library.
We have 384 cores so 3840 child processes running.  When migration occur on
a page in the common library, the first child that access the page will
page fault and lock the page, with the other children also page faulting
quickly and pile up in the page wait list, till the first child is done.

Probably some kind of access pattern of the common library induces the
page migration to happen.

BTW, will you be merging these 2 patches in 4.14?

Thanks.

Tim

Re: [PATCH v2 1/2] dt-bindings: spi: Add Spreadtrum ADI controller documentation

[Baolin Wang]

Hi Rob,

On 14 September 2017 at 03:51, Rob Herring  wrote:
> On Fri, Sep 08, 2017 at 04:33:41PM +0800, Baolin Wang wrote:
>> This patch adds the binding documentation for Spreadtrum ADI
>> controller device.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes since v1:
>>  - Add more documentation the 'sprd,hw-channels' property and why need
>>  one hardware spinlock.
>> ---
>>  .../devicetree/bindings/spi/spi-sprd-adi.txt   |   58 
>> 
>>  1 file changed, 58 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/spi/spi-sprd-adi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt 
>> b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt
>> new file mode 100644
>> index 000..0f76336
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt
>> @@ -0,0 +1,58 @@
>> +Spreadtrum ADI controller based on SPI framework
>
> "SPI framework" is not relevant to bindings.

OK, I will remove this in next version.

>
>> +
>> +ADI is the abbreviation of Anolog-Digital interface, which is used to access
>> +analog chip (such as PMIC) from digital chip. ADI controller follows the SPI
>> +framework for its hardware implementation is alike to SPI bus and its timing
>> +is compatile to SPI timing.
>> +
>> +ADI controller has 50 channels including 2 software read/write channels and
>> +48 hardware channels to access analog chip. For 2 software read/write 
>> channels,
>> +users should set ADI registers to access analog chip. For hardware channels,
>> +we can configure them to allow other hardware components to use it 
>> independently,
>> +which means we can just link one analog chip address to one hardware 
>> channel,
>> +then users can access the mapped analog chip address by this hardware 
>> channel
>> +triggered by hardware components instead of ADI software channels.
>> +
>> +Thus we introduce one property named "sprd,hw-channels" to configure 
>> hardware
>> +channels, the first value specifies the hardware channel id which is used to
>> +transfer data triggered by hardware automatically, and the second value 
>> specifies
>> +the analog chip address where user want to access by hardware components.
>> +
>> +Another hand since we have multi-subsystems will use unique ADI to access 
>> analog
>
> Drop "Another hand"

OK.

>
>> +chip, when one system is reading/writing data by ADI software channels, that
>> +should be under one hardware spinlock protection to prevent other systems 
>> from
>> +reading/writing data by ADI software channels at the same time, or two 
>> parallel
>> +routine of setting ADI registers will make ADI controller registers chaos to
>> +lead incorrect results. Then we need one hardware spinlock to synchronize 
>> between
>> +the multiple subsystems.
>> +
>> +Required properties:
>> +- compatible: Should be "sprd,sc9860-adi".
>> +- reg: Offset and length of ADI-SPI controller register space.
>> +- hwlocks: Reference to a phandle of a hwlock provider node.
>> +- hwlock-names: Reference to hwlock name strings defined in the same order
>> + as the hwlocks, should be "adi".
>> +- #address-cells: Number of cells required to define a chip select address
>> + on the ADI-SPI bus. Should be set to 1.
>> +- #size-cells: Size of cells required to define a chip select address size
>> + on the ADI-SPI bus. Should be set to 0.
>> +
>> +Optional properties:
>> +- sprd,hw-channels: The first value specifies the hardware channel id which
>> + is used to transfer data triggered by hardware automatically, and
>> + the second value specifies the analog chip address where user want
>> + to access by hardware components.
>
> Need to say this is an array of values up to ? channels.

OK. Will add in next version.

>
> I wonder if this should be a slave property. Is there a relationship

It is not a slave property, it is used to configure ADI controller to
support to access analog chip by hardware automatically.

> between the SPI address (i.e. chip select) and the "analog chip

I think they are not related. The "analog chip address" is like the
offset address of one SPI slave (analog chip can be recognized as one
SPI slave).

> address"? It sounds like the h/w channels are a protocol specific to a
> particular PMIC/MFD that this controller supports.

Yes. Very appreciated for your comments.

-- 
Baolin.wang
Best Regards

Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit

[Tim Chen]

On 08/29/2017 09:24 AM, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 9:13 AM, Tim Chen  wrote:
>>
>> It is affecting not a production use, but the customer's acceptance
>> test for their systems.  So I suspect it is a stress test.
> 
> Can you gently poke them and ask if they might make theie stress test
> code available?
> 
> Tell them that we have a fix, but right now it's delayed into 4.14
> because we have no visibility into what it is that it actually fixes,
> and whether it's all that critical or just some microbenchmark.
> 
>

Linus,

Here's what the customer think happened and is willing to tell us.
They have a parent process that spawns off 10 children per core and
kicked them to run. The child processes all access a common library.
We have 384 cores so 3840 child processes running.  When migration occur on
a page in the common library, the first child that access the page will
page fault and lock the page, with the other children also page faulting
quickly and pile up in the page wait list, till the first child is done.

Probably some kind of access pattern of the common library induces the
page migration to happen.

BTW, will you be merging these 2 patches in 4.14?

Thanks.

Tim

Re: [PATCH v2 1/2] dt-bindings: spi: Add Spreadtrum ADI controller documentation

[Baolin Wang]

Hi Rob,

On 14 September 2017 at 03:51, Rob Herring  wrote:
> On Fri, Sep 08, 2017 at 04:33:41PM +0800, Baolin Wang wrote:
>> This patch adds the binding documentation for Spreadtrum ADI
>> controller device.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes since v1:
>>  - Add more documentation the 'sprd,hw-channels' property and why need
>>  one hardware spinlock.
>> ---
>>  .../devicetree/bindings/spi/spi-sprd-adi.txt   |   58 
>> 
>>  1 file changed, 58 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/spi/spi-sprd-adi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt 
>> b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt
>> new file mode 100644
>> index 000..0f76336
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt
>> @@ -0,0 +1,58 @@
>> +Spreadtrum ADI controller based on SPI framework
>
> "SPI framework" is not relevant to bindings.

OK, I will remove this in next version.

>
>> +
>> +ADI is the abbreviation of Anolog-Digital interface, which is used to access
>> +analog chip (such as PMIC) from digital chip. ADI controller follows the SPI
>> +framework for its hardware implementation is alike to SPI bus and its timing
>> +is compatile to SPI timing.
>> +
>> +ADI controller has 50 channels including 2 software read/write channels and
>> +48 hardware channels to access analog chip. For 2 software read/write 
>> channels,
>> +users should set ADI registers to access analog chip. For hardware channels,
>> +we can configure them to allow other hardware components to use it 
>> independently,
>> +which means we can just link one analog chip address to one hardware 
>> channel,
>> +then users can access the mapped analog chip address by this hardware 
>> channel
>> +triggered by hardware components instead of ADI software channels.
>> +
>> +Thus we introduce one property named "sprd,hw-channels" to configure 
>> hardware
>> +channels, the first value specifies the hardware channel id which is used to
>> +transfer data triggered by hardware automatically, and the second value 
>> specifies
>> +the analog chip address where user want to access by hardware components.
>> +
>> +Another hand since we have multi-subsystems will use unique ADI to access 
>> analog
>
> Drop "Another hand"

OK.

>
>> +chip, when one system is reading/writing data by ADI software channels, that
>> +should be under one hardware spinlock protection to prevent other systems 
>> from
>> +reading/writing data by ADI software channels at the same time, or two 
>> parallel
>> +routine of setting ADI registers will make ADI controller registers chaos to
>> +lead incorrect results. Then we need one hardware spinlock to synchronize 
>> between
>> +the multiple subsystems.
>> +
>> +Required properties:
>> +- compatible: Should be "sprd,sc9860-adi".
>> +- reg: Offset and length of ADI-SPI controller register space.
>> +- hwlocks: Reference to a phandle of a hwlock provider node.
>> +- hwlock-names: Reference to hwlock name strings defined in the same order
>> + as the hwlocks, should be "adi".
>> +- #address-cells: Number of cells required to define a chip select address
>> + on the ADI-SPI bus. Should be set to 1.
>> +- #size-cells: Size of cells required to define a chip select address size
>> + on the ADI-SPI bus. Should be set to 0.
>> +
>> +Optional properties:
>> +- sprd,hw-channels: The first value specifies the hardware channel id which
>> + is used to transfer data triggered by hardware automatically, and
>> + the second value specifies the analog chip address where user want
>> + to access by hardware components.
>
> Need to say this is an array of values up to ? channels.

OK. Will add in next version.

>
> I wonder if this should be a slave property. Is there a relationship

It is not a slave property, it is used to configure ADI controller to
support to access analog chip by hardware automatically.

> between the SPI address (i.e. chip select) and the "analog chip

I think they are not related. The "analog chip address" is like the
offset address of one SPI slave (analog chip can be recognized as one
SPI slave).

> address"? It sounds like the h/w channels are a protocol specific to a
> particular PMIC/MFD that this controller supports.

Yes. Very appreciated for your comments.

-- 
Baolin.wang
Best Regards

Re: [PATCH 01/12] mmc: dt-bindings: update Mediatek MMC bindings

[Chaotian Jing]

On Wed, 2017-09-13 at 09:10 -0500, Rob Herring wrote:
> On Tue, Sep 12, 2017 at 05:07:41PM +0800, Chaotian Jing wrote:
> > Change the comptiable for support of multi-platform
> > Add description for reg
> > Add description for source_cg
> > Add description for mediatek,latch-ck
> 
> This is at least the 3rd patch with exactly the same vague subject. 
> Please make the subject somewhat unique.
> 
Thx, will change the subject at next version
> > 
> > Signed-off-by: Chaotian Jing 
> > ---
> >  Documentation/devicetree/bindings/mmc/mtk-sd.txt | 13 ++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
> > b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > index 4182ea3..405cd06 100644
> > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > @@ -7,10 +7,15 @@ This file documents differences between the core 
> > properties in mmc.txt
> >  and the properties used by the msdc driver.
> >  
> >  Required properties:
> > -- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc"
> > +- compatible: value should be either of the following.
> > +   "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
> > +   "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> > +   "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> > +   "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> > +- reg: physical base address of the controller and length
> >  - interrupts: Should contain MSDC interrupt number
> > -- clocks: MSDC source clock, HCLK
> > -- clock-names: "source", "hclk"
> > +- clocks: MSDC source clock, HCLK, source_cg
> > +- clock-names: "source", "hclk", "source_cg"
> 
> All chips support source_cg? That's not backwards compatible for 
> existing compatible strings if the driver requires it.
Not all chips support source_cg, for chips which do not support
source_cg, no need source_cg here, and the driver will parse it
to know if current chip support it.
> 
> >  - pinctrl-names: should be "default", "state_uhs"
> >  - pinctrl-0: should contain default/high speed pin ctrl
> >  - pinctrl-1: should contain uhs mode pin ctrl
> > @@ -30,6 +35,8 @@ Optional properties:
> >  - mediatek,hs400-cmd-resp-sel-rising:  HS400 command response sample 
> > selection
> >If present,HS400 command responses are 
> > sampled on rising edges.
> >If not present,HS400 command responses 
> > are sampled on falling edges.
> > +- mediatek,latch-ck: Some projects do not support enhance_rx, need set 
> > correct latch-ck to avoid data crc
> 
> What's a project?
eg, MT2701
> 
> > +error caused by stop clock(fifo full)
> >  
> >  Examples:
> >  mmc0: mmc@1123 {
> > -- 
> > 1.8.1.1.dirty
> > 

Re: [PATCH 01/12] mmc: dt-bindings: update Mediatek MMC bindings

[Chaotian Jing]

On Wed, 2017-09-13 at 09:10 -0500, Rob Herring wrote:
> On Tue, Sep 12, 2017 at 05:07:41PM +0800, Chaotian Jing wrote:
> > Change the comptiable for support of multi-platform
> > Add description for reg
> > Add description for source_cg
> > Add description for mediatek,latch-ck
> 
> This is at least the 3rd patch with exactly the same vague subject. 
> Please make the subject somewhat unique.
> 
Thx, will change the subject at next version
> > 
> > Signed-off-by: Chaotian Jing 
> > ---
> >  Documentation/devicetree/bindings/mmc/mtk-sd.txt | 13 ++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
> > b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > index 4182ea3..405cd06 100644
> > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > @@ -7,10 +7,15 @@ This file documents differences between the core 
> > properties in mmc.txt
> >  and the properties used by the msdc driver.
> >  
> >  Required properties:
> > -- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc"
> > +- compatible: value should be either of the following.
> > +   "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
> > +   "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> > +   "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> > +   "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> > +- reg: physical base address of the controller and length
> >  - interrupts: Should contain MSDC interrupt number
> > -- clocks: MSDC source clock, HCLK
> > -- clock-names: "source", "hclk"
> > +- clocks: MSDC source clock, HCLK, source_cg
> > +- clock-names: "source", "hclk", "source_cg"
> 
> All chips support source_cg? That's not backwards compatible for 
> existing compatible strings if the driver requires it.
Not all chips support source_cg, for chips which do not support
source_cg, no need source_cg here, and the driver will parse it
to know if current chip support it.
> 
> >  - pinctrl-names: should be "default", "state_uhs"
> >  - pinctrl-0: should contain default/high speed pin ctrl
> >  - pinctrl-1: should contain uhs mode pin ctrl
> > @@ -30,6 +35,8 @@ Optional properties:
> >  - mediatek,hs400-cmd-resp-sel-rising:  HS400 command response sample 
> > selection
> >If present,HS400 command responses are 
> > sampled on rising edges.
> >If not present,HS400 command responses 
> > are sampled on falling edges.
> > +- mediatek,latch-ck: Some projects do not support enhance_rx, need set 
> > correct latch-ck to avoid data crc
> 
> What's a project?
eg, MT2701
> 
> > +error caused by stop clock(fifo full)
> >  
> >  Examples:
> >  mmc0: mmc@1123 {
> > -- 
> > 1.8.1.1.dirty
> > 

Re: [PATCH v2 2/2] spi: Add ADI driver for Spreadtrum platform

[Baolin Wang]

Hi Rob,

On 14 September 2017 at 03:45, Rob Herring  wrote:
> On Fri, Sep 08, 2017 at 04:33:42PM +0800, Baolin Wang wrote:
>> This patch adds ADI driver based on SPI framework for
>> Spreadtrum SC9860 platform.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>
> [...]
>
>> +++ b/drivers/spi/spi-sprd-adi.c
>> @@ -0,0 +1,419 @@
>> +/*
>> + * Copyright (C) 2017 Spreadtrum Communications Inc.
>> + *
>> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> Kernel code should generally not be MIT license.

OK. Will fix in next version.

>
> [...]
>
>> +static int sprd_adi_drain_fifo(struct sprd_adi *sadi)
>> +{
>> + u32 timeout = ADI_FIFO_DRAIN_TIMEOUT;
>> + u32 sts;
>> +
>> + do {
>> + sts = readl_relaxed(sadi->base + REG_ADI_ARM_FIFO_STS);
>> + if (sts & BIT_FIFO_EMPTY)
>> + break;
>> +
>> + cpu_relax();
>> + } while (--timeout);
>
> You can use readl_poll_timeout.

The readl_poll_timeout() function might be sleep, but we can not sleep
when reading/writing data through ADI controller, since the routine is
under hardware spinlock protection. Moreover it is usually very quick
to jump the loop and we no need to sleep here.

>
>> +
>> + if (timeout == 0) {
>> + dev_err(sadi->dev, "drain write fifo timeout\n");
>> + return -EBUSY;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int sprd_adi_fifo_is_full(struct sprd_adi *sadi)
>> +{
>> + return readl_relaxed(sadi->base + REG_ADI_ARM_FIFO_STS) & 
>> BIT_FIFO_FULL;
>> +}
>> +
>> +static int sprd_adi_read(struct sprd_adi *sadi, u32 reg_paddr, u32 
>> *read_val)
>> +{
>> + int read_timeout = ADI_READ_TIMEOUT;
>> + u32 val, rd_addr;
>> +
>> + /*
>> +  * Set the physical register address need to read into RD_CMD register,
>> +  * then ADI controller will start to transfer automatically.
>> +  */
>> + writel_relaxed(reg_paddr, sadi->base + REG_ADI_RD_CMD);
>> +
>> + /*
>> +  * Wait read operation complete, the BIT_RD_CMD_BUSY will be set
>> +  * simultaneously when writing read command to register, and the
>> +  * BIT_RD_CMD_BUSY will be cleared after the read operation is
>> +  * completed.
>> +  */
>> + do {
>> + val = readl_relaxed(sadi->base + REG_ADI_RD_DATA);
>> + if (!(val & BIT_RD_CMD_BUSY))
>> + break;
>> +
>> + cpu_relax();
>> + } while (--read_timeout);
>
> readl_poll_timeout

The same reason as above. Thanks for your comments.

-- 
Baolin.wang
Best Regards

Re: [PATCH v2 2/2] spi: Add ADI driver for Spreadtrum platform

[Baolin Wang]

Hi Rob,

On 14 September 2017 at 03:45, Rob Herring  wrote:
> On Fri, Sep 08, 2017 at 04:33:42PM +0800, Baolin Wang wrote:
>> This patch adds ADI driver based on SPI framework for
>> Spreadtrum SC9860 platform.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>
> [...]
>
>> +++ b/drivers/spi/spi-sprd-adi.c
>> @@ -0,0 +1,419 @@
>> +/*
>> + * Copyright (C) 2017 Spreadtrum Communications Inc.
>> + *
>> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> Kernel code should generally not be MIT license.

OK. Will fix in next version.

>
> [...]
>
>> +static int sprd_adi_drain_fifo(struct sprd_adi *sadi)
>> +{
>> + u32 timeout = ADI_FIFO_DRAIN_TIMEOUT;
>> + u32 sts;
>> +
>> + do {
>> + sts = readl_relaxed(sadi->base + REG_ADI_ARM_FIFO_STS);
>> + if (sts & BIT_FIFO_EMPTY)
>> + break;
>> +
>> + cpu_relax();
>> + } while (--timeout);
>
> You can use readl_poll_timeout.

The readl_poll_timeout() function might be sleep, but we can not sleep
when reading/writing data through ADI controller, since the routine is
under hardware spinlock protection. Moreover it is usually very quick
to jump the loop and we no need to sleep here.

>
>> +
>> + if (timeout == 0) {
>> + dev_err(sadi->dev, "drain write fifo timeout\n");
>> + return -EBUSY;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int sprd_adi_fifo_is_full(struct sprd_adi *sadi)
>> +{
>> + return readl_relaxed(sadi->base + REG_ADI_ARM_FIFO_STS) & 
>> BIT_FIFO_FULL;
>> +}
>> +
>> +static int sprd_adi_read(struct sprd_adi *sadi, u32 reg_paddr, u32 
>> *read_val)
>> +{
>> + int read_timeout = ADI_READ_TIMEOUT;
>> + u32 val, rd_addr;
>> +
>> + /*
>> +  * Set the physical register address need to read into RD_CMD register,
>> +  * then ADI controller will start to transfer automatically.
>> +  */
>> + writel_relaxed(reg_paddr, sadi->base + REG_ADI_RD_CMD);
>> +
>> + /*
>> +  * Wait read operation complete, the BIT_RD_CMD_BUSY will be set
>> +  * simultaneously when writing read command to register, and the
>> +  * BIT_RD_CMD_BUSY will be cleared after the read operation is
>> +  * completed.
>> +  */
>> + do {
>> + val = readl_relaxed(sadi->base + REG_ADI_RD_DATA);
>> + if (!(val & BIT_RD_CMD_BUSY))
>> + break;
>> +
>> + cpu_relax();
>> + } while (--read_timeout);
>
> readl_poll_timeout

The same reason as above. Thanks for your comments.

-- 
Baolin.wang
Best Regards

Re: linux-next: build warning after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

On Fri, 8 Sep 2017 09:25:45 +1000 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> kernel/signal.c: In function 'C_SYSC_rt_sigaction':
> kernel/signal.c:3405:19: warning: unused variable 'mask' [-Wunused-variable]
>compat_sigset_t mask;
>^
> 
> Introduced by commit
> 
>   fc271087ebcb ("signal: replace sigset_to_compat() with put_compat_sigset()")

I am still getting this warning ...
-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

On Fri, 8 Sep 2017 09:25:45 +1000 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> kernel/signal.c: In function 'C_SYSC_rt_sigaction':
> kernel/signal.c:3405:19: warning: unused variable 'mask' [-Wunused-variable]
>compat_sigset_t mask;
>^
> 
> Introduced by commit
> 
>   fc271087ebcb ("signal: replace sigset_to_compat() with put_compat_sigset()")

I am still getting this warning ...
-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 RESEND 0/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

[Baoquan He]

Hi all,

PING!

Do anyone has any suggestion about this issue? This bug blocks SGI
system's boot, KASLR has to be disabled on SGI system if they want to
run tests.

Thanks
Baoquan

On 09/07/17 at 03:42pm, Baoquan He wrote:
> This is v2 post RESEND. Add Mike's Acked-by to patch 2/2 as he suggested
> in private mail. And update patches log slightly.
> 
> This patchset is trying to fix a bug that SGI UV system casually hang
> during boot with KASLR enabled. The root cause is that mm KASLR adapts
> size of the direct mapping section only based on the system RAM size.
> Then later when map SGI UV MMIOH region into the direct mapping during
> rest_init() invocation, it might go beyond of the directing mapping
> section and step into VMALLOC or VMEMMAP area, then BUG_ON triggered.
> 
> The fix is adding a helper function is_early_uv_system to check UV system
> earlier, then call the helper function in kernel_randomize_memory() to
> check if it's a SGI UV system, if yes, we keep the size of direct mapping
> section to be 64TB just as nokslr.
> 
> With this fix, SGI UV system can have 64TB direct mapping size always,
> and the starting address of direct mapping/vmalloc/vmemmap and the padding
> between them can still be randomized to enhance the system security.
> 
> v1->v2:
> 1. Mike suggested making is_early_uv_system() an inline function and be
> put in include/asm/uv/uv.h so that they can adjust them easier in the
> future.
> 
> 2. Split the v1 code into uv part and mm KASLR part as Mike suggested.
> 
> Baoquan He (2):
>   x86/UV: Introduce a helper function to check UV system at earlier
> stage
>   x86/mm/KASLR: Do not adapt the size of the direct mapping section for
> SGI UV system
> 
>  arch/x86/include/asm/uv/uv.h | 6 ++
>  arch/x86/mm/kaslr.c  | 3 ++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> -- 
> 2.5.5
> 

Re: [PATCH v2 RESEND 0/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

[Baoquan He]

Hi all,

PING!

Do anyone has any suggestion about this issue? This bug blocks SGI
system's boot, KASLR has to be disabled on SGI system if they want to
run tests.

Thanks
Baoquan

On 09/07/17 at 03:42pm, Baoquan He wrote:
> This is v2 post RESEND. Add Mike's Acked-by to patch 2/2 as he suggested
> in private mail. And update patches log slightly.
> 
> This patchset is trying to fix a bug that SGI UV system casually hang
> during boot with KASLR enabled. The root cause is that mm KASLR adapts
> size of the direct mapping section only based on the system RAM size.
> Then later when map SGI UV MMIOH region into the direct mapping during
> rest_init() invocation, it might go beyond of the directing mapping
> section and step into VMALLOC or VMEMMAP area, then BUG_ON triggered.
> 
> The fix is adding a helper function is_early_uv_system to check UV system
> earlier, then call the helper function in kernel_randomize_memory() to
> check if it's a SGI UV system, if yes, we keep the size of direct mapping
> section to be 64TB just as nokslr.
> 
> With this fix, SGI UV system can have 64TB direct mapping size always,
> and the starting address of direct mapping/vmalloc/vmemmap and the padding
> between them can still be randomized to enhance the system security.
> 
> v1->v2:
> 1. Mike suggested making is_early_uv_system() an inline function and be
> put in include/asm/uv/uv.h so that they can adjust them easier in the
> future.
> 
> 2. Split the v1 code into uv part and mm KASLR part as Mike suggested.
> 
> Baoquan He (2):
>   x86/UV: Introduce a helper function to check UV system at earlier
> stage
>   x86/mm/KASLR: Do not adapt the size of the direct mapping section for
> SGI UV system
> 
>  arch/x86/include/asm/uv/uv.h | 6 ++
>  arch/x86/mm/kaslr.c  | 3 ++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> -- 
> 2.5.5
> 

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

[Al Viro]

On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote:

> Android triggers umount(2) by init process, which is definitely not a kernel
> thread. But, we've seen some kernel panics which say umount(2) was succeeded,
> but ext4 triggered a kernel panic due to EIO after then like below. I'm also
> not sure task_work_run() would be also safe enoughly. May I ask where I can
> find sys_umount() calls task_work_run()?

ret_{fast,slow}_syscall ->
slow_work_pending ->
do_work_pending() ->
tracehook_notify_resume() ->
task_work_run()

It's not sys_umount() (or any other sys_...()) - it's syscall dispatcher after
having called one of those and before returning to userland.  What is guaranteed
is that after successful task_work_add() the damn thing will be run in context
of originating process before it returns from syscall.  So any subsequent
syscalls from that process are guaranteed to happen after the work has run.
The same happens if the process exits rather than returns to userland 
(do_exit() ->
exit_task_work() -> task_work_run()), but for that you would need it to die in
umount(2) (e.g. get kill -9 delivered on the way out).

Please, check if you are seeing task_work_add() failure in there and if you do,
I would like to see a stack trace.  IOW, slap WARN_ON(1); right after
if (!task_work_add(task, >mnt_rcu, true))
return;
and see what (if anything) gets printed.

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

[Al Viro]

On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote:

> Android triggers umount(2) by init process, which is definitely not a kernel
> thread. But, we've seen some kernel panics which say umount(2) was succeeded,
> but ext4 triggered a kernel panic due to EIO after then like below. I'm also
> not sure task_work_run() would be also safe enoughly. May I ask where I can
> find sys_umount() calls task_work_run()?

ret_{fast,slow}_syscall ->
slow_work_pending ->
do_work_pending() ->
tracehook_notify_resume() ->
task_work_run()

It's not sys_umount() (or any other sys_...()) - it's syscall dispatcher after
having called one of those and before returning to userland.  What is guaranteed
is that after successful task_work_add() the damn thing will be run in context
of originating process before it returns from syscall.  So any subsequent
syscalls from that process are guaranteed to happen after the work has run.
The same happens if the process exits rather than returns to userland 
(do_exit() ->
exit_task_work() -> task_work_run()), but for that you would need it to die in
umount(2) (e.g. get kill -9 delivered on the way out).

Please, check if you are seeing task_work_add() failure in there and if you do,
I would like to see a stack trace.  IOW, slap WARN_ON(1); right after
if (!task_work_add(task, >mnt_rcu, true))
return;
and see what (if anything) gets printed.

[PATCH v9 2/4] ARM: dts: rockchip: add RGA device node for RK3288

[Jacob Chen]

This patch add the RGA dt config of rk3288 SoC.

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
---
 arch/arm/boot/dts/rk3288.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 595d395..ca6c63a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -953,6 +953,17 @@
status = "okay";
};
 
+   rga: rga@ff92 {
+   compatible = "rockchip,rk3288-rga";
+   reg = <0xff92 0x180>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA>;
+   clock-names = "aclk", "hclk", "sclk";
+   power-domains = < RK3288_PD_VIO>;
+   resets = < SRST_RGA_CORE>, < SRST_RGA_AXI>, < 
SRST_RGA_AHB>;
+   reset-names = "core", "axi", "ahb";
+   };
+
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0xff93 0x19c>;
-- 
2.7.4

[PATCH v9 2/4] ARM: dts: rockchip: add RGA device node for RK3288

[Jacob Chen]

This patch add the RGA dt config of rk3288 SoC.

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
---
 arch/arm/boot/dts/rk3288.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 595d395..ca6c63a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -953,6 +953,17 @@
status = "okay";
};
 
+   rga: rga@ff92 {
+   compatible = "rockchip,rk3288-rga";
+   reg = <0xff92 0x180>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA>;
+   clock-names = "aclk", "hclk", "sclk";
+   power-domains = < RK3288_PD_VIO>;
+   resets = < SRST_RGA_CORE>, < SRST_RGA_AXI>, < 
SRST_RGA_AHB>;
+   reset-names = "core", "axi", "ahb";
+   };
+
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0xff93 0x19c>;
-- 
2.7.4

[PATCH v9 1/4] rockchip/rga: v4l2 m2m support

[Jacob Chen]

Rockchip RGA is a separate 2D raster graphic acceleration unit. It
accelerates 2D graphics operations, such as point/line drawing, image
scaling, rotation, BitBLT, alpha blending and image blur/sharpness

The drvier is mostly based on s5p-g2d v4l2 m2m driver
And supports various operations from the rendering pipeline.
 - copy
 - fast solid color fill
 - rotation
 - flip
 - alpha blending

The code in rga-hw.c is used to configure regs according to operations
The code in rga-buf.c is used to create private mmu table for RGA.

changes in V7:
- fix some warning reported by "checkpatch --strict"

Signed-off-by: Jacob Chen 
---
 drivers/media/platform/Kconfig|   11 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/rockchip-rga/Makefile  |3 +
 drivers/media/platform/rockchip-rga/rga-buf.c |  156 
 drivers/media/platform/rockchip-rga/rga-hw.c  |  435 +++
 drivers/media/platform/rockchip-rga/rga-hw.h  |  437 +++
 drivers/media/platform/rockchip-rga/rga.c | 1030 +
 drivers/media/platform/rockchip-rga/rga.h |  110 +++
 8 files changed, 2184 insertions(+)
 create mode 100644 drivers/media/platform/rockchip-rga/Makefile
 create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
 create mode 100644 drivers/media/platform/rockchip-rga/rga.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49..9b79350 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -458,6 +458,17 @@ config VIDEO_RENESAS_VSP1
  To compile this driver as a module, choose M here: the module
  will be called vsp1.
 
+config VIDEO_ROCKCHIP_RGA
+   tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
+   select VIDEOBUF2_DMA_SG
+   select V4L2_MEM2MEM_DEV
+   default n
+   ---help---
+ This is a v4l2 driver for Rockchip SOC RGA2
+ 2d graphics accelerator.
+
 config VIDEO_TI_VPE
tristate "TI VPE (Video Processing Engine) driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946..06039c3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -62,6 +62,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)  += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1/
 
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA)   += rockchip-rga/
+
 obj-y  += omap/
 
 obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/
diff --git a/drivers/media/platform/rockchip-rga/Makefile 
b/drivers/media/platform/rockchip-rga/Makefile
new file mode 100644
index 000..92fe254
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/Makefile
@@ -0,0 +1,3 @@
+rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
+
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c 
b/drivers/media/platform/rockchip-rga/rga-buf.c
new file mode 100644
index 000..373c36f
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/rga-buf.c
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2017 Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Jacob Chen 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rga-hw.h"
+#include "rga.h"
+
+static int
+rga_queue_setup(struct vb2_queue *vq,
+   unsigned int *nbuffers, unsigned int *nplanes,
+   unsigned int sizes[], struct device *alloc_devs[])
+{
+   struct rga_ctx *ctx = vb2_get_drv_priv(vq);
+   struct rga_frame *f = rga_get_frame(ctx, vq->type);
+
+   if (IS_ERR(f))
+   return PTR_ERR(f);
+
+   if (*nplanes)
+   return sizes[0] < f->size ? -EINVAL : 0;
+
+   sizes[0] = f->size;
+   *nplanes = 1;
+
+   return 0;
+}
+
+static int rga_buf_prepare(struct vb2_buffer *vb)
+{
+   struct rga_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
+   struct rga_frame *f = rga_get_frame(ctx, vb->vb2_queue->type);
+
+   if (IS_ERR(f))
+   return PTR_ERR(f);
+
+   vb2_set_plane_payload(vb, 0, f->size);
+
+   

[PATCH v9 1/4] rockchip/rga: v4l2 m2m support

[Jacob Chen]

Rockchip RGA is a separate 2D raster graphic acceleration unit. It
accelerates 2D graphics operations, such as point/line drawing, image
scaling, rotation, BitBLT, alpha blending and image blur/sharpness

The drvier is mostly based on s5p-g2d v4l2 m2m driver
And supports various operations from the rendering pipeline.
 - copy
 - fast solid color fill
 - rotation
 - flip
 - alpha blending

The code in rga-hw.c is used to configure regs according to operations
The code in rga-buf.c is used to create private mmu table for RGA.

changes in V7:
- fix some warning reported by "checkpatch --strict"

Signed-off-by: Jacob Chen 
---
 drivers/media/platform/Kconfig|   11 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/rockchip-rga/Makefile  |3 +
 drivers/media/platform/rockchip-rga/rga-buf.c |  156 
 drivers/media/platform/rockchip-rga/rga-hw.c  |  435 +++
 drivers/media/platform/rockchip-rga/rga-hw.h  |  437 +++
 drivers/media/platform/rockchip-rga/rga.c | 1030 +
 drivers/media/platform/rockchip-rga/rga.h |  110 +++
 8 files changed, 2184 insertions(+)
 create mode 100644 drivers/media/platform/rockchip-rga/Makefile
 create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
 create mode 100644 drivers/media/platform/rockchip-rga/rga.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49..9b79350 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -458,6 +458,17 @@ config VIDEO_RENESAS_VSP1
  To compile this driver as a module, choose M here: the module
  will be called vsp1.
 
+config VIDEO_ROCKCHIP_RGA
+   tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
+   select VIDEOBUF2_DMA_SG
+   select V4L2_MEM2MEM_DEV
+   default n
+   ---help---
+ This is a v4l2 driver for Rockchip SOC RGA2
+ 2d graphics accelerator.
+
 config VIDEO_TI_VPE
tristate "TI VPE (Video Processing Engine) driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946..06039c3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -62,6 +62,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)  += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1/
 
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA)   += rockchip-rga/
+
 obj-y  += omap/
 
 obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/
diff --git a/drivers/media/platform/rockchip-rga/Makefile 
b/drivers/media/platform/rockchip-rga/Makefile
new file mode 100644
index 000..92fe254
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/Makefile
@@ -0,0 +1,3 @@
+rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
+
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c 
b/drivers/media/platform/rockchip-rga/rga-buf.c
new file mode 100644
index 000..373c36f
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/rga-buf.c
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2017 Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Jacob Chen 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rga-hw.h"
+#include "rga.h"
+
+static int
+rga_queue_setup(struct vb2_queue *vq,
+   unsigned int *nbuffers, unsigned int *nplanes,
+   unsigned int sizes[], struct device *alloc_devs[])
+{
+   struct rga_ctx *ctx = vb2_get_drv_priv(vq);
+   struct rga_frame *f = rga_get_frame(ctx, vq->type);
+
+   if (IS_ERR(f))
+   return PTR_ERR(f);
+
+   if (*nplanes)
+   return sizes[0] < f->size ? -EINVAL : 0;
+
+   sizes[0] = f->size;
+   *nplanes = 1;
+
+   return 0;
+}
+
+static int rga_buf_prepare(struct vb2_buffer *vb)
+{
+   struct rga_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
+   struct rga_frame *f = rga_get_frame(ctx, vb->vb2_queue->type);
+
+   if (IS_ERR(f))
+   return PTR_ERR(f);
+
+   vb2_set_plane_payload(vb, 0, f->size);
+
+   return 0;
+}
+
+static void 

Re: [PATCH v9 0/4] Add Rockchip RGA V4l2 support

[Jacob Chen]

Hi all,


2017-09-14 9:19 GMT+08:00 Jacob Chen :
> This patch series add a v4l2 m2m drvier for rockchip RGA direct rendering 
> based 2d graphics acceleration module.
>
> Recently I tried to add protduff support for gstreamer on rockchip platform, 
> and i found that API
> were not very suitable for my purpose.
> It shouldn't go upstream until we can figure out what people need,
>
> change in V9:
> - remove protduff things
> - test with the latest v4l2-compliance
>
> change in V8:
> - remove protduff things
>
> change in V6,V7:
> - correct warning in checkpatch.pl
>
> change in V5:
> - v4l2-compliance: handle invalid pxielformat
> - v4l2-compliance: add subscribe_event
> - add colorspace support
>
> change in V4:
> - document the controls.
> - change according to Hans's comments
>
> change in V3:
> - rename the controls.
> - add pm_runtime support.
> - enable node by default.
> - correct spelling in documents.
>
> change in V2:
> - generalize the controls.
> - map buffers (10-50 us) in every cmd-run rather than in buffer-import to 
> avoid get_free_pages failed on
> actively used systems.
> - remove status in dt-bindings examples.
>
> Jacob Chen (4):
>   rockchip/rga: v4l2 m2m support
>   ARM: dts: rockchip: add RGA device node for RK3288
>   arm64: dts: rockchip: add RGA device node for RK3399
>   dt-bindings: Document the Rockchip RGA bindings
>
>  .../devicetree/bindings/media/rockchip-rga.txt |   33 +
>  arch/arm/boot/dts/rk3288.dtsi  |   11 +
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi   |   11 +
>  drivers/media/platform/Kconfig |   11 +
>  drivers/media/platform/Makefile|2 +
>  drivers/media/platform/rockchip-rga/Makefile   |3 +
>  drivers/media/platform/rockchip-rga/rga-buf.c  |  156 +++
>  drivers/media/platform/rockchip-rga/rga-hw.c   |  435 +
>  drivers/media/platform/rockchip-rga/rga-hw.h   |  437 +
>  drivers/media/platform/rockchip-rga/rga.c  | 1030 
> 
>  drivers/media/platform/rockchip-rga/rga.h  |  110 +++
>  11 files changed, 2239 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h
>
> --
> 2.7.4
>


v4l2-compliance SHA   : d7c41e2576c09f37b33fe8bf2e38615703086045

Driver Info:
Driver name   : rockchip-rga
Card type : rockchip-rga
Bus info  : platform:rga
Driver version: 4.13.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 0

Format ioctls:
  

Re: [PATCH v9 0/4] Add Rockchip RGA V4l2 support

[Jacob Chen]

Hi all,


2017-09-14 9:19 GMT+08:00 Jacob Chen :
> This patch series add a v4l2 m2m drvier for rockchip RGA direct rendering 
> based 2d graphics acceleration module.
>
> Recently I tried to add protduff support for gstreamer on rockchip platform, 
> and i found that API
> were not very suitable for my purpose.
> It shouldn't go upstream until we can figure out what people need,
>
> change in V9:
> - remove protduff things
> - test with the latest v4l2-compliance
>
> change in V8:
> - remove protduff things
>
> change in V6,V7:
> - correct warning in checkpatch.pl
>
> change in V5:
> - v4l2-compliance: handle invalid pxielformat
> - v4l2-compliance: add subscribe_event
> - add colorspace support
>
> change in V4:
> - document the controls.
> - change according to Hans's comments
>
> change in V3:
> - rename the controls.
> - add pm_runtime support.
> - enable node by default.
> - correct spelling in documents.
>
> change in V2:
> - generalize the controls.
> - map buffers (10-50 us) in every cmd-run rather than in buffer-import to 
> avoid get_free_pages failed on
> actively used systems.
> - remove status in dt-bindings examples.
>
> Jacob Chen (4):
>   rockchip/rga: v4l2 m2m support
>   ARM: dts: rockchip: add RGA device node for RK3288
>   arm64: dts: rockchip: add RGA device node for RK3399
>   dt-bindings: Document the Rockchip RGA bindings
>
>  .../devicetree/bindings/media/rockchip-rga.txt |   33 +
>  arch/arm/boot/dts/rk3288.dtsi  |   11 +
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi   |   11 +
>  drivers/media/platform/Kconfig |   11 +
>  drivers/media/platform/Makefile|2 +
>  drivers/media/platform/rockchip-rga/Makefile   |3 +
>  drivers/media/platform/rockchip-rga/rga-buf.c  |  156 +++
>  drivers/media/platform/rockchip-rga/rga-hw.c   |  435 +
>  drivers/media/platform/rockchip-rga/rga-hw.h   |  437 +
>  drivers/media/platform/rockchip-rga/rga.c  | 1030 
> 
>  drivers/media/platform/rockchip-rga/rga.h  |  110 +++
>  11 files changed, 2239 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h
>
> --
> 2.7.4
>


v4l2-compliance SHA   : d7c41e2576c09f37b33fe8bf2e38615703086045

Driver Info:
Driver name   : rockchip-rga
Card type : rockchip-rga
Bus info  : platform:rga
Driver version: 4.13.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 0

Format ioctls:
test 

[PATCH v9 4/4] dt-bindings: Document the Rockchip RGA bindings

[Jacob Chen]

Add DT bindings documentation for Rockchip RGA

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/rockchip-rga.txt | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt

diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt 
b/Documentation/devicetree/bindings/media/rockchip-rga.txt
new file mode 100644
index 000..fd5276a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt
@@ -0,0 +1,33 @@
+device-tree bindings for rockchip 2D raster graphic acceleration controller 
(RGA)
+
+RGA is a standalone 2D raster graphic acceleration unit. It accelerates 2D
+graphics operations, such as point/line drawing, image scaling, rotation,
+BitBLT, alpha blending and image blur/sharpness.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-rga";
+   "rockchip,rk3399-rga";
+
+- interrupts: RGA interrupt specifier.
+
+- clocks: phandle to RGA sclk/hclk/aclk clocks
+
+- clock-names: should be "aclk", "hclk" and "sclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: should be "core", "axi" and "ahb"
+
+Example:
+SoC-specific DT entry:
+   rga: rga@ff68 {
+   compatible = "rockchip,rk3399-rga";
+   reg = <0xff68 0x1>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA_CORE>;
+   clock-names = "aclk", "hclk", "sclk";
+
+   resets = < SRST_RGA_CORE>, < SRST_A_RGA>, < 
SRST_H_RGA>;
+   reset-names = "core, "axi", "ahb";
+   };
-- 
2.7.4

[PATCH v9 4/4] dt-bindings: Document the Rockchip RGA bindings

[Jacob Chen]

Add DT bindings documentation for Rockchip RGA

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/rockchip-rga.txt | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt

diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt 
b/Documentation/devicetree/bindings/media/rockchip-rga.txt
new file mode 100644
index 000..fd5276a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt
@@ -0,0 +1,33 @@
+device-tree bindings for rockchip 2D raster graphic acceleration controller 
(RGA)
+
+RGA is a standalone 2D raster graphic acceleration unit. It accelerates 2D
+graphics operations, such as point/line drawing, image scaling, rotation,
+BitBLT, alpha blending and image blur/sharpness.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-rga";
+   "rockchip,rk3399-rga";
+
+- interrupts: RGA interrupt specifier.
+
+- clocks: phandle to RGA sclk/hclk/aclk clocks
+
+- clock-names: should be "aclk", "hclk" and "sclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: should be "core", "axi" and "ahb"
+
+Example:
+SoC-specific DT entry:
+   rga: rga@ff68 {
+   compatible = "rockchip,rk3399-rga";
+   reg = <0xff68 0x1>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA_CORE>;
+   clock-names = "aclk", "hclk", "sclk";
+
+   resets = < SRST_RGA_CORE>, < SRST_A_RGA>, < 
SRST_H_RGA>;
+   reset-names = "core, "axi", "ahb";
+   };
-- 
2.7.4

[PATCH v9 0/4] Add Rockchip RGA V4l2 support

[Jacob Chen]

This patch series add a v4l2 m2m drvier for rockchip RGA direct rendering based 
2d graphics acceleration module.

Recently I tried to add protduff support for gstreamer on rockchip platform, 
and i found that API 
were not very suitable for my purpose. 
It shouldn't go upstream until we can figure out what people need, 

change in V9:
- remove protduff things
- test with the latest v4l2-compliance

change in V8:
- remove protduff things

change in V6,V7:
- correct warning in checkpatch.pl

change in V5:
- v4l2-compliance: handle invalid pxielformat 
- v4l2-compliance: add subscribe_event
- add colorspace support

change in V4:
- document the controls.
- change according to Hans's comments

change in V3:
- rename the controls.
- add pm_runtime support.
- enable node by default.
- correct spelling in documents.

change in V2:
- generalize the controls.
- map buffers (10-50 us) in every cmd-run rather than in buffer-import to avoid 
get_free_pages failed on
actively used systems.
- remove status in dt-bindings examples.

Jacob Chen (4):
  rockchip/rga: v4l2 m2m support
  ARM: dts: rockchip: add RGA device node for RK3288
  arm64: dts: rockchip: add RGA device node for RK3399
  dt-bindings: Document the Rockchip RGA bindings

 .../devicetree/bindings/media/rockchip-rga.txt |   33 +
 arch/arm/boot/dts/rk3288.dtsi  |   11 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |   11 +
 drivers/media/platform/Kconfig |   11 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/rockchip-rga/Makefile   |3 +
 drivers/media/platform/rockchip-rga/rga-buf.c  |  156 +++
 drivers/media/platform/rockchip-rga/rga-hw.c   |  435 +
 drivers/media/platform/rockchip-rga/rga-hw.h   |  437 +
 drivers/media/platform/rockchip-rga/rga.c  | 1030 
 drivers/media/platform/rockchip-rga/rga.h  |  110 +++
 11 files changed, 2239 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
 create mode 100644 drivers/media/platform/rockchip-rga/Makefile
 create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
 create mode 100644 drivers/media/platform/rockchip-rga/rga.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga.h

-- 
2.7.4

[PATCH v9 0/4] Add Rockchip RGA V4l2 support

[Jacob Chen]

This patch series add a v4l2 m2m drvier for rockchip RGA direct rendering based 
2d graphics acceleration module.

Recently I tried to add protduff support for gstreamer on rockchip platform, 
and i found that API 
were not very suitable for my purpose. 
It shouldn't go upstream until we can figure out what people need, 

change in V9:
- remove protduff things
- test with the latest v4l2-compliance

change in V8:
- remove protduff things

change in V6,V7:
- correct warning in checkpatch.pl

change in V5:
- v4l2-compliance: handle invalid pxielformat 
- v4l2-compliance: add subscribe_event
- add colorspace support

change in V4:
- document the controls.
- change according to Hans's comments

change in V3:
- rename the controls.
- add pm_runtime support.
- enable node by default.
- correct spelling in documents.

change in V2:
- generalize the controls.
- map buffers (10-50 us) in every cmd-run rather than in buffer-import to avoid 
get_free_pages failed on
actively used systems.
- remove status in dt-bindings examples.

Jacob Chen (4):
  rockchip/rga: v4l2 m2m support
  ARM: dts: rockchip: add RGA device node for RK3288
  arm64: dts: rockchip: add RGA device node for RK3399
  dt-bindings: Document the Rockchip RGA bindings

 .../devicetree/bindings/media/rockchip-rga.txt |   33 +
 arch/arm/boot/dts/rk3288.dtsi  |   11 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |   11 +
 drivers/media/platform/Kconfig |   11 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/rockchip-rga/Makefile   |3 +
 drivers/media/platform/rockchip-rga/rga-buf.c  |  156 +++
 drivers/media/platform/rockchip-rga/rga-hw.c   |  435 +
 drivers/media/platform/rockchip-rga/rga-hw.h   |  437 +
 drivers/media/platform/rockchip-rga/rga.c  | 1030 
 drivers/media/platform/rockchip-rga/rga.h  |  110 +++
 11 files changed, 2239 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
 create mode 100644 drivers/media/platform/rockchip-rga/Makefile
 create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
 create mode 100644 drivers/media/platform/rockchip-rga/rga.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga.h

-- 
2.7.4