[PATCH] iommu/ipmmu-vmsa: Use iommu_device_sysfs_add()/remove()

[Magnus Damm]

From: Magnus Damm 

Extend the driver to make use of iommu_device_sysfs_add()/remove()
functions to hook up initial sysfs support.

Suggested-by: Joerg Roedel 
Signed-off-by: Magnus Damm 
---

 Applies on top of next-20170817

 drivers/iommu/ipmmu-vmsa.c |6 ++
 1 file changed, 6 insertions(+)

--- 0001/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-08-21 14:40:13.940607110 +0900
@@ -953,6 +953,11 @@ static int ipmmu_probe(struct platform_d
 
ipmmu_device_reset(mmu);
 
+   ret = iommu_device_sysfs_add(>iommu, >dev, NULL,
+dev_name(>dev));
+   if (ret)
+   return ret;
+
iommu_device_set_ops(>iommu, _ops);
iommu_device_set_fwnode(>iommu, >dev.of_node->fwnode);
 
@@ -975,6 +980,7 @@ static int ipmmu_remove(struct platform_
 {
struct ipmmu_vmsa_device *mmu = platform_get_drvdata(pdev);
 
+   iommu_device_sysfs_remove(>iommu);
iommu_device_unregister(>iommu);
 
 #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)

[PATCH] iommu/ipmmu-vmsa: Use iommu_device_sysfs_add()/remove()

[Magnus Damm]

From: Magnus Damm 

Extend the driver to make use of iommu_device_sysfs_add()/remove()
functions to hook up initial sysfs support.

Suggested-by: Joerg Roedel 
Signed-off-by: Magnus Damm 
---

 Applies on top of next-20170817

 drivers/iommu/ipmmu-vmsa.c |6 ++
 1 file changed, 6 insertions(+)

--- 0001/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-08-21 14:40:13.940607110 +0900
@@ -953,6 +953,11 @@ static int ipmmu_probe(struct platform_d
 
ipmmu_device_reset(mmu);
 
+   ret = iommu_device_sysfs_add(>iommu, >dev, NULL,
+dev_name(>dev));
+   if (ret)
+   return ret;
+
iommu_device_set_ops(>iommu, _ops);
iommu_device_set_fwnode(>iommu, >dev.of_node->fwnode);
 
@@ -975,6 +980,7 @@ static int ipmmu_remove(struct platform_
 {
struct ipmmu_vmsa_device *mmu = platform_get_drvdata(pdev);
 
+   iommu_device_sysfs_remove(>iommu);
iommu_device_unregister(>iommu);
 
 #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)

Re: [PATCH v3 01/13] mpt3sas: Update MPI Header

[Suganath Prabu Subramani]

Hi James,
we have fixed the sparse warnings associated with this patch set and
posting V4 of mpt3sas patches soon. We are also working on sparse
error/warnings that existed before this patch set and we ll be posting
it separately.

Thanks,
Suganath Prabu S

On Wed, Aug 9, 2017 at 2:48 AM, J Freyensee
 wrote:
>
>
> Looks like your header has a white space error:
>
> Applying: mpt3sas: Update MPI Header
> .git/rebase-apply/patch:1452: new blank line at EOF.
> +
>
> Also, FYI, this project has a lot of sparse errors that look like existed
> before your patchset.  As your patchset touches a few of the files that
> have sparse warnings (such as mpt3sas_base.c, mpt3sas_scsih.c, etc), maybe
> you'll want to investigate fixing these things?
>
>
> [mainline-linux]$ make C=1
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   CHK scripts/mod/devicetable-offsets.h
>   CHK include/generated/compile.h
>   AR  drivers/scsi/mpt3sas/built-in.o
>   CHECK   drivers/scsi/mpt3sas/mpt3sas_base.c
> drivers/scsi/mpt3sas/mpt3sas_base.c:861:42: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:861:42:expected unsigned short
> [unsigned] [usertype] Event
> drivers/scsi/mpt3sas/mpt3sas_base.c:861:42:got restricted __le16
> [usertype] Event
> drivers/scsi/mpt3sas/mpt3sas_base.c:862:49: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:862:49:expected unsigned int
> [unsigned] [usertype] EventContext
> drivers/scsi/mpt3sas/mpt3sas_base.c:862:49:got restricted __le32
> [usertype] EventContext
> drivers/scsi/mpt3sas/mpt3sas_base.c:1080:64: warning: incorrect type in
> argument 2 (different address spaces)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1080:64:expected void volatile
> [noderef] *addr
> drivers/scsi/mpt3sas/mpt3sas_base.c:1080:64:got unsigned long long
> [usertype] *
> drivers/scsi/mpt3sas/mpt3sas_base.c:1129:52: warning: incorrect type in
> argument 2 (different address spaces)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1129:52:expected void volatile
> [noderef] *addr
> drivers/scsi/mpt3sas/mpt3sas_base.c:1129:52:got unsigned long long
> [usertype] *
> drivers/scsi/mpt3sas/mpt3sas_base.c:1519:36: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1519:36:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1519:36:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1532:37: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1532:37:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1532:37:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1552:45: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1552:45:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1552:45:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1565:45: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1565:45:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1565:45:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1575:36: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1575:36:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1575:36:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1594:5: warning: symbol 'base_mod64'
> was not declared. Should it be static?
> drivers/scsi/mpt3sas/mpt3sas_base.c:1717:36: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1717:36:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1717:36:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1722:28: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1722:28:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1722:28:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1620:1: warning: symbol
> 'base_make_prp_nvme' was not declared. Should it be static?
> 

Re: [PATCH v3 01/13] mpt3sas: Update MPI Header

[Suganath Prabu Subramani]

Hi James,
we have fixed the sparse warnings associated with this patch set and
posting V4 of mpt3sas patches soon. We are also working on sparse
error/warnings that existed before this patch set and we ll be posting
it separately.

Thanks,
Suganath Prabu S

On Wed, Aug 9, 2017 at 2:48 AM, J Freyensee
 wrote:
>
>
> Looks like your header has a white space error:
>
> Applying: mpt3sas: Update MPI Header
> .git/rebase-apply/patch:1452: new blank line at EOF.
> +
>
> Also, FYI, this project has a lot of sparse errors that look like existed
> before your patchset.  As your patchset touches a few of the files that
> have sparse warnings (such as mpt3sas_base.c, mpt3sas_scsih.c, etc), maybe
> you'll want to investigate fixing these things?
>
>
> [mainline-linux]$ make C=1
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   CHK scripts/mod/devicetable-offsets.h
>   CHK include/generated/compile.h
>   AR  drivers/scsi/mpt3sas/built-in.o
>   CHECK   drivers/scsi/mpt3sas/mpt3sas_base.c
> drivers/scsi/mpt3sas/mpt3sas_base.c:861:42: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:861:42:expected unsigned short
> [unsigned] [usertype] Event
> drivers/scsi/mpt3sas/mpt3sas_base.c:861:42:got restricted __le16
> [usertype] Event
> drivers/scsi/mpt3sas/mpt3sas_base.c:862:49: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:862:49:expected unsigned int
> [unsigned] [usertype] EventContext
> drivers/scsi/mpt3sas/mpt3sas_base.c:862:49:got restricted __le32
> [usertype] EventContext
> drivers/scsi/mpt3sas/mpt3sas_base.c:1080:64: warning: incorrect type in
> argument 2 (different address spaces)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1080:64:expected void volatile
> [noderef] *addr
> drivers/scsi/mpt3sas/mpt3sas_base.c:1080:64:got unsigned long long
> [usertype] *
> drivers/scsi/mpt3sas/mpt3sas_base.c:1129:52: warning: incorrect type in
> argument 2 (different address spaces)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1129:52:expected void volatile
> [noderef] *addr
> drivers/scsi/mpt3sas/mpt3sas_base.c:1129:52:got unsigned long long
> [usertype] *
> drivers/scsi/mpt3sas/mpt3sas_base.c:1519:36: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1519:36:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1519:36:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1532:37: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1532:37:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1532:37:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1552:45: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1552:45:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1552:45:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1565:45: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1565:45:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1565:45:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1575:36: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1575:36:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1575:36:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1594:5: warning: symbol 'base_mod64'
> was not declared. Should it be static?
> drivers/scsi/mpt3sas/mpt3sas_base.c:1717:36: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1717:36:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1717:36:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1722:28: warning: incorrect type in
> assignment (different base types)
> drivers/scsi/mpt3sas/mpt3sas_base.c:1722:28:expected unsigned long long
> [unsigned] [long] [long long] [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1722:28:got restricted __le64
> [usertype] 
> drivers/scsi/mpt3sas/mpt3sas_base.c:1620:1: warning: symbol
> 'base_make_prp_nvme' was not declared. Should it be static?
> drivers/scsi/mpt3sas/mpt3sas_base.c:1761:21: warning: incorrect type in
> 

[PACTH v2] SOC: fsl/guts: Add compatible string for LS1088

[Ashish Kumar]

Adding compatible string "ls1088a-dcfg" so that
guts driver can be init for ls1088

Signed-off-by: Ashish Kumar 
Signed-off-by: Amrita Kumari 
---
 drivers/soc/fsl/guts.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 6af7a11..d89a6a8 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -213,6 +213,7 @@ static int fsl_guts_remove(struct platform_device *dev)
{ .compatible = "fsl,ls1021a-dcfg", },
{ .compatible = "fsl,ls1043a-dcfg", },
{ .compatible = "fsl,ls2080a-dcfg", },
+   { .compatible = "fsl,ls1088a-dcfg", },
{}
 };
 MODULE_DEVICE_TABLE(of, fsl_guts_of_match);
-- 
1.7.6.GIT

[PACTH v2] SOC: fsl/guts: Add compatible string for LS1088

[Ashish Kumar]

Adding compatible string "ls1088a-dcfg" so that
guts driver can be init for ls1088

Signed-off-by: Ashish Kumar 
Signed-off-by: Amrita Kumari 
---
 drivers/soc/fsl/guts.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 6af7a11..d89a6a8 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -213,6 +213,7 @@ static int fsl_guts_remove(struct platform_device *dev)
{ .compatible = "fsl,ls1021a-dcfg", },
{ .compatible = "fsl,ls1043a-dcfg", },
{ .compatible = "fsl,ls2080a-dcfg", },
+   { .compatible = "fsl,ls1088a-dcfg", },
{}
 };
 MODULE_DEVICE_TABLE(of, fsl_guts_of_match);
-- 
1.7.6.GIT

Re: [PATCH v3 5/5] perf annotate browser: Circulate percent, total period and samples view

[Taeung Song]

On 08/18/2017 11:23 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Aug 18, 2017 at 05:47:08PM +0900, Taeung Song escreveu:

With a existing 't' hotkey, support the three view based on percent,
total period and number of samples on the annotate TUI browser,
circulating them like below:

   Percent -> Period -> Samples -> Percent ...

Suggested-by: Namhyung Kim 
Cc: Milian Wolff 
Cc: Jiri Olsa 
Signed-off-by: Taeung Song 
---


Ok, here I removed this part, that is not documented in the patch nor in
the 'h' help screen, if you think it should be considered, please
resubmit it with a proper explanation:


I'm really sorry. The case 'e' code is a residue..
I missed removing the code.
Thank you for indicating my mistakes.

Do I resend this patchkit based on your changes ?
Or, will you modify it by yourself ?

Thanks,
Taeung



diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index e82e6c5df83b..ba0aee576a2b 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -921,12 +921,6 @@ static int annotate_browser__run(struct annotate_browser 
*browser,
annotate_browser__opts.show_total_period = true;
annotate_browser__update_addr_width(browser);
continue;
-   case 'e':
-   annotate_browser__opts.show_total_period = false;
-   annotate_browser__opts.show_nr_samples =
-   !annotate_browser__opts.show_nr_samples;
-   annotate_browser__update_addr_width(browser);
-   continue;
case K_LEFT:
case K_ESC:
case 'q':

Re: [PATCH v3 5/5] perf annotate browser: Circulate percent, total period and samples view

[Taeung Song]

On 08/18/2017 11:23 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Aug 18, 2017 at 05:47:08PM +0900, Taeung Song escreveu:

With a existing 't' hotkey, support the three view based on percent,
total period and number of samples on the annotate TUI browser,
circulating them like below:

   Percent -> Period -> Samples -> Percent ...

Suggested-by: Namhyung Kim 
Cc: Milian Wolff 
Cc: Jiri Olsa 
Signed-off-by: Taeung Song 
---


Ok, here I removed this part, that is not documented in the patch nor in
the 'h' help screen, if you think it should be considered, please
resubmit it with a proper explanation:


I'm really sorry. The case 'e' code is a residue..
I missed removing the code.
Thank you for indicating my mistakes.

Do I resend this patchkit based on your changes ?
Or, will you modify it by yourself ?

Thanks,
Taeung



diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index e82e6c5df83b..ba0aee576a2b 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -921,12 +921,6 @@ static int annotate_browser__run(struct annotate_browser 
*browser,
annotate_browser__opts.show_total_period = true;
annotate_browser__update_addr_width(browser);
continue;
-   case 'e':
-   annotate_browser__opts.show_total_period = false;
-   annotate_browser__opts.show_nr_samples =
-   !annotate_browser__opts.show_nr_samples;
-   annotate_browser__update_addr_width(browser);
-   continue;
case K_LEFT:
case K_ESC:
case 'q':

Re: [PATCH v2] soc: ti: knav: Add a NULL pointer check for kdev in knav_pool_create

[santosh.shilim...@oracle.com]

Hi Arnd,

On 7/30/17 9:31 PM, Keerthy wrote:

knav_pool_create is an exported function. In the event of a call
before knav_queue_probe, we encounter a NULL pointer dereference
in the following line. Hence return -EPROBE_DEFER to the caller till
the kdev pointer is non-NULL.

Signed-off-by: Keerthy 
---

Changes in v2:

   * Fixed returning an int to returning pointer.

FWIW, Acked-by: Santosh Shilimkar 

Can you please also apply this fix in your fixes branch ?

Re: [PATCH v2] soc: ti: knav: Add a NULL pointer check for kdev in knav_pool_create

[santosh.shilim...@oracle.com]

Hi Arnd,

On 7/30/17 9:31 PM, Keerthy wrote:

knav_pool_create is an exported function. In the event of a call
before knav_queue_probe, we encounter a NULL pointer dereference
in the following line. Hence return -EPROBE_DEFER to the caller till
the kdev pointer is non-NULL.

Signed-off-by: Keerthy 
---

Changes in v2:

   * Fixed returning an int to returning pointer.

FWIW, Acked-by: Santosh Shilimkar 

Can you please also apply this fix in your fixes branch ?

Re: [RFC] interrupts DT property for irqdomain hierarchy

[Masahiro Yamada]

Hi Rob,


2017-08-11 2:23 GMT+09:00 Rob Herring :
> On Thu, Jul 6, 2017 at 4:58 PM, Masahiro Yamada
>  wrote:
>> Hi IRQ experts, DT exports,
>>
>>
>> I have a question about CONFIG_IRQ_DOMAIN_HIERARCHY.
>>
>> When IRQ domains are hierarchy,
>> how can we specify IRQ number re-mapping between the
>> parent irqchip and the child irqchip?
>>
>> The following figure shows a simplified example.
>>
>> |--||--|   |--|
>> | parent   || child|   |  IRQ |
>> | IRQ chip | <- | IRQ chip |<- | consumer |
>> |  ||  |   | Device   |
>> |--||--|   |--|
>>
>> Perhaps, we may describe DT like follows
>>
>> gic: interrupt-controller {
>> ...
>> interrupt-controller;
>> #interrupt-cells = <3>;
>> };
>>
>> child_intc: child-interrupt-controller {
>> ...
>> interrupt-parent = <>;
>> interrupts = <0 50 0>, <0 51 0>, <0 52 0>, <0 53 0>;
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> };
>>
>> i2c: i2c {
>> ...
>> interrupt-parent = <_intc>;
>> interrupts = <0 4>;
>> };
>>
>>
>> In this example, the I2C controller takes HWIRQ=0 of the child_intc device.
>> This goes through the child IRQ chip,
>> then connected to HWIRQ=50 of the parent intc.
>>
>> The DT above describes the hardware connection well,
>> but it actually does not work.
>>
>> The root irqchip is usually declared with IRQCHIP_DECLARE().
>> So, IRQ resources are allocated when platform devices are populated from DT.
>> This means IRQ allocation happens before drivers are probed.
>>
>> of_pupulate_default_populate() does not know the fact about irqdomain 
>> hierarchy.
>
> This has not been true for some time now. The irqs are resolved at
> probe time rather than statically created resources and deferred probe
> is supported if one of the interrupt controllers is not yet
> initialized.


Yes, it is true if the irqchip is a platform driver instead of
IRQCHIP_DECLARE(),
but irqdomain hierarchy always wants to disable the static resource allocation.






>>interrupt-ranges = <0 0 0 50 0 4>;
>>
>> This means   <0 0>, <0 1>, <0 2>, <0 3> in the child
>> should be mapped to  <0 50 0>, <0 51 0>, <0 52 0>, <0 53 0> in the parent,
>> respectively.
>
> interrupt-map property does this. See here[1].
>
> Rob
>
> [1] http://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping


Thanks for the pointer.

I read it and of_irq_parse_raw() implementation as well.

The interrupt-map would not work for the irqdomain hierarchy
because the interrupt-map transforms irq-spec based on "reg" property.

In this case, no relation between the irqchip and its irq-consumers
(between "child_intc" and "i2c") in therms of the physical address view.

Some irq-consumers have address cell size 1,
and other irq-consumers have address cells size 2.



-- 
Best Regards
Masahiro Yamada

Re: [RFC] interrupts DT property for irqdomain hierarchy

[Masahiro Yamada]

Hi Rob,


2017-08-11 2:23 GMT+09:00 Rob Herring :
> On Thu, Jul 6, 2017 at 4:58 PM, Masahiro Yamada
>  wrote:
>> Hi IRQ experts, DT exports,
>>
>>
>> I have a question about CONFIG_IRQ_DOMAIN_HIERARCHY.
>>
>> When IRQ domains are hierarchy,
>> how can we specify IRQ number re-mapping between the
>> parent irqchip and the child irqchip?
>>
>> The following figure shows a simplified example.
>>
>> |--||--|   |--|
>> | parent   || child|   |  IRQ |
>> | IRQ chip | <- | IRQ chip |<- | consumer |
>> |  ||  |   | Device   |
>> |--||--|   |--|
>>
>> Perhaps, we may describe DT like follows
>>
>> gic: interrupt-controller {
>> ...
>> interrupt-controller;
>> #interrupt-cells = <3>;
>> };
>>
>> child_intc: child-interrupt-controller {
>> ...
>> interrupt-parent = <>;
>> interrupts = <0 50 0>, <0 51 0>, <0 52 0>, <0 53 0>;
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> };
>>
>> i2c: i2c {
>> ...
>> interrupt-parent = <_intc>;
>> interrupts = <0 4>;
>> };
>>
>>
>> In this example, the I2C controller takes HWIRQ=0 of the child_intc device.
>> This goes through the child IRQ chip,
>> then connected to HWIRQ=50 of the parent intc.
>>
>> The DT above describes the hardware connection well,
>> but it actually does not work.
>>
>> The root irqchip is usually declared with IRQCHIP_DECLARE().
>> So, IRQ resources are allocated when platform devices are populated from DT.
>> This means IRQ allocation happens before drivers are probed.
>>
>> of_pupulate_default_populate() does not know the fact about irqdomain 
>> hierarchy.
>
> This has not been true for some time now. The irqs are resolved at
> probe time rather than statically created resources and deferred probe
> is supported if one of the interrupt controllers is not yet
> initialized.


Yes, it is true if the irqchip is a platform driver instead of
IRQCHIP_DECLARE(),
but irqdomain hierarchy always wants to disable the static resource allocation.






>>interrupt-ranges = <0 0 0 50 0 4>;
>>
>> This means   <0 0>, <0 1>, <0 2>, <0 3> in the child
>> should be mapped to  <0 50 0>, <0 51 0>, <0 52 0>, <0 53 0> in the parent,
>> respectively.
>
> interrupt-map property does this. See here[1].
>
> Rob
>
> [1] http://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping


Thanks for the pointer.

I read it and of_irq_parse_raw() implementation as well.

The interrupt-map would not work for the irqdomain hierarchy
because the interrupt-map transforms irq-spec based on "reg" property.

In this case, no relation between the irqchip and its irq-consumers
(between "child_intc" and "i2c") in therms of the physical address view.

Some irq-consumers have address cell size 1,
and other irq-consumers have address cells size 2.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 4/5] perf annotate browser: Support --show-nr-samples option

[Taeung Song]

On 08/18/2017 11:17 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Aug 18, 2017 at 05:47:03PM +0900, Taeung Song escreveu:

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Signed-off-by: Taeung Song 


Ok, now that check for !--stdio is lifted and replaced with:

-   if (symbol_conf.show_nr_samples && !annotate.use_stdio) {
-   pr_err("--show-nr-samples is only available in --stdio mode at this 
time\n");
+   if (symbol_conf.show_nr_samples && annotate.use_gtk) {
+   pr_err("--show-nr-samples is not available in --gtk mode at this 
time\n");
 return ret;
 }

- Arnaldo



I got it :)

Thanks,
Taeung

Re: [PATCH v3 4/5] perf annotate browser: Support --show-nr-samples option

[Taeung Song]

On 08/18/2017 11:17 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Aug 18, 2017 at 05:47:03PM +0900, Taeung Song escreveu:

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Signed-off-by: Taeung Song 


Ok, now that check for !--stdio is lifted and replaced with:

-   if (symbol_conf.show_nr_samples && !annotate.use_stdio) {
-   pr_err("--show-nr-samples is only available in --stdio mode at this 
time\n");
+   if (symbol_conf.show_nr_samples && annotate.use_gtk) {
+   pr_err("--show-nr-samples is not available in --gtk mode at this 
time\n");
 return ret;
 }

- Arnaldo



I got it :)

Thanks,
Taeung

Re: [PATCH v3 1/5] perf annotate stdio: Support --show-nr-samples option

[Taeung Song]

On 08/18/2017 10:33 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Aug 18, 2017 at 05:46:48PM +0900, Taeung Song escreveu:

Add --show-nr-samples option to perf-annotate
so that it corresponds with perf-report.


So, at this point I tried to test it and forgot this was just about
--stdio, which confused me, so I added the following patch, that I'll
lift when adding the browser support, which may not happen at this time
if there are problems there.

@@ -473,6 +474,11 @@ int cmd_annotate(int argc, const char **argv)
 annotate.sym_hist_filter = argv[0];
 }
  
+   if (symbol_conf.show_nr_samples && !annotate.use_stdio) {

+   pr_err("--show-nr-samples is only available in --stdio mode at this 
time\n");
+   return ret;
+   }
+

- Arnaldo



Ok, got it.

Thanks,
Taeung


Cc: Namhyung Kim 
Cc: Milian Wolff 
Cc: Jiri Olsa 
Signed-off-by: Taeung Song 
---
  tools/perf/Documentation/perf-annotate.txt | 4 
  tools/perf/builtin-annotate.c  | 2 ++
  tools/perf/util/annotate.c | 6 +-
  3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-annotate.txt 
b/tools/perf/Documentation/perf-annotate.txt
index a89273d..2a5975c 100644
--- a/tools/perf/Documentation/perf-annotate.txt
+++ b/tools/perf/Documentation/perf-annotate.txt
@@ -43,6 +43,10 @@ OPTIONS
  --quiet::
Do not show any message.  (Suppress -v)
  
+-n::

+--show-nr-samples::
+   Show the number of samples for each symbol
+
  -D::
  --dump-raw-trace::
  Dump raw trace in ASCII.
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 658c920..acde4cc 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -445,6 +445,8 @@ int cmd_annotate(int argc, const char **argv)
"Show event group information together"),
OPT_BOOLEAN(0, "show-total-period", _conf.show_total_period,
"Show a column with the sum of periods"),
+   OPT_BOOLEAN('n', "show-nr-samples", _conf.show_nr_samples,
+   "Show a column with the number of samples"),
OPT_CALLBACK_DEFAULT(0, "stdio-color", NULL, "mode",
 "'always' (default), 'never' or 'auto' only applicable 
to --stdio mode",
 stdio__config_color, "always"),
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 2dab0e5..4397a8b 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1145,6 +1145,9 @@ static int disasm_line__print(struct disasm_line *dl, 
struct symbol *sym, u64 st
if (symbol_conf.show_total_period)
color_fprintf(stdout, color, " %11" PRIu64,
  sample.period);
+   else if (symbol_conf.show_nr_samples)
+   color_fprintf(stdout, color, " %7" PRIu64,
+ sample.nr_samples);
else
color_fprintf(stdout, color, " %7.2f", percent);
}
@@ -1825,7 +1828,8 @@ int symbol__annotate_printf(struct symbol *sym, struct 
map *map,
width *= evsel->nr_members;
  
  	graph_dotted_len = printf(" %-*.*s|	Source code & Disassembly of %s for %s (%" PRIu64 " samples)\n",

- width, width, symbol_conf.show_total_period ? "Event 
count" : "Percent",
+ width, width, symbol_conf.show_total_period ? 
"Period" :
+ symbol_conf.show_nr_samples ? "Samples" : 
"Percent",
  d_filename, evsel_name, h->nr_samples);
  
  	printf("%-*.*s\n",

--
2.7.4

Re: [PATCH v3 1/5] perf annotate stdio: Support --show-nr-samples option

[Taeung Song]

On 08/18/2017 10:33 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Aug 18, 2017 at 05:46:48PM +0900, Taeung Song escreveu:

Add --show-nr-samples option to perf-annotate
so that it corresponds with perf-report.


So, at this point I tried to test it and forgot this was just about
--stdio, which confused me, so I added the following patch, that I'll
lift when adding the browser support, which may not happen at this time
if there are problems there.

@@ -473,6 +474,11 @@ int cmd_annotate(int argc, const char **argv)
 annotate.sym_hist_filter = argv[0];
 }
  
+   if (symbol_conf.show_nr_samples && !annotate.use_stdio) {

+   pr_err("--show-nr-samples is only available in --stdio mode at this 
time\n");
+   return ret;
+   }
+

- Arnaldo



Ok, got it.

Thanks,
Taeung


Cc: Namhyung Kim 
Cc: Milian Wolff 
Cc: Jiri Olsa 
Signed-off-by: Taeung Song 
---
  tools/perf/Documentation/perf-annotate.txt | 4 
  tools/perf/builtin-annotate.c  | 2 ++
  tools/perf/util/annotate.c | 6 +-
  3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-annotate.txt 
b/tools/perf/Documentation/perf-annotate.txt
index a89273d..2a5975c 100644
--- a/tools/perf/Documentation/perf-annotate.txt
+++ b/tools/perf/Documentation/perf-annotate.txt
@@ -43,6 +43,10 @@ OPTIONS
  --quiet::
Do not show any message.  (Suppress -v)
  
+-n::

+--show-nr-samples::
+   Show the number of samples for each symbol
+
  -D::
  --dump-raw-trace::
  Dump raw trace in ASCII.
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 658c920..acde4cc 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -445,6 +445,8 @@ int cmd_annotate(int argc, const char **argv)
"Show event group information together"),
OPT_BOOLEAN(0, "show-total-period", _conf.show_total_period,
"Show a column with the sum of periods"),
+   OPT_BOOLEAN('n', "show-nr-samples", _conf.show_nr_samples,
+   "Show a column with the number of samples"),
OPT_CALLBACK_DEFAULT(0, "stdio-color", NULL, "mode",
 "'always' (default), 'never' or 'auto' only applicable 
to --stdio mode",
 stdio__config_color, "always"),
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 2dab0e5..4397a8b 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1145,6 +1145,9 @@ static int disasm_line__print(struct disasm_line *dl, 
struct symbol *sym, u64 st
if (symbol_conf.show_total_period)
color_fprintf(stdout, color, " %11" PRIu64,
  sample.period);
+   else if (symbol_conf.show_nr_samples)
+   color_fprintf(stdout, color, " %7" PRIu64,
+ sample.nr_samples);
else
color_fprintf(stdout, color, " %7.2f", percent);
}
@@ -1825,7 +1828,8 @@ int symbol__annotate_printf(struct symbol *sym, struct 
map *map,
width *= evsel->nr_members;
  
  	graph_dotted_len = printf(" %-*.*s|	Source code & Disassembly of %s for %s (%" PRIu64 " samples)\n",

- width, width, symbol_conf.show_total_period ? "Event 
count" : "Percent",
+ width, width, symbol_conf.show_total_period ? 
"Period" :
+ symbol_conf.show_nr_samples ? "Samples" : 
"Percent",
  d_filename, evsel_name, h->nr_samples);
  
  	printf("%-*.*s\n",

--
2.7.4

Re: [virtio-dev] Re: [PATCH v14 5/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

[Wei Wang]

On 08/19/2017 02:10 AM, Michael S. Tsirkin wrote:

On Fri, Aug 18, 2017 at 04:36:06PM +0800, Wei Wang wrote:

On 08/18/2017 10:28 AM, Michael S. Tsirkin wrote:

On Thu, Aug 17, 2017 at 11:26:56AM +0800, Wei Wang wrote:

Add a new vq to report hints of guest free pages to the host.

Signed-off-by: Wei Wang 
Signed-off-by: Liang Li 
---
   drivers/virtio/virtio_balloon.c | 167 
+++-
   include/uapi/linux/virtio_balloon.h |   1 +
   2 files changed, 147 insertions(+), 21 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 72041b4..e6755bc 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -54,11 +54,12 @@ static struct vfsmount *balloon_mnt;
   struct virtio_balloon {
struct virtio_device *vdev;
-   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
+   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
/* The balloon servicing is delegated to a freezable workqueue. */
struct work_struct update_balloon_stats_work;
struct work_struct update_balloon_size_work;
+   struct work_struct report_free_page_work;
/* Prevent updating balloon when it is being canceled. */
spinlock_t stop_update_lock;
@@ -90,6 +91,13 @@ struct virtio_balloon {
/* Memory statistics */
struct virtio_balloon_stat stats[VIRTIO_BALLOON_S_NR];
+   /*
+* Used by the device and driver to signal each other.
+* device->driver: start the free page report.
+* driver->device: end the free page report.
+*/
+   __virtio32 report_free_page_signal;
+
/* To register callback in oom notifier call chain */
struct notifier_block nb;
   };
@@ -174,6 +182,17 @@ static void send_balloon_page_sg(struct virtio_balloon *vb,
} while (unlikely(ret == -ENOSPC));
   }
+static void send_free_page_sg(struct virtqueue *vq, void *addr, uint32_t size)
+{
+   unsigned int len;
+
+   add_one_sg(vq, addr, size);
+   virtqueue_kick(vq);
+   /* Release entries if there are */
+   while (virtqueue_get_buf(vq, ))
+   ;
+}
+
   /*
* Send balloon pages in sgs to host. The balloon pages are recorded in the
* page xbitmap. Each bit in the bitmap corresponds to a page of PAGE_SIZE.
@@ -511,42 +530,143 @@ static void update_balloon_size_func(struct work_struct 
*work)
queue_work(system_freezable_wq, work);
   }
+static void virtio_balloon_send_free_pages(void *opaque, unsigned long pfn,
+  unsigned long nr_pages)
+{
+   struct virtio_balloon *vb = (struct virtio_balloon *)opaque;
+   void *addr = (void *)pfn_to_kaddr(pfn);
+   uint32_t len = nr_pages << PAGE_SHIFT;
+
+   send_free_page_sg(vb->free_page_vq, addr, len);
+}
+
+static void report_free_page_completion(struct virtio_balloon *vb)
+{
+   struct virtqueue *vq = vb->free_page_vq;
+   struct scatterlist sg;
+   unsigned int len;
+   int ret;
+
+   sg_init_one(, >report_free_page_signal, sizeof(__virtio32));
+retry:
+   ret = virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL);
+   virtqueue_kick(vq);
+   if (unlikely(ret == -ENOSPC)) {
+   wait_event(vb->acked, virtqueue_get_buf(vq, ));
+   goto retry;
+   }
+}

So the annoying thing here is that once this starts going,
it will keep sending free pages from the list even if
host is no longer interested. There should be a way
for host to tell guest "stop" or "start from the beginning".

This can be achieved via two output signal buf here:
signal_buf_start: filled with VIRTIO_BALLOON_F_FREE_PAGE_REPORT_START
signal_buf_end: filled with VIRTIO_BALLOON_F_FREE_PAGE_REPORT_END

The device holds both, and can put one of them to the vq and notify.

Do you mean device writes start and end in the buf? then it's an inbuf
not an outbuf.



Not really. I meant that the driver fills two signal buffer,_START and _STOP
and send them as outbuf to the device. Then the device holds two read-only
signal buffer:
When request to start: add the _START elem to the vq
When request  to stop: add the _STOP elem to the vq





It's the result of using same vq for guest to host and
host to guest communication, and I think it's not a great idea.
I'd reuse stats vq for host to guest requests maybe.



As we discussed before, we can't have a vq interleave the report of stats
and free pages.
The vq will be locked when one command is in use. So, when live migration
starts, the
periodically reported stats will be delayed.







Would this be OK? Or would you
like to have
one host to guest vq, and multiple host to guest vqs? That is,

- host to guest:
CMD_VQ

- guest to host:
STATS_REPORT_VQ
FREE_PAGE_VQ


Best,
Wei


Point is stats report vq is also host to guest.
So I think it can be combined with CMD VQ.
If it's too hard a separate 

Re: [virtio-dev] Re: [PATCH v14 5/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

[Wei Wang]

On 08/19/2017 02:10 AM, Michael S. Tsirkin wrote:

On Fri, Aug 18, 2017 at 04:36:06PM +0800, Wei Wang wrote:

On 08/18/2017 10:28 AM, Michael S. Tsirkin wrote:

On Thu, Aug 17, 2017 at 11:26:56AM +0800, Wei Wang wrote:

Add a new vq to report hints of guest free pages to the host.

Signed-off-by: Wei Wang 
Signed-off-by: Liang Li 
---
   drivers/virtio/virtio_balloon.c | 167 
+++-
   include/uapi/linux/virtio_balloon.h |   1 +
   2 files changed, 147 insertions(+), 21 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 72041b4..e6755bc 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -54,11 +54,12 @@ static struct vfsmount *balloon_mnt;
   struct virtio_balloon {
struct virtio_device *vdev;
-   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
+   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
/* The balloon servicing is delegated to a freezable workqueue. */
struct work_struct update_balloon_stats_work;
struct work_struct update_balloon_size_work;
+   struct work_struct report_free_page_work;
/* Prevent updating balloon when it is being canceled. */
spinlock_t stop_update_lock;
@@ -90,6 +91,13 @@ struct virtio_balloon {
/* Memory statistics */
struct virtio_balloon_stat stats[VIRTIO_BALLOON_S_NR];
+   /*
+* Used by the device and driver to signal each other.
+* device->driver: start the free page report.
+* driver->device: end the free page report.
+*/
+   __virtio32 report_free_page_signal;
+
/* To register callback in oom notifier call chain */
struct notifier_block nb;
   };
@@ -174,6 +182,17 @@ static void send_balloon_page_sg(struct virtio_balloon *vb,
} while (unlikely(ret == -ENOSPC));
   }
+static void send_free_page_sg(struct virtqueue *vq, void *addr, uint32_t size)
+{
+   unsigned int len;
+
+   add_one_sg(vq, addr, size);
+   virtqueue_kick(vq);
+   /* Release entries if there are */
+   while (virtqueue_get_buf(vq, ))
+   ;
+}
+
   /*
* Send balloon pages in sgs to host. The balloon pages are recorded in the
* page xbitmap. Each bit in the bitmap corresponds to a page of PAGE_SIZE.
@@ -511,42 +530,143 @@ static void update_balloon_size_func(struct work_struct 
*work)
queue_work(system_freezable_wq, work);
   }
+static void virtio_balloon_send_free_pages(void *opaque, unsigned long pfn,
+  unsigned long nr_pages)
+{
+   struct virtio_balloon *vb = (struct virtio_balloon *)opaque;
+   void *addr = (void *)pfn_to_kaddr(pfn);
+   uint32_t len = nr_pages << PAGE_SHIFT;
+
+   send_free_page_sg(vb->free_page_vq, addr, len);
+}
+
+static void report_free_page_completion(struct virtio_balloon *vb)
+{
+   struct virtqueue *vq = vb->free_page_vq;
+   struct scatterlist sg;
+   unsigned int len;
+   int ret;
+
+   sg_init_one(, >report_free_page_signal, sizeof(__virtio32));
+retry:
+   ret = virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL);
+   virtqueue_kick(vq);
+   if (unlikely(ret == -ENOSPC)) {
+   wait_event(vb->acked, virtqueue_get_buf(vq, ));
+   goto retry;
+   }
+}

So the annoying thing here is that once this starts going,
it will keep sending free pages from the list even if
host is no longer interested. There should be a way
for host to tell guest "stop" or "start from the beginning".

This can be achieved via two output signal buf here:
signal_buf_start: filled with VIRTIO_BALLOON_F_FREE_PAGE_REPORT_START
signal_buf_end: filled with VIRTIO_BALLOON_F_FREE_PAGE_REPORT_END

The device holds both, and can put one of them to the vq and notify.

Do you mean device writes start and end in the buf? then it's an inbuf
not an outbuf.



Not really. I meant that the driver fills two signal buffer,_START and _STOP
and send them as outbuf to the device. Then the device holds two read-only
signal buffer:
When request to start: add the _START elem to the vq
When request  to stop: add the _STOP elem to the vq





It's the result of using same vq for guest to host and
host to guest communication, and I think it's not a great idea.
I'd reuse stats vq for host to guest requests maybe.



As we discussed before, we can't have a vq interleave the report of stats
and free pages.
The vq will be locked when one command is in use. So, when live migration
starts, the
periodically reported stats will be delayed.







Would this be OK? Or would you
like to have
one host to guest vq, and multiple host to guest vqs? That is,

- host to guest:
CMD_VQ

- guest to host:
STATS_REPORT_VQ
FREE_PAGE_VQ


Best,
Wei


Point is stats report vq is also host to guest.
So I think it can be combined with CMD VQ.
If it's too hard a separate vq isn't too bad though.



IMHO, this kind 

Re: [PATCH v14 5/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

[Wei Wang]

On 08/19/2017 02:26 AM, Michael S. Tsirkin wrote:

On Fri, Aug 18, 2017 at 04:41:41PM +0800, Wei Wang wrote:

On 08/18/2017 10:13 AM, Michael S. Tsirkin wrote:

On Thu, Aug 17, 2017 at 11:26:56AM +0800, Wei Wang wrote:

Add a new vq to report hints of guest free pages to the host.

Please add some text here explaining the report_free_page_signal
thing.


I also really think we need some kind of ID in the
buffer to do a handshake. whenever id changes you
add another outbuf.

Please let me introduce the current design first:
1) device put the signal buf to the vq and notify the driver (we need
a buffer because currently the device can't notify when the vq is empty);

2) the driver starts the report of free page blocks via inbuf;

3) the driver adds an the signal buf via outbuf to tell the device all are
reported.


Could you please elaborate more on the usage of ID?

While driver is free to maintain at most one buffer in flight
the design must work with pipelined requests as that
is important for performance.


How would the pipeline be designed?

Currently, once the report starts,
- the driver work: add_inbuf(free_pages) & kick;

- the device work:
record the pages into a free page bitmap;
virtqueue_push(elem);
virtio_notify();

For the driver, as long as the vq has available entries, it keeps doing 
its work;
For the device, as long as there are free pages in the vq, it also keeps 
doing its work.





So host might be able to request the reporting twice.
How does it know what is the report in response to?


The request to start is sent when live migration starts, where would be
the second chance to send the request to start?





If we put an id in request and in response, then that fixes it.


So there's a vq used for requesting free page reports.
driver does add_inbuf( >id).

Then when it starts reporting it does


add_outbuf(>id)

followed by pages.


Also if device->id changes it knows it should restart
reporting from beginning.







+retry:
+   ret = virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL);
+   virtqueue_kick(vq);
+   if (unlikely(ret == -ENOSPC)) {

what if there's another error?

Another error is -EIO, how about disabling the free page report feature?
(I also saw it isn't handled in many other virtio devices e.g. virtio-net)


+   wait_event(vb->acked, virtqueue_get_buf(vq, ));
+   goto retry;
+   }

what is this trickery doing? needs more comments or
a simplification.

Just this:
if the vq is full, blocking wait till an entry gets released, then retry.
This is the
final one, which puts the signal buf to the vq to signify the end of the
report and
the mm lock is not held here, so it is fine to block.


But why do you kick here on failure? I would understand it if you
did not kick when adding pages, as it is I don't understand.


Also pls rewrite this with a for or while loop for clarity.


OK, I will rewrite this part.


Best,
Wei

Re: [PATCH v14 5/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

[Wei Wang]

On 08/19/2017 02:26 AM, Michael S. Tsirkin wrote:

On Fri, Aug 18, 2017 at 04:41:41PM +0800, Wei Wang wrote:

On 08/18/2017 10:13 AM, Michael S. Tsirkin wrote:

On Thu, Aug 17, 2017 at 11:26:56AM +0800, Wei Wang wrote:

Add a new vq to report hints of guest free pages to the host.

Please add some text here explaining the report_free_page_signal
thing.


I also really think we need some kind of ID in the
buffer to do a handshake. whenever id changes you
add another outbuf.

Please let me introduce the current design first:
1) device put the signal buf to the vq and notify the driver (we need
a buffer because currently the device can't notify when the vq is empty);

2) the driver starts the report of free page blocks via inbuf;

3) the driver adds an the signal buf via outbuf to tell the device all are
reported.


Could you please elaborate more on the usage of ID?

While driver is free to maintain at most one buffer in flight
the design must work with pipelined requests as that
is important for performance.


How would the pipeline be designed?

Currently, once the report starts,
- the driver work: add_inbuf(free_pages) & kick;

- the device work:
record the pages into a free page bitmap;
virtqueue_push(elem);
virtio_notify();

For the driver, as long as the vq has available entries, it keeps doing 
its work;
For the device, as long as there are free pages in the vq, it also keeps 
doing its work.





So host might be able to request the reporting twice.
How does it know what is the report in response to?


The request to start is sent when live migration starts, where would be
the second chance to send the request to start?





If we put an id in request and in response, then that fixes it.


So there's a vq used for requesting free page reports.
driver does add_inbuf( >id).

Then when it starts reporting it does


add_outbuf(>id)

followed by pages.


Also if device->id changes it knows it should restart
reporting from beginning.







+retry:
+   ret = virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL);
+   virtqueue_kick(vq);
+   if (unlikely(ret == -ENOSPC)) {

what if there's another error?

Another error is -EIO, how about disabling the free page report feature?
(I also saw it isn't handled in many other virtio devices e.g. virtio-net)


+   wait_event(vb->acked, virtqueue_get_buf(vq, ));
+   goto retry;
+   }

what is this trickery doing? needs more comments or
a simplification.

Just this:
if the vq is full, blocking wait till an entry gets released, then retry.
This is the
final one, which puts the signal buf to the vq to signify the end of the
report and
the mm lock is not held here, so it is fine to block.


But why do you kick here on failure? I would understand it if you
did not kick when adding pages, as it is I don't understand.


Also pls rewrite this with a for or while loop for clarity.


OK, I will rewrite this part.


Best,
Wei

[PATCH] staging: greybus: audio: constify snd_soc_dai_ops structures

[Arvind Yadav]

snd_soc_dai_ops are not supposed to change at runtime. All functions
working with snd_soc_dai_ops provided by  work with
const snd_soc_dai_ops. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/staging/greybus/audio_codec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/greybus/audio_codec.c 
b/drivers/staging/greybus/audio_codec.c
index 25c8bb4..a6d01f0 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -674,7 +674,7 @@ static int gbcodec_mute_stream(struct snd_soc_dai *dai, int 
mute, int stream)
return ret;
 }
 
-static struct snd_soc_dai_ops gbcodec_dai_ops = {
+static const struct snd_soc_dai_ops gbcodec_dai_ops = {
.startup = gbcodec_startup,
.shutdown = gbcodec_shutdown,
.hw_params = gbcodec_hw_params,
-- 
1.9.1

[PATCH] staging: greybus: audio: constify snd_soc_dai_ops structures

[Arvind Yadav]

snd_soc_dai_ops are not supposed to change at runtime. All functions
working with snd_soc_dai_ops provided by  work with
const snd_soc_dai_ops. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/staging/greybus/audio_codec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/greybus/audio_codec.c 
b/drivers/staging/greybus/audio_codec.c
index 25c8bb4..a6d01f0 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -674,7 +674,7 @@ static int gbcodec_mute_stream(struct snd_soc_dai *dai, int 
mute, int stream)
return ret;
 }
 
-static struct snd_soc_dai_ops gbcodec_dai_ops = {
+static const struct snd_soc_dai_ops gbcodec_dai_ops = {
.startup = gbcodec_startup,
.shutdown = gbcodec_shutdown,
.hw_params = gbcodec_hw_params,
-- 
1.9.1

[GIT] Networking

[David Miller]

1) Fix IGMP handling wrt VRF, from David Ahern.

2) Fix timer access to freed object in dccp, from Eric Dumazet.

3) Use kmalloc_array() in ptr_ring to avoid overflow cases which
   are triggerable by userspace.  Also from Eric Dumazet.

4) Fix infinite loop in unmapping cleanup of nfp driver, from Colin
   Ian King.

5) Correct datagram peek handling of empty SKBs, from Matthew Dawson.

6) Fix use after free in TIPC, from Eric Dumazet.

7) When replacing a route in ipv6 we need to reset the round robin
   pointer, from Wei Wang.

8) Fix bug in pci_find_pcie_root_port() which was unearthed by the
   relaxed ordering changes, from Thierry Redding.  I made sure to get
   an explicit ACK from Bjorn this time around :-)

Please pull, thanks a lot!

The following changes since commit 510c8a899caf095cb13d09d203573deef15db2fe:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-08-15 
18:52:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 348a4002729ccab8b888b38cbc099efa2f2a2036:

  ipv6: repair fib6 tree in failure case (2017-08-20 20:06:56 -0700)


Alexander Potapenko (1):
  sctp: fully initialize the IPv6 address in sctp_v6_to_addr()

Chris Packham (1):
  switchdev: documentation: minor typo fixes

Colin Ian King (3):
  nfp: fix infinite loop on umapping cleanup
  netxen: fix incorrect loop counter decrement
  irda: do not leak initialized list.dev to userspace

Daniel Borkmann (2):
  bpf, doc: improve sysctl knob description
  bpf, doc: also add s390x as arch to sysctl description

David Ahern (1):
  net: igmp: Use ingress interface rather than vrf device

David Howells (1):
  rxrpc: Fix oops when discarding a preallocated service call

Eric Dumazet (5):
  dccp: defer ccid_hc_tx_delete() at dismantle time
  ptr_ring: use kmalloc_array()
  ipv4: better IP_MAX_MTU enforcement
  tun: handle register_netdevice() failures properly
  tipc: fix use-after-free

Eric Leblond (1):
  tools lib bpf: improve warning

Huy Nguyen (1):
  net/mlx4_core: Enable 4K UAR if SRIOV module parameter is not enabled

Jiri Pirko (1):
  net: sched: fix p_filter_chain check in tcf_chain_flush

Konstantin Khlebnikov (1):
  net_sched: fix order of queue length updates in qdisc_replace()

Liping Zhang (1):
  openvswitch: fix skb_panic due to the incorrect actions attrlen

Matthew Dawson (1):
  datagram: When peeking datagrams with offset < 0 don't skip empty skbs

Michael Ellerman (1):
  bpf: Update sysctl documentation to list all supported architectures

Neal Cardwell (1):
  tcp: when rearming RTO, if RTO time is in past then fire RTO ASAP

Roopa Prabhu (1):
  net: check and errout if res->fi is NULL when RTM_F_FIB_MATCH is set

Thierry Reding (1):
  PCI: Allow PCI express root ports to find themselves

Wei Wang (2):
  ipv6: reset fn->rr_ptr when replacing route
  ipv6: repair fib6 tree in failure case

Xin Long (1):
  net: sched: fix NULL pointer dereference when action calls some targets

 Documentation/networking/switchdev.txt  |  4 ++--
 Documentation/sysctl/net.txt| 47 
---
 drivers/net/ethernet/mellanox/mlx4/main.c   |  4 ++--
 drivers/net/ethernet/netronome/nfp/nfp_net_common.c |  3 +--
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c  |  2 +-
 drivers/net/tun.c   |  3 +++
 drivers/pci/pci.c   |  9 -
 include/linux/ptr_ring.h|  9 +
 include/linux/skb_array.h   |  3 ++-
 include/net/ip.h|  4 ++--
 include/net/sch_generic.h   |  5 -
 include/net/sock.h  |  4 +---
 net/core/datagram.c | 12 +---
 net/dccp/proto.c| 14 --
 net/ipv4/igmp.c | 10 +-
 net/ipv4/route.c| 13 ++---
 net/ipv4/tcp_input.c|  3 +--
 net/ipv4/udp.c  |  3 ++-
 net/ipv6/ip6_fib.c  | 28 
+++-
 net/ipv6/udp.c  |  3 ++-
 net/irda/af_irda.c  |  2 +-
 net/openvswitch/actions.c   |  1 +
 net/openvswitch/datapath.c  |  7 ---
 net/openvswitch/datapath.h  |  2 ++
 net/rxrpc/call_accept.c |  1 +
 net/sched/act_ipt.c |  2 ++
 net/sched/cls_api.c |  2 +-
 

[GIT] Networking

[David Miller]

1) Fix IGMP handling wrt VRF, from David Ahern.

2) Fix timer access to freed object in dccp, from Eric Dumazet.

3) Use kmalloc_array() in ptr_ring to avoid overflow cases which
   are triggerable by userspace.  Also from Eric Dumazet.

4) Fix infinite loop in unmapping cleanup of nfp driver, from Colin
   Ian King.

5) Correct datagram peek handling of empty SKBs, from Matthew Dawson.

6) Fix use after free in TIPC, from Eric Dumazet.

7) When replacing a route in ipv6 we need to reset the round robin
   pointer, from Wei Wang.

8) Fix bug in pci_find_pcie_root_port() which was unearthed by the
   relaxed ordering changes, from Thierry Redding.  I made sure to get
   an explicit ACK from Bjorn this time around :-)

Please pull, thanks a lot!

The following changes since commit 510c8a899caf095cb13d09d203573deef15db2fe:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-08-15 
18:52:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 348a4002729ccab8b888b38cbc099efa2f2a2036:

  ipv6: repair fib6 tree in failure case (2017-08-20 20:06:56 -0700)


Alexander Potapenko (1):
  sctp: fully initialize the IPv6 address in sctp_v6_to_addr()

Chris Packham (1):
  switchdev: documentation: minor typo fixes

Colin Ian King (3):
  nfp: fix infinite loop on umapping cleanup
  netxen: fix incorrect loop counter decrement
  irda: do not leak initialized list.dev to userspace

Daniel Borkmann (2):
  bpf, doc: improve sysctl knob description
  bpf, doc: also add s390x as arch to sysctl description

David Ahern (1):
  net: igmp: Use ingress interface rather than vrf device

David Howells (1):
  rxrpc: Fix oops when discarding a preallocated service call

Eric Dumazet (5):
  dccp: defer ccid_hc_tx_delete() at dismantle time
  ptr_ring: use kmalloc_array()
  ipv4: better IP_MAX_MTU enforcement
  tun: handle register_netdevice() failures properly
  tipc: fix use-after-free

Eric Leblond (1):
  tools lib bpf: improve warning

Huy Nguyen (1):
  net/mlx4_core: Enable 4K UAR if SRIOV module parameter is not enabled

Jiri Pirko (1):
  net: sched: fix p_filter_chain check in tcf_chain_flush

Konstantin Khlebnikov (1):
  net_sched: fix order of queue length updates in qdisc_replace()

Liping Zhang (1):
  openvswitch: fix skb_panic due to the incorrect actions attrlen

Matthew Dawson (1):
  datagram: When peeking datagrams with offset < 0 don't skip empty skbs

Michael Ellerman (1):
  bpf: Update sysctl documentation to list all supported architectures

Neal Cardwell (1):
  tcp: when rearming RTO, if RTO time is in past then fire RTO ASAP

Roopa Prabhu (1):
  net: check and errout if res->fi is NULL when RTM_F_FIB_MATCH is set

Thierry Reding (1):
  PCI: Allow PCI express root ports to find themselves

Wei Wang (2):
  ipv6: reset fn->rr_ptr when replacing route
  ipv6: repair fib6 tree in failure case

Xin Long (1):
  net: sched: fix NULL pointer dereference when action calls some targets

 Documentation/networking/switchdev.txt  |  4 ++--
 Documentation/sysctl/net.txt| 47 
---
 drivers/net/ethernet/mellanox/mlx4/main.c   |  4 ++--
 drivers/net/ethernet/netronome/nfp/nfp_net_common.c |  3 +--
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c  |  2 +-
 drivers/net/tun.c   |  3 +++
 drivers/pci/pci.c   |  9 -
 include/linux/ptr_ring.h|  9 +
 include/linux/skb_array.h   |  3 ++-
 include/net/ip.h|  4 ++--
 include/net/sch_generic.h   |  5 -
 include/net/sock.h  |  4 +---
 net/core/datagram.c | 12 +---
 net/dccp/proto.c| 14 --
 net/ipv4/igmp.c | 10 +-
 net/ipv4/route.c| 13 ++---
 net/ipv4/tcp_input.c|  3 +--
 net/ipv4/udp.c  |  3 ++-
 net/ipv6/ip6_fib.c  | 28 
+++-
 net/ipv6/udp.c  |  3 ++-
 net/irda/af_irda.c  |  2 +-
 net/openvswitch/actions.c   |  1 +
 net/openvswitch/datapath.c  |  7 ---
 net/openvswitch/datapath.h  |  2 ++
 net/rxrpc/call_accept.c |  1 +
 net/sched/act_ipt.c |  2 ++
 net/sched/cls_api.c |  2 +-
 

Re: [Patch v2 01/19] CIFS: Add RDMA mount option

[Leon Romanovsky]

On Sun, Aug 20, 2017 at 12:04:25PM -0700, Long Li wrote:
> From: Long Li 
>
> Add "rdma" to CIFS mount option, which tells CIFS this is for connecting to a 
> SMB server over SMBDirect. Add checks to validate this feature is only used 
> on SMB 3.X dialects.
>
> To connect to SMBDirect, use "mount.cifs -o rdma,vers=3.x".
>
> Signed-off-by: Long Li 
> ---
>  fs/cifs/cifs_debug.c |  2 ++
>  fs/cifs/cifsfs.c |  2 ++
>  fs/cifs/cifsglob.h   |  3 +++
>  fs/cifs/connect.c| 25 -
>  4 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/fs/cifs/cifs_debug.c b/fs/cifs/cifs_debug.c
> index 9727e1d..ba0870d 100644
> --- a/fs/cifs/cifs_debug.c
> +++ b/fs/cifs/cifs_debug.c
> @@ -171,6 +171,8 @@ static int cifs_debug_data_proc_show(struct seq_file *m, 
> void *v)
>   ses->ses_count, ses->serverOS, ses->serverNOS,
>   ses->capabilities, ses->status);
>   }
> + if (server->rdma)
> + seq_printf(m, "RDMA\n\t");
>   seq_printf(m, "TCP status: %d\n\tLocal Users To "
>  "Server: %d SecMode: 0x%x Req On Wire: %d",
>  server->tcpStatus, server->srv_count,
> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
> index fe0c8dc..a628800 100644
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@ -330,6 +330,8 @@ cifs_show_address(struct seq_file *s, struct 
> TCP_Server_Info *server)
>   default:
>   seq_puts(s, "(unknown)");
>   }
> + if (server->rdma)
> + seq_puts(s, ",rdma");
>  }
>
>  static void
> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
> index 8289f95..703c2fb 100644
> --- a/fs/cifs/cifsglob.h
> +++ b/fs/cifs/cifsglob.h
> @@ -531,6 +531,7 @@ struct smb_vol {
>   bool nopersistent:1;
>   bool resilient:1; /* noresilient not required since not fored for CA */
>   bool domainauto:1;
> + bool rdma:1;
>   unsigned int rsize;
>   unsigned int wsize;
>   bool sockopt_tcp_nodelay:1;
> @@ -649,6 +650,8 @@ struct TCP_Server_Info {
>   boolsec_kerberos;   /* supports plain Kerberos */
>   boolsec_mskerberos; /* supports legacy MS Kerberos */
>   boollarge_buf;  /* is current buffer large? */
> + /* use SMBD connection instead of socket */
> + boolrdma;
>   struct delayed_work echo; /* echo ping workqueue job */
>   char*smallbuf;  /* pointer to current "small" buffer */
>   char*bigbuf;/* pointer to current "big" buffer */
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 2eeaac6..d5d0ecd 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -94,7 +94,7 @@ enum {
>   Opt_multiuser, Opt_sloppy, Opt_nosharesock,
>   Opt_persistent, Opt_nopersistent,
>   Opt_resilient, Opt_noresilient,
> - Opt_domainauto,
> + Opt_domainauto, Opt_rdma,
>
>   /* Mount options which take numeric value */
>   Opt_backupuid, Opt_backupgid, Opt_uid,
> @@ -185,6 +185,7 @@ static const match_table_t cifs_mount_option_tokens = {
>   { Opt_resilient, "resilienthandles"},
>   { Opt_noresilient, "noresilienthandles"},
>   { Opt_domainauto, "domainauto"},
> + { Opt_rdma, "rdma"},
>
>   { Opt_backupuid, "backupuid=%s" },
>   { Opt_backupgid, "backupgid=%s" },
> @@ -1541,6 +1542,9 @@ cifs_parse_mount_options(const char *mountdata, const 
> char *devname,
>   case Opt_domainauto:
>   vol->domainauto = true;
>   break;
> + case Opt_rdma:
> + vol->rdma = true;
> + break;
>
>   /* Numeric Values */
>   case Opt_backupuid:
> @@ -1931,6 +1935,21 @@ cifs_parse_mount_options(const char *mountdata, const 
> char *devname,
>   goto cifs_parse_mount_err;
>   }
>
> + if (vol->rdma) {
> + switch (vol->vals->protocol_id) {
> + case SMB30_PROT_ID:
> + case SMB302_PROT_ID:
> + case SMB311_PROT_ID:
> + break;

In cover letter, you wrote that this option is relevant for 3.X versions,
so why do you write explicitly versions and don't do check if (version > 
SMB30_PROT_ID) ...?

Thanks


signature.asc
Description: PGP signature

Re: [Patch v2 01/19] CIFS: Add RDMA mount option

[Leon Romanovsky]

On Sun, Aug 20, 2017 at 12:04:25PM -0700, Long Li wrote:
> From: Long Li 
>
> Add "rdma" to CIFS mount option, which tells CIFS this is for connecting to a 
> SMB server over SMBDirect. Add checks to validate this feature is only used 
> on SMB 3.X dialects.
>
> To connect to SMBDirect, use "mount.cifs -o rdma,vers=3.x".
>
> Signed-off-by: Long Li 
> ---
>  fs/cifs/cifs_debug.c |  2 ++
>  fs/cifs/cifsfs.c |  2 ++
>  fs/cifs/cifsglob.h   |  3 +++
>  fs/cifs/connect.c| 25 -
>  4 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/fs/cifs/cifs_debug.c b/fs/cifs/cifs_debug.c
> index 9727e1d..ba0870d 100644
> --- a/fs/cifs/cifs_debug.c
> +++ b/fs/cifs/cifs_debug.c
> @@ -171,6 +171,8 @@ static int cifs_debug_data_proc_show(struct seq_file *m, 
> void *v)
>   ses->ses_count, ses->serverOS, ses->serverNOS,
>   ses->capabilities, ses->status);
>   }
> + if (server->rdma)
> + seq_printf(m, "RDMA\n\t");
>   seq_printf(m, "TCP status: %d\n\tLocal Users To "
>  "Server: %d SecMode: 0x%x Req On Wire: %d",
>  server->tcpStatus, server->srv_count,
> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
> index fe0c8dc..a628800 100644
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@ -330,6 +330,8 @@ cifs_show_address(struct seq_file *s, struct 
> TCP_Server_Info *server)
>   default:
>   seq_puts(s, "(unknown)");
>   }
> + if (server->rdma)
> + seq_puts(s, ",rdma");
>  }
>
>  static void
> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
> index 8289f95..703c2fb 100644
> --- a/fs/cifs/cifsglob.h
> +++ b/fs/cifs/cifsglob.h
> @@ -531,6 +531,7 @@ struct smb_vol {
>   bool nopersistent:1;
>   bool resilient:1; /* noresilient not required since not fored for CA */
>   bool domainauto:1;
> + bool rdma:1;
>   unsigned int rsize;
>   unsigned int wsize;
>   bool sockopt_tcp_nodelay:1;
> @@ -649,6 +650,8 @@ struct TCP_Server_Info {
>   boolsec_kerberos;   /* supports plain Kerberos */
>   boolsec_mskerberos; /* supports legacy MS Kerberos */
>   boollarge_buf;  /* is current buffer large? */
> + /* use SMBD connection instead of socket */
> + boolrdma;
>   struct delayed_work echo; /* echo ping workqueue job */
>   char*smallbuf;  /* pointer to current "small" buffer */
>   char*bigbuf;/* pointer to current "big" buffer */
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 2eeaac6..d5d0ecd 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -94,7 +94,7 @@ enum {
>   Opt_multiuser, Opt_sloppy, Opt_nosharesock,
>   Opt_persistent, Opt_nopersistent,
>   Opt_resilient, Opt_noresilient,
> - Opt_domainauto,
> + Opt_domainauto, Opt_rdma,
>
>   /* Mount options which take numeric value */
>   Opt_backupuid, Opt_backupgid, Opt_uid,
> @@ -185,6 +185,7 @@ static const match_table_t cifs_mount_option_tokens = {
>   { Opt_resilient, "resilienthandles"},
>   { Opt_noresilient, "noresilienthandles"},
>   { Opt_domainauto, "domainauto"},
> + { Opt_rdma, "rdma"},
>
>   { Opt_backupuid, "backupuid=%s" },
>   { Opt_backupgid, "backupgid=%s" },
> @@ -1541,6 +1542,9 @@ cifs_parse_mount_options(const char *mountdata, const 
> char *devname,
>   case Opt_domainauto:
>   vol->domainauto = true;
>   break;
> + case Opt_rdma:
> + vol->rdma = true;
> + break;
>
>   /* Numeric Values */
>   case Opt_backupuid:
> @@ -1931,6 +1935,21 @@ cifs_parse_mount_options(const char *mountdata, const 
> char *devname,
>   goto cifs_parse_mount_err;
>   }
>
> + if (vol->rdma) {
> + switch (vol->vals->protocol_id) {
> + case SMB30_PROT_ID:
> + case SMB302_PROT_ID:
> + case SMB311_PROT_ID:
> + break;

In cover letter, you wrote that this option is relevant for 3.X versions,
so why do you write explicitly versions and don't do check if (version > 
SMB30_PROT_ID) ...?

Thanks


signature.asc
Description: PGP signature

Re: [PATCH kernel] PCI: Disable IOV before pcibios_sriov_disable()

[Alexey Kardashevskiy]

On 19/08/17 01:27, Bjorn Helgaas wrote:
> On Fri, Aug 18, 2017 at 08:05:42AM +1000, Alexey Kardashevskiy wrote:
>> On 11/08/17 18:19, Alexey Kardashevskiy wrote:
>>> From: Gavin Shan 
>>>
>>> The PowerNV platform is the only user of pcibios_sriov_disable().
>>> The IOV BAR could be shifted by pci_iov_update_resource(). The
>>> warning message in the function is printed if the IOV capability
>>> is in enabled (PCI_SRIOV_CTRL_VFE && PCI_SRIOV_CTRL_MSE) state.
>>>
>>> This is the backtrace of what is happening:
>>>pci_disable_sriov
>>>sriov_disable
>>>pnv_pci_sriov_disable
>>>pnv_pci_vf_resource_shift
>>>pci_update_resource
>>>pci_iov_update_resource
>>>
>>> This fixes the issue by disabling IOV capability before calling
>>> pcibios_sriov_disable(). With it, the disabling path matches
>>> the enabling path: pcibios_sriov_enable() is called before the
>>> IOV capability is enabled.
>>>
>>> Cc: shan.ga...@gmail.com
>>> Cc: Benjamin Herrenschmidt 
>>> Cc: Paul Mackerras 
>>> Reported-by: Carol L Soto 
>>> Signed-off-by: Gavin Shan 
>>> Tested-by: Carol L Soto 
>>> Signed-off-by: Alexey Kardashevskiy 
>>> ---
>>>
>>> This is repost. Since Gavin left the team, I am trying to push it out.
>>> The previos converstion is here: https://patchwork.ozlabs.org/patch/732653/
>>>
>>> Two questions were raised then. I'll try to comment on this below.
>>
>> Bjorn, ping? Thanks.
> 
> Thanks for the reminder.  This is in patchwork, so it's on my to-do
> list.
> 
> My last response in the thread above was:
> 
>   I'm not going to merge this without a comment in
>   pnv_pci_vf_resource_shift() that addresses the two questions I
>   raised in my very first response.  I don't think the existing
>   comment about "After doing so, there would be a 'hole'" is
>   sufficient.  If it were sufficient, I wouldn't have raised the
>   questions in the first place.
> 
> The problem here is that I'm looking for a comment *in the code*, and
> you and Gavin are giving responses and clarifications in email.

I understand.

> What we need to do is transfer this email information into something
> useful when reading the code, i.e., a comment in the code.

I agree. Here are few problems though.

1. I am not sure if there is nothing to fix (like adding dummy regions to
prevent these "holes" to be used for something else)

2. I do not really know how exactly to update the comment in the code to
make it clearer for the future readers, and before doing this, I'd like to
understand about 1).


An example of the comment which would make sense to me:

@@ -1002,9 +1016,13 @@ static int pnv_pci_vf_resource_shift(struct pci_dev
*dev, int offset)
}

/*
-* After doing so, there would be a "hole" in the /proc/iomem when
-* offset is a positive value. It looks like the device return some
-* mmio back to the system, which actually no one could use it.
+* Since M64 BAR shares segments among all possible 256 PEs,
+* we have to shift the beginning of PF IOV BAR to make it start from
+* the segment which belongs to the PE number assigned to the first VF.
+* This creates a "hole" in the /proc/iomem which could be used for
+* allocating other resources, however this is not expected to happen
+* on IODA as the only possibility would be a PCI hotplug and IODA
+* hardware only allows it on a slot with dedicated PHB.
 */


Does this make sense? Thanks.



> 
 1) "res" is already in the resource tree, so we shouldn't be changing
   its start address, because that may make the tree inconsistent,
   e.g., the resource may no longer be completely contained in its
   parent, it may conflict with a sibling, etc.
>>>
>>> We should not, yes. But...
>>>
>>> At the boot time IOV BAR gets as much MMIO space as it can possibly use.
>>> (Embarassingly I cannot trace where this is coming from, 8GB is selected
>>> via pci_assign_unassigned_root_bus_resources() path somehow).
>>> For example, it is 256*32MB=8GB where 256 is maximum PEs number and 32MB
>>> is a PF/VF BAR size. Whatever shifting we do afterwards, the boudaries of
>>> that 8GB area do not change and we test it in pnv_pci_vf_resource_shift():
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/platforms/powernv/pci-ioda.c#n987
>>>
 2) If we update "res->start", shouldn't we update "res->end"
   correspondingly?
>>>
>>> We have to update the PF's IOV BAR address as we allocate PEs dynamically
>>> and we do not know in advance where our VF numbers start in that
>>> 8GB window. So we change IOV BASR start. Changing the end may make it
>>> look more like there is a free area to use but in reality it won't be
>>> usable as well as the area we "release" by shifting the start address.
>>>
>>> 

Re: [PATCH kernel] PCI: Disable IOV before pcibios_sriov_disable()

[Alexey Kardashevskiy]

On 19/08/17 01:27, Bjorn Helgaas wrote:
> On Fri, Aug 18, 2017 at 08:05:42AM +1000, Alexey Kardashevskiy wrote:
>> On 11/08/17 18:19, Alexey Kardashevskiy wrote:
>>> From: Gavin Shan 
>>>
>>> The PowerNV platform is the only user of pcibios_sriov_disable().
>>> The IOV BAR could be shifted by pci_iov_update_resource(). The
>>> warning message in the function is printed if the IOV capability
>>> is in enabled (PCI_SRIOV_CTRL_VFE && PCI_SRIOV_CTRL_MSE) state.
>>>
>>> This is the backtrace of what is happening:
>>>pci_disable_sriov
>>>sriov_disable
>>>pnv_pci_sriov_disable
>>>pnv_pci_vf_resource_shift
>>>pci_update_resource
>>>pci_iov_update_resource
>>>
>>> This fixes the issue by disabling IOV capability before calling
>>> pcibios_sriov_disable(). With it, the disabling path matches
>>> the enabling path: pcibios_sriov_enable() is called before the
>>> IOV capability is enabled.
>>>
>>> Cc: shan.ga...@gmail.com
>>> Cc: Benjamin Herrenschmidt 
>>> Cc: Paul Mackerras 
>>> Reported-by: Carol L Soto 
>>> Signed-off-by: Gavin Shan 
>>> Tested-by: Carol L Soto 
>>> Signed-off-by: Alexey Kardashevskiy 
>>> ---
>>>
>>> This is repost. Since Gavin left the team, I am trying to push it out.
>>> The previos converstion is here: https://patchwork.ozlabs.org/patch/732653/
>>>
>>> Two questions were raised then. I'll try to comment on this below.
>>
>> Bjorn, ping? Thanks.
> 
> Thanks for the reminder.  This is in patchwork, so it's on my to-do
> list.
> 
> My last response in the thread above was:
> 
>   I'm not going to merge this without a comment in
>   pnv_pci_vf_resource_shift() that addresses the two questions I
>   raised in my very first response.  I don't think the existing
>   comment about "After doing so, there would be a 'hole'" is
>   sufficient.  If it were sufficient, I wouldn't have raised the
>   questions in the first place.
> 
> The problem here is that I'm looking for a comment *in the code*, and
> you and Gavin are giving responses and clarifications in email.

I understand.

> What we need to do is transfer this email information into something
> useful when reading the code, i.e., a comment in the code.

I agree. Here are few problems though.

1. I am not sure if there is nothing to fix (like adding dummy regions to
prevent these "holes" to be used for something else)

2. I do not really know how exactly to update the comment in the code to
make it clearer for the future readers, and before doing this, I'd like to
understand about 1).


An example of the comment which would make sense to me:

@@ -1002,9 +1016,13 @@ static int pnv_pci_vf_resource_shift(struct pci_dev
*dev, int offset)
}

/*
-* After doing so, there would be a "hole" in the /proc/iomem when
-* offset is a positive value. It looks like the device return some
-* mmio back to the system, which actually no one could use it.
+* Since M64 BAR shares segments among all possible 256 PEs,
+* we have to shift the beginning of PF IOV BAR to make it start from
+* the segment which belongs to the PE number assigned to the first VF.
+* This creates a "hole" in the /proc/iomem which could be used for
+* allocating other resources, however this is not expected to happen
+* on IODA as the only possibility would be a PCI hotplug and IODA
+* hardware only allows it on a slot with dedicated PHB.
 */


Does this make sense? Thanks.



> 
 1) "res" is already in the resource tree, so we shouldn't be changing
   its start address, because that may make the tree inconsistent,
   e.g., the resource may no longer be completely contained in its
   parent, it may conflict with a sibling, etc.
>>>
>>> We should not, yes. But...
>>>
>>> At the boot time IOV BAR gets as much MMIO space as it can possibly use.
>>> (Embarassingly I cannot trace where this is coming from, 8GB is selected
>>> via pci_assign_unassigned_root_bus_resources() path somehow).
>>> For example, it is 256*32MB=8GB where 256 is maximum PEs number and 32MB
>>> is a PF/VF BAR size. Whatever shifting we do afterwards, the boudaries of
>>> that 8GB area do not change and we test it in pnv_pci_vf_resource_shift():
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/platforms/powernv/pci-ioda.c#n987
>>>
 2) If we update "res->start", shouldn't we update "res->end"
   correspondingly?
>>>
>>> We have to update the PF's IOV BAR address as we allocate PEs dynamically
>>> and we do not know in advance where our VF numbers start in that
>>> 8GB window. So we change IOV BASR start. Changing the end may make it
>>> look more like there is a free area to use but in reality it won't be
>>> usable as well as the area we "release" by shifting the start address.
>>>
>>> We could probably move that M64 MMIO window by the same delta in
>>> opposite direction so the IOV BAR start address would remain the same
>>> but its 

Re: [PATCH] tpm/tpm_crb: Access locality for non-ACPI and non-SMC start method

[Jiandi An]

On 08/19/2017 12:05 PM, Jarkko Sakkinen wrote:

On Thu, Aug 17, 2017 at 11:15:36PM -0500, Jiandi An wrote:

For ARM64, the locality is handled by Trust Zone in FW.
The layout does not have crb_regs_head.  It is hitting
the following line.
dev_warn(dev, FW_BUG "Bad ACPI memory layout");

Current code excludes CRB_FL_ACPI_START and when
CRB_FL_CRB_SMC_START is added around the same time
locality support is added, it should also be excluded.

For goIdle and cmdReady where code was excluding
CRB_FL_ACPI_START only (do nothing for ACPI start method),
CRB_FL_CRB_SMC_START was also excluded as ARM64 SMC start
method does not have TPM_CRB_CTRL_REQ.
Change if confition to white list instead of black list.

Signed-off-by: Jiandi An 


Is this v2? If so, where is the change log?

Based on the previous comments, I now understand that
because of Intel PTT bug workaround, it is not appropriate
for the patch to have title/subject "Access locality for
only CRB_START method"

So the more descriptive patch title is "Access locality for
only non-ACPI and non-SMC start method".  Because the patch
is changed, I thought I start a new series.  Would you like
me to tag this v3 and put change log even though patch title
has changed?

Thanks
- Jiandi



/Jarkko



--
Jiandi An
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project.

Re: [PATCH] tpm/tpm_crb: Access locality for non-ACPI and non-SMC start method

[Jiandi An]

On 08/19/2017 12:05 PM, Jarkko Sakkinen wrote:

On Thu, Aug 17, 2017 at 11:15:36PM -0500, Jiandi An wrote:

For ARM64, the locality is handled by Trust Zone in FW.
The layout does not have crb_regs_head.  It is hitting
the following line.
dev_warn(dev, FW_BUG "Bad ACPI memory layout");

Current code excludes CRB_FL_ACPI_START and when
CRB_FL_CRB_SMC_START is added around the same time
locality support is added, it should also be excluded.

For goIdle and cmdReady where code was excluding
CRB_FL_ACPI_START only (do nothing for ACPI start method),
CRB_FL_CRB_SMC_START was also excluded as ARM64 SMC start
method does not have TPM_CRB_CTRL_REQ.
Change if confition to white list instead of black list.

Signed-off-by: Jiandi An 


Is this v2? If so, where is the change log?

Based on the previous comments, I now understand that
because of Intel PTT bug workaround, it is not appropriate
for the patch to have title/subject "Access locality for
only CRB_START method"

So the more descriptive patch title is "Access locality for
only non-ACPI and non-SMC start method".  Because the patch
is changed, I thought I start a new series.  Would you like
me to tag this v3 and put change log even though patch title
has changed?

Thanks
- Jiandi



/Jarkko



--
Jiandi An
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project.

[PATCH v4 0/3] Add i2c dt-binding and compatible for Mediatek MT7622 SoC

[Jun Gao]

This patch series based on v4.13-rc1, include i2c binding file information
formats modification, MT7622 i2c dt-binding and compatible.

changes since v3:
- Split the formats modification into another patch

changes since v2:
- Remove all the length settings from mt7622_i2c_quirks

changes since v1:
- Modify commit message
- Revise dt-binding documentation

Jun Gao (3):
  dt-bindings: i2c: modify information formats
  dt-bindings: i2c: Add MediaTek MT7622 i2c binding
  i2c: mediatek: Add i2c compatible for MediaTek MT7622

 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 15 ---
 drivers/i2c/busses/i2c-mt65xx.c   | 14 ++
 2 files changed, 22 insertions(+), 7 deletions(-)

--
1.8.1.1

[PATCH v4 1/3] dt-bindings: i2c: modify information formats

[Jun Gao]

From: Jun Gao 

Use common name MediaTek and modify the compatible information
formats of all SoCs to the same.

Signed-off-by: Jun Gao 
---
 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index bd5a7be..9c86424 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -1,14 +1,14 @@
-* Mediatek's I2C controller
+* MediaTek's I2C controller
 
-The Mediatek's I2C controller is used to interface with I2C devices.
+The MediaTek's I2C controller is used to interface with I2C devices.
 
 Required properties:
   - compatible: value should be either of the following.
-  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701
-  "mediatek,mt6577-i2c": for i2c compatible with mt6577.
-  "mediatek,mt6589-i2c": for i2c compatible with mt6589.
-  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible with 
mt7623.
-  "mediatek,mt8173-i2c": for i2c compatible with mt8173.
+  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701
+  "mediatek,mt6577-i2c": for MediaTek MT6577
+  "mediatek,mt6589-i2c": for MediaTek MT6589
+  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623
+  "mediatek,mt8173-i2c": for MediaTek MT8173
   - reg: physical base address of the controller and dma base, length of memory
 mapped region.
   - interrupts: interrupt number to the cpu.
-- 
1.8.1.1

[PATCH v4 3/3] i2c: mediatek: Add i2c compatible for MediaTek MT7622

[Jun Gao]

From: Jun Gao 

Add i2c compatible for MT7622. Compare to MT8173 i2c controller,
MT7622 limits message numbers to 255, and does not support 4GB
DMA mode.

Signed-off-by: Jun Gao 
Reviewed-by: Yingjoe Chen 
---
 drivers/i2c/busses/i2c-mt65xx.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 9bedf0b..09d288c 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -172,6 +172,10 @@ struct mtk_i2c {
.max_comb_2nd_msg_len = 31,
 };
 
+static const struct i2c_adapter_quirks mt7622_i2c_quirks = {
+   .max_num_msgs = 255,
+};
+
 static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = _i2c_quirks,
.pmic_i2c = 0,
@@ -190,6 +194,15 @@ struct mtk_i2c {
.support_33bits = 0,
 };
 
+static const struct mtk_i2c_compatible mt7622_compat = {
+   .quirks = _i2c_quirks,
+   .pmic_i2c = 0,
+   .dcm = 1,
+   .auto_restart = 1,
+   .aux_len_reg = 1,
+   .support_33bits = 0,
+};
+
 static const struct mtk_i2c_compatible mt8173_compat = {
.pmic_i2c = 0,
.dcm = 1,
@@ -201,6 +214,7 @@ struct mtk_i2c {
 static const struct of_device_id mtk_i2c_of_match[] = {
{ .compatible = "mediatek,mt6577-i2c", .data = _compat },
{ .compatible = "mediatek,mt6589-i2c", .data = _compat },
+   { .compatible = "mediatek,mt7622-i2c", .data = _compat },
{ .compatible = "mediatek,mt8173-i2c", .data = _compat },
{}
 };
-- 
1.8.1.1

[PATCH v4 0/3] Add i2c dt-binding and compatible for Mediatek MT7622 SoC

[Jun Gao]

This patch series based on v4.13-rc1, include i2c binding file information
formats modification, MT7622 i2c dt-binding and compatible.

changes since v3:
- Split the formats modification into another patch

changes since v2:
- Remove all the length settings from mt7622_i2c_quirks

changes since v1:
- Modify commit message
- Revise dt-binding documentation

Jun Gao (3):
  dt-bindings: i2c: modify information formats
  dt-bindings: i2c: Add MediaTek MT7622 i2c binding
  i2c: mediatek: Add i2c compatible for MediaTek MT7622

 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 15 ---
 drivers/i2c/busses/i2c-mt65xx.c   | 14 ++
 2 files changed, 22 insertions(+), 7 deletions(-)

--
1.8.1.1

[PATCH v4 1/3] dt-bindings: i2c: modify information formats

[Jun Gao]

From: Jun Gao 

Use common name MediaTek and modify the compatible information
formats of all SoCs to the same.

Signed-off-by: Jun Gao 
---
 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index bd5a7be..9c86424 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -1,14 +1,14 @@
-* Mediatek's I2C controller
+* MediaTek's I2C controller
 
-The Mediatek's I2C controller is used to interface with I2C devices.
+The MediaTek's I2C controller is used to interface with I2C devices.
 
 Required properties:
   - compatible: value should be either of the following.
-  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701
-  "mediatek,mt6577-i2c": for i2c compatible with mt6577.
-  "mediatek,mt6589-i2c": for i2c compatible with mt6589.
-  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible with 
mt7623.
-  "mediatek,mt8173-i2c": for i2c compatible with mt8173.
+  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701
+  "mediatek,mt6577-i2c": for MediaTek MT6577
+  "mediatek,mt6589-i2c": for MediaTek MT6589
+  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623
+  "mediatek,mt8173-i2c": for MediaTek MT8173
   - reg: physical base address of the controller and dma base, length of memory
 mapped region.
   - interrupts: interrupt number to the cpu.
-- 
1.8.1.1

[PATCH v4 3/3] i2c: mediatek: Add i2c compatible for MediaTek MT7622

[Jun Gao]

From: Jun Gao 

Add i2c compatible for MT7622. Compare to MT8173 i2c controller,
MT7622 limits message numbers to 255, and does not support 4GB
DMA mode.

Signed-off-by: Jun Gao 
Reviewed-by: Yingjoe Chen 
---
 drivers/i2c/busses/i2c-mt65xx.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 9bedf0b..09d288c 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -172,6 +172,10 @@ struct mtk_i2c {
.max_comb_2nd_msg_len = 31,
 };
 
+static const struct i2c_adapter_quirks mt7622_i2c_quirks = {
+   .max_num_msgs = 255,
+};
+
 static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = _i2c_quirks,
.pmic_i2c = 0,
@@ -190,6 +194,15 @@ struct mtk_i2c {
.support_33bits = 0,
 };
 
+static const struct mtk_i2c_compatible mt7622_compat = {
+   .quirks = _i2c_quirks,
+   .pmic_i2c = 0,
+   .dcm = 1,
+   .auto_restart = 1,
+   .aux_len_reg = 1,
+   .support_33bits = 0,
+};
+
 static const struct mtk_i2c_compatible mt8173_compat = {
.pmic_i2c = 0,
.dcm = 1,
@@ -201,6 +214,7 @@ struct mtk_i2c {
 static const struct of_device_id mtk_i2c_of_match[] = {
{ .compatible = "mediatek,mt6577-i2c", .data = _compat },
{ .compatible = "mediatek,mt6589-i2c", .data = _compat },
+   { .compatible = "mediatek,mt7622-i2c", .data = _compat },
{ .compatible = "mediatek,mt8173-i2c", .data = _compat },
{}
 };
-- 
1.8.1.1

[PATCH v4 2/3] dt-bindings: i2c: Add MediaTek MT7622 i2c binding

[Jun Gao]

From: Jun Gao 

Add MT7622 i2c binding to binding file. Compare to MT8173 i2c
controller, MT7622 limits message numbers to 255, and does not
support 4GB DMA mode.

Signed-off-by: Jun Gao 
---
 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index 9c86424..ff7bf37 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -7,6 +7,7 @@ Required properties:
   "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701
   "mediatek,mt6577-i2c": for MediaTek MT6577
   "mediatek,mt6589-i2c": for MediaTek MT6589
+  "mediatek,mt7622-i2c": for MediaTek MT7622
   "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623
   "mediatek,mt8173-i2c": for MediaTek MT8173
   - reg: physical base address of the controller and dma base, length of memory
-- 
1.8.1.1

[PATCH v4 2/3] dt-bindings: i2c: Add MediaTek MT7622 i2c binding

[Jun Gao]

From: Jun Gao 

Add MT7622 i2c binding to binding file. Compare to MT8173 i2c
controller, MT7622 limits message numbers to 255, and does not
support 4GB DMA mode.

Signed-off-by: Jun Gao 
---
 Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index 9c86424..ff7bf37 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -7,6 +7,7 @@ Required properties:
   "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701
   "mediatek,mt6577-i2c": for MediaTek MT6577
   "mediatek,mt6589-i2c": for MediaTek MT6589
+  "mediatek,mt7622-i2c": for MediaTek MT7622
   "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623
   "mediatek,mt8173-i2c": for MediaTek MT8173
   - reg: physical base address of the controller and dma base, length of memory
-- 
1.8.1.1

Re: special handle of scripts/kconfig/zconf.tab.o

[Cao jin]

Hi,
  Thank you both for those valuable info.

On 08/19/2017 08:42 PM, Masahiro Yamada wrote:
> Hi.
> (+CC Sam)
> 
> 2017-08-15 20:02 GMT+09:00 Cao jin :
>> Masahiro-san,
>>
>> I have a question about make *config. In scripts/kconfig/Makefile, there
>> is following statement:
>>
>> $(obj)/zconf.tab.o: $(obj)/zconf.lex.c $(obj)/zconf.hash.c
>>
>> and the $(obj)/zconf.{tab,hash,lex}.c match the rule in Makefile.lib:
>>
>> $(obj)/%: $(src)/%_shipped
>> $(call cmd,shipped)
>>
>> and cmd_shipped just transform the _shipped file to .c via `cat`.
>>
>> And zconf.tab.c includes several *other* .c files which make the whole
>> process a little obscure, because there are not corresponding .o files
>> for the *other* .c files.
>>
>> My questions is: Does this special handling has other meanings that I
>> may miss? Or just legacy.
> 

> 
> 
>> Because a straightforward way in my mind would be:
>>
>> rename zconf.{tab,hash,lex}.c_shipped to zconf.{tab,hash,lex}.c, then
>> has following in the Makefile
>>
>> common-objs := zconf.tab.o zconf.hash.o zconf.lex.o util.o etc...
>> conf-objs := conf.o $(common-objs)
>>
> 

> 
> 
> Here, we have one more question.
> 
> 
> Can we generate zconf.{tab,hash,lex}.c from zconf.{y,gperf,l}
> instead of from *_shipped?
> 
> This is also possible, technically.
> But, I do not know if it is acceptable to have
> more external tool dependencies.
> (So, I sent RFC patches to hear more opinions.)
> 

I think this is good for the new comers who don't know those tools
before. When I come to here. I just noticed that kbuild will cat
*_shipped file to the corresponding .c file, and miss the part that the
.c file is actually created by the tools.

And another new-comer friendly improvement may be something like: remove
"include *.c" lines in zconf.y, and modify makefile like I said above.
 So I will not get confused when I see symbols within certain .c file is
used while don't see the certain .o file.

-- 
Sincerely,
Cao jin

Re: special handle of scripts/kconfig/zconf.tab.o

[Cao jin]

Hi,
  Thank you both for those valuable info.

On 08/19/2017 08:42 PM, Masahiro Yamada wrote:
> Hi.
> (+CC Sam)
> 
> 2017-08-15 20:02 GMT+09:00 Cao jin :
>> Masahiro-san,
>>
>> I have a question about make *config. In scripts/kconfig/Makefile, there
>> is following statement:
>>
>> $(obj)/zconf.tab.o: $(obj)/zconf.lex.c $(obj)/zconf.hash.c
>>
>> and the $(obj)/zconf.{tab,hash,lex}.c match the rule in Makefile.lib:
>>
>> $(obj)/%: $(src)/%_shipped
>> $(call cmd,shipped)
>>
>> and cmd_shipped just transform the _shipped file to .c via `cat`.
>>
>> And zconf.tab.c includes several *other* .c files which make the whole
>> process a little obscure, because there are not corresponding .o files
>> for the *other* .c files.
>>
>> My questions is: Does this special handling has other meanings that I
>> may miss? Or just legacy.
> 

> 
> 
>> Because a straightforward way in my mind would be:
>>
>> rename zconf.{tab,hash,lex}.c_shipped to zconf.{tab,hash,lex}.c, then
>> has following in the Makefile
>>
>> common-objs := zconf.tab.o zconf.hash.o zconf.lex.o util.o etc...
>> conf-objs := conf.o $(common-objs)
>>
> 

> 
> 
> Here, we have one more question.
> 
> 
> Can we generate zconf.{tab,hash,lex}.c from zconf.{y,gperf,l}
> instead of from *_shipped?
> 
> This is also possible, technically.
> But, I do not know if it is acceptable to have
> more external tool dependencies.
> (So, I sent RFC patches to hear more opinions.)
> 

I think this is good for the new comers who don't know those tools
before. When I come to here. I just noticed that kbuild will cat
*_shipped file to the corresponding .c file, and miss the part that the
.c file is actually created by the tools.

And another new-comer friendly improvement may be something like: remove
"include *.c" lines in zconf.y, and modify makefile like I said above.
 So I will not get confused when I see symbols within certain .c file is
used while don't see the certain .o file.

-- 
Sincerely,
Cao jin

RE: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries

[Wangkai (Kevin,C)]

> -Original Message-
> From: Waiman Long [mailto:long...@redhat.com]
> Sent: Friday, August 18, 2017 10:10 PM
> To: Wangkai (Kevin,C); Alexander Viro; Jonathan Corbet
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linux-fsde...@vger.kernel.org; Paul E. McKenney; Andrew Morton; Ingo Molnar;
> Miklos Szeredi; Matthew Wilcox; Larry Woodman; James Bottomley
> Subject: Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries
> 
> On 08/18/2017 05:59 AM, Wangkai (Kevin,C) wrote:
> >
> >>> In my patch the DCACHE_FILE_REMOVED flag was to distinguish the
> >>> removed file and The closed file, I found there was no difference of
> >>> a dentry between the removed file and the closed File, they all on the lru
> list.
> >> There is a difference between removed file and closed file. The type
> >> field of d_flags will be empty for a removed file which indicate a negative
> dentry.
> >> Anything else is a positive dentry. Look at the inline function
> >> d_is_negative() [d_is_miss()] and you will see how it is done.
> > After the file was removed, the dentry flag was not MISS, the flag was:
> > DCACHE_REFERENCED | DCACHE_RCUACCESS | DCACHE_LRU_LIST |
> > DCACHE_REGULAR_TYPE So, the dentry never be freed, until the kernel
> reclaim the slab memory.
> 
> The dentry_unlink_inode() function will clear DCACHE_REGULAR_TYPE.
> 

Yes, I have add some trace info for the dentry state changed, with dentry flag 
and reference count:

File create:
[   42.636675] dentry [_1234] 0x880230be8180 flag 0x0 ref 1 ev dentry 
alloc
File close:
[   42.637421] dentry [_1234] 0x880230be8180 flag 0x4800c0 ref 0 ev 
dput called

Unlink lookup:
[  244.658086] dentry [_1234] 0x880230be8180 flag 0x4800c0 ref 1 ev 
d_lookup
Unlink d_delete:
[  244.658254] dentry [_1234] 0x880230be8180 flag 0x800c0 ref 1 ev 
d_lockref ref 1
Unlink dput:
[  244.658438] dentry [_1234] 0x880230be8180 flag 0x800c0 ref 0 ev dput 
called

The end, dentry's flag stay at 0x800c0, but this dentry was not freed, keeped 
by the dcache as unused,
After tens of thousands of the dentries slow down the dentry lookup 
performance, kernel memory usage
Keep high.

Regards,
Kevin

RE: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries

[Wangkai (Kevin,C)]

> -Original Message-
> From: Waiman Long [mailto:long...@redhat.com]
> Sent: Friday, August 18, 2017 10:10 PM
> To: Wangkai (Kevin,C); Alexander Viro; Jonathan Corbet
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linux-fsde...@vger.kernel.org; Paul E. McKenney; Andrew Morton; Ingo Molnar;
> Miklos Szeredi; Matthew Wilcox; Larry Woodman; James Bottomley
> Subject: Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries
> 
> On 08/18/2017 05:59 AM, Wangkai (Kevin,C) wrote:
> >
> >>> In my patch the DCACHE_FILE_REMOVED flag was to distinguish the
> >>> removed file and The closed file, I found there was no difference of
> >>> a dentry between the removed file and the closed File, they all on the lru
> list.
> >> There is a difference between removed file and closed file. The type
> >> field of d_flags will be empty for a removed file which indicate a negative
> dentry.
> >> Anything else is a positive dentry. Look at the inline function
> >> d_is_negative() [d_is_miss()] and you will see how it is done.
> > After the file was removed, the dentry flag was not MISS, the flag was:
> > DCACHE_REFERENCED | DCACHE_RCUACCESS | DCACHE_LRU_LIST |
> > DCACHE_REGULAR_TYPE So, the dentry never be freed, until the kernel
> reclaim the slab memory.
> 
> The dentry_unlink_inode() function will clear DCACHE_REGULAR_TYPE.
> 

Yes, I have add some trace info for the dentry state changed, with dentry flag 
and reference count:

File create:
[   42.636675] dentry [_1234] 0x880230be8180 flag 0x0 ref 1 ev dentry 
alloc
File close:
[   42.637421] dentry [_1234] 0x880230be8180 flag 0x4800c0 ref 0 ev 
dput called

Unlink lookup:
[  244.658086] dentry [_1234] 0x880230be8180 flag 0x4800c0 ref 1 ev 
d_lookup
Unlink d_delete:
[  244.658254] dentry [_1234] 0x880230be8180 flag 0x800c0 ref 1 ev 
d_lockref ref 1
Unlink dput:
[  244.658438] dentry [_1234] 0x880230be8180 flag 0x800c0 ref 0 ev dput 
called

The end, dentry's flag stay at 0x800c0, but this dentry was not freed, keeped 
by the dcache as unused,
After tens of thousands of the dentries slow down the dentry lookup 
performance, kernel memory usage
Keep high.

Regards,
Kevin

Re: [PATCH 0/3] MIPS,bpf: Improvements for MIPS eBPF JIT

[David Miller]

From: David Daney 
Date: Fri, 18 Aug 2017 16:40:30 -0700

> I suggest that the whole thing go via the BPF/net-next path as there
> are dependencies on code that is not yet merged to Linus' tree.

What kind of dependency?  On networking or MIPS changes?

If the dependency is on MIPS changes, then if I cannot apply this as
it will break the net-next build on MIPS.  You should merge this
via the MIPS tree, where the dependencies are, in that case.

Please clarify what is specifically happening here.

Thanks.

Re: [PATCH 0/3] MIPS,bpf: Improvements for MIPS eBPF JIT

[David Miller]

From: David Daney 
Date: Fri, 18 Aug 2017 16:40:30 -0700

> I suggest that the whole thing go via the BPF/net-next path as there
> are dependencies on code that is not yet merged to Linus' tree.

What kind of dependency?  On networking or MIPS changes?

If the dependency is on MIPS changes, then if I cannot apply this as
it will break the net-next build on MIPS.  You should merge this
via the MIPS tree, where the dependencies are, in that case.

Please clarify what is specifically happening here.

Thanks.

Re: [PATCH] net: dsa: mv88e6xxx: make irq_chip const

[David Miller]

From: Bhumika Goyal 
Date: Sat, 19 Aug 2017 16:25:52 +0530

> Make this const as it is only used in a copy operation.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 

Applied to net-next, thanks.

Re: [PATCH] net: dsa: mv88e6xxx: make irq_chip const

[David Miller]

From: Bhumika Goyal 
Date: Sat, 19 Aug 2017 16:25:52 +0530

> Make this const as it is only used in a copy operation.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 

Applied to net-next, thanks.

Re: [PATCH v6 2/2] PCI: iproc: add device shutdown for PCI RC

[Oza Oza]

On Mon, Aug 21, 2017 at 2:55 AM, Bjorn Helgaas  wrote:
> On Sun, Aug 20, 2017 at 09:06:51AM +0530, Oza Oza wrote:
>> On Sun, Aug 20, 2017 at 2:34 AM, Bjorn Helgaas  wrote:
>> > On Fri, Aug 04, 2017 at 09:18:16PM +0530, Oza Pawandeep wrote:
>> >> PERST must be asserted around ~500ms before the reboot is applied.
>> >>
>> >> During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs
>> >> LCPLL clock and PERST both goes off simultaneously.
>> >> This will cause certain Endpoints Intel NVMe not get detected, upon
>> >> next boot sequence.
>> >>
>> >> This is specifically happening with Intel P3700 400GB series.
>> >> Endpoint is expecting the clock for some amount of time after PERST is
>> >> asserted, which is not happening in Stingray (iproc based SOC).
>> >> This causes NVMe to behave in undefined way.
>> >>
>> >> On the contrary, Intel x86 boards will have ref clock running, so we
>> >> do not see this behavior there.
>> >>
>> >> Besides, PCI spec does not stipulate about such timings.
>> >> In-fact it does not tell us, whether PCIe device should consider
>> >> refclk to be available or not to be.
>> >>
>> >> It is completely up to vendor to design their EP the way they want
>> >> with respect to ref clock availability.
>> >
>> > I am unconvinced.  Designing an endpoint that relies on ref clock
>> > timing not guaranteed by the spec does not sound like a way to build
>> > reliable hardware.
>> >
>> > The PCIe Card Electromechanical spec, r2.0, sec 2.2.3 says the clock
>> > goes inactive after PERST# goes active, but doesn't specify how long.
>> > In the absence of a spec requirement, I don't see a reason to assume
>> > other systems preserve the ref clock after PERST#, so if the Intel
>> > device requires clocks for 500ms after PERST#, we should see problems
>> > on other systems.
>>
>> The reason you do not see and most likely you will not see on any
>> other system is
>> because, the ref clock is supplied by on board oscillator.
>> when PERST# is asserted, the ref clock is still available.
>>
>> but in our case, we do not have on-board clock generator, rather we
>> rely on the clock
>> coming from SOC, so if SOC reset is issued, both PERST# and the ref
>> clock goes off simultaneously.
>
> OK.  I'm not a hardware person and will have to take your word for
> this.
>
>> please also refer to the link below which stipulate on clk being
>> active after PERST# being asserted.
>> http://www.eetimes.com/document.asp?doc_id=1279299  [Figure 2:
>> Power-down waveforms]
>
> This is just a copy of Figure 2-13 from the PCIe CEM spec I cited
> above.  It's better to cite the spec itself than an article based on
> the spec.
>
>> however I am not saying that, this article has more to claim than PCIe spec.
>> but, I think the PCIe Card Electromechanical spec leaves the margin
>> for card manufactures to design the card based on the assumption
>> that ref clock could be available after PERST#  is asserted.
>
> The only statement in the spec I'm aware of is that "Clock and JTAG go
> inactive after PERST# goes inactive."  Since there's no required time
> the clock must remain active, a robust card would not assume the clock
> is available at all after PERST.  500ms is a *huge* length of time;
> I'd be very surprised if Intel designed a card that required that.
>
> I don't feel like we really got to the root cause of this, but this
> patch only hurts the iproc reboot time, so I'm OK with it.  I was just
> hoping to avoid slowing down your reboot time.
>

I appreciate your concern and valuable inputs.

However, while writing this patch I shared the similar concern.

And, after multiple discussions this is the best we could do.
reboot is less likely in data centers,
but failing to detect the NVMe after reboot has more severe business
impact than delaying reboot by 500ms.

I will rebase both the patches on top of Lorenzo's patches, and submit v7 today.

Thanks and Regards,
Oza.

>> most of the cards do not assume that, but at the least we have seen that,
>> once particular card which behaves as per the link which I have just
>> pasted above.
>>
>> >
>> > Sec 2.2 says that on power up, the power rails must be stable at least
>> > T(PVPERL) (100ms) and reference clocks must be stable at least
>> > T(PERST-CLK) (100us) before PERST# is deasserted.  I think it's more
>> > likely the problem is here.
>> >
>> > The current iproc_pcie_reset() looks like it sleeps 100ms *after* it
>> > deasserts PERST#.  Should that be *before* deasserting PERST#?
>> >
>>
>> T(PERST-CLK) (100us) before PERST# is deasserted.
>> which we are already waiting for 250us
>>
>> T(PVPERL) (100ms), the power rail is stable much before linux comes up.
>> so I still think we are meeting power up requirements.
>>
>> >> 500ms is just based on the observation and taken as safe margin.
>> >> This patch adds platform shutdown where it should be
>> >> called in device_shutdown while reboot command is issued.
>> >> 

Re: [PATCH v6 2/2] PCI: iproc: add device shutdown for PCI RC

[Oza Oza]

On Mon, Aug 21, 2017 at 2:55 AM, Bjorn Helgaas  wrote:
> On Sun, Aug 20, 2017 at 09:06:51AM +0530, Oza Oza wrote:
>> On Sun, Aug 20, 2017 at 2:34 AM, Bjorn Helgaas  wrote:
>> > On Fri, Aug 04, 2017 at 09:18:16PM +0530, Oza Pawandeep wrote:
>> >> PERST must be asserted around ~500ms before the reboot is applied.
>> >>
>> >> During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs
>> >> LCPLL clock and PERST both goes off simultaneously.
>> >> This will cause certain Endpoints Intel NVMe not get detected, upon
>> >> next boot sequence.
>> >>
>> >> This is specifically happening with Intel P3700 400GB series.
>> >> Endpoint is expecting the clock for some amount of time after PERST is
>> >> asserted, which is not happening in Stingray (iproc based SOC).
>> >> This causes NVMe to behave in undefined way.
>> >>
>> >> On the contrary, Intel x86 boards will have ref clock running, so we
>> >> do not see this behavior there.
>> >>
>> >> Besides, PCI spec does not stipulate about such timings.
>> >> In-fact it does not tell us, whether PCIe device should consider
>> >> refclk to be available or not to be.
>> >>
>> >> It is completely up to vendor to design their EP the way they want
>> >> with respect to ref clock availability.
>> >
>> > I am unconvinced.  Designing an endpoint that relies on ref clock
>> > timing not guaranteed by the spec does not sound like a way to build
>> > reliable hardware.
>> >
>> > The PCIe Card Electromechanical spec, r2.0, sec 2.2.3 says the clock
>> > goes inactive after PERST# goes active, but doesn't specify how long.
>> > In the absence of a spec requirement, I don't see a reason to assume
>> > other systems preserve the ref clock after PERST#, so if the Intel
>> > device requires clocks for 500ms after PERST#, we should see problems
>> > on other systems.
>>
>> The reason you do not see and most likely you will not see on any
>> other system is
>> because, the ref clock is supplied by on board oscillator.
>> when PERST# is asserted, the ref clock is still available.
>>
>> but in our case, we do not have on-board clock generator, rather we
>> rely on the clock
>> coming from SOC, so if SOC reset is issued, both PERST# and the ref
>> clock goes off simultaneously.
>
> OK.  I'm not a hardware person and will have to take your word for
> this.
>
>> please also refer to the link below which stipulate on clk being
>> active after PERST# being asserted.
>> http://www.eetimes.com/document.asp?doc_id=1279299  [Figure 2:
>> Power-down waveforms]
>
> This is just a copy of Figure 2-13 from the PCIe CEM spec I cited
> above.  It's better to cite the spec itself than an article based on
> the spec.
>
>> however I am not saying that, this article has more to claim than PCIe spec.
>> but, I think the PCIe Card Electromechanical spec leaves the margin
>> for card manufactures to design the card based on the assumption
>> that ref clock could be available after PERST#  is asserted.
>
> The only statement in the spec I'm aware of is that "Clock and JTAG go
> inactive after PERST# goes inactive."  Since there's no required time
> the clock must remain active, a robust card would not assume the clock
> is available at all after PERST.  500ms is a *huge* length of time;
> I'd be very surprised if Intel designed a card that required that.
>
> I don't feel like we really got to the root cause of this, but this
> patch only hurts the iproc reboot time, so I'm OK with it.  I was just
> hoping to avoid slowing down your reboot time.
>

I appreciate your concern and valuable inputs.

However, while writing this patch I shared the similar concern.

And, after multiple discussions this is the best we could do.
reboot is less likely in data centers,
but failing to detect the NVMe after reboot has more severe business
impact than delaying reboot by 500ms.

I will rebase both the patches on top of Lorenzo's patches, and submit v7 today.

Thanks and Regards,
Oza.

>> most of the cards do not assume that, but at the least we have seen that,
>> once particular card which behaves as per the link which I have just
>> pasted above.
>>
>> >
>> > Sec 2.2 says that on power up, the power rails must be stable at least
>> > T(PVPERL) (100ms) and reference clocks must be stable at least
>> > T(PERST-CLK) (100us) before PERST# is deasserted.  I think it's more
>> > likely the problem is here.
>> >
>> > The current iproc_pcie_reset() looks like it sleeps 100ms *after* it
>> > deasserts PERST#.  Should that be *before* deasserting PERST#?
>> >
>>
>> T(PERST-CLK) (100us) before PERST# is deasserted.
>> which we are already waiting for 250us
>>
>> T(PVPERL) (100ms), the power rail is stable much before linux comes up.
>> so I still think we are meeting power up requirements.
>>
>> >> 500ms is just based on the observation and taken as safe margin.
>> >> This patch adds platform shutdown where it should be
>> >> called in device_shutdown while reboot command is issued.
>> >> So in sequence first Endpoint Shutdown 

[PATCH v2] kselftest: exec: make exec test output conform to TAP13

[Paul Elder]

Convert exec test output to TAP13 format, using the ksft framework.

Signed-off-by: Paul Elder 
---

Changes from v1: Fixed a couple coding style errors and changed a forgotten
printf() to ksft_print_msg()

 tools/testing/selftests/exec/execveat.c | 151 ++--
 1 file changed, 83 insertions(+), 68 deletions(-)

diff --git a/tools/testing/selftests/exec/execveat.c 
b/tools/testing/selftests/exec/execveat.c
index 8d5d1d2ee7c1..de28050019d3 100644
--- a/tools/testing/selftests/exec/execveat.c
+++ b/tools/testing/selftests/exec/execveat.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include "../kselftest.h"
+
 static char longpath[2 * PATH_MAX] = "";
 static char *envp[] = { "IN_TEST=yes", NULL, NULL };
 static char *argv[] = { "execveat", "99", NULL };
@@ -41,23 +43,27 @@ static int _check_execveat_fail(int fd, const char *path, 
int flags,
int expected_errno, const char *errno_str)
 {
int rc;
+   char msg[512];
+
+   snprintf(msg, sizeof(msg), "Check failure of execveat(%d, '%s', %d) 
with %s...\n",
+   fd, path?:"(null)", flags, errno_str);
 
errno = 0;
-   printf("Check failure of execveat(%d, '%s', %d) with %s... ",
-   fd, path?:"(null)", flags, errno_str);
rc = execveat_(fd, path, argv, envp, flags);
 
if (rc > 0) {
-   printf("[FAIL] (unexpected success from execveat(2))\n");
+   ksft_test_result_fail(msg);
+   ksft_print_msg("unexpected success from execveat(2)\n");
return 1;
}
if (errno != expected_errno) {
-   printf("[FAIL] (expected errno %d (%s) not %d (%s)\n",
+   ksft_test_result_fail(msg);
+   ksft_print_msg("expected errno %d (%s) not %d (%s)\n",
expected_errno, strerror(expected_errno),
errno, strerror(errno));
return 1;
}
-   printf("[OK]\n");
+   ksft_test_result_pass(msg);
return 0;
 }
 
@@ -68,43 +74,48 @@ static int check_execveat_invoked_rc(int fd, const char 
*path, int flags,
int rc;
pid_t child;
int pathlen = path ? strlen(path) : 0;
+   char msg[512];
 
if (pathlen > 40)
-   printf("Check success of execveat(%d, '%.20s...%s', %d)... ",
+   snprintf(msg, sizeof(msg), "Check success of execveat(%d, 
'%.20s...%s', %d)...\n",
fd, path, (path + pathlen - 20), flags);
else
-   printf("Check success of execveat(%d, '%s', %d)... ",
+   snprintf(msg, sizeof(msg), "Check success of execveat(%d, '%s', 
%d)...\n",
fd, path?:"(null)", flags);
child = fork();
if (child < 0) {
-   printf("[FAIL] (fork() failed)\n");
+   ksft_test_result_fail(msg);
+   ksft_print_msg("fork() failed\n");
return 1;
}
if (child == 0) {
/* Child: do execveat(). */
rc = execveat_(fd, path, argv, envp, flags);
-   printf("[FAIL]: execveat() failed, rc=%d errno=%d (%s)\n",
+   ksft_exit_fail_msg("execveat() failed, rc=%d errno=%d (%s)\n",
rc, errno, strerror(errno));
exit(1);  /* should not reach here */
}
/* Parent: wait for & check child's exit status. */
rc = waitpid(child, , 0);
if (rc != child) {
-   printf("[FAIL] (waitpid(%d,...) returned %d)\n", child, rc);
+   ksft_test_result_fail(msg);
+   ksft_print_msg("waitpid(%d,...) returned %d\n", child, rc);
return 1;
}
if (!WIFEXITED(status)) {
-   printf("[FAIL] (child %d did not exit cleanly, status=%08x)\n",
+   ksft_test_result_fail(msg);
+   ksft_print_msg("child %d did not exit cleanly, status=%08x\n",
child, status);
return 1;
}
if ((WEXITSTATUS(status) != expected_rc) &&
(WEXITSTATUS(status) != expected_rc2)) {
-   printf("[FAIL] (child %d exited with %d not %d nor %d)\n",
+   ksft_test_result_fail(msg);
+   ksft_print_msg("child %d exited with %d not %d nor %d\n",
child, WEXITSTATUS(status), expected_rc, expected_rc2);
return 1;
}
-   printf("[OK]\n");
+   ksft_test_result_pass(msg);
return 0;
 }
 
@@ -127,7 +138,7 @@ static int open_or_die(const char *filename, int flags)
int fd = open(filename, flags);
 
if (fd < 0) {
-   printf("Failed to open '%s'; "
+   ksft_exit_fail_msg("Failed to open '%s'; "
"check prerequisites are available\n", filename);
exit(1);
}
@@ -180,11 +191,11 @@ static int check_execveat_pathmax(int 

[PATCH v2] kselftest: exec: make exec test output conform to TAP13

[Paul Elder]

Convert exec test output to TAP13 format, using the ksft framework.

Signed-off-by: Paul Elder 
---

Changes from v1: Fixed a couple coding style errors and changed a forgotten
printf() to ksft_print_msg()

 tools/testing/selftests/exec/execveat.c | 151 ++--
 1 file changed, 83 insertions(+), 68 deletions(-)

diff --git a/tools/testing/selftests/exec/execveat.c 
b/tools/testing/selftests/exec/execveat.c
index 8d5d1d2ee7c1..de28050019d3 100644
--- a/tools/testing/selftests/exec/execveat.c
+++ b/tools/testing/selftests/exec/execveat.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include "../kselftest.h"
+
 static char longpath[2 * PATH_MAX] = "";
 static char *envp[] = { "IN_TEST=yes", NULL, NULL };
 static char *argv[] = { "execveat", "99", NULL };
@@ -41,23 +43,27 @@ static int _check_execveat_fail(int fd, const char *path, 
int flags,
int expected_errno, const char *errno_str)
 {
int rc;
+   char msg[512];
+
+   snprintf(msg, sizeof(msg), "Check failure of execveat(%d, '%s', %d) 
with %s...\n",
+   fd, path?:"(null)", flags, errno_str);
 
errno = 0;
-   printf("Check failure of execveat(%d, '%s', %d) with %s... ",
-   fd, path?:"(null)", flags, errno_str);
rc = execveat_(fd, path, argv, envp, flags);
 
if (rc > 0) {
-   printf("[FAIL] (unexpected success from execveat(2))\n");
+   ksft_test_result_fail(msg);
+   ksft_print_msg("unexpected success from execveat(2)\n");
return 1;
}
if (errno != expected_errno) {
-   printf("[FAIL] (expected errno %d (%s) not %d (%s)\n",
+   ksft_test_result_fail(msg);
+   ksft_print_msg("expected errno %d (%s) not %d (%s)\n",
expected_errno, strerror(expected_errno),
errno, strerror(errno));
return 1;
}
-   printf("[OK]\n");
+   ksft_test_result_pass(msg);
return 0;
 }
 
@@ -68,43 +74,48 @@ static int check_execveat_invoked_rc(int fd, const char 
*path, int flags,
int rc;
pid_t child;
int pathlen = path ? strlen(path) : 0;
+   char msg[512];
 
if (pathlen > 40)
-   printf("Check success of execveat(%d, '%.20s...%s', %d)... ",
+   snprintf(msg, sizeof(msg), "Check success of execveat(%d, 
'%.20s...%s', %d)...\n",
fd, path, (path + pathlen - 20), flags);
else
-   printf("Check success of execveat(%d, '%s', %d)... ",
+   snprintf(msg, sizeof(msg), "Check success of execveat(%d, '%s', 
%d)...\n",
fd, path?:"(null)", flags);
child = fork();
if (child < 0) {
-   printf("[FAIL] (fork() failed)\n");
+   ksft_test_result_fail(msg);
+   ksft_print_msg("fork() failed\n");
return 1;
}
if (child == 0) {
/* Child: do execveat(). */
rc = execveat_(fd, path, argv, envp, flags);
-   printf("[FAIL]: execveat() failed, rc=%d errno=%d (%s)\n",
+   ksft_exit_fail_msg("execveat() failed, rc=%d errno=%d (%s)\n",
rc, errno, strerror(errno));
exit(1);  /* should not reach here */
}
/* Parent: wait for & check child's exit status. */
rc = waitpid(child, , 0);
if (rc != child) {
-   printf("[FAIL] (waitpid(%d,...) returned %d)\n", child, rc);
+   ksft_test_result_fail(msg);
+   ksft_print_msg("waitpid(%d,...) returned %d\n", child, rc);
return 1;
}
if (!WIFEXITED(status)) {
-   printf("[FAIL] (child %d did not exit cleanly, status=%08x)\n",
+   ksft_test_result_fail(msg);
+   ksft_print_msg("child %d did not exit cleanly, status=%08x\n",
child, status);
return 1;
}
if ((WEXITSTATUS(status) != expected_rc) &&
(WEXITSTATUS(status) != expected_rc2)) {
-   printf("[FAIL] (child %d exited with %d not %d nor %d)\n",
+   ksft_test_result_fail(msg);
+   ksft_print_msg("child %d exited with %d not %d nor %d\n",
child, WEXITSTATUS(status), expected_rc, expected_rc2);
return 1;
}
-   printf("[OK]\n");
+   ksft_test_result_pass(msg);
return 0;
 }
 
@@ -127,7 +138,7 @@ static int open_or_die(const char *filename, int flags)
int fd = open(filename, flags);
 
if (fd < 0) {
-   printf("Failed to open '%s'; "
+   ksft_exit_fail_msg("Failed to open '%s'; "
"check prerequisites are available\n", filename);
exit(1);
}
@@ -180,11 +191,11 @@ static int check_execveat_pathmax(int dot_dfd, const char 

Re: [PATCH v2] net: ibm: emac: Fix some error handling path in 'emac_probe()'

[David Miller]

From: Christophe JAILLET 
Date: Sun, 20 Aug 2017 06:35:00 +0200

> If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is
> known to be 0 at this point.
> So return -ENODEV instead in the first case and use 'of_iomap()' instead of
> the equivalent 'of_address_to_resource()/ioremap()' combinaison in the 2nd
> case.
> 
> Doing so, the 'rsrc_regs' field of the 'emac_instance struct' becomes
> redundant and is removed.
> 
> While at it, turn a 'err != 0' test into an equivalent 'err' to be more
> consistent.
> 
> Signed-off-by: Christophe JAILLET 
> ---
> v2: use of_iomap() to simplify code
> remove 'rsrc_regs' field of the 'emac_instance struct'
> update comment

Applied to net-next.

Re: [PATCH v2] net: ibm: emac: Fix some error handling path in 'emac_probe()'

[David Miller]

From: Christophe JAILLET 
Date: Sun, 20 Aug 2017 06:35:00 +0200

> If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is
> known to be 0 at this point.
> So return -ENODEV instead in the first case and use 'of_iomap()' instead of
> the equivalent 'of_address_to_resource()/ioremap()' combinaison in the 2nd
> case.
> 
> Doing so, the 'rsrc_regs' field of the 'emac_instance struct' becomes
> redundant and is removed.
> 
> While at it, turn a 'err != 0' test into an equivalent 'err' to be more
> consistent.
> 
> Signed-off-by: Christophe JAILLET 
> ---
> v2: use of_iomap() to simplify code
> remove 'rsrc_regs' field of the 'emac_instance struct'
> update comment

Applied to net-next.

Re: [PATCH] switchdev: documentation: minor typo fixes

[David Miller]

From: Chris Packham 
Date: Mon, 21 Aug 2017 08:52:54 +1200

> Two typos in switchdev.txt
> 
> Signed-off-by: Chris Packham 

Applied.

Re: [PATCH] switchdev: documentation: minor typo fixes

[David Miller]

From: Chris Packham 
Date: Mon, 21 Aug 2017 08:52:54 +1200

> Two typos in switchdev.txt
> 
> Signed-off-by: Chris Packham 

Applied.

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

Folks,

Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I
repost this or go back to PCI bus flags or something else? Thanks.



On 14/08/17 19:45, Alexey Kardashevskiy wrote:
> Folks,
> 
> Is there anything to change besides those compiler errors and David's
> comment in 5/5? Or the while patchset is too bad? Thanks.
> 
> 
> 
> On 07/08/17 17:25, Alexey Kardashevskiy wrote:
>> This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for 
>> mmapping MSI-X table"
>> http://www.spinics.net/lists/kvm/msg152232.html
>>
>> This time it is using "caps" in IOMMU groups. The main question is if PCI
>> bus flags or IOMMU domains are still better (and which one).
> 
>>
>>
>>
>> Here is some background:
>>
>> Current vfio-pci implementation disallows to mmap the page
>> containing MSI-X table in case that users can write directly
>> to MSI-X table and generate an incorrect MSIs.
>>
>> However, this will cause some performance issue when there
>> are some critical device registers in the same page as the
>> MSI-X table. We have to handle the mmio access to these
>> registers in QEMU emulation rather than in guest.
>>
>> To solve this issue, this series allows to expose MSI-X table
>> to userspace when hardware enables the capability of interrupt
>> remapping which can ensure that a given PCI device can only
>> shoot the MSIs assigned for it. And we introduce a new bus_flags
>> PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
>> for different archs.
>>
>>
>> This is based on sha1
>> 26c5cebfdb6c "Merge branch 'parisc-4.13-4' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux"
>>
>> Please comment. Thanks.
>>
>> Changelog:
>>
>> v5:
>> * redid the whole thing via so-called IOMMU group capabilities
>>
>> v4:
>> * rebased on recent upstream
>> * got all 6 patches from v2 (v3 was missing some)
>>
>>
>>
>>
>> Alexey Kardashevskiy (5):
>>   iommu: Add capabilities to a group
>>   iommu: Set IOMMU_GROUP_CAP_ISOLATE_MSIX if MSI controller enables IRQ
>> remapping
>>   iommu/intel/amd: Set IOMMU_GROUP_CAP_ISOLATE_MSIX if IRQ remapping is
>> enabled
>>   powerpc/iommu: Set IOMMU_GROUP_CAP_ISOLATE_MSIX
>>   vfio-pci: Allow to expose MSI-X table to userspace when safe
>>
>>  include/linux/iommu.h| 20 
>>  include/linux/vfio.h |  1 +
>>  arch/powerpc/kernel/iommu.c  |  1 +
>>  drivers/iommu/amd_iommu.c|  3 +++
>>  drivers/iommu/intel-iommu.c  |  3 +++
>>  drivers/iommu/iommu.c| 35 +++
>>  drivers/vfio/pci/vfio_pci.c  | 20 +---
>>  drivers/vfio/pci/vfio_pci_rdwr.c |  5 -
>>  drivers/vfio/vfio.c  | 15 +++
>>  9 files changed, 99 insertions(+), 4 deletions(-)
>>
> 
> 


-- 
Alexey

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

Folks,

Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I
repost this or go back to PCI bus flags or something else? Thanks.



On 14/08/17 19:45, Alexey Kardashevskiy wrote:
> Folks,
> 
> Is there anything to change besides those compiler errors and David's
> comment in 5/5? Or the while patchset is too bad? Thanks.
> 
> 
> 
> On 07/08/17 17:25, Alexey Kardashevskiy wrote:
>> This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for 
>> mmapping MSI-X table"
>> http://www.spinics.net/lists/kvm/msg152232.html
>>
>> This time it is using "caps" in IOMMU groups. The main question is if PCI
>> bus flags or IOMMU domains are still better (and which one).
> 
>>
>>
>>
>> Here is some background:
>>
>> Current vfio-pci implementation disallows to mmap the page
>> containing MSI-X table in case that users can write directly
>> to MSI-X table and generate an incorrect MSIs.
>>
>> However, this will cause some performance issue when there
>> are some critical device registers in the same page as the
>> MSI-X table. We have to handle the mmio access to these
>> registers in QEMU emulation rather than in guest.
>>
>> To solve this issue, this series allows to expose MSI-X table
>> to userspace when hardware enables the capability of interrupt
>> remapping which can ensure that a given PCI device can only
>> shoot the MSIs assigned for it. And we introduce a new bus_flags
>> PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
>> for different archs.
>>
>>
>> This is based on sha1
>> 26c5cebfdb6c "Merge branch 'parisc-4.13-4' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux"
>>
>> Please comment. Thanks.
>>
>> Changelog:
>>
>> v5:
>> * redid the whole thing via so-called IOMMU group capabilities
>>
>> v4:
>> * rebased on recent upstream
>> * got all 6 patches from v2 (v3 was missing some)
>>
>>
>>
>>
>> Alexey Kardashevskiy (5):
>>   iommu: Add capabilities to a group
>>   iommu: Set IOMMU_GROUP_CAP_ISOLATE_MSIX if MSI controller enables IRQ
>> remapping
>>   iommu/intel/amd: Set IOMMU_GROUP_CAP_ISOLATE_MSIX if IRQ remapping is
>> enabled
>>   powerpc/iommu: Set IOMMU_GROUP_CAP_ISOLATE_MSIX
>>   vfio-pci: Allow to expose MSI-X table to userspace when safe
>>
>>  include/linux/iommu.h| 20 
>>  include/linux/vfio.h |  1 +
>>  arch/powerpc/kernel/iommu.c  |  1 +
>>  drivers/iommu/amd_iommu.c|  3 +++
>>  drivers/iommu/intel-iommu.c  |  3 +++
>>  drivers/iommu/iommu.c| 35 +++
>>  drivers/vfio/pci/vfio_pci.c  | 20 +---
>>  drivers/vfio/pci/vfio_pci_rdwr.c |  5 -
>>  drivers/vfio/vfio.c  | 15 +++
>>  9 files changed, 99 insertions(+), 4 deletions(-)
>>
> 
> 


-- 
Alexey

Re: [PATCH v2 5/5] thermal: Add Tegra BPMP thermal sensor driver

[Wei Ni]

On Friday, August 11, 2017 10:57 AM, Zhang Rui wrote:
> On Mon, 2017-07-24 at 19:29 +0300, Mikko Perttunen wrote:
>> On Tegra186, the BPMP (Boot and Power Management Processor) exposes
>> an
>> interface to thermal sensors on the system-on-chip. This driver
>> implements access to the interface. It supports reading the
>> temperature, setting trip points and receiving notification of a
>> tripped trip point.
>>
>> Signed-off-by: Mikko Perttunen 
> 
> Wei Ni,
> 
> what do you think of this patch?

Reviewed this patch, it looked fine to me.

> 
> thanks,
> rui
>> ---
>> v2:
>> - don't allocate space for disabled zones
>> - allow compilation with COMPILE_TEST
>>
>>  drivers/thermal/Makefile |   2 +-
>>  drivers/thermal/tegra/Kconfig|   7 +
>>  drivers/thermal/tegra/Makefile   |   3 +-
>>  drivers/thermal/tegra/bpmp-thermal.c | 263
>> +++
>>  4 files changed, 273 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/thermal/tegra/bpmp-thermal.c
>>
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 094d7039981c..c03dccdba7b8 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -54,7 +54,7 @@ obj-$(CONFIG_INTEL_BXT_PMIC_THERMAL) +=
>> intel_bxt_pmic_thermal.o
>>  obj-$(CONFIG_INTEL_PCH_THERMAL) += intel_pch_thermal.o
>>  obj-$(CONFIG_ST_THERMAL)+= st/
>>  obj-$(CONFIG_QCOM_TSENS)+= qcom/
>> -obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra/
>> +obj-y   += tegra/
>>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>>  obj-$(CONFIG_MTK_THERMAL)   += mtk_thermal.o
>>  obj-$(CONFIG_GENERIC_ADC_THERMAL)   += thermal-generic-adc.o
>> diff --git a/drivers/thermal/tegra/Kconfig
>> b/drivers/thermal/tegra/Kconfig
>> index cec586ec7e4b..f8740f7852e3 100644
>> --- a/drivers/thermal/tegra/Kconfig
>> +++ b/drivers/thermal/tegra/Kconfig
>> @@ -10,4 +10,11 @@ config TEGRA_SOCTHERM
>>zones to manage temperatures. This option is also required
>> for the
>>emergency thermal reset (thermtrip) feature to function.
>>  
>> +config TEGRA_BPMP_THERMAL
>> +tristate "Tegra BPMP thermal sensing"
>> +depends on TEGRA_BPMP || COMPILE_TEST
>> +help
>> + Enable this option for support for sensing system
>> temperature of NVIDIA
>> + Tegra systems-on-chip with the BPMP coprocessor (Tegra186).
>> +
>>  endmenu
>> diff --git a/drivers/thermal/tegra/Makefile
>> b/drivers/thermal/tegra/Makefile
>> index 1ce1af2cf0f5..757abcd1feaf 100644
>> --- a/drivers/thermal/tegra/Makefile
>> +++ b/drivers/thermal/tegra/Makefile
>> @@ -1,4 +1,5 @@
>> -obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra-soctherm.o
>> +obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra-soctherm.o
>> +obj-$(CONFIG_TEGRA_BPMP_THERMAL)+= bpmp-thermal.o
>>  
>>  tegra-soctherm-y:= soctherm.o
>> soctherm-fuse.o
>>  tegra-soctherm-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-
>> soctherm.o
>> diff --git a/drivers/thermal/tegra/bpmp-thermal.c
>> b/drivers/thermal/tegra/bpmp-thermal.c
>> new file mode 100644
>> index ..b0980dbca3b3
>> --- /dev/null
>> +++ b/drivers/thermal/tegra/bpmp-thermal.c
>> @@ -0,0 +1,263 @@
>> +/*
>> + * Copyright (c) 2015-2017, NVIDIA CORPORATION.  All rights
>> reserved.
>> + *
>> + * Author:
>> + *  Mikko Perttunen 
>> + *  Aapo Vienamo
>> + *
>> + * 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 
>> +
>> +struct tegra_bpmp_thermal_zone {
>> +struct tegra_bpmp_thermal *tegra;
>> +struct thermal_zone_device *tzd;
>> +struct work_struct tz_device_update_work;
>> +unsigned int idx;
>> +};
>> +
>> +struct tegra_bpmp_thermal {
>> +struct device *dev;
>> +struct tegra_bpmp *bpmp;
>> +unsigned int num_zones;
>> +struct tegra_bpmp_thermal_zone **zones;
>> +};
>> +
>> +static int tegra_bpmp_thermal_get_temp(void *data, int *out_temp)
>> +{
>> +struct tegra_bpmp_thermal_zone *zone = data;
>> +struct mrq_thermal_host_to_bpmp_request req;
>> +union mrq_thermal_bpmp_to_host_response reply;
>> +struct tegra_bpmp_message msg;
>> +int err;
>> +
>> +memset(, 0, sizeof(req));
>> +req.type = CMD_THERMAL_GET_TEMP;
>> +req.get_temp.zone = zone->idx;
>> +
>> +memset(, 0, sizeof(msg));
>> +msg.mrq = MRQ_THERMAL;
>> +msg.tx.data = 
>> +msg.tx.size = sizeof(req);

Re: [PATCH v2 5/5] thermal: Add Tegra BPMP thermal sensor driver

[Wei Ni]

On Friday, August 11, 2017 10:57 AM, Zhang Rui wrote:
> On Mon, 2017-07-24 at 19:29 +0300, Mikko Perttunen wrote:
>> On Tegra186, the BPMP (Boot and Power Management Processor) exposes
>> an
>> interface to thermal sensors on the system-on-chip. This driver
>> implements access to the interface. It supports reading the
>> temperature, setting trip points and receiving notification of a
>> tripped trip point.
>>
>> Signed-off-by: Mikko Perttunen 
> 
> Wei Ni,
> 
> what do you think of this patch?

Reviewed this patch, it looked fine to me.

> 
> thanks,
> rui
>> ---
>> v2:
>> - don't allocate space for disabled zones
>> - allow compilation with COMPILE_TEST
>>
>>  drivers/thermal/Makefile |   2 +-
>>  drivers/thermal/tegra/Kconfig|   7 +
>>  drivers/thermal/tegra/Makefile   |   3 +-
>>  drivers/thermal/tegra/bpmp-thermal.c | 263
>> +++
>>  4 files changed, 273 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/thermal/tegra/bpmp-thermal.c
>>
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 094d7039981c..c03dccdba7b8 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -54,7 +54,7 @@ obj-$(CONFIG_INTEL_BXT_PMIC_THERMAL) +=
>> intel_bxt_pmic_thermal.o
>>  obj-$(CONFIG_INTEL_PCH_THERMAL) += intel_pch_thermal.o
>>  obj-$(CONFIG_ST_THERMAL)+= st/
>>  obj-$(CONFIG_QCOM_TSENS)+= qcom/
>> -obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra/
>> +obj-y   += tegra/
>>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>>  obj-$(CONFIG_MTK_THERMAL)   += mtk_thermal.o
>>  obj-$(CONFIG_GENERIC_ADC_THERMAL)   += thermal-generic-adc.o
>> diff --git a/drivers/thermal/tegra/Kconfig
>> b/drivers/thermal/tegra/Kconfig
>> index cec586ec7e4b..f8740f7852e3 100644
>> --- a/drivers/thermal/tegra/Kconfig
>> +++ b/drivers/thermal/tegra/Kconfig
>> @@ -10,4 +10,11 @@ config TEGRA_SOCTHERM
>>zones to manage temperatures. This option is also required
>> for the
>>emergency thermal reset (thermtrip) feature to function.
>>  
>> +config TEGRA_BPMP_THERMAL
>> +tristate "Tegra BPMP thermal sensing"
>> +depends on TEGRA_BPMP || COMPILE_TEST
>> +help
>> + Enable this option for support for sensing system
>> temperature of NVIDIA
>> + Tegra systems-on-chip with the BPMP coprocessor (Tegra186).
>> +
>>  endmenu
>> diff --git a/drivers/thermal/tegra/Makefile
>> b/drivers/thermal/tegra/Makefile
>> index 1ce1af2cf0f5..757abcd1feaf 100644
>> --- a/drivers/thermal/tegra/Makefile
>> +++ b/drivers/thermal/tegra/Makefile
>> @@ -1,4 +1,5 @@
>> -obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra-soctherm.o
>> +obj-$(CONFIG_TEGRA_SOCTHERM)+= tegra-soctherm.o
>> +obj-$(CONFIG_TEGRA_BPMP_THERMAL)+= bpmp-thermal.o
>>  
>>  tegra-soctherm-y:= soctherm.o
>> soctherm-fuse.o
>>  tegra-soctherm-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-
>> soctherm.o
>> diff --git a/drivers/thermal/tegra/bpmp-thermal.c
>> b/drivers/thermal/tegra/bpmp-thermal.c
>> new file mode 100644
>> index ..b0980dbca3b3
>> --- /dev/null
>> +++ b/drivers/thermal/tegra/bpmp-thermal.c
>> @@ -0,0 +1,263 @@
>> +/*
>> + * Copyright (c) 2015-2017, NVIDIA CORPORATION.  All rights
>> reserved.
>> + *
>> + * Author:
>> + *  Mikko Perttunen 
>> + *  Aapo Vienamo
>> + *
>> + * 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 
>> +
>> +struct tegra_bpmp_thermal_zone {
>> +struct tegra_bpmp_thermal *tegra;
>> +struct thermal_zone_device *tzd;
>> +struct work_struct tz_device_update_work;
>> +unsigned int idx;
>> +};
>> +
>> +struct tegra_bpmp_thermal {
>> +struct device *dev;
>> +struct tegra_bpmp *bpmp;
>> +unsigned int num_zones;
>> +struct tegra_bpmp_thermal_zone **zones;
>> +};
>> +
>> +static int tegra_bpmp_thermal_get_temp(void *data, int *out_temp)
>> +{
>> +struct tegra_bpmp_thermal_zone *zone = data;
>> +struct mrq_thermal_host_to_bpmp_request req;
>> +union mrq_thermal_bpmp_to_host_response reply;
>> +struct tegra_bpmp_message msg;
>> +int err;
>> +
>> +memset(, 0, sizeof(req));
>> +req.type = CMD_THERMAL_GET_TEMP;
>> +req.get_temp.zone = zone->idx;
>> +
>> +memset(, 0, sizeof(msg));
>> +msg.mrq = MRQ_THERMAL;
>> +msg.tx.data = 
>> +msg.tx.size = sizeof(req);
>> +msg.rx.data = 
>> +msg.rx.size = sizeof(reply);
>> +

Re: [GIT PULL] tpmdd updates for Linux 4.14

[James Morris]

On Sat, 19 Aug 2017, Jarkko Sakkinen wrote:

> Hi James,
> 
> Not much this time except a few fixes.
> 
> /Jarkko
> 
> The following changes since commit 76e22e212a850bbd16cf49f9c586d4635507e0b5:
> 
>   apparmor: fix incorrect type assignment when freeing proxies (2017-08-18 
> 06:45:37 -0700)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20170819
> 
> for you to fetch changes up to 08f49ffce0522ae4738308f400795ee4d92f6e3d:

Pulled.


-- 
James Morris

Re: [GIT PULL] tpmdd updates for Linux 4.14

[James Morris]

On Sat, 19 Aug 2017, Jarkko Sakkinen wrote:

> Hi James,
> 
> Not much this time except a few fixes.
> 
> /Jarkko
> 
> The following changes since commit 76e22e212a850bbd16cf49f9c586d4635507e0b5:
> 
>   apparmor: fix incorrect type assignment when freeing proxies (2017-08-18 
> 06:45:37 -0700)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20170819
> 
> for you to fetch changes up to 08f49ffce0522ae4738308f400795ee4d92f6e3d:

Pulled.


-- 
James Morris

[PATCH v1 1/3] clk: rockchip: add rv1108 ACLK_GAMC and PCLK_GMAC ID

[Elaine Zhang]

This patch exports gmac aclk and pclk for dts reference.

Signed-off-by: Elaine Zhang 
---
 include/dt-bindings/clock/rv1108-cru.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/clock/rv1108-cru.h 
b/include/dt-bindings/clock/rv1108-cru.h
index f269d833e41a..2239ae2a19b9 100644
--- a/include/dt-bindings/clock/rv1108-cru.h
+++ b/include/dt-bindings/clock/rv1108-cru.h
@@ -110,6 +110,7 @@
 #define ACLK_CIF2  207
 #define ACLK_CIF3  208
 #define ACLK_PERI  209
+#define ACLK_GMAC  210
 
 /* pclk gates */
 #define PCLK_GPIO1 256
@@ -141,6 +142,7 @@
 #define PCLK_EFUSE0282
 #define PCLK_EFUSE1283
 #define PCLK_WDT   284
+#define PCLK_GMAC  285
 
 /* hclk gates */
 #define HCLK_I2S0_8CH  320
-- 
1.9.1

Re: [PATCH v2 00/20] Speculative page faults

[Sergey Senozhatsky]

Hello,

On (08/18/17 00:04), Laurent Dufour wrote:
> This is a port on kernel 4.13 of the work done by Peter Zijlstra to
> handle page fault without holding the mm semaphore [1].
> 
> The idea is to try to handle user space page faults without holding the
> mmap_sem. This should allow better concurrency for massively threaded
> process since the page fault handler will not wait for other threads memory
> layout change to be done, assuming that this change is done in another part
> of the process's memory space. This type page fault is named speculative
> page fault. If the speculative page fault fails because of a concurrency is
> detected or because underlying PMD or PTE tables are not yet allocating, it
> is failing its processing and a classic page fault is then tried.
> 
> The speculative page fault (SPF) has to look for the VMA matching the fault
> address without holding the mmap_sem, so the VMA list is now managed using
> SRCU allowing lockless walking. The only impact would be the deferred file
> derefencing in the case of a file mapping, since the file pointer is
> released once the SRCU cleaning is done.  This patch relies on the change
> done recently by Paul McKenney in SRCU which now runs a callback per CPU
> instead of per SRCU structure [1].
> 
> The VMA's attributes checked during the speculative page fault processing
> have to be protected against parallel changes. This is done by using a per
> VMA sequence lock. This sequence lock allows the speculative page fault
> handler to fast check for parallel changes in progress and to abort the
> speculative page fault in that case.
> 
> Once the VMA is found, the speculative page fault handler would check for
> the VMA's attributes to verify that the page fault has to be handled
> correctly or not. Thus the VMA is protected through a sequence lock which
> allows fast detection of concurrent VMA changes. If such a change is
> detected, the speculative page fault is aborted and a *classic* page fault
> is tried.  VMA sequence locks are added when VMA attributes which are
> checked during the page fault are modified.
> 
> When the PTE is fetched, the VMA is checked to see if it has been changed,
> so once the page table is locked, the VMA is valid, so any other changes
> leading to touching this PTE will need to lock the page table, so no
> parallel change is possible at this time.

[ 2311.315400] ==
[ 2311.315401] WARNING: possible circular locking dependency detected
[ 2311.315403] 4.13.0-rc5-next-20170817-dbg-00039-gaf11d7500492-dirty #1743 Not 
tainted
[ 2311.315404] --
[ 2311.315406] khugepaged/43 is trying to acquire lock:
[ 2311.315407]  (>i_mmap_rwsem){}, at: [] 
rmap_walk_file+0x5a/0x147
[ 2311.315415] 
   but task is already holding lock:
[ 2311.315416]  (fs_reclaim){+.+.}, at: [] 
fs_reclaim_acquire+0x12/0x35
[ 2311.315420] 
   which lock already depends on the new lock.

[ 2311.315422] 
   the existing dependency chain (in reverse order) is:
[ 2311.315423] 
   -> #3 (fs_reclaim){+.+.}:
[ 2311.315427]fs_reclaim_acquire+0x32/0x35
[ 2311.315429]__alloc_pages_nodemask+0x8d/0x217
[ 2311.315432]pte_alloc_one+0x13/0x5e
[ 2311.315434]__pte_alloc+0x1f/0x83
[ 2311.315436]move_page_tables+0x2c9/0x5ac
[ 2311.315438]move_vma.isra.25+0xff/0x2a2
[ 2311.315439]SyS_mremap+0x41b/0x49e
[ 2311.315442]entry_SYSCALL_64_fastpath+0x18/0xad
[ 2311.315443] 
   -> #2 (>vm_sequence/1){+.+.}:
[ 2311.315449]write_seqcount_begin_nested+0x1b/0x1d
[ 2311.315451]__vma_adjust+0x1b7/0x5d6
[ 2311.315453]__split_vma+0x142/0x1a3
[ 2311.315454]do_munmap+0x128/0x2af
[ 2311.315455]vm_munmap+0x5a/0x73
[ 2311.315458]elf_map+0xb1/0xce
[ 2311.315459]load_elf_binary+0x8e0/0x1348
[ 2311.315462]search_binary_handler+0x70/0x1f3
[ 2311.315464]load_script+0x1a6/0x1b5
[ 2311.315466]search_binary_handler+0x70/0x1f3
[ 2311.315468]do_execveat_common+0x461/0x691
[ 2311.315471]kernel_init+0x5a/0xf0
[ 2311.315472]ret_from_fork+0x27/0x40
[ 2311.315473] 
   -> #1 (>vm_sequence){+.+.}:
[ 2311.315478]write_seqcount_begin_nested+0x1b/0x1d
[ 2311.315480]__vma_adjust+0x19c/0x5d6
[ 2311.315481]__split_vma+0x142/0x1a3
[ 2311.315482]do_munmap+0x128/0x2af
[ 2311.315484]vm_munmap+0x5a/0x73
[ 2311.315485]elf_map+0xb1/0xce
[ 2311.315487]load_elf_binary+0x8e0/0x1348
[ 2311.315489]search_binary_handler+0x70/0x1f3
[ 2311.315490]load_script+0x1a6/0x1b5
[ 2311.315492]search_binary_handler+0x70/0x1f3
[ 2311.315494]do_execveat_common+0x461/0x691
[ 2311.315496]kernel_init+0x5a/0xf0
[ 2311.315497]ret_from_fork+0x27/0x40
[ 2311.315498] 
   -> #0 

[PATCH v1 1/3] clk: rockchip: add rv1108 ACLK_GAMC and PCLK_GMAC ID

[Elaine Zhang]

This patch exports gmac aclk and pclk for dts reference.

Signed-off-by: Elaine Zhang 
---
 include/dt-bindings/clock/rv1108-cru.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/clock/rv1108-cru.h 
b/include/dt-bindings/clock/rv1108-cru.h
index f269d833e41a..2239ae2a19b9 100644
--- a/include/dt-bindings/clock/rv1108-cru.h
+++ b/include/dt-bindings/clock/rv1108-cru.h
@@ -110,6 +110,7 @@
 #define ACLK_CIF2  207
 #define ACLK_CIF3  208
 #define ACLK_PERI  209
+#define ACLK_GMAC  210
 
 /* pclk gates */
 #define PCLK_GPIO1 256
@@ -141,6 +142,7 @@
 #define PCLK_EFUSE0282
 #define PCLK_EFUSE1283
 #define PCLK_WDT   284
+#define PCLK_GMAC  285
 
 /* hclk gates */
 #define HCLK_I2S0_8CH  320
-- 
1.9.1

Re: [PATCH v2 00/20] Speculative page faults

[Sergey Senozhatsky]

Hello,

On (08/18/17 00:04), Laurent Dufour wrote:
> This is a port on kernel 4.13 of the work done by Peter Zijlstra to
> handle page fault without holding the mm semaphore [1].
> 
> The idea is to try to handle user space page faults without holding the
> mmap_sem. This should allow better concurrency for massively threaded
> process since the page fault handler will not wait for other threads memory
> layout change to be done, assuming that this change is done in another part
> of the process's memory space. This type page fault is named speculative
> page fault. If the speculative page fault fails because of a concurrency is
> detected or because underlying PMD or PTE tables are not yet allocating, it
> is failing its processing and a classic page fault is then tried.
> 
> The speculative page fault (SPF) has to look for the VMA matching the fault
> address without holding the mmap_sem, so the VMA list is now managed using
> SRCU allowing lockless walking. The only impact would be the deferred file
> derefencing in the case of a file mapping, since the file pointer is
> released once the SRCU cleaning is done.  This patch relies on the change
> done recently by Paul McKenney in SRCU which now runs a callback per CPU
> instead of per SRCU structure [1].
> 
> The VMA's attributes checked during the speculative page fault processing
> have to be protected against parallel changes. This is done by using a per
> VMA sequence lock. This sequence lock allows the speculative page fault
> handler to fast check for parallel changes in progress and to abort the
> speculative page fault in that case.
> 
> Once the VMA is found, the speculative page fault handler would check for
> the VMA's attributes to verify that the page fault has to be handled
> correctly or not. Thus the VMA is protected through a sequence lock which
> allows fast detection of concurrent VMA changes. If such a change is
> detected, the speculative page fault is aborted and a *classic* page fault
> is tried.  VMA sequence locks are added when VMA attributes which are
> checked during the page fault are modified.
> 
> When the PTE is fetched, the VMA is checked to see if it has been changed,
> so once the page table is locked, the VMA is valid, so any other changes
> leading to touching this PTE will need to lock the page table, so no
> parallel change is possible at this time.

[ 2311.315400] ==
[ 2311.315401] WARNING: possible circular locking dependency detected
[ 2311.315403] 4.13.0-rc5-next-20170817-dbg-00039-gaf11d7500492-dirty #1743 Not 
tainted
[ 2311.315404] --
[ 2311.315406] khugepaged/43 is trying to acquire lock:
[ 2311.315407]  (>i_mmap_rwsem){}, at: [] 
rmap_walk_file+0x5a/0x147
[ 2311.315415] 
   but task is already holding lock:
[ 2311.315416]  (fs_reclaim){+.+.}, at: [] 
fs_reclaim_acquire+0x12/0x35
[ 2311.315420] 
   which lock already depends on the new lock.

[ 2311.315422] 
   the existing dependency chain (in reverse order) is:
[ 2311.315423] 
   -> #3 (fs_reclaim){+.+.}:
[ 2311.315427]fs_reclaim_acquire+0x32/0x35
[ 2311.315429]__alloc_pages_nodemask+0x8d/0x217
[ 2311.315432]pte_alloc_one+0x13/0x5e
[ 2311.315434]__pte_alloc+0x1f/0x83
[ 2311.315436]move_page_tables+0x2c9/0x5ac
[ 2311.315438]move_vma.isra.25+0xff/0x2a2
[ 2311.315439]SyS_mremap+0x41b/0x49e
[ 2311.315442]entry_SYSCALL_64_fastpath+0x18/0xad
[ 2311.315443] 
   -> #2 (>vm_sequence/1){+.+.}:
[ 2311.315449]write_seqcount_begin_nested+0x1b/0x1d
[ 2311.315451]__vma_adjust+0x1b7/0x5d6
[ 2311.315453]__split_vma+0x142/0x1a3
[ 2311.315454]do_munmap+0x128/0x2af
[ 2311.315455]vm_munmap+0x5a/0x73
[ 2311.315458]elf_map+0xb1/0xce
[ 2311.315459]load_elf_binary+0x8e0/0x1348
[ 2311.315462]search_binary_handler+0x70/0x1f3
[ 2311.315464]load_script+0x1a6/0x1b5
[ 2311.315466]search_binary_handler+0x70/0x1f3
[ 2311.315468]do_execveat_common+0x461/0x691
[ 2311.315471]kernel_init+0x5a/0xf0
[ 2311.315472]ret_from_fork+0x27/0x40
[ 2311.315473] 
   -> #1 (>vm_sequence){+.+.}:
[ 2311.315478]write_seqcount_begin_nested+0x1b/0x1d
[ 2311.315480]__vma_adjust+0x19c/0x5d6
[ 2311.315481]__split_vma+0x142/0x1a3
[ 2311.315482]do_munmap+0x128/0x2af
[ 2311.315484]vm_munmap+0x5a/0x73
[ 2311.315485]elf_map+0xb1/0xce
[ 2311.315487]load_elf_binary+0x8e0/0x1348
[ 2311.315489]search_binary_handler+0x70/0x1f3
[ 2311.315490]load_script+0x1a6/0x1b5
[ 2311.315492]search_binary_handler+0x70/0x1f3
[ 2311.315494]do_execveat_common+0x461/0x691
[ 2311.315496]kernel_init+0x5a/0xf0
[ 2311.315497]ret_from_fork+0x27/0x40
[ 2311.315498] 
   -> #0 

[PATCH v1 3/3] clk: rockchip: rv1108: rename macphy to mac

[Elaine Zhang]

This MAC has no internal phy for rv1108.

Signed-off-by: Elaine Zhang 
---
 drivers/clk/rockchip/clk-rv1108.c  | 12 ++--
 include/dt-bindings/clock/rv1108-cru.h |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rv1108.c 
b/drivers/clk/rockchip/clk-rv1108.c
index 0e441ec21e90..658da17c9d99 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -140,7 +140,7 @@ enum rv1108_plls {
 PNAME(mux_uart0_p) = { "uart0_src", "uart0_frac", "xin24m" };
 PNAME(mux_uart1_p) = { "uart1_src", "uart1_frac", "xin24m" };
 PNAME(mux_uart2_p) = { "uart2_src", "uart2_frac", "xin24m" };
-PNAME(mux_sclk_macphy_p)   = { "ext_gmac", "sclk_macphy_pre" };
+PNAME(mux_sclk_mac_p)  = { "ext_gmac", "sclk_mac_pre" };
 PNAME(mux_i2s0_pre_p)  = { "i2s0_src", "i2s0_frac", "ext_i2s", 
"xin12m" };
 PNAME(mux_i2s_out_p)   = { "i2s0_pre", "xin12m" };
 PNAME(mux_i2s1_p)  = { "i2s1_src", "i2s1_frac", "dummy", "xin12m" 
};
@@ -755,14 +755,14 @@ enum rv1108_plls {
RV1108_CLKGATE_CON(5), 4, GFLAGS),
GATE(HCLK_SFC, "hclk_sfc", "hclk_periph", 0, RV1108_CLKGATE_CON(15), 
10, GFLAGS),
 
-   COMPOSITE(SCLK_MACPHY_PRE, "sclk_macphy_pre", mux_pll_src_apll_gpll_p, 
0,
+   COMPOSITE(SCLK_MAC_PRE, "sclk_mac_pre", mux_pll_src_apll_gpll_p, 0,
RV1108_CLKSEL_CON(24), 12, 1, MFLAGS, 0, 5, DFLAGS,
RV1108_CLKGATE_CON(4), 10, GFLAGS),
-   MUX(SCLK_MACPHY, "sclk_macphy", mux_sclk_macphy_p, CLK_SET_RATE_PARENT,
+   MUX(SCLK_MAC, "sclk_mac", mux_sclk_mac_p, CLK_SET_RATE_PARENT,
RV1108_CLKSEL_CON(24), 8, 1, MFLAGS),
-   GATE(SCLK_MACPHY_RX, "sclk_macphy_rx", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 8, GFLAGS),
-   GATE(SCLK_MAC_REF, "sclk_mac_ref", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 6, GFLAGS),
-   GATE(SCLK_MAC_REFOUT, "sclk_mac_refout", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 7, GFLAGS),
+   GATE(SCLK_MAC_RX, "sclk_mac_rx", "sclk_mac", 0, RV1108_CLKGATE_CON(4), 
8, GFLAGS),
+   GATE(SCLK_MAC_REF, "sclk_mac_ref", "sclk_mac", 0, 
RV1108_CLKGATE_CON(4), 6, GFLAGS),
+   GATE(SCLK_MAC_REFOUT, "sclk_mac_refout", "sclk_mac", 0, 
RV1108_CLKGATE_CON(4), 7, GFLAGS),
GATE(ACLK_GMAC, "aclk_gmac", "aclk_periph", 0, RV1108_CLKGATE_CON(15), 
4, GFLAGS),
GATE(PCLK_GMAC, "pclk_gmac", "pclk_periph", 0, RV1108_CLKGATE_CON(15), 
5, GFLAGS),
 
diff --git a/include/dt-bindings/clock/rv1108-cru.h 
b/include/dt-bindings/clock/rv1108-cru.h
index 2239ae2a19b9..d8d0e0456dc2 100644
--- a/include/dt-bindings/clock/rv1108-cru.h
+++ b/include/dt-bindings/clock/rv1108-cru.h
@@ -67,9 +67,9 @@
 #define SCLK_SPI   108
 #define SCLK_SARADC109
 #define SCLK_TSADC 110
-#define SCLK_MACPHY_PRE111
-#define SCLK_MACPHY112
-#define SCLK_MACPHY_RX 113
+#define SCLK_MAC_PRE   111
+#define SCLK_MAC   112
+#define SCLK_MAC_RX113
 #define SCLK_MAC_REF   114
 #define SCLK_MAC_REFOUT115
 #define SCLK_DSP_PFM   116
-- 
1.9.1

[PATCH v1 3/3] clk: rockchip: rv1108: rename macphy to mac

[Elaine Zhang]

This MAC has no internal phy for rv1108.

Signed-off-by: Elaine Zhang 
---
 drivers/clk/rockchip/clk-rv1108.c  | 12 ++--
 include/dt-bindings/clock/rv1108-cru.h |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rv1108.c 
b/drivers/clk/rockchip/clk-rv1108.c
index 0e441ec21e90..658da17c9d99 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -140,7 +140,7 @@ enum rv1108_plls {
 PNAME(mux_uart0_p) = { "uart0_src", "uart0_frac", "xin24m" };
 PNAME(mux_uart1_p) = { "uart1_src", "uart1_frac", "xin24m" };
 PNAME(mux_uart2_p) = { "uart2_src", "uart2_frac", "xin24m" };
-PNAME(mux_sclk_macphy_p)   = { "ext_gmac", "sclk_macphy_pre" };
+PNAME(mux_sclk_mac_p)  = { "ext_gmac", "sclk_mac_pre" };
 PNAME(mux_i2s0_pre_p)  = { "i2s0_src", "i2s0_frac", "ext_i2s", 
"xin12m" };
 PNAME(mux_i2s_out_p)   = { "i2s0_pre", "xin12m" };
 PNAME(mux_i2s1_p)  = { "i2s1_src", "i2s1_frac", "dummy", "xin12m" 
};
@@ -755,14 +755,14 @@ enum rv1108_plls {
RV1108_CLKGATE_CON(5), 4, GFLAGS),
GATE(HCLK_SFC, "hclk_sfc", "hclk_periph", 0, RV1108_CLKGATE_CON(15), 
10, GFLAGS),
 
-   COMPOSITE(SCLK_MACPHY_PRE, "sclk_macphy_pre", mux_pll_src_apll_gpll_p, 
0,
+   COMPOSITE(SCLK_MAC_PRE, "sclk_mac_pre", mux_pll_src_apll_gpll_p, 0,
RV1108_CLKSEL_CON(24), 12, 1, MFLAGS, 0, 5, DFLAGS,
RV1108_CLKGATE_CON(4), 10, GFLAGS),
-   MUX(SCLK_MACPHY, "sclk_macphy", mux_sclk_macphy_p, CLK_SET_RATE_PARENT,
+   MUX(SCLK_MAC, "sclk_mac", mux_sclk_mac_p, CLK_SET_RATE_PARENT,
RV1108_CLKSEL_CON(24), 8, 1, MFLAGS),
-   GATE(SCLK_MACPHY_RX, "sclk_macphy_rx", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 8, GFLAGS),
-   GATE(SCLK_MAC_REF, "sclk_mac_ref", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 6, GFLAGS),
-   GATE(SCLK_MAC_REFOUT, "sclk_mac_refout", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 7, GFLAGS),
+   GATE(SCLK_MAC_RX, "sclk_mac_rx", "sclk_mac", 0, RV1108_CLKGATE_CON(4), 
8, GFLAGS),
+   GATE(SCLK_MAC_REF, "sclk_mac_ref", "sclk_mac", 0, 
RV1108_CLKGATE_CON(4), 6, GFLAGS),
+   GATE(SCLK_MAC_REFOUT, "sclk_mac_refout", "sclk_mac", 0, 
RV1108_CLKGATE_CON(4), 7, GFLAGS),
GATE(ACLK_GMAC, "aclk_gmac", "aclk_periph", 0, RV1108_CLKGATE_CON(15), 
4, GFLAGS),
GATE(PCLK_GMAC, "pclk_gmac", "pclk_periph", 0, RV1108_CLKGATE_CON(15), 
5, GFLAGS),
 
diff --git a/include/dt-bindings/clock/rv1108-cru.h 
b/include/dt-bindings/clock/rv1108-cru.h
index 2239ae2a19b9..d8d0e0456dc2 100644
--- a/include/dt-bindings/clock/rv1108-cru.h
+++ b/include/dt-bindings/clock/rv1108-cru.h
@@ -67,9 +67,9 @@
 #define SCLK_SPI   108
 #define SCLK_SARADC109
 #define SCLK_TSADC 110
-#define SCLK_MACPHY_PRE111
-#define SCLK_MACPHY112
-#define SCLK_MACPHY_RX 113
+#define SCLK_MAC_PRE   111
+#define SCLK_MAC   112
+#define SCLK_MAC_RX113
 #define SCLK_MAC_REF   114
 #define SCLK_MAC_REFOUT115
 #define SCLK_DSP_PFM   116
-- 
1.9.1

[PATCH v1 0/3] clk: rockchip: rv1108: support mac clk

[Elaine Zhang]

Elaine Zhang (3):
  clk: rockchip: add rv1108 ACLK_GAMC and PCLK_GMAC ID
  clk: rockchip: rv1108: add ACLK_GMAC and PCLK_GMAC clk id
  clk: rockchip: rv1108: rename macphy to mac

 drivers/clk/rockchip/clk-rv1108.c  | 14 --
 include/dt-bindings/clock/rv1108-cru.h |  8 +---
 2 files changed, 13 insertions(+), 9 deletions(-)

-- 
1.9.1

[PATCH v1 2/3] clk: rockchip: rv1108: add ACLK_GMAC and PCLK_GMAC clk id

[Elaine Zhang]

Signed-off-by: Elaine Zhang 
---
 drivers/clk/rockchip/clk-rv1108.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rv1108.c 
b/drivers/clk/rockchip/clk-rv1108.c
index d1065dd9f442..0e441ec21e90 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -763,6 +763,8 @@ enum rv1108_plls {
GATE(SCLK_MACPHY_RX, "sclk_macphy_rx", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 8, GFLAGS),
GATE(SCLK_MAC_REF, "sclk_mac_ref", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 6, GFLAGS),
GATE(SCLK_MAC_REFOUT, "sclk_mac_refout", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 7, GFLAGS),
+   GATE(ACLK_GMAC, "aclk_gmac", "aclk_periph", 0, RV1108_CLKGATE_CON(15), 
4, GFLAGS),
+   GATE(PCLK_GMAC, "pclk_gmac", "pclk_periph", 0, RV1108_CLKGATE_CON(15), 
5, GFLAGS),
 
MMC(SCLK_SDMMC_DRV,"sdmmc_drv","sclk_sdmmc", RV1108_SDMMC_CON0, 
1),
MMC(SCLK_SDMMC_SAMPLE, "sdmmc_sample", "sclk_sdmmc", RV1108_SDMMC_CON1, 
1),
-- 
1.9.1

[PATCH v1 0/3] clk: rockchip: rv1108: support mac clk

[Elaine Zhang]

Elaine Zhang (3):
  clk: rockchip: add rv1108 ACLK_GAMC and PCLK_GMAC ID
  clk: rockchip: rv1108: add ACLK_GMAC and PCLK_GMAC clk id
  clk: rockchip: rv1108: rename macphy to mac

 drivers/clk/rockchip/clk-rv1108.c  | 14 --
 include/dt-bindings/clock/rv1108-cru.h |  8 +---
 2 files changed, 13 insertions(+), 9 deletions(-)

-- 
1.9.1

[PATCH v1 2/3] clk: rockchip: rv1108: add ACLK_GMAC and PCLK_GMAC clk id

[Elaine Zhang]

Signed-off-by: Elaine Zhang 
---
 drivers/clk/rockchip/clk-rv1108.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rv1108.c 
b/drivers/clk/rockchip/clk-rv1108.c
index d1065dd9f442..0e441ec21e90 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -763,6 +763,8 @@ enum rv1108_plls {
GATE(SCLK_MACPHY_RX, "sclk_macphy_rx", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 8, GFLAGS),
GATE(SCLK_MAC_REF, "sclk_mac_ref", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 6, GFLAGS),
GATE(SCLK_MAC_REFOUT, "sclk_mac_refout", "sclk_macphy", 0, 
RV1108_CLKGATE_CON(4), 7, GFLAGS),
+   GATE(ACLK_GMAC, "aclk_gmac", "aclk_periph", 0, RV1108_CLKGATE_CON(15), 
4, GFLAGS),
+   GATE(PCLK_GMAC, "pclk_gmac", "pclk_periph", 0, RV1108_CLKGATE_CON(15), 
5, GFLAGS),
 
MMC(SCLK_SDMMC_DRV,"sdmmc_drv","sclk_sdmmc", RV1108_SDMMC_CON0, 
1),
MMC(SCLK_SDMMC_SAMPLE, "sdmmc_sample", "sclk_sdmmc", RV1108_SDMMC_CON1, 
1),
-- 
1.9.1

Re: [PATCH 3.16 032/134] MIPS: Loongson-3: Select MIPS_L1_CACHE_SHIFT_6

[Huacai Chen]

3.16 doesn't need this, because 3.16 doesn't support Loongson-3 R2/R3.

Huacai

On Fri, Aug 18, 2017 at 9:13 PM, Ben Hutchings  wrote:
> 3.16.47-rc1 review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Huacai Chen 
>
> commit 17c99d9421695a0e0de18bf1e7091d859e20ec1d upstream.
>
> Some newer Loongson-3 have 64 bytes cache lines, so select
> MIPS_L1_CACHE_SHIFT_6.
>
> Signed-off-by: Huacai Chen 
> Cc: John Crispin 
> Cc: Steven J . Hill 
> Cc: Fuxin Zhang 
> Cc: Zhangjin Wu 
> Cc: linux-m...@linux-mips.org
> Patchwork: https://patchwork.linux-mips.org/patch/15755/
> Signed-off-by: Ralf Baechle 
> [bwh: Backported to 3.16: adjust context]
> Signed-off-by: Ben Hutchings 
> ---
>  arch/mips/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -1193,6 +1193,7 @@ config CPU_LOONGSON3
> select CPU_SUPPORTS_HUGEPAGES
> select WEAK_ORDERING
> select WEAK_REORDERING_BEYOND_LLSC
> +   select MIPS_L1_CACHE_SHIFT_6
> help
> The Loongson 3 processor implements the MIPS64R2 instruction
> set with many extensions.
>
>

Re: [PATCH 3.16 032/134] MIPS: Loongson-3: Select MIPS_L1_CACHE_SHIFT_6

[Huacai Chen]

3.16 doesn't need this, because 3.16 doesn't support Loongson-3 R2/R3.

Huacai

On Fri, Aug 18, 2017 at 9:13 PM, Ben Hutchings  wrote:
> 3.16.47-rc1 review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Huacai Chen 
>
> commit 17c99d9421695a0e0de18bf1e7091d859e20ec1d upstream.
>
> Some newer Loongson-3 have 64 bytes cache lines, so select
> MIPS_L1_CACHE_SHIFT_6.
>
> Signed-off-by: Huacai Chen 
> Cc: John Crispin 
> Cc: Steven J . Hill 
> Cc: Fuxin Zhang 
> Cc: Zhangjin Wu 
> Cc: linux-m...@linux-mips.org
> Patchwork: https://patchwork.linux-mips.org/patch/15755/
> Signed-off-by: Ralf Baechle 
> [bwh: Backported to 3.16: adjust context]
> Signed-off-by: Ben Hutchings 
> ---
>  arch/mips/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -1193,6 +1193,7 @@ config CPU_LOONGSON3
> select CPU_SUPPORTS_HUGEPAGES
> select WEAK_ORDERING
> select WEAK_REORDERING_BEYOND_LLSC
> +   select MIPS_L1_CACHE_SHIFT_6
> help
> The Loongson 3 processor implements the MIPS64R2 instruction
> set with many extensions.
>
>

Re: [PATCH v3 1/3] dt-bindings: Document the hi3660 thermal sensor bindings

[Wangtao (Kevin, Kirin)]

在 2017/8/17 23:10, Rob Herring 写道:

On Thu, Aug 10, 2017 at 04:32:13PM +0800, Tao Wang wrote:

From: Tao Wang 

This adds documentation of device tree bindings for the
thermal sensor controller of hi3660 SoC.

Signed-off-by: Tao Wang 
---
  .../devicetree/bindings/thermal/hisi-tsensor.txt   | 23 ++
  1 file changed, 23 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/thermal/hisi-tsensor.txt

diff --git a/Documentation/devicetree/bindings/thermal/hisi-tsensor.txt 
b/Documentation/devicetree/bindings/thermal/hisi-tsensor.txt
new file mode 100644
index 000..2ab0eb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/hisi-tsensor.txt
@@ -0,0 +1,23 @@
+* Temperature Sensor on hisilicon SoC
+
+** Required properties :
+
+- compatible: "hisilicon,thermal-tsensor".


Needs an SoC specific compatible.

OK



+- reg: physical base address of thermal sensor and length of memory mapped
+  region.
+- offset: reg offset of each sensor.


Should be implied by the compatible.

Do you mean that the reg offset should not in dts?



+- coefficients:An array of integers (one signed cell) containing
+   coefficients to turn adc value to temperture.


Needs a vendor prefix.

OK



+- hisi,adc-range: adc value range, minimum value is followed by maximum value.
+- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
+
+Example :
+
+tsensor: tsensor@FFF3000 {
+   compatible = "hisilicon,tsensor";
+   reg = <0x0 0xfff3 0x0 0x1000>;
+   offset = <0x1c 0x5c 0x9c>;
+   coefficients = <165000 (-4)>;
+   hisi,adc-range = <0x74 0x39A>;
+   #thermal-sensor-cells = <1>;
+};
--
2.8.1

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


.

Re: [PATCH v3 1/3] dt-bindings: Document the hi3660 thermal sensor bindings

[Wangtao (Kevin, Kirin)]

在 2017/8/17 23:10, Rob Herring 写道:

On Thu, Aug 10, 2017 at 04:32:13PM +0800, Tao Wang wrote:

From: Tao Wang 

This adds documentation of device tree bindings for the
thermal sensor controller of hi3660 SoC.

Signed-off-by: Tao Wang 
---
  .../devicetree/bindings/thermal/hisi-tsensor.txt   | 23 ++
  1 file changed, 23 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/thermal/hisi-tsensor.txt

diff --git a/Documentation/devicetree/bindings/thermal/hisi-tsensor.txt 
b/Documentation/devicetree/bindings/thermal/hisi-tsensor.txt
new file mode 100644
index 000..2ab0eb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/hisi-tsensor.txt
@@ -0,0 +1,23 @@
+* Temperature Sensor on hisilicon SoC
+
+** Required properties :
+
+- compatible: "hisilicon,thermal-tsensor".


Needs an SoC specific compatible.

OK



+- reg: physical base address of thermal sensor and length of memory mapped
+  region.
+- offset: reg offset of each sensor.


Should be implied by the compatible.

Do you mean that the reg offset should not in dts?



+- coefficients:An array of integers (one signed cell) containing
+   coefficients to turn adc value to temperture.


Needs a vendor prefix.

OK



+- hisi,adc-range: adc value range, minimum value is followed by maximum value.
+- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
+
+Example :
+
+tsensor: tsensor@FFF3000 {
+   compatible = "hisilicon,tsensor";
+   reg = <0x0 0xfff3 0x0 0x1000>;
+   offset = <0x1c 0x5c 0x9c>;
+   coefficients = <165000 (-4)>;
+   hisi,adc-range = <0x74 0x39A>;
+   #thermal-sensor-cells = <1>;
+};
--
2.8.1

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


.

Re: [PATCH 0/3] Ceph: Adjustments for some function implementations

[Yan, Zheng]

> On 21 Aug 2017, at 02:37, SF Markus Elfring  
> wrote:
> 
> From: Markus Elfring 
> Date: Sun, 20 Aug 2017 20:32:10 +0200
> 
> Three update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (3):
>  Delete an error message for a failed memory allocation in 
> __get_or_create_frag()
>  Delete an unnecessary return statement in update_dentry_lease()
>  Adjust 36 checks for null pointers
> 
> fs/ceph/addr.c   |  2 +-
> fs/ceph/cache.c  |  2 +-
> fs/ceph/caps.c   |  4 ++--
> fs/ceph/debugfs.c|  2 +-
> fs/ceph/file.c   |  2 +-
> fs/ceph/inode.c  | 14 +-
> fs/ceph/mds_client.c | 22 +++---
> fs/ceph/mdsmap.c |  6 +++---
> fs/ceph/super.c  | 18 +-
> fs/ceph/xattr.c  |  8 
> 10 files changed, 38 insertions(+), 42 deletions(-)
> 
> — 

Whole series applied, thanks

Yan, Zheng

> 2.14.0
> 

Re: [PATCH 0/3] Ceph: Adjustments for some function implementations

[Yan, Zheng]

> On 21 Aug 2017, at 02:37, SF Markus Elfring  
> wrote:
> 
> From: Markus Elfring 
> Date: Sun, 20 Aug 2017 20:32:10 +0200
> 
> Three update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (3):
>  Delete an error message for a failed memory allocation in 
> __get_or_create_frag()
>  Delete an unnecessary return statement in update_dentry_lease()
>  Adjust 36 checks for null pointers
> 
> fs/ceph/addr.c   |  2 +-
> fs/ceph/cache.c  |  2 +-
> fs/ceph/caps.c   |  4 ++--
> fs/ceph/debugfs.c|  2 +-
> fs/ceph/file.c   |  2 +-
> fs/ceph/inode.c  | 14 +-
> fs/ceph/mds_client.c | 22 +++---
> fs/ceph/mdsmap.c |  6 +++---
> fs/ceph/super.c  | 18 +-
> fs/ceph/xattr.c  |  8 
> 10 files changed, 38 insertions(+), 42 deletions(-)
> 
> — 

Whole series applied, thanks

Yan, Zheng

> 2.14.0
> 

Re: + kbuild-disable-wformat-truncation-warnings-by-default.patch added to -mm tree

[Masahiro Yamada]

Hi Arnd,

2017-08-21 4:51 GMT+09:00 Arnd Bergmann :
> On Sun, Aug 20, 2017 at 3:19 PM, Masahiro Yamada
>  wrote:
>> 2017-07-20 16:24 GMT+09:00 Arnd Bergmann :
>>> - enable all three warnings with "make W=1" in 4.13, but leave them
>>>   disabled by default.
>>> - backport Linus' patch, plus the follow-up for W=1 to stable kernels,
>>>   to allow stable kernels to build cleanly
>>> - backport the patches that address any other gcc-7 warnings, as
>>>   well as those that are not obvious false-positives to stable kernels
>>> - In 4.14+, use my version above and address all int-in-bool-context
>>>   and format-overflow warnings, but only use -Wformat-truncation
>>>   with make W=1.
>>>
>>
>> Talking about 4.14+, shall we move -Wformat-truncation
>> from the top Makefile (always disable) to
>> Makefile.extrawarn (enable with W=1) ?
>
> I dropped the ball on this one, sorry. I think we should do this for
> all three warnings (format-overflow, format-truncation and
> int-in-bool-context) for the time being.
>
> In case of format-truncation, there are countless warnings,
> most of them false-postives, so we simply can't enable them
> by default.
>
> For -Wformat-overflow, there is one patch that I need to
> rewrite, all my other patches are pending for 4.14, see
> https://patchwork.kernel.org/patch/9840801/ for the missing
> one. This should be trivial to fix. However, enabling
> CONFIG_UBSAN_SANITIZE_ALL results in seven additional
> false positives. I created an patch for this in
> https://pastebin.com/CD7nhRNp but can't submit that as it's
> obviously bogus. I reported the gcc bug as
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81592
>
> What we could do there is to disable the warning if
> CONFIG_UBSAN_SANITIZE_ALL is turned on (like
> we do for -Wmaybe-uninitialized in
> CONFIG_UBSAN_SANITIZE_ALL) but leave it on otherwise.
>
> I submitted patches for all -Wint-in-bool-context in arm/arm64/x86
> randconfig builds, but there are still six known warnings for which
> my patches did not get queued for 4.14.
> I have to revisit those all to decide whether we can find an
> acceptable workaround in the kernel and enable the warning again
> by default, or leave it in W=1 until gcc improves enough.
>

I was just wondering how to handle your original patch.
I do not mean to press you.
We can take our time to make the right decision.  Thanks!



-- 
Best Regards
Masahiro Yamada

Re: + kbuild-disable-wformat-truncation-warnings-by-default.patch added to -mm tree

[Masahiro Yamada]

Hi Arnd,

2017-08-21 4:51 GMT+09:00 Arnd Bergmann :
> On Sun, Aug 20, 2017 at 3:19 PM, Masahiro Yamada
>  wrote:
>> 2017-07-20 16:24 GMT+09:00 Arnd Bergmann :
>>> - enable all three warnings with "make W=1" in 4.13, but leave them
>>>   disabled by default.
>>> - backport Linus' patch, plus the follow-up for W=1 to stable kernels,
>>>   to allow stable kernels to build cleanly
>>> - backport the patches that address any other gcc-7 warnings, as
>>>   well as those that are not obvious false-positives to stable kernels
>>> - In 4.14+, use my version above and address all int-in-bool-context
>>>   and format-overflow warnings, but only use -Wformat-truncation
>>>   with make W=1.
>>>
>>
>> Talking about 4.14+, shall we move -Wformat-truncation
>> from the top Makefile (always disable) to
>> Makefile.extrawarn (enable with W=1) ?
>
> I dropped the ball on this one, sorry. I think we should do this for
> all three warnings (format-overflow, format-truncation and
> int-in-bool-context) for the time being.
>
> In case of format-truncation, there are countless warnings,
> most of them false-postives, so we simply can't enable them
> by default.
>
> For -Wformat-overflow, there is one patch that I need to
> rewrite, all my other patches are pending for 4.14, see
> https://patchwork.kernel.org/patch/9840801/ for the missing
> one. This should be trivial to fix. However, enabling
> CONFIG_UBSAN_SANITIZE_ALL results in seven additional
> false positives. I created an patch for this in
> https://pastebin.com/CD7nhRNp but can't submit that as it's
> obviously bogus. I reported the gcc bug as
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81592
>
> What we could do there is to disable the warning if
> CONFIG_UBSAN_SANITIZE_ALL is turned on (like
> we do for -Wmaybe-uninitialized in
> CONFIG_UBSAN_SANITIZE_ALL) but leave it on otherwise.
>
> I submitted patches for all -Wint-in-bool-context in arm/arm64/x86
> randconfig builds, but there are still six known warnings for which
> my patches did not get queued for 4.14.
> I have to revisit those all to decide whether we can find an
> acceptable workaround in the kernel and enable the warning again
> by default, or leave it in W=1 until gcc improves enough.
>

I was just wondering how to handle your original patch.
I do not mean to press you.
We can take our time to make the right decision.  Thanks!



-- 
Best Regards
Masahiro Yamada

[PATCH v9 RESEND 2/9] mfd: rk808: add rk805 regs addr and ID

[Heiko Stuebner]

From: Elaine Zhang 

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 include/linux/mfd/rk808.h | 120 ++
 1 file changed, 120 insertions(+)

diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
index 54feb140c210..d3156594674c 100644
--- a/include/linux/mfd/rk808.h
+++ b/include/linux/mfd/rk808.h
@@ -206,6 +206,97 @@ enum rk818_reg {
 #define RK818_USB_ILMIN_2000MA 0x7
 #define RK818_USB_CHG_SD_VSEL_MASK 0x70
 
+/* RK805 */
+enum rk805_reg {
+   RK805_ID_DCDC1,
+   RK805_ID_DCDC2,
+   RK805_ID_DCDC3,
+   RK805_ID_DCDC4,
+   RK805_ID_LDO1,
+   RK805_ID_LDO2,
+   RK805_ID_LDO3,
+};
+
+/* CONFIG REGISTER */
+#define RK805_VB_MON_REG   0x21
+#define RK805_THERMAL_REG  0x22
+
+/* POWER CHANNELS ENABLE REGISTER */
+#define RK805_DCDC_EN_REG  0x23
+#define RK805_SLP_DCDC_EN_REG  0x25
+#define RK805_SLP_LDO_EN_REG   0x26
+#define RK805_LDO_EN_REG   0x27
+
+/* BUCK AND LDO CONFIG REGISTER */
+#define RK805_BUCK_LDO_SLP_LP_EN_REG   0x2A
+#define RK805_BUCK1_CONFIG_REG 0x2E
+#define RK805_BUCK1_ON_VSEL_REG0x2F
+#define RK805_BUCK1_SLP_VSEL_REG   0x30
+#define RK805_BUCK2_CONFIG_REG 0x32
+#define RK805_BUCK2_ON_VSEL_REG0x33
+#define RK805_BUCK2_SLP_VSEL_REG   0x34
+#define RK805_BUCK3_CONFIG_REG 0x36
+#define RK805_BUCK4_CONFIG_REG 0x37
+#define RK805_BUCK4_ON_VSEL_REG0x38
+#define RK805_BUCK4_SLP_VSEL_REG   0x39
+#define RK805_LDO1_ON_VSEL_REG 0x3B
+#define RK805_LDO1_SLP_VSEL_REG0x3C
+#define RK805_LDO2_ON_VSEL_REG 0x3D
+#define RK805_LDO2_SLP_VSEL_REG0x3E
+#define RK805_LDO3_ON_VSEL_REG 0x3F
+#define RK805_LDO3_SLP_VSEL_REG0x40
+
+/* INTERRUPT REGISTER */
+#define RK805_PWRON_LP_INT_TIME_REG0x47
+#define RK805_PWRON_DB_REG 0x48
+#define RK805_DEV_CTRL_REG 0x4B
+#define RK805_INT_STS_REG  0x4C
+#define RK805_INT_STS_MSK_REG  0x4D
+#define RK805_GPIO_IO_POL_REG  0x50
+#define RK805_OUT_REG  0x52
+#define RK805_ON_SOURCE_REG0xAE
+#define RK805_OFF_SOURCE_REG   0xAF
+
+#define RK805_NUM_REGULATORS   7
+
+#define RK805_PWRON_FALL_RISE_INT_EN   0x0
+#define RK805_PWRON_FALL_RISE_INT_MSK  0x81
+
+/* RK805 IRQ Definitions */
+#define RK805_IRQ_PWRON_RISE   0
+#define RK805_IRQ_VB_LOW   1
+#define RK805_IRQ_PWRON2
+#define RK805_IRQ_PWRON_LP 3
+#define RK805_IRQ_HOTDIE   4
+#define RK805_IRQ_RTC_ALARM5
+#define RK805_IRQ_RTC_PERIOD   6
+#define RK805_IRQ_PWRON_FALL   7
+
+#define RK805_IRQ_PWRON_RISE_MSK   BIT(0)
+#define RK805_IRQ_VB_LOW_MSK   BIT(1)
+#define RK805_IRQ_PWRON_MSKBIT(2)
+#define RK805_IRQ_PWRON_LP_MSK BIT(3)
+#define RK805_IRQ_HOTDIE_MSK   BIT(4)
+#define RK805_IRQ_RTC_ALARM_MSKBIT(5)
+#define RK805_IRQ_RTC_PERIOD_MSK   BIT(6)
+#define RK805_IRQ_PWRON_FALL_MSK   BIT(7)
+
+#define RK805_PWR_RISE_INT_STATUS  BIT(0)
+#define RK805_VB_LOW_INT_STATUSBIT(1)
+#define RK805_PWRON_INT_STATUS BIT(2)
+#define RK805_PWRON_LP_INT_STATUS  BIT(3)
+#define RK805_HOTDIE_INT_STATUSBIT(4)
+#define RK805_ALARM_INT_STATUS BIT(5)
+#define RK805_PERIOD_INT_STATUSBIT(6)
+#define RK805_PWR_FALL_INT_STATUS  BIT(7)
+
+#define RK805_BUCK1_2_ILMAX_MASK   (3 << 6)
+#define RK805_BUCK3_4_ILMAX_MASK(3 << 3)
+#define RK805_RTC_PERIOD_INT_MASK  (1 << 6)
+#define RK805_RTC_ALARM_INT_MASK   (1 << 5)
+#define RK805_INT_ALARM_EN (1 << 3)
+#define RK805_INT_TIMER_EN (1 << 2)
+
 /* RK808 IRQ Definitions */
 #define RK808_IRQ_VOUT_LO  0
 #define RK808_IRQ_VB_LO1
@@ -298,7 +389,14 @@ enum rk818_reg {
 #define VOUT_LO_INTBIT(0)
 #define CLK32KOUT2_EN  BIT(0)
 
+#define TEMP115C   0x0c
+#define TEMP_HOTDIE_MSK0x0c
+#define SLP_SD_MSK (0x3 << 2)
+#define SHUTDOWN_FUN   (0x2 << 2)
+#define SLEEP_FUN  (0x1 << 2)
 #define RK8XX_ID_MSK   0xfff0
+#define FPWM_MODE  BIT(7)
+
 enum {
BUCK_ILMIN_50MA,
BUCK_ILMIN_100MA,
@@ -322,6 +420,28 @@ enum {
 };
 
 enum {
+   RK805_BUCK1_2_ILMAX_2500MA,
+   RK805_BUCK1_2_ILMAX_3000MA,
+   RK805_BUCK1_2_ILMAX_3500MA,
+   RK805_BUCK1_2_ILMAX_4000MA,
+};
+
+enum {
+   RK805_BUCK3_ILMAX_1500MA,
+   RK805_BUCK3_ILMAX_2000MA,
+   

[PATCH v9 RESEND 2/9] mfd: rk808: add rk805 regs addr and ID

[Heiko Stuebner]

From: Elaine Zhang 

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 include/linux/mfd/rk808.h | 120 ++
 1 file changed, 120 insertions(+)

diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
index 54feb140c210..d3156594674c 100644
--- a/include/linux/mfd/rk808.h
+++ b/include/linux/mfd/rk808.h
@@ -206,6 +206,97 @@ enum rk818_reg {
 #define RK818_USB_ILMIN_2000MA 0x7
 #define RK818_USB_CHG_SD_VSEL_MASK 0x70
 
+/* RK805 */
+enum rk805_reg {
+   RK805_ID_DCDC1,
+   RK805_ID_DCDC2,
+   RK805_ID_DCDC3,
+   RK805_ID_DCDC4,
+   RK805_ID_LDO1,
+   RK805_ID_LDO2,
+   RK805_ID_LDO3,
+};
+
+/* CONFIG REGISTER */
+#define RK805_VB_MON_REG   0x21
+#define RK805_THERMAL_REG  0x22
+
+/* POWER CHANNELS ENABLE REGISTER */
+#define RK805_DCDC_EN_REG  0x23
+#define RK805_SLP_DCDC_EN_REG  0x25
+#define RK805_SLP_LDO_EN_REG   0x26
+#define RK805_LDO_EN_REG   0x27
+
+/* BUCK AND LDO CONFIG REGISTER */
+#define RK805_BUCK_LDO_SLP_LP_EN_REG   0x2A
+#define RK805_BUCK1_CONFIG_REG 0x2E
+#define RK805_BUCK1_ON_VSEL_REG0x2F
+#define RK805_BUCK1_SLP_VSEL_REG   0x30
+#define RK805_BUCK2_CONFIG_REG 0x32
+#define RK805_BUCK2_ON_VSEL_REG0x33
+#define RK805_BUCK2_SLP_VSEL_REG   0x34
+#define RK805_BUCK3_CONFIG_REG 0x36
+#define RK805_BUCK4_CONFIG_REG 0x37
+#define RK805_BUCK4_ON_VSEL_REG0x38
+#define RK805_BUCK4_SLP_VSEL_REG   0x39
+#define RK805_LDO1_ON_VSEL_REG 0x3B
+#define RK805_LDO1_SLP_VSEL_REG0x3C
+#define RK805_LDO2_ON_VSEL_REG 0x3D
+#define RK805_LDO2_SLP_VSEL_REG0x3E
+#define RK805_LDO3_ON_VSEL_REG 0x3F
+#define RK805_LDO3_SLP_VSEL_REG0x40
+
+/* INTERRUPT REGISTER */
+#define RK805_PWRON_LP_INT_TIME_REG0x47
+#define RK805_PWRON_DB_REG 0x48
+#define RK805_DEV_CTRL_REG 0x4B
+#define RK805_INT_STS_REG  0x4C
+#define RK805_INT_STS_MSK_REG  0x4D
+#define RK805_GPIO_IO_POL_REG  0x50
+#define RK805_OUT_REG  0x52
+#define RK805_ON_SOURCE_REG0xAE
+#define RK805_OFF_SOURCE_REG   0xAF
+
+#define RK805_NUM_REGULATORS   7
+
+#define RK805_PWRON_FALL_RISE_INT_EN   0x0
+#define RK805_PWRON_FALL_RISE_INT_MSK  0x81
+
+/* RK805 IRQ Definitions */
+#define RK805_IRQ_PWRON_RISE   0
+#define RK805_IRQ_VB_LOW   1
+#define RK805_IRQ_PWRON2
+#define RK805_IRQ_PWRON_LP 3
+#define RK805_IRQ_HOTDIE   4
+#define RK805_IRQ_RTC_ALARM5
+#define RK805_IRQ_RTC_PERIOD   6
+#define RK805_IRQ_PWRON_FALL   7
+
+#define RK805_IRQ_PWRON_RISE_MSK   BIT(0)
+#define RK805_IRQ_VB_LOW_MSK   BIT(1)
+#define RK805_IRQ_PWRON_MSKBIT(2)
+#define RK805_IRQ_PWRON_LP_MSK BIT(3)
+#define RK805_IRQ_HOTDIE_MSK   BIT(4)
+#define RK805_IRQ_RTC_ALARM_MSKBIT(5)
+#define RK805_IRQ_RTC_PERIOD_MSK   BIT(6)
+#define RK805_IRQ_PWRON_FALL_MSK   BIT(7)
+
+#define RK805_PWR_RISE_INT_STATUS  BIT(0)
+#define RK805_VB_LOW_INT_STATUSBIT(1)
+#define RK805_PWRON_INT_STATUS BIT(2)
+#define RK805_PWRON_LP_INT_STATUS  BIT(3)
+#define RK805_HOTDIE_INT_STATUSBIT(4)
+#define RK805_ALARM_INT_STATUS BIT(5)
+#define RK805_PERIOD_INT_STATUSBIT(6)
+#define RK805_PWR_FALL_INT_STATUS  BIT(7)
+
+#define RK805_BUCK1_2_ILMAX_MASK   (3 << 6)
+#define RK805_BUCK3_4_ILMAX_MASK(3 << 3)
+#define RK805_RTC_PERIOD_INT_MASK  (1 << 6)
+#define RK805_RTC_ALARM_INT_MASK   (1 << 5)
+#define RK805_INT_ALARM_EN (1 << 3)
+#define RK805_INT_TIMER_EN (1 << 2)
+
 /* RK808 IRQ Definitions */
 #define RK808_IRQ_VOUT_LO  0
 #define RK808_IRQ_VB_LO1
@@ -298,7 +389,14 @@ enum rk818_reg {
 #define VOUT_LO_INTBIT(0)
 #define CLK32KOUT2_EN  BIT(0)
 
+#define TEMP115C   0x0c
+#define TEMP_HOTDIE_MSK0x0c
+#define SLP_SD_MSK (0x3 << 2)
+#define SHUTDOWN_FUN   (0x2 << 2)
+#define SLEEP_FUN  (0x1 << 2)
 #define RK8XX_ID_MSK   0xfff0
+#define FPWM_MODE  BIT(7)
+
 enum {
BUCK_ILMIN_50MA,
BUCK_ILMIN_100MA,
@@ -322,6 +420,28 @@ enum {
 };
 
 enum {
+   RK805_BUCK1_2_ILMAX_2500MA,
+   RK805_BUCK1_2_ILMAX_3000MA,
+   RK805_BUCK1_2_ILMAX_3500MA,
+   RK805_BUCK1_2_ILMAX_4000MA,
+};
+
+enum {
+   RK805_BUCK3_ILMAX_1500MA,
+   RK805_BUCK3_ILMAX_2000MA,
+   RK805_BUCK3_ILMAX_2500MA,
+   RK805_BUCK3_ILMAX_3000MA,
+};
+
+enum {
+   RK805_BUCK4_ILMAX_2000MA,
+   

[PATCH v9 RESEND 5/9] mfd: rk808: Add RK805 support

[Heiko Stuebner]

From: Elaine Zhang 

The RK805 chip is a Power Management IC (PMIC) for multimedia and handheld
devices. It contains the following components:

- Regulators
- RTC
- Clocking

Both RK808 and RK805 chips are using a similar register map,
so we can reuse the RTC and Clocking functionality.

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 drivers/mfd/Kconfig |   4 +-
 drivers/mfd/rk808.c | 108 
 2 files changed, 110 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c601ee1945c6..f247de83fa6c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -965,13 +965,13 @@ config MFD_RC5T583
  different functionality of the device.
 
 config MFD_RK808
-   tristate "Rockchip RK808/RK818 Power Management Chip"
+   tristate "Rockchip RK805/RK808/RK818 Power Management Chip"
depends on I2C && OF
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
help
- If you say yes here you get support for the RK808 and RK818
+ If you say yes here you get support for the RK805, RK808 and RK818
  Power Management chips.
  This driver provides common support for accessing the device
  through I2C interface. The device supports multiple sub-devices
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 8e60ebaeaadb..18329c8b4fe7 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -70,6 +70,14 @@ static const struct regmap_config rk818_regmap_config = {
.volatile_reg = rk808_is_volatile_reg,
 };
 
+static const struct regmap_config rk805_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = RK805_OFF_SOURCE_REG,
+   .cache_type = REGCACHE_RBTREE,
+   .volatile_reg = rk808_is_volatile_reg,
+};
+
 static const struct regmap_config rk808_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -86,6 +94,16 @@ static struct resource rtc_resources[] = {
}
 };
 
+static const struct mfd_cell rk805s[] = {
+   { .name = "rk808-clkout", },
+   { .name = "rk808-regulator", },
+   {
+   .name = "rk808-rtc",
+   .num_resources = ARRAY_SIZE(rtc_resources),
+   .resources = _resources[0],
+   },
+};
+
 static const struct mfd_cell rk808s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
@@ -106,6 +124,20 @@ static const struct mfd_cell rk818s[] = {
},
 };
 
+static const struct rk808_reg_data rk805_pre_init_reg[] = {
+   {RK805_BUCK1_CONFIG_REG, RK805_BUCK1_2_ILMAX_MASK,
+RK805_BUCK1_2_ILMAX_4000MA},
+   {RK805_BUCK2_CONFIG_REG, RK805_BUCK1_2_ILMAX_MASK,
+RK805_BUCK1_2_ILMAX_4000MA},
+   {RK805_BUCK3_CONFIG_REG, RK805_BUCK3_4_ILMAX_MASK,
+RK805_BUCK3_ILMAX_3000MA},
+   {RK805_BUCK4_CONFIG_REG, RK805_BUCK3_4_ILMAX_MASK,
+RK805_BUCK4_ILMAX_3500MA},
+   {RK805_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_400MA},
+   {RK805_GPIO_IO_POL_REG, SLP_SD_MSK, SLEEP_FUN},
+   {RK805_THERMAL_REG, TEMP_HOTDIE_MSK, TEMP115C},
+};
+
 static const struct rk808_reg_data rk808_pre_init_reg[] = {
{ RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_150MA },
{ RK808_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_200MA },
@@ -135,6 +167,41 @@ static const struct rk808_reg_data rk818_pre_init_reg[] = {
VB_LO_SEL_3500MV },
 };
 
+static const struct regmap_irq rk805_irqs[] = {
+   [RK805_IRQ_PWRON_RISE] = {
+   .mask = RK805_IRQ_PWRON_RISE_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_VB_LOW] = {
+   .mask = RK805_IRQ_VB_LOW_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_PWRON] = {
+   .mask = RK805_IRQ_PWRON_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_PWRON_LP] = {
+   .mask = RK805_IRQ_PWRON_LP_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_HOTDIE] = {
+   .mask = RK805_IRQ_HOTDIE_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_RTC_ALARM] = {
+   .mask = RK805_IRQ_RTC_ALARM_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_RTC_PERIOD] = {
+   .mask = RK805_IRQ_RTC_PERIOD_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_PWRON_FALL] = {
+   .mask = RK805_IRQ_PWRON_FALL_MSK,
+   .reg_offset = 0,
+   },
+};
+
 static const struct regmap_irq rk808_irqs[] = {
/* INT_STS */
[RK808_IRQ_VOUT_LO] = {
@@ -247,6 +314,17 @@ static 

[PATCH v9 RESEND 5/9] mfd: rk808: Add RK805 support

[Heiko Stuebner]

From: Elaine Zhang 

The RK805 chip is a Power Management IC (PMIC) for multimedia and handheld
devices. It contains the following components:

- Regulators
- RTC
- Clocking

Both RK808 and RK805 chips are using a similar register map,
so we can reuse the RTC and Clocking functionality.

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 drivers/mfd/Kconfig |   4 +-
 drivers/mfd/rk808.c | 108 
 2 files changed, 110 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c601ee1945c6..f247de83fa6c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -965,13 +965,13 @@ config MFD_RC5T583
  different functionality of the device.
 
 config MFD_RK808
-   tristate "Rockchip RK808/RK818 Power Management Chip"
+   tristate "Rockchip RK805/RK808/RK818 Power Management Chip"
depends on I2C && OF
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
help
- If you say yes here you get support for the RK808 and RK818
+ If you say yes here you get support for the RK805, RK808 and RK818
  Power Management chips.
  This driver provides common support for accessing the device
  through I2C interface. The device supports multiple sub-devices
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 8e60ebaeaadb..18329c8b4fe7 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -70,6 +70,14 @@ static const struct regmap_config rk818_regmap_config = {
.volatile_reg = rk808_is_volatile_reg,
 };
 
+static const struct regmap_config rk805_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = RK805_OFF_SOURCE_REG,
+   .cache_type = REGCACHE_RBTREE,
+   .volatile_reg = rk808_is_volatile_reg,
+};
+
 static const struct regmap_config rk808_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -86,6 +94,16 @@ static struct resource rtc_resources[] = {
}
 };
 
+static const struct mfd_cell rk805s[] = {
+   { .name = "rk808-clkout", },
+   { .name = "rk808-regulator", },
+   {
+   .name = "rk808-rtc",
+   .num_resources = ARRAY_SIZE(rtc_resources),
+   .resources = _resources[0],
+   },
+};
+
 static const struct mfd_cell rk808s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
@@ -106,6 +124,20 @@ static const struct mfd_cell rk818s[] = {
},
 };
 
+static const struct rk808_reg_data rk805_pre_init_reg[] = {
+   {RK805_BUCK1_CONFIG_REG, RK805_BUCK1_2_ILMAX_MASK,
+RK805_BUCK1_2_ILMAX_4000MA},
+   {RK805_BUCK2_CONFIG_REG, RK805_BUCK1_2_ILMAX_MASK,
+RK805_BUCK1_2_ILMAX_4000MA},
+   {RK805_BUCK3_CONFIG_REG, RK805_BUCK3_4_ILMAX_MASK,
+RK805_BUCK3_ILMAX_3000MA},
+   {RK805_BUCK4_CONFIG_REG, RK805_BUCK3_4_ILMAX_MASK,
+RK805_BUCK4_ILMAX_3500MA},
+   {RK805_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_400MA},
+   {RK805_GPIO_IO_POL_REG, SLP_SD_MSK, SLEEP_FUN},
+   {RK805_THERMAL_REG, TEMP_HOTDIE_MSK, TEMP115C},
+};
+
 static const struct rk808_reg_data rk808_pre_init_reg[] = {
{ RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_150MA },
{ RK808_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_200MA },
@@ -135,6 +167,41 @@ static const struct rk808_reg_data rk818_pre_init_reg[] = {
VB_LO_SEL_3500MV },
 };
 
+static const struct regmap_irq rk805_irqs[] = {
+   [RK805_IRQ_PWRON_RISE] = {
+   .mask = RK805_IRQ_PWRON_RISE_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_VB_LOW] = {
+   .mask = RK805_IRQ_VB_LOW_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_PWRON] = {
+   .mask = RK805_IRQ_PWRON_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_PWRON_LP] = {
+   .mask = RK805_IRQ_PWRON_LP_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_HOTDIE] = {
+   .mask = RK805_IRQ_HOTDIE_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_RTC_ALARM] = {
+   .mask = RK805_IRQ_RTC_ALARM_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_RTC_PERIOD] = {
+   .mask = RK805_IRQ_RTC_PERIOD_MSK,
+   .reg_offset = 0,
+   },
+   [RK805_IRQ_PWRON_FALL] = {
+   .mask = RK805_IRQ_PWRON_FALL_MSK,
+   .reg_offset = 0,
+   },
+};
+
 static const struct regmap_irq rk808_irqs[] = {
/* INT_STS */
[RK808_IRQ_VOUT_LO] = {
@@ -247,6 +314,17 @@ static const struct regmap_irq rk818_irqs[] = {
},
 };
 
+static struct regmap_irq_chip rk805_irq_chip = {
+ 

[PATCH v9 RESEND 4/9] mfd: dt-bindings: Add RK805 device tree bindings document

[Heiko Stuebner]

From: Elaine Zhang 

Add device tree bindings documentation for Rockchip's RK805 PMIC.

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-by: Rob Herring 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 Documentation/devicetree/bindings/mfd/rk808.txt | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt 
b/Documentation/devicetree/bindings/mfd/rk808.txt
index 9636ae8d8d41..91b65227afeb 100644
--- a/Documentation/devicetree/bindings/mfd/rk808.txt
+++ b/Documentation/devicetree/bindings/mfd/rk808.txt
@@ -1,11 +1,14 @@
 RK8XX Power Management Integrated Circuit
 
 The rk8xx family current members:
+rk805
 rk808
 rk818
 
 Required properties:
-- compatible: "rockchip,rk808", "rockchip,rk818"
+- compatible: "rockchip,rk805"
+- compatible: "rockchip,rk808"
+- compatible: "rockchip,rk818"
 - reg: I2C slave address
 - interrupt-parent: The parent interrupt controller.
 - interrupts: the interrupt outputs of the controller.
@@ -18,6 +21,14 @@ Optional properties:
 - rockchip,system-power-controller: Telling whether or not this pmic is 
controlling
   the system power.
 
+Optional RK805 properties:
+- vcc1-supply:  The input supply for DCDC_REG1
+- vcc2-supply:  The input supply for DCDC_REG2
+- vcc3-supply:  The input supply for DCDC_REG3
+- vcc4-supply:  The input supply for DCDC_REG4
+- vcc5-supply:  The input supply for LDO_REG1 and LDO_REG2
+- vcc6-supply:  The input supply for LDO_REG3
+
 Optional RK808 properties:
 - vcc1-supply:  The input supply for DCDC_REG1
 - vcc2-supply:  The input supply for DCDC_REG2
@@ -56,6 +67,15 @@ by a child node of the 'regulators' node.
/* standard regulator bindings here */
};
 
+Following regulators of the RK805 PMIC regulators are supported. Note that
+the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO
+number as described in RK805 datasheet.
+
+   - DCDC_REGn
+   - valid values for n are 1 to 4.
+   - LDO_REGn
+   - valid values for n are 1 to 3
+
 Following regulators of the RK808 PMIC block are supported. Note that
 the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO
 number as described in RK808 datasheet.
-- 
2.14.1

[PATCH v9 RESEND 4/9] mfd: dt-bindings: Add RK805 device tree bindings document

[Heiko Stuebner]

From: Elaine Zhang 

Add device tree bindings documentation for Rockchip's RK805 PMIC.

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-by: Rob Herring 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 Documentation/devicetree/bindings/mfd/rk808.txt | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt 
b/Documentation/devicetree/bindings/mfd/rk808.txt
index 9636ae8d8d41..91b65227afeb 100644
--- a/Documentation/devicetree/bindings/mfd/rk808.txt
+++ b/Documentation/devicetree/bindings/mfd/rk808.txt
@@ -1,11 +1,14 @@
 RK8XX Power Management Integrated Circuit
 
 The rk8xx family current members:
+rk805
 rk808
 rk818
 
 Required properties:
-- compatible: "rockchip,rk808", "rockchip,rk818"
+- compatible: "rockchip,rk805"
+- compatible: "rockchip,rk808"
+- compatible: "rockchip,rk818"
 - reg: I2C slave address
 - interrupt-parent: The parent interrupt controller.
 - interrupts: the interrupt outputs of the controller.
@@ -18,6 +21,14 @@ Optional properties:
 - rockchip,system-power-controller: Telling whether or not this pmic is 
controlling
   the system power.
 
+Optional RK805 properties:
+- vcc1-supply:  The input supply for DCDC_REG1
+- vcc2-supply:  The input supply for DCDC_REG2
+- vcc3-supply:  The input supply for DCDC_REG3
+- vcc4-supply:  The input supply for DCDC_REG4
+- vcc5-supply:  The input supply for LDO_REG1 and LDO_REG2
+- vcc6-supply:  The input supply for LDO_REG3
+
 Optional RK808 properties:
 - vcc1-supply:  The input supply for DCDC_REG1
 - vcc2-supply:  The input supply for DCDC_REG2
@@ -56,6 +67,15 @@ by a child node of the 'regulators' node.
/* standard regulator bindings here */
};
 
+Following regulators of the RK805 PMIC regulators are supported. Note that
+the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO
+number as described in RK805 datasheet.
+
+   - DCDC_REGn
+   - valid values for n are 1 to 4.
+   - LDO_REGn
+   - valid values for n are 1 to 3
+
 Following regulators of the RK808 PMIC block are supported. Note that
 the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO
 number as described in RK808 datasheet.
-- 
2.14.1

[PATCH v9 RESEND 9/9] mfd: rk808: Add RK805 power key support

[Heiko Stuebner]

From: Joseph Chen 

Signed-off-by: Joseph Chen 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 drivers/mfd/rk808.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index c803d2d5dfb7..216fbf6adec9 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -94,6 +94,19 @@ static struct resource rtc_resources[] = {
}
 };
 
+static struct resource rk805_key_resources[] = {
+   {
+   .start  = RK805_IRQ_PWRON_FALL,
+   .end= RK805_IRQ_PWRON_FALL,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = RK805_IRQ_PWRON_RISE,
+   .end= RK805_IRQ_PWRON_RISE,
+   .flags  = IORESOURCE_IRQ,
+   }
+};
+
 static const struct mfd_cell rk805s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
@@ -103,6 +116,10 @@ static const struct mfd_cell rk805s[] = {
.num_resources = ARRAY_SIZE(rtc_resources),
.resources = _resources[0],
},
+   {   .name = "rk805-pwrkey",
+   .num_resources = ARRAY_SIZE(rk805_key_resources),
+   .resources = _key_resources[0],
+   },
 };
 
 static const struct mfd_cell rk808s[] = {
-- 
2.14.1

[PATCH v9 RESEND 1/9] mfd: rk808: fix up the chip id get failed

[Heiko Stuebner]

From: Elaine Zhang 

the rk8xx chip id is:
((MSB << 8) | LSB) & 0xfff0

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 drivers/mfd/rk808.c   | 21 +++--
 include/linux/mfd/rk808.h |  1 +
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index fd087cbb0bde..8e60ebaeaadb 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -325,7 +325,7 @@ static int rk808_probe(struct i2c_client *client,
void (*pm_pwroff_fn)(void);
int nr_pre_init_regs;
int nr_cells;
-   int pm_off = 0;
+   int pm_off = 0, msb, lsb;
int ret;
int i;
 
@@ -333,14 +333,23 @@ static int rk808_probe(struct i2c_client *client,
if (!rk808)
return -ENOMEM;
 
-   rk808->variant = i2c_smbus_read_word_data(client, RK808_ID_MSB);
-   if (rk808->variant < 0) {
-   dev_err(>dev, "Failed to read the chip id at 0x%02x\n",
+   /* Read chip variant */
+   msb = i2c_smbus_read_byte_data(client, RK808_ID_MSB);
+   if (msb < 0) {
+   dev_err(>dev, "failed to read the chip id at 0x%x\n",
RK808_ID_MSB);
-   return rk808->variant;
+   return msb;
}
 
-   dev_dbg(>dev, "Chip id: 0x%x\n", (unsigned int)rk808->variant);
+   lsb = i2c_smbus_read_byte_data(client, RK808_ID_LSB);
+   if (lsb < 0) {
+   dev_err(>dev, "failed to read the chip id at 0x%x\n",
+   RK808_ID_LSB);
+   return lsb;
+   }
+
+   rk808->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
+   dev_info(>dev, "chip id: 0x%x\n", (unsigned int)rk808->variant);
 
switch (rk808->variant) {
case RK808_ID:
diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
index 83701ef7d3c7..54feb140c210 100644
--- a/include/linux/mfd/rk808.h
+++ b/include/linux/mfd/rk808.h
@@ -298,6 +298,7 @@ enum rk818_reg {
 #define VOUT_LO_INTBIT(0)
 #define CLK32KOUT2_EN  BIT(0)
 
+#define RK8XX_ID_MSK   0xfff0
 enum {
BUCK_ILMIN_50MA,
BUCK_ILMIN_100MA,
-- 
2.14.1

[PATCH v9 RESEND 9/9] mfd: rk808: Add RK805 power key support

[Heiko Stuebner]

From: Joseph Chen 

Signed-off-by: Joseph Chen 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 drivers/mfd/rk808.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index c803d2d5dfb7..216fbf6adec9 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -94,6 +94,19 @@ static struct resource rtc_resources[] = {
}
 };
 
+static struct resource rk805_key_resources[] = {
+   {
+   .start  = RK805_IRQ_PWRON_FALL,
+   .end= RK805_IRQ_PWRON_FALL,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = RK805_IRQ_PWRON_RISE,
+   .end= RK805_IRQ_PWRON_RISE,
+   .flags  = IORESOURCE_IRQ,
+   }
+};
+
 static const struct mfd_cell rk805s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
@@ -103,6 +116,10 @@ static const struct mfd_cell rk805s[] = {
.num_resources = ARRAY_SIZE(rtc_resources),
.resources = _resources[0],
},
+   {   .name = "rk805-pwrkey",
+   .num_resources = ARRAY_SIZE(rk805_key_resources),
+   .resources = _key_resources[0],
+   },
 };
 
 static const struct mfd_cell rk808s[] = {
-- 
2.14.1

[PATCH v9 RESEND 1/9] mfd: rk808: fix up the chip id get failed

[Heiko Stuebner]

From: Elaine Zhang 

the rk8xx chip id is:
((MSB << 8) | LSB) & 0xfff0

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 drivers/mfd/rk808.c   | 21 +++--
 include/linux/mfd/rk808.h |  1 +
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index fd087cbb0bde..8e60ebaeaadb 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -325,7 +325,7 @@ static int rk808_probe(struct i2c_client *client,
void (*pm_pwroff_fn)(void);
int nr_pre_init_regs;
int nr_cells;
-   int pm_off = 0;
+   int pm_off = 0, msb, lsb;
int ret;
int i;
 
@@ -333,14 +333,23 @@ static int rk808_probe(struct i2c_client *client,
if (!rk808)
return -ENOMEM;
 
-   rk808->variant = i2c_smbus_read_word_data(client, RK808_ID_MSB);
-   if (rk808->variant < 0) {
-   dev_err(>dev, "Failed to read the chip id at 0x%02x\n",
+   /* Read chip variant */
+   msb = i2c_smbus_read_byte_data(client, RK808_ID_MSB);
+   if (msb < 0) {
+   dev_err(>dev, "failed to read the chip id at 0x%x\n",
RK808_ID_MSB);
-   return rk808->variant;
+   return msb;
}
 
-   dev_dbg(>dev, "Chip id: 0x%x\n", (unsigned int)rk808->variant);
+   lsb = i2c_smbus_read_byte_data(client, RK808_ID_LSB);
+   if (lsb < 0) {
+   dev_err(>dev, "failed to read the chip id at 0x%x\n",
+   RK808_ID_LSB);
+   return lsb;
+   }
+
+   rk808->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
+   dev_info(>dev, "chip id: 0x%x\n", (unsigned int)rk808->variant);
 
switch (rk808->variant) {
case RK808_ID:
diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
index 83701ef7d3c7..54feb140c210 100644
--- a/include/linux/mfd/rk808.h
+++ b/include/linux/mfd/rk808.h
@@ -298,6 +298,7 @@ enum rk818_reg {
 #define VOUT_LO_INTBIT(0)
 #define CLK32KOUT2_EN  BIT(0)
 
+#define RK8XX_ID_MSK   0xfff0
 enum {
BUCK_ILMIN_50MA,
BUCK_ILMIN_100MA,
-- 
2.14.1

[PATCH v9 RESEND 7/9] pinctrl: Add pinctrl driver for the RK805 PMIC

[Heiko Stuebner]

From: Joseph Chen 

RK805 is one of Rockchip PMICs family, it has 2 output only GPIOs.

This driver is also designed for other Rockchip PMICs to expend.
Different PMIC maybe have different pin features, for example,
RK816 has one pin which can be used for TS or GPIO(input/out).
The mainly difference between PMICs pins are pinmux, direction
and output value, that is 'struct rk805_pin_config'.

Signed-off-by: Joseph Chen 
Acked-by: Linus Walleij 
Signed-off-by: Heiko Stuebner 
---
 drivers/pinctrl/Kconfig |   9 +
 drivers/pinctrl/Makefile|   1 +
 drivers/pinctrl/pinctrl-rk805.c | 493 
 3 files changed, 503 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-rk805.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index e14b46c7b37f..124fe2c09c61 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -331,6 +331,15 @@ config PINCTRL_INGENIC
select GENERIC_PINMUX_FUNCTIONS
select REGMAP_MMIO
 
+config PINCTRL_RK805
+   tristate "Pinctrl and GPIO driver for RK805 PMIC"
+   depends on MFD_RK808
+   select GPIOLIB
+   select PINMUX
+   select GENERIC_PINCONF
+   help
+ This selects the pinctrl driver for RK805.
+
 source "drivers/pinctrl/aspeed/Kconfig"
 source "drivers/pinctrl/bcm/Kconfig"
 source "drivers/pinctrl/berlin/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 2bc641d62400..792ffaeaf340 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
 obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
 obj-$(CONFIG_PINCTRL_INGENIC)  += pinctrl-ingenic.o
+obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
 
 obj-$(CONFIG_ARCH_ASPEED)  += aspeed/
 obj-y  += bcm/
diff --git a/drivers/pinctrl/pinctrl-rk805.c b/drivers/pinctrl/pinctrl-rk805.c
new file mode 100644
index ..b0bfd3082a1b
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-rk805.c
@@ -0,0 +1,493 @@
+/*
+ * Pinctrl driver for Rockchip RK805 PMIC
+ *
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Joseph Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under  the terms of the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Based on the pinctrl-as3722 driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "pinconf.h"
+#include "pinctrl-utils.h"
+
+struct rk805_pin_function {
+   const char *name;
+   const char *const *groups;
+   unsigned int ngroups;
+   int mux_option;
+};
+
+struct rk805_pin_group {
+   const char *name;
+   const unsigned int pins[1];
+   unsigned int npins;
+};
+
+/*
+ * @reg: gpio setting register;
+ * @fun_mask: functions select mask value, when set is gpio;
+ * @dir_mask: input or output mask value, when set is output, otherwise input;
+ * @val_mask: gpio set value, when set is level high, otherwise low;
+ *
+ * Different PMIC has different pin features, belowing 3 mask members are not
+ * all necessary for every PMIC. For example, RK805 has 2 pins that can be used
+ * as output only GPIOs, so func_mask and dir_mask are not needed. RK816 has 1
+ * pin that can be used as TS/GPIO, so fun_mask, dir_mask and val_mask are all
+ * necessary.
+ */
+struct rk805_pin_config {
+   u8 reg;
+   u8 fun_msk;
+   u8 dir_msk;
+   u8 val_msk;
+};
+
+struct rk805_pctrl_info {
+   struct rk808 *rk808;
+   struct device *dev;
+   struct pinctrl_dev *pctl;
+   struct gpio_chip gpio_chip;
+   struct pinctrl_desc pinctrl_desc;
+   const struct rk805_pin_function *functions;
+   unsigned int num_functions;
+   const struct rk805_pin_group *groups;
+   int num_pin_groups;
+   const struct pinctrl_pin_desc *pins;
+   unsigned int num_pins;
+   struct rk805_pin_config *pin_cfg;
+};
+
+enum rk805_pinmux_option {
+   RK805_PINMUX_GPIO,
+};
+
+enum {
+   RK805_GPIO0,
+   RK805_GPIO1,
+};
+
+static const char *const rk805_gpio_groups[] = {
+   "gpio0",
+   "gpio1",
+};
+
+/* RK805: 2 output only GPIOs */
+static const struct pinctrl_pin_desc rk805_pins_desc[] = {
+   PINCTRL_PIN(RK805_GPIO0, "gpio0"),
+   PINCTRL_PIN(RK805_GPIO1, "gpio1"),
+};
+
+static const struct rk805_pin_function rk805_pin_functions[] = {
+   {
+   .name = "gpio",
+   .groups = rk805_gpio_groups,
+   .ngroups = ARRAY_SIZE(rk805_gpio_groups),
+   

[PATCH v9 RESEND 7/9] pinctrl: Add pinctrl driver for the RK805 PMIC

[Heiko Stuebner]

From: Joseph Chen 

RK805 is one of Rockchip PMICs family, it has 2 output only GPIOs.

This driver is also designed for other Rockchip PMICs to expend.
Different PMIC maybe have different pin features, for example,
RK816 has one pin which can be used for TS or GPIO(input/out).
The mainly difference between PMICs pins are pinmux, direction
and output value, that is 'struct rk805_pin_config'.

Signed-off-by: Joseph Chen 
Acked-by: Linus Walleij 
Signed-off-by: Heiko Stuebner 
---
 drivers/pinctrl/Kconfig |   9 +
 drivers/pinctrl/Makefile|   1 +
 drivers/pinctrl/pinctrl-rk805.c | 493 
 3 files changed, 503 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-rk805.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index e14b46c7b37f..124fe2c09c61 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -331,6 +331,15 @@ config PINCTRL_INGENIC
select GENERIC_PINMUX_FUNCTIONS
select REGMAP_MMIO
 
+config PINCTRL_RK805
+   tristate "Pinctrl and GPIO driver for RK805 PMIC"
+   depends on MFD_RK808
+   select GPIOLIB
+   select PINMUX
+   select GENERIC_PINCONF
+   help
+ This selects the pinctrl driver for RK805.
+
 source "drivers/pinctrl/aspeed/Kconfig"
 source "drivers/pinctrl/bcm/Kconfig"
 source "drivers/pinctrl/berlin/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 2bc641d62400..792ffaeaf340 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
 obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
 obj-$(CONFIG_PINCTRL_INGENIC)  += pinctrl-ingenic.o
+obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
 
 obj-$(CONFIG_ARCH_ASPEED)  += aspeed/
 obj-y  += bcm/
diff --git a/drivers/pinctrl/pinctrl-rk805.c b/drivers/pinctrl/pinctrl-rk805.c
new file mode 100644
index ..b0bfd3082a1b
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-rk805.c
@@ -0,0 +1,493 @@
+/*
+ * Pinctrl driver for Rockchip RK805 PMIC
+ *
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Joseph Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under  the terms of the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Based on the pinctrl-as3722 driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "pinconf.h"
+#include "pinctrl-utils.h"
+
+struct rk805_pin_function {
+   const char *name;
+   const char *const *groups;
+   unsigned int ngroups;
+   int mux_option;
+};
+
+struct rk805_pin_group {
+   const char *name;
+   const unsigned int pins[1];
+   unsigned int npins;
+};
+
+/*
+ * @reg: gpio setting register;
+ * @fun_mask: functions select mask value, when set is gpio;
+ * @dir_mask: input or output mask value, when set is output, otherwise input;
+ * @val_mask: gpio set value, when set is level high, otherwise low;
+ *
+ * Different PMIC has different pin features, belowing 3 mask members are not
+ * all necessary for every PMIC. For example, RK805 has 2 pins that can be used
+ * as output only GPIOs, so func_mask and dir_mask are not needed. RK816 has 1
+ * pin that can be used as TS/GPIO, so fun_mask, dir_mask and val_mask are all
+ * necessary.
+ */
+struct rk805_pin_config {
+   u8 reg;
+   u8 fun_msk;
+   u8 dir_msk;
+   u8 val_msk;
+};
+
+struct rk805_pctrl_info {
+   struct rk808 *rk808;
+   struct device *dev;
+   struct pinctrl_dev *pctl;
+   struct gpio_chip gpio_chip;
+   struct pinctrl_desc pinctrl_desc;
+   const struct rk805_pin_function *functions;
+   unsigned int num_functions;
+   const struct rk805_pin_group *groups;
+   int num_pin_groups;
+   const struct pinctrl_pin_desc *pins;
+   unsigned int num_pins;
+   struct rk805_pin_config *pin_cfg;
+};
+
+enum rk805_pinmux_option {
+   RK805_PINMUX_GPIO,
+};
+
+enum {
+   RK805_GPIO0,
+   RK805_GPIO1,
+};
+
+static const char *const rk805_gpio_groups[] = {
+   "gpio0",
+   "gpio1",
+};
+
+/* RK805: 2 output only GPIOs */
+static const struct pinctrl_pin_desc rk805_pins_desc[] = {
+   PINCTRL_PIN(RK805_GPIO0, "gpio0"),
+   PINCTRL_PIN(RK805_GPIO1, "gpio1"),
+};
+
+static const struct rk805_pin_function rk805_pin_functions[] = {
+   {
+   .name = "gpio",
+   .groups = rk805_gpio_groups,
+   .ngroups = ARRAY_SIZE(rk805_gpio_groups),
+   .mux_option = RK805_PINMUX_GPIO,
+   },
+};
+
+static const struct rk805_pin_group rk805_pin_groups[] = {
+   {
+  

[PATCH v9 RESEND 3/9] regulator: rk808: Add regulator driver for RK805

[Heiko Stuebner]

From: Elaine Zhang 

Add support for the rk805 regulator. The regulator module consists
of 4 DCDCs, 3 LDOs.

The output voltages are configurable and are meant to supply power
to the main processor and other components.

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-by: Mark Brown 
Signed-off-by: Heiko Stuebner 
---
 drivers/regulator/Kconfig   |   4 +-
 drivers/regulator/rk808-regulator.c | 130 
 2 files changed, 132 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 99b9362331b5..008ab58cd19b 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -687,11 +687,11 @@ config REGULATOR_RC5T583
  outputs which can be controlled by i2c communication.
 
 config REGULATOR_RK808
-   tristate "Rockchip RK808/RK818 Power regulators"
+   tristate "Rockchip RK805/RK808/RK818 Power regulators"
depends on MFD_RK808
help
  Select this option to enable the power regulator of ROCKCHIP
- PMIC RK808 and RK818.
+ PMIC RK805,RK808 and RK818.
  This driver supports the control of different power rails of device
  through regulator interface. The device supports multiple DCDC/LDO
  outputs which can be controlled by i2c communication.
diff --git a/drivers/regulator/rk808-regulator.c 
b/drivers/regulator/rk808-regulator.c
index a16d81420612..213b68743cc8 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -65,6 +65,27 @@
 /* max steps for increase voltage of Buck1/2, equal 100mv*/
 #define MAX_STEPS_ONE_TIME 8
 
+#define RK805_DESC(_id, _match, _supply, _min, _max, _step, _vreg,  \
+   _vmask, _ereg, _emask, _etime)  \
+   [_id] = {   \
+   .name   = (_match), \
+   .supply_name= (_supply),\
+   .of_match   = of_match_ptr(_match), \
+   .regulators_node = of_match_ptr("regulators"),  \
+   .type   = REGULATOR_VOLTAGE,\
+   .id = (_id),\
+   .n_voltages = (((_max) - (_min)) / (_step) + 1),\
+   .owner  = THIS_MODULE,  \
+   .min_uV = (_min) * 1000,\
+   .uV_step= (_step) * 1000,   \
+   .vsel_reg   = (_vreg),  \
+   .vsel_mask  = (_vmask), \
+   .enable_reg = (_ereg),  \
+   .enable_mask= (_emask), \
+   .enable_time= (_etime), \
+   .ops= _reg_ops,   \
+   }
+
 #define RK8XX_DESC(_id, _match, _supply, _min, _max, _step, _vreg, \
_vmask, _ereg, _emask, _etime)  \
[_id] = {   \
@@ -298,6 +319,28 @@ static int rk808_set_suspend_voltage_range(struct 
regulator_dev *rdev, int uv)
  sel);
 }
 
+static int rk805_set_suspend_enable(struct regulator_dev *rdev)
+{
+   unsigned int reg;
+
+   reg = rdev->desc->enable_reg + RK808_SLP_SET_OFF_REG_OFFSET;
+
+   return regmap_update_bits(rdev->regmap, reg,
+ rdev->desc->enable_mask,
+ rdev->desc->enable_mask);
+}
+
+static int rk805_set_suspend_disable(struct regulator_dev *rdev)
+{
+   unsigned int reg;
+
+   reg = rdev->desc->enable_reg + RK808_SLP_SET_OFF_REG_OFFSET;
+
+   return regmap_update_bits(rdev->regmap, reg,
+ rdev->desc->enable_mask,
+ 0);
+}
+
 static int rk808_set_suspend_enable(struct regulator_dev *rdev)
 {
unsigned int reg;
@@ -320,6 +363,27 @@ static int rk808_set_suspend_disable(struct regulator_dev 
*rdev)
  rdev->desc->enable_mask);
 }
 
+static struct regulator_ops rk805_reg_ops = {
+   .list_voltage   = regulator_list_voltage_linear,
+   .map_voltage= regulator_map_voltage_linear,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .is_enabled = 

[PATCH v9 RESEND 3/9] regulator: rk808: Add regulator driver for RK805

[Heiko Stuebner]

From: Elaine Zhang 

Add support for the rk805 regulator. The regulator module consists
of 4 DCDCs, 3 LDOs.

The output voltages are configurable and are meant to supply power
to the main processor and other components.

Signed-off-by: Elaine Zhang 
Signed-off-by: Joseph Chen 
Acked-by: Mark Brown 
Signed-off-by: Heiko Stuebner 
---
 drivers/regulator/Kconfig   |   4 +-
 drivers/regulator/rk808-regulator.c | 130 
 2 files changed, 132 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 99b9362331b5..008ab58cd19b 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -687,11 +687,11 @@ config REGULATOR_RC5T583
  outputs which can be controlled by i2c communication.
 
 config REGULATOR_RK808
-   tristate "Rockchip RK808/RK818 Power regulators"
+   tristate "Rockchip RK805/RK808/RK818 Power regulators"
depends on MFD_RK808
help
  Select this option to enable the power regulator of ROCKCHIP
- PMIC RK808 and RK818.
+ PMIC RK805,RK808 and RK818.
  This driver supports the control of different power rails of device
  through regulator interface. The device supports multiple DCDC/LDO
  outputs which can be controlled by i2c communication.
diff --git a/drivers/regulator/rk808-regulator.c 
b/drivers/regulator/rk808-regulator.c
index a16d81420612..213b68743cc8 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -65,6 +65,27 @@
 /* max steps for increase voltage of Buck1/2, equal 100mv*/
 #define MAX_STEPS_ONE_TIME 8
 
+#define RK805_DESC(_id, _match, _supply, _min, _max, _step, _vreg,  \
+   _vmask, _ereg, _emask, _etime)  \
+   [_id] = {   \
+   .name   = (_match), \
+   .supply_name= (_supply),\
+   .of_match   = of_match_ptr(_match), \
+   .regulators_node = of_match_ptr("regulators"),  \
+   .type   = REGULATOR_VOLTAGE,\
+   .id = (_id),\
+   .n_voltages = (((_max) - (_min)) / (_step) + 1),\
+   .owner  = THIS_MODULE,  \
+   .min_uV = (_min) * 1000,\
+   .uV_step= (_step) * 1000,   \
+   .vsel_reg   = (_vreg),  \
+   .vsel_mask  = (_vmask), \
+   .enable_reg = (_ereg),  \
+   .enable_mask= (_emask), \
+   .enable_time= (_etime), \
+   .ops= _reg_ops,   \
+   }
+
 #define RK8XX_DESC(_id, _match, _supply, _min, _max, _step, _vreg, \
_vmask, _ereg, _emask, _etime)  \
[_id] = {   \
@@ -298,6 +319,28 @@ static int rk808_set_suspend_voltage_range(struct 
regulator_dev *rdev, int uv)
  sel);
 }
 
+static int rk805_set_suspend_enable(struct regulator_dev *rdev)
+{
+   unsigned int reg;
+
+   reg = rdev->desc->enable_reg + RK808_SLP_SET_OFF_REG_OFFSET;
+
+   return regmap_update_bits(rdev->regmap, reg,
+ rdev->desc->enable_mask,
+ rdev->desc->enable_mask);
+}
+
+static int rk805_set_suspend_disable(struct regulator_dev *rdev)
+{
+   unsigned int reg;
+
+   reg = rdev->desc->enable_reg + RK808_SLP_SET_OFF_REG_OFFSET;
+
+   return regmap_update_bits(rdev->regmap, reg,
+ rdev->desc->enable_mask,
+ 0);
+}
+
 static int rk808_set_suspend_enable(struct regulator_dev *rdev)
 {
unsigned int reg;
@@ -320,6 +363,27 @@ static int rk808_set_suspend_disable(struct regulator_dev 
*rdev)
  rdev->desc->enable_mask);
 }
 
+static struct regulator_ops rk805_reg_ops = {
+   .list_voltage   = regulator_list_voltage_linear,
+   .map_voltage= regulator_map_voltage_linear,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+   .set_suspend_voltage= rk808_set_suspend_voltage,
+   

[PATCH v9 RESEND 0/9] mfd: rk808: Add RK805 support

[Heiko Stuebner]

Hi Lee,

as we talked about on IRC on friday, here are the patches enabling
rk805 support in the common rk808 driver. As we agreed I've dropped
the cosmetic patches for clk and rtc adding the rk805 to the Kconfig
helptext and I've also dropped the input driver patch, which Dmitry
already applied.

I've also checked that the patches apply to your mfd-next branch.


Thanks for considering these
Heiko


old changelog from Joseph

change in v9:
PATCH V9 1/12: (1) fix spelling issue: s/Chip/chip/
   (2) apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 2/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 3/12: None
PATCH V9 4/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 5/12: None
PATCH V9 6/12: None
PATCH V9 7/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 8/12: apply tag: Acked-by: Linus Walleij 
PATCH V9 9/12: None (Actually, something directly updated by Dmitry Torokhov 
and applied on PATCH V7.
   Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/log/?h=next
PATCH V9 10/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 11/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 12/12: None

change in v8:
PATCH V8 1/12: add: Signed-off-by: Joseph Chen 
PATCH V8 2/12: add: Signed-off-by: Joseph Chen 
PATCH V8 3/12: add: Signed-off-by: Joseph Chen 
PATCH V8 4/12: add: Signed-off-by: Joseph Chen 
PATCH V8 5/12: add: Signed-off-by: Joseph Chen 
PATCH V8 6/12: add: Signed-off-by: Joseph Chen 
PATCH V8 7/12: add: Signed-off-by: Joseph Chen 
PATCH V8 8/12: (1) Kconfig: update coding style
   (2) pinctrl-rk805.c: using #include 
   (3) pinctrl-rk805.c: inline data and open code it; remove 
FUNCTION_GROUP and PINGROUP macros definition 
PATCH V8 9/12: NO change in V8
PATCH V8 10/12: apply tag: Acked-by: Linus Walleij    
PATCH V8 11/12: NO change in V8
PATCH V8 12/12: (1) using semicolon after "output-high"
(2) apply tag: Acked-by: Linus Walleij 


change in v7:
PATCH V7 1/12: NO change in V7
PATCH V7 2/12: NO change in V7
PATCH V7 3/12: fix missing: Acked-by: Mark Brown 
PATCH V7 4/12: NO change in V7
PATCH V7 5/12: NO change in V7
PATCH V7 6/12: NO change in V7
PATCH V7 7/12: fix missing: Acked-by: Rob Herring 
PATCH V7 8/12: abandon drivers/gpio/gpio-rk805.c and add 
drivers/pinctrl/pinctrl-rk805.c
PATCH V7 9/12: reset author and signed off with my english name
   reset MODULE_AUTHOR() with my english name
   replace devm_request_threaded_irq() with 
devm_request_any_context_irq()
PATCH V7 10/12: replace 'gpio-rk805' with 'pinctrl-rk805' in struct mfd_cell 
rk805s[]
PATCH V7 11/12: NO change in V7
PATCH V7 12/12: dt-bindings: abandon gpio-rk805.txt and add pinctrl-rk805.txt

change in v6:
patch1~7 no changed in V6.
add patch 8~12 for gpio and powerkey func for rk805.

change in v5:
PATCH V5 1/7: NO change in V5
PATCH V5 2/7: fix the rk805 reg addr in numerical order
PATCH V5 3/7: NO change in V5
PATCH V5 4/7: fix up the rk805_device_shutdown func
PATCH V5 5/7: NO change in V5
PATCH V5 6/7: NO change in V5
PATCH V5 7/7: fix up the description of the rk805

change in v4:
PATCH V4 1/7: NO change in V4
PATCH V4 2/7: rename the commit message
PATCH V4 3/7: NO change in V4
PATCH V4 4/7: Split this patch up into subsystems patch 5/7 6/7
PATCH V4 5/7: new added
PATCH V4 6/7: new added
PATCH V4 7/7: NO change in V4


change in V3:
PATCH V3 1/5: NO change in V3
PATCH V3 2/5: add rk805 RTC INT MASK define
PATCH V3 3/5: RK805 set suspend enable and disable is different from rk808
  use rk805_regs_ops and rk805_switch_ops
PATCH V3 4/5: fix up the shutdown func
  use pm_shutdown_prepare_fn to prepare shutdown
  and pm_pwroff_fn pull down gpio to shut down rk805
  it will update in the future(after rk808 support gpio func)
PATCH V3 5/5: NO change in V3

change in V2:
PATCH V2 1/5: NO change in V2
PATCH V2 2/5: add rk805 BUCK ILMAX define
PATCH V2 3/5: NO change in V2
PATCH V2 4/5: setting RK805 BUCK ILMAX in pre init
PATCH V2 5/5: Add RK805 device tree bindings document


Elaine Zhang (5):
  mfd: rk808: fix up the chip id get failed
  mfd: rk808: add rk805 regs addr and ID
  regulator: rk808: Add regulator driver for RK805
  mfd: dt-bindings: Add RK805 device tree bindings document
  mfd: rk808: Add RK805 support

Joseph Chen (4):
  pinctrl: dt-bindings: add bindings for Rockchip RK805 PMIC
  pinctrl: Add pinctrl driver for the RK805 PMIC
  mfd: rk808: Add RK805 pinctrl support
  mfd: rk808: Add RK805 power key support

 

[PATCH v9 RESEND 0/9] mfd: rk808: Add RK805 support

[Heiko Stuebner]

Hi Lee,

as we talked about on IRC on friday, here are the patches enabling
rk805 support in the common rk808 driver. As we agreed I've dropped
the cosmetic patches for clk and rtc adding the rk805 to the Kconfig
helptext and I've also dropped the input driver patch, which Dmitry
already applied.

I've also checked that the patches apply to your mfd-next branch.


Thanks for considering these
Heiko


old changelog from Joseph

change in v9:
PATCH V9 1/12: (1) fix spelling issue: s/Chip/chip/
   (2) apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 2/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 3/12: None
PATCH V9 4/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 5/12: None
PATCH V9 6/12: None
PATCH V9 7/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 8/12: apply tag: Acked-by: Linus Walleij 
PATCH V9 9/12: None (Actually, something directly updated by Dmitry Torokhov 
and applied on PATCH V7.
   Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/log/?h=next
PATCH V9 10/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 11/12: apply tag: Acked-for-MFD-by: Lee Jones 
PATCH V9 12/12: None

change in v8:
PATCH V8 1/12: add: Signed-off-by: Joseph Chen 
PATCH V8 2/12: add: Signed-off-by: Joseph Chen 
PATCH V8 3/12: add: Signed-off-by: Joseph Chen 
PATCH V8 4/12: add: Signed-off-by: Joseph Chen 
PATCH V8 5/12: add: Signed-off-by: Joseph Chen 
PATCH V8 6/12: add: Signed-off-by: Joseph Chen 
PATCH V8 7/12: add: Signed-off-by: Joseph Chen 
PATCH V8 8/12: (1) Kconfig: update coding style
   (2) pinctrl-rk805.c: using #include 
   (3) pinctrl-rk805.c: inline data and open code it; remove 
FUNCTION_GROUP and PINGROUP macros definition 
PATCH V8 9/12: NO change in V8
PATCH V8 10/12: apply tag: Acked-by: Linus Walleij
PATCH V8 11/12: NO change in V8
PATCH V8 12/12: (1) using semicolon after "output-high"
(2) apply tag: Acked-by: Linus Walleij 


change in v7:
PATCH V7 1/12: NO change in V7
PATCH V7 2/12: NO change in V7
PATCH V7 3/12: fix missing: Acked-by: Mark Brown 
PATCH V7 4/12: NO change in V7
PATCH V7 5/12: NO change in V7
PATCH V7 6/12: NO change in V7
PATCH V7 7/12: fix missing: Acked-by: Rob Herring 
PATCH V7 8/12: abandon drivers/gpio/gpio-rk805.c and add 
drivers/pinctrl/pinctrl-rk805.c
PATCH V7 9/12: reset author and signed off with my english name
   reset MODULE_AUTHOR() with my english name
   replace devm_request_threaded_irq() with 
devm_request_any_context_irq()
PATCH V7 10/12: replace 'gpio-rk805' with 'pinctrl-rk805' in struct mfd_cell 
rk805s[]
PATCH V7 11/12: NO change in V7
PATCH V7 12/12: dt-bindings: abandon gpio-rk805.txt and add pinctrl-rk805.txt

change in v6:
patch1~7 no changed in V6.
add patch 8~12 for gpio and powerkey func for rk805.

change in v5:
PATCH V5 1/7: NO change in V5
PATCH V5 2/7: fix the rk805 reg addr in numerical order
PATCH V5 3/7: NO change in V5
PATCH V5 4/7: fix up the rk805_device_shutdown func
PATCH V5 5/7: NO change in V5
PATCH V5 6/7: NO change in V5
PATCH V5 7/7: fix up the description of the rk805

change in v4:
PATCH V4 1/7: NO change in V4
PATCH V4 2/7: rename the commit message
PATCH V4 3/7: NO change in V4
PATCH V4 4/7: Split this patch up into subsystems patch 5/7 6/7
PATCH V4 5/7: new added
PATCH V4 6/7: new added
PATCH V4 7/7: NO change in V4


change in V3:
PATCH V3 1/5: NO change in V3
PATCH V3 2/5: add rk805 RTC INT MASK define
PATCH V3 3/5: RK805 set suspend enable and disable is different from rk808
  use rk805_regs_ops and rk805_switch_ops
PATCH V3 4/5: fix up the shutdown func
  use pm_shutdown_prepare_fn to prepare shutdown
  and pm_pwroff_fn pull down gpio to shut down rk805
  it will update in the future(after rk808 support gpio func)
PATCH V3 5/5: NO change in V3

change in V2:
PATCH V2 1/5: NO change in V2
PATCH V2 2/5: add rk805 BUCK ILMAX define
PATCH V2 3/5: NO change in V2
PATCH V2 4/5: setting RK805 BUCK ILMAX in pre init
PATCH V2 5/5: Add RK805 device tree bindings document


Elaine Zhang (5):
  mfd: rk808: fix up the chip id get failed
  mfd: rk808: add rk805 regs addr and ID
  regulator: rk808: Add regulator driver for RK805
  mfd: dt-bindings: Add RK805 device tree bindings document
  mfd: rk808: Add RK805 support

Joseph Chen (4):
  pinctrl: dt-bindings: add bindings for Rockchip RK805 PMIC
  pinctrl: Add pinctrl driver for the RK805 PMIC
  mfd: rk808: Add RK805 pinctrl support
  mfd: rk808: Add RK805 power key support

 Documentation/devicetree/bindings/mfd/rk808.txt|  22 +-
 .../devicetree/bindings/pinctrl/pinctrl-rk805.txt  |  63 +++
 drivers/mfd/Kconfig|   4 +-
 drivers/mfd/rk808.c| 147 +-
 drivers/pinctrl/Kconfig|   9 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/pinctrl-rk805.c| 493 +

[PATCH v9 RESEND 6/9] pinctrl: dt-bindings: add bindings for Rockchip RK805 PMIC

[Heiko Stuebner]

From: Joseph Chen 

Signed-off-by: Joseph Chen 
Acked-by: Linus Walleij 
Acked-by: Rob Herring 
Signed-off-by: Heiko Stuebner 
---
 .../devicetree/bindings/pinctrl/pinctrl-rk805.txt  | 63 ++
 1 file changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
new file mode 100644
index ..eee3dc260934
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
@@ -0,0 +1,63 @@
+Pincontrol driver for RK805 Power management IC.
+
+RK805 has 2 pins which can be configured as GPIO output only.
+
+Please refer file 
+for details of the common pinctrl bindings used by client devices,
+including the meaning of the phrase "pin configuration node".
+
+Optional Pinmux properties:
+--
+Following properties are required if default setting of pins are required
+at boot.
+- pinctrl-names: A pinctrl state named per .
+- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
+   .
+
+The pin configurations are defined as child of the pinctrl states node. Each
+sub-node have following properties:
+
+Required properties:
+--
+- #gpio-cells: Should be two. The first cell is the pin number and the
+  second is the GPIO flags.
+
+- gpio-controller: Marks the device node as a GPIO controller.
+
+- pins: List of pins. Valid values of pins properties are: gpio0, gpio1.
+
+First 2 properties must be added in the RK805 PMIC node, documented in
+Documentation/devicetree/bindings/mfd/rk808.txt
+
+Optional properties:
+---
+Following are optional properties defined as pinmux DT binding document
+. Absence of properties will leave the configuration
+on default.
+   function,
+   output-low,
+   output-high.
+
+Valid values for function properties are: gpio.
+
+Theres is also not customised properties for any GPIO.
+
+Example:
+
+rk805: rk805@18 {
+   compatible = "rockchip,rk805";
+   ...
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_int_l>, <_default>;
+
+   rk805_default: pinmux {
+   gpio01 {
+   pins = "gpio0", "gpio1";
+   function = "gpio";
+   output-high;
+   };
+   };
+};
-- 
2.14.1

[PATCH v9 RESEND 8/9] mfd: rk808: Add RK805 pinctrl support

[Heiko Stuebner]

From: Joseph Chen 

Signed-off-by: Joseph Chen 
Acked-by: Linus Walleij 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 drivers/mfd/rk808.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 18329c8b4fe7..c803d2d5dfb7 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -97,6 +97,7 @@ static struct resource rtc_resources[] = {
 static const struct mfd_cell rk805s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
+   { .name = "rk805-pinctrl", },
{
.name = "rk808-rtc",
.num_resources = ARRAY_SIZE(rtc_resources),
-- 
2.14.1

[PATCH v9 RESEND 6/9] pinctrl: dt-bindings: add bindings for Rockchip RK805 PMIC

[Heiko Stuebner]

From: Joseph Chen 

Signed-off-by: Joseph Chen 
Acked-by: Linus Walleij 
Acked-by: Rob Herring 
Signed-off-by: Heiko Stuebner 
---
 .../devicetree/bindings/pinctrl/pinctrl-rk805.txt  | 63 ++
 1 file changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
new file mode 100644
index ..eee3dc260934
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
@@ -0,0 +1,63 @@
+Pincontrol driver for RK805 Power management IC.
+
+RK805 has 2 pins which can be configured as GPIO output only.
+
+Please refer file 
+for details of the common pinctrl bindings used by client devices,
+including the meaning of the phrase "pin configuration node".
+
+Optional Pinmux properties:
+--
+Following properties are required if default setting of pins are required
+at boot.
+- pinctrl-names: A pinctrl state named per .
+- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
+   .
+
+The pin configurations are defined as child of the pinctrl states node. Each
+sub-node have following properties:
+
+Required properties:
+--
+- #gpio-cells: Should be two. The first cell is the pin number and the
+  second is the GPIO flags.
+
+- gpio-controller: Marks the device node as a GPIO controller.
+
+- pins: List of pins. Valid values of pins properties are: gpio0, gpio1.
+
+First 2 properties must be added in the RK805 PMIC node, documented in
+Documentation/devicetree/bindings/mfd/rk808.txt
+
+Optional properties:
+---
+Following are optional properties defined as pinmux DT binding document
+. Absence of properties will leave the configuration
+on default.
+   function,
+   output-low,
+   output-high.
+
+Valid values for function properties are: gpio.
+
+Theres is also not customised properties for any GPIO.
+
+Example:
+
+rk805: rk805@18 {
+   compatible = "rockchip,rk805";
+   ...
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_int_l>, <_default>;
+
+   rk805_default: pinmux {
+   gpio01 {
+   pins = "gpio0", "gpio1";
+   function = "gpio";
+   output-high;
+   };
+   };
+};
-- 
2.14.1

[PATCH v9 RESEND 8/9] mfd: rk808: Add RK805 pinctrl support

[Heiko Stuebner]

From: Joseph Chen 

Signed-off-by: Joseph Chen 
Acked-by: Linus Walleij 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Heiko Stuebner 
---
 drivers/mfd/rk808.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 18329c8b4fe7..c803d2d5dfb7 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -97,6 +97,7 @@ static struct resource rtc_resources[] = {
 static const struct mfd_cell rk805s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
+   { .name = "rk805-pinctrl", },
{
.name = "rk808-rtc",
.num_resources = ARRAY_SIZE(rtc_resources),
-- 
2.14.1

Re: kvm splat in mmu_spte_clear_track_bits

[Wanpeng Li]

2017-08-21 7:13 GMT+08:00 Adam Borowski :
> Hi!
> I'm afraid I keep getting a quite reliable, but random, splat when running
> KVM:

I reported something similar before. https://lkml.org/lkml/2017/6/29/64

Regards,
Wanpeng Li

>
> [ cut here ]
> WARNING: CPU: 5 PID: 5826 at arch/x86/kvm/mmu.c:717 
> mmu_spte_clear_track_bits+0x123/0x170
> Modules linked in: tun nbd arc4 rtl8xxxu mac80211 cfg80211 rfkill nouveau 
> video ttm
> CPU: 5 PID: 5826 Comm: qemu-system-x86 Not tainted 
> 4.13.0-rc5-vanilla-ubsan-00211-g7f680d7ec315 #1
> Hardware name: System manufacturer System Product Name/M4A77T, BIOS 2401
> 05/18/2011
> task: 880207ef0400 task.stack: c900035e4000
> RIP: 0010:mmu_spte_clear_track_bits+0x123/0x170
> RSP: 0018:c900035e7ab0 EFLAGS: 00010246
> RAX:  RBX: 00010501cc67 RCX: 0001
> RDX: dead00ff RSI: 88020e501df8 RDI: 04140700
> RBP: c900035e7ad8 R08: 0100 R09: 0003
> R10: 0003 R11: 0005 R12: 0010501c
> R13: ea0004140700 R14: 88020e1d R15: 
> FS:  7f0213fbd700() GS:88022fd4() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 00022187f000 CR4: 06e0
> Call Trace:
>  drop_spte+0x26/0x130
>  mmu_page_zap_pte+0xc4/0x160
>  kvm_mmu_prepare_zap_page+0x65/0x660
>  kvm_mmu_invalidate_zap_all_pages+0xc5/0x1f0
>  kvm_mmu_invalidate_zap_pages_in_memslot+0x9/0x10
>  kvm_page_track_flush_slot+0x86/0xd0
>  kvm_arch_flush_shadow_memslot+0x9/0x10
>  __kvm_set_memory_region+0x8fb/0x14f0
>  kvm_set_memory_region+0x2f/0x50
>  kvm_vm_ioctl+0x559/0xcc0
>  ? kvm_vcpu_ioctl+0x171/0x620
>  ? __switch_to+0x30b/0x740
>  do_vfs_ioctl+0xbb/0x8d0
>  ? find_vma+0x23/0x100
>  ? __fget_light+0x94/0x110
>  SyS_ioctl+0x86/0xa0
>  entry_SYSCALL_64_fastpath+0x17/0x98
> RIP: 0033:0x7f021c80ddc7
> RSP: 002b:7f0213fbc518 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX:  RCX: 7f021c80ddc7
> RDX: 7f0213fbc5b0 RSI: 4020ae46 RDI: 000a
> RBP:  R08: 7f020c1698a0 R09: 
> R10: 7f020c1698a0 R11: 0246 R12: 0006
> R13: 7f022201c000 R14: 0002 R15: 558c3899e550
> Code: ae fc 01 48 85 c0 75 1c 4c 89 e7 e8 98 de fd ff 48 8b 05 81 ae fc 01 48 
> 85 c0 74 ba 48 85 c3 0f 95 c3 eb b8 48 85 c3 74 e7 eb dd <0f> ff eb 97 4c 89 
> e7 66 0f 1f 44 00 00 e8 6b de fd ff eb 97 31
> ---[ end trace 16c196134f0dd0a9 ]---
>
> After this, there are hundreds of repeats and lots of secondary damage which
> kills the host quickly.
>
> Usually this happens within a few minutes, but sometimes it takes ~half an
> hour to reproduce.  Because of this, it'd be unpleasant to bisect -- is this
> problem already known?
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
> ⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
> ⠈⠳⣄

Re: kvm splat in mmu_spte_clear_track_bits

[Wanpeng Li]

2017-08-21 7:13 GMT+08:00 Adam Borowski :
> Hi!
> I'm afraid I keep getting a quite reliable, but random, splat when running
> KVM:

I reported something similar before. https://lkml.org/lkml/2017/6/29/64

Regards,
Wanpeng Li

>
> [ cut here ]
> WARNING: CPU: 5 PID: 5826 at arch/x86/kvm/mmu.c:717 
> mmu_spte_clear_track_bits+0x123/0x170
> Modules linked in: tun nbd arc4 rtl8xxxu mac80211 cfg80211 rfkill nouveau 
> video ttm
> CPU: 5 PID: 5826 Comm: qemu-system-x86 Not tainted 
> 4.13.0-rc5-vanilla-ubsan-00211-g7f680d7ec315 #1
> Hardware name: System manufacturer System Product Name/M4A77T, BIOS 2401
> 05/18/2011
> task: 880207ef0400 task.stack: c900035e4000
> RIP: 0010:mmu_spte_clear_track_bits+0x123/0x170
> RSP: 0018:c900035e7ab0 EFLAGS: 00010246
> RAX:  RBX: 00010501cc67 RCX: 0001
> RDX: dead00ff RSI: 88020e501df8 RDI: 04140700
> RBP: c900035e7ad8 R08: 0100 R09: 0003
> R10: 0003 R11: 0005 R12: 0010501c
> R13: ea0004140700 R14: 88020e1d R15: 
> FS:  7f0213fbd700() GS:88022fd4() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 00022187f000 CR4: 06e0
> Call Trace:
>  drop_spte+0x26/0x130
>  mmu_page_zap_pte+0xc4/0x160
>  kvm_mmu_prepare_zap_page+0x65/0x660
>  kvm_mmu_invalidate_zap_all_pages+0xc5/0x1f0
>  kvm_mmu_invalidate_zap_pages_in_memslot+0x9/0x10
>  kvm_page_track_flush_slot+0x86/0xd0
>  kvm_arch_flush_shadow_memslot+0x9/0x10
>  __kvm_set_memory_region+0x8fb/0x14f0
>  kvm_set_memory_region+0x2f/0x50
>  kvm_vm_ioctl+0x559/0xcc0
>  ? kvm_vcpu_ioctl+0x171/0x620
>  ? __switch_to+0x30b/0x740
>  do_vfs_ioctl+0xbb/0x8d0
>  ? find_vma+0x23/0x100
>  ? __fget_light+0x94/0x110
>  SyS_ioctl+0x86/0xa0
>  entry_SYSCALL_64_fastpath+0x17/0x98
> RIP: 0033:0x7f021c80ddc7
> RSP: 002b:7f0213fbc518 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX:  RCX: 7f021c80ddc7
> RDX: 7f0213fbc5b0 RSI: 4020ae46 RDI: 000a
> RBP:  R08: 7f020c1698a0 R09: 
> R10: 7f020c1698a0 R11: 0246 R12: 0006
> R13: 7f022201c000 R14: 0002 R15: 558c3899e550
> Code: ae fc 01 48 85 c0 75 1c 4c 89 e7 e8 98 de fd ff 48 8b 05 81 ae fc 01 48 
> 85 c0 74 ba 48 85 c3 0f 95 c3 eb b8 48 85 c3 74 e7 eb dd <0f> ff eb 97 4c 89 
> e7 66 0f 1f 44 00 00 e8 6b de fd ff eb 97 31
> ---[ end trace 16c196134f0dd0a9 ]---
>
> After this, there are hundreds of repeats and lots of secondary damage which
> kills the host quickly.
>
> Usually this happens within a few minutes, but sometimes it takes ~half an
> hour to reproduce.  Because of this, it'd be unpleasant to bisect -- is this
> problem already known?
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
> ⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
> ⠈⠳⣄