[PATCH 3/4] input: xpad.rst: proc/bus/usb was renamed to dev/bus/usb

[Mauro Carvalho Chehab]

xpad.rst requests a dump of the USB description, as found
on the USB character device. When we got rid of usbfs,
its location change. Update it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/devices/xpad.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/input/devices/xpad.rst 
b/Documentation/input/devices/xpad.rst
index c7c4e154bd34..3c74c185be7d 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -89,7 +89,7 @@ HOWEVER if you have an unknown dance pad not listed below, it 
will not
 work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
 
 PLEASE, if you have an unknown controller, email Dom  
with
-a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
+a dump from /dev/bus/usb and a description of the pad (manufacturer, country,
 whether it is a dance pad or normal controller) so that we can add your pad
 to the list of supported devices, ensuring that it will work out of the
 box in the future.
-- 
2.9.3

[PATCH 3/4] input: xpad.rst: proc/bus/usb was renamed to dev/bus/usb

[Mauro Carvalho Chehab]

xpad.rst requests a dump of the USB description, as found
on the USB character device. When we got rid of usbfs,
its location change. Update it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/devices/xpad.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/input/devices/xpad.rst 
b/Documentation/input/devices/xpad.rst
index c7c4e154bd34..3c74c185be7d 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -89,7 +89,7 @@ HOWEVER if you have an unknown dance pad not listed below, it 
will not
 work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
 
 PLEASE, if you have an unknown controller, email Dom  
with
-a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
+a dump from /dev/bus/usb and a description of the pad (manufacturer, country,
 whether it is a dance pad or normal controller) so that we can add your pad
 to the list of supported devices, ensuring that it will work out of the
 box in the future.
-- 
2.9.3

[PATCH 2/4] input: xpad.rst: Don't use literal blocks inside footnotes

[Mauro Carvalho Chehab]

Unfortunately, Sphinx (or LaTeX) can't handle literal blocks
inside footnotes. So, just use normal text for the two
literal code-blocks that documents the output of
/sys/kernel/debug/usb/devices for xpad devices.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/devices/xpad.rst | 51 ++--
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/Documentation/input/devices/xpad.rst 
b/Documentation/input/devices/xpad.rst
index e19669fe5a80..c7c4e154bd34 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -138,15 +138,37 @@ Driver Installation
 
 Once you have the adapter cable, if needed, and the controller connected
 the xpad module should be auto loaded. To confirm you can cat
-/sys/kernel/debug/usb/devices. There should be an entry like the one at the 
end [4]_.
+/sys/kernel/debug/usb/devices. There should be an entry like those:
 
+.. code-block:: none
+   :caption: dump from InterAct PowerPad Pro (Germany)
+
+T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
+D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
+P:  Vendor=05fd ProdID=107a Rev= 1.00
+C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
+I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
+E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
+E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
+
+.. code-block:: none
+   :caption: dump from Redoctane Xbox Dance Pad (US)
+
+T:  Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
+D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
+P:  Vendor=0c12 ProdID=8809 Rev= 0.01
+S:  Product=XBOX DDR
+C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
+I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
+E:  Ad=82(I) Atr=03(Int.) MxPS=  32 Ivl=4ms
+E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=4ms
 
 
 Supported Controllers
 =
 
 For a full list of supported controllers and associated vendor and product
-IDs see the xpad_device[] array[6].
+IDs see the xpad_device[] array\ [4]_.
 
 As of the historic version 0.0.6 (2006-10-10) the following devices
 were supported::
@@ -202,30 +224,7 @@ References
 .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
 .. [2] http://xpad.xbox-scene.com/
 .. [3] http://www.markosweb.com/www/xboxhackz.com/
-.. [4] /sys/kernel/debug/usb/devices - dump from InterAct PowerPad Pro 
(Germany):
-
- ::
-
-T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
-D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
-P:  Vendor=05fd ProdID=107a Rev= 1.00
-C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
-I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
-E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
-E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
-.. [5] /sys/kernel/debug/usb/devices - dump from Redoctane Xbox Dance Pad (US):
-
- ::
-
-T:  Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
-D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
-P:  Vendor=0c12 ProdID=8809 Rev= 0.01
-S:  Product=XBOX DDR
-C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
-I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
-E:  Ad=82(I) Atr=03(Int.) MxPS=  32 Ivl=4ms
-E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=4ms
-.. [6] http://lxr.free-electrons.com/ident?i=xpad_device
+.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
 
 
 Historic Edits
-- 
2.9.3

[PATCH 1/4] input: xpad.rst: usb/devices is now at /sys/kernel/debug/

[Mauro Carvalho Chehab]

The /proc/bus/usb/devices got moved to sysfs. It is now
sitting at:
/sys/kernel/debug/usb/devices

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/devices/xpad.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/input/devices/xpad.rst 
b/Documentation/input/devices/xpad.rst
index 80028433b460..e19669fe5a80 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -138,7 +138,7 @@ Driver Installation
 
 Once you have the adapter cable, if needed, and the controller connected
 the xpad module should be auto loaded. To confirm you can cat
-/proc/bus/usb/devices. There should be an entry like the one at the end [4]_.
+/sys/kernel/debug/usb/devices. There should be an entry like the one at the 
end [4]_.
 
 
 
@@ -202,7 +202,7 @@ References
 .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
 .. [2] http://xpad.xbox-scene.com/
 .. [3] http://www.markosweb.com/www/xboxhackz.com/
-.. [4] /proc/bus/usb/devices - dump from InterAct PowerPad Pro (Germany):
+.. [4] /sys/kernel/debug/usb/devices - dump from InterAct PowerPad Pro 
(Germany):
 
  ::
 
@@ -213,7 +213,7 @@ References
 I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
 E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
 E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
-.. [5] /proc/bus/usb/devices - dump from Redoctane Xbox Dance Pad (US):
+.. [5] /sys/kernel/debug/usb/devices - dump from Redoctane Xbox Dance Pad (US):
 
  ::
 
-- 
2.9.3

[PATCH 2/4] input: xpad.rst: Don't use literal blocks inside footnotes

[Mauro Carvalho Chehab]

Unfortunately, Sphinx (or LaTeX) can't handle literal blocks
inside footnotes. So, just use normal text for the two
literal code-blocks that documents the output of
/sys/kernel/debug/usb/devices for xpad devices.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/devices/xpad.rst | 51 ++--
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/Documentation/input/devices/xpad.rst 
b/Documentation/input/devices/xpad.rst
index e19669fe5a80..c7c4e154bd34 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -138,15 +138,37 @@ Driver Installation
 
 Once you have the adapter cable, if needed, and the controller connected
 the xpad module should be auto loaded. To confirm you can cat
-/sys/kernel/debug/usb/devices. There should be an entry like the one at the 
end [4]_.
+/sys/kernel/debug/usb/devices. There should be an entry like those:
 
+.. code-block:: none
+   :caption: dump from InterAct PowerPad Pro (Germany)
+
+T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
+D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
+P:  Vendor=05fd ProdID=107a Rev= 1.00
+C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
+I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
+E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
+E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
+
+.. code-block:: none
+   :caption: dump from Redoctane Xbox Dance Pad (US)
+
+T:  Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
+D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
+P:  Vendor=0c12 ProdID=8809 Rev= 0.01
+S:  Product=XBOX DDR
+C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
+I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
+E:  Ad=82(I) Atr=03(Int.) MxPS=  32 Ivl=4ms
+E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=4ms
 
 
 Supported Controllers
 =
 
 For a full list of supported controllers and associated vendor and product
-IDs see the xpad_device[] array[6].
+IDs see the xpad_device[] array\ [4]_.
 
 As of the historic version 0.0.6 (2006-10-10) the following devices
 were supported::
@@ -202,30 +224,7 @@ References
 .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
 .. [2] http://xpad.xbox-scene.com/
 .. [3] http://www.markosweb.com/www/xboxhackz.com/
-.. [4] /sys/kernel/debug/usb/devices - dump from InterAct PowerPad Pro 
(Germany):
-
- ::
-
-T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
-D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
-P:  Vendor=05fd ProdID=107a Rev= 1.00
-C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
-I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
-E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
-E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
-.. [5] /sys/kernel/debug/usb/devices - dump from Redoctane Xbox Dance Pad (US):
-
- ::
-
-T:  Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
-D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
-P:  Vendor=0c12 ProdID=8809 Rev= 0.01
-S:  Product=XBOX DDR
-C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
-I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
-E:  Ad=82(I) Atr=03(Int.) MxPS=  32 Ivl=4ms
-E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=4ms
-.. [6] http://lxr.free-electrons.com/ident?i=xpad_device
+.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
 
 
 Historic Edits
-- 
2.9.3

[PATCH 1/4] input: xpad.rst: usb/devices is now at /sys/kernel/debug/

[Mauro Carvalho Chehab]

The /proc/bus/usb/devices got moved to sysfs. It is now
sitting at:
/sys/kernel/debug/usb/devices

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/devices/xpad.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/input/devices/xpad.rst 
b/Documentation/input/devices/xpad.rst
index 80028433b460..e19669fe5a80 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -138,7 +138,7 @@ Driver Installation
 
 Once you have the adapter cable, if needed, and the controller connected
 the xpad module should be auto loaded. To confirm you can cat
-/proc/bus/usb/devices. There should be an entry like the one at the end [4]_.
+/sys/kernel/debug/usb/devices. There should be an entry like the one at the 
end [4]_.
 
 
 
@@ -202,7 +202,7 @@ References
 .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
 .. [2] http://xpad.xbox-scene.com/
 .. [3] http://www.markosweb.com/www/xboxhackz.com/
-.. [4] /proc/bus/usb/devices - dump from InterAct PowerPad Pro (Germany):
+.. [4] /sys/kernel/debug/usb/devices - dump from InterAct PowerPad Pro 
(Germany):
 
  ::
 
@@ -213,7 +213,7 @@ References
 I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
 E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
 E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
-.. [5] /proc/bus/usb/devices - dump from Redoctane Xbox Dance Pad (US):
+.. [5] /sys/kernel/debug/usb/devices - dump from Redoctane Xbox Dance Pad (US):
 
  ::
 
-- 
2.9.3

Re: [PATCH 1/2] iio: adc: Fix integration time/averaging for INA219/220

[Stefan Bruens]

On Freitag, 14. April 2017 17:02:33 CEST Jonathan Cameron wrote:
> On 12/04/17 04:01, Stefan Brüns wrote:
> > INA226/230/231 has integration times per voltage channel and common
> > averaging setting for both channels, while the INA219/220 only has a
> > combined integration time/averaging setting per channel.
> > Only expose the averaging attribute for the INA226, and expose the correct
> > integration times for the INA219.
> > 
> > Signed-off-by: Stefan Brüns 
> 
> A few bits inline.
> 
> The info_mask_shared_by_dir isn't right in the driver currently.
> Those elements should be list for every channel in that direction.  This
> moves where they are rather than fixing that.
> 
> Please sort that mess out whilst you are here.
> 
> Thanks,
> 
> Jonathan
> 
> > ---
> > 
> >  drivers/iio/adc/ina2xx-adc.c | 179
> >  ++- 1 file changed, 158
> >  insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
> > index 3263231276ca..d1678f886297 100644
> > --- a/drivers/iio/adc/ina2xx-adc.c
> > +++ b/drivers/iio/adc/ina2xx-adc.c
> > @@ -48,6 +48,7 @@
> > 
> >  /* settings - depend on use case */
> >  #define INA219_CONFIG_DEFAULT   0x399F /* PGA=8 */
> > 
> > +#define INA219_DEFAULT_IT  532
> > 
> >  #define INA226_CONFIG_DEFAULT   0x4327
> >  #define INA226_DEFAULT_AVG  4
> >  #define INA226_DEFAULT_IT  1110
> > 
> > @@ -55,19 +56,24 @@
> > 
> >  #define INA2XX_RSHUNT_DEFAULT   1
> >  
> >  /*
> > 
> > - * bit mask for reading the averaging setting in the configuration
> > register + * bit masks for reading the settings in the configuration
> > register> 
> >   * FIXME: use regmap_fields.
> 
> Either fix this or drop the fixme. It's fine to regmap fields if you
> like, but it it's not broken if it doesn't use them.

The FIXME was not added nor changed by me. I see no reason to drop it.
 
> >   */
> >  
> >  #define INA2XX_MODE_MASK   GENMASK(3, 0)
> > 
> > +/* Averaging for VBus/VShunt/Power */
> > 
> >  #define INA226_AVG_MASKGENMASK(11, 9)
> >  #define INA226_SHIFT_AVG(val)  ((val) << 9)
> >  
> >  /* Integration time for VBus */
> > 
> > +#define INA219_ITB_MASKGENMASK(10, 7)
> > +#define INA219_SHIFT_ITB(val)  ((val) << 7)
> > 
> >  #define INA226_ITB_MASKGENMASK(8, 6)
> >  #define INA226_SHIFT_ITB(val)  ((val) << 6)
> >  
> >  /* Integration time for VShunt */
> > 
> > +#define INA219_ITS_MASKGENMASK(6, 3)
> > +#define INA219_SHIFT_ITS(val)  ((val) << 3)
> > 
> >  #define INA226_ITS_MASKGENMASK(5, 3)
> >  #define INA226_SHIFT_ITS(val)  ((val) << 3)
> > 
> > @@ -107,6 +113,7 @@ struct ina2xx_config {
> > 
> > int bus_voltage_shift;
> > int bus_voltage_lsb;/* uV */
> > int power_lsb;  /* uW */
> > 
> > +   enum ina2xx_ids chip_id;
> > 
> >  };
> >  
> >  struct ina2xx_chip_info {
> > 
> > @@ -129,6 +136,7 @@ static const struct ina2xx_config ina2xx_config[] = {
> > 
> > .bus_voltage_shift = 3,
> > .bus_voltage_lsb = 4000,
> > .power_lsb = 2,
> > 
> > +   .chip_id = ina219,
> > 
> > },
> > [ina226] = {
> > 
> > .config_default = INA226_CONFIG_DEFAULT,
> > 
> > @@ -137,6 +145,7 @@ static const struct ina2xx_config ina2xx_config[] = {
> > 
> > .bus_voltage_shift = 0,
> > .bus_voltage_lsb = 1250,
> > .power_lsb = 25000,
> > 
> > +   .chip_id = ina226,
> > 
> > },
> >  
> >  };
> > 
> > @@ -282,6 +291,66 @@ static int ina226_set_int_time_vshunt(struct
> > ina2xx_chip_info *chip,> 
> > return 0;
> >  
> >  }
> > 
> > +/* Conversion times in uS. */
> > +static const int ina219_conv_time_tab_subsample[] = { 84, 148, 276, 532
> > };
> > +static const int ina219_conv_time_tab_average[] = { 532, 1060, 2130,
> > 4260,
> > +   8510, 17020, 34050, 68100};
> > +
> > +static int ina219_lookup_int_time(unsigned int *val_us, int *bits)
> > +{
> > +   if (*val_us > 68100 || *val_us < 84)
> > +   return -EINVAL;
> > +
> > +   if (*val_us <= 532) {
> > +   *bits = find_closest(*val_us, ina219_conv_time_tab_subsample,
> > +   ARRAY_SIZE(ina219_conv_time_tab_subsample));
> > +   *val_us = ina219_conv_time_tab_subsample[*bits];
> > +   } else {
> > +   *bits = find_closest(*val_us, ina219_conv_time_tab_average,
> > +   ARRAY_SIZE(ina219_conv_time_tab_average));
> > +   *val_us = ina219_conv_time_tab_average[*bits];
> > +   *bits |= 0x8;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int ina219_set_int_time_vbus(struct ina2xx_chip_info *chip,
> > +   unsigned int val_us, unsigned int *config)
> > +{
> > +   int bits, ret;
> > +   unsigned int 

Re: [PATCH 1/2] iio: adc: Fix integration time/averaging for INA219/220

[Stefan Bruens]

On Freitag, 14. April 2017 17:02:33 CEST Jonathan Cameron wrote:
> On 12/04/17 04:01, Stefan Brüns wrote:
> > INA226/230/231 has integration times per voltage channel and common
> > averaging setting for both channels, while the INA219/220 only has a
> > combined integration time/averaging setting per channel.
> > Only expose the averaging attribute for the INA226, and expose the correct
> > integration times for the INA219.
> > 
> > Signed-off-by: Stefan Brüns 
> 
> A few bits inline.
> 
> The info_mask_shared_by_dir isn't right in the driver currently.
> Those elements should be list for every channel in that direction.  This
> moves where they are rather than fixing that.
> 
> Please sort that mess out whilst you are here.
> 
> Thanks,
> 
> Jonathan
> 
> > ---
> > 
> >  drivers/iio/adc/ina2xx-adc.c | 179
> >  ++- 1 file changed, 158
> >  insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
> > index 3263231276ca..d1678f886297 100644
> > --- a/drivers/iio/adc/ina2xx-adc.c
> > +++ b/drivers/iio/adc/ina2xx-adc.c
> > @@ -48,6 +48,7 @@
> > 
> >  /* settings - depend on use case */
> >  #define INA219_CONFIG_DEFAULT   0x399F /* PGA=8 */
> > 
> > +#define INA219_DEFAULT_IT  532
> > 
> >  #define INA226_CONFIG_DEFAULT   0x4327
> >  #define INA226_DEFAULT_AVG  4
> >  #define INA226_DEFAULT_IT  1110
> > 
> > @@ -55,19 +56,24 @@
> > 
> >  #define INA2XX_RSHUNT_DEFAULT   1
> >  
> >  /*
> > 
> > - * bit mask for reading the averaging setting in the configuration
> > register + * bit masks for reading the settings in the configuration
> > register> 
> >   * FIXME: use regmap_fields.
> 
> Either fix this or drop the fixme. It's fine to regmap fields if you
> like, but it it's not broken if it doesn't use them.

The FIXME was not added nor changed by me. I see no reason to drop it.
 
> >   */
> >  
> >  #define INA2XX_MODE_MASK   GENMASK(3, 0)
> > 
> > +/* Averaging for VBus/VShunt/Power */
> > 
> >  #define INA226_AVG_MASKGENMASK(11, 9)
> >  #define INA226_SHIFT_AVG(val)  ((val) << 9)
> >  
> >  /* Integration time for VBus */
> > 
> > +#define INA219_ITB_MASKGENMASK(10, 7)
> > +#define INA219_SHIFT_ITB(val)  ((val) << 7)
> > 
> >  #define INA226_ITB_MASKGENMASK(8, 6)
> >  #define INA226_SHIFT_ITB(val)  ((val) << 6)
> >  
> >  /* Integration time for VShunt */
> > 
> > +#define INA219_ITS_MASKGENMASK(6, 3)
> > +#define INA219_SHIFT_ITS(val)  ((val) << 3)
> > 
> >  #define INA226_ITS_MASKGENMASK(5, 3)
> >  #define INA226_SHIFT_ITS(val)  ((val) << 3)
> > 
> > @@ -107,6 +113,7 @@ struct ina2xx_config {
> > 
> > int bus_voltage_shift;
> > int bus_voltage_lsb;/* uV */
> > int power_lsb;  /* uW */
> > 
> > +   enum ina2xx_ids chip_id;
> > 
> >  };
> >  
> >  struct ina2xx_chip_info {
> > 
> > @@ -129,6 +136,7 @@ static const struct ina2xx_config ina2xx_config[] = {
> > 
> > .bus_voltage_shift = 3,
> > .bus_voltage_lsb = 4000,
> > .power_lsb = 2,
> > 
> > +   .chip_id = ina219,
> > 
> > },
> > [ina226] = {
> > 
> > .config_default = INA226_CONFIG_DEFAULT,
> > 
> > @@ -137,6 +145,7 @@ static const struct ina2xx_config ina2xx_config[] = {
> > 
> > .bus_voltage_shift = 0,
> > .bus_voltage_lsb = 1250,
> > .power_lsb = 25000,
> > 
> > +   .chip_id = ina226,
> > 
> > },
> >  
> >  };
> > 
> > @@ -282,6 +291,66 @@ static int ina226_set_int_time_vshunt(struct
> > ina2xx_chip_info *chip,> 
> > return 0;
> >  
> >  }
> > 
> > +/* Conversion times in uS. */
> > +static const int ina219_conv_time_tab_subsample[] = { 84, 148, 276, 532
> > };
> > +static const int ina219_conv_time_tab_average[] = { 532, 1060, 2130,
> > 4260,
> > +   8510, 17020, 34050, 68100};
> > +
> > +static int ina219_lookup_int_time(unsigned int *val_us, int *bits)
> > +{
> > +   if (*val_us > 68100 || *val_us < 84)
> > +   return -EINVAL;
> > +
> > +   if (*val_us <= 532) {
> > +   *bits = find_closest(*val_us, ina219_conv_time_tab_subsample,
> > +   ARRAY_SIZE(ina219_conv_time_tab_subsample));
> > +   *val_us = ina219_conv_time_tab_subsample[*bits];
> > +   } else {
> > +   *bits = find_closest(*val_us, ina219_conv_time_tab_average,
> > +   ARRAY_SIZE(ina219_conv_time_tab_average));
> > +   *val_us = ina219_conv_time_tab_average[*bits];
> > +   *bits |= 0x8;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int ina219_set_int_time_vbus(struct ina2xx_chip_info *chip,
> > +   unsigned int val_us, unsigned int *config)
> > +{
> > +   int bits, ret;
> > +   unsigned int val_us_best = val_us;
> > +
> > +   

Re: [PATCH 1/2] [media] uvcvideo: Refactor teardown of uvc on USB disconnect

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch (and the investigation).

On Monday 17 Apr 2017 18:52:39 Daniel Axtens wrote:
> Currently, disconnecting a USB webcam while it is in use prints out a
> number of warnings, such as:
> 
> WARNING: CPU: 2 PID: 3118 at
> /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237
> sysfs_remove_group+0x8b/0x90 sysfs group a7cd0780 not found for
> kobject 'event13'
> 
> This has been noticed before. [0]
> 
> This is because of the order in which things are torn down.
> 
> If there are no streams active during a USB disconnect:
> 
>  - uvc_disconnect() is invoked via device_del() through the bus
>notifier mechanism.
> 
>  - this calls uvc_unregister_video().
> 
>  - uvc_unregister_video() unregisters the video device for each
>stream,
> 
>  - because there are no streams open, it calls uvc_delete()
> 
>  - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
>input device.
> 
>  - uvc_delete() calls media_device_unregister(), which cleans up the
>media device
> 
>  - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all
>return, and we end up back in device_del().
> 
>  - device_del() then cleans up the sysfs folder for the camera with
>dpm_sysfs_remove(). Because uvc_status_cleanup() and
>media_device_unregister() have already been called, this all works
>nicely.
> 
> If, on the other hand, there *are* streams active during a USB disconnect:
> 
>  - uvc_disconnect() is invoked
> 
>  - this calls uvc_unregister_video()
> 
>  - uvc_unregister_video() unregisters the video device for each
>stream,
> 
>  - uvc_unregister_video() and uvc_disconnect() return, and we end up
>back in device_del().
> 
>  - device_del() then cleans up the sysfs folder for the camera with
>dpm_sysfs_remove(). Because the status input device and the media
>device are children of the USB device, this also deletes their
>sysfs folders.
> 
>  - Sometime later, the final stream is closed, invoking uvc_release().
> 
>  - uvc_release() calls uvc_delete()
> 
>  - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
>input device. Because the sysfs directory has already been removed,
>this causes a WARNing.
> 
>  - uvc_delete() calls media_device_unregister(), which cleans up the
>media device. Because the sysfs directory has already been removed,
>this causes another WARNing.
> 
> To fix this, we need to make sure the devices are always unregistered
> before the end of uvc_disconnect(). To this, move the unregistration
> into the disconnect path:
>
>  - split uvc_status_cleanup() into two parts, one on disconnect that
>unregisters and one on delete that frees.
> 
>  - move media_device_unregister() into the disconnect path.

While the patch looks reasonable to me (with one comment below though), isn't 
this an issue with the USB core, or possibly the device core ? It's a common 
practice to create device nodes as children of physical devices. Does the 
device core really require all device nodes to be unregistered synchronously 
with physical device hot-unplug ? If so, shouldn't it warn somehow when a 
device is deleted and still has children, instead of accepting that silently 
and later complaining due to sysfs issues ?

> [0]: https://lkml.org/lkml/2016/12/8/657
> 
> Cc: Laurent Pinchart 
> Cc: Dave Stevenson 
> Cc: Greg KH 
> Signed-off-by: Daniel Axtens 
> 
> ---
> 
> Tested with cheese and yavta.
> ---
>  drivers/media/usb/uvc/uvc_driver.c | 8 ++--
>  drivers/media/usb/uvc/uvc_status.c | 8 ++--
>  drivers/media/usb/uvc/uvcvideo.h   | 1 +
>  3 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 46d6be0bb316..2390592f78e0
> 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1815,8 +1815,6 @@ static void uvc_delete(struct uvc_device *dev)
>   if (dev->vdev.dev)
>   v4l2_device_unregister(>vdev);
>  #ifdef CONFIG_MEDIA_CONTROLLER
> - if (media_devnode_is_registered(dev->mdev.devnode))
> - media_device_unregister(>mdev);

media_device_unregister() will now be called before v4l2_device_unregister() 
which, unless I'm mistaken, will now result in 
media_device_unregister_entity() being called twice for every entity, the 
first time by media_device_unregister(), and the second time by 
v4l2_device_unregister_subdev() through v4l2_device_unregister(). Looking at 
media_device_unregister() I don't think that's safe.

We could move to v4l2_device_unregister() call to uvc_unregister_video(), but 
that worries me (perhaps unnecessarily though) due to the race conditions it 
could introduce. Would you still be able to give it a try ?

Note that your patch isn't really at fault here, the media controller and V4L2 
core code 

Re: [PATCH 1/2] [media] uvcvideo: Refactor teardown of uvc on USB disconnect

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch (and the investigation).

On Monday 17 Apr 2017 18:52:39 Daniel Axtens wrote:
> Currently, disconnecting a USB webcam while it is in use prints out a
> number of warnings, such as:
> 
> WARNING: CPU: 2 PID: 3118 at
> /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237
> sysfs_remove_group+0x8b/0x90 sysfs group a7cd0780 not found for
> kobject 'event13'
> 
> This has been noticed before. [0]
> 
> This is because of the order in which things are torn down.
> 
> If there are no streams active during a USB disconnect:
> 
>  - uvc_disconnect() is invoked via device_del() through the bus
>notifier mechanism.
> 
>  - this calls uvc_unregister_video().
> 
>  - uvc_unregister_video() unregisters the video device for each
>stream,
> 
>  - because there are no streams open, it calls uvc_delete()
> 
>  - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
>input device.
> 
>  - uvc_delete() calls media_device_unregister(), which cleans up the
>media device
> 
>  - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all
>return, and we end up back in device_del().
> 
>  - device_del() then cleans up the sysfs folder for the camera with
>dpm_sysfs_remove(). Because uvc_status_cleanup() and
>media_device_unregister() have already been called, this all works
>nicely.
> 
> If, on the other hand, there *are* streams active during a USB disconnect:
> 
>  - uvc_disconnect() is invoked
> 
>  - this calls uvc_unregister_video()
> 
>  - uvc_unregister_video() unregisters the video device for each
>stream,
> 
>  - uvc_unregister_video() and uvc_disconnect() return, and we end up
>back in device_del().
> 
>  - device_del() then cleans up the sysfs folder for the camera with
>dpm_sysfs_remove(). Because the status input device and the media
>device are children of the USB device, this also deletes their
>sysfs folders.
> 
>  - Sometime later, the final stream is closed, invoking uvc_release().
> 
>  - uvc_release() calls uvc_delete()
> 
>  - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
>input device. Because the sysfs directory has already been removed,
>this causes a WARNing.
> 
>  - uvc_delete() calls media_device_unregister(), which cleans up the
>media device. Because the sysfs directory has already been removed,
>this causes another WARNing.
> 
> To fix this, we need to make sure the devices are always unregistered
> before the end of uvc_disconnect(). To this, move the unregistration
> into the disconnect path:
>
>  - split uvc_status_cleanup() into two parts, one on disconnect that
>unregisters and one on delete that frees.
> 
>  - move media_device_unregister() into the disconnect path.

While the patch looks reasonable to me (with one comment below though), isn't 
this an issue with the USB core, or possibly the device core ? It's a common 
practice to create device nodes as children of physical devices. Does the 
device core really require all device nodes to be unregistered synchronously 
with physical device hot-unplug ? If so, shouldn't it warn somehow when a 
device is deleted and still has children, instead of accepting that silently 
and later complaining due to sysfs issues ?

> [0]: https://lkml.org/lkml/2016/12/8/657
> 
> Cc: Laurent Pinchart 
> Cc: Dave Stevenson 
> Cc: Greg KH 
> Signed-off-by: Daniel Axtens 
> 
> ---
> 
> Tested with cheese and yavta.
> ---
>  drivers/media/usb/uvc/uvc_driver.c | 8 ++--
>  drivers/media/usb/uvc/uvc_status.c | 8 ++--
>  drivers/media/usb/uvc/uvcvideo.h   | 1 +
>  3 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 46d6be0bb316..2390592f78e0
> 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1815,8 +1815,6 @@ static void uvc_delete(struct uvc_device *dev)
>   if (dev->vdev.dev)
>   v4l2_device_unregister(>vdev);
>  #ifdef CONFIG_MEDIA_CONTROLLER
> - if (media_devnode_is_registered(dev->mdev.devnode))
> - media_device_unregister(>mdev);

media_device_unregister() will now be called before v4l2_device_unregister() 
which, unless I'm mistaken, will now result in 
media_device_unregister_entity() being called twice for every entity, the 
first time by media_device_unregister(), and the second time by 
v4l2_device_unregister_subdev() through v4l2_device_unregister(). Looking at 
media_device_unregister() I don't think that's safe.

We could move to v4l2_device_unregister() call to uvc_unregister_video(), but 
that worries me (perhaps unnecessarily though) due to the race conditions it 
could introduce. Would you still be able to give it a try ?

Note that your patch isn't really at fault here, the media controller and V4L2 
core code have been broken for a long time when it comes to entity lifetime 
management. That might be fixed some day, 

[PATCH v3 12/12] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Icenowy Zheng]

The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
one provides I/O voltage).

Add device node for it.

Although the Wi-Fi module is an external module which should be inserted
to a header, according to my personal talk with TL Lim, he does not want
this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
other GPIO headers).

Signed-off-by: Icenowy Zheng 
---
Changes in v3:
- Added explaination on 2.0mm pitch.

 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7da074f95065..9d90bb32aa87 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -64,6 +64,11 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+   };
 };
 
  {
@@ -91,6 +96,17 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dldo4>;
+   vqmmc-supply = <_eldo1>;
+   mmc-pwrseq = <_pwrseq>;
+   non-removable;
+   bus-width = <4>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.12.2

[PATCH v3 12/12] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Icenowy Zheng]

The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
one provides I/O voltage).

Add device node for it.

Although the Wi-Fi module is an external module which should be inserted
to a header, according to my personal talk with TL Lim, he does not want
this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
other GPIO headers).

Signed-off-by: Icenowy Zheng 
---
Changes in v3:
- Added explaination on 2.0mm pitch.

 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7da074f95065..9d90bb32aa87 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -64,6 +64,11 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+   };
 };
 
  {
@@ -91,6 +96,17 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dldo4>;
+   vqmmc-supply = <_eldo1>;
+   mmc-pwrseq = <_pwrseq>;
+   non-removable;
+   bus-width = <4>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.12.2

[PATCH v3 11/12] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

Add support of AXP803 regulators in the Pine64 device tree, in order to
enable many future functionalities, e.g. Wi-Fi.

Signed-off-by: Icenowy Zheng 
---
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +
 1 file changed, 109 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 2132d8e6cb3d..7da074f95065 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -106,6 +106,115 @@
};
 };
 
+#include "axp803.dtsi"
+
+_aldo1 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "vcc-csi";
+};
+
+_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-pl";
+};
+
+_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <270>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-pll-avcc";
+};
+
+_dc1sw {
+   regulator-name = "vcc-phy";
+};
+
+_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-3v3";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+_dcdc6 {
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-sys";
+};
+
+_dldo1 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-hdmi";
+};
+
+_dldo2 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-mipi";
+};
+
+_dldo3 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "avdd-csi";
+};
+
+_dldo4 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-wifi";
+};
+
+_eldo1 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "cpvdd";
+};
+
+_eldo3 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "vdd-1v8-csi";
+};
+
+_fldo1 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-name = "vcc-1v2-hsic";
+};
+
+_fldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-cpus";
+};
+
+_rtc_ldo {
+   regulator-name = "vcc-rtc";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.12.2

[PATCH v3 11/12] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

Add support of AXP803 regulators in the Pine64 device tree, in order to
enable many future functionalities, e.g. Wi-Fi.

Signed-off-by: Icenowy Zheng 
---
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +
 1 file changed, 109 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 2132d8e6cb3d..7da074f95065 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -106,6 +106,115 @@
};
 };
 
+#include "axp803.dtsi"
+
+_aldo1 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "vcc-csi";
+};
+
+_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-pl";
+};
+
+_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <270>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-pll-avcc";
+};
+
+_dc1sw {
+   regulator-name = "vcc-phy";
+};
+
+_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-3v3";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+_dcdc6 {
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-sys";
+};
+
+_dldo1 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-hdmi";
+};
+
+_dldo2 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-mipi";
+};
+
+_dldo3 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "avdd-csi";
+};
+
+_dldo4 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-wifi";
+};
+
+_eldo1 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "cpvdd";
+};
+
+_eldo3 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "vdd-1v8-csi";
+};
+
+_fldo1 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-name = "vcc-1v2-hsic";
+};
+
+_fldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-cpus";
+};
+
+_rtc_ldo {
+   regulator-name = "vcc-rtc";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.12.2

[PATCH v3 10/12] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Icenowy Zheng]

As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
like the old DTSI files for AXP20x/22x, for the common parts of the
PMIC.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++
 1 file changed, 150 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi 
b/arch/arm64/boot/dts/allwinner/axp803.dtsi
new file mode 100644
index ..f0e53a7fffbd
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2017 Icenowy Zheng 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP803 Integrated Power Management Chip
+ * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf
+ */
+
+ {
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   regulators {
+   /* Default work frequency for buck regulators */
+   x-powers,dcdc-freq = <3000>;
+
+   reg_dcdc1: dcdc1 {
+   regulator-name = "dcdc1";
+   };
+
+   reg_dcdc2: dcdc2 {
+   regulator-name = "dcdc2";
+   };
+
+   reg_dcdc3: dcdc3 {
+   regulator-name = "dcdc3";
+   };
+
+   reg_dcdc4: dcdc4 {
+   regulator-name = "dcdc4";
+   };
+
+   reg_dcdc5: dcdc5 {
+   regulator-name = "dcdc5";
+   };
+
+   reg_dcdc6: dcdc6 {
+   regulator-name = "dcdc6";
+   };
+
+   reg_dc1sw: dc1sw {
+   regulator-name = "dc1sw";
+   };
+
+   reg_aldo1: aldo1 {
+   regulator-name = "aldo1";
+   };
+
+   reg_aldo2: aldo2 {
+   regulator-name = "aldo2";
+   };
+
+   reg_aldo3: aldo3 {
+   regulator-name = "aldo3";
+   };
+
+   reg_dldo1: dldo1 {
+   regulator-name = "dldo1";
+   };
+
+   reg_dldo2: dldo2 {
+   regulator-name = "dldo2";
+   };
+
+   reg_dldo3: dldo3 {
+   regulator-name = "dldo3";
+   };
+
+   reg_dldo4: dldo4 {
+   regulator-name = "dldo4";
+   };
+
+   reg_eldo1: eldo1 {
+   regulator-name = "eldo1";
+   };
+
+   reg_eldo2: eldo2 {
+   regulator-name = "eldo2";
+   };
+
+   reg_eldo3: eldo3 {
+   regulator-name = "eldo3";
+   };
+
+   reg_fldo1: fldo1 {
+   regulator-name = "fldo1";
+   };
+
+   reg_fldo2: fldo2 {
+   regulator-name = "fldo2";
+   };
+
+ 

[PATCH v3 10/12] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Icenowy Zheng]

As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
like the old DTSI files for AXP20x/22x, for the common parts of the
PMIC.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++
 1 file changed, 150 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi 
b/arch/arm64/boot/dts/allwinner/axp803.dtsi
new file mode 100644
index ..f0e53a7fffbd
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2017 Icenowy Zheng 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP803 Integrated Power Management Chip
+ * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf
+ */
+
+ {
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   regulators {
+   /* Default work frequency for buck regulators */
+   x-powers,dcdc-freq = <3000>;
+
+   reg_dcdc1: dcdc1 {
+   regulator-name = "dcdc1";
+   };
+
+   reg_dcdc2: dcdc2 {
+   regulator-name = "dcdc2";
+   };
+
+   reg_dcdc3: dcdc3 {
+   regulator-name = "dcdc3";
+   };
+
+   reg_dcdc4: dcdc4 {
+   regulator-name = "dcdc4";
+   };
+
+   reg_dcdc5: dcdc5 {
+   regulator-name = "dcdc5";
+   };
+
+   reg_dcdc6: dcdc6 {
+   regulator-name = "dcdc6";
+   };
+
+   reg_dc1sw: dc1sw {
+   regulator-name = "dc1sw";
+   };
+
+   reg_aldo1: aldo1 {
+   regulator-name = "aldo1";
+   };
+
+   reg_aldo2: aldo2 {
+   regulator-name = "aldo2";
+   };
+
+   reg_aldo3: aldo3 {
+   regulator-name = "aldo3";
+   };
+
+   reg_dldo1: dldo1 {
+   regulator-name = "dldo1";
+   };
+
+   reg_dldo2: dldo2 {
+   regulator-name = "dldo2";
+   };
+
+   reg_dldo3: dldo3 {
+   regulator-name = "dldo3";
+   };
+
+   reg_dldo4: dldo4 {
+   regulator-name = "dldo4";
+   };
+
+   reg_eldo1: eldo1 {
+   regulator-name = "eldo1";
+   };
+
+   reg_eldo2: eldo2 {
+   regulator-name = "eldo2";
+   };
+
+   reg_eldo3: eldo3 {
+   regulator-name = "eldo3";
+   };
+
+   reg_fldo1: fldo1 {
+   regulator-name = "fldo1";
+   };
+
+   reg_fldo2: fldo2 {
+   regulator-name = "fldo2";
+   };
+
+   reg_ldo_io0: ldo_io0 {
+ 

[PATCH v3 09/12] mfd: axp20x: add axp20x-regulator cell for AXP803

[Icenowy Zheng]

As axp20x-regulator now supports AXP803, add a cell for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v3:
- Make the new cell one-liner.

 drivers/mfd/axp20x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 1dc6235778eb..431b7f118606 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
.name   = "axp20x-pek",
.num_resources  = ARRAY_SIZE(axp803_pek_resources),
.resources  = axp803_pek_resources,
-   }
+   },
+   {   .name   = "axp20x-regulator" }
 };
 
 static struct mfd_cell axp806_cells[] = {
-- 
2.12.2

[PATCH v3 09/12] mfd: axp20x: add axp20x-regulator cell for AXP803

[Icenowy Zheng]

As axp20x-regulator now supports AXP803, add a cell for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v3:
- Make the new cell one-liner.

 drivers/mfd/axp20x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 1dc6235778eb..431b7f118606 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
.name   = "axp20x-pek",
.num_resources  = ARRAY_SIZE(axp803_pek_resources),
.resources  = axp803_pek_resources,
-   }
+   },
+   {   .name   = "axp20x-regulator" }
 };
 
 static struct mfd_cell axp806_cells[] = {
-- 
2.12.2

[PATCH v3 08/12] regulator: axp20x-regulator: add support for AXP803

[Icenowy Zheng]

AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
controllable via I2C/RSB bus.

Add support for them.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Place AXP803 codes before AXP806/809 ones.
- Fixed some errors in regulator description.
- Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.

 drivers/regulator/axp20x-regulator.c | 153 ++-
 include/linux/mfd/axp20x.h   |  37 +
 2 files changed, 168 insertions(+), 22 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 0b9d4e3e52c7..2ed15e4a7a82 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,82 @@ static const struct regulator_desc 
axp22x_drivevbus_regulator = {
.ops= _ops_sw,
 };
 
+static const struct regulator_linear_range axp803_dcdc234_ranges[] = {
+   REGULATOR_LINEAR_RANGE(50, 0x0, 0x46, 1),
+   REGULATOR_LINEAR_RANGE(122, 0x47, 0x4b, 2),
+};
+
+static const struct regulator_linear_range axp803_dcdc5_ranges[] = {
+   REGULATOR_LINEAR_RANGE(80, 0x0, 0x20, 1),
+   REGULATOR_LINEAR_RANGE(114, 0x21, 0x44, 2),
+};
+
+static const struct regulator_linear_range axp803_dcdc6_ranges[] = {
+   REGULATOR_LINEAR_RANGE(60, 0x0, 0x32, 1),
+   REGULATOR_LINEAR_RANGE(112, 0x33, 0x47, 2),
+};
+
+/* AXP806's CLDO2 and AXP809's DLDO1 shares the same range */
+static const struct regulator_linear_range axp803_dldo2_ranges[] = {
+   REGULATOR_LINEAR_RANGE(70, 0x0, 0x1a, 10),
+   REGULATOR_LINEAR_RANGE(340, 0x1b, 0x1f, 20),
+};
+
+static const struct regulator_desc axp803_regulators[] = {
+   AXP_DESC(AXP803, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+AXP803_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+   AXP_DESC_RANGES(AXP803, DCDC2, "dcdc2", "vin2", axp803_dcdc234_ranges,
+   76, AXP803_DCDC2_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(1)),
+   AXP_DESC_RANGES(AXP803, DCDC3, "dcdc3", "vin3", axp803_dcdc234_ranges,
+   76, AXP803_DCDC3_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(2)),
+   AXP_DESC_RANGES(AXP803, DCDC4, "dcdc4", "vin4", axp803_dcdc234_ranges,
+   76, AXP803_DCDC4_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(3)),
+   AXP_DESC_RANGES(AXP803, DCDC5, "dcdc5", "vin5", axp803_dcdc5_ranges,
+   68, AXP803_DCDC5_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(4)),
+   AXP_DESC_RANGES(AXP803, DCDC6, "dcdc6", "vin6", axp803_dcdc6_ranges,
+   72, AXP803_DCDC6_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(5)),
+   /* secondary switchable output of DCDC1 */
+   AXP_DESC_SW(AXP803, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+   BIT(7)),
+   AXP_DESC(AXP803, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(5)),
+   AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(6)),
+   AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(7)),
+   AXP_DESC(AXP803, DLDO1, "dldo1", "dldoin", 700, 3300, 100,
+AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(3)),
+   AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin", axp803_dldo2_ranges,
+   32, AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+   BIT(4)),
+   AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
+AXP22X_DLDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+   AXP_DESC(AXP803, DLDO4, "dldo4", "dldoin", 700, 3300, 100,
+AXP22X_DLDO4_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(6)),
+   AXP_DESC(AXP803, ELDO1, "eldo1", "eldoin", 700, 1900, 50,
+AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+   AXP_DESC(AXP803, ELDO2, "eldo2", "eldoin", 700, 1900, 50,
+AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+   AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
+AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+   AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
+AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
+   AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
+AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
+   AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+   AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+   AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+   AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 

[PATCH v3 08/12] regulator: axp20x-regulator: add support for AXP803

[Icenowy Zheng]

AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
controllable via I2C/RSB bus.

Add support for them.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Place AXP803 codes before AXP806/809 ones.
- Fixed some errors in regulator description.
- Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.

 drivers/regulator/axp20x-regulator.c | 153 ++-
 include/linux/mfd/axp20x.h   |  37 +
 2 files changed, 168 insertions(+), 22 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 0b9d4e3e52c7..2ed15e4a7a82 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,82 @@ static const struct regulator_desc 
axp22x_drivevbus_regulator = {
.ops= _ops_sw,
 };
 
+static const struct regulator_linear_range axp803_dcdc234_ranges[] = {
+   REGULATOR_LINEAR_RANGE(50, 0x0, 0x46, 1),
+   REGULATOR_LINEAR_RANGE(122, 0x47, 0x4b, 2),
+};
+
+static const struct regulator_linear_range axp803_dcdc5_ranges[] = {
+   REGULATOR_LINEAR_RANGE(80, 0x0, 0x20, 1),
+   REGULATOR_LINEAR_RANGE(114, 0x21, 0x44, 2),
+};
+
+static const struct regulator_linear_range axp803_dcdc6_ranges[] = {
+   REGULATOR_LINEAR_RANGE(60, 0x0, 0x32, 1),
+   REGULATOR_LINEAR_RANGE(112, 0x33, 0x47, 2),
+};
+
+/* AXP806's CLDO2 and AXP809's DLDO1 shares the same range */
+static const struct regulator_linear_range axp803_dldo2_ranges[] = {
+   REGULATOR_LINEAR_RANGE(70, 0x0, 0x1a, 10),
+   REGULATOR_LINEAR_RANGE(340, 0x1b, 0x1f, 20),
+};
+
+static const struct regulator_desc axp803_regulators[] = {
+   AXP_DESC(AXP803, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+AXP803_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+   AXP_DESC_RANGES(AXP803, DCDC2, "dcdc2", "vin2", axp803_dcdc234_ranges,
+   76, AXP803_DCDC2_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(1)),
+   AXP_DESC_RANGES(AXP803, DCDC3, "dcdc3", "vin3", axp803_dcdc234_ranges,
+   76, AXP803_DCDC3_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(2)),
+   AXP_DESC_RANGES(AXP803, DCDC4, "dcdc4", "vin4", axp803_dcdc234_ranges,
+   76, AXP803_DCDC4_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(3)),
+   AXP_DESC_RANGES(AXP803, DCDC5, "dcdc5", "vin5", axp803_dcdc5_ranges,
+   68, AXP803_DCDC5_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(4)),
+   AXP_DESC_RANGES(AXP803, DCDC6, "dcdc6", "vin6", axp803_dcdc6_ranges,
+   72, AXP803_DCDC6_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+   BIT(5)),
+   /* secondary switchable output of DCDC1 */
+   AXP_DESC_SW(AXP803, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+   BIT(7)),
+   AXP_DESC(AXP803, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(5)),
+   AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(6)),
+   AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(7)),
+   AXP_DESC(AXP803, DLDO1, "dldo1", "dldoin", 700, 3300, 100,
+AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(3)),
+   AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin", axp803_dldo2_ranges,
+   32, AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+   BIT(4)),
+   AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
+AXP22X_DLDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+   AXP_DESC(AXP803, DLDO4, "dldo4", "dldoin", 700, 3300, 100,
+AXP22X_DLDO4_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(6)),
+   AXP_DESC(AXP803, ELDO1, "eldo1", "eldoin", 700, 1900, 50,
+AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+   AXP_DESC(AXP803, ELDO2, "eldo2", "eldoin", 700, 1900, 50,
+AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+   AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
+AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+   AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
+AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
+   AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
+AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
+   AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+   AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+   AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+   AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
+

[PATCH v3 07/12] dt-bindings: add AXP803's regulator info

[Icenowy Zheng]

AXP803 have the most regulators in currently supported AXP PMICs.

Add info for the regulators in the dt-bindings document.

Signed-off-by: Icenowy Zheng 
Acked-by: Rob Herring 
---
Changes in v3:
- Added Rob's ACK.
Changes in v2:
- Place AXP803 regulators before AXP806/809 ones.

 Documentation/devicetree/bindings/mfd/axp20x.txt | 27 
 1 file changed, 27 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 44df88be3c89..aca09af66514 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -96,6 +96,33 @@ LDO_IO1  : LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
 
+AXP803 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDC1  : DC-DC buck: vin1-supply
+DCDC2  : DC-DC buck: vin2-supply   : poly-phase capable
+DCDC3  : DC-DC buck: vin3-supply   : poly-phase capable
+DCDC4  : DC-DC buck: vin4-supply
+DCDC5  : DC-DC buck: vin5-supply   : poly-phase capable
+DCDC6  : DC-DC buck: vin6-supply   : poly-phase capable
+DC1SW  : On/Off Switch :   : DCDC1 secondary output
+ALDO1  : LDO   : aldoin-supply : shared supply
+ALDO2  : LDO   : aldoin-supply : shared supply
+ALDO3  : LDO   : aldoin-supply : shared supply
+DLDO1  : LDO   : dldoin-supply : shared supply
+DLDO2  : LDO   : dldoin-supply : shared supply
+DLDO3  : LDO   : dldoin-supply : shared supply
+DLDO4  : LDO   : dldoin-supply : shared supply
+ELDO1  : LDO   : eldoin-supply : shared supply
+ELDO2  : LDO   : eldoin-supply : shared supply
+ELDO3  : LDO   : eldoin-supply : shared supply
+FLDO1  : LDO   : fldoin-supply : shared supply
+FLDO2  : LDO   : fldoin-supply : shared supply
+LDO_IO0: LDO   : ips-supply: GPIO 0
+LDO_IO1: LDO   : ips-supply: GPIO 1
+RTC_LDO: LDO   : ips-supply: always on
+
 AXP806 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
-- 
2.12.2

[PATCH v3 07/12] dt-bindings: add AXP803's regulator info

[Icenowy Zheng]

AXP803 have the most regulators in currently supported AXP PMICs.

Add info for the regulators in the dt-bindings document.

Signed-off-by: Icenowy Zheng 
Acked-by: Rob Herring 
---
Changes in v3:
- Added Rob's ACK.
Changes in v2:
- Place AXP803 regulators before AXP806/809 ones.

 Documentation/devicetree/bindings/mfd/axp20x.txt | 27 
 1 file changed, 27 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 44df88be3c89..aca09af66514 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -96,6 +96,33 @@ LDO_IO1  : LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
 
+AXP803 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDC1  : DC-DC buck: vin1-supply
+DCDC2  : DC-DC buck: vin2-supply   : poly-phase capable
+DCDC3  : DC-DC buck: vin3-supply   : poly-phase capable
+DCDC4  : DC-DC buck: vin4-supply
+DCDC5  : DC-DC buck: vin5-supply   : poly-phase capable
+DCDC6  : DC-DC buck: vin6-supply   : poly-phase capable
+DC1SW  : On/Off Switch :   : DCDC1 secondary output
+ALDO1  : LDO   : aldoin-supply : shared supply
+ALDO2  : LDO   : aldoin-supply : shared supply
+ALDO3  : LDO   : aldoin-supply : shared supply
+DLDO1  : LDO   : dldoin-supply : shared supply
+DLDO2  : LDO   : dldoin-supply : shared supply
+DLDO3  : LDO   : dldoin-supply : shared supply
+DLDO4  : LDO   : dldoin-supply : shared supply
+ELDO1  : LDO   : eldoin-supply : shared supply
+ELDO2  : LDO   : eldoin-supply : shared supply
+ELDO3  : LDO   : eldoin-supply : shared supply
+FLDO1  : LDO   : fldoin-supply : shared supply
+FLDO2  : LDO   : fldoin-supply : shared supply
+LDO_IO0: LDO   : ips-supply: GPIO 0
+LDO_IO1: LDO   : ips-supply: GPIO 1
+RTC_LDO: LDO   : ips-supply: always on
+
 AXP806 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
-- 
2.12.2

[PATCH v3 05/12] mfd: axp20x: support AXP803 variant

[Icenowy Zheng]

AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64
via RSB bus. The PMIC itself is like AXP288, but with RSB support and
dedicated VBUS and ACIN.

Add support for it in the axp20x mfd driver.

Currently only power key function is supported.

Signed-off-by: Icenowy Zheng 
---
This patch is said to be applied by Lee Jones, however, I didn't see it
in the linux-next, so I included it in the patchset now.

Changes in v2:
- Share regmap configs with AXP288.
- Place AXP803 bits before AXP806/809.

 drivers/mfd/axp20x-rsb.c   |  1 +
 drivers/mfd/axp20x.c   | 79 ++
 include/linux/mfd/axp20x.h | 40 ++-
 3 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index a732cb50bcff..fd5c7267b136 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
 
 static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+   { .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
{ .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
{ },
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index e6f55079876e..1dc6235778eb 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
"AXP221",
"AXP223",
"AXP288",
+   "AXP803",
"AXP806",
"AXP809",
 };
@@ -117,6 +118,7 @@ static const struct regmap_access_table 
axp22x_volatile_table = {
.n_yes_ranges   = ARRAY_SIZE(axp22x_volatile_ranges),
 };
 
+/* AXP288 ranges are shared with the AXP803, as they cover the same range */
 static const struct regmap_range axp288_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
@@ -264,6 +266,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
},
 };
 
+static struct resource axp803_pek_resources[] = {
+   {
+   .name   = "PEK_DBR",
+   .start  = AXP803_IRQ_PEK_RIS_EDGE,
+   .end= AXP803_IRQ_PEK_RIS_EDGE,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = "PEK_DBF",
+   .start  = AXP803_IRQ_PEK_FAL_EDGE,
+   .end= AXP803_IRQ_PEK_FAL_EDGE,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
 static struct resource axp809_pek_resources[] = {
{
.name   = "PEK_DBR",
@@ -457,6 +473,43 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,5, 1),
 };
 
+static const struct regmap_irq axp803_regmap_irqs[] = {
+   INIT_REGMAP_IRQ(AXP803, ACIN_OVER_V,0, 7),
+   INIT_REGMAP_IRQ(AXP803, ACIN_PLUGIN,0, 6),
+   INIT_REGMAP_IRQ(AXP803, ACIN_REMOVAL,   0, 5),
+   INIT_REGMAP_IRQ(AXP803, VBUS_OVER_V,0, 4),
+   INIT_REGMAP_IRQ(AXP803, VBUS_PLUGIN,0, 3),
+   INIT_REGMAP_IRQ(AXP803, VBUS_REMOVAL,   0, 2),
+   INIT_REGMAP_IRQ(AXP803, BATT_PLUGIN,1, 7),
+   INIT_REGMAP_IRQ(AXP803, BATT_REMOVAL,   1, 6),
+   INIT_REGMAP_IRQ(AXP803, BATT_ENT_ACT_MODE,  1, 5),
+   INIT_REGMAP_IRQ(AXP803, BATT_EXIT_ACT_MODE, 1, 4),
+   INIT_REGMAP_IRQ(AXP803, CHARG,  1, 3),
+   INIT_REGMAP_IRQ(AXP803, CHARG_DONE, 1, 2),
+   INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH, 2, 7),
+   INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH_END, 2, 6),
+   INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW,  2, 5),
+   INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW_END,  2, 4),
+   INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH, 2, 3),
+   INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH_END, 2, 2),
+   INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW,  2, 1),
+   INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW_END,  2, 0),
+   INIT_REGMAP_IRQ(AXP803, DIE_TEMP_HIGH,  3, 7),
+   INIT_REGMAP_IRQ(AXP803, GPADC,  3, 2),
+   INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL1,   3, 1),
+   INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL2,   3, 0),
+   INIT_REGMAP_IRQ(AXP803, TIMER,  4, 7),
+   INIT_REGMAP_IRQ(AXP803, PEK_RIS_EDGE,   4, 6),
+   INIT_REGMAP_IRQ(AXP803, PEK_FAL_EDGE,   4, 5),
+   INIT_REGMAP_IRQ(AXP803, PEK_SHORT,  4, 4),
+   INIT_REGMAP_IRQ(AXP803, PEK_LONG,   4, 3),
+   INIT_REGMAP_IRQ(AXP803, PEK_OVER_OFF,   4, 2),
+   INIT_REGMAP_IRQ(AXP803, GPIO1_INPUT,4, 1),
+   INIT_REGMAP_IRQ(AXP803, GPIO0_INPUT,4, 0),
+   

[PATCH v3 06/12] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.

Add its device node.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index c680ed385da3..2132d8e6cb3d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -95,6 +95,17 @@
status = "okay";
 };
 
+_rsb {
+   status = "okay";
+
+   axp803: pmic@3a3 {
+   compatible = "x-powers,axp803";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.12.2

[PATCH v3 05/12] mfd: axp20x: support AXP803 variant

[Icenowy Zheng]

AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64
via RSB bus. The PMIC itself is like AXP288, but with RSB support and
dedicated VBUS and ACIN.

Add support for it in the axp20x mfd driver.

Currently only power key function is supported.

Signed-off-by: Icenowy Zheng 
---
This patch is said to be applied by Lee Jones, however, I didn't see it
in the linux-next, so I included it in the patchset now.

Changes in v2:
- Share regmap configs with AXP288.
- Place AXP803 bits before AXP806/809.

 drivers/mfd/axp20x-rsb.c   |  1 +
 drivers/mfd/axp20x.c   | 79 ++
 include/linux/mfd/axp20x.h | 40 ++-
 3 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index a732cb50bcff..fd5c7267b136 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
 
 static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+   { .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
{ .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
{ },
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index e6f55079876e..1dc6235778eb 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
"AXP221",
"AXP223",
"AXP288",
+   "AXP803",
"AXP806",
"AXP809",
 };
@@ -117,6 +118,7 @@ static const struct regmap_access_table 
axp22x_volatile_table = {
.n_yes_ranges   = ARRAY_SIZE(axp22x_volatile_ranges),
 };
 
+/* AXP288 ranges are shared with the AXP803, as they cover the same range */
 static const struct regmap_range axp288_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
@@ -264,6 +266,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
},
 };
 
+static struct resource axp803_pek_resources[] = {
+   {
+   .name   = "PEK_DBR",
+   .start  = AXP803_IRQ_PEK_RIS_EDGE,
+   .end= AXP803_IRQ_PEK_RIS_EDGE,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = "PEK_DBF",
+   .start  = AXP803_IRQ_PEK_FAL_EDGE,
+   .end= AXP803_IRQ_PEK_FAL_EDGE,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
 static struct resource axp809_pek_resources[] = {
{
.name   = "PEK_DBR",
@@ -457,6 +473,43 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,5, 1),
 };
 
+static const struct regmap_irq axp803_regmap_irqs[] = {
+   INIT_REGMAP_IRQ(AXP803, ACIN_OVER_V,0, 7),
+   INIT_REGMAP_IRQ(AXP803, ACIN_PLUGIN,0, 6),
+   INIT_REGMAP_IRQ(AXP803, ACIN_REMOVAL,   0, 5),
+   INIT_REGMAP_IRQ(AXP803, VBUS_OVER_V,0, 4),
+   INIT_REGMAP_IRQ(AXP803, VBUS_PLUGIN,0, 3),
+   INIT_REGMAP_IRQ(AXP803, VBUS_REMOVAL,   0, 2),
+   INIT_REGMAP_IRQ(AXP803, BATT_PLUGIN,1, 7),
+   INIT_REGMAP_IRQ(AXP803, BATT_REMOVAL,   1, 6),
+   INIT_REGMAP_IRQ(AXP803, BATT_ENT_ACT_MODE,  1, 5),
+   INIT_REGMAP_IRQ(AXP803, BATT_EXIT_ACT_MODE, 1, 4),
+   INIT_REGMAP_IRQ(AXP803, CHARG,  1, 3),
+   INIT_REGMAP_IRQ(AXP803, CHARG_DONE, 1, 2),
+   INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH, 2, 7),
+   INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH_END, 2, 6),
+   INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW,  2, 5),
+   INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW_END,  2, 4),
+   INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH, 2, 3),
+   INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH_END, 2, 2),
+   INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW,  2, 1),
+   INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW_END,  2, 0),
+   INIT_REGMAP_IRQ(AXP803, DIE_TEMP_HIGH,  3, 7),
+   INIT_REGMAP_IRQ(AXP803, GPADC,  3, 2),
+   INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL1,   3, 1),
+   INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL2,   3, 0),
+   INIT_REGMAP_IRQ(AXP803, TIMER,  4, 7),
+   INIT_REGMAP_IRQ(AXP803, PEK_RIS_EDGE,   4, 6),
+   INIT_REGMAP_IRQ(AXP803, PEK_FAL_EDGE,   4, 5),
+   INIT_REGMAP_IRQ(AXP803, PEK_SHORT,  4, 4),
+   INIT_REGMAP_IRQ(AXP803, PEK_LONG,   4, 3),
+   INIT_REGMAP_IRQ(AXP803, PEK_OVER_OFF,   4, 2),
+   INIT_REGMAP_IRQ(AXP803, GPIO1_INPUT,4, 1),
+   INIT_REGMAP_IRQ(AXP803, GPIO0_INPUT,4, 0),
+   

[PATCH v3 06/12] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.

Add its device node.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index c680ed385da3..2132d8e6cb3d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -95,6 +95,17 @@
status = "okay";
 };
 
+_rsb {
+   status = "okay";
+
+   axp803: pmic@3a3 {
+   compatible = "x-powers,axp803";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.12.2

[PATCH v3 04/12] dt-bindings: add device tree binding for X-Powers AXP803 PMIC

[Icenowy Zheng]

AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
bus.

Add a compatible for it.

Signed-off-by: Icenowy Zheng 
Acked-by: Chen-Yu Tsai 
Acked-by: Rob Herring 
---
Changes in v3:
- Make the compatible one-liner.
Changes in v2:
- Place AXP803 before AXP806/809.
- Added Chen-Yu's ACK.

 Documentation/devicetree/bindings/mfd/axp20x.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index a3e813f6060a..44df88be3c89 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -6,6 +6,7 @@ axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (X-Powers)
+axp803 (X-Powers)
 axp809 (X-Powers)
 
 Required properties:
@@ -15,6 +16,7 @@ Required properties:
 * "x-powers,axp209"
 * "x-powers,axp221"
 * "x-powers,axp223"
+* "x-powers,axp803"
 * "x-powers,axp806"
 * "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
-- 
2.12.2

[PATCH v3 04/12] dt-bindings: add device tree binding for X-Powers AXP803 PMIC

[Icenowy Zheng]

AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
bus.

Add a compatible for it.

Signed-off-by: Icenowy Zheng 
Acked-by: Chen-Yu Tsai 
Acked-by: Rob Herring 
---
Changes in v3:
- Make the compatible one-liner.
Changes in v2:
- Place AXP803 before AXP806/809.
- Added Chen-Yu's ACK.

 Documentation/devicetree/bindings/mfd/axp20x.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index a3e813f6060a..44df88be3c89 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -6,6 +6,7 @@ axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (X-Powers)
+axp803 (X-Powers)
 axp809 (X-Powers)
 
 Required properties:
@@ -15,6 +16,7 @@ Required properties:
 * "x-powers,axp209"
 * "x-powers,axp221"
 * "x-powers,axp223"
+* "x-powers,axp803"
 * "x-powers,axp806"
 * "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
-- 
2.12.2

[PATCH v3 03/12] dt-bindings: make AXP20X compatible strings one per line

[Icenowy Zheng]

In the binding documentation of AXP20X mfd, the compatible strings used
to be listed for three per line, which leads to some mess when trying to
add AXP803 compatible string (as we have already AXP806 and AXP809
compatibles, which is after AXP803 in ascending order).

Make the compatible strings one per line, so that inserting a new
compatible string will be directly a new line.

Signed-off-by: Icenowy Zheng 
---
New patch in v3.

 Documentation/devicetree/bindings/mfd/axp20x.txt | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index b41d2601c6ba..a3e813f6060a 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -9,9 +9,14 @@ axp223 (X-Powers)
 axp809 (X-Powers)
 
 Required properties:
-- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
- "x-powers,axp809"
+- compatible: should be one of:
+* "x-powers,axp152"
+* "x-powers,axp202"
+* "x-powers,axp209"
+* "x-powers,axp221"
+* "x-powers,axp223"
+* "x-powers,axp806"
+* "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
-- 
2.12.2

[PATCH v3 03/12] dt-bindings: make AXP20X compatible strings one per line

[Icenowy Zheng]

In the binding documentation of AXP20X mfd, the compatible strings used
to be listed for three per line, which leads to some mess when trying to
add AXP803 compatible string (as we have already AXP806 and AXP809
compatibles, which is after AXP803 in ascending order).

Make the compatible strings one per line, so that inserting a new
compatible string will be directly a new line.

Signed-off-by: Icenowy Zheng 
---
New patch in v3.

 Documentation/devicetree/bindings/mfd/axp20x.txt | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index b41d2601c6ba..a3e813f6060a 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -9,9 +9,14 @@ axp223 (X-Powers)
 axp809 (X-Powers)
 
 Required properties:
-- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
- "x-powers,axp809"
+- compatible: should be one of:
+* "x-powers,axp152"
+* "x-powers,axp202"
+* "x-powers,axp209"
+* "x-powers,axp221"
+* "x-powers,axp223"
+* "x-powers,axp806"
+* "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
-- 
2.12.2

[PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64

[Icenowy Zheng]

Allwinner A64 SoC features a NMI controller, which is usually connected
to the AXP PMIC.

Add support for it.

Signed-off-by: Icenowy Zheng 
Acked-by: Chen-Yu Tsai 
---
Changes in v2:
- Added Chen-Yu's ACK.

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 05ec9fc5e81f..53c18ca372ea 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -403,6 +403,14 @@
 ;
};
 
+   nmi_intc: interrupt-controller@01f00c0c {
+   compatible = "allwinner,sun6i-a31-sc-nmi";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x01f00c0c 0x38>;
+   interrupts = ;
+   };
+
r_ccu: clock@1f01400 {
compatible = "allwinner,sun50i-a64-r-ccu";
reg = <0x01f01400 0x100>;
-- 
2.12.2

[PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64

[Icenowy Zheng]

Allwinner A64 SoC features a NMI controller, which is usually connected
to the AXP PMIC.

Add support for it.

Signed-off-by: Icenowy Zheng 
Acked-by: Chen-Yu Tsai 
---
Changes in v2:
- Added Chen-Yu's ACK.

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 05ec9fc5e81f..53c18ca372ea 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -403,6 +403,14 @@
 ;
};
 
+   nmi_intc: interrupt-controller@01f00c0c {
+   compatible = "allwinner,sun6i-a31-sc-nmi";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x01f00c0c 0x38>;
+   interrupts = ;
+   };
+
r_ccu: clock@1f01400 {
compatible = "allwinner,sun50i-a64-r-ccu";
reg = <0x01f01400 0x100>;
-- 
2.12.2

[PATCH v3 01/12] arm64: allwinner: a64: enable RSB on A64

[Icenowy Zheng]

Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.

Add it and its pinmux.

Signed-off-by: Icenowy Zheng 
Acked-by: Chen-Yu Tsai 
---
Changes in v2:
- Removed bonus properties in pio node.
- Added Chen-Yu's ACK.

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index c7f669f5884f..05ec9fc5e81f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -422,6 +422,25 @@
#gpio-cells = <3>;
interrupt-controller;
#interrupt-cells = <3>;
+
+   r_rsb_pins: rsb@0 {
+   pins = "PL0", "PL1";
+   function = "s_rsb";
+   };
+   };
+
+   r_rsb: rsb@1f03400 {
+   compatible = "allwinner,sun8i-a23-rsb";
+   reg = <0x01f03400 0x400>;
+   interrupts = ;
+   clocks = <_ccu 6>;
+   clock-frequency = <300>;
+   resets = <_ccu 2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rsb_pins>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
};
};
 };
-- 
2.12.2

[PATCH v3 01/12] arm64: allwinner: a64: enable RSB on A64

[Icenowy Zheng]

Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.

Add it and its pinmux.

Signed-off-by: Icenowy Zheng 
Acked-by: Chen-Yu Tsai 
---
Changes in v2:
- Removed bonus properties in pio node.
- Added Chen-Yu's ACK.

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index c7f669f5884f..05ec9fc5e81f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -422,6 +422,25 @@
#gpio-cells = <3>;
interrupt-controller;
#interrupt-cells = <3>;
+
+   r_rsb_pins: rsb@0 {
+   pins = "PL0", "PL1";
+   function = "s_rsb";
+   };
+   };
+
+   r_rsb: rsb@1f03400 {
+   compatible = "allwinner,sun8i-a23-rsb";
+   reg = <0x01f03400 0x400>;
+   interrupts = ;
+   clocks = <_ccu 6>;
+   clock-frequency = <300>;
+   resets = <_ccu 2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rsb_pins>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
};
};
 };
-- 
2.12.2

[PATCH v3 00/12] AXP803 PMIC support for Pine64

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).

This patchset adds support for it and enabled it in Pine64 device tree.

This patchset can be splitted into two big parts:

- Part1: PATCH 1/11 to PATCH 6/12, which are enabling the MFD (and the
  power key functionality) of AXP803.

- Part2: PATCH 7/12 to PATCH 12/12, which are enabling the regulator
  function of the AXP803 PMIC. Finally Wi-Fi function is added
  as a usage of regulators function.

PATCH 1 and 2 added RSB and NMI device nodes, which are used for the
communication between A64 and AXP803.

PATCH 3 re-arranged the compatible strings in AXP20x device tree binding,
for easier insertion of AXP803 compatible. This is based on the suggestion
by device tree maintainer Rob Herring.

PATCH 4 adds basical devicetree binding for AXP803.

PATCH 5 adds support for the AXP803 variant in axp20x-rsb mfd driver. It's
said to be applied already by Lee Jones, but I didn't see it in linux-next
now, so it's kept in this series.

PATCH 6 enabled the AXP803 MFD in Pine64 device tree.

PATCH 7 adds devicetree binding for the regulators in AXP803.

PATCH 8 adds support for the regulators in AXP803 in the axp20x-regulator
driver.

PATCH 9 enabled the regulator MFD cell in AXP803.

PATCH 10 adds a DTSI file for AXP803, just like what have been done for other
AXPs.

PATCH 11 enabled the regulators on Pine64.

PATCH 12 enabled Wi-Fi support on Pine64, which required DLDO4 and ELDO1
regulators.

Icenowy Zheng (12):
  arm64: allwinner: a64: enable RSB on A64
  arm64: allwinner: a64: add NMI controller on A64
  dt-bindings: make AXP20X compatible strings one per line
  dt-bindings: add device tree binding for X-Powers AXP803 PMIC
  mfd: axp20x: support AXP803 variant
  arm64: allwinner: a64: add AXP803 node to Pine64 device tree
  dt-bindings: add AXP803's regulator info
  regulator: axp20x-regulator: add support for AXP803
  mfd: axp20x: add axp20x-regulator cell for AXP803
  arm64: allwinner: a64: add DTSI file for AXP803 PMIC
  arm64: allwinner: a64: enable AXP803 regulators for Pine64
  arm64: allwinner: a64: enable Wi-Fi for Pine64

 Documentation/devicetree/bindings/mfd/axp20x.txt   |  40 +-
 arch/arm64/boot/dts/allwinner/axp803.dtsi  | 150 
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  |  27 
 drivers/mfd/axp20x-rsb.c   |   1 +
 drivers/mfd/axp20x.c   |  80 +++
 drivers/regulator/axp20x-regulator.c   | 153 ++---
 include/linux/mfd/axp20x.h |  77 ++-
 8 files changed, 638 insertions(+), 26 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

-- 
2.12.2

[PATCH v3 00/12] AXP803 PMIC support for Pine64

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).

This patchset adds support for it and enabled it in Pine64 device tree.

This patchset can be splitted into two big parts:

- Part1: PATCH 1/11 to PATCH 6/12, which are enabling the MFD (and the
  power key functionality) of AXP803.

- Part2: PATCH 7/12 to PATCH 12/12, which are enabling the regulator
  function of the AXP803 PMIC. Finally Wi-Fi function is added
  as a usage of regulators function.

PATCH 1 and 2 added RSB and NMI device nodes, which are used for the
communication between A64 and AXP803.

PATCH 3 re-arranged the compatible strings in AXP20x device tree binding,
for easier insertion of AXP803 compatible. This is based on the suggestion
by device tree maintainer Rob Herring.

PATCH 4 adds basical devicetree binding for AXP803.

PATCH 5 adds support for the AXP803 variant in axp20x-rsb mfd driver. It's
said to be applied already by Lee Jones, but I didn't see it in linux-next
now, so it's kept in this series.

PATCH 6 enabled the AXP803 MFD in Pine64 device tree.

PATCH 7 adds devicetree binding for the regulators in AXP803.

PATCH 8 adds support for the regulators in AXP803 in the axp20x-regulator
driver.

PATCH 9 enabled the regulator MFD cell in AXP803.

PATCH 10 adds a DTSI file for AXP803, just like what have been done for other
AXPs.

PATCH 11 enabled the regulators on Pine64.

PATCH 12 enabled Wi-Fi support on Pine64, which required DLDO4 and ELDO1
regulators.

Icenowy Zheng (12):
  arm64: allwinner: a64: enable RSB on A64
  arm64: allwinner: a64: add NMI controller on A64
  dt-bindings: make AXP20X compatible strings one per line
  dt-bindings: add device tree binding for X-Powers AXP803 PMIC
  mfd: axp20x: support AXP803 variant
  arm64: allwinner: a64: add AXP803 node to Pine64 device tree
  dt-bindings: add AXP803's regulator info
  regulator: axp20x-regulator: add support for AXP803
  mfd: axp20x: add axp20x-regulator cell for AXP803
  arm64: allwinner: a64: add DTSI file for AXP803 PMIC
  arm64: allwinner: a64: enable AXP803 regulators for Pine64
  arm64: allwinner: a64: enable Wi-Fi for Pine64

 Documentation/devicetree/bindings/mfd/axp20x.txt   |  40 +-
 arch/arm64/boot/dts/allwinner/axp803.dtsi  | 150 
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  |  27 
 drivers/mfd/axp20x-rsb.c   |   1 +
 drivers/mfd/axp20x.c   |  80 +++
 drivers/regulator/axp20x-regulator.c   | 153 ++---
 include/linux/mfd/axp20x.h |  77 ++-
 8 files changed, 638 insertions(+), 26 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

-- 
2.12.2

[PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed

[sunil . kovvuri]

From: Sunil Goutham 

For software initiated address translation, when domain type is
IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
i.e return the same IOVA as translated address.

This patch is an extension to Will Deacon's patchset 
"Implement SMMU passthrough using the default domain".

Signed-off-by: Sunil Goutham 
---
 drivers/iommu/arm-smmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 41afb07..2f4a130 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1405,6 +1405,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct 
iommu_domain *domain,
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
 
+   if (domain->type == IOMMU_DOMAIN_IDENTITY)
+   return iova;
+
if (!ops)
return 0;
 
-- 
2.7.4

[PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed

[sunil . kovvuri]

From: Sunil Goutham 

For software initiated address translation, when domain type is
IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
i.e return the same IOVA as translated address.

This patch is an extension to Will Deacon's patchset 
"Implement SMMU passthrough using the default domain".

Signed-off-by: Sunil Goutham 
---
 drivers/iommu/arm-smmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 41afb07..2f4a130 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1405,6 +1405,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct 
iommu_domain *domain,
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
 
+   if (domain->type == IOMMU_DOMAIN_IDENTITY)
+   return iova;
+
if (!ops)
return 0;
 
-- 
2.7.4

Re: [PATCH 1/4] ftrace: Fix function pid filter on instances

[Masami Hiramatsu]

On Mon, 17 Apr 2017 11:44:27 +0900
Namhyung Kim  wrote:

> When function tracer has a pid filter, it adds a probe to sched_switch
> to track if current task can be ignored.  The probe checks the
> ftrace_ignore_pid from current tr to filter tasks.  But it misses to
> delete the probe when removing an instance so that it can cause a crash
> due to the invalid tr pointer (use-after-free).
> 
> This is easily reproducible with the following:
> 
>   # cd /sys/kernel/debug/tracing
>   # mkdir instances/buggy
>   # echo $$ > instances/buggy/set_ftrace_pid
>   # rmdir instances/buggy
> 
>   
>   BUG: KASAN: use-after-free in ftrace_filter_pid_sched_switch_probe+0x3d/0x90
>   Read of size 8 by task kworker/0:1/17
>   CPU: 0 PID: 17 Comm: kworker/0:1 Tainted: GB   4.11.0-rc3  #198
>   Call Trace:
>dump_stack+0x68/0x9f
>kasan_object_err+0x21/0x70
>kasan_report.part.1+0x22b/0x500
>? ftrace_filter_pid_sched_switch_probe+0x3d/0x90
>kasan_report+0x25/0x30
>__asan_load8+0x5e/0x70
>ftrace_filter_pid_sched_switch_probe+0x3d/0x90
>? fpid_start+0x130/0x130
>__schedule+0x571/0xce0
>...
> 
> To fix it, use ftrace_pid_reset() to unregister the probe.  As
    ftrace_clear_pids()?

> instance_rmdir() already updated ftrace codes, it can just free the
> filter safely.

And following explanation may not need.

The code looks good to me.

Reviewed-by: Masami Hiramatsu 

Thanks,

> 
> Fixes: 0c8916c34203 ("tracing: Add rmdir to remove multibuffer instances")
> Signed-off-by: Namhyung Kim 
> ---
>  kernel/trace/ftrace.c | 9 +
>  kernel/trace/trace.c  | 1 +
>  kernel/trace/trace.h  | 2 ++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 34f63e78d661..7b27066c5ed0 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -5610,6 +5610,15 @@ static void clear_ftrace_pids(struct trace_array *tr)
>   trace_free_pid_list(pid_list);
>  }
>  
> +void ftrace_clear_pids(struct trace_array *tr)
> +{
> + mutex_lock(_lock);
> +
> + clear_ftrace_pids(tr);
> +
> + mutex_unlock(_lock);
> +}
> +
>  static void ftrace_pid_reset(struct trace_array *tr)
>  {
>   mutex_lock(_lock);
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index b5d4b80f2d45..0bf623c182da 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -7485,6 +7485,7 @@ static int instance_rmdir(const char *name)
>  
>   tracing_set_nop(tr);
>   event_trace_del_tracer(tr);
> + ftrace_clear_pids(tr);
>   ftrace_destroy_function_files(tr);
>   tracefs_remove_recursive(tr->dir);
>   free_trace_buffers(tr);
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 571acee52a32..ee27163b7549 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -897,6 +897,7 @@ void ftrace_init_tracefs(struct trace_array *tr, struct 
> dentry *d_tracer);
>  void ftrace_init_tracefs_toplevel(struct trace_array *tr,
> struct dentry *d_tracer);
>  int init_function_trace(void);
> +void ftrace_clear_pids(struct trace_array *tr);
>  #else
>  static inline int ftrace_trace_task(struct trace_array *tr)
>  {
> @@ -916,6 +917,7 @@ static inline void ftrace_reset_array_ops(struct 
> trace_array *tr) { }
>  static inline void ftrace_init_tracefs(struct trace_array *tr, struct dentry 
> *d) { }
>  static inline void ftrace_init_tracefs_toplevel(struct trace_array *tr, 
> struct dentry *d) { }
>  static inline int init_function_trace(void) { return 0; }
> +static inline void ftrace_clear_pids(struct trace_array *tr) { }
>  /* ftace_func_t type is not defined, use macro instead of static inline */
>  #define ftrace_init_array_ops(tr, func) do { } while (0)
>  #endif /* CONFIG_FUNCTION_TRACER */
> -- 
> 2.12.2
> 


-- 
Masami Hiramatsu 

Re: [PATCH 1/4] ftrace: Fix function pid filter on instances

[Masami Hiramatsu]

On Mon, 17 Apr 2017 11:44:27 +0900
Namhyung Kim  wrote:

> When function tracer has a pid filter, it adds a probe to sched_switch
> to track if current task can be ignored.  The probe checks the
> ftrace_ignore_pid from current tr to filter tasks.  But it misses to
> delete the probe when removing an instance so that it can cause a crash
> due to the invalid tr pointer (use-after-free).
> 
> This is easily reproducible with the following:
> 
>   # cd /sys/kernel/debug/tracing
>   # mkdir instances/buggy
>   # echo $$ > instances/buggy/set_ftrace_pid
>   # rmdir instances/buggy
> 
>   
>   BUG: KASAN: use-after-free in ftrace_filter_pid_sched_switch_probe+0x3d/0x90
>   Read of size 8 by task kworker/0:1/17
>   CPU: 0 PID: 17 Comm: kworker/0:1 Tainted: GB   4.11.0-rc3  #198
>   Call Trace:
>dump_stack+0x68/0x9f
>kasan_object_err+0x21/0x70
>kasan_report.part.1+0x22b/0x500
>? ftrace_filter_pid_sched_switch_probe+0x3d/0x90
>kasan_report+0x25/0x30
>__asan_load8+0x5e/0x70
>ftrace_filter_pid_sched_switch_probe+0x3d/0x90
>? fpid_start+0x130/0x130
>__schedule+0x571/0xce0
>...
> 
> To fix it, use ftrace_pid_reset() to unregister the probe.  As
    ftrace_clear_pids()?

> instance_rmdir() already updated ftrace codes, it can just free the
> filter safely.

And following explanation may not need.

The code looks good to me.

Reviewed-by: Masami Hiramatsu 

Thanks,

> 
> Fixes: 0c8916c34203 ("tracing: Add rmdir to remove multibuffer instances")
> Signed-off-by: Namhyung Kim 
> ---
>  kernel/trace/ftrace.c | 9 +
>  kernel/trace/trace.c  | 1 +
>  kernel/trace/trace.h  | 2 ++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 34f63e78d661..7b27066c5ed0 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -5610,6 +5610,15 @@ static void clear_ftrace_pids(struct trace_array *tr)
>   trace_free_pid_list(pid_list);
>  }
>  
> +void ftrace_clear_pids(struct trace_array *tr)
> +{
> + mutex_lock(_lock);
> +
> + clear_ftrace_pids(tr);
> +
> + mutex_unlock(_lock);
> +}
> +
>  static void ftrace_pid_reset(struct trace_array *tr)
>  {
>   mutex_lock(_lock);
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index b5d4b80f2d45..0bf623c182da 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -7485,6 +7485,7 @@ static int instance_rmdir(const char *name)
>  
>   tracing_set_nop(tr);
>   event_trace_del_tracer(tr);
> + ftrace_clear_pids(tr);
>   ftrace_destroy_function_files(tr);
>   tracefs_remove_recursive(tr->dir);
>   free_trace_buffers(tr);
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 571acee52a32..ee27163b7549 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -897,6 +897,7 @@ void ftrace_init_tracefs(struct trace_array *tr, struct 
> dentry *d_tracer);
>  void ftrace_init_tracefs_toplevel(struct trace_array *tr,
> struct dentry *d_tracer);
>  int init_function_trace(void);
> +void ftrace_clear_pids(struct trace_array *tr);
>  #else
>  static inline int ftrace_trace_task(struct trace_array *tr)
>  {
> @@ -916,6 +917,7 @@ static inline void ftrace_reset_array_ops(struct 
> trace_array *tr) { }
>  static inline void ftrace_init_tracefs(struct trace_array *tr, struct dentry 
> *d) { }
>  static inline void ftrace_init_tracefs_toplevel(struct trace_array *tr, 
> struct dentry *d) { }
>  static inline int init_function_trace(void) { return 0; }
> +static inline void ftrace_clear_pids(struct trace_array *tr) { }
>  /* ftace_func_t type is not defined, use macro instead of static inline */
>  #define ftrace_init_array_ops(tr, func) do { } while (0)
>  #endif /* CONFIG_FUNCTION_TRACER */
> -- 
> 2.12.2
> 


-- 
Masami Hiramatsu 

Re: [PATCH] x86, kvm: Handle PFNs outside of kernel reach when touching GPTEs

[Xiao Guangrong]

On 04/12/2017 09:16 PM, Sironi, Filippo wrote:

Thanks for taking the time and sorry for the delay.


On 6. Apr 2017, at 16:22, Radim Krčmář  wrote:

2017-04-05 15:07+0200, Filippo Sironi:

cmpxchg_gpte() calls get_user_pages_fast() to retrieve the number of
pages and the respective struct pages for mapping in the kernel virtual
address space.
This doesn't work if get_user_pages_fast() is invoked with a userspace
virtual address that's backed by PFNs outside of kernel reach (e.g.,
when limiting the kernel memory with mem= in the command line and using
/dev/mem to map memory).

If get_user_pages_fast() fails, look up the VMA that backs the userspace
virtual address, compute the PFN and the physical address, and map it in
the kernel virtual address space with memremap().


What is the reason for a configuration that voluntarily restricts access
to memory that it needs?


By using /dev/mem to provide VM memory, one can avoid the overhead of 
allocating struct page(s) for the whole memory, which is wasteful when using a 
server entirely for hosting VMs.



Sounds reasonable, however it is incomplete so far as there are some
code paths still do not support non-page backend memory, e.g,
emulator_cmpxchg_emulated().

I would suggest to unify the code introduced in this patch with existing
hva_to_pfn(), also we can introduce a common API, maybe named
kvm_map_hva(), to improve the caller sides.


BTW, i do not know why we used kmap_atomic() rather than kmap(), the
path of cmpxchg_gpte() is sleep-able anyway.

Thanks!

Re: [PATCH] x86, kvm: Handle PFNs outside of kernel reach when touching GPTEs

[Xiao Guangrong]

On 04/12/2017 09:16 PM, Sironi, Filippo wrote:

Thanks for taking the time and sorry for the delay.


On 6. Apr 2017, at 16:22, Radim Krčmář  wrote:

2017-04-05 15:07+0200, Filippo Sironi:

cmpxchg_gpte() calls get_user_pages_fast() to retrieve the number of
pages and the respective struct pages for mapping in the kernel virtual
address space.
This doesn't work if get_user_pages_fast() is invoked with a userspace
virtual address that's backed by PFNs outside of kernel reach (e.g.,
when limiting the kernel memory with mem= in the command line and using
/dev/mem to map memory).

If get_user_pages_fast() fails, look up the VMA that backs the userspace
virtual address, compute the PFN and the physical address, and map it in
the kernel virtual address space with memremap().


What is the reason for a configuration that voluntarily restricts access
to memory that it needs?


By using /dev/mem to provide VM memory, one can avoid the overhead of 
allocating struct page(s) for the whole memory, which is wasteful when using a 
server entirely for hosting VMs.



Sounds reasonable, however it is incomplete so far as there are some
code paths still do not support non-page backend memory, e.g,
emulator_cmpxchg_emulated().

I would suggest to unify the code introduced in this patch with existing
hva_to_pfn(), also we can introduce a common API, maybe named
kvm_map_hva(), to improve the caller sides.


BTW, i do not know why we used kmap_atomic() rather than kmap(), the
path of cmpxchg_gpte() is sleep-able anyway.

Thanks!

Re: [PATCH] net: thunderx: Fix set_max_bgx_per_node for 81xx rgx

[Sunil Kovvuri]

On Thu, Apr 13, 2017 at 12:55 PM, George Cherian
 wrote:
> Add the PCI_SUBSYS_DEVID_81XX_RGX and use the same to set
> the max bgx per node count.
>
> This fixes the issue intoduced by following commit
> 78aacb6f6 net: thunderx: Fix invalid mac addresses for node1 interfaces
> With this commit the max_bgx_per_node for 81xx is set as 2 instead of 3
> because of which num_vfs is always calculated as zero.
>
> Signed-off-by: George Cherian 
> ---
>  drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 1 +
>  drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 64a1095..a0ca68c 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -134,6 +134,7 @@ static void set_max_bgx_per_node(struct pci_dev *pdev)
> pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, );
> switch (sdevid) {
> case PCI_SUBSYS_DEVID_81XX_BGX:
> +   case PCI_SUBSYS_DEVID_81XX_RGX:
> max_bgx_per_node = MAX_BGX_PER_CN81XX;
> break;
> case PCI_SUBSYS_DEVID_83XX_BGX:
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h 
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
> index c5080f2c..6b7fe6fd 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
> @@ -16,6 +16,7 @@
>  /* Subsystem device IDs */
>  #define PCI_SUBSYS_DEVID_88XX_BGX  0xA126
>  #define PCI_SUBSYS_DEVID_81XX_BGX  0xA226
> +#define PCI_SUBSYS_DEVID_81XX_RGX  0xA254
>  #define PCI_SUBSYS_DEVID_83XX_BGX  0xA326
>
>  #defineMAX_BGX_THUNDER 8 /* Max 2 nodes, 4 per node 
> */
> --
> 2.1.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Looks good, thanks.

Sunil.

Re: [PATCH] net: thunderx: Fix set_max_bgx_per_node for 81xx rgx

[Sunil Kovvuri]

On Thu, Apr 13, 2017 at 12:55 PM, George Cherian
 wrote:
> Add the PCI_SUBSYS_DEVID_81XX_RGX and use the same to set
> the max bgx per node count.
>
> This fixes the issue intoduced by following commit
> 78aacb6f6 net: thunderx: Fix invalid mac addresses for node1 interfaces
> With this commit the max_bgx_per_node for 81xx is set as 2 instead of 3
> because of which num_vfs is always calculated as zero.
>
> Signed-off-by: George Cherian 
> ---
>  drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 1 +
>  drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 64a1095..a0ca68c 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -134,6 +134,7 @@ static void set_max_bgx_per_node(struct pci_dev *pdev)
> pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, );
> switch (sdevid) {
> case PCI_SUBSYS_DEVID_81XX_BGX:
> +   case PCI_SUBSYS_DEVID_81XX_RGX:
> max_bgx_per_node = MAX_BGX_PER_CN81XX;
> break;
> case PCI_SUBSYS_DEVID_83XX_BGX:
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h 
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
> index c5080f2c..6b7fe6fd 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
> @@ -16,6 +16,7 @@
>  /* Subsystem device IDs */
>  #define PCI_SUBSYS_DEVID_88XX_BGX  0xA126
>  #define PCI_SUBSYS_DEVID_81XX_BGX  0xA226
> +#define PCI_SUBSYS_DEVID_81XX_RGX  0xA254
>  #define PCI_SUBSYS_DEVID_83XX_BGX  0xA326
>
>  #defineMAX_BGX_THUNDER 8 /* Max 2 nodes, 4 per node 
> */
> --
> 2.1.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Looks good, thanks.

Sunil.

Re: [PATCH 2/2] powerpc/book3s: mce: Use add_taint_no_warn() in machine_check_early().

[Mahesh Jagannath Salgaonkar]

On 04/17/2017 04:09 PM, Daniel Axtens wrote:
> Hi Mahesh,
> 
>> Fixes: 27ea2c420cad powerpc: Set the correct kernel taint on machine check 
>> errors.
> 
> I notice this Fixes a commit I introduced. Please could you cc me when
> you do this? I am likely to miss it otherwise, especially since I have
> now left IBM.

Sure will do. :-)

> 
> Being cced allows me to provide an Ack or a review. And getting feedback
> on my changes is very helpful in becoming a better programmer.
> 
> In this case, as per Michael's comment, why don't we just move the
> add_taint from machine_check_early to
> machine_check_process_queued_event - the other side of the work queue.

Yes. That is what my plan is. Also, that is not the only place.
add_taint() need to be called from machine_check_exception() as well. So
it will be called from two places.

Thanks,
-Mahesh.

> 
> The work queue system is supposed to provide us with a safe place to do
> printing, etc., so it's an appropriate place. Also, we already do
> machine_check_print_event_info there, and adding the taint doesn't need
> to be done synchronously.
> 
> Regards,
> Daniel
> 
> Mahesh J Salgaonkar  writes:
> 
>> From: Mahesh Salgaonkar 
>>
>> machine_check_early() gets called in real mode. The very first time when
>> add_taint() is called, it prints a warning which ends up calling opal
>> call (that uses OPAL_CALL wrapper) for writing it to console. If we get a
>> very first machine check while we are in opal we are doomed. OPAL_CALL
>> overwrites the PACASAVEDMSR in r13 and in this case when we are done with
>> MCE handling the original opal call will use this new MSR on it's way
>> back to opal_return. This usually leads unexpected behaviour or kernel
>> to panic. Instead use the add_taint_no_warn() that does not call printk.
>>
>> This is broken with current FW level. We got lucky so far for not getting
>> very first MCE hit while in OPAL. But easily reproducible on Mambo.
>> This should go to stable as well alongwith patch 1/2.
>>
>> Signed-off-by: Mahesh Salgaonkar 
>> ---
>>  arch/powerpc/kernel/traps.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>> index 62b587f..4a048dc 100644
>> --- a/arch/powerpc/kernel/traps.c
>> +++ b/arch/powerpc/kernel/traps.c
>> @@ -306,7 +306,7 @@ long machine_check_early(struct pt_regs *regs)
>>  
>>  __this_cpu_inc(irq_stat.mce_exceptions);
>>  
>> -add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
>> +add_taint_no_warn(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
>>  
>>  /*
>>   * See if platform is capable of handling machine check. (e.g. PowerNV
> 

Re: [PATCH 2/2] powerpc/book3s: mce: Use add_taint_no_warn() in machine_check_early().

[Mahesh Jagannath Salgaonkar]

On 04/17/2017 04:09 PM, Daniel Axtens wrote:
> Hi Mahesh,
> 
>> Fixes: 27ea2c420cad powerpc: Set the correct kernel taint on machine check 
>> errors.
> 
> I notice this Fixes a commit I introduced. Please could you cc me when
> you do this? I am likely to miss it otherwise, especially since I have
> now left IBM.

Sure will do. :-)

> 
> Being cced allows me to provide an Ack or a review. And getting feedback
> on my changes is very helpful in becoming a better programmer.
> 
> In this case, as per Michael's comment, why don't we just move the
> add_taint from machine_check_early to
> machine_check_process_queued_event - the other side of the work queue.

Yes. That is what my plan is. Also, that is not the only place.
add_taint() need to be called from machine_check_exception() as well. So
it will be called from two places.

Thanks,
-Mahesh.

> 
> The work queue system is supposed to provide us with a safe place to do
> printing, etc., so it's an appropriate place. Also, we already do
> machine_check_print_event_info there, and adding the taint doesn't need
> to be done synchronously.
> 
> Regards,
> Daniel
> 
> Mahesh J Salgaonkar  writes:
> 
>> From: Mahesh Salgaonkar 
>>
>> machine_check_early() gets called in real mode. The very first time when
>> add_taint() is called, it prints a warning which ends up calling opal
>> call (that uses OPAL_CALL wrapper) for writing it to console. If we get a
>> very first machine check while we are in opal we are doomed. OPAL_CALL
>> overwrites the PACASAVEDMSR in r13 and in this case when we are done with
>> MCE handling the original opal call will use this new MSR on it's way
>> back to opal_return. This usually leads unexpected behaviour or kernel
>> to panic. Instead use the add_taint_no_warn() that does not call printk.
>>
>> This is broken with current FW level. We got lucky so far for not getting
>> very first MCE hit while in OPAL. But easily reproducible on Mambo.
>> This should go to stable as well alongwith patch 1/2.
>>
>> Signed-off-by: Mahesh Salgaonkar 
>> ---
>>  arch/powerpc/kernel/traps.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>> index 62b587f..4a048dc 100644
>> --- a/arch/powerpc/kernel/traps.c
>> +++ b/arch/powerpc/kernel/traps.c
>> @@ -306,7 +306,7 @@ long machine_check_early(struct pt_regs *regs)
>>  
>>  __this_cpu_inc(irq_stat.mce_exceptions);
>>  
>> -add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
>> +add_taint_no_warn(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
>>  
>>  /*
>>   * See if platform is capable of handling machine check. (e.g. PowerNV
> 

[PATCH] arm64: allwinner: h5: add support for NanoPi NEO2 board

[Icenowy Zheng]

NanoPi NEO2 is a board with the same size factor with the original
NanoPi NEO by FriendlyELEC.

It has a H5 instead of H3 on NanoPi NEO, and the ethernet is upgraded to
1Gbps (with external RTL8211E PHY).

Add support for this board.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/Makefile |   1 +
 .../boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts   | 134 +
 2 files changed, 135 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 92a84eea6b96..546720096aef 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo2.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
new file mode 100644
index ..f6d71b0d482a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2017 Icenowy Zheng 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun50i-h5.dtsi"
+
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi NEO 2";
+   compatible = "friendlyarm,nanopi-neo2", "allwinner,sun50i-h5";
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   pwr {
+   label = "nanopi:green:pwr";
+   gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+
+   status {
+   label = "nanopi:blue:status";
+   gpios = < 0 10 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   reg_usb0_vbus: usb0-vbus {
+   compatible = "regulator-fixed";
+   regulator-name = "usb0-vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   enable-active-high;
+   gpio = <_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */
+   status = "okay";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>, <_cd_pin>;
+   vmmc-supply = 

[PATCH] arm64: allwinner: h5: add support for NanoPi NEO2 board

[Icenowy Zheng]

NanoPi NEO2 is a board with the same size factor with the original
NanoPi NEO by FriendlyELEC.

It has a H5 instead of H3 on NanoPi NEO, and the ethernet is upgraded to
1Gbps (with external RTL8211E PHY).

Add support for this board.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/Makefile |   1 +
 .../boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts   | 134 +
 2 files changed, 135 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 92a84eea6b96..546720096aef 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo2.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
new file mode 100644
index ..f6d71b0d482a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2017 Icenowy Zheng 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun50i-h5.dtsi"
+
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi NEO 2";
+   compatible = "friendlyarm,nanopi-neo2", "allwinner,sun50i-h5";
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   pwr {
+   label = "nanopi:green:pwr";
+   gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+
+   status {
+   label = "nanopi:blue:status";
+   gpios = < 0 10 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   reg_usb0_vbus: usb0-vbus {
+   compatible = "regulator-fixed";
+   regulator-name = "usb0-vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   enable-active-high;
+   gpio = <_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */
+   status = "okay";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>, <_cd_pin>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+ 

[PATCH] tools/virtio: fix build breakage

[Sekhar Nori]

Commit db932ced55cf ("virtio: add context flag to find vqs")
added a new 'context' flag to vring_new_virtqueue(), but the
corresponding API in tools/virtio/ is not updated causing
build errors due to conflicting declarations.

Bring code in tools/virtio in sync with that in kernel.

I have used 'false' for the value of the new boolean 'context'
flag as that seems to be the best way to preserve existing
behavior.

Tested with:

$ make -C tools/virtio clean all ARCH=x86

Fixes: db932ced55cf ("virtio: add context flag to find vqs")
Signed-off-by: Sekhar Nori 
---
I am not really a virtio user so I have not tested
these apart from the build test. Applies on linux-next
of April 11 2017

 tools/virtio/linux/virtio.h | 1 +
 tools/virtio/virtio_test.c  | 2 +-
 tools/virtio/vringh_test.c  | 7 ---
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/virtio/linux/virtio.h b/tools/virtio/linux/virtio.h
index 9377c8b4ac16..d8f534025b7f 100644
--- a/tools/virtio/linux/virtio.h
+++ b/tools/virtio/linux/virtio.h
@@ -57,6 +57,7 @@ struct virtqueue *vring_new_virtqueue(unsigned int index,
  unsigned int vring_align,
  struct virtio_device *vdev,
  bool weak_barriers,
+ bool ctx,
  void *pages,
  bool (*notify)(struct virtqueue *vq),
  void (*callback)(struct virtqueue *vq),
diff --git a/tools/virtio/virtio_test.c b/tools/virtio/virtio_test.c
index e0445898f08f..76d6f583c249 100644
--- a/tools/virtio/virtio_test.c
+++ b/tools/virtio/virtio_test.c
@@ -100,7 +100,7 @@ static void vq_info_add(struct vdev_info *dev, int num)
vring_init(>vring, num, info->ring, 4096);
info->vq = vring_new_virtqueue(info->idx,
   info->vring.num, 4096, >vdev,
-  true, info->ring,
+  true, false, info->ring,
   vq_notify, vq_callback, "test");
assert(info->vq);
info->vq->priv = info;
diff --git a/tools/virtio/vringh_test.c b/tools/virtio/vringh_test.c
index 5f94f5105678..9476c616d064 100644
--- a/tools/virtio/vringh_test.c
+++ b/tools/virtio/vringh_test.c
@@ -314,7 +314,8 @@ static int parallel_test(u64 features,
err(1, "Could not set affinity to cpu %u", first_cpu);
 
vq = vring_new_virtqueue(0, RINGSIZE, ALIGN, , true,
-guest_map, fast_vringh ? no_notify_host
+false, guest_map,
+fast_vringh ? no_notify_host
 : parallel_notify_host,
 never_callback_guest, "guest vq");
 
@@ -479,7 +480,7 @@ int main(int argc, char *argv[])
memset(__user_addr_min, 0, vring_size(RINGSIZE, ALIGN));
 
/* Set up guest side. */
-   vq = vring_new_virtqueue(0, RINGSIZE, ALIGN, , true,
+   vq = vring_new_virtqueue(0, RINGSIZE, ALIGN, , true, false,
 __user_addr_min,
 never_notify_host, never_callback_guest,
 "guest vq");
@@ -663,7 +664,7 @@ int main(int argc, char *argv[])
/* Force creation of direct, which we modify. */
__virtio_clear_bit(, VIRTIO_RING_F_INDIRECT_DESC);
vq = vring_new_virtqueue(0, RINGSIZE, ALIGN, , true,
-__user_addr_min,
+false, __user_addr_min,
 never_notify_host,
 never_callback_guest,
 "guest vq");
-- 
2.9.0

[PATCH] tools/virtio: fix build breakage

[Sekhar Nori]

Commit db932ced55cf ("virtio: add context flag to find vqs")
added a new 'context' flag to vring_new_virtqueue(), but the
corresponding API in tools/virtio/ is not updated causing
build errors due to conflicting declarations.

Bring code in tools/virtio in sync with that in kernel.

I have used 'false' for the value of the new boolean 'context'
flag as that seems to be the best way to preserve existing
behavior.

Tested with:

$ make -C tools/virtio clean all ARCH=x86

Fixes: db932ced55cf ("virtio: add context flag to find vqs")
Signed-off-by: Sekhar Nori 
---
I am not really a virtio user so I have not tested
these apart from the build test. Applies on linux-next
of April 11 2017

 tools/virtio/linux/virtio.h | 1 +
 tools/virtio/virtio_test.c  | 2 +-
 tools/virtio/vringh_test.c  | 7 ---
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/virtio/linux/virtio.h b/tools/virtio/linux/virtio.h
index 9377c8b4ac16..d8f534025b7f 100644
--- a/tools/virtio/linux/virtio.h
+++ b/tools/virtio/linux/virtio.h
@@ -57,6 +57,7 @@ struct virtqueue *vring_new_virtqueue(unsigned int index,
  unsigned int vring_align,
  struct virtio_device *vdev,
  bool weak_barriers,
+ bool ctx,
  void *pages,
  bool (*notify)(struct virtqueue *vq),
  void (*callback)(struct virtqueue *vq),
diff --git a/tools/virtio/virtio_test.c b/tools/virtio/virtio_test.c
index e0445898f08f..76d6f583c249 100644
--- a/tools/virtio/virtio_test.c
+++ b/tools/virtio/virtio_test.c
@@ -100,7 +100,7 @@ static void vq_info_add(struct vdev_info *dev, int num)
vring_init(>vring, num, info->ring, 4096);
info->vq = vring_new_virtqueue(info->idx,
   info->vring.num, 4096, >vdev,
-  true, info->ring,
+  true, false, info->ring,
   vq_notify, vq_callback, "test");
assert(info->vq);
info->vq->priv = info;
diff --git a/tools/virtio/vringh_test.c b/tools/virtio/vringh_test.c
index 5f94f5105678..9476c616d064 100644
--- a/tools/virtio/vringh_test.c
+++ b/tools/virtio/vringh_test.c
@@ -314,7 +314,8 @@ static int parallel_test(u64 features,
err(1, "Could not set affinity to cpu %u", first_cpu);
 
vq = vring_new_virtqueue(0, RINGSIZE, ALIGN, , true,
-guest_map, fast_vringh ? no_notify_host
+false, guest_map,
+fast_vringh ? no_notify_host
 : parallel_notify_host,
 never_callback_guest, "guest vq");
 
@@ -479,7 +480,7 @@ int main(int argc, char *argv[])
memset(__user_addr_min, 0, vring_size(RINGSIZE, ALIGN));
 
/* Set up guest side. */
-   vq = vring_new_virtqueue(0, RINGSIZE, ALIGN, , true,
+   vq = vring_new_virtqueue(0, RINGSIZE, ALIGN, , true, false,
 __user_addr_min,
 never_notify_host, never_callback_guest,
 "guest vq");
@@ -663,7 +664,7 @@ int main(int argc, char *argv[])
/* Force creation of direct, which we modify. */
__virtio_clear_bit(, VIRTIO_RING_F_INDIRECT_DESC);
vq = vring_new_virtqueue(0, RINGSIZE, ALIGN, , true,
-__user_addr_min,
+false, __user_addr_min,
 never_notify_host,
 never_callback_guest,
 "guest vq");
-- 
2.9.0

Re: [PATCH 1/3] zram: fix operator precedence to get offset

[Sergey Senozhatsky]

On (04/17/17 19:50), Sergey Senozhatsky wrote:
[..]
> so in the existing scheme of things, we never care about 'sector'
> passed from zram_rw_page(). and this has worked for us for quite
> some time. my call would be -- let's drop zram_rw_page() `sector'
> calculation.

d'oh... s/sector/offset/g


-ss

Re: [PATCH 1/3] zram: fix operator precedence to get offset

[Sergey Senozhatsky]

On (04/17/17 19:50), Sergey Senozhatsky wrote:
[..]
> so in the existing scheme of things, we never care about 'sector'
> passed from zram_rw_page(). and this has worked for us for quite
> some time. my call would be -- let's drop zram_rw_page() `sector'
> calculation.

d'oh... s/sector/offset/g


-ss

Re: [PATCH 1/3] zram: fix operator precedence to get offset

[Sergey Senozhatsky]

Hello Minchan,

On (04/17/17 11:14), Minchan Kim wrote:
> On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote:
> > On (04/17/17 10:21), Sergey Senozhatsky wrote:
> > > > However, it should be *fixed* to prevent confusion in future
> > 
> > or may be something like below? can save us some cycles.
> > 
> > remove this calculation
> > 
> > -   offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT;
> > 
> > 
> > and pass 0 to zram_bvec_rw()
> > 
> > -   err = zram_bvec_rw(zram, , index, offset, is_write);
> > +   err = zram_bvec_rw(zram, , index, 0, is_write);
> 
> That was one I wrote but have thought it more.
> 
> Because I suspect fs can submit page-size IO in non-aligned PAGE_SIZE
> sector? For example, it can submit PAGE_SIZE read request from 9 sector.
> Is it possible? I don't know.
> 
> As well, FS can format zram from sector 1, not sector 0? IOW, can't it
> use starting sector as non-page algined sector?
> We can do it via fdisk?
> 
> Anyway, If one of scenario I mentioned is possible, zram_rw_page will
> be broken.
> 
> If it's hard to check all of scenario in this moment, it would be
> better to not remove it and then add WARN_ON(offset) in there.
> 
> While I am writing this, I found this.
> 
> /**
>  * bdev_read_page() - Start reading a page from a block device
>  * @bdev: The device to read the page from
>  * @sector: The offset on the device to read the page to (need not be aligned)
>  * @page: The page to read
>  *
> 
> Hmm,, need investigation but no time.

good questions.

as far as I can see, we never use 'offset' which we pass to zram_bvec_rw()
from zram_rw_page(). `offset' makes a lot of sense for partial IO, but in
zram_bvec_rw() we always do "bv.bv_len = PAGE_SIZE".

so what we have is

for READ

zram_rw_page()
bv.bv_len = PAGE_SIZE
zram_bvec_rw(zram, , index, offset, is_write);
zram_bvec_read()
if (is_partial_io(bvec))// always false
memcpy(user_mem + bvec->bv_offset,
uncmem + offset,
bvec->bv_len);


for WRITE

zram_rw_page()
bv.bv_len = PAGE_SIZE
zram_bvec_rw(zram, , index, offset, is_write);
zram_bvec_write()
if (is_partial_io(bvec))// always false
memcpy(uncmem + offset,
user_mem + bvec->bv_offset,
bvec->bv_len);


and our is_partial_io() looks at ->bv_len:

bvec->bv_len != PAGE_SIZE;

which we set to PAGE_SIZE.

so in the existing scheme of things, we never care about 'sector'
passed from zram_rw_page(). and this has worked for us for quite
some time. my call would be -- let's drop zram_rw_page() `sector'
calculation.

-ss

Re: [PATCH 1/3] zram: fix operator precedence to get offset

[Sergey Senozhatsky]

Hello Minchan,

On (04/17/17 11:14), Minchan Kim wrote:
> On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote:
> > On (04/17/17 10:21), Sergey Senozhatsky wrote:
> > > > However, it should be *fixed* to prevent confusion in future
> > 
> > or may be something like below? can save us some cycles.
> > 
> > remove this calculation
> > 
> > -   offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT;
> > 
> > 
> > and pass 0 to zram_bvec_rw()
> > 
> > -   err = zram_bvec_rw(zram, , index, offset, is_write);
> > +   err = zram_bvec_rw(zram, , index, 0, is_write);
> 
> That was one I wrote but have thought it more.
> 
> Because I suspect fs can submit page-size IO in non-aligned PAGE_SIZE
> sector? For example, it can submit PAGE_SIZE read request from 9 sector.
> Is it possible? I don't know.
> 
> As well, FS can format zram from sector 1, not sector 0? IOW, can't it
> use starting sector as non-page algined sector?
> We can do it via fdisk?
> 
> Anyway, If one of scenario I mentioned is possible, zram_rw_page will
> be broken.
> 
> If it's hard to check all of scenario in this moment, it would be
> better to not remove it and then add WARN_ON(offset) in there.
> 
> While I am writing this, I found this.
> 
> /**
>  * bdev_read_page() - Start reading a page from a block device
>  * @bdev: The device to read the page from
>  * @sector: The offset on the device to read the page to (need not be aligned)
>  * @page: The page to read
>  *
> 
> Hmm,, need investigation but no time.

good questions.

as far as I can see, we never use 'offset' which we pass to zram_bvec_rw()
from zram_rw_page(). `offset' makes a lot of sense for partial IO, but in
zram_bvec_rw() we always do "bv.bv_len = PAGE_SIZE".

so what we have is

for READ

zram_rw_page()
bv.bv_len = PAGE_SIZE
zram_bvec_rw(zram, , index, offset, is_write);
zram_bvec_read()
if (is_partial_io(bvec))// always false
memcpy(user_mem + bvec->bv_offset,
uncmem + offset,
bvec->bv_len);


for WRITE

zram_rw_page()
bv.bv_len = PAGE_SIZE
zram_bvec_rw(zram, , index, offset, is_write);
zram_bvec_write()
if (is_partial_io(bvec))// always false
memcpy(uncmem + offset,
user_mem + bvec->bv_offset,
bvec->bv_len);


and our is_partial_io() looks at ->bv_len:

bvec->bv_len != PAGE_SIZE;

which we set to PAGE_SIZE.

so in the existing scheme of things, we never care about 'sector'
passed from zram_rw_page(). and this has worked for us for quite
some time. my call would be -- let's drop zram_rw_page() `sector'
calculation.

-ss

Re: cgroup: avoid attaching a cgroup root to two different superblocks

[Zefan Li]

On 2017/4/15 7:32, Andrei Vagin wrote:
> On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote:
>> Hello,
>>
>> One of our CRIU tests hangs with this patch.
>>
>> Steps to reproduce:
>> curl -o cgroupns.c 
>> https://gist.githubusercontent.com/avagin/f87c8a8bd2a0de9afcc74976327786bc/raw/5843701ef3679f50dd2427cf57a80871082eb28c/gistfile1.txt
>> gcc cgroupns.c -o cgroupns
>> ./cgroupns
>> ./cgroupns
> 
> I've found a trivial reproducer:
> mkdir /tmp/xxx
> mount -t cgroup -o none,name=zdtmtst xxx /tmp/xxx
> mkdir /tmp/xxx/xxx
> umount /tmp/xxx
> mount -t cgroup -o none,name=zdtmtst xxx /tmp/xxx
> 

Now I remember why it didn't check NULL pointer... Could you try the following 
fix?
It also reverts my previous patch. I would appreciate if you run the full test 
suit,
to make sure it won't break anything.

PS: Tejun, I found recently I can no longer receive your emails. Don't know 
why...

===

[PATCH] cgruop: avoid attaching a cgroup root to two different superblocks, 
take 2

Commit bfb0b80db5f9 is broken. Now we try to fix the race by delaying
the initialization of cgroup root refcnt until a superblock has been
allocated.

Cc: sta...@vger.kernel.org # 3.16+
Reported-by: Dmitry Vyukov 
Reported-by: Andrei Vagin 
Signed-off-by: Zefan Li 
---
 kernel/cgroup/cgroup-internal.h |  2 +-
 kernel/cgroup/cgroup-v1.c   | 18 --
 kernel/cgroup/cgroup.c  |  8 
 3 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index 9203bfb..e470268 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -163,7 +163,7 @@ int cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, 
size_t buflen,
 
 void cgroup_free_root(struct cgroup_root *root);
 void init_cgroup_root(struct cgroup_root *root, struct cgroup_sb_opts *opts);
-int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask);
+int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask, int ref_flags);
 int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask);
 struct dentry *cgroup_do_mount(struct file_system_type *fs_type, int flags,
   struct cgroup_root *root, unsigned long magic,
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 12e19f0..6ca9b12 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -1072,6 +1072,7 @@ struct dentry *cgroup1_mount(struct file_system_type 
*fs_type, int flags,
struct cgroup_subsys *ss;
struct dentry *dentry;
int i, ret;
+   bool new_root = false;
 
cgroup_lock_and_drain_offline(_dfl_root.cgrp);
 
@@ -1146,7 +1147,7 @@ struct dentry *cgroup1_mount(struct file_system_type 
*fs_type, int flags,
 * path is super cold.  Let's just sleep a bit and retry.
 */
pinned_sb = kernfs_pin_sb(root->kf_root, NULL);
-   if (IS_ERR_OR_NULL(pinned_sb) ||
+   if (IS_ERR(pinned_sb) ||
!percpu_ref_tryget_live(>cgrp.self.refcnt)) {
mutex_unlock(_mutex);
if (!IS_ERR_OR_NULL(pinned_sb))
@@ -1181,10 +1182,11 @@ struct dentry *cgroup1_mount(struct file_system_type 
*fs_type, int flags,
ret = -ENOMEM;
goto out_unlock;
}
+   new_root = true;
 
init_cgroup_root(root, );
 
-   ret = cgroup_setup_root(root, opts.subsys_mask);
+   ret = cgroup_setup_root(root, opts.subsys_mask, PERCPU_REF_INIT_DEAD);
if (ret)
cgroup_free_root(root);
 
@@ -1201,6 +1203,18 @@ struct dentry *cgroup1_mount(struct file_system_type 
*fs_type, int flags,
 CGROUP_SUPER_MAGIC, ns);
 
/*
+* There's a race window after we release cgroup_mutex and before
+* allocating a superblock. Make sure a concurrent process won't
+* be able to re-use the root during this window by delaying the
+* initialization of root refcnt.
+*/
+   if (new_root) {
+   mutex_lock(_mutex);
+   percpu_ref_reinit(>cgrp.self.refcnt);
+   mutex_unlock(_mutex);
+   }
+
+   /*
 * If @pinned_sb, we're reusing an existing root and holding an
 * extra ref on its sb.  Mount is complete.  Put the extra ref.
 */
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 4885132..0f98010 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -1640,7 +1640,7 @@ void init_cgroup_root(struct cgroup_root *root, struct 
cgroup_sb_opts *opts)
set_bit(CGRP_CPUSET_CLONE_CHILDREN, >cgrp.flags);
 }
 
-int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask)
+int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask, int ref_flags)
 {
LIST_HEAD(tmp_links);
struct cgroup *root_cgrp = >cgrp;
@@ -1656,8 

Re: cgroup: avoid attaching a cgroup root to two different superblocks

[Zefan Li]

On 2017/4/15 7:32, Andrei Vagin wrote:
> On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote:
>> Hello,
>>
>> One of our CRIU tests hangs with this patch.
>>
>> Steps to reproduce:
>> curl -o cgroupns.c 
>> https://gist.githubusercontent.com/avagin/f87c8a8bd2a0de9afcc74976327786bc/raw/5843701ef3679f50dd2427cf57a80871082eb28c/gistfile1.txt
>> gcc cgroupns.c -o cgroupns
>> ./cgroupns
>> ./cgroupns
> 
> I've found a trivial reproducer:
> mkdir /tmp/xxx
> mount -t cgroup -o none,name=zdtmtst xxx /tmp/xxx
> mkdir /tmp/xxx/xxx
> umount /tmp/xxx
> mount -t cgroup -o none,name=zdtmtst xxx /tmp/xxx
> 

Now I remember why it didn't check NULL pointer... Could you try the following 
fix?
It also reverts my previous patch. I would appreciate if you run the full test 
suit,
to make sure it won't break anything.

PS: Tejun, I found recently I can no longer receive your emails. Don't know 
why...

===

[PATCH] cgruop: avoid attaching a cgroup root to two different superblocks, 
take 2

Commit bfb0b80db5f9 is broken. Now we try to fix the race by delaying
the initialization of cgroup root refcnt until a superblock has been
allocated.

Cc: sta...@vger.kernel.org # 3.16+
Reported-by: Dmitry Vyukov 
Reported-by: Andrei Vagin 
Signed-off-by: Zefan Li 
---
 kernel/cgroup/cgroup-internal.h |  2 +-
 kernel/cgroup/cgroup-v1.c   | 18 --
 kernel/cgroup/cgroup.c  |  8 
 3 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index 9203bfb..e470268 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -163,7 +163,7 @@ int cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, 
size_t buflen,
 
 void cgroup_free_root(struct cgroup_root *root);
 void init_cgroup_root(struct cgroup_root *root, struct cgroup_sb_opts *opts);
-int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask);
+int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask, int ref_flags);
 int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask);
 struct dentry *cgroup_do_mount(struct file_system_type *fs_type, int flags,
   struct cgroup_root *root, unsigned long magic,
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 12e19f0..6ca9b12 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -1072,6 +1072,7 @@ struct dentry *cgroup1_mount(struct file_system_type 
*fs_type, int flags,
struct cgroup_subsys *ss;
struct dentry *dentry;
int i, ret;
+   bool new_root = false;
 
cgroup_lock_and_drain_offline(_dfl_root.cgrp);
 
@@ -1146,7 +1147,7 @@ struct dentry *cgroup1_mount(struct file_system_type 
*fs_type, int flags,
 * path is super cold.  Let's just sleep a bit and retry.
 */
pinned_sb = kernfs_pin_sb(root->kf_root, NULL);
-   if (IS_ERR_OR_NULL(pinned_sb) ||
+   if (IS_ERR(pinned_sb) ||
!percpu_ref_tryget_live(>cgrp.self.refcnt)) {
mutex_unlock(_mutex);
if (!IS_ERR_OR_NULL(pinned_sb))
@@ -1181,10 +1182,11 @@ struct dentry *cgroup1_mount(struct file_system_type 
*fs_type, int flags,
ret = -ENOMEM;
goto out_unlock;
}
+   new_root = true;
 
init_cgroup_root(root, );
 
-   ret = cgroup_setup_root(root, opts.subsys_mask);
+   ret = cgroup_setup_root(root, opts.subsys_mask, PERCPU_REF_INIT_DEAD);
if (ret)
cgroup_free_root(root);
 
@@ -1201,6 +1203,18 @@ struct dentry *cgroup1_mount(struct file_system_type 
*fs_type, int flags,
 CGROUP_SUPER_MAGIC, ns);
 
/*
+* There's a race window after we release cgroup_mutex and before
+* allocating a superblock. Make sure a concurrent process won't
+* be able to re-use the root during this window by delaying the
+* initialization of root refcnt.
+*/
+   if (new_root) {
+   mutex_lock(_mutex);
+   percpu_ref_reinit(>cgrp.self.refcnt);
+   mutex_unlock(_mutex);
+   }
+
+   /*
 * If @pinned_sb, we're reusing an existing root and holding an
 * extra ref on its sb.  Mount is complete.  Put the extra ref.
 */
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 4885132..0f98010 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -1640,7 +1640,7 @@ void init_cgroup_root(struct cgroup_root *root, struct 
cgroup_sb_opts *opts)
set_bit(CGRP_CPUSET_CLONE_CHILDREN, >cgrp.flags);
 }
 
-int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask)
+int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask, int ref_flags)
 {
LIST_HEAD(tmp_links);
struct cgroup *root_cgrp = >cgrp;
@@ -1656,8 +1656,8 @@ int cgroup_setup_root(struct cgroup_root *root, u16 

Re: [PATCH 2/2] powerpc/book3s: mce: Use add_taint_no_warn() in machine_check_early().

[Daniel Axtens]

Hi Mahesh,

> Fixes: 27ea2c420cad powerpc: Set the correct kernel taint on machine check 
> errors.

I notice this Fixes a commit I introduced. Please could you cc me when
you do this? I am likely to miss it otherwise, especially since I have
now left IBM.

Being cced allows me to provide an Ack or a review. And getting feedback
on my changes is very helpful in becoming a better programmer.

In this case, as per Michael's comment, why don't we just move the
add_taint from machine_check_early to
machine_check_process_queued_event - the other side of the work queue.

The work queue system is supposed to provide us with a safe place to do
printing, etc., so it's an appropriate place. Also, we already do
machine_check_print_event_info there, and adding the taint doesn't need
to be done synchronously.

Regards,
Daniel

Mahesh J Salgaonkar  writes:

> From: Mahesh Salgaonkar 
>
> machine_check_early() gets called in real mode. The very first time when
> add_taint() is called, it prints a warning which ends up calling opal
> call (that uses OPAL_CALL wrapper) for writing it to console. If we get a
> very first machine check while we are in opal we are doomed. OPAL_CALL
> overwrites the PACASAVEDMSR in r13 and in this case when we are done with
> MCE handling the original opal call will use this new MSR on it's way
> back to opal_return. This usually leads unexpected behaviour or kernel
> to panic. Instead use the add_taint_no_warn() that does not call printk.
>
> This is broken with current FW level. We got lucky so far for not getting
> very first MCE hit while in OPAL. But easily reproducible on Mambo.
> This should go to stable as well alongwith patch 1/2.
>
> Signed-off-by: Mahesh Salgaonkar 
> ---
>  arch/powerpc/kernel/traps.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 62b587f..4a048dc 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -306,7 +306,7 @@ long machine_check_early(struct pt_regs *regs)
>  
>   __this_cpu_inc(irq_stat.mce_exceptions);
>  
> - add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
> + add_taint_no_warn(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
>  
>   /*
>* See if platform is capable of handling machine check. (e.g. PowerNV

Re: [PATCH 2/2] powerpc/book3s: mce: Use add_taint_no_warn() in machine_check_early().

[Daniel Axtens]

Hi Mahesh,

> Fixes: 27ea2c420cad powerpc: Set the correct kernel taint on machine check 
> errors.

I notice this Fixes a commit I introduced. Please could you cc me when
you do this? I am likely to miss it otherwise, especially since I have
now left IBM.

Being cced allows me to provide an Ack or a review. And getting feedback
on my changes is very helpful in becoming a better programmer.

In this case, as per Michael's comment, why don't we just move the
add_taint from machine_check_early to
machine_check_process_queued_event - the other side of the work queue.

The work queue system is supposed to provide us with a safe place to do
printing, etc., so it's an appropriate place. Also, we already do
machine_check_print_event_info there, and adding the taint doesn't need
to be done synchronously.

Regards,
Daniel

Mahesh J Salgaonkar  writes:

> From: Mahesh Salgaonkar 
>
> machine_check_early() gets called in real mode. The very first time when
> add_taint() is called, it prints a warning which ends up calling opal
> call (that uses OPAL_CALL wrapper) for writing it to console. If we get a
> very first machine check while we are in opal we are doomed. OPAL_CALL
> overwrites the PACASAVEDMSR in r13 and in this case when we are done with
> MCE handling the original opal call will use this new MSR on it's way
> back to opal_return. This usually leads unexpected behaviour or kernel
> to panic. Instead use the add_taint_no_warn() that does not call printk.
>
> This is broken with current FW level. We got lucky so far for not getting
> very first MCE hit while in OPAL. But easily reproducible on Mambo.
> This should go to stable as well alongwith patch 1/2.
>
> Signed-off-by: Mahesh Salgaonkar 
> ---
>  arch/powerpc/kernel/traps.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 62b587f..4a048dc 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -306,7 +306,7 @@ long machine_check_early(struct pt_regs *regs)
>  
>   __this_cpu_inc(irq_stat.mce_exceptions);
>  
> - add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
> + add_taint_no_warn(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
>  
>   /*
>* See if platform is capable of handling machine check. (e.g. PowerNV

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

[Andi Shyti]

Hi Dmitry,

kindly ping, again. Please let me know if there is something I
can do.

Andi

On Fri, Apr 07, 2017 at 06:31:29PM +0900, Andi Shyti wrote:
> Hi Dmitry,
> 
> just a kind ping, do you have any comment about this?
> 
> Thanks,
> Andi
> 
> On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote:
> > The stmfts (ST-Microelectronics FingerTip S) touchscreen device
> > is a capacitive multi-touch controller mainly for mobile use.
> > 
> > It's connected through i2c bus at the address 0x49 and it
> > interfaces with userspace through input event interface.
> > 
> > At the current state it provides a touchscreen multitouch
> > functionality up to 10 fingers. Each finger is enumerated with a
> > distinctive id (from 0 to 9).
> > 
> > If enabled the device can support single "touch" hovering, by
> > providing three coordinates, x, y and distance.
> > 
> > It is possible to select the touchkey functionality which
> > provides a basic two keys interface for "home" and "back" menu,
> > typical in mobile phones.
> > 
> > Signed-off-by: Andi Shyti 
> > ---
> >  drivers/input/touchscreen/Kconfig  |  12 +
> >  drivers/input/touchscreen/Makefile |   1 +
> >  drivers/input/touchscreen/stmfts.c | 805 
> > +
> >  3 files changed, 818 insertions(+)
> >  create mode 100644 drivers/input/touchscreen/stmfts.c
> > 
> > diff --git a/drivers/input/touchscreen/Kconfig 
> > b/drivers/input/touchscreen/Kconfig
> > index 33c62e5de4fa..f8631c64290d 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -1114,6 +1114,18 @@ config TOUCHSCREEN_ST1232
> >   To compile this driver as a module, choose M here: the
> >   module will be called st1232_ts.
> >  
> > +config TOUCHSCREEN_STMFTS
> > +   tristate "STMicroelectronics STMFTS touchscreen"
> > +   depends on I2C
> > +   depends on INPUT
> > +   depends on LEDS_CLASS
> > +   help
> > + Say Y here if you want support for STMicroelectronics
> > + STMFTS touchscreen.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called stmfts.
> > +
> >  config TOUCHSCREEN_STMPE
> > tristate "STMicroelectronics STMPE touchscreens"
> > depends on MFD_STMPE
> > diff --git a/drivers/input/touchscreen/Makefile 
> > b/drivers/input/touchscreen/Makefile
> > index 18e476948e44..6badce87037b 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -67,6 +67,7 @@ obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_SILEAD)   += silead.o
> >  obj-$(CONFIG_TOUCHSCREEN_SIS_I2C)  += sis_i2c.o
> >  obj-$(CONFIG_TOUCHSCREEN_ST1232)   += st1232.o
> > +obj-$(CONFIG_TOUCHSCREEN_STMFTS)   += stmfts.o
> >  obj-$(CONFIG_TOUCHSCREEN_STMPE)+= stmpe-ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_SUN4I)+= sun4i-ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_SUR40)+= sur40.o
> > diff --git a/drivers/input/touchscreen/stmfts.c 
> > b/drivers/input/touchscreen/stmfts.c
> > new file mode 100644
> > index ..2e18b1456f42
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/stmfts.c
> > @@ -0,0 +1,805 @@
> > +/*
> > + * Copyright (c) 2017 Samsung Electronics Co., Ltd.
> > + * Author: Andi Shyti 
> > + *
> > + * 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.
> > + *
> > + * STMicroelectronics FTS Touchscreen device driver
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* I2C commands */
> > +#define STMFTS_READ_INFO   0x80
> > +#define STMFTS_READ_STATUS 0x84
> > +#define STMFTS_READ_ONE_EVENT  0x85
> > +#define STMFTS_READ_ALL_EVENT  0x86
> > +#define STMFTS_LATEST_EVENT0x87
> > +#define STMFTS_SLEEP_IN0x90
> > +#define STMFTS_SLEEP_OUT   0x91
> > +#define STMFTS_MS_MT_SENSE_OFF 0x92
> > +#define STMFTS_MS_MT_SENSE_ON  0x93
> > +#define STMFTS_SS_HOVER_SENSE_OFF  0x94
> > +#define STMFTS_SS_HOVER_SENSE_ON   0x95
> > +#define STMFTS_MS_KEY_SENSE_OFF0x9a
> > +#define STMFTS_MS_KEY_SENSE_ON 0x9b
> > +#define STMFTS_SYSTEM_RESET0xa0
> > +#define STMFTS_CLEAR_EVENT_STACK   0xa1
> > +#define STMFTS_FULL_FORCE_CALIBRATION  0xa2
> > +#define STMFTS_MS_CX_TUNING0xa3
> > +#define STMFTS_SS_CX_TUNING0xa4
> > +
> > +/* events */
> > +#define STMFTS_EV_NO_EVENT 0x00
> > +#define STMFTS_EV_MULTI_TOUCH_DETECTED 0x02
> > 

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

[Andi Shyti]

Hi Dmitry,

kindly ping, again. Please let me know if there is something I
can do.

Andi

On Fri, Apr 07, 2017 at 06:31:29PM +0900, Andi Shyti wrote:
> Hi Dmitry,
> 
> just a kind ping, do you have any comment about this?
> 
> Thanks,
> Andi
> 
> On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote:
> > The stmfts (ST-Microelectronics FingerTip S) touchscreen device
> > is a capacitive multi-touch controller mainly for mobile use.
> > 
> > It's connected through i2c bus at the address 0x49 and it
> > interfaces with userspace through input event interface.
> > 
> > At the current state it provides a touchscreen multitouch
> > functionality up to 10 fingers. Each finger is enumerated with a
> > distinctive id (from 0 to 9).
> > 
> > If enabled the device can support single "touch" hovering, by
> > providing three coordinates, x, y and distance.
> > 
> > It is possible to select the touchkey functionality which
> > provides a basic two keys interface for "home" and "back" menu,
> > typical in mobile phones.
> > 
> > Signed-off-by: Andi Shyti 
> > ---
> >  drivers/input/touchscreen/Kconfig  |  12 +
> >  drivers/input/touchscreen/Makefile |   1 +
> >  drivers/input/touchscreen/stmfts.c | 805 
> > +
> >  3 files changed, 818 insertions(+)
> >  create mode 100644 drivers/input/touchscreen/stmfts.c
> > 
> > diff --git a/drivers/input/touchscreen/Kconfig 
> > b/drivers/input/touchscreen/Kconfig
> > index 33c62e5de4fa..f8631c64290d 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -1114,6 +1114,18 @@ config TOUCHSCREEN_ST1232
> >   To compile this driver as a module, choose M here: the
> >   module will be called st1232_ts.
> >  
> > +config TOUCHSCREEN_STMFTS
> > +   tristate "STMicroelectronics STMFTS touchscreen"
> > +   depends on I2C
> > +   depends on INPUT
> > +   depends on LEDS_CLASS
> > +   help
> > + Say Y here if you want support for STMicroelectronics
> > + STMFTS touchscreen.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called stmfts.
> > +
> >  config TOUCHSCREEN_STMPE
> > tristate "STMicroelectronics STMPE touchscreens"
> > depends on MFD_STMPE
> > diff --git a/drivers/input/touchscreen/Makefile 
> > b/drivers/input/touchscreen/Makefile
> > index 18e476948e44..6badce87037b 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -67,6 +67,7 @@ obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_SILEAD)   += silead.o
> >  obj-$(CONFIG_TOUCHSCREEN_SIS_I2C)  += sis_i2c.o
> >  obj-$(CONFIG_TOUCHSCREEN_ST1232)   += st1232.o
> > +obj-$(CONFIG_TOUCHSCREEN_STMFTS)   += stmfts.o
> >  obj-$(CONFIG_TOUCHSCREEN_STMPE)+= stmpe-ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_SUN4I)+= sun4i-ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_SUR40)+= sur40.o
> > diff --git a/drivers/input/touchscreen/stmfts.c 
> > b/drivers/input/touchscreen/stmfts.c
> > new file mode 100644
> > index ..2e18b1456f42
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/stmfts.c
> > @@ -0,0 +1,805 @@
> > +/*
> > + * Copyright (c) 2017 Samsung Electronics Co., Ltd.
> > + * Author: Andi Shyti 
> > + *
> > + * 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.
> > + *
> > + * STMicroelectronics FTS Touchscreen device driver
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* I2C commands */
> > +#define STMFTS_READ_INFO   0x80
> > +#define STMFTS_READ_STATUS 0x84
> > +#define STMFTS_READ_ONE_EVENT  0x85
> > +#define STMFTS_READ_ALL_EVENT  0x86
> > +#define STMFTS_LATEST_EVENT0x87
> > +#define STMFTS_SLEEP_IN0x90
> > +#define STMFTS_SLEEP_OUT   0x91
> > +#define STMFTS_MS_MT_SENSE_OFF 0x92
> > +#define STMFTS_MS_MT_SENSE_ON  0x93
> > +#define STMFTS_SS_HOVER_SENSE_OFF  0x94
> > +#define STMFTS_SS_HOVER_SENSE_ON   0x95
> > +#define STMFTS_MS_KEY_SENSE_OFF0x9a
> > +#define STMFTS_MS_KEY_SENSE_ON 0x9b
> > +#define STMFTS_SYSTEM_RESET0xa0
> > +#define STMFTS_CLEAR_EVENT_STACK   0xa1
> > +#define STMFTS_FULL_FORCE_CALIBRATION  0xa2
> > +#define STMFTS_MS_CX_TUNING0xa3
> > +#define STMFTS_SS_CX_TUNING0xa4
> > +
> > +/* events */
> > +#define STMFTS_EV_NO_EVENT 0x00
> > +#define STMFTS_EV_MULTI_TOUCH_DETECTED 0x02
> > +#define STMFTS_EV_MULTI_TOUCH_ENTER

Re: [PATCH] Revert "arm64: Increase the max granular size"

[Sunil Kovvuri]

>> >> Do you have an explanation on the performance variation when
>> >> L1_CACHE_BYTES is changed? We'd need to understand how the network 
>> stack
>> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for
>> >> non-coherent DMA?).
>> >
>> > network stack use SKB_DATA_ALIGN to align.
>> > ---
>> > #define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \
>> > ~(SMP_CACHE_BYTES - 1))
>> >
>> > #define SMP_CACHE_BYTES L1_CACHE_BYTES
>> > ---
>> > I think this is the reason of performance regression.
>> >
>>
>> Yes this is the reason for performance regression. Due to increases L1 
>> cache alignment the
>> object is coming from next kmalloc slab and skb->truesize is changing 
>> from 2304 bytes to
>> 4352 bytes. This in turn increases sk_wmem_alloc which causes queuing of 
>> less send buffers.

With what traffic did you check 'skb->truesize' ?
Increase from 2304 to 4352 bytes doesn't seem to be real. I checked
with ICMP pkts with maximum
size possible with 1500byte MTU and I don't see such a bump. If the
bump is observed with Iperf
sending TCP packets then I suggest to check if TSO is playing a part over here.

And for 'sk_wmem_alloc', I have done Iperf benchmarking on a 40G
interface and I hit linerate irrespective
of cache line size being 64 or 128 bytes. I guess transmit completion
latency on your HW or driver is very
high and that seems to be the real issue for low performance and not
due to cache line size, basically you are
not able to freeup skbs/buffers fast enough so that new ones get queued up.

Doesn't skb_orphan() solve your issue ?
FYI,
https://patchwork.ozlabs.org/patch/455134/
http://lxr.free-electrons.com/source/drivers/net/ethernet/chelsio/cxgb3/sge.c#L1288


>>
>> We tried different benchmarks and found none which really affects with Cache 
>> line change. If there is no correctness issue,
>> I think we are fine with reverting the patch.
>>
> So, can we revert the patch that makes L1_CACHE_SHIFT 7 or should the patch 
> suggested by Catalin should be mainlined.

This doesn't seem right, as someone said earlier what if there is
another arm64 platform with 32bytes
cacheline size and wants to reduce this further. Either this should be
made platform dependent or left as is
i.e that is maximum of all.

Thanks,
Sunil.

Re: [PATCH] Revert "arm64: Increase the max granular size"

[Sunil Kovvuri]

>> >> Do you have an explanation on the performance variation when
>> >> L1_CACHE_BYTES is changed? We'd need to understand how the network 
>> stack
>> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for
>> >> non-coherent DMA?).
>> >
>> > network stack use SKB_DATA_ALIGN to align.
>> > ---
>> > #define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \
>> > ~(SMP_CACHE_BYTES - 1))
>> >
>> > #define SMP_CACHE_BYTES L1_CACHE_BYTES
>> > ---
>> > I think this is the reason of performance regression.
>> >
>>
>> Yes this is the reason for performance regression. Due to increases L1 
>> cache alignment the
>> object is coming from next kmalloc slab and skb->truesize is changing 
>> from 2304 bytes to
>> 4352 bytes. This in turn increases sk_wmem_alloc which causes queuing of 
>> less send buffers.

With what traffic did you check 'skb->truesize' ?
Increase from 2304 to 4352 bytes doesn't seem to be real. I checked
with ICMP pkts with maximum
size possible with 1500byte MTU and I don't see such a bump. If the
bump is observed with Iperf
sending TCP packets then I suggest to check if TSO is playing a part over here.

And for 'sk_wmem_alloc', I have done Iperf benchmarking on a 40G
interface and I hit linerate irrespective
of cache line size being 64 or 128 bytes. I guess transmit completion
latency on your HW or driver is very
high and that seems to be the real issue for low performance and not
due to cache line size, basically you are
not able to freeup skbs/buffers fast enough so that new ones get queued up.

Doesn't skb_orphan() solve your issue ?
FYI,
https://patchwork.ozlabs.org/patch/455134/
http://lxr.free-electrons.com/source/drivers/net/ethernet/chelsio/cxgb3/sge.c#L1288


>>
>> We tried different benchmarks and found none which really affects with Cache 
>> line change. If there is no correctness issue,
>> I think we are fine with reverting the patch.
>>
> So, can we revert the patch that makes L1_CACHE_SHIFT 7 or should the patch 
> suggested by Catalin should be mainlined.

This doesn't seem right, as someone said earlier what if there is
another arm64 platform with 32bytes
cacheline size and wants to reduce this further. Either this should be
made platform dependent or left as is
i.e that is maximum of all.

Thanks,
Sunil.

[PATCH] ARM: sunxi: h3/h5: fix the compatible of R_CCU

[Icenowy Zheng]

The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible.

Fix it by changing it to the correct H3 compatible.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 1aeeacb3a884..d0067fec99de 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -558,7 +558,7 @@
};
 
r_ccu: clock@1f01400 {
-   compatible = "allwinner,sun50i-a64-r-ccu";
+   compatible = "allwinner,sun8i-h3-r-ccu";
reg = <0x01f01400 0x100>;
clocks = <>, <>, <>;
clock-names = "hosc", "losc", "iosc";
-- 
2.12.2

[PATCH] ARM: sunxi: h3/h5: fix the compatible of R_CCU

[Icenowy Zheng]

The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible.

Fix it by changing it to the correct H3 compatible.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 1aeeacb3a884..d0067fec99de 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -558,7 +558,7 @@
};
 
r_ccu: clock@1f01400 {
-   compatible = "allwinner,sun50i-a64-r-ccu";
+   compatible = "allwinner,sun8i-h3-r-ccu";
reg = <0x01f01400 0x100>;
clocks = <>, <>, <>;
clock-names = "hosc", "losc", "iosc";
-- 
2.12.2

Re: [PATCH v2 2/2] usb: dwc2: add multiple clocks handling

[Frank Wang]

Hi John,

I apologize if this was presumptuous, would you like to have a look this 
series please?



On 2017/3/28 21:49, Felipe Balbi wrote:

Hi,

Heiko Stübner  writes:

Am Donnerstag, 9. Februar 2017, 10:44:39 CET schrieb Frank Wang:

Since dwc2 may have one or more input clocks need to manage for some
platform, so this adds change clk to clk's array of struct dwc2_hsotg
to handle more clocks operation.

Signed-off-by: Frank Wang 

for the simple clock handling the dwc2-driver does right now, this looks
adquate and honoring EPROBE_DEFER is a nice touch ;-), so

Reviewed-by: Heiko Stuebner 

John, care to look at this series?



BR.
Frank

Re: [PATCH v2 2/2] usb: dwc2: add multiple clocks handling

[Frank Wang]

Hi John,

I apologize if this was presumptuous, would you like to have a look this 
series please?



On 2017/3/28 21:49, Felipe Balbi wrote:

Hi,

Heiko Stübner  writes:

Am Donnerstag, 9. Februar 2017, 10:44:39 CET schrieb Frank Wang:

Since dwc2 may have one or more input clocks need to manage for some
platform, so this adds change clk to clk's array of struct dwc2_hsotg
to handle more clocks operation.

Signed-off-by: Frank Wang 

for the simple clock handling the dwc2-driver does right now, this looks
adquate and honoring EPROBE_DEFER is a nice touch ;-), so

Reviewed-by: Heiko Stuebner 

John, care to look at this series?



BR.
Frank

Re: [PATCH 3/8] x86/boot/64: Add support of additional page table level during early boot

[Ingo Molnar]

* Kirill A. Shutemov  wrote:

> On Tue, Apr 11, 2017 at 07:09:07AM -0700, Andi Kleen wrote:
> > > I'll look closer (building proccess it's rather complicated), but my
> > > understanding is that VDSO is stand-alone binary and doesn't really links
> > > with the rest of the kernel, rather included as blob, no?
> > > 
> > > Andy, may be you have an idea?
> > 
> > There isn't any way I know of to directly link them together. The ELF 
> > format wasn't designed for that. You would need to merge blobs and then use
> > manual jump vectors, like the 16bit startup code does. It would be likely
> > complicated and ugly.
> 
> Ingo, can we proceed without coverting this assembly to C?
> 
> I'm committed to convert it to C later if we'll find reasonable solution
> to the issue.

So one way to do it would be to build it standalone as a .o, then add it not to 
the regular kernel objects link target (as you found out it's not possible to 
link 
32-bit and 64-bit objects), but to link it in a manual fashion, as part of 
vmlinux.bin.all-y in arch/x86/boot/compressed/Makefile.

But there would be other complications with this approach, such as we'd have to 
add a size field and there might be symbol linking problems ...

Another, pretty hacky way would be to generate a .S from the .c, then 
post-process 
the .S and essentially generate today's 32-bit .S from it.

Probably not worth the trouble.

Thanks,

Ingo

Re: [PATCH 3/8] x86/boot/64: Add support of additional page table level during early boot

[Ingo Molnar]

* Kirill A. Shutemov  wrote:

> On Tue, Apr 11, 2017 at 07:09:07AM -0700, Andi Kleen wrote:
> > > I'll look closer (building proccess it's rather complicated), but my
> > > understanding is that VDSO is stand-alone binary and doesn't really links
> > > with the rest of the kernel, rather included as blob, no?
> > > 
> > > Andy, may be you have an idea?
> > 
> > There isn't any way I know of to directly link them together. The ELF 
> > format wasn't designed for that. You would need to merge blobs and then use
> > manual jump vectors, like the 16bit startup code does. It would be likely
> > complicated and ugly.
> 
> Ingo, can we proceed without coverting this assembly to C?
> 
> I'm committed to convert it to C later if we'll find reasonable solution
> to the issue.

So one way to do it would be to build it standalone as a .o, then add it not to 
the regular kernel objects link target (as you found out it's not possible to 
link 
32-bit and 64-bit objects), but to link it in a manual fashion, as part of 
vmlinux.bin.all-y in arch/x86/boot/compressed/Makefile.

But there would be other complications with this approach, such as we'd have to 
add a size field and there might be symbol linking problems ...

Another, pretty hacky way would be to generate a .S from the .c, then 
post-process 
the .S and essentially generate today's 32-bit .S from it.

Probably not worth the trouble.

Thanks,

Ingo

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Russell King - ARM Linux]

On Sun, Apr 16, 2017 at 07:10:21PM -0600, Shuah Khan wrote:
> On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote:
> > On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote:
>  This would be however quite large task, especially taking into account
>  all current users of DMA-buf framework...
> >>> Yeah it will be a large task.
> >>
> >> Maybe once scatterlist are switched to pfns, changing dmabuf internal
> >> memory representation to pfn array might be much easier.
> > 
> > Switching to a PFN array won't work either as we have no cross-arch
> > way to translate PFNs to a DMA address and vice versa.  Yes, we have
> > them in ARM, but they are an _implementation detail_ of ARM's
> > DMA API support, they are not for use by drivers.
> > 
> > So, the very first problem that needs solving is this:
> > 
> >   How do we go from a coherent DMA allocation for device X to a set
> >   of DMA addresses for device Y.
> > 
> > Essentially, we need a way of remapping the DMA buffer for use with
> > another device, and returning a DMA address suitable for that device.
> > This could well mean that we need to deal with setting up an IOMMU
> > mapping.  My guess is that this needs to happen at the DMA coherent
> > API level - the DMA coherent API needs to be augmented with support
> > for this.  I'll call this "DMA coherent remap".
> > 
> > We then need to think about how to pass this through the dma-buf API.
> > dma_map_sg() is done by the exporter, who should know what kind of
> > memory is being exported.  The exporter can avoid calling dma_map_sg()
> > if it knows in advance that it is exporting DMA coherent memory.
> > Instead, the exporter can simply create a scatterlist with the DMA
> > address and DMA length prepopulated with the results of the DMA
> > coherent remap operation above.
> 
> The only way to conclusively say that it is coming from coherent area
> is at the time it is getting allocated in dma_alloc_from_coherent().
> Since dma_alloc_attrs() will go on to find memory from other areas if
> dma_alloc_from_coherent() doesn't allocate memory.

Sorry, I disagree.

The only thing that matters is "did this memory come from
dma_alloc_coherent()".  It doesn't matter where dma_alloc_coherent()
ultimately got the memory from, it's memory from the coherent allocator
interface, and it should not be passed back into the streaming APIs.
It is, after all, DMA _coherent_ memory, passing it into the streaming
APIs which is for DMA _noncoherent_ memory is insane - the streaming APIs
can bring extra expensive cache flushes, which are not required for
DMA _coherent_ memory.

The exporter should know where it got the memory from.  It's really not
sane for anyone except the _original_ allocator to be exporting memory
through a DMA buffer - only the original allocator knows the properties
of that memory, and how to map it, whether that be for DMA, kmap or
mmap.

If a dmabuf is imported into a driver and then re-exported, the original
dmabuf should be what is re-exported, not some creation of the driver -
the re-exporting driver can't know what the properties of the memory
backing the dmabuf are, so anything else is just insane.

> How about adding get_sgtable, map_sg, unmap_sg to dma_buf_ops. The right
> ops need to be installed based on buffer type. As I mentioned before, we
> don't know which memory we got until dma_alloc_from_coherent() finds
> memory in dev->mem area. So how about using the dma_check_dev_coherent()
> to determine which ops we need. These could be set based on buffer type.
> vb2_dc_get_dmabuf() can do that.

Given my statement above, I don't believe any of that is necessary.  All
memory allocated from dma_alloc_coherent() is DMA coherent.  So, if
memory was obtained from dma_alloc_coherent() or similar, then it must
not be passed to the streaming DMA API.  It doesn't matter where it
ultimately came from.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Russell King - ARM Linux]

On Sun, Apr 16, 2017 at 07:10:21PM -0600, Shuah Khan wrote:
> On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote:
> > On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote:
>  This would be however quite large task, especially taking into account
>  all current users of DMA-buf framework...
> >>> Yeah it will be a large task.
> >>
> >> Maybe once scatterlist are switched to pfns, changing dmabuf internal
> >> memory representation to pfn array might be much easier.
> > 
> > Switching to a PFN array won't work either as we have no cross-arch
> > way to translate PFNs to a DMA address and vice versa.  Yes, we have
> > them in ARM, but they are an _implementation detail_ of ARM's
> > DMA API support, they are not for use by drivers.
> > 
> > So, the very first problem that needs solving is this:
> > 
> >   How do we go from a coherent DMA allocation for device X to a set
> >   of DMA addresses for device Y.
> > 
> > Essentially, we need a way of remapping the DMA buffer for use with
> > another device, and returning a DMA address suitable for that device.
> > This could well mean that we need to deal with setting up an IOMMU
> > mapping.  My guess is that this needs to happen at the DMA coherent
> > API level - the DMA coherent API needs to be augmented with support
> > for this.  I'll call this "DMA coherent remap".
> > 
> > We then need to think about how to pass this through the dma-buf API.
> > dma_map_sg() is done by the exporter, who should know what kind of
> > memory is being exported.  The exporter can avoid calling dma_map_sg()
> > if it knows in advance that it is exporting DMA coherent memory.
> > Instead, the exporter can simply create a scatterlist with the DMA
> > address and DMA length prepopulated with the results of the DMA
> > coherent remap operation above.
> 
> The only way to conclusively say that it is coming from coherent area
> is at the time it is getting allocated in dma_alloc_from_coherent().
> Since dma_alloc_attrs() will go on to find memory from other areas if
> dma_alloc_from_coherent() doesn't allocate memory.

Sorry, I disagree.

The only thing that matters is "did this memory come from
dma_alloc_coherent()".  It doesn't matter where dma_alloc_coherent()
ultimately got the memory from, it's memory from the coherent allocator
interface, and it should not be passed back into the streaming APIs.
It is, after all, DMA _coherent_ memory, passing it into the streaming
APIs which is for DMA _noncoherent_ memory is insane - the streaming APIs
can bring extra expensive cache flushes, which are not required for
DMA _coherent_ memory.

The exporter should know where it got the memory from.  It's really not
sane for anyone except the _original_ allocator to be exporting memory
through a DMA buffer - only the original allocator knows the properties
of that memory, and how to map it, whether that be for DMA, kmap or
mmap.

If a dmabuf is imported into a driver and then re-exported, the original
dmabuf should be what is re-exported, not some creation of the driver -
the re-exporting driver can't know what the properties of the memory
backing the dmabuf are, so anything else is just insane.

> How about adding get_sgtable, map_sg, unmap_sg to dma_buf_ops. The right
> ops need to be installed based on buffer type. As I mentioned before, we
> don't know which memory we got until dma_alloc_from_coherent() finds
> memory in dev->mem area. So how about using the dma_check_dev_coherent()
> to determine which ops we need. These could be set based on buffer type.
> vb2_dc_get_dmabuf() can do that.

Given my statement above, I don't believe any of that is necessary.  All
memory allocated from dma_alloc_coherent() is DMA coherent.  So, if
memory was obtained from dma_alloc_coherent() or similar, then it must
not be passed to the streaming DMA API.  It doesn't matter where it
ultimately came from.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] Make DMABUF a menuconfig to ease disabling it all

[Vincent Legoll]

No need to get into the submenu to disable all DMABUF-related config entries

Make the selecters also select the new DMABUF menuconfig

Signed-off-by: Vincent Legoll 
---
 drivers/dma-buf/Kconfig | 7 ---
 drivers/gpu/drm/Kconfig | 1 +
 drivers/gpu/drm/msm/Kconfig | 1 +
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index ed3b785..ad5075f 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -1,8 +1,10 @@
-menu "DMABUF options"
+menuconfig DMABUF
+   bool "DMABUF options"
 
 config SYNC_FILE
bool "Explicit Synchronization Framework"
default n
+   depends on DMABUF
select ANON_INODES
select DMA_SHARED_BUFFER
---help---
@@ -20,6 +22,7 @@ config SYNC_FILE
 config SW_SYNC
bool "Sync File Validation Framework"
default n
+   depends on DMABUF
depends on SYNC_FILE
depends on DEBUG_FS
---help---
@@ -29,5 +32,3 @@ config SW_SYNC
 
  WARNING: improper use of this can result in deadlocking kernel
  drivers from userspace. Intended for test and debug only.
-
-endmenu
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 88e01e08e..c9c21c8 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+   select DMABUF
select SYNC_FILE
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 5b8e23d..fdc621b 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -12,6 +12,7 @@ config DRM_MSM
select TMPFS
select QCOM_SCM
select SND_SOC_HDMI_CODEC if SND_SOC
+   select DMABUF
select SYNC_FILE
default y
help
-- 
2.9.3

[PATCH] Make DMABUF a menuconfig to ease disabling it all

[Vincent Legoll]

No need to get into the submenu to disable all DMABUF-related config entries

Make the selecters also select the new DMABUF menuconfig

Signed-off-by: Vincent Legoll 
---
 drivers/dma-buf/Kconfig | 7 ---
 drivers/gpu/drm/Kconfig | 1 +
 drivers/gpu/drm/msm/Kconfig | 1 +
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index ed3b785..ad5075f 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -1,8 +1,10 @@
-menu "DMABUF options"
+menuconfig DMABUF
+   bool "DMABUF options"
 
 config SYNC_FILE
bool "Explicit Synchronization Framework"
default n
+   depends on DMABUF
select ANON_INODES
select DMA_SHARED_BUFFER
---help---
@@ -20,6 +22,7 @@ config SYNC_FILE
 config SW_SYNC
bool "Sync File Validation Framework"
default n
+   depends on DMABUF
depends on SYNC_FILE
depends on DEBUG_FS
---help---
@@ -29,5 +32,3 @@ config SW_SYNC
 
  WARNING: improper use of this can result in deadlocking kernel
  drivers from userspace. Intended for test and debug only.
-
-endmenu
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 88e01e08e..c9c21c8 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+   select DMABUF
select SYNC_FILE
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 5b8e23d..fdc621b 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -12,6 +12,7 @@ config DRM_MSM
select TMPFS
select QCOM_SCM
select SND_SOC_HDMI_CODEC if SND_SOC
+   select DMABUF
select SYNC_FILE
default y
help
-- 
2.9.3

[PATCH] f2fs: introduce __check_rb_tree_consistence

[Chao Yu]

Introduce __check_rb_tree_consistence to check consistence of rb-tree
based discard cache in runtime.

Signed-off-by: Chao Yu 
---
 fs/f2fs/extent_cache.c | 32 
 fs/f2fs/f2fs.h |  2 ++
 fs/f2fs/segment.c  | 15 +--
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
index 221ad086ee00..2f98d7039701 100644
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -159,6 +159,38 @@ struct rb_entry *__lookup_rb_tree_ret(struct rb_root *root,
return re;
 }
 
+bool __check_rb_tree_consistence(struct f2fs_sb_info *sbi,
+   struct rb_root *root)
+{
+#ifdef CONFIG_F2FS_CHECK_FS
+   struct rb_node *cur = rb_first(root), *next;
+   struct rb_entry *cur_re, *next_re;
+
+   if (!cur)
+   return true;
+
+   while (cur) {
+   next = rb_next(cur);
+   if (!next)
+   return true;
+
+   cur_re = rb_entry(cur, struct rb_entry, rb_node);
+   next_re = rb_entry(next, struct rb_entry, rb_node);
+
+   if (cur_re->ofs + cur_re->len > next_re->ofs) {
+   f2fs_msg(sbi->sb, KERN_INFO, "inconsistent rbtree, "
+   "cur(%u, %u) next(%u, %u)",
+   cur_re->ofs, cur_re->len,
+   next_re->ofs, next_re->len);
+   return false;
+   }
+
+   cur = next;
+   }
+#endif
+   return true;
+}
+
 static struct kmem_cache *extent_tree_slab;
 static struct kmem_cache *extent_node_slab;
 
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index bd3519059ae8..62fcb52be0ba 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2622,6 +2622,8 @@ struct rb_entry *__lookup_rb_tree_ret(struct rb_root 
*root,
struct rb_entry **prev_entry, struct rb_entry **next_entry,
struct rb_node ***insert_p, struct rb_node **insert_parent,
bool force);
+bool __check_rb_tree_consistence(struct f2fs_sb_info *sbi,
+   struct rb_root *root);
 unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info *sbi, int nr_shrink);
 bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext);
 void f2fs_drop_extent_tree(struct inode *inode);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 08b9e3806a50..4be74c99643d 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -833,6 +833,7 @@ static void __punch_discard_cmd(struct f2fs_sb_info *sbi,
if (blkaddr > di.lstart) {
dc->len = blkaddr - dc->lstart;
__relocate_discard_cmd(dcc, dc);
+   f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi, >root));
modified = true;
}
 
@@ -842,11 +843,15 @@ static void __punch_discard_cmd(struct f2fs_sb_info *sbi,
di.start + blkaddr + 1 - di.lstart,
di.lstart + di.len - 1 - blkaddr,
NULL, NULL);
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
} else {
dc->lstart++;
dc->len--;
dc->start++;
__relocate_discard_cmd(dcc, dc);
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
}
}
 }
@@ -906,6 +911,8 @@ static void __update_discard_tree_range(struct f2fs_sb_info 
*sbi,
__is_discard_back_mergeable(, _dc->di)) {
prev_dc->di.len += di.len;
__relocate_discard_cmd(dcc, prev_dc);
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
di = prev_dc->di;
tdc = prev_dc;
merged = true;
@@ -920,13 +927,17 @@ static void __update_discard_tree_range(struct 
f2fs_sb_info *sbi,
__relocate_discard_cmd(dcc, next_dc);
if (tdc)
__remove_discard_cmd(sbi, tdc);
-
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
merged = true;
}
 
-   if (!merged)
+   if (!merged) {
__insert_discard_tree(sbi, bdev, di.lstart, di.start,
di.len, NULL, NULL);
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
+   }
  next:
prev_dc = next_dc;
if 

[PATCH] f2fs: introduce __check_rb_tree_consistence

[Chao Yu]

Introduce __check_rb_tree_consistence to check consistence of rb-tree
based discard cache in runtime.

Signed-off-by: Chao Yu 
---
 fs/f2fs/extent_cache.c | 32 
 fs/f2fs/f2fs.h |  2 ++
 fs/f2fs/segment.c  | 15 +--
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
index 221ad086ee00..2f98d7039701 100644
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -159,6 +159,38 @@ struct rb_entry *__lookup_rb_tree_ret(struct rb_root *root,
return re;
 }
 
+bool __check_rb_tree_consistence(struct f2fs_sb_info *sbi,
+   struct rb_root *root)
+{
+#ifdef CONFIG_F2FS_CHECK_FS
+   struct rb_node *cur = rb_first(root), *next;
+   struct rb_entry *cur_re, *next_re;
+
+   if (!cur)
+   return true;
+
+   while (cur) {
+   next = rb_next(cur);
+   if (!next)
+   return true;
+
+   cur_re = rb_entry(cur, struct rb_entry, rb_node);
+   next_re = rb_entry(next, struct rb_entry, rb_node);
+
+   if (cur_re->ofs + cur_re->len > next_re->ofs) {
+   f2fs_msg(sbi->sb, KERN_INFO, "inconsistent rbtree, "
+   "cur(%u, %u) next(%u, %u)",
+   cur_re->ofs, cur_re->len,
+   next_re->ofs, next_re->len);
+   return false;
+   }
+
+   cur = next;
+   }
+#endif
+   return true;
+}
+
 static struct kmem_cache *extent_tree_slab;
 static struct kmem_cache *extent_node_slab;
 
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index bd3519059ae8..62fcb52be0ba 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2622,6 +2622,8 @@ struct rb_entry *__lookup_rb_tree_ret(struct rb_root 
*root,
struct rb_entry **prev_entry, struct rb_entry **next_entry,
struct rb_node ***insert_p, struct rb_node **insert_parent,
bool force);
+bool __check_rb_tree_consistence(struct f2fs_sb_info *sbi,
+   struct rb_root *root);
 unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info *sbi, int nr_shrink);
 bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext);
 void f2fs_drop_extent_tree(struct inode *inode);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 08b9e3806a50..4be74c99643d 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -833,6 +833,7 @@ static void __punch_discard_cmd(struct f2fs_sb_info *sbi,
if (blkaddr > di.lstart) {
dc->len = blkaddr - dc->lstart;
__relocate_discard_cmd(dcc, dc);
+   f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi, >root));
modified = true;
}
 
@@ -842,11 +843,15 @@ static void __punch_discard_cmd(struct f2fs_sb_info *sbi,
di.start + blkaddr + 1 - di.lstart,
di.lstart + di.len - 1 - blkaddr,
NULL, NULL);
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
} else {
dc->lstart++;
dc->len--;
dc->start++;
__relocate_discard_cmd(dcc, dc);
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
}
}
 }
@@ -906,6 +911,8 @@ static void __update_discard_tree_range(struct f2fs_sb_info 
*sbi,
__is_discard_back_mergeable(, _dc->di)) {
prev_dc->di.len += di.len;
__relocate_discard_cmd(dcc, prev_dc);
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
di = prev_dc->di;
tdc = prev_dc;
merged = true;
@@ -920,13 +927,17 @@ static void __update_discard_tree_range(struct 
f2fs_sb_info *sbi,
__relocate_discard_cmd(dcc, next_dc);
if (tdc)
__remove_discard_cmd(sbi, tdc);
-
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
merged = true;
}
 
-   if (!merged)
+   if (!merged) {
__insert_discard_tree(sbi, bdev, di.lstart, di.start,
di.len, NULL, NULL);
+   f2fs_bug_on(sbi,
+   !__check_rb_tree_consistence(sbi, >root));
+   }
  next:
prev_dc = next_dc;
if (!prev_dc)
-- 

Re: [PATCH RFC] Make BCMA a menuconfig to ease disabling it all

[Vincent Legoll]

Argh,

looks like the "--in-reply-to" did not hook it up properly...

This was intended as a reply to:
http://lkml.iu.edu/hypermail/linux/kernel/1704.1/04654.html
Re: [PATCH] Make AMBA a menuconfig to ease disabling it all
from (Fri Apr 14 2017 - 08:33:57 EST)

Sorry

-- 
Vincent Legoll

Re: [PATCH RFC] Make BCMA a menuconfig to ease disabling it all

[Vincent Legoll]

Argh,

looks like the "--in-reply-to" did not hook it up properly...

This was intended as a reply to:
http://lkml.iu.edu/hypermail/linux/kernel/1704.1/04654.html
Re: [PATCH] Make AMBA a menuconfig to ease disabling it all
from (Fri Apr 14 2017 - 08:33:57 EST)

Sorry

-- 
Vincent Legoll

[PATCH RFC] Make BCMA a menuconfig to ease disabling it all

[Vincent Legoll]

Hello,

this is more what I wanted to achieve, an easily disableable BCMA menuconfig.

This is working as intended on x86_64 defconfig, whereas it is harder to disable
for ARCH=arm because of "select"s. But that's less of an issue, as those arch's
defconfigs may very well want the feature enbled, and that would make sense.

Any input appreciated.

Thanks

[PATCH] Make BCMA a menuconfig to ease disabling it all

[Vincent Legoll]

No need to get into the submenu to disable all BCMA-related config entries

Signed-off-by: Vincent Legoll 
---
 drivers/bcma/Kconfig | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index b5c48a8..54f81c5 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -3,11 +3,8 @@ config BCMA_POSSIBLE
depends on HAS_IOMEM && HAS_DMA
default y
 
-menu "Broadcom specific AMBA"
-   depends on BCMA_POSSIBLE
-
-config BCMA
-   tristate "BCMA support"
+menuconfig BCMA
+   tristate "Broadcom specific AMBA"
depends on BCMA_POSSIBLE
help
  Bus driver for Broadcom specific Advanced Microcontroller Bus
@@ -117,5 +114,3 @@ config BCMA_DEBUG
  This turns on additional debugging messages.
 
  If unsure, say N
-
-endmenu
-- 
2.9.3

[PATCH RFC] Make BCMA a menuconfig to ease disabling it all

[Vincent Legoll]

Hello,

this is more what I wanted to achieve, an easily disableable BCMA menuconfig.

This is working as intended on x86_64 defconfig, whereas it is harder to disable
for ARCH=arm because of "select"s. But that's less of an issue, as those arch's
defconfigs may very well want the feature enbled, and that would make sense.

Any input appreciated.

Thanks

[PATCH] Make BCMA a menuconfig to ease disabling it all

[Vincent Legoll]

No need to get into the submenu to disable all BCMA-related config entries

Signed-off-by: Vincent Legoll 
---
 drivers/bcma/Kconfig | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index b5c48a8..54f81c5 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -3,11 +3,8 @@ config BCMA_POSSIBLE
depends on HAS_IOMEM && HAS_DMA
default y
 
-menu "Broadcom specific AMBA"
-   depends on BCMA_POSSIBLE
-
-config BCMA
-   tristate "BCMA support"
+menuconfig BCMA
+   tristate "Broadcom specific AMBA"
depends on BCMA_POSSIBLE
help
  Bus driver for Broadcom specific Advanced Microcontroller Bus
@@ -117,5 +114,3 @@ config BCMA_DEBUG
  This turns on additional debugging messages.
 
  If unsure, say N
-
-endmenu
-- 
2.9.3

Re: [PATCH 0/6] fujitsu-laptop: LED cleanup

[Jonathan Woithe]

On Fri, Apr 07, 2017 at 03:07:07PM +0200, Micha?? K??pie?? wrote:
> This patch series cleans up parts of fujitsu-laptop responsible for
> handling LED class devices.  It was tested on a Lifebook E744.  It
> depends on the previous patch series I submitted for fujitsu-laptop and
> should be applied on top of the backlight cleanup series.

I have completed my review.  The changes in this patch series are reasonably
extensive but should not result in any observable changes in behaviour. 
They represent a significant modernisation of the code, taking advantage of
the current approach to module architecture.  Unfortunately I do not have
hardware which includes the LEDs which these changes affect, so I cannot
confirm the absence of regressions.  I note however that it has been tested
on a Lifebook E744.

My only question about this patch set relates to patch 5/6 ("fujitsu-laptop:
do not log LED registration failures").  While it is true that driver core
will log an error due to the error flagged by the return value from
acpi_fujitsu_laptop_add() (as explained in the commit message), the
elimination of the pr_err() statements means that we loose the ability to
see which LED caused the problem.  All we know is that there has been an
error flagged by something within (or called by) acpi_fujitsu_laptop_add(). 
This may be related to LEDs or anything else initialised by
acpi_fujitsu_laptop_add().

Is the resulting simplification of code worth the loss of this finer grained
information in the event of a LED registration error?

Regards
  jonathan

RE: [PATCH] ACPICA: Export mutex functions

[Zheng, Lv]

Hi,

> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv
> Sent: Monday, April 17, 2017 5:40 PM
> To: Guenter Roeck ; Moore, Robert 
> Cc: linux-a...@vger.kernel.org; de...@acpica.org; Wysocki, Rafael J 
> ;
> linux-kernel@vger.kernel.org
> Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions
> 
> Hi,
> 
> > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > Subject: Re: [PATCH] ACPICA: Export mutex functions
> >
> > On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote:
> > > The ACPICA mutex functions are based on the host OS functions, so they 
> > > don't really buy you
> anything.
> > You should just use the native Linux functions.
> > >
> >
> > You mean they don't really acquire the requested ACPI mutex,
> > and the underlying DSDT which declares and uses the mutex
> > just ignores if the mutex was acquired by acpi_acquire_mutex() ?
> >
> > To clarify: You are saying that code such as
> >
> > acpi_status status;
> >
> > status = acpi_acquire_mutex(NULL, "\\_SB.PCI0.SBRG.SIO1.MUT0", 0x10);
> > if (ACPI_FAILURE(status)) {
> > pr_err("Failed to acquire ACPI mutex\n");
> > return -EBUSY;
> > }
> 
> Why do you need to access \_SB.PCI0.SBRG.SIO1.MUT0?
> OSPM should only invoke entry methods predefined by ACPI spec or whatever 
> specs.
> There shouldn't be any needs that a driver acquires an arbitrary AML mutex.
> You do not seem to have justified the usage model, IMO.
> 
> Thanks
> Lv
> 
> > ...
> >
> > when used in conjunction with
> >
> > ...
> > Mutex (MUT0, 0x00)
> > Method (ENFG, 1, NotSerialized)
> > {
> > Acquire (MUT0, 0x0FFF)
> > ...
> > }
> >
> > doesn't really provide exclusive access to the resource(s) protected
> > by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?

IMO, the use case you are talking about is commonly seen in an operation region 
access code.
Most likely, we'll prepare a driver own lock, and use it for both driver 
initiated accesses and AML initiated accesses.

Finally, how can the driver writer know which mutex he should acquire?
AML mutexes should be invisible to the OS (except the global lock).

So I'm really confused by your argument.
Please explain in details - what the resource is.

Thanks
Lv


> >
> > Outch. Really ?
> >
> > Thanks,
> > Guenter
> >
> > >
> > > > -Original Message-
> > > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > > To: Moore, Robert ; Zheng, Lv
> > > > ; Wysocki, Rafael J ;
> > > > Len Brown 
> > > > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > > ker...@vger.kernel.org; Guenter Roeck 
> > > > Subject: [PATCH] ACPICA: Export mutex functions
> > > >
> > > > Mutex functions may be needed by drivers. Examples are accesses to
> > > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > > environmental monitor registers, both which may also be accessed through
> > > > DSDT.
> > > >
> > > > Signed-off-by: Guenter Roeck 
> > > > ---
> > > >  drivers/acpi/acpica/utxfmutex.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > > 100644
> > > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
> > > > pathname, u16 timeout)
> > > > status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, 
> > > > timeout);
> > > > return (status);
> > > >  }
> > > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > > >
> > > >
> > > > /***
> > > > 
> > > >   *
> > > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
> > > > acpi_string pathname)
> > > > acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > > > return (AE_OK);
> > > >  }
> > > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > > --
> > > > 2.7.4
> > >
> ___
> Devel mailing list
> de...@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel

Re: [PATCH 0/6] fujitsu-laptop: LED cleanup

[Jonathan Woithe]

On Fri, Apr 07, 2017 at 03:07:07PM +0200, Micha?? K??pie?? wrote:
> This patch series cleans up parts of fujitsu-laptop responsible for
> handling LED class devices.  It was tested on a Lifebook E744.  It
> depends on the previous patch series I submitted for fujitsu-laptop and
> should be applied on top of the backlight cleanup series.

I have completed my review.  The changes in this patch series are reasonably
extensive but should not result in any observable changes in behaviour. 
They represent a significant modernisation of the code, taking advantage of
the current approach to module architecture.  Unfortunately I do not have
hardware which includes the LEDs which these changes affect, so I cannot
confirm the absence of regressions.  I note however that it has been tested
on a Lifebook E744.

My only question about this patch set relates to patch 5/6 ("fujitsu-laptop:
do not log LED registration failures").  While it is true that driver core
will log an error due to the error flagged by the return value from
acpi_fujitsu_laptop_add() (as explained in the commit message), the
elimination of the pr_err() statements means that we loose the ability to
see which LED caused the problem.  All we know is that there has been an
error flagged by something within (or called by) acpi_fujitsu_laptop_add(). 
This may be related to LEDs or anything else initialised by
acpi_fujitsu_laptop_add().

Is the resulting simplification of code worth the loss of this finer grained
information in the event of a LED registration error?

Regards
  jonathan

RE: [PATCH] ACPICA: Export mutex functions

[Zheng, Lv]

Hi,

> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv
> Sent: Monday, April 17, 2017 5:40 PM
> To: Guenter Roeck ; Moore, Robert 
> Cc: linux-a...@vger.kernel.org; de...@acpica.org; Wysocki, Rafael J 
> ;
> linux-kernel@vger.kernel.org
> Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions
> 
> Hi,
> 
> > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > Subject: Re: [PATCH] ACPICA: Export mutex functions
> >
> > On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote:
> > > The ACPICA mutex functions are based on the host OS functions, so they 
> > > don't really buy you
> anything.
> > You should just use the native Linux functions.
> > >
> >
> > You mean they don't really acquire the requested ACPI mutex,
> > and the underlying DSDT which declares and uses the mutex
> > just ignores if the mutex was acquired by acpi_acquire_mutex() ?
> >
> > To clarify: You are saying that code such as
> >
> > acpi_status status;
> >
> > status = acpi_acquire_mutex(NULL, "\\_SB.PCI0.SBRG.SIO1.MUT0", 0x10);
> > if (ACPI_FAILURE(status)) {
> > pr_err("Failed to acquire ACPI mutex\n");
> > return -EBUSY;
> > }
> 
> Why do you need to access \_SB.PCI0.SBRG.SIO1.MUT0?
> OSPM should only invoke entry methods predefined by ACPI spec or whatever 
> specs.
> There shouldn't be any needs that a driver acquires an arbitrary AML mutex.
> You do not seem to have justified the usage model, IMO.
> 
> Thanks
> Lv
> 
> > ...
> >
> > when used in conjunction with
> >
> > ...
> > Mutex (MUT0, 0x00)
> > Method (ENFG, 1, NotSerialized)
> > {
> > Acquire (MUT0, 0x0FFF)
> > ...
> > }
> >
> > doesn't really provide exclusive access to the resource(s) protected
> > by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?

IMO, the use case you are talking about is commonly seen in an operation region 
access code.
Most likely, we'll prepare a driver own lock, and use it for both driver 
initiated accesses and AML initiated accesses.

Finally, how can the driver writer know which mutex he should acquire?
AML mutexes should be invisible to the OS (except the global lock).

So I'm really confused by your argument.
Please explain in details - what the resource is.

Thanks
Lv


> >
> > Outch. Really ?
> >
> > Thanks,
> > Guenter
> >
> > >
> > > > -Original Message-
> > > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > > To: Moore, Robert ; Zheng, Lv
> > > > ; Wysocki, Rafael J ;
> > > > Len Brown 
> > > > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > > ker...@vger.kernel.org; Guenter Roeck 
> > > > Subject: [PATCH] ACPICA: Export mutex functions
> > > >
> > > > Mutex functions may be needed by drivers. Examples are accesses to
> > > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > > environmental monitor registers, both which may also be accessed through
> > > > DSDT.
> > > >
> > > > Signed-off-by: Guenter Roeck 
> > > > ---
> > > >  drivers/acpi/acpica/utxfmutex.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > > 100644
> > > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
> > > > pathname, u16 timeout)
> > > > status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, 
> > > > timeout);
> > > > return (status);
> > > >  }
> > > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > > >
> > > >
> > > > /***
> > > > 
> > > >   *
> > > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
> > > > acpi_string pathname)
> > > > acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > > > return (AE_OK);
> > > >  }
> > > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > > --
> > > > 2.7.4
> > >
> ___
> Devel mailing list
> de...@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel

Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume

[Sergei Shtylyov]

Hello!

On 4/17/2017 2:19 AM, Michael S. Tsirkin wrote:


Applications that consume a batch of entries in one go
can benefit from ability to return some of them back
into the ring.

Add an API for that - assuming there's space. If there's no space
naturally we can't do this and have to drop entries, but this implies
ring is full so we'd likely drop some anyway.

Signed-off-by: Michael S. Tsirkin 
---

Jason, in my mind the biggest issue with your batching patchset is the
backet drops on disconnect.  This API will help avoid that in the common


   Packet?

[...]

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 783e7f5..5fbeab4 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -457,6 +457,63 @@ static inline int ptr_ring_init(struct ptr_ring *r, int 
size, gfp_t gfp)
return 0;
 }

+/*
+ * Return entries into ring. Destroy entries that don't fit.
+ *
+ * Note: this is expected to be a rare slow path operation.
+ *
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
+static inline void ptr_ring_unconsume(struct ptr_ring *r, void **batch, int n,
+ void (*destroy)(void *))
+{
+   unsigned long flags;
+   int head;
+
+   spin_lock_irqsave(&(r)->consumer_lock, flags);
+   spin_lock(&(r)->producer_lock);


   The innermost parens seem pointless here

[...]

+done:
+   /* Destroy all entries left in the batch. */
+   while (n--) {
+   destroy(batch[n]);
+   }


   Braces not needed here.


+   spin_unlock(&(r)->producer_lock);
+   spin_unlock_irqrestore(&(r)->consumer_lock, flags);


   Same comment about the innermost parens...

[...]

MBR, Sergei

Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume

[Sergei Shtylyov]

Hello!

On 4/17/2017 2:19 AM, Michael S. Tsirkin wrote:


Applications that consume a batch of entries in one go
can benefit from ability to return some of them back
into the ring.

Add an API for that - assuming there's space. If there's no space
naturally we can't do this and have to drop entries, but this implies
ring is full so we'd likely drop some anyway.

Signed-off-by: Michael S. Tsirkin 
---

Jason, in my mind the biggest issue with your batching patchset is the
backet drops on disconnect.  This API will help avoid that in the common


   Packet?

[...]

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 783e7f5..5fbeab4 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -457,6 +457,63 @@ static inline int ptr_ring_init(struct ptr_ring *r, int 
size, gfp_t gfp)
return 0;
 }

+/*
+ * Return entries into ring. Destroy entries that don't fit.
+ *
+ * Note: this is expected to be a rare slow path operation.
+ *
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
+static inline void ptr_ring_unconsume(struct ptr_ring *r, void **batch, int n,
+ void (*destroy)(void *))
+{
+   unsigned long flags;
+   int head;
+
+   spin_lock_irqsave(&(r)->consumer_lock, flags);
+   spin_lock(&(r)->producer_lock);


   The innermost parens seem pointless here

[...]

+done:
+   /* Destroy all entries left in the batch. */
+   while (n--) {
+   destroy(batch[n]);
+   }


   Braces not needed here.


+   spin_unlock(&(r)->producer_lock);
+   spin_unlock_irqrestore(&(r)->consumer_lock, flags);


   Same comment about the innermost parens...

[...]

MBR, Sergei

RE: [PATCH] ACPICA: Export mutex functions

[Zheng, Lv]

Hi,

> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Subject: Re: [PATCH] ACPICA: Export mutex functions
> 
> On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote:
> > The ACPICA mutex functions are based on the host OS functions, so they 
> > don't really buy you anything.
> You should just use the native Linux functions.
> >
> 
> You mean they don't really acquire the requested ACPI mutex,
> and the underlying DSDT which declares and uses the mutex
> just ignores if the mutex was acquired by acpi_acquire_mutex() ?
> 
> To clarify: You are saying that code such as
> 
>   acpi_status status;
> 
>   status = acpi_acquire_mutex(NULL, "\\_SB.PCI0.SBRG.SIO1.MUT0", 0x10);
>   if (ACPI_FAILURE(status)) {
>   pr_err("Failed to acquire ACPI mutex\n");
>   return -EBUSY;
>   }

Why do you need to access \_SB.PCI0.SBRG.SIO1.MUT0?
OSPM should only invoke entry methods predefined by ACPI spec or whatever specs.
There shouldn't be any needs that a driver acquires an arbitrary AML mutex.
You do not seem to have justified the usage model, IMO.

Thanks
Lv

>   ...
> 
> when used in conjunction with
> 
>   ...
>   Mutex (MUT0, 0x00)
>   Method (ENFG, 1, NotSerialized)
>   {
>   Acquire (MUT0, 0x0FFF)
>   ...
>   }
> 
> doesn't really provide exclusive access to the resource(s) protected
> by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?
> 
> Outch. Really ?
> 
> Thanks,
> Guenter
> 
> >
> > > -Original Message-
> > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > To: Moore, Robert ; Zheng, Lv
> > > ; Wysocki, Rafael J ;
> > > Len Brown 
> > > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > ker...@vger.kernel.org; Guenter Roeck 
> > > Subject: [PATCH] ACPICA: Export mutex functions
> > >
> > > Mutex functions may be needed by drivers. Examples are accesses to
> > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > environmental monitor registers, both which may also be accessed through
> > > DSDT.
> > >
> > > Signed-off-by: Guenter Roeck 
> > > ---
> > >  drivers/acpi/acpica/utxfmutex.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > 100644
> > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
> > > pathname, u16 timeout)
> > >   status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> > >   return (status);
> > >  }
> > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > >
> > >
> > > /***
> > > 
> > >   *
> > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
> > > acpi_string pathname)
> > >   acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > >   return (AE_OK);
> > >  }
> > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > --
> > > 2.7.4
> >

RE: [PATCH] ACPICA: Export mutex functions

[Zheng, Lv]

Hi,

> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Subject: Re: [PATCH] ACPICA: Export mutex functions
> 
> On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote:
> > The ACPICA mutex functions are based on the host OS functions, so they 
> > don't really buy you anything.
> You should just use the native Linux functions.
> >
> 
> You mean they don't really acquire the requested ACPI mutex,
> and the underlying DSDT which declares and uses the mutex
> just ignores if the mutex was acquired by acpi_acquire_mutex() ?
> 
> To clarify: You are saying that code such as
> 
>   acpi_status status;
> 
>   status = acpi_acquire_mutex(NULL, "\\_SB.PCI0.SBRG.SIO1.MUT0", 0x10);
>   if (ACPI_FAILURE(status)) {
>   pr_err("Failed to acquire ACPI mutex\n");
>   return -EBUSY;
>   }

Why do you need to access \_SB.PCI0.SBRG.SIO1.MUT0?
OSPM should only invoke entry methods predefined by ACPI spec or whatever specs.
There shouldn't be any needs that a driver acquires an arbitrary AML mutex.
You do not seem to have justified the usage model, IMO.

Thanks
Lv

>   ...
> 
> when used in conjunction with
> 
>   ...
>   Mutex (MUT0, 0x00)
>   Method (ENFG, 1, NotSerialized)
>   {
>   Acquire (MUT0, 0x0FFF)
>   ...
>   }
> 
> doesn't really provide exclusive access to the resource(s) protected
> by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?
> 
> Outch. Really ?
> 
> Thanks,
> Guenter
> 
> >
> > > -Original Message-
> > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > To: Moore, Robert ; Zheng, Lv
> > > ; Wysocki, Rafael J ;
> > > Len Brown 
> > > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > ker...@vger.kernel.org; Guenter Roeck 
> > > Subject: [PATCH] ACPICA: Export mutex functions
> > >
> > > Mutex functions may be needed by drivers. Examples are accesses to
> > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > environmental monitor registers, both which may also be accessed through
> > > DSDT.
> > >
> > > Signed-off-by: Guenter Roeck 
> > > ---
> > >  drivers/acpi/acpica/utxfmutex.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > 100644
> > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
> > > pathname, u16 timeout)
> > >   status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> > >   return (status);
> > >  }
> > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > >
> > >
> > > /***
> > > 
> > >   *
> > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
> > > acpi_string pathname)
> > >   acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > >   return (AE_OK);
> > >  }
> > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > --
> > > 2.7.4
> >

[PATCH] efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space

[Ard Biesheuvel]

As reported by James, Catalin and Mark, commit e69176d68d26
("ef/libstub/arm/arm64: Randomize the base of the UEFI rt services
region") results in a crash in the firmware regardless of whether KASLR
is in effect or not, and whether the firmware implements EFI_RNG_PROTOCOL
or not.

Mark has identified the root cause to be the inappropriate use of
TASK_SIZE in the stub, which arm64 defines as

  #define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
TASK_SIZE_32 : TASK_SIZE_64)

and testing thread flags at this point results in the dereference of
pointers in uninitialized structures.

So instead, introduce a preprocessor symbol EFI_RT_VIRTUAL_LIMIT and
define it to TASK_SIZE_64 on arm64 and TASK_SIZE on ARM, both of which
are compile time constants. Also, change the 'headroom' variable to
static const to force an error if this might change in the future.

Cc: Matt Fleming 
Tested-by: Mark Rutland 
Tested-by: James Morse 
Tested-by: Catalin Marinas 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/libstub/arm-stub.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index 1e45ec51b094..34010ff3b77e 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -32,6 +32,12 @@
 #define EFI_RT_VIRTUAL_BASESZ_512M
 #define EFI_RT_VIRTUAL_SIZESZ_512M
 
+#ifdef CONFIG_ARM64
+#define EFI_RT_VIRTUAL_LIMIT   TASK_SIZE_64
+#else
+#define EFI_RT_VIRTUAL_LIMIT   TASK_SIZE
+#endif
+
 static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
 
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
@@ -236,8 +242,9 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
 * shift of 21 bit positions into account when scaling
 * the headroom value using a 32-bit random value.
 */
-   u64 headroom = TASK_SIZE - EFI_RT_VIRTUAL_BASE -
-  EFI_RT_VIRTUAL_SIZE;
+   static const u64 headroom = EFI_RT_VIRTUAL_LIMIT -
+   EFI_RT_VIRTUAL_BASE -
+   EFI_RT_VIRTUAL_SIZE;
u32 rnd;
 
status = efi_get_random_bytes(sys_table, sizeof(rnd),
-- 
2.9.3

[PATCH] efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space

[Ard Biesheuvel]

As reported by James, Catalin and Mark, commit e69176d68d26
("ef/libstub/arm/arm64: Randomize the base of the UEFI rt services
region") results in a crash in the firmware regardless of whether KASLR
is in effect or not, and whether the firmware implements EFI_RNG_PROTOCOL
or not.

Mark has identified the root cause to be the inappropriate use of
TASK_SIZE in the stub, which arm64 defines as

  #define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
TASK_SIZE_32 : TASK_SIZE_64)

and testing thread flags at this point results in the dereference of
pointers in uninitialized structures.

So instead, introduce a preprocessor symbol EFI_RT_VIRTUAL_LIMIT and
define it to TASK_SIZE_64 on arm64 and TASK_SIZE on ARM, both of which
are compile time constants. Also, change the 'headroom' variable to
static const to force an error if this might change in the future.

Cc: Matt Fleming 
Tested-by: Mark Rutland 
Tested-by: James Morse 
Tested-by: Catalin Marinas 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/libstub/arm-stub.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index 1e45ec51b094..34010ff3b77e 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -32,6 +32,12 @@
 #define EFI_RT_VIRTUAL_BASESZ_512M
 #define EFI_RT_VIRTUAL_SIZESZ_512M
 
+#ifdef CONFIG_ARM64
+#define EFI_RT_VIRTUAL_LIMIT   TASK_SIZE_64
+#else
+#define EFI_RT_VIRTUAL_LIMIT   TASK_SIZE
+#endif
+
 static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
 
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
@@ -236,8 +242,9 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
 * shift of 21 bit positions into account when scaling
 * the headroom value using a 32-bit random value.
 */
-   u64 headroom = TASK_SIZE - EFI_RT_VIRTUAL_BASE -
-  EFI_RT_VIRTUAL_SIZE;
+   static const u64 headroom = EFI_RT_VIRTUAL_LIMIT -
+   EFI_RT_VIRTUAL_BASE -
+   EFI_RT_VIRTUAL_SIZE;
u32 rnd;
 
status = efi_get_random_bytes(sys_table, sizeof(rnd),
-- 
2.9.3

[GIT PULL] EFI fixup for v4.12 queue

[Ard Biesheuvel]

Hi all,

Please merge this onto the v4.12 EFI queue: it fixes an issue reported with
-next where arm64 machines fail to boot due to a premature dereference of the
'current' pointer.

The following changes since commit efc491b0f06f65ea588f6591f0bc31db779e0594:

  ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region 
(2017-04-02 16:36:29 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next

for you to fetch changes up to d3e759649e1b057da72a8981aaafcd2f34f10681:

  efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space 
(2017-04-17 08:16:25 +0100)


A single fix for a regression caused by changes that are queued for v4.12:
- don't use TASK_SIZE in the stub on arm64, as it depends on thread flags


Ard Biesheuvel (1):
  efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space

 drivers/firmware/efi/libstub/arm-stub.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

[GIT PULL] EFI fixup for v4.12 queue

[Ard Biesheuvel]

Hi all,

Please merge this onto the v4.12 EFI queue: it fixes an issue reported with
-next where arm64 machines fail to boot due to a premature dereference of the
'current' pointer.

The following changes since commit efc491b0f06f65ea588f6591f0bc31db779e0594:

  ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region 
(2017-04-02 16:36:29 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next

for you to fetch changes up to d3e759649e1b057da72a8981aaafcd2f34f10681:

  efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space 
(2017-04-17 08:16:25 +0100)


A single fix for a regression caused by changes that are queued for v4.12:
- don't use TASK_SIZE in the stub on arm64, as it depends on thread flags


Ard Biesheuvel (1):
  efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space

 drivers/firmware/efi/libstub/arm-stub.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

Re: [PATCH v3 1/1] perf tools: fix perf build with ARCH=x86_64

[Jiada Wang]

On 04/10/2017 12:44 AM, Jiri Olsa wrote:

On Sun, Apr 09, 2017 at 07:43:15PM -0700, Jiada Wang wrote:

Hello Jiri

On 04/09/2017 10:27 AM, Jiri Olsa wrote:

On Tue, Apr 04, 2017 at 11:25:44PM -0700, jiada_w...@mentor.com wrote:

From: Jiada Wang

with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable)
the following build failure is seen when build with ARCH=x86_64

is that described somewhere as a valid building interface?
I never use it so I have no idea.. would you describe your
build env/process?

I used "ARCH=x86_64 make -C tools perf V=1" to build perf for x86_64 ARCH.

you're on x86 machine right? I don't see CROSS_COMPILE being used..

what's the purpose of the ARCH var setup then?

Sorry for late response.

Yes, I am on x86 machine, and want to build for x86_64,
I didn't mention CROSS_COMPILE option in my last reply is because no
matter what 'CROSS_COMPILE' is, the issue can be reproduced when 
ARCH=X86_64.


The full command I used to build perf, is somewhat near to
make -C tools perf V=2 ARCH=x86_64 CROSS_COMPILE=i686-pc-linux-gnc-g 
CC=i686-pc-linux-gnc-gcc


Thanks,
Jiada




In file included from util/event.c:2:0:
  tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No 
such file or directory
  compilation terminated.

fix this issue by use SRCARCH instead of ARCH in perf.

please describe also the the issue itself in the changelog, not just the fix

I will update changelog with detail information about the issue in v4


so objtool is using SRCARCH this way, I guess it's fine

if we go this way, you also need to change the pmu-events/Build
and there's some comment using $(ARCH) in util/header.c

will update pmu-events/Build in v4

I'll check

thanks,
jirka

Re: [PATCH v3 1/1] perf tools: fix perf build with ARCH=x86_64

[Jiada Wang]

On 04/10/2017 12:44 AM, Jiri Olsa wrote:

On Sun, Apr 09, 2017 at 07:43:15PM -0700, Jiada Wang wrote:

Hello Jiri

On 04/09/2017 10:27 AM, Jiri Olsa wrote:

On Tue, Apr 04, 2017 at 11:25:44PM -0700, jiada_w...@mentor.com wrote:

From: Jiada Wang

with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable)
the following build failure is seen when build with ARCH=x86_64

is that described somewhere as a valid building interface?
I never use it so I have no idea.. would you describe your
build env/process?

I used "ARCH=x86_64 make -C tools perf V=1" to build perf for x86_64 ARCH.

you're on x86 machine right? I don't see CROSS_COMPILE being used..

what's the purpose of the ARCH var setup then?

Sorry for late response.

Yes, I am on x86 machine, and want to build for x86_64,
I didn't mention CROSS_COMPILE option in my last reply is because no
matter what 'CROSS_COMPILE' is, the issue can be reproduced when 
ARCH=X86_64.


The full command I used to build perf, is somewhat near to
make -C tools perf V=2 ARCH=x86_64 CROSS_COMPILE=i686-pc-linux-gnc-g 
CC=i686-pc-linux-gnc-gcc


Thanks,
Jiada




In file included from util/event.c:2:0:
  tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No 
such file or directory
  compilation terminated.

fix this issue by use SRCARCH instead of ARCH in perf.

please describe also the the issue itself in the changelog, not just the fix

I will update changelog with detail information about the issue in v4


so objtool is using SRCARCH this way, I guess it's fine

if we go this way, you also need to change the pmu-events/Build
and there's some comment using $(ARCH) in util/header.c

will update pmu-events/Build in v4

I'll check

thanks,
jirka

[PATCH] perf/core: Remove redundant get_online_cpus()

[Thomas Gleixner]

SyS_perf_event_open() calls get_online_cpus() and eventually invokes
swevent_hlist_get() which does it again. 

All callchains leading to swevent_hlist_get() originate from
SyS_perf_event_open() so the extra protection is redundant.

Remove it.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
---
 kernel/events/core.c |5 -
 1 file changed, 5 deletions(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7592,7 +7592,6 @@ static int swevent_hlist_get(void)
 {
int err, cpu, failed_cpu;
 
-   get_online_cpus();
for_each_possible_cpu(cpu) {
err = swevent_hlist_get_cpu(cpu);
if (err) {
@@ -7600,8 +7599,6 @@ static int swevent_hlist_get(void)
goto fail;
}
}
-   put_online_cpus();
-
return 0;
 fail:
for_each_possible_cpu(cpu) {
@@ -7609,8 +7606,6 @@ static int swevent_hlist_get(void)
break;
swevent_hlist_put_cpu(cpu);
}
-
-   put_online_cpus();
return err;
 }
 

[PATCH] perf/core: Remove redundant get_online_cpus()

[Thomas Gleixner]

SyS_perf_event_open() calls get_online_cpus() and eventually invokes
swevent_hlist_get() which does it again. 

All callchains leading to swevent_hlist_get() originate from
SyS_perf_event_open() so the extra protection is redundant.

Remove it.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
---
 kernel/events/core.c |5 -
 1 file changed, 5 deletions(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7592,7 +7592,6 @@ static int swevent_hlist_get(void)
 {
int err, cpu, failed_cpu;
 
-   get_online_cpus();
for_each_possible_cpu(cpu) {
err = swevent_hlist_get_cpu(cpu);
if (err) {
@@ -7600,8 +7599,6 @@ static int swevent_hlist_get(void)
goto fail;
}
}
-   put_online_cpus();
-
return 0;
 fail:
for_each_possible_cpu(cpu) {
@@ -7609,8 +7606,6 @@ static int swevent_hlist_get(void)
break;
swevent_hlist_put_cpu(cpu);
}
-
-   put_online_cpus();
return err;
 }
 

[PATCH] [media] atmel-isc: Fix the static checker warning

[Songjun Wu]

Initialize the pointer 'fmt' before the start of
the loop.

Reported-by: Dan Carpenter 
Signed-off-by: Songjun Wu 
---

 drivers/media/platform/atmel/atmel-isc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 7dacf8c1354f..c4b2115559a5 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1490,6 +1490,7 @@ static int isc_formats_init(struct isc_device *isc)
}
}
 
+   fmt = _formats[0];
for (i = 0, num_fmts = 0; i < ARRAY_SIZE(isc_formats); i++) {
if (fmt->isc_support || fmt->sd_support)
num_fmts++;
-- 
2.11.0

[PATCH] [media] atmel-isc: Fix the static checker warning

[Songjun Wu]

Initialize the pointer 'fmt' before the start of
the loop.

Reported-by: Dan Carpenter 
Signed-off-by: Songjun Wu 
---

 drivers/media/platform/atmel/atmel-isc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 7dacf8c1354f..c4b2115559a5 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1490,6 +1490,7 @@ static int isc_formats_init(struct isc_device *isc)
}
}
 
+   fmt = _formats[0];
for (i = 0, num_fmts = 0; i < ARRAY_SIZE(isc_formats); i++) {
if (fmt->isc_support || fmt->sd_support)
num_fmts++;
-- 
2.11.0

Re: [patch 03/20] padata: Make padata_alloc() static

[Thomas Gleixner]

On Sun, 16 Apr 2017, Jason A. Donenfeld wrote:

> I rather like this option of padata, which, since it lives in
> kernel/padata.c and linux/padata.h, should be generic and useful for
> other components. Seems like the ability to allocate it for a
> particular set of worker CPUs and callback CPUs could be useful down
> the line. Would rather not see it become static.

It's simple enough to export it once there is an actual user. Just keeping
stuff global because it might be useful somewhere down the road is really
pointless.

Thanks,

tglx

Re: [patch 03/20] padata: Make padata_alloc() static

[Thomas Gleixner]

On Sun, 16 Apr 2017, Jason A. Donenfeld wrote:

> I rather like this option of padata, which, since it lives in
> kernel/padata.c and linux/padata.h, should be generic and useful for
> other components. Seems like the ability to allocate it for a
> particular set of worker CPUs and callback CPUs could be useful down
> the line. Would rather not see it become static.

It's simple enough to export it once there is an actual user. Just keeping
stuff global because it might be useful somewhere down the road is really
pointless.

Thanks,

tglx