Re: [PATCH 1/9] net: mediatek: update the IRQ part of the binding document

[David Miller]

Every patch series must begin with a postings labelled "[PATCH 0/9] ..."
which explains what the series is doing, how it is implementing that,
and why it is implemented that way.

Re: [PATCH 1/9] net: mediatek: update the IRQ part of the binding document

[David Miller]

Every patch series must begin with a postings labelled "[PATCH 0/9] ..."
which explains what the series is doing, how it is implementing that,
and why it is implemented that way.

[RESEND/PATCH V7 2/2] regulator: mt6323: Add support for MT6323 regulator

[John Crispin]

From: Chen Zhong 

The MT6323 is a regulator found on boards based on MediaTek MT7623 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.

Signed-off-by: Chen Zhong 
Signed-off-by: John Crispin 
---
Series was dropped in the 4.6-rc1 merge window to avoid a merge order
conflict with the corresponding MFD driver.

Changes in V7
* none

Changes in V6
* add back the set/get mode callbacks

Changes in V5
* remove the code that modifies constraints
* remove the code allows mode changes

Changes in V4:
* add id_table and of_match_table
* use short GPL text
* change MODULE_LICENSE to GPL V2

Changes in V3:
* none

Changes in V2:
* send to the the proper maintainer

 drivers/regulator/Kconfig  |9 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/mt6323-regulator.c   |  432 
 include/linux/regulator/mt6323-regulator.h |   52 
 4 files changed, 494 insertions(+)
 create mode 100644 drivers/regulator/mt6323-regulator.c
 create mode 100644 include/linux/regulator/mt6323-regulator.h

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c77dc08..a0082c2 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -488,6 +488,15 @@ config REGULATOR_MT6311
  This driver supports the control of different power rails of device
  through regulator interface.
 
+config REGULATOR_MT6323
+   tristate "MediaTek MT6323 PMIC"
+   depends on MFD_MT6397
+   help
+ Say y here to select this option to enable the power regulator of
+ MediaTek MT6323 PMIC.
+ This driver supports the control of different power rails of device
+ through regulator interface.
+
 config REGULATOR_MT6397
tristate "MediaTek MT6397 PMIC"
depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 61bfbb9..a76659e 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
 obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
+obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/mt6323-regulator.c 
b/drivers/regulator/mt6323-regulator.c
new file mode 100644
index 000..28ebbda
--- /dev/null
+++ b/drivers/regulator/mt6323-regulator.c
@@ -0,0 +1,432 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MT6323_LDO_MODE_NORMAL 0
+#define MT6323_LDO_MODE_LP 1
+
+/*
+ * MT6323 regulators' information
+ *
+ * @desc: standard fields of regulator description.
+ * @qi: Mask for query enable signal status of regulators
+ * @vselon_reg: Register sections for hardware control mode of bucks
+ * @vselctrl_reg: Register for controlling the buck control mode.
+ * @vselctrl_mask: Mask for query buck's voltage control mode.
+ */
+struct mt6323_regulator_info {
+   struct regulator_desc desc;
+   u32 qi;
+   u32 vselon_reg;
+   u32 vselctrl_reg;
+   u32 vselctrl_mask;
+   u32 modeset_reg;
+   u32 modeset_mask;
+};
+
+#define MT6323_BUCK(match, vreg, min, max, step, volt_ranges, enreg,   \
+   vosel, vosel_mask, voselon, vosel_ctrl) \
+[MT6323_ID_##vreg] = { \
+   .desc = {   \
+   .name = #vreg,  \
+   .of_match = of_match_ptr(match),\
+   .ops = _volt_range_ops,  \
+   .type = REGULATOR_VOLTAGE,  \
+   .id = MT6323_ID_##vreg, \
+   .owner = THIS_MODULE,   \
+   .n_voltages = (max - min)/step + 1, \
+   .linear_ranges = volt_ranges,   \
+   .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
+   .vsel_reg = vosel,  \
+   .vsel_mask = vosel_mask,\
+   .enable_reg = 

[RESEND/PATCH V7 2/2] regulator: mt6323: Add support for MT6323 regulator

[John Crispin]

From: Chen Zhong 

The MT6323 is a regulator found on boards based on MediaTek MT7623 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.

Signed-off-by: Chen Zhong 
Signed-off-by: John Crispin 
---
Series was dropped in the 4.6-rc1 merge window to avoid a merge order
conflict with the corresponding MFD driver.

Changes in V7
* none

Changes in V6
* add back the set/get mode callbacks

Changes in V5
* remove the code that modifies constraints
* remove the code allows mode changes

Changes in V4:
* add id_table and of_match_table
* use short GPL text
* change MODULE_LICENSE to GPL V2

Changes in V3:
* none

Changes in V2:
* send to the the proper maintainer

 drivers/regulator/Kconfig  |9 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/mt6323-regulator.c   |  432 
 include/linux/regulator/mt6323-regulator.h |   52 
 4 files changed, 494 insertions(+)
 create mode 100644 drivers/regulator/mt6323-regulator.c
 create mode 100644 include/linux/regulator/mt6323-regulator.h

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c77dc08..a0082c2 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -488,6 +488,15 @@ config REGULATOR_MT6311
  This driver supports the control of different power rails of device
  through regulator interface.
 
+config REGULATOR_MT6323
+   tristate "MediaTek MT6323 PMIC"
+   depends on MFD_MT6397
+   help
+ Say y here to select this option to enable the power regulator of
+ MediaTek MT6323 PMIC.
+ This driver supports the control of different power rails of device
+ through regulator interface.
+
 config REGULATOR_MT6397
tristate "MediaTek MT6397 PMIC"
depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 61bfbb9..a76659e 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
 obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
+obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/mt6323-regulator.c 
b/drivers/regulator/mt6323-regulator.c
new file mode 100644
index 000..28ebbda
--- /dev/null
+++ b/drivers/regulator/mt6323-regulator.c
@@ -0,0 +1,432 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MT6323_LDO_MODE_NORMAL 0
+#define MT6323_LDO_MODE_LP 1
+
+/*
+ * MT6323 regulators' information
+ *
+ * @desc: standard fields of regulator description.
+ * @qi: Mask for query enable signal status of regulators
+ * @vselon_reg: Register sections for hardware control mode of bucks
+ * @vselctrl_reg: Register for controlling the buck control mode.
+ * @vselctrl_mask: Mask for query buck's voltage control mode.
+ */
+struct mt6323_regulator_info {
+   struct regulator_desc desc;
+   u32 qi;
+   u32 vselon_reg;
+   u32 vselctrl_reg;
+   u32 vselctrl_mask;
+   u32 modeset_reg;
+   u32 modeset_mask;
+};
+
+#define MT6323_BUCK(match, vreg, min, max, step, volt_ranges, enreg,   \
+   vosel, vosel_mask, voselon, vosel_ctrl) \
+[MT6323_ID_##vreg] = { \
+   .desc = {   \
+   .name = #vreg,  \
+   .of_match = of_match_ptr(match),\
+   .ops = _volt_range_ops,  \
+   .type = REGULATOR_VOLTAGE,  \
+   .id = MT6323_ID_##vreg, \
+   .owner = THIS_MODULE,   \
+   .n_voltages = (max - min)/step + 1, \
+   .linear_ranges = volt_ranges,   \
+   .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
+   .vsel_reg = vosel,  \
+   .vsel_mask = vosel_mask,\
+   .enable_reg = enreg,\
+   .enable_mask = BIT(0),  

[RESEND/PATCH V7 1/2] regulator: Add document for MT6323 regulator

[John Crispin]

Signed-off-by: John Crispin 
Cc: devicet...@vger.kernel.org
---
Series was dropped in the 4.6-rc1 merge window to avoid a merge order
conflict with the corresponding MFD driver.

Changes in V7
* remove another compatible string
* small wording changes

Changes in V6
* remove the compatible string

Changes in V5
* regulator vs regulators

Changes in V4
* regulator is a subnode and not a property

 .../bindings/regulator/mt6323-regulator.txt|  239 
 1 file changed, 239 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/mt6323-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt 
b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
new file mode 100644
index 000..9fd95e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
@@ -0,0 +1,239 @@
+Mediatek MT6323 Regulator Driver
+
+All voltage regulators are defined as subnodes of the regulators node. A list
+of regulators provided by this controller are defined as subnodes of the
+PMIC's node. Each regulator is named according to its regulator type,
+buck_ and ldo_. The definition for each of these nodes is defined
+using the standard binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are::
+BUCK:
+  buck_vproc, buck_vsys, buck_vpa
+LDO:
+  ldo_vtcxo, ldo_vcn28, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_va, ldo_vcama,
+  ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
+  ldo_vgp3, ldo_vcn18, ldo_vsim1, ldo_vsim2, ldo_vrtc, ldo_vcamaf, ldo_vibr,
+  ldo_vrf18, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio
+
+Example:
+
+   pmic: mt6323 {
+   compatible = "mediatek,mt6323";
+
+   mt6323regulator: regulators {
+   mt6323_vproc_reg: buck_vproc{
+   regulator-name = "vproc";
+   regulator-min-microvolt = < 70>;
+   regulator-max-microvolt = <135>;
+   regulator-ramp-delay = <12500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vsys_reg: buck_vsys{
+   regulator-name = "vsys";
+   regulator-min-microvolt = <140>;
+   regulator-max-microvolt = <2987500>;
+   regulator-ramp-delay = <25000>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vpa_reg: buck_vpa{
+   regulator-name = "vpa";
+   regulator-min-microvolt = < 50>;
+   regulator-max-microvolt = <365>;
+   };
+
+   mt6323_vtcxo_reg: ldo_vtcxo{
+   regulator-name = "vtcxo";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <90>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vcn28_reg: ldo_vcn28{
+   regulator-name = "vcn28";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <185>;
+   };
+
+   mt6323_vcn33_bt_reg: ldo_vcn33_bt{
+   regulator-name = "vcn33_bt";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <360>;
+   regulator-enable-ramp-delay = <185>;
+   };
+
+   mt6323_vcn33_wifi_reg: ldo_vcn33_wifi{
+   regulator-name = "vcn33_wifi";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <360>;
+   regulator-enable-ramp-delay = <185>;
+   };
+
+   mt6323_va_reg: ldo_va{
+   regulator-name = "va";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <216>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   

[RESEND/PATCH V7 1/2] regulator: Add document for MT6323 regulator

[John Crispin]

Signed-off-by: John Crispin 
Cc: devicet...@vger.kernel.org
---
Series was dropped in the 4.6-rc1 merge window to avoid a merge order
conflict with the corresponding MFD driver.

Changes in V7
* remove another compatible string
* small wording changes

Changes in V6
* remove the compatible string

Changes in V5
* regulator vs regulators

Changes in V4
* regulator is a subnode and not a property

 .../bindings/regulator/mt6323-regulator.txt|  239 
 1 file changed, 239 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/mt6323-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt 
b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
new file mode 100644
index 000..9fd95e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
@@ -0,0 +1,239 @@
+Mediatek MT6323 Regulator Driver
+
+All voltage regulators are defined as subnodes of the regulators node. A list
+of regulators provided by this controller are defined as subnodes of the
+PMIC's node. Each regulator is named according to its regulator type,
+buck_ and ldo_. The definition for each of these nodes is defined
+using the standard binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are::
+BUCK:
+  buck_vproc, buck_vsys, buck_vpa
+LDO:
+  ldo_vtcxo, ldo_vcn28, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_va, ldo_vcama,
+  ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
+  ldo_vgp3, ldo_vcn18, ldo_vsim1, ldo_vsim2, ldo_vrtc, ldo_vcamaf, ldo_vibr,
+  ldo_vrf18, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio
+
+Example:
+
+   pmic: mt6323 {
+   compatible = "mediatek,mt6323";
+
+   mt6323regulator: regulators {
+   mt6323_vproc_reg: buck_vproc{
+   regulator-name = "vproc";
+   regulator-min-microvolt = < 70>;
+   regulator-max-microvolt = <135>;
+   regulator-ramp-delay = <12500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vsys_reg: buck_vsys{
+   regulator-name = "vsys";
+   regulator-min-microvolt = <140>;
+   regulator-max-microvolt = <2987500>;
+   regulator-ramp-delay = <25000>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vpa_reg: buck_vpa{
+   regulator-name = "vpa";
+   regulator-min-microvolt = < 50>;
+   regulator-max-microvolt = <365>;
+   };
+
+   mt6323_vtcxo_reg: ldo_vtcxo{
+   regulator-name = "vtcxo";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <90>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vcn28_reg: ldo_vcn28{
+   regulator-name = "vcn28";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <185>;
+   };
+
+   mt6323_vcn33_bt_reg: ldo_vcn33_bt{
+   regulator-name = "vcn33_bt";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <360>;
+   regulator-enable-ramp-delay = <185>;
+   };
+
+   mt6323_vcn33_wifi_reg: ldo_vcn33_wifi{
+   regulator-name = "vcn33_wifi";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <360>;
+   regulator-enable-ramp-delay = <185>;
+   };
+
+   mt6323_va_reg: ldo_va{
+   regulator-name = "va";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <216>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6323_vcama_reg: 

Re: [PATCH] ARM: dts: k2*: Rename the k2* files to keystone-k2* files

[Nishanth Menon]

On Thu, Apr 7, 2016 at 1:39 PM, santosh.shilim...@oracle.com
 wrote:
> On 4/7/16 10:01 AM, Nishanth Menon wrote:
>>
>> Hi Santosh,
>>
>> On Wed, Mar 16, 2016 at 10:43 AM, santosh shilimkar
>>  wrote:
>>>
>>> On 3/16/2016 7:39 AM, Nishanth Menon wrote:


 As reported in [1], rename the k2* dts files to keystone-* files
 this will force consistency throughout.

 Script for the same (and hand modified for Makefile and MAINTAINERS
 files):
 for i in arch/arm/boot/dts/k2*
 do
  b=`basename $i`;
  git mv $i arch/arm/boot/dts/keystone-$b;
  sed -i -e "s/$b/keystone-$b/g" arch/arm/boot/dts/*[si]
 done

 NOTE: bootloaders that depend on older dtb names will need to be
 updated as well.

 [1] http://marc.info/?l=linux-arm-kernel=145637407804754=2

 Reported-by: Olof Johansson 
 Signed-off-by: Nishanth Menon 
 ---

>>> Thanks Nishant for taking care of this. I will add this to the
>>> next soon.
>>>
>>
>> I dont see this in 4.6-rc2 yet.. did this slip our pull request? will
>> be good to get this in so that we can fix up u-boot consistently.
>>
> As discussed already, the 4.6 merge window contained the k2g renames
> as you can see from the pull request[1]. The other rename was suppose
> to be for 4.7 so that it lives in next for sometime for users to get
> the time to get to update the bootloaders etc.
>
> So it didn't slip pull request but just happen to go in 4.7 pull
> request. I added that to next early for testing. Hope it
> clarifies.

Aaah.. OK. I had misunderstood this to mean this cleanup was for 4.6
cycle. I will have to hold off on u-boot update till this is in master
:(.

>
> Regards,
> Santosh
>
> [1] https://patchwork.ozlabs.org/patch/588386/
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
---
Regards,
Nishanth Menon

Re: [PATCH] ARM: dts: k2*: Rename the k2* files to keystone-k2* files

[Nishanth Menon]

On Thu, Apr 7, 2016 at 1:39 PM, santosh.shilim...@oracle.com
 wrote:
> On 4/7/16 10:01 AM, Nishanth Menon wrote:
>>
>> Hi Santosh,
>>
>> On Wed, Mar 16, 2016 at 10:43 AM, santosh shilimkar
>>  wrote:
>>>
>>> On 3/16/2016 7:39 AM, Nishanth Menon wrote:


 As reported in [1], rename the k2* dts files to keystone-* files
 this will force consistency throughout.

 Script for the same (and hand modified for Makefile and MAINTAINERS
 files):
 for i in arch/arm/boot/dts/k2*
 do
  b=`basename $i`;
  git mv $i arch/arm/boot/dts/keystone-$b;
  sed -i -e "s/$b/keystone-$b/g" arch/arm/boot/dts/*[si]
 done

 NOTE: bootloaders that depend on older dtb names will need to be
 updated as well.

 [1] http://marc.info/?l=linux-arm-kernel=145637407804754=2

 Reported-by: Olof Johansson 
 Signed-off-by: Nishanth Menon 
 ---

>>> Thanks Nishant for taking care of this. I will add this to the
>>> next soon.
>>>
>>
>> I dont see this in 4.6-rc2 yet.. did this slip our pull request? will
>> be good to get this in so that we can fix up u-boot consistently.
>>
> As discussed already, the 4.6 merge window contained the k2g renames
> as you can see from the pull request[1]. The other rename was suppose
> to be for 4.7 so that it lives in next for sometime for users to get
> the time to get to update the bootloaders etc.
>
> So it didn't slip pull request but just happen to go in 4.7 pull
> request. I added that to next early for testing. Hope it
> clarifies.

Aaah.. OK. I had misunderstood this to mean this cleanup was for 4.6
cycle. I will have to hold off on u-boot update till this is in master
:(.

>
> Regards,
> Santosh
>
> [1] https://patchwork.ozlabs.org/patch/588386/
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
---
Regards,
Nishanth Menon

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

[Mathieu Desnoyers]

- On Apr 7, 2016, at 12:52 PM, Linus Torvalds torva...@linux-foundation.org 
wrote:

> On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds
>  wrote:
>>
>> Because if not, then this discussion is done for. Stop with the
>> f*cking idiotic "let's look at some kernel size and user-space size
>> and try to match them up". The kernel doesn't care. The kernel MUST
>> NOT care. The kernel will touch one single word, and that's all the
>> kernel does, and user space had better be able make up their own
>> semantics around that.
> 
> .. and btw - if people aren't sure that that is a "good enough"
> interface, then I'm sure as hell not going to merge that patch anyway.
> Andy mentions rseq. Yeah, I'm not going to merge anything where part
> of the discussion is "and we might want to do something else for X".
> 
> Either the suggested patches are useful and generic enough that people
> can do this, or they aren't.
> 
> If people can agree that "yes, this whole cpu id cache is a great
> interface that we can build up interesting user-space constructs
> around", then great. Such a new kernel interface may be worth merging.

One basic use of cpu id cache is to speed up the sched_getcpu(3)
implementation in glibc. This is why I'm proposing it as a stand-alone
feature that does not require the restartable sequences. It can
also be used directly from applications to remove the function call
overhead of sched_getcpu, which further accelerates this operation.

> 
> But if people cannot be convinced that it is sufficient, then I don't
> want to merge some half-arsed interface that generates these kinds of
> discussions.
> 
> So the fact that currently makes me go "no way will I merge any of
> this" is the very fact that these discussions continue and are still
> going on.

The intent of this RFC patchset is to get people to agree on the proper
way to introduce both the "cpu id" and the "rseq (restartable critical
section)" features. I have so far proposed two ways of doing it: one
system call per feature, or one system call to register all the features.

My previous patch rounds were adding a system call specific for the
cpu_id field, registering a pointer to a 32-bit per-thread integer.
(getcpu_cache system call) Based on prior email exchanges I had with
you on other topics, I was inclined to go for the specific getcpu_cache
system call route, and adding future features as separate system calls.

hpa pointed out that this will mean keeping track of one pointer
per task-struct for cpu_id, and eventually another pointer per
task-struct for rseq fields, thus degrading cache locality. In
order to address his concerns, I proposed this "thread local ABI"
system call, which registers a fixed-size 64 bytes structure that
starts with a feature mask.

The other route we could take is to just implement one "rseq" system
call, which would contain all fields needed for the rseq feature,
which happen to include the cpu_id. The main downside of this
approach is that whenever we want to port the cpu_id feature to
another architecture, it _needs_ to come with the implemented
"rseq" feature too, which is rather more complex. I don't mind
going that way either if that's preferred.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[John Youn]

On 3/31/2016 2:44 PM, Michael Niewoehner wrote:
> Hi John,
> 
> Am 29.03.2016 um 04:36 schrieb John Youn :
> 
>> Hi,
>>
>> The following patch series addresses the core reset and force mode
>> delay problems we have been seeing on dwc2 for some platforms.
>>
>> I think I have identified the source of the inconsistencies between
>> platforms and this series attempts to address them.
>>
>> Basically everything stems from the IDDIG debounce filter delay, which
>> is a function of the PHY clock speed and can range from 5-50 ms if
>> enabled. This delay must be taken into account on core reset and force
>> modes. A full explanation is provided in the patch commit log and code
>> comments.
>>
>> The first two patches are prerequisites to the force mode fixes,
>> including one patch that was sent separately by Przemek Rudy. I have
>> resubmitted it with this series for convenience.
>>
>> Please help by reviewing and testing on your platforms.
>>
>> Patches were tested on:
>> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
>>
>> Regards,
>> John
>>
>> John Youn (3):
>> usb: dwc2: gadget: Only initialize device if in device mode
>> usb: dwc2: Add delay to core soft reset
>> usb: dwc2: Properly account for the force mode delays
>>
>> Przemek Rudy (1):
>> usb: dwc2: do not override forced dr_mode in gadget setup
>>
>> drivers/usb/dwc2/core.c | 195 
>> 
>> drivers/usb/dwc2/core.h |   2 +-
>> drivers/usb/dwc2/gadget.c   |  30 +--
>> drivers/usb/dwc2/hcd.c  |   6 +-
>> drivers/usb/dwc2/hw.h   |   1 +
>> drivers/usb/dwc2/platform.c |   9 +-
>> 6 files changed, 161 insertions(+), 82 deletions(-)
>>
>> -- 
>> 2.7.4
>>
> 
> after applying your patch series on v4.6-rc1 usb keeps being broken on rk3188.
> Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set host 
> mode“ repeatedly.
> 
> Currently this works for me:
> - Revert "usb: dwc2: Fix probe problem on bcm2835“
> - Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"
> 
> 
> Best regards
> Michael
> 

Thanks Michael.

I won't be able to look at this again until next week. In the meantime
could you provide a driver log? In particular I want to see the values
of your GHWCFG registers, and where you are seeing the
dwc2_wait_for_mode() failure.

Regards,
John

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

[Mathieu Desnoyers]

- On Apr 7, 2016, at 12:52 PM, Linus Torvalds torva...@linux-foundation.org 
wrote:

> On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds
>  wrote:
>>
>> Because if not, then this discussion is done for. Stop with the
>> f*cking idiotic "let's look at some kernel size and user-space size
>> and try to match them up". The kernel doesn't care. The kernel MUST
>> NOT care. The kernel will touch one single word, and that's all the
>> kernel does, and user space had better be able make up their own
>> semantics around that.
> 
> .. and btw - if people aren't sure that that is a "good enough"
> interface, then I'm sure as hell not going to merge that patch anyway.
> Andy mentions rseq. Yeah, I'm not going to merge anything where part
> of the discussion is "and we might want to do something else for X".
> 
> Either the suggested patches are useful and generic enough that people
> can do this, or they aren't.
> 
> If people can agree that "yes, this whole cpu id cache is a great
> interface that we can build up interesting user-space constructs
> around", then great. Such a new kernel interface may be worth merging.

One basic use of cpu id cache is to speed up the sched_getcpu(3)
implementation in glibc. This is why I'm proposing it as a stand-alone
feature that does not require the restartable sequences. It can
also be used directly from applications to remove the function call
overhead of sched_getcpu, which further accelerates this operation.

> 
> But if people cannot be convinced that it is sufficient, then I don't
> want to merge some half-arsed interface that generates these kinds of
> discussions.
> 
> So the fact that currently makes me go "no way will I merge any of
> this" is the very fact that these discussions continue and are still
> going on.

The intent of this RFC patchset is to get people to agree on the proper
way to introduce both the "cpu id" and the "rseq (restartable critical
section)" features. I have so far proposed two ways of doing it: one
system call per feature, or one system call to register all the features.

My previous patch rounds were adding a system call specific for the
cpu_id field, registering a pointer to a 32-bit per-thread integer.
(getcpu_cache system call) Based on prior email exchanges I had with
you on other topics, I was inclined to go for the specific getcpu_cache
system call route, and adding future features as separate system calls.

hpa pointed out that this will mean keeping track of one pointer
per task-struct for cpu_id, and eventually another pointer per
task-struct for rseq fields, thus degrading cache locality. In
order to address his concerns, I proposed this "thread local ABI"
system call, which registers a fixed-size 64 bytes structure that
starts with a feature mask.

The other route we could take is to just implement one "rseq" system
call, which would contain all fields needed for the rseq feature,
which happen to include the cpu_id. The main downside of this
approach is that whenever we want to port the cpu_id feature to
another architecture, it _needs_ to come with the implemented
"rseq" feature too, which is rather more complex. I don't mind
going that way either if that's preferred.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

[John Youn]

On 3/31/2016 2:44 PM, Michael Niewoehner wrote:
> Hi John,
> 
> Am 29.03.2016 um 04:36 schrieb John Youn :
> 
>> Hi,
>>
>> The following patch series addresses the core reset and force mode
>> delay problems we have been seeing on dwc2 for some platforms.
>>
>> I think I have identified the source of the inconsistencies between
>> platforms and this series attempts to address them.
>>
>> Basically everything stems from the IDDIG debounce filter delay, which
>> is a function of the PHY clock speed and can range from 5-50 ms if
>> enabled. This delay must be taken into account on core reset and force
>> modes. A full explanation is provided in the patch commit log and code
>> comments.
>>
>> The first two patches are prerequisites to the force mode fixes,
>> including one patch that was sent separately by Przemek Rudy. I have
>> resubmitted it with this series for convenience.
>>
>> Please help by reviewing and testing on your platforms.
>>
>> Patches were tested on:
>> * Synopsys HAPS platform IP 3.20a OTG, dr_mode=OTG,HOST,PERIPHERAL
>>
>> Regards,
>> John
>>
>> John Youn (3):
>> usb: dwc2: gadget: Only initialize device if in device mode
>> usb: dwc2: Add delay to core soft reset
>> usb: dwc2: Properly account for the force mode delays
>>
>> Przemek Rudy (1):
>> usb: dwc2: do not override forced dr_mode in gadget setup
>>
>> drivers/usb/dwc2/core.c | 195 
>> 
>> drivers/usb/dwc2/core.h |   2 +-
>> drivers/usb/dwc2/gadget.c   |  30 +--
>> drivers/usb/dwc2/hcd.c  |   6 +-
>> drivers/usb/dwc2/hw.h   |   1 +
>> drivers/usb/dwc2/platform.c |   9 +-
>> 6 files changed, 161 insertions(+), 82 deletions(-)
>>
>> -- 
>> 2.7.4
>>
> 
> after applying your patch series on v4.6-rc1 usb keeps being broken on rk3188.
> Besides that I get "dwc2 1018.usb: dwc2_wait_for_mode: Couldn't set host 
> mode“ repeatedly.
> 
> Currently this works for me:
> - Revert "usb: dwc2: Fix probe problem on bcm2835“
> - Apply "usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"
> 
> 
> Best regards
> Michael
> 

Thanks Michael.

I won't be able to look at this again until next week. In the meantime
could you provide a driver log? In particular I want to see the values
of your GHWCFG registers, and where you are seeing the
dwc2_wait_for_mode() failure.

Regards,
John

Re: [PATCH] ARM: dts: k2*: Rename the k2* files to keystone-k2* files

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

On 4/7/16 10:01 AM, Nishanth Menon wrote:

Hi Santosh,

On Wed, Mar 16, 2016 at 10:43 AM, santosh shilimkar
 wrote:

On 3/16/2016 7:39 AM, Nishanth Menon wrote:


As reported in [1], rename the k2* dts files to keystone-* files
this will force consistency throughout.

Script for the same (and hand modified for Makefile and MAINTAINERS
files):
for i in arch/arm/boot/dts/k2*
do
 b=`basename $i`;
 git mv $i arch/arm/boot/dts/keystone-$b;
 sed -i -e "s/$b/keystone-$b/g" arch/arm/boot/dts/*[si]
done

NOTE: bootloaders that depend on older dtb names will need to be
updated as well.

[1] http://marc.info/?l=linux-arm-kernel=145637407804754=2

Reported-by: Olof Johansson 
Signed-off-by: Nishanth Menon 
---


Thanks Nishant for taking care of this. I will add this to the
next soon.



I dont see this in 4.6-rc2 yet.. did this slip our pull request? will
be good to get this in so that we can fix up u-boot consistently.


As discussed already, the 4.6 merge window contained the k2g renames
as you can see from the pull request[1]. The other rename was suppose
to be for 4.7 so that it lives in next for sometime for users to get
the time to get to update the bootloaders etc.

So it didn't slip pull request but just happen to go in 4.7 pull
request. I added that to next early for testing. Hope it
clarifies.

Regards,
Santosh

[1] https://patchwork.ozlabs.org/patch/588386/

Re: [PATCH] ARM: dts: k2*: Rename the k2* files to keystone-k2* files

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

On 4/7/16 10:01 AM, Nishanth Menon wrote:

Hi Santosh,

On Wed, Mar 16, 2016 at 10:43 AM, santosh shilimkar
 wrote:

On 3/16/2016 7:39 AM, Nishanth Menon wrote:


As reported in [1], rename the k2* dts files to keystone-* files
this will force consistency throughout.

Script for the same (and hand modified for Makefile and MAINTAINERS
files):
for i in arch/arm/boot/dts/k2*
do
 b=`basename $i`;
 git mv $i arch/arm/boot/dts/keystone-$b;
 sed -i -e "s/$b/keystone-$b/g" arch/arm/boot/dts/*[si]
done

NOTE: bootloaders that depend on older dtb names will need to be
updated as well.

[1] http://marc.info/?l=linux-arm-kernel=145637407804754=2

Reported-by: Olof Johansson 
Signed-off-by: Nishanth Menon 
---


Thanks Nishant for taking care of this. I will add this to the
next soon.



I dont see this in 4.6-rc2 yet.. did this slip our pull request? will
be good to get this in so that we can fix up u-boot consistently.


As discussed already, the 4.6 merge window contained the k2g renames
as you can see from the pull request[1]. The other rename was suppose
to be for 4.7 so that it lives in next for sometime for users to get
the time to get to update the bootloaders etc.

So it didn't slip pull request but just happen to go in 4.7 pull
request. I added that to next early for testing. Hope it
clarifies.

Regards,
Santosh

[1] https://patchwork.ozlabs.org/patch/588386/

[PATCH v2] mvsas: Generalize Marvell 9485 in pci_device_id

[Leonid Moiseichuk]

For generic subvendor has sense to use generic subdevice.
If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated.

Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635.

Signed-off-by: Leonid Moiseichuk 
---
 drivers/scsi/mvsas/mv_init.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index c7c250519c4b..a6a4f09df0be 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -704,24 +704,7 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9445,
},
-   {
-   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
-   .device = 0x9485,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = 0x9480,
-   .class  = 0,
-   .class_mask = 0,
-   .driver_data= chip_9485,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
-   .device = 0x9485,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = 0x9485,
-   .class  = 0,
-   .class_mask = 0,
-   .driver_data= chip_9485,
-   },
+   { PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
-- 
2.8.0.rc3

[PATCH v2] mvsas: Generalize Marvell 9485 in pci_device_id

[Leonid Moiseichuk]

For generic subvendor has sense to use generic subdevice.
If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated.

Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635.

Signed-off-by: Leonid Moiseichuk 
---
 drivers/scsi/mvsas/mv_init.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index c7c250519c4b..a6a4f09df0be 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -704,24 +704,7 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9445,
},
-   {
-   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
-   .device = 0x9485,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = 0x9480,
-   .class  = 0,
-   .class_mask = 0,
-   .driver_data= chip_9485,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
-   .device = 0x9485,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = 0x9485,
-   .class  = 0,
-   .class_mask = 0,
-   .driver_data= chip_9485,
-   },
+   { PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
-- 
2.8.0.rc3

Re: [PATCH 2/3] orangefs: strncpy -> strlcpy

[Andy Shevchenko]

On Mon, Apr 4, 2016 at 11:26 PM, Martin Brandenburg  wrote:
> From: Martin Brandenburg 
>
> Almost everywhere we use strncpy we should use strlcpy. This affects
> path names (d_name mostly), symlink targets, and server names.
>
> Leave debugfs code as is for now, though it could use a review as well.
>

|Why not strscpy() as most robust one?

> Signed-off-by: Martin Brandenburg 
> ---
>  fs/orangefs/dcache.c |  2 +-
>  fs/orangefs/namei.c  | 16 
>  fs/orangefs/orangefs-utils.c |  2 +-
>  fs/orangefs/super.c  |  6 +++---
>  4 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/fs/orangefs/dcache.c b/fs/orangefs/dcache.c
> index 5dfc4f3..0710869 100644
> --- a/fs/orangefs/dcache.c
> +++ b/fs/orangefs/dcache.c
> @@ -30,7 +30,7 @@ static int orangefs_revalidate_lookup(struct dentry *dentry)
>
> new_op->upcall.req.lookup.sym_follow = ORANGEFS_LOOKUP_LINK_NO_FOLLOW;
> new_op->upcall.req.lookup.parent_refn = parent->refn;
> -   strncpy(new_op->upcall.req.lookup.d_name,
> +   strlcpy(new_op->upcall.req.lookup.d_name,
> dentry->d_name.name,
> ORANGEFS_NAME_MAX);
>
> diff --git a/fs/orangefs/namei.c b/fs/orangefs/namei.c
> index 5a60c50..fc7e948 100644
> --- a/fs/orangefs/namei.c
> +++ b/fs/orangefs/namei.c
> @@ -37,7 +37,7 @@ static int orangefs_create(struct inode *dir,
> fill_default_sys_attrs(new_op->upcall.req.create.attributes,
>ORANGEFS_TYPE_METAFILE, mode);
>
> -   strncpy(new_op->upcall.req.create.d_name,
> +   strlcpy(new_op->upcall.req.create.d_name,
> dentry->d_name.name, ORANGEFS_NAME_MAX);
>
> ret = service_operation(new_op, __func__, 
> get_interruptible_flag(dir));
> @@ -132,7 +132,7 @@ static struct dentry *orangefs_lookup(struct inode *dir, 
> struct dentry *dentry,
>  >refn.khandle);
> new_op->upcall.req.lookup.parent_refn = parent->refn;
>
> -   strncpy(new_op->upcall.req.lookup.d_name, dentry->d_name.name,
> +   strlcpy(new_op->upcall.req.lookup.d_name, dentry->d_name.name,
> ORANGEFS_NAME_MAX);
>
> gossip_debug(GOSSIP_NAME_DEBUG,
> @@ -231,7 +231,7 @@ static int orangefs_unlink(struct inode *dir, struct 
> dentry *dentry)
> return -ENOMEM;
>
> new_op->upcall.req.remove.parent_refn = parent->refn;
> -   strncpy(new_op->upcall.req.remove.d_name, dentry->d_name.name,
> +   strlcpy(new_op->upcall.req.remove.d_name, dentry->d_name.name,
> ORANGEFS_NAME_MAX);
>
> ret = service_operation(new_op, "orangefs_unlink",
> @@ -282,10 +282,10 @@ static int orangefs_symlink(struct inode *dir,
>ORANGEFS_TYPE_SYMLINK,
>mode);
>
> -   strncpy(new_op->upcall.req.sym.entry_name,
> +   strlcpy(new_op->upcall.req.sym.entry_name,
> dentry->d_name.name,
> ORANGEFS_NAME_MAX);
> -   strncpy(new_op->upcall.req.sym.target, symname, ORANGEFS_NAME_MAX);
> +   strlcpy(new_op->upcall.req.sym.target, symname, ORANGEFS_NAME_MAX);
>
> ret = service_operation(new_op, __func__, 
> get_interruptible_flag(dir));
>
> @@ -347,7 +347,7 @@ static int orangefs_mkdir(struct inode *dir, struct 
> dentry *dentry, umode_t mode
> fill_default_sys_attrs(new_op->upcall.req.mkdir.attributes,
>   ORANGEFS_TYPE_DIRECTORY, mode);
>
> -   strncpy(new_op->upcall.req.mkdir.d_name,
> +   strlcpy(new_op->upcall.req.mkdir.d_name,
> dentry->d_name.name, ORANGEFS_NAME_MAX);
>
> ret = service_operation(new_op, __func__, 
> get_interruptible_flag(dir));
> @@ -419,10 +419,10 @@ static int orangefs_rename(struct inode *old_dir,
> new_op->upcall.req.rename.old_parent_refn = ORANGEFS_I(old_dir)->refn;
> new_op->upcall.req.rename.new_parent_refn = ORANGEFS_I(new_dir)->refn;
>
> -   strncpy(new_op->upcall.req.rename.d_old_name,
> +   strlcpy(new_op->upcall.req.rename.d_old_name,
> old_dentry->d_name.name,
> ORANGEFS_NAME_MAX);
> -   strncpy(new_op->upcall.req.rename.d_new_name,
> +   strlcpy(new_op->upcall.req.rename.d_new_name,
> new_dentry->d_name.name,
> ORANGEFS_NAME_MAX);
>
> diff --git a/fs/orangefs/orangefs-utils.c b/fs/orangefs/orangefs-utils.c
> index 40f5163..d72f3fc 100644
> --- a/fs/orangefs/orangefs-utils.c
> +++ b/fs/orangefs/orangefs-utils.c
> @@ -505,7 +505,7 @@ int orangefs_unmount_sb(struct super_block *sb)
> return -ENOMEM;
> new_op->upcall.req.fs_umount.id = ORANGEFS_SB(sb)->id;
> new_op->upcall.req.fs_umount.fs_id = ORANGEFS_SB(sb)->fs_id;
> -   strncpy(new_op->upcall.req.fs_umount.orangefs_config_server,
> +   strlcpy(new_op->upcall.req.fs_umount.orangefs_config_server,

Re: [PATCH 2/3] orangefs: strncpy -> strlcpy

[Andy Shevchenko]

On Mon, Apr 4, 2016 at 11:26 PM, Martin Brandenburg  wrote:
> From: Martin Brandenburg 
>
> Almost everywhere we use strncpy we should use strlcpy. This affects
> path names (d_name mostly), symlink targets, and server names.
>
> Leave debugfs code as is for now, though it could use a review as well.
>

|Why not strscpy() as most robust one?

> Signed-off-by: Martin Brandenburg 
> ---
>  fs/orangefs/dcache.c |  2 +-
>  fs/orangefs/namei.c  | 16 
>  fs/orangefs/orangefs-utils.c |  2 +-
>  fs/orangefs/super.c  |  6 +++---
>  4 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/fs/orangefs/dcache.c b/fs/orangefs/dcache.c
> index 5dfc4f3..0710869 100644
> --- a/fs/orangefs/dcache.c
> +++ b/fs/orangefs/dcache.c
> @@ -30,7 +30,7 @@ static int orangefs_revalidate_lookup(struct dentry *dentry)
>
> new_op->upcall.req.lookup.sym_follow = ORANGEFS_LOOKUP_LINK_NO_FOLLOW;
> new_op->upcall.req.lookup.parent_refn = parent->refn;
> -   strncpy(new_op->upcall.req.lookup.d_name,
> +   strlcpy(new_op->upcall.req.lookup.d_name,
> dentry->d_name.name,
> ORANGEFS_NAME_MAX);
>
> diff --git a/fs/orangefs/namei.c b/fs/orangefs/namei.c
> index 5a60c50..fc7e948 100644
> --- a/fs/orangefs/namei.c
> +++ b/fs/orangefs/namei.c
> @@ -37,7 +37,7 @@ static int orangefs_create(struct inode *dir,
> fill_default_sys_attrs(new_op->upcall.req.create.attributes,
>ORANGEFS_TYPE_METAFILE, mode);
>
> -   strncpy(new_op->upcall.req.create.d_name,
> +   strlcpy(new_op->upcall.req.create.d_name,
> dentry->d_name.name, ORANGEFS_NAME_MAX);
>
> ret = service_operation(new_op, __func__, 
> get_interruptible_flag(dir));
> @@ -132,7 +132,7 @@ static struct dentry *orangefs_lookup(struct inode *dir, 
> struct dentry *dentry,
>  >refn.khandle);
> new_op->upcall.req.lookup.parent_refn = parent->refn;
>
> -   strncpy(new_op->upcall.req.lookup.d_name, dentry->d_name.name,
> +   strlcpy(new_op->upcall.req.lookup.d_name, dentry->d_name.name,
> ORANGEFS_NAME_MAX);
>
> gossip_debug(GOSSIP_NAME_DEBUG,
> @@ -231,7 +231,7 @@ static int orangefs_unlink(struct inode *dir, struct 
> dentry *dentry)
> return -ENOMEM;
>
> new_op->upcall.req.remove.parent_refn = parent->refn;
> -   strncpy(new_op->upcall.req.remove.d_name, dentry->d_name.name,
> +   strlcpy(new_op->upcall.req.remove.d_name, dentry->d_name.name,
> ORANGEFS_NAME_MAX);
>
> ret = service_operation(new_op, "orangefs_unlink",
> @@ -282,10 +282,10 @@ static int orangefs_symlink(struct inode *dir,
>ORANGEFS_TYPE_SYMLINK,
>mode);
>
> -   strncpy(new_op->upcall.req.sym.entry_name,
> +   strlcpy(new_op->upcall.req.sym.entry_name,
> dentry->d_name.name,
> ORANGEFS_NAME_MAX);
> -   strncpy(new_op->upcall.req.sym.target, symname, ORANGEFS_NAME_MAX);
> +   strlcpy(new_op->upcall.req.sym.target, symname, ORANGEFS_NAME_MAX);
>
> ret = service_operation(new_op, __func__, 
> get_interruptible_flag(dir));
>
> @@ -347,7 +347,7 @@ static int orangefs_mkdir(struct inode *dir, struct 
> dentry *dentry, umode_t mode
> fill_default_sys_attrs(new_op->upcall.req.mkdir.attributes,
>   ORANGEFS_TYPE_DIRECTORY, mode);
>
> -   strncpy(new_op->upcall.req.mkdir.d_name,
> +   strlcpy(new_op->upcall.req.mkdir.d_name,
> dentry->d_name.name, ORANGEFS_NAME_MAX);
>
> ret = service_operation(new_op, __func__, 
> get_interruptible_flag(dir));
> @@ -419,10 +419,10 @@ static int orangefs_rename(struct inode *old_dir,
> new_op->upcall.req.rename.old_parent_refn = ORANGEFS_I(old_dir)->refn;
> new_op->upcall.req.rename.new_parent_refn = ORANGEFS_I(new_dir)->refn;
>
> -   strncpy(new_op->upcall.req.rename.d_old_name,
> +   strlcpy(new_op->upcall.req.rename.d_old_name,
> old_dentry->d_name.name,
> ORANGEFS_NAME_MAX);
> -   strncpy(new_op->upcall.req.rename.d_new_name,
> +   strlcpy(new_op->upcall.req.rename.d_new_name,
> new_dentry->d_name.name,
> ORANGEFS_NAME_MAX);
>
> diff --git a/fs/orangefs/orangefs-utils.c b/fs/orangefs/orangefs-utils.c
> index 40f5163..d72f3fc 100644
> --- a/fs/orangefs/orangefs-utils.c
> +++ b/fs/orangefs/orangefs-utils.c
> @@ -505,7 +505,7 @@ int orangefs_unmount_sb(struct super_block *sb)
> return -ENOMEM;
> new_op->upcall.req.fs_umount.id = ORANGEFS_SB(sb)->id;
> new_op->upcall.req.fs_umount.fs_id = ORANGEFS_SB(sb)->fs_id;
> -   strncpy(new_op->upcall.req.fs_umount.orangefs_config_server,
> +   strlcpy(new_op->upcall.req.fs_umount.orangefs_config_server,
> ORANGEFS_SB(sb)->devname,
> 

[GIT PULL] ext4 bug fixes for 4.6

[Theodore Ts'o]

The following changes since commit 243d50678583100855862bc084b8b307eea67f68:

  Merge branch 'overlayfs-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2016-03-22 13:11:15 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/ext4_for_linus_stable

for you to fetch changes up to c325a67c72903e1cc30e990a15ce745bda0dbfde:

  ext4: ignore quota mount options if the quota feature is enabled (2016-04-03 
17:03:37 -0400)


These changes contains a fix for overlayfs interacting with some
(badly behaved) dentry code in various file systems.  These have been
reviewed by Al and the respective file system mtinainers and are going
through the ext4 tree for convenience.

This also has a few ext4 encryption bug fixes that were discovered in
Android testing (yes, we will need to get these sync'ed up with the
fs/crypto code; I'll take care of that).  It also has some bug fixes
and a change to ignore the legacy quota options to allow for xfstests
regression testing of ext4's internal quota feature and to be more
consistent with how xfs handles this case.


Dan Carpenter (1):
  ext4 crypto: fix some error handling

Filipe Manana (1):
  btrfs: fix crash/invalid memory access on fsync when using overlayfs

Jan Kara (1):
  ext4: retry block allocation for failed DIO and DAX writes

Miklos Szeredi (4):
  fs: add file_dentry()
  nfs: use file_dentry()
  ext4: use dget_parent() in ext4_file_open()
  ext4: use file_dentry()

Theodore Ts'o (7):
  ext4: check if in-inode xattr is corrupted in ext4_expand_extra_isize_ea()
  ext4 crypto: don't let data integrity writebacks fail with ENOMEM
  ext4 crypto: use dget_parent() in ext4_d_revalidate()
  ext4: allow readdir()'s of large empty directories to be interrupted
  ext4: add lockdep annotations for i_data_sem
  ext4: avoid calling dquot_get_next_id() if quota is not enabled
  ext4: ignore quota mount options if the quota feature is enabled

 fs/btrfs/file.c|  2 +-
 fs/dcache.c|  5 -
 fs/ext4/crypto.c   | 49 +
 fs/ext4/dir.c  |  5 +
 fs/ext4/ext4.h | 29 +++--
 fs/ext4/file.c | 12 
 fs/ext4/inode.c| 58 
--
 fs/ext4/move_extent.c  | 11 +--
 fs/ext4/namei.c|  5 +
 fs/ext4/page-io.c  | 14 +-
 fs/ext4/readpage.c |  2 +-
 fs/ext4/super.c| 61 
+++--
 fs/ext4/xattr.c| 32 
 fs/nfs/dir.c   |  6 +++---
 fs/nfs/inode.c |  2 +-
 fs/nfs/nfs4file.c  |  4 ++--
 fs/overlayfs/super.c   | 33 +
 include/linux/dcache.h | 10 ++
 include/linux/fs.h | 10 ++
 19 files changed, 264 insertions(+), 86 deletions(-)

Re: [PATCH v2] mvsas: Generalize Marvell 9485 in pci_device_id

[Andy Shevchenko]

On Thu, Apr 7, 2016 at 8:06 PM, Leonid Moiseichuk
 wrote:
> For generic subvendor has sense to use generic subdevice.
> If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated.
>
> Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635.

Minors below.

FWIW:
Reviewed-by: Andy Shevchenko 

>
> Signed-off-by: Leonid Moiseichuk 
> ---

Missed changelog vfrom v1 to v2.

>  drivers/scsi/mvsas/mv_init.c | 19 +--
>  1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
> index c7c250519c4b..a6a4f09df0be 100644
> --- a/drivers/scsi/mvsas/mv_init.c
> +++ b/drivers/scsi/mvsas/mv_init.c
> @@ -704,24 +704,7 @@ static struct pci_device_id mvs_pci_table[] = {
> .class_mask = 0,
> .driver_data= chip_9445,
> },
> -   {
> -   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> -   .device = 0x9485,
> -   .subvendor  = PCI_ANY_ID,
> -   .subdevice  = 0x9480,
> -   .class  = 0,
> -   .class_mask = 0,
> -   .driver_data= chip_9485,
> -   },
> -   {
> -   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> -   .device = 0x9485,
> -   .subvendor  = PCI_ANY_ID,
> -   .subdevice  = 0x9485,
> -   .class  = 0,
> -   .class_mask = 0,
> -   .driver_data= chip_9485,
> -   },
> +   { PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 },

+ commentary line?

... /* MARVELL bla-bla-bla */

> { PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
> { PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
> (exact model unknown) */
> { PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
> (exact model unknown) */
> --
> 2.8.0.rc3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
With Best Regards,
Andy Shevchenko

[GIT PULL] ext4 bug fixes for 4.6

[Theodore Ts'o]

The following changes since commit 243d50678583100855862bc084b8b307eea67f68:

  Merge branch 'overlayfs-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2016-03-22 13:11:15 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/ext4_for_linus_stable

for you to fetch changes up to c325a67c72903e1cc30e990a15ce745bda0dbfde:

  ext4: ignore quota mount options if the quota feature is enabled (2016-04-03 
17:03:37 -0400)


These changes contains a fix for overlayfs interacting with some
(badly behaved) dentry code in various file systems.  These have been
reviewed by Al and the respective file system mtinainers and are going
through the ext4 tree for convenience.

This also has a few ext4 encryption bug fixes that were discovered in
Android testing (yes, we will need to get these sync'ed up with the
fs/crypto code; I'll take care of that).  It also has some bug fixes
and a change to ignore the legacy quota options to allow for xfstests
regression testing of ext4's internal quota feature and to be more
consistent with how xfs handles this case.


Dan Carpenter (1):
  ext4 crypto: fix some error handling

Filipe Manana (1):
  btrfs: fix crash/invalid memory access on fsync when using overlayfs

Jan Kara (1):
  ext4: retry block allocation for failed DIO and DAX writes

Miklos Szeredi (4):
  fs: add file_dentry()
  nfs: use file_dentry()
  ext4: use dget_parent() in ext4_file_open()
  ext4: use file_dentry()

Theodore Ts'o (7):
  ext4: check if in-inode xattr is corrupted in ext4_expand_extra_isize_ea()
  ext4 crypto: don't let data integrity writebacks fail with ENOMEM
  ext4 crypto: use dget_parent() in ext4_d_revalidate()
  ext4: allow readdir()'s of large empty directories to be interrupted
  ext4: add lockdep annotations for i_data_sem
  ext4: avoid calling dquot_get_next_id() if quota is not enabled
  ext4: ignore quota mount options if the quota feature is enabled

 fs/btrfs/file.c|  2 +-
 fs/dcache.c|  5 -
 fs/ext4/crypto.c   | 49 +
 fs/ext4/dir.c  |  5 +
 fs/ext4/ext4.h | 29 +++--
 fs/ext4/file.c | 12 
 fs/ext4/inode.c| 58 
--
 fs/ext4/move_extent.c  | 11 +--
 fs/ext4/namei.c|  5 +
 fs/ext4/page-io.c  | 14 +-
 fs/ext4/readpage.c |  2 +-
 fs/ext4/super.c| 61 
+++--
 fs/ext4/xattr.c| 32 
 fs/nfs/dir.c   |  6 +++---
 fs/nfs/inode.c |  2 +-
 fs/nfs/nfs4file.c  |  4 ++--
 fs/overlayfs/super.c   | 33 +
 include/linux/dcache.h | 10 ++
 include/linux/fs.h | 10 ++
 19 files changed, 264 insertions(+), 86 deletions(-)

Re: [PATCH v2] mvsas: Generalize Marvell 9485 in pci_device_id

[Andy Shevchenko]

On Thu, Apr 7, 2016 at 8:06 PM, Leonid Moiseichuk
 wrote:
> For generic subvendor has sense to use generic subdevice.
> If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated.
>
> Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635.

Minors below.

FWIW:
Reviewed-by: Andy Shevchenko 

>
> Signed-off-by: Leonid Moiseichuk 
> ---

Missed changelog vfrom v1 to v2.

>  drivers/scsi/mvsas/mv_init.c | 19 +--
>  1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
> index c7c250519c4b..a6a4f09df0be 100644
> --- a/drivers/scsi/mvsas/mv_init.c
> +++ b/drivers/scsi/mvsas/mv_init.c
> @@ -704,24 +704,7 @@ static struct pci_device_id mvs_pci_table[] = {
> .class_mask = 0,
> .driver_data= chip_9445,
> },
> -   {
> -   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> -   .device = 0x9485,
> -   .subvendor  = PCI_ANY_ID,
> -   .subdevice  = 0x9480,
> -   .class  = 0,
> -   .class_mask = 0,
> -   .driver_data= chip_9485,
> -   },
> -   {
> -   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> -   .device = 0x9485,
> -   .subvendor  = PCI_ANY_ID,
> -   .subdevice  = 0x9485,
> -   .class  = 0,
> -   .class_mask = 0,
> -   .driver_data= chip_9485,
> -   },
> +   { PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 },

+ commentary line?

... /* MARVELL bla-bla-bla */

> { PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
> { PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
> (exact model unknown) */
> { PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
> (exact model unknown) */
> --
> 2.8.0.rc3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

[Jiri Kosina]

On Thu, 7 Apr 2016, Josh Poimboeuf wrote:

> > I admittedly forgot what the "ftrace handler switching idea" is, and am 
> > not sure where exactly to look for it (could you please point it to me so 
> > that I can refresh my memory)
> 
> Here's where I originally described it [1]:

Thanks!

> | 2) As mentioned above, kthreads which are always sleeping on a patched 
> function
> |will never transition to the new universe.  This is really a minor issue
> |(less than 1% of patches).  It's not necessarily something that needs to 
> be
> |resolved with this patch set, but it would be good to have some 
> discussion
> |about it regardless.
> |
> |To overcome this issue, I have 1/2 an idea: we could add some stack 
> checking
> |code to the ftrace handler itself to transition the kthread to the new
> |universe after it re-enters the function it was originally sleeping on, 
> if
> |the stack doesn't already have have any other to-be-patched functions.
> |Combined with the klp_transition_work_fn()'s periodic stack checking of
> |sleeping tasks, that would handle most of the cases (except when trying 
> to
> |patch the high-level thread_fn itself).
> 
> > but generally we can't assume that a memory holding stack of a
> > sleeping task hasn't been reclaimed and wouldn't need to have been
> > paged in again.
> 
> Hm, we're talking about kernel stacks, right?  Are they not always
> resident in memory?

Sure they are, excuse my evening braindamage.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

[Jiri Kosina]

On Thu, 7 Apr 2016, Josh Poimboeuf wrote:

> > I admittedly forgot what the "ftrace handler switching idea" is, and am 
> > not sure where exactly to look for it (could you please point it to me so 
> > that I can refresh my memory)
> 
> Here's where I originally described it [1]:

Thanks!

> | 2) As mentioned above, kthreads which are always sleeping on a patched 
> function
> |will never transition to the new universe.  This is really a minor issue
> |(less than 1% of patches).  It's not necessarily something that needs to 
> be
> |resolved with this patch set, but it would be good to have some 
> discussion
> |about it regardless.
> |
> |To overcome this issue, I have 1/2 an idea: we could add some stack 
> checking
> |code to the ftrace handler itself to transition the kthread to the new
> |universe after it re-enters the function it was originally sleeping on, 
> if
> |the stack doesn't already have have any other to-be-patched functions.
> |Combined with the klp_transition_work_fn()'s periodic stack checking of
> |sleeping tasks, that would handle most of the cases (except when trying 
> to
> |patch the high-level thread_fn itself).
> 
> > but generally we can't assume that a memory holding stack of a
> > sleeping task hasn't been reclaimed and wouldn't need to have been
> > paged in again.
> 
> Hm, we're talking about kernel stacks, right?  Are they not always
> resident in memory?

Sure they are, excuse my evening braindamage.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: How to get creatior PID information for the local tcp connection

[Eric Dumazet]

On Thu, 2016-04-07 at 11:26 -0700, Eric Dumazet wrote:
> On Thu, 2016-04-07 at 23:01 +0530, Vishnu Pratap Singh wrote:
> > Hi,
> > 
> > 
> > Issue -  How to get PID information for the local tcp connection
> > 
> > 
> > 
> > i want to get the creator PID for each socket in user space for local
> > tcp connection, i see in kernel there is support for returing PID with
> > "SO_PEERCRED" ioctl to work across namespaces. it uses struct pid and
> > struct cred to store the peer credentials on struct sock.
> > cred_to_ucred(sk->sk_peer_pid, sk->sk_peer_cred, ); Above
> > function stores the PID information in ucred->pid = pid_vnr(pid); and
> > same is returned via "SO_PEERCRED" ioctl .
> > 
> > But for local tcp connection i get pid as 0, is there any way i can
> > get the PID information. Any help or suggestion will be highly
> > helpful.
> > 
> > 
> 
> man 7 socket
> 
>SO_PEERCRED
>   Return the credentials of the foreign  process  connected  to  
> this  socket.
>   This  is  possible  only  for  connected  AF_UNIX stream 
> sockets and AF_UNIX
>   stream and datagram socket pairs created using socketpair(2);  
> see  unix(7).
>   The  returned  credentials  are those that were in effect at 
> the time of the
>   call to connect(2) or socketpair(2).  The argument  is  a  
> ucred  structure;
>   define  the  GNU_SOURCE  feature test macro to obtain the 
> definition of that
>   structure from .  This socket option is read-only.
> 

Sorry, I hit "Send" too fast.

This is not implemented for TCP yet.

You'll have to take a look at iproute2 package, since "ss -tp" is able
to find this information, by looking at all /proc/{pid}/fd/*  files and
the socket inode number the kernel gives through inet_diag

Not scalable if you have millions of sockets...

Re: How to get creatior PID information for the local tcp connection

[Eric Dumazet]

On Thu, 2016-04-07 at 11:26 -0700, Eric Dumazet wrote:
> On Thu, 2016-04-07 at 23:01 +0530, Vishnu Pratap Singh wrote:
> > Hi,
> > 
> > 
> > Issue -  How to get PID information for the local tcp connection
> > 
> > 
> > 
> > i want to get the creator PID for each socket in user space for local
> > tcp connection, i see in kernel there is support for returing PID with
> > "SO_PEERCRED" ioctl to work across namespaces. it uses struct pid and
> > struct cred to store the peer credentials on struct sock.
> > cred_to_ucred(sk->sk_peer_pid, sk->sk_peer_cred, ); Above
> > function stores the PID information in ucred->pid = pid_vnr(pid); and
> > same is returned via "SO_PEERCRED" ioctl .
> > 
> > But for local tcp connection i get pid as 0, is there any way i can
> > get the PID information. Any help or suggestion will be highly
> > helpful.
> > 
> > 
> 
> man 7 socket
> 
>SO_PEERCRED
>   Return the credentials of the foreign  process  connected  to  
> this  socket.
>   This  is  possible  only  for  connected  AF_UNIX stream 
> sockets and AF_UNIX
>   stream and datagram socket pairs created using socketpair(2);  
> see  unix(7).
>   The  returned  credentials  are those that were in effect at 
> the time of the
>   call to connect(2) or socketpair(2).  The argument  is  a  
> ucred  structure;
>   define  the  GNU_SOURCE  feature test macro to obtain the 
> definition of that
>   structure from .  This socket option is read-only.
> 

Sorry, I hit "Send" too fast.

This is not implemented for TCP yet.

You'll have to take a look at iproute2 package, since "ss -tp" is able
to find this information, by looking at all /proc/{pid}/fd/*  files and
the socket inode number the kernel gives through inet_diag

Not scalable if you have millions of sockets...

Re: [PATCH v6 2/5] vfio: allow the user to register reserved iova range for MSI mapping

[Alex Williamson]

On Thu, 7 Apr 2016 15:43:29 +0200
Eric Auger  wrote:

> Hi Alex,
> On 04/07/2016 12:07 AM, Alex Williamson wrote:
> > On Mon,  4 Apr 2016 08:30:08 +
> > Eric Auger  wrote:
> >   
> >> The user is allowed to [un]register a reserved IOVA range by using the
> >> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
> >> It provides the base address and the size. This region is stored in the
> >> vfio_dma rb tree. At that point the iova range is not mapped to any target
> >> address yet. The host kernel will use those iova when needed, typically
> >> when the VFIO-PCI device allocates its MSIs.
> >>
> >> This patch also handles the destruction of the reserved binding RB-tree and
> >> domain's iova_domains.
> >>
> >> Signed-off-by: Eric Auger 
> >> Signed-off-by: Bharat Bhushan 
> >>
> >> ---
> >> v3 -> v4:
> >> - use iommu_alloc/free_reserved_iova_domain exported by dma-reserved-iommu
> >> - protect vfio_register_reserved_iova_range implementation with
> >>   CONFIG_IOMMU_DMA_RESERVED
> >> - handle unregistration by user-space and on vfio_iommu_type1 release
> >>
> >> v1 -> v2:
> >> - set returned value according to alloc_reserved_iova_domain result
> >> - free the iova domains in case any error occurs
> >>
> >> RFC v1 -> v1:
> >> - takes into account Alex comments, based on
> >>   [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region:
> >> - use the existing dma map/unmap ioctl interface with a flag to register
> >>   a reserved IOVA range. A single reserved iova region is allowed.
> >>
> >> Conflicts:
> >>drivers/vfio/vfio_iommu_type1.c
> >> ---
> >>  drivers/vfio/vfio_iommu_type1.c | 141 
> >> +++-
> >>  include/uapi/linux/vfio.h   |  12 +++-
> >>  2 files changed, 150 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c 
> >> b/drivers/vfio/vfio_iommu_type1.c
> >> index c9ddbde..4497b20 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++ b/drivers/vfio/vfio_iommu_type1.c
> >> @@ -36,6 +36,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  
> >>  #define DRIVER_VERSION  "0.2"
> >>  #define DRIVER_AUTHOR   "Alex Williamson "
> >> @@ -403,10 +404,22 @@ static void vfio_unmap_unpin(struct vfio_iommu 
> >> *iommu, struct vfio_dma *dma)
> >>vfio_lock_acct(-unlocked);
> >>  }
> >>  
> >> +static void vfio_unmap_reserved(struct vfio_iommu *iommu)
> >> +{
> >> +#ifdef CONFIG_IOMMU_DMA_RESERVED
> >> +  struct vfio_domain *d;
> >> +
> >> +  list_for_each_entry(d, >domain_list, next)
> >> +  iommu_unmap_reserved(d->domain);
> >> +#endif
> >> +}
> >> +
> >>  static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma 
> >> *dma)
> >>  {
> >>if (likely(dma->type != VFIO_IOVA_RESERVED))
> >>vfio_unmap_unpin(iommu, dma);
> >> +  else
> >> +  vfio_unmap_reserved(iommu);
> >>vfio_unlink_dma(iommu, dma);
> >>kfree(dma);
> >>  }  
> > 
> > This makes me nervous, apparently we can add reserved mappings
> > individually, but we have absolutely no granularity on remove, so if we
> > remove one, we've removed them all even though we still have them
> > linked in our rb tree.  I see later that only one reserved region is
> > allowed, but that seems very short sighted, especially to impose that
> > on the user level API.  
> On kernel-size the reserved region is currently backed by a unique
> iova_domain. Do you mean you would like me to handle a list of
> iova_domains instead of using a single "cookie"?

TBH, I'm not really sure how this works with a single iova domain.  If
we have multiple irq chips and each gets mapped by a separate page in
the iova space, then is it really sufficient to do a lookup from the
irq_data to the msi_desc to the device to the domain in order to get a
reserved iova to map that msi doorbell?  Don't we need an iova from the
pool mapping the specific irqchip associated with our device?  The IOMMU
domain might span any number of irq chips, how can we assume there's
one only reserved iova space?  Maybe I'm not understanding how the code
works.

Conceptually, this is a generic IOMMU API extension to include reserved
iova space, MSI mappings are a consumer of that reserved iova pool but
I don't think we can say they will necessarily be the only consumer.
So building into the interface that there's only one is like making a
fixed length array to hold a string, it works for the initial
implementation, but it's not a robust solution.

I'm also trying to figure out how this maps to x86, the difference of
course being that for ARM you have a user specified, explicit MSI iova
space while x86 has an implicit MSI iova space.  So should x86 be
creating a reserved iova pool for the implicit mapping?  Should the
user have some way to query the mapping, whether implicit or explicit?
For instance, a 

Re: [PATCH v6 2/5] vfio: allow the user to register reserved iova range for MSI mapping

[Alex Williamson]

On Thu, 7 Apr 2016 15:43:29 +0200
Eric Auger  wrote:

> Hi Alex,
> On 04/07/2016 12:07 AM, Alex Williamson wrote:
> > On Mon,  4 Apr 2016 08:30:08 +
> > Eric Auger  wrote:
> >   
> >> The user is allowed to [un]register a reserved IOVA range by using the
> >> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
> >> It provides the base address and the size. This region is stored in the
> >> vfio_dma rb tree. At that point the iova range is not mapped to any target
> >> address yet. The host kernel will use those iova when needed, typically
> >> when the VFIO-PCI device allocates its MSIs.
> >>
> >> This patch also handles the destruction of the reserved binding RB-tree and
> >> domain's iova_domains.
> >>
> >> Signed-off-by: Eric Auger 
> >> Signed-off-by: Bharat Bhushan 
> >>
> >> ---
> >> v3 -> v4:
> >> - use iommu_alloc/free_reserved_iova_domain exported by dma-reserved-iommu
> >> - protect vfio_register_reserved_iova_range implementation with
> >>   CONFIG_IOMMU_DMA_RESERVED
> >> - handle unregistration by user-space and on vfio_iommu_type1 release
> >>
> >> v1 -> v2:
> >> - set returned value according to alloc_reserved_iova_domain result
> >> - free the iova domains in case any error occurs
> >>
> >> RFC v1 -> v1:
> >> - takes into account Alex comments, based on
> >>   [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region:
> >> - use the existing dma map/unmap ioctl interface with a flag to register
> >>   a reserved IOVA range. A single reserved iova region is allowed.
> >>
> >> Conflicts:
> >>drivers/vfio/vfio_iommu_type1.c
> >> ---
> >>  drivers/vfio/vfio_iommu_type1.c | 141 
> >> +++-
> >>  include/uapi/linux/vfio.h   |  12 +++-
> >>  2 files changed, 150 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c 
> >> b/drivers/vfio/vfio_iommu_type1.c
> >> index c9ddbde..4497b20 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++ b/drivers/vfio/vfio_iommu_type1.c
> >> @@ -36,6 +36,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  
> >>  #define DRIVER_VERSION  "0.2"
> >>  #define DRIVER_AUTHOR   "Alex Williamson "
> >> @@ -403,10 +404,22 @@ static void vfio_unmap_unpin(struct vfio_iommu 
> >> *iommu, struct vfio_dma *dma)
> >>vfio_lock_acct(-unlocked);
> >>  }
> >>  
> >> +static void vfio_unmap_reserved(struct vfio_iommu *iommu)
> >> +{
> >> +#ifdef CONFIG_IOMMU_DMA_RESERVED
> >> +  struct vfio_domain *d;
> >> +
> >> +  list_for_each_entry(d, >domain_list, next)
> >> +  iommu_unmap_reserved(d->domain);
> >> +#endif
> >> +}
> >> +
> >>  static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma 
> >> *dma)
> >>  {
> >>if (likely(dma->type != VFIO_IOVA_RESERVED))
> >>vfio_unmap_unpin(iommu, dma);
> >> +  else
> >> +  vfio_unmap_reserved(iommu);
> >>vfio_unlink_dma(iommu, dma);
> >>kfree(dma);
> >>  }  
> > 
> > This makes me nervous, apparently we can add reserved mappings
> > individually, but we have absolutely no granularity on remove, so if we
> > remove one, we've removed them all even though we still have them
> > linked in our rb tree.  I see later that only one reserved region is
> > allowed, but that seems very short sighted, especially to impose that
> > on the user level API.  
> On kernel-size the reserved region is currently backed by a unique
> iova_domain. Do you mean you would like me to handle a list of
> iova_domains instead of using a single "cookie"?

TBH, I'm not really sure how this works with a single iova domain.  If
we have multiple irq chips and each gets mapped by a separate page in
the iova space, then is it really sufficient to do a lookup from the
irq_data to the msi_desc to the device to the domain in order to get a
reserved iova to map that msi doorbell?  Don't we need an iova from the
pool mapping the specific irqchip associated with our device?  The IOMMU
domain might span any number of irq chips, how can we assume there's
one only reserved iova space?  Maybe I'm not understanding how the code
works.

Conceptually, this is a generic IOMMU API extension to include reserved
iova space, MSI mappings are a consumer of that reserved iova pool but
I don't think we can say they will necessarily be the only consumer.
So building into the interface that there's only one is like making a
fixed length array to hold a string, it works for the initial
implementation, but it's not a robust solution.

I'm also trying to figure out how this maps to x86, the difference of
course being that for ARM you have a user specified, explicit MSI iova
space while x86 has an implicit MSI iova space.  So should x86 be
creating a reserved iova pool for the implicit mapping?  Should the
user have some way to query the mapping, whether implicit or explicit?
For instance, a new capability within the vfio iommu INFO ioctl might
expose reserved regions.  It might be initially present on x86 due to

Re: How to get creatior PID information for the local tcp connection

[Eric Dumazet]

On Thu, 2016-04-07 at 23:01 +0530, Vishnu Pratap Singh wrote:
> Hi,
> 
> 
> Issue -  How to get PID information for the local tcp connection
> 
> 
> 
> i want to get the creator PID for each socket in user space for local
> tcp connection, i see in kernel there is support for returing PID with
> "SO_PEERCRED" ioctl to work across namespaces. it uses struct pid and
> struct cred to store the peer credentials on struct sock.
> cred_to_ucred(sk->sk_peer_pid, sk->sk_peer_cred, ); Above
> function stores the PID information in ucred->pid = pid_vnr(pid); and
> same is returned via "SO_PEERCRED" ioctl .
> 
> But for local tcp connection i get pid as 0, is there any way i can
> get the PID information. Any help or suggestion will be highly
> helpful.
> 
> 

man 7 socket

   SO_PEERCRED
  Return the credentials of the foreign  process  connected  to  
this  socket.
  This  is  possible  only  for  connected  AF_UNIX stream sockets 
and AF_UNIX
  stream and datagram socket pairs created using socketpair(2);  
see  unix(7).
  The  returned  credentials  are those that were in effect at the 
time of the
  call to connect(2) or socketpair(2).  The argument  is  a  ucred  
structure;
  define  the  GNU_SOURCE  feature test macro to obtain the 
definition of that
  structure from .  This socket option is read-only.

Re: How to get creatior PID information for the local tcp connection

[Eric Dumazet]

On Thu, 2016-04-07 at 23:01 +0530, Vishnu Pratap Singh wrote:
> Hi,
> 
> 
> Issue -  How to get PID information for the local tcp connection
> 
> 
> 
> i want to get the creator PID for each socket in user space for local
> tcp connection, i see in kernel there is support for returing PID with
> "SO_PEERCRED" ioctl to work across namespaces. it uses struct pid and
> struct cred to store the peer credentials on struct sock.
> cred_to_ucred(sk->sk_peer_pid, sk->sk_peer_cred, ); Above
> function stores the PID information in ucred->pid = pid_vnr(pid); and
> same is returned via "SO_PEERCRED" ioctl .
> 
> But for local tcp connection i get pid as 0, is there any way i can
> get the PID information. Any help or suggestion will be highly
> helpful.
> 
> 

man 7 socket

   SO_PEERCRED
  Return the credentials of the foreign  process  connected  to  
this  socket.
  This  is  possible  only  for  connected  AF_UNIX stream sockets 
and AF_UNIX
  stream and datagram socket pairs created using socketpair(2);  
see  unix(7).
  The  returned  credentials  are those that were in effect at the 
time of the
  call to connect(2) or socketpair(2).  The argument  is  a  ucred  
structure;
  define  the  GNU_SOURCE  feature test macro to obtain the 
definition of that
  structure from .  This socket option is read-only.

[PATCH] net-next: mediatek: add support for IRQ grouping

[John Crispin]

The ethernet core has 3 IRQs. Using the IRQ grouping registers we are able
to separate TX and RX IRQs, which allows us to service them on separate
cores. This patch splits the IRQ handler into 2 separate functions, one
for TX and another for RX. The TX housekeeping is split out of the NAPI
handler. Instead we use a tasklet to handle housekeeping.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |  115 +--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |   12 ++-
 2 files changed, 86 insertions(+), 41 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8163047..6387516 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -756,7 +756,7 @@ drop:
 }
 
 static int mtk_poll_rx(struct napi_struct *napi, int budget,
-  struct mtk_eth *eth, u32 rx_intr)
+  struct mtk_eth *eth)
 {
struct mtk_rx_ring *ring = >rx_ring;
int idx = ring->calc_idx;
@@ -842,12 +842,12 @@ release_desc:
}
 
if (done < budget)
-   mtk_w32(eth, rx_intr, MTK_QMTK_INT_STATUS);
+   mtk_w32(eth, MTK_RX_DONE_INT, MTK_QMTK_INT_STATUS);
 
return done;
 }
 
-static int mtk_poll_tx(struct mtk_eth *eth, int budget, bool *tx_again)
+static int mtk_poll_tx(struct mtk_eth *eth, int budget)
 {
struct mtk_tx_ring *ring = >tx_ring;
struct mtk_tx_dma *desc;
@@ -910,9 +910,7 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
}
 
/* read hw index again make sure no new tx packet */
-   if (cpu != dma || cpu != mtk_r32(eth, MTK_QTX_DRX_PTR))
-   *tx_again = true;
-   else
+   if (cpu == dma && cpu == mtk_r32(eth, MTK_QTX_DRX_PTR))
mtk_w32(eth, MTK_TX_DONE_INT, MTK_QMTK_INT_STATUS);
 
if (!total)
@@ -924,27 +922,27 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
return total;
 }
 
+static void mtk_clean_tx_tasklet(unsigned long arg)
+{
+   struct mtk_eth *eth = (struct mtk_eth *)arg;
+
+   if (mtk_poll_tx(eth, MTK_NAPI_WEIGHT) > 0)
+   tasklet_schedule(>tx_clean_tasklet);
+   else
+   mtk_irq_enable(eth, MTK_TX_DONE_INT);
+}
+
 static int mtk_poll(struct napi_struct *napi, int budget)
 {
struct mtk_eth *eth = container_of(napi, struct mtk_eth, rx_napi);
-   u32 status, status2, mask, tx_intr, rx_intr, status_intr;
-   int tx_done, rx_done;
-   bool tx_again = false;
+   u32 status, status2, mask, status_intr;
+   int rx_done = 0;
 
status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
status2 = mtk_r32(eth, MTK_INT_STATUS2);
-   tx_intr = MTK_TX_DONE_INT;
-   rx_intr = MTK_RX_DONE_INT;
status_intr = (MTK_GDM1_AF | MTK_GDM2_AF);
-   tx_done = 0;
-   rx_done = 0;
-   tx_again = 0;
 
-   if (status & tx_intr)
-   tx_done = mtk_poll_tx(eth, budget, _again);
-
-   if (status & rx_intr)
-   rx_done = mtk_poll_rx(napi, budget, eth, rx_intr);
+   rx_done = mtk_poll_rx(napi, budget, eth);
 
if (unlikely(status2 & status_intr)) {
mtk_stats_update(eth);
@@ -953,20 +951,20 @@ static int mtk_poll(struct napi_struct *napi, int budget)
 
if (unlikely(netif_msg_intr(eth))) {
mask = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   netdev_info(eth->netdev[0],
-   "done tx %d, rx %d, intr 0x%08x/0x%x\n",
-   tx_done, rx_done, status, mask);
+   dev_info(eth->dev,
+"done rx %d, intr 0x%08x/0x%x\n",
+rx_done, status, mask);
}
 
-   if (tx_again || rx_done == budget)
+   if (rx_done == budget)
return budget;
 
status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
-   if (status & (tx_intr | rx_intr))
+   if (status & MTK_RX_DONE_INT)
return budget;
 
napi_complete(napi);
-   mtk_irq_enable(eth, tx_intr | rx_intr);
+   mtk_irq_enable(eth, MTK_RX_DONE_INT);
 
return rx_done;
 }
@@ -1195,22 +1193,43 @@ static void mtk_tx_timeout(struct net_device *dev)
schedule_work(>pending_work);
 }
 
-static irqreturn_t mtk_handle_irq(int irq, void *_eth)
+static irqreturn_t mtk_handle_irq_rx(int irq, void *_eth)
 {
struct mtk_eth *eth = _eth;
u32 status;
 
status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
+   status &= ~MTK_TX_DONE_INT;
+
if (unlikely(!status))
return IRQ_NONE;
 
-   if (likely(status & (MTK_RX_DONE_INT | MTK_TX_DONE_INT))) {
+   if (status & MTK_RX_DONE_INT) {
if (likely(napi_schedule_prep(>rx_napi)))
__napi_schedule(>rx_napi);
-   } else {
-   mtk_w32(eth, status, 

[PATCH] net-next: mediatek: add support for IRQ grouping

[John Crispin]

The ethernet core has 3 IRQs. Using the IRQ grouping registers we are able
to separate TX and RX IRQs, which allows us to service them on separate
cores. This patch splits the IRQ handler into 2 separate functions, one
for TX and another for RX. The TX housekeeping is split out of the NAPI
handler. Instead we use a tasklet to handle housekeeping.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |  115 +--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |   12 ++-
 2 files changed, 86 insertions(+), 41 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8163047..6387516 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -756,7 +756,7 @@ drop:
 }
 
 static int mtk_poll_rx(struct napi_struct *napi, int budget,
-  struct mtk_eth *eth, u32 rx_intr)
+  struct mtk_eth *eth)
 {
struct mtk_rx_ring *ring = >rx_ring;
int idx = ring->calc_idx;
@@ -842,12 +842,12 @@ release_desc:
}
 
if (done < budget)
-   mtk_w32(eth, rx_intr, MTK_QMTK_INT_STATUS);
+   mtk_w32(eth, MTK_RX_DONE_INT, MTK_QMTK_INT_STATUS);
 
return done;
 }
 
-static int mtk_poll_tx(struct mtk_eth *eth, int budget, bool *tx_again)
+static int mtk_poll_tx(struct mtk_eth *eth, int budget)
 {
struct mtk_tx_ring *ring = >tx_ring;
struct mtk_tx_dma *desc;
@@ -910,9 +910,7 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
}
 
/* read hw index again make sure no new tx packet */
-   if (cpu != dma || cpu != mtk_r32(eth, MTK_QTX_DRX_PTR))
-   *tx_again = true;
-   else
+   if (cpu == dma && cpu == mtk_r32(eth, MTK_QTX_DRX_PTR))
mtk_w32(eth, MTK_TX_DONE_INT, MTK_QMTK_INT_STATUS);
 
if (!total)
@@ -924,27 +922,27 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
return total;
 }
 
+static void mtk_clean_tx_tasklet(unsigned long arg)
+{
+   struct mtk_eth *eth = (struct mtk_eth *)arg;
+
+   if (mtk_poll_tx(eth, MTK_NAPI_WEIGHT) > 0)
+   tasklet_schedule(>tx_clean_tasklet);
+   else
+   mtk_irq_enable(eth, MTK_TX_DONE_INT);
+}
+
 static int mtk_poll(struct napi_struct *napi, int budget)
 {
struct mtk_eth *eth = container_of(napi, struct mtk_eth, rx_napi);
-   u32 status, status2, mask, tx_intr, rx_intr, status_intr;
-   int tx_done, rx_done;
-   bool tx_again = false;
+   u32 status, status2, mask, status_intr;
+   int rx_done = 0;
 
status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
status2 = mtk_r32(eth, MTK_INT_STATUS2);
-   tx_intr = MTK_TX_DONE_INT;
-   rx_intr = MTK_RX_DONE_INT;
status_intr = (MTK_GDM1_AF | MTK_GDM2_AF);
-   tx_done = 0;
-   rx_done = 0;
-   tx_again = 0;
 
-   if (status & tx_intr)
-   tx_done = mtk_poll_tx(eth, budget, _again);
-
-   if (status & rx_intr)
-   rx_done = mtk_poll_rx(napi, budget, eth, rx_intr);
+   rx_done = mtk_poll_rx(napi, budget, eth);
 
if (unlikely(status2 & status_intr)) {
mtk_stats_update(eth);
@@ -953,20 +951,20 @@ static int mtk_poll(struct napi_struct *napi, int budget)
 
if (unlikely(netif_msg_intr(eth))) {
mask = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   netdev_info(eth->netdev[0],
-   "done tx %d, rx %d, intr 0x%08x/0x%x\n",
-   tx_done, rx_done, status, mask);
+   dev_info(eth->dev,
+"done rx %d, intr 0x%08x/0x%x\n",
+rx_done, status, mask);
}
 
-   if (tx_again || rx_done == budget)
+   if (rx_done == budget)
return budget;
 
status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
-   if (status & (tx_intr | rx_intr))
+   if (status & MTK_RX_DONE_INT)
return budget;
 
napi_complete(napi);
-   mtk_irq_enable(eth, tx_intr | rx_intr);
+   mtk_irq_enable(eth, MTK_RX_DONE_INT);
 
return rx_done;
 }
@@ -1195,22 +1193,43 @@ static void mtk_tx_timeout(struct net_device *dev)
schedule_work(>pending_work);
 }
 
-static irqreturn_t mtk_handle_irq(int irq, void *_eth)
+static irqreturn_t mtk_handle_irq_rx(int irq, void *_eth)
 {
struct mtk_eth *eth = _eth;
u32 status;
 
status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
+   status &= ~MTK_TX_DONE_INT;
+
if (unlikely(!status))
return IRQ_NONE;
 
-   if (likely(status & (MTK_RX_DONE_INT | MTK_TX_DONE_INT))) {
+   if (status & MTK_RX_DONE_INT) {
if (likely(napi_schedule_prep(>rx_napi)))
__napi_schedule(>rx_napi);
-   } else {
-   mtk_w32(eth, status, MTK_QMTK_INT_STATUS);
+ 

Re: Problems with commit a770d946371e ("gpio: pxa: add pin control gpio direction and request")

[Robert Jarzmik]

Guenter Roeck  writes:

>> But no more poor excuses, would you try the patch at the end of this mail, 
>> while
>> I'm doing the same on my Jenkins, on both device-tree and legacy 
>> platform-data
>> builds, to see if we can fix this ?
>>
>> Cheers.
> Any updates ? I still see the problem in mainline.

Please be patient, it's scheduled for this kernel version, see here :
 - Linus fixes tree
 - and more specifically here :
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=fixes=c32f4fd558e1b278addc9514578dd98e20218e00

Cheers.

-- 
Robert

Re: livepatch: robustify klp_register_patch() API error checking

[Jessica Yu]

+++ Jiri Kosina [07/04/16 18:06 +0200]:

From: Jiri Kosina 

Commit 425595a7fc20 ("livepatch: reuse module loader code to write
relocations") adds a possibility of dereferncing pointers supplied by the
consumer of the livepatch API before sanity (NULL) checking them (patch
and patch->mod).

Spotted by smatch tool.

Reported-by: Dan Carpenter 
Signed-off-by: Jiri Kosina 


Acked-by: Jessica Yu 

Thank you Jiri!

Re: Problems with commit a770d946371e ("gpio: pxa: add pin control gpio direction and request")

[Robert Jarzmik]

Guenter Roeck  writes:

>> But no more poor excuses, would you try the patch at the end of this mail, 
>> while
>> I'm doing the same on my Jenkins, on both device-tree and legacy 
>> platform-data
>> builds, to see if we can fix this ?
>>
>> Cheers.
> Any updates ? I still see the problem in mainline.

Please be patient, it's scheduled for this kernel version, see here :
 - Linus fixes tree
 - and more specifically here :
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=fixes=c32f4fd558e1b278addc9514578dd98e20218e00

Cheers.

-- 
Robert

Re: livepatch: robustify klp_register_patch() API error checking

[Jessica Yu]

+++ Jiri Kosina [07/04/16 18:06 +0200]:

From: Jiri Kosina 

Commit 425595a7fc20 ("livepatch: reuse module loader code to write
relocations") adds a possibility of dereferncing pointers supplied by the
consumer of the livepatch API before sanity (NULL) checking them (patch
and patch->mod).

Spotted by smatch tool.

Reported-by: Dan Carpenter 
Signed-off-by: Jiri Kosina 


Acked-by: Jessica Yu 

Thank you Jiri!

Re: [PATCH] kvm: x86: do not leak guest xcr0 into host interrupt handlers

[David Matlack]

On Thu, Apr 7, 2016 at 2:08 AM, Paolo Bonzini  wrote:
>
>
> On 05/04/2016 17:56, David Matlack wrote:
>> On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini  wrote:
>>>
>> ...
>>>
>>> While running my acceptance tests, in one case I got one CPU whose xcr0
>>> had leaked into the host.  This showed up as a SIGILL in strncasecmp's
>>> AVX code, and a simple program confirmed it:
>>>
>>> $ cat xgetbv.c
>>> #include 
>>> int main(void)
>>> {
>>> unsigned xcr0_h, xcr0_l;
>>> asm("xgetbv" : "=d"(xcr0_h), "=a"(xcr0_l) : "c"(0));
>>> printf("%08x:%08x\n", xcr0_h, xcr0_l);
>>> }
>>> $ gcc xgetbv.c -O2
>>> $ for i in `seq 0 55`; do echo $i `taskset -c $i ./a.out`; done|grep -v 
>>> 007
>>> 19 :0003
>>>
>>> I'm going to rerun the tests without this patch, as it seems the most
>>> likely culprit, and leave it out of the pull request if they pass.
>>
>> Agreed this is a very likely culprit. I think I see one way the
>> guest's xcr0 can leak into the host.
>
> That's cancel_injection, right?  If it's just about moving the load call
> below, I can do that.  Hmm, I will even test that today. :)

Yes that's what I was thinking, move kvm_load_guest_xcr0 below that if.

Thank you :). Let me know how testing goes.

>
> Paolo
>

Re: [PATCH] kvm: x86: do not leak guest xcr0 into host interrupt handlers

[David Matlack]

On Thu, Apr 7, 2016 at 2:08 AM, Paolo Bonzini  wrote:
>
>
> On 05/04/2016 17:56, David Matlack wrote:
>> On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini  wrote:
>>>
>> ...
>>>
>>> While running my acceptance tests, in one case I got one CPU whose xcr0
>>> had leaked into the host.  This showed up as a SIGILL in strncasecmp's
>>> AVX code, and a simple program confirmed it:
>>>
>>> $ cat xgetbv.c
>>> #include 
>>> int main(void)
>>> {
>>> unsigned xcr0_h, xcr0_l;
>>> asm("xgetbv" : "=d"(xcr0_h), "=a"(xcr0_l) : "c"(0));
>>> printf("%08x:%08x\n", xcr0_h, xcr0_l);
>>> }
>>> $ gcc xgetbv.c -O2
>>> $ for i in `seq 0 55`; do echo $i `taskset -c $i ./a.out`; done|grep -v 
>>> 007
>>> 19 :0003
>>>
>>> I'm going to rerun the tests without this patch, as it seems the most
>>> likely culprit, and leave it out of the pull request if they pass.
>>
>> Agreed this is a very likely culprit. I think I see one way the
>> guest's xcr0 can leak into the host.
>
> That's cancel_injection, right?  If it's just about moving the load call
> below, I can do that.  Hmm, I will even test that today. :)

Yes that's what I was thinking, move kvm_load_guest_xcr0 below that if.

Thank you :). Let me know how testing goes.

>
> Paolo
>

Re: Regulator: drivers that need to know their supply

[Martin Fuzzey]

Thanks for your reply.

On 07/04/16 19:02, Mark Brown wrote:

On Thu, Apr 07, 2016 at 03:25:09PM +0200, Martin Fuzzey wrote:


To implement the .enable_time() method I need the voltage (which is
the supply's voltage).

No, this is not sensible.  You should be telling the framework about the
slew rate and letting the framework work out how long it's going to take
to transition.  Your driver shouldn't be peering around inside other
regulators, it should be telling the framework what it does itself and
any handling of interrelationships should be in the framework.


Ok, but I fail to see any way to do that (at least with the framework as 
is).


The framework can tell the driver what slew rate to use (via 
.set_ramp_delay)

And it can ask the driver what the turn on time is (via .enable_time)
It doesn't actullay know the slew rate (as a driver may not have 
configurable
slew rates or the driver may have rounded the slew rate to something it 
supports)


Or are you saying I should extend the framework to add a .get_ramp_delay
driver callback and make the framework do the calculation itself?

Happy to do that if it's the best way but your reply makes it sound
like i'm not using an existing framework functionality and I don't think
that is the case unless I'm overlooking something.

I'm just trying to do what rc5t583 already does in 
rc5t583_regulator_enable_time()
except that in my case I don't know the voltage (since it comes from my 
supply).


While moving it to the framework will avoid the driver knowing about other
regulators it won't fix the underlying issues I mentionned.

For a regulator configured as always-on the framework doesn't lookup and
enable the parent  regulators until regulator_register_resolve_supply()
is caused right at the end of regulator_register().

This means that, when the always-on register is enabled it has no supply
assigned, even at the  framework level.

It also means that currently there is a difference in the switch on order
depending if the regulator is configured as always-on:

Suppose A is the supply for B.

If B is NOT always-on, calling regulator_enable(B) will first enable A 
then B

However if B is always-on, regulator_register(B) will first enable B then A

I'm not sure this actually matters in practice but A then B seems better
from an inrush current point of view.

Regards,

Martin

Re: Regulator: drivers that need to know their supply

[Martin Fuzzey]

Thanks for your reply.

On 07/04/16 19:02, Mark Brown wrote:

On Thu, Apr 07, 2016 at 03:25:09PM +0200, Martin Fuzzey wrote:


To implement the .enable_time() method I need the voltage (which is
the supply's voltage).

No, this is not sensible.  You should be telling the framework about the
slew rate and letting the framework work out how long it's going to take
to transition.  Your driver shouldn't be peering around inside other
regulators, it should be telling the framework what it does itself and
any handling of interrelationships should be in the framework.


Ok, but I fail to see any way to do that (at least with the framework as 
is).


The framework can tell the driver what slew rate to use (via 
.set_ramp_delay)

And it can ask the driver what the turn on time is (via .enable_time)
It doesn't actullay know the slew rate (as a driver may not have 
configurable
slew rates or the driver may have rounded the slew rate to something it 
supports)


Or are you saying I should extend the framework to add a .get_ramp_delay
driver callback and make the framework do the calculation itself?

Happy to do that if it's the best way but your reply makes it sound
like i'm not using an existing framework functionality and I don't think
that is the case unless I'm overlooking something.

I'm just trying to do what rc5t583 already does in 
rc5t583_regulator_enable_time()
except that in my case I don't know the voltage (since it comes from my 
supply).


While moving it to the framework will avoid the driver knowing about other
regulators it won't fix the underlying issues I mentionned.

For a regulator configured as always-on the framework doesn't lookup and
enable the parent  regulators until regulator_register_resolve_supply()
is caused right at the end of regulator_register().

This means that, when the always-on register is enabled it has no supply
assigned, even at the  framework level.

It also means that currently there is a difference in the switch on order
depending if the regulator is configured as always-on:

Suppose A is the supply for B.

If B is NOT always-on, calling regulator_enable(B) will first enable A 
then B

However if B is always-on, regulator_register(B) will first enable B then A

I'm not sure this actually matters in practice but A then B seems better
from an inrush current point of view.

Regards,

Martin

Re: [PATCH 1/2] regulator: s2mps11: Use module_platform_driver() instead subsys initcall

[Javier Martinez Canillas]

Hello Krzysztof,

On 04/07/2016 08:30 AM, Krzysztof Kozlowski wrote:
> On Wed, Apr 06, 2016 at 09:49:46AM -0400, Javier Martinez Canillas wrote:
>> The driver's init and exit function don't do anything besides registering
>> and unregistering the platform driver, so the module_platform_driver()
>> macro could just be used instead of having separate functions.
>>
>> Currently the macro is not being used because the driver is initialized at
>> subsys init call level but this isn't necessary since consumer devices are
>> defined in the DT as dependencies so there's no need for init calls order.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>> This patch was tested on an Exynos5422 Odroid XU4 board.
> 
> This test might not be sufficient. XU4 is not a mobile device like many
> other users of this driver (except Arndale Octa and Artiks all of other
> users are mobiles/wearables).
> 
> For example XU4 does not have USB OTG (like other devices and like XU3).
>

All the consumer device nodes for these regulators are defined in the
exynos5422-odroidxu3-common.dtsi that is shared by all the Odroid XU*
so I thought testing in the XU4 was as good as testing in the XU3
(since the USB OTG doesn't use a regulator from this PMIC).

I've also checked the DTS for all the boards that use regulators that
are registered by this driver and all consumer drivers supports probe
deferral so I think this change is safe.

Also, the driver Kconfig symbol is tristate already so the driver can be
built as module and the init func won't be executed at subsys init call.
 
> Best regards,
> Krzysztof
> 
>>
>>  drivers/regulator/s2mps11.c | 12 +---
>>  1 file changed, 1 insertion(+), 11 deletions(-)
>>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 1/2] regulator: s2mps11: Use module_platform_driver() instead subsys initcall

[Javier Martinez Canillas]

Hello Krzysztof,

On 04/07/2016 08:30 AM, Krzysztof Kozlowski wrote:
> On Wed, Apr 06, 2016 at 09:49:46AM -0400, Javier Martinez Canillas wrote:
>> The driver's init and exit function don't do anything besides registering
>> and unregistering the platform driver, so the module_platform_driver()
>> macro could just be used instead of having separate functions.
>>
>> Currently the macro is not being used because the driver is initialized at
>> subsys init call level but this isn't necessary since consumer devices are
>> defined in the DT as dependencies so there's no need for init calls order.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>> This patch was tested on an Exynos5422 Odroid XU4 board.
> 
> This test might not be sufficient. XU4 is not a mobile device like many
> other users of this driver (except Arndale Octa and Artiks all of other
> users are mobiles/wearables).
> 
> For example XU4 does not have USB OTG (like other devices and like XU3).
>

All the consumer device nodes for these regulators are defined in the
exynos5422-odroidxu3-common.dtsi that is shared by all the Odroid XU*
so I thought testing in the XU4 was as good as testing in the XU3
(since the USB OTG doesn't use a regulator from this PMIC).

I've also checked the DTS for all the boards that use regulators that
are registered by this driver and all consumer drivers supports probe
deferral so I think this change is safe.

Also, the driver Kconfig symbol is tristate already so the driver can be
built as module and the init func won't be executed at subsys init call.
 
> Best regards,
> Krzysztof
> 
>>
>>  drivers/regulator/s2mps11.c | 12 +---
>>  1 file changed, 1 insertion(+), 11 deletions(-)
>>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

[Joe Perches]

On Thu, 2016-04-07 at 21:06 +0300, Andy Shevchenko wrote:
> On Thu, Apr 7, 2016 at 9:04 PM, Joe Perches  wrote:
> > On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote:
> > > On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim  wrote:
> > > > 
> > > > Remove unneeded blank lines appearing after opening braces as suggested
> > > > by checkpatch.pl
> > > > 
> > > You have to combine this with the rest so called 'indentation' fixes,
> > > e.g. +- empty lines, tabs vs. spaces, etc.
> > Actually, patches that do single things like removing
> > undesired blank lines are easier to review if separate
> > from patches that change horizontal whitespace.
> > 
> Okay, but I think you at least agree that +- empty lines can be easily 
> combined.

Not really, but it's not important enough to me to care much
either way.

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

[Joe Perches]

On Thu, 2016-04-07 at 21:06 +0300, Andy Shevchenko wrote:
> On Thu, Apr 7, 2016 at 9:04 PM, Joe Perches  wrote:
> > On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote:
> > > On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim  wrote:
> > > > 
> > > > Remove unneeded blank lines appearing after opening braces as suggested
> > > > by checkpatch.pl
> > > > 
> > > You have to combine this with the rest so called 'indentation' fixes,
> > > e.g. +- empty lines, tabs vs. spaces, etc.
> > Actually, patches that do single things like removing
> > undesired blank lines are easier to review if separate
> > from patches that change horizontal whitespace.
> > 
> Okay, but I think you at least agree that +- empty lines can be easily 
> combined.

Not really, but it's not important enough to me to care much
either way.

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

[Andy Gross]

On Thu, Apr 07, 2016 at 12:57:36PM -0500, Rob Herring wrote:
> On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote:
> > This adds the regulator nodes to DK04 device tree to support
> > 
> > Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa
> > Signed-off-by: Sreedhar Sambangi 
> > ---
> >  .../bindings/regulator/ipq4019-regulator.txt  | 19 
> > +++
> >  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 11 +++
> >  2 files changed, 30 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt 
> > b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> > new file mode 100644
> > index 000..9d934a4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> > @@ -0,0 +1,19 @@
> > +* Qualcomm Technologies, Inc. IPQ4019 regulators
> > +
> > +Required properties:
> > +- compatible   : Must be "regulator-ipq4019".
> 
> Doesn't match your example which correctly has vendor prefix. Also, the 
> preferred form is ,-.
> 
> > +- states   : Selection of available voltages and corresponding 
> > values
> 
> Too generic of a name.
> 
> Is this not fixed by the h/w block?

I'd put this info in the driver itself.  I believe it has 4 fixed states.

> 
> > +- reg  : Register address for controlling LDO
> > +- mask : Mask value for switching voltages
> 
> What else is in this register? If something unrelated, then this is all 
> wrong to the regulator. You can only define the register address in one 
> place in the DT. Otherwise, you should know the mask from the compatible 
> string.

I agree.  All of this needs to be done inside the code itself.  All you need is
the register.  This is a TCSR register which means that it could have other bits
doing other things.  I would hope that the hw guys isolated only regulator bits
in here.


Regards,

Andy Gross

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

[Andy Gross]

On Thu, Apr 07, 2016 at 12:57:36PM -0500, Rob Herring wrote:
> On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote:
> > This adds the regulator nodes to DK04 device tree to support
> > 
> > Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa
> > Signed-off-by: Sreedhar Sambangi 
> > ---
> >  .../bindings/regulator/ipq4019-regulator.txt  | 19 
> > +++
> >  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 11 +++
> >  2 files changed, 30 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt 
> > b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> > new file mode 100644
> > index 000..9d934a4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> > @@ -0,0 +1,19 @@
> > +* Qualcomm Technologies, Inc. IPQ4019 regulators
> > +
> > +Required properties:
> > +- compatible   : Must be "regulator-ipq4019".
> 
> Doesn't match your example which correctly has vendor prefix. Also, the 
> preferred form is ,-.
> 
> > +- states   : Selection of available voltages and corresponding 
> > values
> 
> Too generic of a name.
> 
> Is this not fixed by the h/w block?

I'd put this info in the driver itself.  I believe it has 4 fixed states.

> 
> > +- reg  : Register address for controlling LDO
> > +- mask : Mask value for switching voltages
> 
> What else is in this register? If something unrelated, then this is all 
> wrong to the regulator. You can only define the register address in one 
> place in the DT. Otherwise, you should know the mask from the compatible 
> string.

I agree.  All of this needs to be done inside the code itself.  All you need is
the register.  This is a TCSR register which means that it could have other bits
doing other things.  I would hope that the hw guys isolated only regulator bits
in here.


Regards,

Andy Gross

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

[Andy Shevchenko]

On Thu, Apr 7, 2016 at 9:04 PM, Joe Perches  wrote:
> On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote:
>> On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim  wrote:
>> >
>> > Remove unneeded blank lines appearing after opening braces as suggested
>> > by checkpatch.pl
>> >
>> You have to combine this with the rest so called 'indentation' fixes,
>> e.g. +- empty lines, tabs vs. spaces, etc.
>
> Actually, patches that do single things like removing
> undesired blank lines are easier to review if separate
> from patches that change horizontal whitespace.
>

Okay, but I think you at least agree that +- empty lines can be easily combined.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

[Andy Shevchenko]

On Thu, Apr 7, 2016 at 9:04 PM, Joe Perches  wrote:
> On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote:
>> On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim  wrote:
>> >
>> > Remove unneeded blank lines appearing after opening braces as suggested
>> > by checkpatch.pl
>> >
>> You have to combine this with the rest so called 'indentation' fixes,
>> e.g. +- empty lines, tabs vs. spaces, etc.
>
> Actually, patches that do single things like removing
> undesired blank lines are easier to review if separate
> from patches that change horizontal whitespace.
>

Okay, but I think you at least agree that +- empty lines can be easily combined.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] i2c: designware-platdrv: get fast/std speed scl high/low count from DT

[Andy Shevchenko]

On Wed, Apr 6, 2016 at 10:28 AM, Jisheng Zhang  wrote:
> Sometimes, it's convenient to define the scl's high/low count directly,
> e.g HW people would do some measurement then directly give out the
> optimum counts. Previously, we solved the sda falling time and scl
> falling time by i2c_dw_scl_hcnt() and i2c_dw_scl_lcnt(), then put them
> into dt, but what we really care isn't the sda/scl falling time.
>
> From another side, the dw_i2c_acpi_configure() on ACPI platform also
> get hcnt/lcnt values rather than the sda/scl falling time from ACPI
> method, we want similar feature for DT platforms.
>

Instead of duplicating some words maybe better to explicitly define
two groups of parameters and one which supersedes the other.

> Signed-off-by: Jisheng Zhang 
> ---
>  Documentation/devicetree/bindings/i2c/i2c-designware.txt | 16 
> 
>  drivers/i2c/busses/i2c-designware-platdrv.c  |  8 
>  2 files changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> index fee26dc..05176fbf 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> @@ -20,6 +20,22 @@ Optional properties :
>   - i2c-sda-falling-time-ns : should contain the SDA falling time in 
> nanoseconds.
> This value which is by default 300ns is used to compute the tHIGH period.
>
> + - i2c-ss-scl-high-count : should contain the standard speed i2c clock SCL 
> high
> +   count. If defined, the i2c-scl-falling-time-ns and i2c-sda-falling-time-ns
> +   will be ignored.
> +
> + - i2c-ss-scl-low-count : should contain the standard speed i2c clock SCL low
> +   count. If defined, the i2c-scl-falling-time-ns and i2c-sda-falling-time-ns
> +   will be ignored.
> +
> + - i2c-fs-scl-high-count : should contain the fast speed i2c clock SCL high
> +   count. If defined, the i2c-scl-falling-time-ns and i2c-sda-falling-time-ns
> +   will be ignored.
> +
> + - i2c-fs-scl-low-count : should contain the fast speed i2c clock SCL low
> +   count. If defined, the i2c-scl-falling-time-ns and i2c-sda-falling-time-ns
> +   will be ignored.
> +
>  Example :
>
> i2c@f {
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index d656657..8739a60 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -188,6 +188,14 @@ static int dw_i2c_plat_probe(struct platform_device 
> *pdev)
>  >scl_falling_time);
> device_property_read_u32(>dev, "clock-frequency",
>  _freq);
> +   device_property_read_u16(>dev, "i2c-ss-scl-high-count",
> +>ss_hcnt);
> +   device_property_read_u16(>dev, "i2c-ss-scl-low-count",
> +>ss_lcnt);
> +   device_property_read_u16(>dev, "i2c-fs-scl-high-count",
> +>fs_hcnt);
> +   device_property_read_u16(>dev, "i2c-fs-scl-low-count",
> +>fs_lcnt);
> }
>
> if (has_acpi_companion(>dev))
> --
> 2.8.0.rc3
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] i2c: designware-platdrv: get fast/std speed scl high/low count from DT

[Andy Shevchenko]

On Wed, Apr 6, 2016 at 10:28 AM, Jisheng Zhang  wrote:
> Sometimes, it's convenient to define the scl's high/low count directly,
> e.g HW people would do some measurement then directly give out the
> optimum counts. Previously, we solved the sda falling time and scl
> falling time by i2c_dw_scl_hcnt() and i2c_dw_scl_lcnt(), then put them
> into dt, but what we really care isn't the sda/scl falling time.
>
> From another side, the dw_i2c_acpi_configure() on ACPI platform also
> get hcnt/lcnt values rather than the sda/scl falling time from ACPI
> method, we want similar feature for DT platforms.
>

Instead of duplicating some words maybe better to explicitly define
two groups of parameters and one which supersedes the other.

> Signed-off-by: Jisheng Zhang 
> ---
>  Documentation/devicetree/bindings/i2c/i2c-designware.txt | 16 
> 
>  drivers/i2c/busses/i2c-designware-platdrv.c  |  8 
>  2 files changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> index fee26dc..05176fbf 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> @@ -20,6 +20,22 @@ Optional properties :
>   - i2c-sda-falling-time-ns : should contain the SDA falling time in 
> nanoseconds.
> This value which is by default 300ns is used to compute the tHIGH period.
>
> + - i2c-ss-scl-high-count : should contain the standard speed i2c clock SCL 
> high
> +   count. If defined, the i2c-scl-falling-time-ns and i2c-sda-falling-time-ns
> +   will be ignored.
> +
> + - i2c-ss-scl-low-count : should contain the standard speed i2c clock SCL low
> +   count. If defined, the i2c-scl-falling-time-ns and i2c-sda-falling-time-ns
> +   will be ignored.
> +
> + - i2c-fs-scl-high-count : should contain the fast speed i2c clock SCL high
> +   count. If defined, the i2c-scl-falling-time-ns and i2c-sda-falling-time-ns
> +   will be ignored.
> +
> + - i2c-fs-scl-low-count : should contain the fast speed i2c clock SCL low
> +   count. If defined, the i2c-scl-falling-time-ns and i2c-sda-falling-time-ns
> +   will be ignored.
> +
>  Example :
>
> i2c@f {
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index d656657..8739a60 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -188,6 +188,14 @@ static int dw_i2c_plat_probe(struct platform_device 
> *pdev)
>  >scl_falling_time);
> device_property_read_u32(>dev, "clock-frequency",
>  _freq);
> +   device_property_read_u16(>dev, "i2c-ss-scl-high-count",
> +>ss_hcnt);
> +   device_property_read_u16(>dev, "i2c-ss-scl-low-count",
> +>ss_lcnt);
> +   device_property_read_u16(>dev, "i2c-fs-scl-high-count",
> +>fs_hcnt);
> +   device_property_read_u16(>dev, "i2c-fs-scl-low-count",
> +>fs_lcnt);
> }
>
> if (has_acpi_companion(>dev))
> --
> 2.8.0.rc3
>



-- 
With Best Regards,
Andy Shevchenko

Applied "ASoC: dwc: Use fifo depth to program FCR" to the asoc tree

[Mark Brown]

The patch

   ASoC: dwc: Use fifo depth to program FCR

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 3fafd14d9422c46f5c2a142298384dc15dbf88b2 Mon Sep 17 00:00:00 2001
From: Jose Abreu 
Date: Thu, 7 Apr 2016 17:53:57 +0100
Subject: [PATCH] ASoC: dwc: Use fifo depth to program FCR

This patch makes Designware I2S driver use the fifo
depth value to program the fifo configuration register
instead of using hardcoded values.

Signed-off-by: Jose Abreu 
Signed-off-by: Mark Brown 
---
 sound/soc/dwc/designware_i2s.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 3effcd1a7df8..0db69b7e9617 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -100,6 +100,7 @@ struct dw_i2s_dev {
struct device *dev;
u32 ccr;
u32 xfer_resolution;
+   u32 fifo_th;
 
/* data related to DMA transfers b/w i2s and DMAC */
union dw_i2s_snd_dma_data play_dma_data;
@@ -232,14 +233,16 @@ static void dw_i2s_config(struct dw_i2s_dev *dev, int 
stream)
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
i2s_write_reg(dev->i2s_base, TCR(ch_reg),
  dev->xfer_resolution);
-   i2s_write_reg(dev->i2s_base, TFCR(ch_reg), 0x02);
+   i2s_write_reg(dev->i2s_base, TFCR(ch_reg),
+ dev->fifo_th - 1);
irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x30);
i2s_write_reg(dev->i2s_base, TER(ch_reg), 1);
} else {
i2s_write_reg(dev->i2s_base, RCR(ch_reg),
  dev->xfer_resolution);
-   i2s_write_reg(dev->i2s_base, RFCR(ch_reg), 0x07);
+   i2s_write_reg(dev->i2s_base, RFCR(ch_reg),
+ dev->fifo_th - 1);
irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x03);
i2s_write_reg(dev->i2s_base, RER(ch_reg), 1);
@@ -499,6 +502,7 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
 */
u32 comp1 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp1);
u32 comp2 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp2);
+   u32 fifo_depth = 1 << (1 + COMP1_FIFO_DEPTH_GLOBAL(comp1));
u32 idx;
 
if (dev->capability & DWC_I2S_RECORD &&
@@ -537,6 +541,7 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
dev->capability |= DW_I2S_SLAVE;
}
 
+   dev->fifo_th = fifo_depth / 2;
return 0;
 }
 
-- 
2.8.0.rc3

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

[Joe Perches]

On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote:
> On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim  wrote:
> > 
> > Remove unneeded blank lines appearing after opening braces as suggested
> > by checkpatch.pl
> > 
> You have to combine this with the rest so called 'indentation' fixes,
> e.g. +- empty lines, tabs vs. spaces, etc.

Actually, patches that do single things like removing
undesired blank lines are easier to review if separate
from patches that change horizontal whitespace.

Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

[Linus Walleij]

On Thu, Apr 7, 2016 at 4:17 PM, Octavian Purdila
 wrote:
> On Wed, Apr 6, 2016 at 1:49 PM, Graeme Gregory  wrote:

>> Why has there been no attempt in ASWG to make these sort of features a
>> 1st class citizen of ACPI so they can interact correctly with the other
>> features?
>
> IMO having an ASWG pinctrl specification and using _DSD for Linux are
> orthogonal approaches. The latter is very specific to Linux and we
> want it so that we can support the Linux pinctrl model as best as
> possible and I doubt it is a common denominator for all OSes that ACPI
> supports.

Sob, I tried so hard to implement pin control referring to generic
concepts that everyone should be able to reuse. E.g. stressing SI
units to be used all over the place, neutral scientific terms for all
config options and what not.

The multiplexing with groups and functions is a simple (aehm,
OK, super-complicated) matter of mapping disjunct sets onto each
other, so that comes from logic.

Not even the GPIO ranges that map GPIOs to pin ranges are very
Linux-specific: it is a property of the hardware that sometimes
GPIO is "behind" the pin, in a distinct hardware unit. (See pinctrl.txt
for the GPIO pitfalls.)

If I was to rewrite pin control and GPIO from scratch I would make it
one subsystem instead of two. This is more of an architectural
choice. GPIO would still be a stand-alone part of it.

Yours,
Linus Walleij

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

[Josh Poimboeuf]

On Thu, Apr 07, 2016 at 05:47:00PM +0200, Jiri Kosina wrote:
> On Thu, 7 Apr 2016, Josh Poimboeuf wrote:
> 
> > > > - try ftrace handler switching idea from v1 cover letter
> [ ... ]
> > > We probably should not check the stack in atomic context
> > 
> > Can you elaborate why not?
> 
> I admittedly forgot what the "ftrace handler switching idea" is, and am 
> not sure where exactly to look for it (could you please point it to me so 
> that I can refresh my memory)

Here's where I originally described it [1]:

| 2) As mentioned above, kthreads which are always sleeping on a patched 
function
|will never transition to the new universe.  This is really a minor issue
|(less than 1% of patches).  It's not necessarily something that needs to be
|resolved with this patch set, but it would be good to have some discussion
|about it regardless.
|
|To overcome this issue, I have 1/2 an idea: we could add some stack 
checking
|code to the ftrace handler itself to transition the kthread to the new
|universe after it re-enters the function it was originally sleeping on, if
|the stack doesn't already have have any other to-be-patched functions.
|Combined with the klp_transition_work_fn()'s periodic stack checking of
|sleeping tasks, that would handle most of the cases (except when trying to
|patch the high-level thread_fn itself).

> but generally we can't assume that a memory holding stack of a
> sleeping task hasn't been reclaimed and wouldn't need to have been
> paged in again.

Hm, we're talking about kernel stacks, right?  Are they not always
resident in memory?


[1] https://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com:

-- 
Josh

Re: [PATCH v2 3/5] dmaengine: qcom: bam_dma: add controlled remotely dt property

[Rob Herring]

On Wed, Apr 06, 2016 at 01:56:20AM +0300, Stanimir Varbanov wrote:
> Some of the peripherals has bam which is controlled by remote
> processor, thus the bam dma driver must avoid register writes
> which initialise bam hw block. Those registers are protected
> from xPU block and any writes to them will lead to secure
> violation and system reboot.
> 
> Adding the contolled_remotely flag in bam driver to avoid
> not permitted register writes in bam_init function.
> 
> Signed-off-by: Stanimir Varbanov 
> Reviewed-by: Andy Gross 
> ---
>  Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++
>  drivers/dma/qcom/bam_dma.c | 7 +++
>  2 files changed, 9 insertions(+)

Acked-by: Rob Herring 

On being a separate patch, yes that is always the preference. However, 
this change is so small it doesn't matter to me. But this is going in 
thru Vinod's tree, so it is his call.

Rob

Applied "ASoC: dwc: Use fifo depth to program FCR" to the asoc tree

[Mark Brown]

The patch

   ASoC: dwc: Use fifo depth to program FCR

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 3fafd14d9422c46f5c2a142298384dc15dbf88b2 Mon Sep 17 00:00:00 2001
From: Jose Abreu 
Date: Thu, 7 Apr 2016 17:53:57 +0100
Subject: [PATCH] ASoC: dwc: Use fifo depth to program FCR

This patch makes Designware I2S driver use the fifo
depth value to program the fifo configuration register
instead of using hardcoded values.

Signed-off-by: Jose Abreu 
Signed-off-by: Mark Brown 
---
 sound/soc/dwc/designware_i2s.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 3effcd1a7df8..0db69b7e9617 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -100,6 +100,7 @@ struct dw_i2s_dev {
struct device *dev;
u32 ccr;
u32 xfer_resolution;
+   u32 fifo_th;
 
/* data related to DMA transfers b/w i2s and DMAC */
union dw_i2s_snd_dma_data play_dma_data;
@@ -232,14 +233,16 @@ static void dw_i2s_config(struct dw_i2s_dev *dev, int 
stream)
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
i2s_write_reg(dev->i2s_base, TCR(ch_reg),
  dev->xfer_resolution);
-   i2s_write_reg(dev->i2s_base, TFCR(ch_reg), 0x02);
+   i2s_write_reg(dev->i2s_base, TFCR(ch_reg),
+ dev->fifo_th - 1);
irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x30);
i2s_write_reg(dev->i2s_base, TER(ch_reg), 1);
} else {
i2s_write_reg(dev->i2s_base, RCR(ch_reg),
  dev->xfer_resolution);
-   i2s_write_reg(dev->i2s_base, RFCR(ch_reg), 0x07);
+   i2s_write_reg(dev->i2s_base, RFCR(ch_reg),
+ dev->fifo_th - 1);
irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x03);
i2s_write_reg(dev->i2s_base, RER(ch_reg), 1);
@@ -499,6 +502,7 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
 */
u32 comp1 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp1);
u32 comp2 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp2);
+   u32 fifo_depth = 1 << (1 + COMP1_FIFO_DEPTH_GLOBAL(comp1));
u32 idx;
 
if (dev->capability & DWC_I2S_RECORD &&
@@ -537,6 +541,7 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
dev->capability |= DW_I2S_SLAVE;
}
 
+   dev->fifo_th = fifo_depth / 2;
return 0;
 }
 
-- 
2.8.0.rc3

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

[Joe Perches]

On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote:
> On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim  wrote:
> > 
> > Remove unneeded blank lines appearing after opening braces as suggested
> > by checkpatch.pl
> > 
> You have to combine this with the rest so called 'indentation' fixes,
> e.g. +- empty lines, tabs vs. spaces, etc.

Actually, patches that do single things like removing
undesired blank lines are easier to review if separate
from patches that change horizontal whitespace.

Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

[Linus Walleij]

On Thu, Apr 7, 2016 at 4:17 PM, Octavian Purdila
 wrote:
> On Wed, Apr 6, 2016 at 1:49 PM, Graeme Gregory  wrote:

>> Why has there been no attempt in ASWG to make these sort of features a
>> 1st class citizen of ACPI so they can interact correctly with the other
>> features?
>
> IMO having an ASWG pinctrl specification and using _DSD for Linux are
> orthogonal approaches. The latter is very specific to Linux and we
> want it so that we can support the Linux pinctrl model as best as
> possible and I doubt it is a common denominator for all OSes that ACPI
> supports.

Sob, I tried so hard to implement pin control referring to generic
concepts that everyone should be able to reuse. E.g. stressing SI
units to be used all over the place, neutral scientific terms for all
config options and what not.

The multiplexing with groups and functions is a simple (aehm,
OK, super-complicated) matter of mapping disjunct sets onto each
other, so that comes from logic.

Not even the GPIO ranges that map GPIOs to pin ranges are very
Linux-specific: it is a property of the hardware that sometimes
GPIO is "behind" the pin, in a distinct hardware unit. (See pinctrl.txt
for the GPIO pitfalls.)

If I was to rewrite pin control and GPIO from scratch I would make it
one subsystem instead of two. This is more of an architectural
choice. GPIO would still be a stand-alone part of it.

Yours,
Linus Walleij

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

[Josh Poimboeuf]

On Thu, Apr 07, 2016 at 05:47:00PM +0200, Jiri Kosina wrote:
> On Thu, 7 Apr 2016, Josh Poimboeuf wrote:
> 
> > > > - try ftrace handler switching idea from v1 cover letter
> [ ... ]
> > > We probably should not check the stack in atomic context
> > 
> > Can you elaborate why not?
> 
> I admittedly forgot what the "ftrace handler switching idea" is, and am 
> not sure where exactly to look for it (could you please point it to me so 
> that I can refresh my memory)

Here's where I originally described it [1]:

| 2) As mentioned above, kthreads which are always sleeping on a patched 
function
|will never transition to the new universe.  This is really a minor issue
|(less than 1% of patches).  It's not necessarily something that needs to be
|resolved with this patch set, but it would be good to have some discussion
|about it regardless.
|
|To overcome this issue, I have 1/2 an idea: we could add some stack 
checking
|code to the ftrace handler itself to transition the kthread to the new
|universe after it re-enters the function it was originally sleeping on, if
|the stack doesn't already have have any other to-be-patched functions.
|Combined with the klp_transition_work_fn()'s periodic stack checking of
|sleeping tasks, that would handle most of the cases (except when trying to
|patch the high-level thread_fn itself).

> but generally we can't assume that a memory holding stack of a
> sleeping task hasn't been reclaimed and wouldn't need to have been
> paged in again.

Hm, we're talking about kernel stacks, right?  Are they not always
resident in memory?


[1] https://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com:

-- 
Josh

Re: [PATCH v2 3/5] dmaengine: qcom: bam_dma: add controlled remotely dt property

[Rob Herring]

On Wed, Apr 06, 2016 at 01:56:20AM +0300, Stanimir Varbanov wrote:
> Some of the peripherals has bam which is controlled by remote
> processor, thus the bam dma driver must avoid register writes
> which initialise bam hw block. Those registers are protected
> from xPU block and any writes to them will lead to secure
> violation and system reboot.
> 
> Adding the contolled_remotely flag in bam driver to avoid
> not permitted register writes in bam_init function.
> 
> Signed-off-by: Stanimir Varbanov 
> Reviewed-by: Andy Gross 
> ---
>  Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++
>  drivers/dma/qcom/bam_dma.c | 7 +++
>  2 files changed, 9 insertions(+)

Acked-by: Rob Herring 

On being a separate patch, yes that is always the preference. However, 
this change is so small it doesn't matter to me. But this is going in 
thru Vinod's tree, so it is his call.

Rob

Re: [PATCH RFC 1/5] net: phy: sun8i-h3-ephy: Add bindings for Allwinner H3 Ethernet PHY

[Rob Herring]

On Tue, Apr 05, 2016 at 12:22:30AM +0800, Chen-Yu Tsai wrote:
> The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and
> configured through a memory mapped hardware register.
> 
> This same register also configures the MAC interface mode and TX clock
> source. Also covered by the register, but not supported in these bindings,
> are TX/RX clock delay chains and inverters, and an RMII module.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../bindings/net/allwinner,sun8i-h3-ephy.txt   | 44 
> ++
>  1 file changed, 44 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt

Acked-by: Rob Herring 

Re: [PATCH] i2c: designware-platdrv: get fast/std speed scl high/low count from DT

[Rob Herring]

On Wed, Apr 06, 2016 at 03:28:00PM +0800, Jisheng Zhang wrote:
> Sometimes, it's convenient to define the scl's high/low count directly,
> e.g HW people would do some measurement then directly give out the
> optimum counts. Previously, we solved the sda falling time and scl
> falling time by i2c_dw_scl_hcnt() and i2c_dw_scl_lcnt(), then put them
> into dt, but what we really care isn't the sda/scl falling time.

This is just so you can put specific clock count instead of converting 
from nanoseconds with standard properties or you gain some additional 
control of the timing. If only the former, then I prefer we stick with 
the common properties.

> From another side, the dw_i2c_acpi_configure() on ACPI platform also
> get hcnt/lcnt values rather than the sda/scl falling time from ACPI
> method, we want similar feature for DT platforms.

That's nice, but not really a reason IMO.

> 
> Signed-off-by: Jisheng Zhang 
> ---
>  Documentation/devicetree/bindings/i2c/i2c-designware.txt | 16 
> 
>  drivers/i2c/busses/i2c-designware-platdrv.c  |  8 
>  2 files changed, 24 insertions(+)

[PATCH 3/9] net: mediatek: mtk_cal_txd_req() returns bad value

[John Crispin]

The code used to also support the PDMA engine, which had 2 packet pointers
per descriptor. Because of this we had to divide the result by 2 and round
it up. This is no longer needed as the code only supports QDMA.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index bb10d57..94cceb8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -681,7 +681,7 @@ static inline int mtk_cal_txd_req(struct sk_buff *skb)
nfrags += skb_shinfo(skb)->nr_frags;
}
 
-   return DIV_ROUND_UP(nfrags, 2);
+   return nfrags;
 }
 
 static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
-- 
1.7.10.4

Re: [PATCH RFC 1/5] net: phy: sun8i-h3-ephy: Add bindings for Allwinner H3 Ethernet PHY

[Rob Herring]

On Tue, Apr 05, 2016 at 12:22:30AM +0800, Chen-Yu Tsai wrote:
> The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and
> configured through a memory mapped hardware register.
> 
> This same register also configures the MAC interface mode and TX clock
> source. Also covered by the register, but not supported in these bindings,
> are TX/RX clock delay chains and inverters, and an RMII module.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../bindings/net/allwinner,sun8i-h3-ephy.txt   | 44 
> ++
>  1 file changed, 44 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt

Acked-by: Rob Herring 

Re: [PATCH] i2c: designware-platdrv: get fast/std speed scl high/low count from DT

[Rob Herring]

On Wed, Apr 06, 2016 at 03:28:00PM +0800, Jisheng Zhang wrote:
> Sometimes, it's convenient to define the scl's high/low count directly,
> e.g HW people would do some measurement then directly give out the
> optimum counts. Previously, we solved the sda falling time and scl
> falling time by i2c_dw_scl_hcnt() and i2c_dw_scl_lcnt(), then put them
> into dt, but what we really care isn't the sda/scl falling time.

This is just so you can put specific clock count instead of converting 
from nanoseconds with standard properties or you gain some additional 
control of the timing. If only the former, then I prefer we stick with 
the common properties.

> From another side, the dw_i2c_acpi_configure() on ACPI platform also
> get hcnt/lcnt values rather than the sda/scl falling time from ACPI
> method, we want similar feature for DT platforms.

That's nice, but not really a reason IMO.

> 
> Signed-off-by: Jisheng Zhang 
> ---
>  Documentation/devicetree/bindings/i2c/i2c-designware.txt | 16 
> 
>  drivers/i2c/busses/i2c-designware-platdrv.c  |  8 
>  2 files changed, 24 insertions(+)

[PATCH 3/9] net: mediatek: mtk_cal_txd_req() returns bad value

[John Crispin]

The code used to also support the PDMA engine, which had 2 packet pointers
per descriptor. Because of this we had to divide the result by 2 and round
it up. This is no longer needed as the code only supports QDMA.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index bb10d57..94cceb8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -681,7 +681,7 @@ static inline int mtk_cal_txd_req(struct sk_buff *skb)
nfrags += skb_shinfo(skb)->nr_frags;
}
 
-   return DIV_ROUND_UP(nfrags, 2);
+   return nfrags;
 }
 
 static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
-- 
1.7.10.4

Re: [PATCH] livepatch: robustify klp_register_patch() API error checking

[Josh Poimboeuf]

On Thu, Apr 07, 2016 at 06:06:25PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina 
> 
> Commit 425595a7fc20 ("livepatch: reuse module loader code to write 
> relocations") adds a possibility of dereferncing pointers supplied by the 
> consumer of the livepatch API before sanity (NULL) checking them (patch 
> and patch->mod).
> 
> Spotted by smatch tool.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jiri Kosina 

Acked-by: Josh Poimboeuf 


-- 
Josh

Re: [PATCH] livepatch: robustify klp_register_patch() API error checking

[Josh Poimboeuf]

On Thu, Apr 07, 2016 at 06:06:25PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina 
> 
> Commit 425595a7fc20 ("livepatch: reuse module loader code to write 
> relocations") adds a possibility of dereferncing pointers supplied by the 
> consumer of the livepatch API before sanity (NULL) checking them (patch 
> and patch->mod).
> 
> Spotted by smatch tool.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jiri Kosina 

Acked-by: Josh Poimboeuf 


-- 
Josh

[PATCH 1/9] net: mediatek: update the IRQ part of the binding document

[John Crispin]

The current binding document only describes a single interrupt. Update the
document by adding the 2 other interrupts.

The driver currently only uses a single interrupt. The HW is however able
to using IRQ grouping to split TX and RX onto separate GIC irqs.

Signed-off-by: John Crispin 
Cc: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/net/mediatek-net.txt |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 5ca7929..2f142be 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -9,7 +9,7 @@ have dual GMAC each represented by a child node..
 Required properties:
 - compatible: Should be "mediatek,mt7623-eth"
 - reg: Address and length of the register set for the device
-- interrupts: Should contain the frame engines interrupt
+- interrupts: Should contain the three frame engines interrupts
 - clocks: the clock used by the core
 - clock-names: the names of the clock listed in the clocks property. These are
"ethif", "esw", "gp2", "gp1"
@@ -42,7 +42,9 @@ eth: ethernet@1b10 {
 < CLK_ETHSYS_GP2>,
 < CLK_ETHSYS_GP1>;
clock-names = "ethif", "esw", "gp2", "gp1";
-   interrupts = ;
+   interrupts = ;
power-domains = < MT2701_POWER_DOMAIN_ETH>;
resets = < MT2701_ETHSYS_ETH_RST>;
reset-names = "eth";
-- 
1.7.10.4

[PATCH 1/9] net: mediatek: update the IRQ part of the binding document

[John Crispin]

The current binding document only describes a single interrupt. Update the
document by adding the 2 other interrupts.

The driver currently only uses a single interrupt. The HW is however able
to using IRQ grouping to split TX and RX onto separate GIC irqs.

Signed-off-by: John Crispin 
Cc: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/net/mediatek-net.txt |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 5ca7929..2f142be 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -9,7 +9,7 @@ have dual GMAC each represented by a child node..
 Required properties:
 - compatible: Should be "mediatek,mt7623-eth"
 - reg: Address and length of the register set for the device
-- interrupts: Should contain the frame engines interrupt
+- interrupts: Should contain the three frame engines interrupts
 - clocks: the clock used by the core
 - clock-names: the names of the clock listed in the clocks property. These are
"ethif", "esw", "gp2", "gp1"
@@ -42,7 +42,9 @@ eth: ethernet@1b10 {
 < CLK_ETHSYS_GP2>,
 < CLK_ETHSYS_GP1>;
clock-names = "ethif", "esw", "gp2", "gp1";
-   interrupts = ;
+   interrupts = ;
power-domains = < MT2701_POWER_DOMAIN_ETH>;
resets = < MT2701_ETHSYS_ETH_RST>;
reset-names = "eth";
-- 
1.7.10.4

Re: [PATCH] ASoC: rockchip: i2s: configure the sdio pins' iomux mode

[Rob Herring]

On Wed, Apr 06, 2016 at 04:38:22PM +0800, Sugar Zhang wrote:
> There are 3 i2s sdio pins, which iomux mode is as follows:

s/i2s sdio/I2S\/SDIO muxed/

> 
>  - sdi3_sdo1
>  - sdi2_sdo2
>  - sdi1_sdo3
> 
> we need to configure these pins' iomux mode via the GRF register
> when use multi channel playback/capture.

Why not a pinctrl binding here? If you want SDIO mode, then you need 
similar code in the SDIO driver (or just rely on default mode).

> 
> Signed-off-by: Sugar Zhang 
> ---
> 
>  .../devicetree/bindings/sound/rockchip-i2s.txt |  5 +++
>  sound/soc/rockchip/rockchip_i2s.c  | 39 
> +-
>  sound/soc/rockchip/rockchip_i2s.h  |  8 +
>  3 files changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt 
> b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
> index 6e86d8a..ad72a7d 100644
> --- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
> @@ -23,6 +23,11 @@ Required properties:
>  - rockchip,playback-channels: max playback channels, if not set, 8 channels 
> default.
>  - rockchip,capture-channels: max capture channels, if not set, 2 channels 
> default.
>  
> +Required properties for controller which support multi channels 
> playback/capture:
> +
> +- rockchip,grf: Should be phandle/offset pair. the phandle of the syscon 
> node for GRF register,

Wrap your lines at less than 80 chars.

> +  and the offset of the GRF for control register.
> +
>  Example for rk3288 I2S controller:
>  
>  i2s@ff89 {

[PATCH 9/9] net: mediatek: do not set the QID field in the TX DMA descriptors

[John Crispin]

The QID field gets set to the mac id. This made the DMA linked list queue
the traffic of each MAC on a different internal queue. However during long
term testing we found that this will cause traffic stalls as the multi
queue setup requires a more complete initialisation which is not part of
the upstream driver yet.

This patch removes the code setting the QID field, resulting in all
traffic ending up in queue 0 which works without any special setup.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index f9f8851..8163047 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -603,8 +603,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
WRITE_ONCE(txd->txd1, mapped_addr);
WRITE_ONCE(txd->txd3, (TX_DMA_SWC |
   TX_DMA_PLEN0(frag_map_size) |
-  last_frag * TX_DMA_LS0) |
-  mac->id);
+  last_frag * TX_DMA_LS0));
WRITE_ONCE(txd->txd4, 0);
 
tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
-- 
1.7.10.4

[PATCH 6/9] net: mediatek: fix mtk_pending_work

[John Crispin]

The driver supports 2 MACs. Both run on the same DMA ring. If we hit a TX
timeout we need to stop both netdevs before restarting them again. If we
don't do this, mtk_stop() wont shutdown DMA and the consecutive call to
mtk_open() wont restart DMA and enable IRQs.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   31 ++-
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 4ebc42e..60b66ab 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1430,19 +1430,30 @@ static int mtk_do_ioctl(struct net_device *dev, struct 
ifreq *ifr, int cmd)
 
 static void mtk_pending_work(struct work_struct *work)
 {
-   struct mtk_mac *mac = container_of(work, struct mtk_mac, pending_work);
-   struct mtk_eth *eth = mac->hw;
-   struct net_device *dev = eth->netdev[mac->id];
-   int err;
+   struct mtk_eth *eth = container_of(work, struct mtk_eth, pending_work);
+   int err, i;
+   unsigned long restart = 0;
 
rtnl_lock();
-   mtk_stop(dev);
 
-   err = mtk_open(dev);
-   if (err) {
-   netif_alert(eth, ifup, dev,
-   "Driver up/down cycle failed, closing device.\n");
-   dev_close(dev);
+   /* stop all devices to make sure that dma is properly shut down */
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!netif_oper_up(eth->netdev[i]))
+   continue;
+   mtk_stop(eth->netdev[i]);
+   __set_bit(i, );
+   }
+
+   /* restart DMA and enable IRQs */
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!test_bit(i, ))
+   continue;
+   err = mtk_open(eth->netdev[i]);
+   if (err) {
+   netif_alert(eth, ifup, eth->netdev[i],
+ "Driver up/down cycle failed, closing device.\n");
+   dev_close(eth->netdev[i]);
+   }
}
rtnl_unlock();
 }
-- 
1.7.10.4

[PATCH 5/9] net: mediatek: fix stop and wakeup of queue

[John Crispin]

The driver supports 2 MACs. Both run on the same DMA ring. If we go
above/below the TX rings threshold value, we always need to wake/stop
the queue of both devices. Not doing to can cause TX stalls and packet
drops on one of the devices.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   37 +++
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index a4982e4..4ebc42e 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -684,6 +684,28 @@ static inline int mtk_cal_txd_req(struct sk_buff *skb)
return nfrags;
 }
 
+static void mtk_wake_queue(struct mtk_eth *eth)
+{
+   int i;
+
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!eth->netdev[i])
+   continue;
+   netif_wake_queue(eth->netdev[i]);
+   }
+}
+
+static void mtk_stop_queue(struct mtk_eth *eth)
+{
+   int i;
+
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!eth->netdev[i])
+   continue;
+   netif_stop_queue(eth->netdev[i]);
+   }
+}
+
 static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
struct mtk_mac *mac = netdev_priv(dev);
@@ -695,7 +717,7 @@ static int mtk_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
 
tx_num = mtk_cal_txd_req(skb);
if (unlikely(atomic_read(>free_count) <= tx_num)) {
-   netif_stop_queue(dev);
+   mtk_stop_queue(eth);
netif_err(eth, tx_queued, dev,
  "Tx Ring full when queue awake!\n");
return NETDEV_TX_BUSY;
@@ -720,10 +742,10 @@ static int mtk_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
goto drop;
 
if (unlikely(atomic_read(>free_count) <= ring->thresh)) {
-   netif_stop_queue(dev);
+   mtk_stop_queue(eth);
if (unlikely(atomic_read(>free_count) >
 ring->thresh))
-   netif_wake_queue(dev);
+   mtk_wake_queue(eth);
}
 
return NETDEV_TX_OK;
@@ -897,13 +919,8 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
if (!total)
return 0;
 
-   for (i = 0; i < MTK_MAC_COUNT; i++) {
-   if (!eth->netdev[i] ||
-   unlikely(!netif_queue_stopped(eth->netdev[i])))
-   continue;
-   if (atomic_read(>free_count) > ring->thresh)
-   netif_wake_queue(eth->netdev[i]);
-   }
+   if (atomic_read(>free_count) > ring->thresh)
+   mtk_wake_queue(eth);
 
return total;
 }
-- 
1.7.10.4

Re: [PATCH] ASoC: rockchip: i2s: configure the sdio pins' iomux mode

[Rob Herring]

On Wed, Apr 06, 2016 at 04:38:22PM +0800, Sugar Zhang wrote:
> There are 3 i2s sdio pins, which iomux mode is as follows:

s/i2s sdio/I2S\/SDIO muxed/

> 
>  - sdi3_sdo1
>  - sdi2_sdo2
>  - sdi1_sdo3
> 
> we need to configure these pins' iomux mode via the GRF register
> when use multi channel playback/capture.

Why not a pinctrl binding here? If you want SDIO mode, then you need 
similar code in the SDIO driver (or just rely on default mode).

> 
> Signed-off-by: Sugar Zhang 
> ---
> 
>  .../devicetree/bindings/sound/rockchip-i2s.txt |  5 +++
>  sound/soc/rockchip/rockchip_i2s.c  | 39 
> +-
>  sound/soc/rockchip/rockchip_i2s.h  |  8 +
>  3 files changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt 
> b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
> index 6e86d8a..ad72a7d 100644
> --- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
> @@ -23,6 +23,11 @@ Required properties:
>  - rockchip,playback-channels: max playback channels, if not set, 8 channels 
> default.
>  - rockchip,capture-channels: max capture channels, if not set, 2 channels 
> default.
>  
> +Required properties for controller which support multi channels 
> playback/capture:
> +
> +- rockchip,grf: Should be phandle/offset pair. the phandle of the syscon 
> node for GRF register,

Wrap your lines at less than 80 chars.

> +  and the offset of the GRF for control register.
> +
>  Example for rk3288 I2S controller:
>  
>  i2s@ff89 {

[PATCH 9/9] net: mediatek: do not set the QID field in the TX DMA descriptors

[John Crispin]

The QID field gets set to the mac id. This made the DMA linked list queue
the traffic of each MAC on a different internal queue. However during long
term testing we found that this will cause traffic stalls as the multi
queue setup requires a more complete initialisation which is not part of
the upstream driver yet.

This patch removes the code setting the QID field, resulting in all
traffic ending up in queue 0 which works without any special setup.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index f9f8851..8163047 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -603,8 +603,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
WRITE_ONCE(txd->txd1, mapped_addr);
WRITE_ONCE(txd->txd3, (TX_DMA_SWC |
   TX_DMA_PLEN0(frag_map_size) |
-  last_frag * TX_DMA_LS0) |
-  mac->id);
+  last_frag * TX_DMA_LS0));
WRITE_ONCE(txd->txd4, 0);
 
tx_buf->skb = (struct sk_buff *)MTK_DMA_DUMMY_DESC;
-- 
1.7.10.4

[PATCH 6/9] net: mediatek: fix mtk_pending_work

[John Crispin]

The driver supports 2 MACs. Both run on the same DMA ring. If we hit a TX
timeout we need to stop both netdevs before restarting them again. If we
don't do this, mtk_stop() wont shutdown DMA and the consecutive call to
mtk_open() wont restart DMA and enable IRQs.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   31 ++-
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 4ebc42e..60b66ab 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1430,19 +1430,30 @@ static int mtk_do_ioctl(struct net_device *dev, struct 
ifreq *ifr, int cmd)
 
 static void mtk_pending_work(struct work_struct *work)
 {
-   struct mtk_mac *mac = container_of(work, struct mtk_mac, pending_work);
-   struct mtk_eth *eth = mac->hw;
-   struct net_device *dev = eth->netdev[mac->id];
-   int err;
+   struct mtk_eth *eth = container_of(work, struct mtk_eth, pending_work);
+   int err, i;
+   unsigned long restart = 0;
 
rtnl_lock();
-   mtk_stop(dev);
 
-   err = mtk_open(dev);
-   if (err) {
-   netif_alert(eth, ifup, dev,
-   "Driver up/down cycle failed, closing device.\n");
-   dev_close(dev);
+   /* stop all devices to make sure that dma is properly shut down */
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!netif_oper_up(eth->netdev[i]))
+   continue;
+   mtk_stop(eth->netdev[i]);
+   __set_bit(i, );
+   }
+
+   /* restart DMA and enable IRQs */
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!test_bit(i, ))
+   continue;
+   err = mtk_open(eth->netdev[i]);
+   if (err) {
+   netif_alert(eth, ifup, eth->netdev[i],
+ "Driver up/down cycle failed, closing device.\n");
+   dev_close(eth->netdev[i]);
+   }
}
rtnl_unlock();
 }
-- 
1.7.10.4

[PATCH 5/9] net: mediatek: fix stop and wakeup of queue

[John Crispin]

The driver supports 2 MACs. Both run on the same DMA ring. If we go
above/below the TX rings threshold value, we always need to wake/stop
the queue of both devices. Not doing to can cause TX stalls and packet
drops on one of the devices.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   37 +++
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index a4982e4..4ebc42e 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -684,6 +684,28 @@ static inline int mtk_cal_txd_req(struct sk_buff *skb)
return nfrags;
 }
 
+static void mtk_wake_queue(struct mtk_eth *eth)
+{
+   int i;
+
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!eth->netdev[i])
+   continue;
+   netif_wake_queue(eth->netdev[i]);
+   }
+}
+
+static void mtk_stop_queue(struct mtk_eth *eth)
+{
+   int i;
+
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!eth->netdev[i])
+   continue;
+   netif_stop_queue(eth->netdev[i]);
+   }
+}
+
 static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
struct mtk_mac *mac = netdev_priv(dev);
@@ -695,7 +717,7 @@ static int mtk_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
 
tx_num = mtk_cal_txd_req(skb);
if (unlikely(atomic_read(>free_count) <= tx_num)) {
-   netif_stop_queue(dev);
+   mtk_stop_queue(eth);
netif_err(eth, tx_queued, dev,
  "Tx Ring full when queue awake!\n");
return NETDEV_TX_BUSY;
@@ -720,10 +742,10 @@ static int mtk_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
goto drop;
 
if (unlikely(atomic_read(>free_count) <= ring->thresh)) {
-   netif_stop_queue(dev);
+   mtk_stop_queue(eth);
if (unlikely(atomic_read(>free_count) >
 ring->thresh))
-   netif_wake_queue(dev);
+   mtk_wake_queue(eth);
}
 
return NETDEV_TX_OK;
@@ -897,13 +919,8 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
if (!total)
return 0;
 
-   for (i = 0; i < MTK_MAC_COUNT; i++) {
-   if (!eth->netdev[i] ||
-   unlikely(!netif_queue_stopped(eth->netdev[i])))
-   continue;
-   if (atomic_read(>free_count) > ring->thresh)
-   netif_wake_queue(eth->netdev[i]);
-   }
+   if (atomic_read(>free_count) > ring->thresh)
+   mtk_wake_queue(eth);
 
return total;
 }
-- 
1.7.10.4

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

[Andy Shevchenko]

On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim  wrote:
> Remove unneeded blank lines appearing after opening braces as suggested
> by checkpatch.pl
>

You have to combine this with the rest so called 'indentation' fixes,
e.g. +- empty lines, tabs vs. spaces, etc.

P.S. By the way. are they first patches you are trying to push to kernel?

> Signed-off-by: Nicholas Sim 
> ---
>  drivers/staging/rtl8192u/r8192U_core.c | 14 --
>  1 file changed, 14 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 2f506b8..21d5693 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -323,7 +323,6 @@ void write_nic_byte(struct net_device *dev, int indx, u8 
> data)
>
>  void write_nic_word(struct net_device *dev, int indx, u16 data)
>  {
> -
> int status;
>
> struct r8192_priv *priv = (struct r8192_priv *)ieee80211_priv(dev);
> @@ -347,7 +346,6 @@ void write_nic_word(struct net_device *dev, int indx, u16 
> data)
>
>  void write_nic_dword(struct net_device *dev, int indx, u32 data)
>  {
> -
> int status;
>
> struct r8192_priv *priv = (struct r8192_priv *)ieee80211_priv(dev);
> @@ -733,7 +731,6 @@ void rtl8192_update_msr(struct net_device *dev)
>  * master (see the create BSS/IBSS func)
>  */
> if (priv->ieee80211->state == IEEE80211_LINKED) {
> -
> if (priv->ieee80211->iw_mode == IW_MODE_INFRA)
> msr |= (MSR_LINK_MANAGED << MSR_LINK_SHIFT);
> else if (priv->ieee80211->iw_mode == IW_MODE_ADHOC)
> @@ -768,7 +765,6 @@ static void rtl8192_rx_isr(struct urb *urb);
>
>  static u32 get_rxpacket_shiftbytes_819xusb(struct ieee80211_rx_stats *pstats)
>  {
> -
> return (sizeof(rx_desc_819x_usb) + pstats->RxDrvInfoSize
> + pstats->RxBufShift);
>  }
> @@ -1267,7 +1263,6 @@ static void rtl8192_update_cap(struct net_device *dev, 
> u16 cap)
>  }
>  static void rtl8192_net_update(struct net_device *dev)
>  {
> -
> struct r8192_priv *priv = ieee80211_priv(dev);
> struct ieee80211_network *net;
> u16 BcnTimeCfg = 0, BcnCW = 6, BcnIFS = 0xf;
> @@ -1725,7 +1720,6 @@ static short rtl8192_usb_initendpoints(struct 
> net_device *dev)
>
>  #ifndef JACKSON_NEW_RX
> for (i = 0; i < (MAX_RX_URB + 1); i++) {
> -
> priv->rx_urb[i] = usb_alloc_urb(0, GFP_KERNEL);
>
> priv->rx_urb[i]->transfer_buffer =
> @@ -2658,7 +2652,6 @@ static short rtl8192_get_channel_map(struct net_device 
> *dev)
>
>  static short rtl8192_init(struct net_device *dev)
>  {
> -
> struct r8192_priv *priv = ieee80211_priv(dev);
>
> memset(&(priv->stats), 0, sizeof(struct Stats));
> @@ -3007,7 +3000,6 @@ static bool rtl8192_adapter_start(struct net_device 
> *dev)
>  bMaskByte2);
>
> for (i = 0; i < CCKTxBBGainTableLength; i++) {
> -
> if (TempCCk == 
> priv->cck_txbbgain_table[i].ccktxbb_valuearray[0]) {
> 
> priv->cck_present_attentuation_20Mdefault = (u8)i;
> break;
> @@ -3228,7 +3220,6 @@ static void CamRestoreAllEntry(struct net_device *dev)
>
> if ((priv->ieee80211->pairwise_key_type == KEY_TYPE_WEP40) ||
> (priv->ieee80211->pairwise_key_type == KEY_TYPE_WEP104)) {
> -
> for (EntryId = 0; EntryId < 4; EntryId++) {
> MacAddr = CAM_CONST_ADDR[EntryId];
> setKey(dev, EntryId, EntryId,
> @@ -3237,7 +3228,6 @@ static void CamRestoreAllEntry(struct net_device *dev)
> }
>
> } else if (priv->ieee80211->pairwise_key_type == KEY_TYPE_TKIP) {
> -
> if (priv->ieee80211->iw_mode == IW_MODE_ADHOC)
> setKey(dev, 4, 0, priv->ieee80211->pairwise_key_type,
>(u8 *)dev->dev_addr, 0, NULL);
> @@ -3245,7 +3235,6 @@ static void CamRestoreAllEntry(struct net_device *dev)
> setKey(dev, 4, 0, priv->ieee80211->pairwise_key_type,
>MacAddr, 0, NULL);
> } else if (priv->ieee80211->pairwise_key_type == KEY_TYPE_CCMP) {
> -
> if (priv->ieee80211->iw_mode == IW_MODE_ADHOC)
> setKey(dev, 4, 0, priv->ieee80211->pairwise_key_type,
>(u8 *)dev->dev_addr, 0, NULL);
> @@ -3446,7 +3435,6 @@ static void rtl819x_watchdog_wqcallback(struct 
> work_struct *work)
> /* for AP roaming */
> if (priv->ieee80211->state == IEEE80211_LINKED &&
> priv->ieee80211->iw_mode == IW_MODE_INFRA) {
> -
> rtl819x_update_rxcounts(priv, , 
> );
> if ((TotalRxBcnNum + TotalRxDataNum) == 0) {
>  

[PATCH 8/9] net: mediatek: move the pending_work struct to the device generic struct

[John Crispin]

The worker always touches both netdevs. It is ethernet core and not MAC
specific. We only need one worker, which belongs into the ethernets core
struct.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   10 --
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |4 ++--
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8434355..f9f8851 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1193,7 +1193,7 @@ static void mtk_tx_timeout(struct net_device *dev)
eth->netdev[mac->id]->stats.tx_errors++;
netif_err(eth, tx_err, dev,
  "transmit timed out\n");
-   schedule_work(>pending_work);
+   schedule_work(>pending_work);
 }
 
 static irqreturn_t mtk_handle_irq(int irq, void *_eth)
@@ -1438,7 +1438,7 @@ static void mtk_pending_work(struct work_struct *work)
 
/* stop all devices to make sure that dma is properly shut down */
for (i = 0; i < MTK_MAC_COUNT; i++) {
-   if (!netif_oper_up(eth->netdev[i]))
+   if (!eth->netdev[i])
continue;
mtk_stop(eth->netdev[i]);
__set_bit(i, );
@@ -1463,15 +1463,13 @@ static int mtk_cleanup(struct mtk_eth *eth)
int i;
 
for (i = 0; i < MTK_MAC_COUNT; i++) {
-   struct mtk_mac *mac = netdev_priv(eth->netdev[i]);
-
if (!eth->netdev[i])
continue;
 
unregister_netdev(eth->netdev[i]);
free_netdev(eth->netdev[i]);
-   cancel_work_sync(>pending_work);
}
+   cancel_work_sync(>pending_work);
 
return 0;
 }
@@ -1659,7 +1657,6 @@ static int mtk_add_mac(struct mtk_eth *eth, struct 
device_node *np)
mac->id = id;
mac->hw = eth;
mac->of_node = np;
-   INIT_WORK(>pending_work, mtk_pending_work);
 
mac->hw_stats = devm_kzalloc(eth->dev,
 sizeof(*mac->hw_stats),
@@ -1761,6 +1758,7 @@ static int mtk_probe(struct platform_device *pdev)
 
eth->dev = >dev;
eth->msg_enable = netif_msg_init(mtk_msg_level, MTK_DEFAULT_MSG_ENABLE);
+   INIT_WORK(>pending_work, mtk_pending_work);
 
err = mtk_hw_init(eth);
if (err)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 48a5292..eed626d 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -363,6 +363,7 @@ struct mtk_rx_ring {
  * @clk_gp1:   The gmac1 clock
  * @clk_gp2:   The gmac2 clock
  * @mii_bus:   If there is a bus we need to create an instance for it
+ * @pending_work:  The workqueue used to reset the dma ring
  */
 
 struct mtk_eth {
@@ -389,6 +390,7 @@ struct mtk_eth {
struct clk  *clk_gp1;
struct clk  *clk_gp2;
struct mii_bus  *mii_bus;
+   struct work_struct  pending_work;
 };
 
 /* struct mtk_mac -the structure that holds the info about the MACs of the
@@ -398,7 +400,6 @@ struct mtk_eth {
  * @hw:Backpointer to our main datastruture
  * @hw_stats:  Packet statistics counter
  * @phy_dev:   The attached PHY if available
- * @pending_work:  The workqueue used to reset the dma ring
  */
 struct mtk_mac {
int id;
@@ -406,7 +407,6 @@ struct mtk_mac {
struct mtk_eth  *hw;
struct mtk_hw_stats *hw_stats;
struct phy_device   *phy_dev;
-   struct work_struct  pending_work;
 };
 
 /* the struct describing the SoC. these are declared in the soc_xyz.c files */
-- 
1.7.10.4

Re: [PATCH 1/2] thermal: generic-adc: Add DT binding for ADC based thermal sensor driver

[Rob Herring]

On Wed, Apr 06, 2016 at 03:33:05PM +0530, Laxman Dewangan wrote:
> Sometimes, thermal sensors like NCT thermistors are connected to
> the ADC channel. The temperature is read by reading the voltage
> across the sensor resistance via ADC and referring the lookup
> table for ADC value to temperature. The ADC interface is provided
> through the IIO framework.

IIO framework is a detail not relevant to the binding.

> 
> Add DT binding doc for the adc based thermal sensor driver to detail
> the DT property and provide the example for how to use it.
> 
> Signed-off-by: Laxman Dewangan 
> ---
>  .../bindings/thermal/thermal-generic-adc.txt   | 86 
> ++
>  1 file changed, 86 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt 
> b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt
> new file mode 100644
> index 000..6b3e715
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt
> @@ -0,0 +1,86 @@
> +General Purpose Analog To Digital Converter (ADC) based thermal sensor
> +
> +On some of platforms, thermal sensor like thermistors are connected to
> +one of ADC channel and sensor resistance is read via voltage across the
> +sensor. The voltage read across the sensor is mapped to temperature using
> +voltage-temperature lookup table.
> +
> +This driver provides the interface to sensor-ADC interconnection and
> +the relation ship between ADC read value and temperature.

Bindings don't describe drivers.

> +
> +Required properties:
> +===
> +- compatible: Must be "generic-adc-thermal".
> +- lower-temperature:  Lower temperature for the lookup table
> +  in millicelsius.
> +- upper-temperature:  Upper temperature for the lookup table
> +  in millicelsius.
> +- step-temperature:   The temperature steps for the reading ADC
> +  value in millicelsius.
> +- temperature-lookup-table:  The ADC reading value on each step of the
> +  temperature starting from lower temperature
> +  to upper temperature.
> +  When ADC is read, the value is looked up on the
> +  table to get the equivalent temperature.
> +- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description
> +  of this property. 
> +
> +Example :
> +#include 
> +
> +i2c@7000c400 {
> + ads1015: ads1015@4a {
> + reg = <0x4a>;
> + compatible = "ads1015";
> + sampling-frequency = <3300>;
> + #io-channel-cells = <1>; 
> + };
> +};
> +
> +thermal-sensor@1 {
> + compatible = "generic-adc-thermal";
> + #thermal-sensor-cells = <0>;
> + io-channels = < 1>; 
> + io-channel-names = "sensor-channel";
> + lower-temperature = <(-4)>;
> + upper-temperature = <125000>;
> + step-temperature = <1000>;
> + temperature-lookup-table = <2578 2577 2576 2575 2574
> + 2573 2572 2571 2569 2568
> + 2567 2565 2563 2561 2559
> + ::
> + 254 247 240 233 226 220 
> + 214 208>;
> +};
> +
> +dummy_cool_dev: dummy-cool-dev {
> + compatible = "dummy-cooling-dev";
> + #cooling-cells = <2>; /* min followed by max */
> +};
> +
> +thermal-zones {
> + Tboard {
> + polling-delay = <15000>; /* milliseconds */
> + polling-delay-passive = <0>; /* milliseconds */
> + thermal-sensors = <_thermistor>;

Missing a label?

> +
> + trips {
> + therm_est_trip: therm_est_trip {
> + temperature = <4>;
> + type = "active";
> + hysteresis = <1000>;
> + writable;

Missing indentation and closing brace.

> + };
> + };
> +
> + cooling-maps {
> + map0 {
> + trip = <_est_trip>;
> + cooling-device = <_cool_dev THERMAL_NO_LIMIT 
> THERMAL_NO_LIMIT>;
> + contribution = <100>;
> + cdev-type = "therm_est_activ";
> + };

Here's your missing brace... 

> + };
> +
> + };
> +};
> -- 
> 2.1.4
> 

[PATCH 4/9] net: mediatek: remove superfluous reset call

[John Crispin]

HW reset is triggered in the mtk_hw_init() function. There is no need to
also reset the core during probe.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 94cceb8..a4982e4 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1679,10 +1679,6 @@ static int mtk_probe(struct platform_device *pdev)
struct mtk_eth *eth;
int err;
 
-   err = device_reset(>dev);
-   if (err)
-   return err;
-
match = of_match_device(of_mtk_match, >dev);
soc = (struct mtk_soc_data *)match->data;
 
-- 
1.7.10.4

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

[Andy Shevchenko]

On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim  wrote:
> Remove unneeded blank lines appearing after opening braces as suggested
> by checkpatch.pl
>

You have to combine this with the rest so called 'indentation' fixes,
e.g. +- empty lines, tabs vs. spaces, etc.

P.S. By the way. are they first patches you are trying to push to kernel?

> Signed-off-by: Nicholas Sim 
> ---
>  drivers/staging/rtl8192u/r8192U_core.c | 14 --
>  1 file changed, 14 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 2f506b8..21d5693 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -323,7 +323,6 @@ void write_nic_byte(struct net_device *dev, int indx, u8 
> data)
>
>  void write_nic_word(struct net_device *dev, int indx, u16 data)
>  {
> -
> int status;
>
> struct r8192_priv *priv = (struct r8192_priv *)ieee80211_priv(dev);
> @@ -347,7 +346,6 @@ void write_nic_word(struct net_device *dev, int indx, u16 
> data)
>
>  void write_nic_dword(struct net_device *dev, int indx, u32 data)
>  {
> -
> int status;
>
> struct r8192_priv *priv = (struct r8192_priv *)ieee80211_priv(dev);
> @@ -733,7 +731,6 @@ void rtl8192_update_msr(struct net_device *dev)
>  * master (see the create BSS/IBSS func)
>  */
> if (priv->ieee80211->state == IEEE80211_LINKED) {
> -
> if (priv->ieee80211->iw_mode == IW_MODE_INFRA)
> msr |= (MSR_LINK_MANAGED << MSR_LINK_SHIFT);
> else if (priv->ieee80211->iw_mode == IW_MODE_ADHOC)
> @@ -768,7 +765,6 @@ static void rtl8192_rx_isr(struct urb *urb);
>
>  static u32 get_rxpacket_shiftbytes_819xusb(struct ieee80211_rx_stats *pstats)
>  {
> -
> return (sizeof(rx_desc_819x_usb) + pstats->RxDrvInfoSize
> + pstats->RxBufShift);
>  }
> @@ -1267,7 +1263,6 @@ static void rtl8192_update_cap(struct net_device *dev, 
> u16 cap)
>  }
>  static void rtl8192_net_update(struct net_device *dev)
>  {
> -
> struct r8192_priv *priv = ieee80211_priv(dev);
> struct ieee80211_network *net;
> u16 BcnTimeCfg = 0, BcnCW = 6, BcnIFS = 0xf;
> @@ -1725,7 +1720,6 @@ static short rtl8192_usb_initendpoints(struct 
> net_device *dev)
>
>  #ifndef JACKSON_NEW_RX
> for (i = 0; i < (MAX_RX_URB + 1); i++) {
> -
> priv->rx_urb[i] = usb_alloc_urb(0, GFP_KERNEL);
>
> priv->rx_urb[i]->transfer_buffer =
> @@ -2658,7 +2652,6 @@ static short rtl8192_get_channel_map(struct net_device 
> *dev)
>
>  static short rtl8192_init(struct net_device *dev)
>  {
> -
> struct r8192_priv *priv = ieee80211_priv(dev);
>
> memset(&(priv->stats), 0, sizeof(struct Stats));
> @@ -3007,7 +3000,6 @@ static bool rtl8192_adapter_start(struct net_device 
> *dev)
>  bMaskByte2);
>
> for (i = 0; i < CCKTxBBGainTableLength; i++) {
> -
> if (TempCCk == 
> priv->cck_txbbgain_table[i].ccktxbb_valuearray[0]) {
> 
> priv->cck_present_attentuation_20Mdefault = (u8)i;
> break;
> @@ -3228,7 +3220,6 @@ static void CamRestoreAllEntry(struct net_device *dev)
>
> if ((priv->ieee80211->pairwise_key_type == KEY_TYPE_WEP40) ||
> (priv->ieee80211->pairwise_key_type == KEY_TYPE_WEP104)) {
> -
> for (EntryId = 0; EntryId < 4; EntryId++) {
> MacAddr = CAM_CONST_ADDR[EntryId];
> setKey(dev, EntryId, EntryId,
> @@ -3237,7 +3228,6 @@ static void CamRestoreAllEntry(struct net_device *dev)
> }
>
> } else if (priv->ieee80211->pairwise_key_type == KEY_TYPE_TKIP) {
> -
> if (priv->ieee80211->iw_mode == IW_MODE_ADHOC)
> setKey(dev, 4, 0, priv->ieee80211->pairwise_key_type,
>(u8 *)dev->dev_addr, 0, NULL);
> @@ -3245,7 +3235,6 @@ static void CamRestoreAllEntry(struct net_device *dev)
> setKey(dev, 4, 0, priv->ieee80211->pairwise_key_type,
>MacAddr, 0, NULL);
> } else if (priv->ieee80211->pairwise_key_type == KEY_TYPE_CCMP) {
> -
> if (priv->ieee80211->iw_mode == IW_MODE_ADHOC)
> setKey(dev, 4, 0, priv->ieee80211->pairwise_key_type,
>(u8 *)dev->dev_addr, 0, NULL);
> @@ -3446,7 +3435,6 @@ static void rtl819x_watchdog_wqcallback(struct 
> work_struct *work)
> /* for AP roaming */
> if (priv->ieee80211->state == IEEE80211_LINKED &&
> priv->ieee80211->iw_mode == IW_MODE_INFRA) {
> -
> rtl819x_update_rxcounts(priv, , 
> );
> if ((TotalRxBcnNum + TotalRxDataNum) == 0) {
>  #ifdef TODO
> @@ -4865,7 +4853,6 @@ static void 

[PATCH 8/9] net: mediatek: move the pending_work struct to the device generic struct

[John Crispin]

The worker always touches both netdevs. It is ethernet core and not MAC
specific. We only need one worker, which belongs into the ethernets core
struct.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   10 --
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |4 ++--
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8434355..f9f8851 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1193,7 +1193,7 @@ static void mtk_tx_timeout(struct net_device *dev)
eth->netdev[mac->id]->stats.tx_errors++;
netif_err(eth, tx_err, dev,
  "transmit timed out\n");
-   schedule_work(>pending_work);
+   schedule_work(>pending_work);
 }
 
 static irqreturn_t mtk_handle_irq(int irq, void *_eth)
@@ -1438,7 +1438,7 @@ static void mtk_pending_work(struct work_struct *work)
 
/* stop all devices to make sure that dma is properly shut down */
for (i = 0; i < MTK_MAC_COUNT; i++) {
-   if (!netif_oper_up(eth->netdev[i]))
+   if (!eth->netdev[i])
continue;
mtk_stop(eth->netdev[i]);
__set_bit(i, );
@@ -1463,15 +1463,13 @@ static int mtk_cleanup(struct mtk_eth *eth)
int i;
 
for (i = 0; i < MTK_MAC_COUNT; i++) {
-   struct mtk_mac *mac = netdev_priv(eth->netdev[i]);
-
if (!eth->netdev[i])
continue;
 
unregister_netdev(eth->netdev[i]);
free_netdev(eth->netdev[i]);
-   cancel_work_sync(>pending_work);
}
+   cancel_work_sync(>pending_work);
 
return 0;
 }
@@ -1659,7 +1657,6 @@ static int mtk_add_mac(struct mtk_eth *eth, struct 
device_node *np)
mac->id = id;
mac->hw = eth;
mac->of_node = np;
-   INIT_WORK(>pending_work, mtk_pending_work);
 
mac->hw_stats = devm_kzalloc(eth->dev,
 sizeof(*mac->hw_stats),
@@ -1761,6 +1758,7 @@ static int mtk_probe(struct platform_device *pdev)
 
eth->dev = >dev;
eth->msg_enable = netif_msg_init(mtk_msg_level, MTK_DEFAULT_MSG_ENABLE);
+   INIT_WORK(>pending_work, mtk_pending_work);
 
err = mtk_hw_init(eth);
if (err)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 48a5292..eed626d 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -363,6 +363,7 @@ struct mtk_rx_ring {
  * @clk_gp1:   The gmac1 clock
  * @clk_gp2:   The gmac2 clock
  * @mii_bus:   If there is a bus we need to create an instance for it
+ * @pending_work:  The workqueue used to reset the dma ring
  */
 
 struct mtk_eth {
@@ -389,6 +390,7 @@ struct mtk_eth {
struct clk  *clk_gp1;
struct clk  *clk_gp2;
struct mii_bus  *mii_bus;
+   struct work_struct  pending_work;
 };
 
 /* struct mtk_mac -the structure that holds the info about the MACs of the
@@ -398,7 +400,6 @@ struct mtk_eth {
  * @hw:Backpointer to our main datastruture
  * @hw_stats:  Packet statistics counter
  * @phy_dev:   The attached PHY if available
- * @pending_work:  The workqueue used to reset the dma ring
  */
 struct mtk_mac {
int id;
@@ -406,7 +407,6 @@ struct mtk_mac {
struct mtk_eth  *hw;
struct mtk_hw_stats *hw_stats;
struct phy_device   *phy_dev;
-   struct work_struct  pending_work;
 };
 
 /* the struct describing the SoC. these are declared in the soc_xyz.c files */
-- 
1.7.10.4

Re: [PATCH 1/2] thermal: generic-adc: Add DT binding for ADC based thermal sensor driver

[Rob Herring]

On Wed, Apr 06, 2016 at 03:33:05PM +0530, Laxman Dewangan wrote:
> Sometimes, thermal sensors like NCT thermistors are connected to
> the ADC channel. The temperature is read by reading the voltage
> across the sensor resistance via ADC and referring the lookup
> table for ADC value to temperature. The ADC interface is provided
> through the IIO framework.

IIO framework is a detail not relevant to the binding.

> 
> Add DT binding doc for the adc based thermal sensor driver to detail
> the DT property and provide the example for how to use it.
> 
> Signed-off-by: Laxman Dewangan 
> ---
>  .../bindings/thermal/thermal-generic-adc.txt   | 86 
> ++
>  1 file changed, 86 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt 
> b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt
> new file mode 100644
> index 000..6b3e715
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt
> @@ -0,0 +1,86 @@
> +General Purpose Analog To Digital Converter (ADC) based thermal sensor
> +
> +On some of platforms, thermal sensor like thermistors are connected to
> +one of ADC channel and sensor resistance is read via voltage across the
> +sensor. The voltage read across the sensor is mapped to temperature using
> +voltage-temperature lookup table.
> +
> +This driver provides the interface to sensor-ADC interconnection and
> +the relation ship between ADC read value and temperature.

Bindings don't describe drivers.

> +
> +Required properties:
> +===
> +- compatible: Must be "generic-adc-thermal".
> +- lower-temperature:  Lower temperature for the lookup table
> +  in millicelsius.
> +- upper-temperature:  Upper temperature for the lookup table
> +  in millicelsius.
> +- step-temperature:   The temperature steps for the reading ADC
> +  value in millicelsius.
> +- temperature-lookup-table:  The ADC reading value on each step of the
> +  temperature starting from lower temperature
> +  to upper temperature.
> +  When ADC is read, the value is looked up on the
> +  table to get the equivalent temperature.
> +- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description
> +  of this property. 
> +
> +Example :
> +#include 
> +
> +i2c@7000c400 {
> + ads1015: ads1015@4a {
> + reg = <0x4a>;
> + compatible = "ads1015";
> + sampling-frequency = <3300>;
> + #io-channel-cells = <1>; 
> + };
> +};
> +
> +thermal-sensor@1 {
> + compatible = "generic-adc-thermal";
> + #thermal-sensor-cells = <0>;
> + io-channels = < 1>; 
> + io-channel-names = "sensor-channel";
> + lower-temperature = <(-4)>;
> + upper-temperature = <125000>;
> + step-temperature = <1000>;
> + temperature-lookup-table = <2578 2577 2576 2575 2574
> + 2573 2572 2571 2569 2568
> + 2567 2565 2563 2561 2559
> + ::
> + 254 247 240 233 226 220 
> + 214 208>;
> +};
> +
> +dummy_cool_dev: dummy-cool-dev {
> + compatible = "dummy-cooling-dev";
> + #cooling-cells = <2>; /* min followed by max */
> +};
> +
> +thermal-zones {
> + Tboard {
> + polling-delay = <15000>; /* milliseconds */
> + polling-delay-passive = <0>; /* milliseconds */
> + thermal-sensors = <_thermistor>;

Missing a label?

> +
> + trips {
> + therm_est_trip: therm_est_trip {
> + temperature = <4>;
> + type = "active";
> + hysteresis = <1000>;
> + writable;

Missing indentation and closing brace.

> + };
> + };
> +
> + cooling-maps {
> + map0 {
> + trip = <_est_trip>;
> + cooling-device = <_cool_dev THERMAL_NO_LIMIT 
> THERMAL_NO_LIMIT>;
> + contribution = <100>;
> + cdev-type = "therm_est_activ";
> + };

Here's your missing brace... 

> + };
> +
> + };
> +};
> -- 
> 2.1.4
> 

[PATCH 4/9] net: mediatek: remove superfluous reset call

[John Crispin]

HW reset is triggered in the mtk_hw_init() function. There is no need to
also reset the core during probe.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 94cceb8..a4982e4 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1679,10 +1679,6 @@ static int mtk_probe(struct platform_device *pdev)
struct mtk_eth *eth;
int err;
 
-   err = device_reset(>dev);
-   if (err)
-   return err;
-
match = of_match_device(of_mtk_match, >dev);
soc = (struct mtk_soc_data *)match->data;
 
-- 
1.7.10.4

[PATCH 2/9] net: mediatek: watchdog_timeo was not set

[John Crispin]

The original commit failed to set watchdog_timeo. This patch sets
watchdog_timeo to HZ.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index e0b68af..bb10d57 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1645,6 +1645,7 @@ static int mtk_add_mac(struct mtk_eth *eth, struct 
device_node *np)
mac->hw_stats->reg_offset = id * MTK_STAT_OFFSET;
 
SET_NETDEV_DEV(eth->netdev[id], eth->dev);
+   eth->netdev[id]->watchdog_timeo = HZ;
eth->netdev[id]->netdev_ops = _netdev_ops;
eth->netdev[id]->base_addr = (unsigned long)eth->base;
eth->netdev[id]->vlan_features = MTK_HW_FEATURES &
-- 
1.7.10.4

[PATCH 2/9] net: mediatek: watchdog_timeo was not set

[John Crispin]

The original commit failed to set watchdog_timeo. This patch sets
watchdog_timeo to HZ.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index e0b68af..bb10d57 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1645,6 +1645,7 @@ static int mtk_add_mac(struct mtk_eth *eth, struct 
device_node *np)
mac->hw_stats->reg_offset = id * MTK_STAT_OFFSET;
 
SET_NETDEV_DEV(eth->netdev[id], eth->dev);
+   eth->netdev[id]->watchdog_timeo = HZ;
eth->netdev[id]->netdev_ops = _netdev_ops;
eth->netdev[id]->base_addr = (unsigned long)eth->base;
eth->netdev[id]->vlan_features = MTK_HW_FEATURES &
-- 
1.7.10.4

Re: [PATCH v3 4/9] drm/fsl-dcu: add extra clock for pixel clock

[Rob Herring]

On Mon, Apr 04, 2016 at 10:28:36PM -0700, Stefan Agner wrote:
> The Vybrid DCU variant has two independent clock inputs, one
> for the registers (IPG bus clock) and one for the pixel clock.
> Support this distinction in the DCU DRM driver while staying
> backward compatible for old device trees.
> 
> Signed-off-by: Stefan Agner 
> ---
>  Documentation/devicetree/bindings/display/fsl,dcu.txt | 11 +++

Acked-by: Rob Herring 

>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c|  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 16 +++-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 +
>  4 files changed, 24 insertions(+), 6 deletions(-)

Re: [PATCH v1] regulator: twl: Provide of_map_mode for twl4030

[Rob Herring]

On Tue, Apr 05, 2016 at 08:59:34AM +0300, Ivaylo Dimitrov wrote:
> of_map_mode is needed so to be possible to set initial regulators mode from
> the board DTS. Otherwise, for DT boot, regulators are left in their default
> state after reset/reboot. Document device specific modes as well.
> 
> Signed-off-by: Ivaylo Dimitrov 
> ---
>  .../bindings/regulator/twl-regulator.txt   |  6 ++

Acked-by: Rob Herring 

>  drivers/regulator/twl-regulator.c  | 22 
> +++---
>  2 files changed, 25 insertions(+), 3 deletions(-)
> 

[PATCH 7/9] net: mediatek: fix TX locking

[John Crispin]

Inside the TX path there is a lock inside the tx_map function. This is
however too late. The patch moves the lock to the start of the xmit
function right before the free count check of the DMA ring happens.
If we do not do this, the code becomes racy leading to TX stalls and
dropped packets. This happens as there are 2 netdevs running on the
same physical DMA ring.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 60b66ab..8434355 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -536,7 +536,6 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
struct mtk_eth *eth = mac->hw;
struct mtk_tx_dma *itxd, *txd;
struct mtk_tx_buf *tx_buf;
-   unsigned long flags;
dma_addr_t mapped_addr;
unsigned int nr_frags;
int i, n_desc = 1;
@@ -568,11 +567,6 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
if (unlikely(dma_mapping_error(>dev, mapped_addr)))
return -ENOMEM;
 
-   /* normally we can rely on the stack not calling this more than once,
-* however we have 2 queues running ont he same ring so we need to lock
-* the ring access
-*/
-   spin_lock_irqsave(>page_lock, flags);
WRITE_ONCE(itxd->txd1, mapped_addr);
tx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
@@ -632,8 +626,6 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
WRITE_ONCE(itxd->txd3, (TX_DMA_SWC | TX_DMA_PLEN0(skb_headlen(skb)) |
(!nr_frags * TX_DMA_LS0)));
 
-   spin_unlock_irqrestore(>page_lock, flags);
-
netdev_sent_queue(dev, skb->len);
skb_tx_timestamp(skb);
 
@@ -661,8 +653,6 @@ err_dma:
itxd = mtk_qdma_phys_to_virt(ring, itxd->txd2);
} while (itxd != txd);
 
-   spin_unlock_irqrestore(>page_lock, flags);
-
return -ENOMEM;
 }
 
@@ -712,14 +702,22 @@ static int mtk_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
struct mtk_eth *eth = mac->hw;
struct mtk_tx_ring *ring = >tx_ring;
struct net_device_stats *stats = >stats;
+   unsigned long flags;
bool gso = false;
int tx_num;
 
+   /* normally we can rely on the stack not calling this more than once,
+* however we have 2 queues running ont he same ring so we need to lock
+* the ring access
+*/
+   spin_lock_irqsave(>page_lock, flags);
+
tx_num = mtk_cal_txd_req(skb);
if (unlikely(atomic_read(>free_count) <= tx_num)) {
mtk_stop_queue(eth);
netif_err(eth, tx_queued, dev,
  "Tx Ring full when queue awake!\n");
+   spin_unlock_irqrestore(>page_lock, flags);
return NETDEV_TX_BUSY;
}
 
@@ -747,10 +745,12 @@ static int mtk_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
 ring->thresh))
mtk_wake_queue(eth);
}
+   spin_unlock_irqrestore(>page_lock, flags);
 
return NETDEV_TX_OK;
 
 drop:
+   spin_unlock_irqrestore(>page_lock, flags);
stats->tx_dropped++;
dev_kfree_skb(skb);
return NETDEV_TX_OK;
-- 
1.7.10.4

Re: [PATCH v2 2/2] devicetree: document NXP LPC1850 PINT irq controller binding

[Rob Herring]

On Sat, Apr 02, 2016 at 06:35:24PM +0200, Joachim Eastwood wrote:
> Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT)
> controller.
> 
> Signed-off-by: Joachim Eastwood 
> ---
>  .../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/interrupt-controller/nxp,lpc1850-gpio-pint.txt

Acked-by: Rob Herring 

Re: [PATCH v3 4/9] drm/fsl-dcu: add extra clock for pixel clock

[Rob Herring]

On Mon, Apr 04, 2016 at 10:28:36PM -0700, Stefan Agner wrote:
> The Vybrid DCU variant has two independent clock inputs, one
> for the registers (IPG bus clock) and one for the pixel clock.
> Support this distinction in the DCU DRM driver while staying
> backward compatible for old device trees.
> 
> Signed-off-by: Stefan Agner 
> ---
>  Documentation/devicetree/bindings/display/fsl,dcu.txt | 11 +++

Acked-by: Rob Herring 

>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c|  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 16 +++-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 +
>  4 files changed, 24 insertions(+), 6 deletions(-)

Re: [PATCH v1] regulator: twl: Provide of_map_mode for twl4030

[Rob Herring]

On Tue, Apr 05, 2016 at 08:59:34AM +0300, Ivaylo Dimitrov wrote:
> of_map_mode is needed so to be possible to set initial regulators mode from
> the board DTS. Otherwise, for DT boot, regulators are left in their default
> state after reset/reboot. Document device specific modes as well.
> 
> Signed-off-by: Ivaylo Dimitrov 
> ---
>  .../bindings/regulator/twl-regulator.txt   |  6 ++

Acked-by: Rob Herring 

>  drivers/regulator/twl-regulator.c  | 22 
> +++---
>  2 files changed, 25 insertions(+), 3 deletions(-)
> 

[PATCH 7/9] net: mediatek: fix TX locking

[John Crispin]

Inside the TX path there is a lock inside the tx_map function. This is
however too late. The patch moves the lock to the start of the xmit
function right before the free count check of the DMA ring happens.
If we do not do this, the code becomes racy leading to TX stalls and
dropped packets. This happens as there are 2 netdevs running on the
same physical DMA ring.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 60b66ab..8434355 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -536,7 +536,6 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
struct mtk_eth *eth = mac->hw;
struct mtk_tx_dma *itxd, *txd;
struct mtk_tx_buf *tx_buf;
-   unsigned long flags;
dma_addr_t mapped_addr;
unsigned int nr_frags;
int i, n_desc = 1;
@@ -568,11 +567,6 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
if (unlikely(dma_mapping_error(>dev, mapped_addr)))
return -ENOMEM;
 
-   /* normally we can rely on the stack not calling this more than once,
-* however we have 2 queues running ont he same ring so we need to lock
-* the ring access
-*/
-   spin_lock_irqsave(>page_lock, flags);
WRITE_ONCE(itxd->txd1, mapped_addr);
tx_buf->flags |= MTK_TX_FLAGS_SINGLE0;
dma_unmap_addr_set(tx_buf, dma_addr0, mapped_addr);
@@ -632,8 +626,6 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
WRITE_ONCE(itxd->txd3, (TX_DMA_SWC | TX_DMA_PLEN0(skb_headlen(skb)) |
(!nr_frags * TX_DMA_LS0)));
 
-   spin_unlock_irqrestore(>page_lock, flags);
-
netdev_sent_queue(dev, skb->len);
skb_tx_timestamp(skb);
 
@@ -661,8 +653,6 @@ err_dma:
itxd = mtk_qdma_phys_to_virt(ring, itxd->txd2);
} while (itxd != txd);
 
-   spin_unlock_irqrestore(>page_lock, flags);
-
return -ENOMEM;
 }
 
@@ -712,14 +702,22 @@ static int mtk_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
struct mtk_eth *eth = mac->hw;
struct mtk_tx_ring *ring = >tx_ring;
struct net_device_stats *stats = >stats;
+   unsigned long flags;
bool gso = false;
int tx_num;
 
+   /* normally we can rely on the stack not calling this more than once,
+* however we have 2 queues running ont he same ring so we need to lock
+* the ring access
+*/
+   spin_lock_irqsave(>page_lock, flags);
+
tx_num = mtk_cal_txd_req(skb);
if (unlikely(atomic_read(>free_count) <= tx_num)) {
mtk_stop_queue(eth);
netif_err(eth, tx_queued, dev,
  "Tx Ring full when queue awake!\n");
+   spin_unlock_irqrestore(>page_lock, flags);
return NETDEV_TX_BUSY;
}
 
@@ -747,10 +745,12 @@ static int mtk_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
 ring->thresh))
mtk_wake_queue(eth);
}
+   spin_unlock_irqrestore(>page_lock, flags);
 
return NETDEV_TX_OK;
 
 drop:
+   spin_unlock_irqrestore(>page_lock, flags);
stats->tx_dropped++;
dev_kfree_skb(skb);
return NETDEV_TX_OK;
-- 
1.7.10.4

Re: [PATCH v2 2/2] devicetree: document NXP LPC1850 PINT irq controller binding

[Rob Herring]

On Sat, Apr 02, 2016 at 06:35:24PM +0200, Joachim Eastwood wrote:
> Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT)
> controller.
> 
> Signed-off-by: Joachim Eastwood 
> ---
>  .../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/interrupt-controller/nxp,lpc1850-gpio-pint.txt

Acked-by: Rob Herring 

Re: [PATCH v12 8/9] add TC G210 platform driver

[Rob Herring]

On Mon, Apr 04, 2016 at 11:48:23AM +0100, Joao Pinto wrote:
> 
> Hi Rob,
> 
> On 4/4/2016 6:15 AM, Rob Herring wrote:
> > On Thu, Mar 31, 2016 at 07:57:21PM +0100, Joao Pinto wrote:
> >> This patch adds a glue platform driver for the Synopsys G210 Test Chip.
> >>
> >> Signed-off-by: Joao Pinto 
> >> ---
> 
> [snip]
> 
> >> +
> >> +Required properties:
> >> +- compatible  : compatible list must contain the PHY type & version:
> >> +  "snps, g210-tc-6.00-20bit"
> >> +  "snps, g210-tc-6.00-40bit"
> > Remove the space  ^
> > 
> >> +complemented with the Controller IP version:
> >> +  "snps, dwc-ufshcd-1.40a"
> > 
> > ditto
> 
> Ok, will do that!
> 
> > 
> > Combining the phy and controller compatible strings is a bit strange. 
> > Generally, they would be separate nodes using the common phy binding.
> > 
> 
> Correct, but in this case is just the compatibility string is just to tell the
> dw ufs host that it has a 40-bit or a 20-bit test chip connected. The Test 
> chip
> is initialized by a unipro command sequence and there is no more ops related 
> to it.

Okay. In that case, I think it should be a separate property unless the 
controller h/w is synthesized for one or the other.

Rob

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

[Rob Herring]

On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote:
> This adds the regulator nodes to DK04 device tree to support
> 
> Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa
> Signed-off-by: Sreedhar Sambangi 
> ---
>  .../bindings/regulator/ipq4019-regulator.txt  | 19 
> +++
>  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 11 +++
>  2 files changed, 30 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt 
> b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> new file mode 100644
> index 000..9d934a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> @@ -0,0 +1,19 @@
> +* Qualcomm Technologies, Inc. IPQ4019 regulators
> +
> +Required properties:
> +- compatible : Must be "regulator-ipq4019".

Doesn't match your example which correctly has vendor prefix. Also, the 
preferred form is ,-.

> +- states : Selection of available voltages and corresponding 
> values

Too generic of a name.

Is this not fixed by the h/w block?

> +- reg: Register address for controlling LDO
> +- mask   : Mask value for switching voltages

What else is in this register? If something unrelated, then this is all 
wrong to the regulator. You can only define the register address in one 
place in the DT. Otherwise, you should know the mask from the compatible 
string.

Rob

Re: [PATCH v12 8/9] add TC G210 platform driver

[Rob Herring]

On Mon, Apr 04, 2016 at 11:48:23AM +0100, Joao Pinto wrote:
> 
> Hi Rob,
> 
> On 4/4/2016 6:15 AM, Rob Herring wrote:
> > On Thu, Mar 31, 2016 at 07:57:21PM +0100, Joao Pinto wrote:
> >> This patch adds a glue platform driver for the Synopsys G210 Test Chip.
> >>
> >> Signed-off-by: Joao Pinto 
> >> ---
> 
> [snip]
> 
> >> +
> >> +Required properties:
> >> +- compatible  : compatible list must contain the PHY type & version:
> >> +  "snps, g210-tc-6.00-20bit"
> >> +  "snps, g210-tc-6.00-40bit"
> > Remove the space  ^
> > 
> >> +complemented with the Controller IP version:
> >> +  "snps, dwc-ufshcd-1.40a"
> > 
> > ditto
> 
> Ok, will do that!
> 
> > 
> > Combining the phy and controller compatible strings is a bit strange. 
> > Generally, they would be separate nodes using the common phy binding.
> > 
> 
> Correct, but in this case is just the compatibility string is just to tell the
> dw ufs host that it has a 40-bit or a 20-bit test chip connected. The Test 
> chip
> is initialized by a unipro command sequence and there is no more ops related 
> to it.

Okay. In that case, I think it should be a separate property unless the 
controller h/w is synthesized for one or the other.

Rob

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

[Rob Herring]

On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote:
> This adds the regulator nodes to DK04 device tree to support
> 
> Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa
> Signed-off-by: Sreedhar Sambangi 
> ---
>  .../bindings/regulator/ipq4019-regulator.txt  | 19 
> +++
>  arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 11 +++
>  2 files changed, 30 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt 
> b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> new file mode 100644
> index 000..9d934a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt
> @@ -0,0 +1,19 @@
> +* Qualcomm Technologies, Inc. IPQ4019 regulators
> +
> +Required properties:
> +- compatible : Must be "regulator-ipq4019".

Doesn't match your example which correctly has vendor prefix. Also, the 
preferred form is ,-.

> +- states : Selection of available voltages and corresponding 
> values

Too generic of a name.

Is this not fixed by the h/w block?

> +- reg: Register address for controlling LDO
> +- mask   : Mask value for switching voltages

What else is in this register? If something unrelated, then this is all 
wrong to the regulator. You can only define the register address in one 
place in the DT. Otherwise, you should know the mask from the compatible 
string.

Rob