stack gap fix for 4.1

[Arkadiusz Miskiewicz]

Hi.

I'm looking for stack gap fix backport for 4.1 (it's not in 4.1 stable queue 
git unfortunately).

I wonder if any distro still maintains 4.1 and could already make backport?

Thanks,
-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

stack gap fix for 4.1

[Arkadiusz Miskiewicz]

Hi.

I'm looking for stack gap fix backport for 4.1 (it's not in 4.1 stable queue 
git unfortunately).

I wonder if any distro still maintains 4.1 and could already make backport?

Thanks,
-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: linux-next: build failure after merge of most trees

[Nicholas Piggin]

On Thu, 22 Jun 2017 15:24:41 +1000
Stephen Rothwell  wrote:

> Hi Dave,
> 
> After merging almost all the trees, today's linux-next build (sparc64
> defconfig) failed like this:
> 
> arch/sparc/lib/hweight.o: In function `__arch_hweight8':
> (.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
> `__sw_hweight8' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight16':
> (.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
> `__sw_hweight16' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight32':
> (.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
> `__sw_hweight32' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight64':
> (.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
> `__sw_hweight64' defined in .text section in lib/hweight.o
> 
> I though it may have been caused by the thin archive changes, but
> disabling CONFIG_THIN_ARCHIVE did not fix it. I have cc'd Nick and
> Masahiro just in case.

It could be this

https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=thin-ar=ec2c9c20f0efab37ae31de44fe0617aa61283905

kbuild: handle libs-y archives separately from built-in.o archives

That touches the lib linking code regardless of CONFIG_THIN_ARCHIVE.
You should be able to revert it by itself (which will break a few
other archs, so you would also have to revert the default y patch
for thin archives to repair your tree if this is the cause).

I'll try to get around to it after I fix up some other arch breakage
caused by the series :)

Thanks,
Nick

Re: linux-next: build failure after merge of most trees

[Nicholas Piggin]

On Thu, 22 Jun 2017 15:24:41 +1000
Stephen Rothwell  wrote:

> Hi Dave,
> 
> After merging almost all the trees, today's linux-next build (sparc64
> defconfig) failed like this:
> 
> arch/sparc/lib/hweight.o: In function `__arch_hweight8':
> (.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
> `__sw_hweight8' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight16':
> (.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
> `__sw_hweight16' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight32':
> (.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
> `__sw_hweight32' defined in .text section in lib/hweight.o
> arch/sparc/lib/hweight.o: In function `__arch_hweight64':
> (.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
> `__sw_hweight64' defined in .text section in lib/hweight.o
> 
> I though it may have been caused by the thin archive changes, but
> disabling CONFIG_THIN_ARCHIVE did not fix it. I have cc'd Nick and
> Masahiro just in case.

It could be this

https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=thin-ar=ec2c9c20f0efab37ae31de44fe0617aa61283905

kbuild: handle libs-y archives separately from built-in.o archives

That touches the lib linking code regardless of CONFIG_THIN_ARCHIVE.
You should be able to revert it by itself (which will break a few
other archs, so you would also have to revert the default y patch
for thin archives to repair your tree if this is the cause).

I'll try to get around to it after I fix up some other arch breakage
caused by the series :)

Thanks,
Nick

[PATCH 3/3] iio: adc: mt7622: Add compatible node for mt7622.

[Zhiyong Tao]

This commit adds mt7622 compatible node.

Signed-off-by: Zhiyong Tao 
---
 drivers/iio/adc/mt6577_auxadc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
index 2dd7c74..4a2cd9e 100644
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -308,6 +308,7 @@ static int mt6577_auxadc_remove(struct platform_device 
*pdev)
 static const struct of_device_id mt6577_auxadc_of_match[] = {
{ .compatible = "mediatek,mt2701-auxadc", },
{ .compatible = "mediatek,mt8173-auxadc", },
+   { .compatible = "mediatek,mt7622-auxadc", },
{ }
 };
 MODULE_DEVICE_TABLE(of, mt6577_auxadc_of_match);
-- 
1.7.9.5

[PATCH 0/3] ADC: Mediatek auxadc driver for mt7622

[Zhiyong Tao]

These patches are first version of Mediatek auxadc driver for mt7622.
These patches include three patches.
The First patch adds mt7622 compatible node in binding document.
The second patch adds support for suspend/resume.
The last patch adds mt7622 compatible node in auxadc driver.

Zhiyong Tao (3):
  dt-bindings: adc: mt7622: add binding document
  iio: adc: mt7622: add support for suspend/resume.
  iio: adc: mt7622: Add compatible node for mt7622.

 .../devicetree/bindings/iio/adc/mt6577_auxadc.txt  |1 +
 drivers/iio/adc/mt6577_auxadc.c|   38 
 2 files changed, 39 insertions(+)

--
1.7.9.5

[PATCH 3/3] iio: adc: mt7622: Add compatible node for mt7622.

[Zhiyong Tao]

This commit adds mt7622 compatible node.

Signed-off-by: Zhiyong Tao 
---
 drivers/iio/adc/mt6577_auxadc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
index 2dd7c74..4a2cd9e 100644
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -308,6 +308,7 @@ static int mt6577_auxadc_remove(struct platform_device 
*pdev)
 static const struct of_device_id mt6577_auxadc_of_match[] = {
{ .compatible = "mediatek,mt2701-auxadc", },
{ .compatible = "mediatek,mt8173-auxadc", },
+   { .compatible = "mediatek,mt7622-auxadc", },
{ }
 };
 MODULE_DEVICE_TABLE(of, mt6577_auxadc_of_match);
-- 
1.7.9.5

[PATCH 0/3] ADC: Mediatek auxadc driver for mt7622

[Zhiyong Tao]

These patches are first version of Mediatek auxadc driver for mt7622.
These patches include three patches.
The First patch adds mt7622 compatible node in binding document.
The second patch adds support for suspend/resume.
The last patch adds mt7622 compatible node in auxadc driver.

Zhiyong Tao (3):
  dt-bindings: adc: mt7622: add binding document
  iio: adc: mt7622: add support for suspend/resume.
  iio: adc: mt7622: Add compatible node for mt7622.

 .../devicetree/bindings/iio/adc/mt6577_auxadc.txt  |1 +
 drivers/iio/adc/mt6577_auxadc.c|   38 
 2 files changed, 39 insertions(+)

--
1.7.9.5

[PATCH 1/3] dt-bindings: adc: mt7622: add binding document

[Zhiyong Tao]

The commit adds mt7622 compatible node in binding document.

Signed-off-by: Zhiyong Tao 
---
 .../devicetree/bindings/iio/adc/mt6577_auxadc.txt  |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt 
b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
index 68c45cb..e6aa30a 100644
--- a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
@@ -13,6 +13,7 @@ Required properties:
   - compatible: Should be one of:
 - "mediatek,mt2701-auxadc": For MT2701 family of SoCs
 - "mediatek,mt8173-auxadc": For MT8173 family of SoCs
+- "mediatek,mt7622-auxadc": For MT7622 family of SoCs
   - reg: Address range of the AUXADC unit.
   - clocks: Should contain a clock specifier for each entry in clock-names
   - clock-names: Should contain "main".
-- 
1.7.9.5

[PATCH 2/3] iio: adc: mt7622: add support for suspend/resume.

[Zhiyong Tao]

This patch supports auxadc suspend/resume flow.
Disable auxadc clk and power in suspend function.
Enable axuadc clk and power in resume function.

Signed-off-by: Zhiyong Tao 
---
 drivers/iio/adc/mt6577_auxadc.c |   37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
index 2d104c8..2dd7c74 100644
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -184,6 +184,37 @@ static int mt6577_auxadc_read_raw(struct iio_dev 
*indio_dev,
.read_raw = _auxadc_read_raw,
 };
 
+static int mt6577_auxadc_resume(struct device *dev)
+{
+   struct iio_dev *indio_dev = dev_get_drvdata(dev);
+   struct mt6577_auxadc_device *adc_dev = iio_priv(indio_dev);
+   int ret;
+
+   ret = clk_prepare_enable(adc_dev->adc_clk);
+   if (ret) {
+   pr_err("failed to enable auxadc clock\n");
+   return ret;
+   }
+
+   mt6577_auxadc_mod_reg(adc_dev->reg_base + MT6577_AUXADC_MISC,
+ MT6577_AUXADC_PDN_EN, 0);
+   mdelay(MT6577_AUXADC_POWER_READY_MS);
+
+   return 0;
+}
+
+static int mt6577_auxadc_suspend(struct device *dev)
+{
+   struct iio_dev *indio_dev = dev_get_drvdata(dev);
+   struct mt6577_auxadc_device *adc_dev = iio_priv(indio_dev);
+
+   mt6577_auxadc_mod_reg(adc_dev->reg_base + MT6577_AUXADC_MISC,
+ 0, MT6577_AUXADC_PDN_EN);
+   clk_disable_unprepare(adc_dev->adc_clk);
+
+   return 0;
+}
+
 static int mt6577_auxadc_probe(struct platform_device *pdev)
 {
struct mt6577_auxadc_device *adc_dev;
@@ -269,6 +300,11 @@ static int mt6577_auxadc_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static const struct dev_pm_ops mt6577_auxadc_pm_ops = {
+   .suspend = mt6577_auxadc_suspend,
+   .resume = mt6577_auxadc_resume,
+};
+
 static const struct of_device_id mt6577_auxadc_of_match[] = {
{ .compatible = "mediatek,mt2701-auxadc", },
{ .compatible = "mediatek,mt8173-auxadc", },
@@ -280,6 +316,7 @@ static int mt6577_auxadc_remove(struct platform_device 
*pdev)
.driver = {
.name   = "mt6577-auxadc",
.of_match_table = mt6577_auxadc_of_match,
+   .pm = _auxadc_pm_ops,
},
.probe  = mt6577_auxadc_probe,
.remove = mt6577_auxadc_remove,
-- 
1.7.9.5

[PATCH 1/3] dt-bindings: adc: mt7622: add binding document

[Zhiyong Tao]

The commit adds mt7622 compatible node in binding document.

Signed-off-by: Zhiyong Tao 
---
 .../devicetree/bindings/iio/adc/mt6577_auxadc.txt  |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt 
b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
index 68c45cb..e6aa30a 100644
--- a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
@@ -13,6 +13,7 @@ Required properties:
   - compatible: Should be one of:
 - "mediatek,mt2701-auxadc": For MT2701 family of SoCs
 - "mediatek,mt8173-auxadc": For MT8173 family of SoCs
+- "mediatek,mt7622-auxadc": For MT7622 family of SoCs
   - reg: Address range of the AUXADC unit.
   - clocks: Should contain a clock specifier for each entry in clock-names
   - clock-names: Should contain "main".
-- 
1.7.9.5

[PATCH 2/3] iio: adc: mt7622: add support for suspend/resume.

[Zhiyong Tao]

This patch supports auxadc suspend/resume flow.
Disable auxadc clk and power in suspend function.
Enable axuadc clk and power in resume function.

Signed-off-by: Zhiyong Tao 
---
 drivers/iio/adc/mt6577_auxadc.c |   37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
index 2d104c8..2dd7c74 100644
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -184,6 +184,37 @@ static int mt6577_auxadc_read_raw(struct iio_dev 
*indio_dev,
.read_raw = _auxadc_read_raw,
 };
 
+static int mt6577_auxadc_resume(struct device *dev)
+{
+   struct iio_dev *indio_dev = dev_get_drvdata(dev);
+   struct mt6577_auxadc_device *adc_dev = iio_priv(indio_dev);
+   int ret;
+
+   ret = clk_prepare_enable(adc_dev->adc_clk);
+   if (ret) {
+   pr_err("failed to enable auxadc clock\n");
+   return ret;
+   }
+
+   mt6577_auxadc_mod_reg(adc_dev->reg_base + MT6577_AUXADC_MISC,
+ MT6577_AUXADC_PDN_EN, 0);
+   mdelay(MT6577_AUXADC_POWER_READY_MS);
+
+   return 0;
+}
+
+static int mt6577_auxadc_suspend(struct device *dev)
+{
+   struct iio_dev *indio_dev = dev_get_drvdata(dev);
+   struct mt6577_auxadc_device *adc_dev = iio_priv(indio_dev);
+
+   mt6577_auxadc_mod_reg(adc_dev->reg_base + MT6577_AUXADC_MISC,
+ 0, MT6577_AUXADC_PDN_EN);
+   clk_disable_unprepare(adc_dev->adc_clk);
+
+   return 0;
+}
+
 static int mt6577_auxadc_probe(struct platform_device *pdev)
 {
struct mt6577_auxadc_device *adc_dev;
@@ -269,6 +300,11 @@ static int mt6577_auxadc_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static const struct dev_pm_ops mt6577_auxadc_pm_ops = {
+   .suspend = mt6577_auxadc_suspend,
+   .resume = mt6577_auxadc_resume,
+};
+
 static const struct of_device_id mt6577_auxadc_of_match[] = {
{ .compatible = "mediatek,mt2701-auxadc", },
{ .compatible = "mediatek,mt8173-auxadc", },
@@ -280,6 +316,7 @@ static int mt6577_auxadc_remove(struct platform_device 
*pdev)
.driver = {
.name   = "mt6577-auxadc",
.of_match_table = mt6577_auxadc_of_match,
+   .pm = _auxadc_pm_ops,
},
.probe  = mt6577_auxadc_probe,
.remove = mt6577_auxadc_remove,
-- 
1.7.9.5

Re: [PATCH v2 1/3] input: sun4i-a10-lradc-keys: Add support for A83T

[Ziping Chen]

2017-06-22 4:35 GMT+08:00 Maxime Ripard :
> On Tue, Jun 20, 2017 at 09:44:43PM +0800, Ziping Chen wrote:
>> From: Ziping Chen 
>>
>> Allwinner A83T SoC has a low res adc like the one
>> in Allwinner A10 SoC, however, the A10 SoC's vref
>> of lradc internally is divided by 2/3 and the A83T
>> SoC's isn't, thus add a hardware variant for it to
>> be compatible with various devices.
>
> Where did you get that info from?
>
> Judging from the user manual, the threshold is actually set to 3/4,
> and not 2/3, but there's still one.


In the top of page 266 of the A10 User Manual V1.50, it said "2/3
ADC_REF (Level A)" which mean Level A is 2/3 of the vref.

In the bottom of page 230 of the A83T User Manual V1.5.1, it said
"1.35V (Level A)" meaning that Level A is 1.35V. Oh, it's my fault...
It's 3/4 of the vref (A83T's ADC_REF is fixed at 1.8V).

So... i will change r_lradc_variant_a83t.divisor_numerator to 3 and
r_lradc_variant_a83t.divisor_denominator to 4...

Is there any other problems?

Thanks,
Ziping

>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: [PATCH v2 1/3] input: sun4i-a10-lradc-keys: Add support for A83T

[Ziping Chen]

2017-06-22 4:35 GMT+08:00 Maxime Ripard :
> On Tue, Jun 20, 2017 at 09:44:43PM +0800, Ziping Chen wrote:
>> From: Ziping Chen 
>>
>> Allwinner A83T SoC has a low res adc like the one
>> in Allwinner A10 SoC, however, the A10 SoC's vref
>> of lradc internally is divided by 2/3 and the A83T
>> SoC's isn't, thus add a hardware variant for it to
>> be compatible with various devices.
>
> Where did you get that info from?
>
> Judging from the user manual, the threshold is actually set to 3/4,
> and not 2/3, but there's still one.


In the top of page 266 of the A10 User Manual V1.50, it said "2/3
ADC_REF (Level A)" which mean Level A is 2/3 of the vref.

In the bottom of page 230 of the A83T User Manual V1.5.1, it said
"1.35V (Level A)" meaning that Level A is 1.35V. Oh, it's my fault...
It's 3/4 of the vref (A83T's ADC_REF is fixed at 1.8V).

So... i will change r_lradc_variant_a83t.divisor_numerator to 3 and
r_lradc_variant_a83t.divisor_denominator to 4...

Is there any other problems?

Thanks,
Ziping

>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: linux-next: Tree for Jun 7 (arch/x86/mm/tlb.c: events)

[Stephen Rothwell]

Hi Randy,

On Wed, 21 Jun 2017 20:58:38 -0700 Randy Dunlap <rdun...@infradead.org> wrote:
>
> I cannot repro it on linux-next of 20170621.

Thanks.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: Tree for Jun 7 (arch/x86/mm/tlb.c: events)

[Stephen Rothwell]

Hi Randy,

On Wed, 21 Jun 2017 20:58:38 -0700 Randy Dunlap  wrote:
>
> I cannot repro it on linux-next of 20170621.

Thanks.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of most trees

[Stephen Rothwell]

Hi Dave,

After merging almost all the trees, today's linux-next build (sparc64
defconfig) failed like this:

arch/sparc/lib/hweight.o: In function `__arch_hweight8':
(.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
`__sw_hweight8' defined in .text section in lib/hweight.o
arch/sparc/lib/hweight.o: In function `__arch_hweight16':
(.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
`__sw_hweight16' defined in .text section in lib/hweight.o
arch/sparc/lib/hweight.o: In function `__arch_hweight32':
(.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
`__sw_hweight32' defined in .text section in lib/hweight.o
arch/sparc/lib/hweight.o: In function `__arch_hweight64':
(.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
`__sw_hweight64' defined in .text section in lib/hweight.o

I though it may have been caused by the thin archive changes, but
disabling CONFIG_THIN_ARCHIVE did not fix it. I have cc'd Nick and
Masahiro just in case.

I am using powerpc-le hosted cross compilers:
gcc 5.2.0
binutsila 2.25.2

I have left it broken for now.

32 bit sparc is not affected.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of most trees

[Stephen Rothwell]

Hi Dave,

After merging almost all the trees, today's linux-next build (sparc64
defconfig) failed like this:

arch/sparc/lib/hweight.o: In function `__arch_hweight8':
(.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
`__sw_hweight8' defined in .text section in lib/hweight.o
arch/sparc/lib/hweight.o: In function `__arch_hweight16':
(.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
`__sw_hweight16' defined in .text section in lib/hweight.o
arch/sparc/lib/hweight.o: In function `__arch_hweight32':
(.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
`__sw_hweight32' defined in .text section in lib/hweight.o
arch/sparc/lib/hweight.o: In function `__arch_hweight64':
(.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol 
`__sw_hweight64' defined in .text section in lib/hweight.o

I though it may have been caused by the thin archive changes, but
disabling CONFIG_THIN_ARCHIVE did not fix it. I have cc'd Nick and
Masahiro just in case.

I am using powerpc-le hosted cross compilers:
gcc 5.2.0
binutsila 2.25.2

I have left it broken for now.

32 bit sparc is not affected.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v3 00/11] PCID and improved laziness

[Andy Lutomirski]

On Wed, Jun 21, 2017 at 11:23 AM, Linus Torvalds
 wrote:
> On Tue, Jun 20, 2017 at 10:22 PM, Andy Lutomirski  wrote:
>> There are three performance benefits here:
>
> Side note: can you post the actual performance numbers, even if only
> from some silly test program on just one platform? Things like lmbench
> pipe benchmark or something?
>
> Or maybe you did, and I just missed it. But when talking about
> performance, I'd really like to always see some actual numbers.

Here are some timings using KVM:

pingpong between two processes using eventfd:
patched: 883ns
unpatched: 1046ns (with considerably higher variance)

madvise(MADV_DONTNEED); write to the page; switch CPUs:
patched: ~12.5us
unpatched: 19us

The latter test is a somewhat contrived example to show off the
improved laziness.  Current kernels send an IPI on each iteration if
the system is otherwise idle.

Re: [PATCH v3 00/11] PCID and improved laziness

[Andy Lutomirski]

On Wed, Jun 21, 2017 at 11:23 AM, Linus Torvalds
 wrote:
> On Tue, Jun 20, 2017 at 10:22 PM, Andy Lutomirski  wrote:
>> There are three performance benefits here:
>
> Side note: can you post the actual performance numbers, even if only
> from some silly test program on just one platform? Things like lmbench
> pipe benchmark or something?
>
> Or maybe you did, and I just missed it. But when talking about
> performance, I'd really like to always see some actual numbers.

Here are some timings using KVM:

pingpong between two processes using eventfd:
patched: 883ns
unpatched: 1046ns (with considerably higher variance)

madvise(MADV_DONTNEED); write to the page; switch CPUs:
patched: ~12.5us
unpatched: 19us

The latter test is a somewhat contrived example to show off the
improved laziness.  Current kernels send an IPI on each iteration if
the system is otherwise idle.

Re: [PATCH][net-next] qtnfmac: fix uninitialized return code in ret

[Dan Carpenter]

On Wed, Jun 21, 2017 at 02:25:30PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The return value ret is unitialized and garbage is being returned
> for the three different error conditions when setting up the PCIe
> BARs. Fix this by initializing ret to  -ENOMEM to indicate that
> the BARs failed to be setup correctly.
> 
> Detected by CoverityScan, CID#1437563 ("Unitialized scalar variable")
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
> b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
> index f93b27f3a236..7fc4f0d6a9ad 100644
> --- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
> +++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
> @@ -247,7 +247,7 @@ static void qtnf_pcie_free_shm_ipc(struct 
> qtnf_pcie_bus_priv *priv)
>  
>  static int qtnf_pcie_init_memory(struct qtnf_pcie_bus_priv *priv)
>  {
> - int ret;
> + int ret = -ENOMEM;
>  
>   priv->sysctl_bar = qtnf_map_bar(priv, QTN_SYSCTL_BAR);
>   if (IS_ERR_OR_NULL(priv->sysctl_bar)) {

Not related to your patch but qtnf_map_bar() should be changed not to
return NULL.  When functions return both NULL and error pointers the
NULL is supposed to be a special type of success return.  Here it is
just a fail return where we forgot to set the error code to
ERR_PTR(-ENOMEM).

regards,
dan carpenter

Re: [PATCH][net-next] qtnfmac: fix uninitialized return code in ret

[Dan Carpenter]

On Wed, Jun 21, 2017 at 02:25:30PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The return value ret is unitialized and garbage is being returned
> for the three different error conditions when setting up the PCIe
> BARs. Fix this by initializing ret to  -ENOMEM to indicate that
> the BARs failed to be setup correctly.
> 
> Detected by CoverityScan, CID#1437563 ("Unitialized scalar variable")
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
> b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
> index f93b27f3a236..7fc4f0d6a9ad 100644
> --- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
> +++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
> @@ -247,7 +247,7 @@ static void qtnf_pcie_free_shm_ipc(struct 
> qtnf_pcie_bus_priv *priv)
>  
>  static int qtnf_pcie_init_memory(struct qtnf_pcie_bus_priv *priv)
>  {
> - int ret;
> + int ret = -ENOMEM;
>  
>   priv->sysctl_bar = qtnf_map_bar(priv, QTN_SYSCTL_BAR);
>   if (IS_ERR_OR_NULL(priv->sysctl_bar)) {

Not related to your patch but qtnf_map_bar() should be changed not to
return NULL.  When functions return both NULL and error pointers the
NULL is supposed to be a special type of success return.  Here it is
just a fail return where we forgot to set the error code to
ERR_PTR(-ENOMEM).

regards,
dan carpenter

[PATCH v5 0/2] drm: atmel-hlcdc: clut support

[Peter Rosin]

Hi!

This series adds support for an 8-bit clut mode in the atmel-hlcdc
driver.

Changes since v4:

- Added .clut_offset for overlay2 at 0xe00 for sama5d4 (unconfirmed if 0xe00
  is the correct offset, but I'll eat my hat if it's not there). The sama5d4
  overlay2 is indeed there, it is just AWOL in the current datasheet.
- Added Acked-by from Daniel on patch 2/2.

Changes since v3:

- Dropped ugly code (patches 2/3 and 3/3) for legacy fbdev interaction.
- Slit out the .set_property change to a patch of its own.

Changes since v2:

- Fix mapping to the clut registers.

Changes since v1:

- Move the clut update from atmel_hlcdc_crtc_mode_valid to
  atmel_hlcdc_plane_atomic_update.
- Add default .gamma_set helper (drm_atomic_helper_legacy_gamma_set).
- Don't keep a spare copy of the clut, reuse gamma_store instead.
- Don't try to synchronize the legacy fb clut with the drm clut.

Cheers,
peda

Peter Rosin (2):
  drm: atmel-hlcdc: add missing .set_property helper to the crtc
  drm: atmel-hlcdc: add support for 8-bit color lookup table mode

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  5 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 14 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 16 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 29 +
 4 files changed, 64 insertions(+)

-- 
2.1.4

[PATCH v5 2/2] drm: atmel-hlcdc: add support for 8-bit color lookup table mode

[Peter Rosin]

All layers of all supported chips support this, the only variable is the
base address of the lookup table in the register map.

Acked-by: Daniel Vetter 
Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  4 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 14 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 16 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 29 +
 4 files changed, 63 insertions(+)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index cc00ce3..694adcc 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -430,6 +430,7 @@ static const struct drm_crtc_funcs atmel_hlcdc_crtc_funcs = 
{
.enable_vblank = atmel_hlcdc_crtc_enable_vblank,
.disable_vblank = atmel_hlcdc_crtc_disable_vblank,
.set_property = drm_atomic_helper_crtc_set_property,
+   .gamma_set = drm_atomic_helper_legacy_gamma_set,
 };
 
 int atmel_hlcdc_crtc_create(struct drm_device *dev)
@@ -485,6 +486,9 @@ int atmel_hlcdc_crtc_create(struct drm_device *dev)
drm_crtc_helper_add(>base, _crtc_helper_funcs);
drm_crtc_vblank_reset(>base);
 
+   drm_mode_crtc_set_gamma_size(>base, ATMEL_HLCDC_CLUT_SIZE);
+   drm_crtc_enable_color_mgmt(>base, 0, false, 
ATMEL_HLCDC_CLUT_SIZE);
+
dc->crtc = >base;
 
return 0;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 30dbffd..6ff771c 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -42,6 +42,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9n12_layers[] = {
.default_color = 3,
.general_config = 4,
},
+   .clut_offset = 0x400,
},
 };
 
@@ -73,6 +74,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x400,
},
{
.name = "overlay1",
@@ -91,6 +93,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0x800,
},
{
.name = "high-end-overlay",
@@ -112,6 +115,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.scaler_config = 13,
.csc = 14,
},
+   .clut_offset = 0x1000,
},
{
.name = "cursor",
@@ -131,6 +135,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0x1400,
},
 };
 
@@ -162,6 +167,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x600,
},
{
.name = "overlay1",
@@ -180,6 +186,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0xa00,
},
{
.name = "overlay2",
@@ -198,6 +205,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0xe00,
},
{
.name = "high-end-overlay",
@@ -223,6 +231,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
},
.csc = 14,
},
+   .clut_offset = 0x1200,
},
{
.name = "cursor",
@@ -244,6 +253,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.general_config = 9,
.scaler_config = 13,
},
+   .clut_offset = 0x1600,
},
 };
 
@@ -275,6 +285,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d4_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x600,
},
{
.name = "overlay1",
@@ -293,6 +304,7 @@ static const struct atmel_hlcdc_layer_desc 

[PATCH v5 1/2] drm: atmel-hlcdc: add missing .set_property helper to the crtc

[Peter Rosin]

The default implementation should be used.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 5348985..cc00ce3 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -429,6 +429,7 @@ static const struct drm_crtc_funcs atmel_hlcdc_crtc_funcs = 
{
.atomic_destroy_state = atmel_hlcdc_crtc_destroy_state,
.enable_vblank = atmel_hlcdc_crtc_enable_vblank,
.disable_vblank = atmel_hlcdc_crtc_disable_vblank,
+   .set_property = drm_atomic_helper_crtc_set_property,
 };
 
 int atmel_hlcdc_crtc_create(struct drm_device *dev)
-- 
2.1.4

[PATCH v5 0/2] drm: atmel-hlcdc: clut support

[Peter Rosin]

Hi!

This series adds support for an 8-bit clut mode in the atmel-hlcdc
driver.

Changes since v4:

- Added .clut_offset for overlay2 at 0xe00 for sama5d4 (unconfirmed if 0xe00
  is the correct offset, but I'll eat my hat if it's not there). The sama5d4
  overlay2 is indeed there, it is just AWOL in the current datasheet.
- Added Acked-by from Daniel on patch 2/2.

Changes since v3:

- Dropped ugly code (patches 2/3 and 3/3) for legacy fbdev interaction.
- Slit out the .set_property change to a patch of its own.

Changes since v2:

- Fix mapping to the clut registers.

Changes since v1:

- Move the clut update from atmel_hlcdc_crtc_mode_valid to
  atmel_hlcdc_plane_atomic_update.
- Add default .gamma_set helper (drm_atomic_helper_legacy_gamma_set).
- Don't keep a spare copy of the clut, reuse gamma_store instead.
- Don't try to synchronize the legacy fb clut with the drm clut.

Cheers,
peda

Peter Rosin (2):
  drm: atmel-hlcdc: add missing .set_property helper to the crtc
  drm: atmel-hlcdc: add support for 8-bit color lookup table mode

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  5 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 14 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 16 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 29 +
 4 files changed, 64 insertions(+)

-- 
2.1.4

[PATCH v5 2/2] drm: atmel-hlcdc: add support for 8-bit color lookup table mode

[Peter Rosin]

All layers of all supported chips support this, the only variable is the
base address of the lookup table in the register map.

Acked-by: Daniel Vetter 
Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  4 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 14 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 16 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 29 +
 4 files changed, 63 insertions(+)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index cc00ce3..694adcc 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -430,6 +430,7 @@ static const struct drm_crtc_funcs atmel_hlcdc_crtc_funcs = 
{
.enable_vblank = atmel_hlcdc_crtc_enable_vblank,
.disable_vblank = atmel_hlcdc_crtc_disable_vblank,
.set_property = drm_atomic_helper_crtc_set_property,
+   .gamma_set = drm_atomic_helper_legacy_gamma_set,
 };
 
 int atmel_hlcdc_crtc_create(struct drm_device *dev)
@@ -485,6 +486,9 @@ int atmel_hlcdc_crtc_create(struct drm_device *dev)
drm_crtc_helper_add(>base, _crtc_helper_funcs);
drm_crtc_vblank_reset(>base);
 
+   drm_mode_crtc_set_gamma_size(>base, ATMEL_HLCDC_CLUT_SIZE);
+   drm_crtc_enable_color_mgmt(>base, 0, false, 
ATMEL_HLCDC_CLUT_SIZE);
+
dc->crtc = >base;
 
return 0;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 30dbffd..6ff771c 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -42,6 +42,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9n12_layers[] = {
.default_color = 3,
.general_config = 4,
},
+   .clut_offset = 0x400,
},
 };
 
@@ -73,6 +74,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x400,
},
{
.name = "overlay1",
@@ -91,6 +93,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0x800,
},
{
.name = "high-end-overlay",
@@ -112,6 +115,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.scaler_config = 13,
.csc = 14,
},
+   .clut_offset = 0x1000,
},
{
.name = "cursor",
@@ -131,6 +135,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9x5_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0x1400,
},
 };
 
@@ -162,6 +167,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x600,
},
{
.name = "overlay1",
@@ -180,6 +186,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0xa00,
},
{
.name = "overlay2",
@@ -198,6 +205,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.chroma_key_mask = 8,
.general_config = 9,
},
+   .clut_offset = 0xe00,
},
{
.name = "high-end-overlay",
@@ -223,6 +231,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
},
.csc = 14,
},
+   .clut_offset = 0x1200,
},
{
.name = "cursor",
@@ -244,6 +253,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d3_layers[] = {
.general_config = 9,
.scaler_config = 13,
},
+   .clut_offset = 0x1600,
},
 };
 
@@ -275,6 +285,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d4_layers[] = {
.disc_pos = 5,
.disc_size = 6,
},
+   .clut_offset = 0x600,
},
{
.name = "overlay1",
@@ -293,6 +304,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d4_layers[] = {

[PATCH v5 1/2] drm: atmel-hlcdc: add missing .set_property helper to the crtc

[Peter Rosin]

The default implementation should be used.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 5348985..cc00ce3 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -429,6 +429,7 @@ static const struct drm_crtc_funcs atmel_hlcdc_crtc_funcs = 
{
.atomic_destroy_state = atmel_hlcdc_crtc_destroy_state,
.enable_vblank = atmel_hlcdc_crtc_enable_vblank,
.disable_vblank = atmel_hlcdc_crtc_disable_vblank,
+   .set_property = drm_atomic_helper_crtc_set_property,
 };
 
 int atmel_hlcdc_crtc_create(struct drm_device *dev)
-- 
2.1.4

Re: [PATCH] iio: adc: Add support for DLN2 ADC

[Peter Meerwald-Stadler]

> This patch adds support for Diolan DLN2 ADC via IIO's ADC interface.
> ADC is the fourth and final component of the DLN2 for the kernel.

comments below

> Signed-off-by: Jack Andersen 
> ---
>  drivers/iio/adc/Kconfig|   9 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/dln2-adc.c | 648 
> +
>  drivers/mfd/dln2.c |  12 +
>  4 files changed, 670 insertions(+)
>  create mode 100644 drivers/iio/adc/dln2-adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 401f47b..78d7455 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -239,6 +239,15 @@ config DA9150_GPADC
> To compile this driver as a module, choose M here: the module will be
> called berlin2-adc.
>  
> +config DLN2_ADC
> + tristate "Diolan DLN-2 ADC driver support"
> + depends on MFD_DLN2
> + help
> +   Say yes here to build support for Diolan DLN-2 ADC.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called adc_dln2.
> +
>  config ENVELOPE_DETECTOR
>   tristate "Envelope detector using a DAC and a comparator"
>   depends on OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 9339bec..378bc65 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
>  obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_CPCAP_ADC) += cpcap-adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> +obj-$(CONFIG_DLN2_ADC) += dln2-adc.o
>  obj-$(CONFIG_ENVELOPE_DETECTOR) += envelope-detector.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
> diff --git a/drivers/iio/adc/dln2-adc.c b/drivers/iio/adc/dln2-adc.c
> new file mode 100644
> index 000..7900e2c
> --- /dev/null
> +++ b/drivers/iio/adc/dln2-adc.c
> @@ -0,0 +1,648 @@
> +/*
> + * Driver for the Diolan DLN-2 USB-ADC adapter
> + *
> + * Copyright (c) 2017 Jack Andersen
> + *
> + * 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, version 2.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

virtio needed?

> +#include 
> +
> +#define DLN2_ADC_MOD_NAME "dln2-adc"
> +
> +#define DLN2_ADC_ID 0x06
> +
> +#define DLN2_ADC_GET_CHANNEL_COUNT   DLN2_CMD(0x01, DLN2_ADC_ID)
> +#define DLN2_ADC_ENABLE  DLN2_CMD(0x02, DLN2_ADC_ID)
> +#define DLN2_ADC_DISABLE DLN2_CMD(0x03, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_ENABLE  DLN2_CMD(0x05, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_DISABLE DLN2_CMD(0x06, DLN2_ADC_ID)
> +#define DLN2_ADC_SET_RESOLUTION  DLN2_CMD(0x08, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_GET_VAL DLN2_CMD(0x0A, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_GET_ALL_VAL DLN2_CMD(0x0B, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_SET_CFG DLN2_CMD(0x0C, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_GET_CFG DLN2_CMD(0x0D, DLN2_ADC_ID)
> +#define DLN2_ADC_CONDITION_MET_EVDLN2_CMD(0x10, DLN2_ADC_ID)
> +
> +#define DLN2_ADC_EVENT_NONE  0
> +#define DLN2_ADC_EVENT_BELOW 1
> +#define DLN2_ADC_EVENT_LEVEL_ABOVE   2
> +#define DLN2_ADC_EVENT_OUTSIDE   3
> +#define DLN2_ADC_EVENT_INSIDE4
> +#define DLN2_ADC_EVENT_ALWAYS5
> +
> +#define DLN2_ADC_MAX_CHANNELS 8
> +#define DLN2_ADC_DATA_BITS 10
> +
> +struct dln2_adc {
> + struct platform_device *pdev;
> + int port;

u8

> + struct iio_trigger *trig;
> + /* Set once initialized */
> + u8 port_enabled;

bool, and use true/false

> + /* Set once resolution request made to HW */
> + u8 resolution_set;

bool

> + /* Bitmask requesting enabled channels */
> + unsigned long chans_requested;
> + /* Bitmask indicating enabled channels on HW */
> + unsigned long chans_enabled;
> + /* Channel that is arbitrated for event trigger */
> + int trigger_chan;
> +};
> +
> +struct dln2_adc_port_chan {
> + u8 port;
> + u8 chan;
> +};
> +
> +struct dln2_adc_get_all_vals {
> + __le16 channel_mask;
> + __le16 values[DLN2_ADC_MAX_CHANNELS];
> +};
> +
> +static int dln2_adc_get_chan_count(struct dln2_adc *dln2)
> +{
> + int ret;
> + u8 port = dln2->port;
> + int ilen = sizeof(port);

save/drop these two temporary variable (here and elsewhere)

> + u8 count;
> + int olen = sizeof(count);
> +
> + ret = dln2_transfer(dln2->pdev, DLN2_ADC_GET_CHANNEL_COUNT,
> + , ilen, , );
> + if (ret < 0) {
> + dev_dbg(>pdev->dev, "Problem in %s\n", __func__);
> + return ret;
> + }
> + if (olen < sizeof(count))
> + 

Re: [PATCH] iio: adc: Add support for DLN2 ADC

[Peter Meerwald-Stadler]

> This patch adds support for Diolan DLN2 ADC via IIO's ADC interface.
> ADC is the fourth and final component of the DLN2 for the kernel.

comments below

> Signed-off-by: Jack Andersen 
> ---
>  drivers/iio/adc/Kconfig|   9 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/dln2-adc.c | 648 
> +
>  drivers/mfd/dln2.c |  12 +
>  4 files changed, 670 insertions(+)
>  create mode 100644 drivers/iio/adc/dln2-adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 401f47b..78d7455 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -239,6 +239,15 @@ config DA9150_GPADC
> To compile this driver as a module, choose M here: the module will be
> called berlin2-adc.
>  
> +config DLN2_ADC
> + tristate "Diolan DLN-2 ADC driver support"
> + depends on MFD_DLN2
> + help
> +   Say yes here to build support for Diolan DLN-2 ADC.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called adc_dln2.
> +
>  config ENVELOPE_DETECTOR
>   tristate "Envelope detector using a DAC and a comparator"
>   depends on OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 9339bec..378bc65 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
>  obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_CPCAP_ADC) += cpcap-adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> +obj-$(CONFIG_DLN2_ADC) += dln2-adc.o
>  obj-$(CONFIG_ENVELOPE_DETECTOR) += envelope-detector.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
> diff --git a/drivers/iio/adc/dln2-adc.c b/drivers/iio/adc/dln2-adc.c
> new file mode 100644
> index 000..7900e2c
> --- /dev/null
> +++ b/drivers/iio/adc/dln2-adc.c
> @@ -0,0 +1,648 @@
> +/*
> + * Driver for the Diolan DLN-2 USB-ADC adapter
> + *
> + * Copyright (c) 2017 Jack Andersen
> + *
> + * 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, version 2.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

virtio needed?

> +#include 
> +
> +#define DLN2_ADC_MOD_NAME "dln2-adc"
> +
> +#define DLN2_ADC_ID 0x06
> +
> +#define DLN2_ADC_GET_CHANNEL_COUNT   DLN2_CMD(0x01, DLN2_ADC_ID)
> +#define DLN2_ADC_ENABLE  DLN2_CMD(0x02, DLN2_ADC_ID)
> +#define DLN2_ADC_DISABLE DLN2_CMD(0x03, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_ENABLE  DLN2_CMD(0x05, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_DISABLE DLN2_CMD(0x06, DLN2_ADC_ID)
> +#define DLN2_ADC_SET_RESOLUTION  DLN2_CMD(0x08, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_GET_VAL DLN2_CMD(0x0A, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_GET_ALL_VAL DLN2_CMD(0x0B, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_SET_CFG DLN2_CMD(0x0C, DLN2_ADC_ID)
> +#define DLN2_ADC_CHANNEL_GET_CFG DLN2_CMD(0x0D, DLN2_ADC_ID)
> +#define DLN2_ADC_CONDITION_MET_EVDLN2_CMD(0x10, DLN2_ADC_ID)
> +
> +#define DLN2_ADC_EVENT_NONE  0
> +#define DLN2_ADC_EVENT_BELOW 1
> +#define DLN2_ADC_EVENT_LEVEL_ABOVE   2
> +#define DLN2_ADC_EVENT_OUTSIDE   3
> +#define DLN2_ADC_EVENT_INSIDE4
> +#define DLN2_ADC_EVENT_ALWAYS5
> +
> +#define DLN2_ADC_MAX_CHANNELS 8
> +#define DLN2_ADC_DATA_BITS 10
> +
> +struct dln2_adc {
> + struct platform_device *pdev;
> + int port;

u8

> + struct iio_trigger *trig;
> + /* Set once initialized */
> + u8 port_enabled;

bool, and use true/false

> + /* Set once resolution request made to HW */
> + u8 resolution_set;

bool

> + /* Bitmask requesting enabled channels */
> + unsigned long chans_requested;
> + /* Bitmask indicating enabled channels on HW */
> + unsigned long chans_enabled;
> + /* Channel that is arbitrated for event trigger */
> + int trigger_chan;
> +};
> +
> +struct dln2_adc_port_chan {
> + u8 port;
> + u8 chan;
> +};
> +
> +struct dln2_adc_get_all_vals {
> + __le16 channel_mask;
> + __le16 values[DLN2_ADC_MAX_CHANNELS];
> +};
> +
> +static int dln2_adc_get_chan_count(struct dln2_adc *dln2)
> +{
> + int ret;
> + u8 port = dln2->port;
> + int ilen = sizeof(port);

save/drop these two temporary variable (here and elsewhere)

> + u8 count;
> + int olen = sizeof(count);
> +
> + ret = dln2_transfer(dln2->pdev, DLN2_ADC_GET_CHANNEL_COUNT,
> + , ilen, , );
> + if (ret < 0) {
> + dev_dbg(>pdev->dev, "Problem in %s\n", __func__);
> + return ret;
> + }
> + if (olen < sizeof(count))
> + return 

Re: [PATCH] radio: wl1273: add check on core->write() return value

[Baruch Siach]

Hi Gustavi,

On Wed, Jun 21, 2017 at 11:01:22PM -0500, Gustavo A. R. Silva wrote:
> Check return value from call to core->write(), so in case of
> error print error message, jump to goto label fail and eventually
> return.
> 
> Addresses-Coverity-ID: 1226943
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/media/radio/radio-wl1273.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/radio/radio-wl1273.c 
> b/drivers/media/radio/radio-wl1273.c
> index 7240223..17e82a9 100644
> --- a/drivers/media/radio/radio-wl1273.c
> +++ b/drivers/media/radio/radio-wl1273.c
> @@ -610,10 +610,21 @@ static int wl1273_fm_start(struct wl1273_device *radio, 
> int new_mode)
>   }
>   }
>  
> - if (radio->rds_on)
> + if (radio->rds_on) {
>   r = core->write(core, WL1273_RDS_DATA_ENB, 1);
> - else
> + if (r) {
> + dev_err(dev, "%s: RDS_DATA_ENB ON fails\n",
> + __func__);
> + goto fail;
> + }
> + } else {
>   r = core->write(core, WL1273_RDS_DATA_ENB, 0);
> + if (r) {
> + dev_err(dev, "%s: RDS_DATA_ENB OFF fails\n",
> + __func__);
> + goto fail;
> + }
> + }
>   } else {
>   dev_warn(dev, "%s: Illegal mode.\n", __func__);
>   }

An alternative that duplicates less code (untested):

r = core->write(core, WL1273_RDS_DATA_ENB, !!radio->rds_on);
if (r) {
dev_err(dev, "%s: RDS_DATA_ENB %s fails\n",
__func__, radio->rds_on ? "ON" : "OFF");
goto fail;
}

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH] radio: wl1273: add check on core->write() return value

[Baruch Siach]

Hi Gustavi,

On Wed, Jun 21, 2017 at 11:01:22PM -0500, Gustavo A. R. Silva wrote:
> Check return value from call to core->write(), so in case of
> error print error message, jump to goto label fail and eventually
> return.
> 
> Addresses-Coverity-ID: 1226943
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/media/radio/radio-wl1273.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/radio/radio-wl1273.c 
> b/drivers/media/radio/radio-wl1273.c
> index 7240223..17e82a9 100644
> --- a/drivers/media/radio/radio-wl1273.c
> +++ b/drivers/media/radio/radio-wl1273.c
> @@ -610,10 +610,21 @@ static int wl1273_fm_start(struct wl1273_device *radio, 
> int new_mode)
>   }
>   }
>  
> - if (radio->rds_on)
> + if (radio->rds_on) {
>   r = core->write(core, WL1273_RDS_DATA_ENB, 1);
> - else
> + if (r) {
> + dev_err(dev, "%s: RDS_DATA_ENB ON fails\n",
> + __func__);
> + goto fail;
> + }
> + } else {
>   r = core->write(core, WL1273_RDS_DATA_ENB, 0);
> + if (r) {
> + dev_err(dev, "%s: RDS_DATA_ENB OFF fails\n",
> + __func__);
> + goto fail;
> + }
> + }
>   } else {
>   dev_warn(dev, "%s: Illegal mode.\n", __func__);
>   }

An alternative that duplicates less code (untested):

r = core->write(core, WL1273_RDS_DATA_ENB, !!radio->rds_on);
if (r) {
dev_err(dev, "%s: RDS_DATA_ENB %s fails\n",
__func__, radio->rds_on ? "ON" : "OFF");
goto fail;
}

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH v6 0/2] IV Generation algorithms for dm-crypt

[Binoy Jayan]

===
dm-crypt optimization for larger block sizes
===

Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move these algorithms from the dm layer to the kernel crypto layer by
implementing them as template ciphers so they can be used in relation with
algorithms like aes, and with multiple modes like cbc, ecb etc. As part of this
patchset, the iv-generation code is moved from the dm layer to the crypto layer
and adapt the dm-layer to send a whole 'bio' (as defined in the block layer)
at a time. Each bio contains the in memory representation of physically
contiguous disk blocks. Since the bio itself may not be contiguous in main
memory, the dm layer sets up a chained scatterlist of these blocks split into
physically contiguous segments in memory so that DMA can be performed.

One challenge in doing so is that the IVs are generated based on a 512-byte
sector number. This infact limits the block sizes to 512 bytes. But this should
not be a problem if a hardware with iv generation support is used. The geniv
itself splits the segments into sectors so it could choose the IV based on
sector number. But it could be modelled in hardware effectively by not
splitting up the segments in the bio.

Another challenge faced is that dm-crypt has an option to use multiple keys.
The key selection is done based on the sector number. If the whole bio is
encrypted / decrypted with the same key, the encrypted volumes will not be
compatible with the original dm-crypt [without the changes]. So, the key
selection code is moved to crypto layer so the neighboring sectors are
encrypted with a different key.

The dm layer allocates space for iv. The hardware drivers can choose to make
use of this space to generate their IVs sequentially or allocate it on their
own. This can be moved to crypto layer too. Postponing this decision until
the requirement to integrate milan's changes are clear.

Interface to the crypto layer - include/crypto/geniv.h

More information on test procedure can be found in v1.
Results of performance tests with software crypto in v5.

The patch 'crypto: Multikey template for essiv' depends on
the following patches by Gilad:
 MAINTAINERS: add Gilad BY as maintainer for ccree
 staging: ccree: add devicetree bindings
 staging: ccree: add TODO list
 staging: add ccree crypto driver

Revisions:
--

v1: https://patchwork.kernel.org/patch/9439175
v2: https://patchwork.kernel.org/patch/9471923
v3: https://lkml.org/lkml/2017/1/18/170
v4: https://patchwork.kernel.org/patch/9559665
v5: https://patchwork.kernel.org/patch/9669237

v5 --> v6:
--

1. Moved allocation of initialization vectors to the iv-generator
2. Few consmetic changes as the consequence of the above
3. Few logical to boolean expressions for faster calculation
4. Included multikey template for splitting keys.
   This needs testing with real hardware (juno with ccree)
   and also modification. It is only for testing and not
   for inclusion upstream.

v4 --> v5
--

1. Fix for the multiple instance issue in /proc/crypto
2. Few cosmetic changes including struct alignment
3. Simplified 'struct geniv_req_info'

v3 --> v4
--
Fix for the bug reported by Gilad Ben-Yossef.
The element '__ctx' in 'struct skcipher_request req' overflowed into the
element 'struct scatterlist src' which immediately follows 'req' in
'struct geniv_subreq' and corrupted src.

v2 --> v3
--

1. Moved iv algorithms in dm-crypt.c for control
2. Key management code moved from dm layer to cryto layer
   so that cipher instance selection can be made depending on key_index
3. The revision v2 had scatterlist nodes created for every sector in the bio.
   It is modified to create only once scatterlist node to reduce memory
   foot print. Synchronous requests are processed sequentially. Asynchronous
   requests are processed in parallel and is freed in the async callback.
4. Changed allocation for sub-requests using mempool

v1 --> v2
--

1. dm-crypt changes to process larger block sizes (one segment in a bio)
2. Incorporated changes w.r.t. comments from Herbert.


Binoy Jayan (2):
  crypto: Add IV generation algorithms
  crypto: Multikey template for essiv

 drivers/md/dm-crypt.c| 1940 +++---
 drivers/staging/ccree/Makefile   |2 +-
 drivers/staging/ccree/essiv.c|  777 +++
 drivers/staging/ccree/essiv_sw.c | 1040 
 include/crypto/geniv.h   |   46 +
 5 files changed, 3251 insertions(+), 554 deletions(-)
 create mode 100644 drivers/staging/ccree/essiv.c
 create mode 100644 drivers/staging/ccree/essiv_sw.c
 create mode 100644 include/crypto/geniv.h

-- 
Binoy Jayan

[PATCH v6 0/2] IV Generation algorithms for dm-crypt

[Binoy Jayan]

===
dm-crypt optimization for larger block sizes
===

Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move these algorithms from the dm layer to the kernel crypto layer by
implementing them as template ciphers so they can be used in relation with
algorithms like aes, and with multiple modes like cbc, ecb etc. As part of this
patchset, the iv-generation code is moved from the dm layer to the crypto layer
and adapt the dm-layer to send a whole 'bio' (as defined in the block layer)
at a time. Each bio contains the in memory representation of physically
contiguous disk blocks. Since the bio itself may not be contiguous in main
memory, the dm layer sets up a chained scatterlist of these blocks split into
physically contiguous segments in memory so that DMA can be performed.

One challenge in doing so is that the IVs are generated based on a 512-byte
sector number. This infact limits the block sizes to 512 bytes. But this should
not be a problem if a hardware with iv generation support is used. The geniv
itself splits the segments into sectors so it could choose the IV based on
sector number. But it could be modelled in hardware effectively by not
splitting up the segments in the bio.

Another challenge faced is that dm-crypt has an option to use multiple keys.
The key selection is done based on the sector number. If the whole bio is
encrypted / decrypted with the same key, the encrypted volumes will not be
compatible with the original dm-crypt [without the changes]. So, the key
selection code is moved to crypto layer so the neighboring sectors are
encrypted with a different key.

The dm layer allocates space for iv. The hardware drivers can choose to make
use of this space to generate their IVs sequentially or allocate it on their
own. This can be moved to crypto layer too. Postponing this decision until
the requirement to integrate milan's changes are clear.

Interface to the crypto layer - include/crypto/geniv.h

More information on test procedure can be found in v1.
Results of performance tests with software crypto in v5.

The patch 'crypto: Multikey template for essiv' depends on
the following patches by Gilad:
 MAINTAINERS: add Gilad BY as maintainer for ccree
 staging: ccree: add devicetree bindings
 staging: ccree: add TODO list
 staging: add ccree crypto driver

Revisions:
--

v1: https://patchwork.kernel.org/patch/9439175
v2: https://patchwork.kernel.org/patch/9471923
v3: https://lkml.org/lkml/2017/1/18/170
v4: https://patchwork.kernel.org/patch/9559665
v5: https://patchwork.kernel.org/patch/9669237

v5 --> v6:
--

1. Moved allocation of initialization vectors to the iv-generator
2. Few consmetic changes as the consequence of the above
3. Few logical to boolean expressions for faster calculation
4. Included multikey template for splitting keys.
   This needs testing with real hardware (juno with ccree)
   and also modification. It is only for testing and not
   for inclusion upstream.

v4 --> v5
--

1. Fix for the multiple instance issue in /proc/crypto
2. Few cosmetic changes including struct alignment
3. Simplified 'struct geniv_req_info'

v3 --> v4
--
Fix for the bug reported by Gilad Ben-Yossef.
The element '__ctx' in 'struct skcipher_request req' overflowed into the
element 'struct scatterlist src' which immediately follows 'req' in
'struct geniv_subreq' and corrupted src.

v2 --> v3
--

1. Moved iv algorithms in dm-crypt.c for control
2. Key management code moved from dm layer to cryto layer
   so that cipher instance selection can be made depending on key_index
3. The revision v2 had scatterlist nodes created for every sector in the bio.
   It is modified to create only once scatterlist node to reduce memory
   foot print. Synchronous requests are processed sequentially. Asynchronous
   requests are processed in parallel and is freed in the async callback.
4. Changed allocation for sub-requests using mempool

v1 --> v2
--

1. dm-crypt changes to process larger block sizes (one segment in a bio)
2. Incorporated changes w.r.t. comments from Herbert.


Binoy Jayan (2):
  crypto: Add IV generation algorithms
  crypto: Multikey template for essiv

 drivers/md/dm-crypt.c| 1940 +++---
 drivers/staging/ccree/Makefile   |2 +-
 drivers/staging/ccree/essiv.c|  777 +++
 drivers/staging/ccree/essiv_sw.c | 1040 
 include/crypto/geniv.h   |   46 +
 5 files changed, 3251 insertions(+), 554 deletions(-)
 create mode 100644 drivers/staging/ccree/essiv.c
 create mode 100644 drivers/staging/ccree/essiv_sw.c
 create mode 100644 include/crypto/geniv.h

-- 
Binoy Jayan

[PATCH v6 1/2] crypto: Add IV generation algorithms

[Binoy Jayan]

Just for reference. Not for merging.

Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be
implemented in hardware for performance. As part of this patchset, the
iv-generation code is moved from the dm layer to the crypto layer and
adapt the dm-layer to send a whole 'bio' (as defined in the block layer)
at a time. Each bio contains an in memory representation of physically
contiguous disk blocks. The dm layer sets up a chained scatterlist of
these blocks split into physically contiguous segments in memory so that
DMA can be performed. Also, the key management code is moved from dm layer
to the cryto layer since the key selection for encrypting neighboring
sectors depend on the keycount.

Synchronous crypto requests to encrypt/decrypt a sector are processed
sequentially. Asynchronous requests if processed in parallel, are freed
in the async callback. The storage space for the initialization vectors
are allocated in the iv generator implementations.

Interface to the crypto layer - include/crypto/geniv.h

Signed-off-by: Binoy Jayan 
---
 drivers/md/dm-crypt.c  | 1939 ++--
 include/crypto/geniv.h |   46 ++
 2 files changed, 1432 insertions(+), 553 deletions(-)
 create mode 100644 include/crypto/geniv.h

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 389a363..bef54f5 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -32,170 +32,120 @@
 #include 
 #include 
 #include 
-
 #include 
-
-#define DM_MSG_PREFIX "crypt"
-
-/*
- * context holding the current state of a multi-part conversion
- */
-struct convert_context {
-   struct completion restart;
-   struct bio *bio_in;
-   struct bio *bio_out;
-   struct bvec_iter iter_in;
-   struct bvec_iter iter_out;
-   sector_t cc_sector;
-   atomic_t cc_pending;
-   struct skcipher_request *req;
+#include 
+#include 
+#include 
+#include 
+
+#define DM_MSG_PREFIX  "crypt"
+#define MAX_SG_LIST(BIO_MAX_PAGES * 8)
+#define MIN_IOS64
+#define LMK_SEED_SIZE  64 /* hash + 0 */
+#define TCW_WHITENING_SIZE 16
+
+struct geniv_ctx;
+struct geniv_req_ctx;
+
+/* Sub request for each of the skcipher_request's for a segment */
+struct geniv_subreq {
+   struct scatterlist src;
+   struct scatterlist dst;
+   struct geniv_req_ctx *rctx;
+   struct skcipher_request req CRYPTO_MINALIGN_ATTR;
 };
 
-/*
- * per bio private data
- */
-struct dm_crypt_io {
-   struct crypt_config *cc;
-   struct bio *base_bio;
-   struct work_struct work;
-
-   struct convert_context ctx;
-
-   atomic_t io_pending;
-   int error;
-   sector_t sector;
-
-   struct rb_node rb_node;
-} CRYPTO_MINALIGN_ATTR;
-
-struct dm_crypt_request {
-   struct convert_context *ctx;
-   struct scatterlist sg_in;
-   struct scatterlist sg_out;
+struct geniv_req_ctx {
+   struct geniv_subreq *subreq;
+   int is_write;
sector_t iv_sector;
+   unsigned int nents;
+   struct completion restart;
+   atomic_t req_pending;
+   struct skcipher_request *req;
 };
 
-struct crypt_config;
-
 struct crypt_iv_operations {
-   int (*ctr)(struct crypt_config *cc, struct dm_target *ti,
-  const char *opts);
-   void (*dtr)(struct crypt_config *cc);
-   int (*init)(struct crypt_config *cc);
-   int (*wipe)(struct crypt_config *cc);
-   int (*generator)(struct crypt_config *cc, u8 *iv,
-struct dm_crypt_request *dmreq);
-   int (*post)(struct crypt_config *cc, u8 *iv,
-   struct dm_crypt_request *dmreq);
+   int (*ctr)(struct geniv_ctx *ctx);
+   void (*dtr)(struct geniv_ctx *ctx);
+   int (*init)(struct geniv_ctx *ctx);
+   int (*wipe)(struct geniv_ctx *ctx);
+   int (*generator)(struct geniv_ctx *ctx,
+struct geniv_req_ctx *rctx,
+struct geniv_subreq *subreq, u8 *iv);
+   int (*post)(struct geniv_ctx *ctx,
+   struct geniv_req_ctx *rctx,
+   struct geniv_subreq *subreq, u8 *iv);
 };
 
-struct iv_essiv_private {
+struct geniv_essiv_private {
struct crypto_ahash *hash_tfm;
u8 *salt;
 };
 
-struct iv_benbi_private {
+struct geniv_benbi_private {
int shift;
 };
 
-#define LMK_SEED_SIZE 64 /* hash + 0 */
-struct iv_lmk_private {
+struct geniv_lmk_private {
struct crypto_shash *hash_tfm;
u8 *seed;
 };
 
-#define TCW_WHITENING_SIZE 16
-struct iv_tcw_private {
+struct geniv_tcw_private {
struct crypto_shash *crc32_tfm;
u8 *iv_seed;
u8 *whitening;
 };
 
-/*
- * Crypt: maps a linear range of a block device
- * and encrypts / decrypts at the same time.
- */
-enum flags { 

[PATCH v6 1/2] crypto: Add IV generation algorithms

[Binoy Jayan]

Just for reference. Not for merging.

Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be
implemented in hardware for performance. As part of this patchset, the
iv-generation code is moved from the dm layer to the crypto layer and
adapt the dm-layer to send a whole 'bio' (as defined in the block layer)
at a time. Each bio contains an in memory representation of physically
contiguous disk blocks. The dm layer sets up a chained scatterlist of
these blocks split into physically contiguous segments in memory so that
DMA can be performed. Also, the key management code is moved from dm layer
to the cryto layer since the key selection for encrypting neighboring
sectors depend on the keycount.

Synchronous crypto requests to encrypt/decrypt a sector are processed
sequentially. Asynchronous requests if processed in parallel, are freed
in the async callback. The storage space for the initialization vectors
are allocated in the iv generator implementations.

Interface to the crypto layer - include/crypto/geniv.h

Signed-off-by: Binoy Jayan 
---
 drivers/md/dm-crypt.c  | 1939 ++--
 include/crypto/geniv.h |   46 ++
 2 files changed, 1432 insertions(+), 553 deletions(-)
 create mode 100644 include/crypto/geniv.h

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 389a363..bef54f5 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -32,170 +32,120 @@
 #include 
 #include 
 #include 
-
 #include 
-
-#define DM_MSG_PREFIX "crypt"
-
-/*
- * context holding the current state of a multi-part conversion
- */
-struct convert_context {
-   struct completion restart;
-   struct bio *bio_in;
-   struct bio *bio_out;
-   struct bvec_iter iter_in;
-   struct bvec_iter iter_out;
-   sector_t cc_sector;
-   atomic_t cc_pending;
-   struct skcipher_request *req;
+#include 
+#include 
+#include 
+#include 
+
+#define DM_MSG_PREFIX  "crypt"
+#define MAX_SG_LIST(BIO_MAX_PAGES * 8)
+#define MIN_IOS64
+#define LMK_SEED_SIZE  64 /* hash + 0 */
+#define TCW_WHITENING_SIZE 16
+
+struct geniv_ctx;
+struct geniv_req_ctx;
+
+/* Sub request for each of the skcipher_request's for a segment */
+struct geniv_subreq {
+   struct scatterlist src;
+   struct scatterlist dst;
+   struct geniv_req_ctx *rctx;
+   struct skcipher_request req CRYPTO_MINALIGN_ATTR;
 };
 
-/*
- * per bio private data
- */
-struct dm_crypt_io {
-   struct crypt_config *cc;
-   struct bio *base_bio;
-   struct work_struct work;
-
-   struct convert_context ctx;
-
-   atomic_t io_pending;
-   int error;
-   sector_t sector;
-
-   struct rb_node rb_node;
-} CRYPTO_MINALIGN_ATTR;
-
-struct dm_crypt_request {
-   struct convert_context *ctx;
-   struct scatterlist sg_in;
-   struct scatterlist sg_out;
+struct geniv_req_ctx {
+   struct geniv_subreq *subreq;
+   int is_write;
sector_t iv_sector;
+   unsigned int nents;
+   struct completion restart;
+   atomic_t req_pending;
+   struct skcipher_request *req;
 };
 
-struct crypt_config;
-
 struct crypt_iv_operations {
-   int (*ctr)(struct crypt_config *cc, struct dm_target *ti,
-  const char *opts);
-   void (*dtr)(struct crypt_config *cc);
-   int (*init)(struct crypt_config *cc);
-   int (*wipe)(struct crypt_config *cc);
-   int (*generator)(struct crypt_config *cc, u8 *iv,
-struct dm_crypt_request *dmreq);
-   int (*post)(struct crypt_config *cc, u8 *iv,
-   struct dm_crypt_request *dmreq);
+   int (*ctr)(struct geniv_ctx *ctx);
+   void (*dtr)(struct geniv_ctx *ctx);
+   int (*init)(struct geniv_ctx *ctx);
+   int (*wipe)(struct geniv_ctx *ctx);
+   int (*generator)(struct geniv_ctx *ctx,
+struct geniv_req_ctx *rctx,
+struct geniv_subreq *subreq, u8 *iv);
+   int (*post)(struct geniv_ctx *ctx,
+   struct geniv_req_ctx *rctx,
+   struct geniv_subreq *subreq, u8 *iv);
 };
 
-struct iv_essiv_private {
+struct geniv_essiv_private {
struct crypto_ahash *hash_tfm;
u8 *salt;
 };
 
-struct iv_benbi_private {
+struct geniv_benbi_private {
int shift;
 };
 
-#define LMK_SEED_SIZE 64 /* hash + 0 */
-struct iv_lmk_private {
+struct geniv_lmk_private {
struct crypto_shash *hash_tfm;
u8 *seed;
 };
 
-#define TCW_WHITENING_SIZE 16
-struct iv_tcw_private {
+struct geniv_tcw_private {
struct crypto_shash *crc32_tfm;
u8 *iv_seed;
u8 *whitening;
 };
 
-/*
- * Crypt: maps a linear range of a block device
- * and encrypts / decrypts at the same time.
- */
-enum flags { DM_CRYPT_SUSPENDED, 

[PATCH v6 2/2] crypto: Multikey template for essiv

[Binoy Jayan]

Just for reference and to get the performance numbers.
Not for merging.

Depends on the following patches by Gilad:
 MAINTAINERS: add Gilad BY as maintainer for ccree
 staging: ccree: add devicetree bindings
 staging: ccree: add TODO list
 staging: add ccree crypto driver

A multi key template implementation which calls the underlying
iv generator 'essiv-aes-du512-dx' cum crypto algorithm. This
template sits on top of the underlying IV generator and accepts
a key length that is a multiple of the underlying key length.
This has not been tested on Juno with the CryptoCell accelerator
for which it was written for.

The underlying IV generator 'essiv-aes-du512-dx' generates IV for
every 512 byte blocks.

Signed-off-by: Binoy Jayan 
---
 drivers/md/dm-crypt.c|5 +-
 drivers/staging/ccree/Makefile   |2 +-
 drivers/staging/ccree/essiv.c|  777 
 drivers/staging/ccree/essiv_sw.c | 1040 ++
 4 files changed, 1821 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/ccree/essiv.c
 create mode 100644 drivers/staging/ccree/essiv_sw.c

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index bef54f5..32f75dd 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -1555,7 +1555,8 @@ static int __init geniv_register_algs(void)
if (err)
goto out_undo_plain;
 
-   err = crypto_register_template(_essiv_tmpl);
+   err = 0;
+   // err = crypto_register_template(_essiv_tmpl);
if (err)
goto out_undo_plain64;
 
@@ -1594,7 +1595,7 @@ static void __exit geniv_deregister_algs(void)
 {
crypto_unregister_template(_plain_tmpl);
crypto_unregister_template(_plain64_tmpl);
-   crypto_unregister_template(_essiv_tmpl);
+   // crypto_unregister_template(_essiv_tmpl);
crypto_unregister_template(_benbi_tmpl);
crypto_unregister_template(_null_tmpl);
crypto_unregister_template(_lmk_tmpl);
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 44f3e3e..524e930 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o essiv.o
 ccree-$(CCREE_FIPS_SUPPORT) += ssi_fips.o ssi_fips_ll.o ssi_fips_ext.o 
ssi_fips_local.o
diff --git a/drivers/staging/ccree/essiv.c b/drivers/staging/ccree/essiv.c
new file mode 100644
index 000..719b8bf
--- /dev/null
+++ b/drivers/staging/ccree/essiv.c
@@ -0,0 +1,777 @@
+/*
+ * Copyright (C) 2003 Jana Saout 
+ * Copyright (C) 2004 Clemens Fruhwirth 
+ * Copyright (C) 2006-2015 Red Hat, Inc. All rights reserved.
+ * Copyright (C) 2013 Milan Broz 
+ *
+ * This file is released under the GPL.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DM_MSG_PREFIX  "crypt"
+#define MAX_SG_LIST(BIO_MAX_PAGES * 8)
+#define MIN_IOS64
+#define LMK_SEED_SIZE  64 /* hash + 0 */
+#define TCW_WHITENING_SIZE 16
+
+struct geniv_ctx;
+struct geniv_req_ctx;
+
+/* Sub request for each of the skcipher_request's for a segment */
+struct geniv_subreq {
+   struct scatterlist src;
+   struct scatterlist dst;
+   struct geniv_req_ctx *rctx;
+   struct skcipher_request req CRYPTO_MINALIGN_ATTR;
+};
+
+struct geniv_req_ctx {
+   struct geniv_subreq *subreq;
+   int is_write;
+   sector_t iv_sector;
+   unsigned int nents;
+   struct completion restart;
+   atomic_t req_pending;
+   struct skcipher_request *req;
+};
+
+struct crypt_iv_operations {
+   int (*ctr)(struct geniv_ctx *ctx);
+   void (*dtr)(struct geniv_ctx *ctx);
+   int (*init)(struct geniv_ctx *ctx);
+   int (*wipe)(struct geniv_ctx *ctx);
+   int (*generator)(struct geniv_ctx *ctx,
+struct geniv_req_ctx *rctx,
+struct geniv_subreq *subreq, u8 *iv);
+   int (*post)(struct geniv_ctx *ctx,
+   struct geniv_req_ctx *rctx,
+   struct geniv_subreq *subreq, u8 *iv);
+};
+
+struct geniv_ctx {
+   unsigned int tfms_count;
+   struct crypto_skcipher *child;
+   struct crypto_skcipher **tfms;
+   char *ivmode;
+   unsigned int iv_size;
+   unsigned int iv_start;

[PATCH v6 2/2] crypto: Multikey template for essiv

[Binoy Jayan]

Just for reference and to get the performance numbers.
Not for merging.

Depends on the following patches by Gilad:
 MAINTAINERS: add Gilad BY as maintainer for ccree
 staging: ccree: add devicetree bindings
 staging: ccree: add TODO list
 staging: add ccree crypto driver

A multi key template implementation which calls the underlying
iv generator 'essiv-aes-du512-dx' cum crypto algorithm. This
template sits on top of the underlying IV generator and accepts
a key length that is a multiple of the underlying key length.
This has not been tested on Juno with the CryptoCell accelerator
for which it was written for.

The underlying IV generator 'essiv-aes-du512-dx' generates IV for
every 512 byte blocks.

Signed-off-by: Binoy Jayan 
---
 drivers/md/dm-crypt.c|5 +-
 drivers/staging/ccree/Makefile   |2 +-
 drivers/staging/ccree/essiv.c|  777 
 drivers/staging/ccree/essiv_sw.c | 1040 ++
 4 files changed, 1821 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/ccree/essiv.c
 create mode 100644 drivers/staging/ccree/essiv_sw.c

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index bef54f5..32f75dd 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -1555,7 +1555,8 @@ static int __init geniv_register_algs(void)
if (err)
goto out_undo_plain;
 
-   err = crypto_register_template(_essiv_tmpl);
+   err = 0;
+   // err = crypto_register_template(_essiv_tmpl);
if (err)
goto out_undo_plain64;
 
@@ -1594,7 +1595,7 @@ static void __exit geniv_deregister_algs(void)
 {
crypto_unregister_template(_plain_tmpl);
crypto_unregister_template(_plain64_tmpl);
-   crypto_unregister_template(_essiv_tmpl);
+   // crypto_unregister_template(_essiv_tmpl);
crypto_unregister_template(_benbi_tmpl);
crypto_unregister_template(_null_tmpl);
crypto_unregister_template(_lmk_tmpl);
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 44f3e3e..524e930 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o essiv.o
 ccree-$(CCREE_FIPS_SUPPORT) += ssi_fips.o ssi_fips_ll.o ssi_fips_ext.o 
ssi_fips_local.o
diff --git a/drivers/staging/ccree/essiv.c b/drivers/staging/ccree/essiv.c
new file mode 100644
index 000..719b8bf
--- /dev/null
+++ b/drivers/staging/ccree/essiv.c
@@ -0,0 +1,777 @@
+/*
+ * Copyright (C) 2003 Jana Saout 
+ * Copyright (C) 2004 Clemens Fruhwirth 
+ * Copyright (C) 2006-2015 Red Hat, Inc. All rights reserved.
+ * Copyright (C) 2013 Milan Broz 
+ *
+ * This file is released under the GPL.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DM_MSG_PREFIX  "crypt"
+#define MAX_SG_LIST(BIO_MAX_PAGES * 8)
+#define MIN_IOS64
+#define LMK_SEED_SIZE  64 /* hash + 0 */
+#define TCW_WHITENING_SIZE 16
+
+struct geniv_ctx;
+struct geniv_req_ctx;
+
+/* Sub request for each of the skcipher_request's for a segment */
+struct geniv_subreq {
+   struct scatterlist src;
+   struct scatterlist dst;
+   struct geniv_req_ctx *rctx;
+   struct skcipher_request req CRYPTO_MINALIGN_ATTR;
+};
+
+struct geniv_req_ctx {
+   struct geniv_subreq *subreq;
+   int is_write;
+   sector_t iv_sector;
+   unsigned int nents;
+   struct completion restart;
+   atomic_t req_pending;
+   struct skcipher_request *req;
+};
+
+struct crypt_iv_operations {
+   int (*ctr)(struct geniv_ctx *ctx);
+   void (*dtr)(struct geniv_ctx *ctx);
+   int (*init)(struct geniv_ctx *ctx);
+   int (*wipe)(struct geniv_ctx *ctx);
+   int (*generator)(struct geniv_ctx *ctx,
+struct geniv_req_ctx *rctx,
+struct geniv_subreq *subreq, u8 *iv);
+   int (*post)(struct geniv_ctx *ctx,
+   struct geniv_req_ctx *rctx,
+   struct geniv_subreq *subreq, u8 *iv);
+};
+
+struct geniv_ctx {
+   unsigned int tfms_count;
+   struct crypto_skcipher *child;
+   struct crypto_skcipher **tfms;
+   char *ivmode;
+   unsigned int iv_size;
+   unsigned int iv_start;
+   char *algname;
+   char *ivopts;
+   char *cipher;
+   char 

Re: [PATCH 32/32] ext4: add nombcache mount option

[Theodore Ts'o]

On Wed, Jun 21, 2017 at 04:46:48PM -0700, Tahsin Erdogan wrote:
> Remount option handling is a bit strange. If an option is not
> specified, it is not automatically cleared in sbi->s_mount_opt. So,
> once nombcache option is set in the original mount, it is not possible
> to clear it. I don't know whether this option handling behavior in
> ext4 is deliberate but because of that, the mount -o remount,ro does
> not result in a mount failure. The check above is effectively only to
> protect against going from not having nombcache option to having
> nombcache option, because the opposite is not possible.

The option handling behavior is deliberate, yes.  This is why we have
the mount options "lazytime" and "nolazytime", "discard" and
"nodiscard", "barrier" and "nobarrier", etc.

 -Ted

Re: [PATCH 32/32] ext4: add nombcache mount option

[Theodore Ts'o]

On Wed, Jun 21, 2017 at 04:46:48PM -0700, Tahsin Erdogan wrote:
> Remount option handling is a bit strange. If an option is not
> specified, it is not automatically cleared in sbi->s_mount_opt. So,
> once nombcache option is set in the original mount, it is not possible
> to clear it. I don't know whether this option handling behavior in
> ext4 is deliberate but because of that, the mount -o remount,ro does
> not result in a mount failure. The check above is effectively only to
> protect against going from not having nombcache option to having
> nombcache option, because the opposite is not possible.

The option handling behavior is deliberate, yes.  This is why we have
the mount options "lazytime" and "nolazytime", "discard" and
"nodiscard", "barrier" and "nobarrier", etc.

 -Ted

Re: [PATCH V4 2/2] powerpc/powernv : Add support for OPAL-OCC command/response interface

[Shilpasri G Bhat]

Hi Cyril,

On 06/22/2017 06:28 AM, Cyril Bur wrote:
> On Wed, 2017-06-21 at 13:36 +0530, Shilpasri G Bhat wrote:
>> In P9, OCC (On-Chip-Controller) supports shared memory based
>> commad-response interface. Within the shared memory there is an OPAL
>> command buffer and OCC response buffer that can be used to send
>> inband commands to OCC. This patch adds a platform driver to support
>> the command/response interface between OCC and the host.
>>
> 
> Sorry I probably should have pointed out earlier that I don't really
> understand the first patch or exactly what problem you're trying to
> solve. I've left it ignored, feel free to explain what the idea is
> there or hopefully someone who can see what you're trying to do can
> step in.

Thanks for reviewing this patch.

For the first patch however, OCC expects a different request_id in the command
interface every time OPAL is requesting a new command .
'opal_async_get_token_interruptible()' returns a free token from the
'opal_async_complete_map' which does not work for the above OCC requirement as
we may end up getting the same token. Thus the first patch tries to get a new
token excluding a token that was used for the last command.


> 
> As for this patch, just one thing.
> 
> 
>> Signed-off-by: Shilpasri G Bhat 
>> ---
>> - Hold occ->cmd_in_progress in read()
>> - Reset occ->rsp_consumed if copy_to_user() fails
>>
>>  arch/powerpc/include/asm/opal-api.h|  41 +++-
>>  arch/powerpc/include/asm/opal.h|   3 +
>>  arch/powerpc/platforms/powernv/Makefile|   2 +-
>>  arch/powerpc/platforms/powernv/opal-occ.c  | 313 
>> +
>>  arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
>>  arch/powerpc/platforms/powernv/opal.c  |   8 +
>>  6 files changed, 366 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c
>>
> 
> [snip]
> 
>> +
>> +static ssize_t opal_occ_read(struct file *file, char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> +struct miscdevice *dev = file->private_data;
>> +struct occ *occ = container_of(dev, struct occ, dev);
>> +int rc;
>> +
>> +if (count < sizeof(*occ->rsp) + occ->rsp->size)
>> +return -EINVAL;
>> +
>> +if (!atomic_cmpxchg(>rsp_consumed, 1, 0))
>> +return -EBUSY;
>> +
>> +if (atomic_cmpxchg(>cmd_in_progress, 0, 1))
>> +return -EBUSY;
>> +
> 
> Personally I would have done these two checks the other way around, it
> doesn't really matter which one you do first but what does matter is
> that you undo the change you did in the first cmpxchg if the second
> cmpxchg causes you do return.
> 
> In this case if cmd_in_progress then you'll have marked the response as
> consumed...

Here, if cmd_in_progress is set by some other thread doing a write() then it
will set the 'rsp_consumed' to valid on successful command completion. If
write() fails then we are doing a good thing here by not setting 'rsp_consumed'
so the user will not be able to read previous command's response.

Thanks and Regards,
Shilpa

> 
>> +rc = copy_to_user((void __user *)buf, occ->rsp,
>> +  sizeof(occ->rsp) + occ->rsp->size);
>> +if (rc) {
>> +atomic_set(>rsp_consumed, 1);
>> +atomic_set(>cmd_in_progress, 0);
>> +pr_err("Failed to copy OCC response data to user\n");
>> +return rc;
>> +}
>> +
>> +atomic_set(>cmd_in_progress, 0);
>> +return sizeof(*occ->rsp) + occ->rsp->size;
>> +}
>> +
> 
> [snip]
> 

Re: [PATCH V4 2/2] powerpc/powernv : Add support for OPAL-OCC command/response interface

[Shilpasri G Bhat]

Hi Cyril,

On 06/22/2017 06:28 AM, Cyril Bur wrote:
> On Wed, 2017-06-21 at 13:36 +0530, Shilpasri G Bhat wrote:
>> In P9, OCC (On-Chip-Controller) supports shared memory based
>> commad-response interface. Within the shared memory there is an OPAL
>> command buffer and OCC response buffer that can be used to send
>> inband commands to OCC. This patch adds a platform driver to support
>> the command/response interface between OCC and the host.
>>
> 
> Sorry I probably should have pointed out earlier that I don't really
> understand the first patch or exactly what problem you're trying to
> solve. I've left it ignored, feel free to explain what the idea is
> there or hopefully someone who can see what you're trying to do can
> step in.

Thanks for reviewing this patch.

For the first patch however, OCC expects a different request_id in the command
interface every time OPAL is requesting a new command .
'opal_async_get_token_interruptible()' returns a free token from the
'opal_async_complete_map' which does not work for the above OCC requirement as
we may end up getting the same token. Thus the first patch tries to get a new
token excluding a token that was used for the last command.


> 
> As for this patch, just one thing.
> 
> 
>> Signed-off-by: Shilpasri G Bhat 
>> ---
>> - Hold occ->cmd_in_progress in read()
>> - Reset occ->rsp_consumed if copy_to_user() fails
>>
>>  arch/powerpc/include/asm/opal-api.h|  41 +++-
>>  arch/powerpc/include/asm/opal.h|   3 +
>>  arch/powerpc/platforms/powernv/Makefile|   2 +-
>>  arch/powerpc/platforms/powernv/opal-occ.c  | 313 
>> +
>>  arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
>>  arch/powerpc/platforms/powernv/opal.c  |   8 +
>>  6 files changed, 366 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c
>>
> 
> [snip]
> 
>> +
>> +static ssize_t opal_occ_read(struct file *file, char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> +struct miscdevice *dev = file->private_data;
>> +struct occ *occ = container_of(dev, struct occ, dev);
>> +int rc;
>> +
>> +if (count < sizeof(*occ->rsp) + occ->rsp->size)
>> +return -EINVAL;
>> +
>> +if (!atomic_cmpxchg(>rsp_consumed, 1, 0))
>> +return -EBUSY;
>> +
>> +if (atomic_cmpxchg(>cmd_in_progress, 0, 1))
>> +return -EBUSY;
>> +
> 
> Personally I would have done these two checks the other way around, it
> doesn't really matter which one you do first but what does matter is
> that you undo the change you did in the first cmpxchg if the second
> cmpxchg causes you do return.
> 
> In this case if cmd_in_progress then you'll have marked the response as
> consumed...

Here, if cmd_in_progress is set by some other thread doing a write() then it
will set the 'rsp_consumed' to valid on successful command completion. If
write() fails then we are doing a good thing here by not setting 'rsp_consumed'
so the user will not be able to read previous command's response.

Thanks and Regards,
Shilpa

> 
>> +rc = copy_to_user((void __user *)buf, occ->rsp,
>> +  sizeof(occ->rsp) + occ->rsp->size);
>> +if (rc) {
>> +atomic_set(>rsp_consumed, 1);
>> +atomic_set(>cmd_in_progress, 0);
>> +pr_err("Failed to copy OCC response data to user\n");
>> +return rc;
>> +}
>> +
>> +atomic_set(>cmd_in_progress, 0);
>> +return sizeof(*occ->rsp) + occ->rsp->size;
>> +}
>> +
> 
> [snip]
> 

Re: [lkp-robot] [mm] 1be7107fbe: kernel_BUG_at_mm/mmap.c

[Hugh Dickins]

On Wed, 21 Jun 2017, Oleg Nesterov wrote:
> On 06/21, Linus Torvalds wrote:
> >
> > Hugh, Michal - I also merged Helge's drop-up cleanup, is there
> > anything I've missed? I think Oleg had something, but I can't recall
> > right now, and I might just have missed it.
> 
> Well, I meant, perhaps we need a bit more changes to ensure that a new
> GROWSDOWN vma can't come without a gap below. But this is really minor,
> we can do this later even if I am right.

I'm mortified.  At last I understand you, and see that you spelt it out
perfectly clearly in your "unmapped_gap" mail earlier in another thread,
when I was in a rush to prioritize what bugs needed looking at first,
and brusquely persuaded you to say that this is only a minor defect.

Well, yes, it's not a new vulnerability and it's not a new regression,
and the users of MAP_GROWSDOWN are few and far between, and often the
assignment of holes will work out just fine; but it's an embarrassing
oversight on my part, that everything was geared to inflating the
size of the existing VM_GROWS vmas, completely forgetting to inflate
the size of the area to be added.

Without reading you thoroughly (and all the fault mine not yours),
I had thought you were referring to the way that a MAP_GROWSDOWN
area may be assigned a place in which the stack_guard_gap would
immediately prevent it from growing down afterwards (and I'm not
sure what to do about that).  But your point is that it may be
assigned a place in which there is not even a stack_guard_gap
below it.  (And so the bug that trinity found would not even
depend upon MAP_FIXED.)

I'll go back to read you again and think on the best way to
correct that, I hope it won't need lots of plumbing through
different levels.

Hugh

Re: [lkp-robot] [mm] 1be7107fbe: kernel_BUG_at_mm/mmap.c

[Hugh Dickins]

On Wed, 21 Jun 2017, Oleg Nesterov wrote:
> On 06/21, Linus Torvalds wrote:
> >
> > Hugh, Michal - I also merged Helge's drop-up cleanup, is there
> > anything I've missed? I think Oleg had something, but I can't recall
> > right now, and I might just have missed it.
> 
> Well, I meant, perhaps we need a bit more changes to ensure that a new
> GROWSDOWN vma can't come without a gap below. But this is really minor,
> we can do this later even if I am right.

I'm mortified.  At last I understand you, and see that you spelt it out
perfectly clearly in your "unmapped_gap" mail earlier in another thread,
when I was in a rush to prioritize what bugs needed looking at first,
and brusquely persuaded you to say that this is only a minor defect.

Well, yes, it's not a new vulnerability and it's not a new regression,
and the users of MAP_GROWSDOWN are few and far between, and often the
assignment of holes will work out just fine; but it's an embarrassing
oversight on my part, that everything was geared to inflating the
size of the existing VM_GROWS vmas, completely forgetting to inflate
the size of the area to be added.

Without reading you thoroughly (and all the fault mine not yours),
I had thought you were referring to the way that a MAP_GROWSDOWN
area may be assigned a place in which the stack_guard_gap would
immediately prevent it from growing down afterwards (and I'm not
sure what to do about that).  But your point is that it may be
assigned a place in which there is not even a stack_guard_gap
below it.  (And so the bug that trinity found would not even
depend upon MAP_FIXED.)

I'll go back to read you again and think on the best way to
correct that, I hope it won't need lots of plumbing through
different levels.

Hugh

[PATCH] dvb-usb-v2: lmedm04: remove unnecessary variable in lme2510_stream_restart()

[Gustavo A. R. Silva]

Remove unnecessary variable _ret_ and refactor the code.

Addresses-Coverity-ID: 1226934
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/usb/dvb-usb-v2/lmedm04.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c 
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 594360a..a91fdad 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -207,15 +207,13 @@ static int lme2510_stream_restart(struct dvb_usb_device 
*d)
struct lme2510_state *st = d->priv;
u8 all_pids[] = LME_ALL_PIDS;
u8 stream_on[] = LME_ST_ON_W;
-   int ret;
u8 rbuff[1];
if (st->pid_off)
-   ret = lme2510_usb_talk(d, all_pids, sizeof(all_pids),
-   rbuff, sizeof(rbuff));
+   lme2510_usb_talk(d, all_pids, sizeof(all_pids),
+rbuff, sizeof(rbuff));
/*Restart Stream Command*/
-   ret = lme2510_usb_talk(d, stream_on, sizeof(stream_on),
-   rbuff, sizeof(rbuff));
-   return ret;
+   return lme2510_usb_talk(d, stream_on, sizeof(stream_on),
+   rbuff, sizeof(rbuff));
 }
 
 static int lme2510_enable_pid(struct dvb_usb_device *d, u8 index, u16 pid_out)
-- 
2.5.0

[PATCH] dvb-usb-v2: lmedm04: remove unnecessary variable in lme2510_stream_restart()

[Gustavo A. R. Silva]

Remove unnecessary variable _ret_ and refactor the code.

Addresses-Coverity-ID: 1226934
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/usb/dvb-usb-v2/lmedm04.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c 
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 594360a..a91fdad 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -207,15 +207,13 @@ static int lme2510_stream_restart(struct dvb_usb_device 
*d)
struct lme2510_state *st = d->priv;
u8 all_pids[] = LME_ALL_PIDS;
u8 stream_on[] = LME_ST_ON_W;
-   int ret;
u8 rbuff[1];
if (st->pid_off)
-   ret = lme2510_usb_talk(d, all_pids, sizeof(all_pids),
-   rbuff, sizeof(rbuff));
+   lme2510_usb_talk(d, all_pids, sizeof(all_pids),
+rbuff, sizeof(rbuff));
/*Restart Stream Command*/
-   ret = lme2510_usb_talk(d, stream_on, sizeof(stream_on),
-   rbuff, sizeof(rbuff));
-   return ret;
+   return lme2510_usb_talk(d, stream_on, sizeof(stream_on),
+   rbuff, sizeof(rbuff));
 }
 
 static int lme2510_enable_pid(struct dvb_usb_device *d, u8 index, u16 pid_out)
-- 
2.5.0

[PATCH] docs/memory-hotplug: adjust the explanation of valid_zones sysfs

[Wei Yang]

After commit "mm, memory_hotplug: do not associate hotadded memory to zones
until online", the meaning of valid_zones is changed.

1. When the memory block is online, it returns the onlined zone name
2. We won't have "Movable Normal" case, because default_zone couldn't be
MOVABLE

This patch adjust the document according the code change.

Signed-off-by: Wei Yang 
---
 Documentation/memory-hotplug.txt | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 670f3ded0802..d85ceb53f52a 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -171,15 +171,15 @@ Under each memory block, you can see 5 files:
 block is removable and a value of 0 indicates that
 it is not removable. A memory block is removable only if
 every section in the block is removable.
-'valid_zones' : read-only: designed to show which zones this memory block
-   can be onlined to.
-   The first column shows it's default zone.
+'valid_zones' : read-only: shows different information based on state.
+   When state is online, it is designed to show the
+   zone name this memory block is onlined to.
+   When state is offline, it is designed to show which zones
+   this memory block can be onlined to.  The first column
+   shows it's default zone.
"memory6/valid_zones: Normal Movable" shows this memoryblock
can be onlined to ZONE_NORMAL by default and to ZONE_MOVABLE
by online_movable.
-   "memory7/valid_zones: Movable Normal" shows this memoryblock
-   can be onlined to ZONE_MOVABLE by default and to ZONE_NORMAL
-   by online_kernel.
 
 NOTE:
   These directories/files appear after physical memory hotplug phase.
-- 
2.11.0

[PATCH] docs/memory-hotplug: adjust the explanation of valid_zones sysfs

[Wei Yang]

After commit "mm, memory_hotplug: do not associate hotadded memory to zones
until online", the meaning of valid_zones is changed.

1. When the memory block is online, it returns the onlined zone name
2. We won't have "Movable Normal" case, because default_zone couldn't be
MOVABLE

This patch adjust the document according the code change.

Signed-off-by: Wei Yang 
---
 Documentation/memory-hotplug.txt | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 670f3ded0802..d85ceb53f52a 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -171,15 +171,15 @@ Under each memory block, you can see 5 files:
 block is removable and a value of 0 indicates that
 it is not removable. A memory block is removable only if
 every section in the block is removable.
-'valid_zones' : read-only: designed to show which zones this memory block
-   can be onlined to.
-   The first column shows it's default zone.
+'valid_zones' : read-only: shows different information based on state.
+   When state is online, it is designed to show the
+   zone name this memory block is onlined to.
+   When state is offline, it is designed to show which zones
+   this memory block can be onlined to.  The first column
+   shows it's default zone.
"memory6/valid_zones: Normal Movable" shows this memoryblock
can be onlined to ZONE_NORMAL by default and to ZONE_MOVABLE
by online_movable.
-   "memory7/valid_zones: Movable Normal" shows this memoryblock
-   can be onlined to ZONE_MOVABLE by default and to ZONE_NORMAL
-   by online_kernel.
 
 NOTE:
   These directories/files appear after physical memory hotplug phase.
-- 
2.11.0

[PATCH 5/6] ARM: sun8i: a83t: Add device node for AXP813 PMIC

[Chen-Yu Tsai]

The AXP813/AXP818 PMICs used with the A83T/H8 SoCs are actually 2 dies
in one package sharing the serial bus (I2C/RSB) pins. One die is the
actual PMIC. The other is an AC100 codec / RTC combo chip.

This patch adds a device node for the PMIC die.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts 
b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
index cff33454fc24..027602ce03d1 100644
--- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
@@ -102,6 +102,17 @@
};
 };
 
+_rsb {
+   status = "okay";
+
+   axp813: pmic@3a3 {
+   compatible = "x-powers,axp813";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.11.0

[PATCH 5/6] ARM: sun8i: a83t: Add device node for AXP813 PMIC

[Chen-Yu Tsai]

The AXP813/AXP818 PMICs used with the A83T/H8 SoCs are actually 2 dies
in one package sharing the serial bus (I2C/RSB) pins. One die is the
actual PMIC. The other is an AC100 codec / RTC combo chip.

This patch adds a device node for the PMIC die.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts 
b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
index cff33454fc24..027602ce03d1 100644
--- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
@@ -102,6 +102,17 @@
};
 };
 
+_rsb {
+   status = "okay";
+
+   axp813: pmic@3a3 {
+   compatible = "x-powers,axp813";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.11.0

[PATCH 0/6] mfd: axp20x: Add basic support for AXP813

[Chen-Yu Tsai]

Hi everyone,

This series adds basic device tree bindings and driver support for the
AXP813/818 PMICs. The two models are identical when comparing their
datasheets. These PMICs are actually two dies in one package: one being
the actual PMIC, the other being an AC100 codec/RTC combo chip. The
latter has its own device tree binding.

This series only adds the basic parts of the device tree binding and
driver. For the bindings, only the core and regulator bits are added.
Any sub-devices that have their own binding will be updated later on.
For the driver, only the mfd part with a basic power button (PEK) cell
is added, along with regulator IDs. I hope that this part can be merged
for 4.13, so I can work on the regulators for 4.14, and we won't have
any cross tree compile time dependencies.

The device tree changes depend on my R_INTC patches I sent earlier,
which are waiting on irqchip driver changes to be merged first.

To recap, I hope the mfd bits can be merged for 4.13, while the device
tree stuff will have to wait for 4.14.

Patch 1 adds AXP806 to the main list of supported chips, which was
missing.

Patch 2 adds bindings for the AXP813.

Patch 3 adds basic mfd driver support with PEK enabled for AXP813.

Patch 4 adds the device node and pinmux settings for the RSB controller
on the A83T. This is used to communicate with the PMIC.

Patch 5 adds a device node for the PMIC part of the chip.

Patch 6 adds a device node for the embedded AC100 part of the chip.


Regards
ChenYu


Chen-Yu Tsai (6):
  dt-bindings: mfd: axp20x: Add AXP806 to supported list of chips
  dt-bindings: mfd: axp20x: Introduce bindings for AXP813
  mfd: axp20x: Add support for AXP813 PMIC
  ARM: sun8i: a83t: Add device node and pinmux setting for RSB
controller
  ARM: sun8i: a83t: Add device node for AXP813 PMIC
  ARM: sun8i: a83t: Enable AC100 codec / RTC combo chip in AXP813 PMIC

 Documentation/devicetree/bindings/mfd/axp20x.txt | 50 +---
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 35 +
 arch/arm/boot/dts/sun8i-a83t.dtsi| 22 +++
 drivers/mfd/axp20x-rsb.c |  1 +
 drivers/mfd/axp20x.c | 22 +++
 include/linux/mfd/axp20x.h   | 29 ++
 6 files changed, 154 insertions(+), 5 deletions(-)

-- 
2.11.0

[PATCH 0/6] mfd: axp20x: Add basic support for AXP813

[Chen-Yu Tsai]

Hi everyone,

This series adds basic device tree bindings and driver support for the
AXP813/818 PMICs. The two models are identical when comparing their
datasheets. These PMICs are actually two dies in one package: one being
the actual PMIC, the other being an AC100 codec/RTC combo chip. The
latter has its own device tree binding.

This series only adds the basic parts of the device tree binding and
driver. For the bindings, only the core and regulator bits are added.
Any sub-devices that have their own binding will be updated later on.
For the driver, only the mfd part with a basic power button (PEK) cell
is added, along with regulator IDs. I hope that this part can be merged
for 4.13, so I can work on the regulators for 4.14, and we won't have
any cross tree compile time dependencies.

The device tree changes depend on my R_INTC patches I sent earlier,
which are waiting on irqchip driver changes to be merged first.

To recap, I hope the mfd bits can be merged for 4.13, while the device
tree stuff will have to wait for 4.14.

Patch 1 adds AXP806 to the main list of supported chips, which was
missing.

Patch 2 adds bindings for the AXP813.

Patch 3 adds basic mfd driver support with PEK enabled for AXP813.

Patch 4 adds the device node and pinmux settings for the RSB controller
on the A83T. This is used to communicate with the PMIC.

Patch 5 adds a device node for the PMIC part of the chip.

Patch 6 adds a device node for the embedded AC100 part of the chip.


Regards
ChenYu


Chen-Yu Tsai (6):
  dt-bindings: mfd: axp20x: Add AXP806 to supported list of chips
  dt-bindings: mfd: axp20x: Introduce bindings for AXP813
  mfd: axp20x: Add support for AXP813 PMIC
  ARM: sun8i: a83t: Add device node and pinmux setting for RSB
controller
  ARM: sun8i: a83t: Add device node for AXP813 PMIC
  ARM: sun8i: a83t: Enable AC100 codec / RTC combo chip in AXP813 PMIC

 Documentation/devicetree/bindings/mfd/axp20x.txt | 50 +---
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 35 +
 arch/arm/boot/dts/sun8i-a83t.dtsi| 22 +++
 drivers/mfd/axp20x-rsb.c |  1 +
 drivers/mfd/axp20x.c | 22 +++
 include/linux/mfd/axp20x.h   | 29 ++
 6 files changed, 154 insertions(+), 5 deletions(-)

-- 
2.11.0

[PATCH 4/6] ARM: sun8i: a83t: Add device node and pinmux setting for RSB controller

[Chen-Yu Tsai]

The A83T has an RSB controller for talking to the PMIC and audio codec.
Add a device node for it. Since there is only one usable pinmux setting,
for it, add that as well.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 21439d0aa55d..420b1484e17d 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -45,6 +45,7 @@
 #include 
 
 #include 
+#include 
 
 / {
interrupt-parent = <>;
@@ -309,6 +310,27 @@
#gpio-cells = <3>;
interrupt-controller;
#interrupt-cells = <3>;
+
+   r_rsb_pins: r-rsb-pins {
+   pins = "PL0", "PL1";
+   function = "s_rsb";
+   drive-strength = <20>;
+   bias-pull-up;
+   };
+   };
+
+   r_rsb: rsb@1f03400 {
+   compatible = "allwinner,sun8i-a23-rsb";
+   reg = <0x01f03400 0x400>;
+   interrupts = ;
+   clocks = <_ccu CLK_APB0_RSB>;
+   clock-frequency = <300>;
+   resets = <_ccu RST_APB0_RSB>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rsb_pins>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
};
};
 };
-- 
2.11.0

[PATCH 4/6] ARM: sun8i: a83t: Add device node and pinmux setting for RSB controller

[Chen-Yu Tsai]

The A83T has an RSB controller for talking to the PMIC and audio codec.
Add a device node for it. Since there is only one usable pinmux setting,
for it, add that as well.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 21439d0aa55d..420b1484e17d 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -45,6 +45,7 @@
 #include 
 
 #include 
+#include 
 
 / {
interrupt-parent = <>;
@@ -309,6 +310,27 @@
#gpio-cells = <3>;
interrupt-controller;
#interrupt-cells = <3>;
+
+   r_rsb_pins: r-rsb-pins {
+   pins = "PL0", "PL1";
+   function = "s_rsb";
+   drive-strength = <20>;
+   bias-pull-up;
+   };
+   };
+
+   r_rsb: rsb@1f03400 {
+   compatible = "allwinner,sun8i-a23-rsb";
+   reg = <0x01f03400 0x400>;
+   interrupts = ;
+   clocks = <_ccu CLK_APB0_RSB>;
+   clock-frequency = <300>;
+   resets = <_ccu RST_APB0_RSB>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rsb_pins>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
};
};
 };
-- 
2.11.0

[PATCH 3/6] mfd: axp20x: Add support for AXP813 PMIC

[Chen-Yu Tsai]

The X-Powers AXP813 PMIC is normally used with Allwinner's A83T SoC.
It has the same range of functions as other X-Powers PMICs, such as
DC-DC buck converter and linear regulator outputs, AC-IN and VBUS
power supplies, power button trigger, GPIOs, ADCs, and a battery
charger.

Note that the IRQ table given in the datasheet is incorrect: in IRQ
enable/status registers 1, there are separate IRQs for ACIN and VBUS,
instead of bits [7:5] being the same as bits [4:2]. So it shares the
same IRQs as the AXP803, rather than the AXP288.

This patch adds basic mfd support for it, with only the power button
enabled.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/mfd/axp20x-rsb.c   |  1 +
 drivers/mfd/axp20x.c   | 22 ++
 include/linux/mfd/axp20x.h | 29 +
 3 files changed, 52 insertions(+)

diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index fd5c7267b136..7ddbd9e8dd03 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -64,6 +64,7 @@ static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
{ .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
+   { .compatible = "x-powers,axp813", .data = (void *)AXP813_ID },
{ },
 };
 MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 917b6ddc4f15..ec4271ca065c 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -44,6 +44,7 @@ static const char * const axp20x_model_names[] = {
"AXP803",
"AXP806",
"AXP809",
+   "AXP813",
 };
 
 static const struct regmap_range axp152_writeable_ranges[] = {
@@ -870,6 +871,14 @@ static struct mfd_cell axp809_cells[] = {
},
 };
 
+static struct mfd_cell axp813_cells[] = {
+   {
+   .name   = "axp20x-pek",
+   .num_resources  = ARRAY_SIZE(axp803_pek_resources),
+   .resources  = axp803_pek_resources,
+   }
+};
+
 static struct axp20x_dev *axp20x_pm_power_off;
 static void axp20x_power_off(void)
 {
@@ -956,6 +965,19 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_cfg = _regmap_config;
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
+   case AXP813_ID:
+   axp20x->nr_cells = ARRAY_SIZE(axp813_cells);
+   axp20x->cells = axp813_cells;
+   axp20x->regmap_cfg = _regmap_config;
+   /*
+* The IRQ table given in the datasheet is incorrect.
+* In IRQ enable/status registers 1, there are separate
+* IRQs for ACIN and VBUS, instead of bits [7:5] being
+* the same as bits [4:2]. So it shares the same IRQs
+* as the AXP803, rather than the AXP288.
+*/
+   axp20x->regmap_irq_chip = _regmap_irq_chip;
+   break;
default:
dev_err(dev, "unsupported AXP20X ID %lu\n", axp20x->variant);
return -EINVAL;
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 965b027e31b3..e9c908c4fba8 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -23,6 +23,7 @@ enum axp20x_variants {
AXP803_ID,
AXP806_ID,
AXP809_ID,
+   AXP813_ID,
NR_AXP20X_VARIANTS,
 };
 
@@ -387,6 +388,34 @@ enum {
AXP803_REG_ID_MAX,
 };
 
+enum {
+   AXP813_DCDC1 = 0,
+   AXP813_DCDC2,
+   AXP813_DCDC3,
+   AXP813_DCDC4,
+   AXP813_DCDC5,
+   AXP813_DCDC6,
+   AXP813_DCDC7,
+   AXP813_ALDO1,
+   AXP813_ALDO2,
+   AXP813_ALDO3,
+   AXP813_DLDO1,
+   AXP813_DLDO2,
+   AXP813_DLDO3,
+   AXP813_DLDO4,
+   AXP813_ELDO1,
+   AXP813_ELDO2,
+   AXP813_ELDO3,
+   AXP813_FLDO1,
+   AXP813_FLDO2,
+   AXP813_FLDO3,
+   AXP813_RTC_LDO,
+   AXP813_LDO_IO0,
+   AXP813_LDO_IO1,
+   AXP813_SW,
+   AXP813_REG_ID_MAX,
+};
+
 /* IRQs */
 enum {
AXP152_IRQ_LDO0IN_CONNECT = 1,
-- 
2.11.0

[PATCH 2/6] dt-bindings: mfd: axp20x: Introduce bindings for AXP813

[Chen-Yu Tsai]

The X-Powers AXP813 is a PMIC designed to be paired with Allwinner's
A83T SoC. There is also an AXP818, which is paired with the H8 SoC.

The two models seem to be identical, apart from the external markings.

This patch introduces the basic mfd and regulator bindings for the
AXP813.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 49 +---
 1 file changed, 44 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 211a100c6b20..1dff7e2ec375 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -9,6 +9,12 @@ axp223 (X-Powers)
 axp803 (X-Powers)
 axp806 (X-Powers)
 axp809 (X-Powers)
+axp813 (X-Powers)
+
+The AXP813 is 2 chips packaged into 1. The 2 chips do not share anything
+other than the packaging. Pins are routed separately. As such they should
+be treated as separate entities. The other half is an AC100 RTC/codec
+combo chip. Please see ac100.txt for its bindings.
 
 Required properties:
 - compatible: should be one of:
@@ -20,6 +26,7 @@ Required properties:
 * "x-powers,axp803"
 * "x-powers,axp806"
 * "x-powers,axp809"
+* "x-powers,axp813"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -29,12 +36,14 @@ Required properties:
 Optional properties:
 - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
  AXP152/20X: range:  750-1875, Default: 1.5 MHz
- AXP22X/80X: range: 1800-4050, Default: 3   MHz
+ AXP22X/8XX: range: 1800-4050, Default: 3   MHz
 
-- x-powers,drive-vbus-en: axp221 / axp223 only boolean, set this when the
- N_VBUSEN pin is used as an output pin to control an external
- regulator to drive the OTG VBus, rather then as an input pin
- which signals whether the board is driving OTG VBus or not.
+- x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
+ used as an output pin to control an external
+ regulator to drive the OTG VBus, rather then
+ as an input pin which signals whether the
+ board is driving OTG VBus or not.
+ (axp221 / axp223 / axp813 only)
 
 - x-powers,master-mode: Boolean (axp806 only). Set this when the PMIC is
wired for master mode. The default is slave mode.
@@ -172,6 +181,36 @@ LDO_IO1: LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 SW : On/Off Switch : swin-supply
 
+AXP813 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDC1  : DC-DC buck: vin1-supply
+DCDC2  : DC-DC buck: vin2-supply   : poly-phase capable
+DCDC3  : DC-DC buck: vin3-supply   : poly-phase capable
+DCDC4  : DC-DC buck: vin4-supply
+DCDC5  : DC-DC buck: vin5-supply   : poly-phase capable
+DCDC6  : DC-DC buck: vin6-supply   : poly-phase capable
+DCDC7  : DC-DC buck: vin7-supply
+ALDO1  : LDO   : aldoin-supply : shared supply
+ALDO2  : LDO   : aldoin-supply : shared supply
+ALDO3  : LDO   : aldoin-supply : shared supply
+DLDO1  : LDO   : dldoin-supply : shared supply
+DLDO2  : LDO   : dldoin-supply : shared supply
+DLDO3  : LDO   : dldoin-supply : shared supply
+DLDO4  : LDO   : dldoin-supply : shared supply
+ELDO1  : LDO   : eldoin-supply : shared supply
+ELDO2  : LDO   : eldoin-supply : shared supply
+ELDO3  : LDO   : eldoin-supply : shared supply
+FLDO1  : LDO   : fldoin-supply : shared supply
+FLDO2  : LDO   : fldoin-supply : shared supply
+FLDO3  : LDO   : fldoin-supply : shared supply
+LDO_IO0: LDO   : ips-supply: GPIO 0
+LDO_IO1: LDO   : ips-supply: GPIO 1
+RTC_LDO: LDO   : ips-supply: always on
+SW : On/Off Switch : swin-supply
+DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
+
 Example:
 
 axp209: pmic@34 {
-- 
2.11.0

[PATCH 2/6] dt-bindings: mfd: axp20x: Introduce bindings for AXP813

[Chen-Yu Tsai]

The X-Powers AXP813 is a PMIC designed to be paired with Allwinner's
A83T SoC. There is also an AXP818, which is paired with the H8 SoC.

The two models seem to be identical, apart from the external markings.

This patch introduces the basic mfd and regulator bindings for the
AXP813.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 49 +---
 1 file changed, 44 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 211a100c6b20..1dff7e2ec375 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -9,6 +9,12 @@ axp223 (X-Powers)
 axp803 (X-Powers)
 axp806 (X-Powers)
 axp809 (X-Powers)
+axp813 (X-Powers)
+
+The AXP813 is 2 chips packaged into 1. The 2 chips do not share anything
+other than the packaging. Pins are routed separately. As such they should
+be treated as separate entities. The other half is an AC100 RTC/codec
+combo chip. Please see ac100.txt for its bindings.
 
 Required properties:
 - compatible: should be one of:
@@ -20,6 +26,7 @@ Required properties:
 * "x-powers,axp803"
 * "x-powers,axp806"
 * "x-powers,axp809"
+* "x-powers,axp813"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -29,12 +36,14 @@ Required properties:
 Optional properties:
 - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
  AXP152/20X: range:  750-1875, Default: 1.5 MHz
- AXP22X/80X: range: 1800-4050, Default: 3   MHz
+ AXP22X/8XX: range: 1800-4050, Default: 3   MHz
 
-- x-powers,drive-vbus-en: axp221 / axp223 only boolean, set this when the
- N_VBUSEN pin is used as an output pin to control an external
- regulator to drive the OTG VBus, rather then as an input pin
- which signals whether the board is driving OTG VBus or not.
+- x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
+ used as an output pin to control an external
+ regulator to drive the OTG VBus, rather then
+ as an input pin which signals whether the
+ board is driving OTG VBus or not.
+ (axp221 / axp223 / axp813 only)
 
 - x-powers,master-mode: Boolean (axp806 only). Set this when the PMIC is
wired for master mode. The default is slave mode.
@@ -172,6 +181,36 @@ LDO_IO1: LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 SW : On/Off Switch : swin-supply
 
+AXP813 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDC1  : DC-DC buck: vin1-supply
+DCDC2  : DC-DC buck: vin2-supply   : poly-phase capable
+DCDC3  : DC-DC buck: vin3-supply   : poly-phase capable
+DCDC4  : DC-DC buck: vin4-supply
+DCDC5  : DC-DC buck: vin5-supply   : poly-phase capable
+DCDC6  : DC-DC buck: vin6-supply   : poly-phase capable
+DCDC7  : DC-DC buck: vin7-supply
+ALDO1  : LDO   : aldoin-supply : shared supply
+ALDO2  : LDO   : aldoin-supply : shared supply
+ALDO3  : LDO   : aldoin-supply : shared supply
+DLDO1  : LDO   : dldoin-supply : shared supply
+DLDO2  : LDO   : dldoin-supply : shared supply
+DLDO3  : LDO   : dldoin-supply : shared supply
+DLDO4  : LDO   : dldoin-supply : shared supply
+ELDO1  : LDO   : eldoin-supply : shared supply
+ELDO2  : LDO   : eldoin-supply : shared supply
+ELDO3  : LDO   : eldoin-supply : shared supply
+FLDO1  : LDO   : fldoin-supply : shared supply
+FLDO2  : LDO   : fldoin-supply : shared supply
+FLDO3  : LDO   : fldoin-supply : shared supply
+LDO_IO0: LDO   : ips-supply: GPIO 0
+LDO_IO1: LDO   : ips-supply: GPIO 1
+RTC_LDO: LDO   : ips-supply: always on
+SW : On/Off Switch : swin-supply
+DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
+
 Example:
 
 axp209: pmic@34 {
-- 
2.11.0

[PATCH 3/6] mfd: axp20x: Add support for AXP813 PMIC

[Chen-Yu Tsai]

The X-Powers AXP813 PMIC is normally used with Allwinner's A83T SoC.
It has the same range of functions as other X-Powers PMICs, such as
DC-DC buck converter and linear regulator outputs, AC-IN and VBUS
power supplies, power button trigger, GPIOs, ADCs, and a battery
charger.

Note that the IRQ table given in the datasheet is incorrect: in IRQ
enable/status registers 1, there are separate IRQs for ACIN and VBUS,
instead of bits [7:5] being the same as bits [4:2]. So it shares the
same IRQs as the AXP803, rather than the AXP288.

This patch adds basic mfd support for it, with only the power button
enabled.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/mfd/axp20x-rsb.c   |  1 +
 drivers/mfd/axp20x.c   | 22 ++
 include/linux/mfd/axp20x.h | 29 +
 3 files changed, 52 insertions(+)

diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index fd5c7267b136..7ddbd9e8dd03 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -64,6 +64,7 @@ static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
{ .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
+   { .compatible = "x-powers,axp813", .data = (void *)AXP813_ID },
{ },
 };
 MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 917b6ddc4f15..ec4271ca065c 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -44,6 +44,7 @@ static const char * const axp20x_model_names[] = {
"AXP803",
"AXP806",
"AXP809",
+   "AXP813",
 };
 
 static const struct regmap_range axp152_writeable_ranges[] = {
@@ -870,6 +871,14 @@ static struct mfd_cell axp809_cells[] = {
},
 };
 
+static struct mfd_cell axp813_cells[] = {
+   {
+   .name   = "axp20x-pek",
+   .num_resources  = ARRAY_SIZE(axp803_pek_resources),
+   .resources  = axp803_pek_resources,
+   }
+};
+
 static struct axp20x_dev *axp20x_pm_power_off;
 static void axp20x_power_off(void)
 {
@@ -956,6 +965,19 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_cfg = _regmap_config;
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
+   case AXP813_ID:
+   axp20x->nr_cells = ARRAY_SIZE(axp813_cells);
+   axp20x->cells = axp813_cells;
+   axp20x->regmap_cfg = _regmap_config;
+   /*
+* The IRQ table given in the datasheet is incorrect.
+* In IRQ enable/status registers 1, there are separate
+* IRQs for ACIN and VBUS, instead of bits [7:5] being
+* the same as bits [4:2]. So it shares the same IRQs
+* as the AXP803, rather than the AXP288.
+*/
+   axp20x->regmap_irq_chip = _regmap_irq_chip;
+   break;
default:
dev_err(dev, "unsupported AXP20X ID %lu\n", axp20x->variant);
return -EINVAL;
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 965b027e31b3..e9c908c4fba8 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -23,6 +23,7 @@ enum axp20x_variants {
AXP803_ID,
AXP806_ID,
AXP809_ID,
+   AXP813_ID,
NR_AXP20X_VARIANTS,
 };
 
@@ -387,6 +388,34 @@ enum {
AXP803_REG_ID_MAX,
 };
 
+enum {
+   AXP813_DCDC1 = 0,
+   AXP813_DCDC2,
+   AXP813_DCDC3,
+   AXP813_DCDC4,
+   AXP813_DCDC5,
+   AXP813_DCDC6,
+   AXP813_DCDC7,
+   AXP813_ALDO1,
+   AXP813_ALDO2,
+   AXP813_ALDO3,
+   AXP813_DLDO1,
+   AXP813_DLDO2,
+   AXP813_DLDO3,
+   AXP813_DLDO4,
+   AXP813_ELDO1,
+   AXP813_ELDO2,
+   AXP813_ELDO3,
+   AXP813_FLDO1,
+   AXP813_FLDO2,
+   AXP813_FLDO3,
+   AXP813_RTC_LDO,
+   AXP813_LDO_IO0,
+   AXP813_LDO_IO1,
+   AXP813_SW,
+   AXP813_REG_ID_MAX,
+};
+
 /* IRQs */
 enum {
AXP152_IRQ_LDO0IN_CONNECT = 1,
-- 
2.11.0

[PATCH 6/6] ARM: sun8i: a83t: Enable AC100 codec / RTC combo chip in AXP813 PMIC

[Chen-Yu Tsai]

The AXP813/AXP818 PMICs used with the A83T/H8 SoCs are actually 2 dies
in one package sharing the serial bus (I2C/RSB) pins. One die is the
actual PMIC. The other is an AC100 codec / RTC combo chip.

This patch enables the RSB controller and adds the device nodes for
the AC100 chip under it.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts 
b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
index 027602ce03d1..933245758603 100644
--- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
@@ -111,6 +111,30 @@
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
};
+
+   ac100: codec@e89 {
+   compatible = "x-powers,ac100";
+   reg = <0xe89>;
+
+   ac100_codec: codec {
+   compatible = "x-powers,ac100-codec";
+   interrupt-parent = <_pio>;
+   interrupts = <0 11 IRQ_TYPE_LEVEL_LOW>; /* PL11 */
+   #clock-cells = <0>;
+   clock-output-names = "4M_adda";
+   };
+
+   ac100_rtc: rtc {
+   compatible = "x-powers,ac100-rtc";
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   clocks = <_codec>;
+   #clock-cells = <1>;
+   clock-output-names = "cko1_rtc",
+"cko2_rtc",
+"cko3_rtc";
+   };
+   };
 };
 
  {
-- 
2.11.0

[PATCH 6/6] ARM: sun8i: a83t: Enable AC100 codec / RTC combo chip in AXP813 PMIC

[Chen-Yu Tsai]

The AXP813/AXP818 PMICs used with the A83T/H8 SoCs are actually 2 dies
in one package sharing the serial bus (I2C/RSB) pins. One die is the
actual PMIC. The other is an AC100 codec / RTC combo chip.

This patch enables the RSB controller and adds the device nodes for
the AC100 chip under it.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts 
b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
index 027602ce03d1..933245758603 100644
--- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
@@ -111,6 +111,30 @@
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
};
+
+   ac100: codec@e89 {
+   compatible = "x-powers,ac100";
+   reg = <0xe89>;
+
+   ac100_codec: codec {
+   compatible = "x-powers,ac100-codec";
+   interrupt-parent = <_pio>;
+   interrupts = <0 11 IRQ_TYPE_LEVEL_LOW>; /* PL11 */
+   #clock-cells = <0>;
+   clock-output-names = "4M_adda";
+   };
+
+   ac100_rtc: rtc {
+   compatible = "x-powers,ac100-rtc";
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   clocks = <_codec>;
+   #clock-cells = <1>;
+   clock-output-names = "cko1_rtc",
+"cko2_rtc",
+"cko3_rtc";
+   };
+   };
 };
 
  {
-- 
2.11.0

[PATCH 1/6] dt-bindings: mfd: axp20x: Add AXP806 to supported list of chips

[Chen-Yu Tsai]

The binding already lists compatibles and regulators for the AXP806,
but it is missing from the list of supported chips at the beginning.

Add it.

Fixes: 204ae2963e10 ("mfd: axp20x: Add bindings for AXP806 PMIC")
Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index aca09af66514..211a100c6b20 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -7,6 +7,7 @@ axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (X-Powers)
 axp803 (X-Powers)
+axp806 (X-Powers)
 axp809 (X-Powers)
 
 Required properties:
-- 
2.11.0

[PATCH 1/6] dt-bindings: mfd: axp20x: Add AXP806 to supported list of chips

[Chen-Yu Tsai]

The binding already lists compatibles and regulators for the AXP806,
but it is missing from the list of supported chips at the beginning.

Add it.

Fixes: 204ae2963e10 ("mfd: axp20x: Add bindings for AXP806 PMIC")
Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index aca09af66514..211a100c6b20 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -7,6 +7,7 @@ axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (X-Powers)
 axp803 (X-Powers)
+axp806 (X-Powers)
 axp809 (X-Powers)
 
 Required properties:
-- 
2.11.0

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

[Andy Lutomirski]

On Wed, Jun 21, 2017 at 5:02 PM, Dave Chinner  wrote:
>
> You seem to be calling the "fdatasync on every page fault" the

It's the opposite of fdatasync().  It needs to sync whatever metadata
is needed to find the data.  The data doesn't need to be synced.

> "lightweight" option. That's the brute-force-with-big-hammer
> solution - it's most definitely not lightweight as every page fault
> has extra overhead to call ->fsync(). Sure, the API is simple, but
> the runtime overhead is significant.

It's lightweight in terms of its impact on the filesystem.  It doesn't
need any persistent setup -- you can just use it.

> Even if you are considering the complexity of the APIs, it's hardly
> a "heavyweight" when it only requires a single call to fallocate()
> before mmap() to set up the immutable extents on the file...

So what would the exact semantics be?  In particular, how can it fail?
 If I do the fallocate(), is it absolutely promised that the extent
map won't get out of sync between what mmap sees and what's on disk?
Do user programs need to worry about colliding with each other when
one does fallocate() to DAXify a file and the other does fallocate()
to unDAXify a file?  Does this particular fallocate() call still keep
its effect after a reboot?

These issues are why I think it would be nicer to have an API that
makes a particular mapping or fd be unconditionally *correct* and then
to provide something else that makes it avoid latency spikes.

Is there an actual concrete proposal that's reviewable?

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

[Andy Lutomirski]

On Wed, Jun 21, 2017 at 5:02 PM, Dave Chinner  wrote:
>
> You seem to be calling the "fdatasync on every page fault" the

It's the opposite of fdatasync().  It needs to sync whatever metadata
is needed to find the data.  The data doesn't need to be synced.

> "lightweight" option. That's the brute-force-with-big-hammer
> solution - it's most definitely not lightweight as every page fault
> has extra overhead to call ->fsync(). Sure, the API is simple, but
> the runtime overhead is significant.

It's lightweight in terms of its impact on the filesystem.  It doesn't
need any persistent setup -- you can just use it.

> Even if you are considering the complexity of the APIs, it's hardly
> a "heavyweight" when it only requires a single call to fallocate()
> before mmap() to set up the immutable extents on the file...

So what would the exact semantics be?  In particular, how can it fail?
 If I do the fallocate(), is it absolutely promised that the extent
map won't get out of sync between what mmap sees and what's on disk?
Do user programs need to worry about colliding with each other when
one does fallocate() to DAXify a file and the other does fallocate()
to unDAXify a file?  Does this particular fallocate() call still keep
its effect after a reboot?

These issues are why I think it would be nicer to have an API that
makes a particular mapping or fd be unconditionally *correct* and then
to provide something else that makes it avoid latency spikes.

Is there an actual concrete proposal that's reviewable?

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

[Viresh Kumar]

On 21-06-17, 17:57, Morten Rasmussen wrote:
> It is true that this patch relies on the notifiers, but I don't see how
> that prevents us from adding a non-notifier based solution for
> fast-switch enabled platforms later?

No it doesn't, but I thought it would be better to have a single
solution (if possible) for all the cases here.

> > I think this patch doesn't really need to go down the notifiers way.
> > 
> > We can do something like this in the implementation of
> > topology_get_freq_scale():
> > 
> > return (policy->cur << SCHED_CAPACITY_SHIFT) / max;
> > 
> > Though, we would be required to take care of policy structure in this
> > case somehow.
> 
> This is exactly what this patch implements. Unfortunately we can't be
> sure that there is a valid policy data structure where we can read the
> information from.

Actually there is a way around that.

- Revert one of my patches:
  commit f9f41e3ef99a ("cpufreq: Remove policy create/remove notifiers")

- Use those notifiers in init_cpu_capacity_callback() instead of
  CPUFREQ_NOTIFY and set/reset a local policy pointer.

- And this pointer we can use safely/reliably in
  topology_get_freq_scale(). We may need to use RCU read side
  protection in topology_get_freq_scale() though, to make sure the
  local policy pointer isn't getting updated simultaneously.

- If the policy pointer isn't set, then we can use
  SCHED_CAPACITY_SCALE value instead.


> Isn't the policy protected by a lock as well?

There are locks, but you don't need any to read policy->cur.

> Another thing is that I don't think a transition notifier based solution
> or any other solution based on the cur/max ratio is really the right way
> to go for fast-switching platforms. If we can do very frequent frequency
> switching it makes less sense to use the current ratio whenever we
> update the PELT averages as the frequency might have changed multiple
> times since the last update. So it would make more sense to have an
> average ratio instead.

> If the platform has HW counters (e.g. APERF/MPERF) that can provide the
> ratio then we should of course use those, if not, one solution could be
> to let cpufreq track the average frequency for each cpu over a suitable
> time window (around one sched period I think). It should be fairly low
> overhead to maintain. In the topology driver, we would then choose
> whether the scaling factor is provided by the cpufreq average frequency
> ratio or the current transition notifier based approach based on the
> capabilities of the platform.

Hmm, maybe.

-- 
viresh

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

[Viresh Kumar]

On 21-06-17, 17:57, Morten Rasmussen wrote:
> It is true that this patch relies on the notifiers, but I don't see how
> that prevents us from adding a non-notifier based solution for
> fast-switch enabled platforms later?

No it doesn't, but I thought it would be better to have a single
solution (if possible) for all the cases here.

> > I think this patch doesn't really need to go down the notifiers way.
> > 
> > We can do something like this in the implementation of
> > topology_get_freq_scale():
> > 
> > return (policy->cur << SCHED_CAPACITY_SHIFT) / max;
> > 
> > Though, we would be required to take care of policy structure in this
> > case somehow.
> 
> This is exactly what this patch implements. Unfortunately we can't be
> sure that there is a valid policy data structure where we can read the
> information from.

Actually there is a way around that.

- Revert one of my patches:
  commit f9f41e3ef99a ("cpufreq: Remove policy create/remove notifiers")

- Use those notifiers in init_cpu_capacity_callback() instead of
  CPUFREQ_NOTIFY and set/reset a local policy pointer.

- And this pointer we can use safely/reliably in
  topology_get_freq_scale(). We may need to use RCU read side
  protection in topology_get_freq_scale() though, to make sure the
  local policy pointer isn't getting updated simultaneously.

- If the policy pointer isn't set, then we can use
  SCHED_CAPACITY_SCALE value instead.


> Isn't the policy protected by a lock as well?

There are locks, but you don't need any to read policy->cur.

> Another thing is that I don't think a transition notifier based solution
> or any other solution based on the cur/max ratio is really the right way
> to go for fast-switching platforms. If we can do very frequent frequency
> switching it makes less sense to use the current ratio whenever we
> update the PELT averages as the frequency might have changed multiple
> times since the last update. So it would make more sense to have an
> average ratio instead.

> If the platform has HW counters (e.g. APERF/MPERF) that can provide the
> ratio then we should of course use those, if not, one solution could be
> to let cpufreq track the average frequency for each cpu over a suitable
> time window (around one sched period I think). It should be fairly low
> overhead to maintain. In the topology driver, we would then choose
> whether the scaling factor is provided by the cpufreq average frequency
> ratio or the current transition notifier based approach based on the
> capabilities of the platform.

Hmm, maybe.

-- 
viresh

[PATCH] radio: wl1273: add check on core->write() return value

[Gustavo A. R. Silva]

Check return value from call to core->write(), so in case of
error print error message, jump to goto label fail and eventually
return.

Addresses-Coverity-ID: 1226943
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/radio/radio-wl1273.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 7240223..17e82a9 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -610,10 +610,21 @@ static int wl1273_fm_start(struct wl1273_device *radio, 
int new_mode)
}
}
 
-   if (radio->rds_on)
+   if (radio->rds_on) {
r = core->write(core, WL1273_RDS_DATA_ENB, 1);
-   else
+   if (r) {
+   dev_err(dev, "%s: RDS_DATA_ENB ON fails\n",
+   __func__);
+   goto fail;
+   }
+   } else {
r = core->write(core, WL1273_RDS_DATA_ENB, 0);
+   if (r) {
+   dev_err(dev, "%s: RDS_DATA_ENB OFF fails\n",
+   __func__);
+   goto fail;
+   }
+   }
} else {
dev_warn(dev, "%s: Illegal mode.\n", __func__);
}
-- 
2.5.0

[PATCH] radio: wl1273: add check on core->write() return value

[Gustavo A. R. Silva]

Check return value from call to core->write(), so in case of
error print error message, jump to goto label fail and eventually
return.

Addresses-Coverity-ID: 1226943
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/radio/radio-wl1273.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 7240223..17e82a9 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -610,10 +610,21 @@ static int wl1273_fm_start(struct wl1273_device *radio, 
int new_mode)
}
}
 
-   if (radio->rds_on)
+   if (radio->rds_on) {
r = core->write(core, WL1273_RDS_DATA_ENB, 1);
-   else
+   if (r) {
+   dev_err(dev, "%s: RDS_DATA_ENB ON fails\n",
+   __func__);
+   goto fail;
+   }
+   } else {
r = core->write(core, WL1273_RDS_DATA_ENB, 0);
+   if (r) {
+   dev_err(dev, "%s: RDS_DATA_ENB OFF fails\n",
+   __func__);
+   goto fail;
+   }
+   }
} else {
dev_warn(dev, "%s: Illegal mode.\n", __func__);
}
-- 
2.5.0

Re: linux-next: Tree for Jun 7 (arch/x86/mm/tlb.c: events)

[Randy Dunlap]

On 06/21/2017 05:35 PM, Stephen Rothwell wrote:
> Hi Randy,
> 
> On Wed, 7 Jun 2017 09:26:26 -0700 Randy Dunlap <rdun...@infradead.org> wrote:
>>
>> on i386:
>>
>>   CC  arch/x86/mm/tlb.o
>> In file included from ../include/linux/mm.h:1032:0,
>>  from ../arch/x86/mm/tlb.c:3:
>> ../arch/x86/mm/tlb.c: In function 'flush_tlb_func_remote':
>> ../arch/x86/mm/tlb.c:251:21: error: 'NR_TLB_REMOTE_FLUSH_RECEIVED' 
>> undeclared (first use in this function)
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
>>  ^
>> ../arch/x86/mm/tlb.c:251:21: note: each undeclared identifier is reported 
>> only once for each function it appears in
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
>>  ^
>> ../arch/x86/mm/tlb.c: In function 'native_flush_tlb_others':
>> ../arch/x86/mm/tlb.c:258:21: error: 'NR_TLB_REMOTE_FLUSH' undeclared (first 
>> use in this function)
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
>>  ^
>> ../arch/x86/mm/tlb.c: In function 'do_flush_tlb_all':
>> ../arch/x86/mm/tlb.c:326:21: error: 'NR_TLB_REMOTE_FLUSH_RECEIVED' 
>> undeclared (first use in this function)
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
>>  ^
>> ../arch/x86/mm/tlb.c: In function 'flush_tlb_all':
>> ../arch/x86/mm/tlb.c:334:21: error: 'NR_TLB_REMOTE_FLUSH' undeclared (first 
>> use in this function)
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
> 
> Do you know if this has been fixed?
> 

I cannot repro it on linux-next of 20170621.

-- 
~Randy

Re: linux-next: Tree for Jun 7 (arch/x86/mm/tlb.c: events)

[Randy Dunlap]

On 06/21/2017 05:35 PM, Stephen Rothwell wrote:
> Hi Randy,
> 
> On Wed, 7 Jun 2017 09:26:26 -0700 Randy Dunlap  wrote:
>>
>> on i386:
>>
>>   CC  arch/x86/mm/tlb.o
>> In file included from ../include/linux/mm.h:1032:0,
>>  from ../arch/x86/mm/tlb.c:3:
>> ../arch/x86/mm/tlb.c: In function 'flush_tlb_func_remote':
>> ../arch/x86/mm/tlb.c:251:21: error: 'NR_TLB_REMOTE_FLUSH_RECEIVED' 
>> undeclared (first use in this function)
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
>>  ^
>> ../arch/x86/mm/tlb.c:251:21: note: each undeclared identifier is reported 
>> only once for each function it appears in
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
>>  ^
>> ../arch/x86/mm/tlb.c: In function 'native_flush_tlb_others':
>> ../arch/x86/mm/tlb.c:258:21: error: 'NR_TLB_REMOTE_FLUSH' undeclared (first 
>> use in this function)
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
>>  ^
>> ../arch/x86/mm/tlb.c: In function 'do_flush_tlb_all':
>> ../arch/x86/mm/tlb.c:326:21: error: 'NR_TLB_REMOTE_FLUSH_RECEIVED' 
>> undeclared (first use in this function)
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
>>  ^
>> ../arch/x86/mm/tlb.c: In function 'flush_tlb_all':
>> ../arch/x86/mm/tlb.c:334:21: error: 'NR_TLB_REMOTE_FLUSH' undeclared (first 
>> use in this function)
>>   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
>>  ^
>> ../include/linux/vmstat.h:90:49: note: in definition of macro 
>> 'count_vm_tlb_event'
>>  #define count_vm_tlb_event(x)count_vm_event(x)
> 
> Do you know if this has been fixed?
> 

I cannot repro it on linux-next of 20170621.

-- 
~Randy

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

[Viresh Kumar]

On 21-06-17, 17:38, Dietmar Eggemann wrote:
> On 20/06/17 07:17, Viresh Kumar wrote:

> > Any specific reason on why are we doing this from PRECHANGE and
> > not POSTCHANGE ? i.e. we are doing this before the frequency is
> > really updated.
> 
> Not really. In case I get a CPUFREQ_POSTCHANGE all the time the
> frequency actually changed I can switch to CPUFREQ_POSTCHANGE.

Yes, you should always get that. And its not right to do any such
change in PRECHANGE notifier as we may fail to change the frequency as
well..

> > Wanted to make sure that we all understand the constraints this is going to 
> > add
> > for the ARM64 platforms.
> > 
> > With the introduction of this transition notifier, we would not be able to 
> > use
> > the fast-switch path in the schedutil governor. I am not sure if there are 
> > any
> > ARM platforms that can actually use the fast-switch path in future or not
> > though. The requirement of fast-switch path is that the freq can be changed
> > without sleeping in the hot-path.
> 
> That's a good point. The cpufreq transition notifier based Frequency
> Invariance Engine (FIE) can only work if none of the cpufreq policies
> support fast frequency switching. 

At least with the current design, yes.

> What about we still enable cpufreq transition notifier based FIE for
> systems where this is true. This will cover 100% of all arm/arm64
> systems today.

I would suggest having a single solution for everyone if we can.

> In case one day we have a cpufreq driver which allows fast frequency
> switching we would need a FIE based on something else than cpufreq
> transition notifier. Maybe based on performance counters (something
> similar to x86 APERF/MPERF) or cpufreq core could provide a function
> which provides the avg frequency value.
> 
> I could make the current implementation more future-proof by only
> using the notifier based FIE in case all policies use slow frequency
> switching:
> 
> >From afe64b5c0606cad4304b77fc5cff819d3083a88d Mon Sep 17 00:00:00 2001
> From: Dietmar Eggemann 
> Date: Wed, 21 Jun 2017 14:53:26 +0100
> Subject: [PATCH] drivers base/arch_topology: enable cpufreq transistion
>  notifier based FIE only for slow frequency switching
> 
> Fast frequency switching is incompatible with cpufreq transition
> notifiers.
> 
> Enable the cpufreq transition notifier based Frequency Invariance Engine
> (FIE) only in case there are no cpufreq policies able to use fast
> frequency switching.
> 
> Currently there are no cpufreq drivers for arm/arm64 which support fast
> frequency switching. In case such a driver will appear the FEI
> topology_get_freq_scale() has to be extended to provide frequency
> invariance based on something else than cpufreq transition notifiers,
> e.g. performance counters.
> 
> Signed-off-by: Dietmar Eggemann 
> ---
>  drivers/base/arch_topology.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> index c2539dc584d5..bd14c5e81f63 100644
> --- a/drivers/base/arch_topology.c
> +++ b/drivers/base/arch_topology.c
> @@ -171,6 +171,7 @@ static bool cap_parsing_done;
>  static void parsing_done_workfn(struct work_struct *work);
>  static DECLARE_WORK(parsing_done_work, parsing_done_workfn);
>  static DEFINE_PER_CPU(unsigned long, max_freq);
> +static bool enable_freq_inv = true;
> 
>  static int
>  init_cpu_capacity_callback(struct notifier_block *nb,
> @@ -199,6 +200,8 @@ init_cpu_capacity_callback(struct notifier_block *nb,
> policy->cpuinfo.max_freq / 1000UL;
> capacity_scale = max(raw_capacity[cpu], 
> capacity_scale);
> }
> +   if (policy->fast_switch_possible)
> +   enable_freq_inv = false;
> if (cpumask_empty(cpus_to_visit)) {
> if (!cap_parsing_failed) {
> topology_normalize_cpu_scale();
> @@ -268,21 +271,23 @@ static int __init register_cpufreq_notifier(void)
> ret = cpufreq_register_notifier(_cpu_capacity_notifier,
> CPUFREQ_POLICY_NOTIFIER);
> 
> -   if (ret) {
> +   if (ret)
> free_cpumask_var(cpus_to_visit);
> -   return ret;
> -   }
> 
> -   return cpufreq_register_notifier(_freq_scale_notifier,
> -CPUFREQ_TRANSITION_NOTIFIER);
> +   return ret;
>  }
>  core_initcall(register_cpufreq_notifier);
> 
>  static void parsing_done_workfn(struct work_struct *work)
>  {
> +
> free_cpumask_var(cpus_to_visit);
> cpufreq_unregister_notifier(_cpu_capacity_notifier,
>  CPUFREQ_POLICY_NOTIFIER);
> +
> +   if (enable_freq_inv)
> +   cpufreq_register_notifier(_freq_scale_notifier,
> + 

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

[Viresh Kumar]

On 21-06-17, 17:38, Dietmar Eggemann wrote:
> On 20/06/17 07:17, Viresh Kumar wrote:

> > Any specific reason on why are we doing this from PRECHANGE and
> > not POSTCHANGE ? i.e. we are doing this before the frequency is
> > really updated.
> 
> Not really. In case I get a CPUFREQ_POSTCHANGE all the time the
> frequency actually changed I can switch to CPUFREQ_POSTCHANGE.

Yes, you should always get that. And its not right to do any such
change in PRECHANGE notifier as we may fail to change the frequency as
well..

> > Wanted to make sure that we all understand the constraints this is going to 
> > add
> > for the ARM64 platforms.
> > 
> > With the introduction of this transition notifier, we would not be able to 
> > use
> > the fast-switch path in the schedutil governor. I am not sure if there are 
> > any
> > ARM platforms that can actually use the fast-switch path in future or not
> > though. The requirement of fast-switch path is that the freq can be changed
> > without sleeping in the hot-path.
> 
> That's a good point. The cpufreq transition notifier based Frequency
> Invariance Engine (FIE) can only work if none of the cpufreq policies
> support fast frequency switching. 

At least with the current design, yes.

> What about we still enable cpufreq transition notifier based FIE for
> systems where this is true. This will cover 100% of all arm/arm64
> systems today.

I would suggest having a single solution for everyone if we can.

> In case one day we have a cpufreq driver which allows fast frequency
> switching we would need a FIE based on something else than cpufreq
> transition notifier. Maybe based on performance counters (something
> similar to x86 APERF/MPERF) or cpufreq core could provide a function
> which provides the avg frequency value.
> 
> I could make the current implementation more future-proof by only
> using the notifier based FIE in case all policies use slow frequency
> switching:
> 
> >From afe64b5c0606cad4304b77fc5cff819d3083a88d Mon Sep 17 00:00:00 2001
> From: Dietmar Eggemann 
> Date: Wed, 21 Jun 2017 14:53:26 +0100
> Subject: [PATCH] drivers base/arch_topology: enable cpufreq transistion
>  notifier based FIE only for slow frequency switching
> 
> Fast frequency switching is incompatible with cpufreq transition
> notifiers.
> 
> Enable the cpufreq transition notifier based Frequency Invariance Engine
> (FIE) only in case there are no cpufreq policies able to use fast
> frequency switching.
> 
> Currently there are no cpufreq drivers for arm/arm64 which support fast
> frequency switching. In case such a driver will appear the FEI
> topology_get_freq_scale() has to be extended to provide frequency
> invariance based on something else than cpufreq transition notifiers,
> e.g. performance counters.
> 
> Signed-off-by: Dietmar Eggemann 
> ---
>  drivers/base/arch_topology.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> index c2539dc584d5..bd14c5e81f63 100644
> --- a/drivers/base/arch_topology.c
> +++ b/drivers/base/arch_topology.c
> @@ -171,6 +171,7 @@ static bool cap_parsing_done;
>  static void parsing_done_workfn(struct work_struct *work);
>  static DECLARE_WORK(parsing_done_work, parsing_done_workfn);
>  static DEFINE_PER_CPU(unsigned long, max_freq);
> +static bool enable_freq_inv = true;
> 
>  static int
>  init_cpu_capacity_callback(struct notifier_block *nb,
> @@ -199,6 +200,8 @@ init_cpu_capacity_callback(struct notifier_block *nb,
> policy->cpuinfo.max_freq / 1000UL;
> capacity_scale = max(raw_capacity[cpu], 
> capacity_scale);
> }
> +   if (policy->fast_switch_possible)
> +   enable_freq_inv = false;
> if (cpumask_empty(cpus_to_visit)) {
> if (!cap_parsing_failed) {
> topology_normalize_cpu_scale();
> @@ -268,21 +271,23 @@ static int __init register_cpufreq_notifier(void)
> ret = cpufreq_register_notifier(_cpu_capacity_notifier,
> CPUFREQ_POLICY_NOTIFIER);
> 
> -   if (ret) {
> +   if (ret)
> free_cpumask_var(cpus_to_visit);
> -   return ret;
> -   }
> 
> -   return cpufreq_register_notifier(_freq_scale_notifier,
> -CPUFREQ_TRANSITION_NOTIFIER);
> +   return ret;
>  }
>  core_initcall(register_cpufreq_notifier);
> 
>  static void parsing_done_workfn(struct work_struct *work)
>  {
> +
> free_cpumask_var(cpus_to_visit);
> cpufreq_unregister_notifier(_cpu_capacity_notifier,
>  CPUFREQ_POLICY_NOTIFIER);
> +
> +   if (enable_freq_inv)
> +   cpufreq_register_notifier(_freq_scale_notifier,
> + CPUFREQ_TRANSITION_NOTIFIER);
>  }

This may 

Re: [PATCH 1/1] futex: remove duplicated code and fix UB

[Darren Hart]

On Wed, Jun 21, 2017 at 01:53:18PM +0200, Jiri Slaby wrote:
> There is code duplicated over all architecture's headers for
> futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
> and comparison of the result.
> 
> Remove this duplication and leave up to the arches only the needed
> assembly which is now in arch_futex_atomic_op_inuser.
> 
> This effectively distributes the Will Deacon's arm64 fix for undefined
> behaviour reported by UBSAN to all architectures. The fix was done in
> commit 5f16a046f8e1 (arm64: futex: Fix undefined behaviour with
> FUTEX_OP_OPARG_SHIFT usage).  Look there for an example dump.
> 
> Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
> remove pointless access_ok() checks") as access_ok there returns true.
> We introduce it back to the helper for the sake of simplicity (it gets
> optimized away anyway).
> 

This required a minor manual merge for ARM on the tip of Linus' tree today. The
reduced duplication is a welcome improvement.

Reviewed-by: Darren Hart (VMware) 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 1/1] futex: remove duplicated code and fix UB

[Darren Hart]

On Wed, Jun 21, 2017 at 01:53:18PM +0200, Jiri Slaby wrote:
> There is code duplicated over all architecture's headers for
> futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
> and comparison of the result.
> 
> Remove this duplication and leave up to the arches only the needed
> assembly which is now in arch_futex_atomic_op_inuser.
> 
> This effectively distributes the Will Deacon's arm64 fix for undefined
> behaviour reported by UBSAN to all architectures. The fix was done in
> commit 5f16a046f8e1 (arm64: futex: Fix undefined behaviour with
> FUTEX_OP_OPARG_SHIFT usage).  Look there for an example dump.
> 
> Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
> remove pointless access_ok() checks") as access_ok there returns true.
> We introduce it back to the helper for the sake of simplicity (it gets
> optimized away anyway).
> 

This required a minor manual merge for ARM on the tip of Linus' tree today. The
reduced duplication is a welcome improvement.

Reviewed-by: Darren Hart (VMware) 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH NET] net/hns:bugfix of ethtool -t phy self_test

[l00371289]

Hi, Andrew

On 2017/6/22 11:35, Andrew Lunn wrote:
>> I don't think returning to user space is an option, because it mean
>> ethtool phy self test would fail because if availability of some software
>> resoure, which is not some application would expect. here is what I can
>> think of:
>>
>> driver/net/ethernet/hisilicon/hns/hns_ethtool.c
>> int phy_loopback_selftest(struct phy_device *dev)
>> {
>>  int err;
>>
>>  mutex_lock(dev->mutex);
>>
>>  if (dev->drv->loopback)
>>  err = dev->drv->loopback(dev, 1);
>>
>>  if (err)
>>  goto out;
>>  
>>  /* mac driver do the test*/
>>  .
>>
>>
>>  if (dev->drv->loopback)
>>  err = dev->drv->loopback(dev, 0);
>>
>>  if (err)
>>  goto out;
>>
>> out:
>>  mutex_unlock(dev->mutex);
>>  return err;
>> }
> 
> I don't think you need a mutex here. dev_ioctl.c:
> 
>case SIOCETHTOOL:
> dev_load(net, ifr.ifr_name);
> rtnl_lock();
> ret = dev_ethtool(net, );
> rtnl_unlock();
>  
> So all ethtool operations are protected by the rtnl. You cannot have
> two tests running at once.
> 
>> One question I can think of is that, how do we ensure mac driver enable and
>> disable phy loopback in pair, enable loopback after dev->mutex is taken,
>> disable loopback  before dev->mutex is released?
>> I hope I am not missing something obvious, any suggestion and idea?
> 
> You cannot ensure this. But it would be a pretty obvious bug.
> 
Thanks for your reply, I will send a new patch based on the discussion above.
Please let me know if there is anything else need changing.

Best Regards
Yunsheng Lin

Re: [PATCH NET] net/hns:bugfix of ethtool -t phy self_test

[l00371289]

Hi, Andrew

On 2017/6/22 11:35, Andrew Lunn wrote:
>> I don't think returning to user space is an option, because it mean
>> ethtool phy self test would fail because if availability of some software
>> resoure, which is not some application would expect. here is what I can
>> think of:
>>
>> driver/net/ethernet/hisilicon/hns/hns_ethtool.c
>> int phy_loopback_selftest(struct phy_device *dev)
>> {
>>  int err;
>>
>>  mutex_lock(dev->mutex);
>>
>>  if (dev->drv->loopback)
>>  err = dev->drv->loopback(dev, 1);
>>
>>  if (err)
>>  goto out;
>>  
>>  /* mac driver do the test*/
>>  .
>>
>>
>>  if (dev->drv->loopback)
>>  err = dev->drv->loopback(dev, 0);
>>
>>  if (err)
>>  goto out;
>>
>> out:
>>  mutex_unlock(dev->mutex);
>>  return err;
>> }
> 
> I don't think you need a mutex here. dev_ioctl.c:
> 
>case SIOCETHTOOL:
> dev_load(net, ifr.ifr_name);
> rtnl_lock();
> ret = dev_ethtool(net, );
> rtnl_unlock();
>  
> So all ethtool operations are protected by the rtnl. You cannot have
> two tests running at once.
> 
>> One question I can think of is that, how do we ensure mac driver enable and
>> disable phy loopback in pair, enable loopback after dev->mutex is taken,
>> disable loopback  before dev->mutex is released?
>> I hope I am not missing something obvious, any suggestion and idea?
> 
> You cannot ensure this. But it would be a pretty obvious bug.
> 
Thanks for your reply, I will send a new patch based on the discussion above.
Please let me know if there is anything else need changing.

Best Regards
Yunsheng Lin

[Patch v2 3/3] arm64: dts: register Hi3660's thermal sensor

[Tao Wang]

Bind thermal sensor driver for Hi3660.

Signed-off-by: Tao Wang 
Signed-off-by: Leo Yan 
---
Changes in v2:
- rebase changes on linux next

 arch/arm64/boot/dts/hisilicon/hi3660.dtsi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index c6a1961..a6a1e01 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -848,5 +848,11 @@
 _cfg_func>;
status = "disabled";
};
+
+   tsensor: tsensor {
+   compatible = "hisilicon,hi3660-thermal";
+   reg = <0x0 0xfff3 0x0 0x1000>;
+   #thermal-sensor-cells = <1>;
+   };
};
 };
-- 
1.7.9.5

[Patch v2 3/3] arm64: dts: register Hi3660's thermal sensor

[Tao Wang]

Bind thermal sensor driver for Hi3660.

Signed-off-by: Tao Wang 
Signed-off-by: Leo Yan 
---
Changes in v2:
- rebase changes on linux next

 arch/arm64/boot/dts/hisilicon/hi3660.dtsi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index c6a1961..a6a1e01 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -848,5 +848,11 @@
 _cfg_func>;
status = "disabled";
};
+
+   tsensor: tsensor {
+   compatible = "hisilicon,hi3660-thermal";
+   reg = <0x0 0xfff3 0x0 0x1000>;
+   #thermal-sensor-cells = <1>;
+   };
};
 };
-- 
1.7.9.5

[Patch v2 1/3] dt-bindings: Document the hi3660 thermal sensor bindings

[Tao Wang]

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

Signed-off-by: Tao Wang 
---
Changes in v2:
- remove redundant property

 .../devicetree/bindings/thermal/hi3660-thermal.txt |   16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/hi3660-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/hi3660-thermal.txt 
b/Documentation/devicetree/bindings/thermal/hi3660-thermal.txt
new file mode 100644
index 000..f3dddcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/hi3660-thermal.txt
@@ -0,0 +1,16 @@
+* Temperature Sensor on hisilicon hi3660 SoC
+
+** Required properties :
+
+- compatible: "hisilicon,thermal-hi3660".
+- reg: physical base address of thermal sensor and length of memory mapped
+  region.
+- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
+
+Example :
+
+   tsensor: tsensor {
+   compatible = "hisilicon,thermal-hi3660";
+   reg = <0x0 0xfff3 0x0 0x1000>;
+   #thermal-sensor-cells = <1>;
+};
-- 
1.7.9.5

[Patch v2 2/3] thermal: hisilicon: add thermal sensor driver for Hi3660

[Tao Wang]

This patch adds the support for thermal sensor of Hi3660 SoC.
this will register sensors for thermal framework and use device
tree to bind cooling device.

Signed-off-by: Tao Wang 
Signed-off-by: Leo Yan 
---
Changes in v2:
- correct alphabet order
- correct compatible name

 drivers/thermal/Kconfig  |   10 ++
 drivers/thermal/Makefile |1 +
 drivers/thermal/hi3660_thermal.c |  198 ++
 3 files changed, 209 insertions(+)
 create mode 100644 drivers/thermal/hi3660_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b5b5fac..ed22a90 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -192,6 +192,16 @@ config THERMAL_EMULATION
  because userland can easily disable the thermal policy by simply
  flooding this sysfs node with low temperature values.
 
+config HI3660_THERMAL
+   tristate "Hi3660 thermal driver"
+   depends on ARCH_HISI || COMPILE_TEST
+   depends on HAS_IOMEM
+   depends on OF
+   default y
+   help
+ Enable this to plug Hi3660 thermal driver into the Linux thermal
+ framework.
+
 config HISI_THERMAL
tristate "Hisilicon thermal driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 094d703..f29d0a5 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -55,6 +55,7 @@ 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-$(CONFIG_HI3660_THERMAL)   += hi3660_thermal.o
 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/hi3660_thermal.c b/drivers/thermal/hi3660_thermal.c
new file mode 100644
index 000..68fa9018
--- /dev/null
+++ b/drivers/thermal/hi3660_thermal.c
@@ -0,0 +1,198 @@
+/*
+ *  linux/drivers/thermal/hi3660_thermal.c
+ *
+ *  Copyright (c) 2017 Hisilicon Limited.
+ *  Copyright (c) 2017 Linaro Limited.
+ *
+ *  Author: Tao Wang 
+ *  Author: Leo Yan 
+ *
+ *  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; version 2 of the License.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "thermal_core.h"
+
+#define HW_MAX_SENSORS 4
+#define HISI_MAX_SENSORS   6
+#define SENSOR_MAX 4
+#define SENSOR_AVG 5
+
+#define ADC_MIN116
+#define ADC_MAX922
+
+/* hi3660 Thermal Sensor Dev Structure */
+struct hi3660_thermal_sensor {
+   struct hi3660_thermal_data *thermal;
+   struct thermal_zone_device *tzd;
+
+   uint32_t id;
+};
+
+struct hi3660_thermal_data {
+   struct platform_device *pdev;
+   struct hi3660_thermal_sensor sensors[HISI_MAX_SENSORS];
+   void __iomem *thermal_base;
+};
+
+unsigned int sensor_reg_offset[HW_MAX_SENSORS] = { 0x1c, 0x5c, 0x9c, 0xdc };
+
+
+static int hi3660_thermal_get_temp(void *_sensor, int *temp)
+{
+   struct hi3660_thermal_sensor *sensor = _sensor;
+   struct hi3660_thermal_data *data = sensor->thermal;
+   unsigned int idx;
+   int val, average = 0, max = 0;
+
+   if (sensor->id < HW_MAX_SENSORS) {
+   val = readl(data->thermal_base + sensor_reg_offset[sensor->id]);
+   val = clamp_val(val, ADC_MIN, ADC_MAX);
+   } else {
+   for (idx = 0; idx < HW_MAX_SENSORS; idx++) {
+   val = readl(data->thermal_base
+   + sensor_reg_offset[idx]);
+   val = clamp_val(val, ADC_MIN, ADC_MAX);
+   average += val;
+   if (val > max)
+   max = val;
+   }
+
+   if (sensor->id == SENSOR_MAX)
+   val = max;
+   else if (sensor->id == SENSOR_AVG)
+   val = average / HW_MAX_SENSORS;
+   }
+
+   *temp = ((val - ADC_MIN) * 165000) / (ADC_MAX - ADC_MIN) - 4;
+
+   return 0;
+}
+
+static struct thermal_zone_of_device_ops hi3660_of_thermal_ops = {
+   .get_temp = 

[Patch v2 1/3] dt-bindings: Document the hi3660 thermal sensor bindings

[Tao Wang]

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

Signed-off-by: Tao Wang 
---
Changes in v2:
- remove redundant property

 .../devicetree/bindings/thermal/hi3660-thermal.txt |   16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/hi3660-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/hi3660-thermal.txt 
b/Documentation/devicetree/bindings/thermal/hi3660-thermal.txt
new file mode 100644
index 000..f3dddcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/hi3660-thermal.txt
@@ -0,0 +1,16 @@
+* Temperature Sensor on hisilicon hi3660 SoC
+
+** Required properties :
+
+- compatible: "hisilicon,thermal-hi3660".
+- reg: physical base address of thermal sensor and length of memory mapped
+  region.
+- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
+
+Example :
+
+   tsensor: tsensor {
+   compatible = "hisilicon,thermal-hi3660";
+   reg = <0x0 0xfff3 0x0 0x1000>;
+   #thermal-sensor-cells = <1>;
+};
-- 
1.7.9.5

[Patch v2 2/3] thermal: hisilicon: add thermal sensor driver for Hi3660

[Tao Wang]

This patch adds the support for thermal sensor of Hi3660 SoC.
this will register sensors for thermal framework and use device
tree to bind cooling device.

Signed-off-by: Tao Wang 
Signed-off-by: Leo Yan 
---
Changes in v2:
- correct alphabet order
- correct compatible name

 drivers/thermal/Kconfig  |   10 ++
 drivers/thermal/Makefile |1 +
 drivers/thermal/hi3660_thermal.c |  198 ++
 3 files changed, 209 insertions(+)
 create mode 100644 drivers/thermal/hi3660_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b5b5fac..ed22a90 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -192,6 +192,16 @@ config THERMAL_EMULATION
  because userland can easily disable the thermal policy by simply
  flooding this sysfs node with low temperature values.
 
+config HI3660_THERMAL
+   tristate "Hi3660 thermal driver"
+   depends on ARCH_HISI || COMPILE_TEST
+   depends on HAS_IOMEM
+   depends on OF
+   default y
+   help
+ Enable this to plug Hi3660 thermal driver into the Linux thermal
+ framework.
+
 config HISI_THERMAL
tristate "Hisilicon thermal driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 094d703..f29d0a5 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -55,6 +55,7 @@ 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-$(CONFIG_HI3660_THERMAL)   += hi3660_thermal.o
 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/hi3660_thermal.c b/drivers/thermal/hi3660_thermal.c
new file mode 100644
index 000..68fa9018
--- /dev/null
+++ b/drivers/thermal/hi3660_thermal.c
@@ -0,0 +1,198 @@
+/*
+ *  linux/drivers/thermal/hi3660_thermal.c
+ *
+ *  Copyright (c) 2017 Hisilicon Limited.
+ *  Copyright (c) 2017 Linaro Limited.
+ *
+ *  Author: Tao Wang 
+ *  Author: Leo Yan 
+ *
+ *  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; version 2 of the License.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "thermal_core.h"
+
+#define HW_MAX_SENSORS 4
+#define HISI_MAX_SENSORS   6
+#define SENSOR_MAX 4
+#define SENSOR_AVG 5
+
+#define ADC_MIN116
+#define ADC_MAX922
+
+/* hi3660 Thermal Sensor Dev Structure */
+struct hi3660_thermal_sensor {
+   struct hi3660_thermal_data *thermal;
+   struct thermal_zone_device *tzd;
+
+   uint32_t id;
+};
+
+struct hi3660_thermal_data {
+   struct platform_device *pdev;
+   struct hi3660_thermal_sensor sensors[HISI_MAX_SENSORS];
+   void __iomem *thermal_base;
+};
+
+unsigned int sensor_reg_offset[HW_MAX_SENSORS] = { 0x1c, 0x5c, 0x9c, 0xdc };
+
+
+static int hi3660_thermal_get_temp(void *_sensor, int *temp)
+{
+   struct hi3660_thermal_sensor *sensor = _sensor;
+   struct hi3660_thermal_data *data = sensor->thermal;
+   unsigned int idx;
+   int val, average = 0, max = 0;
+
+   if (sensor->id < HW_MAX_SENSORS) {
+   val = readl(data->thermal_base + sensor_reg_offset[sensor->id]);
+   val = clamp_val(val, ADC_MIN, ADC_MAX);
+   } else {
+   for (idx = 0; idx < HW_MAX_SENSORS; idx++) {
+   val = readl(data->thermal_base
+   + sensor_reg_offset[idx]);
+   val = clamp_val(val, ADC_MIN, ADC_MAX);
+   average += val;
+   if (val > max)
+   max = val;
+   }
+
+   if (sensor->id == SENSOR_MAX)
+   val = max;
+   else if (sensor->id == SENSOR_AVG)
+   val = average / HW_MAX_SENSORS;
+   }
+
+   *temp = ((val - ADC_MIN) * 165000) / (ADC_MAX - ADC_MIN) - 4;
+
+   return 0;
+}
+
+static struct thermal_zone_of_device_ops hi3660_of_thermal_ops = {
+   .get_temp = hi3660_thermal_get_temp,
+};
+
+static int hi3660_thermal_register_sensor(struct platform_device 

[PATCH V5 Resend] PM / OPP: Use - instead of @ for DT entries

[Viresh Kumar]

Compiling the DT file with W=1, DTC warns like follows:

Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
unit name, but no reg property

Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.

Reported-by: Krzysztof Kozlowski 
Reported-by: Masahiro Yamada 
Suggested-by: Mark Rutland 
Signed-off-by: Viresh Kumar 
Acked-by: Rob Herring 
Reviewed-by: Stephen Boyd 
---
@Rafael: You haven't applied it yesterday and I couldn't find it in
patchwork anymore, so I am assuming that I need to send it again.

 Documentation/devicetree/bindings/opp/opp.txt | 38 +--
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
b/Documentation/devicetree/bindings/opp/opp.txt
index 63725498bd20..e36d261b9ba6 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -186,20 +186,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch 
DVFS states together.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@10 {
+   opp-10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <975000 97 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
-   opp@11 {
+   opp-11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <100 98 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
-   opp@12 {
+   opp-12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
clock-latency-ns = <29>;
@@ -265,20 +265,20 @@ independently.
 * independently.
 */
 
-   opp@10 {
+   opp-10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <975000 97 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
-   opp@11 {
+   opp-11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <100 98 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
-   opp@12 {
+   opp-12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
opp-microamp = <9;
@@ -341,20 +341,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@10 {
+   opp-10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <975000 97 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
-   opp@11 {
+   opp-11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <100 98 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
-   opp@12 {
+   opp-12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
opp-microamp = <9>;
@@ -367,20 +367,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@13 {
+   opp-13 {
opp-hz = /bits/ 64 <13>;
opp-microvolt = <105 1045000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <40>;
opp-suspend;
};
-   opp@14 {
+   opp-14 {
opp-hz = /bits/ 64 <14>;
opp-microvolt = <1075000>;
opp-microamp = <10>;
clock-latency-ns = <40>;
};
-   opp@15 {
+   opp-15 {
opp-hz = /bits/ 64 <15>;

[PATCH V5 Resend] PM / OPP: Use - instead of @ for DT entries

[Viresh Kumar]

Compiling the DT file with W=1, DTC warns like follows:

Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
unit name, but no reg property

Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.

Reported-by: Krzysztof Kozlowski 
Reported-by: Masahiro Yamada 
Suggested-by: Mark Rutland 
Signed-off-by: Viresh Kumar 
Acked-by: Rob Herring 
Reviewed-by: Stephen Boyd 
---
@Rafael: You haven't applied it yesterday and I couldn't find it in
patchwork anymore, so I am assuming that I need to send it again.

 Documentation/devicetree/bindings/opp/opp.txt | 38 +--
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
b/Documentation/devicetree/bindings/opp/opp.txt
index 63725498bd20..e36d261b9ba6 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -186,20 +186,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch 
DVFS states together.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@10 {
+   opp-10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <975000 97 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
-   opp@11 {
+   opp-11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <100 98 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
-   opp@12 {
+   opp-12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
clock-latency-ns = <29>;
@@ -265,20 +265,20 @@ independently.
 * independently.
 */
 
-   opp@10 {
+   opp-10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <975000 97 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
-   opp@11 {
+   opp-11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <100 98 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
-   opp@12 {
+   opp-12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
opp-microamp = <9;
@@ -341,20 +341,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@10 {
+   opp-10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <975000 97 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
-   opp@11 {
+   opp-11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <100 98 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
-   opp@12 {
+   opp-12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
opp-microamp = <9>;
@@ -367,20 +367,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@13 {
+   opp-13 {
opp-hz = /bits/ 64 <13>;
opp-microvolt = <105 1045000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <40>;
opp-suspend;
};
-   opp@14 {
+   opp-14 {
opp-hz = /bits/ 64 <14>;
opp-microvolt = <1075000>;
opp-microamp = <10>;
clock-latency-ns = <40>;
};
-   opp@15 {
+   opp-15 {
opp-hz = /bits/ 64 <15>;
opp-microvolt = <110 101 111>;
opp-microamp = <95000>;
@@ -409,7 +409,7 @@ 

Re: [RFC][PATCH 0/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if existed

[Chao Fan]

On Thu, Jun 22, 2017 at 11:20:32AM +0800, Baoquan He wrote:
>On 06/22/17 at 11:10am, Chao Fan wrote:
>> Hi all,
>> 
>> After testing this issue for 100 times in total, I think this patchset
>> works well.
>
>Thanks for your effort, Chao!

No problem, and many thanks for your patch, Bao!

>
>Then I will repost with some modification according to the kbuild test report
>and your comment, and thanks again for that. Maybe next week, there is 
>urgent rhel bug now I am trying to fix.

That's OK if next week. But of course, the earlier to repost, the
better for us.
Thank you again for the patch.

Thanks,
Chao Fan

>
>Thanks
>Baoquan
>
>> 
>> The size of physical memory in my test machine is 229G, the size of
>> mirror region is 26G. In the 100 times, 50 times are with this patchset,
>> 50 times are without it.
>> 
>> Here is my test result:
>> 
>> 
>> |total times|in non-mirror|in mirror
>> |---|-|-
>> before patch| 50|  41 |   9
>> |---|-|-
>> with patch  | 50|   0 |  50
>> 
>> 
>> Firstly, I add the earlyprintk to get efi map when walking the efi map.
>> Then get the range of mirror regions.
>> In kaslr.c, add the earlyprintk to get random_addr in function
>> choose_random_location, find_random_phys_addr. Then check if the address
>> in which is choosen to extract kernel is in mirror region.
>> 
>> If there are any problems, please let me know.
>> 
>> Thanks,
>> Chao Fan
>> 
>> On Thu, Jun 15, 2017 at 03:52:47PM +0800, Baoquan He wrote:
>> >Our customer reported that Kernel text may be located on non-mirror
>> >region (movable zone) when both address range mirroring feature and
>> >KASLR are enabled.
>> >
>> >The functions of address range mirroring feature are as follows.
>> >- The physical memory region whose descriptors in EFI memory map have
>> >  EFI_MEMORY_MORE_RELIABLE attribute (bit: 16) are mirrored
>> >- The function arranges such mirror region into normal zone and other region
>> >  into movable zone in order to locate kernel code and data on mirror region
>> >
>> >So we need restrict kernel to be located inside mirror region if it
>> >is existed.
>> >
>> >The method is very simple. If efi is enabled, just iterate all efi
>> >memory map and pick up mirror region to process for adding candidate
>> >of slot. If efi disabled or no mirror region existed, still process
>> >e820 memory map. This won't bring much efficiency loss, at worst we
>> >just go through all efi memory maps and found no mirror.
>> >
>> >One question:
>> >From code, though mirror regions are existed, they are meaningful only
>> >if kernelcore=mirror kernel option is specified. Not sure if my 
>> >understanding
>> >is correct.
>> >
>> >NOTE:
>> >I haven't got a machine with efi mirror region enabled, so only test the
>> >e820 map processing case and the case of no mirror region on efi machine.
>> >So set this as a RFC patchset, will post formal one after above question
>> >is made clear and mirror issue test passed.
>> >
>> >Baoquan He (2):
>> >  x86/boot/KASLR: Adapt process_e820_entry for all kinds of memory map
>> >  x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if
>> >existed
>> >
>> > arch/x86/boot/compressed/kaslr.c | 129 
>> > +++
>> > 1 file changed, 104 insertions(+), 25 deletions(-)
>> >
>> >-- 
>> >2.5.5
>> >
>> >
>> >
>> 
>> 
>
>

Re: [RFC][PATCH 0/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if existed

[Chao Fan]

On Thu, Jun 22, 2017 at 11:20:32AM +0800, Baoquan He wrote:
>On 06/22/17 at 11:10am, Chao Fan wrote:
>> Hi all,
>> 
>> After testing this issue for 100 times in total, I think this patchset
>> works well.
>
>Thanks for your effort, Chao!

No problem, and many thanks for your patch, Bao!

>
>Then I will repost with some modification according to the kbuild test report
>and your comment, and thanks again for that. Maybe next week, there is 
>urgent rhel bug now I am trying to fix.

That's OK if next week. But of course, the earlier to repost, the
better for us.
Thank you again for the patch.

Thanks,
Chao Fan

>
>Thanks
>Baoquan
>
>> 
>> The size of physical memory in my test machine is 229G, the size of
>> mirror region is 26G. In the 100 times, 50 times are with this patchset,
>> 50 times are without it.
>> 
>> Here is my test result:
>> 
>> 
>> |total times|in non-mirror|in mirror
>> |---|-|-
>> before patch| 50|  41 |   9
>> |---|-|-
>> with patch  | 50|   0 |  50
>> 
>> 
>> Firstly, I add the earlyprintk to get efi map when walking the efi map.
>> Then get the range of mirror regions.
>> In kaslr.c, add the earlyprintk to get random_addr in function
>> choose_random_location, find_random_phys_addr. Then check if the address
>> in which is choosen to extract kernel is in mirror region.
>> 
>> If there are any problems, please let me know.
>> 
>> Thanks,
>> Chao Fan
>> 
>> On Thu, Jun 15, 2017 at 03:52:47PM +0800, Baoquan He wrote:
>> >Our customer reported that Kernel text may be located on non-mirror
>> >region (movable zone) when both address range mirroring feature and
>> >KASLR are enabled.
>> >
>> >The functions of address range mirroring feature are as follows.
>> >- The physical memory region whose descriptors in EFI memory map have
>> >  EFI_MEMORY_MORE_RELIABLE attribute (bit: 16) are mirrored
>> >- The function arranges such mirror region into normal zone and other region
>> >  into movable zone in order to locate kernel code and data on mirror region
>> >
>> >So we need restrict kernel to be located inside mirror region if it
>> >is existed.
>> >
>> >The method is very simple. If efi is enabled, just iterate all efi
>> >memory map and pick up mirror region to process for adding candidate
>> >of slot. If efi disabled or no mirror region existed, still process
>> >e820 memory map. This won't bring much efficiency loss, at worst we
>> >just go through all efi memory maps and found no mirror.
>> >
>> >One question:
>> >From code, though mirror regions are existed, they are meaningful only
>> >if kernelcore=mirror kernel option is specified. Not sure if my 
>> >understanding
>> >is correct.
>> >
>> >NOTE:
>> >I haven't got a machine with efi mirror region enabled, so only test the
>> >e820 map processing case and the case of no mirror region on efi machine.
>> >So set this as a RFC patchset, will post formal one after above question
>> >is made clear and mirror issue test passed.
>> >
>> >Baoquan He (2):
>> >  x86/boot/KASLR: Adapt process_e820_entry for all kinds of memory map
>> >  x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if
>> >existed
>> >
>> > arch/x86/boot/compressed/kaslr.c | 129 
>> > +++
>> > 1 file changed, 104 insertions(+), 25 deletions(-)
>> >
>> >-- 
>> >2.5.5
>> >
>> >
>> >
>> 
>> 
>
>

Re: [PATCH NET] net/hns:bugfix of ethtool -t phy self_test

[Andrew Lunn]

> I don't think returning to user space is an option, because it mean
> ethtool phy self test would fail because if availability of some software
> resoure, which is not some application would expect. here is what I can
> think of:
> 
> driver/net/ethernet/hisilicon/hns/hns_ethtool.c
> int phy_loopback_selftest(struct phy_device *dev)
> {
>   int err;
> 
>   mutex_lock(dev->mutex);
> 
>   if (dev->drv->loopback)
>   err = dev->drv->loopback(dev, 1);
> 
>   if (err)
>   goto out;
>   
>   /* mac driver do the test*/
>   .
> 
> 
>   if (dev->drv->loopback)
>   err = dev->drv->loopback(dev, 0);
> 
>   if (err)
>   goto out;
> 
> out:
>   mutex_unlock(dev->mutex);
>   return err;
> }

I don't think you need a mutex here. dev_ioctl.c:

   case SIOCETHTOOL:
dev_load(net, ifr.ifr_name);
rtnl_lock();
ret = dev_ethtool(net, );
rtnl_unlock();
 
So all ethtool operations are protected by the rtnl. You cannot have
two tests running at once.

> One question I can think of is that, how do we ensure mac driver enable and
> disable phy loopback in pair, enable loopback after dev->mutex is taken,
> disable loopback  before dev->mutex is released?
> I hope I am not missing something obvious, any suggestion and idea?

You cannot ensure this. But it would be a pretty obvious bug.

Andrew

Re: [PATCH NET] net/hns:bugfix of ethtool -t phy self_test

[Andrew Lunn]

> I don't think returning to user space is an option, because it mean
> ethtool phy self test would fail because if availability of some software
> resoure, which is not some application would expect. here is what I can
> think of:
> 
> driver/net/ethernet/hisilicon/hns/hns_ethtool.c
> int phy_loopback_selftest(struct phy_device *dev)
> {
>   int err;
> 
>   mutex_lock(dev->mutex);
> 
>   if (dev->drv->loopback)
>   err = dev->drv->loopback(dev, 1);
> 
>   if (err)
>   goto out;
>   
>   /* mac driver do the test*/
>   .
> 
> 
>   if (dev->drv->loopback)
>   err = dev->drv->loopback(dev, 0);
> 
>   if (err)
>   goto out;
> 
> out:
>   mutex_unlock(dev->mutex);
>   return err;
> }

I don't think you need a mutex here. dev_ioctl.c:

   case SIOCETHTOOL:
dev_load(net, ifr.ifr_name);
rtnl_lock();
ret = dev_ethtool(net, );
rtnl_unlock();
 
So all ethtool operations are protected by the rtnl. You cannot have
two tests running at once.

> One question I can think of is that, how do we ensure mac driver enable and
> disable phy loopback in pair, enable loopback after dev->mutex is taken,
> disable loopback  before dev->mutex is released?
> I hope I am not missing something obvious, any suggestion and idea?

You cannot ensure this. But it would be a pretty obvious bug.

Andrew

Re: [PATCH 01/12] coresight replicator: Cleanup programmable replicator naming

[Rob Herring]

On Tue, Jun 20, 2017 at 11:44 AM, Mathieu Poirier
 wrote:
> On 18 June 2017 at 08:04, Rob Herring  wrote:
>> On Tue, Jun 13, 2017 at 10:55:28AM -0600, Mathieu Poirier wrote:
>>> On Mon, Jun 12, 2017 at 03:36:40PM +0100, Suzuki K Poulose wrote:
>>> > The Linux coresight drivers define the programmable ATB replicator as
>>> > Qualcom replicator, while this is designed by ARM. This can cause 
>>> > confusion
>>> > to a user selecting the driver. Cleanup all references to make it
>>> >  explicitly clear. This patch :
>>> >
>>> >  1) Adds a new compatible string for the same, retaining the old one for
>>> > compatibility.
>>> >  2) Changes the Kconfig symbol (since this is not part of any defconfigs)
>>> >  CORESIGHT_QCOM_REPLICATOR => CORESIGHT_DYNAMIC_REPLICATOR
>>> >  3) Improves the help message in the Kconfig.
>>> >  4) Changes the name of the driver :
>>> > coresight-replicator-qcom => coresight-dynamic-replicator
>>> >
>>> > Cc: Pratik Patel 
>>> > Cc: Ivan T. Ivanov 
>>> > Cc: Mathieu Poirier 
>>> > Cc: devicet...@vger.kernel.org
>>> > Cc: Rob Herring 
>>> > Cc: Mark Rutland 
>>> > Signed-off-by: Suzuki K Poulose 
>>>
>>> Hi Suzuki,
>>>
>>> > ---
>>> >  Documentation/devicetree/bindings/arm/coresight.txt |  4 +++-
>>> >  drivers/hwtracing/coresight/Kconfig | 10 +-
>>> >  drivers/hwtracing/coresight/Makefile|  2 +-
>>> >  drivers/hwtracing/coresight/coresight-replicator-qcom.c |  2 +-
>>> >  4 files changed, 10 insertions(+), 8 deletions(-)
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
>>> > b/Documentation/devicetree/bindings/arm/coresight.txt
>>> > index fcbae6a..f77329f 100644
>>> > --- a/Documentation/devicetree/bindings/arm/coresight.txt
>>> > +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>>> > @@ -34,7 +34,9 @@ its hardware characteristcs.
>>> > - Embedded Trace Macrocell (version 4.x):
>>> > "arm,coresight-etm4x", "arm,primecell";
>>> >
>>> > -   - Qualcomm Configurable Replicator (version 1.x):
>>> > +   - Coresight programmable Replicator (version 1.x):
>>> > +   "arm,coresight-dynamic-replicator", "arm,primecell";
>>> > +   OR
>>> > "qcom,coresight-replicator1x", "arm,primecell";
>>>
>>> Rob, what's your view on keeping the old binding around?  We could simply 
>>> change
>>> the two occurences we find in the DTs (Juno and 410c) to the new name and be
>>> done with the old one.
>>
>> Juno uses the Qcom string? We should keep the old string. You can switch
>> the dts files, but the driver should support the old name.
>
> When we first started working on CoreSight programmable replicators
> were available but the documentation wasn't public.  As such when I
> saw Qualcomm's design I mistakenly thought it was a custom IP block
> and came up with a compatible string that reflected that reality.
> Fast forward 3 years the documentation is available and Juno has used
> the same IP block in their design.  Suzuki's patch rectifies history
> by changing the programmable replicator naming convention to what it
> should have been from the start.
>
> That being said, we can keep the old compatible string around but it
> won't change anything.  CoreSight devices are discovered on the AMBA
> bus and don't use the compatible string - drivers are probed based on
> AMBA IDs laid out in the drivers and device IDs found in HW ID
> registers.
>
> In light of the above let me know what you want to do.

Well, if drivers don't use the string, then there is nothing to keep around.

Rob

Re: [PATCH 01/12] coresight replicator: Cleanup programmable replicator naming

[Rob Herring]

On Tue, Jun 20, 2017 at 11:44 AM, Mathieu Poirier
 wrote:
> On 18 June 2017 at 08:04, Rob Herring  wrote:
>> On Tue, Jun 13, 2017 at 10:55:28AM -0600, Mathieu Poirier wrote:
>>> On Mon, Jun 12, 2017 at 03:36:40PM +0100, Suzuki K Poulose wrote:
>>> > The Linux coresight drivers define the programmable ATB replicator as
>>> > Qualcom replicator, while this is designed by ARM. This can cause 
>>> > confusion
>>> > to a user selecting the driver. Cleanup all references to make it
>>> >  explicitly clear. This patch :
>>> >
>>> >  1) Adds a new compatible string for the same, retaining the old one for
>>> > compatibility.
>>> >  2) Changes the Kconfig symbol (since this is not part of any defconfigs)
>>> >  CORESIGHT_QCOM_REPLICATOR => CORESIGHT_DYNAMIC_REPLICATOR
>>> >  3) Improves the help message in the Kconfig.
>>> >  4) Changes the name of the driver :
>>> > coresight-replicator-qcom => coresight-dynamic-replicator
>>> >
>>> > Cc: Pratik Patel 
>>> > Cc: Ivan T. Ivanov 
>>> > Cc: Mathieu Poirier 
>>> > Cc: devicet...@vger.kernel.org
>>> > Cc: Rob Herring 
>>> > Cc: Mark Rutland 
>>> > Signed-off-by: Suzuki K Poulose 
>>>
>>> Hi Suzuki,
>>>
>>> > ---
>>> >  Documentation/devicetree/bindings/arm/coresight.txt |  4 +++-
>>> >  drivers/hwtracing/coresight/Kconfig | 10 +-
>>> >  drivers/hwtracing/coresight/Makefile|  2 +-
>>> >  drivers/hwtracing/coresight/coresight-replicator-qcom.c |  2 +-
>>> >  4 files changed, 10 insertions(+), 8 deletions(-)
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
>>> > b/Documentation/devicetree/bindings/arm/coresight.txt
>>> > index fcbae6a..f77329f 100644
>>> > --- a/Documentation/devicetree/bindings/arm/coresight.txt
>>> > +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>>> > @@ -34,7 +34,9 @@ its hardware characteristcs.
>>> > - Embedded Trace Macrocell (version 4.x):
>>> > "arm,coresight-etm4x", "arm,primecell";
>>> >
>>> > -   - Qualcomm Configurable Replicator (version 1.x):
>>> > +   - Coresight programmable Replicator (version 1.x):
>>> > +   "arm,coresight-dynamic-replicator", "arm,primecell";
>>> > +   OR
>>> > "qcom,coresight-replicator1x", "arm,primecell";
>>>
>>> Rob, what's your view on keeping the old binding around?  We could simply 
>>> change
>>> the two occurences we find in the DTs (Juno and 410c) to the new name and be
>>> done with the old one.
>>
>> Juno uses the Qcom string? We should keep the old string. You can switch
>> the dts files, but the driver should support the old name.
>
> When we first started working on CoreSight programmable replicators
> were available but the documentation wasn't public.  As such when I
> saw Qualcomm's design I mistakenly thought it was a custom IP block
> and came up with a compatible string that reflected that reality.
> Fast forward 3 years the documentation is available and Juno has used
> the same IP block in their design.  Suzuki's patch rectifies history
> by changing the programmable replicator naming convention to what it
> should have been from the start.
>
> That being said, we can keep the old compatible string around but it
> won't change anything.  CoreSight devices are discovered on the AMBA
> bus and don't use the compatible string - drivers are probed based on
> AMBA IDs laid out in the drivers and device IDs found in HW ID
> registers.
>
> In light of the above let me know what you want to do.

Well, if drivers don't use the string, then there is nothing to keep around.

Rob

[PATCH] tuners: mxl5005s: remove useless variable assignments

[Gustavo A. R. Silva]

Values assigned to variables Fmax and Fmin at lines 2740 and 2741 are
overwritten at lines 2754 and 2755 before they can be used. This makes
such variable assignments useless.

Addresses-Coverity-ID: 1226952
Addresses-Coverity-ID: 1226953
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/tuners/mxl5005s.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/tuners/mxl5005s.c b/drivers/media/tuners/mxl5005s.c
index 353744f..dd59c2c 100644
--- a/drivers/media/tuners/mxl5005s.c
+++ b/drivers/media/tuners/mxl5005s.c
@@ -2737,8 +2737,6 @@ static u16 MXL_TuneRF(struct dvb_frontend *fe, u32 
RF_Freq)
status += MXL_ControlWrite(fe, TG_LO_DIVVAL,0x0);
status += MXL_ControlWrite(fe, TG_LO_SELVAL,0x7);
divider_val = 2 ;
-   Fmax = FmaxBin ;
-   Fmin = FminBin ;
}
 
/* TG_DIV_VAL */
-- 
2.5.0

[PATCH] tuners: mxl5005s: remove useless variable assignments

[Gustavo A. R. Silva]

Values assigned to variables Fmax and Fmin at lines 2740 and 2741 are
overwritten at lines 2754 and 2755 before they can be used. This makes
such variable assignments useless.

Addresses-Coverity-ID: 1226952
Addresses-Coverity-ID: 1226953
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/tuners/mxl5005s.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/tuners/mxl5005s.c b/drivers/media/tuners/mxl5005s.c
index 353744f..dd59c2c 100644
--- a/drivers/media/tuners/mxl5005s.c
+++ b/drivers/media/tuners/mxl5005s.c
@@ -2737,8 +2737,6 @@ static u16 MXL_TuneRF(struct dvb_frontend *fe, u32 
RF_Freq)
status += MXL_ControlWrite(fe, TG_LO_DIVVAL,0x0);
status += MXL_ControlWrite(fe, TG_LO_SELVAL,0x7);
divider_val = 2 ;
-   Fmax = FmaxBin ;
-   Fmin = FminBin ;
}
 
/* TG_DIV_VAL */
-- 
2.5.0

Re: [RFC][PATCH 0/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if existed

[Baoquan He]

On 06/22/17 at 11:10am, Chao Fan wrote:
> Hi all,
> 
> After testing this issue for 100 times in total, I think this patchset
> works well.

Thanks for your effort, Chao!

Then I will repost with some modification according to the kbuild test report
and your comment, and thanks again for that. Maybe next week, there is 
urgent rhel bug now I am trying to fix.

Thanks
Baoquan

> 
> The size of physical memory in my test machine is 229G, the size of
> mirror region is 26G. In the 100 times, 50 times are with this patchset,
> 50 times are without it.
> 
> Here is my test result:
> 
> 
> |total times|in non-mirror|in mirror
> |---|-|-
> before patch| 50|  41 |   9
> |---|-|-
> with patch  | 50|   0 |  50
> 
> 
> Firstly, I add the earlyprintk to get efi map when walking the efi map.
> Then get the range of mirror regions.
> In kaslr.c, add the earlyprintk to get random_addr in function
> choose_random_location, find_random_phys_addr. Then check if the address
> in which is choosen to extract kernel is in mirror region.
> 
> If there are any problems, please let me know.
> 
> Thanks,
> Chao Fan
> 
> On Thu, Jun 15, 2017 at 03:52:47PM +0800, Baoquan He wrote:
> >Our customer reported that Kernel text may be located on non-mirror
> >region (movable zone) when both address range mirroring feature and
> >KASLR are enabled.
> >
> >The functions of address range mirroring feature are as follows.
> >- The physical memory region whose descriptors in EFI memory map have
> >  EFI_MEMORY_MORE_RELIABLE attribute (bit: 16) are mirrored
> >- The function arranges such mirror region into normal zone and other region
> >  into movable zone in order to locate kernel code and data on mirror region
> >
> >So we need restrict kernel to be located inside mirror region if it
> >is existed.
> >
> >The method is very simple. If efi is enabled, just iterate all efi
> >memory map and pick up mirror region to process for adding candidate
> >of slot. If efi disabled or no mirror region existed, still process
> >e820 memory map. This won't bring much efficiency loss, at worst we
> >just go through all efi memory maps and found no mirror.
> >
> >One question:
> >From code, though mirror regions are existed, they are meaningful only
> >if kernelcore=mirror kernel option is specified. Not sure if my understanding
> >is correct.
> >
> >NOTE:
> >I haven't got a machine with efi mirror region enabled, so only test the
> >e820 map processing case and the case of no mirror region on efi machine.
> >So set this as a RFC patchset, will post formal one after above question
> >is made clear and mirror issue test passed.
> >
> >Baoquan He (2):
> >  x86/boot/KASLR: Adapt process_e820_entry for all kinds of memory map
> >  x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if
> >existed
> >
> > arch/x86/boot/compressed/kaslr.c | 129 
> > +++
> > 1 file changed, 104 insertions(+), 25 deletions(-)
> >
> >-- 
> >2.5.5
> >
> >
> >
> 
> 

Re: [RFC][PATCH 0/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if existed

[Baoquan He]

On 06/22/17 at 11:10am, Chao Fan wrote:
> Hi all,
> 
> After testing this issue for 100 times in total, I think this patchset
> works well.

Thanks for your effort, Chao!

Then I will repost with some modification according to the kbuild test report
and your comment, and thanks again for that. Maybe next week, there is 
urgent rhel bug now I am trying to fix.

Thanks
Baoquan

> 
> The size of physical memory in my test machine is 229G, the size of
> mirror region is 26G. In the 100 times, 50 times are with this patchset,
> 50 times are without it.
> 
> Here is my test result:
> 
> 
> |total times|in non-mirror|in mirror
> |---|-|-
> before patch| 50|  41 |   9
> |---|-|-
> with patch  | 50|   0 |  50
> 
> 
> Firstly, I add the earlyprintk to get efi map when walking the efi map.
> Then get the range of mirror regions.
> In kaslr.c, add the earlyprintk to get random_addr in function
> choose_random_location, find_random_phys_addr. Then check if the address
> in which is choosen to extract kernel is in mirror region.
> 
> If there are any problems, please let me know.
> 
> Thanks,
> Chao Fan
> 
> On Thu, Jun 15, 2017 at 03:52:47PM +0800, Baoquan He wrote:
> >Our customer reported that Kernel text may be located on non-mirror
> >region (movable zone) when both address range mirroring feature and
> >KASLR are enabled.
> >
> >The functions of address range mirroring feature are as follows.
> >- The physical memory region whose descriptors in EFI memory map have
> >  EFI_MEMORY_MORE_RELIABLE attribute (bit: 16) are mirrored
> >- The function arranges such mirror region into normal zone and other region
> >  into movable zone in order to locate kernel code and data on mirror region
> >
> >So we need restrict kernel to be located inside mirror region if it
> >is existed.
> >
> >The method is very simple. If efi is enabled, just iterate all efi
> >memory map and pick up mirror region to process for adding candidate
> >of slot. If efi disabled or no mirror region existed, still process
> >e820 memory map. This won't bring much efficiency loss, at worst we
> >just go through all efi memory maps and found no mirror.
> >
> >One question:
> >From code, though mirror regions are existed, they are meaningful only
> >if kernelcore=mirror kernel option is specified. Not sure if my understanding
> >is correct.
> >
> >NOTE:
> >I haven't got a machine with efi mirror region enabled, so only test the
> >e820 map processing case and the case of no mirror region on efi machine.
> >So set this as a RFC patchset, will post formal one after above question
> >is made clear and mirror issue test passed.
> >
> >Baoquan He (2):
> >  x86/boot/KASLR: Adapt process_e820_entry for all kinds of memory map
> >  x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if
> >existed
> >
> > arch/x86/boot/compressed/kaslr.c | 129 
> > +++
> > 1 file changed, 104 insertions(+), 25 deletions(-)
> >
> >-- 
> >2.5.5
> >
> >
> >
> 
> 

[PATCH] iio: adc: Add support for DLN2 ADC

[Jack Andersen]

This patch adds support for Diolan DLN2 ADC via IIO's ADC interface.
ADC is the fourth and final component of the DLN2 for the kernel.

Signed-off-by: Jack Andersen 
---
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/dln2-adc.c | 648 +
 drivers/mfd/dln2.c |  12 +
 4 files changed, 670 insertions(+)
 create mode 100644 drivers/iio/adc/dln2-adc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 401f47b..78d7455 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -239,6 +239,15 @@ config DA9150_GPADC
  To compile this driver as a module, choose M here: the module will be
  called berlin2-adc.
 
+config DLN2_ADC
+   tristate "Diolan DLN-2 ADC driver support"
+   depends on MFD_DLN2
+   help
+ Say yes here to build support for Diolan DLN-2 ADC.
+
+ This driver can also be built as a module. If so, the module will be
+ called adc_dln2.
+
 config ENVELOPE_DETECTOR
tristate "Envelope detector using a DAC and a comparator"
depends on OF
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9339bec..378bc65 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
 obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
 obj-$(CONFIG_CPCAP_ADC) += cpcap-adc.o
 obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
+obj-$(CONFIG_DLN2_ADC) += dln2-adc.o
 obj-$(CONFIG_ENVELOPE_DETECTOR) += envelope-detector.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
 obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
diff --git a/drivers/iio/adc/dln2-adc.c b/drivers/iio/adc/dln2-adc.c
new file mode 100644
index 000..7900e2c
--- /dev/null
+++ b/drivers/iio/adc/dln2-adc.c
@@ -0,0 +1,648 @@
+/*
+ * Driver for the Diolan DLN-2 USB-ADC adapter
+ *
+ * Copyright (c) 2017 Jack Andersen
+ *
+ * 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, version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DLN2_ADC_MOD_NAME "dln2-adc"
+
+#define DLN2_ADC_ID 0x06
+
+#define DLN2_ADC_GET_CHANNEL_COUNT DLN2_CMD(0x01, DLN2_ADC_ID)
+#define DLN2_ADC_ENABLEDLN2_CMD(0x02, DLN2_ADC_ID)
+#define DLN2_ADC_DISABLE   DLN2_CMD(0x03, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_ENABLEDLN2_CMD(0x05, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_DISABLE   DLN2_CMD(0x06, DLN2_ADC_ID)
+#define DLN2_ADC_SET_RESOLUTIONDLN2_CMD(0x08, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_GET_VAL   DLN2_CMD(0x0A, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_GET_ALL_VAL   DLN2_CMD(0x0B, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_SET_CFG   DLN2_CMD(0x0C, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_GET_CFG   DLN2_CMD(0x0D, DLN2_ADC_ID)
+#define DLN2_ADC_CONDITION_MET_EV  DLN2_CMD(0x10, DLN2_ADC_ID)
+
+#define DLN2_ADC_EVENT_NONE0
+#define DLN2_ADC_EVENT_BELOW   1
+#define DLN2_ADC_EVENT_LEVEL_ABOVE 2
+#define DLN2_ADC_EVENT_OUTSIDE 3
+#define DLN2_ADC_EVENT_INSIDE  4
+#define DLN2_ADC_EVENT_ALWAYS  5
+
+#define DLN2_ADC_MAX_CHANNELS 8
+#define DLN2_ADC_DATA_BITS 10
+
+struct dln2_adc {
+   struct platform_device *pdev;
+   int port;
+   struct iio_trigger *trig;
+   /* Set once initialized */
+   u8 port_enabled;
+   /* Set once resolution request made to HW */
+   u8 resolution_set;
+   /* Bitmask requesting enabled channels */
+   unsigned long chans_requested;
+   /* Bitmask indicating enabled channels on HW */
+   unsigned long chans_enabled;
+   /* Channel that is arbitrated for event trigger */
+   int trigger_chan;
+};
+
+struct dln2_adc_port_chan {
+   u8 port;
+   u8 chan;
+};
+
+struct dln2_adc_get_all_vals {
+   __le16 channel_mask;
+   __le16 values[DLN2_ADC_MAX_CHANNELS];
+};
+
+static int dln2_adc_get_chan_count(struct dln2_adc *dln2)
+{
+   int ret;
+   u8 port = dln2->port;
+   int ilen = sizeof(port);
+   u8 count;
+   int olen = sizeof(count);
+
+   ret = dln2_transfer(dln2->pdev, DLN2_ADC_GET_CHANNEL_COUNT,
+   , ilen, , );
+   if (ret < 0) {
+   dev_dbg(>pdev->dev, "Problem in %s\n", __func__);
+   return ret;
+   }
+   if (olen < sizeof(count))
+   return -EPROTO;
+
+   return count;
+}
+
+static int dln2_adc_set_port_resolution(struct dln2_adc *dln2)
+{
+   int ret;
+   struct dln2_adc_port_chan port_chan = {
+   .port = dln2->port,
+   .chan = DLN2_ADC_DATA_BITS,
+   };
+   int ilen = sizeof(port_chan);
+
+   ret = 

[PATCH] iio: adc: Add support for DLN2 ADC

[Jack Andersen]

This patch adds support for Diolan DLN2 ADC via IIO's ADC interface.
ADC is the fourth and final component of the DLN2 for the kernel.

Signed-off-by: Jack Andersen 
---
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/dln2-adc.c | 648 +
 drivers/mfd/dln2.c |  12 +
 4 files changed, 670 insertions(+)
 create mode 100644 drivers/iio/adc/dln2-adc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 401f47b..78d7455 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -239,6 +239,15 @@ config DA9150_GPADC
  To compile this driver as a module, choose M here: the module will be
  called berlin2-adc.
 
+config DLN2_ADC
+   tristate "Diolan DLN-2 ADC driver support"
+   depends on MFD_DLN2
+   help
+ Say yes here to build support for Diolan DLN-2 ADC.
+
+ This driver can also be built as a module. If so, the module will be
+ called adc_dln2.
+
 config ENVELOPE_DETECTOR
tristate "Envelope detector using a DAC and a comparator"
depends on OF
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9339bec..378bc65 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
 obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
 obj-$(CONFIG_CPCAP_ADC) += cpcap-adc.o
 obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
+obj-$(CONFIG_DLN2_ADC) += dln2-adc.o
 obj-$(CONFIG_ENVELOPE_DETECTOR) += envelope-detector.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
 obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
diff --git a/drivers/iio/adc/dln2-adc.c b/drivers/iio/adc/dln2-adc.c
new file mode 100644
index 000..7900e2c
--- /dev/null
+++ b/drivers/iio/adc/dln2-adc.c
@@ -0,0 +1,648 @@
+/*
+ * Driver for the Diolan DLN-2 USB-ADC adapter
+ *
+ * Copyright (c) 2017 Jack Andersen
+ *
+ * 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, version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DLN2_ADC_MOD_NAME "dln2-adc"
+
+#define DLN2_ADC_ID 0x06
+
+#define DLN2_ADC_GET_CHANNEL_COUNT DLN2_CMD(0x01, DLN2_ADC_ID)
+#define DLN2_ADC_ENABLEDLN2_CMD(0x02, DLN2_ADC_ID)
+#define DLN2_ADC_DISABLE   DLN2_CMD(0x03, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_ENABLEDLN2_CMD(0x05, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_DISABLE   DLN2_CMD(0x06, DLN2_ADC_ID)
+#define DLN2_ADC_SET_RESOLUTIONDLN2_CMD(0x08, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_GET_VAL   DLN2_CMD(0x0A, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_GET_ALL_VAL   DLN2_CMD(0x0B, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_SET_CFG   DLN2_CMD(0x0C, DLN2_ADC_ID)
+#define DLN2_ADC_CHANNEL_GET_CFG   DLN2_CMD(0x0D, DLN2_ADC_ID)
+#define DLN2_ADC_CONDITION_MET_EV  DLN2_CMD(0x10, DLN2_ADC_ID)
+
+#define DLN2_ADC_EVENT_NONE0
+#define DLN2_ADC_EVENT_BELOW   1
+#define DLN2_ADC_EVENT_LEVEL_ABOVE 2
+#define DLN2_ADC_EVENT_OUTSIDE 3
+#define DLN2_ADC_EVENT_INSIDE  4
+#define DLN2_ADC_EVENT_ALWAYS  5
+
+#define DLN2_ADC_MAX_CHANNELS 8
+#define DLN2_ADC_DATA_BITS 10
+
+struct dln2_adc {
+   struct platform_device *pdev;
+   int port;
+   struct iio_trigger *trig;
+   /* Set once initialized */
+   u8 port_enabled;
+   /* Set once resolution request made to HW */
+   u8 resolution_set;
+   /* Bitmask requesting enabled channels */
+   unsigned long chans_requested;
+   /* Bitmask indicating enabled channels on HW */
+   unsigned long chans_enabled;
+   /* Channel that is arbitrated for event trigger */
+   int trigger_chan;
+};
+
+struct dln2_adc_port_chan {
+   u8 port;
+   u8 chan;
+};
+
+struct dln2_adc_get_all_vals {
+   __le16 channel_mask;
+   __le16 values[DLN2_ADC_MAX_CHANNELS];
+};
+
+static int dln2_adc_get_chan_count(struct dln2_adc *dln2)
+{
+   int ret;
+   u8 port = dln2->port;
+   int ilen = sizeof(port);
+   u8 count;
+   int olen = sizeof(count);
+
+   ret = dln2_transfer(dln2->pdev, DLN2_ADC_GET_CHANNEL_COUNT,
+   , ilen, , );
+   if (ret < 0) {
+   dev_dbg(>pdev->dev, "Problem in %s\n", __func__);
+   return ret;
+   }
+   if (olen < sizeof(count))
+   return -EPROTO;
+
+   return count;
+}
+
+static int dln2_adc_set_port_resolution(struct dln2_adc *dln2)
+{
+   int ret;
+   struct dln2_adc_port_chan port_chan = {
+   .port = dln2->port,
+   .chan = DLN2_ADC_DATA_BITS,
+   };
+   int ilen = sizeof(port_chan);
+
+   ret = 

[PATCH] DLN2 module for ADC interface

[Jack Andersen]

Hello,

I've been having to blacklist the dln2 module in order to use Diolan's iffy
libusb-based "driver". I'd much rather use dln2, but the lack of ADC support
has been an issue for my robotics application.

I've extended the dln2 module with an additional platform driver to expose the
ADC using the IIO subsystem. It supports triggered buffering via the event
handle kept by dln2, as well as direct raw reads. The voltage scale is fixed
at 3.3v over 10-bits, since that appears to be the maximum resolution supported
by the hardware.

I've tested the module under 4.11.6 and everything appears to be stable.
However, this is my first patch, so it's possible I've missed something.

Jack Andersen (1):
  iio: adc: Add support for DLN2 ADC

 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/dln2-adc.c | 648 +
 drivers/mfd/dln2.c |  12 +
 4 files changed, 670 insertions(+)
 create mode 100644 drivers/iio/adc/dln2-adc.c

-- 
1.9.1

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

[Rob Herring]

On Tue, Jun 20, 2017 at 3:48 PM, Scott Branden
 wrote:
> Hi Rob,
>
>
> On 17-06-18 07:04 AM, Rob Herring wrote:
>>
>> On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote:
>>>
>>> Add device tree binding documentation for the Broadcom DTE
>>> PTP clock driver.
>>>
>>> Signed-off-by: Arun Parameswaran 
>>> ---
>>>   Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt | 13
>>> +
>>>   1 file changed, 13 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
>>> b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
>>> new file mode 100644
>>> index 000..07590bc
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
>>> @@ -0,0 +1,13 @@
>>> +* Broadcom Digital Timing Engine(DTE) based PTP clock driver
>>
>> Bindings describe h/w, not drivers.
>>
>>> +
>>> +Required properties:
>>> +- compatible: should be "brcm,ptp-dte"
>>
>> Looks too generic. You need SoC specific compatible strings.
>
>
> Rob, could you please help me understand the use of adding SoC specific
> compatible strings.
> I still don't get it.
>
> It's my understanding that the SoC compatibility string is to future proof
> against bugs/incompatibilities
> between different versions of the hardware block due to integration issues
> or any other reason.
> You can then compare in your driver because the strings were already used in
> the dtb.
>
> That would make sense if you can't already differentiate what SoC you are
> running on.
> But the SoC is already specified in the root of the device tree in the
> compatible string?
> Why can't you just use of_machine_is_compatible inside your driver when
> needed?

Use of of_machine_is_compatible in drivers will result in the same
mess we had with machine_is_X defines pre-DT. It practically
guarantees that you must update the driver for a new SoC (with
fallback compatibles you don't). Plus the matching logic for
of_machine_is_compatible is open coded logic in every driver which is
worse IMO than having a standard match table.

>
> Please explain what I'm missing.  I see other drivers already following the
> of_machine_is_compatible
> approach and it makes more sense to me than adding SoC specific compatible
> strings into every
> driver.

If the IP blocks are all the same, you don't have to add them to any
drivers, just add fallback compatibles.

Rob

[PATCH] DLN2 module for ADC interface

[Jack Andersen]

Hello,

I've been having to blacklist the dln2 module in order to use Diolan's iffy
libusb-based "driver". I'd much rather use dln2, but the lack of ADC support
has been an issue for my robotics application.

I've extended the dln2 module with an additional platform driver to expose the
ADC using the IIO subsystem. It supports triggered buffering via the event
handle kept by dln2, as well as direct raw reads. The voltage scale is fixed
at 3.3v over 10-bits, since that appears to be the maximum resolution supported
by the hardware.

I've tested the module under 4.11.6 and everything appears to be stable.
However, this is my first patch, so it's possible I've missed something.

Jack Andersen (1):
  iio: adc: Add support for DLN2 ADC

 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/dln2-adc.c | 648 +
 drivers/mfd/dln2.c |  12 +
 4 files changed, 670 insertions(+)
 create mode 100644 drivers/iio/adc/dln2-adc.c

-- 
1.9.1

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

[Rob Herring]

On Tue, Jun 20, 2017 at 3:48 PM, Scott Branden
 wrote:
> Hi Rob,
>
>
> On 17-06-18 07:04 AM, Rob Herring wrote:
>>
>> On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote:
>>>
>>> Add device tree binding documentation for the Broadcom DTE
>>> PTP clock driver.
>>>
>>> Signed-off-by: Arun Parameswaran 
>>> ---
>>>   Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt | 13
>>> +
>>>   1 file changed, 13 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
>>> b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
>>> new file mode 100644
>>> index 000..07590bc
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
>>> @@ -0,0 +1,13 @@
>>> +* Broadcom Digital Timing Engine(DTE) based PTP clock driver
>>
>> Bindings describe h/w, not drivers.
>>
>>> +
>>> +Required properties:
>>> +- compatible: should be "brcm,ptp-dte"
>>
>> Looks too generic. You need SoC specific compatible strings.
>
>
> Rob, could you please help me understand the use of adding SoC specific
> compatible strings.
> I still don't get it.
>
> It's my understanding that the SoC compatibility string is to future proof
> against bugs/incompatibilities
> between different versions of the hardware block due to integration issues
> or any other reason.
> You can then compare in your driver because the strings were already used in
> the dtb.
>
> That would make sense if you can't already differentiate what SoC you are
> running on.
> But the SoC is already specified in the root of the device tree in the
> compatible string?
> Why can't you just use of_machine_is_compatible inside your driver when
> needed?

Use of of_machine_is_compatible in drivers will result in the same
mess we had with machine_is_X defines pre-DT. It practically
guarantees that you must update the driver for a new SoC (with
fallback compatibles you don't). Plus the matching logic for
of_machine_is_compatible is open coded logic in every driver which is
worse IMO than having a standard match table.

>
> Please explain what I'm missing.  I see other drivers already following the
> of_machine_is_compatible
> approach and it makes more sense to me than adding SoC specific compatible
> strings into every
> driver.

If the IP blocks are all the same, you don't have to add them to any
drivers, just add fallback compatibles.

Rob