date:20191017

Re: [PATCH v5 05/14] software node: clean up property_copy_string_array()

2019-10-17 Thread Andy Shevchenko

On Wed, Oct 16, 2019 at 10:00:59AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 16, 2019 at 10:53:00AM +0300, Andy Shevchenko wrote:
> > On Tue, Oct 15, 2019 at 11:12:11AM -0700, Dmitry Torokhov wrote:
> > > On Tue, Oct 15, 2019 at 03:07:26PM +0300, Andy Shevchenko wrote:

> > Yes, since property_set_pointer is called independently
> > on the type of the value.
> 
> We still call property_set_pointer() independently of the type of the
> value even with this patch. The point is that we do not set the pointer
> in property_copy_string_array(), so we only set the pointer once.
> 
> We used to have essentially for string arrays:
> 
>   copy data
>   set pointer in dst
>   get pointer from dst
>   set pointer in dst
> 
> With this patch we have:
> 
>   copy data
>   set pointer in dst

> > > This is confising and awkward and I believe it
> > > is cleaner for property_copy_string_array() to give a pointer to a copy
> > > of a string array, and then property_entry_copy_data() use it when
> > > handling the destination structure.
> > 
> > We probably need a 3rd opinion here.
> 
> I think I can still convince you ;)

Probably this is fine.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] drivers: mcb: use symbol namespaces

2019-10-17 Thread Johannes Thumshirn

On 16/10/2019 15:53, Greg KH wrote:
> I can take this now, into my -next tree.  I'll do so later this week
> unless you object.


Perfect, thanks.


-- 
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH] scripts/gdb: fix debugging modules on s390

2019-10-17 Thread Jan Kiszka

On 15.10.19 17:43, Ilya Leoshkevich wrote:
>> Am 15.10.2019 um 17:21 schrieb Jan Kiszka :
>>
>>> @@ -113,6 +113,12 @@ lx-symbols command."""
>>> if module_file:
>>> gdb.write("loading @{addr}: {filename}\n".format(
>>> addr=module_addr, filename=module_file))
>>> +if utils.is_target_arch('s390'):
>>> +# Module text is preceded by PLT stubs on s390.
>>> +module_arch = module['arch']
>>> +plt_offset = int(module_arch['plt_offset'])
>>> +plt_size = int(module_arch['plt_size'])
>>> +module_addr = hex(int(module_addr, 0) + plt_offset + 
>>> plt_size)
>>
>> Shouldn't we report the actual address above, ie. reorder this tuning
>> with the gdb.write?
> 
> That's a tough question. I thought about this, and the argument for
> showing the fixed up address is that if someone does the math with
> symbol offsets from e.g. objdump, the result will be consistent with
> what gdb shows.
> 
> On the other hand side, why would anyone do this? that's exactly what
> this gdb script is for. So showing the actual address at which the
> memory was allocated gives the user some additional information, and is
> also consistent with what cat /proc/modules would show.
> 
> At the end of the day, I don't have a strong opinion on this, so if you
> think it's better to show the fixed up address, I'll send a v2.

One of the original ideas of the printout was to provide the information
needed to reproduce potential issues manually. From that perspective,
the fixed-up address would the the thing to print.

If you think the vanilla address has some value as well, we could make
an s390-specifi printout of both values.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH] iommu/vt-d: Return the correct dma mask when we are bypassing the IOMMU

2019-10-17 Thread Christoph Hellwig

On Wed, Oct 16, 2019 at 03:15:52PM -0400, Arvind Sankar wrote:
> > > Reported-by: Arvind Sankar 
> > > Tested-by: Arvind Sankar 
> > > Originally-by: Christoph Hellwig 
> > > Signed-off-by: Christoph Hellwig 
> > > Fixed-by: Arvind Sankar 
> > > Signed-off-by: Arvind Sankar 
> > 
> > This patch looks good to me.
> > 
> > Reviewed-by: Lu Baolu 
> > 
> 
> Hi Christoph, will you be taking this through your dma-mapping branch?

Given this is a patch to intel-iommu I expect Joerg to pick it up.
But if he is fine with that I can also queue it up instead.

Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages()

2019-10-17 Thread Michal Hocko

On Thu 17-10-19 10:44:41, Anshuman Khandual wrote:
[...]
> Does this add-on documentation look okay ? Should we also mention about the
> possible reduction in chances of success during pfn block search for the
> non-power-of-two cases as the implicit alignment will probably turn out to
> be bigger than nr_pages itself ?
> 
>  * Requested nr_pages may or may not be power of two. The search for suitable
>  * memory range in a zone happens in nr_pages aligned pfn blocks. But in case
>  * when nr_pages is not power of two, an implicitly aligned pfn block search
>  * will happen which in turn will impact allocated memory block's alignment.
>  * In these cases, the size (i.e nr_pages) and the alignment of the allocated
>  * memory will be different. This problem does not exist when nr_pages is 
> power
>  * of two where the size and the alignment of the allocated memory will always
>  * be nr_pages.

I dunno, it sounds more complicated than really necessary IMHO. Callers
shouldn't really be bothered by memory blocks and other really deep
implementation details.. Wouldn't be the below sufficient?

The allocated memory is always aligned to a page boundary. If nr_pages
is a power of two then the alignement is guaranteed to be to the given
nr_pages (e.g. 1GB request would be aligned to 1GB).
-- 
Michal Hocko
SUSE Labs

Re: [tip: perf/core] perf trace: Introduce --filter for tracepoint events

2019-10-17 Thread Borislav Petkov

On Tue, Oct 15, 2019 at 05:31:43AM -, tip-bot2 for Arnaldo Carvalho de Melo 
wrote:
> The following commit has been merged into the perf/core branch of tip:
> 
> Commit-ID: d4097f1937f2242d0aa0a7c654d2159a6895e5c8
> Gitweb:
> https://git.kernel.org/tip/d4097f1937f2242d0aa0a7c654d2159a6895e5c8
> Author:Arnaldo Carvalho de Melo 
> AuthorDate:Tue, 08 Oct 2019 07:33:08 -03:00
> Committer: Arnaldo Carvalho de Melo 
> CommitterDate: Wed, 09 Oct 2019 11:23:52 -03:00
> 
> perf trace: Introduce --filter for tracepoint events
> 
> Similar to what is in 'perf record', works just like there:
> 
>   # perf trace -e msr:*
>328.297 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
>328.302 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
>328.306 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
>328.317 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
>328.322 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
>328.327 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
>328.331 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
>328.336 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
>328.340 :0/0 ^Cmsr:write_msr(msr: FS_BASE, val: 140240388381888)

I wonder if you guys can force this val:'s format to be always hex?
Because MSR values are a lot more "natural" in hex...

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[PATCH v3 3/6] dt-bindings: regulator: max77650: convert the binding document to yaml

2019-10-17 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

Convert the binding document for MAX77650 regulator module to YAML.

Signed-off-by: Bartosz Golaszewski 
---
 .../bindings/regulator/max77650-regulator.txt | 41 ---
 .../regulator/max77650-regulator.yaml | 31 ++
 2 files changed, 31 insertions(+), 41 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/regulator/max77650-regulator.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/max77650-regulator.yaml

diff --git a/Documentation/devicetree/bindings/regulator/max77650-regulator.txt 
b/Documentation/devicetree/bindings/regulator/max77650-regulator.txt
deleted file mode 100644
index f1cbe813c30f..
--- a/Documentation/devicetree/bindings/regulator/max77650-regulator.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Regulator driver for MAX77650 PMIC from Maxim Integrated.
-
-This module is part of the MAX77650 MFD device. For more details
-see Documentation/devicetree/bindings/mfd/max77650.txt.
-
-The regulator controller is represented as a sub-node of the PMIC node
-on the device tree.
-
-The device has a single LDO regulator and a SIMO buck-boost regulator with
-three independent power rails.
-
-Required properties:
-
-- compatible:  Must be "maxim,max77650-regulator"
-
-Each rail must be instantiated under the regulators subnode of the top PMIC
-node. Up to four regulators can be defined. For standard regulator properties
-refer to Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Available regulator compatible strings are: "ldo", "sbb0", "sbb1", "sbb2".
-
-Example:
-
-
-   regulators {
-   compatible = "maxim,max77650-regulator";
-
-   max77650_ldo: regulator@0 {
-   regulator-compatible = "ldo";
-   regulator-name = "max77650-ldo";
-   regulator-min-microvolt = <135>;
-   regulator-max-microvolt = <2937500>;
-   };
-
-   max77650_sbb0: regulator@1 {
-   regulator-compatible = "sbb0";
-   regulator-name = "max77650-sbb0";
-   regulator-min-microvolt = <80>;
-   regulator-max-microvolt = <1587500>;
-   };
-   };
diff --git 
a/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml
new file mode 100644
index ..a8770742836d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/max77650-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Regulator driver for MAX77650 PMIC from Maxim Integrated.
+
+maintainers:
+  - Bartosz Golaszewski 
+
+description: |
+  This module is part of the MAX77650 MFD device. For more details
+  see Documentation/devicetree/bindings/mfd/max77650.txt.
+
+  The regulator controller is represented as a sub-node of the PMIC node
+  on the device tree.
+
+  The device has a single LDO regulator and a SIMO buck-boost regulator with
+  three independent power rails.
+
+properties:
+  compatible:
+const: maxim,max77650-regulator
+
+patternProperties:
+  "^regulator@[0-3]$":
+$ref: "regulator.yaml#"
+
+required:
+  - compatible
-- 
2.23.0

[PATCH v3 0/6] dt-bindings: max77650: convert the device-tree bindings to yaml

2019-10-17 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

This series converts all DT binding documents for MAX77650 PMIC to YAML.

v1 -> v2:
- use upper case for abbreviations in commit messages

v2 -> v3:
- pull all example fragments into the binding document for the core MFD module
- fix all dt_binding_check errors
- add references to submodules to the main binding document
- drop the type for gpio-line-names
- drop the description for the interrupts property
- completely delete the previous txt files

Bartosz Golaszewski (6):
  dt-bindings: mfd: max77650: convert the binding document to yaml
  dt-bindings: input: max77650: convert the binding document to yaml
  dt-bindings: regulator: max77650: convert the binding document to yaml
  dt-bindings: power: max77650: convert the binding document to yaml
  dt-bindings: leds: max77650: convert the binding document to yaml
  MAINTAINERS: update the list of maintained files for max77650

 .../bindings/input/max77650-onkey.txt |  26 ---
 .../bindings/input/max77650-onkey.yaml|  35 
 .../bindings/leds/leds-max77650.txt   |  57 ---
 .../bindings/leds/leds-max77650.yaml  |  58 +++
 .../devicetree/bindings/mfd/max77650.txt  |  46 --
 .../devicetree/bindings/mfd/max77650.yaml | 151 ++
 .../power/supply/max77650-charger.txt |  28 
 .../power/supply/max77650-charger.yaml|  34 
 .../bindings/regulator/max77650-regulator.txt |  41 -
 .../regulator/max77650-regulator.yaml |  31 
 MAINTAINERS   |   4 +-
 11 files changed, 311 insertions(+), 200 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/input/max77650-onkey.txt
 create mode 100644 Documentation/devicetree/bindings/input/max77650-onkey.yaml
 delete mode 100644 Documentation/devicetree/bindings/leds/leds-max77650.txt
 create mode 100644 Documentation/devicetree/bindings/leds/leds-max77650.yaml
 delete mode 100644 Documentation/devicetree/bindings/mfd/max77650.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/max77650.yaml
 delete mode 100644 
Documentation/devicetree/bindings/power/supply/max77650-charger.txt
 create mode 100644 
Documentation/devicetree/bindings/power/supply/max77650-charger.yaml
 delete mode 100644 
Documentation/devicetree/bindings/regulator/max77650-regulator.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/max77650-regulator.yaml

-- 
2.23.0

[PATCH v3 2/6] dt-bindings: input: max77650: convert the binding document to yaml

2019-10-17 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

Convert the binding document for MAX77650 onkey module to YAML.

Signed-off-by: Bartosz Golaszewski 
---
 .../bindings/input/max77650-onkey.txt | 26 --
 .../bindings/input/max77650-onkey.yaml| 35 +++
 2 files changed, 35 insertions(+), 26 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/input/max77650-onkey.txt
 create mode 100644 Documentation/devicetree/bindings/input/max77650-onkey.yaml

diff --git a/Documentation/devicetree/bindings/input/max77650-onkey.txt 
b/Documentation/devicetree/bindings/input/max77650-onkey.txt
deleted file mode 100644
index 477dc74f452a..
--- a/Documentation/devicetree/bindings/input/max77650-onkey.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Onkey driver for MAX77650 PMIC from Maxim Integrated.
-
-This module is part of the MAX77650 MFD device. For more details
-see Documentation/devicetree/bindings/mfd/max77650.txt.
-
-The onkey controller is represented as a sub-node of the PMIC node on
-the device tree.
-
-Required properties:
-
-- compatible:  Must be "maxim,max77650-onkey".
-
-Optional properties:
-- linux,code:  The key-code to be reported when the key is pressed.
-   Defaults to KEY_POWER.
-- maxim,onkey-slide:   The system's button is a slide switch, not the default
-   push button.
-
-Example:
-
-
-   onkey {
-   compatible = "maxim,max77650-onkey";
-   linux,code = ;
-   maxim,onkey-slide;
-   };
diff --git a/Documentation/devicetree/bindings/input/max77650-onkey.yaml 
b/Documentation/devicetree/bindings/input/max77650-onkey.yaml
new file mode 100644
index ..2f2e0b6ebbbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/max77650-onkey.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/max77650-onkey.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Onkey driver for MAX77650 PMIC from Maxim Integrated.
+
+maintainers:
+  - Bartosz Golaszewski 
+
+description: |
+  This module is part of the MAX77650 MFD device. For more details
+  see Documentation/devicetree/bindings/mfd/max77650.yaml.
+
+  The onkey controller is represented as a sub-node of the PMIC node on
+  the device tree.
+
+properties:
+  compatible:
+const: maxim,max77650-onkey
+
+  linux,code:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  The key-code to be reported when the key is pressed. Defaults
+  to KEY_POWER.
+
+  maxim,onkey-slide:
+$ref: /schemas/types.yaml#/definitions/flag
+description:
+  The system's button is a slide switch, not the default push button.
+
+required:
+  - compatible
-- 
2.23.0

[PATCH v3 4/6] dt-bindings: power: max77650: convert the binding document to yaml

2019-10-17 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

Convert the binding document for MAX77650 charger module to YAML.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Sebastian Reichel 
---
 .../power/supply/max77650-charger.txt | 28 ---
 .../power/supply/max77650-charger.yaml| 34 +++
 2 files changed, 34 insertions(+), 28 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/power/supply/max77650-charger.txt
 create mode 100644 
Documentation/devicetree/bindings/power/supply/max77650-charger.yaml

diff --git 
a/Documentation/devicetree/bindings/power/supply/max77650-charger.txt 
b/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
deleted file mode 100644
index e6d0fb6ff94e..
--- a/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Battery charger driver for MAX77650 PMIC from Maxim Integrated.
-
-This module is part of the MAX77650 MFD device. For more details
-see Documentation/devicetree/bindings/mfd/max77650.txt.
-
-The charger is represented as a sub-node of the PMIC node on the device tree.
-
-Required properties:
-
-- compatible:  Must be "maxim,max77650-charger"
-
-Optional properties:
-
-- input-voltage-min-microvolt: Minimum CHGIN regulation voltage. Must be one
-   of: 400, 410, 420, 430,
-   440, 450, 460, 470.
-- input-current-limit-microamp:CHGIN input current limit (in 
microamps). Must
-   be one of: 95000, 19, 285000, 38,
-   475000.
-
-Example:
-
-
-   charger {
-   compatible = "maxim,max77650-charger";
-   input-voltage-min-microvolt = <420>;
-   input-current-limit-microamp = <285000>;
-   };
diff --git 
a/Documentation/devicetree/bindings/power/supply/max77650-charger.yaml 
b/Documentation/devicetree/bindings/power/supply/max77650-charger.yaml
new file mode 100644
index ..a48054cc87cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/max77650-charger.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/max77650-charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Battery charger driver for MAX77650 PMIC from Maxim Integrated.
+
+maintainers:
+  - Bartosz Golaszewski 
+
+description: |
+  This module is part of the MAX77650 MFD device. For more details
+  see Documentation/devicetree/bindings/mfd/max77650.txt.
+
+  The charger is represented as a sub-node of the PMIC node on the device tree.
+
+properties:
+  compatible:
+const: maxim,max77650-charger
+
+  input-voltage-min-microvolt:
+description:
+  Minimum CHGIN regulation voltage.
+enum: [ 400, 410, 420, 430,
+440, 450, 460, 470 ]
+
+  input-current-limit-microamp:
+description:
+  CHGIN input current limit (in microamps).
+enum: [ 95000, 19, 285000, 38, 475000 ]
+
+required:
+  - compatible
-- 
2.23.0

[PATCH v3 6/6] MAINTAINERS: update the list of maintained files for max77650

2019-10-17 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

The DT bindings for MAX77650 MFD have now been converted to YAML.
Update the MAINTAINERS entry for this set of drivers.

Signed-off-by: Bartosz Golaszewski 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a69e6db80c79..c05e6fd6aedb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9903,8 +9903,8 @@ MAXIM MAX77650 PMIC MFD DRIVER
 M: Bartosz Golaszewski 
 L: linux-kernel@vger.kernel.org
 S: Maintained
-F: Documentation/devicetree/bindings/*/*max77650.txt
-F: Documentation/devicetree/bindings/*/max77650*.txt
+F: Documentation/devicetree/bindings/*/*max77650.yaml
+F: Documentation/devicetree/bindings/*/max77650*.yaml
 F: include/linux/mfd/max77650.h
 F: drivers/mfd/max77650.c
 F: drivers/regulator/max77650-regulator.c
-- 
2.23.0

[PATCH v3 1/6] dt-bindings: mfd: max77650: convert the binding document to yaml

2019-10-17 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

Convert the binding document for MAX77650 core MFD module to YAML.

Signed-off-by: Bartosz Golaszewski 
---
 .../devicetree/bindings/mfd/max77650.txt  |  46 --
 .../devicetree/bindings/mfd/max77650.yaml | 151 ++
 2 files changed, 151 insertions(+), 46 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/max77650.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/max77650.yaml

diff --git a/Documentation/devicetree/bindings/mfd/max77650.txt 
b/Documentation/devicetree/bindings/mfd/max77650.txt
deleted file mode 100644
index b529d8d19335..
--- a/Documentation/devicetree/bindings/mfd/max77650.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-MAX77650 ultra low-power PMIC from Maxim Integrated.
-
-Required properties:

-- compatible:  Must be "maxim,max77650"
-- reg: I2C device address.
-- interrupts:  The interrupt on the parent the controller is
-   connected to.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells:Must be <2>.
-
-- gpio-controller: Marks the device node as a gpio controller.
-- #gpio-cells: Must be <2>. The first cell is the pin number and
-   the second cell is used to specify the gpio active
-   state.
-
-Optional properties:
-
-gpio-line-names:   Single string containing the name of the GPIO line.
-
-The GPIO-controller module is represented as part of the top-level PMIC
-node. The device exposes a single GPIO line.
-
-For device-tree bindings of other sub-modules (regulator, power supply,
-LEDs and onkey) refer to the binding documents under the respective
-sub-system directories.
-
-For more details on GPIO bindings, please refer to the generic GPIO DT
-binding document .
-
-Example:
-
-
-   pmic@48 {
-   compatible = "maxim,max77650";
-   reg = <0x48>;
-
-   interrupt-controller;
-   interrupt-parent = <&gpio2>;
-   #interrupt-cells = <2>;
-   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
-
-   gpio-controller;
-   #gpio-cells = <2>;
-   gpio-line-names = "max77650-charger";
-   };
diff --git a/Documentation/devicetree/bindings/mfd/max77650.yaml 
b/Documentation/devicetree/bindings/mfd/max77650.yaml
new file mode 100644
index ..66a447e1cf56
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77650.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/max77650.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX77650 ultra low-power PMIC from Maxim Integrated.
+
+maintainers:
+  - Bartosz Golaszewski 
+
+description: |
+  This document describes the DT properties of the core MFD controller.
+
+  The GPIO-controller module is represented as part of the top-level PMIC
+  node. The device exposes a single GPIO line.
+
+  For device-tree bindings of other sub-modules (regulator, power supply,
+  LEDs and onkey) refer to the binding documents under the respective
+  sub-system directories.
+
+  For more details on GPIO bindings, please refer to the generic GPIO DT
+  binding document .
+
+properties:
+  compatible:
+const: maxim,max77650
+
+  reg:
+description:
+  I2C device address.
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+const: 2
+description:
+  The first cell is the IRQ number, the second cell is the trigger type.
+
+  gpio-controller: true
+
+  "#gpio-cells":
+const: 2
+description:
+  The first cell is the pin number and the second cell is used to specify
+  the gpio active state.
+
+  gpio-line-names:
+maxItems: 1
+description:
+  Single string containing the name of the GPIO line.
+
+  regulators:
+$ref: ../regulator/max77650-regulator.yaml
+
+  charger:
+$ref: ../power/supply/max77650-charger.yaml
+
+  leds:
+$ref: ../leds/leds-max77650.yaml
+
+  onkey:
+$ref: ../input/max77650-onkey.yaml
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - interrupt-controller
+  - "#interrupt-cells"
+  - gpio-controller
+  - "#gpio-cells"
+
+examples:
+  - |
+#include 
+#include 
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+pmic@48 {
+compatible = "maxim,max77650";
+reg = <0x48>;
+
+interrupt-controller;
+interrupt-parent = <&gpio2>;
+#interrupt-cells = <2>;
+interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+gpio-controller;
+#gpio-cells = <2>;
+gpio-line-names = "max77650-charger";
+
+regulators {
+compatible = "maxim,max77650-regulator";
+
+max77650_ldo: regulator@0 {
+

[PATCH v3 5/6] dt-bindings: leds: max77650: convert the binding document to yaml

2019-10-17 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

Convert the binding document for MAX77650 LED module to YAML.

Signed-off-by: Bartosz Golaszewski 
---
 .../bindings/leds/leds-max77650.txt   | 57 --
 .../bindings/leds/leds-max77650.yaml  | 58 +++
 2 files changed, 58 insertions(+), 57 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/leds/leds-max77650.txt
 create mode 100644 Documentation/devicetree/bindings/leds/leds-max77650.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-max77650.txt 
b/Documentation/devicetree/bindings/leds/leds-max77650.txt
deleted file mode 100644
index 3a67115cc1da..
--- a/Documentation/devicetree/bindings/leds/leds-max77650.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-LED driver for MAX77650 PMIC from Maxim Integrated.
-
-This module is part of the MAX77650 MFD device. For more details
-see Documentation/devicetree/bindings/mfd/max77650.txt.
-
-The LED controller is represented as a sub-node of the PMIC node on
-the device tree.
-
-This device has three current sinks.
-
-Required properties:
-
-- compatible:  Must be "maxim,max77650-led"
-- #address-cells:  Must be <1>.
-- #size-cells: Must be <0>.
-
-Each LED is represented as a sub-node of the LED-controller node. Up to
-three sub-nodes can be defined.
-
-Required properties of the sub-node:
-
-
-- reg: Must be <0>, <1> or <2>.
-
-Optional properties of the sub-node:
-
-
-- label:   See Documentation/devicetree/bindings/leds/common.txt
-- linux,default-trigger: See Documentation/devicetree/bindings/leds/common.txt
-
-For more details, please refer to the generic GPIO DT binding document
-.
-
-Example:
-
-
-   leds {
-   compatible = "maxim,max77650-led";
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   led@0 {
-   reg = <0>;
-   label = "blue:usr0";
-   };
-
-   led@1 {
-   reg = <1>;
-   label = "red:usr1";
-   linux,default-trigger = "heartbeat";
-   };
-
-   led@2 {
-   reg = <2>;
-   label = "green:usr2";
-   };
-   };
diff --git a/Documentation/devicetree/bindings/leds/leds-max77650.yaml 
b/Documentation/devicetree/bindings/leds/leds-max77650.yaml
new file mode 100644
index ..5a1e256185bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-max77650.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-max77650.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LED driver for MAX77650 PMIC from Maxim Integrated.
+
+maintainers:
+  - Bartosz Golaszewski 
+
+description: |
+  This module is part of the MAX77650 MFD device. For more details
+  see Documentation/devicetree/bindings/mfd/max77650.txt.
+
+  The LED controller is represented as a sub-node of the PMIC node on
+  the device tree.
+
+  This device has three current sinks.
+
+properties:
+  compatible:
+const: maxim,max77650-led
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^led@[0-2]$":
+type: object
+description: |
+  Properties for a single LED.
+
+properties:
+  reg:
+description:
+  Index of the LED.
+maxItems: 1
+minimum: 0
+maximum: 2
+
+  label:
+$ref: "/schemas/types.yaml#/definitions/string"
+description:
+  The label of this LED.
+
+  linux,default-trigger:
+$ref: "/schemas/types.yaml#/definitions/string"
+description:
+  String defining the default trigger assigned to this LED.
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
-- 
2.23.0

Re: [PATCH v5 0/4] Fix MTRR bug for intel-lpss-pci

2019-10-17 Thread Andy Shevchenko

On Wed, Oct 16, 2019 at 03:06:25PM -0600, Tuowen Zhao wrote:
> Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
> in MTRR. This will cause the system to hang during boot. If possible,
> this bug could be corrected with a firmware update.
> 
> Previous version: https://lkml.org/lkml/2019/10/14/575
> 
> Changes from previous version:
> 
>  * implement ioremap_uc for sparc64
>  * split docs changes to not CC stable (doc location moved since 5.3)
> 

It forgot to explicitly mention through which tree is supposed to go.
I think it's MFD one, correct?

Other than above remark, the series looks good to me, thanks!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 10/14] software node: rename is_array to is_inline

2019-10-17 Thread Andy Shevchenko

On Wed, Oct 16, 2019 at 09:54:30AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 16, 2019 at 10:59:40AM +0300, Andy Shevchenko wrote:
> > On Tue, Oct 15, 2019 at 11:22:06AM -0700, Dmitry Torokhov wrote:
> > > On Mon, Oct 14, 2019 at 10:37:20AM +0300, Andy Shevchenko wrote:
> > > > On Fri, Oct 11, 2019 at 04:07:17PM -0700, Dmitry Torokhov wrote:

> > > > 'stored inline' -> 'embedded in the &struct...' ?
> > > 
> > > I was trying to have a link "stored inline" -> "is_inline".
> > > 
> > > Do we want to change the flag to be "is_embedded"?
> > 
> > In dictionaries I have
> > 
> > embedded <-> unilateral
> 
> Are you trying to show synonym or antonym here? But I am pretty sure
> "unilateral" is either.

Antonyms. The 'unilateral' is marked as so in the dictionary.

> Antonyms for our use of "embedded" are likely "detached" or
> "disconnected".
> 
> > inline <-> ???
> 
> "out of line" but I still believe "stored separately" explains precisely
> what we have here.

No, 'out of line' is idiom with a special meaning.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] mm, soft-offline: convert parameter to pfn

2019-10-17 Thread David Hildenbrand


On 17.10.19 01:47, Naoya Horiguchi wrote:

On Wed, Oct 16, 2019 at 10:57:57AM +0200, David Hildenbrand wrote:

On 16.10.19 10:54, Naoya Horiguchi wrote:

On Wed, Oct 16, 2019 at 10:34:52AM +0200, David Hildenbrand wrote:

On 16.10.19 10:27, Naoya Horiguchi wrote:

On Wed, Oct 16, 2019 at 09:56:19AM +0200, David Hildenbrand wrote:

On 16.10.19 09:09, Naoya Horiguchi wrote:

Hi,

I wrote a simple cleanup for parameter of soft_offline_page(),
based on thread https://lkml.org/lkml/2019/10/11/57.

I know that we need more cleanup on hwpoison-inject, but I think
that will be mentioned in re-write patchset Oscar is preparing now.
So let me shared only this part as a separate one now.

...


I think you should rebase that patch on linux-next (where the
pfn_to_online_page() check is in place). I assume you'll want to move the
pfn_to_online_page() check into soft_offline_page() then as well?


I rebased to next-20191016. And yes, we will move pfn_to_online_page()
into soft offline code.  It seems that we can also move pfn_valid(),
but is simply moving like below good enough for you?


At least I can't am the patch to current next/master (due to
pfn_to_online_page()).


Could also be that my "git am" skills failed as the mail was not a
proper patch itself :)


Sorry for the inconvenience, my company email system breaks original
message by introducing quoted-printable format ('=20' or '=3D').
Most mail client usually handles it but git-am doesn't.
I give up using it and send via smtp.gmail.com.


@@ -1877,11 +1877,17 @@ static int soft_offline_free_page(struct page *page)
   * This is not a 100% solution for all memory, but tries to be
   * ``good enough'' for the majority of memory.
   */
-int soft_offline_page(struct page *page, int flags)
+int soft_offline_page(unsigned long pfn, int flags)
  {
int ret;
-   unsigned long pfn = page_to_pfn(page);
+   struct page *page;
+   if (!pfn_valid(pfn))
+   return -ENXIO;
+   /* Only online pages can be soft-offlined (esp., not ZONE_DEVICE). */
+   page = pfn_to_online_page(pfn);
+   if (!page)
+   return -EIO;
if (is_zone_device_page(page)) {


-> this is now no longer possible! So you can drop the whole if
(is_zone_device) case


OK, thanks. I updated it.

Thanks,
Naoya Horiguchi
---
 From 5faf227839b578726fe7f5ff414a153abb3b3a31 Mon Sep 17 00:00:00 2001
From: Naoya Horiguchi 
Date: Thu, 17 Oct 2019 08:40:53 +0900
Subject: [PATCH] mm, soft-offline: convert parameter to pfn

Currently soft_offline_page() receives struct page, and its sibling
memory_failure() receives pfn. This discrepancy looks weird and makes
precheck on pfn validity tricky. So let's align them.

Signed-off-by: Naoya Horiguchi 
---
  drivers/base/memory.c |  7 +--
  include/linux/mm.h|  2 +-
  mm/madvise.c  |  2 +-
  mm/memory-failure.c   | 19 +--
  4 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 55907c27075b..a757d9ed88a7 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -538,12 +538,7 @@ static ssize_t soft_offline_page_store(struct device *dev,
if (kstrtoull(buf, 0, &pfn) < 0)
return -EINVAL;
pfn >>= PAGE_SHIFT;
-   if (!pfn_valid(pfn))
-   return -ENXIO;
-   /* Only online pages can be soft-offlined (esp., not ZONE_DEVICE). */
-   if (!pfn_to_online_page(pfn))
-   return -EIO;
-   ret = soft_offline_page(pfn_to_page(pfn), 0);
+   ret = soft_offline_page(pfn, 0);
return ret == 0 ? count : ret;
  }
  
diff --git a/include/linux/mm.h b/include/linux/mm.h

index 44d058723db9..fd360d208346 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2794,7 +2794,7 @@ extern int sysctl_memory_failure_early_kill;
  extern int sysctl_memory_failure_recovery;
  extern void shake_page(struct page *p, int access);
  extern atomic_long_t num_poisoned_pages __read_mostly;
-extern int soft_offline_page(struct page *page, int flags);
+extern int soft_offline_page(unsigned long pfn, int flags);
  
  
  /*

diff --git a/mm/madvise.c b/mm/madvise.c
index 2be9f3fdb05e..99dd06fecfa9 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -887,7 +887,7 @@ static int madvise_inject_error(int behavior,
pr_info("Soft offlining pfn %#lx at process virtual address 
%#lx\n",
pfn, start);
  
-			ret = soft_offline_page(page, MF_COUNT_INCREASED);

+   ret = soft_offline_page(pfn, MF_COUNT_INCREASED);
if (ret)
return ret;
continue;
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 05c8c6df25e6..af2712004a4d 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1476,7 +1476,7 @@ static void memory_failure_work_func(struct work_struct 
*work)
if (!gotten)
br

[PATCH] use devm_platform_ioremap_resource() for irqchip drivers

2019-10-17 Thread Daode Huang

From: Daode Huang 

Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together

Signed-off-by: Daode Huang 
---
 drivers/irqchip/irq-mvebu-icu.c   | 3 +--
 drivers/irqchip/irq-mvebu-pic.c   | 3 +--
 drivers/irqchip/irq-stm32-exti.c  | 3 +--
 drivers/irqchip/irq-ti-sci-inta.c | 3 +--
 drivers/irqchip/irq-ts4800.c  | 3 +--
 5 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/irqchip/irq-mvebu-icu.c b/drivers/irqchip/irq-mvebu-icu.c
index 547045d..ddf9b0d 100644
--- a/drivers/irqchip/irq-mvebu-icu.c
+++ b/drivers/irqchip/irq-mvebu-icu.c
@@ -357,8 +357,7 @@ static int mvebu_icu_probe(struct platform_device *pdev)
 
icu->dev = &pdev->dev;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   icu->base = devm_ioremap_resource(&pdev->dev, res);
+   icu->base = devm_platform_ioremap_resource(pdev, res);
if (IS_ERR(icu->base)) {
dev_err(&pdev->dev, "Failed to map icu base address.\n");
return PTR_ERR(icu->base);
diff --git a/drivers/irqchip/irq-mvebu-pic.c b/drivers/irqchip/irq-mvebu-pic.c
index eec6395..0c3520d 100644
--- a/drivers/irqchip/irq-mvebu-pic.c
+++ b/drivers/irqchip/irq-mvebu-pic.c
@@ -130,8 +130,7 @@ static int mvebu_pic_probe(struct platform_device *pdev)
if (!pic)
return -ENOMEM;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   pic->base = devm_ioremap_resource(&pdev->dev, res);
+   pic->base = devm_platform_ioremap_resource(pdev, res);
if (IS_ERR(pic->base))
return PTR_ERR(pic->base);
 
diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
index e00f2fa..7f5500e 100644
--- a/drivers/irqchip/irq-stm32-exti.c
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -849,8 +849,7 @@ static int stm32_exti_probe(struct platform_device *pdev)
if (!host_data->chips_data)
return -ENOMEM;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   host_data->base = devm_ioremap_resource(dev, res);
+   host_data->base = devm_platform_ioremap_resource(pdev, res);
if (IS_ERR(host_data->base)) {
dev_err(dev, "Unable to map registers\n");
return PTR_ERR(host_data->base);
diff --git a/drivers/irqchip/irq-ti-sci-inta.c 
b/drivers/irqchip/irq-ti-sci-inta.c
index ef4d625..d2ad3cc 100644
--- a/drivers/irqchip/irq-ti-sci-inta.c
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -567,8 +567,7 @@ static int ti_sci_inta_irq_domain_probe(struct 
platform_device *pdev)
return PTR_ERR(inta->global_event);
}
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   inta->base = devm_ioremap_resource(dev, res);
+   inta->base = devm_platform_ioremap_resource(pdev, res);
if (IS_ERR(inta->base))
return -ENODEV;
 
diff --git a/drivers/irqchip/irq-ts4800.c b/drivers/irqchip/irq-ts4800.c
index 2325fb3..f1cefa9 100644
--- a/drivers/irqchip/irq-ts4800.c
+++ b/drivers/irqchip/irq-ts4800.c
@@ -101,8 +101,7 @@ static int ts4800_ic_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   data->base = devm_ioremap_resource(&pdev->dev, res);
+   data->base = devm_platform_ioremap_resource(pdev, res);
if (IS_ERR(data->base))
return PTR_ERR(data->base);
 
-- 
2.8.1

[GIT PULL] GPIO fixes for v5.4 take two

2019-10-17 Thread Linus Walleij

Hi Linus,

here are some GPIO fixes, pertaining to Intel SoCs.

Details in the signed tag as usual.

Please pull it in!

Yours,
Linus Walleij

The following changes since commit 4f5cafb5cb8471e54afdc9054d973535614f7675:

  Linux 5.4-rc3 (2019-10-13 16:37:36 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-v5.4-3

for you to fetch changes up to 75e99bf5ed8fa74bc80d693d8e0a24eeaa38202b:

  gpio: lynxpoint: set default handler to be handle_bad_irq()
(2019-10-15 01:19:05 +0200)


GPIO fixes for the v5.4 series

The fixes pertain to a problem with initializing the Intel GPIO
irqchips when adding gpiochips, Andy fixed it up elegantly by
adding a hardware initialization callback to the struct
gpio_irq_chip so let's use this. Tested and verified on the
target hardware.


Andy Shevchenko (6):
  gpio: merrifield: Restore use of irq_base
  gpiolib: Initialize the hardware with a callback
  gpio: intel-mid: Move hardware initialization to callback
  gpio: lynxpoint: Move hardware initialization to callback
  gpio: merrifield: Move hardware initialization to callback
  gpio: lynxpoint: set default handler to be handle_bad_irq()

 drivers/gpio/gpio-intel-mid.c  |  9 ++---
 drivers/gpio/gpio-lynxpoint.c  | 10 ++
 drivers/gpio/gpio-merrifield.c |  9 ++---
 drivers/gpio/gpiolib.c | 22 +-
 include/linux/gpio/driver.h|  8 
 5 files changed, 47 insertions(+), 11 deletions(-)

Re: [PATCH v4 2/2] ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound to a driver

2019-10-17 Thread Takashi Iwai

On Mon, 07 Oct 2019 20:49:56 +0200,
Kai-Heng Feng wrote:
> 
> Hi Takashi,
> 
> > On Sep 25, 2019, at 19:32, Kai-Heng Feng  
> > wrote:
> > 
> > Nvidia proprietary driver doesn't support runtime power management, so
> > when a user only wants to use the integrated GPU, it's a common practice
> > to let dGPU not to bind any driver, and let its upstream port to be
> > runtime suspended. At the end of runtime suspension the port uses
> > platform power management to disable power through _OFF method of power
> > resource, which is listed by _PR3.
> > 
> > After commit b516ea586d71 ("PCI: Enable NVIDIA HDA controllers"), when
> > the dGPU comes with an HDA function, the HDA won't be suspended if the
> > dGPU is unbound, so the power resource can't be turned off by its
> > upstream port driver.
> > 
> > Commit 37a3a98ef601 ("ALSA: hda - Enable runtime PM only for
> > discrete GPU") only allows HDA to be runtime suspended once GPU is
> > bound, to keep APU's HDA working.
> > 
> > However, HDA on dGPU isn't that useful if dGPU is not bound to any
> > driver.  So let's relax the runtime suspend requirement for dGPU's HDA
> > function, to disable the power source to save lots of power.
> > 
> > BugLink: https://bugs.launchpad.net/bugs/1840835
> > Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers")
> > Signed-off-by: Kai-Heng Feng 
> 
> Do you still have any concern on this patch?
> Please merge [v5 1/2] and this patch [v4 2/2] if you think it's good.

Sorry for the late reply, as I've been off for a few weeks.
Now I applied both patches for 5.4.


Thanks!

Takashi

> 
> Thanks!
> 
> Kai-Heng
> 
> > ---
> > v4:
> > - Find upstream port, it's callee's responsibility now.
> > v3:
> > - Make changelog more clear.
> > v2:
> > - Change wording.
> > - Rebase to Tiwai's branch.
> > sound/pci/hda/hda_intel.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> > index 240f4ca76391..e63b871343e5 100644
> > --- a/sound/pci/hda/hda_intel.c
> > +++ b/sound/pci/hda/hda_intel.c
> > @@ -1280,11 +1280,17 @@ static void init_vga_switcheroo(struct azx *chip)
> > {
> > struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
> > struct pci_dev *p = get_bound_vga(chip->pci);
> > +   struct pci_dev *parent;
> > if (p) {
> > dev_info(chip->card->dev,
> >  "Handle vga_switcheroo audio client\n");
> > hda->use_vga_switcheroo = 1;
> > -   chip->bus.keep_power = 1; /* cleared in either gpu_bound op or 
> > codec probe */
> > +
> > +   /* cleared in either gpu_bound op or codec probe, or when its
> > +* upstream port has _PR3 (i.e. dGPU).
> > +*/
> > +   parent = pci_upstream_bridge(p);
> > +   chip->bus.keep_power = parent ? !pci_pr3_present(parent) : 1;
> > chip->driver_caps |= AZX_DCAPS_PM_RUNTIME;
> > pci_dev_put(p);
> > }
> > -- 
> > 2.17.1
> > 
> 
>

[PATCH v4 0/2] mtd: spi-nor: cadence-quadspi: Disable the DAC and Autopoll for Intel LGM SoC

2019-10-17 Thread Ramuthevar,Vadivel MuruganX

On Intel Lightning Mountain SoCs QSPI controller do not use auto-poll
and Direct Access Controller (DAC).

Thanks vignesh for your time to review the patch.
The following comments are addressed..
changes from v3:
- commit messages are updated in both the patches
- moved cqspi_disable_auto_poll() in cqspi_controller_init()
- moved the check quirks & CQSPI_DISABLE_DAC_MODE))> in 
cqspi_setup_flash()
- introduced cqspi->auto_poll variable instead of f_pdata->use_direct_mode for 
auto_poll patch 
  
Ramuthevar Vadivel Murugan (2):
  mtd: spi-nor: cadence-quadspi: Disable the DAC for Intel LGM SoC
  - This patch adds a quirk to disable the Direct Access Controller
for data transfer instead it uses indirect data transfer.   

  mtd: spi-nor: cadence-quadspi: Disable the auto-poll for Intel LGM SoC
  - This patch disables auto polling when direct access mode is disabled

 drivers/mtd/spi-nor/Kconfig   |  2 +-
 drivers/mtd/spi-nor/cadence-quadspi.c | 55 +++
 2 files changed, 50 insertions(+), 7 deletions(-)

-- 
2.11.0

[PATCH v4 2/2] mtd: spi-nor: cadence-quadspi: Disable the auto-poll for Intel LGM SoC

2019-10-17 Thread Ramuthevar,Vadivel MuruganX

From: Ramuthevar Vadivel Murugan 

On Intel Lightning Mountain SoCs QSPI controller do not use auto-poll.
This patch disables auto polling when direct access mode is disabled

Signed-off-by: Ramuthevar Vadivel Murugan 

---
 drivers/mtd/spi-nor/cadence-quadspi.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 0ad076eaa81b..c2333f0473e3 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -88,6 +88,7 @@ struct cqspi_st {
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
+   boolauto_poll;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
 };
 
@@ -136,6 +137,8 @@ struct cqspi_driver_platdata {
 #define CQSPI_REG_RD_INSTR_TYPE_DATA_MASK  0x3
 #define CQSPI_REG_RD_INSTR_DUMMY_MASK  0x1F
 
+#define CQSPI_REG_WR_COMPLETION_CTRL   0x38
+#define CQSPI_REG_WR_COMPLETION_DISABLE_AUTO_POLL  BIT(14)
 #define CQSPI_REG_WR_INSTR 0x08
 #define CQSPI_REG_WR_INSTR_OPCODE_LSB  0
 #define CQSPI_REG_WR_INSTR_TYPE_ADDR_LSB   12
@@ -1175,6 +1178,18 @@ static int cqspi_of_get_pdata(struct platform_device 
*pdev)
return 0;
 }
 
+static int cqspi_disable_auto_poll(struct cqspi_st *cqspi)
+{
+   void __iomem *reg_base = cqspi->iobase;
+   unsigned int reg;
+
+   reg = readl(reg_base + CQSPI_REG_WR_COMPLETION_CTRL);
+   reg |= CQSPI_REG_WR_COMPLETION_DISABLE_AUTO_POLL;
+   writel(reg, reg_base + CQSPI_REG_WR_COMPLETION_CTRL);
+
+   return 0;
+}
+
 static void cqspi_controller_init(struct cqspi_st *cqspi)
 {
u32 reg;
@@ -1206,6 +1221,10 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
 
+   /* Disable auto-polling */
+   if (!cqspi->auto_poll)
+   cqspi_disable_auto_poll(cqspi);
+
cqspi_controller_enable(cqspi, 1);
 }
 
@@ -1421,6 +1440,9 @@ static int cqspi_probe(struct platform_device *pdev)
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
   cqspi->master_ref_clk_hz);
 
+   if (ddata && (ddata->quirks & CQSPI_DISABLE_DAC_MODE))
+   cqspi->auto_poll = false;
+
ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
   pdev->name, cqspi);
if (ret) {
-- 
2.11.0

[PATCH v4 1/2] mtd: spi-nor: cadence-quadspi: Disable the DAC for Intel LGM SoC

2019-10-17 Thread Ramuthevar,Vadivel MuruganX

From: Ramuthevar Vadivel Murugan 

On Intel Lightning Mountain(LGM) SoCs QSPI controller do not use
Direct Access Controller(DAC).

This patch adds a quirk to disable the Direct Access Controller
for data transfer instead it uses indirect data transfer.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
 drivers/mtd/spi-nor/Kconfig   |  2 +-
 drivers/mtd/spi-nor/cadence-quadspi.c | 33 +++--
 2 files changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index f237fcdf7f86..ef1aa369c2e3 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -36,7 +36,7 @@ config SPI_ASPEED_SMC
 
 config SPI_CADENCE_QUADSPI
tristate "Cadence Quad SPI controller"
-   depends on OF && (ARM || ARM64 || COMPILE_TEST)
+   depends on OF && (ARM || ARM64 || COMPILE_TEST || X86)
help
  Enable support for the Cadence Quad SPI Flash controller.
 
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 7bef63947b29..0ad076eaa81b 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -34,6 +34,7 @@
 
 /* Quirks */
 #define CQSPI_NEEDS_WR_DELAY   BIT(0)
+#define CQSPI_DISABLE_DAC_MODE BIT(1)
 
 /* Capabilities mask */
 #define CQSPI_BASE_HWCAPS_MASK \
@@ -600,6 +601,13 @@ static int cqspi_write_setup(struct spi_nor *nor)
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
 
+   /* Disable direct access controller */
+   if (!f_pdata->use_direct_mode) {
+   reg = readl(reg_base + CQSPI_REG_CONFIG);
+   reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+   writel(reg, reg_base + CQSPI_REG_CONFIG);
+   }
+
/* Set opcode. */
reg = nor->program_opcode << CQSPI_REG_WR_INSTR_OPCODE_LSB;
writel(reg, reg_base + CQSPI_REG_WR_INSTR);
@@ -1292,12 +1300,16 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, 
struct device_node *np)
f_pdata->registered = true;
 
if (mtd->size <= cqspi->ahb_size) {
-   f_pdata->use_direct_mode = true;
-   dev_dbg(nor->dev, "using direct mode for %s\n",
-   mtd->name);
-
-   if (!cqspi->rx_chan)
-   cqspi_request_mmap_dma(cqspi);
+   if (ddata && (ddata->quirks & CQSPI_DISABLE_DAC_MODE)) {
+   f_pdata->use_direct_mode = false;
+   } else {
+   f_pdata->use_direct_mode = true;
+   dev_dbg(nor->dev, "using direct mode for %s\n",
+   mtd->name);
+
+   if (!cqspi->rx_chan)
+   cqspi_request_mmap_dma(cqspi);
+   }
}
}
 
@@ -1501,6 +1513,11 @@ static const struct cqspi_driver_platdata am654_ospi = {
.quirks = CQSPI_NEEDS_WR_DELAY,
 };
 
+static const struct cqspi_driver_platdata intel_lgm_qspi = {
+   .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+   .quirks = CQSPI_DISABLE_DAC_MODE,
+};
+
 static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
@@ -1514,6 +1531,10 @@ static const struct of_device_id cqspi_dt_ids[] = {
.compatible = "ti,am654-ospi",
.data = &am654_ospi,
},
+   {
+   .compatible = "intel,lgm-qspi",
+   .data = &intel_lgm_qspi,
+   },
{ /* end of table */ }
 };
 
-- 
2.11.0

[PATCH] dmaengine: fsl-edma: Add eDMA support for QorIQ LS1028A platform

2019-10-17 Thread Peng Ma

Our platforms with below registers(CHCFG0 - CHCFG15) of eDMA as follows:
*---*
| Offset   |OTHERS  |   LS1028A |
|--||---|
| 0x0  |CHCFG0  |   CHCFG3  |
|--||---|
| 0x1  |CHCFG1  |   CHCFG2  |
|--||---|
| 0x2  |CHCFG2  |   CHCFG1  |
|--||---|
| 0x3  |CHCFG3  |   CHCFG0  |
|--||---|
| ...  |..  |   ..  |
|--||---|
| 0xC  |CHCFG12 |   CHCFG15 |
|--||---|
| 0xD  |CHCFG13 |   CHCFG14 |
|--||---|
| 0xE  |CHCFG14 |   CHCFG13 |
|--||---|
| 0xF  |CHCFG15 |   CHCFG12 |
*---*

This patch is to improve edma driver to fit LS1028A platform.

Signed-off-by: Peng Ma 
---
 drivers/dma/fsl-edma-common.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
index b1a7ca9..611186b 100644
--- a/drivers/dma/fsl-edma-common.c
+++ b/drivers/dma/fsl-edma-common.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "fsl-edma-common.h"
 
@@ -42,6 +43,11 @@
 
 #define EDMA_TCD   0x1000
 
+static struct soc_device_attribute soc_fixup_tuning[] = {
+   { .family = "QorIQ LS1028A"},
+   { },
+};
+
 static void fsl_edma_enable_request(struct fsl_edma_chan *fsl_chan)
 {
struct edma_regs *regs = &fsl_chan->edma->regs;
@@ -109,10 +115,16 @@ void fsl_edma_chan_mux(struct fsl_edma_chan *fsl_chan,
u32 ch = fsl_chan->vchan.chan.chan_id;
void __iomem *muxaddr;
unsigned int chans_per_mux, ch_off;
+   int endian_diff[4] = {3, 1, -1, -3};
u32 dmamux_nr = fsl_chan->edma->drvdata->dmamuxs;
 
chans_per_mux = fsl_chan->edma->n_chans / dmamux_nr;
ch_off = fsl_chan->vchan.chan.chan_id % chans_per_mux;
+
+   if (!fsl_chan->edma->big_endian &&
+   soc_device_match(soc_fixup_tuning))
+   ch_off += endian_diff[ch_off % 4];
+
muxaddr = fsl_chan->edma->muxbase[ch / chans_per_mux];
slot = EDMAMUX_CHCFG_SOURCE(slot);
 
-- 
2.9.5

[tip: ras/core] x86/mce: Lower throttling MCE messages' priority to warning

2019-10-17 Thread tip-bot2 for Benjamin Berg

The following commit has been merged into the ras/core branch of tip:

Commit-ID: 9c3bafaa1fd88e4dd2dba3735a1f1abb0f2c7bb7
Gitweb:
https://git.kernel.org/tip/9c3bafaa1fd88e4dd2dba3735a1f1abb0f2c7bb7
Author:Benjamin Berg 
AuthorDate:Wed, 09 Oct 2019 17:54:24 +02:00
Committer: Borislav Petkov 
CommitterDate: Thu, 17 Oct 2019 09:07:09 +02:00

x86/mce: Lower throttling MCE messages' priority to warning

On modern CPUs it is quite normal that the temperature limits are
reached and the CPU is throttled. In fact, often the thermal design is
not sufficient to cool the CPU at full load and limits can quickly be
reached when a burst in load happens. This will even happen with
technologies like RAPL limitting the long term power consumption of
the package.

Also, these limits are "softer", as Srinivas explains:

"CPU temperature doesn't have to hit max(TjMax) to get these warnings.
OEMs ha[ve] an ability to program a threshold where a thermal interrupt
can be generated. In some systems the offset is 20C+ (Read only value).

In recent systems, there is another offset on top of it which can be
programmed by OS, once some agent can adjust power limits dynamically.
By default this is set to low by the firmware, which I guess the
prime motivation of Benjamin to submit the patch."

So these messages do not usually indicate a hardware issue (e.g.
insufficient cooling). Log them as warnings to avoid confusion about
their severity.

 [ bp: Massage commit mesage. ]

Signed-off-by: Benjamin Berg 
Signed-off-by: Borislav Petkov 
Reviewed-by: Hans de Goede 
Tested-by: Christian Kellner 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: linux-edac 
Cc: Peter Zijlstra 
Cc: Srinivas Pandruvada 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20191009155424.249277-1-bb...@redhat.com
---
 arch/x86/kernel/cpu/mce/therm_throt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/mce/therm_throt.c 
b/arch/x86/kernel/cpu/mce/therm_throt.c
index 6e2becf..bc441d6 100644
--- a/arch/x86/kernel/cpu/mce/therm_throt.c
+++ b/arch/x86/kernel/cpu/mce/therm_throt.c
@@ -188,7 +188,7 @@ static void therm_throt_process(bool new_event, int event, 
int level)
/* if we just entered the thermal event */
if (new_event) {
if (event == THERMAL_THROTTLING_EVENT)
-   pr_crit("CPU%d: %s temperature above threshold, cpu 
clock throttled (total events = %lu)\n",
+   pr_warn("CPU%d: %s temperature above threshold, cpu 
clock throttled (total events = %lu)\n",
this_cpu,
level == CORE_LEVEL ? "Core" : "Package",
state->count);

Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages()

2019-10-17 Thread David Hildenbrand


On 17.10.19 09:11, Michal Hocko wrote:

On Thu 17-10-19 10:44:41, Anshuman Khandual wrote:
[...]

Does this add-on documentation look okay ? Should we also mention about the
possible reduction in chances of success during pfn block search for the
non-power-of-two cases as the implicit alignment will probably turn out to
be bigger than nr_pages itself ?

  * Requested nr_pages may or may not be power of two. The search for suitable
  * memory range in a zone happens in nr_pages aligned pfn blocks. But in case
  * when nr_pages is not power of two, an implicitly aligned pfn block search
  * will happen which in turn will impact allocated memory block's alignment.
  * In these cases, the size (i.e nr_pages) and the alignment of the allocated
  * memory will be different. This problem does not exist when nr_pages is power
  * of two where the size and the alignment of the allocated memory will always
  * be nr_pages.


I dunno, it sounds more complicated than really necessary IMHO. Callers
shouldn't really be bothered by memory blocks and other really deep
implementation details.. Wouldn't be the below sufficient?

The allocated memory is always aligned to a page boundary. If nr_pages
is a power of two then the alignement is guaranteed to be to the given


s/alignement/alignment/

and "the PFN is guaranteed to be aligned to nr_pages" (the address is 
aligned to nr_pages*PAGE_SIZE)



nr_pages (e.g. 1GB request would be aligned to 1GB).



I'd probably add "This function will miss allocation opportunities if 
nr_pages is not a power of two (and the implicit alignment is bogus)."


--

Thanks,

David / dhildenb

Re: [PATCH v3 3/3] selftests/livepatch: Test interaction with ftrace_enabled

2019-10-17 Thread Kamalesh Babulal

On 10/17/19 3:17 AM, Joe Lawrence wrote:
> On 10/16/19 1:06 PM, Kamalesh Babulal wrote:
>> On 10/16/19 5:03 PM, Miroslav Benes wrote:
>>> From: Joe Lawrence 
>>>
>>> Since livepatching depends upon ftrace handlers to implement "patched"
>>> code functionality, verify that the ftrace_enabled sysctl value
>>> interacts with livepatch registration as expected.  At the same time,
>>> ensure that ftrace_enabled is set and part of the test environment
>>> configuration that is saved and restored when running the selftests.
>>>
>>> Signed-off-by: Joe Lawrence 
>>> Signed-off-by: Miroslav Benes 
>>
>> [...]
>>> diff --git a/tools/testing/selftests/livepatch/test-ftrace.sh 
>>> b/tools/testing/selftests/livepatch/test-ftrace.sh
>>> new file mode 100755
>>> index ..e2a76887f40a
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/livepatch/test-ftrace.sh
>>
>> This test fails due to wrong file permissions, with the warning:
>>
>> # Warning: file test-ftrace.sh is not executable, correct this.
>> not ok 4 selftests: livepatch: test-ftrace.sh
>>
> 
> Hi Kamalesh,
> 
> Thanks for testing.  This error is weird as the git log says new file mode: 
> 100755.  'git am' of Miroslav's patchset gives me a new test-ftrace.sh with 
> "Access: (0775/-rwxrwxr-x)"  Did you apply the mbox directly or.. ?
> 

Hi Joe,

Thanks, I was using patch command to apply the patches and using git am
helped. Sorry for the noise. The test cases passes now, without the issue
I previously reported:

[...]
# TEST: livepatch interaction with ftrace_enabled sysctl ... ok
ok 4 selftests: livepatch: test-ftrace.sh

Long story is that the patch command version installed on the test machine
doesn't understand new file mode permission from the git diff, updating
the patch version creates the patch with 755 mode.

-- 
Kamalesh

Re: [PATCH -next] staging: media: cedrus: use devm_platform_ioremap_resource() to simplify code

2019-10-17 Thread Paul Kocialkowski

Hi,

On Wed 16 Oct 19, 16:56, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.

This is still:
Acked-by: Paul Kocialkowski 

Please collect the tag in your next version, if there's a need for one.

Cheers,

Paul

> Signed-off-by: YueHaibing 
> ---
>  drivers/staging/media/sunxi/cedrus/cedrus_hw.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c 
> b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> index a942cd9..f19b87c 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> @@ -146,7 +146,6 @@ static irqreturn_t cedrus_irq(int irq, void *data)
>  int cedrus_hw_probe(struct cedrus_dev *dev)
>  {
>   const struct cedrus_variant *variant;
> - struct resource *res;
>   int irq_dec;
>   int ret;
>  
> @@ -225,8 +224,7 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
>   goto err_sram;
>   }
>  
> - res = platform_get_resource(dev->pdev, IORESOURCE_MEM, 0);
> - dev->base = devm_ioremap_resource(dev->dev, res);
> + dev->base = devm_platform_ioremap_resource(dev->pdev, 0);
>   if (IS_ERR(dev->base)) {
>   dev_err(dev->dev, "Failed to map registers\n");
>  
> -- 
> 2.7.4
> 
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH v3] arm64: zynqmp: Add ZynqMP SDHCI compatible string

2019-10-17 Thread Manish Narani

Add the new compatible string for ZynqMP SD Host Controller for its use
in the Arasan SDHCI driver for some of the ZynqMP specific operations.
Add required properties for the same.

Signed-off-by: Manish Narani 
---
This patch depends on the below series of patches:
https://lkml.org/lkml/2019/10/17/37

Changes in v2:
- Added clock-names for SD card clocks for getting clocks in the driver

Changes in v3:
- Reverted "Added clock-names for SD card clocks for getting clocks in 
the driver"
---
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi 
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 9aa67340a4d8..c7b8c3c28aa7 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -494,20 +494,26 @@
 
sdhci0: mmc@ff16 {
compatible = "arasan,sdhci-8.9a";
+   compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 48 4>;
reg = <0x0 0xff16 0x0 0x1000>;
clock-names = "clk_xin", "clk_ahb";
+   #clock-cells = <1>;
+   clock-output-names = "clk_out_sd0", "clk_in_sd0";
};
 
sdhci1: mmc@ff17 {
compatible = "arasan,sdhci-8.9a";
+   compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 49 4>;
reg = <0x0 0xff17 0x0 0x1000>;
clock-names = "clk_xin", "clk_ahb";
+   #clock-cells = <1>;
+   clock-output-names = "clk_out_sd1", "clk_in_sd1";
};
 
smmu: smmu@fd80 {
-- 
2.17.1

Re: [PATCH 2/4] mfd: Add for PMIC MT6359 registers definition

2019-10-17 Thread Lee Jones

On Wed, 16 Oct 2019, Wen Su wrote:

> From: "wen.su" 

Should be:

  From: Wen Su 

> This adds MediaTek PMIC MT6359 registers definition for the
> following sub modules:
> 
> - Regulator
> - RTC
> - Interrupt
> 
> Signed-off-by: wen.su 

Same here.  Please change your Git config.

> ---
>  include/linux/mfd/mt6359/registers.h | 531 
> +++
>  1 file changed, 531 insertions(+)
>  create mode 100644 include/linux/mfd/mt6359/registers.h

Once you've fixed the above, please add my:

For my own reference:
  Acked-for-MFD-by: Lee Jones 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH -tip v4 0/4] x86: kprobes: Prohibit kprobes on Xen/KVM emulate prefixes

2019-10-17 Thread Peter Zijlstra

On Thu, Oct 17, 2019 at 12:26:55PM +0900, Masami Hiramatsu wrote:
> Hi Peter,
> 
> On Wed, 9 Oct 2019 14:31:06 +0200
> Peter Zijlstra  wrote:
> 
> > On Tue, Sep 17, 2019 at 03:14:03PM +0900, Masami Hiramatsu wrote:
> > > Hi Peter,
> > > 
> > > Could you review this version?
> > 
> > These look good to me; shall I merge them or what was the plan?
> 
> Thanks for the review, yes, could you merge this series to support emulated 
> prefixes correctly?

OK, I'll get them merged.

Dear Friend (Assalamu Alaikum),

2019-10-17 Thread AISHA GADDAFI

-- 
Dear Friend (Assalamu Alaikum),

I came across your e-mail contact prior a private search while in need of
your assistance. My name is Aisha  Al-Qaddafi a single Mother and a Widow
with three Children. I am the only biological Daughter of late Libyan
President (Late Colonel Muammar Gaddafi).

I have investment funds worth Twenty Seven Million Five Hundred Thousand
United State Dollar ($27.500.000.00 ) and i need a trusted investment
Manager/Partner because of my current refugee status, however, I am
interested in you for investment project assistance in your country, may be
from there, we can build business relationship in the nearest future.

I am willing to negotiate investment/business profit sharing ratio with you
base on the future investment earning profits.

If you are willing to handle this project on my behalf kindly reply urgent
to enable me provide you more information about the investment funds.

Your Urgent Reply Will Be Appreciated. write me at this email address(
ayishagdda...@mail.com ) for further discussion.

Best Regards
Mrs Aisha Al-Qaddafi
Reply to: ayishagdda...@mail.com

Re: [PATCH v5 0/4] Fix MTRR bug for intel-lpss-pci

2019-10-17 Thread Lee Jones

On Thu, 17 Oct 2019, Andy Shevchenko wrote:

> On Wed, Oct 16, 2019 at 03:06:25PM -0600, Tuowen Zhao wrote:
> > Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
> > in MTRR. This will cause the system to hang during boot. If possible,
> > this bug could be corrected with a firmware update.
> > 
> > Previous version: https://lkml.org/lkml/2019/10/14/575
> > 
> > Changes from previous version:
> > 
> >  * implement ioremap_uc for sparc64
> >  * split docs changes to not CC stable (doc location moved since 5.3)
> > 
> 
> It forgot to explicitly mention through which tree is supposed to go.
> I think it's MFD one, correct?

To be fair, that's not really up to the submitter to decide.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH -next] ASoC: atmel: Fix build error

2019-10-17 Thread Yuehaibing

ping..., this issue still in linux-next 20191017

On 2019/9/28 16:16, YueHaibing wrote:
> when do randbuilding, I got this error:
> 
> sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
> (.text+0x12f6): undefined reference to `atmel_pcm_pdc_platform_register'
> 
> This is because SND_ATMEL_SOC_SSC_DMA=y, SND_ATMEL_SOC_SSC=y,
> but SND_ATMEL_SOC_SSC_PDC=m. Fix it bt reintroducing the default Kconfig.
> 
> Reported-by: Hulk Robot 
> Fixes: 18291410557f ("ASoC: atmel: enable SOC_SSC_PDC and SOC_SSC_DMA in 
> Kconfig")
> Signed-off-by: YueHaibing 
> ---
>  sound/soc/atmel/Kconfig | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
> index f118c22..79e45f2 100644
> --- a/sound/soc/atmel/Kconfig
> +++ b/sound/soc/atmel/Kconfig
> @@ -12,10 +12,14 @@ if SND_ATMEL_SOC
>  config SND_ATMEL_SOC_PDC
>   tristate
>   depends on HAS_DMA
> + default m if SND_ATMEL_SOC_SSC_PDC=m && SND_ATMEL_SOC_SSC=m
> + default y if SND_ATMEL_SOC_SSC_PDC=y || (SND_ATMEL_SOC_SSC_PDC=m && 
> SND_ATMEL_SOC_SSC=y)
>  
>  config SND_ATMEL_SOC_DMA
>   tristate
>   select SND_SOC_GENERIC_DMAENGINE_PCM
> + default m if SND_ATMEL_SOC_SSC_DMA=m && SND_ATMEL_SOC_SSC=m
> + default y if SND_ATMEL_SOC_SSC_DMA=y || (SND_ATMEL_SOC_SSC_DMA=m && 
> SND_ATMEL_SOC_SSC=y)
>  
>  config SND_ATMEL_SOC_SSC
>   tristate
>

Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages()

2019-10-17 Thread Michal Hocko

On Thu 17-10-19 09:21:24, David Hildenbrand wrote:
> On 17.10.19 09:11, Michal Hocko wrote:
> > On Thu 17-10-19 10:44:41, Anshuman Khandual wrote:
> > [...]
> > > Does this add-on documentation look okay ? Should we also mention about 
> > > the
> > > possible reduction in chances of success during pfn block search for the
> > > non-power-of-two cases as the implicit alignment will probably turn out to
> > > be bigger than nr_pages itself ?
> > > 
> > >   * Requested nr_pages may or may not be power of two. The search for 
> > > suitable
> > >   * memory range in a zone happens in nr_pages aligned pfn blocks. But in 
> > > case
> > >   * when nr_pages is not power of two, an implicitly aligned pfn block 
> > > search
> > >   * will happen which in turn will impact allocated memory block's 
> > > alignment.
> > >   * In these cases, the size (i.e nr_pages) and the alignment of the 
> > > allocated
> > >   * memory will be different. This problem does not exist when nr_pages 
> > > is power
> > >   * of two where the size and the alignment of the allocated memory will 
> > > always
> > >   * be nr_pages.
> > 
> > I dunno, it sounds more complicated than really necessary IMHO. Callers
> > shouldn't really be bothered by memory blocks and other really deep
> > implementation details.. Wouldn't be the below sufficient?
> > 
> > The allocated memory is always aligned to a page boundary. If nr_pages
> > is a power of two then the alignement is guaranteed to be to the given
> 
> s/alignement/alignment/
> 
> and "the PFN is guaranteed to be aligned to nr_pages" (the address is
> aligned to nr_pages*PAGE_SIZE)

thx for the correction.

> > nr_pages (e.g. 1GB request would be aligned to 1GB).
> > 
> 
> I'd probably add "This function will miss allocation opportunities if
> nr_pages is not a power of two (and the implicit alignment is bogus)."

This is again an implementation detail and quite a confusing one to
whoever not familiar with the MM internals. And to be fair even a proper
alignment doesn't give you any stronger guarantee as long as the
allocation operates on non movable zones anyway.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3 06/15] powerpc/32: prepare for CONFIG_VMAP_STACK

2019-10-17 Thread Andrew Donnellan


On 10/9/19 7:16 pm, Christophe Leroy wrote:

+#if defined(CONFIG_VMAP_STACK) && CONFIG_THREAD_SHIFT < PAGE_SHIFT
+#define THREAD_SHIFT   PAGE_SHIFT
+#else
  #define THREAD_SHIFT  CONFIG_THREAD_SHIFT
+#endif

  #define THREAD_SIZE   (1 << THREAD_SHIFT)



Looking at 64-bit book3s: with 64K pages, this results in a THREAD_SIZE 
that's too large for immediate mode arithmetic operations, which is 
annoying. Hmm.


--
Andrew Donnellan  OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited

Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages()

2019-10-17 Thread David Hildenbrand


On 17.10.19 09:34, Michal Hocko wrote:

On Thu 17-10-19 09:21:24, David Hildenbrand wrote:

On 17.10.19 09:11, Michal Hocko wrote:

On Thu 17-10-19 10:44:41, Anshuman Khandual wrote:
[...]

Does this add-on documentation look okay ? Should we also mention about the
possible reduction in chances of success during pfn block search for the
non-power-of-two cases as the implicit alignment will probably turn out to
be bigger than nr_pages itself ?

   * Requested nr_pages may or may not be power of two. The search for suitable
   * memory range in a zone happens in nr_pages aligned pfn blocks. But in case
   * when nr_pages is not power of two, an implicitly aligned pfn block search
   * will happen which in turn will impact allocated memory block's alignment.
   * In these cases, the size (i.e nr_pages) and the alignment of the allocated
   * memory will be different. This problem does not exist when nr_pages is 
power
   * of two where the size and the alignment of the allocated memory will always
   * be nr_pages.


I dunno, it sounds more complicated than really necessary IMHO. Callers
shouldn't really be bothered by memory blocks and other really deep
implementation details.. Wouldn't be the below sufficient?

The allocated memory is always aligned to a page boundary. If nr_pages
is a power of two then the alignement is guaranteed to be to the given


s/alignement/alignment/

and "the PFN is guaranteed to be aligned to nr_pages" (the address is
aligned to nr_pages*PAGE_SIZE)


thx for the correction.


nr_pages (e.g. 1GB request would be aligned to 1GB).



I'd probably add "This function will miss allocation opportunities if
nr_pages is not a power of two (and the implicit alignment is bogus)."


This is again an implementation detail and quite a confusing one to
whoever not familiar with the MM internals. And to be fair even a proper
alignment doesn't give you any stronger guarantee as long as the
allocation operates on non movable zones anyway.



To be honest, I'd not suggest to anyone to use this function with 
nr_pages not being a power of two, and I already explained why. I prefer 
to spill that out than having people complain afterwards. Yes it's an 
implementation detail users should be aware of until reworked.


But I think we talked about this here for way too long, so I am fine 
with either.


--

Thanks,

David / dhildenb

Re: [PATCH] net: stmmac: fix argument to stmmac_pcs_ctrl_ane()

2019-10-17 Thread Ben Dooks

On 16/10/2019 21:28, David Miller wrote:

From: "Ben Dooks (Codethink)" 
Date: Wed, 16 Oct 2019 09:22:05 +0100

The stmmac_pcs_ctrl_ane() expects a register address as
argument 1, but for some reason the mac_device_info is
being passed.

Fix the warning (and possible bug) from sparse:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect 
type in argument 1 (different address spaces)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:expected void [noderef] 
 *ioaddr
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:got struct 
mac_device_info *hw

Signed-off-by: Ben Dooks 

I'm still reviewing this but FYI you did not have to send this
twice.

Yes, I accidentally sent the wrong patch out (already apologised
on the re-send as I noticed it about 10 minutes after sending).

--
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

Re: [PATCH] media: st-mipid02: add a check for devm_gpiod_get_optional

2019-10-17 Thread Chuhong Yuan

On Thu, Oct 17, 2019 at 1:43 PM Mickael GUENE  wrote:
>
> Hello Chuhong,
>
>  Is this check necessary ?
> since looking into code it seems to me devm_gpiod_get_optional() can only
> return NULL in case of error due to following check in 
> devm_gpiod_get_index_optional()
> if (IS_ERR(desc)) {
> if (PTR_ERR(desc) == -ENOENT)
> return NULL;
> }
>  And in that case reset_gpio is not used
>

The problem may not be a null return value, but a returned error,
which is a minus value,
like -EPROBE_DEFER or -EINVAL returned by gpiod_find in gpiod_get_index.
In these cases, devm_gpiod_get_index_optional will not return null but
return the error.
Therefore, this check is necessary.

> Regards
> Mickael
>
> On 10/16/19 12:56, Chuhong Yuan wrote:
> > mipid02_probe misses a check for devm_gpiod_get_optional and may miss
> > the failure.
> > Add a check to fix the problem.
> >
> > Signed-off-by: Chuhong Yuan 
> > ---
> >  drivers/media/i2c/st-mipid02.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/media/i2c/st-mipid02.c b/drivers/media/i2c/st-mipid02.c
> > index 81285b8d5cfb..d38e888b0a43 100644
> > --- a/drivers/media/i2c/st-mipid02.c
> > +++ b/drivers/media/i2c/st-mipid02.c
> > @@ -971,6 +971,9 @@ static int mipid02_probe(struct i2c_client *client)
> >   bridge->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> >GPIOD_OUT_HIGH);
> >
> > + if (IS_ERR(bridge->reset_gpio))
> > + return PTR_ERR(bridge->reset_gpio);
> > +
> >   ret = mipid02_get_regulators(bridge);
> >   if (ret) {
> >   dev_err(dev, "failed to get regulators %d", ret);
> >

Re: [PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support

2019-10-17 Thread JC Kuo

Hi Thierry, Hi Rob, Hi Kishon,
Please let me know your thoughts of the below implementation.

1. Add a "bool disable_gen2" to "phy->attrs" structure.
2. In _of_phy_get() of phy-core.c to add the follow to parse a generic property.

phy->attrs.disable_gen2 = of_property_read_bool(args.np,
"usb-disable-gen2");
3. In individual phy driver, to add SOC/PHY specific programming accordingly.

Thanks,
JC

On 10/14/19 9:40 PM, Rob Herring wrote:
> On Mon, Oct 14, 2019 at 8:17 AM Thierry Reding  
> wrote:
>>
>> On Wed, Oct 09, 2019 at 06:39:00PM -0500, Rob Herring wrote:
>>> On Wed, Oct 09, 2019 at 10:43:41AM +0800, JC Kuo wrote:
 Extend the bindings to cover the set of features found in Tegra194.
 Note that, technically, there are four more supplies connected to the
 XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL)
 , but the power sequencing requirements of Tegra194 require these to be
 under the control of the PMIC.

 Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is
 possible for some platforms have long signal trace that could not
 provide sufficient electrical environment for Gen 2 speed. To deal with
 this, a new device node property "nvidia,disable-gen2" was added to
 Tegra194 that be used to specifically disable Gen 2 speed for a
 particular USB 3.0 port so that the port can be limited to Gen 1 speed
 and avoid the instability.
>>>
>>> I suspect this may be a common issue and we should have a common
>>> property. Typically, this kind of property is in the controller though
>>> and supports multiple speed limits. See PCI bindings for inspiration.
>>
>> Given that support for gen 2 speeds is dependent on signal trace length,
>> it doesn't really make sense to restrict the whole controller to a given
>> speed if only the signal trace for a single port exceeds the limit for
>> which gen 2 would work.
>>
>> Also, the USB PHYs are in a different hardware block than the USB
>> controller, so this really is a property of the PHY block, not the USB
>> controller.
> 
> Okay, but still should be common for USB PHYs IMO.
> 
> Rob
>

Re: [PATCH] staging: exfat: add exfat filesystem code to staging

2019-10-17 Thread Pali Rohár

On Wednesday 16 October 2019 16:33:17 Sasha Levin wrote:
> On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
> > > On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
> > > > On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
> > > > > On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> > > > > > With regards to missing specs/docs/whatever - our main concern with 
> > > > > > this
> > > > > > release was that we want full interoperability, which is why the 
> > > > > > spec
> > > > > > was made public as-is without modifications from what was used
> > > > > > internally. There's no "secret sauce" that Microsoft is hiding here.
> > > > >
> > > > > Ok, if it was just drop of "current version" of documentation then it
> > > > > makes sense.
> > > > >
> > > > > > How about we give this spec/code time to get soaked and reviewed 
> > > > > > for a
> > > > > > bit, and if folks still feel (in a month or so?) that there are 
> > > > > > missing
> > > > > > bits of information related to exfat, I'll be happy to go back and 
> > > > > > try
> > > > > > to get them out as well.
> > > >
> > > > Hello Sasha!
> > > >
> > > > Now one month passed, so do you have some information when missing parts
> > > > of documentation like TexFAT would be released to public?
> > > 
> > > Sure, I'll see if I can get an approval to open it up.
> > 
> > Ok!
> > 
> > > Can I assume you will be implementing TexFAT support once the spec is
> > > available?
> > 
> > I cannot promise that I would implement something which I do not know
> > how is working... It depends on how complicated TexFAT is and also how
> > future exfat support in kernel would look like.
> > 
> > But I'm interesting in implementing it.
> 
> It looks like the reason this wasn't made public along with the exFAT
> spec is that TexFAT is pretty much dead - it's old, there are no users
> we are aware of, and digging it out of it's grave to make it public is
> actually quite the headache.
> 
> Is this something you actually have a need for? an entity that has a
> requirement for TexFAT?

Hi!

I do not have device with requirements for TexFAT. The first reason why
I wanted to use TexFAT was that it it the only way how to use more FAT
tables (e.g. secondary for backup) and information for that is missing
in released exFAT specification. This could bring better data recovery.

> I'd would rather spend my time elsewhere than digging TexFAT out of it's 
> grave.

Ok.

I was hoping that it would be possible to easily use secondary FAT table
(from TexFAT extension) for redundancy without need to implement full
TexFAT, which could be also backward compatible with systems which do
not implement TexFAT extension at all. Similarly like using FAT32 disk
with two FAT tables is possible also on system which use first FAT
table.

> Is there anything else in the exFAT spec that is missing (and someone
> actually wants/uses)?

Currently I do not know.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH v3 5/6] media: sun4i: Add H3 deinterlace driver

2019-10-17 Thread Hans Verkuil

On 10/16/19 9:28 PM, Jernej Skrabec wrote:
> Allwinner H3 SoC contains deinterlace unit, which has several modes of
> operation - bypass, weave, bob and mixed (advanced) mode. I don't know
> how mixed mode works, but according to Allwinner it gives best results,
> so they use it exclusively. Currently this mode is also hardcoded here.
> 
> For each interleaved frame queued, this driver produces 2 deinterlaced
> frames. Deinterlaced frames are based on 2 consequtive output buffers,
> except for the first 2, where same output buffer is given to peripheral
> as current and previous.
> 
> There is no documentation for this core, so register layout and fixed
> values were taken from BSP driver.
> 
> I'm not sure if maximum size of the image unit is capable to process is
> governed by size of "flag" buffers, frequency or it really is some HW
> limitation. Currently driver can process full HD image in ~15ms (7.5ms
> for each capture buffer), which allows to process 1920x1080@60i video
> smoothly in real time.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  MAINTAINERS   |7 +
>  drivers/media/platform/sunxi/Kconfig  |1 +
>  drivers/media/platform/sunxi/Makefile |1 +
>  drivers/media/platform/sunxi/sun8i-di/Kconfig |   11 +
>  .../media/platform/sunxi/sun8i-di/Makefile|2 +
>  .../media/platform/sunxi/sun8i-di/sun8i-di.c  | 1020 +
>  .../media/platform/sunxi/sun8i-di/sun8i-di.h  |  237 
>  7 files changed, 1279 insertions(+)
>  create mode 100644 drivers/media/platform/sunxi/sun8i-di/Kconfig
>  create mode 100644 drivers/media/platform/sunxi/sun8i-di/Makefile
>  create mode 100644 drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
>  create mode 100644 drivers/media/platform/sunxi/sun8i-di/sun8i-di.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c7b48525822a..c375455125fb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4646,6 +4646,13 @@ M: "Maciej W. Rozycki" 
>  S:   Maintained
>  F:   drivers/net/fddi/defxx.*
>  
> +DEINTERLACE DRIVERS FOR ALLWINNER H3
> +M:   Jernej Skrabec 
> +L:   linux-me...@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/platform/sunxi/sun8i-di/
> +
>  DELL SMBIOS DRIVER
>  M:   Pali Rohár 
>  M:   Mario Limonciello 
> diff --git a/drivers/media/platform/sunxi/Kconfig 
> b/drivers/media/platform/sunxi/Kconfig
> index 71808e93ac2e..d7a5621bf327 100644
> --- a/drivers/media/platform/sunxi/Kconfig
> +++ b/drivers/media/platform/sunxi/Kconfig
> @@ -1,2 +1,3 @@
>  source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
>  source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> +source "drivers/media/platform/sunxi/sun8i-di/Kconfig"

This is a m2m driver, so this belongs in drivers/media/platform/Kconfig in the
Memory-to-memory section.

> diff --git a/drivers/media/platform/sunxi/Makefile 
> b/drivers/media/platform/sunxi/Makefile
> index a05127529006..3878cb4efdc2 100644
> --- a/drivers/media/platform/sunxi/Makefile
> +++ b/drivers/media/platform/sunxi/Makefile
> @@ -1,2 +1,3 @@
>  obj-y+= sun4i-csi/
>  obj-y+= sun6i-csi/
> +obj-y+= sun8i-di/
> diff --git a/drivers/media/platform/sunxi/sun8i-di/Kconfig 
> b/drivers/media/platform/sunxi/sun8i-di/Kconfig
> new file mode 100644
> index ..dbd77a61e3b3
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun8i-di/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config VIDEO_SUN8I_DEINTERLACE
> + tristate "Allwinner Deinterlace driver"
> + depends on VIDEO_DEV && VIDEO_V4L2
> + depends on HAS_DMA
> + depends on OF
> + depends on PM
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> + help
> +Support for the Allwinner Deinterlace unit found on some SoCs.

Shouldn't this depend on ARCH_SUNXI || COMPILE_TEST?
And also on COMMON_CLK?

Regards,

Hans

Re: [PATCH] mm, soft-offline: convert parameter to pfn

2019-10-17 Thread Naoya Horiguchi

On Thu, Oct 17, 2019 at 09:16:42AM +0200, David Hildenbrand wrote:
> On 17.10.19 01:47, Naoya Horiguchi wrote:
> > On Wed, Oct 16, 2019 at 10:57:57AM +0200, David Hildenbrand wrote:
> > > On 16.10.19 10:54, Naoya Horiguchi wrote:
> > > > On Wed, Oct 16, 2019 at 10:34:52AM +0200, David Hildenbrand wrote:
> > > > > On 16.10.19 10:27, Naoya Horiguchi wrote:
> > > > > > On Wed, Oct 16, 2019 at 09:56:19AM +0200, David Hildenbrand wrote:
> > > > > > > On 16.10.19 09:09, Naoya Horiguchi wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I wrote a simple cleanup for parameter of soft_offline_page(),
> > > > > > > > based on thread https://lkml.org/lkml/2019/10/11/57.
> > > > > > > > 
> > > > > > > > I know that we need more cleanup on hwpoison-inject, but I think
> > > > > > > > that will be mentioned in re-write patchset Oscar is preparing 
> > > > > > > > now.
> > > > > > > > So let me shared only this part as a separate one now.
> > > > > > ...
> > > > > > > 
> > > > > > > I think you should rebase that patch on linux-next (where the
> > > > > > > pfn_to_online_page() check is in place). I assume you'll want to 
> > > > > > > move the
> > > > > > > pfn_to_online_page() check into soft_offline_page() then as well?
> > > > > > 
> > > > > > I rebased to next-20191016. And yes, we will move 
> > > > > > pfn_to_online_page()
> > > > > > into soft offline code.  It seems that we can also move pfn_valid(),
> > > > > > but is simply moving like below good enough for you?
> > > > > 
> > > > > At least I can't am the patch to current next/master (due to
> > > > > pfn_to_online_page()).
> > > 
> > > Could also be that my "git am" skills failed as the mail was not a
> > > proper patch itself :)
> > 
> > Sorry for the inconvenience, my company email system breaks original
> > message by introducing quoted-printable format ('=20' or '=3D').
> > Most mail client usually handles it but git-am doesn't.
> > I give up using it and send via smtp.gmail.com.
> > 
> > > > @@ -1877,11 +1877,17 @@ static int soft_offline_free_page(struct page 
> > > > *page)
> > > >* This is not a 100% solution for all memory, but tries to be
> > > >* ``good enough'' for the majority of memory.
> > > >*/
> > > > -int soft_offline_page(struct page *page, int flags)
> > > > +int soft_offline_page(unsigned long pfn, int flags)
> > > >   {
> > > > int ret;
> > > > -   unsigned long pfn = page_to_pfn(page);
> > > > +   struct page *page;
> > > > +   if (!pfn_valid(pfn))
> > > > +   return -ENXIO;
> > > > +   /* Only online pages can be soft-offlined (esp., not 
> > > > ZONE_DEVICE). */
> > > > +   page = pfn_to_online_page(pfn);
> > > > +   if (!page)
> > > > +   return -EIO;
> > > > if (is_zone_device_page(page)) {
> > > 
> > > -> this is now no longer possible! So you can drop the whole if
> > > (is_zone_device) case
> > 
> > OK, thanks. I updated it.
> > 
> > Thanks,
> > Naoya Horiguchi
> > ---
> >  From 5faf227839b578726fe7f5ff414a153abb3b3a31 Mon Sep 17 00:00:00 2001
> > From: Naoya Horiguchi 
> > Date: Thu, 17 Oct 2019 08:40:53 +0900
> > Subject: [PATCH] mm, soft-offline: convert parameter to pfn
> > 
> > Currently soft_offline_page() receives struct page, and its sibling
> > memory_failure() receives pfn. This discrepancy looks weird and makes
> > precheck on pfn validity tricky. So let's align them.
> > 
> > Signed-off-by: Naoya Horiguchi 
> > ---
> >   drivers/base/memory.c |  7 +--
> >   include/linux/mm.h|  2 +-
> >   mm/madvise.c  |  2 +-
> >   mm/memory-failure.c   | 19 +--
> >   4 files changed, 12 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> > index 55907c27075b..a757d9ed88a7 100644
> > --- a/drivers/base/memory.c
> > +++ b/drivers/base/memory.c
> > @@ -538,12 +538,7 @@ static ssize_t soft_offline_page_store(struct device 
> > *dev,
> > if (kstrtoull(buf, 0, &pfn) < 0)
> > return -EINVAL;
> > pfn >>= PAGE_SHIFT;
> > -   if (!pfn_valid(pfn))
> > -   return -ENXIO;
> > -   /* Only online pages can be soft-offlined (esp., not ZONE_DEVICE). */
> > -   if (!pfn_to_online_page(pfn))
> > -   return -EIO;
> > -   ret = soft_offline_page(pfn_to_page(pfn), 0);
> > +   ret = soft_offline_page(pfn, 0);
> > return ret == 0 ? count : ret;
> >   }
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 44d058723db9..fd360d208346 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -2794,7 +2794,7 @@ extern int sysctl_memory_failure_early_kill;
> >   extern int sysctl_memory_failure_recovery;
> >   extern void shake_page(struct page *p, int access);
> >   extern atomic_long_t num_poisoned_pages __read_mostly;
> > -extern int soft_offline_page(struct page *page, int flags);
> > +extern int soft_offline_page(unsigned long pfn, int flags);
> >   /*
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 2be9f3fdb05e..99

Re: [PATCH] staging: exfat: add exfat filesystem code to staging

2019-10-17 Thread Pali Rohár

On Wednesday 16 October 2019 17:53:43 Valdis Klētnieks wrote:
> and may cause problems if Linux says "currently using FAT 2", and the
> disk is next used on a Windows 10 box that only looks at FAT 1

You should use same algorithm which is used for FAT32. Primary FAT is
first. And all operations are done on Secondary FAT and then is
Secondary FAT copied to Primary. This is backward compatible with
systems which operates only with first primary FAT. And other systems
which see both FATs can benefit from redundancy/recovery.

-- 
Pali Rohár
pali.ro...@gmail.com

[PATCH] usb: cdns3: Error out if USB_DR_MODE_UNKNOWN in cdns3_core_init_role()

2019-10-17 Thread Roger Quadros

USB_DR_MODE_UNKNOWN should be treated as error as it is done in
cdns3_drd_update_mode().

Fixes: 02ffc26df96b ("usb: cdns3: fix cdns3_core_init_role()")
Signed-off-by: Roger Quadros 
---
 drivers/usb/cdns3/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index 1109dc5a4c39..c2123ef8d8a3 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -166,7 +166,6 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
goto err;
 
switch (cdns->dr_mode) {
-   case USB_DR_MODE_UNKNOWN:
case USB_DR_MODE_OTG:
ret = cdns3_hw_role_switch(cdns);
if (ret)
@@ -182,6 +181,9 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
if (ret)
goto err;
break;
+   default:
+   ret = -EINVAL;
+   goto err;
}
 
return ret;
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] mm, soft-offline: convert parameter to pfn

2019-10-17 Thread David Hildenbrand


On 17.10.19 09:50, Naoya Horiguchi wrote:

On Thu, Oct 17, 2019 at 09:16:42AM +0200, David Hildenbrand wrote:

On 17.10.19 01:47, Naoya Horiguchi wrote:

On Wed, Oct 16, 2019 at 10:57:57AM +0200, David Hildenbrand wrote:

On 16.10.19 10:54, Naoya Horiguchi wrote:

On Wed, Oct 16, 2019 at 10:34:52AM +0200, David Hildenbrand wrote:

On 16.10.19 10:27, Naoya Horiguchi wrote:

On Wed, Oct 16, 2019 at 09:56:19AM +0200, David Hildenbrand wrote:

On 16.10.19 09:09, Naoya Horiguchi wrote:

Hi,

I wrote a simple cleanup for parameter of soft_offline_page(),
based on thread https://lkml.org/lkml/2019/10/11/57.

I know that we need more cleanup on hwpoison-inject, but I think
that will be mentioned in re-write patchset Oscar is preparing now.
So let me shared only this part as a separate one now.

...


I think you should rebase that patch on linux-next (where the
pfn_to_online_page() check is in place). I assume you'll want to move the
pfn_to_online_page() check into soft_offline_page() then as well?


I rebased to next-20191016. And yes, we will move pfn_to_online_page()
into soft offline code.  It seems that we can also move pfn_valid(),
but is simply moving like below good enough for you?


At least I can't am the patch to current next/master (due to
pfn_to_online_page()).


Could also be that my "git am" skills failed as the mail was not a
proper patch itself :)


Sorry for the inconvenience, my company email system breaks original
message by introducing quoted-printable format ('=20' or '=3D').
Most mail client usually handles it but git-am doesn't.
I give up using it and send via smtp.gmail.com.


@@ -1877,11 +1877,17 @@ static int soft_offline_free_page(struct page *page)
* This is not a 100% solution for all memory, but tries to be
* ``good enough'' for the majority of memory.
*/
-int soft_offline_page(struct page *page, int flags)
+int soft_offline_page(unsigned long pfn, int flags)
   {
int ret;
-   unsigned long pfn = page_to_pfn(page);
+   struct page *page;
+   if (!pfn_valid(pfn))
+   return -ENXIO;
+   /* Only online pages can be soft-offlined (esp., not ZONE_DEVICE). */
+   page = pfn_to_online_page(pfn);
+   if (!page)
+   return -EIO;
if (is_zone_device_page(page)) {


-> this is now no longer possible! So you can drop the whole if
(is_zone_device) case


OK, thanks. I updated it.

Thanks,
Naoya Horiguchi
---
  From 5faf227839b578726fe7f5ff414a153abb3b3a31 Mon Sep 17 00:00:00 2001
From: Naoya Horiguchi 
Date: Thu, 17 Oct 2019 08:40:53 +0900
Subject: [PATCH] mm, soft-offline: convert parameter to pfn

Currently soft_offline_page() receives struct page, and its sibling
memory_failure() receives pfn. This discrepancy looks weird and makes
precheck on pfn validity tricky. So let's align them.

Signed-off-by: Naoya Horiguchi 
---
   drivers/base/memory.c |  7 +--
   include/linux/mm.h|  2 +-
   mm/madvise.c  |  2 +-
   mm/memory-failure.c   | 19 +--
   4 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 55907c27075b..a757d9ed88a7 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -538,12 +538,7 @@ static ssize_t soft_offline_page_store(struct device *dev,
if (kstrtoull(buf, 0, &pfn) < 0)
return -EINVAL;
pfn >>= PAGE_SHIFT;
-   if (!pfn_valid(pfn))
-   return -ENXIO;
-   /* Only online pages can be soft-offlined (esp., not ZONE_DEVICE). */
-   if (!pfn_to_online_page(pfn))
-   return -EIO;
-   ret = soft_offline_page(pfn_to_page(pfn), 0);
+   ret = soft_offline_page(pfn, 0);
return ret == 0 ? count : ret;
   }
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 44d058723db9..fd360d208346 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2794,7 +2794,7 @@ extern int sysctl_memory_failure_early_kill;
   extern int sysctl_memory_failure_recovery;
   extern void shake_page(struct page *p, int access);
   extern atomic_long_t num_poisoned_pages __read_mostly;
-extern int soft_offline_page(struct page *page, int flags);
+extern int soft_offline_page(unsigned long pfn, int flags);
   /*
diff --git a/mm/madvise.c b/mm/madvise.c
index 2be9f3fdb05e..99dd06fecfa9 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -887,7 +887,7 @@ static int madvise_inject_error(int behavior,
pr_info("Soft offlining pfn %#lx at process virtual address 
%#lx\n",
pfn, start);
-   ret = soft_offline_page(page, MF_COUNT_INCREASED);
+   ret = soft_offline_page(pfn, MF_COUNT_INCREASED);
if (ret)
return ret;
continue;
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 05c8c6df25e6..af2712004a4d 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1476,7

Re: [PATCH] mm, soft-offline: convert parameter to pfn

2019-10-17 Thread Oscar Salvador

On Thu, Oct 17, 2019 at 07:50:18AM +, Naoya Horiguchi wrote:
> Actually I guess that !pfn_valid() never happens when called from
> madvise_inject_error(), because madvise_inject_error() gets pfn via
> get_user_pages_fast() which only returns valid page for valid pfn.
> 
> And we plan to remove MF_COUNT_INCREASED by Oscar's re-design work,
> so I start feeling that this patch should come on top of his tree.

Hi Naoya,

I am pretty much done with my testing.
If you feel like, I can take the patch and add it on top of [1]
, then I will do some more testing and, if nothing pops up, I will
send it upstream.

[1] https://github.com/leberus/linux/tree/hwpoison-v2

> 
> Thanks,
> Naoya Horiguchi

-- 
Oscar Salvador
SUSE L3

Re: [PATCH v5 0/4] Fix MTRR bug for intel-lpss-pci

2019-10-17 Thread Andy Shevchenko

On Thu, Oct 17, 2019 at 08:31:16AM +0100, Lee Jones wrote:
> On Thu, 17 Oct 2019, Andy Shevchenko wrote:
> > On Wed, Oct 16, 2019 at 03:06:25PM -0600, Tuowen Zhao wrote:
> > > Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
> > > in MTRR. This will cause the system to hang during boot. If possible,
> > > this bug could be corrected with a firmware update.
> > > 
> > > Previous version: https://lkml.org/lkml/2019/10/14/575
> > > 
> > > Changes from previous version:
> > > 
> > >  * implement ioremap_uc for sparc64
> > >  * split docs changes to not CC stable (doc location moved since 5.3)
> > > 
> > 
> > It forgot to explicitly mention through which tree is supposed to go.
> > I think it's MFD one, correct?
> 
> To be fair, that's not really up to the submitter to decide.

Submitter still can share their view, no?

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC] Memory Tiering

2019-10-17 Thread David Hildenbrand


On 16.10.19 22:05, Dave Hansen wrote:

The memory hierarchy is getting more complicated and the kernel is
playing an increasing role in managing the different tiers.  A few
different groups of folks described "migration" optimizations they were
doing in this area at LSF/MM earlier this year.  One of the questions
folks asked was why autonuma wasn't being used.

At Intel, the primary new tier that we're looking at is persistent
memory (PMEM).  We'd like to be able to use "persistent memory"
*without* using its persistence properties, treating it as slightly
slower DRAM.  Keith Busch has some patches to use NUMA migration to
automatically migrate DRAM->PMEM instead of discarding it near the end
of the reclaim process.  Huang Ying has some patches which use a
modified autonuma to migrate frequently-used data *back* from PMEM->DRAM.


Very interesting topic. I heard similar demand from HPC folks 
(especially involving other memory types ("tiers")). There, I think you 
often want to let the application manage that. But of course, for many 
applications an automatic management might already be beneficial.


Am I correct that you are using PMEM in this area along with ZONE_DEVICE 
and not by giving PMEM to the buddy (add_memory())?




We've tried to do this all generically so that it is not tied to
persistent memory and can be applied to any memory types in lots of
topologies.

We've been running this code in various forms for the past few months,
comparing it to pure DRAM and hardware-based caching.  The initial
results are encouraging and we thought others might want to take a look
at the code or run their own experiments.  We're expecting to post the
individual patches soon.  But, until then, the code is available here:

https://git.kernel.org/pub/scm/linux/kernel/git/vishal/tiering.git

and is tagged with "tiering-0.2", aka. d8e31e81b1dca9.

Note that internally folks have been calling this "hmem" which is
terribly easy to confuse with the existing hmm.  There are still some
"hmem"'s in the tree, but I don't expect them to live much longer.




--

Thanks,

David / dhildenb

Re: [PATCH 1/3] auxdisplay: Make charlcd.[ch] more general

2019-10-17 Thread Lars Poeschel

On Wed, Oct 16, 2019 at 06:53:20PM +0200, Miguel Ojeda wrote:
> On Wed, Oct 16, 2019 at 10:24 AM Lars Poeschel  wrote:
> >
> > charlcd.c contains lots of hd44780 hardware specific stuff. It is nearly
> > impossible to reuse the interface for other character based displays.
> > The current users of charlcd are the hd44780 and the panel drivers.
> > This does factor out the hd44780 specific stuff out of charlcd into a
> > new module called hd44780_common.
> > charlcd gets rid of the hd44780 specfics and more generally useable.
> > The hd44780 and panel drivers are modified to use the new
> > hd44780_common.
> > This is tested on a hd44780 connected through the gpios of a pcf8574.
> >
> > Signed-off-by: Lars Poeschel 
> > ---
> >  drivers/auxdisplay/Kconfig  |  16 +
> >  drivers/auxdisplay/Makefile |   1 +
> >  drivers/auxdisplay/charlcd.c| 591 
> >  drivers/auxdisplay/charlcd.h| 109 -
> >  drivers/auxdisplay/hd44780.c| 121 --
> >  drivers/auxdisplay/hd44780_common.c | 370 +
> >  drivers/auxdisplay/hd44780_common.h |  32 ++
> >  drivers/auxdisplay/panel.c  | 178 -
> >  8 files changed, 851 insertions(+), 567 deletions(-)
> 
> Thanks Lars, CC'ing Geert since he wrote a large portion of this, as
> well as Andy.
> 
> From a cursory look (sorry, not doing it inline since it is a pain to
> edit in this UI given the size...):

I am okay with this. I know, what you are talking about, since I know
the code very well. But maybe it is a bit harder to follow for others.

>   * panel.c doesn't compile since lcd_backlight's return type did not
> get updated, which makes me uneasy. I am not sure why you changed the
> return type anyway, since callers ignore it and callees always return
> 0.

That panel.c doesn't compile is of course a no-go. Sorry. I missed
something and I will fix this in a next version of the patch. But before
submitting a next version, I will wait some time, if there is more
feedback.
The idea with changing the return types: It seems a bit, that with this
patch charlcd is becoming more of an universal interface and maybe more
display backends get added - maybe with displays, that can report
failure of operations. And I thought, it will be better to have this
earlier and have the "interface" stable and more uniform. But you are
the maintainer. If you don't like the changed return types I happily
revert back to the original ones in the next version of the patch.

>   * Declared and then immediately defined hd44780_common in the header...?

This is not intended. I'll change it.

>   * Some things (e.g. the addition of enums like charlcd_onoff) seem
> like could have been done other patches (since they are not really
> related to the reorganization).

I can split this out into separate patches. It'd be good know what else
you mean by "some things" so I can do this as well. Do you want each
enum as a separate patch or one big enum patch ?

>   * From checkpatch.pl: DOS line endings and trailing whitespace

Strange. I did indeed checkpatch.pl the patches before submitting and I
got no complaints about whitespace or line endings. There was "WARNING:
added, moved or deleted file(s), does MAINTAINERS need updating?" and
patch 1 also has "WARNING: please write a paragraph that describes the
config symbol fully". I submitted the patches with git send-email so it
is very unlikely, that the mailer messed up the patches. Strange...
Oh by the way: Do you know what I can do to make checkpatch happy with
its describing of the config symbol ? I tried writing a help paragraph
for the config symbols in Kconfig, but that did not help.

> I am not capable of testing this, so extra testing by anyone who has
> the different hardware affected around is very welcome.

Are you able to test the panel driver ?

Thank you for your prompt feedback!

Lars

Re: [PATCH v1 2/3] tty: serial: lpuart: Use defines that correspond to correct register

2019-10-17 Thread Philippe Schenker

On Wed, 2019-10-16 at 22:22 +0200, Stefan Agner wrote:
> On 2019-10-16 17:18, Philippe Schenker wrote:
> > Use UARTMODIR defines instead of UARTMODEM as it is a 32-bit
> > function
> 
> This reads a bit strange at first. Also it is helpful for later to
> state
> that this does not make a difference in practise, so how about:
> 
> Use define from the 32-bit register description UARTMODIR_* instead of
> UARTMODEM_*. The value is the same, so there is no functional change.
> 
> Otherwise looks good to me:
> 
> Reviewed-by: Stefan Agner 

Thanks for your review and comment. And also thanks to Andy Duan for his
reviews!

You're right, I could have included that so it is clear that nothing is
changed. I will send a v2 today with your suggested commit message

Philippe

> 
> --
> Stefan
> 
> > Signed-off-by: Philippe Schenker 
> > ---
> > 
> >  drivers/tty/serial/fsl_lpuart.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/tty/serial/fsl_lpuart.c
> > b/drivers/tty/serial/fsl_lpuart.c
> > index f3271857621c..346b4a070ce9 100644
> > --- a/drivers/tty/serial/fsl_lpuart.c
> > +++ b/drivers/tty/serial/fsl_lpuart.c
> > @@ -1879,10 +1879,10 @@ lpuart32_set_termios(struct uart_port *port,
> > struct ktermios *termios,
> > }
> >  
> > if (termios->c_cflag & CRTSCTS) {
> > -   modem |= UARTMODEM_RXRTSE | UARTMODEM_TXCTSE;
> > +   modem |= (UARTMODIR_RXRTSE | UARTMODIR_TXCTSE);
> > } else {
> > termios->c_cflag &= ~CRTSCTS;
> > -   modem &= ~(UARTMODEM_RXRTSE | UARTMODEM_TXCTSE);
> > +   modem &= ~(UARTMODIR_RXRTSE | UARTMODIR_TXCTSE);
> > }
> >  
> > if (termios->c_cflag & CSTOPB)

Re: [PATCH v2] media: imx7-mipi-csis: Add a check for devm_regulator_get

2019-10-17 Thread Marco Felsch

Hi Rui,

On 19-10-16 14:43, Rui Miguel Silva wrote:
> Hi Marco,
> On Wed 16 Oct 2019 at 10:06, Marco Felsch wrote:
> > Hi Chuhong,
> >
> > On 19-10-15 21:59, Chuhong Yuan wrote:
> >> devm_regulator_get may return an error but mipi_csis_phy_init misses
> >> a check for it.
> >> This may lead to problems when regulator_set_voltage uses the unchecked
> >> pointer.
> >> This patch adds a check for devm_regulator_get to avoid potential risk.
> >>
> >> Signed-off-by: Chuhong Yuan 
> >> ---
> >> Changes in v2:
> >>   - Add a check in mipi_csis_probe for the modified mipi_csis_phy_init.
> >
> > Did you miss the check for -EPROBE_DEFER?
> >
> 
> I think nothing special is really needed to do in case of
> EPROBE_DEFER, or am I missing something?
> It just return to probe and probe returns also. I just talked
> about it because it was not cover in the original code.

Yes, your are right... I shouldn't comment on anything I read with one
eye. Sorry.

Regards,
  Marco

> ---
> Cheers,
>   Rui
> 
> >
> > Regards,
> >   Marco
> >
> >>
> >>  drivers/staging/media/imx/imx7-mipi-csis.c | 8 +++-
> >>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c 
> >> b/drivers/staging/media/imx/imx7-mipi-csis.c
> >> index 73d8354e618c..e8a6acaa969e 100644
> >> --- a/drivers/staging/media/imx/imx7-mipi-csis.c
> >> +++ b/drivers/staging/media/imx/imx7-mipi-csis.c
> >> @@ -350,6 +350,8 @@ static void mipi_csis_sw_reset(struct csi_state *state)
> >>  static int mipi_csis_phy_init(struct csi_state *state)
> >>  {
> >>state->mipi_phy_regulator = devm_regulator_get(state->dev, "phy");
> >> +  if (IS_ERR(state->mipi_phy_regulator))
> >> +  return PTR_ERR(state->mipi_phy_regulator);
> >>
> >>return regulator_set_voltage(state->mipi_phy_regulator, 100,
> >> 100);
> >> @@ -966,7 +968,10 @@ static int mipi_csis_probe(struct platform_device 
> >> *pdev)
> >>return ret;
> >>}
> >>
> >> -  mipi_csis_phy_init(state);
> >> +  ret = mipi_csis_phy_init(state);
> >> +  if (ret < 0)
> >> +  return ret;
> >> +
> >>mipi_csis_phy_reset(state);
> >>
> >>mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> --
> >> 2.20.1
> >>
> >>
> >>
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] mm, soft-offline: convert parameter to pfn

2019-10-17 Thread Naoya Horiguchi

On Thu, Oct 17, 2019 at 10:03:21AM +0200, Oscar Salvador wrote:
> On Thu, Oct 17, 2019 at 07:50:18AM +, Naoya Horiguchi wrote:
> > Actually I guess that !pfn_valid() never happens when called from
> > madvise_inject_error(), because madvise_inject_error() gets pfn via
> > get_user_pages_fast() which only returns valid page for valid pfn.
> > 
> > And we plan to remove MF_COUNT_INCREASED by Oscar's re-design work,
> > so I start feeling that this patch should come on top of his tree.
> 
> Hi Naoya,
> 
> I am pretty much done with my testing.
> If you feel like, I can take the patch and add it on top of [1]
> , then I will do some more testing and, if nothing pops up, I will
> send it upstream.

Hi Oscar,
Yes, please take it, thank you for speaking up.

> 
> [1] https://github.com/leberus/linux/tree/hwpoison-v2

Re: [PATCH 00/10] Add support for more Kontron i.MX6UL/ULL SoMs and boards

2019-10-17 Thread Marco Felsch

Hi Frieder,

On 19-10-16 15:06, Schrempf Frieder wrote:
> From: Frieder Schrempf 
> 
> In order to support more of the i.MX6UL/ULL-based SoMs and boards by
> Kontron Electronics GmbH, we restructure the devicetrees to share common
> parts and add new devicetrees for the missing boards.
> 
> Currently there are the following SoM flavors:
>   * N6310: SoM with i.MX6UL-2, 256MB RAM, 256MB SPI NAND
>   * N6311: SoM with i.MX6UL-2, 512MB RAM, 512MB SPI NAND (new)
>   * N6411: SoM with i.MX6ULL, 512MB RAM, 512MB SPI NAND (new)
> 
> Each of the SoMs also features 1MB SPI NOR and an Ethernet PHY. The carrier
> board for the evalkit is the same for all SoMs.
> 
> Frieder Schrempf (10):
>   ARM: dts: imx6ul-kontron-n6310: Move common SoM nodes to a separate
> file
>   ARM: dts: Add support for two more Kontron SoMs N6311 and N6411
>   ARM: dts: imx6ul-kontron-n6310-s: Move common nodes to a separate file
>   ARM: dts: Add support for two more Kontron evalkit boards 'N6311 S'
> and 'N6411 S'
>   ARM: dts: imx6ul-kontron-n6x1x: Add 'chosen' node with 'stdout-path'
>   ARM: dts: imx6ul-kontron-n6x1x-s: Specify bus-width for SD card and
> eMMC
>   ARM: dts: imx6ul-kontron-n6x1x-s: Add vbus-supply and overcurrent
> polarity to usb nodes
>   ARM: dts: imx6ul-kontron-n6x1x-s: Remove an obsolete comment and fix
> indentation
>   dt-bindings: arm: fsl: Add more Kontron i.MX6UL/ULL compatibles
>   MAINTAINERS: Add an entry for Kontron Electronics ARM board support

Did you send all patches to same To: and Cc:?

Regards,
  Marco

> 
>  .../devicetree/bindings/arm/fsl.yaml  |  14 +
>  MAINTAINERS   |   6 +
>  arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts  | 405 +
>  .../boot/dts/imx6ul-kontron-n6310-som.dtsi|  95 +---
>  arch/arm/boot/dts/imx6ul-kontron-n6311-s.dts  |  16 +
>  .../boot/dts/imx6ul-kontron-n6311-som.dtsi|  40 ++
>  arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi | 422 ++
>  .../dts/imx6ul-kontron-n6x1x-som-common.dtsi  | 129 ++
>  arch/arm/boot/dts/imx6ull-kontron-n6411-s.dts |  16 +
>  .../boot/dts/imx6ull-kontron-n6411-som.dtsi   |  40 ++
>  10 files changed, 685 insertions(+), 498 deletions(-)
>  create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6311-s.dts
>  create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6311-som.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6ull-kontron-n6411-s.dts
>  create mode 100644 arch/arm/boot/dts/imx6ull-kontron-n6411-som.dtsi
> 
> -- 
> 2.17.1
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

2019-10-17 Thread Takashi Iwai

On Fri, 11 Oct 2019 19:19:36 +0200,
Szabolcs Szőke wrote:
> 
> BOSS Katana amplifiers cannot be used for recording or playback if quirks
> are applied
> 
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223
> Signed-off-by: Szabolcs Szőke 

Applied now.  Thanks.


Takashi

> 
> ---
>  sound/usb/pcm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> index 33cd26763c0e..daadb0c66eee 100644
> --- a/sound/usb/pcm.c
> +++ b/sound/usb/pcm.c
> @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct 
> snd_usb_substream *subs,
>   ep = 0x84;
>   ifnum = 0;
>   goto add_sync_ep_from_ifnum;
> + case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
> + /* BOSS Katana amplifiers do not need quirks */
> + return 0;
>   }
>  
>   if (attr == USB_ENDPOINT_SYNC_ASYNC &&
> -- 
> 2.20.1
>

Re: [PATCH v5 0/4] Fix MTRR bug for intel-lpss-pci

2019-10-17 Thread Lee Jones

On Thu, 17 Oct 2019, Andy Shevchenko wrote:

> On Thu, Oct 17, 2019 at 08:31:16AM +0100, Lee Jones wrote:
> > On Thu, 17 Oct 2019, Andy Shevchenko wrote:
> > > On Wed, Oct 16, 2019 at 03:06:25PM -0600, Tuowen Zhao wrote:
> > > > Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
> > > > in MTRR. This will cause the system to hang during boot. If possible,
> > > > this bug could be corrected with a firmware update.
> > > > 
> > > > Previous version: https://lkml.org/lkml/2019/10/14/575
> > > > 
> > > > Changes from previous version:
> > > > 
> > > >  * implement ioremap_uc for sparc64
> > > >  * split docs changes to not CC stable (doc location moved since 5.3)
> > > > 
> > > 
> > > It forgot to explicitly mention through which tree is supposed to go.
> > > I think it's MFD one, correct?
> > 
> > To be fair, that's not really up to the submitter to decide.
> 
> Submitter still can share their view, no?

Preferences can be voiced, if held, and will always be taken into
consideration.  The final decision will always be made by the people
managing the trees.

The comment above implies a requirement to specify which tree is
preferred, which is not the case.  In almost all cases, it's best not
to specify.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] use devm_platform_ioremap_resource() for irqchip drivers

2019-10-17 Thread Marc Zyngier


On 2019-10-17 08:13, Daode Huang wrote:

From: Daode Huang 

Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together

Signed-off-by: Daode Huang 
---
 drivers/irqchip/irq-mvebu-icu.c   | 3 +--
 drivers/irqchip/irq-mvebu-pic.c   | 3 +--
 drivers/irqchip/irq-stm32-exti.c  | 3 +--
 drivers/irqchip/irq-ti-sci-inta.c | 3 +--
 drivers/irqchip/irq-ts4800.c  | 3 +--
 5 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/irqchip/irq-mvebu-icu.c
b/drivers/irqchip/irq-mvebu-icu.c
index 547045d..ddf9b0d 100644
--- a/drivers/irqchip/irq-mvebu-icu.c
+++ b/drivers/irqchip/irq-mvebu-icu.c
@@ -357,8 +357,7 @@ static int mvebu_icu_probe(struct platform_device 
*pdev)


icu->dev = &pdev->dev;

-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   icu->base = devm_ioremap_resource(&pdev->dev, res);
+   icu->base = devm_platform_ioremap_resource(pdev, res);


void __iomem *devm_platform_ioremap_resource(struct platform_device 
*pdev,

 unsigned int index)

What could possibly go wrong? I'd suggest you start compiling (and 
possibly

testing) the code you change before sending patches...

M.
--
Jazz is not dead. It just smells funny...

[PATCH V3] mm/page_alloc: Add alloc_contig_pages()

2019-10-17 Thread Anshuman Khandual

HugeTLB helper alloc_gigantic_page() implements fairly generic allocation
method where it scans over various zones looking for a large contiguous pfn
range before trying to allocate it with alloc_contig_range(). Other than
deriving the requested order from 'struct hstate', there is nothing HugeTLB
specific in there. This can be made available for general use to allocate
contiguous memory which could not have been allocated through the buddy
allocator.

alloc_gigantic_page() has been split carving out actual allocation method
which is then made available via new alloc_contig_pages() helper wrapped
under CONFIG_CONTIG_ALLOC. All references to 'gigantic' have been replaced
with more generic term 'contig'. Allocated pages here should be freed with
free_contig_range() or by calling __free_page() on each allocated page.

Cc: Mike Kravetz 
Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Michal Hocko 
Cc: David Rientjes 
Cc: Andrea Arcangeli 
Cc: Oscar Salvador 
Cc: Mel Gorman 
Cc: Mike Rapoport 
Cc: Dan Williams 
Cc: Pavel Tatashin 
Cc: Matthew Wilcox 
Cc: David Hildenbrand 
Cc: linux-kernel@vger.kernel.org
Acked-by: David Hildenbrand 
Acked-by: Michal Hocko 
Signed-off-by: Anshuman Khandual 
---
This is based on https://patchwork.kernel.org/patch/11190213/

Changes in V3:

- Added an in-code comment per Michal and David

Changes in V2:

- Rephrased patch subject per David
- Fixed all typos per David
- s/order/contiguous

Changes from [V5,1/2] mm/hugetlb: Make alloc_gigantic_page()...

- alloc_contig_page() takes nr_pages instead of order per Michal
- s/gigantic/contig on all related functions

 include/linux/gfp.h |   2 +
 mm/hugetlb.c|  77 +
 mm/page_alloc.c | 101 
 3 files changed, 105 insertions(+), 75 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index fb07b503dc45..1a11d4857027 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -589,6 +589,8 @@ static inline bool pm_suspended_storage(void)
 /* The below functions must be run on a range from a single zone. */
 extern int alloc_contig_range(unsigned long start, unsigned long end,
  unsigned migratetype, gfp_t gfp_mask);
+extern struct page *alloc_contig_pages(unsigned long nr_pages, gfp_t gfp_mask,
+  int nid, nodemask_t *nodemask);
 #endif
 void free_contig_range(unsigned long pfn, unsigned int nr_pages);
 
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 985ee15eb04b..a5c2c880af27 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1023,85 +1023,12 @@ static void free_gigantic_page(struct page *page, 
unsigned int order)
 }
 
 #ifdef CONFIG_CONTIG_ALLOC
-static int __alloc_gigantic_page(unsigned long start_pfn,
-   unsigned long nr_pages, gfp_t gfp_mask)
-{
-   unsigned long end_pfn = start_pfn + nr_pages;
-   return alloc_contig_range(start_pfn, end_pfn, MIGRATE_MOVABLE,
- gfp_mask);
-}
-
-static bool pfn_range_valid_gigantic(struct zone *z,
-   unsigned long start_pfn, unsigned long nr_pages)
-{
-   unsigned long i, end_pfn = start_pfn + nr_pages;
-   struct page *page;
-
-   for (i = start_pfn; i < end_pfn; i++) {
-   page = pfn_to_online_page(i);
-   if (!page)
-   return false;
-
-   if (page_zone(page) != z)
-   return false;
-
-   if (PageReserved(page))
-   return false;
-
-   if (page_count(page) > 0)
-   return false;
-
-   if (PageHuge(page))
-   return false;
-   }
-
-   return true;
-}
-
-static bool zone_spans_last_pfn(const struct zone *zone,
-   unsigned long start_pfn, unsigned long nr_pages)
-{
-   unsigned long last_pfn = start_pfn + nr_pages - 1;
-   return zone_spans_pfn(zone, last_pfn);
-}
-
 static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
int nid, nodemask_t *nodemask)
 {
-   unsigned int order = huge_page_order(h);
-   unsigned long nr_pages = 1 << order;
-   unsigned long ret, pfn, flags;
-   struct zonelist *zonelist;
-   struct zone *zone;
-   struct zoneref *z;
-
-   zonelist = node_zonelist(nid, gfp_mask);
-   for_each_zone_zonelist_nodemask(zone, z, zonelist, gfp_zone(gfp_mask), 
nodemask) {
-   spin_lock_irqsave(&zone->lock, flags);
+   unsigned long nr_pages = 1UL << huge_page_order(h);
 
-   pfn = ALIGN(zone->zone_start_pfn, nr_pages);
-   while (zone_spans_last_pfn(zone, pfn, nr_pages)) {
-   if (pfn_range_valid_gigantic(zone, pfn, nr_pages)) {
-   /*
-* We release the zone lock here because
-* alloc_contig_range() will also l

Re: [PATCH 00/10] Add support for more Kontron i.MX6UL/ULL SoMs and boards

2019-10-17 Thread Schrempf Frieder

Hi Marco,

On 17.10.19 10:14, Marco Felsch wrote:
> Hi Frieder,
> 
> On 19-10-16 15:06, Schrempf Frieder wrote:
>> From: Frieder Schrempf 
>>
>> In order to support more of the i.MX6UL/ULL-based SoMs and boards by
>> Kontron Electronics GmbH, we restructure the devicetrees to share common
>> parts and add new devicetrees for the missing boards.
>>
>> Currently there are the following SoM flavors:
>>* N6310: SoM with i.MX6UL-2, 256MB RAM, 256MB SPI NAND
>>* N6311: SoM with i.MX6UL-2, 512MB RAM, 512MB SPI NAND (new)
>>* N6411: SoM with i.MX6ULL, 512MB RAM, 512MB SPI NAND (new)
>>
>> Each of the SoMs also features 1MB SPI NOR and an Ethernet PHY. The carrier
>> board for the evalkit is the same for all SoMs.
>>
>> Frieder Schrempf (10):
>>ARM: dts: imx6ul-kontron-n6310: Move common SoM nodes to a separate
>>  file
>>ARM: dts: Add support for two more Kontron SoMs N6311 and N6411
>>ARM: dts: imx6ul-kontron-n6310-s: Move common nodes to a separate file
>>ARM: dts: Add support for two more Kontron evalkit boards 'N6311 S'
>>  and 'N6411 S'
>>ARM: dts: imx6ul-kontron-n6x1x: Add 'chosen' node with 'stdout-path'
>>ARM: dts: imx6ul-kontron-n6x1x-s: Specify bus-width for SD card and
>>  eMMC
>>ARM: dts: imx6ul-kontron-n6x1x-s: Add vbus-supply and overcurrent
>>  polarity to usb nodes
>>ARM: dts: imx6ul-kontron-n6x1x-s: Remove an obsolete comment and fix
>>  indentation
>>dt-bindings: arm: fsl: Add more Kontron i.MX6UL/ULL compatibles
>>MAINTAINERS: Add an entry for Kontron Electronics ARM board support
> 
> Did you send all patches to same To: and Cc:?

No, I have a script that runs get_maintainer.pl for each patch. So the 
recipients might differ. I only had Krzysztof and Rob as hard-coded 
recipients for the whole series.

Do you think I should change this so each recipient receives the whole 
series?

Thanks,
Frieder

> 
> Regards,
>Marco
> 
>>
>>   .../devicetree/bindings/arm/fsl.yaml  |  14 +
>>   MAINTAINERS   |   6 +
>>   arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts  | 405 +
>>   .../boot/dts/imx6ul-kontron-n6310-som.dtsi|  95 +---
>>   arch/arm/boot/dts/imx6ul-kontron-n6311-s.dts  |  16 +
>>   .../boot/dts/imx6ul-kontron-n6311-som.dtsi|  40 ++
>>   arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi | 422 ++
>>   .../dts/imx6ul-kontron-n6x1x-som-common.dtsi  | 129 ++
>>   arch/arm/boot/dts/imx6ull-kontron-n6411-s.dts |  16 +
>>   .../boot/dts/imx6ull-kontron-n6411-som.dtsi   |  40 ++
>>   10 files changed, 685 insertions(+), 498 deletions(-)
>>   create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6311-s.dts
>>   create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6311-som.dtsi
>>   create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi
>>   create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi
>>   create mode 100644 arch/arm/boot/dts/imx6ull-kontron-n6411-s.dts
>>   create mode 100644 arch/arm/boot/dts/imx6ull-kontron-n6411-som.dtsi
>>
>> -- 
>> 2.17.1
>>
>>
>

Re: [PATCH] sched/fair: util_est: fast ramp-up EWMA on utilization increases

2019-10-17 Thread Peter Zijlstra

On Mon, Oct 14, 2019 at 05:16:02PM +0100, Douglas Raillard wrote:

> random idea: Since these things are much easier to understand by looking at a 
> graph
> of util over time, we may agree on some mailing-list-friendly way to convey 
> graphs.

I don't think that this patch warrants something like that. It is fairly
clear what it does.

For other stuff, maybe.

> For example, a simple CSV with:
> * before/after delimiters (line of # or =)
> * graph title
> * one point per signal transition, so that it can be plotted with gnuplot 
> style "steps" or matplotlib drawstyle='steps-post'
> * consistent column names:
>- time: in seconds (scientific notation for nanoseconds)
>- activation: 1 when the task is actually running, 0 otherwise
> (so it can be turned into transparent coloured bands like using gnuplot 
> filledcurves, like in [1])
>- util: util_avg of the task being talked about
> 
> The delimiters allow writing a scripts to render graphs directly out of an 
> mbox file or ML archive URL.
> This won't solve the issue for the commit message itself, but that may ease 
> the ML discussions.

Something like that could work; mutt can easily pipe emails into
scripts. OTOH gnuplot also has ASCII output, so one can easily stick
something like that into email.

[PATCH RESEND v7 4/6] usb: musb: Add noirq type of dma create interface

2019-10-17 Thread min.guo

From: Min Guo 

Add noirq type of dma create interface for platform which do not
have dedicated DMA interrupt line, move musbhsdma macro definition
to musb_dma.h

Signed-off-by: Min Guo 
---
changes in v7:
1. no changes

changes in v6:
1. no changes

changes in v5:
1. no changes

new patch based on v4:
---
 drivers/usb/musb/musb_dma.h  |  9 
 drivers/usb/musb/musbhsdma.c | 54 ++--
 2 files changed, 46 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 8f60271..05103ea3 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -35,6 +35,12 @@
  *whether shared with the Inventra core or separate.
  */
 
+#define MUSB_HSDMA_BASE0x200
+#define MUSB_HSDMA_INTR(MUSB_HSDMA_BASE + 0)
+#define MUSB_HSDMA_CONTROL 0x4
+#define MUSB_HSDMA_ADDRESS 0x8
+#define MUSB_HSDMA_COUNT   0xc
+
 #defineDMA_ADDR_INVALID(~(dma_addr_t)0)
 
 #ifdef CONFIG_MUSB_PIO_ONLY
@@ -191,6 +197,9 @@ static inline void musb_dma_controller_destroy(struct 
dma_controller *d) { }
 extern struct dma_controller *
 musbhs_dma_controller_create(struct musb *musb, void __iomem *base);
 extern void musbhs_dma_controller_destroy(struct dma_controller *c);
+extern struct dma_controller *
+musbhs_dma_controller_create_noirq(struct musb *musb, void __iomem *base);
+extern irqreturn_t dma_controller_irq(int irq, void *private_data);
 
 extern struct dma_controller *
 tusb_dma_controller_create(struct musb *musb, void __iomem *base);
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 5fc6825..d549c0b 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -10,12 +10,7 @@
 #include 
 #include 
 #include "musb_core.h"
-
-#define MUSB_HSDMA_BASE0x200
-#define MUSB_HSDMA_INTR(MUSB_HSDMA_BASE + 0)
-#define MUSB_HSDMA_CONTROL 0x4
-#define MUSB_HSDMA_ADDRESS 0x8
-#define MUSB_HSDMA_COUNT   0xc
+#include "musb_dma.h"
 
 #define MUSB_HSDMA_CHANNEL_OFFSET(_bchannel, _offset)  \
(MUSB_HSDMA_BASE + (_bchannel << 4) + _offset)
@@ -268,7 +263,7 @@ static int dma_channel_abort(struct dma_channel *channel)
return 0;
 }
 
-static irqreturn_t dma_controller_irq(int irq, void *private_data)
+irqreturn_t dma_controller_irq(int irq, void *private_data)
 {
struct musb_dma_controller *controller = private_data;
struct musb *musb = controller->private_data;
@@ -383,6 +378,7 @@ static irqreturn_t dma_controller_irq(int irq, void 
*private_data)
spin_unlock_irqrestore(&musb->lock, flags);
return retval;
 }
+EXPORT_SYMBOL_GPL(dma_controller_irq);
 
 void musbhs_dma_controller_destroy(struct dma_controller *c)
 {
@@ -398,18 +394,10 @@ void musbhs_dma_controller_destroy(struct dma_controller 
*c)
 }
 EXPORT_SYMBOL_GPL(musbhs_dma_controller_destroy);
 
-struct dma_controller *musbhs_dma_controller_create(struct musb *musb,
-   void __iomem *base)
+static struct musb_dma_controller *
+dma_controller_alloc(struct musb *musb, void __iomem *base)
 {
struct musb_dma_controller *controller;
-   struct device *dev = musb->controller;
-   struct platform_device *pdev = to_platform_device(dev);
-   int irq = platform_get_irq_byname(pdev, "dma");
-
-   if (irq <= 0) {
-   dev_err(dev, "No DMA interrupt line!\n");
-   return NULL;
-   }
 
controller = kzalloc(sizeof(*controller), GFP_KERNEL);
if (!controller)
@@ -423,6 +411,25 @@ struct dma_controller *musbhs_dma_controller_create(struct 
musb *musb,
controller->controller.channel_release = dma_channel_release;
controller->controller.channel_program = dma_channel_program;
controller->controller.channel_abort = dma_channel_abort;
+   return controller;
+}
+
+struct dma_controller *
+musbhs_dma_controller_create(struct musb *musb, void __iomem *base)
+{
+   struct musb_dma_controller *controller;
+   struct device *dev = musb->controller;
+   struct platform_device *pdev = to_platform_device(dev);
+   int irq = platform_get_irq_byname(pdev, "dma");
+
+   if (irq <= 0) {
+   dev_err(dev, "No DMA interrupt line!\n");
+   return NULL;
+   }
+
+   controller = dma_controller_alloc(musb, base);
+   if (!controller)
+   return NULL;
 
if (request_irq(irq, dma_controller_irq, 0,
dev_name(musb->controller), &controller->controller)) {
@@ -437,3 +444,16 @@ struct dma_controller *musbhs_dma_controller_create(struct 
musb *musb,
return &controller->controller;
 }
 EXPORT_SYMBOL_GPL(musbhs_dma_controller_create);
+
+struct dma_controller *
+musbhs_dma_controller_create_noirq(struct musb *musb, void __iomem *base)
+{
+   s

[PATCH RESEND v7 3/6] usb: musb: Add get/set toggle hooks

2019-10-17 Thread min.guo

From: Min Guo 

Add get/set toggle hooks in struct musb_io and struct musb_platform_ops
for special platform; remove function musb_save_toggle, use the set/get
callback to handle toggle.

Signed-off-by: Min Guo 
---
changes in v7:
1. no changes

changes in v6:
1. no changes

changes in v5:
1. no changes

new patch based on v4:
---
 drivers/usb/musb/musb_core.c | 42 
 drivers/usb/musb/musb_core.h |  5 +
 drivers/usb/musb/musb_host.c | 46 ++--
 drivers/usb/musb/musb_io.h   |  4 
 4 files changed, 61 insertions(+), 36 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index bd63450af..690b8da 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -274,6 +274,38 @@ static void musb_default_writew(void __iomem *addr, 
unsigned offset, u16 data)
__raw_writew(data, addr + offset);
 }
 
+static u16 musb_default_get_toggle(struct musb_qh *qh, int is_out)
+{
+   void __iomem *epio = qh->hw_ep->regs;
+   u16 csr;
+
+   if (is_out)
+   csr = musb_readw(epio, MUSB_TXCSR) & MUSB_TXCSR_H_DATATOGGLE;
+   else
+   csr = musb_readw(epio, MUSB_RXCSR) & MUSB_RXCSR_H_DATATOGGLE;
+
+   return csr;
+}
+
+static u16 musb_default_set_toggle(struct musb_qh *qh, int is_out,
+  struct urb *urb)
+{
+   u16 csr;
+   u16 toggle;
+
+   toggle = usb_gettoggle(urb->dev, qh->epnum, is_out);
+
+   if (is_out)
+   csr = toggle ? (MUSB_TXCSR_H_WR_DATATOGGLE
+   | MUSB_TXCSR_H_DATATOGGLE)
+   : MUSB_TXCSR_CLRDATATOG;
+   else
+   csr = toggle ? (MUSB_RXCSR_H_WR_DATATOGGLE
+   | MUSB_RXCSR_H_DATATOGGLE) : 0;
+
+   return csr;
+}
+
 /*
  * Load an endpoint's FIFO
  */
@@ -2271,6 +2303,16 @@ static void musb_deassert_reset(struct work_struct *work)
else
musb->io.write_fifo = musb_default_write_fifo;
 
+   if (musb->ops->get_toggle)
+   musb->io.get_toggle = musb->ops->get_toggle;
+   else
+   musb->io.get_toggle = musb_default_get_toggle;
+
+   if (musb->ops->set_toggle)
+   musb->io.set_toggle = musb->ops->set_toggle;
+   else
+   musb->io.set_toggle = musb_default_set_toggle;
+
if (!musb->xceiv->io_ops) {
musb->xceiv->io_dev = musb->controller;
musb->xceiv->io_priv = musb->mregs;
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 04203b7..9f5a69c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -27,6 +27,7 @@
 struct musb;
 struct musb_hw_ep;
 struct musb_ep;
+struct musb_qh;
 
 /* Helper defines for struct musb->hwvers */
 #define MUSB_HWVERS_MAJOR(x)   ((x >> 10) & 0x1f)
@@ -123,6 +124,8 @@ enum musb_g_ep0_state {
  * @writew:write 16 bits
  * @read_fifo: reads the fifo
  * @write_fifo:writes to fifo
+ * @get_toggle:platform specific get toggle function
+ * @set_toggle:platform specific set toggle function
  * @dma_init:  platform specific dma init function
  * @dma_exit:  platform specific dma exit function
  * @init:  turns on clocks, sets up platform-specific registers, etc
@@ -167,6 +170,8 @@ struct musb_platform_ops {
void(*writew)(void __iomem *addr, unsigned offset, u16 data);
void(*read_fifo)(struct musb_hw_ep *hw_ep, u16 len, u8 *buf);
void(*write_fifo)(struct musb_hw_ep *hw_ep, u16 len, const u8 *buf);
+   u16 (*get_toggle)(struct musb_qh *qh, int is_out);
+   u16 (*set_toggle)(struct musb_qh *qh, int is_out, struct urb *urb);
struct dma_controller *
(*dma_init) (struct musb *musb, void __iomem *base);
void(*dma_exit)(struct dma_controller *c);
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 5a44b70..886c9b6 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -286,26 +286,6 @@ static void musb_giveback(struct musb *musb, struct urb 
*urb, int status)
spin_lock(&musb->lock);
 }
 
-/* For bulk/interrupt endpoints only */
-static inline void musb_save_toggle(struct musb_qh *qh, int is_in,
-   struct urb *urb)
-{
-   void __iomem*epio = qh->hw_ep->regs;
-   u16 csr;
-
-   /*
-* FIXME: the current Mentor DMA code seems to have
-* problems getting toggle correct.
-*/
-
-   if (is_in)
-   csr = musb_readw(epio, MUSB_RXCSR) & MUSB_RXCSR_H_DATATOGGLE;
-   else
-   csr = musb_readw(epio, MUSB_TXCSR) & MUSB_TXCSR_H_DATATOGGLE;
-
-   usb_settoggle(urb->dev, qh->epnum, !is_in, csr ? 1 : 0);
-}
-
 /*
  * Advance this hardware endpoint's queue, completing the specified URB and
  * advancing

[PATCH RESEND v7 0/6] Add MediaTek MUSB Controller Driver

2019-10-17 Thread min.guo

From: Min Guo 

These patches introduce the MediaTek MUSB controller driver.

The driver can be configured as Dual-Role Device (DRD),
Peripheral Only and Host Only modes. This has beed tested on
MT2701 with a variety of devices in host mode and with the 
f_mass gadget driver in peripheral mode, plugging otg cables
in/out a lot of times in all possible imaginable plug orders.

changes in v7:
changes of dt-bindings and DTS:
1. Change compatible string
2. Change usb connector child node compatible as "gpio-usb-b-connector" 

changes in v6:
changes of dt-bindings:
1. Modify usb connector child node
changes of DTS:
1. Modify usb connector child node
changes of driver:
1. Add of_platform_populate in probe to populate connector platform_devices
   from device tree data
2. Replace extcon with usb role switch mechanism to support dual-role mode,
   depends on [1]
3. Remove set vbus function

[1] [v6,09/10] usb: roles: add USB Type-B GPIO connector driver
https://patchwork.kernel.org/patch/10966361/

changes in v5:
changes of dt-bindings suggested by Rob:
1. Modify compatible as 
- compatible : should be one of:
   "mediatek,mt-2701"
   ...
   followed by "mediatek,mtk-musb"
2. Add usb connector child node
changes of DTS:
1. Add usb connector child node
changes of driver suggested by Bin:
1. Replace musb_readb() with musb_clearb() to clear dma pending interrupts
2. Replace musb_readb() with musb_clearb() to clear common/tx/rx pending 
interrupts
3. Make musb_clearb/w() return the value of musb_readb/w()

changes in v4:
changes of dt-bindings suggested by Sergei:
1. String alignment
changes of driver suggested by Tony and Bin:
1. Add a new patch for set/get_toggle()
2. Add a new patch for noirq type of dma
3. Add a new patch musb_clearb/w()
4. Abondon patch "usb: musb: Delete the const attribute of addr parameter in 
readb/w/l hooks"

changes in v3:
changes of driver suggested by Bin:
1. Add a new patch for musb_readb/w/l() to remove const attribute 
2. Use is_out as function parameter in set_toggle/get_toggle() hooks
3. Remove 'u8/u16 data' parameter in clearb/w() hooks
4. Remove musb_default_clearb/w()
5. Replace musb_readb/w() with musb_clearb/w() to clear pending interrupts 
6. Add comments to clearb/w() hooks
7. Replace musb_save_toggle() with musb->io.get_toggle()
8. Replace musb_set_toggle() with musb->io.set_toggle()

changes in v2:
changes of dt-bindings suggested by Rob and Bin:
1. Modify DRC to DRD
2. Drop the "-musb" in compatible
3. Remove phy-names
4. Add space after comma in clock-names
dtsi:
1. Remove phy-names
changes of driver suggested by Bin:
1. Add a new patch for musb_set_toggle
2. Add summarize of MediaTek musb controller differences in the commit log
3. Abondon patch "usb: musb: Move musbhsdma macro definition to musb_dma.h"
4. Add "|| COMPILE_TEST" in Kconfig
5. Add musb_clearb() and musb_clearw() hooks
6. Add get_toggle() and set_toggle() hooks
7. Replace musb_readl() with musb_readw() to read 16bit toggle register
8. Move MediaTek's private toggle registers from musb_regs.h to mediatek.c
9. Create musbhs_dma_controller_create_noirq()

Min Guo (6):
  dt-bindings: usb: musb: Add support for MediaTek musb controller
  arm: dts: mt2701: Add usb2 device nodes
  usb: musb: Add get/set toggle hooks
  usb: musb: Add noirq type of dma create interface
  usb: musb: Add musb_clearb/w() interface
  usb: musb: Add support for MediaTek musb controller

 .../devicetree/bindings/usb/mediatek,musb.txt  |  55 ++
 arch/arm/boot/dts/mt2701-evb.dts   |  21 +
 arch/arm/boot/dts/mt2701.dtsi  |  33 ++
 drivers/usb/musb/Kconfig   |   9 +-
 drivers/usb/musb/Makefile  |   1 +
 drivers/usb/musb/mediatek.c| 582 +
 drivers/usb/musb/musb_core.c   |  74 ++-
 drivers/usb/musb/musb_core.h   |  13 +-
 drivers/usb/musb/musb_dma.h|   9 +
 drivers/usb/musb/musb_host.c   |  46 +-
 drivers/usb/musb/musb_io.h |  12 +-
 drivers/usb/musb/musbhsdma.c   |  56 +-
 drivers/usb/musb/sunxi.c   |   4 +-
 drivers/usb/musb/tusb6010.c|   2 +-
 14 files changed, 845 insertions(+), 72 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
 create mode 100644 drivers/usb/musb/mediatek.c

-- 
1.9.1

[PATCH] tracing: fix "gfp_t" format for synthetic events

2019-10-17 Thread Zhengjun Xing

In the format of synthetic events, the "gfp_t" is shown as "signed:1",
but in fact the "gfp_t" is "unsigned", should be shown as "signed:0".
The offset should be increased by the real size of each field, rather
than by the size of "u64".

The issue can be reproduced by the following commands:

echo 'memlatency u64 lat; unsigned int order; gfp_t gfp_flags; int migratetype' 
> /sys/kernel/debug/tracing/synthetic_events
cat  /sys/kernel/debug/tracing/events/synthetic/memlatency/format

name: memlatency
ID: 2233
format:
field:unsigned short common_type;   offset:0;   size:2; 
signed:0;
field:unsigned char common_flags;   offset:2;   size:1; 
signed:0;
field:unsigned char common_preempt_count;   offset:3;   size:1; 
signed:0;
field:int common_pid;   offset:4;   size:4; signed:1;

field:u64 lat;  offset:8;   size:8; signed:0;
field:unsigned int order;   offset:16;  size:4; signed:0;
field:gfp_t gfp_flags;  offset:24;  size:4; signed:1;
field:int migratetype;  offset:32;  size:4; signed:1;

print fmt: "lat=%llu, order=%u, gfp_flags=%x, migratetype=%d", REC->lat, 
REC->order, REC->gfp_flags, REC->migratetype

Signed-off-by: Zhengjun Xing 
---
 kernel/trace/trace_events_hist.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 57648c5aa679..7d70321d03b1 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -665,7 +665,7 @@ static int synth_event_define_fields(struct 
trace_event_call *call)
offset += STR_VAR_LEN_MAX;
n_u64 += STR_VAR_LEN_MAX / sizeof(u64);
} else {
-   offset += sizeof(u64);
+   offset += size;
n_u64++;
}
}
@@ -679,6 +679,8 @@ static bool synth_field_signed(char *type)
 {
if (str_has_prefix(type, "u"))
return false;
+   if (strcmp(type, "gfp_t") == 0)
+   return false;
 
return true;
 }
-- 
2.17.1

[PATCH RESEND v7 6/6] usb: musb: Add support for MediaTek musb controller

2019-10-17 Thread min.guo

From: Min Guo 

This adds support for MediaTek musb controller in
host, peripheral and otg mode.
There are some quirk of MediaTek musb controller, such as:
 -W1C interrupt status registers
 -Private data toggle registers
 -No dedicated DMA interrupt line

Signed-off-by: Min Guo 
Signed-off-by: Yonglong Wu 
---
changes in v7:
1. no changes

changes in v6:
1. Add of_platform_populate in probe to populate connector platform_devices
   from device tree data
2. Replace extcon with usb role switch mechanism to support dual-role mode
3. Remove set vbus function

changes in v5:
1. Replace musb_readb() with musb_clearb() to clear common/tx/rx pending 
interrupts
2. Make musb_clearb/w() return the value of musb_readb/w()
3. Add driver to get child nodes of usb connector and extcon device

changes in v4:
1. no changes

changes in v3:
suggested by Bin:
1. Remove 'u8/u16 data' parameter in clearb/w() hooks
2. Replace musb_readb/w() with musb_clearb/w() to clear interrupts status

changes in v2:
suggested by Bin:
1. Add summarize of MediaTek musb controller differences in the commit log
2. Add "|| COMPILE_TEST" in Kconfig
3. Move MediaTek's private toggle registers from musb_regs.h to mediatek.c
4. Replace musb_readl() with musb_readw() to read 16bit toggle register
---
 drivers/usb/musb/Kconfig|   9 +-
 drivers/usb/musb/Makefile   |   1 +
 drivers/usb/musb/mediatek.c | 582 
 3 files changed, 591 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/musb/mediatek.c

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 52f8e2b..767c5da 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -116,6 +116,13 @@ config USB_MUSB_JZ4740
depends on USB_MUSB_GADGET
depends on USB=n || USB_OTG_BLACKLIST_HUB
 
+config USB_MUSB_MEDIATEK
+   tristate "MediaTek platforms"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on NOP_USB_XCEIV
+   depends on GENERIC_PHY
+   select USB_ROLE_SWITCH
+
 config USB_MUSB_AM335X_CHILD
tristate
 
@@ -142,7 +149,7 @@ config USB_UX500_DMA
 
 config USB_INVENTRA_DMA
bool 'Inventra'
-   depends on USB_MUSB_OMAP2PLUS
+   depends on USB_MUSB_OMAP2PLUS || USB_MUSB_MEDIATEK
help
  Enable DMA transfers using Mentor's engine.
 
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 3a88c79..63d82d0 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX)  += da8xx.o
 obj-$(CONFIG_USB_MUSB_UX500)   += ux500.o
 obj-$(CONFIG_USB_MUSB_JZ4740)  += jz4740.o
 obj-$(CONFIG_USB_MUSB_SUNXI)   += sunxi.o
+obj-$(CONFIG_USB_MUSB_MEDIATEK)+= mediatek.o
 
 
 obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/mediatek.c b/drivers/usb/musb/mediatek.c
new file mode 100644
index 000..3df8d7e
--- /dev/null
+++ b/drivers/usb/musb/mediatek.c
@@ -0,0 +1,582 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ *
+ * Author:
+ *  Min Guo 
+ *  Yonglong Wu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "musb_core.h"
+#include "musb_dma.h"
+
+#define USB_L1INTS 0x00a0
+#define USB_L1INTM 0x00a4
+#define MTK_MUSB_TXFUNCADDR0x0480
+
+/* MediaTek controller toggle enable and status reg */
+#define MUSB_RXTOG 0x80
+#define MUSB_RXTOGEN   0x82
+#define MUSB_TXTOG 0x84
+#define MUSB_TXTOGEN   0x86
+#define MTK_TOGGLE_EN  GENMASK(15, 0)
+
+#define TX_INT_STATUS  BIT(0)
+#define RX_INT_STATUS  BIT(1)
+#define USBCOM_INT_STATUS  BIT(2)
+#define DMA_INT_STATUS BIT(3)
+
+#define DMA_INTR_STATUS_MSKGENMASK(7, 0)
+#define DMA_INTR_UNMASK_SET_MSKGENMASK(31, 24)
+
+struct mtk_glue {
+   struct device *dev;
+   struct musb *musb;
+   struct platform_device *musb_pdev;
+   struct platform_device *usb_phy;
+   struct phy *phy;
+   struct usb_phy *xceiv;
+   enum phy_mode phy_mode;
+   struct clk *main;
+   struct clk *mcu;
+   struct clk *univpll;
+   enum usb_role role;
+   struct usb_role_switch *role_sw;
+};
+
+static int mtk_musb_clks_get(struct mtk_glue *glue)
+{
+   struct device *dev = glue->dev;
+
+   glue->main = devm_clk_get(dev, "main");
+   if (IS_ERR(glue->main)) {
+   dev_err(dev, "fail to get main clock\n");
+   return PTR_ERR(glue->main);
+   }
+
+   glue->mcu = devm_clk_get(dev, "mcu");
+   if (IS_ERR(glue->mcu)) {
+   dev_err(dev, "fail to get mcu clock\n");
+   return PTR_ERR(glue->mcu);
+   }
+
+   glue->univpll = devm_clk_get(dev, "univpll");
+   if (IS_ERR(glue->univpll)) {
+   dev_err(dev, "fail to get univpll clock\n");
+

[PATCH RESEND v7 2/6] arm: dts: mt2701: Add usb2 device nodes

2019-10-17 Thread min.guo

From: Min Guo 

Add musb nodes and usb2 phy nodes for MT2701

Signed-off-by: Min Guo 
---
changes in v7:
1. Change usb connector child node compatible as "gpio-usb-b-connector" 

changes in v6:
1. Modify usb connector child node

changes in v5:
1. Add usb connector child node

changes in v4:
1. no changes

changes in v3:
1. no changes

changes in v2:
1. Remove phy-names
---
 arch/arm/boot/dts/mt2701-evb.dts | 21 +
 arch/arm/boot/dts/mt2701.dtsi| 33 +
 2 files changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 88f8fd2..05ba43c 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -6,6 +6,7 @@
  */
 
 /dts-v1/;
+#include 
 #include "mt2701.dtsi"
 
 / {
@@ -61,6 +62,15 @@
>;
default-brightness-level = <9>;
};
+
+   usb_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&pio 45 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
 };
 
 &auxadc {
@@ -230,3 +240,14 @@
 &uart0 {
status = "okay";
 };
+
+&usb2 {
+   status = "okay";
+   connector{
+   compatible = "gpio-usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   id-gpios = <&pio 44 GPIO_ACTIVE_HIGH>;
+   vbus-supply = <&usb_vbus>;
+   };
+};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 51e1305..80a3b55 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -671,6 +671,39 @@
};
};
 
+   usb2: usb@1120 {
+   compatible = "mediatek,mt2701-musb",
+"mediatek,mtk-musb";
+   reg = <0 0x1120 0 0x1000>;
+   interrupts = ;
+   interrupt-names = "mc";
+   phys = <&u2port2 PHY_TYPE_USB2>;
+   dr_mode = "otg";
+   clocks = <&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB0_MCU>,
+<&pericfg CLK_PERI_USB_SLV>;
+   clock-names = "main","mcu","univpll";
+   power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
+   status = "disabled";
+   };
+
+   u2phy0: usb-phy@1121 {
+   compatible = "mediatek,generic-tphy-v1";
+   reg = <0 0x1121 0 0x0800>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "okay";
+
+   u2port2: usb-phy@1a1c4800 {
+   reg = <0 0x11210800 0 0x0100>;
+   clocks = <&topckgen CLK_TOP_USB_PHY48M>;
+   clock-names = "ref";
+   #phy-cells = <1>;
+   status = "okay";
+   };
+   };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b00 0 0x1000>;
-- 
1.9.1

[PATCH RESEND v7 1/6] dt-bindings: usb: musb: Add support for MediaTek musb controller

2019-10-17 Thread min.guo

From: Min Guo 

This adds support for MediaTek musb controller in
host, peripheral and otg mode.

Signed-off-by: Min Guo 
---
changes in v7:
1. Modify compatible as
- compatible : should be one of:
   "mediatek,mt2701-musb"
   ...
   followed by "mediatek,mtk-musb"
2. Change usb connector child node compatible as "gpio-usb-b-connector" 

changes in v6:
1. Modify usb connector child node

changes in v5:
suggested by Rob:
1. Modify compatible as 
- compatible : should be one of:
   "mediatek,mt-2701"
   ...
   followed by "mediatek,mtk-musb"
2. Add usb connector child node

changes in v4:
suggested by Sergei:
1. String alignment

changes in v3:
1. no changes

changes in v2:
suggested by Bin:
1. Modify DRC to DRD
suggested by Rob:
2. Drop the "-musb" in compatible
3. Remove phy-names
4. Add space after comma in clock-names
---
 .../devicetree/bindings/usb/mediatek,musb.txt  | 55 ++
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt

diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt 
b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
new file mode 100644
index 000..e53c482
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
@@ -0,0 +1,55 @@
+MediaTek musb DRD/OTG controller
+---
+
+Required properties:
+ - compatible  : should be one of:
+ "mediatek,mt2701-musb"
+ ...
+ followed by "mediatek,mtk-musb"
+ - reg : specifies physical base address and size of
+ the registers
+ - interrupts  : interrupt used by musb controller
+ - interrupt-names : must be "mc"
+ - phys: PHY specifier for the OTG phy
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+ refer to usb/generic.txt
+ - clocks  : a list of phandle + clock-specifier pairs, one for
+ each entry in clock-names
+ - clock-names : must contain "main", "mcu", "univpll"
+ for clocks of controller
+
+Optional properties:
+ - power-domains   : a phandle to USB power domain node to control USB's
+ MTCMOS
+
+Required child nodes:
+ usb connector node as defined in bindings/connector/usb-connector.txt
+Optional properties:
+ - id-gpios: input GPIO for USB ID pin.
+ - vbus-gpios  : input GPIO for USB VBUS pin.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+ dual-role mode
+
+Example:
+
+usb2: usb@1120 {
+   compatible = "mediatek,mt2701-musb",
+"mediatek,mtk-musb";
+   reg = <0 0x1120 0 0x1000>;
+   interrupts = ;
+   interrupt-names = "mc";
+   phys = <&u2port2 PHY_TYPE_USB2>;
+   dr_mode = "otg";
+   clocks = <&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB0_MCU>,
+<&pericfg CLK_PERI_USB_SLV>;
+   clock-names = "main","mcu","univpll";
+   power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
+   connector{
+   compatible = "gpio-usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   id-gpios = <&pio 44 GPIO_ACTIVE_HIGH>;
+   vbus-supply = <&usb_vbus>;
+   };
+};
-- 
1.9.1

[PATCH RESEND v7 5/6] usb: musb: Add musb_clearb/w() interface

2019-10-17 Thread min.guo

From: Min Guo 

Delete the const attribute of addr parameter in readb/w/l hooks, these
changes are for implementing clearing W1C registers.
Replace musb_readb/w with musb_clearb/w to clear the interrupt status.

Signed-off-by: Min Guo 
---
changes in v7:
1. no changes

changes in v6:
1. no changes

changes in v5:
1. Replace musb_readb() with musb_clearb() to clear dma pending interrupts

new patch based on v4:
---
 drivers/usb/musb/musb_core.c | 32 +++-
 drivers/usb/musb/musb_core.h |  8 ++--
 drivers/usb/musb/musb_io.h   |  8 +---
 drivers/usb/musb/musbhsdma.c |  2 +-
 drivers/usb/musb/sunxi.c |  4 ++--
 drivers/usb/musb/tusb6010.c  |  2 +-
 6 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 690b8da..9d4399d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -246,7 +246,7 @@ static u32 musb_default_busctl_offset(u8 epnum, u16 offset)
return 0x80 + (0x08 * epnum) + offset;
 }
 
-static u8 musb_default_readb(const void __iomem *addr, unsigned offset)
+static u8 musb_default_readb(void __iomem *addr, unsigned offset)
 {
u8 data =  __raw_readb(addr + offset);
 
@@ -260,7 +260,7 @@ static void musb_default_writeb(void __iomem *addr, 
unsigned offset, u8 data)
__raw_writeb(data, addr + offset);
 }
 
-static u16 musb_default_readw(const void __iomem *addr, unsigned offset)
+static u16 musb_default_readw(void __iomem *addr, unsigned offset)
 {
u16 data = __raw_readw(addr + offset);
 
@@ -396,19 +396,25 @@ static void musb_default_read_fifo(struct musb_hw_ep 
*hw_ep, u16 len, u8 *dst)
 /*
  * Old style IO functions
  */
-u8 (*musb_readb)(const void __iomem *addr, unsigned offset);
+u8 (*musb_readb)(void __iomem *addr, unsigned offset);
 EXPORT_SYMBOL_GPL(musb_readb);
 
 void (*musb_writeb)(void __iomem *addr, unsigned offset, u8 data);
 EXPORT_SYMBOL_GPL(musb_writeb);
 
-u16 (*musb_readw)(const void __iomem *addr, unsigned offset);
+u8 (*musb_clearb)(void __iomem *addr, unsigned int offset);
+EXPORT_SYMBOL_GPL(musb_clearb);
+
+u16 (*musb_readw)(void __iomem *addr, unsigned offset);
 EXPORT_SYMBOL_GPL(musb_readw);
 
 void (*musb_writew)(void __iomem *addr, unsigned offset, u16 data);
 EXPORT_SYMBOL_GPL(musb_writew);
 
-u32 musb_readl(const void __iomem *addr, unsigned offset)
+u16 (*musb_clearw)(void __iomem *addr, unsigned int offset);
+EXPORT_SYMBOL_GPL(musb_clearw);
+
+u32 musb_readl(void __iomem *addr, unsigned offset)
 {
u32 data = __raw_readl(addr + offset);
 
@@ -1047,7 +1053,6 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 
int_usb,
 static void musb_disable_interrupts(struct musb *musb)
 {
void __iomem*mbase = musb->mregs;
-   u16 temp;
 
/* disable interrupts */
musb_writeb(mbase, MUSB_INTRUSBE, 0);
@@ -1057,9 +1062,9 @@ static void musb_disable_interrupts(struct musb *musb)
musb_writew(mbase, MUSB_INTRRXE, 0);
 
/*  flush pending interrupts */
-   temp = musb_readb(mbase, MUSB_INTRUSB);
-   temp = musb_readw(mbase, MUSB_INTRTX);
-   temp = musb_readw(mbase, MUSB_INTRRX);
+   musb_clearb(mbase, MUSB_INTRUSB);
+   musb_clearw(mbase, MUSB_INTRTX);
+   musb_clearw(mbase, MUSB_INTRRX);
 }
 
 static void musb_enable_interrupts(struct musb *musb)
@@ -2278,10 +2283,19 @@ static void musb_deassert_reset(struct work_struct 
*work)
musb_readb = musb->ops->readb;
if (musb->ops->writeb)
musb_writeb = musb->ops->writeb;
+   if (musb->ops->clearb)
+   musb_clearb = musb->ops->clearb;
+   else
+   musb_clearb = musb_readb;
+
if (musb->ops->readw)
musb_readw = musb->ops->readw;
if (musb->ops->writew)
musb_writew = musb->ops->writew;
+   if (musb->ops->clearw)
+   musb_clearw = musb->ops->clearw;
+   else
+   musb_clearw = musb_readw;
 
 #ifndef CONFIG_MUSB_PIO_ONLY
if (!musb->ops->dma_init || !musb->ops->dma_exit) {
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 9f5a69c..0d9a35f 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -120,8 +120,10 @@ enum musb_g_ep0_state {
  * @fifo_offset: returns the fifo offset
  * @readb: read 8 bits
  * @writeb:write 8 bits
+ * @clearb:could be clear-on-readb or W1C
  * @readw: read 16 bits
  * @writew:write 16 bits
+ * @clearw:could be clear-on-readw or W1C
  * @read_fifo: reads the fifo
  * @write_fifo:writes to fifo
  * @get_toggle:platform specific get toggle function
@@ -164,10 +166,12 @@ struct musb_platform_ops {
u16 fifo_mode;
u32 (*fifo_offset)(u8 epnum);
u32 (*busctl_offset)(u8 epnum, u16 offset);
-   u8  (*readb)(const void __iomem *addr, unsigned offset);
+   u8  (*readb)(void __iomem *addr, un

[RFC] scripts : mkmakefile : change name to create_makefile

2019-10-17 Thread Bhaskar Chowdhury


Hi,

It would be good, if we can change the name of the script to more
explicit name ,which also tell us the purpose of the script by just
looking at it. 


The present name "mkmakefile" is perfectly alright for the people ,who
are technically inclined not so with other, who wants to understand.

This my understanding.

Present Script Name :  mkmakefile

Change Script name  : create_makefile

Please shed some light.

Thanks,
Bhaskar


signature.asc
Description: PGP signature

[PATCH] irqchip: remove redundant semicolon after while

2019-10-17 Thread Daode Huang

check drivers/irqchip with "make coccicheck M=drivers/irqchip/",
it will report unneeded semicolon like below, just remove them.

drivers/irqchip/irq-zevio.c:54:2-3: Unneeded semicolon
drivers/irqchip/irq-gic-v3.c:177:2-3: Unneeded semicolon
drivers/irqchip/irq-gic-v3.c:234:2-3: Unneeded semicolon

Signed-off-by: Daode Huang 
---
 drivers/irqchip/irq-gic-v3.c | 4 ++--
 drivers/irqchip/irq-zevio.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 422664a..58518e5 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -174,7 +174,7 @@ static void gic_do_wait_for_rwp(void __iomem *base)
}
cpu_relax();
udelay(1);
-   };
+   }
 }
 
 /* Wait for completion of a distributor change */
@@ -231,7 +231,7 @@ static void gic_enable_redist(bool enable)
break;
cpu_relax();
udelay(1);
-   };
+   }
if (!count)
pr_err_ratelimited("redistributor failed to %s...\n",
   enable ? "wakeup" : "sleep");
diff --git a/drivers/irqchip/irq-zevio.c b/drivers/irqchip/irq-zevio.c
index 5a7efeb..84163f1 100644
--- a/drivers/irqchip/irq-zevio.c
+++ b/drivers/irqchip/irq-zevio.c
@@ -51,7 +51,7 @@ static void __exception_irq_entry zevio_handle_irq(struct 
pt_regs *regs)
while (readl(zevio_irq_io + IO_STATUS)) {
irqnr = readl(zevio_irq_io + IO_CURRENT);
handle_domain_irq(zevio_irq_domain, irqnr, regs);
-   };
+   }
 }
 
 static void __init zevio_init_irq_base(void __iomem *base)
-- 
2.8.1

Re: [PATCH] quota: minor code cleanup for v1_format_ops

2019-10-17 Thread Jan Kara

On Thu 10-10-19 21:09:24, Chengguang Xu wrote:
> It's not a functinal change, it's just for keeping
> consistent coding style.
> 
> Signed-off-by: Chengguang Xu 

Thanks. Applied.

Honza

> ---
>  fs/quota/quota_v1.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/fs/quota/quota_v1.c b/fs/quota/quota_v1.c
> index c740e5572eb8..cd92e5fa0062 100644
> --- a/fs/quota/quota_v1.c
> +++ b/fs/quota/quota_v1.c
> @@ -217,7 +217,6 @@ static const struct quota_format_ops v1_format_ops = {
>   .check_quota_file   = v1_check_quota_file,
>   .read_file_info = v1_read_file_info,
>   .write_file_info= v1_write_file_info,
> - .free_file_info = NULL,
>   .read_dqblk = v1_read_dqblk,
>   .commit_dqblk   = v1_commit_dqblk,
>  };
> -- 
> 2.21.0
> 
> 
> 
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] fsnotify: move declaration of fsnotify_mark_connector_cachep to fsnotify.h

2019-10-17 Thread Jan Kara

On Tue 15-10-19 14:25:18, Ben Dooks wrote:
> Move fsnotify_mark_connector_cachep to fsnotify.h to properly
> share it with the user in mark.c and avoid the following warning
> from sparse:
> 
> fs/notify/mark.c:82:19: warning: symbol 'fsnotify_mark_connector_cachep' was 
> not declared. Should it be static?
> 
> Signed-off-by: Ben Dooks 

OK, fair enough. Applied. Thanks for the patch.

Honza

> ---
> Cc: Jan Kara 
> Cc: Amir Goldstein 
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  fs/notify/fsnotify.c | 2 --
>  fs/notify/fsnotify.h | 2 ++
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
> index 2ecef6155fc0..3e77b728a22b 100644
> --- a/fs/notify/fsnotify.c
> +++ b/fs/notify/fsnotify.c
> @@ -381,8 +381,6 @@ int fsnotify(struct inode *to_tell, __u32 mask, const 
> void *data, int data_is,
>  }
>  EXPORT_SYMBOL_GPL(fsnotify);
>  
> -extern struct kmem_cache *fsnotify_mark_connector_cachep;
> -
>  static __init int fsnotify_init(void)
>  {
>   int ret;
> diff --git a/fs/notify/fsnotify.h b/fs/notify/fsnotify.h
> index f3462828a0e2..ff2063ec6b0f 100644
> --- a/fs/notify/fsnotify.h
> +++ b/fs/notify/fsnotify.h
> @@ -65,4 +65,6 @@ extern void __fsnotify_update_child_dentry_flags(struct 
> inode *inode);
>  extern struct fsnotify_event_holder *fsnotify_alloc_event_holder(void);
>  extern void fsnotify_destroy_event_holder(struct fsnotify_event_holder 
> *holder);
>  
> +extern struct kmem_cache *fsnotify_mark_connector_cachep;
> +
>  #endif   /* __FS_NOTIFY_FSNOTIFY_H_ */
> -- 
> 2.23.0
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] fsnotify/fdinfo: exportfs_encode_inode_fh() takes pointer as 4th argument

2019-10-17 Thread Jan Kara

On Wed 16-10-19 10:59:55, Ben Dooks (Codethink) wrote:
> The call to exportfs_encode_inode_fh() takes an pointer
> as the 4th argument, so replace the integer 0 with the
> NULL pointer.
> 
> This fixes the following sparse warning:
> 
> fs/notify/fdinfo.c:53:87: warning: Using plain integer as NULL pointer
> 
> Signed-off-by: Ben Dooks 

Thanks for the cleanup! Applied.

Honza

> ---
> Cc: Jan Kara 
> Cc: Amir Goldstein 
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  fs/notify/fdinfo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
> index 1e2bfd26b352..ef83f4020554 100644
> --- a/fs/notify/fdinfo.c
> +++ b/fs/notify/fdinfo.c
> @@ -50,7 +50,7 @@ static void show_mark_fhandle(struct seq_file *m, struct 
> inode *inode)
>   f.handle.handle_bytes = sizeof(f.pad);
>   size = f.handle.handle_bytes >> 2;
>  
> - ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle, 
> &size, 0);
> + ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle, 
> &size, NULL);
>   if ((ret == FILEID_INVALID) || (ret < 0)) {
>   WARN_ONCE(1, "Can't encode file handler for inotify: %d\n", 
> ret);
>   return;
> -- 
> 2.23.0
> 
-- 
Jan Kara 
SUSE Labs, CR

[PATCH v4 0/5] Add support for mt2701 JPEG ENC support

2019-10-17 Thread Xia Jiang

This patchset add support for mt2701 JPEG ENC support.

This is the compliance test result for jpeg dec and enc.

The JPEG dec log:   

v4l2-compliance -d /dev/video0  
   
v4l2-compliance SHA: b51e9a8a74eed6da15127fe5eadf515914347f76, 32 bits  
   

   
Compliance test for mtk-jpeg device /dev/video0:
   

   
Driver Info:
   
Driver name  : mtk-jpeg 
   
Card type: mtk-jpeg decoder 
   
Bus info : platform:15004000.jpegdec
   
Driver version   : 5.4.0
   
Capabilities : 0x84204000   
   
Video Memory-to-Memory Multiplanar  
   
Streaming   
   
Extended Pix Format 
   
Device Capabilities 
   
Device Caps  : 0x04204000   
   
Video Memory-to-Memory Multiplanar  
   
Streaming   
   
Extended Pix Format 
   
Detected JPEG Decoder   
   

   
Required ioctls:
   
test VIDIOC_QUERYCAP: OK
   

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

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

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

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

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

[PATCH v4 1/5] media: dt-bindings: Add jpeg enc device tree node document

2019-10-17 Thread Xia Jiang

Add jpeg enc device tree node document

Reviewed-by: Rob Herring 
Signed-off-by: Xia Jiang 
---
v4: no changes

v3: change compatible to SoC specific compatible

v2: no changes
---
 .../bindings/media/mediatek-jpeg-encoder.txt  | 37 +++
 1 file changed, 37 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt 
b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
new file mode 100644
index ..fa8da699493b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -0,0 +1,37 @@
+* MediaTek JPEG Encoder
+
+MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs
+
+Required properties:
+- compatible : should be one of:
+   "mediatek,mt2701-jpgenc"
+   ...
+   followed by "mediatek,mtk-jpgenc"
+- reg : physical base address of the JPEG encoder registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgenc". It is the clock of JPEG encoder.
+- power-domains: a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current SoCs, see
+  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+  for details.
+- iommus: should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+
+Example:
+   jpegenc: jpegenc@1500a000 {
+   compatible = "mediatek,mt2701-jpgenc",
+"mediatek,mtk-jpgenc";
+   reg = <0 0x1500a000 0 0x1000>;
+   interrupts = ;
+   clocks =  <&imgsys CLK_IMG_VENC>;
+   clock-names = "jpgenc";
+   power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <&larb2>;
+   iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>,
+<&iommu MT2701_M4U_PORT_JPGENC_BSDMA>;
+   };
-- 
2.18.0

[PATCH v4 3/5] media: platform: Rename jpeg dec file name

2019-10-17 Thread Xia Jiang

Rename the files which are for decode feature. This is preparing
path since the jpeg enc patch will be added later.

Signed-off-by: Xia Jiang 
---
v4: no changes

v3: no changes

v2: no changes
---
 drivers/media/platform/mtk-jpeg/Makefile  | 2 +-
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c   | 4 ++--
 .../platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c}| 2 +-
 .../platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h}| 2 +-
 .../mtk-jpeg/{mtk_jpeg_parse.c => mtk_jpeg_dec_parse.c}   | 2 +-
 .../mtk-jpeg/{mtk_jpeg_parse.h => mtk_jpeg_dec_parse.h}   | 2 +-
 .../platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h}  | 0
 7 files changed, 7 insertions(+), 7 deletions(-)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c} 
(99%)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h} 
(98%)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.c => 
mtk_jpeg_dec_parse.c} (98%)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.h => 
mtk_jpeg_dec_parse.h} (92%)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h} 
(100%)

diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
index 92a4fc046bfe..48516dcf96e6 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0-only
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index ee802fc3bcdf..5f0990fce8ef 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -23,9 +23,9 @@
 #include 
 #include 
 
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
 #include "mtk_jpeg_core.h"
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
 
 static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
{
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
similarity index 99%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
index ddf0dfa78e20..922dbe421fae 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
 
 #define MTK_JPEG_DUNUM_MASK(val)   (((val) - 1) & 0x3)
 
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
similarity index 98%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
index 9c6584eaad99..a37be1a48415 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
@@ -11,7 +11,7 @@
 #include 
 
 #include "mtk_jpeg_core.h"
-#include "mtk_jpeg_reg.h"
+#include "mtk_jpeg_dec_reg.h"
 
 enum {
MTK_JPEG_DEC_RESULT_EOF_DONE= 0,
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
similarity index 98%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
index f862d38f3af7..b95c45791c29 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
 
 #define TEM0x01
 #define SOF0   0xc0
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
similarity index 92%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
index 0a48eeabaff2..2918f15811f8 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
@@ -8,7 +8,7 @@
 #ifndef _MTK_JPEG_PARSE_H
 #define _MTK_JPEG_PARSE_H
 
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
 
 bool mtk_jpeg_parse(struct mtk_jpeg_dec_param *param, u8 *src_addr_va,
u32 src_size);
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
similarity index 100%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
-- 
2.18.0

[PATCH v4 2/5] arm: dts: Add jpeg enc device tree node

2019-10-17 Thread Xia Jiang

Add jpeg enc device tree node

Signed-off-by: Xia Jiang 
---
v4: no changes

v3: change compatible to SoC specific compatible

v2: no changes
---
 arch/arm/boot/dts/mt2701.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 51e1305c6471..f2f92150b3fb 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -569,6 +569,19 @@
 <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
 
+   jpegenc: jpegenc@1500a000 {
+   compatible = "mediatek,mt2701-jpgenc",
+"mediatek,mtk-jpgenc";
+   reg = <0 0x1500a000 0 0x1000>;
+   interrupts = ;
+   clocks =  <&imgsys CLK_IMG_VENC>;
+   clock-names = "jpgenc";
+   power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <&larb2>;
+   iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>,
+<&iommu MT2701_M4U_PORT_JPGENC_BSDMA>;
+   };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
-- 
2.18.0

[PATCH v4 4/5] media: platform: Fix v4l2-compliance test bug

2019-10-17 Thread Xia Jiang

Improve subscribe event handling: let v4l2_ctrl_subscribe_event() do the
job for other types except V4L2_EVENT_SOURCE_CHANGE.
Add checking created buffer size follow in mtk_jpeg_queue_setup().

Signed-off-by: Xia Jiang 
---
v4: new add patch for v4l2-compliance test bug fix
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 5f0990fce8ef..abc506a552c1 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -446,9 +446,9 @@ static int mtk_jpeg_subscribe_event(struct v4l2_fh *fh,
switch (sub->type) {
case V4L2_EVENT_SOURCE_CHANGE:
return v4l2_src_change_event_subscribe(fh, sub);
-   default:
-   return -EINVAL;
}
+
+   return v4l2_ctrl_subscribe_event(fh, sub);
 }
 
 static int mtk_jpeg_g_selection(struct file *file, void *priv,
@@ -571,6 +571,13 @@ static int mtk_jpeg_queue_setup(struct vb2_queue *q,
if (!q_data)
return -EINVAL;
 
+   if (*num_planes) {
+   for (i = 0; i < *num_planes; i++)
+   if (sizes[i] < q_data->sizeimage[i])
+   return -EINVAL;
+   return 0;
+   }
+
*num_planes = q_data->fmt->colplanes;
for (i = 0; i < q_data->fmt->colplanes; i++) {
sizes[i] = q_data->sizeimage[i];
-- 
2.18.0

[PATCH v4 5/5] media: platform: Add jpeg dec/enc feature

2019-10-17 Thread Xia Jiang

Add mtk jpeg encode v4l2 driver based on jpeg decode, because that jpeg
decode and encode have great similarities with function operation.

Signed-off-by: Xia Jiang 
---
v4: split mtk_jpeg_try_fmt_mplane() to two functions, one for encoder,
one for decoder.
split mtk_jpeg_set_default_params() to two functions, one for
encoder, one for decoder.
add cropping support for encoder in g/s_selection ioctls.
change exif mode support by using V4L2_JPEG_ACTIVE_MARKER_APP1.
change MTK_JPEG_MAX_WIDTH/MTK_JPEG_MAX_HEIGH from 8192 to 65535 by
specification.
move width shifting operation behind aligning operation in
mtk_jpeg_try_enc_fmt_mplane() for bug fix.
fix user abuseing data_offset issue for DMABUF in
mtk_jpeg_set_enc_src().
fix kbuild warings: change MTK_JPEG_MIN_HEIGHT/MTK_JPEG_MAX_HEIGHT
and MTK_JPEG_MIN_WIDTH/MTK_JPEG_MAX_WIDTH from
'int' type to 'unsigned int' type.
fix msleadingly indented of 'else'.

v3: delete Change-Id.
only test once handler->error after the last v4l2_ctrl_new_std().
seperate changes of v4l2-ctrls.c and v4l2-controls.h to new patch.

v2: fix compliance test fail, check created buffer size in driver.
---
 drivers/media/platform/mtk-jpeg/Makefile  |   5 +-
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 731 +++---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.h   | 123 ++-
 .../media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h |   7 +-
 .../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c | 175 +
 .../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h |  60 ++
 .../platform/mtk-jpeg/mtk_jpeg_enc_reg.h  |  49 ++
 7 files changed, 1004 insertions(+), 146 deletions(-)
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_reg.h

diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
index 48516dcf96e6..76c33aad0f3f 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,3 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o \
+mtk_jpeg_dec_hw.o \
+mtk_jpeg_dec_parse.o \
+mtk_jpeg_enc_hw.o
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index abc506a552c1..087b62bb1d5c 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2016 MediaTek Inc.
  * Author: Ming Hsiu Tsai 
  * Rick Chang 
+ * Xia Jiang 
  */
 
 #include 
@@ -23,6 +24,7 @@
 #include 
 #include 
 
+#include "mtk_jpeg_enc_hw.h"
 #include "mtk_jpeg_dec_hw.h"
 #include "mtk_jpeg_core.h"
 #include "mtk_jpeg_dec_parse.h"
@@ -31,7 +33,8 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
{
.fourcc = V4L2_PIX_FMT_JPEG,
.colplanes  = 1,
-   .flags  = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_OUTPUT |
+ MTK_JPEG_FMT_FLAG_ENC_CAPTURE,
},
{
.fourcc = V4L2_PIX_FMT_YUV420M,
@@ -51,6 +54,42 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
.v_align= 3,
.flags  = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
},
+   {
+   .fourcc = V4L2_PIX_FMT_NV12M,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 2, 2},
+   .colplanes  = 2,
+   .h_align= 4,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_NV21M,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 2, 2},
+   .colplanes  = 2,
+   .h_align= 4,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_YUYV,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 4, 4},
+   .colplanes  = 1,
+   .h_align= 4,
+   .v_align= 3,
+   .flags  = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_YVYU,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 4, 4},
+   .colplanes  = 1,
+   .h_align= 4,
+   .v_align= 3,
+   .flag

Re: [Patch v3 2/7] sched: Add infrastructure to store and update instantaneous thermal pressure

2019-10-17 Thread Vincent Guittot

Hi Thara,

On Wed, 16 Oct 2019 at 23:22, Thara Gopinath  wrote:
>
> Hi Vincent,
>
> Thanks for the review
> On 10/14/2019 11:50 AM, Vincent Guittot wrote:
> > Hi Thara,
> >
> > On Mon, 14 Oct 2019 at 02:58, Thara Gopinath  
> > wrote:
> >>
> >> Add thermal.c and thermal.h files that provides interface
> >> APIs to initialize, update/average, track, accumulate and decay
> >> thermal pressure per cpu basis. A per cpu structure max_capacity_info is
> >> introduced to keep track of instantaneous per cpu thermal pressure.
> >> Thermal pressure is the delta between max_capacity and cap_capacity.
> >> API update_periodic_maxcap is called for periodic accumulate and decay
> >> of the thermal pressure. It is to to be called from a periodic tick
> >> function. This API calculates the delta between max_capacity and
> >> cap_capacity and passes on the delta to update_thermal_avg to do the
> >> necessary accumulate, decay and average. API update_maxcap_capacity is for
> >> the system to update the thermal pressure by updating cap_capacity.
> >> Considering, update_periodic_maxcap reads cap_capacity and
> >> update_maxcap_capacity writes into cap_capacity, one can argue for
> >> some sort of locking mechanism to avoid a stale value.
> >> But considering update_periodic_maxcap can be called from a system
> >> critical path like scheduler tick function, a locking mechanism is not
> >> ideal. This means that it is possible the value used to
> >> calculate average thermal pressure for a cpu can be stale for upto 1
> >> tick period.
> >>
> >> Signed-off-by: Thara Gopinath 
> >> ---
> >>  include/linux/sched.h  | 14 +++
> >>  kernel/sched/Makefile  |  2 +-
> >>  kernel/sched/thermal.c | 66 
> >> ++
> >>  kernel/sched/thermal.h | 13 ++
> >>  4 files changed, 94 insertions(+), 1 deletion(-)
> >>  create mode 100644 kernel/sched/thermal.c
> >>  create mode 100644 kernel/sched/thermal.h
> >>
> >> diff --git a/include/linux/sched.h b/include/linux/sched.h
> >> index 2c2e56b..875ce2b 100644
> >> --- a/include/linux/sched.h
> >> +++ b/include/linux/sched.h
> >> @@ -1983,6 +1983,20 @@ static inline void rseq_syscall(struct pt_regs 
> >> *regs)
> >>
> >>  #endif
> >>
> >> +#ifdef CONFIG_SMP
> >> +void update_maxcap_capacity(int cpu, u64 capacity);
> >> +
> >> +void populate_max_capacity_info(void);
> >> +#else
> >> +static inline void update_maxcap_capacity(int cpu, u64 capacity)
> >> +{
> >> +}
> >> +
> >> +static inline void populate_max_capacity_info(void)
> >> +{
> >> +}
> >> +#endif
> >> +
> >>  const struct sched_avg *sched_trace_cfs_rq_avg(struct cfs_rq *cfs_rq);
> >>  char *sched_trace_cfs_rq_path(struct cfs_rq *cfs_rq, char *str, int len);
> >>  int sched_trace_cfs_rq_cpu(struct cfs_rq *cfs_rq);
> >> diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
> >> index 21fb5a5..4d3b820 100644
> >> --- a/kernel/sched/Makefile
> >> +++ b/kernel/sched/Makefile
> >> @@ -20,7 +20,7 @@ obj-y += core.o loadavg.o clock.o cputime.o
> >>  obj-y += idle.o fair.o rt.o deadline.o
> >>  obj-y += wait.o wait_bit.o swait.o completion.o
> >>
> >> -obj-$(CONFIG_SMP) += cpupri.o cpudeadline.o topology.o stop_task.o pelt.o
> >> +obj-$(CONFIG_SMP) += cpupri.o cpudeadline.o topology.o stop_task.o pelt.o 
> >> thermal.o
> >>  obj-$(CONFIG_SCHED_AUTOGROUP) += autogroup.o
> >>  obj-$(CONFIG_SCHEDSTATS) += stats.o
> >>  obj-$(CONFIG_SCHED_DEBUG) += debug.o
> >> diff --git a/kernel/sched/thermal.c b/kernel/sched/thermal.c
> >> new file mode 100644
> >> index 000..5f0b2d4
> >> --- /dev/null
> >> +++ b/kernel/sched/thermal.c
> >> @@ -0,0 +1,66 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Sceduler Thermal Interactions
> >> + *
> >> + *  Copyright (C) 2018 Linaro, Inc., Thara Gopinath 
> >> 
> >> + */
> >> +
> >> +#include 
> >> +#include "sched.h"
> >> +#include "pelt.h"
> >> +#include "thermal.h"
> >> +
> >> +struct max_capacity_info {
> >> +   unsigned long max_capacity;
> >> +   unsigned long cap_capacity;
> >> +};
> >> +
> >> +static DEFINE_PER_CPU(struct max_capacity_info, max_cap);
> >> +
> >> +void update_maxcap_capacity(int cpu, u64 capacity)
> >> +{
> >> +   struct max_capacity_info *__max_cap;
> >> +   unsigned long __capacity;
> >> +
> >> +   __max_cap = (&per_cpu(max_cap, cpu));
> >> +   if (!__max_cap) {
> >> +   pr_err("no max_capacity_info structure for cpu %d\n", cpu);
> >> +   return;
> >> +   }
> >> +
> >> +   /* Normalize the capacity */
> >> +   __capacity = (capacity * arch_scale_cpu_capacity(cpu)) >>
> >> +   
> >> SCHED_CAPACITY_SHIFT;
> >> +   pr_debug("updating cpu%d capped capacity from %lu to %lu\n", cpu, 
> >> __max_cap->cap_capacity, __capacity);
> >> +
> >> +   __max_cap->cap_capacity = __capacity;
> >> +}
> >> +
> >> +void populate_max_capacity_info(void)
> >> +{
> >> +   struct max_capacity_info *__max_cap;
> >> +

Re: [PATCH 4/4] uprobe: only do FOLL_SPLIT_PMD for uprobe register

2019-10-17 Thread Oleg Nesterov

On 10/16, Song Liu wrote:
>
> > On Oct 16, 2019, at 5:10 AM, Oleg Nesterov  wrote:
> >
> >> @@ -489,6 +492,9 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, 
> >> struct mm_struct *mm,
> >>if (ret <= 0)
> >>goto put_old;
> >>
> >> +  WARN(!is_register && PageCompound(old_page),
> >> +   "uprobe unregister should never work on compound page\n");
> >
> > But this can happen with the change above. You can't know if *vaddr was
> > previously changed by install_breakpoint() or not.
>
> > If not, verify_opcode() should likely save us, but we can't rely on it.
> > Say, someone can write "int3" into vm_file at uprobe->offset.
>
> I think this won't really happen. With is_register == false, we already
> know opcode is not "int3", so current call must be from set_orig_insn().
> Therefore, old_page must be installed by uprobe, and cannot be compound.
>
> The other way is not guaranteed. With is_register == true, it is still
> possible current call is from set_orig_insn(). However, we do not rely
> on this path.

Quite contrary.

When is_register == true we know that a) the caller is install_breakpoint()
and b) the original insn is NOT int3 unless this page was alreadt COW'ed by
userspace, say, by gdb.

If is_register == false we only know that the caller is remove_breakpoint().
We can't know if this page was COW'ed by uprobes or userspace, we can not
know if the insn we are going to replace is int3 or not, thus we can not
assume that verify_opcode() will fail and save us.

Oleg.

Re: [PATCH v3 4/7] thermal: Add generic power domain warming device driver.

2019-10-17 Thread Ulf Hansson

On Wed, 16 Oct 2019 at 21:37, Thara Gopinath  wrote:
>
> Resources modeled as power domains in linux kenrel
> can  be used to warm the SoC(eg. mx power domain on sdm845).
> To support this feature, introduce a generic power domain
> warming device driver that can be plugged into the thermal framework
> (The thermal framework itself requires further modifiction to
> support a warming device in place of a cooling device.
> Those extensions are not introduced in this patch series).
>
> Signed-off-by: Thara Gopinath 
> ---
>  drivers/thermal/Kconfig  |  10 +++
>  drivers/thermal/Makefile |   2 +
>  drivers/thermal/pwr_domain_warming.c | 136 
> +++
>  include/linux/pwr_domain_warming.h   |  31 
>  4 files changed, 179 insertions(+)
>  create mode 100644 drivers/thermal/pwr_domain_warming.c
>  create mode 100644 include/linux/pwr_domain_warming.h
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 001a21a..0c5c93e 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -187,6 +187,16 @@ config DEVFREQ_THERMAL
>
>   If you want this support, you should say Y here.
>
> +config PWR_DOMAIN_WARMING_THERMAL
> +   bool "Power Domain based warming device"
> +   depends on PM_GENERIC_DOMAINS_OF
> +   help
> + This implements the generic power domain based warming
> + mechanism through increasing the performance state of
> + a power domain.
> +
> + If you want this support, you should say Y here.
> +
>  config THERMAL_EMULATION
> bool "Thermal emulation mode support"
> help
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 74a37c7..382c64a 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -27,6 +27,8 @@ thermal_sys-$(CONFIG_CLOCK_THERMAL)   += clock_cooling.o
>  # devfreq cooling
>  thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>
> +thermal_sys-$(CONFIG_PWR_DOMAIN_WARMING_THERMAL)   += 
> pwr_domain_warming.o
> +
>  # platform thermal drivers
>  obj-y  += broadcom/
>  obj-$(CONFIG_THERMAL_MMIO) += thermal_mmio.o
> diff --git a/drivers/thermal/pwr_domain_warming.c 
> b/drivers/thermal/pwr_domain_warming.c
> new file mode 100644
> index 000..60fae3e
> --- /dev/null
> +++ b/drivers/thermal/pwr_domain_warming.c
> @@ -0,0 +1,136 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019, Linaro Ltd
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct pd_warming_device {
> +   struct thermal_cooling_device *cdev;
> +   struct generic_pm_domain *gpd;

No, this isn't a genpd provider and thus we should not need to carry
the above pointer in the struct pd_warming_device.

> +   struct device *dev;
> +   int max_state;
> +   int cur_state;
> +   bool runtime_resumed;
> +};
> +
> +static int pd_wdev_get_max_state(struct thermal_cooling_device *cdev,
> +unsigned long *state)
> +{
> +   struct pd_warming_device *pd_wdev = cdev->devdata;
> +
> +   *state = pd_wdev->max_state;
> +   return 0;
> +}
> +
> +static int pd_wdev_get_cur_state(struct thermal_cooling_device *cdev,
> +unsigned long *state)
> +{
> +   struct pd_warming_device *pd_wdev = cdev->devdata;
> +
> +   *state = dev_pm_genpd_get_performance_state(pd_wdev->dev);
> +
> +   return 0;
> +}
> +
> +static int pd_wdev_set_cur_state(struct thermal_cooling_device *cdev,
> +unsigned long state)
> +{
> +   struct pd_warming_device *pd_wdev = cdev->devdata;
> +   struct device *dev = pd_wdev->dev;
> +   int ret;
> +
> +   ret = dev_pm_genpd_set_performance_state(dev, state);
> +
> +   if (ret)
> +   return ret;
> +
> +   if (state && !pd_wdev->runtime_resumed) {
> +   ret = pm_runtime_get_sync(dev);
> +   pd_wdev->runtime_resumed = true;
> +   } else if (!state && pd_wdev->runtime_resumed) {
> +   ret = pm_runtime_put(dev);
> +   pd_wdev->runtime_resumed = false;
> +   }
> +
> +   return ret;
> +}
> +
> +static int pd_wdev_late_init(struct thermal_cooling_device *cdev)
> +{
> +   struct pd_warming_device *pd_wdev = cdev->devdata;
> +   struct device *dev = &cdev->device;
> +   int state_count, ret;
> +
> +   ret = pm_genpd_add_device(pd_wdev->gpd, dev);

The pm_genpd_add_device() is a legacy interface and we are striving to
remove it. I think there are two better options for you to use to deal
with the attach thingy.

1. The easiest one is probably just to convert into using
of_genpd_add_device() instead. I think you already have the
information that you need in the ->cdev pointer to do that. However,
that also means you need to add the ->late_init() callb

Re: [PATCH v2 2/3] HID: logitech-hidpp: rework device validation

2019-10-17 Thread Benjamin Tissoires

On Wed, Oct 16, 2019 at 9:38 PM Andrey Smirnov  wrote:
>
> On Wed, Oct 16, 2019 at 12:24 PM Benjamin Tissoires
>  wrote:
> >
> > Hi Andrey,
> >
> > On Wed, Oct 16, 2019 at 8:30 PM Andrey Smirnov  
> > wrote:
> > >
> > > G920 device only advertises REPORT_ID_HIDPP_LONG and
> > > REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying
> > > for REPORT_ID_HIDPP_SHORT with optional=false will always fail and
> > > prevent G920 to be recognized as a valid HID++ device.
> > >
> > > To fix this and improve some other aspects, modify
> > > hidpp_validate_device() as follows:
> > >
> > >   - Inline the code of hidpp_validate_report() to simplify
> > > distingushing between non-present and invalid report descriptors
> > >
> > >   - Drop the check for id >= HID_MAX_IDS || id < 0 since all of our
> > > IDs are static and known to satisfy that at compile time
> > >
> > >   - Change the algorithms to check all possible report
> > > types (including very long report) and deem the device as a valid
> > > HID++ device if it supports at least one
> > >
> > >   - Treat invalid report length as a hard stop for the validation
> > > algorithm, meaning that if any of the supported reports has
> > > invalid length we assume the worst and treat the device as a
> > > generic HID device.
> > >
> > >   - Fold initialization of hidpp->very_long_report_length into
> > > hidpp_validate_device() since it already fetches very long report
> > > length and validates its value
> > >
> > > Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to be 
> > > handled by this module")
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191
> > > Reported-by: Sam Bazely 
> > > Signed-off-by: Andrey Smirnov 
> > > Cc: Jiri Kosina 
> > > Cc: Benjamin Tissoires 
> > > Cc: Henrik Rydberg 
> > > Cc: Pierre-Loup A. Griffais 
> > > Cc: Austin Palmer 
> > > Cc: linux-in...@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: sta...@vger.kernel.org # 5.2+
> > > ---
> > >  drivers/hid/hid-logitech-hidpp.c | 54 ++--
> > >  1 file changed, 30 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/hid/hid-logitech-hidpp.c 
> > > b/drivers/hid/hid-logitech-hidpp.c
> > > index 85911586b3b6..8c4be991f387 100644
> > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > @@ -3498,34 +3498,45 @@ static int hidpp_get_report_length(struct 
> > > hid_device *hdev, int id)
> > > return report->field[0]->report_count + 1;
> > >  }
> > >
> > > -static bool hidpp_validate_report(struct hid_device *hdev, int id,
> > > - int expected_length, bool optional)
> > > +static bool hidpp_validate_device(struct hid_device *hdev)
> > >  {
> > > -   int report_length;
> > > +   struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> > > +   int id, report_length, supported_reports = 0;
> > > +
> > > +   id = REPORT_ID_HIDPP_SHORT;
> > > +   report_length = hidpp_get_report_length(hdev, id);
> > > +   if (report_length) {
> > > +   if (report_length < HIDPP_REPORT_SHORT_LENGTH)
> > > +   goto bad_device;
> > >
> > > -   if (id >= HID_MAX_IDS || id < 0) {
> > > -   hid_err(hdev, "invalid HID report id %u\n", id);
> > > -   return false;
> > > +   supported_reports++;
> > > }
> > >
> > > +   id = REPORT_ID_HIDPP_LONG;
> > > report_length = hidpp_get_report_length(hdev, id);
> > > -   if (!report_length)
> > > -   return optional;
> > > +   if (report_length) {
> > > +   if (report_length < HIDPP_REPORT_LONG_LENGTH)
> > > +   goto bad_device;
> > >
> > > -   if (report_length < expected_length) {
> > > -   hid_warn(hdev, "not enough values in hidpp report %d\n", 
> > > id);
> > > -   return false;
> > > +   supported_reports++;
> > > }
> > >
> > > -   return true;
> > > -}
> > > +   id = REPORT_ID_HIDPP_VERY_LONG;
> > > +   report_length = hidpp_get_report_length(hdev, id);
> > > +   if (report_length) {
> > > +   if (report_length > HIDPP_REPORT_LONG_LENGTH &&
> > > +   report_length < HIDPP_REPORT_VERY_LONG_MAX_LENGTH)
> >
> > Can you double check the conditions here?
> > It's late, but I think you inverted the tests as we expect the report
> > length to be between HIDPP_REPORT_LONG_LENGTH and
> > HIDPP_REPORT_VERY_LONG_MAX_LENGTH inclusive, while here this creates a
> > bad_device.
>
> Hmm, I think you are right. Not sure why I didn't catch it on G920
> since it support very long reports AFAIR. Will re-spin and double
> check in v3. Sorry about that.
>

Oh, the issue is that the very long HID++ reports on the G920 are
HIDPP_REPORT_VERY_LONG_MAX_LENGTH long, which means the test will fail
for those.

Cheers,
Benjamin

Re: [PATCH v9 01/22] RISC-V: Add bitmap reprensenting ISA features common across CPUs

2019-10-17 Thread Anup Patel

Hi Paul,

On Wed, Oct 16, 2019 at 9:38 PM Anup Patel  wrote:
>
> This patch adds riscv_isa bitmap which represents Host ISA features
> common across all Host CPUs. The riscv_isa is not same as elf_hwcap
> because elf_hwcap will only have ISA features relevant for user-space
> apps whereas riscv_isa will have ISA features relevant to both kernel
> and user-space apps.
>
> One of the use-case for riscv_isa bitmap is in KVM hypervisor where
> we will use it to do following operations:
>
> 1. Check whether hypervisor extension is available
> 2. Find ISA features that need to be virtualized (e.g. floating
>point support, vector extension, etc.)
>
> Signed-off-by: Anup Patel 
> Signed-off-by: Atish Patra 
> Reviewed-by: Alexander Graf 

Can you consider this patch for Linux-5.4-rcX ??

Regards,
Anup

> ---
>  arch/riscv/include/asm/hwcap.h | 22 +
>  arch/riscv/kernel/cpufeature.c | 83 --
>  2 files changed, 102 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index 7ecb7c6a57b1..5989dd4426d1 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -8,6 +8,7 @@
>  #ifndef __ASM_HWCAP_H
>  #define __ASM_HWCAP_H
>
> +#include 
>  #include 
>
>  #ifndef __ASSEMBLY__
> @@ -22,5 +23,26 @@ enum {
>  };
>
>  extern unsigned long elf_hwcap;
> +
> +#define RISCV_ISA_EXT_a('a' - 'a')
> +#define RISCV_ISA_EXT_c('c' - 'a')
> +#define RISCV_ISA_EXT_d('d' - 'a')
> +#define RISCV_ISA_EXT_f('f' - 'a')
> +#define RISCV_ISA_EXT_h('h' - 'a')
> +#define RISCV_ISA_EXT_i('i' - 'a')
> +#define RISCV_ISA_EXT_m('m' - 'a')
> +#define RISCV_ISA_EXT_s('s' - 'a')
> +#define RISCV_ISA_EXT_u('u' - 'a')
> +
> +#define RISCV_ISA_EXT_MAX  256
> +
> +unsigned long riscv_isa_extension_base(const unsigned long *isa_bitmap);
> +
> +#define riscv_isa_extension_mask(ext) BIT_MASK(RISCV_ISA_EXT_##ext)
> +
> +bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int 
> bit);
> +#define riscv_isa_extension_available(isa_bitmap, ext) \
> +   __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_##ext)
> +
>  #endif
>  #endif
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index eaad5aa07403..64068d36658d 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -6,21 +6,64 @@
>   * Copyright (C) 2017 SiFive
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>
>  unsigned long elf_hwcap __read_mostly;
> +
> +/* Host ISA bitmap */
> +static DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX) __read_mostly;
> +
>  #ifdef CONFIG_FPU
>  bool has_fpu __read_mostly;
>  #endif
>
> +/**
> + * riscv_isa_extension_base() - Get base extension word
> + *
> + * @isa_bitmap: ISA bitmap to use
> + * Return: base extension word as unsigned long value
> + *
> + * NOTE: If isa_bitmap is NULL then Host ISA bitmap will be used.
> + */
> +unsigned long riscv_isa_extension_base(const unsigned long *isa_bitmap)
> +{
> +   if (!isa_bitmap)
> +   return riscv_isa[0];
> +   return isa_bitmap[0];
> +}
> +EXPORT_SYMBOL_GPL(riscv_isa_extension_base);
> +
> +/**
> + * __riscv_isa_extension_available() - Check whether given extension
> + * is available or not
> + *
> + * @isa_bitmap: ISA bitmap to use
> + * @bit: bit position of the desired extension
> + * Return: true or false
> + *
> + * NOTE: If isa_bitmap is NULL then Host ISA bitmap will be used.
> + */
> +bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int 
> bit)
> +{
> +   const unsigned long *bmap = (isa_bitmap) ? isa_bitmap : riscv_isa;
> +
> +   if (bit >= RISCV_ISA_EXT_MAX)
> +   return false;
> +
> +   return test_bit(bit, bmap) ? true : false;
> +}
> +EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
> +
>  void riscv_fill_hwcap(void)
>  {
> struct device_node *node;
> const char *isa;
> -   size_t i;
> +   char print_str[BITS_PER_LONG+1];
> +   size_t i, j, isa_len;
> static unsigned long isa2hwcap[256] = {0};
>
> isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
> @@ -32,8 +75,11 @@ void riscv_fill_hwcap(void)
>
> elf_hwcap = 0;
>
> +   bitmap_zero(riscv_isa, RISCV_ISA_EXT_MAX);
> +
> for_each_of_cpu_node(node) {
> unsigned long this_hwcap = 0;
> +   unsigned long this_isa = 0;
>
> if (riscv_of_processor_hartid(node) < 0)
> continue;
> @@ -41,8 +87,24 @@ void riscv_fill_hwcap(void)
> if (riscv_read_check_isa(node, &isa) < 0)
> continue;
>
> -   for (i = 0; i < strlen(isa); ++i)
> +   i = 0;
> +   isa_len = strlen(isa);
> +#if IS_ENABLED(CONFIG_32BIT)
> +

Re: [PATCH v3 1/7] PM/Domains: Add support for retrieving genpd performance states information

2019-10-17 Thread Ulf Hansson

On Wed, 16 Oct 2019 at 21:37, Thara Gopinath  wrote:
>
> Add two new APIs in the genpd framework,
> dev_pm_genpd_get_performance_state to return the current performance
> state of a power domain and dev_pm_genpd_performance_state_count to
> return the total number of performance states supported by a
> power domain. Since the genpd framework does not maintain
> a count of number of performance states supported by a power domain,
> introduce a new callback(.get_performance_state_count) that can be used
> to retrieve this information from power domain drivers.
>
> These APIs are added to aid the implementation of a power domain as
> a warming device. Linux kernel cooling device framework(into which
> warming device can be plugged in) requires during initialization to be
> provided with the maximum number of states that can be supported. When
> a power domain acts as a warming device, the max state is the max number
> of perfomrance states supported by the power domain. The cooling
> device framework implements API to retrieve the current state of the
> cooling device. This in turn translates to the current performance
> state of the power domain.
>
> Signed-off-by: Thara Gopinath 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe


> ---
>  drivers/base/power/domain.c | 37 +
>  include/linux/pm_domain.h   | 13 +
>  2 files changed, 50 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index cc85e87..507e530 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -408,6 +408,43 @@ int dev_pm_genpd_set_performance_state(struct device 
> *dev, unsigned int state)
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_genpd_set_performance_state);
>
> +int dev_pm_genpd_get_performance_state(struct device *dev)
> +{
> +   struct generic_pm_domain *genpd;
> +   unsigned int state;
> +
> +   genpd = dev_to_genpd_safe(dev);
> +   if (IS_ERR(genpd))
> +   return -ENODEV;
> +
> +   genpd_lock(genpd);
> +   state = genpd->performance_state;
> +   genpd_unlock(genpd);
> +
> +   return state;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_genpd_get_performance_state);
> +
> +int dev_pm_genpd_performance_state_count(struct device *dev)
> +{
> +   struct generic_pm_domain *genpd;
> +   int count;
> +
> +   genpd = dev_to_genpd_safe(dev);
> +   if (IS_ERR(genpd))
> +   return -ENODEV;
> +
> +   if (unlikely(!genpd->get_performance_state_count))
> +   return -EINVAL;
> +
> +   genpd_lock(genpd);
> +   count = genpd->get_performance_state_count(genpd);
> +   genpd_unlock(genpd);
> +
> +   return count;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_genpd_performance_state_count);
> +
>  static int _genpd_power_on(struct generic_pm_domain *genpd, bool timed)
>  {
> unsigned int state_idx = genpd->state_idx;
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index baf02ff..e88e57f 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -117,6 +117,7 @@ struct generic_pm_domain {
>  struct dev_pm_opp *opp);
> int (*set_performance_state)(struct generic_pm_domain *genpd,
>  unsigned int state);
> +   int (*get_performance_state_count)(struct generic_pm_domain *genpd);
> struct gpd_dev_ops dev_ops;
> s64 max_off_time_ns;/* Maximum allowed "suspended" time. */
> bool max_off_time_changed;
> @@ -204,6 +205,8 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
>   struct dev_power_governor *gov, bool is_off);
>  int pm_genpd_remove(struct generic_pm_domain *genpd);
>  int dev_pm_genpd_set_performance_state(struct device *dev, unsigned int 
> state);
> +int dev_pm_genpd_get_performance_state(struct device *dev);
> +int dev_pm_genpd_performance_state_count(struct device *dev);
>
>  extern struct dev_power_governor simple_qos_governor;
>  extern struct dev_power_governor pm_domain_always_on_gov;
> @@ -251,6 +254,16 @@ static inline int 
> dev_pm_genpd_set_performance_state(struct device *dev,
> return -ENOTSUPP;
>  }
>
> +static inline int dev_pm_genpd_get_performance_state(struct device *dev)
> +{
> +   return -ENOTSUPP;
> +}
> +
> +static inline int dev_pm_genpd_performance_state_count(struct device *dev)
> +{
> +   return -ENOTSUPP;
> +}
> +
>  #define simple_qos_governor(*(struct dev_power_governor *)(NULL))
>  #define pm_domain_always_on_gov(*(struct dev_power_governor 
> *)(NULL))
>  #endif
> --
> 2.1.4
>

Re: [PATCH v2 1/5] pidfd: verify task is alive when printing fdinfo

2019-10-17 Thread Oleg Nesterov

On 10/16, Christian Brauner wrote:
>
> On Wed, Oct 16, 2019 at 06:24:09PM +0200, Oleg Nesterov wrote:
> >
> > And why task_ if it accepts pid+pid_type? May be pid_has_task() or
> > something like this...
>
> Given what I said above that might be a decent name.
>
> >
> > OK, since I can't suggest a better name I won't really argue. Feel free
> > to add my reviewed-by to this series.
>
> No, naming is important. Thanks for being picky about that too and I'll
> happily resend. :)

Thanks ;) May be pid_in_use() ? Up to you, anything which starts with pid_
looks better to me than task_alive().

Oleg.

[PATCH 1/2] dt-bindings: arm: at91: Document Kizbox2 boards binding

2019-10-17 Thread Kamel Bouhara

Document devicetree's bindings for the SAMA5D31 Kizbox2 boards of
Overkiz SAS.

Signed-off-by: Kamel Bouhara 
---
 .../devicetree/bindings/arm/atmel-at91.yaml   | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml 
b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
index c0869cb860f3..7636bf7c2382 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
@@ -80,6 +80,41 @@ properties:
   - const: atmel,sama5d3
   - const: atmel,sama5
 
+  - description: Overkiz kizbox2 board without antenna
+items:
+  - const: overkiz,kizbox2-0
+  - const: atmel,sama5d31
+  - const: atmel,sama5d3
+  - const: atmel,sama5
+
+  - description: Overkiz kizbox2 board with one head
+items:
+  - const: overkiz,kizbox2-1
+  - const: atmel,sama5d31
+  - const: atmel,sama5d3
+  - const: atmel,sama5
+
+  - description: Overkiz kizbox2 board with two heads
+items:
+  - const: overkiz,kizbox2-2
+  - const: atmel,sama5d31
+  - const: atmel,sama5d3
+  - const: atmel,sama5
+
+  - description: Overkiz kizbox2 board with three heads
+items:
+  - const: overkiz,kizbox2-3
+  - const: atmel,sama5d31
+  - const: atmel,sama5d3
+  - const: atmel,sama5
+
+  - description: Overkiz kizbox2 board Rev2 with two heads
+items:
+  - const: overkiz,kizbox2-rev2
+  - const: atmel,sama5d31
+  - const: atmel,sama5d3
+  - const: atmel,sama5
+
   - items:
   - enum:
   - atmel,sama5d31
-- 
2.23.0

[PATCH 0/2] Add a Kizbox2 dtsi and documentation

2019-10-17 Thread Kamel Bouhara

This short serie add a Kizbox2 DSTI file for the Overkiz's
SAMAD31 based boards and add their documentation.

Kamel Bouhara (2):
  dt-bindings: arm: at91: Document Kizbox2 boards binding
  ARM: dts: at91: add a common kizbox2 dtsi file

 .../devicetree/bindings/arm/atmel-at91.yaml   |  35 +++
 arch/arm/boot/dts/Makefile|   6 +-
 arch/arm/boot/dts/at91-kizbox.dts | 173 ++--
 arch/arm/boot/dts/at91-kizbox2-0.dts  |  17 ++
 arch/arm/boot/dts/at91-kizbox2-1.dts  |  22 ++
 arch/arm/boot/dts/at91-kizbox2-2.dts  |  26 ++
 arch/arm/boot/dts/at91-kizbox2-3.dts  |  30 ++
 arch/arm/boot/dts/at91-kizbox2-rev2.dts   |  34 +++
 arch/arm/boot/dts/at91-kizbox2.dts| 244 -
 arch/arm/boot/dts/at91-kizbox2_common.dtsi| 258 ++
 10 files changed, 512 insertions(+), 333 deletions(-)
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-0.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-1.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-2.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-3.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-rev2.dts
 delete mode 100644 arch/arm/boot/dts/at91-kizbox2.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2_common.dtsi

--
2.23.0

[PATCH 2/2] ARM: dts: at91: add a common kizbox2 dtsi file

2019-10-17 Thread Kamel Bouhara

There are three different boards available depending on the PCB
(3 antennas support and several revison). Add a dtsi file to share
common binding between all kizbox2 boards.

Signed-off-by: Kamel Bouhara 
Signed-off-by: Kévin RAYMOND 
Signed-off-by: Mickael GARDET 
---
 arch/arm/boot/dts/Makefile |   6 +-
 arch/arm/boot/dts/at91-kizbox.dts  | 173 +++---
 arch/arm/boot/dts/at91-kizbox2-0.dts   |  17 ++
 arch/arm/boot/dts/at91-kizbox2-1.dts   |  22 ++
 arch/arm/boot/dts/at91-kizbox2-2.dts   |  26 +++
 arch/arm/boot/dts/at91-kizbox2-3.dts   |  30 +++
 arch/arm/boot/dts/at91-kizbox2-rev2.dts|  34 +++
 arch/arm/boot/dts/at91-kizbox2.dts | 244 ---
 arch/arm/boot/dts/at91-kizbox2_common.dtsi | 258 +
 9 files changed, 477 insertions(+), 333 deletions(-)
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-0.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-1.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-2.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-3.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2-rev2.dts
 delete mode 100644 arch/arm/boot/dts/at91-kizbox2.dts
 create mode 100644 arch/arm/boot/dts/at91-kizbox2_common.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3bda216c41be..c976b72a4c94 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -45,7 +45,11 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
at91sam9x25ek.dtb \
at91sam9x35ek.dtb
 dtb-$(CONFIG_SOC_SAM_V7) += \
-   at91-kizbox2.dtb \
+   at91-kizbox2-0.dtb \
+   at91-kizbox2-1.dtb \
+   at91-kizbox2-2.dtb \
+   at91-kizbox2-rev2.dtb \
+   at91-kizbox2-3.dtb \
at91-kizbox3-hs.dtb \
at91-nattis-2-natte-2.dtb \
at91-sama5d27_som1_ek.dtb \
diff --git a/arch/arm/boot/dts/at91-kizbox.dts 
b/arch/arm/boot/dts/at91-kizbox.dts
index 90996eaf73b2..9eb1ea750159 100644
--- a/arch/arm/boot/dts/at91-kizbox.dts
+++ b/arch/arm/boot/dts/at91-kizbox.dts
@@ -28,85 +28,6 @@
};
};
 
-   ahb {
-   apb {
-   tcb0: timer@fffa {
-   timer@0 {
-   compatible = "atmel,tcb-timer";
-   reg = <0>, <1>;
-   };
-
-   timer@2 {
-   compatible = "atmel,tcb-timer";
-   reg = <2>;
-   };
-   };
-
-   macb0: ethernet@fffc4000 {
-   phy-mode = "mii";
-   pinctrl-0 = <&pinctrl_macb_rmii
-&pinctrl_macb_rmii_mii_alt>;
-   status = "okay";
-   };
-
-   usart3: serial@fffd {
-   status = "okay";
-   };
-
-   dbgu: serial@f200 {
-   status = "okay";
-   };
-
-   watchdog@fd40 {
-   timeout-sec = <15>;
-   atmel,max-heartbeat-sec = <16>;
-   atmel,min-heartbeat-sec = <0>;
-   status = "okay";
-   };
-   };
-
-   usb0: ohci@50 {
-   num-ports = <1>;
-   status = "okay";
-   };
-
-   ebi: ebi@1000 {
-   status = "okay";
-
-   nand_controller: nand-controller {
-   status = "okay";
-   pinctrl-0 = <&pinctrl_nand_cs &pinctrl_nand_rb>;
-   pinctrl-names = "default";
-
-   nand@3 {
-   reg = <0x3 0x0 0x80>;
-   rb-gpios = <&pioC 13 GPIO_ACTIVE_HIGH>;
-   cs-gpios = <&pioC 14 GPIO_ACTIVE_HIGH>;
-   nand-bus-width = <8>;
-   nand-ecc-mode = "soft";
-   nand-on-flash-bbt;
-   label = "atmel_nand";
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   bootstrap@0 {
-   label = "bootstrap";
-   reg = <0x0 0x2>;
-

Re: [PATCH 4.19 62/81] cifs: use cifsInodeInfo->open_file_lock while iterating to avoid a panic

2019-10-17 Thread Pavel Machek

Hi!

> From: Dave Wysochanski 
> 
> Commit 487317c99477 ("cifs: add spinlock for the openFileList to
> cifsInodeInfo") added cifsInodeInfo->open_file_lock spin_lock to protect

> Fixes: 487317c99477 ("cifs: add spinlock for the openFileList to 
> cifsInodeInfo")
> 
> CC: Stable 
> Signed-off-by: Dave Wysochanski 
> Reviewed-by: Ronnie Sahlberg 
> Signed-off-by: Steve French 

This is missing upstream commit ID and a signoff.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: PGP signature

Re: [RFC PATCH v3 2/6] sched/cpufreq: Attach perf domain to sugov policy

2019-10-17 Thread Dietmar Eggemann

On 11/10/2019 15:44, Douglas RAILLARD wrote:

[...]

> @@ -66,6 +70,38 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
>  
>  / Governor internals ***/
>  
> +#ifdef CONFIG_ENERGY_MODEL
> +static void sugov_policy_attach_pd(struct sugov_policy *sg_policy)
> +{
> + struct em_perf_domain *pd;
> + struct cpufreq_policy *policy = sg_policy->policy;

Shouldn't always order local variable declarations from longest to
shortest line?

> +
> + sg_policy->pd = NULL;
> + pd = em_cpu_get(policy->cpu);
> + if (!pd)
> + return;
> +
> + if (cpumask_equal(policy->related_cpus, to_cpumask(pd->cpus)))
> + sg_policy->pd = pd;
> + else
> + pr_warn("%s: Not all CPUs in schedutil policy %u share the same 
> perf domain, no perf domain for that policy will be registered\n",
> + __func__, policy->cpu);

Maybe {} because of 2 lines?

> +}
> +
> +static struct em_perf_domain *sugov_policy_get_pd(
> + struct sugov_policy *sg_policy)


Maybe this way? This format is already used in this file.

static struct em_perf_domain *
sugov_policy_get_pd(struct sugov_policy *sg_policy)


> +{
> + return sg_policy->pd;
> +}
> +#else /* CONFIG_ENERGY_MODEL */
> +static void sugov_policy_attach_pd(struct sugov_policy *sg_policy) {}
> +static struct em_perf_domain *sugov_policy_get_pd(
> + struct sugov_policy *sg_policy)
> +{
> + return NULL;
> +}
> +#endif /* CONFIG_ENERGY_MODEL */
> +
>  static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 
> time)
>  {
>   s64 delta_ns;
> @@ -859,6 +895,9 @@ static int sugov_start(struct cpufreq_policy *policy)
>   sugov_update_shared :
>   sugov_update_single);
>   }
> +
> + sugov_policy_attach_pd(sg_policy);
> +
>   return 0;
>  }

A sugov_policy_detach_pd() called from sugov_stop() (doing for instance
the g_policy->pd = NULL) is not needed?

Re: [RFC PATCH v3 1/6] PM: Introduce em_pd_get_higher_freq()

2019-10-17 Thread Dietmar Eggemann

On 11/10/2019 15:44, Douglas RAILLARD wrote:

[...]

> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
> index d249b88a4d5a..dd6a35f099ea 100644
> --- a/include/linux/energy_model.h
> +++ b/include/linux/energy_model.h
> @@ -159,6 +159,53 @@ static inline int em_pd_nr_cap_states(struct 
> em_perf_domain *pd)
>   return pd->nr_cap_states;
>  }
>  
> +#define EM_COST_MARGIN_SCALE 1024U
> +
> +/**
> + * em_pd_get_higher_freq() - Get the highest frequency that does not exceed 
> the
> + * given cost margin compared to min_freq
> + * @pd   : performance domain for which this must be done
> + * @min_freq : minimum frequency to return
> + * @cost_margin  : allowed margin compared to min_freq, on the
> + * EM_COST_MARGIN_SCALE scale.
> + *
> + * Return: the chosen frequency, guaranteed to be at least as high as 
> min_freq.
> + */
> +static inline unsigned long em_pd_get_higher_freq(struct em_perf_domain *pd,
> + unsigned long min_freq, unsigned long cost_margin)
> +{
> + unsigned long max_cost = 0;
> + struct em_cap_state *cs;
> + int i;
> +
> + if (!pd)
> + return min_freq;
> +
> + /* Compute the maximum allowed cost */
> + for (i = 0; i < pd->nr_cap_states; i++) {
> + cs = &pd->table[i];
> + if (cs->frequency >= min_freq) {
> + max_cost = cs->cost +
> + (cs->cost * cost_margin) / EM_COST_MARGIN_SCALE;
> + break;
> + }
> + }
> +
> + /* Find the highest frequency that will not exceed the cost margin */
> + for (i = pd->nr_cap_states-1; i >= 0; i--) {
> + cs = &pd->table[i];
> + if (cs->cost <= max_cost)
> + return cs->frequency;
> + }
> +
> + /*
> +  * We should normally never reach here, unless min_freq was higher than
> +  * the highest available frequency, which is not expected to happen.
> +  */
> + return min_freq;
> +}
> +
> +

Why two blank lines?

>  #else

Doesn't apply cleanly on v5.4-rc3. There seems to be a line missing?

27871f7a8a341 (Quentin Perret2018-12-03 09:56:16 + 163) struct
em_perf_domain {};

[...]

Re: [RFC PATCH v3 4/6] sched/cpufreq: Introduce sugov_cpu_ramp_boost

2019-10-17 Thread Dietmar Eggemann

On 11/10/2019 15:44, Douglas RAILLARD wrote:

[...]

> @@ -181,6 +185,42 @@ static void sugov_deferred_update(struct sugov_policy 
> *sg_policy, u64 time,
>   }
>  }
>  
> +static unsigned long sugov_cpu_ramp_boost(struct sugov_cpu *sg_cpu)
> +{
> + return READ_ONCE(sg_cpu->ramp_boost);
> +}
> +
> +static unsigned long sugov_cpu_ramp_boost_update(struct sugov_cpu *sg_cpu)
> +{
> + struct rq *rq = cpu_rq(sg_cpu->cpu);
> + unsigned long util_est_enqueued;
> + unsigned long util_avg;
> + unsigned long boost = 0;
> +
> + util_est_enqueued = READ_ONCE(rq->cfs.avg.util_est.enqueued);
> + util_avg = READ_ONCE(rq->cfs.avg.util_avg);
> +
> + /*
> +  * Boost when util_avg becomes higher than the previous stable
> +  * knowledge of the enqueued tasks' set util, which is CPU's
> +  * util_est_enqueued.
> +  *
> +  * We try to spot changes in the workload itself, so we want to
> +  * avoid the noise of tasks being enqueued/dequeued. To do that,
> +  * we only trigger boosting when the "amount of work' enqueued

s/"amount of work'/"amount of work" or 'amount of work'

[...]

> @@ -552,6 +593,8 @@ static unsigned int sugov_next_freq_shared(struct 
> sugov_cpu *sg_cpu, u64 time)
>   unsigned long j_util, j_max;
>  
>   j_util = sugov_get_util(j_sg_cpu);
> + if (j_sg_cpu == sg_cpu)
> + sugov_cpu_ramp_boost_update(sg_cpu);

Can you not call this already in sugov_update_shared(), like in the
sugov_update_single() case?

diff --git a/kernel/sched/cpufreq_schedutil.c
b/kernel/sched/cpufreq_schedutil.c
index e35c20b42780..4c53f63a537d 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -595,8 +595,6 @@ static unsigned int sugov_next_freq_shared(struct
sugov_cpu *sg_cpu, u64 time)
unsigned long j_util, j_max;

j_util = sugov_get_util(j_sg_cpu);
-   if (j_sg_cpu == sg_cpu)
-   sugov_cpu_ramp_boost_update(sg_cpu);
j_max = j_sg_cpu->max;
j_util = sugov_iowait_apply(j_sg_cpu, time, j_util, j_max);

@@ -625,6 +623,7 @@ sugov_update_shared(struct update_util_data *hook,
u64 time, unsigned int flags)
ignore_dl_rate_limit(sg_cpu, sg_policy);

if (sugov_should_update_freq(sg_policy, time)) {
+   sugov_cpu_ramp_boost_update(sg_cpu);
next_f = sugov_next_freq_shared(sg_cpu, time);

[...]

Re: [PATCH 4.19 68/81] ACPICA: ACPI 6.3: PPTT add additional fields in Processor Structure Flags

2019-10-17 Thread Pavel Machek

Hi!

> From: Erik Schmauss 
> 
> Commit b5eab512e7cffb2bb37c4b342b5594e9e75fd486 upstream.

So this introduces another format of "upstream" information. So far I
had this:

ma = re.match(".*Upstream commit ([0-9a-f]*) .*", l)
...
ma = re.match("commit ([0-9a-f]*) upstream[.]*", l)

I believe this information belongs to the signoff area; it is
important to know who pushed patch to the upstream and who is pusing
it to the stable.

Could we just introduce "Upstream: " tag and use it? It would
improve consistency...

Thanks,
Pavel

> ACPICA commit c736ea34add19a3a07e0e398711847cd6b95affd
> 
> Link: https://github.com/acpica/acpica/commit/c736ea34
> Signed-off-by: Erik Schmauss 
> Signed-off-by: Bob Moore 
> Signed-off-by: Rafael J. Wysocki 
> Signed-off-by: John Garry 
> Signed-off-by: Sasha Levin 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: PGP signature

[PATCH v2] scripts/gdb: fix debugging modules on s390

2019-10-17 Thread Ilya Leoshkevich

Currently lx-symbols assumes that module text is always located at
module->core_layout->base, but s390 uses the following layout:

+--+  <- module->core_layout->base
| GOT  |
+--+  <- module->core_layout->base + module->arch->plt_offset
| PLT  |
+--+  <- module->core_layout->base + module->arch->plt_offset +
| TEXT | module->arch->plt_size
+--+

Therefore, when trying to debug modules on s390, all the symbol
addresses are skewed by plt_offset + plt_size.

Fix by adding plt_offset + plt_size to module_addr in
load_module_symbols().

Signed-off-by: Ilya Leoshkevich 
---

v1 -> v2: print the adjusted address.

 scripts/gdb/linux/symbols.py | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
index f0d8f2ecfde7..df4c810de663 100644
--- a/scripts/gdb/linux/symbols.py
+++ b/scripts/gdb/linux/symbols.py
@@ -15,7 +15,7 @@ import gdb
 import os
 import re
 
-from linux import modules
+from linux import modules, utils
 
 
 if hasattr(gdb, 'Breakpoint'):
@@ -111,6 +111,12 @@ lx-symbols command."""
 module_file = self._get_module_file(module_name)
 
 if module_file:
+if utils.is_target_arch('s390'):
+# Module text is preceded by PLT stubs on s390.
+module_arch = module['arch']
+plt_offset = int(module_arch['plt_offset'])
+plt_size = int(module_arch['plt_size'])
+module_addr = hex(int(module_addr, 0) + plt_offset + plt_size)
 gdb.write("loading @{addr}: {filename}\n".format(
 addr=module_addr, filename=module_file))
 cmdline = "add-symbol-file {filename} {addr}{sections}".format(
-- 
2.23.0

Re: [PATCH v3 6/7] dt-bindings: soc: qcom: Extend RPMh power controller binding to describe thermal warming device

2019-10-17 Thread Ulf Hansson

On Wed, 16 Oct 2019 at 21:37, Thara Gopinath  wrote:
>
> RPMh power controller hosts mx domain that can be used as thermal
> warming device. Add a sub-node to specify this.
>
> Signed-off-by: Thara Gopinath 
> ---
>  Documentation/devicetree/bindings/power/qcom,rpmpd.txt | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt 
> b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> index eb35b22..fff695d 100644
> --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> @@ -18,6 +18,16 @@ Required Properties:
>  Refer to  for the level values for
>  various OPPs for different platforms as well as Power domain indexes
>
> += SUBNODES
> +RPMh alsp hosts power domains that can behave as thermal warming device.
> +These are expressed as subnodes of the RPMh. The name of the node is used
> +to identify the power domain and must therefor be "mx".
> +
> +- #cooling-cells:
> +   Usage: optional
> +   Value type: 
> +   Definition: must be 2
> +

Just wanted to express a minor thought about this. In general we use
subnodes of PM domain providers to represent the topology of PM
domains (subdomains), this is something different, which I guess is
fine.

I assume the #cooling-cells is here tells us this is not a PM domain
provider, but a "cooling device provider"?

Also, I wonder if it would be fine to specify "power-domains" here,
rather than using "name" as I think that is kind of awkward!?

>  Example: rpmh power domain controller and OPP table
>
>  #include 
> --
> 2.1.4
>

Kind regards
Uffe

Re: [PATCH 2/2] ARM: dts: at91: add a common kizbox2 dtsi file

2019-10-17 Thread Thomas Petazzoni

Hello Kamel,

On Thu, 17 Oct 2019 10:54:05 +0200
Kamel Bouhara  wrote:

> There are three different boards available depending on the PCB
> (3 antennas support and several revison). Add a dtsi file to share
> common binding between all kizbox2 boards.
> 
> Signed-off-by: Kamel Bouhara 
> Signed-off-by: Kévin RAYMOND 
> Signed-off-by: Mickael GARDET 
> ---
>  arch/arm/boot/dts/Makefile |   6 +-
>  arch/arm/boot/dts/at91-kizbox.dts  | 173 +++---

The changes to this file (change to use phandles) seem unrelated to the
current patch, unless I'm missing something.

>  arch/arm/boot/dts/at91-kizbox2-0.dts   |  17 ++
>  arch/arm/boot/dts/at91-kizbox2-1.dts   |  22 ++
>  arch/arm/boot/dts/at91-kizbox2-2.dts   |  26 +++
>  arch/arm/boot/dts/at91-kizbox2-3.dts   |  30 +++
>  arch/arm/boot/dts/at91-kizbox2-rev2.dts|  34 +++
>  arch/arm/boot/dts/at91-kizbox2.dts | 244 ---
>  arch/arm/boot/dts/at91-kizbox2_common.dtsi | 258 +

"-" seems to be a much more common separator for DT names, including in
this file, so what about at91-kizbox2-common.dtsi ?

> +// WMBUS (inverted with IO in the latest schematic)

I am not sure C++ comments are common in Device Tree files.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2 1/2] mmc: core: Add sdio_trigger_replug() API

2019-10-17 Thread Ulf Hansson

On Thu, 17 Oct 2019 at 02:22, Doug Anderson  wrote:
>
> Hi,
>
> On Thu, Oct 10, 2019 at 7:11 AM Ulf Hansson  wrote:
> >
> > On Mon, 22 Jul 2019 at 21:41, Douglas Anderson  
> > wrote:
> > >
> > > When using Marvell WiFi SDIO cards, it is not uncommon for Linux WiFi
> > > driver to fully lose the communication channel to the firmware running
> > > on the card.  Presumably the firmware on the card has a bug or two in
> > > it and occasionally crashes.
> > >
> > > The Marvell WiFi driver attempts to recover from this problem.
> > > Specifically the driver has the function mwifiex_sdio_card_reset()
> > > which is called when communcation problems are found.  That function
> > > attempts to reset the state of things by utilizing the mmc_hw_reset()
> > > function.
> > >
> > > The current solution is a bit complex because the Marvell WiFi driver
> > > needs to manually deinit and reinit the WiFi driver around the reset
> > > call.  This means it's going through a bunch of code paths that aren't
> > > normally tested.  However, complexity isn't our only problem.  The
> > > other (bigger) problem is that Marvell WiFi cards are often combo
> > > WiFi/Bluetooth cards and Bluetooth runs on a second SDIO func.  While
> > > the WiFi driver knows that it should re-init its own state around the
> > > mmc_hw_reset() call there is no good way to inform the Bluetooth
> > > driver.  That means that in Linux today when you reset the Marvell
> > > WiFi driver you lose all Bluetooth communication.  Doh!
> >
> > Thanks for a nice description to the problem!
> >
> > In principle it makes mmc_hw_reset() quite questionable to use for
> > SDIO func drivers, at all. However, let's consider that for later.
>
> Yeah, unless you somehow knew that your card would only have one function.
>
>
> > > One way to fix the above problems is to leverage a more standard way
> > > to reset the Marvell WiFi card where we go through the same code paths
> > > as card unplug and the card plug.  In this patch we introduce a new
> > > API call for doing just that: sdio_trigger_replug().  This API call
> > > will trigger an unplug of the SDIO card followed by a plug of the
> > > card.  As part of this the card will be nicely reset.
> >
> > I have been thinking back and forth on this, exploring various
> > options, perhaps adding some callbacks that the core could invoke to
> > inform the SDIO func drivers of what is going on.
> >
> > Although, in the end this boils done to complexity and I think your
> > approach is simply the most superior in regards to this. However, I
> > think there is a few things that we can do to even further simply your
> > approach, let me comment on the code below.
>
> Right.  Unplugging / re-plugging is sorta gross / inelegant, but it is
> definitely simpler and nice that it doesn't add so many new code
> paths.  For cases where you're just trying to re-init things with a
> hammer it works pretty well.
>
>
> > > Signed-off-by: Douglas Anderson 
> > > Reviewed-by: Matthias Kaehlcke 
> > > ---
> > >
> > > Changes in v2:
> > > - s/routnine/routine (Brian Norris, Matthias Kaehlcke).
> > > - s/contining/containing (Matthias Kaehlcke).
> > > - Add Matthias Reviewed-by tag.
> > >
> > >  drivers/mmc/core/core.c   | 28 ++--
> > >  drivers/mmc/core/sdio_io.c| 20 
> > >  include/linux/mmc/host.h  | 15 ++-
> > >  include/linux/mmc/sdio_func.h |  2 ++
> > >  4 files changed, 62 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> > > index 221127324709..5da365b1fdb4 100644
> > > --- a/drivers/mmc/core/core.c
> > > +++ b/drivers/mmc/core/core.c
> > > @@ -2161,6 +2161,12 @@ int mmc_sw_reset(struct mmc_host *host)
> > >  }
> > >  EXPORT_SYMBOL(mmc_sw_reset);
> > >
> > > +void mmc_trigger_replug(struct mmc_host *host)
> > > +{
> > > +   host->trigger_replug_state = MMC_REPLUG_STATE_UNPLUG;
> > > +   _mmc_detect_change(host, 0, false);
> > > +}
> > > +
> > >  static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq)
> > >  {
> > > host->f_init = freq;
> > > @@ -2214,6 +2220,11 @@ int _mmc_detect_card_removed(struct mmc_host *host)
> > > if (!host->card || mmc_card_removed(host->card))
> > > return 1;
> > >
> > > +   if (host->trigger_replug_state == MMC_REPLUG_STATE_UNPLUG) {
> > > +   mmc_card_set_removed(host->card);
> > > +   return 1;
> >
> > Do you really need to set state of the card to "removed"?
> >
> > If I understand correctly, what you need is to allow mmc_rescan() to
> > run a second time, in particular for non removable cards.
> >
> > In that path, mmc_rescan should find the card being non-functional,
> > thus it should remove it and then try to re-initialize it again. Etc.
> >
> > Do you want me to send a patch to show you what I mean!?
>
> If you don't mind, that would probably be easiest.  I've totally
> swapped out all of the implem

Re: [PATCH 3/3] cpufreq: simplify and remove lots of debug messages

2019-10-17 Thread Sudeep Holla

On Thu, Oct 17, 2019 at 08:12:00AM +0530, Viresh Kumar wrote:
> On 16-10-19, 12:03, Sudeep Holla wrote:
> > cpufreq_arm_bL_ops is no longer needed after merging the generic
> > arm_big_little and vexpress-spc driver. Remove cpufreq_arm_bL_ops
> > and rename all the bL_* function names to ve_spc_*.
> >
> > This driver have been used for year now and the extensive debug
> > messages in the driver are not really required anymore.
>
> This does lots of cleanup in this patch and not strictly what the commit log
> says. Can you please create separate patches for remove ops, debug messages 
> and
> other formatting things ?
>

Yes I did notice just after posting. These patches were sitting in my tree
for long time and didn't look at them in detail before posting. I will
split the patch accordingly.

--
Regards,
Sudeep

答复: [PATCH] use devm_platform_ioremap_resource() for irqchip drivers

2019-10-17 Thread huangdaode

Hi Marc
I am just doing the coccicheck using the command "make coccicheck 
M=drivers/irqchip/", and it report 
$ make coccicheck M=drivers/irqchip/
...
drivers/irqchip//irq-mvebu-icu.c:361:1-10: WARNING: Use 
devm_platform_ioremap_resource for icu -> base
drivers/irqchip//irq-ts4800.c:105:1-11: WARNING: Use 
devm_platform_ioremap_resource for data -> base
drivers/irqchip//irq-mvebu-pic.c:134:1-10: WARNING: Use 
devm_platform_ioremap_resource for pic -> base
drivers/irqchip//irq-ti-sci-inta.c:571:1-11: WARNING: Use 
devm_platform_ioremap_resource for inta -> base
drivers/irqchip//irq-stm32-exti.c:853:1-16: WARNING: Use 
devm_platform_ioremap_resource for host_data -> base

so just fix the WARNING. 

And after  apply the patch, I do the compile, it's OK, but I lack of hardware 
to test it. 
That's the case. 

MBR.
Thanks

-邮件原件-
发件人: Marc Zyngier [mailto:m...@kernel.org] 
发送时间: 2019年10月17日 16:24
收件人: huangdaode 
抄送: ja...@lakedaemon.net; and...@lunn.ch; gregory.clem...@bootlin.com; 
sebastian.hesselba...@gmail.com; t...@linutronix.de; mcoquelin.st...@gmail.com; 
alexandre.tor...@st.com; n...@ti.com; t-kri...@ti.com; ssant...@kernel.org; 
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; 
linux-st...@st-md-mailman.stormreply.com
主题: Re: [PATCH] use devm_platform_ioremap_resource() for irqchip drivers

On 2019-10-17 08:13, Daode Huang wrote:
> From: Daode Huang 
>
> Use the new helper that wraps the calls to platform_get_resource() and 
> devm_ioremap_resource() together
>
> Signed-off-by: Daode Huang 
> ---
>  drivers/irqchip/irq-mvebu-icu.c   | 3 +--
>  drivers/irqchip/irq-mvebu-pic.c   | 3 +--
>  drivers/irqchip/irq-stm32-exti.c  | 3 +--  
> drivers/irqchip/irq-ti-sci-inta.c | 3 +--
>  drivers/irqchip/irq-ts4800.c  | 3 +--
>  5 files changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/irqchip/irq-mvebu-icu.c 
> b/drivers/irqchip/irq-mvebu-icu.c index 547045d..ddf9b0d 100644
> --- a/drivers/irqchip/irq-mvebu-icu.c
> +++ b/drivers/irqchip/irq-mvebu-icu.c
> @@ -357,8 +357,7 @@ static int mvebu_icu_probe(struct platform_device
> *pdev)
>
>   icu->dev = &pdev->dev;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - icu->base = devm_ioremap_resource(&pdev->dev, res);
> + icu->base = devm_platform_ioremap_resource(pdev, res);

void __iomem *devm_platform_ioremap_resource(struct platform_device *pdev,
  unsigned int index)

What could possibly go wrong? I'd suggest you start compiling (and possibly
testing) the code you change before sending patches...

 M.
--
Jazz is not dead. It just smells funny...

撤回: [PATCH] use devm_platform_ioremap_resource() for irqchip drivers

2019-10-17 Thread huangdaode

huangdaode 将撤回邮件“[PATCH] use devm_platform_ioremap_resource() for irqchip 
drivers”。

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1065 matches

Mail list logo